Compartilhar via

Migrar o cluster do Service Fabric para o suporte à zona de disponibilidade

  • Artigo

Este guia descreve como migrar os clusters do Service Fabric do suporte à zona de não disponibilidade para o suporte à disponibilidade. Vamos apresentar as diferentes opções de migração. Um cluster do Service Fabric distribuído entre as zonas de disponibilidade garante alta disponibilidade do estado do cluster.

Você pode migrar os clusters gerenciados e não gerenciados. Ambos são abordados neste artigo.

Quanto aos clusters não gerenciados, discutiremos dois cenários diferentes:

  • Migrar um cluster com um balanceador de carga de SKU Standard e um recurso de IP. Essa configuração dá suporte às zonas de disponibilidade sem a necessidade de criar novos recursos.
  • Migrar um cluster com um balanceador de carga de SKU Básico e um recurso de IP. Essa configuração não dá suporte às zonas de disponibilidade e requer a criação de novos recursos.

Consulte as seções apropriadas em cada cabeçalho no cenário de cluster do Service Fabric.

Observação

O benefício de abranger o tipo de nó primário entre as zonas de disponibilidade é visto apenas em três zonas e não apenas duas. Isso é verdadeiro para os clusters gerenciados e não gerenciados.

Os modelos de exemplo estão disponíveis nos modelos de zona de disponibilidade cruzada do Service Fabric.

Pré-requisitos

Clusters gerenciados do Service Fabric

Necessário:

Recomendado:

  • A SKU do cluster deve ser Standard.
  • O tipo de nó primário deve ter pelo menos nove nós para obter a melhor resiliência, mas dá suporte ao número mínimo de seis.
  • Os tipos de nó secundários devem ter pelo menos seis nós para obter a melhor resiliência, mas dão suporte ao número mínimo de três.

Os clusters não gerenciados do Service Fabric

Obrigatório (N/D).

Recomendado:

  • O nível de confiabilidade do cluster definido como Platinum.
  • Um recurso único de IP público usando um SKU Standard
  • Um recurso único do balanceador de carga usando um SKU Standard
  • Um grupo de segurança de rede (NSG) referenciado pela sub-rede na qual você implanta seus Conjuntos de Dimensionamento de Máquinas Virtuais.

Balanceador de carga de SKU Standard existente e recurso de IP

Não há pré-requisitos para esse cenário, pois pressupõe que você tenha os recursos necessários existentes.

Balanceador de carga de SKU Básico e recurso de IP

  • Um novo balanceador de carga usando o SKU Standard, diferente do seu balanceador de carga de SKU Básico existente.
  • Um novo recurso de IP usando o SKU Standard, diferente do seu balanceador de carga de SKU Básico existente.

Observação

Não é possível atualizar seus recursos existentes de um SKU Básico para um SKU Standard, portanto, novos recursos são necessários.

Requisitos de tempo de inatividade

Cluster gerenciado do Service Fabric

A migração para uma configuração resiliente à zona pode causar uma breve perda de conectividade externa pelo balanceador de carga, mas não afetará a integridade do cluster. A perda de conectividade externa ocorre quando um novo IP público precisa ser criado para tornar a rede resiliente às falhas de zona. Planeje a migração adequadamente.

Cluster não gerenciado do Service Fabric

O tempo de inatividade para migrar os clusters não gerenciados do Service Fabric varia amplamente com base no número de VMs e Domínios de Atualização (UDs) no seu cluster. UDs são agrupamentos lógicos de VMs que determinam a ordem na qual as atualizações são enviadas por push para as VMs no seu cluster. O tempo de inatividade também é afetado pelo modo de atualização do cluster, o qual manipula como as tarefas de atualização dos UDs no seu cluster são processadas. A propriedade sfZonalUpgradeMode, que controla o modo de atualização, é abordada com mais detalhes nas seções a seguir.

Migração para os clusters gerenciados do Service Fabric

Siga as etapas em Migrar o cluster gerenciado do Service Fabric para uma zona resiliente.

Opções de migração para os clusters não gerenciados do Service Fabric

Opção de migração 1: habilitar várias Zonas de Disponibilidade em um único Conjunto de Dimensionamento de Máquinas Virtuais

Quando usar essa opção

Essa solução permite que os usuários incluam três Zonas de disponibilidade no mesmo tipo de nó. Essa é a topologia de implantação recomendada, pois permite que você implante entre as zonas de disponibilidade, mantendo um único Conjunto de Dimensionamento de Máquinas Virtuais.

Um modelo de exemplo está disponível no GitHub.

Você deve usar essa opção quando tiver um cluster não gerenciado do Service Fabric existente com o balanceador de carga de SKU Standard e os recursos de IP que você quer migrar. Se seu cluster não gerenciado existente tiver os recursos do SKU Básico, você deverá ver a opção de migração do SKU Básico abaixo.

