Introduzione

Qualchì tempu fà mi era datu u compitu di sviluppà un cluster di failover per PostgreSQL, chì operanu in parechji centri di dati cunnessi da fibra ottica in una cità, è capaci di sustene un fallimentu (per esempiu, blackout) di un centru di dati. Cum'è u software chì hè rispunsevule per a tolleranza di difetti, aghju sceltu Pacemakerperchè questa hè a suluzione ufficiale da RedHat per creà clusters di failover. Hè bonu perchè RedHat furnisce supportu per questu, è perchè sta suluzione hè universale (modulare). Cù u so aiutu, serà pussibule di assicurà a tolleranza di difetti micca solu di PostgreSQL, ma ancu di altri servizii, sia utilizendu moduli standard sia creendu per bisogni specifichi.

Sta decisione hà suscitatu una quistione ragiunate: quantu sarà tollerante à i difetti un cluster di failover? Per investigà questu, aghju sviluppatu un bancu di teste chì simula diversi fallimenti nantu à i nodi di cluster, aspetta chì u serviziu sia restauratu, ricuperà u node fallutu, è cuntinueghja a prova in un ciclu. Stu prughjettu era urigginariamente chjamatu hapgsql, ma cù u tempu aghju stancu di u nome, chì avia solu una vucali. Dunque, aghju cuminciatu à chjamà basa di dati toleranti à i difetti (è float IP indicà à elli) krogan (un caratteru di un ghjocu di computer in quale tutti l'organi impurtanti sò duplicati), è i nodi, i clusters è u prughjettu stessu sò tuchanka (u pianeta induve campanu i krogans).

Avà a gestione hà permessu apre u prugettu à a cumunità open source sottu a licenza MIT. U README sarà prestu traduttu in inglese (perchè hè previstu chì i principali cunsumatori seranu sviluppatori Pacemaker è PostgreSQL), è aghju decisu di prisentà a vechja versione russa di u README (parzialmente) in a forma di stu articulu.

I clusters sò implementati nantu à e macchine virtuali VirtualBox. Un totale di 12 macchine virtuali (36GiB in totale) seranu implementate, chì formanu 4 clusters tolleranti à i difetti (opzioni diverse). I primi dui clusters sò custituiti da dui servitori PostgreSQL, chì si trovanu in diversi centri di dati, è un servitore cumuni tistimone c dispusitivu di quorum (ospitu nantu à una macchina virtuale economica in un terzu centru di dati), chì risolve l'incertezza 50% / 50%, dendu u vostru votu à unu di i partiti. Terzu cluster in trè centri di dati: un maestru, dui schiavi, no dispusitivu di quorum. U quartu cluster hè custituitu da quattru servitori PostgreSQL, dui per centru di dati: un maestru, u restu repliche, è ancu usa. tistimone c dispusitivu di quorum. U quartu pò sustene u fallimentu di dui servitori o un centru di dati. Sta suluzione pò esse scalata à un nùmeru più grande di repliche se ne necessariu.

U serviziu di tempu precisu ntpd reconfiguratu ancu per a tolleranza di difetti, ma usa u metudu stessu ntpd (modu orfanu). Servitore spartutu tistimone agisce cum'è un servitore NTP centrale, distribuzendu u so tempu à tutti i clusters, sincronizendu cusì tutti i servitori cù l'altri. Se tistimone fiasca o diventa isolatu, allora unu di i servitori di cluster (in u cluster) cumencia à distribuisce u so tempu. Caching ausiliari Proxy HTTP alzatu ancu à tistimone, cù u so aiutu, altre macchine virtuali anu accessu à i repositori Yum. In realtà, i servizii cum'è u tempu precisu è i proxy seranu più prubabilmente ospitati in servitori dedicati, ma in a cabina sò ospitu. tistimone solu per salvà u numeru di macchine virtuale è spaziu.

Versioni

v0. Funziona cù CentOS 7 è PostgreSQL 11 nantu à VirtualBox 6.1.

Struttura di cluster

Tutti i clusters sò pensati per esse situati in parechji centri di dati, cumminati in una rete piatta è deve resiste à fallimentu o isolamentu di a rete di un unicu centru di dati. Hè perchè hè impussibule aduprà per prutezzione contru split-brain tecnulugia Pacemaker standard chjamatu STONITH (Spara l'altru Node in a testa) o scherma. A so essenza: se i nodi in u cluster cumincianu à sospettà chì qualcosa hè sbagliatu cù qualchì nodu, ùn hè micca rispundenu o si cumportanu in modu incorrectu, allora a forza di spegnellu per via di i dispositi "esterni", per esempiu, una carta di cuntrollu IPMI o UPS. . Ma questu funziona solu in i casi induve, in casu di un fallimentu unicu, u servitore IPMI o UPS cuntinueghja à travaglià. Quì avemu pensa à prutege contru à un fallimentu assai più catastròficu, quandu tuttu u centru di dati fiasca (per esempiu, perde u putere). È cun un tali rifiutu, tuttu petra-dispositivi (IPMI, UPS, etc.) ùn hà ancu travaglià.

Invece, u sistema hè basatu annantu à l'idea di quorum. Tutti i nodi anu una voce, è solu quelli chì ponu vede più di a mità di tutti i nodi ponu travaglià. Questa quantità di "metà + 1" hè chjamata quorum. Se u quorum ùn hè micca righjuntu, u node decide chì hè in isolamentu di a rete è deve disattivà e so risorse, i.e. questu hè ciò chì hè prutezzione split-brain. Se u software chì hè rispunsevuli di stu cumpurtamentu ùn viaghja micca, allora un watchdog, per esempiu, basatu in IPMI, hà da travaglià.

Se u numeru di nodi hè ancu (un cluster in dui centri di dati), allora a chjamata incertezza pò esse. 50% / 50% (cinquanta-cinquanta) quandu l'isolamentu di a rete divide u cluster esattamente in a mità. Dunque, per un numeru pari di nodi, aghjunghjemu dispusitivu di quorum hè un daemon pocu esigente chì pò esse lanciatu nantu à a macchina virtuale più economica in un terzu centru di dati. Dà u so votu à unu di i segmenti (chì ellu vede), è cusì risolve l'incertezza 50% / 50%. Aghju chjamatu u servitore nantu à quale u dispusitivu di quorum serà lanciatu tistimone (terminulugia da repmgr, mi piacia).

E risorse ponu esse spustate da un locu à un locu, per esempiu, da i servitori difetti à quelli sani, o à u cumandimu di l'amministratori di u sistema. Allora chì i clienti sanu induve si trovanu e risorse chì anu bisognu (induve cunnetta?), IP flottante (float IP). Quessi sò IP chì Pacemaker pò spustà intornu à i nodi (tuttu hè nantu à una reta piatta). Ognunu di elli simbulizeghja una risorsa (serviziu) è serà situatu induve avete bisognu di cunnette per avè accessu à stu serviziu (in u nostru casu, una basa di dati).

Tuchanka1 (circuit cun compattazione)

strutura

L'idea era chì avemu parechje basa di dati chjuche cù una carica bassa, per quale ùn hè micca prufittu di mantene un servitore slave dedicatu in modu di standby caldu per transazzioni di lettura solu (ùn ci hè bisognu di tali perdi di risorse).

Ogni centru di dati hà un servitore. Ogni servitore hà duie istanze PostgreSQL (in a terminologia PostgreSQL sò chjamati clusters, ma per evità cunfusioni li chjameraghju istanze (per analogia cù altre basa di dati), è chjameraghju solu clusters Pacemaker clusters). Una istanza opera in modu maestru, è solu furnisce servizii (solu IP float porta à questu). A seconda istanza travaglia cum'è schiavu per u sicondu centru di dati, è furnisce servizii solu se u so maestru falla. Siccomu a maiò parte di u tempu solu una istanza di dui (u maestru) furnisce servizii (eseguite dumande), tutte e risorse di u servitore sò ottimizzati per u maestru (a memoria hè attribuita per a cache shared_buffers, etc.), ma cusì chì a seconda istanza. hà ancu abbastanza risorse (anche per u funziunamentu suboptimal attraversu a cache di u sistema di fugliale) in casu di fallimentu di unu di i centri di dati. U slave ùn furnisce micca servizii (ùn eseguisce micca e dumande solu di lettura) durante u funziunamentu normale di u cluster, perchè ùn ci hè micca guerra per risorse cù u maestru nantu à a stessa macchina.

In u casu di dui nodi, a tolleranza di difetti hè pussibule solu cù a replicazione asincrona, postu chì cù a replicazione sincrona, u fallimentu di un slave porta à a stoppa di u maestru.

A mancanza di tistimunianza

fallimentu di tistimunianza (dispusitivu di quorum) Cunsidereraghju solu per u cluster Tuchanka1, cù tutti l'altri serà a stessa storia. Se u tistimone falla, nunda ùn cambierà in a struttura di cluster, tuttu hà da cuntinuà à travaglià a listessa manera. Ma u quorum diventerà 2 fora di 3, è dunque ogni fallimentu sussegwente serà fatale per u cluster. Avarà ancu esse fissatu urgentemente.

Tuchanka1 rifiutu

Fiascu di unu di i centri di dati per Tuchanka1. In stu casu tistimone dà u so votu à un secondu node in un secondu centru di dati. Là, l'anzianu schiavu si trasforma in un maestru, per quessa, i dui maestri travaglianu nantu à u stessu servitore è e so IP float puntanu à elli.

Tuchanka 2 (classica)

strutura

Schema classicu di dui nodi. U maestru travaglia nantu à unu, u schiavu nantu à u sicondu. Tutti dui ponu eseguisce richieste (u schiavu hè lettu solu), cusì i dui sò indicati da IP float: krogan2 hè u maestru, krogan2s1 hè u schiavu. Sia u maestru è u slave seranu tolleranza à i difetti.

In u casu di dui nodi, a tolleranza di difetti hè pussibule solu cù a replicazione asincrona, perchè cù a replicazione sincrona, u fallimentu di u slave portarà à u stop di u maestru.

Tuchanka2 rifiutu

Se unu di i centri di dati falla tistimone voti per u sicondu. Nantu à l'unicu centru di dati di travagliu, u maestru serà risuscitatu, è i dui IP float puntanu à questu: u maestru è u slave. Di sicuru, l'istanza deve esse cunfigurata in modu chì hà abbastanza risorse (limiti di cunnessione, etc.) per accettà simultaneamente tutte e cunnessione è e dumande da u IP float maestru è slave. Vale à dì, durante u funziunamentu normale, deve avè un fornimentu suffirenziu di limiti.

Tuchanka4 (assai schiavi)

strutura

Dighjà un altru estremu. Ci sò basa di dati chì ricevenu assai richieste di sola lettura (un casu tipicu di un situ d'alta carica). Tuchanka4 hè una situazione induve pò esse trè o più schiavi per trattà tali dumande, ma ancu micca troppu. Cù un gran numaru di schiavi, serà necessariu inventà un sistema di replicazione gerarchicu. In u casu minimu (in a stampa), ognunu di i dui centri di dati hà dui servitori, ognunu cù una istanza PostgreSQL.

Una altra caratteristica di stu schema hè chì hè digià pussibule urganizà una replicazione sincrona. Hè cunfiguratu per riplicà, se pussibule, à un altru centru di dati, invece di una replica in u stessu centru di dati cum'è u maestru. U maestru è ogni slave sò indicati da un IP float. Fortunatamente, trà i schiavi serà necessariu di equilibrà e dumande in qualchì manera sql proxy, per esempiu, da u cliente. Diversi tipi di clienti ponu esse bisognu di diversi tipi sql proxy, è solu i sviluppatori di u cliente sapanu quale hà bisognu. Sta funziunalità pò esse implementata sia da un daemon esternu sia da una biblioteca di client (piscina di cunnessione), etc. Tuttu chistu va oltre u tema di un cluster di basa di dati di failover (failover proxy SQL pò esse implementatu indipindente, inseme cù a tolleranza di u cliente).

Tuchanka4 rifiutu

Se un centru di dati (vale à dì, dui servitori) falla, tistimunianza vota per u sicondu. In u risultatu, dui servitori sò in esecuzione in u sicondu centru di dati: unu hè in esecuzione di un maestru, è l'IP float master punta à questu (per riceve richieste di lettura-scrittura); è nantu à u sicondu servitore ci hè un slave chì funziona cù replicazione sincrona, è unu di i slave float IPs punta à questu (per richieste di sola lettura).

A prima cosa da nutà hè chì micca tutti i slave float IPs seranu travagliadori, ma solu unu. È per travaglià cun ellu currettamente serà necessariu chì sql proxy reindirizzatu tutte e dumande à l'unicu IP float restante; è si sql proxy no, allora pudete listà tutti i slaves IP float separati da virgule in l'URL di cunnessione. In stu casu, cù libpq a cunnessione serà à u primu IP di travagliu, questu hè fattu in u sistema di teste automaticu. Forsi in altre biblioteche, per esempiu, JDBC, questu ùn hà micca travagliatu è hè necessariu sql proxy. Questu hè fattu perchè l'IP float per i schiavi sò pruibiti da esse elevati simultaneamente nantu à un servitore, in modu chì sò distribuiti uniformemente trà i servitori schiavi s'ellu ci sò parechji di elli in esecuzione.

Siconda: ancu in casu di fallimentu di u centru di dati, a replicazione sincrona serà mantenuta. E ancu s'ellu si trova un fallimentu secundariu, vale à dì, unu di i dui servitori in u centru di dati restante fallenu, u cluster, ancu s'ellu smetterà di furnisce servizii, mantene sempre l'infurmazioni nantu à tutte e transazzione impegnate per quale hà datu cunferma di l'impegnu. (Ùn ci sarà micca infurmazione di perdita in casu di fallimentu secundariu).

Tuchanka3 (3 centri di dati)

strutura

Questu hè un cluster per una situazione induve ci sò trè centri di dati cumpletamente funziunanti, ognunu di i quali hà un servitore di basa di dati cumpletamente funziunanti. In stu casu dispusitivu di quorum micca necessariu. Un centru di dati hè persunalizatu da un maestru, l'altri dui sò stati persunalizatu da schiavi. A replicazione hè sincrona, scrivite ANY (slave1, slave2), vale à dì, u cliente riceverà una cunferma di cummissione quandu qualcunu di i schiavi hè u primu à risponde chì hà accettatu l'impegnu. I risorse sò indicati da un IP float per u maestru è dui per i schiavi. A cuntrariu di Tuchanka4, tutti i trè IP float sò fault-tolerant. Per equilibrà e dumande SQL di sola lettura pudete aduprà sql proxy (cù una toleranza di difetti separata), o assignate un IP float slave à a mità di i clienti, è l'altra mità à a seconda.

Tuchanka3 rifiutu

Se unu di i centri di dati falla, dui restanu. In una, u maestru è u float IP da u maestru sò suscitati, in u sicondu - u slave è i dui slave float IPs (l'istanza deve avè una doppia riserva di risorse per accettà tutte e cunnessione da i dui slave float IPs). Replicazione sincrona trà maestri è schiavi. Inoltre, u cluster salvarà l'infurmazioni nantu à e transazzioni impegnati è cunfirmati (ùn serà micca perdita di infurmazione) in casu di a distruzzione di dui centri di dati (se ùn sò micca distrutti simultaneamente).

Aghju decisu di ùn include micca una descrizzione dettagliata di a struttura di u schedariu è a distribuzione. Qualchissia chì vole ghjucà intornu pò leghje tuttu in u README. Sò solu furnisce una descrizzione di e teste automatizate.

Sistema di teste automaticu

Per pruvà a tolleranza à i difetti di clusters simulando diversi difetti, hè statu creatu un sistema di teste automaticu. Lanciatu da script test/failure. U script pò piglià cum'è paràmetri i numeri di clusters chì vulete pruvà. Per esempiu stu cumandamentu:

test/failure 2 3

pruverà solu u sicondu è u terzu cluster. Se i paràmetri ùn sò micca specificati, allora tutti i clusters seranu pruvati. Tutti i clusters sò pruvati in parallelu, è u risultatu hè visualizatu in u pannellu tmux. Tmux usa un servitore tmux dedicatu, cusì u script pò esse eseguitu da u tmux predeterminatu, risultatu in un tmux nidificatu. Aghju ricumandemu di utilizà u terminal in una finestra grande è cù un fonti chjucu. Prima di principià a prova, tutte e macchine virtuali sò ritruvate in una foto à u mumentu chì u script hè cumpletu. setup.

U terminal hè divisu in culonne secondu u numeru di clusters chì sò pruvati; per difettu (in a screenshot) ci sò quattru. Descriveraghju u cuntenutu di e culonne cù l'esempiu di Tuchanka2. I pannelli in a screenshot sò numerati:

1. E statistiche di prova sò mostrate quì. Culonni:
   • fallimentu - u nome di a prova (funzione in u script) chì emula u difettu.
   • riazzioni - tempu mediu aritmeticu in seconde durante u quale u cluster hà recuperatu a so funziunalità. Hè misurata da u principiu di u script emulendu un difettu finu à u mumentu chì u cluster restaurà a so funziunalità è hè capaci di cuntinuà à furnisce servizii. Se u tempu hè assai cortu, per esempiu, sei seconde (questu succede in clusters cù parechji schiavi (Tuchanka3 è Tuchanka4)), questu significa chì u difettu era nantu à u slave asincronu è ùn hà micca affettatu u rendiment in ogni modu; ùn ci era micca. switch di u statu di cluster.
   • deviazione - mostra a diffusione (accurata) di u valore riazzioni usendu u metudu di deviazione standard.
   • contani - quante volte hè stata fatta sta prova.
2. Un brevi logu permette di valutà ciò chì u cluster hè attualmente fattu. U numeru di iterazione (test), timestamp è nome di l'operazione sò visualizati. A corsa troppu longa (> 5 minuti) indica un prublema.
3. lu cori (coore) - ora attuale. Per a valutazione visuale di u rendiment maestru L'ora attuale hè constantemente scritta à a so tavula cù u float IP master. Se successu, u risultatu hè visualizatu in stu pannellu.
4. Susanu (impulsu) - "ora attuale", chì era prima arregistrata da u script lu cori à maestru, avà leghje da schiavu via u so float IP. Permette di valutà visualmente u rendiment di u schiavu è a replicazione. In Tuchanka1 ùn ci sò micca schiavi cù IP float (senza schiavi chì furnisce servizii), ma ci sò dui casi (DB), perchè ùn serà micca mostratu quì. Susanue lu cori seconda istanza.
5. Monitorà a salute di u cluster usendu l'utilità pcs mon. Mostra a struttura, a distribuzione di risorse in i nodi è altre informazioni utili.
6. U monitoraghju di u sistema da ogni macchina virtuale in u cluster hè mostratu quì. Ci ponu esse più tali pannelli sicondu quante macchine virtuale hà u cluster. Dui grafici Carica CPU (e macchine virtuali anu dui processori), nome di a macchina virtuale, Caricamentu di u Sistema (chjamatu Load Average perchè hè una media di più di 5, 10 è 15 minuti), processà i dati è l'allocazione di memoria.
7. Trace di u script chì esegue a prova. In casu di un malfunzionamentu - una interruzzione brusca di u funziunamentu o un ciclu d'attesa interminabile - quì pudete vede u mutivu di stu cumpurtamentu.

A prova hè fatta in dui fasi. Prima, u script passa per tutti i tipi di teste, selezziunendu aleatoriamente una macchina virtuale à quale applicà sta prova. Allora un ciculu infinitu di teste hè realizatu, e macchine virtuali è u difettu sò scelti in modu aleatoriu ogni volta. A terminazione brusca di u script di prova (pannellu di fondu) o un ciclu infinitu di aspittà per qualcosa (> 5 minuti di tempu d'esekzione per una operazione, questu pò esse vistu in a traccia) indica chì alcune di e teste nantu à stu cluster anu fallutu.

Ogni prova hè custituita da e seguenti operazioni:

1. Lanciate una funzione chì emula un difettu.
2. Animu? - aspittendu chì u cluster sia restauratu (quandu tutti i servizii sò furniti).
3. Mostra u timeout di ricuperazione di u cluster (riazzioni).
4. Fix - u cluster hè "riparatu". Dopu quì, deve vultà à un statu cumplettamente operativu è esse prontu per u prossimu malfunzionamentu.

Eccu una lista di teste cù una descrizzione di ciò chì facenu:

• ForkBomb: Crea "Fora di memoria" cù una bomba di furchetta.
• OutOfSpace: U discu duru hè pienu. Ma a prova hè piuttostu simbolica; cù a carica insignificante chì hè creata durante a prova, PostgreSQL di solitu ùn falla micca quandu u discu duru hè pienu.
• Postgres-KILL: uccide PostgreSQL cù u cumandimu killall -KILL postgres.
• Postgres-STOP: suspende u cumandamentu PostgreSQL killall -STOP postgres.
• Power Off: "de-energizes" a macchina virtuale cù u cumandimu VBoxManage controlvm "виртуалка" poweroff.
• resetten: overloads the virtual machine with the command VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: suspende u dimòniu SBD cù u cumandamentu killall -STOP sbd.
• Chjodi: manda un cumandamentu à a macchina virtuale via SSH systemctl poweroff, u sistema si chjude grazia.
• UnLink: isolamentu di a rete, cumandamentu VBoxManage controlvm "виртуалка" setlinkstate1 off.

Cumpiendu a prova sia cù u cumandimu standard tmux "kill-window" Ctrl-b &, o u cumandimu "detach-client". Ctrl-b d: à questu puntu a prova finisce, tmux si chjude, e macchine virtuali sò spenti.

Prublemi identificati durante a prova

• A stu mumentu watchdog demon sbd travaglia per fermà i demoni osservati, ma micca per congelarli. È, in u risultatu, i difetti chì portanu à a congelazione solu Corosync и Pacemaker, ma micca suspesu sbd. Per verificà Corosync dighjà PR #83 (nantu à GitHub à sbd), accettatu à u filu Maestru. Anu prumessu (in PR # 83) chì ci saria qualcosa simili per Pacemaker, spergu chì da Cappelli Rossi 8 farà. Ma tali "malfunctions" sò speculative è ponu esse facilmente simulate artificialmente usendu, per esempiu, killall -STOP corosync, ma mai scuntrà in a vita vera.

• У Pacemaker in a versione per CentOS 7 impostatu in modu incorrectu sync_timeout у dispusitivu di quorum, di cunsiguenza se un node hà fiascatu, cù una certa probabilità chì u sicondu node hà ancu riavviatu, à quale u maestru duvia passà. Curatu da l'allargamentu sync_timeout у dispusitivu di quorum durante l'implementazione (in script setup/setup1). Questa mudificazione ùn hè micca accettata da i sviluppatori Pacemaker, invece anu prumessu di redesignà l'infrastruttura in tale manera (in un futuru micca specificatu) chì stu timeout serà calculatu automaticamente.

• Se a cunfigurazione di a basa di dati specifica chì LC_MESSAGES (messages di testu) Unicode pò esse usatu, p.e. ru_RU.UTF-8, dopu à l'iniziu postgres in un ambiente induve u locale ùn hè micca UTF-8, dì in un ambiente viotu (qui Pacemaker+pgsqlms(paf) corre postgres), allora u logu cuntene punti interrogativi invece di lettere UTF-8. I sviluppatori di PostgreSQL ùn anu micca accunsentutu nantu à ciò chì fà in questu casu. Custa, avete bisognu di stallà LC_MESSAGES=en_US.UTF-8 quandu cunfigurà (creà) una istanza di basa di dati.

• Se wal_receiver_timeout hè stabilitu (per default hè 60s), allora durante a prova PostgreSQL-STOP nantu à u maestru in i clusters tuchanka3 è tuchanka4 a replicazione ùn cunnetta micca à u novu maestru. A replicazione hè sincrona, perchè micca solu u schiavu si ferma, ma ancu u novu maestru. Funciona intornu à wal_receiver_timeout = 0 quandu cunfigurà PostgreSQL.

• In ocasu aghju osservatu i congelamenti di replicazione in PostgreSQL in a prova ForkBomb (overflow di memoria). Dopu à ForkBomb, à volte i schiavi ùn ponu micca ricunniscenu à u novu maestru. Aghju scontru solu questu in i clusters tuchanka3 è tuchanka4, induve u maestru si congelava per a replicazione sincrona. U prublema si n'andò da sè stessu dopu à un bellu pezzu (circa duie ore). Hè necessariu più ricerca per correggerà questu. I sintomi sò simili à l'errore precedente, chì hè causatu da un mutivu diversu, ma cù i stessi cunsiquenzi.

Foto di Krogan presa da Art Deviant cù l'autorizazione di l'autore:

Source: www.habr.com