Porównanie i wyjaśnienie funkcji VMware vSphere HA i DRS

Hypervisor VMware umożliwia uruchamianie maszyn wirtualnych na jednym serwerze. Na pojedynczym hoście ESXi można uruchamiać wiele maszyn wirtualnych, a w celu uruchomienia większej liczby maszyn wirtualnych można wdrożyć wiele hostów. Jeśli dysponujesz wieloma hostami ESXi połączonymi w sieci, możesz migrować maszyny wirtualne z jednego hosta na drugi.

Czasami korzystanie z wielu hostów połączonych sieciowo do uruchamiania maszyn wirtualnych nie wystarcza, by zaspokoić potrzeby biznesowe. Na przykład w przypadku awarii jednego hosta wszystkie maszyny wirtualne znajdujące się na tym hoście również ulegną awarii. Ponadto obciążenia maszyn wirtualnych na hostach ESXi mogą być nierównomiernie rozłożone, a ręczna migracja maszyn wirtualnych między hostami jest rutynową czynnością. Aby rozwiązać te problemy, firma VMware udostępnia funkcje klastrowania, takie jak VMware High Availability (HA) i Distributed  Resource Scheduler (DRS). Wykorzystanie klastrowania vSphere pozwala skrócić przestoje maszyn wirtualnych i racjonalnie wykorzystywać zasoby sprzętowe. Ten wpis na blogu omawia przypadki użycia funkcji klastrowania VMware HA i DRS.

NAKIVO – tworzenie kopii zapasowej dla VMware vSphere

Kompleksowa ochrona danych dla maszyn wirtualnych VMware vSphere oraz opcje natychmiastowego odzyskiwania. Bezpieczne lokalizacje kopii zapasowych na miejscu, zdalnie oraz w chmurze. Funkcje ochrony przed oprogramowaniem wymuszającym okup.

ODKRYJ ROZWIĄZANIE

Czym jest klaster vSphere?

Klaster vSphere to zbiór połączonych hostów ESXi, które współdzielą zasoby sprzętowe, takie jak procesor, pamięć i pamięć masowa. Klastry VMware vSphere są zarządzane centralnie w vCenter. Zasoby klastra są agregowane w puli zasobów, więc po dodaniu hosta do klasterzasoby tego hosta stają się częścią zasobów całego klastra. Hosty ESXi należące do klastra nazywane są również węzłami klastra. Istnieją dwa typy klastrów vSphere: vSphere High Availability oraz Distributed Resource Scheduler (VMware HA i DRS).

Wymagania dotyczące klastrów VMware

Aby przeprowadzić wdrażanie VMware HA oraz DRS, należy spełnić zestaw wymagań dotyczących klastra:

• Należy użyć co najmniej dwóch hostów ESXi o identycznej konfiguracji (procesory z tej samej rodziny, wersja ESXi i poziom poprawek itp.). Na przykład można użyć dwóch serwerów z procesorami Intel tej samej rodziny (lub AMD procesorami) oraz {12} zainstalowanym na serwerach. Zaleca się użycie co najmniej trzech hostów w celu zapewnienia lepszej ochrony i wydajności.
• Szybkie połączenia sieciowe dla sieci zarządzania, sieci pamięci masowej oraz sieci vMotion. Wymagane są redundantne połączenia sieciowe.
• Wspólny magazyn danych, do którego dostęp mają wszystkie hosty ESXi w klastrze. Jako współdzielony magazyn danych można wykorzystać sieć pamięci masowej (SAN), sieciową pamięć masową (NAS) oraz VMware vSAN . Obsługiwane są protokoły NFS i iSCSI umożliwiające dostęp do danych we współdzielonym magazynie danych. Pliki maszyn wirtualnych muszą być przechowywane we współdzielonym magazynie danych.
• VMware vCenter Server kompatybilny z wersją ESXi zainstalowaną na hostach.

W przeciwieństwie do Hyper-V Failover Clusternie jest wymagane kworum i nie ma potrzeby stosowania skomplikowanych nazw sieciowych.

Czym jest VMware HA w vSphere?

VMware vSphere High Availability (HA) to funkcja klastrowania zaprojektowana w celu automatycznego ponownego uruchamiania maszyny wirtualnej (VM) w przypadku awarii. VMware vSphere High Availability pozwala organizacjom zapewnić wysoką dostępność maszyn wirtualnych i aplikacji działających na tych maszynach w klastrze vSphere (niezależnie od uruchomionych aplikacji). VMware HA może zapewnić ochronę przed awarią hosta ESXi — maszyna wirtualna, na której wystąpiła awaria, jest ponownie uruchamiana na sprawnym hoście. W rezultacie można znacznie skrócić czas przestoju.

Wymagania dotyczące vSphere HA

Wymagania dotyczące vSphere HA należy uwzględnić wraz z ogólnymi wymaganiami dotyczącymi klastra vSphere. Aby skonfigurować VMware vSphere High Availability, należy dysponować:

• A VMware vSphere Standard licencja
• Co najmniej 4 GB pamięci RAM na każdym hoście
• Brama, z którą można nawiązać połączenie za pomocą polecenia ping

Jak działa vSphere HA ?

VMware vSphere High Availability sprawdza hosty ESXi w celu wykrycia awarii hosta. Jeśli wykryta zostanie awaria hosta (maszyny wirtualne działające na tym hoście również ulegną awarii), wówczas uszkodzone maszyny wirtualne są migrowane na sprawne hosty ESXi w obrębie klastra. Po migracji maszyny wirtualne są rejestrowane na nowych hostach, a następnie uruchamiane. Pliki maszyn wirtualnych (VMX, VMDK i inne) po migracji znajdują się na tym samym zasobie, którym jest współdzielony magazyn danych. Pliki maszyn wirtualnych nie są migrowane. Po migracji nowy host ESXi udostępnia jedynie Procesor, pamięć i komponenty sieciowe wykorzystywane przez uszkodzone maszyny wirtualne.

