Implantar um cluster do Azure Service Fabric em zonas de disponibilidade

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

• 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

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:

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 balanceador de carga ou recurso IP sem a propriedade SKU cria uma SKU básica, que não oferece suporte a 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"
  }
}

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 balanceador de carga SKU padrão e o IP público introduzem novas habilidades e comportamentos diferentes para a conectividade de saída quando comparados 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?.

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.

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

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.

{
  "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 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ó.

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:

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 balanceador de carga de SKU básico e um IP de SKU básico

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