Controlelijst voor tolerantie voor specifieke Azure-services

  • Artikel

Flexibiliteit is het vermogen van een systeem om te herstellen van fouten en te kunnen blijven functioneren. Elke technologie heeft zijn eigen specifieke foutmodi, waarmee u rekening moet houden 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 flexibele toepassingen.

App Service

Gebruik de Standard- of Premium-laag. Deze lagen ondersteunen faseringssites en geautomatiseerde back-ups. Zie uitgebreid overzicht van Azure App Service plannen voor meer informatie

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

Configuratie opslaan als app-instellingen. Gebruik app-instellingen om configuratie-instellingen vast 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 informatie.

Maak afzonderlijke App Service plannen voor productie en test. Gebruik geen sleuven in uw productie-implementatie voor het 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 degraderen van de live productiesite. Door testimplementaties in een afzonderlijk plan te plaatsen, kunt u ze isoleren van de productieversie.

Web-apps scheiden 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. Dit ontwerp maakt het eenvoudiger om de oplossing op te delen op basis van workload. U kunt de web-app en de API in afzonderlijke App Service plannen uitvoeren, zodat ze onafhankelijk van elkaar kunnen worden geschaald. Als u dat schaalbaarheidsniveau in eerste instantie niet nodig hebt, kunt u de apps implementeren in hetzelfde plan en ze later, indien nodig, naar afzonderlijke plannen verplaatsen.

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

Implementeren naar een staging-site. Maak een implementatiesite voor fasering. Implementeer toepassingsupdates in de staging-site en controleer de implementatie voordat u deze in productie wisselt. Dit vermindert de kans op een slechte update in de productie. Het zorgt er ook voor dat alle exemplaren worden opgewarmd voordat ze in productie worden gewisseld. Veel toepassingen hebben een aanzienlijke warming-up 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. Dit maakt het eenvoudiger om een slechte implementatie terug te draaien. Als u later een probleem ontdekt, kunt u snel terugkeren naar de LKG-versie. Zie Basiswebtoepassing voor meer informatie.

Diagnostische logboekregistratie inschakelen, inclusief toepassingslogboekregistratie en logboekregistratie van webservers. Logboekregistratie is belangrijk voor bewaking en diagnose. Zie Diagnostische logboekregistratie inschakelen voor web-apps in Azure App Service

Meld u aan bij blob-opslag. 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 prestatiebewakingsservice zoals New Relic of Application Insights om de prestaties en het gedrag van toepassingen bij belasting te bewaken. Prestatiebewaking geeft u realtime inzicht in de toepassing. Hiermee kunt u problemen vaststellen en de hoofdoorzaakanalyse van fouten uitvoeren.

Azure Load Balancer

Selecteer Standaard-SKU Standard Load Balancer biedt een betrouwbaarheidsdimensie die Basic niet heeft: die van beschikbaarheidszones en zonetolerantie. Dit betekent dat wanneer een zone uitvalt, uw zone-redundante Standard Load Balancer niet worden beïnvloed. Dit zorgt ervoor dat uw implementaties bestand zijn tegen zonefouten binnen een regio. Daarnaast ondersteunt Standard Load Balancer 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 een Single Point of Failure. Als u wilt bouwen voor schaal, kunt u LB koppelen aan Virtual Machine Scale Sets.

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

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 exemplaren inrichten.

Azure Cosmos DB

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 uit een andere replica. De client-SDK verwerkt dit automatisch. U kunt ook een failover uitvoeren voor de schrijfregio naar een andere regio. Zie Distribute data globally with Azure Cosmos DB (Gegevens wereldwijd distribueren met Azure Cosmos DB) voor meer informatie.

Event Hubs

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

Dubbele berichten verwerken. Als een gebeurtenisconsumer mislukt, wordt de berichtverwerking hervat vanaf het laatst opgenomen controlepunt. Alle berichten die al zijn verwerkt na het laatste controlepunt, 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 binnen deze verwerkingslus afhandelen om te voorkomen dat een hele batch berichten verloren gaat als één bericht een uitzondering veroorzaakt.

Gebruik een wachtrij met onbestelbare berichten. Als het verwerken van een bericht resulteert in een niet-tijdelijke fout, plaatst u het bericht in een wachtrij met onbestelbare berichten, 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. Houd er rekening mee dat Event Hubs geen ingebouwde wachtrijfunctionaliteit voor onbestelbare berichten heeft. U kunt Azure Queue Storage of Service Bus gebruiken om een wachtrij met onbestelbare berichten te implementeren, of Azure Functions of een ander gebeurtenismechanisme gebruiken.

Herstel na noodgevallen implementeren door een failover uit te voeren naar een secundaire Event Hubs-naamruimte. Zie Azure Event Hubs Geo-noodherstel voor meer informatie.

Azure Cache voor Redis

Geo-replicatie configureren. Geo-replicatie biedt een mechanisme voor het koppelen van twee premium-Azure Cache voor Redis exemplaren. Gegevens die naar de primaire cache worden geschreven, worden gerepliceerd naar een secundaire alleen-lezencache. Zie Geo-replicatie configureren voor Azure Cache voor Redis voor meer informatie

Gegevenspersistentie configureren. Met Redis-persistentie kunt u in de Redis-cache opgeslagen gegevens persistent maken. U kunt ook momentopnamen maken en een back-up van de gegevens maken, die u kunt laden in het geval van een hardwarestoring. Zie Gegevenspersistentie configureren 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.

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

Indexeerfuncties configureren voor implementaties in meerdere regio's. Als u een implementatie met meerdere regio's hebt, moet u rekening houden met de opties voor continuïteit bij het indexeren.

  • Als de gegevensbron geo-gerepliceerd is, moet u over het algemeen elke indexeerfunctie van elke regionale Azure-Search-service verwijzen naar de lokale gegevensbronreplica. 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 vanaf secundaire SQL Database replica's, alleen van primaire replica's. Wijs in plaats daarvan alle indexeerfuncties naar de primaire replica. Na een failover wijst u de Azure Search-indexeerfuncties naar de nieuwe primaire replica.

  • Als de gegevensbron niet geo-gerepliceerd is, wijst u meerdere indexeerfuncties naar dezelfde gegevensbron, zodat Azure Search-services in meerdere regio's continu en onafhankelijk van de gegevensbron indexeren. 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.

Dubbele berichten verwerken. Als een uitgever onmiddellijk na het verzenden van een bericht mislukt of netwerk- of systeemproblemen ondervindt, kan deze mogelijk ten onrechte niet vastleggen dat het bericht is bezorgd en kan hetzelfde bericht twee keer naar het systeem worden verzonden. Service Bus kan dit probleem afhandelen door duplicaatdetectie 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 met name belangrijk bij batchverwerking, waarbij uitzonderingsafhandeling kan worden gebruikt om te voorkomen dat een hele batch berichten verloren gaat. Zie Uitzonderingen voor Service Bus-berichten 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 onbestelbare berichten. Als een bericht niet kan worden verwerkt of bezorgd bij een ontvanger na meerdere nieuwe pogingen, wordt het verplaatst naar een wachtrij met onbestelbare berichten. Implementeer een proces om berichten uit de wachtrij met onbestelbare berichten te lezen, te inspecteren en het probleem op te lossen. Afhankelijk van het scenario kunt u het bericht opnieuw proberen, wijzigingen aanbrengen en opnieuw proberen of het bericht negeren. Zie Overview of Service Bus dead-letter queues (Overzicht van Service Bus-wachtrijen voor onbestelbare berichten) voor meer informatie.

Gebruik Geo-Disaster Recovery. Geo-herstel na noodgevallen zorgt ervoor dat gegevensverwerking in een andere regio of datacenter blijft werken 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

Configureer uw opslagaccount voor geografisch redundante opslag met leestoegang (RA-GRS) of geografisch zone-redundante opslag met leestoegang (RA-GZRS). 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 in de primaire regio gebruikt. Beide configuraties bieden alleen-lezentoegang tot uw gegevens in de secundaire regio. Als er een opslagstoring is 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 onderhevig aan de IOPS-limieten van VHD's die in een opslagaccount zijn gemaakt. Zie De beschikbaarheid van virtuele Windows-machines beheren in Azure voor meer informatie.

Maak voor Queue Storage een back-upwachtrij in een andere regio. Voor Queue Storage heeft een alleen-lezenreplica een beperkt gebruik, omdat u items niet in de wachtrij kunt plaatsen of uit de wachtrij kunt 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 naar een bepaald tijdstip (35 dagen). Zie opties en prestaties SQL Database voor meer informatie.

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

Actieve geo-replicatie gebruiken Gebruik Actieve Geo-Replication om een leesbare secundaire in een andere regio te maken. Als uw primaire database uitvalt of gewoon 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 actieve geo-replicatie SQL Database 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.

