Update!. Di şîroveyan de, yek ji xwendevanan pêşniyar kir ku hewl bidin (dibe ku ew bi xwe li ser wê dixebite) ji ber vê yekê min beşek li ser vê çareseriyê zêde kiriye. Min jî nivîsand , ji ber ku pêvajo ji yên din pir cuda ye.
Bi rastî, min dev jê berda û dev jê berda (qet nebe ji bo niha). Ez ê bikar bînim . Çima? Ji ber hilanînê! Kê dê bifikirî ku ez ê ji Kubernetes bi xwe bêtir hilanînê bixebitim. Ez bi kar tînim ji ber ku ew erzan e û performansa baş e û ji destpêkê ve min koman bi kar tîne . Min karûbarên Kubernetes yên ji Google/Amazon/Microsoft/DigitalOcean, hwd., hwd., û hwd. ya rêvebirinî ceriband, ji ber ku min dixwest ez bixwe her tiştî fêr bibim. Ez jî erzan im.
Ji ber vê yekê erê, min gelek wext derbas kir ku ez biryar bidim ka kîjan hilanînê hilbijêrin dema ku min stûnek gengaz a Kubernetes dinirxand. Ez çareseriyên çavkaniya vekirî tercîh dikim, ne tenê ji ber bihayê, lê min ji meraqê li çend vebijarkên drav nihêrî ji ber ku wan guhertoyên belaş ên bi sînor hene. Dema ku min vebijarkên cihêreng dan ber hev, min hin hejmar ji ceribandinên vê dawiyê tomar kir, û dibe ku ew ji wan kesên ku di derheqê hilanîna Kubernetes de fêr dibin balkêş bin. Her çend min bixwe ji bo nuha xatir ji Kubernetes xwestiye. Ez jî dixwazim behs bikim , ku dikare rasterast cildên Hetzner Cloud peyda bike, lê min hîn ew ceriband. Min li hilanîna nermalava-dîyarkirî ya ewr nihêrî ji ber ku min hewcedarî dubarekirin û şiyana ku ez bi lez cildên domdar li ser her girêkekê bigirim, bi taybetî di rewşa têkçûna girêk û rewşên din ên bi vî rengî de hewce bûm. Hin çareserî dîmenên xal-di-dem û paşvekêşana derveyî malperê pêşkêşî dikin, ku ev hêsan e.
Min 6-7 çareseriyên hilanînê ceriband:
Wekî ku min berê jî got Piştî ku piraniya vebijarkên ji navnîşê ceriband, min di destpêkê de li ser OpenEBS rûnişt. OpenEBS saz kirin û bikar anîn pir hêsan e, lê rast be, piştî ceribandina daneyên rastîn ên di bin barkirinê de, ez ji performansa wê bêhêvî bûm. Ev çavkaniyek vekirî ye, û pêşdebir bi xwe ne gava ku ez hewceyê alîkariyê bûm her gav pir alîkar e. Mixabin, ew li gorî vebijarkên din performansa wê pir xirab e, ji ber vê yekê pêdivî bû ku ceribandin ji nû ve werin meşandin. OpenEBS niha 3 motorên hilanînê hene, lê ez encamên pîvanê ji bo cStor diweşînim. Ji bo Jiva û LocalPV hêj hejmarên min tune ne.
Bi kurtasî, Jiva piçek zûtir e, û LocalPV bi gelemperî bilez e, ne ji pîvana dîskê rasterast xirabtir e. Pirsgirêka LocalPV ev e ku hêjmar tenê li ser girêka ku lê hatî amade kirin dikare were gihandin, û bi tevahî dubare tune. Di vegerandina hilanînê de hin pirsgirêkên min hebûn li ser komek nû ji ber ku navên node cuda bûn. Ger em li ser paşkêşan biaxivin, cStor heye , ya ku hûn dikarin di demek wextê de paşvekêşana wêneyan li derveyî malperê çêbikin, ku ji paşvekêşana asta pelê ya bi Velero-Restic re hêsantir e. Min nivîsand , da ku bi vê pêvekê re birêvebirina hilanînê û sererastkirinan hêsantir bike. Bi tevayî, ez bi rastî ji OpenEBS hez dikim, lê performansa wê ...
Rook di heman demê de çavkaniyek vekirî ye û ji vebijarkên mayî yên di navnîşê de cûda dibe ku ew orkestratorek hilanînê ye ku karên rêveberiya hilanînê ya tevlihev bi paşnavên cihêreng pêk tîne, mînakî. , û yên din, ku kar pir hêsan dike. Dema ku min çend meh berê ceriband bi EfgeFS re pirsgirêkên min hebûn, ji ber vê yekê min bi giranî bi Ceph re ceriband. Ceph ne tenê hilanîna blokê pêşkêşî dike, lê di heman demê de hilanîna tiştan jî bi S3 / Swift û pergala pelê belavkirî re hevaheng e. Tiştê ku ez di derbarê Ceph de jê hez dikim ev e ku meriv daneya dengdanê li ser gelek dîskan belav dike da ku cild bikaribe ji ya ku dikare li ser dîskek yekane cîhê dîskê bi kar bîne. Rehet e. Taybetmendiyek din a xweş ev e ku gava ku hûn dîskan li komekê zêde dikin, ew bixweber daneyan li hemî dîskan ji nû ve belav dike.
Ceph wêneyan hene, lê bi qasî ku ez dizanim, ew rasterast di Rook / Kubernetes de nayên bikar anîn. Rast e, ez di vê yekê de kûr neçûm. Lê paşvekişandina derveyî malperê tune, ji ber vê yekê hûn neçar in ku bi Velero/Restic re tiştek bikar bînin, lê tenê paşvekêşên asta pelê hene, ne dîmenên xal-di-demê. Tiştê ku min di derbarê Rook de pir jê hez kir ev bû ku ew çiqas hêsan e ku bi Ceph re bixebite - ew hema hema hemî tiştên tevlihev vedişêre û amûran pêşkêşî dike ku rasterast bi Ceph re ji bo çareserkirina pirsgirêkan biaxive. Mixabin, di dema ceribandina stresê ya cildên Ceph de, min pirsgirêkên xwe berdewam kirin , ku dibe sedem ku Ceph bêîstîkrar bibe. Hîn ne diyar e ka ev xeletiyek di Ceph bixwe de ye an pirsgirêkek di awayê ku Rook Ceph birêve dibe de ye. Min bi mîhengên bîranînê vekir, û ew çêtir bû, lê pirsgirêk bi tevahî nehat çareser kirin. Ceph xwedan performansa maqûl e, wekî ku hûn dikarin di pîvanên jêrîn de bibînin. Di heman demê de dashboardek baş jî heye.
Ez bi rastî ji Longhorn hez dikim. Li gorî min, ev çareseriyek hêvîdar e. Rast e, pêşdebiran bixwe (Rancher Labs) qebûl dikin ku ew hîn ji bo hawîrdora xebatê ne maqûl e, û ev nîşan dide. Ew çavkaniyek vekirî ye û xwedan performansa maqûl e (her çend wan hîna ew xweştir nekirine), lê cild ji bo girêdana bi podê re demek pir dirêj digire, û di rewşên herî xirab de ew 15-16 hûrdem digire, nemaze piştî vegerandina paşgirek mezin an nûvekirina barê xebatê. Wê wêne û paşvekêşên derveyî yên van wêneyan hene, lê ew tenê li cildan têne sepandin, ji ber vê yekê hûn ê hîn jî hewceyê tiştek mîna Velero bin ku hûn çavkaniyên din paşve bikin. Vegerandin û vegerandin pir pêbawer in, lê bi rengekî nebaş hêdî hêdî. Bi giranî, tenê pir hêdî hêdî. Bikaranîna CPU û barkirina pergalê bi gelemperî dema ku li Longhorn bi mîqdarek navîn a daneyê re dixebitin zêde dibe. Ji bo birêvebirina Longhorn tabloyek hêsan heye. Min berê jî got ku ez ji Longhorn hez dikim, lê ew hewceyê hin xebatê ye.
StorageOS yekem hilbera drav di navnîşê de ye. Ew guhertoyek pêşdebir heye ku bi mezinahiya hilanînê ya bi sînorkirî ya 500 GB ve hatî rêve kirin, lê ez nafikirim ku di hejmara girêkan de sînorek hebe. Daîreya firotanê ji min re got ku lêçûn ji bo 125 TB mehê ji 1 $ dest pê dike, heke ez rast bi bîr bînim. Tabloyek bingehîn û CLI-yek hêsan heye, lê tiştek ecêb bi performansê re diqewime: di hin pîvanan de ew pir maqûl e, lê di testa stresê ya voltê de min qet ji lezê hez nekir. Bi gelemperî, ez nizanim çi bêjim. Ji ber vê yekê min pir zêde fêm nekir. Li vir paşvekêşên derveyî malperê tune ne û hûn ê di heman demê de neçar in ku Velero bi Restic re bikar bînin da ku cildên hilanînê. Ew xerîb e, ji ber ku hilber tê dayîn. Û pêşdebiran ne dilxwaz bûn ku li ser Slack ragihînin.
Ez li ser Robin li ser Reddit ji derhênerê teknîkî wan fêr bûm. Min berê qet li ser wî nebihîstibû. Dibe ku ji ber ku ez li çareseriyên belaş digeriyam, lê Robin tê dayîn. Ew bi 10TB hilanînê û sê nod ve guhertoyek belaş a xweş bi comerdî hene. Bi tevahî, hilber pir maqûl e û taybetmendiyên xweş hene. CLI-yek mezin heye, lê ya herî xweş ev e ku hûn dikarin hemî serîlêdanê wênekêş bikin û paşgir bikin (di hilbijêra çavkaniyê de jê re tê gotin berdanên Helm an "sepanên flex"), tevî cild û çavkaniyên din, ji ber vê yekê hûn dikarin bêyî Velero bikin. Û heke ne ji bo yek hûrguliyek piçûk be, her tişt dê ecêb be: heke hûn serîlêdanek li ser komikek nû sererast bikin (an "inport", wekî ku di Robin de tê gotin) - mînakî, di bûyera başbûna ji karesatekê de - vesazkirin, bê guman, dixebite, lê berdewamkirina paşvekirina serîlêdanê qedexe ye. Ev di vê serbestberdanê de bi tenê ne mumkin e, wekî ku pêşdebiran piştrast kirine. Ev, bi hûrgulî, xerîb e, nemaze ku avantajên din bihesibîne (mînakî, paşvekêşandin û sererastkirina pir bilez). Pêşdebir soz didin ku heya berdana paşîn her tiştî rast bikin. Performans bi gelemperî baş e, lê min bala xwe da xerîbiyek: heke ez pîvanê rasterast li ser cildek ku bi mêvandarê ve girêdayî ye bimeşînim, leza xwendinê ji meşandina heman dengî ji hundurê podê pir zûtir e. Hemî encamên din yek in, lê di teoriyê de divê cûdahî tune be. Her çend ew li ser wê dixebitin, ez ji pirsgirêka sererastkirin û paşvekişandinê aciz bûm - min difikirî ku min di dawiyê de çareseriyek maqûl dîtiye, û tewra ez amade bûm ku ji bo wê bidim gava ku ez hewceyê cîhek zêdetir an serverek bêtir hewce bikim.
Li vir zêde tişt nîne ku ez bibêjim. Ev hilberek dravê ye, bi heman rengî xweş û biha ye. Performansa bi tenê ecêb e. Ev nîşana herî baş e heya niha. Slack ji min re got ku biha bi mehê 205 $ ji her nodê dest pê dike, wekî ku di Bazara GKE ya Google de hatî navnîş kirin. Ez nizanim eger hûn rasterast bikirin dê erzantir be. Digel vê yekê ez nikarim wiya bikirim, ji ber vê yekê ez pir, pir xemgîn bûm ku lîsansa pêşdebir (heta 1 TB û 3 nod) bi Kubernetes re bi pratîkî bêkêr e heya ku hûn bi dabînkirina statîk razî nebin. Min hêvî dikir ku di dawiya heyama ceribandinê de lîsansa dengdanê bixweber ji pêşdebiran re dakêşe, lê ew nebû. Lîsansa pêşdebir tenê rasterast bi Docker re dikare were bikar anîn, û veavakirina li Kubernetes pir bikêr û sînordar e. Bê guman, ez çavkaniya vekirî tercîh dikim, lê ger min drav hebûya, ez ê bê guman Portworx hilbijêrin. Heya nuha, performansa wê tenê bi vebijarkên din re nayê berhev kirin.
Min ev beş piştî weşandina postê zêde kir, dema ku xwendevanek pêşniyar kir ku Linstor biceribînim. Min ew ceriband û jê hez kir! Lê divê ez hinekî din bikolim. Ji bo niha, ez dikarim bibêjim ku performans pir baş e (min encamên benchmarkê li jêr zêde kirine). Bi rastî, min heman performans wekî bi benchmarka dîska rasterast bi dest xist, bêyî ku sergiraniyek hebe. (Nepirsin çima hejmarên Portworx ji benchmarka dîska rasterast çêtir in. Ez nizanim. Sihirbazî, ez texmîn dikim.) Ji ber vê yekê, Linstor heta niha pir bi bandor xuya dike. Sazkirina wê ne pir dijwar e, lê ew ne bi qasî vebijarkên din hêsan e. Pêşî, min neçar ma ku Linstor (modula kernel û amûr/xizmet) saz bikim û LVM ji bo dabînkirina zirav û piştgiriya wênekêşanê li derveyî Kubernetes, rasterast li ser mêvandar saz bikim, û dûv re çavkaniyên pêwîst ji bo karanîna hilanînê ji Kubernetes biafirînim. Ez kêfxweş nebûm ku ew li ser nexebitî. CentOS û ew mecbûr bû ku bikar bîne UbuntuBê guman ne tiştekî mezin e, lê hinekî acizker e ji ber ku belgekirin (ku bi awayê pir baş e) behsa çend pakêtan dike ku di depoyên Epel ên diyarkirî de tune ne. Linstor wêneyên demkî hene, lê kopiyên hilanînê yên derveyî malperê tune ne, ji ber vê yekê min neçar ma ku dîsa Velero bi Restic re ji bo kopiyên hilanînê yên bi volûm bikar bînim. Ez ê wêneyên demkî li ser kopiyên hilanînê yên asta pelan tercîh bikim, lê heke çareserî performans û pêbawer be ev yek tê tehmûlkirin. Linstor çavkaniya vekirî ye, lê piştgiriya dravî heye. Ger ez rast fêm bikim, hûn dikarin wê bê sînorkirin bikar bînin her çend peymana piştgiriyê ya we tune be jî, lê divê ez wê kontrol bikim. Ez nizanim Linstor çiqas ji bo Kubernetes hatiye ceribandin, lê qata hilanînê bi xwe li derveyî Kubernetes e, û xuya dike ku ew demek dirêj e heye, ji ber vê yekê dibe ku ew berê di şert û mercên cîhana rastîn de hatiye ceribandin. Ma li vir çareseriyek heye ku dê min biguhezîne û vegerim Kubernetes? Ez nizanim. Pêdivî ye ez hinekî din lê bikolim û li ser dubarekirinê fêr bibim. Em ê bibînin. Lê bandora yekem baş e. Ji bo bêtir azadî û fêrbûna tiştên nû, bê guman ez tercîh dikim ku komên xwe yên Kubernetes li şûna Heroku bikar bînim. Ji ber ku sazkirina Linstor ne wekî yên din hêsan e, ez ê di demek nêzîk de postek li ser vê yekê binivîsim.
Benchmarks
Mixabin, min di derbarê berhevdanê de gelek têbînî negirtin ji ber ku min nedifikirî ku ez li ser binivîsim. Encamên min tenê ji pîvanên fio-ya bingehîn hene û tenê ji bo komikên girêk yekane, ji ber vê yekê hêj hejmarên min ji bo veavakirinên dubarekirî tune ne. Lê ji van encaman hûn dikarin ramanek berbiçav bistînin ka meriv ji her vebijarkê çi hêvî dike, ji ber ku min wan li ser heman serverên ewr, 4 core, 16 GB RAM, bi dîskek 100 GB ya zêde ji bo cildên ceribandinê berhev kir. Min ji bo her çareseriyê sê caran pîvanan gerand û encama navîn hesap kir, plus min mîhengên serverê ji bo her hilberek ji nû ve vekir. Ev hemî bi tevahî nezanistî ye, tenê ji bo ku hûn ramanek gelemperî bidin. Di ceribandinên din de, min 38 GB wêne û vîdyoyên ji cildê kopî kir û xwendin û nivîsandinê ceriband, lê, mixabin, min hejmar xilas nekir. Bi kurtasî: Portworkx pir zûtir bû.
Ji bo pîvana volumê min ev eşkere bikar anî:
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: dbench
spec:
storageClassName: ...
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
---
apiVersion: batch/v1
kind: Job
metadata:
name: dbench
spec:
template:
spec:
containers:
- name: dbench
image: sotoaster/dbench:latest
imagePullPolicy: IfNotPresent
env:
- name: DBENCH_MOUNTPOINT
value: /data
- name: FIO_SIZE
value: 1G
volumeMounts:
- name: dbench-pv
mountPath: /data
restartPolicy: Never
volumes:
- name: dbench-pv
persistentVolumeClaim:
claimName: dbench
backoffLimit: 4Min pêşî bi çîna hilanînê ya guncav cildek çêkir û dûv re bi fio li pişt perdeyê kar kir. Min 1 GB girt ku performansê texmîn bikim û pir dirêj nekim. Li vir encam hene:
Min nirxa çêtirîn ji bo her metrîkê bi kesk û ya herî xirab bi sor ronî kiriye.
encamê
Wekî ku hûn dikarin bibînin, di pir rewşan de Portworx ji yên din çêtir kir. Lê ji bo min biha ye. Ez nizanim Robin çiqas mesref dike, lê wan guhertoyek belaş a hêja heye, ji ber vê yekê heke hûn hilberek drav dixwazin, hûn dikarin wê biceribînin (hêvîdarim ku ew di demek nêzîk de pirsgirêkê bi sererastkirin û paşvekişandinê çareser bikin). Ji sê belaşên belaş, min bi OpenEBS-ê re pirsgirêkên herî kêm hebûn, lê performansa wê nebaş e. Heyf e ku min bêtir encam xilas nekir, lê ez hêvî dikim ku hejmar û şîroveyên min ji we re bibin alîkar.
Source: www.habr.com
