Frissítés!. A megjegyzésekben az egyik olvasó javasolta a próbálkozást (lehet, hogy ő maga dolgozik rajta), ezért hozzáadtam egy részt erről a megoldásról. én is írtam , mert a folyamat nagyon eltér a többitől.
Őszintén szólva feladtam és feladtam (Legalább most). használni fogom . Miért? A tárolás miatt! Ki gondolta volna, hogy többet bütykölök a tárolással, mint magával a Kubernetes-el. használom mert olcsó és a teljesítménye jó, és a kezdetektől fogva fürtöket telepítek . Nem próbáltam ki a Google/Amazon/Microsoft/DigitalOcean stb., stb. menedzselt Kubernetes szolgáltatásait, mert mindent magam akartam megtanulni. Én is takarékos vagyok.
Szóval igen, sok időt töltöttem azzal, hogy eldöntsem, melyik tárhelyet válasszam, amikor egy lehetséges Kubernetes-vermet értékeltem. Inkább a nyílt forráskódú megoldásokat részesítem előnyben, nem csak az ára miatt, hanem kíváncsiságból utánanéztem pár fizetős lehetőségnek is, mert vannak ingyenes verzióik, korlátozásokkal. Feljegyeztem néhány számot a legutóbbi tesztekből, amikor összehasonlítottam a különböző lehetőségeket, és ezek érdekesek lehetnek azok számára, akik tanulnak a Kubernetes tárolásáról. Bár én személy szerint egyelőre búcsút mondtam a Kubernetesnek. Azt is szeretném megemlíteni , amely képes közvetlenül ellátni a Hetzner Cloud köteteket, de még nem próbáltam ki. Megnéztem a felhőalapú szoftver által definiált tárolást, mert replikációra volt szükségem, és arra, hogy gyorsan felcsatoljam a perzisztens köteteket bármely csomópontra, különösen csomóponti hibák és más hasonló helyzetek esetén. Egyes megoldások pont-időben pillanatképeket és off-site biztonsági mentéseket kínálnak, ami kényelmes.
6-7 tárolási megoldást teszteltem:
Ahogy már mondtam Miután kipróbáltam a listából a legtöbb lehetőséget, először az OpenEBS mellett döntöttem. Az OpenEBS telepítése és használata nagyon egyszerű, de őszintén szólva a valós adatokkal való tesztelés után terhelés alatt csalódott voltam a teljesítményében. Ez nyílt forráskódú, és a fejlesztők saját maguk mindig nagyon segítőkész volt, ha segítségre volt szükségem. Sajnos más opciókhoz képest nagyon gyenge a teljesítménye, ezért a teszteket újra kellett futtatni. Az OpenEBS-nek jelenleg 3 tárolómotorja van, de közzéteszem a cStor benchmark eredményeit. Még nincs számom a Jiva és a LocalPV számára.
Dióhéjban a Jiva egy kicsit gyorsabb, a LocalPV pedig általában gyors, nem rosszabb, mint a lemez benchmark közvetlenül. A LocalPV problémája az, hogy a kötet csak azon a csomóponton érhető el, ahol előkészítették, és nincs replikáció. Problémám akadt a biztonsági mentés visszaállítása közben egy új fürtön, mert a csomópontnevek eltérőek voltak. Ha a biztonsági mentésekről beszélünk, a cStornak igen , mellyel egy adott időpontban pillanatképekről külső helyszínről készíthet biztonsági másolatot, ami kényelmesebb, mint a Velero-Restic fájlszintű biztonsági mentése. írtam , hogy ezzel a bővítménnyel könnyebben kezelhető legyen a biztonsági mentések és visszaállítások. Összességében nagyon szeretem az OpenEBS-t, de a teljesítménye...
A Rook szintén nyílt forráskódú, és abban különbözik a lista többi lehetőségétől, hogy egy tárhelykezelő, amely összetett tárkezelési feladatokat hajt végre különböző háttérrendszerekkel, pl. , és mások, ami nagyban leegyszerűsíti a munkát. Amikor néhány hónappal ezelőtt kipróbáltam, problémáim voltak az EfgeFS-sel, ezért főleg Ceph-el teszteltem. A Ceph nem csak blokktárolást kínál, hanem S3/Swift-tel és elosztott fájlrendszerrel kompatibilis objektumtárolást is. Amit szeretek a Ceph-ben, az az a képesség, hogy a kötetadatokat több lemezen szétosztják, így a kötet több lemezterületet tud használni, mint amennyi egyetlen lemezen elfér. Ez kényelmes. Egy másik nagyszerű funkció, hogy amikor lemezeket ad hozzá egy fürthöz, az automatikusan újraelosztja az adatokat az összes lemezen.
A Ceph-nek vannak pillanatképei, de amennyire én tudom, ezek nem használhatók közvetlenül a Rook/Kubernetesben. Igaz, ebbe nem mentem mélyre. De nincsenek off-site biztonsági mentések, tehát valamit használnia kell a Velero/Restic szolgáltatással, de csak fájlszintű biztonsági másolatok vannak, pillanatfelvételek nem. Amit nagyon szerettem Rook-ban, az az, hogy mennyire könnyű a Ceph-fel dolgozni – szinte minden bonyolult dolgot elrejt, és eszközöket kínál, amelyek segítségével közvetlenül Ceph-fel beszélhetek a hibaelhárításhoz. Sajnos a Ceph kötetek stressztesztje során folyamatosan problémáim voltak , ami miatt a Ceph instabillá válik. Egyelőre nem világos, hogy ez magában a Ceph hibája, vagy Rook Ceph kezelésének problémája. A memória beállításain bütykölgettem, és jobb lett, de a probléma nem oldódott meg teljesen. A Ceph tisztességes teljesítményt nyújt, amint azt az alábbi benchmarkok is láthatják. Jó műszerfala is van.
Nagyon szeretem Longhornt. Véleményem szerint ez egy ígéretes megoldás. Igaz, maguk a fejlesztők (Rancher Labs) elismerik, hogy ez még nem alkalmas a munkakörnyezetre, és ez meg is látszik. Nyílt forráskódú, és megfelelő a teljesítménye (bár még nem optimalizálták), de a kötetek nagyon sokáig tartanak, amíg a podhoz csatlakoznak, és legrosszabb esetben 15-16 percet vesz igénybe, különösen egy nagy biztonsági másolat visszaállítása, ill. a munkaterhelés korszerűsítése. Rendelkezik pillanatképekkel és külső biztonsági másolatokkal ezekről a pillanatképekről, de ezek csak a kötetekre vonatkoznak, így más erőforrások mentéséhez továbbra is szüksége lesz valamire, mint a Velero. A biztonsági mentések és visszaállítások nagyon megbízhatóak, de illetlenül lassúak. Komolyan, hihetetlenül lassú. A processzorhasználat és a rendszerterhelés gyakran megugrik, ha közepes mennyiségű adattal dolgozik a Longhornban. Van egy kényelmes műszerfal a Longhorn kezeléséhez. Már mondtam, hogy szeretem a Longhornt, de még dolgozni kell rajta.
A StorageOS az első fizetős termék a listán. Van egy fejlesztői verziója, korlátozottan 500 GB-os menedzselt tárhellyel, de szerintem a csomópontok számának nincs korlátozása. Az értékesítési osztály azt mondta, hogy ha jól emlékszem, a költség havi 125 dollártól kezdődik 1 TB-ért. Van egy alap műszerfal és egy kényelmes CLI, de valami furcsa történik a teljesítménnyel: bizonyos benchmarkokban egészen tisztességes, de a hangerő-tesztben egyáltalán nem tetszett a sebesség. Általában véve nem tudom, mit mondjak. Szóval nem sokat értettem. Itt nincsenek külső biztonsági mentések, és a kötetek biztonsági mentéséhez a Velero-t és a Restic-et is használnia kell. Furcsa, mert a termék fizetős. A fejlesztők pedig nem szívesen kommunikáltak a Slacken.
A Redditen a technikai igazgatójuktól értesültem Robinról. Még soha nem hallottam róla. Talán azért, mert ingyenes megoldásokat kerestem, de Robin fizetett. Van egy meglehetősen nagyvonalú ingyenes verziójuk 10 TB tárhellyel és három csomóponttal. Összességében a termék meglehetősen tisztességes és jó tulajdonságokkal rendelkezik. Van egy nagyszerű CLI, de a legmenőbb az, hogy pillanatképet készíthet és biztonsági másolatot készíthet a teljes alkalmazásról (az erőforrás-választóban ezt Helm-kiadásoknak vagy „flex alkalmazásoknak” nevezik), beleértve a köteteket és más erőforrásokat is, így a Velero nélkül is megteheti. És minden csodálatos lenne, ha nem egy apró részletre: ha visszaállít (vagy „importál”, ahogy Robinban hívják) egy alkalmazást egy új klaszteren - például katasztrófa utáni helyreállítás esetén - a helyreállítás, természetesen működik, de továbbra is tilos biztonsági másolatot készíteni az alkalmazásról. Ez egyszerűen nem lehetséges ebben a kiadásban, amint azt a fejlesztők megerősítették. Ez enyhén szólva is furcsa, különös tekintettel az egyéb előnyökre (például hihetetlenül gyors mentések és visszaállítások). A fejlesztők azt ígérik, hogy a következő kiadásig mindent kijavítanak. A teljesítmény általában jó, de észrevettem egy furcsaságot: ha a benchmarkot közvetlenül a gazdagéphez csatlakoztatott köteten futtatom, az olvasási sebesség sokkal gyorsabb, mintha ugyanazt a kötetet futtatnám a podból. Minden más eredmény azonos, de elméletileg nem lehet különbség. Bár dolgoznak rajta, engem is idegesített a visszaállítás és a biztonsági mentés probléma - azt hittem végre megtaláltam a megfelelő megoldást, és még akkor is hajlandó voltam fizetni érte, ha több helyre vagy több szerverre volt szükségem.
Nincs itt sok mondanivalóm. Ez egy fizetős termék, ugyanolyan jó és drága. A teljesítmény egyszerűen lenyűgöző. Ez az eddigi legjobb mutató. Slack azt mondta, hogy az ár havi 205 dollártól indul csomópontonként, amint azt a Google GKE Marketplace-jén feltüntették. Nem tudom, hogy olcsóbb lesz-e, ha közvetlenül veszed. Ezt egyébként nem engedhetem meg magamnak, ezért nagyon-nagyon csalódott voltam, hogy a fejlesztői licenc (1 TB-ig és 3 csomópontig) gyakorlatilag használhatatlan a Kubernetesnél, hacsak nem elégszik meg a statikus kiépítéssel. Reméltem, hogy a próbaidőszak végén a mennyiségi licenc automatikusan fejlesztőire vált, de ez nem történt meg. A fejlesztői licenc csak közvetlenül a Dockerrel használható, a Kubernetes konfigurációja pedig nagyon nehézkes és korlátozott. Természetesen jobban szeretem a nyílt forráskódot, de ha lenne rá pénzem, mindenképp a Portworxet választanám. Eddig a teljesítménye egyszerűen nem hasonlítható össze más opciókkal.
Ezt a részt a bejegyzés megjelenése után adtam hozzá, amikor az egyik olvasó a Linstor kipróbálását javasolta. Kipróbáltam és tetszett! De még mélyebbre kell ásnunk. Most már elmondhatom, hogy a teljesítmény nem rossz (a benchmark eredményeket alább csatoltam). Lényegében ugyanazt a teljesítményt kaptam, mint a lemezen közvetlenül, mindenféle többletköltség nélkül. (Ne kérdezd, hogy a Portworx-nek miért vannak jobb számai, mint közvetlenül a meghajtó benchmark. Fogalmam sincs. Magic, azt hiszem.) Szóval a Linstor eddig nagyon hatékonynak tűnik. Nem olyan nehéz telepíteni, de nem is olyan egyszerű, mint más lehetőségek. Először telepítenem kellett a Linstort (kernelmodul és eszközök/szolgáltatások), és be kellett állítani az LVM-et a Kubernetesen kívüli vékony kiépítéshez és pillanatkép-támogatáshoz, közvetlenül a gazdagépen, majd létre kellett hoznom a Kubernetes tárhely használatához szükséges erőforrásokat. Nem tetszett, hogy nem működik CentOS-en, és Ubuntut kellett használnom. Nem vészes persze, de egy kicsit bosszantó, mert a dokumentáció (ami egyébként kiváló) több olyan csomagot is említ, amelyek nem találhatók meg a megadott Epel tárolókban. A Linstornak vannak pillanatképei, de nem telephelyen kívüli biztonsági mentések, így itt is Velero-t kellett használnom Restic-el a kötetek mentéséhez. Fájlszintű biztonsági mentések helyett inkább a pillanatképeket részesítem előnyben, de ez is elviselhető, ha a megoldás hatékony és megbízható. A Linstor nyílt forráskódú, de fizetett támogatással rendelkezik. Ha jól értem, akkor is korlátozás nélkül használható, ha nincs támogatási szerződésed, de ezt tisztázni kell. Nem tudom, hogy a Linstor mennyire tesztelt Kubernetesen, de maga a tárolóréteg a Kubernetesen kívül van, és úgy tűnik, a megoldás nem tegnap jelent meg, így valószínűleg már tesztelték valós körülmények között. Van itt olyan megoldás, ami miatt meggondolom magam, és visszamegyek a Kuberneteshez? Nem tudom. Még mélyebbre kell ásnunk és tanulmányoznunk kell a replikációt. Lássuk. De az első benyomás jó. Határozottan szívesebben használnám a saját Kubernetes-fürtjeimet a Heroku helyett, hogy nagyobb szabadságom legyen és új dolgokat tanuljak. Mivel a Linstor telepítése nem olyan egyszerű, mint a többi, hamarosan írok róla egy bejegyzést.
Benchmarkok
Sajnos nem sok jegyzetet készítettem az összehasonlításról, mert nem gondoltam volna, hogy írok róla. Csak az alapvető fio benchmarkok eredményei vannak, és csak az egy csomópontos fürtökhöz, így még nincsenek számok a replikált konfigurációkhoz. De ezekből az eredményekből hozzávetőleges képet kaphat arról, hogy mire számíthat az egyes opcióktól, mivel ugyanazon felhőszervereken hasonlítottam össze őket, 4 mag, 16 GB RAM és további 100 GB-os lemez a tesztelt kötetekhez. Mindegyik megoldásnál háromszor futtattam le a benchmarkokat, és kiszámoltam az átlagos eredményt, plusz minden terméknél visszaállítottam a szerverbeállításokat. Ez az egész teljesen tudománytalan, csak hogy általános képet adjak. Más teszteknél 38 GB-nyi fotót és videót másoltam a kötetről, hogy teszteljem az olvasást és az írást, de sajnos nem mentettem el a számokat. Röviden: a Portworkx sokkal gyorsabb volt.
A mennyiségi viszonyítási alaphoz ezt a jegyzéket 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ályokkal, majd lefuttattam a munkát fio-val a színfalak mögött. 1 GB-ot használtam, hogy megbecsüljem a teljesítményt, és ne várjak túl sokáig. Íme az eredmények:
Minden mutatónál a legjobb értéket zölddel, a legrosszabbat pedig pirossal emeltem ki.
Következtetés
Mint látható, a legtöbb esetben a Portworx jobban teljesített, mint mások. De nekem drága. Nem tudom mennyibe kerül a Robin, de van egy remek ingyenes verziójuk, szóval aki fizetős terméket szeretne, az ki is próbálhatja (remélem hamarosan visszaállítással és biztonsági mentéssel megoldják a problémát). A három ingyenes közül az OpenEBS-sel volt a legkevesebb problémám, de a teljesítménye borzalmas. Kár, hogy nem mentettem el több találatot, de remélem, a számok és a megjegyzéseim segítenek.
Forrás: will.com