No primeiro post sobre Hyper-V Replica abordamos as vantagens sobre réplica de storage e como iniciar a configuração e réplica http://www.marcelosincic.com.br/blog/post/Utilizando-o-Hyper-V-Replica-Parte-1e28093Vantagens-e-Primeira-Replica.aspx
Neste segundo post vamos abordar como o RTO e RPO são importantes e como o Hyper-V Replica se encaixa nestes conceitos.
Recovery Time Objective e Recovery Point Objective
Basicamente os termos RTO e RPO indicam os objetivos que uma solução de desastre deve cumprir:
- RTO – Tempo máximo para se recolocar o serviço em produção
- RPO – Tempo máximo de dados que podem ser “perdidos” entre o evento de desastre e o ambiente restaurado
Um bom exemplo de como estes valores se relacionam e o que significam pode ser explicado no gráfico abaixo:
No exemplo acima conseguimos “enxergar” claramente o RTO e o RPO:
- RTO foi de 5 horas e 3 minutos, entre as 05:15 e as 10:18
- RPO foi de 3 horas e 15 minutos, entre as 02:00 e as 05:15, uma vez que o backup foi realizado as 2 da manhã
Como determinar o RTO e RPO
Estes valores são determinados por um plano que é chamado de DRP (Disaster Recovery Plan) que é orquestrado por consultorias especializadas neste tipo de processo. Geralmente é realizado quando uma organização está atualizando seu datacenter e, consequentemente revendo suas políticas de recuperação dos dados ou montagem do datacenter redundante.
O processo de levantamento destes dados se baseia em entrevistas e dados do ambiente de TI e, entre outras coisas, coleta:
Porque o Hyper-V Replica é uma ótima opção
O processo de backup é uma das formas que o RPO e RTO podem ser cumpridos, porem as práticas normais de restore muitas vezes são impeditivas levando em conta o tempo que é perdido entre o ultimo backup e a falha (RPO) e o tempo necessário para se restaurar um servidor a partir de backups (RTO).
Com o Hyper-V Replica o tempo de RTO é minimo, uma vez que as réplicas mantem a maquina virtual (VM) no ambiente de redundância integra.
E o RPO?
Em um ambiente de backup o RPO é facilmente calculado e mantido. Por exemplo, se o RPO da aplicação CRM tem perda máxima calculada em 30 minutos, podemos fazer o backup incremental a cada 15 ou 30 minutos.
No caso do Hyper-V Replica este tempo não é determinado de forma simples, uma vez que o tempo de replicação (Replication Frequency) de cada VM indica o intervalo e não o periodo desejado de proteção. Seria muito bom ter uma opção onde pudesse ser indicado qual o tempo máximo em que uma réplica pode estar desatualizada…
Um segundo item importante é levar em conta o grupo de uma aplicação, por exemplo mais de um servidor que forma a mesma aplicação e precisa estar com a réplica sincronizada por igual. Como o Hyper-V Replica não tem o conceito de grupo de serviço, não temos como garantir a integridade do conjunto da aplicação.
Outra dificuldade no Hyper-V Replica é o baixo número de opções de intervalo da réplica (Windows 2012 a cada 5 minutos, Windows 2012 R2 a cada 30 segundos, 5 minutos ou 15 minutos):
Imagine um cluster com 80 VMs, sendo que cada VM tem impacto diferente no negócio ou requisitos técnicos particulares. Destas 80 VMs algumas são servidores web que podem ser replicadas uma vez por dia, outras são servidores de aplicação que só precisam ser replicados quando sofrem algum tipo de atualização e, por fim temos os servidores que precisam ser replicados continuamente.
Como configurar diferentes RPO?
Uma prática que pode ser adotada de forma simples, é colocar as máquinas em grupos de criticidade e configurar utilizando as 3 janelas de réplica do Windows 2012 R2 (30 segundos, 5 minutos e 15 minutos).
O problema é que se a VM que será replicada a cada 30 segundos for, por exemplo um banco de dados e o ambiente de redundância for por WAN, o consumo do link será muito alto e as outras VMs entrarão em intervalo de réplica e com isso todas as réplicas ocorrerão simultaneamente. Com isso, o RPO ficará prejudicado para todas as VMs críticas e muito baixo para as maquinas não criticas.
Uma boa prática neste caso é configurar as VMs com RPO maior que 2 horas para serem replicadas manualmente por meio de PowerShell abaixo:
Resume-VMReplication MaquinaVirtual –Resynchronize –ResynchronizeStartTime “8/1/2012 05:00 AM”
Este comando pode ser executado pelo Task Scheduler ou utilizando o Orchestrator com schedule embutindo o comando.
No exemplo citado anteriormente, as VMs de banco de dados ou informações como File Server ficariam com a configuração do próprio Hyper-V a cada 5 ou 15 minutos. As VMs estáticas poderiam ser configuradas com replicação manual, e com tarefas ou runbook agendados e recorrentes replicar pontualmente conforme o grupo de criticidade.
Conclusão
Este segundo post abordamos como alcançar o RTO e RPO.
O próximo post irei abordar os comandos e a sequencia de comandos PowerShell que podem ser executados como script ou com Runbook no Orchestrator.