Перенос кластера Service Fabric в поддержку зоны доступности

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

Вы можете перенести управляемые и неуправляемые кластеры. Оба рассматриваются в этой статье.

Для неуправляемых кластеров мы обсудим два различных сценария:

• Перенос кластера с подсистемой балансировки нагрузки SKU уровня "Стандартный" и ip-ресурсом. Эта конфигурация поддерживает зоны доступности без необходимости создавать новые ресурсы.
• Перенос кластера с помощью подсистемы балансировки нагрузки SKU уровня "Базовый" и IP-ресурса. Эта конфигурация не поддерживает зоны доступности и требует создания новых ресурсов.

Ознакомьтесь с соответствующими разделами в каждом заголовке для сценария кластера Service Fabric.

Примечание.

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

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

Необходимые компоненты

Управляемые кластеры Service Fabric

Нужно:

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

Рекомендация:

• Кластер должен быть ценовой категории "Стандартный".
• тип первичного узла должен содержать по меньшей мере девять узлов для обеспечения оптимальной устойчивости, и при этом поддерживать как минимум шесть;
• тип вторичного узла должен содержать по меньшей мере шесть узлов для обеспечения лучшей отказоустойчивости, и при этом поддерживать как минимум три.

Неуправляемые кластеры Service Fabric

Обязательный: N/A.

Рекомендация:

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

Существующий балансировщик нагрузки SKU уровня "Стандартный" и "IP-ресурс"

Предварительные требования для этого сценария отсутствуют, так как предполагается, что у вас есть существующие необходимые ресурсы.

Базовый балансировщик нагрузки SKU и IP-ресурс

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

Примечание.

Невозможно обновить существующие ресурсы с номера SKU уровня "Базовый" до номера SKU уровня "Стандартный", поэтому требуются новые ресурсы.

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

Управляемый кластер Service Fabric

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

Неуправляемый кластер Service Fabric

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

Миграция управляемых кластеров Service Fabric

Выполните действия, описанные в разделе "Миграция управляемого кластера Service Fabric" в устойчивый к зоне.

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

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

Когда использовать этот параметр

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

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

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

Перенос неуправляемого кластера Service Fabric с существующим балансировщиком нагрузки SKU уровня "Стандартный" и ресурсами IP-адресов

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

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

• Первое значение — 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 виртуальных машин.
• Зона доступности с масштабируемым набором виртуальных машин с устойчивостью Бронзовой машины должна иметь по крайней мере шесть виртуальных машин.

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

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

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

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

  • Если это значение равно 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-сети. Этот процесс уже описан в подразделе ниже для решения с одним типом узла на каждую Зону доступности.

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

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

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

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

Когда использовать этот параметр

Эта конфигурация общедоступна уже сейчас.

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

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

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

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

Перенос неуправляемого кластера Service Fabric с существующим балансировщиком нагрузки SKU уровня "Стандартный" и ресурсами IP-адресов

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

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

• Первое значение — 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')]"
    }
  ]
}

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

Вариант миграции: неуправляемый кластер Service Fabric с подсистемой балансировки нагрузки SKU уровня "Базовый" и ресурсами IP-адресов

Когда использовать этот параметр

Этот параметр следует использовать при наличии существующего неуправляемого кластера Service Fabric с подсистемой балансировки нагрузки базового номера SKU и ресурсами IP-адресов, которые требуется перенести. Если существующий неуправляемый кластер имеет ресурсы SKU уровня "Стандартный", вы увидите приведенные выше параметры миграции. Если вы еще не создали неуправляемый кластер, но знаете, что он будет включен в AZ, создайте его с ресурсами SKU уровня "Стандартный".

Перенос неуправляемого кластера Service Fabric с помощью подсистемы балансировки нагрузки SKU уровня "Базовый" и IP-ресурсов

Чтобы выполнить миграцию кластера, в котором использовались подсистема балансировки нагрузки и 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

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

Следующие шаги

• Увеличение масштаба неуправляемого типа основного узла кластера Service Fabric

• Добавление, удаление или масштабирование типов узлов управляемого кластера Service Fabric