{"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\/et\/blog\/administrirovanie\/postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya","title":{"rendered":"Postgres-teisip\u00e4ev nr 5: \u00abPostgreSQL ja Kubernetes. CI\/CD. Testimise automatiseerimine\u00bb","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Postgres-teisip\u00e4ev
\n
\nEelmisel aastal toimus taas otse\u00fclekanne Venemaa PostgreSQL-i kogukonnast #RuPostgres<\/a><\/noindex>, mille raames r\u00e4\u00e4kis selle kaasasutaja Nikolai Samohvalov Flanti tehnilise direktori Dmitri Stolyaroviga sellest andmebaasis\u00fcsteemist Kubernetes'i kontekstis.<\/p>\n

Avaldame selle arutelu p\u00f5hiosa stenogrammi ning kogukonna YouTube'i kanalil<\/a><\/noindex> on avaldatud t\u00e4ielik videosalvestus:<\/a><\/noindex><\/p>\n

\r\n \"M\u00e4ngi\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Andmebaasid ja Kubernetes<\/h2>\n

\n\u041d\u0421<\/b>: Me ei r\u00e4\u00e4gi t\u00e4na VACUUMist ja CHECKPOINTidest. Soovime r\u00e4\u00e4kida Kubernetesest. Ma tean, et sul on juba palju kogemusi. Olen vaadanud sinu videosid ja m\u00f5ned neist olen isegi osade kaupa uuesti \u00fcle vaadanud\u2026 L\u00e4hme otse asja juurde: miks \u00fcldse Postgres v\u00f5i MySQL K8s-is?<\/i><\/p>\n

\u0414\u0421<\/b>: Sellele k\u00fcsimusele ei ole \u00fchtegi kindlat vastust. Kuid \u00fcldiselt, see on lihtsus ja mugavus\u2026 potentsiaalsed. K\u00f5igile meeldib managed-teenuseid saada.<\/p>\n

\u041d\u0421<\/b>: Kas nagu RDS<\/a><\/noindex>, vaid enda juures?<\/i><\/p>\n

\u0414\u0421<\/b>: Jah: et oleks nagu RDS, aga igal pool.<\/p>\n

\u041d\u0421<\/b>: \"Igal pool\" \u2014 see on hea m\u00e4rkuset. Suurtes ettev\u00f5tetes on k\u00f5ik eraldi kohtades. Aga miks sel juhul, kui see on suur ettev\u00f5te, mitte v\u00f5tta valmis lahendust? N\u00e4iteks Nutanix\u2019il on oma arengud, teistel ettev\u00f5tetel (VMware\u2026) on samuti \"RDS, aga enda juures\".<\/i><\/p>\n

\u0414\u0421<\/b>: Kuid r\u00e4\u00e4gime me siiski \u00fcksikust rakendusest, mis t\u00f6\u00f6tab ainult kindlates tingimustes. Kui jutt on Kubernetes'est, siis siin on tohutu infrastruktuuri mitmekesisus (mis v\u00f5ib K8s-is olla). Sisuliselt on see standard pilve API-le...<\/p>\n

\u041d\u0421<\/b>: Ja veel tasuta!<\/i><\/p>\n

\u0414\u0421<\/b>: See pole nii oluline. Tasuta on t\u00e4htis ainult v\u00e4iksemale turusegmendile. Oluline on midagi muud\u2026 Sa kindlasti m\u00e4letad ettekannet \"Andmebaasid ja Kubernetes<\/a><\/noindex>\u00bb?<\/p>\n

\u041d\u0421<\/b>: Jah.<\/i><\/p>\n

\u0414\u0421<\/b>: Ma sain aru, et seda t\u00f5lgendati v\u00e4ga eri moodi. Osa inimesi m\u00f5tles, et ma \u00fctlen: \u201ePoisid, l\u00e4hme k\u00f5ik andmebaasid Kubernetesesse!\u201c, \u2014 teised j\u00e4lle arvasid, et need on horribles jalgrattad. Aga mina tahtsin \u00f6elda hoopis midagi muud: \u201eVaadake, mis toimub, millised probleemid eksisteerivad ja kuidas neid lahendada. Kas selliste andmebaaside viimine Kubernetesesse? Tootmisele? Ainult siis, kui teile meeldib\u2026 tegeleda teatud asjadega. Ja dev\u2019iga \u2014 v\u00f5in \u00f6elda, et soovitan. Dev\u2019iga on v\u00e4ga oluline keskkondade loomise\/ kustutamise d\u00fcnaamilisus.<\/p>\n

\u041d\u0421: Kas dev\u2019iga sa m\u00f5tled k\u00f5iki keskkondi, mis ei ole prod? Staging, QA\u2026<\/i><\/p>\n

\u0414\u0421<\/b>: Kui r\u00e4\u00e4gime perf-seintidest, siis t\u00f5en\u00e4oliselt mitte, kuna seal on spetsiifilised n\u00f5uded. Kui r\u00e4\u00e4gime erandjuhtudest, kus stagingus on v\u00e4ga suur andmebaas, siis ka t\u00f5en\u00e4oliselt mitte... Kui see on staatiline keskkond, mis elab kaua, siis milline on kasu, kui andmebaas asub K8s-is?<\/p>\n

\u041d\u0421<\/b>: Ei mingit. Aga kus me n\u00e4eme staatilisi keskkondi? Staatiline keskkond on homme juba aegunud.<\/i><\/p>\n

\u0414\u0421<\/b>: Staging v\u00f5ib olla staatiline. Meil on kliente...<\/p>\n

\u041d\u0421<\/b>: Jah, mul on ka. Suur probleem, kui sul on 10 TB andmebaas ja staging \u2014 200 GB...<\/i><\/p>\n

\u0414\u0421<\/b>: Mul on v\u00e4ga \u00e4ge juhtum! Stagingus on prod\u2019iga andmebaas, kuhu tehakse muudatusi. Ja seal on nupp: \u201eviia tootmisse\u201c. Need muudatused \u2014 deltat \u2014 s\u00fcnkroniseeritakse (tundub, et lihtsalt API kaudu) tootmisse. See on v\u00e4ga eksootiline variant.<\/p>\n

\u041d\u0421<\/b>: Olen n\u00e4inud startuppe oru piirkonnas, kes kasutavad RDS\u2019i v\u00f5i isegi Heroku, see on 2-3 aasta tagune lugu, ja nad laadivad endale dumpi s\u00fclekompuutrisse. Sest andmebaas on alles 80 GB, ja s\u00fclekompuutris on ruumi. Siis ostavad nad iga\u00fchele lisadiskid, et omada 3 andmebaasi erinevate arenduste jaoks. Nii ka juhtub. Olen n\u00e4inud, et ei karda tootmist kopeerida stagingusse \u2014 see s\u00f5ltub ettev\u00f5ttest. Aga olen n\u00e4inud ka, et kardetakse v\u00e4ga ja et tihti ei j\u00e4\u00e4 aega ja t\u00f6\u00f6tajaid. Enne kui me selle teema juurde liigume, tahaksin kuulda Kubernetesest. Kas ma saan \u00f5igesti aru, et tootmises pole seda kellestki veel?<\/i><\/p>\n

\u0414\u0421<\/b>: Meil on tootmises m\u00f5ned v\u00e4iksed andmebaasid. R\u00e4\u00e4gime k\u00fcmnete gigabaitide mahust ja mitte kriitilistest teenustest, mille jaoks ei viitsitud replikaid teha (ja vajadus ka puudus). Ja tingimusel, et Kuberneteses on normaalne salvestus. See andmebaas t\u00f6\u00f6tas virtuaalmasinas \u2014 tinglikult VMware\u2019is, salvestuss\u00fcsteemi peal. Me panime selle PV<\/a><\/noindex> ja n\u00fc\u00fcd saame seda masinast masinasse liigutada.<\/p>\n

\u041d\u0421<\/b>: Sellise suurusega, kuni 100 GB andmebaasid, headel ketastel ja hea v\u00f5rgu korral saab eetrisse panna paarik\u00fcmne minutiga, eks? Kiirus 1 GB sekundis \u2014 see ei ole enam eksootika.<\/i><\/p>\n

\u0414\u0421<\/b>: Jah, lineaarse operatsiooni jaoks ei ole see probleem.<\/p>\n

\u041d\u0421<\/b>: Selge, tootmise kohta peame vaid m\u00f5tlema. Aga kui me kaalume Kuberneteset mitte-prod-keskkondade jaoks - kuidas seda teha? N\u00e4en, et Zalando teeb operaatorit<\/a><\/noindex>, Crunchy arendab<\/a><\/noindex>, on veel m\u00f5ned variandid. Ja on OnGres<\/a><\/noindex> \u2014 see on meie hea s\u00f5ber Alvaro Hispaaniast: nad teevad mitte lihtsalt operaatorit<\/a><\/noindex>, vaid tervet distributsiooni (StackGres<\/a><\/noindex>), kuhu lisaks Postgres\u2019ile tahtsime paigutada ka varukoopiad, proxy Envoy\u2026<\/i><\/p>\n

\u0414\u0421<\/b>: Miks on vaja Envoy\u2019d? T\u00e4pselt PostgreSQL\u2019i liikluse tasakaalustamiseks?<\/p>\n

\u041d\u0421<\/b>: Jah. Nad n\u00e4evad seda nii: kui v\u00f5tta Linuxi distributiiv ja tuum, siis tavaline PostgreSQL on tuum, aga nad tahavad teha distributiivi, mis oleks pilvele s\u00f5bralik ja saaks Kuberneteses t\u00f6\u00f6tada. Nad siduvad komponente (varukoopiad jne) ja h\u00e4\u00e4lestavad, et need t\u00f6\u00f6taksid h\u00e4sti.<\/i><\/p>\n

\u0414\u0421<\/b>: T\u00f5eliselt \u00e4ge! Sisuliselt on see tarkvara, et luua oma hallatud PostgreSQL.<\/p>\n

\u041d\u0421<\/b>: Linuxi distributiivide jaoks on igavene probleem: kuidas teha draivereid, et kogu riistvara oleks toetatud. Neil on idee, et nad t\u00f6\u00f6tavad Kuberneteses. Tean, et Zalando operaatoris n\u00e4gime hiljuti seotust AWS-iga ja see ei ole just eriti hea. See ei tohiks s\u00f5ltuda konkreetsest infrastruktuurist \u2014 siis milleks see on?<\/i><\/p>\n

\u0414\u0421<\/b>: Ei tea, milles konkreetselt Zalando seondus, aga Kuberneteses on praegu nii, et salvestus on tehtud niimoodi, et ei saa \u00fcldiselt kettavarukoopiaid teha. Hiljuti viimases versioonis loodi standardile CSI, specifikatsioonide CSI<\/a><\/noindex> \u2014 lisati v\u00f5imalus snapshots\u2019teks, aga kus see on rakendatud? Ausalt \u00f6eldes, see on ikka veel nii toores... Proovime CSI-d AWS, GCE, Azure, vSphere peal, aga kui hakkad kasutama, siis on kohe n\u00e4ha, et see ei ole veel valmis.<\/p>\n

\u041d\u0421<\/b>: Seet\u00f5ttu on vahel kohustuslik s\u00f5ltuda infrastruktuurist. Arvan, et see on ikka varases arenguetapis \u2014 kasvuprobleemid. K\u00fcsimus: mida sa soovitaksid algajatele, kes tahavad proovida PgSQL-i K8s-is? Milline operaator, v\u00f5ib-olla?<\/i><\/p>\n

\u0414\u0421<\/b>: Probleem on see, et Postgres on meie jaoks vaid 3%. Meil on veel suur nimekiri erinevast tarkvarast Kubernetes'is, ei hakka isegi k\u00f5ike loetlema. N\u00e4iteks Elasticsearch. Operaatorite hulk on suur: m\u00f5ned arenevad aktiivselt, teised mitte. Oleme endale seadnud n\u00f5uded, mis peavad operaatoris olema, et me v\u00f5iksime seda t\u00f5siselt v\u00f5tta. Operaator Kubernetes'i jaoks \u2014 mitte \u201eoperaator, et teha midagi Amazonis\u201c... Praktikas kasutame me \u00fcsna massiliselt (= peaaegu k\u00f5igi klientide seas) \u00fchte operaatorit \u2014 Redis\u2019i jaoks<\/a><\/noindex> (varsti avaldame ka artikli selle kohta)<\/i>.<\/p>\n

\u041d\u0421<\/b>: Aga MySQL-i jaoks pole ka? Tean, et Percona... kuna nad tegelevad n\u00fc\u00fcd nii MySQLi, MongoDB kui ka PostgreSQL-iga, peavad nad ju midagi universaalset v\u00e4lja t\u00f6\u00f6tama: k\u00f5igi andmebaaside jaoks, k\u00f5igi pilveteenuse pakkujate jaoks.<\/i><\/p>\n

\u0414\u0421<\/b>: Me ei j\u00f5udnud vaadata MySQL operaatorite peale. Meie jaoks pole see praegu peamine fookus. MySQL t\u00f6\u00f6tab korralikult iseseisvalt. Miks operaator, kui saad lihtsalt andmebaasi k\u00e4ivitada\u2026 Sa saad k\u00e4ivitada Docker konteineri Postrgesiga, v\u00f5i saad selle k\u00e4ivitada lihtsalt.<\/p>\n

\u041d\u0421<\/b>: Sellest oli ka k\u00fcsimus. \u00dcldse ilma operaatorita?<\/i><\/p>\n

\u0414\u0421<\/b>: Jah, meil on 100% PostgreSQL k\u00e4ivitunud ilma operaatorita. Praegu nii. Me kasutame operaatorit aktiivselt Prometheuse ja Redis'e jaoks. Meil on plaanis leida operaator Elasticsearch'i jaoks \u2014 see on k\u00f5ige p\u00f5letavam teema, kuna soovime seda 100% juhtudel Kubernetesesse paigaldada. Nii nagu soovime, et MongoDB oleks ka alati Kuberneteses. Siin tekivad kindlad soovid \u2014 on tunne, et nendes olukordades on midagi teha. PostgreSQL'i osas me isegi ei vaadanud. Loomulikult teame erinevate variantide olemasolust, aga tegelikult on meil iseseisev lahendus.<\/p>\n

Andmebaas testimiseks Kuberneteses<\/h2>\n

\n\u041d\u0421<\/b>: Liigume testimise teema juurde. Kuidas rakendada muudatusi andmebaasis \u2014 DevOps'i perspektiivist. On mikroteenused, palju andmebaase, pidevalt kuskil midagi muutub. Kuidas tagada normaalne CI\/CD, et andmebaasi poolest oleks k\u00f5ik korras. Mis on sinu l\u00e4henemine?<\/i><\/p>\n

\u0414\u0421<\/b>: \u00dchte vastust ei saa olla. On mitu parameetrit. Esiteks, kui suur on andmebaas, mida soovime rakendada. Sa ise mainisid, et ettev\u00f5ttes on erinevad l\u00e4henemised, kuidas prod-andmebaasi koopia olla dev- ja stage'is.<\/p>\n

\u041d\u0421<\/b>: GDPR-i tingimustes, ma arvan, nad on j\u00e4rjest ettevaatlikumad... V\u00f5in \u00f6elda, et Euroopas on juba alustanud trahvimist.<\/i><\/p>\n

\u0414\u0421<\/b>: Aga tihti on v\u00f5imalik kirjutada tarkvara, mis teeb dump'i tootmisest ja obfuskab selle. Saame tootmisandmed (snapshot, dump, binaarne koopia\u2026), kuid need on anon\u00fc\u00fcmsed. Selle asemel v\u00f5ivad olla ka genereerimisk\u00e4sud: need v\u00f5ivad olla fikstuurid v\u00f5i lihtsalt skript, mis genereerib suure andmebaasi. Probleem on selles: kui kaua kulub p\u00f5hi\u00fche loomine? Ja kui kaua kulub selle k\u00e4itamine vajalikus keskkonnas?<\/p>\n

Oleme j\u00f5udnud skeemile: kui kliendil on fikstuuri andmekogum (minimaalne versioon andmebaasist), siis kasutame neid vaikimisi. Kui asi puudutab \u00fclevaatekeskkondi, kui oleme loonud haru, meie rakenduse eksemplar k\u00e4ivitub \u2014 me paneme sinna v\u00e4ikese andmebaasi. Aga see tuli h\u00e4sti v\u00e4lja ning variant<\/a><\/noindex>, kui v\u00f5tame tootmisest dump'i korra p\u00e4evas (\u00f6\u00f6siti) ja kogume selle p\u00f5hjal Docker'i konteineri PostgreSQL'i ja MySQL'iga koos nende laaditud andmetega. Kui sellest pildist on vaja 50 korda andmebaasi k\u00e4ivitada, siis saab seda teha \u00fcsna lihtsalt ja kiirelt.<\/p>\n

\u041d\u0421<\/b>: Lihtsa kopeerimisega?<\/i><\/p>\n

\u0414\u0421<\/b>: Andmed salvestatakse otse Docker-pildis. St meil on valmis pilt, olgu see 100 GB. T\u00e4nu Docker'i kihtidele saame seda pilti kiiresti vajalikul hulgal arendada. Meetod on primitiivne, kuid t\u00f6\u00f6tab h\u00e4sti.<\/p>\n

\u041d\u0421<\/b>: Edasi, kui testite, kas see muutub otse Docker'is, eks? Copy-on-write Docker'is \u2014 viskame v\u00e4lja ja alustame uuesti, k\u00f5ik on h\u00e4sti. Lahe! Ja kasutate seda juba t\u00e4ies mahus?<\/i><\/p>\n

\u0414\u0421<\/b>: Juba pikka aega.<\/p>\n

\u041d\u0421<\/b>: Tegeleme v\u00e4ga sarnaste asjadega. Ainult et me ei kasuta Docker'i copy-on-write'i, vaid m\u00f5nda muud.<\/i><\/p>\n

\u0414\u0421<\/b>: Ta ei ole generic. Kuid Docker'i oma t\u00f6\u00f6tab igal pool.<\/p>\n

\u041d\u0421<\/b>: Ideaalis jah. Aga meil on seal ka moodulid, saate teha erinevaid mooduleid ja t\u00f6\u00f6tada erinevate failis\u00fcsteemidega. Siin on \u00fcks punkt. Me vaatame PostgreSQL'i poolt k\u00f5ike seda teistsuguse pilguga. N\u00fc\u00fcd olen vaadanud Docker'i poolt ja n\u00e4inud, et teil k\u00f5ik t\u00f6\u00f6tab. Aga kui andmebaas on tohutu, n\u00e4iteks 1 TB, siis see juba kestab kaua: nii \u00f6ised operatsioonid kui ka k\u00f5ik Docker'i panemine\u2026 Aga kui 5 TB paneb Docker'i\u2026 V\u00f5i on k\u00f5ik normaalne?<\/i><\/p>\n

\u0414\u0421<\/b>: Mis vahet seal on: need on ju blob'id, lihtsalt bitid ja baitid.<\/p>\n

\u041d\u0421<\/b>: Vahe on selline: teete seda dump'i ja restore'iga?<\/i><\/p>\n

\u0414\u0421<\/b>: \u00dcldse ei pea. Selle pildi genereerimise meetodid v\u00f5ivad olla erinevad.<\/p>\n

\u041d\u0421<\/b>: M\u00f5nedel klientidel oleme seadnud nii, et regulaarsest p\u00f5hiv\u00e4\u00e4rise genereerimisest asemel hoiame seda pidevalt ajakohasena. See on sisuliselt replika, kuid andmed ei tule otse meistrist, vaid kausta. Binaarkood, kuhu WAL’id kantakse kokku iga p\u00e4ev, seal tehakse ka varukoopiad... Need WAL’id lendavad hiljem \u2014 v\u00e4ikese viivitusega (t\u00f5eliselt 1-2 sekundit) \u2014 p\u00f5hiv\u00e4\u00e4rise juurde. Sealt kopeerime me igasuguste meetoditega \u2014 meil on vaikimisi ZFS.<\/i><\/p>\n

\u0414\u0421<\/b>: Kuid ZFS-i puhul olete piiratud \u00fche s\u00f5lmega.<\/p>\n

\u041d\u0421<\/b>: Jah. Kuid ZFS-il on ka maagiline send<\/a><\/noindex>: selle abil saab saata snapshots ja isegi (ma ei ole seda veel v\u00e4ga testinud, kuid\u2026) saab edasi saata deltat kahe vahel PGDATA<\/code>. Tegelikult on meil veel \u00fcks t\u00f6\u00f6riist, mida me ei ole selliste \u00fclesannete jaoks eriti vaadanud. PostgreSQL-is on pg_rewind<\/a><\/noindex>, t\u00f6\u00f6tades nagu \u201enutikas\u201d rsync, j\u00e4ttes vahele palju, mida pole vaja vaadata, sest seal pole t\u00f5eliselt midagi muutunud. Saame kahe serveri vahel kiiresti s\u00fcnkroonida ja tagasi kerida t\u00e4pselt samamoodi.<\/i><\/p>\n

Nii et p\u00fc\u00fcame seda, DBA’le l\u00e4htuvalt, teha t\u00f6\u00f6riista, mis laseb teha samu asju, millest sa r\u00e4\u00e4kisid: meil on \u00fcks andmebaas, kuid tahame midagi 50 korda testida, peaaegu samal ajal.<\/i><\/p>\n

\u0414\u0421<\/b>: 50 korda t\u00e4hendab, et peate tellima 50 Spot’instantsi.<\/p>\n

\u041d\u0421<\/b>: Ei, teeme k\u00f5ik \u00fchel masinal.<\/i><\/p>\n

\u0414\u0421<\/b>: Aga kuidas te juurutate 50 korda, kui see \u00fcks andmebaas on, \u00fctleme, terabaidi suurune? T\u00f5en\u00e4oliselt vajab see umbes 256 GB RAM-i?<\/p>\n

\u041d\u0421<\/b>: Jah, m\u00e4lu vajatakse m\u00f5nikord palju \u2014 see on normaalne. Kuid selline n\u00e4ide elust. Tootmismasinal on 96 tuuma ja 600 GB. Samas andmebaasi jaoks kasutatakse 32 tuuma (isegi 16 tuuma n\u00fc\u00fcd m\u00f5nikord) ja m\u00e4lu 100-120 GB.<\/i><\/p>\n

\u0414\u0421<\/b>: Kas sinna mahub 50 koopiat?<\/p>\n

\u041d\u0421<\/b>: Niisiis, koopiad on \u00fcks, p\u00e4rast t\u00f6\u00f6tab copy-on-write (ZFS’ne)... R\u00e4\u00e4gin l\u00e4hemalt.<\/i><\/p>\n

Meil on n\u00e4iteks 10 TB andmebaas. Disk selle jaoks tehtud, ZFS veel tihendas selle suurust 30-40 protsendi v\u00f5rra. Kuna me ei tee koormustestimist, ei ole meil t\u00e4pset reageerimisaega oluline: olgu see kuni 2 korda aeglasem \u2014 see on okei.<\/i><\/p>\n

Anname v\u00f5imaluse programmeerijatele, QA, DBA ja teistele testida 1-2 l\u00f5imes. N\u00e4iteks nad saavad k\u00e4ivitada mingit migratsiooni. See ei n\u00f5ua kohe 10 tuuma \u2014 vajab 1 Postgres’ backendi, 1 tuuma. Migratsioon k\u00e4ivitub \u2014 v\u00f5ib-olla, autovacuum<\/a><\/noindex> k\u00e4ivitub veel, siis kasutatakse teist tuuma. Meil on eraldatud 16-32 tuuma, nii et 10 inimest saavad samal ajal t\u00f6\u00f6tada, probleeme pole.<\/i><\/p>\n

Kuna f\u00fc\u00fcsiliselt PGDATA<\/code> kui see on t\u00e4iesti sama, kuidas me Postgres’ile tegelikult petame. Asi on selles: n\u00e4iteks k\u00e4ivitame 10 Postgres’i samaaegselt. Milline probleem on tavaliselt? Paneme shared_buffers<\/a><\/noindex>, oletame, 25% suuruseks. Seega on see 200 GB. Rohkem kui kolm sellist juba ei k\u00e4ivita, sest m\u00e4lu l\u00f5peb.<\/i><\/p>\n

Aga m\u00f5nes hetkes m\u00f5istsime, et see ei ole vajalik: seame shared_buffers 2 GB peale. PostgreSQL-il on effective_cache_size<\/a><\/noindex>, ja tegelikult m\u00f5jutab ainult see plaane<\/a><\/noindex>. Seega seadistame selle 0,5 TB-ks. Ja isegi ei ole oluline, et neid tegelikult ei ole: ta koostab plaane, nagu need oleksid olemas.<\/i><\/p>\n

Vastavalt, kui testime mingit migratsiooni, saab k\u00f5ik plaanid kokku koguda \u2014 me n\u00e4eme, kuidas see toimub tootmisprotsessis. Seal on teised sekundid (aeglased), kuid andmed, mida me reaalselt loeme, ja ise plaanid (millised JOIN’id jne) on t\u00e4pselt samad nagu tootmises. Ja samaaegselt saab k\u00e4ivitada suure hulga selliseid kontrolle \u00fchel masinal.<\/i><\/p>\n

\u0414\u0421<\/b>: Kas sa ei arva, et siin on m\u00f5ned probleemid? Esiteks \u2014 see lahendus t\u00f6\u00f6tab ainult PostgreSQL'is. Selline l\u00e4henemine on v\u00e4ga spetsiifiline, mitte \u00fcldine. Teiseks \u2014 Kubernetes (ja k\u00f5ik, kuhu t\u00e4nap\u00e4eval piloodid l\u00e4hevad) eeldab palju s\u00f5lmi, ja need s\u00f5lmed on efemeersed. Ent sinu puhul on see stateful, p\u00fcsiv s\u00f5lm. Need asjad tekitavad minus vastuolusid.<\/p>\n

\u041d\u0421<\/b>: Esiteks \u2014 n\u00f5ustun, see on puhtalt Postgres’ vahel. Arvan, et kui meil on mingisugune otse IO ja puhverpesa peaaegu kogu m\u00e4lu ulatuses, siis see l\u00e4henemine ei sobi \u2014 plaanid on erinevad. Kuid hetkel t\u00f6\u00f6tame ainult Postgres’iga, teistega ei m\u00f5tle.<\/i><\/p>\n

Kubernetese kohta. Sa ise r\u00e4\u00e4gid, et meie andmebaas on p\u00fcsiv. Kui instants kukub, on peamine s\u00e4ilitada ketas. Meie platvorm on samuti Kubernetesis, kuid PostgreSQL'i komponent on eraldi (kuigi ka see kunagi sinna tuleb). Seet\u00f5ttu on asi nii: instants kukkus, kuid meie s\u00e4ilitasime selle PV ja lihtsalt \u00fchendasime uue instantsi nagu poleks midagi juhtunud.<\/i><\/p>\n

\u0414\u0421<\/b>: Minu seisukohalt loome pod’e Kuberneteses. K8s \u2014 fleksiaalne: s\u00f5lmed tellitakse iseseisvalt vastavalt vajadusele. \u00dclesanne \u2014 lihtsalt luua pod ja \u00f6elda, mida X ressursse on vaja, ning edasi K8s teab ise, kuidas sellega hakkama saada. Kuid salvestustoe toetus Kuberneteses j\u00e4\u00e4b endiselt ebastabiilseks: 1.16<\/a><\/noindex>, in 1.17<\/a><\/noindex> (see versioon ilmus n\u00e4dalat<\/i> tagasi) need funktsioonid on alles beetaversioonis.<\/p>\n

Pool aasta v\u00f5i rohkem \u2014 see muutub enam-v\u00e4hem stabiilseks v\u00f5i v\u00e4hemalt kuulutatakse seda selliseks. Siis lahendab v\u00f5imalus snapshootide ja resize’iga teie \u00fclesande t\u00e4ielikult. Sest teil on baas. Jah, see ei pruugi olla eriti kiire, aga kiirus s\u00f5ltub sellest, mis on \"kapoti all\", sest m\u00f5ned teostused oskavad kopeerida ja copy-on-write tasandil kettas\u00fcsteemis.<\/p>\n

\u041d\u0421<\/b>: Siin peab ka olema, et k\u00f5ik mootorid (Amazon, Google\u2026) oleksid suutnud hakata seda versiooni toetama \u2014 see v\u00f5tab samuti aega.<\/i><\/p>\n

\u0414\u0421<\/b>: Seni me neid ei kasuta. Me kasutame oma.<\/p>\n

Kohalik arendus Kubernetese all<\/h2>\n

\n\u041d\u0421<\/b>: Kas oled kunagi kokku puutunud sellise sooviga, et on vaja \u00fchel masinal k\u00f5ik pod’id \u00fcles t\u00f5sta ja teha selline v\u00e4ike testimine. Et kiiresti t\u00f5estada kontseptsioon, vaadata, kas rakendus t\u00f6\u00f6tab Kuberneteses, mitte eraldades selleks hunnikut masinatest. On olemas Minikube, eks?<\/i><\/p>\n

\u0414\u0421<\/b>: Tundub, et see juhtum \u2014 \u00fchel s\u00f5lmel k\u00e4ivitamine \u2014 on puhtalt kohalike arenduste jaoks. V\u00f5i mingid sellised ilmingud. On Minikube<\/a><\/noindex>, on k3s<\/a><\/noindex>, KIND<\/a><\/noindex>. Me liigume suunas, et hakkame Kuberneteset Dockeris kasutama. Oleme n\u00fc\u00fcd hakanud sellega testimiseks t\u00f6\u00f6tama.<\/p>\n

\u041d\u0421<\/b>: Varem arvasin, et see on katse panna k\u00f5ik pod’id \u00fchte Docker-pilti. Kuid selgus, et see on hoopis millegi muu kohta. Seal on ikkagi eraldi konteinerid, eraldi pod’id \u2014 lihtsalt Docker’is.<\/i><\/p>\n

\u0414\u0421<\/b>: Jah. Seal on p\u00e4ris naljakas imitatsioon, aga idee on selline... Meil on deployment'i utiliit \u2014 werf<\/a><\/noindex>. Taha, et teeksime seal re\u017eiimi \u2014 \u00fctleme, werf up<\/code>: \"T\u00f5sta mulle kohalik Kubernetes \u00fcles\". Ja seej\u00e4rel k\u00e4ivitada seal tingimuslik werf follow<\/code>. Siis saab arendaja IDE's redigeerida, ja s\u00fcsteemis t\u00f6\u00f6tab protsess, mis n\u00e4eb muudatusi ja ehitab pildid uuesti ning deponeerib need kohalikku K8s-i. Nii soovime proovida lahendada kohaliku arenduse probleemi.<\/p>\n

Snapshotid ja andmebaasi kloonimine K8s-i tingimustes<\/h2>\n

\n\u041d\u0421<\/b>: Kui tagasi minna copy-on-write\u2019i juurde. Olen m\u00e4rganud, et ka pilvedel on snapshootid. Need t\u00f6\u00f6tavad erinevalt. N\u00e4iteks GCP-s: sul on Ameerika \u00dchendriikide idaosas mitme terabaidi suurune instants. Teed perioodiliselt snapshootid. T\u00f5stad snapshootist kettakopi L\u00e4\u00e4ne-Ameerika \u00dchendriikidesse \u2014 m\u00f5ne minutiga on k\u00f5ik valmis, see t\u00f6\u00f6tab v\u00e4ga kiiresti, lihtsalt vahem\u00e4lu tuleb m\u00e4lu t\u00e4ita. Kuid need kloonid (snapshootid) \u2014 on selleks, et \"provision\u2018ida\" uus maht. See on \u00e4ge, kui on vajadus luua palju instantsse.<\/i><\/p>\n

Aga testide jaoks, tundub mulle, et snapshootid, millest sa r\u00e4\u00e4gid Docker\u2019is v\u00f5i millest mina r\u00e4\u00e4gin ZFS-is, btrfs-is ja isegi LVM-is\u2026 \u2014 need v\u00f5imaldavad saavutada, et \u00fchel masinal ei oleks tegelikult uusi andmeid. Pilves pead sa neid iga kord eest maksma ja ootama juba mitte sekundeid, vaid minuteid (ja juhul lazy load’ist<\/a><\/noindex>, v\u00f5ib-olla isegi tunde).<\/i><\/p>\n

Selle asemel saad sekundi-kahega need andmed, jookse test l\u00e4bi ja viska need minema. Need snapshotid lahendavad erinevaid \u00fclesandeid. Esimesel juhul \u2014 et skaleerida ja saada uusi replikaate, teisel \u2014 testideks.<\/i><\/p>\n

\u0414\u0421<\/b>: Ma ei n\u00f5ustu. H\u00e4sti toimiva mahutite kloonimise tegemine on pilve \u00fclesanne. Ma ei ole nende teostust vaadanud, aga tean, kuidas me seda riistvaral teeme. Meil on Ceph, milles v\u00f5ib igale f\u00fc\u00fcsilisele mahutile (RBD<\/a><\/noindex>) \u00f6elda clone<\/i> ja saada m\u00f5ne k\u00fcmne millisekundi jooksul teine maht sama iseloomuga, IOPS<\/a><\/noindex>‘ide jne. Peab aru saama, et seal on sees keeruline copy-on-write. Miks pilv ei v\u00f5iks sama teha? Olen kindel, et nad \u00fchel v\u00f5i teisel viisil p\u00fc\u00fcavad seda teha.<\/p>\n

\u041d\u0421<\/b>: Kuid neil l\u00e4hevad ikkagi sekundid, k\u00fcmned sekundid, et instants \u00fcles t\u00f5sta, Docker sinna tuua jne.<\/i><\/p>\n

\u0414\u0421<\/b>: Miks peab tingimata \u00fcles t\u00f5stma terve instantsi? Meil on ju instants 32 tuuma, 16... ja sellesse mahub teatud arv \u2014 n\u00e4iteks neli. Kui tellime viienda, siis t\u00f5useb instants ja siis kustutatakse see.<\/p>\n

\u041d\u0421<\/b>: Jah, huvitav, Kuberneteses on lugu teistsugune. Meie andmebaas ei ole K8s-is ja meil on \u00fcks instants. Kuid mitme terabaidi andmebaasi kloonimiseks kulub mitte rohkem kui kaks sekundit.<\/i><\/p>\n

\u0414\u0421<\/b>: See on \u00e4ge. Aga minu algne m\u00f5te on see, et see ei ole \u00fcldine lahendus. Jah, see on kaunis, kuid sobib ainult Postgres\u2019ile ja ainult \u00fches s\u00f5lmest.<\/p>\n

\u041d\u0421<\/b>: See sobib mitte ainult Postgres\u2019ile: need plaanid, nagu ma kirjeldasin, t\u00f6\u00f6tavad nii ainult seal. Kuid kui plaanide p\u00e4rast ei muretse, vaid vajame lihtsalt k\u00f5iki andmeid funktsionaalseks testimiseks, siis sobib see iga andmebaassi jaoks.<\/i><\/p>\n

\u0414\u0421<\/b>: Palju aastaid tagasi tegime sarnast LVM-snap\u0161ottidega. See on klassika. Sellist l\u00e4henemist kasutati v\u00e4ga aktiivselt. Lihtsalt stateful s\u00f5lmed \u2014 see on valu. Sest neid ei tohi kukutada, neist tuleb alati meeles pidada...<\/p>\n

\u041d\u0421<\/b>: Kas sa ei n\u00e4e siin mingit h\u00fcbriidi v\u00f5imalust? Oletame, et stateful on mingi pod, see t\u00f6\u00f6tab mitme inimese peal (palju testijaid). Meil on \u00fcks maht, aga t\u00e4nu failis\u00fcsteemile on kloonid \u2014 kohalikes. Kui pod kukub, j\u00e4\u00e4b kettale j\u00e4rgi \u2014 pod t\u00f5useb \u00fcles, loeb k\u00f5igi kloonide teavet, t\u00f5stab k\u00f5ik tagasi ja \u00fctleb: \u201eSiin on teie kloonid nende portides, t\u00f6\u00f6tage nendega edasi.\u201d<\/i><\/p>\n

\u0414\u0421<\/b>: Tehniliselt t\u00e4hendab see, et Kuberneteses on see \u00fcks pod, mille sees me k\u00e4ivitame palju Postgres’eid.<\/p>\n

\u041d\u0421<\/b>: Jah. Tal on piir: oletame, et samal ajal t\u00f6\u00f6tavad temaga mitte rohkem kui 10 inimest. Kui on vaja 20 \u2014 k\u00e4ivitame teise sellise podi. T\u00e4iesti on v\u00f5imalik, et kloonime selle, saades teise t\u00e4is mahu, millel on samad 10 \u201e\u00f5hukest\u201d klooni. Kas sa ei n\u00e4e sellist v\u00f5imalust?<\/i><\/p>\n

\u0414\u0421<\/b>: Tuleks lisada siia turvak\u00fcsimused. Selline organisatsiooni variant eeldab, et sellel pod'il on k\u00f5rged privileegid (capabilities), kuna see suudab teostada ebatavalisi toiminguid failis\u00fcsteemiga\u2026 Kuid ma kordaksin: usun, et keskmises plaanis viib Kubernetes storage'i korda, pilves k\u00f5rvaldatakse k\u00f5ik mahutite probleemid \u2013 k\u00f5ik hakkab \u201elihtsalt toimima\u201c. Ootame resize'i, kloonimist\u2026 On mahuti \u2013 me \u00fctleme: \u201eLoo uus selle p\u00f5hjal,\u201c \u2013 ja poolteise sekundi p\u00e4rast saame, mida vajame.<\/p>\n

\u041d\u0421<\/b>: Ma ei usu, et paljude terabaitide puhul on poolteist sekundit v\u00f5imalik. Cephis teed ise, aga r\u00e4\u00e4gid pilvedest. Mine pilve, tee EC2-s kloon EBS mahust paljude terabaitide ulatuses ja vaata, milliseks j\u00f5udluseks see muutub. See ei kesta paar sekundit. Mind huvitab, millal nad sellise tasemeni j\u00f5uavad. Ma saan aru, millisest sa r\u00e4\u00e4gid, aga luban endal mitte n\u00f5ustuda.<\/i><\/p>\n

\u0414\u0421<\/b>: Okei, aga ma \u00fctlesin, et keskpikas perspektiivis, mitte l\u00fchikese. Paari aasta jooksul.<\/p>\n

Zalando PostgreSQL operaatori kohta<\/h2>\n

\nSelle kohtumise keskpaiku liitus temaga ka Aleksei Kljukin, endine arendaja Zalando\u2019st, kes r\u00e4\u00e4kis PostgreSQL operaatori ajaloost:<\/p>\n

Hea, et see teema \u00fcldse \u00fcles kerkis: nii Postgres kui Kubernetes. Kui me alustasime selle loomist Zalando's 2017. aastal, oli see teema, mille eest k\u00f5ik soovisid tegeleda, kuid keegi ei teinud. K\u00f5igil hakkas Kubernetes tekkima, aga kui k\u00fcsiti, kuidas andmebaasidega olla, siis isegi sellised inimesed nagu Kelsey Hightower<\/a><\/noindex>, kes propageerisid K8s-i, \u00fctlesid umbes j\u00e4rgmist:<\/p>\n

\u201eMinge haldusteenustele ja kasutage neid, \u00e4rge k\u00e4itage DB-d Kuberneteses. Muul juhul otsustab teie K8s n\u00e4iteks teha uuenduse, sulgeb k\u00f5ik s\u00f5lmed ja teie andmed l\u00e4hevad kaugele- kaugele.\u201d<\/i><\/p>\n

Me otsustasime teha operaatori, mis vastupidiselt sellele n\u00f5uandele k\u00e4ivitab PostgreSQL andmebaasi Kuberneteses. Ja meil oli hea alus - Patronit<\/a><\/noindex>. See on automaatne failover PostgreSQL'ile, mis on tehtud \u00f5igesti, st kasutades etcd, consul v\u00f5i ZooKeeper'i klastriteabe salvestamiseks. Selline salvestus, mis edastab k\u00f5igile, kes k\u00fcsivad, n\u00e4iteks, kes on praegune juht, sama teabe \u2014 hoolimata meie jagatud loomusest \u2014 et v\u00e4ltida split brain'i. Pluss, meil oli Docker-ima<\/a><\/noindex> selle jaoks.<\/p>\n

\u00dcldiselt tekkis vajadus automaatse failover'i j\u00e4rele ettev\u00f5ttes p\u00e4rast migratsiooni seestpoolt raudvarakeskusesse pilve. Pilv p\u00f5hines omaenda PaaS (Platform-as-a-Service) lahendusel. See on avatud l\u00e4htekoodiga, kuid selle \u00fclesseadmiseks tuli k\u00f5vasti vaeva n\u00e4ha. Nimi oli STUPS<\/a><\/noindex>.<\/p>\n

Alguses ei olnud mingit Kubernetes'e. T\u00e4psemalt, kui oma lahendust \u00fcles seab, siis K8s juba eksisteeris, kuid oli nii toore, et tootmises ei sobinud. See oli minu m\u00e4letamist m\u00f6\u00f6da 2015. v\u00f5i 2016. aasta. 2017. aastaks oli Kubernetes muutunud enam-v\u00e4hem k\u00fcpseks \u2013 tekkis vajadus sinna migreerimise j\u00e4rele.<\/p>\n

Ja meil oli juba Docker-konteiner. Oli PaaS, mis kasutas Dockerit. Miks mitte proovida K8s? Miks mitte kirjutada oma operaator? Murat Kabilov, kes tuli meie juurde Avitost, alustas seda projekti isikliku algatuse p\u00f5hjal \u2014 \"m\u00e4ngimiseks\" \u2014 ja projekt \"lendas\".<\/p>\n

Aga tegelikult tahtsin ma r\u00e4\u00e4kida AWS-ist. Miks seal oli ajalooliselt kood, mis oli seotud AWS-iga\u2026<\/p>\n

Kui te k\u00e4ivate oma midagi Kubernetes'es, peate m\u00f5istma, et K8s on t\u00f6\u00f6 k\u00e4igus. See areneb pidevalt, t\u00e4iustatakse ja perioodiliselt isegi puruneb. Tuleb hoolikalt j\u00e4lgida k\u00f5iki muudatusi Kubernetes'es, olla valmis s\u00fcvenema ja v\u00e4lja selgitama, kuidas see detailides t\u00f6\u00f6tab \u2014 v\u00f5ib-olla rohkem, kui sooviksite. See on p\u00f5him\u00f5tteliselt igal platvormil, millel te oma andmebaase k\u00e4itate\u2026<\/p>\n

Nii et kui me tegime operaatorit, oli meil Postgres, mis t\u00f6\u00f6tas v\u00e4lise mahuga (antud juhul \u2014 EBS, kuna me tegutsesime AWS-is). Andmebaas kasvas, ja mingil hetkel tuli teha resize: n\u00e4iteks, algne EBS suurus \u2014 100 Tb, andmebaas j\u00f5udis selleni, n\u00fc\u00fcd tahame EBS-i 200 Tb. Kuidas? Oletame, et v\u00f5ib teha dump\/restore uuele instantsile, kuid see on aeglane ja aeglane.<\/p>\n

Seet\u00f5ttu tahtsime sellist resize'i, mis suurendaks EBS'i partitsiooni ja seej\u00e4rel \u00fctleks failis\u00fcsteemile kasutada uut ruumi. Ja me tegime seda, kuid toona ei olnud Kubernetes'el mingit API'd resize'ide tegemiseks. Kuna t\u00f6\u00f6tasime AWS'is, kirjutasime koodi selle API jaoks.<\/p>\n

Keegi ei takista sama teha teiste platvormide jaoks. Operaatoril ei ole s\u00f5ltuvust, et seda saab k\u00e4itada ainult AWS-is, v\u00f5i et see ei t\u00f6\u00f6ta mujal. \u00dches\u00f5naga, see on avatud allikaga projekt: kui kellegil on soov kiirendada uue API kasutuselev\u00f5ttu \u2014 olete teretulnud. On GitHub<\/a><\/noindex>, pull-requests \u2014 Zalando meeskond p\u00fc\u00fcab neile \u00fcsna kiiresti vastata ja operaatorit edendada. Nii palju kui ma tean, projekt osales<\/a><\/noindex> Google Summer of Code'i ja m\u00f5nedes teistes sarnastes algatustes. Zalando t\u00f6\u00f6tab selle kallal v\u00e4ga aktiivselt.\n<\/p><\/blockquote>\n

<\/p>\n

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

\nKui teid huvitab PostgreSQL ja Kubernetes, siis juhtime t\u00e4helepanu, et eelmisel n\u00e4dalal toimus j\u00e4rgmine Postgres-teisip\u00e4ev, kus Nikolai suhtles Alexander Kukushkiniga Zalando's<\/b>. Video temast on saadaval siin<\/a><\/noindex>.<\/p>\n

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

\nLugege ka meie blogist:<\/p>\n