Utforma tillförlitliga Azure-program

Azure-hanterade tjänster ger inbyggda återhämtningsfunktioner för att stödja övergripande programtillförlitlighet. PaaS-erbjudanden (Plattform som en tjänst) bör användas för att utnyttja dessa funktioner. PaaS-alternativ är enklare att konfigurera och administrera. Du behöver inte etablera virtuella datorer, konfigurera virtuella nätverk, hantera korrigeringar och uppdateringar och all annan overhead som förknippas med att köra programvara på en virtuell dator. Mer information finns i Använda hanterade tjänster.

Har programmet utformats för att skala ut?

Azure ger elastisk skalbarhet och du bör utforma för att skala ut. Program måste dock använda en skalningsenhetsmetod för att navigera i tjänst- och prenumerationsgränser för att säkerställa att enskilda komponenter och programmet som helhet kan skalas horisontellt. Glöm inte att skala in, vilket är viktigt för att öka kostnaderna. Till exempel skala in och ut för App Service görs via regler. Kunder skriver ofta utskalningsregler och skriver aldrig in skalning i regler. Detta gör App Service dyrare.

Distribueras programmet över flera Azure-prenumerationer?

Det är viktigt att förstå prenumerationslandskapet i programmet och hur komponenter organiseras i eller mellan prenumerationer när du analyserar om relevanta prenumerationsgränser eller kvoter kan navigeras. Granska Azure-prenumeration och tjänstbegränsningar för att verifiera att kapaciteten som krävs ligger inom azure-tjänstens skalningsgränser och kvoter. Mer information finns i Azure-prenumeration och tjänstbegränsningar.

Nästa steg

Relaterade länkar

• Information om hur du minimerar beroenden finns i Minimera samordning.
• Mer information om felpunkter och fellägen finns i Fellägesanalys för Azure-program.
• Information om hanterade tjänster finns i Använda PaaS-alternativ (plattform som en tjänst).

Gå tillbaka till huvudartikeln: Design

Att skapa ett tillförlitligt program i molnet skiljer sig från traditionell programutveckling. Tidigare kanske du har köpt nivåer av redundant maskinvara på högre nivå för att minimera risken för att en hel programplattform misslyckas, men i molnet bekräftar vi att fel kommer att inträffa. Målet är att minimera effekten av en enda komponent som havererar snarare än att förhindra fel helt och hållet. Fel som du kan förvänta dig här beror på starkt distribuerade system, inte en funktion i Azure.

Viktiga punkter

• Använd Tillgänglighetszoner om tillämpligt för att förbättra tillförlitligheten och optimera kostnaderna.
• Utforma program som ska fungera när de påverkas av fel.
• Använd De inbyggda återhämtningsfunktionerna i PaaS för att stödja övergripande programtillförlitlighet.
• Designa för att skala ut.
• Kontrollera att den kapacitet som krävs ligger inom Azure-tjänstens skalningsgränser och kvoter.

Använda Tillgänglighetszoner inom en region

Om dina krav kräver en ännu större felisolering än vad Tillgänglighetszoner kan erbjuda kan du överväga att distribuera till flera regioner. Flera regioner bör användas för redundans i ett katastroftillstånd. Ytterligare kostnader måste beaktas. Exempel på kostnadsbehov är data och nätverk och tjänster som Azure Site Recovery.

Utforma din programarkitektur så att den Tillgänglighetszoner inom en region. Tillgänglighetszoner kan användas för att optimera programtillgänglighet inom en region genom att tillhandahålla feltolerans på datacenternivå. Programarkitekturen får dock inte dela beroenden mellan zoner för att använda dem på ett effektivt sätt.

Överväg om komponentens närhet krävs av programprestandaskäl. Om hela eller delar av programmet är mycket känsligt för svarstider kan det kräva samplatsen för komponenter som kan begränsa tillämpligheten för strategier för flera regioner och flera zoner.

Svara på fel

Det går inte att undvika haveri i det offentliga molnet, och därför kräver program motståndskraft för att svara på avbrott och leverera tillförlitlighet. Programmet bör därför utformas för att fungera även om det påverkas av regionala, zonindelade fel, tjänst- eller komponentfel i kritiska programscenarier och funktioner. Programåtgärder kan uppleva nedsatt funktionalitet eller försämrad prestanda under ett avbrott.

Definiera en tillgänglighetsstrategi för att avbilda hur programmet förblir tillgängligt när det är i ett feltillstånd. Det bör gälla för alla programkomponenter och programdistributionsstämpeln som helhet, till exempel via distributionsmetod för multi-geo-skalningsenhet. Det finns även kostnadskonsekvenser: Fler resurser måste etableras i förväg för att ge hög tillgänglighet. Aktiv-aktiv-konfiguration, medan det är dyrare än en enskild distribution, kan balansera kostnaden genom att minska belastningen på en stämpel och minska den totala mängden resurser som behövs.

Förutom en tillgänglighetsstrategi definierar du en bcdr-strategi för haveriberedskap för affärskontinuier (BCDR) för programmet och/eller dess nyckelscenarier. En strategi för haveriberedskap bör avbilda hur programmet svarar på en katastrofsituation, till exempel ett regionalt avbrott eller förlust av en kritisk plattformstjänst, med hjälp av antingen en aktiv-passiv-återdistribution, varmreservant eller aktiv-aktiv-reservstrategi.

Om du vill öka kostnaderna kan du dela upp programkomponenter och data i grupper. Till exempel:

• Måste skydda
• Bra att skydda
• Tillfälliga/kan återskapas/gå förlorade i stället för att skydda alla data med samma princip

Överväganden för att förbättra tillförlitligheten

Är programmet utformat för att använda hanterade tjänster?