Kiedy danych jest więcej, niż mieści się na jednym dysku, czas pomyśleć o macierzy RAID. Jako dziecko często słyszałem od starszych: „pewnego dnia RAID będzie już przeszłością, magazynowanie obiektów wypełni świat, a ty nawet nie wiesz, co to jest CEPH”, więc pierwszą rzeczą w moim niezależnym życiu było stworzenie własnego klastra. Celem doświadczenia było zapoznanie się z budową wewnętrzną cefa i zrozumienie zakresu jego zastosowania. Na ile zasadne jest wdrożenie ceph w średnich i małych przedsiębiorstwach? Po kilku latach działania i kilku nieodwracalnych stratach danych pojawiło się zrozumienie zawiłości, że nie wszystko jest takie proste. Specyfika CEPH stwarza bariery w jego powszechnym przyjęciu i z tego powodu eksperymenty utknęły w ślepym zaułku. Poniżej znajduje się opis wszystkich podjętych kroków, uzyskany wynik i wyciągnięte wnioski. Jeżeli znający się na rzeczy ludzie podzielą się swoim doświadczeniem i wyjaśnią pewne kwestie, będę wdzięczny.
Uwaga: Komentatorzy zauważyli poważne błędy w niektórych założeniach, które wymagają przeglądu całego artykułu.
Strategia CEPH
Klaster CEPH łączy dowolną liczbę K dysków o dowolnej wielkości i przechowuje na nich dane, powielając każdy fragment (domyślnie 4 MB) określoną liczbę N razy.
Rozważmy najprostszy przypadek z dwoma identycznymi dyskami. Z nich możesz złożyć RAID 1 lub klaster z N=2 - wynik będzie taki sam. Jeśli są trzy dyski i są one różnej wielkości, łatwo jest złożyć klaster z N=2: część danych będzie na dyskach 1 i 2, część będzie na dyskach 1 i 3, a część będzie na 2 i 3, podczas gdy RAID nie będzie (można taki RAID złożyć, ale byłoby to wypaczenie). Jeśli dysków jest jeszcze więcej, możliwe jest utworzenie RAID 5, CEPH ma analogowy - erasure_code, który jest sprzeczny z wczesnymi koncepcjami programistów i dlatego nie jest brany pod uwagę. W przypadku RAID 5 zakłada się, że istnieje niewielka liczba dysków i wszystkie są w dobrym stanie. Jeśli jeden ulegnie awarii, pozostałe muszą wytrzymać do czasu wymiany dysku i przywrócenia na niego danych. CEPH, przy N>=3, zachęca do korzystania ze starych dysków, w szczególności jeśli przechowujesz kilka dobrych dysków do przechowywania jednej kopii danych, a pozostałe dwie lub trzy kopie przechowujesz na dużej liczbie starych dysków, wówczas informacja będzie bezpiecznie, bo na razie nowe dyski żyją - nie ma problemów, a jeśli jeden z nich ulegnie uszkodzeniu, to jednoczesna awaria trzech dysków o żywotności przekraczającej pięć lat, najlepiej z różnych serwerów, jest wyjątkowo mało prawdopodobne wydarzenie.
Dystrybucja kopii jest subtelna. Domyślnie zakłada się, że dane są podzielone na więcej (~100 na dysk) grup dystrybucyjnych PG, z których każda jest duplikowana na niektórych dyskach. Powiedzmy, że K=6, N=2, a jeśli jakiekolwiek dwa dyski zawiodą, dane zostaną utracone, ponieważ zgodnie z teorią prawdopodobieństwa na tych dwóch dyskach będzie znajdować się co najmniej jeden PG. Utrata jednej grupy powoduje, że wszystkie dane w puli stają się niedostępne. Jeśli dyski zostaną podzielone na trzy pary i dane będą mogły być przechowywane tylko na dyskach w ramach jednej pary, to taki rozkład jest również odporny na awarię któregokolwiek z dysków, natomiast w przypadku awarii dwóch dysków prawdopodobieństwo utraty danych nie jest 100%, ale tylko 3/15, a nawet w przypadku awarii trzech dysków - tylko 12/20. Dlatego entropia w dystrybucji danych nie przyczynia się do odporności na błędy. Należy również pamiętać, że w przypadku serwera plików wolna pamięć RAM znacznie zwiększa szybkość odpowiedzi. 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. Jest to niewątpliwie przewaga klastra nad pojedynczym serwerem, a tym bardziej sprzętowym serwerem NAS, w którym wbudowana jest bardzo mała ilość pamięci.
Wynika z tego, że CEPH to dobry sposób na stworzenie niezawodnego systemu przechowywania danych na kilkadziesiąt TB z możliwością skalowania przy minimalnych nakładach inwestycyjnych z przestarzałego sprzętu (tutaj oczywiście wymagane będą koszty, ale niewielkie w porównaniu z komercyjnymi systemami przechowywania).
Wdrożenie klastra
Do eksperymentu weźmy zdemontowany komputer Intel DQ57TM + Intel Core i3 540 + 16 GB RAM. Zorganizujemy cztery dyski 2 TB w coś na wzór RAID10, po udanym teście dodamy drugi węzeł i taką samą liczbę dysków.
Instalowanie Linuksa. Dystrybucja wymaga możliwości dostosowania i stabilności. Debian i Suse spełniają wymagania. Suse ma bardziej elastyczny instalator, który pozwala wyłączyć dowolny pakiet; Niestety nie udało mi się ustalić, które z nich można wyrzucić bez uszkodzenia systemu. Zainstaluj Debiana za pomocą narzędzia debootstrap. Opcja min-base instaluje uszkodzony system, w którym brakuje sterowników. Różnica w wielkości w stosunku do pełnej wersji nie jest na tyle duża, aby przeszkadzać. Ponieważ praca odbywa się na maszynie fizycznej, chcę robić migawki, jak na maszynach wirtualnych. Tę opcję udostępnia albo LVM, albo btrfs (albo xfs, albo zfs - różnica nie jest duża). Migawki LVM nie są mocną stroną. Zainstaluj btrfs. A bootloader jest w MBR. Nie ma sensu zaśmiecać dysku 50 MB partycją FAT, jeśli można go wepchnąć do obszaru tablicy partycji o wielkości 1 MB i przydzielić całe miejsce dla systemu. Zajęło 700 MB na dysku. Nie pamiętam ile ma podstawowa instalacja SUSE, myślę że około 1.1 lub 1.4 GB.
Zainstaluj CEPH. Ignorujemy wersję 12 w repozytorium Debiana i łączymy się bezpośrednio ze strony 15.2.3. Postępujemy zgodnie z instrukcjami z sekcji „Zainstaluj CEPH ręcznie” z następującymi zastrzeżeniami:
- Przed podłączeniem repozytorium należy zainstalować certyfikaty gnupg wget ca
- Po podłączeniu repozytorium, ale przed instalacją klastra, instalowanie pakietów jest pomijane: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
- Podczas instalacji CEPH z nieznanych powodów spróbuje zainstalować lvm2. W zasadzie nie szkoda, ale instalacja się nie udaje, więc CEPH też nie zainstaluje.
Ta poprawka pomogła:
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
Przegląd klastra
ceph-osd - odpowiada za przechowywanie danych na dysku. Dla każdego dysku uruchamiana jest usługa sieciowa, która akceptuje i wykonuje żądania odczytu lub zapisu do obiektów. Na dysku utworzone zostaną dwie partycje. Jeden z nich zawiera informacje o klastrze, numerze dysku i kluczach do klastra. Ta informacja o rozmiarze 1 KB jest tworzona raz podczas dodawania dysku i nigdy nie zauważono, że uległa ona zmianie. Druga partycja nie ma systemu plików i przechowuje dane binarne CEPH. Automatyczna instalacja w poprzednich wersjach utworzyła partycję xfs o wielkości 100 MB na informacje serwisowe. Przekonwertowałem dysk na MBR i przydzieliłem tylko 16MB - serwis nie narzeka. Myślę, że xfs można bez problemu zastąpić ext. Partycja ta jest montowana w /var/lib/…, gdzie usługa odczytuje informacje o OSD, a także znajduje odniesienie do urządzenia blokowego, w którym przechowywane są dane binarne. Teoretycznie możesz od razu umieścić pliki pomocnicze w /var/lib/… i przeznaczyć cały dysk na dane. Podczas tworzenia OSD poprzez ceph-deploy, automatycznie tworzona jest reguła montowania partycji w /var/lib/…, a użytkownikowi ceph przypisywane są także prawa do odczytu żądanego urządzenia blokowego. Jeśli instalujesz ręcznie, musisz to zrobić samodzielnie; dokumentacja tego nie mówi. Wskazane jest również określenie parametru docelowej pamięci osd, aby zapewnić wystarczającą ilość pamięci fizycznej.
ceph-mds. Na niskim poziomie CEPH to pamięć obiektowa. Możliwość blokowania pamięci sprowadza się do przechowywania każdego bloku 4 MB jako obiektu. Przechowywanie plików działa na tej samej zasadzie. Tworzone są dwie pule: jedna dla metadanych, druga dla danych. Są one połączone w system plików. W tym momencie tworzony jest jakiś zapis, więc jeśli usuniesz system plików, ale zachowasz obie pule, nie będzie można go przywrócić. Istnieje procedura wyodrębniania plików blokami, nie testowałem jej. Za dostęp do systemu plików odpowiada usługa ceph-mds. Każdy system plików wymaga osobnej instancji usługi. Dostępna jest opcja „indeks”, która pozwala stworzyć pozory kilku systemów plików w jednym - również nie testowana.
Ceph-mon - Ta usługa przechowuje mapę klastra. Zawiera informacje o wszystkich OSD, algorytm dystrybucji PG w OSD i co najważniejsze, informacje o wszystkich obiektach (szczegóły tego mechanizmu nie są dla mnie jasne: istnieje katalog /var/lib/ceph/mon/…/ store.db, zawiera duży plik o wielkości 26MB, a w klastrze 105K obiektów okazuje się, że jest to nieco ponad 256 bajtów na obiekt - myślę, że monitor przechowuje listę wszystkich obiektów i PG, w których się znajdują). Uszkodzenie tego katalogu powoduje utratę wszystkich danych w klastrze. Stąd wysnuto wniosek, że CRUSH pokazuje, jak PG są ułożone na OSD, a jak obiekty na PG - są one centralnie przechowywane w bazie danych, niezależnie od tego, jak bardzo twórcy unikają tego słowa. Sprawia to, że po pierwsze nie możemy zainstalować systemu na pendrive w trybie RO, gdyż baza danych jest stale zapisywana, do tego potrzebny jest dodatkowy dysk (niewiele więcej niż 1 GB), po drugie konieczne jest posiadanie kopiuj w czasie rzeczywistym tę bazę. Jeśli jest kilka monitorów, odporność na uszkodzenia jest zapewniona automatycznie, ale w naszym przypadku jest tylko jeden monitor, maksymalnie dwa. Istnieje teoretyczna procedura przywracania monitora na podstawie danych OSD, skorzystałem z niej trzy razy z różnych powodów i trzy razy nie było żadnych komunikatów o błędach ani danych. Niestety ten mechanizm nie działa. Albo obsłużymy miniaturową partycję na OSD i złożymy RAID do przechowywania bazy danych, co z pewnością będzie miało bardzo zły wpływ na wydajność, albo przydzielimy przynajmniej dwa niezawodne nośniki fizyczne, najlepiej USB, aby nie zajmować portów.
rados-gw - eksportuje pamięć obiektową poprzez protokół S3 i podobny. Tworzy wiele pul, nie jest jasne dlaczego. Nie eksperymentowałem zbyt wiele.
ceph-mgr - Podczas instalowania tej usługi uruchamianych jest kilka modułów. Jednym z nich jest automatyczne skalowanie, którego nie można wyłączyć. Dąży do utrzymania prawidłowej ilości PG/OSD. Jeśli chcesz ręcznie kontrolować współczynnik, możesz wyłączyć skalowanie dla każdej puli, ale w tym przypadku moduł zawiesza się przy dzieleniu przez 0, a status klastra staje się BŁĄD. Moduł jest napisany w Pythonie i jeśli zakomentujesz w nim potrzebną linię, prowadzi to do jego wyłączenia. Zbyt leniwy, żeby pamiętać szczegóły.
Lista wykorzystanych źródeł:
Lista skryptów:
Instalacja systemu poprzez 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 << 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 6Utwórz klaster
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@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@$osdnumStreszczenie
Główną zaletą marketingową CEPH jest CRUSH – algorytm obliczania lokalizacji danych. Monitory rozpowszechniają ten algorytm wśród klientów, po czym klienci bezpośrednio żądają żądanego węzła i żądanego OSD. CRUSH nie zapewnia centralizacji. Jest to mały plik, który można nawet wydrukować i powiesić na ścianie. Praktyka pokazała, że CRUSH nie jest mapą wyczerpującą. Jeśli zniszczysz i odtworzysz monitory, zachowując wszystkie OSD i CRUSH, to nie wystarczy, aby przywrócić klaster. Z tego wynika, że każdy monitor przechowuje pewne metadane dotyczące całego klastra. Mała ilość tych metadanych nie nakłada ograniczeń na wielkość klastra, ale wymaga zapewnienia ich bezpieczeństwa, co eliminuje oszczędność dysku poprzez instalację systemu na pendrive'ie i wyklucza klastry posiadające mniej niż trzy węzły. Agresywna polityka dewelopera dotycząca opcjonalnych funkcji. Daleko nam do minimalizmu. Dokumentacja jest na poziomie „dziękujemy za to, co mamy, ale jest to bardzo, bardzo skromne”. Zapewniona jest możliwość interakcji z usługami na niskim poziomie, jednak dokumentacja porusza ten temat zbyt powierzchownie, więc raczej nie, niż tak. Praktycznie nie ma szans na odzyskanie danych z sytuacji awaryjnej.
Opcje dalszego działania: porzuć CEPH i użyj banalnego wielodyskowego btrfs (lub xfs, zfs), zdobądź nowe informacje o CEPH, które pozwolą ci obsługiwać go w określonych warunkach, spróbuj napisać własną pamięć masową jako zaawansowaną szkolenie.
Źródło: www.habr.com