Microsoft AZ-801: Hyper-V, wirtualizacja i pamięć masowa — Przewodnik do nauki
Część Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.
Przegląd
Hyper‑V i zdefiniowane programowo magazyny w Windows Server tworzą spójną platformę dla bezpiecznych, izolowanych i wysoko dostępnych obciążeń. Opanowanie materiału wymaga zrozumienia, jak chronione sieci szkieletowe (guarded fabrics) zabezpieczają maszyny wirtualne dzierżawców przed administratorami sieci szkieletowej, jak Virtualization‑Based Security (VBS) wzmacnia system operacyjny poprzez izolację zakorzenioną w sprzęcie, jak sieć Hyper‑V wymusza izolację oraz jak replikacja, punkty kontrolne i klastrowanie zachowują się pod obciążeniem i w przypadku awarii. Ta sekcja wyjaśnia model bezpieczeństwa dla maszyn wirtualnych chronionych (shielded VMs) i wzmacniania zabezpieczeń hosta, zagłębia się w konstrukcje izolacji sieciowej, omawia trwałość danych dzięki Hyper‑V Replica i mechanizmom punktów kontrolnych, a kończy na Storage Spaces Direct (S2D), woluminach udostępnionych klastra (Cluster Shared Volumes, CSV) i projektowaniu kworum w klastrach trybu failover (Failover Clustering).
Bezpieczna wirtualizacja i ochrona obciążeń
Maszyny wirtualne chronione (Shielded VMs) zabezpieczają zasoby dzierżawcy przed dostępem z poziomu sieci szkieletowej (fabric). Usługa Host Guardian Service (HGS) działa jako kotwica zaufania (trust anchor), dostarczając dwie usługi: atestację (weryfikuje kondycję hosta) i ochronę kluczy (udostępnia klucze do odblokowania wirtualnego modułu TPM maszyny wirtualnej). HGS jest wdrażany w dedykowanym, zabezpieczonym lesie lub domenie, aby zminimalizować ryzyko naruszenia bezpieczeństwa. Istnieją dwa tryby atestacji:
- Atestacja oparta na zaufaniu do TPM: najsilniejsze zabezpieczenie. Hosty Hyper‑V wymagają modułu TPM 2.0, włączonego Secure Boot, wymuszania zasad integralności kodu i funkcji measured boot. HGS weryfikuje logi z measured boot i tożsamość hosta przed udostępnieniem protektora klucza do wirtualnego modułu TPM (vTPM) maszyny wirtualnej.
- Atestacja oparta na zaufaniu administratora (Active Directory): słabsze zabezpieczenie. Hosty potwierdzają zaufanie poprzez członkostwo w grupie AD i opublikowane metadane hosta. Dowody z measured boot nie są oceniane, co ułatwia uruchomienie, ale jest mniej odporne na manipulacje.
Role administratora sieci szkieletowej (fabric) i dzierżawcy są celowo rozdzielone. Administratorzy sieci szkieletowej zarządzają hostami, klastrami, magazynem i siecią, ale nie mogą inspekcjonować dysków maszyn wirtualnych chronionych, podłączać debugerów ani używać konsoli/PowerShell Direct. Administratorzy dzierżawcy tworzą maszynę wirtualną, posiadają poświadczenia do systemu operacyjnego i tworzą dane osłony (shielding data) – zapieczętowany pakiet zawierający plik odpowiedzi unattend, certyfikat RDP i klucze opiekuna (guardian keys) – aby kontrolować, gdzie maszyna wirtualna może być uruchamiana. Maszyny wirtualne chronione używają funkcji BitLocker wewnątrz systemu gościa, zakotwiczonej w wirtualnym module TPM (vTPM), a tylko chronione hosty (guarded hosts) z atestacją HGS otrzymują sekrety potrzebne do ich uruchomienia.
Virtualization‑Based Security (VBS) podnosi granicę bezpieczeństwa ponad jądro systemu, tworząc tryb Virtual Secure Mode (VSM). Dzięki VBS hypervisor wymusza wirtualne poziomy zaufania (Virtual Trust Levels, VTLs), izolując wrażliwe komponenty w VTL1 obok bezpiecznego jądra. Funkcje obejmują:
- Credential Guard: Sekrety procesu LSASS znajdują się w izolowanym procesie (LSAISO) w VSM; normalny system operacyjny (VTL0) nie może bezpośrednio odczytać tej pamięci.
- Hypervisor‑Enforced Code Integrity (HVCI): wykonywany jest tylko kod jądra spełniający nowoczesne wymagania dotyczące podpisywania i integralności; ataki DMA są łagodzone za pomocą IOMMU. Wymagania obejmują UEFI z Secure Boot, wirtualizację procesora z SLAT (Intel EPT/AMD NPT) oraz IOMMU (Intel VT‑d/AMD‑Vi). Konfiguracja odbywa się poprzez zasady grupy (Group Policy): włącz opcję „Turn On Virtualization Based Security”, następnie aktywuj Credential Guard i HVCI; zablokuj konfigurację za pomocą Secure Boot, aby uniemożliwić jej wycofanie. W połączeniu z maszynami wirtualnymi generacji 2, Secure Boot i vTPM, VBS/VSM zapewnia silne wzmocnienie zabezpieczeń zarówno dla hostów, jak i gości.
Izolacja sieciowa, replikacja i punkty kontrolne w Hyper‑V
Przełączniki wirtualne Hyper‑V wymuszają izolację na warstwie 2/L3:
- Przełączniki zewnętrzne (External) łączą się z fizyczną kartą sieciową (lub zespołem SET), aby uzyskać dostęp do sieci LAN. Używaj oddzielnych kart sieciowych dla ruchu zarządczego i ruchu najemców, aby uniknąć wzajemnego przenikania.
- Przełączniki wewnętrzne (Internal) łączą maszyny wirtualne tylko z hostem; brak połączenia z siecią zewnętrzną.
- Przełączniki prywatne (Private) łączą maszyny wirtualne tylko ze sobą; nie ma łączności ani z hostem, ani z siecią LAN. Sieci VLAN segmentują domeny L2. Przypisz VLAN dostępowy (access) do każdej karty sieciowej maszyny wirtualnej w celu prostej izolacji lub włącz tryb trunk, aby przenosić wiele sieci VLAN do urządzenia gościa obsługującego VLAN. Listy ACL portów na karcie sieciowej maszyny wirtualnej dodają bezstanowe filtrowanie oparte na 5-krotce (źródłowy/docelowy adres IP, protokół, port) z kierunkami (przychodzący/wychodzący/oba) i akcjami (zezwalaj/odmawiaj/mierz). Listy ACL portów są wymuszane na hoście i przydatne do lokalnej izolacji oraz podstawowej kontroli ruchu wychodzącego, ale nie zastępują pełnoprawnej zapory sieciowej.
Hyper‑V Replica zapewnia asynchroniczną replikację per maszyna wirtualna bez wymogu współdzielonej pamięci masowej. Jeden serwer jest serwerem podstawowym (primary, wysyłającym dzienniki zmian), a drugi serwerem repliki (replica, odbierającym delty oparte na plikach AVHDX). Interwały replikacji wynoszą 30 sekund, 5 minut lub 15 minut. Opcje uwierzytelniania:
- Kerberos (HTTP 80): proste rozwiązanie dla serwerów przyłączonych do domeny; ruch nie jest szyfrowany. Użyj IPsec, jeśli wymagane jest szyfrowanie w tranzycie.
- Oparte na certyfikatach (HTTPS 443): szyfrowane za pomocą TLS, działa w niezaufanych sieciach i grupach roboczych. Zaplanuj odpowiednie otwarcia w zaporze sieciowej, skonfiguruj autoryzację na serwerze repliki i wybierz magazyn dla repliki. Typy trybu failover:
- Test Failover: uruchamia izolowaną maszynę wirtualną do testów na serwerze repliki bez wpływu na ochronę.
- Planned Failover: zaaranżowane przełączenie; serwer podstawowy jest zamykany, pozostałe dzienniki są wysyłane, co daje RPO z zerową utratą danych przy prawidłowej łączności. Obsługuje replikację odwrotną w celu ponownego ustanowienia ochrony.
- Unplanned Failover: wywoływany, gdy serwer podstawowy jest niedostępny; RPO jest równe ostatniemu otrzymanemu dziennikowi. Replikacja rozszerzona (Extended replication) może przekazywać zmiany z serwera repliki do trzeciej lokalizacji, zwiększając redundancję.
Punkty kontrolne (Checkpoints) przechwytują stan maszyny wirtualnej w danym punkcie czasowym na potrzeby odzyskiwania oraz środowisk deweloperskich i testowych. Standardowe punkty kontrolne (Standard checkpoints) zapisują pamięć maszyny wirtualnej i stan urządzeń, umożliwiając natychmiastowe przywracanie, ale mogą potencjalnie zakłócić spójność aplikacji. Produkcyjne punkty kontrolne (Production checkpoints) używają VSS wewnątrz systemu gościa (Windows) lub opróżniania buforów systemu plików (Linux), aby utworzyć spójny aplikacyjnie obraz bez stanu pamięci; są odpowiednie dla procesów tworzenia kopii zapasowych i długotrwałych punktów przywracania. Pamięć masowa jest zaimplementowana jako dyski różnicowe AVHDX połączone łańcuchowo z bazowym dyskiem VHDX. Zastosowanie lub usunięcie punktu kontrolnego scala łańcuch różnicowy z jego rodzicem w trybie online; duże operacje scalania generują obciążenie I/O, dlatego należy utrzymywać odpowiedni zapas wydajności i unikać głębokich drzew. W przypadku kontrolerów domeny i aplikacji rozproszonych, produkcyjne punkty kontrolne łagodzą problem wycofania numeru USN (USN rollback) i powiązane problemy; standardowe punkty kontrolne najlepiej ograniczyć do krótkotrwałych prac deweloperskich i testowych.
Możliwości hosta, wirtualizacja zagnieżdżona i bezpieczeństwo generacji maszyn wirtualnych
Maszyny wirtualne Generacji 2 uruchamiają się za pomocą UEFI, obsługując Secure Boot i vTPM. Secure Boot weryfikuje programy rozruchowe na podstawie zaufanej bazy danych (użyj szablonu Windows lub odpowiedniego szablonu Linux). vTPM wprowadza semantykę TPM 2.0 do systemu gościa, umożliwiając korzystanie z BitLocker, aprowizację Windows Hello for Business oraz scenariusze maszyn wirtualnych chronionych (shielded VM). Gdy starsze systemy gościa wymagają BIOS-u lub urządzeń starszego typu, maszyny wirtualne Generacji 1 pozostają dostępne, ale nie posiadają Secure Boot ani vTPM.
Wirtualizacja zagnieżdżona (Nested virtualization) umożliwia uruchomienie Hyper‑V wewnątrz maszyny wirtualnej. Wymagania obejmują kompatybilny procesor (Intel VT‑x/EPT lub AMD‑V/NPT), system Windows Server 2016 lub nowszy na hoście i w gościu oraz maszynę wirtualną skonfigurowaną z:
- Pamięcią statyczną (wyłącz pamięć dynamiczną - Dynamic Memory).
- Udostępnionymi rozszerzeniami wirtualizacji (
undefined
).
- Włączonym fałszowaniem adresów MAC (MAC address spoofing) dla scenariuszy, w których wewnętrzne hosty zapewniają NAT lub sieć mostkowaną. Przypadki użycia obejmują uruchamianie kontenerów izolowanych Hyper‑V, budowanie klastrów laboratoryjnych, testowanie trybu failover oraz potoki CI, które wymagają hypervisorów. Azure obsługuje wirtualizację zagnieżdżoną w określonych seriach maszyn wirtualnych; upewnij się, że wybrany rozmiar jest zgodny z zapotrzebowaniem na rozszerzenia wirtualizacji.
Pamięć masowa zdefiniowana programowo, zachowanie woluminów CSV i kworum
Storage Spaces Direct agreguje lokalnie podłączone dyski w pulę obejmującą cały klaster, używając SMB3, RDMA i stosu klastrowania. Wymagania klastra obejmują system Windows Server w edycji Datacenter, węzły przyłączone do domeny z jednorodnymi kartami sieciowymi, sieć o wysokiej przepustowości i niskim opóźnieniu (10/25/40 GbE; zalecane RDMA przez iWARP lub RoCEv2) oraz zweryfikowany sprzęt. Domeny błędów (fault domains) mogą reprezentować węzły, obudowy i szafy serwerowe; ich skonfigurowanie poprawia zachowanie podczas umieszczania i naprawy danych oraz łagodzi skorelowane awarie. Typy odporności na awarie obejmują:
- Dwukierunkowe dublowanie (min. 2 domeny błędów): zorientowane na wydajność, toleruje jedną awarię.
- Trzykierunkowe dublowanie (min. 3 domeny błędów): wyższa trwałość, toleruje dwie awarie.
- Podwójna parzystość i parzystość akcelerowana dublowaniem: wydajne pod względem pojemności z kompromisami w opóźnieniu zapisu; odpowiednie dla obciążeń archiwalnych lub mieszanych z pamięcią podręczną typu write-back. Warstwy buforujące (caching tiers) wiążą szybsze nośniki (NVMe/SSD) jako pamięć podręczną odczytu/zapisu z dyskami pojemnościowymi (SSD/HDD). Pamięć podręczna typu write-back absorbuje losowe zapisy i koalesuje je; dostrajanie odbywa się na poziomie woluminu. Używaj ReFS dla przyspieszonej alokacji, klonowania bloków i strumieni integralności; dobrze komponuje się z semantyką wydajności i naprawy S2D. Świadek (dysk, udział plików lub chmura) jest obowiązkowy dla dwuwęzłowego klastra S2D, aby mógł on przetrwać awarię jednego węzła.
Współdzielone woluminy klastra (Cluster Shared Volumes, CSV) udostępniają spójną przestrzeń nazw (C:\ClusterStorage...) wszystkim węzłom, umożliwiając współbieżny dostęp do woluminów NTFS/ReFS przez CSVFS. Normalne operacje wykorzystują bezpośrednie I/O (direct I/O), gdzie koordynacja metadanych odbywa się przez SMB, ale operacje odczytu/zapisu trafiają bezpośrednio na ścieżki pamięci masowej. Przekierowane I/O (redirected I/O) jest aktywowane w określonych warunkach — podczas konserwacji, awarii ścieżki pamięci masowej, operacji migawek/kopii zapasowych lub gdy wolumin jest wstrzymany. Istnieją dwa tryby przekierowania:
- Przekierowane I/O na poziomie systemu plików: ruch przechodzi przez SMB do koordynatora.
- Przekierowane I/O na poziomie bloków: bardziej wydajne w razie potrzeby dla obciążeń intensywnie korzystających z operacji blokowych. Pamięć podręczna CSV (CSV cache) to pamięć podręczna odczytu w pamięci RAM hosta, która przynosi korzyści obciążeniom zdominowanym przez odczyt, takim jak nadrzędne dyski VHDX i łańcuchy dysków różnicowych. Skonfiguruj pamięć podręczną na poziomie klastra, włączając ją i ustawiając rozmiar pamięci podręcznej bloków odpowiedni dla dostępnej pamięci RAM, pozostawiając margines dla hosta i obciążeń. Monitoruj wskaźniki trafień w pamięci podręcznej (cache hit ratios) i dostosowuj je konserwatywnie, aby uniknąć wyczerpania pamięci systemowej.
Kworum klastra pracy awaryjnej określa żywotność klastra. Tryby obejmują:
- Większość węzłów (Node Majority): nieparzysta liczba węzłów; przetrwa awarię floor((N-1)/2) węzłów.
- Większość węzłów i dysku (Node and Disk Majority): dodaje świadka dyskowego, który uczestniczy w głosowaniu; dobre rozwiązanie, gdy dostępna jest współdzielona pamięć masowa.
- Większość węzłów i udziału plików (Node and File Share Majority): wykorzystuje świadka w postaci udziału plików hostowanego poza domeną awarii klastra.
- Świadek w chmurze (Cloud Witness): wykorzystuje konto Azure Storage jako lekki, wysoko dostępny świadek, idealny dla wdrożeń wielooddziałowych i brzegowych. Nowoczesne klastry używają dynamicznego kworum i dynamicznego świadka: głosy są dostosowywane w czasie rzeczywistym, aby zmaksymalizować tolerancję na awarie, a świadek automatycznie zyskuje lub traci głos, aby uniknąć remisów. W razie potrzeby zastosuj wagi węzłów, aby wykluczyć z głosowania zawodne węzły. Dla klastrów dwuwęzłowych zawsze konfiguruj świadka (udział plików lub chmura), aby umożliwić przetrwanie awarii jednego węzła.
Praktyczny scenariusz problemowy
W firmie Siemens zespół OT/IT musi zmodernizować małą lokalizację brzegową (edge site) hostującą trzy maszyny wirtualne z Windows Server, które obsługują telemetrię produkcyjną. Muszą odizolować ruch między sieciami OT i korporacyjnymi, chronić poświadczenia na hostach i osiągnąć odporność na poziomie lokalizacji bez współdzielonej pamięci masowej.
- Zbuduj dwuwęzłowy klaster pracy awaryjnej Hyper‑V z Storage Spaces Direct
- Dlaczego: S2D eliminuje potrzebę stosowania sieci SAN, zapewnia dublowanie między węzłami w celu zapewnienia trwałości i integruje się z klastrowaniem pracy awaryjnej (Failover Clustering) w celu automatycznego przełączania awaryjnego. Dodaje się świadka w postaci udziału plików lub chmury, aby dwuwęzłowy klaster mógł przetrwać awarię jednego węzła.
- Włącz VBS z Credential Guard i HVCI na obu hostach
- Dlaczego: VBS/VSM izoluje poświadczenia LSASS i wymusza integralność kodu jądra, zmniejszając ryzyko ruchu bocznego złośliwego oprogramowania w środowisku z mieszanymi urządzeniami OT.
- Użyj maszyn wirtualnych generacji 2 z Secure Boot i vTPM
- Dlaczego: UEFI Secure Boot jest odporny na manipulacje typu boot-kit; vTPM umożliwia użycie funkcji BitLocker wewnątrz gościa do szyfrowania danych w spoczynku (data at rest). Jest to zgodne z wymogiem firmy Siemens dotyczącym ochrony wrażliwych konfiguracji telemetrycznych przed kradzieżą w zdalnych lokalizacjach.
- Utwórz zewnętrzny przełącznik Hyper‑V dla każdego fizycznego łącza nadrzędnego (uplink) i segmentuj ruch za pomocą sieci VLAN i list ACL portów
- Dlaczego: Sieci VLAN oddzielają ruch OT i korporacyjny na tej samej fizycznej infrastrukturze, podczas gdy listy ACL portów zapewniają szczegółowe, wymuszane na hoście filtry, aby zapobiec komunikacji wschód-zachód (east-west) między warstwami bez wdrażania pełnych urządzeń wirtualnych na brzegu sieci.
- Skonfiguruj Hyper‑V Replica z lokalizacji brzegowej do serwera repliki w centralnym centrum danych przez HTTPS
- Dlaczego: Uwierzytelnianie oparte na certyfikatach szyfruje replikację na całej trasie (end-to-end) przez niezaufane łącza WAN. Planowane przełączenie awaryjne (planned failover) obsługuje okna konserwacyjne; nieplanowane przełączenie awaryjne (unplanned failover) oferuje odzyskiwanie po awarii (DR), gdy lokalizacja brzegowa jest offline. Replikacja odwrotna (reverse replication) ponownie zabezpiecza dane po przywróceniu działania (failback).
- Standaryzuj użycie wyłącznie produkcyjnych punktów kontrolnych
- Dlaczego: Produkcyjne punkty kontrolne tworzą spójne aplikacyjnie punkty przywracania bez stanu pamięci, co jest odpowiednie dla stosu telemetrycznego i bezpieczniejsze w dłuższej perspektywie niż standardowe punkty kontrolne, które przechwytują pamięć ulotną.
- Włącz pamięć podręczną CSV z konserwatywnym doborem rozmiaru
- Dlaczego: Pulpity telemetryczne, które głównie odczytują dane, korzystają z buforowanych bloków nadrzędnych, co poprawia responsywność bez zużywania nadmiernej ilości pamięci RAM na węzłach brzegowych o ograniczonych zasobach.
Ten projekt wykorzystuje S2D do zapewnienia wysokiej dostępności, VBS/vTPM/Secure Boot do wzmocnienia zaufania, sieci VLAN i listy ACL portów do deterministycznej izolacji oraz Hyper‑V Replica do zapewnienia odporności na poziomie lokalizacji — równoważąc bezpieczeństwo, wydajność i operacyjność w środowisku brzegowym o ograniczonych zasobach.
← Aktualizacje Windows Server i zarządzanie poprawkami · Wszystkie domeny · Odzyskiwanie po awarii i ciągłość działania →
Przećwicz te pytania → · Testy na czas na ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Zdaj egzamin →