Konserwacja maszyn wirtualnych na platformie Azure

Dotyczy: ✔️ Maszyny wirtualne z systemem Linux ✔️ Maszyny wirtualne z systemem Windows ✔️ Zestawy skalowania z elastyczną orkiestracją ✔️ Zestawy skalowania z jednolitą orkiestracją

Platforma Azure co pewien jest czas aktualizowana w celu poprawy niezawodności, wydajności i zabezpieczeń infrastruktury hostowania maszyn wirtualnych. Zakres aktualizacji obejmuje tematykę od poprawek składników oprogramowania w środowisku hostingu do uaktualniania składników sieci lub likwidowania sprzętu.

Aktualizacje rzadko wpływają na hostowane maszyny wirtualne. Gdy aktualizacje mają wpływ, Azure wybiera metodę aktualizacji powodującą najmniejsze zakłócenia:

• Jeśli aktualizacja nie wymaga ponownego uruchomienia, maszyna wirtualna jest wstrzymana podczas aktualizacji hosta lub jest migrowana na żywo do już zaktualizowanego hosta.

• Jeśli aktualizacja wymaga ponownego uruchomienia, Azure powiadomi Cię o planowanej konserwacji. Platforma Azure udostępnia również przedział czasu, w którym można samodzielnie rozpocząć konserwację, w odpowiednim dla ciebie momencie. Okno samodzielnej konserwacji zależy od typu konserwacji:

  • Likwidowanie sprzętu: okno samodzielnej konserwacji wynosi zwykle 14 dni.
  • Konserwacja hosta: okno samodzielnej konserwacji wynosi zwykle 35 dni, chyba że konserwacja jest pilna.

  Azure inwestuje w technologie w celu zmniejszenia liczby przypadków, w których planowana konserwacja platformy wymaga ponownego uruchomienia maszyn wirtualnych. Aby uzyskać instrukcje dotyczące zarządzania planowaną konserwacją, zobacz Obsługa powiadomień dotyczących planowanej konserwacji przy użyciu Azure CLI, programu PowerShell lub portalu.

Na tej stronie opisano sposób wykonywania obu typów konserwacji przez platformę Azure. Aby uzyskać więcej informacji na temat nieplanowanych zdarzeń (awarii), zobacz Zarządzanie dostępnością maszyn wirtualnych dla systemu Windows lub odpowiedni artykuł dla systemu Linux.

Na maszynie wirtualnej można otrzymywać powiadomienia o nadchodzącej konserwacji przy użyciu zaplanowanych zdarzeń dla systemu Windows lub Linux.

Konserwacja, która nie wymaga ponownego uruchomienia

Większość aktualizacji platformy nie ma wpływu na maszyny wirtualne klienta. Jeśli przeprowadzenie aktualizacji bez wpływu nie jest możliwe, Azure wybiera mechanizm aktualizacji, który ma najmniejszy wpływ na maszyny wirtualne klientów.

Gdy wymagana jest konserwacja wpływająca na maszynę wirtualną, prawie zawsze będzie ona zakończona przez wstrzymanie maszyny wirtualnej przez mniej niż 10 sekund. W rzadkich przypadkach, nie częściej niż raz na 18 miesięcy dla rozmiarów maszyn wirtualnych ogólnego przeznaczenia, platforma Azure używa mechanizmu, który wstrzymuje maszynę wirtualną na około 30 sekund. Po każdej operacji wstrzymania zegar maszyny wirtualnej jest automatycznie synchronizowany po wznowieniu.

Konserwacja zachowująca pamięć działa dla ponad 90 procent maszyn wirtualnych platformy Azure. Nie działa w przypadku serii G, L, N i H. Aby uzyskać więcej informacji, zobacz , które rozmiary maszyn wirtualnych obsługują konserwację zachowującą pamięć. Platforma Azure coraz częściej korzysta z technologii migracji na żywo i ulepsza mechanizmy konserwacji chroniące pamięć w celu skrócenia czasu trwania wstrzymania.

Te operacje konserwacji, które nie wymagają ponownego uruchomienia, są stosowane w jednej domenie błędów naraz. Zatrzymują się, jeśli wykryją jakiekolwiek ostrzegawcze sygnały o problemach ze stanem platformy z narzędzi monitorujących platformę. Operacje konserwacji, które nie wymagają ponownego uruchomienia, mogą wystąpić jednocześnie w sparowanych regionach lub Strefy dostępności. W przypadku danej zmiany wdrożenia są w większości przeprowadzane sekwencyjnie w różnych strefach dostępności oraz parach regionów, ale pod koniec może wystąpić pewne nakładanie się.

