Antes de seguir para o próximo capítulo na minha série sobre o laboratório de virtualização, acho que esta pode ser uma boa oportunidade para rever algumas das opções de agrupamento (clustering) disponíveis hoje. Vou usar o Windows Clustering Failover Server com Hyper-V, porque no mundo de hoje a tendência é combinar a Virtualização com Alta Disponibilidade (AD).
Há muitas maneiras de implementar estas soluções e os conceitos básicos de design aqui apresentados podem ser adaptados para outras plataformas de virtualização. Alguns deles não garantirão uma solução tolerante a falhas, mas a maioria pode ser usada em situações específicas (mesmo que apenas para fins de demonstração).
Duas máquinas virtuais num servidor físico
Neste cenário, um cluster de AD é construído entre duas (ou mais) máquinas virtuais numa única máquina física. Aqui temos um único servidor físico executando o Hyper-V e duas partições filho em que é executado o Failover Clustering. Esta configuração não protege contra falhas de hardware porque, quando o servidor físico falhar, ambos os nós (virtuais) do cluster falham. Portanto, a máquina física em si é um ponto único de falha (Single Point Of Failure - SPOF).
 |
| (Clique para aumentar) |
Obviamente, esta configuração não é útil para atingir a verdadeira alta disponibilidade mas pode ser interessante para treino, teste ou demonstrações, como uma forma confortável de testar diferentes configurações de cluster AD sem exigir muitos recursos de hardware.
Duas máquinas virtuais em dois servidores físicos
Neste segundo cenário, um cluster de AD é construído entre duas ou mais máquinas virtuais, cada uma delas a ser executando em diferentes máquinas físicas. Nesta configuração, o SPOF de uma única máquina física é eliminado. Mais uma vez, o gestor de cluster (Windows Server Clustering Failover 2008) é executado directamente na máquina virtual, ou seja, é implementado ao nível da partição filho no Hyper-V.
 |
| (Clique para aumentar) |
Uma vez que o cluster está a ser executado numa máquina virtual, pode ser facilmente transferido para outras máquinas físicas simplificando assim os procedimentos de backup e recuperação. Este arranjo é tolerante a falhas e pode sustentar a falha de um dos servidores físicos. Com uma rede e infra-estrutura de armazenamento redundantes (não mostrados na imagem), isto pode ser uma solução verdadeiramente altamente disponível.
Cluster misto máquina física e virtual
Aqui temos dois servidores físicos (habitualmente nós activos) cada deles formando um cluster com um servidor virtual (habitualmente nó passivo). O gestor de cluster é executado, de um lado directamente na máquina física, do outro na máquina virtual. Se o servidor físico falhar, o irmão virtual vai assumir a sua carga de trabalho.
 |
| (Clique para aumentar) |
A vantagem desta configuração é a possibilidade de combinar múltiplos nós de reserva numa única máquina física (N para 1), enquanto normalmente seria necessária uma segunda máquina física para cada nó de reserva (Activo/Passivo). Isto oferece um grande potencial para redução de custos. No entanto, requer um planeamento cuidadoso, não só para o dimensionamento dos nós de reserva, mas também para lidar com o uso de hardware diferente no cluster. O Failover Clustering Validation Wizard pode confirmar a viabilidade de cada configuração específica.
Esta configuração também pode sobreviver à falha de ambos os servidores físicos. Se configurarmos a rede e infra-estrutura de armazenamento para ser tolerante a falhas, podemos ter uma outra solução verdadeiramente altamente disponível.
Máquina virtual num cluster com dois servidores físicos
 |
| (Clique para aumentar) |
Em contraste com os cenários discutidos anteriormente, neste o gestor do cluster é executado ao nível da partição pai do Hyper-V. Assim, o cluster de AD é construído entre duas ou mais máquinas físicas como em configurações tradicionais sem virtualização. A diferença é que as aplicações não estão a ser executadas directamente na máquina física, mas em vez disso fazem-no numa ou mais máquinas virtuais. As próprias máquinas virtuais estão configuradas como um recurso do cluster e são geridas pelo gestor de cluster. No caso de uma falha, toda a máquina virtual faz failover para o nó de reserva.
Como se pode ver, esta arquitectura pode sobreviver à falha de um dos servidores físicos. Mais uma vez, com uma rede e infra-estrutura de armazenamento redundantes, podemos ter uma solução verdadeiramente altamente disponível.
Laptop autónomo
O objectivo deste último cenário é ter num único laptop que hospeda uma demonstração completa de Failover Clustering com o Hyper-V. A fim de conseguir isso, necessitamos uma SAN iSCSI virtual, mais duas partições filho a desempenhar o papel de nós do cluster. Isto certamente não é uma verdadeira solução de alta disponibilidade, mas pode ser uma máquina de demonstração interessante, sem dependências da rede externa.
 |
| (Clique para aumentar) |
Estas são apenas algumas das opções básicas e podem ser combinadas para formar muitas, se não mesmo todas, as arquitecturas de cluster discutidas anteriormente.