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

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.

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ário:

• Cluster de SKU padrão.
• Três zonas de disponibilidade na região.

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 Standard.
• Um NSG (grupo de segurança de rede) referenciado pela sub-rede onde tu implantas os teus Conjuntos de Escalonamento de Máquinas Virtuais.

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 Standard SKU, distinto do seu balanceador de carga existente Basic SKU.
• Um novo recurso IP usando o SKU padrão, distinto do seu recurso IP SKU básico existente.

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ó. Esta é a topologia de implementação recomendada, pois possibilita a implantação em zonas de disponibilidade enquanto mantém um único conjunto dimensionável de máquinas virtuais.

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 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 Standard SKU e recursos IP existentes

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 a atualizações de infraestrutura a ficarem bloqueadas. Leia mais sobre equilíbrio de zonas.

Não é necessário configurar as FaultDomain e UpgradeDomain substituições.

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

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 múltiplas 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 de acordo com o tipo de nó são agrupadas em UDs e ignoram as informações de 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 Escalonamento de Máquinas Virtuais ainda ocorrem em paralelo em todas as Zonas de Disponibilidade. Esta propriedade não afeta a distribuição UD para os tipos de nó que não possuem múltiplas zonas ativadas.

• 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.

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

Migrar para o nó do tipo 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. Não é possível migrar um tipo de nó existente para suportar múltiplas zonas. O artigo Dimensionar um tipo de nó primário de um 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 recursos de IP e recursos 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 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 estender um cluster do Service Fabric entre Zonas de Disponibilidade, deve-se criar um tipo de nó primário em cada Zona de Disponibilidade suportada pela região. Isso distribui os nós de origem 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 o seu próprio Conjunto de Escala de Máquinas Virtuais, 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 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 Standard SKU e recursos IP existentes

Habilitar zonas num conjunto de dimensionamento de máquinas virtuais

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 propriedade faultDomainOverride no conjunto de escalas de máquinas virtuais 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, deve-se ter três tipos de nós 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 esta opção quando tiver um cluster não gerido do Service Fabric existente com o balanceador de carga SKU Básico e 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 Basic SKU 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 Standard SKU
   • 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 o seu próprio Conjunto de Escala de Máquinas Virtuais, 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 ser implementados, pode desativar 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. Após todos os nós estarem desativados, os serviços do sistema serão executados no tipo de nó primário, que está distribuído por várias 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

• Aumentar a escala de um tipo de nó primário num cluster não gerido do Service Fabric

• Adicionar, remover ou dimensionar tipos de nós de clusters geridos pelo Service Fabric