Parte 1: planejamento, configuração e validação do cluster

2. Em Datacenter > SDN > VNets, crie hvmgmt, hviscsi e hvclus na zona hvclu, sem sub-redes.

3. Volte em Datacenter > SDN e clique em Apply. Nada entra em vigor antes disso.

Pela linha de comando, o equivalente é:

# Proxmox VE 8.1 ou superior - shell do host como root

pvesh create /cluster/sdn/zones --type simple --zone hvclu

pvesh create /cluster/sdn/vnets --vnet hvmgmt  --zone hvclu

pvesh create /cluster/sdn/vnets --vnet hviscsi --zone hvclu

pvesh create /cluster/sdn/vnets --vnet hvclus  --zone hvclu

pvesh set /cluster/sdn      # o mesmo que o botao Apply

Uma lição do laboratório: no Proxmox, a zona é só um contêiner de redes, não uma fronteira de segurança como uma zona de firewall (no Sophos, por exemplo). O isolamento vem das VNets sem gateway. VNets com VLAN ficam para um próximo laboratório.

O controlador de domínio (DC01)

O laboratório usa um domínio Active Directory já existente: no nosso lab, o DC01 (VM 112), com AD DS e DNS integrado, no domínio jbitcore.lab, com o IP 10.0.10.10 na rede hvmgmt. A criação do domínio não faz parte deste tutorial. Se você ainda não tem um domínio, crie o seu antes de continuar.

Criando as VMs a partir do VHD

O HV01 nasce do VHD de avaliação do Windows Server 2019, importado pela linha de comando, e o HV02 é um clone dele feito antes do primeiro boot. As placas de rede entram só depois do clone.

Antes de tudo, confirme que a virtualização aninhada está ativa no host:

# Proxmox VE - shell do host como root

# Este host é AMD. Em host Intel, troque kvm_amd por kvm_intel

cat /sys/module/kvm_amd/parameters/nested    # 1 ou Y = habilitado

cat /etc/modprobe.d/kvm-amd.conf

# Se retornar 0 ou N:

echo "options kvm-amd nested=1" > /etc/modprobe.d/kvm-amd.conf

# reinicie o host (ou recarregue o modulo com todas as VMs desligadas)

Dica: identificando qual placa é qual

O Windows nomeia as placas como Ethernet, Ethernet 2 e Ethernet 3, e a ordem nem sempre bate com net0, net1 e net2. No laboratório, o jeito mais simples foi desconectar o cabo virtual de uma placa por vez:

1. No Proxmox, em Hardware, selecione uma placa (por exemplo, net1, na hviscsi), clique em Edit e marque Disconnect.

2. No ncpa.cpl, a placa que passar para Network cable unplugged é a dessa rede. Renomeie-a.

3. Desmarque o Disconnect e repita com as outras placas.

Outra opção é comparar os MACs. No ncpa.cpl, abra Status > Details de cada placa e compare o Physical Address com o MAC da aba Hardware. Pelo PowerShell, o comando abaixo lista as placas com o MAC; o Windows mostra o MAC com hífens (BC-24-11-...) e o Proxmox com dois-pontos (BC:24:11:...).

# HV01 / HV02 - PowerShell 5.1, Windows Server 2019, como Administrator local

Get-NetAdapter | Sort-Object Name | Format-Table Name, InterfaceDescription, MacAddress, Status

Para quem gosta de PowerShell, o script a seguir faz toda a configuração desta seção de uma vez. Atenção: o console do Proxmox não cola texto dentro de uma VM Windows, então ele precisa ser digitado. Em outros hipervisores, verifique se o console aceita copiar e colar.

# HV01 / HV02 - PowerShell 5.1, Windows Server 2019, como Administrator local

# Substitua pelos MACs da aba Hardware do Proxmox (com hifens)

$Mgmt  = "BC-24-11-00-00-01"   # net0 - hvmgmt

$iSCSI = "BC-24-11-00-00-02"   # net1 - hviscsi

$Clus  = "BC-24-11-00-00-03"   # net2 - hvclus

$N = 11                        # HV01 = 11, HV02 = 12

# 1. Renomear as placas pelo MAC

Get-NetAdapter | Where-Object MacAddress -eq $Mgmt  | Rename-NetAdapter -NewName "MGMT"

Get-NetAdapter | Where-Object MacAddress -eq $iSCSI | Rename-NetAdapter -NewName "iSCSI"

Get-NetAdapter | Where-Object MacAddress -eq $Clus  | Rename-NetAdapter -NewName "CLUS"

