{"id":92570,"date":"2020-08-28T19:42:21","date_gmt":"2020-08-28T17:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker"},"modified":"2020-08-28T19:42:21","modified_gmt":"2020-08-28T17:42:21","slug":"modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker","title":{"rendered":"Modellazione di cluster ad alta disponibilit\u00e0 basati su PostgreSQL e Pacemaker","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Introduzione<\/h1>\n

<\/p>\n

Qualche tempo fa, mi \u00e8 stato affidato il compito di sviluppare un cluster resiliente per PostgreSQL<\/a><\/noindex>, che opera in diversi data center collegati da fibra ottica all'interno della stessa citt\u00e0 e in grado di resistere a un guasto (come un'interruzione di corrente) di un data center. Ho scelto come software per la resilienza Pacemaker<\/a><\/noindex>, perch\u00e9 \u00e8 la soluzione ufficiale di RedHat per creare cluster resilienti. \u00c8 vantaggioso poich\u00e9 RedHat fornisce supporto e perch\u00e9 \u00e8 una soluzione versatile (modulare). Con esso sar\u00e0 possibile garantire la resilienza non solo di PostgreSQL, ma anche di altri servizi, sia utilizzando moduli standard, sia creandoli per esigenze specifiche.<\/p>\n

<\/p>\n

A questo punto \u00e8 sorto un legittimo interrogativo: quanto sar\u00e0 resiliente il cluster resiliente? Per esplorare questo aspetto, ho sviluppato un banco di prova che simula vari guasti sui nodi del cluster, attende il ripristino della funzionalit\u00e0, riporta online il nodo guasto e continua il test in ciclo. Inizialmente questo progetto si chiamava hapgsql, ma col tempo mi sono stancato di un nome con solo una vocale. Pertanto, ho iniziato a chiamare i database resilienti (e l'IP fluttuante che li indica) krogan<\/strong> (un personaggio di un videogioco, il cui corpo ha tutti gli organi principali duplicati), mentre nodi, cluster e il progetto stesso sono stati denominati tuchanka<\/strong> (il pianeta dove vivono i krogan).<\/p>\n

<\/p>\n

Attualmente la direzione ha autorizzato l'apertura del progetto alla comunit\u00e0 open source con licenza MIT<\/a><\/noindex>. Il README sar\u00e0 presto tradotto in inglese (poich\u00e9 ci si aspetta che i principali utilizzatori siano gli sviluppatori di Pacemaker e PostgreSQL), mentre il precedente README in russo lo sistemer\u00f2 (parzialmente) sotto forma di questo articolo.<\/p>\n

<\/p>\n

\"Modellazione<\/p>\n

<\/a><\/noindex><\/p>\n

I cluster vengono distribuiti su macchine virtuali VirtualBox<\/a><\/noindex>. In totale saranno distribuite 12 macchine virtuali (per un totale di 36 GiB), che formeranno 4 cluster resilienti (diverse configurazioni). I primi due cluster sono composti da due server PostgreSQL, che si trovano in diversi data center, e da un server comune witness<\/em> c quorum device<\/strong> (ospitato su una macchina virtuale economica in un terzo data center), che risolve l'incertezza 50%\/50%<\/strong>, esprimendo il proprio voto a favore di una delle parti. Il terzo cluster \u00e8 distribuito su tre data center: un master, due slave, senza quorum device<\/strong>. Il quarto cluster \u00e8 composto da quattro server PostgreSQL, due per centro dati: uno master, gli altri repliche, e utilizza anche witness<\/em> c quorum device<\/strong>. Il quarto supporta il guasto di due server o di un centro dati. Questa soluzione pu\u00f2 essere, se necessario, scalata a un maggior numero di repliche.<\/p>\n

<\/p>\n

Servizio di ora esatta ntpd<\/a><\/noindex> \u00e8 anch'esso configurato per la tolleranza ai guasti, ma utilizza il metodo stesso ntpd<\/code> (orphan mode<\/em>). Il server generale witness<\/em> svolge il ruolo di server NTP centrale, distribuisce il suo tempo a tutti i cluster, sincronizzando cos\u00ec tutti i server tra loro. Se witness<\/em> si guasta o risulta isolato, allora uno dei server del cluster (all'interno del cluster) inizier\u00e0 a distribuire il suo tempo. Un proxy di caching HTTP<\/strong> \u00e8 anch'esso attivo su witness<\/em>, grazie al quale le altre macchine virtuali hanno accesso ai repository Yum. Nella realt\u00e0, servizi come l'ora esatta e il proxy saranno sicuramente ospitati su server dedicati, mentre nello stand sono ospitati su witness<\/em> soltanto per risparmiare il numero di macchine virtuali e spazio.<\/p>\n

