Service Fabric 常见问题

有许多关于 Service Fabric 可以做些什么以及应该如何使用的常见问题。 本文档介绍其中许多常见问题及其答案。

群集设置和管理

如何回退 Service Fabric 群集证书?

回退应用程序的任何升级需要在提交更改的 Service Fabric 群集仲裁前,进行运行状况故障检测;已提交的更改只能前滚。 如果引入了不受监控的重大证书更改,则可能需要呈报工程师的通过客户支持服务才能恢复群集。 Service Fabric 的应用程序升级应用应用程序升级参数,并提供零停机时间升级承诺。 按照建议的应用程序升级监视模式,更新域上的自动更新进度基于运行状况检查是否通过,如果更新默认服务失败,将自动回退。

如果你的群集仍在利用资源管理器模板中的经典 Certificate Thumbprint 属性,建议你将群集从证书指纹更改为公用名称,以便利用新式机密管理功能。

是否可以创建跨越多个 Azure 区域或自己的数据中心的群集?

是的。

核心 Service Fabric 群集技术可用于将世界各地运行的计算机集合到一起,前提是它们相互之间已建立网络连接。 然而,生成并运行这样的群集可能很复杂。

如果你对此方案有兴趣,建议你通过 Service Fabric Github 问题列表或通过支持代表联系我们以获取其他指南。 Service Fabric 团队正在努力针对此方案提供其他解释、指南和建议。

应考虑的一些事项:

  1. 如同构建群集的虚拟机规模集一样,Azure 中的 Service Fabric 群集资源如今也是区域性的。 这意味着如果出现区域性故障,将可能无法通过 Azure 资源管理器或 Azure 门户管理群集。 即使群集仍在运行,且你能够直接与其交互,也可能发生此情况。 此外,Azure 目前不提供创建跨区域可用的单个虚拟网络的功能。 这意味着 Azure 中的多区域群集需要适用于 VM 规模集中的每个 VM 的公共 IP 地址Azure VPN 网关。 这些网络选择对成本、性能以及某种程度上的应用程序设计都有不同的影响,因此需要在选择此类环境前仔细分析和规划。
  2. 维护、管理和监视这些计算机可能会变得很复杂,尤其是在跨多种类型环境时,比如不同云提供程序之间或本地资源和 Azure 之间。 必须格外小心,确保在此类环境中运行生产工作负荷前,已了解群集和应用程序的升级、监视、管理和诊断。 如果你已有在 Azure 或自己的数据中心解决这些问题的经验,则很可能这些相同的解决方案在生成或运行 Service Fabric 群集时均适用。

Service Fabric 节点是否会自动接收操作系统更新?

目前不是,但这也是一个常见的请求,Azure 有意推出此功能。

在此期间,我们已提供一个应用程序,Service Fabric 节点下的操作系统不断修补并保持最新状态。

操作系统更新的挑战在于,它们通常需要重启计算机,而这会导致暂时丢失可用性。 就其自身而言,这不是问题,因为 Service Fabric 会自动将这些服务的流量重定向到其他节点。 但是,如果不在群集间协调操作系统更新,可能会有多个节点同时停机。 此类同时重启可能导致某个服务完全失去可用性,或至少让特定分区(对于有状态服务)失去可用性。

将来,我们计划支持在更新域之间完全自动化的、经过协调的 OS 更新策略,确保即使重新启动或发生其他意外故障,也仍能保持可用性。

是否可以在我的 SF 群集中使用大型虚拟机规模集?

简短解答 - 否。

详细解答 - 尽管通过大型虚拟机规模集可将虚拟机规模集扩展至多达 1000 个 VM 实例,但这是通过使用放置组 (PG) 实现的。 容错域 (FD) 和升级域 (UD) 仅在使用 FD 和 UD 来为服务副本/服务实例做出放置决策的放置组 Service Fabric 中保持一致。 因为 FD 和 UD 仅在放置组中可比较,因此 SF 无法使用它。 例如,如果 PG1 中的 VM1 具有一个 FD=0 的拓扑,并且 PG2 中的 VM9 具有一个 FD=4 的拓扑,这并不意味着 VM1 和 VM2 在两个不同的硬件机架上,因此在这种情况下 SF 无法使用 FD 值做出放置决策。

