Nagy rajongója vagyok a Ceph-nek, a nyílt forráskódú, masszívan skálázható, szoftveresen definiált tárolási megoldásnak. Az öngyógyító képessége és az egyébként traumatikus klasztereseményekkel való megbirkózás képessége (ó, elvesztettél egy csomópontot? nem probléma!), valamint az egyetlen hibapontok hiánya miatt a kedvencem.
Az alábbiakban három egyszerű alapelvet ismertetek, amelyek segíthetnek a nagy vagy kis klaszterek tervezésében.
Ha a fő hangsúlyt az egy megabájtnyi tárhelyre jutó dollár adja, akkor természetesen a lehető legtöbb lemezt befogadni képes szerverek és a lehető legnagyobb lemezek felé húzhat.
Azzal itt óvatosan kell bánni. Van néhány megfontolás a “keskeny és mély” fürtökkel kapcsolatban:
- Minden csomópont a fürt adatainak nagyobb százalékát tárolja. Példa: Egy három csomópontból álló fürtben minden csomópont az adatok 33%-át tartalmazza. Egy tíz csomópontos fürtben ez csomópontonként csak 10%. Egyetlen csomópont elvesztése egy kis fürtben lényegesen több adatmigrációt eredményez, különösen, ha a fürt kezd megtelni, és potenciálisan kiesést, ha nem megfelelően konfigurálta a fürtje teljes és majdnem teljes arányait.
- Kényszeríti a nagyobb hálózati forgalmat kevesebb csomópontra. A Ceph egy hálózati alapú tárolórendszer, így kevesebb csomóponttal kevesebb NIC-re kényszeríti a nagy ügyfélforgalmat. Ez annál rosszabb lesz, minél több lemez van csomópontonként, mivel több OSD versenyez a korlátozott sávszélességért. Ami még rosszabb, a helyreállítási események során a helyreállítási forgalom versenyez az ügyfél I/O-jával a hálózaton, ami tovább rontja a felhasználói élményt.
- A csomópontonkénti nagy lemezszám esetén a lemezvezérlő szűk keresztmetszetet jelenthet, ha nem rendelkezik elegendő sávszélességgel az összes lemez teljes sebességű szállítására.
- Növekvő helyreállítási és gyógyítási idő egy teljes csomópont elvesztése esetén, mivel több adatot kell replikálni és helyreállítani.
A fürtök összteljesítménye nagyon jól skálázódik a csomópontok számának növekedésével. Itt talál egy összehasonlítást egy 3 csomópontos vs. 5 csomópontos fürtről a BlueStore segítségével.
Ha nagy fürtre törekszik, álljon ellen a kísértésnek, hogy az összes lemezt a lehető legkevesebb csomópontba pakolja.
Összefoglalva:
- A Ceph nagyon jól skálázódik a csomópontok számának növekedésével.
- Ha túl kevés csomópont van a fürtben, a fürt adataiból több kerül minden egyes csomópontra, ami növeli a helyreállítási I/O-t és a helyreállítási időt.
- Elkezdhet akár három csomóponttal is, de ha megengedheti magának, hogy a lemezeket több csomópontra ossza szét, akkor jobb, ha ezt teszi.
Legyen nagyvonalú a hálózattal
Nincs értelme gyors adathordozókat tenni egy szerverbe, majd 1 GbE hálózati kapcsolattal megbénítani. A termeléshez legalább 10 GbE-re törekedjen, és még jobb, ha a nagyobb sávszélesség érdekében több 10 Gb-os, LACP (Link Aggregation Control Protocol) protokollal összekapcsolt interfészre törekszik. A Ceph egy hálózati alapú tárolórendszer, így az egyik dolog, ami a fürtből nem hiányozhat, az a hálózati sávszélesség.
A nyilvános hálózatot mindig különítse el a belső fürthálózattól. A nyilvános hálózat az ügyfélforgalmat, míg a belső hálózat az OSD-k közötti heartbeat, replikációs és helyreállítási forgalmat fogja bonyolítani. Ha meg tudja kímélni a hálózati kártyákat, vigye ezt a két hálózatot külön interfészeken keresztül. A kettő szétválasztása javítja az ügyfelek reakciókészségét a helyreállítási események során, és segít a helyreállítási események gyorsabb befejezésében, mivel a helyreállítási I/O nem versenyez az ügyfél I/O-jával ugyanazon a hálózati kártyán.
Ne feledje, hogy a belső hálózat szállítja a replikációs forgalmat, így minden írás a nyilvános hálózaton (n-1) írást okoz a belső hálózaton, ahol n a replikák száma. A Ceph csak akkor nyugtázza az írást a kliensnek, ha az összes replika journal/WAL-jába beíródott – tehát nem akarod, hogy a replikációs írások szűk keresztmetszetet képezzenek a hálózaton. Ha nagymértékben használja a replikált poolokat, fontolja meg a fürthálózat méretezését úgy, hogy az n-1-szer nagyobb legyen, mint a nyilvános hálózat.
Végül a redundancia érdekében gondoskodjon arról, hogy a csomópontokat redundáns top of rack switchekhez kábelezze. Nem akar egy egész csomópontot – vagy csomópontok csoportját – elveszíteni, mert egyetlen kapcsoló meghibásodott!
Összefoglalva:
- 10Gbit Ethernet a termeléshez legalább.
- Válassza szét a nyilvános és a fürthálózatot, ideális esetben különböző hálózati kártyákra, de legalábbis különböző VLAN-okba/alhálózatokba.
- Emlékezzen a replikált adatokra vonatkozó (n-1) ökölszabályra – fontolja meg a belső hálózat méretezését úgy, hogy az n-1-szer nagyobb legyen, mint a nyilvános.
- Ne felejtsen el kábelezni a redundancia érdekében, és az operációs rendszer szintjén helyesen létrehozni a kötéseket.
- És extraként: ne feledkezzen meg a jumbo keretekről az interfészein!
Flash adathordozó a BlueStore metaadatokhoz.
A Ceph csak akkor nyugtázza az írást az ügyfélnek, ha az adatok az elsődleges OSD írási naplójába (WAL) és az összes replika WAL-jába íródtak. Tehát minél gyorsabb az írás a WAL-ba, annál gyorsabban nyugtázza a Ceph az írást, és annál jobb az írási IOPS az ügyfél számára.
A WAL-ok és ideális esetben a BlueStore RocksDB metaadatok a lehető leggyorsabb adathordozón legyenek – legalább SSD-n, és lehetőleg NVMe-n. Ha teljes HDD-s fürtöt épít, erősen fontolja meg, hogy csomópontonként egy kicsit többet költ, és legalább két gyors médiaeszközzel bővíti a metaadatok és a WAL számára.
A gyors médiaeszköz szűk keresztmetszetének elkerülése érdekében vegye figyelembe az adatlemezek tartós írási sebességét, és hasonlítsa össze a gyors eszköz tartós írási sebességével. Ha a HDD-je 100MB/s tartós írásra képes, és az SSD-je 500MB/s tartós írásra képes, akkor 4-5 OSD-nél több SSD-nként, és az SSD szűk keresztmetszetet fog jelenteni az írásoknál. Az NVMe tökéletes erre a felhasználási esetre, mivel a fenntartható írási sebességük elérheti a gigabájt/másodperc értéket.
Végül pedig mindig legyen csomópontonként egynél több SSD/NVMe eszköz a metaadatok/WAL számára, hogy ne veszítse el az összes OSD-t a csomóponton, ha egy metaadat-eszköz meghibásodik.
Összefoglalva:
- A Ceph akkor nyugtázza az írást egy ügyfél számára, ha az elsődleges OSD WAL-jébe és az összes replika WAL-jébe íródott. Ezt azért teszi, hogy megőrizze az adatok integritását.
- A WAL-nak és a RocksDB-nek a lehető leggyorsabb adathordozón kell lennie – ideális esetben NVMe -, hogy a kliens a lehető leggyorsabban kapjon választ.
- Ne írja túl a gyors eszközöket a WAL/RocksDB számára. Ha így teszel, akkor csak a szűk keresztmetszetet helyezed át a gyors eszközödre.
- Legyen egynél több gyors eszközöd, hogy ne veszítsd el az összes OSD-t egy csomóponton, ha a WAL-eszközöd meghibásodik.
Összefoglalás
A Ceph egy hálózati alapú, szoftveresen definiált tárolórendszer, amely horizontálisan kivételesen jól skálázható. A fentiekben csak néhány alapelvet ismertettünk, amelyek segítenek egy nagy teljesítményű rendszer összeállításában – ne menj túl szűk vagy mélyre, tartsd a fürtöt sávszélességgel ellátva, és használj gyors adathordozókat a metaadatok és a WAL számára.