Amikor az adatok mennyisége meghaladja egy lemez kapacitását, ideje elgondolkodni a RAID-ről. Gyerekként gyakran hallottam az idősebbektől: „Egyszer a RAID a múlté lesz, az objektumtárolók elárasztják a világot, te pedig még csak nem is tudod, mi az a CEPH,” - ezért az első dolog, amit a felnőtt életemben tettem, a saját klaszterem létrehozása volt. Kísérletem célja az volt, hogy megismerjem a ceph belső felépítését és megértsem a használati kereteit. Mennyire indokolt a ceph bevezetése a közepes méretű vállalkozásoknál, és a kisvállalkozásoknál? Pár év használat és néhány visszafordíthatatlan adatvesztés után kezdtem megérteni a finomságokat, hogy nem minden olyan egyértelmű. A CEPH sajátosságai akadályokat teremtenek a széles körű elterjedésében, és emiatt a kísérletek zsákutcába jutottak. Az alábbiakban bemutatásra kerülnek az összes elvégzett lépés, az elért eredmény és a levont következtetések. Ha a hozzáértők megosztanák tapasztalataikat és tisztáznák egyes pontokat – hálás lennék.
Megjegyzés: a kommentelők súlyos hibákat emeltek ki néhány feltételezésben, amelyek a cikk teljes átdolgozását igénylik.
CEPH Stratégia
A CEPH klaszter tetszőleges számú K lemezt egyesít tetszőleges méretben, és az adatokat rajtuk tárolja, minden darabot (alapértelmezés szerint 4 MB) N alkalommal megismételve.
Nézzük meg a legegyszerűbb esetet, amikor két azonos lemezt használunk. Ezekből vagy RAID 1-et, vagy N=2 klasztert hozhatunk létre — az eredmény ugyanaz lesz. Ha három lemezről van szó, és ezek különböző méretűek, akkor könnyen létrehozható egy N=2 klaszter: az adatok egy része az 1-es és 2-es lemezen lesz, egy másik rész az 1-es és 3-as lemezen, a harmadik pedig a 2-es és 3-as lemezen, míg a RAID létrehozása nem lehetséges (létrehozható ilyen RAID, de ez már torzítás). Ha még több lemez van, akkor RAID 5 létrehozása is lehetséges, a CEPH rendelkezik az analógjával — erasure_code, amely ellentmond a fejlesztők korábbi koncepcióinak, és ezért nem kerül megvitatásra. A RAID 5 azt feltételezi, hogy kevés számú lemez van, és mindegyik jó állapotban van. Egy lemez meghibásodása esetén a többinek ki kell tartania addig, amíg ki nem cserélik a lemezt és az adatokat vissza nem állítják rá. A CEPH viszont, ha N≥3, bátorítja a régi lemezek használatát, különösen, ha néhány jó lemezt tartanak egy adatok másolatának tárolására, míg a fennmaradó két-három másolatot sok régi lemezen tárolják, az információ biztonságban lesz, mivel amíg az új lemezek működnek — nincsenek problémák, és ha az egyik meghibásodik, a három, öt évnél régebbi lemez egyidejű meghibásodása, előnyösen különböző szerverekből — rendkívül valószínűtlen esemény.
A másolatok elosztásának van egy árnyalata. Alapértelmezés szerint úgy tekintjük, hogy az adatok egy nagyobb mennyiségre (~100 lemezenként) oszlanak meg PG elosztási csoportokból, amelyeket bizonyos lemezeken tükröznek. Tegyük fel, hogy K=6, N=2, így ha két bármilyen lemez meghibásodik, az adatok garantáltan elvesznek, mivel a valószínűségelmélet szerint legalább egy PG található, amely pontosan ezen a két lemezen helyezkedik el. Ha egy csoport elveszik, akkor az egész pool adatai elérhetetlenekké válnak. Ha azonban a lemezeket három párra osztjuk, és megengedjük, hogy az adatokat csak az egy páron belüli lemezek tárolják, akkor ez az elosztás is ellenáll egy bármelyik lemez meghibásodásának, de ha két lemez hibásodik meg, az adatvesztés valószínűsége nem 100%, hanem csak 3/15, és még három lemez meghibásodása esetén is csak 12/20. Itt látható, hogy az adatok elosztásának entrópiája nem segíti a hibatűrést. Azt is észrevehetjük, hogy a fájlszerverek esetében a szabad operatív memória jelentősen növeli a válaszidőt. Minél több memória van minden egyes csomópontban, és minél több memória van az összes csomópontban — annál gyorsabb lesz. Ez kétségtelen előny a klaszter esetében az egyetlen szerverhez képest, nem is beszélve a hardver NAS-ról, amelybe nagyon kis memória mennyiséget építenek be.
Ebből következik, hogy a CEPH jó módja a régi berendezések minimális befektetéseivel megbízható adattároló rendszer kialakításának, akár több tucat TB esetén is, a skálázhatóság lehetőségével (itt természetesen szükség lesz költségekre, de azok kicsik a kereskedelmi tároló rendszerekhez képest).
Klaszter megvalósítása
Kísérletként vegyünk egy selejtezett számítógépet, Intel DQ57TM + Intel Core i3 540 + 16 GB RAM. Négy 2 TB-os lemezt szervezünk RAID10 hasonlóságban, a sikeres teszt után hozzáadunk egy második csomópontot és ugyanennyi lemezt.
Linux telepítése. A disztribúciótól elvárt a testreszabhatóság és a stabilitás. A Debian és a Suse megfelel a követelményeknek. A Suse telepítője rugalmasabb, lehetővé téve bármely csomag letiltását; sajnos nem tudtam megérteni, hogy mely csomagokat lehetne eltávolítani anélkül, hogy a rendszer károsodna. Telepítjük a Debiant a debootstrap buster segítségével. A min-base opció egy nem működő rendszert telepít, amelyből hiányoznak a driverek. A teljes verzióhoz képest a méretkülönbség nem olyan nagy, hogy megérje foglalkozni vele. Mivel a munka fizikai gépen zajlik, szeretnénk pillanatképeket készíteni, mint a virtuális gépeknél. Ezt az LVM vagy a btrfs (vagy xfs, vagy zfs — a különbség nem jelentős) kínálja. Az LVM pillanatképei nem a legerősebb pontja. Btrfs-t telepítünk. A betöltő pedig az MBR-ben lesz. Nincs értelme 50 MB FAT partícióval szennyezni a lemezt, amikor ezt 1 MB területre is el lehet helyezni a partíciós táblában, és az egész teret a rendszernek szentelni. A lemezen 700 MB-ot foglalt el. A SUSE alaptelepítése mennyi volt — nem emlékszem, úgy tűnik, kb. 1.1 vagy 1.4 GB.
CEPH telepítése. Figyelmen kívül hagyjuk a 12-es verziót a debian repóban, és közvetlenül a 15.2.3-as verzióval az oldalról csatlakozunk. Követjük a "CEPH kézi telepítése" szakaszból származó utasításokat a következő megjegyzésekkel:
- A repó csatlakoztatása előtt telepíteni kell a gnupg wget ca-certificates csomagokat.
- A repó csatlakoztatása után, de a klaszter telepítése előtt, a következő csomagok telepítése elmaradt: apt -y —no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr.
- A CEPH telepítésekor érthetetlen okokból megpróbálkozik a lvm2 telepítésével. Elvileg nem kár érte, de a telepítés hibaüzenettel zárul, ezért a CEPH sem kerül telepítésre.
Ez a javítás segített:
cat <> /var/lib/dpkg/status Package: lvm2 Status: install ok installed Priority: important Section: admin Installed-Size: 0 Maintainer: Debian Adduser Developers Architecture: all Multi-Arch: foreign Version: 113.118 Description: No-install EOF
A klaszter áttekintése
ceph-osd — felelős az adatok tárolásáért a lemezen. Minden lemezhez egy hálózati szolgáltatás indul el, amely fogadja és végrehajtja a műveleteket olvasásra vagy írásra az objektumokba. A lemezen két partíció jön létre. Az egyik a klaszterről, a lemez számáról és a klaszter kulcsairól tartalmaz információt. Ez az 1 KB méretű információ egyszer létrejön a lemez hozzáadásakor, és azóta soha nem változott. A második partíció nem tartalmaz fájlrendszert, és a CEPH binális adatait tárolja. A korábbi verziók automatikus telepítése xfs partíciót hozott létre 100 MB méretben a rendszerszolgáltatások számára. A lemezt MBR-re konvertáltam, és csak 16 MB-ot jelöltem ki — a szolgáltatás nem panaszkodik. Gondolom, az xfs problémamentesen helyettesíthető lenne ext-nel is. Ezt a partíciót a \/var\/lib\/…-ben szerelik fel, ahol a szolgáltatás olvassa az OSD információt, és megtalálja a hivatkozást a blokkeszközre, ahol a binális adatok tárolódnak. Elméletileg azonnal elhelyezhetők a segédprogramok a \/var\/lib\/…-ben, míg a lemez teljes egészében az adatok számára van fenntartva. Az OSD létrehozásakor a ceph-deploy automatikusan létrehoz egy szabályt a partíció \/var\/lib\/…-be történő felszerelésére, és jogosultságokat ad a ceph felhasználónak a szükséges blokkeszköz olvasására. Kézi telepítéskor ezt magunknak kell megtennünk, erről a dokumentáció nem tartalmaz információt. Ezenkívül ajánlott megadni az osd memory target paramétert, hogy elegendő fizikai memória álljon rendelkezésre.
ceph-mds. Alapvetően a CEPH — objektumtárolás. A blokktárolás lehetősége összefoglalja, hogy mindegyik 4 MB méretű blokkot objektumként tárolunk. Ugyanezen a elven működik a fájltárolás. Két tároló jön létre: az egyik a metadatákhoz, a másik az adatokhoz. Ezeket egy fájlrendszerbe egyesítik. Ekkor jön létre valamilyen feljegyzés, tehát ha töröljük a fájlrendszert, de megőrizzük mindkét tárolót, akkor nem lehet azt helyreállítani. Van eljárás fájlok blokkba történő kiemelésére, de ezt nem teszteltem. A fájlrendszerhez való hozzáférésért a ceph-mds szolgáltatás felelős. Minden fájlrendszerhez külön példányra van szükség a szolgáltatásból. Létezik egy "index" opció, amely lehetővé teszi, hogy több fájlrendszert hozzunk létre egy példányban — ezt sem teszteltem.
a ceph-mon — ez a szolgáltatás tárolja a klaszter térképét. Tartalmazza az összes OSD információját, a PG elosztásának algoritmusát OSD-n, és ami a legfontosabb, információt az összes objektumról (e mechanizmus részletei számomra érthetetlenek: van egy könyvtár /var/lib/ceph/mon/.../store.db, amelyben egy nagy fájl található — 26MB, a klaszterben 105K objektummal, ez pedig kissé több mint 256 byte objektumonként - azt gondolom, hogy a monitor tárolja az összes objektum és PG listáját, amelyben ezek helyezkednek el). E könyvtár megsérülése az összes adathoz való hozzáférés elvesztését eredményezi a klaszterben. Innen a következtetés, hogy a CRUSH megmutatja, hogyan oszlanak meg a PG-k az OSD-ken, míg az objektumok hol helyezkednek el a PG-k között — központosítva tárolódnak az adatbázisban, bármennyire is próbálnak a fejlesztők elkerülni ezt a szót. Ennek következményeként, először is, nem tudunk rendszert telepíteni USB stickre RO módban, mivel az adatbázisba állandó írás történik, szükséges egy további lemez ezekhez (valószínűleg nem több mint 1 GB), másodszor, valós időben szükség van ennek az adatbázisnak a másolatára. Ha több monitor van, akkor a hibatűrőség automatikusan biztosított, de esetünkben a monitor egy, maximum kettő. Van egy elméleti eljárás a monitor helyreállítására az OSD adatai alapján, háromszor fordultam ehhez különböző okokból, és háromszor nem volt hibaüzenet, ahogy adatok sem. Sajnos ez a mechanizmus nem működik. Vagy egy mini partíciót használunk az OSD-n, és RAID-et állítunk össze az adatbázis tárolásához, ami biztosan nagyon rosszul érinti a teljesítményt, vagy legalább két megbízható fizikai adathordozót különítünk el, lehetőleg USB-t, hogy a portokat ne foglaljuk el.
rados-gw — exportálja az objektumtárolót az S3 protokoll és hasonlók szerint. Számos medencét hoz létre, nem világos, miért. Különösebben nem kísérleteztem.
ceph-mgr — ezen szolgáltatás telepítésekor számos modul indul el. Az egyik — a letilthatatlan autoscale. Ez arra törekszik, hogy fenntartja a megfelelő PG/OSD számot. Ha kézzel szeretnénk kezelni az arányt, megtilthatjuk a skálázást minden medencére, de ebben az esetben a modul 0-val való osztás miatt összeomlik, és a klaszter állapota ERROR-ra vált. A modult Pythonban írták, és ha a szükséges sort kommenteljük, az a leállításához vezet. A részletek eszembe jutása fárasztó.
Felhasznált források listája:
Szkriptek listázása:
A rendszer telepítése debootstrap segítségével
blkdev=sdb1
mkfs.btrfs -f /dev/$blkdev
mount /dev/$blkdev /mnt
cd /mnt
for i in {@,@var,@home}; do btrfs subvolume create $i; done
mkdir snapshot @/{var,home}
for i in {var,home}; do mount -o bind @${i} @/$i; done
debootstrap buster @ http://deb.debian.org/debian; echo $?
for i in {dev,proc,sys}; do mount -o bind /$i @/$i; done
cp /etc/bash.bashrc @/etc/
chroot /mnt/@ /bin/bash
echo rbd1 > /etc/hostname
passwd
uuid=`blkid | grep $blkdev | cut -d '"' -f 2`
cat < /etc/fstab
UUID=$uuid / btrfs noatime,nodiratime,subvol=@ 0 1
UUID=$uuid /var btrfs noatime,nodiratime,subvol=@var 0 2
UUID=$uuid /home btrfs noatime,nodiratime,subvol=@home 0 2
EOF
cat <> /var/lib/dpkg/status
Package: lvm2
Status: install ok installed
Priority: important
Section: admin
Installed-Size: 0
Maintainer: Debian Adduser Developers
Architecture: all
Multi-Arch: foreign
Version: 113.118
Description: No-install
Package: sudo
Status: install ok installed
Priority: important
Section: admin
Installed-Size: 0
Maintainer: Debian Adduser Developers
Architecture: all
Multi-Arch: foreign
Version: 113.118
Description: No-install
EOF
exit
grub-install --boot-directory=@/boot/ /dev/$blkdev
init 6
apt -yq install --no-install-recommends linux-image-amd64 bash-completion ed btrfs-progs grub-pc iproute2 ssh smartmontools ntfs-3g net-tools man
exit
grub-install --boot-directory=@/boot/ /dev/$blkdev
init 6Klónozási folyamat létrehozása
apt -yq install --no-install-recommends gnupg wget ca-certificates
echo 'deb https://download.ceph.com/debian-octopus/ buster main' >> /etc/apt/sources.list
wget -q -O- 'https://download.ceph.com/keys/release.asc' | apt-key add -
apt update
apt -yq install --no-install-recommends ceph-common ceph-mon
echo 192.168.11.11 rbd1 >> /etc/hosts
uuid=`cat /proc/sys/kernel/random/uuid`
cat < /etc/ceph/ceph.conf
[global]
fsid = $uuid
auth cluster required = cephx
auth service required = cephx
auth client required = cephx
mon allow pool delete = true
mon host = 192.168.11.11
mon initial members = rbd1
mon max pg per osd = 385
osd crush update on start = false
#osd memory target = 2147483648
osd memory target = 1610612736
osd scrub chunk min = 1
osd scrub chunk max = 2
osd scrub sleep = .2
osd pool default pg autoscale mode = off
osd pool default size = 1
osd pool default min size = 1
osd pool default pg num = 1
osd pool default pgp num = 1
[mon]
mgr initial modules = dashboard
EOF
ceph-authtool --create-keyring ceph.mon.keyring --gen-key -n mon. --cap mon 'allow *'
ceph-authtool --create-keyring ceph.client.admin.keyring --gen-key -n client.admin --cap mon 'allow *' --cap osd 'allow *' --cap mds 'allow *' --cap mgr 'allow *'
cp ceph.client.admin.keyring /etc/ceph/
ceph-authtool --create-keyring bootstrap-osd.ceph.keyring --gen-key -n client.bootstrap-osd --cap mon 'profile bootstrap-osd' --cap mgr 'allow r'
cp bootstrap-osd.ceph.keyring /var/lib/ceph/bootstrap-osd/ceph.keyring
ceph-authtool ceph.mon.keyring --import-keyring /etc/ceph/ceph.client.admin.keyring
ceph-authtool ceph.mon.keyring --import-keyring /var/lib/ceph/bootstrap-osd/ceph.keyring
monmaptool --create --add rbd1 192.168.11.11 --fsid $uuid monmap
rm -R /var/lib/ceph/mon/ceph-rbd1/*
ceph-mon --mkfs -i rbd1 --monmap monmap --keyring ceph.mon.keyring
chown ceph:ceph -R /var/lib/ceph
systemctl enable ceph-mon@rbd1
systemctl start ceph-mon@rbd1
ceph mon enable-msgr2
ceph status
# dashboard
apt -yq install --no-install-recommends ceph-mgr ceph-mgr-dashboard python3-distutils python3-yaml
mkdir /var/lib/ceph/mgr/ceph-rbd1
ceph auth get-or-create mgr.rbd1 mon 'allow profile mgr' osd 'allow *' mds 'allow *' > /var/lib/ceph/mgr/ceph-rbd1/keyring
systemctl enable ceph-mgr@rbd1
systemctl start ceph-mgr@rbd1
ceph config set mgr mgr/dashboard/ssl false
ceph config set mgr mgr/dashboard/server_port 7000
ceph dashboard ac-user-create root 1111115 administrator
systemctl stop ceph-mgr@rbd1
systemctl start ceph-mgr@rbd1OSD hozzáadása (rész)
apt install ceph-osd
osdnum=`ceph osd create`
mkdir -p /var/lib/ceph/osd/ceph-$osdnum
mkfs -t xfs /dev/sda1
mount -t xfs /dev/sda1 /var/lib/ceph/osd/ceph-$osdnum
cd /var/lib/ceph/osd/ceph-$osdnum
ceph auth get-or-create osd.0 mon 'profile osd' mgr 'profile osd' osd 'allow *' > /var/lib/ceph/osd/ceph-$osdnum/keyring
ln -s /dev/disk/by-partuuid/d8cc3da6-02 block
ceph-osd -i $osdnum --mkfs
#chown ceph:ceph /dev/sd?2
chown ceph:ceph -R /var/lib/ceph
systemctl enable ceph-osd@$osdnum
systemctl start ceph-osd@$osdnumÖsszefoglaló
A CEPH fő marketingelőnye a CRUSH — az adatok elhelyezésének számítási algoritmusa. A monitorok ezt az algoritmust terjesztik az ügyfelek felé, akik közvetlenül kérhetik a szükséges csomópontot és a kívánt OSD-t. A CRUSH biztosítja a centralizáltság hiányát. Ez egy kis fájl, amit akár ki is nyomtathatunk és fel is akaszthatunk a falra. A gyakorlat azt mutatta, hogy a CRUSH nem egy kimerítő térkép. Ha a monitorokat megsemmisítjük és újra létrehozzuk, miközben megőrizzük az összes OSD-t és a CRUSH-t, ez nem elegendő a klaszter helyreállításához. Ebből az következik, hogy minden monitoron tárolnak bizonyos metainformációkat az egész klaszterről. Ezek a metainformációk nem korlátozzák a klaszter méretét, de megkövetelik a megőrzésüket, ami kizárja a lemeztakarékosságot, ha a rendszert pendrive-ra telepítjük, és kizárja az olyan klasztere végrehajtását, amelyek kevesebb mint három csomópontból állnak. A fejlesztő agresszív politikája az opcionális funkciókkal szemben. Messze van a minimalizmustól. A dokumentáció szintje: „amire van, – már kösz, de nagyon, nagyon szegényes”. Az alacsony szintű szolgáltatásokkal való interakció lehetősége adott, de a dokumentáció túl felszínesen foglalkozik ezzel a témával, így inkább nem, mint igen. Szinte semmi esély a hibás állapotból való adatok helyreállítására.
További lépések: lemondani a CEPH-ról és használni egy banális többlemezes btrfs-t (vagy xfs-t, zfs-t), új információkat szerezni a CEPH-ról, hogy kihasználhassuk azt a megadott körülmények között, vagy megpróbálni mint továbbképzést elkészíteni a saját tárolónkat.
Forrás: habr.com
