Scenarier med hög tillgänglighet och haveriberedskap för IaaS-appar

Azure Site Recovery
Azure Virtual Machines
Azure Disk Storage

Den här artikeln innehåller ett beslutsträd och exempel på alternativ för hög tillgänglighet (HA) och haveriberedskap (DR) när du distribuerar IaaS-appar (infrastruktur som en tjänst) i flera nivåer till Azure.

Arkitektur

This diagram illustrates the high availability decision tree.

Arbetsflöde

Tillgänglighetsuppsättningar (AS) ger redundans och tillgänglighet för virtuella datorer i ett datacenter genom att distribuera virtuella datorer över flera isolerade maskinvarunoder. En delmängd av de virtuella datorerna fortsätter att köras under planerad eller oplanerad stilleståndstid, så hela appen förblir tillgänglig och i drift.

Tillgänglighetszoner (AZs) är unika fysiska platser som sträcker sig över datacenter i en Azure-region. Varje AZ har åtkomst till ett eller flera datacenter som har oberoende ström, kylning och nätverk, och varje AZ-aktiverad Azure-region har minst tre separata AZs. Den fysiska separationen av AZs i en region skyddar distribuerade virtuella datorer från datacenterfel.

Beslutsflödesschemat återspeglar principen att HA-appar ska använda AZs om möjligt. Ha tillhandahåller > 99,99 % serviceavtal i flera zoner och därmed över datacenter på grund av motståndskraft mot datacenterfel.

ASs och AZs för olika appnivåer är inte garanterade att finnas inom samma datacenter. Om appfördröjning är ett primärt problem bör du samlokalisera tjänster i ett enda datacenter med hjälp av närhetsplaceringsgrupper (PPG:er) med AZs och AS.

Komponenter

Alternativ

  • Om appen kan replikera data internt kan du som ett alternativ till regional dr med Hjälp av Azure Site Recovery implementera dr i flera regioner med hjälp av servrar med frekvent/kall vänteläge, till exempel ett utsträckt kluster endast för DR. Det här alternativet beskrivs inte specifikt i exemplen, men kan läggas till i någon av lösningarna. Observera att replikeringen mellan regioner är asynkron och att viss dataförlust förväntas.

    Om du har en egen datareplikeringsteknik kan du också använda den för att skapa en sekundär zon i regionen för DR. Beroende på regionen för dina arbetsbelastningar kan det också vara möjligt att använda Azure Site Recovery för att replikera objekt till en alternativ zon. Du kan kontrollera regional tillgänglighet och läsa mer om den här funktionen i Aktivera zon-till-zon-haveriberedskap för virtuella Azure-datorer.

  • Ha för flera regioner är möjligt, men kräver en global lastbalanserare som Front Door eller Traffic Manager. Mer information finns i Köra ett N-nivåprogram i flera Azure-regioner för hög tillgänglighet.

Information om scenario

Arkitekturer på flera nivåer eller n-nivå är vanliga i traditionella lokala appar, så de är ett naturligt val för migrering av lokala appar till molnet eller när du utvecklar appar för både lokalt och molnet. N-nivåarkitekturer implementeras vanligtvis som IaaS-appar indelade i logiska lager och fysiska nivåer, med en topp webb- eller presentationsnivå, en mellannivå och en datanivå.

I en IaaS n-nivåapp körs varje nivå på en separat uppsättning virtuella datorer. Webb- och affärsnivåerna är tillståndslösa, vilket innebär att alla virtuella datorer på nivån kan hantera alla begäranden för den nivån. Datanivån är en replikerad databas, objektlagring eller fillagring. Flera virtuella datorer på varje nivå ger återhämtning om en virtuell dator misslyckas och lastbalanserare distribuerar begäranden mellan de virtuella datorerna.

Du kan skala ut nivåer genom att lägga till fler virtuella datorer i poolerna och använda vm-skalningsuppsättningar för att automatiskt skala ut identiska virtuella datorer. Eftersom du använder lastbalanserare kan du skala ut nivåer utan att påverka appens drifttid.

