Koncom minulého roka prebehol ďalší priamy prenos ruskej PostgreSQL komunity , počas ktorej jej spoluzakladateľ Nikolaj Samokhvalov hovoril s technickým riaditeľom Flant Dmitrijom Stolyarovom o tomto DBMS v kontexte Kubernetes.
Zverejňujeme prepis hlavnej časti tejto diskusie a o Zverejnené celé video:
Databázy a Kubernetes
НС: O VAKUUM a CHECKPOINToch sa dnes baviť nebudeme. Chceme hovoriť o Kubernetes. Viem, že máte dlhoročné skúsenosti. Pozrel som si vaše videá a dokonca som si niektoré z nich pozrel znova... Poďme rovno k veci: prečo vôbec Postgres alebo MySQL v K8?
DS: Na túto otázku neexistuje a nemôže existovať jednoznačná odpoveď. Ale vo všeobecnosti ide o jednoduchosť a pohodlie... potenciál. Každý chce spravované služby.
НС: Ako , len doma?
DS: Áno: ako RDS, jednoducho kdekoľvek.
НС: „Kdekoľvek“ je dobrý bod. Vo veľkých spoločnostiach sa všetko nachádza na rôznych miestach. Prečo potom, ak ide o veľkú spoločnosť, nezobrať hotové riešenie? Napríklad Nutanix má svoj vlastný vývoj, iné spoločnosti (VMware...) majú rovnaké „RDS, len doma“.
DS: Hovoríme však o samostatnej implementácii, ktorá bude fungovať len za určitých podmienok. A ak hovoríme o Kubernetes, potom existuje obrovská rozmanitosť infraštruktúry (ktorá môže byť v K8). V podstate ide o štandard pre API do cloudu...
НС: Je to tiež zadarmo!
DS: To nie je také dôležité. Bezplatnosť je dôležitá pre nie veľmi veľký segment trhu. Dôležité je niečo iné... Určite si spomínate na reportáž “»?
НС: Áno.
DS: Uvedomil som si, že to bolo prijaté veľmi nejednoznačne. Niektorí ľudia si mysleli, že hovorím: "Chlapci, poďme všetky databázy do Kubernetes!", zatiaľ čo iní sa rozhodli, že to všetko sú hrozné bicykle. Chcel som však povedať niečo úplne iné: „Pozrite sa, čo sa deje, aké problémy sú a ako sa dajú vyriešiť. Mali by sme teraz používať databázy Kubernetes? Výroba? No, iba ak rád...robíš isté veci. Ale pre vývojárov môžem povedať, že to odporúčam. Pre vývojárov je dynamika vytvárania/odstraňovania prostredí veľmi dôležitá.“
NS: Pod pojmom dev máte na mysli všetky prostredia, ktoré nie sú prod? Staging, QA…
DS: Ak hovoríme o výkonových stojanoch, potom pravdepodobne nie, pretože tam sú špecifické požiadavky. Ak hovoríme o špeciálnych prípadoch, keď je na staging potrebná veľmi veľká databáza, tak asi nie... Ak ide o statické prostredie s dlhou životnosťou, aká je potom výhoda umiestnenia databázy v K8?
НС: Žiadne. Kde však vidíme statické prostredia? Statické prostredie sa zajtra stane zastaraným.
DS: Inscenácia môže byť statická. Máme klientov...
НС: Áno, aj ja mám jednu. Je to veľký problém, ak máte 10 TB databázu a 200 GB staging...
DS: Mám veľmi skvelý prípad! Pri zavádzaní existuje databáza produktov, v ktorej sa vykonávajú zmeny. A je tu tlačidlo: „zaviesť do výroby“. Tieto zmeny – delty – sú pridané (zdá sa, že sú jednoducho synchronizované cez API) vo výrobe. Toto je veľmi exotická možnosť.
НС: Videl som startupy v údolí, ktoré sedia v RDS alebo dokonca v Heroku – to sú príbehy spred 2 – 3 rokov – a sťahujú si výpis do svojho notebooku. Pretože databáza má stále len 80 GB a na notebooku je miesto. Potom pre každého kúpia ďalšie disky, aby mali 3 databázy na vykonávanie rôznych vývojov. Aj takto sa to deje. Tiež som videl, že sa neboja skopírovať prod do inscenácie - veľmi záleží od firmy. Ale tiež som videl, že sa veľmi boja, a že často nemajú dosť času a rúk. Ale predtým, ako prejdeme k tejto téme, chcem počuť o Kubernetes. Chápem to správne, že ešte nikto nie je v prod?
DS: Máme malé databázy v prod. Hovoríme o objemoch desiatok gigabajtov a nekritických službách, pre ktoré sme boli príliš leniví robiť repliky (a nie je taká potreba). A to za predpokladu, že pod Kubernetes existuje normálne úložisko. Táto databáza fungovala vo virtuálnom stroji – podmienečne vo VMware, na vrchu úložného systému. Vložili sme to a teraz to môžeme preniesť zo stroja na stroj.
НС: Databázy takejto veľkosti, až do 100 GB, sa dajú spustiť za pár minút na dobrých diskoch a dobrej sieti, však? Rýchlosť 1 GB za sekundu už nie je exotická.
DS: Áno, pre lineárnu prevádzku to nie je problém.
НС: Dobre, musíme len myslieť na prod. A ak uvažujeme o Kubernetes pre neprodukčné prostredia, čo by sme mali robiť? Vidím to na Zalande , v Crunchy , existuje niekoľko ďalších možností. A existuje - to je náš dobrý priateľ Alvaro zo Španielska: to, čo robia, nie je v podstate spravodlivé a celá distribúcia (), do ktorého sa okrem samotného Postgresu rozhodli napchať aj zálohu, Envoy proxy...
DS: Vyslanec za čo? Konkrétne vyrovnávate návštevnosť Postgresu?
НС: Áno. To znamená, že to vidia takto: ak si vezmete linuxovú distribúciu a jadro, jadrom je bežný PostgreSQL a chcú vytvoriť distribúciu, ktorá bude vhodná pre cloud a bude fungovať na Kubernetes. Poskladajú komponenty (zálohy a pod.) a odladia ich tak, aby dobre fungovali.
DS: Husté! V podstate ide o softvér na vytvorenie vlastného spravovaného Postgresu.
НС: Linuxové distribúcie majú večné problémy: ako urobiť ovládače tak, aby bol podporovaný všetok hardvér. A majú predstavu, že budú pracovať v Kubernetes. Viem, že v operátorovi Zalando sme nedávno videli prepojenie na AWS a to už nie je veľmi dobré. Nemalo by existovať spojenie s konkrétnou infraštruktúrou – aký to má potom zmysel?
DS: Neviem presne, do akej situácie sa Zalando dostal, ale úložisko Kubernetes je teraz robené tak, že nie je možné urobiť zálohu disku pomocou všeobecnej metódy. Nedávno v štandarde - v najnovšej verzii — umožnili sme snímky, ale kde sa to implementuje? Úprimne povedané, všetko je stále také surové... Skúšame CSI nad AWS, GCE, Azure, vSphere, ale hneď ako ho začnete používať, vidíte, že ešte nie je pripravený.
НС: Preto sa niekedy musíme spoliehať na infraštruktúru. Myslím, že toto je ešte skoré štádium - rastové bolesti. Otázka: Čo by ste poradili nováčikom, ktorí chcú vyskúšať PgSQL v K8? Aký operátor asi?
DS: Problém je, že Postgres je pre nás 3%. V Kubernetes máme tiež veľmi veľký zoznam rôzneho softvéru, nebudem ani uvádzať všetko. Napríklad Elasticsearch. Existuje veľa operátorov: niektorí sa aktívne rozvíjajú, iní nie. Vypracovali sme si požiadavky na to, čo by mal mať operátor, aby sme to brali vážne. V operátorovi špeciálne pre Kubernetes - nie v "operátorovi, ktorý robí niečo v podmienkach Amazonu"... V skutočnosti pomerne široko (= takmer všetci klienti) používame jediného operátora - (čoskoro o ňom uverejníme článok).
НС: A nie pre MySQL? Viem, že Percona... keďže teraz pracujú na MySQL, MongoDB a Postgres, budú musieť vytvoriť nejaké univerzálne riešenie: pre všetky databázy, pre všetkých poskytovateľov cloudu.
DS: Nemali sme čas pozrieť sa na operátorov pre MySQL. Toto nie je momentálne naša hlavná pozornosť. MySQL funguje dobre aj samostatne. Načo používať operátora, keď stačí spustiť databázu... Docker kontajner môžete spustiť pomocou Postrges, alebo ho môžete spustiť jednoduchým spôsobom.
НС: Aj na toto bola otázka. Vôbec žiadny operátor?
DS: Áno, 100% z nás má spustený PostgreSQL bez operátora. Zatiaľ áno. Aktívne využívame operátora pre Prometheus a Redis. Máme v pláne nájsť operátora pre Elasticsearch – ten je najviac „v plameňoch“, pretože ho chceme nainštalovať do Kubernetes v 100% prípadov. Rovnako ako chceme zabezpečiť, aby bol MongoDB vždy nainštalovaný aj v Kubernetes. Tu sa objavujú určité želania - existuje pocit, že v týchto prípadoch sa dá niečo urobiť. A to sme sa ani nepozreli na Postgres. Samozrejme, vieme, že existujú rôzne možnosti, ale v skutočnosti máme samostatný.
DB na testovanie v Kubernetes
НС: Prejdime k téme testovania. Ako zavádzať zmeny do databázy – z pohľadu DevOps. Sú tu mikroslužby, veľa databáz, neustále sa niekde niečo mení. Ako zabezpečiť normálne CI/CD, aby bolo z pohľadu DBMS všetko v poriadku. Aký je váš prístup?
DS: Nemôže existovať jedna odpoveď. Možností je viacero. Prvým je veľkosť základne, ktorú chceme vyvaľkať. Sami ste spomenuli, že spoločnosti majú rozdielne postoje k tomu, aby mali kópiu databázy produktov na vývojároch a na pódiu.
НС: A v podmienkach GDPR si myslím, že sú čoraz opatrnejší... Môžem povedať, že v Európe už začali udeľovať pokuty.
DS: Často však dokážete napísať softvér, ktorý odoberie výpis z výroby a zahmlí ho. Údaje o produkte sa získavajú (snímka, výpis, binárna kópia...), ale sú anonymizované. Namiesto toho môžu existovať generačné skripty: môžu to byť prípravky alebo len skript, ktorý generuje veľkú databázu. Problém je: ako dlho trvá vytvorenie základného obrázka? A ako dlho trvá jeho nasadenie v požadovanom prostredí?
Dospeli sme k schéme: ak má klient fixný súbor údajov (minimálna verzia databázy), tak ich štandardne používame. Ak hovoríme o recenzných prostrediach, keď sme vytvorili pobočku, nasadili sme inštanciu aplikácie – tam nasadíme malú databázu. Ale dopadlo to dobre , kedy si raz za deň (v noci) vezmeme z výroby výpis a na jeho základe postavíme Docker kontajner s PostgreSQL a MySQL s týmito načítanými dátami. Ak potrebujete z tohto obrázku rozšíriť databázu 50-krát, urobíte to celkom jednoducho a rýchlo.
НС: Jednoduchým kopírovaním?
DS: Údaje sú uložené priamo v obrázku Docker. Tie. Máme hotový obraz, aj keď 100 GB. Vďaka vrstvám v Dockeri môžeme tento obrázok rýchlo nasadiť toľkokrát, koľkokrát potrebujeme. Metóda je hlúpa, ale funguje dobre.
НС: Potom, keď testujete, zmení sa to priamo v Dockeri, však? Copy-on-write vnútri Docker - zahoďte to a choďte znova, všetko je v poriadku. Trieda! A využívate ho už naplno?
DS: Dlho.
НС: Robíme veľmi podobné veci. Len nepoužívame Dockerovu kópiu na zápis, ale nejakú inú.
DS: Nie je to všeobecné. A Docker funguje všade.
НС: Teoreticky áno. Ale máme tam aj moduly, môžete robiť rôzne moduly a pracovať s rôznymi súborovými systémami. Aký moment tu. Zo strany Postgresu sa na to všetko pozeráme inak. Teraz som sa pozrel zo strany Dockera a videl som, že všetko pre vás funguje. Ale ak je databáza obrovská, napríklad 1 TB, tak to všetko trvá dlho: operácie v noci a napchanie všetkého do Dockera... A ak sa do Dockeru natlačí 5 TB... Alebo je všetko v poriadku?
DS: Aký je rozdiel: toto sú bloby, len bity a bajty.
НС: Rozdiel je v tomto: robíte to cez výpis a obnovenie?
DS: Vôbec nie je potrebné. Spôsoby vytvárania tohto obrázka môžu byť rôzne.
НС: Pre niektorých klientov sme to urobili tak, že namiesto pravidelného generovania základného obrazu ho neustále aktualizujeme. Je to v podstate replika, ale údaje neprijíma priamo od mastera, ale prostredníctvom archívu. Binárny archív, kde sa každý deň sťahujú WAL, kde sa robia zálohy... Tieto WAL sa potom dostanú do základného obrazu s miernym oneskorením (doslova 1-2 sekundy). Klonujeme z neho akýmkoľvek spôsobom - teraz máme štandardne ZFS.
DS: Ale so ZFS ste obmedzený na jeden uzol.
НС: Áno. Ale ZFS má aj čaro : s ním môžete poslať snímku a dokonca (toto som ešte netestoval, ale...) môžete poslať deltu medzi dvoma PGDATA. V skutočnosti máme ďalší nástroj, o ktorom sme na takéto úlohy skutočne neuvažovali. PostgreSQL má , ktorý funguje ako „inteligentný“ rsync, preskakuje veľa z toho, čo pozerať nemusíte, pretože sa tam nič nezmenilo. Môžeme urobiť rýchlu synchronizáciu medzi dvoma servermi a pretočiť späť rovnakým spôsobom.
Takže z tejto, viac DBA strany, sa snažíme vytvoriť nástroj, ktorý nám umožní robiť to isté, čo ste povedali: máme jednu databázu, ale chceme niečo otestovať 50-krát, takmer súčasne.
DS: 50-krát znamená, že musíte objednať 50 inštancií Spot.
НС: Nie, všetko robíme na jednom stroji.
DS: Ale ako sa rozšírite 50-krát, ak je táto databáza, povedzme, terabajtová. S najväčšou pravdepodobnosťou potrebuje podmienených 256 GB RAM?
НС: Áno, niekedy potrebujete veľa pamäte – to je normálne. Ale toto je príklad zo života. Produkčný stroj má 96 jadier a 600 GB. Zároveň sa na databázu používa 32 jadier (teraz niekedy aj 16 jadier) a 100-120 GB pamäte.
DS: A zmestilo sa tam 50 kópií?
НС: Takže existuje len jedna kópia, potom funguje kopírovanie pri zápise (ZFS)... Poviem vám to podrobnejšie.
Napríklad máme 10 TB databázu. Vyrobili na to disk, ZFS skomprimoval aj jeho veľkosť o 30-40 percent. Keďže nevykonávame záťažové testovanie, presný čas odozvy pre nás nie je dôležitý: nech je až 2-krát pomalší – to je v poriadku.
Dávame príležitosť programátorom, QA, DBA atď. vykonajte testovanie v 1-2 vláknach. Mohli by napríklad spustiť nejaký druh migrácie. Nevyžaduje 10 jadier naraz - potrebuje 1 Postgres backend, 1 jadro. Migrácia sa spustí - možno sa stále spustí, potom sa použije druhé jadro. Máme pridelených 16-32 jadier, takže môže pracovať 10 ľudí súčasne, žiadny problém.
Pretože fyzicky PGDATA rovnako sa ukazuje, že v skutočnosti klameme Postgres. Trik je v tomto: napríklad 10 Postgres sa spustí súčasne. Aký je zvyčajne problém? Dali , povedzme 25 %. V súlade s tým je to 200 GB. Nebudete môcť spustiť viac ako tri z nich, pretože sa minie pamäť.
V určitom okamihu sme si však uvedomili, že to nie je potrebné: nastavili sme shared_buffers na 2 GB. PostgreSQL má , a v skutočnosti je to jediné, čo ovplyvňuje . Nastavili sme to na 0,5 TB. A nezáleží ani na tom, že v skutočnosti neexistujú: robí plány, ako keby existovali.
Podľa toho, keď otestujeme nejaký druh migrácie, môžeme zhromaždiť všetky plány - uvidíme, ako to bude vo výrobe. Sekundy tam budú iné (pomalšie), ale dáta, ktoré skutočne čítame, a samotné plány (aké tam sú JOINy atď.) vychádzajú úplne rovnako ako vo výrobe. A na jednom stroji môžete paralelne spustiť veľa takýchto kontrol.
DS: Nemyslíš si, že je tu pár problémov? Prvým je riešenie, ktoré funguje iba na PostgreSQL. Tento prístup je veľmi súkromný, nie je všeobecný. Druhým je, že Kubernetes (a všetko, na čo sa teraz cloudové technológie chystajú) zahŕňa veľa uzlov a tieto uzly sú pominuteľné. A vo vašom prípade ide o stavový, pretrvávajúci uzol. Tieto veci vo mne vyvolávajú konflikty.
НС: Po prvé, súhlasím, toto je čisto príbeh Postgres. Myslím si, že ak máme nejaké priame IO a vyrovnávaciu pamäť pre takmer celú pamäť, tento prístup nebude fungovať - plány budú iné. Ale zatiaľ pracujeme iba s Postgres, nemyslíme na ostatných.
O Kubernetes. Sami nám všade hovoríte, že máme stálu databázu. Ak inštancia zlyhá, hlavnou vecou je uložiť disk. Tu máme aj celú platformu v Kubernetes a komponent s Postgresom je samostatný (aj keď raz tam bude). Preto je všetko takto: inštancia padla, ale my sme jej PV uložili a jednoducho ju pripojili k inej (novej) inštancii, akoby sa nič nestalo.
DS: Z môjho pohľadu vytvárame pody v Kubernetes. K8s - elastické: uzly sa objednávajú podľa potreby. Úlohou je jednoducho vytvoriť modul a povedať, že potrebuje X množstvo zdrojov, a potom na to K8 prídu sami. Podpora úložiska v Kubernetes je však stále nestabilná: V (toto vydanie bolo vydané týždňa pred) sa tieto funkcie stanú iba beta.
Uplynie šesť mesiacov až rok – viac-menej sa to ustáli, alebo sa to tak aspoň vyhlási. Potom možnosť snímok a zmeny veľkosti váš problém úplne vyrieši. Pretože máte základňu. Áno, nemusí to byť veľmi rýchle, ale rýchlosť závisí od toho, čo je „pod kapotou“, pretože niektoré implementácie dokážu kopírovať a kopírovať pri zápise na úrovni diskového subsystému.
НС: Taktiež je potrebné, aby všetky enginy (Amazon, Google...) začali podporovať túto verziu – aj to nejaký čas trvá.
DS: Zatiaľ ich nepoužívame. Používame naše.
Miestny vývoj pre Kubernetes
НС: Stretli ste sa s takýmto želaním, keď potrebujete nainštalovať všetky pody na jeden stroj a urobiť taký malý test. Ak chcete rýchlo získať dôkaz o koncepte, pozrite sa, že aplikácia beží v Kubernetes bez toho, aby ste pre ňu vyhradili veľa strojov. Je tu Minikube, však?
DS: Zdá sa mi, že tento prípad – nasadený na jednom uzle – je výlučne o lokálnom rozvoji. Alebo nejaké prejavy takéhoto vzoru. Jedzte , tam je , . Smerujeme k používaniu Kubernetes IN Docker. Teraz sme s tým začali pracovať na testoch.
НС: Kedysi som si myslel, že ide o pokus zabaliť všetky moduly do jedného obrázka Docker. Ukázalo sa však, že tu ide o niečo úplne iné. Každopádne existujú samostatné kontajnery, samostatné pody - len v Dockeri.
DS: Áno. A vznikla celkom vtipná napodobenina, ale význam je takýto... Máme utilitu na nasadenie - . Chceme z toho urobiť podmienený režim werf up: "Získajte mi miestne Kubernetes." A potom tam spustite podmienku werf follow. Potom bude môcť vývojár upravovať IDE a v systéme sa spustí proces, ktorý uvidí zmeny a prestaví obrázky a premiestni ich do miestnych K8. Takto sa chceme pokúsiť vyriešiť problém miestneho rozvoja.
Snímky a klonovanie databázy v realite K8s
НС: Ak sa vrátime ku kopírovaniu pri zápise. Všimol som si, že aj mraky majú momentky. Fungujú inak. Napríklad v GCP: máte viacterabajtovú inštanciu na východnom pobreží Spojených štátov. Pravidelne robíte snímky. Kópiu disku na západnom pobreží zoberiete zo snímky – za pár minút je všetko pripravené, funguje to veľmi rýchlo, len treba vyplniť vyrovnávaciu pamäť. Ale tieto klony (snímky) slúžia na „poskytnutie“ nového zväzku. Je to skvelé, keď potrebujete vytvoriť veľa inštancií.
Ale na testy sa mi zdá, že snapshoty, o ktorých hovoríte v Dockeri alebo ja v ZFS, btrfs a dokonca aj LVM... - vám umožňujú nevytvárať skutočne nové dáta na jednom stroji. V cloude za ne budete stále platiť zakaždým a čakať nie sekundy, ale minúty (a v príp , prípadne hodinky).
Namiesto toho môžete tieto údaje získať za sekundu alebo dve, spustiť test a zahodiť ich. Tieto snímky riešia rôzne problémy. V prvom prípade - zväčšiť a získať nové repliky av druhom - na testy.
DS: Nesúhlasím. Správne fungovanie klonovania objemu je úlohou cloudu. Nepozeral som sa na ich implementáciu, ale viem, ako to robíme na hardvéri. Máme Ceph, umožňuje akýkoľvek fyzický objem () povedať klonovať a získate druhý zväzok s rovnakými charakteristikami v desiatkach milisekúnd, 'ami atď. Musíte pochopiť, že vo vnútri je zložité kopírovanie na zapisovanie. Prečo by to isté nemal robiť cloud? Som si istý, že sa o to pokúšajú tak či onak.
НС: Ale aj tak im bude trvať sekundy, desiatky sekúnd, kým vyvolajú inštanciu, privedú tam Dockera atď.
DS: Prečo je potrebné vyvolať celú inštanciu? Máme inštanciu s 32 jadrami, 16... a zmestí sa do nej - napríklad štyri. Keď objednáme piaty, inštancia už bude vyvolaná a potom bude vymazaná.
НС: Áno, zaujímavé, Kubernetes sa ukazuje ako iný príbeh. Naša databáza nie je v K8 a máme jednu inštanciu. Ale klonovanie viacterabajtovej databázy netrvá dlhšie ako dve sekundy.
DS: Toto je skvelé. Ale môj prvý bod je, že toto nie je všeobecné riešenie. Áno, je to skvelé, ale je vhodné iba pre Postgres a iba na jednom uzle.
НС: Je vhodný nielen pre Postgres: tieto plány, ako som opísal, budú fungovať iba v ňom. Ak sa však nestaráme o plány a potrebujeme iba všetky údaje na funkčné testovanie, potom je to vhodné pre akýkoľvek DBMS.
DS: Pred mnohými rokmi sme urobili niečo podobné na snímkach LVM. Toto je klasika. Tento prístup bol veľmi aktívne využívaný. Stavové uzly sú len bolesťou. Pretože by ste ich nemali zahodiť, mali by ste si ich vždy pamätať...
НС: Vidíte tu nejakú možnosť hybridu? Povedzme, že stateful je nejaký druh modulu, ktorý funguje pre viacerých ľudí (veľa testerov). Máme jeden zväzok, no vďaka súborovému systému sú klony lokálne. Ak modul spadne, ale disk zostane, modul sa zdvihne, spočíta informácie o všetkých klonoch, znova všetko vyberie a povie: „Tu sú vaše klony spustené na týchto portoch, pokračujte v práci s nimi.“
DS: Technicky to znamená, že v rámci Kubernetes je to jeden modul, v ktorom prevádzkujeme mnoho Postgres.
НС: Áno. Má limit: povedzme, že s ním nepracuje viac ako 10 ľudí súčasne. Ak potrebujete 20, spustíme druhý takýto modul. Plne ho naklonujeme, keď dostaneme druhý plný zväzok, bude mať rovnakých 10 „tenkých“ klonov. Nevidíš túto príležitosť?
DS: Tu musíme pridať bezpečnostné problémy. Z tohto typu organizácie vyplýva, že tento pod má vysoké privilégiá (schopnosti), pretože dokáže vykonávať neštandardné operácie na súborovom systéme... Ale opakujem: Verím, že v strednodobom horizonte opravia úložisko v Kubernetes a v r. mraky opravia celý príbeh objemami - všetko bude „fungovať“. Uskutoční sa zmena veľkosti, klonovanie... Existuje zväzok – povieme: „Na základe toho vytvorte nový,“ a po sekunde a pol dostaneme, čo potrebujeme.
НС: Neverím v jeden a pol sekundy pri mnohých terabajtoch. Na Ceph si to robíš sám, ale hovoríš o oblakoch. Choďte do cloudu, vytvorte klon multi-terabajtového zväzku EBS na EC2 a uvidíte, aký bude výkon. Nezaberie to pár sekúnd. Veľmi ma zaujíma, kedy sa dostanú na túto úroveň. Rozumiem, čo hovoríte, ale chcem sa odlišovať.
DS: Dobre, ale povedal som v strednodobom, nie krátkodobom horizonte. Už niekoľko rokov.
O operátorovi pre PostgreSQL od Zalanda
Uprostred tohto stretnutia sa pridal aj Alexey Klyukin, bývalý vývojár zo Zalanda, ktorý hovoril o histórii operátora PostgreSQL:
Je skvelé, že sa táto téma dotýka všeobecne: Postgres aj Kubernetes. Keď sme to začali robiť v Zalande v roku 2017, bola to téma, ktorú chcel robiť každý, no nikto ju nerobil. Každý už mal Kubernetes, ale keď sa pýtali, čo robiť s databázami, aj ľuďom sa to páči , ktorý kázal K8, povedal niečo takéto:
„Prejdite na spravované služby a používajte ich, nespúšťajte databázu v Kubernetes. V opačnom prípade sa vaše K8 rozhodnú napríklad urobiť upgrade, vypnúť všetky uzly a vaše dáta budú lietať ďaleko, ďaleko.“
Rozhodli sme sa urobiť operátora, ktorý na rozdiel od tejto rady spustí Postgres databázu v Kubernetes. A mali sme dobrý dôvod - . Ide o automatický failover pre PostgreSQL, urobený správne, t.j. pomocou etcd, consul alebo ZooKeeper ako úložisko informácií o klastri. Také úložisko, ktoré dá každému, kto sa napríklad pýta, aký je súčasný líder, rovnaké informácie – napriek tomu, že všetko máme rozdané – aby nedošlo k rozštiepeniu mozgu. Navyše sme mali pre neho.
Vo všeobecnosti sa potreba spoločnosti po automatickom núdzovom prepnutí objavila po migrácii z interného hardvérového dátového centra do cloudu. Cloud bol založený na proprietárnom riešení PaaS (Platform-as-a-Service). Je to Open Source, ale jeho uvedenie do prevádzky si vyžadovalo veľa práce. Nazývalo sa to .
Spočiatku neexistoval žiadny Kubernetes. Presnejšie, keď bolo nasadené naše vlastné riešenie, K8 už existovali, ale boli také hrubé, že sa nehodili na výrobu. Bol to podľa mňa rok 2015 alebo 2016. Do roku 2017 sa Kubernetes stal viac-menej dospelým – bolo potrebné tam migrovať.
A už sme mali kontajner Docker. Existoval PaaS, ktorý používal Docker. Prečo neskúsiť K8? Prečo nenapísať vlastného operátora? Murat Kabilov, ktorý k nám prišiel z Avita, to začal ako projekt z vlastnej iniciatívy – „hrať sa“ – a projekt sa „rozbehol“.
Ale vo všeobecnosti som chcel hovoriť o AWS. Prečo existoval historický kód súvisiaci s AWS...
Keď niečo spustíte v Kubernetes, musíte pochopiť, že K8s je taká nedokončená práca. Neustále sa vyvíja, zdokonaľuje a z času na čas sa dokonca rozpadá. Musíte pozorne sledovať všetky zmeny v Kubernetes, musíte byť pripravení ponoriť sa do toho, ak sa niečo stane, a naučiť sa, ako to funguje podrobne - možno viac, ako by ste chceli. Toto v zásade platí pre akúkoľvek platformu, na ktorej prevádzkujete svoje databázy...
Takže, keď sme urobili vyhlásenie, mali sme Postgres spustený na externom zväzku (v tomto prípade EBS, keďže sme pracovali na AWS). Databáza rástla, v určitom momente bolo potrebné zmeniť jej veľkosť: napríklad počiatočná veľkosť EBS bola 100 TB, databáza sa na ňu rozrástla, teraz chceme urobiť EBS 200 TB. Ako? Povedzme, že môžete urobiť výpis/obnovu na novej inštancii, ale bude to trvať dlho a bude to vyžadovať prestoje.
Preto som chcel zmenu veľkosti, ktorá by zväčšila oblasť EBS a potom povedala systému súborov, aby použil nový priestor. A urobili sme to, ale v tom čase Kubernetes nemal žiadne API na operáciu zmeny veľkosti. Keďže sme pracovali na AWS, napísali sme kód pre jeho API.
Nikto vám nebráni urobiť to isté pre iné platformy. Vo vyhlásení nie je žiadny náznak, že sa dá spustiť iba na AWS a nebude fungovať na všetkom ostatnom. Vo všeobecnosti ide o Open Source projekt: ak chce niekto urýchliť vznik používania nového API, ste vítaní. Jedzte , pull requesty – tím Zalando sa snaží na ne pomerne rýchlo reagovať a povýšiť operátora. Pokiaľ viem, projekt na Google Summer of Code a niektorých ďalších podobných iniciatívach. Zalando na tom veľmi aktívne pracuje.
PS Bonus!
Ak vás zaujíma téma PostgreSQL a Kubernetes, tak tiež upozorňujeme, že minulý týždeň sa konal ďalší Postgres utorok, kde som hovoril s Nikolaiom Alexander Kukushkin zo Zalanda. Video z neho je k dispozícii .
PPS
Prečítajte si aj na našom blogu:
- «»;
- «»;
- «»;
- «".
Zdroj: hab.com