Czas przestoju jest równy czasowi potrzebnemu do ponownego uruchomienia maszyny wirtualnej na innym hoście. Należy jednak pamiętać, że należy również uwzględnić czas potrzebny na uruchomienie systemu operacyjnego oraz załadowanie niezbędnych aplikacji na maszynie wirtualnej. VMware HA to rozwiązanie działające na poziomie maszyn wirtualnych, które można wykorzystać nawet wtedy, gdy aplikacje nie posiadają natywnych funkcji wysokiej dostępności. VMware vSphere High Availability nie zależy od systemu operacyjnego gościa zainstalowanego na maszynie wirtualnej.

Schemat działania klastra vSphere HA przedstawiono na poniższym rysunku. W tym przykładzie klaster składa się z trzech hostów ESXi. Maszyny wirtualne działają na wszystkich hostach. Połączenia między maszynami wirtualnymi i ich plikami przedstawiono liniami kropkowanymi.

1. Normalne działanie klastra. Wszystkie maszyny wirtualne działają na swoich natywnych hostach.

2. Awaria hosta ESXi 1. Maszyny wirtualne znajdujące się na hoście ESXi 1 (VM1 i VM2) ulegają awarii (są wyłączone). Klaster vSphere HA inicjuje ponowne uruchomienie maszyn wirtualnych na innych sprawnych hostach ESXi.

3. Maszyny wirtualne zostały przeniesione i uruchomione ponownie na sprawnych hostach. VM1 została przeniesiona na host ESXi 2, a VM2 na host ESXi 3. Pliki maszyn wirtualnych znajdują się w tym samym miejscu na współdzielonej pamięci masowej, do której podłączone są wszystkie hosty ESXi w klastrze vSphere.

HA host główny i podległe

Po vSphere High Availability włączeniu tej funkcji w klastrze jeden host ESXi zostaje wybrany jako HA host główny. Pozostałe hosty ESXi są hostami podrzędnymi (hostami typu slave). Host główny wykonuje monitorowanie stanu hostów podrzędnych, aby na czas wykryć awarię hosta i zainicjować ponowne uruchomienie maszyn wirtualnych, w których wystąpiła awaria. Host główny wykonuje również monitorowanie stanu zasilania maszyn wirtualnych w węzłach klastra. W przypadku wykrycia awarii maszyny wirtualnej host główny inicjuje jej ponowne uruchomienie (przed ponownym uruchomieniem maszyny wirtualnej, w której wystąpiła awaria, host główny wybiera optymalny host). Główny HA wysyła informacje o stanie klastra HA do vCenter. VMware vCenter zarządza klastrem za pomocą interfejsu dostarczonego przez głównego hosta HA.

Główny host może uruchamiać Maszyny wirtualne tak samo jak inne hosty w klastrze. Jeśli główny host ulegnie awarii, wybrany zostaje inny główny host. Host połączony z największą liczbą magazynów danych ma przewagę w wyborach głównego hosta ESXi. Hosty, które nie są w trybie konserwacji, biorą udział w wyborze głównego hosta.

Podporządkowane hosty mogą uruchamiać maszyny wirtualne, monitorować stany maszyn wirtualnych oraz raportować zaktualizowane informacje o ich stanach do głównego hosta HA.

Fault Domain Manager (FDM) to nazwa agenta używanego do monitorowania dostępności serwerów fizycznych. Agent FDM działa na każdym hoście ESXi w klastrze HA.

Typy awarii hosta

Istnieją trzy typy niepowodzenia hosta ESXi:

Niepowodzenie. Host ESXi przestał działać z jakiegoś powodu.

Izolacja. Host ESXi oraz maszyny wirtualne na tym hoście dalej działają, ale host jest izolowany od innych hostów w klastrze z powodu problemów z siecią.

Podział. Utracono łączność sieciową z głównym hostem.

Jak wykrywane są awarie

Aby wykryć awarie w klastrze HA vSphere, wymieniane są sygnały kontrolne. Główny host monitoruje stan drugorzędnych hostów, odbierając sygnały z tych hostów co sekundę. Główny host wysyła ICMP ping’i do hosta drugorzędnego i czeka na odpowiedzi. Jeśli główny host nie może komunikować się bezpośrednio z agentem hosta drugorzędnego, host drugorzędny może być zdrowy lub uszkodzony, ale niedostępny przez sieć.

Jeśli główny host nie odbiera sygnałów kontrolnych, wtedy sprawdza podejrzany host za pomocą Datastore Heartbeating. Podczas normalnej pracy, każdy host w klastrze HA wymienia sygnały kontrolne z dzielonym magazynem danych. Główny host ESXi sprawdza, czy wymieniono sygnały kontrolne magazynu danych z podejrzanym hostem, oprócz wysyłania ping’ów do tego hosta. Jeśli nie ma wymiany sygnałów kontrolnych z podejrzanym hostem, a ten host nie wysyła ICMP żądań, to host zostaje oznaczony jako uszkodzony.

Uwaga: Na korzeniu dzielonego magazynu danych tworzony jest specjalny katalog .vSphere-HA do wysyłania sygnałów kontrolnych i identyfikacji listy chronionych Maszyn wirtualnych. Zauważ, że magazyny danych vSAN nie mogą być używane do wymiany sygnałów kontrolnych. Jeśli główny host nie może połączyć się z agentem hosta pomocniczego, ale host pomocniczy wymienia się sygnałami serca z udostępnionym magazynem danych, główny host oznacza podejrzany host jako izolowany sieciowo. Jeśli główny host ustali, że host pomocniczy działa w izolowanym segmencie sieci, główny host kontynuuje monitorowanie maszyn wirtualnych na tym izolowanym hoscie. Jeśli maszyny wirtualne na izolowanym hoscie są wyłączone, główny host inicjuje ponowne uruchomienie tych maszyn wirtualnych na innym hoscie ESXi. Możesz skonfigurować reakcję klastra vSphere HA na sytuację, gdy host ESXi zostanie izolowany sieciowo.

Monitorowanie indywidualnych maszyn wirtualnych. VMware vSphere High Availability ma mechanizm monitorowania indywidualnych maszyn wirtualnych i wykrywania, czy konkretna maszyna wirtualna zakończyła się niepowodzeniem. {45} zainstalowane na systemie operacyjnym (OS) gościa są używane do określenia stanu maszyny wirtualnej. VMware Tools wysyłają sygnały serca systemu operacyjnego gościa do hosta ESXi.

Sygnały serca i aktywność wejścia/wyjścia (I/O) generowana przez VMware Tools są monitorowane przez usługę monitorowania maszyn wirtualnych. Jeśli główny host ESXi w klastrze HA wykryje, że VMware Tools na chronionej maszynie wirtualnej nie odpowiadają i nie ma aktywności I/O, host inicjuje ponowne uruchomienie maszyny wirtualnej. Monitorowanie aktywności maszyny wirtualnej I/O pozwala klastrze HA uniknąć niepotrzebnych resetów maszyn wirtualnych, jeśli VMware Tools z jakiegoś powodu nie wysyłają sygnałów serca, ale maszyna wirtualna działa. Możesz ustawić czułość monitorowania, aby skonfigurować okres, po którym maszyna wirtualna musi zostać ponownie uruchomiona, jeśli sygnały serca systemu operacyjnego gościa generowane przez VMware Tools nie zostaną odebrane przez hosta ESXi. VMware vSphere HA ponownie uruchamia maszynę wirtualną na tym samym hoście ESXi w przypadku pojedynczego niepowodzenia maszyny wirtualnej.

VMware Tools sygnały serca są wysyłane do hostd na poziomie hiperwizora (ESXi), nie przy użyciu stosu sieciowego. Następnie host ESXi wysyła otrzymane informacje do vCenter. VMware Tools sygnały serca mogą być odbierane przez hosta ESXi, jeśli maszyna wirtualna jest odłączona od sieci, a nawet jeśli nie ma podłączonego wirtualnego adaptera sieciowego do maszyny wirtualnej.

Monitorowanie maszyn wirtualnych i aplikacji. Możesz użyć SDK od zewnętrznego dostawcy do monitorowania, czy zainstalowana na maszynie wirtualnej specyficzna aplikacja zakończyła się niepowodzeniem. Alternatywną opcją jest użycie aplikacji, która już wspiera monitorowanie aplikacji VMware. Sygnały serca aplikacji są używane do monitorowania aplikacji na maszynach wirtualnych VMware działających w klastrze vSphere HA.

Kluczowe parametry dla konfiguracji klastra HA

Zanim rozpoczniesz konfigurowanie klastra HA, musisz zdefiniować kilka kluczowych parametrów. Odpowiedź izolacji to parametr definiujący, jak host ESXi działa, gdy nie otrzymuje sygnałów odczepień serca. Opcje to Leave powered on, Power off (domyślny), oraz Shutdown.

Reservation to parametr, który obliczany jest na podstawie maksymalnych charakterystyk najbardziej obciążającej maszyny wirtualnej w klastrze. Ten parametr wykorzystywany jest do szacowania Trybu failover. Klaster HA tworzy gniazda rezerwacji, używając wartości parametru Rezerwacja.

Tryb failover. Ten parametr mierzony jest w liczbach całkowitych i definiuje maksymalną liczbę serwerów, które mogą ulec zakończeniu niepowodzeniem w klastrze bez negatywnego wpływu na obciążenia (klaster oraz wszystkie maszyny wirtualne mogą dalej działać po awarii tej liczby hostów ESXi).

Liczba dozwolonych awarii hostów. Ten parametr jest definiowany przez administratora systemu, aby ustalić, ile hostów może zakończyć się niepowodzeniem, aby kontynuować pracę klastra. Tryb failover jest brany pod uwagę przy ustalaniu wartości dla tego parametru.

Admission Control to parametr wykorzystywany do zapewnienia, że zarezerwowano wystarczająco zasobów, aby odzyskać maszyny wirtualne po awarii hosta ESXi. Ten parametr jest ustawiany przez administratora i definiuje zachowanie maszyn wirtualnych, jeśli nie ma wystarczającej liczby wolnych gniazd do uruchomienia maszyn wirtualnych po awarii hostów ESXi. Admission Control definiuje pojemność failover, czyli procentową degradację zasobów, którą można tolerować w klasie vSphere HA po failover.

Restart Priority jest ustawiany przez administratora, aby określić kolejność uruchamiania maszyn wirtualnych po awarii węzła klastra. Administratorzy mogą skonfigurować vSphere HA do uruchomienia najpierw krytycznych maszyn wirtualnych, a następnie pozostałych maszyn wirtualnych.

pojemność failover i awaria hosta

Zobaczmy dwa przypadki, każdy z trzema hostami ESXi, ale z różnymi wartościami pojemności failover. W pierwszym przypadku klaster HA może działać po awarii jednego hosta ESXi (patrz lewa strona obrazka poniżej). W drugim przypadku klaster HA może tolerować awarię dwóch hostów ESXi (patrz prawa strona obrazka).

1. Każdy host ESXi ma 4 gniazda. W klastrze znajduje się 6 maszyn wirtualnych. Jeśli jeden host ESXi zakończy się niepowodzeniem (na przykład trzeci host), wtedy trzy maszyny wirtualne (VM4, VM5, i VM6) mogą migrować do pozostałych dwóch hostów ESXi. W moim przykładzie te trzy maszyny wirtualne migrują do drugiego hosta ESXi. Jeśli jeszcze jeden host ESXi zakończy się niepowodzeniem, wówczas nie będzie już wolnych gniazd do migracji i uruchamiania innych maszyn wirtualnych.

