Ontwerpmethodologie voor bedrijfskritieke workloads in Azure
Het bouwen van een bedrijfskritieke toepassing op elk cloudplatform vereist aanzienlijke technische expertise en technische investeringen, met name omdat er sprake is van een aanzienlijke complexiteit van:
- Inzicht in het cloudplatform,
- Het kiezen van de juiste diensten en samenstelling,
- De juiste serviceconfiguratie toepassen,
- Gebruikte services operationeel maken, en
- Voortdurend afstemmen op de nieuwste best practices en serviceroadmaps.
Deze ontwerpmethodologie streeft ernaar een eenvoudig te volgen ontwerppad te bieden om deze complexiteit te helpen navigeren en ontwerpbeslissingen te nemen die nodig zijn om een optimale doelarchitectuur te produceren.
1: ontwerpen voor bedrijfsvereisten
Niet alle bedrijfskritieke workloads hebben dezelfde vereisten. Verwacht dat de beoordelingsoverwegingen en ontwerpaanbevelingen van deze ontwerpmethodologie verschillende ontwerpbeslissingen en afwegingen voor verschillende toepassingsscenario's opleveren.
Selecteer een betrouwbaarheidslaag
Betrouwbaarheid is een relatief concept en om een workload op de juiste wijze betrouwbaar te maken, moet deze overeenkomen met de bedrijfsvereisten eromheen. Een bedrijfskritieke workload met een beschikbaarheid van 99,999% Service Level Objective (SLO) vereist bijvoorbeeld een veel hoger betrouwbaarheidsniveau dan een andere minder kritieke workload met een SLO van 99,9%.
Deze ontwerpmethodologie past het concept van betrouwbaarheidslagen toe die worden uitgedrukt als beschikbaarheids-SLO's om vereiste betrouwbaarheidskenmerken te informeren. In de onderstaande tabel worden toegestane foutbudgetten vastgelegd die zijn gekoppeld aan algemene betrouwbaarheidslagen.
| Betrouwbaarheidslaag (beschikbaarheids-SLO) | Toegestane downtime (week) | Toegestane downtime (maand) | Toegestane downtime (jaar) |
|---|---|---|---|
| 99,9% | 10 minuten, 4 seconden | 43 minuten, 49 seconden | 8 uur, 45 minuten, 56 seconden |
| 99.95% | 5 minuten, 2 seconden | 21 minuten, 54 seconden | 4 uur, 22 minuten, 58 seconden |
| 99,99% | 1 minuut | 4 minuten en 22 seconden | 52 minuten, 35 seconden |
| 99,999% | 6 seconden | 26 seconden | 5 minuten, 15 seconden |
| 99.9999% | <1 seconde | 2 seconden | 31 seconden |
Belangrijk
Beschikbaarheids-SLO wordt door deze ontwerpmethodologie beschouwd als meer dan eenvoudige uptime, maar eerder een consistent niveau van toepassingsservice ten opzichte van een bekende, gezonde toepassingsstatus.
Als eerste oefening wordt lezers geadviseerd om een doelbetrouwbaarheidslaag te selecteren door te bepalen hoeveel downtime acceptabel is? Het nastreven van een bepaalde betrouwbaarheidslaag heeft uiteindelijk een belangrijke invloed op het ontwerppad en omvat ontwerpbeslissingen, wat resulteert in een andere doelarchitectuur.
In deze afbeelding ziet u hoe de verschillende betrouwbaarheidslagen en onderliggende bedrijfsvereisten van invloed zijn op de doelarchitectuur voor een conceptuele referentie-implementatie, met name wat betreft het aantal regionale implementaties en gebruikte wereldwijde technologieën.
RTO (Recovery Time Objective) en RPO (Recovery Point Objective) zijn andere essentiële aspecten bij het bepalen van de vereiste betrouwbaarheid. Als u bijvoorbeeld een toepassings-RTO van minder dan een minuut wilt bereiken, zijn herstelstrategieën op basis van back-ups of een actief-passieve implementatiestrategie waarschijnlijk onvoldoende.
2: Evalueer de ontwerpgebieden met behulp van de ontwerpprincipes
De kern van deze methodologie is een kritiek ontwerppad dat bestaat uit:
- Basisprincipes voor ontwerp
- Fundamenteel ontwerpgebied met sterk onderling verbonden en afhankelijke ontwerpbeslissingen.
De impact van beslissingen die binnen elk ontwerpgebied worden genomen, zal zich herhalen in andere ontwerpgebieden en ontwerpbeslissingen. Bekijk de verstrekte overwegingen en aanbevelingen om meer inzicht te krijgen in de gevolgen van ingesloten beslissingen, die kunnen leiden tot compromissen binnen gerelateerde ontwerpgebieden.
Als u bijvoorbeeld een doelarchitectuur wilt definiëren, is het essentieel om te bepalen hoe de toepassingsstatus het beste kan worden bewaakt voor de belangrijkste onderdelen. We raden u ten zeerste aan om het ontwerpgebied voor statusmodellering te bekijken met behulp van de beschreven aanbevelingen om beslissingen te nemen.
3: Uw eerste bedrijfskritieke toepassing implementeren
Raadpleeg deze referentiearchitecturen waarin de ontwerpbeslissingen op basis van deze methodologie worden beschreven.
Tip
De architectuur wordt ondersteund door een bedrijfskritieke online-implementatie die de ontwerpaanbevelingen illustreert.
Artefacten op productieniveau Elk technisch artefact is klaar voor gebruik in productieomgevingen, waarbij rekening wordt gehouden met alle end-to-end operationele aspecten.
Geworteld in echte ervaringen Alle technische beslissingen worden geleid door ervaringen van Azure-klanten en lessen die zijn geleerd bij het implementeren van deze oplossingen.
Uitlijning van Azure-roadmap De bedrijfskritieke referentiearchitecturen hebben hun eigen roadmap die is afgestemd op Azure-productroadmaps.
4: Uw workload integreren in Azure-landingszones
Azure-landingszoneabonnementen bieden een gedeelde infrastructuur voor bedrijfsimplementaties waarvoor gecentraliseerd beheer nodig is.
Het is van cruciaal belang om te evalueren welke connectiviteitsgebruikscase vereist is voor uw bedrijfskritieke toepassing. Azure-landingszones ondersteunen twee hoofd archetypen, gescheiden in verschillende beheergroepbereiken: Online of Corp. zoals weergegeven in deze afbeelding.
Online abonnement
Een bedrijfskritieke workload werkt als een onafhankelijke oplossing, zonder directe bedrijfsnetwerkconnectiviteit met de rest van de Architectuur van de Azure-landingszone. De toepassing wordt verder beveiligd via de beleidsgestuurde governance en wordt automatisch geïntegreerd met gecentraliseerde platformlogboekregistratie via beleid.
De basislijnarchitectuur en mission-critical online implementatie zijn afgestemd op de Online-benadering.
Corp.-abonnement
Wanneer deze wordt geïmplementeerd in een Corp.-abonnement, is een bedrijfskritieke workload afhankelijk van de Azure-landingszone om connectiviteitsresources te bieden. Deze benadering maakt integratie met andere toepassingen en gedeelde services mogelijk. U moet ontwerpen rond een aantal basisresources, die vooraf zullen bestaan als onderdeel van het gedeelde serviceplatform. Het regionale implementatiestempel mag bijvoorbeeld niet langer een kortstondige Virtual Network of Azure Privé-DNS-zone omvatten, omdat deze in het Corp.-abonnement aanwezig zullen zijn.
Om aan de slag te gaan met deze use-case, raden we de basislijnarchitectuur in een referentiearchitectuur voor azure-landingszones aan.
Tip
De voorgaande architectuur wordt ondersteund door mission-critical connected-implementatie .
5: Een sandbox-toepassingsomgeving implementeren
Parallel aan ontwerpactiviteiten wordt ten zeerste aangeraden om een sandbox-toepassingsomgeving tot stand te gebracht met behulp van de Mission-Critical referentie-implementaties.
Dit biedt praktische mogelijkheden om ontwerpbeslissingen te valideren door de doelarchitectuur te repliceren, zodat ontwerponzekerheid snel kan worden beoordeeld. Als deze problemen correct worden toegepast met dekking van representatieve vereisten, kunnen de meeste problematische problemen die de voortgang waarschijnlijk belemmeren, worden ontdekt en vervolgens worden opgelost.
6: Continu ontwikkelen met Azure-roadmaps
Toepassingsarchitecturen die zijn opgezet met behulp van deze ontwerpmethodologie, moeten zich blijven ontwikkelen in overeenstemming met de roadmaps van het Azure-platform om geoptimaliseerde duurzaamheid te ondersteunen.
Volgende stap
Bekijk de ontwerpprincipes voor bedrijfskritieke toepassingsscenario's.
Feedback
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie: https://aka.ms/ContentUserFeedback.
Feedback verzenden en weergeven voor