Controlelijst voor tolerantie voor specifieke Azure-services

Flexibiliteit is het vermogen van een systeem om te herstellen van fouten en te kunnen blijven functioneren. Elke technologie heeft zijn eigen specifieke foutmodi, die u moet overwegen bij het ontwerpen en implementeren van uw toepassing. Gebruik deze controlelijst om de tolerantieoverwegingen voor specifieke Azure-services te bekijken. Zie Betrouwbare Azure-toepassingen ontwerpen voor meer informatie over het ontwerpen van robuuste toepassingen.

App Service

Gebruik de Standard- of Premium-laag. Deze lagen ondersteunen faseringssites en geautomatiseerde back-ups. Zie het uitgebreide overzicht van Azure-app Service-abonnementen voor meer informatie

Vermijd omhoog of omlaag schalen. Selecteer in plaats daarvan een laag en instantiegrootte die voldoet aan uw prestatievereisten onder normale belasting en schaal vervolgens de exemplaren uit om wijzigingen in het verkeersvolume af te handelen. Omhoog en omlaag schalen kan ertoe leiden dat een toepassing opnieuw wordt opgestart.

Sla de configuratie op als app-instellingen. Gebruik app-instellingen voor het opslaan van configuratie-instellingen als app-instellingen. Definieer de instellingen in uw Resource Manager-sjablonen of gebruik PowerShell, zodat u ze kunt toepassen als onderdeel van een geautomatiseerd implementatie-/updateproces, dat betrouwbaarder is. Zie Web-apps configureren in Azure-app Service voor meer informatie.

Maak afzonderlijke App Service-plannen voor productie en test. Gebruik geen sites in uw productie-implementatie om te testen. Alle apps binnen hetzelfde App Service-plan delen dezelfde VM-exemplaren. Als u productie- en testimplementaties in hetzelfde plan plaatst, kan dit een negatieve invloed hebben op de productie-implementatie. Belastingstests kunnen bijvoorbeeld de live productiesite verminderen. Door testimplementaties in een afzonderlijk plan te plaatsen, isoleert u deze van de productieversie.

Scheid web-apps van web-API's. Als uw oplossing zowel een web-front-end als een web-API heeft, kunt u deze opsplitsen in afzonderlijke App Service-apps. Met dit ontwerp kunt u de oplossing eenvoudiger op basis van workload opsplitsen. U kunt de web-app en de API uitvoeren in afzonderlijke App Service-plannen, zodat ze onafhankelijk kunnen worden geschaald. Als u dat schaalbaarheidsniveau in eerste instantie niet nodig hebt, kunt u de apps implementeren in hetzelfde plan en ze later verplaatsen naar afzonderlijke plannen, indien nodig.

Zone-redundante App Service-plannen implementeren. In ondersteunde regio's kunnen App Service-plannen worden geïmplementeerd als zone-redundant, wat betekent dat de exemplaren automatisch worden verdeeld over beschikbaarheidszones. App Service distribueert automatisch verkeer tussen de zones en verwerkt failover als een zone een storing ondervindt. Zie App Service migreren naar ondersteuning voor beschikbaarheidszones voor meer informatie.

Vermijd het gebruik van de back-upfunctie van App Service om back-ups te maken van Azure SQL-databases. Gebruik in plaats daarvan geautomatiseerde back-ups van SQL Database. App Service-back-up exporteert de database naar een SQL BACPAC-bestand, dat DTU's kost.

Implementeren in een staging-site. Maak een implementatiesite voor fasering. Implementeer toepassingsupdates naar de staging-site en controleer de implementatie voordat u deze in productie wisselt. Dit vermindert de kans op een slechte update in productie. Het zorgt er ook voor dat alle exemplaren worden opgewarmd voordat ze in productie worden gewisseld. Veel toepassingen hebben een aanzienlijke opwarm- en koude starttijd. Zie Faseringsomgevingen instellen voor web-apps in Azure-app Service voor meer informatie.

Maak een implementatiesite voor de laatst bekende goede implementatie (LKG). Wanneer u een update naar productie implementeert, verplaatst u de vorige productie-implementatie naar de LKG-site. Hierdoor is het eenvoudiger om een slechte implementatie terug te draaien. Als u later een probleem ontdekt, kunt u snel terugkeren naar de LKG-versie. Zie Basic-webtoepassing voor meer informatie.

Schakel diagnostische logboekregistratie in, waaronder logboekregistratie van toepassingen en webserverlogboeken. Logboekregistratie is belangrijk voor bewaking en diagnose. Zie Diagnostische logboekregistratie inschakelen voor web-apps in Azure-app Service

Meld u aan bij blobopslag. Dit maakt het gemakkelijker om de gegevens te verzamelen en te analyseren.

Maak een afzonderlijk opslagaccount voor logboeken. Gebruik niet hetzelfde opslagaccount voor logboeken en toepassingsgegevens. Dit helpt voorkomen dat logboekregistratie de prestaties van toepassingen vermindert.

Prestaties bewaken. Gebruik een service voor prestatiebewaking, zoals New Relic of Application Insights , om de prestaties en het gedrag van toepassingen onder belasting te bewaken. Met prestatiebewaking krijgt u realtime inzicht in de toepassing. Hiermee kunt u problemen diagnosticeren en hoofdoorzaakanalyses van fouten uitvoeren.

Azure-belastingsverdeling

Selecteer Standard-SKU. Standard Load Balancer biedt een dimensie van betrouwbaarheid die basic niet doet: die van beschikbaarheidszones en zonetolerantie. Dit betekent dat wanneer een zone uitvalt, uw zone-redundante Standard Load Balancer niet wordt beïnvloed. Dit zorgt ervoor dat uw implementaties bestand zijn tegen zonefouten binnen een regio. Daarnaast biedt Standard Load Balancer ondersteuning voor wereldwijde taakverdeling, zodat uw toepassing ook niet wordt beïnvloed door regiofouten.

Richt ten minste twee exemplaren in. Implementeer Azure LB met ten minste twee exemplaren in de back-end. Eén exemplaar kan leiden tot een single point of failure. Als u wilt bouwen voor schaal, wilt u mogelijk LB koppelen aan virtuele-machineschaalsets.

Gebruik uitgaande regels. Uitgaande regels zorgen ervoor dat u niet te maken hebt met verbindingsfouten als gevolg van uitputting van de SNAT-poort. Meer informatie over uitgaande connectiviteit. Hoewel uitgaande regels helpen bij het verbeteren van de oplossing voor kleine tot middelgrote implementaties, raden we voor productieworkloads aan Standard Load Balancer of een subnetimplementatie met VNet NAT te koppelen.

Application Gateway

Richt ten minste twee exemplaren in. Implementeer Application Gateway met ten minste twee exemplaren. Eén exemplaar is een single point of failure. Gebruik twee of meer exemplaren voor redundantie en schaalbaarheid. Als u in aanmerking wilt komen voor de SLA, moet u twee of meer middelgrote of grotere instanties inrichten.

Azure Cosmos DB

Zoneredundantie configureren. Wanneer u zoneredundantie gebruikt, repliceert Azure Cosmos DB synchroon alle schrijfbewerkingen in beschikbaarheidszones. Er wordt automatisch een failover uitgevoerd in het geval van een zone-storing. Zie Hoge beschikbaarheid bereiken met Azure Cosmos DB voor meer informatie.

Repliceer de database tussen regio's. Met Azure Cosmos DB kunt u een willekeurig aantal Azure-regio's koppelen aan een Azure Cosmos DB-databaseaccount. Een Azure Cosmos DB-database kan één schrijfregio en meerdere leesregio's hebben. Als er een fout optreedt in de schrijfregio, kunt u lezen vanuit een andere replica. De client-SDK verwerkt dit automatisch. U kunt ook een failover van de schrijfregio naar een andere regio uitvoeren. Zie Distribute data globally with Azure Cosmos DB (Gegevens wereldwijd distribueren met Azure Cosmos DB) voor meer informatie.

