Nadgradnja!. V komentarjih je eden od bralcev predlagal poskus (morda sam dela na tem), zato sem dodal razdelek o tej rešitvi. sem tudi napisal , ker se postopek zelo razlikuje od ostalih.
Če sem iskren, sem obupal in obupal (vsaj za zdaj). bom uporabil . Zakaj? Zaradi skladiščenja! Kdo bi si mislil, da se bom bolj ukvarjal s shranjevanjem kot s samim Kubernetesom. jaz uporabljam ker je poceni in je zmogljivost dobra in že od samega začetka uporabljam gruče z uporabo . Nisem preizkusil upravljanih storitev Kubernetes iz Googla/Amazona/Microsofta/DigitalOceana itd. itd., ker sem se vsega želel naučiti sam. Sem tudi varčna.
Tako da, ko sem ocenjeval možen sklad Kubernetes, sem porabil veliko časa za odločanje, katero shrambo izbrati. Raje imam odprtokodne rešitve, ne le zaradi cene, ampak sem iz radovednosti preučil nekaj plačljivih možnosti, ker imajo brezplačne različice z omejitvami. Zapisal sem nekaj številk iz nedavnih testov, ko sem primerjal različne možnosti, in morda bodo zanimive za tiste, ki se učijo o shranjevanju Kubernetes. Čeprav sem se osebno od Kubernetesa za zdaj poslovil. Prav tako želim omeniti , ki lahko neposredno zagotovi nosilce Hetzner Cloud, vendar ga še nisem preizkusil. Preučil sem programsko definirano shranjevanje v oblaku, ker sem potreboval replikacijo in možnost hitrega priklopa trajnih nosilcev na katero koli vozlišče, zlasti v primeru okvar vozlišča in drugih podobnih situacij. Nekatere rešitve ponujajo trenutne posnetke in varnostne kopije zunaj spletnega mesta, kar je priročno.
Preizkusil sem 6-7 rešitev za shranjevanje:
Kot sem že rekel Ko sem preizkusil večino možnosti s seznama, sem se najprej odločil za OpenEBS. OpenEBS je zelo enostaven za namestitev in uporabo, a če sem iskren, sem bil po testiranju z resničnimi podatki pod obremenitvijo razočaran nad njegovo zmogljivostjo. To je odprta koda in razvijalci so sami vedno v veliko pomoč, ko sem potreboval pomoč. Na žalost ima zelo slabo zmogljivost v primerjavi z drugimi možnostmi, zato je bilo treba teste ponoviti. OpenEBS ima trenutno 3 mehanizme za shranjevanje, vendar objavljam primerjalne rezultate za cStor. Za Jiva in LocalPV še nimam številk.
Na kratko, Jiva je nekoliko hitrejša, LocalPV pa je na splošno hiter, nič slabši od neposrednega merila diska. Težava z LocalPV je, da je do nosilca mogoče dostopati samo na vozlišču, kjer je bil pripravljen, podvajanja pa sploh ni. Imel sem nekaj težav pri obnavljanju varnostne kopije prek v novi gruči, ker so bila imena vozlišč drugačna. Če govorimo o varnostnih kopijah, jih ima cStor , s katerim lahko naredite varnostne kopije posnetkov zunaj mesta v določenem trenutku, kar je bolj priročno kot varnostno kopiranje na ravni datoteke z Velero-Restic. napisal sem , da olajšate upravljanje varnostnih kopij in obnovitev s tem vtičnikom. Na splošno mi je zelo všeč OpenEBS, vendar njegova zmogljivost ...
Rook je prav tako odprtokoden in se od ostalih možnosti na seznamu razlikuje po tem, da je orkestrator shranjevanja, ki izvaja zapletene naloge upravljanja shranjevanja z različnimi zaledji, npr. , in drugi, kar zelo poenostavi delo. Pred nekaj meseci sem imel težave z EfgeFS, ko sem ga preizkusil, zato sem testiral predvsem s Cephom. Ceph ne ponuja le blokovnega shranjevanja, temveč tudi objektno shranjevanje, združljivo s S3/Swift in porazdeljenim datotečnim sistemom. Kar mi je všeč pri Cephu, je zmožnost širjenja podatkov o nosilcu na več diskih, tako da lahko nosilec porabi več prostora na disku, kot ga je mogoče namestiti na en sam disk. Udobno je. Druga kul funkcija je, da ko dodate diske v gručo, ta samodejno prerazporedi podatke po vseh diskih.
Ceph ima posnetke, vendar kolikor vem, jih ni mogoče uporabiti neposredno v Rook/Kubernetes. Res je, nisem šel globoko v to. Vendar ni varnostnih kopij zunaj spletnega mesta, zato boste morali uporabiti nekaj z Velero/Restic, vendar obstajajo samo varnostne kopije na ravni datoteke, ne pa trenutnih posnetkov. Pri Rooku mi je bilo zelo všeč, kako enostavno je delati s Cephom - skrije skoraj vse zapletene stvari in ponuja orodja za neposreden pogovor s Cephom za odpravljanje težav. Na žalost sem imel med stresnim testom količin Ceph še naprej težave , zaradi česar Ceph postane nestabilen. Ni še jasno, ali je to napaka v samem Cephu ali težava v načinu, kako Rook upravlja Ceph. Poigraval sem se z nastavitvami pomnilnika in bilo je bolje, vendar težava ni bila popolnoma rešena. Ceph ima dostojno zmogljivost, kot lahko vidite v spodnjih merilih. Ima tudi dobro armaturno ploščo.
Res mi je všeč Longhorn. Po mojem mnenju je to obetavna rešitev. Res je, razvijalci sami (Rancher Labs) priznavajo, da še ni primeren za delovno okolje, in to se kaže. Je odprtokoden in ima spodobno delovanje (čeprav ga še niso optimizirali), vendar se nosilci zelo dolgo povežejo s podom, v najslabšem primeru pa traja 15-16 minut, še posebej po obnovitvi velike varnostne kopije oz. nadgradnjo delovne obremenitve. Ima posnetke in varnostne kopije teh posnetkov zunaj spletnega mesta, vendar veljajo samo za nosilce, zato boste za varnostno kopiranje drugih virov še vedno potrebovali nekaj podobnega Velero. Varnostne kopije in obnovitve so zelo zanesljive, a nespodobno počasne. Resno, samo neverjetno počasi. Uporaba procesorja in obremenitev sistema se pogosto povečata pri delu s srednjo količino podatkov v Longhornu. Na voljo je priročna nadzorna plošča za upravljanje Longhorna. Rekel sem že, da mi je všeč Longhorn, vendar ga je treba še malo dodelati.
StorageOS je prvi plačan izdelek na seznamu. Ima različico za razvijalce z omejeno upravljano velikostjo pomnilnika 500 GB, vendar menim, da ni omejitve glede števila vozlišč. Prodajni oddelek mi je povedal, da se cena začne pri 125 USD na mesec za 1 TB, če se prav spomnim. Obstaja osnovna armaturna plošča in priročen CLI, vendar se nekaj čudnega dogaja z zmogljivostjo: v nekaterih merilih je precej spodobno, toda pri volumskem stresnem testu mi hitrost sploh ni bila všeč. Na splošno ne vem, kaj naj rečem. Tako da nisem prav veliko razumel. Tu ni varnostnih kopij zunaj spletnega mesta in za varnostno kopiranje nosilcev boste morali uporabiti tudi Velero z Restic. Čudno, ker je izdelek plačan. In razvijalci niso bili navdušeni nad komunikacijo o Slacku.
Za Robina sem izvedel na Redditu od njihovega tehničnega direktorja. Nikoli prej nisem slišal zanj. Mogoče zato, ker sem iskal brezplačne rešitve, a Robin je plačan. Imajo precej radodarno brezplačno različico z 10 TB prostora za shranjevanje in tremi vozlišči. Na splošno je izdelek precej spodoben in ima lepe lastnosti. Obstaja odličen CLI, najbolj kul pa je, da lahko naredite posnetek in varnostno kopijo celotne aplikacije (v izbirniku virov se to imenuje izdaje Helm ali »aplikacije flex«), vključno z nosilci in drugimi viri, tako da lahko storite brez Velera. In vse bi bilo čudovito, če ne bi bila ena majhna podrobnost: če obnovite (ali "uvozite", kot se imenuje v Robinu) aplikacijo na novi gruči - na primer v primeru okrevanja po katastrofi - obnovitev, seveda deluje, vendar je prepovedano še naprej varnostno kopirati aplikacijo. To preprosto ni mogoče v tej izdaji, kot so potrdili razvijalci. To je milo rečeno nenavadno, sploh če upoštevamo druge prednosti (denimo neverjetno hitro varnostno kopiranje in obnavljanje). Razvijalci obljubljajo, da bodo vse popravili do naslednje izdaje. Zmogljivost je na splošno dobra, vendar sem opazil nenavadnost: če zaženem merilo uspešnosti neposredno na nosilcu, ki je pritrjen na gostitelja, je hitrost branja veliko večja kot pri izvajanju istega nosilca znotraj enote. Vsi drugi rezultati so enaki, vendar v teoriji ne bi smelo biti razlik. Čeprav delajo na tem, sem bil razburjen zaradi težave z obnovitvijo in varnostnim kopiranjem - mislil sem, da sem končno našel primerno rešitev, in sem bil pripravljen celo plačati zanjo, ko sem potreboval več prostora ali več strežnikov.
Tukaj nimam veliko povedati. To je plačan izdelek, enako kul in drag. Izvedba je preprosto neverjetna. To je najboljši kazalnik do sedaj. Slack mi je povedal, da se cene začnejo pri 205 USD na mesec na vozlišče, kot je navedeno na Googlovi tržnici GKE. Ne vem, če bo ceneje, če kupiš direktno. Tega si vseeno ne morem privoščiti, zato sem bil zelo, zelo razočaran, da je licenca za razvijalce (do 1 TB in 3 vozlišča) s Kubernetesom praktično neuporabna, razen če ste zadovoljni s statično oskrbo. Upal sem, da se bo količinska licenca ob koncu preizkusnega obdobja samodejno spremenila v različico za razvijalce, vendar se to ni zgodilo. Licenco za razvijalce je mogoče uporabiti samo neposredno z Dockerjem, konfiguracija v Kubernetesu pa je zelo okorna in omejena. Seveda imam raje odprto kodo, a če bi imel denar, bi zagotovo izbral Portworx. Zaenkrat se njegova zmogljivost preprosto ne primerja z drugimi možnostmi.
Ta razdelek sem dodal po objavi objave, ko je en bralec predlagal poskus Linstorja. Poskusil sem in bilo mi je všeč! Vendar moramo še vedno kopati globlje. Zdaj lahko rečem, da zmogljivost ni slaba (spodaj sem dodal rezultate primerjalnih testov). V bistvu sem dobil enako zmogljivost kot disk neposredno, brez dodatnih stroškov. (Ne sprašujte se, zakaj ima Portworx boljše številke kot neposredno merilo pogona. Pojma nimam. Predvidevam, da je čarobno.) Torej se Linstor do zdaj zdi zelo učinkovit. Ni tako težko namestiti, vendar ni tako enostavno kot druge možnosti. Najprej sem moral namestiti Linstor (modul jedra in orodja/storitve) ter konfigurirati LVM za tanko zagotavljanje in podporo za posnetke zunaj Kubernetesa, neposredno na gostitelju, nato pa ustvariti vire, potrebne za uporabo prostora za shranjevanje iz Kubernetesa. Ni mi bilo všeč, da ni delovalo na CentOS in sem moral uporabiti Ubuntu. Seveda ni grozno, a nekoliko moteče, ker dokumentacija (ki je mimogrede odlična) omenja več paketov, ki jih ni mogoče najti v navedenih repozitorijih Epel. Linstor ima posnetke, ne pa varnostnih kopij zunaj spletnega mesta, tako da sem tukaj spet moral uporabiti Velero z Restic za varnostno kopiranje nosilcev. Raje bi imel posnetke namesto varnostnih kopij na ravni datoteke, vendar je to mogoče tolerirati, če je rešitev učinkovita in zanesljiva. Linstor je odprtokoden, vendar ima plačljivo podporo. Če prav razumem, se lahko uporablja brez omejitev, tudi če nimate podporne pogodbe, vendar je to treba pojasniti. Ne vem, koliko je Linstor preizkušen za Kubernetes, vendar je sam sloj za shranjevanje zunaj Kubernetesa in očitno se rešitev ni pojavila včeraj, tako da je verjetno že preizkušena v realnih pogojih. Ali tukaj obstaja rešitev, zaradi katere si bom premislil in se vrnil v Kubernetes? Ne vem. Še vedno moramo kopati globlje in preučiti replikacijo. Pa poglejmo. Ampak prvi vtis je dober. Vsekakor bi raje uporabil lastne gruče Kubernetes namesto Herokuja, da bi imel več svobode in se naučil novih stvari. Ker Linstor ni tako enostaven za namestitev kot drugi, bom o tem kmalu napisal objavo.
Merila uspešnosti
O primerjavi si žal nisem veliko zapisoval, ker si nisem mislil, da bom o tem pisal. Imam samo rezultate iz osnovnih meril uspešnosti fio in samo za gruče z enim vozliščem, zato še nimam številk za podvojene konfiguracije. Toda iz teh rezultatov lahko dobite približno predstavo o tem, kaj lahko pričakujete od vsake možnosti, saj sem jih primerjal na istih strežnikih v oblaku, 4 jedra, 16 GB RAM-a, z dodatnim 100 GB diskom za testirane količine. Trikrat sem izvedel merila uspešnosti za vsako rešitev in izračunal povprečni rezultat ter ponastavil nastavitve strežnika za vsak izdelek. Vse to je popolnoma neznanstveno, samo da vam dam splošno predstavo. V drugih testih sem kopiral 38 GB fotografij in videoposnetkov z nosilca, da bi preizkusil branje in pisanje, vendar, žal, številk nisem shranil. Na kratko: Portworkx je bil veliko hitrejši.
Za merilo obsega sem uporabil ta manifest:
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: 4Najprej sem ustvaril nosilec z ustreznim razredom shranjevanja in nato v zakulisju opravil delo s fio. Vzel sem 1 GB, da ocenim zmogljivost in ne čakam predolgo. Tukaj so rezultati:
Najboljšo vrednost za vsako meritev sem označil z zeleno, najslabšo pa z rdečo.
Zaključek
Kot lahko vidite, se je v večini primerov Portworx izkazal bolje kot drugi. Ampak zame je drago. Ne vem, koliko stane Robin, vendar imajo odlično brezplačno različico, tako da če želite plačan izdelek, ga lahko preizkusite (upam, da bodo kmalu odpravili težavo z obnovitvijo in varnostnimi kopijami). Od treh brezplačnih sem imel najmanj težav z OpenEBS, vendar je njegova zmogljivost klavrna. Škoda, da nisem shranil več rezultatov, vendar upam, da vam bodo številke in moji komentarji pomagali.
Vir: www.habr.com