Proteger VMs implementadas no Azure Stack Hub

  • Artigo

Utilize este artigo como um guia para o ajudar a desenvolver uma estratégia de proteção de dados e recuperação após desastre para máquinas virtuais (VMs) IaaS implementadas pelo utilizador implementadas no Azure Stack Hub.

Para proteger contra a perda de dados e o período de indisponibilidade prolongado, implemente um plano de recuperação de cópias de segurança ou recuperação após desastre para aplicações de utilizador e os respetivos dados. Cada aplicação tem de ser avaliada como parte da estratégia abrangente de continuidade de negócio e recuperação após desastre (BC/DR) da sua organização.

Considerações para proteger VMs IaaS

Funções e responsabilidades

Primeiro, confirme que existe uma compreensão clara das funções e responsabilidades atribuídas aos proprietários e operadores da aplicação no contexto de proteção e recuperação.

Os utilizadores são responsáveis por proteger as VMs. Os operadores são responsáveis por manter o Azure Stack Hub online e em bom estado de funcionamento. O Azure Stack Hub inclui um serviço que cria cópias de segurança de dados de serviço interno a partir de serviços de infraestrutura e não inclui quaisquer dados de utilizador, incluindo VMs criadas pelo utilizador, contas de armazenamento com dados de utilizadores ou aplicações ou bases de dados de utilizador.

Proprietário/arquiteto da aplicação Operador do Azure Stack Hub
- Alinhe a arquitetura da aplicação com os princípios de conceção da cloud.
- Modernizar as aplicações tradicionais conforme necessário, para prepará-las para o ambiente na cloud.
- Definir RTO e RPO aceitáveis para a aplicação.
- Identifique os recursos da aplicação e os repositórios de dados que têm de ser protegidos.
- Implemente um método de recuperação de dados e aplicações que melhor se alinhe com a arquitetura da aplicação e os requisitos do cliente.		 - Identifique os objetivos de continuidade de negócio e recuperação após desastre da organização.
- Implemente instâncias do Azure Stack Hub suficientes para cumprir os objetivos bc/DR da organização.
- Conceber e operar a infraestrutura de proteção de dados/aplicações.
- Fornecer soluções geridas ou acesso self-service a serviços de proteção.
- Trabalhe com proprietários/arquitetos de aplicações para compreender a conceção de aplicações e recomendar estratégias de proteção.
- Ative a cópia de segurança da infraestrutura para recuperação de serviços e recuperação na cloud.

Combinações de origem/destino

Os utilizadores que precisam de proteger contra um datacenter ou indisponibilidade do site podem utilizar outro Azure Stack Hub ou Azure para fornecer elevada disponibilidade ou recuperação rápida. Com a localização primária e secundária, os utilizadores podem implementar aplicações numa configuração ativa/ativa ou ativa/passiva em dois ambientes. Para cargas de trabalho menos críticas, os utilizadores podem utilizar a capacidade na localização secundária para efetuar o restauro a pedido das aplicações a partir da cópia de segurança.

Uma ou mais clouds do Azure Stack Hub podem ser implementadas num datacenter. Para sobreviver a um desastre catastrófico, implementar pelo menos uma cloud do Azure Stack Hub num datacenter diferente garante que pode efetuar a ativação pós-falha de cargas de trabalho e minimizar o tempo de inatividade não planeado. Se tiver apenas um Azure Stack Hub, deve considerar a utilização da cloud pública do Azure como a cloud de recuperação. A determinação de onde a sua aplicação pode ser executada será determinada por regulamentos governamentais, políticas empresariais e requisitos de latência rigorosos. Tem a flexibilidade de determinar a localização de recuperação adequada por aplicação. Por exemplo, pode ter aplicações numa subscrição a fazer cópias de segurança de dados para outro datacenter e noutra subscrição, replicando dados para a cloud pública do Azure.

Objetivos de recuperação de aplicações

Os proprietários de aplicações são os principais responsáveis por determinar a quantidade de tempo de inatividade e perda de dados que a aplicação e a organização podem tolerar. Ao quantificar um período de indisponibilidade aceitável e uma perda de dados aceitável, pode criar um plano de recuperação que minimize o impacto de um desastre na sua organização. Para cada aplicação, considere o seguinte:

  • Objetivo de tempo de recuperação (RTO)
    O RTO é o tempo máximo aceitável que uma aplicação pode estar indisponível após um incidente. Por exemplo, um RTO de 90 minutos significa que tem de conseguir restaurar a aplicação para um estado de execução dentro de 90 minutos a partir do início de um desastre. Se tiver um RTO baixo, poderá manter uma segunda implementação continuamente em execução em modo de espera para proteger contra uma indisponibilidade regional.
  • Objetivo de ponto de recuperação (RPO)
    O RPO é a duração máxima de perda de dados que é aceitável durante um desastre. Por exemplo, se armazenar dados numa base de dados individual, cuja cópia de segurança é efetuada por hora e não tem replicação para outras bases de dados, poderá perder até uma hora de dados.

Outra métrica é o Tempo Médio de Recuperação (MTTR), que é o tempo médio que demora a restaurar a aplicação 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 inaceitável do negócio porque não será possível restaurar o sistema no RTO definido.

Opções de proteção

Restauro da cópia de segurança

Criar cópias de segurança das suas aplicações e conjuntos de dados permite-lhe recuperar rapidamente do período de indisponibilidade devido a danos em dados, eliminações acidentais ou desastres. Para aplicações baseadas em VMs IaaS, pode utilizar um agente convidado para proteger os dados da aplicação, a configuração do sistema operativo e os dados armazenados em volumes.

Cópia de segurança com o agente no convidado

Normalmente, a cópia de segurança de uma VM com um agente do SO convidado inclui a captura da configuração do sistema operativo, ficheiros/pastas, discos, binários de aplicações ou dados da aplicação.

A recuperação de uma aplicação a partir de um agente requer a recriação manual da VM, a instalação do sistema operativo e a instalação do agente convidado. Nessa altura, os dados podem ser restaurados para o SO convidado ou diretamente para a aplicação.

Cópia de segurança com instantâneo de disco para VMs paradas

Os produtos de cópia de segurança podem proteger a configuração da VM IaaS e os discos ligados a uma VM parada. Utilize produtos de cópia de segurança que se integram com as APIs do Azure Stack Hub para capturar a configuração da VM e criar instantâneos de disco. Se for possível um período de indisponibilidade planeado para a aplicação, certifique-se de que a VM está num estado parado antes de iniciar o fluxo de trabalho de cópia de segurança.

Cópia de segurança com instantâneo de disco para executar VMs

Importante

A utilização de instantâneos de disco do portal não é atualmente suportada para A VM num estado de 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 operativo ou da aplicação na VM. A recomendação é utilizar uma solução de fornecedor de cópias de segurança que se integra com a capacidade de instantâneo incremental do RP de Armazenamento ou um agente convidado para proteger a aplicação se o período de indisponibilidade planeado não for uma opção.

VMs num conjunto de dimensionamento ou conjunto de disponibilidade

As VMs num conjunto de dimensionamento ou grupo de disponibilidade considerados recursos efémeros não devem ser criadas cópias de segurança ao nível da VM, especialmente se a aplicação não tiver estado. Para aplicações com monitorização de estado implementadas num conjunto de dimensionamento ou conjunto de disponibilidade, considere proteger os dados da aplicação (por exemplo, uma base de dados ou um volume num agrupamento de armazenamento).

Replicação/ativação pós-falha manual

Para aplicações que requerem perda mínima de dados ou período de indisponibilidade mínimo, a replicação de dados pode ser ativada ao nível do SO convidado ou da aplicação para replicar dados para outra localização. Algumas aplicações, como a Microsoft SQL Server, suportam nativamente a replicação. Se a aplicação não suportar a replicação, pode utilizar software no SO convidado para replicar discos ou uma solução de parceiro que é instalada como agente no SO convidado.

Com esta abordagem, a aplicação é implementada numa cloud e os dados são replicados para a outra cloud no local ou para o Azure. Quando uma ativação pós-falha é acionada, a aplicação no destino terá de ser iniciada e anexada aos dados replicados antes de poder iniciar pedidos de manutenção.

Elevada disponibilidade/ativação pós-falha automática

Para aplicações sem estado que só podem tolerar alguns segundos ou minutos de tempo de inatividade, considere uma configuração de elevada disponibilidade. As aplicações de elevada disponibilidade foram concebidas para serem implementadas em várias localizações numa topologia ativa/ativa onde todas as instâncias podem atender pedidos. Para falhas de hardware local, a infraestrutura do Azure Stack Hub implementa a elevada disponibilidade na rede física com dois comutadores de rack superior. Para falhas ao nível da computação, o Azure Stack Hub utiliza vários nós numa unidade de escala e irá efetuar automaticamente a ativação pós-falha de uma VM. Ao nível da VM, pode utilizar conjuntos de dimensionamento ou VMs no conjunto de disponibilidade para garantir que as falhas de nós não derrubam a aplicação. A mesma aplicação teria de ser implementada numa localização secundária na mesma configuração. Para tornar a aplicação ativa/ativa, um balanceador de carga ou DNS pode ser utilizado para direcionar pedidos para todas as instâncias disponíveis.

