Ha több adat van, mint amennyi elfér egy lemezen, ideje elgondolkodni a RAID-en. Gyerekkoromban gyakran hallottam az idősebbektől: „egy napon a RAID a múlté lesz, az objektumtárolás be fogja tölteni a világot, és még azt sem tudod, mi az a CEPH”, szóval az első dolog az önálló életemben. saját klaszter létrehozása volt. A kísérlet célja a ceph belső szerkezetének megismerése és alkalmazási körének megértése volt. Mennyire indokolt a ceph bevezetése a közép- és kisvállalkozásokban? Több évnyi működés és néhány visszafordíthatatlan adatvesztés után megértettük a bonyodalmakat, hogy nem minden olyan egyszerű. A CEPH sajátosságai gátat szabnak a széles körű elterjedésének, és emiatt a kísérletek zsákutcába jutottak. Az alábbiakban ismertetjük az összes megtett lépést, a kapott eredményt és a levont következtetéseket. Ha hozzáértő emberek megosztják tapasztalataikat és elmagyaráznak néhány pontot, hálás lennék.
Megjegyzés: A hozzászólók súlyos hibákat azonosítottak néhány feltételezésben, amelyek a teljes cikk felülvizsgálatát igénylik.
CEPH stratégia
A CEPH-fürt tetszőleges számú, tetszőleges méretű lemezt egyesít, és adatokat tárol rajtuk, minden egyes darabot (alapértelmezés szerint 4 MB) adott számú N-szer megkettőzve.
Tekintsük a legegyszerűbb esetet két azonos lemezzel. Ezekből akár RAID 1-et, akár N=2-es klasztert állíthat össze - az eredmény ugyanaz lesz. Ha három lemez van, és ezek különböző méretűek, akkor könnyen összeállíthatunk egy klasztert N=2-vel: az adatok egy része az 1. és 2. lemezen, egy része az 1. és 3. lemezen lesz, néhány pedig 2-en és 3-on, míg a RAID nem fog (egy ilyen RAID-et össze lehet állítani, de az perverzió lenne). Ha még több lemez van, akkor lehetőség van RAID 5 létrehozására; a CEPH-nak van egy analóg - erasure_code -ja, ami ellentmond a fejlesztők korai koncepcióinak, ezért nem veszik figyelembe. A RAID 5 feltételezi, hogy van néhány meghajtó, amelyek mindegyike jó állapotban van. Ha az egyik meghibásodik, a többieknek ki kell tartaniuk, amíg ki nem cserélik a lemezt és vissza nem állítják az adatokat. A CEPH, ahol N>=3, a régi lemezek használatát bátorítja, különösen, ha több jó lemezt tart az adatok egy példányának tárolására, a fennmaradó két vagy három másolatot pedig nagyszámú régi lemezen tárolja, akkor az információ biztonságos lesz, mivel egyelőre az új lemezek élnek - nincs probléma, és ha az egyik elromlik, akkor rendkívül valószínűtlen három, öt évnél hosszabb élettartamú, lehetőleg különböző szerverekről származó lemez egyidejű meghibásodása. esemény.
Van egy finomság a másolatok terjesztésében. Alapértelmezés szerint az adatok több (lemezenként ~100) PG terjesztési csoportra vannak osztva, amelyek mindegyike megkettőződik néhány lemezen. Tegyük fel, hogy K=6, N=2, akkor ha bármelyik két lemez meghibásodik, akkor garantáltan adatvesztés történik, hiszen a valószínűségszámítás szerint ezen a két lemezen lesz legalább egy PG. Egy csoport elvesztése pedig elérhetetlenné teszi a készlet összes adatát. Ha a lemezeket három párra osztjuk, és az adatok csak egy páron belüli lemezeken tárolhatók, akkor az ilyen elosztás bármely lemez meghibásodásával szemben is ellenáll, de ha két lemez meghibásodik, az adatvesztés valószínűsége nem 100%, de csak 3/15, és még meghibásodás esetén is három lemez - csak 12/20. Ezért az adateloszlás entrópiája nem járul hozzá a hibatűréshez. Vegye figyelembe azt is, hogy egy fájlszerver esetében a szabad RAM jelentősen megnöveli a válaszsebességet. Minél több memória az egyes csomópontokban, és minél több memória az összes csomópontban, annál gyorsabb lesz. Ez kétségtelenül előnye a fürtnek egyetlen szerverrel, és még inkább a hardveres NAS-szal szemben, ahol nagyon kevés memória van beépítve.
Ebből az következik, hogy a CEPH jó módja annak, hogy megbízható adattároló rendszert hozzunk létre több tíz TB-ig, amely minimális befektetéssel méretezhető elavult berendezésekből (itt természetesen költségekre lesz szükség, de a kereskedelmi tárolórendszerekhez képest kicsi).
Klaszter megvalósítás
A kísérlethez vegyünk egy leszerelt számítógépet Intel DQ57TM + Intel core i3 540 + 16 GB RAM. Négy 2 TB-os lemezt valami RAID10-be rendezünk, sikeres teszt után hozzáadunk egy második csomópontot és ugyanennyi lemezt.
Linux telepítése. A disztribúció megköveteli a testreszabhatóságot és a stabilitást. A Debian és a Suse megfelel a követelményeknek. A Suse rugalmasabb telepítővel rendelkezik, amely lehetővé teszi bármely csomag letiltását; Sajnos nem tudtam rájönni, hogy melyiket lehetne kidobni a rendszer károsodása nélkül. Telepítse a Debiant a debootstrap buster segítségével. A min-base opció egy törött rendszert telepít, amelyhez nincsenek illesztőprogramok. A méretbeli különbség a teljes verzióhoz képest nem akkora, hogy zavarjon. Mivel a munka fizikai gépen történik, szeretnék pillanatképeket készíteni, mint a virtuális gépeken. Ezt a lehetőséget vagy az LVM, vagy a btrfs (vagy xfs, vagy zfs - nem nagy a különbség) biztosítja. Az LVM pillanatfelvételek nem erős oldalak. Telepítse a btrfs-t. A rendszerbetöltő pedig az MBR-ben van. Nincs értelme egy 50 MB-os lemezt telezsúfolni egy FAT-partícióval, ha egy 1 MB-os partíciós tábla területére tolhatja, és lefoglalhatja az összes helyet a rendszer számára. 700 MB-ot foglalt el a lemezen. Nem emlékszem, mennyi az alap SUSE telepítés, szerintem kb 1.1 vagy 1.4 GB.
Telepítse a CEPH-t. Figyelmen kívül hagyjuk a 12-es verziót a debian tárolóban, és közvetlenül a 15.2.3 webhelyről csatlakozunk. Követjük a „CEPH manuális telepítése” című részben található utasításokat a következő figyelmeztetésekkel:
- A tároló csatlakoztatása előtt telepítenie kell a gnupg wget ca-tanúsítványokat
- A tároló csatlakoztatása után, de a fürt telepítése előtt a csomagok telepítése elmarad: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
- A CEPH telepítésekor ismeretlen okokból megpróbálja telepíteni az lvm2-t. Elvileg nem kár, de a telepítés nem sikerül, így a CEPH sem telepíti.
Ez a javítás segített:
cat << EOF >> /var/lib/dpkg/status Package: lvm2 Status: install ok installed Priority: important Section: admin Installed-Size: 0 Maintainer: Debian Adduser Developers <[email protected]> Architecture: all Multi-Arch: foreign Version: 113.118 Description: No-install EOF
A klaszter áttekintése
ceph-osd - az adatok lemezen való tárolásáért felelős. Minden lemez esetében elindul egy hálózati szolgáltatás, amely elfogadja és végrehajtja az objektumok olvasására vagy írására vonatkozó kéréseket. Két partíció jön létre a lemezen. Az egyik a fürtről, a lemezszámról és a fürt kulcsairól tartalmaz információkat. Ez az 1 KB-os információ egyszer jön létre a lemez hozzáadásakor, és soha nem vették észre, hogy megváltoztak. A második partíciónak nincs fájlrendszere, és CEPH bináris adatokat tárol. A korábbi verziók automatikus telepítése 100 MB-os xfs partíciót hozott létre a szolgáltatási információkhoz. Átalakítottam a lemezt MBR-re, és csak 16 MB-ot foglaltam le - a szolgáltatás nem panaszkodik. Szerintem az xfs-t gond nélkül le lehetne cserélni ext-re. Ez a partíció a /var/lib/… könyvtárba van felszerelve, ahol a szolgáltatás információkat olvas az OSD-ről, és talál egy hivatkozást a blokkeszközre, ahol a bináris adatok tárolódnak. Elméletileg azonnal elhelyezheti a segédfájlokat a /var/lib/… mappába, és lefoglalhatja a teljes lemezt az adatok számára. Amikor a ceph-deploy segítségével OSD-t hoz létre, automatikusan létrejön egy szabály a partíció felcsatolására a /var/lib/… könyvtárban, és a ceph felhasználó jogosultságot kap a kívánt blokkeszköz olvasására is. Ha manuálisan telepíti, ezt magának kell megtennie, a dokumentáció nem írja ezt. Célszerű az osd memória célparaméterét is megadni, hogy legyen elegendő fizikai memória.
ceph-mds. Alacsony szinten a CEPH objektumtároló. A blokktárolási képesség abban áll, hogy minden 4 MB-os blokkot objektumként tárolunk. A fájltárolás ugyanezen az elven működik. Két készlet jön létre: az egyik a metaadatok, a másik az adatok számára. Fájlrendszerré egyesítik. Ebben a pillanatban létrejön valamilyen rekord, így ha törli a fájlrendszert, de megtartja mindkét készletet, akkor nem tudja visszaállítani. Van egy eljárás a fájlok blokkok szerinti kibontására, nem teszteltem. A ceph-mds szolgáltatás felelős a fájlrendszerhez való hozzáférésért. Minden fájlrendszerhez külön példány szükséges a szolgáltatásból. Van egy „index” opció, amely lehetővé teszi több fájlrendszer látszatának létrehozását egyben - szintén nem tesztelt.
Ceph-mon – Ez a szolgáltatás a fürt térképét tárolja. Tartalmaz információkat az összes OSD-ről, egy algoritmust a PG-k OSD-kben való elosztására, és ami a legfontosabb, információkat az összes objektumról (ennek a mechanizmusnak a részletei nem világosak számomra: van egy /var/lib/ceph/mon/…/ könyvtár store.db, ez egy nagy fájlt tartalmaz, 26 MB, és egy 105 256 objektumból álló klaszterben kiderül, hogy objektumonként valamivel több mint 1 bájt - szerintem a monitor tárolja az összes objektum listáját és a PG-t, amelyben találhatók). A könyvtár sérülése a fürt összes adatának elvesztését eredményezi. Ebből az a következtetés vonható le, hogy a CRUSH megmutatja, hogy a PG-k hogyan helyezkednek el az OSD-n, és hogyan helyezkednek el az objektumok a PG-ken – ezek központilag az adatbázisban vannak tárolva, bármennyire kerülik is ezt a szót a fejlesztők. Emiatt egyrészt nem tudjuk RO módban pendrive-ra telepíteni a rendszert, mivel az adatbázis folyamatosan rögzítésre kerül, ezekhez szükség van egy további lemezre (alig több, mint XNUMX GB), másrészt szükség van egy másolja valós időben ezt a bázist. Ha több monitor van, akkor a hibatűrés automatikusan biztosítva van, de esetünkben csak egy monitor van, maximum kettő. Van egy elméleti eljárás a monitor visszaállítására OSD adatok alapján, háromszor folyamodtam hozzá különböző okok miatt, és háromszor nem volt hibaüzenet, valamint adat sem. Sajnos ez a mechanizmus nem működik. Vagy üzemeltetünk egy miniatűr partíciót az OSD-n, és összeállítunk egy RAID-et az adatbázis tárolására, ami minden bizonnyal nagyon rossz hatással lesz a teljesítményre, vagy legalább két megbízható fizikai adathordozót foglalunk le, lehetőleg USB-t, hogy ne foglalják el a portokat.
rados-gw - az objektumtárolást az S3 protokollon és hasonlókon keresztül exportálja. Sok medencét hoz létre, nem világos, miért. Nem sokat kísérleteztem.
ceph-mgr - A szolgáltatás telepítésekor több modul is elindul. Az egyik az automatikus skálázás, amelyet nem lehet letiltani. Arra törekszik, hogy fenntartsa a megfelelő mennyiségű PG/OSD-t. Ha manuálisan szeretné szabályozni az arányt, akkor letilthatja a méretezést az egyes készleteknél, de ebben az esetben a modul 0-val osztva összeomlik, és a fürt állapota HIBA lesz. A modul Pythonban van írva, és ha kiírod benne a szükséges sort, az a letiltásához vezet. Túl lusta, hogy emlékezzen a részletekre.
A felhasznált források listája:
Szkript listák:
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 << EOF > /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 << EOF >> /var/lib/dpkg/status
Package: lvm2
Status: install ok installed
Priority: important
Section: admin
Installed-Size: 0
Maintainer: Debian Adduser Developers <[email protected]>
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 <[email protected]>
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 6Hozzon létre egy klasztert
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 << EOF > /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Összegzés
A CEPH fő marketing előnye a CRUSH – az adatok helyének kiszámítására szolgáló algoritmus. A monitorok ezt az algoritmust kiosztják a klienseknek, majd az ügyfelek közvetlenül kérik a kívánt csomópontot és a kívánt OSD-t. A CRUSH nem biztosítja a központosítást. Ez egy kis fájl, amelyet akár ki is nyomtathat, és a falra akaszthatja. A gyakorlat azt mutatja, hogy a CRUSH nem egy teljes térkép. Ha megsemmisíti és újra létrehozza a monitorokat, megtartva az összes OSD-t és a CRUSH-t, akkor ez nem elég a fürt helyreállításához. Ebből arra következtethetünk, hogy minden monitor tárol bizonyos metaadatokat a teljes klaszterről. Ezen metaadatok kis mennyisége nem korlátozza a fürt méretét, de megköveteli a biztonságuk biztosítását, ami kiküszöböli a lemezmegtakarítást a rendszer flash meghajtóra történő telepítésével, és kizárja a háromnál kevesebb csomóponttal rendelkező fürtöket. A fejlesztő agresszív politikája az opcionális funkciókkal kapcsolatban. Távol a minimalizmustól. A dokumentáció a "köszönjük, amink van, de nagyon-nagyon csekély" szintű. A szolgáltatásokkal való alacsony szintű interakció lehetősége biztosított, de a dokumentáció túlságosan felületesen érinti ezt a témát, ezért valószínűbb, hogy nem, mint igen. Vészhelyzetből gyakorlatilag nincs esély az adatok helyreállítására.
További teendők: hagyja el a CEPH-t, és használja a banális többlemezes btrf-eket (vagy xfs-t, zfs-t), tudjon meg új információkat a CEPH-ról, amelyek lehetővé teszik a működését a megadott feltételek mellett, próbálja meg saját tárhelyét haladóként írni kiképzés.
Forrás: will.com