Frissítés!. A kommentekben az egyik olvasó javasolta, hogy próbáljuk ki (lehet, hogy ő maga dolgozik rajta), így hozzáadtam egy szakaszt erről a megoldásról. Írtam egy , mert a folyamat nagyon eltér a többitől.
Őszintén szólva, feladtam és lemondtam a (mindenesetre egyelőre). Használni fogom a . Miért? Mert a tárolás! Ki gondolta volna, hogy többet foglalkozom a tárolással, mint magával a Kubernetes-szel. Használom a , mert olcsó és jó a teljesítmény, és az elejétől kezdve klasztereket telepítettem . Nem próbáltam ki a Google/Amazon/Microsoft/DigitalOcean stb. által kínált menedzselt Kubernetes szolgáltatásokat, mert mindent magam akartam megtanulni. Ráadásul takarékos vagyok.
Szóval igen, rengeteg időt töltöttem azzal, hogy megpróbáljam kitalálni, melyik tárolót válasszam, amikor a Kubernetes lehetséges stack-jét terveztem. Szeretem a nyílt forráskódú megoldásokat, és nem csak az ára miatt, hanem kíváncsiságból kipróbáltam néhány fizetős lehetőséget is, mert ezeknek van ingyenes, korlátozott verziójuk. Felírtam néhány számot az utolsó tesztekből, mikor összehasonlítottam a különböző lehetőségeket, és ezek érdekelhetik azokat, akik a Kubernetes tárolással foglalkoznak. Bár személy szerint én egyelőre búcsút intettem a Kubernetesnek. Még meg szeretném említeni , amellyel közvetlenül készíthetjük elő a Hetzner Cloud köteteket, de eddig még nem próbáltam ki. Felhőalapú szoftveresen definiált tárolásokat tanulmányoztam, mert szükségem volt replikálásra és állandó kötetek gyors csatlakoztatására bármelyik node-on, különösen node hiba és hasonló helyzetek esetén. Néhány megoldás időpontra vonatkozó pillanatképeket és off-site mentéseket kínál, ami kényelmes.
6–7 tárolási megoldást teszteltem:
Mint már említettem , tesztelve a legtöbb lehetőséget a listából, kezdetben az OpenEBS-re esett a választásom. Az OpenEBS-t nagyon egyszerű telepíteni és használni, de őszintén szólva a valós adatok terhelés alatti tesztjei után a teljesítménye csalódást okozott. Ez egy nyílt forráskódú megoldás, és a fejlesztők a saját mindig nagyon segítettek, amikor segítségre volt szükségem. Sajnos a teljesítménye nagyon alacsony más lehetőségekhez képest, ezért újra kellett végezni a teszteket. Jelenleg az OpenEBS-nek 3 tárolómotorja van, de az cStor teljesítményének tesztelési eredményeit publikálom. Még nincsenek adataim a Jiva és a LocalPV tekintetében.
Röviden, a Jiva kicsit gyorsabb, míg a LocalPV igazán gyors, nem rosszabb, mint a közvetlen lemez tesztje. A LocalPV probléma az, hogy csak azon a nódon érhető el, ahol előkészítették, és nincs replikáció. Volt néhány problémám a biztonsági mentés visszaállításával a új klaszteren, mert a nódok nevei eltértek. Ha a biztonsági mentésekről beszélünk, a cStor rendelkezik pluginnal, amellyel időpontbeli snapshots offsite biztonsági mentéseket készíthetünk, ami kényelmesebb, mint a fájl szintű biztonsági mentések a Velero-Restic segítségével. Írtam , hogy egyszerűbb legyen a biztonsági mentések és visszaállítások kezelése ezzel a pluginnal. Összességében nagyon tetszik az OpenEBS, de a teljesítménye...
A Rook is nyílt forráskódú, és az összes többi lehetőségtől abban különbözik, hogy ez egy tárolóorchestrátor, amely bonyolult tároláskezelési feladatokat végez különböző backendekkel, mint például , és mások, ami jelentősen megkönnyíti a munkát. Volt néhány problémám az EdgeFS-sel, amikor néhány hónappal ezelőtt próbáltam, így főleg a Ceph-teszteltem. A Ceph nemcsak blokk storage-ot, hanem S3/Swift kompatibilis objektumtárolást és elosztott fájlrendszert is kínál. Ami tetszik a Ceph-ben, az a lehetőség, hogy a kötet adatait több lemezen eloszthatjuk, így a kötet több lemez területét is felhasználhatja, mint ami egy lemezen elfér. Ez kényelmes. Egy másik szuper funkció - amikor új lemezeket adunk a klaszterhez, automatikusan újraelosztja az adatokat az összes lemezen.
A Ceph-ben léteznek snapshotok, de amennyire tudom, ezeket nem lehet közvetlenül használni a Rook/Kubernetes-ben. Igaz, hogy nem mélyedtem el ebben. Off-site backupok viszont nincsenek, így valami Velero/Restic megoldást kell használnunk, de az csak fájl szintű backupokat kínál, nem időpillanat snapshotokat. Viszont a Rook-ban nagyon tetszett a Ceph egyszerű kezelése – szinte minden bonyolult dolgot elrejt és eszközöket kínál a Ceph közvetlen kommunikációjára a hibák elhárítása érdekében. Sajnos a Ceph kötetek stressztesztelésénél folyamatosan , ami miatt a Ceph instabillá válik. Egyelőre nem világos, hogy ez egy bug a Ceph-ben, vagy a Rook kezelési problémája. Játszottam a memóriabeállításokkal, és lett egy kicsit jobb, de a probléma véglegesen nem oldódott meg. A Ceph teljesítménye nem rossz, ahogy az az alábbi benchmarkokból is látható. Ráadásul jó monitorozó felülete van.
Nagyon tetszik a Longhorn. Szerintem ígéretes megoldás. Igaz, hogy a fejlesztők (Rancher Labs) elismerik, hogy a termelői környezethez még nem alkalmas, és ez látszik is. Nyílt forráskódú és tisztességes teljesítménye van (bár az optimalizálásán még nem dolgoztak), de a kötetek csatlakozása a podhoz nagyon sokáig tart, a legrosszabb esetekben akár 15–16 perc is lehet, különösen nagy backupok helyreállítása vagy a munkaterhelés frissítése után. Vannak snapshotok és off-site backupok ezekhez a snapshotokhoz, de ezek csak a kötetekre vonatkoznak, így szükség van valami Velero szerű megoldásra az egyéb erőforrások backupjához. A backupok és helyreállítások nagyon megbízhatóak, de borzasztóan lassúak. Komolyan, irreálisan lassúak. A CPU erőforrások kihasználtsága és a rendszer terhelése gyakran megugrik, amikor közepes mennyiségű adatot kezelünk a Longhornban. Van egy kényelmes monitorozó panel a Longhorn kezeléséhez. Már mondtam, hogy tetszik a Longhorn, de ezen még rendesen dolgozni kell.
A StorageOS az első fizetős termék a listán. Van egy fejlesztői verziója, amely korlátozott, 500 GB méretű kezelhető tárolással rendelkezik, de a csomópontok számának korlátozása úgy tűnik, hogy nincs. Az értékesítési osztályban azt mondták nekem, hogy az árak 125 dollártól kezdődnek havonta 1 TB-ra, ha jól emlékszem. Van egy alap monitoring panel és kényelmes CLI, de a teljesítménnyel valami furcsa történik: egyes benchmarkok teljesítménye egészen tisztességes, de a kötetek stressztesztjén a sebesség egyáltalán nem tetszett. Összességében nem tudom, mit mondjak. Ezért nem is mélyedtem el benne. Itt nincsenek off-site biztonsági mentések, és a kötetek biztonsági mentéséhez is a Velero-t kell használni a Restic-kel. Furcsa, hiszen a termék fizetős. A fejlesztők pedig nem nagyon akartak kommunikálni a Slack-en.
A Robin-ról a Redditen tudtam meg az ő műszaki igazgatójától. Előtte sosem hallottam róla. Talán azért, mert ingyenes megoldásokat kerestem, mientras a Robin egy fizetős szolgáltatás. Van egy elég nagylelkű ingyenes verziójuk, 10 TB tárhellyel és három núddal. Összességében a termék eléggé értékes és kellemes funkciókkal rendelkezik. Kiváló CLI-jük van, de a legjobb az, hogy lehetőség van az egész alkalmazás snapshotjára és biztonsági mentésére (a forráselemek kiválasztásánál „Helm release”-nek vagy „flex apps”-nak hívják), beleértve a köteteket és egyéb forrásokat, így Velero nélkül is megoldható. Minden szép lenne, ha nem lenne egy kis részlet: ha egy alkalmazást egy új klaszterre kell helyreállítani (vagy „importálni”, ahogy a Robin hívja) - például katasztrófa utáni helyreállítás esetén - a helyreállítás természetesen működik, de az alkalmazás biztonsági mentését nem lehet folytatni. Ebben a kiadásban ez egyszerűen nem lehetséges, és a fejlesztők ezt megerősítették. Ez, finoman szólva, furcsa, különösen figyelembe véve a többi előnyét (például a hihetetlenül gyors biztonsági mentéseket és helyreállításokat). A fejlesztők ígéretet tettek arra, hogy a következő kiadásra megoldják. A teljesítmény összességében jó, de észrevettem egy furcsaságot: ha közvetlenül a hosztra csatlakoztatott kötetben futtatom a benchmarkot, az olvasási sebesség sokkal magasabb, mint ugyanabban a kötetben, de a pod-ból. Minden más eredmény azonos, de elméletileg ennek nem kellene így lennie. Bár dolgoznak rajta, elkeseredtem a helyreállítás és biztonsági mentés problémája miatt - úgy éreztem, végre megtaláltam a megfelelő megoldást, és még hajlandó lettem volna fizetni érte, amikor több térre vagy több szerverre lesz szükségem.
Itt különösebben nincs mit mondanom. Ez egy fizetős termék, ugyanannyira nagyszerű, mint drága. A teljesítmény egyszerűen csodás. Jelenleg ez a legjobb mutató. A Slackben azt mondták, hogy az ár havi 205 dollártól kezdődik nodánként, ahogy azt a Google GKE Marketplace-en feltüntették. Nem tudom, olcsóbb lesz-e, ha közvetlenül vásárolsz. Mindenesetre nem engedhetem meg magamnak, így nagyon és nagyon csalódott voltam, hogy a fejlesztői licenc (1 TB-ig és 3 nodáig) gyakorlatilag haszontalan Kubernetes mellett, hacsak nem elégedsz meg a statikus felkészüléssel. Reméltem, hogy a vállalati licenc automatikusan lecsökkent a fejlesztői szintre a próbaverzió végén, de ez nem történt meg. A fejlesztői licencet csak közvetlenül Dockerrel lehet használni, míg a Kubernetes konfigurálása nagyon körülményes és korlátozott. Természetesen az open source-t részesítem előnyben, de ha lenne pénzem, biztosan a Portworx-ot választanám. Jelenleg a teljesítménye egyszerűen felülmúlja a többi lehetőséget.
Ezt a részt már a bejegyzés közzététele után adtam hozzá, amikor egy olvasó javasolta, hogy próbáljam ki a Linstort. Kipróbáltam, és nagyon tetszett! De még van mit kutatni. Jelenleg elmondhatom, hogy a teljesítmény nem rossz (a benchmark eredményeket lentebb adtam hozzá). Alapvetően olyan teljesítményt kaptam, mint közvetlen diszk használatával, teljes költségek nélkül. (Ne kérdezd, miért jobb a Portworx adatainak száma, mint a közvetlen diszk benchmarké. Fogalmam sincs. Talán csak varázslat.) Szóval a Linstor eddig nagyon hatékonynak tűnik. A telepítése nem nehéz, de nem is annyira egyszerű, mint a többi alternatíva. Először a Linstort (kernel modul és eszközök/szolgáltatások) kellett telepítenem, és beállítanom az LVM-et a thin provisioning és a Kubernetes-en kívüli snapshotok támogatására közvetlenül a gazdagépen, majd létrehozni a tárolás használatához szükséges erőforrásokat Kubernetes-ből. Nem tetszett, hogy CentOS-on nem működött, és Ubuntu-t kellett használnom. Persze nem tragikus, de kissé bosszantó mert a dokumentáció (amúgy remek) említ néhány csomagot, amelyet nem találni az Epel-adatbázisokban. A Linstor támogatja a snapshotokat, de nem az off-site biztonsági mentéseket, így újra a Velero volt szükséges a kötetek biztonsági mentéséhez Restic segítségével. Jobban preferálnám a snapshotokat a fájl szintű biztonsági mentések helyett, de ezt el lehet viselni, ha a megoldás teljesítmény- és megbízhatóság szempontjából is rendben van. A Linstornak nyílt forráskódú a kódja, de van fizetett támogatás is. Ha jól értem, korlátlanul használható, még akkor is, ha nincs támogatási szerződése, de ezt érdemes tisztázni. Nem tudom, mennyire van a Linstor bevizsgálva Kubernetes-re, de a tárolási szint Kubernetes-en kívül van, és úgy tűnik, a megoldás nem tegnap jelent meg, szóval valós környezetben már valószínűleg bevizsgálták. Van itt olyan megoldás, ami miatt meggondolnám magam és visszatérnék a Kubernetes-hez? Nem tudom, nem tudom. Még kell kutakodnom, a replikációt is meg kell néznem. Majd meglátjuk. De az első benyomás jó. Határozottan inkább használnám a saját Kubernetes klasztereimet a Heroku helyett, hogy több szabadságot kapjak és új dolgokat tanuljak. Mivel a Linstor telepítése nem olyan egyszerű, mint a többi, hamarosan írok erről egy bejegyzést.
Benchmarkok
Sajnálom, hogy kevés összehasonlítást mentettem el, mert nem gondoltam, hogy erről írni fogok. Csak a fenti alap benchmarkok eredményei vannak, és azok is csak az egycsomópontos klaszterekre vonatkoznak, így a replikált konfigurációkhoz még nincsenek számadataim. De ezek alapján nagyjából képet kaphatunk arról, hogy mit várhatunk az egyes opcióktól, mivel azonos felhőszervereken, 4 maggal és 16 GB RAM-mal teszteltem őket, valamint 100 GB-os külön diszkot használtam a tesztelt kötetekhez. Minden megoldásnál háromszor futtattam a benchmarkokat, és kiszámoltam az átlagos eredményt, emellett minden termékhez visszaállítottam a szerver beállításait. Ez az egész teljesen nem tudományos, csupán annyira, hogy átfogó képet kapj. Más tesztekben 38 GB képet és videót másoltam kötetből kötetbe, hogy teszteljem az olvasást és írást, de sajnos nem jegyeztem fel a számokat. Röviden: a Portworx sokkal gyorsabb volt.
A kötetek benchmarkjához ezt a manifestot használtam:
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: 4Először létrehoztam egy kötetet a megfelelő tárolási osztállyal, majd háttérben futtattam egy fio feladatot. 1 GB-ot választottam a teljesítmény becslésére, hogy ne kelljen túlságosan sokáig várakozni. Íme az eredmények:
Minden mutatóhoz a legjobb értéket zölddel, a legrosszabbat pedig pirossal jelöltem.
Zárás
Ahogy látjátok, a legtöbb esetben a Portworx jobbnak bizonyult a többinél. De számomra drága. Nem tudom, mennyibe kerül a Robin, de van egy remek ingyenes verziója, szóval, ha fizetős termékre van szükséged, érdemes kipróbálni (remélem, hamarosan orvosolják a helyreállítási és biztonsági mentési problémákat). A három ingyenes közül nekem az OpenEBS-sel volt a legkevesebb problémám, de a teljesítménye siralmas. Kár, hogy nem mentettem el több eredményt, de remélem, hogy a megadott számok és a megjegyzéseim hasznosak lesznek számodra.
Forrás: habr.com
