Wysokie limity

Limit maksymalnej liczby maszyn wirtualnych uruchomionych w ramach hosta to 500 przy 3250 wirtualnych procesorach na host. Maksymalny rozmiar pamięci obsługiwany przez pojedynczy host to 1 TB. Do pojedynczej maszyny wirtualnej możemy przypisać do 16 wirtualnych procesorów i 128 GB RAM. Maksymalny rozmiar wirtualnego dysku to 2TB, niezależnie czy jest to dysk NFS czy LVM. Jedna maszyna wirtualna może mieć podłączonych do 7 interfejsów sieciowych. W ramach puli zasobów możemy zgromadzić do 16 hostów, w tej puli możliwe jest jednoczesne uruchomienie do 3 procesów migracji na żywo za pomocą XenMotion.

Wydaje się, że w większości aplikacji nie uda nam się osiągnąć limitów tego rozwiązania, chociaż w kilku elementach (obsługiwana pamięć, procesory logiczne są one niższe niż w przypadku komercyjnej konkurencji.

Zobacz również:

• AI ma duży apetyt na prąd. Google znalazł na to sposób

Wykorzystanie pamięci przez wirtualizator

Ważną informacją przy planowaniu zasobów serwera pod wirutalizację jest narzut wykorzystania pamięci, jaki wprowadza samo wykorzystanie hypervisora. W przypadku rozwiązania Citrixa jest to rozmiar pamięci wykorzystywany przez Control Domain na hoście oraz jądro o nazwie Xen Server Crash Kernel czyli część oprogramowania wykorzystywana w sytuacjach awaryjnych. Konieczny obszar pamięci jest rezerwowany automatycznie. Jeśli host ma poniżej 24 GB pamięci RAM alokowane jest 752 MB, w coraz popularniejszych konfiguracjach powyżej 64 GB jest to już 4 GB RAM. Należy uwzględnić różnicę pomiędzy fizyczną pamięcią a tą rezerwowaną przez wirtualizator przy określaniu parametrów hosta i jego zamawianiu.

XenServer posiada także narzędzie optymalizacji wykorzystania pamięci przez maszyny wirtualne. Rozwiązanie o nazwie Dynamic Memory Control (DMC) zapewnia dynamiczną kontrolę pamięci przydzielanej do poszczególnych maszyn VM w zależności od parametrów minimalnego i maksymalnego rozmiaru pamięci oraz priorytetu maszyny.

Pule zasobów

Pula zasobów (resource poll) to bardzo ważny mechanizm XenServera pozwalający na grupowanie hostów i zarządzanie ich jako jednostką. W ramach puli zasobów gromadzimy oprócz hostów także zasoby dyskowe oraz sieciowe, z których mogą one wspólnie korzystać. W ramach puli można dokonać szybkiej migracji maszyny wirtualnej z jednego hosta na drugi.

Jeden z hostów w puli musi zostać wybrany na hosta głównego puli (Pool Master). Host taki kontroluje całość działań administracyjnych w ramach puli. Rozwiązanie nie zakłada pojedynczego punktu awarii. Dzięki temu, jeśli Pool Master ulegnie awarii pozostałe hosty w puli kontynuują pracę podobnie, jak uruchomione na nich maszyny wirtualne. W sytuacji, gdy nie powiedzie się przywrócenie do pracy Pool Mastera inny host w puli może przejąć jego zadania. Proces ten jest zautomatyzowany dzięki funkcjonalności wysokiej dostępności (high availability).

Dane konfiguracyjne puli zasobów są przechowywane na każdym hoście wchodzącym w jej skład, dzięki temu mechanizm promowania dowolnego hosta do pracy jako Pool Master jest możliwy. Również wszelkie zmiany wprowadzone do konfiguracji puli na serwerze Pool Master są automatycznie propagowane na pozostałe hosty. Gdy dodajemy nowy host do puli otrzymuje on automatycznie ustawienia konfiguracyjne dla pamięci masowej i sieci przypisane do niej.

Rekomendowane jest wykorzystywanie procesorów tego samego typu w ramach hostów przypisanych do jednej puli. Tworzą one wtedy homogeniczną pulę zasobów (homogeneous resource pool). Możliwe jest jednak stworzenie puli heterogenicznej (heterogeneous resource pool), co zawdzięczamy takim technikom opracowanym przez producentów procesorów jak Intel FlexMigration oraz AMD Extended Migration. Zapewniają one mechanizm maskowania procesora, dzięki czemu można skonfigurować procesor, tak aby przedstawiał się pod inną marką, modelem i z innymi funkcjami niż rzeczywiście ma. Pozwala to na tworzenie puli z maszyn z różnymi procesorami i umożliwia ich bezpieczną migrację.

XenMotion - migracja VM na żywo

Za migrację maszyn na żywo odpowiada mechanizm o nazwie XenMotion. Możemy wykorzystywać go do przenoszenia maszyn pomiędzy hostami zgromadzonymi w jednej puli. Przeniesienie maszyny możemy wykonać podczas jej pracy ręcznie poprzez odpowiednią zmianę w GUI XenCenter czy odpowiednią komendę linii komend. Możliwe jest także automatyczne przenoszenie maszyn przez mechanizm równoważenia obciążenia. Kiedy zauważy on, że jeden z hostów jest zbyt obciążony a na innym hoście w puli są wystarczające zasoby, może zdecydować o automatycznym przeniesieniu wirtualnej maszyny na inny host. W przypadku, gdy hosty mają wspólne zasoby dyskowe przenoszony jest jedynie stan maszyny ponieważ pozostałe dane znajdują się na pamięci masowej, do której wszystkie hosty puli mają dostęp. Migracja na żywo w tym wypadku może być więc bardzo szybka. Proces migracji na żywo odbywa się w tle, dopiero gdy nowe środowisko maszyny wirtualnej jest gotowe następuje przełączenie. Opóźnienie w samym przełączeniu i przywróceniu widoczności maszyny determinuje szybkość rekonfiguracji sieci – przeniesienie adresu IP oraz MAC i propagacja tej informacji w sieci. Zwykle trwa to ułamki sekund powodując krótkotrwałe opóźnienie w odpowiedzi na ping.