<\/p>\n

Versioni<\/h1>\n

<\/p>\n

v0. Funziona con CentOS 7 e PostgreSQL 11 su VirtualBox 6.1.<\/p>\n

<\/p>\n

Struttura dei cluster<\/h1>\n

<\/p>\n

Tutti i cluster sono progettati per essere ospitati in diversi centri dati, uniti in una rete piatta e devono tollerare il guasto o l'isolamento di rete di un centro dati. Pertanto non \u00e8 possibile<\/strong> utilizzare per proteggersi da split-brain<\/strong> la tecnologia standard Pacemaker, chiamata STONITH<\/em> (Shoot The Other Node In The Head) oppure fencing<\/em>. Il principio \u00e8: se i nodi nel cluster iniziano a sospettare che un certo nodo possa avere dei problemi, non risponde o si comporta in modo anomalo, allora lo disattivano forzatamente tramite dispositivi \u201cesterni\u201d, ad esempio, una scheda di controllo IPMI o un UPS. Ma questo funziona solo se, in caso di guasto di un server singolo, IPMI o UPS continuano a funzionare. Qui si prevede una protezione contro un guasto molto pi\u00f9 catastrofico, quando fallisce (ad esempio, viene disalimentato) l'intero centro dati. E in caso di tale guasto, tutti dispositivi stonith<\/em>(IPMI, UPS, ecc.) non funzioneranno nemmeno.<\/p>\n

<\/p>\n

Invece, il sistema si basa sull'idea di quorum. Tutti i nodi hanno diritto di voto e possono lavorare solo quelli che vedono pi\u00f9 della met\u00e0 di tutti i nodi. Questo numero di 'met\u00e0+1' \u00e8 chiamato quorum<\/strong>. Se non si raggiunge il quorum, il nodo decide che si trova in isolamento di rete e deve disattivare le proprie risorse, cio\u00e8 \u00e8 una sorta di protezione contro lo split-brain<\/strong>. Se il software che gestisce questo comportamento non funziona, allora dovrebbe attivarsi il watchdog, ad esempio, sulla base di IPMI.<\/p>\n

<\/p>\n

Se il numero di nodi \u00e8 pari (cluster in due data center), pu\u00f2 sorgere quella che viene chiamata incertezza. 50%\/50%<\/strong> (cinquanta e cinquanta<\/em>), quando l'isolamento di rete divide il cluster esattamente a met\u00e0. Pertanto, per un numero pari di nodi si aggiunge quorum device<\/strong> \u2014 un demone non esigente, che pu\u00f2 essere eseguito sulla virtual machine pi\u00f9 economica nel terzo data center. Esso d\u00e0 la propria voce a uno dei segmenti (che vede), e in tal modo risolve l'incertezza 50%\/50%. Il server su cui verr\u00e0 eseguito il dispositivo di quorum l'ho chiamato witness<\/em> (terminologia di repmgr, mi \u00e8 piaciuta).<\/p>\n

<\/p>\n

Le risorse possono spostarsi da un luogo all'altro, ad esempio, dai server guasti a quelli funzionanti, o su comando degli amministratori di sistema. Affinch\u00e9 i clienti sappiano dove si trovano le risorse di cui hanno bisogno (dove collegarsi?), si utilizzano IP fluttuanti<\/em> (float IP<\/strong>). Questi sono IP che Pacemaker pu\u00f2 spostare tra i nodi (tutto si trova in una rete piatta). Ognuno di essi simboleggia una risorsa (servizio) e si trover\u00e0 l\u00ec dove \u00e8 necessario collegarsi per accedere a questo servizio (nel nostro caso al DB).<\/p>\n

