Uvod

Prije nekog vremena, dobio sam zadatak da razvijem klaster za uklanjanje greške PostgreSQL, koji rade u nekoliko centara podataka povezanih vlaknima unutar istog grada i mogu izdržati kvar (na primjer, zamračenje) jednog podatkovnog centra. Kao softver koji je odgovoran za toleranciju grešaka, izabrao sam pejsmejker, jer je ovo službeno rješenje RedHat-a za kreiranje klastera za preklapanje greške. Dobro je jer RedHat pruža podršku za njega i jer je ovo rješenje univerzalno (modularno). Uz njegovu pomoć biće moguće obezbediti toleranciju grešaka ne samo za PostgreSQL, već i za druge servise, bilo korišćenjem standardnih modula ili kreiranjem za specifične potrebe.

Na ovu odluku, postavilo se razumno pitanje: koliko će klaster za napuštanje greške biti otporan na greške? Da bih to istražio, razvio sam testni stol koji simulira različite kvarove na čvorovima klastera, čeka oporavak, vraća neuspjeli čvor i nastavlja testiranje u petlji. U početku se ovaj projekat zvao hapgsql, ali mi je vremenom dosadio naziv koji ima samo jedan samoglasnik. Stoga sam počeo da imenujem baze podataka otporne na greške (i plutajuće IP adrese koje upućuju na njih) krogan (lik iz kompjuterske igrice, u kojoj su svi važni organi duplicirani), a čvorovi, klasteri i sam projekat su tuchanka (planeta na kojoj žive krogani).

Uprava je sada odobrila otvorite projekat zajednici otvorenog koda pod MIT licencom. README će uskoro biti preveden na engleski (jer se očekuje da će programeri Pejsmejkera i PostgreSQL-a biti glavni potrošači), a ja sam odlučio da izdam staru rusku verziju README-a (delimično) u obliku ovog članka.

Klasteri se postavljaju na virtuelne mašine VirtualBox. Ukupno 12 virtuelnih mašina (36GiB ukupno) će biti raspoređeno, koje formiraju 4 klastera otporna na greške (različite opcije). Prva dva klastera sastoje se od dva PostgreSQL servera, koji se nalaze u različitim data centrima, i zajedničkog servera svjedok c kvorum uređaj (hostovan na jeftinoj virtuelnoj mašini u trećem data centru), što rešava neizvesnost 50% / 50%, dajući svoj glas jednoj od stranaka. Treći klaster u tri data centra: jedan master, dva slave, br kvorum uređaj. Četvrti klaster se sastoji od četiri PostgreSQL servera, dva po data centru: jedan master, ostali su replike, a takođe koristi svjedok c kvorum uređaj. Četvrti preživi kvar dva servera ili jednog data centra. Ovo rješenje se može povećati na više replika ako je potrebno.

Vremenska služba ntpd također rekonfiguriran za toleranciju grešaka, ali koristi metodu ntpd (orphan mode). Zajednički server svjedok djeluje kao centralni NTP server, raspodjeljujući svoje vrijeme svim klasterima, čime se svi serveri međusobno sinhronizuju. Ako svjedok ne uspije ili se ispostavi da je izoliran, tada će jedan od servera klastera (unutar klastera) početi distribuirati svoje vrijeme. Pomoćno keširanje HTTP proxy takođe podignut na svjedok, uz njegovu pomoć, druge virtuelne mašine imaju pristup Yum repozitorijumima. U stvarnosti, usluge kao što su tačno vrijeme i proxy će najvjerovatnije biti smještene na namjenskim serverima, au kabini na kojima se hostuju svjedok samo za uštedu broja virtuelnih mašina i prostora.

Verzije

v0. Radi sa CentOS 7 i PostgreSQL 11 na VirtualBox 6.1.

Struktura klastera

