Editar

Utilizar clusters dispersos do Azure Stack HCI para recuperação após desastre

Azure Blob Storage
Azure Backup
Azure Monitor
Azure Stack HCI

A seguinte arquitetura de referência ilustra como conceber e implementar a recuperação após desastre do Azure Stack HCI com clustering disperso.

Arquitetura

Diagrama que ilustra um cluster disperso ativo-ativo e ativo-passivo do Azure Stack HCI, com volumes de armazenamento e histórico de desempenho do cluster a replicar através da Réplica de Armazenamento. No modo ativo-ativo, existe tráfego de replicação em cada direção, com ambos os sites a alojar VMs do Azure Stack HCI. No modo ativo-passivo, a replicação é unidirecional, com o site ativo a alojar VMs do Azure Stack HCI.

Transfira um ficheiro do Visio desta arquitetura.

Componentes

A arquitetura incorpora os seguintes componentes e capacidades:

  • Azure Stack HCI (20H2). O Azure Stack HCI é uma solução de cluster de infraestrutura hiperconvergida (HCI) que aloja cargas de trabalho virtualizadas do Windows e linux e o respetivo armazenamento num ambiente híbrido no local. O cluster disperso pode consistir entre quatro e 16 nós físicos.
  • Réplica de Armazenamento. A Réplica de Armazenamento é uma tecnologia do Windows Server que permite a replicação de volume entre servidores ou clusters para efeitos de recuperação após desastre.
  • Migração em direto. A migração em direto é uma funcionalidade do Hyper-V no Windows Server que lhe permite mover facilmente máquinas virtuais (VMs) em execução de um anfitrião Hyper-V para outro sem tempo de inatividade percebido.
  • Testemunho de Nuvem. O Testemunho de Cloud é um testemunho de quórum do Cluster de Ativação Pós-falha que utiliza o Microsoft Armazenamento de Blobs do Azure para fornecer uma votação sobre o quórum do cluster.

Detalhes do cenário

Normalmente, utiliza esta arquitetura para recuperação após desastre com ativação pós-falha automática de VMs do Azure Stack HCI e partilhas de ficheiros entre duas localizações físicas num intervalo de 5 ms de latência de rede de ida e volta.

Recomendações

A seguinte recomendação aplica-se à maioria dos cenários. Siga a recomendação, a menos que tenha um requisito específico que a substitua.

Utilizar clusters dispersos para implementar a recuperação após desastre automatizada para cargas de trabalho virtualizadas e partilhas de ficheiros alojadas no Azure Stack HCI

Para melhorar a resiliência incorporada do Azure Stack HCI, implemente um cluster do Azure Stack HCI disperso que consiste em dois grupos de nós, com um grupo por site. Cada grupo tem de conter um mínimo de dois nós. O número total de nós num cluster não pode exceder o número máximo de nós suportados por um cluster do Azure Stack HCI. Os nós têm de satisfazer os requisitos de hardware do HCI padrão.

Um cluster disperso do Azure Stack HCI depende da Réplica de Armazenamento para executar a replicação de armazenamento síncrona entre volumes de armazenamento alojados pelos dois grupos de nós nos respetivos sites físicos. Se uma falha afetar a disponibilidade do site primário, o cluster transita automaticamente as cargas de trabalho para os nós no site sobrevivente para minimizar potenciais períodos de indisponibilidade. Para períodos de indisponibilidade planeados ou esperados no site primário, pode utilizar a Migração em Direto do Hyper-V para efetuar a transição totalmente integrada de cargas de trabalho para o outro site, evitando completamente o tempo de inatividade. Para este cenário, deve estar atento à localização de armazenamento. Primeiro, deve inverter a direção de replicação para a Réplica de Armazenamento e, em seguida, executar a Migração em Direto das VMs. Haverá um impacto no desempenho até que a Migração em Direto seja concluída.

Nota

A replicação síncrona garante a consistência da falha sem perda de dados ao nível do sistema de ficheiros durante uma ativação pós-falha.

Atenção

O requisito de replicação síncrona aplicável aos clusters dispersos impõe um limite de 5 ms de latência de rede de ida e volta entre dois grupos de nós de cluster nos sites replicados. Dependendo das características de conectividade de rede física, esta restrição normalmente traduz-se em cerca de 20 a 30 milhas físicas.

Nota

