Partilhar via

Proteger VMs implantadas no Azure Stack Hub

  • Artigo

Use este artigo como um guia para ajudá-lo a desenvolver uma estratégia de proteção de dados e recuperação de desastres para máquinas virtuais (VMs) IaaS implantadas pelo usuário implantadas no Azure Stack Hub.

Para proteger contra perda de dados e tempo de inatividade estendido, implemente um plano de recuperação de backup ou recuperação de desastres para aplicativos de usuário e seus dados. Cada aplicativo deve ser avaliado como parte da estratégia abrangente de continuidade de negócios e recuperação de desastres (BC/DR) da sua organização.

Considerações para proteger VMs IaaS

Funções e responsabilidades

Primeiro, certifique-se de que haja uma compreensão clara das funções e responsabilidades atribuídas aos proprietários e operadores de aplicativos no contexto de proteção e recuperação.

Os usuários são responsáveis pela proteção de VMs. Os operadores são responsáveis por manter o Azure Stack Hub online e íntegro. O Azure Stack Hub inclui um serviço que faz backup de dados de serviços internos de serviços de infraestrutura e não inclui dados de utilizador, incluindo VMs criadas pelo utilizador, contas de armazenamento com dados de utilizador ou de aplicações, ou bases de dados de utilizadores.

Proprietário/arquiteto do aplicativo Operador do Azure Stack Hub
- Alinhar a arquitetura de aplicativos com os princípios de design de nuvem.
- Modernizar as aplicações tradicionais conforme necessário, para prepará-las para o ambiente de nuvem.
- Definir RTO e RPO aceitáveis para o aplicativo.
- Identificar recursos de aplicativos e repositórios de dados que precisam ser protegidos.
- Implementar um método de recuperação de dados e aplicativos que melhor se alinhe à arquitetura do aplicativo e aos requisitos do cliente.		 - Identificar os objetivos de continuidade de negócios e recuperação de desastres da organização.
- Implante instâncias suficientes do Azure Stack Hub para atender às metas de BC/DR da organização.
- Conceber e operar infraestruturas de aplicação/proteção de dados.
- Fornecer soluções gerenciadas ou acesso de autoatendimento a serviços de proteção.
- Trabalhe com proprietários/arquitetos de aplicativos para entender o design do aplicativo e recomendar estratégias de proteção.
- Habilite o backup de infraestrutura para recuperação de serviços e recuperação em nuvem.

Combinações origem/destino

Os usuários que precisam se proteger contra uma interrupção do datacenter ou do site podem usar outro Azure Stack Hub ou Azure para fornecer alta disponibilidade ou recuperação rápida. Com o local primário e secundário, os usuários podem implantar aplicativos em uma configuração ativa/ativa ou ativa/passiva em dois ambientes. Para cargas de trabalho menos críticas, os usuários podem usar a capacidade no local secundário para executar a restauração sob demanda de aplicativos a partir do backup.

Uma ou mais nuvens do Azure Stack Hub podem ser implantadas em um datacenter. Para sobreviver a um desastre catastrófico, implantar pelo menos uma nuvem do Azure Stack Hub em um datacenter diferente garante que você possa fazer failover de cargas de trabalho e minimizar o tempo de inatividade não planejado. Se você tiver apenas um Azure Stack Hub, considere usar a nuvem pública do Azure como sua nuvem de recuperação. A determinação de onde seu aplicativo pode ser executado será determinada por regulamentos governamentais, políticas corporativas e requisitos rigorosos de latência. Você tem a flexibilidade de determinar o local de recuperação apropriado por aplicativo. Por exemplo, você pode ter aplicativos em uma assinatura fazendo backup de dados em outro datacenter e em outra assinatura, replicando dados para a nuvem pública do Azure.

Objetivos de recuperação de aplicativos

Os proprietários de aplicativos são os principais responsáveis por determinar a quantidade de tempo de inatividade e perda de dados que o aplicativo e a organização podem tolerar. Ao quantificar o tempo de inatividade aceitável e a perda de dados aceitável, você pode criar um plano de recuperação que minimize o impacto de um desastre em sua organização. Para cada aplicação, considere o seguinte:

  • Objetivo de tempo de recuperação (RTO)
    RTO é o tempo máximo aceitável que um aplicativo pode ficar indisponível após um incidente. Por exemplo, um RTO de 90 minutos significa que você deve ser capaz de restaurar o aplicativo para um estado de execução dentro de 90 minutos a partir do início de um desastre. Caso tenha um RTO baixo, pode manter uma segunda instância continuamente operacional e pronta para proteger contra uma falha regional.
  • RPO, Recovery Point Objective (objetivo de ponto de recuperação)
    RPO é a duração máxima de perda de dados aceitável durante um desastre. Por exemplo, se você armazenar dados em um único banco de dados, cujo backup é feito de hora em hora e não tem replicação para outros bancos de dados, poderá perder até uma hora de dados.

