Wirtualka w 7 sekund – jak skonfigurować macierz z SheepDog

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?

  1. Task – ładowanie dysku
  2. Task – zdefiniowanie wirtualnej maszyny
  3. Task – podłączenie karty sieciowej
  4. Odświeżanie listy wirtualnych maszyn co sekundę – max. 1s

Plus mały, pomijalny lag przeglądarki i komunikacji z nodami.

Leave a Reply

Your email address will not be published. Required fields are marked *