A capacidade de assinatura e encriptação da Réplica de Armazenamento protege automaticamente o tráfego de replicação.

Considerações

O Microsoft Azure Well-Architected Framework é um conjunto de princípios orientadores que são seguidos nesta arquitetura de referência. As seguintes considerações são enquadradas no contexto destes princípios.

Fiabilidade

A fiabilidade garante que a sua aplicação cumpre os compromissos assumidos com os seus clientes. Para obter mais informações, veja Descrição geral do pilar de fiabilidade.

  • Domínios de falha ao nível do site. Cada site físico de um cluster disperso do Azure Stack HCI representa domínios de falha distintos que proporcionam resiliência adicional. Um domínio de falha é um conjunto de componentes de hardware que partilham um único ponto de falha. Para ser tolerante a falhas a um determinado nível, precisa de vários domínios de falha nesse nível.

Nota

Se cada localização corresponder a um site do AD DS separado, o processo de aprovisionamento do cluster configura automaticamente a atribuição de sites. Se não existirem sites do AD DS separados que representem as duas localizações, mas os nós estiverem em duas sub-redes diferentes, o processo de aprovisionamento do cluster identificará os sites com base nas atribuições de sub-rede. Se os nós estiverem na mesma sub-rede, tem de definir explicitamente a atribuição de sites.

  • Sensibilização do site. A deteção de sites permite-lhe controlar a colocação de cargas de trabalho virtualizadas ao designar os respetivos sites preferidos. Especificar o site preferencial para um cluster disperso oferece muitas vantagens, incluindo a capacidade de agrupar cargas de trabalho ao nível do site e personalizar as opções de voto do quórum. Por predefinição, durante um arranque a frio, todas as máquinas virtuais utilizam o site preferencial, embora também seja possível configurar o site preferencial ao nível da função de cluster ou do grupo. Isto permite-lhe alocar máquinas virtuais específicas aos respetivos sites no modo ativo-ativo. Do ponto de vista do quórum, a seleção do site preferencial afeta a alocação de votos de uma forma que favorece esse site. Por exemplo, se a conectividade entre os dois sites que alojam nós de cluster dispersos falhar e o testemunho de cluster não estiver acessível, o site preferencial permanece online, enquanto os nós no outro site são expulsos.

  • Melhoria Espaços de Armazenamento Direto velocidade de reparação do volume. Espaços de Armazenamento Direto fornece eventos de ressincronização automática que afetam a disponibilidade de discos no respetivo agrupamento de armazenamento, como encerrar um dos nós de cluster ou uma falha de hardware localizada. O Azure Stack HCI implementa um processo de ressincronização melhorado que funciona com uma granularidade muito mais fina do que o Windows Server 2019. Este processo reduz significativamente a duração da operação de ressincronização e minimiza o impacto potencial de várias falhas de hardware sobrepostas.

  • Limites de resiliência. O Azure Stack HCI fornece vários níveis de resiliência, mas devido à sua arquitetura hiperconvergida, essa resiliência está sujeita a limites impostos não só pelo quórum do cluster, mas também pelo quórum do conjunto.

  • Integração com uma variedade de serviços do Azure que proporcionam vantagens de resiliência adicionais. Pode integrar cargas de trabalho virtualizadas em execução em clusters do Azure Stack HCI com serviços do Azure como Azure Backup e Site Recovery do Azure.

  • Ativação pós-falha acelerada. Pode otimizar a infraestrutura de rede e a respetiva configuração para acelerar a conclusão de uma ativação pós-falha ao nível do site. Por exemplo, pode tirar partido de LANs virtuais (VLANs) dispersas, dispositivos de abstração de rede e valores TTL (Time to Live) mais curtos em registos DNS que representam recursos em cluster. Além disso, considere reduzir o período de resiliência predefinido, que determina o período de tempo durante o qual uma VM em cluster tem permissão para ser executada no estado isolado.

Atenção

A utilização de clusters dispersos com SDN é considerada uma configuração avançada e deve contactar o Seu Integrador de Sistemas ou Suporte da Microsoft para obter mais assistência.

Segurança

