Przewodnik po zagadnieniach dotyczących projektu sieci szkieletowej wirtualizacji
Dla kogo jest przeznaczony ten przewodnik? Jest on przeznaczony dla informatyków w średnich i dużych organizacjach odpowiedzialnych za projektowanie wirtualizacji sieci szkieletowej, która obsługuje wiele maszyn wirtualnych. W tym dokumencie są oni nazywani administratorami sieci szkieletowej. Osoby administrujące maszynami wirtualnymi w sieci szkieletowej są nazywani administratorami maszyn wirtualnych. Nie są oni jednak docelowymi odbiorcami tego dokumentu. W ramach danej organizacji konkretne osoby mogą odpowiadać za obie role.
W czym może być pomocny ten przewodnik? Ten przewodnik pozwala zrozumieć, jak projektować wirtualizację sieci szkieletowej umożliwiającą obsługę wielu maszyn wirtualnych w organizacji. W tym dokumencie kolekcja serwerów i funkcji hypervisor maszyn wirtualnych oraz urządzeń sprzętowych magazynu i sieci używana do obsługi maszyn wirtualnych w organizacji jest określana jako sieć szkieletowa wirtualizacji. Poniższy rysunek przedstawia przykładową sieć szkieletową wirtualizacji.
.jpeg "Sieć szkieletowa wirtualizacji")
Rysunek 1.Przykład sieci szkieletowej wirtualizacji
Uwaga: Każdy diagram w tym dokumencie jest dostępny na osobnej karcie w dokumencie Diagramy uwag dotyczących projektowania wirtualizacji sieci szkieletowej, który można pobrać po kliknięciu poszczególnych nazw rysunków w podpisach tabel.
Chociaż wszystkie sieci szkieletowe wirtualizacji zawierają serwery na potrzeby magazynu i hostingu maszyn wirtualnych (oprócz sieci, które łączą te elementy), projekt sieci szkieletowej wirtualizacji konkretnej organizacji będzie prawdopodobnie inny niż pokazany w tym przykładzie na Rysunku 1 z powodu różnic w wymaganiach.
Ten przewodnik zawiera szczegóły serii czynności i zadań, które można wykonać, aby ułatwić projektowanie sieci szkieletowej wirtualizacji spełniającej unikatowe wymagania danej organizacji. W ramach zadań i kroków przewodnik przedstawia informacje o odpowiednich technologiach i dostępnych opcjach funkcji pozwalających zapewnić wymagane poziomy funkcjonalności i jakości usługi (np. dostępność, skalowalność, wydajność, możliwości zarządzania i bezpieczeństwo).
Ten dokument ułatwia projektowanie możliwej do zarządzania sieci szkieletowej wirtualizacji, jednak nie omówiono w nim uwag dotyczących projektowania i opcji służących do obsługi sieci szkieletowej wirtualizacji i zarządzania nią za pomocą produktów, takich jak Microsoft System Center 2012 lub System Center 2012 R2. Aby uzyskać więcej informacji, zobacz temat System Center 2012 w bibliotece TechNet.
Ten przewodnik pomaga projektować sieć szkieletową wirtualizacji z użyciem systemów Windows Server 2012 R2 i Windows Server 2012 oraz sprzętu pochodzącego od dowolnego dostawcy. Niektóre funkcje omówione w dokumencie są unikatowe dla systemu Windows Server 2012 R2 i są oznaczone w dokumencie.
Założenia: Użytkownik ma pewne doświadczenie w zakresie wdrażania funkcji Hyper-V, maszyn wirtualnych, sieci wirtualnych, usług plików systemu Windows Server i klastra trybu failover oraz pewne doświadczenie w zakresie wdrażania serwerów fizycznych, magazynu i urządzeń sieciowych.
Zasoby dodatkowe
Przed rozpoczęciem projektowania sieci szkieletowej wirtualizacji przydatne mogą być informacje w następujących dokumentach:
Architektura referencyjna struktury usług w chmurze firmy Microsoft — model referencyjny
Architektura referencyjna struktury usług w chmurze firmy Microsoft — zasady, pojęcia i wzorce
Oba te dokumenty zawierają podstawowe pojęcia obecne w wielu sieciach szkieletowych wirtualizacji i mogą służyć jako podstawa dowolnego projektu sieci szkieletowej wirtualizacji.
Opinie: Aby wyrazić swoją opinię na temat tego dokumentu, wyślij wiadomość e-mail na adres virtua@microsoft.com.
Omówienie zagadnień dotyczących projektowania
Dalsza część tego dokumentu zawiera zestaw kroków i zadań, których można używać w celu projektowania sieci szkieletowej wirtualizacji najlepiej odpowiadającej konkretnym wymaganiom. Kroki są prezentowane w uporządkowanej kolejności. Uwagi dotyczące projektowania, o których można dowiedzieć się w dalszych krokach, mogą jednak powodować konieczność zmiany decyzji podjętych we wcześniejszych krokach z powodu wystąpienia konfliktów. W całym dokumencie staramy się podkreślać ryzyko potencjalnych konfliktów.
Aby opracować projekt najlepiej spełniający potrzeby, należy iteracyjnie stosować wskazówki zawarte w krokach dokumentu — tyle razy, ile to jest konieczne — tak aby uwzględnić je wszystkie.
Krok 1. Określanie wymagań dotyczących zasobów maszyny wirtualnej
Krok 2. Planowanie konfiguracji maszyny wirtualnej
Krok 3. Planowanie grup hostów wirtualizacji serwera
Krok 4. Planowanie hostów wirtualizacji serwera
Krok 5. Pojęcia związane z planowaniem architektury sieci szkieletowej wirtualizacji
Krok 6. Planowanie cech początkowych możliwości
Krok 1. Określanie wymagań dotyczących zasobów maszyny wirtualnej
Pierwszy krok projektowania sieci szkieletowej wirtualizacji ma na celu określenie wymagań dotyczących maszyn wirtualnych hostowanych w sieci szkieletowej. Sieć szkieletowa musi zawierać fizyczny sprzęt niezbędny w celu spełnienia tych wymagań. Wymagania dotyczące zasobów maszyny wirtualnej są określone przez systemy operacyjne i aplikacje przeznaczone do uruchamiania na maszynach wirtualnych. W pozostałej części niniejszego dokumentu kombinacja systemu operacyjnego i aplikacji przeznaczonych do uruchamiania na maszynie wirtualnej jest nazywana obciążeniem. Zadania w tym kroku pomagają zdefiniować wymagania dotyczące zasobów dla obciążeń.
Porada: Zamiast oceniać wymagania dotyczące zasobów istniejących obciążeń i następnie projektować sieć szkieletową wirtualizacji umożliwiającą obsługę każdego z nich, można zaprojektować sieć szkieletową wirtualizacji, która może zamiast tego spełniać potrzeby najbardziej typowych obciążeń. Następnie można osobno spełnić unikatowe wymagania poszczególnych obciążeń.
Przykładami takich sieci szkieletowych wirtualizacji są te udostępniane przez dostawców chmury publicznej, takich jak Microsoft Azure. Aby uzyskać więcej informacji, zobacz Rozmiary maszyn wirtualnych i usług w chmurze na platformie Azure.
Dostawcy chmury publicznej oferują zwykle kilka konfiguracji maszyn wirtualnych, które spełniają potrzeby większości obciążeń. W przypadku decyzji o zastosowaniu takiego podejścia można od razu przejść do części Krok 2. Planowanie konfiguracji maszyny wirtualnej w tym dokumencie. Dodatkowe korzyści wynikające z używania tej metody:
W przypadku podjęcia decyzji o migracji niektórych lokalnych maszyn wirtualnych do dostawcy usług w chmurze publicznej, jeśli typy konfiguracji lokalnych maszyn wirtualnych przypominają te udostępniane przez publicznego dostawcę, migracja maszyn wirtualnych będzie łatwiejsza niż w przypadku, gdy typy konfiguracji różnią się.
To podejście pozwala łatwiej prognozować wymagania dotyczące pojemności i korzystać z możliwości samoobsługi w zakresie obsługi administracyjnej sieci szkieletowej wirtualizacji. Oznacza to, że administratorzy maszyn wirtualnych w organizacji mogą automatycznie samodzielnie inicjować obsługę maszyn wirtualnych bez udziału administratorów sieci szkieletowej.
Zadanie 1. Określanie wymagań dotyczących zasobów obciążenia
Każde obciążenie ma wymagania dotyczące poniższych zasobów. W pierwszej kolejności należy odpowiedzieć na następujące pytania dotyczące każdego z obciążeń.
Procesor: Jakie są wymagania w zakresie szybkości procesora, architektury (Intel lub AMD) lub liczby procesorów?
Sieć: Jaka przepustowość sieci jest wymagana dla ruchu przychodzącego i wychodzącego (w gigabitach na sekundę — Gb/s)? Jakie jest maksymalne opóźnienie w sieci, przy którym obciążenie może jeszcze działać prawidłowo?
Magazyn: Ile gigabajtów (GB) magazynu wymagają pliki systemu operacyjnego i aplikacji obciążenia? Ile gigabajtów magazynu jest potrzebne do przechowywania danych obciążenia? Ile operacji we/wy na sekundę (IOPS) w magazynie wymaga obciążenie?
Pamięć: Ile pamięci wymaga obciążenie (w gigabajtach)? Czy obciążenie obsługuje technologię niejednolitego dostępu do pamięci (NUMA)?
Oprócz ustalenia powyższych wymagań dotyczących zasobów ważne jest również ustalenie:
Czy wymagania dotyczące zasobów są minimalne czy zalecane?
Ile wynosi szczytowe i średnie wymaganie w zakresie poszczególnych składników sprzętowych — godzinowo, dziennie, tygodniowo, miesięcznie i rocznie?
Ile minut przestoju miesięcznie jest możliwe do zaakceptowania w przypadku obciążenia i jego danych? W czasie określania powyższych informacji należy wziąć pod uwagę następujące kwestie:
Czy obciążenie działa tylko na jednej maszynie wirtualnej czy jest uruchamiane na kolekcji maszyn wirtualnych działającej jako jedna, na przykład przy użyciu kolekcji serwerów sieciowych z równoważeniem obciążenia obsługujących to samo obciążenie? W przypadku użycia kolekcji serwerów — czy możliwy do zaakceptowania czas przestoju dotyczy poszczególnych serwerów w kolekcji, wszystkich serwerów w kolekcji czy samej kolekcji?
Godziny pracy i czas poza godzinami pracy. Na przykład należy uwzględnić w wymaganiach tę kwestię, jeśli nikt nie korzysta z obciążenia między 21:00 a 6:00, ale krytyczne jest utrzymanie maksymalnej możliwej dostępności między 6:00 a 21:00 z możliwym do zaakceptowania czasem przestoju wynoszącym zaledwie 10 minut miesięcznie.
Ilość utraconych danych możliwa do zaakceptowania w przypadku nieoczekiwanej awarii infrastruktury wirtualnej. To wymaganie jest wyrażone w minutach, ponieważ replikacja infrastruktury wirtualnej jest zwykle definiowana z użyciem wartości czasu. Mimo że często w wymaganiach zakłada się brak utraty danych, należy pamiętać, że spełnienie takiego wymagania może wymagać poniesienia wysokich nakładów oraz obniżenia wydajności.
Czy pliki obciążenia i/lub jego dane muszą być szyfrowane na dysku i czy jego dane muszą być szyfrowane w czasie przesyłania między maszynami wirtualnymi i użytkownikami końcowymi.
W kontekście określania wymienionych wymagań dotyczących zasobów są dostępne następujące opcje.
Opcja |
Zalety |
Wady |
|---|---|---|
Ręczne ocenianie i rejestrowanie użycia zasobów |
Możliwość raportowania dowolnych informacji |
Może wymagać dużego nakładu pracy |
Aby automatycznie ocenić i zarejestrować użycie zasobów, użyj Zestawu narzędzi firmy Microsoft do oceny i planowania |
|
Raporty mogą, ale nie muszą, zawierać wszystkie dane, które są wymagane |
Uwaga: W przypadku wybrania opcji ręcznej oceny wymagań dotyczących zasobów możesz pobrać Arkusze Przewodnika po zagadnieniach dotyczących projektu sieci szkieletowej wirtualizacji i wprowadzić informacje w arkuszu Workload resource req. (Wymagania w zakresie zasobów obciążenia). Ten przewodnik odwołuje się do określonych arkuszy w wyżej wymienionym dokumencie.
Zadanie 2. Definiowanie cech obciążenia
Można określić dowolną liczbę cech obciążenia w środowisku. Poniższe przykłady wybrano, ponieważ każdy z nich wymaga innej konfiguracji składników sieci szkieletowej wirtualizacji, które zostaną dokładniej omówione w dalszych krokach.
Bezstanowe: Po początkowym zainicjowaniu i przypisaniu unikatowych nazw komputerów i adresów sieciowych nie zapisują na swoich dyskach lokalnych żadnych unikatowych informacji. Mogą jednak zapisywać unikatowe informacje w innym magazynie, na przykład w bazie danych. Obciążenia bezstanowe są optymalne w kontekście sieci szkieletowej wirtualizacji, ponieważ możliwe jest utworzenie głównego obrazu maszyny wirtualnej. Następnie taki obraz można łatwo kopiować i uruchamiać w sieci szkieletowej wirtualizacji na potrzeby skalowania obciążenia lub szybkiego zastąpienia maszyny wirtualnej, która stała się niedostępna na skutek awarii hosta wirtualizacji. Przykładem bezstanowego obciążenia jest serwer sieci Web z uruchomioną aplikacją frontonu.
Stanowe: Po początkowym zainicjowaniu i przypisaniu unikatowych nazw komputerów i adresów sieciowych zapisują na swoich dyskach lokalnych unikatowe informacje. Mogą również zapisywać unikatowe informacje w innym magazynie, na przykład w bazie danych. Obciążenia stanowe zwykle wymagają bardziej złożonych strategii inicjowania i skalowania niż bezstanowe. Strategie wysokiej dostępności dla obciążeń stanowych mogą wymagać udostępniania stanu między maszynami wirtualnymi. Przykładem obciążenia stanowego jest aparat bazy danych programu SQL Server.
Stanowe z udostępnianiem: Są to obciążenia stanowe, które wymagają udostępniania stanu między maszynami wirtualnymi. Te obciążenia często używają możliwości klastra trybu failover systemu Windows Server w celu zapewniania wysokiej dostępności, co wymaga dostępu do udostępnionego magazynu. Przykładem stanowego obciążenia z udostępnianiem jest program Microsoft System Center — Virtual Machine Manager.
Inne: Charakteryzuje obciążenia, które mogą nie działać w ogóle albo nie działać optymalnie w sieci szkieletowej wirtualizacji. Takie obciążenia cechuje:
Dostęp do fizycznych urządzeń peryferyjnych. Przykładem takiej aplikacji jest obciążenie obsługi telefonii, które komunikuje się z fizyczną telefoniczną kartą sieciową hosta.
Znacznie wyższe wymagania w zakresie zasobów niż w przypadku innych obciążeń. Przykładem jest aplikacja działająca w czasie rzeczywistym, która wymaga mniej niż jednej milisekundy opóźnienia między warstwami aplikacji.
W przypadku takich obciążeń może nie być możliwe uruchamianie ich w sieci szkieletowej wirtualizacji lub mogą one wymagać bardzo specyficznego zestawu sprzętu lub konfiguracji, który nie jest podobny do większości innych obciążeń.
Uwaga: Cechy obciążenia można zdefiniować w arkuszu Settings (Ustawienia), a następnie można wybrać odpowiednie cechy obciążeń w arkuszu Workload resource req. (Wymagania w zakresie zasobów obciążenia).
Krok 2. Planowanie konfiguracji maszyny wirtualnej
W tym kroku należy zdefiniować typy maszyn wirtualnych spełniających wymagania dotyczące zasobów i cech obciążeń, które zostały zdefiniowane w kroku 1.
Zadanie 1. Definiowanie konfiguracji obliczeniowej
W ramach tego zadania należy określić ilość pamięci i liczbę procesorów, które są wymagane dla każdej maszyny wirtualnej.
Zadanie 1a. Definiowanie typu generacji maszyny wirtualnej
W systemie Windows Server 2012 R2 wprowadzono maszyny wirtualne drugiej generacji. Maszyny wirtualne drugiej generacji obsługują funkcje sprzętu i wirtualizacji, które nie są obsługiwane przez maszyny wirtualne pierwszej generacji. Ważne jest podjęcie prawidłowej decyzji dotyczącej wymagań, ponieważ po utworzeniu maszyny wirtualnej nie można zmienić jej typu.
Maszyny wirtualne drugiej generacji udostępniają następujące nowe funkcje:
Rozruch za pomocą standardowej karty sieciowej w środowisku PXE
Rozruch z wirtualnego dysku twardego SCSI
Rozruch z wirtualnego dysku DVD SCSI
Bezpieczny rozruch (domyślnie włączony)
Obsługa oprogramowania układowego UEFI
Maszyny wirtualne drugiej generacji obsługują następujące systemy operacyjne gościa:
Windows Server 2012 R2
Windows Server 2012
Wersje 64-bitowe systemu Windows 8.1
Wersje 64-bitowe systemu Windows 8
Określone wersje systemu Linux Aby uzyskać listę dystrybucji i wersji obsługujących maszyny wirtualne drugiej generacji, zobacz Maszyny wirtualne z systemem Linux w ramach funkcji Hyper-V.
Poniższa tabela zawiera listę zalet i wad maszyn wirtualnych pierwszej generacji i drugiej generacji.
Opcja |
Zalety |
Wady |
|---|---|---|
Pierwsza generacja |
|
Brak dostępu do nowych funkcji maszyn wirtualnych |
Druga generacja |
|
|
Ważne: Funkcja Bezpieczny rozruch nie jest obsługiwana w przypadku maszyn wirtualnych drugiej generacji z systemem Linux. Jeśli tworzysz maszynę wirtualną i zamierzasz zainstalować system Linux, w jej ustawieniach wyłącz funkcję Bezpieczny rozruch.
Informacje dodatkowe:
Omówienie maszyn wirtualnych drugiej generacji
Zadanie 1b. Definiowanie pamięci
Rozmiar pamięci maszyny wirtualnej należy zaplanować tak, jak zwykle jest on planowany dla aplikacji serwerowych na komputerze fizycznym. Należy zapewnić, że oczekiwane obciążenia będą mogły być obsługiwane w normalnych godzinach i w godzinach szczytu. Zbyt mały rozmiar pamięci może znacznie zwiększyć czas reakcji i użycie procesora CPU lub we/wy.
Pamięć statyczna lub dynamiczna
Pamięć statyczna to ilość pamięci przypisanej do maszyny wirtualnej. Jest zawsze przydzielana podczas uruchamiania maszyny wirtualnej i nie zmienia się w czasie, gdy maszyna wirtualna działa. Cała pamięć jest przypisywana do maszyny wirtualnej podczas uruchamiania, zaś pamięć, która nie jest używana przez maszynę wirtualną, nie jest dostępna dla innych maszyn wirtualnych. Jeśli na hoście nie ma dostępnej wystarczającej ilości pamięci do przydzielenia do maszyny wirtualnej, gdy jest ona uruchamiana, maszyna wirtualna nie zostanie uruchomiona.
Pamięć statyczna dobrze sprawdza się w przypadku obciążeń intensywnie wykorzystujących pamięć i obciążeń, które mają własne systemy zarządzania pamięcią, takich jak program SQL Server. Tego rodzaju obciążenia będą działać lepiej z pamięcią statyczną.
Uwaga: Nie ma ustawienia włączania pamięci statycznej. Pamięć statyczna jest włączona, gdy ustawienie pamięci dynamicznej nie jest włączone.
Pamięć dynamiczna pozwala na lepsze wykorzystanie pamięci fizycznej w systemie przez równoważenie całkowitej ilości pamięci fizycznej między wieloma maszynami wirtualnymi przez przydzielanie większej ilości pamięci do maszyn wirtualnych, które są zajęte, i usuwanie przydziału pamięci dla mniej intensywnie używanych maszyn wirtualnych. Może to prowadzić do uzyskania wyższych współczynników konsolidacji, szczególnie w dynamicznych środowiskach, takich jak serwery infrastruktury pulpitów wirtualnych (VDI) lub sieci Web.
W przypadku użycia pamięci statycznej, gdy do maszyny wirtualnej jest przypisane 10 GB pamięci, ale maszyna używa tylko 3 GB, pozostałe 7 GB pamięci nie będzie dostępne do użycia przez inne maszyny wirtualne. Gdy maszyna wirtualna używa pamięci dynamicznej, używa tylko ilości pamięci, która jest wymagana (ale nie niższej niż skonfigurowana minimalna ilość pamięci RAM). Powoduje to zwolnienie większej ilości pamięci dla innych maszyn wirtualnych.
Poniższa tabela zawiera listę zalet i wad dla pamięci statycznych i dynamicznych.
Opcja |
Zalety |
Wady |
|---|---|---|
Pamięć statyczna |
|
|
Pamięć dynamiczna |
|
|
Dostępne są następujące ustawienia konfiguracji pamięci:
Początkowa pamięć RAM: Określa ilość pamięci wymaganą do uruchomienia maszyny wirtualnej. Wartość musi być odpowiednio wysoka, aby umożliwić uruchomienie systemu operacyjnego gościa, ale powinna być możliwie jak najmniejsza, aby umożliwić optymalne wykorzystanie pamięci i potencjalnie zapewnienie wyższego współczynnika konsolidacji.
Minimalna ilość pamięci RAM: Określa minimalną ilość pamięci, która powinna zostać przydzielona do maszyny wirtualnej po jej uruchomieniu. Najmniejsza możliwa wartość to 32 MB, a największa to ustawienie Początkowa pamięć RAM. To ustawienie jest dostępne tylko wtedy, gdy jest włączona pamięć dynamiczna.
Maksymalna ilość pamięci RAM: Określa maksymalną ilość pamięci, której może używać maszyna wirtualna. Najmniejsza wartość to ustawienie Początkowa pamięć RAM, a największa to 1 TB. Jednak maszyna wirtualna może używać ilości pamięci nie większej niż maksymalna ilość obsługiwana przez system operacyjny gościa. Na przykład jeśli określisz 64 GB dla maszyny wirtualnej z systemem operacyjnym gościa, który obsługuje maksymalnie 32 GB, maszyna wirtualna nie będzie mogła użyć więcej niż 32 GB. To ustawienie jest dostępne tylko wtedy, gdy jest włączona pamięć dynamiczna.
Waga pamięci: Zapewnia funkcji Hyper-V możliwość określenia sposobu dystrybucji pamięci między maszynami wirtualnymi, jeśli nie jest dostępna wystarczająca ilość fizycznej pamięci na hoście w celu przydzielenia wszystkim maszynom wirtualnym ich żądanej ilości pamięci. Maszyny wirtualne mające wyższą wagę pamięci mają pierwszeństwo przed maszynami wirtualnymi z niższymi wagami pamięci.
Uwagi:
Nie można używać jednocześnie pamięci dynamicznej i wirtualnej architektury NUMA. Maszyny wirtualne, które korzystają z pamięci dynamicznej, w praktyce mają tylko jeden wirtualny węzeł NUMA, a topologia NUMA nie jest udostępniana maszynie wirtualnej niezależnie od ustawień wirtualnej architektury NUMA.
Podczas instalowania lub uaktualniania systemu operacyjnego maszyny wirtualnej ilość pamięci, która jest dostępna dla maszyny wirtualnej podczas instalacji i procesu uaktualniania, jest wartością określoną jako Początkowa pamięć RAM. Nawet wtedy, gdy dla maszyny wirtualnej została skonfigurowana pamięć dynamiczna, maszyna wirtualna używa tylko ilości pamięci, która jest skonfigurowana w ustawieniu Początkowa pamięć RAM. Upewnij się, że wartość Początkowa pamięć RAM spełnia wymagania minimalnej ilości pamięci systemu operacyjnego podczas wykonywania procedur instalacji lub uaktualniania.
System operacyjny gościa działający na maszynie wirtualnej musi obsługiwać pamięć dynamiczną.
Złożone aplikacje bazy danych, takie jak program SQL Server lub Exchange Server, implementują własnych menedżerów pamięci. Zapoznaj się z dokumentacją obciążenia w celu określenia, czy obciążenie jest zgodne z pamięcią dynamiczną.
Informacje dodatkowe:
Zadanie 1c. Definiowanie procesora
Należy określić następujące ustawienia konfiguracji maszyny wirtualnej:
Określ liczbę procesorów wymaganych dla każdej maszyny wirtualnej. To często będzie taka sama wartość jak liczba procesorów wymaganych przez obciążenie. Funkcji Hyper-V obsługuje maksymalnie 64 procesory wirtualne na maszynie wirtualnej.
Określ kontrolę zasobów dla każdej maszyny wirtualnej. Można skonfigurować limity, aby zapewnić, że żadna maszyna wirtualna będzie mogła zająć całych zasobów procesora hosta wirtualizacji.
Zdefiniuj topologię architektury NUMA. Dla intensywnych obciążeń wykorzystujących architekturę NUMA można określić maksymalną liczbę procesorów, dozwoloną ilość pamięci w jednym wirtualnym węźle NUMA oraz dozwoloną maksymalną liczbę węzłów na pojedynczy procesor. Aby uzyskać więcej informacji, zobacz temat Omówienie wirtualnej architektury NUMA funkcji Hyper-V.
Uwaga: Nie można używać jednocześnie wirtualnej architektury NUMA i pamięci dynamicznej. Jeśli chcesz określić, czy ma być używana pamięć dynamiczna czy architektura NUMA, odpowiedz na następujące pytania. Jeśli w obu przypadkach odpowiedzi są twierdzące, włącz wirtualną architekturę NUMA i nie włączaj pamięci dynamicznej.
Czy obciążenie działające na maszynie wirtualnej obsługuje architekturę NUMA?
Czy maszyna wirtualna zajmie więcej zasobów, procesorów lub pamięci niż jest dostępne w jednym fizycznym węźle NUMA?
Zadanie 1d. Definiowanie obsługiwanych systemów operacyjnych
Należy zapewnić, że system operacyjny wymagany przez obciążenie jest obsługiwany jako system operacyjny gościa. Zapoznaj się z następującymi informacjami:
Supported Windows Guest Operating Systems for Hyper-V in Windows Server 2012 R2 and Windows 8.1
Supported Windows Guest Operating Systems for Hyper-V in Windows Server 2012 and Windows 8
W przypadku systemu Linux: Aby uzyskać informacje o obsługiwanych dystrybucjach systemu Linux, zobacz Maszyny wirtualne z systemem Linux i funkcja Hyper-V.
Uwaga: Funkcja Hyper-V udostępnia pakiet oprogramowania dla obsługiwanych systemów operacyjnych gościa, który zapewnia wyższą wydajność i lepszą integrację komputera fizycznego i maszyny wirtualnej. Ta kolekcja usług i sterowników oprogramowania jest nazywana usługami integracji. Aby zapewnić najwyższą wydajność maszyn wirtualnych, należy korzystać z najnowszej wersji usług integracji.
Licencjonowanie
Należy zapewnić, że systemy operacyjne gościa będą prawidłowo licencjonowane. W przypadku uruchamiania zwirtualizowanego środowiska zapoznaj się z dokumentacją dostawcy, aby sprawdzić wszelkie wymagania dotyczące licencjonowania.
Automatyczna aktywacja maszyny wirtualnej (AVMA) to funkcja, która została wprowadzona w systemie Windows Server 2012 R2. Funkcja AVMA wiąże aktywację maszyny wirtualnej z licencjonowanym serwerem wirtualizacji i aktywuje maszynę wirtualną podczas jej uruchamiania. Eliminuje to konieczność wprowadzania informacji dotyczących licencjonowania i aktywowania poszczególnych maszyn wirtualnych.
Funkcja AVMA wymaga, aby na hoście był uruchomiony system Windows Server 2012 R2 Datacenter i aby systemami operacyjnymi gościa maszyny wirtualnej były system Windows Server 2012 R2 Datacenter, system Windows Server 2012 R2 Standard lub system Windows Server 2012 R2 Essentials.
Uwaga: Funkcję AVMA należy skonfigurować na każdym hoście w sieci szkieletowej wirtualizacji.
Informacje dodatkowe:
Automatyczna aktywacja maszyny wirtualnej
Zadanie 1e. Definiowanie konwencji nazewnictwa maszyny wirtualnej
Istniejąca strategia nazewnictwa komputerów może opierać się na tym, gdzie fizycznie znajduje się komputer lub serwer. Maszyny wirtualne można przenosić z hosta do hosta, a nawet do różnych centrów danych, więc istniejąca strategia nazewnictwa może nie być w tym przypadku skuteczna. Aktualizacja istniejącej konwencji nazewnictwa pozwalająca wskazać, że komputer działa jako maszyna wirtualna, może pomóc określać lokalizację uruchomionej maszyny wirtualnej.
Zadanie 2. Definiowanie konfiguracji sieci
Każda maszyna wirtualna będzie odbierać lub wysyłać różne rodzaje ruchu w sieci. Każdy typ ruchu sieciowego będzie mieć różne wymagania w zakresie wydajności, dostępności i zabezpieczeń.
Maszyny wirtualne pierwszej generacji mogą mieć maksymalnie 12 kart sieciowych — 4 karty sieciowe starszej wersji i 8 wirtualnych kart sieciowych. Maszyny wirtualne drugiej generacji nie obsługują kart sieciowych starszej wersji, więc maksymalną obsługiwaną liczbą kart jest 8.
Zadanie 2a. Określanie typów ruchu sieciowego
Każda maszyna wirtualna będzie wysyłać i odbierać różne typy danych, takie jak:
Dane aplikacji
Kopie zapasowe danych
Komunikacja z komputerami klienckimi, serwerami lub usługami
Komunikacji wewnątrz klastra, jeśli obciążenie jest częścią klastra trybu failover maszyny wirtualnej gościa
Pomoc techniczna
Magazyn
Jeśli masz już istniejące sieci, które są przeznaczone dla różnych typów ruchu w sieci, możesz ich użyć do wykonania tego zadania. Jeśli definiujesz nowe projekty sieci do obsługi sieci szkieletowej wirtualizacji, dla poszczególnych maszyn wirtualnych można zdefiniować rodzaje ruchu sieciowego, które będą przez nie obsługiwane.
Zadanie 2b. Definiowanie opcji wydajności ruchu sieciowego
Każdy typ ruchu sieciowego ma wymagania minimalnego opóźnienia i maksymalnej przepustowości. W poniższej tabeli przedstawiono strategie, których można użyć, aby spełnić różne wymagania dotyczące wydajności sieci.
Strategia |
Zalety |
Wady |
|---|---|---|
Rozdzielenie typów ruchu między różnymi fizycznymi kartami sieciowymi |
Dzieli ruch, tak aby nie łączyć ze sobą różnych typów ruchu |
|
Zarządzanie przepustowością funkcji Hyper-V (Jakość usługi (QoS) funkcji Hyper-V) |
|
|
Wirtualizacja SR-IOV |
|
|
|
|
|
Duże ramki |
|
|
Zadanie 2c. Definiowanie opcji dostępności ruchu sieciowego
Funkcja tworzenia zespołu kart sieciowych, nazywana również równoważeniem obciążenia i trybem failover (LBFO), pozwala na umieszczenie w zespole wielu kart sieciowych na potrzeby trybu failover i agregacji ruchu. Zapewnia to dostępność połączenia w przypadku awarii składnika sieci. Zespoły kart sieciowych zwykle są skonfigurowane na hoście, a po utworzeniu przełącznika wirtualnego jest on wiązany z zespołem kart sieciowych.
Wdrożone przełączniki sieciowe określają tryb działania zespołu kart sieciowych. Ustawienia domyślne w systemie Windows Server 2012 R2 powinny być wystarczające w większości wdrożeń.
Uwaga: Wirtualizacja SR-IOV nie jest zgodna z zespołami kart sieciowych. Aby uzyskać więcej informacji na temat wirtualizacji SR-IOV, zobacz część Zadanie 2b. Definiowanie opcji wydajności ruchu sieciowego.
Informacje dodatkowe:
Omówienie zespołów kart sieciowych
Zadanie 2d. Definiowanie opcji zabezpieczeń ruchu sieciowego
Każdy typ ruchu sieciowego może mieć różne wymagania w zakresie zabezpieczeń, na przykład wymagania dotyczące izolacji i szyfrowania. W poniższej tabeli opisano strategie, których można użyć na potrzeby spełnienia różnych wymagań w zakresie zabezpieczeń.
Strategia |
Zalety |
Wady |
|---|---|---|
Rozdzielenie między różnymi kartami sieciowymi |
Oddziela ruch od innego ruchu sieciowego |
Powoduje trudności w kontekście skalowania. Im więcej masz sieci, tym więcej potrzebujesz kart sieciowych zainstalowanych na hoście i zarządzanych na nim. |
Protokół IPsec z odciążaniem zadań protokołu IPsec |
|
|
Znakowanie sieci VLAN |
|
|
|
|
|
|
Minimalny wpływ na wydajność |
|
|
Minimalny wpływ na wydajność |
Decyzje projektowe — pobierz Arkusze Przewodnika po zagadnieniach dotyczących projektu sieci szkieletowej wirtualizacji i zmień przykładowe dane w arkuszu Virtual machine configs. (Konfiguracje maszyny wirtualnej), aby zebrać decyzje podjęte w poprzednich zadaniach tego kroku. W przypadku kolejnych decyzji projektowych ten dokument odwołuje się do określonych arkuszy wspomnianego przewodnika, w których można wprowadzać dane.
Zadanie 2e. Definiowanie wirtualnych kart sieciowych
Określenie typów ruchu wymaganego przez maszyny wirtualne, oprócz wydajności, dostępności i strategii zabezpieczeń ruchu sieciowego, pozwala stwierdzić, ile wirtualnych kart sieciowych jest wymaganych dla każdej maszyny wirtualnej.
Wirtualna karta sieciowa jest podłączona do przełącznika wirtualnego. Istnieją trzy typy przełączników wirtualnych:
Zewnętrzny przełącznik wirtualny
Wewnętrzny przełącznik wirtualny
Prywatny przełącznik wirtualny
Zewnętrzny przełącznik wirtualny udostępnia maszynie wirtualnej dostęp do sieci fizycznej za pośrednictwem karty sieciowej skojarzonej z przełącznikiem wirtualnym, z którym nawiązuje ona połączenie. Fizyczną kartę sieciową na hoście można skojarzyć tylko z jednym przełącznikiem zewnętrznym.
Maszyny wirtualne pierwszej generacji mogą mieć maksymalnie 12 kart sieciowych — 4 karty sieciowe starszej wersji i 8 wirtualnych kart sieciowych. Maszyny wirtualne drugiej generacji nie obsługują kart sieciowych starszej wersji, więc maksymalna obsługiwana liczba kart to 8. Wirtualna karta sieciowa może mieć przypisany jeden identyfikator sieci VLAN, o ile nie jest skonfigurowana w trybie magistrali.
Jeśli chcesz przypisać ruch maszyny wirtualnej do różnych sieci VLAN, karta sieciowa, która obsługuje sieci VLAN, musi być zainstalowana na hoście i przypisana do przełącznika wirtualnego. Identyfikator sieci VLAN dla maszyny wirtualnej można ustawić we właściwościach maszyny wirtualnej. Identyfikator sieci VLAN, który jest ustawiony w przełączniku wirtualnym, jest identyfikatorem sieci VLAN, który zostanie przypisany do wirtualnej karty sieciowej przypisanej do systemu operacyjnego hosta.
Uwaga: W przypadku gdy maszyna wirtualna wymaga dostępu do większej liczby sieci niż liczba dostępnych kart sieciowych, dla karty sieciowej maszyny wirtualnej można włączyć tryb magistrali sieci VLAN za pomocą polecenia cmdlet środowiska Windows PowerShell Set-VMNetworkAdapterVlan.
Zadanie 2f. Definiowanie strategii adresowania IP
Należy określić, jak adresy IP będą przypisywane do maszyn wirtualnych. Jeśli to zadanie nie zostanie wykonane, mogą wystąpić konflikty adresów IP, które mogą mieć wpływ na inne maszyny wirtualne i fizyczne urządzenia w sieci.
Ponadto nieautoryzowane serwery DHCP mogą destabilizować infrastrukturę sieci i mogą być szczególnie trudne do wykrycia, gdy serwer działa jako maszyna wirtualna. Sieć można chronić przed nieautoryzowanymi serwerami DHCP działającymi na maszynach wirtualnych przez włączenie funkcji DHCPGuard w ustawieniach maszyn wirtualnych. Funkcja DHCPGuard chroni przed powodującymi destabilizację maszynami wirtualnymi, które anonsują się jako serwery DHCP i mogą być źródłem ataków typu man-in-the-middle.
Informacje dodatkowe:
Omówienie protokołu Dynamic Host Configuration Protocol (DHCP)
Zarządzanie adresami IP (IPAM) — omówienie
Zadanie 3. Definiowanie konfiguracji magazynu
Aby określić konfigurację magazynu, należy zdefiniować typy danych, które będą przechowywane przez maszyny wirtualne, i potrzebne typy magazynu.
Zadanie 3a. Definiowanie typów danych
Poniższa tabela zawiera listę typów danych przechowywanych przez maszyny wirtualne oraz miejsc, w których te typy danych są zwykle przechowywane.
Typ danych |
Lokalizacja magazynu dla typu danych |
|---|---|
Pliki systemu operacyjnego |
W pliku wirtualnego dysku twardego, który jest przechowywany przez hosta wirtualizacji. Uwagi dotyczące magazynu dla hosta wirtualizacji są opisane bardziej szczegółowo w sekcji Krok 4. Planowanie hostów serwerów wirtualizacji poniżej. |
Plik stronicowania systemu Windows |
Często przechowywany w tej samej lokalizacji co pliki systemu operacyjnego. |
Pliki programów aplikacji |
Często przechowywane w tej samej lokalizacji co pliki systemu operacyjnego. |
Dane konfiguracji aplikacji |
Często przechowywane w tej samej lokalizacji co pliki systemu operacyjnego. |
Dane aplikacji |
Często przechowywane w innej lokalizacji niż pliki aplikacji i systemu operacyjnego. Na przykład jeśli aplikacja to aplikacja bazy danych, pliki bazy danych są często przechowywane na wysoce dostępnych, wydajnych, sieciowych pamięciach masowych w innej lokalizacji niż pliki aplikacji lub systemu operacyjnego. |
Udostępnione woluminy klastra (CSV) i monitor dysku (wymagane w przypadku klastrowania maszyn wirtualnych gościa) |
Często przechowywane w innej lokalizacji niż pliki aplikacji i systemu operacyjnego.
|
Pliki zrzutu awaryjnego |
Często przechowywane w tej samej lokalizacji co pliki systemu operacyjnego. |
Zadanie 3b. Definiowanie typów magazynu
Poniższa tabela zawiera typy magazynu, które mogą być używane na potrzeby typów danych zdefiniowanych sekcji Krok 2. Zadanie 2a. powyżej.
Typ magazynu |
Kwestie do rozważenia |
|---|---|
Wirtualny dysk IDE |
Maszyny wirtualne pierwszej generacji:
Maszyny wirtualne drugiej generacji nie obsługują urządzeń IDE. |
Wirtualne urządzenie SCSI |
|
Inicjator iSCSI na maszynie wirtualnej |
|
Wirtualny protokół Fibre Channel |
|
Protokół SMB 3.0 |
Zapewnia dostęp do plików przechowywanych w udziałach protokołu SMB 3.0 z maszyny wirtualnej. |
Zadanie 3c. Definiowanie formatu i typu wirtualnego dysku twardego
Jeśli jest używany typ magazynu wirtualnego dysku twardego, należy wybrać format wirtualnego dysku twardego do użycia spośród opcji wymienionych w poniższej tabeli.
Format dysku |
Zalety |
Wady |
|---|---|---|
VHD |
|
|
|
|
|
Używany na potrzeby udostępnionego magazynu klastrów maszyny wirtualnej gościa |
|
Następnie wybierz typ dysku, który będzie używany, z opcji wymienionych w poniższej tabeli.
Typ dysku |
Zalety |
Wady |
|---|---|---|
Stały |
|
|
Dynamiczny |
Używa tylko potrzebnej ilości miejsca, a nie całego przypisanego mu miejsca |
|
Różnicowy |
W przypadku użycia wielu dysków różnicowych z tym samym elementem nadrzędnym można zużyć mniej miejsca na dysku |
|
Podczas wybierania typu i formatu pliku wirtualnego dysku twardego należy wziąć pod uwagę poniższe kwestie:
W przypadku użycia formatu VHDX można użyć dysku dynamicznego, ponieważ zapewnia on gwarancje niezawodności (oprócz oszczędności miejsca, która jest skutkiem przydzielania miejsca tylko wtedy, gdy istnieje taka potrzeba).
Bez względu na format można również użyć dysku stałego, gdy magazyn w woluminie hostingu nie jest aktywnie monitorowany. Zapewnia to, że będzie dostępna wystarczająca ilość miejsca na dysku, gdy plik VHD będzie zapełniany w czasie wykonywania.
Użycie punktów kontrolnych (wcześniej nazywanych migawkami) maszyny wirtualnej powoduje utworzenie różnicowego dysku twardego przechowującego zapisy na dyskach. Wystarczy, że będzie używanych tylko kilka punktów kontrolnych, a użycie procesora CPU związane z we/wy magazynu wrośnie, ale nie musi to znacznie wpłynąć na wydajność (z wyjątkiem intensywnych obciążeń we/wy serwera).
Jednak długie łańcuchy punktów kontrolnych mogą znacznie wpłynąć na wydajność, ponieważ odczyty z wirtualnych dysków twardych mogą wymagać wykonania sprawdzania dla żądanych bloków na wielu dyskach różnicowych. Utrzymywanie krótkich łańcuchów punktów kontrolnych jest bardzo istotne pod kątem zapewnienia wysokiej wydajności we/wy dysku.
Zadanie 3d. Definiowanie typu magazynu do użycia w przypadku każdego typu danych
Po zdefiniowaniu typów danych i typów magazynu przechowywanych przez maszyny wirtualne można określić typy magazynu oraz formaty i typy wirtualnego dysku używane dla każdego typu danych.
Zadanie 4. Definiowanie strategii dostępności maszyny wirtualnej
Administratorzy sieci szkieletowej są odpowiedzialni za zapewnienie dostępności sieci szkieletowej, a administratorzy maszyn wirtualnych są odpowiedzialni za dostępność ich maszyn wirtualnych. W związku z tym administrator maszyny wirtualnej musi rozumieć funkcje sieci szkieletowej, aby móc zaprojektować strategię dostępności odpowiednią dla jego maszyn wirtualnych.
W poniższej tabeli przeanalizowano trzy strategie dostępności dla maszyn wirtualnych działających z obciążeniami o cechach zdefiniowanych w sekcji Krok 1. Zadanie 2. powyżej. Zwykle administrator sieci szkieletowej informuje administratorów maszyn wirtualnych z wyprzedzeniem o planowanych działaniach wymagających przestoju sieci szkieletowej, aby administratorzy maszyn wirtualnych mogli się do tego przygotować. Istnieją trzy strategie dostępności:
Bezstanowa
Stanowa
Stanowa z udostępnianiem
Bezstanowa
Opcja |
Kwestie do rozważenia |
|---|---|
Migracja maszyny wirtualnej na żywo na poziomie hosta |
|
Klastry z równoważeniem obciążenia (z użyciem równoważenia obciążenia sieciowego systemu Windows) |
|
Klastry z równoważeniem obciążenia (z użyciem sprzętowego rozwiązania do równoważenia obciążenia) |
|
Stanowa
Opcja |
Kwestie do rozważenia |
|---|---|
|
Stanowa z udostępnianiem
Podczas uruchamiania obciążeń wykorzystujących możliwości klastra można zapewnić dodatkową warstwę dostępności przez włączenie usługi klastrowania gościa maszyny wirtualnej. Usługa klastrowania gościa obsługuje wysoką dostępność dla obciążeń na maszynie wirtualnej. Chroni ona obciążenia działające na maszynach wirtualnych nawet w przypadku awarii hosta, na którym działa maszyna wirtualna. Ponieważ obciążenie było chronione przez klaster trybu failover, maszyna wirtualna w innym węźle może automatycznie przejąć obsługę obciążenia.
Opcja |
Kwestie do rozważenia |
|---|---|
|
Informacje dodatkowe:
Wdrażanie klastra gościa przy użyciu udostępnionego wirtualnego dysku twardego
Używanie klastrowania gościa w celu zapewnienia wysokiej dostępności
Odzyskiwanie po awarii
W przypadku wystąpienia awarii — jak szybko możesz zapewnić, aby wymagane obciążenia stały się znowu dostępne dla klientów? W niektórych przypadkach limit czasu może wynosić tylko kilka minut.
Replikacja danych z głównego centrum danych do centrów odzyskiwania po awarii jest wymagana, aby zapewnić, że będą replikowane najbardziej aktualne dane (przy dopuszczalnej utracie danych z powodu opóźnienia). W przypadku uruchamiania obciążeń na maszynach wirtualnych można replikować wirtualne dyski twarde i pliki konfiguracyjne maszyn wirtualnych z lokacji podstawowej do lokacji repliki.
W poniższej tabeli porównano opcje odzyskiwania po awarii.
Opcja |
Kwestie do rozważenia |
|---|---|
Hyper-V Replica |
|
Kopia zapasowa |
|
Uwagi:
Aby centralnie zarządzać replikacją oraz automatyzować ją w programie System Center 2012 R2 — Virtual Machine Manager, należy użyć usługi Microsoft Azure Site Recovery.
Aby replikować maszyny wirtualne do platformy Azure przy użyciu usługi Microsoft Azure Site Recovery. Funkcja replikacji maszyny wirtualnej do platformy Azure jest obecnie w wersji Preview.
Informacje dodatkowe:
Usługa Microsoft Azure Site Recovery
Ważne:
Przejdź do strony Planowanie pojemności funkcji Hyper-V Replica, aby zrozumieć wpływ funkcji Hyper-V Replica na infrastrukturę sieci, użycie procesora na serwerze podstawowym, repliki i rozszerzonym serwerze repliki, użycie pamięci na serwerze podstawowym i repliki oraz operacje we/wy dysku na serwerze podstawowym, repliki i rozszerzonym serwerze repliki w kontekście istniejących maszyn wirtualnych.
Obciążenie może mieć wbudowane rozwiązanie do odtwarzania po awarii, na przykład Grupy dostępności AlwaysOn serwera SQL Server. Zapoznaj się z dokumentacją obciążenia, aby potwierdzić, że funkcja Hyper-V Replica jest obsługiwana przez obciążenie.
Informacje dodatkowe:
System Center Data Protection Manager
Zadanie 5. Definiowanie typów maszyny wirtualnej
Do obsługi obciążeń w danym środowisku można utworzyć maszyny wirtualne z unikatowymi wymaganiami zasobów w celu spełnienia określonych potrzeb obciążenia. Możesz też zastosować podejście podobne do stosowanego przez publicznych dostawców usług hostowania maszyn wirtualnych (inna nazwa tych usług to „infrastruktura jako usługa” — IaaS).
Zobacz temat Rozmiary maszyn wirtualnych i usług w chmurze na platformie Azure, aby uzyskać opis konfiguracji maszyn wirtualnych oferowanych przez usługi infrastruktury platformy Microsoft Azure. W momencie opracowywania tego tekstu usługi obsługują 13 konfiguracji maszyn wirtualnych, każda z różną kombinacją możliwości procesora, wielkości pamięci, pojemności magazynu i operacji we/wy.
Decyzja projektowa — decyzje podejmowane we wszystkich zadaniach tego kroku można wpisać w arkuszach Virtual machine configs. (Konfiguracje maszyn wirtualnych).
Krok 3. Planowanie grup hostów wirtualizacji serwera
Przed zdefiniowaniem poszczególnych serwerów hostów można najpierw zdefiniować grupy hostów. Grupy hostów to po prostu nazwane zbiory serwerów, które są zgrupowane w celu spełnienia wspólnych celów; opisano je w pozostałych zadaniach tego kroku.
Zadanie 1. Definiowanie lokalizacji fizycznych
Prawdopodobnie będziesz grupować zasoby sprzętowe i zarządzać nimi na podstawie fizycznej lokalizacji, więc najpierw należy zdefiniować lokalizacje zawierające zasoby sieci szkieletowej w ramach danej organizacji.
Zadanie 2. Definiowanie typów grup hostów
Grupy hostów można tworzyć z dowolnych przyczyn, na przykład przyczyną może być hostowanie obciążeń z określonymi:
Cechami obciążenia
Wymaganiami zasobów
Wymaganiami dotyczącymi jakości usługi
Na poniższym obrazie przedstawiono organizację, w której utworzono pięć grup hostów w dwóch lokalizacjach.
.jpeg "Grupa hostów")
Rysunek 2.Przykład grupy hostów
Grupy hostów zostały utworzone przez organizację z powodów opisanych w poniższej tabeli.
Grupa hostów |
Przyczyna jej utworzenia |
|---|---|
Obciążenia bezstanowe i stanowe |
|
Obciążenia stanowe i bezstanowe działu księgowości |
Mimo że konfiguracja sprzętu serwerów w tej grupie jest taka sama jak innych bezstanowych i stanowych grupach hostów obciążeń w środowisku, dział księgowości ma aplikacje, które mają wyższe wymagania dotyczące zabezpieczeń niż aplikacje innych działów w organizacji. W związku z tym została dla nich utworzona dedykowana grupa hostów, aby można było ją zabezpieczyć inaczej niż pozostałe grupy hostów w sieci szkieletowej. |
Obciążenia stanowe z udostępnianiem |
Obciążenia należące do tej grupy hostów wymagają magazynu udostępnionego, ponieważ korzystają z usług klastrowania z trybem failover w systemie Windows Server w celu zapewnienia ich dostępności. Te obciążenia są hostowane przez dedykowaną grupę hostów, ponieważ konfiguracja maszyn wirtualnych jest inna niż w przypadku pozostałych maszyn wirtualnych w organizacji. |
Obciążenia stanowe z dużą ilością operacji we/wy |
Wszystkie hosty w tej grupie są połączone z sieciami o wyższej szybkości niż hosty w innych grupach hostów. |
Organizacja może rozmieszczać elementy grupy hostów w różnych lokalizacjach, ale zdecydowano o umieszczeniu wszystkich elementów każdej grupy hostów w tej samej lokalizacji, aby ułatwić zarządzanie nimi. Jak widać w tym przykładzie, można tworzyć grupy hostów z różnych przyczyn — specyficznych dla każdej organizacji. Im więcej grup hostów utworzysz w organizacji, tym bardziej środowisko będzie złożone w kontekście zarządzania, co zwiększy koszty obsługi maszyn wirtualnych.
Porada: Im bardziej ustandaryzowany jest sprzęt serwerów znajdujący się w obrębie grupy hostów, tym łatwiej będzie skalować i utrzymywać grupę hostów. Jeśli chcesz ustandaryzować sprzęt w grupie hostów, możesz dodać dane konfiguracji standaryzowanej w arkuszu Host groups (Grupy hostów) w Arkuszach Przewodnika po zagadnieniach dotyczących projektu sieci szkieletowej wirtualizacji. Aby uzyskać więcej informacji na temat zagadnień związanych ze sprzętem fizycznym, zobacz Krok 4. Planowanie hostów wirtualizacji serwera.
Obecnie większość publicznych dostawców chmury hostujących maszyny wirtualne:
Hostuje tylko maszyny wirtualne, które nie wymagają udostępniania stanu.
Ma często tylko jeden zestaw miar jakości usług zapewnianych wszystkim klientom.
Nie rezerwuje specyficznego sprzętu dla specyficznych klientów.
Zalecamy rozpocząć od jednej grupy hostów zawierającej identyczny sprzęt, a potem tylko dodawać dodatkowe typy grup hostów — korzyści z takiego podejścia są większe niż koszty.
Zadanie 3. Określanie, czy należy klastrować elementy członkowskie grupy hostów
W przeszłości klastry trybu failover w systemie Windows Server były używane tylko w celu zwiększenia dostępności serwera, ale ich możliwości są teraz większe i zapewniają one znacznie więcej funkcji. Weź pod uwagę informacje zawarte w tabeli poniżej, aby określić, czy należy klastrować elementy grupy hostów.
Opcja |
Zalety |
Wady |
|---|---|---|
Elementy członkowskie grupy hostów są częścią klastra trybu failover |
|
|
Elementy członkowskie grupy hostów nie są częścią klastra trybu failover |
|
Maszyny wirtualne uruchomione na hoście, który uległ awarii, należy ręcznie (lub z użyciem automatyzacji) przenieść na innego sprawnego hosta i ponownie uruchomić. |
Decyzja projektowa — decyzje podejmowane we wszystkich zadaniach tego kroku można wpisać w arkuszu Settings (Ustawienia).
Krok 4. Planowanie hostów wirtualizacji serwera
W tym kroku będziesz definiować typy hostów potrzebne od obsługi maszyn wirtualnych, które planujesz uruchamiać w sieci szkieletowej wirtualizacji. Prawdopodobnie będziesz ograniczać liczbę konfiguracji hosta, w niektórych przypadkach do jednej konfiguracji, aby ułatwić proces zakupu i zmniejszyć koszty obsługi. Ponadto zakupu niewłaściwego sprzętu podniesie koszty wdrożenia.
Cloud Platform System
Doświadczenie firmy Microsoft w zakresie utrzymywania największych centrów danych i usług chmurowych zostało przeniesione na fabrycznie zintegrowany i w pełni sprawdzony system konwergentny. System Cloud Platform System (CPS) to połączenie sprawdzonego zestawu oprogramowania firmy Microsoft — Windows Server 2012 R2, System Center 2012 R2 i Windows Azure Pack — ze sprzętem serwera chmurowego, magazynu i sieci firmy Dell. System CPS jest skalowalnym blokiem chmury, który pozwala skrócić czas zwrotu z inwestycji i pozwala na zachowanie spójności chmury.
System CPS udostępnia samoobsługowe środowisko chmury dla wielu dzierżawców w modelu platformy jako usługi (PaaS) i maszyny wirtualne z systemami Windows i Linux oraz obejmuje zoptymalizowane pakiety wdrażania aplikacji firmy Microsoft, takich jak SQL Server, SharePoint i Exchange. Fabryczna integracja zmniejsza ryzyko i złożoność oraz skraca czas wdrażania z miesięcy do dni. Uproszczony proces obsługi i automatyzacja rutynowych zadań związanych z infrastrukturą zwalnia zasoby IT i pozwala skupić się na innowacjach.
Więcej informacji znajduje się w witrynie Cloud Platform System.
Fast Track
Zamiast projektować konfiguracje sprzętu (i oprogramowania), możesz kupić wstępnie skonfigurowane konfiguracje sprzętu od różnych partnerów sprzętowych w ramach programu Microsoft Private Cloud Fast Track.
Program Fast Track to wspólna inicjatywa firmy Microsoft i partnerów dostarczających sprzęt mająca na celu zaoferowanie wstępnie skonfigurowanych i sprawdzonych rozwiązań pozwalających ograniczyć złożoność i ryzyko związane z wprowadzeniem sieci szkieletowej wirtualizacji oraz narzędzi do zarządzania nią.
Program Fast Track zapewnia elastyczność rozwiązań i szeroki wybór technologii dostawcy sprzętu. Są w nim wykorzystywane podstawowe funkcje systemu operacyjnego Windows Server, technologii Hyper-V i programu Microsoft System Center w celu dostarczenia bloków konstrukcyjnych infrastruktury chmury prywatnej jako oferty usługi.
Informacje dodatkowe:
Witryna programu Microsoft Private Cloud Fast Track
Zadanie 1. Definiowanie konfiguracji obliczeniowej
W tym zadaniu określisz ilość pamięci, liczbę procesorów i wersje systemu Windows Server, które są wymagane dla każdego hosta. Liczba maszyn wirtualnych możliwa do uruchamiania na hoście będzie określana przez składniki sprzętowe omówione w tej sekcji.
Uwaga: Aby upewnić się, że rozwiązanie jest w pełni obsługiwane, wszystkie nabywane urządzenia muszą mieć logo Certified for Windows Server dla używanej wersji systemu Windows Server.
Obecność logo Certified for Windows Server oznacza, że system serwera spełnia najwyższe wymagania firmy Microsoft w zakresie zabezpieczeń, niezawodności i możliwości zarządzania. W połączeniu z innymi certyfikowanymi urządzeniami i sterownikami może obsługiwać role, funkcje i interfejsy dla obciążeń chmury i obciążeń klasy korporacyjnej oraz kluczowych aplikacji biznesowych.
Najbardziej aktualną listę sprzętu z logo Certified for Windows Server można znaleźć w witrynie wykazu systemu Windows Server.
Zadanie 1a. Definiowanie procesora
Funkcji Hyper-V prezentuje procesory logiczne każdej aktywnej maszynie wirtualnej jako procesory wirtualne. Można zapewnić wyższą wydajność w czasie wykonywania przez użycie procesorów, które obsługują technologie translacji adresów drugiego poziomu (SLAT), takie jak rozszerzone tabele stron (EPT) lub zagnieżdżone tabele stron (NPT). Funkcja Hyper-V w systemie Windows Server 2012 R2 obsługuje maksymalnie 320 procesorów logicznych.
Kwestie do rozważenia:
Obciążenia, które nie korzystają intensywnie z procesora, powinny zostać skonfigurowane z jednym procesorem wirtualnym. Monitoruj użycie procesora hosta wraz z upływem czasu, aby upewnić się, że przydzielone procesory zapewniają maksymalną efektywność.
Obciążenia, które korzystają intensywnie z procesora, powinny zostać skonfigurowane z dwoma procesorami wirtualnymi lub większą ich liczbą. Do maszyny wirtualnej można przypisać maksymalnie 64 procesory wirtualne. Liczba procesorów wirtualnych rozpoznawana przez maszynę wirtualną jest zależna od systemu operacyjnego gościa. Na przykład system Windows Server 2008 z dodatkiem Service Pack 2 rozpoznaje tylko cztery procesory wirtualne.
Informacje dodatkowe:
Dostosowywanie wydajności serwerów funkcji Hyper-V
Zadanie 1b. Definiowanie pamięci
Serwer fizyczny wymaga wystarczającej ilości pamięci do obsługi hosta i jego maszyn wirtualnych. Host wymaga pamięci, aby efektywnie obsługiwać operacje we/wy w imieniu maszyn wirtualnych i operacje, takie jak tworzenie punktu kontrolnego maszyny wirtualnej. Funkcja Hyper-V zapewnia, że dla hosta jest dostępna wystarczająca ilość pamięci, i udostępnia pozostałą pamięć do przypisania do maszyn wirtualnych. Rozmiary maszyn wirtualnych należy ustalać w oparciu o potrzeby oczekiwanego obciążenia dla każdej maszyny wirtualnej.
Funkcja hypervisor wirtualizuje pamięć fizyczną gościa, aby odizolować maszyny wirtualne od siebie i zapewnić ciągły obszar pamięci z adresami liczonymi od zera dla każdego systemu operacyjnego gościa — taki sam jak w systemach niezwirtualizowanych. Aby mieć pewność, że wydajność będzie maksymalna, należy użyć sprzętu z obsługą technologii SLAT — minimalizuje to koszt wydajności wirtualizacji pamięci.
Rozmiar pamięci maszyny wirtualnej należy ustalić tak, jak zwykle jest to ustalane dla aplikacji serwerowych na komputerze fizycznym. Ilość pamięci przypisana do maszyny wirtualnej powinna pozwalać maszynie wirtualnej obsługiwać oczekiwane obciążenie w zwykłych i szczytowych okresach, ponieważ zbyt mała ilość pamięci może znacznie zwiększyć czas reakcji i użycie procesora lub we/wy.
Pamięć, która została przydzielona dla maszyny wirtualnej, zmniejsza ilość pamięci, która jest dostępna dla innych maszyn wirtualnych. Jeśli na hoście jest za mało dostępnej pamięci, maszyna wirtualna nie zostanie uruchomiona.
Pamięć dynamiczna umożliwia osiągnięcie wyższego poziomu konsolidacji i zwiększonej niezawodności operacji ponownego uruchomienia. Może to prowadzić do obniżenia kosztów, zwłaszcza w środowiskach, które mają wiele bezczynnych maszyn wirtualnych lub maszyn o niskim obciążeniu, na przykład w środowiskach infrastruktury VDI z pulami. Zmiany konfiguracji pamięci dynamicznej w czasie wykonywania mogą zmniejszyć czasy przestoju i zapewnić wyższą elastyczność w kontekście reagowania na zmiany wymagań.
Aby uzyskać więcej informacji o pamięci dynamicznej, zobacz Zadanie 1b. Definiowanie pamięci. Omówiono w nim sposób określania ilości pamięci dla maszyny wirtualnej.
Informacje dodatkowe:
Omówienie wirtualnej architektury NUMA
Zadanie 1c. Definiowanie wersji systemu operacyjnego Windows Server
Funkcje dostępne w systemie Windows Server Standard i Windows Server Datacenter są dokładnie takie same. W systemie Windows Server Datacenter można tworzyć nieograniczoną liczbę maszyn wirtualnych. W systemie Windows Server Standard istnieje ograniczenie maksymalnie dwóch maszyn wirtualnych.
W systemie Windows Server 2012 R2 dodano funkcję automatycznej aktywacji maszyny wirtualnej (AVMA). Funkcja AVMA umożliwia zainstalowanie maszyn wirtualnych na poprawnie aktywowanym serwerze bez konieczności zarządzania kluczami produktów dla każdej maszyny wirtualnej, nawet w środowiskach bez połączenia z Internetem.
Funkcja AVMA wymaga, aby systemem operacyjnym gościa był Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Standard lub Windows Server 2012 R2 Essentials. W poniższej tabeli porównano wersje.
Wersja |
Zalety |
Wady |
|---|---|---|
Standard |
|
Ograniczenie do dwóch maszyn wirtualnych |
Datacenter |
|
Droższa |
Funkcja Hyper-V może zostać zainstalowana w instalacji Server Core systemu Windows Server. Instalacja Server Core zmniejsza wymagania w zakresie miejsca na dysku, liczbę potencjalnych możliwości ataku i — szczególnie — wymagania w zakresie obsługi. Instalacja Server Core jest zarządzana za pomocą wiersza polecenia, programu Windows PowerShell lub funkcje administracji zdalnej.
Ważne jest przejrzenie postanowień licencyjnych dotyczących oprogramowania, którego zamierzasz używać.
Microsoft Hyper-V Server
Serwer Microsoft Hyper-V Server to proste i niezawodne rozwiązanie do wirtualizacji pomagające organizacjom poprawić wykorzystanie serwerów i ograniczyć koszty. Jest to produkt autonomiczny zawierający tylko funkcję hypervisor systemu Windows, model sterowników systemu Windows Server i składniki wirtualizacji.
Serwer Hyper-V Server może być odpowiedni dla istniejącego środowiska informatycznego klienta i pozwolić wykorzystać istniejące metody obsługi administracyjnej, procesy zarządzania i narzędzia obsługi. Serwer obsługuje tę samą listę zgodności sprzętu co odpowiednia wersja systemu Windows Server, a także w pełni integruje się z programem Microsoft System Center i technologiami systemu Windows, takimi jak Windows Update, usługi Active Directory i klaster trybu failover.
Serwer Hyper-V Serwer jest dostępny do bezpłatnego pobrania i jego instalacja jest już aktywowana. Jednak każdy system operacyjny, który działa na hostowanej maszynie wirtualnej, wymaga odpowiedniej licencji.
Informacje dodatkowe:
Automatyczna aktywacja maszyny wirtualnej
Zdalne zarządzanie serwerem Hyper-V Server
Zadanie 2. Definiowanie konfiguracji sieci
W części Krok 2. Zadanie 2. powyżej omówiono uwagi dotyczące projektowania dotyczące sieci maszyny wirtualnej. Teraz omówimy uwagi dotyczące sieci dla hosta. Istnieje kilka typów ruchu sieciowego, który należy wziąć pod uwagę i zaplanować przy wdrażaniu funkcji Hyper-V. Należy projektować konfigurację sieci z myślą o:
Zapewnieniu jakości usługi (QoS) sieci
Zapewnieniu nadmiarowości sieci
Izolacji ruchu w zdefiniowanych sieciach
Zadanie 2a. Definiowanie typów ruchu sieciowego
W przypadku wdrażania klastra funkcji Hyper-V należy planować pod kątem kilku typów ruchu w sieci. Poniższa tabela zawiera podsumowanie typów ruchu.
Typ ruchu |
Opis |
|---|---|
Zarządzanie |
|
Klaster i woluminy CSV |
|
Migracja na żywo |
Używany na potrzeby funkcji migracji na żywo i migracji na żywo bez współdzielonych zasobów |
Magazyn |
Używany na potrzeby ruchu protokołów SMB lub iSCSI |
Replika |
Używany na potrzeby ruchu związanego z replikacją maszyn wirtualnych za pomocą funkcji Hyper-V Replica |
Ruch maszyny wirtualnej (dzierżawcy) |
Uwaga: Zobacz Krok 2. Planowanie konfiguracji maszyny wirtualnej, aby uzyskać listę typów ruchu maszyny wirtualnej. |
Kopia zapasowa |
Używany do wykonania kopii zapasowej plików wirtualnego dysku twardego |
Zadanie 2b. Definiowanie opcji wydajności ruchu sieciowego
Każdy typ ruchu sieciowego ma wymagania minimalnego opóźnienia i minimalnej i maksymalnej przepustowości. Poniżej przedstawiono strategie, których można użyć, aby spełnić różne wymagania dotyczące wydajności sieci.
Jakość usługi oparta na zasadach
W przypadku wdrażania klastra funkcji Hyper-V potrzebnych jest minimum sześć wzorców ruchu lub sieci. Każda sieć wymaga nadmiarowości. Mówimy więc o 12 kartach sieciowych na hoście. Można zainstalować wiele czteroportowych kart sieciowych, ale w pewnym momencie skończą się gniazda na hoście.
Urządzenie sieciowe są coraz szybsze. Nie tak dawno temu jednogigabitowe karty sieciowe były szczytem wydajności. Karty 10 Gb/s w serwerach z stają się coraz bardziej popularne, ceny sprzętu do obsługi infrastruktury 10 Gb/s stają się coraz bardziej przystępne.
Zainstalowanie dwóch kart sieciowych 10 Gb/s w zespole zapewnia większą przepustowość niż zainstalowanie dwóch czteroportowych kart 1 Gb/s, wymaga mniejszej liczby portów przełącznika i upraszcza okablowanie. W miarę łączenia typów ruchu sieci na kartach sieciowych 10 Gb/s w zespole jakość usługi oparta na zasadach będzie umożliwiała zarządzanie ruchem sieciowym w celu spełnienia potrzeb infrastruktury wirtualizacji.
Jakość usługi oparta na zasadach umożliwia określenie kontroli przepustowości sieci na podstawie typu aplikacji, użytkowników i komputerów. Zasady jakości usługi pozwalają spełnić wymagania usługi obciążenia lub aplikacji przez dokonywanie pomiarów przepustowości sieci, wykrywanie zmieniających się warunków sieciowych (takich jak przeciążenie lub dostępność przepustowości) i priorytetyzowanie ruchu sieciowego lub ograniczanie go.
Oprócz możliwości wymuszania maksymalnej przepustowości zasady jakości usługi w systemie Windows Server 2012 R2 zapewniają nową funkcję zarządzania przepustowością: przepustowość minimalna. W odróżnieniu od przepustowości maksymalnej, która jest limitem przepustowości, funkcja przepustowości minimalnej określa najmniejsza dostępną wartość przepustowości i przypisuje taką przepustowość do danego typu ruchu. Limity przepustowości minimalnej i maksymalnej można zaimplementować jednocześnie.
Zalety |
Wady |
|---|---|
|
|
Informacje dodatkowe:
Omówienie jakości usługi (QoS)
Jakość usługi oparta na zasadach
Mostkowanie centrum danych
Funkcja Mostkowanie centrum danych (DCB) zapewnia sprzętowe możliwości przydziału przepustowości dla określonego typu ruchu i zwiększa niezawodność transportu w sieci Ethernet dzięki sterowaniu przepływem na podstawie priorytetu. Użycie funkcji DCB jest zalecane w przypadku korzystania z protokołów FCoE i iSCSI.
Zalety |
Wady |
|---|---|
|
|
Informacje dodatkowe:
Mostkowanie centrum danych (DCB) — omówienie
SMB Direct
Funkcja SMB Direct (protokół SMB przez zdalny dostęp do pamięci — RDMA) to protokół magazynu w systemie Windows Server 2012 R2. Umożliwia bezpośrednie przesyłanie danych z pamięci do pamięci między serwerem a magazynem. Wymaga minimalnego użycia procesora CPU i używa standardowych kart sieciowych z obsługą dostępu RDMA. Zapewnia to bardzo krótkie czasy odpowiedzi na żądania sieci, co w związku z tym oznacza, że czasy odpowiedzi dla zdalnego magazynu plików są porównywalne z czasem odpowiedzi magazynu blokowego podłączonego bezpośrednio.
Zalety |
Wady |
|---|---|
|
|
Łączenie odbieranych segmentów (RSC)
Funkcja Łączenie odbieranych segmentów (RSC) ogranicza wykorzystanie procesora związane z przetwarzaniem ruchu przychodzącego przez odciążenie zadań procesora na kartę sieciową z obsługą funkcji RSC.
Zalety |
Wady |
|---|---|
|
|
Skalowanie po stronie odbierania (RSS)
Funkcja Skalowanie po stronie odbierania (RSS) pozwala kartom sieciowym rozpraszać obciążenie przetwarzania ruchu sieciowego trybu jądra na wiele rdzeni procesora w komputerach z procesorami wielordzeniowymi. Rozproszenie tego przetwarzania umożliwia obsługę wyższych obciążeń ruchu w sieci, co nie byłoby możliwe w przypadku użycia pojedynczego rdzenia. Funkcja RSS pozwala uzyskać to przyspieszenie dzięki rozproszeniu obciążenia przetwarzania ruchu sieciowego na wiele procesorów i aktywnemu równoważeniu obciążenia związanego z ruchem, którego przetwarzanie zostaje zakończone na poziomie protokołu Transmission Control Protocol (TCP).
Zalety |
Wady |
|---|---|
|
|
Wirtualizacja SR-IOV
Funkcja Hyper-V obsługuje urządzenia sieciowe z obsługą wirtualizacji SR-IOV i pozwala bezpośrednio przypisywać funkcje wirtualne SR-IOV fizycznych kart sieciowych do maszyny wirtualnej. Zwiększa to przepływność sieci, zmniejsza opóźnienie sieci i zmniejsza narzut użycia procesora hosta wymagany do przetwarzania ruchu sieciowego.
Aby uzyskać więcej informacji na temat wirtualizacji SR-IOV, zobacz Zadanie 2b. Definiowanie opcji wydajności ruchu sieciowego powyżej.
Zadanie 2c. Definiowanie strategii wysokiej dostępności i przepustowości ruchu w sieci
Funkcja tworzenia zespołu kart sieciowych, nazywana również równoważeniem obciążenia i trybem failover (LBFO), pozwala na umieszczenie w zespole wielu kart sieciowych na potrzeby trybu failover i agregacji ruchu. Pomaga to zapewnić dostępność połączenia w przypadku awarii składnika sieci.
Ta funkcja jest udostępniana przez dostawców kart sieciowych. Funkcja tworzenia zespołu kart sieciowych wprowadzona w systemie Windows Server 2012 jest uwzględniona jako funkcja w systemie operacyjnym Windows Server.
Funkcja tworzenia zespołu kart sieciowych jest zgodna z wszystkimi możliwościami sieciowymi w systemie Windows Server 2012 R2 z trzema wyjątkami:
Wirtualizacja SR-IOV
Dostęp RDMA
Uwierzytelnianie 802.1X
Z punktu widzenia skalowalności w systemie Windows Server 2012 R2 do jednego zespołu można dodać co najmniej jedną i maksymalnie trzydzieści dwie karty sieciowe. Na jednym hoście można utworzyć nieograniczoną liczbę zespołów.
Informacje dodatkowe:
Omówienie zespołów kart sieciowych
Wirtualna akademia firmy Microsoft: Tworzenie zespołu kart sieciowych w systemie Windows Server 2012
Polecenia cmdlet tworzenia zespołu kart sieciowych (NetLBFO) w programie Windows PowerShell
Konwergentne centrum danych z magazynem na serwerze plików
Zadanie 2d. Definiowanie strategii izolacji i zabezpieczeń ruchu sieciowego
Każdy typ ruchu sieciowego może mieć różne wymagania zabezpieczeń w zakresie funkcji, takich jak izolacja i szyfrowanie. W poniższej tabeli opisano strategie, których można użyć na potrzeby spełnienia różnych wymagań zabezpieczeń.
Strategia |
Zalety |
Wady |
|---|---|---|
Szyfrowanie (IPsec) |
Ruch jest zabezpieczony podczas transmisji przewodowej |
|
Oddzielne sieci fizyczne |
Sieci są fizycznie oddzielone |
|
Wirtualna sieć lokalna (VLAN) |
|
|
Zadanie 2e. Definiowanie wirtualnych kart sieciowych
Po zrozumieniu typów ruchu wymaganych przez hosty serwerów wirtualizacji i strategii wydajności, dostępności i zabezpieczeń dla ruchu sieciowego można określić, ile fizycznych kart sieciowych jest wymaganych dla każdego hosta i typu ruchu sieciowego transmitowanego za pośrednictwem każdej karty.
Zadanie 2f. Definiowanie przełączników wirtualnych
Aby połączyć maszynę wirtualną z siecią, karta sieciowa musi być podłączona do przełącznika wirtualnego funkcji Hyper-V.
Istnieją trzy typy przełączników wirtualnych, które mogą zostać utworzone w funkcji Hyper-V:
Zewnętrzny przełącznik wirtualny
Użyj zewnętrznego przełącznika wirtualnego, jeśli chcesz zapewnić maszynom wirtualnym dostęp do sieci fizycznej w celu komunikowania się ze zlokalizowanymi na zewnątrz serwerami i klientami. Ten typ przełącznika wirtualnego umożliwia także maszynom wirtualnym na tym samym hoście komunikowanie się ze sobą. Sieć tego typu może być także dostępna do użycia przez system operacyjny hosta w zależności od tego, w jaki sposób zostanie ona skonfigurowana.
Ważne: Fizyczna karta sieciowa w danym momencie może być powiązana tylko z jednym przełącznikiem wirtualnym.
Wewnętrzny przełącznik wirtualny
Użyj wewnętrznego przełącznika wirtualnego, jeśli chcesz umożliwić komunikację między maszynami wirtualnymi na tym samym hoście i między maszynami wirtualnymi i systemem operacyjnym hosta. Ten typ przełącznika wirtualnego jest najczęściej używany do tworzenia środowiska testowego, w którym potrzebna jest możliwość nawiązywania połączeń z maszynami wirtualnymi z poziomu systemu operacyjnego hosta. Wewnętrzny przełącznik wirtualny nie jest powiązany z fizyczną kartą sieciową. W związku z tym wewnętrzna sieć wirtualna jest odizolowana od zewnętrznego ruchu sieciowego.
Prywatny przełącznik wirtualny
Użyj prywatnego przełącznika wirtualnego, jeśli chcesz umożliwić komunikację tylko między maszynami wirtualnymi na tym samym hoście. Prywatny przełącznik wirtualny nie jest powiązany z fizyczną kartą sieciową. Prywatny przełącznik wirtualny jest odizolowany od całego zewnętrznego ruchu sieciowego na serwerze wirtualizacji i całego ruchu sieciowego systemu operacyjnego hosta i sieci zewnętrznej. Sieć tego typu jest przydatna, gdy chcesz utworzyć izolowane środowisko sieciowe, takie jak izolowana domena testowa.
Uwaga: Prywatne i wewnętrzne przełączniki wirtualne nie korzystają z funkcji przyspieszenia sprzętowego, które są dostępne dla maszyny wirtualnej podłączonej do zewnętrznego przełącznika wirtualnego
Decyzja projektowa — decyzje podejmowane we wszystkich zadaniach tego kroku można wpisać w arkuszach Virtualization hosts (Hosty wirtualizacji).
Porada: Nazwy przełączników wirtualnych na różnych hostach, które są połączone z tą samą siecią, powinny być takie same. Eliminuje to problemy interpretacyjne związane z określaniem, z którym przełącznikiem wirtualnym powinna być połączona maszyna wirtualna, i upraszcza przenoszenie maszyny wirtualnej z jednego hosta na inny. Polecenie cmdlet Move-VM programu Windows PowerShell zakończy się niepowodzeniem, jeśli nie zostanie znaleziona taka sama nazwa przełącznika wirtualnego na hoście docelowym.
Zadanie 3. Definiowanie konfiguracji magazynu
Oprócz magazynu wymaganego przez system operacyjny hosta każdy host wymaga dostępu do magazynu, w którym są przechowywane pliki konfiguracji maszyny wirtualnej i wirtualne dyski twarde. W tym zadaniu skupiono się na magazynie maszyny wirtualnej.
Zadanie 3a. Definiowanie typów danych
Poniżej przedstawiono przykładowe typy danych, które należy wziąć pod uwagę w kontekście wymagań dotyczących magazynu.
Typ danych |
Lokalizacja magazynu dla typu danych |
|---|---|
Pliki systemu operacyjnego hosta |
Zwykle na lokalnym dysku twardym |
Plik stronicowania i pliki zrzutu awaryjnego systemu Windows hosta |
Zwykle na lokalnym dysku twardym |
Udostępniony stan klastra trybu failover |
Magazyn udostępniony sieci lub udostępniony wolumin klastra |
Pliki wirtualnego dysku twardego i plik konfiguracji maszyny wirtualnej |
Zwykle w magazynie udostępnionym sieci lub na udostępnionym woluminie klastra |
Pozostała część tego kroku dotyczy magazynu wymaganego dla maszyn wirtualnych.
Zadanie 3b. Opcje magazynu
Na potrzeby przechowywania plików konfiguracyjnych maszyn wirtualnych i wirtualnych dysków twardych są dostępne następujące opcje.
Opcja 1: Magazyn dołączany bezpośrednio
Magazyn dołączany bezpośrednio to magazyn komputera podłączony bezpośrednio do serwera, a nie podłączony bezpośrednio do sieci. Magazyn dołączany bezpośrednio to nie tylko wewnętrzny magazyn. Może to również być zewnętrzna obudowa zawierająca dyski twarde, na przykład obudowa z dyskami JBOD i obudowa połączona za pośrednictwem kontrolera SAS lub innego kontrolera dysku.
Zalety |
Wady |
|---|---|
|
|
Opcja 2: Magazyn dołączony do sieci
Urządzenia magazynu dołączone do sieci łączą magazyn z siecią, w której magazyn jest dostępny w postaci udziałów plików magazynu. W odróżnieniu od magazynu podłączonego bezpośrednio nie są bezpośrednio dołączone do komputera.
Urządzenia magazynu dołączone do sieci obsługują połączenia sieci Ethernet i zwykle pozwalają administratorowi zarządzać miejscem na dysku, ustawiać przydziały dysków, zapewniać bezpieczeństwo i używać technologii punktu kontrolnego. Urządzenia magazynu dołączone do sieci obsługują wiele protokołów. Należą do nich systemy plików dołączone do sieci, system plików CIFS (Common Internet File Systems) i protokół SMB (Server Message Block).
Zalety |
Wady |
|---|---|
|
|
Opcja 3: Sieć magazynowania (SAN)
Sieci magazynowania to dedykowana sieć, która pozwala na współużytkowanie magazynu. Sieć SAN składa się z urządzenia pamięci masowej, infrastruktury sieci zapewniającej łączność (przełączniki, kartu magistrali hosta i okablowanie) i serwerów, które są połączone z tą siecią. Urządzenia sieci SAN zapewnienia ciągły i szybki dostęp do dużych ilości danych. Mechanizm komunikacji i transferu danych dla danego wdrożenia zwykle jest nazywany siecią szkieletową magazynu.
Sieć SAN używa oddzielnej sieci i zwykle nie jest dostępna dla innych urządzeń za pośrednictwem sieci lokalnej. Siecią SAN można zarządzać za pomocą protokołu SMI-S (Storage Management Initiative Specification), protokołu Simple Network Management Protocol (SNMP) lub własnego protokołu zarządzania dostawcy.
Sieci SAN nie zapewniają funkcji abstrakcji pliku, a jedynie obsługują operacje na poziomie bloków. Najbardziej popularne protokoły sieci SAN to iSCSI, Fiber Channel i Fiber Channel przez Ethernet (FCoE). Protokół SMI-S lub własny protokół zarządzania dostawcy może zapewniać dodatkowe możliwości, takie jak podział dysku na strefy, mapowanie dysku, maskowanie numerów LUN i zarządzania błędami.
Zalety |
Wady |
|---|---|
|
|
Opcja 4: Udziały plików protokołu SMB 3.0
Funkcja Hyper-V może przechowywać pliki maszyny wirtualnej, takie jak pliki konfiguracyjne, pliki wirtualnego dysku twardego i punkty kontrolne, w udziałach plików, które używają protokołu SMB 3.0. Zwykle udziały plików znajdują się serwerze plików skalowalnym w poziomie, aby zapewnić nadmiarowość. W przypadku używania serwera plików skalowalnego w poziomie, jeśli jeden węzeł nie działa, udziały plików są nadal dostępne z poziomu innych węzłów takiego serwera.
Zalety |
Wady |
|---|---|
|
|
SMB Direct
Funkcja SMB Direct działa jako część udziałów plików SMB. Funkcja SMB Direct wymaga kart sieciowych i przełączników, które obsługują funkcję RDMA, aby zapewnić pełną szybkość dostępu do magazynu i krótki czas oczekiwania. Użycie funkcji SMB Direct sprawia, że zdalne serwery plików przypominają lokalny lub podłączony bezpośrednio magazyn. Oprócz korzyści z zastosowania protokołu SMB funkcja SMB Direct ma następujące zalety i wady.
Zalety |
Wady |
|---|---|
|
|
.jpeg "Serwer plików skalowany w poziomie")
Rysunek 3.Przykładowy serwer plików skalowalny w poziomie wykorzystujący konwergentną sieć i funkcję RDMA
Informacje dodatkowe:
Konwergentne centrum danych z magazynem na serwerze plików
Wdrożenie funkcji Hyper-V z użyciem protokołu SMB
Zadanie 3c. Definiowanie typów architektury dysku fizycznego
Typ architektury dysku fizycznego, który zostanie wybrany do obsługi magazynu, ma wpływ na wydajność rozwiązania magazynu. Aby uzyskać więcej informacji o typach dysków, zapoznaj się z sekcją 7.1 opracowania Architektura linii produktów rozwiązania IaaS.
Zadanie 3d. Definiowanie typu sieci magazynu
Używane typy kontrolera magazynu lub kontrolera sieci magazynu zależą od opcji magazynowania wybranej dla każdej grupy hostów. Aby uzyskać więcej informacji, zobacz Zadanie 3b. Opcje magazynu.
Zadanie 3e. Określenie typu magazynu do użycia w przypadku każdego typu danych
Po określeniu typów danych można teraz określić najlepsze opcje magazynu, kontrolera pamięci masowej, kontrolera sieci magazynu i architektury dysku fizycznego zgodnie z wymaganiami.
Decyzja projektowa — decyzje podejmowane w tym zadaniu można wpisać w arkuszu Virtualization hosts (Hosty wirtualizacji).
Informacje dodatkowe:
Omówienie technologii magazynowania
Zadanie 4. Definiowanie jednostek skalowania hosta wirtualizacji serwera
Zakup pojedynczych serwerów wymaga nabycia, instalacji i konfiguracji każdego serwera. Jednostki skalowania umożliwiają zakup kolekcji serwerów (zazwyczaj zawierającej identyczny sprzęt). Są one wstępnie skonfigurowane, co umożliwia zwiększenie wydajności centrum danych przez dodanie jednostek skalowania, a nie przez dodanie poszczególnych serwerów.
Na poniższym obrazie przedstawiono wstępnie skonfigurowaną jednostkę skalowania, która mogła zostać zakupiona od dowolnego dostawcy sprzętu. Zawiera ona stojak, zasilacz awaryjny (UPS), parę nadmiarowych przełączników sieciowych dla serwerów w stojaku i dziesięć serwerów.
.jpeg "Jednostka skali hosta")
Rysunek 4.Przykład jednostki skalowania hosta wirtualizacji serwera
Jednostka skalowania jest wstępnie skonfigurowana i wstępnie okablowana między zasilaczem UPS i przełącznikami sieciowymi. Wystarczy ją dodać do centrum danych, podłączyć do zasilania i połączyć z siecią i magazynem. Będzie wówczas gotowa do użycia. Jeśli pojedynczych składników nie zakupiono w postaci jednostki skalowania, nabywca musi zainstalować w stojaku i okablować wszystkie składniki.
Decyzja projektowa — w przypadku decyzji o użyciu jednostek skalowania hosta wirtualizacji serwera sprzęt dla takich jednostek można zdefiniować w arkuszu Host scale units (Jednostki skalowania hosta).
Porada: Wstępnie skonfigurowane jednostki skalowania można nabyć od wielu partnerów sprzętowych firmy Microsoft w ramach programu Microsoft Private Cloud Fast Track.
Zadanie 5. Definiowanie strategii dostępności hosta wirtualizacji serwera
Hosty serwerów wirtualizacji mogą stać się niedostępne z planowanych przyczyn (na przykład konserwacji) lub niezaplanowanych przyczyn. Oto kilka strategii, które mogą być używane w obu przypadkach.
Planowane
Można użyć funkcji Migracja na żywo, która umożliwia przenoszenie maszyn wirtualnych z jednego hosta na inny. Nie wymaga przestojów maszyn wirtualnych.
Nieplanowane
Ten scenariusz zależy od typów obciążeń, które działają na hoście.
W przypadku obciążeń stanowych z udostępnianiem użyj klastra trybu failover działającego na maszynach wirtualnych.
W przypadku obciążeń stanowych uruchom maszynę wirtualną jako maszynę wysokiej dostępności w klastrze funkcji Hyper-V.
W przypadku obciążeń bezstanowych uruchom nowe wystąpienia ręcznie lub z użyciem zautomatyzowanych metod.
W przypadku korzystania z klastra trybu failover w systemie Windows Server z funkcją Hyper-V należy rozważyć, czy mają być używane funkcje wymienione w poniższej tabeli. Aby uzyskać dodatkowe informacje dotyczące każdej funkcji, kliknij hiperlink.
Funkcja |
Kwestie do rozważenia |
|---|---|
Umożliwia monitorowanie maszyny wirtualnej pod kątem błędów sieci i magazynu, które nie są monitorowane przez usługę klastra trybu failover. |
|
|
|
Antykoligacja przed maszyny wirtualnej |
Ustaw antykoligację dla maszyn wirtualnych, których nie chcesz uruchamiać w tym samym węźle klastra funkcji Hyper-V. Może to być potrzebne w przypadku maszyn wirtualnych, które zapewniają nadmiarowe usługi lub są częścią klastra maszyny wirtualnej gościa. Uwaga: Ustawienia antykoligacji są konfigurowane przy użyciu programu Windows PowerShell. |
|
|
|
|
Kolejnym powodem, dla którego można ustawić priorytet maszyny wirtualnej, jest to, że usługa klastrowania może wyłączyć maszynę wirtualną o niższym priorytecie, gdy maszyna wirtualna o wyższym priorytecie nie ma potrzebnej pamięci i innych zasobów, aby mogła zostać uruchomiona.
|
Uwaga: Klaster funkcji Hyper-V może zawierać maksymalnie 64 węzłów i 8000 maszyn wirtualnych.
Krok 5. Pojęcia związane z planowaniem architektury sieci szkieletowej wirtualizacji
Ten krok wymaga zdefiniowania logicznych pojęć, które określą architekturę sieci szkieletowej.
Zadanie 1. Definiowanie domen konserwacji
Domeny konserwacji są logicznymi zbiorami serwerów, które są obsługiwane razem. Obsługa techniczna może obejmować uaktualnienia sprzętu i oprogramowania lub zmiany konfiguracji. Domeny konserwacji zwykle obejmują grupy hostów danego typu lub w danej lokalizacji, chociaż takie grupowanie nie jest obowiązkowe. Celem ich stosowania jest uniknięcie niekorzystnego wpływu na obciążenia klientów w czasie przeprowadzania konserwacji na serwerze.
Uwaga: To pojęcie ma zastosowanie do składników sieci fizycznej i magazynu.
Zadanie 2. Definiowanie fizycznych domen awarii
Grupy hostów serwera wirtualizacji często razem ulegają awarii w wyniku awarii składnika udostępnionej infrastruktury, takiego jak przełącznik sieci lub zasilacz awaryjny (UPS). Fizyczne domeny awarii mogą pomóc zapewnić niezawodność w sieci szkieletowej wirtualizacji. Należy określić, jak domena awarii wpływa na każdą grupę hostów, która została zdefiniowana w sieci szkieletowej.
Uwaga: To pojęcie ma zastosowanie do składników sieci fizycznej i magazynu.
Rozważ przykład pokazany na poniższej ilustracji, na której nałożono domeny konserwacji i fizyczne domeny awarii na zbiór grup hostów w centrum danych.
.jpeg "Domena awarii")
Rysunek 5.Przykład definicji domeny konserwacji i fizycznej domeny awarii
W tym przykładzie każdy stojak serwerów jest zdefiniowany jako oddzielna, numerowana fizyczna domena awarii. Jest tak dlatego, że każdy stojak zawiera przełącznik sieci (u góry) i UPS (u dołu). Wszystkie serwery w stojaku wykorzystują te dwa składniki, a jeśli jeden z tych składników ulegnie awarii, wszystkie serwery w stojaku również ulegną awarii.
Ponieważ wszystkie serwery w stojaku są również elementami członkowskimi unikatowych grup hostów, w takim projekcie nie istnieje żaden sposób zapobiegania awarii którejkolwiek fizycznej domeny awarii. Aby zapobiec problemom, można dodać fizyczne domeny awarii każdego typu grupy hostów. W środowiskach o mniejszej skali można ewentualnie dodać nadmiarowy przełącznik i zasilacze w każdym stojaku lub użyć klastra trybu failover dla hostów serwerów wirtualizacji w fizycznych domenach awarii.
Na Rysunku 5 poszczególne kolorowe pola oznaczone kreskowaną linią definiują domeny konserwacji (oznaczone od MD 1 do MD 5). Należy zwrócić uwagę, jak każdy serwer w klastrze równoważenia obciążenia maszyn wirtualnych jest hostowany przy użyciu serwera hosta wirtualizacji, który znajduje się w oddzielnej domenie konserwacji i oddzielnej fizycznej domenie awarii.
Dzięki temu administrator sieci szkieletowej może wyłączyć wszystkie hosty serwera wirtualizacji w domenie konserwacji bez wywierania znacznego wpływu na aplikacje, które działają na wielu serwerach w różnych domenach konserwacji. Oznacza to również, że aplikacje uruchomione w klastrze równoważenia obciążenia nie staną się całkowicie niedostępne w przypadku awarii fizycznej domeny awarii.
Decyzja projektowa — decyzje podejmowane w zadaniach 1 i 2 tego kroku można wpisać w arkuszu Settings (Ustawienia).
Zadanie 3. Definiowanie pojemności rezerwowej
Awarie poszczególnych serwerów w sieci szkieletowej są nieuniknione. Projekt sieci szkieletowej musi obsłużyć awarie poszczególnych serwerów, tak samo jak obsługuje awarie kolekcji serwerów w domenach awarii i konserwacji. Poniższa ilustracja jest taka sama jak Rysunek 5, ale na czerwono zaznaczono trzy serwery, które uległy awarii.
.jpeg "Serwery po awarii")
Rysunek 6.Serwery po awarii
Na Rysunku 6 hosty wirtualizacji serwera uległy awarii w następujących grupach hostów, domenach konserwacji i fizycznych domenach awarii.
Grupa hostów |
Fizyczna domena awarii |
Domena konserwacji |
|---|---|---|
2 |
2 |
3 |
3 |
3 |
2 |
4 |
4 |
2 |
Aplikacja działająca w klastrze równoważenia obciążenia jest nadal dostępna, mimo że host w fizycznej domenie awarii 2 uległ awarii, jednak aplikacja będzie miała dostępną o jedna trzecią mniejszą pojemność.
Rozważ, co się stanie, jeśli host wirtualizacji serwera hostujący maszyny wirtualne w fizycznej domenie awarii 3 ulegnie awarii lub domena konserwacji 2 zostanie przełączona w tryb konserwacji. W takich sytuacjach pojemność dostępna dla aplikacji zmniejszy się o 2/3.
W określonych przypadkach może to być niedopuszczalne w sieci szkieletowej wirtualizacji. Aby zmniejszyć wpływ awarii na serwery, należy zapewnić, że każda fizyczna domena awarii oraz domena konserwacji będzie miała wystarczającą pojemność rezerwową, tak aby pojemność nigdy nie spadła poniżej zdefiniowanego dopuszczalnego poziomu.
Aby uzyskać więcej informacji, zobacz sekcję Pojemność rezerwowa w temacie Architektura referencyjna struktury usług w chmurze — zasady, pojęcia i wzorce.
Krok 6. Planowanie cech początkowych możliwości
Po ukończeniu wszystkich zadań w tym dokumencie można określić wstępne koszty hostowania maszyn wirtualnych i magazynu w sieci szkieletowej oraz początkowe poziomy jakości usług, które zapewnia sieć szkieletowa. Nie będzie można ukończyć żadnego z tych zadań do czasu wdrożenia narzędzi i personelu do zarządzania siecią szkieletową, co omówiono w sekcji Kolejne kroki tego dokumentu.
Zadanie 1. Definiowanie początkowych metryk umowy dotyczącej poziomu usług (SLA) dla magazynu i maszyn wirtualnych
Jako administrator sieci szkieletowej prawdopodobnie zdefiniujesz umowę dotyczącą poziomu usług (SLA) wyszczególniającą metryki jakości usług, które ma spełniać sieć szkieletowa. Administratorzy maszyn wirtualnych muszą znać te metryki, aby zaplanować, jak będzie przez nich używana sieć szkieletowa.
W minimalnej wersji należy uwzględnić metrykę dostępności, ale mogą zostać również uwzględnione inne metryki. Aby zobaczyć, jak wyglądają podstawowe metryki umowy dotyczącej poziomu usług sieci szkieletowej wirtualizacji, można przejrzeć metryki oferowane przez dostawców chmury publicznej, takich jak Microsoft Azure. W przypadku hostingu maszyn wirtualnych umowa dotycząca poziomu usług gwarantuje, że gdy klient wdroży co najmniej dwa wystąpienia tego samego obciążenia na maszynach wirtualnych — i wdroży je w różnych domenach awarii i uaktualniania (w tym dokumencie te ostatnie są nazywane „domenami konserwacji”) — co najmniej jedna z tych maszyn wirtualnych będzie dostępna przez 99,95% czasu.
Aby zapoznać się z pełną wersją umowy SLA platformy Azure, zobacz Umowy dotyczące poziomu usług. W optymalnym scenariuszu sieć szkieletowa wirtualizacji powinna zapewniać takie same lub wyższe poziomy jak te oferowane przez dostawców w chmurze publicznej.
Zadanie 2. Definiowanie wstępnych kosztów hostingu magazynu i maszyn wirtualnych
Po zaprojektowaniu sieci szkieletowej można również obliczyć:
Koszty sprzętu, miejsca, zasilania i chłodzenia związane z siecią szkieletową
Pojemność hostingu sieci szkieletowej
Te informacje w połączeniu z informacjami o innych kosztach, takich jak koszt narzędzi i personelu do zarządzania siecią szkieletową, umożliwią określenie końcowego kosztu hostingu maszyn wirtualnych i magazynu.
Aby zobaczyć, jak wygląda podstawowe oszacowanie kosztów maszyn wirtualnych i magazynu, można przejrzeć koszty hostingu dostawców chmury publicznej, takich jak Microsoft Azure. Aby uzyskać więcej informacji, zobacz Szczegóły cenników maszyn wirtualnych.
Chociaż nie zawsze musi to być prawdą, w większości przypadków okaże się, że koszty hostingu są wyższe niż w przypadku publicznych dostawców, ponieważ sieć szkieletowa będzie znacznie mniejsza niż sieci szkieletowe dużych dostawców publicznych, którzy są w stanie uzyskać rabaty hurtowe na zakup sprzętu, miejsca w centrum danych i zasilania.
Następne kroki
Po ukończeniu wszystkich zadań w tym dokumencie opracujesz projekt sieci szkieletowej, który spełnia wymagania w organizacji. Opracujesz również początkową definicję cech usług obejmującą koszty i metryki poziomu usług. Nie będzie można określić ostatecznych kosztów i metryk poziomu usług do czasu ustalenia kosztów personelu oraz narzędzi i procesów zarządzania w sieci szkieletowej.
Program Microsoft System Center 2012 zapewnia rozbudowany zestaw funkcji umożliwiających obsługę administracyjną, monitorowanie i konserwację sieci szkieletowej wirtualizacji. Więcej informacji na temat użycia programu System Center do zarządzania zasobami sieci szkieletowej zawierają następujące zasoby: