Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Si applica a: Azure Stack HCI, versioni 22H2 e 21H2; Windows Server 2022, Windows Server
Windows Server Failover Clustering offre disponibilità elevata per i carichi di lavoro in esecuzione nei cluster Azure Stack HCI e Windows Server. Queste risorse sono considerate a disponibilità elevata se i nodi che le ospitano sono operativi. Tuttavia, il cluster richiede in genere che siano operativi più della metà dei nodi, condizione nota come quorum.
Il quorum è progettato per evitare scenari di split-brain che possono verificarsi quando c'è una partizione nella rete e i subset di nodi non possono comunicare tra loro. Ciò può causare che entrambi i subset di nodi tentino di possedere il carico di lavoro e di scrivere nello stesso disco, causando numerosi problemi. Tuttavia, ciò viene impedito dal concetto di quorum nel clustering di failover, che costringe uno solo di questi gruppi di nodi a continuare a funzionare, in modo che solo uno di questi gruppi rimanga online.
Quorum determina il numero di errori che il cluster può sostenere pur rimanendo online. Il quorum è progettato per gestire lo scenario in cui si verifica un problema di comunicazione tra subset di nodi del cluster, in modo che più server non tentino di ospitare contemporaneamente un gruppo di risorse e di scrivere nello stesso disco contemporaneamente. Avendo questo concetto di quorum, il cluster forza la cessazione del servizio del cluster in uno dei sottoinsiemi di nodi per garantire che ci sia un unico vero proprietario di un determinato gruppo di risorse. I nodi arrestati possono comunicare di nuovo con il gruppo principale di nodi e si riuniranno automaticamente nel cluster e avviano il servizio cluster.
In Azure Stack HCI e Windows Server 2019 sono disponibili due componenti del sistema che dispongono di meccanismi quorum specifici:
- Quorum del cluster: funziona a livello di cluster ( ad esempio, è possibile perdere i nodi e mantenere il cluster)
- Quorum Del Pool: funziona a livello di pool (ad esempio, è possibile perdere nodi e unità e mantenere attivo il pool). I pool di archiviazione sono stati progettati per essere usati sia in scenari cluster che non cluster, motivo per cui hanno un meccanismo quorum diverso.
Panoramica del quorum del cluster
La tabella seguente offre una panoramica dei risultati del quorum del cluster per scenario:
| Nodi server | Funzionamento anche in caso di errore di un nodo server | Funzionamento anche in caso di errore di un nodo server seguito da un altro errore | Funzionamento anche in caso di due errori simultanei dei nodi server |
|---|---|---|---|
| 2 | 50/50 | NO | NO |
| 2 + Testimone | Sì | NO | NO |
| 3 | Sì | 50/50 | NO |
| 3 + Testimone | Sì | Sì | NO |
| 4 | Sì | Sì | 50/50 |
| 4 + Testimone | Sì | Sì | Sì |
| 5 e oltre | Sì | Sì | Sì |
Raccomandazioni relative al quorum del cluster
- Se sono presenti due nodi, è necessario un testimone.
- Se sono presenti tre o quattro nodi, il witness è fortemente consigliato.
- Se si hanno cinque nodi o più, un testimone non è necessario e non offre resilienza aggiuntiva.
- Se si ha accesso a Internet, usare un testimone del cloud.
- Se si usa un ambiente IT con altri computer e condivisioni file, usare un server di controllo della condivisione file.
Funzionamento del quorum del cluster
Quando i nodi hanno esito negativo o quando un sottoinsieme di nodi perde il contatto con un altro subset, i nodi sopravvissuti devono verificare che rappresentino la maggior parte del cluster per rimanere online. Se non riescono a verificarlo, verranno offline.
Ma il concetto di maggioranza funziona correttamente solo quando il numero totale di nodi nel cluster è dispari (ad esempio, tre nodi in un cluster a cinque nodi). Che ne dici dei cluster con un numero pari di nodi(ad esempio, un cluster a quattro nodi)?
Esistono due modi in cui il cluster può rendere dispari il numero totale di voti :
- In primo luogo, può incrementarne uno aggiungendo un testimone con un voto in più. Ciò richiede la configurazione dell'utente.
- In alternativa, può scendere di una unità azzerando il voto di un nodo sfortunato (ciò avviene automaticamente quando necessario).
Ogni volta che i nodi sopravvissuti verificano correttamente che siano la maggioranza, la definizione della maggioranza viene aggiornata per essere tra i sopravvissuti. Ciò consente al cluster di perdere un nodo, un altro, un altro e così via. Questo concetto del numero totale di voti che si adattano dopo errori successivi è noto come quorum dinamico.
Testimone dinamico
"Il testimone dinamico attiva/disattiva il voto del testimone per assicurarsi che il numero totale di voti sia dispari." Se ci sono un numero dispari di voti, il testimone non ha un voto. Se c'è un numero pari di voti, il testimone ha un voto. Il testimone dinamico riduce significativamente il rischio che il cluster si arresti a causa di un guasto del testimone. Il cluster decide se utilizzare il voto di testimone in base al numero di nodi di voto che sono disponibili nel cluster.
Il quorum dinamico funziona con il testimone dinamico nel modo descritto di seguito.
Comportamento del quorum dinamico
- Se si dispone di un numero pari di nodi e nessun testimone, viene azzerato il voto di un nodo. Ad esempio, solo tre dei quattro nodi ottengono voti, quindi il numero totale di voti è tre e due sopravvissuti con voti vengono considerati una maggioranza.
- Se si dispone di un numero dispari di nodi e nessun testimone, tutti ottengono voti.
- Se si dispone di un numero pari di nodi più un testimone, il testimone vota, quindi il totale è dispari.
- Se si dispone di un numero dispari di nodi più un testimone, il testimone non voterà.
Il quorum dinamico consente di assegnare un voto a un nodo in modo dinamico per evitare di perdere la maggior parte dei voti e di consentire l'esecuzione del cluster con un nodo (noto come last-man standing). Di seguito è riportato un esempio di cluster a quattro nodi. Si supponga che il quorum richieda 3 voti.
In questo caso, il cluster sarebbe andato inattivo se si perdevano due nodi.
Tuttavia, il quorum dinamico impedisce che ciò accada. Il numero totale di voti necessari per il quorum viene ora determinato in base al numero di nodi disponibili. Pertanto, con quorum dinamico, il cluster rimane attivo anche se si perdono tre nodi.
Lo scenario precedente si applica a un cluster generale che non dispone di Spazi di archiviazione diretta abilitati. Tuttavia, quando Spazi di Archiviazione Diretta è abilitato, il cluster può supportare solo due guasti del nodo. Questa operazione è illustrata più in dettaglio nella sezione quorum del pool.
Esempi
Due nodi senza un testimone
Il voto di un nodo viene azzerato, quindi il voto di maggioranza viene determinato su un totale di 1 voto. Se il nodo non di voto si arresta in modo imprevisto, il sopravvissuto ha 1/1 e il cluster sopravvive. Se il nodo di voto si arresta in modo imprevisto, il sopravvissuto ha un risultato di 0/1 e il cluster si arresta anch'esso. Se il nodo di voto viene spento correttamente, il voto viene trasferito all'altro nodo e il cluster sopravvive. Ecco perché è fondamentale configurare un testimone.
- Può sopravvivere a un errore del server: 50% di probabilità.
- Può sopravvivere a un errore del server, quindi un altro: No.
- Può sopravvivere a due errori del server contemporaneamente: No.
Due nodi con un server witness
Entrambi i nodi votano, più i voti del testimone, quindi la maggioranza viene determinata su un totale di 3 voti. Se uno dei due nodi si arresta, il sopravvissuto mantiene 2/3 delle risorse e il cluster continua a funzionare.
Quorum illustrato nel caso con due nodi e un witness.
- Può sopravvivere a un errore del server: Sì.
- Può sopravvivere a un errore del server, quindi un altro: No.
- Può sopravvivere a due errori del server contemporaneamente: No.
Tre nodi senza un testimone
Tutti i nodi votano, quindi la maggioranza viene determinata su un totale di 3 voti. Qualora un nodo si arresti, 2/3 dei nodi sopravvivono e il cluster continua a funzionare. Il cluster diventa due nodi senza un testimone, a quel punto ci si trova nello scenario 1.
- Può sopravvivere a un errore del server: Sì.
- Può sopravvivere a un errore del server, quindi un altro: cinquanta percento di probabilità.
- Può sopravvivere a due errori del server contemporaneamente: No.
Tre nodi con un testimone
Tutti i nodi votano, quindi il testimone non vota all'inizio. La maggioranza è determinata da un totale di 3 voti. Dopo un errore, il cluster ha due nodi con un witness, tornando allo Scenario 2. Quindi, ora i due nodi e il voto del testimone.
- Può sopravvivere a un errore del server: Sì.
- Può sopravvivere a un errore del server, quindi un altro: Sì.
- Può sopravvivere a due errori del server contemporaneamente: No.
Quattro nodi senza un testimone
Il voto di un nodo è zero, quindi la maggioranza viene determinata su un totale di 3 voti. Dopo un errore, il cluster diventa tre nodi e si è nello scenario 3.
- Può sopravvivere a un errore del server: Sì.
- Può sopravvivere a un errore del server, quindi un altro: Sì.
- Può sopravvivere a due errori del server contemporaneamente: la probabilità del 50%.
Quattro nodi con un testimone
Tutti i nodi votano e anche i voti dei testimoni, quindi la maggioranza viene determinata su un totale di 5 voti. Dopo un errore, si è nello scenario 4. Dopo due errori simultanei, si passa allo scenario 2.
- Può sopravvivere a un errore del server: Sì.
- Può sopravvivere a un errore del server, quindi un altro: Sì.
- Può sopravvivere a due errori del server contemporaneamente: Sì.
Cinque nodi e oltre
Tutti i nodi votano, oppure votano tutti tranne uno, in modo che il totale sia dispari. Storage Spaces Direct non può gestire più di due nodi inattivi comunque, quindi a questo punto un testimone non è necessario né utile.
- Può sopravvivere a un errore del server: Sì.
- Può sopravvivere a un errore del server, quindi un altro: Sì.
- Può sopravvivere a due errori del server contemporaneamente: Sì.
Ora che comprendiamo come funziona il quorum, esaminiamo i tipi di testimoni del quorum.
Tipi di testimone del quorum
Il clustering di failover supporta tre tipi di server di controllo quorum:
- Cloud Witness - Blob Storage in Azure accessibile da tutti i nodi del cluster. Gestisce le informazioni di clustering in un file witness.log, ma non ne archivia una copia del database del cluster.
- Testimone di condivisione file – Una condivisione file SMB configurata su un file server che esegue Windows Server. Gestisce le informazioni di clustering in un file witness.log, ma non ne archivia una copia del database del cluster.
- Testimone del disco - un piccolo disco cluster presente nel gruppo Archiviazione disponibile cluster. Questo disco è altamente disponibile e può passare da un nodo all'altro in caso di guasto. Contiene una copia del database del cluster. Un testimone del disco non è supportato con Spazi di memorizzazione diretta.
Panoramica del quorum del pool
Si è appena parlato del quorum del cluster, che opera a livello di cluster. Esaminiamo ora il quorum del pool, che opera a livello di pool (ad esempio, è possibile perdere nodi e unità mantenendo il pool attivo). I pool di archiviazione sono stati progettati per essere usati sia in scenari cluster che non cluster, motivo per cui hanno un meccanismo quorum diverso.
La tabella seguente offre una panoramica dei risultati del quorum del pool per scenario:
| Nodi server | Funzionamento anche in caso di errore di un nodo server | Funzionamento anche in caso di errore di un nodo server seguito da un altro errore | Funzionamento anche in caso di due errori simultanei dei nodi server |
|---|---|---|---|
| 2 | Sì | NO | NO |
| 2 + Testimone | Sì | NO | NO |
| 3 | Sì | NO | NO |
| 3 + Testimone | Sì | NO | NO |
| 4 | Sì | NO | NO |
| 4 + Testimone | Sì | Sì | Sì |
| 5 e oltre | Sì | Sì | Sì |
Funzionamento del quorum del pool
Quando le unità hanno esito negativo o quando un sottoinsieme di unità perde il contatto con un altro subset, le unità che ospitano i metadati devono verificare che rappresentino la maggior parte del pool per rimanere online. Se non riescono a verificarlo, verranno offline. Il pool è l'entità che va offline o rimane online in base al fatto che abbia un numero sufficiente di dischi per raggiungere il quorum (50% + 1). Il database del cluster può essere il +1 finché il cluster stesso è in quorum.
Ma il quorum del pool funziona in modo diverso rispetto al quorum del cluster nei modi seguenti:
- Il pool seleziona un sottoinsieme di unità per ogni nodo per ospitare gli metadati.
- Il pool usa il database del cluster per interrompere i legami
- Il pool non dispone di quorum dinamico
- Il pool non implementa la propria versione di rimozione di un voto
Esempi
Quattro nodi con un layout simmetrico
Ognuna delle 16 unità ha un voto e al nodo due viene assegnato un voto in quanto proprietario delle risorse del pool. La maggioranza è determinata da un totale di 16 voti. Se i nodi tre e quattro si arrestano, il subset sopravvissuto ha 8 unità e il proprietario della risorsa del pool, ovvero 9/16 voti. Così, la piscina sopravvive.
- Può sopravvivere a un errore del server: Sì.
- Può sopravvivere a un errore del server, quindi un altro: Sì.
- Può sopravvivere a due errori del server contemporaneamente: Sì.
Quattro nodi con topologia simmetrica e guasto dell'unità di disco
Ognuna delle 16 unità ha un voto e il nodo 2 ha anche un voto (poiché è il proprietario della risorsa del pool). La maggioranza è determinata da un totale di 16 voti. Prima di tutto, il drive 7 scende. Se i nodi tre e quattro si arrestano, il sottoinsieme rimanente ha 7 unità e il proprietario delle risorse del pool, ovvero 8/16 voti. Quindi, la piscina non ha la maggioranza e scende.
- Può sopravvivere a un errore del server: Sì.
- Può sopravvivere a un errore del server, quindi un altro: No.
- Può sopravvivere a due errori del server contemporaneamente: No.
Raccomandazioni per il quorum del pool
- Accertarsi che ogni nodo del cluster sia simmetrico (ogni nodo ha lo stesso numero di unità)
- Abilitare il mirroring a tre vie o la doppia parità in modo che sia possibile tollerare due errori del nodo e mantenere online i dischi virtuali.
- Se sono inattivi più di due nodi, o due nodi e un disco in un altro nodo sono inattivi, i volumi possono non avere accesso a tutte e tre le copie dei dati e quindi essere messi offline e non disponibili. È consigliabile ripristinare i server o sostituire rapidamente i dischi per garantire la massima resilienza per tutti i dati nel volume.