A segurança fornece garantias contra ataques deliberados e abuso dos seus valiosos dados e sistemas. Para obter mais informações, veja Descrição geral do pilar de segurança.

  • Proteção em trânsito. A Réplica de Armazenamento oferece segurança incorporada para o tráfego de replicação, que inclui assinatura de pacotes, encriptação de dados completa AES-128-GCM, suporte para aceleração de encriptação Intel AES-NI e prevenção de ataques man-in-the-middle de integridade de pré-autenticação. A Réplica de Armazenamento também utiliza o Kerberos AES256 para autenticação entre os nós de replicação.

  • Encriptação inativa. O Azure Stack HCI suporta a Encriptação de Unidade BitLocker para os seus volumes de dados, facilitando assim a conformidade com normas como FIPS 140-2 e HIPAA.

  • Integração com uma variedade de serviços do Azure que proporcionam vantagens de segurança adicionais. Pode integrar cargas de trabalho virtualizadas em execução em clusters do Azure Stack HCI com serviços do Azure como Microsoft Defender para a Cloud

  • Configuração compatível com a firewall. O tráfego da Réplica de Armazenamento requer um número limitado de portas abertas entre os nós de replicação.

Atenção

A Réplica de Armazenamento e os clusters dispersos do Azure Stack HCI têm de funcionar num ambiente do AD DS. Ao planear a implementação de clusters dispersos do Azure Stack HCI, garanta a conectividade aos controladores de domínio do AD DS em cada site que aloja nós de cluster.

Otimização de custos

A otimização de custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, veja Descrição geral do pilar de otimização de custos.

  • Configuração ativa-ativa versus ativa-passiva. Os clusters dispersos do Azure Stack HCI suportam os modos ativo-passivo e ativo-ativo. No modo ativo-passivo, um site primário designado é replicado de forma unidirecional para outro site que fornece a capacidade de recuperação após desastre. No modo ativo-ativo, dois sites replicam os respetivos volumes unidirecionalmente entre si, fornecendo a capacidade de ativação pós-falha em caso de falha em qualquer um dos sites. O modo ativo-ativo ajuda a minimizar os custos de continuidade do negócio ao eliminar a necessidade de um site de recuperação após desastre dedicado.

  • Testemunho de Nuvem versus Testemunho de Partilha de Ficheiros. Um recurso testemunha é um componente obrigatório nos clusters do Azure Stack HCI. Para implementá-lo, escolha um testemunho da cloud do Azure ou um testemunho de partilha de ficheiros. Um testemunho da cloud do Azure baseia-se num blob numa conta de armazenamento do Azure que designa como o ponto de arbitragem para impedir cenários de dividir o cérebro. Um testemunho de partilha de ficheiros baseia-se numa partilha de ficheiros do Server Message Block (SMB) para atingir o mesmo objetivo.

Nota

O Azure Cloud Witness é a opção recomendada para clusters dispersos do Azure Stack HCI, desde que todos os nós de servidor no cluster tenham ligações fiáveis à Internet. Os custos do Azure correspondentes são insignificantes; baseiam-se no preço de um pequeno blob com atualizações pouco frequentes correspondentes a alterações ao estado do cluster. Em cenários que envolvam clusters dispersos, um testemunho de partilha de ficheiros deve residir num terceiro site, o que pode aumentar significativamente os custos de implementação, a menos que o terceiro site já esteja disponível e tenha ligações fiáveis e existentes aos sites que alojam os nós de cluster dispersos.

  • Eliminação de Dados Duplicados. O Azure Stack HCI e a Réplica de Armazenamento suportam a eliminação de dados duplicados. A partir do Windows Server 2019, a eliminação de duplicados está disponível em volumes formatados com o Sistema de Ficheiros Resiliente (ReFS), que é o sistema de ficheiros recomendado para o Azure Stack HCI. A eliminação de duplicados ajuda a aumentar a capacidade de armazenamento utilizável ao identificar partes duplicadas de ficheiros e apenas armazená-los uma vez.

Atenção

Embora deva instalar o serviço de função de servidor de Eliminação de Dados Duplicados nos servidores de origem e de destino, não ative a Eliminação de Dados Duplicados nos nós de destino num cluster disperso do Azure Stack HCI. Uma vez que a Eliminação de Dados Duplicados gere as escritas, deve ser executada apenas em nós de cluster de origem. Os nós de destino recebem sempre cópias duplicadas de cada volume.

Excelência operacional

