część 2: wydajność pamięci blokowej Ceph w klastrze All – Flash z interfejsem BlueStore

wprowadzenie

Podsumowanie: w blogu Episode – 1 omówiliśmy RHCS, wprowadzenie BlueStore, szczegóły sprzętu laboratoryjnego, metodologię benchmarkingu i porównanie wydajności między domyślną konfiguracją Ceph a dostrojoną konfiguracją Ceph

jest to drugi odcinek serii Performance blog na Rhcs 3.2 BlueStore działający na klastrze All-Flash. Nie ma reguły kategoryzowania rozmiarów bloków do kategorii małych, średnich i dużych. W związku z tym wyznaczyliśmy 4K do kategorii małych bloków, 8K-64K do średniej i 1M-4M do kategorii dużych bloków. W tym odcinku dowiesz się o charakterystyce wydajności pamięci bloku Ceph dla małych (4K), średnich (8K-32K) i dużych (1M-4M) rozmiarów bloków we wzorcach losowego odczytu, losowego zapisu i losowego odczytu i zapisu.

Streszczenie

• małe obciążenie bloku 4K, dostarczone do 2.2 miliony losowych odczytów, 691k losowego odczytu i zapisu(70/30) i 463k losowego zapisu IOPS do czasu ograniczenia przez CPU i media contention.
• podobnie jak w przypadku małych bloków, stwierdzono, że wydajność średnich bloków jest ograniczona przez procesor i media.
• duży blok obciążenia 4M Szczytowa wydajność rejestrowana przy 10,9 GB / s dla wszystkich trzech wzorców testowych, tj. losowy odczyt, zapis i Odczyt-Zapis (70/30) mieszają się do czasu ograniczenia przepustowości sieci klienta.

Część 1: Wydajność małego bloku (4KB)

kluczowe wiadomości

• losowe obciążenie pracą pokazało 2.2 miliony IOPS@3ms średnie opóźnienie do wąskiego gardła przez nasycenie mediów.
• losowy odczyt-Zapis (70/30) obciążenie mix wykazało 691k IOPS@6ms średnie opóźnienie do momentu wąskiego gardła przez Ceph node contention zasobów procesora CPU.
• losowy zapis: 463k IOPS@11ms średnie opóźnienie aż do wąskiego gardła przez Ceph node CPU resource contention.

podsumowanie

w tej części testów Interfejs pamięci blokowej Ceph został wykonany z małym obciążeniem bloku (4KB) we wzorcach losowego odczytu, losowego zapisu i losowego odczytu-zapisu (70/30). Kluczowe wskaźniki przechwycone podczas testów obejmują IOPS, średnią, opóźnienie, CPU węzła Ceph i wykorzystanie mediów.

wykres-1 pokazuje najwyższą wydajność dla rozmiaru bloku 4K w różnych wzorcach dostępu z 5 węzłami typu all-flash. W związku z tym stwierdzono, że maksymalna wydajność

• losowy odczyt: 2,2 miliona IOPS@ 3ms średnie opóźnienie
• losowy odczyt-Zapis (70/30) Mix: 691k IOPS @6ms średnie opóźnienie
• losowy zapis: 463k IOPS@11ms średnie opóźnienie

hzastosowanie procesora i mediów uchwycone w graph-2 i graph-3 pomogło nam zrozumieć wąskie gardła dla różnych wzorców obciążenia.

• okazało się, że wydajność losowego odczytu jest wąska przez niezgodność z zasobami procesora, jednak wykorzystanie mediów okazało się również wyższe. W związku z tym dodaliśmy dodatkowe węzły Ceph (CPU i media), wydajność odczytu losowego mogła wzrosnąć.
• zarówno w przypadku losowego zapisu, jak i losowego zapisu do odczytu (70/30) wydajność była ograniczona przez wyższe zużycie procesora. Co ciekawe w tym samym czasie media miały wystarczającą przepustowość, która pozostała niewykorzystana z powodu braku mocy obliczeniowej. W związku z tym wyższa alokacja rdzenia procesora na płyty OSD Ceph mogła zapewnić wyższą wydajność dla losowego zapisu & losowych obciążeń mieszanych do odczytu i zapisu.

