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.

• Baslinjearkitektur för ett internetuppkopplad program

• Baslinjearkitektur för ett internetuppkopplad program med nätverkskontroller

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.

Designprinciper