A excelência operacional abrange os processos de operações que implementam uma aplicação e a mantêm em execução em produção. Para obter mais informações, veja Descrição geral do pilar de excelência operacional.

  • Ativação pós-falha automática e recuperação. Uma falha do site primário aciona a ativação pós-falha automática. Após a ativação pós-falha, o processo de estabelecer a replicação a partir do novo site primário/antigo secundário de volta ao novo site primário secundário/antigo também é automático. Para evitar potenciais perdas de dados, o cluster impede a reativação pós-falha até que os volumes replicados sejam totalmente sincronizados.

  • Experiência de aprovisionamento e gestão simplificada com Windows Admin Center. O assistente Criar Cluster no Windows Admin Center fornece uma interface orientada pelo assistente que o orienta ao longo do processo de criação de um cluster disperso do Azure Stack HCI. O assistente deteta se os nós de cluster residem em dois sites de Active Directory Domain Services distintos (AD DS) ou se os respetivos endereços IP pertencem a duas sub-redes diferentes. Se residirem em duas sub-redes diferentes, o assistente cria e configura automaticamente os sites de cluster correspondentes com cada um a representar um domínio de falha separado. Também lhe permite designar o site preferencial. Da mesma forma, Windows Admin Center simplifica o processo de aprovisionamento de volumes replicados.

Nota

A criação de volumes e discos virtuais para clusters dispersos está mais envolvida do que em clusters de sites únicos. Os clusters dispersos requerem um mínimo de quatro volumes, compostos por dois volumes de dados e dois volumes de registo, com um par de volumes de dados/registo em cada site. Quando cria um volume de dados replicado com Windows Admin Center, o processo aprovisiona automaticamente o volume de registo no site primário e os volumes replicados de dados e registos no site secundário, garantindo que cada um deles tem o tamanho e as definições de configuração necessários.

  • Suporte para a gestão de armazenamento e aprovisionamento de clusters disperso automatizado com Windows PowerShell. Pode executar o PowerShell localmente a partir de um dos servidores do Azure Stack HCI ou remotamente a partir de um computador de gestão.

  • Integração com uma gama de serviços do Azure que proporcionam vantagens operacionais adicionais. Pode integrar cargas de trabalho virtualizadas em execução em clusters do Azure Stack HCI com serviços do Azure como o Azure Monitor e soluções de Automatização do Azure, incluindo Registo de Alterações e Inventário e Gestão de Atualizações. Ao seguir um procedimento de registo obrigatório inicial, os clusters do Azure Stack HCI podem tirar partido do Azure Arc para monitorização e faturação. A integração do Azure Arc oferece uma integração melhorada com outros serviços híbridos, como o Azure Policy e o Log Analytics. O registo aciona a criação de um recurso do Azure Resource Manager que representa um cluster do Azure Stack HCI, expandindo efetivamente o plano de gestão do Azure para o Azure Stack HCI.

Eficiência de desempenho

Eficiência de desempenho é a capacidade da sua carga de trabalho para dimensionar para satisfazer as exigências que os utilizadores lhe colocam de forma eficiente. Para obter mais informações, veja Descrição geral do pilar Eficiência do desempenho.

  • Tráfego de replicação otimizado. Ao conceber a infraestrutura para clusters dispersos do Azure Stack HCI, considere o tráfego adicional de Réplica de Armazenamento, Migração Em Direto e Histórico de Desempenho do Cluster de Réplica de Armazenamento que flui entre os sites. A replicação síncrona requer, pelo menos, 1 Gb de acesso remoto direto à memória (RDMA) ou ligação Ethernet/TCP entre sites de cluster dispersos. No entanto, dependendo do volume de tráfego de replicação, poderá precisar de uma ligação RDMA mais rápida. Também deve aprovisionar várias ligações entre sites, o que proporciona benefícios de resiliência e permite separar o tráfego da Réplica de Armazenamento do tráfego de migração em direto do Hyper-V.

Atenção

O RDMA está ativado por predefinição para todo o tráfego entre nós de cluster no mesmo site na mesma sub-rede. O RDMA está desativado e não é suportado entre sites ou entre sub-redes diferentes. Deve desativar o SMB Direto para tráfego entre sites ou implementar disposições adicionais que a separam do tráfego entre nós no mesmo site.

Nota

Windows Admin Center atribui automaticamente a configuração ideal se a utilizar para aprovisionar volumes de cluster dispersos.

Passos seguintes