Wraz ze wzrostem popularności gry Rook chcemy porozmawiać o jej pułapkach i problemach, które mogą pojawić się po drodze.
O mnie: Doświadczenie w administracji Ceph od wersji Hammer, założyciel społeczności w telegramie.
Aby nie być gołosłownym, będę odwoływał się do postów akceptowanych przez Habr (sądząc po ocenie) na temat problemów z ceph. Ja również napotkałem większość problemów w tych postach. Linki do wykorzystanych materiałów znajdują się na końcu posta.
W poście o Rook wspominamy o ceph nie bez powodu — Rook to w zasadzie ceph zawinięty w kubernetes, co oznacza, że dziedziczy wszystkie jego problemy. Zacznijmy od problemów ceph.
Uproszczenie zarządzania klastrem
Jedną z zalet Rooka jest łatwość zarządzania Ceph za pośrednictwem Kubernetesa.
Jednakże ceph zawiera ponad 1000 parametrów konfiguracyjnych, podczas gdy poprzez rook możemy edytować tylko niewielką ich część.
Przykład na Luminous
> ceph daemon mon.a konfiguracja pokaż | wc -l
1401
Rook jest pozycjonowany jako wygodny sposób instalacji i aktualizacji Ceph
Instalacja Ceph bez Rooka nie nastręcza żadnych problemów — podręcznik Ansible można napisać w 30 minut, ale istnieje wiele problemów z aktualizacją.
Cytat z postu Kroka
Przykład: nieprawidłowa obsługa strojów Crush po aktualizacji z hummera do klejnotu
> ceph osd crush show-tunables
{
...
„wersja_obliczeń_słomy”: 1,
„allowed_bucket_algs”: 22,
„profil”: „nieznany”,
„optymalne_regulacje”: 0,
...
}
Ale nawet w mniejszych wersjach występują problemy.
Przykład: Aktualizacja 12.2.6 wprowadza klaster w stan błędu kondycji i warunkowo uszkodzonego PG
Nie aktualizować, czekać i testować? Ale wydaje się, że używamy Rook dla wygody aktualizacji, między innymi.
Złożoność klastra odzyskiwania po awarii w Rook
Przykład: OSD ulega awarii, rzucając błędy u swoich stóp. Podejrzewasz, że problem leży w jednym z parametrów w konfiguracji, chcesz zmienić konfigurację dla konkretnego demona, ale nie możesz, ponieważ masz kubernetes i DaemonSet.
Nie ma alternatywy. Polecenie ceph tell osd.Num injectargs nie działa — OSD jest wyłączone.
Złożoność debugowania
W przypadku niektórych ustawień i testów wydajnościowych musisz połączyć się bezpośrednio z gniazdem demona OSD. W przypadku Rooka najpierw musisz znaleźć pożądany kontener, a następnie wejść do niego, znaleźć brakujące narzędzia debugowania i bardzo się zdenerwować.
Trudność sekwencyjnego podnoszenia OSD
Przykład: OSD spada na OOM, rozpoczyna się rebalansowanie, po czym spadają następne.
Rozwiązanie: Uruchom OSD jeden po drugim, poczekaj, aż zostaną w pełni uwzględnione w klastrze, i uruchom następne. (Więcej szczegółów w raporcie Ceph. Anatomia katastrofy).
W przypadku instalacji baremetal wykonuje się to po prostu ręcznie; w przypadku Rook i jednego OSD na węzeł nie ma szczególnych problemów; problemy z sekwencyjnym podnoszeniem pojawią się, jeśli OSD > 1 na węzeł.
Oczywiście, że są one rozwiązywalne, ale dla uproszczenia wprowadzamy Rooka i otrzymujemy komplikację.
Trudności z wyborem limitów dla demonów Ceph
W przypadku instalacji baremetal ceph dość łatwo jest obliczyć wymagane zasoby dla klastra — istnieją wzory i badania. W przypadku korzystania ze słabych procesorów nadal będziesz musiał przeprowadzić szereg testów wydajnościowych, dowiedzieć się, czym jest Numa, ale nadal jest to prostsze niż w Rook.
W przypadku Rooka, oprócz limitów pamięci, które można obliczyć, pojawia się pytanie o ustawienie limitu procesora.
I tutaj będziesz musiał się namęczyć z testami wydajności. W przypadku niedoszacowania limitów otrzymasz wolny klaster, w przypadku ustawienia unlim otrzymasz aktywne użycie procesora podczas rebalansowania, co będzie miało zły wpływ na Twoje aplikacje w kubernetes.
Problemy z siecią v1
W przypadku ceph zaleca się używanie sieci 2x10Gb. Jedna dla ruchu klienta, druga dla potrzeb usługi ceph (rebalansowanie). Jeśli korzystasz z ceph na baremetal, to ta separacja jest łatwa do skonfigurowania, jeśli korzystasz z Rook, to separacja według sieci sprawi ci problemy, ponieważ nie każda konfiguracja klastra pozwala na dostarczanie dwóch różnych sieci do podu.
Problemy z siecią v2
Jeśli odmówisz rozdzielenia sieci, to podczas rebalansowania ruch ceph zatka cały kanał, a Twoje aplikacje w kubernetes spowolnią lub ulegną awarii. Możesz zmniejszyć prędkość rebalansowania ceph, ale wtedy z powodu długiego rebalansowania, otrzymasz zwiększone ryzyko wypadnięcia drugiego węzła z klastra na dyskach lub OOM, a następnie jest gwarantowany tylko do odczytu dla klastra.
Długie ponowne równoważenie - długie spowolnienia aplikacji
Cytat z posta Cepha: Anatomia katastrofy.
Test wydajności klastra:
Operacja zapisu 4 KB trwa 1 ms, a przepustowość wynosi 1000 operacji na sekundę w 1 wątku.
Operacja o rozmiarze 4 MB (rozmiar obiektu) trwa 22 ms, wydajność wynosi 45 operacji na sekundę.
Dlatego też, gdy jedna z trzech domen ulegnie awarii, klaster przez jakiś czas będzie w stanie zdegradowanym, a połowa aktywnych obiektów zostanie rozproszona w różnych wersjach, wówczas połowa operacji zapisu rozpocznie się od wymuszonego odzyskiwania.
Czas wymuszonego odzyskiwania obliczamy w przybliżeniu jako czas operacji zapisu do zdegradowanego obiektu.
Najpierw odczytujemy 4 MB w 22 ms, zapisujemy 22 ms, a następnie w 1 ms zapisujemy 4 KB rzeczywistych danych. Łącznie 45 ms na jedną operację zapisu do zdegradowanego obiektu na dysku SSD, gdy nasza standardowa wydajność wynosiła 1 ms - 45-krotny spadek wydajności.
Im większy procent zdegradowanych przedmiotów posiadamy, tym wszystko staje się bardziej przerażające.
Okazuje się, że szybkość rebalansowania ma kluczowe znaczenie dla prawidłowej pracy klastra.
Ustawienia specyficzne dla serwera dla ceph
Ceph czasami wymaga specyficznego dostrojenia hosta.
Przykład: ustawienia sysctl i ten sam JumboFrame. Niektóre z tych ustawień mogą negatywnie wpłynąć na ładunek.
Prawdziwe potrzeby Rooka pozostają kwestią otwartą
Jeśli korzystasz z chmury, masz dostęp do pamięci masowej udostępnianej przez dostawcę chmury, co jest o wiele wygodniejsze.
Jeśli korzystasz z własnych serwerów, zarządzanie Ceph będzie wygodniejsze bez Kubernetesa.
Czy wynajmujesz serwery w jakimś tanim hostingu? Wtedy będziesz miał dużo zabawy z siecią, jej opóźnieniami i przepustowością, co wyraźnie negatywnie wpływa na ceph.
Razem: Implementacja kuberentes i implementacja storage to różne zadania z różnymi danymi wejściowymi i różnymi opcjami rozwiązań - mieszanie ich oznacza potencjalnie niebezpieczny kompromis na korzyść jednego lub drugiego. Bardzo trudno będzie połączyć te rozwiązania nawet na etapie projektowania, a jest jeszcze okres operacyjny.
Lista wykorzystanej literatury:
Ale mówisz, że Ceph... czy on naprawdę jest taki dobry?
Cef. Anatomia katastrofy
Źródło: www.habr.com
