Update!. Sa mga komento, iminungkahi ng isa sa mga mambabasa na subukan (marahil siya mismo ang gumagawa nito) kaya nagdagdag ako ng isang seksyon tungkol sa solusyon na ito. nagsulat din ako , dahil ibang-iba ang proseso sa iba.
Sa totoo lang, sumuko ako at sumuko (basta sa ngayon). gagamitin ko . Bakit? Dahil sa storage! Sinong mag-aakala na mas mag-iimbak ako kaysa sa Kubernetes mismo. gumagamit ako mura kasi at maganda ang performance at sa simula pa lang ay nagdedeploy na ako ng mga cluster gamit . Hindi ko sinubukan ang mga pinamamahalaang serbisyo ng Kubernetes mula sa Google/Amazon/Microsoft/DigitalOcean, atbp., atbp., dahil gusto kong matutunan ko ang lahat sa aking sarili. Matipid din ako.
Kaya oo, gumugol ako ng maraming oras sa pagsubok na magpasya kung aling storage ang pipiliin kapag sinusuri ko ang isang posibleng stack ng Kubernetes. Mas gusto ko ang mga open source na solusyon, hindi lamang dahil sa presyo, ngunit tumingin ako sa ilang mga bayad na opsyon dahil sa pag-usisa dahil mayroon silang mga libreng bersyon na may mga limitasyon. Nagtala ako ng ilang numero mula sa mga kamakailang pagsubok noong inihambing ko ang iba't ibang mga opsyon, at maaaring interesado ang mga ito sa mga natututo tungkol sa storage ng Kubernetes. Bagama't ako ay personal na nagpaalam sa Kubernetes sa ngayon. Gusto ko rin banggitin , na direktang makakapagbigay ng mga volume ng Hetzner Cloud, ngunit hindi ko pa ito nasubukan. Tumingin ako sa storage na tinukoy ng cloud software dahil kailangan ko ng replikasyon at kakayahang mabilis na mag-mount ng mga persistent volume sa anumang node, lalo na sa kaso ng mga pagkabigo ng node at iba pang katulad na sitwasyon. Ang ilang mga solusyon ay nag-aalok ng mga point-in-time na snapshot at off-site na backup, na maginhawa.
Sinubukan ko ang 6-7 na solusyon sa imbakan:
Tulad ng nasabi ko na Ang pagkakaroon ng pagsubok sa karamihan ng mga opsyon mula sa listahan, una akong nanirahan sa OpenEBS. Ang OpenEBS ay napakadaling i-install at gamitin, ngunit sa totoo lang, pagkatapos ng pagsubok sa totoong data sa ilalim ng pagkarga, ako ay nabigo sa pagganap nito. Ito ay open source, at ang mga developer ay nag-iisa laging nakakatulong kapag kailangan ko ng tulong. Sa kasamaang palad, ito ay may napakahinang pagganap kumpara sa iba pang mga opsyon, kaya ang mga pagsubok ay kailangang muling patakbuhin. Kasalukuyang mayroong 3 storage engine ang OpenEBS, ngunit nagpo-post ako ng mga benchmark na resulta para sa cStor. Wala pa akong mga numero para sa Jiva at LocalPV.
Sa madaling sabi, ang Jiva ay medyo mas mabilis, at ang LocalPV ay karaniwang mabilis, hindi mas masahol pa sa disk benchmark nang direkta. Ang problema sa LocalPV ay ang volume ay maa-access lamang sa node kung saan ito inihanda, at walang anumang pagtitiklop. Nagkaroon ako ng ilang problema sa pagpapanumbalik ng backup sa pamamagitan ng sa isang bagong cluster dahil magkaiba ang mga pangalan ng node. Kung pag-uusapan natin ang tungkol sa mga backup, mayroon ang cStor , kung saan maaari kang gumawa ng mga pag-backup sa labas ng site ng mga snapshot sa isang punto ng oras, na mas maginhawa kaysa sa mga backup sa antas ng file gamit ang Velero-Restic. Sinulat ko , upang gawing mas madaling pamahalaan ang mga backup at pag-restore gamit ang plugin na ito. Sa pangkalahatan, gusto ko talaga ang OpenEBS, ngunit ang pagganap nito...
Ang Rook ay open source din, at kung ano ang nagtatakda nito bukod sa iba pang mga opsyon sa listahan ay isa itong storage orchestrator na humahawak ng mga kumplikadong gawain sa pamamahala ng storage na may iba't ibang backend, hal. , at iba pa, na lubos na nagpapadali sa gawain. Nagkaroon ako ng mga problema sa EfgeFS noong sinubukan ko ito ilang buwan na ang nakakaraan, kaya sinubukan ko pangunahin sa Ceph. Hindi lamang nag-aalok ang Ceph ng block storage, kundi pati na rin ang object storage na tugma sa S3/Swift at distributed file system. Ang gusto ko kay Ceph ay ang kakayahang magpakalat ng data ng volume sa maraming disk upang ang volume ay makagamit ng mas maraming espasyo sa disk kaysa sa maaaring magkasya sa isang disk. Ito ay komportable. Ang isa pang cool na tampok ay kapag nagdagdag ka ng mga disk sa isang kumpol, awtomatiko itong muling namamahagi ng data sa lahat ng mga disk.
May mga snapshots si Ceph, pero sa pagkakaalam ko, hindi ito direktang magagamit sa Rook/Kubernetes. Totoo, hindi ako nagpalalim dito. Ngunit walang mga pag-backup sa labas ng site, kaya kailangan mong gumamit ng isang bagay sa Velero/Restic, ngunit mayroon lamang mga backup sa antas ng file, hindi mga point-in-time na snapshot. Ang talagang nagustuhan ko kay Rook ay kung gaano kadaling makipagtulungan kay Ceph - tinatago nito ang halos lahat ng kumplikadong bagay at nag-aalok ng mga tool upang direktang makausap si Ceph para sa pag-troubleshoot. Sa kasamaang palad, sa panahon ng stress test ng Ceph volume, patuloy akong nagkakaproblema , na nagiging sanhi ng pagiging unstable ni Ceph. Hindi pa malinaw kung bug ito sa mismong Ceph o problema sa paraan ng pamamahala ni Rook kay Ceph. Pinagmasdan ko ang mga setting ng memorya, at ito ay naging mas mahusay, ngunit ang problema ay hindi ganap na nalutas. Si Ceph ay may disenteng pagganap, tulad ng makikita mo sa mga benchmark sa ibaba. Mayroon din itong magandang dashboard.
Gusto ko talaga si Longhorn. Sa aking opinyon, ito ay isang promising na solusyon. Totoo, ang mga developer mismo (Rancher Labs) ay umamin na hindi pa ito angkop para sa kapaligiran ng pagtatrabaho, at ito ay nagpapakita. Ito ay bukas na mapagkukunan at may disenteng pagganap (bagaman hindi pa nila ito na-optimize), ngunit ang mga volume ay tumatagal ng napakatagal na oras upang kumonekta sa pod, at sa pinakamasamang mga kaso ito ay tumatagal ng 15-16 minuto, lalo na pagkatapos na maibalik ang isang malaking backup o pag-upgrade ng workload. Mayroon itong mga snapshot at off-site na backup ng mga snapshot na ito, ngunit nalalapat lamang ang mga ito sa mga volume, kaya kakailanganin mo pa rin ang isang bagay tulad ng Velero upang mag-backup ng iba pang mga mapagkukunan. Ang mga pag-backup at pag-restore ay lubos na maaasahan, ngunit mabagal. Seryoso, napakabagal lang. Ang paggamit ng CPU at pag-load ng system ay madalas na tumataas kapag nagtatrabaho sa katamtamang dami ng data sa Longhorn. Mayroong isang maginhawang dashboard upang pamahalaan ang Longhorn. Nasabi ko na na gusto ko ang Longhorn, ngunit kailangan nito ng ilang trabaho.
Ang StorageOS ay ang unang bayad na produkto sa listahan. Mayroon itong bersyon ng developer na may limitadong laki ng pinamamahalaang storage na 500GB, ngunit sa palagay ko ay walang limitasyon sa bilang ng mga node. Sinabi sa akin ng departamento ng pagbebenta na ang gastos ay nagsisimula sa $125 bawat buwan para sa 1 TB, kung tama ang pagkakaalala ko. Mayroong isang pangunahing dashboard at isang maginhawang CLI, ngunit may kakaibang nangyayari sa pagganap: sa ilang mga benchmark ito ay medyo disente, ngunit sa dami ng stress test ay hindi ko nagustuhan ang bilis. Sa pangkalahatan, hindi ko alam kung ano ang sasabihin. Kaya hindi ko talaga masyadong naintindihan. Walang mga pag-backup sa labas ng site dito at kakailanganin mo ring gamitin ang Velero na may Restic sa mga backup na volume. Ito ay kakaiba, dahil ang produkto ay binabayaran. At ang mga developer ay hindi sabik na makipag-usap sa Slack.
Nalaman ko ang tungkol kay Robin sa Reddit mula sa kanilang teknikal na direktor. Hindi ko pa siya narinig noon. Siguro dahil naghahanap ako ng mga libreng solusyon, ngunit binabayaran si Robin. Mayroon silang medyo mapagbigay na libreng bersyon na may 10TB na imbakan at tatlong node. Sa pangkalahatan, ang produkto ay medyo disente at may magagandang katangian. Mayroong isang mahusay na CLI, ngunit ang pinaka-cool na bagay ay na maaari mong i-snapshot at i-backup ang buong application (sa resource selector ito ay tinatawag na Helm releases o "flex apps"), kasama ang mga volume at iba pang mga mapagkukunan, para magawa mo nang wala si Velero. At ang lahat ay magiging kahanga-hanga kung hindi para sa isang maliit na detalye: kung ibabalik mo (o "pag-import", tulad ng tawag sa Robin) isang aplikasyon sa isang bagong kumpol - halimbawa, sa kaganapan ng pagbawi mula sa isang sakuna - ang pagpapanumbalik, siyempre, gumagana, ngunit patuloy na i-back up ang application na ito ay ipinagbabawal. Hindi ito posible sa release na ito, gaya ng kinumpirma ng mga developer. Ito ay, upang ilagay ito nang mahinahon, kakaiba, lalo na kung isasaalang-alang ang iba pang mga pakinabang (halimbawa, hindi kapani-paniwalang mabilis na pag-backup at pag-restore). Nangangako ang mga developer na ayusin ang lahat sa susunod na release. Sa pangkalahatan ay maganda ang performance, ngunit napansin ko ang isang kakaiba: kung direktang patakbuhin ko ang benchmark sa isang volume na naka-attach sa host, ang bilis ng pagbasa ay mas mabilis kaysa sa pagpapatakbo ng parehong volume mula sa loob ng pod. Ang lahat ng iba pang mga resulta ay magkapareho, ngunit sa teorya ay dapat walang pagkakaiba. Bagama't ginagawa nila ito, nagalit ako tungkol sa problema sa pagpapanumbalik at pag-backup - naisip ko na sa wakas ay nakahanap na ako ng angkop na solusyon, at handa pa akong bayaran ito kapag kailangan ko ng mas maraming espasyo o higit pang mga server.
Wala akong masyadong masabi dito. Ito ay isang bayad na produkto, parehong cool at mahal. Ang pagganap ay kahanga-hanga lamang. Ito ang pinakamahusay na tagapagpahiwatig sa ngayon. Sinabi sa akin ni Slack na ang pagpepresyo ay nagsisimula sa $205 bawat buwan bawat node, gaya ng nakalista sa GKE Marketplace ng Google. Hindi ko alam kung magiging mas mura kung direktang bibili ka. Hindi ko pa rin kayang bayaran iyon, kaya labis akong nadismaya na ang lisensya ng developer (hanggang 1 TB at 3 node) ay halos walang silbi sa Kubernetes maliban kung kontento ka sa static na provisioning. Umaasa ako na ang lisensya ng volume ay awtomatikong magda-downgrade sa developer sa pagtatapos ng panahon ng pagsubok, ngunit hindi iyon nangyari. Ang lisensya ng developer ay maaari lamang gamitin nang direkta sa Docker, at ang pagsasaayos sa Kubernetes ay napakahirap at limitado. Siyempre, mas gusto ko ang open source, ngunit kung mayroon akong pera, tiyak na pipiliin ko ang Portworx. Sa ngayon, ang pagganap nito ay hindi kumpara sa iba pang mga opsyon.
Idinagdag ko ang seksyong ito pagkatapos ng paglalathala ng post, nang iminungkahi ng isang mambabasa na subukan ang Linstor. Sinubukan ko ito at nagustuhan ko ito! Ngunit kailangan pa rin nating maghukay ng mas malalim. Ngayon ay maaari kong sabihin na ang pagganap ay hindi masama (idinagdag ko ang mga resulta ng benchmark sa ibaba). Mahalaga, nakuha ko ang parehong pagganap bilang ang disk nang direkta, nang walang anumang overhead. (Huwag magtanong kung bakit ang Portworx ay may mas mahusay na mga numero kaysa sa drive benchmark nang direkta. Wala akong ideya. Magic, sa palagay ko.) Kaya ang Linstor ay tila napaka-epektibo sa ngayon. Hindi ganoon kahirap i-install, ngunit hindi ito kasingdali ng iba pang mga opsyon. Una, kinailangan kong i-install ang Linstor (kernel module at mga tool/serbisyo) at i-configure ang LVM para sa manipis na provisioning at snapshot na suporta sa labas ng Kubernetes, nang direkta sa host, at pagkatapos ay lumikha ng mga mapagkukunang kailangan para magamit ang storage mula sa Kubernetes. Hindi ko nagustuhan na hindi ito gumana sa CentOS at kailangan kong gumamit ng Ubuntu. Hindi kakila-kilabot, siyempre, ngunit medyo nakakainis, dahil ang dokumentasyon (na kung saan ay mahusay, sa pamamagitan ng paraan) ay nagbabanggit ng ilang mga pakete na hindi matatagpuan sa tinukoy na mga repositoryo ng Epel. Ang Linstor ay may mga snapshot, ngunit hindi off-site na pag-backup, kaya narito muli kailangan kong gumamit ng Velero na may Restic upang mag-backup ng mga volume. Mas gugustuhin ko ang mga snapshot sa halip na mga pag-backup sa antas ng file, ngunit maaari itong tiisin kung ang solusyon ay gumaganap at maaasahan. Ang Linstor ay open source ngunit may bayad na suporta. Kung naiintindihan ko nang tama, maaari itong gamitin nang walang mga paghihigpit, kahit na wala kang kontrata sa suporta, ngunit ito ay kailangang linawin. Hindi ko alam kung gaano nasubok ang Linstor para sa Kubernetes, ngunit ang storage layer mismo ay nasa labas ng Kubernetes at, tila, ang solusyon ay hindi lumabas kahapon, kaya malamang na nasubok na ito sa totoong mga kondisyon. Mayroon bang solusyon dito na magpapabago sa isip ko at babalik sa Kubernetes? Hindi ko alam. Kailangan pa nating maghukay ng mas malalim at pag-aralan ang replikasyon. Tingnan natin. Pero maganda ang first impression. Mas gugustuhin kong gamitin ang sarili kong mga Kubernetes cluster sa halip na Heroku para magkaroon ng higit na kalayaan at matuto ng mga bagong bagay. Dahil ang Linstor ay hindi kasing dali ng iba, magsusulat ako ng post tungkol dito sa lalong madaling panahon.
Mga benchmark
Sa kasamaang palad, hindi ako nagtago ng maraming tala tungkol sa paghahambing dahil hindi ko naisip na isusulat ko ito. Mayroon lang akong mga resulta mula sa mga pangunahing benchmark ng fio at para lamang sa mga solong node cluster, kaya wala pa akong mga numero para sa mga kino-reply na configuration. Ngunit mula sa mga resultang ito maaari kang makakuha ng isang magaspang na ideya kung ano ang aasahan mula sa bawat pagpipilian, dahil inihambing ko ang mga ito sa parehong mga server ng ulap, 4 na mga core, 16 GB ng RAM, na may karagdagang 100 GB na disk para sa nasubok na mga volume. Pinatakbo ko ang mga benchmark nang tatlong beses para sa bawat solusyon at kinakalkula ang average na resulta, at ni-reset ko ang mga setting ng server para sa bawat produkto. Ang lahat ng ito ay ganap na hindi makaagham, para lamang mabigyan ka ng pangkalahatang ideya. Sa iba pang mga pagsubok, kinopya ko ang 38 GB ng mga larawan at video mula sa volume upang subukan ang pagbabasa at pagsulat, ngunit, sayang, hindi ko nai-save ang mga numero. Sa madaling salita: Ang Portworkx ay mas mabilis.
Para sa benchmark ng volume na ginamit ko ang manifest na ito:
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: 4Gumawa muna ako ng volume na may naaangkop na klase ng storage at pagkatapos ay pinatakbo ko ang trabaho kasama ang fio behind the scenes. Kumuha ako ng 1 GB para tantiyahin ang performance at hindi maghintay ng masyadong mahaba. Narito ang mga resulta:
Na-highlight ko ang pinakamahusay na halaga para sa bawat sukatan sa berde at ang pinakamasama sa pula.
Konklusyon
Tulad ng nakikita mo, sa karamihan ng mga kaso, gumanap nang mas mahusay ang Portworx kaysa sa iba. Pero para sa akin mahal. Hindi ko alam kung magkano ang halaga ng Robin, ngunit mayroon silang isang mahusay na libreng bersyon, kaya kung gusto mo ng isang bayad na produkto, maaari mong subukan ito (sana ay maayos nila ang problema sa pagpapanumbalik at pag-backup sa lalong madaling panahon). Sa tatlong libre, mayroon akong pinakamaliit na problema sa OpenEBS, ngunit ang pagganap nito ay hindi maganda. Sayang at hindi na ako nakapag-save ng mas maraming resulta, ngunit sana ay makatulong sa iyo ang mga numero at ang aking mga komento.
Pinagmulan: www.habr.com