{"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 resistenti ai guasti basati su PostgreSQL e Pacemaker.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Introduzione<\/h1>\n

<\/p>\n

Non molto tempo fa mi \u00e8 stato chiesto di sviluppare un cluster ad alta disponibilit\u00e0 per PostgreSQL<\/a><\/noindex>, operante in diversi data center collegati tramite fibra ottica all'interno di una stessa citt\u00e0 e in grado di sostenere il guasto (ad esempio, l'interruzione di corrente) di un data center. Come software responsabile della resilienza, ho scelto Pacemaker<\/a><\/noindex>, poich\u00e9 \u00e8 la soluzione ufficiale di RedHat per la creazione di cluster ad alta disponibilit\u00e0. \u00c8 vantaggioso perch\u00e9 RedHat offre supporto per questa tecnologia e inoltre \u00e8 una soluzione versatile (modulare). Con essa \u00e8 possibile garantire l'alta disponibilit\u00e0 non solo per PostgreSQL, ma anche per altri servizi, sia utilizzando moduli standard che creandone di specifici per esigenze particolari.<\/p>\n

<\/p>\n

A questo proposito sorge una domanda ragionevole: quanto \u00e8 davvero affidabile un cluster resiliente? Per indagare, ho creato un banco di prova che simula vari guasti nei nodi del cluster, attende il ripristino della funzionalit\u00e0, recupera il nodo guasto e continua a testare in ciclo. Inizialmente, questo progetto si chiamava hapgsql, ma col tempo mi sono stancato di un nome con solo una vocale. Pertanto, le basi di dati resilienti (e gli IP float associati) li ho chiamati krogan<\/strong> (un personaggio di un videogioco, che ha tutti gli organi vitali duplicati), e i nodi, i cluster e il progetto stesso \u2014 tuchanka<\/strong> (il pianeta abitato dai krogan).<\/p>\n

<\/p>\n

Attualmente, la direzione ha autorizzato l'apertura del progetto alla comunit\u00e0 open source sotto la licenza MIT<\/a><\/noindex>. Il README sar\u00e0 tradotto in inglese a breve (poich\u00e9 ci si aspetta che i principali utilizzatori siano sviluppatori di Pacemaker e PostgreSQL), e la vecchia versione russa del README ho deciso di presentarla (parzialmente) in 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>. Saranno distribuite 12 macchine virtuali (per un totale di 36GiB), che formeranno 4 cluster ridondanti (varie opzioni). I primi due cluster consistono in due server PostgreSQL, situati in diversi data center, e un server condiviso testimone<\/em> c dispositivo di quorum<\/strong> (collocato su una macchina virtuale economica in un terzo data center), che risolve l'incertezza 50%\/50%<\/strong>, esprimendo il suo voto per una delle parti. Il terzo cluster si trova in tre data center: un master, due schiavi, senza dispositivo di quorum<\/strong>. Il quarto cluster \u00e8 composto da quattro server PostgreSQL, due per data center: uno master, le altre repliche, e utilizza anche testimone<\/em> c dispositivo di quorum<\/strong>. Il quarto resiste al guasto di due server o di un data center. Questa soluzione pu\u00f2, se necessario, essere scalata a un numero maggiore di repliche.<\/p>\n

<\/p>\n

Servizio di sincronizzazione dell'ora ntpd<\/a><\/noindex> \u00e8 stato anche riconfigurato per la ridondanza, ma utilizza il metodo di ntpd<\/code> (orphan mode<\/em>). Il server centrale testimone<\/em> funge da server NTP centrale, distribuendo il proprio tempo a tutti i cluster, sincronizzando cos\u00ec tutti i server tra loro. Se testimone<\/em> si guasta o viene isolato, uno dei server del cluster inizier\u00e0 a distribuire il proprio tempo (all'interno del cluster). Un cache ausiliario proxy HTTP<\/strong> \u00e8 anch'esso attivo su testimone<\/em>, tramite il quale le altre macchine virtuali hanno accesso ai repository Yum. In realt\u00e0, servizi come l'ora esatta e il proxy saranno sicuramente ospitati su server dedicati, mentre nel banco sono ospitati su testimone<\/em> solo per risparmiare sul 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 data center, uniti in una rete piatta e devono resistere al fallimento o all'isolamento di rete di un data center. Pertanto non \u00e8 possibile<\/strong> utilizzare per la protezione da split-brain<\/strong> la tecnologia standard Pacemaker, che si chiama STONITH<\/em> (Shoot The Other Node In The Head) o fencing<\/em>. La sua essenza: se i nodi nel cluster iniziano a sospettare che ci sia qualcosa di strano con un nodo, che non risponde o si comporta in modo anomalo, lo scollegano forzatamente tramite dispositivi \"esterni\", come la scheda di gestione IPMI o l'UPS. Tuttavia, questo funzioner\u00e0 solo nei casi in cui, in caso di guasto singolo del server, IPMI o UPS continuino a funzionare. Qui \u00e8 prevista una protezione da un guasto molto pi\u00f9 catastrofico, quando fallisce (ad esempio, si interrompe l'alimentazione) l'intero data center. E in caso di tale guasto, tutto stonith<\/em>-i dispositivi (IPMI, UPS, ecc.) non funzioneranno nemmeno.<\/p>\n

<\/p>\n

Invece, il sistema si basa sull'idea del quorum. Tutti i nodi hanno diritto di voto e possono lavorare solo quelli che vedono pi\u00f9 della met\u00e0 di tutti i nodi. Questa quantit\u00e0 \"met\u00e0+1\" \u00e8 chiamata quorum<\/strong>. Se il quorum non viene raggiunto, il nodo decide che si trova in isolamento di rete e deve disattivare le proprie risorse, cio\u00e8 \u00e8 una sorta di protezione da split-brain<\/strong>. Se il software che gestisce questo comportamento non funziona, si deve attivare un watchdog, ad esempio basato su IPMI.<\/p>\n

<\/p>\n

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

<\/p>\n

Le risorse possono spostarsi da un posto all'altro, ad esempio, da server guasti a server funzionanti, o su comando degli amministratori di sistema. Per informare i clienti su dove si trovano le risorse di cui hanno bisogno (a quale punto connettersi?), vengono utilizzati IP galleggianti<\/em> (float IP<\/strong>). Questi IP possono essere spostati da Pacemaker tra i nodi (tutto si trova in una rete piatta). Ognuno di essi rappresenta una risorsa (servizio) e sar\u00e0 posizionato dove \u00e8 necessario connettersi per accedere a questo servizio (nel nostro caso, al DB).<\/p>\n

<\/p>\n

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

<\/p>\n

Struttura<\/h3>\n

<\/p>\n

\"Modellazione<\/p>\n

<\/p>\n

L'idea era quella di avere molti piccoli database con un basso carico, per i quali non \u00e8 conveniente mantenere un server slave dedicato in modalit\u00e0 hot standby per transazioni in sola lettura (non c'\u00e8 bisogno di uno spreco di risorse del genere).<\/p>\n

<\/p>\n

In ogni data center c'\u00e8 un server. Ogni server ha due istanze di PostgreSQL (nella terminologia di PostgreSQL si chiamano claster, ma per evitare confusione le chiamer\u00f2 istanze, analogamente ad altre DB, e chiamer\u00f2 cluster solo i cluster Pacemaker). Un'istanza funziona in modalit\u00e0 master e solo essa fornisce servizi (solo su di essa \u00e8 presente un IP fluttuante). L'altra istanza funziona come slave per il secondo data center e fornir\u00e0 servizi solo se il suo master dovesse andare offline. Poich\u00e9 la maggior parte del tempo fornir\u00e0 servizi (eseguir\u00e0 query) solo un'istanza su due (il master), tutte le risorse del server vengono ottimizzate per il master (viene allocata memoria per il cache shared_buffers, ecc.), ma in modo tale da garantire risorse anche per la seconda istanza (anche se con prestazioni non ottimali tramite la cache del filesystem) nel caso in cui uno dei data center dovesse fallire. Lo slave non fornisce servizi (non esegue query di sola lettura) durante il normale funzionamento del cluster, per evitare di competere per le risorse con il master sulla stessa macchina.<\/p>\n

<\/p>\n