# 2. IPs fixos; gateway só na MGMT (10.0.10.1, reservado para um roteador futuro)

Set-NetIPInterface -InterfaceAlias "MGMT","iSCSI","CLUS" -AddressFamily IPv4 -Dhcp Disabled

New-NetIPAddress -InterfaceAlias "MGMT"  -IPAddress "10.0.10.$N" -PrefixLength 24 -DefaultGateway "10.0.10.1"

New-NetIPAddress -InterfaceAlias "iSCSI" -IPAddress "10.0.20.$N" -PrefixLength 24

New-NetIPAddress -InterfaceAlias "CLUS"  -IPAddress "10.0.30.$N" -PrefixLength 24

# 3. DNS apenas na MGMT; iSCSI e CLUS sem DNS e sem registro

Set-DnsClientServerAddress -InterfaceAlias "MGMT" -ServerAddresses "10.0.10.10"

Set-DnsClientServerAddress -InterfaceAlias "iSCSI","CLUS" -ResetServerAddresses

Set-DnsClient -InterfaceAlias "iSCSI","CLUS" -RegisterThisConnectionsAddress $false

Instalando as funções e testando o Hyper-V aninhado

Com os nós no domínio, instalamos as funções nos dois e, antes de seguir, testamos se o Hyper-V roda aninhado. Esse teste é o ponto de decisão do laboratório: se o hipervisor não subir dentro da VM, o cluster não roda neste host.

1. Instalar as funções

Nos dois nós, um único comando instala o Hyper-V, o Failover Clustering e o Multipath I/O, com as ferramentas de gerenciamento. O nó reinicia duas vezes até concluir.

# HV01 e HV02 - PowerShell 5.1, Windows Server 2019, como administrador do domínio

Install-WindowsFeature Hyper-V, Failover-Clustering, Multipath-IO -IncludeManagementTools -Restart

O Multipath I/O fica instalado, mas não é configurado neste laboratório, porque o storage tem um único caminho. Ele já fica pronto para um segundo caminho iSCSI no futuro.

2. Testar o Hyper-V aninhado com uma VM temporária

Esta VM não tem relação com o cluster: é um teste rápido no HV01, feito antes de existir storage compartilhado ou cluster, e apagada logo em seguida. No HV01, criamos uma VM de teste sem disco, só para ver o hipervisor iniciar. Se o Get-VM mostrar o estado Running, o Hyper-V funciona aninhado. Depois, a VM é removida.

# HV01 - PowerShell 5.1, Windows Server 2019, como administrador do domínio

New-VM -Name NestTest -MemoryStartupBytes 512MB -Generation 1 -NoVHD

Start-VM NestTest

Get-VM NestTest

Stop-VM NestTest

Remove-VM NestTest -Force

No laboratório, o teste passou: a VM chegou ao estado Running. Vale saber o que esse teste prova e o que não prova. Ele confirma que o hipervisor sobe dentro da VM, mas não testa um sistema operacional convidado de verdade. Isso só aparece mais tarde, quando a VM de teste precisa dar boot, e é aí que entra o --machine q35 explicado na criação das VMs.

Storage compartilhado: a SAN01 com TrueNAS

O cluster precisa de discos que os dois nós enxerguem ao mesmo tempo. No laboratório, esse papel fica com a SAN01, uma VM com TrueNAS SCALE que entrega dois discos por iSCSI: um pequeno para o witness e um maior para o CSV, onde as VMs do cluster vão ficar na Parte 2.

A SAN01 vem depois dos nós por um motivo prático: o assistente de iSCSI do TrueNAS pede os IQNs dos initiators, ou seja, os nomes iSCSI do HV01 e do HV02, que só existem depois que os nós estão prontos.

1. Criar a VM SAN01

A VM foi criada pelo assistente do Proxmox e ajustada em seguida. A configuração final:

• VM: 115, nome SAN01

• CPU: 2 núcleos, tipo host

• Memória: 8 GB, com ballooning desligado

• BIOS e chipset: SeaBIOS e i440fx (o padrão do Proxmox)

• Controladora: VirtIO SCSI single

• Disco de boot: 32 GB (scsi0)

• Disco de dados: 150 GB (scsi1), com número de série SAN01DATA01

• Placas: uma na hvmgmt, uma na hviscsi e uma temporária na vmbr0

• QEMU Guest Agent: habilitado

O disco de dados e as duas placas extras foram adicionados depois do assistente, pelo shell do host:

