Topologie di failover clustering

Windows Server Failover Clustering supporta più topologie di distribuzione per soddisfare requisiti aziendali diversi per la disponibilità elevata e il ripristino di emergenza per applicazioni, servizi e dati. Queste topologie offrono affidabilità, resilienza e tempi di attività critici in ambienti cloud locali, ibridi, pubblici, cloud privati e cloud sovrani.

La topologia scelta dipende da fattori quali l'infrastruttura fisica, i requisiti di latenza di rete, i vincoli di budget e gli obiettivi di ripristino. La comprensione di queste topologie consente di progettare la soluzione più adatta per i carichi di lavoro.

È anche possibile usare il clustering di failover nelle distribuzioni locali di Azure per offrire alta disponibilità all'interno delle località ai margini della rete. Per altre informazioni su Locale di Azure, vedere Che cosa sono le distribuzioni iperconvergente di Azure Local?

Topologie

Windows Server Failover Clustering supporta diverse topologie, ognuna con i propri vantaggi e compromessi. Le principali topologie includono:

• Cluster semplice (singolo dominio di errore)
• Cluster di Storage Spaces Direct del campus
• Cluster esteso di Storage Spaces Direct
• Cluster di estensione SAN
• Topologia multi-cluster

Le sezioni seguenti offrono una panoramica di ogni topologia, inclusi i casi d'uso, i vantaggi e le limitazioni.

Domini di errore del clustering di failover

Prima di esplorare topologie specifiche, è importante comprendere il concetto di domini di errore in un cluster di failover. Un dominio di errore è un raggruppamento logico di componenti hardware che condividono un punto di errore comune. Quando un componente in un dominio di errore ha esito negativo, può influire potenzialmente su tutti gli altri componenti nello stesso dominio.

Esempi comuni di domini di errore includono:

• Livello nodo: singoli errori del server a causa di problemi hardware, problemi del sistema operativo o manutenzione
• Livello rack: infrastruttura condivisa all'interno del rack, come le unità di distribuzione dell'alimentazione (PDU), gli switch di rete top-of-rack (TOR) o i sistemi di raffreddamento
• Livello di sala o data center: sistemi a livello di edificio come alimentatori principali, sistemi di raffreddamento o sicurezza fisica
• Livello del sito: rischi specifici della posizione geografica, ad esempio calamità naturali, interruzioni dell'alimentazione a livello di area o problemi di connettività di rete

Quando si progetta un cluster di failover, la comprensione e la pianificazione dei domini di errore è fondamentale per ottenere il livello di disponibilità e resilienza desiderato. Un cluster ben progettato continua a funzionare anche quando un intero dominio di errore ha esito negativo. Per esempio:

• Un cluster semplice con tutti i nodi in un rack può sopravvivere a singoli errori dei nodi, ma non un errore a livello di rack.
• Un cluster campus con nodi distribuiti tra due rack può sopravvivere al guasto di un intero rack.
• Un cluster esteso con nodi in siti geografici separati può sopravvivere a un guasto totale del sito.

Il numero e il tipo di domini di errore nella topologia influisce direttamente sulla capacità del cluster di gestire il servizio durante vari scenari di errore. Più domini di errore offrono in genere maggiore resilienza, ma presentano una maggiore complessità e costi.

Per altre informazioni sui domini di errore in Windows Server, vedere Riconoscimento del dominio di errore.

Confronto tra topologie

Nella tabella seguente vengono confrontate le caratteristiche principali di ogni topologia di clustering di failover:

