Implantar um cluster gerenciado do Service Fabric entre Zonas de Disponibilidade

Artigo
10/15/2024

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.

O cluster gerenciado do Service Fabric dá suporte a implantações que se estendem por várias Zonas de Disponibilidade para fornecer resiliência de zona. Esta configuração garante a alta disponibilidade dos serviços críticos do sistema e seus aplicativos para proteção contra pontos únicos de falha. As Zonas de Disponibilidade do Azure só estão disponíveis em regiões específicas. Para obter mais informações, confira Visão geral de Zonas de Disponibilidade do Azure.

Observação

A abrangência da Zona de Disponibilidade só está disponível em clusters SKU Standard.

Há modelos de exemplo disponíveis: modelo do Service Fabric de zona de disponibilidade cruzada

Topologia para clusters gerenciados do Azure Service Fabric com resiliência de zona

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.

Um cluster do Service Fabric distribuído entre Zonas de Disponibilidade (AZ) garante alta disponibilidade do estado do cluster.

A topologia recomendada para o cluster gerenciado requer os recursos a seguir:

A SKU do cluster deve ser Standard
O tipo de nó primário deve ter pelo menos nove nós (3 em cada AZ) para melhor resiliência, mas dá suporte ao número mínimo de seis (2 em cada AZ).
Os tipos de nós secundários devem ter pelo menos seis nós para melhor resiliência, mas dão suporte a um número mínimo de três.

Observação

Há suporte apenas para três implantações de Zona de Disponibilidade.

Observação

Não é possível fazer uma alteração local de conjunto de dimensionamento de máquinas virtuais em um cluster gerenciado sem abrangência em zona para um cluster de abrangência em zona.

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

Lista de nós de exemplo ilustrando formatos FD/UD em um conjunto de dimensionamento de máquinas virtuais que abrangem zonas

Lista de nós de exemplo ilustrando 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 for implantado em tipos de nó, que são zonas de abrangência, as réplicas serão colocadas para garantir que elas se espalhem em zonas separadas. Essa separação é garantida porque o domínio de falha nos nós presentes em cada um desses tipos de nós 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 um serviço, a distribuição é 2-2-1 e o tempo de execução tentará garantir uma distribuição igual entre as AZs.

Configuração da réplica de serviço do usuário: os serviços de usuário com estado implantados nos tipos de nó da zona de disponibilidade cruzada devem ter esta configuração: contagem de réplicas com destino = 9, mín = 5. Esta configuração ajuda o serviço a funcionar mesmo quando uma zona ficar inativa, pois seis réplicas ainda estarão ativas nas outras duas zonas. Nesse cenário, uma atualização de aplicativo também ocorrerá.

Cenário de zona inativa: quando uma zona fica inativa, todos os nós presentes nela aparecerão como inativos. As réplicas de serviço nesses nós também ficarão inativas. Como há réplicas nas outras zonas, o serviço continua a ser responsivo com réplicas primárias que estejam fazendo failover para as zonas que estejam funcionando. Os serviços aparecerão em estado de aviso, pois a contagem de réplicas de destino não foi atingida e a contagem de máquinas virtuais (VMs) ainda é maior do que o tamanho mínimo de réplica de destino definido. Consequentemente, o balanceador de carga do Service Fabric abre réplicas nas zonas de trabalho para corresponder à contagem de réplica de destino configurada. Neste ponto, os serviços devem parecer íntegros. Quando a zona que estava inativa voltar a atividade, o balanceador de carga redistribuirá todas as réplicas de serviço uniformemente entre todas as zonas.

Configuração de rede

Para obter mais informações, confira Definir as configurações de rede para clusters gerenciados pelo Service Fabric.

Habilitando um cluster gerenciado do Azure Service Fabric resiliente à zona

Para habilitar um cluster gerenciado do Microsoft Azure Service Fabric com resiliência de zona, você deve incluir a propriedade ZonalResiliency a seguir, que especifica se o cluster tem resiliência de zona ou não.

{
  "apiVersion": "2021-05-01",
  "type": "Microsoft.ServiceFabric/managedclusters",
  "properties": {
  ...
  "zonalResiliency": "true",
  ...
  }
}

Migrar um cluster sem resiliência de zona existente para um cluster com Resiliência de Zona

Os clusters gerenciados do Service Fabric existentes que não estão estendidos pelas zonas de disponibilidade agora podem ser migrados no local para estender as zonas de disponibilidade. Os cenários com suporte incluem clusters criados em regiões que têm três zonas de disponibilidade, bem como clusters em regiões onde três zonas de disponibilidade são disponibilizadas após a implantação.

Requisitos:

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

Observação

A migração para uma configuração com resiliência de zona pode causar uma breve perda de conectividade externa por meio do balanceador de carga, mas não causará efeito na integridade do cluster. Isso 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.

Comece determinando se haverá um novo IP necessário e quais recursos precisam ser migrados para se tornarem resilientes à zona. Para obter o estado de resiliência da Zona de Disponibilidade atual para os recursos do cluster gerenciado, use a seguinte chamada à API:

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ServiceFabric/managedClusters/{clusterName}/getazresiliencystatus?api-version=2022-02-01-preview

Ou você pode usar o Módulo Az da seguinte maneira:

Select-AzSubscription -SubscriptionId {subscriptionId}
Invoke-AzResourceAction -ResourceId /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ServiceFabric/managedClusters/{clusterName} -Action getazresiliencystatus -ApiVersion 2022-02-01-preview

O comando deve fornecer uma resposta semelhante a:

{
"baseResourceStatus" :[
  {
  "resourceName": "sfmccluster1"
  "resourceType": "Microsoft.Storage/storageAccounts"
  "isZoneResilient": false
  },
  {
  "resourceName": "PublicIP-sfmccluster1"
  "resourceType": "Microsoft.Network/publicIPAddresses"
  "isZoneResilient": false
  },
  {
  "resourceName": "primary"
  "resourceType": "Microsoft.Compute/virutalmachinescalesets"
  "isZoneResilient": false
  }
],
"isClusterZoneResilient": false
}

Se o recurso de IP público não for resiliente à zona, a migração do cluster causará uma breve perda de conectividade externa. Essa perda de conexão ocorre devido à migração configurar um novo IP público e atualizar o FQDN do cluster para o novo IP. Se o recurso de IP público for resiliente à zona, a migração não modificará o recurso de IP público ou o FQDN, e não haverá nenhum impacto de conectividade externa.

Inicie a conversão da conta de armazenamento subjacente criada para o cluster gerenciado do LRS (armazenamento com redundância local) para o ZRS (armazenamento com redundância de zona) usando a conversão iniciada pelo cliente. O grupo de recursos da conta de armazenamento que precisa ser migrado seria do formulário "SFC_ClusterId"(ex SFC_9240df2f-71ab-4733-a641-53a8464d992d) na mesma assinatura que o recurso de cluster gerenciado.
Adicionar propriedade de zonas aos tipos de nó existentes

Essa etapa configura o Conjunto de Dimensionamento de Máquinas Virtuais gerenciado associado ao tipo de nó como resiliente à zona, garantindo que todas as novas VMs adicionadas a ela sejam implantadas entre zonas de disponibilidade (VMs zonais). Essa etapa disparará o provedor de recursos para executar a migração do tipo de nó primário e IP público, juntamente com uma atualização DNS FQDN de cluster, se necessário, para se tornar resiliente à zona. Use a API getazresiliencystatus para entender a implicação dessa etapa.

Usar apiVersion 2022-02-01-preview ou superior.

Adicione o conjunto de parâmetros zones ao ["1", "2", "3"] para os tipos de nó existentes:

{
   "apiVersion": "2024-02-01-preview",
   "type": "Microsoft.ServiceFabric/managedclusters/nodetypes",
   "name": "[concat(parameters('clusterName'), '/', parameters('nodeTypeName'))]",
   "location": "[resourcegroup().location]",
   "dependsOn": [
     "[concat('Microsoft.ServiceFabric/managedclusters/', parameters('clusterName'))]"
   ],
   "properties": {
     ...
     "isPrimary": true,
     "zones": ["1", "2", "3"]
     ...
   }
},
{
   "apiVersion": "2024-02-01-preview",
   "type": "Microsoft.ServiceFabric/managedclusters/nodetypes",
   "name": "[concat(parameters('clusterName'), '/', parameters('nodeTypeNameSecondary'))]",
   "location": "[resourcegroup().location]",
   "dependsOn": [
     "[concat('Microsoft.ServiceFabric/managedclusters/', parameters('clusterName'))]"
   ],
   "properties": {
     ...
     "isPrimary": false,
     "zones": ["1", "2", "3"]
     ...
   }
}

Escale os tipos de nó para adicionar nós zonais e remover nós regionais

Nessa fase, os Conjuntos de Dimensionamento de Máquinas Virtuais são marcados como resilientes à zona. Portanto, ao escalar verticalmente, os nós recém-adicionados serão zonais e, ao reduzir verticalmente, os nós regionais serão removidos. Essa abordagem fornece a flexibilidade para escalar em qualquer ordem que se alinhe aos requisitos de capacidade ajustando a propriedade vmInstanceCount nos tipos de nó.

Por exemplo, se o vmInstanceCount inicial estiver definido como 6 (indicando seis nós regionais), você poderá executar duas implantações:
- Primeira implantação: aumente o vmInstanceCount para 12 para adicionar 6 nós zonais.
- Segunda implantação: diminua o vmInstanceCount para 6 para remover todos os nós regionais.
Ao longo do processo, você pode verificar a API getazresiliencystatus para recuperar o status de progresso, conforme ilustrado abaixo. O processo é considerado concluído quando cada tipo de nó tem um mínimo de seis nós zonais e zero nós regionais.
```
{
"baseResourceStatus" :[
  {
  "resourceName": "sfmccluster1"
  "resourceType": "Microsoft.Storage/storageAccounts"
  "isZoneResilient": true
  },
  {
  "resourceName": "PublicIP-sfmccluster1"
  "resourceType": "Microsoft.Network/publicIPAddresses"
  "isZoneResilient": true
  },
  {
  "resourceName": "ntPrimary"
  "resourceType": "Microsoft.Compute/virutalmachinescalesets"
  "isZoneResilient": false
  "details": "Status: InProgress, ZonalNodes: 6, RegionalNodes: 6"
  },
  {
  "resourceName": "ntSecondary"
  "resourceType": "Microsoft.Compute/virutalmachinescalesets"
  "isZoneResilient": true
  "details": "Status: Done, ZonalNodes: 6, RegionalNodes: 0"
  }
],
"isClusterZoneResilient": false
}
```
Observação

O processo de escala para o tipo de nó primário exigirá tempo adicional, pois cada adição ou remoção de um nó iniciará uma atualização de cluster do Service Fabric.
Marcar o cluster resiliente a falhas de zona

Esta etapa ajuda em implantações futuras, pois garante que todas as implantações futuras de tipos de nó se esteram entre zonas de disponibilidade e, portanto, o cluster permanece tolerante a falhas de AZ. Defina zonalResiliency: true no modelo do ARM do cluster e faça uma implantação para marcar o cluster como com resiliência de zona e garantir que todas as novas implantações de tipo de nó abranjam as diferentes zonas de disponibilidade. Essa atualização só será permitida se todos os tipos de nó tiverem pelo menos seis nós zonais e zero nós regionais.
```
{
  "apiVersion": "2022-02-01-preview",
  "type": "Microsoft.ServiceFabric/managedclusters",
  "zonalResiliency": "true"
}
```
Você também pode ver o status atualizado no portal em Visão Geral –> Propriedades semelhantes a Zonal resiliency True, uma vez concluído.

Validar que todos os recursos são resilientes à zona

Para validar o estado de resiliência da zona de disponibilidade atual para os recursos do cluster gerenciado, use a seguinte chamada à API GET:

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ServiceFabric/managedClusters/{clusterName}/getazresiliencystatus?api-version=2022-02-01-preview

Essa chamada à API deve fornecer uma resposta semelhante a:

{
 "baseResourceStatus" :[
   {
   "resourceName": "sfmccluster1"
   "resourceType": "Microsoft.Storage/storageAccounts"
   "isZoneResilient": true
   },
   {
   "resourceName": "PublicIP-sfmccluster1"
   "resourceType": "Microsoft.Network/publicIPAddresses"
   "isZoneResilient": true
   },
   {
     "resourceName": "ntPrimary"
     "resourceType": "Microsoft.Compute/virutalmachinescalesets"
     "isZoneResilient": true
     "details": "Status: Done, ZonalNodes: 6, RegionalNodes: 0"
   },
   {
     "resourceName": "ntSecondary"
     "resourceType": "Microsoft.Compute/virutalmachinescalesets"
     "isZoneResilient": true
     "details": "Status: Done, ZonalNodes: 6, RegionalNodes: 0"
   }
 ],
 "isClusterZoneResilient": true
}

Se você tiver problemas, entre em contato com o suporte para obter assistência.

Habilitar o FastZonalUpdate em clusters gerenciados do Service Fabric

Os clusters gerenciados do Service Fabric dão suporte a atualizações mais rápidas de cluster e aplicativo, reduzindo o máximo de domínios de atualização por zona de disponibilidade. A configuração padrão agora pode ter no máximo 15 domínios de upgrade (UDs) em vários tipos de nó AZ. Esse grande número de UDs reduziu a velocidade da atualização. A nova configuração reduz o máximo de UDs, o que resulta em atualizações mais rápidas, mantendo a segurança das atualizações intacta.

A atualização deve ser feita por meio do modelo do ARM definindo a propriedade zonalUpdateMode como "rápida" e modificando um atributo de tipo de nó, como adicionar um nó e, em seguida, remover o nó a cada nó (consulte as etapas 2 e 3 necessárias). A apiVersion do recurso de cluster gerenciado do Service Fabric deve ser 2022-10-01- versão prévia ou posterior.

Modifique o modelo do ARM com a nova propriedade zonalUpdateMode.

   "resources": [
        {
            "type": "Microsoft.ServiceFabric/managedClusters",
            "apiVersion": "2022-10-01-preview",
            '''
            "properties": {
                '''
                "zonalResiliency": true,
                "zonalUpdateMode": "fast",
                ...
            }
        }]

Adicione um nó a um cluster usando o comando do PowerShell az sf cluster node add.
Remova um nó de um cluster usando o comando do PowerShell az sf cluster node remove.

Compartilhar via

Implantar um cluster gerenciado do Service Fabric entre Zonas de Disponibilidade

Topologia para clusters gerenciados do Azure Service Fabric com resiliência de zona

Configuração de rede

Habilitando um cluster gerenciado do Azure Service Fabric resiliente à zona

Migrar um cluster sem resiliência de zona existente para um cluster com Resiliência de Zona

Habilitar o FastZonalUpdate em clusters gerenciados do Service Fabric

Comentários

Recursos adicionais