# Proxmox VE - shell do host como root

qm set 115 --scsi1 nvme-storage:150,cache=unsafe,discard=on,serial=SAN01DATA01

qm set 115 --net1 virtio,bridge=hviscsi,firewall=0

qm set 115 --net2 virtio,bridge=vmbr0,firewall=0

Por que cada escolha:

• serial=SAN01DATA01: o TrueNAS identifica os discos pelo número de série, e um disco virtual do Proxmox não tem um por padrão.

• cache=unsafe e discard=on: o SSD NVMe de consumo do host fica lento com gravações que pedem flush. O cache unsafe ignora esses flushes e acelera bastante, mas pode perder dados se o host cair, então só serve para laboratório. O discard devolve ao host o espaço que o TrueNAS libera.

• Placa temporária na vmbr0: o laboratório não tem saída para a internet, e o Internet Explorer 11 dos servidores não abre a interface web do TrueNAS. Com essa placa na rede de casa, o TrueNAS é administrado pelo navegador do seu PC.

2. Instalar o TrueNAS

O instalador usado foi o TrueNAS SCALE 22.12.2, com a ISO guardada no storage Disk500. Instale no disco de 32 GB e deixe o de 150 GB livre, porque ele vai virar o pool de dados. Depois da instalação, remova o CD e deixe o scsi0 em primeiro na ordem de boot.

3. Configurar a rede do TrueNAS

Em Network > Interfaces, desligue o DHCP de cada placa e defina um endereço estático (alias). O TrueNAS aplica a mudança em modo de teste: clique em Test Changes e depois em Save Changes dentro de 60 segundos, senão ele volta à configuração anterior.

• ens18 (hvmgmt): 10.0.10.15/24

• ens19 (hviscsi): 10.0.20.10/24

• ens20 (vmbr0): DHCP da rede de casa, só para administração

Para saber qual interface é qual, olhe o endereço IPv6 link-local: ele contém o MAC da placa. Por exemplo, fe80::be24:11ff:fe56:95d2 corresponde ao MAC BC:24:11:56:95:D2, que aparece na aba Hardware da VM no Proxmox.

Em Network > Global Configuration, defina o hostname SAN01 e o domínio jbitcore.lab.

4. Criar o pool e os zvols

Em Storage, crie o pool tank com o disco de 150 GB (SAN01DATA01) em stripe. Um stripe de um disco não tem redundância: se o disco falhar, o pool se perde. Em laboratório é aceitável; em produção, não.

Ligue o Auto TRIM no card ZFS Health > Edit Auto TRIM. A opção é do pool, não do dataset, por isso não aparece nas propriedades do dataset.

Depois, crie dois zvols no pool tank, com Add Zvol e os valores padrão:

• witness: 1 GiB

• csv01: 100 GiB

Não se assuste com o pool mostrando 73% usado antes de gravar qualquer dado: os zvols reservam o tamanho total na criação.

5. Publicar os zvols por iSCSI

Antes do assistente, anote o IQN dos dois nós. No HV01 e no HV02, abra o iSCSI Initiator (na primeira vez, aceite iniciar o serviço e deixá-lo automático) e copie o nome em Configuration > Initiator Name.

No TrueNAS, em Shares > Block (iSCSI) Shares Targets, rode o Wizard duas vezes, uma para cada zvol:

• 1ª execução: nome witness, dispositivo tank/witness, Use For Modern OS, portal novo sem autenticação escutando só em 10.0.20.10, e initiators com os IQNs do HV01 e do HV02

• 2ª execução: nome csv01, dispositivo tank/csv01, Use For Modern OS, usando o portal e o grupo de initiators já criados

O resultado são dois targets, witness e csv01, que compartilham um portal e um grupo de initiators. Confira a tela de confirmação antes de salvar. No laboratório, três padrões do assistente precisaram de correção:

• Use For vinha como VMware; para o Windows, o certo é Modern OS.

• O portal escutava em 0.0.0.0, o que incluiria a placa da rede de casa; o certo é só 10.0.20.10.

• Um IQN estava digitado errado; confira caractere por caractere.

Por fim, em System Settings > Services, deixe o iSCSI em Running e marque Start Automatically.

Conectando os nós ao storage iSCSI

Nos dois nós, conecte os dois targets pela placa iSCSI, no iSCSI Initiator:

1. Em Discovery > Discover Portal, informe 10.0.20.10, porta 3260. Em Advanced, escolha Local adapter Microsoft iSCSI Initiator e Initiator IP 10.0.20.11 (no HV02, 10.0.20.12).

