Planeamento de capacidade com o Azure Site Recovery
Enquanto organização, é imperativo adotar uma estratégia de continuidade empresarial e recuperação após desastre (BCDR) que mantenha os seus dados seguros, as aplicações disponíveis e as cargas de trabalho online durante interrupções planeadas e não planeadas.
Através da replicação de cargas de trabalho de máquinas virtuais (VMs) de um site primário para uma localização secundária, o Azure Site Recovery no Azure Stack Hub fornece serviços que podem suportar a segurança de dados organizacionais, disponibilidade de aplicações e cargas de trabalho durante falhas. Por exemplo, quando ocorre uma indisponibilidade no seu site primário, efetua a ativação pós-falha para uma localização secundária para aceder às suas aplicações. Assim que o site primário estiver novamente em execução, pode efetuar a reativação pós-falha. Para obter mais informações, veja Acerca de Site Recovery.
Para ativar a replicação de VMs em dois selos do Azure Stack Hub, configure dois ambientes:
-
Ambiente de origem :
- O carimbo do Azure Stack Hub onde as VMs do inquilino estão em execução.
-
Ambiente de destino:
- Onde o Fornecedor de Recursos Site Recovery do Azure é executado.
Um componente essencial para o sucesso de um plano de continuidade de negócio e recuperação após desastre é o planeamento de capacidade. Durante o planeamento da capacidade, existem alguns fatores a considerar:
Objetivos de tempo de recuperação (RTO) e objetivos de ponto de recuperação (RPO) para as cargas de trabalho específicas que pretende proteger.
Cargas de trabalho e as características da aplicação:
- Com que frequência os dados são alterados na respetiva VM.
- Quantos dados são gerados ou removidos?
- Qual é o aspeto da estrutura da aplicação e muito mais?
Tamanhos de VM, o número de discos e a forma como cada VM está associada a outras VMs.
- Para soluções que requerem várias VMs, compreenda por que ordem essas VMs têm de ser iniciadas.
Largura de banda de rede entre os ambientes de origem e de destino. Este componente pode afetar os RPOs.
Cada um destes pontos é importante e tem amplas implicações na criação de um plano BCDR.
As secções seguintes listam os pontos principais a considerar de uma perspetiva Site Recovery do Azure. Cada plano BCDR é diferente e baseia-se nas especificações das cargas de trabalho que planeia proteger. Portanto, esta lista não é abrangente.
Considerações de origem
No ambiente de origem, o Azure Stack Hub executa a aplicação Azure Site Recovery VM. A VM é uma VM de Standard_DS4_v2 (8 vCPUs, 28 Gb de memória e 32 discos de dados) que é executada na subscrição de utilizador do Azure Stack Hub.
No ambiente de origem, considere as seguintes áreas:
Quota:
- Deve ter quota suficiente para criar a aplicação de VM do Azure Site Recovery. Precisa de um ou mais, consoante o plano geral.
Armazenamento para a aplicação de VM do Azure Site Recovery:
A própria aplicação de VM do Azure Site Recovery tem os requisitos de dados definidos pelo respetivo tamanho de VM.
Ao planear a capacidade, confirme que a VM da aplicação tem armazenamento suficiente para exercer os mecanismos de reativação pós-falha e de nova proteção.
Nota
Se existirem limitações de armazenamento, a reativação pós-falha e a nova proteção podem falhar com um erro Ocorreu um erro interno . Os utilizadores devem verificar os registos de eventos na aplicação para confirmar o erro real do Azure Resource Manager. Para obter mais informações, veja Problemas conhecidos do Azure Site Recovery.
Largura de banda:
- A replicação inicial gera uma utilização de largura de banda elevada.
- As alterações em cada VM são replicadas, consoante as políticas de replicação e cada tipo de aplicação.
Considerações de destino
No ambiente de destino, existem duas partes a considerar para o planeamento da 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 a criação de um cofre do Azure Site Recovery para cada Site Recovery aplicação, para proteger as VMs da origem (uma aplicação por cofre). Embora esta não seja uma limitação do ponto de vista da capacidade, deve ser levada em consideração ao planear a conceção do ambiente geral.
Recursos RP do Azure Site Recovery
A instalação do Azure Site Recovery no Azure Stack Hub requer que instale o Fornecedor de Recursos (RP) Site Recovery.
Nota
Com Microsoft.SiteRecovery-1.2301.2216.2287, o Azure Site Recovery no Azure Stack Hub não necessita de Hubs de Eventos como dependência.
Este serviço é criado na subscrição de administrador do Azure Stack Hub e gerido pelo próprio Azure Stack Hub, pelo que não é necessária qualquer configuração. No entanto, tal como acontece com qualquer serviço, estes 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 |
Nota
Estes recursos são serviços do Azure Stack Hub do lado da administração do Azure Stack Hub. Depois de instalada, a plataforma gere estes recursos.
Cargas de trabalho protegidas
Ao criar o plano BCDR, considere todos os aspetos das cargas de trabalho protegidas. A lista seguinte 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, alterações a dados e novos dados criados.
Considerações sobre a largura de banda de rede:
- A largura de banda de rede necessária para a replicação delta.
- A quantidade de débito, no ambiente de destino, que o Azure Site Recovery pode obter a partir do ambiente de origem.
- O número de VMs a colocar em lote de cada vez. Este número baseia-se na largura de banda estimada para concluir a replicação inicial num determinado período de tempo.
- O RPO que pode ser alcançado para uma determinada largura de banda.
- O efeito no RPO pretendido se a largura de banda inferior for aprovisionada.
Considerações de armazenamento:
- A quantidade de dados necessária para a replicação inicial.
- Quantos pontos de recuperação são mantidos e como os dados aumentam, para cada VM protegida, durante estes intervalos.
- Quantas quotas têm de ser atribuídas às subscrições de utilizador do Azure Stack Hub de destino, para que os utilizadores tenham alocação suficiente.
- A conta de armazenamento em cache para replicação.
Considerações de computação:
- Quando ocorre a ativação pós-falha, as VMs são iniciadas nas subscrições de utilizador do Azure Stack Hub de destino. Tem de estar implementada uma alocação de quota suficiente para poder iniciar estes recursos de VM.
- Durante a proteção da VM, quando a VM protegida está ativa no ambiente de origem, não são consumidos recursos relacionados com a VM, como vCPU, memória, etc. no ambiente de destino. Estes recursos tornam-se relevantes apenas durante um processo de ativação pós-falha, como a ativação pós-falha de teste.
Para o âmbito do Azure Site Recovery no Azure Stack Hub, eis um ponto de partida para cálculos, especialmente para a conta de armazenamento em cache utilizada:
Se existir uma ativação pós-falha, durante as operações normais, multiplique o número de discos replicados pelo RPO médio. Por exemplo, pode ter (2 MB * 250s). Normalmente, a conta de armazenamento em cache é de alguns KB a 500 MB por disco.
Se existir uma ativação pós-falha, tendo em conta o pior cenário, multiplique o número de discos replicados pelo RPO médio durante 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 diferença na conta de armazenamento antes de o Azure Site Recovery decidir exceder o limite de tempo.
Reativação pós-falha para a nova VM. Calcular a soma do tamanho dos discos de cada lote.
- O disco inteiro tem de ser copiado para a conta de armazenamento de cache para que a VM de destino se aplique, uma vez que o destino é um disco vazio.
- Os dados associados são eliminados uma vez copiados, mas é provável que veja o pico de utilização com a soma de todos os tamanhos de disco.
Crie o plano BDCR com base nas especificidades da solução que está a tentar proteger.
A tabela seguinte é um exemplo de testes executados nos nossos ambientes. Pode utilizar estas informações para obter uma linha de base para a sua própria aplicação, mas cada carga de trabalho difere:
Configuração
| Tamanho do bloco | Débito/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 | Débito total | Total OPS | Estrangulamento |
|---|---|---|---|
| 68 | 136 MB/s | 68 | storage |
| 60 | 120 MB/s | 2048 | storage |
| 28 | 28 MB/s | 3584 | CPU e memória do Azure Site Recovery |
| 16 | 32 MB/s | 4096 |
Nota
8Kb é o tamanho de bloco mais pequeno dos dados suportados pelo Azure Site Recovery. Quaisquer alterações inferiores a 8 Kb são tratadas como 8 Kb.
Para testar ainda mais, gerámos 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. Este cenário não é provável numa 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 estes padrões aleatórios, também testámos cenários com:
- 120 VMs (80 Windows, 40 Linux) protegidas através da mesma aplicação de VM do Azure Site Recovery.
Cada VM gerada em intervalos aleatórios, pelo menos duas vezes por hora, bloqueia aleatoriamente um total de 5 Gb de dados em cinco ficheiros.
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.
Nota
Estes números devem ser utilizados apenas como linha de base. Não dimensionam necessariamente 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 utilizadas.
Como deve planear e testar
As aplicações e as cargas de trabalho de solução têm determinados requisitos de objetivo de tempo de recuperação (RTO) e objetivo de ponto de recuperação (RPO). A continuidade de negócio e a recuperação após desastre (BCDR) eficazes tiram partido das capacidades ao nível da plataforma que cumprem estes requisitos, uma vez que utilizamos os mecanismos específicos da solução. Para conceber capacidades BCDR, capture os requisitos de recuperação após desastre da plataforma (DR) e considere todos estes fatores na sua conceção:
Requisitos de disponibilidade de aplicações 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 de várias regiões para ativação pós-falha, com proximidade de componentes para desempenho. Pode experimentar operações de aplicações com funcionalidade reduzida ou desempenho degradado durante uma indisponibilidade.
Nota
A aplicação pode saber nativamente para ser executada ou ter determinados componentes que são capazes de ser executados em vários ambientes do Azure Stack Hub. Nesse caso, pode utilizar o Azure Site Recovery para replicar apenas as VMs com os componentes que não têm esta funcionalidade; por exemplo, uma solução de front-end ou de back-end, na qual pode implementar os front-ends em ambientes do Azure Stack Hub.
Evite utilizar 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 requerem um processo de ativação pós-falha que pode complicar e atrasar a ativação pós-falha da aplicação. Sempre que possível, planeie uma arquitetura de rede BCDR que forneça conectividade simultânea a todos os sites.
Dimensionar os ambientes de destino:
- Se estiver a utilizar a origem e o destino de forma 1:1, aloque um pouco mais de armazenamento no seu ambiente de destino. Isto deve-se à forma como o histórico dos marcadores de disco acontece. Esta alocação não é um aumento de 2x, uma vez que inclui apenas alterações aos dados. Consoante o tipo de dados e as alterações esperadas, as políticas de replicação com um armazenamento de 1,5x a 2x no destino garantem que os processos de ativação pós-falha não apresentam preocupações.
- Poderá considerar ter o ambiente do Azure Stack Hub de destino como o destino de várias origens do Azure Stack Hub. Neste caso, está a reduzir o custo global, mas tem de planear o que acontece quando determinadas cargas de trabalho descem; por exemplo, que origem tem de ser priorizada.
- Se o seu ambiente de destino for utilizado para executar outras cargas de trabalho, o plano BCDR tem de incluir o comportamento destas cargas de trabalho. Por exemplo, pode executar as VMs Dev/Test no ambiente de destino e, se ocorrer um problema com o ambiente de origem, pode desativar todas as VMs no destino para garantir que estão disponíveis recursos suficientes para iniciar as VMs protegidas.
Deve testar o BCDR e validar regularmente. Pode fazê-lo através de processos de ativação pós-falha de teste ou ao mover todas as cargas de trabalho para validar os fluxos ponto a ponto.