2. Każdy host ESXi ma 4 gniazda. 4 Maszyny wirtualne są uruchomione w klastrze VMware vSphere HA. W tym przypadku, istnieje wystarczająco szybów, aby uruchomić wszystkie maszyny w klastrze, jeśli dwa hosty ESXi zawiodą.

Aby obliczyć Failover Capacity, wykonaj następujące czynności: Od liczby wszystkich węzłów w klastrze odejmij stosunek liczby maszyn wirtualnych w klastrze do liczby szybów na jednym węźle. Jeśli jako wynik masz niecałkowitą (liczbę, która nie jest całością), zaokrąglij liczbę do najbliższego niższego całkowitego. Obliczmy Failover Capacity dla dwóch przykładów.

Przykład 1:

3–6/4=1.5

Zaokrąglij 1.5 do 1. Wszystkie maszyny w klastrze HA mogą przetrwać, jeśli 1 host ESXi zawiedzie.

Przykład 2:

3–4/4=2

Nie trzeba zaokrąglać w dół, bo 2 to liczba całkowita. Wszystkie maszyny mogą dalej działać, jeśli 2 hosty ESXi zawiodą.

Kontrola dostępu

Jak wspomniano wcześniej, kontrola dostępu to parametr potrzebny do zapewnienia wystarczających zasobów do uruchamiania maszyn po awarii hosta w klastrze. Możesz również zdefiniować parametr Admission Control State dla większej wygody. Admission Control State jest obliczany jako stosunek Failover Capacity do Liczba dozwolonych awarii hosta (NHF).

Jeśli Failover Capacity jest wyższa niż NHF, wtedy klaster HA jest prawidłowo skonfigurowany. W przeciwnym razie musisz ustawić Admission Control ręcznie. Dostępne są dwie opcje:

1. Nie uruchamiaj maszyn wirtualnych, jeśli naruszają ograniczenia dostępności (nie uruchamiaj maszyn wirtualnych, jeśli nie ma wystarczających zasobów sprzętowych).

2. Pozwól na uruchomienie maszyn wirtualnych, nawet jeśli naruszają dostępność (uruchom maszyny pomimo braku zasobów sprzętowych).

Wybierz opcję, która najlepiej pasuje do przypadku użycia klastra vSphere High Availability. Jeśli Twoim celem jest niezawodność klastra HA, wybierz pierwszą opcję (Do not power on VMs). Jeśli najważniejszą rzeczą jest uruchomienie wszystkich maszyn wirtualnych, wybierz drugą opcję (Allow VMs to be started). Zwróć uwagę, że w drugim przypadku zachowanie klastra może być nieprzewidywalne. W najgorszym scenariuszu klaster HA może stać się bezużyteczny.

Nadpisy maszyn wirtualnych

Nadpisania maszyn wirtualnych (lub HA nadpisania w przypadku klastra HA) to opcja pozwalająca na wyłączenie HA dla konkretnej maszyny wirtualnej uruchomionej w klastrze HA. Możesz skonfigurować swój klaster vSphere HA na bardziej szczegółowym poziomie dzięki tej opcji na poziomie klastra.

Odporność na awarie

VMware udostępnia funkcję dla klastra vSphere HA, która pozwala osiągnąć zerowy czas przestoju w przypadku awarii hosta ESXi. Ta funkcja nosi nazwę Fault Tolerance. Podczas gdy standardowa konfiguracja vSphere High Availability wymaga ponownego uruchomienia maszyny wirtualnej w przypadku awarii, Fault Tolerance pozwala maszynom wirtualnym na dalsze działanie, jeśli główny host ESXi, na którym są zarejestrowane, ulegnie awarii. Fault Tolerance można wykorzystać w przypadku maszyn wirtualnych o znaczeniu krytycznym, na których działają kluczowe aplikacje.

Osiągnięcie zerowego czasu przestoju zapewniającego najwyższy poziom ciągłości działania wiąże się z dodatkowym obciążeniem, ponieważ istnieją dwie uruchomione instancje maszyny wirtualnej chronione za pomocą Fault Tolerance. Druga maszyna wirtualna typu „ghost” działa na drugim hoście ESXi, a wszystkie zmiany w oryginalnej maszynie wirtualnej (Procesor, pamięć RAM, stan sieci) są replikowane z pierwotnego hosta ESXi na hosta ESXi pomocniczego. Chroniona maszyna wirtualna nazywana jest maszyną główną, a jej duplikat — maszyną pomocniczą. Maszyny wirtualne główna i pomocnicza muszą znajdować się na różnych hostach ESXi, aby zapewnić ochronę przed awarią hosta ESXi.

Obie maszyny wirtualne (główna i pomocnicza) działają jednocześnie i zużywają zasoby procesora, pamięci RAM oraz sieci na obu hostach ESXi (w związku z tym maszyna wirtualna chroniona funkcją Fault Tolerance zużywa dwa razy więcej zasobów w klastrze vSphere HA ). Maszyny te są stale synchronizowane w czasie rzeczywistym. Użytkownicy mogą pracować wyłącznie z maszyną wirtualną główną (oryginalną), a maszyna wirtualna pomocnicza (ghost) jest dla nich niewidoczna.

Jeśli pierwszy host ESXi ulegnie awarii (host, na którym znajduje się maszyna wirtualna główna), obciążenia są migrowane do maszyny wirtualnej pomocniczej (czyli klonu maszyny wirtualnej lub maszyny wirtualnej typu „ghost”) działającej na drugim hoście ESXi. Maszyna wirtualna pomocnicza staje się aktywna i dostępna w ciągu kilku chwil. Użytkownicy mogą zauważyć niewielkie opóźnienie sieciowe w momencie Trybu failover. Podczas Trybu failover nie dochodzi do przerwy w działaniu usług ani utraty danych. Po pomyślnym zakończeniu Trybu failover na alternatywnym, sprawnym hoście ESXi tworzona jest nowa maszyna wirtualna typu „ghost”, aby zapewnić nadmiarowość i kontynuować ochronę maszyny wirtualnej przed awarią hosta ESXi.