2. Em Targets, clique em Refresh: os dois targets (witness e csv01) aparecem como Inactive.

3. Em cada um, clique em Connect, marque Add this connection to the list of Favorite Targets, deixe Enable multi-path desmarcado e, em Advanced, repita o adaptador, o Initiator IP e o portal 10.0.20.10 / 3260.

Prender a conexão ao IP iSCSI garante que o tráfego de storage passe só pela hviscsi. Os Favorite Targets reconectam os discos a cada boot.

Preparar os discos só no HV01

No Disk Management do HV01, coloque os dois discos Online, inicialize em GPT e crie um volume NTFS em cada um, sem letra de unidade, com os rótulos Witness (1 GB) e CSV01 (100 GB). No HV02, não toque nos discos: eles ficam Offline, que é o correto antes do cluster. Dois nós montando o mesmo NTFS ao mesmo tempo corromperiam o volume; quem vai coordenar esse acesso é o cluster.

Para conferir, nos dois nós:

# HV01 e HV02 - PowerShell 5.1, Windows Server 2019

Get-IscsiConnection | Format-Table InitiatorAddress, TargetAddress

Get-Disk | Where-Object BusType -eq iSCSI |  Format-Table Number, FriendlyName, Size, OperationalStatus

O esperado: no HV01, InitiatorAddress 10.0.20.11 e, no HV02, 10.0.20.12, os dois apontando para 10.0.20.10. Os discos TrueNAS iSCSI Disk aparecem Online no HV01 e Offline no HV02.

A rede das VMs: o vSwitch-VM

As VMs do cluster precisam de um vSwitch externo com o mesmo nome nos dois nós; sem isso, uma VM não migra de um nó para o outro. Para isso, cada nó ganha uma quarta placa, na hvmgmt, dedicada ao vSwitch.

# Proxmox VE - shell do host como root

qm set 113 --net3 virtio,bridge=hvmgmt,firewall=0

qm set 114 --net3 virtio,bridge=hvmgmt,firewall=0

No Windows, identifique a placa nova, renomeie para VM e não configure IP nela. Depois, nos dois nós:

# HV01 e HV02 - PowerShell 5.1, Windows Server 2019, como administrador do domínio

New-VMSwitch -Name vSwitch-VM -NetAdapterName VM -AllowManagementOS $false

Get-VMSwitch | Format-Table Name, SwitchType, NetAdapterInterfaceDescription, AllowManagementOS

Com -AllowManagementOS $false, o Windows do nó não usa essa placa: ela fica só para as VMs. O esperado é vSwitch-VM, External, AllowManagementOS False, nos dois nós.

Confira mesmo nos dois. No laboratório, um dos nós ficou com AllowManagementOS True: o Windows criou uma placa vEthernet (vSwitch-VM) só com IPv6 link-local, e o cluster a tratou como uma quarta rede. Se acontecer, corrija no nó afetado: 

# Nó afetado - PowerShell 5.1, Windows Server 2019

Set-VMSwitch -Name vSwitch-VM -AllowManagementOS $false

Dica: reinicie os dois nós depois de criar o vSwitch. No laboratório, a validação feita logo em seguida falhou em todas as redes, porque a pilha de rede ainda não tinha estabilizado. Depois do reboot, passou.

Ponto de restauração: snapshots antes do cluster

Antes de validar e criar o cluster, tire um snapshot das quatro VMs. Se algo der errado, voltar leva poucos minutos.

A ordem importa. Desligue os nós primeiro, depois a SAN01 e, por último, o DC01: os nós dependem da SAN, e tudo depende do DC. Com tudo desligado, tire o snapshot pre-cluster de cada VM em Snapshots > Take Snapshot. Pela linha de comando, o equivalente é:

# Proxmox VE - shell do host como root, com as quatro VMs desligadas

for id in 112 113 114 115; do

  qm snapshot $id pre-cluster --description "Before Test-Cluster / New-Cluster"

done

Para ligar, use a ordem inversa: DC01, SAN01 (espere o menu do console do TrueNAS) e só então os nós. Um nó ligado antes da SAN falha o logon iSCSI no boot. Depois, confira nos dois nós se as sessões iSCSI voltaram:

# HV01 e HV02 - PowerShell 5.1, Windows Server 2019

Get-IscsiSession | Format-Table TargetNodeAddress, IsConnected

