演员内部 GetStateAsync 上的 System.Fabric.FabricNotPrimaryException

Question

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

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

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

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

一旦发生此异常并且演员被停用，他们不会被重新激活。

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

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

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

不健康事件：SourceId='System.FM'、Property='State'、HealthState='Warning'、ConsideWarningAsError=false。 分区重新配置花费的时间比预期的要长。 结构：/Ism.TvcRecognition.App/TvChannelMonitor 3 3 4dcca5ee-2297-44f9-b63e-76a60df3bc3d S/S IB _Node1_4 向上 131456742276273986 S/P RD_Node1_2 向上 131456742361691499 P/S RD_Node1_0 Down 131457861497316547 （显示 4 个副本中的 3 个。可用副本总数：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)：句柄无效 在 Tools.EtlReader.TraceFileEventReader.ReadEvents（日期时间开始时间，日期时间结束时间） 在 System.Fabric.Dca.Utility.PerformWithRetries[T]（Action`1 worker，T 上下文，RetriableOperationExceptionHandler exceptionHandler，Int32 initialRetryIntervalMs，Int32 maxRetryCount，Int32 maxRetryIntervalMs） 在 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_4dcca5ee-2297- 44f9-b63e-76a60df3bc3d\R_131457861497316547\edbres00002.jrs” 在偏移量 5242880 (0x0000000000500000) 处 0 (0x00000000) 个字节在 0.000 秒后失败，系统错误 112 (0x0000000)“磁盘上没有足够的空间”。写入操作将失败，错误为 -1808 (0xfffff8f0)。如果此错误仍然存​​在，则文件可能已损坏，可能需要从以前的备份中恢复。

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

Answer 1

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

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

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

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