Outra métrica é Mean Time to Recover (MTTR), que é o tempo médio que leva para restaurar o aplicativo após uma falha. MTTR é um valor empírico para um sistema. Se o MTTR exceder o RTO, uma falha no sistema causará uma interrupção de negócios inaceitável porque não será possível restaurar o sistema dentro do RTO definido.

Opções de proteção

Backup-restauração

O backup de seus aplicativos e conjuntos de dados permite que você se recupere rapidamente do tempo de inatividade devido a corrupção de dados, exclusões acidentais ou desastres. Para aplicativos baseados em VM IaaS, você pode usar um agente convidado para proteger dados de aplicativos, configuração do sistema operacional e dados armazenados em volumes.

Backup usando agente convidado

O backup de uma VM usando um agente de sistema operacional convidado normalmente inclui a captura da configuração do sistema operacional, arquivos/pastas, discos, binários de aplicativos ou dados de aplicativos.

A recuperação de um aplicativo de um agente requer a recriação manual da VM, a instalação do sistema operacional e a instalação do agente convidado. Nesse ponto, os dados podem ser restaurados no SO convidado ou diretamente no aplicativo.

Backup usando instantâneo de disco para VMs paradas

Os produtos de backup podem proteger a configuração de VM IaaS e os discos conectados a uma VM interrompida. Use produtos de backup que se integram às APIs do Azure Stack Hub para capturar a configuração da VM e criar instantâneos de disco. Se o tempo de inatividade planejado para o aplicativo for possível, verifique se a VM está em um estado interrompido antes de iniciar o fluxo de trabalho de backup.

Backup usando instantâneo de disco para executar VMs

Importante

No momento, não há suporte para o uso de instantâneos de disco do portal para VMs em estado de execução. Criar um instantâneo de um disco conectado a uma VM em execução pode degradar o desempenho ou afetar a disponibilidade do sistema operacional ou aplicativo na VM. A recomendação é usar uma solução de fornecedor de backup que se integre ao recurso de snapshot incremental do Storage RP ou um agente convidado para proteger o aplicativo se o tempo de inatividade planejado não for uma opção.

VMs em um conjunto de escala ou disponibilidade

Não se deve fazer backup de VMs num conjunto de escala ou grupo de disponibilidade que são considerados recursos efémeros ao nível da VM, especialmente se a aplicação for sem estado. Para aplicativos com monitoração de estado implantados em um conjunto de escala ou de disponibilidade, considere proteger os dados do aplicativo (por exemplo, um banco de dados ou volume em um pool de armazenamento).

Replicação/comutação de falha manual

Para aplicativos que exigem perda mínima de dados ou tempo de inatividade mínimo, a replicação de dados pode ser habilitada no SO convidado ou no nível do aplicativo para replicar dados para outro local. Alguns aplicativos, como o Microsoft SQL Server, oferecem suporte nativo à replicação. Se o aplicativo não oferecer suporte à replicação, você poderá usar software no SO convidado para replicar discos ou uma solução de parceiro que seja instalada como um agente no sistema operacional convidado.

Com essa abordagem, o aplicativo é implantado em uma nuvem e os dados são replicados para a outra nuvem local ou para o Azure. Quando um failover é acionado, a aplicação no destino precisará ser iniciada e anexada aos dados replicados antes de poder começar a atender às solicitações.

Alta disponibilidade/failover automático

Para aplicações sem estado que só podem tolerar poucos segundos ou minutos de interrupção, considere uma configuração de alta disponibilidade. Os aplicativos de alta disponibilidade são projetados para serem implantados em vários locais em uma topologia ativa/ativa onde todas as instâncias podem atender solicitações. Para falhas de hardware locais, a infraestrutura do Azure Stack Hub implementa alta disponibilidade na rede física usando dois switches topo de rack. Para falhas no nível de computação, o Azure Stack Hub usa vários nós em uma unidade de escalabilidade e fará automaticamente o failover de uma VM. No nível da VM, você pode usar conjuntos de escala ou VMs no conjunto de disponibilidade para garantir que falhas de nó não derrubem seu aplicativo. O mesmo aplicativo precisaria ser implantado em um local secundário na mesma configuração. Para tornar o aplicativo ativo/ativo, um balanceador de carga ou DNS pode ser usado para direcionar solicitações para todas as instâncias disponíveis.

