Windows Server 2008

Osiąganie wysokiej dostępności dla Hyper-V Udostępnij na: Facebook

Autor: Steven Ekren

Opublikowano: 12 listopada 2008

Zawartość strony
 Wysoka dostępność   Wysoka dostępność
 Hosty i goście   Hosty i goście
 Dostępność gościa   Dostępność gościa
 Zapewnianie wysokiej dostępności maszyn wirtualnych   Zapewnianie wysokiej dostępności maszyn wirtualnych
 Warunki wstępne   Warunki wstępne
 Instalowanie wysokiej dostępności (HA)   Instalowanie wysokiej dostępności (HA)
 Czynniki, które należy wziąć pod uwagę   Czynniki, które należy wziąć pod uwagę
 Przydatne pojęcia związane z Hyper-V   Przydatne pojęcia związane z Hyper-V
 Artykuły na temat Hyper-V   Artykuły na temat Hyper-V

Wirtualizacja serwera może wkrótce wywrzeć znaczny wpływ na pracę działów IT przedsiębiorstw dzięki technologii Hyper-V zawartej w Windows Server 2008. Konsolidacja serwerów w mniejszą liczbę maszyn fizycznych daje ogromne korzyści w postaci oszczędzania zasobów oraz kosztów, lecz w czasie procesu planowania trzeba rozważyć dwa kluczowe czynniki. Użytkownicy mają rosnące oczekiwania dotyczące dostępności swojego oprogramowania, łącznie z aplikacjami biznesowymi (ang. line-of-business, LOB) i narzędzi, takich jak platformy komunikacji i współpracy. Ponadto problemy lub awarie na serwerach mogą mieć znacznie większy wpływ na działanie. Windows Server 2008 oraz Hyper-V dostarczają rozwiązania, które mogą być implementowane w celu dostarczenia wysokiej dostępności (HA) maszyn wirtualnych (VM), a także do obciążeń obsługiwanych przez maszyny wirtualne.

Wysoka dostępność

Dostępność oznacza, że użytkownicy mają dostęp do systemu, aby wykonywać swoją pracę. Wysoka dostępność łączy się ze znacznymi oczekiwaniami ze strony użytkowników, którzy powinni mieć stały dostęp do systemu, ponieważ został zaprojektowany i zaimplementowany dla zapewnienia ciągłości operacyjnej.

Wysoką dostępność dla Hyper-V osiągamy poprzez użycie funkcji Failover Cluster w Windows Server 2008. Na wysoką dostępność mają wpływ zarówno planowane, jak i nieplanowane przestoje, a klastrowanie przy pracy awaryjnej (ang. failover clustering) może znacznie zwiększyć dostępność maszyn wirtualnych w obydwu tych kategoriach.

Maszyny wirtualne mogą być zarządzane przez funkcję Failover Cluster (klaster pracy awaryjnej), która może być w nich zastosowana do monitorowania i przenoszenia obciążeń na maszynach wirtualnych. Opiszę bardziej szczegółowo oba te scenariusze konfiguracji, lecz większa część tego artykułu będzie poświęcona zarządzaniu maszynami wirtualnymi. Zanim jednak zaczniemy, możemy popatrzeć na sekcję „Przydatne pojęcia związane z Hyper-V”.

 Do początku strony Do początku strony

Hosty i goście

Ponieważ w systemie Hyper-V działa wiele systemów operacyjnych, może być trudno zorientować się, która warstwa lub system operacyjny jest omawiany. Słowa „gość” używam w odniesieniu system operacyjnego lub środowiska w maszynie wirtualnej Hyper-V, która jest uruchomiona w partycji podrzędnej. Słowo „host” stosuję do wskazywania maszyny fizycznej, która jest zarządzana prze system operacyjny na nadrzędnej partycji Hyper-V.

