Pagājušā gada beigās notika kārtējais tiešais pārraides Krievijas PostgreSQL kopienai , kurās tās līdzautore Nikolajs Samohvalovs sarunājās ar tehnisko direktoru "Flanta" Dimitriju Stoljārovu par šo DBMS kontekstā ar Kubernetes.
Mēs publicējam šīs diskusijas galvenās daļas stenogrammu, bet publicēta pilna videoieraksts:
Datu bāzes un Kubernetes
NS: Šodien mēs nerunāsim par VACUUM un CHECKPOINT. Mēs vēlamies runāt par Kubernetes. Es zinu, ka tev jau daudz gadu pieredzes. Esmu skatījies tavus video un dažus pat atkārtoti skatījies... Sāksim no vietas: kāpēc vispār Postgres vai MySQL K8s?
DS: Uz šo jautājumu nav viennozīmīgas atbildes un nevar būt. Bet vispār – tā ir vienkāršība un ērtība... potenciāli. Ikvienam taču gribas managed pakalpojumus.
NS: Lai kā , tikai pie sevis?
DS: Jā: lai kā RDS, tikai jebkur.
NS: "Jebkur" — tas ir labs novērojums. Lielās kompānijās viss ir izvietots dažādās vietās. Un kāpēc tad, ja tā ir liela kompānija, neizmantot gatavu risinājumu? Piemēram, Nutanix ir savi izstrādājumi, citām kompānijām (VMware…) ir tas pats "RDS, tikai pie sevis".
DS: Bet mēs runājam par atsevišķu ieviešanu, kas darbosies tikai noteiktos apstākļos. Bet ja runājam par Kubernetes, tad šeit ir milzīga infrastruktūras daudzveidība (kas var būt K8s). Patiesībā tā ir standarts API uz mākoņa...
NS: Vēl arī bez maksas!
DS: Tas nav tik svarīgi. Bezmaksas ir svarīgi ne ļoti lielai tirgus daļai. Svarīgāks ir cits jautājums... Tu, iespējams, atceries ziņojumu "»?
NS: Jā.
DS: Es sapratu, ka to uztvēra ļoti neskaidri. Daļa cilvēku domāja, ka es saku: "Puiši, braucam visus DB Kubernetes!", — bet citi nolēma, ka tas viss ir kaut kādi šausmīgi velosipēdi. Bet es gribēju teikt kaut ko pavisam citu: "Skatieties, kas notiek, kādas ir problēmas un kā tās var risināt. Vai tagad pārvietoties datubāzēs Kubernetes? Uz ražošanu? Nu, tikai, ja jūs mīlat... nodarboties ar noteiktām lietām. Bet dev'iem — varu teikt, ka iesaku. Dev'iem ļoti svarīga ir dinamika vides izveidē/nosūtīšanā."
NS: Par dev'iem tu domā visus vidējumus, kas nav produkcija? Staging, QA...
DS: Ja, runājot par perf-stendiem, droši vien, ka nē, jo tur prasības ir specifiskas. Ja runājam par īpašiem gadījumiem, kur staging nepieciešama ļoti liela DB, tad arī droši vien, ka nē… Ja tas ir statisks vidē, ilgstošs, tad kāda ir ieguvums, ka datu bāze atrodas K8s?
NS: Necita. Bet kur mēs redzam statiskus vidē? Statiskā vide ir novecojusi jau rīt.
DS: Staging var būt statisks. Mums ir klienti…
NS: Jā, man arī ir. Liela problēma, ja tev ir datu bāze uz 10 TB, bet staging — 200 GB…
DS: Man ir ļoti foršs gadījums! Staging atrodas prod’ova datu bāze, kurā veic izmaiņas. Un ir paredzēta poga: „izlaist ražošanā”. Šīs izmaiņas — deltās — tiek pievienotas (šķiet, vienkārši pa API sinhronizējas) produkcijā. Tas ir ļoti eksotisks variants.
NS: Es esmu redzējis start-upus ielejā, kas sēž RDS’ē vai pat vēl Heroku — tās ir stāsti no pirms 2-3 gadiem, — un viņi lejupielādē datu dumpu uz sava klēpjdatora. Jo datu bāze ir tikai 80 GB, un klēpjdatorā ir vieta. Pēc tam viņi iegādājas diskus katram, lai būtu pa 3 datu bāzēm, lai varētu veikt dažādas izstrādes. Tā arī notiek. Esmu redzējis, ka nebaidās kopēt prod uz staging — tas ļoti atkarīgs no uzņēmuma. Bet esmu redzējis arī, ka ļoti baidās, un bieži trūkst laika un roku. Bet pirms mēs pārejam uz šo tēmu, gribu dzirdēt par Kubernetes. Vai es pareizi saprotu, ka prod’ā vēl nevienam nav?
DS: Mums ir nelielas datu bāzes prod’ā. Runa ir par apjomiem desmitos gigabaitu un nekritiskiem pakalpojumiem, kur priekšā nebija izdevību veidot replikas (un nav vajadzības). Un pie nosacījuma, ka zem Kubernetes’a ir normāla glabātuve. Šī datu bāze darbojās virtuālajā mašīnā — nosacīti VMware, virs SChD. Mēs to ievietojām un tagad varam to pārvietot no mašīnas uz mašīnu.
NS: Datu bāzes šāda izmēra, līdz 100 GB, uz labiem diskiem un labā tīklā var izplatīt dažu minūšu laikā, vai ne? Ātrums 1 GB sekundē — tas jau nav eksotisks.
DS: Jā, lineāra operācija tas nav problēma.
NS: Ok, par prod mēs tikai jāmāca. Bet ja aplūkojam Kubernetes ne-prod vidēm — kā rīkoties? Es redzu, ka Zalando , Crunchy , ir vēl kādi varianti. Un ir — tas ir mūsu labs draugs Alvaro no Spānijas: viņi praktiski neizstrādā tikai , bet visu distribūciju (), kurā papildus pašam Postgres ir iekļauta arī dublēšana, proxy Envoy…
DS: Envoy kādēļ? Postgres datu plūsmas sadalīšanai?
NS: Jā. Tātad viņi to redz tā: ja ņem Linux izplatījumu un kodolu, tad parasts PostgreSQL ir kodols, bet viņi vēlas izveidot izplatījumu, kas būs draudzīgs mākoņiem un darbosies Kubernetes. Viņi savieno komponentus (dublējumus utt.) un pielāgo, lai tie labi darbotos.
DS: Ļoti forši! Principā tas ir programmatūra, lai izveidotu savu pārvaldīto Postgres.
NS: Linux izplatījumiem ir mūžīgas problēmas: kā izstrādāt draiverus, lai viss ekipējums tiktu atbalstīts. Un viņiem ir ideja, ka tie darbosies Kubernetes. Es zinu, ka operatorā Zalando nesen redzējām saikni ar AWS, un tas jau nav labi. Nedrīkst taču būt atkarībai no konkrētas infrastruktūras — kāda tad ir jēga?
DS: Nezinu, kādā situācijā tieši Zalando saistījās, bet Kubernetes šobrīd krātuve ir izstrādāta tā, ka vispārīgi nevar izveidot diskdublējumu. Nesen standartā — jaunākajā versijā — ir izveidota iespēja veikt momentuzņēmumus, bet kur tas ir īstenots? Godīgi sakot, joprojām viss ir tik nenobriedis… Mēs izmēģinām CSI virs AWS, GCE, Azure, vSphere, bet tiklīdz sākat lietot, ir redzams, ka tas vēl nav gatavs.
NS: Tāpēc dažreiz nākas saistīties ar infrastruktūru. Domāju, tas vēl ir agrīnā stadijā — izaugsmes problēmas. Jautājums: ko tu ieteiktu iesācējiem, kuri vēlas izmēģināt PgSQL K8s? Kādu operatoru, varbūt?
DS: Problēma ir tajā, ka Postgres mums ir 3%. Mums ir vēl ļoti liels saraksts ar dažādu programmatūru Kubernetes, pat nepateikšu visu. Piemēram, Elasticsearch. Operatoru ir daudz: daži aktīvi attīstās, citi — nē. Mēs esam izveidojuši prasības, kādām jābūt operatoram, lai mēs to ņemtu nopietni. Operatorā tieši Kubernetes — nevis „operators, lai kaut ko darītu Amazon apstākļos”… Faktiski mēs diezgan plaši (= gandrīz visiem klientiem) izmantojam vienīgo operatoru — (drīz publicēsim rakstu arī par to).
NS: Bet MySQL arī nav? Es zinu, ka Percona… tā kā viņi tagad nodarbojas gan ar MySQL, gan MongoDB, gan Postgres, viņiem vajadzētu izstrādāt kādu universālu risinājumu: visām datu bāzēm, visiem mākoņu pakalpojumu sniedzējiem.
DS: Mēs nesagaidījām iespēju apskatīt MySQL operatorus. Tas šobrīd nav mūsu galvenā uzmanība. MySQL normāli strādā patstāvīgi. Kāpēc operatoram, ja var vienkārši palaist datubāzi... Var palaist Docker konteineru ar Postgres, vai arī to izdarīt vienkārši.
NS: Par to arī bija jautājums. Vispār bez operatora?
DS: Jā, 100% gadījumu mūsu PostgreSQL darbojas bez operatora. Pag пока tā ir. Mēs aktīvi izmantojam operatoru Prometheus, Redis. Mums ir plānos atrast operatoru Elasticsearch — tas ir visvairāk
Datubāze testēšanai Kubernetes
NS: Pāriesim pie testēšanas tēmas. Kā veikt izmaiņu izplatīšanu datubāzē — no DevOps perspektīvas. Ir mikrosistēmas, daudz datubāzu, visu laiku kaut kas mainās. Kā nodrošināt normālu CI/CD, lai datubāzes puse būtu kārtībā? Kāds ir tavs pieejas veids?
DS: Nav viena pareizā atbildes. Ir vairāki parametri. Pirmais — tas ir datubāzes apjoms, kuru mēs vēlamies izplatīt. Tu pats pieminēji, ka uzņēmumos atšķirīgi attieksme pret to, lai prod-datubāze būtu dev un stage.
NS: Bet GDPR apstākļos, es domāju, viņi attiecina aizvien lielāku uzmanību... Varu teikt, ka Eiropā jau ir sākuši piemērot sodus.
DS: Bet bieži var uzrakstīt programmatūru, kas veic dumpi no ražošanas un to obfūzē. Tiek iegūti ražošanas dati (snapšots, dumpis, binārā kopija...), bet anonimizēti. Tā vietā var būt arī ģenerēšanas skripti: tas varētu būt fikstūras vai vienkārši skripts, kas ģenerē lielu datubāzi. Problēma ir tāda: cik ilgi tiek izveidota pamatattēls? Un cik ilgi to ir jāuzstāda vajadzīgajā vidē?
Mēs nonācām pie shēmas: ja klientam ir fikstūru datu kopums (minimālā versija datubāzes), tad pēc noklusējuma izmantojam tos. Ja runājam par review-vidēm, kad mēs esam izveidojuši zaru, mums ir uzstādīts lietojumprogrammas instances — mēs tur izplatām nelielu datubāzi. Bet viss ir izdevies labi. , kad no produkcijas reizi dienā (nakts laikā) ņemam dublējumu un veidojam uz tā pamata Docker konteineru ar PostgreSQL un MySQL, kas satur šo ielādēto informāciju. Ja no šī attēla jāizveido datu bāze 50 reizes, tad tas tiek darīts diezgan vienkārši un ātri.
NS: Ar vienkāršu kopēšanu?
DS: Dati tiek glabāti tieši Docker attēlā. T.i., mums ir gatavs attēls, lai arī 100 GB liels. Pateicoties Docker kārtām, mēs varam ātri izveidot šo attēlu vajadzīgajā daudzumā. Metode ir primitīva, bet darbojas diezgan labi.
NS: Tā kā, kad testē, tas tieši iekšā Docker tiek mainīts, vai ne? Copy-on-write iekšā Docker — izmetam un sākam no jauna, viss kārtībā. Super! Un jūs to jau aktīvi izmantojat?
DS: Jā, jau kādu laiku.
NS: Mēs nodarbojamies ar ļoti līdzīgām lietām. Tikai mēs neizmantojam Docker copy-on-write, bet kaut ko citu.
DS: Tas nav vispārējs. Bet Docker variants darbojas visur.
NS: Teorētiski jā. Bet mums tur juga ir moduļi, var izveidot dažādus moduļus un strādāt ar dažādām failu sistēmām. Šeit ir tāda lieta. Mēs no PostgreSQL puses uz visu to skatāmies citādi. Tagad es skatījos no Docker puses un redzēju, ka jums viss darbojas. Bet, ja datu bāze ir milzīga, piemēram, 1 TB, tad tas viss jau ir lēns: gan operācijas naktī, gan viss jāpagriež Docker… Bet ja 5 TB jāpagriež Docker… Vai tad viss ir kārtībā?
DS: Kāda starpība: taču tas ir blobi, tikai biti un baitos.
NS: Starpība ir tāda: vai jūs to veicat caur dublēšanu un atjaunošanu?
DS: Pilnīgi nav obligāti. Attēla ģenerēšanas veidi var būt dažādi.
NS: Dažiem klientiem mēs izveidojām tā, ka vietā, lai regulāri ģenerētu pamata attēlu, mēs to pastāvīgi uzturam aktuālā stāvoklī. Tas būtībā ir replikācija, bet dati tiek saņemti ne tieši no meistarā, bet gan caur arhīvu. Binārais arhīvs, kur WAL tiek pievienoti katru dienu, turpat tiek izveidoti dublējumi… Šie WAL pēc tam aizlido — ar nelielu aizturi (burtiski 1-2 sekundes) — līdz pamata attēlam. No tā mēs varam jebkurā veidā klonēt — šobrīd mūsu noklusējums ir ZFS.
DS: Bet ar ZFS jūs esat ierobežoti ar vienu mezglu.
NS: Jā. Bet ZFS ir vēl viens burvju : ar to var nosūtīt snapshots un pat (es to vēl neesmu ļoti testējis, bet…) var nosūtīt delta starp diviem PGDATA. Patiesībā mums ir vēl viens rīks, ko mēs neesam īpaši apsvēruši šādām vajadzībām. PostgreSQL ir , darbojo kā "gudrais" rsync, izslēdzot daudz ko, ko nevar skatīties, jo tur tiešām nekas nav mainījies. Mēs varam veikt ātru sinhronizāciju starp diviem serveriem un atgriezties atpakaļ tieši tāpat.
Tātad, mēs cenšamies no šīs, vairāk DBA puses, izveidot rīku, kas ļauj izdarīt to pašu, par ko tu runāji: mums ir viena datubāze, bet mēs vēlamies 50 reizes kaut ko testēt, teju vienlaicīgi.
DS: 50 reizes nozīmē, ka jums jāpasūta 50 Spot instance.
NS: Nē, visu darām uz vienas mašīnas.
DS: Bet kā jūs izveidosiet 50 reizes, ja šī viena datubāze, teiksim, ir terabaitu? Droši vien tai vajag, nosacīti, 256 GB RAM?
NS: Jā, atmiņas dažreiz nepieciešams daudz — tas ir normāli. Bet šāds piemērs no dzīves. Produkcijas mašīnā ir 96 kodoli un 600 GB. Tajā pašā laikā datubāzēm tiek izmantoti 32 kodoli (pat 16 kodoli tagad dažreiz) un atmiņa 100-120 GB.
DS: Un tur ietilpst 50 kopijas?
NS: Bet kopija ir viena, tālāk darbojas copy-on-write (ZFS)... pastāstīšu sīkāk.
Mums, piemēram, datubāze uz 10 TB. Disks tam ir izveidots, ZFS vēl sarukusi tās lielumu par 30-40%. Tā kā mēs neveicam slodzi testēšanu, mums precīzs atbildes laiks nav svarīgs: lai būtu līdz 2 reizes lēnāk — tas ir normāli.
Mēs sniedzam iespēju programmētājiem, QA, DBA un tamlīdzīgiem veikt testēšanu 1-2 pavedienos. Piemēram, viņi var palaist kādu migrāciju. Tai nav nepieciešami uzreiz 10 kodoli — tai vajag 1 Postgres aizmuguri, 1 kodolu. Migrācija tiks uzsākta — iespējams, vēl kāda lēks, tad otrais kodols tiks iesaistīts. Mums ir atvēlēti 16-32 kodoli, tāpēc 10 cilvēki var strādāt vienlaicīgi, problēmu nav.
Tā kā fiziski PGDATA ir vienādi, iznāk tā, ka mēs patiesībā maldinām Postgres. Jautājums ir šāds: tiek palaisti, piemēram, 10 Postgres vienlaikus. Parasti problēma ir kāda? Iestata , teiksim, 25%. Attiecīgi, tas ir 200 GB. Vairāk par trim tādiem vairs neiesāks, jo atmiņa beigsies.
Bet kādā brīdī mēs sapratām, ka tas nav nepieciešams: mēs iestatām shared_buffers uz 2 GB. PostgreSQL ir , un realitātē tikai tas ietekmē . To mēs iestatām uz 0,5 TB. Pat nav svarīgi, ka viņi patiesībā nav: viņš veido plānus, it kā tie būtu.
Attiecīgi, kad mēs pārbaudām kādu migrāciju, varam apkopot visus plānus — mēs redzēsim, kā tas notiks ražošanā. Sekundes tur būs citas (lēnākas), bet dati, kurus mēs faktiski iegūstam, un paši plāni (kādi tur būs JOIN'leri u.tml.) iznāk precīzi tādi paši kā ražošanā. Un paralēli var palaist vairākas šādas pārbaudes uz vienas mašīnas.
DS: Vai tu neuzskati, ka šeit ir dažas problēmas? Pirmā — tas ir risinājums, kas darbojas tikai uz PostgreSQL. Šāds piegājiens ir ļoti specifisks, tas nav ģenerisks. Otrā — Kubernetes (un viss, uz ko tagad virzās mākoņu tehnoloģijas) paredz daudzas mezglu sistēmas, un šie mezgli ir efemēri. Bet tavā gadījumā tas ir stateful, persistejošs mezgls. Šīs lietas man rada pretrunas.
NS: Pirmkārt — piekrītu, tas ir tīri Postgres stāsts. Domāju, ja mums ir kāds direct IO un buferu baseins gandrīz visai atmiņai, šāds piegājiens nederēs — plāni būs citi. Bet mēs pagaidām strādājam tikai ar Postgres, par citiem nedomājam.
Par Kubernetes. Tu taču pats visur stāsti, ka mūsu datubāze ir persistejoša. Ja instances sabrūk, svarīgi ir saglabāt disku. Aizpildām arī visu platformu Kubernetes, bet komponents ar Postgres ir atsevišķi (lai gan reiz viņš tur būs). Tāpēc viss ir tā: instances sabrūk, bet mēs saglabājām viņa PV un vienkārši pievienojām to citam (jaunam) instancei, it kā nekas nebūtu noticis.
DS: No manas skatupunkta, mēs izveidojam podus Kubernetes. K8s ir elastīgs: mezgli tiek pasūtīti paši pēc nepieciešamības. Uzdevums — vienkārši izveidot pod un pateikt, ka tam nepieciešami X resursi, bet tālāk K8s pats tiks galā. Taču atbalsts krātuves risinājumiem Kubernetes joprojām ir nestabils: , vienā no saviem ziņojumiem (šis izlaidums iznāca nedēļas pirms) šīs īpašības kļūst tikai par beta versijām.
Pagājuši seši mēneši-gads — tas kļūs par vairāk vai mazāk stabilu, vai vismaz tiks pasludināts tāds. Tad iespēja nolikt uzkrājumus un resize jau pilnībā atrisina jūsu uzdevumu. Jo jums ir datubāze. Jā, tā var nebūt ļoti ātra, bet ātrums ir atkarīgs no tā, kas ir "zem kapota", jo dažas realizācijas spēj veikt kopēšanu un copy-on-write disku sistēmas līmenī.
NS: Šeit vēl jānodrošina, lai visi dzinēji (Amazon, Google...) paspētu uzsākt atbalstīt šo versiju — tas arī prasa kādu laiku.
DS: Kamēr mēs tos neizmantojam. Mēs izmantojam savu.
Vietējā izstrāde Kubernetes
NS: Vai tu esi saskāries ar tādu vēlēšanos, kad vienā mašīnā ir jāizveido visi podi un jāveic neliels tests. Lai ātri iegūtu pierādījumu par konceptu, redzētu, ka lietojumprogramma darbojas Kubernetes, nepārdalot uz to daudz mašīnu. Ir taču Minikube, vai ne?
DS: Man šķiet, ka šis gadījums — izvietot uz viena mezgla — ir tīri lokālai izstrādei. Vai arī kādiem šāda rakstura izpausmēm. Ir , ir , . Mēs virzāmies uz to, lai izmantotu Kubernetes IN Docker. Tagad sākām ar to strādāt testiem.
NS: Agrāk es domāju, ka tas ir mēģinājums iesaiņot visus podus vienā Docker attēlā. Bet izrādās, ka tas ir pavisam par citu. Joprojām tur ir atsevišķas konteineru, atsevišķi podi — vienkārši Docker iekšienē.
DS: Jā. Un tur ir diezgan interesanta imitācija izveidota, bet doma ir šāda… Mums ir utilīta deploy — . Mēs vēlamies tajā izveidot režīmu – nosacīti werf up: „Uzcel man vietējo Kubernetes”. Un pēc tam palaist tur nosacītu werf follow. Tad izstrādātājs varēs labot IDE, bet sistēmā darbojas process, kas redz izmaiņas un pārbūvē attēlus, pārdepoyē tos lokālajā K8s. Tādējādi mēs gribam mēģināt atrisināt vietējās izstrādes problēmu.
Snaipšoti un datubāzu klonēšana K8s realitātēs
NS: Ja atgriežas pie copy-on-write. Es pamanīju, ka arī mākoņiem ir snaipšoti. Tie darbojas atšķirīgi. Piemēram, GCP: tev ir daudzterabaitu instances Amerikas austrumu krastā. Periodiski veic snaipšotus. Pacel no snaipšota kopiju diska uz rietumu krastu — dažu minūšu laikā viss jau ir gatavs, strādā ļoti ātri, tikai kešs jāsatiprina atmiņā. Bet šie kloni (snaipšoti) ir, lai „provision” jaunu apjomu. Tas ir forši, kad vajag izveidot daudz instanču.
Bet testiem, man šķiet, snaipšoti, par kuriem tu stāsti Docker’ā vai es stāstu ZFS, btrfs un pat LVM... — tie ļauj tieši uz viena datora neizveidot reālas jaunas datu kopijas. Mākonī tu vēl maksāsi par tiem katru reizi un gaidīsi vairs ne sekundes, bet minūtes (bet pie , iespējams, pat stundas).
Tā vietā tu vari iegūt šos datus dažu sekunžu laikā, veikt testu un izmest. Šie snaipšoti risina dažādas problēmas. Pirmajā gadījumā — lai palielinātos un iegūtu jaunas replikas, bet otrajā — testiem.
DS: Nesotriešu. Veikt normālu tiltu klonēšanu — tas ir mākoņa uzdevums. Es neesmu skatījies uz viņu īstenojumu, bet zinu, kā to darām mēs uz dzelžiem. Mums ir Ceph, tajā var jebkuram fiziskam tiltam () teikt clone un iegūt dažu desmitu milisekunžu laikā otro tiltu ar tādām pašām specifikācijām, utml. Jāsaprot, ka tur iekšā ir sarežģīts copy-on-write. Kāpēc mākoņiem to nedarīt tāpat? Esmu pārliecināts, ka viņi vienā vai otrā veidā cenšas to izdarīt.
NS: Bet viņiem joprojām aizņems sekundes, desmitiem sekunžu, lai izgaisinātu instance, novietotu tur Docker utt.
DS: Kāpēc obligāti jāuzceļ visa instance? Mums taču ir instance ar 32 kodoliem, ar 16… un tajā iekļaujas noteikts skaits — piemēram, četri. Kad mēs pasūtām piekto, jau uzcelsies instance, un tad tā tiks dzēsta.
NS: Jā, interesanti, ka Kubernetes iznāk cita stāsts. Mums BDs nav K8s, un viena instance. Toties daudzu terabaitu datu klonēšanai nepaiet vairāk par divām sekundēm.
DS: Tas ir lieliski. Bet mans sākotnējais uzsvars ir uz to, ka tas nav generisks risinājums. Jā, tas ir foršs, bet der tikai Postgres un tikai uz viena mezgla.
NS: Tas der ne tikai Postgres: šie plāni, kā es aprakstīju, darbosies tikai tajā. Bet ja nesatrauktu par plāniem, bet mums vienkārši ir nepieciešami visi dati funkcionālai testēšanai, tad tas derēs jebkurai DBMS.
DS: Pirms daudziem gadiem mēs darījām līdzīgu uz LVM momentuzņēmumiem. Tas ir klasika. Šāds risinājums tika ļoti aktīvi izmantots. Vienkārši stateful mezgli — tā ir sāpīga vieta. Jo tos nevar laist vaļā, vienmēr par tiem jāatceras...
NS: Vai tu neredzi šeit kādu hibrīda iespēju? Pieņemsim, ka stateful — tas ir kāds pods, kas strādā uz vairākiem cilvēkiem (daudziem testētājiem). Mums ir viens tilts, bet pateicoties failu sistēmai kloni — lokāli. Ja pods nokrīt, disks paliek — pacelsies pods, informāciju par visiem kloniem nolasīs, visu atpakaļ pacels un teiks: «Lūk, jūsu kloni šajos portos ir uzsākti, strādājiet ar tiem tālāk».
DS: Tehniski tas nozīmē, ka Kubernetes ietvaros tas ir viens pods, iekš kurām mēs palaidīsim daudz Postgres’ u.
NS: Jā. Tam ir ierobežojums: pieņemsim, ka vienlaicīgi ar to strādā ne vairāk kā 10 cilvēki. Ja nepieciešami 20 — palaidīsim otro tādu pašu podu. Pilnīgi reāli to klonēt, iegūstot otro pilnīgu tiltu, uz kura būs tādi paši 10 «plānie» kloni. Vai tu neredzi tādu iespēju?
DS: Jā, būtu jāiekļauj šeit drošības jautājumi. Šāda organizācija nozīmē, ka šim podam ir augstas privilēģijas (capabilities), jo tas var veikt nestandarta operācijas failu sistēmā… Bet atkārtošu: es uzskatu, ka vidējā termiņā Kubernetes novērsīs glabāšanu, mākoņos tiks atrisināta visa apjoma problēma — viss darbosies
NS: Neesmu pārliecināts par pusotru sekundi daudziem terabaitiem. Ceph tu dari pats, bet tu runā par mākoņiem. Aiziet uz mākoņu, EC2 izveido klonu EBS apjoma daudzu terabaitu un paskaties, kāda būs veiktspēja. Tas neaizņems dažas sekundes. Man ļoti interesē, kad viņi sasniegs šādu rādītāju. Saprotu, par ko tu runā, bet ļaušos nepiekrīt.
DS: Labi, bet es teicu, ka vidējā termiņā, nevis īstermiņā. Dažu gadu laikā.
Par PostgreSQL operatoru no Zalando
Šīs tikšanās vidū pie viņas pievienojās arī Aleksejs Kļukins, bijušais izstrādātājs no uzņēmuma Zalando, kurš pastāstīja par PostgreSQL operatora vēsturi:
Forši, ka vispār šī tēma ir pieskārta: gan Postgres, gan Kubernetes. Kad mēs sākām to darīt Zalando 2017. gadā, tā bija tēma, ar kuru visi vēlējās nodarboties, bet neviens to nedarīja. Visi jau ieguva Kubernetes, bet, kad jautāja, ko darīt ar datu bāzēm, pat tādi cilvēki kā , kas sludināja K8s, teica apmēram sekojošo:
«Iet uz pārvaldītajiem pakalpojumiem un izmantojiet tos, nepalaižiet DB Kubernetes. Pretējā gadījumā jūsu K8s izlemt, piemēram, veikt atjauninājumu, izslēgs visus mezglus, un jūsu dati aizlidos tālu, tālu».
Mēs nolēmām izveidot operatoru, kurš, par spīti šai padomam, palaidīs Postgres DB Kubernetes. Un mums bija labs pamats — . Tas ir automātiskais failover PostgreSQL, kuru veic pareizi, t.i., izmantojot etcd, consul vai ZooKeeper kā informācijas par klasteri glabātuvi. Šāda glabātuve, kas visiem, kas jautā, piemēram, sniegs vienu un to pašu informāciju par to, kurš pašlaik ir vadītājs — neskatoties uz to, ka mums viss ir izkaisīts — lai nebūtu split brain. Turklāt mums bija tam.
Vispār, uzņēmumam radās nepieciešamība pēc auto failover pēc pārejas no iekšējā datu centra uz mākoni. Mākonis tika balstīts uz paša izstrādātu PaaS (Platform-as-a-Service) risinājumu. Tas ir atvērta koda, taču, lai to uzsāktu, bija jāiegulda liels darbs. Tas tika saukts par .
Sākotnēji nebija nekādu Kubernetes. Precīzāk, kad tika īstenots mūsu risinājums, K8s jau pastāvēja, taču bija tik nepilnīgs, ka produkcijai nebija izmantojams. Domāju, tas bija 2015. vai 2016. gadā. Līdz 2017. gadam Kubernetes kļuva samērā nobriedis — radās nepieciešamība migrēt uz to.
Un mums jau bija Docker konteiners. Pastāvēja PaaS, kas izmantoja Docker. Kāpēc neizmēģināt K8s? Kāpēc neuzrakstīt savu operatoru? Murats Kabilovs, kurš pievienojās mums no Avito, sākotnēji uzsāka šo projektu pēc savas iniciatīvas — "paspēlēties", — un projekts "uzsākās".
Bet vispār es gribēju pastāstīt par AWS. Kāpēc tur bija vēsturiski kods, kas saistīts ar AWS…
Kad jūs uzsākat jebko Kubernetes, jāatceras, ka K8s ir tāds darbs progresā. Tas pastāvīgi attīstās, uzlabojas un periodiski pat sabojas. Jāseko visām izmaiņām Kubernetes, jābūt gatavam, ja kaut kas notiks, iedziļināties tajā un uzzināt, kā tas darbojas detaļās — iespējams, pat vairāk, nekā jums patiktu. Tas attiecas uz jebkuru platformu, uz kuras jūs uzsākat savas DB…
Tātad, kad mēs izstrādājām operatoru, mums bija Postgres, kas strādāja ar ārējo apjomu (šajā gadījumā — EBS, jo mēs strādājām AWS). Datu bāze pieauga, un kādā brīdī nācās veikt resize: piemēram, sākotnējais EBS apjoms bija 100 TB, datu bāze pieauga līdz tam, tagad vēlamies EBS 200 TB. Kā? Pieņemsim, ka var izveidot dump/restore uz jauna instancēm, bet tas ir ilgs un ar dīkstāvi.
Tāpēc mēs vēlējāmies tādu resize, kas palielinātu EBS daļu un pēc tam norādītu failu sistēmai izmantot jauno vietu. Mēs to izdarījām, taču tajā laikā Kubernetes nebija nekādas API operācijai resize. Tā kā mēs strādājām AWS, uzrakstījām kodu tā API.
Neviens netraucē izdarīt to pašu citām platformām. Operatorā nav saistības, ka to var palaist tikai AWS, un uz visu citu tas nedarbosies. Kopumā tas ir atvērta koda projekts: ja kāds vēlas paātrināt jaunā API izmantošanas parādīšanos — laipni lūdzam. Ir , pull pieprasījumi — Zalando komanda cenšas diezgan operatīvi uz tiem reaģēt un virzīt operatoru. Cik zinu, projekts Google Summer of Code un citās līdzīgās iniciatīvās. Zalando ļoti aktīvi strādā pie tā.
P.S. Bonuss!
Ja jūs interesē tēma PostgreSQL un Kubernetes, tad jāņem vērā, ka pagājušajā nedēļā notika nākamais Postgres otrdiena, kur Nikolajs sarunājās ar Aleksandru Kukuškinu no Zalando. Video no tā ir pieejams .
P.P.S.
Lasiet arī mūsu emuāra rakstos:
- «»;
- «»;
- «»;
- «».
Avots: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish