Entenda, de forma prática e direta, quantos endereços IP você realmente precisa para configurar um cluster de failover com dois nós no Windows Server, quando separar redes e como planejar DNS, roteamento e boas práticas sem desperdiçar endereços.
Visão geral do cenário
Em um Windows Server Failover Cluster (WSFC) com dois servidores, o objetivo é manter serviços disponíveis mesmo quando um nó falha. Para isso, cada servidor precisa de conectividade estável e o próprio cluster expõe um ponto de acesso que os clientes utilizam. A dúvida recorrente é: quantos endereços IP devo reservar e como distribuí‑los entre redes de produção, tráfego interno do cluster, backup e armazenamento?
Embora existam variações conforme a carga de trabalho (Hyper‑V, SQL Server, File Server em alta disponibilidade, entre outras), há um denominador comum simples: o mínimo absoluto é reservar três IPs — um para cada nó e um para o ponto de acesso administrativo do cluster. A partir daí, IPs adicionais são decisões de design para isolar heartbeat, backup e/ou tráfego de armazenamento.
Resumo essencial dos endereços
| Item | Obrigatório? | Observações práticas |
|---|---|---|
| Endereço do nó primário | Sim | Cada servidor participante precisa de um IP único na rede de produção. |
| Endereço do nó secundário | Sim | Mesmo requisito do nó primário. |
| Ponto de acesso do cluster (Cluster Name Object / “Cluster IP”) | Sim | É o endereço virtual que os administradores e clientes usam para acessar o cluster. |
| Rede privada para heartbeat | Opcional | O WSFC usa qualquer rede comum aos nós para pulsos de saúde. Uma NIC dedicada melhora isolamento, mas não é requisito. |
| Rede para backup e/ou armazenamento | Opcional | Ao isolar backup, iSCSI ou SMB Direct em VLAN/NIC própria, cada interface precisa de seu próprio IP. |
Mínimo absoluto: três IPs. Recomendado em produção: quatro ou mais IPs quando você separa heartbeat, replicação, backup ou armazenamento.
Detalhes que fazem diferença
Como o cluster usa o endereço virtual
O nome do cluster é publicado no DNS com um endereço virtual. Esse IP não “mora” em um nó específico; ele acompanha o grupo de cluster conforme o proprietário ativo muda. Os clientes e administradores usam esse endereço para gerenciar e monitorar o cluster, e algumas funções também expõem seus próprios endereços virtuais.
Sobre redes de heartbeat
O heartbeat é a troca periódica de mensagens de saúde entre nós. O WSFC consegue fazê‑lo por qualquer rede comum. Separar uma rede de heartbeat pode reduzir ruído e evitar contendas, mas não é obrigatório. Se optar por separar, marque essa rede como “somente comunicação entre nós” para impedir que o tráfego de cliente passe por ali.
Sobre redes de backup e armazenamento
Boa prática é não misturar backup e iSCSI com a rede de produção. Separe VLANs/NICs para iSCSI e, quando usar SMB Direct (RDMA), mantenha redes dedicadas para esse tráfego. Cada NIC adicional requer um IP na sua respectiva rede. Em iSCSI, evite default gateway nessas NICs; utilize rotas estáticas conforme necessário.
Cenários práticos de contagem de IPs
Os exemplos abaixo ajudam a estimar a reserva de endereços em diferentes desenhos, mantendo o conceito de mínimo versus recomendado.
Ambiente de laboratório simples
- IPs necessários: nó primário, nó secundário, IP do cluster.
- Opções: tudo na mesma sub-rede, sem redes dedicadas. DNS registra o nome do cluster com um único A‑record.
- Observação: suficiente para estudo, prova de conceito e testes rápidos.
Produção com redes separadas para heartbeat
- IPs necessários: nó primário, nó secundário, IP do cluster, IPs da rede de heartbeat para cada nó.
- Configuração: marque a rede de heartbeat como “somente comunicação entre nós” no Gerenciador de Cluster.
- Benefício: isolamento e previsibilidade do tráfego de saúde do cluster.
Virtualização com Hyper‑V, CSV e live migration
- IPs necessários típicos por nó: produção/gerenciamento, rede de cluster/CSV, rede de live migration e, quando aplicável, redes SMB Direct. Além disso, um IP do cluster para administração.
- Regras: cada NIC dedicada a uma rede requer um IP. Em SMB Direct, cada rede RDMA costuma operar sem gateway e sem registro DNS.
- Nota: as máquinas virtuais possuem seus próprios endereços independentes do cluster.
Serviço que publica endereço virtual próprio
- Exemplo: File Server em alta disponibilidade ou SQL Server em instância de cluster de failover (FCI).
- IPs necessários: além do IP do cluster, cada Client Access Point desse serviço pode exigir outro IP virtual. Em desenho multi‑sub-rede, reserve um IP por sub-rede para cada ponto de acesso.
- Efeito: a contagem de IPs cresce conforme o número de serviços em alta disponibilidade expostos.
Implantação estendida entre sub-redes
- Contexto: nós em sub-redes distintas (site primário e site de contingência).
- IPs necessários: um IP do cluster por sub-rede, com dependência OR no recurso de nome. Apenas o IP da sub-rede ativa fica online.
- Atenção: cada serviço com nome virtual também precisa de um IP por sub-rede.
Como decidir quantas redes utilizar
- Defina a carga de trabalho: apenas administração do cluster ou serviços que expõem nomes virtuais? Se houver serviços, reserve IPs virtuais para cada um.
- Planeje isolamento: precisa separar heartbeat, backup, live migration, iSCSI ou SMB Direct? Some um IP por NIC por nó em cada rede dedicada.
- Considere resiliência: redes redundantes reduzem pontos únicos de falha; múltiplas NICs podem exigir teaming ou RDMA, conforme o caso.
- Avalie sub-redes: haverá mobilidade de função entre sub-redes? Então cada nome virtual terá um IP por sub-rede.
Planejamento de endereçamento e DNS
- Endereços estáticos ou reservas DHCP: para nós e IPs virtuais do cluster, prefira estático ou reserva de longa duração.
- Registro DNS: o IP do cluster e os IPs virtuais de serviços criam registros A em DNS. Garanta permissões adequadas do objeto de computador do cluster para atualizar registros.
- Desative registro em redes internas: em iSCSI, SMB Direct ou heartbeat, desmarque “Registrar este endereço no DNS” para evitar nomes resolvendo para redes internas.
- Rotas e gateways: não configure gateway padrão em NICs de armazenamento; use rotas estáticas quando necessário, mantendo o gateway apenas na rede de produção.
- IPv4 e IPv6: o WSFC funciona com ambos. Em muitos ambientes corporativos, a padronização em IPv4 estático simplifica operação e auditoria.
Passo a passo de configuração
- Validação: execute a Validação de Cluster para checar hardware, redes e armazenamento.
- Criação do cluster: no assistente, informe o nome do cluster e o endereço IP virtual. Em ambientes com DHCP, o assistente pode sugerir um IP automaticamente; valide o valor.
- Classificação das redes: em Failover Cluster Manager > Networks, abra as propriedades de cada rede:
- Produção: “Permitir que os nós se comuniquem nesta rede” e “Permitir que os clientes se conectem por esta rede”.
- Heartbeat/Interna: “Somente comunicação entre nós”.
- Armazenamento/SMB Direct: “Somente comunicação entre nós”, sem gateway e sem registro no DNS.
- Prioridade e métrica: ajuste a ordem de preferência com PowerShell para orientar qual rede o cluster usa para comunicação interna.
# Exibir redes e métricas
Get-ClusterNetwork | Format-Table Name, Role, Metric, AutoMetric
Tornar uma rede apenas interna ao cluster
(Get-ClusterNetwork -Name "Heartbeat").Role = 1 # 0=Desabilitada, 1=Somente cluster, 3=Cluster e clientes
Ajustar métrica manualmente (número menor = preferência maior)
(Get-ClusterNetwork -Name "Produção").AutoMetric = 0
(Get-ClusterNetwork -Name "Produção").Metric = 1000
(Get-ClusterNetwork -Name "Heartbeat").AutoMetric = 0
(Get-ClusterNetwork -Name "Heartbeat").Metric = 2000
Adição de IP para sub-rede alternativa
Em desenho multi‑sub-rede, adicione outro IP ao recurso de nome do cluster e configure dependência lógica para alternância correta entre sub-redes.
# Criar novo recurso de IP para a segunda sub-rede
Add-ClusterResource -Name "IP Secundário do Cluster" -ResourceType "IP Address" -Group "Cluster Group"
Definir parâmetros do novo IP
\$net = (Get-ClusterNetwork | Where-Object {$\_.Name -eq "Rede DR"})
Set-ClusterParameter -InputObject (Get-ClusterResource "IP Secundário do Cluster") ` -Name "Address" -Value "10.20.30.40"
Set-ClusterParameter -InputObject (Get-ClusterResource "IP Secundário do Cluster")`
-Name "SubnetMask" -Value "255.255.255.0"
Set-ClusterParameter -InputObject (Get-ClusterResource "IP Secundário do Cluster") \`
-Name "Network" -Value \$net.Id
Tornar o nome do cluster dependente de OR entre os IPs
\$clusterName = Get-ClusterResource -Name "Nome do Cluster"
Set-ClusterResourceDependency -Resource \$clusterName -Dependency "\[Cluster IP Address] or \[IP Secundário do Cluster]" Boas práticas de rede
- Redundância de NICs: para links de produção, avalie NIC Teaming. Para RDMA, evite teaming e use múltiplas NICs independentes com switch‑independent e múltiplos caminhos.
- Jumbo frames: útil em iSCSI e SMB Direct se toda a rota suportar MTU maior. Aplique de ponta a ponta.
- QoS e limitação: proteja live migration e backup para não saturarem a rede de produção.
- Quorum e testemunha: para dois nós, configure uma testemunha (compartilhamento de arquivos, disco ou nuvem) e garanta conectividade estável nessa rede.
Erros comuns e prevenção
- Permissões do nome do cluster: falhas ao registrar o A‑record acontecem quando o objeto do cluster não tem permissão no DNS. Revise ACLs e políticas.
- Registro indevido em DNS: se as NICs internas registrarem no DNS, clientes podem tentar acessar o cluster por redes erradas. Desative o registro nessas NICs.
- Gateway em NIC de armazenamento: manter gateway em iSCSI cria roteamento confuso. Use apenas gateway na rede de produção.
- Endereços duplicados: reserve previamente e documente a alocação para evitar conflitos.
- Dependências de IP em múltiplas sub-redes: esqueceu de configurar dependência OR? O nome do cluster não alternará corretamente entre IPs.
Checklist de alocação de endereços
| Item | Quantidade | Observações |
|---|---|---|
| IPs para os nós | Dois | Produção/gerenciamento em sub-rede de usuários/adm. |
| IP do cluster | Um por sub-rede | Administração e ponto único de acesso ao cluster. |
| IPs para redes internas | Um por NIC | Heartbeat, CSV, live migration, iSCSI, SMB Direct conforme design. |
| IPs para serviços em alta disponibilidade | Um por serviço por sub-rede | File Server, SQL FCI, DHCP e similares exigem ponto de acesso próprio. |
Perguntas frequentes
É obrigatório ter rede dedicada para heartbeat?
Não. O cluster usa qualquer rede comum para troca de pulsos. Separar ajuda, mas é opcional.
Se o cluster for apenas para Hyper‑V, preciso de IP adicional?
Além do IP do cluster administrativo, as VMs têm seus próprios IPs. Não há IP virtual de serviço adicional para Hyper‑V em si.
Posso usar DHCP?
Pode, mas prefira reservas estáticas para nós e para os IPs virtuais. Isso evita mudanças inesperadas e simplifica auditoria.
E em redes com IPv6?
Funciona. Muitos ambientes padronizam IPv4 estático para reduzir variáveis. Se usar IPv6, mantenha coerência de DNS, rotas e políticas.
O que muda em desenho multi‑sub-rede?
O nome do cluster e cada serviço que exponha nome virtual precisam de um IP por sub-rede, com dependências configuradas para ativar apenas o IP da sub-rede ativa.
Exemplo consolidado de planejamento
Suponha um cluster com dois servidores e os seguintes requisitos:
- Rede de produção para administração e acesso de clientes.
- Rede dedicada para heartbeat.
- Duas redes RDMA para SMB Direct/CSV.
- Serviço de File Server em alta disponibilidade.
Reserva de endereços sugerida:
- Nó primário: um IP em produção, um IP em heartbeat, dois IPs nas redes RDMA.
- Nó secundário: um IP em produção, um IP em heartbeat, dois IPs nas redes RDMA.
- Cluster administrativo: um IP virtual em produção.
- File Server: um IP virtual em produção.
No total, são oito IPs quando consideradas redes dedicadas e um serviço que publica endereço virtual próprio. Em versão mínima (sem heartbeat dedicado, sem redes RDMA e sem serviço que exponha nome): três IPs.
Conclusão objetiva
Para um WSFC com dois nós, três endereços IP compõem o piso: um para cada nó e um para o nome do cluster. A partir daí, a conta cresce conforme a necessidade de isolamento (heartbeat, backup, iSCSI, SMB Direct), de serviços com nomes virtuais (File Server, SQL FCI) e de sub-redes adicionais em implantações estendidas. Planeje o endereçamento junto com DNS, rotas e permissões do objeto de cluster para evitar surpresas. Em produção, separar pelo menos uma rede interna além da de produção é prática recomendada para reduzir pontos únicos de falha e dar previsibilidade ao tráfego do cluster.
Resumo prático para ação imediata
- Reserve três IPs como base e adicione IPs conforme redes e serviços que você decidir isolar.
- Marque redes internas como “somente comunicação entre nós” e desative o registro DNS nelas.
- Use endereços estáticos ou reservas DHCP e evite gateway em NICs de armazenamento.
- Em múltiplas sub-redes, crie um IP por sub-rede e configure dependência OR nos nomes virtuais.
- Documente tudo e valide o cluster antes de ir para produção.