Partilhar via

Implantar um cluster gerenciado do 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.

O cluster gerenciado do Service Fabric oferece suporte a implantações que abrangem várias zonas de disponibilidade para fornecer resiliência de zona. Essa configuração garante alta disponibilidade dos serviços críticos do sistema e de seus aplicativos para proteger contra pontos únicos de falha. As Zonas de Disponibilidade do Azure só estão disponíveis em regiões selecionadas. Para obter mais informações, consulte Visão geral das zonas de disponibilidade do Azure.

Nota

A abrangência da zona de disponibilidade só está disponível em clusters de SKU padrão.

Modelos de exemplo estão disponíveis: modelo de zona de disponibilidade cruzada do Service Fabric

Topologia para clusters gerenciados do Azure Service Fabric resilientes por zona

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.

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

A topologia recomendada para cluster gerenciado requer os seguintes recursos:

  • 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 suporta um número mínimo de seis (2 em cada AZ).
  • Os tipos de nó secundário devem ter pelo menos seis nós para melhor resiliência, mas suportam o número mínimo de três.

Nota

Apenas 3 implantações de zona de disponibilidade são suportadas.

Nota

Não é possível fazer uma alteração in-loco de conjuntos de escala de máquina virtual em um cluster gerenciado de cluster sem abrangência de zona para cluster com abrangência de zona.

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

Lista de nós de exemplo representando formatos FD/UD em uma escala de máquina virtual definir zonas de abrangência

Lista de nós de exemplo representando formatos FD/UD em uma escala de máquina virtual definir zonas de abrangência.

Distribuição de réplicas de serviço entre zonas: quando um serviço é implantado nos tipos de nó que abrangem zonas, as réplicas são colocadas para garantir que elas aterrissem em zonas separadas. Essa separação é assegurada à medida que os domínios de falha nos nós presentes 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 um serviço, a distribuição é 2-2-1 e o tempo de execução tenta garantir uma distribuição igual entre AZs.

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ó da zona de disponibilidade cruzada devem ser configurados com esta configuração: contagem de réplicas com destino = 9, min = 5. Essa configuração ajuda o serviço a funcionar mesmo quando uma zona fica inativa, já que seis réplicas ainda estarão ativas nas outras duas zonas. Uma atualização de aplicativo em tal cenário também será realizada.

Cenário de zona inativa: quando uma zona fica inativa, todos os nós dessa zona aparecem como inativos. As réplicas de serviço nesses nós também estarão inativas. Como há réplicas nas outras zonas, o serviço continua a responder com réplicas primárias fazendo failover para as zonas que estão funcionando. Os serviços aparecerão em estado de aviso à medida que a contagem de réplicas de destino não for atendida e a contagem de máquinas virtuais (VM) ainda for maior do que o tamanho mínimo definido da réplica de destino. Como resultado, o balanceador de carga do Service Fabric exibe réplicas nas zonas de trabalho para corresponder à contagem de réplicas de destino configurada. Neste ponto, os serviços devem parecer saudáveis. Quando a zona que estava inativa voltar a subir, o balanceador de carga espalhará novamente todas as réplicas de serviço uniformemente por todas as zonas.

Configuração de rede

Para obter mais informações, consulte Definir configurações de rede para clusters gerenciados do Service Fabric.

Habilitando um cluster gerenciado do Azure Service Fabric resiliente de zona

Para habilitar um cluster gerenciado do Azure Service Fabric resiliente de zona, você deve incluir a seguinte propriedade ZonalResiliency , que especifica se o cluster é resiliente de zona ou não.

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

Migrar um cluster resiliente não de zona existente para Resiliente de Zona (Visualização)

Os clusters gerenciados do Service Fabric existentes que não são estendidos entre zonas de disponibilidade agora podem ser migrados in-loco para abranger zonas de disponibilidade. Os cenários suportados incluem clusters criados em regiões que têm três zonas de disponibilidade e clusters em regiões onde três zonas de disponibilidade são disponibilizadas após a implantação.

Requisitos:

Nota

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

  1. Comece determinando se um novo IP é necessário e quais recursos precisam ser migrados para se tornar resiliente à zona. Para obter o estado atual de resiliência da Zona de Disponibilidade para os recursos do cluster gerenciado, use a seguinte chamada de 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 IP público não for resiliente à zona, a migração do cluster causará uma breve perda de conectividade externa. Esta perda de ligação deve-se à migração, à configuração de um novo IP público e à atualização do FQDN (nome de domínio totalmente qualificado) do cluster para o novo IP. Se o recurso IP público for resiliente à zona, a migração não modificará o recurso IP público nem o FQDN e não haverá impacto na conectividade externa.

  2. Inicie a conversão da conta de armazenamento subjacente criada para cluster gerenciado de LRS (armazenamento com redundância local) para ZRS (armazenamento redundante de zona) usando a conversão iniciada pelo cliente. O grupo de recursos da conta de armazenamento que precisa ser migrado seria do formato "SFC_ClusterId" (ex SFC_9240df2f-71ab-4733-a641-53a8464d992d) sob a mesma assinatura que o recurso de cluster gerenciado.

  3. Adicionar propriedade zones a tipos de nó existentes

    Esta etapa configura o Conjunto de Escala de Máquina Virtual gerenciado associado ao tipo de nó como resiliente a zona, garantindo que todas as novas VMs adicionadas a ele sejam implantadas em zonas de disponibilidade (VMs zonais). Se o tipo de nó especificado for primário, o provedor de recursos executará a migração do IP público junto com uma atualização do DNS do FQDN do cluster, se necessário, para se tornar resiliente à zona. Use a API para entender a getazresiliencystatus implicação desta etapa.

  • Use apiVersion 2022-02-01-preview ou superior.

  • Adicione o zones conjunto de parâmetros aos ["1", "2", "3"] 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"]
     ...
   }
}

  1. Dimensionar tipos de nós para adicionar nós zonais e remover nós regionais

    Neste estágio, os Conjuntos de Escala de Máquina Virtual são marcados como resilientes a zona. Assim, ao aumentar a escala, os nós recém-adicionados serão zonais e, ao reduzir, os nós regionais serão removidos. Essa abordagem oferece a flexibilidade de dimensionamento em qualquer ordem que esteja alinhada com seus requisitos de capacidade, ajustando a vmInstanceCount propriedade 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 .

    Durante todo o processo, você pode verificar a getazresiliencystatus API 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 0 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
}

    Nota

    O processo de dimensionamento 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 de malha de serviço.

  2. 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 estendam por zonas de disponibilidade e, portanto, o cluster permaneça tolerante a falhas de AZ. Defina zonalResiliency: true o modelo ARM do cluster e faça uma implantação para marcar o cluster como resiliente à zona e garantir que todas as implantações do novo tipo de nó se estendam pelas zonas de disponibilidade. Esta atualização só é permitida se todos os tipos de nó tiverem pelo menos seis nós zonais e 0 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.

  3. Valide que todos os recursos são resilientes à zona

    Para validar o estado de resiliência da Zona de Disponibilidade 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

    Esta chamada de 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 algum problema, entre em contato com o suporte para obter assistência.

Habilitar o FastZonalUpdate em clusters gerenciados do Service Fabric (visualização)

Os clusters gerenciados do Service Fabric oferecem suporte a atualizações mais rápidas de clusters e aplicativos, 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 atualização (UDs) em vários tipos de nó AZ. Esse grande número de UDs reduziu a velocidade de 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 via modelo ARM, definindo a propriedade zonalUpdateMode como "rápida" e, em seguida, modificando um atributo de tipo de nó, como adicionar um nó e, em seguida, remover o nó para cada tipo de nó (consulte as etapas necessárias 2 e 3). O recurso de cluster gerenciado do Service Fabric apiVersion deve ser 2022-10-01-preview ou posterior.

  1. Modifique o modelo ARM com a nova propriedade zonalUpdateMode.
   "resources": [
        {
            "type": "Microsoft.ServiceFabric/managedClusters",
            "apiVersion": "2022-10-01-preview",
            '''
            "properties": {
                '''
                "zonalResiliency": true,
                "zonalUpdateMode": "fast",
                ...
            }
        }]

  1. Adicione um nó a um cluster usando o comando az sf cluster node add PowerShell.

  2. Remova um nó de um cluster usando o comando az sf cluster node remove PowerShell.