Fault Tolerance zapobiega scenariuszom typu „split-brain” (gdy dwie aktywne kopie chronionej maszyny wirtualnej działają jednocześnie) dzięki mechanizmowi blokowania plików na wspólnej pamięci masowej, służącemu do koordynacji Trybu failover. Jednak Fault Tolerance nie zapewnia ochrony przed awariami oprogramowania wewnątrz maszyny wirtualnej (takimi jak awaria systemu operacyjnego gościa lub awaria poszczególnych aplikacji). Jeśli nastąpi awaria maszyny wirtualnej głównej, awarię odnotuje również maszyna wirtualna rezerwowa. Wymagania dotyczące Fault Tolerance

• Klaster vSphere HA z co najmniej dwoma hostami ESXi.
• vMotion oraz FT logging.
• Kompatybilny procesor, który wspiera wirtualizację wspomaganą sprzętowo MMU.

Zaleca się korzystanie z dedykowanej sieci Fault Tolerance w klastrze vSphere HA.

Licencja na Fault Tolerance

• Hosty ESXi muszą posiadać licencję do korzystania z Fault Tolerance.
• vSphere Standard oraz Enterprise obsługują do 2 vCPU na jedną maszynę wirtualną.
• vSphere Enterprise Plus pozwala na korzystanie z maksymalnie 8 vCPU na maszynę wirtualną.

Fault Tolerance ograniczenia

Istnieją pewne ograniczenia w korzystaniu z VMware Fault Tolerance w vSphere. Funkcje VMware vSphere, które są niekompatybilne z FT:

• Migawki maszyn wirtualnych. Chroniona maszyna wirtualna nie może mieć migawek.
• Klony połączone
• Magazyny danych VMware {118}

Urządzenia, które nie są obsługiwane:

• Raw device mapping urządzenia
• Fizyczne CD-ROM-y i inne urządzenia serwera, które są podłączone do maszyny wirtualnej jako urządzenia wirtualne
• Urządzenia dźwiękowe i urządzenia USB
• Wirtualne dyski VMDK o rozmiarze większym niż 2 TB
• Urządzenia wideo z grafiką 3D
• Porty równoległe i szeregowe
• Hot-plug urządzenia
• NIC (network interface controller) przesyłania
• Storage vMotion (musi być tymczasowo wyłączone, aby przenieść pliki maszyny wirtualnej do innego magazynu)

Co to jest DRS w VMware vSphere?

Distributed Resource Scheduler (DRS) to funkcja klastrów VMware vSphere, która pozwala na równoważenie obciążenia maszyn wirtualnych uruchomionych w klastrze. DRS monitoruje obciążenie maszyn wirtualnych oraz serwerów ESXi w obrębie klastra vSphere. Jeśli DRS wykryje, że host lub maszyna wirtualna są przeciążone, DRS przenosi maszynę wirtualną na host ESXi dysponujący wystarczającymi zasobami sprzętowymi, aby zapewnić jakość usługi (QoS). DRS może wybrać optymalny host ESXi dla maszyny wirtualnej, gdy tworzysz nową maszynę w klastrze.

VMware DRS umożliwia uruchamianie maszyn wirtualnych w zrównoważonym klastrze i unikanie przeciążeń oraz sytuacji, kiedy brakuje zasobów sprzętowych dla maszyn wirtualnych oraz aplikacji działających na maszynach dla normalnego działania (w takim przypadku w całym klastrze musi być dostępna wystarczająca ilość zasobów).

DRS Wymagania

Wymagania dla DRS, wraz z ogólnymi wymaganiami dla klastra vSphere, obejmują:

• vSphere Enterprise lub vSphere Enterprise Plus licencja
• Procesor z Enhanced vMotion Compatibility do migracji maszyn wirtualnych „live” z vMotion
• Dedykowany vMotion sieć

Skonfigurowana VMware vMotion jest wymagana do działania klastra DRS, w przeciwieństwie do klastra HA, gdzie vMotion jest wymagane tylko podczas używania Fault Tolerance. Ponadto licencja na vSphere wymagana dla VMware DRS jest wyższa niż licencja na korzystanie z vSphere High Availability.

Rola vMotion

Przenieś Maszyny Wirtualne z jednego hosta ESXi na inny z vMotion, który omówiliśmy podczas wyjaśniania jak działa Fault Tolerance. Z VMware vMotion, migracja maszyn wirtualnych (procesor, pamięć, stan sieci) odbywa się bez przerywania pracy maszyn wirtualnych (nie ma przerw). VMware vMotion jest kluczową funkcją do prawidłowego działania DRS.

Przyjrzyjmy się głównym krokom operacji vMotion:

1. vMotion tworzy VM cieniową na docelowym hoście ESXi. Host docelowy ESXi uprzednio alokuje wystarczającą ilość zasobów dla maszyny wirtualnej do zmigrowania. Maszyna wirtualna jest ustawiona w stanie pośrednim, a konfiguracja maszyny wirtualnej nie może być zmieniana w czasie migracji.

2. Proces prekopy. Każda strona pamięci maszyny wirtualnej jest kopiowana z hosta źródłowego do celu przy użyciu sieci vMotion.

3. Następne przepisanie stron pamięci z hosta źródłowego do celu jest wykonywane, ponieważ strony pamięci zmieniają się podczas działania maszyny wirtualnej. Jest to proces iteracyjny wykonywany do momentu, gdy nie pozostają żadne zmienione strony pamięci. Zmienione strony pamięci są nazywane „brudnymi stronami”. Migracja maszyn wirtualnych z vMotion zajmuje więcej czasu, jeśli na maszynie wirtualnej wykonywane są operacje wymagające dużo pamięci, ponieważ zmienianych jest więcej stron pamięci.