Om serviceavtalet (SLA) för en IaaS-app kräver > 99 % tillgänglighet kan du placera virtuella datorer i tillgänglighetsuppsättningar, tillgänglighetszoner och närhetsplaceringsgrupper för att konfigurera hög tillgänglighet för appen. Vilka HA- och DR-lösningar du väljer beror på vilket serviceavtal som krävs, svarstidsöverväganden och regionala DR-krav.

Potentiella användningsfall

  • Migrera en n-nivåapp från lokal plats till molnet.
  • Distribuera en n-nivåapp både lokalt och till molnet.
  • Konfigurera hög tillgänglighet och haveriberedskap för en IaaS-app.

Den här lösningen kan användas för alla branscher, inklusive följande scenarier:

  • Program inom den offentliga sektorn
  • Banktjänster (finansbranschen)
  • Sjukvård

Att tänka på

  • AZs är inte tillgängliga i alla Azure-regioner.

  • Bestäm vilket distributionsalternativ du vill använda innan du skapar lösningen. Även om det är möjligt är det inte lätt att gå från ett alternativ till ett annat efter distributionen. Du måste ta bort de virtuella datorerna och återskapa dem från de underliggande hanterade diskarna, vilket är en involverad process.

  • Se till att du kan mappa ditt program mot den valda lösningen. Många mönster och design för återhämtning av appskikt ligger utanför omfånget för det här beslutsträdet.

  • Tre scenarier kan leda till omstarter av virtuella Azure-datorer: oplanerat maskinvaruunderhåll, oväntad stilleståndstid och planerat underhåll. Mer information om dessa händelser och bästa praxis för hög tillgänglighet för att minska deras påverkan finns i Förstå omstarter av virtuella datorer, underhåll kontra stilleståndstid.

Enskilda virtuella datorer

Om en app inte kräver > 99,9 % tillgänglighet behöver du inte konfigurera den för HA och kan distribuera enskilda virtuella datorer. Du kan använda vm-skalningsuppsättningar för att automatiskt skala ut identiska virtuella datorer. Distribuera enskilda virtuella datorer utan att ange en zon, så att de distribueras i en region. Dessa appar har ett serviceavtal på 99,9 % om du använder Azure Premium SSD-diskar.

Enskilda virtuella datorer använder standardfunktionerna för tjänståterställning inbyggda i alla Azure-datacenter. För förutsägbara fel använder den här funktionen vanligtvis direktmigrering, men under oförutsägbara händelser kan virtuella datorer startas om eller göras otillgängliga.

Hög tillgänglighet

Om appen kräver ett serviceavtal på > 99,9 % utformar du appen för HA. Använd AZs om möjligt, eftersom de ger feltolerans för datacenter. Du kan använda ASs i stället för AZs, men med hjälp av ASs minskar tillgängligheten från 99,99 % till 99,95 %, eftersom ASS inte kan tolerera datacenterfel.

AZ:er är lämpliga för många klustrade appscenarier, inklusive AlwaysOn SQL-kluster, aktiv-aktiv, aktiv-passiv eller en kombination av båda HA-nivåerna på varje nivå med snabb redundans. Synkron replikering är möjlig mellan alla DBMS-noder (Database Management System) på grund av den låga svarstiden för det zonöverskridande nätverket. Du kan också köra en konfiguration för stretchkluster mellan zoner, som har högre svarstid och stöder asynkron replikering.

Om du vill använda en VM-baserad klusterdomare, till exempel ett filresursvittne, placerar du det i den tredje AZ:n för att säkerställa att kvorumet inte går förlorat om någon zon misslyckas. Du kan också använda ett molnbaserat vittne i en annan region.

Alla virtuella datorer i en AZ finns i en enda feldomän (FD) och uppdateringsdomän (UD), vilket innebär att de delar en gemensam strömkälla och nätverksväxel och alla kan startas om samtidigt. Om du skapar virtuella datorer mellan olika AZ:er distribueras dina virtuella datorer effektivt över olika FD:er och UD:er, så att de inte alla misslyckas eller startas om samtidigt. Om du vill ha redundanta virtuella datorer i zonen samt virtuella datorer mellan zoner bör du placera de virtuella datorerna i zonen i AS:er i PPG:er för att säkerställa att alla inte startas om samtidigt. Även för vm-arbetsbelastningar med en instans som inte är redundanta i dag kan du fortfarande använda ASs i PPG:erna för att möjliggöra framtida tillväxt och flexibilitet.

Om du vill distribuera vm-skalningsuppsättningar mellan AZ:er bör du överväga att använda orkestreringsläge, för närvarande i offentlig förhandsversion, vilket gör det möjligt att kombinera FD:er och AZs.

AZ:er med ppg:er i zonen tillåter en av de lägsta nätverksfördröjningarna i Azure och ett serviceavtal på minst 99,99 % på grund av återhämtning med flera datacenter. Använd accelererat nätverk på de virtuella datorerna där det är möjligt.

Den här lösningen kan presentera ett scenario där en tjänst som körs på en virtuell dator i en zon måste interagera med en tjänst i en annan zon. Det kan till exempel finnas en aktiv-aktiv webbnivå och en aktiv-passiv databasnivå mellan zoner. Vissa begäranden kommer att korsa zoner, vilket medför svarstid. Även om svarstiden mellan zoner fortfarande är mycket låg, bör du behålla all nätverkskommunikation mellan appnivåer inom en zon om du behöver säkerställa lägsta möjliga svarstid.

Överväganden för svarstid

Nätverksfördröjning beror bland annat på det fysiska avståndet mellan distribuerade virtuella datorer. Om en app kräver mycket låg svarstid mellan nivåer kan du distribuera den i ett enda datacenter med hjälp av en PPG med AS för varje nivå. Använd om möjligt accelererat nätverk på de virtuella datorerna. Det här scenariot tillåter en av de lägsta nätverksfördröjningarna i Azure och ett serviceavtal på 99,95 %.

Du kan använda följande verktyg för att få bättre insikt i svarstidsförhållanden för en mängd olika scenarier:

  • Information om hur du testar svarstiden mellan virtuella datorer finns i Testa svarstiden för virtuella datorers nätverk.
  • Om du vill testa svarstiden mellan zoner använder du AvZone-Latency-Test. Det här testet kan hjälpa dig att avgöra vilka logiska zoner som har lägst svarstid för din prenumeration.
  • Om du vill testa svarstiden mellan Azure-regioner använder du http://www.azurespeed.com/. Det här regelbundet uppdaterade verktyget kan vara användbart när du överväger asynkron replikering mellan regioner.

Haveriberedskap

Dr-överväganden inkluderar tillgänglighet, appens möjlighet att fortsätta köras i ett felfritt tillstånd och datahållbarhet, bevarande av data om en katastrof inträffar.

HA-redundansväxling bör vara snabb, utan dataförlust och ha en mycket begränsad effekt på tjänsten. Däremot kan en traditionell dr-redundans ha ett längre associerat mål för återställningstid (RTO) och mål för återställningspunkt (RPO) och är asynkron, med potentiell dataförlust.

Du kan dra nytta av AZs för både HA och DR genom att använda en annan AZ för din DR-lösning. Men att använda en annan AZ garanterar inte att datacenter i varje AZ kommer att finnas fysiskt långt ifrån varandra.

Med Azure Site Recovery kan du replikera virtuella datorer till en annan Azure-region för regional haveriberedskap och affärskontinuitet. Du kan använda Azure Site Recovery för att återställa dina appar i händelse av avbrott i källregionen eller utföra regelbundna haveriberedskapstest för att säkerställa att du uppfyller efterlevnadskraven.

Om din app stöder Azure Site Recovery kan du tillhandahålla en regional DR-lösning för ökat skydd, om appens allvarlighetsgrad kräver det. Det kan dock vara tillräckligt med skydd mellan zoner och datacenter, för om en app är helt motståndskraftig mot datacenterfel bör det inte finnas någon avbrottstid eller dataförlust.

Kostnadsoptimering

Det finns ingen extra kostnad för virtuella datorer som distribueras i AZs. Det kan finnas ytterligare avgifter för dataöverföring mellan virtuella datorer mellan AZ-datorer. Mer information finns på sidan Bandbreddspriser.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

Nästa steg