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ž čtenář navrhl vyzkoušet Linstor. Zkusil jsem to a líbilo se mi to! Ale stejně musíte kopat. Nyní mohu říci, že výkon není špatný (výsledky benchmarku přidány níže). Vlastně jsem dostal stejný výkon jako u disku přímo, bez jakékoliv režie. (Neptejte se, proč jsou čísla Portworxu přímo lepší než benchmark disku. Nemám ponětí. Myslím, že magie.) Takže Linstor se zatím zdá být velmi efektivní. Instalace není tak obtížná, ale není tak snadná jako jiné možnosti. Nejprve jsem musel nainstalovat Linstor (modul jádra a nástroje/služby) a nastavit LVM pro tenké zřizování a podporu snapshotů mimo Kubernetes, přímo na hostiteli a poté vytvořit prostředky potřebné k používání úložiště z Kubernetes. Nelíbilo se mi, že to nefungovalo na CentOS a muselo se používat Ubuntu. Není to samozřejmě strašné, ale trochu otravné, protože dokumentace (mimochodem vynikající) zmiňuje několik balíčků, které nelze najít ve specifikovaných repozitářích Epel. Linstor má snímky, ale žádné zálohy mimo web, takže i zde jsem musel k zálohování svazků použít Velero s Restic. Upřednostnil bych snímky před zálohami na úrovni souborů, ale to lze tolerovat, pokud je řešení výkonné a spolehlivé. Linstor je open source, ale má placenou podporu. Pokud tomu dobře rozumím, lze jej používat bez omezení, i když nemáte smlouvu o podpoře, ale je potřeba si to ujasnit. Nevím, jak je Linstor testován pro Kubernetes, ale samotná vrstva úložiště je mimo Kubernetes a řešení se zjevně neobjevilo včera, takže je pravděpodobně již testováno v reálných podmínkách. Existuje zde řešení, které mě přiměje změnit názor a vrátit se ke Kubernetes? Nevím. Stále musíme kopat hlouběji, studovat replikaci. Uvidíme. Ale první dojem je dobrý. Rozhodně bych raději místo Heroku používal vlastní clustery Kubernetes, abych měl větší svobodu a učil se nové věci. Vzhledem k tomu, že instalace Linstoru není tak snadná jako u jiných, brzy o něm 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