Event Hubs

Gebruik controlepunten. Een gebeurtenisgebruiker moet de huidige positie naar permanente opslag schrijven met een vooraf gedefinieerd interval. Als de consument op die manier een fout ondervindt (bijvoorbeeld als de consument vastloopt of de host uitvalt), kan een nieuw exemplaar het lezen van de stream vanaf de laatst vastgelegde positie hervatten. Zie Gebeurtenisgebruikers voor meer informatie.

Afhandelen van dubbele berichten. Als een gebeurtenisconsumer mislukt, wordt de verwerking van berichten hervat vanaf het laatst opgenomen controlepunt. Alle berichten die al na het laatste controlepunt zijn verwerkt, worden opnieuw verwerkt. Daarom moet uw berichtverwerkingslogica idempotent zijn of moet de toepassing berichten kunnen ontdubbelen.

Uitzonderingen verwerken.. Een gebeurtenisconsumer verwerkt doorgaans een batch berichten in een lus. U moet uitzonderingen in deze verwerkingslus verwerken om te voorkomen dat een hele batch berichten verloren gaat als één bericht een uitzondering veroorzaakt.

Gebruik een wachtrij met dode letters. Als het verwerken van een bericht resulteert in een niet-tijdelijke fout, plaatst u het bericht in een wachtrij met dode letters, zodat u de status kunt bijhouden. Afhankelijk van het scenario kunt u het bericht later opnieuw proberen, een compenserende transactie toepassen of een andere actie ondernemen. Event Hubs heeft geen ingebouwde functionaliteit voor wachtrijen met dode letters. U kunt Azure Queue Storage of Service Bus gebruiken om een wachtrij met dode letters te implementeren of Azure Functions of een ander mechanisme voor gebeurtenissen te gebruiken.

Zoneredundantie configureren. Wanneer zoneredundantie is ingeschakeld voor uw naamruimte, repliceert Event Hubs automatisch wijzigingen tussen meerdere beschikbaarheidszones. Als één beschikbaarheidszone mislukt, vindt failover automatisch plaats. Zie Beschikbaarheidszones voor meer informatie.

Implementeer herstel na noodgevallen door een failover uit te voeren naar een secundaire Event Hubs-naamruimte. Zie Azure Event Hubs Geo-disaster recovery voor meer informatie.

Azure Cache voor Redis

Zoneredundantie configureren. Wanneer zoneredundantie is ingeschakeld in uw cache, verspreidt Azure Cache voor Redis de virtuele machines die uw cache hosten over meerdere beschikbaarheidszones. Zoneredundantie biedt hoge beschikbaarheid en fouttolerantie in het geval van een storing in het datacenter. Zie Zoneredundantie inschakelen voor Azure Cache voor Redis voor meer informatie.

Geo-replicatie configureren. Geo-replicatie biedt een mechanisme voor het koppelen van twee Premium-laag Azure Cache voor Redis exemplaren. Gegevens die naar de primaire cache worden geschreven, worden gerepliceerd naar een secundaire cache met het kenmerk Alleen-lezen. Zie Geo-replicatie configureren voor Azure Cache voor Redis voor meer informatie

Configureer gegevenspersistentie. Met Redis-persistentie kunt u in de Redis-cache opgeslagen gegevens persistent maken. U kunt ook momentopnamen maken en een back-up maken van de gegevens, die u kunt laden in geval van een hardwarefout. Zie Voor meer informatie het configureren van gegevenspersistentie voor een Premium-laag Azure Cache voor Redis

Als u Azure Cache voor Redis gebruikt als een tijdelijke gegevenscache en niet als permanente opslag, zijn deze aanbevelingen mogelijk niet van toepassing.

Cognitive Search

Richt meer dan één replica in. Gebruik ten minste twee replica's voor hoge beschikbaarheid van leesbewerkingen of drie voor hoge beschikbaarheid van lezen/schrijven.