4. Maszyna wirtualna jest zatrzymywana na źródłowym hoście ESXi i wznawiana na docelowym hoście. Nieznaczna latencja sieciowa może być zauważona wewnątrz migrowanej maszyny wirtualnej przez około sekundę w tym momencie.

Zasada działania DRS w VMware

VMware DRS sprawdza obciążenia z perspektywy procesora i pamięci RAM, aby co 5 minut, co jest domyślnym interwałem, ocenić równowagę klastra vSphere. VMware DRS sprawdza wszystkie zasoby w puli zasobów klastra, w tym zasoby wykorzystywane przez maszyny wirtualne oraz zasoby każdego hosta ESXi w obrębie klastra, które mogą zostać dostarczone do działania maszyn wirtualnych. Kontrole zasobów są wykonywane zgodnie z skonfigurowanymi zasadami.

Żądania maszyny wirtualnej są również brane pod uwagę (zasoby sprzętowe, które maszyna wirtualna potrzebuje do działania w momencie sprawdzania). Formula jest używana do obliczania zapotrzebowania maszyny wirtualnej na pamięć: Zapotrzebowanie na pamięć Maszyny wirtualnej = Funkcja (Aktywna pamięć używana, Wymieniona, Wspólna) + 25% (pamięć konsumowana bezczynnie)

Zapotrebeniowanie CPU jest obliczane na podstawie liczby zasobów procesora, które są obecnie używane przez Maszyna wirtualna. Maksymalne wartości procesora Maszyna wirtualna i średnie wartości procesora Maszyna wirtualna zebrane podczas ostatniej kontroli pomagają DRS określić trend zużycia zasobów dla konkretnej Maszyna wirtualna. Jeśli vSphere DRS wykryje niezrównoważenie w klastrze i że niektóre hosty ESXi są przeciążone, wtedy DRS inicjuje żywą migrację Maszyny wirtualne działających na przeciążonym hoście do hosta z wolnymi zasobami.

Spójrzmy, jak działa vSphere DRS w VMware, używając przykładu z diagramami. Na poniższym diagramie widać klaster DRS z 3 hostami ESXi. Wszystkie hosty są podłączone do wspólnych magazynów, gdzie znajdują się pliki Maszyny wirtualne. Pierwszy host jest bardzo obciążony, drugi host ma wolne zasoby CPU i pamięci, a trzeci host jest bardzo obciążony. Niektóre Maszyny wirtualne na pierwszym (VM1) i trzecim (VM4, VM5) hostach ESXi zużywają niemal wszystkie przeznaczone zasoby CPU i pamięci. W takim przypadku wydajność tych Maszyny wirtualne może ulec pogorszeniu.

VMware DRS stwierdza, że racjonalnym działaniem jest przeniesienie bardzo obciążonej VM2 z przeciążonego hosta ESXi 1 do hosta ESXi 2, który ma wystarczająco wolnych zasobów, i przeniesienie VM4 z hosta ESXi 3 do hosta ESXi 2. Jeśli DRS jest skonfigurowany do pracy w trybie automatycznym, to uruchomione Maszyny wirtualne są migrowane z vMotion (to działanie jest ilustrowane zielonymi strzałkami na poniższej ilustracji). Pliki Maszyny wirtualna, w tym dyski wirtualne (VMDK), pliki konfiguracyjne (VMX) i inne pliki, znajdują się w tym samym miejscu w magazynie współdzielonym podczas migracji Maszyny wirtualna i po migracji Maszyny wirtualna (połączenia Maszyny wirtualna i ich plików są ilustrowane przerywanymi liniami na obrazku).

Po zakończeniu migracji wybranych Maszyny wirtualne klaster DRS staje się zbalansowany. Na każdym hoście ESXi w klastrze znajdują się wolne zasoby do skutecznego uruchamiania Maszyny wirtualna i zapewnienia wysokiej wydajności.

Sytuacja może się zmienić z powodu nierównomiernych obciążeń Maszyny wirtualne, a klaster może znów stać się niezrównoważony. W takim przypadku DRS przeanalizuje zużyte zasoby i wolne zasoby w klastrze, aby ponownie rozpocząć migrację Maszyny wirtualna.

Kluczowe parametry dla Konfiguracja vSphere DRS

VMware vSphere DRS jest wysoce konfigurowalną funkcją klastrową, która pozwala na użycie DRS z większą wydajnością w różnych sytuacjach. Przyjrzyjmy się głównym parametrom, które wpływają na zachowanie DRS w klastrze vSphere.

VMware DRS poziomy automatyzacji

Gdy DRS wykrywa, że klaster vSphere jest niezrównoważony, DRS dostarcza rekomendacje dotyczące umiejscowienia Maszyn wirtualnych oraz ich migracji z vMotion. Rekomendacje można wdrożyć, korzystając z jednego z trzech poziomów automatyzacji:

Fully automated. Początkowe umiejscowienie Maszyn wirtualnych oraz vMotion rekomendacje są stosowane automatycznie przez DRS (interwencja użytkownika nie jest wymagana).

Partially automated. Rekomendacje dotyczące początkowego umiejscowienia nowych Maszyn wirtualnych to jedyne, które są stosowane automatycznie. Inne rekomendacje można zainicjować i zastosować ręcznie lub zignorować.

Manual. DRS dostarcza rekomendacje dotyczące początkowego umiejscowienia Maszyn wirtualnych oraz ich migracji, ale wymagane jest działanie użytkownika w celu zastosowania tych rekomendacji. Można również zignorować rekomendacje dostarczone przez DRS.

DRS poziomy agresji (progi migracji)

DRS poziomy agresji lub progi migracji to opcje kontroli maksymalnego poziomu niezrównoważenia akceptowalnego dla klastra DRS. Istnieje pięć wartości progów, od 1, najbardziej konserwatywnej, do 5, najbardziej agresywnej.

