Continuidade dos negócios e recuperação de desastres para a Solução VMware no Azure
Esse cenário de escala empresarial ajuda a melhorar a continuidade de negócios e a recuperação de desastres (BCDR). A Solução VMware do Azure fornece nuvens privadas que contêm clusters VMware vSphere criados a partir de infraestrutura bare-metal dedicada do Azure. A solução fornece um mínimo de três hosts ESXi, até um máximo de 16 hosts por cluster. Todas as nuvens privadas provisionadas têm VMware vCenter Server, o VMware vSAN, o VMware vSphere e o Data Center do VMware NSX-T. Para saber mais sobre o contrato de nível de serviço (SLA) para a Solução VMware do Azure, consulte SLA para a Solução VMware do Azure.
Se você tiver uma solução local ou VMware do Azure, você deve considerar vários fatores BCDR para se preparar para um desastre. Um plano BCDR robusto visa proteger uma empresa contra perda de dados, perda financeira e tempo de inatividade se houver um evento disruptivo. A árvore de decisão a seguir mostra várias opções de BCDR disponíveis para a Solução VMware do Azure.
Observação
Um ambiente de luz piloto é configurado com uma configuração mínima, com apenas componentes principais para suportar um conjunto crítico de aplicativos. No entanto, ele pode expandir e gerar mais hosts para receber a maior parte da carga se ocorrer um failover. Para recuperação de desastres de cargas de trabalho de solução VMware do Azure com uso intensivo de computação e memória, a mesma quantidade de armazenamento é necessária no local secundário.
Considerações de design de continuidade de negócios
As políticas de armazenamento vSAN do VMware na Solução VMware no Azure são implementadas pensando na disponibilidade de armazenamento. Quando o cluster tem entre três e cinco hosts, o número de falhas de host que podem ser toleradas sem perda de dados é igual a um. Quando um cluster tem entre 6 e 16 hosts, o número de falhas de host a tolerar antes que a perda de dados possa ocorrer é igual a dois. As políticas de armazenamento vSAN do VMware podem ser aplicadas por VM. Embora essas políticas sejam o padrão, você pode alterá-la para atender aos requisitos personalizados. Para obter mais informações, confira Conceitos de armazenamento da Solução VMware no Azure.
A alta disponibilidade do vSphere é habilitada por padrão na Solução VMware do Azure. A política de admissão de alta disponibilidade reserva capacidade de computação e memória para um único nó. Essa reserva garante capacidade suficiente para reiniciar cargas de trabalho em outro nó em um cluster de Solução VMware do Azure.
Alta disponibilidade com cluster stretch: com a Solução VMware do Azure, os hosts ESXi implantados em um cluster vSphere padrão tradicionalmente residem em uma única zona de disponibilidade do Azure e são protegidos pela alta disponibilidade do vSphere. No entanto, as cargas de trabalho não são protegidas contra uma falha na zona de disponibilidade. Para proteger contra falhas, um único cluster vSAN pode abranger duas zonas de disponibilidade separadas, chamadas de cluster estendido vSAN. Para obter mais informações, consulte Implantar clusters estendidos vSAN.
Escolha uma solução de backup validada para as máquinas virtuais (VMs) VMware vSphere, como o Servidor de Backup do Microsoft Azure ou uma solução de backup de parceiro.
Para obter informações sobre os recursos suportados em soluções de backup de parceiros, consulte a respectiva documentação do parceiro.
Observação
As configurações do vCenter Server e do NSX-T Data Center para nuvens privadas são armazenadas em backup de hora em hora e os backups são mantidos por três dias.
Os componentes da Solução VMware do Azure, como o vCenter Server, o NSX-T Manager ou o HCX Manager, são serviços gerenciados para os quais o Azure gerencia o backup. Para restaurar a partir de um backup, crie uma solicitação de Suporte do Azure.
Recomendações de design de continuidade de negócios
Use o Servidor de Backup do Azure para fazer backup da nuvem privada da Solução VMware do Azure. Para obter mais informações, consulte Fazer backup de VMs VMware vSphere com o Backup do Azure. As topologias de implantação com suporte incluem o Agente MARS e o Data Protection Manager. Cada topologia de implantação tem sua própria matriz de suporte, restrições e limitações.
Implante o Servidor de Backup do Azure na mesma região do Azure que a nuvem privada da Solução VMware no Azure. Esse método de implantação reduz os custos de tráfego, facilita a administração e mantém a topologia primária/ secundária. Consulte o guia de seleção de regiões do Azure para conhecer as práticas recomendadas de implantação de região do Azure.
O Backup do Azure pode ser implantado como uma VM de IaaS (infraestrutura como serviço) do Azure ou na nuvem privada da Solução VMware do Azure. É altamente recomendável implantá-lo fora da nuvem privada da Solução VMware do Azure. Implante o Backup em uma rede virtual do Azure e verifique se essa rede virtual está conectada à mesma Rota Expressa conectada à nuvem privada da Solução VMware do Azure. Executar o Servidor de Backup fora da nuvem privada da Solução VMware do Azure ajuda a reduzir o consumo de vSAN, já que o vSAN é um recurso de capacidade limitada na nuvem privada da Solução VMware do Azure.
Servidor de Backup do Azure implantado como uma VM IaaS do Azure.
Servidor de Backup do Azure implantado como uma VM de Solução VMware do Azure.
Use a lista de verificação de requisitos de desempenho do aplicativo para chegar à capacidade e ao tipo de disco corretos, como HDD, SSD ou Ultra. Considere a SKU da VM IaaS do Azure que dá suporte ao tipo de disco e à capacidade para operações de backup.
Use o planejador de capacidade do Servidor de Backup do Azure para determinar o número de servidores, armazenamento e requisitos de IOPS para cada um deles. Ao fornecer o valor "Tamanho total da carga de trabalho (GB)*" no planejador de capacidade, use o valor médio entre "armazenamento usado" e "armazenamento alocado" de todas as VMs no vCenter das quais você deseja fazer backup.
Use pools de armazenamento com o Servidor de Backup do Azure para IOPS/taxa de transferência de disco aprimorada. Use o armazenamento hierárquico no Servidor de Backup para operações aprimoradas. Defina o valor de configuração DisableWriteAutoTiering como 1 no volume MABS para que toda a camada de desempenho esteja disponível para armazenar metadados do ReFS.
Identifique o número de trabalhos de backup paralelos e operações de restauração a serem executados no servidor de Backup do Azure. Atualmente, há suporte para oito trabalhos de backup paralelos. Meça o tempo necessário para fazer backup e restaurar cargas de trabalho de missão crítica em várias execuções. Valide se os tempos de backup e restauração atendem aos requisitos de RPO e RTO para o servidor de Backup do Azure. Verifique se o armazenamento de dados do AVS vSAN tem capacidade suficiente para manter o backup restaurado.
Adicione as exceções de Antivírus necessárias para arquivos e pastas do Servidor de Backup do Azure, conforme documentado aqui , se qualquer software Antivírus/Antimalware for executado no Servidor de Backup do Azure. Ao usar o agente de proteção do DPM em qualquer VM de solução VMware do Azure para backup de aplicativos (por exemplo, SQL, Sharepoint, etc.), desabilite o monitoramento em tempo real de dpmra.exe.
Configure as regras NSG (Grupo de Segurança de Rede) apropriadas na sub-rede que hospeda o Servidor de Backup do Azure para permitir a comunicação de rede do agente de proteção do DPM em execução na VM protegida na Solução VMware do Azure. O agente de proteção do DPM se comunica com o Servidor de Backup do Azure em qualquer porta dinâmica entre 1024 e 65535.
Atualmente, o Servidor de Backup do Azure não oferece suporte à restauração entre regiões para a nuvem privada da Solução VMware do Azure. Consulte a seção Soluções de backup de parceiros e recuperação de desastres quando a recuperação da Solução VMware do Azure entre regiões for necessária.
Considerações de design de recuperação de desastre
Alinhe os requisitos de negócios com os objetivos de tempo de recuperação (RTO), capacidade e RPO (Recovery Point Objectives, objetivos de ponto de recuperação) para aplicativos. Planeje e projete de acordo para atingir esses objetivos usando a tecnologia de replicação mais apropriada. Por exemplo, replique nativamente bancos de dados SQL usando o grupo de disponibilidade SQL Always On ou use uma ferramenta de recuperação de desastres, como o VMware Site Recovery Manager.
Determine o site de recuperação de desastres de destino para a nuvem privada protegida da Solução VMware do Azure. Esse site influencia quais ferramentas de recuperação de desastres são adequadas para o ambiente. Por exemplo, se você quiser recuperar cargas de trabalho da Solução VMware do Azure para máquinas virtuais IaaS nativas do Azure, considere o Azure Site Recovery ou o Zerto.
Determine qual subconjunto de cargas de trabalho da Solução VMware do Azure requer proteção se houver um evento de recuperação de desastre. Considere categorizar as cargas de trabalho com base na prioridade: P0 para cargas de trabalho críticas para os negócios e P1, P2, P3 para outras cargas de trabalho que são importantes, mas não tão críticas para a operação dos negócios. O plano de continuidade de negócios do cliente define os níveis de prioridade, o que ajuda a controlar os custos associados à implementação da recuperação de desastres.
Na maioria dos casos, ambientes de não produção, como desenvolvimento, teste ou UAT, não precisam fazer failover para um site secundário. Você deve executar a luz piloto no local secundário com capacidade reduzida para produção e cargas de trabalho críticas para economizar custos. Para obter mais capacidade, você pode expandir para adicionar hosts ESXi ao cluster durante o evento de recuperação de desastres.
Para implantações leves piloto, especialmente, certifique-se de ter garantido toda a cota de host necessária no site secundário para que você não precise esperar pela capacidade necessária durante a expansão total. Consulte Solicitar cota de host para a Solução VMware do Azure.
Configure funções de domínio funcional, como controladores de domínio do Active Directory, no ambiente secundário.
As soluções de parceiros como JetStream e Zerto estão disponíveis e validadas no Azure VMware Solution. Eles oferecem suporte à maioria dos cenários de recuperação de desastres e podem fornecer recuperação mais rápida com RPO quase zero.
O VMware Site Recovery Manager, o Jetstream e o Zerto oferecem suporte à migração de locais de terceiros para a Solução VMware do Azure.
O VMware HCX também é uma solução econômica de recuperação de desastres. No entanto, não é recomendado para grandes cargas de trabalho de produção devido à orquestração manual.
Para recuperação de desastres entre nuvens privadas da Solução VMware do Azure em diferentes regiões do Azure, você precisa habilitar o Alcance Global da Rota Expressa entre os dois circuitos de Rota Expressa de back-end. Esses circuitos criam conectividade de nuvem privada primária para secundária quando necessário para soluções como VMware SRM e VMware HCX.
Para recuperação de desastres entre nuvens privadas do Azure VMware Solution na mesma região do Azure, você precisa habilitar o Azure VMware Solution Interconnect. Ele cria um link de roteamento entre as redes de gerenciamento e carga de trabalho das nuvens privadas da Solução VMware do Azure para comunicação entre as nuvens. Certifique-se de que o espaço de endereço IP roteado em cada nuvem privada seja exclusivo e não se sobreponha.
Ao trabalhar com recuperação de desastres, você pode usar o mesmo espaço de endereço IP de origem na região primária do Azure e na região secundária do Azure. No entanto, requer esforços extras de projeto e engenharia.
Reter os mesmos endereços IP: as máquinas virtuais no site secundário da Solução VMware do Azure podem ser recuperadas usando o mesmo endereço IP de origem do site primário. Para esse método, crie VLANs isoladas ou segmentos NSX-T no site secundário e certifique-se de que nenhuma dessas VLANs ou segmentos isolados esteja conectada ao ambiente. Modifique suas rotas de recuperação de desastres para refletir que a sub-rede foi movida para o site secundário e o novo local de endereços IP. Embora esse método funcione, ele também cria sobrecarga de engenharia ao visar a recuperação de desastres totalmente automatizada.
Usar endereços IP diferentes: você também pode usar endereços IP diferentes para VMs recuperadas. Se a VM for movida para um site secundário, o plano de recuperação no VMware Site Recovery Manager detalhará o mapa IP personalizado. Selecione este mapa para a alteração do endereço IP. As VMs são ativadas nos novos segmentos NSX-T e novos endereços IP são atribuídos. As ferramentas podem ser diferentes para diferentes soluções de recuperação de desastres.
Fatores importantes para cenários de recuperação de desastres parciais e totais:
O VMware Site Recovery Manager oferece suporte à recuperação parcial, que recupera apenas um subconjunto de máquinas virtuais, e à recuperação completa de desastres. Entre dois sites da Solução VMware do Azure na região 1 e na região 2, todas ou algumas das VMs podem fazer failover.
O requisito de retenção de endereço IP de origem para VMs recuperadas determina se a recuperação de desastres parcial versus total é possível.
Para manter o endereço IP de origem enquanto executa a recuperação parcial de desastres no Gerenciador de Recuperação de Site, o gateway de sub-rede precisa ser movido para o site secundário.
Observação
A recuperação de desastres em espera ativa não requer alongamento da Camada 2.
Recomendações de design de recuperação de desastre
Use o VMware Site Recovery Manager ao trabalhar com a Solução VMware do Azure em sites primários e secundários. Os sites primário e secundário também são conhecidos como o site protegido e o site de recuperação, respectivamente.
Visão geral de alto nível da replicação contínua do vSphere.
Exemplo detalhado de replicação contínua do vSphere entre sites primários e secundários.
Para aplicativos essenciais aos negócios, a Zerto e a JetStream estão disponíveis como soluções de recuperação de desastres para a nuvem privada da Solução VMware do Azure. O JetStream e o Zerto são construídos com base na CDP (Continuous Data Protection, proteção contínua de dados), usando a estrutura VMware vSphere API for I/O filtering (VAIO), que permite perda mínima ou quase nenhuma de dados. Ele também permite a recuperação de desastres econômica usando recursos mínimos.
Use o Azure Site Recovery ou o Zerto, se as máquinas virtuais IaaS do Azure forem o destino de recuperação de desastres para a nuvem privada da Solução VMware do Azure.
Minimize a entrada manual usando planos de recuperação automatizados em cada uma das respectivas soluções de recuperação de desastres. Esses planos são úteis ao trabalhar com o VMware Site Recovery Manager ou com soluções de parceiros. Um plano de recuperação reúne computadores em grupos de recuperação para failover. Em seguida, ajuda a definir um processo de recuperação sistemático, criando unidades independentes que podem fazer failover.
Configure testes de fumaça ou exercícios de recuperação de desastres pelo menos uma vez por ano para garantir que os planos de recuperação funcionem conforme o esperado. Os recursos de orquestração da ferramenta de recuperação de desastres escolhida determinam o nível de esforço envolvido na execução desses exercícios.
Use pares regionais geopolíticos como o ambiente secundário de recuperação de desastres . Alguns dos benefícios dos pares regionais são a recuperação de região priorizada, atualizações sequenciais, isolamento físico e residência de dados.
Mantenha os espaços de endereço diferentes para evitar a sobreposição de endereços IP entre os dois sites. Por exemplo, você pode usar
192.168.0.0/16para a região 1 e10.0.0.0/16para a região 2.Use a conectividade ExpressRoute Global Reach entre as nuvens privadas primária e secundária em diferentes regiões. Veja mais considerações e recomendações de rede na área de design pertinente.
Próximas etapas
Saiba mais sobre as considerações e recomendações para a implantação inicial da Solução VMware no Azure e as diretrizes para a automação operacional.