Развертывание управляемого кластера Service Fabric в зонах доступности

Статья
03/22/2024

Зоны доступности в Azure обеспечивают высокий уровень доступности, защищая приложения и данные от сбоев центров обработки данных. Зона доступности — уникальное физическое расположение, оснащенное независимым питанием, охлаждением и сетевым подключением в пределах региона Azure.

Управляемый кластер Service Fabric поддерживает развертывания, охватывающие несколько Зон доступности, чтобы обеспечить устойчивость зоны. Эта конфигурация обеспечивает высокий уровень доступности критически важных системных служб и приложений для защиты от единой точки сбоя. Функциональные возможности зон доступности Azure предоставляются не во всех регионах. Дополнительные сведения см. в статье Общие сведения о зонах доступности в Azure.

Примечание.

Охват зоны доступности доступен только в кластерах ценовой категории "Стандартный".

Доступны примеры шаблонов: Шаблон Service Fabric для разных зон доступности

Топология устойчивого к зонам управляемого кластера Azure Service Fabric

Примечание.

Преимущество охвата типа первичного узла в зонах доступности действительно рассматривается только для трех зон, а не только для двух.

Кластер Service Fabric, распределенный по Зоны доступности (AZ), обеспечивает высокий уровень доступности состояния кластера.

Рекомендуемая топология для управляемого кластера требует следующих ресурсов:

кластер должен быть ценовой категории "Стандартный";
Тип первичного узла должен иметь по крайней мере девять узлов (3 в каждом AZ) для обеспечения оптимальной устойчивости, но поддерживает минимальное число шести (2 в каждом AZ).
Вторичные типы узлов должны иметь по крайней мере шесть узлов для оптимальной устойчивости, но поддерживает минимальное число трех.

Примечание.

Поддерживаются только 3 развертывания зон доступности.

Примечание.

Невозможно на месте изменить масштабируемые наборы виртуальных машин в управляемом кластере с неохватывающего зоны на охваченный кластер.

Схема архитектуры зоны доступности Azure Service Fabric Архитектура зоны доступности Azure Service Fabric

Пример списка узлов, в котором показаны форматы FD/UD в масштабируемом наборе виртуальных машин, охватывающем разные зоны

Пример списка узлов, в котором показаны форматы FD/UD в масштабируемом наборе виртуальных машин, охватывающем разные зоны.

Распределение Реплик службы между зонами. При развертывании службы на типах узлов, охватывающих разные зоны, реплики размещаются так, чтобы обеспечить их попадание в отдельные зоны. Это разделение гарантируется, так как домен сбоя на узлах, присутствующих в каждом из этих типов узлов, настраивается с информацией о зоне (т. е. FD = fd:/zone1/1 и т. д.). Например, для пяти реплика или экземпляров службы распределение равно 2-2-1, а среда выполнения пытается обеспечить равное распределение между AZ.

Конфигурация реплики службы пользователя. Пользовательские службы с отслеживанием состояния, развернутые на типах узлов с разными зонами доступности, должны быть настроены в следующей конфигурации: число реплик с целевым значением = 9, минимальным = 5. Эта конфигурация помогает службе работать, даже если одна зона выходит из строя, так как шесть реплика по-прежнему будут работать в других двух зонах. Обновление приложения в таком сценарии также будет выполнено.

Сценарий понижения зоны: при понижении зоны все узлы в этой зоне отображаются как вниз. Реплики служб на этих узлах также будут отключены. Так как в других зонах есть реплика, служба продолжает реагировать с основными реплика отработки отказа в зоны, которые работают. Службы будут отображаться в состоянии предупреждения, так как целевое число реплика не выполняется, а количество виртуальных машин по-прежнему превышает определенный минимальный размер реплика. В результате подсистема балансировки нагрузки Service Fabric открывает реплика в рабочих зонах, чтобы соответствовать настроенной целевой реплика счетчику. На этом этапе службы должны отображаться здоровыми. При резервном копировании зоны, которая была вниз, подсистема балансировки нагрузки снова распределяет все реплика службы равномерно по всем зонам.

Конфигурация сети

Дополнительные сведения см. в разделе "Настройка параметров сети" для управляемых кластеров Service Fabric.

Включение устойчивого к зонам управляемого кластера Azure Service Fabric

Чтобы включить управляемый кластер Azure Service Fabric, необходимо включить следующее свойство ZonalResiliency , указывающее, является ли кластер устойчивым или нет.

{
  "apiVersion": "2021-05-01",
  "type": "Microsoft.ServiceFabric/managedclusters",
  "properties": {
  ...
  "zonalResiliency": "true",
  ...
  }
}

Перенос существующего отказоустойчивого кластера незон в устойчивый к зоне (предварительная версия)

Существующие управляемые кластеры Service Fabric, которые не охватываются между зонами доступности, теперь можно перенести на месте для охвата зон доступности. Поддерживаемые сценарии включают кластеры, созданные в регионах с тремя зонами доступности и кластерами в регионах, где три зоны доступности становятся доступными после развертывания.

Требования:

Стандартный кластер SKU.
Три зоны доступности в регионе.

Примечание.

Перенос в устойчивую к зонам конфигурацию может привести к кратковременной потере внешнего подключения через подсистему балансировки нагрузки, но не затронет работоспособность кластера. Это происходит, если необходимо создать новый общедоступный IP-адрес, чтобы устойчивость сети к сбоям зоны. Рекомендуется спланировать миграцию соответствующим образом.

Начните с определения необходимости нового IP-адреса и того, какие ресурсы необходимо перенести для обеспечения устойчивости зоны. Чтобы получить текущее состояние устойчивости зоны доступности для ресурсов управляемого кластера, используйте следующий вызов API:
```
POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ServiceFabric/managedClusters/{clusterName}/getazresiliencystatus?api-version=2022-02-01-preview
```
Вы также можете использовать модуль Az следующим образом:
```
Select-AzSubscription -SubscriptionId {subscriptionId}
Invoke-AzResourceAction -ResourceId /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ServiceFabric/managedClusters/{clusterName} -Action getazresiliencystatus -ApiVersion 2022-02-01-preview
```
Команда должна предоставить ответ, аналогичный следующему:
```
{
"baseResourceStatus" :[
  {
  "resourceName": "sfmccluster1"
  "resourceType": "Microsoft.Storage/storageAccounts"
  "isZoneResilient": false
  },
  {
  "resourceName": "PublicIP-sfmccluster1"
  "resourceType": "Microsoft.Network/publicIPAddresses"
  "isZoneResilient": false
  },
  {
  "resourceName": "primary"
  "resourceType": "Microsoft.Compute/virutalmachinescalesets"
  "isZoneResilient": false
  }
],
"isClusterZoneResilient": false
}
```
Если ресурс общедоступного IP-адреса не является устойчивым, миграция кластера приведет к краткой потере внешнего подключения. Эта потеря подключения возникает из-за миграции нового общедоступного IP-адреса и обновления полного доменного имени кластера (FQDN) до нового IP-адреса. Если ресурс общедоступного IP-адреса является устойчивым, миграция не изменит ресурс общедоступного IP-адреса или полное доменное имя, и не будет влиять на внешнее подключение.
Инициируйте преобразование базовой учетной записи хранения, созданной для управляемого кластера из локально избыточного хранилища (LRS) в резервную зону служба хранилища (ZRS) с помощью преобразования, инициированного клиентом. Группа ресурсов учетной записи хранения, которую необходимо перенести, будет иметь форму "SFC_ClusterId" (например, SFC_9240df2f-71ab-4733-a641-53a8464d992d) в той же подписке, что и ресурс управляемого кластера.
Добавление свойства зон в существующие типы узлов