wykorzystanie urządzenia danych OSD (P4500 NVMe) pozostało poniżej 50% wykorzystania, urządzenie Intel Optane p4800, które hostowało metadane BlueStore WAL i Rocksdb, okazało się bardzo zajęte na 90%. Parametr bluestore_min_alloc_size_ssd został ustawiony na 16KB, stąd wszystkie zapisy poniżej 16KB zostały odroczone, zapis najpierw przechodzi do urządzenia WAL, a następnie asynchronicznie zostaje zapisany do danych OSD, stąd urządzenie Optane P4800 pochłonęło zapisy dla wszystkich OSD na hoście. Pomimo dużego wykorzystania urządzenia RocksDB / WAL, nie widzieliśmy żadnych oznak niezgody na urządzeniu danych OSD P4500. Ale bazując na tym doświadczeniu, nie zalecamy umieszczania więcej niż 7 urządzeń P4500 NVMe za pojedynczym Intel Optane P4800 dla WAL/RocksDB.

wykres 2

Wykres 3

kolejnym ciekawym testem był client sweep test, w którym liniowo zwiększyliśmy liczbę klientów od 20 do 140. Zwiększając obciążenie klienta, obserwowaliśmy liniową poprawę wydajności, aż do momentu przeciążenia CPU na Ceph OSD. W przypadku 100 klientów zaobserwowaliśmy ~ 445k zagregowanych 4K write IOPS. Po tym przeciążeniu zasobów systemowych powodowało duże opóźnienia ogonowe. Intel Optane używany jako metadane pomógł wchłonąć skok opóźnień z dużą liczbą równoległych klientów, ponieważ takie średnie opóźnienie pozostało poniżej 40 ms.

G

Cz. 2: Średni rozmiar bloku wydajność

kluczowe odpowiedzi

• dopóki wydajność nie została ograniczona przez nasycenie procesora i mediów, 5 węzłów Ceph all-flash dostarczyło ~1,8 miliona losowych odczytów, ~636K losowego odczytu (70/30) i ~410k losowego zapisu IOPS.
• aby zwiększyć wydajność, konieczne było dodanie dodatkowych węzłów OSD Ceph w istniejącym klastrze Ceph.

podsumowanie

na poniższych wykresach staraliśmy się przedstawić różne punkty danych, takie jak IOPS, średnie opóźnienie, opóźnienie ogona, CPU węzła Ceph i wykorzystanie mediów. A wszystko to w zakresie wielkości bloku, tj. od 4K do 64K dla losowego zapisu, losowego odczytu i losowego odczytu-zapisu (70/30).

kilka interesujących punktów danych obejmuje

• zgodnie z oczekiwaniami, małe rozmiary bloków wykazały najwyższe IOPS i niższe średnie i opóźnienia ogonowe w porównaniu do średnich rozmiarów bloków. W związku z tym zaobserwowaliśmy odpowiednio ~1,8 miliona, ~636K, ~410k IOPS dla losowego odczytu, losowego odczytu i losowego zapisu.
• wysokie wykorzystanie zaobserwowano na urządzeniach CPU i multimedialnych na węzłach Ceph OSD. Wykorzystanie okazało się być tak wysokie, jak ~90% i ~80% odpowiednio dla procesora i mediów. W związku z tym wydajność mogłaby wzrosnąć, gdyby dodaliśmy węzły Ceph OSD do istniejącego klastra Ceph.

G

Część 3: Wydajność dużego bloku

kluczowe rozwiązania

• wydajność dużego bloku 4M osiągnęła szczyt 10.9 GB/s do losowego odczytu, zapisu i odczytu-zapisu (70/30).
• sieć klienta okazała się czynnikiem ograniczającym i powodującym wąskie gardło wydajności.
• wydajność mogłaby być wyższa, gdybyśmy mieli więcej węzłów klienckich lub większe rury sieciowe.

podsumowanie

wszystkie różne wzorce, które przetestowaliśmy, tj. losowy odczyt, zapis i Odczyt-Zapis (70/30) mix dla dużych bloków o rozmiarze 4M z łączną przepustowością 10,9 GB/s. Sieć klienta okazała się czynnikiem ograniczającym powodującym wąskie gardło wydajności. Poza siecią drugim najczęściej wykorzystywanym zasobem były media, jednak miał on wystarczająco dużo miejsca, aby zapewnić większą wydajność, jeśli sieć nie była wąskim gardłem.

G

do góry dalej

kontynuując serię blogów benchmarkingowych, w następnej sekcji wyjaśnimy wyniki związane z testowaniem skalowalności RHCS 3.2. Odpowiadając na kilka kluczowych pytań, takich jak „jak zmienia się wydajność, przechodząc z klastra węzłów 3 do węzłów 5”. Zostańcie Z Nami.