Aktualizace!. V komentářích jeden z čtenářů navrhl zkusit (možná na něm sám pracuje), takže jsem přidal sekci o tomto řešení. Také jsem napsal , protože proces se výrazně liší od ostatních.
Pokud mám být upřímný, vzdal jsem to a vzdal se (aspoň zatím). Budu používat . Proč? Kvůli úložním systémům! Kdo by si pomyslel, že se budu více zabývat úložišti než samotným Kubernetes. Používám , protože je to levné a výkon je dobrý, a od začátku jsem nasazoval clustery pomocí . Nezkoušel jsem řízené služby Kubernetes od Google/Amazon/Microsoft/DigitalOcean a dalších, protože jsem se to chtěl naučit sám. A také jsem šetrný.
Takže ano, strávil jsem spoustu času snažíc se rozhodnout, které úložiště zvolit, když jsem zvažoval možný stack na Kubernetes. Preferuji řešení s otevřeným zdrojovým kódem, a to nejen kvůli ceně, ale také jsem prozkoumal pár placených variant z zvědavosti, protože mají bezplatné verze s omezeními. Zaznamenal jsem několik čísel z posledních testů, když jsem srovnával různé možnosti, a ty by mohly zajímat ty, kteří studují úložiště v Kubernetes. Ačkoli jsem osobně zatím s Kubernetes skončil. Ještě chci zmínit , kterým lze přímo připravovat svazky Hetzner Cloud, ale zatím jsem ho nezkoušel. Zkoumal jsem cloudová softwarově definovaná úložiště, protože jsem potřeboval replikaci a možnost rychle připojit trvalé svazky na jakémkoli uzlu, zvlášť v případě selhání uzlů a podobných situací. Některá řešení nabízejí snímky v čase a off-site zálohy, což je praktické.
Otestoval jsem 6–7 řešení pro ukládání:
Jak už jsem říkal , po testování většiny možností z seznamu jsem se zpočátku zastavil na OpenEBS. OpenEBS je velmi snadné nainstalovat a používat, ale, pokud mám být upřímný, po testech s reálnými daty pod zátěží mě jeho výkon zklamal. Je to open-source, a vývojáři na svém vždy mi velmi pomohli, když jsem potřeboval pomoc. Bohužel má velmi nízký výkon ve srovnání s jinými variantami, takže jsem musel provést testy znovu. V současné době má OpenEBS 3 úložné motory, ale publikuji výsledky benchmarku pro cStor. Zatím nemám čísla pro Jiva a LocalPV.
Stručně řečeno, Jiva je o něco rychlejší, zatímco LocalPV je skutečně rychlý, není horší než benchmark disku přímo. Problém s LocalPV je, že přístup k němu lze získat pouze na té uzlu, kde byl připraven, a replikace vůbec neexistuje. 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é. Pokud jde o zálohy, cStor má , s kterým lze provádět off site zálohy snapshotů k určitému času, což je pohodlnější než zálohy na úrovni souborů s Velero-Restic. Napsal jsem , abych usnadnil správu záloh a obnovení s tímto pluginem. Celkově se mi OpenEBS velmi líbí, ale jeho výkon…
Rook má také otevřený zdrojový kód, a od ostatních variant v seznamu se liší tím, že je to orchestrátor úložiště, který provádí složité úkoly správy úložiště s různými backendy, například , a další, což výrazně usnadňuje práci. Měl jsem problémy s EfgeFS, když jsem ho zkoušel před několika měsíci, takže jsem testoval převážně s Ceph. Ceph nabízí nejen blokové úložiště, ale také objektové úložiště kompatibilní se S3/Swift a distribuovaný souborový systém. Co se mi na Cephu líbí, je možnost rozšířit data objemu na několik disků, aby objem mohl využívat více prostoru na disku, než se vejde na jeden disk. To je pohodlné. Další skvělá funkce je, že když přidáte do clustru disky, automaticky přerozdělí data mezi všechny disky.
Ceph má snapshoty, ale jak víte, nelze je přímo použít v Rook/Kubernetes. I když jsem se tím podrobněji nezabýval. Off site zálohy bohužel nejsou, takže bude potřeba použít něco jako Velero/Restic, ale tam jsou pouze zálohy na úrovni souborů, nikoli snapshoty v daném okamžiku. Na druhou stranu se mi v Rook velmi líbila jednoduchost práce s Ceph — skrývá téměř všechny složité záležitosti a nabízí nástroje pro přímou komunikaci s Ceph pro odstraňování problémů. Bohužel jsem měl stále problémy se stresovými testy objemů Ceph. , kvůli němuž je Ceph nestabilní. Zatím není jasné, zda je to chyba v samotném Ceph nebo problém v tom, jak Rook spravuje Ceph. Pohrál jsem si s nastavením paměti a bylo to lepší, ale problém nebyl úplně vyřešen. Ceph má slušný výkon, jak je vidět v benchmarkech níže. Navíc má dobrou monitorovací konzoli.
Longhorn se mi opravdu líbí. Domnívám se, že je to perspektivní řešení. Přesto sami vývojáři (Rancher Labs) uznávají, že pro produkční prostředí zatím není vhodný, a to je patrné. Má otevřený zdrojový kód a slušný výkon (i když se jeho optimalizací dosud nezabývali), ale objemy se k podu připojují velmi pomalu, v nejhorších případech to trvá 15–16 minut, zejména po obnově velké zálohy nebo upgradu pracovní zátěže. Má snapshoty a off site zálohy těchto snapshotů, ale ty se týkají pouze objemů, takže budete stejně potřebovat něco jako Velero pro zálohování ostatních zdrojů. Zálohy a obnovy jsou velmi spolehlivé, ale neuvěřitelně pomalé. Opravu, prostě extrémně pomalé. Využití procesorových zdrojů a zatížení systému často vzrůstají při práci se středně velkými daty v Longhorn. Existuje pohodlná monitorovací konzole pro správu Longhorn. Už jsem řekl, že se mi Longhorn líbí, ale je třeba na něm pořádně zapracovat.
StorageOS je prvním placeným produktem na seznamu. Má verzi pro vývojáře s omezenou velikostí spravovaného úložiště na 500 GB, ale počet uzlů není, jak se zdá, omezen. V obchodním oddělení mi řekli, že cena začíná na 125 $ měsíčně za 1 TB, pokud si to pamatuji správně. Existuje základní monitorovací panel a pohodlné CLI, ale s výkonností je to nějak divné: v některých benchmarkách je docela slušná, ale ve stresovém testu objemů se mi rychlost vůbec nelíbila. Celkově nevím, co říct. Proto jsem se o to příliš nezajímal. Nebylo zde žádné off-site zálohování a budu muset také použít Velero s Restic pro zálohování objemů. Divné, vždyť je to placený produkt. A vývojáři neměli moc chuť komunikovat na Slacku.
O Robin jsem se dozvěděl na Redditu od jejich technického ředitele. Dříve jsem o něm neslyšel. Možná proto, že jsem hledal bezplatná řešení, zatímco Robin je placené. Mají docela štědrý bezplatný plán s úložištěm o velikosti 10 TB a třemi uzly. Celkově je produkt velmi solidní a nabízí příjemné funkce. Existuje vynikající CLI, ale to nejlepší je, že můžete vytvořit snapshot a zálohu celé aplikace (v sekci zdrojů se to nazývá release Helm nebo „flex apps“), včetně svazků a dalších zdrojů, takže se můžete obejít bez Velera. A vše by bylo skvělé, kdyby nebyl jeden malý detail: pokud obnovujete (nebo „importujete“, jak se to nazývá v Robin) aplikaci na novém clusteru — například v případě obnovy po havárii — obnova samozřejmě funguje, ale pokračovat v zálohování aplikace není možné. V této verzi je to zkrátka nemožné a vývojáři to potvrdili. To je mírně řečeno divné, zvlášť když vezmeme v úvahu ostatní výhody (například neuvěřitelně rychlé zálohy a obnovy). Vývojáři slibují, že vše opraví v další verzi. Výkon je celkově dobrý, ale všiml jsem si jednoho zvláštního jevu: pokud spustím benchmark přímo na svazku připojeném k hostiteli, rychlost čtení je mnohem vyšší než ve stejném svazku, ale uvnitř podu. Všechny ostatní výsledky jsou identické, ale teoreticky by neměla být žádná rozdílnost. Ačkoliv na tom stále pracují, rozesmutnilo mě to, že problém s obnovou a zálohováním přetrvává — zdálo se mi, že jsem konečně našel vhodné řešení, a dokonce jsem byl ochoten za něj zaplatit, až budu potřebovat více prostoru nebo více serverů.
Tady nemám moc co říct. Je to placený produkt, stejně skvělý a drahý. Výkon je prostě úžasný. Zatím to nejlepší, co máme. V Slacku mi řekli, že cena začíná na 205 $ měsíčně za uzel, jak je uvedeno na GKE Marketplace od Google. Nevím, jestli to bude levnější při přímém nákupu. Tak jako tak, já si to nemohu dovolit, takže jsem byl velmi a velmi zklamaný, že licence pro vývojáře (do 1 TB a 3 uzly) je prakticky k ničemu s Kubernetes, pokud se spokojíte s statickou přípravou. Doufal jsem, že firemní licence se automaticky sníží na úroveň vývojáře na konci zkušebního období, ale to se nestalo. Licenci pro vývojáře lze používat pouze přímo s Dockerem, a nastavení v Kubernetes je velmi složité a omezené. Já samozřejmě preferuji open source, ale kdybych měl peníze, určitě bych zvolil Portworx. Jeho výkon zatím prostě nemá konkurenci mezi ostatními možnostmi.
Tuto sekci jsem přidal až po publikaci příspěvku, když jeden čtenář navrhl vyzkoušet Linstor. Vyzkoušel jsem to a byl jsem spokojen! Ale je třeba se ještě hlouběji prozkoumat. Teď mohu říct, že výkon není špatný (výsledky benchmarku jsem přidal níže). V podstatě jsem dostal stejný výkon, jaký mám pro disk přímo, úplně bez ztrát. (Neptejte se, proč mají Portworx lepší čísla než benchmark disku přímo. Nemám tušení. Asi magie.) Takže Linstor se zatím zdá být velmi efektivní. Instalace není zrovna složitá, ale není tak snadná jako u ostatních možností. Nejprve 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 pak vytvořit potřebné zdroje pro používání úložiště z Kubernetes. Nelíbilo se mi, že nefungoval na CentOS a musel jsem použít Ubuntu. Není to sice tragédie, ale trochu to rozčiluje, protože v dokumentaci (která je mimochodem skvělá) se zmiňuje několik balíků, které nelze najít v uvedených repozitářích Epel. V Linstoru jsou snapshoty, ale ne off-site zálohy, takže jsem musel znovu použít Velero s Resticem pro zálohu objemů. Raději bych měl snapshoty místo záloh na úrovni souborů, ale to se dá přežít, pokud bude řešení výkonné a spolehlivé. Linstor má otevřený zdroj, ale existuje placená podpora. Pokud chápu správně, lze ho používat bez omezení, i když nemáte smlouvu na podporu, ale to je třeba ověřit. Nevím, jak moc je Linstor ověřen pro Kubernetes, ale samotná úroveň úložiště je za hranicemi Kubernetes a zdá se, že toto řešení nevzniklo včera, takže asi už bylo ověřeno v reálných podmínkách. Existuje zde nějaké řešení, které mě přesvědčí a přivede zpět k Kubernetes? Nevím, nevím. Je třeba se ještě více probádat a prozkoumat replikaci. Uvidíme. Ale první dojem je dobrý. Rozhodně bych raději používal své vlastní Kubernetes clustery místo Heroku, abych měl více svobody a učil se novým věcem. Protože instalace Linstoru není tak jednoduchá jako u ostatních, brzy o tom napíšu článek.
Benchmarky
Bohužel, uchoval jsem si málo záznamů o srovnání, protože jsem si nemyslel, že o tom budu psát. Mám pouze výsledky základních benchmarků fio a to jen pro clustery s jedním uzlem, takže pro replikované konfigurace zatím nemám čísla. Ale z těchto výsledků lze získat přibližnou představu o tom, co očekávat od každé varianty, protože jsem je srovnával na stejných cloudových serverech, 4 jádra, 16 GB RAM, s dodatečným diskem o kapacitě 100 GB pro testované objemy. Benchmarky jsem spustil třikrát pro každé řešení a vypočítal průměrný výsledek, plus jsem resetoval nastavení serveru pro každý produkt. Vše je zcela neodborné, jen abyste měli obecnou představu. V jiných testech jsem kopíroval 38 GB fotek a videí z objemu a na objem, abych otestoval čtení a zápis, ale čísla, bohužel, nemám. Stručně řečeno: Portworx bylo mnohem rychlejší.
Pro benchmark objemů 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 objem se odpovídající třídou úložiště a poté jsem spustil úlohu s fio na pozadí. Vybral jsem 1 GB, abych si odhadl výkon a nečekal příliš dlouho. Zde jsou výsledky:
Nejlepší hodnota každé metriky je zvýrazněna zeleně a nejhorší červeně.
Závěr
Jak vidíte, v drtivé většině případů si Portworx vedlo lépe než ostatní. Ale pro mě je to drahé. Nevím, kolik stojí Robin, ale mají skvělou bezplatnou verzi, takže pokud potřebujete placený produkt, můžete to zkusit (doufám, že brzy vyřeší problém s obnovou a zálohováním). Z těch tří bezplatných jsem měl nejméně problémů s OpenEBS, ale jeho výkon je tragický. Škoda, že jsem si uchoval méně výsledků, ale doufám, že vám uvedená čísla a mé komentáře pomohou.
Zdroj: habr.com