Dostępność hosta dotyczy kwestii wynikających ze scenariusza „stawiania wszystkiego na jedną kartę”, który może być rezultatem konsolidacji serwera. Klaster pracy awaryjnej Windows Server 2008 może być skonfigurowany w nadrzędnej partycji Hyper-V (host), aby partycje podrzędne Hyper-V (maszyny wirtualne lub goście) mogły być monitorowane pod kątem ich zdrowia i przenoszone pomiędzy węzłami klastra. Ta konfiguracja ma następujące kluczowe zalety:

  • Jeśli maszyna fizyczna, na której są uruchomione Hyper-V i maszyny wirtualne, musi być aktualizowana, zmieniona lub ponownie uruchomiona, wtedy maszyny wirtualne mogą być przeniesione do innych węzłów klastra. Maszyny wirtualne mogą być przeniesione z powrotem, gdy tylko maszyna fizyczna zostanie ponownie uruchomiona.
  • Jeśli maszyna fizyczna, na której są uruchomione Hyper-V i maszyny wirtualne, ulegnie awarii (być może z powodu uszkodzenia płyty głównej) lub będzie poważnie zepsuta, inni członkowie klastra trybu awaryjnego (Windows Failover Cluster) przejmą własność maszyn wirtualnyh i automatycznie wprowadzą je w tryb online.
  • Jeśli maszyna wirtualna ulegnie awarii, może być ponownie uruchomiona na tym samym serwerze Hyper-V lub przeniesiona na inny serwer Hyper-V. Ponieważ jest to wykrywane przez Windows Server Failover Cluster, automatycznie podejmie on kroki oparte na ustawieniach właściwości zasobów maszyny wirtualnej. Przestój jest zminimalizowany dzięki automatyzacji wykrywania i odzyskiwania.

Rysunek 1 przedstawia to, co może się zdarzyć w takich sytuacjach. Najpierw maszyna wirtualna (VM2) znajduje się na Host A, a następnie VM2 zostaje przeniesiona na Host B. Zwróćmy uwagę, że podczas przenoszenia węzeł, który jest właścicielem pamięci SAN LUN 2 zmienia się z Hosta A na Host B. Aby rozwiązanie wysokiej dostępności spełniało nasze potrzeby dotyczące dostępności, trzeba uważnie rozmieścić maszyny wirtualne. Trzeba pomyśleć zarówno o pojemności, jak i wydajności.

Rysunek 1: Maszyna wirtualna i jej pamięć przeniesione do nowego hosta.

Pojemność węzłów powinna być wystarczająca, aby pomieścić wszystkie maszyny wirtualne i pozwolić, aby x węzłów uległo awarii lub było zabrane z aktywnego udziału klastra (X reprezentuje liczbę węzłów, których utratę jest w stanie tolerować klaster nadal udostępniając wszystkie maszyny wirtualne). Przy podejmowaniu decyzji o pojemności można zdecydować się na posiadanie kilku węzłów, które zwykle nie przechowują maszyn wirtualnych, jako rezerwy. Alternatywnie można rozłożyć maszyny wirtualne na wszystkie węzły, zapewniając węzłom dość dodatkowej pojemności, aby z powodzeniem przejąć własność i uruchomić maszyny wirtualne, jeśli x węzłów ulegnie awarii.

Ze względu na dzienną wydajność może być pożądane rozłożenie maszyn wirtualnych na wszystkie węzły klastra. Jeśli węzły są trzymane w rezerwie i nie przechowują żadnych maszyn wirtualnych, wtedy hosty przechowujące maszyny wirtualne będą wykorzystywać więcej zasobów, co może zmniejszyć wydajność maszyn wirtualnych, a także partycji zarządzania. Rozkładanie maszyn wirtualnych na węzły zmniejsza obciążenie, któremu poddawany jest każdy z nich i może zapewnić lepszą wydajność dla maszyn wirtualnych i partycji zarządzania. Jednak planowanie pojemności może być wtedy większym wyzwaniem. Oprogramowanie do zarządzania, takie jak System Center Virtual Machine Manager 2008 może pomóc w zapewnieniu obliczeń pojemności na potrzeby awarii węzła i umieszczenia maszyny wirtualnej.

 Do początku strony Do początku strony

Dostępność gościa

