Partilhar via

Implantar um cluster do Azure Service Fabric em zonas de disponibilidade

  • Artigo

As Zonas de Disponibilidade no Azure são uma oferta de alta disponibilidade que protege as suas aplicações e dados contra falhas no centro de dados. Uma Zona de Disponibilidade é uma localização física exclusiva equipada com alimentação, arrefecimento e rede independentes numa região do Azure.

Para dar suporte a clusters que se estendem por zonas de disponibilidade, o Azure Service Fabric fornece os dois métodos de configuração, conforme descrito no artigo abaixo. As Zonas de Disponibilidade estão disponíveis apenas em regiões selecionadas. Para obter mais informações, consulte a visão geral das zonas de disponibilidade.

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

Topologia para abrangência de um tipo de nó primário em zonas de disponibilidade

Nota

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

  • 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

Nota

A propriedade do grupo de posicionamento único do conjunto de dimensionamento da máquina virtual deve ser definida como true.

A lista de nós de exemplo a seguir descreve formatos FD/UD em zonas de abrangência de um conjunto de escala de máquina virtual:

Captura de tela que mostra uma lista de nós de exemplo de formatos FD/UD em um conjunto de zonas de abrangência de escala de máquina virtual.

Distribuição de réplicas de serviço entre zonas

Quando um serviço é implantado nos tipos de nó que abrangem Zonas de Disponibilidade, as réplicas são colocadas para garantir que elas aterrissem em zonas separadas. Os domínios de falha nos nós em cada um desses tipos de nó são configurados com as informações da zona (ou seja, FD = fd:/zone1/1, etc.). Por exemplo, para cinco réplicas ou instâncias de serviço, a distribuição é 2-2-1 e o tempo de execução tentará garantir uma distribuição igual entre zonas.

Configuração da réplica de serviço do usuário

Os serviços de usuário com monitoração de estado implantados nos tipos de nó nas Zonas de Disponibilidade devem ser configurados da seguinte forma: contagem de réplicas com destino = 9, min = 5. Essa configuração ajuda o serviço a funcionar mesmo quando uma zona fica inativa, pois seis réplicas ainda estarão ativas nas outras duas zonas. Uma atualização de aplicativo nesse cenário também será bem-sucedida.

Nível de confiabilidade do cluster

Esse valor define o número de nós de propagação no cluster e o tamanho da réplica dos serviços do sistema. Uma configuração de zona de disponibilidade cruzada tem um número maior de nós, que são distribuídos entre zonas para permitir a resiliência da zona.

Um valor mais alto ReliabilityLevel garante que mais nós de propagação e réplicas de serviço do sistema estejam presentes e distribuídos uniformemente entre as zonas, de modo que, se uma zona falhar, o cluster e os serviços do sistema não sejam afetados. ReliabilityLevel = Platinum (recomendado) garante que existem nove nós de sementes espalhados por zonas no aglomerado, com três sementes em cada zona.

Cenário de zone-down

Quando uma zona fica inativa, todos os nós e réplicas de serviço dessa zona aparecem como inativos. Como há réplicas nas outras zonas, o serviço continua a responder. Failover de réplicas primárias para as zonas de funcionamento. Os serviços parecem estar em estados de aviso porque a contagem de réplicas de destino ainda não foi alcançada e a contagem de máquinas virtuais (VM) ainda é maior do que o tamanho mínimo da réplica de destino.

O balanceador de carga do Service Fabric exibe réplicas nas zonas de trabalho para corresponder à contagem de réplicas de destino. Neste ponto, os serviços parecem saudáveis. Quando a zona que estava inativa voltar a subir, o balanceador de carga distribuirá todas as réplicas de serviço uniformemente pelas zonas.

Próximas otimizações

  • Para fornecer atualizações confiáveis de infraestrutura, o Service Fabric exige que a durabilidade do conjunto de escala da máquina virtual seja definida pelo menos como Silver. Isso permite que o conjunto de dimensionamento da máquina virtual subjacente e o tempo de execução do Service Fabric forneçam atualizações confiáveis. Isso também requer que cada zona tenha no mínimo 5 VMs. Estamos trabalhando para reduzir esse requisito para 3 & 2 VMs por zona para tipos de nós primários ou não primários, respectivamente.
  • Todas as configurações abaixo mencionadas e o trabalho futuro, fornecem migração in-loco para os clientes, onde o mesmo cluster pode ser atualizado para usar a nova configuração, adicionando novos nodeTypes e aposentando os antigos.

Requisitos de rede

IP público e recurso de balanceador de carga

