Pamięci masowe definiowane programowo (SDS) rozwijają się w oszałamiającym tempie. W tej chwili mamy już do wyboru całą masę rozwiązań np. VMware vSAN, EMC ScaleIO (które bazuje na Ceph), GlusterFS, XtreemeFS czy w końcu Ceph. Niestety, jak do tej pory żadne z tych rozwiązań nie wspiera natywnie takich funkcji jak deduplikacja (jedynie vSAN 6.2 wspiera deduplikację i kompresję). W tym artykule pokażę jak zainstalować, na trzech nodach, klaster Ceph Jewel (czyli najnowszy stabilny) oparty na dyskach (OSD) sformatowanych za pomocą ZFS. Źródłem ZFS jest system Solaris (i firma SUN Microsystems, aktualnie Oracle), jest on w pełni przeportowany na system Linuks. Po raz pierwszy też uzyskał pełne wsparcie w systemie Ubuntu 16 LTS. Celem tego ćwiczenia jest przetestowanie deduplikacji w SDS (którą wspiera ZFS) i sprawdzenie czy jest to możliwe. Pamiętajcie jednak, Ceph oficjalnie nie wspiera OSD na ZFS.
Testowy klaster składa się z trzech wirtualnych maszyn z zainstalowanym Ubuntu 16 LTS (ich nazwy to uaceph1, uaceph2, uaceph3), pierwszy serwer będzie pełnił rolę serwera administracyjnego. Zanim zaczniemy, musimy spreparować odpowiednią, startową konfigurację na wszystkich nodach klastra. Dotyczy to dodania źródeł APT, poprawnego skonfigurowania proxy (jeśli korzystamy) oraz utworzenia użytkownika za pomocą którego będziemy nadzorowali instalację i pracę klastra Ceph (ssh). Dodatkowo musimy skonfigurować rozwiązywanie nazw nodów, robimy to albo poprzez DNS albo poprzez pliki /etc/hosts (wszystkie hosty muszą być w tej samej sieci i muszą się pingać poprzez krótkie nazwy). Dodajemy źródła APT (na każdym serwerze):
Konfigurujemy użytkownika (na każdym nodzie), w moim przypadku będzie to pulab. Konfigurujemy dla użytkownika klucze ssh (ssh-keygen z pustym hasłem) i za pomocą polecenia ssh-copy-id transferujemy klucz na wszystkie pozostałe nody (ssh-copy-id nazwa_hosta). W katalogu .ssh użytkownika tworzymy plik config w którym podajemy parametry połączeń:
Jeśli korzystamy z serwera proxy to w pliku /etc/apt/apt.conf podajemy dyrektywę Acquire::http::Proxy http://ugproxy1.pulab.local:8080; i dodatkowo proxy musi być wpisane w pliku /etc/environments.
Jeszcze raz, zanim zaczniecie dalszą konfigurację upewnijcie się, że wszystkie nody nawzajem rozwiązują swoje nazwy (długie i krótkie). Założony przez Was użytkownik może wykonywać ssh bez loginu i hasła na wszystkie nody oraz że na każdym nodzie macie zsynchronizowany czas (to bardzo ważne). Jeśli wszystko jest ok, to na pierwszym serwerze (administracyjnym) instalujemy pakiet ceph-deploy.
Z poziomu użytkownika administracyjnego tworzymy katalog (jego nazwa jest automatycznie nazwą klastra Ceph), wewnątrz tego katalogu wydajemy polecenie:
ceph-deploy new serwer1 serwer2 serwer3 (ważne aby podać wszystkie hosty)
W ten sposób tworzymy inicjalną konfigurację, na tym etapie dodajemy do pliku ceph.conf wszystkie linie zaczynając od public network. Wpisy dotyczące konfiguracji OSD są specyficzne dla wymogów współdziałania z ZFS (oprócz pool default size).
Gdy mamy przygotowany plik konfiguracyjny, wydajemy polecenie instalacji klastra na wszystkich nodach. Instalacja trwa dość długo, jeśli przerwie się na jednym z serwerów, możemy ją uruchomić jeszcze raz tylko dla wybranego serwera.
Po zainstalowaniu pakietów uruchamiamy stworzenie inicjalnej konfiguracji dla wszystkich monitorów.
Na tym etapie mamy skonfigurowany i działający klaster Ceph bez podłączonych dysków (OSD). Przy konfigurowaniu OSD użyjemy ZFS którego nie wspiera skrypt ceph-deploy, od tego momentu wszystkie kroki wykonamy ręcznie i na każdym serwerze osobno. Zaczynamy od wydania polecenia “ceph osd create”, numer który zostanie zwrócony to ID danego OSD (którym będziemy posługiwali się w dalszej konfiguracji).
Do każdego serwera mam dodane dwa dodatkowe dyski, na OSD przeznaczam /dev/sdb. Na tym dysku tworzymy pulę ZFS, pula obejmuje cały dysk i jest jednocześnie systemem plików (FS), możemy w ramach jednej puli stworzyć wiele FS (ale tutaj nie jest to potrzebne). Za pomocą polecenia zfs set mountpoint montujemy dysk w katalogu zgodnym z OSD ID, obrazek poniżej przedstawia konfigurację z serwera drugiego (uaceph2).
Poleceniem ceph-osd –i (ID OSD) –mkfs – mkkey tworzymy system plików Ceph i klucz autoryzacyjny. System plików w serwerze powinien wyglądać tak jak ten:
W kolejnym kroku sprawdzamy uprawnienia /var/lib/ceph/osd/ceph-ID na każdym serwerze, jeśli właściciel jest innych niż użytkownik ceph to zmieniamy na poprawne.
Ręcznie startujemy (aktywujemy) poszczególne OSD na każdym nodzie (systemctl start ceph-osd@ID), poleceniem “ceph osd tree” sprawdzamy czy OSD wstają poprawnie.
Na koniec sprawdzamy status całego klastra, powinniśmy otrzymać HEALTH_OK.
Gratuluję, mamy funkcjonujący klaster Ceph oparty na dyska z systemem plików ZFS. Możemy przystąpić do testów, będę korzystał z wolumenu blokowego RBD, dlatego dodaję do ceph.conf linijkę rbd_default_features = 3 (kernel w Ubuntu 16 LTS nie wpiera wszystkich rozwiązań z Ceph Jewel), nową konfigurację rozsyłamy poleceniem “ceph-deploy admin serwer1 serwer2 serwer3”. W kolejnym kroku tworzymy zasób blokowy poleceniem rbd create:
Jeśli zasób plikowy, to musi być sformatowany, tutaj użyty został ext4. Mamy tutaj swoistą incepcję, główne dyski OSD zostały sformatowane ZFS a wolumeny z nich wystawiane EXT (można na odwrót). Klient dostaje standardowy dysk który może sformatować dowolnym FS, natomiast po stronie SDS możemy włączyć globalnie deduplikację lub kompresję i będzie to przeźroczyste dla klienta. Zamontowany FS:
Czas na test, dysk RBD zapełniłem dziewięcioma obrazami ova maszyny wirtualnej (każdy wielkości 1GB) i kilkunastoma obrazami ISO. Przed włączeniem deduplikacji zasoby prezentują się tak:
Teraz przechodzimy do deduplikacji, najpierw upewnimy się że nie jest włączona i czy warto ją włączyć.
Nie jest włączona, polecenie zdb –S stara się zasymulować wartości jakie uzyskamy po włączeniu, wartość wyliczona to dedup = 2.18, czyli śmiało można włączyć deduplikację. W przypadku ZFS jest to niezwykle proste, ustawiamy parametr dedup=on i czekamy.
Jeżeli czekanie nas znudzi, to w ramach przyśpieszania możemy usunąć dane i wgrać je ponownie. Generalnie, deduplikacja działa znakomicie na obszarze całego klastra Ceph:
Gdzie możemy zastosować taką konfigurację? Na przykład w Proxmox VM który wspiera i ZFS i Ceph. Włączenie deduplikacji w SDS, gdzie dane są zwielokrotniane, może przynieść bardzo duże oszczędności przestrzeni dyskowej.