Ustawienie agresywne inicjuje migrację Maszyn wirtualnych, nawet jeśli korzyść z umiejscowienia Maszyn wirtualnych jest niewielka. Ustawienie konserwatywne nie inicjuje migracji Maszyn wirtualnych, nawet jeśli można osiągnąć istotne korzyści po migracji Maszyn wirtualnych. Poziom 3, środkowy poziom agresji, jest wybierany domyślnie i jest to zalecane ustawienie.

Reguły afiliacji w VMware DRS

Reguły afiliacji i antyafiliacji są przydatne, gdy trzeba umieścić konkretne Maszyny wirtualne na konkretnych hostach ESXi. Na przykład, może zajść potrzeba uruchomienia niektórych Maszyn wirtualnych razem na jednym hoście ESXi w obrębie klastra lub odwrotnie (trzeba, aby dwie lub więcej Maszyn wirtualnych było umieszczonych tylko na różnych hostach ESXi i Maszyny wirtualne nie mogą być umieszczone na jednym hoście). Przypadki użycia mogą obejmować:

• Maszyny wirtualne kontrolera domeny wirtualnej (główny kontroler domeny oraz dodatkowy kontroler domeny) na różnych hostach, aby uniknąć awarii obu Maszyn wirtualnych, jeśli jeden host zawiedzie. W tym przypadku te Maszyny wirtualne nie mogą działać razem na jednym hoście ESXi.
• Maszyny wirtualne uruchamiające oprogramowanie licencjonowane do działania na odpowiednim sprzęcie i nie mogą uruchamiać się na innych komputerach fizycznych z powodu ograniczeń licencyjnych (na przykład Baza danych Oracle).

Reguły afiliacji dzielą się na:

• Reguły afiliacji Maszyna wirtualna – Maszyna wirtualna (dla indywidualnych Maszyn wirtualnych)
• Reguły afiliacji Maszyna wirtualna-host (relacja między grupami hostów a grupami Maszyn wirtualnych)

Reguły hosta Maszyny wirtualnej mogą być preferencyjne (Maszyny wirtualne powinny…) lub obligatoryjne (Maszyny wirtualne muszą…). Obowiązkowe zasady nadal działają nawet wtedy, gdy DRS jest wyłączona, co uniemożliwia ręczną migrację odpowiednich maszyn wirtualnych za pomocą vMotion. Zasada ta jest stosowana, aby uniknąć naruszenia reguły zastosowanej do maszyn wirtualnych działających na hostach ESXi, jeśli vCenter jest chwilowo niedostępne lub zakończone niepowodzeniem.

Są cztery opcje reguł skojarzenia DRS:

Zachowaj maszyny wirtualne razem. Wybrane maszyny wirtualne muszą działać razem na jednym hoście ESXi (jeśli konieczna jest migracja maszyn wirtualnych, wszystkie te maszyny muszą być migrowane razem). Regułę tę można użyć, gdy chcesz lokalizować ruch sieciowy między wybranymi maszynami wirtualnymi (aby uniknąć przeładowania sieci między hostami ESXi, jeśli maszyny wirtualne generują znaczący ruch sieciowy). Innym przypadkiem użycia jest uruchomienie złożonej aplikacji, która wykorzystuje komponenty (zależne od siebie) zainstalowane na wielu maszynach wirtualnych lub uruchomienie vApp. To może obejmować na przykład serwer bazy danych i serwer aplikacji.

Oddziel maszyny wirtualne. Wybrane maszyny wirtualne nie mogą działać na jednym hoście ESXi. Opcja ta jest stosowana w celach wysokiej dostępności.

Maszyny wirtualne do hostów. Maszyny wirtualne dodane do grupy maszyn wirtualnych muszą działać na określonym hoście ESXi lub grupie hostów. Trzeba skonfigurować grupy DRS (grupy maszyn/hostów). Grupa DRS zawiera wiele maszyn wirtualnych lub hostów ESXi.

Maszyny wirtualne do maszyn wirtualnych. Reguła ta może być wybrana, aby powiązać maszyny wirtualne z maszynami wirtualnymi, gdy chcesz najpierw włączyć jedną grupę maszyn, a następnie włączyć inną (zależną) grupę maszyn. Opcja ta jest używana, gdy VMware HA i DRS są skonfigurowane razem w klastrze.

Jeśli występuje konflikt reguł, starsza reguła ma pierwszeństwo.

Nadpisanie maszyny wirtualnej dla VMware DRS

Podobnie jak użycie nadpisania maszyny wirtualnej w klastrze vSphere HA, nadpisania maszyn wirtualnych są używane do bardziej szczegółowej konfiguracji DRS w VMware vSphere i pozwalają na nadpisanie globalnych ustawień ustawionych na poziomie klastra DRS oraz definiowanie konkretnych ustawień dla pojedynczej maszyny wirtualnej. Inne maszyny wirtualne klastra nie są dotknięte, gdy dla konkretnej maszyny wirtualnej zastosowano nadpisanie.

Predictive DRS

Główną koncepcją Predictive DRS jest zbieranie informacji o rozmieszczeniu maszyn wirtualnych, a następnie, na podstawie wcześniej zebranych informacji, przewidywanie, kiedy i gdzie nastąpi wysokie użycie zasobów. Wykorzystując te informacje, Predictive DRS może przenosić maszyny wirtualne między hostami dla lepszego rozkładu obciążenia, zanim serwer ESXi zostanie przeciążony i maszyny wirtualne nie będą miały zasobów. Funkcja ta może być przydatna, gdy występują zmiany popytu w czasie na potrzeby maszyn wirtualnych w klastrze. Predictive DRS jest domyślnie wyłączona. VMware vRealize Operations Manager jest wymagane do użycia Power DRS.

Distributed Power Manager

