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

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

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

Примеры шаблонов приведены на странице Шаблоны Service Fabric для разных Зон доступности.

Топология для распределения типов первичных узлов по Зонам доступности

• Уровень надежности кластера Platinum
• Один ресурс общедоступного IP-адреса с использованием SKU категории "Стандартный"
• Один ресурс общедоступного балансировщика нагрузки с использованием SKU категории "Стандартный"
• Группа безопасности сети (NSG), на которую ссылается подсеть, где развертываются масштабируемые наборы виртуальных машин

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

Распределение реплик службы между зонами

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

Конфигурация реплики службы пользователя

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

Значение ReliabilityLevel для кластера

Это значение определяет количество начальных узлов в кластере и размер реплики системных служб. Настройка с несколькими Зонами доступности охватывает большее количество узлов, распределенных между зонами для обеспечения устойчивости зоны.

Более высокое значение ReliabilityLevel гарантирует наличие большего числа начальных узлов и реплик системной службы, а также равномерное распределение между зонами, поэтому при сбое зоны кластер и системные службы не затрагиваются. Рекомендуется задать значение ReliabilityLevel = Platinum, которое гарантирует, что в каждой зоне размещаются девять начальных узлов, которые распределяются между зонами в кластере.

Сценарий выхода зоны из строя

Когда зона выходит из строя, все ее узлы и реплики служб отображаются в неработоспособном состоянии. Так как в других зонах есть реплики, служба продолжит отвечать на запросы. Выполняется отработка отказа с первичных реплик на работающие зоны. Службы отображаются в состоянии с предупреждением, так как количество целевых реплик еще не достигнуто, а число виртуальных машин по-прежнему превышает минимальный размер целевой реплики.

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

Будущие оптимизации

• Чтобы обеспечить надежность обновлений инфраструктуры, Service Fabric требует, чтобы уровень устойчивости масштабируемого набора виртуальных машин был не менее чем Silver. Это позволяет базовому масштабируемому набору виртуальных машин и среде выполнения Service Fabric предоставлять надежные обновления. Для этого также требуется, чтобы каждая зона имела не менее 5 виртуальных машин. Мы работаем над тем, чтобы снизить это требование до 3 и 2 виртуальным машинам на каждую зону для первичного и всех не первичных типов узлов соответственно.
• Все перечисленные ниже конфигурации и предстоящая работа обеспечивают миграцию на месте для клиентов, где один и тот же кластер можно обновить для использования новой конфигурации путем добавления новых типов nodeType и прекращения использования старых.

Требования к сети

Ресурс общедоступного IP-адреса и службы Load Balancer

Чтобы включить свойство zones в ресурсе масштабируемого набора виртуальных машин, как подсистема балансировки нагрузки, так и ресурс IP, на которые ссылается этот масштабируемый набор виртуальных машин, должны использовать номер SKU категории "Стандартный". При создании подсистемы балансировки нагрузки или ресурса IP-адреса без свойства SKU создается SKU категории "Базовый", который не поддерживает Зоны доступности. Подсистема балансировки нагрузки для SKU категории "Стандартный" блокирует весь трафик извне по умолчанию. Чтобы разрешить внешний трафик, разверните NSG в подсети.

{
  "apiVersion": "2018-11-01",
  "type": "Microsoft.Network/publicIPAddresses",
  "name": "[concat('LB','-', parameters('clusterName')]",
  "location": "[parameters('computeLocation')]",
  "sku": {
    "name": "Standard"
  }
}

{
  "apiVersion": "2018-11-01",
  "type": "Microsoft.Network/loadBalancers",
  "name": "[concat('LB','-', parameters('clusterName')]",
  "location": "[parameters('computeLocation')]",
  "dependsOn": [
    "[concat('Microsoft.Network/networkSecurityGroups/', concat('nsg', parameters('subnet0Name')))]"
  ],
  "properties": {
    "addressSpace": {
      "addressPrefixes": [
        "[parameters('addressPrefix')]"
      ]
    },
    "subnets": [
      {
        "name": "[parameters('subnet0Name')]",
        "properties": {
          "addressPrefix": "[parameters('subnet0Prefix')]",
          "networkSecurityGroup": {
            "id": "[resourceId('Microsoft.Network/networkSecurityGroups', concat('nsg', parameters('subnet0Name')))]"
          }
        }
      }
    ]
  },
  "sku": {
    "name": "Standard"
  }
}

Правила NAT для масштабируемых наборов виртуальных машин