Herstel naar een bepaald tijdstip gebruiken om een menselijke fout te herstellen. Herstel naar een bepaald tijdstip retourneert uw database naar een eerder tijdstip. Zie Een Azure SQL-database herstellen met behulp van automatische databaseback-ups voor meer informatie.

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

Azure Synapse Analytics

Schakel geo-back-up niet uit. Synapse Analytics maakt standaard elke 24 uur een volledige back-up van uw gegevens voor herstel na noodgevallen. Het wordt afgeraden om deze functie uit te schakelen. Zie Geo-back-ups voor meer informatie.

SQL Server wordt uitgevoerd op een VM

Repliceer de database. Gebruik SQL Server AlwaysOn-beschikbaarheidsgroepen om de database te repliceren. Biedt hoge beschikbaarheid als één SQL Server exemplaar mislukt. Zie Windows-VM's uitvoeren voor een N-tier-toepassing voor meer informatie

Maak een back-up van de database. Als u Azure Backup al gebruikt voor het maken van back-ups van uw VM's, kunt u overwegen om Azure Backup te gebruiken voor SQL Server workloads met 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 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. Voordat u een failback uitvoert, controleert u of alle toepassingssubsystemen in orde zijn. Anders kunt u een situatie creëren waarin de toepassing heen en weer schakelt tussen datacenters. Zie VM's uitvoeren in meerdere regio's voor hoge beschikbaarheid voor meer informatie.

Een statustesteindpunt maken. Maak een aangepast eindpunt dat rapporteert over de algehele status van de toepassing. Hierdoor kan Traffic Manager een failover uitvoeren als een kritiek pad uitvalt, 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 ontstaan. Zie Eindpuntbewaking en failover van Traffic Manager voor meer informatie.

Virtual Machines

Vermijd het uitvoeren van een productieworkload op één virtuele machine. Een implementatie van één VM 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 vooraan.

Geef een beschikbaarheidsset op wanneer u de VM inricht. Op dit moment is er geen manier om een VM toe te voegen aan een beschikbaarheidsset nadat de VM is ingericht. Wanneer u een nieuwe virtuele machine 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 de load balancer geen netwerkverkeer naar die VM.

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). Als u echter het redundantievoordeel van FD's en UD's wilt krijgen, moet elke VM in de beschikbaarheidsset dezelfde clientaanvragen kunnen verwerken.

Vm's 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. Dit geeft u een Recovery Point Objective (RPO) in de volgorde van minuten. U kunt zo vaak als u wilt noodherstelanalyses uitvoeren, zonder dat dit van invloed is op de productietoepassing of de lopende replicatie. Zie Een noodherstelanalyse uitvoeren naar Azure voor meer informatie.

Kies de juiste VM-grootte op basis van de prestatievereisten. Wanneer u een bestaande workload naar Azure verplaatst, begint u met de VM-grootte die het meest overeenkomt met uw on-premises servers. Meet vervolgens de prestaties van uw werkelijke workload met betrekking tot CPU, geheugen en schijf-IOPS en pas indien nodig de grootte 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 ook niet onderhevig aan de IOPS-limieten van VHD's die in een opslagaccount zijn gemaakt. Zie De beschikbaarheid van virtuele Windows-machines beheren in Azure voor meer informatie.

Installeer toepassingen op een gegevensschijf, niet op de besturingssysteemschijf. Anders bereikt u mogelijk de limiet voor de schijfgrootte.

Gebruik Azure Backup om back-ups 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. Inclusief metrische basisstatusgegevens, infrastructuurlogboeken en diagnostische gegevens over opstarten. 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.

Azure Monitor configureren. Verzamel en analyseer bewakingsgegevens van virtuele Azure-machines, waaronder het gastbesturingssysteem en de workloads die erin 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 de toegang voor kwaadwillende gebruikers of sta alleen toegang toe van gebruikers die toegangsrechten hebben voor toegang tot de toepassing.

Maak een aangepaste statustest. Load Balancer statustests kunnen HTTP of TCP testen. Als een VIRTUELE machine 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 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 naar of van dit IP-adres niet in firewallbeleid of regels voor netwerkbeveiligingsgroepen. Als u de statustest blokkeert, wordt de vm door de load balancer uit de rotatie verwijderd.

Schakel Load Balancer logboekregistratie in. De logboeken laten zien hoeveel VM's op de back-end geen netwerkverkeer ontvangen vanwege mislukte testreacties. Zie Log Analytics voor Azure Load Balancer voor meer informatie.