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 desastre para VMs (máquinas virtuais) 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 desastre para aplicativos de usuário e seus dados. Cada aplicativo deve ser avaliado como parte da estratégia abrangente de BC/DR (continuidade dos negócios e recuperação de desastres) da sua organização.

Considerações sobre como proteger VMs IaaS

Funções e responsabilidades

Primeiro, verifique se há uma compreensão clara das funções e responsabilidades atribuídas aos proprietários e operadores do aplicativo no contexto de proteção e recuperação.

Os usuários são responsáveis por proteger 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ço internos de serviços de infraestrutura e não inclui dados de usuário, incluindo VMs criadas pelo usuário, contas de armazenamento com dados de usuário ou aplicativo ou bancos de dados de usuário.

Proprietário/arquiteto do aplicativo Operador do Azure Stack Hub
– Alinhar a arquitetura do aplicativo com os princípios de design de nuvem.
– Modernizar aplicativos tradicionais conforme necessário, para prepará-los para o ambiente de nuvem.
– Defina RTO e RPO aceitáveis para o aplicativo.
– Identificar os recursos do aplicativo e os repositórios de dados que precisam ser protegidos.
– Implemente um método de recuperação de dados e aplicativos que melhor se alinhe aos requisitos de arquitetura do aplicativo e do cliente.		 - Identifique as metas de continuidade dos 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.
– Projetar e operar a infraestrutura de proteção de dados/aplicativo.
– Fornecer soluções gerenciadas ou acesso de autoatendimento aos 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.
– Habilitar o backup de infraestrutura para recuperação de serviço e recuperação de nuvem.

Combinações de origem/destino

Os usuários que precisam proteger contra um datacenter ou interrupção de 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 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 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 aplicativo

Os proprietários de aplicativos são os responsáveis principalmente 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 minimiza o impacto de um desastre em sua organização. Para cada aplicativo, considere o seguinte:

  • RTO (objetivo de tempo de recuperação)
    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 em execução dentro de 90 minutos após o início de um desastre. Se você tiver um RTO baixo, poderá manter uma segunda implantação em execução continuamente em espera para proteger contra uma interrupção regional.
  • RPO (objetivo de ponto de recuperação)
    RPO é a duração máxima de perda de dados que é aceitável durante um desastre. Por exemplo, se você armazenar dados em um banco de dados individual, que faz backup por hora e não tem replicação em outros bancos de dados, poderá perder até uma hora de dados.

Outra métrica é MtTR (Tempo Médio de Recuperação ), que é o tempo médio necessário para restaurar o aplicativo após uma falha. MTTR é um valor empírico para um sistema. Se 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

Restauração de backup

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

Fazer backup usando o agente convidado

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

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

Backup usando instantâneo de disco para VMs interrompidas

Os produtos de backup podem proteger a configuração da VM iaaS e os discos anexados 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.

Fazer 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 VM em um estado em execução. A criação de um instantâneo de um disco anexado a uma VM em execução pode prejudicar o desempenho ou afetar a disponibilidade do sistema operacional ou do aplicativo na VM. A recomendação é usar uma solução de fornecedor de backup que se integre à funcionalidade de instantâneo incremental de RP de armazenamento 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 dimensionamento ou conjunto de disponibilidade

As VMs em um conjunto de dimensionamento ou grupo de disponibilidade considerados recursos efêmeros não devem ser backup no nível da VM, especialmente se o aplicativo não tiver estado. Para aplicativos com estado implantados em um conjunto de dimensionamento ou conjunto de disponibilidade, considere proteger os dados do aplicativo (por exemplo, um banco de dados ou volume em um pool de armazenamento).

Replicação/failover 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 nível do sistema operacional convidado ou do aplicativo para replicar dados em outro local. Alguns aplicativos, como o Microsoft SQL Server, dão suporte nativo à replicação. Se o aplicativo não der suporte à replicação, você poderá usar software no sistema operacional convidado para replicar discos ou uma solução de parceiro que é 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 é disparado, o aplicativo no destino precisará ser iniciado e anexado aos dados replicados antes que ele possa iniciar solicitações de manutenção.

