Comprensione del cluster e piscina quorum

• 01/18/2019
• 11 minuti a leggere
• • un
  • e
  • v
  • C
  • J
  • +3

si Applica a: Windows Server 2019, Windows Server 2016

Windows Server Clustering di Failover garantisce l’alta disponibilità dei carichi di lavoro. Queste risorse sono considerate altamente disponibili se i nodi che ospitano le risorse sono attivi; tuttavia, il cluster richiede generalmente più della metà dei nodi per essere in esecuzione, che è noto come avere quorum.

Quorum è progettato per prevenire scenari split-brain che possono accadere quando c’è una partizione nella rete e sottoinsiemi di nodi non possono comunicare tra loro. Ciò può causare entrambi i sottoinsiemi di nodi per cercare di possedere il carico di lavoro e scrivere sullo stesso disco che può portare a numerosi problemi. Tuttavia, questo viene impedito con il concetto di quorum del Clustering di failover che costringe solo uno di questi gruppi di nodi a continuare a funzionare, quindi solo uno di questi gruppi rimarrà online.

Quorum determina il numero di errori che il cluster può sostenere pur rimanendo in linea. Quorum è progettato per gestire lo scenario in caso di problemi di comunicazione tra sottoinsiemi di nodi cluster, in modo che più server non tentino di ospitare contemporaneamente un gruppo di risorse e di scrivere sullo stesso disco allo stesso tempo. Avendo questo concetto di quorum, il cluster costringerà il servizio cluster a fermarsi in uno dei sottoinsiemi di nodi per garantire che esista un solo vero proprietario di un particolare gruppo di risorse. Una volta che i nodi che sono stati fermati possono ancora una volta comunicare con il gruppo principale di nodi, si ricongiungeranno automaticamente al cluster e avvieranno il loro servizio cluster.

In Windows Server 2019 e Windows Server 2016, ci sono due componenti del sistema che hanno i propri meccanismi di quorum:

• Quorum cluster: funziona a livello di cluster (cioè è possibile perdere nodi e mantenere il cluster attivo)
• Quorum del pool: funziona a livello del pool quando è abilitato Storage Spaces Direct (ovvero è possibile perdere nodi e unità e mantenere il pool attivo). I pool di archiviazione sono stati progettati per essere utilizzati in scenari cluster e non cluster, motivo per cui hanno un meccanismo di quorum diverso.

Panoramica del quorum del cluster

La tabella seguente fornisce una panoramica dei risultati del Quorum del cluster per scenario:

i nodi del Server	Può sopravvivere a un server del nodo	Può sopravvivere a un nodo del server di fallimento, poi un altro	Può sopravvivere contemporaneamente due server errori di nodo
2	50/50	No	No
2 + Testimonianza	Sì	No	No
3	Sì	50/50	No
3 + Testimonianza	Sì	Sì	No
4	Sì	Sì	50/50
4 + Testimonianza	Sì	Sì	Sì
5 e al di sopra di	Sì	Sì	Sì

Il quorum del Cluster di raccomandazioni

• Se si dispone di due nodi, un testimone è necessario.
• Se si dispone di tre o quattro nodi, witness è fortemente raccomandato.
• Se si dispone di accesso a Internet, utilizzare un cloud testimonianza
• Se sei in un ambiente con altre macchine e condivisioni di file, utilizzare un testimone di condivisione file

Come quorum del cluster opere

Quando i nodi non riuscire, o quando un certo sottoinsieme di nodi perde il contatto con un altro sottoinsieme, nodi necessario verificare che costituiscono la maggioranza del cluster di rimanere on-line. Se non possono verificarlo, andranno offline.

Ma il concetto di maggioranza funziona in modo pulito solo quando il numero totale di nodi nel cluster è dispari (ad esempio, tre nodi in un cluster a cinque nodi). Quindi, che dire dei cluster con un numero pari di nodi (ad esempio, un cluster a quattro nodi)?

Ci sono due modi in cui il cluster può rendere dispari il numero totale di voti:

1. In primo luogo, può salire uno aggiungendo un testimone con un voto in più. Ciò richiede la configurazione dell’utente.
2. Oppure, può scendere uno azzerando il voto di un nodo sfortunato (avviene automaticamente se necessario).

Ogni volta che i nodi sopravvissuti verificano con successo che sono la maggioranza, la definizione di maggioranza viene aggiornata per essere solo tra i sopravvissuti. Ciò consente al cluster di perdere un nodo, poi un altro, poi un altro e così via. Questo concetto del numero totale di voti che si adatta dopo fallimenti successivi è noto come quorum dinamico.

Dynamic witness

Dynamic witness commuta 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. Dynamic witness riduce significativamente il rischio che il cluster diminuisca a causa di un guasto del testimone. Il cluster decide se utilizzare il voto testimone in base al numero di nodi di voto disponibili nel cluster.