Dostępność gościa skupia się na wysokiej dostępności obciążenia, które jest uruchomione na maszynie wirtualnej. Do typowych obciążeń należą serwery plików i wydruku, IIS, oraz aplikacje biznesowe (LOB). Analizowanie potrzeb dotyczących wysokiej dostępności oraz rozwiązań dla obciążeń na maszynach wirtualnych jest bardzo podobne jak w przypadku niezależnych serwerów. Rozwiązanie będzie zależeć od określonego obciążenia.

Niektóre obciążenia mogą osiągać wysoką dostępność poprzez zastosowanie funkcji równoważenia obciążenia (Windows Network Load Balance, NLB), która pozwala, aby kilka serwerów było częścią puli o wspólnej nazwie sieciowej. Klienty tworzą żądania połączenia przy użyciu tej nazwy wirtualnej sieci, a połączenie jest tworzone do jednego z węzłów klastra NLB. Typowy scenariusz z użyciem klastrowania NLB to budowanie farm Web z usługami IIS, gdzie każdy oddzielny system ma IIS z takimi samymi stronami Web i dostęp do takich samych danych. NLB zapewnia równoważenie obciążenia, a także możliwość usuwania serwerów z członkostwa dla celów konserwacji lub w przypadku problemu z serwerem i dlatego zapewnia poziom wysokiej dostępności. Jeśli maszyna wirtualna Hyper-V uruchamia Windows Server 2008 (lub wcześniejszą wersję Windows Server, która zawiera NLB), gość może być członkiem klastra NLB z innymi gośćmi na tym samym lub innym hoście (hostach) Hyper-V.

Goście z uruchomionym Windows Server 2008 mogą użyć funkcji Windows Failover Cluster, aby zapewnić wysoką dostępność dla swoich obciążeń. Zastosowanie klastrowania Windows z pracą awaryjną na gościu (klastrowanie gościa) ma kilka, wymienionym poniżej zalet.

Monitorowanie zdrowia obciążenia Windows Failover Cluster zawiera monitor zasobów, który odwołuje się do biblioteki DLL zasobów związanych z klastrem. Każdy zasób ma monitorowane zdrowie, które testuje aplikację lub usługę zarządzaną przez zasób, aby zapewnić jej właściwe działanie. Te testy są zwykle nazywane kontrolą isAlive/looksAlive. Jeśli zasób nie przejdzie jednego z tych wywołań, sam zasób nie będzie działał. Zależnie od tego, jak są skonfigurowane jego właściwości, zasób może próbować ponownie uruchomić usługę lub aplikację lub może być przeniesiony do innego węzła w Windows Failover Cluster.

Konserwacja maszyny wirtualnej Jeśli konfiguracja maszyny wirtualnej musi być zmieniona lub jeśli system operacyjny lub oprogramowanie muszą być zaktualizowane lub zmienione, obciążenie będzie przeniesione do innego węzła klastra, a maszyna wirtualna będzie wyłączona albo zaktualizowana z minimalną przerwą dla użytkowników.

Konserwacja maszyny hosta J eśli maszyna fizyczna będąca hostem maszyny wirtualnej Hyper-V wymaga konserwacji lub aktualizacji oprogramowania, inni członkowie Windows Failover Cluster są umieszczani na innych hostach Hyper-V, obciążenie w wirtualnej maszynie może być przeniesione do innego węzła klastra, a dana maszyna wirtualna może zostać wyłączona, aby dostosować się do zmian lub ponownie uruchamia serwer fizyczny.

Awaria maszyny wirtualnej lub fizycznej Jeśli uszkodzony jest fizyczny host Hyper-V lub gość maszyny wirtualnej, inne węzły Windows Failover Cluster wykryją, że członek klastra już nie odpowiada lub nie bierze udziału w klastrze, funkcjonujące węzły przejmą w tryb online aplikacje lub usługi, które były uruchomione na niedziałającej maszynie wirtualnej.

 Do początku strony Do początku strony

Zapewnianie wysokiej dostępności maszyn wirtualnych

Konfigurowanie maszyny wirtualnej jako wysoko dostępnej oznacza po prostu przejście przez kreator HA Role Wizard zawarty w konsoli Failover Cluster Management. Maszyny wirtualne Hyper-V mają kilka kluczowych komponentów, które trzeba wziąć pod uwagę, gdy są zarządzane jako wysoko dostępne. Przyjrzyjmy się niektórym ważnym koncepcjom oraz wstępnym wymaganiom.

