Tänapäeval nõutakse teenuste kõrget kättesaadavust alati ja igal pool, mitte ainult suurte kallite projektide puhul. Ajutiselt kättesaamatuid saite, millel on teade "Vabandust, hooldus on pooleli", tuleb ikka ette, kuid need põhjustavad tavaliselt halvustavat naeratust. Lisagem siia elu pilvedes, kui lisaserveri käivitamiseks on vaja vaid ühte API-kõnet ja pole vaja mõelda "raudsele" toimimisele. Ja pole enam mingit vabandust, miks kriitilist süsteemi ei tehtud klastritehnoloogiaid ja koondamist kasutades usaldusväärselt.
Räägime teile, milliseid lahendusi kaalusime oma teenustes andmebaaside usaldusväärsuse tagamiseks ja milleni jõudsime. Lisaks demo koos kaugeleulatuvate järeldustega.
Kõrge kättesaadavusega arhitektuuri pärand
Seda on veelgi paremini näha erinevate avatud lähtekoodiga süsteemide arendamise kontekstis. Pärandlahendused pidid nõudluse kasvades lisama kõrge kättesaadavusega tehnoloogiaid. Ja nende kvaliteet oli erinev. Järgmise põlvkonna lahendused seavad oma arhitektuuri keskmesse kõrge kättesaadavuse. Näiteks positsioneerib MongoDB klastri oma peamiseks kasutusjuhtumiks. Klaster skaleerub horisontaalselt, mis on selle DBMS-i tugev konkurentsieelis.
Tuleme tagasi PostgreSQL-i juurde. See on üks vanimaid populaarseid avatud lähtekoodiga projekte, mille esimene väljalaskmine toimus eelmise sajandi 95. aastal. Projektimeeskond ei pidanud pikka aega kõrget käideldavust süsteemi poolt lahendatavaks ülesandeks. Seetõttu sai andmete koopiate loomise replikatsioonitehnoloogia sisseehitatud alles 8.2. aasta versioonis 2006, kuid see oli fail (logi saatmine). 2010. aastal ilmus voogesituse replikatsioon versioonis 9.0 ja see on aluseks paljude erinevate klastrite loomisele. See on tegelikult väga üllatav inimestele, kes tutvuvad PostgreSQL-iga pärast Enterprise SQL-i või kaasaegset NoSQL-i - kogukonna standardlahendus on lihtsalt sünkroonse või asünkroonse replikatsiooniga master-replica paar. Samal ajal toimub äravoolus masteri ümberlülitamine käsitsi ning ka klientide vahetamise küsimust tehakse ettepanek lahendada iseseisvalt.
Kuidas me otsustasime teha usaldusväärse PostgreSQL-i ja mida me selleks valisime
PostgreSQL poleks aga nii populaarseks saanud, kui poleks olnud tohutul hulgal projekte ja tööriistu, mis aitavad luua tõrketaluvusega lahendust, mis ei nõua pidevat tähelepanu. Pilves (MCS) on alates DBaaS-i käivitamisest saadaval olnud üksikud PostgreSQL-serverid ja asünkroonse replikatsiooniga põhi-replica paarid.
Loomulikult tahtsime muuta kõigi elu lihtsamaks ja teha kättesaadavaks PostgreSQL-i installi, mis võiks olla aluseks kõrge kättesaadavusega teenustele, mis ei peaks pidevalt jälgima ja öösel ärkama, et lülituda. Selles segmendis on nii vanu tõestatud lahendusi kui ka põlvkond uusi kommunaalteenuseid, mis kasutavad uusimaid arenguid.
Tänapäeval ei toetu kõrge kättesaadavuse probleem mitte broneerimisel (see on ütlematagi selge), vaid konsensusel - juhi valimise algoritmil (Juhivalimised). Enamasti juhtuvad suurõnnetused mitte serverite puudumise, vaid konsensuse probleemide tõttu: uus juht ei saanud välja, kaks juhti ilmusid erinevatesse andmekeskustesse jne. Näiteks Githubi MySQL-klastri krahh – kirjutasid nad .
Selle küsimuse matemaatiline alus on väga tõsine. Ühest küljest seal , mis seab teoreetilised piirangud HA-lahenduste konstrueerimise võimalustele, teisalt matemaatiliselt tõestatud konsensuse määramise algoritmid, nagu nt. и . Selle põhjal on üsna populaarsed DCS (detsentraliseeritud konsensussüsteemid) - Zookeeper, etcd, Consul. Seega, kui otsustussüsteem töötab mõne oma algoritmi alusel, mis on kirjutatud iseseisvalt, tuleks selle suhtes olla äärmiselt ettevaatlik. Pärast suure hulga süsteemide analüüsimist otsustasime Patroni, avatud lähtekoodiga süsteemiga, mille töötas peamiselt välja Zalando.
Lüürilise kõrvalepõikena ütlen, et kaalusime ka multi-master lahendusi ehk salvestuseks horisontaalselt skaleeritavaid klastreid. Kuid kahel peamisel põhjusel otsustasime sellist klastrit mitte teha. Esiteks on sellistel lahendustel suur keerukus ja vastavalt ka rohkem haavatavust. Kõigil juhtudel on raske stabiilset lahendust leida. Teiseks, sel juhul lakkab PostgreSQL olemast puhas (native), mõned funktsioonid pole saadaval, mõnel rakendusel võib töötamise ajal esineda peidetud vigu.
Patroni
Niisiis, kuidas Patroni töötab? Arendajad ei leiutanud jalgratast uuesti ja soovitasid aluseks võtta üht end tõestanud DCS-lahendust. Tema meelevallas on kõik konfiguratsioonide sünkroniseerimise, juhi valiku ja kvoorumi küsimused. Valisime selleks etcd.
Järgmisena tegeleb Patroni kõigi PostgreSQL-i sätete ja replikatsioonisätete õige rakendamisega, samuti ümberlülitamise ja tõrkevahetuse käskude täitmisega (st ülemseadme regulaarne ja ebanormaalne ümberlülitamine). Täpsemalt, MCS-pilves saate luua klastri põhiseadmest, sünkroonsest koopiast ja ühest või mitmest asünkroonsest koopiast. Sünkroonse koopia olemasolu tagab andmete ohutuse vähemalt kahes serveris ja just see koopia on peamine "peakandidaat".
Kuna etcd on juurutatud samades serverites, on optimaalse kvoorumi jaoks soovitatav kasutada 3 või 5 serverit. Selline klaster skaleerub lugemiseks horisontaalselt (kirjutasin kirjutamise skaleerimisest eespool). Kuid pidage meeles, et asünkroonsed koopiad kipuvad hilinema, eriti suure koormuse korral.
Selliste koopiate kasutamine lugemiseks (kuum ooterežiim) on põhjendatud aruandlus- või analüüsiülesannete jaoks ja laadib põhiserveri maha.
Kui soovite sellist klastri ise teha, vajate:
- valmistada ette 3 või enam serverit, konfigureerida nende vahel IP-aadressi ja tulemüüri reegleid;
- installida paketid etcd, Patroni, PostgreSQL teenuste jaoks;
- luua etcd klaster;
- konfigureerige patroniteenus töötama koos PostgreSQL-iga.
See tähendab, et kokku peate õigesti koostama tosin konfiguratsioonifaili ja mitte kuskil viga tegema. Selleks tuleks kindlasti kasutada konfiguratsioonihaldustööriista, nagu näiteks Ansible. Siiski pole endiselt saadaval kõrgetasemelist TCP tasakaalustajat. Selle tegemine on omaette töö.
Neile, kes vajavad valmis klastrit, kuid ei taha selle kõigega tuhnida, proovisime elu lihtsustada ja tegime Patronil meie pilves valmis klastri, saate seda tasuta testida. Lisaks klastrile tegime:
- TCP tasakaalustaja; erinevatel portidel osutab see alati vastavalt praegusele põhi-, sünkroonsele või asünkroonsele koopiale;
- API aktiivse Patroni masteri vahetamiseks.
Neid saab alamklassidesse liigitada nii MCS pilve API kui ka veebikonsooli kaudu.
Demo
PostgreSQL-i klastri võimaluste testimiseks MCS-pilves vaatame, kuidas reaalajas rakendus käitub DBMS-i probleemide korral.
Järgmine on rakenduse kood, mis logib tehissündmused ja teatab neist ekraanile. Vigade korral teatab see sellest ja jätkab oma tööd tsüklina, kuni me selle Ctrl + C kombinatsiooniga peatame.
from __future__ import print_function
from datetime import datetime
from random import randint
from time import sleep
import psycopg2
def main():
try:
connection = psycopg2.connect(user = "admin",
password = "P@ssw0rd",
host = "89.208.87.38",
port = "5432",
database = "myproddb")
cursor = connection.cursor()
cursor.execute("SELECT version();")
record = cursor.fetchone()
print("Connection opened to", record[0])
cursor.execute(
"INSERT INTO log VALUES ({});".format(randint(1, 10000)))
connection.commit()
cursor.execute("SELECT COUNT(event_id) from log;")
record = cursor.fetchone()
print("Logged a value, overall count: {}".format(record[0]))
except Exception as error:
print ("Error while connecting to PostgreSQL", error)
finally:
if connection:
cursor.close()
connection.close()
print("Connection closed")
if __name__ == '__main__':
try:
while True:
try:
print(datetime.now())
main()
sleep(3)
except Exception as e:
print("Caught error:n", e)
sleep(1)
except KeyboardInterrupt:
print("exit")
Rakendus vajab töötamiseks PostgreSQL-i. Loome API abil MCS-pilve klastri. Tavalises terminalis, kus muutuja OS_TOKEN sisaldab API-le juurdepääsu luba (saab hankida openstacki märgi väljastamise käsuga), sisestame käsud:
Looge klaster:
cat <<EОF > pgc10.json
{"cluster":{"name":"postgres10","allow_remote_access":true,"datastore":{"type":"postgresql","version":"10"},"databases":[{"name":"myproddb"}],"users":[{"databases":[{"name":"myproddb"}],"name":"admin","password":"P@ssw0rd"}],"instances":[{"key_name":"shared","availability_zone":"DP1","flavorRef":"d659fa16-c7fb-42cf-8a5e-9bcbe80a7538","nics":[{"net-id":"b91eafed-12b1-4a46-b000-3984c7e01599"}],"volume":{"size":50,"type":"DP1"}},{"key_name":"shared","availability_zone":"DP1","flavorRef":"d659fa16-c7fb-42cf-8a5e-9bcbe80a7538","nics":[{"net-id":"b91eafed-12b1-4a46-b000-3984c7e01599"}],"volume":{"size":50,"type":"DP1"}},{"key_name":"shared","availability_zone":"DP1","flavorRef":"d659fa16-c7fb-42cf-8a5e-9bcbe80a7538","nics":[{"net-id":"b91eafed-12b1-4a46-b000-3984c7e01599"}],"volume":{"size":50,"type":"DP1"}}]}}
EOF
curl -s -H "X-Auth-Token: $OS_TOKEN"
-H 'Accept: application/json'
-H 'Content-Type: application/json'
-d @pgc10.json https://infra.mail.ru:8779/v1.0/ce2a41bbd1434013b85bdf0ba07c770f/clusters
Kui klaster lülitub olekusse ACTIVE, saavad kõik väljad praegused väärtused – klaster on valmis.
GUI-s:
Proovime ühendada ja luua tabeli:
psql -h 89.208.87.38 -U admin -d myproddb
Password for user admin:
psql (11.1, server 10.7)
Type "help" for help.
myproddb=> CREATE TABLE log (event_id integer NOT NULL);
CREATE TABLE
myproddb=> INSERT INTO log VALUES (1),(2),(3);
INSERT 0 3
myproddb=> SELECT * FROM log;
event_id
----------
1
2
3
(3 rows)
myproddb=>
Rakenduses täpsustame praegused seaded PostgreSQL-iga ühenduse loomiseks. Täpsustame TCP tasakaalustaja aadressi, välistades sellega vajaduse käsitsi lülituda ülemseadme aadressile. Käivitame selle. Nagu näete, on sündmused edukalt andmebaasi logitud.
Planeeritud üleminek
Nüüd testime oma rakenduse tööd planeeritud kapteni vahetamise ajal:
Me vaatame rakendust. Näeme, et rakendus on tõesti katkenud, kuid selleks kulub vaid mõni sekund, antud juhul maksimaalselt 9.
autoavarii
Nüüd proovime simuleerida virtuaalse masina, praeguse kapteni, kukkumist. Horizon liidese kaudu oleks võimalik lihtsalt virtuaalmasin välja lülitada, ainult et see on tavaline seiskamine. Sellist üleminekut töötlevad kõik teenused, sealhulgas Patroni.
Vajame ettearvamatut sulgemist. Seetõttu palusin meie administraatoritel testimise eesmärgil virtuaalmasin – praegune juht – ebanormaalsel viisil välja lülitada.
Samal ajal jätkas meie rakendus tööd. Loomulikult ei saa selline kapteni hädaabilülitus jääda märkamatuks.
2019-03-29 10:45:56.071234
Connection opened to PostgreSQL 10.7 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), 64-bit
Logged a value, overall count: 453
Connection closed
2019-03-29 10:45:59.205463
Connection opened to PostgreSQL 10.7 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), 64-bit
Logged a value, overall count: 454
Connection closed
2019-03-29 10:46:02.661440
Error while connecting to PostgreSQL server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
Caught error:
local variable 'connection' referenced before assignment
……………………………………………………….. - здесь какое-то количество ошибок
2019-03-29 10:46:30.930445
Error while connecting to PostgreSQL server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
Caught error:
local variable 'connection' referenced before assignment
2019-03-29 10:46:31.954399
Connection opened to PostgreSQL 10.7 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), 64-bit
Logged a value, overall count: 455
Connection closed
2019-03-29 10:46:35.409800
Connection opened to PostgreSQL 10.7 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), 64-bit
Logged a value, overall count: 456
Connection closed
^Cexit
Nagu näete, suutis rakendus oma tööd jätkata vähem kui 30 sekundiga. Jah, teatud arvul teenusekasutajatel on aega probleeme märgata. See on aga tõsine serveri rike, seda ei juhtu nii sageli. Samas vaevalt oleks inimesel (administraatoril) olnud aega nii kiiresti reageerida, kui ta poleks lülitusskriptiga valmisolekus konsoolis istunud.
Väljund
Mulle tundub, et selline klaster annab administraatoritele tohutu eelise. Tegelikult ei ole andmebaasiserverite tõsised rikked ja tõrked rakendusele ja vastavalt ka kasutajale märgatavad. Te ei pea kiirustades midagi parandama ja lülituma ajutistele konfiguratsioonidele, serveritele jne. Ja kui sellist lahendust kasutatakse pilves valmisteenusena, siis pole vaja selle ettevalmistamisele aega kulutada. Saate teha midagi huvitavamat.
Allikas: www.habr.com