Distributed Power Manager (DPM) to funkcja używana do migracji Maszyn wirtualnych, jeśli jest wystarczająco dużo wolnych zasobów w klastrze, aby wyłączyć hosta ESXi (umieścić host w trybie gotowości) i uruchomić Maszyny wirtualne na pozostałych hostach ESXi w klastrze (pozostałe hosty muszą zapewniać wystarczające zasoby do uruchomienia potrzebnych Maszyn wirtualnych).

Gdy potrzeba więcej zasobów w klastrze do uruchomienia Maszyn wirtualnych, DPM inicjuje działanie serwera, który został wyłączony, aby obudzić się i działać w trybie normalnym. Jeden z obsługiwanych protokołów zarządzania energią jest używany do włączenia hosta przez sieć. Te protokoły to Inteligentne Platform Management Interface (IPMI), Hewlett-Packard Integrated Lights-Out (iLO) lub Wake-On-LAN (WOL). Następnie DRS migruje niektóre Maszyny wirtualne na ten serwer, aby rozdzielić obciążenia i zbilansować klaster. Domyślnie Distributed Power Management jest wyłączona. Rekomendacje DPM mogą być zastosowane automatycznie lub manualnie.

Storage DRS

Podczas gdy DRS migruje Maszyny wirtualne na podstawie zasobów obliczeniowych Procesora i RAM, Storage DRS przenosi pliki maszyn wirtualnych z jednego magazynu danych do innego na podstawie zużycia magazynu danych, na przykład, wolnego miejsca na dysku. Reguły spójności i antyspójności pozwalają skonfigurować czy Storage DRS musi przechowywać pliki dyskowe Maszyny wirtualnej razem na tym samym magazynie danych. Na przykład, można skonfigurować regułę antyspójności, aby przechowywać pliki VMDK Maszyny wirtualnej wykonującej operacje intensywnego I/O na różnych magazynach danych. Robi się to w celu uniknięcia degradacji wydajności Maszyny wirtualnej i początkowego magazynu danych Maszyny wirtualnej (obciążenia dysków I/O zostaną rozdzielone pomiędzy wieloma magazynami danych, gdy używa się reguły antyspójności).

Storage DRS jest użyteczny przy użyciu Maszyn wirtualnych z dyskami przydzielane dynamicznie w przypadku nadprovisioningu. Storage DRS pomaga unikać sytuacji, gdy rozmiar cienkich dysków rośnie, a co za tym idzie, nie ma wolnego miejsca w magazynie danych. Brak wolnego miejsca powoduje, że Maszyny wirtualne przechowujące wirtualne dyski w tym magazynie danych zakończą się niepowodzeniem. Pliki dysków maszyn wirtualnych można migrować z jednego magazynu danych do innego za pomocą Storage vMotion podczas działania Maszyny wirtualnej.

Monitorowanie zużycia Procesora i pamięci

VMware zapewnia możliwość monitorowania zużycia zasobów w interfejsie webowym VMware vSphere Client. Można monitorować zużycie Procesora w klastrze, przechodząc do Settings > Monitor > vSphere DRS > CPU Utilization. Istnieją również inne opcje monitorowania pamięci i przestrzeni magazynowej dla oddzielnych hostów ESXi. Monitorowanie VMware jest obsługiwane w NAKIVO Backup & Replication 10.5. Przeczytaj więcej na temat monitorowania infrastruktury w wpis na blogu.

Używanie VMware HA i DRS razem

VMware HA i DRS nie są technologiami rywalizującymi. Uzupełniają się nawzajem, a Ty możesz użyć zarówno VMware DRS, jak i HA w klastrze vSphere, aby zapewnić wysoką dostępność maszyn wirtualnych i równoważyć obciążenie pracy, jeśli maszyny wirtualne są ponownie uruchamiane przez HA na innych hostach ESXi. Zaleca się korzystanie z obu technologii w produkcyjnych środowiskach klastrów vSphere dla automatycznego trybu failover i równoważenia obciążenia.

Kiedy host ESXi zawodzi, Tryb failover maszyn wirtualnych jest zainicjowane przez HA, a maszyny wirtualne są ponownie uruchamiane na innych hostach. Priorytetem w tej sytuacji jest dostępność maszyn wirtualnych. Ale po migracji maszyn wirtualnych, niektóre hosty ESXi mogą być przeciążone, co negatywnie wpłynęłoby na maszyny wirtualne działające na tych hostach. VMware DRS sprawdza użycie zasobów na każdym hostie w klastrze i udziela rekomendacji na temat najbardziej racjonalnego rozmieszczenia maszyn wirtualnych po trybie failover. W rezultacie, zawsze możesz być pewien, że po trybie failover masz wystarczająco zasobów, aby obciążenia działały z właściwą wydajnością. Z włączonymi zarówno VMware DRS, jak i HA możesz mieć bardziej efektywny klaster.

Wniosek

VMware zapewnia potężną funkcjonalność klastrów w vSphere, aby sprostać potrzebom najbardziej wymagających klientów vSphere. Zajęliśmy się VMware DRS oraz HA i wyjaśniliśmy zasady działania oraz główne parametry każdej z tych funkcji klastrowania. VMware DRS i HA uzupełniają się nawzajem i poprawiają końcowy wynik użytkowania klastra.

Nawet jeśli używasz VMware DRS oraz HA, nie zapomnij wykonać kopii zapasowej maszyn wirtualnych VMware w vSphere. Pobierz NAKIVO Backup & Replication Darmowa edycja dla Wykonać kopię zapasową VMware w Twoim środowisku.

Wypróbuj NAKIVO Backup & Replication

Skorzystaj z bezpłatnej wersji próbnej, aby zapoznać się ze wszystkimi funkcjami rozwiązania w zakresie ochrony danych. 15 dni za darmo. Bez żadnych ograniczeń dotyczących funkcji ani pojemności. Nie jest wymagana karta kredytowa.

Wypróbuj za darmo