Pegadinha: se o snapshot falhar com VM snapshot already started, é porque uma segunda solicitação chegou enquanto a primeira ainda gravava a memória. O Proxmox limpa sozinho; confira com qm config <id> | grep -i lock e tire o snapshot de novo com a VM desligada.

Validando a configuração

Com tudo pronto, rode a validação no HV01. O Test-Cluster testa inventário, rede, storage e configuração do sistema nos dois nós e gera um relatório HTML em C:\Windows\Cluster\Reports\.

# HV01 - PowerShell 5.1, Windows Server 2019, como administrador do domínio

Test-Cluster -Node HV01, HV02

Antes de cada rodada, confira no host em qual bridge cada placa está. Desconectar o cabo virtual confirma o nome da placa no Windows, mas não a bridge no Proxmox:

# Proxmox VE - shell do host como root

for id in 113 114; do echo "VM $id:"; qm config $id | grep ^net | sed 's/=[^,]*,/ /'; done

O esperado, igual nos dois nós: net0 na hvmgmt, net1 na hviscsi, net2 na hvclus e net3 na hvmgmt.

O storage passou desde a primeira rodada, inclusive o teste de reserva persistente SCSI-3 (Validate SCSI-3 Persistent Reservation), que é o que permite ao cluster usar o disco witness.

Criando o cluster

Com a validação limpa, crie o cluster no HV01. O -NoStorage cria o cluster sem discos, para que eles sejam adicionados de forma deliberada logo depois.

# HV01 - PowerShell 5.1, Windows Server 2019, como administrador do domínio

New-Cluster -Name HVCLU01 -Node HV01, HV02 -StaticAddress 10.0.10.20 -NoStorage

O cluster se chama HVCLU01 (HVCLU01.jbitcore.lab) e responde em 10.0.10.20, na rede MGMT. É aqui que o gateway da MGMT faz falta: o cluster usa a rede com gateway como rede de acesso dos clientes.

Redes do cluster

O cluster detecta as três redes com nomes genéricos. Renomeie e defina o papel de cada uma:

# HV01 - PowerShell 5.1, Windows Server 2019, como administrador do domínio

Get-ClusterNetwork | Format-Table Name, Address, Role, State

(Get-ClusterNetwork | Where-Object Address -eq "10.0.10.0").Name = "MGMT"

(Get-ClusterNetwork | Where-Object Address -eq "10.0.20.0").Name = "iSCSI"

(Get-ClusterNetwork | Where-Object Address -eq "10.0.30.0").Name = "CLUS"

(Get-ClusterNetwork MGMT).Role  = 3

(Get-ClusterNetwork iSCSI).Role = 0

(Get-ClusterNetwork CLUS).Role  = 1

Get-ClusterNetwork | Format-Table Name, Address, Role, Metric, State -AutoSize

O resultado:

• CLUS (10.0.30.0): papel 1, Cluster Only, métrica 30240

• MGMT (10.0.10.0): papel 3, Cluster and Client, métrica 70240

• iSCSI (10.0.20.0): papel 0, None, métrica 70241

Confira também as interfaces de cada nó. Precisam ser seis, uma por rede em cada nó: 

# HV01 - PowerShell 5.1, Windows Server 2019

Get-ClusterNetworkInterface | Sort-Object Node, Network |

  Format-Table Node, Network, Name, Address -AutoSize

Se faltar uma interface, a placa daquele nó não está na rede certa. Se sobrar uma rede, como uma “Cluster Network 1” sem endereço, confira o AllowManagementOS do vSwitch. 

O papel 0 tira a rede iSCSI do cluster (nas propriedades, ela aparece como Do not allow cluster network communication on this network), para que o heartbeat e o CSV nunca disputem banda com o storage. A métrica menor faz da CLUS a rede preferida para o tráfego interno do cluster.

Live Migration

Em Failover Cluster Manager > Networks > Live Migration Settings, deixe a CLUS marcada e no topo, a MGMT marcada em segundo lugar, como reserva, e a iSCSI desmarcada.

Witness, quorum e CSV

Agora os discos entram no cluster. Eles são identificados pelo tamanho e renomeados:

# HV01 - PowerShell 5.1, Windows Server 2019, como administrador do domínio

Get-ClusterAvailableDisk | Format-Table Name, Number, Size

$w = Get-ClusterAvailableDisk | Where-Object Size -lt 2GB  | Add-ClusterDisk

$w.Name = "Witness"

$c = Get-ClusterAvailableDisk | Where-Object Size -gt 50GB | Add-ClusterDisk