Alta disponibilidade/failover automático

Para aplicativos sem estado que só podem tolerar alguns segundos ou minutos de tempo de inatividade, considere uma configuração de alta disponibilidade. Os aplicativos de alta disponibilidade foram projetados para serem implantados em vários locais em uma topologia ativa/ativa em que todas as instâncias podem atender às solicitações. Para falhas de hardware locais, a infraestrutura do Azure Stack Hub implementa alta disponibilidade na rede física usando duas opções superiores de rack. Para falhas no nível de computação, o Azure Stack Hub usa vários nós em uma unidade de escala e fará failover automático de uma VM. No nível da VM, você pode usar conjuntos de dimensionamento ou VMs no conjunto de disponibilidade para garantir que as 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 fazer sem proteção para um aplicativo ou conjunto de dados.

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

Recomendação Comentários
Backup/restauração de VMs para um destino de backup externo já implantado em seu datacenter Recomendadas Aproveite a infraestrutura de backup existente e as habilidades operacionais. Certifique-se de dimensionar a infraestrutura de backup para que ela esteja pronta para proteger as instâncias de VM adicionais. Verifique se a infraestrutura de backup não está próxima de sua origem. Você pode restaurar VMs para o Azure Stack Hub de origem, para uma instância secundária do Azure Stack Hub ou do Azure.
Fazer backup/restaurar VMs para um destino de backup externo dedicado ao Azure Stack Hub Recomendadas Você pode comprar uma nova infraestrutura de backup ou provisionar a infraestrutura de backup dedicada para o Azure Stack Hub. Verifique se a infraestrutura de backup não está próxima de sua origem. Você pode restaurar VMs para o Azure Stack Hub de origem, para uma instância secundária do Azure Stack Hub ou do Azure.
Backup/restauração de VMs diretamente para o Azure global ou um provedor de serviços confiável Recomendadas Desde que você possa atender aos seus requisitos regulatórios e de privacidade de dados, você pode armazenar seus backups no Azure global ou em um provedor de serviços confiável. O ideal é que o provedor de serviços também esteja executando o Azure Stack Hub para que você obtenha consistência na experiência operacional ao restaurar.
Replicar/failover de VMs para uma instância separada do Azure Stack Hub Recomendadas No caso de failover, você precisa ter uma segunda nuvem do Azure Stack Hub totalmente operacional para evitar o tempo de inatividade estendido do aplicativo.
Replicar/fazer failover de VMs diretamente no Azure ou em um provedor de serviços confiável Recomendadas Desde que você possa atender aos seus requisitos regulatórios e de privacidade de dados, você pode replicar seus dados para o Azure global ou um provedor de serviços confiável. O ideal é que o provedor de serviços também esteja 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: destino não recomendado
que replica dados de backup externamente: recomendado		 Se você optar por implantar uma dispositivo de backup no Azure Stack Hub (para otimizar a restauração operacional), deverá garantir que todos os dados sejam copiados continuamente para um local de backup externo.
Implantar o backup físico dispositivo no mesmo rack em que a solução do Azure Stack Hub está instalada Sem suporte Atualmente, você não pode conectar nenhum outro dispositivo à parte superior dos comutadores rack que não fazem parte da solução original.

Considerações sobre uma VM IaaS restaurada

Você precisará fazer algumas alterações na VM depois de restaurar o computador do backup. Estão incluídos:

  • Endereço MAC
    O adaptador de rede virtual obterá 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 em que o endereço IP pode estar em uso.
  • Artefatos desnecessários
    Se a VM tiver feito backup em uma plataforma diferente, como o VMware vSphere, você precisará seguir algumas etapas adicionais para limpo quaisquer artefatos desnecessários da origem.

Próximas etapas

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: