Jak zbudować wydajny klaster Ceph? Testy, optymalizacja, architektura – część 1

Ceph obecnie zdobywa bardzo dużą popularność wśród programowo definiowanych storage nazywanych również SDS (Software-defined storage). Rozwiązanie nie bez powodu cieszy się zainteresowaniem, ponieważ umożliwia współpracę z takimi rozwiązaniami jak OpenStack, OpenShift/OKD czy KVM/QEMU. Zapewnia również wiele metod dostępu do przechowywanych zasobów:

  • Ceph Native API (librados): natywna biblioteka pozwalająca aplikacjom na bezpośredni dostęp do obiektów, danych przechowywanych w klastrze;
  • Ceph Object Gateway: zapewnia RESTful API kompatybilne z Amazon S3 lub OpenStack Swift; Object Gateway jest również nazywany RADOS Gateway RADOSGW lub RGW; rozwiązania korzystające z modułu to między innymi Docker Registry, OpenStack Cinder (backup), s3fs-fuse, s3cmd;
  • Ceph Block Device (RBD, librbd): nazywany również Block Storage; z tego rozwiązania mogą korzystać między innymi QEMU/KVM i OpenStack Cinder, iSCSI;
  • Ceph File System (CephFS, libcephfs, MDS): klaster zapewnia również własny system plików, który do działania wymaga agenta MDS.

Wybierając rozwiązanie, zyskujemy również możliwość skalowania w poziomie „Scale-out”, jak również możliwość pracy w wielu ośrodkach „multi-site”.

W artykule chciałbym skupić się na dwóch głównych aspektach: wyborze odpowiedniej konfiguracji sprzętowej oraz narzędziach, sposobach optymalizacji klastra Ceph.

Ceph do działania w środowisku produkcyjnym nie stawia wysokich wymagań sprzętowych. Klaster minimalnie powinien składać się z 6 fizycznych węzłów (3 x ceph-mon, radosgw, mds, 3 x ceph-osd), aczkolwiek niekiedy można spotkać się z konfiguracją składającą się tylko 3 węzłów fizycznych. Minimalnie rekomendowane wymagania sprzętowe z podziałem na agentów została przedstawiona w poniższej tabeli:

Podzespoły Ceph-OSD Ceph-Mon Ceph-Radosgw Ceph-mds
Procesor 1x AMD64 or Intel 64 1x AMD64 or Intel 64 1x AMD64 or Intel 64 1x AMD64 or Intel 64
RAM 16 GB dla OS, 2GB RAM per OSD agent 1 GB per agent 1 GB per agent 1 GB per agent (zależy od „MDS cache size”)
Dysk Zalecany minimum jeden dysk 1TB per OSD agent, pomijając dysk systemowy 10 GB per agent 5 GB per agent 1MB per agent plus przestrzeń dla plików logu
Sieć 2 x Gigabit Ethernet NIC 2 x Gigabit Ethernet NIC 2 x Gigabit Ethernet NIC 2 x Gigabit Ethernet NIC

Oczywiście powyższa konfiguracja jest minimalną i w dużej mierze uzależnioną od wymagań klienta. Jeżeli poważnie zastanawiamy się nad stworzeniem klastra Ceph, to na początkowym etapie należy podjąć decycję o tym, które z modułów będą wykorzystane przez klaster.

Jaką konfigurację wybrać dla węzłów OSD?

Ważnym elementem podczas etapu projektowania klastra Ceph jest podjęcie decyzji o docelowym przeznaczeniu klastra. Wiele dokumentacji wyróżnia trzy główne ścieżki optymalizacji:

  • IOPS – wybierany dla rozwiązań wykorzystujących „block storage” z przeznaczeniem pod rozwiązania bazodanowe lub OpenStack-a;
  • Wydajność – skierowany dla rozwiązań korzystających z „block storage” lub „object storage”. Konfiguracja jest głównie przeznaczona do obsługi mediów strumieniowych; wideo, audio, obrazów;
  • Koszt/Pojemność – optymalny stosunek kosztu do pojemności. Rozwiązanie przeznaczone głównie pod „object storage” ukierunkowane do działania jako rozwiązanie do przechowywania kopii bezpieczeństwa, audio, wideo, obrazów.

W zależności od wybranego kryterium zaleca się wykorzystanie urządzeń o odpowiednich parametrach, które mają duży wpływ na wydajność działania klastra Ceph. Poniższa tabela zawiera przykładową konfigurację przewidzianą dla węzłów OSD.

Kryteria optymalizacji Przykładowa konfiguracja
IOPS
  • Przeznaczenie: Ceph RBD (block) pools
  • Zabezpieczenie danych: 3 x repliki dla HDD, 2 x repliki dla SSD
  • Backing store: BlueStore
  • Procesory: 10 x cpu 2 GHz per NVMe SSD,
  • RAM: 16GB pod OS, 2GB na każde OSD
  • Konfiguracja OSD:
    • 4x NVMe SSD P4500 4TB OSD, 1x NVMe SSD P4800X 375GB database (DB)/write-ahead log (WAL)
  • Kontroler: Natywna szyna PCIe
  • Sieć:
    • Zalecana: 2 x 10 GbE dla public network oraz 2 x 10 GbE cluster network
    • Najlepsza: 2 x 25 GbE dla public network oraz 2 x 25 GbE cluster network
Wydajność
  • Przeznaczenie: Ceph RBD (block) lub Ceph RGW (object)
  • Zabezpieczenie danych: 3 x repliki per HDD
  • Backing store: BlueStore
  • Procesory: 1 x cpu 2 GHz per SSD/HDD, 10 x cpu 2 GHz per NVMe SSD,
  • RAM: 16GB pod OS, 2GB per OSD
  • Konfiguracja OSD:
    • Dobra: 4 – 5 x HDD OSD, 1x SSD S4600 480GB database (DB)/write-ahead log (WAL)
    • Lepsza: 12 – 18 x HDD OSD, 1x NVMe SSD P4600 1TB database (DB)/write-ahead log (WAL)
    • Najlepsza: 12 – 18 x HDD OSD, 1x NVMe SSD P4600 1-2TB database (DB)/write-ahead log (WAL) + Intel Cache Acceleration Software (CAS)
  • Kontroler: JBOD lub RAID0
  • Sieć:
    • Ogólne zalecenia: 10 GbE per 12 OSDs
    • Lepsza: 2 x 10 GbE dla public network oraz 2 x 10 GbE cluster network
    • Najlepsza: 2 x 25 GbE dla public network oraz 2 x 25 GbE cluster network
Koszt / Pojemność
  • Przeznaczenie: Ceph RGW (object)
  • Zabezpieczenie danych: Erasure coding (CPU intensive)
  • Backing store: BlueStore
  • Procesory: 1 x cpu 2 GHz per HDD,
  • RAM: 16GB pod OS, 2GB per OSD,
  • Konfiguracja OSD:
    • Rozwiązanie oparte o dyski HDD, data + database (DB)/write-ahead log (WAL) na jednym dysku
  • Kontroler: JBOD
  • Sieć:
    • Ogólne zalecenia: 10 GbE per 12 OSDs

Kontroler

W większości przypadków kontrolery HBA obsługujące tryb JBOD są wystarczające dla węzłów OSD. Jednak niekiedy warto rozważyć konfigurację każdego dysku OSD w trybie RAID0. W przypadku losowych operacji I/O na małych blokach dyski HDD skonfigurowane jako pojedyńczy dysk w RAID0 zapewniają lepszą wydajność od skonfigurowanych w trybie JBOD.

Sekwencyjne operacje I/O na dużych blokach zazwyczaj lepiej wypadają w testach dla dysków HDD skonfigurowanych w trybie JBOD. Wiele kontrolerów posiada układ „SAS expander”, który mimo wielu zalet narzuca dodatkowe opóźnienie, ze względu na stosowanie STP w tunelowaniu SATA w SAS. W doborze dysków lub kontrolera ma czasami znaczenie producent oraz wersja używanego firmware.

Sieć

Węzły OSD, MON powinny posiadać dwa interfejsy sieciowe odpowiednio dla sieci:

  • cluster network (back-side) – dedykowana sieć wykorzystywana na potrzeby replikacji pg, awarii jednego z dysków osd oraz komunikacji pomiędzy węzłami OSD oraz MON;
  • public network (front-side) – sieć przeznaczona do komunikacji z klientami, węzłami korzystającymi z klastra.

Dla małych węzłów OSD, które posiadają 12-16 slotów na dyski, wystarczające jest wykorzystanie interfejsu sieciowego o przepustowości 10Gb. W przypadku węzłów OSD z 24-72 slotami zalecane są odpowiednio 25, 40, 50 Gb interfejsy ethernet lub infiniband. Przykładowo replikacja 1 TB danych przez interfejs 1Gb/s będzie trwać około 3 godzin odpowiednio 3 TB 9 godzin. W przypadku gdy wykorzystamy interfejs 10Gb/s replikacja będzie trwać odpowiednio dla dysku 1TB 20 minut i 1 godzinę dla dysku 3TB. Przy wyborze wielkości dysków, jak i ich ilości w węźle osd powinno dobrać się kartę sieciową o odpowiedniej przepustowości.

Ważnym elementem, który również należy wziąć pod uwagę, jest przepustowość interfejsu sieciowego po stronie klienta lub rozwiązania, które korzysta z klastra Ceph. Niekiedy okazuje się, że komunikacja pomiędzy klientem a klastrem odbywa się przez interfejs 10Gb/s po stronie klienta, co w przypadku dużych klastrów Ceph często staje się wąskim gardłem. Narzędziem wykorzystywanym do wykonywania testów typu „client do cluster” lub „cluster do cluster” jest iperf. To narzędzie pozwala na sprawdzenie i ocenę czy zastosowana konfiguracja sieciowa jest odpowiednia.

W kolejnej części, która ukaże się już niebawem, zastanowimy się nad optymalnym doborem ilości dysków dla węzła OSD oraz przedstawieniem różnic w przepustowości odczytu i zapisu dla różnych wielkości klastra Ceph.

Tags

Dodaj komentarz

avatar
2000
  Subscribe  
Powiadom o
top