Svi klasteri su dizajnirani da budu locirani u više centara podataka, kombinovani u jednu ravnu mrežu i moraju izdržati kvar ili mrežnu izolaciju jednog centra podataka. Zbog toga je nemoguće koristiti za zaštitu od podijeljeni mozak standardna tehnologija pejsmejkera tzv STONITH (Pucaj u drugi čvor u glavu) ili mačevanje. Njegova suština: ako čvorovi u klasteru počnu sumnjati da nešto nije u redu s nekim čvorom, on ne reagira ili se ponaša pogrešno, onda ga nasilno isključuju putem "vanjskih" uređaja, na primjer, IPMI ili UPS kontrolne kartice. Ali ovo će funkcionirati samo u slučajevima kada, s jednim kvarom IPMI servera ili UPS-a, oni nastave da rade. Planira i zaštitu od mnogo katastrofalnijeg kvara, kada cijeli podatkovni centar otkaže (na primjer, ostane bez struje). A sa takvim odbijanjem, sve stonith-neće raditi ni uređaji (IPMI, UPS, itd.).

Umjesto toga, sistem je zasnovan na ideji kvoruma. Svi čvorovi imaju glas, a mogu raditi samo oni koji mogu vidjeti više od polovine svih čvorova. Ova količina "pola + 1" se zove kvorum. Ako kvorum nije dostignut, tada čvor odlučuje da je u mrežnoj izolaciji i mora isključiti svoje resurse, tj. to je tako zaštita podijeljenog mozga. Ako softver koji je odgovoran za ovo ponašanje ne radi, onda bi nadzorni program, na primjer, zasnovan na IPMI-ju, trebao raditi.

Ako je broj čvorova paran (klaster u dva data centra), tada može nastati tzv. 50% / 50% (pola pola) kada mrežna izolacija dijeli klaster tačno na pola. Stoga, za paran broj čvorova, dodajemo kvorum uređaj je nezahtjevan demon koji se može pokrenuti na najjeftinijoj virtuelnoj mašini u trećem data centru. On daje svoj glas jednom od segmenata (koji vidi) i time rješava nesigurnost 50%/50%. Imenovao sam server na kojem će se kvorum uređaj pokrenuti svjedok (terminologija iz repmgr-a, svidjelo mi se).

Resursi se mogu premještati s mjesta na mjesto, na primjer, sa neispravnih servera na servisne, ili na naredbu administratora sistema. Kako bi klijenti znali gdje se nalaze resursi koji su im potrebni (gdje da se povežu?), floating IP (float IP). Ovo su IP adrese koje Pacemaker može kretati po čvorovima (sve je u ravnoj mreži). Svaki od njih simbolizira resurs (uslugu) i nalazit će se tamo gdje se trebate povezati da biste dobili pristup ovoj usluzi (u našem slučaju bazi podataka).

Tuchanka1 (komprimirana shema)

struktura

Ideja je bila da imamo mnogo malih baza podataka sa niskim opterećenjem, za koje je neisplativo održavati namenski slave server u hot standby modu za transakcije samo za čitanje (nema potrebe za takvim rasipanjem resursa).

Svaki data centar ima jedan server. Svaki server ima dve PostgreSQL instance (u PostgreSQL terminologiji se zovu klasteri, ali da ne bude zabune, nazvaću ih instancama (po analogiji sa drugim bazama podataka), a klastere Pacemaker zvaću samo klasterima). Jedna instanca radi u master modu i samo ona pruža usluge (do nje vodi samo float IP). Druga instanca radi kao slave za drugi centar podataka i pruža usluge samo ako njen master ne uspije. Budući da će najčešće samo jedna od dvije instance (master) pružati usluge (obavljati zahtjeve), svi resursi servera su optimizirani za master (memorija se dodjeljuje za shared_buffers keš itd.), ali tako da i druga instanca ima dovoljno resursa (iako za suboptimalan rad kroz keš sistema datoteka) u slučaju kvara jednog od centara podataka. Slave ne pruža usluge (ne izvršava zahtjeve samo za čitanje) tokom normalnog rada klastera, tako da nema rata za resurse sa masterom na istoj mašini.

U slučaju dva čvora, tolerancija grešaka je moguća samo sa asinhronom replikacijom, jer će kod sinhrone replikacije kvar slave-a dovesti do zaustavljanja mastera.

