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.
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.
Dodaj komentarz