Fine de la pasinta jaro okazis alia rekta elsendo de la rusa PostgreSQL-komunumo , dum kiu ĝia kunfondinto Nikolaj Samokhvalov parolis kun Flant-teknika direktoro Dmitry Stolyarov pri ĉi tiu DBMS en la kunteksto de Kubernetes.
Ni publikigas transskribon de la ĉefa parto de ĉi tiu diskuto, kaj ĉe Plena video afiŝita:
Datumbazoj kaj Kubernetes
НС: Ni ne parolos pri VAKUO kaj ĈEKPOINTOJ hodiaŭ. Ni volas paroli pri Kubernetes. Mi scias, ke vi havas multajn jarojn da sperto. Mi spektis viajn videojn kaj eĉ respektis kelkajn el ili... Ni iru rekte al la afero: kial Postgres aŭ MySQL en K8s entute?
DS: Ne estas kaj ne povas esti definitiva respondo al ĉi tiu demando. Sed ĝenerale, ĉi tio estas simpleco kaj oportuno... potencialo. Ĉiuj volas administritajn servojn.
НС: Al kiel , nur hejme?
DS: Jes: kiel RDS, ie ajn.
НС: "Ie ajn" estas bona punkto. En grandaj kompanioj ĉio situas en malsamaj lokoj. Kial do, se ĝi estas granda kompanio, ne preni pretan solvon? Ekzemple, Nutanix havas siajn proprajn evoluojn, aliaj kompanioj (VMware...) havas la saman "RDS, nur hejme."
DS: Sed ni parolas pri aparta efektivigo, kiu funkcios nur sub certaj kondiĉoj. Kaj se ni parolas pri Kubernetes, tiam ekzistas grandega vario de infrastrukturo (kiu povas esti en K8s). Esence ĉi tio estas normo por API-oj al la nubo...
НС: Ĝi ankaŭ estas senpaga!
DS: Ĝi ne estas tiel grava. Libereco estas grava por ne tre granda segmento de la merkato. Io alia estas grava... Vi verŝajne memoras la raporton “"?"
НС: Jes.
DS: Mi konstatis, ke ĝi estas ricevita tre ambigue. Iuj homoj pensis, ke mi diras: "Knaboj, ni enigu ĉiujn datumbazojn en Kubernetes!", Dum aliaj decidis, ke ĉi tiuj ĉiuj estas teruraj bicikloj. Sed mi volis diri ion tute alian: “Rigardu, kio okazas, kiaj problemoj estas kaj kiel ili povas esti solvitaj. Ĉu ni nun uzu datumbazojn de Kubernetes? Produktado? Nu, nur se vi ŝatas...fari certajn aferojn. Sed por dev, mi povas diri, ke mi rekomendas ĝin. Por dev, la dinamismo krei/forigi mediojn estas tre grava."
NS: Per dev, ĉu vi celas ĉiujn mediojn, kiuj ne estas prod? Enscenigo, QA...
DS: Se ni parolas pri perf-standoj, do verŝajne ne, ĉar la postuloj tie estas specifaj. Se ni parolas pri specialaj kazoj, kie necesas tre granda datumbazo por surscenigo, tiam verŝajne ne... Se ĉi tio estas senmova, longviva medio, kia do profitas havi la datumbazon lokita en K8s?
НС: Neniu. Sed kie ni vidas senmovajn mediojn? Senmoka medio malnoviĝos morgaŭ.
DS: Enscenigo povas esti senmova. Ni havas klientojn...
НС: Jes, ankaŭ mi havas unu. Estas granda problemo se vi havas 10 TB-datumbazon kaj 200 GB-scenigon...
DS: Mi havas tre bonegan kazon! Sur enscenigo ekzistas produkta datumbazo al kiu ŝanĝoj estas faritaj. Kaj estas butono: "eliru al produktado". Ĉi tiuj ŝanĝoj - deltoj - estas aldonitaj (ŝajnas, ke ili estas simple sinkronigitaj per la API) en produktado. Ĉi tio estas tre ekzotika opcio.
НС: Mi vidis noventreprenojn en la Valo kiuj sidas en RDS aŭ eĉ en Heroku - jen rakontoj de antaŭ 2-3 jaroj - kaj ili elŝutas la rubejon al sia tekkomputilo. Ĉar la datumbazo estas ankoraŭ nur 80 GB, kaj estas spaco sur la tekkomputilo. Poste ili aĉetas pliajn diskojn por ĉiuj, por ke ili havu 3 datumbazojn por fari malsamajn evoluojn. Tiel okazas ankaŭ. Mi ankaŭ vidis, ke ili ne timas kopii prod en surscenigon - ĝi tre dependas de la kompanio. Sed mi ankaŭ vidis, ke ili tre timas, kaj ke ili ofte ne havas sufiĉe da tempo kaj manoj. Sed antaŭ ol ni transiru al ĉi tiu temo, mi volas aŭdi pri Kubernetes. Ĉu mi ĝuste komprenas, ke neniu ankoraŭ estas en prod?
DS: Ni havas malgrandajn datumbazojn en prod. Ni parolas pri volumoj de dekoj da gigabajtoj kaj ne-kritikaj servoj, por kiuj ni estis tro mallaboremaj por fari kopiojn (kaj ne ekzistas tia bezono). Kaj kondiĉe ke ekzistas normala stokado sub Kubernetes. Ĉi tiu datumbazo funkciis en virtuala maŝino - kondiĉe en VMware, aldone al la stokadsistemo. Ni metis ĝin enen kaj nun ni povas translokigi ĝin de maŝino al maŝino.
НС: Datenbazoj de ĉi tiu grandeco, ĝis 100 GB, povas esti lanĉitaj en kelkaj minutoj sur bonaj diskoj kaj bona reto, ĉu ne? Rapido de 1 GB sekundo ne plu estas ekzotika.
DS: Jes, por lineara operacio tio ne estas problemo.
НС: Bone, ni nur devas pensi pri prod. Kaj se ni konsideras Kubernetes por ne-produktaj medioj, kion ni faru? Mi vidas tion en Zalando , en Crunchy , estas iuj aliaj ebloj. Kaj ekzistas — jen nia bona amiko Alvaro el Hispanio: kion ili faras esence ne estas justa , kaj la tuta distribuo (), en kiun, krom Postgres mem, ili ankaŭ decidis ŝtopi sekurkopion, la Envoy-prokurilon...
DS: Sendito por kio? Ĉu ekvilibrigi Postgres-trafikon specife?
НС: Jes. Tio estas, ili vidas ĝin kiel: se vi prenas Linuksan distribuon kaj kernon, tiam regula PostgreSQL estas la kerno, kaj ili volas fari distribuon kiu estos nubo-amika kaj ruliĝos sur Kubernetes. Ili kunmetas komponantojn (sekurkopioj, ktp.) kaj sencimigas ilin por ke ili bone funkciu.
DS: Tre mojosa! Esence ĉi tio estas programaro por krei vian propran administritan Postgres.
НС: Linuksaj distribuoj havas eternajn problemojn: kiel fari ŝoforojn por ke ĉiu aparataro estu subtenata. Kaj ili havas la ideon, ke ili laboros en Kubernetes. Mi scias, ke en la telefonisto Zalando ni lastatempe vidis konekton al AWS kaj ĉi tio ne plu estas tre bona. Ne devus esti ligo al specifa infrastrukturo - kio do estas la signifo?
DS: Mi ne scias precize en kian situacion eniris Zalando, sed en Kubernetes konservado nun estas farita tiel, ke estas neeble preni diskrezervon per ĝenerala metodo. Lastatempe en norma - en lasta versio — ni ebligis momentfotojn, sed kie ĝi estas efektivigita? Sincere, ĉio ankoraŭ estas tiel kruda... Ni provas CSI aldone al AWS, GCE, Azure, vSphere, sed tuj kiam vi komencas uzi ĝin, vi povas vidi, ke ĝi ankoraŭ ne estas preta.
НС: Tial ni foje devas fidi al infrastrukturo. Mi pensas, ke ĉi tio estas ankoraŭ frua etapo - kreskantaj doloroj. Demando: Kian konsilon vi donus al novuloj, kiuj volas provi PgSQL en K8s? Kiu operatoro eble?
DS: La problemo estas, ke Postgres estas 3% por ni. Ni ankaŭ havas tre grandan liston de malsamaj programoj en Kubernetes, mi eĉ ne listigos ĉion. Ekzemple, Elasticsearch. Estas multaj operatoroj: iuj aktive disvolviĝas, aliaj ne. Ni ellaboris postulojn por ni mem pri tio, kion operatoro devus havi por ke ni konsideru ĝin serioze. En funkciigisto specife por Kubernetes - ne en "funkciigisto por fari ion en la kondiĉoj de Amazon"... Fakte, ni sufiĉe vaste (= preskaŭ ĉiuj klientoj) uzas ununuran funkciigiston - (ni baldaŭ publikigos artikolon pri li).
НС: Kaj ankaŭ ne por MySQL? Mi scias, ke Percona... ĉar ili nun laboras pri MySQL, MongoDB kaj Postgres, ili devos krei ian universalan solvon: por ĉiuj datumbazoj, por ĉiuj nubaj provizantoj.
DS: Ni ne havis tempon por rigardi la funkciigistojn por MySQL. Ĉi tio ne estas nia ĉefa fokuso nun. MySQL funkcias bone en memstara. Kial uzi operatoron se vi povas simple lanĉi datumbazon... Vi povas lanĉi Docker-ujon kun Postrges, aŭ vi povas lanĉi ĝin per simpla maniero.
НС: Estis demando ankaŭ pri ĉi tio. Tute neniu telefonisto?
DS: Jes, 100% el ni havas PostgreSQL funkcianta sen funkciigisto. Ĝis nun tiel. Ni aktive uzas la funkciigiston por Prometheus kaj Redis. Ni planas trovi funkciigiston por Elasticsearch - ĝi estas tiu, kiu plej "fajras", ĉar ni volas instali ĝin en Kubernetes en 100% de kazoj. Same kiel ni volas certigi, ke MongoDB ankaŭ ĉiam estas instalita en Kubernetes. Ĉi tie aperas certaj deziroj - estas sento, ke en ĉi tiuj kazoj io povas esti farita. Kaj ni eĉ ne rigardis Postgres. Kompreneble, ni scias, ke ekzistas malsamaj ebloj, sed fakte ni havas memstaran.
DB por testado en Kubernetes
НС: Ni transiru al la temo pri testado. Kiel efektivigi ŝanĝojn al la datumbazo - de DevOps-perspektivo. Estas mikroservoj, multaj datumbazoj, io ŝanĝiĝas ie la tutan tempon. Kiel certigi normalan CI/KD por ke ĉio estu en ordo de la DBMS-perspektivo. Kio estas via aliro?
DS: Ne povas esti unu respondo. Estas pluraj ebloj. La unua estas la grandeco de la bazo, kiun ni volas ruliĝi. Vi mem menciis, ke kompanioj havas malsamajn sintenojn pri havi kopion de la prod-datumbazo sur dev kaj scenejo.
НС: Kaj laŭ la kondiĉoj de la GDPR, mi pensas, ke ili estas pli kaj pli singardaj... Mi povas diri, ke en Eŭropo oni jam komencis trudi monpunojn.
DS: Sed ofte oni povas verki programaron kiu prenas rubejon de produktado kaj malklarigas ĝin. Prod-datumoj estas akiritaj (momentfoto, dump, duuma kopio...), sed ĝi estas anonimigita. Anstataŭe, povas ekzisti generaciaj skriptoj: ĉi tiuj povas esti fiksaĵoj aŭ nur skripto, kiu generas grandan datumbazon. La problemo estas: kiom da tempo necesas por krei bazan bildon? Kaj kiom da tempo necesas por deploji ĝin en la deziratan medion?
Ni venis al skemo: se la kliento havas fiksan datuman aron (minimuma versio de la datumbazo), tiam ni uzas ilin defaŭlte. Se ni parolas pri reviziaj medioj, kiam ni kreis branĉon, ni disfaldis ekzemplon de la aplikaĵo - ni disvolvas malgrandan datumbazon tie. Sed ĝi rezultis bone , kiam ni prenas rubejon de produktado unufoje tage (nokte) kaj konstruas Docker-ujon kun PostgreSQL kaj MySQL kun ĉi tiu ŝarĝita datumo bazita sur ĝi. Se vi bezonas vastigi la datumbazon 50 fojojn de ĉi tiu bildo, tio estas farita simple kaj rapide.
НС: Per simpla kopiado?
DS: Datumoj estas konservitaj rekte en la bildo de Docker. Tiuj. Ni havas pretan bildon, kvankam 100 GB. Danke al tavoloj en Docker, ni povas rapide disfaldi ĉi tiun bildon tiom da fojoj kiom ni bezonas. La metodo estas stulta, sed ĝi funkcias bone.
НС: Tiam, kiam vi testas, ĝi ŝanĝiĝas ĝuste ene de Docker, ĉu ne? Kopiu-sur-skribi ene de Docker - forĵetu ĝin kaj reiru, ĉio estas en ordo. Klaso! Kaj ĉu vi jam uzas ĝin plene?
DS: Longtempe.
НС: Ni faras tre similajn aferojn. Nur ni ne uzas kopion-sur-skribi de Docker, sed iun alian.
DS: Ĝi ne estas ĝenerala. Kaj Docker funkcias ĉie.
НС: En teorio, jes. Sed ni ankaŭ havas modulojn tie, vi povas fari malsamajn modulojn kaj labori kun malsamaj dosiersistemoj. Kia momento ĉi tie. De la flanko de Postgres, ni rigardas ĉion ĉi malsame. Nun mi rigardis de la Docker-flanko kaj vidis, ke ĉio funkcias por vi. Sed se la datumbazo estas grandega, ekzemple, 1 TB, tiam ĉio ĉi prenas longan tempon: operacioj nokte, kaj enŝtopi ĉion en Docker... Kaj se 5 TB estas ŝtopitaj en Docker... Aŭ ĉu ĉio estas en ordo?
DS: Kio estas la diferenco: ĉi tiuj estas blobs, nur bitoj kaj bajtoj.
НС: La diferenco estas jena: ĉu vi faras ĝin per dump kaj restarigo?
DS: Tute ne necesas. La metodoj por generi ĉi tiun bildon povas esti malsamaj.
НС: Por iuj klientoj, ni faris ĝin tiel, ke anstataŭ regule generi bazan bildon, ni konstante konservas ĝin ĝisdatigita. Ĝi estas esence kopio, sed ĝi ricevas datumojn ne rekte de la majstro, sed per arkivo. Duuma arkivo kie WAL-oj estas elŝutitaj ĉiutage, kie sekurkopioj estas prenitaj... Tiuj WAL-oj tiam atingas la bazan bildon kun eta prokrasto (laŭvorte 1-2 sekundoj). Ni klonas el ĝi iel - nun ni havas ZFS defaŭlte.
DS: Sed kun ZFS vi estas limigita al unu nodo.
НС: Jes. Sed ZFS ankaŭ havas magian : per ĝi oni povas sendi momentfoton kaj eĉ (mi ankoraŭ ne vere testis tion, sed...) oni povas sendi delton inter du PGDATA. Fakte, ni havas alian ilon, kiun ni ne vere konsideris por tiaj taskoj. PostgreSQL havas , kiu funkcias kiel "inteligenta" rsync, pretersaltas multon de tio, kion vi ne devas spekti, ĉar nenio ŝanĝiĝis tie. Ni povas fari rapidan sinkronigon inter la du serviloj kaj rebobeni de la sama maniero.
Do, de ĉi tio, pli DBA-flanko, ni provas krei ilon, kiu ebligas al ni fari la samon, kiun vi diris: ni havas unu datumbazon, sed ni volas provi ion 50 fojojn, preskaŭ samtempe.
DS: 50 fojojn signifas, ke vi devas mendi 50 Spot-instancojn.
НС: Ne, ni faras ĉion per unu maŝino.
DS: Sed kiel vi vastiĝos 50 fojojn se ĉi tiu datumbazo estas, ekzemple, terabajto. Plej verŝajne ŝi bezonas kondiĉajn 256 GB da RAM?
НС: Jes, foje oni bezonas multe da memoro - tio estas normala. Sed ĉi tio estas ekzemplo de vivo. La produktmaŝino havas 96 kernojn kaj 600 GB. Samtempe, 32 kernoj (eĉ 16 kernoj nun foje) kaj 100-120 GB da memoro estas uzataj por la datumbazo.
DS: Kaj 50 ekzempleroj konvenas tie?
НС: Do estas nur unu kopio, tiam kopio-sur-skribi (ZFS) funkcias... Mi rakontos al vi pli detale.
Ekzemple, ni havas 10 TB datumbazon. Ili faris diskon por ĝi, ZFS ankaŭ kunpremis ĝian grandecon je 30-40 procentoj. Ĉar ni ne faras ŝarĝtestadon, la ĝusta responda tempo ne gravas por ni: ĝi estu ĝis 2 fojojn pli malrapida - tio estas en ordo.
Ni donas la ŝancon al programistoj, QA, DBA, ktp. fari testadon en 1-2 fadenoj. Ekzemple, ili povus fari ian migradon. Ĝi ne postulas 10 kernojn samtempe - ĝi bezonas 1 Postgres-backend, 1 kerno. Migrado komenciĝos – eble ankoraŭ komenciĝos, tiam la dua kerno estos uzata. Ni havas 16-32 kernojn asignitaj, do 10 homoj povas labori samtempe, neniu problemo.
Ĉar fizike PGDATA same, rezultas, ke ni efektive trompas Postgres. La lertaĵo estas jena: ekzemple, 10 Postgres estas lanĉitaj samtempe. Kio estas la problemo kutime? Ili metis , ni diru 25%. Sekve, ĉi tio estas 200 GB. Vi ne povos lanĉi pli ol tri el ĉi tiuj, ĉar la memoro elĉerpiĝos.
Sed iam ni rimarkis, ke tio ne estas necesa: ni starigis shared_buffers al 2 GB. PostgreSQL havas , kaj fakte ĝi estas la sola kiu influas . Ni starigis ĝin al 0,5 TB. Kaj eĉ ne gravas, ke ili fakte ne ekzistas: li faras planojn kvazaŭ ili ekzistus.
Sekve, kiam ni testas ian migradon, ni povas kolekti ĉiujn planojn - ni vidos kiel ĝi okazos en produktado. La sekundoj tie estos malsamaj (pli malrapidaj), sed la datumoj, kiujn ni efektive legas, kaj la planoj mem (kiaj JOIN-oj estas tie, ktp.) rezultas ĝuste same kiel en produktado. Kaj vi povas fari multajn tiajn kontrolojn paralele sur unu maŝino.
DS: Ĉu vi ne pensas, ke estas kelkaj problemoj ĉi tie? La unua estas solvo, kiu funkcias nur sur PostgreSQL. Ĉi tiu aliro estas tre privata, ĝi ne estas ĝenerala. La dua estas, ke Kubernetes (kaj ĉio, kion nun nubaj teknologioj iras) implikas multajn nodojn, kaj ĉi tiuj nodoj estas efemeraj. Kaj en via kazo ĝi estas ŝtata, persista nodo. Ĉi tiuj aferoj konfliktas min.
НС: Unue, mi konsentas, ĉi tio estas pure Postgres-rakonto. Mi pensas, se ni havas ian rektan IO kaj bufran naĝejon por preskaŭ la tuta memoro, ĉi tiu aliro ne funkcios - la planoj estos malsamaj. Sed nuntempe ni laboras nur kun Postgres, ni ne pensas pri aliaj.
Pri Kubernetes. Vi mem diras al ni ĉie, ke ni havas konstantan datumbazon. Se la kazo malsukcesas, la ĉefa afero estas konservi la diskon. Ĉi tie ni ankaŭ havas la tutan platformon en Kubernetes, kaj la komponanto kun Postgres estas aparta (kvankam ĝi estos tie iam). Tial ĉio estas tiel: la instanco falis, sed ni konservis ĝian PV kaj simple konektis ĝin al alia (nova) instanco, kvazaŭ nenio estus okazinta.
DS: El mia vidpunkto, ni kreas podojn en Kubernetes. K8s - elasta: nodoj estas menditaj laŭbezone. La tasko estas simple krei pod kaj diri, ke ĝi bezonas X-kvanton da rimedoj, kaj tiam K8s eltrovos ĝin memstare. Sed konservada subteno en Kubernetes ankoraŭ estas malstabila: en (ĉi tiu eldono estis publikigita Ĵus antaŭ) ĉi tiuj funkcioj fariĝas nur beta.
Ses monatoj ĝis unu jaro pasos - ĝi fariĝos pli-malpli stabila, aŭ almenaŭ ĝi estos deklarita kiel tia. Tiam la ebleco de momentfotoj kaj regrandigo solvas vian problemon tute. Ĉar vi havas bazon. Jes, ĝi eble ne estas tre rapida, sed la rapideco dependas de tio, kio estas "sub la kapuĉo", ĉar iuj efektivigoj povas kopii kaj kopii-sur-skribi ĉe la disksubsistemnivelo.
НС: Necesas ankaŭ, ke ĉiuj motoroj (Amazon, Guglo...) komencu subteni ĉi tiun version - ĉi tio ankaŭ bezonas iom da tempo.
DS: Ni ankoraŭ ne uzas ilin. Ni uzas nian.
Loka evoluo por Kubernetes
НС: Ĉu vi renkontis tian deziron, kiam vi bezonas instali ĉiujn podojn sur unu maŝino kaj fari tian malgrandan teston. Por rapide akiri pruvon de koncepto, vidu, ke la aplikaĵo funkcias en Kubernetes, sen dediĉi amason da maŝinoj por ĝi. Estas Minikube, ĉu ne?
DS: Ŝajnas al mi, ke ĉi tiu kazo - deplojita sur unu nodo - temas ekskluzive pri loka evoluo. Aŭ iuj manifestiĝoj de tia ŝablono. Manĝu , Estas , . Ni iras al uzado de Kubernetes IN Docker. Nun ni komencis labori kun ĝi por provoj.
НС: Mi kutimis pensi, ke tio estas provo envolvi ĉiujn podojn en unu bildo de Docker. Sed evidentiĝis, ke temas pri io tute alia. Ĉiuokaze, estas apartaj ujoj, apartaj podoj - nur en Docker.
DS: Jes. Kaj estas sufiĉe amuza imitaĵo farita, sed la signifo estas ĉi tiu... Ni havas utilon por deplojo - . Ni volas fari ĝin kondiĉa reĝimo werf up: "Prenu al mi lokajn Kubernetes." Kaj tiam rulu la kondiĉon tie werf follow. Tiam la programisto povos redakti la IDE, kaj procezo estos lanĉita en la sistemo, kiu vidas la ŝanĝojn kaj rekonstruas la bildojn, redeplojante ilin al lokaj K8s. Jen kiel ni volas provi solvi la problemon de loka evoluo.
Momentfotoj kaj datumbaza klonado en K8s-realeco
НС: Se ni revenos al kopio-sur-skribi. Mi rimarkis, ke ankaŭ la nuboj havas momentfotojn. Ili funkcias malsame. Ekzemple, en GCP: vi havas mult-terabajtan ekzemplon sur la orienta marbordo de Usono. Vi periode prenas momentfotojn. Vi prenas kopion de la disko sur la okcidenta marbordo de momentfoto - en kelkaj minutoj ĉio estas preta, ĝi funkcias tre rapide, nur la kaŝmemoro bezonas esti plenigita en memoro. Sed ĉi tiuj klonoj (momentfotoj) estas por "provizi" novan volumon. Ĉi tio estas bonega kiam vi bezonas krei multajn okazojn.
Sed por provoj, ŝajnas al mi, ke momentfotoj, pri kiuj vi parolas en Docker aŭ pri kiuj mi parolas en ZFS, btrfs kaj eĉ LVM... - ili permesas al vi ne krei vere novajn datumojn sur unu maŝino. En la nubo, vi ankoraŭ pagos por ili ĉiufoje kaj atendos ne sekundojn, sed minutojn (kaj en la kazo , eble horloĝo).
Anstataŭe, vi povas akiri ĉi tiujn datumojn en sekundo aŭ du, ruli la teston kaj forĵeti ĝin. Ĉi tiuj fotoj solvas malsamajn problemojn. En la unua kazo - por pligrandigi kaj akiri novajn kopiojn, kaj en la dua - por provoj.
DS: Mi ne konsentas. Fari klonadon de volumo konvene estas la tasko de la nubo. Mi ne rigardis ilian efektivigon, sed mi scias kiel ni faras ĝin sur aparataro. Ni havas Ceph, ĝi permesas ajnan fizikan volumenon () diru klono kaj ricevu duan volumon kun la samaj trajtoj en dekoj da milisekundoj, 'ami, ktp. Vi devas kompreni, ke estas malfacila kopio-sur-skribi interne. Kial la nubo ne faru same? Mi certas, ke ili provas fari ĉi tion unu aŭ alian.
НС: Sed ili ankoraŭ bezonos sekundojn, dekojn da sekundoj por levi ekzemplon, alporti Docker tien, ktp.
DS: Kial necesas levi tutan petskribon? Ni havas ekzemplon kun 32 kernoj, 16... kaj ĝi povas konveni en ĝi - ekzemple, kvar. Kiam ni mendos la kvinan, la petskribo jam estos levita, kaj tiam ĝi estos forigita.
НС: Jes, interese, Kubernetes rezultas esti alia rakonto. Nia datumbazo ne estas en K8s, kaj ni havas unu ekzemplon. Sed klonado de multterabajta datumbazo daŭras ne pli ol du sekundojn.
DS: Ĉi tio estas bonega. Sed mia komenca punkto estas, ke ĉi tio ne estas ĝenerala solvo. Jes, ĝi estas bonega, sed ĝi taŭgas nur por Postgres kaj nur sur unu nodo.
НС: Ĝi taŭgas ne nur por Postgres: ĉi tiuj planoj, kiel mi priskribis, nur funkcios en ĝi. Sed se ni ne zorgas pri planoj, kaj ni nur bezonas ĉiujn datumojn por funkciaj provoj, tiam ĉi tio taŭgas por iu ajn DBMS.
DS: Antaŭ multaj jaroj ni faris ion similan ĉe LVM-fotoj. Ĉi tio estas klasikaĵo. Ĉi tiu aliro estis tre aktive uzata. Stateful nodoj estas nur doloro. Ĉar vi ne devus faligi ilin, vi devus ĉiam memori ilin...
НС: Ĉu vi vidas iun eblecon de hibrido ĉi tie? Ni diru stateful estas ia pod, ĝi funkcias por pluraj homoj (multaj testistoj). Ni havas unu volumon, sed danke al la dosiersistemo, la klonoj estas lokaj. Se la pod falas, sed la disko restas, la pod leviĝos, kalkulos informojn pri ĉiuj klonoj, reprenu ĉion kaj diros: "Jen viaj klonoj funkcias per ĉi tiuj havenoj, daŭrigu labori kun ili."
DS: Teknike tio signifas, ke ene de Kubernetes ĝi estas unu pod, ene de kiu ni kuras multajn Postgres.
НС: Jes. Li havas limon: ni diru, ke ne pli ol 10 homoj laboras kun li samtempe. Se vi bezonas 20, ni lanĉos duan tian podon. Ni plene klonos ĝin, ricevinte la duan plenan volumon, ĝi havos la samajn 10 "maldikajn" klonojn. Ĉu vi ne vidas ĉi tiun ŝancon?
DS: Ni devas aldoni sekurecajn problemojn ĉi tie. Ĉi tiu tipo de organizo implicas, ke ĉi tiu podo havas altajn privilegiojn (kapablojn), ĉar ĝi povas fari nenormajn operaciojn sur la dosiersistemo... Sed mi ripetas: mi kredas, ke meztempe ili riparos stokadon en Kubernetes, kaj en la nubojn ili riparos la tutan rakonton per volumoj - ĉio "nur funkcios". Estos regrandigo, klonado... Estas volumo - ni diras: "Kreu novan surbaze de tio", kaj post sekundo kaj duono ni ricevas tion, kion ni bezonas.
НС: Mi ne kredas je unu kaj duono sekundoj dum multaj terabajtoj. Sur Ceph vi mem faras ĝin, sed vi parolas pri la nuboj. Iru al la nubo, faru klonon de mult-terabajta EBS-volumo sur EC2 kaj vidu, kia estos la agado. Ne daŭros kelkajn sekundojn. Mi tre interesas, kiam ili atingos ĉi tiun nivelon. Mi komprenas, kion vi diras, sed mi petas diferenci.
DS: Bone, sed mi diris meztempe, ne baldaŭ. Dum pluraj jaroj.
Pri la operatoro por PostgreSQL de Zalando
Meze de ĉi tiu renkontiĝo, Alexey Klyukin, iama programisto de Zalando, ankaŭ aliĝis kaj parolis pri la historio de la operatoro PostgreSQL:
Estas bonege, ke ĉi tiu temo estas ĝenerale tuŝita: kaj Postgres kaj Kubernetes. Kiam ni komencis fari ĝin ĉe Zalando en 2017, ĝi estis temo kiun ĉiuj volis fari, sed neniu faris. Ĉiuj jam havis Kubernetes, sed kiam ili demandis kion fari kun datumbazoj, eĉ homoj ŝatas , kiu predikis K8s, diris ion tian:
"Iru al administritaj servoj kaj uzu ilin, ne rulu la datumbazon en Kubernetes. Alie, viaj K8-oj decidos, ekzemple, fari ĝisdatigon, malŝalti ĉiujn nodojn, kaj viaj datumoj flugos malproksimen.
Ni decidis fari funkciigiston kiu, kontraŭe al ĉi tiu konsilo, lanĉos Postgres-datumbazon en Kubernetes. Kaj ni havis bonan kialon - . Ĉi tio estas aŭtomata malsukceso por PostgreSQL, farita ĝuste, t.e. uzante etcd, konsulon aŭ ZooKeeper kiel konservadon de informoj pri la areto. Tia deponejo, kiu donos al ĉiuj, kiuj demandas, kia estas la nuna gvidanto, la samajn informojn – malgraŭ tio, ke ni havas ĉion disdonita – por ke ne estu disigita cerbo. Plie ni havis por li.
Ĝenerale, la bezono de la kompanio pri aŭtomata malsukceso aperis post migrado de interna aparatara datumcentro al la nubo. La nubo baziĝis sur proprieta solvo PaaS (Platform-as-a-Service). Ĝi estas Malferma Kodo, sed necesis multe da laboro por ekfunkciigi ĝin. Ĝi estis nomita .
Komence, ekzistis neniu Kubernetes. Pli precize, kiam nia propra solvo estis deplojita, K8s jam ekzistis, sed ĝi estis tiel kruda ke ĝi ne estis taŭga por produktado. Ĝi estis, laŭ mi, 2015 aŭ 2016. Ĝis 2017, Kubernetes fariĝis pli-malpli matura—estis bezono migri tien.
Kaj ni jam havis Docker-ujon. Estis PaaS kiu uzis Docker. Kial ne provi K8s? Kial ne skribi vian propran operatoron? Murat Kabilov, kiu venis al ni el Avito, komencis ĉi tion kiel projekton pro sia propra iniciato - "ludi" - kaj la projekto "ekiris".
Sed ĝenerale, mi volis paroli pri AWS. Kial ekzistis historia AWS-rilata kodo...
Kiam vi kuras ion en Kubernetes, vi devas kompreni, ke K8s estas tia laboro en progreso. Ĝi konstante disvolvas, pliboniĝas kaj eĉ malfunkcias de tempo al tempo. Vi devas atente observi ĉiujn ŝanĝojn en Kubernetes, vi devas esti preta plonĝi en ĝi se io okazas kaj lerni kiel ĝi funkcias detale - eble pli ol vi ŝatus. Ĉi tio principe validas por ajna platformo sur kiu vi prizorgas viajn datumbazojn...
Do, kiam ni faris la deklaron, ni havis Postgres funkcianta sur ekstera volumo (EBS en ĉi tiu kazo, ĉar ni laboris pri AWS). La datumbazo kreskis, iam necesis regrandigi ĝin: ekzemple, la komenca grandeco de EBS estis 100 TB, la datumbazo kreskis al ĝi, nun ni volas fari EBS 200 TB. Kiel? Ni diru, ke vi povas fari forĵeton/restarigon sur nova kazo, sed tio daŭros longan tempon kaj implikos malfunkcion.
Tial mi volis regrandigi la EBS-diskon kaj poste diri al la dosiersistemo uzi la novan spacon. Kaj ni faris ĝin, sed tiutempe Kubernetes ne havis ajnan API por la regrandigo operacio. Ĉar ni laboris pri AWS, ni skribis kodon por ĝia API.
Neniu malhelpas vin fari la samon por aliaj platformoj. Ne estas sugesto en la deklaro, ke ĝi nur povas ruliĝi per AWS, kaj ĝi ne funkcios pri ĉio alia. Ĝenerale, ĉi tio estas Open Source projekto: se iu volas akceli la aperon de la uzo de la nova API, vi estas bonvena. Manĝu , tirpetoj - la Zalando-teamo provas respondi al ili sufiĉe rapide kaj promocii la funkciigiston. Kiom mi scias, la projekto ĉe Google Summer of Code kaj iuj aliaj similaj iniciatoj. Zalando tre aktive laboras pri ĝi.
PS Gratifiko!
Se vi interesiĝas pri la temo PostgreSQL kaj Kubernetes, do bonvolu ankaŭ noti, ke la venonta Postgres-mardo okazis pasintsemajne, kie mi parolis kun Nikolai Aleksandro Kukuŝkin el Zalando. Video de ĝi haveblas .
PPS
Legu ankaŭ en nia blogo:
- «»;
- «»;
- «»;
- «".
fonto: www.habr.com