Podczas sprawdzania działania CoreCluster z Debianem Stretch przetestowałem też macierz software’ową, opartą o Sheepdog, zamiast tradycyjnego udziału opartego o NFS + lokalne dyski. Wynik – niecałe 7 sekund od kliknięcia w interfejsie do otrzymania wirtualnej maszyny w stanie stopped.
Jak to działało do tej pory?
Domyślnie CoreCluster konfiguruje się w najprostszej konfiguracji do używania zasobu NFS. W panelu administratora podajemy IP i katalog z macierzy (lub jakiegokolwiek serwera) i wszystko się montuje automatycznie. Dyski bazowe dla wirtualek są kopiowane podczas tworzenia ich na lokalne dyski nodów (do lokalnego libvirt pool images). Wydajność poszczególnych wirtualek zależy wtedy głównie od wydajności lokalnego dysku i jego obciążenia przez inne wirtualki.
Czas dostarczenia zatrzymanej wirtualnej maszyny jest więc zależny głównie od tego, co startujemy. Kilku gigabajtowy dysk kopiuje się do kilku minut, w zależności od naszego sprzętu i sieci.
Jak to działa z Sheepdog?
Zanim niektórzy zaczną krzyczeć dlaczego nie Ceph albo Gluster – sheepdog odpala się prawie bezboleśnie dla administratora (o czym później) i nie ma absolutnie żadnego centralnego punktu klastra, co czasem może być plusem.
Jak więc to działa? Sheepdog po doinstalowaniu korzysta z Corosync zintegrowanego z CoreCluster do znalezienia innych węzłów w sieci. Od strony użytkownika pozwala on tworzyć dyski (odpowiednik block storage), które możemy wykorzystać m.in. w wirtualnych maszynach. Dzięki jego architekturze, każdy węzeł obsługujący Sheepdog’a ma taki sam dostęp do obiektów zapisanych na macierzy, niezależnie od położenia w sieci.
Podczas tworzenia klastra możemy podać w ilu miejscach na raz będą trzymane dane. Tak – w RAID możesz to zrobić wybierając odpowiednią konfigurację (RAID1, 5 itd.). W sheepdog podajesz po prostu ile kopii każdego dysku ma mieć Twój klaster:
dog cluster format --copies 3 |
Niezależnie od Twoich dysków o sprzętu, jeśli tylko ilość węzłów sheepdog’a pozwoli, będziesz on starał się tak rozłożyć dane, aby każdy fragment każdego dysku był zapisany w trzech różnych lokalizacjach. Oczywiście ma to wpływ na pojemność klastra.
CoreCluster, po dodaniu macierzy z transportem sheepdog wykorzystuje ją jako pojemnik na wszystkie swoje dyski. Obrazy użytkowników chmury są zapisywane oczywiście przez sheepdog, natomiast w odróżniniu od NFS, lokalne pule obrazów na nodach (te, w których są trzymane wirtualne maszyny, w /images) nie są wykorzystane. Zamiast tego CoreCluster zapisuje te obrazy również jako obrazy w sheepdog, pod trochę inną nazwą.
Plusem takiego rozwiązania jest to, że każdy dysk wirtualnej maszyny jest klonem swojego bazowego obrazu. Dzięki temu tworzenie wirtualnej maszyny trwa sekundy zamiast minut. Nie jest konieczne kopiowanie obrazów pomiędzy libvirt’owymi pulami podczas bootu. Dodatkowo Sheepdog nieco przyspiesza sam dostęp do danych – jeśli obraz ma więcej niż jedną kopię w sheepdog, to sam odczyt jest wtedy nieco szybszy w porównaniu do NFS i lokalnych obrazów.
Instalacja i konfiguracja macierzy
Management CoreCluster potrzebuje jednego dodatkowego pakietu – corecluster-storage-sheepdog. Zainstaluj go poleceniem:
apt-get install corecluster-storage-sheepdog |
Doinstaluje on wszystkie zależności. Następnie na każdym Compute Node doinstaluj sam pakiet sheepdog:
apt-get install sheepdog |
Następnie sprawdź, czy w plikach /etc/default/corosync oraz /etc/default/sheepdog oba demony są uruchamiane (parametr START=yes). Możesz też sprawdzić, czy są w uruchomionych procesach:
ps uax | grep corosync ... ps uax | grep sheep |
Sprawdź też, czy corosync jest poprawnie zainstalowany i skonfigurowany. Powinieneś widzieć wszystkie Compute Nody oraz Management:
corosync-cmapctl | grep member runtime.totem.pg.mrp.srp.members.167772417.config_version (u64) = 0 runtime.totem.pg.mrp.srp.members.167772417.ip (str) = r(0) ip(10.0.1.1) runtime.totem.pg.mrp.srp.members.167772417.join_count (u32) = 2 runtime.totem.pg.mrp.srp.members.167772417.status (str) = joined runtime.totem.pg.mrp.srp.members.167772418.config_version (u64) = 0 runtime.totem.pg.mrp.srp.members.167772418.ip (str) = r(0) ip(10.0.1.2) runtime.totem.pg.mrp.srp.members.167772418.join_count (u32) = 2 runtime.totem.pg.mrp.srp.members.167772418.status (str) = joined runtime.totem.pg.mrp.srp.members.167772419.config_version (u64) = 0 runtime.totem.pg.mrp.srp.members.167772419.ip (str) = r(0) ip(10.0.1.3) runtime.totem.pg.mrp.srp.members.167772419.join_count (u32) = 2 runtime.totem.pg.mrp.srp.members.167772419.status (str) = joined runtime.totem.pg.mrp.srp.members.167772670.config_version (u64) = 0 runtime.totem.pg.mrp.srp.members.167772670.ip (str) = r(0) ip(10.0.1.254) runtime.totem.pg.mrp.srp.members.167772670.join_count (u32) = 1 runtime.totem.pg.mrp.srp.members.167772670.status (str) = joined |
Jeśli wszystko działa, to Twój klaster sheepdog powinien być gotowy do użycia. Sformatuj go poleceniem:
dog cluster format --copies 2 |
Możesz oczywiście zmienić ilość kopii jeśli potrzebujesz. Następnie dodaj taką macierz do CoreCluster, w panelu administratora z następującymi parametrami:
- directory /var/lib/sheepdog (jest pomijane) przez sterownik
- address 127.0.0.1 (każdy node będzie miał swój własny punkt dostępu)
- transport sheepdog (najważniejszy parametr)
Oraz capacity według Twojego uznania.
To, czy sheepdog działa możesz sprawdzić kilkoma poleceniami:
dog node list Id Host:Port V-Nodes Zone 0 10.0.1.1:7000 129 16842762 1 10.0.1.2:7000 129 33619978 2 10.0.1.3:7000 129 50397194 3 10.0.1.254:7000 126 4261478410 |
Powinien wyświetlić listę wszystkich nodów oraz management
dog vdi create test 10M dog vdi list Name Id Size Used Shared Creation time VDI id Copies Tag test 0 10 MB 0.0 MB 0.0 MB 2017-11-03 09:17 7c2b26 2 |
Powinno utworzyć nowy dysk o rozmiarze 10M. Dysk ten powinien być widoczny z wszystkich nodów w klastrze oraz managementu.
Pozostało jeszcze ustawić sterownik w konfiguracji CoreCluster management i zrestartować wszystko. Znajdź listę APPS w pliku /etc/corecluster/config.py i zamień wpis:
'corecluster-storage-libvirt.app', |
na:
'corecluster-storage-sheepdog.app', |
Finalnie lista APPS powinna wyglądać mniej więcej tak:
APPS = [ 'corecluster.app', 'corecluster-auth-db.app', 'corecluster-algorithm-storage-default.app', 'corecluster-algorithm-node-fillup.app', 'corecluster-algorithm-id-uuid.app', 'corecluster-storage-sheepdog.app', 'corenetwork.app', 'coretalk.app', ] |
Na koniec restartujemy procesy agentów corecluster:
service corecluster restart
Przy pomyślnym układzie gwiazd i sprzyjającej koniunkcji Jowisza z Neptunem po restarcie macierz zamontuje się i będziesz mógł cieszyć się jej wydajnością.
Problemy?
Większość problemów jest związana z konfiguracją sieci na nodach lub management (plik pakietu CoreNetwork – /etc/corenetwork/config.py), która ma wpływ na konfigurację Corosync. Jeśli to działa poprawnie i corosync-cmapctl poprawnie listuje wszystkie węzły, to powinieneś bez problemu uruchomić całość.
ps. co się składa na wspomniane 7 sekund?
- Task – ładowanie dysku
- Task – zdefiniowanie wirtualnej maszyny
- Task – podłączenie karty sieciowej
- Odświeżanie listy wirtualnych maszyn co sekundę – max. 1s
Plus mały, pomijalny lag przeglądarki i komunikacji z nodami.