Mwishoni mwa mwaka jana, matangazo mengine ya moja kwa moja ya jamii ya Urusi PostgreSQL yalifanyika , Wakati ambapo mwanzilishi wake mwenza Nikolai Samokhvalov alizungumza na mkurugenzi wa kiufundi wa Flant Dmitry Stolyarov kuhusu DBMS hii katika muktadha wa Kubernetes.
Tunachapisha nakala ya sehemu kuu ya mjadala huu, na saa Video kamili imetumwa:
Hifadhidata na Kubernetes
NS: Hatutazungumza kuhusu VACUUM na CHECKPOINTs leo. Tunataka kuzungumza juu ya Kubernetes. Najua una uzoefu wa miaka mingi. Nilitazama video zako na hata kutazama tena baadhi yao... Hebu tuende moja kwa moja kwenye uhakika: kwa nini Postgres au MySQL katika K8s kabisa?
DS: Hakuna na hawezi kuwa na jibu la uhakika kwa swali hili. Lakini kwa ujumla, hii ni unyenyekevu na urahisi ... uwezo. Kila mtu anataka huduma zinazodhibitiwa.
NS: Kwa jinsi gani , nyumbani tu?
DS: Ndiyo: kama RDS, popote pale.
NS: "Popote" ni hatua nzuri. Katika makampuni makubwa, kila kitu iko katika maeneo tofauti. Kwa nini basi, ikiwa ni kampuni kubwa, usichukue suluhisho tayari? Kwa mfano, Nutanix ina maendeleo yake, makampuni mengine (VMware...) yana "RDS sawa, nyumbani tu."
DS: Lakini tunazungumza juu ya utekelezaji tofauti ambao utafanya kazi tu chini ya hali fulani. Na ikiwa tunazungumzia Kubernetes, basi kuna aina kubwa ya miundombinu (ambayo inaweza kuwa katika K8s). Kimsingi hiki ni kiwango cha API kwa wingu...
NS: Pia ni bure!
DS: Sio muhimu sana. Uhuru ni muhimu kwa si sehemu kubwa sana ya soko. Kitu kingine ni muhimu... Pengine unakumbuka ripoti hiyo “?
NS: Ndiyo.
DS: Niligundua kuwa ilipokelewa kwa utata sana. Watu wengine walidhani kwamba nilikuwa nikisema: "Guys, hebu tupate hifadhidata zote kwenye Kubernetes!", Wakati wengine waliamua kuwa hizi zote zilikuwa baiskeli za kutisha. Lakini nilitaka kusema jambo tofauti kabisa: “Angalia kinachoendelea, matatizo yaliyopo na jinsi yanavyoweza kutatuliwa. Je, tunapaswa kutumia hifadhidata za Kubernetes sasa? Uzalishaji? Naam, ikiwa tu unapenda ... kufanya mambo fulani. Lakini kwa dev, naweza kusema kwamba ninapendekeza. Kwa dev, mabadiliko ya kuunda / kufuta mazingira ni muhimu sana.
NS: Kwa dev, unamaanisha mazingira yote ambayo si ya uzalishaji? Jukwaa, QA...
DS: Ikiwa tunazungumzia juu ya vituo vya perf, basi labda sivyo, kwa sababu mahitaji kuna maalum. Ikiwa tunazungumzia kuhusu kesi maalum ambapo database kubwa sana inahitajika kwa ajili ya staging, basi labda si ... Ikiwa hii ni mazingira ya tuli, ya muda mrefu, basi ni faida gani ya kuwa na database iko katika K8s?
NS: Hapana. Lakini tunaona wapi mazingira tuli? Mazingira tulivu yatapitwa na wakati kesho.
DS: Staging inaweza kuwa tuli. Tuna wateja...
NS: Ndiyo, ninayo pia. Ni shida kubwa ikiwa una hifadhidata ya TB 10 na uwekaji wa GB 200...
DS: Nina kesi nzuri sana! Kwenye jukwaa kuna hifadhidata ya bidhaa ambayo mabadiliko hufanywa. Na kuna kifungo: "kutoka kwa uzalishaji". Mabadiliko haya - deltas - yanaongezwa (inaonekana kuwa yamesawazishwa kupitia API) katika uzalishaji. Hii ni chaguo la kigeni sana.
NS: Nimeona wanaoanza katika Bonde ambao wameketi katika RDS au hata Heroku - hizi ni hadithi za miaka 2-3 iliyopita - na wanapakua utupaji kwenye kompyuta zao ndogo. Kwa sababu hifadhidata bado ni GB 80 tu, na kuna nafasi kwenye kompyuta ndogo. Kisha wananunua diski za ziada kwa kila mtu ili wawe na hifadhidata 3 za kutekeleza maendeleo tofauti. Hivi ndivyo inavyotokea pia. Pia niliona kuwa hawaogopi kunakili prod kwenye hatua - inategemea sana kampuni. Lakini pia niliona kwamba wanaogopa sana, na kwamba mara nyingi hawana muda wa kutosha na mikono. Lakini kabla hatujaendelea na mada hii, ningependa kusikia kuhusu Kubernetes. Je! ninaelewa kwa usahihi kuwa bado hakuna mtu anayetengeneza?
DS: Tuna hifadhidata ndogo katika uzalishaji. Tunazungumza juu ya makumi ya gigabytes na huduma zisizo muhimu ambazo tulikuwa wavivu sana kutengeneza nakala (na hakuna hitaji kama hilo). Na mradi kuna uhifadhi wa kawaida chini ya Kubernetes. Hifadhidata hii ilifanya kazi katika mashine pepe - kwa masharti katika VMware, juu ya mfumo wa kuhifadhi. Tuliiweka ndani na sasa tunaweza kuihamisha kutoka kwa mashine hadi kwa mashine.
NS: Hifadhidata za ukubwa huu, hadi GB 100, zinaweza kutolewa kwa dakika chache kwenye diski nzuri na mtandao mzuri, sawa? Kasi ya GB 1 kwa sekunde sio ya kigeni tena.
DS: Ndio, kwa operesheni ya laini hii sio shida.
NS: Sawa, inabidi tu tufikirie kuhusu prod. Na ikiwa tunazingatia Kubernetes kwa mazingira yasiyo ya uzalishaji, tunapaswa kufanya nini? Naona huko Zalando , katika Crunchy , kuna chaguzi zingine. Na kuna - huyu ni rafiki yetu mzuri Alvaro kutoka Uhispania: wanachofanya kimsingi sio tu , na usambazaji mzima (), ambayo, pamoja na Postgres yenyewe, waliamua pia kuweka nakala rudufu, wakala wa Mjumbe...
DS: Mjumbe wa nini? Kusawazisha trafiki ya Postgres haswa?
NS: Ndiyo. Hiyo ni, wanaona kama: ikiwa unachukua usambazaji wa Linux na kernel, basi PostgreSQL ya kawaida ni kernel, na wanataka kufanya usambazaji ambao utakuwa wa kirafiki wa wingu na kukimbia kwenye Kubernetes. Wanaweka pamoja vipengele (chelezo, nk) na kuzitatua ili zifanye kazi vizuri.
DS: Poa sana! Kimsingi hii ni programu ya kuunda Postgres zako zinazosimamiwa.
NS: Usambazaji wa Linux una shida za milele: jinsi ya kutengeneza madereva ili vifaa vyote viungwe. Na wana wazo kwamba watafanya kazi Kubernetes. Ninajua kuwa katika opereta wa Zalando tuliona muunganisho wa AWS hivi karibuni na hii sio nzuri sana. Haipaswi kuwa na uhusiano na miundombinu maalum - ni jambo gani basi?
DS: Sijui ni hali gani hasa Zalando aliingia, lakini katika hifadhi ya Kubernetes sasa inafanywa kwa namna ambayo haiwezekani kuchukua hifadhi ya disk kwa kutumia njia ya generic. Hivi karibuni katika kiwango - katika toleo la hivi karibuni - tulifanya snapshots iwezekanavyo, lakini inatekelezwa wapi? Kusema kweli, kila kitu bado ni kibichi... Tunajaribu CSI juu ya AWS, GCE, Azure, vSphere, lakini punde tu unapoanza kuitumia, unaweza kuona kwamba bado haijawa tayari.
NS: Ndiyo maana wakati mwingine tunalazimika kutegemea miundombinu. Nadhani hii bado ni hatua ya mapema - maumivu ya kukua. Swali: Ni ushauri gani unaweza kuwapa wanaoanza wanaotaka kujaribu PgSQL katika K8s? Ni operator gani labda?
DS: Tatizo ni kwamba Postgres ni 3% kwa ajili yetu. Pia tuna orodha kubwa sana ya programu tofauti katika Kubernetes, hata sitaorodhesha kila kitu. Kwa mfano, Elasticsearch. Kuna waendeshaji wengi: wengine wanaendeleza kikamilifu, wengine sio. Tumejitengenezea mahitaji kuhusu kile ambacho mwendeshaji anapaswa kuwa nacho ili tukichukulie kwa uzito. Katika opereta mahususi kwa ajili ya Kubernetes - si katika "opereta kufanya kitu katika hali ya Amazon"... Kwa kweli, sisi kwa upana kabisa (= karibu wateja wote) tunatumia opereta moja - (tutachapisha makala kuhusu yeye hivi karibuni).
NS: Na sio kwa MySQL pia? Ninajua kuwa Percona... kwa kuwa sasa wanafanya kazi kwenye MySQL, MongoDB, na Postgres, watalazimika kuunda aina fulani ya suluhisho la ulimwengu wote: kwa hifadhidata zote, kwa watoa huduma wote wa wingu.
DS: Hatukuwa na muda wa kuangalia waendeshaji wa MySQL. Hili sio lengo letu kuu kwa sasa. MySQL inafanya kazi vizuri kwa kujitegemea. Kwa nini utumie opereta ikiwa unaweza tu kuzindua hifadhidata... Unaweza kuzindua kontena ya Docker na Postrges, au unaweza kuizindua kwa njia rahisi.
NS: Kulikuwa na swali kuhusu hili pia. Hakuna mwendeshaji hata kidogo?
DS: Ndiyo, 100% yetu tuna PostgreSQL inayoendesha bila mwendeshaji. Hadi sasa hivyo. Tunatumia opereta kikamilifu kwa Prometheus na Redis. Tuna mipango ya kupata opereta wa Elasticsearch - ndio "moto" zaidi, kwa sababu tunataka kuiweka Kubernetes katika 100% ya kesi. Kama vile tunavyotaka kuhakikisha kuwa MongoDB pia imesakinishwa kila wakati katika Kubernetes. Hapa matakwa fulani yanaonekana - kuna hisia kwamba katika kesi hizi kitu kinaweza kufanywa. Na hata hatukuangalia Postgres. Bila shaka, tunajua kwamba kuna chaguo tofauti, lakini kwa kweli tuna kujitegemea.
DB kwa majaribio katika Kubernetes
NS: Hebu tuendelee kwenye mada ya kupima. Jinsi ya kufanya mabadiliko kwenye hifadhidata - kutoka kwa mtazamo wa DevOps. Kuna huduma ndogo ndogo, hifadhidata nyingi, kitu kinabadilika mahali fulani kila wakati. Jinsi ya kuhakikisha CI/CD ya kawaida ili kila kitu kiwe sawa kutoka kwa mtazamo wa DBMS. Nini mtazamo wako?
DS: Hakuwezi kuwa na jibu moja. Kuna chaguzi kadhaa. Ya kwanza ni saizi ya msingi ambayo tunataka kusambaza. Wewe mwenyewe ulitaja kuwa makampuni yana mitazamo tofauti kuhusu kuwa na nakala ya hifadhidata ya prod kwenye dev na jukwaa.
NS: Na kwa masharti ya GDPR, nadhani wanakuwa makini zaidi na zaidi... naweza kusema huko Ulaya tayari wameanza kutoza faini.
DS: Lakini mara nyingi unaweza kuandika programu ambayo inachukua utupaji kutoka kwa uzalishaji na kuipotosha. Data ya uzalishaji hupatikana (picha, dampo, nakala ya jozi...), lakini haijatambulishwa. Badala yake, kunaweza kuwa na hati za kizazi: hizi zinaweza kuwa marekebisho au hati tu ambayo hutoa hifadhidata kubwa. Shida ni: inachukua muda gani kuunda picha ya msingi? Na inachukua muda gani kuipeleka katika mazingira unayotaka?
Tulikuja kwenye mpango: ikiwa mteja ana seti ya data iliyowekwa (toleo ndogo la hifadhidata), basi tunazitumia kwa chaguo-msingi. Ikiwa tunazungumza juu ya mazingira ya ukaguzi, tulipounda tawi, tulituma mfano wa programu - tunatoa hifadhidata ndogo hapo. Lakini iligeuka vizuri , tunapochukua dampo kutoka kwa uzalishaji mara moja kwa siku (usiku) na kuunda kontena la Docker na PostgreSQL na MySQL na data hii iliyopakiwa kulingana nayo. Ikiwa unahitaji kupanua hifadhidata mara 50 kutoka kwa picha hii, hii inafanywa kwa urahisi na haraka.
NS: Kwa kunakili rahisi?
DS: Data imehifadhiwa moja kwa moja kwenye picha ya Docker. Wale. Tuna picha iliyotengenezwa tayari, pamoja na GB 100. Shukrani kwa tabaka kwenye Docker, tunaweza kusambaza picha hii haraka iwezekanavyo mara nyingi tunavyohitaji. Njia hiyo ni ya kijinga, lakini inafanya kazi vizuri.
NS: Halafu, unapojaribu, inabadilika ndani ya Docker, sivyo? Nakili-kwa-kuandika ndani ya Docker - itupe na uende tena, kila kitu kiko sawa. Darasa! Na tayari unaitumia kikamilifu?
DS: Kwa muda mrefu.
NS: Tunafanya mambo yanayofanana sana. Ni sisi tu hatutumii nakala-ya-kuandika ya Docker, lakini nyingine.
DS: Sio kawaida. Na Docker inafanya kazi kila mahali.
NS: Kwa nadharia, ndiyo. Lakini pia tuna moduli huko, unaweza kufanya moduli tofauti na kufanya kazi na mifumo tofauti ya faili. Ni muda gani hapa. Kutoka kwa upande wa Postgres, tunaangalia haya yote kwa njia tofauti. Sasa niliangalia kutoka upande wa Docker na nikaona kuwa kila kitu kinakufanyia kazi. Lakini ikiwa hifadhidata ni kubwa, kwa mfano, 1 TB, basi hii yote inachukua muda mrefu: shughuli za usiku, na kuingiza kila kitu kwenye Docker ... Na ikiwa TB 5 imefungwa kwenye Docker ... Au kila kitu ni sawa?
DS: Kuna tofauti gani: hizi ni blobs, biti na ka tu.
NS: Tofauti ni hii: unaifanya kwa njia ya kutupa na kurejesha?
DS: Sio lazima hata kidogo. Njia za kuunda picha hii zinaweza kuwa tofauti.
NS: Kwa wateja wengine, tumeifanya ili badala ya kutengeneza picha ya msingi mara kwa mara, tunaisasisha kila mara. Kimsingi ni nakala, lakini hupokea data sio kutoka kwa bwana moja kwa moja, lakini kupitia kumbukumbu. Kumbukumbu ya binary ambapo WAL hupakuliwa kila siku, ambapo nakala rudufu huchukuliwa... WAL hizi kisha hufikia picha ya msingi kwa kuchelewa kidogo (sekunde 1-2). Tunatengeneza kutoka kwayo kwa njia yoyote - sasa tuna ZFS kwa msingi.
DS: Lakini na ZFS umezuiliwa kwa nodi moja.
NS: Ndiyo. Lakini ZFS pia ina kichawi : nayo unaweza kutuma picha ndogo na hata (sijajaribu hii bado, lakini...) unaweza kutuma delta kati ya mbili. PGDATA. Kwa kweli, tuna zana nyingine ambayo hatujazingatia kabisa kwa kazi kama hizo. PostgreSQL ina , ambayo hufanya kazi kama rsync ya "smart", kuruka mengi ambayo hutakiwi kutazama, kwa sababu hakuna kilichobadilika hapo. Tunaweza kufanya ulandanishi wa haraka kati ya seva mbili na kurudi nyuma kwa njia sawa.
Kwa hivyo, kutoka kwa hii, upande wa DBA zaidi, tunajaribu kuunda zana ambayo inaturuhusu kufanya kitu kile kile ulichosema: tuna hifadhidata moja, lakini tunataka kujaribu kitu mara 50, karibu wakati huo huo.
DS: Mara 50 inamaanisha unahitaji kuagiza matukio 50 ya Spot.
NS: Hapana, tunafanya kila kitu kwenye mashine moja.
DS: Lakini utapanua vipi mara 50 ikiwa hifadhidata hii moja ni, tuseme, terabyte. Uwezekano mkubwa zaidi anahitaji 256 GB ya RAM ya masharti?
NS: Ndiyo, wakati mwingine unahitaji kumbukumbu nyingi - hiyo ni kawaida. Lakini hii ni mfano kutoka kwa maisha. Mashine ya uzalishaji ina cores 96 na 600 GB. Wakati huo huo, cores 32 (hata cores 16 sasa wakati mwingine) na 100-120 GB ya kumbukumbu hutumiwa kwa hifadhidata.
DS: Na nakala 50 zinafaa huko?
NS: Kwa hiyo kuna nakala moja tu, kisha nakala-on-write (ZFS) inafanya kazi ... Nitawaambia kwa undani zaidi.
Kwa mfano, tuna hifadhidata 10 za TB. Walitengeneza diski kwa ajili yake, ZFS pia ilisisitiza ukubwa wake kwa asilimia 30-40. Kwa kuwa hatufanyi majaribio ya upakiaji, muda halisi wa kujibu si muhimu kwetu: wacha iwe hadi mara 2 polepole - ni sawa.
Tunatoa fursa kwa watengeneza programu, QA, DBA, nk. fanya majaribio katika nyuzi 1-2. Kwa mfano, wanaweza kukimbia aina fulani ya uhamiaji. Haihitaji cores 10 mara moja - inahitaji 1 Postgres backend, 1 msingi. Uhamiaji utaanza - labda bado itaanza, kisha msingi wa pili utatumika. Tuna cores 16-32 zilizotengwa, hivyo watu 10 wanaweza kufanya kazi kwa wakati mmoja, hakuna tatizo.
Kwa sababu kimwili PGDATA sawa, inageuka kuwa tunawadanganya Postgres. Ujanja ni huu: kwa mfano, Postgres 10 zinazinduliwa wakati huo huo. Tatizo ni nini kwa kawaida? Wanaweka , tuseme 25%. Ipasavyo, hii ni 200 GB. Hutaweza kuzindua zaidi ya tatu kati ya hizi, kwa sababu kumbukumbu itaisha.
Lakini wakati fulani tuligundua kuwa hii haikuwa lazima: tuliweka pamoja_buffers hadi 2 GB. PostgreSQL ina , na kwa kweli ndiyo pekee inayoathiri . Tunaweka kwa 0,5 TB. Na haijalishi hata kuwa haipo: anapanga mipango kana kwamba ipo.
Ipasavyo, tunapojaribu aina fulani ya uhamiaji, tunaweza kukusanya mipango yote - tutaona jinsi itatokea katika uzalishaji. Sekunde kutakuwa na tofauti (polepole), lakini data ambayo tunasoma kwa kweli, na mipango yenyewe (nini JOINs huko, nk) inageuka sawa na katika uzalishaji. Na unaweza kuendesha hundi nyingi kama hizo sambamba kwenye mashine moja.
DS: Je, hufikirii kuna matatizo machache hapa? Ya kwanza ni suluhisho ambalo linafanya kazi tu kwenye PostgreSQL. Njia hii ni ya kibinafsi sana, sio ya kawaida. Ya pili ni kwamba Kubernetes (na kila kitu ambacho teknolojia za wingu zinakwenda sasa) inahusisha nodes nyingi, na nodes hizi ni za ephemeral. Na kwa upande wako ni nodi ya hali, inayoendelea. Mambo haya yananifanya niwe na migogoro.
NS: Kwanza, ninakubali, hii ni hadithi ya Postgres. Nadhani ikiwa tuna aina fulani ya IO ya moja kwa moja na bwawa la buffer kwa karibu kumbukumbu zote, mbinu hii haitafanya kazi - mipango itakuwa tofauti. Lakini kwa sasa tunafanya kazi tu na Postgres, hatufikirii kuhusu wengine.
Kuhusu Kubernetes Wewe mwenyewe unatuambia kila mahali kwamba tuna hifadhidata inayoendelea. Ikiwa mfano unashindwa, jambo kuu ni kuokoa diski. Hapa pia tuna jukwaa zima katika Kubernetes, na kijenzi kilicho na Postgres ni tofauti (ingawa kitakuwepo siku moja). Kwa hivyo, kila kitu ni kama hii: mfano ulianguka, lakini tulihifadhi PV yake na kuiunganisha kwa mfano mwingine (mpya), kana kwamba hakuna kitu kilichotokea.
DS: Kwa mtazamo wangu, tunaunda maganda katika Kubernetes. K8s - elastic: mafundo yanaamriwa kama inahitajika. Kazi ni kuunda tu ganda na kusema kwamba inahitaji kiasi cha X cha rasilimali, na kisha K8s itabaini yenyewe. Lakini usaidizi wa kuhifadhi katika Kubernetes bado si thabiti: ndani (toleo hili lilitolewa ya wiki ago) vipengele hivi vinakuwa beta pekee.
Miezi sita hadi mwaka itapita - itakuwa thabiti zaidi au kidogo, au angalau itatangazwa hivyo. Kisha uwezekano wa snapshots na resize kutatua tatizo lako kabisa. Kwa sababu una msingi. Ndiyo, inaweza kuwa si haraka sana, lakini kasi inategemea kile kilicho "chini ya hood", kwa sababu baadhi ya utekelezaji unaweza kunakili na kuandika-kuandika kwenye ngazi ya mfumo mdogo wa disk.
NS: Ni muhimu pia kwa injini zote (Amazon, Google...) kuanza kusaidia toleo hili - hii pia inachukua muda.
DS: Bado hatuzitumii. Tunatumia yetu.
Maendeleo ya ndani kwa Kubernetes
NS: Umewahi kukutana na hamu kama hiyo wakati unahitaji kusakinisha maganda yote kwenye mashine moja na kufanya jaribio ndogo kama hilo. Ili kupata uthibitisho wa dhana haraka, angalia kwamba programu inaendeshwa Kubernetes, bila kuweka wakfu kundi la mashine kwa ajili yake. Kuna Minikube, sivyo?
DS: Inaonekana kwangu kwamba kesi hii - iliyowekwa kwenye nodi moja - inahusu maendeleo ya ndani pekee. Au udhihirisho fulani wa muundo kama huo. Kula , kuna , . Tunaelekea kutumia Kubernetes IN Docker. Sasa tulianza kufanya kazi nayo kwa vipimo.
NS: Nilikuwa nikifikiria kuwa hili lilikuwa jaribio la kufunga maganda yote kwenye picha moja ya Docker. Lakini ikawa kwamba hii ni kuhusu kitu tofauti kabisa. Kwa hivyo, kuna vyombo tofauti, maganda tofauti - kwenye Docker tu.
DS: Ndiyo. Na kuna uigaji wa kuchekesha uliotengenezwa, lakini maana ni hii... Tunayo matumizi ya kupeleka - . Tunataka kuifanya hali ya masharti werf up: "Nipatie Kubernetes ya karibu." Na kisha endesha masharti hapo werf follow. Kisha msanidi ataweza kuhariri IDE, na mchakato utazinduliwa katika mfumo unaoona mabadiliko na kuunda upya picha, na kuzipeleka kwa K8 za ndani. Hivi ndivyo tunavyotaka kujaribu kutatua tatizo la maendeleo ya ndani.
Picha na uundaji wa hifadhidata katika uhalisia wa K8s
NS: Tukirudi kunakili-kwa-kuandika. Niligundua kuwa mawingu pia yana snapshots. Wanafanya kazi tofauti. Kwa mfano, katika GCP: una mfano wa terabyte nyingi kwenye pwani ya mashariki ya Marekani. Unapiga picha mara kwa mara. Unachukua nakala ya diski kwenye pwani ya magharibi kutoka kwa snapshot - kwa dakika chache kila kitu ni tayari, inafanya kazi kwa haraka sana, tu cache inahitaji kujazwa katika kumbukumbu. Lakini clones hizi (snapshots) ni kwa ajili ya kutoa kiasi kipya. Hii ni nzuri wakati unahitaji kuunda matukio mengi.
Lakini kwa vipimo, inaonekana kwangu kuwa snapshots, ambazo unazungumza juu ya Docker au ninazungumza juu ya ZFS, btrfs na hata LVM ... - hukuruhusu kuunda data mpya kwenye mashine moja. Katika wingu, bado utawalipa kila wakati na usisubiri sio sekunde, lakini dakika (na katika kesi hiyo , ikiwezekana saa).
Badala yake, unaweza kupata data hii kwa sekunde moja au mbili, endesha jaribio na uitupe. Picha hizi fupi hutatua matatizo tofauti. Katika kesi ya kwanza - kuongeza na kupata nakala mpya, na kwa pili - kwa vipimo.
DS: Sikubali. Kufanya cloning kiasi kufanya kazi vizuri ni kazi ya wingu. Sijaangalia utekelezaji wao, lakini najua jinsi tunavyofanya kwenye vifaa. Tuna Ceph, inaruhusu kiasi chochote cha kimwili () kusema Clone na upate juzuu ya pili yenye sifa sawa katika makumi ya milisekunde, ‘ami, nk. Unahitaji kuelewa kuwa kuna nakala ngumu ya kuandika ndani. Kwa nini wingu lisifanye vivyo hivyo? Nina hakika wanajaribu kufanya hivi kwa njia moja au nyingine.
NS: Lakini bado itawachukua sekunde, makumi ya sekunde kuongeza mfano, kuleta Docker hapo, nk.
DS: Kwa nini ni muhimu kuongeza mfano mzima? Tuna mfano na cores 32, 16 ... na inaweza kuingia ndani yake - kwa mfano, nne. Tunapoagiza ya tano, mfano tayari utafufuliwa, na kisha utafutwa.
NS: Ndiyo, ya kuvutia, Kubernetes inageuka kuwa hadithi tofauti. Hifadhidata yetu haiko katika K8s, na tuna mfano mmoja. Lakini kuunda hifadhidata ya terabyte nyingi huchukua si zaidi ya sekunde mbili.
DS: Hii ni nzuri. Lakini hoja yangu ya awali ni kwamba hii sio suluhisho la kawaida. Ndiyo, ni baridi, lakini inafaa tu kwa Postgres na kwenye node moja tu.
NS: Haifai tu kwa Postgres: mipango hii, kama nilivyoelezea, itafanya kazi ndani yake tu. Lakini ikiwa hatujisumbui kuhusu mipango, na tunahitaji tu data zote kwa ajili ya kupima kazi, basi hii inafaa kwa DBMS yoyote.
DS: Miaka mingi iliyopita tulifanya kitu kama hicho kwenye vijipicha vya LVM. Hii ni classic. Mbinu hii ilitumika sana. Nodi za serikali ni maumivu tu. Kwa sababu haupaswi kuziacha, unapaswa kuzikumbuka kila wakati ...
NS: Je, unaona uwezekano wowote wa kuwa na mseto hapa? Wacha tuseme stateful ni aina fulani ya ganda, inafanya kazi kwa watu kadhaa (wajaribu wengi). Tuna kiasi kimoja, lakini shukrani kwa mfumo wa faili, clones ni za ndani. Ikiwa ganda litaanguka, lakini diski inabaki, ganda litainuka, kuhesabu habari kuhusu clones zote, chukua kila kitu tena na kusema: "Hizi ni clones zako zinazoendesha kwenye bandari hizi, endelea kufanya kazi nazo."
DS: Kitaalam hii ina maana kwamba ndani ya Kubernetes ni ganda moja ambalo tunaendesha Postgres nyingi.
NS: Ndiyo. Ana kikomo: tuseme hakuna zaidi ya watu 10 wanaofanya kazi naye kwa wakati mmoja. Ikiwa unahitaji 20, tutazindua ganda la pili kama hilo. Tutaifunga kikamilifu, baada ya kupokea kiasi cha pili kamili, itakuwa na clones 10 "nyembamba" sawa. Je, huoni fursa hii?
DS: Tunahitaji kuongeza masuala ya usalama hapa. Aina hii ya shirika ina maana kwamba pod hii ina marupurupu ya juu (uwezo), kwa sababu inaweza kufanya shughuli zisizo za kawaida kwenye mfumo wa faili ... Lakini narudia: Ninaamini kwamba kwa muda wa kati watatengeneza hifadhi katika Kubernetes, na katika mawingu watarekebisha hadithi nzima kwa wingi - kila kitu "kitafanya kazi tu". Kutakuwa na resize, cloning ... Kuna kiasi - tunasema: "Unda mpya kulingana na hilo," na baada ya pili na nusu tunapata kile tunachohitaji.
NS: Siamini katika sekunde moja na nusu kwa terabytes nyingi. Kwenye Ceph unafanya mwenyewe, lakini unazungumza juu ya mawingu. Nenda kwenye wingu, tengeneza sauti ya EBS ya terabyte nyingi kwenye EC2 na uone utendakazi utakuwaje. Haitachukua sekunde chache. Ninavutiwa sana na wakati watafikia kiwango hiki. Ninaelewa unachosema, lakini naomba kutofautiana.
DS: Sawa, lakini nilisema kwa muda wa kati, sio wa muda mfupi. Kwa miaka kadhaa.
Kuhusu opereta wa PostgreSQL kutoka Zalando
Katikati ya mkutano huu, Alexey Klyukin, msanidi programu wa zamani kutoka Zalando, pia alijiunga na kuzungumza juu ya historia ya opereta wa PostgreSQL:
Ni vyema kuwa mada hii inaguswa kwa ujumla: Postgres na Kubernetes. Tulipoanza kuifanya Zalando mnamo 2017, ilikuwa mada ambayo kila mtu alitaka kufanya, lakini hakuna aliyeifanya. Kila mtu tayari alikuwa na Kubernetes, lakini walipouliza nini cha kufanya na hifadhidata, hata watu wanapenda , ambaye alihubiri K8s, alisema kitu kama hiki:
"Nenda kwa huduma zinazosimamiwa na uzitumie, usiendeshe hifadhidata huko Kubernetes. Vinginevyo, K8s zako zitaamua, kwa mfano, kufanya uboreshaji, kuzima nodi zote, na data yako itaruka mbali, mbali zaidi.
Tuliamua kutengeneza opereta ambayo, kinyume na ushauri huu, itazindua hifadhidata ya Postgres huko Kubernetes. Na tulikuwa na sababu nzuri - . Hii ni kushindwa kwa moja kwa moja kwa PostgreSQL, iliyofanywa kwa usahihi, i.e. kutumia etcd, balozi au ZooKeeper kama hifadhi ya taarifa kuhusu nguzo. Hifadhi kama hiyo ambayo itampa kila mtu anayeuliza, kwa mfano, kiongozi wa sasa ni nini, habari sawa - licha ya kwamba kila kitu tumesambazwa - ili hakuna ubongo uliogawanyika. Zaidi tulikuwa nayo kwa ajili yake.
Kwa ujumla, haja ya kampuni ya kushindwa kwa auto ilionekana baada ya kuhama kutoka kituo cha data cha vifaa vya ndani hadi kwenye wingu. Wingu lilitokana na suluhu inayomilikiwa na PaaS (Platform-as-a-Service). Ni Chanzo Huria, lakini ilichukua kazi nyingi kuianzisha na kuiendesha. Iliitwa .
Hapo awali, hakukuwa na Kubernetes. Kwa usahihi zaidi, wakati suluhisho letu lilipotumwa, K8 tayari zilikuwepo, lakini ilikuwa ghafi sana kwamba haikufaa kwa uzalishaji. Ilikuwa, kwa maoni yangu, 2015 au 2016. Kufikia 2017, Kubernetes alikuwa amekomaa zaidi au kidogo—kulikuwa na haja ya kuhamia huko.
Na tayari tulikuwa na chombo cha Docker. Kulikuwa na PaaS ambayo ilitumia Docker. Kwa nini usijaribu K8s? Kwa nini usiandike mwendeshaji wako mwenyewe? Murat Kabilov, ambaye alikuja kwetu kutoka Avito, alianza hii kama mradi kwa hiari yake mwenyewe - "kucheza" - na mradi "ulianza."
Lakini kwa ujumla, nilitaka kuzungumza juu ya AWS. Kwa nini kulikuwa na nambari ya kihistoria inayohusiana na AWS ...
Unapoendesha kitu katika Kubernetes, unahitaji kuelewa kuwa K8 ni kazi inayoendelea. Inaendelea kuendeleza, kuboresha na hata kuvunja mara kwa mara. Unahitaji kuangalia kwa karibu mabadiliko yote katika Kubernetes, unahitaji kuwa tayari kupiga mbizi ndani yake ikiwa kitu kitatokea na kujifunza jinsi inavyofanya kazi kwa undani - labda zaidi kuliko ungependa. Hii, kimsingi, inatumika kwa jukwaa lolote ambalo unaendesha hifadhidata zako...
Kwa hiyo, tulipofanya taarifa hiyo, tulikuwa na Postgres inayoendesha kiasi cha nje (EBS katika kesi hii, kwa kuwa tulikuwa tukifanya kazi kwenye AWS). Database ilikua, wakati fulani ilikuwa ni lazima kurekebisha ukubwa wake: kwa mfano, ukubwa wa awali wa EBS ulikuwa 100 TB, database ilikua, sasa tunataka kufanya EBS 200 TB. Vipi? Wacha tuseme unaweza kufanya utupaji / kurejesha kwa mfano mpya, lakini hii itachukua muda mrefu na kuhusisha wakati wa kupumzika.
Kwa hivyo, nilitaka resize ambayo ingeongeza kizigeu cha EBS na kisha kuwaambia mfumo wa faili kutumia nafasi mpya. Na tulifanya hivyo, lakini wakati huo Kubernetes hakuwa na API yoyote ya operesheni ya kurekebisha ukubwa. Kwa kuwa tulifanya kazi kwenye AWS, tuliandika nambari ya API yake.
Hakuna anayekuzuia kufanya vivyo hivyo kwa majukwaa mengine. Hakuna maoni katika taarifa kwamba inaweza tu kuendeshwa kwenye AWS, na haitafanya kazi kwa kila kitu kingine. Kwa ujumla, huu ni mradi wa Open Source: ikiwa mtu yeyote anataka kuharakisha kuibuka kwa matumizi ya API mpya, unakaribishwa. Kula , maombi ya kuvuta - timu ya Zalando inajaribu kujibu haraka sana na kukuza mwendeshaji. Kwa kadiri ninavyojua, mradi huo katika Majira ya joto ya Google ya Kanuni na mipango mingine kama hiyo. Zalando inafanya kazi kwa bidii juu yake.
P.S. Ziada!
Ikiwa una nia ya mada ya PostgreSQL na Kubernetes, basi tafadhali kumbuka kuwa Jumanne ijayo ya Postgres ilifanyika wiki iliyopita, ambapo nilizungumza na Nikolai. Alexander Kukushkin kutoka Zalando. Video kutoka kwake inapatikana .
PPS
Soma pia kwenye blogi yetu:
- «";
- «";
- «";
- «'.
Chanzo: mapenzi.com