Microsoft AZ-140: Odporność, odzyskiwanie i migracja — Przewodnik do nauki

By Laurynas Brazys · 12 August 2026 · #microsoft #az-140 #certification #exam-prep #study-guide

Część Microsoft Azure Virtual Desktop Specialty AZ-140 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Omówienie

Planowanie odporności, odzyskiwania i migracji w usłudze Azure Virtual Desktop (AVD) koncentruje się na utrzymaniu produktywności użytkowników podczas awarii regionalnych, ochronie danych (profili, obrazów, aplikacji), orkiestracji przełączania awaryjnego zależności oraz zapewnieniu przewidywalnego przejścia ze starszych usług Remote Desktop Services (RDS). Efektywne projekty oddzielają bezstanową płaszczyznę sterowania AVD od stanowych płaszczyzn danych, wykorzystują powtarzalną automatyzację do odbudowy, definiują jasne cele odzyskiwania dla każdego komponentu i weryfikują rzeczywistą wydajność za pomocą analizy i modelowania pojemności.

Architektura regionalna, dostęp użytkowników i przełączanie awaryjne

• Płaszczyzny sterowania i danych: Usługi brokera, dostępu internetowego, diagnostyki i zarządzania AVD są globalnie odporne. Hosty sesji, pule hostów, obrazy i magazyn są specyficzne dla regionu i muszą być zaprojektowane pod kątem przełączania awaryjnego.
• Strategia na wypadek awarii regionalnej:
  • Utwórz pulę hostów w regionie dodatkowym dla każdej grupy użytkowników, używając tej samej rodziny rozmiarów maszyn wirtualnych i tego samego pochodzenia obrazu. Replikuj obrazy do regionu dodatkowego za pomocą Azure Compute Gallery.
  • Opublikuj identyczne grupy aplikacji (RemoteApp i/lub Desktop) w obu regionach i przypisz do nich użytkowników, ustawiając pulę podstawową jako domyślną, a dodatkową jako cel DR.
  • Utrzymuj hosty DR w trybie gotowości zimnej lub ciepłej. W przypadku hostów w puli, skaluj do zera lub wyłączaj je, a następnie polegaj na planach skalowania i funkcji Start VM on Connect, aby zminimalizować koszty w stanie spoczynku.
• Dostęp użytkowników podczas awarii:
  • Usługa AVD kieruje żądania połączeń do sprawnych hostów sesji. Gdy przełączysz podstawową pulę hostów w tryb opróżniania lub gdy jest ona niedostępna, nowe połączenia są kierowane do puli dodatkowej, jeśli użytkownicy mają tam przypisania.
  • Poinformuj użytkowników, że otwarte sesje w regionie dotkniętym awarią zostaną rozłączone; ponowne połączenie nastąpi z dostępnym regionem.
• Równoważność obrazów i dołączania aplikacji MSIX app attach:
  • Używaj Azure Image Builder i Azure Compute Gallery (SIG) z replikacją regionalną dla obrazów.
  • Przechowuj pakiety MSIX app attach w odpornych lokalizacjach magazynu, które są dostępne w obu regionach, i replikuj zawartość do regionu dodatkowego (np. za pomocą replikacji międzyregionalnej ANF lub replikacji konta magazynu).
• Zależności sieciowe i tożsamości:
  • Upewnij się, że DNS i tożsamość (Active Directory lub Azure AD DS) są osiągalne z obu regionów. W przypadku Azure AD DS skonfiguruj ustawienia DNS sieci VNet na adresy IP domeny zarządzanej w każdej regionalnej sieci VNet, która wymaga przyłączenia do domeny i rozpoznawania nazw.
  • Sprawdź działanie RDP Shortpath między regionami; w przypadku problemów z UDP nastąpi powrót do trybu reverse connect.

Przykład replikacji wersji obrazu do dwóch regionów:

az sig image-version create \
  --resource-group rg-avd-images \
  --gallery-name sig-avd \
  --gallery-image-definition win11-ms \
  --gallery-image-version 1.0.3 \
  --target-regions eastus=1 westus=1

Cele odzyskiwania i role ochrony danych

Zdefiniuj odrębne RTO/RPO dla każdego komponentu:

• Pule hostów i hosty sesji:
  • W puli: Traktuj hosty sesji jako efemeryczne. RTO wynosi minuty (zautomatyzowane ponowne wdrożenie), RPO jest nieokreślone (brak stanu hosta). Nie polegaj na kopiach zapasowych maszyn wirtualnych do odzyskiwania; wdrażaj ponownie z obrazu i używaj autoskalowania.
  • Osobiste: Jeśli stan użytkownika znajduje się na dysku systemu operacyjnego, chroń go za pomocą Azure Backup lub Azure Site Recovery (ASR). Preferuj przeniesienie stanu użytkownika do profili FSLogix, aby uprościć DR.
