Jaka konfiguracja jest optymalna dla klastra Ceph? - część 2

Jaka konfiguracja jest optymalna dla klastra Ceph? – część 2

12/11/2019
Podziel się

W pierwszej części artykułu Jak zbudować wydajny klaster Ceph? Testy, optymalizacja, architektura – część 1 skupiliśmy się na kryteriach optymalizacji klastra Ceph i przedstawiliśmy przykładową konfigurację sprzętową dla węzłów OSD.

W tej części skupimy się na optymalnym doborze rodzaju, wielkości oraz ilości dysków dla węzła OSD.

Często przy wyborze sprzętu zastanawiamy się, jaka konfiguracja sprzętowa najlepiej spełni nasze potrzeby. Z pomocą przychodzą dostawcy sprzętu, którzy posiadają dedykowany sprzęt pod rozwiązania oparte o klaster Ceph. Niektórzy producenci dostarczają biuletyny zawierające przykładową architekturę rozwiązania oraz przeprowadzają szczegółowe testy, które mogą pomóc nam w doborze optymalnej konfiguracji.

W tym artykule skupię się na wynikach testów, które przeprowadził Red Hat wraz z Supermicro. Pokazują one, jak ilość węzłów OSD wpływa na przepustowość zapisu oraz odczytu w klastrze Ceph.

Producent do budowy klastra wykorzystał serwery o następującej konfiguracji sprzętowej: 

  • CPU: Dual Intel Xeon E5-2630v2 CPUs
  • RAM: 128 GB DDR3-1333,
  • SSD: Seagate ST200FM0053 200GB
  • PCIe (NVMe): Intel DC P3700 NVMe flash SSD

W zależności od ilości dysków skorzystano z różnych przepustowości interfejsów sieciowych:

  • 12 x 4TB (1 x PCIe): Intel 2x 10 GbE
  • 12 x 6TB (1 x PCIe): Intel 2x 10 GbE
  • 30 x 4TB (6 x SSD): Intel 2x 10 GbE
  • 36 x 4TB (2 x PCIe): Mellanox 40 GbE
  • 36 x 6TB (2 x PCIe): Mellanox 40 GbE
  • 60 x 4TB (12 x SSD): Mellanox 40 GbE
  • 72 x 6TB: 2x 10Gb/s: Mellanox 40 GbE

Podczas testu wykorzystano łącznie dwa interfejsy sieciowe 10GbE: pierwszy dla ruchu “public” oraz drugi dla ruchu sieciowego “cluster”. W przypadku interfejsów 40GbE ruch dla sieci “public” oraz “cluster” był obsługiwany przez jeden interfejs sieciowy. W teście wykorzystano filestore jako backing store oraz zabezpieczenie danych w postaci 3 x replik per HDD.

Poniższa tabela prezentuje różne konfiguracje, dla których był wykonywany test. W pierwszym etapie został wykonany test sprawdzający odczyt i zapis sekwencyjny dla poszczególnych konfiguracji. Najlepszą wydajność w tym teście osiągnął węzeł 4U z 60 x 4TB dyskami HDD oraz 12 x SSD z 80 TB dostępnej przestrzeni dla użytkownika. Odczyt na poziomie 2,202 MB/s zapis 601 MB/s z 40GbE interfejsem sieciowym. Węzły w konfiguracji 12 x 4-6TB (1 x PCIe) osiągają podobne rezultaty.

Węzły w konfiguracji 12 x 4-6TB (1 x PCIe) osiągają podobne rezultaty.

Kolejny test dla klastra o wielkości 50TB został przeprowadzony tylko dla konfiguracji czterech serwerów 2U 12 x 4TB (1x PCIe) ze względu na zabezpieczenie danych w postaci  3 x repliki per HDD. W tej konfiguracji klaster Ceph osiągnie odczyt na poziomie 3540 MB/s oraz zapis na poziomie 1118 MB/s. W przypadku gdy potrzebujemy 500TB przestrzeni, najlepszą konfiguracją będzie wykorzystanie serwerów 2U 12 x 4TB (1 x PCIe) z interfejsem 2 x 10 GbE. Serwery 12 x 4-6TB (1 x PCIe), które różnią się jedynie wielkością dysku HDD, w przypadku większej ilości osiągają zupełnie inne rezultaty niż w indywidualnym teście. Odczyt dla konfiguracji 12 x 6TB (1 x PCIe) jest blisko mniejszy o 10 000 MB/s. 