Characteristic	Cluster semplice	Cluster Campus di Spazi di archiviazione diretti	Cluster di estensione di Storage Spaces Direct	SAN Stretch Cluster	Multi-Cluster
Ambito geografico	Singolo dominio di errore	Stessa posizione fisica, edifici separati	Separare i siti geografici	Siti geografici separati	Più siti separati
Tipo di rete	LAN (rete locale)	LAN (rete locale)	LAN o WAN	LAN o WAN	Determinato dal requisito del carico di lavoro
Latenza ottimale	≤1 ms	≤1 ms	≤1-5 ms (sincronizzazione) Variabile (asincrona)	Determinato dal fornitore SAN	Variabile (determinato dal carico di lavoro)
Configurazione dell'archiviazione	DESTINAZIONE SAN, NAS o iSCSI/Pool diretto di Spazi di archiviazione singola/combinato	Pool di Storage Spaces Direct singolo che si estende su rack	Separare i Pool di Spazi di Archiviazione Diretta per sito	LUN SAN replicati tra siti	Archiviazione indipendente per cluster
Metodo di replica di archiviazione	None	Mirror annidato a livello di rack diretto di Spazi di archiviazione	Replica di archiviazione	Replica del fornitore di SAN	Replica di archiviazione o a livello di applicazione
Domini di errore	Solo nodi	2 domini di errore	2 domini di errore	2 domini di errore	Cluster indipendenti
Protegge contro	Errore del nodo, Nodo + disco	Errore rack + nodo (configurazione 2+2)	Errore del sito	Errore del sito	Errore del sito e del cluster
Complessità della distribuzione	Low	Intermedio	Alto	Alto	Alto
Caso d'uso principale	Disponibilità elevata per data center singolo	Campus/multi-edificio ad alta disponibilità	Ripristino di emergenza (Disaster Recovery) dell'area metropolitana	Ripristino di emergenza dell'area metropolitana	Ripristino multi-regionale di emergenza (DR)

Configurazioni di archiviazione

Windows Server Failover Clustering supporta più architetture di archiviazione. È possibile combinare queste architetture con topologie di cluster diverse per soddisfare i requisiti di prestazioni, scalabilità e disponibilità. La scelta dell'architettura di archiviazione influisce sulla scalabilità delle risorse di calcolo e archiviazione, sulla resilienza dei dati e sul comportamento complessivo del cluster.

Le architetture di archiviazione principali includono:

• Archiviazione SAN o NAS: l'archiviazione condivisa esterna a cui si accede tramite la rete, consentendo il ridimensionamento indipendente delle risorse di calcolo e archiviazione.

• Iperconvergente: Storage Spaces Direct raggruppa i dischi locali tra i nodi del cluster con una scalabilità simmetrica di calcolo e archiviazione.

• Spazi di archiviazione diretta disaggregati: separare cluster di calcolo e archiviazione con scalabilità indipendente di ogni livello.

• Iperconvergente con l'archiviazione SAN: combina Spazi di archiviazione diretta con archiviazione SAN esterna nello stesso cluster.

• Architetture miste: più tipi di archiviazione che servono lo stesso cluster di calcolo per strategie di scalabilità flessibili.

Per informazioni dettagliate su ogni architettura di archiviazione, incluse le caratteristiche di scalabilità, le considerazioni sulla pianificazione e le linee guida per la distribuzione, vedere Architetture di archiviazione del clustering di failover.

Cluster semplice (singolo dominio di errore)

Un cluster semplice inserisce tutti i nodi del cluster all'interno di un singolo dominio di errore, in genere nello stesso rack fisico in una sala data center. Questa topologia è la topologia del cluster di failover più comune e semplice. Tutti i nodi si trovano in un rack, con archiviazione condivisa che può essere SAN, NAS, Spazi di archiviazione diretta (S2D) o S2D con coesistenza SAN. Questa configurazione offre ridondanza a livello di nodo e protezione da singoli errori del server mantenendo al tempo stesso la latenza di rete più bassa tra i nodi.

Il diagramma seguente illustra un esempio di topologia di cluster semplice con tutti i nodi nel dominio di errore del sito subnet predefinito usando una configurazione di archiviazione disaggregata.

Questa topologia è ideale per distribuzioni di singoli data center, carichi di lavoro che richiedono prestazioni elevate con latenza minima, organizzazioni con infrastruttura fisica limitata e ambienti di sviluppo e test. È la configurazione più semplice da distribuire e gestire, rendendola un ottimo punto di partenza per molte organizzazioni.

In un cluster semplice è possibile combinare Spazi di archiviazione diretta con soluzioni di archiviazione condivise come soluzioni SAN o NAS o usare spazi di archiviazione diretta da soli. Per ulteriori informazioni sulla combinazione di soluzioni di archiviazione, vedere Hyperconverged with SAN storage.

Tuttavia, questa topologia presenta limitazioni importanti. Non fornisce alcuna protezione da errori che potrebbero influire sull'intero dominio di errore. Ad esempio, se il dominio di errore è a livello di rack, errori come problemi di distribuzione dell'alimentazione o errori del commutatore top-of-rack potrebbero influire sulla disponibilità del cluster. Non offre inoltre alcuna protezione contro un data center più ampio o situazioni di emergenza a livello di sito. L'infrastruttura rack stessa rappresenta un singolo punto di errore che le organizzazioni devono accettare quando si sceglie questa topologia.

Campus cluster di Storage Spaces Direct

Un campus cluster di Storage Spaces Direct è una configurazione a due rack all'interno della stessa posizione fisica, come un'azienda, un ospedale, un campus universitario o un datacenter connesso da un'infrastruttura di rete locale (LAN) a bassa latenza. I cluster campus offrono resilienza a livello di rack usando Spazi di archiviazione diretti (S2D) con volumi di due copie o di quattro copie, noti come Rack Level Nested Mirror (RLNM). Questo approccio indica che i dati vengono distribuiti in modo intelligente tra rack. La topologia è progettata per la protezione da errori a livello di rack, mantenendo al tempo stesso bassa latenza tra i nodi.

Il diagramma seguente illustra un esempio di topologia del cluster campus di Storage Spaces Direct con nodi distribuiti su due domini di errore di rack all'interno della stessa posizione fisica.

I cluster Campus richiedono Windows Server 2025 con l'aggiornamento cumulativo di dicembre installato (KB5072033). I cluster campus supportano solo due domini di fault rack all'interno della stessa sede fisica connessa tramite LAN. Questa topologia differisce in modo significativo rispetto ai cluster estesi, che si estendono su siti geograficamente separati collegati tramite WAN e usano Storage Replica per la replica tra siti. Questa topologia offre resilienza a livello di rack per le macchine virtuali Hyper-V, SQL Server FCI, i file server, SAP e altre applicazioni.

La configurazione richiede esattamente due domini di errore del rack con un singolo pool di archiviazione di Storage Spaces Direct (S2D) che si estende su entrambi i rack. Rack Level Nested Mirror (RLNM) distribuisce le copie dei dati tra i rack: i volumi a due copie posizionano una copia in ciascun rack, mentre i volumi a quattro copie posizionano due copie in ciascun rack. Tutte le unità di capacità devono essere dello stesso tipo. Le unità SSD o NVMe basate su flash sono consigliate per ottenere prestazioni ottimali. I livelli di memorizzazione nella cache e i dischi rigidi non sono consigliati.

Il cluster campus usa la connettività LAN e richiede una latenza di 1 ms o inferiore tra i rack. Per ridurre il sovraccarico della CPU, è consigliabile usare schede di interfaccia di rete e commutatori RDMA. La configurazione funziona meglio con fili ridondanti di cavo in fibra scura tra rack e commutatori TOR (Top-of-Rack) a disponibilità elevata per evitare singoli punti di guasto. Ogni rack deve avere un percorso di rete separato per la risorsa quorum del cluster.

Questa topologia è ideale per ambienti campus, tra cui fabbriche, parchi commerciali, ospedali, scuole e campus universitari, navi e navi da crociera, e stadi. È anche ideale per le organizzazioni che soddisfano i requisiti NIS2 per stanze dati separate o qualsiasi posizione con due edifici o stanze connesse tramite fibra.

I cluster Campus supportano distribuzioni di nodi simmetriche (nodi per dominio di errore rack) con due e quattro volumi di copia consigliati. Ad esempio, 1+1, 2+2, 3+3 e così via, fino a un massimo di 10 nodi (5+5).

Le configurazioni comuni includono:

• 1+1: un nodo per ogni dominio di errore rack, la configurazione minima. Questa configurazione usa un mirror bidirezionale annidato con volumi di quattro copie per ottenere la massima resilienza dei dati. Per altre informazioni sui mirror annidati, vedere Resilienza annidata per Spazi di archiviazione diretta.
• 2+2: due nodi per ogni dominio di guasto rack, utilizzando qualsiasi combinazione di volumi a due o quattro copie.

Suggerimento

Una configurazione 2+2 con volumi con quattro copie offre il miglior equilibrio tra costi, prestazioni e resilienza, consentendo al cluster di sopravvivere alla perdita di un intero rack (dominio di errore) e di un nodo contemporaneamente.

Per altre informazioni sulle diverse opzioni di resilienza dei volumi, vedere Tolleranza di errore ed efficienza di archiviazione nei cluster locali di Azure e Windows Server.

Per il quorum del cluster, posizionare la risorsa testimone (Testimone condivisione file, Testimone disco, Testimone cloud, o Testimone USB) in una terza posizione, separata dai due rack.

I cluster campus di Storage Spaces Direct sono noti anche come cluster rack-aware per Azure Local. I cluster campus di Storage Spaces Direct offrono le stesse funzionalità e gli stessi vantaggi dell'Azure Local rack-aware cluster, ma hanno requisiti specifici di distribuzione e configurazione. Per altre informazioni sul clustering compatibile con rack locale di Azure, vedere Panoramica del clustering compatibile con rack locale di Azure.

