Jestem wielkim fanem Ceph, open-source’owego, masowo skalowalnego rozwiązania pamięci masowej definiowanej programowo. Jego zdolność do samoregeneracji i radzenia sobie w obliczu traumatycznych wydarzeń w klastrze (straciłeś węzeł? nie ma problemu!), w połączeniu z brakiem pojedynczych punktów awarii, czyni go moim ulubionym rozwiązaniem.
Poniżej przedstawiam trzy proste zasady, które mogą pomóc w projektowaniu dużych lub małych klastrów.
Jeśli twoim głównym celem są dolary na megabajt pamięci masowej, to naturalnie możesz kierować się w stronę serwerów, które mogą obsłużyć największą liczbę dysków i największe dyski, jakie możesz dostać.
Trzeba tu zachować ostrożność. Istnieje kilka kwestii związanych z „wąskimi i głębokimi” klastrami:
- Każdy węzeł przechowuje większy procent danych klastra. Przykład: w klastrze z trzema węzłami każdy węzeł przechowuje 33% danych. W klastrze dziesięciowęzłowym jest to tylko 10% na węzeł. Utrata pojedynczego węzła w małym klastrze spowoduje znacznie większą migrację danych, zwłaszcza gdy klaster zacznie się zapełniać, i potencjalnie awarię, jeśli nie skonfigurowałeś poprawnie współczynników pełnych i zbliżonych do pełnych w klastrze.
- Wymuszanie większego ruchu sieciowego na mniejszej liczbie węzłów. Ceph jest sieciowym systemem pamięci masowej, więc przy mniejszej liczbie węzłów wymuszasz duży ruch kliencki na mniejszej liczbie NIC. Sytuacja pogarsza się wraz ze wzrostem liczby dysków na węzeł, ponieważ masz więcej OSD konkurujących o ograniczoną przepustowość. Co gorsza, podczas zdarzeń odzyskiwania ruch związany z odzyskiwaniem konkuruje z ruchem we/wy klientów w sieci, co jeszcze bardziej pogarsza wrażenia użytkowników.
- W przypadku dużej liczby dysków na węzeł kontroler dysków może być wąskim gardłem, jeśli nie ma wystarczającej przepustowości do obsługi wszystkich dysków z pełną prędkością.
- Większy czas odzyskiwania i leczenia w przypadku utraty całego węzła, ponieważ więcej danych musi być replikowanych i odzyskiwanych.
Zagregowana wydajność klastra skaluje się bardzo dobrze wraz ze wzrostem liczby węzłów. Tutaj można znaleźć porównanie 3-węzłowego vs 5-węzłowego klastra z BlueStore.
Jeśli dążysz do dużego klastra, oprzyj się pokusie upakowania wszystkich dysków w jak najmniejszej liczbie węzłów.
Podsumowując:
- Ceph bardzo dobrze skaluje się wraz ze wzrostem liczby węzłów.
- Mając zbyt mało węzłów w klastrze, umieszczasz więcej danych klastra na każdym węźle, zwiększając liczbę operacji wejścia/wyjścia i czasy odzyskiwania.
- Możesz zacząć od zaledwie trzech węzłów, ale jeśli możesz sobie pozwolić na rozłożenie dysków na więcej węzłów, lepiej to zrobić.
Bądź hojny z siecią
Nie ma sensu umieszczać szybkich nośników w serwerze, a następnie ograniczać je połączeniem sieciowym 1GbE. Celuj w 10GbE dla produkcji, co najmniej, a jeszcze lepiej poszukaj wielu interfejsów 10Gb połączonych za pomocą Link Aggregation Control Protocol (LACP) dla zwiększenia przepustowości. Ceph jest sieciowym systemem pamięci masowej, więc jedną z rzeczy, których nie powinno zabraknąć w klastrze, jest przepustowość sieci.
Zawsze oddzielaj swoją sieć publiczną od wewnętrznej sieci klastra. Sieć publiczna będzie przenosić ruch kliencki, natomiast sieć wewnętrzna będzie przenosić ruch związany z pracą serca, replikacją i odzyskiwaniem danych między OSD. Jeśli możesz zaoszczędzić na kartach NIC, przeprowadź te dwie sieci przez oddzielne interfejsy. Rozdzielenie ich poprawia reaktywność klientów podczas zdarzeń odzyskiwania i pomaga w szybszym zakończeniu zdarzeń odzyskiwania, ponieważ operacje we/wy odzyskiwania nie konkurują z operacjami we/wy klientów na tym samym NIC.
Pamiętajmy też, że sieć wewnętrzna przenosi ruch replikacyjny, więc każdy zapis w sieci publicznej spowoduje (n-1) zapisów w sieci wewnętrznej, gdzie n to liczba replik. Ceph potwierdzi zapis do klienta dopiero wtedy, gdy zostanie on zapisany w dzienniku/WAL wszystkich replik – nie chcesz więc, aby zapisy replikacyjne były wąskim gardłem w sieci. Jeśli intensywnie korzystasz z puli replikowanych, zastanów się, czy sieć klastra jest n-1 razy większa niż sieć publiczna.
Na koniec, dla redundancji, upewnij się, że podłączasz węzły do redundantnych przełączników top of rack. Nie chcesz stracić całego węzła – lub zestawu węzłów – ponieważ pojedynczy przełącznik zawiódł!
Podsumowując:
- 10Gbit Ethernet dla produkcji na minimum.
- Oddziel swoją sieć publiczną od klastrowej, najlepiej na różne NIC, ale przynajmniej na różne VLANy/podsieci.
- Pamiętaj o zasadzie (n-1) dla replikowanych danych – rozważ rozmiar swojej sieci wewnętrznej, aby była n-1 razy większa niż publiczna.
- Nie zapomnij o okablowaniu w celu zapewnienia redundancji oraz o prawidłowym ustanowieniu wiązań na poziomie systemu operacyjnego.
- I jako dodatek: nie zapomnij o ramkach jumbo na swoich interfejsach!
Nośnik flash dla metadanych BlueStore.
Ceph potwierdza zapis do klienta dopiero wtedy, gdy dane zostaną zapisane w dzienniku WAL (write-ahead log) głównego OSD i w WAL wszystkich replik. Zatem im szybszy zapis do WAL, tym szybciej Ceph potwierdzi zapis i tym lepsze IOPS dla klienta.
Twoje WAL, a najlepiej metadane BlueStore RocksDB, powinny znajdować się na najszybszym nośniku, jaki można uzyskać – minimum SSD, a jeśli to możliwe, NVMe. Jeśli budujesz klaster z pełnym dyskiem twardym, zdecydowanie rozważ wydanie nieco więcej na węzeł i dodanie co najmniej dwóch szybkich urządzeń medialnych dla metadanych i WAL.
Aby uniknąć wąskich gardeł na szybkim urządzeniu medialnym, rozważ stałą prędkość zapisu na dyskach danych i porównaj ją ze stałym zapisem na szybkim urządzeniu. Jeśli dysk HDD może zapisywać z trwałą prędkością 100 MB/s, a dysk SSD może zapisywać z trwałą prędkością 500 MB/s, wówczas więcej niż 4-5 dysków OSD na dysk SSD spowoduje wąskie gardło dysku SSD w zakresie zapisu. NVMe jest idealnym rozwiązaniem w tym przypadku, ponieważ ich trwałe prędkości zapisu mogą sięgać gigabajtów na sekundę.
Na koniec, zawsze miej więcej niż jedno urządzenie SSD/NVMe na węzeł dla metadanych/WAL, aby zapewnić, że nie stracisz wszystkich OSD w węźle, jeśli urządzenie metadanych ulegnie awarii.
Podsumowując:
- Ceph potwierdza zapis do klienta, gdy został on zapisany w WAL głównego OSD i WAL wszystkich replik. Robi to, aby zachować integralność twoich danych.
- WAL i RocksDB powinny znajdować się na najszybszych nośnikach, jakie możesz uzyskać – najlepiej NVMe – aby uzyskać odpowiedź do klienta tak szybko, jak to możliwe.
- Nie przesadź z szybkimi urządzeniami dla swoich WAL / RocksDB. Jeśli to zrobisz, przesuniesz wąskie gardło na swoje szybkie urządzenie.
- Miej więcej niż jedno szybkie urządzenie, aby uniknąć utraty wszystkich OSD na węźle, jeśli urządzenie WAL zawiedzie.
Podsumowanie
Ceph to sieciowy system pamięci masowej definiowany programowo, który wyjątkowo dobrze skaluje się w poziomie. Powyżej przedstawiamy tylko kilka zasad, które pomogą Ci stworzyć wydajny system – nie wchodź zbyt wąsko lub głęboko, utrzymuj klaster zasilany pasmem i używaj szybkich nośników dla swoich metadanych i WAL.
.