Te typy aktualizacji mogą mieć wpływ na niektóre aplikacje. Gdy maszyna wirtualna jest migrowana na żywo do innego hosta, niektóre wrażliwe obciążenia mogą spowodować niewielkie obniżenie wydajności w ciągu kilku minut poprzedzających wstrzymanie maszyny wirtualnej. Aby przygotować się do konserwacji maszyny wirtualnej i zmniejszyć wpływ na konserwację platformy Azure, spróbuj użyć zaplanowanych zdarzeń dla systemu Windows lub Linux dla takich aplikacji.

Aby uzyskać większą kontrolę nad wszystkimi operacjami konserwacyjnymi, w tym aktualizacjami bez wpływu na działanie systemu i niewymagającymi ponownego uruchomienia, można utworzyć konfigurację konserwacji. Utworzenie konfiguracji konserwacji umożliwia pominięcie wszystkich aktualizacji platformy i zastosowanie aktualizacji w wybranym czasie. Aby uzyskać więcej informacji, zobacz Zarządzanie aktualizacjami platformy za pomocą konfiguracji konserwacji.

Migracja na żywo

Migracja na żywo to operacja, która nie wymaga ponownego uruchomienia i która zachowuje pamięć dla maszyny wirtualnej. Powoduje to przerwę lub zawieszenie, które zwykle trwa nie dłużej niż 5 sekund. Z wyjątkiem serii G, L, N i H, wszystkie maszyny wirtualne IaaS obsługują migrację na żywo. Migracja na żywo jest dostępna w większości jednostek SKU serii M. Kwalifikujące się maszyny wirtualne reprezentują ponad 90% maszyn wirtualnych IaaS wdrożonych w floty platformy Azure.

Uwaga

Nie otrzymasz powiadomienia w witrynie Azure Portal dla operacji migracji na żywo, które zostały podjęto próbę lub nie wymagają ponownego uruchomienia. Aby wyświetlić listę migracji na żywo, które nie wymagają ponownego uruchomienia, wykonaj zapytanie dotyczące zaplanowanych zdarzeń.

Migracja na żywo jest przeprowadzana na zasadzie najlepszych starań. W niektórych rzadkich przypadkach migracja na żywo może zakończyć się niepowodzeniem, a maszyna wirtualna zostanie zaplanowana na naprawę serwisową, jeśli zajdzie taka potrzeba, przed powiadomieniem. Migracja na żywo nie jest gwarantowaną operacją.

Platforma Azure wyzwala migrację na żywo w następujących scenariuszach:

• Planowana konserwacja
• Awaria sprzętu
• Optymalizacje alokacji

Niektóre scenariusze planowanej konserwacji korzystają z migracji na żywo i można użyć zaplanowanych zdarzeń, aby wiedzieć z wyprzedzeniem, kiedy zostaną uruchomione operacje migracji na żywo.

Migracja na żywo może również służyć do przenoszenia maszyn wirtualnych, gdy algorytmy usługi Azure Machine Learning przewidują zbliżającą się awarię sprzętu lub optymalizację alokacji maszyn wirtualnych. Aby uzyskać więcej informacji na temat modelowania predykcyjnego, które wykrywa wystąpienia sprzętu o obniżonej wydajności, zobacz Ulepszanie odporności maszyny wirtualnej platformy Azure przy użyciu predykcyjnego uczenia maszynowego i migracji na żywo. Powiadomienia o migracji dynamicznej są wyświetlane w portalu Azure w dziennikach usługi Monitor i Service Health, a także w usłudze Scheduled Events, jeśli korzystasz z tych usług.

Odporność połączenia TCP podczas migracji na żywo

Aplikacje, które utrzymują długotrwałe połączenia TCP, takie jak serwery bazy danych, brokery komunikatów i warstwy buforowania, mogą powodować zakłócenia połączeń podczas migracji na żywo. Chociaż wstrzymanie maszyny wirtualnej trwa zwykle krócej niż 5 sekund, zachowanie stosu TCP w trakcie wstrzymania i po jego zakończeniu może wydłużyć czas przywracania działania aplikacji, jeśli nie zostanie odpowiednio obsłużone.

