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 dos negócios e a recuperação de desastres (BCDR). A Solução VMware no Azure fornece nuvens privadas que contêm clusters do VMware vSphere criados a partir da 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 SLA (contrato de nível de serviço) da Solução VMware no Azure, consulte SLA para a Solução VMware no Azure.
Se você tiver uma Solução VMware local ou no Azure, considere vários fatores de BCDR para se preparar para um desastre. Um plano robusto de BCDR 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 no Azure.
Observação
Um ambiente de luz piloto é configurado com uma configuração mínima, com apenas componentes principais para dar suporte a um conjunto crítico de aplicativos. No entanto, ele pode escalar horizontalmente e gerar mais hosts para assumir a maior parte da carga se ocorrer um failover. Para recuperação de desastre de cargas de trabalho de solução VMware no Azure com uso intensivo de computação e memória, a mesma quantidade de armazenamento é necessária no site 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á-las 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 é ativada por padrão na Solução VMware no Azure. A política de admitância 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 da Solução VMware no Azure.
Alta disponibilidade com cluster estendido: com a Solução VMware no Azure, os hosts ESXi implantados em um cluster padrão do vSphere 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 de 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 do vSAN.
Escolha uma solução de backup validada para as VMs (máquinas virtuais) do 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 compatíveis com as soluções de backup de parceiros, consulte a respectiva documentação do parceiro.
Observação
As configurações do vCenter Server e do HCX Manager (se habilitado) na nuvem privada da Solução VMware no Azure estão em um agendamento de backup diário e a configuração do NSX está em um agendamento de backup por hora. Os backups são mantidos por, no mínimo, três dias.
Os componentes da Solução VMware no Azure, como vCenter Server, NSX-T Manager ou HCX Manager, são serviços gerenciados para os quais o Azure gerencia o backup. Para restaurar 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 no Azure. Para obter mais informações, consulte Fazer backup de VMs do VMware vSphere com o Backup do Azure. As topologias de implantação com suporte incluem o MARS Agent 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 obter as melhores práticas 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 no Azure. É altamente recomendável implantá-lo fora da nuvem privada da Solução VMware no Azure. Implante o Backup em uma rede virtual do Azure e verifique se essa rede virtual está conectada ao mesmo ExpressRoute conectado à nuvem privada da Solução VMware no Azure. Executar o Servidor de Backup fora da nuvem privada da Solução VMware no Azure ajuda a reduzir o consumo de vSAN, pois o vSAN é um recurso de capacidade limitada na nuvem privada da Solução VMware no Azure.
Servidor de Backup do Azure implantado como uma VM de IaaS do Azure.
Servidor de Backup do Azure implantado como uma VM da Solução VMware no 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 mediano 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 todo o nível de desempenho esteja disponível para armazenar metadados ReFS.
Identifique o número de trabalhos de backup paralelos e operações de restauração a serem executadas 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 críticas 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. Certifique-se de que o repositório de dados AVS vSAN tenha 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 algum software antivírus/antimalware for executado no Servidor de Backup do Azure. Ao usar o agente de proteção do DPM em qualquer VM da Solução VMware no Azure para backup de aplicativos (por exemplo, SQL, SharePoint etc.), desabilite o monitoramento em tempo real do dpmra.exe.
Configure as regras de 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 no 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 dá suporte à restauração entre regiões para a nuvem privada da Solução VMware no Azure. Consulte a seção soluções de backup de parceiros e recuperação de desastre quando a recuperação da Solução VMware no 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 objetivos de ponto de recuperação (RPO) para aplicativos. Planeje e projete adequadamente 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 desastre de destino para a nuvem privada protegida da Solução VMware no Azure. Este site influencia quais ferramentas de recuperação de desastre são adequadas para o ambiente. Por exemplo, se você quiser recuperar cargas de trabalho da Solução VMware no Azure para máquinas virtuais de IaaS nativas do Azure, considere o Azure Site Recovery ou o Zerto.
Determine qual subconjunto de cargas de trabalho da Solução VMware no Azure exigirá 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 de produção e cargas de trabalho críticas para economizar custos. Para obter mais capacidade, você pode escalar horizontalmente para adicionar hosts ESXi ao cluster durante o evento de recuperação de desastres.
Especialmente para implantações de luz piloto, verifique se você garantiu 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 no 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 em disponibilidade geral e validadas na Solução VMware no Azure. Eles dão 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 dão suporte à migração de locais de terceiros para a Solução VMware no 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 desastre entre nuvens privadas da Solução VMware no Azure em diferentes regiões do Azure, você precisa habilitar o Alcance Global do ExpressRoute entre os dois circuitos de back-end do ExpressRoute. 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 desastre entre nuvens privadas da Solução VMware no Azure na mesma região do Azure, você precisa habilitar a Interconexão da Solução VMware no Azure. Ele cria um link de roteamento entre as redes de gerenciamento e carga de trabalho das nuvens privadas da Solução VMware no 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 desastre, 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 design e engenharia.
Manter os mesmos endereços IP: as máquinas virtuais no site secundário da Solução VMware no Azure podem ser recuperadas usando o mesmo endereço IP de origem que o site primário. Para esse método, crie VLANs ou segmentos NSX-T isolados no site secundário e certifique-se de que nenhuma dessas VLANs ou segmentos isolados esteja conectado ao ambiente. Modifique suas rotas de recuperação de desastre 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 buscar uma 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 de IP personalizado. Selecione este mapa para a alteração do endereço IP. As VMs são ativadas nos novos segmentos do 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 parcial e total de desastres:
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 no 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 desastre parcial ou total é possível.
Para manter o endereço IP de origem durante a execução da recuperação parcial de desastre no Site Recovery Manager, 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 de Camada 2.
Recomendações de design de recuperação de desastre
Use o VMware Site Recovery Manager ao trabalhar com a Solução VMware no 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 comercialmente críticos, o Zerto e o JetStream estão disponíveis como soluções de recuperação de desastre para a nuvem privada da Solução VMware no Azure. O JetStream e o Zerto são criados com base na proteção contínua de dados (CDP), usando a estrutura VMware vSphere API for I/O filtering (VAIO), que permite perda mínima ou quase nenhuma perda 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 de IaaS do Azure forem o destino de recuperação de desastre para a nuvem privada da Solução VMware no 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 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 desastre 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 de Alcance Global do ExpressRoute entre as nuvens privadas primárias e secundárias 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.