升级 Azure Service Fabric 群集

对于任何新式系统而言,为可升级性做好规划是实现产品长期成功的关键所在。 Azure Service Fabric 群集是你拥有的,但部分由世纪互联管理的资源。 本文说明自动管理的项目以及可以自行配置的项目。

控制群集中运行的结构版本

可以将群集设置为 21ViaNet 发布自动结构升级时接收该升级,也可以选择想要群集安装的受支持结构版本。

为此,请门户上设置“upgradeMode”群集配置,或者在创建时或稍后在实时群集上使用 Resource Manager 进行设置。

Note

请确保群集始终运行受支持的结构版本。 当我们公布新版本的 Service Fabric 发布后,则标志着自该日期起至少 60 天以后结束对旧版本的支持。 新版发布会在 Service Fabric 团队博客中通告。 之后新版本则可供选择。

群集运行的版本过期前 14 天,系统会生成运行状况事件,使群集进入警告运行状况状态。 在升级到支持的结构版本之前,群集将保持警告状态。

通过门户设置升级模式

创建群集时可以将群集设置为自动或手动模式。

Create_Manualmode

在实时群集上可以利用管理经验将群集设置为自动或手动模式。

在设置为手动模式的群集上,通过门户升级到新版本。

若要升级到新版本,只需从下拉列表中选择可用的版本并保存即可。 结构升级会被自动启动。 升级过程中遵守群集运行状况策略(节点运行状况和所有在群集中运行的应用程序的运行状况的组合)。

如果不符合现行的群集运行状况策略,则回滚升级。 请在本文档中向下滚动,详细了解如何设置这些自定义运行状况策略。

修复造成回滚的问题后,需要按照与之前完全相同的步骤重新启动升级。

Manage_Automaticmode

通过 Resource Manager 模板设置升级模式

将“upgradeMode”配置添加到 Microsoft.ServiceFabric/clusters 资源定义,将“clusterCodeVersion”设置为支持的结构版本之一,如下所示,并部署模板。 “upgradeMode”的有效值为“Manual”或“Automatic”。

ARMUpgradeMode

在设置为手动模式的群集上,通过 Resource Manager 模板升级到新版本。

当群集处于手动模式时,要升级到新版本,请将“clusterCodeVersion”更改为支持的版本,然后部署该版本。 模板的部署启动了结构升级自动被启动。 在升级期间,将遵守群集运行状况策略(节点运行状况和所有在群集中运行的应用程序的运行状况的组合)。

如果不符合现行的群集运行状况策略,则回滚升级。 请在本文档中向下滚动,详细了解如何设置这些自定义运行状况策略。

解决导致回滚的问题后,需要遵循前面相同的步骤再次启动升级。

获取给定订阅的所有环境的所有可用版本列表

运行以下命令,应会获得类似于此的输出。

“supportExpiryUtc”告知给定的版本何时即将到期或已过期。 最新版本没有有效日期 - 它的值为“9999-12-31T23:59:59.9999999”,这只是表示尚未设置过期日期。

GET https://<endpoint>/subscriptions/{{subscriptionId}}/providers/Microsoft.ServiceFabric/locations/{{location}}/clusterVersions?api-version=2016-09-01

Example: https://management.chinacloudapi.cn/subscriptions/1857f442-3bce-4b96-ad95-627f76437a67/providers/Microsoft.ServiceFabric/locations/chinaeast/clusterVersions?api-version=2016-09-01

Output:
{
                  "value": [
                    {
                      "id": "subscriptions/35349203-a0b3-405e-8a23-9f1450984307/providers/Microsoft.ServiceFabric/environments/Windows/clusterVersions/5.0.1427.9490",
                      "name": "5.0.1427.9490",
                      "type": "Microsoft.ServiceFabric/environments/clusterVersions",
                      "properties": {
                        "codeVersion": "5.0.1427.9490",
                        "supportExpiryUtc": "2016-11-26T23:59:59.9999999",
                        "environment": "Windows"
                      }
                    },
                    {
                      "id": "subscriptions/35349203-a0b3-405e-8a23-9f1450984307/providers/Microsoft.ServiceFabric/environments/Windows/clusterVersions/4.0.1427.9490",
                      "name": "5.1.1427.9490",
                      "type": " Microsoft.ServiceFabric/environments/clusterVersions",
                      "properties": {
                        "codeVersion": "5.1.1427.9490",
                        "supportExpiryUtc": "9999-12-31T23:59:59.9999999",
                        "environment": "Windows"
                      }
                    },
                    {
                      "id": "subscriptions/35349203-a0b3-405e-8a23-9f1450984307/providers/Microsoft.ServiceFabric/environments/Windows/clusterVersions/4.4.1427.9490",
                      "name": "4.4.1427.9490",
                      "type": " Microsoft.ServiceFabric/environments/clusterVersions",
                      "properties": {
                        "codeVersion": "4.4.1427.9490",
                        "supportExpiryUtc": "9999-12-31T23:59:59.9999999",
                        "environment": "Linux"
                      }
                    }
                  ]
                }

群集升级模式为“自动”时的结构升级行为

Azure 将维护 Azure 群集中运行的结构代码和配置。 我们根据需要,对软件执行受监视的自动升级。 升级的部分可能是代码和/或配置。 为了确保应用程序不受这些升级的影响或者将影响降到最低,我们分以下阶段执行升级:

阶段 1:使用所有群集运行状况策略执行升级

在此阶段,升级过程将每次升级一个升级域,已在群集中运行的应用程序将继续运行,而不会造成任何停机时间。 升级过程中遵守群集运行状况策略(节点运行状况和所有在群集中运行的应用程序的运行状况的组合)。

