Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Como organização, é imperativo adotar uma estratégia de continuidade de negócios e recuperação de desastres (BCDR) que mantenha seus dados seguros, aplicativos disponíveis e cargas de trabalho on-line durante interrupções planejadas e não planejadas.
Por meio da replicação de cargas de trabalho de máquinas virtuais (VMs) 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 de aplicativos e cargas de trabalho durante interrupções. Por exemplo, quando ocorre uma interrupção no site principal, você faz failover para um local secundário para acessar seus aplicativos. Assim que o site primário estiver sendo executado novamente, você poderá fazer failback para ele. Para obter mais informações, consulte Sobre a recuperação de site.
Para habilitar a replicação de VMs em dois carimbos do Azure Stack Hub, configure dois ambientes:
-
Ambiente de origem :
- O carimbo do Azure Stack Hub onde as VMs de locatário estão sendo executadas.
-
Ambiente de destino :
- Onde o Provedor de Recursos do Azure Site Recovery é executado.
Um componente essencial para o sucesso de um plano de continuidade de negócios e recuperação de desastres é o planejamento de capacidade. Durante o planejamento de capacidade, há alguns fatores a serem considerados:
RTO (Recovery Time Objetives, objetivos de tempo de recuperação) e RPO (Recovery Point Objetives, objetivos de ponto de recuperação) para as cargas de trabalho específicas que você deseja proteger.
Cargas de trabalho e características do aplicativo:
- Com que frequência os dados são alterados dentro da respetiva 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 construir um plano BCDR.
As seções a seguir listam os principais pontos a serem considerados de uma perspetiva do Azure Site Recovery. Cada plano BCDR é diferente e baseia-se nas especificidades das cargas de trabalho que pretende proteger. Portanto, esta lista não é abrangente.
Considerações sobre a fonte
No ambiente de origem, o Azure Stack Hub executa o dispositivo 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:
Quota:
- 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 o dispositivo VM do Azure Site Recovery:
O próprio dispositivo de VM do Azure Site Recovery tem os requisitos de dados definidos pelo tamanho da VM.
Ao planear a capacidade, verifique se a VM do aparelho tem armazenamento suficiente para executar os mecanismos de failback e reprotecção.
Observação
Se houver limitações de armazenamento, o fail-back e a nova proteção podem falhar com um erro Ocorreu uma mensagem de erro interno . Os usuários devem verificar os logs de eventos no dispositivo para confirmar o erro real do Azure Resource Manager. 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 alvo
No ambiente de destino, há duas partes a considerar para o planejamento de capacidade:
Os requisitos de serviço do Azure Site Recovery: quanto é consumido para executar o Azure Site Recovery, sem necessariamente proteger quaisquer cargas de trabalho.
Os requisitos de cargas de trabalho protegidas.
O ambiente de destino requer que um cofre do Azure Site Recovery seja criado para cada aplicação de Recuperação de Site, para proteger as VMs na origem (uma aplicação por cofre). Embora isso não seja uma limitação do ponto de vista da capacidade, deve ser levado em consideração ao planejar o projeto do ambiente geral.
Recursos do Azure Site Recovery RP
A instalação do Azure Site Recovery no Azure Stack Hub requer que você instale o Site Recovery Resource Provider (RP).
Observação
Com Microsoft.SiteRecovery-1.2301.2216.2287, o Azure Site Recovery no Azure Stack Hub não requer Hubs de Eventos como 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 |
|---|---|---|---|
| Recuperação de Sites do Azure | 18 | 64 GB | 384 GB |
Observação
Esses recursos são serviços do Azure Stack Hub no lado da administração do Azure Stack Hub. Uma vez instalada, a plataforma gerencia esses recursos.
Cargas de trabalho protegidas
Ao criar o plano BCDR, considere todos os aspetos das cargas de trabalho protegidas. A lista a seguir não está completa 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 a serem enviadas em lote de cada vez. Esse número é baseado na largura de banda estimada para concluir a replicação inicial em um determinado período de tempo.
- O RPO que pode ser alcançado para uma determinada largura de banda.
- O efeito no RPO desejado se uma largura de banda menor for provisionada.
Considerações sobre 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. Deve haver alocação de cota suficiente 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., é consumido no ambiente de destino. Esses recursos tornam-se 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 ocorrer um failover, no decorrer das operações normais, multiplique o número de discos replicados pelo RPO médio. Por exemplo, você pode ter (2 MB * 250 s). A conta de armazenamento em cache é normalmente de alguns KB a 500 MB por disco.
Se houver um failover, no pior dos cenários, 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 a funcionar, mas outras estiverem a funcionar, pode haver no máximo um dia de registo de diferenças (difflog) na conta de armazenamento antes que o Azure Site Recovery decida expirar.
Retroceder para a nova VM. Calcule a soma do tamanho dos discos de cada lote.
- O disco inteiro deve ser copiado para a conta de armazenamento em cache para que a VM de destino seja aplicada, já que o destino é um disco vazio.
- Os dados associados são excluídos uma vez copiados, mas é provável que haja 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 essa perceção para obter uma linha de base para seu próprio aplicativo, mas cada carga de trabalho difere:
Configuração
| Tamanho do bloco | Desempenho/disco |
|---|---|
| 2 MB | 2 MB/s |
| 64 KB | 2 MB/s |
| 8 KB | 1 MB/s |
| 8 KB | 2 MB/s |
Resultado
| Número de discos suportados | Rendimento total | Total OPS | Gargalo |
|---|---|---|---|
| 68 | 136 MB/s | 68 | armazenamento |
| 60 | 120 MB/s | 2048 | armazenamento |
| 28 | 28 MB/s | 3584 | CPU e memória do Azure Site Recovery |
| 16 | 32 MB/s | 4096 |
Observação
8 Kb é o menor tamanho de bloco de dados suportado pelo Azure Site Recovery. Qualquer alteração inferior a 8 Kb é tratada como 8 Kb.
Para testar ainda mais, geramos um tipo consistente de carga de trabalho; por exemplo, alterações consistentes de armazenamento em blocos de 8 Kb que totalizam até 1 MB/s por disco. Este cenário não é provável em uma carga de trabalho real, dado que as mudanças podem acontecer em vários momentos 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 através do mesmo dispositivo de VM do Azure Site Recovery.
Cada VM gera em intervalos aleatórios, pelo menos duas vezes por hora, blocos aleatórios totalizando 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 do Azure Site Recovery.
Observação
Estes números devem ser utilizados apenas como base de referência. Eles não necessariamente escalam linearmente. Adicionar outro lote do mesmo número de VMs pode ter menos impacto do que o inicial. Os resultados dependem muito do tipo de cargas de trabalho utilizadas.
Como deve planear e testar
As cargas de trabalho de aplicativos e soluções têm determinados requisitos de RTO (Recovery Time Objetive, objetivo de tempo de recuperação) e RPO (Recovery Point Objetive, objetivo de ponto de recuperação). O projeto eficaz de continuidade de negócios e recuperação de desastres (BCDR) aproveita os recursos no nível da plataforma que atendem a esses requisitos, à medida que usamos os mecanismos específicos da solução. Para projetar recursos BCDR, capture os requisitos de recuperação de desastres (DR) da plataforma e considere todos esses fatores em seu projeto:
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 para implementações em várias regiões para failover, com proximidade de componentes para assegurar desempenho. Você pode enfrentar operações de aplicativos 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 do tipo 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.
- As redes de produção e DR com 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 BCDR que forneça conectividade simultânea a todos os sites.
Dimensionamento de 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. Isto deve-se à forma como a história dos marcadores de disco acontece. Esta alocação não é um aumento de 2x, uma vez que inclui apenas alterações nos dados. Dependendo do tipo de dados e das alterações esperadas, as políticas de replicação que possuam entre 1,5x a 2x mais armazenamento no destino garantem que os processos de transferência em caso de falha não apresentem preocupações.
- Você pode considerar ter o ambiente de destino do Azure Stack Hub 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 certas cargas de trabalho diminuem; 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.
Deve testar o BCDR e validá-lo regularmente. Você pode fazer isso usando processos de teste de failover ou transferindo a totalidade das cargas de trabalho para validar os fluxos de início a fim.