Delen via

Documentatie voor Azure-betrouwbaarheid

  • Artikel

Betrouwbaarheid bestaat uit twee principes: tolerantie en beschikbaarheid. Het doel van tolerantie is om fouten te voorkomen en, als ze nog steeds voorkomen, uw toepassing te retourneren naar een volledig werkende status. Het doel van beschikbaarheid is om consistente toegang te bieden tot uw toepassing of workload. Het is belangrijk om te plannen voor proactieve betrouwbaarheid op basis van uw toepassingsvereisten.

Azure bevat ingebouwde betrouwbaarheidsservices die u kunt gebruiken en beheren op basis van uw bedrijfsbehoeften. Of het nu gaat om één hardwareknooppuntfout, een storing op rackniveau, een storing in een datacenter of een grootschalige regionale storing, Azure biedt oplossingen die de betrouwbaarheid verbeteren. Beschikbaarheidssets zorgen er bijvoorbeeld voor dat de virtuele machines die zijn geïmplementeerd in Azure, worden verdeeld over meerdere geïsoleerde hardwareknooppunten in een cluster. Beschikbaarheidszones beschermen de toepassingen en gegevens van klanten tegen datacenterfouten op meerdere fysieke locaties binnen een regio. Regio's en beschikbaarheidszones staan centraal in uw toepassingsontwerp en tolerantiestrategie en worden verderop in dit artikel uitgebreider besproken.

De documentatie over Azure-betrouwbaarheid biedt richtlijnen voor betrouwbaarheid voor Azure-services. Deze richtlijnen bevatten informatie over ondersteuning voor beschikbaarheidszones, richtlijnen voor herstel na noodgevallen en beschikbaarheid van services.

Zie het overzicht van azure-servicespecifieke richtlijnen voor betrouwbaarheid, waaronder beschikbaarheidszones, herstel na noodgevallen of hoge beschikbaarheid.

Zie Microsoft Azure Well-Architected Framework: Betrouwbaarheid voor informatie over de principes en de architectuur van Microsoft Azure-services.

Betrouwbaarheidsvereisten

Het vereiste betrouwbaarheidsniveau voor elke Azure-oplossing is afhankelijk van verschillende overwegingen. De SLA voor beschikbaarheid en latentie en andere zakelijke vereisten zorgen voor de architectuurkeuzen en het tolerantieniveau en moeten als eerste worden beschouwd. Beschikbaarheidsvereisten variëren van hoeveel downtime acceptabel is – en hoeveel het uw bedrijf kost – tot de hoeveelheid geld en tijd die u realistisch kunt investeren in het maximaal beschikbaar maken van een toepassing.

Het bouwen van betrouwbaarheidssystemen in Azure is een gedeelde verantwoordelijkheid. Microsoft is verantwoordelijk voor de betrouwbaarheid van het cloudplatform, met inbegrip van het wereldwijde netwerk en datacenters. Azure-klanten en -partners zijn verantwoordelijk voor de tolerantie van hun cloudtoepassingen, met behulp van best practices voor architectuur op basis van de vereisten van elke workload. Hoewel Azure voortdurend streeft naar een zo hoog mogelijke tolerantie in de SLA voor het cloudplatform, moet u uw eigen doel-SLA's definiëren voor elke workload in uw oplossing. Met een SLA kunt u evalueren of de architectuur voldoet aan de bedrijfsvereisten. Naarmate u streeft naar hogere percentages gegarandeerde uptime van de SLA, neemt de kosten en complexiteit om dat beschikbaarheidsniveau te bereiken toe. Een uptime van 99,99 procent resulteert in ongeveer vijf minuten totale downtime per maand. Is het de moeite waard de complexiteit en kosten om dat percentage te bereiken? Het antwoord is afhankelijk van de individuele bedrijfsvereisten. Houd bij het bepalen van definitieve SLA-toezeggingen inzicht in de ondersteunde SLA's van Microsoft. Elke Azure-service heeft een eigen SLA.

Diagram showing the shared responsibility model for Azure business continuity.

In het traditionele on-premises model valt de volledige verantwoordelijkheid voor het beheren van, van de hardware voor rekenkracht, opslag en netwerken tot de toepassing, op u. U moet plannen voor verschillende soorten fouten en hoe u ermee omgaat door een strategie voor herstel na noodgevallen te maken. Met IaaS is de cloudserviceprovider verantwoordelijk voor de tolerantie van de kerninfrastructuur, waaronder opslag, netwerken en compute. Wanneer u overstapt van IaaS naar PaaS en vervolgens naar SaaS, zult u merken dat u verantwoordelijk bent voor minder en dat de cloudserviceprovider verantwoordelijk is voor meer.  

Zie de documentatie over goed ontworpen Framework Reliability voor meer informatie over betrouwbaarheidsprincipes.  

Betrouwbaarheid van gebouwen

U moet aan het begin van de planning de betrouwbaarheidsvereisten van uw toepassing definiëren. Als u weet welke toepassingen gedurende bepaalde perioden geen hoge beschikbaarheid van 100% nodig hebben, kunt u de kosten optimaliseren tijdens deze niet-kritieke perioden. Identificeer het type fouten dat een toepassing kan ondervinden en het mogelijke effect van elke fout. Een herstelplan moet betrekking hebben op alle kritieke services door de herstelstrategie op het afzonderlijke onderdeel en het algehele toepassingsniveau te voltooien. Ontwerp uw herstelstrategie om te beschermen tegen zonegebonden, regionale en toepassingsniveaufouten. Voer tests uit van de end-to-end-toepassingsomgeving om de betrouwbaarheid en het herstel van toepassingen te meten tegen onverwachte fouten.

In de volgende controlelijst wordt het bereik van betrouwbaarheidsplanning behandeld.

Betrouwbaarheidsplanning
Definieer beschikbaarheids- en hersteldoelen om te voldoen aan bedrijfsvereisten.
Ontwerp de betrouwbaarheidsfuncties van uw toepassingen op basis van de beschikbaarheidsvereisten.
Toepassingen en gegevensplatformen afstemmen om te voldoen aan uw betrouwbaarheidsvereisten.
Configureer verbindingspaden om de beschikbaarheid te verhogen.
Gebruik waar van toepassing beschikbaarheidszones en planning voor herstel na noodgevallen om de betrouwbaarheid te verbeteren en de kosten te optimaliseren.
Zorg ervoor dat uw toepassingsarchitectuur bestand is tegen fouten.
Weet wat er gebeurt als niet aan de SLA-vereisten wordt voldaan.
Identificeer mogelijke storingspunten in het systeem. Het toepassingsontwerp moet afhankelijkheidsfouten tolereren door circuitonderbreking te implementeren.
Bouw toepassingen die werken in afwezigheid van hun afhankelijkheden.

RTO en RPO

Twee belangrijke metrieken waarmee rekening moet worden gehouden zijn beoogde hersteltijd en beoogd herstelpunt, omdat deze te maken hebben met herstel na noodgevallen.  Zie Goed ontworpen Framework-functionele en niet-functionele ontwerpvereisten voor meer informatie over functionele en niet-functionele ontwerpvereisten.

  • Beoogde hersteltijd (RTO, Recovery Time Objective) is de maximaal te accepteren tijd gedurende welke een toepassing na een incident niet beschikbaar mag zijn.

  • Beoogd herstelpunt (RPO, Recovery Point Objective) is de maximaal te accepteren periode van gegevensverlies tijdens een noodgeval.

RTO en RPO zijn niet-functionele vereisten van een systeem en moeten worden bepaald door bedrijfsvereisten. Om deze waarden te bepalen, raden wij aan om een risicoanalyse uit te voeren en de kosten van downtime of gegevensverlies in kaart te brengen.  

Regio’s en beschikbaarheidszones

Regio's en beschikbaarheidszones maken een groot deel uit van de betrouwbaarheidsvergelijking. Regio's hebben meerdere, fysiek gescheiden beschikbaarheidszones. Deze beschikbaarheidszones zijn verbonden door een netwerk met hoge prestaties met minder dan 2 ms latentie tussen fysieke zones. Lage latentie helpt uw gegevens gesynchroniseerd en toegankelijk te blijven wanneer er iets misgaat. U kunt deze infrastructuur strategisch gebruiken tijdens het ontwerpen van toepassingen en gegevensinfrastructuur die automatisch ononderbroken services tussen zones en tussen regio's repliceren en leveren.

Microsoft Azure-services bieden ondersteuning voor beschikbaarheidszones en zijn ingeschakeld om uw cloudbewerkingen optimaal beschikbaar te maken en tegelijkertijd uw strategiebehoeften voor meerdere regio's en bedrijfscontinuïteit te ondersteunen.

Voor herstel na noodgevallen bieden regio's die zijn gekoppeld aan andere regio's replicatie tussen regio's en bescherming door asynchroon gegevens te repliceren in andere Azure-regio's. Regio's zonder paar volgen richtlijnen voor gegevenslocatie en bieden hoge beschikbaarheid met beschikbaarheidszones en lokaal redundante of zone-redundante opslag. Klanten moeten plannen voor herstel na noodgevallen in meerdere regio's op basis van hun RTO-/RPO-behoeften.

Kies de beste regio voor uw behoeften op basis van technische en wettelijke overwegingen: servicemogelijkheden, gegevenslocatie, nalevingsvereisten, latentie en begin met het doorvoeren van uw betrouwbaarheidsstrategie. Zie Azure-regio's en beschikbaarheidszones voor meer informatie.

Azure-serviceafhankelijkheden

Microsoft Azure-services zijn wereldwijd beschikbaar om uw cloudbewerkingen op een optimaal niveau te stimuleren.

Azure-services die zijn geïmplementeerd in Azure-regio's, worden weergegeven op de pagina producten van de globale infrastructuur van Azure. Zie Regio's en Beschikbaarheidszones in Azure voor meer inzicht in regio's en Beschikbaarheidszones in Azure.

Azure-services zijn gebouwd voor betrouwbaarheid, waaronder hoge beschikbaarheid en herstel na noodgevallen. Er zijn geen services die afhankelijk zijn van één logisch datacenter (om single points of failure te voorkomen). Niet-regionale services die worden vermeld in globale Azure-infrastructuurproducten zijn services waarvoor geen afhankelijkheid is van een specifieke Azure-regio. Niet-regionale services worden geïmplementeerd in twee of meer regio's en als er een regionale storing optreedt, blijft het exemplaar van de service in een andere regio serviceklanten onderhouden. Met bepaalde niet-regionale services kunnen klanten de regio opgeven waar de onderliggende virtuele machine (VM) waarop de service wordt uitgevoerd, worden geïmplementeerd. Met Azure Virtual Desktop kunnen klanten bijvoorbeeld de regiolocatie opgeven waar de VIRTUELE machine zich bevindt. Met alle Azure-services die klantgegevens opslaan, kan de klant de specifieke regio's opgeven waarin hun gegevens worden opgeslagen. De uitzondering is Microsoft Entra ID, die geografische plaatsing heeft (zoals Europa of Noord-Amerika). Zie de toewijzing gegevenslocatie voor meer informatie over gegevensopslaglocatie.

Als u afhankelijkheden tussen Azure-services moet begrijpen om uw toepassingen en services beter te ontwerpen, kunt u de documentatie voor Azure-serviceafhankelijkheid aanvragen door contact op te vragen met uw Microsoft-verkoop- of klantvertegenwoordiger. Dit document bevat de afhankelijkheden voor Azure-services, inclusief afhankelijkheden van algemene interne services, zoals besturingsvlakservices. Als u deze documentatie wilt verkrijgen, moet u een Microsoft-klant zijn en beschikken over de juiste geheimhoudingsovereenkomst (NDA) met Microsoft.

Volgende stappen