Правила преобразования сетевых адресов (NAT) для входящего трафика подсистемы балансировки нагрузки должны соответствовать пулам NAT из масштабируемого набора виртуальных машин. Каждый масштабируемый набор виртуальных машин должен иметь уникальный пул NAT для входящего трафика.

{
  "inboundNatPools": [
    {
      "name": "LoadBalancerBEAddressNatPool0",
      "properties": {
        "backendPort": "3389",
        "frontendIPConfiguration": {
          "id": "[variables('lbIPConfig0')]"
        },
        "frontendPortRangeEnd": "50999",
        "frontendPortRangeStart": "50000",
        "protocol": "tcp"
      }
    },
    {
      "name": "LoadBalancerBEAddressNatPool1",
      "properties": {
        "backendPort": "3389",
        "frontendIPConfiguration": {
          "id": "[variables('lbIPConfig0')]"
        },
        "frontendPortRangeEnd": "51999",
        "frontendPortRangeStart": "51000",
        "protocol": "tcp"
      }
    },
    {
      "name": "LoadBalancerBEAddressNatPool2",
      "properties": {
        "backendPort": "3389",
        "frontendIPConfiguration": {
          "id": "[variables('lbIPConfig0')]"
        },
        "frontendPortRangeEnd": "52999",
        "frontendPortRangeStart": "52000",
        "protocol": "tcp"
      }
    }
  ]
}

Правила для исходящего трафика подсистемы балансировки нагрузки со SKU категории "Стандартный"

Подсистема балансировки нагрузки со SKU категории "Стандартный" и общедоступный IP-адрес категории "Стандартный" имеют новые возможности и различные расширения функциональности для исходящего подключения по сравнению с SKU категории "Базовый". Если вам требуется исходящее подключение при работе с номерами SKU категории "Стандартный", вы должны явно определить это подключение с использованием общедоступных IP-адресов SKU категории "Стандартный" или общедоступной подсистемы балансировки нагрузки SKU категории "Стандартный". Дополнительные сведения см. в статьях Исходящие подключения и Что такое Azure Load Balancer.

1. Включение нескольких Зон доступности в одном масштабируемом наборе виртуальных машин

Это решение позволяет пользователям распространить три Зоны доступности на узлы одного типа. Это рекомендуемая топология развертывания, так как она позволяет осуществлять развертывание в разных зонах доступности, сохраняя при этом один масштабируемый набор виртуальных машин.

Пример шаблона доступен на сайте GitHub.

Настройка зон в масштабируемом наборе виртуальных машин

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

• Первое значение — свойство zones, которое указывает Зоны доступности, присутствующие в масштабируемом наборе виртуальных машин.

• Второе значение — это свойство singlePlacementGroup, для которого необходимо задать значение true. Масштабируемый набор, который распространяется на три Зоны доступности, может масштабироваться до 300 виртуальных машин даже при singlePlacementGroup = true.

• Третье значение — zoneBalance, которое обеспечивает строгую балансировку зон. Это значение должно быть равно true. Это гарантирует, что распределение виртуальных машин между зонами не будет несбалансированным. Таким образом, при выходе из строя одной зоны другие две зоны будут иметь достаточно виртуальных машин, чтобы поддержать работу кластера.

  Кластер с несбалансированным распределением виртуальных машин может не выдержать выхода зоны из строя, так как в этой зоне может располагаться большинство виртуальных машин. Несбалансированное распределение виртуальных машин между зонами также приводит к возникновению проблем с размещением служб и обновлениями инфраструктуры. См дополнительные сведения о возможностях zoneBalancing.

Нет необходимости настраивать переопределения FaultDomain и UpgradeDomain.

{
  "apiVersion": "2018-10-01",
  "type": "Microsoft.Compute/virtualMachineScaleSets",
  "name": "[parameters('vmNodeType1Name')]",
  "location": "[parameters('computeLocation')]",
  "zones": [ "1", "2", "3" ],
  "properties": {
    "singlePlacementGroup": true,
    "zoneBalance": true
  }
}

Включение поддержки нескольких зон для типа узла Service Fabric

Для поддержки нескольких Зон доступности необходимо включить тип узла Service Fabric.

• Первое значение — multipleAvailabilityZones, для которого должно быть задано значение true для типа узла.

