Onderhoud voor virtuele machines in Azure

Van toepassing op: ✔️ Linux-VM's ✔️ Windows-VM's ✔️ Flexibele schaalsets ✔️ Uniforme schaalsets

Van tijd tot tijd voert Azure updates van zijn platform uit om de betrouwbaarheid, prestaties en veiligheid te verbeteren van de host-infrastructuur voor virtuele machines. Het doel van deze updates behelst zowel het uitvoeren van softwarepatches voor onderdelen in de hostomgeving als het upgraden van netwerkonderdelen of het buiten gebruik stellen van hardware.

Updates zijn zelden van invloed op de gehoste VM's. Wanneer updates een effect hebben, kiest Azure de minst impactvolle methode voor updates:

• Als de update geen herstart vereist, wordt de VM onderbroken terwijl de host wordt bijgewerkt of wordt de VM live gemigreerd naar een al bijgewerkte host.

• Als de update opnieuw moet worden opgestart, Azure u op de hoogte brengt van het geplande onderhoud. Azure biedt ook een tijdvenster waarin u het onderhoud zelf kunt starten, op een tijdstip dat voor u uitkomt. Het zelfonderhoudsvenster is afhankelijk van het type onderhoud:

  • Buitendienststelling van hardware: Het periode voor zelfonderhoud is doorgaans 14 dagen.
  • Hostonderhoud: het venster voor zelfonderhoud is doorgaans 35 dagen, tenzij het onderhoud dringend is.

  Azure investeert in technologieën om het aantal gevallen te verminderen waarin gepland platformonderhoud vereist dat de VM's opnieuw worden opgestart. Zie Meldingen over gepland onderhoud verwerken met behulp van de Azure CLI, PowerShell of portal voor instructies voor het beheren van gepland onderhoud.

Op deze pagina wordt beschreven hoe Azure beide typen onderhoud uitvoert. Zie De beschikbaarheid van VM's voor Windows of het bijbehorende artikel voor Linux beheren voor meer informatie over niet-geplande gebeurtenissen (storingen).

Binnen een VIRTUELE machine kunt u meldingen ontvangen over gepland onderhoud met behulp van geplande gebeurtenissen voor Windows of Linux.

Onderhoud waarvoor opnieuw opstarten niet nodig is

De meeste platformupdates hebben geen invloed op vm's van klanten. Wanneer een update zonder impact niet mogelijk is, kiest Azure het updatemechanisme dat het minst van invloed is op de vm's van klanten.

Wanneer onderhoud nodig is dat gevolgen heeft voor de VM, wordt dit bijna altijd uitgevoerd door middel van een VM-pauze van minder dan 10 seconden. In zeldzame gevallen, niet meer dan één keer per 18 maanden voor VM-grootten voor algemeen gebruik, gebruikt Azure een mechanisme waarmee de VIRTUELE machine ongeveer 30 seconden wordt onderbroken. Na een onderbrekingsbewerking wordt de klok van de VIRTUELE machine automatisch gesynchroniseerd wanneer deze wordt hervat.

Onderhoud met geheugenbehoud werkt voor meer dan 90 procent van de Virtuele Azure-machines. Het werkt niet voor de G-, L-, N- en H-serie. Zie voor meer informatie welke VM-grootten ondersteuning bieden voor onderhoud met geheugenbehoud. Azure maakt steeds vaker gebruik van technologieën voor livemigratie en verbetert onderhoudsmechanismen met geheugenbehoud om de onderbrekingsduur te verminderen.

Deze onderhoudsbewerkingen waarvoor opnieuw opstarten niet nodig is, worden één foutdomein tegelijk toegepast. Ze stoppen als ze statuswaarschuwingen ontvangen van platformbewakingstools. Onderhoudsbewerkingen waarvoor geen herstart is vereist, kunnen gelijktijdig plaatsvinden in gekoppelde regio's of Beschikbaarheidszones. Voor een bepaalde wijziging wordt de implementatie meestal gesequentieerd over Beschikbaarheidszones en tussen regioparen, maar er kan sprake zijn van overlapping aan de staart.

