Compartilhar via


Visão geral de clusters estendidos

Aplica-se a: Azure Local, versão 22H2

Importante

O Azure Stack HCI agora faz parte do Azure Local. A renomeação da documentação do produto está em andamento. No entanto, as versões mais antigas do Azure Stack HCI, por exemplo, 22H2, continuarão a fazer referência ao Azure Stack HCI e não refletirão a alteração de nome. Saiba mais.

Importante

Não há suporte para clusters estendidos no Azure Local, versão 23H2.

Uma solução de cluster estendido do Azure Stack HCI para recuperação de desastre fornece failover automático 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 de desastres, com todos os servidores permanecendo em sincronia.

A Réplica de Armazenamento oferece suporte à replicação síncrona e assíncrona:

  • A replicação síncrona espelha dados entre sites em uma rede de baixa latência com volumes consistentes com falhas para garantir perda zero de dados no nível do sistema de arquivos durante uma falha.
  • A replicação assíncrona espelha dados entre sites além dos intervalos metropolitanos em links de rede com latências mais altas, mas sem garantia de que ambos os sites tenham 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 ficará online automaticamente após o failover. Se a replicação estiver em andamento no momento da falha, você deverá colocar manualmente o volume de destino online.

Existem dois tipos de clusters estendidos, ativo-passivo e ativo-ativo. Você pode configurar a replicação de site ativo-passivo, onde há um site e uma direção preferenciais para replicação. A replicação ativa-ativa é onde a replicação pode acontecer bidirecionalmente de qualquer site. Este artigo aborda apenas a configuração ativa/passiva.

Em termos simples, um site ativo é aquele que tem recursos e fornece funções e cargas de trabalho para os clientes se conectarem. Um site passivo é aquele que não fornece nenhuma função ou carga de trabalho para clientes e está aguardando um failover do site ativo para recuperação de desastre.

Os sites podem estar em dois estados diferentes, cidades diferentes, andares diferentes ou salas diferentes. Os clusters estendidos que usam dois sites fornecem recuperação de desastres e continuidade dos negócios caso um site sofra uma interrupção ou falha.

Reserve alguns minutos para assistir ao vídeo sobre clustering estendido com o Azure Stack HCI:

Cluster estendido ativo-passivo

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

Cenário de cluster estendido ativo/passivo.

Cluster estendido ativo-ativo

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

Cenário de cluster estendido ativo/ativo

Considerações sobre failover de IP convidado

Ao falar sobre clustering estendido, uma das considerações que devem ser levadas em consideração são as máquinas virtuais e os endereços IP que estão sendo usados. Os datacenters que residem em locais diferentes geralmente têm sub-redes IP diferentes. Os endereços IP que as máquinas virtuais usam seriam bons para um datacenter, mas inacessíveis em outro. Portanto, o planejamento de como lidar com as alterações de endereço IP deve ser levado em consideração. Normalmente, há quatro maneiras diferentes de lidar com a alteração do endereço IP na máquina virtual no failover. Pode haver outros, mas este artigo cobre os quatro primeiros.

O primeiro e mais fácil é o uso de DHCP. Ao mover uma máquina virtual de um site para outro, a VM solicita um endereço DHCP. Isso obtém o endereço IP adequado para o site em que está, desde que um servidor DHCP esteja disponível.

Em seguida, há o uso de um endereço estático. No entanto, ao contrário da Réplica do Hyper-V, não há uma maneira de especificar um endereço IP alternativo. Portanto, um script deve ser criado para atribuir o endereço IP adequado para a VM, dependendo do site em que ela está. Por exemplo, o SiteA usa uma rede 1.x e o SiteB usa uma rede 156.x. Esse script precisa detectar a rede em que a máquina virtual está e definir um esquema de endereço IP 1.x se estiver no SiteA ou um esquema de endereço IP 156.x se estiver no SiteB. O DNS (Serviços de Nomes de Domínio) também precisa ser alertado sobre a alteração e replicado entre os sites.

Outra opção é o uso de um dispositivo de rede intermediário que fornece um único endereço IP para a máquina virtual para conectividade do cliente, que pode rotear o tráfego para a máquina virtual. Os clientes e o DNS sempre têm o mesmo endereço para a máquina virtual, e o dispositivo intermediário precisa rastrear o endereço IP real e o local da máquina virtual para que os clientes sejam direcionados para a máquina virtual adequadamente.

A última opção é o uso de uma vLAN estendida. Com uma vLAN estendida, as máquinas virtuais podem manter o mesmo endereço IP, independentemente do site em que estejam. No entanto, devido a algumas das complexidades de configurar e manter uma vLAN estendida, essa opção não é recomendada pela Microsoft.

Com qualquer uma das opções acima, considerações adicionais (DNS, caches ARP, TTL, etc.) precisam ser levadas em consideração quando se trata de conectividade do cliente e devem ser cuidadosamente pensadas. Trabalhe com sua equipe de rede para identificar a melhor opção para atender às suas necessidades.

Próximas etapas