🥇Porady i triki w pracy z Ceph w obciążonych projektach

Używając Ceph jako sieciowe magazynowanie w różnych projektach o różnym obciążeniu, możemy napotkać różne zadania, które na pierwszy rzut oka nie wydają się proste ani trywialne. Na przykład:

migracja danych ze starego Ceph do nowego z częściowym wykorzystaniem poprzednich serwerów w nowym klastrze;
rozwiązanie problemu rozdzielania przestrzeni dyskowej w Ceph.

Zajmując się takimi zadaniami, stykamy się z koniecznością poprawnego wyciągnięcia OSD bez utraty danych, co jest szczególnie istotne przy dużych woluminach danych. O tym będzie mowa w artykule.

Opisane poniżej metody są aktualne dla wszystkich wersji Ceph. Ponadto weźmie się pod uwagę fakt, że w Ceph można przechowywać dużą ilość danych: aby zapobiec utracie danych i innym problemom, niektóre działania będą „dzielone” na kilka innych.

Wstęp do OSD

Ponieważ dwa z trzech omawianych przepisów dotyczą OSD (Object Storage Daemon), przed przejściem do części praktycznej — w skrócie opowiemy, czym to właściwie jest w Ceph i dlaczego jest tak ważne.

Przede wszystkim należy powiedzieć, że cały klaster Ceph składa się z wielu OSD. Im więcej ich jest, tym więcej wolnej przestrzeni danych w Ceph. Stąd łatwo zrozumieć główną funkcję OSD: przechowuje dane obiektów Ceph na systemach plików wszystkich węzłów klastra i zapewnia dostęp sieciowy do nich (do odczytu, zapisu i innych запросов).

Na tym samym poziomie ustalane są parametry replikacji poprzez kopiowanie obiektów między różnymi OSD. I tutaj można napotkać różne problemy, o rozwiązaniu których będzie mowa dalej.

Przypadek nr 1. Bezpieczne wyciąganie OSD z klastra Ceph bez utraty danych

Potrzeba wyciągnięcia OSD może być spowodowana usunięciem serwera z klastra — na przykład w celu jego wymiany na inny serwer — co miało miejsce w naszym przypadku, co było powodem napisania artykułu. Ostatecznym celem działań jest wyciągnięcie wszystkich OSD i monów na tym serwerze, aby można było go zatrzymać.

Dla wygody i uniknięcia sytuacji, w której podczas wykonywania poleceń popełnimy błąd w wskazywaniu odpowiedniego OSD, zdefiniujemy oddzielną zmienną, której wartością będzie numer usuwanego OSD. Nazwijmy ją ${ID} — tutaj i w dalszej części taka zmienna zastępuje numer OSD, z którym pracujemy.

Zobaczmy stan przed rozpoczęciem prac:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME      STATUS REWEIGHT PRI-AFF
-1       0.46857 root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
 1   ssd 0.15619      osd.1     up     1.00000  1.00000
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2     up     1.00000  1.00000

Aby zainicjować usunięcie OSD, należy stopniowo wykonać reweight na niej do zera. W ten sposób zmniejszamy ilość danych w OSD poprzez ich balansowanie na inne OSD. W tym celu wykonuje się następujące polecenia:

ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78

… i tak dalej do zera.

Stopniowe balansowanie jest konieczne, aby nie utracić danych. Jest to szczególnie ważne, jeśli w OSD znajduje się duża ilość danych. Aby dokładnie upewnić się, że po wykonaniu poleceń reweight wszystko poszło pomyślnie, można wykonać ceph -s lub w osobnym oknie terminala uruchomić ceph -w aby obserwować zmiany w czasie rzeczywistym.

Gdy OSD jest "opustoszona", można przystąpić do standardowej operacji jej usunięcia. W tym celu przekażemy odpowiednią OSD w stan down:

ceph osd down osd.${ID}

"Wydobędziemy" OSD z klastra:

ceph osd out osd.${ID}

Zatrzymamy usługę OSD i odmontujemy jej partycję w FS:

systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}

Usuniemy OSD z mapy CRUSH:

ceph osd crush remove osd.${ID}

Usuniemy użytkownika OSD:

ceph auth del osd.${ID}

I wreszcie usuniemy samą OSD:

ceph osd rm osd.${ID}

Uwaga: jeśli używasz wersji Ceph Luminous lub wyższej, to powyższe działania związane z usunięciem OSD można sprowadzić do dwóch poleceń:

ceph osd out osd.${ID}
ceph osd purge osd.${ID}

Jeśli po wykonaniu powyższych działań wykonasz polecenie ceph osd tree, powinno być widać, że na serwerze, na którym przeprowadzano prace, nie ma już OSD, dla których przeprowadzano wcześniejsze operacje:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
-1       0.46857      root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2    up     1.00000  1.00000

Przy okazji zauważymy, że stan klastra Ceph przechodzi w HEALTH_WARN, a także zobaczymy zmniejszenie liczby OSD oraz dostępnego miejsca na dysku.