Nel caso di due nodi, l'affidabilit\u00e0 \u00e8 possibile solo con la replicazione asincrona, in quanto con la replicazione sincronizzata il guasto dello slave porter\u00e0 alla fermata del master.<\/p>\n

<\/p>\n

Guasto witness<\/h3>\n

<\/p>\n

\"Modellazione<\/p>\n

<\/p>\n

Guasto witness (dispositivo di quorum<\/em>) lo considero solo per il cluster Tuchanka1, per tutti gli altri sar\u00e0 la stessa storia. In caso di guasto del witness nella struttura del cluster, nulla cambier\u00e0, tutto continuer\u00e0 a funzionare come prima. Tuttavia, il quorum diventer\u00e0 2 su 3, e quindi qualsiasi successivo guasto diventer\u00e0 fatale per il cluster. Sar\u00e0 comunque necessario ripararlo rapidamente.<\/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 testimone<\/em> vota per il secondo nodo nel secondo data center. Qui l'ex slave si trasforma in master, quindi entrambi i master funzionano su un server e entrambi puntano al 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 composto da due nodi. Uno ospita il master, l'altro lo slave. Entrambi possono gestire le richieste (lo slave \u00e8 solo read only), quindi entrambi puntano al float IP: krogan2 \u2014 per il master, krogan2s1 \u2014 per lo slave. L'affidabilit\u00e0 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 replicazione asincrona, poich\u00e9 con la replicazione sincrona un guasto del server secondario 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 testimone<\/em> voterebbe per il secondo. Nel data center attivo verr\u00e0 avviato il master, e entrambi gli IP float: quello master e quello secondario, punteranno su di esso. Naturalmente, l'istanza deve essere configurata in modo tale da avere risorse sufficienti (limiti di connessione, ecc.) per accettare simultaneamente tutte le connessioni e le richieste dagli IP float master e secondario. Cio\u00e8, in condizioni normali, deve avere un margine sufficiente sui limiti.<\/p>\n

<\/p>\n

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

<\/p>\n

Struttura<\/h3>\n

<\/p>\n

\"Modellazione<\/p>\n

<\/p>\n