Como migrar seu cluster não gerenciado do Service Fabric com recursos de IP e balanceador de carga de SKU Standard existentes

Para habilitar as zonas em um Conjunto de Dimensionamento de Máquinas Virtuais:

Inclua os três valores a seguir no recurso Conjunto de Dimensionamento de Máquinas Virtuais:

  • O primeiro valor é a propriedade zones, que especifica as Zonas de Disponibilidade que estão no Conjunto de Dimensionamento de Máquinas Virtuais.

  • O segundo valor é a propriedade singlePlacementGroup, que deve ser definida como true. O conjunto de dimensionamento que é distribuído em três Zonas de disponibilidade pode ser dimensionado para até 300 VMs, mesmo com singlePlacementGroup = true.

  • O terceiro valor é zoneBalance, que garante um balanceamento de zona rigoroso. Esse valor deve ser true. Isso garante que as distribuições de VM entre zonas não sejam desbalanceadas, o que significa que quando uma zona ficar inativa, as outras duas zonas terão VMs suficientes para manter o cluster em execução.

    Um cluster com uma distribuição de VM desbalanceada pode não sobreviver a um cenário de zona inativa, pois essa zona pode conter a maioria das VMs. A distribuição de VM desbalanceada entre zonas também resulta em problemas de posicionamento de serviço e suspensão de atualizações de infraestrutura. Leia mais sobre zoneBalancing.

Você não precisa configurar as substituições FaultDomain e UpgradeDomain.

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

Observação

  • Os clusters do Service Fabric precisam ter pelo menos um tipo de nó primário. O nível de durabilidade dos tipos de nós primários deve ser Silver ou superior.
  • Uma zona de disponibilidade que abrange o Conjunto de Dimensionamento de Máquinas Virtuais deve ser configurada com pelo menos três Zonas de Disponibilidade, independentemente do nível de durabilidade.
  • Uma zona de disponibilidade que abrange o Conjunto de Dimensionamento de Máquinas Virtuais com Durabilidade Silver ou superior deve ter pelo menos 15 VMs.
  • Uma zona de disponibilidade que abrange o Conjunto de Dimensionamento de Máquinas Virtuais com durabilidade Bronze deve ter pelo menos seis VMs.
Habilitar o suporte para várias zonas no tipo de nó do Service Fabric

Para dar suporte às várias zonas de disponibilidade, o tipo de nó do Service Fabric deve ser habilitado.

  • O primeiro valor é multipleAvailabilityZones, que deve ser definido como true para o tipo de nó.

  • O segundo valor é sfZonalUpgradeMode e é opcional. Essa propriedade não poderá ser modificada se um tipo de nó com várias zonas de disponibilidade já estiver presente no cluster. Essa propriedade controla o agrupamento lógico de VMs em UDs.

    • Se esse valor for definido como Parallel: as VMs sob o tipo de nó serão agrupadas em UDs e ignorarão as informações de zona em cinco UDs. Essa configuração faz com que os UDs em todas as zonas sejam atualizados ao mesmo tempo. Embora esse modo de implementação seja mais rápido para upgrades, não o recomendamos porque ele vai contra as diretrizes do SDP, que afirmam que as atualizações devem ser aplicadas a uma zona de cada vez.

    • Se esse valor for omitido ou definido como Hierarchical: as VMs serão agrupadas para refletir a distribuição em zona em até 15 UDs. Cada uma das três zonas tem cinco UDs. Isso garante que as zonas sejam atualizadas uma de cada vez, mudando para a próxima zona somente depois de concluir cinco UDs dentro da primeira zona. O processo de atualização é mais seguro para o cluster e o aplicativo de usuário.

    Essa propriedade define apenas o comportamento de atualização para atualizações de aplicativo e código do Service Fabric. As atualizações subjacentes do Conjunto de Dimensionamento de Máquinas Virtuais ainda são paralelas em todas as Zonas de Disponibilidade. Essa propriedade não afeta a distribuição de UD para tipos de nó que não têm várias zonas habilitadas.

  • O terceiro valor é vmssZonalUpgradeMode, é opcional e pode ser atualizado a qualquer momento. Essa propriedade define o esquema de atualização para que o Conjunto de Dimensionamento de Máquinas Virtuais ocorra em paralelo ou sequencialmente entre as Zonas de Disponibilidade.

    • Se esse valor foi definido como Parallel: todas as atualizações do conjunto de dimensionamento ocorrem em paralelo em todas as zonas. Esse modo de implementação é mais rápido para as atualizações e, portanto, não o recomendamos porque ele vai contra as diretrizes do SDP, que afirmam que as atualizações devem ser aplicadas a uma zona de cada vez.
    • Se esse valor foi omitido ou definido como Hierarchical: isso garante que as zonas sejam atualizadas uma de cada vez, mudando para a próxima zona somente depois de concluir cinco UDs dentro da primeira zona. Esse processo de atualização é mais seguro para o cluster e o aplicativo de usuário.