Dalej opisane będą działania, które będą wymagane, jeśli chcesz całkowicie zatrzymać serwer i odpowiednio usunąć go z Ceph. W takim przypadku ważne jest, aby pamiętać, że przed wyłączeniem serwera należy wyodrębnić wszystkie OSD na tym serwerze.

Jeśli na tym serwerze nie pozostały już żadne OSD, to po ich usunięciu należy wykluczyć z mapy OSD serwer hv-2, wykonując następujące polecenie:

ceph osd crush rm hv-2

Usuwamy mon z serwera hv-2, uruchamiając polecenie poniżej na innym serwerze (tj. w tym przypadku — na hv-1):

ceph-deploy mon destroy hv-2

Po tym można zatrzymać serwer i przejść do kolejnych działań (jego ponownego wdrażania itd.).

Przypadek nr 2. Rozdział przestrzeni dyskowej w już utworzonym klastrze Ceph

Drugą historię rozpocznę od wprowadzenia na temat PG (Placement Groups). Główna rola PG w Ceph polega przede wszystkim na agregowaniu obiektów Ceph i dalszej replikacji w OSD. Wzór, za pomocą którego można obliczyć potrzebną liczbę PG, znajduje się w odpowiedniej sekcji dokumentacji Ceph. Tam też ten problem został omówiony na konkretnych przykładach.

Tak więc: jednym z powszechnych problemów podczas eksploatacji Ceph jest niezrównoważona liczba OSD i PG pomiędzy pulami w Ceph.

Po pierwsze, może zaistnieć sytuacja, w której wskazana zostanie zbyt duża liczba PG w małej objętości pułki, co w zasadzie jest nieracjonalnym wykorzystaniem przestrzeni dyskowej w klastrze. Po drugie, w praktyce pojawia się poważniejszy problem: przepełnienie danych w jednym z OSD. To prowadzi do stanu klastra najpierw w HEALTH_WARN, a potem w HEALTH_ERR. Wszystkiemu winien jest fakt, że Ceph przy obliczaniu dostępnej objętości danych (można to sprawdzić za pomocą MAX AVAIL w wyniku polecenia ceph df dla każdej puli osobno) opiera się na objętości dostępnych danych w OSD. Jeśli chociaż w jednym OSD będzie za mało miejsca, to więcej danych nie da się zapisać, dopóki dane nie zostaną właściwie rozdzielone pomiędzy wszystkie OSD.

Warto zaznaczyć, że te problemy w większym stopniu są rozwiązywane na etapie konfiguracji klastra Ceph. Jednym z narzędzi, z którego można skorzystać, jest Ceph PGCalc. Dzięki niemu można w sposób wizualny obliczyć potrzebną liczbę PG. Niemniej jednak można z niego skorzystać również w sytuacji, gdy klaster Ceph już jest nieprawidłowo skonfigurowany. Należy zaznaczyć, że w ramach prac naprawczych prawdopodobnie będzie trzeba zmniejszyć liczbę PG, a ta możliwość nie była dostępna w starszych wersjach Ceph (pojawiła się dopiero w wersji Nautilus).

Wyobraźmy sobie więc następującą sytuację: klaster ma status HEALTH_WARN z powodu tego, że w jednym z OSD kończy się miejsce. O tym świadczyć będzie błąd HEALTH_WARN: 1 near full osd. Poniżej przedstawiono algorytm wyjścia z takiej sytuacji.

Na początku należy rozdzielić istniejące dane pomiędzy pozostałe OSD. Taką operację już wykonywaliśmy w pierwszym przypadku, gdy 'osuszaliśmy' węzeł — z tą różnicą, że teraz będziemy musieli nieznacznie zmniejszyć reweight. Na przykład do 0.95:

ceph osd reweight osd.${ID} 0.95

W ten sposób zwalnia się przestrzeń dyskowa w OSD i naprawia błąd w ceph health. Jednak, jak już wspomniano, problem ten występuje głównie z powodu nieprawidłowej konfiguracji Ceph na początkowych etapach: bardzo ważne jest, aby przeprowadzić rekonfigurację, aby nie pojawił się w przyszłości.

W naszym konkretnym przypadku wszystko sprowadzało się do:

zbyt wysokiej wartości replication_count w jednym z pul,
zbyt dużej liczby PG w jednym puli i zbyt małej — w drugim.

Skorzystamy z już wspomnianego kalkulatora. Pokazuje on wyraźnie, co należy wprowadzić i w zasadzie nie ma w tym nic skomplikowanego. Po ustawieniu wymaganych parametrów otrzymujemy następujące zalecenia:

Uwaga: jeśli konfigurowałeś klaster Ceph od podstaw, kolejną przydatną funkcją kalkulatora będzie generowanie poleceń, które stworzą puli od zera z parametrami podanymi w tabeli.

Pomaga się zorientować ostatnia kolumna — Suggested PG Count. W naszym przypadku przydatna jest także druga, w której określony jest parametr replikacji, ponieważ zdecydowaliśmy się zmienić i mnożnik replikacji.

