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.
| Kryteria optymalizacji | Przykładowa konfiguracja |
| IOPS |
|
| Wydajność |
|
| Koszt / Pojemność |
|
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.
Zapraszam lektury do kolejnej części Jaka konfiguracja jest optymalna dla klastra Ceph?, gdzie wyjaśniam kwestie optymalnego doboru rodzaju, wielkości oraz ilości dysków dla węzła OSD.
