Obter verdadeiro funcionamento ininterrupto para uma aplicação de missão crítica não exige SAN nem virtualização pesada—com dois servidores físicos idênticos e o Windows Server 2019 é possível formar um cluster em workgroup que faz failover automático e mantém o serviço disponível 24 × 7.
Desafio de alta disponibilidade com servidores físicos
Empresas de todos os tamanhos procuram eliminar pontos únicos de falha sem inflar custos ou complexidade. O cenário típico envolve dois servidores bare‑metal executando a mesma carga de trabalho. Se um deles falhar por hardware, software ou manutenção programada, o usuário final não deve perceber. Soluções baseadas em hipervisor (Live Migration, vMotion) ou em storage dedicado (SAN, NAS com multipath) funcionam, porém acrescentam licenças, energia, tráfego de rede e novos itens a monitorar.
Desde o Windows Server 2016 a Microsoft permite construir Windows Server Failover Clusters (WSFC) sem Active Directory, adotando o modo workgroup. Esse avanço remove a necessidade de um domínio e, aliado a recursos de réplica de disco, permite criar um cluster “apenas com o que você já possui no gabinete”.
Como o Windows Server Failover Cluster resolve o problema
O WSFC age como um “guarda‑chuva” de monitoramento: ele verifica constantemente se cada nó (servidor) e cada serviço (recurso) estão de pé. Caso algo caia, o cluster reinicia o recurso ou o move para outro nó conforme políticas configuradas. Para duas máquinas físicas, o papel do cluster é redirecionar clientes de um host para o outro em questão de segundos.
Matriz de requisitos práticos
| Requisito | Detalhes práticos |
|---|---|
| Cluster em workgroup | Disponível a partir do Windows Server 2016; nenhum controlador de domínio é necessário. |
| Test‑Cluster | Executa validações de hardware, rede e armazenamento antes da criação. |
| Criação do cluster | New-Cluster -Name MeuCluster -Node SRV1,SRV2 -NoStorage |
| Quorum/Witness | File‑Share witness, Cloud witness no Azure ou USB disk witness compartilhado por SMB. |
| Replicação de dados | Storage Replica, Storage Spaces Direct ou mecanismo nativo da aplicação (ex.: SQL Always On). |
| Limitações em workgroup | Sem Cluster‑Aware Updating, Live Migration Kerberos, entre outros recursos avançados. |
Pré‑requisitos fundamentais
- Hardware idêntico: CPU, memória, controladora RAID e versão de firmware iguais evitam problemas de driver.
- Patches de segurança e cumulative updates no mesmo nível em ambos os hosts.
- Duas redes independentes: uma para tráfego de produção (client access) e outra dedicada ao heartbeat do cluster/replicação.
- Permissões de administrador local em cada servidor; sem necessidade de conta de domínio.
Instalação e validação do cluster
A instalação da função de clustering é trivial, mas a validação evita horas de troubleshooting posterior.
Install-WindowsFeature Failover-Clustering -IncludeManagementTools
Test-Cluster -Node SRV1,SRV2
O Test-Cluster gera um relatório HTML destacando qualquer configuração fora do padrão: drivers de NIC, timeouts de disco, diversidade de adaptadores, etc. Corrija cada item antes de seguir.
Criação do cluster
Se os discos locais não serão compartilhados, use a opção -NoStorage. O WSFC criará recursos core (Cluster Name Object, IP do cluster) e aguardará que você adicione funções de carga de trabalho.
New-Cluster -Name FILECLUSTER -Node SRV1,SRV2 -NoStorage
É recomendável reiniciar os nós após essa etapa para garantir que todos os serviços do cluster carreguem com as dependências corretas.
Configuração do witness
Em um cluster de apenas dois nós, o witness é obrigatório para evitar split‑brain (situação em que cada servidor pensa ser o único vivo). Escolha o tipo de witness conforme a infraestrutura disponível:
- File‑Share Witness: qualquer compartilhamento SMB acessível por ambos os nós, hospedado em NAS ou até mesmo em uma terceira VM.
- Cloud Witness: pequeno arquivo de blob armazenado no Azure; requer somente conta de armazenamento.
- USB Disk Witness: disco USB conectado a um NAS com SMB ou a um pequeno servidor de arquivos.
Set-ClusterQuorum -FileShareWitness \\NAS\Quorum
Estratégias de replicação de dados
Sem um volume compartilhado, cada nó tem seu próprio conjunto de discos. Para fornecer dados consistentes durante o failover, você precisa de réplica síncrona (para zero perda) ou assíncrona (para distâncias maiores):
Storage Replica
Incluído no Windows Server 2019 Standard (somente assíncrona) e Datacenter (síncrona). Replica bloco a bloco em volumes inteiros ou partições selecionadas. Latência de rede recomenda‑se <5 ms para síncrono.
Storage Spaces Direct (S2D)
Reúne discos locais (HDD/SSD/NVMe) via SMB‑Direct, cria pools e volumes CSV apresentados ao cluster. Necessita edição Datacenter e NICs RDMA 10 GbE ou superior. Traz desempenho de SAN sem hardware dedicado.
Replicação ao nível da aplicação
Algumas workloads realizam sua própria cópia de dados. Exemplos:
- SQL Server Always On Availability Groups
- File Server Resource Manager com DFS Replication
- Serviços Web stateless que persistem estado em banco externo
Nesse modelo, o cluster apenas monitora o serviço; a consistência cabe à aplicação.
Passo a passo para adicionar uma aplicação ao cluster
- No Gerenciador de Cluster, clique em Roles → Configure Role e escolha o tipo de serviço (Generic Service, File Server, etc.).
- Selecione o nome do serviço do Windows ou caminho do executável.
- Defina IP e DNS sob demanda. Ele será movido junto com o serviço no failover.
- Configure políticas de reinício, prioridade e ordem de dependência.
- Teste o failover manual para verificar se a aplicação fica acessível no nó secundário.
Vantagens do cluster em workgroup
- Elimina custos de SAN ou hipervisor.
- Sobe rapidamente: apenas habilitar função, nenhum schema de AD.
- Permite usar discos NVMe locais e RDMA para baixíssima latência.
- Combinado a Storage Replica oferece RPO 0 entre servidores no mesmo rack.
Pontos de atenção
- Clusters em workgroup não suportam Live Migration de VMs Hyper‑V com autenticação Kerberos.
- Sem Cluster‑Aware Updating, o patching deve ser manual ou via scripts.
- Necessário witness externo permanente; perda do witness reduz tolerância a falhas.
- Verifique incompatibilidades: alguns softwares herdados exigem casa‑matriz em AD.
Licenciamento e custos
O Windows Server 2019 Standard já inclui direito a Failover Clustering. Entretanto, Storage Spaces Direct requer edição Datacenter. Storage Replica síncrono também só está presente no Datacenter; na edição Standard você se limita ao modo assíncrono e um único volume até 2 TB.
Monitorização e manutenção
Use o console Failover Cluster Manager para:
- Visualizar status de nós, redes e recursos.
- Agendar failover simulado (planejamento de manutenção).
- Gerar relatórios Health Service em HTML para auditoria.
O Windows Admin Center simplifica tarefas e oferece dashboards em tempo real, inclusive para Storage Replica. Habilite notificações do Cluster Aware Monitoring (CAM) para receber alertas de degradação antes que vire indisponibilidade.
Backups continuam imprescindíveis
Alta disponibilidade não substitui backup. Se malware criptografa dados ou uma operação acidental remove arquivos, o cluster replicará instantaneamente o estado corrompido. Mantenha cópias off‑site, teste restaurações e crie snapshots consistentes de app.
Planejamento de recuperação de desastres
Se um desastre afetar todo o site (incêndio, falta de energia prolongada), ambos os nós podem ficar off‑line. Para mitigar, implemente réplica assíncrona para um terceiro servidor em outra localidade ou aproveite Azure Site Recovery. Combine VPN ou ExpressRoute para manter latências razoáveis caso precise failover para nuvem.
Troubleshooting recorrente e boas práticas
- Erro 1194: Cluster Network not found. Verifique se as NICs foram adicionadas corretamente e se a métrica automática não marcou a interface errada como cluster‑only.
- CSV em paused state. Quorum instável ou perda de replicação pode pausar volumes. Reintegre o witness e force resync.
- Event ID 7024 no serviço de cluster. Geralmente DLL de antivírus em conflito; crie exceções.
- Agende validação mensal com
Test-Cluster -Include Inventory, Network, SystemConfigurationpara detectar drift de driver.
Exemplo de script completo de criação
# Variáveis
$nodes = 'SRV1','SRV2'
$clusterName = 'PROD-CLUSTER'
$witness = '\\NAS01\Quorum$
Instalação
Invoke-Command -ComputerName \$nodes -ScriptBlock {
Install-WindowsFeature Failover-Clustering -IncludeManagementTools
}
Validação
Test-Cluster -Node \$nodes -Verbose
Criação
New-Cluster -Name \$clusterName -Node \$nodes -NoStorage -StaticAddress 10.10.0.50
Witness
Set-ClusterQuorum -FileShareWitness \$witness
Adicionar serviço genérico
Add-ClusterGenericServiceRole -Cluster \$clusterName \`
-Name "MeuServico" -ServiceName "NomeDoServico" Conclusão
Com o Windows Server 2019 é perfeitamente factível alcançar failover automático entre dois servidores físicos em workgroup. A solução dispensa SAN e hipervisor, reduz capex e mantem‑se dentro da edição Standard, desde que você:
- Valide hardware e rede com
Test-Cluster; - Implemente um witness confiável para quorum;
- Escolha uma estratégia de réplica coerente com o RPO/RTO exigido;
- Monitore continuamente e mantenha backups externos;
- Teste failover periodicamente para assegurar que o SLA de 24 × 7 seja cumprido.
Ao seguir estas recomendações, o serviço permanecerá disponível mesmo diante de falhas de hardware, atualizações ou desastres locais, garantindo continuidade operacional e tranquilidade para a equipe de TI.