Aktualizace!. V komentářích jeden ze čtenářů navrhl vyzkoušet (možná na tom sám pracuje), tak jsem přidal část o tomto řešení. Taky jsem psal protože proces je velmi odlišný od ostatních.
Abych byl upřímný, vzdal jsem to a vzdal jsem to (prozatím). použiji . Proč? Kvůli skladování! Kdo by to byl řekl, že se s úložištěm budu makat víc než se samotným Kubernetesem. používám , protože je to levné a výkon je dobrý, a od samého začátku jsem nasadil clustery s . Kubernetes spravované služby od Google/Amazon/Microsoft/DigitalOcean atd. atd. jsem nezkoušel, protože jsem se chtěl všechno naučit sám. Taky jsem spořivý.
Takže - ano, strávil jsem spoustu času rozhodováním, které úložiště vybrat, když jsem zvažoval možný stack na Kubernetes. Preferuji open source řešení a nejen kvůli ceně, ale podíval jsem se na pár placených variant ze zvědavosti, protože mají bezplatné verze s omezením. Zapsal jsem si několik čísel z nedávných benchmarků, když jsem porovnával různé možnosti, a mohou být zajímavá pro ty, kteří studují úložiště v Kubernetes. I když osobně jsem se s Kubernetes zatím rozloučil. Chci se také zmínit , ve kterém můžete přímo poskytovat svazky Hetzner Cloud, ale zatím jsem to nezkoušel. Hledal jsem cloudové softwarově definované úložiště, protože jsem potřeboval replikaci a možnost rychle připojit trvalé svazky na jakýkoli uzel, zejména v případě selhání uzlů a dalších podobných situací. Některá řešení nabízejí snímky k určitému okamžiku a zálohy mimo pracoviště, což je praktické.
Testoval jsem 6-7 úložných řešení:
Jak jsem již řekl , po otestování většiny možností ze seznamu jsem se původně rozhodl pro OpenEBS. OpenEBS se velmi snadno instaluje a používá, ale abych byl upřímný, po testování s reálnými daty v zátěži mě jeho výkon zklamal. Toto je open source a vývojáři jsou na to sami vždy velmi užitečné, když jsem potřeboval pomoc. Bohužel má ve srovnání s jinými možnostmi velmi špatný výkon, takže jsem musel testy spustit znovu. Právě teď má OpenEBS 3 storage engine, ale posílám výsledky benchmarků pro cStor. Zatím nemám čísla pro Jiva a LocalPV.
Stručně řečeno, Jiva je o něco rychlejší a LocalPV je obecně rychlý, o nic horší než přímo benchmark disku. Problém s LocalPV je v tom, že ke svazku lze přistupovat pouze v uzlu, kde byl zřízen, a nedochází k žádné replikaci. Měl jsem nějaké problémy s obnovením zálohy přes na novém clusteru, protože názvy uzlů byly odlišné. Když už mluvíme o zálohách, cStor má , pomocí kterého můžete provádět zálohy snímků k určitému bodu v čase mimo pracoviště, což je pohodlnější než zálohování na úrovni souborů s Velero-Restic. napsal jsem pro snazší správu záloh a obnovení pomocí tohoto pluginu. Celkově se mi OpenEBS opravdu líbí, ale jeho výkon...
Rook je také open source a liší se od ostatních možností v seznamu tím, že jde o orchestrátor úložiště, který provádí složité úlohy správy úložiště s různými backendy, například , a další, což značně zjednodušuje práci. Měl jsem problémy s EfgeFS, když jsem ho před pár měsíci zkoušel, takže jsem testoval hlavně s Cephem. Ceph nabízí nejen blokové úložiště, ale také objektové úložiště kompatibilní s S3/Swift a distribuovaným souborovým systémem. Na Cephu se mi líbí možnost rozložit data svazku na více disků, takže svazek může zabírat více místa na disku, než se vejde na jeden disk. Je to pohodlné. Další skvělou funkcí je, že když do clusteru přidáte disky, automaticky se přerozdělí data na všechny disky.
Ceph má snapshoty, ale pokud vím, nedají se použít přímo v Rook/Kubernetes. Přiznám se, že jsem se v tom nehrabal. Neexistují však žádné zálohy mimo web, takže musíte použít něco s Velero / Restic, ale existují pouze zálohy na úrovni souborů, nikoli snímky v určitém okamžiku. Co se mi však na Rooku opravdu líbí, je snadnost práce s Cephem – skrývá téměř všechny složité věci a nabízí nástroje, jak mluvit přímo s Cephem za účelem řešení problémů. Bohužel na zátěžový test objemů Ceph jsem měl vždy , což způsobuje, že se Ceph stává nestabilním. Zatím není jasné, zda se jedná o chybu v Cephu samotném, nebo o problém v tom, jak Rook Ceph spravuje. Hrál jsem s nastavením paměti a zlepšilo se to, ale problém nebyl úplně vyřešen. Ceph má dobrý výkon, jak je vidět v níže uvedených benchmarcích. Má také dobrou palubní desku.
Longhorn se mi moc líbí. Myslím, že je to slibné řešení. Pravda, sami vývojáři (Rancher Labs) přiznávají, že to zatím není vhodné pro produkční prostředí, a to je vidět. Je to open source a má slušný výkon (i když to ještě neoptimalizovali), ale svazky se k podu připojují velmi dlouho a v nejhorších případech to trvá 15-16 minut, zvláště po obnovení velké zálohy nebo upgradu zátěže. Má snímky a off-site zálohy těchto snímků, ale vztahují se pouze na svazky, takže k zálohování zbytku prostředků stále potřebujete něco jako Velero. Zálohování a obnova jsou velmi spolehlivé, ale neslušně pomalé. Vážně, jen neúměrně pomalu. Při práci s průměrným množstvím dat v Longhornu často stoupá využití procesoru a zatížení systému. K dispozici je praktický přístrojový panel pro správu Longhornu. Už jsem říkal, že mám Longhorn rád, ale je potřeba na něm pořádně zapracovat.
StorageOS je prvním placeným produktem na seznamu. Má vývojářskou verzi s omezenou velikostí spravovaného úložiště 500 GB, ale nemyslím si, že existuje omezení počtu uzlů. Obchodní oddělení mi řeklo, že cena začíná na 125 $ měsíčně za 1 TB, pokud si dobře pamatuji. Je tu základní přístrojová deska a šikovné CLI, ale s výkonem se děje něco zvláštního: v některých benchmarcích je docela slušný, ale v zátěžovém testu objemů se mi rychlost vůbec nelíbila. Obecně nevím, co říct. Tak to jsem fakt nepochopil. Neexistují zde žádné zálohy mimo místo a k zálohování svazků budete muset také použít Velero s Restic. Je to zvláštní, protože produkt je placený. A vývojáři nebyli dychtiví komunikovat ve Slacku.
O Robinovi jsem se dozvěděl na Redditu od jejich CTO. Nikdy předtím jsem o něm neslyšel. Možná proto, že jsem hledal řešení zdarma a Robin je placený. Mají docela velkorysou bezplatnou verzi s 10 TB úložiště a třemi uzly. Obecně je produkt docela slušný a s pěknými vlastnostmi. Je tu skvělé CLI, ale nejlepší na tom je, že můžete pořídit snímek a zálohovat celou aplikaci (nazývanou Helm releases nebo „flex apps“ ve výběru prostředků), včetně svazků a dalších zdrojů, takže se obejdete bez Velero. A všechno by bylo úžasné, kdyby to nebylo pro jeden malý detail: pokud obnovíte (nebo „importujete“, jak se tomu říká v Robinovi) aplikaci na novém clusteru – například v případě obnovy po havárii – obnova samozřejmě funguje, ale nemůžete pokračovat v zálohování aplikace. V tomto vydání to prostě není možné a vývojáři to potvrdili. To je přinejmenším zvláštní, zvláště když vezmete v úvahu další výhody (například neuvěřitelně rychlé zálohy a obnovy). Vývojáři slibují, že vše napraví do příštího vydání. Výkon je obecně dobrý, ale všiml jsem si zvláštní věci: pokud spustíte benchmark přímo na svazku připojeném k hostiteli, rychlost čtení je mnohem vyšší než u stejného svazku, ale zevnitř pod. Všechny ostatní výsledky jsou identické, ale teoreticky by mezi nimi neměl být žádný rozdíl. Přestože na tom pracují, byl jsem frustrovaný problémem s obnovou a zálohováním - zdálo se mi, že jsem konečně našel vhodné řešení a byl jsem dokonce připraven za něj zaplatit, když jsem potřeboval více místa nebo více serverů.
Tady nemám moc co říct. Jedná se o placený produkt, stejně skvělý a drahý. Výkon je prostě úžasný. Zatím je to nejlepší ukazatel. Slack mi řekl, že ceny začínají na 205 USD za měsíc za uzel, jak je uvedeno na GKE Marketplace společnosti Google. Nevím, jestli to bude levnější, když koupíte přímo. V žádném případě si to nemohu dovolit, takže jsem byl velmi, velmi zklamán, že vývojářská licence (až 1TB a 3 nody) je u Kubernetes prakticky k ničemu, pokud se nespokojíte se statickým zřizováním. Doufal jsem, že multilicence na konci zkušebního období automaticky přejde na nižší verzi na vývojáře, ale to se nestalo. Vývojářskou licenci lze použít pouze přímo s Dockerem a nastavení v Kubernetes je velmi těžkopádné a omezené. Samozřejmě preferuji open source, ale kdybych měl peníze, určitě bych zvolil Portworx. Zatím se jeho výkon prostě nevyrovná jiným možnostem.
Tuto sekci jsem přidal po zveřejnění příspěvku, když mi jeden čtenář navrhl vyzkoušet Linstor. Vyzkoušel jsem ho a líbil se mi! Ale musím se do toho víc ponořit. Prozatím mohu říct, že výkon je docela dobrý (níže jsem přidal výsledky benchmarku). Ve skutečnosti jsem dosáhl stejného výkonu jako u benchmarku s přímým diskem, bez jakékoli režie. (Neptejte se, proč jsou čísla Portworxu lepší než u benchmarku s přímým diskem. Nemám tušení. Asi je to nějaká magie.) Takže Linstor se zatím zdá být velmi efektivní. Jeho nastavení není zrovna složité, ale není to tak snadné jako jiné možnosti. Nejdříve jsem musel nainstalovat Linstor (modul jádra a nástroje/služby) a nastavit LVM pro thin provisioning a podporu snapshotů mimo Kubernetes, přímo na hostiteli, a poté vytvořit prostředky potřebné k použití úložiště z Kubernetes. Nebyl jsem spokojený, že to nefungovalo na... CentOS a musel použít UbuntuNení to samozřejmě velký problém, ale je to trochu otravné, protože dokumentace (mimochodem vynikající) zmiňuje několik balíčků, které nejsou dostupné v uvedených repozitářích Epel. Linstor má snapshoty, ale žádné zálohy mimo web, takže jsem pro zálohy svazků musel znovu použít Velero s Resticem. Preferoval bych snapshoty před zálohami na úrovni souborů, ale to je snesitelné, pokud je řešení výkonné a spolehlivé. Linstor je open source, ale existuje placená podpora. Pokud tomu správně rozumím, můžete ho používat bez omezení, i když nemáte smlouvu o podpoře, ale to bych si musel ověřit. Nevím, jak je Linstor testovaný pro Kubernetes, ale samotná úložná vrstva je mimo Kubernetes a vypadá to, že už nějakou dobu existuje, takže pravděpodobně už byla testována v reálných podmínkách. Existuje zde nějaké řešení, které by mě přimělo změnit názor a přejít zpět na Kubernetes? Nevím. Musím se v tom trochu víc pohrabat a naučit se něco o replikaci. Uvidíme. Ale první dojem je dobrý. Určitě bych raději používal vlastní clustery Kubernetes než Heroku, protože mám větší svobodu a můžu se učit nové věci. Protože Linstor se nenainstaluje tak snadno jako ostatní, brzy o tom napíšu příspěvek.
Srovnávací hodnoty
Bohužel jsem si o srovnání vedl málo záznamů, protože jsem si nemyslel, že o tom budu psát. Mám pouze výsledky benchmarků základní linie fio a pouze pro clustery s jedním uzlem, takže zatím nemám čísla pro replikované konfigurace. Ale z těchto výsledků si můžete udělat přibližnou představu o tom, co od jednotlivých možností očekávat, protože jsem je porovnával na stejných cloudových serverech, 4 jádrech, 16 GB RAM, s přídavným 100 GB diskem pro testované svazky. Pro každé řešení jsem třikrát provedl srovnávací testy a vypočítal průměrný výsledek plus resetoval nastavení serveru pro každý produkt. To vše je zcela nevědecké, jen abyste to pochopili obecně. V dalších testech jsem zkopíroval 38 GB fotografií a videí ze svazku a pro testování čtení a psaní, ale bohužel jsem čísla neuložil. Stručně řečeno: Portworkx byl mnohem rychlejší.
Pro objemový benchmark jsem použil tento 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: 4Nejprve jsem vytvořil svazek s příslušnou třídou úložiště a poté jsem v zákulisí spustil úlohu s fio. Vzal jsem si 1 GB, abych odhadl výkon a nečekal příliš dlouho. Zde jsou výsledky:
Nejlepší hodnotu pro každou metriku jsem zvýraznil zeleně a nejhorší červeně.
Závěr
Jak můžete vidět, ve většině případů si Portworx vedl lépe než ostatní. Ale pro mě je to drahé. Nevím, kolik Robin stojí, ale existuje skvělá bezplatná verze, takže pokud potřebujete placený produkt, můžete ho vyzkoušet (doufám, že problém s obnovami a zálohami brzy vyřeší). Ze tří bezplatných jsem měl nejméně problémů s OpenEBS, ale jeho výkon je propastný. Omlouvám se, že jsem neuložil více výsledků, ale doufám, že vám čísla a mé komentáře pomohou.
Zdroj: www.habr.com