Dynamic quorum funziona con Dynamic witness nel modo descritto di seguito.

Comportamento quorum dinamico

• Se hai un numero pari di nodi e nessun testimone, un nodo ottiene il suo voto azzerato. 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 hai un numero dispari di nodi e nessun testimone, ottengono tutti voti.
• Se hai un numero pari di nodi più testimone, il testimone vota, quindi il totale è dispari.
• Se hai un numero dispari di nodi più testimone, il testimone 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 consentire al cluster di funzionare con un nodo (noto come last-man standing). Prendiamo un cluster a quattro nodi come esempio. Supponiamo che il quorum richieda 3 voti.

In questo caso, il cluster sarebbe andato giù se hai perso due nodi.

Tuttavia, il quorum dinamico impedisce che ciò accada. Il numero totale di voti necessari per il quorum è ora determinato in base al numero di nodi disponibili. Quindi, con il quorum dinamico, il cluster rimarrà attivo anche se perdi tre nodi.

Lo scenario precedente si applica a un cluster generale che non dispone di Spazi di archiviazione diretti abilitati. Tuttavia, quando Storage Spaces Direct è abilitato, il cluster può supportare solo due errori di nodo. Questo è spiegato più nella sezione pool quorum.

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 votante si interrompe inaspettatamente, il sopravvissuto ha 1/1 e il cluster sopravvive. Se il nodo di voto scende inaspettatamente, il sopravvissuto ha 0/1 e il cluster scende. Se il nodo di voto viene disattivato con grazia, il voto viene trasferito all’altro nodo e il cluster sopravvive. Questo è il motivo per cui è fondamentale configurare un testimone.

• Può sopravvivere a un errore del server: cinquanta per cento di possibilità.
• Può sopravvivere a un errore del server, quindi a un altro: No.
• Può sopravvivere a due errori del server contemporaneamente: No.

Due nodi con un testimone.

Entrambi i nodi votano, più i voti dei testimoni, quindi la maggioranza è determinata su un totale di 3 voti. Se uno dei nodi va giù, 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 a due errori del server contemporaneamente: No.

Tre nodi senza un testimone.

Tutti i nodi votano, quindi la maggioranza è determinata su un totale di 3 voti. Se un nodo va giù, i sopravvissuti sono 2/3 e il cluster sopravvive. Il cluster diventa due nodi senza un testimone – a quel punto, sei nello scenario 1.

• Può sopravvivere a un errore del server: Sì.
• Può sopravvivere a un errore del server, poi a un altro: cinquanta per cento di possibilità.
• Può sopravvivere a due errori del server contemporaneamente: No.

Tre nodi con un testimone.

Tutti i nodi votano, quindi il testimone non vota inizialmente. La maggioranza è determinata su un totale di 3 voti. Dopo un errore, il cluster ha due nodi con un testimone-che è tornato allo scenario 2. Quindi, ora i due nodi e il voto dei testimoni.

• Può sopravvivere a un errore del server: Sì.
• Può sopravvivere a un errore del server, poi a un altro: Sì.
• Può sopravvivere a due errori del server contemporaneamente: No.

Quattro nodi senza testimone

Il voto di un nodo viene azzerato, quindi la maggioranza viene determinata su un totale di 3 voti. Dopo un errore, il cluster diventa tre nodi e sei nello scenario 3.

• Può sopravvivere a un errore del server: Sì.
• Può sopravvivere a un errore del server, poi a un altro: Sì.
• Può sopravvivere a due errori del server contemporaneamente: cinquanta per cento di possibilità.

Quattro nodi con un testimone.

Tutti i voti dei nodi e i voti dei testimoni, quindi la maggioranza è determinata su un totale di 5 voti. Dopo un fallimento, sei 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, poi a 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 renda il totale dispari. Storage Spaces Direct non può gestire più di due nodi in giù comunque, quindi a questo punto, nessun testimone è necessario o utile.

• Può sopravvivere a un errore del server: Sì.
• Può sopravvivere a un errore del server, poi a un altro: Sì.
• Può sopravvivere a due errori del server contemporaneamente: Sì.

Ora che abbiamo capito come funziona il quorum, diamo un’occhiata ai tipi di testimoni del quorum.

Tipi di testimoni del quorum

Il clustering di failover supporta tre tipi di testimoni del Quorum:

• Cloud Witness-Archiviazione Blob in Azure accessibile da tutti i nodi del cluster. Mantiene informazioni clustering in un testimone.file di registro, ma non memorizza una copia del database del cluster.
• File Share Witness-Una condivisione di file SMB configurata su un file server che esegue Windows Server. Mantiene informazioni clustering in un testimone.file di registro, ma non memorizza una copia del database del cluster.
• Disk Witness-Un piccolo disco cluster che si trova nel Cluster Available Storage group. Questo disco è altamente disponibile e può eseguire il failover tra i nodi. Contiene una copia del database del cluster. Un testimone disco non è supportato con Storage Spaces Direct.