• Obrazy:
  • RPO bliskie zeru dla dostępności obrazów dzięki replikacji w Compute Gallery; RTO w minutach na wdrożenie nowych hostów. Utrzymuj potoki złotych obrazów w wersjonowanej i odtwarzalnej formie.
• Profile i pamięci podręczne Office (FSLogix):
  • RPO: od minut do godzin, w zależności od harmonogramów replikacji i tworzenia kopii zapasowych; RTO: minuty na zamontowanie w regionie dodatkowym, jeśli skonfigurowano Cloud Cache, w przeciwnym razie czas na przywrócenie woluminu/udziału i ponowne wskazanie sesji.
• Aplikacje:
  • W przypadku aplikacji w obrazie, dostosuj do RTO/RPO obrazu. W przypadku MSIX app attach, dostosuj do czasu replikacji magazynu pakietów i ponownej rejestracji.

Azure Backup i ASR:

• Azure Backup:
  • Twórz kopie zapasowe udziałów Azure Files, na których przechowywane są kontenery profili FSLogix i ODFC. Używaj częstych migawek, aby osiągnąć cele RPO; przywracaj pojedyncze pliki VHD/VHDX lub cały udział. Poinformuj, że migawki są spójne na poziomie awarii, gdy użytkownicy są zalogowani; w celu precyzyjnego przywracania wykonaj kopiowanie/zmianę nazwy kontenera użytkownika w trybie out-of-band i poinstruuj użytkownika, aby zalogował się ponownie.
  • W razie potrzeby twórz kopie zapasowe dysków systemowych pulpitów osobistych. Hosty w puli generalnie nie wymagają kopii zapasowych maszyn wirtualnych.
• Azure Site Recovery:
  • Używaj ASR dla stanowych komponentów infrastruktury, które są krytyczne dla AVD (np. serwery zarządzania, serwery licencji, jeśli dotyczy, serwery LOB) oraz dla osobistych pul hostów, gdy wymagane jest zachowanie stanu maszyny wirtualnej.
  • Unikaj ASR dla hostów AVD w puli; ponowne wdrożenie z obrazu/planów skalowania jest szybsze i tańsze.

Odporność magazynu profili, Cloud Cache, kopie zapasowe i przywracanie

• Opcje magazynu dla FSLogix:
  • Azure NetApp Files (ANF): Najwyższa liczba IOPS/najniższe opóźnienia na dużą skalę; obsługuje replikację międzyregionalną na potrzeby DR. Idealne dla bardzo dużych środowisk lub wysokiej współbieżności i wymagań dotyczących operacji we/wy profili.
  • Azure Files Premium: Udziały plików PaaS na dyskach SSD z ZRS dla odporności wewnątrzregionalnej; doskonała równowaga między wydajnością a administracją. W przypadku DR między regionami połącz z Cloud Cache i kopią zapasową/przywracaniem na poziomie udziału lub zaprojektuj udziały w dwóch regionach.
  • Storage Spaces Direct (S2D) na IaaS: Używaj tylko wtedy, gdy PaaS nie jest realną opcją. Wymaga co najmniej trzech maszyn wirtualnych bez Cloud Witness dla kworum. Narzut operacyjny jest wyższy niż w przypadku alternatyw PaaS.
• Cloud Cache:
  • Skonfiguruj wielu dostawców (np. dwa punkty końcowe Azure Files lub ANF w różnych strefach/regionach). Podczas awarii regionalnej FSLogix kontynuuje pracę z ocalałymi dostawcami, zapewniając ostateczną spójność dla zapisów w pamięci podręcznej.
  • Przykładowa konfiguracja:

# PowerShell on session host
New-Item -Path HKLM:\SOFTWARE\FSLogix\Profiles -Force | Out-Null
New-ItemProperty HKLM:\SOFTWARE\FSLogix\Profiles -Name Enabled -Type DWord -Value 1 | Out-Null
New-ItemProperty HKLM:\SOFTWARE\FSLogix\Profiles -Name CCDLocations -Type String `
  -Value "type=smb,connectionString=\\files-pri.file.core.windows.net\profiles;type=smb,connectionString=\\files-dr.file.core.windows.net\profiles" | Out-Null
New-ItemProperty HKLM:\SOFTWARE\FSLogix\Profiles -Name DeleteLocalProfileWhenVHDShouldApply -Type DWord -Value 1 | Out-Null

• Wzorce tworzenia kopii zapasowych i przywracania:
  • Wdróż cogodzinne lub co kilka godzin tworzenie migawek Azure Backup dla udziałów profili. W przypadku uszkodzonego profilu użytkownika, odizoluj bieżący plik VHDX, przywróć poprzednią migawkę do alternatywnej lokalizacji i skopiuj lub ponownie dołącz kontener użytkownika.
  • W przypadku ANF używaj migawek i replikacji międzyregionalnej; przywracaj na poziomie woluminu lub pojedynczy plik za pośrednictwem katalogu migawek.
• Testowanie:
  • Uwzględnij w ćwiczeniach DR walidację montowania/dołączania, symulacje uszkodzeń i przywracanie na poziomie użytkownika.

Przełączanie awaryjne ruchu, DNS i zależności

• Zależności aplikacji:
  • Wiele aplikacji AVD zależy od interfejsów API HTTP/S, front-endów webowych lub baz danych. Projektuj je z globalnym równoważeniem obciążenia i wdrożeniami regionalnymi, aby przełączanie awaryjne zależności nie pozostawiało użytkowników w sesjach, które poza tym są w pełni sprawne.
• Azure Front Door i Traffic Manager:
  • Używaj Azure Front Door do globalnego równoważenia obciążenia HTTP/S w warstwie 7, WAF i routingu opartego na ścieżkach dla zależności aplikacji używanych przez użytkowników AVD. Połącz z backendami strefowo-nadmiarowymi (zone-redundant) w każdym regionie.
  • Używaj Azure Traffic Manager do równoważenia obciążenia opartego na DNS dla publicznie dostępnych punktów końcowych innych niż HTTP, które obsługują sondy kondycji (health probes).
• Prywatny DNS i rozpoznawanie nazw:
  • Centralizuj warunkowe usługi przesyłania dalej (conditional forwarders) za pomocą Azure DNS Private Resolver, aby kierować zapytania między środowiskiem lokalnym (on-premises), sieciami VNet w Azure i domenami zarządzanymi. Publikuj rekordy o niskim TTL dla punktów końcowych, które mogą wymagać szybkiego przełączania awaryjnego.
  • Dla punktów końcowych magazynu, które nie mogą natywnie przełączać się awaryjnie w sposób płynny, rozważ punkty końcowe o podwójnej nazwie, abstrahowane za wewnętrznym DNS, aby przełączać się między udziałami podstawowymi (primary) i odzyskiwania po awarii (DR) podczas incydentu.
• Sieciowy QoS i dostęp:
  • Priorytetyzuj ruch AVD w czasie rzeczywistym (UDP/TCP) w sieciach WAN; dostosuj QoS na routerach oddziałowych, aby zapewnić klasom ruchu AVD wystarczającą przepustowość w celu zmniejszenia błędów połączeń i opóźnień.
  • Weryfikuj osiągalność Shortpath i otwarte porty na zaporze sieciowej (firewall pinholes); upewnij się, że planowanie przepustowości wychodzącej (egress) odpowiada współbieżności i mieszance obciążeń.

Migracja z RDS, odnajdywanie, gęstość i pojemność

• Ocena środowiska RDS:
  • Zrób inwentaryzację Connection Brokers, RD Gateways, RD Web, RD Session Hosts, RD Licensing oraz serwerów plików/magazynów profili. Udokumentuj obiekty GPO, konfigurację FSLogix i metody dostarczania aplikacji.
  • Przyporządkuj role do konstrukcji AVD: pule hostów, obszary robocze, grupy aplikacji, magazyn profili i brokering zarządzany przez AVD; wyeliminuj potrzebę używania RD Gateway i RD Broker w Azure.
• Azure Migrate i odnajdywanie:
  • Użyj urządzenia Azure Migrate, aby odnaleźć istniejące maszyny wirtualne RDS, bazowe wskaźniki wydajności i zależności. Zidentyfikuj relacje aplikacja-serwer w celu rozmieszczenia hostów sesji AVD i uwzględnienia grawitacji danych (data gravity).
• Analiza gęstości użytkowników:
  • Zbuduj modele gęstości dla każdego typu obciążenia (użytkownicy zadaniowi/merytoryczni/zaawansowani - task/knowledge/power users). Określ liczbę sesji na maszynę wirtualną, korzystając z bazowych wskaźników gotowości procesora (CPU ready), presji na pamięć (memory pressure) i operacji we/wy profilu (profile IO). Zweryfikuj za pomocą testów pilotażowych na kandydackich jednostkach SKU maszyn wirtualnych (np. Dv5/Esv5/Dasv5, z obsługą GPU dla grafiki).
  • Użyj narzędzia Azure Virtual Desktop Experience Estimator, aby wybrać regiony o najniższym opóźnieniu między użytkownikiem a hostem.
• Modelowanie pojemności:
  • Przekształć gęstość w liczbę hostów na pulę, uwzględniając bufor N+1 i narzut na konserwację. Zdefiniuj progi skalowania w poziomie (scale-out) oraz minimalną/maksymalną liczbę hostów w planach skalowania. Rozważ rezerwacje pojemności (capacity reservations) w celu uzyskania przewidywalnych kosztów i gwarantowanych rdzeni w obciążonych regionach.
  • Upewnij się, że limity subskrypcji i regionalne (vCPU, rdzenie na rodzinę, adresy IP, karty sieciowe, dyski) zostaną podniesione z wyprzedzeniem; składaj wnioski o zwiększenie limitów odpowiednio wcześnie.

Przełączenie, współistnienie, limity i runbooki

• Planowanie przełączenia:
  • Uruchom równoległe współistnienie: utrzymuj działanie RDS, podczas gdy AVD wdraża piloty. Publikuj te same aplikacje w obu systemach, ale kieruj użytkowników według kohort.
  • Kohorty pilotażowe: zacznij od działu IT i early adopters, rozszerz na reprezentatywne działy, a następnie przeprowadź szerokie wdrożenie. Wykorzystaj opinie do dostosowania obrazów, ustawień FSLogix i skalowania.
  • Plan wycofania (rollback): utrzymuj ścieżki dostępu do RDS do momentu spełnienia kryteriów akceptacji. Zachowaj profile użytkowników kompatybilne wstecznie lub zapewnij ścieżkę resetowania profilu dla każdej kohorty.
• Gotowość operacyjna:
  • Klucze rejestracyjne: podczas dołączania istniejących maszyn wirtualnych do pul hostów, wygeneruj klucz rejestracyjny i dołącz za pomocą agenta AVD; zautomatyzuj to za pomocą Azure Image Builder i skryptów uruchamianych po udostępnieniu zasobów.
  • Higiena obszarów roboczych i grup aplikacji: publikuj grupy aplikacji z najniższymi uprawnieniami; oddziel Desktop i RemoteApp; utrzymuj grupy aplikacji DR przypisane, ale w razie potrzeby wizualnie mniej wyeksponowane.
• Runbooki i automatyzacja:
  • Zbuduj runbooki ciągłości działania i odzyskiwania po awarii (BCDR), które obejmują:
    • Ogłoszenie incydentu i przełączenie pul podstawowych w tryb opróżniania (drain mode).
    • Skalowanie pul DR i weryfikacja zgodności obrazów.
    • Przełączanie magazynu profili za pomocą Cloud Cache lub zmiany przekierowania DNS.
    • Walidacja krytycznych zależności aplikacji przez Front Door/Traffic Manager.
    • Komunikacja z użytkownikami i service deskiem.
    • Wycofanie zmian po przywróceniu regionu podstawowego.
  • Zaimplementuj runbooki przy użyciu Azure Automation lub Functions z kontrolą dostępu opartą na rolach i zatwierdzeniami zmian.
• Koszty i rezerwacje:
  • Używaj Savings Plans i Capacity Reservations dla stałych obciążeń bazowych; utrzymuj pojemność na skoki obciążenia w modelu pay-as-you-go z autoskalowaniem. Zaplanuj wyłączanie pul nieprodukcyjnych poza godzinami pracy.

Praktyczny scenariusz problemowy

Firma Adobe musi zapewnić zespołom kreatywnym i wsparcia ciągłość pracy podczas awarii regionalnej w trakcie migracji z lokalnej farmy RDS do Azure Virtual Desktop, przy setkach terabajtów profili mobilnych i wymagających obciążeniach graficznych.

1. Wykrywanie i ustalanie punktu odniesienia

• Użyj Azure Migrate do inwentaryzacji hostów RDS, udziałów profilowych i zależności aplikacji biznesowych (LOB) oraz do przechwycenia wzorców użycia CPU/pamięci/IO dla kohort graficznych i wsparcia.
• Dlaczego: Empiryczne dane bazowe pozwalają na precyzyjne określenie docelowej gęstości użytkowników i wybór jednostek SKU maszyn wirtualnych, minimalizując nadmiarowe alokowanie zasobów.

2. Zaprojektuj architekturę regionalną

• Utwórz podstawowe pule hostów w regionie West US 2 z maszynami NVadsA v5 z obsługą GPU dla zespołów kreatywnych i Dv5 dla wsparcia; wdróż dodatkowe pule w Central US.
• Replikuj obrazy za pomocą Azure Compute Gallery; przechowuj pakiety MSIX w ANF z replikacją międzyregionową.
• Dlaczego: Zapewnia to zgodność zasobów obliczeniowych i aplikacji w różnych regionach z przewidywalną wydajnością.

3. Wzmocnij tożsamość i DNS

• Skonfiguruj DNS w VNet na adresy IP Azure AD DS, do których będą dołączać hosty sesji; wdróż Azure DNS Private Resolver, aby przekazywać zapytania między środowiskiem lokalnym a Azure.
• Dlaczego: Niezawodne rozpoznawanie nazw w różnych regionach umożliwia logowanie i dostęp do aplikacji podczas przełączania awaryjnego.

4. Zaimplementuj odporne profile

• Użyj Azure NetApp Files dla FSLogix z migawkami i replikacją międzyregionową; włącz FSLogix Cloud Cache wskazujący na podstawowe i zapasowe woluminy ANF.
• Dlaczego: ANF dostarcza IOPS/opóźnienia wymagane przez zespoły kreatywne; Cloud Cache i CRR zapewniają ciągłość działania w przypadku awarii regionu.

5. Zorganizuj przełączanie awaryjne zależności

• Użyj Azure Front Door jako frontendu dla internetowych interfejsów API aplikacji biznesowych (LOB) i skonfiguruj backendy wdrożone regionalnie; użyj Traffic Manager dla publicznych punktów końcowych innych niż HTTP.
• Dlaczego: Utrzymuje to osiągalność punktów końcowych aplikacji z dowolnego regionu AVD bez potrzeby rekonfiguracji.

6. Ustal cele odzyskiwania i ochronę

• Ustaw RTO na minuty dla hostów w puli (odbudowa), godziny dla pulpitów osobistych (jeśli istnieją, chronione przez Azure Backup/ASR) oraz RPO na poziomie 15 minut dla profili za pomocą migawek ANF; twórz kopie zapasowe udziałów Azure Files kohorty wsparcia, jeśli są używane.
• Dlaczego: Cele specyficzne dla komponentów dostosowują koszty do wpływu na biznes.

7. Pilotaż i współistnienie

• Wdróż 100 użytkowników wsparcia i 50 kreatywnych na AVD; utrzymuj RDS opublikowany równolegle. Zweryfikuj gęstość, stabilność profili i wydajność aplikacji. Iteracyjnie dostosowuj polityki skalowania i ustawienia FSLogix.
• Dlaczego: Kontrolowane pilotaże zmniejszają ryzyko związane z wyborem obrazów, magazynu i autoskalowania.

8. Przełączenie i test odzyskiwania po awarii (DR)

• Wygeneruj klucze rejestracyjne AVD, aby rozszerzyć pule; przypisz grupy aplikacji DR do wszystkich użytkowników. Przeprowadź test DR: opróżnij pulę podstawową, przeskaluj pulę DR, zweryfikuj ciągłość działania Cloud Cache i przełącz awaryjnie zależności aplikacji przez Front Door.
• Dlaczego: Dowodzi to skuteczności przełączania awaryjnego end-to-end, włączając profile i zależności, przed pełną migracją.

9. Limity, rezerwacje i automatyzacja

• Wcześniej zwiększ regionalne limity vCPU i GPU; zakup Capacity Reservations dla bazowego obciążenia GPU i CPU; zaimplementuj runbooki Azure Automation do opróżniania pul, skalowania, przełączania magazynu i komunikacji.
• Dlaczego: Gwarantuje to pojemność podczas incydentów i eliminuje ręczne kroki podczas stresujących zdarzeń.

10. Pełna migracja i plan wycofania

• Migruj pozostałe kohorty falami w ciągu dwóch tygodni; utrzymuj dostęp do RDS jako ścieżkę wycofania z jasnymi bramkami decyzyjnymi dla każdej fali.
• Dlaczego: Stopniowe przełączanie zmniejsza ryzyko i zachowuje natychmiastową opcję awaryjną na wypadek pojawienia się nieoczekiwanych problemów.

← Monitorowanie · Wszystkie domeny

Przećwicz te pytania → · Testy na czas na ExamRoll.io →

Przeglądaj Microsoft →