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

Introduktion<\/h1>\n

<\/p>\n

For some time now, I have been tasked with developing a fault-tolerant cluster for PostgreSQL<\/a><\/noindex>, operating in several data centers connected by fiber optics within one city, and capable of withstanding the failure (for example, a 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 building fault-tolerant clusters. It is good in that RedHat provides support for it, and because this solution is universal (modular). With its help, it will be possible 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 actually be? To investigate this, I developed a test setup 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 called hapgsql, but over time I grew tired of the 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 computer game who has all vital organs duplicated), while the nodes, clusters, and the project itself are called tuchanka<\/strong> (the planet where the krogan live).<\/p>\n

<\/p>\n

Now the management has allowed to open the project to the open-source community under the MIT license<\/a><\/noindex>. The README will soon be translated into English (because it is expected that the main 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 will be deployed (36GiB in total), forming 4 fault-tolerant clusters (different options). The first two clusters consist of two PostgreSQL servers, which are located in different data centers, and a common server witness<\/em> c quorum device<\/strong> (located on a cheap virtual machine in the third data center), which resolves uncertainty 50%\/50%<\/strong>, giving its vote to one of the parties. The third cluster spans three data centers: one master, two slaves, without quorum device<\/strong>. Klyngen best\u00e5r af fire PostgreSQL-servere, to per datacenter: en master og de \u00f8vrige replikaer, og benytter ogs\u00e5 witness<\/em> c quorum device<\/strong>. Klyngen kan t\u00e5le at to servere eller et datacenter fejler. Denne l\u00f8sning kan, om n\u00f8dvendigt, skaleres til et st\u00f8rre antal replikaer.<\/p>\n

<\/p>\n

Tidsynkroniseringstjeneste ntpd<\/a><\/noindex> er ogs\u00e5 omkonfigureret for redundans, men den bruger metoden med ntpd<\/code> (orphan mode<\/em>). Den centrale server witness<\/em> funker som en central NTP-server, der distribuerer sin tid til alle klynger, hvilket synchroniserer alle serverne indbyrdes. Hvis witness<\/em> den fejler eller isoleres, s\u00e5 vil en af klyngens servere (inden for klyngen) begynde at distribuere sin tid. En supplementary caching HTTP proxy<\/strong> er ogs\u00e5 oprettet p\u00e5 witness<\/em>, som g\u00f8r det muligt for de \u00f8vrige virtuelle maskiner at f\u00e5 adgang til Yum-repositories. I virkeligheden vil s\u00e5danne tjenester som tidsynkronisering og proxy sandsynligvis v\u00e6re placeret p\u00e5 dedikerede servere, mens de i denne opstilling er placeret p\u00e5 witness<\/em> kun for at spare p\u00e5 antallet af virtuelle maskiner og plads.<\/p>\n

<\/p>\n

Versioner<\/h1>\n

<\/p>\n

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

<\/p>\n

Klyngeopbygning<\/h1>\n

<\/p>\n

Alle klynger er designet til at v\u00e6re placeret i flere datacentre, bundet sammen i et fladt netv\u00e6rk og skal kunne modst\u00e5 nedbrud eller netv\u00e6rksisolering af et datacenter. Derfor ikke er muligt<\/strong> bruger standard teknologien Pacemaker til at beskytte mod split-brain<\/strong> teknologi kaldet STONITH<\/em> (Shoot The Other Node In The Head) eller fencing<\/em>. Dens essens: hvis noderne i klyngen begynder at mist\u00e6nke, at en nod er i problemer, ikke svarer eller opf\u00f8rer sig unormalt, vil de tvinge den til at lukke ned via \"eksterne\" enheder, s\u00e5som en IPMI-kontrolkort eller UPS. Men dette vil kun virke i tilf\u00e6lde, hvor i tilf\u00e6lde af en enkelt serverfejl forts\u00e6tter IPMI eller UPS med at fungere. Her planl\u00e6gges der beskyttelse mod en meget mere katastrofal fejl, n\u00e5r hele datacentret fejler (for eksempel mister str\u00f8m). Ved en s\u00e5dan fejltagelse vil alle stonith<\/em>-enheder (IPMI, UPS osv.) heller ikke fungere.<\/p>\n

<\/p>\n

I stedet bygger systemet p\u00e5 en kvorum-ide. Alle noder har stemmerettighed, og kun de, der kan se mere end halvdelen af alle noder, kan fungere. Antallet \"halvdel + 1\" kaldes kvorum<\/strong>. Hvis kvorum ikke kan oprettes, beslutter noden, at den er i netv\u00e6rksisolering og skal deaktivere sine ressourcer, dvs. det er s\u00e5dan en beskyttelse mod split-brain<\/strong>. Hvis softwaren, der styrer denne adf\u00e6rd, ikke fungerer, skal en watchdog aktiveres, for eksempel baseret p\u00e5 IPMI.<\/p>\n

<\/p>\n

Hvis antallet af noder er lige (klyngen i to datacentre), kan der opst\u00e5 det, der kaldes usikkerhed 50%\/50%<\/strong> (fifty-fifty<\/em>), n\u00e5r netv\u00e6rksisoleringen opdeler klyngen pr\u00e6cist i to. Derfor tilf\u00f8jes quorum device<\/strong> \u2014 en ubesv\u00e6ret daemon, der kan k\u00f8res p\u00e5 den billigste virtuelle maskine i det tredje datacenter. Den giver sin stemme til en af sektionerne (som den ser), og derved afklarer usikkerheden 50%\/50%. Serveren, hvor quorum-enheden skal k\u00f8res, har jeg kaldt witness<\/em> (terminologi fra repmgr, som jeg kan lide).<\/p>\n

<\/p>\n

Ressourcer kan flytte fra sted til sted, for eksempel fra defekte servere til fungerende, eller p\u00e5 ordre fra systemadministratorer. For at kunderne skal vide, hvor deres n\u00f8dvendige ressourcer er (hvor skal de forbinde?), bruges der flydende IP<\/em> (float IP<\/strong>). Dette er IP-adresser, som Pacemaker kan flytte mellem noder (alt er i et fladt netv\u00e6rk). Hver af dem symboliserer en ressource (tjeneste) og vil v\u00e6re der, hvor der skal forbindes for at f\u00e5 adgang til denne tjeneste (i vores tilf\u00e6lde databasen).<\/p>\n

<\/p>\n

Tuchanka1 (schema med t\u00e6thed)<\/h2>\n

<\/p>\n

Struktur<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Id\u00e9en var, at vi har mange sm\u00e5 databaser med lav belastning, for hvilke det ikke er rentabelt at opretholde en dedikeret slave-server i hot standby-tilstand til read-only-transaktioner (der er ikke behov for s\u00e5dan en ressourcespild).<\/p>\n

<\/p>\n

Der er \u00e9n server i hver datacenter. P\u00e5 hver server er der to PostgreSQL-instanser (i PostgreSQL-terminologi kaldes de kl\u00f8fter, men for at undg\u00e5 forvirring vil jeg kalde dem instanser (analogt med andre databaser) og kalde klustrene kun for Pacemaker-klustre). En instans k\u00f8rer i master-tilstand, og kun den leverer tjenester (kun denne har et float IP). Den anden instans fungerer som slave for det andet datacenter og vil kun levere tjenester, hvis dens master fejler. Da der kun vil v\u00e6re \u00e9n instans, der leverer tjenester (behandler foresp\u00f8rgsler) det meste af tiden (master), optimeres serverens ressourcer til masteren (hukommelse tildeles til cache shared_buffers osv.), men s\u00e5 der ogs\u00e5 er tilstr\u00e6kkelige ressourcer til den anden instans (selv om det kun er til suboptimal drift gennem filsystemets cache) i tilf\u00e6lde af svigt i et af datacentrene. Slaven leverer ikke tjenester (behandler ikke read only-foresp\u00f8rgsler) under normal drift af klyngen for at undg\u00e5 ressourcekonflikter med masteren p\u00e5 samme maskine.<\/p>\n

<\/p>\n

I tilf\u00e6lde af to noder er h\u00f8j tilg\u00e6ngelighed kun mulig ved asynkron replikation, da en synkron fejlfunktion p\u00e5 slaven vil resultere i stop af masteren.<\/p>\n

<\/p>\n

Fejl witness<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Fejl witness (quorum device<\/em>) vil jeg kun overveje for klyngen Tuchanka1, historien er den samme for alle andre. Ved fejl p\u00e5 witness \u00e6ndres der ikke noget i klynge-strukturen, alt forts\u00e6tter med at fungere som f\u00f8r. Men quorum vil v\u00e6re lig med 2 ud af 3, og derfor vil enhver efterf\u00f8lgende fejl v\u00e6re fatal for klyngen. Det skal hastigt repareres.<\/p>\n

<\/p>\n

Fejl Tuchanka1<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Fejl p\u00e5 et af datacentrene for Tuchanka1. I dette tilf\u00e6lde witness<\/em> stemmer denne for den anden node i det andet datacenter. Her bliver den tidligere slave omdannet til master, hvilket resulterer i, at begge mastere k\u00f8rer p\u00e5 \u00e9n server, og begge deres float IP peger p\u00e5 dem.<\/p>\n

<\/p>\n

Tuchanka2 (klassisk)<\/h2>\n

<\/p>\n

Struktur<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Den klassiske konfiguration best\u00e5ende af to noder. P\u00e5 den ene k\u00f8rer master, og p\u00e5 den anden er der en slave. Begge kan h\u00e5ndtere foresp\u00f8rgsler (slaven kun read only), derfor peger begge p\u00e5 et float IP: krogan2 \u2014 p\u00e5 master, krogan2s1 \u2014 p\u00e5 slaven. Der vil v\u00e6re h\u00f8j tilg\u00e6ngelighed b\u00e5de for masteren og slaven.<\/p>\n

<\/p>\n

I tilf\u00e6lde af to noder er h\u00f8j tilg\u00e6ngelighed kun mulig ved asynkron replikation, fordi en synkron fejlfunktion p\u00e5 slaven vil resultere i stop af masteren.<\/p>\n

<\/p>\n

Fejl Tuchanka2<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Ved fejl p\u00e5 et af datacentrene witness<\/em> stemmer imod den anden. P\u00e5 det eneste fungerende datacenter vil master blive oprettet, og begge float IP'er: master og slave vil pege p\u00e5 det. Selvf\u00f8lgelig skal instansen v\u00e6re konfigureret s\u00e5ledes, at den har tilstr\u00e6kkelige ressourcer (gr\u00e6nser for forbindelser osv.) til samtidig at h\u00e5ndtere alle forbindelser og anmodninger fra b\u00e5de master og slave float IP. Det vil sige, at den skal have et tilstr\u00e6kkeligt overskud af gr\u00e6nser under normal drift.<\/p>\n

<\/p>\n

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

<\/p>\n

Struktur<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Der er allerede en anden ekstrem. Der er databaser, som har mange read-only anmodninger (et typisk tilf\u00e6lde af en h\u00f8jbelastet hjemmeside). Tuchanka4 er en situation, hvor der kan v\u00e6re tre eller flere slaver til at h\u00e5ndtere s\u00e5danne anmodninger, men ikke mere end det. Ved et meget stort antal slaver skal der opfindes et hierarkisk replikationssystem. I det mindste tilf\u00e6lde (p\u00e5 billedet) er der to servere i hvert af de to datacentre, hvor hver har en instans PostgreSQL.<\/p>\n

<\/p>\n

En anden funktion ved denne ordning er, at der allerede kan organiseres en synkron replikation. Den er konfigureret til at replikere, s\u00e5 vidt det er muligt, til et andet datacenter, og ikke til en kopi i det samme datacenter som master. Master og hver slave peger p\u00e5 float IP. Ideelt set skal der mellem slaverne laves en belastningsbalancering af anmodninger p\u00e5 en eller anden m\u00e5de. sql proxy<\/em>, for eksempel p\u00e5 klientsiden. Forskellige typer af klienter kan kr\u00e6ve forskellige typer sql proxy<\/em>, og kun klientudviklerne ved, hvem der har brug for hvad. Denne funktionalitet kan implementeres b\u00e5de som et eksternt demon og som et klientbibliotek (forbindelsespool) osv. Alt dette ligger uden for emnet for det fejltolerante DB-kluster (fejltolerance SQL proxy<\/em> kan implementeres uafh\u00e6ngigt, sammen med klientens fejltolerance).<\/p>\n

<\/p>\n

Fejl Tuchanka4<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Ved fejlen p\u00e5 et datacenter (dvs. de to servere) stemmer witness for den anden. Som et resultat fungerer der to servere i det andet datacenter: p\u00e5 den ene k\u00f8rer master, og den peger p\u00e5 master float IP (til modtagelse af read-write anmodninger); og p\u00e5 den anden server k\u00f8rer en slave med synkron replikation, og den peger p\u00e5 en af slave float IP'er (til read only-anmodninger).<\/p>\n

<\/p>\n

Det f\u00f8rste, man skal bem\u00e6rke: de fungerende slave float IP'er vil ikke v\u00e6re alle, men kun \u00e9n. Og for korrekt brug af den, skal det v\u00e6re s\u00e5dan, at sql proxy<\/em> omdirigerede alle foresp\u00f8rgsler til den eneste tilbagev\u00e6rende float IP; og hvis sql proxy<\/em> nej, s\u00e5 kan man opdatere alle float IP'er for slaverne med komma i URL'en for forbindelsen. I s\u00e5 fald libpq<\/em> vil forbindelsen ske til den f\u00f8rste fungerende IP, som det er gjort i testsystemet. Det er muligt, at det ikke fungerer p\u00e5 samme m\u00e5de i andre biblioteker, f.eks. JDBC, og det er n\u00f8dvendigt sql proxy<\/em>. Det er gjort s\u00e5dan, fordi der er forbud mod at have flere float IP'er for slaverne k\u00f8rende p\u00e5 samme server, s\u00e5 de bliver j\u00e6vnt fordelt p\u00e5 slave-serverne, hvis der er flere i drift.<\/p>\n

<\/p>\n

Det andet: selv i tilf\u00e6lde af fejl i datacenteret vil den synkrone replikation blive bevaret. Og selv hvis der sker en sekund\u00e6r fejl, alts\u00e5 hvis en af de to servere i det tilbagev\u00e6rende datacenter g\u00e5r ned, vil klyngen, selvom den stopper med at yde service, stadig gemme information om alle bekr\u00e6ftede transaktioner, som den har givet en bekr\u00e6ftelse om kommittering (der vil ikke v\u00e6re tab af information ved sekund\u00e6r fejl).<\/p>\n

<\/p>\n

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

<\/p>\n

Struktur<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Dette er en klynge for situationen, hvor der er tre fuldt operationelle datacentre, hvor hver har en fuldt operationel DB-server. I dette tilf\u00e6lde quorum device<\/em> er ikke n\u00f8dvendig. I \u00e9t datacenter k\u00f8rer masteren, i de to andre \u2014 slaverne. Replikationen er synkron, type ANY (slave1, slave2), hvilket betyder, at klienten vil modtage en bekr\u00e6ftelse p\u00e5 kommitteringen, n\u00e5r nogen af slaverne f\u00f8rst svarer, at de har accepteret kommitteringen. Der peges p\u00e5 en float IP for masteren og to for slaverne. I mods\u00e6tning til Tuchanka4 er alle tre float IP'er fejl tolerante. Til belastningsbalancering af read-only SQL-foresp\u00f8rgsler kan man bruge sql proxy<\/em> (med separate fejl tolerancer), eller den ene halvdel af kunderne f\u00e5r tildelt \u00e9n slave float IP, og den anden halvdel en anden.<\/p>\n

<\/p>\n

Fejl Tuchanka3<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Ved fejl i et af datacentrene forbliver der to. I \u00e9t k\u00f8rer masteren og float IP'en fra masteren, i det andet \u2014 slaven og begge slave float IP'er (instansen skal have dobbelt s\u00e5 mange ressourcer for at kunne modtage alle forbindelser fra begge slave float IP'er). Mellem masterne og slaven er der synkron replikation. Desuden vil klyngen gemme information om bekr\u00e6ftede og accepterede transaktioner (der vil ikke v\u00e6re tab af information) i tilf\u00e6lde af \u00f8del\u00e6ggelse af to datacentre (hvis de ikke \u00f8del\u00e6gges samtidigt).<\/p>\n

<\/p>\n

Jeg har valgt ikke at inkludere en detaljeret beskrivelse af filstrukturen og deployment. Den, der \u00f8nsker at lege med det, kan l\u00e6se alt dette i README. Jeg giver kun en beskrivelse af automatiseret testning.<\/em><\/p>\n

<\/p>\n

Automatiseret testsystem<\/h1>\n

<\/p>\n

For at teste fejltolerance i klynger med simulering af forskellige fejl er der oprettet et automatiseret testsystem. Det startes med et script test\/failure<\/code>. Scriptet kan tage som parametre numrene p\u00e5 de klynger, der \u00f8nskes testet. For eksempel vil denne kommando:<\/p>\n

<\/p>\n

test\/failure 2 3<\/code><\/pre>\n
<\/p>\n
teste kun den anden og tredje klynge. Hvis der ikke angives parametre, vil alle klynger blive testet. Alle klynger testes parallelt, og resultatet vises i tmux-panelet. Tmux bruger en dedikeret tmux-server, s\u00e5 scriptet kan startes fra standard tmux, hvilket vil resultere i indlejret tmux. Jeg anbefaler at bruge terminalen i et stort vindue med lille skrift. F\u00f8r testningen begynder, bliver alle virtuelle maskiner rullet tilbage til det \u00f8jebliksbillede, der blev taget ved afslutningen af scriptet. setup<\/code>.<\/p>\n
<\/p>\n
\"Modellering<\/p>\n
<\/p>\n
Terminalen er opdelt i kolonner svarende til antallet af testede klynger, som i standard (p\u00e5 sk\u00e6rmbilledet) er fire. Indholdet af kolonnerne vil jeg beskrive med eksemplet Tuchanka2. Panelerne p\u00e5 sk\u00e6rmbilledet er nummererede:<\/p>\n
<\/p>\n
    \n
  1. Her vises statistikken for testene. Kolonnerne:\n