Panoramica del quorum del pool

Abbiamo appena parlato del Quorum del cluster, che opera a livello di cluster. Ora, tuffiamoci nel Quorum del pool, che opera a livello del pool (cioè puoi perdere nodi e unità e far sì che il pool rimanga attivo). I pool di archiviazione sono stati progettati per essere utilizzati in scenari cluster e non cluster, motivo per cui hanno un meccanismo di quorum diverso.

La tabella seguente fornisce una panoramica dei risultati del quorum del pool per scenario:

i nodi del Server	Può sopravvivere a un server del nodo	Può sopravvivere a un nodo del server di fallimento, poi un altro	Può sopravvivere contemporaneamente due server errori di nodo
2	No	No	No
2 + Testimonianza	Sì	No	No
3	Sì	No	No
3 + Testimonianza	Sì	No	No
4	Sì	No	No
4 + Testimonianza	Sì	Sì	Sì
5 e al di sopra di	Sì	Sì	Sì

Come piscina quorum opere

Quando le unità non riuscire, o quando un certo sottoinsieme di unità perde il contatto con un altro sottoinsieme, unità funzionanti necessario verificare che rappresentano la maggioranza della piscina per rimanere in linea. Se non possono verificarlo, andranno offline. Il pool è l’entità che va offline o rimane online in base al fatto che abbia abbastanza dischi per il quorum (50% + 1). Il proprietario della risorsa pool (nodo cluster attivo) può essere +1.

Ma il quorum del pool funziona in modo diverso dal quorum del cluster nei seguenti modi:

• piscina utilizza un nodo del cluster, come testimonianza di un tie-break per sopravvivere metà di unità andato (questo nodo che è il pool di risorse proprietario)
• il pool NON ha dinamica quorum
• la piscina NON implementare la propria versione di rimozione di un voto

Esempi

Quattro nodi con una struttura simmetrica.

Ciascuna delle 16 unità ha un voto e il nodo due ha anche un voto (poiché è il proprietario della risorsa pool). La maggioranza è determinata su un totale di 16 voti. Se i nodi tre e quattro diminuiscono, il sottoinsieme superstite ha 8 unità e il proprietario della risorsa pool, che è 9/16 voti. Quindi, la piscina sopravvive.

• Può sopravvivere a un errore del server: Sì.
• Può sopravvivere a un errore del server, poi a un altro: Sì.
• Può sopravvivere a due errori del server contemporaneamente: Sì.

Quattro nodi con layout simmetrico e guasto dell’unità.

Ciascuna delle 16 unità ha un voto e il nodo 2 ha anche un voto (poiché è il proprietario della risorsa pool). La maggioranza è determinata su un totale di 16 voti. In primo luogo, unità 7 va giù. Se i nodi tre e quattro vanno giù, il sottoinsieme superstite ha 7 unità e il proprietario della risorsa pool, che è 8/16 voti. Quindi, la piscina non ha la maggioranza e va giù.

• Può sopravvivere a un errore del server: Sì.
• Può sopravvivere a un errore del server, quindi a un altro: No.
• Può sopravvivere a due errori del server contemporaneamente: No.

Quattro nodi con un layout non simmetrico.

Ciascuna delle 24 unità ha un voto e il nodo due ha anche un voto (poiché è il proprietario della risorsa pool). La maggioranza è determinata su un totale di 24 voti. Se i nodi tre e quattro diminuiscono, il sottoinsieme superstite ha 8 unità e il proprietario della risorsa pool, che è 9/24 voti. Quindi, la piscina non ha la maggioranza e va giù.

• Può sopravvivere a un errore del server: Sì.
• Può sopravvivere a un errore del server, poi un altro: * * Dipende * * (non può sopravvivere se entrambi i nodi tre e quattro vanno giù, ma può sopravvivere a tutti gli altri scenari.
• Può sopravvivere a due errori del server contemporaneamente: ** Dipende * * (non può sopravvivere se entrambi i nodi tre e quattro vanno giù, ma può sopravvivere a tutti gli altri scenari.

Raccomandazioni del quorum del pool

• Assicurati che ogni nodo del cluster sia simmetrico (ogni nodo ha lo stesso numero di unità)
• Abilita il mirror a tre vie o la doppia parità in modo da poter tollerare gli errori di un nodo e mantenere online i dischi virtuali. Vedi la nostra pagina di guida del volume per maggiori dettagli.
• Se più di due nodi sono inattivo o due nodi e un disco su un altro nodo sono inattivo, i volumi potrebbero non avere accesso a tutte e tre le copie dei loro dati e pertanto essere offline e non essere disponibili. Si consiglia di riportare i server o sostituire rapidamente i dischi per garantire la massima resilienza per tutti i dati nel volume.