Węzły klastra trybu awaryjnego Każdy serwer fizyczny, który jest częścią klastra trybu awaryjnego jest nazywany węzłem. Dla celów klastrowania hosta usługa Failover Cluster jest uruchomiona w Windows Server 2008 na nadrzędnej partycji systemu Hyper-V. Pozwala to na skonfigurowanie maszyn wirtualnych, uruchomionych jako partycje podrzędne na tych samych serwerach fizycznych, jako maszyn wirtualnych o wysokiej dostępności. Maszyny wirtualne skonfigurowane dla HA będą pokazane jako zasoby w konsoli Failover Cluster Management.

Pamięć HA Wysoko dostępne maszyny wirtualne mogą być skonfigurowane, aby używały dysków VHD (Virtual Hard Disks), dysków typu passthrough oraz dysków różnicowych. Aby umożliwić przeniesienie maszyn wirtualnych między węzłami klastra trybu awaryjnego, potrzebna jest pamięć (przedstawiona jako dyski w Disk Management), do której można wejść przez każdy węzeł, który mógłby być hostem maszyny wirtualnej i który jest zarządzany przez usługę Failover Cluster. Dyski typu passthrough powinny być dodawane do klastra pracy awaryjnej jako zasoby dyskowe, a pliki VHD muszą znajdować się na dyskach, które są dodawane do klastrów pracy awaryjnej jako zasoby dyskowe.

Zasób maszyny wirtualnej Jest to typ zasobu klastra pracy awaryjnej, który reprezentuje maszynę wirtualną. Kiedy zasób maszyny wirtualnej jest ustawiany w tryb online, tworzona jest partycja podrzędna przez Hyper-V i uruchamiany jest system operacyjny w maszynie wirtualnej. Funkcja offline zasobu maszyny wirtualnej usuwa maszynę wirtualną z Hyper-V w węźle, na którym była udostępniana, a partycja podrzędna jest usuwana z hosta Hyper-V. Jeśli maszyna wirtualna jest wyłączona, zatrzymana lub ustawiona w stanie zapisanym, ten zasób będzie ustawiony w stan offline.

Zasób konfiguracji maszyny wirtualnej Jest to typ zasobu klastra pracy awaryjnej, który jest stosowany do zarządzania informacją konfiguracji dla maszyny wirtualnej. Dla każdej maszyny wirtualnej istnieje jeden zasób jej konfiguracji. Właściwość tego zasobu obejmuje ścieżkę do pliku konfiguracji, w którym są zawarte wszystkie informacje potrzebne do dodania wirtualnej maszyny do hosta Hyper-V. Dostęp do pliku konfiguracji jest konieczny do uruchomienia zasobu maszyny wirtualnej. Ponieważ konfiguracja jest zarządzana przez osobny zasób, konfiguracja zasobu maszyny wirtualnej może być modyfikowana, nawet gdy maszyna wirtualna jest w trybie offline.

Usługi maszyny wirtualnej oraz grupa aplikacji Aby usługa lub aplikacja stały się wysoko dostępne poprzez klastrowanie z pracą awaryjną, trzeba udostępnić wiele zasobów na tym samym węźle klastra pracy awaryjnej. Aby zapewnić, że te zasoby są zawsze na tym samym węźle i właściwie ze sobą współdziałają, są one umieszczane w grupach, które w Windows Server 2008 Failover Cluster nazywają się „Service or Application” (Usługa lub aplikacja). Zasób konfiguracji maszyny wirtualnej i jej zasób konfiguracji znajdują się zawsze w tej samej grupie usług lub aplikacji. W tej samej grupie Service lub Applications może również znajdować się jeden lub kilka zasobów dysków fizycznych (lub inny typ pamięci) zawierających VHD, plików konfiguracji lub dysków typu passthrough.

Zależności zasobów Ważne jest, aby zasób konfiguracji maszyny wirtualnej był w trybie online, zanim zasób maszyny wirtualnej będzie w trybie online (uruchomiony), oraz aby zasób konfiguracji maszyny wirtualnej był ustawiany w tryb offline, po tym jak zasób maszyny wirtualnej zostanie ustawiony w tryb offline (zatrzymany). Taka kolejność trybów online/offline zapewnia ustawianie właściwości zasobu maszyny wirtualnej, tak aby była ona zależna od zasobu konfiguracji maszyny wirtualnej. Jeśli mamy zasób pamięci, który zawiera plik dla zasobu konfiguracji maszyny wirtualnej lub zasób maszyny wirtualnej, wtedy ten zasób powinien stać sie zależny na tym zasobie (zasobach) pamięci. Jeśli na przykład maszyna wirtualna korzysta z plików VHD na dyskach G: oraz H:, zasób maszyny wirtualnej powinien zależeć od zasobu pliku konfiguracji, zasobu dla dysku G: oraz zasobu dla dysku H:.

 Do początku strony Do początku strony

Warunki wstępne

Są trzy warunki wstępne, aby maszyny wirtualne Hyper-V mogły stać się wysoko dostępne przy użyciu funkcji Failover Cluster w Windows Server 2008:

  1. Funkcja Failover Cluster w Windows Server 2008 musi być skonfigurowana dla każdego węzła klastra. Więcej informacji na temat konfigurowania i zarządzania klastrami pracy awaryjnej można znaleźć w sekcji „Artykuły na temat Hyper-V”.
  2. Rola Hyper-V musi zostać zainstalowana. Aktualizacje Hyper-V muszą być zainstalowane, a rola skonfigurowana dla każdego węzła klastra pracy awaryjnej (ponownie spójrzmy na „Artykuły na temat Hyper-V”). Hyper-V ma pakiet aktualizacji, który instaluje komponenty serwera Hyper-V, i jeszcze jeden pakiet, który instaluje konsolę zarządzania Hyper-V. Po zainstalowaniu aktualizacji dla komponentów serwera Hyper-V, rola może być dodana poprzez menedżera serwera (Server Manager) lub ServerManagerCMD.
  3. Trzeba mieć wspólną pamięć, dostępną dla maszyn wirtualnych. Pamięć powinna być zarządza przez klaster pracy awaryjnej jako wbudowany typ zasobu dysku fizycznego, lecz można użyć rozwiązania innej firmy do zarządzania współużytkowaną pamięcią. Oczywiście to rozwiązanie innej firmy musi obsługiwać funkcję Failover Clusters systemu Windows Server 2008.

 Do początku strony Do początku strony

Instalowanie wysokiej dostępności (HA)

Teraz zobaczmy, jak instalowane jest rozwiązanie wysokiej dostępności. Pierwszym krokiem jest zainstalowanie wirtualnej maszyny. Na jednym z węzłów klastra pracy awaryjnej, który miał zainstalowaną rolę Hyper-V, konfigurujemy maszynę wirtualną przy użyciu menedżera Hyper-V Manager (patrz rysunek 2). To może być nowa maszyna wirtualna, która jest konfigurowana ręcznie lub można zaimportować maszynę już istniejącą. Dyski VHD powinny być umieszczone na dysku, który jest zarządzany przez Windows Server 2008 Failover Cluster i który jest aktualnie online na węźle, na którym jest konfigurowana maszyna wirtualna.

Rysunek 2: Konfigurowanie wirtualnej maszyny.

Teraz przenosimy wirtualną maszynę w stan zatrzymania, zamykając ją, wyłączając lub zapisując stan. Tylko zatrzymane maszyny wirtualne mogą być skonfigurowane na potrzeby zarządzania przez klaster pracy awaryjnej.

Otwieramy konsolę Failover Cluster Manager (pokazaną na rysunku 3) na dowolnym serwerze, na którym jest uruchomiona rola Windows Server 2008 Failover Cluster lub na kliencie Windows Vista z uruchomionymi narzędziami Remote Server Administration Tools (RSAT). Dołączamy klaster pracy awaryjnej, wybierając działanie Manage a cluster… (Zarządzaj klastrem…), a następnie wybierając nazwę węzła lub klastra albo wybierając opcję połączenia z klastrem w węźle, na którym jest uruchomiona konsola.

