Wykorzystując Ceph jako pamięć sieciową w projektach o różnym obciążeniu, możemy napotkać różne zadania, które na pierwszy rzut oka nie wydają się proste i trywialne. Na przykład:
- migracja danych ze starego Cepha na nowy z częściowym wykorzystaniem poprzednich serwerów w nowym klastrze;
- rozwiązanie problemu alokacji miejsca na dysku w Ceph.
Radząc sobie z takimi problemami stajemy przed koniecznością prawidłowego usunięcia OSD bez utraty danych, co jest szczególnie istotne przy dużej ilości danych. Zostanie to omówione w artykule.
Metody opisane poniżej dotyczą każdej wersji Ceph. Dodatkowo brany będzie pod uwagę fakt, że Ceph może przechowywać dużą ilość danych: aby zapobiec utracie danych i innym problemom, niektóre działania zostaną „podzielone” na kilka innych.
Przedmowa o OSD
Ponieważ dwa z trzech omawianych przepisów są dedykowane OSD (), zanim przejdziemy do części praktycznej – krótko o tym, co jest w Ceph i dlaczego jest to takie ważne.
Przede wszystkim należy stwierdzić, że cały klaster Ceph składa się z wielu OSD. Im jest ich więcej, tym większa jest wolna ilość danych w Ceph. Stąd łatwo to zrozumieć główna funkcja OSD: Przechowuje dane obiektowe Ceph w systemach plików wszystkich węzłów klastra i zapewnia do nich dostęp sieciowy (w celu odczytu, zapisu i innych żądań).
Na tym samym poziomie parametry replikacji ustawiane są poprzez kopiowanie obiektów pomiędzy różnymi OSD. I tutaj możesz napotkać różne problemy, których rozwiązania zostaną omówione poniżej.
Sprawa nr 1. Bezpiecznie usuń OSD z klastra Ceph bez utraty danych
Konieczność usunięcia OSD może być spowodowana usunięciem serwera z klastra - na przykład zastąpienie go innym serwerem - co nam się przytrafiło i stało się powodem napisania tego artykułu. Zatem ostatecznym celem manipulacji jest wydobycie wszystkich OSD i monów na danym serwerze, aby można było je zatrzymać.
Dla wygody i aby uniknąć sytuacji, gdy wykonując polecenia pomylimy się przy wskazywaniu wymaganego OSD, ustawimy osobną zmienną, której wartością będzie numer OSD do usunięcia. Zadzwońmy do niej ${ID} — tutaj i poniżej taka zmienna zastępuje numer OSD, z którym pracujemy.
Spójrzmy na stan przed rozpoczęciem pracy:
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 rozpocząć usuwanie OSD, musisz sprawnie przeprowadzić operację reweight na nim do zera. W ten sposób zmniejszamy ilość danych w OSD, równoważąc je z innymi OSD. Aby to zrobić, uruchom 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, aż do zera.
Wymagane płynne równoważenieaby nie stracić danych. Jest to szczególnie prawdziwe, jeśli OSD zawiera dużą ilość danych. Aby się upewnić, że po wykonaniu poleceń reweight wszystko poszło dobrze, możesz to ukończyć ceph -s lub w oddzielnym uruchomieniu okna terminala ceph -w w celu obserwacji zmian w czasie rzeczywistym.
Kiedy OSD zostanie „opróżnione”, możesz kontynuować standardową operację, aby je usunąć. Aby to zrobić, przenieś żądane OSD do stanu down:
ceph osd down osd.${ID}„Wyciągnijmy” OSD z klastra:
ceph osd out osd.${ID}Zatrzymajmy usługę OSD i odmontujmy jej partycję w FS:
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}Usuń OSD z :
ceph osd crush remove osd.${ID}Usuńmy użytkownika OSD:
ceph auth del osd.${ID}I na koniec usuńmy samo OSD:
ceph osd rm osd.${ID}Operacja: Jeśli używasz wersji Ceph Luminous lub wyższej, powyższe kroki usuwania OSD można zredukować do dwóch poleceń:
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
Jeśli po wykonaniu opisanych powyżej kroków uruchomisz polecenie ceph osd tree, to powinno być jasne, że na serwerze, na którym wykonywana była praca, nie ma już OSD, dla których wykonano powyższe 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
Po drodze należy pamiętać, że stan gromady Ceph dojdzie do HEALTH_WARN, a także zaobserwujemy spadek liczby OSD i ilości dostępnego miejsca na dysku.
Poniżej opisano kroki, które będą wymagane, jeśli chcesz całkowicie zatrzymać serwer i odpowiednio usunąć go z Ceph. W tym przypadku warto o tym pamiętać Przed wyłączeniem serwera należy usunąć wszystkie OSD na tym serwerze.
Jeżeli na tym serwerze nie ma już OSD to po ich usunięciu należy wykluczyć serwer z mapy OSD hv-2uruchamiając następujące polecenie:
ceph osd crush rm hv-2
Usuwać mon z serwera hv-2uruchamiając poniższe polecenie na innym serwerze (tj. w tym przypadku na hv-1):
ceph-deploy mon destroy hv-2Następnie możesz zatrzymać serwer i rozpocząć kolejne działania (ponowne jego wdrożenie itp.).
Sprawa nr 2. Podział przestrzeni dyskowej w już utworzonym klastrze Ceph
Drugą opowieść rozpocznę wstępem o PG (). Główną rolą PG w Ceph jest przede wszystkim agregacja obiektów Ceph i dalsza replikacja ich w OSD. Wzór, za pomocą którego można obliczyć wymaganą ilość PG, znajduje się w Dokumentacja Cepha. Zagadnienie to również zostało tam omówione na konkretnych przykładach.
Zatem: jednym z typowych problemów podczas używania Ceph jest niezrównoważona liczba OSD i PG pomiędzy pulami w Ceph.
Po pierwsze, może dojść do sytuacji, gdy w małej puli zostanie określonych zbyt wiele PG, co w istocie oznacza irracjonalne wykorzystanie miejsca na dysku w klastrze. Po drugie, w praktyce istnieje poważniejszy problem: przepełnienie danych w jednym z OSD. Oznacza to, że klaster najpierw przechodzi do stanu HEALTH_WARN, i wtedy HEALTH_ERR. Dzieje się tak dlatego, że Ceph przy obliczaniu dostępnej ilości danych (można to sprawdzić np MAX AVAIL w wynikach polecenia ceph df dla każdej puli osobno) opiera się na ilości danych dostępnych w OSD. Jeśli w co najmniej jednym OSD nie ma wystarczającej ilości miejsca, nie można zapisać więcej danych, dopóki dane nie zostaną prawidłowo rozdzielone pomiędzy wszystkie OSD.
Warto wyjaśnić te problemy są w dużej mierze ustalane na etapie konfiguracji klastra Ceph. Jednym z narzędzi, z którego możesz skorzystać, jest . Za jego pomocą można wyraźnie obliczyć wymaganą ilość PG. Można się jednak po nią sięgnąć również w sytuacji, gdy klaster Ceph już skonfigurowany nieprawidłowo. Warto tutaj wyjaśnić, że w ramach prac naprawczych najprawdopodobniej będziesz musiał zmniejszyć liczbę PG, a ta funkcja nie jest dostępna w starszych wersjach Cepha (pojawiła się tylko w wersji ).
Wyobraźmy sobie więc następujący obraz: klaster ma status HEALTH_WARN z powodu braku miejsca w jednym z OSD. Zostanie to zasygnalizowane błędem HEALTH_WARN: 1 near full osd. Poniżej znajduje się algorytm wyjścia z tej sytuacji.
Przede wszystkim należy rozdzielić dostępne dane pomiędzy pozostałe OSD. Podobną operację wykonaliśmy już w pierwszym przypadku, kiedy „opróżniliśmy” węzeł - z tą tylko różnicą, że teraz będziemy musieli nieco zmniejszyć reweight. Na przykład do 0.95:
ceph osd reweight osd.${ID} 0.95Zwalnia to miejsce na dysku w OSD i naprawia błąd w stanie ceph. Jednakże, jak już wspomniano, problem ten występuje głównie z powodu nieprawidłowej konfiguracji Ceph na początkowych etapach: bardzo ważne jest dokonanie rekonfiguracji, aby nie pojawiła się ona w przyszłości.
W naszym konkretnym przypadku wszystko sprowadzało się do:
- wartość jest zbyt wysoka
replication_countw jednym z basenów, - za dużo PG w jednej puli i za mało w drugiej.
Skorzystajmy ze wspomnianego już kalkulatora. Jasno pokazuje, co należy wpisać i w zasadzie nie ma tu nic skomplikowanego. Po ustawieniu niezbędnych parametrów otrzymujemy następujące zalecenia:
Operacja: Jeśli konfigurujesz klaster Ceph od podstaw, kolejną przydatną funkcją kalkulatora jest generowanie poleceń, które utworzą od podstaw pule o parametrach podanych w tabeli.
Ostatnia kolumna pomaga w nawigacji - Sugerowana liczba PG. W naszym przypadku przydatny jest również ten drugi, gdzie wskazany jest parametr replikacji, gdyż zdecydowaliśmy się na zmianę mnożnika replikacji.
Najpierw więc musisz zmienić parametry replikacji - warto to najpierw zrobić, ponieważ zmniejszając mnożnik, zwolnimy miejsce na dysku. Po wykonaniu polecenia zauważysz, że dostępna przestrzeń dyskowa wzrośnie:
ceph osd pool $pool_name set $replication_size
A po jego zakończeniu zmieniamy wartości parametrów pg_num и 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_numberTo jest ważne: musimy zmieniać liczbę PG po kolei w każdej puli i nie zmieniać wartości w innych pulach, dopóki ostrzeżenia nie znikną „Pogorszona redundancja danych” и „n-liczba pgs uległa degradacji”.
Możesz także sprawdzić, czy wszystko poszło dobrze, używając wyników poleceń ceph health detail и ceph -s.
Sprawa nr 3. Migracja maszyny wirtualnej z LVM do Ceph RBD
W sytuacji, gdy w projekcie wykorzystywane są maszyny wirtualne zainstalowane na wynajętych serwerach typu bare-metal, często pojawia się kwestia przechowywania odpornego na awarie. Bardzo pożądane jest również, aby w tym magazynie było wystarczająco dużo miejsca... Inna częsta sytuacja: na serwerze znajduje się maszyna wirtualna z lokalną pamięcią masową i trzeba rozszerzyć dysk, ale nie ma dokąd pójść, bo nie ma wolne miejsce na dysku pozostałe na serwerze.
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. Jednak nie zawsze jest to możliwe, więc migracja z LVM do Ceph może być doskonałym rozwiązaniem tego problemu. Wybierając tę opcję, upraszczamy także dalszy proces migracji pomiędzy serwerami, ponieważ nie będzie konieczności przenoszenia lokalnego magazynu z jednego hypervisora na drugi. Jedynym haczykiem jest to, że będziesz musiał zatrzymać maszynę wirtualną na czas wykonywania pracy.
Poniższy przepis pochodzi z , którego instrukcja została sprawdzona w działaniu. Przy okazji, jest tam również opisany sposób bezproblemowej migracjijednak w naszym przypadku nie było to po prostu potrzebne, więc tego nie sprawdzaliśmy. Jeśli ma to kluczowe znaczenie dla Twojego projektu, z przyjemnością usłyszymy o wynikach w komentarzach.
Przejdźmy do części praktycznej. W przykładzie używamy virsh i odpowiednio libvirt. Najpierw upewnij się, że pula Ceph, do której będą migrowane dane, jest podłączona do libvirt:
virsh pool-dumpxml $ceph_poolOpis puli musi zawierać dane połączenia z Ceph wraz z danymi autoryzacyjnymi.
Następnym krokiem jest konwersja obrazu LVM do formatu Ceph RBD. Czas realizacji zależy przede wszystkim od wielkości obrazu:
qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_namePo konwersji pozostanie obraz LVM, który będzie przydatny w przypadku niepowodzenia migracji VM do RBD i konieczności wycofania zmian. Ponadto, aby móc szybko cofnąć zmiany, wykonajmy kopię zapasową pliku konfiguracyjnego maszyny wirtualnej:
virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml
... i edytuj oryginał (vm_name.xml). Znajdźmy blok z opisem dysku (zaczyna się od linii <disk type='file' device='disk'> i kończy się </disk>) i sprowadź go do następującej postaci:
<disk type='network' device='disk'>
<driver name='qemu'/>
<auth username='libvirt'>
<secret type='ceph' uuid='sec-ret-uu-id'/>
</auth>
<source protocol='rbd' name='$ceph_pool/$vm_image_name>
<host name='10.0.0.1' port='6789'/>
<host name='10.0.0.2' port='6789'/>
</source>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>Przyjrzyjmy się kilku szczegółom:
- Do protokołu
sourcewskazany jest adres do magazynu w Ceph RBD (jest to adres wskazujący nazwę puli Ceph oraz ustalony na pierwszym etapie obraz RBD). - W bloku
secrettyp jest wskazanyceph, a także UUID sekretu, aby się z nim połączyć. Jego identyfikator uuid można znaleźć za pomocą poleceniavirsh secret-list. - W bloku
hostwskazane są adresy monitorów Ceph.
Po edycji pliku konfiguracyjnego i zakończeniu konwersji LVM do RBD można zastosować zmodyfikowany plik konfiguracyjny i uruchomić maszynę wirtualną:
virsh define $vm_name.xml
virsh start $vm_name
Czas sprawdzić czy maszyna wirtualna uruchomiła się poprawnie: możesz się o tym przekonać łącząc się z nią poprzez SSH lub poprzez virsh.
Jeśli maszyna wirtualna działa poprawnie i nie znalazłeś innych problemów, możesz usunąć obraz LVM, który nie jest już używany:
lvremove main/$vm_image_namewniosek
Wszystkie opisane przypadki zetknęliśmy się w praktyce - mamy nadzieję, że instrukcje pomogą innym administratorom rozwiązać podobne problemy. Jeśli masz uwagi lub inne podobne historie z doświadczeń związanych z używaniem Ceph, będzie nam miło je zobaczyć w komentarzach!
PS
Przeczytaj także na naszym blogu:
- «";
- «";
- «";
- «".
Źródło: www.habr.com