W zależności od tego, jak potężny posiadamy sprzęt i jakie zasoby są niezbędne dla naszych systemów, będziemy mieli średni stosunek maszyn wirtualnych na serwer.
Weźmy na przykład zaplanowaną konserwację serwera w Centrum komputerowym. Kilka lat temu, gdyby nie było to częścią klastra, system zawarty w sprzęcie zostałby wyłączony, w konsekwencji użytkownicy również byliby narażeni i / lub personel zaangażowany w konserwację musiałby pracować w skróconych oknach czasowych (np. niewygodny).
W przypadku środowiska zwirtualizowanego maszyny wirtualne można po prostu „przenieść lub migrować” do innego członka klastra, a sprzęt można wyłączyć, aby na nim pracować. Problem rozwiązany.
Zacznijmy widzieć sytuacje, w których brak obsługi nie jest zaprogramowany.
Monitorowanie maszyn wirtualnych i aplikacji
Za każdym razem, gdy tworzymy maszynę wirtualną, zaleca się instalację kompendium aplikacji i sterowników, które w całości optymalizują zachowanie wirtualnego sprzętu (dostępne dla Windows, Mac OS, Linux i innych OS). Narzędzia te, zwane VMTools, obejmują między innymi możliwość monitorowania maszyny wirtualnej przez hosta (poprzez pulsy, jak w klastrach). Jeśli nie odpowie w określonym czasie, ponownie uruchomi system operacyjny.
Podobny przypadek ma miejsce w przypadku monitorowania aplikacji, ale najpierw musisz zaopatrzyć się w odpowiedni pakiet SDK (lub korzystać z aplikacji obsługującej monitorowanie aplikacji VMware).
Ale… co się stanie, jeśli usterka tkwi w sprzęcie?
Wspomniany powyżej klaster to pierwsza warstwa rozwiązania.
Pamięć współdzielonaGdzie wszyscy członkowie klastra mają dostęp do maszyn wirtualnych.
Współpraca w sieciW obliczu awarii jednej tablicy pozostałe nadal zarządzają ruchem.
Wiele ścieżek (wiele ścieżek)W przypadku przechowywania nie tylko zoptymalizują dostęp, ale także zapewnią redundancję.
Ogólnie rzecz biorąc, te trzy technologie łagodzą czas, w którym nasze informacje są niedostępne. Teraz, w zależności od posiadanej licencji, możemy mieć również dwie bardzo interesujące funkcje: wysoką dostępność (HA) i odporność na awarie (FT).
W obu przypadkach potrzebujemy klastra ze współdzieloną pamięcią masową. Bez konieczności instalowania dodatkowego oprogramowania, HA można włączyć i skonfigurować w taki sposób, że jeśli serwer lub maszyna wirtualna ulegnie awarii w klastrze, automatycznie uruchomi się na innym elemencie klastra. Warto wyjaśnić, że HA nie jest przeznaczony dla maszyn wirtualnych o znaczeniu krytycznym (maszyny wirtualne). Tak więc szacowany czas bez usługi będzie wynosił: "Uruchomienie systemu operacyjnego + uruchomienie usług".
Liczba awarii hosta obsługiwanych przez klaster
Mamy X maszyn wirtualnych rozproszonych na Y serwerach w klastrze.
Ile hostów może ulec awarii bez wpływu na dostępność i wydajność naszego środowiska wirtualnego?
HA można skonfigurować do obsługi określonej liczby awarii serwera, zapewniając, że podczas odzyskiwania pozostaje wystarczająca ilość zasobów.
HA w bardzo konserwatywny sposób dzieli dostępne zasoby klastra, biorąc pod uwagę procesor i pamięć RAM skonfigurowaną i zużywaną przez nasze maszyny wirtualne. Pobiera największą skonfigurowaną rezerwację procesora dowolnej maszyny wirtualnej na każdym hoście w klastrze, a następnie największą rezerwację pamięci i jej nadmiar. Jeśli nie ma skonfigurowanej rezerwacji, zajmie to minimum 32 Mhz na maszynę wirtualną dla procesora i 0 Mb pamięci RAM + jej nadmiar.
Przy tych liczbach zakłada się, że każda używana maszyna wirtualna zużyje ten procesor i pamięć, a następnie generuje wartość zwaną rozmiarem gniazda. Za pomocą tej wartości określa się, ile gniazd jest dostępnych / używanych przez każdy host.
Problem pojawia się, gdy np. mamy do czynienia z pojedynczą maszyną z dużym zapasem CPU i pamięci. Biorąc skonfigurowane rezerwacje, jest bardzo prawdopodobne, że reszta naszych maszyn wirtualnych tak naprawdę nie potrzebuje tych zasobów, co skutkuje mniejszą liczbą slotów dla naszego klastra.
Procent zasobów klastra jako zdolność do niepowodzeń
W przeciwieństwie do poprzedniej opcji, ta działa bardzo dobrze, gdy masz maszyny wirtualne o bardzo zmiennych konfiguracjach procesora i pamięci.
Możliwe jest oddzielne konfigurowanie wartości procentowych procesora i pamięci, będąc w ten sposób jeszcze bardziej elastycznym, a co za tym idzie oszczędzającym zasoby. Jest to zazwyczaj preferowana metoda konfiguracji HA.
Hosty do przełączania awaryjnego
Jest to typowa konfiguracja klastra w trybie gotowości. Ta opcja jest dostępna głównie dlatego, że niektóre organizacje utrzymują zasady, które wskazują, że serwery muszą być w stanie gotowości na wypadek awarii. Ponieważ VMware dobrze zarządza odpornością na błędy, być może byłaby to opcja, gdy zasoby są obfite… ale zdecydowanie nie najlepsza.
Ruch: Migracje na żywo
Migracja na żywo umożliwia przenoszenie działających maszyn wirtualnych z jednego serwera fizycznego na inny przy zachowaniu połączenia sieciowego i tożsamości. Aktywna pamięć (uruchomione procesy) jest przesyłana przez szybką sieć. Cały proces zajmuje mniej niż 5 sekund w sieci gigabitowej.
Możliwe jest przeniesienie maszyny wirtualnej, używanych przez nią plików lub obu, a procedurę można wykonać przy włączonej lub wyłączonej maszynie. W tym drugim przypadku nazywamy to „zimną migracją”, a jeśli maszyna jest uruchomiona, nazywamy to vMotion.
Zastosowania i zalety vMotion
- Reorganizacja maszyny wirtualnej, optymalizując w ten sposób zasoby. Usuń je z serwerów podatnych na awarie lub nasycenie.
- Automatyczna optymalizacja dostępnych zasobów (Pracuję w połączeniu z Dynamic Resource Scheduler lub DRS).
- Robić utrzymanie infrastruktury bazowej, brak konieczności planowania konserwacji lub przerw w działalności.
Każdy składnik kondycji maszyny wirtualnej jest obsługiwany inaczej podczas migracji. Ogólna konfiguracja jest najprostsza, nie przenosi się, ale jest ponownie tworzona na komputerze docelowym.
Ponieważ dysk nie może zostać odtworzony w tak krótkim czasie, konieczne jest posiadanie współdzielonej pamięci masowej. Aktualny stan pamięci jest stopniowo kopiowany do hosta docelowego.Pod koniec kopiowania porównuje się istniejące różnice, które powstały podczas migracji, stan źródłowej maszyny wirtualnej zostaje zamrożony i system operacyjny jest aktywowany na docelowej maszynie wirtualnej .
Ponieważ w niektórych przypadkach opcja ponownego uruchomienia maszyny nie jest idealna, w przypadku misji krytycznej mamy Tolerancja błędów. To, co jest pożądane w takich przypadkach, nie przestaje działać w dowolnym momencie, nawet jeśli jego host ulegnie awarii. Jedynym sposobem, aby było to możliwe, jest to, że maszyna wirtualna działała w dwóch miejscach w tym samym czasie. Jest skonfigurowany na poziomie maszyny wirtualnej i wygeneruje dokładną kopię maszyny wirtualnej, utrzymując ją w 100% replikowaną przez cały czas na innym serwerze, więc w przypadku awarii sprzętu jego bliźniak będzie po prostu nadal działał bez utraty informacji. Ciekawe, prawda?
Gdyby chodziło tylko o zasoby, włączylibyśmy FT na wszystkich maszynach wirtualnych w naszym centrum danych, ale w poprzednich wersjach vSphere napotkaliśmy pewne ograniczenia, z najważniejszych: Nie było możliwości włączenia FT na maszynach, które korzystały z więcej niż jednego wirtualnego procesor . Na szczęście w najnowszej wersji produktu obsługuje do 4 procesorów wirtualnych jednocześnie na chronioną maszynę, jednak trzeba będzie wziąć pod uwagę licencjonowanie:
Liczba procesorów wirtualnych obsługiwanych przez maszynę wirtualną z obsługą FT jest ograniczona poziomem licencji zakupionej dla vSphere.
Tolerancja błędów jest obsługiwana w następujący sposób:
- vSphere Standard i Enterprise. Umożliwia obsługę do 2 procesorów wirtualnych.
- vSphere Enterprise Plus. Umożliwia obsługę do 4 procesorów wirtualnych.
To nie jedyne wymaganie systemu.
MagazynowanieMaszyny wirtualne muszą mieć udostępniony magazyn. Nie jest możliwe użycie fizycznego RDM (ang. Raw Devide Mapping).
InternetKonieczne jest posiadanie co najmniej dwóch wirtualnych kart (vmnics), jednej do vMotion i drugiej (10 gbps) do rejestrowania FT. Jest to nowe wymaganie wersji 6 (wcześniej potrzebne były płyty 1 gbps)
EdytorProcesory i systemy operacyjne muszą być kompatybilne z FT (i ze sobą).
Ograniczenia
- Nie jest możliwe robienie migawek maszyn wirtualnych chronionych przez FT i należy je usunąć przed włączeniem tej funkcji.
- Dyski wirtualne (VMDK) większe niż 2 TB.
- W dokumentacji VMware znajduje się lista konkretnych urządzeń i funkcji.
Istnieje również ograniczenie liczby maszyn wirtualnych na serwer: maksymalnie 4 chronione maszyny na host lub 8 chronionych procesorów wirtualnych (w zależności od tego, który limit nastąpi wcześniej). Te wartości maksymalne obejmują komputer podstawowy i dodatkowy (oraz procesory wirtualne)
Różnice między dziedzictwem FT (poprzednim) a obecnym
IPv6
Legacy FT = Nieobsługiwane przez karty sieciowe skonfigurowane do rejestrowania FT FT = Obsługiwane
Interfejsy API VStorage - tworzenie kopii zapasowych z ochroną danych
Starsze FT = Nieobsługiwane FT = Obsługiwane
Dysk wirtualny
Legacy FT = EZT (Eager Zeroed Thick) FT = Wszystkie typy, w tym grube i cienkie
Nadmiarowość Vmdk (dysk wirtualny)
Legacy FT = Pojedyncza kopia FT = Maszyny podstawowe i wtórne utrzymują niezależne kopie, co pozwala na ich przechowywanie w różnych magazynach danych i zwiększa nadmiarowość
Przepustowość płyty sieciowej
Legacy FT = zalecana dedykowana karta sieciowa 1 Gb FT = zalecana dedykowana karta sieciowa 10 Gb
Kompatybilność procesora i hosta
Legacy FT = Wymaga tego samego modelu i rodziny procesora. Prawie identyczne wersje vSphere FT = CPU muszą być kompatybilne z vSphere vMotion lub EVC. Wersja VSphere musi być zgodna z vSphere vMotion
Aktywuj / dezaktywuj FT przy uruchomionej maszynie
Starsze FT = Nie zawsze obsługiwane FT = Obsługiwane
Pamiętaj, że FT chroni przed awarią sprzętu serwerowego, a nie awarią systemów operacyjnych czy aplikacji.
Program nadzorujący serwer vCenter jest to wbudowana funkcjonalność wersji 6.x. Okresowo sprawdza stan usług wchodzących w skład vCenter, w razie potrzeby zrestartuje procesy administracyjne lub maszynę wirtualną.