$c.Name = "CSV01"

Set-ClusterQuorum -DiskWitness "Witness"

Add-ClusterSharedVolume -Name "CSV01"

Com dois nós, o quorum precisa de um terceiro voto para desempatar, e o disco witness dá esse voto (Node and Disk Majority). O CSV01 vira um Cluster Shared Volume, visível em C:\ClusterStorage\Volume1 nos dois nós ao mesmo tempo:

# HV01 e HV02 - PowerShell 5.1, Windows Server 2019

Get-ChildItem C:\ClusterStorage

Ver o Volume1 nos dois nós não basta: um nó sem acesso ao storage continua vendo o CSV, só que pelo outro nó, em modo redirecionado. Para confirmar o acesso direto:

# HV01 - PowerShell 5.1, Windows Server 2019

Get-ClusterSharedVolumeState -Name CSV01 |

  Format-Table Node, StateInfo, FileSystemRedirectedIOReason -AutoSize

Repare na diferença entre os dois discos. A witness pertence a um nó por vez, e é assim que ela desempata, pela reserva SCSI-3 que a validação testou; por isso, no Failover Cluster Manager, ela aparece com um Owner Node e parece indisponível para o outro. O CSV, ao contrário, é usado pelos dois nós simultaneamente.

Pegadinhas e lições do laboratório

O cluster não subiu de primeira, e isso foi bom: cada falha ensinou alguma coisa. A validação precisou de algumas rodadas até passar sem avisos, e os problemas foram apontados pelo próprio relatório do Test-Cluster.

As falhas da validação

• AllowManagementOS True em um nó: o vSwitch criou uma placa vEthernet só com IPv6 link-local, e o cluster passou a mostrar uma quarta rede, “Cluster Network 1”, que também apareceu no Live Migration Settings. Correção: Set-VMSwitch -AllowManagementOS $false no nó afetado.

• Placa iSCSI sem IP fixo: depois da criação do cluster, a placa iSCSI do HV01 voltou para DHCP e pegou um endereço 169.254.x.x. O cluster continuou no ar, porque o HV01 passou a acessar o CSV pelo HV02, em modo redirecionado. Na prática, o HV02 tinha virado um ponto único de falha. O sintoma estava na lista de interfaces (só cinco) e no Get-ClusterSharedVolumeState. Correção: IP fixo de volta e reboot do nó pausado para os Favorite Targets reconectarem.

• Falha na comunicação da rede CLUS. A CLUS de um nó não alcançava a do outro na porta UDP 3343. O ping para 10.0.30.12 voltava “Destination host unreachable” vindo do próprio IP, sinal de que o ARP não tinha resposta. A causa estava no Proxmox: a placa CLUS do HV02 tinha ido para a bridge hviscsi, por um clique errado. Correção: mover a placa para a hvclus. Lição: desconectar o cabo virtual confirma o nome da placa no Windows, mas não a bridge; confira com

qm config <id> | grep ^net. E “Destination host unreachable” vindo do próprio IP é problema de camada 2, não de firewall.

• Falha em todas as redes logo após criar o vSwitch. A porta UDP 3343 falhou nas três redes, com as regras de firewall e os perfis de rede corretos. Correção: reiniciar os dois nós. Lição: depois de mexer na pilha de rede (como criar um vSwitch), reinicie antes de validar.

• Conferência só da rede. Para confirmar a correção sem esperar a validação inteira, rodamos só os testes de rede (-Include "Network"), que passaram. Lição: quando a falha é localizada, valide só a categoria afetada; é mais rápido.

• Validação completa. Na rodada final, todas as categorias ficaram em Success, sem avisos.

O storage passou desde a primeira rodada, inclusive o teste de reserva persistente SCSI-3, que é o que permite ao cluster usar o disco witness.

Onde chegamos

Ao fim da Parte 1, o laboratório tem um cluster de dois nós no ar e validado: HVCLU01 em 10.0.10.20, redes separadas por função, Live Migration preferindo a rede CLUS, quorum com disco witness e um CSV de 100 GB pronto para receber VMs.

Uma limitação para ter em mente desde já: a SAN01 é um ponto único de falha. O cluster protege contra a queda de um nó, mas não contra a perda do storage. Esse ponto volta na Parte 3, no veredito final.

Próximo passo: na Parte 2 (em breve), vamos criar VMs altamente disponíveis no cluster, fazer Live Migration entre os nós e colocar um nó em manutenção sem parar as VMs.