propust da svjedoči

propust da svjedoči (kvorum uređaj) Razmatraću samo za klaster Tučanka1, sa svim ostalima će biti ista priča. Ako svjedok ne uspije, ništa se neće promijeniti u strukturi klastera, sve će nastaviti raditi na isti način. Ali kvorum će postati 2 od 3, i stoga će svaki naredni neuspjeh biti fatalan za klaster. I dalje će to morati hitno da se popravi.

Odbijanje Tuchanka1

Kvar jednog od data centara za Tuchanka1. U ovom slučaju svjedok daje svoj glas drugom čvoru u drugom podatkovnom centru. Tu se bivši slave pretvara u gospodara, kao rezultat, oba mastera rade na istom serveru i oba njihova float IP-a upućuju na njih.

tučanka2 (klasična)

struktura

Klasična shema od dva čvora. Gospodar radi na jednom, rob na drugom. Oba mogu izvršavati zahtjeve (slave je samo za čitanje), tako da na oba pokazuje float IP: krogan2 je master, krogan2s1 je slave. I master i slave će imati toleranciju grešaka.

U slučaju dva čvora, tolerancija grešaka je moguća samo sa asinkronom replikacijom, jer će kod sinhrone replikacije kvar slave-a dovesti do zaustavljanja mastera.

Odbijanje Tuchanka2

Ako jedan od data centara pokvari svjedok glasaj za drugog. Na jedinom radnom podatkovnom centru, master će biti podignut, a obje float IP adrese će upućivati ​​na njega: master i slave. Naravno, instanca mora biti konfigurisana na takav način da ima dovoljno resursa (ograničenja veze, itd.) da istovremeno prihvati sve veze i zahtjeve od master i slave float IP-a. To jest, tokom normalnog rada, trebalo bi da ima dovoljnu marginu za ograničenja.

Tučanka4 (mnogo robova)

struktura

Već druga krajnost. Postoje baze podataka koje primaju mnogo zahteva samo za čitanje (tipičan slučaj sajta sa velikim opterećenjem). Tuchanka4 je situacija u kojoj mogu postojati tri ili više robova za obradu takvih zahtjeva, ali ipak ne previše. Sa veoma velikim brojem robova, biće neophodno izmisliti hijerarhijski sistem replikacije. U minimalnom slučaju (na slici), svaki od dva data centra ima dva servera, svaki sa PostgreSQL instancom.

Još jedna karakteristika ove šeme je da je ovdje već moguće organizirati jednu sinhronu replikaciju. Konfiguriran je za repliciranje, ako je moguće, na drugi podatkovni centar, a ne na repliku u istom podatkovnom centru kao glavni. Master i svaki slave označeni su float IP. Za dobro, između robova će biti potrebno napraviti neku vrstu balansiranja zahtjeva sql proxy, na primjer, na strani klijenta. Različiti tipovi klijenata mogu zahtijevati različite vrste sql proxy, a samo klijent programeri znaju kome koji treba. Ovu funkcionalnost može implementirati ili vanjski demon ili klijentska biblioteka (povezivanje spremišta) itd. Sve ovo je izvan opsega klastera za nadilaženje greške baze podataka (failover SQL proxy može se implementirati nezavisno, zajedno sa prelaskom na grešku klijenta).

Odbijanje Tuchanka4

Ako jedan data centar (tj. dva servera) pokvari, svjedok glasa za drugi. Kao rezultat, u drugom data centru rade dva servera: master radi na jednom, a glavni float IP ukazuje na njega (da prima zahteve za čitanje i upisivanje); i slave sa sinhronom replikacijom radi na drugom serveru, a jedan od podređenih float IP-ova ukazuje na njega (za zahtjeve samo za čitanje).

