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

  • Artigo

Este guia descreve como migrar clusters do Service Fabric do suporte de zona de indisponibilidade para o suporte de disponibilidade. Vamos guiá-lo através das diferentes opções de migração. Um cluster do Service Fabric distribuído entre zonas de disponibilidade garante alta disponibilidade do estado do cluster.

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

Para clusters não gerenciados, discutimos dois cenários diferentes:

  • Migração de um cluster com um balanceador de carga SKU padrão e um recurso IP. Essa configuração suporta zonas de disponibilidade sem a necessidade de criar novos recursos.
  • Migração de um cluster com um balanceador de carga SKU básico e um recurso IP. Esta configuração não suporta zonas de disponibilidade e requer a criação de novos recursos.

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

Nota

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

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

Pré-requisitos

Clusters geridos do Service Fabric

Necessários:

Recomendado:

  • A SKU do cluster deve ser Padrão.
  • O tipo de nó primário deve ter pelo menos nove nós para melhor resiliência, mas suporta o número mínimo de seis.
  • O(s) tipo(s) de nó(s) secundário(s) deve(m) ter pelo menos seis nós para melhor resiliência, mas suporta um número mínimo de três.

Clusters não gerenciados do Service Fabric

Obrigatório: N/A.

Recomendado:

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

Balanceador de carga SKU padrão existente e recurso IP

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

Balanceador de carga SKU básico e recurso IP

  • Um novo balanceador de carga usando o SKU padrão, distinto do seu balanceador de carga Basic SKU existente.
  • Um novo recurso IP usando o SKU padrão, distinto do seu recurso IP SKU básico existente.

Nota

Não é possível atualizar seus recursos existentes de uma SKU básica para uma SKU padrão, 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 de zona pode causar uma breve perda de conectividade externa por meio do 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 a falhas de zona. Planeje a migração de acordo.

Cluster não gerenciado do Service Fabric

O tempo de inatividade para migrar clusters não gerenciados do Service Fabric varia amplamente com base no número de VMs e Domínios de Atualização (UDs) em 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 em seu cluster. O tempo de inatividade também é afetado pelo modo de atualização do cluster, que lida com a forma como as tarefas de atualização para as UDs no cluster são processadas. A sfZonalUpgradeMode propriedade, que controla o modo de atualização, é abordada com mais detalhes nas seções a seguir.

Migração para clusters gerenciados do Service Fabric

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

Opções de migração para 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áquina virtual

Quando usar esta opção

Essa solução permite que os usuários abranjam três zonas de disponibilidade no mesmo tipo de nó. Essa é a topologia de implantação recomendada, pois permite implantar em zonas de disponibilidade enquanto mantém um único Conjunto de Dimensionamento de Máquina Virtual.

Um modelo de exemplo completo 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 SKU padrão e os recursos IP que deseja migrar. Se o cluster não gerenciado existente tiver recursos de SKU básicos, você verá a opção de migração de SKU básica abaixo.

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

Para habilitar zonas em um Conjunto de Dimensionamento de Máquina Virtual:

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

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

  • O segundo valor é a singlePlacementGroup propriedade, que deve ser definida como true. O conjunto de escalas que abrange três zonas de disponibilidade pode ser dimensionado para até 300 VMs, mesmo com singlePlacementGroup = true.

  • O terceiro valor é zoneBalance, que garante um equilíbrio de zona rigoroso. Este valor deve ser true. Isso garante que as distribuições de VM entre zonas não sejam desequilibradas, o que significa que, quando uma zona fica inativa, as outras duas zonas têm VMs suficientes para manter o cluster em execução.

    Um cluster com uma distribuição de VM desequilibrada pode não sobreviver a um cenário de zone-down porque essa zona pode ter a maioria das VMs. A distribuição desequilibrada de VM entre zonas também leva a problemas de posicionamento de serviço e atualizações de infraestrutura ficando presas. Leia mais sobre zoneBalancing.

Não é necessário configurar o FaultDomain e UpgradeDomain substitui.

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

Nota

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

Para oferecer suporte a 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 pode ser modificada se um tipo de nó com várias zonas de disponibilidade já estiver presente no cluster. Esta propriedade controla o agrupamento lógico de VMs em UDs.

    • Se esse valor for definido como Parallel: As VMs sob o tipo de nó são agrupadas em UDs e ignoram as informações da zona em cinco UDs. Essa configuração faz com que UDs em todas as zonas sejam atualizadas ao mesmo tempo. Embora esse modo de implantação seja mais rápido para atualizações, não o recomendamos porque 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 zonal em até 15 UDs. Cada uma das três zonas tem cinco UDs. Isso garante que as zonas sejam atualizadas uma de cada vez, movendo-se para a próxima zona somente depois de completar cinco UDs dentro da primeira zona. O processo de atualização é mais seguro para o cluster e o aplicativo do usuário.

    Essa propriedade define apenas o comportamento de atualização para atualizações de código e aplicativo do Service Fabric. As atualizações subjacentes do Conjunto de Dimensionamento de Máquina Virtual ainda são paralelas em todas as Zonas de Disponibilidade. Essa propriedade não afeta a distribuição 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. Esta propriedade define o esquema de atualização para que o Conjunto de Dimensionamento de Máquina Virtual aconteça em paralelo ou sequencialmente nas Zonas de Disponibilidade.

    • Se este valor estiver definido como Parallel: Todas as atualizações do conjunto de escalas acontecem em paralelo em todas as zonas. Esse modo de implantação é mais rápido para atualizações e, portanto, não o recomendamos porque vai contra as diretrizes 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: Isso garante que as zonas sejam atualizadas uma de cada vez, movendo-se 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 do usuário.

