Utilizando o Hyper-V Replica Parte II - Boas Práticas para RTO e RPO
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.
Utilizando o Hyper-V Replica Parte I–Vantagens e Primeira Réplica
O segundo artigo sobre Hyper-V Replica abordando RPO e RTO esta disponivel em http://www.marcelosincic.com.br/blog/post/Utilizando-o-Hyper-V-Replica-Boas-Praticas-para-RTO-e-RPO.aspx
Apesar de muito noticiado como novidade no Windows Server 2012, o Hyper-V Replica não está sendo tão utilizado pelos profissionais de TI como esperado. Muito provavelmente temos o desconhecimento e a restrição a ser uma nova tecnologia, o que é natural.
Porem, uma das formas hoje usadas para réplica de VMs e que no Hyper-V criam diversos problemas é a réplica de storage, ou seja, a replicação que ocorre entre os storages em casos de datacenter de redundância (DR).
A tabela abaixo mostra alguns motivos pelo qual Hyper-V Replica é melhor opção a réplica de storage:
|
Storage
|
Hyper-V Replica
|
| Performance da Réplica |
Performance da cópia usa algoritmos dedicados de compressão
|
Boa performance, só replica alterações no VHDX, Windows 2012 R2 oferece compressão |
| Consistência |
Assegura consistência na réplica |
Replica baseada em NTFS, permitindo ativo/passivo e Live Migration
|
|
RPO
|
Permite a réplica em agendamentos regulares ou contínuos |
Permite agendar a primeira réplica, as atualizações são a cada 5 minutos no Windows 2012 RTM e 30 segundos, 5 minutos ou 15 minutos no Windows 2012 R2 |
|
RTO
|
Necessita que os discos sejam ativados e os hosts Hyper-V inicializados |
Imediatamente os hosts ativam as VMs no DR |
| Replica de Novas VMs |
É necessário criar manualmente no site DR |
Replica qualquer alteração no XML da VM |
|
Admin Tools
|
Storage console
|
Console do Cluster/Hyper-V
|
| Nivel de Especialização |
Conceitos de Storage geral e do fabricante |
Hyper-V e Microsoft Cluster
|
| Cancelamento da Réplica |
Permite cancelar réplica de uma LUN |
Permite cancelar a réplica apenas de uma VM ou até mesmo um VHDX |
| Inversão |
Necessário reconfigurar a réplica |
Permite a inversão em modo gráfico |
|
Cluster Mode
|
Ativo/Passivo |
Ativo/Ativo |
| Ação de Recover |
Recriar/Reiniciar os algoritmos de réplica |
Menu de contexto para reiniciar ou inverter |
O maior problema da réplica de storage para Hyper-V é que a LUN replicada no site DR está offline. Sendo assim, não dá para alterar ou mesmo ver no Hyper-V as VMs no site DR, uma vez que a LUN não está acessivel e só pode ficar no momento de uma virada de operação.
Já o Hyper-V Replica permite inverter as VMs sem qualquer passo adicional, incluindo a reversão (inverter primário com secundário). Porem, iremos falar disso em outro post. Vamos focar no momento da primeira réplica.
Existem duas formas de a primeira réplica ser realizada sem utilizar o link entre os sites do exemplo abaixo:
A primeira forma é fazer local a configuração do Hyper-V Replica e esperar o secundário ter todas as VMs prontas.
Este método tem a desvantagem da montagem do storage e servidores em dois momentos, o que pode encarecer o serviço e em muitos casos não haver espaço ou recursos de energia elétrica suficientes.
A outra forma é fazer isso por usar o próprio wizard do Hyper-V Replica escolhendo exportar a VM.
Para isso, ao configurar a réplica de uma VM escolha a opção "Send initial copy using external media” e defina um local para exportar os arquivos como abaixo:
O passo seguinte é importar a VM no host onde ela foi criada. Note que a VM é criada no final do wizard acima no host destino, mas sem os arquivos e sem ativar a réplica:
Escolha a localização criada pelo wizard e aguarde a importação:
Completado este item no servidor destino o status estará Warning e no servidor de origem Normal indicando que está ok.
O próximo passo é clicar no servidor de origem na VM e usar a opção Resume Replica para que ele inicie a cópia de sincronização.
Uma dica importante é que o Hyper-V Replica funciona criando um snapshot e enviando o arquivo de snapshot da origem para o destino, portanto não demore muito tempo para fazer a sincronização inicial pois poderá ter problemas de espaço e performance por conta do uso de um disco diferencial do snapshot.
Nos próximos posts iremos abordar melhores configurações e como montar um ambiente de Hyper-V Replica.
Novo Microsoft MVA: Novidades do Windows Server 2012 R2
Este final de semana foi liberado mais um Microsoft Virtual Academy (MVA) sobre Windows Server 2012.
Abordamos as novidades do sistema operacional na versão R2, na infraestrutura de rede (NVGRE, OMI, etc) e Hyper-V (Shared VHDX, ativação automática, etc).
Acesse em http://www.microsoftvirtualacademy.com/training-courses/novidades-do-windows-server-2012-r2
Conceitos de Storage para IT Pro 3 – Virtualização e Tierização
No primeiro artigo desta série Conceitos de Storage para IT Pros–Tipos de RAID e IOPS abordamos alguns conceitos importantes e básicos para profissionais de TI sobre os tipos de RAID disponiveis e utilizados hoje em storages e também como calcular IOPS (operaçoes de leitura e escrita) para cada tipo de disco e aplicações.
No segundo artigo http://www.marcelosincic.com.br/blog/post/Conceitos-de-Storage-para-IT-Pro-2-e28093-Controladoras-e-Modelos.aspx abordamos os tipos de controladoras e tecnologias de storage mais comuns hoje existentes no mercado.
Neste terceiro artigo veremos o que são conceitos de tierização e virtualização de storages.
Virtualização
A virtualização de storage conceitualmente é diferente da virtualização de computadores.
Na virtualização de storages o conceito é utilizarmos um produto que faça a conexão com vários tipos e modelos de storage. Por exemplo, o System Center Virtual Machine Manager 2012 é capaz de ser a interface entre os diferentes storages e as máquinas virtuais. Mais detalhes sobre isso podem ser vistos no post http://www.marcelosincic.com.br/blog/post/Gerenciamento-de-Storage-com-o-System-Center-Virtual-Machine-2012.aspx
O mesmo recurso pode ser alcançado com o SMB 3.0 do Windows Server 2012, onde podemos apontar todas as LUNs disponíveis em um File Server e por meio do SMB 3.0 mapear as VMs entre os diferentes storages.
Tierização
Este recurso está presente em alguns storages de mercado e pode ser simulado pelo VMM. Significa ter a possibilidade de termos diversos storages com performances diferentes e ter a capacidade de mover uma VM de um storage mais lento para outro mais rápido de forma transparente a operação.
Isso pode ser simulado pelo VMM e pelo Hyper-V 3.0 com o recurso Storage Migration, onde podemos mover as VMs com Live Storage Migration permitindo que a operação não seja interrompida quando movemos entre os diferentes modelos de storage disponíveis.
Porem, alguns modelos storage como, por exemplo Compellent e Equallogic, podem conter “gavetas” de discos de diferentes tipos e mover os dados entre as gavetas conforme a performance necessária da aplicação ou maquina virtual. Neste caso o software do storage faz isso automaticamente conforme a carga que cada VM ou aplicação impõe ao storage.
Fonte: http://www.dellstorage.com/storage-tiering-archiving/storage-tiering.aspx
Para mais informações sobre o Windows Server 2012, acesse: http://clk.atdmt.com/MBL/go/425205719/direct/01/
Conceitos de Storage para IT Pro 2 – Controladoras e Modelos
No primeiro artigo desta série Conceitos de Storage para IT Pros–Tipos de RAID e IOPS abordamos alguns conceitos importantes e básicos para profissionais de TI sobre os tipos de RAID disponiveis e utilizados hoje em storages e também como calcular IOPS (operaçoes de leitura e escrita) para cada tipo de disco e aplicações.
Neste artigo iremos abordar os tipos mais comuns de controladoras e modelos de storages.
A tabela a seguir retirada do documento da Microsoft “Analyzing Characterizing and IO Size Considerations” disponivel em http://bit.ly/18nlbTg mostra como o tipo de barramento da controladora fisica utilizada para o seu storage influencia diretamente na performance:
HBA – Host Bus Adapter
Este é um tipo de barramento muito utilizado antes do iSCSI e muito eficiente, interligando o storage diretamente com o servidor por uma placa dedicada, sendo utilizado pelo Fibre Channel (exemplo Compellent) ou modelo de conexão direta (exemplo MD3000).
Como pode ser visto na tabela acima, por ser um barramento dedicado temos toda a performance sem concorrencia, diferente do iSCSI, pois no HBA cada servidor se conecta a uma saida do storage ou a um switch dedicado e no iSCSI usamos duas saidas de rede para todos os servidores.
Alem disso, em um storage dedicado são pelo menos duas controladoras, sendo elas redundantes e simultaneas para acesso, garantindo segurança e alta performance.
A desvantagem dos modelos HBA se dá por conta da limitação de conexões possiveis, uma vez que em alguns modelos (exemplo MD3000) são 4 portas, limitando a 4 servidores. Para este modelo utilizar HBA e montar um cluster de 4 nós é uma boa alternativa.
Fibre Channel
O FC é um dos modelos de HBA muito utilizado por conta da alta performance e numero ilimitado de hosts que podem ser conectados pelo switch Fibre Channel.
Alem disso, o FC permite boot de servidores sem disco local, o que garante a substituição de um host apenas colocando outro hardware identico e alterando o WWN no storage.
Nos storages FCs utilizamos o WWN (World Wide Name) para indicar qual LUNs será utilizado por cada servidor, sendo muito simples de ser realizado e configurado. Com o Windows 2012 podemos entregar storages diretamente as VMs por criar um WWN virtual no Hyper-V:
A desvantagem do FC se dá pelo custo mais alto que as outras soluções envolvendo HBA e, principalmente, iSCSI. Porem, as vantagens técnicas, administrativas e performance fazem do FC o melhor tipo de conexão a storage.
iSCSI
O iSCSI (Internet SCSI) é o modelo mais utilizado hoje por conta do custo acessivel, diversas opções de fabricantes, modelos e tamanhos. Basicamente o iSCSI utiliza comunicação pela rede ethernet comum, porem com algumas vantagens que melhoram a performance se seguidos:
- Utilizar switches de rede separados apenas para a rede de storage
- Trabalhar com 2 placas de rede em cada servidor para configurar o recurso de MPIO (Multipath I/O) que permite utilizar as duas placas simultanêas no acesso aos dados, duplicando a velocidade de acesso
- Configurar o Jumbo Frame para trabalhar com pacotes de dados de 9K ao invés de 1.5K, uma vez que storage sempre trafega dados em pacotes maiores diferentemente da comunicação comum em rede
A desvantagem do iSCSI se dá exatamente pelos pontos acima, já que a estrutura de rede precisa ser dedicada para ter melhor performance e redundância.
O suporte ao iSCSI pode ser pelo storage ou até por softwares que habilitam um servidor comum a se tornar um storage iSCSI, o que é chamado de iSCSI Initiator Server e o cliente de iSCSI Initiator. A Microsoft tem este software disponivel, mas é muito conhecido no mercado o StarWind iSCSI Initiator Server.
NAS com SMB 3.0
A tecnologia de NAS (Network Attached Server) é baseada no Windows Server 2012 que com o SMB 3.0 torna ele compativel com virtualização, permitindo que o Hyper-V utilize um File Server para armazenar as maquinas virtuais, possibilitando que seja montado um Cluster baseado apenas em File Server.
As vantagens deste modelo são o baixo custo, facilidade na administração e entrega para novos servidores.
As desvantagens se dão por conta da rede que tem os mesmos requisitos listados do iSCSI, tendo algumas considerações adicionais:
- O MPIO precisa ter placas de rede redundantes no servidor baseadas em SMB Direct e RDMA que não são modelos triviais em servidores atualmente
- O Jumbo Frame impossibilita que maquinas de usuários (clientes) utilizem o servidor para guarda de arquivos, a menos que se habilite neles o modo Jumbo Frame com implicações em todos os switches da rede Core
- Storages possuem recursos de multicontroladoras e fontes, o que nem sempre é presente em File Servers
Conclusão
Utilizando corretamente os tipos de storages disponiveis e pensando em sua necessidade é possivel ter um ambiente confiável e com boa performance e redundância.
Fonte: http://bit.ly/13uRbOs (Windows Server 2012 White Paper Storage)
Para mais informações sobre o Windows Server 2012, acesse: http://clk.atdmt.com/MBL/go/425205719/direct/01/