Zoneredundantie gebruiken. U kunt Cognitive Search-replica's implementeren in meerdere beschikbaarheidszones. Deze aanpak helpt uw service om operationeel te blijven, zelfs wanneer er storingen in het datacenter optreden. Zie Betrouwbaarheid in Azure Cognitive Search voor meer informatie

Indexeerfuncties configureren voor implementaties in meerdere regio's. Als u een implementatie met meerdere regio's hebt, kunt u de opties voor continuïteit in indexeren overwegen.

• Als de gegevensbron geo-gerepliceerd is, moet u in het algemeen elke indexeerfunctie van elke regionale Azure Cognitive Search-service naar de lokale gegevensbronreplica verwijzen. Deze benadering wordt echter niet aanbevolen voor grote gegevenssets die zijn opgeslagen in Azure SQL Database. De reden hiervoor is dat Azure Cognitive Search geen incrementele indexering kan uitvoeren vanuit secundaire SQL Database-replica's, alleen van primaire replica's. Wijs in plaats daarvan alle indexeerfuncties naar de primaire replica. Wijs na een failover de Indexeerfuncties van Azure Cognitive Search aan op de nieuwe primaire replica.

• Als de gegevensbron niet geografisch gerepliceerd is, wijst u meerdere indexeerfuncties aan op dezelfde gegevensbron, zodat Azure Cognitive Search-service continu en onafhankelijk van de gegevensbron indexeert. Zie overwegingen voor prestaties en optimalisatie van Azure Search voor meer informatie.

Service Bus

Gebruik de Premium-laag voor productieworkloads. Service Bus Premium Messaging biedt toegewezen en gereserveerde verwerkingsresources en geheugencapaciteit ter ondersteuning van voorspelbare prestaties en doorvoer. De Premium Messaging-laag biedt u ook toegang tot nieuwe functies die in eerste instantie alleen beschikbaar zijn voor Premium-klanten. U kunt het aantal berichteneenheden bepalen op basis van verwachte workloads.

Afhandelen van dubbele berichten. Als een uitgever onmiddellijk na het verzenden van een bericht mislukt of netwerk- of systeemproblemen ondervindt, kan het foutloos mislukken om vast te leggen dat het bericht is bezorgd en kan hetzelfde bericht twee keer naar het systeem worden verzonden. Service Bus kan dit probleem afhandelen door dubbele detectie in te schakelen. Zie Detectie van duplicaten voor meer informatie.

Uitzonderingen verwerken. Berichten-API's genereren uitzonderingen wanneer een gebruikersfout, configuratiefout of andere fout optreedt. De clientcode (afzenders en ontvangers) moet deze uitzonderingen in hun code verwerken. Dit is vooral belangrijk bij batchverwerking, waarbij uitzonderingsafhandeling kan worden gebruikt om te voorkomen dat een hele batch berichten verloren gaat. Zie Service Bus Messaging-uitzonderingen voor meer informatie.

Beleid voor opnieuw proberen. Met Service Bus kunt u het beste beleid voor opnieuw proberen voor uw toepassingen kiezen. Het standaardbeleid is om maximaal 9 nieuwe pogingen toe te staan en 30 seconden te wachten, maar dit kan verder worden aangepast. Zie Beleid voor opnieuw proberen – Service Bus voor meer informatie.

Gebruik een wachtrij met dode letters. Als een bericht na meerdere nieuwe pogingen niet kan worden verwerkt of bezorgd bij een ontvanger, wordt het verplaatst naar een wachtrij met dode brieven. Implementeer een proces voor het lezen van berichten uit de wachtrij met dode brieven, inspecteer deze en los het probleem op. Afhankelijk van het scenario kunt u het bericht opnieuw proberen, wijzigingen aanbrengen en het bericht opnieuw proberen of het bericht verwijderen. Zie Overview of Service Bus dead-letter queues (Overzicht van Service Bus-wachtrijen voor onbestelbare berichten) voor meer informatie.

Zoneredundantie gebruiken. Wanneer zoneredundantie is ingeschakeld voor uw naamruimte, repliceert Service Bus automatisch wijzigingen tussen meerdere beschikbaarheidszones. Als één beschikbaarheidszone mislukt, vindt failover automatisch plaats. Zie Best practices voor het isoleren van toepassingen tegen Service Bus-storingen en -noodgevallen voor meer informatie.

Geo-noodherstel gebruiken. Herstel na geo-noodgeval zorgt ervoor dat gegevensverwerking blijft werken in een andere regio of datacenter als een hele Azure-regio of -datacenter niet meer beschikbaar is vanwege een noodgeval. Zie Azure Service Bus Geo-disaster recovery (Geo-herstel na noodgeval in Azure Service Bus) voor meer informatie.

Storage

Zone-redundante opslag gebruiken. Zone-redundante opslag (ZRS) kopieert uw gegevens synchroon naar drie Azure-beschikbaarheidszones in de primaire regio. Als een beschikbaarheidszone een storing ondervindt, voert Azure Storage automatisch een failover uit naar een alternatieve zone. Zie Redundantie in Azure Storage voor meer informatie.

Wanneer u georedundantie gebruikt, configureert u leestoegang. Als u een architectuur met meerdere regio's gebruikt, gebruikt u een geschikte opslaglaag voor wereldwijde redundantie. Met RA-GRS of RA-GZRS worden uw gegevens gerepliceerd naar een secundaire regio. RA-GRS maakt gebruik van lokaal redundante opslag (LRS) in de primaire regio, terwijl RA-GZRS zone-redundante opslag (ZRS) gebruikt in de primaire regio. Beide configuraties bieden alleen-lezentoegang tot uw gegevens in de secundaire regio. Als er sprake is van een opslagstoring in de primaire regio, kan de toepassing de gegevens uit de secundaire regio lezen als u deze voor deze mogelijkheid hebt ontworpen. Zie Redundantie in Azure Storage voor meer informatie.

Gebruik beheerde schijven voor VM-schijven.Beheerde schijven bieden een betere betrouwbaarheid voor VM's in een beschikbaarheidsset, omdat de schijven voldoende van elkaar zijn geïsoleerd om single points of failure te voorkomen. Beheerde schijven zijn ook niet onderworpen aan de IOPS-limieten van VHD's die zijn gemaakt in een opslagaccount. Zie De beschikbaarheid van virtuele Windows-machines in Azure beheren voor meer informatie.

Maak voor Queue Storage een back-upwachtrij in een andere regio. Voor Queue Storage heeft een replica met het kenmerk Alleen-lezen een beperkt gebruik, omdat u items niet in de wachtrij kunt plaatsen of verwijderen. Maak in plaats daarvan een back-upwachtrij in een opslagaccount in een andere regio. Als er een Azure Storage-storing is, kan de toepassing de back-upwachtrij gebruiken totdat de primaire regio weer beschikbaar is. Op die manier kan de toepassing nieuwe aanvragen blijven verwerken tijdens de storing.

SQL Database

Gebruik de Standard- of Premium-laag. Deze lagen bieden een langere herstelperiode (35 dagen). Zie de opties en prestaties van SQL Database voor meer informatie.

Schakel SQL Database-controle in. Controle kan worden gebruikt om schadelijke aanvallen of menselijke fouten te diagnosticeren. Zie Aan de slag met sql-databasecontrole voor meer informatie.

Gebruik Actieve geo-replicatie Gebruik actieve geo-replicatie om een leesbare secundaire in een andere regio te maken. Als uw primaire database mislukt of offline moet worden gehaald, voert u een handmatige failover uit naar de secundaire database. Totdat u een failover uitvoert, blijft de secundaire database alleen-lezen. Zie SQL Database Active Geo-Replication voor meer informatie.

Gebruik sharding. Overweeg het gebruik van sharding om de database horizontaal te partitioneren. Sharding kan foutisolatie bieden. Zie Uitschalen met Azure SQL Database voor meer informatie.

Gebruik herstel naar een bepaald tijdstip om te herstellen van menselijke fouten. Herstel naar een bepaald tijdstip retourneert uw database naar een eerder tijdstip. Zie Een Azure SQL-database herstellen met behulp van geautomatiseerde databaseback-ups voor meer informatie.

Gebruik geo-herstel om te herstellen na een servicestoring. Met geo-herstel wordt een database hersteld vanuit een geografisch redundante back-up. Zie Een Azure SQL-database herstellen met behulp van geautomatiseerde databaseback-ups voor meer informatie.

Azure Synapse Analytics

Schakel geo-back-up niet uit. Synapse Analytics maakt standaard elke 24 uur elke 24 uur een volledige back-up van uw gegevens in een toegewezen SQL-pool voor herstel na noodgevallen. Het is niet raadzaam deze functie uit te schakelen. Zie Geo-back-ups voor meer informatie.

SQL Server die wordt uitgevoerd op een VIRTUELE machine

Maak een back-up van de database. Als u azure Backup al gebruikt om een back-up van uw VM's te maken, kunt u overwegen Om Azure Backup te gebruiken voor SQL Server-workloads met behulp van DPM. Met deze aanpak is er één rol van back-upbeheerder voor de organisatie en een uniforme herstelprocedure voor VM's en SQL Server. Gebruik anders SQL Server Managed Backup naar Microsoft Azure.

Traffic Manager

Handmatige failback uitvoeren. Voer na een Traffic Manager-failover handmatige failback uit in plaats van automatisch een failback uit te voeren. Controleer voordat u een failback uitvoert of alle toepassingssubsystemen in orde zijn. Anders kunt u een situatie maken waarin de toepassing heen en weer wordt gespiegeld tussen datacenters. Zie VM's uitvoeren in meerdere regio's voor hoge beschikbaarheid voor meer informatie.

Maak een statustesteindpunt. Maak een aangepast eindpunt dat rapporteert over de algehele status van de toepassing. Hierdoor kan Traffic Manager een failover uitvoeren als een kritiek pad mislukt, niet alleen de front-end. Het eindpunt moet een HTTP-foutcode retourneren als een kritieke afhankelijkheid beschadigd of onbereikbaar is. Rapporteer echter geen fouten voor niet-kritieke services. Anders kan de statustest failover activeren wanneer deze niet nodig is, waardoor fout-positieven worden gemaakt. Zie Traffic Manager-eindpuntbewaking en failover voor meer informatie.

Virtual Machines

Vermijd het uitvoeren van een productieworkload op één virtuele machine. Eén VM-implementatie is niet tolerant voor gepland of ongepland onderhoud. Plaats in plaats daarvan meerdere VM's in een beschikbaarheidsset of virtuele-machineschaalset, met een load balancer vooraan.

Geef een beschikbaarheidsset op wanneer u de VIRTUELE machine inricht. Op dit moment is er geen manier om een VIRTUELE machine toe te voegen aan een beschikbaarheidsset nadat de VIRTUELE machine is ingericht. Wanneer u een nieuwe VIRTUELE machine toevoegt aan een bestaande beschikbaarheidsset, moet u een NIC voor de VIRTUELE machine maken en de NIC toevoegen aan de back-endadresgroep op de load balancer. Anders routeert de load balancer geen netwerkverkeer naar die VIRTUELE machine.

Plaats elke toepassingslaag in een afzonderlijke beschikbaarheidsset. Plaats in een N-tier-toepassing geen VM's uit verschillende lagen in dezelfde beschikbaarheidsset. VM's in een beschikbaarheidsset worden geplaatst in foutdomeinen (FD's) en updatedomeinen (UD). Om het redundantievoordeel van FD's en UD's te krijgen, moet elke VIRTUELE machine in de beschikbaarheidsset dezelfde clientaanvragen kunnen verwerken.

Virtuele machines repliceren met behulp van Azure Site Recovery. Wanneer u Virtuele Azure-machines repliceert met Behulp van Site Recovery, worden alle VM-schijven continu asynchroon gerepliceerd naar de doelregio. De herstelpunten worden om de paar minuten gemaakt. Hiermee krijgt u een RPO (Recovery Point Objective) in de volgorde van minuten. U kunt noodherstelanalyses zo vaak uitvoeren als u wilt, zonder dat dit van invloed is op de productietoepassing of de doorlopende replicatie. Zie Een noodherstelanalyse uitvoeren naar Azure voor meer informatie.

Kies de juiste VM-grootte op basis van prestatievereisten. Wanneer u een bestaande workload naar Azure verplaatst, begint u met de VM-grootte die het dichtst bij uw on-premises servers past. Meet vervolgens de prestaties van uw werkelijke workload met betrekking tot CPU, geheugen en schijf-IOPS en pas de grootte indien nodig aan. Dit helpt ervoor te zorgen dat de toepassing zich gedraagt zoals verwacht in een cloudomgeving. Als u meerdere NIC's nodig hebt, moet u rekening houden met de NIC-limiet voor elke grootte.

Beheerde schijven gebruiken voor VHD's.Beheerde schijven bieden een betere betrouwbaarheid voor VM's in een beschikbaarheidsset, omdat de schijven voldoende van elkaar zijn geïsoleerd om single points of failure te voorkomen. Beheerde schijven zijn ook niet onderworpen aan de IOPS-limieten van VHD's die zijn gemaakt in een opslagaccount. Zie De beschikbaarheid van virtuele Windows-machines in Azure beheren voor meer informatie.

Installeer toepassingen op een gegevensschijf, niet op de besturingssysteemschijf. Anders kunt u de schijfgroottelimiet bereiken.

Gebruik Azure Backup om een back-up te maken van VM's. Back-ups beschermen tegen onbedoeld gegevensverlies. Zie Azure-VM's beveiligen met een Recovery Services-kluis voor meer informatie.

Diagnostische logboeken inschakelen. Voeg basisgegevens voor statusgegevens, infrastructuurlogboeken en diagnostische gegevens over opstarten toe. Diagnostische gegevens over opstarten kunnen u helpen bij het diagnosticeren van een opstartfout als uw VIRTUELE machine een niet-opstartbare status krijgt. Zie Overzicht van diagnostische logboeken van Azure voor meer informatie.

Configureer Azure Monitor. Bewakingsgegevens verzamelen en analyseren van virtuele Azure-machines, waaronder het gastbesturingssysteem en de workloads die erin worden uitgevoerd, raadpleegt u Azure Monitor en quickstart: Azure Monitor.

Virtual Network

Als u openbare IP-adressen wilt toestaan of blokkeren, voegt u een netwerkbeveiligingsgroep toe aan het subnet. Blokkeer de toegang van kwaadwillende gebruikers of sta alleen toegang toe van gebruikers die toegangsrechten hebben tot de toepassing.

Maak een aangepaste statustest. Load Balancer-statustests kunnen HTTP of TCP testen. Als een VM een HTTP-server uitvoert, is de HTTP-test een betere indicator van de status dan een TCP-test. Gebruik voor een HTTP-test een aangepast eindpunt dat de algehele status van de toepassing rapporteert, inclusief alle kritieke afhankelijkheden. Zie het overzicht van Azure Load Balancer voor meer informatie.

Blokkeer de statustest niet. De load balancer-statustest wordt verzonden vanaf een bekend IP-adres, 168.63.129.16. Blokkeer verkeer van of naar dit IP-adres niet in firewallbeleidsregels of regels voor netwerkbeveiligingsgroepen. Als u de statustest blokkeert, kan de load balancer de VM uit de rotatie verwijderen.

Logboekregistratie van Load Balancer inschakelen. In de logboeken ziet u hoeveel VM's op de back-end geen netwerkverkeer ontvangen vanwege mislukte testreacties. Zie Log Analytics voor Azure Load Balancer voor meer informatie.