Deze typen updates kunnen van invloed zijn op sommige toepassingen. Wanneer de VM live wordt gemigreerd naar een andere host, kunnen sommige gevoelige workloads gedurende de paar minuten voorafgaand aan het onderbreken van de VM een licht prestatieverlies vertonen. Probeer geplande gebeurtenissen voor Windows of Linux te gebruiken voor dergelijke toepassingen om het onderhoud van vm's voor te bereiden en de impact tijdens azure-onderhoud te verminderen.

Voor een grotere controle over alle onderhoudsactiviteiten, inclusief updates zonder impact en zonder opnieuw opstarten, kunt u een onderhoudsconfiguratiefunctie maken. Als u een onderhoudsconfiguratie maakt, hebt u de mogelijkheid om alle platformupdates over te slaan en de updates op uw keuze toe te passen. Zie Platformupdates beheren met onderhoudsconfiguraties voor meer informatie.

Livemigratie

Livemigratie is een bewerking die geen herstart vereist en die geheugen voor de virtuele machine behoudt. Het veroorzaakt een pauze of bevriezen, meestal niet langer dan 5 seconden. Met uitzondering van G-, L-, N- en H-serie komen alle IaaS-VM's (Infrastructure as a Service) in aanmerking voor livemigratie. Livemigratie is beschikbaar voor de meeste SKU's uit de M-serie. In aanmerking komende VM's vertegenwoordigen meer dan 90 procent van de IaaS-VM's die zijn geïmplementeerd in de Azure-vloot.

Notitie

U ontvangt geen melding in Azure Portal voor livemigratiebewerkingen die zijn geprobeerd of waarvoor geen herstart is vereist. Als u een lijst wilt zien met livemigraties waarvoor geen herstart is vereist, voert u een query uit op geplande gebeurtenissen.

Livemigratie wordt naar beste kunnen uitgevoerd. In sommige zeldzame gevallen kan livemigratie niet slagen en wordt de virtuele machine, als dat nodig is, voorafgaand aan de melding door de service hersteld. Livemigratie is geen gegarandeerd of verzekerd proces.

Het Azure-platform activeert livemigratie in de volgende scenario's:

• Gepland onderhoud
• Hardwarestoring
• Toewijzingsoptimalisaties

Sommige scenario's voor gepland onderhoud maken gebruik van livemigratie en u kunt geplande gebeurtenissen gebruiken om vooraf te weten wanneer livemigratiebewerkingen worden gestart.

Livemigratie kan ook worden gebruikt om VM's te verplaatsen wanneer Azure Machine Learning-algoritmen een dreigende hardwarefout voorspellen of optimalisatie van VM-toewijzingen. Zie Voor meer informatie over voorspellende modellering waarmee exemplaren van gedegradeerde hardware worden gedetecteerd, de tolerantie van azure-VM's verbeteren met voorspellende machine learning en livemigratie. Livemigratiemeldingen worden weergegeven in Azure Portal in de logboeken Monitor en Service Health en in Geplande gebeurtenissen als u deze services gebruikt.

Robuustheid van TCP-verbindingen tijdens live migratie

Toepassingen die langdurige TCP-verbindingen onderhouden, zoals databaseservers, berichtbrokers en cachelagen, kunnen tijdens livemigratie verbindingonderbreking ondervinden. Hoewel de VM-pauze doorgaans minder dan 5 seconden is, kan het gedrag van de TCP-stack tijdens en na de pauze de hersteltijd op toepassingsniveau verlengen als dit niet is opgelost.

Hoe livemigratie van invloed is op TCP-verbindingen:

• Tijdens de pauze worden TCP-segmenten tijdens de vlucht niet bevestigd door de migrerende VM.
• De verzendende zijde (client of statustest van de load balancer) start TCP-hertransmissie met exponentiële back-off.
• Azure Standard Load Balancer verzendt een TCP RST naar niet-actieve verbindingen die de geconfigureerde time-out voor inactiviteit overschrijden. Voor actieve verbindingen met gegevens die nog worden verzonden, verzendt de load balancer echter geen TCP RST tijdens de migratiepauze. De verbinding blijft geopend, maar reageert niet en de client heeft geen direct signaal van storing.
• Zonder afstemming op toepassingsniveau kan het standaardgedrag van TCP-hertransmissie (tcp_retries2 = 15 op Linux) de detectie van verbindingsfouten met ongeveer 15 minuten vertragen.

Important

De impact is aanzienlijk afhankelijk van de standaardinstellingen van het besturingssysteem. In Linux wordt tcp_retries2 standaard ingesteld op 15, wat resulteert in ongeveer 15 minuten voordat een dode verbinding wordt gedetecteerd. Op Windows wordt TcpMaxDataRetransmissions standaard ingesteld op 5, waardoor de detectietijd wordt beperkt tot ongeveer 25-50 seconden zonder afstemming. De oplossingen die in dit artikel worden beschreven, zijn het meest essentieel voor linux-workloads.

Notitie

Voor HTTP/1.1-workloads is de impact doorgaans beperkt: alleen verzoeken die op het moment van de migratie in behandeling zijn, worden beïnvloed, en omdat HTTP/1.1-clients geen pipelining gebruiken over keep-alive-verbindingen, herstellen ze zich snel door voor het volgende verzoek een nieuwe verbinding te openen. Voor HTTP/2 is de straalstraal breder omdat meerdere gelijktijdige streams één TCP-verbinding delen.

Wanneer de load balancer werkt in de L4 TLS-passthrough-modus, kan de load balancer geen foutmeldingen inspecteren, opnieuw proberen of injecteren in de versleutelde stream. In deze configuratie is de client alleen verantwoordelijk voor het detecteren en herstellen van de vastgelopen verbinding.

Beperk de impact met implementaties met meerdere instanties:

Voordat u beperkingen op TCP-niveau toepast, moet u rekening houden met de architectuurbasislijn. Live migration heeft invloed op één VM tegelijk binnen een beschikbaarheidsset of schaalset voor virtuele machines. Het spreiden van verbindingen over meerdere back-endinstanties beperkt de impact van een enkele migratiegebeurtenis:

• Een schaalset met drie exemplaren betekent dat elke migratiegebeurtenis ten hoogste één derde van de actieve verbindingen beïnvloedt.
• Implementatie in Beschikbaarheidszones zorgt ervoor dat migraties in verschillende zones niet overlappen.
• Clients met verbindingsgroepen die zijn gedistribueerd over meerdere back-ends, kunnen sneller worden hersteld, omdat niet-beïnvloede verbindingen aanvragen onmiddellijk blijven verwerken.

Tijdens de VM-pauze mislukken ook de statuscontroles van Azure Standard Load Balancer voor de onderbroken back-end. De load balancer markeert de back-end als beschadigd binnen ongeveer 10 seconden (twee opeenvolgende testfouten met het standaardinterval van 5 seconden) en stopt de routering van nieuwe verbindingen naar de back-end. Deze voorwaarde betekent dat nieuwe verbindingen op natuurlijke wijze worden beveiligd. De TCP-oplossingen die in dit artikel worden beschreven, hebben betrekking op bestaande verbindingen die al tot stand zijn gebracht voordat de migratie werd gestart.

Aanbevolen mitigerende maatregelen:

De volgende mitigerende maatregelen zijn aanvullend. Wanneer ze samen worden geïmplementeerd, verminderen ze de impact van een livemigratiegebeurtenis van minuten van potentiële downtime tot seconden van automatisch herstel.

Priority	Mitigation	Inspanning	Impact
1	Stel TCP_USER_TIMEOUT op socketniveau in	Laag	Vermindert de detectie van dode verbindingen van ~15 minuten tot 30 seconden
2	Abonneren op geplande gebeurtenissen	Gemiddeld	Maakt proactieve afvoer van verbindingen mogelijk voordat het blokkeren plaatsvindt
3	TCP-keepalive-parameters afstemmen	Laag	Detecteert niet-actieve verbindingen die verlopen na de migratie
4	Logica voor opnieuw proberen aan clientzijde implementeren	Gemiddeld	Biedt tolerantie, ongeacht de hoofdoorzaak

Mitigatie 1: TCP_USER_TIMEOUT (snelste detectie)

TCP_USER_TIMEOUT bepaalt hoe lang de kernel wacht op bevestiging van verzonden gegevens voordat een verbinding is uitgeschakeld. Als u dit instelt op 30 seconden (30000 ms) per socket, vermindert u de detectietijd aanzienlijk.

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

U kunt ook het aantal systeembrede hertransmissies verminderen:

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

Tip

Ingesteld TCP_USER_TIMEOUT op sdk- of socketniveau in plaats van systeembreed. Een waarde van 30 seconden is een goed uitgangspunt. Waarden onder de 10 seconden kunnen vals-positieve meldingen veroorzaken bij normale netwerkschommelingen.

Aandachtspunten voor Windows:

De TCP_USER_TIMEOUT socketoptie is specifiek voor Linux. Op Windows wordt het gedrag van TCP-hertransmissie anders beheerd:

• Windows gebruikt standaard 5 hertransmissies (TcpMaxDataRetransmissions), wat al ongeveer 25-50 seconden detectietijd biedt zonder enige afstemming.
• Als u de detectietijd op Windows verder wilt verminderen, past u het register aan:

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

Wanneer TcpMaxDataRetransmissions is ingesteld op 3, wordt de detectietijd verkort tot ongeveer 10-20 seconden, afhankelijk van de initiële time-out voor hertransmissie.

Notitie

In tegenstelling tot Linux biedt Windows geen equivalent per socket van TCP_USER_TIMEOUT. De registerinstelling is van toepassing op alle TCP-verbindingen op het systeem. Voor gedetailleerde controle over Windows kunt u gebruikmaken van time-outs op toepassingsniveau en statuscontroles (Beperking 4).

Risicobeperking 2: Geplande gebeurtenissen (proactieve afvoer)

De service Geplande gebeurtenissen biedt vooraf kennisgeving voordat een livemigratie begint. Toepassingen kunnen luisteren naar Freeze gebeurtenissen en proactief verbindingen leegmaken voordat de pauze plaatsvindt.

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

Een livemigratiegebeurtenis wordt weergegeven als:

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

Wanneer een Freeze gebeurtenis wordt gedetecteerd:

1. Stop met het accepteren van nieuwe verbindingen op het betreffende knooppunt.
2. Bestaande verbindingen afbouwen (clients een signaal geven om opnieuw verbinding te maken met een ander knooppunt).
3. Wacht tot de lopende bewerkingen zijn voltooid, met een beperkte time-out.
4. Bevestig de gebeurtenis desgewenst door de EventId terug te plaatsen.

Notitie

De voorafgaande kennisgevingsperiode is doorgaans 15 minuten, maar kan in zeldzame gevallen zo kort zijn als 30 seconden. Een pollfrequentie van één keer per seconde wordt aanbevolen voor productieworkloads.

Maatregel 3: afstemming van TCP-keepalive

TCP-keepalive-tests detecteren verbindingen die niet actief worden na de migratiegebeurtenis:

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)

Met deze instellingen wordt een verlopen verbinding binnen 60 seconden gedetecteerd (30 + 10 x 3). Keepalive-probes tellen ook als activiteit voor de inactiviteitstime-out van de Standard Load Balancer, waardoor wordt voorkomen dat de load balancer inactieve verbindingen onafhankelijk time-out.

Mitigatie 4: Retrylogica aan de clientzijde

Opnieuw verbinding maken op toepassingsniveau en logica voor opnieuw proberen zorgt voor herstel, ongeacht de methode voor foutdetectie:

1. Verbindingsfout detecteren (time-out, RST of verbinding geweigerd).
2. Sluit de dode verbinding en verwijder deze uit de verbindingsgroep.
3. Open een nieuwe verbinding met hetzelfde of een ander knooppunt.
4. Voer de bewerking opnieuw uit met een exponentieel toenemende wachttijd.

Schakel voor database-SDK's en verbindingsgroepen periodieke statuscontroles in (bijvoorbeeld elke 10-15 seconden een lichtgewicht ping) om verbindingen proactief te valideren.

Configuratie van verbindingsgroep:

Connectionpools die langdurige verbindingen in stand houden, hebben baat bij een instelling voor de maximale levensduur. Deze instelling dwingt periodieke recycling van verbindingen af, zodat er geen enkele verbinding een niet-gebonden risico van toekomstige migratiegebeurtenissen verzamelt:

Pooltechnologie	Setting	Aanbevolen waarde
HikariCP (Java)	maxLifetime	1800000 (30 minuten)
PgBouncer	server_lifetime	1800 (30 minuten)
Gaan database/sql	SetConnMaxLifetime	30 * tijd. Minuut
Node.js (pg-pool)	idleTimeoutMillis	30000 (30 seconden inactief verwijderen; maximale levensduur vereist aangepaste logica)
.NET SqlConnection	Verbindingsreeks: Connection Lifetime	1800 (30 minuten)

Het instellen van een maximale levensduur van 30 minuten betekent dat verbindingen, zelfs zonder actieve statuscontroles, natuurlijk worden vervangen voordat ze lange perioden van niet-gedetecteerde veroudering kunnen verzamelen.

Bewaking en waarneembaarheid:

Gebruik de volgende methoden om de impact van livemigratiegebeurtenissen op TCP-verbindingen te detecteren en te meten:

• Azure Monitor VM-beschikbaarheidsmetriek (Preview): Daalt naar 0 tijdens het pauzeren van de VM. Maak een waarschuwingsregel VmAvailabilityMetric met een drempelwaarde van minder dan 1 om migratie-gebeurtenissen te detecteren.
• Activiteitenlogboek voor geplande gebeurtenissen: Gebeurtenissen voor livemigratie worden weergegeven in het activiteitenlogboek onder de Microsoft.Compute-provider met de bewerkingsnaam Microsoft.Compute/virtualMachines/liveMigration/action, of als Freeze-gebeurtenissen wanneer ze worden opgevraagd via de Metadata Service.
• Verbindingsfoutpercentage op toepassingsniveau: Controleer het opnieuw instellen van TCP-verbindingen, time-outs en het aantal nieuwe verbindingen in de metrische gegevens van uw toepassing. Een piek in verbindingsfouten, samenhangend met een dip in de VM-beschikbaarheid, bevestigt de impact van de migratie.
• TCP-retransmissietellers: Controleer /proc/net/netstat in Linux het veld TCPTimeouts of gebruik ss -ti om het aantal nieuwe doorgiften op afzonderlijke sockets te observeren. Verhoogde hertransmissies tijdens een bekend onderhoudsvenster geven aan dat verbindingen zijn beïnvloed.

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

Als u een basislijn voor deze metrische gegevens tot stand brengt tijdens de normale werking, kunt u eenvoudig de impact van migratie-gebeurtenissen kwantificeren en controleren of uw risicobeperking werkt zoals verwacht.

Workloads met nultolerantie voor onderbreking van livemigratie

Voor workloads die geen onderbreking van livemigratie kunnen verdragen, kunt u overwegen om Azure Toegewezen hosts met onderhoudsconfiguraties te gebruiken. Toegewezen hosts bieden u controle over wanneer onderhoud op hostniveau plaatsvindt, waardoor onverwachte livemigratiegebeurtenissen worden geëlimineerd.

Onderhoud waarvoor opnieuw opstarten is vereist

In het zeldzame geval dat VM's opnieuw moeten worden opgestart voor gepland onderhoud, ontvangt u van tevoren een melding. Gepland onderhoud heeft twee fasen: de selfservicefase en een geplande onderhoudsfase.

Tijdens de selfservicefase, die doorgaans vier weken duurt, start u het onderhoud op uw VM's. Als onderdeel van de selfservice kunt u elke VIRTUELE machine opvragen om de status en het resultaat van uw laatste onderhoudsaanvraag te bekijken.

Notitie

Voor VM-reeksen die geen ondersteuning bieden voor livemigratie, kunnen lokale (tijdelijke) schijven verloren gaan tijdens de onderhoudsgebeurtenissen. Bekijk elke afzonderlijke VM-serie voor informatie over of livemigratie wordt ondersteund.

Wanneer u selfserviceonderhoud start, wordt uw VM opnieuw geïmplementeerd naar een al bijgewerkt knooppunt. Omdat de virtuele machine opnieuw wordt geïmplementeerd, gaat de tijdelijke schijf verloren en worden openbare dynamische IP-adressen bijgewerkt die zijn gekoppeld aan de interface van het virtuele netwerk.

Als er een fout optreedt tijdens selfserviceonderhoud, stopt de bewerking, wordt de VM niet bijgewerkt en krijgt u de optie om het selfserviceonderhoud opnieuw uit te voeren.

Wanneer de selfservicefase afloopt, begint de geplande onderhoudsfase . Tijdens deze fase kunt u nog steeds een query uitvoeren op de onderhoudsfase, maar u kunt het onderhoud niet zelf starten.

Zie Meldingen over gepland onderhoud verwerken met behulp van de Azure CLI, PowerShell of portal voor meer informatie over het beheren van onderhoud waarvoor opnieuw opstarten is vereist.

Overwegingen voor beschikbaarheid tijdens gepland onderhoud

Als u besluit te wachten tot de geplande onderhoudsfase, moet u rekening houden met de hoogste beschikbaarheid van uw VM's.

Gekoppelde regio's

Elke Azure-regio wordt gekoppeld aan een andere regio binnen dezelfde geografische omgeving. Samen vormen ze een regiopaar. Tijdens de geplande onderhoudsfase werkt Azure alleen de VM's in één regio van een regiopaar bij. Als Azure bijvoorbeeld een VM in North Central US bijwerkt, werkt het niet tegelijkertijd een VM in South Central US bij. Tegelijkertijd met VS - oost kan er echter wel onderhoud plaatsvinden in andere regio's, zoals Europa - noord. Als u begrijpt hoe regioparen werken, kunt u uw VM's beter verdelen over regio's. Zie Azure-regioparen voor meer informatie.

Beschikbaarheidszones

Beschikbaarheidszones zijn unieke, fysieke locaties binnen een Azure-regio. Elke zone bestaat uit een of meer datacenters met onafhankelijke stroomvoorziening, koeling en netwerken. Om robuustheid te garanderen, zijn er in alle ingeschakelde regio's minimaal drie afzonderlijke zones.

Een beschikbaarheidszone is een combinatie van een foutdomein en een updatedomein. Als u drie of meer VM's in drie zones in een Azure-regio maakt, worden uw VM's effectief verdeeld over drie foutdomeinen en drie updatedomeinen. Het Azure-platform herkent deze verdeling over updatedomeinen om ervoor te zorgen dat virtuele machines in verschillende zones niet op hetzelfde moment worden bijgewerkt.

Elke infrastructuurupdate implementeert zone per zone, binnen één regio. Maar u kunt implementatie in zone 1 uitvoeren en tegelijkertijd verschillende implementaties uitvoeren in zone 2. Implementaties worden niet allemaal geserialiseerd. Maar één uitrol waarvoor een herstart nodig is, wordt telkens naar slechts één zone uitgerold om het risico te beperken. Over het algemeen worden updates waarvoor opnieuw opstarten is vereist, vermeden wanneer dat mogelijk is en probeert Azure livemigratie te gebruiken of klanten controle te bieden.

Schaalsets voor virtuele machines

Schaalsets voor virtuele machines in de Flexible-indelingsmodus zijn een Azure-rekenresource waarmee u de schaalbaarheid van schaalsets voor virtuele machines in de uniforme indelingsmodus kunt combineren met de regionale beschikbaarheidsgaranties van beschikbaarheidssets.

Met flexibele orkestratie kunt u kiezen of uw instanties worden verdeeld over meerdere zones of over foutdomeinen binnen één regio.

Beschikbaarheidssets en uniforme schaalsets

Wanneer u een workload implementeert op Azure-VM's, kunt u de VM's binnen een beschikbaarheidsset maken om hoge beschikbaarheid voor uw toepassing te bieden. Met behulp van beschikbaarheidssets kunt u ervoor zorgen dat tijdens een storing of onderhoudsevenementen waarvoor opnieuw opstarten is vereist, ten minste één VM beschikbaar is.

Binnen een beschikbaarheidsset worden afzonderlijke VM's verdeeld over maximaal 20 updatedomeinen. Tijdens gepland onderhoud wordt op elk gewenst moment slechts één updatedomein bijgewerkt. Updatedomeinen worden niet noodzakelijkerwijs opeenvolgend bijgewerkt.

Virtuele-machineschaalsets in de uniformindelingsmodus zijn een Azure-rekenresource die u kunt gebruiken om een set identieke VM's als één resource te implementeren en beheren. De schaalset wordt automatisch over de UD's geïmplementeerd, net als VM's in een beschikbaarheidsset. Net als bij beschikbaarheidssets wordt, wanneer u Uniform scale sets gebruikt, tijdens gepland onderhoud op een bepaald moment slechts één UD bijgewerkt.

Zie De beschikbaarheid van uw VM's voor Windows of het bijbehorende artikel voor Linux beheren voor meer informatie over het instellen van uw VM's voor hoge beschikbaarheid.

Volgende stappen

Gebruik de Azure CLI, Azure PowerShell of de portal om gepland onderhoud te beheren.