Gi\u00e0 un'altra estremit\u00e0. Ci sono database che ricevono molte richieste in sola lettura (caso tipico di un sito ad alto carico). Tuchanka4 \u00e8 la situazione in cui possono esserci tre o pi\u00f9 secondari per gestire tali richieste, ma comunque non troppi. Con un numero eccessivo di secondari, sar\u00e0 necessaria l'ideazione di un sistema gerarchico di replicazione. Nel caso minimo (nell'immagine) ci sono due server in ciascuno dei due data center, ognuno con un'istanza di PostgreSQL.<\/p>\n

<\/p>\n

Un'altra caratteristica di questo schema \u00e8 che qui \u00e8 possibile organizzare una replica sincrona. \u00c8 configurata per replicare, se possibile, in un altro data center, e non su una replica nello stesso data center del master. Il master e ogni slave sono indicati da un IP float. Idealmente, tra gli slave si dovrebbe effettuare il bilanciamento delle richieste tramite qualche sql proxy<\/em>, per esempio, sul lato client. A diversi tipi di client potrebbe servire un tipo diverso sql proxy<\/em>, e solo gli sviluppatori dei client sanno quale sia necessario per ognuno. Questa funzionalit\u00e0 pu\u00f2 essere implementata sia come demone esterno, sia come libreria client (connection pool), ecc. Tutto ci\u00f2 esula dal tema del cluster DB ad alta disponibilit\u00e0 (l'alta disponibilit\u00e0 SQL proxy<\/em> pu\u00f2 essere implementata indipendentemente, insieme all'alta disponibilit\u00e0 del client).<\/p>\n

<\/p>\n

Guasto Tuchanka4<\/h3>\n

<\/p>\n

\"Modellazione<\/p>\n

<\/p>\n

In caso di malfunzionamento di un data center (ovvero di due server), il witness vota per il secondo. Di conseguenza, in quest'ultimo data center operano due server: su uno si trova il master, al quale corrisponde un float IP master (per ricevere richieste read-write); mentre sull'altro server opera uno slave con replica sincrona, al quale corrisponde uno dei float IP slave (per richieste read only).<\/p>\n

<\/p>\n

La prima cosa da notare \u00e8 che il float IP slave attivo non sar\u00e0 tutti, ma solo uno. E per funzionare correttamente, \u00e8 necessario che sql proxy<\/em> reindirizzi tutte le richieste all'unico float IP rimanente; e se sql proxy<\/em> no, \u00e8 possibile elencare tutti i float IP degli slave separati da una virgola nell'URL per la connessione. In tal caso, con libpq<\/em> la connessione avverr\u00e0 al primo IP operativo, come previsto nel sistema di test automatici. Potrebbe non funzionare allo stesso modo in altre librerie, ad esempio JDBC, e potrebbe essere necessario sql proxy<\/em>. Questo perch\u00e9 per i float IP degli slave \u00e8 vietato attivarsi contemporaneamente su un server, affinch\u00e9 siano distribuiti uniformemente tra i server slave, se ce ne sono diversi attivi.<\/p>\n

<\/p>\n

In secondo luogo: anche in caso di guasto del data center, la replica sincrona sar\u00e0 mantenuta. E anche se si verifica un guasto secondario, ovvero uno dei due server nel data center rimanente si guasta, il cluster smetter\u00e0 di fornire servizi, ma manterr\u00e0 comunque informazioni su tutte le transazioni impegnate per le quali ha fornito 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 la situazione in cui ci sono tre data center completamente operativi, ciascuno con un server di database completamente funzionante. In questo caso dispositivo di quorum<\/em> non \u00e8 necessario. In un data center opera il master, mentre negli altri due ci sono i server slave. La replica \u00e8 sincrona, tipo ANY (slave1, slave2), il che significa che il cliente ricever\u00e0 conferma del commit quando uno degli slave risponder\u00e0 per primo di aver accettato il commit. Le risorse indicano un IP float per il master e due per gli slave. A differenza di Tuchanka4, tutti e tre gli IP float sono a prova di guasto. Per bilanciare le richieste SQL in sola lettura \u00e8 possibile utilizzare sql proxy<\/em> (con affidabilit\u00e0 separata), oppure si pu\u00f2 assegnare un IP float a un gruppo di clienti e un altro a un secondo gruppo.<\/p>\n

<\/p>\n

Guasto Tuchanka3<\/h3>\n

<\/p>\n

\"Modellazione<\/p>\n

<\/p>\n

Se uno dei data center dovesse crollare, ne rimarrebbero due. In uno \u00e8 attivato il master e l'IP flottante dal master, nell'altro \u2014 lo slave e entrambi gli IP flottanti slave (l'istanza deve avere una riserva doppia di risorse per accettare tutte le connessioni da entrambi gli IP flottanti slave). Tra master e slave c'\u00e8 una replica sincrona. Inoltre, il cluster manterr\u00e0 le informazioni sulle transazioni impegnate e confermate (non ci sar\u00e0 perdita di informazioni) in caso di distruzione di due data center (se distrutti non contemporaneamente).<\/p>\n

<\/p>\n

Ho deciso di non includere una descrizione dettagliata della struttura dei file e del deployment. Chi desidera sperimentare pu\u00f2 leggere tutto nel README. Fornisco solo la descrizione del test automatico.<\/em><\/p>\n

<\/p>\n

Sistema di test automatico<\/h1>\n

<\/p>\n

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

<\/p>\n

test\/failure 2 3<\/code><\/pre>\n
<\/p>\n
verr\u00e0 testato solo il secondo e il terzo cluster. Se i parametri non sono specificati, verranno testati tutti i cluster. Tutti i cluster vengono testati in parallelo e il risultato viene visualizzato nel pannello tmux. Tmux utilizza un server tmux dedicato, quindi lo script pu\u00f2 essere eseguito all'interno del tmux predefinito, creando un tmux annidato. Consiglio di utilizzare il terminale in una finestra grande e con un carattere piccolo. Prima dell'inizio dei 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 suddiviso in colonne in base al numero di cluster testati, di default (nello screenshot) sono quattro. Contenuto delle colonne che descriver\u00f2 usando l'esempio Tuchanka2. I pannelli nello screenshot sono numerati:<\/p>\n
<\/p>\n
    \n
  1. Qui viene visualizzata la statistica dei test. Colonne:\n