Informazioni sul quorum di cluster e pool
Si applica a: Azure Stack HCI, versioni 22H2 e 21H2; Windows Server 2022, Windows Server
Il clustering di failover di Windows Server 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 elevati; Tuttavia, il cluster richiede in genere più di metà dei nodi in esecuzione, noto come quorum.
Quorum è progettato per evitare scenari di split-brain che possono verificarsi quando è presente una partizione nella rete e nei sottoinsieme di nodi non possono comunicare tra loro. Ciò può causare entrambi i subset di nodi di provare a possedere il carico di lavoro e scrivere nello stesso disco, che può causare numerosi problemi. Tuttavia, questo è impedito con il concetto di clustering di failover del quorum, 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 mentre rimane ancora online. Quorum è progettato per gestire lo scenario quando si verifica un problema con la comunicazione tra subset di nodi del cluster, in modo che più server non tentino contemporaneamente di ospitare un gruppo di risorse e scrivere nello stesso disco contemporaneamente. Avendo questo concetto di quorum, il cluster forza l'arresto del servizio cluster in uno dei sottoinsieme di nodi per garantire che sia presente un solo proprietario vero di un determinato gruppo di risorse. I nodi arrestati possono ancora una volta comunicare con il gruppo principale di nodi e rigiurne automaticamente il cluster e avviare il servizio cluster.
In Azure Stack HCI e Windows Server 2019 sono presenti due componenti del sistema che hanno i propri meccanismi quorum:
- Quorum del cluster: questo funziona a livello di cluster (ad esempio, è possibile perdere i nodi e mantenere il cluster)
- Quorum del pool: questo 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 in scenari cluster e non cluster, che è il 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 ogni 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 di controllo | Sì | No | No |
| 3 | Sì | 50/50 | No |
| 3 + Controllo di controllo | Sì | Sì | No |
| 4 | Sì | Sì | 50/50 |
| 4 + Controllo di controllo | Sì | Sì | Sì |
| 5 e oltre | Sì | Sì | Sì |
Raccomandazioni relative al quorum del cluster
- Se sono presenti due nodi, è necessario un controllo di controllo.
- Se sono presenti tre o quattro nodi, il controllo di controllo è fortemente consigliato.
- Se sono presenti cinque nodi o più, un server di controllo di controllo non è necessario e non offre una resilienza aggiuntiva.
- Se si dispone dell'accesso a Internet, usare un server di controllo cloud.
- Se si è in un ambiente IT con altre macchine e condivisioni file, usare un controllo di condivisione file.
Funzionamento del quorum del cluster
Quando i nodi non riescono o quando un sottoinsieme di nodi perde contatto con un altro subset, i nodi sopravvissuti devono verificare che costituiscono la maggior parte del cluster per rimanere online. Se non è possibile verificare che, verranno disattivati.
Ma il concetto di maggioranza funziona in modo pulito solo quando il numero totale di nodi nel cluster è strano (ad esempio, tre nodi in un cluster a cinque nodi). Quindi, quali sono i cluster con un numero pari di nodi (ad esempio, un cluster a quattro nodi)?
Esistono due modi in cui il cluster può rendere il numero totale di voti dispari :
- In primo luogo, può salire uno aggiungendo un controllo di controllo con un voto aggiuntivo. Ciò richiede la configurazione dell'utente.
- In alternativa, può andare giù uno zero zerondo un voto di un nodo sfortunato (viene eseguito 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, quindi 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
Il controllo dinamico attiva attiva il voto del controllo di controllo per assicurarsi che il numero totale di voti sia dispari. Se ci sono un numero di voti dispari, il testimone non ha un voto. Se c'è un numero pari di voti, il testimone ha un voto. Il controllo dinamico riduce significativamente il rischio che il cluster si arresta 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 controllo dinamico nel modo descritto di seguito.
Comportamento del quorum dinamico
- Se si dispone di un numero pari di nodi e nessun controllo di controllo, un nodo ottiene il relativo voto zero. Ad esempio, solo tre dei quattro nodi ottengono voti, quindi il numero totale di voti è tre e due sopravvissuti con voti sono considerati una maggioranza.
- Se si ha un numero dispari di nodi e nessun controllo di controllo, tutti ottengono voti.
- Se si dispone di un numero pari di nodi e di controllo, i voti del controllo di controllo, quindi il totale è dispari.
- Se si dispone di un numero di nodi dispari più il controllo di controllo, il controllo di controllo non vota.
Il quorum dinamico consente di assegnare un voto a un nodo in modo dinamico per evitare di perdere la maggioranza dei voti e di consentire al cluster di eseguire con un nodo (noto come last-man standing). Si prenda un cluster a quattro nodi come esempio. Si supponga che il quorum richieda 3 voti.
In questo caso, il cluster sarebbe andato giù se si perdevano due nodi.
Tuttavia, il quorum dinamico impedisce che questo accada. Il numero totale di voti necessari per il quorum è ora determinato in base al numero di nodi disponibili. Quindi, 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 abilitato. Tuttavia, quando Spazi di archiviazione diretta è abilitato, il cluster può supportare solo due errori del nodo. Questo argomento è illustrato di più nella sezione quorum del pool.
Esempio
Due nodi senza un controllo di controllo
Il voto di un nodo è zero, quindi il voto di maggioranza viene determinato al di fuori di un totale di 1 voto. Se il nodo non di voto scende in modo imprevisto, il sopravvissuto ha 1/1 e il cluster sopravvive. Se il nodo di voto scende in modo imprevisto, il sopravvissuto ha 0/1 e il cluster scende. Se il nodo di voto è inattivo, il voto viene trasferito all'altro nodo e il cluster sopravvive. Questo è il motivo per cui è fondamentale configurare un server di controllo del mirroring.
- Può sopravvivere a un errore del server: probabilità del 50%.
- Può sopravvivere a un errore del server, quindi a un altro: No.
- Può sopravvivere contemporaneamente a due errori del server: 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 a un altro: No.
- Può sopravvivere contemporaneamente a due errori del server: 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 contemporaneamente a due errori del server: 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 su 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 contemporaneamente a due errori del server: 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 votano 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, passare 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 comunque più di due nodi, quindi a questo punto non è necessario alcun server di controllo o 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 si comprende il funzionamento del quorum, si esaminino i tipi di testimoni del quorum.
Tipi di controllo quorum
Il clustering di failover supporta tre tipi 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 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 archivia una copia del database del cluster.
- Disco di controllo : un piccolo disco cluster che si trova nel gruppo Di archiviazione disponibile del cluster. Questo disco è a disponibilità elevata e può eseguire il failover tra i nodi. Contiene una copia del database 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 esamini ora il quorum del pool, che opera a livello di pool( ad esempio, è possibile perdere nodi e unità e mantenere il pool attivo). I pool di archiviazione sono stati progettati per essere usati in scenari cluster e 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, andranno 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.
Tuttavia, 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 le relazioni
- Il pool non dispone di quorum dinamico
- Il pool non implementa la propria versione di rimozione di un voto
Esempio
Quattro nodi con layout simmetrico
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 su un totale di 16 voti. Se i nodi tre e quattro vanno giù, 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 (poiché è il proprietario della risorsa del pool). La maggioranza è determinata su un totale di 16 voti. In primo luogo, l'unità 7 va giù. Se i nodi tre e quattro vanno giù, 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 a un altro: No.
- Può sopravvivere contemporaneamente a due errori del server: No.
Raccomandazioni sul 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 da poter tollerare due errori del nodo e mantenere online i dischi virtuali.
- Se più di due nodi sono inattivo 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.