• Второе значение — sfZonalUpgradeMode, оно необязательное. Это свойство нельзя изменить, если тип узла с несколькими Зонами доступности уже присутствует в кластере. Это свойство управляет логическим группированием виртуальных машин в доменах обновления.

  • Если это значение равно Parallel, виртуальные машины для типа узла группируются в домены обновления и игнорируют сведения о зоне в пяти доменах обновления. Этот параметр приводит к одновременному обновлению доменов обновления для всех зон. Такой режим развертывания ускоряет обновление, но мы его не рекомендуем, так как противоречит рекомендациям SDP, предписывающим применять обновления только к зонам по одной за раз.
  • Если значение опущено или задано как Hierarchical, виртуальные машины будут сгруппированы в соответствии с зональным распределением в доменах обновления количеством до 15. Каждая из трех зон имеет пять доменов обновления. Это гарантирует, что зоны обновляются по одной за раз, а переход к следующей зоне осуществляется только после завершения для пяти доменов обновления в первой зоне. Этот процесс обновления более безопасен для кластера и пользовательского приложения.

  Это свойство определяет только способ обновления приложения Service Fabric и применения обновлений кода. Базовые обновления масштабируемого набора виртуальных машин по-прежнему выполняются параллельно во всех Зонах доступности. Это свойство не влияет на распределение доменов обновления для типов узлов, для которых не включена поддержка нескольких зон.

• Третье значение — vmssZonalUpgradeMode, является необязательным, его можно обновить в любое время. Это свойство определяет схему обновления для масштабируемого набора виртуальных машин, выполняемых параллельно или последовательно во всех Зонах доступности.

  • Если это значение равно Parallel: все обновления масштабируемого набора происходят параллельно во всех зонах. Такой режим развертывания ускоряет обновление, но мы его не рекомендуем, так как противоречит рекомендациям SDP, предписывающим применять обновления только к зонам по одной за раз.
  • Если значение опущено или задано как Hierarchical: это гарантирует, что зоны обновляются по одной за раз, а переход к следующей зоне осуществляется только после завершения для пяти доменов обновления в первой зоне. Этот процесс обновления более безопасен для кластера и пользовательского приложения.

{
  "apiVersion": "2020-12-01-preview",
  "type": "Microsoft.ServiceFabric/clusters",
  "name": "[parameters('clusterName')]",
  "location": "[parameters('clusterLocation')]",
  "dependsOn": [
    "[concat('Microsoft.Storage/storageAccounts/', parameters('supportLogStorageAccountName'))]"
  ],
  "properties": {
    "reliabilityLevel": "Platinum",
    "sfZonalUpgradeMode": "Hierarchical",
    "vmssZonalUpgradeMode": "Parallel",
    "nodeTypes": [
      {
        "name": "[parameters('vmNodeType0Name')]",
        "multipleAvailabilityZones": true
      }
    ]
  }
}

Миграция на тип узла с несколькими Зонами доступности

Для всех сценариев миграции необходимо добавить новый тип узла, поддерживающий несколько Зон доступности. Существующий тип узла нельзя перевести на поддержку нескольких зон. В статье Масштабирование типа первичного узла кластера Service Fabric содержатся подробные инструкции по добавлению нового типа узла и других ресурсов, необходимых для нового типа узла, например ресурсов IP-сети и подсистемы балансировки нагрузки. В этой же статье описывается, как прекратить использование имеющегося типа узла после добавления в кластер типа узла с несколькими Зонами доступности.

• Миграция с типа узла, использующего базовую подсистему балансировки нагрузки и ресурсы IP-сети. Этот процесс уже описан в подразделе ниже для решения с одним типом узла на каждую Зону доступности.

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

• Миграция с типа узла, который применяет группу безопасности сети для использования подсистемы балансировки нагрузки со SKU уровня "Стандартный" и ресурсов IP-сети. Выполните ту же процедуру, которая описана выше. Однако нет необходимости добавлять новые подсистемы балансировки нагрузки, а также ресурсы IP-сети и NSG. Те же ресурсы можно повторно использовать в новом типе узла.

2. Развертывание зон путем закрепления одного масштабируемого набора виртуальных машин в каждой зоне

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

Для топологии, рекомендуемой для основного типа узла, требуется следующее:

• Три типа узлов, помеченные как первичные
  • Каждый тип узла должен быть сопоставлен с собственным масштабируемым набором виртуальных машин, расположенным в другой зоне.
  • Каждый масштабируемый набор виртуальных машин должен иметь по крайней мере пять узлов (уровень устойчивости Silver).

На следующей схеме показана архитектура Зоны доступности Azure Service Fabric.

Включение зон в масштабируемом наборе виртуальных машин

Чтобы включить зону, в масштабируемом наборе виртуальных машин, добавьте следующие три значения в ресурс масштабируемого набора виртуальных машин.

• Первое значение — свойство zones, которое указывает, в какой зоне доступности развертывается масштабируемый набор виртуальных машин.
• Второе значение — это свойство singlePlacementGroup, для которого необходимо задать значение true.
• Третье значение — свойство faultDomainOverride в расширении масштабируемого набора виртуальных машин для Service Fabric. Это свойство должно включать в себя только зону, в которой будет размещен этот масштабируемый набор виртуальных машин. Пример: "faultDomainOverride": "az1". Все ресурсы масштабируемого набора виртуальных машин должны быть помещены в один и тот же регион, так как кластеры Azure Service Fabric не поддерживают работу в нескольких регионах.

{
  "apiVersion": "2018-10-01",
  "type": "Microsoft.Compute/virtualMachineScaleSets",
  "name": "[parameters('vmNodeType1Name')]",
  "location": "[parameters('computeLocation')]",
  "zones": [
    "1"
  ],
  "properties": {
    "singlePlacementGroup": true
  },
  "virtualMachineProfile": {
    "extensionProfile": {
      "extensions": [
        {
          "name": "[concat(parameters('vmNodeType1Name'),'_ServiceFabricNode')]",
          "properties": {
            "type": "ServiceFabricNode",
            "autoUpgradeMinorVersion": false,
            "publisher": "Microsoft.Azure.ServiceFabric",
            "settings": {
              "clusterEndpoint": "[reference(parameters('clusterName')).clusterEndpoint]",
              "nodeTypeRef": "[parameters('vmNodeType1Name')]",
              "dataPath": "D:\\\\SvcFab",
              "durabilityLevel": "Silver",
              "certificate": {
                "thumbprint": "[parameters('certificateThumbprint')]",
                "x509StoreName": "[parameters('certificateStoreValue')]"
              },
              "systemLogUploadSettings": {
                "Enabled": true
              },
              "faultDomainOverride": "az1"
            },
            "typeHandlerVersion": "1.0"
          }
        }
      ]
    }
  }
}

Включение нескольких основных типов узлов в ресурсе кластера Service Fabric

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

{
  "reliabilityLevel": "Platinum",
  "nodeTypes": [
    {
      "name": "[parameters('vmNodeType0Name')]",
      "applicationPorts": {
        "endPort": "[parameters('nt0applicationEndPort')]",
        "startPort": "[parameters('nt0applicationStartPort')]"
      },
      "clientConnectionEndpointPort": "[parameters('nt0fabricTcpGatewayPort')]",
      "durabilityLevel": "Silver",
      "ephemeralPorts": {
        "endPort": "[parameters('nt0ephemeralEndPort')]",
        "startPort": "[parameters('nt0ephemeralStartPort')]"
      },
      "httpGatewayEndpointPort": "[parameters('nt0fabricHttpGatewayPort')]",
      "isPrimary": true,
      "vmInstanceCount": "[parameters('nt0InstanceCount')]"
    },
    {
      "name": "[parameters('vmNodeType1Name')]",
      "applicationPorts": {
        "endPort": "[parameters('nt1applicationEndPort')]",
        "startPort": "[parameters('nt1applicationStartPort')]"
      },
      "clientConnectionEndpointPort": "[parameters('nt1fabricTcpGatewayPort')]",
      "durabilityLevel": "Silver",
      "ephemeralPorts": {
        "endPort": "[parameters('nt1ephemeralEndPort')]",
        "startPort": "[parameters('nt1ephemeralStartPort')]"
      },
      "httpGatewayEndpointPort": "[parameters('nt1fabricHttpGatewayPort')]",
      "isPrimary": true,
      "vmInstanceCount": "[parameters('nt1InstanceCount')]"
    },
    {
      "name": "[parameters('vmNodeType2Name')]",
      "applicationPorts": {
        "endPort": "[parameters('nt2applicationEndPort')]",
        "startPort": "[parameters('nt2applicationStartPort')]"
      },
      "clientConnectionEndpointPort": "[parameters('nt2fabricTcpGatewayPort')]",
      "durabilityLevel": "Silver",
      "ephemeralPorts": {
        "endPort": "[parameters('nt2ephemeralEndPort')]",
        "startPort": "[parameters('nt2ephemeralStartPort')]"
      },
      "httpGatewayEndpointPort": "[parameters('nt2fabricHttpGatewayPort')]",
      "isPrimary": true,
      "vmInstanceCount": "[parameters('nt2InstanceCount')]"
    }
  ]
}

Переход на Зоны доступности из кластера с использованием подсистемы балансировки нагрузки со SKU категории "Базовый" и IP-адресом со SKU категории "Базовый"

Чтобы выполнить миграцию кластера, в котором использовались подсистема балансировки нагрузки и IP-адресом со SKU категории "Базовый", сначала необходимо создать полностью новый ресурс подсистемы балансировки нагрузки и IP-сети, используя SKU категории "Стандартный". Обновить эти ресурсы невозможно.

Укажите новую подсистему балансировки нагрузки и IP-адрес в новых типах узлов с несколькими Зонами доступности, которые вы хотите использовать. В приведенном выше примере добавлены три новых ресурса масштабируемых наборов виртуальных машин в зонах 1, 2 и 3. Эти масштабируемые наборы виртуальных машин ссылаются на только что созданную подсистему балансировки нагрузки и IP-адрес и помечены как основные типы узлов в ресурсе кластера Service Fabric.

1. Для начала добавьте новые ресурсы в имеющийся шаблон Azure Resource Manager. К этим ресурсам относятся:

   • Ресурс общедоступного IP-адреса с использованием SKU категории "Стандартный"
   • Ресурс подсистемы балансировки нагрузки с использованием SKU категории "Стандартный"
   • Группа безопасности сети, на которую ссылается подсеть, где развертываются масштабируемые наборы виртуальных машин
   • Три типа узлов, помеченные как первичные
     • Каждый тип узла должен быть сопоставлен с собственным масштабируемым набором виртуальных машин, расположенным в другой зоне.
     • Каждый масштабируемый набор виртуальных машин должен иметь по крайней мере пять узлов (уровень устойчивости Silver).

   Пример этих ресурсов можно найти в образце шаблона.

   New-AzureRmResourceGroupDeployment `
       -ResourceGroupName $ResourceGroupName `
       -TemplateFile $Template `
       -TemplateParameterFile $Parameters
   

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

   Connect-ServiceFabricCluster -ConnectionEndpoint $ClusterName `
       -KeepAliveIntervalInSec 10 `
       -X509Credential `
       -ServerCertThumbprint $thumb  `
       -FindType FindByThumbprint `
       -FindValue $thumb `
       -StoreLocation CurrentUser `
       -StoreName My 
   
   Write-Host "Connected to cluster"
   
   $nodeNames = @("_nt0_0", "_nt0_1", "_nt0_2", "_nt0_3", "_nt0_4")
   
   Write-Host "Disabling nodes..."
   foreach($name in $nodeNames) {
       Disable-ServiceFabricNode -NodeName $name -Intent RemoveNode -Force
   }
   

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

   foreach($name in $nodeNames){
       # Remove the node from the cluster
       Remove-ServiceFabricNodeState -NodeName $name -TimeoutSec 300 -Force
       Write-Host "Removed node state for node $name"
   }
   
   $scaleSetName="nt0"
   Remove-AzureRmVmss -ResourceGroupName $groupname -VMScaleSetName $scaleSetName -Force
   
   $lbname="LB-cluster-nt0"
   $oldPublicIpName="LBIP-cluster-0"
   $newPublicIpName="LBIP-cluster-1"
   
   Remove-AzureRmLoadBalancer -Name $lbname -ResourceGroupName $groupname -Force
   Remove-AzureRmPublicIpAddress -Name $oldPublicIpName -ResourceGroupName $groupname -Force
   

4. Затем следует удалить ссылки на эти ресурсы из развернутого шаблона Resource Manager.

5. Наконец, обновите DNS-имя и общедоступный IP-адрес.

$oldprimaryPublicIP = Get-AzureRmPublicIpAddress -Name $oldPublicIpName  -ResourceGroupName $groupname
$primaryDNSName = $oldprimaryPublicIP.DnsSettings.DomainNameLabel
$primaryDNSFqdn = $oldprimaryPublicIP.DnsSettings.Fqdn

Remove-AzureRmLoadBalancer -Name $lbname -ResourceGroupName $groupname -Force
Remove-AzureRmPublicIpAddress -Name $oldPublicIpName -ResourceGroupName $groupname -Force

$PublicIP = Get-AzureRmPublicIpAddress -Name $newPublicIpName  -ResourceGroupName $groupname
$PublicIP.DnsSettings.DomainNameLabel = $primaryDNSName
$PublicIP.DnsSettings.Fqdn = $primaryDNSFqdn
Set-AzureRmPublicIpAddress -PublicIpAddress $PublicIP