Compartilhar via

Implantar um cluster do Azure Service Fabric entre zonas de disponibilidade

  • Artigo

As Zonas de Disponibilidade no Azure são uma oferta de alta disponibilidade que protege os aplicativos e dados contra falhas do datacenter. Uma Zona de Disponibilidade é um local físico exclusivo equipado com energia, resfriamento e rede independentes em uma região do Azure.

Para dar suporte a clusters que abrangem Zonas de disponibilidade, o Azure Service Fabric fornece os dois métodos de configuração, conforme descrito no artigo abaixo. Zonas de disponibilidade estão disponíveis somente em determinadas regiões. Para obter mais informações, confira Visão geral de Zonas de disponibilidade.

Há modelos de exemplo disponíveis em Modelos de Zona de disponibilidade cruzada do Service Fabric.

Topologia para abranger um tipo de nó primário entre Zonas de Disponibilidade

Observação

O benefício de abranger o tipo de nó primário entre 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 recurso único de IP público usando um SKU Standard
  • Um recurso único do balanceador de carga usando um SKU Standard
  • Um NSG (grupo de segurança de rede) referenciado pela sub-rede na qual você implanta seus conjuntos de dimensionamento de máquinas virtuais

Observação

A propriedade de grupo de posicionamento único do conjunto de dimensionamento de máquinas virtuais deve ser definida como true.

A seguinte lista de nós de exemplo detalha os formatos FD/UD em um conjunto de dimensionamento de máquinas virtuais que abrangem zonas:

Captura de tela que mostra uma lista de nós de exemplo de formatos FD/UD em um conjunto de dimensionamento de máquinas virtuais que abrangem zonas.

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 inseridas para garantir que elas sejam colocadas 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 de 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 runtime tentará garantir a distribuição igual entre zonas.

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

Os serviços de usuário com estado implantados nos tipos de nó de Zonas de disponibilidade devem ser configurados da desta 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 porque seis réplicas ainda estarão ativas nas outras duas zonas. Uma atualização de aplicativo neste cenário também será bem-sucedida.

ReliabilityLevel de cluster

Esse valor define o número de nós de semente 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 habilitar a resiliência de zona.

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

Cenário de zona inativa

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. Réplicas primárias fazem failover para as zonas em funcionamento. Os serviços parecem estar em estados de aviso porque a contagem de réplicas de destino ainda não foi obtida, 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 de Service Fabric abre réplicas nas zonas de trabalho para corresponder à contagem de réplicas de destino. Nesse ponto, os serviços aparentam ser íntegros. Quando a zona que estava inativa voltar, o balanceador de carga distribuirá todas as réplicas de serviço uniformemente entre as zonas.

Otimizações futuras

  • Para fornecer atualizações de infraestrutura confiáveis, o Service Fabric requer que a durabilidade do conjunto de dimensionamento de máquinas virtuais seja definida pelo menos como Silver. Isso habilita o conjunto de dimensionamento de máquinas virtuais subjacente e o tempo de execução de Service Fabric para fornecer atualizações confiáveis. Isso também exige que cada zona tenha no mínimo 5 VMs. Estamos trabalhando para levar esse requisito para 3 e 2 VMs por zona para os tipos de nó principais e não primário, respectivamente.
  • Todas as configurações mencionadas abaixo e o trabalho futuro fornecem migração no local para os clientes em que o mesmo cluster pode ser atualizado para usar a nova configuração adicionando novos nodeTypes e desativando os antigos.

Requisitos de rede

IP público e recurso do balanceador de carga

Para habilitar a propriedade zones em um recurso de conjunto de dimensionamento de máquinas virtuais, o balanceador de carga e o recurso de IP referenciado por esse conjunto de dimensionamento de máquinas virtuais devem estar usando um SKU Standard. A criação de um recurso de IP sem a propriedade SKU cria um SKU Básico, que não dá suporte a Zonas de Disponibilidade. Um balanceador de carga de SKU Standard bloqueia todo o tráfego de fora 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"
  }
}

Observação

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 têm um SKU Básico, consulte a seção de migração deste artigo.

Regras NAT dos 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 NAT do conjunto de dimensionamento de máquinas virtuais. Cada conjunto de dimensionamento de máquinas virtuais deve ter um pool 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 de SKU Standard

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

Observação

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 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 de SKU Standard 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. Habilitar várias Zonas de Disponibilidade em um único conjunto de dimensionamento de máquinas virtuais

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 em zonas de disponibilidade mantendo um único conjunto de dimensionamento de máquinas virtuais.

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

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

Configurar zonas em um conjunto de dimensionamento de máquinas virtuais

Para habilitar zonas em um conjunto de dimensionamento de máquinas virtuais, inclua os três valores a seguir no recurso do 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.
  • É necessário que uma zona de disponibilidade que abrange conjuntos de dimensionamento de máquinas virtuais seja configurada com pelo menos três zonas de disponibilidade, não importa o nível de durabilidade.
  • Uma zona de disponibilidade que abrange conjuntos de dimensionamento de máquinas virtuais com durabilidade Prata ou mais alta precisa ter pelo menos 15 VMs (cinco por região).
  • É necessário que uma zona de disponibilidade que abrange conjuntos de dimensionamento de máquinas virtuais com durabilidade bronze alta tenha pelo menos seis VMs.

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

O tipo de nó do Service Fabric deve ser habilitado para dar 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 poderá 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 domínios de atualização (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. Esse modo de implantação é mais rápido para atualizações, mas não é recomendado, pois vai contra as diretrizes de SDP, que indicam que as atualizações devem ser aplicadas somente a uma zona por 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. Esse 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 do conjunto de dimensionamento de máquinas virtuais subjacentes 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 aconteça paralela ou sequencialmente em 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 implantação é mais rápido para atualizações, mas não é recomendado, pois vai contra as diretrizes de SDP, que indicam que as atualizações devem ser aplicadas somente a uma zona por 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 8.1.321 ou superior.

{
  "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 nodetype 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 recursos IP básicos: esse processo já está descrito em uma sub-seçã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 dimensionamento de máquinas virtuais 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 de SKU Padrão com um NSG: siga o mesmo procedimento descrito anteriormente. No entanto, não é necessário adicionar novos recursos de IP e NSG. Os mesmos recursos podem ser reutilizados no novo tipo de nó.

2. Implantar zonas ao fixar um conjunto de dimensionamento de máquinas virtuais para cada zona

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 para 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).

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

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

Habilitar 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 valores a seguir no recurso do 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')]"
    }
  ]
}

Migrar para Zonas de Disponibilidade do Azure de um cluster usando um IP de SKU básico

Para migrar um cluster que está usando um IP com um SKU Básico, primeiro você deve criar um recurso de IP totalmente novo usando o SKU Standard. 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 do conjunto de dimensionamento de máquinas virtuais foram adicionados nas Zonas 1, 2 e 3. Esses conjuntos de dimensionamento de máquinas virtuais fazem referência ao IP recém-criado 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 para 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 o IP original, o balanceador de carga e os recursos do 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