A Rook egyre növekvő népszerűsége miatt szeretnék beszélni a hátulütőiről és a problémákról, amelyekkel szembesülhet.
Rólam: Ceph adminisztrációs tapasztalat a hammer verzió óta, közösségi alapító. a Telegramon.
Annak érdekében, hogy ne legyek alapos, hivatkozni fogok a Habr-on (a rangsor alapján!) lévő problémákra a ceph-el kapcsolatban. Ezekkel a problémákkal én is találkoztam. Az anyagfelhasználás linkje a poszt végén található.
A Rook posztban nem véletlenül említjük a ceph-t — a Rook lényegében a ceph Kubernetes-be csomagolva, tehát örökli annak összes problémáját. A ceph problémáival kezdjünk.
A klaszter kezelésének egyszerűsítése
A Rook egyik előnye a ceph kényelmes kezelése Kubernetes-en keresztül.
Ugyanakkor a ceph több mint 1000 paramétert tartalmaz a konfiguráláshoz, míg a rook-on keresztül csak ezek egy kisebb részét módosíthatjuk.
Példa a Luminous-ra
> ceph daemon mon.a config show | wc -l
1401
A Rook kényelmes módot kínál a ceph telepítésére és frissítésére.
A ceph Rook nélkül történő telepítése nem jelent problémát — az ansible playbook 30 perc alatt elkészül, de a frissítés során rengeteg probléma adódik.
Idézet a Krok posztjából
Példa: a crush tunables helytelen működése a hummer-ről jewel-re történő frissítés után.
> ceph osd crush show-tunables
{
…
«straw_calc_version»: 1,
«allowed_bucket_algs»: 22,
«profile»: «ismeretlen»,
«optimal_tunables»: 0,
…
}
De még a kisebb verziókon belül is akadnak problémák.
Példa: a 12.2.6-os frissítés a klasztert health err állapotba és lényegében hibás PG állapotba hozza.
Ne frissítse, várjon és teszteljen? De úgy tűnik, a Rook-ot a frissítések kényelme érdekében használjuk.
A klaszter disaster recovery nehézségei a Rook-ban
Példa: Az OSD leáll, hibákat dobálva. Gyanítja, hogy a probléma a konfiguráció egyik paraméterében van, szeretné megváltoztatni a konfigurációt egy adott démon számára, de nem tudja, mert Kubernetes-ét használ, és DaemonSet-tel rendelkezik.
Nincs alternatíva. A ceph tell osd.Num injectargs nem működik — az OSD le van állva.
A debug nehézségei
Néhány beállítás és teljesítményteszt érdekében közvetlenül az osd démon aljzatához kell csatlakozni. Rook esetén először meg kell találni a szükséges konténert, majd belépni abba, felfedezni a debug tooling hiányát, és nagyon csalódottnak lenni.
Az OSD folyamatos emelkedésének nehézségei
Példa: Az OSD OOM miatt leáll, megkezdődik az újraosztás, ezután a következők is leállnak.
Megoldás: Az OSD-t egyesével indítsa, várjon, amíg teljesen csatlakozik a klaszterhez, majd indítsa el a következőket. (További információk a Ceph. A katasztrófák anatómiája című jelentésben.)
Bare metal telepítés esetén ezt kézzel kell elvégezni, Rook esetén egy OSD-vel a noden általában nincsenek problémák, de ha OSD > 1 van a noden, akkor problémák léphetnek fel a sorrendiség miatt.
Természetesen ezek megoldhatók, de a Rookot a leegyszerűsítés érdekében használjuk, míg bonyolultságot kapunk.
A ceph démonok limitjeinek kiválasztásának nehézsége
Bare metal telepítés esetén a szükséges erőforrások könnyen kiszámíthatók a klaszterhez — léteznek képletek és kutatások. Gyengébb CPU-k használata esetén mégis számos teljesítménytesztet kell elvégeznie, hogy megértse mi a Numa, de ez még mindig egyszerűbb, mint a Rook esetében.
Rook esetében nemcsak a memóriakorlátok vannak, amelyeket meg lehet határozni, hanem a CPU korlátozásának beállításának kérdése is felmerül.
Itt pedig sokat kell dolgoznia a teljesítménytesztekkel. Ha a korlátokat alábecsüli, akkor lassú klasztert kap, ha unlimitet állít be, akkor aktív CPU használatot kap a rebalance során, ami rosszul hat a Kubernetesben futó alkalmazásaira.
Hálózati interakciós problémák v1
Ceph esetén 2x10 Gb-os hálózat használata ajánlott. Az egyiket a kliensforgalomra, a másikat pedig a ceph szolgáltatási igényeire (rebalance) használják. Ha bare metal ceph-t használ, akkor ezt a felosztást könnyen beállíthatja, ha Rookkal él, akkor a hálózatok közötti felosztás problémákat okozhat, mivel nem minden klaszter konfiguráció engedi meg a két különböző hálózat betáplálását egy podba.
Hálózati interakciós problémák v2
Ha nem választja szét a hálózatokat, akkor rebalance során a ceph forgalma elárasztja az egész csatornát, és a Kubernetesben futó alkalmazásai akadozni fognak vagy leállnak. Csökkentheti a ceph rebalance sebességét, de ezzel a hosszabb rebalance miatt megnő a kockázata annak, hogy a második node kilép a klaszterből a lemezek vagy OOM miatt, ami garantált read only állapotot eredményez a klaszterre.
Hosszú rebalance — hosszú alkalmazásakadás
Idézet a Ceph. A katasztrófák anatómiája című bejegyzésből.
A tesztklaszter teljesítménye:
A 4 Kbyte méretű írási művelet 1 ms-ot vesz igénybe, 1000 művelet/másodperc teljesítmény 1 szálon.
A 4 Mbyte (objektumméret) méretű művelet 22 ms-ot vesz igénybe, 45 művelet/másodperc teljesítmény.
Tehát, amikor az egyik doménből három meghibásodik, a klaszter egy ideig degradált állapotban marad, és a forró objektumok fele különböző verziók között oszlik meg, így a feljegyzések fele kényszerített helyreállítással kezdődik.
A kényszerített helyreállítás idejét körülbelül így számítjuk ki — feljegyzési műveletek a degradált objektumban.
Először 4 MB-ot olvasunk 22 ms alatt, írunk 22 ms-ot, majd 1 ms alatt 4 kB adatot. Tehát összesen 45 ms egy feljegyzés végrehajtásához a degradált objektumban SSD-n, amikor a normál teljesítményünk 1 ms volt — a teljesítmény csökkenése 45-szörös.
Minél nagyobb a degradált objektumok aránya, annál ijesztőbb lesz a helyzet.
Kiderül, hogy a rebalance sebessége kritikus a klaszter helyes működéséhez.
Szerver-specifikus beállítások a ceph-hez
A ceph speciális hoszt tuningot igényelhet.
Példa: sysctl beállítások és a JumboFrame, ezek egy része negatívan befolyásolhatja a payload-ját.
A Rook valódi szükséglete kérdéses marad
Ha felhőben dolgozik, rendelkezik a felhőszolgáltatójától származó tárolóval, ami sokkal kényelmesebb.
Ha a saját szerverein van, a ceph kezelése könnyebb lesz Kubernetes nélkül.
Kölcsönöz szervereket valamelyik olcsóbb hoszting szolgáltatótól? Akkor sok izgalom vár Önre a hálózattal, a késésekkel és a sávszélességgel kapcsolatban, ami nyilvánvalóan negatívan befolyásolja a ceph-t.
Összesen: A Kubernetes bevezetése és a tárolás bevezetése külön feladatok, külön bemenetekkel és különböző megoldási lehetőségekkel — ezek keverése veszélyes trade-off-ot jelenthet az egyik vagy a másik érdekében. Az ilyen döntések kombinálása nagyon nehéz lesz a tervezési fázisban, és még van egy üzemelési időszak is.
Felhasznált irodalom:
És Ön a Cephről beszél… de tényleg olyan jó?
Ceph. A katasztrófa anatómiája
Forrás: habr.com