Zatem najpierw będziemy musieli zmienić parametry replikacji — jest to coś, co powinno być robione w pierwszej kolejności, ponieważ zmniejszając mnożnik, zwolnimy przestrzeń dyskową. W trakcie wykonywania polecenia można zauważyć, że wartość dostępnej przestrzeni dyskowej będzie się zwiększać:

ceph osd pool $pool_name set $replication_size

A po jego zakończeniu — zmieniamy wartości parametrów pg_num i pgp_num w następujący sposób:

ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_number

Ważne: musimy kolejno w każdym puli zmienić liczbę PG i nie zmieniać wartości w innych pulach, dopóki nie znikną ostrzeżenia «Degraded data redundancy» i «n-number of pgs degraded».

Można również sprawdzić, że wszystko przebiegło pomyślnie, analizując wyniki poleceń ceph health detail i ceph -s.

Przypadek nr 3. Migracja maszyny wirtualnej z LVM do Ceph RBD

W sytuacji, gdy w projekcie wykorzystuje się maszyny wirtualne zainstalowane na wynajętych serwerach bare-metal, często pojawia się pytanie o niezawodne magazynowanie. Dobrze by też było, aby miejsca w tym magazynie było wystarczająco dużo… Inna powszechna sytuacja: jest maszyna wirtualna z lokalnym magazynem na serwerze i trzeba zwiększyć dysk, ale nie ma gdzie, ponieważ na serwerze nie pozostało wolnego miejsca na dysku.

Problem można rozwiązać na różne sposoby – na przykład, migrując na inny serwer (jeśli taki istnieje) lub dodając nowe dyski do serwera. Ale nie zawsze da się to zrobić, dlatego migracja z LVM do Ceph może być doskonałym rozwiązaniem tego problemu. Wybierając tę opcję, upraszczamy także dalszy proces migracji między serwerami, ponieważ nie trzeba będzie przenosić lokalnego magazynu z jednego hypervisora na inny. Jedyną przeszkodą jest to, że trzeba będzie na chwilę zatrzymać VM podczas prac.

Jako przytaczany poniżej przepis wykorzystano artykuł z tego bloga, którego instrukcje zostały przetestowane w praktyce. Nawiasem mówiąc, opisana jest tam również metoda migracji bez przestojów, jednak w naszym przypadku nie była potrzebna, więc jej nie sprawdzaliśmy. Jeśli jednak jest to krytyczne dla Twojego projektu – z przyjemnością poznamy wyniki w komentarzach.

Przystąpmy do części praktycznej. W przykładzie wykorzystujemy virsh i, odpowiednio, libvirt. Na początek upewnij się, że pula Ceph'a, do której będą migrowane dane, jest podłączona do libvirt:

virsh pool-dumpxml $ceph_pool

W opisie puli powinny znajdować się dane połączenia z Ceph wraz z danymi do autoryzacji.

Następny etap polega na tym, że obraz LVM konwertowany jest na Ceph RBD. Czas realizacji zależy przede wszystkim od rozmiaru obrazu:

qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_name

Po konwersji pozostanie obraz LVM, który będzie przydatny w przypadku, gdy migracja VM do RBD się nie powiedzie i trzeba będzie cofnąć zmiany. Również – aby mieć możliwość szybkiego cofnięcia zmian – wykonamy kopię zapasową pliku konfiguracyjnego maszyny wirtualnej:

virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml

… i edytujemy oryginał (vm_name.xml). Znajdź blok z opisem dysku (zaczyna się od wiersza <disk type='file' device='disk'> i kończy na </disk>) i przekształcimy go w następujący sposób:

Przeanalizujmy kilka szczegółów:

W protokole source wskazujemy adres do pamięci w Ceph RBD (jest to adres z określeniem nazwy puli Ceph i obrazu RBD, który był definiowany w pierwszym etapie).
W bloku secret wskazuje typ ceph, a także UUID sekretu do połączenia z nim. Jego uuid można znaleźć za pomocą polecenia virsh secret-list.
W bloku Najciekawsza linia — ostatnia. wskazują adresy monitorów Ceph.

Po edycji pliku konfiguracyjnego i zakończeniu konwersji LVM do RBD, możemy zastosować zmieniony plik konfiguracyjny i uruchomić maszynę wirtualną:

virsh define $vm_name.xml
virsh start $vm_name

Teraz warto sprawdzić, czy maszyna wirtualna uruchomiła się poprawnie: można to zweryfikować na przykład, łącząc się z nią przez SSH lub przez virsh.

Jeżeli maszyna wirtualna działa poprawnie i nie napotkałeś innych problemów, możesz usunąć obraz LVM, który nie jest już używany:

lvremove main/$vm_image_name

Podsumowanie

Z wszystkimi opisanymi przypadkami mieliśmy do czynienia w praktyce — mamy nadzieję, że instrukcje pomogą również innym administratorom rozwiązać podobne problemy. Jeśli masz uwagi lub inne podobne historie z doświadczeń w pracy z Ceph — chętnie je zobaczymy w komentarzach!