如果不符合现行的群集运行状况策略,则回滚升级。 然后,系统会向订阅所有者发送一封电子邮件。 电子邮件中包含以下信息:

  • 有关必须回滚群集升级的通知。
  • 建议的补救措施(如果有)。
  • 距离执行阶段 2 的天数 (n)。

如果有任何升级因为基础结构方面的原因而失败,我们将尝试多次执行同一升级。 自电子邮件发送日期的 n 天之后,我们继续执行阶段 2。

如果符合群集运行状况策略,则升级被视为成功并标记为完成。 在此阶段进行初始升级或重新运行任何升级期间,可能发生这种情形。 如果运行成功,不会发送任何电子邮件确认。 这是为了避免发送过多的电子邮件。收到电子邮件则表示出现异常。 大多数群集升级预期都会成功,且不影响应用程序可用性。

阶段 2:仅使用默认运行状况策略执行升级

在此阶段设置好运行状况策略,以便在升级开始时运行正常的应用程序数目在升级程序期间保持不变。 与阶段 1 一样,阶段 2 升级过程将每次升级一个升级域,已在群集中运行的应用程序将继续运行,而不会造成任何停机时间。 在升级期间,将遵守群集运行状况策略(节点运行状况和所有在群集中运行的应用程序的运行状况的组合)。

如果不符合现行的群集运行状况策略,则回滚升级。 然后,系统会向订阅所有者发送一封电子邮件。 电子邮件中包含以下信息:

  • 有关必须回滚群集升级的通知。
  • 建议的补救措施(如果有)。
  • 距离执行阶段 3 的天数 (n)。

如果有任何升级因为基础结构方面的原因而失败,我们应尝试多次执行同一升级。 将在 n 天结束前的几天发送提醒电子邮件。 自电子邮件发送日期的 n 天之后,我们将继续执行阶段 3。 必须认真看待阶段 2 发送的电子邮件并采取补救措施。

如果符合群集运行状况策略,则升级被视为成功并标记为完成。 在此阶段进行初始升级或重新运行任何升级期间,可能发生这种情形。 如果运行成功,不会发送任何电子邮件确认。

阶段 3:使用积极的群集运行状况策略执行升级

此阶段中的这些运行状况策略旨在升级完成,而不反映应用程序的运行状况。 极少的群集升级会在此阶段结束。 如果群集进入此阶段,则表示应用程序有可能变得不正常和/或失去可用性。

类似于另外两个阶段,阶段 3 每次升级一个升级域。

如果不符合现行的群集运行状况策略,则回滚升级。 如果有任何升级因为基础结构方面的原因而失败,我们应尝试多次执行同一升级。 之后,便会锁定群集,使它不再接收支持和/或升级。

系统会将包含此信息以及补救措施的电子邮件发送给订阅所有者。 预期不会有任何群集遇到阶段 3 失败的状况。

如果符合群集运行状况策略,则升级被视为成功并标记为完成。 在此阶段进行初始升级或重新运行任何升级期间,可能发生这种情形。 如果运行成功,将不发送任何电子邮件确认。

可以控制的群集配置

除了设置群集升级模式外,还可以在实时群集上更改以下配置。

证书

通过门户可以轻松为群集新增或删除证书。 请参阅此文档中的详细说明

显示 Azure 门户中证书指纹的屏幕截图。

应用程序端口

可以通过更改与节点类型关联的负载均衡器资源属性来更改应用程序端口。 可以使用门户或者直接使用 Resource Manager PowerShell。

若要在某个节点类型中的所有 VM 上打开新端口,请执行以下操作:

  1. 将新探测添加到相应的负载均衡器。

    如果群集是使用门户部署的,则负载均衡器将命名为“LB-name of the Resource group-NodeTypename”,每个节点类型各有一个负载均衡器。 由于负载均衡器名称只是在资源组中唯一,因此最好在特定资源组下搜索名称。

    显示如何在门户中向负载均衡器添加探测的屏幕截图。

  2. 将新规则添加到负载均衡器。

    使用在上一个步骤中创建的探测,向同一负载均衡器添加新规则。

    在门户中向负载均衡器添加新规则。

放置属性

对于每个节点类型,可以添加要在应用程序中使用的自定义放置属性。 NodeType 是无需显式添加即可使用的默认属性。

Note

有关使用放置约束、节点属性以及如何定义它们的详细信息,请参阅 Service Fabric 群集 Resource Manager 文档描述群集中的“放置约束和节点属性”部分。

容量度量值

对于每个节点类型,可以添加要在应用程序中用于报告负载的自定义容量度量值。 有关使用容量指标来报告负载的详细信息,请参阅 Service Fabric 群集 Resource Manager 文档描述群集,以及指标和负载

Fabric 升级设置 - 运行状况策略

可为结构升级指定自定义运行状况策略。 如果已将群集设置为“自动”结构升级,则这些策略将应用到自动结构升级的阶段 1。 如果已将群集设置为“手动”结构升级,则每当选择新版本,因而触发系统开始在群集中进行结构升级时,就会应用这些策略。 如果未重写这些策略,则使用默认值。

在“结构升级”边栏选项卡下面,可以选择高级升级设置来指定自定义运行状况策略,或者查看当前设置。 请参考下图了解操作方法。

管理自定义运行状况策略

自定义群集的结构设置

请参阅 Service Fabric 群集结构设置了解可以如何自定义这些设置。

构成群集的 VM 上的操作系统修补

请参考可部署在群集上的修补业务流程应用程序,以便以协调一致的方式从 Windows 更新安装修补程序,从而使服务始终可用。

构成群集的 VM 上的操作系统升级

如果必须升级群集虚拟机上的操作系统映像,必须一次升级一个 VM。 需要自行负责这种升级 - 目前没有自动化的功能用于实现此目的。

后续步骤