Поделиться через

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

  • Статья

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

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

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

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

Примечание.

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

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

Примечание.

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

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

Снимок экрана, на котором показан пример списка узлов с указанным форматом 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"
  }
}

Примечание.

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

Правила 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 категории "Стандартный"

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

Примечание.

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

Внимание

Для каждого типа узла в кластере Service Fabric, использующего балансировщик нагрузки SKU категории "Стандартный", требуется правило, разрешающее исходящий трафик через порт 443. Это необходимо для завершения настройки кластера. Любое развертывание без этого правила завершится сбоем.

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

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

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

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

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

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

  • Первое значение — свойство 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 должен быть по крайней мере один тип первичного узла. Уровень устойчивости для типов первичных узлов должен быть не ниже Silver.
  • Зона доступности, охватывающая масштабируемые наборы виртуальных машин, должна быть настроена по крайней мере для трех Зоны доступности, независимо от уровня устойчивости.
  • Зона доступности, охватывающий масштабируемый набор виртуальных машин с уровнем устойчивости Silver или более высокой устойчивости, должен иметь не менее 15 виртуальных машин (5 на регион).
  • Зона доступности, охватывающая масштабируемые наборы виртуальных машин с устойчивостью уровня Bronze, должны иметь по меньшей мере шесть виртуальных машин.

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

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

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

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

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

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

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

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

Внимание

Значением версии API для ресурса кластера Service Fabric должна быть версия "2020-12-01-preview" или более новая.

Версией кода кластера должна быть 8.1.321 или более новая.

{
  "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
      }
    ]
  }
}

Примечание.

  • Ресурсы общедоступного IP-адреса и подсистемы балансировки нагрузки должны использовать SKU категории "Стандартный", как описано выше в этой статье.
  • Свойство multipleAvailabilityZones для типа узла может быть определено только при создании типа узла и не может быть изменено позже. Имеющиеся типы узлов нельзя настроить с помощью этого свойства.
  • Если параметр sfZonalUpgradeMode опущен или имеет значение Hierarchical, развертывание кластера и приложений будет выполняться медленнее, так как в кластере больше доменов обновления. Важно правильно настроить время ожидания в политике обновления, чтобы учесть время обновления, требуемое для 15 доменов обновления. Необходимо обновить политику обновления как для приложения, так и для кластера, чтобы развертывание гарантировано не превысило предельное время развертывания службы ресурсов Azure в 12 часов. Это означает, что развертывание не должно занять более 12 часов для 15 доменов обновления (то есть должно длиться не более 40 минут для каждого домена обновления).
  • Установите для кластера уровень устойчивости Platinum, чтобы гарантировать устойчивость кластера к сценарию с выходом из строя одной зоны.
  • Обновление УстойчивыйLevel для типа узла с несколькими Зонами доступности не поддерживается. Создайте новый тип узла с более высокой устойчивостью.
  • SF поддерживает только 3 availabilityZones. Любое большее число сейчас не поддерживается.

Совет

Рекомендуется задавать для sfZonalUpgradeMode значение Hierarchical или опустить его. Развертывание будет соответствовать зональному распределению виртуальных машин и повлияет на меньший объем реплик или экземпляров, что делает их более безопасными. Используйте для параметра sfZonalUpgradeMode значение Parallel, если скорость развертывания является приоритетной или для типа узла с несколькими Зонами доступности выполняются только рабочие нагрузки без отслеживания состояния. Это приведет к тому, что во всех Зонах доступности обход доменов обновления будет выполняться параллельно.

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

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

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

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

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

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

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

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

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

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

Схема, на которой показана архитектура Зоны доступности 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')]"
    }
  ]
}

Миграция на Зоны доступности из кластера с помощью 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