Odczyt dla konfiguracji 12 x 6TB (1 x PCIe) jest blisko mniejszy o 10 000 MB/s.

W klastrze o wielkości 1PB najlepsze rezultaty osiąga konfiguracja węzłów 2U 12 x 4TB (1 x PCIe), osiągając szybkość odczytu na poziomie 55 GB/s i zapisu na poziomie 18 GB/s. Niestety węzły wypadają najgorzej, jeżeli chodzi o ilość wykorzystanych węzłów do stworzenia klastra.

W klastrze o wielkości 1PB najlepsze rezultaty osiąga konfiguracja węzłów 2U 12 x 4TB (1 x PCIe), osiągając szybkość odczytu na poziomie 55 GB/s i zapisu na poziomie 18 GB/s.

Najwydajniejszą konfiguracją przy 500TB – 1PB klastrach jest wykorzystanie serwerów 2U składających się z 12 x 4TB dysków HDD i jednego dysku SSD NVMe (PCIe). Zaskakujący może być dość wysoki spadek odczytu i zapisu dla identycznej konfiguracji, z tym że wykorzystującej 6 TB dyski HDD. Powyższa tabela pozwala na zobrazowanie i dobranie najlepszej konfiguracji sprzętowej dla naszego środowiska. 

W kolejnej części Co możemy zrobić aby poprawić wydajność klastra Ceph omówię elementy rozwiązania, na których warto się skupić podczas optymalizacji istniejącego klastra Ceph.

Zobacz również

4 thoughts on “Jaka konfiguracja jest optymalna dla klastra Ceph? – część 2

  1. Witam,
    Jakiej pojemności muszą być karty NVMe dla noda o 36 dyskach 6TB aby sprawnie to działało. Zastanawiałem się na dwoma kartami NVMe o pojemności 1,6TB. Czy to wystarczy?

    1. Do wyliczenia rozmiaru dziennika w przypadku filestore wykorzystuje się następujący wzór:
      osd journal size = 2 * (expected throughput * filestore max sync interval)

      Jeżeli założymy że „throughput” dysku nvme/ssd to około 1.5 GB/s i 'filestore max sync interval’ wynosi 5 to rozmiar dziennika 'journal size’ będzie wynosić 15GB = 2 * 1.5 * 5.
      Podsumowując dla 18 dysków będzie potrzebnych około 270GB na nvme. Niekiedy można spotkać się z wyliczeniem journal size w następujący sposób (nvme disk size / amount of disks per nvme). Przykładowo dla dysku o pojemności 1.5TB będzie to około 80GB (~83GB = 1500 GB / 18 ). W przypadku nvme liczy się bardziej szybkość odczytu / zapisu niż pojemność dysku.

      1. Dzięki za odpowiedź. Pytam bo chciałem zastosować raczej bluestore i jest w dokumentacji taka informacja:

        „When using a mixed spinning and solid drive setup it is important to make a large-enough block.db logical volume for Bluestore. Generally, block.db should have as large as possible logical volumes.

        It is recommended that the block.db size isn’t smaller than 4% of block. For example, if the block size is 1TB, then block.db shouldn’t be less than 40GB.

        If not using a mix of fast and slow devices, it isn’t required to create separate logical volumes for block.db (or block.wal). Bluestore will automatically manage these within the space of block”.

        Zastanawiam się co się stanie jeśli nie spełnię tego warunku 4%. Czy masz jakieś doświadczenie?

    2. W przypadku środowisk produkcyjnych staramy się trzymać wymagań ciężko jest mi jednoznacznie odpowiedzieć jak konfiguracja będzie przekładać się na wydajność. Wymaga to wykonania testów klastra ceph i oceny czy taka konfiguracja będzie działać wydajnie.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

    Skontaktuj się z nami