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 controleren. Zie Betrouwbare Azure-toepassingen ontwerpen voor meer informatie over het ontwerpen van flexibele toepassingen.
App Service
Gebruik Standard of Premium laag. Deze lagen ondersteunen faseringssleuven en automatische back-ups. Zie uitgebreid overzicht van Azure App Service plannen voor meer informatie
Schaal niet omhoog of omlaag. Selecteer in plaats daarvan een laag en instantiegrootte die voldoen aan uw prestatievereisten bij een normale belasting en schaal vervolgens de exemplaren uit om wijzigingen in het verkeersvolume te verwerken. Als u omhoog en omlaag schaalt, wordt de toepassing mogelijk opnieuw opgestart.
Configuratie opslaan als app-instellingen. Gebruik app-instellingen om configuratie-instellingen op te houden als app-instellingen. Definieer de instellingen in uw Resource Manager-sjablonen of met behulp van PowerShell, zodat u deze kunt toepassen als onderdeel van een geautomatiseerd implementatie-/updateproces, dat betrouwbaarder is. Zie Web-apps configureren in Azure App Service voor meer Azure App Service.
Maak afzonderlijke App Service voor productie en testen. Gebruik geen sleuven in uw productie-implementatie voor testen. Alle apps binnen hetzelfde abonnement App Service dezelfde VM-exemplaren delen. Als u productie- en testimplementaties in hetzelfde plan zet, kan dit een negatieve invloed hebben op de productie-implementatie. Belastingstests kunnen bijvoorbeeld de live productiesite verslechteren. Door testimplementaties in een afzonderlijk plan te plaatsen, kunt u ze isoleren 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 overwegen deze op te delen in afzonderlijke App Service apps. Dit ontwerp maakt het gemakkelijker om de oplossing op te maken op workload. U kunt de web-app en de API in afzonderlijke App Service uitvoeren, zodat ze onafhankelijk van elkaar kunnen worden geschaald. Als u dat schaalbaarheidsniveau in eerste instantie niet nodig hebt, kunt u de apps in hetzelfde plan implementeren en ze indien nodig later naar afzonderlijke plannen verplaatsen.
Vermijd het gebruik van App Service back-upfunctie om back-ups te maken van Azure SQL databases. Gebruik in plaats daarvan SQL Database automatische back-ups. App Service back-up exporteert de database naar een SQL BACPAC-bestand, wat DTUs kost.
Implementeren naar een staging-sleuf. Maak een implementatiesleuf voor fasering. Implementeer toepassingsupdates naar de staging-sleuf 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 genomen. Veel toepassingen hebben een aanzienlijke opwarm- en koude starttijd. Zie Faseringsomgevingen instellen voor web-apps in Azure App Service.
Maak een implementatiesleuf voor de laatste bekende goede implementatie (LKG). Wanneer u een update voor productie implementeert, verplaatst u de vorige productie-implementatie naar de LKG-sleuf. Dit maakt het gemakkelijker 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, inclusief toepassingslogboekregistratie en webserverlogboekregistratie. Logboekregistratie is belangrijk voor bewaking en diagnostische gegevens. Zie Logboekregistratie van diagnostische gegevens 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 te 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 bij belasting te bewaken. Prestatiebewaking biedt u realtime inzicht in de toepassing. Hiermee kunt u problemen diagnosticeren en de hoofdoorzaak van fouten analyseren.
Azure Load Balancer
Selecteer Standaard-SKU Standard Load Balancer biedt een dimensie van betrouwbaarheid die Basic niet biedt: die van beschikbaarheidszones en zone resiliency. Dit betekent dat wanneer een zone uitgaat, uw zone-redundante Standard Load Balancer niet worden beïnvloed. Dit zorgt ervoor dat uw implementaties bestand zijn tegen zonefouten binnen een regio. Bovendien biedt Standard Load Balancer ondersteuning voor wereldwijde taakverdeling, zodat uw toepassing ook niet wordt beïnvloed door regiofouten.
Ten minste twee exemplaren inrichten Implementeer Azure LB met ten minste twee exemplaren in de back-end. Eén exemplaar kan leiden tot één storingspunt. Als u wilt bouwen voor schaal, kunt u LB koppelen aan Virtual Machine Scale Sets.
Uitgaande regels gebruiken Uitgaande regels zorgen ervoor dat u niet wordt geconfronteerd met verbindingsfouten als gevolg van uitputting van de SNAT-poort. Meer informatie over uitgaande connectiviteit. Uitgaande regels helpen bij het verbeteren van de oplossing voor kleine tot middelgrote implementaties, maar voor productieworkloads wordt aangeraden om Standard Load Balancer of een subnetimplementatie met VNet NATte koppelen.
Application Gateway
Inrichting van ten minste twee exemplaren. Implementeer Application Gateway met ten minste twee exemplaren. Eén exemplaar is een single point of failure. Gebruik twee of meer instanties voor redundantie en schaalbaarheid. Als u in aanmerking wilt komen voor de SLA,moet u twee of meer middelgrote of grotere exemplaren inrichten.
Cosmos DB
Repliceer de database tussen regio's. Cosmos DB kunt u een aantal Azure-regio's koppelen aan een Cosmos DB-databaseaccount. Een Cosmos DB-database kan één schrijfregio en meerdere leesregio's hebben. Als er een fout is in de schrijfregio, kunt u lezen vanuit een andere replica. De Client-SDK verwerkt dit automatisch. U kunt ook een fail over de schrijfregio naar een andere regio maken. Zie Distribute data globally with Azure Cosmos DB (Gegevens wereldwijd distribueren met Azure Cosmos DB) voor meer informatie.
Event Hubs
Gebruik controlepunten. Een gebeurtenis consumer moet de huidige positie schrijven naar permanente opslag met een vooraf gedefinieerd interval. Op die manier kan een nieuw exemplaar het lezen van de stream vanaf de laatst vastgelegde positie hervatten als de consument een fout ervaart (bijvoorbeeld als de consument vastvalt of mislukt). Zie Gebeurtenisverbruikers voor meer informatie.
Dubbele berichten verwerken. Als een gebeurtenis consumer mislukt, wordt de verwerking van berichten hervat vanaf het laatst vastgelegde controlepunt. Alle berichten die al na het laatste controlepunt zijn verwerkt, worden opnieuw verwerkt. Daarom moet uw berichtverwerkingslogica idempotent zijn, anders moet de toepassing berichten kunnen ontdubbelen.
Af te handelen uitzonderingen.. Een gebeurtenis consumer verwerkt doorgaans een batch berichten in een lus. U moet uitzonderingen binnen deze verwerkingslus afhandelen om te voorkomen dat een hele batch berichten verloren gaat als één bericht een uitzondering veroorzaakt.
Gebruik een wachtrij voor in wachtrijen zonder berichten. Als het verwerken van een bericht resulteert in een niet-tijdelijke fout, zet u het bericht in een wachtrij voor onbesleede berichten, zodat u de status kunt volgen. Afhankelijk van het scenario kunt u het bericht later opnieuw proberen, een compenserende transactie toepassen of een andere actie ondernemen. Houd er Event Hubs dat er geen ingebouwde functionaliteit voor wachtrijen voor ingebouwde wachtrijen voor ingebouwde berichten is. U kunt Azure Queue Storage of Service Bus gebruiken om een wachtrij voor in wachtrijen geplaatste berichten te implementeren, of Azure Functions of een ander gebeurtenismechanisme gebruiken.
Implementeert herstel na noodherstel door een failing over te maken naar een Event Hubs naamruimte. Zie Geo-herstel na Azure Event Hubs voor meer informatie.
Azure Cache voor Redis
Configureer geo-replicatie. Geo-replicatie biedt een mechanisme voor het koppelen van twee Premium-tier Azure Cache voor Redis instanties. Gegevens die naar de primaire cache worden geschreven, worden gerepliceerd naar een secundaire alleen-lezencache. Zie How to configure geo-replication for Azure Cache voor Redis (Geo-replicatie configureren voor Azure Cache voor Redis
Gegevens persistentie configureren. Met Redis-persistentie kunt u gegevens persistent maken die zijn opgeslagen in Redis. U kunt ook momentopnamen maken en een back-up maken van de gegevens, die u kunt laden in het geval van een hardwarestoring. Zie How to configure data persistence for a Premium-tier Azure Cache voor Redis (Gegevens persistentie configureren voor een Premium-tier-Azure Cache voor Redis
Als u een Azure Cache voor Redis als een tijdelijke gegevenscache en niet als een permanente opslag, zijn deze aanbevelingen mogelijk niet van toepassing.
Zoeken
Meer dan één replica inrichten. Gebruik ten minste twee replica's voor hoge beschikbaarheid van lees of drie voor lees-/schrijf-hoge beschikbaarheid.
Indexeerders configureren voor implementaties in meerdere regio's. Als u een implementatie voor meerdere regio's hebt, kunt u uw opties voor continuïteit in indexering overwegen.
Als de gegevensbron geo-gerepliceerd is, moet u over het algemeen elke indexeerster van elke regionale Azure-Search-service naar de lokale gegevensbronreplica laten wijzen. Deze aanpak wordt echter niet aanbevolen voor grote gegevenssets die zijn opgeslagen in Azure SQL Database. De reden hiervoor is dat Azure Search geen incrementele indexering kan uitvoeren van secundaire SQL Database replica's, alleen vanaf primaire replica's. Wijs in plaats daarvan alle indexeerders naar de primaire replica. Wijs na een failover de Indexers van Azure Search aan op de nieuwe primaire replica.
Als de gegevensbron niet geo-gerepliceerd is, moet u meerdere indexeerfuncties op dezelfde gegevensbron wijzen, zodat Azure Search-services in meerdere regio's continu en onafhankelijk van de gegevensbron worden geïndexeerd. Zie Prestatie- en optimalisatieoverwegingen voor Azure Search voor meer informatie.
Service Bus
Gebruik Premium laag voor productieworkloads. Service Bus Premium Messaging biedt toegewezen en gereserveerde verwerkingsresources en geheugencapaciteit ter ondersteuning van voorspelbare prestaties en doorvoer. Premium Berichtenlaag 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 werkbelastingen.
Dubbele berichten verwerken. Als een uitgever onmiddellijk uitvalt na het verzenden van een bericht, of als er netwerk- of systeemproblemen zijn, kan het ten onrechte niet registreren dat het bericht is afgeleverd en kan hetzelfde bericht tweemaal naar het systeem worden verzonden. Service Bus dit probleem kunnen oplossen door detectie van duplicaten in te stellen. Zie Detectie van duplicaten voor meer informatie.
Af te handelen uitzonderingen. Bericht-API's genereren uitzonderingen wanneer een gebruikersfout, configuratiefout of andere fout optreedt. De clientcode (afzenders en ontvangers) moet deze uitzonderingen in de code verwerken. Dit is vooral belangrijk bij batchverwerking, waarbij afhandeling van uitzonderingen kan worden gebruikt om te voorkomen dat een hele batch berichten verloren gaat. Zie Berichten-uitzonderingen Service Bus meer informatie.
Beleid voor opnieuw proberen. Service Bus kunt u het beste beleid voor opnieuw proberen kiezen voor uw toepassingen. Het standaardbeleid is om 9 maximum aantal nieuwe pogingen toe te staan en 30 seconden te wachten, maar dit kan verder worden aangepast. Zie Beleid voor opnieuw proberen - Service Bus.
Gebruik een wachtrij voor in wachtrijen met in wachtrij geplaatste berichten. Als een bericht na meerdere nieuwe keren niet kan worden verwerkt of bezorgd bij een ontvanger, wordt het verplaatst naar een wachtrij voor niet-bezorgde berichten. Implementeer een proces voor het lezen van berichten uit de wachtrij voor in wachtrijen geplaatste berichten, het inspecteren ervan en het oplossen van het probleem. Afhankelijk van het scenario kunt u het bericht opnieuw proberen, wijzigingen aanbrengen en het 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.
Gebruik Geo-Disaster Recovery. Herstel na geo-noodherstel zorgt ervoor dat de gegevensverwerking blijft werken in een andere regio of in een ander datacenter als een hele Azure-regio of een datacentrum niet meer beschikbaar is vanwege een noodherstel. Zie Azure Service Bus Geo-disaster recovery (Geo-herstel na noodgeval in Azure Service Bus) voor meer informatie.
Storage
Gebruik geografisch redundante opslag met leestoegang (RA-GRS) voor toepassingsgegevens. Ra-GRS-opslag repliceert de gegevens naar een secundaire regio en biedt alleen-lezentoegang vanuit de secundaire regio. Als er een opslagstoring in de primaire regio is, kan de toepassing de gegevens uit de secundaire regio lezen. Zie Azure Storage-replicatie 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 bovendien niet onderhevig aan de IOPS-limieten van VHD's die in een opslagaccount zijn gemaakt. Zie Manage the availability of Windows virtual machines in Azure (De beschikbaarheid van virtuele machines in Azure beheren) voor meer informatie.
Maak voor Queue Storage een back-upwachtrij in een andere regio. Voor Queue Storage heeft een alleen-lezen replica beperkt gebruik, omdat u geen items in de wachtrij kunt opslaan of uit de wachtrij kunt verwijderen. Maak in plaats daarvan een back-upwachtrij in een opslagaccount in een andere regio. Als er een opslagstoring is, kan de toepassing de back-upwachtrij gebruiken totdat de primaire regio weer beschikbaar is. Op die manier kan de toepassing nog steeds nieuwe aanvragen verwerken.
SQL Database
Gebruik Standard of Premium laag. Deze lagen bieden een langere herstelperiode (35 dagen). Zie voor meer informatie SQL Database opties en prestaties.
Schakel SQL Database in. Controle kan worden gebruikt om schadelijke aanvallen of menselijke fouten vast te stellen. Zie Get started with SQL database auditing (Aan de slag SQL databasecontrole) voor meer informatie.
Actieve geo-replicatie gebruiken Gebruik Active Geo-Replication om een leesbare secundaire te maken in een andere regio. Als uw primaire database uitvalt of gewoon offline moet worden genomen, voert u een handmatige failover uit naar de secundaire database. Totdat u een fail over hebt, blijft de secundaire database alleen-lezen. Zie Actieve geo SQL Database replicatie 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 Azure SQL Database.
Herstel naar een bepaald tijdstip gebruiken om te herstellen van menselijke fouten. Herstel naar een bepaald tijdstip retourneert uw database naar een eerder tijdstip. Zie Recover an Azure SQL database using automated database backups (Een Azure SQL-database herstellen met behulp van automatische databaseback-ups) voor meer informatie.
Geo-herstel gebruiken om te herstellen na een servicestoring. Geo-herstel herstelt een database vanuit een geografisch redundante back-up. Zie Recover an Azure SQL database using automated database backups (Een Azure SQL-database herstellen met behulp van automatische databaseback-ups) voor meer informatie.
Azure Synapse Analytics
Schakel geo-back-up niet uit. Standaard maakt Synapse Analytics elke 24 uur een volledige back-up van uw gegevens voor herstel na noodherstel. Het wordt afgeraden om deze functie uit te schakelen. Zie Geo-back-ups voor meer informatie.
SQL Server uitgevoerd in een VM
Repliceer de database. Gebruik SQL Server Always On-beschikbaarheidsgroepen om de database te repliceren. Biedt hoge beschikbaarheid als één SQL Server mislukt. Zie Run Windows VMs for an N-tier application (Virtuele Windows uitvoeren voor een toepassing met meerdere lagen) voor meer informatie
Een back-up maken van de database. Als u al gebruik maakt van Azure Backup back-up van uw VM's, kunt u overwegen om Azure Backup te gebruiken SQL Server werkbelastingenmet behulp van DPM . Met deze aanpak is er één back-upbeheerdersrol voor de organisatie en een uniforme herstelprocedure voor VM's en SQL Server. Gebruik anders beheerde SQL Server back-up om Microsoft Azure.
Traffic Manager
Handmatige failback uitvoeren. Voer na Traffic Manager failover handmatige failback uit in plaats van automatisch een failback uit te voeren. Voordat u een fout maakt, controleert u of alle toepassingssubsystemen in orde zijn. Anders kunt u een situatie creëren waarin de toepassing heen en weer wordt geslipt tussen datacenters. Zie VM's uitvoeren in meerdere regio's voor hoge beschikbaarheid voor meer informatie.
Maak een statustest-eindpunt. Maak een aangepast eindpunt dat rapporteert over de algehele status van de toepassing. Hierdoor kan Traffic Manager fail over te slaan als een kritiek pad mislukt, niet alleen de front-end. Het eindpunt moet een HTTP-foutcode retourneren als een kritieke afhankelijkheid niet in orde of onbereikbaar is. Rapporteer echter geen fouten voor niet-kritieke services. Anders kan de statustest een failover activeren wanneer deze niet nodig is, waardoor fout-positieven worden gemaakt. Zie Eindpuntbewaking en failover Traffic Manager voor meer informatie.
Virtual Machines
Vermijd het uitvoeren van een productieworkload op één VM. Eén VM-implementatie is niet bestand tegen gepland of ongepland onderhoud. Plaats in plaats daarvan meerdere VM's in een beschikbaarheidsset of virtuele-machineschaalset,met een load balancer vóór.
Geef een beschikbaarheidsset op wanneer u de VM inrichten. Er is momenteel geen manier om een VM toe te voegen aan een beschikbaarheidsset nadat de VM is ingericht. Wanneer u een nieuwe VM toevoegt aan een bestaande beschikbaarheidsset, moet u een NIC voor de VM maken en de NIC toevoegen aan de back-endadresgroep op de load balancer. Anders routeert load balancer netwerkverkeer niet naar die VM.
Plaats elke toepassingslaag in een afzonderlijke beschikbaarheidsset. Plaats in een toepassing met meerdere lagen 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 VM in de beschikbaarheidsset echter dezelfde clientaanvragen kunnen verwerken.
Repliceer VM's met Azure Site Recovery. Wanneer u Virtuele Azure-Site Recovery 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 orde van minuten. U kunt zo vaak noodhersteloefeningen uitvoeren als u wilt, zonder dat dit van invloed is op de productietoepassing of de lopende replicatie. Zie Een noodhersteloefening uitvoeren op 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 komt. 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 ook 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 bovendien niet onderhevig aan de IOPS-limieten van VHD's die in een opslagaccount zijn gemaakt. Zie Manage the availability of Windows virtual machines in Azure (De beschikbaarheid van virtuele machines in Azure beheren) voor meer informatie.
Toepassingen installeren op een gegevensschijf, niet op de besturingssysteemschijf. Anders kunt u de limiet voor schijfgrootte bereiken.
Gebruik Azure Backup om 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.
Schakel diagnostische logboeken in. Neem metrische basisgegevens over de status, infrastructuurlogboeken en diagnostische gegevens over opstarten op. Diagnostische gegevens over opstarten kunnen u helpen bij het vaststellen van een opstartfout als uw VM een niet-opstartbare status krijgt. Zie Overzicht van Diagnostische logboeken van Azure voor meer informatie.
Configureer Azure Monitor. Verzamel en analyseer bewakingsgegevens van virtuele Azure-machines, inclusief het gastbesturingssysteem en de workloads die erop worden uitgevoerd. Zie 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 toegang van kwaadwillende gebruikers of sta alleen toegang toe van gebruikers die toegangsrechten hebben voor de toepassing.
Maak een aangepaste statustest. Load Balancer statustests kunnen HTTP of TCP testen. Als op een VM een HTTP-server wordt uitgevoerd, 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 overzicht 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 geen verkeer naar of van dit IP-adres in firewallbeleid of regels voor netwerkbeveiligingsgroep. Als de statustest wordt geblokkeerd, load balancer de VM uit rotatie verwijderd.
Schakel Load Balancer logboekregistratie in. De logboeken laten zien hoeveel VM's in de back-end geen netwerkverkeer ontvangen vanwege mislukte testreacties. Zie Log Analytics voor meer informatie Azure Load Balancer.