W związku z rosnącą popularnością Rook warto poruszyć jego pułapki i problemy, które mogą na Ciebie czekać.
O mnie: Doświadczenie w administrowaniu ceph od wersji hammer, założyciel społeczności. w Telegramie.
Aby nie być gołosłownym, będę się odwoływać do uznanych postów na Habrze (sądząc po ocenie) dotyczących problemów z ceph. Z większością problemów poruszanych w tych postach również się spotkałem. Linki do wykorzystanego materiału na końcu posta.
W poście o Rook wspominamy ceph nieprzypadkowo — Rook w zasadzie to ceph zamknięty w Kubernetesie, a więc dziedziczy wszystkie jego problemy. Z problemami ceph zaczniemy.
Uproszczenie zarządzania klastrem.
Jedną z zalet Rook jest wygodne zarządzanie ceph przez Kubernetes.
Jednak ceph zawiera ponad 1000 parametrów do konfiguracji, a przez Rook możemy zmieniać tylko mniejszą ich część.
Przykład na Luminous.
> ceph daemon mon.a config show | wc -l
1401
Rook jest pozycjonowany jako wygodny sposób instalacji i aktualizacji ceph.
Z instalacją ceph bez Rook nie ma problemów — playbook Ansible pisze się w 30 minut, a z aktualizacjami pojawia się wiele problemów.
Cytat z posta Krok.
Przykład: nieprawidłowe działanie crush tunables po aktualizacji z hummer do jewel.
> ceph osd crush show-tunables
{
…
"straw_calc_version": 1,
"allowed_bucket_algs": 22,
"profile": "unknown",
"optimal_tunables": 0,
…
}
Jednak nawet w ramach wersji mniejszych występują problemy.
Przykład: aktualizacja 12.2.6 prowadząca klaster do stanu health err i warunkowo uszkodzonego PG.
Nie aktualizować, czekać i testować? Ale chyba używamy Rook właśnie dla wygody aktualizacji.
Trudności w odzyskiwaniu klastrów w przypadku awarii w Rook.
Przykład: OSD awaria, generując błędy. Podejrzewasz, że problem jest w jednym z parametrów konfiguracji, chcesz zmienić ustawienia dla konkretnego demona, ale nie możesz, ponieważ masz Kubernetes i DaemonSet.
Nie ma alternatywy. ceph tell osd.Num injectargs nie działa — OSD leży.
Trudność w debugowaniu.
Dla niektórych ustawień i testów wydajnościowych konieczne jest bezpośrednie podłączenie się do gniazda demona osd. W przypadku Rook należy najpierw znaleźć odpowiedni kontener, a następnie do niego wejść, odkryć brakujące narzędzia do debugowania i bardzo się rozczarować.
Trudność w sekwencyjnej aktywacji OSD.
Przykład: OSD awaria z powodu OOM, następuje rebalance, a po tym występują kolejne awarie.
Rozwiązanie: Podnoś OSD po jednym, czekając na pełne włączenie do klastra przed podniesieniem następnego. (Szczegóły w raporcie Ceph. Anatomia katastrofy).
W przypadku instalacji baremetal to robi się po prostu ręcznie, w przypadku Rook i jednej OSD na węźle nie ma większych problemów, ale problemy z kolejnością podnoszenia wystąpią, jeśli OSD > 1 na węzeł.
Oczywiście, są one do rozwiązania, ale przecież wprowadzamy Rook dla uproszczenia, a otrzymujemy komplikacje.
Trudności z doborem limitów dla demonów ceph.
Dla instalacji baremetal w ceph dość łatwo obliczyć wymagane zasoby na klaster — są formuły i badania. Przy użyciu słabych CPU wciąż będziesz musiał przeprowadzić szereg testów wydajności, dowiedzieć się, czym jest Numa, ale to wciąż jest prostsze niż w Rook.
W przypadku Rook oprócz limitów pamięci, które można obliczyć, pojawia się pytanie o ustalenie limitu CPU.
I tu będziesz musiał się napracować nad testami wydajności. W przypadku zaniżenia limitów otrzymasz wolny klaster, przy ustawieniu unlim będziesz miał aktywne wykorzystanie CPU podczas rebalance, co źle wpłynie na Twoje aplikacje w kubernetes.
Problemy z interakcją sieciową v1.
Dla ceph zaleca się użycie sieci 2x10 gb. Jedna dla ruchu klienckiego, druga dla potrzeb serwisowych ceph (rebalance). Jeśli działasz z ceph na baremetal, to podział jest łatwy do skonfigurowania, ale działając z Rook, podział sieci sprawi Ci problemy, ponieważ nie każda konfiguracja klastra pozwala na przypisanie do podu dwóch różnych sieci.
Problemy z interakcją sieciową v2.
Jeśli zrezygnujesz z podziału sieci, podczas rebalance ruch ceph zablokuje cały kanał i Twoje aplikacje w kubernetes będą działać wolno lub się zawieszą. Można zmniejszyć prędkość rebalance ceph, ale wtedy ryzykujesz długi rebalance, co zwiększa ryzyko wykluczenia drugiego węzła z klastra z powodu dysków lub OOM, a wtedy masz już gwarantowane tylko do odczytu na klastrze.
Długi rebalance — długie spowolnienie aplikacji.
Cytat z posta Ceph. Anatomia katastrofy.
Wydajność testowego klastra:
Operacja zapisu o wielkości 4 Kb zajmuje 1 ms, wydajność 1000 operacji/sekundę w 1 wątku.
Operacja o wielkości 4 Mb (wielkość obiektu) zajmuje 22 ms, wydajność 45 operacji/sekundę.
W związku z tym, gdy jeden z trzech domen zawiedzie, klaster przez pewien czas znajduje się w stanie degradacji, a połowa gorących obiektów rozprzestrzenia się po różnych wersjach, niektóre operacje zapisu będą zaczynać się od wymuszonego przywracania.
Czas wymuszonego przywracania obliczamy w przybliżeniu — operacje zapisu w obiekcie w degradacji.
Najpierw odczytujemy 4 MB w ciągu 22 ms, zapisujemy przez 22 ms, a następnie 1 ms zajmuje zapisanie 4 KB konkretnego zestawu danych. Łącznie trwa to 45 ms na jedną operację zapisu w obiekcie w degradacji na SSD, podczas gdy normalna wydajność wynosiła 1 ms — spadek wydajności o 45 razy.
Im większy procent obiektów w degradacji, tym sytuacja staje się gorsza.
Okazuje się, że prędkość rebalance'u jest krytycznie ważna dla prawidłowego działania klastra.
Specyficzne ustawienia serwerów dla Ceph
Ceph często wymaga specyficznego tuningu hosta.
Przykład: ustawienia sysctl i JumboFrame; niektóre z tych ustawień mogą negatywnie wpływać na Twoje obciążenie.
Prawdziwa potrzeba Rook pozostaje pod znakiem zapytania.
Jeśli jesteś w chmurze, masz magazyn od swojego dostawcy chmurowego, co jest znacznie wygodniejsze.
Jeśli korzystasz z własnych serwerów, zarządzanie Ceph będzie łatwiejsze bez Kubernetes.
Czy wynajmujesz serwery w jakimś niedrogim hostingu? W takim razie czeka cię wiele zabawnych sytuacji z siecią, jej opóźnieniami i przepustowością, co wyraźnie negatywnie wpływa na Ceph.
Podsumowując: Wdrożenie Kubernetes i wdrożenie magazynu to różne zadania z różnymi wymaganiami i różnymi opcjami rozwiązań — ich mieszanie to ryzykowny trade-off na rzecz tego czy innego. Połączenie tych rozwiązań będzie bardzo trudne nawet na etapie projektowania, a co dopiero w okresie eksploatacji.
Lista wykorzystanej literatury:
A wy mówicie Ceph… czy naprawdę jest tak dobry?
Ceph. Anatomia katastrofy.
Źródło: habr.com
