Visão geral dos aglomerados esticados

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

Uma solução de cluster esticado Azure Stack HCI para a recuperação de desastres proporciona falhas automáticas para restaurar a produção rapidamente, e sem a necessidade de intervenção manual. Armazenamento Replica fornece a replicação de volumes em sites para recuperação de desastres, com todos os servidores a permanecerem sincronizados.

Armazenamento Replica suporta a replicação sincronizada e assíncronea:

  • A replicação sincronizada espelha dados em todos os sites numa rede de baixa latência com volumes consistentes com falhas para garantir a perda zero de dados ao nível do sistema de ficheiros durante uma falha.
  • Replicação assíncrona permite o espelhamento de dados em todos os sites para além dos intervalos de metrópole através de ligações de rede com latências superiores, mas sem uma garantia de os sites têm cópias idênticas dos dados no momento de uma falha.

Nota

Para uma replicação assíncronea, você precisa trazer volumes de destino no outro site on-line manualmente após o failover. Para mais informações, consulte a replicação assíncronea.

Existem dois tipos de aglomerados esticados, ativos passivos e ativos. Pode configurar a replicação do site passivo ativo, onde existe um local preferido e uma direção para a replicação. A replicação ativa é onde a replicação pode acontecer bi-direcionalmente a partir de qualquer um dos sites. Este artigo cobre apenas a configuração ativa/passiva.

Em termos simples, um site ativo é aquele que tem recursos e está a fornecer papéis e cargas de trabalho para os clientes se conectarem. Um site passivo é aquele que não fornece quaisquer papéis ou cargas de trabalho para os clientes e está à espera de uma falha do local ativo para a recuperação de desastres.

Os locais podem estar em dois estados diferentes, cidades diferentes, pisos diferentes ou quartos diferentes. Aglomerados esticados usando dois locais proporcionam recuperação de desastres e continuidade de negócios em caso de um site sofrer uma paragem ou falha.

Dedique alguns minutos a ver o vídeo em agrupamento esticado com Azure Stack HCI:

Aglomerado esticado activo-passivo

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

Active/passive stretched cluster scenario

Cluster esticado ativo

O diagrama seguinte mostra tanto o Site 1 como o Site 2 como sendo locais ativos, com replicação bidirecional para o outro local.

Active/active stretched cluster scenario

Considerações de failover do IP do hóspede

Quando se fala de agrupamento de alongamentos, uma das considerações que devem ser contabilizadas são as máquinas virtuais e os endereços IP que estão a ser utilizados. Os datacenters que residem em diferentes locais geralmente têm diferentes sub-redes IP. O IP endereça a utilização de máquinas virtuais seria bom para um datacenter, mas inacessível noutro. Por conseguinte, o planeamento de como lidar com as alterações do endereço IP deve ser contabilizado. Na maior parte das vezes, existem quatro maneiras diferentes de lidar com a alteração do endereço IP na máquina virtual em falha. Pode haver outros, mas este documento cobrirá 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 é solicitar um endereço DHCP. Isto obterá o endereço IP adequado para o site adequado em que esteja disponível em enquanto um servidor DHCP estiver disponível.

Em seguida, há o uso de um endereço estático. No entanto, ao contrário da Réplica Hiper-V, não existe uma forma de especificar um endereço IP alternativo. Portanto, será necessário criar um script para atribuir o endereço IP adequado para o VM, dependendo do site em que se encontra. Por exemplo, o SiteA utiliza uma rede de 1.x e o SiteB utiliza uma rede de 156.x. Este script teria de detetar a rede em que a máquina virtual está acesa e definir um esquema de endereço IP de 1.x se estiver no SiteA ou num esquema de endereço IP de 156.x se estiver no SiteB. Os Serviços de Nome de Domínio (DNS) também terão de ser informados da 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 a conectividade do cliente que pode encaminhar o tráfego para a máquina virtual para o site em que se encontra atualmente. Os clientes e DNS terão sempre o mesmo endereço para a máquina virtual, e o dispositivo intermediário teria de rastrear o endereço IP real e a localização da máquina virtual para que os clientes sejam direcionados para a máquina virtual adequadamente.

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

Com qualquer uma das opções acima, considerações adicionais (DNS, caches ARP, TTL, etc.) precisam de ser contabilizados quando se trata de conectividade com o cliente e devem ser cuidadosamente pensados. Por favor, trabalhe com a sua equipa de networking para identificar a melhor opção para atender às suas necessidades.

Passos seguintes