Redes no failover cluster
O primeiro passo na instalação do failover cluster é a criação de um domínio visto que todos os nós que integram o cluster têm que pertencer ao mesmo domínio. E antes de fazer isto, voltei a alterar a configuração de rede de todas as MV de modo a adaptá-las a um melhor funcionamento neste novo ambiente.LAB-DC:IP: 192.168.1.10
Gateway: 192.168.1.1 (Router Físico)
DNS: 127.0.0.1
DNS Alternativo: 192.168.1.1
LAB-NODE1:
IP: 192.168.1.11
Gateway: 192.168.1.1
DNS: 192.168.1.10 (DC)
DNS Alternativo: 192.168.1.1 (Router Físico)
LAB-NODE2:IP: 192.168.1.12
Gateway: 192.168.1.1
DNS: 192.168.1.10
DNS Alternativo: 192.168.1.1
LAB-NODE3:
IP: 192.168.1.13
Gateway: 192.168.1.1
DNS: 192.168.1.10
DNS Alternativo: 192.168.1.1
LAB-STORAGE:IP: 192.168.1.14
Gateway: 192.168.1.1
DNS: 192.168.1.10
DNS Alternativo: 192.168.1.1
Assim, fiquei com um domínio com 5 máquinas; um controlador e dois servidores como MVs do Hyper-V, um servidor como MV do VMware e outro servidor como MV do VirtualBox.
Até aqui já demonstrei que é possível integrar na mesma infra-estrutura servidores virtualizados sobre diferentes plataformas e técnicas de virtualização porque neste caso temos MVs em hipervisores de Tipo 1 (Hyper-V) e de Tipo 2 (VMware Workstation e VirtualBox).
A opção pela criação de uma rede com IP estático é tão válida quanto a da utilização do DHCP. Mais à frente irei explorar as potencialidades de rede dos clusters em Windows 2008 mas por agora mantive a rede assim e continuei a instalação do laboratório.
Características de rede dos failover clusters em Windows Server 2008
O clustering no Windows Server 2008 introduziu algumas novas possibilidades que são um grande progresso relativamente aquilo que existia anteriormente. Essas novas possibilidades incluem:
Nova arquitectura de drivers de rede
O antigo driver de rede (clusnet.sys) foi subtituido por um novo driver NDIS chamado Microsoft Failover Cluster Virtual Adapter (netft.sys). Enquanto o antigo driver aparecia na lista como Non-Plug and Play Driver, este novo driver tolerante a falhas aparece como um adaptador de rede quando se revelam os dispositivos escondidos no Device Manager.
Capacidade de localizar nós em redes diferentes para suportar clusters multi site
Com o failover clustering do Windows Server 2008 os nós individuais podem ser localizados em redes separadas, através de encaminhamento.
Suporte para endereços IP atribuidos por DHCP
Com o failover clustering do Windows Server 2008 os recursos do cluster podem obter o seu IP de servidores DHCP. Se pelo menos um nó do cluster tiver uma interface de rede configurada para obter o IP por DHCP, então o procedimento padrão vai ser obter o IP por essa via para todos os outros recursos do cluster.
Melhorias no mecanismo de monitorização do cluster (heartbeat) (link)
O mecanismo de monitorização do cluster mudou no Windows Server 2008. Embora ainda utilize a porta 3343, já não funciona por difusão (broadcast). Agora funciona em modo unicast e utiliza um processo do tipo pedido-resposta o que permite uma maior segurança.
Suporte para IPv6
Como o Windows Server 2008 suporta o IPv6, também o serviço de cluster tem que suportar esta funcionalidade. Isto inclui a capacidade de suportar em simultâneo endereços IPv4 e IPv6. Além disso, a comunicação entre nós utiliza por padrão o IPv6.
Concepção de redes num failover cluster
A estabilidade de um failover cluster depende em grande medida da concepção de rede onde ele assenta. Em Windows 2008 já não existe a necessidade, como nos clusters em Windows 2003, de uma rede dedicada para a monitorização (heartbeat) mas existem outros requisitos a ter em conta.
A comunicação interna no cluster agora vai passar por todas as redes a não ser que isso seja impedido, como no caso do iSCSI. É uma regra bem conhecida que a rede iSCSI deve servir apenas para este tipo de tráfego e nenhum outro.
A regra de ouro num failover cluster é ter no mínimo dois caminhos de rede redundantes entre os nós do cluster. Mas muitas vezes é aconselhável ter mais que o mínimo para garantir redundância ou desempenho adicional ou para suportar a utilização de outras funcionalidades do Hyper-V como o Live Migration (LM) ou o Cluster Shares Volumes (CSV).
Dependendo das cargas colocadas no failover cluster, o número de interfaces de rede necessárias pode subir rapidamente. Num failover cluster em Hyper-V utilizando LM e iSCSI, o mínimo já serão 4 placas de rede físicas independentes. Geralmente o serviço de cluster (NEFT-Network Fault Tolerant) vai descobrir automaticamente cada rede baseado nas subnets e adicioná-las ao cluster como redes do cluster.
Naturalmente que, mesmo num ambiente de laboratório, podemos simular a existência de múltiplas redes através da criação de várias VLANs dedicadas aos diferentes tipos de tráfego. Até aqui a minha opção foi a de simplificar ao máximo tentando para já apenas interligar MVs em plataformas diferentes. Uma vez conseguido isto, irei adicionar alguma complexidade adicional.
Armazenamento no Failover cluster
O próximo passo para a criação de um failover cluster é a instalação do armazenamento que vai ser partilhado pelo cluster e servir como testemunha no mecanismo de quórum. Para isso vou servir-me do Storage Server para criar o armazenamento iSCSI necessário ao funcionamento do cluster.
Criação de iSCSI targets com o Starwind
Optei por instalar o Starwind na MV Windows Storage Server seguindo os passos que descrevo em seguida.
Depois da instalação, adicionei como host a máquina local, ou seja, o LAB-STORAGE:
Depois liguei o Starwind ao host recém criado:
E comecei a criação do primeiro iSCSI Target:
Dei-lhe um nome e escolhi as seguintes opções:
Em seguida escolhi criar um ficheiro de imagem no disco para exportar como iSCSI Target:
Depois escolhi onde criar o meu disco virtual e a sua dimensão. Previamente tinha adicionado um ficheiro .vhd de 20 Gb como disco E: à MV LAB-STORAGE e foi nesse disco secundário que decidi colocar os meus iSCSI targets. O disco testemunha não necessita ser muito grande e, por isso mesmo, limitei-o a 1 Gb. No entanto é de crucial importância escolher as opções correctas na janela seguinte de modo a possibilitar que estes discos virtuais possam ser utilizados num cluster.
Por último, as definições do caching:
E, depois de repetir os mesmos procedimentos básicos mais duas vezes, fiquei com três discos virtuais que usei como iSCSI targets no meu cluster. Os outros dois discos foram criados com a finalidade de serem armazenamento partilhado do cluster e assim dimensionei-os com 5 Gb cada um.
Instalação do armazenamento partilhado nos nós do cluster
Antes de instalar o armazenamento nos nós do cluster é necessário garantir que o tráfego iSCSI passa em todas as firewalls. Além disso, neste exemplo tive também que garantir que o Starwind fazia parte da lista das excepções aos filtros da firewall.
Agora configurei o iSCSI Initiator em cada nó; Seleccionei iSCSI initiator a partir das Administrative Tools. Como foi a primeira vez que utilizei o iSCSI Initiator, o Windows tem que arrancar com o serviço:
Agora, em cada um dos nós, liguei o Initiator ao Storage Server:
A escolha da opção para adicionar o target à lista de favoritos fará com o nó se ligue automaticamente a esse target de cada vez que inicia:
Depois de tudo isto, os discos iSCSI surgiram na consola Disk Management de cada um dos nós:
Foi necessário colocá-los online, inicializá-los, formatá-los e dar-lhes um nome. Isto teve que ser feito nos dois nós embora a formatação apenas tenha que ser efectuada uma única vez:
Agora o Starwind tem duas sessões ligadas a cada um dos discos, uma para cada um dos nós. Não adicionei o terceiro nó instalado no VMware porque, embora este consiga comunicar com as MVs no Hyper-V não consegue comunicar com a MV do Virtual Box. A razão tem a ver com o facto de estar a usar simultaneamente duas ligações bridged sobre a mesma ligação física e os drivers não conseguirem comunicar um com o outro. Talvez mais à frente instale uma segunda placa de rede no Desktop e demonstre que isto também é possível mas por enquanto limitei-me a criar um cluster apenas com os dois nós do Hyper-V.
Criação do cluster
Agora que todos os nós pertenciam ao domínio e tinham armazenamento iSCSI partilhado, instalei a Failover Clustering Feature (a partir da Server Manager Console) em cada nó:
Depois de instalada (não foi necessário reiniciar as máquinas) utilizei uma ferramenta fabulosa que é a Cluster Validation Wizard.
Seleccionei os nós a incluir:
E executei todos os testes:
Os avisos nos testes de rede alertam para a existência de apenas uma rede que não garante a redundância aconselhável:
Dei um nome ao cluster e um endereço IP:
E o cluster foi criado no modo Maioria de Nó e Disco, o mais adequado para um cluster com um número par de nós:
O disco testemunha é o mais pequeno:
E depois tratei de instalar sobre o cluster dois serviços; MS Distributed Transaction Coordinator e o SQL Server 2008 R2:
Agora já tinha as condições suficientes para testar as potencialidades de um cluster, ensaiar o processo de failover, configurar as opções de failback, mudar a configuração do quórum, etc.
Nos próximos artigos irei mostrar algumas variações possíveis a partir desta configuração base.