Para habilitar a zones propriedade em um recurso de conjunto de escala de máquina virtual, o balanceador de carga e o recurso IP referenciado por esse conjunto de escala de máquina virtual devem usar uma SKU padrão. Criar um recurso IP sem a propriedade SKU cria uma SKU básica, que não suporta zonas de disponibilidade. Um balanceador de carga SKU padrão bloqueia todo o tráfego externo por padrão. Para permitir o tráfego externo, implante um NSG na sub-rede.

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

Nota

Não é possível fazer uma alteração in-loco de SKU em recursos IP públicos. Se você estiver migrando de recursos existentes que tenham uma SKU básica, consulte a seção de migração deste artigo.

Regras NAT para conjuntos de dimensionamento de máquinas virtuais

As regras NAT (conversão de endereços de rede) de entrada para o balanceador de carga devem corresponder aos pools de NAT do conjunto de escala da máquina virtual. Cada conjunto de escala de máquina virtual deve ter um pool de NAT de entrada exclusivo.

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

Regras de saída para um balanceador de carga SKU padrão

O IP público de SKU padrão introduz novas habilidades e comportamentos diferentes para a conectividade de saída quando comparado ao uso de SKUs básicos. Se você quiser conectividade de saída quando estiver trabalhando com SKUs padrão, deverá defini-la explicitamente com um endereço IP público de SKU padrão ou um balanceador de carga de SKU padrão. Para obter mais informações, consulte Conexões de saída e O que é o Azure Load Balancer?.

Nota

O modelo padrão faz referência a um NSG que permite todo o tráfego de saída por padrão. O tráfego de entrada é limitado às portas necessárias para as operações de gerenciamento do Service Fabric. As regras do NSG podem ser modificadas para atender às suas necessidades.

Importante

Cada tipo de nó em um cluster do Service Fabric que usa um balanceador de carga SKU padrão requer uma regra que permita o tráfego de saída na porta 443. Isso é necessário para concluir a configuração do cluster. Qualquer implantação sem essa regra falhará.

1. Habilite várias zonas de disponibilidade em um único conjunto de escala de máquina virtual

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.

Diagrama da arquitetura da Zona de Disponibilidade do Azure Service Fabric.

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

Para habilitar zonas em um conjunto de dimensionamento de máquina virtual, inclua os três valores a seguir no recurso de conjunto de escala de máquina virtual:

  • O primeiro valor é a zones propriedade, que especifica as Zonas de Disponibilidade que estão no conjunto de escala da 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.
  • Um conjunto de dimensionamento de máquina virtual de abrangência de zona de disponibilidade deve ser configurado com pelo menos três zonas de disponibilidade, independentemente do nível de durabilidade.
  • Uma escala de máquina virtual de zona de disponibilidade definida com durabilidade Silver ou superior deve ter pelo menos 15 VMs (5 por região).
  • Um conjunto de escala de máquina virtual de abrangência de zona de disponibilidade com durabilidade Bronze deve ter pelo menos seis VMs.

Habilitar suporte para várias zonas no tipo de nó do Service Fabric

O tipo de nó do Service Fabric deve estar habilitado para oferecer suporte a várias zonas de disponibilidade.

  • 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. Essa propriedade controla o agrupamento lógico de VMs em domínios de atualização (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. Este modo de implantação é mais rápido para atualizações, nã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: 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. Esse 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 da 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 escala da 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. Este modo de implantação é mais rápido para atualizações, nã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 recursos IP básicos: 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 os recursos IP SKU padrão com um NSG: Siga o mesmo procedimento descrito anteriormente. No entanto, não há necessidade de adicionar novos recursos IP e NSG. Os mesmos recursos podem ser reutilizados no novo tipo de nó.

2. Implante zonas fixando uma escala de máquina virtual definida para cada zona

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 dimensionamento de máquina virtual deve ter pelo menos cinco nós (Durabilidade Prateada).

O diagrama a seguir mostra a arquitetura da Zona de Disponibilidade do Azure Service Fabric:

Diagrama que mostra a arquitetura da Zona de Disponibilidade do Azure Service Fabric.

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 de conjunto de escala de máquina virtual:

  • O primeiro valor é a propriedade, que especifica em zones qual Zona de Disponibilidade o conjunto de escala da 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 do 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 dimensionamento 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')]"
    }
  ]
}

Migrar para zonas de disponibilidade de um cluster usando um IP de SKU básico

Para migrar um cluster que está usando um IP com uma SKU Básica, você deve primeiro criar um recurso IP totalmente novo usando a SKU Padrão. Não é possível atualizar esses recursos.

Faça referência ao novo IP nos novos tipos de nó de zona de disponibilidade cruzada que você deseja usar. No exemplo anterior, três novos recursos de 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 IP recém-criado 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 dimensionamento 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 dimensionamento da 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