Importante

A versão da API do recurso de cluster do Service Fabric deve ser a versão prévia de 01-12-2020 ou superior.

A versão do código do cluster deve ser de pelo menos 8.1.321 ou posterior.

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

Observação

  • Os recursos de IP público e de balanceador de carga devem usar o SKU Standard descrito anteriormente neste artigo.
  • A propriedade multipleAvailabilityZones no tipo de nó só pode ser definida quando o tipo de nó é criado e não pode ser modificada posteriormente. Não é possível configurar os tipos de nó existentes com essa propriedade.
  • Quando sfZonalUpgradeMode for omitida ou definida como Hierarchical, as implantações de cluster e aplicativo serão mais lentas, pois haverá mais domínios de atualização no cluster. É importante ajustar corretamente os tempos limite da política de atualização para considerar o tempo de atualização necessário para 15 domínios de atualização. A política de atualização para o aplicativo e o cluster deve ser atualizada para garantir que a implantação não exceda o limite de tempo de implantação do serviço de recursos do Azure de 12 horas. Isso significa que a implantação não deve levar mais de 12 horas para 15 UDs (ou seja, não deve levar mais de 40 minutos para cada UD).
  • Defina o nível de confiabilidade do cluster como Platinum para garantir que o cluster sobreviva ao cenário de uma zona inativa.
  • Não há suporte para fazer upgrade do DurabilityLevel para um nodetype com multipleAvailabilityZones. Em vez disso, crie um novo tipo de nó com maior durabilidade.
  • O SF dá suporte a apenas 3 AvailabilityZones. Não há suporte para um número maior no momento.

Dica

É recomendável definir sfZonalUpgradeMode como Hierarchical ou omiti-lo. A implantação seguirá a distribuição zonal de VMs e afetará uma quantidade menor de réplicas ou instâncias, tornando-as mais seguras. Use sfZonalUpgradeMode definido como Parallel se a velocidade de implantação for uma prioridade ou apenas as cargas de trabalho sem estado forem executadas no tipo de nó com várias Zonas de disponibilidade. Isso faz com que a UD ocorra em paralelo em todas as Zonas de disponibilidade.

Migrar para o tipo de nó com várias Zonas de disponibilidade

Para todos os cenários de migração, você precisa adicionar um novo tipo de nó que dê suporte a várias Zonas de disponibilidade. Um tipo de nó existente não pode ser migrado para dar suporte a várias zonas. O artigo Escalar verticalmente um tipo de nó primário do cluster do Service Fabric inclui etapas detalhadas para adicionar um novo tipo de nó e os outros recursos necessários para o novo tipo de nó, como os recursos de IP e de balanceador de carga. Esse artigo também descreve como desativar o tipo de nó existente depois que um novo tipo de nó com várias Zonas de disponibilidade é adicionado ao cluster.

  • Migração de um tipo de nó que usa o balanceador de carga básico e recursos de IP: esse processo já está descrito em uma subseção abaixo para a solução com um tipo de nó por Zona de disponibilidade.

    Quanto ao novo tipo de nó, a única diferença é que há apenas um conjunto de dimensionamento de máquina virtual e um tipo de nó para todas as zonas de disponibilidade, em vez de um por Zona de Disponibilidade.

  • Migração de um tipo de nó que usa o balanceador de carga de SKU Standard e os recursos de IP com um NSG: siga o mesmo procedimento descrito anteriormente. No entanto, não é necessário adicionar novos recursos de balanceador de carga, IP e NSG. Os mesmos recursos podem ser reutilizados no novo tipo de nó.

Se você tiver problemas, contate o suporte para obter assistência.

Opção de migração 2: implantar zonas fixando um Conjunto de Dimensionamento de Máquinas Virtuais em cada zona

Quando usar essa opção

Essa é a configuração geralmente disponível no momento.

Para abranger um cluster do Service Fabric entre Zonas de disponibilidade, você deve criar um tipo de nó primário em cada Zona de disponibilidade com suporte na região. Isso distribui os nós de semente uniformemente entre cada um dos tipos de nó primários.

A topologia recomendada para o tipo de nó primário requer isto:

  • Três tipos de nó marcados como primários
    • Cada tipo de nó deve ser mapeado no seu próprio Conjunto de Dimensionamento de Máquinas Virtuais localizado em uma zona diferente.
    • Cada Conjunto de Dimensionamento de Máquinas Virtuais deve ter pelo menos cinco nós (Durabilidade Prata).

