Proteger VMs implementadas no Azure Stack Hub – Robustas

  • Artigo

Utilize este artigo como um guia para desenvolver um plano para proteger máquinas virtuais (VMs) que os seus utilizadores implementam no Azure Stack Hub.

Para proteger contra perda de dados e período de indisponibilidade não planeado, implemente um plano de proteção de dados e recuperação após desastre para aplicações baseadas em VMs no Azure Stack Hub. O plano de proteção implementado dependerá dos requisitos empresariais e da conceção da aplicação. Este plano deve seguir a arquitetura estabelecida pela estratégia abrangente de continuidade de negócio e recuperação após desastre (BC/DR) da sua organização.

Objetivos de recuperação de aplicações

Determine a quantidade de tempo de inatividade e perda de dados que a sua organização pode tolerar para cada aplicação. Ao quantificar o tempo de inatividade e a perda de dados, pode criar um plano de recuperação que minimiza o impacto de um desastre na sua organização. Para cada aplicação, considere:

  • 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 em execução no prazo de 90 minutos após o 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 única base de dados que é efetuada uma cópia de segurança de hora a hora e não tem replicação para outras bases de dados, poderá perder até uma hora de dados.

Efetue uma avaliação para definir o RTO e o RPO para cada aplicação.

Outra métrica importante a considerar é 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 de negócio inaceitável porque não será possível restaurar o sistema no RTO definido.

Opções de proteção para VMs IaaS

Restauro da cópia de segurança

O esquema de proteção mais comum para aplicações baseadas em VM é utilizar software de cópia de segurança. Normalmente, a cópia de segurança de uma VM inclui o sistema operativo, a configuração do sistema operativo, os binários da aplicação e os dados persistentes da aplicação contidos na VM. As cópias de segurança são criadas através de um agente no SO convidado para capturar a aplicação, o SO ou os volumes/sistemas de ficheiros. Outra abordagem é sem agente ao depender da integração com as APIs do Azure Stack Hub para ler informações sobre a configuração da VM e instantâneos dos discos anexados à VM. Tenha em atenção que o Azure Stack Hub não suporta a cópia de segurança diretamente a partir do hipervisor.

Planear a sua estratégia de cópia de segurança

Planear a estratégia de cópia de segurança e definir requisitos de dimensionamento começa por quantificar o número de instâncias de VM que precisam de ser protegidas. Fazer uma cópia de segurança de todas as VMs no sistema pode não ser a forma mais eficaz de proteger a aplicação. Com o Azure Stack Hub, as VMs num conjunto de dimensionamento ou conjunto de disponibilidade não devem ser efetuadas cópias de segurança ao nível da VM. Estas VMs são consideradas efémeras, uma vez que o conjunto de VMs pode ser aumentado ou reduzido horizontalmente. Idealmente, quaisquer dados que precisem de ser mantidos estão num repositório separado, como uma base de dados ou um arquivo de objetos. Se as aplicações implementadas numa arquitetura de escalamento horizontal contiverem dados que têm de ser persistentes e protegidos, isso exigirá a cópia de segurança ao nível da aplicação através de capacidades nativas fornecidas pela aplicação ou dependendo de um agente.

Considerações importantes para criar cópias de segurança de VMs no Azure Stack:

  • Categorização
    • Considere um modelo em que os utilizadores optam pela cópia de segurança da VM.
    • Defina um contrato de nível de serviço de recuperação (SLA) com base na prioridade das aplicações ou no impacto para a empresa.
  • Dimensionamento
    • Considere cópias de segurança escalonadas ao embarcar num grande número de novas VMs (se for necessária uma cópia de segurança).
    • Avalie os produtos de cópia de segurança que podem capturar e transmitir dados de cópia de segurança de forma eficiente para minimizar o conteúdo dos recursos na solução.
    • Avalie os produtos de cópia de segurança que armazenam dados de cópia de segurança de forma eficiente com cópias de segurança incrementais ou diferenciais para minimizar a necessidade de cópias de segurança completas em todas as VMs no ambiente.
  • Restaurar
    • Os produtos de cópia de segurança podem restaurar discos virtuais, dados de aplicações numa VM existente ou todo o recurso da VM e discos virtuais associados. O esquema de restauro de que precisa depende de como planeia restaurar a aplicação. Por exemplo, pode ser mais fácil reimplementar o SQL Server a partir de um modelo e, em seguida, restaurar as bases de dados em vez de restaurar toda a VM ou conjunto de VMs.

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

Uma abordagem alternativa para suportar a recuperação é replicar dados para outro ambiente. Os dados podem ser direcionados para a aplicação, como a replicação da base de dados ou para o sistema operativo no SO convidado, utilizando um agente ou ao nível da VM ao integrar com as APIs do Azure Stack Hub. Em caso de desastre, é necessária a ativação pós-falha para a localização secundária. A ativação pós-falha pode ser processada nativamente pela aplicação, como com Os Grupos de Disponibilidade do SQL ou ao nível do SO convidado através de agentes ou tecnologia de cluster, ou ao nível da VM através de um produto de proteção.

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

As aplicações que suportam nativamente elevada disponibilidade ou dependem de software de cluster para alcançar uma elevada disponibilidade entre nós podem ser implementadas num grupo de VMs num Azure Stack Hub ou em várias instâncias do Azure Stack Hub. Em todos os casos, é necessário algum nível de balanceamento de carga para garantir que o tráfego da aplicação é encaminhado corretamente. Nesta configuração, a aplicação pode recuperar automaticamente de falhas. Para falhas de hardware locais, a infraestrutura do Azure Stack Hub implementa elevada disponibilidade e tolerância a falhas na infraestrutura física. Para falhas de nível de computação, o Azure Stack Hub utiliza vários nós numa unidade de escala numa configuração N-1. Ao nível da VM, a disponibilidade e os conjuntos de dimensionamento modelam cada nó na unidade de escala como um domínio de falha para garantir a antifinidade ao nível do nó para que as falhas do nó não derrubem uma aplicação distribuída.

Sem proteção

Algumas aplicações podem não ter dados que precisem de ser mantidos. Por exemplo, as VMs utilizadas para desenvolvimento e teste normalmente não precisam de ser recuperadas. Outro exemplo é uma aplicação sem estado que pode ser novamente implementada a partir de um pipeline CI/CD em caso de falha. É importante identificar as aplicações que não necessitam de proteção para evitar proteger desnecessariamente as VMs.

Produtos parceiros