0

我也在 Github 上问过这个问题 - https://github.com/Azure/service-fabric-issues/issues/379

我有 (n) 个演员每秒钟都在连续提醒执行。

这些演员在过去 4 天里一直运行良好，但每个实例在调用 StateManager.GetStateAsync 时都会收到以下异常。随后，我看到所有的演员都被停用了。

我找不到与可靠参与者遇到的此异常有关的任何信息。

一旦发生此异常并且参与者被停用，它们就不会被重新激活。

发生此错误的条件是什么？如何进一步诊断问题？

“System.Fabric.FabricNotPrimaryException：引发了‘System.Fabric.FabricNotPrimaryException’类型的异常。在 Microsoft.ServiceFabric.Actors.Runtime.ActorStateProviderHelper.d__81.MoveNext() --- 堆栈跟踪从上一个引发异常的位置结束--- 在 System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess（任务任务） 在 System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification（任务任务） 在 Microsoft.ServiceFabric.Actors.Runtime.ActorStateManager.d__181.MoveNext() ---从先前引发异常的位置结束堆栈跟踪 --- 在 System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 在 Microsoft.ServiceFabric.Actors.Runtime 的 System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) .ActorStateManager.d__7`1.MoveNext()

看看集群资源管理器，我现在可以在该参与者服务的一个分区上看到以下警告：

不健康事件：SourceId='System.FM'、Property='State'、HealthState='Warning'、ConsideWarningAsError=false。分区重新配置花费的时间比预期的要长。fabric:/Ism.TvcRecognition.App/TvChannelMonitor 3 3 4dcca5ee-2297-44f9-b63e-76a60df3bc3d S/S IB _Node1_4 Up 131456742276273986 S/P RD _Node1_2 Up 131456742361691499 P/S RD _Node1_0 Down 131457861497316547 (Showing 3 out of 4 replicas.可用副本总数：1。）

在该分区的主副本中出现警告：

不健康事件：SourceId='System.RAP'、Property='IReplicator.CatchupReplicaSetDuration'、HealthState='Warning'、ConsideWarningAsError=false。

并在 ActiveSecondary 中发出警告：

不健康事件：SourceId='System.RAP'、Property='IStatefulServiceReplica.CloseDuration'、HealthState='Warning'、ConsideWarningAsError=false。开始时间（UTC）：2017-08-01 04:51:39.740_Node1_0

5 个节点中有 3 个显示以下错误：

不健康事件：SourceId='FabricDCA'、Property='DataCollectionAgent.DiskSpaceAvailable'、HealthState='Warning'、ConsideWarningAsError=false。数据收集代理 (DCA) 没有足够的磁盘空间进行操作。如果这种情况继续发生，将不会收集诊断信息。

更多信息：

我的集群设置由 5 个 D1 虚拟机节点组成。

Microsoft-Service Fabric 应用程序中的事件查看器错误：

我看到很多

无法从 ETL 文件 D:\SvcFab\Log\QueryTraces\query_traces_5.6.231.9494_131460372168133038_1.etl 读取部分或全部事件。System.ComponentModel.Win32Exception (0x80004005): 句柄在 System.Fabric.Dca.Utility.PerformWithRetries[T](Action`1 worker, T context, RetriableOperationExceptionHandler exceptionHandler, Int32 initialRetryIntervalMs, Int32 maxRetryCount, Int32 maxRetryIntervalMs) at FabricDCA.EtlProcessor.ProcessActiveEtlFile(FileInfo etlFile, DateTime lastEndTime, DateTime& newEndTime, CancellationToken cancelToken)

以及一堆警告，例如：

Api IStatefulServiceReplica.Close() 在分区 {4dcca5ee-2297-44f9-b63e-76a60df3bc3d} 副本 131457861497316547 上运行缓慢，StartTimeUTC = ‎2017‎-‎08‎-‎01T04:51:39.789083900Z

最后我想我可能是这一切的根源。事件查看器应用程序日志有一大堆错误，例如：

Ism.TvcRecognition.TvChannelMonitor (3688) (4dcca5ee-2297-44f9-b63e-76a60df3bc3d:131457861497316547)：尝试写入文件“D:\SvcFab_App\Ism.TvcRecognition.AppType_App1\work\P_4dcca-b6ee-2297-44e -76a60df3bc3d\R_131457861497316547\edbres00002.jrs" 在偏移量 5242880 (0x0000000000500000) 处 0 (0x00000000) 字节在 0.000 秒后失败，系统错误 112 (0x00000070)：“磁盘空间不足。”。写入操作将失败，错误为 -1808 (0xfffff8f0)。如果此错误仍然存​​在，则文件可能已损坏，可能需要从以前的备份中恢复。

好的，该错误指向 D 驱动器，即临时存储。它有 549 MB 的可用空间，而不是 50 GB。服务结构真的应该坚持到临时存储吗？

4

1 回答 1

2

回复：错误 - 是的，看起来磁盘已满导致故障。只是为了在这里结束循环——看起来你发现你的状态实际上并没有在集群中分布，一旦你修复了这个问题，你就不再看到磁盘已满。希望您的容量规划现在应该更有意义。

关于安全： TLDR：使用临时驱动器很好，因为您使用的是 Service Fabric。如果您不使用该驱动器获取真实数据，那将是一个非常糟糕的主意。

从 Azure 的角度来看，这些驱动器是“临时的”，因为它们是机器上的本地驱动器。Azure 不知道您在使用驱动器做什么，并且它不希望任何单个机器应用程序认为写入那里的数据是安全的，因为 Azure 可能会通过服务修复VM 以响应一堆不同的事情。

在 SF 中，我们将数据复制到多台机器上，因此使用本地磁盘很好/安全。SF 还与 Azure 集成，因此许多会破坏该数据的管理操作都在集群中进行管理，以防止这种情况发生。当 Azure 宣布将进行更新以破坏该节点上的数据时，我们会在允许这种情况发生之前将您的服务移动到其他位置，并尝试在此期间停止更新。更多关于这方面的信息在这里。

于 2017-08-25T17:32:49.563 回答