Rysunek 3: Maszyna wirtualna w Failover Cluster Manager.

Z konsoli Failover Cluster Manager wybieramy działanie Configure a Service or Application… (Konfiguruj usługę lub aplikację...). To spowoduje otwarcie kreatora High Availability Wizard, który przeprowadzi nas przez konfigurowanie usług, aplikacji lub maszyny wirtualnej, które mają być zarządzane przez klaster pracy awaryjnej. Na stronie kreatora Select Service or Application (Wybierze usługę lub aplikację) wybieramy Virtual Machine (Maszyna wirtualna), a następnie Next (Dalej).

Strona Select Virtual Machine (Wybierz maszynę wirtualną) wyświetli wszystkie maszyny wirtualne, które są skonfigurowane na dowolnym węźle klastra pracy awaryjnej. Wybieramy maszynę wirtualną, a następnie Next. Strona kreatora Confirmation (Potwierdzenie) pokaże wszelkie ostrzeżenia lub błędy. Na tym etapie sprawdzana jest konfiguracja maszyny wirtualnej, aby potwierdzić, że może być ona skonfigurowana jako zasób HA i że węzły powinny być w stanie ją udostępniać. Wybór Next (Dalej) powoduje dodanie maszyny wirtualnej do klastra pracy awaryjnej jako zasobu wysoko dostępnego.

Strona Summary (Podsumowanie) podaje informacje o wynikach dodawania maszyny wirtualnej jako zasobu wysoko dostępnego, wraz z ostrzeżeniami. Przycisk View Report… (Wyświetl raport ...) może pokazać nam szczegóły zadań, które zostały wykonane, aby maszyna wirtualna była wysoko dostępna, a także wszelkie ostrzeżenia lub błędy. Na koniec wybieramy Finish (Zakończ), aby zamknąć kreatora High Availability Wizard.

Jak pokazuje okno na rysunku 3, konsola Failover Cluster Manager podaje listę obiektów z domyślną nazwą maszyny wirtualnej Virtual Machine(x) w lewym okienku, pod nazwą klastra i grupy Services or Applications. Z tej struktury drzewa wybieramy nazwę maszyny wirtualnej oraz zasoby, które są częścią tej grupy Services or Applications, która będzie pokazana w środkowym okienku konsoli. Jeśli jakaś inna maszyna wirtualna ma swoje pliki w tej samej pamięci co wybrana maszyna, ona również będzie dodana do grupy. Widoczne będą wszystkie maszyny wirtualne umieszczone w tej grupie oraz ich zasoby konfiguracji.

Okienko informacji dla grupy Services or Applications wyświetla takie informacje, jak Status (Status), Alerts (Alerty), Preferred Owners (Preferowani właściciele) oraz Current Owner (Aktualny właściciel). Węzeł Owner (Właściciel) jest węzłem, na którym maszyna wirtualna jest aktualnie skonfigurowana lub uruchomiona. Wybieramy akcję Move Virtual Machine(s) to another node (Przenieś maszynę(y) wirtualne do innego węzła), aby przełączyć maszyny wirtualne w tryb offline, a następnie uaktywnić je na innym węźle. Na ogół najlepszą praktyką jest przenoszenie maszyny wirtualnej do każdego węzła, na którym może ją udostępniać w klastrze pracy awaryjnej, aby sprawdzić, czy przeniesienie się udało i czy maszyna wirtualne uruchomi się i będzie działać.

 Do początku strony Do początku strony

Czynniki, które należy wziąć pod uwagę

Oto kilka kluczowych punktów, o których trzeba pamiętać przy ustawianiu maszyn wirtualnych do celów wysokiej dostępności:

Pamięć Jeśli maszyny wirtualne mają pliki VHD na tym samym, współużytkowanym dysku, to nawet jeśli znajdują się one na różnych woluminach na tym samym dysku, będą umieszczone w tej samej grupie Service or Application (Usługa lub aplikacja). Jedną z zalet udostępnienia dysku jest fakt, że pozwala on lepiej wykorzystać wspólny obszar pamięci.

