Informazioni sul quorum di cluster e pool
Si applica a: Azure Stack HCI, versioni 22H2 e 21H2; Windows Server 2022, Windows Server
Importante
Azure Stack HCI is now part of Azure Local. La ridenominazione della documentazione del prodotto è in corso. Tuttavia, le versioni precedenti di Azure Stack HCI, ad esempio 22H2 continueranno a fare riferimento ad Azure Stack HCI e non rifletteranno la modifica del nome. Altre informazioni.
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 ospitano le risorse sono disponibili; Tuttavia, il cluster richiede in genere più della metà dei nodi da eseguire, noto come quorum.
Il quorum è progettato per evitare scenari split brain che possono verificarsi quando è presente una partizione nella rete e nei 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 con il concetto di quorum del clustering di failover, che forza solo uno di questi gruppi di nodi a continuare l'esecuzione, quindi solo uno di questi gruppi rimane 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 l'arresto del servizio cluster in uno dei subset di nodi per garantire che sia presente un solo 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 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 + Controllo del mirroring | Sì | No | No |
| 3 | Sì | 50/50 | No |
| 3 + Controllo del mirroring | Sì | Sì | No |
| 4 | Sì | Sì | 50/50 |
| 4 + Controllo del mirroring | Sì | Sì | Sì |
| 5 e oltre | Sì | Sì | Sì |
Raccomandazioni relative al quorum del cluster
- Se sono presenti due nodi, è necessario un server di controllo del mirroring.
- Se sono presenti tre o quattro nodi, il server di controllo del mirroring è fortemente consigliato.
- Se si hanno cinque nodi o più, un server di controllo del mirroring non è necessario e non offre resilienza aggiuntiva.
- Se si ha accesso a Internet, usare un cloud di controllo.
- 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ò alzarne uno aggiungendo un testimone con un voto aggiuntivo. Ciò richiede la configurazione dell'utente.
- In alternativa, può scendere uno zero azzerando il voto di un nodo sfortunato (avviene automaticamente in base alle esigenze).
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.
Controllo dinamico
Controllo dinamico attiva/disattiva il voto del server di controllo del mirroring 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 mirroring dinamico riduce significativamente il rischio che il cluster si arresti a causa di un errore di controllo. Il cluster decide se usare il voto di controllo in base al numero di nodi di voto disponibili nel cluster.
Il quorum dinamico funziona con il server di controllo dinamico nel modo descritto di seguito.
Comportamento del quorum dinamico
- Se si dispone di un numero pari di nodi e nessun server di controllo del mirroring, un nodo ottiene il voto zero. 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 server di controllo del mirroring , tutti ottengono voti.
- Se si dispone di un numero pari di nodi più server di controllo del mirroring, i voti del server di controllo del mirroring sono dispari.
- Se si dispone di un numero dispari di nodi più server di controllo del mirroring , il server di controllo del mirroring 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 ha Spazi di archiviazione diretta abilitato. Tuttavia, quando Spazi di archiviazione diretta è abilitato, il cluster può supportare solo due errori del nodo. Questa operazione è illustrata più in dettaglio nella sezione quorum del pool.
Esempi
Due nodi senza un server di controllo del mirroring
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 0/1 e il cluster si arresta. Se il nodo di voto viene normalmente spento, il voto viene trasferito all'altro nodo e il cluster sopravvive. Ecco perché è fondamentale configurare un server di controllo del mirroring.
- 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 di controllo del mirroring
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 ha 2/3 e il cluster sopravvive.
- 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 server di controllo del mirroring
Tutti i nodi votano, quindi la maggioranza viene determinata su un totale di 3 voti. Se un nodo si arresta, i sopravvissuti sono 2/3 e il cluster sopravvive. Il cluster diventa due nodi senza un server di controllo del mirroring, a quel punto si è 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 server di controllo del mirroring
Tutti i nodi votano, quindi il server di controllo del mirroring non vota inizialmente. La maggioranza è determinata da un totale di 3 voti. Dopo un errore, il cluster ha due nodi con un server di controllo del mirroring, che torna 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 server di controllo del mirroring
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 server di controllo del mirroring
Tutti i nodi voti e i voti di controllo, 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, o tutti tranne un voto, qualunque cosa faccia dispari il totale. Spazi di archiviazione diretta non è in grado di gestire più di due nodi inattivo, quindi a questo punto non è necessario o utile alcun server di controllo del mirroring.
- 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 si comprende il funzionamento del quorum, si esaminerà il tipo di server di controllo del quorum.
Tipi di controllo quorum
Il clustering di failover supporta tre tipi di server di controllo quorum:
- Cloud Di controllo : archiviazione BLOB 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.
- Controllo condivisione file: condivisione file SMB configurata in 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.
- Disco di controllo : un piccolo disco cluster presente nel gruppo Archiviazione disponibile cluster. Questo disco è a disponibilità elevata e può eseguire il failover tra i nodi. Contiene una copia del database del cluster. Un server di controllo del disco non è supportato con Spazi di archiviazione diretta.
Panoramica del quorum del pool
Si è appena parlato del quorum del cluster, che opera a livello di cluster. Si esaminerà ora il quorum del pool, che opera a livello di pool( ad esempio, è possibile perdere nodi e unità e mantenere 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.
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 + Controllo del mirroring | Sì | No | No |
| 3 | Sì | No | No |
| 3 + Controllo del mirroring | Sì | No | No |
| 4 | Sì | No | No |
| 4 + Controllo del mirroring | 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 passa offline o rimane online in base al fatto che disponga di dischi sufficienti per il quorum (50% + 1). Il database del cluster può essere +1 purché il cluster stesso sia quorate.
Ma il quorum del pool funziona in modo diverso rispetto al quorum del cluster nei modi seguenti:
- Il pool seleziona un subset di unità per nodo per ospitare i 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 il nodo due ha anche un voto (dal momento che è il proprietario della risorsa 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 layout simmetrico e errore di unità
Ognuna delle 16 unità ha un voto e il nodo 2 ha anche un voto (dal momento che è il proprietario della risorsa del pool). La maggioranza è determinata da un totale di 16 voti. Prima di tutto, l'unità 7 scende. Se i nodi tre e quattro si arrestano, il subset sopravvissuto ha 7 unità e il proprietario della risorsa 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
- Assicurarsi 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 inattivo più di due nodi o due nodi e un disco in un altro nodo sono inattivo, i volumi potrebbero non avere accesso a tutte e tre le copie dei dati e quindi essere portati offline e non disponibili. È consigliabile ripristinare i server o sostituire rapidamente i dischi per garantire la massima resilienza per tutti i dati nel volume.