È anche possibile ottenere altre informazioni sui cluster campus di Storage Spaces Direct nel nostro blog di annunci, Annunciamo il supporto per il Campus Cluster S2D su Windows Server 2025.

Estensione del cluster

Un cluster esteso, noto anche come cluster geografico o cluster multisito, estende un cluster di failover in due siti fisici geograficamente separati da un'infrastruttura WAN (Wide Area Network) ad alta velocità. La differenza principale da un cluster campus è che i cluster estesi si estendono su posizioni geografiche separate connesse tramite WAN, mentre i cluster del campus usano la connettività LAN all'interno di una singola posizione.

È possibile implementare cluster estesi usando due architetture di archiviazione diverse:

• Cluster esteso di Spazi di archiviazione diretta: ogni sito gestisce il proprio pool di Spazi di archiviazione diretta, con Replica di archiviazione che fornisce la replica tra siti
• Cluster di estensione SAN: usa l'archiviazione SAN condivisa o replicata con la tecnologia di replica specifica del fornitore

Entrambe le varianti di cluster estesi sono progettate per il ripristino di emergenza in tutte le aree metropolitane, mantenendo un'infrastruttura completa e indipendente in ogni posizione. Sono ideali per le organizzazioni con più posizioni del data center o con requisiti di conformità che obbligano la protezione dei dati fuori sede.

Per il quorum del cluster, usare un testimone di condivisione file o un testimone cloud. Il testimone deve essere accessibile da entrambi i siti per abilitare il failover automatico e determinare la maggioranza dei siti durante le partizioni di rete.

Le topologie di cluster estese sono più complesse da configurare e gestire rispetto ai cluster a sito singolo. Una latenza più elevata tra siti può influire sulle prestazioni di replica sincrone, indipendentemente dall'architettura di archiviazione scelta.

Cluster esteso di Storage Spaces Direct

In una configurazione di cluster stretch di Storage Spaces Direct, ogni sito opera il proprio pool di archiviazione indipendente. Storage Replica gestisce la replicazione tra siti ed è possibile configurarla come sincrona o asincrona a seconda della distanza e della latenza tra i siti.

Il diagramma seguente illustra un esempio di topologia di cluster Stretch di Storage Spaces Direct con nodi e pool di archiviazione in ogni sito geografico, connessi tramite WAN.

I requisiti di rete differiscono in base alla modalità di replica. La replica sincrona richiede una latenza di round trip inferiore a 5 ms sulla connessione WAN. Questo requisito garantisce prestazioni ottimali. La replica asincrona può funzionare con una latenza più elevata. Tuttavia, la replica asincrona implica la perdita di più dati durante un errore (RPO di dimensioni maggiori). Entrambe le modalità richiedono una connessione WAN dedicata a banda larga elevata tra i siti, e ogni sito deve avere un percorso di rete verso il testimone per garantire una gestione corretta del quorum.

Questa configurazione richiede l'edizione di Windows Server Datacenter per la funzionalità Replica di archiviazione. La larghezza di banda e l'affidabilità della rete sono fondamentali per mantenere la corretta replica e l'integrità del cluster.

Cluster di estensione SAN

Un cluster di estensione SAN si basa sulle funzionalità di replica del fornitore della rete di archiviazione per mantenere la sincronizzazione dei dati tra siti. La SAN gestisce la replica a livello di archiviazione, presentando LUN replicati ai nodi del cluster in entrambi i siti.

Il diagramma seguente illustra un esempio di topologia di cluster di estensione SAN con archiviazione SAN replicata in ogni sito geografico connesso tramite WAN.

Quando si implementa un cluster di estensione SAN, esaminare i requisiti di interoperabilità e le configurazioni supportate del fornitore SAN. Diversi fornitori san hanno requisiti diversi per latenza di rete, la larghezza di banda e i parametri di configurazione. Verificare che la soluzione SAN sia convalidata per gli scenari di cluster estesi e soddisfi gli obiettivi di ripristino di emergenza specifici.

I cluster di estensione SAN richiedono un'attenta collaborazione con gli amministratori di archiviazione e la conformità alle procedure consigliate specifiche del fornitore per la configurazione della replica, le procedure di failover e il monitoraggio.

Topologia multi-cluster