当前,大型虚拟机规模集还存在其他问题,例如缺少 level-4 负载均衡支持。 请参考有关大型规模集的详细信息

Service Fabric 群集的最小大小如何? 为什么不能更小?

运行生产工作负荷的 Service Fabric 群集支持的最小大小是五个节点。 对于开发/测试方案,我们支持三节点群集。

存在这些最小值的原因在于,Service Fabric 群集运行一组有状态系统服务,其中包括命名服务和故障转移管理器。 这些服务跟踪哪些服务已部署到群集及其当前的托管位置,取决于非常一致性。 而这种非常一致性又取决于能否获取仲裁来更新这些服务的状态,其中,仲裁表示给定服务在严格意义上的大多数副本 (N/2 + 1)。

在了解这种背景的前提下,让我们探讨一些可能的群集配置:

单节点:此选项无法提供高可用性,因为出于任何原因丢失单个节点就意味着丢失整个群集。

双节点:跨两个节点 (N = 2) 部署的服务的仲裁为 2 (2/2 + 1 = 2)。 丢失单个副本时,无法创建仲裁。 由于执行服务升级要求暂时关闭副本,因此这不是一个有用的配置。

三节点:包含三个节点 (N = 3),创建仲裁仍然要求使用两个节点 (3/2 + 1 = 2)。 这意味着,可以丢失单个节点,在这种情况下,仍可保留仲裁。

开发/测试支持三节点群集配置,因为只要不同时发生,就可以安全地执行升级以及从单独的节点故障中恢复。 对于生产工作负荷,必须具有应对此类同时发生的故障的复原能力,因此需要五个节点。

是否可以在夜间/周末关闭群集以节约成本?

一般而言,不可以。 Service Fabric 在本地、临时磁盘上存储状态,这意味着如果虚拟机移到其他主机,数据不会随之移动。 在正常操作中,这是没有问题的,因为其他节点可使新节点保持最新状态。 但是,如果停止所有节点并重启,很可能发生的情况是,大部分节点在新主机上启动,导致系统无法恢复。

如果在部署应用程序之前想要创建群集来测试应用程序,我们建议将这些群集动态创建为持续集成/持续部署管道的一部分。

如何升级操作系统(例如从 Windows Server 2012 升级到 Windows Server 2016)?

我们致力于改善体验,但现在升级由你负责。 必须升级群集虚拟机上的 OS 映像,一次升级一个 VM。

是否可以对群集节点类型(虚拟机规模集)中的附加数据磁盘进行加密?

是的。 有关详细信息,请参阅创建具有附加数据磁盘的群集

在群集中运行防病毒程序时需要排除哪些目录和进程?

防病毒排除目录
Program Files\Microsoft Service Fabric
FabricDataRoot(从群集配置中)
FabricLogRoot(从群集配置中)
防病毒排除进程
Fabric.exe
FabricHost.exe
FabricInstallerService.exe
FabricSetup.exe
FabricDeployer.exe
ImageBuilder.exe
FabricGateway.exe
FabricDCA.exe
FabricFAS.exe
FabricUOS.exe
FabricRM.exe
FileStoreService.exe

应用程序设计

跨可靠集合的分区查询数据的最佳方法是什么?

Reliable Collections 通常已分区以支持扩展并提高性能和吞吐量。 这意味着,给定服务的状态可以分散在数十甚至数百台计算机上。 若要对这个完整的数据集执行操作,有以下几个选项:

  • 创建查询其他服务的所有分区的服务,拉入所需的数据。
  • 创建可从其他服务的所有分区接收数据的服务。
  • 定期将每个服务中的数据推送到外部存储。 此方法仅适用于要执行的查询不属于核心业务逻辑的情况。