<\/p>\n

Tuchanka1 (schema di sigillatura)<\/h2>\n

<\/p>\n

Struttura<\/h3>\n

<\/p>\n

\"Modellazione<\/p>\n

<\/p>\n

L'idea era che abbiamo molte piccole banche dati con un carico basso, per le quali non \u00e8 conveniente mantenere un server slave dedicato in modalit\u00e0 hot standby per le transazioni in sola lettura (non c'\u00e8 bisogno di uno spreco di risorse simile).<\/p>\n

<\/p>\n

In ogni data center c'\u00e8 un server. Su ogni server ci sono due istanze di PostgreSQL (nella terminologia di PostgreSQL si chiamano cluster, ma per evitare confusione li chiamer\u00f2 istanze (analogamente ad altri database), e solo i cluster di Pacemaker saranno definiti cluster). Un'istanza opera in modalit\u00e0 master e solo essa fornisce servizi (su di essa c'\u00e8 un float IP). La seconda istanza opera come slave per il secondo data center e fornir\u00e0 servizi solo se il suo master dovesse guastarsi. Poich\u00e9 per la maggiore parte del tempo fornir\u00e0 servizi (eseguendo query) solo un'istanza su due (il master), tutte le risorse del server sono ottimizzate per il master (viene allocata memoria per il cache shared_buffers, ecc.), ma in modo che anche la seconda istanza abbia sufficienti risorse (anche se per un'operazione non ottimale tramite la cache del filesystem) nel caso di un guasto di uno dei data center. Lo slave non fornisce servizi (non esegue query in sola lettura) durante il normale funzionamento del cluster, per evitare conflitti per le risorse con il master sulla stessa macchina.<\/p>\n

<\/p>\n

Nel caso di due nodi, la tolleranza ai guasti \u00e8 possibile solo con la replica asincrona, poich\u00e9 con la replica sincrona il guasto dello slave porter\u00e0 all'arresto del master.<\/p>\n

<\/p>\n

Guasto witness<\/h3>\n

<\/p>\n

\"Modellazione<\/p>\n

<\/p>\n

Guasto witness (quorum device<\/em>) considerer\u00f2 solo per il cluster Tuchanka1, con tutti gli altri sar\u00e0 la stessa storia. In caso di guasto del witness, la struttura del cluster non cambier\u00e0, continuer\u00e0 a funzionare come ha sempre fatto. Ma il quorum diventer\u00e0 2 su 3, e quindi qualsiasi guasto successivo diventer\u00e0 fatale per il cluster. Sar\u00e0 comunque necessario ripararlo urgentemente.<\/p>\n

<\/p>\n

Guasto Tuchanka1<\/h3>\n

<\/p>\n

\"Modellazione<\/p>\n

<\/p>\n

Guasto di uno dei data center per Tuchanka1. In questo caso witness<\/em> d\u00e0 il suo voto al secondo nodo nel secondo data center. Qui l'ex slave si trasforma in master, quindi su un server funzionano entrambi i master e su di essi puntano entrambi i loro float IP.<\/p>\n

<\/p>\n

Tuchanka2 (classico)<\/h2>\n

<\/p>\n

Struttura<\/h3>\n

<\/p>\n

\"Modellazione<\/p>\n

<\/p>\n

Schema classico di due nodi. Su uno funziona il master, sull'altro lo slave. Entrambi possono eseguire query (lo slave solo in sola lettura), quindi su entrambi ci sono float IP: krogan2 \u2014 sul master, krogan2s1 \u2014 sullo slave. La tolleranza ai guasti sar\u00e0 sia per il master che per lo slave.<\/p>\n

<\/p>\n

Nel caso di due nodi, la tolleranza ai guasti \u00e8 possibile solo con la replica asincrona, poich\u00e9 con la replica sincrona il guasto dello slave porter\u00e0 all'arresto del master.<\/p>\n

<\/p>\n

Guasto Tuchanka2<\/h3>\n

<\/p>\n

\"Modellazione<\/p>\n

<\/p>\n

In caso di guasto di uno dei data center witness<\/em> vota per il secondo. Sul data center attualmente funzionante verr\u00e0 attivato un master, e su di esso verranno puntati entrambi gli IP float: quello master e quello slave. Ovviamente, l'istanza deve essere configurata in modo tale da avere risorse sufficienti (limiti per connessione, ecc.) per gestire simultaneamente tutte le connessioni e le richieste provenienti dall'IP float master e slave. Quindi, durante il normale funzionamento, deve avere un adeguato margine sui limiti.<\/p>\n

<\/p>\n

Tuchanka4 (molti schiavi)<\/h2>\n

<\/p>\n

Struttura<\/h3>\n

<\/p>\n

\"Modellazione<\/p>\n

<\/p>\n

\u00c8 gi\u00e0 un'altra estremit\u00e0. Ci sono DB che ricevono un numero molto elevato di richieste in sola lettura (un caso tipico di un sito ad alta capacit\u00e0). Tuchanka4 \u00e8 una situazione in cui possono esserci tre o pi\u00f9 schiavi per gestire tali richieste, ma comunque non troppi. Con un numero molto elevato di schiavi sar\u00e0 necessario inventare un sistema gerarchico di replica. Nel caso minimo (nella figura), in ciascuno dei due data center ci sono due server, ciascuno con un'istanza di PostgreSQL.<\/p>\n

<\/p>\n

Un'altra caratteristica di questo schema \u00e8 che qui si pu\u00f2 organizzare una replica sincrona. Essa \u00e8 configurata per replicare, se possibile, in un altro data center, piuttosto che su una replica nello stesso data center dove si trova il master. Sia il master che ogni schiavo hanno un IP float. A dire il vero, tra gli schiavi bisogna implementare un bilanciamento delle richieste con qualche sql proxy<\/em>, ad esempio, lato cliente. Diversi tipi di clienti possono avere bisogno di un diverso tipo sql proxy<\/em>, e solo gli sviluppatori dei client sanno chi ha bisogno di cosa. Questa funzionalit\u00e0 pu\u00f2 essere realizzata sia come demone esterno, sia come libreria client (connection pool), ecc. Tutto ci\u00f2 esula dall'argomento del cluster DB altamente disponibile (l'alta disponibilit\u00e0 SQL proxy<\/em> pu\u00f2 essere realizzata indipendentemente, insieme all'alta disponibilit\u00e0 del client).<\/p>\n

<\/p>\n

Guasto di Tuchanka4<\/h3>\n

<\/p>\n

\"Modellazione<\/p>\n

<\/p>\n

In caso di guasto di un data center (cio\u00e8 di due server), il testimone vota per il secondo. Di conseguenza, nel secondo data center operano due server: su uno c'\u00e8 il master, e su di esso punta l'IP float master (per ricevere richieste read-write); sull'altro server opera uno schiavo con replica sincrona, e su di esso punta uno degli IP float slave (per richieste in sola lettura).<\/p>\n

<\/p>\n

La prima cosa da notare \u00e8 che l'IP float slave non sar\u00e0 solo uno, ma solo uno. E per un funzionamento corretto con esso sar\u00e0 necessario che sql proxy<\/em> reindirizzava tutte le richieste all'unico float IP rimanente; e se sql proxy<\/em> no, \u00e8 possibile elencare tutti i float IP dei server slave separandoli con una virgola nell'URL di connessione. In questo caso con libpq<\/em> la connessione avverr\u00e0 al primo IP funzionante, come impostato nel sistema di test automatico. Potrebbe non funzionare in altre librerie, ad esempio JDBC, e sar\u00e0 necessario sql proxy<\/em>. Questo \u00e8 stato fatto perch\u00e9 per gli float IP dei server slave \u00e8 vietato essere attivi contemporaneamente su un singolo server, in modo che vengano distribuiti uniformemente tra i server slave, qualora ce ne siano pi\u00f9 di uno attivo.<\/p>\n

<\/p>\n

Secondo: anche in caso di guasto del data center verr\u00e0 mantenuta la replica sincrona. E anche se si verifica un guasto secondario, cio\u00e8 se uno dei due server nel data center rimanente si guasta, il cluster, pur smettendo di fornire servizi, manterr\u00e0 comunque le informazioni su tutte le transazioni confermate, per le quali ha dato conferma di commit (non ci sar\u00e0 perdita di informazioni in caso di guasto secondario).<\/p>\n

<\/p>\n

Tuchanka3 (3 data center)<\/h2>\n

<\/p>\n

Struttura<\/h3>\n

<\/p>\n

\"Modellazione<\/p>\n

<\/p>\n

Questo \u00e8 un cluster per situazioni in cui ci sono tre data center completamente operativi, ognuno dei quali ha un server DB completamente funzionante. In questo caso quorum device<\/em> non \u00e8 necessario. In un data center opera il master, negli altri due \u2014 gli slave. La replica \u00e8 sincrona, di tipo ANY (slave1, slave2), cio\u00e8 al cliente verr\u00e0 fornita una conferma di commit quando uno qualsiasi degli slave risponder\u00e0 per primo di aver accettato il commit. Le risorse sono indicate da un float IP per il master e due per gli slave. A differenza di Tuchanka4, tutti e tre gli float IP sono a prova di guasto. Per bilanciare le query SQL read-only \u00e8 possibile utilizzare sql proxy<\/em> (con resistenza individuale), oppure si pu\u00f2 assegnare un float IP slave a met\u00e0 dei clienti e un altro float IP slave all'altra met\u00e0.<\/p>\n

<\/p>\n

Guasto Tuchanka3<\/h3>\n

<\/p>\n

\"Modellazione<\/p>\n

<\/p>\n

In caso di guasto di uno dei data center, ne rimangono due. In uno \u00e8 attivo il master e il float IP del master, nell'altro \u2014 lo slave e entrambi i float IP slave (l'istanza deve avere una riserva di risorse doppia, per accettare tutte le connessioni da entrambi i float IP slave). Tra il master e lo slave c'\u00e8 replica sincrona. Inoltre, il cluster manterr\u00e0 le informazioni sulle transazioni confermate e registrate (non ci sar\u00e0 perdita di informazioni) in caso di distruzione di due data center (se non vengono distrutti contemporaneamente).<\/p>\n

<\/p>\n

Ho deciso di non inserire una descrizione dettagliata della struttura dei file e del deployment. Chi vuole sperimentare, pu\u00f2 leggere tutto questo nel README. Riporto solo la descrizione dei test automatici.<\/em><\/p>\n

<\/p>\n

Sistema di test automatici<\/h1>\n

<\/p>\n

Per verificare la resilienza dei cluster con simulazione di vari guasti, \u00e8 stato creato un sistema di test automatici. Viene avviato tramite script test\/failure<\/code>. Lo script pu\u00f2 accettare come parametri i numeri dei cluster che si desidera testare. Ad esempio, questo comando:<\/p>\n

<\/p>\n

test\/failure 2 3<\/code><\/pre>\n
<\/p>\n
tester\u00e0 solo il secondo e il terzo cluster. Se i parametri non sono specificati, verranno testati tutti i cluster. Tutti i cluster vengono testati parallelamente e il risultato viene visualizzato nel pannello tmux. Tmux utilizza un server tmux dedicato, quindi lo script pu\u00f2 essere eseguito da tmux predefinito, risultando in un tmux annidato. Consiglio di utilizzare un terminale in una finestra grande e con un carattere piccolo. Prima di iniziare i test, tutte le macchine virtuali vengono ripristinate a uno snapshot al momento del completamento dello script. setup<\/code>.<\/p>\n
<\/p>\n
\"Modellazione<\/p>\n
<\/p>\n
Il terminale \u00e8 diviso in colonne in base al numero di cluster in fase di test, di default (nello screenshot) ce ne sono quattro. Il contenuto delle colonne verr\u00e0 descritto con l'esempio di Tuchanka2. I pannelli nello screenshot sono numerati:<\/p>\n
<\/p>\n
    \n
  1. Qui viene visualizzata la statistica dei test. Colonne:\n