Prva stvar koju treba napomenuti: neće raditi sve podređene float IP adrese, već samo jedna. A da bi se s njim ispravno radilo, to će biti neophodno sql proxy preusmjerio sve zahtjeve na jedinu preostalu float IP; i ako sql proxy ne, možete navesti sve float IP slave odvojene zarezima u URL-u veze. U tom slučaju, sa libpq veza će biti na prvi radni IP, kao što je urađeno u sistemu za automatsko testiranje. Možda u drugim bibliotekama, na primjer, JDBC, ovo neće raditi i neophodno je sql proxy. Ovo je učinjeno jer je zabranjeno istovremeno podizanje float IP za slave na jednom serveru, tako da su ravnomjerno raspoređeni među slave serverima ako ih ima više.

Drugo: čak i u slučaju kvara podatkovnog centra, sinhrona replikacija će se održati. Pa čak i ako dođe do sekundarnog kvara, odnosno da jedan od dva servera otkaže u preostalom podatkovnom centru, klaster, iako će prestati pružati usluge, i dalje će zadržati informacije o svim izvršenim transakcijama za koje je dao potvrdu urezivanja (neće biti gubitka informacija u slučaju sekundarnog kvara).

Tuchanka3 (3 data centra)

struktura

Ovo je klaster za situaciju u kojoj postoje tri potpuno funkcionalna centra podataka, od kojih svaki ima potpuno funkcionalan server baze podataka. U ovom slučaju kvorum uređaj nije potrebno. Master radi u jednom data centru, a slave rade u druga dva. Replikacija je sinhrona, tipa ANY (slave1, slave2), odnosno, klijent će dobiti potvrdu urezivanja kada bilo koji od slaveova prvi odgovori da je prihvatio urezivanje. Na resurse ukazuje jedan float IP za master i dva za slave. Za razliku od Tuchanka4, sva tri float IP-a su tolerantna na greške. Da biste uravnotežili SQL upite samo za čitanje, možete koristiti sql proxy (sa odvojenom tolerancijom grešaka), ili dodijelite jedan slave IP float polovini klijenata, a drugi drugoj polovini.

Odbijanje Tuchanka3

Ako jedan od data centara pokvari, ostaju dva. U jednom se podižu master i float IP od mastera, u drugom - slave i oba slave float IP (instanca mora imati dvostruku rezervu resursa da bi prihvatila sve veze sa oba slave float IP-a). Sinhrona replikacija između mastera i slaveova. Takođe, klaster će sačuvati informacije o izvršenim i potvrđenim transakcijama (neće biti gubitka informacija) u slučaju uništenja dva data centra (ako se ne unište istovremeno).

Odlučio sam da ne uključujem detaljan opis strukture datoteke i implementacije. Ako želite da se poigrate, sve ovo možete pročitati u README. Dajem samo opis automatskog testiranja.

Automatski sistem testiranja

Za provjeru otpornosti klastera uz imitaciju različitih kvarova napravljen je sistem za automatsko testiranje. Pokrenut skriptom test/failure. Skripta može uzeti kao parametre brojeve klastera koje želite da testirate. Na primjer ova naredba:

test/failure 2 3

će testirati samo drugi i treći klaster. Ako parametri nisu specificirani, svi klasteri će biti testirani. Svi klasteri se testiraju paralelno i rezultat se prikazuje na tmux panelu. Tmux koristi namjenski tmux server, tako da se skripta može pokrenuti ispod zadanog tmuxa, što rezultira ugniježđenim tmuxom. Preporučujem korištenje terminala u velikom prozoru i sa malim fontom. Prije početka testiranja, sve virtuelne mašine se vraćaju na snimak u trenutku kada se skripta završi setup.

Terminal je podijeljen u kolone prema broju testiranih klastera, po defaultu (na snimku ekrana) ih ima četiri. Opisaću sadržaj kolona koristeći Tuchanka2 kao primjer. Paneli na snimku ekrana su numerisani:

1. Ovdje se prikazuje statistika testa. Kolone:
   • neuspeh — naziv testa (funkcija u skripti) koji emulira neuspjeh.
   • reakcija — srednje aritmetičko vrijeme u sekundama za koje je klaster obnovio svoje performanse. Mjeri se od početka skripte koja emulira kvar, pa do trenutka kada klaster povrati svoje zdravlje i bude u stanju da nastavi pružati usluge. Ako je vrijeme vrlo kratko, na primjer, šest sekundi (to se događa u klasterima s nekoliko slave-a (Tuchanka3 i Tuchanka4)), to znači da je kvar završio na asinkronom slave-u i ni na koji način nije utjecao na performanse, nije bilo prekidača stanja klastera.
   • odstupanje — pokazuje širenje (tačnost) vrijednosti reakcija koristeći metodu standardne devijacije.
   • Brojanje Koliko je puta ovaj test obavljen.
2. Kratak dnevnik vam omogućava da procenite šta klaster trenutno radi. Prikazuju se broj iteracije (testiranja), vremenska oznaka i naziv operacije. Predugo izvršavanje (> 5 minuta) ukazuje na neku vrstu problema.
3. srce (srce) je trenutno vrijeme. Za vizuelnu procenu performansi majstore Trenutno vrijeme se konstantno upisuje u njegovu tabelu koristeći float IP master. Ako je uspješan, rezultat se prikazuje na ovom panelu.
4. Pobijediti (puls) - "trenutno vrijeme", koje je prethodno snimljeno skriptom srce savladati, sada čitati iz rob kroz njegov float IP. Omogućava vam da vizualno procijenite performanse slave-a i replikacije. U Tuchanka1 nema slave-a sa float IP-om (nema slave-ova koji pružaju usluge), ali postoje dvije instance (DB), tako da neće biti prikazano ovdje Pobijeditii srce druga instanca.
5. Praćenje stanja klastera pomoću uslužnog programa pcs mon. Prikazuje strukturu, distribuciju resursa po čvorovima i druge korisne informacije.
6. Ovdje je prikazan nadzor sistema sa svake virtuelne mašine u klasteru. Ovakvih panela može biti više u zavisnosti od toga koliko virtuelnih mašina ima klaster. Dva grafikona Opterećenje procesora (virtuelne mašine imaju dva procesora), naziv virtuelne mašine, Opterećenje sistema (nazvan Prosjek opterećenja jer je u prosjeku iznosio 5, 10 i 15 minuta), procesne podatke i dodjelu memorije.
7. Praćenje skripte koja izvodi testove. U slučaju kvara - iznenadnog prekida rada ili beskonačnog ciklusa čekanja - ovdje možete vidjeti razlog ovakvog ponašanja.

Testiranje se provodi u dvije faze. Prvo, skripta prolazi kroz sve vrste testova, nasumično birajući virtuelnu mašinu na koju ovaj test treba da se primeni. Zatim se izvodi beskonačan ciklus testiranja, svaki put se nasumično biraju virtuelne mašine i kvar. Iznenadni prekid test skripte (donji panel) ili beskonačna petlja čekanja za nešto (> 5 minuta vremena za dovršetak jedne operacije, to se može vidjeti na tragu) ukazuje da su neki od testova na ovom klasteru neuspjeli.

Svaki test se sastoji od sljedećih operacija:

1. Pokretanje funkcije koja emulira grešku.
2. Spreman? - čekanje na obnovu zdravlja klastera (kada su sve usluge pružene).
3. Prikazuje se vremensko ograničenje za oporavak klastera (reakcija).
4. popraviti — klaster se „popravlja“. Nakon toga bi se trebao vratiti u potpuno operativno stanje i biti spreman za sljedeći kvar.

Evo liste testova sa opisom onoga što rade:

• Forkbomb: Stvara "Nedostaje memorije" pomoću viljuške bombe.
• OutOfSpace: Čvrsti disk je pun. Ali test je prilično simboličan; uz neznatno opterećenje koje se stvara tokom testiranja, PostgreSQL obično ne propadne kada je čvrsti disk pun.
• Postgres-KILL: ubija PostgreSQL naredbom killall -KILL postgres.
• Postgres-STOP: visi PostgreSQL sa naredbom killall -STOP postgres.
• Iskljuciti: "isključuje" virtuelnu mašinu sa komandom VBoxManage controlvm "виртуалка" poweroff.
• Resetovanje: ponovo učitava virtuelnu mašinu sa komandom VBoxManage controlvm "виртуалка" reset.
• SBD STOP: suspenduje SBD demon sa naredbom killall -STOP sbd.
• Ugasiti: preko SSH-a šalje naredbu virtuelnoj mašini systemctl poweroff, sistem se graciozno isključuje.
• prekinuti vezu: mrežna izolacija, komanda VBoxManage controlvm "виртуалка" setlinkstate1 off.

Završite testiranje ili sa standardnom tmux naredbom "kill-window" Ctrl-b &, ili naredbom "detach-client" Ctrl-b d: u ovom trenutku testiranje se završava, tmux se zatvara, virtuelne mašine su isključene.

Problemi identifikovani tokom testiranja

• Trenutno Watchdog demon sbd upravlja zaustavljanjem uočenih demona, ali ih ne zamrzava. I, kao rezultat toga, kvarovi se neispravno rješavaju, što dovodi samo do zamrzavanja Corosync и pejsmejker, ali ne visi sbd... Za proveru Corosync već jesmo PR#83 (na GitHubu na adresi sbd), prihvaćeno na temu majstor. Obećali su (u PR#83) da će biti nešto slično za Pacemaker, nadam se da će do Crveni šešir 8 uradit ću. Ali takvi "kvarovi" su spekulativni, lako se imitiraju umjetno koristeći, na primjer, killall -STOP corosync, ali se nikad ne sretne u stvarnom životu.

• У pejsmejker u verziji za CentOS 7 pogrešno postavljeno sync_timeout у kvorum uređaj, kao rezultat ako jedan čvor pokvari, drugi čvor se ponovo pokreće sa određenom vjerovatnoćom, na koji je majstor trebao da se preseli. Izliječen povećanjem sync_timeout у kvorum uređaj tokom implementacije (u skripti setup/setup1). Ovaj amandman nisu prihvatili programeri pejsmejker, umjesto toga su obećali da će preraditi infrastrukturu na takav način (u nekoj neograničenoj budućnosti) da se taj timeout automatski računa.

• Ako ste naveli tokom konfiguracije baze podataka da LC_MESSAGES (tekstualne poruke) Unicode se može koristiti, npr. ru_RU.UTF-8, zatim pri pokretanju postgres u okruženju u kojem lokalizacija nije UTF-8, recimo, u praznom okruženju (ovdje pejsmejker+pgsqlms(paf) trči postgres), onda dnevnik će sadržavati upitnike umjesto UTF-8 slova. PostgreSQL programeri se nikada nisu složili šta da rade u ovom slučaju. To košta, morate staviti LC_MESSAGES=en_US.UTF-8 prilikom konfigurisanja (kreiranja) DB instance.

• Ako je postavljeno wal_receiver_timeout (podrazumevano je 60s), tada tokom PostgreSQL-STOP testa na masteru u klasterima tuchanka3 i tuchanka4 Replikacija se ne povezuje ponovo s novim masterom. Replikacija je tamo sinhrona, tako da se ne zaustavlja samo slave, već i novi master. Zaobilazi postavljanjem wal_receiver_timeout=0 prilikom konfigurisanja PostgreSQL-a.

• Povremeno sam primetio da PostgreSQL replikacija visi u testu ForkBomb (prelivanje memorije). Nakon ForkBomb-a, ponekad se slave možda neće ponovo povezati s novim masterom. To sam vidio samo u tuchanka3 i tuchanka4 klasterima, gdje je zbog činjenice da je replikacija sinhrona, master visio. Problem je nestao sam od sebe, nakon dužeg vremena (oko dva sata). Potrebno je više istraživanja da se ovo popravi. Simptomi su slični prethodnoj grešci, koja je uzrokovana drugim uzrokom, ali s istim posljedicama.

Krogan slika preuzeta sa Deviant Art uz dozvolu autora:

izvor: www.habr.com