跨执行组件查询数据的最佳方法是什么?

执行组件设计为独立的状态和计算单元,因此,不建议在运行时对执行组件状态执行广泛查询。 如果需要跨执行组件状态的完整集进行查询,应考虑以下方法之一:

  • 将执行组件服务替换为有状态 Reliable Services,使得从一定数目的执行组件中收集所有数据的网络请求数等于服务中的分区数。
  • 将执行组件设计为定期将其状态推送到外部存储,以方便查询。 如上所述,此方法仅在运行时行为不需要所执行的查询时才可行。

可以在可靠集合中存储多少数据?

Reliable Services 通常已分区,因此,存储量仅受限于群集中的计算机数量以及这些计算机的可用内存量。

例如,某个服务中的 Reliable Collection 包含 100 个分区和 3 个副本,存储平均大小为 1 KB 的对象。 现在假设群集中有 10 台计算机,每台计算机的内存为 16 GB。 我们做一个简单且保守的假设:操作系统和系统服务、Service Fabric 运行时以及服务消耗了 6GB 内存,也就是说,每个计算机还剩余 10GB 内存,整个群集还有 100GB 内存。

请记住,每个对象必须存储三次(一个主要副本和两个次要副本),满负荷运行时,集合可提供足够的内存来存储约 3.5 亿个对象。 但是,我们建议能够弹性应对故障域和升级域的同时丢失(它们会占用大约 1/3 的容量),并将对象数目减少到大约 2300 万个。

请注意,此计算还假设:

  • 跨分区的数据分布大致是均匀的,或者可向群集资源管理器报告负载指标。 默认情况下,Service Fabric 会根据副本计数执行负载均衡。 在前面的示例中,群集中的每个节点上会放置 10 个主副本和 20 个辅助副本。 这也适用于跨分区均匀分布的负载。 如果负载不均衡,必须报告负载,使 Resource Manager 能够将较小副本打包在一起,增加较大副本在单个节点上占用的内存。

  • 讨论的可靠服务是群集中存储状态的唯一服务。 由于可将多个服务部署到群集,因此你需要知道每个服务运行时以及管理其状态时所需的资源。

  • 群集本身不会变大或缩小。 如果添加更多计算机,Service Fabric 会重新平衡副本以利用新增容量,直到计算机数量超过服务中的分区数量,因为单独的副本不能跨计算机。 相比之下,如果通过删除计算机来减小群集大小,副本将更加严密地打包,减少总体容量消耗。

可以在执行组件中存储多少数据?

和 Reliable Services 一样,可以在执行组件服务中存储的数据量仅受限于群集中各个节点的总磁盘空间和可用内存。 但是,单独的执行组件在用于封装少量状态和关联的业务逻辑时效率最高。 一般而言,单独的执行组件应具有以千字节为单位的状态。

其他问题

Service Fabric 如何与容器关联?

容器提供打包服务及其依赖项的简单方法,以便它们能够在所有环境中一致地运行并且可在单台计算机上以隔离方式运行。 使用 Service Fabric 可以部署和管理服务,包括在容器中打包的服务

你们是否打算开放 Service Fabric 源代码?

我们已在 GitHub 上开放了部分 Service Fabric 源代码(可靠服务框架可靠执行组件框架ASP.NET Core 集成库Service Fabric ExplorerService Fabric CLI),并接受有关这些项目的社区投稿。

我们最近宣布了计划完全开放 Service Fabric 运行时源代码。 当前,Service Fabric 存储库可在 GitHub 与 Linux 生成和测试工具上运行,这意味着可克隆存储库、为 Linux 构建 Service Fabric、运行基本测试、提出问题并提交拉取请求。 我们正在努力将 Windows 生成环境以及完整的 CI 环境迁移过来。

有关已发布的更多详细信息,请参阅 Service Fabric 博客

后续步骤