Continuidade de negócios e recuperação de desastres para a solução VMware do Azure
Esse cenário em 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 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, VMware vSAN, VMware vSphere e VMware NSX-T Data Center. Para saber mais sobre o contrato de nível de serviço (SLA) da Solução VMware do Azure, consulte SLA para a Solução VMware do Azure.
Quer tenha uma solução VMware local ou do Azure, 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.
Nota
Um ambiente piloto leve é configurado com uma configuração mínima, com apenas componentes principais para suportar um conjunto crítico de aplicações. 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 computação e memória intensivas da solução VMware do Azure, a mesma quantidade de armazenamento é necessária no local secundário.
Considerações sobre o projeto de continuidade de negócios
As políticas de armazenamento VMware vSAN na solução VMware do Azure são implementadas com a disponibilidade de armazenamento em mente. 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 o cluster tem entre 6 e 16 hosts, o número de falhas de host a serem toleradas antes que a perda de dados possa ocorrer é igual a dois. As políticas de armazenamento VMware vSAN 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, consulte Conceitos de armazenamento da solução VMware do Azure.
A alta disponibilidade do vSphere está 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 do Azure VMware Solution.
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 do vSAN.
Escolha uma solução de backup validada para as máquinas virtuais (VMs) VMware vSphere, como o Microsoft Azure Backup Server 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 documentação do respetivo parceiro.
Nota
As configurações do vCenter Server e do NSX-T Data Center para nuvens privadas são copiadas 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 projeto 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 suportadas 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 do Azure. Esse método de implantação reduz os custos de tráfego, facilita a administração e mantém a topologia principal/secundária. Consulte o guia de seleção de regiões do Azure para conhecer as práticas recomendadas de implantação da região do Azure.
O Backup do Azure pode ser implantado como uma VM 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. A execução do Servidor de Backup fora da nuvem privada do Azure VMware Solution ajuda a reduzir o consumo de vSAN, uma vez que o vSAN é um recurso de capacidade limitada dentro da 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 o Azure IaaS VM SKU 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 toda a camada 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, oito trabalhos de backup paralelos são suportados. 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. Certifique-se de que o armazenamento de dados AVS vSAN tenha capacidade suficiente para armazenar o backup restaurado.
Adicione 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 do Azure VMware Solution para backup de aplicativos (por exemplo, SQL, Sharepoint, etc.), desabilite o monitoramento em tempo real de dpmra.exe.
Configure 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 em 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 do Azure VMware Solution. Consulte a seção de 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 desastres
Alinhe os requisitos de negócios com RTO (Recovery Time Objetives, objetivos de tempo de recuperação), capacidade e RPO (Recovery Point Objetives, 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 local de recuperação de desastres de destino para a nuvem privada protegida da Solução VMware do Azure. Este site influencia quais ferramentas de recuperação de desastres são adequadas para o ambiente. Por exemplo, se você quiser recuperar cargas de trabalho do Azure VMware Solution para máquinas virtuais IaaS nativas do Azure, poderá considerar o Azure Site Recovery ou o Zerto.
Determine qual subconjunto de cargas de trabalho do Azure VMware Solution 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 empresa operar. 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, os ambientes que não são de produção, como desenvolvimento, teste ou UAT, não precisam fazer failover para um local 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 desastre.
Para implantações piloto leves, especialmente, certifique-se de ter garantido toda a cota de host necessária no site secundário para não ter que esperar pela capacidade necessária durante o dimensionamento total. Consulte Solicitar cota de host para a Solução VMware do Azure.
Configure funções de domínio funcionais, como controladores de domínio do Ative Directory, no ambiente secundário.
As soluções de parceiros como JetStream e Zerto estão geralmente disponíveis e validadas na Solução VMware do Azure. Eles suportam a 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 suportam a 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 back-end da Rota Expressa. Esses circuitos criam conectividade de nuvem privada primária a 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.
Mantenha 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 conectado 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 local secundário, o plano de recuperação no VMware Site Recovery Manager detalha o mapa IP personalizado. Selecione este mapa para a alteração do endereço IP. As VMs são exibidas nos novos segmentos NSX-T e novos endereços IP são atribuídos. As ferramentas podem diferir 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 total 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 Site Recovery Manager, o gateway de sub-rede precisa ser movido para o site secundário.
Nota
A recuperação de desastres em espera ativa não requer alongamento da Camada 2.
Recomendações de projeto de recuperação de desastres
Use o VMware Site Recovery Manager ao trabalhar com a solução VMware do Azure em sites primários e secundários. Os locais primários e secundários também são conhecidos como locais protegidos e 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 locais primários e secundários.
Para aplicativos críticos para os negócios, o Zerto e o JetStream estão disponíveis como soluções de recuperação de desastres para a nuvem privada do Azure VMware Solution. 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 de dados mínima ou quase nenhuma. 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 respetivas 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 máquinas 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 geopolíticos regionais 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 do 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 relevante.
Próximos passos
Saiba mais sobre considerações e recomendações para a implantação inicial da Solução VMware do Azure e orientações para automação operacional.