Planejamento de capacidade usando o Azure Site Recovery
Como uma organização, é imperativo adotar uma estratégia de BCDR (continuidade dos negócios e recuperação de desastres) que mantenha seus dados seguros, aplicativos disponíveis e cargas de trabalho online durante interrupções planejadas e não planejadas.
Por meio da replicação de cargas de trabalho de VMs (máquinas virtuais) de um site primário para um local secundário, o Azure Site Recovery no Azure Stack Hub fornece serviços que podem dar suporte à segurança de dados organizacionais, disponibilidade do aplicativo e cargas de trabalho durante interrupções. Por exemplo, quando ocorre uma interrupção em seu site primário, você faz failover para um local secundário para acessar seus aplicativos. Assim que o site primário estiver em execução novamente, você poderá fazer failback para ele. Para obter mais informações, confira Sobre o Site Recovery.
Para habilitar a replicação de VMs em dois selos do Azure Stack Hub, configure dois ambientes:
-
Ambiente de origem :
- O selo do Azure Stack Hub em que as VMs de locatário estão em execução.
-
Ambiente de destino:
- Onde o Provedor de Recursos Site Recovery do Azure é executado.
Um componente essencial para o sucesso de um plano de continuidade dos negócios e recuperação de desastres é o planejamento de capacidade. Durante o planejamento da capacidade, há alguns fatores a serem considerados:
RTO (objetivos de tempo de recuperação) e RPO (objetivos de ponto de recuperação) para as cargas de trabalho específicas que você deseja proteger.
Cargas de trabalho e as características do aplicativo:
- Com que frequência os dados são alterados na respectiva VM.
- Quantos dados são gerados ou removidos?
- Qual é a aparência do design do aplicativo e muito mais?
Tamanhos de VM, o número de discos e como cada VM está vinculada a outras VMs.
- Para soluções que exigem várias VMs, entenda em que ordem essas VMs precisam ser iniciadas.
Largura de banda de rede entre os ambientes de origem e de destino. Esse componente pode afetar RPOs.
Cada um desses pontos é importante e tem amplas implicações ao criar um plano BCDR.
As seções a seguir listam os pontos de main a serem considerados de uma perspectiva Site Recovery do Azure. Cada plano BCDR é diferente e se baseia nas especificidades das cargas de trabalho que você planeja proteger. Portanto, essa lista não é abrangente.
Considerações sobre a origem
No ambiente de origem, o Azure Stack Hub executa o dispositivo de VM do Azure Site Recovery. A VM é uma VM Standard_DS4_v2 (8 vCPUs, memória de 28 Gb, 32 discos de dados) que é executada na assinatura de usuário do Azure Stack Hub.
No ambiente de origem, considere as seguintes áreas:
Cota:
- Você deve ter cota suficiente para criar o dispositivo de VM do Azure Site Recovery. Você precisa de um ou mais, dependendo do plano geral.
Armazenamento para a VM do Azure Site Recovery dispositivo:
A VM Site Recovery do Azure dispositivo em si tem os requisitos de dados definidos pelo tamanho da VM.
Ao planejar a capacidade, verifique se a VM dispositivo tem armazenamento suficiente para exercer os mecanismos de fail-back e proteger novamente.
Observação
Se houver limitações de armazenamento, o fail-back e a nova proteção poderão falhar com um erro Uma mensagem de erro interno. Os usuários devem marcar os logs de eventos no dispositivo para confirmar o erro de Resource Manager real do Azure. Para obter mais informações, consulte Problemas conhecidos do Azure Site Recovery.
Largura de banda:
- A replicação inicial gera alto uso de largura de banda.
- As alterações em cada VM são replicadas, dependendo das políticas de replicação e de cada tipo de aplicativo.
Considerações de destino
No ambiente de destino, há duas partes a serem consideradas para planejamento de capacidade:
O Azure Site Recovery requisitos de serviço: quanto é consumido para executar o Azure Site Recovery, sem necessariamente proteger nenhuma carga de trabalho.
Os requisitos de cargas de trabalho protegidas.
O ambiente de destino requer que um cofre de Site Recovery do Azure seja criado para cada Site Recovery dispositivo, para proteger as VMs da origem (uma dispositivo por cofre). Embora essa não seja uma limitação de uma perspectiva de capacidade, ela deve ser levada em consideração ao planejar o design do ambiente geral.
Recursos de RP Site Recovery do Azure
A instalação do Site Recovery do Azure no Azure Stack Hub exige que você instale o RP (Provedor de Recursos Site Recovery).
Observação
Com Microsoft.SiteRecovery-1.2301.2216.2287, o Azure Site Recovery no Azure Stack Hub não requer Hubs de Eventos como uma dependência.
Esse serviço é criado na assinatura de administrador do Azure Stack Hub e gerenciado pelo próprio Azure Stack Hub, portanto, não há nenhuma configuração necessária. No entanto, como em qualquer serviço, esses recursos consomem memória, armazenamento e têm determinadas vCPUs alocadas:
| Serviço | vCore | Memória | Tamanho do disco |
|---|---|---|---|
| Azure Site Recovery | 12 | 42 GB | 1,4 TB |
Observação
Esses recursos são serviços do Azure Stack Hub no lado administrativo do Azure Stack Hub. Depois de instalada, a plataforma gerencia esses recursos.
Cargas de trabalho protegidas
Ao criar o plano BCDR, considere todos os aspectos das cargas de trabalho protegidas. A lista a seguir não está concluída e deve ser tratada como um ponto de partida:
Tamanho da VM, número de discos, tamanho do disco, IOPS, rotatividade de dados e novos dados criados.
Considerações sobre largura de banda de rede:
- A largura de banda de rede necessária para a replicação delta.
- A quantidade de taxa de transferência, no ambiente de destino, que o Azure Site Recovery pode obter do ambiente de origem.
- O número de VMs para lote por vez. Esse número se baseia na largura de banda estimada para concluir a replicação inicial em um determinado período de tempo.
- O RPO que pode ser obtido para uma determinada largura de banda.
- O efeito no RPO desejado se a largura de banda inferior for provisionada.
Considerações de armazenamento:
- Quantos dados são necessários para a replicação inicial.
- Quantos pontos de recuperação são mantidos e como os dados aumentam, para cada VM protegida, durante esses intervalos.
- Quantas cotas precisam ser atribuídas às assinaturas de usuário do Azure Stack Hub de destino, para que os usuários tenham alocação suficiente.
- A conta de armazenamento em cache para replicação.
Considerações de computação:
- Quando ocorre failover, as VMs são iniciadas nas assinaturas de usuário do Azure Stack Hub de destino. A alocação de cota suficiente deve estar em vigor para poder iniciar esses recursos de VM.
- Durante a proteção da VM, quando a VM protegida está ativa no ambiente de origem, nenhum recurso relacionado à VM, como vCPU, memória etc. são consumidos no ambiente de destino. Esses recursos se tornam relevantes somente durante um processo de failover, como failover de teste.
Para o escopo do Azure Site Recovery no Azure Stack Hub, aqui está um ponto de partida para cálculos, especialmente para a conta de armazenamento de cache usada:
Se houver um failover, durante operações normais, multiplique o número de discos replicados pelo RPO médio. Por exemplo, você pode ter (2 MB * 250s). A conta de armazenamento em cache normalmente é de alguns KB a 500 MB por disco.
Se houver um failover, dado o pior cenário, multiplique o número de discos replicados pelo RPO médio em um dia inteiro.
Importante
Se algumas partes do Azure Site Recovery não estiverem funcionando, mas outras estiverem funcionando, poderá haver no máximo um dia de difflog na conta de armazenamento antes que o Azure Site Recovery decida atingir o tempo limite.
Failback para a nova VM. Calcule a soma do tamanho dos discos de cada lote.
- Todo o disco deve ser copiado para a conta de armazenamento de cache para que a VM de destino seja aplicada, pois o destino é um disco vazio.
- Os dados associados são excluídos uma vez copiados, mas é provável que vejam o pico de uso com a soma de todos os tamanhos de disco.
Crie o plano BDCR com base nas especificidades da solução que você está tentando proteger.
A tabela a seguir é um exemplo de testes executados em nossos ambientes. Você pode usar esse insight para obter uma linha de base para seu próprio aplicativo, mas cada carga de trabalho difere:
Configuração
| Tamanho do bloco | Taxa de transferência/disco |
|---|---|
| 2 MB | 2 MB/s |
| 64 KB | 2 MB/s |
| 8 KB | 1 MB/s |
| 8 KB | 2 MB/s |
Result
| Número de discos com suporte | Taxa de transferência total | Total OPS | Gargalo |
|---|---|---|---|
| 68 | 136 MB/s | 68 | armazenamento |
| 60 | 120 MB/s | 2.048 | armazenamento |
| 28 | 28 MB/s | 3584 | CPU e memória Site Recovery do Azure |
| 16 | 32 MB/s | 4096 |
Observação
8Kb é o menor tamanho de bloco de dados que o Azure Site Recovery dá suporte. Quaisquer alterações inferiores a 8 Kb são tratadas como 8Kb.
Para testar ainda mais, geramos um tipo consistente de carga de trabalho; por exemplo, alterações de armazenamento consistentes em blocos de 8 Kb que totalizam até 1 MB/s por disco. Esse cenário provavelmente não está em uma carga de trabalho real, dado que as alterações podem ocorrer em várias horas do dia ou em picos de vários tamanhos.
Para replicar esses padrões aleatórios, também testamos cenários com:
- 120 VMs (80 Windows, 40 Linux) protegidas pela mesma VM do Azure Site Recovery dispositivo.
Cada VM gerando em intervalos aleatórios, pelo menos duas vezes por hora, blocos aleatórios que totalizam 5 Gb de dados em cinco arquivos.
A replicação foi bem-sucedida em todas as 120 VMs com uma carga baixa a média nos serviços de Site Recovery do Azure.
Observação
Esses números devem ser usados apenas como uma linha de base. Eles não são necessariamente dimensionados linearmente. Adicionar outro lote do mesmo número de VMs pode ter menos impacto do que o inicial. Os resultados são altamente dependentes do tipo de cargas de trabalho usadas.
Como você deve planejar e testar
Os aplicativos e as cargas de trabalho de solução têm determinados requisitos de RTO (objetivo de tempo de recuperação) e RPO (objetivo de ponto de recuperação). O design eficaz de BCDR (continuidade dos negócios e recuperação de desastres) aproveita os recursos de nível de plataforma que atendem a esses requisitos, pois usamos os mecanismos específicos da solução. Para criar recursos de BCDR, capture os requisitos de DR (recuperação de desastres da plataforma) e considere todos esses fatores em seu design:
Requisitos de disponibilidade de aplicativos e dados:
- Requisitos de RTO e RPO para cada carga de trabalho.
- Suporte para padrões de disponibilidade ativo-ativo e ativo-passivo.
Suporte a implantações de várias regiões para failover, com proximidade dos componentes visando o desempenho. Você pode experimentar operações de aplicativo com funcionalidade reduzida ou desempenho degradado durante uma interrupção.
Observação
O aplicativo pode saber nativamente para ser executado ou ter determinados componentes que podem ser executados em vários ambientes do Azure Stack Hub. Nesse caso, você pode usar o Azure Site Recovery para replicar apenas as VMs com os componentes que não têm essa funcionalidade; por exemplo, uma solução de tipo de front-end ou back-end, na qual você pode implantar os front-ends em ambientes do Azure Stack Hub.
Evite usar intervalos de endereços IP sobrepostos em redes de produção e DR.
- Redes de produção e DR que têm endereços IP sobrepostos exigem um processo de failover que pode complicar e atrasar o failover do aplicativo. Quando possível, planeje uma arquitetura de rede de BCDR que forneça conectividade simultânea a todos os sites.
Dimensionando seus ambientes de destino:
- Se você estiver usando a origem e o destino de maneira 1:1, aloque um pouco mais de armazenamento em seu ambiente de destino. Isso ocorre devido à maneira como o histórico dos indicadores de disco acontece. Essa alocação não é um aumento de 2x, pois inclui apenas alterações nos dados. Dependendo do tipo de dados e das alterações esperadas, e as políticas de replicação com um armazenamento de 1,5x a 2x a mais no destino garantem que os processos de failover não apresentem nenhuma preocupação.
- Você pode considerar ter o ambiente do Azure Stack Hub de destino como destino para várias fontes do Azure Stack Hub. Nesse caso, você está reduzindo o custo geral, mas deve planejar o que acontece quando determinadas cargas de trabalho ficam inativas; por exemplo, qual fonte deve ser priorizada.
- Se o ambiente de destino for usado para executar outras cargas de trabalho, o plano BCDR deverá incluir o comportamento dessas cargas de trabalho. Por exemplo, você pode executar as VMs de Desenvolvimento/Teste no ambiente de destino e, se ocorrer um problema com seu ambiente de origem, poderá desativar todas as VMs no destino para garantir que recursos suficientes estejam disponíveis para iniciar as VMs protegidas.
Você deve testar o BCDR e validar regularmente. Você pode fazer isso usando processos de failover de teste ou movendo todas as cargas de trabalho para validar os fluxos de ponta a ponta.