Arbetsbelastningar i operatörsklass i Azure

Verksamhetskritiska system fokuserar främst på att maximera drifttiden och de finns i många branscher. Inom telekommunikationsindustrin kallas de för system av bärarkvalitet. Dessa system utvecklas på grund av en eller flera av följande drivrutiner:

• Minimera förlust av liv eller skada.
• Uppfylla regelkraven för tillförlitlighet för att undvika att betala böter.
• Optimera tjänsten för kunder för att minimera omsättning till konkurrenter.
• Uppfylla avtalsenliga serviceavtal (SLA) med företags- eller myndighetskunder.

Den här serien med artiklar använder designmetoden för verksamhetskritiska arbetsbelastningar för att ge vägledning för att skapa och driva en mycket tillförlitlig, elastisk och tillgänglig telekommunikationsarbetsbelastning i Azure.

Kommentar

Artiklarna i den här serien fokuserar på att ge ytterligare verksamhetskritiska överväganden vid utformning av 99,999% ("5 9s") nivåer av tillförlitlighet inom telekommunikationsindustrin.

Vad är en arbetsbelastning i bärarklass?

Termen arbetsbelastning refererar till en samling programresurser som stöder ett gemensamt affärsmål eller körning av en gemensam affärsprocess, med flera tjänster, till exempel API:er och datalager, som arbetar tillsammans för att leverera specifika funktioner från slutpunkt till slutpunkt.

Termen verksamhetskritisk avser en klassificering av kritiskhet där en betydande ekonomisk kostnad (affärskritisk) eller mänsklig kostnad (säkerhetskritisk) är förknippad med otillgänglighet eller underprestation.

En arbetsbelastning i bärarklass pivoteras på både affärskritisk och säkerhetskritisk, där det finns ett grundläggande krav på att vara i drift med bara minuter eller till och med sekunders stilleståndstid per kalenderår. Om detta drifttidskrav inte uppnås kan det leda till omfattande förluster av liv, betydande böter eller avtalsenliga påföljder.

Den operativa aspekten av arbetsbelastningen omfattar hur tillförlitlighet mäts och vilka mål den måste uppfylla eller överskrida. Mycket tillförlitliga system riktar vanligtvis in sig på 99,999 % drifttid (kallas vanligtvis "5 9:or") eller 0,001 % stilleståndstid på ett år (cirka 5 minuter). Vissa system riktar in sig på 99,9999 % drifttid, eller 30 sekunders stilleståndstid per år, eller ännu högre tillförlitlighetsnivåer. Detta omfattar alla former och orsaker till avbrott – schemalagt underhåll, infrastrukturfel, mänskliga fel, programvaruproblem och till och med naturkatastrofer.

Även om den plattform som används har utvecklats från dedikerad, proprietär maskinvara genom kommersiell, fristående maskinvara till OpenStack- eller VMware-moln, levererar telekommunikationsföretag konsekvent tjänster som uppnår ≤ 5 minuters stilleståndstid per år, och i många fall uppnår ≤ 30 sekunders stilleståndstid på grund av oplanerade avbrott.

Vilka är de vanliga utmaningarna?

Att skapa arbetsbelastningar i transportföretagsklass är en utmaning av följande huvudskäl:

Lift and shift-metoden

Telekommunikationsföretag har väldefinierade program som levererar det förväntade beteendet på sin befintliga infrastruktur. Var dock försiktig innan du antar att portning av dessa program som är till en offentlig molninfrastruktur inte påverkar deras återhämtning.

De befintliga programmen gör en uppsättning antaganden om sin underliggande infrastruktur, vilket sannolikt inte kommer att förbli sant när de flyttas från lokalt till offentligt moln. Arkitekten måste kontrollera att de fortfarande har och justerar infrastrukturen och programdesignen så att den passar den nya verkligheten. Arkitekten bör också söka efter möjligheter där den nya infrastrukturen tar bort begränsningar som fanns lokalt.

Till exempel måste uppgradering av lokala system ske på plats eftersom det inte är möjligt att underhålla tillräckligt med maskinvara för att skapa en ny distribution tillsammans med och långsamt överföra på ett säkert sätt. Den här uppgraderingsvägen genererar en mängd krav för hur uppgraderingar och återställningar hanteras. Dessa krav leder till komplexitet och innebär att uppgraderingar är ovanliga och endast tillåtna i noggrant hanterade underhållsperioder.

I det offentliga molnet är det dock rimligt att skapa en ny distribution parallellt med den befintliga distributionen. Den här processen skapar möjlighet till stora förenklingar i programmets driftsdesign och förbättringar av användarens upplevelse och förväntningar.

Monolitiska lösningar

Erfarenhet inom en rad verksamhetskritiska branscher visar att det inte är realistiskt att försöka konstruera en monolitisk lösning som uppnår önskad tillgänglighetsnivå. Det finns alldeles för många potentiella felkällor i ett komplext system. I stället består lyckade lösningar av enskilda oberoende och redundanta element. Varje enhet har relativt grundläggande tillgänglighet (vanligtvis ~99,9 %), men när den kombineras tillsammans uppnår den totala lösningen de nödvändiga tillgänglighetsmålen. Konsten att konstruktion i bärarklass blir då att se till att de enda beroenden som är gemensamma för de redundanta elementen är de som är absolut nödvändiga eftersom de utövar det mest betydande inflytandet på den övergripande tillgängligheten, ofta storleksordningar större än något annat i designen.

Endast att skapa zonredundans

Att använda Microsoft Azure-tillgänglighetszoner är det grundläggande valet för att minska risken för avbrott på grund av maskinvarufel eller lokaliserade miljöproblem. Det räcker dock inte att uppnå tillgänglighet i transportföretagsklass, främst av följande skäl:

• Tillgänglighetszoner (AZs) är utformade så att nätverksfördröjningen mellan två zoner i en enda region är ≤ 2 ms. AZs kan inte vara allmänt och geografiskt spridda. Så AZs delar en korrelerad risk för fel på grund av naturkatastrofer, till exempel översvämningar eller massiva strömavbrott, vilket kan inaktivera flera AZs inom en region.

• Många Azure-tjänster är uttryckligen utformade för att vara zonredundanta så att de program som använder dem inte behöver explicit logik för att dra nytta av tillgänglighetsvinsten. Den här redundansfunktionen i tjänsten kräver samarbete mellan elementen i varje zon. Det finns ofta en oundviklig risk för programvarufel i en zon som orsakar korrelerade fel i andra zoner. Ett problem med en hemlighet eller ett certifikat som används med den zonredundanta tjänsten kan till exempel påverka alla AZs samtidigt.

Vilka är de viktigaste designområdena?

När du utformar en arbetsbelastning i bärarklass bör du tänka på följande områden:

Designområde	beskrivning
Feltolerans	Programdesignen måste tillåta oundvikliga fel så att programmet som helhet kan fortsätta att fungera på någon nivå. Designen måste minimera felpunkter och ha en federerad metod.
Datamodell	Designen måste hantera databasens behov av konsekvens, tillgänglighet och partitionstolerans. Tillgänglighet för carrier grade kräver att programmet distribueras i flera regioner. Den här distributionen kräver noggranna tankar om hur programmets data ska hanteras i dessa regioner.
Hälsomodellering	En effektiv hälsomodell ger observerbarhet för alla komponenter, plattformar och program, så att problem snabbt kan identifieras och svar är klara antingen genom självåterställning eller andra åtgärder.
Testning och validering	Utformningen och implementeringen av programmet måste testas noggrant. Dessutom måste integreringen och distributionen av programmet som en hel lösning testas.

Gå vidare

Börja med att granska designprinciperna för programscenarier i bärarklass.

Designprinciper