La topologia multi-cluster prevede la distribuzione di più cluster di failover indipendenti che interagiscono tra loro tramite la replica o il coordinamento a livello di applicazione. Questa topologia differisce fondamentalmente da un singolo cluster esteso. In questo approccio, due o più cluster di failover indipendenti operano in modo autonomo, con la replica a livello di applicazione tra cluster e nessun quorum condiviso o risorse del cluster.

Il diagramma seguente illustra un esempio di topologia multi-cluster con due cluster SQL indipendenti in siti geografici separati, connessi tramite wan e replicati a livello di applicazione.

I cluster replicano i dati tra loro usando metodi come:

• Gruppi di disponibilità AlwaysOn di SQL Server per i carichi di lavoro del database
• Copia basata su file per carichi di lavoro di archiviazione
• Strumenti di sincronizzazione personalizzati progettati per applicazioni specifiche

Questa topologia funziona bene per:

• Distribuzioni su larga scala che richiedono l'isolamento tra cluster
• Ambienti con limiti amministrativi o aree di sicurezza diversi
• Configurazioni attive in cui si distribuisce il carico tra siti
• Scenari che richiedono la separazione massima tra siti

È possibile gestire ogni cluster in modo indipendente e un errore in un cluster non influisce sul quorum di altri cluster. Questa architettura offre flessibilità nelle configurazioni e nelle versioni del cluster. Consente ai cluster di estendersi su distanze maggiori usando la replica asincrona senza i vincoli dei requisiti quorum di un singolo cluster.

Tuttavia, le distribuzioni multi-cluster richiedono un'attenta pianificazione. L'approccio dipende dal supporto delle applicazioni per la replica tra cluster. Comporta procedure operative più complesse rispetto alle topologie a cluster singolo. Potrebbe essere necessaria l'orchestrazione a livello di applicazione per gli scenari di failover. Il monitoraggio deve coprire in modo completo più ambienti cluster per garantire l'integrità e le prestazioni complessive del sistema.

Scelta della topologia appropriata

Quando si seleziona la topologia del cluster di failover appropriata, è necessario considerare attentamente più fattori tra le dimensioni aziendali, dell'infrastruttura, del carico di lavoro e delle operazioni.

Dal punto di vista aziendale, iniziare definendo l'obiettivo del tempo di ripristino (RTO), ovvero la velocità con cui i servizi devono essere ripristinati dopo un errore e l'obiettivo del punto di ripristino (RPO), la quantità di perdita di dati accettabile per l'organizzazione. Queste metriche influiscono direttamente sulla selezione della topologia. Considerare inoltre il budget per hardware, rete e licenze, perché le topologie più resilienti richiedono in genere un maggiore investimento. I requisiti normativi e di conformità possono imporre configurazioni specifiche, ad esempio data center separati geograficamente o specifici standard di protezione dei dati.

I fattori dell'infrastruttura modellano anche la decisione. Prendere in considerazione il numero e la posizione dei data center o delle sale a cui si ha accesso. Valutare i collegamenti di rete e la latenza tra siti. Esaminare i sistemi di archiviazione esistenti che è possibile riutilizzare. Valutare il backup dell'alimentazione e del raffreddamento in ogni posizione. Un campus con due edifici vicini collegati da fiber supporta topologie diverse rispetto ai data center distanti.

Le caratteristiche del carico di lavoro svolgono un ruolo fondamentale nella selezione della topologia. Valutare i modelli di I/O delle applicazioni e i requisiti di prestazioni, in quanto i carichi di lavoro sensibili alla latenza potrebbero non tollerare il sovraccarico della replica geografica.

Valutare la quantità di spazio di archiviazione necessaria, la larghezza di banda di rete disponibile e se il carico di lavoro può gestire i ritardi. Questi fattori consentono di decidere tra replica sincrona e asincrona.

Infine, non trascurare le considerazioni operative. Valutare le competenze e le risorse disponibili del team IT, perché le topologie più complesse richiedono conoscenze tecniche più approfondite.

Si pensi a come gestire e monitorare il cluster. Valutare la frequenza con cui è necessario testare il ripristino di emergenza. Esaminare le opzioni disponibili per le finestre di manutenzione e le pianificazioni di aggiornamento.

Una topologia che sembra ideale su carta potrebbe rivelarsi difficile da usare se supera le capacità del team o le risorse disponibili.

Contenuti correlati

• Panoramica del clustering compatibile con rack locale di Azure (anteprima)
• Panoramica di Storage Spaces Direct
• Failover clustering