Proteger VMs implantados no Azure Stack Hub - Modular Data Center (MDC)

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

Para proteger contra a perda de dados e o tempo de inatividade não planeado, implemente um plano de proteção de dados e recuperação de desastres para aplicações baseadas em VM 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 o quadro estabelecido pela estratégia abrangente de continuidade de negócios e recuperação de desastres (BC/DR) da sua organização. Para uma visão geral de alto nível das considerações BC/DR para O Azure Stack Hub, consulte Azure Stack: Considerações para a continuidade do negócio e recuperação de desastres.

Objetivos de recuperação de candidaturas

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 minimize 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 para que uma aplicação possa estar indisponível após um incidente. Por exemplo, um RTO de 90 minutos significa que você deve ser capaz de restaurar a app para um estado de funcionamento dentro de 90 minutos a partir do início de um desastre. Se tiver um RTO baixo, poderá manter uma segunda implantação continuamente em modo de espera para proteger contra uma paragem 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 é apoiada a cada hora e não tem replicação noutras bases de dados, poderá perder até uma hora de dados.

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

Outra métrica importante a considerar é o Tempo Médio para Recuperar (MTTR), que é o tempo médio que leva para restaurar a aplicação após uma falha. O MTTR é um valor empírico para um sistema. Se o MTTR exceder o RTO, então uma falha no sistema causará uma perturbação inaceitável do negócio porque não será possível restaurar o sistema dentro do RTO definido.

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

Backback-restore

O esquema de proteção mais comum para aplicações baseadas em VM é usar software de backup. O backup de um VM normalmente inclui o sistema operativo, a configuração do sistema operativo, binários de aplicações e dados de aplicação persistentes contidos dentro do VM. As cópias de segurança são criadas utilizando um agente no so convidado para capturar aplicação, SISTEMA ou sistema de ficheiros/volumes. Outra abordagem é sem agente, confiando na integração com as APIs do Azure Stack Hub para ler informações sobre a configuração VM e visualizar os discos ligados ao VM. Por favor, note que o Azure Stack Hub não suporta o backup diretamente do hipervisor.

Planejando a sua estratégia de backup

Planear a sua estratégia de backup e definir os requisitos de escala começa por quantificar o número de instâncias VM que precisam de ser protegidas. O backup de todos os VMs no sistema pode não ser a forma mais eficaz de proteger a aplicação. Com o Azure Stack Hub, os VMs num conjunto de escala ou disponibilidade não devem ser apoiados ao nível de VM. Estes VMs são considerados efémeros, uma vez que o conjunto de VMs pode ser dimensionado para dentro ou para fora. Idealmente, quaisquer dados que precisem de ser persistidos estão num repositório separado, como uma base de dados ou uma loja de objetos. Se as aplicações implementadas numa arquitetura de escala contiver dados que devem ser persistidos e protegidos, então isso exigirá backup de nível de aplicação usando capacidades nativas fornecidas pela aplicação ou confiando num agente.

Considerações importantes para apoiar os VMs na Azure Stack:

  • Categorização
    • Considere um modelo onde os utilizadores optem por cópia de segurança 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 o negócio.
  • Dimensionamento
    • Considere cópias de segurança escalonadas ao embarcar num grande número de novos VMs (se for necessário backup).
    • Avalie os produtos de backup que possam capturar e transmitir de forma eficiente dados de backup para minimizar o conteúdo dos recursos na solução.
    • Avalie os produtos de backup que armazenam eficientemente dados de backup usando backups incrementais ou diferenciais para minimizar a necessidade de cópias de segurança completas em todos os VMs no ambiente.
  • Restaurar
    • Os produtos de backup podem restaurar discos virtuais, dados de aplicações dentro de um VM existente, ou todo o recurso VM e discos virtuais associados. O esquema de restauro que precisa depende de como planeia restaurar a app. Por exemplo, pode ser mais fácil recolocar SQL servidor a partir de um modelo e, em seguida, restaurar as bases de dados em vez de restaurar todo o VM ou conjunto de VMs.

Replicação/falha manual

Uma abordagem alternativa para apoiar a recuperação é replicar dados para outro ambiente. Os dados podem ser atentos à aplicação como a replicação da base de dados ou ao sistema operativo no sistema operativo do so convidado utilizando um agente, ou ao nível de VM, integrando-se com APIs do Azure Stack Hub. Em caso de catástrofe, é necessário falhar até à localização secundária. A falha pode ser tratada de forma nativa pela aplicação, como com SQL Grupos de Disponibilidade ou ao nível de OS convidados utilizando agentes ou tecnologia de cluster, ou a nível VM utilizando um produto de proteção.

Alta disponibilidade/falha automática

Aplicações que suportam de forma nativa alta disponibilidade ou dependem de software de cluster para alcançar uma alta disponibilidade através de nós podem ser implementadas através de um grupo de VMs em um Azure Stack Hub ou em vários exemplos do Azure Stack Hub. Em todos os casos, é necessário um certo equilíbrio de carga para garantir que o tráfego de aplicações é encaminhado corretamente. Nesta configuração, a aplicação pode recuperar automaticamente de falhas. Para falhas de hardware locais, a infraestrutura Azure Stack Hub implementa alta disponibilidade e tolerância a falhas na infraestrutura física. Para falhas de nível de cálculo, o Azure Stack Hub utiliza múltiplos nós numa unidade de escala numa configuração N-1. Ao nível de VM, a disponibilidade e a escala definem cada nó na unidade de escala como um domínio de falha para garantir a anti-afinidade ao nível do nó para que as falhas no nó não derrubem uma aplicação distribuída.

Sem proteção

Algumas aplicações podem não ter dados que precisam de ser persistidos. Por exemplo, os VM utilizados para o desenvolvimento e teste normalmente não precisam de ser recuperados. Outro exemplo é uma aplicação apátrida que pode ser reencam unida a partir de um oleoduto CI/CD em caso de falha. É importante identificar as aplicações que não requerem proteção para evitar a proteção desnecessária dos VM.

Passos seguintes

Este artigo forneceu orientações gerais para a proteção dos VM do utilizador implantados na Pilha Azure. Para obter informações sobre a utilização dos serviços Azure para proteger os VM do utilizador, consulte:

Produtos parceiros