Jak migracja na żywo wpływa na połączenia TCP:

• Podczas wstrzymania segmenty TCP będące w tranzycie nie są potwierdzane przez migrowaną maszynę wirtualną.
• Strona wysyłająca (klient lub sonda kondycji modułu równoważenia obciążenia) rozpoczyna retransmisję TCP z wykładniczo narastającym opóźnieniem.
• Azure usługa Load Balancer w warstwie Standardowa wysyła protokół RST TCP do bezczynnych połączeń, które przekraczają skonfigurowany limit czasu bezczynności. Jednak w przypadku aktywnych połączeń z danymi w locie moduł równoważenia obciążenia nie wysyła protokołu TCP RST podczas wstrzymania migracji. Połączenie pozostaje otwarte, ale nie odpowiada, a klient nie ma natychmiastowego sygnału awarii.
• Bez dostrajania na poziomie aplikacji domyślne zachowanie retransmisji TCP (tcp_retries2 = 15 w systemie Linux) może opóźnić wykrywanie błędów połączenia o około 15 minut.

Important

Wpływ różni się znacznie w zależności od domyślnych ustawień systemu operacyjnego. W systemie Linux domyślna wartość parametru tcp_retries2 wynosi 15, co oznacza, że zerwane połączenie zostanie wykryte po około 15 minutach. W Windows TcpMaxDataRetransmissions wartość domyślna to 5, która ogranicza czas wykrywania do około 25–50 sekund bez żadnego dostrajania. Środki zaradcze opisane w tym artykule mają kluczowe znaczenie dla obciążeń opartych na systemie Linux.

Uwaga

W przypadku obciążeń HTTP/1.1 wpływ jest zwykle ograniczony: dotyczy tylko żądań będących w trakcie realizacji w momencie migracji, a ponieważ klienci HTTP/1.1 nie stosują pipeliningu w połączeniach keep-alive, szybko wznawiają pracę, otwierając nowe połączenie, aby wysłać kolejne żądanie. W przypadku protokołu HTTP/2 promień wybuchu jest szerszy, ponieważ wiele współbieżnych strumieni współużytkuje jedno połączenie TCP.

Gdy moduł równoważenia obciążenia działa w trybie przekazywania protokołu TLS L4, nie może sprawdzić, ponowić lub wstrzyknąć odpowiedzi o błędach do zaszyfrowanego strumienia. W tej konfiguracji klient jest wyłącznie odpowiedzialny za wykrywanie i odzyskiwanie po zatrzymanym połączeniu.

Zmniejsz promień wybuchu przy użyciu wdrożeń obejmujących wiele wystąpień:

Przed zastosowaniem środków zaradczych na poziomie TCP należy wziąć pod uwagę punkt odniesienia architektury. Migracja na żywo dotyczy jednocześnie tylko jednej maszyny wirtualnej (VM) w zestawie dostępności lub zestawie skalowania maszyn wirtualnych. Rozłożenie połączeń między wieloma wystąpieniami zaplecza ogranicza wpływ dowolnego pojedynczego zdarzenia migracji:

• Zestaw skalowania z trzema wystąpieniami oznacza, że każde zdarzenie migracji ma wpływ na co najwyżej jedną trzecią aktywnych połączeń.
• Wdrażanie w Strefy dostępności zapewnia, że migracje w różnych strefach nie nakładają się na siebie.
• Klienci z pulami połączeń rozproszonymi na wiele backendów odzyskują sprawność szybciej, ponieważ połączenia, których problem nie dotyczy, nadal mogą natychmiast obsługiwać żądania.

W czasie wstrzymania maszyny wirtualnej sondy kondycji usługi Azure usługa Load Balancer w warstwie Standardowa dla wstrzymanego zaplecza również nie przechodzą. Moduł równoważenia obciążenia oznacza serwer zaplecza jako niesprawny w ciągu około 10 sekund (dwie kolejne nieudane próby sondowania przy domyślnym 5-sekundowym interwale) i przestaje kierować do niego nowe połączenia. Ten warunek oznacza, że nowe połączenia są naturalnie chronione. Środki zaradcze protokołu TCP opisane w tym artykule dotyczą istniejących połączeń, które zostały już ustanowione przed rozpoczęciem migracji.