Sem recuperação

Algumas aplicações no seu ambiente podem não precisar de proteção contra perdas de dados ou indisponibilidade não planeadas. Por exemplo, as VMs utilizadas para desenvolvimento e teste normalmente não precisam de ser recuperadas. A decisão é sua sem proteção para uma aplicação ou conjunto de dados.

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

Recomendação Comentários
Cópia de segurança/restauro de VMs para um destino de cópia de segurança externo já implementado no seu datacenter Recomendado Tire partido da infraestrutura de cópia de segurança existente e das competências operacionais. Certifique-se de que dimensiona a infraestrutura de cópia de segurança para que esteja pronta para proteger as instâncias de VM adicionais. Certifique-se de que a infraestrutura de cópia de segurança não está próxima da sua origem. Pode restaurar VMs para o Azure Stack Hub de origem, para uma instância secundária do Azure Stack Hub ou para o Azure.
Cópia de segurança/restauro de VMs para um destino de cópia de segurança externo dedicado ao Azure Stack Hub Recomendado Pode comprar uma nova infraestrutura de cópia de segurança ou aprovisionar uma infraestrutura de cópia de segurança dedicada para o Azure Stack Hub. Certifique-se de que a infraestrutura de cópia de segurança não está próxima da sua origem. Pode restaurar VMs para o Azure Stack Hub de origem, para uma instância secundária do Azure Stack Hub ou para o Azure.
Fazer cópia de segurança/restaurar VMs diretamente para o Azure global ou um fornecedor de serviços fidedigno Recomendado Desde que possa cumprir os requisitos regulamentares e de privacidade dos seus dados, pode armazenar as suas cópias de segurança no Azure global ou num fornecedor de serviços fidedigno. Idealmente, o fornecedor de serviços também está a executar o Azure Stack Hub para obter consistência na experiência operacional ao restaurar.
Replicar/efetuar a ativação pós-falha de VMs para uma instância separada do Azure Stack Hub Recomendado No caso de ativação pós-falha, tem de ter uma segunda cloud do Azure Stack Hub totalmente operacional para evitar um período de indisponibilidade prolongado da aplicação.
Replicar/efetuar a ativação pós-falha de VMs diretamente para o Azure ou um fornecedor de serviços fidedigno Recomendado Desde que possa cumprir os seus 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 fornecedor de serviços também está a executar o Azure Stack Hub para obter consistência na experiência operacional após a ativação pós-falha.
Implemente um destino de cópia de segurança no mesmo Azure Stack Hub que também aloja todas as aplicações protegidas pelo mesmo destino de cópia de segurança. Destino autónomo: Destino não recomendado
que replica dados de cópia de segurança externamente: Recomendado		 Se optar por implementar uma aplicação de cópia de segurança no Azure Stack Hub (para fins de otimização do restauro operacional), tem de garantir que todos os dados são copiados continuamente para uma localização de cópia de segurança externa.
Implementar a aplicação de cópia de segurança física no mesmo rack onde está instalada a solução do Azure Stack Hub Não suportado Atualmente, não pode ligar outros dispositivos à parte superior dos comutadores de rack que não fazem parte da solução original.

Considerações para uma VM IaaS restaurada

Terá de fazer algumas alterações à VM depois de restaurar a máquina a partir da cópia de segurança. Incluem-se:

  • Endereço MAC
    A placa de rede virtual obterá um novo endereço MAC. Não existe 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 na placa de rede virtual pode ser definido para corresponder ao original. Poderá ter de considerar se a VNET tem uma VPN S2S para um ambiente externo onde o endereço IP possa estar a ser utilizado.
  • Artefactos desnecessários
    Se a VM tiver sido criada uma cópia de segurança numa plataforma diferente, como o VMware vSphere, terá de seguir alguns passos adicionais para limpar quaisquer artefactos desnecessários da origem.

Passos seguintes

Este artigo forneceu diretrizes gerais para proteger as VMs de utilizador implementadas no Azure Stack Hub. Para obter informações sobre como utilizar os serviços do Azure para proteger VMs de utilizador, veja: