Descrição geral dos clusters dispersos

  • Artigo

Aplica-se a: Azure Stack HCI, versões 22H2 e 21H2

Uma solução de cluster disperso do Azure Stack HCI para recuperação após desastre fornece ativação pós-falha automática para restaurar a produção rapidamente e sem a necessidade de intervenção manual. A Réplica de Armazenamento fornece a replicação de volumes entre sites para recuperação após desastre, com todos os servidores a manterem-se sincronizados.

A Réplica de Armazenamento suporta a replicação síncrona e assíncrona:

  • A replicação síncrona espelha os dados entre sites numa rede de baixa latência com volumes consistentes com falhas para garantir a perda de dados zero ao nível do sistema de ficheiros durante uma falha.
  • A replicação assíncrona espelha os dados em sites além dos intervalos metropolitanos através de ligações de rede com latências mais elevadas, mas sem a garantia de que ambos os sites têm cópias idênticas dos dados no momento de uma falha. Se a replicação for concluída antes da falha, o volume de destino fica online automaticamente após a ativação pós-falha. Se a replicação estiver em processo no momento da falha, tem de colocar manualmente o volume de destino online.

Existem dois tipos de clusters dispersos, ativo-passivo e ativo-ativo. Pode configurar a replicação de site ativo-passivo, onde existe um site preferencial e uma direção para a replicação. A replicação ativa-ativa é onde a replicação pode ocorrer bidirecionalmente a partir de qualquer um dos sites. Este artigo abrange apenas a configuração ativa/passiva.

Em termos simples, um site ativo é um site que tem recursos e está a fornecer funções e cargas de trabalho para os clientes se ligarem. Um site passivo é aquele que não fornece quaisquer funções ou cargas de trabalho para clientes e está à espera de uma ativação pós-falha do site ativo para recuperação após desastre.

Os sites podem estar em dois estados diferentes, cidades diferentes, pisos diferentes ou salas diferentes. Os clusters dispersos que utilizam dois sites fornecem recuperação após desastre e continuidade de negócio caso um site sofra uma falha ou falha.

Dedique alguns minutos para watch o vídeo sobre clustering disperso com o Azure Stack HCI:

Cluster disperso ativo-passivo

O diagrama seguinte mostra o Site 1 como o site ativo com replicação para o Site 2, uma replicação unidirecional.

Cenário de cluster disperso ativo/passivo.

Cluster disperso ativo-ativo

O diagrama seguinte mostra o Site 1 e o Site 2 como sites ativos, com replicação bidirecional para o outro site.

Cenário de cluster disperso ativo/ativo

Considerações sobre a ativação pós-falha do IP convidado

Ao falar sobre clustering disperso, uma das considerações que têm de ser contabilizadas são as máquinas virtuais e os endereços IP que estão a ser utilizados. Geralmente, os datacenters que residem em localizações diferentes têm sub-redes IP diferentes. Os endereços IP que as máquinas virtuais utilizam seriam bons para um datacenter, mas inacessíveis noutro. Por conseguinte, o planeamento de como lidar com as alterações de endereços IP tem de ser contabilizado. Na maior parte das vezes, existem quatro formas diferentes de lidar com a alteração do endereço IP na máquina virtual na ativação pós-falha. Podem existir outros, mas este documento abrangerá os quatro primeiros.

A primeira e mais fácil é a utilização de DHCP. Ao mover uma máquina virtual de um site para outro, um passo que irá fazer é pedir um endereço DHCP. Esta ação obterá o Endereço IP adequado para o site adequado em que se encontra, desde que esteja disponível um servidor DHCP.

Em seguida, há a utilização de um endereço estático. No entanto, ao contrário da Réplica do Hyper-V, não existe uma forma de especificar um endereço IP alternativo. Por conseguinte, terá de ser criado um script para atribuir o endereço IP adequado para a VM, consoante o site em que se encontra. Por exemplo, o SiteA utiliza uma rede 1.x e o SiteB utiliza uma rede 156.x. Este script teria de detetar a rede na qual a máquina virtual está ativada e definir um esquema de endereços IP 1.x se estiver no SiteA ou num esquema de endereços IP 156.x se estiver no SiteB. Os Serviços de Nomes de Domínio (DNS) também terão de ser alertados para a alteração e replicados entre os sites.

Outra opção é a utilização de um dispositivo de rede intermediário que fornecerá um único endereço IP para a máquina virtual para conectividade de cliente, que pode encaminhar o tráfego para a máquina virtual para o site onde se encontra atualmente. Os clientes e o DNS terão sempre o mesmo endereço para a máquina virtual e o dispositivo intermediário terá de controlar o endereço IP real e a localização da máquina virtual para que os clientes sejam direcionados adequadamente para a máquina virtual.

A última opção é a utilização de uma vLAN esticada. Com uma vLAN esticada, as máquinas virtuais podem manter o mesmo endereço IP independentemente do site onde se encontra. No entanto, devido a algumas das complexidades de configurar e manter uma vLAN esticada, esta opção não é recomendada pela Microsoft.

Com qualquer uma das opções acima, as considerações adicionais (DNS, caches do ARP, TTL, etc.) têm de ser contabilizadas no que diz respeito à conectividade do cliente e têm de ser cuidadosamente pensadas. Trabalhe com a sua equipa de rede para identificar a melhor opção para satisfazer as suas necessidades.

Passos seguintes