Jednak kompromis jest taki, że za każdym razem, gdy maszyna wirtualna jest przenoszona, to wszystkie maszyny wirtualne w tej grupie będą przeniesione, niezależnie od tego, czy z powodu automatycznego odzyskiwania z maszyny wirtualnej, czy z powodu problemu z maszyną wirtualną, czy też zgodnie z wyborem administratora.

Litery dysków oraz identyfikatory GUID Woluminy mogą być tworzone bez przydzielania liter dysków. Maszyny wirtualne mogą korzystać z tych woluminów, a woluminy mogą być zarządzane przez klaster pracy awaryjnej. Jeśli zasób dyskowy ma woluminy, które używają identyfikatorów GUID zamiast liter dysków, GUID będzie pokazany w Cluster Management. Kiedy tworzymy maszyny wirtualne i określamy ścieżkę maszyn wirtualnych dla VHD, trzeba się upewnić, że GUID w ścieżce pasuje do GUID pokazywanego w Cluster Management dla woluminu. Jeśli GUID nie pasuje, uruchomienie (online) wirtualnej maszyny na innych węzłach klastra pracy awaryjnej może się nie udać.

Jest kilka sytuacji, które mogą spowodować, że identyfikatory GUID nie będą pasować. Jeśli wolumin został ustawiony w trybie online, zanim został dodany jako zasób dyskowy zarządzany przez klaster pracy awaryjnej, może mieć inny GUID na każdym węźle. Wolumin może mieć również kilka identyfikatorów GUID na pojedynczym węźle. Kiedy dysk zostanie dodany do klastra pracy awaryjnej jako zasób dysku fizycznego, we właściwościach tego zasobu dyskowego zostaną zapisane identyfikatory GUID woluminu używane na węźle, na którym dyski są w trybie online.

Identyfikatory GUID dla woluminów będą dodane do węzła po ustawieniu dysku w tryb online. Dzięki temu określony GUID, który został zapisany dla woluminu przez klaster pracy awaryjnej jest właściwą ścieżką na każdym węźle, który przełącza dysk w tryb online. Ten węzeł może mieć inne identyfikatory GUID, które również są związane z tym samym woluminem. Dlatego użytkownik może znaleźć GUID, który jest właściwy dla woluminu na tym węźle, lecz nie jest to ten sam GUID, który jest zapewniany przez klaster pracy awaryjnej jako GUID woluminu stosowany na innych węzłach. Symptomem tego problemu jest fakt, że zasobu maszyny wirtualnej, zwykle zasobu Konfiguracja, nie można przełączyć w tryb online i jest wyświetlany komunikat o błędzie wskazujący, że ścieżka jest niewłaściwa. Ścieżka podana w komunikacie błędu pokazuje GUID, który nie jest identyfikatorem GUID zarządzanym przez klaster dla tego woluminu.

Punkty montowania Woluminy, które są montowane do folderu w innym woluminie, zamiast przypisywania litery dysku lub stosowania identyfikatora GUID, mogą być używane z Hyper-V oraz klastrami pracy awaryjnej. Ponieważ obydwa woluminy – ten montowany oraz ten, który udostępnia punkt montowania – muszą być w tym samym węźle klastra pracy awaryjnej, wszystkie dyski muszą być częścią punktu montowania w grupie Failover Cluster Service lub Application.

Oczywiście nie ma problemu, gdy woluminy są na tych samych dyskach. Natomiast z pewnością problem istnieje, gdy woluminy są na różnych dyskach. Równie oczywisty, lecz nadal wart przypomnienia jest fakt, że obydwa woluminy – montowany oraz będący hostem punktu montowania –muszą współużytkować pamięć, która ma być zarządzana przez klaster pracy awaryjnej.

Dyski różnicowe Wszystkie pliki VHD, które są częścią dysków różnicowych muszą znajdować w pamięci współużytkowanej w tej samej grupie Services or Applications maszyny wirtualnej, korzystając z dysków różnicowych. W swojej najprostszej konfiguracji dysk różnicowy obejmuje dwa dyski VHD. Jeden z nich jest nadrzędny i zawiera zestaw danych data, służących jako baza, drugi dysk VHD jest dyskiem podrzędnym, powiązanym z nadrzędnym.

