Pagājušā gada nogalē notika vēl viena Krievijas PostgreSQL kopienas tiešraide , kuras laikā tās līdzdibinātājs Nikolajs Samohvalovs runāja ar Flant tehnisko direktoru Dmitriju Stoļarovu par šo DBVS Kubernetes kontekstā.
Publicējam šīs diskusijas galvenās daļas atšifrējumu, un plkst Pilns video ievietots:
Datu bāzes un Kubernetes
NS: Mēs šodien nerunāsim par VAKUUMU un PĀRBAUDES PUNKTIEM. Mēs vēlamies runāt par Kubernetes. Es zinu, ka jums ir daudzu gadu pieredze. Es noskatījos jūsu videoklipus un pat noskatījos dažus no tiem atkārtoti... Sāksim uzreiz pie lietas: kāpēc Postgres vai MySQL vispār K8s?
DS: Uz šo jautājumu nav un nevar būt konkrētas atbildes. Bet kopumā tā ir vienkāršība un ērtības... potenciāls. Ikviens vēlas pārvaldītus pakalpojumus.
NS: Kā , tikai mājās?
DS: Jā: tāpat kā RDS, jebkurā vietā.
NS: “Jebkur” ir labs punkts. Lielajos uzņēmumos viss atrodas dažādās vietās. Kāpēc tad, ja tas ir liels uzņēmums, neņemt gatavu risinājumu? Piemēram, Nutanix ir savas izstrādes, citiem uzņēmumiem (VMware...) ir tas pats “RDS, tikai mājās”.
DS: Bet mēs runājam par atsevišķu ieviešanu, kas darbosies tikai noteiktos apstākļos. Un, ja mēs runājam par Kubernetes, tad tur ir ļoti daudz dažādu infrastruktūru (kas var būt K8s). Būtībā šis ir mākoņa API standarts...
NS: Tas ir arī bez maksas!
DS: Tas nav tik svarīgi. Brīvība ir svarīga ne pārāk lielam tirgus segmentam. Svarīgs ir kas cits... Jūs droši vien atceraties ziņojumu “"?
NS: Jā.
DS: Sapratu, ka tas tika uztverts ļoti neviennozīmīgi. Dažiem likās, ka es saku: "Puiši, ielaidīsim visas datubāzes Kubernetes!", bet citi uzskatīja, ka tie visi ir briesmīgi velosipēdi. Bet man gribējās teikt pavisam ko citu: “Paskatieties, kas notiek, kādas ir problēmas un kā tās var atrisināt. Vai mums tagad vajadzētu izmantot Kubernetes datu bāzes? Ražošana? Nu, tikai tad, ja jums patīk... darīt noteiktas lietas. Bet izstrādātājam varu teikt, ka iesaku. Izstrādātājiem vides izveides/dzēšanas dinamisms ir ļoti svarīgs.
NS: Vai ar izstrādātāju jūs domājat visas vides, kas nav ražotas? Iestudējums, kvalitātes nodrošināšana…
DS: Ja mēs runājam par perf stendiem, tad droši vien nē, jo prasības tur ir specifiskas. Ja mēs runājam par īpašiem gadījumiem, kad inscenēšanai nepieciešama ļoti liela datu bāze, tad droši vien nē... Ja šī ir statiska, ilgstoša vide, tad kāds labums no tā, ka datubāze atrodas K8s?
NS: Nav. Bet kur mēs redzam statisku vidi? Rīt statiska vide kļūs novecojusi.
DS: Iestudējums var būt statisks. Mums ir klienti...
NS: Jā, man arī tāds ir. Tā ir liela problēma, ja jums ir 10 TB datu bāze un 200 GB inscenējums...
DS: Man ir ļoti foršs gadījums! Uzstādīšanas laikā ir produktu datu bāze, kurā tiek veiktas izmaiņas. Un ir poga: “izrullēt uz ražošanu”. Šīs izmaiņas - deltas - tiek pievienotas (šķiet, ka tās ir vienkārši sinhronizētas, izmantojot API) ražošanā. Šī ir ļoti eksotiska iespēja.
NS: Esmu redzējis jaunuzņēmumus Valley, kas darbojas RDS vai pat Heroku — tie ir stāsti pirms 2–3 gadiem — un viņi lejupielādē izgāztuvi savā klēpjdatorā. Jo datubāze joprojām ir tikai 80 GB, un klēpjdatorā ir vieta. Tad viņi iegādājas papildu diskus katram, lai viņiem būtu 3 datu bāzes, lai veiktu dažādas izstrādes. Tā tas arī notiek. Es arī redzēju, ka viņi nebaidās kopēt prod iestudējumā - tas ir ļoti atkarīgs no uzņēmuma. Bet es arī redzēju, ka viņi ļoti baidās, un viņiem bieži vien nepietiek laika un roku. Bet, pirms mēs pārejam pie šīs tēmas, es vēlos dzirdēt par Kubernetes. Vai es pareizi saprotu, ka neviens vēl nav prod?
DS: Mums ir nelielas datu bāzes ražošanā. Mēs runājam par desmitiem gigabaitu apjomiem un nekritiskiem pakalpojumiem, kuriem mēs bijām pārāk slinki, lai izveidotu kopijas (un tādas vajadzības nav). Un ar nosacījumu, ka zem Kubernetes ir normāla krātuve. Šī datu bāze darbojās virtuālajā mašīnā - nosacīti VMware, virs atmiņas sistēmas. Mēs to ievietojām un tagad mēs varam to pārsūtīt no mašīnas uz mašīnu.
NS: Šāda izmēra datu bāzes, līdz 100 GB, var izvilkt dažu minūšu laikā labos diskos un labā tīklā, vai ne? Ātrums 1 GB sekundē vairs nav eksotisks.
DS: Jā, lineārai darbībai tā nav problēma.
NS: Labi, mums tikai jādomā par prod. Un, ja mēs apsveram Kubernetes izmantošanu vidēm, kas nav ražotas, kas mums jādara? Es to redzu Zalando , in Crunchy , ir vēl dažas iespējas. Un ir - tas ir mūsu labs draugs Alvaro no Spānijas: tas, ko viņi dara, būtībā nav tikai , un viss sadalījums (), kurā bez paša Postgres nolēma iebāzt arī rezerves kopiju, Envoy proxy...
DS: Sūtni par ko? Vai īpaši līdzsvarot Postgres trafiku?
NSJā. Tas ir, viņi to uztver šādi: ja jūs ņemat LinuxJa mēs runājam par distributīvu un kodolu, tad parastais PostgreSQL ir kodols, un viņi vēlas izveidot distributīvu, kas ir draudzīgs mākonim un darbojas uz Kubernetes. Viņi savieno komponentus (rezerves kopijas utt.) un veic to atkļūdošanu, lai nodrošinātu to pareizu darbību.
DS: Ļoti foršs! Būtībā šī ir programmatūra, lai izveidotu savu pārvaldīto Postgres.
NS: U LinuxDistribūcijām ir mūžīga problēma: kā izveidot draiverus, lai atbalstītu visu aparatūru. Un viņi domā, ka tie darbosies Kubernetes vidē. Es zinu, ka nesen mēs redzējām Zalando paļaušanos uz AWS, un tas nav īpaši labi. Nevajadzētu būt paļaušanās uz konkrētu infrastruktūru — kāda tad jēga?
DS: Es precīzi nezinu, kādā situācijā Zalando nokļuva, bet Kubernetes krātuve tagad ir izveidota tā, ka nav iespējams veikt diska dublējumu, izmantojot vispārīgu metodi. Nesen standarta - jaunākajā versijā — mēs padarījām iespējamus momentuzņēmumus, bet kur tas tiek īstenots? Godīgi sakot, viss vēl ir tik neapstrādāts... Mēģinām CSI virsū AWS, GCE, Azure, vSphere, bet tiklīdz sāc lietot, var redzēt, ka tas vēl nav gatavs.
NS: Tāpēc mums dažreiz ir jāpaļaujas uz infrastruktūru. Es domāju, ka tas vēl ir sākuma posms - augšanas sāpes. Jautājums: Kādu padomu jūs sniegtu iesācējiem, kuri vēlas izmēģināt PgSQL K8s? Kāds operators varbūt?
DS: Problēma ir tāda, ka Postgres mums ir 3%. Mums ir arī ļoti liels dažādu programmatūru saraksts Kubernetes, es pat neuzskaitīšu visu. Piemēram, Elasticsearch. Operatoru ir daudz: daži aktīvi attīstās, citi ne. Esam sev izstrādājuši prasības, kam jābūt operatoram, lai mēs to uztvertu nopietni. Operatorā speciāli Kubernetes - nevis "operatorā, lai kaut ko darītu Amazones apstākļos"... Patiesībā mēs diezgan plaši (= gandrīz visi klienti) izmantojam vienu operatoru - (drīzumā publicēsim rakstu par viņu).
NS: Un arī ne MySQL? Es zinu, ka Percona... tā kā viņi tagad strādā pie MySQL, MongoDB un Postgres, viņiem būs jāizveido kaut kāds universāls risinājums: visām datu bāzēm, visiem mākoņa pakalpojumu sniedzējiem.
DS: Mums nebija laika apskatīt MySQL operatorus. Šobrīd tas nav mūsu galvenais uzsvars. MySQL darbojas labi atsevišķi. Kāpēc izmantot operatoru, ja var vienkārši palaist datu bāzi... Varat palaist Docker konteineru ar Postrges, vai arī varat to palaist vienkāršā veidā.
NS: Par šo arī bija jautājums. Nav operatora vispār?
DS: Jā, 100% no mums PostgreSQL darbojas bez operatora. Līdz šim tā. Mēs aktīvi izmantojam operatoru Prometheus un Redis. Esam plānojuši atrast Elasticsearch operatoru - tas ir visvairāk “uguns”, jo 100% gadījumu vēlamies to uzstādīt Kubernetes. Tāpat kā mēs vēlamies nodrošināt, ka MongoDB vienmēr tiek instalēts arī Kubernetes. Te parādās zināmas vēlmes – ir sajūta, ka šajos gadījumos kaut ko var izdarīt. Un mēs pat nepaskatījāmies uz Postgresu. Protams, mēs zinām, ka ir dažādas iespējas, bet patiesībā mums ir savrupa.
DB pārbaudei Kubernetes
NS: Pāriesim pie tēmas par testēšanu. Kā ieviest izmaiņas datu bāzē — no DevOps viedokļa. Ir mikropakalpojumi, daudzas datu bāzes, visu laiku kaut kas mainās. Kā nodrošināt normālu CI/CD, lai no DBVS viedokļa viss būtu kārtībā. Kāda ir jūsu pieeja?
DS: Viena atbilde nevar būt. Ir vairākas iespējas. Pirmais ir pamatnes izmērs, kuru vēlamies izrullēt. Jūs pats minējāt, ka uzņēmumiem ir atšķirīga attieksme pret prod datu bāzes kopiju izstrādē un stadijā.
NS: Un GDPR apstākļos, manuprāt, viņi ir arvien uzmanīgāki... Varu teikt, ka Eiropā jau ir sākuši uzlikt sodus.
DS: Bet bieži vien jūs varat rakstīt programmatūru, kas paņem izgāztuvi no ražošanas un aptumšo to. Prod dati tiek iegūti (momentuzņēmums, dump, binārā kopija...), taču tie ir anonimizēti. Tā vietā var būt ģenerēšanas skripti: tie var būt fiksatori vai vienkārši skripti, kas ģenerē lielu datu bāzi. Problēma ir: cik ilgs laiks nepieciešams, lai izveidotu pamata attēlu? Un cik ilgs laiks nepieciešams, lai to izvietotu vēlamajā vidē?
Mēs nonācām pie shēmas: ja klientam ir fiksēta datu kopa (minimālā datu bāzes versija), tad mēs tos izmantojam pēc noklusējuma. Ja mēs runājam par pārskatīšanas vidēm, izveidojot filiāli, mēs izvietojām lietojumprogrammas instanci - mēs tur izlaižam nelielu datu bāzi. Bet sanāca labi , kad mēs reizi dienā (naktī) paņemam izgāztuvi no ražošanas un izveidojam Docker konteineru ar PostgreSQL un MySQL, pamatojoties uz šiem ielādētajiem datiem. Ja jums ir nepieciešams paplašināt datu bāzi 50 reizes no šī attēla, 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ā. Tie. Mums ir gatavs attēls, lai gan 100 GB. Pateicoties Docker slāņiem, mēs varam ātri izvietot šo attēlu tik reižu, cik nepieciešams. Metode ir muļķīga, bet tā darbojas labi.
NS: Tad, pārbaudot, tas mainās tieši Docker iekšienē, vai ne? Kopēšana-uzrakstīšana iekšā Docker - izmet un ej vēlreiz, viss kārtībā. Klase! Un vai jūs to jau izmantojat pilnībā?
DS: Ilgu laiku.
NS: Mēs darām ļoti līdzīgas lietas. Tikai mēs neizmantojam Docker's copy-on-write, bet gan kādu citu.
DS: Tas nav vispārīgs. Un Docker darbojas visur.
NS: Teorētiski jā. Bet mums tur ir arī moduļi, jūs varat izgatavot dažādus moduļus un strādāt ar dažādām failu sistēmām. Kāds te brīdis. No Postgres puses mēs uz to visu skatāmies savādāk. Tagad es paskatījos no Docker puses un redzēju, ka viss darbojas jūsu labā. Bet, ja datu bāze ir milzīga, piemēram, 1 TB, tad tas viss aizņem ilgu laiku: operācijas naktī, un visu sabāzšana Docker... Un ja 5 TB iebāza Docker... Vai arī viss ir kārtībā?
DS: Kāda ir atšķirība: tie ir lāses, tikai biti un baiti.
NS: Atšķirība ir šāda: vai jūs to darāt, izmantojot izgāztuvi un atjaunošanu?
DS: Nemaz nav nepieciešams. Šī attēla ģenerēšanas metodes var būt dažādas.
NS: Dažiem klientiem esam izveidojuši tā, ka tā vietā, lai regulāri ģenerētu bāzes attēlu, mēs to pastāvīgi atjauninām. Tā būtībā ir kopija, taču tā saņem datus nevis tieši no galvenā, bet gan caur arhīvu. Binārais arhīvs, kurā katru dienu tiek lejupielādēti WAL, kur tiek veidotas dublējumkopijas... Pēc tam šie WAL ar nelielu kavēšanos (burtiski 1-2 sekundes) sasniedz bāzes attēlu. Mēs no tā klonējam jebkurā veidā - tagad mums pēc noklusējuma ir ZFS.
DS: Bet ar ZFS jūs aprobežojaties ar vienu mezglu.
NS: Jā. Bet ZFS ir arī maģisks : ar to jūs varat nosūtīt momentuzņēmumu un pat (es vēl neesmu īsti pārbaudījis, bet...) jūs varat nosūtīt delta starp diviem PGDATA. Patiesībā mums ir vēl viens rīks, ko mēs neesam īsti apsvēruši šādiem uzdevumiem. PostgreSQL ir , kas darbojas kā “viedais” rsync, izlaižot daudz no tā, kas nav jāskatās, jo tur nekas nav mainījies. Mēs varam veikt ātru sinhronizāciju starp diviem serveriem un attīt atpakaļ tādā pašā veidā.
Tātad, no šīs, vairāk DBA puses, mēs cenšamies izveidot rīku, kas ļauj mums darīt to pašu, ko jūs teicāt: mums ir viena datu bāze, bet mēs vēlamies kaut ko pārbaudīt 50 reizes, gandrīz vienlaikus.
DS: 50 reizes nozīmē, ka jums ir jāpasūta 50 Spot gadījumi.
NS: Nē, mēs visu darām ar vienu mašīnu.
DS: Bet kā jūs paplašināsiet 50 reizes, ja šī viena datubāze ir, teiksim, terabaits. Visticamāk, viņai vajag nosacītu 256 GB RAM?
NS: Jā, dažreiz jums ir nepieciešams daudz atmiņas - tas ir normāli. Bet tas ir piemērs no dzīves. Ražošanas iekārtai ir 96 kodoli un 600 GB. Tajā pašā laikā datubāzei tiek izmantoti 32 kodoli (pat 16 kodoli tagad dažreiz) un 100-120 GB atmiņa.
DS: Un 50 eksemplāri tur iederas?
NS: Tātad ir tikai viens eksemplārs, tad copy-on-write (ZFS) darbi... Pastāstīšu sīkāk.
Piemēram, mums ir 10 TB datu bāze. Uztaisīja tam disku, ZFS arī saspieda tā izmēru par 30-40 procentiem. Tā kā mēs neveicam slodzes testēšanu, precīzs reakcijas laiks mums nav svarīgs: ļaujiet tam būt līdz 2 reizēm lēnāk - tas ir labi.
Mēs dodam iespēju programmētājiem, QA, DBA u.c. veikt testēšanu 1-2 pavedienos. Piemēram, viņi var veikt sava veida migrāciju. Tam nav nepieciešami 10 kodoli vienlaikus - tam ir nepieciešams 1 Postgres aizmugursistēma, 1 kodols. Sāksies migrācija – varbūt joprojām sāksies, tad tiks izmantots otrais kodols. Mums ir atvēlēti 16-32 kodoli, tātad 10 cilvēki var strādāt vienlaicīgi, bez problēmām.
Jo fiziski PGDATA tas pats, izrādās, ka mēs patiesībā maldinām Postgresu. Viltība ir šāda: piemēram, vienlaikus tiek palaistas 10 Postgres. Kāda parasti ir problēma? Viņi liek , pieņemsim, ka 25%. Attiecīgi tas ir 200 GB. Jūs nevarēsit palaist vairāk kā trīs no tiem, jo beigsies atmiņa.
Bet kādā brīdī mēs sapratām, ka tas nav nepieciešams: mēs iestatījām share_buffers uz 2 GB. PostgreSQL ir , un patiesībā tas ir vienīgais, kas ietekmē . Mēs iestatījām to uz 0,5 TB. Un tas pat nav svarīgi, ka tie patiesībā neeksistē: viņš plāno plānus tā, it kā tie pastāvētu.
Attiecīgi, kad mēs pārbaudām kaut kādu migrāciju, mēs varam savākt visus plānus - mēs redzēsim, kā tas notiks ražošanā. Sekundes tur būs dažādas (lēnākas), bet dati, kurus mēs faktiski nolasām, un paši plāni (kādi tur ir JOIN utt.) izrādās tieši tādi paši kā ražošanā. Un jūs varat veikt daudzas šādas pārbaudes paralēli vienā mašīnā.
DS: Vai jums nešķiet, ka šeit ir dažas problēmas? Pirmais ir risinājums, kas darbojas tikai uz PostgreSQL. Šī pieeja ir ļoti privāta, tā nav vispārīga. Otrais ir tas, ka Kubernetes (un viss, ko tagad izmanto mākoņtehnoloģijas) ietver daudzus mezglus, un šie mezgli ir īslaicīgi. Un jūsu gadījumā tas ir stāvošs, pastāvīgs mezgls. Šīs lietas man rada pretrunas.
NS: Pirmkārt, es piekrītu, šis ir tikai Postgres stāsts. Es domāju, ka, ja mums ir kaut kāds tiešais IO un bufera baseins gandrīz visai atmiņai, šī pieeja nedarbosies - plāni būs atšķirīgi. Bet pagaidām strādājam tikai ar Postgres, par citiem nedomājam.
Par Kubernetes. Jūs pats mums visur sakāt, ka mums ir pastāvīga datubāze. Ja gadījums neizdodas, galvenais ir saglabāt disku. Šeit mums ir arī visa platforma Kubernetes, un komponents ar Postgres ir atsevišķs (lai gan kādu dienu tas tur būs). Tāpēc viss ir tā: instance nokrita, bet mēs saglabājām tās PV un vienkārši pieslēdzām citai (jaunai) instancei, it kā nekas nebūtu noticis.
DS: No mana viedokļa, mēs veidojam pākstis Kubernetes. K8s - elastīgs: mezgli tiek pasūtīti pēc nepieciešamības. Uzdevums ir vienkārši izveidot podziņu un pateikt, ka tam vajag X resursu daudzumu, un tad K8s to izdomās pats. Bet Kubernetes krātuves atbalsts joprojām ir nestabils: Uz (šis izdevums tika izlaists Nedēļas pirms) šīs funkcijas kļūst tikai par beta versiju.
Paies seši mēneši līdz gads - tas kļūs vairāk vai mazāk stabils vai vismaz par tādu tiks deklarēts. Tad momentuzņēmumu un izmēru maiņas iespēja pilnībā atrisina jūsu problēmu. Jo jums ir bāze. Jā, tas var nebūt ļoti ātrs, bet ātrums ir atkarīgs no tā, kas atrodas “zem pārsega”, jo dažas implementācijas var kopēt un kopēt uz rakstīšanas diska apakšsistēmas līmenī.
NS: Ir arī nepieciešams, lai visi dzinēji (Amazon, Google...) sāktu atbalstīt šo versiju - tas arī aizņem kādu laiku.
DS: Mēs tos vēl neizmantojam. Mēs izmantojam savējo.
Vietējā attīstība Kubernetes
NS: Vai esat kādreiz saskārušies ar šādu vēlmi, kad jums ir jāuzstāda visi podi vienā mašīnā un jāveic tik mazs tests. Lai ātri iegūtu koncepcijas pierādījumu, pārbaudiet, vai lietojumprogramma darbojas Kubernetes, nevelkot tai virkni mašīnu. Tur ir Minikube, vai ne?
DS: Man šķiet, ka šī lieta, kas izvietota vienā mezglā, ir saistīta tikai ar vietējo attīstību. Vai dažas šāda modeļa izpausmes. Ēst , Tur ir , . Mēs virzāmies uz Kubernetes IN Docker izmantošanu. Tagad mēs sākām strādāt ar to testu veikšanai.
NS: Agrāk domāju, ka tas ir mēģinājums ietīt visus pākstis vienā Docker attēlā. Taču izrādījās, ka runa ir par pavisam ko citu. Jebkurā gadījumā ir atsevišķi konteineri, atsevišķi podi - tikai Docker.
DS: Jā. Un ir izveidota diezgan smieklīga imitācija, bet nozīme ir tāda... Mums ir utilīta izvietošanai - . Mēs vēlamies to padarīt par nosacītu režīmu werf up: "Atnesiet man vietējo Kubernetes." Un tad tur palaist nosacīto werf follow. Pēc tam izstrādātājs varēs rediģēt IDE, un sistēmā tiks palaists process, kas redz izmaiņas un pārbūvē attēlus, pārizvietojot tos uz vietējiem K8. Tā mēs vēlamies mēģināt atrisināt vietējās attīstības problēmu.
Momentuzņēmumi un datu bāzes klonēšana K8s realitātē
NS: Ja mēs atgriežamies pie kopēšanas-rakstīšanas. Pamanīju, ka mākoņiem ir arī momentuzņēmumi. Viņi strādā savādāk. Piemēram, GSP: jums ir vairāku terabaitu instance Amerikas Savienoto Valstu austrumu krastā. Jūs periodiski uzņemat momentuzņēmumus. Jūs paņemat diska kopiju rietumu krastā no momentuzņēmuma - pēc dažām minūtēm viss ir gatavs, tas darbojas ļoti ātri, tikai kešatmiņa ir jāaizpilda atmiņā. Bet šie kloni (momentuzņēmumi) ir paredzēti jauna apjoma nodrošināšanai. Tas ir lieliski, ja jums ir jāizveido daudz gadījumu.
Bet testiem man liekas, ka momentuzņēmumi, par kuriem tu runā Docker vai es runāju par ZFS, btrfs un pat LVM... - tie ļauj neveidot īsti jaunus datus uz vienas mašīnas. Mākonī jūs joprojām maksāsit par tiem katru reizi un gaidīsit nevis sekundes, bet minūtes (un gadījumā , iespējams, pulkstenis).
Tā vietā varat iegūt šos datus sekundē vai divās, palaist pārbaudi un izmest tos. Šie momentuzņēmumi atrisina dažādas problēmas. Pirmajā gadījumā - lai palielinātu mērogu un iegūtu jaunas kopijas, bet otrajā - testiem.
DS: Es nepiekrītu. Pareiza apjoma klonēšana ir mākoņa uzdevums. Es neesmu apskatījis to ieviešanu, bet es zinu, kā mēs to darām ar aparatūru. Mums ir Ceph, tas pieļauj jebkuru fizisko apjomu () teikt klons un iegūstiet otru tilpumu ar tādām pašām īpašībām desmitos milisekundēs, ‘ami utt. Jums jāsaprot, ka iekšā ir viltīga kopēšana uz rakstīšanas. Kāpēc lai mākonis nedarītu to pašu? Esmu pārliecināts, ka viņi tā vai citādi cenšas to darīt.
NS: Bet viņiem joprojām būs vajadzīgas sekundes, desmitiem sekunžu, lai paceltu instanci, nogādātu Dockeru utt.
DS: Kāpēc ir nepieciešams izvirzīt visu instanci? Mums ir eksemplārs ar 32 kodoliem, 16... un tajā var ietilpt - piemēram, četri. Kad pasūtīsim piekto, instance jau tiks pacelta, un tad tā tiks dzēsta.
NS: Jā, interesanti, Kubernetes izrādās cits stāsts. Mūsu datubāze nav K8s, un mums ir viens gadījums. Bet vairāku terabaitu datu bāzes klonēšana aizņem ne vairāk kā divas sekundes.
DS: Tas ir lieliski. Bet mans sākotnējais viedoklis ir tāds, ka tas nav vispārējs risinājums. Jā, tas ir forši, taču tas ir piemērots tikai Postgres un tikai vienā mezglā.
NS: Tas ir piemērots ne tikai Postgres: šie plāni, kā es aprakstīju, darbosies tikai tajā. Bet, ja mēs neuztraucamies par plāniem un mums ir nepieciešami tikai visi dati funkcionālajai pārbaudei, tad tas ir piemērots jebkurai DBVS.
DS: Pirms daudziem gadiem mēs kaut ko līdzīgu darījām LVM momentuzņēmumos. Šī ir klasika. Šī pieeja tika ļoti aktīvi izmantota. Nozīmīgi mezgli ir tikai sāpes. Tā kā tos nedrīkst nomest, tie vienmēr jāatceras...
NS: Vai jūs šeit redzat kādu hibrīda iespēju? Pieņemsim, ka statusful ir sava veida pods, tas darbojas vairākiem cilvēkiem (daudziem testētājiem). Mums ir viens sējums, bet, pateicoties failu sistēmai, kloni ir lokāli. Ja pods nokrīt, bet disks paliek, pods pacelsies, saskaitīs informāciju par visiem kloniem, paņems visu vēlreiz un saka: "Šeit ir jūsu kloni, kas darbojas šajos portos, turpiniet strādāt ar tiem."
DS: Tehniski tas nozīmē, ka Kubernetes tas ir viens pods, kurā mēs darbinām daudzus Postgres.
NS: Jā. Viņam ir ierobežojums: pieņemsim, ka ar viņu vienlaikus strādā ne vairāk kā 10 cilvēki. Ja jums ir nepieciešami 20, mēs izlaidīsim otru šādu podziņu. Mēs to pilnībā klonēsim, saņemot otro pilno sējumu, tam būs tie paši 10 “plānie” kloni. Vai jūs neredzat šo iespēju?
DS: šeit ir jāpievieno drošības jautājumi. Šāda veida organizācija nozīmē, ka šim podam ir augstas privilēģijas (iespējas), jo tas var veikt nestandarta darbības failu sistēmā... Bet es atkārtoju: es uzskatu, ka vidējā termiņā viņi sakārtos krātuvi Kubernetes, un mākoņus viņi visu stāstu salabos ar apjomiem - viss "vienkārši darbosies". Būs izmēru maiņa, klonēšana... Ir sējums - sakām: “Izveidojiet jaunu, pamatojoties uz to,” un pēc pusotras sekundes mēs iegūstam vajadzīgo.
NS: Es neticu pusotrai sekundei daudziem terabaitiem. Uz Ceph jūs to darāt pats, bet jūs runājat par mākoņiem. Dodieties uz mākoni, izveidojiet vairāku terabaitu EBS sējuma klonu uz EC2 un skatieties, kāds būs sniegums. Tas neaizņems dažas sekundes. Mani ļoti interesē, kad viņi sasniegs šo līmeni. Es saprotu, ko jūs sakāt, bet es lūdzu atšķirties.
DS: Labi, bet es teicu vidējā termiņā, nevis īstermiņā. Jau vairākus gadus.
Par PostgreSQL operatoru no Zalando
Šīs sanāksmes vidū arī Aleksejs Kļukins, bijušais Zalando izstrādātājs, pievienojās un runāja par PostgreSQL operatora vēsturi:
Lieliski, ka šī tēma tiek skarta kopumā: gan Postgres, gan Kubernetes. Kad 2017. gadā sākām to darīt Zalando, tā bija tēma, ko visi gribēja darīt, bet neviens nedarīja. Visiem jau bija Kubernetes, bet kad jautāja, ko darīt ar datu bāzēm, pat cilvēkiem patīk , kurš sludināja K8s, teica apmēram šādi:
“Dodieties uz pārvaldītajiem pakalpojumiem un izmantojiet tos, nepalaidiet datu bāzi Kubernetes. Pretējā gadījumā jūsu K8s nolems, piemēram, veikt jaunināšanu, izslēgt visus mezglus, un jūsu dati lidos tālu, tālu.
Mēs nolēmām izveidot operatoru, kas pretēji šim ieteikumam palaidīs Postgres datubāzi Kubernetes. Un mums bija labs iemesls - . Šī ir automātiska PostgreSQL kļūmjpārlēce, kas veikta pareizi, t.i. izmantojot etcd, consul vai ZooKeeper kā informācijas krātuvi par kopu. Tāda krātuve, kas katram, kas jautās, piemēram, kāds ir pašreizējais vadītājs, dos vienu un to pašu informāciju - neskatoties uz to, ka mums viss ir sadalīts - lai nav sašķeltu smadzenes. Turklāt mums bija viņam.
Kopumā uzņēmuma vajadzība pēc automātiskās kļūmjpārlēces parādījās pēc migrēšanas no iekšējā aparatūras datu centra uz mākoni. Mākoņa pamatā bija patentēts PaaS (Platform-as-a-Service) risinājums. Tas ir atvērts avots, taču bija nepieciešams daudz darba, lai to izveidotu un palaistu. Tas saucās .
Sākotnēji Kubernetes nebija. Precīzāk, kad tika ieviests mūsu pašu risinājums, K8 jau pastāvēja, taču tas bija tik neapstrādāts, ka nebija piemērots ražošanai. Tas, manuprāt, bija 2015. vai 2016. gads. Līdz 2017. gadam Kubernetes bija vairāk vai mazāk nobriedušas — tur bija jāmigrē.
Un mums jau bija Docker konteiners. Bija PaaS, kas izmantoja Docker. Kāpēc gan neizmēģināt K8s? Kāpēc gan neuzrakstīt savu operatoru? Murats Kabilovs, kurš ieradās pie mums no Avito, sāka to kā projektu pēc savas iniciatīvas - "spēlēt" - un projekts "pacēlās".
Bet kopumā es gribēju runāt par AWS. Kāpēc bija vēsturisks ar AWS saistīts kods...
Palaižot kaut ko Kubernetes, jāsaprot, ka K8s ir tāds nepabeigts darbs. Tas pastāvīgi attīstās, uzlabojas un ik pa laikam pat sabojājas. Jums rūpīgi jāseko līdzi visām Kubernetes izmaiņām, jābūt gatavam tajā ienirt, ja kaut kas notiek, un detalizēti uzzināt, kā tas darbojas - varbūt vairāk, nekā jūs vēlētos. Tas principā attiecas uz jebkuru platformu, kurā izmantojat savas datu bāzes...
Tātad, kad mēs sagatavojām paziņojumu, Postgres darbojās ārējā sējumā (šajā gadījumā EBS, jo mēs strādājām pie AWS). Datubāze pieauga, kaut kad bija nepieciešams to mainīt: piemēram, EBS sākotnējais izmērs bija 100 TB, datu bāze izauga līdz tai, tagad gribam uztaisīt EBS 200 TB. Kā? Pieņemsim, ka varat veikt izgāzšanu/atjaunošanu jaunā instancē, taču tas prasīs ilgu laiku un dīkstāvi.
Tāpēc es gribēju mainīt izmēru, kas palielinātu EBS nodalījumu un pēc tam liktu failu sistēmai izmantot jauno vietu. Un mēs to izdarījām, bet tajā laikā Kubernetes nebija API izmēra maiņas darbībai. Tā kā mēs strādājām pie AWS, mēs rakstījām kodu tā API.
Neviens neliedz jums darīt to pašu attiecībā uz citām platformām. Paziņojumā nav mājienu, ka to var palaist tikai AWS, un tas nedarbosies ar visu pārējo. Kopumā šis ir atvērtā koda projekts: ja kāds vēlas paātrināt jaunā API lietošanas rašanos, laipni lūdzam. Ēst , pull pieprasījumus - Zalando komanda cenšas diezgan ātri atbildēt uz tiem un reklamēt operatoru. Cik man zināms, projekts Google Summer of Code un dažās citās līdzīgās iniciatīvās. Zalando ļoti aktīvi strādā pie tā.
P.S. Bonuss!
Ja jūs interesē PostgreSQL un Kubernetes tēma, lūdzu, ņemiet vērā, ka nākamā Postgres otrdiena notika pagājušajā nedēļā, kurā es runāju ar Nikolaju Aleksandrs Kukuškins no Zalando. Ir pieejams video no tā .
PPS
Lasi arī mūsu emuārā:
- «";
- «";
- «";
- «'.
Avots: www.habr.com