На этом шаге настраивается масштабируемый набор управляемых виртуальных машин, связанный с типом узла как устойчивый к зонам, гарантируя, что все новые виртуальные машины, добавленные в него, будут развернуты в зонах доступности (зональные виртуальные машины). Если указанный тип узла является основным, поставщик ресурсов выполнит миграцию общедоступного IP-адреса вместе с обновлением DNS-доменного имени кластера( при необходимости) для обеспечения устойчивости зоны. getazresiliencystatus Используйте API для понимания последствий этого шага.

Используйте API версии 2022-02-01-preview или более поздней.

Добавьте параметр в ["1", "2", "3"] существующие zones типы узлов:

{
   "apiVersion": "2024-02-01-preview",
   "type": "Microsoft.ServiceFabric/managedclusters/nodetypes",
   "name": "[concat(parameters('clusterName'), '/', parameters('nodeTypeName'))]",
   "location": "[resourcegroup().location]",
   "dependsOn": [
     "[concat('Microsoft.ServiceFabric/managedclusters/', parameters('clusterName'))]"
   ],
   "properties": {
     ...
     "isPrimary": true,
     "zones": ["1", "2", "3"]
     ...
   }
},
{
   "apiVersion": "2024-02-01-preview",
   "type": "Microsoft.ServiceFabric/managedclusters/nodetypes",
   "name": "[concat(parameters('clusterName'), '/', parameters('nodeTypeNameSecondary'))]",
   "location": "[resourcegroup().location]",
   "dependsOn": [
     "[concat('Microsoft.ServiceFabric/managedclusters/', parameters('clusterName'))]"
   ],
   "properties": {
     ...
     "isPrimary": false,
     "zones": ["1", "2", "3"]
     ...
   }
}

Масштабирование типов узлов для добавления зональных узлов и удаления региональных узлов

На этом этапе Масштабируемые наборы виртуальных машин помечены как устойчивые к зонам. Таким образом, при масштабировании только что добавленные узлы будут зональными, а при масштабировании будут удалены региональные узлы. Этот подход обеспечивает гибкость масштабирования в любом порядке, который соответствует вашим требованиям к емкости, изменив vmInstanceCount свойство для типов узлов.

Например, если для начальной vmInstanceCount задано значение 6 (указывающее шесть региональных узлов), можно выполнить два развертывания:
- Первое развертывание: увеличьте vmInstanceCount до 12, чтобы добавить 6 зональных узлов.
- Второе развертывание: уменьшите vmInstanceCount до 6, чтобы удалить все региональные узлы.
На протяжении всего процесса можно проверка getazresiliencystatus API для получения состояния хода выполнения, как показано ниже. Процесс считается завершенным после того, как каждый тип узла имеет не менее шести зональных узлов и 0 региональных узлов.
```
{
"baseResourceStatus" :[
  {
  "resourceName": "sfmccluster1"
  "resourceType": "Microsoft.Storage/storageAccounts"
  "isZoneResilient": true
  },
  {
  "resourceName": "PublicIP-sfmccluster1"
  "resourceType": "Microsoft.Network/publicIPAddresses"
  "isZoneResilient": true
  },
  {
  "resourceName": "ntPrimary"
  "resourceType": "Microsoft.Compute/virutalmachinescalesets"
  "isZoneResilient": false
  "details": "Status: InProgress, ZonalNodes: 6, RegionalNodes: 6"
  },
  {
  "resourceName": "ntSecondary"
  "resourceType": "Microsoft.Compute/virutalmachinescalesets"
  "isZoneResilient": true
  "details": "Status: Done, ZonalNodes: 6, RegionalNodes: 0"
  }
],
"isClusterZoneResilient": false
}
```
Примечание.

Процесс масштабирования для типа основного узла потребует дополнительного времени, так как каждое добавление или удаление узла инициирует обновление кластера Service Fabric.
Пометка кластера, устойчивого к сбоям зоны

Этот шаг помогает в будущих развертываниях, так как он гарантирует, что все будущие развертывания типов узлов охватывают зоны доступности и, таким образом, кластер остается устойчивым к сбоям AZ. В шаблоне ARM кластера задайте zonalResiliency: true и выполните развертывание, чтобы пометить кластер как устойчивый к зоне и убедиться, что все развертывания новых типов узлов находятся в зонах доступности. Это обновление допускается только в том случае, если все типы узлов имеют по крайней мере шесть зональных узлов и 0 региональных узлов.
```
{
  "apiVersion": "2022-02-01-preview",
  "type": "Microsoft.ServiceFabric/managedclusters",
  "zonalResiliency": "true"
}
```
Вы также можете увидеть обновленное состояние на портале в разделе "Обзор" —> Свойства, аналогичные Zonal resiliency Trueпосле завершения.

Проверка устойчивости всех ресурсов к зонам

Чтобы проверить состояние устойчивости зоны доступности для ресурсов управляемого кластера, используйте следующий вызов API GET:

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ServiceFabric/managedClusters/{clusterName}/getazresiliencystatus?api-version=2022-02-01-preview

Этот вызов API должен предоставить ответ, аналогичный следующему:

{
 "baseResourceStatus" :[
   {
   "resourceName": "sfmccluster1"
   "resourceType": "Microsoft.Storage/storageAccounts"
   "isZoneResilient": true
   },
   {
   "resourceName": "PublicIP-sfmccluster1"
   "resourceType": "Microsoft.Network/publicIPAddresses"
   "isZoneResilient": true
   },
   {
     "resourceName": "ntPrimary"
     "resourceType": "Microsoft.Compute/virutalmachinescalesets"
     "isZoneResilient": true
     "details": "Status: Done, ZonalNodes: 6, RegionalNodes: 0"
   },
   {
     "resourceName": "ntSecondary"
     "resourceType": "Microsoft.Compute/virutalmachinescalesets"
     "isZoneResilient": true
     "details": "Status: Done, ZonalNodes: 6, RegionalNodes: 0"
   }
 ],
 "isClusterZoneResilient": true
}

Если вы работаете с любыми проблемами, обратитесь к поддержке по оказанию помощи.

Включение FastZonalUpdate в управляемых кластерах Service Fabric (предварительная версия)

Управляемые кластеры Service Fabric поддерживают более быстрые обновления кластера и приложений, уменьшая максимальное количество доменов обновления для каждой зоны доступности. Конфигурация по умолчанию теперь может иметь не более 15 доменов обновления (UD) в нескольких типах узлов AZ. Это огромное количество UD снизило скорость обновления. Новая конфигурация уменьшает максимальное количество идентификаторов, что приводит к более быстрым обновлениям, что позволяет обеспечить безопасность обновлений без изменений.

Обновление должно выполняться с помощью шаблона ARM, задав для свойства zonalUpdateMode значение fast, а затем изменив атрибут типа узла, например добавление узла, а затем удаление узла в каждом типе узла (см. необходимые шаги 2 и 3). Api ресурсов управляемого кластера Service Fabric должен иметь значение 2022-10-01-preview или более поздней версии.

Измените шаблон ARM с помощью нового свойства zonalUpdateMode.

   "resources": [
        {
            "type": "Microsoft.ServiceFabric/managedClusters",
            "apiVersion": "2022-10-01-preview",
            '''
            "properties": {
                '''
                "zonalResiliency": true,
                "zonalUpdateMode": "fast",
                ...
            }
        }]

Добавьте узел в кластер с помощью команды az sf cluster node.
Удалите узел из кластера с помощью команды az sf cluster node.

Share via

Развертывание управляемого кластера Service Fabric в зонах доступности

Топология устойчивого к зонам управляемого кластера Azure Service Fabric

Конфигурация сети

Включение устойчивого к зонам управляемого кластера Azure Service Fabric

Перенос существующего отказоустойчивого кластера незон в устойчивый к зоне (предварительная версия)

Включение FastZonalUpdate в управляемых кластерах Service Fabric (предварительная версия)

Дополнительные ресурсы