Zalecane środki zaradcze:

Następujące środki zaradcze uzupełniają się. Po wdrożeniu razem zmniejszają one wpływ zdarzenia migracji na żywo z minut potencjalnych przestojów do sekund automatycznego odzyskiwania.

Priority	Mitigation	wysiłek	Wpływ
1	Ustaw TCP_USER_TIMEOUT na poziomie gniazda	Low	Skraca czas wykrywania nieaktywnego połączenia z ok. 15 minut do 30 sekund
2	Subskrybowanie zaplanowanych zdarzeń	Średni	Umożliwia aktywne opróżnianie połączeń przed wystąpieniem zamrożenia
3	Dostrajanie parametrów keepalive protokołu TCP	Low	Wykrywa bezczynne połączenia, które stają się nieaktualne po migracji
4	Implementowanie logiki ponawiania po stronie klienta	Średni	Zapewnia odporność niezależnie od głównej przyczyny

Ograniczenie ryzyka 1: TCP_USER_TIMEOUT (najszybsze wykrywanie)

TCP_USER_TIMEOUT Określa, jak długo jądro czeka na potwierdzenie przesłanych danych przed zadeklarowaniem połączenia nieaktywnego. Ustawienie tej wartości na 30 sekund (30000 ms) na gniazdo znacznie skraca czas wykrywania.

// Per-socket (recommended)
int timeout = 30000; // 30 seconds in milliseconds
setsockopt(fd, IPPROTO_TCP, TCP_USER_TIMEOUT, &timeout, sizeof(timeout));

Alternatywnie zmniejsz liczbę retransmisji całego systemu:

# /etc/sysctl.conf — reduces retransmit ceiling to ~25-50 seconds
net.ipv4.tcp_retries2 = 5

Wskazówka

Ustaw TCP_USER_TIMEOUT na poziomie zestawu SDK lub gniazda, a nie na poziomie całego systemu. Wartość 30 sekund jest dobrym punktem wyjścia. Wartości poniżej 10 sekund mogą powodować fałszywe alarmy przy normalnym jitterze sieciowym.

Uwagi dotyczące systemu Windows:

Opcja gniazda TCP_USER_TIMEOUT jest specyficzna dla systemu Linux. W Windows zachowanie retransmisji TCP jest kontrolowane inaczej:

• W systemie Windows domyślnie stosuje się 5 retransmisji (TcpMaxDataRetransmissions), co już zapewnia około 25-50 sekund czasu wykrywania bez żadnego dostrajania.
• Aby jeszcze bardziej skrócić czas wykrywania Windows, dostosuj rejestr:

# Reduce TCP retransmissions (system-wide, requires reboot)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" `
    -Name "TcpMaxDataRetransmissions" -Value 3 -Type DWord

Po TcpMaxDataRetransmissions ustawieniu wartości 3 czas wykrywania skraca się do około 10–20 sekund w zależności od początkowego limitu czasu ponownego transmisji.

Uwaga

W przeciwieństwie do Linuksa system Windows nie udostępnia odpowiednika TCP_USER_TIMEOUT dla pojedynczego gniazda. Ustawienie rejestru dotyczy wszystkich połączeń TCP w systemie. Aby uzyskać precyzyjną kontrolę w systemie Windows, należy polegać na limitach czasu oczekiwania na poziomie aplikacji oraz kontrolach stanu (Środek zaradczy 4).

Działanie zaradcze 2: Zaplanowane wydarzenia (kontrolowane opróżnianie)

Przed rozpoczęciem migracji na żywo usługa Zaplanowane zdarzenia zawiera powiadomienie z wyprzedzeniem. Aplikacje mogą nasłuchiwać zdarzeń Freeze i aktywnie opróżniać połączenia przed wstrzymaniem.

GET http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01
Headers: Metadata: true

Zdarzenie migracji na żywo jest wyświetlane jako:

{
  "EventType": "Freeze",
  "ResourceType": "VirtualMachine",
  "Resources": ["myVM"],
  "EventStatus": "Scheduled",
  "NotBefore": "2026-04-29T18:00:00Z"
}

Po wykryciu zdarzenia Freeze:

1. Przestań akceptować nowe połączenia w węźle, którego dotyczy problem.
2. Opróżnianie istniejących połączeń (sygnalizuj klientom ponowne połączenie z innymi węzłami).
3. Poczekaj na ukończenie operacji w locie z ograniczonym limitem czasu.
4. Opcjonalnie potwierdź zdarzenie, odsyłając EventId.

Uwaga

Okres powiadomienia z wyprzedzeniem wynosi zwykle 15 minut, ale w rzadkich przypadkach może wynosić nawet 30 sekund. Częstotliwość sondowania raz na sekundę jest zalecana w przypadku obciążeń produkcyjnych.

Ograniczenie ryzyka 3: dostrajanie utrzymania aktywności TCP

Sondy keepalive protokołu TCP wykrywają połączenia, które stają się bezczynne po zdarzeniu migracji:

net.ipv4.tcp_keepalive_time = 30      # seconds before first probe (default: 7200)
net.ipv4.tcp_keepalive_intvl = 10     # seconds between probes (default: 75)
net.ipv4.tcp_keepalive_probes = 3     # probes before declaring dead (default: 9)

Przy tych ustawieniach nieużywane, nieaktualne połączenie jest wykrywane w ciągu 60 sekund (30 + 10 x 3). Sondy keepalive są również uznawane za aktywność na potrzeby limitu czasu bezczynności usługi usługa Load Balancer w warstwie Standardowa, co zapobiega samodzielnemu przekraczaniu limitu czasu bezczynnych połączeń przez moduł równoważenia obciążenia.

Ograniczenie ryzyka 4: Logika ponawiania po stronie klienta

Ponowne nawiązywanie połączenia na poziomie aplikacji i logika ponawiania prób zapewnia odzyskiwanie niezależnie od metody wykrywania błędów:

1. Wykrywanie błędu połączenia (przekroczenie limitu czasu, RST lub odmowa połączenia).
2. Zamknij nieaktywne połączenie i usuń je z puli połączeń.
3. Otwórz nowe połączenie z tym samym lub innym węzłem.
4. Ponów operację, stosując wykładniczo wydłużany czas oczekiwania.

W przypadku zestawów SDK baz danych i pul połączeń włącz okresowe kontrole kondycji (na przykład uproszczone polecenie ping co 10–15 sekund), aby proaktywnie weryfikować połączenia.

Konfiguracja puli połączeń:

Pule połączeń, które utrzymują długotrwałe połączenia, korzystają z ustawienia maksymalnego okresu istnienia. To ustawienie wymusza okresowe odtwarzanie połączeń, zapewniając, że żadne pojedyncze połączenie nie gromadzi ryzyka związanego z przyszłymi zdarzeniami migracji:

Technologia puli	Setting	Zalecana wartość
HikariCP (Java)	maxLifetime	1800000 (30 minut)
PgBouncer	server_lifetime	1800 (30 minut)
Dalej database/sql	SetConnMaxLifetime	30 * czas. Minut
Node.js (pg Pool)	idleTimeoutMillis	30000 (usunięcie po 30 sekundach bezczynności; maksymalny czas życia wymaga niestandardowej logiki)
.NET SqlConnection	Ciąg połączenia: Connection Lifetime	1800 (30 minut)

Ustawienie maksymalnego czasu życia na 30 minut oznacza, że nawet bez aktywnych kontroli stanu połączenia są automatycznie wymieniane, zanim zdążą pozostawać niezauważenie przestarzałe przez dłuższy czas.

Monitorowanie i obserwowanie:

Aby wykryć i zmierzyć wpływ zdarzeń migracji na żywo w połączeniach TCP, użyj następujących metod:

• Metryka dostępności maszyny wirtualnej w usłudze Azure Monitor (wersja zapoznawcza): spada do 0 podczas wstrzymania działania maszyny wirtualnej. Utwórz regułę alertu na VmAvailabilityMetric z progiem o wartości mniejszej niż 1, aby wykryć zdarzenia migracji.
• Dziennik aktywności dla zaplanowanych zdarzeń: Zdarzenia migracji na żywo są wyświetlane w Dzienniku aktywności u dostawcy Microsoft.Compute, pod nazwą operacji Microsoft.Compute/virtualMachines/liveMigration/action, lub jako zdarzenia Freeze w przypadku zapytań wykonywanych za pośrednictwem usługi Metadata Service.
• Częstotliwość błędów połączenia na poziomie aplikacji: Monitoruj resetowanie połączeń TCP, przekroczenia limitu czasu i liczbę ponownych połączeń w metrykach aplikacji. Gwałtowny wzrost liczby błędów połączeń korelujących z spadkiem dostępności maszyny wirtualnej potwierdza wpływ migracji.
• Liczniki retransmisji TCP: W systemie Linux należy monitorować /proc/net/netstat pole TCPTimeouts lub używać ss -ti go do obserwowania liczby przetransmisji na poszczególnych gniazdach. Zwiększona liczba retransmisji w trakcie znanego okna konserwacyjnego wskazuje, że połączenia były dotknięte problemem.

# Linux: Check TCP timeout statistics
cat /proc/net/netstat | grep -i timeout
# Or per-socket retransmission info
ss -ti | grep -i retrans

Ustanowienie punktu odniesienia dla tych metryk podczas normalnego działania ułatwia określenie wpływu zdarzeń migracji i sprawdzenie, czy środki zaradcze działają zgodnie z oczekiwaniami.

Obciążenia robocze, które nie tolerują przerw podczas migracji na żywo

W przypadku obciążeń, które nie tolerują żadnych przerw związanych z migracją na żywo, rozważ użycie Azure Dedicated Hosts z Konfiguracjami obsługi. Dedykowane hosty dają kontrolę nad tym, kiedy odbywają się prace konserwacyjne na poziomie hosta, eliminując nieoczekiwane migracje na żywo.

Konserwacja wymagająca ponownego uruchomienia

W rzadkich przypadkach, w których maszyny wirtualne muszą zostać ponownie uruchomione w celu planowanej konserwacji, otrzymasz powiadomienie z wyprzedzeniem. Planowana konserwacja ma dwie fazy: fazę samoobsługi i zaplanowaną fazę konserwacji.

W fazie samoobsługi, która zwykle trwa cztery tygodnie, należy rozpocząć konserwację na maszynach wirtualnych. W ramach samoobsługi możesz wykonać zapytanie dotyczące każdej maszyny wirtualnej, aby zobaczyć jej stan i wynik ostatniego żądania konserwacji.

Uwaga

W przypadku serii maszyn wirtualnych, które nie obsługują migracji na żywo, dane dysków lokalnych (efemerycznych) mogą zostać utracone podczas zdarzeń konserwacji. Zapoznaj się z poszczególnymi seriami maszyn wirtualnych, aby uzyskać informacje na temat tego, czy migracja na żywo jest obsługiwana.

Po uruchomieniu konserwacji samoobsługowej maszyna wirtualna zostanie ponownie wdrożona do już zaktualizowanego węzła. Ponieważ maszyna wirtualna zostanie wdrożona ponownie, dysk tymczasowy zostanie utracony, a publiczne dynamiczne adresy IP skojarzone z interfejsem sieci wirtualnej zostaną zaktualizowane.

Jeśli podczas konserwacji samoobsługowej wystąpi błąd, operacja zostanie zatrzymana, maszyna wirtualna nie zostanie zaktualizowana i zostanie wyświetlona opcja ponawiania próby samoobsługowej konserwacji.

Po zakończeniu fazy samoobsługi rozpocznie się zaplanowana faza konserwacji. W tej fazie nadal można wykonywać zapytania dotyczące fazy konserwacji, ale nie można samodzielnie uruchomić konserwacji.

Aby uzyskać więcej informacji na temat zarządzania konserwacją, która wymaga ponownego uruchomienia, zobacz Obsługa powiadomień dotyczących planowanej konserwacji przy użyciu interfejsu wiersza polecenia platformy Azure, programu PowerShell lub portalu.

Zagadnienia dotyczące dostępności podczas zaplanowanej konserwacji

Jeśli zdecydujesz się poczekać na fazę zaplanowanej konserwacji, należy rozważyć utrzymanie najwyższej dostępności maszyn wirtualnych.

Sparowane regiony

Każdy region świadczenia usługi Azure jest sparowany z innym regionem w tym samym sąsiedztwie geograficznym. Razem tworzą parę regionów. W fazie zaplanowanej konserwacji platforma Azure aktualizuje tylko maszyny wirtualne w jednym regionie pary regionów. Na przykład podczas aktualizowania maszyny wirtualnej w północno-środkowych stanach USA platforma Azure nie aktualizuje żadnej maszyny wirtualnej w południowo-środkowych stanach USA w tym samym czasie. Jednak inne regiony, takie jak North Europe, mogą być jednocześnie objęte konserwacją, podobnie jak region East US. Zrozumienie sposobu działania par regionów może pomóc w lepszym dystrybuowaniu maszyn wirtualnych między regionami. Aby uzyskać więcej informacji, zobacz Pary regionów platformy Azure.

Strefy dostępności

Strefy dostępności to unikatowe lokalizacje fizyczne w regionie świadczenia usługi Azure. Każda strefa składa się z co najmniej jednego centrum danych wyposażonego w niezależne zasilanie, chłodzenie i sieć. W celu zapewnienia odporności istnieją co najmniej trzy osobne strefy we wszystkich włączonych regionach.

Strefa dostępności to połączenie domeny błędów i domeny aktualizacji. Jeśli tworzysz co najmniej trzy maszyny wirtualne w trzech strefach w regionie świadczenia usługi Azure, maszyny wirtualne są skutecznie dystrybuowane między trzy domeny błędów i trzy domeny aktualizacji. Platforma Azure rozpoznaje to rozproszenie w domenach aktualizacji, aby upewnić się, że maszyny wirtualne w różnych strefach nie są aktualizowane w tym samym czasie.

Każda aktualizacja infrastruktury jest wdrażana strefa po strefie w obrębie jednego regionu. Można jednak mieć wdrożenie trwające w strefie 1 i jednocześnie inne wdrożenie trwające w strefie 2. Wdrożenia nie są serializowane. Jednak pojedyncze wdrożenie, które wymaga ponownego uruchomienia, wdraża tylko jedną strefę naraz, aby zmniejszyć ryzyko. Ogólnie rzecz biorąc, aktualizacje wymagające ponownego uruchomienia są unikane, gdy jest to możliwe, a platforma Azure próbuje użyć migracji na żywo lub zapewnić kontrolę klientów.

Zestawy skalowania maszyn wirtualnych

Zestawy skalowania maszyn wirtualnych w trybie orchestracji Flexible to zasób obliczeniowy platformy Azure, który pozwala połączyć skalowalność zestawów skalowania maszyn wirtualnych w trybie orchestracji Uniform z regionalnymi gwarancjami dostępności zapewnianymi przez zestawy dostępności.

Dzięki Flexible orchestration możesz wybrać, czy Twoje instancje są rozproszone między wieloma strefami, czy w domenach błędów w obrębie jednego regionu.

Zestawy dostępności i jednolite zestawy skalowania

Podczas wdrażania obciążenia na maszynach wirtualnych platformy Azure można utworzyć maszyny wirtualne w zestawie dostępności, aby zapewnić aplikacji wysoką dostępność. Za pomocą zestawów dostępności można upewnić się, że podczas awarii lub zdarzeń konserwacji, które wymagają ponownego uruchomienia, jest dostępna co najmniej jedna maszyna wirtualna.

W zestawie dostępności poszczególne maszyny wirtualne są rozmieszczone w maksymalnie 20 domenach aktualizacji. Podczas zaplanowanej konserwacji tylko jedna domena aktualizacji jest aktualizowana w danym momencie. Domeny aktualizacji nie muszą być aktualizowane sekwencyjnie.

Zestawy skalowania maszyn wirtualnych w trybie orkiestracji Uniform to zasób obliczeniowy platformy Azure, którego można używać do wdrażania zestawu identycznych maszyn wirtualnych oraz zarządzania nim jako pojedynczym zasobem. Zestaw skalowania jest automatycznie wdrażany na różnych identyfikatorach UD, takich jak maszyny wirtualne w zestawie dostępności. Podobnie jak w przypadku zestawów dostępności, w przypadku korzystania z ujednoliconych zestawów skalowania tylko jedna trasa zdefiniowana przez użytkownika jest aktualizowana w dowolnym momencie podczas zaplanowanej konserwacji.

Aby uzyskać więcej informacji na temat konfigurowania maszyn wirtualnych pod kątem wysokiej dostępności, zobacz Zarządzanie dostępnością maszyn wirtualnych dla systemu Windows lub odpowiedni artykuł dla systemu Linux.

Następne kroki

Aby zarządzać planowaną konserwacją, użyj Azure CLI, Azure PowerShell lub portalu.