{"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: \"PostgreSQL ja Kubernetes. CI\/CD. Testimise automatiseerimine\"","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Postgres-teisip\u00e4ev
\n
\nM\u00f6\u00f6dunud aasta l\u00f5pus toimus j\u00e4rgmine otse\u00fclekanne Venemaa PostgreSQLi kogukonnalt #RuPostgres<\/a><\/noindex>, mille k\u00e4igus r\u00e4\u00e4kis selle kaasasutaja Nikolai Samokhvalov \"Flanta\" tehnilise direktori Dmitri Stolyaroviga sellest andmebaasis\u00fcsteemist Kubernetes 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 \"Vaata\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Andmebaasid ja Kubernetes<\/h2>\n

\nNS<\/b>: T\u00e4na ei hakka me r\u00e4\u00e4kima VACUUMist ja CHECKPOINTidest. R\u00e4\u00e4gime Kubernetesest. Ma tean, et sul on juba palju aastaid kogemusi. Olen vaadanud sinu videoid ja m\u00f5ned olen isegi taas vaadanud... Alustame kohe: miks on Postgres v\u00f5i MySQL K8s-is vajalik?<\/i><\/p>\n

DS<\/b>: Sellele k\u00fcsimusele ei ole \u00fchtegi kindlat vastust, ega saagi olla. Aga \u00fcldiselt on see lihtsus ja mugavus\u2026 potentsiaalselt. K\u00f5igile meeldiks ju manageeritud teenused.<\/p>\n

NS<\/b>: Nii nagu RDS<\/a><\/noindex>, ainult, et endal?<\/i><\/p>\n

DS<\/b>: Jah: et nagu RDS, ainult kus iganes.<\/p>\n

NS<\/b>: \u201eIgasugustes kohtades\u201c on hea t\u00e4helepanek. Suurtes ettev\u00f5tetes on k\u00f5ik erinevates kohtades. Miks siis, kui tegemist on suure ettev\u00f5ttega, mitte kasutada valmis lahendust? N\u00e4iteks Nutanixil on oma arendus, teistel ettev\u00f5tetel (VMware\u2026) \u2014 sama \u201eRDS, aga enda oma\u201c.<\/i><\/p>\n

DS<\/b>: Aga see, millest me r\u00e4\u00e4gime, on konkreetne teostus, mis t\u00f6\u00f6tab ainult teatud tingimustes. Kui r\u00e4\u00e4kida Kubernetesest, siis siin on tohutu infrastruktuuri mitmekesisus (mis v\u00f5ib olla K8s-is). Sisuliselt on see API standard pilve jaoks\u2026<\/p>\n

NS<\/b>: Veel tasuta!<\/i><\/p>\n

DS<\/b>: See pole nii oluline. Tasuta on oluline mitte v\u00e4ga suurele turusegmendile. Oluline on midagi muud\u2026 Sa ilmselt m\u00e4letad ettekannet \u201eAndmebaasid ja Kubernetes<\/a><\/noindex>\u00bb?<\/p>\n

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

DS<\/b>: Ma sain aru, et seda on v\u00e4ga erinevalt t\u00f5lgendatud. Osad inimesed arvasid, et ma \u00fctlen: \u201ePoisid, l\u00e4hme k\u00f5iki andmebaase Kubernetesesse!\u201c, - teised aga arvasid, et need on jubedad jalgrattad. Ja ma tahtsin \u00f6elda midagi muud: \u201eVaadake, mis toimub, millised probleemid on ja kuidas neid lahendada. Kas peaks andmebaase Kubernetesesse viima? Productioni? No, ainult juhul, kui te armastate... tegeleda teatud asjadega. Aga arenduseks \u2014 ma v\u00f5in \u00f6elda, et soovitan. Arenduses on v\u00e4ga oluline keskkondade loomise\/tugevdamise d\u00fcnaamilisus.<\/p>\n

\u041d\u0421: Kas sa silmas pead arendust, mis ei ole prod? Staging, QA...<\/i><\/p>\n

DS<\/b>: Kui r\u00e4\u00e4gime perf-seisakutest, siis ilmselt mitte, sest seal on n\u00f5uded spetsiifilised. Kui r\u00e4\u00e4gime erijuhtudest, kus staging'ul on vaja v\u00e4ga suurt andmebaasi, siis ka t\u00f5en\u00e4oliselt mitte\u2026 Kui see on staatiline keskkond, mis peab pikalt kestma, siis mis kasu on andmebaasist, mis asub K8s-is?<\/p>\n

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

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

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

DS<\/b>: Mul on v\u00e4ga lahe juhtum! Stagingus on tooteandmebaas, kuhu tehakse muudatusi. Ja seal on nupp: \u201etoota productionisse\u201c. Need muudatused \u2014 delfid \u2014 s\u00fcstitakse (tundub, et lihtsalt API kaudu s\u00fcnkroonitakse) tootmisse. See on v\u00e4ga eksootiline variant.<\/p>\n

NS<\/b>: Ma olen n\u00e4inud startup'e Silicon Valley's, kes kasutavad RDS'i v\u00f5i isegi Herokut \u2014 need on 2-3-aastaselt loodud lood, \u2014 ja nad laadivad andmebaasi endale s\u00fclearvutisse. Sest andmebaas on vaid 80 GB ja s\u00fclearvutis on ruumi. Seej\u00e4rel ostavad nad igale inimesele kettaid, et neil oleks 3 andmebaasi, et erinevaid arendusi teha. Nii ka juhtub. Olen ka n\u00e4inud, et ei karda tooteandmeid stagingusse kopeerida \u2014 see s\u00f5ltub v\u00e4ga palju ettev\u00f5ttest. Aga olen n\u00e4inud ka, et kardetakse ja sageli ei j\u00e4tku aega ja inimesi. Kuid enne, kui me selle teema juurde l\u00e4heme, tahaksin kuulda Kubernetesest. Ma \u00f5igesti sain aru, et tootmises pole seda veel kellegil?<\/i><\/p>\n

DS<\/b>: Meil on tootmises m\u00f5ned v\u00e4iksed andmebaasid. R\u00e4\u00e4gime gigabaitidest ja mitte kriitilistest teenustest, mille replikate tegemine tundus liiga keeruline (ja pole ka sellist vajadust). Ja tingimusel, et Kuberneteses on normaalne salvestuslahendus. See andmebaas t\u00f6\u00f6tas virtuaalmasinas - tinglikult VMware'is, tipptehnoloogia peal. Me panime selle PV<\/a><\/noindex> ja n\u00fc\u00fcd saame seda \u00fchest masinast teise \u00fcle viia.<\/p>\n

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

DS<\/b>: Jah, lineaarse operatsiooni puhul ei ole see probleem.<\/p>\n

NS<\/b>: Okei, prod'ist peame vaid m\u00f5tlema. Aga kui me kaalume Kuberneteset mitte-prod'i keskkondade jaoks \u2014 kuidas tegutseda? Ma n\u00e4en, et Zalando teeb operaatorit<\/a><\/noindex>, Crunchy arendab<\/a><\/noindex>, on veel m\u00f5ned variandid. Ja on OnGres<\/a><\/noindex> \u2014 meie hea tuttav Alvaro Hispaaniast: nad teevad sisuliselt mitte lihtsalt operaator<\/a><\/noindex>, vaid kogu distributsiooni (StackGres<\/a><\/noindex>), kuhu lisaks Postgres'ele t\u00f5ime ka varukoopia, proksi Envoy ...<\/i><\/p>\n

DS<\/b>: Envoy milleks? Just Postgres'i liikluse tasakaalustamiseks?<\/p>\n

NS<\/b>: Jah. See t\u00e4hendab, et nad n\u00e4evad seda nii: kui v\u00f5tta Linuxi jaotamine ja tuum, siis tavaline PostgreSQL on tuum, kuid nad tahavad luua jaotuse, mis on pilves\u00f5bralik ja t\u00f6\u00f6tab Kuberneteses. Nad \u00fchendavad komponente (varukoopiad jne) ja kohandavad, et need h\u00e4sti t\u00f6\u00f6taksid.<\/i><\/p>\n

DS<\/b>: T\u00f5eliselt \u00e4ge! Sisuliselt on see tarkvara, et teha oma hallatud Postgres.<\/p>\n

NS<\/b>: Linuxi jaotustel on pidevalt probleeme: kuidas teha draivereid, et kogu riistvara toetataks. Neil on idee, et nad t\u00f6\u00f6tavad Kuberneteses. Ma tean, et operaatorel Zalando puhul n\u00e4gime hiljuti s\u00f5ltuvust AWS-st ja see pole enam eriti hea. Ei peaks olema s\u00f5ltuvust konkreetsest infrastruktuurist \u2014 mis siis on selle m\u00f5te?<\/i><\/p>\n

DS<\/b>: Ei tea, millises konkreetses olukorras Zalando s\u00f5ltus, aga Kuberneteses on praegu salvestus tehtud nii, et ei saa \u00fcldiselt ketta varukoopiat teha. Hiljuti lisati standardisse \u2014 viimases versioonis CSI spetsifikatsioonid<\/a><\/noindex> \u2014 tehti v\u00f5imalus hetkepilte, aga kus see on rakendatud? Ausalt, see on endiselt nii toores\u2026 Me proovime CSI-d AWS, GCE, Azure, vSphere peal, aga kui hakkad kasutama, siis on kohe n\u00e4ha, et see pole veel valmis.<\/p>\n

NS<\/b>: Seet\u00f5ttu peab m\u00f5nikord infrastruktuuri k\u00fclge siduma. Usun, et see on endiselt varajane staadium - kasvu probleemid. K\u00fcsimus: mida sa soovitaksid algajatele, kes tahavad proovida PgSQL K8s-is? Milline operaator, v\u00f5ib-olla?<\/i><\/p>\n

DS<\/b>: Probleem on selles, et Postgres moodustab meie jaoks 3%. Meil on veel v\u00e4ga suur nimekiri erinevast tarkvarast Kuberneteses, ma ei hakka isegi k\u00f5ike \u00fcles lugema. N\u00e4iteks Elasticsearch. Operaatorite hulk on tohutu: m\u00f5ned arenevad aktiivselt, teised \u2014 ei. Me koostasime endale n\u00f5uded, millised peavad olema operaatorid, et me v\u00f5tleksime nendele t\u00f5siselt. Operaator Kuberneteses \u2014 mitte \u201eoperaator, et midagi Amazonis teha\u201c ... Tegelikult kasutame me \u00fcsna massiliselt (peaaegu k\u00f5igi klientide seas) ainult \u00fchte operaatorit \u2014 Redisile<\/a><\/noindex> (varsti avaldame ka temast artikli)<\/i>.<\/p>\n

NS<\/b>: Ent MySQLi jaoks ei ole ka? Ma tean, et Percona\u2026 kuna nad n\u00fc\u00fcd tegelevad nii MySQL, MongoDB kui ka Postgresiga, peavad nad looma mingi universaalse lahenduse: k\u00f5igi andmebaaside jaoks, k\u00f5igi pilveteenuse pakkujate jaoks.<\/i><\/p>\n

DS<\/b>: Me ei j\u00f5udnud vaadata MySQL operaatorite peale. See ei ole meie peamine fookus. MySQL t\u00f6\u00f6tab iseseisvalt normaalselt. Miks operaator, kui saad lihtsalt DB k\u00e4ivitada\u2026 Sa saad k\u00e4ivitada Docker-konteineri Postgresiga, v\u00f5i siis veel lihtsamalt.<\/p>\n

NS<\/b>: Selle kohta oli ka k\u00fcsimus. T\u00e4iesti ilma operaatorita?<\/i><\/p>\n

DS<\/b>: Jah, 100% meie PostgreSQL t\u00f6\u00f6tab ilma operaatorita. Praegu on see 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, sest tahame seda 100% juhtudel Kubernetesesse paigutada. Nii nagu tahame, et MongoDB oleks alati Kuberneteses. Siin tekivad teatud soovid \u2014 on tunne, et seda on v\u00f5imalik teha. Ja Postgres'i osas me isegi ei vaadanud. Loomulikult teame, et erinevaid variante on olemas, aga tegelikult on meil standalone.<\/p>\n

Andmebaas testimiseks Kuberneteses<\/h2>\n

\nNS<\/b>: Liigume testimise teema juurde. Kuidas teha andmebaasis muudatusi \u2014 DevOpsi perspektiivist. On mikroteenuseid, palju andmebaase, pidevalt muutub midagi. Kuidas tagada normaalne CI\/CD, et DB seisukohalt oleks k\u00f5ik korras. Mis on sinu l\u00e4henemine?<\/i><\/p>\n

DS<\/b>: \u00dchte vastust ei saa olla. On mitu parameetrit. Esimene on andmebaasi suurus, mille me tahame avada. Sa mainisid, et erinevad ettev\u00f5tted suhtuvad erinevalt sellesse, et prod-andmebaasi koopia oleks dev- ja stage-vkes.<\/p>\n

NS<\/b>: GDPR-i tingimustes arvan, et nad k\u00e4ituvad \u00fcha ettevaatlikumalt... V\u00f5in \u00f6elda, et Euroopas on juba hakatud trahve m\u00e4\u00e4rama.<\/i><\/p>\n

DS<\/b>: Kuid sageli on v\u00f5imalik kirjutada tarkvara, mis teeb tooteandmetest dumpi ja selle obfuskeerib. Tulemuseks on tootmisandmed (snapshot, dump, binaarne koopia ...), kuid need on anon\u00fc\u00fcmsed. Sel juhul v\u00f5ivad olla ka genereerimisskripti: need v\u00f5ivad olla fiktsioonid v\u00f5i lihtsalt skripti, mis genereerib suurt andmebaasi. Probleem on selles: kui kaua aega v\u00f5tab algse pildi loomine? Ja kui kaua aega kulub selle \u00fcles seadmiseks vajalikkes keskkondades?<\/p>\n

Oleme j\u00f5udnud skeemi: kui kliendil on fikstuurikomplekt (minimum andmebaasi versioon), siis kasutame neid vaikimisi. Kui r\u00e4\u00e4gime review-keskkondadest, kui oleme loonud haru ja meil on rakendus k\u00e4ivitatud \u2014 t\u00f5stame sinna v\u00e4ikese andmebaasi. Aga see \u00f5nnestus h\u00e4sti ja variant<\/a><\/noindex>, kui v\u00f5tame tootmisest dumpi kord \u00f6\u00f6sel (\u00f6\u00f6siti) ja kogume selle p\u00f5hjal Docker-konteineri PostgreSQL ja MySQL andmetega. Kui seda pilti tuleb 50 korda \u00fcles seada, siis see k\u00e4ib \u00fcsna lihtsalt ja kiiresti.<\/p>\n

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

DS<\/b>: Andmed on otse Docker'i pildis. St meil on valmis pilt, olgu see 100 GB. T\u00e4nu Docker'i kihtidele saame seda pilti kiiresti vajaliku arvu kordi \u00fcles seada. Meetod on v\u00f5ib-olla lihtne, aga t\u00f6\u00f6tab h\u00e4sti.<\/p>\n

NS<\/b>: Edasi, kui testite, siis see muutub otse Dockeris, eks? Copy-on-write Dockeris \u2014 viskame minema ja alustame j\u00e4lle, k\u00f5ik on korras. Lahe! Ja te kasutate seda juba laialdaselt?<\/i><\/p>\n

DS<\/b>: Ammu.<\/p>\n

NS<\/b>: Me tegeleme v\u00e4ga sarnaste asjadega. Ainult, et me ei kasuta Dockeri copy-on-write'i, vaid midagi muud.<\/i><\/p>\n

DS<\/b>: See ei ole geneeriline. Aga Docker'i oma t\u00f6\u00f6tab igal pool.<\/p>\n

NS<\/b>: Idee poolest, jah. Kuid meil on seal ka moodulid, saame teha erinevaid mooduleid ja t\u00f6\u00f6tada erinevate failis\u00fcsteemidega. Siin on \u00fcks punkt. Me vaatame Postgres'e poole k\u00f5igest sellest teistmoodi. N\u00fc\u00fcd olen vaadanud Docker'i k\u00fcljele ja n\u00e4inud, et teil k\u00f5ik t\u00f6\u00f6tab. Kuid kui andmebaas on tohutu, n\u00e4iteks 1 TB, siis on see juba pikk protsess: nii \u00f6\u00f6sel toimuvad operatsioonid kui ka k\u00f5ike Dockerisse suruda ... Aga kui 5 TB suruda Dockerisse ... v\u00f5i on k\u00f5ik korras?<\/i><\/p>\n

DS<\/b>: Mis vahet seal on: need on ju blobid, lihtsalt bitid ja baitid.<\/p>\n

NS<\/b>: Kas vahe on selles, et teete seda dump'i ja restore'iga?<\/i><\/p>\n

DS<\/b>: Sugugi mitte vajalik. Selle pildi genereerimise meetodid v\u00f5ivad olla erinevad.<\/p>\n

NS<\/b>: M\u00f5nele kliendile oleme teinud nii, et regulaarse p\u00f5hjaliku pildi genereerimise asemel hoiame seda pidevalt ajakohasena. See on sisuliselt replika, kuid andmed ei tule otse meistrilt, vaid l\u00e4bi arhiivi. Binaarne arhiiv, kuhu WAL'id sisenevad iga p\u00e4ev, seal teostatakse ka varukoopiaid ... Need WAL'id j\u00f5uavad seej\u00e4rel \u2014 v\u00e4ikese viivitusega (ainult 1-2 sekundit) \u2014 p\u00f5hjalikule kujule. Sellest me kopeerime igal viisil \u2014 praegu on meil vaikimisi ZFS.<\/i><\/p>\n

DS<\/b>: Kuid ZFS-iga olete piiratud \u00fche s\u00f5lme kasutamisega.<\/p>\n

NS<\/b>: Jah. Kuid ZFS-l on veel \u00fcks maagia send<\/a><\/noindex>: selle abil saab saata snapshot'i ja isegi (ma ei ole seda veel eriti testinud, aga...) saab saata delta kahte erineva vahel PGDATA<\/code>. Tegelikult on meil veel \u00fcks t\u00f6\u00f6riist, mida me selliste \u00fclesannete jaoks ei ole eriti uurinud. PostgreSQL-s on pg_rewind<\/a><\/noindex>, mis t\u00f6\u00f6tab nagu 'nutikas' rsync, vahele j\u00e4ttes palju sellist, millele ei pea t\u00e4helepanu p\u00f6\u00f6rama, sest seal ei ole midagi muutunud. Me saame kiire senkroniseerimise teha kahel serveril ja tagasi rullida t\u00e4pselt samamoodi.<\/i><\/p>\n

Nii et, me p\u00fc\u00fcame selle DBA-poolse l\u00e4henemise abil luua t\u00f6\u00f6riista, mis v\u00f5imaldab teha seda, millest sa r\u00e4\u00e4kisid: meil on \u00fcks andmebaas, kuid soovime testida midagi 50 korda, peaaegu samaaegselt.<\/i><\/p>\n

DS<\/b>: 50 korda t\u00e4hendab, et peate tellima 50 Spot-instantsit.<\/p>\n

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

DS<\/b>: Aga kuidas te paigutate 50 korda, kui see \u00fcks andmebaas on, \u00fctleme, terabaidine. T\u00f5en\u00e4oliselt vajab see tinglikult 256 GB RAM-i?<\/p>\n

NS<\/b>: Jah, m\u00f5nikord on m\u00e4lu t\u00f5esti palju \u2014 see on normaalne. Aga selline n\u00e4ide elust. Toote masinal on 96 tuuma ja 600 GB. Samas kasutatakse andmebaasi jaoks 32 tuuma (isegi 16 tuuma vahel on n\u00fc\u00fcd m\u00f5nikord) ja m\u00e4lu 100-120 GB.<\/i><\/p>\n

DS<\/b>: Ja sinna mahub 50 koopiat?<\/p>\n

NS<\/b>: Kuid koopia on \u00fcks, edasi t\u00f6\u00f6tab copy-on-write (ZFS'i jaoks)\u2026 R\u00e4\u00e4gin l\u00e4hemalt.<\/i><\/p>\n

Meil on n\u00e4iteks 10 TB andmebaas. Selle jaoks tehtud kett, ZFS surus selle suurust veel 30-40% v\u00f5rra kokku. Kuna me ei teosta koormustestimist, ei ole meile t\u00e4pne reageerimisaeg oluline: olgu see ka kahe korda aeglasem \u2014 see on okei.<\/i><\/p>\n

Anname v\u00f5imaluse programmeerijatele, QA-le, DBA-dele jne teostada testimist 1-2 voos. N\u00e4iteks saavad nad k\u00e4ivitada mingi migratsiooni. See ei vaja kohe 10 tuuma \u2014 vajalik on 1 PostgreSQL backend ja 1 tuum. Migratsioon k\u00e4ivitub \u2014 v\u00f5ib-olla, autovacuum<\/a><\/noindex> veel k\u00e4ivitub, siis kasutatakse teist tuuma. Meil on eraldatud 16-32 tuuma, nii et 10 inimest saavad samal ajal t\u00f6\u00f6tada, probleeme ei ole.<\/i><\/p>\n

Kuna f\u00fc\u00fcsiliselt PGDATA<\/code> tuleb v\u00e4lja, et me petame PostgreSQL-i. Viga on selles: n\u00e4iteks k\u00e4ivitatakse 10 PostgreSQL-i samaaegselt. Milline on tavaliselt probleem? Paigaldatakse shared_buffers<\/a><\/noindex>, oletame, 25%. Vastavalt sellele on see 200 GB. Rohkem kui kolm sellist ei saa enam k\u00e4ivitada, kuna m\u00e4lu saab otsa.<\/i><\/p>\n

Aga mingil hetkel m\u00f5istsime, et see pole vajalik: seadistame shared_buffers 2 GB. PostgreSQL-l on effective_cache_size<\/a><\/noindex>, ja tegelikult m\u00f5jutab see ainult plaane.<\/a><\/noindex>. Me paigaldame selle 0,5 TB. Ja isegi ei ole oluline, et neid tegelikult ei ole: ta koostab plaane, nagu oleks need olemas.<\/i><\/p>\n

Seega, kui testime mingi migratsiooni, saame koguda k\u00f5ik plaanid \u2014 n\u00e4eme, kuidas see toimub tootmises. Sekundid v\u00f5ivad olla teised (aeglasemad), kuid andmed, mida me tegelikult loeme, ja makrosid (millised JOIN-id jne) on t\u00e4pselt samad nagu tootmises. Ja samal ajal saame k\u00e4ivitada suure hulga selliseid kontrolle \u00fchel masinal.<\/i><\/p>\n

DS<\/b>: Kas sa ei arva, et siin on mitu probleemi? Esiteks \u2014 see lahendus t\u00f6\u00f6tab ainult PostgreSQL-is. Selline l\u00e4henemine on v\u00e4ga spetsiifiline, see ei ole generiline. Teiseks \u2014 Kubernetes (ja k\u00f5ik, kuhu n\u00fc\u00fcd pilvetehnoloogiad l\u00e4hevad) eeldab mitmeid s\u00f5lme, ja need s\u00f5lmed on efemeersed. Aga sinu puhul on see stateful, p\u00fcsiv s\u00f5lm. Need asjad tekitavad minus vastuolusid.<\/p>\n

NS<\/b>: Esiteks \u2014 n\u00f5ustun, see on puhtalt PostgreSQL-i lugu. Arvan, et kui meil on mingi otsene IO ja puhverpank, mis katab peaaegu kogu m\u00e4lu, siis selline l\u00e4henemine ei sobi \u2014 plaanid oleksid teistsugused. Kuid t\u00f6\u00f6tame praegu ainult PostgreSQL-iga, teise peale ei m\u00f5tle.<\/i><\/p>\n

Kubernetesest. Sa ju r\u00e4\u00e4gid igal pool, et meie andmebaas on p\u00fcsiv. Kui instants kukkus kokku, on peamine \u2014 s\u00e4ilitada ketas. Meie kogu platvorm on samuti Kuberneteses, ning Postgres'i komponent on eraldi (kuigi ka see kunagi seal olema hakkab). Seega on asi nii: instants kukkus kokku, aga me s\u00e4ilitasime selle PV ja \u00fchendasime lihtsalt uue instantsi k\u00fclge, nagu polekski midagi juhtunud.<\/i><\/p>\n

DS<\/b>: Minu arvates loome pod'e Kuberneteses. K8s on paindlik: s\u00f5lmed tellitakse automaatselt vastavalt vajadusele. \u00dclesanne on lihtsalt luua pod ja \u00f6elda, et vajab X ressursse, ja K8s m\u00f5istab \u00fclej\u00e4\u00e4nud. Kuid Kuberneteses on salvestuste tugi endiselt ebastabiilne: 1.16<\/a><\/noindex>, in 1.17<\/a><\/noindex> (see v\u00e4ljaanne ilmus n\u00e4dalat<\/i> tagasi) need funktsioonid on alles beetaversioonis.<\/p>\n

Kuue kuu v\u00f5i aasta p\u00e4rast \u2014 see muutub enam-v\u00e4hem stabiilseks, v\u00f5i v\u00e4hemalt nii \u00f6eldakse. Siis v\u00f5imalus snapshot'ide ja resize'i j\u00e4rgis on t\u00e4ielikult teie probleemi lahendanud. Sest teil on andmebaas. Jah, see ei pruugi olla v\u00e4ga kiire, kuid kiirus s\u00f5ltub sellest, mis on 'kapa all', sest m\u00f5ned teostused suudavad kopeerida ja copy-on-write tasemel kettaalust.<\/p>\n

NS<\/b>: Siin on veel asjaolu, et k\u00f5ik mootorid (Amazon, Google\u2026) peavad selle versiooni toetamisega tegelema \u2014 see v\u00f5tab samuti aega.<\/i><\/p>\n

DS<\/b>: Praegu me neid ei kasuta. Me kasutame oma lahendust.<\/p>\n

Kohalik arendus Kubernetes'ile<\/h2>\n

\nNS<\/b>: Kas oled kokku puutunud sellise soovi korral, kus tuleb \u00fchel masinal \u00fcles t\u00f5sta k\u00f5ik pod'id ja teha sellist v\u00e4ikest testimist. Et kiiresti saada t\u00f5end kontseptsiooni, n\u00e4ha, kas rakendus t\u00f6\u00f6tab Kuberneteses, eraldamata selleks mitmeid masinasid. On olemas Minikube, eks?<\/i><\/p>\n

DS<\/b>: Minu arvates on see juhtum \u2014 \u00fchel s\u00f5lmel \u00fcles seadmine \u2014 puhtalt kohaliku arenduse teema. V\u00f5i mingid selle mustri ilmingud. On Minikube<\/a><\/noindex>, on k3s<\/a><\/noindex>, KIND<\/a><\/noindex>. Me oleme suundumas selle poole, et hakkame Kubernetes'i Docker'i sees kasutama. Oleme hakanud sellega katsetama.<\/p>\n

NS<\/b>: Olen varem m\u00f5elnud, et see on katse panna k\u00f5ik pod'id \u00fchte Docker'i pilti. Kuid selgub, et see on hoopis millegi muu kohta. Siiski on need seal eraldi konteinerid, erinevad pod'id \u2014 lihtsalt Docker'is.<\/i><\/p>\n

DS<\/b>: Jah. Ja seal on \u00fcsna naljakas imitatsioon tehtud, aga m\u00f5te on selline... Meil on t\u00f6\u00f6riist, et rakendusi \u00fcles seada \u2014 werf<\/a><\/noindex>. Me tahame sellesse teha re\u017eiimi \u2014 tinglikult werf up<\/code>: \u201eK\u00e4ivita mulle kohalik Kubernetes\u201c. Ja seej\u00e4rel k\u00e4ivitada seal tinglik werf follow<\/code>. Siis saab arendaja IDE-s redigeerida, samal ajal kui s\u00fcsteemis on t\u00f6\u00f6protsess, mis n\u00e4eb muudatusi ja uuesti koostab pildid, deponeerib need kohalikku K8s-s\u00fcsteemi. Just nii p\u00fc\u00fcame lahendada kohaliku arenduse probleemi.<\/p>\n

Snapshots ja andmebaasi kloonimine K8s-i kontekstis<\/h2>\n

\nNS<\/b>: Kui tagasi tulla copy-on-write'i juurde. Olen m\u00e4rganud, et ka pilvedel on snapshot'id. Need toimivad erinevalt. N\u00e4iteks GCP-s: sul on USA idarannikul palju terabaiti instants. Teed regulaarselt snapshot'e. T\u00f5stad snapshot'ist koopia ketta l\u00e4\u00e4nerannikul \u2014 m\u00f5ne minuti p\u00e4rast on k\u00f5ik valmis, t\u00f6\u00f6tab v\u00e4ga kiiresti, lihtsalt tuleb m\u00e4lus cache t\u00e4ita. Kuid need kloonid (snapshot'id) \u2014 on selleks, et 'provision'-ida uus maht. See on tore, kui tuleb luua palju instantsse.<\/i><\/p>\n

Aga testide jaoks, mulle tundub, et snapshot'id, millest sa r\u00e4\u00e4gid Docker'is v\u00f5i millest mina r\u00e4\u00e4gin ZFS-is, btrfs-is ja isegi LVM-i\u2026 \u2014 need v\u00f5imaldavad just \u00fchel masinal mitte luua uusi andmeid. Pilves pead sa samuti nende eest iga kord maksma ja ootama mitte sekundeid, vaid minuteid (ja juhul lazy load'ide<\/a><\/noindex>, v\u00f5ib-olla isegi tunde).<\/i><\/p>\n

Selle asemel saab need andmed sekunditega k\u00e4tte, testi l\u00e4bi viia ja k\u00f5rvaldada. Need kiir\u00fclevaated lahendavad erinevaid \u00fclesandeid. Esimeses olukorras \u2014 et skaleerida ja uusi koopiaid saada, teises \u2014 testide jaoks.<\/i><\/p>\n

DS<\/b>: Ma ei n\u00f5ustu. Korraliku mahutite kloonimise tegemine on pilve \u00fclesanne. Ma ei ole nende teostust vaadanud, aga tean, kuidas me seda riistvaral teeme. Meil on Ceph, kus on v\u00f5imalik igale f\u00fc\u00fcsilisele mahutile (RBD<\/a><\/noindex>) \u00f6elda clone<\/i> ja saada juba k\u00fcmnete millisekunditega teine mahuti, millel on samad omadused, IOPS<\/a><\/noindex>tms. Tuleb m\u00f5ista, et seal sees on keeruline copy-on-write. Miks pilv seda samuti ei saaks teha? Olen kindel, et nad p\u00fc\u00fcavad seda teha.<\/p>\n

NS<\/b>: Kuid neil kulub ikkagi sekundeid, k\u00fcmneid sekundeid, et instantsi \u00fcles t\u00f5sta, Docker sinna tuua jne.<\/i><\/p>\n

DS<\/b>: Miks peaks kohe terve instantsi t\u00f5stma? Meil on ju instants 32 s\u00fcdamikuga, 16\u2026 ja sinna mahub mitmeid \u2014 n\u00e4iteks neli. Kui tellime viienda, t\u00f5useb juba instants, mis siis kaotatakse.<\/p>\n

NS<\/b>: Jah, huvitav, et Kuberneteses on hoopis teine lugu. Meie andmebaas ei ole K8s-is ja on \u00fcks instants. K\u00fcll aga l\u00e4heb mitme terabaidi andmebaasi kloonimiseks maksimaalselt kaks sekundit.<\/i><\/p>\n

DS<\/b>: See on \u00e4ge. Aga minu algne m\u00f5te oli, et see ei ole \u00fcldine lahendus. Jah, see on lahe, aga sobib ainult Postgresile ja ainult \u00fchel s\u00f5lmel.<\/p>\n

NS<\/b>: See sobib mitte ainult Postgresile: nagu ma kirjeldasin, t\u00f6\u00f6tavad need plaanid ainult selles. Aga kui me ei muretse plaanide p\u00e4rast ja vajame lihtsalt k\u00f5iki andmeid funktsionaalseteks testideks, siis sobib see igasuguste andmebaaside jaoks.<\/i><\/p>\n

DS<\/b>: Palju aastaid tagasi tegime me sarnast LVM-snapshottide peal. See on klassika. Sellist l\u00e4henemist kasutati v\u00e4ga aktiivselt. Stateful-s\u00f5lmed on lihtsalt valus. Sest neid ei tohi kukutada, neist tuleb alati meeles pidada...<\/p>\n

NS<\/b>: Kas sa ei n\u00e4e siin mingisugust h\u00fcbriidi v\u00f5imalust? Oletame, et stateful on mingi pod, mis t\u00f6\u00f6tab mitme inimese peal (palju testijate). Meil on \u00fcks maht, aga t\u00e4nu failis\u00fcsteemile on kloonid kohalikud. Kui pod kukub, j\u00e4\u00e4b ketas alles \u2014 pod t\u00f5useb tagasi, loeb kogu teabest kloonide kohta, t\u00f5stab k\u00f5ik tagasi \u00fcles ja \u00fctleb: \u00abSiin on teie kloonid nende portide peal, j\u00e4tkake nendega t\u00f6\u00f6d\u00bb.<\/i><\/p>\n

DS<\/b>: Tehniliselt t\u00e4hendab see, et Kuberneteses on tegemist \u00fche pod'iga, mille sees k\u00e4ivitame palju PostgreSQL'e.<\/p>\n

NS<\/b>: Jah. Tal on piirm\u00e4\u00e4r: oletame, et samal ajal saab selle juures t\u00f6\u00f6tada mitte rohkem kui 10 inimest. Kui on vaja 20 \u2014 k\u00e4ivitame teise sellise pod\u2019i. T\u00e4iesti reaalne on seda kopeerida, saades teise t\u00e4is mahtu, millel on sama 10 \u201e\u00f5hukest\u201c klooni. Kas sa ei n\u00e4e sellist v\u00f5imalust?<\/i><\/p>\n

DS<\/b>: Tuleb lisada siia ka turvalisuse k\u00fcsimused. Selline korraldus eeldab, et sellel pod'il on k\u00f5rged privileegid (capabilities), sest ta v\u00f5ib teostada mittestandardsed toimingud failis\u00fcsteemiga... Kuid kordused: usun, et keskmise t\u00e4htajaga lahendavad Kuberneteses salvestuse, pilvedel lahendavad kogu teema mahtudega \u2014 k\u00f5ik hakkab 'lihtsalt t\u00f6\u00f6tama'. Tuleb resize, kloonimine\u2026 On olemas maht \u2014 me \u00fctleme: 'Loo uus selle p\u00f5hjal', \u2014 ja poolteise sekundi jooksul saame, mida vajame.<\/p>\n

NS<\/b>: Ma ei usu poolteise sekundi saavutamisse paljude terabyte'ide jaoks. Ceph'is teed ise, aga r\u00e4\u00e4gid pilvedest. Mine pilve, tee EC2-s kloon terabyte'ide EBS mahust ja vaata, milline j\u00f5udlus tuleb. See ei v\u00f5ta paar sekundit. Mind huvitab v\u00e4ga, millal nad selleni j\u00f5uavad. Ma saan aru, millest sa r\u00e4\u00e4gid, aga luba endal mitte n\u00f5ustuda.<\/i><\/p>\n

DS<\/b>: Okei, aga ma \u00fctlesin, et keskpikas perspektiivis, mitte l\u00fchikeses. Aastaid kestvaks.<\/p>\n

PostgreSQL operaatorist Zalando poolt<\/h2>\n

\nKohtumise keskel liitus temaga ka Aleksei Kliukin, endine arendaja firmast Zalando, kes r\u00e4\u00e4kis PostgreSQL operaatori ajaloost:<\/p>\n

Hea, et see teema \u00fcldse t\u00f5statati: nii Postgres kui Kubernetes. Kui me hakkasime Zalandos seda 2017. aastal tegema, oli see teema, mida k\u00f5ik tahtsid teha, aga keegi ei teinud. K\u00f5igil hakkas juba Kubernetes olemas olema, aga kui k\u00fcsiti, kuidas andmebaasidega olla, siis isegi sellised inimesed nagu Kelsey Hightower<\/a><\/noindex>, kes propageerisid K8s, \u00fctlesid umbes niimoodi:<\/p>\n

\u201eMinge halduskeskkondadesse ja kasutage neid, \u00e4rge k\u00e4itage andmebaase Kuberneteses. Muul juhul otsustab teie K8s n\u00e4iteks uuendada, sulgeb k\u00f5ik s\u00f5lmed ja teie andmed kaovad kaugele kaugele.\u201d<\/i><\/p>\n

Me otsustasime teha operaatori, mis k\u00e4ivitab Postgresi andmebaasi Kuberneteses, sellele n\u00f5uandele vaatamata. Ja meil oli selleks hea alus \u2014 Patroni<\/a><\/noindex>. See on automaatne failover PostgreSQL-i jaoks, tehtud \u00f5igesti, st kasutades etcd, consul v\u00f5i ZooKeeper'i kui klastriteabe hoidjal. Selline hoidla, mis annab k\u00f5igile, kes k\u00fcsivad, n\u00e4iteks, kes on praegu liider, \u00fchte ja sama teavet \u2014 hoolimata sellest, et meil on k\u00f5ik jaotatud, \u2014 et ei tekiks split brain'i. Pluss, meil oli Docker-image<\/a><\/noindex> selle jaoks.<\/p>\n

Tegelikult tekkis ettev\u00f5ttel vajadus auto failover'i j\u00e4rele p\u00e4rast migratsiooni sisemisest riistvarakeskusest pilve. Pilv p\u00f5hines ettev\u00f5tte enda PaaS (Platform-as-a-Service) lahendusel. See oli avatud l\u00e4htekoodiga, kuid selle k\u00e4ivitamiseks tuli k\u00f5vasti vaeva n\u00e4ha. Selle nimi oli STUPS<\/a><\/noindex>.<\/p>\n

Alguses ei olnud mingit Kubernetes't. T\u00e4psemalt, kui meie enda lahendus juurutati, oli K8s juba olemas, aga nii keeruline, et tootmisse ei sobinud. See oli, minu arust, 2015. v\u00f5i 2016. aasta. Aastaks 2017 oli Kubernetes enam-v\u00e4hem k\u00fcpsemas \u2014 tekkis vajadus sinna migreerimise j\u00e4rele.<\/p>\n

Ja meil oli juba Docker-konteiner. Oli PaaS, mis kasutas Dockerit. Miks mitte proovida K8s-i? Miks mitte kirjutada oma operaator? Murat Kabilov, kes tuli meile Avitost, alustas seda projektina oma algatusel \u2014 \"looma m\u00e4ngida\" \u2014 ja projekt \"t\u00f5usis\".<\/p>\n

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

Kui k\u00e4ivitate midagi Kuberneteses, tuleb aru saada, et K8s on pidevas arengus. See areneb pidevalt, paraneb ja perioodiliselt isegi rikneb. Tuleb hoolikalt j\u00e4lgida k\u00f5iki muudatusi Kuberneteses, olema valmis vajadusel s\u00fcvenema sellesse ja \u00f5ppima, kuidas k\u00f5ik detailid t\u00f6\u00f6tavad \u2014 v\u00f5ib-olla rohkem, kui sooviksite. See kehtib p\u00f5him\u00f5tteliselt iga platvormi kohta, millel te oma andmebaase k\u00e4ivitate...<\/p>\n

N\u00fc\u00fcd, kui me tegime operaatorit, oli meil Postgres, mis t\u00f6\u00f6tas v\u00e4lise mahuga (antud juhul EBS, kuna t\u00f6\u00f6tasime AWS-is). Andmebaas kasvas ja mingil hetkel tuli teha muudatused: n\u00e4iteks, algne EBS-i suurus oli 100 TB, andmebaas ulatus sellele, n\u00fc\u00fcd soovime EBS-i suurust muuta 200 TB-ks. Kuidas? Eeldame, et v\u00f5iks teha dump\/restore uuele instantsile, kuid see on aeglane ja toob kaasa seisaku.<\/p>\n

Seega tahtsime sellist resize'i, mis suurendaks EBS'i jagu ja siis annaks failis\u00fcsteemile korralduse kasutada uut ruumi. Ja me saavutasime selle, kuid tol ajal ei olnud Kubernetes'il mingit API'd resize operatsiooni jaoks. Kuna t\u00f6\u00f6tasime AWS-il, kirjutasime koodi selle API jaoks.<\/p>\n

Keegi ei takista teha sama ka teiste platvormide jaoks. Operaator ei ole seotud ainult AWS-iga, see t\u00f6\u00f6tab ka teistel platvormidel. See on avatud l\u00e4htekoodiga projekt: kui keegi soovib kiirendada uue API kasutuselev\u00f5ttu \u2014 olete teretulnud. On GitHub<\/a><\/noindex>, pull-p\u00e4ringuid \u2014 Zalando meeskond p\u00fc\u00fcab neile \u00fcsna kiiresti reageerida ja operaatorit edendada. Niipalju kui tean, projekt osales<\/a><\/noindex> Google Summer of Code'i ja teiste sarnaste algatuste kohta. Zalando t\u00f6\u00f6tab selle nimel v\u00e4ga aktiivselt.\n<\/p><\/blockquote>\n

<\/p>\n

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

\nKui teid huvitab PostgreSQL ja Kubernetes, tasub m\u00e4rkida, et eelmisel n\u00e4dalal toimus j\u00e4rgmine Postgres-teisip\u00e4ev, kus Nikolai kohtus Alexander Kukushkiniga Zalando's<\/b>. Video on saadaval siit<\/a><\/noindex>.<\/p>\n

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

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