Sem recuperação

Alguns aplicativos em seu ambiente podem não precisar de proteção contra tempo de inatividade não planejado ou perda de dados. Por exemplo, as VMs usadas para desenvolvimento e teste normalmente não precisam ser recuperadas. É sua decisão prescindir da proteção de um aplicativo ou conjunto de dados.

Considerações importantes para sua implantação do Azure Stack Hub:

Recomendação Observações
Backup/restauração de VMs para um destino de backup externo já implantado em seu datacenter Recomendado Aproveite a infraestrutura de backup e as habilidades operacionais existentes. Certifique-se de dimensionar a infraestrutura de backup para que ela esteja pronta para proteger as instâncias de VM adicionais. Certifique-se de que a infraestrutura de backup não esteja próxima da sua origem. Você pode restaurar VMs para o Azure Stack Hub de origem, para uma instância secundária do Azure Stack Hub ou para o Azure.
Backup/restauração de VMs para um destino de backup externo dedicado ao Azure Stack Hub Recomendado Você pode comprar uma nova infraestrutura de backup ou provisionar uma infraestrutura de backup dedicada para o Azure Stack Hub. Certifique-se de que a infraestrutura de backup não esteja próxima da sua origem. Você pode restaurar VMs para o Azure Stack Hub de origem, para uma instância secundária do Azure Stack Hub ou para o Azure.
Backup/restauração de VMs diretamente no Azure global ou em um provedor de serviços confiável Recomendado Desde que possa cumprir os requisitos regulamentares e de privacidade de dados, pode armazenar as suas cópias de segurança no Azure global ou num fornecedor de serviços fidedigno. Idealmente, o provedor de serviços também está executando o Azure Stack Hub, para que você obtenha consistência na experiência operacional ao restaurar.
Replicar/fazer failover de VMs para uma instância separada do Azure Stack Hub Recomendado No caso de failover, você precisa ter uma segunda nuvem do Azure Stack Hub totalmente operacional para evitar o tempo de inatividade prolongado do aplicativo.
Replicar/fazer failover de VMs diretamente para o Azure ou para um fornecedor de serviços de confiança Recomendado Desde que possa cumprir os requisitos regulamentares e de privacidade de dados, pode replicar os seus dados para o Azure global ou para um fornecedor de serviços fidedigno. Idealmente, o provedor de serviços também está executando o Azure Stack Hub para que você obtenha consistência na experiência operacional após o failover.
Implante um destino de backup no mesmo Azure Stack Hub que também hospeda todos os aplicativos protegidos pelo mesmo destino de backup. Destino autônomo: não recomendado
Destino que replica dados de backup externamente: Recomendado		 Se você optar por implantar um dispositivo de backup no Azure Stack Hub (para fins de otimização da restauração operacional), deverá garantir que todos os dados sejam copiados continuamente para um local de backup externo.
Implantar dispositivo de backup físico no mesmo rack em que a solução Azure Stack Hub está instalada Não suportado Atualmente, não é possível conectar outros dispositivos à parte superior dos switches de rack que não façam parte da solução original.

Considerações para uma VM IaaS restaurada

Você precisará fazer algumas alterações na sua VM depois de restaurar a máquina a partir do backup. Estes incluem:

  • endereço MAC
    O adaptador de rede virtual receberá um novo endereço MAC. Não há um método para preservar o endereço MAC original.
  • endereço IP
    Se a VM tiver um IP estático definido internamente, o IP interno no adaptador de rede virtual poderá ser definido para corresponder ao original. Talvez seja necessário considerar se a VNET tem uma VPN S2S para um ambiente externo onde o endereço IP pode estar em uso.
  • Artefatos desnecessários
    Se o backup da VM tiver sido feito em uma plataforma diferente, como o VMware vSphere, você precisará seguir algumas etapas adicionais para limpar quaisquer artefatos desnecessários da origem.

Próximos passos

Este artigo forneceu diretrizes gerais para proteger VMs de usuário implantadas no Azure Stack Hub. Para obter informações sobre como usar os serviços do Azure para proteger VMs de usuário, consulte: