Cluster Hyper-V, Visão Geral e FAQ

Em uma discussão interna do time, decidimos que estava na hora de falar um pouco sobre clusters rodando em Hyper-V e nada como uma rápida visão geral e uma boa FAQ para ajudar a comunidade certo ?

Visão Geral: Virtualização é uma realidade hoje no mundo todo, os benefícios são fáceis de identificar: Menos espaço necessário no Data Center para rodar as aplicações que temos hoje, menos consumo de energia, menos hardware e mais agilidade no processo de implementar novos serviços. O que precisamos saber do lado de TI é como decidir qual nível de continuidade precisamos, visto que toda essa consolidação aumenta o risco de uma falha em um único servidor impactar vários serviços da empresa. Com isso cresce muito a importância de um planejamento cuidadoso da arquitetura e para começar é muito importante saber quais opções temos:

Hyper-V: Cluster convencional:
Alocação de uma LUN para cada maquina virtual.

FAQ: Posso ter várias máquinas rodando em uma única LUN ?
R: Pode, o problema aqui é que não será possível mover uma máquina virtual individualmente.

Hyper-V R2: Cluster convencional + Cluster CSV:
A novidade no R2 é a utilização do Shared Volumes, que possibilita que todos os nós do cluster consigam ler e gravar na mesma unidade do storage. A vantagem aqui é a facilidade de configurar e manter a máquina já que o namespace é sempre o mesmo, e também existe a diminuição do custo administrativo de manter várias LUNs.

FAQ: Algum cuidado especial para montar o CSV ?
R: A letra da unidade do sistema operacional deve ser a mesma em todos os servidores pertencentes ao cluster. Se for C:\ em um servidor, todos tem que usar C:\. Aqui é bem importante atenção para quem quer montar um ambiente de laboratório em seu computador pessoal e utiliza dual boot, pois a quantidade de devices que o Windows identifica pode alterar a letra da unidade de sistema.

Quick migration x Live Migration:
No Hyper-V convencional a única opção disponível para migrar as máquinas virtuais de um nó para outro é utilizar o quick migration, onde a memória do servidor é salva no HD e após isso a máquina é migrada para o outro nó e iniciada. Com isso há uma perda temporária de funcionalidade.
Já no Hyper-V R2, temos o Live Migration, onde não existe mais indisponibilidade.

O caviar aqui é: Se o SLA da sua empresa não permite indisponibilidade, faça o upgrade da sua infra-estrutura para o R2.
Para fazer essa atualização, siga as recomendações da Microsoft publicadas aqui: https://support.microsoft.com/kb/957256

Clusters de Máquinas Virtuais:
No Hyper-v para o uso de cluster em máquinas virtuais existem diversas opções onde destacam-se: ISCSI, Windows Storage Server e ISCSI Target de terceiros.

Virtualização de DCs e DNS:
O post é sobre cluster, mas virtualizar DCs e DNS merece tanto cuidado que resolvi colocar no meio do post um alerta importante. Com o Live Migration e a possibilidade de utilizar clusters geográficos, não é tão incomum ver clientes com projetos de virtualização de 100% do ambiente e clientes que já tiveram problemas com clusters que após uma parada programada (parada de energia programada - por exemplo) tiveram sérios problemas para fazer o ambiente voltar a funcionar, pois haviam colocado todos os DCs e DNS dentro da farm de cluster que foi desligada.
DCs e DNS disponíveis são pré-requisitos para que o cluster seja iniciado, então é muito importante que ao menos 1 servidor físico seja mantido com esses serviços.

Cluster Geográfico:
É possível manter clusters geográficos de hyper-v mas, é importante lembrar de alguns pontos importantes:
1: Projete bem o modelo e tamanho da farm, pois se a idéia aqui é disaster recovery, sua empresa pode não estar disposta a manter o mesmo número de servidores físicos inativos, então identificar e criar farms separadas que podem ser migradas para o site de disaster recovery vai ser de grande valia no futuro.

2: Combine o seu desenho com o desenho do fabricante de storage, a importância do desenho da infra de storage é muito grande em cenários de clusters geográficos.

3: Atente para o fato de que o site de disaster recovery deve ter acesso a mesma subnet das máquinas virtuais, pois em caso negativo você terá um monte de máquinas inacessíveis do outro lado.

Links de grande valia quando o assunto é cluster em Hyper-V:
Descrição do que a serem considerados quando você implantar o Windows Server 2008 failover nós de cluster em sub-redes diferentes e roteadas

Usando a migração ao vivo com Volumes Compartilhados do Cluster no Windows Server 2008 R2

Abraços,

Robson Silva
https://blogs.technet.com/robsonsilva