W związku z rosnącą popularnością Rooka, chciałbym porozmawiać o jego pułapkach i problemach, które czekają na Ciebie po drodze.
O mnie: Doświadczenie w administracji cephami od wersji młotkowej, założyciel społeczności w telegramie.
Żeby nie było bezpodstawnie, odniosę się do postów zaakceptowanych przez Habra (sądząc po ocenie) na temat problemów z ceph. Napotkałem również większość problemów w tych postach. Linki do wykorzystanych materiałów znajdują się na końcu wpisu.
W poście o Rooku nie bez powodu wspominamy o ceph - Rook to w zasadzie ceph owinięty w kubernetes, co oznacza, że dziedziczy wszystkie jego problemy. Zacznijmy od problemów z ceph.
Uprość zarządzanie klastrem
Jedną z zalet Rooka jest łatwość zarządzania ceph poprzez kuberentes.
Jednak ceph zawiera ponad 1000 parametrów do konfiguracji, podczas gdy jednocześnie poprzez Rook możemy edytować tylko niewielką ich część.
Przykład na Luminous
> demon ceph mon.a pokaż konfigurację | wc -l
1401
Rook jest pozycjonowany jako wygodny sposób instalacji i aktualizacji ceph
Nie ma problemów z instalacją ceph bez Rooka - podręcznik ansible jest napisany w 30 minut, ale jest sporo problemów z aktualizacją.
Cytat z postu Kroka
Przykład: strojenie Crush nie działa poprawnie po aktualizacji z hummera do klejnotu
> ceph osd Crush show-tunables
{
...
„straw_calc_version”: 1,
„allowed_bucket_algs”: 22,
"profil": "nieznany",
"optymalne_tunable": 0,
...
}
Ale nawet w mniejszych wersjach występują problemy.
Przykład: aktualizacja 12.2.6 wprowadzająca klaster w stan błędu kondycji i warunkowo zepsuta PG
Nie aktualizujesz, czekasz i testujesz? Ale wydaje się, że używamy Rooka, między innymi dla wygody aktualizacji.
Złożoność klastra odzyskiwania po awarii w Rook
Przykład: OSD spada z lawiną błędów. Podejrzewasz, że problem leży w którymś z parametrów w konfiguracji, chcesz zmienić konfigurację dla konkretnego demona, ale nie możesz, bo masz kubernetes i DaemonSet.
Nie ma alternatywy. ceph tell osd.Num injectargs nie działa - OSD kłamie.
Trudność w debugowaniu
Niektóre konfiguracje i testy wydajności wymagają bezpośredniego podłączenia do gniazda OSD demona. W przypadku Rooka najpierw musisz znaleźć żądany kontener, następnie wejść do niego, znaleźć brakujące narzędzia do debugowania i bardzo się zdenerwować.
Trudności w sekwencyjnym zwiększaniu OSD
Przykład: OSD wypada w OOM, rozpoczyna się rebalans, po którym spadają kolejne.
Rozwiązanie: Podnoś OSD pojedynczo, poczekaj, aż zostanie całkowicie uwzględnione w klastrze i podnoś kolejne. (Więcej szczegółów w raporcie Cepha. Anatomia katastrofy).
W przypadku instalacji baremetal robi się to po prostu ręcznie, w przypadku Rooka i jednego OSD na węzeł nie ma szczególnych problemów; problemy z naprzemiennym podnoszeniem pojawią się, jeśli OSD > 1 na węzeł.
Oczywiście można je rozwiązać, ale używamy Rooka, aby uprościć rzeczy, ale uzyskać większą złożoność.
Trudność w wyborze limitów dla demonów ceph
W przypadku instalacji ceph typu baremetal dość łatwo jest obliczyć wymagane zasoby dla klastra - istnieją wzory i dostępne są badania. Jeśli używasz słabego procesora, nadal będziesz musiał przeprowadzić kilka testów wydajności, aby dowiedzieć się, czym jest Numa, ale nadal jest to łatwiejsze niż Rook.
W przypadku Rooka, oprócz limitów pamięci, które można obliczyć, pojawia się kwestia ustawienia limitu procesora.
I tutaj będziesz musiał ciężko pracować z testami wydajności. Jeśli obniżysz limity, otrzymasz powolny klaster; jeśli ustawisz unlim, uzyskasz aktywne użycie procesora podczas ponownego równoważenia, co będzie miało zły wpływ na twoje aplikacje w Kubernetes.
Problemy z siecią v1
W przypadku ceph zalecane jest użycie sieci 2x10GB. Jeden dla ruchu klienckiego, drugi dla potrzeb usług ceph (rebalance). Jeśli mieszkasz z cephem na baremetalu to ten podział da się łatwo skonfigurować, jeśli mieszkasz z Rookiem to dzielenie po sieciach sprawi ci problemy, gdyż nie każda konfiguracja klastra pozwala na zasilenie kapsuły dwiema różnymi sieciami .
Problemy z siecią v2
Jeśli odmówisz rozdzielenia sieci, to podczas przywracania równowagi ruch ceph zablokuje cały kanał, a Twoje aplikacje w Kubernetes spowalniają lub ulegają awarii. Można zmniejszyć prędkość równoważenia ceph, ale wtedy ze względu na długie równoważenie zwiększa się ryzyko wypadnięcia drugiego węzła z klastra przez dyski lub OOM, a dla klastra jest już gwarantowany tylko odczyt.
Długie przywracanie równowagi - długie opóźnienia aplikacji
Cytat z postu Cepha. Anatomia katastrofy.
Testuj wydajność klastra:
Operacja zapisu o rozmiarze 4 KB zajmuje 1 ms, wydajność wynosi 1000 operacji/sekundę w 1 wątku.
Operacja o wielkości 4 MB (rozmiar obiektu) zajmuje 22 ms, wydajność wynosi 45 operacji/sekundę.
W rezultacie, jeśli jedna z trzech domen ulegnie awarii, klaster będzie przez pewien czas w stanie zdegradowanym, a połowa gorących obiektów zostanie rozproszona w różnych wersjach, wówczas połowa operacji zapisu rozpocznie się od wymuszonego odzyskiwania.
Obliczamy w przybliżeniu czas wymuszonego odzyskiwania - operacje zapisu do zdegradowanego obiektu.
Najpierw odczytujemy 4 MB w 22 ms, zapisujemy 22 ms, a następnie w ciągu 1 ms zapisujemy 4 KB rzeczywistych danych. Łącznie 45 ms na operację zapisu do zdegradowanego obiektu na dysku SSD, gdy standardowa wydajność wynosiła 1 ms – 45-krotny spadek wydajności.
Im wyższy procent zdegradowanych obiektów mamy, tym wszystko staje się gorsze.
Okazuje się, że szybkość rebalansowania jest krytyczna dla poprawnej pracy klastra.
Specyficzne ustawienia serwera dla ceph
ceph może wymagać specjalnego dostrojenia hosta.
Przykład: ustawienia sysctl i ta sama ramka JumboFrame. Niektóre z tych ustawień mogą negatywnie wpłynąć na ładunek.
Prawdziwe zapotrzebowanie na Rooka pozostaje kwestionowane
Jeśli korzystasz z chmury, masz przestrzeń dyskową od swojego dostawcy usług w chmurze, co jest znacznie wygodniejsze.
Jeśli korzystasz z własnych serwerów, zarządzanie ceph będzie wygodniejsze bez Kubernetes.
Czy wynajmujecie serwery od jakiegoś taniego hostingu? Będziesz miał wtedy niezłą zabawę z siecią, jej opóźnieniami i przepustowością, co wyraźnie negatywnie wpływa na ceph.
Razem: Implementacja kuberentes i implementacja pamięci masowej to różne zadania z różnymi danymi wejściowymi i różnymi opcjami rozwiązań — mieszanie ich oznacza dokonanie potencjalnie niebezpiecznego kompromisu na rzecz jednego lub drugiego. Połączenie tych rozwiązań już na etapie projektowania będzie bardzo trudne, a przed nami jeszcze okres eksploatacji.
Lista wykorzystanej literatury:
Ale mówisz, że Ceph... czy on naprawdę jest taki dobry?
Cef. Anatomia katastrofy
Źródło: www.habr.com