Você deve usar essa opção quando tiver um cluster não gerenciado do Service Fabric existente com o balanceador de carga de SKU Standard e os recursos de IP que você quer migrar. Se seu cluster não gerenciado existente tiver os recursos do SKU Básico, você deverá ver a opção de migração do SKU Básico abaixo.

Como migrar seu cluster não gerenciado do Service Fabric com recursos de IP e balanceador de carga de SKU Standard existentes

Habilitar as zonas em um Conjunto de Dimensionamento de Máquinas Virtuais

Para habilitar uma zona em um Conjunto de Dimensionamento de Máquinas Virtuais, inclua os três seguintes valores no recurso Conjunto de Dimensionamento de Máquinas Virtuais:

  • O primeiro valor é a propriedade zones, que especifica em qual Zona de Disponibilidade o Conjunto de Dimensionamento de Máquinas Virtuais é implantado.
  • O segundo valor é a propriedade singlePlacementGroup, que deve ser definida como true.
  • O terceiro valor é a propriedade faultDomainOverride na extensão do Conjunto de Dimensionamento de Máquinas Virtuais do Service Fabric. Essa propriedade deve incluir apenas a zona na qual esse Conjunto de Dimensionamento de Máquinas Virtuais será colocado. Exemplo: "faultDomainOverride": "az1". Todos os recursos do Conjunto de Dimensionamento de Máquinas Virtuais devem ser colocados na mesma região porque os clusters do Azure Service Fabric não têm suporte entre regiões.
{
  "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"
          }
        }
      ]
    }
  }
}
Habilitar vários tipos de nó primários no recurso do cluster do Service Fabric

Para definir um ou mais tipos de nó como primários em um recurso de cluster, defina a propriedade isPrimary como true. Ao implantar um cluster do Service Fabric em Zonas de Disponibilidade, você deve ter três tipos de nó em zonas distintas.

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

Se você tiver problemas, contate o suporte para obter assistência.

Opção de migração: cluster não gerenciado do Service Fabric com o balanceador de carga de SKU Básico e recursos de IP

Quando usar essa opção

Você deve usar essa opção quando tiver um cluster não gerenciado do Service Fabric existente com o balanceador de carga de SKU Básico e os recursos de IP que você quer migrar. Se seu cluster não gerenciado existente tiver recursos de SKU Standard, você deverá ver as opções de migração acima. Se você ainda não criou seu cluster não gerenciado, mas sabe que quer que ele seja habilitado para AZ, crie-o com recursos de SKU Standard.

Como migrar seu cluster não gerenciado do Service Fabric com o balanceador de carga SKU Básico e os recursos de IP

Para migrar um cluster que está usando um balanceador de carga e um IP com um SKU Basic, você deve primeiro criar um recurso do balanceador de carga e de IP totalmente novo usando o SKU Standard. Não é possível atualizar esses recursos.

Referencie o novo balanceador de carga e o IP nos novos tipos de nó de Zona de disponibilidade cruzada que você deseja usar. No exemplo anterior, três novos recursos do Conjunto de Dimensionamento de Máquinas Virtuais foram adicionados nas zonas 1, 2 e 3. Esses Conjuntos de Dimensionamento de Máquinas Virtuais referenciam o balanceador de carga e o IP recém-criados, e são marcados como tipos de nó primários no recurso de cluster do Service Fabric.

  1. Para começar, adicione os novos recursos ao modelo do Azure Resource Manager existente. Esses recursos incluem:

    • Um recurso de IP público usando SKU Standard
    • Um recurso de balanceador de carga usando SKU Standard
    • Um NSG referenciado pela sub-rede na qual você implanta seus Conjuntos de Dimensionamento de Máquinas Virtuais
    • Três tipos de nó marcados como primários
      • Cada tipo de nó deve ser mapeado no seu próprio Conjunto de Dimensionamento de Máquinas Virtuais localizado em uma zona diferente.
      • Cada Conjunto de Dimensionamento de Máquinas Virtuais deve ter pelo menos cinco nós (Durabilidade Prata).

    Um exemplo desses recursos pode ser encontrado no modelo de exemplo.

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

  2. Quando os recursos concluírem a implantação, você poderá desabilitar os nós no tipo de nó primário do cluster original. Quando os nós são desabilitados, os serviços do sistema migram para o novo tipo de nó primário que você implantou anteriormente.

    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. Depois que todos os nós estiverem desabilitados, os serviços do sistema serão executados no tipo de nó primário, que é distribuído entre as zonas. Depois, você pode remover os nós desabilitados do cluster. Depois que os nós forem removidos, você poderá remover os recursos originais de IP, balanceador de carga e Conjunto de Dimensionamento de Máquinas Virtuais.

    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. Em seguida, você deve remover as referências a esses recursos do modelo do Resource Manager que você implantou.

  5. Por fim, atualize o nome DNS e o IP público.

$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

Se você tiver problemas, contate o suporte para obter assistência.

Próximas etapas