Kiedy danych jest więcej, niż może pomieścić jeden dysk, pora pomyśleć o RAID. W dzieciństwie często słyszałem od starszych: „pewnego dnia RAID zniknie w przeszłości, a obiektowe pamięci wypełnią świat, a ty nawet nie wiesz, co to CEPH” - dlatego pierwszym krokiem w moim dorosłym życiu było stworzenie własnego klastra. Celem eksperymentu było zapoznanie się z wewnętrzną strukturą ceph i zrozumienie zakresu jego zastosowania. Jak uzasadnione jest wdrożenie ceph w średnich firmach, a jak w małych? Po kilku latach eksploatacji i kilku nieodwracalnych stratach danych zyskano zrozumienie niuansów; nie wszystko jest tak jednoznaczne. Cechy CEPH stwarzają przeszkody dla jego szerokiego rozpowszechnienia, przez co eksperymenty utknęły w martwym punkcie. Poniżej znajduje się opis wszystkich przebytych kroków, uzyskane wyniki i wyciągnięte wnioski. Będę wdzięczny, jeśli doświadczeni ludzie podzielą się swoimi przemyśleniami i wyjaśnią niektóre kwestie.
Uwaga: komentatorzy zwrócili uwagę na poważne błędy w niektórych założeniach, które wymagają przemyślenia całego artykułu.
Strategia CEPH
Kluster CEPH łączy dowolną liczbę K dysków o dowolnej wielkości i przechowuje na nich dane, powielając każdy kawałek (domyślnie 4 MB) określoną liczbę N razy.
Rozważmy najprostszy przypadek z dwoma identycznymi dyskami. Można z nich skonfigurować either RAID 1, or a cluster with N=2 — wyniki będą takie same. Jeśli dysków jest trzy i mają różne rozmiary, to łatwo jest utworzyć klaster z N=2: część danych będzie na dyskach 1 i 2, część — na 1 i 3, a część — na 2 i 3, podczas gdy RAID — nie (można skonfigurować taki RAID, ale to będzie zniekształcenie). Jeśli dysków jest jeszcze więcej, możliwe jest stworzenie RAID 5, a CEPH ma odpowiednik — erasure_code, który stoi w sprzeczności z wcześnymi koncepcjami twórców, dlatego nie jest rozważany. RAID 5 zakłada, że mamy niewielką liczbę dysków, i wszystkie są w dobrym stanie. W przypadku awarii jednego, pozostałe powinny wytrzymać do momentu, kiedy wymienią dysk i przywrócą dane na nim. CEPH z kolei, przy N>=3, zachęca do korzystania ze starych dysków, w szczególności, jeśli przechować kilka dobrych dysków do przechowywania jednej kopii danych, a pozostałe dwie-trzy kopie trzymać na dużej liczbie starych dysków, to informacje będą bezpieczne, ponieważ dopóki nowe dyski działają — nie ma problemu, a jeśli jeden z nich się zepsuje, równoczesna awaria trzech dysków, które mają więcej niż pięć lat, najlepiej z różnych serwerów — to zdarzenie jest ekstremalnie mało prawdopodobne.
W rozdzielaniu kopii jest subtelność. Domyślnie zakłada się, że dane są dzielone na większą liczbę (~po 100 na dysk) grup rozdzielenia PG, z których każda jest powielana na pewnych dyskach. Załóżmy, że K=6, N=2, wówczas w przypadku awarii dwóch dowolnych dysków, dane są gwarantowanie tracone, ponieważ wg teorii prawdopodobieństwa znajdzie się przynajmniej jedna PG, która znajdzie się właśnie na tych dwóch dyskach. A utrata jednej grupy czyni wszystkie dane w puli niedostępnymi. Jeśli jednak dyski podzielimy na trzy pary i pozwolimy przechowywać dane tylko na dyskach w ramach jednej pary, to takie rozdzielenie również jest odporne na awarię dowolnego dysku, ale w przypadku awarii dwóch prawdopodobieństwo utraty danych wynosi nie 100%, a jedynie 3/15, a nawet przy awarii trzech dysków — tylko 12/20. Stąd, entropia w rozdzielaniu danych nie sprzyja odporności na awarie. Zauważmy również, że dla serwera plików wolna pamięć operacyjna znacznie zwiększa szybkość reakcji. Im więcej pamięci w każdym węźle, i im więcej pamięci we wszystkich węzłach — tym szybciej będzie. To niewątpliwie przewaga klastra nad jednym serwerem, a tym bardziej, nad sprzętowym NAS-em, w którym wbudowuje się bardzo małą ilość pamięci.
Z tego wynika, że CEPH to dobry sposób na stworzenie niezawodnego systemu przechowywania danych na dziesiątki TB przy minimalnych nakładach z przestarzałego sprzętu (oczywiście będą potrzebne wydatki, ale niewielkie w porównaniu do komercyjnych systemów pamięci masowej).
Realizacja klastra
Do eksperymentu weźmiemy wycofaną jednostkę Intel DQ57TM + Intel core i3 540 + 16 GB RAM. Cztery dyski po 2 TB zorganizujemy w podobieństwo RAID10, po udanym teście dodamy drugi węzeł i jeszcze tyle samo dysków.
Instalujemy Linux. Wymagana jest możliwość dostosowania i stabilności dystrybucji. Odpowiednie są Debian i Suse. Suse ma bardziej elastyczny instalator, który pozwala na wyłączenie dowolnego pakietu; niestety, nie udało mi się zrozumieć, które można pominąć bez szkody dla systemu. Instalujemy Debiana za pomocą debootstrap buster. Opcja min-base instaluje niepełną wersję systemu, w której brakuje sterowników. Różnica w rozmiarze w porównaniu z pełną wersją nie jest na tyle duża, aby się tym przejmować. Ponieważ prace są prowadzone na fizycznej maszynie, chcemy robić migawki, jak w wirtualkach. Tę możliwość daje albo LVM, albo btrfs (lub xfs, albo zfs — różnica nie jest duża). W LVM migawki nie są mocną stroną. Instalujemy btrfs. I bootloader — w MBR. Nie ma sensu zanieczyszczać dysku 50 MB partycją FAT, gdy można umieścić ją w 1 MB obszarze tablicy partycji i całe miejsce przeznaczyć na system. Zajęło to na dysku 700 MB. Ile zajmuje podstawowa instalacja SUSE — nie zapamiętałem, wydaje mi się, że około 1.1 lub 1.4 GB.
Instalujemy CEPH. Ignorujemy wersję 12 w repozytorium debian i łączymy się bezpośrednio ze stroną 15.2.3. Postępujemy zgodnie z instrukcją z sekcji „Instalacja CEPH ręcznie” z następującymi zastrzeżeniami:
- Przed dodaniem repozytorium należy zainstalować gnupg wget ca-certificates
- Po dodaniu repozytorium, ale przed instalacją klastra pominięto instalację pakietów: apt -y —no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
- Podczas instalacji CEPH z niewiadomych powodów będzie próbował zainstalować lvm2. W zasadzie, nie ma z tym problemu, ale instalacja kończy się niepowodzeniem, więc CEPH również się nie zainstaluje.
Pomógł ten patch:
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
Przegląd klastra
ceph-osd — odpowiada za przechowywanie danych na dysku. Dla każdego dysku uruchamiana jest usługa sieciowa, która przyjmuje i realizuje żądania odczytu lub zapisu obiektów. Na dysku tworzone są dwie partycje. Jedna z nich zawiera informacje o klastrze, numer dysku oraz klucze do klastra. Te informacje o objętości 1KB tworzone są raz podczas dodawania dysku i więcej nigdy nie zauważyłem, żeby się zmieniały. Na drugiej partycji nie ma systemu plików, przechowywane są dane binarne CEPH. Automatyczna instalacja w poprzednich wersjach tworzyła partycję xfs o rozmiarze 100MB na dane serwisowe. Przekonwertowałem dysk na MBR i przydzieliłem całe 16MB — usługa nie narzeka. Myślę, że bez problemu xfs mogłoby zostać zastąpione przez ext. Ta partycja jest montowana w /var/lib/…, gdzie usługa odczytuje informacje o OSD, a także znajduje odnośnik do urządzenia blokowego, gdzie przechowywane są dane binarne. Teoretycznie można od razu umiejscowić pomocnicze w /var/lib/…, a cały dysk przydzielić na dane. Przy tworzeniu OSD za pomocą ceph-deploy automatycznie tworzone jest zasady montowania partycji w /var/lib/…, a także przydzielane są prawa użytkownikowi ceph do odczytu odpowiedniego urządzenia blokowego. Przy ręcznej instalacji trzeba to zrobić samodzielnie, w dokumentacji nie ma o tym wzmianki. Również pożądane jest określenie parametru osd memory target, aby wystarczyło fizycznej pamięci.
ceph-mds. Na niskim poziomie CEPH — jest to magazyn obiektów. Możliwość przechowywania bloków sprowadza się do zapisywania każdego bloku 4MB jako obiektu. Ta sama zasada dotyczy przechowywania plików. Tworzone są dwa pule: jedna dla metadanych, druga — dla danych. One są łączone w system plików. W tym momencie tworzony jest jakiś zapis, dlatego jeśli usuniesz system plików, ale zachowasz oba pule, to nie będzie możliwości jego odzyskania. Istnieje procedura wydobywania plików po blokach, nie testowałem. Za dostęp do systemu plików odpowiada usługa ceph-mds. Dla każdego systemu plików potrzebny jest oddzielny egzemplarz usługi. Jest opcja „indeks”, która pozwala stworzyć coś na kształt kilku systemów plików w jednym — również nie testowane.
ceph-mon — ta usługa przechowuje mapę klastra. Zawiera informacje o wszystkich OSD, algorytm rozdzielania PG w OSD i, co najważniejsze, informacje o wszystkich obiektach (szczegóły tego mechanizmu są dla mnie niejasne: istnieje katalog /var/lib/ceph/mon/…/store.db, w którym znajduje się duży plik — 26MB, a w klastrze 105K obiektów, co daje nieco ponad 256 bajtów na obiekt, - myślę, że monitor przechowuje listę wszystkich obiektów oraz PG, w których się znajdują). Uszkodzenie tego katalogu prowadzi do utraty wszystkich danych w klastrze. Stąd wniosek, że CRUSH pokazuje, jak PG są rozmieszczone na OSD, a jak obiekty są rozmieszczone w PG — są centralnie przechowywane w bazie danych, niezależnie od tego, jak deweloperzy starają się unikać tego terminu. W konsekwencji, po pierwsze, nie możemy zainstalować systemu na pendrive w trybie RO, ponieważ w bazie danych odbywa się ciągłe zapisywanie, potrzebny jest dodatkowy dysk pod te dane (najprawdopodobniej nie więcej niż 1 GB), po drugie, konieczne jest posiadanie kopii tej bazy w czasie rzeczywistym. Gdy istnieje więcej niż jeden monitor, odporność na błędy zapewnia się automatycznie, ale w naszym przypadku monitor jest jeden, maksymalnie — dwa. Istnieje teoretyczna procedura przywracania monitora na podstawie danych OSD, korzystałem z niej trzykrotnie z różnych powodów, i trzykrotnie nie było żadnych komunikatów o błędach, jak i danych również. Niestety, ten mechanizm nie działa. Albo eksploatujemy miniaturową partycję na OSD i tworzymy RAID do przechowywania bazy danych, co z pewnością bardzo negatywnie wpłynie na wydajność, albo przeznaczamy przynajmniej dwa niezawodne nośniki fizyczne, najlepiej USB, aby nie zajmować portów.
rados-gw — eksportuje magazyn obiektów przez protokół S3 i podobne. Tworzy wiele pul, po co to — nie wiem. Nie eksperymentowałem z tym szczególnie.
ceph-mgr — przy instalacji tej usługi uruchamiane są różne moduły. Jeden z nich to nieodłączany autoscale. Dąży do utrzymania odpowiedniej liczby PG/OSD. Jeśli chcesz zarządzać proporcją ręcznie, możesz zablokować skalowanie dla każdego basenu, ale wtedy moduł crashuje z powodu dzielenia przez 0 i status klastra staje się ERROR. Moduł napisany jest w Pythonie i jeśli odkomentujesz odpowiednią linię, prowadzi to do jego dezaktywacji. Szczegóły trudno mi sobie przypomnieć.
Lista wykorzystanych źródeł:
Listy skryptów:
Instalacja systemu przez debootstrap
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: Brak instalacji
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: Brak instalacji
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 6Tworzenie klastra
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@rbd1Dodawanie OSD (część)
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@$osdnumPodsumowanie
Główną zaletą marketingową CEPH jest CRUSH — algorytm obliczania lokalizacji danych. Monitory przekazują ten algorytm klientom, po czym klienci bezpośrednio żądają potrzebnego węzła i odpowiedniego OSD. CRUSH zapewnia brak centralizacji. To mały plik, który można nawet wydrukować i powiesić na ścianie. Praktyka pokazała, że CRUSH nie jest wyczerpującą mapą. Jeśli zniszczy się i ponownie stworzy monitory, zachowując wszystkie OSD i CRUSH, to za mało, aby przywrócić klaster. Stąd wniosek, że na każdym monitorze przechowywane są pewne metadane dotyczące całego klastra. Niewielka objętość tych metadanych nie narzuca ograniczeń na rozmiar klastra, ale wymaga zapewnienia ich bezpieczeństwa, co wyklucza oszczędności na dysku poprzez instalację systemu na pamięci flash i wyklucza klastry z mniej niż trzema węzłami. Agresywna polityka dewelopera w stosunku do opcjonalnych funkcji. Daleko do minimalizmu. Dokumentacja na poziomie: "za to, co jest, — już dziękuję, ale bardzo, bardzo ubogo". Możliwość interakcji z usługami na niskim poziomie jest przewidziana, ale dokumentacja zbyt pobieżnie porusza ten temat, więc raczej nie niż tak. Praktycznie żadne szanse na odzyskanie danych z sytuacji awaryjnej.
Opcje dalszych działań: zrezygnować z CEPH i skorzystać z banalnego wielodyskowego btrfs (lub xfs, zfs), dowiedzieć się nowych informacji o CEPH, które umożliwią jego eksploatację w podanych warunkach, spróbować w celu podniesienia kwalifikacji napisać własny magazyn danych.
Źródło: habr.com
