Windows Server 2025 / Progettare un cluster di failover

Windows Server Failover Clustering (WSFC), il clustering di failover di Windows Server, coordina ruoli supportati tra server e può riavviarli o spostarli dopo un guasto. Due server da soli non costituiscono una soluzione completa: applicazione, archiviazione, rete, quorum, convalida e obiettivi di ripristino devono essere coerenti.

Definire i guasti da sostenere

Un nodo è un server partecipante. Un ruolo del cluster è un gruppo di risorse di servizio o macchina virtuale gestito dal cluster. Rilevare un guasto e trasferire il ruolo può interrompere le connessioni. Verifica quindi quando il client si riconnette e quando l’applicazione torna realmente utilizzabile, oltre allo stato online mostrato nella console.

L’alta disponibilità non sostituisce backup e ripristino di emergenza. Due macchine virtuali sullo stesso host fisico possono arrestarsi insieme; anche host distinti possono condividere archiviazione, alimentazione o switch. Abilitare la funzionalità cluster su normali server IIS non rende automaticamente i loro siti altamente disponibili. Verifica prima l’architettura supportata dall’applicazione.

Definisci il ruolo protetto, il Recovery Time Objective (RTO), ossia il tempo di ripristino accettabile, e il Recovery Point Objective (RPO), ossia la perdita di dati accettabile rispetto a un punto recuperabile. Registra inizio e fine della misurazione e prove necessarie. Interruzioni e perdita di dati pari a zero non sono caratteristiche automatiche di un cluster.

Valutare nodi, rete e capacità residua

Confronta i requisiti hardware e di archiviazione del cluster con versione Windows Server, dispositivi supportati, driver e firmware. Per un nuovo progetto usa nodi Windows Server 2025 comparabili, verificando supporto e convalida dell’intera configurazione. Nella procedura ordinaria di dominio valgono condizioni sulla stessa versione e sullo stesso dominio; i cluster in gruppo di lavoro hanno requisiti differenti. Non mescolare le procedure.

• Mappa traffico di amministrazione, cluster, archiviazione e migrazione delle macchine virtuali ove prevista. Stima banda e concorrenza del traffico durante guasto e ripristino.
• Individua singoli punti di guasto in schede, switch, alimentazione e percorsi di archiviazione. Registra dipendenze condivise anche se i nodi hanno nomi diversi.
• Calcola CPU, memoria e capacità di archiviazione residue dopo la perdita di un nodo, includendo carichi trasferiti e risincronizzazione. Una somma sufficiente in condizioni normali non dimostra capacità durante il guasto.
• Per la distribuzione di dominio verifica DNS interno, sincronizzazione oraria, identità del cluster e diritti di registrazione dei nomi. Separa nodi e controller di dominio secondo il metodo di distribuzione.

Raccogli indirizzi, nomi, reti locali virtuali (VLAN) e requisiti firewall in un piano di rete condiviso. Più schede sullo stesso switch o percorso di cablaggio non creano percorsi indipendenti. Per esempio, alla perdita di un host indica quale nodo prende il carico e con quali risorse libere. Alla perdita dell’archiviazione condivisa, spiega se i nodi superstiti possono ancora accedere ai dati. Distingui questi scenari prima di acquistare capacità.

Scegliere archiviazione supportata dal ruolo

Dischi condivisi, archiviazione Server Message Block (SMB) e Storage Spaces Direct hanno condizioni specifiche di ruolo, hardware, edizione e supporto. Non ogni scelta è adatta a ogni carico. Cartelle locali con lo stesso nome su due nodi non offrono dati condivisi; DFS Namespaces non crea automaticamente replica o archiviazione del cluster. La soluzione scelta deve permettere al nodo subentrante di accedere ai dati aggiornati tramite una configurazione supportata.

Usa un ambiente di prova separato prima di presentare dischi operativi alla configurazione o alla convalida dell’archiviazione. Documenta proprietà dei dischi, prenotazioni, percorsi e condizioni di licenza dell’architettura. Un disco visibile non è necessariamente libero da assegnare. Non coinvolgere dati di produzione in test dell’archiviazione senza un piano che protegga servizio e dati.

Pianificare quorum e posizione del witness

Il quorum determina se il cluster può continuare a operare anche quando una partizione di rete ne separa i componenti, contribuendo a evitare proprietà concorrente delle stesse risorse. Un witness partecipa a questa decisione; non è una copia dei dati del servizio né un nodo aggiuntivo che esegue il carico. Raggiungere il witness non dimostra l’accessibilità dell’archiviazione o dell’applicazione.

Confronta witness disco, condivisione file e cloud con la guida alla distribuzione dei witness di quorum. Oltre al numero di nodi, considera posizione, autorizzazioni, partizioni di rete e connettività esterna. Ogni tipo ha requisiti propri; il witness cloud, ad esempio, dipende da risorse Azure approvate e connessioni HTTPS dai nodi. Il quorum dinamico non garantisce resistenza a qualsiasi combinazione o sequenza di guasti.

Un witness nello stesso dominio di guasto può scomparire insieme a entrambi i nodi. La distanza fisica non basta se si perdono percorsi comuni o manca l’autorizzazione. Prepara una matrice per perdita di nodo, collegamento tra nodi, percorso di archiviazione e intera sede. Per ciascun caso annota partecipanti rimasti, posizione del witness, accesso ai dati e comportamento previsto. Confrontala con la guida del tipo scelto prima di considerare dimostrata la continuità.

Richiedere convalida prima della distribuzione

1. Documenta nodi, reti, archiviazione, account, nomi e ruoli protetti. Assegna responsabili e collega ogni dipendenza ai guasti che può provocare.
2. Allinea funzionalità, aggiornamenti, driver e requisiti di supporto. Conferma compatibilità della configurazione completa, oltre a quella dei componenti isolati.
3. Pianifica la convalida prima della creazione. Risolvi o spiega ogni avviso ed errore con impatto e azione; salvare un rilievo non equivale ad averlo valutato.
4. Prova gli spostamenti pianificati separatamente dai guasti imprevisti in un ambiente autorizzato. Un trasferimento riuscito non dimostra identico rilevamento e recupero automatico.
5. Misura riconnessione dei client, coerenza dei dati, tempo di ripristino e consegna degli avvisi. Confronta osservazioni con RTO e RPO e documenta differenze senza inventare misurazioni.
6. Convalida separatamente recupero dei backup e perdita di un intero dominio di guasto. Includi sequenza di ripristino, dipendenze, responsabili e criteri per tornare al funzionamento normale.

Segui la guida alla creazione e convalida del cluster appropriata all’architettura. I test dell’archiviazione possono influire sul servizio: non eseguirli tutti indiscriminatamente in produzione. Conserva rapporto, causa, impatto e azione per ogni rilievo. Nel metodo di dominio pianifica diritti per amministrare i nodi e creare o predisporre gli oggetti computer necessari; non assegnare amministrazione dell’intero dominio solo per aggirare un errore di autorizzazione.

Questa esercitazione di progettazione non trasforma DC1, FS1 o gli altri server del corso in un cluster. Produce un progetto di ruoli supportati, fabbisogno di risorse, mappa dei domini di guasto, obiettivi di interruzione e piano di convalida con responsabili. Se resta incerto cosa accade alla perdita dell’archiviazione o come recuperare un file eliminato, registra il punto aperto. Aggiungere un nodo non risolve automaticamente tali condizioni.