Inżynier z firmy Clyso podsumował doświadczenia związane z tworzeniem klastra przechowywania opartego na odpornej na awarie, rozproszonej systemie Ceph z przepustowością przekraczającą tebibajt na sekundę. Zauważono, że to pierwszy klaster oparty na Ceph, który osiągnął taki wynik, ale przed uzyskaniem przedstawionego rezultatu inżynierowie musieli pokonać szereg nieoczywistych pułapek.
Na przykład, aby zwiększyć wydajność o 10-20%, wystarczyło włączyć na serwerach w ustawieniach oszczędzania energii BIOS tryb maksymalnej wydajności i wyłączyć c-state (c-state zmienia parametry oszczędzania energii w zależności od obciążenia, co wpływa na Ceph). Okazało się również, że podczas korzystania z dysków NVMe jądro Linux poświęca znaczną ilość czasu na obsługę spin-locków w trakcie aktualizacji mapowania IOMMU. Wyłączenie IOMMU w jądrze doprowadziło do zauważalnego wzrostu wydajności w testach zapisu i odczytu bloków o rozmiarze 4MB.
Jednak wyłączenie IOMMU nie rozwiązało problemu z spadkiem wydajności przy losowym zapisie bloków o rozmiarze 4KB. Zgłębiając tę kwestię, inżynierowie natrafili na poprawki w skryptach budowania Ceph z projektów Gentoo i Ubuntu, które obejmowały budowę z opcją RelWithDebInfo, ponieważ w tym przypadku w GCC stosowano tryb optymalizacji „-O2”, który znacznie zwiększał wydajność Ceph. Do spadku wydajności przyczyniała się również kompilacja z biblioteką TCMalloc. Zmiana flag kompilacji i zaprzestanie korzystania z TCMalloc doprowadziła do trzykrotnego zmniejszenia czasu kompresji (compaction) oraz podwojenia wydajności losowych operacji zapisu blokami 4K. Na koniec dodatkowo zoptymalizowano ustawienia Reef RocksDB oraz grupy umiejscowienia (PG).
Klaster utworzono z 68 węzłów na bazie serwerów Dell PowerEdge R6615 z CPU AMD EPYC 9454P 48C/96T. Każdy węzeł zawiera 10 dysków NVMe Dell 15.36TB, dwa adaptery Ethernet 100GbE Mellanox ConnectX-6 oraz 192 GB RAM. Oprogramowanie jest oparte na Ubuntu 20.04.6 i Ceph 17.2.7. W klastrze składającym się z 63 węzłów uruchomiono 630 OSD (Object Storage Daemon, proces tła zarządzający przechowywaniem danych w lokalnym magazynie, po jednym OSD na dysk NVMe), trzy procesy MON (monitor, śledzący stan klastra) oraz jeden proces MGR (Manager, zarządzający usługą). Rozmiar magazynu wynosi 8.2 PB.
Przepustowość podczas sekwencyjnych operacji odczytu bloków 4M wyniosła 1025 GiB/s, a zapisu — 270 GiB/s. Przy losowym odczycie bloków 4KB wydajność osiągnęła 25,5 milionów operacji odczytu na sekundę i 4,9 mln przy zapisie. Włączenie szyfrowania zmniejszyło przepustowość podczas odczytu do około 750 GiB/s. Przy użyciu kodów korekcji błędów EC62 przepustowość wyniosła 547 GiB/s przy odczycie i 387 GiB/s przy zapisie (prędkość zapisu okazała się wyższa niż bez zastosowania kodów korekcji), a przy dostępie losowym 3,4M IOPS przy odczycie i 936K IOPS przy zapisie.
Dodatkowo można zauważyć, że we wrześniu podobny poziom przepustowości w tebibajtach na sekundę osiągnięto w klastra eksabajtowego przechowywania CERN, zrealizowanego na bazie otwartego rozproszonego systemu przechowywania EOS, opartego na protokole XRootD.
Źródło: opennet.ru
