{"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\/no\/blog\/administrirovanie\/modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker","title":{"rendered":"Modellering av feiltolerante klynger basert p\u00e5 PostgreSQL og Pacemaker","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Innledning<\/h1>\n

<\/p>\n

For some time now, I have been tasked with developing a fault-tolerant cluster for PostgreSQL<\/a><\/noindex>, operating across several data centers interconnected by fiber optics within a single city, and capable of withstanding the failure (for instance, power outage) of one data center. As the software responsible for fault tolerance, I chose Pacemaker<\/a><\/noindex>, because it is the official solution from RedHat for creating fault-tolerant clusters. Its advantages include that RedHat provides support for it and that it is a universal (modular) solution. With it, we will be able to ensure fault tolerance not only for PostgreSQL but also for other services, either by using standard modules or by creating them for specific needs.<\/p>\n

<\/p>\n

A reasonable question arose regarding this solution: how fault-tolerant will the fault-tolerant cluster be? To investigate this, I developed a test bench that simulates various failures on the nodes of the cluster, waits for recovery, restores the failed node, and continues testing in a cycle. Initially, this project was named hapgsql, but over time I grew weary of a name with only one vowel. Therefore, I began to name the fault-tolerant databases (and the float IPs pointing to them) krogan<\/strong> (a character from a video game, whose vital organs are all duplicated), while the nodes, clusters, and the project itself are named tuchanka<\/strong> (the planet where krogan live).<\/p>\n

<\/p>\n

The management has now allowed to open the project for the open source community under the MIT license<\/a><\/noindex>. The README will soon be translated into English (because it is expected that the primary users will be developers of Pacemaker and PostgreSQL), and I decided to format the old Russian version of the README (partially) as this article.<\/p>\n

<\/p>\n

\"Modellering<\/p>\n

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

Clusters are deployed on virtual machines VirtualBox<\/a><\/noindex>. A total of 12 virtual machines (36GiB in total) will be deployed, forming 4 fault-tolerant clusters (different options). The first two clusters consist of two PostgreSQL servers located in different data centers and a shared witness<\/em> med quorum device<\/strong> (hosted on an inexpensive virtual machine in the third data center), which resolves uncertainty 50%\/50%<\/strong>, casting its vote for one of the sides. The third cluster involves three data centers: one master, two slaves, without quorum device<\/strong>. Den fjerde klyngen best\u00e5r av fire PostgreSQL-servere, to per datasenter: \u00e9n master, de andre replikater, og bruker ogs\u00e5 witness<\/em> med quorum device<\/strong>. Den fjerde kan h\u00e5ndtere svikt av to servere eller ett datasenter. Dette alternativet kan, om n\u00f8dvendig, skaleres opp med flere replikater.<\/p>\n

<\/p>\n

Tjeneste for presis tid ntpd<\/a><\/noindex> er ogs\u00e5 omkonfigurert for feiltoleranse, men bruker metoden til ntpd<\/code> (orphan mode<\/em>). Den generelle serveren witness<\/em> fungerer som en sentral NTP-server, som distribuerer sitt tid til alle klynger, og dermed synkroniserer alle servere med hverandre. Hvis witness<\/em> blir ute av drift eller isolert, vil en av serverne i klyngen begynne \u00e5 dele sin tid (innen klyngen). Den hjelpsomme cachende HTTP-proxy<\/strong> er ogs\u00e5 l\u00f8ftet p\u00e5 witness<\/em>, ved hjelp av dette f\u00e5r de andre virtuelle maskinene tilgang til Yum-repositorier. I virkeligheten vil slike tjenester som presis tid og proxy sannsynligvis bli plassert p\u00e5 dedikerte servere, mens i oppsettet er de plassert p\u00e5 witness<\/em> bare for \u00e5 spare antall virtuelle maskiner og plass.<\/p>\n

<\/p>\n

Versjoner<\/h1>\n

<\/p>\n

v0. Kj\u00f8res med CentOS 7 og PostgreSQL 11 p\u00e5 VirtualBox 6.1.<\/p>\n

<\/p>\n

Struktur av klynger<\/h1>\n

<\/p>\n

Alle klynger er designet for \u00e5 v\u00e6re plassert i flere datasentre, koblet sammen i ett flatt nettverk og skal t\u00e5le svikt eller nettverksisolering av ett datasenter. Derfor is not possible<\/strong> bruke for beskyttelse mot split-brain<\/strong> standardteknologien Pacemaker, som kalles STONITH<\/em> (Shoot The Other Node In The Head) eller fencing<\/em>. Essensen er: hvis noder i klyngen begynner \u00e5 mistenke at det skjer noe galt med en av nodene, at den ikke svarer eller oppf\u00f8rer seg unormalt, s\u00e5 frakobler de den tvangsmessig via \u00abeksterne\u00bb enheter, som for eksempel en kontrollert IPMI-kort eller UPS. Men dette vil fungere bare i tilfeller der ved en enkelt svikt av serveren, IPMI eller UPS fortsetter \u00e5 fungere. Her planlegges beskyttelse mot en mye mer katastrofal svikt, n\u00e5r hele datasenteret svikter (for eksempel ved str\u00f8mbrudd). Ved en slik svikt vil alle stonith<\/em>-enheter (IPMI, UPS og s\u00e5 videre) ogs\u00e5 slutte \u00e5 fungere.<\/p>\n

<\/p>\n

I stedet ligger ideen om kvorum til grunn for systemet. Alle noder har en stemme, og bare de som ser mer enn halvparten av alle noder kan fungere. Dette antallet \u00abhalvparten +1\u00bb kalles kvorummet<\/strong>. Hvis kvorum ikke oppn\u00e5s, avgj\u00f8r noden at den befinner seg i nettverksisolasjon og m\u00e5 koble fra sine ressurser, det vil si at det er en slags beskyttelse mot split-brain<\/strong>. Hvis programvaren som svarer for slik atferd, ikke fungerer, m\u00e5 watchdog, for eksempel basert p\u00e5 IPMI, aktiveres.<\/p>\n

<\/p>\n

Hvis antallet noder er jevnt (klyngen i to datasentre), kan det oppst\u00e5 det som kalles usikkerhet 50%\/50%<\/strong> (fifty-fifty<\/em>), n\u00e5r nettverksisolasjonen deler klyngen n\u00f8yaktig p\u00e5 midten. Derfor blir det lagt til quorum device<\/strong> \u2014 en uvanlig demon som kan kj\u00f8res p\u00e5 den billigste virtuelle maskinen i det tredje datasenteret. Den gir stemmen sin til en av segmentene (som den oppfatter) og l\u00f8ser dermed usikkerheten p\u00e5 50%\/50%. Serveren der quorum-enheten skal kj\u00f8res, kalte jeg witness<\/em> (terminologi fra repmgr, jeg likte den).<\/p>\n

<\/p>\n

Ressurser kan flyttes fra sted til sted, for eksempel fra defekte servere til fungerende, eller p\u00e5 kommando fra systemadministratorer. For at kundene skal vite hvor de aktuelle ressursene er (hvor skal de koble seg til?), brukes flytende IP<\/em> (float IP<\/strong>). Dette er IP-er som Pacemaker kan flytte mellom nodene (alt er i et flatt nettverk). Hver av dem symboliserer en ressurs (tjeneste) og vil v\u00e6re der man m\u00e5 koble seg til for \u00e5 f\u00e5 tilgang til denne tjenesten (i v\u00e5rt tilfelle databasen).<\/p>\n

<\/p>\n

Tuchanka1 (plattform med tetning)<\/h2>\n

<\/p>\n

Struktur<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Ideen var at vi har mange sm\u00e5 databaser med lav belastning, for hvilke det ikke er \u00f8konomisk \u00e5 opprettholde en dedikert slave-server i hot standby for read-only transaksjoner (det er un\u00f8dvendig ressursbruk).<\/p>\n

<\/p>\n

I hvert datasenter er det \u00e9n server. Hver server har to PostgreSQL-instanser (i PostgreSQL-terminologi kalles de klynger, men for \u00e5 unng\u00e5 forvirring vil jeg kalle dem instanser (p\u00e5 lignende m\u00e5te som andre databaser), og klynger vil jeg kun bruke om Pacemaker-klynger). \u00c9n instans fungerer i master-modus, og det er bare den som tilbyr tjenester (det er bare til den det lenkes float IP). Den andre instansen fungerer som slave for det andre datasenteret, og vil kun tilby tjenester hvis dens master svikter. Siden det meste av tiden kun \u00e9n instans av de to (master) tilbyr tjenester (utf\u00f8rer foresp\u00f8rselene), optimaliseres alle serverressurser mot master (minne tildeles til cache shared_buffers osv.), men s\u00f8rger for at den andre instansen ogs\u00e5 har tilstrekkelige ressurser (selv om det er for suboptimal drift via filsystemcache) i tilfelle et av datasentrene svikter. Slaven tilbyr ingen tjenester (utf\u00f8rer ikke lese-foresp\u00f8rselene) under normal drift av klyngen, for \u00e5 unng\u00e5 ressurskonflikter med master p\u00e5 samme maskin.<\/p>\n

<\/p>\n

I tilfelle med to noder er feiltoleranse kun mulig med asynkron replikering, ettersom ved synkron replikering vil feil i slaven f\u00f8re til at master stopper.<\/p>\n

<\/p>\n

Feil i witness<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Feil i witness (quorum device<\/em>) vil jeg kun vurdere for klyngen Tuchanka1, det vil v\u00e6re den samme historien for alle andre. Ved feil i witness vil ingenting endres i klyngeoppsettelsen, alt vil fortsette \u00e5 fungere som f\u00f8r. Men kvorum vil bli lik 2 av 3, og derfor vil enhver annen neste feil v\u00e6re fatal for klyngen. Det m\u00e5 uansett fikses straks.<\/p>\n

<\/p>\n

Feil i Tuchanka1<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Feil i ett av datasentrene for Tuchanka1. I dette tilfellet witness<\/em> gir stemmen sin til den andre noden i det andre datasenteret. Der blir den tidligere slaven til master, slik at begge mestere kj\u00f8rer p\u00e5 \u00e9n server og begge deres float IP-er peker til dem.<\/p>\n

<\/p>\n

Tuchanka2 (klassisk)<\/h2>\n

<\/p>\n

Struktur<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Klassisk oppsett med to noder. \u00c9n kj\u00f8rer som master, den andre som slave. Begge kan utf\u00f8re foresp\u00f8rseler (slaven kun lese), s\u00e5 begge har float IP: krogan2 \u2014 for master, krogan2s1 \u2014 for slaven. Feiltoleranse vil v\u00e6re for b\u00e5de master og slave.<\/p>\n

<\/p>\n

I tilfelle med to noder er feiltoleranse kun mulig med asynkron replikering, fordi ved synkron replikering vil feil i slaven f\u00f8re til at master stopper.<\/p>\n

<\/p>\n

Feil i Tuchanka2<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Ved feil i ett av datasentrene witness<\/em> stemmer for den andre. Den eneste fungerende datasenteret vil heve mesteren, og begge float IP-er vil peke mot den: mesteren og slave. Selvf\u00f8lgelig m\u00e5 instansen v\u00e6re konfigurert slik at den har nok ressurser (grenser for tilkobling osv.) til \u00e5 samtidig motta alle tilkoblinger og foresp\u00f8rselene fra master- og slave float IP. Det vil si at den m\u00e5 ha en tilstrekkelig margin p\u00e5 grensene under normal drift.<\/p>\n

<\/p>\n

Tuchanka4 (mange slaver)<\/h2>\n

<\/p>\n

Struktur<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Det er allerede en annen ekstremitet. Det finnes databaser som mottar mange foresp\u00f8rselene for lesing (et typisk tilfelle med h\u00f8ytrafikk-nettsteder). Tuchanka4 er en situasjon hvor det kan v\u00e6re tre eller flere slaver for \u00e5 h\u00e5ndtere slike foresp\u00f8rselene, men ikke for mange. Med veldig mange slaver m\u00e5 det oppfinnes et hierarkisk system for replikering. I minimumstilfellet (i bildet) er det to servere i hvert datasenter, og p\u00e5 hver av dem er det en instans av PostgreSQL.<\/p>\n

<\/p>\n

En annen funksjon ved dette systemet er at det allerede er mulig \u00e5 organisere en synkron replikering. Den er konfigurert for \u00e5 replikere, om mulig, til et annet datasenter, og ikke til en replika i samme datasenter som mesteren. B\u00e5de p\u00e5 mesteren og p\u00e5 hver slave peker float IP. Ideelt sett m\u00e5 det gj\u00f8res lastbalansering av foresp\u00f8rselet mellom slavene ved hjelp av noe sql proxy<\/em>, for eksempel, p\u00e5 klientsiden. Ulike typer kunder kan kreve forskjellig typ sql proxy<\/em>, og bare utviklerne av klientene vet hvem som trenger hva. Denne funksjonaliteten kan implementeres b\u00e5de som en ekstern demon og som en klientbibliotek (tilkoblingspool), osv. Alt dette g\u00e5r utover temaet for feiltolerante databaser (feiltoleranse SQL proxy<\/em> kan implementeres uavhengig av klientens feiltoleranse).<\/p>\n

<\/p>\n

Feil Tuchanka4<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Ved feil med ett datasenter (dvs. to servere) stemmer vitnet for den andre. Resultatet er at to servere fungerer i det andre datasenteret: p\u00e5 den ene kj\u00f8rer mesteren, og den peker mot master float IP (for \u00e5 motta lesing-skriving foresp\u00f8rselene); og p\u00e5 den andre serveren kj\u00f8rer en slave med synkron replikering, og den peker mot en av slave float IP (for read only-foresp\u00f8rselen).<\/p>\n

<\/p>\n

Det f\u00f8rste som m\u00e5 nevnes: ikke alle slave float IP-er vil v\u00e6re aktive, kun \u00e9n. Og for at den skal fungere korrekt, m\u00e5 det v\u00e6re kommandoer som sikrer det. sql proxy<\/em> vider alle foresp\u00f8rselene til den eneste gjenv\u00e6rende float IP; hvis ikke sql proxy<\/em> , kan du liste opp alle float IP-ene til slavene med komma i URL-en for tilkobling. I s\u00e5 fall vil libpq<\/em> tilkoblingen v\u00e6re til den f\u00f8rste fungerende IP-en, slik det er gjort i automatisk testingssystem. Det kan hende at det ikke vil fungere p\u00e5 andre biblioteker, for eksempel JDBC, og det vil v\u00e6re n\u00f8dvendig sql proxy<\/em>. Det er gjort fordi float IP-ene til slavene har restriksjonen om at de ikke kan aktiveres samtidig p\u00e5 \u00e9n server, slik at de blir jevnt fordelt over slave-serverne hvis det er flere som jobber.<\/p>\n

<\/p>\n

For det andre: selv i tilfelle av datasenterfeil vil synkron replikering bli bevart. Og selv om det skjer en sekund\u00e6r feil, det vil si at en av de to serverne i det gjenv\u00e6rende datasenteret svikter, vil klyngen, selv om den slutter \u00e5 tilby tjenester, fortsatt beholde informasjon om alle bekreftede transaksjoner som den har gitt bekreftelse p\u00e5 for kommittering (det vil ikke v\u00e6re noen tap av informasjon ved sekund\u00e6rfeil).<\/p>\n

<\/p>\n

Tuchanka3 (3 datasentre)<\/h2>\n

<\/p>\n

Struktur<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Dette er en klynge for situasjonen der det finnes tre fullt fungerende datasentre, hvor hver av dem har en fullt fungerende databaseserver. I dette tilfellet quorum device<\/em> er ikke n\u00f8dvendig. I ett datasenter fungerer master, mens i de to andre er det slaver. Replikeringen er synkron, av typen ANY (slave1, slave2), noe som inneb\u00e6rer at klienten vil motta bekreftelse p\u00e5 kommittering n\u00e5r noen av slavene f\u00f8rst svarer at de har mottatt kommitteringen. Ressursene peker p\u00e5 \u00e9n float IP for master og to for slavene. I motsetning til Tuchanka4 er alle tre float IP-ene feiltolerante. For \u00e5 balansere read-only SQL-foresp\u00f8rslene kan man bruke sql proxy<\/em> (med separat feiltoleranse), eller man kan tildele \u00e9n slave float IP til halvparten av klientene og en annen til den andre halvparten.<\/p>\n

<\/p>\n

Feil Tuchanka3<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Ved feil p\u00e5 ett av datasentrene er det fortsatt to igjen. I ett er master og masterens float IP aktivert, mens i det andre er det slaver og begge slavernes float IP-er (instansen m\u00e5 ha dobbelt s\u00e5 mange ressurser tilgjengelig for \u00e5 h\u00e5ndtere alle tilkoblinger fra begge slavernes float IP-er). Det er synkron replikering mellom masterne og slaven. Klyngen vil ogs\u00e5 bevare informasjon om bekreftede og kommitterte transaksjoner (det vil ikke v\u00e6re tap av informasjon) i tilfelle to datasentre blir \u00f8delagt (s\u00e5 lenge de ikke blir \u00f8delagt samtidig).<\/p>\n

<\/p>\n

Eg detaljert beskrivelse av filstrukturen og distribusjonen bestemte jeg meg for ikke \u00e5 inkludere. De som \u00f8nsker \u00e5 eksperimentere, kan lese alt dette i README. Jeg gir bare en beskrivelse av automatisk testing.<\/em><\/p>\n

<\/p>\n

Automatisk testingssystem<\/h1>\n

<\/p>\n

For \u00e5 teste klusterets feilresistens med simulering av forskjellige feil er det laget et automatisk testingssystem. Det kj\u00f8res av et skript test\/failure<\/code>. Skriptet kan ta som parametere nummer p\u00e5 klusterne som skal testes. For eksempel, denne kommandoen:<\/p>\n

<\/p>\n

test\/failure 2 3<\/code><\/pre>\n
<\/p>\n
vil teste bare det andre og tredje klusteret. Hvis ingen parametere er angitt, vil alle klusterne bli testet. Alle klusterne testes parallelt, og resultatet vises i tmux-panelet. Tmux bruker en dedikert tmux-server, s\u00e5 skriptet kan kj\u00f8res fra standard tmux, og det vil bli en nestet tmux. Jeg anbefaler \u00e5 bruke terminalen i et stort vindu med liten skrift. F\u00f8r testing starter, tilbakestilles alle virtuelle maskiner til et snapshot fra tidspunktet da skriptet ble avsluttet. setup<\/code>.<\/p>\n
<\/p>\n
\"Modellering<\/p>\n
<\/p>\n
Terminalen er delt inn i kolonner tilsvarende antall testede klustre; som standard (p\u00e5 skjermbildet) er det fire. Innholdet i kolonnene vil jeg utbrodere med eksemplet Tuchanka2. Panelene p\u00e5 skjermbildet er nummerert:<\/p>\n
<\/p>\n
    \n
  1. Her vises statistikk for testene. Kolonner:\n