Przy pierwszym użyciu dysk różnicowy pojawia się jako nadrzędny. Jeśli dane są umieszczone na dysku nadrzędnym, są one czytane z tego VHD. Wszystkie zapisy mają miejsce na podrzędnym dysku VHD. Jeśli dane są umieszczone na dysku podrzędnym, wtedy zapis danych będzie odnosił się do podrzędnego VHD.

Jeśli maszyna wirtualna jest tak skonfigurowana, że podrzędny dysk VHD znajduje się we współużytkowanej pamięci, lecz dysk nadrzędny VHD nie znajduje się w pamięci współużytkowanej w tej samej grupie ani na dołączonym lokalnie urządzeniu pamięci, wtedy uruchomienie (online) maszyny wirtualnej może się nie powieźć, jeśli będzie ona przeniesiona do innego węzła. Kreator High Availability Wizard powinien sprawdzać, czy jest to dobrze skonfigurowane w maszynie wirtualnej i w przypadku wykrycia błędu wyświetlić komunikat. Te wymagania na nic się jednak nie zdają, gdy konfiguracja maszyny wirtualnej się zmieni.

 Do początku strony Do początku strony

Przydatne pojęcia związane z Hyper-V

Poniżej podano listę pojęć, które pomagają definiować komponenty lub funkcje wysoko dostępnego systemu Hyper-V (klaster hosta).

Partycja nadrzędna Wszystkie systemy operacyjne, które są uruchomione na serwerze hiperwizora mają przydzielone zasoby sprzętowe obejmujące RAM, procesor i inne komponenty systemu. W Hyper-V partycja, która zarządza konfiguracją hiperwizora oraz zasobami systemu, jest często nazywana partycją nadrzędną. Kiedy rola Hyper-V zostanie skonfigurowana, a serwer ponownie uruchomiony, instalacja Windows Server 2008, który był macierzystym systemem operacyjnym, staje się systemem operacyjnym w partycji nadrzędnej Hyper-V.

Partycja podrzędna Izolowane środowisko na serwerze Hyper-V, które jest konfigurowane do przechowywania systemu operacyjnego gościa oraz zapewnienia zasobów sprzętowych dla tego systemu operacyjnego.

Host Hyper-V Serwer fizyczny, który zawiera Hyper-V oraz system operacyjny uruchomiony wewnątrz partycji nadrzędnej.

Maszyna wirtualna Hyper-V Informacje o konfiguracji Hyper-V oraz dane, które służą do uruchomienia i działania podrzędnej partycji Hyper-V. Obejmuje to informację o konfiguracji do utworzenia partycji podrzędnej oraz pliki VHD lub dyski typu passthrough które zawierają jej dane.

Dysk typu passthrough Urządzenie pamięci, które jest udostępniane w Menedżerze dysku (Disk Management) jako dysk fizyczny przypisany do wyłącznego użytku przez gościa Hyper-V. Gość Hyper-V montuje dysk i korzysta z niego, tak jak ze swojego lokalnego urządzenia pamięci.

Wirtualny dysk twardy (VHD) Plik powiązany z podrzędną partycją Hyper-V, który jest udostępniany w systemie operacyjnym jako urządzenie pamięci (dysk). Plik.vhd jest umieszczony na urządzeniu pamięci zamontowanym przez nadrzędną partycję i może być bezpośrednio dołączonym urządzeniem pamięci lub pamięcią połączoną poprzez SAN, NAS lub SMB.

 Do początku strony Do początku strony

Artykuły na temat Hyper-V

O autorze

Steven Ekren jest starszym menedżerem produktu w zespole zajmującym się klastrami pracy awaryjnej oraz wysoką dostępnością Windows. Przez 12 lat Steven pracował w obsłudze technicznej firmy Microsoft, gdzie pomagał klientom firmowym w implementowaniu i rozwiązywaniu problemów z technologiach klastrów pracy awaryjnej, łącznie z Windows Hyper-V, System Center Virtual Machine Manager, Microsoft Virtual Server oraz Microsoft Virtual PC.

 Do początku strony Do początku strony

Windows Server 2008