使用所有可用磁盘空间的 Service Fabric 日志答案

【问题标题】：Service Fabric logs consuming all available disk space使用所有可用磁盘空间的 Service Fabric 日志
【发布时间】：2017-11-18 15:13:57
【问题描述】：

我有几个集群现在已经运行了一个月左右，我发现临时存储完全被 Service Fabric 日志文件吞噬了。在只有 16GB 本地存储的 F1 VM 的甜蜜舰队中，我几乎没有空间，其中一些现在已降至 30MB，是的兆字节存储（我的应用程序消耗的存储空间不到 1GB）所有版本）。

在查看集群 VM 上的磁盘使用情况时，我可以清楚地看到 SvcFab\Log 和 SvcFab\ReplicatorLog 文件夹占用了 90% 以上的可用空间。当然，SF可以更好地处理这个问题。有什么我可以切换或配置来让它刷新它的一些数据吗？还是将其移至 Blob 或表存储更好？

这对其他人来说一定是个问题。别人在做什么？ Service Fabric 团队，这方面的最佳做法是什么？

【问题讨论】：

对于 blob 存储，我想知道您是否尝试将存储帐户添加到 Microsoft.Compute/virtualMachineScaleSets: 'Microsoft.Storage/storageAccounts', 'supportLogStorageAccountName'
默认情况下，集群中添加了三个存储帐户（通过可用的 ARM 模板）。其中一个显然是用于“日志”的，我看到一堆性能计数器和各种日志文件，但似乎 SF 在磁盘空间使用方面没有正确维护本地 Log 和 ReplicatorLog 文件夹。
@BrettRobi 你有没有找到更好的解决方案？我遇到了这个问题，这让我很烦
@BBlake 不，我没有。此后我转移到 A1 实例，由于本地存储更大，这解决了问题，但处理能力有所损失。

标签： azure-service-fabric

【解决方案1】：

如果复制器日志已满，则表明您正在使用 F1 进行数据存储...... 16GB 对于您的数据存储来说并不算多，您最好将应用程序分解为具有不同集合的处理/存储服务。

不是 SF 如何存储东西的专家（我将把它留给其他人，但那里没有很多信息）但如果它与复制器日志类似的解决方案包含您的部分数据并且它会减少安全..另外，您可能最好使用 F2 和 F4 而不是 F1，因为它们具有 *2 或 *4 IO 和核心，您不会丢失任何东西，而是获得额外的存储空间.. 这意味着更少的复制（除非您进行大量分区) .

【讨论】：

不，事实上我目前在该集群上有一个非常简单的无状态服务。我的本地数据为零。您在增加 VM 大小方面做得很好，但是我不需要所有的处理能力也不需要内存。老实说，我似乎不必管理或担心 SF 数据存储，只需要我自己的。

【解决方案2】：

所以没有有用的帮助。我求助于拆除该集群并重建它。幸运的是，集群是一对集群中的一个，我能够通过 TrafficMgr 将所有流量简单地重定向到另一个集群，同时我销毁了有故障的集群并创建了一个新的集群。

让我很不安。如果我没有这种冗余，那将是一个相当大的问题。 :-(

【讨论】：

这类问题让我怀疑 Service Fabric 是不是一个好主意...（目前正在为我的公司评估 Service Fabric。）

【解决方案3】：

我不确定以下是否被视为拆除集群！我在虚拟服务结构应用程序上的无状态服务上对此进行了测试

我们在 standard_DS1_V2 上部署的服务结构遭受仲裁损失，并且健康分析服务也因磁盘空间不足而失败。我没有拆除集群，而是使用 ARM power shell 停止了 vm 规模集

stop-azurermvmss -ResourceGroupName "RG" -VMScaleSetName "VMSS"

然后转到 Azure 门户 > 资源组 > 虚拟机规模集 > 缩放以将 SKU 提升到 Standard_D1_V2 并启动 VM 规模集

start-azurermvmss -ResourceGroupName "RG" -VMScaleSetName "VMSS"

并重新部署了服务结构应用程序，它按预期工作！

【讨论】：