Designmetodik för verksamhetskritiska arbetsbelastningar i Azure
Att skapa ett verksamhetskritiskt program på alla molnplattformar kräver betydande teknisk expertis och tekniska investeringar, särskilt eftersom det finns betydande komplexitet i samband med:
- Förstå molnplattformen
- Välja rätt tjänster och sammansättning,
- Tillämpa rätt tjänstkonfiguration,
- Operationalisera tjänster som används och
- Ständigt i linje med de senaste metodtipsen och tjänstöversikterna.
Den här designmetoden strävar efter att ge en enkel designväg som hjälper dig att navigera i den här komplexiteten och informera designbeslut som krävs för att skapa en optimal målarkitektur.
1 – Designa för affärskrav
Alla verksamhetskritiska arbetsbelastningar har inte samma krav. Förvänta dig att granskningsöverväganden och designrekommendationer som tillhandahålls av den här designmetoden ger olika designbeslut och kompromisser för olika programscenarier.
Välj en tillförlitlighetsnivå
Tillförlitlighet är ett relativt begrepp och för att alla arbetsbelastningar ska vara korrekt tillförlitliga bör det återspegla de affärskrav som omger den. Till exempel kräver en verksamhetskritisk arbetsbelastning med ett servicenivåmål på 99,999 % tillgänglighet (SLO) en mycket högre tillförlitlighetsnivå än en annan mindre kritisk arbetsbelastning med ett servicenivåmål på 99,9 %.
Den här designmetoden tillämpar begreppet tillförlitlighetsnivåer uttryckt som tillgänglighets-SLO:er för att informera nödvändiga tillförlitlighetsegenskaper. Tabellen nedan innehåller tillåtna felbudgetar som är associerade med vanliga tillförlitlighetsnivåer.
| Tillförlitlighetsnivå (tillgänglighets-SLO) | Tillåten stilleståndstid (vecka) | Tillåten stilleståndstid (månad) | Tillåten stilleståndstid (år) |
|---|---|---|---|
| 99,9 % | 10 minuter, 4 sekunder | 43 minuter, 49 sekunder | 8 timmar, 45 minuter, 56 sekunder |
| 99,95 % | 5 minuter, 2 sekunder | 21 minuter, 54 sekunder | 4 timmar, 22 minuter, 58 sekunder |
| 99,99 % | 1 minut | 4 minuter och 22 sekunder | 52 minuter, 35 sekunder |
| 99,999 % | 6 sekunder | 26 sekunder | 5 minuter, 15 sekunder |
| 99.9999% | <1 sekund | 2 sekunder | 31 sekunder |
Viktigt
Tillgänglighets-SLO anses enligt den här designmetoden vara mer än enkel drifttid, utan snarare en konsekvent nivå av programtjänst i förhållande till ett känt felfritt programtillstånd.
Som en första övning rekommenderas läsarna att välja en måltillförlitlighetsnivå genom att fastställa hur mycket stilleståndstid som är acceptabel? Strävan efter en viss tillförlitlighetsnivå kommer i slutändan att ha stor betydelse för designvägen och omfattande designbeslut, vilket kommer att resultera i en annan målarkitektur.
Den här bilden visar hur olika tillförlitlighetsnivåer och underliggande affärskrav påverkar målarkitekturen för en konceptuell referensimplementering, särskilt när det gäller antalet regionala distributioner och använda globala tekniker.
Mål för återställningstid (RTO) och mål för återställningspunkt (RPO) är ytterligare viktiga aspekter när du fastställer nödvändig tillförlitlighet. Om du till exempel strävar efter att uppnå en program-RTO på mindre än en minut är säkerhetskopieringsbaserade återställningsstrategier eller en aktiv-passiv distributionsstrategi sannolikt otillräcklig.
2 – Utvärdera designområden med hjälp av designprinciperna
Kärnan i den här metoden är en kritisk designväg som består av:
- Grundläggande designprinciper
- Grundläggande designområde med kraftigt sammankopplade och beroende designbeslut.
Effekten av beslut som fattas inom varje designområde kommer att återkomma över andra designområden och designbeslut. Granska de överväganden och rekommendationer som tillhandahålls för att bättre förstå konsekvenserna av omfattande beslut, som kan skapa kompromisser inom relaterade designområden.
Om du till exempel vill definiera en målarkitektur är det viktigt att avgöra hur du bäst övervakar programmets hälsa för viktiga komponenter. Vi rekommenderar starkt att du granskar designområdet för hälsomodellering med hjälp av de rekommenderade rekommendationerna som hjälper dig att fatta beslut.
3 – Distribuera ditt första verksamhetskritiska program
Se dessa referensarkitekturer som beskriver designbeslut baserat på den här metoden.
Tips
Arkitekturen backas upp av Mission-Critical Online-implementering som illustrerar designrekommendationerna.
Artefakter i produktionsklass Varje teknisk artefakt är redo att användas i produktionsmiljöer med alla operativa aspekter från slutpunkt till slutpunkt.
Rotad i verkliga upplevelser Alla tekniska beslut styrs av erfarenheter från Azure-kunder och lärdomar från distributionen av dessa lösningar.
Anpassning av Azure-översikt De verksamhetskritiska referensarkitekturerna har en egen översikt som är anpassad till Azures produktöversikter.
4 – Integrera din arbetsbelastning i Azure-landningszoner
Azure-prenumerationer för landningszoner tillhandahåller delad infrastruktur för företagsdistributioner som behöver centraliserad styrning.
Det är viktigt att utvärdera vilket anslutningsanvändningsfall som krävs av ditt verksamhetskritiska program. Azure-landningszoner stöder två huvudsakliga arketyper som är avgränsade i olika hanteringsgruppsomfång: Online eller Corp. som du ser i den här bilden.
Onlineprenumeration
En verksamhetskritisk arbetsbelastning fungerar som en oberoende lösning, utan någon direkt företagsnätverksanslutning till resten av Azure-landningszonens arkitektur. Programmet skyddas ytterligare genom den principdrivna styrningen och integreras automatiskt med centraliserad plattformsloggning via principen.
Baslinjearkitekturen och implementeringen av Mission-Critical Online överensstämmer med onlinemetoden.
Corp.-prenumeration
När den distribueras i en Corp.-prenumeration är en verksamhetskritisk arbetsbelastning beroende av Azure-landningszonen för att tillhandahålla anslutningsresurser. Den här metoden möjliggör integrering med andra program och delade tjänster. Du måste utforma några grundläggande resurser, som kommer att finnas i förväg som en del av plattformen för delade tjänster. Till exempel bör den regionala distributionsstämpeln inte längre omfatta en tillfällig Virtual Network eller Azure Privat DNS Zone eftersom dessa kommer att finnas i Corp.-prenumerationen.
För att komma igång med det här användningsfallet rekommenderar vi baslinjearkitekturen i en referensarkitektur för Azure-landningszoner .
Tips
Den föregående arkitekturen backas upp av verksamhetskritisk ansluten implementering.
5 – Distribuera en sandbox-programmiljö
Parallellt med designaktiviteter rekommenderar vi starkt att en sandbox-programmiljö upprättas med hjälp av Mission-Critical referensimplementeringar.
Detta ger praktiska möjligheter att validera designbeslut genom att replikera målarkitekturen, så att designosäkerhet snabbt kan utvärderas. Om de tillämpas korrekt med representativ kravtäckning kan de flesta problematiska problem som sannolikt hindrar förloppet upptäckas och åtgärdas senare.
6 – Utvecklas kontinuerligt med Azure-översikter
Programarkitekturer som upprättas med den här designmetoden måste fortsätta att utvecklas i linje med Azure-plattformens översikter för att stödja optimerad hållbarhet.
Nästa steg
Granska designprinciperna för verksamhetskritiska programscenarier.