{"id":55467,"date":"2020-01-21T00:00:00","date_gmt":"2020-01-20T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya"},"modified":"2020-02-18T14:03:35","modified_gmt":"2020-02-18T11:03:35","slug":"postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya","title":{"rendered":"Postgres-mar\u021bi nr. 5: \u201ePostgreSQL \u0219i Kubernetes. CI\/CD. Automatizarea test\u0103rii\u201d","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Postgres-mar\u021bi
\n
\nLa sf\u00e2r\u0219itul anului trecut a avut loc un alt live stream al comunit\u0103\u021bii ruse\u0219ti PostgreSQL #RuPostgres<\/a><\/noindex>, \u00een cadrul c\u0103ruia co-fondatorul s\u0103u, Nikolai Samohvalov, a discutat cu directorul tehnic al 'Flanta', Dmitry Stolyarov, despre aceast\u0103 SGBD \u00een contextul Kubernetes.<\/p>\n

Public\u0103m transcrierea p\u0103r\u021bii principale a acestei discu\u021bii, iar pe canalul de YouTube al comunit\u0103\u021bii<\/a><\/noindex> a fost publicat \u00eenregistrarea video complet\u0103:<\/a><\/noindex><\/p>\n

\r\n \"Reda\u021bi\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Baze de date \u0219i Kubernetes<\/h2>\n

\nNS<\/b>: Nu vom vorbi ast\u0103zi despre VACUUM \u0219i CHECKPOINT-uri. Vrem s\u0103 discut\u0103m despre Kubernetes. \u0218tiu c\u0103 ai deja mul\u021bi ani de experien\u021b\u0103. Te-am urm\u0103rit \u00een videoclipuri \u0219i am rev\u0103zut unele chiar \u0219i \u00een fragmente\u2026 Hai s\u0103 fim direc\u021bi: de ce avem nevoie de Postgres sau MySQL \u00een K8s?<\/i><\/p>\n

DS<\/b>: Nu exist\u0103 un r\u0103spuns definitiv la aceast\u0103 \u00eentrebare \u0219i nu poate exista. Dar, \u00een general, este vorba despre simplitate \u0219i confort\u2026 poten\u021biale. Toat\u0103 lumea vrea servicii gestionate.<\/p>\n

NS<\/b>: Ca RDS<\/a><\/noindex>, dar la tine acas\u0103?<\/i><\/p>\n

DS<\/b>: Da: ca RDS, dar oriunde.<\/p>\n

NS<\/b>: 'Oriunde' \u2014 acesta este un comentariu bun. \u00cen companiile mari, totul este situat \u00een locuri diferite. De ce, atunci, dac\u0103 este o companie mare, s\u0103 nu alegem o solu\u021bie gata f\u0103cut\u0103? De exemplu, Nutanix are propriile sale dezvolt\u0103ri, iar alte companii (VMware\u2026) \u2014 acela\u0219i 'RDS, dar la tine acas\u0103'.<\/i><\/p>\n

DS<\/b>: Dar vorbim despre o implementare specific\u0103, care va func\u021biona doar \u00een anumite condi\u021bii. Dac\u0103 discut\u0103m despre Kubernetes, aici exist\u0103 o varietate imens\u0103 de infrastructur\u0103 (care poate fi \u00een K8s). Practic, acesta este standardul pentru API-uri c\u0103tre cloud...<\/p>\n

NS<\/b>: \u0218i este gratuit!<\/i><\/p>\n

DS<\/b>: Nu este at\u00e2t de important. Gratuitatea este important\u0103 pentru un segment nu foarte mare al pie\u021bei. Ceea ce conteaz\u0103 cu adev\u0103rat\u2026 Probabil c\u0103 \u00ee\u021bi aminte\u0219ti prezentarea 'Baze de date \u0219i Kubernetes<\/a><\/noindex>\u00bb?<\/p>\n

NS<\/b>: Da.<\/i><\/p>\n

DS<\/b>: Am \u00een\u021beles c\u0103 a fost perceput foarte diferit. O parte din oameni au crezut c\u0103 spun: \u201eHai s\u0103 folosim toate DB-urile \u00een Kubernetes!\u201d, iar al\u021bii au decis c\u0103 sunt doar ni\u0219te biciclete groaznice. Eu voiam s\u0103 spun cu totul altceva: \u201eUita\u021bi-v\u0103, ce se \u00eent\u00e2mpl\u0103, ce probleme sunt \u0219i cum pot fi rezolvate. Este bine s\u0103 folose\u0219ti baze \u00een Kubernetes? Pe mediu de produc\u021bie? Ei bine, doar dac\u0103 \u00ee\u021bi place\u2026 s\u0103 te ocupi de anumite lucruri. Dar pentru dev? Pot spune c\u0103 recomand. Pentru dev, este foarte important\u0103 dinamicitatea cre\u0103rii\/\u0219tergerii mediilor.\u201d<\/p>\n

NS: C\u00e2nd spui dev, te referi la toate mediile care nu sunt prod? Staging, QA\u2026<\/i><\/p>\n

DS<\/b>: Dac\u0103 vorbim despre standuri perf, atunci probabil c\u0103 nu, pentru c\u0103 cerin\u021bele sunt specifice. Dac\u0103 vorbim despre cazuri speciale \u00een care pe staging este necesar\u0103 o baz\u0103 de date foarte mare, atunci de asemenea, probabil c\u0103 nu\u2026 Dac\u0103 este un mediu static, de lung\u0103 durat\u0103, care este beneficiul ca baza s\u0103 fie plasat\u0103 \u00een K8s?<\/p>\n

NS<\/b>: Niciunul. Dar unde vedem medii statice? Mediile statice sunt deja dep\u0103\u0219ite de m\u00e2ine.<\/i><\/p>\n

DS<\/b>: Staging-ul poate fi static. Avem clien\u021bi\u2026<\/p>\n

NS<\/b>: Da, am \u0219i eu. E o mare problem\u0103 dac\u0103 ai o baz\u0103 de 10 TB, iar staging-ul \u2014 200 GB\u2026<\/i><\/p>\n

DS<\/b>: Am un caz foarte interesant! Pe staging se afl\u0103 o baz\u0103 de date de produc\u021bie, \u00een care se fac modific\u0103ri. \u0218i este prev\u0103zut\u0103 o buton: \u201elansare \u00een produc\u021bie\u201d. Aceste modific\u0103ri \u2014 delta \u2014 sunt transmise (se pare, doar prin API se sincronizeaz\u0103) \u00een produc\u021bie. Este o variant\u0103 foarte exotic\u0103.<\/p>\n

NS<\/b>: Am v\u0103zut startup-uri \u00een Valea Siliconului care folosesc RDS sau chiar Heroku \u2014 sunt pove\u0219ti de acum 2-3 ani \u2014 \u0219i descarc\u0103 un dump pe laptopul lor. Pentru c\u0103 baza are doar 80 GB, iar pe laptop este suficient spa\u021biu. Apoi cump\u0103r\u0103 discul fiec\u0103ruia, pentru a avea c\u00e2te 3 baze de date pentru diferite dezvolt\u0103ri. Asta se \u00eent\u00e2mpl\u0103 uneori. De asemenea, am observat c\u0103 nu le este fric\u0103 s\u0103 copieze produc\u021bia \u00een staging \u2014 foarte mult depinde de companie. Dar am v\u0103zut \u0219i c\u0103 le este foarte fric\u0103, iar de multe ori lipsesc timp \u0219i m\u00e2ini. Dar \u00eenainte s\u0103 trecem la acest subiect, vreau s\u0103 aud despre Kubernetes. Am \u00een\u021beles corect c\u0103 \u00een produc\u021bie nu are nimeni \u00eenc\u0103?<\/i><\/p>\n

DS<\/b>: Avem baze mici \u00een produc\u021bie. Vorbim de volume de c\u00e2teva zeci de gigaocte\u021bi \u0219i servicii non-critice, pentru care nu s-au f\u0103cut replici (nu era nevoie). Cu condi\u021bia ca sub Kubernetes s\u0103 existe un stocaj decent. Aceast\u0103 baz\u0103 a func\u021bionat \u00eentr-o ma\u0219in\u0103 virtual\u0103 \u2014 oarecum \u00eentr-un VMware, pe un sistem de stocare. Am pus-o \u00een PV<\/a><\/noindex> \u0219i acum o putem muta de pe ma\u0219in\u0103 pe ma\u0219in\u0103.<\/p>\n

NS<\/b>: Baze de aceast\u0103 dimensiune, de p\u00e2n\u0103 la 100 GB, pe discuri bune \u0219i cu o re\u021bea bun\u0103 pot fi desf\u0103\u0219urate \u00een c\u00e2teva minute, corect? Viteza de 1 GB pe secund\u0103 \u2014 asta nu mai este o excentricitate.<\/i><\/p>\n

DS<\/b>: Da, pentru o opera\u021bie linear\u0103 nu este o problem\u0103.<\/p>\n

NS<\/b>: Ok, despre produc\u021bie ar trebui s\u0103 ne g\u00e2ndim doar. \u0218i dac\u0103 lu\u0103m \u00een considerare Kubernetes pentru medii non-prod \u2014 cum proced\u0103m? V\u0103d c\u0103 \u00een Zalando fac un operator<\/a><\/noindex>, \u00een Crunchy se dezvolt\u0103<\/a><\/noindex>, exist\u0103 \u0219i alte variante. \u0218i exist\u0103 OnGres<\/a><\/noindex> \u2014 acesta este prietenul nostru bun Alvaro din Spania: ei fac de fapt nu doar operator<\/a><\/noindex>, ci un \u00eentreg distribuibil (StackGres<\/a><\/noindex>), \u00een care pe l\u00e2ng\u0103 Postgres am decis s\u0103 includem \u0219i backup-ul, proxy-ul Envoy\u2026<\/i><\/p>\n

DS<\/b>: Envoy pentru ce? \u00cenc\u0103rcarea traficului Postgres?<\/p>\n

NS<\/b>: Da. Asta \u00eenseamn\u0103 c\u0103 ei v\u0103d astfel: dac\u0103 lu\u0103m un sistem de operare Linux \u0219i nucleul, PostgreSQL obi\u0219nuit este nucleul, iar ei vor s\u0103 creeze un sistem de operare care s\u0103 fie prietenos cu norul \u0219i s\u0103 func\u021bioneze \u00een Kubernetes. Asambleaz\u0103 componente (backup-uri etc.) \u0219i le regleaz\u0103 pentru a func\u021biona bine.<\/i><\/p>\n

DS<\/b>: Foarte bine! Practic, acest software este pentru a crea un Postgres gestionat.<\/p>\n

NS<\/b>: Distribu\u021biile Linux au tot timpul probleme: cum s\u0103 creeze driver-e pentru a suporta tot hardware-ul. Iar ei au ideea c\u0103 vor func\u021biona \u00een Kubernetes. \u0218tiu c\u0103 la operatorul Zalando am v\u0103zut recent o leg\u0103tur\u0103 cu AWS \u0219i asta nu este deloc bine. Nu ar trebui s\u0103 existe o leg\u0103tur\u0103 cu o infrastructur\u0103 specific\u0103 \u2014 care ar fi atunci sensul?<\/i><\/p>\n

DS<\/b>: Nu \u0219tiu \u00een ce situa\u021bie s-a legat Zalando, dar \u00een Kubernetes acum, stocarea este f\u0103cut\u0103 astfel \u00eenc\u00e2t nu po\u021bi face backup de disc \u00eentr-un mod generic. Recent, \u00een standardul \u2014 \u00een ultima versiune specifica\u021biei CSI<\/a><\/noindex> \u2014 au f\u0103cut posibilitatea instantaneelor, dar unde este implementat\u0103? Sincer, totul este at\u00e2t de incipient\u2026 \u00cencerc\u0103m CSI peste AWS, GCE, Azure, vSphere, dar c\u00e2nd \u00eencepi s\u0103 folose\u0219ti, devine evident c\u0103 nu este preg\u0103tit.<\/p>\n

NS<\/b>: De aceea trebuie uneori s\u0103 ne leg\u0103m de infrastructur\u0103. Cred c\u0103 suntem \u00eenc\u0103 \u00een faza incipient\u0103 \u2014 probleme de cre\u0219tere. \u00centrebare: ce ai sf\u0103tui pe cei \u00eencep\u0103tori care vor s\u0103 \u00eencerce PgSQL \u00een K8s? Ce operator, poate?<\/i><\/p>\n

DS<\/b>: Problema este c\u0103 Postgres reprezint\u0103 pentru noi doar 3%. Avem o list\u0103 foarte mare de software divers \u00een Kubernetes, nu voi enumera totul. De exemplu, Elasticsearch. Exist\u0103 o mul\u021bime de operatori: unii se dezvolt\u0103 activ, al\u021bii nu. Am stabilit cerin\u021bele noastre despre ce trebuie s\u0103 con\u021bin\u0103 un operator pentru a-l lua \u00een serios. Un operator destinat \u00een mod special Kubernetes \u2014 nu un \u201eoperator care face ceva \u00een condi\u021biile Amazon’ului\u201d\u2026 \u00cen realitate, folosim pe larg (= aproape to\u021bi clien\u021bii) un singur operator \u2014 pentru Redis<\/a><\/noindex> (vom publica \u00een cur\u00e2nd un articol \u0219i despre acesta)<\/i>.<\/p>\n

NS<\/b>: Dar pentru MySQL nu exist\u0103? \u0218tiu c\u0103 Percona\u2026 deoarece acum se ocup\u0103 at\u00e2t de MySQL, c\u00e2t \u0219i de MongoDB \u0219i Postgres, ar trebui s\u0103 creeze un sistem universal: pentru toate bazele de date, pentru to\u021bi furnizorii de cloud.<\/i><\/p>\n

DS<\/b>: Nu am avut timp s\u0103 ne uit\u0103m la operatorii pentru MySQL. Pentru noi, acest lucru nu este un focus principal acum. MySQL func\u021bioneaz\u0103 bine \u00een mod standalone. De ce un operator, dac\u0103 po\u021bi pur \u0219i simplu s\u0103 lansezi DB\u2026 Po\u021bi lansa un container Docker cu Postgres, sau po\u021bi s\u0103-l lansezi simplu.<\/p>\n

NS<\/b>: A fost, de asemenea, o \u00eentrebare despre asta. Chiar f\u0103r\u0103 operator?<\/i><\/p>\n

DS<\/b>: Da, \u00een 100% din cazuri avem PostgreSQL lansat f\u0103r\u0103 operator. A\u0219a stau lucrurile deocamdat\u0103. Folosim activ operatorul pentru Prometheus, pentru Redis. Avem \u00een plan s\u0103 g\u0103sim un operator pentru Elasticsearch - acesta ne<\/p>\n

este cel mai urgent<\/h2>\n

\nNS<\/b>: Hai s\u0103 trecem la subiectul test\u0103rii. Cum s\u0103 implement\u0103m modific\u0103rile \u00een baz\u0103 - din perspectiva DevOps. Exist\u0103 microservicii, multe baze, tot timpul se schimb\u0103 c\u00e2te ceva. Cum asigur\u0103m un CI\/CD normal, astfel \u00eenc\u00e2t din perspectiva SGBD-ului totul s\u0103 fie \u00een regul\u0103. Care este abordarea ta?<\/i><\/p>\n

DS<\/b>: Nu poate exista un singur r\u0103spuns. Exist\u0103 mai mul\u021bi parametri. Primul - este dimensiunea bazei pe care dorim s\u0103 o implement\u0103m. Ai men\u021bionat tu \u00eensu\u021bi c\u0103 \u00een companii se abordeaz\u0103 diferit ideea ca copia bazei prod s\u0103 fie pe dev \u0219i stage.<\/p>\n

NS<\/b>: \u0218i \u00een condi\u021biile GDPR, cred c\u0103 sunt din ce \u00een ce mai aten\u021bi... Pot spune c\u0103 \u00een Europa au \u00eenceput deja s\u0103 impun\u0103 amenzi.<\/i><\/p>\n

DS<\/b>: Dar, adesea, po\u021bi scrie un software care face un dump din produc\u021bie \u0219i \u00eel obfusc\u0103. Rezultatul sunt datele de produc\u021bie (instantanee, dump, copie binar\u0103\u2026), dar acestea sunt anonimizate. \u00cen loc de aceasta, pot fi \u0219i scripturi de generare: pot fi fixture sau pur \u0219i simplu un script care genereaz\u0103 o baz\u0103 de date mare. Problema este: c\u00e2t timp dureaz\u0103 s\u0103 se creeze imaginea de baz\u0103? \u0218i c\u00e2t timp dureaz\u0103 s\u0103 fie desf\u0103\u0219urat\u0103 \u00een mediu?<\/p>\n

Am ajuns la schema: dac\u0103 clientul are un set de date fixture (versiunea minim\u0103 a bazei), atunci folosim acestea implicit. Dac\u0103 este vorba despre medii de review, c\u00e2nd am creat o ramur\u0103, ne-a fost desf\u0103\u0219urat un exemplarul aplica\u021biei - aici desf\u0103\u0219ur\u0103m o baz\u0103 mic\u0103. o variant\u0103<\/a><\/noindex>, c\u00e2nd facem un dump din produc\u021bie o dat\u0103 pe zi (noaptea) \u0219i construim pe baza acestuia un container Docker cu PostgreSQL \u0219i MySQL cu aceste date \u00eenc\u0103rcate. Dac\u0103 din aceast\u0103 imagine trebuie s\u0103 desf\u0103\u0219ur\u0103m baza de date de 50 de ori, acest lucru se face destul de simplu \u0219i rapid.<\/p>\n

NS<\/b>: Printr-o simpl\u0103 copiere?<\/i><\/p>\n

DS<\/b>: Datele sunt stocate direct \u00een imaginea Docker. Adic\u0103 avem o imagine gata, s\u0103 presupunem de 100 GB. Datorit\u0103 straturilor din Docker, putem desf\u0103\u0219ura rapid aceast\u0103 imagine de at\u00e2tea ori c\u00e2t avem nevoie. Metoda este simpl\u0103, dar func\u021bioneaz\u0103 destul de bine.<\/p>\n

NS<\/b>: Apoi, c\u00e2nd testa\u021bi, se schimb\u0103 chiar \u00een interiorul Docker-ului, nu? Copy-on-write \u00een interiorul Docker-ului \u2014 elimin\u0103m \u0219i \u00eencepem din nou, totul e bine. Grozav! \u0218i deja folosi\u021bi asta la maximum?<\/i><\/p>\n

DS<\/b>: De mult.<\/p>\n

NS<\/b>: Ne ocup\u0103m de lucruri foarte asem\u0103n\u0103toare. Doar c\u0103 noi nu folosim copy-on-write-ul Docker-ului, ci altceva.<\/i><\/p>\n

DS<\/b>: Nu este generic. \u00cens\u0103 cel Docker func\u021bioneaz\u0103 peste tot.<\/p>\n

NS<\/b>: Teoretic, da. Dar avem \u0219i module acolo, putem crea diferite module \u0219i lucra cu diferite sisteme de fi\u0219iere. Iat\u0103 un aspect. Ne uit\u0103m la toate acestea din perspectiva Postgres-ului \u00eentr-un mod diferit. Acum, am privit din perspectiva Docker-ului \u0219i am v\u0103zut c\u0103 totul func\u021bioneaz\u0103. Dar dac\u0103 baza de date este uria\u0219\u0103, de exemplu, 1 TB, atunci devine deja totul lent: \u0219i opera\u021biile noaptea, \u0219i stocarea totul \u00een Docker\u2026 \u0218i dac\u0103 trebuie s\u0103 stoc\u0103m 5 TB \u00een Docker\u2026 Sau e totul \u00een regul\u0103?<\/i><\/p>\n

DS<\/b>: Ce diferen\u021b\u0103 face: sunt doar bloburi, pur \u0219i simplu bi\u021bi \u0219i octe\u021bi.<\/p>\n

NS<\/b>: Diferen\u021ba este aceasta: face\u021bi asta prin dump \u0219i restore?<\/i><\/p>\n

DS<\/b>: Deloc obligatoriu. Metodele de generare a acestei imagini pot fi diferite.<\/p>\n

NS<\/b>: Pentru unii clien\u021bi, am f\u0103cut astfel \u00eenc\u00e2t, \u00een loc s\u0103 gener\u0103m periodic imaginea de baz\u0103, s\u0103 o men\u021binem constant actualizat\u0103. Practic, aceasta este o replic\u0103, dar datele nu sunt preluate direct de la master, ci prin arhiv\u0103. O arhiv\u0103 binar\u0103, unde WAL-urile sunt aplicate zilnic, \u0219i unde se fac \u0219i backup-uri... Aceste WAL-uri ajung apoi \u2014 cu o mic\u0103 \u00eent\u00e2rziere (aproape 1-2 secunde) \u2014 la imaginea de baz\u0103. De acolo, clon\u0103m prin orice metod\u0103 \u2014 \u00een prezent, prin ZFS de fapt.<\/i><\/p>\n

DS<\/b>: Dar cu ZFS e\u0219ti restric\u021bionat la un singur nod.<\/p>\n

NS<\/b>: Da. Dar ZFS are \u0219i o magie send<\/a><\/noindex>: cu care po\u021bi trimite un snapshot \u0219i chiar (asta nu am testat foarte mult, dar...) po\u021bi trimite delta \u00eentre dou\u0103 PGDATA<\/code>. De fapt, avem \u0219i un alt instrument pe care nu l-am considerat foarte mult pentru astfel de sarcini. \u00cen PostgreSQL exist\u0103 pg_rewind<\/a><\/noindex>, care func\u021bioneaz\u0103 ca un rsync \u201einteligent\u201d, omite multe lucruri care nu trebuie verificate, pentru c\u0103 acolo clar nu s-au f\u0103cut modific\u0103ri. Putem realiza o sincronizare rapid\u0103 \u00eentre dou\u0103 servere \u0219i putem reveni la starea anterioar\u0103 \u00een acela\u0219i mod.<\/i><\/p>\n

A\u0219adar, \u00eencerc\u0103m din aceast\u0103 parte, mai orientat\u0103 c\u0103tre DBA, s\u0103 cre\u0103m un instrument care permite s\u0103 facem exact ceea ce ai spus: avem o baz\u0103, dar vrem s\u0103 test\u0103m ceva de 50 de ori, aproape simultan.<\/i><\/p>\n

DS<\/b>: 50 de ori \u00eenseamn\u0103 c\u0103 trebuie s\u0103 comanzi 50 de instan\u021be Spot.<\/p>\n

NS<\/b>: Nu, facem totul pe o singur\u0103 ma\u0219in\u0103.<\/i><\/p>\n

DS<\/b>: Dar cum ve\u021bi desf\u0103\u0219ura de 50 de ori, dac\u0103 aceast\u0103 singur\u0103 baz\u0103, s\u0103 zicem, are 1 terabyte? Cel mai probabil, are nevoie de, s\u0103 zicem, 256 GB RAM?<\/p>\n

NS<\/b>: Da, uneori ai nevoie de mult\u0103 memorie \u2014 este normal. Dar un exemplu din via\u021b\u0103. Pe ma\u0219ina de produc\u021bie sunt 96 de nuclee \u0219i 600 GB. \u00cen acela\u0219i timp, pentru baza de date se folosesc 32 de nuclee (chiar \u0219i 16 nuclee uneori) \u0219i o memorie de 100-120 GB.<\/i><\/p>\n

DS<\/b>: \u0218i acolo \u00eencap 50 de copii?<\/p>\n

NS<\/b>: Deci, copia este una, ulterior lucr\u0103m pe copy-on-write (ZFS)... \u00ce\u021bi voi explica mai \u00een detaliu.<\/i><\/p>\n

De exemplu, avem o baz\u0103 de 10 TB. Am creat un disc pentru ea, ZFS i-a comprimare dimensiunea cu aproximativ 30-40%. Deoarece nu facem testare de \u00eenc\u0103rcare, nu ne intereseaz\u0103 timpul de r\u0103spuns exact: poate s\u0103 fie de 2 ori mai lent \u2014 este \u00een regul\u0103.<\/i><\/p>\n

Oferim oportunitatea programatorilor, QA-urilor, DBA-urilor etc. s\u0103 efectueze test\u0103ri \u00een 1-2 fluxuri. De exemplu, pot lansa o migrare. Aceasta nu necesit\u0103 10 nuclee imediat \u2014 \u00eei trebuie un backend Postgres, 1 nucleu. Migrarea se va lansa \u2014 poate, autovacuum<\/a><\/noindex> se va lansa \u00eenc\u0103, atunci se va activa al doilea nucleu. Avem alocate 16-32 nuclee, a\u0219a c\u0103 10 persoane pot lucra simultan, nu sunt probleme.<\/i><\/p>\n

Deoarece fizic PGDATA<\/code> se dovede\u0219te identic\u0103, astfel c\u0103 \u00een\u0219el\u0103m de fapt Postgres. Ideea este aceasta: de exemplu, se lanseaz\u0103 10 Postgres-uri simultan. Care este problema, de obicei? Se instaleaz\u0103 shared_buffers<\/a><\/noindex>, de exemplu, la 25%. Aproape c\u0103 aceasta \u00eenseamn\u0103 200 GB. Nu po\u021bi lansa mai mult de trei astfel de instan\u021be, pentru c\u0103 r\u0103m\u00e2i f\u0103r\u0103 memorie.<\/i><\/p>\n

Dar \u00eentr-un anumit moment am realizat c\u0103 acest lucru nu este necesar: set\u0103m shared_buffers la 2 GB. PostgreSQL are effective_cache_size<\/a><\/noindex>, \u0219i \u00een realitate doar acesta influen\u021beaz\u0103 planurile<\/a><\/noindex>. Acest lucru \u00eel set\u0103m la 0,5 TB. \u0218i nu conteaz\u0103 c\u0103 de fapt nu exist\u0103: el construie\u0219te planuri ca \u0219i cum ar exista.<\/i><\/p>\n

A\u0219adar, c\u00e2nd test\u0103m o migrare, putem aduna toate planurile \u2014 vom vedea cum va decurge pe produc\u021bie. Secundele vor fi diferite (mai lente), dar datele pe care le citim cu adev\u0103rat \u0219i planurile \u00een sine (ce tipuri de JOIN-uri etc.) sunt exact acelea\u0219i ca pe produc\u021bie. \u0218i \u00een paralel, putem lansa numeroase astfel de verific\u0103ri pe o singur\u0103 ma\u0219in\u0103.<\/i><\/p>\n

DS<\/b>: Nu crezi c\u0103 exist\u0103 c\u00e2teva probleme aici? Prima - este o solu\u021bie care func\u021bioneaz\u0103 doar pe PostgreSQL. Aceast\u0103 abordare este foarte specific\u0103, nu este generic\u0103. A doua - Kubernetes (\u0219i tot ce \u00eenseamn\u0103 acum tehnologiile cloud) presupune multe noduri, iar aceste noduri sunt efemere. \u00cen cazul t\u0103u, este un nod stateful, persistent. Aceste lucruri \u00eemi provoac\u0103 contradic\u021bii.<\/p>\n

NS<\/b>: \u00cen primul r\u00e2nd \u2014 sunt de acord, aceasta este pur \u0219i simplu o poveste Postgres. Cred c\u0103, dac\u0103 avem vreo IO direct \u0219i un pool de buffer aproape pe toat\u0103 memoria, aceast\u0103 abordare nu va func\u021biona \u2014 planurile vor fi diferite. Dar momentan lucr\u0103m doar cu Postgres \u0219i nu ne g\u00e2ndim la altele.<\/i><\/p>\n

Despre Kubernetes. Tu \u00eensu\u021bi poveste\u0219ti peste tot c\u0103 baza noastr\u0103 este persistent\u0103. Dac\u0103 instan\u021ba cade, important este s\u0103 salv\u0103m discul. A\u0219adar, \u00eentreaga noastr\u0103 platform\u0103 este \u00een Kubernetes, iar componenta cu Postgres este separat\u0103 (de\u0219i \u0219i aceasta va fi acolo \u00eentr-o zi). Deci, a\u0219a stau lucrurile: instan\u021ba a c\u0103zut, dar am salvat PV-ul ei \u0219i l-am conectat pur \u0219i simplu la o alt\u0103 (nou\u0103) instan\u021b\u0103, de parc\u0103 nimic nu s-ar fi \u00eent\u00e2mplat.<\/i><\/p>\n

DS<\/b>: Din perspectiva mea, cre\u0103m pod-uri \u00een Kubernetes. K8s este elastic: nodurile se comand\u0103 singure pe m\u0103sur\u0103 ce este necesar. Sarcina este pur \u0219i simplu s\u0103 creezi un pod \u0219i s\u0103 spui c\u0103 are nevoie de X resurse, iar K8s se va ocupa de restul. Dar suportul pentru stocare \u00een Kubernetes r\u0103m\u00e2ne \u00een continuare instabil: \u00een 1.16<\/a><\/noindex>, pe 1.17<\/a><\/noindex> (aceast\u0103 versiune a fost lansat\u0103 s\u0103pt\u0103m\u00e2ni<\/i> \u00een urm\u0103) aceste caracteristici devin doar o versiune beta.<\/p>\n

Vor trecere \u0219ase luni sau un an \u2013 va deveni mai mult sau mai pu\u021bin stabil, sau m\u0103car a\u0219a va fi declarat. Atunci op\u021biunea de snapshots \u0219i resize-ul va rezolva complet problema ta. Pentru c\u0103 ai o baz\u0103. Da, aceasta poate s\u0103 nu fie foarte rapid\u0103, dar viteza depinde de ceea ce este \u201esub capot\u0103\u201d, deoarece unele implement\u0103ri pot face copiere \u0219i copy-on-write la nivelul subsistemului de disc.<\/p>\n

NS<\/b>: Aici mai trebuie s\u0103 se \u00eent\u00e2mple ca toate motoarele (Amazon, Google...) s\u0103 \u00eenceap\u0103 s\u0103 suporte aceast\u0103 versiune - \u0219i asta dureaz\u0103 \u0219i ea un timp.<\/i><\/p>\n

DS<\/b>: P\u00e2n\u0103 acum nu le folosim. Folosim al nostru.<\/p>\n

Dezvoltare local\u0103 pe Kubernetes<\/h2>\n

\nNS<\/b>: Te-ai confruntat vreodat\u0103 cu aceast\u0103 dorin\u021b\u0103, c\u00e2nd trebuie s\u0103 ridici toate pod-urile pe aceea\u0219i ma\u0219in\u0103 \u0219i s\u0103 faci un test mic. Pentru a ob\u021bine rapid un proof of concept, s\u0103 vezi c\u0103 aplica\u021bia func\u021bioneaz\u0103 \u00een Kubernetes, f\u0103r\u0103 a aloca o mul\u021bime de ma\u0219ini pentru asta. Exist\u0103 Minikube, nu?<\/i><\/p>\n

DS<\/b>: Mi se pare c\u0103 acest caz \u2014 desf\u0103\u0219urarea pe un singur nod \u2014 este exclusiv despre dezvoltarea local\u0103. Sau despre anumite manifest\u0103ri ale acestui tipar. Exist\u0103 Minikube<\/a><\/noindex>, exist\u0103 k3s<\/a><\/noindex>, teste e2e actualizate.<\/a><\/noindex>. Mergem spre utilizarea Kubernetes \u00een Docker. Acum am \u00eenceput s\u0103 lucr\u0103m cu el pentru teste.<\/p>\n

NS<\/b>: Credeam \u00eenainte c\u0103 este o tentativ\u0103 de a \u00eenveli toate pod-urile \u00eentr-un singur imagine Docker. Dar s-a dovedit c\u0103 este complet altceva. Oricum, sunt containere separate, pod-uri separate \u2013 doar \u00een Docker.<\/i><\/p>\n

DS<\/b>: Da. \u0218i acolo s-a realizat o imita\u021bie destul de amuzant\u0103, dar sensul este acesta\u2026 Avem un utilitar pentru desf\u0103\u0219urare \u2014 werf<\/a><\/noindex>. Vrem s\u0103 facem un mod \u2014 permi\u021b\u00e2ndu-i werf up<\/code>: \u201eRidic\u0103-mi un Kubernetes local\u201d. \u0218i apoi s\u0103 pornim un proces werf follow<\/code>. Atunci dezvoltatorul va putea edita \u00een IDE, iar \u00een sistem se va rula un proces care va detecta modific\u0103rile \u0219i va reconstrui imaginile, redeploy\u00e2ndu-le \u00een K8s local. Astfel vrem s\u0103 \u00eencerc\u0103m s\u0103 rezolv\u0103m problema dezvolt\u0103rii locale.<\/p>\n

Snapshots \u0219i clonarea Bazei de Date \u00een realit\u0103\u021bile K8s<\/h2>\n

\nNS<\/b>: Dac\u0103 ne \u00eentoarcem la copy-on-write. Am observat c\u0103 \u0219i \u00een cloud exist\u0103 snapshots. Ele func\u021bioneaz\u0103 diferit. De exemplu, \u00een GCP: ai un instan\u021b\u0103 de multe terabytes pe coasta de est a SUA. Fac periodic snapshots. Ridici din snapshot o copie a discului pe coasta de vest \u2013 \u00een c\u00e2teva minute este deja totul gata, func\u021bioneaz\u0103 foarte rapid, doar c\u0103 trebuie s\u0103 umpli cache-ul \u00een memorie. Dar aceste clone (snapshots) sunt pentru a \u201eprovisiona\u201d un nou volum. Este grozav c\u00e2nd trebuie s\u0103 creezi multe instan\u021be.<\/i><\/p>\n

Dar pentru teste, mi se pare c\u0103 snapshots-urile despre care vorbe\u0219ti \u00een Docker sau despre care vorbesc eu \u00een ZFS, btrfs \u0219i chiar LVM\u2026 \u2013 acestea permit, de fapt, s\u0103 nu generezi date noi pe o singur\u0103 ma\u0219in\u0103. \u00cen cloud, va trebui s\u0103 pl\u0103te\u0219ti pentru ele de fiecare dat\u0103 \u0219i s\u0103 a\u0219tep\u021bi nu secunde, ci minute (\u0219i \u00een cazul lazy load-ului<\/a><\/noindex>, posibil, ore).<\/i><\/p>\n

\u00cen locul acesta, po\u021bi ob\u021bine aceste date \u00een una-dou\u0103 secunde, s\u0103 rulezi testul \u0219i s\u0103 le arunci. Aceste snapshots rezolv\u0103 diferite sarcini. \u00cen primul caz \u2014 pentru a scala \u0219i a ob\u021bine replici noi, iar \u00een al doilea \u2014 pentru teste.<\/i><\/p>\n

DS<\/b>: Nu sunt de acord. A face o clonare corect\u0103 a volumelor este o sarcin\u0103 pentru cloud. Nu am analizat implementarea lor, dar \u0219tiu cum facem noi pe echipamente. Avem Ceph, prin el putem oric\u0103rei volume fizice (RBD<\/a><\/noindex>) s\u0103 spunem clone<\/i> \u0219i s\u0103 ob\u021binem \u00een zeci de milisecunde a doua volum cu acelea\u0219i caracteristici, IOPS<\/a><\/noindex>\u0219i a\u0219a mai departe. Trebuie s\u0103 \u00een\u021belegem c\u0103 exist\u0103 un copy-on-write ascuns acolo. De ce s\u0103 nu fac\u0103 cloud-ul la fel? Sunt convins c\u0103 ei \u00eencearc\u0103 s\u0103 fac\u0103 acest lucru \u00eentr-un fel sau altul.<\/p>\n

NS<\/b>: Dar tot le vor lua secunde, zeci de secunde, pentru a ridica un instan\u021b, a aduce Docker etc.<\/i><\/p>\n

DS<\/b>: De ce trebuie s\u0103 ridic\u0103m un \u00eentreg instan\u021b? Avem un instan\u021b cu 32 de nuclee, cu 16\u2026 \u0219i \u00een el \u00eencap c\u00e2teva \u2013 de exemplu, patru. C\u00e2nd cerem al cincilea, se va ridica deja un instan\u021b, apoi va fi \u0219ters.<\/p>\n

NS<\/b>: Da, interesant, \u00een Kubernetes se face altfel. La noi baza de date nu este \u00een K8s, ci \u00eentr-un singur instan\u021b. \u00cen schimb, pentru clonarea unei baze de date de mai mul\u021bi terabi\u021bi nu dureaz\u0103 mai mult de dou\u0103 secunde.<\/i><\/p>\n

DS<\/b>: Asta e grozav. Dar mesajul meu ini\u021bial este c\u0103 aceasta nu este o solu\u021bie generic\u0103. Da, este grozav, dar se potrive\u0219te doar cu Postgres \u0219i numai pe un singur nod.<\/p>\n

NS<\/b>: Se potrive\u0219te nu doar pentru Postgres: acestea sunt planurile, a\u0219a cum am spus, vor func\u021biona doar \u00een el. Dar dac\u0103 nu ne intereseaz\u0103 planurile \u0219i avem pur \u0219i simplu nevoie de toate datele pentru testarea func\u021bional\u0103, atunci aceasta se potrive\u0219te pentru orice SGBD.<\/i><\/p>\n

DS<\/b>: Acum mul\u021bi ani am f\u0103cut ceva similar pe snapshots LVM. Este un clasic. Aceast\u0103 abordare a fost folosit\u0103 foarte activ. Doar c\u0103 nodurile stateful sunt o durere. Pentru c\u0103 trebuie s\u0103 nu le l\u0103s\u0103m, \u00eentotdeauna s\u0103 ne amintim de ele\u2026<\/p>\n

NS<\/b>: Nu vezi aici o posibilitate de hibrid? S\u0103 zicem, stateful \u2013 este un pod oarecare, care lucreaz\u0103 cu c\u00e2\u021biva oameni (multe testeri). Avem un volum, dar datorit\u0103 sistemului de fi\u0219iere clonarile sunt locale. Dac\u0103 podul cade, discul r\u0103m\u00e2ne \u2013 se va ridica podul, va citi informa\u021biile despre toate clonele, le va readuce \u00eenapoi \u0219i va spune: \u201eIat\u0103 clonele voastre pe aceste porturi, lucra\u021bi cu ele \u00een continuare\u201d.<\/i><\/p>\n

DS<\/b>: Din punct de vedere tehnic, asta \u00eenseamn\u0103 c\u0103 \u00een cadrul Kubernetes este un singur pod, \u00een interiorul c\u0103ruia lans\u0103m multe Postgres-uri.<\/p>\n

NS<\/b>: Da. Are o limit\u0103: s\u0103 spunem, nu pot lucra simultan mai mult de 10 persoane. Dac\u0103 avem nevoie de 20 \u2013 vom lansa un al doilea astfel de pod. Este complet posibil s\u0103-l clon\u0103m, ob\u021bin\u00e2nd al doilea volum complet, pe care vor fi acelea\u0219i 10 clone \u201esub\u021biri\u201d. Nu vezi o astfel de posibilitate?<\/i><\/p>\n

DS<\/b>: Trebuie s\u0103 ad\u0103ug\u0103m aici \u00eentreb\u0103rile de securitate. Aceast\u0103 variant\u0103 de organizare implic\u0103 faptul c\u0103 acest pod are privilegii \u00eenalte (capabilities), deoarece poate efectua opera\u021biuni non-standard asupra sistemului de fi\u0219iere... Dar repet: cred c\u0103, pe termen mediu, Kubernetes va repara storage-ul, \u00een cloud-uri se va rezolva \u00eentreaga problem\u0103 cu volumele \u2013 totul va \u201efunc\u021biona pur \u0219i simplu\u201d. Va fi resize, clonare\u2026 Exist\u0103 un volum \u2013 spunem: \u201eCreeaz\u0103 unul nou pe baza acestuia\u201d, \u0219i \u00een aproximativ o secund\u0103 primim ceea ce ne trebuie.<\/p>\n

NS<\/b>: Nu cred \u00een o secund\u0103 \u0219i jum\u0103tate pentru multe terabytes. Pe Ceph faci totul tu, iar tu vorbe\u0219ti despre cloud. Du-te \u00een cloud, pe EC2 f\u0103 un clonare a unui volum EBS de multe terabytes \u0219i vezi ce performan\u021b\u0103 va fi. Nu va dura c\u00e2teva secunde. M\u0103 intereseaz\u0103 foarte mult c\u00e2nd vor ajunge la acest indicator. \u00cen\u021beleg despre ce vorbe\u0219ti, dar voi permite s\u0103 nu fiu de acord.<\/i><\/p>\n

DS<\/b>: Ok, dar am spus c\u0103 pe termen mediu, nu pe termen scurt. \u00cen c\u00e2\u021biva ani.<\/p>\n

Despre operatorul pentru PostgreSQL de la Zalando<\/h2>\n

\nLa mijlocul acestei \u00eent\u00e2lniri, s-a al\u0103turat \u0219i Alexey Klyukin, fost dezvoltator de la Zalando, care a povestit despre istoria operatorului PostgreSQL:<\/p>\n

Este grozav c\u0103 aceast\u0103 tem\u0103 a fost adus\u0103 \u00een discu\u021bie: at\u00e2t Postgres, c\u00e2t \u0219i Kubernetes. C\u00e2nd am \u00eenceput s\u0103 lucr\u0103m la asta \u00een Zalando \u00een 2017, era un subiect la care toat\u0103 lumea dorea s\u0103 se implice, dar nimeni nu o f\u0103cea. Toat\u0103 lumea deja avea Kubernetes, dar c\u00e2nd \u00eentrebam cum s\u0103 proced\u0103m cu bazele de date, chiar \u0219i oameni precum Kelsey Hightower<\/a><\/noindex>, care promovau K8s, spuneau cam urm\u0103toarele:<\/p>\n

\u201eMerge\u021bi la servicii gestionate \u0219i folosi\u021bi-le, nu rula\u021bi baze de date \u00een Kubernetes. Altfel, Kubernetes-ul vostru va decide, de exemplu, s\u0103 fac\u0103 o actualizare, va \u00eenchide toate nodurile \u0219i datele voastre vor zbura departe.\u201d<\/i><\/p>\n

Am decis s\u0103 facem un operator care va rula, contrar acestui sfat, baze de date Postgres \u00een Kubernetes. \u0218i aveam un temei bun \u2014 Patroni<\/a><\/noindex>. Aceasta este o solu\u021bie automat\u0103 de failover pentru PostgreSQL, realizat\u0103 corect, adic\u0103 utiliz\u00e2nd etcd, consul sau ZooKeeper ca depozit de informa\u021bii despre cluster. Un astfel de depozit, care va oferi tuturor celor care \u00eentreab\u0103, de exemplu, care este liderul \u00een prezent, aceea\u0219i informa\u021bie - \u00een ciuda faptului c\u0103 avem totul distribuit - pentru a evita split brain-ul. \u00cen plus, am avut o imagine Docker<\/a><\/noindex> pentru acesta.<\/p>\n

\u00cen general, necesitatea unui auto failover pentru companie a ap\u0103rut dup\u0103 migrarea dintr-un data center intern pe hardware \u00een cloud. Cloud-ul a fost bazat pe o solu\u021bie PaaS (Platform-as-a-Service) proprietar\u0103. Este Open Source, dar pentru a-l pune \u00een func\u021biune, a fost nevoie de mult\u0103 munc\u0103. Se numea STUPS<\/a><\/noindex>.<\/p>\n

Ini\u021bial, nu exista niciun Kubernetes. Mai exact, c\u00e2nd a fost desf\u0103\u0219urat\u0103 solu\u021bia proprie, K8s era deja, dar era at\u00e2t de crude, \u00eenc\u00e2t nu era potrivit pentru produc\u021bie. Era, cred, 2015 sau 2016. P\u00e2n\u0103 \u00een 2017, Kubernetes a devenit mai mult sau mai pu\u021bin matur \u2013 a ap\u0103rut necesitatea migra\u021biei acolo.<\/p>\n

\u0218i deja aveam un container Docker. Aveam PaaS care utiliza Docker. De ce s\u0103 nu \u00eencerc\u0103m K8s? De ce s\u0103 nu scriem propriul operator? Murat Kabilov, care s-a al\u0103turat nou\u0103 de la Avito, a \u00eenceput acest proiect din proprie ini\u021biativ\u0103 \u2014 \u201es\u0103 ne juc\u0103m\u201d \u2014 \u0219i proiectul a avut succes.<\/p>\n

Dar de fapt, voiam s\u0103 vorbesc despre AWS. De ce acolo a existat istoric cod legat de AWS\u2026<\/p>\n

C\u00e2nd lansa\u021bi ceva \u00een Kubernetes, trebuie s\u0103 \u00een\u021belege\u021bi c\u0103 K8s este un work in progress. Evolueaz\u0103 constant, se \u00eembun\u0103t\u0103\u021be\u0219te \u0219i, periodic, chiar se stric\u0103. Trebuie s\u0103 fi\u021bi aten\u021bi la toate modific\u0103rile din Kubernetes, s\u0103 fi\u021bi preg\u0103ti\u021bi, \u00een caz de nevoie, s\u0103 v\u0103 \u00eemp\u0103rt\u0103\u0219i\u021bi experien\u021bele \u0219i s\u0103 \u00een\u021belege\u021bi \u00een detaliu cum func\u021bioneaz\u0103 \u2014 poate mai mult dec\u00e2t v-a\u021bi dori. Asta este valabil, \u00een principiu, pentru orice platform\u0103 pe care rula\u021bi bazele de date...<\/p>\n

A\u0219adar, c\u00e2nd am realizat operatorul, aveam Postgres care lucra cu un volum extern (\u00een acest caz \u2014 EBS, deoarece lucram \u00een AWS). Baza de date a crescut, iar la un moment dat a fost necesar s\u0103 facem resize: de exemplu, dimensiunea ini\u021bial\u0103 EBS era de 100 TB, baza a crescut p\u00e2n\u0103 la aceast\u0103 dimensiune, acum vrem s\u0103 facem EBS de 200 TB. Cum? Putem face un dump\/restaurare pe un nou instan\u021b, dar acest proces este lung \u0219i provoac\u0103 downtime.<\/p>\n

De aceea, ne-am dorit un resize care s\u0103 creasc\u0103 parti\u021bia EBS-ului \u0219i apoi s\u0103 spun\u0103 sistemului de fi\u0219iere s\u0103 utilizeze noul spa\u021biu. \u0218i am f\u0103cut asta, dar pe atunci Kubernetes nu avea niciun API pentru opera\u021bia de resize. Deoarece lucram pe AWS, am scris cod pentru API-ul s\u0103u.<\/p>\n

Nimic nu \u00eempiedic\u0103 realizarea aceluia\u0219i lucru pentru alte platforme. \u00cen operator nu exist\u0103 o leg\u0103tur\u0103 care s\u0103 permit\u0103 rularea doar pe AWS, la fel ca pe celelalte, pe care nu va func\u021biona. \u00cen general, acesta este un proiect open source: dac\u0103 cineva dore\u0219te s\u0103 accelereze apari\u021bia utiliz\u0103rii unui nou API \u2014 sunte\u021bi bineveni\u021bi. GitHub<\/a><\/noindex>, pull request-urile \u2014 echipa Zalando se str\u0103duie\u0219te s\u0103 r\u0103spund\u0103 rapid la acestea \u0219i s\u0103 promoveze operatorul. Din c\u00e2te \u0219tiu, proiectul a participat<\/a><\/noindex> la Google Summer of Code \u0219i la alte ini\u021biative asem\u0103n\u0103toare. Zalando lucreaz\u0103 foarte activ la el.\n<\/p><\/blockquote>\n

<\/p>\n

P.S. Bonus!<\/h2>\n

\nDac\u0103 sunte\u021bi interesat de subiectul PostgreSQL \u0219i Kubernetes, v\u0103 aducem aminte c\u0103 s\u0103pt\u0103m\u00e2na trecut\u0103 a avut loc urm\u0103torul Postgres-mar\u021bi, unde a discutat cu Nikolai Alexandr Kukushkin de la Zalando<\/b>. Video-ul este disponibil aici<\/a><\/noindex>.<\/p>\n

P.P.S.<\/h2>\n

\nCiti\u021bi \u0219i \u00een blogul nostru:<\/p>\n