Importante

A versão da API de recursos de cluster do Service Fabric deve ser 2020-12-01-preview ou posterior.

A versão do código do cluster deve ser 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
      }
    ]
  }
}

Nota

  • Os recursos de IP público e balanceador de carga devem usar a SKU padrão descrita anteriormente no artigo.
  • A multipleAvailabilityZones propriedade no tipo de nó só pode ser definida quando o tipo de nó é criado e não pode ser modificada posteriormente. Os tipos de nó existentes não podem ser configurados com essa propriedade.
  • Quando sfZonalUpgradeMode for omitido ou definido como Hierarchical, as implantações de cluster e aplicativo serão mais lentas porque há mais domínios de atualização no cluster. É importante ajustar corretamente os tempos limite da política de atualização para levar em conta 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 para Platinum garantir que o cluster sobreviva ao cenário de uma zona para baixo.
  • Não há suporte para a atualização do DurabilityLevel para um tipo de nó com multipleAvailabilityZones. Em vez disso, crie um novo tipo de nó com maior durabilidade.
  • SF suporta apenas 3 AvailabilityZones. Qualquer número maior não é suportado no momento.

Gorjeta

Recomendamos configurá-lo sfZonalUpgradeMode ou Hierarchical 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 cargas de trabalho sem monitoração de estado forem executadas no tipo de nó com várias zonas de disponibilidade. Isso faz com que a caminhada UD aconteça 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 ofereça suporte a várias zonas de disponibilidade. Um tipo de nó existente não pode ser migrado para suportar várias zonas. O artigo Escalar um tipo de nó primário de cluster do Service Fabric inclui etapas detalhadas para adicionar um novo tipo de nó e outros recursos necessários para o novo tipo de nó, como recursos IP e 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 balanceador de carga básico e recursos IP: esse processo já está descrito em uma subseção abaixo para a solução com um tipo de nó por zona de disponibilidade.

    Para o novo tipo de nó, a única diferença é que há apenas um Conjunto de Escala 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 SKU padrão e recursos IP com um NSG: Siga o mesmo procedimento descrito anteriormente. No entanto, não há necessidade de adicionar novos recursos de balanceador de carga, IP e NSG. Os mesmos recursos podem ser reutilizados no novo tipo de nó.

Se tiver algum problema, contacte o suporte para obter assistência.

Opção de migração 2: implantar zonas fixando um conjunto de escala de máquina virtual em cada zona

Quando usar esta opção

Esta é 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 suportada pela região. Isso distribui os nós de propagação uniformemente em cada um dos tipos de nós primários.

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

  • Três tipos de nós marcados como primários
    • Cada tipo de nó deve ser mapeado para seu próprio Conjunto de Escala de Máquina Virtual localizado em uma zona diferente.
    • Cada Conjunto de Escala de Máquina Virtual deve ter pelo menos cinco nós (Durabilidade Prateada).

Você deve usar essa opção quando tiver um cluster não gerenciado do Service Fabric existente com o balanceador de carga SKU padrão e os recursos IP que deseja migrar. Se o cluster não gerenciado existente tiver recursos de SKU básicos, você verá a opção de migração de SKU básica abaixo.

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

Habilitar zonas em um conjunto de dimensionamento de máquina virtual

Para habilitar uma zona em um Conjunto de Dimensionamento de Máquina Virtual, inclua os três valores a seguir no recurso Conjunto de Dimensionamento de Máquina Virtual:

  • O primeiro valor é a zones propriedade, que especifica em qual Zona de Disponibilidade o Conjunto de Dimensionamento de Máquina Virtual é implantado.
  • O segundo valor é a singlePlacementGroup propriedade, que deve ser definida como true.
  • O terceiro valor é a faultDomainOverride propriedade na extensão Conjunto de Escala de Máquina Virtual do Service Fabric. Essa propriedade deve incluir apenas a zona na qual esse Conjunto de Dimensionamento de Máquina Virtual será colocado. Exemplo: "faultDomainOverride": "az1". Todos os recursos do Conjunto de Escala de Máquina Virtual 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ário no recurso de cluster do Service Fabric

Para definir um ou mais tipos de nó como primários em um recurso de cluster, defina a isPrimary propriedade 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 tiver algum problema, contacte o suporte para obter assistência.

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

Quando usar esta opção

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

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

Para migrar um cluster que esteja usando um balanceador de carga e IP com uma SKU básica, você deve primeiro criar um balanceador de carga e um recurso IP totalmente novos usando a SKU padrão. Não é possível atualizar esses recursos.

Faça referência ao novo balanceador de carga e 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 Escala de Máquina Virtual foram adicionados nas zonas 1, 2 e 3. Esses Conjuntos de Dimensionamento de Máquina Virtual fazem referência ao balanceador de carga e ao IP recém-criados e são marcados como tipos de nó primário no recurso de cluster do Service Fabric.

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

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

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

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

  2. Quando os recursos terminarem de implantar, 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 desativados, os serviços do sistema serão executados no tipo de nó primário, que está distribuído entre zonas. Em seguida, você pode remover os nós desabilitados do cluster. Depois que os nós forem removidos, você poderá remover o IP original, o balanceador de carga e os recursos do Conjunto de Escala de Máquina Virtual.

    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, remova as referências a esses recursos do modelo do Gerenciador de Recursos que você implantou.

  5. Finalmente, 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 tiver algum problema, contacte o suporte para obter assistência.

Próximos passos