Dela via

Webbprogram med flera nivåer som har skapats för HA/DR

Azure
Azure Arc
SQL Server
Windows

Det här exempelscenariot gäller för alla branscher som behöver distribuera elastiska flerstegsprogram som skapats för hög tillgänglighet och haveriberedskap. I det här scenariot består programmet av tre skikt.

  • Webbnivå: Det översta lagret inklusive användargränssnittet. Det här lagret parsar användarinteraktioner och skickar åtgärderna till nästa lager för bearbetning.
  • Affärsnivå: Bearbetar användarinteraktioner och fattar logiska beslut om nästa steg. Det här lagret ansluter webbnivån och datanivån.
  • Datanivå: Lagrar programdata. Antingen används en databas, objektlagring eller fillagring.

Vanliga programscenarier är alla verksamhetskritiska program som körs i Windows eller Linux. Detta kan vara ett program som inte är färdigt, till exempel SAP och SharePoint eller ett anpassat verksamhetsspecifikt program.

Potentiella användningsfall

Andra relevanta användningsfall är:

  • Distribuera mycket motståndskraftiga program som SAP och SharePoint
  • Utforma en plan för affärskontinuitet och haveriberedskap för verksamhetsspecifika program
  • Konfigurera haveriberedskap och utföra relaterade detaljgranskningar i efterlevnadssyfte

Arkitektur

Diagram som visar arkitekturöversikten över ett mycket elastiskt webbprogram med flera nivåer.

Ladda ned en Visio-fil med den här arkitekturen.

Arbetsflöde

  • Distribuera de virtuella datorerna på varje nivå mellan två tillgänglighetszoner i regioner som stöder zoner. I andra regioner distribuerar du de virtuella datorerna på varje nivå inom en tillgänglighetsuppsättning.
  • Databasnivån kan konfigureras för att använda AlwaysOn-tillgänglighetsgrupper. Med den här SQL Server-konfigurationen konfigureras en primär skrivskyddad replik i en tillgänglighetsgrupp med upp till åtta sekundära skrivskyddade repliker. Om ett problem uppstår med den primära repliken redundansväxlar tillgänglighetsgruppen den primära läs-/skrivaktiviteten till en av de sekundära replikerna, vilket gör att programmet kan förbli tillgängligt. Mer information finns i Översikt över AlwaysOn-tillgänglighetsgrupper för SQL Server.
  • För haveriberedskapsscenarier kan du konfigurera SQL AlwaysOn-asynkron intern replikering till målregionen som används för haveriberedskap. Du kan också konfigurera Azure Site Recovery-replikering till målregionen om dataändringsfrekvensen ligger inom gränserna för Azure Site Recovery som stöds.
  • Användare får åtkomst till klientdelens ASP.NET webbnivå via traffic manager-slutpunkten.
  • Traffic Manager omdirigerar trafik till den primära offentliga IP-slutpunkten i den primära källregionen.
  • Den offentliga IP-adressen omdirigerar anropet till en av de virtuella datorinstanserna på webbnivån via en offentlig lastbalanserare. Alla vm-instanser på webbnivå finns i ett undernät.
  • Från den virtuella webbnivån dirigeras varje anrop till en av de virtuella datorinstanserna på affärsnivån via en intern lastbalanserare för bearbetning. Alla virtuella datorer på affärsnivå finns i ett separat undernät.
  • Åtgärden bearbetas på affärsnivån och det ASP.NET programmet ansluter till Microsoft SQL Server-klustret på en serverdelsnivå via en intern Azure-lastbalanserare. Dessa SQL Server-instanser i serverdelen finns i ett separat undernät.
  • Trafikhanterarens sekundära slutpunkt konfigureras som den offentliga IP-adressen i målregionen som används för haveriberedskap.
  • I händelse av ett avbrott i den primära regionen anropar du Redundansväxling i Azure Site Recovery och programmet blir aktivt i målregionen.
  • Traffic Manager-slutpunkten omdirigerar automatiskt klienttrafiken till den offentliga IP-adressen i målregionen.

Komponenter

  • Tillgänglighetsuppsättningar är en funktion för feltolerans som säkerställer att virtuella datorer distribueras över flera isolerade maskinvarunoder i ett kluster. I den här arkitekturen skyddar tillgänglighetsuppsättningar mot maskinvaru- och programvarufel genom att se till att endast en delmängd av de virtuella datorerna påverkas under ett avbrott. Den här metoden upprätthåller programtillgänglighet och driftkontinuitet i flera nivåer.

  • Tillgänglighetszoner är separata fysiska platser i en Azure-region som skyddar program och data från datacenterfel. I den här arkitekturen ger tillgänglighetszoner högre motståndskraft genom att distribuera virtuella datorer över flera datacenter med oberoende infrastruktur för ström, kylning och nätverk.

  • Azure Load Balancer är en layer 4-lastbalanserare som distribuerar inkommande trafik enligt definierade regler och hälsoavsökningar för högt dataflöde och låg svarstid. I den här arkitekturen distribuerar en offentlig lastbalanserare inkommande klienttrafik över virtuella datorer på webbnivå, medan interna lastbalanserare dirigerar trafik från webbnivån till affärsnivån och från affärsnivån till SQL Server-klustret på serversidan.

  • Azure Traffic Manager är en DNS-baserad trafiklastbalanserare (Domain Name System) som distribuerar trafik mellan globala Azure-regioner. I den här arkitekturen tillhandahåller Traffic Manager global belastningsutjämning genom att dirigera användartrafik till den primära regionen under normala åtgärder och automatiskt omdirigera trafik till haveriberedskapsregionen under avbrott.

  • Site Recovery är en haveriberedskapstjänst som tillåter VM-replikering till en annan Azure-region för affärskontinuitet och haveriberedskap. I den här arkitekturen aktiverar Site Recovery funktioner för haveriberedskap genom att replikera virtuella datorer till en målregion för programåterställning vid avbrott i källregionen. Den stöder också efterlevnadskrav genom regelbundna haveriberedskapstest.

Alternativ

  • Windows kan ersättas av andra operativsystem eftersom ingenting i infrastrukturen är beroende av operativsystemet.
  • SQL Server för Linux kan ersätta serverdelsdatalagret.
  • Databasen kan ersättas av alla tillgängliga standarddatabasprogram.

Information om scenario

Det här scenariot visar ett program med flera nivåer som använder ASP.NET och Microsoft SQL Server. I Azure-regioner som stöder tillgänglighetszoner kan du distribuera dina virtuella datorer i en källregion mellan tillgänglighetszoner och replikera de virtuella datorerna till målregionen som används för haveriberedskap. I Azure-regioner som inte stöder tillgänglighetszoner kan du distribuera dina virtuella datorer inom en tillgänglighetsuppsättning och replikera de virtuella datorerna till målregionen.

För att dirigera trafik mellan regioner behöver du en global lastbalanserare. Det finns två huvudsakliga Azure-erbjudanden:

  • Azure Front Door-tjänsten
  • Azure Traffic Manager

När du väljer en lastbalanserare bör du tänka på dina krav och funktionsuppsättningen för de två erbjudandena. Hur snabbt vill du redundansväsna? Kan du ta på dig kostnaderna för TLS-hantering? Finns det några begränsningar för organisationens kostnader?

Front Door har Layer 7-funktioner: SSL-avlastning, sökvägsbaserad routning, snabb redundans, cachelagring och andra för att förbättra prestanda och hög tillgänglighet för dina program. Du kan uppleva snabbare paketresor eftersom infrastrukturen har registrerats i Azure-nätverket tidigare.

Eftersom Front Door lägger till ett nytt hopp, finns det ytterligare säkerhetsåtgärder. Om arkitekturen uppfyller regelkraven kan det finnas begränsningar för den ytterligare TLS-avslutningspunkten för trafik. De TLS-chiffersviter som valts av Front Door måste uppfylla organisationens säkerhetsfält. Front Door förväntar sig också att serverdelstjänsterna använder certifikat som ingår i Microsofts lista över betrodda certifikatutfärdare.

Ett annat övervägande är kostnaden. Arkitekturen bör dra nytta av den omfattande funktionsuppsättningen (inte bara redundans) för att motivera den extra kostnaden.

Traffic Manager är en DNS-baserad belastningsutjämningstjänst. Den balanserar och redundansväxlar endast på DNS-nivå. Därför kan den inte redundansväxla lika snabbt som Front Door på grund av vanliga utmaningar kring DNS-cachelagring och system som inte uppfyller DNS-TTL:er.

Du kan kombinera båda lastbalanserarna om det behövs. Du vill till exempel ha dns-baserad redundans, men du vill lägga till en POP-upplevelse framför den trafikhanterade infrastrukturen.

Den här arkitekturen använder Traffic Manager eftersom den är enkel. Tidsinställningen för redundans är tillräcklig för illustrativa syften.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som du kan använda för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Well-Architected Framework.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Checklista för designgranskning för säkerhet.

All trafik i det virtuella nätverket till programnivån på klientsidan skyddas av nätverkssäkerhetsgrupper. Regler begränsar trafikflödet så att endast de virtuella datorinstanserna på klientsidans programnivå kan komma åt serverdelsdatabasnivån. Ingen utgående Internettrafik tillåts från affärsnivån eller databasnivån. För att minska angreppsfotavtrycket är inga direkt fjärrhanteringsportar öppna. Mer information finns i Säkerhetsgrupper för Azure-nätverk.

Allmän vägledning om hur du utformar säkra scenarier finns i Azure Security-dokumentationen.

Kostnadsoptimering

Kostnadsoptimering fokuserar på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Checklista för designgranskning för kostnadsoptimering.

Om du konfigurerar haveriberedskap för virtuella Azure-datorer med Azure Site Recovery debiteras följande avgifter löpande.

  • Licensieringskostnad för Azure Site Recovery per virtuell dator.
  • Utgående nätverkskostnader för att replikera dataändringar från källdiskarna för virtuella datorer till en annan Azure-region. Azure Site Recovery använder inbyggd komprimering för att minska dataöverföringskraven med cirka 50 %.
  • Lagringskostnader på återställningsplatsen. Detta är vanligtvis samma som källregionlagringen plus eventuell ytterligare lagring som behövs för att underhålla återställningspunkterna som ögonblicksbilder för återställning.

Vi har angett en exempelkostnadskalkylator för att konfigurera haveriberedskap för ett program med tre nivåer med sex virtuella datorer. Alla tjänster är förkonfigurerade i kostnadskalkylatorn. Om du vill se hur prissättningen skulle ändras för ditt specifika användningsfall ändrar du lämpliga variabler för att beräkna kostnaden.

Prestandaeffektivitet

Prestandaeffektivitet syftar på arbetsbelastningens förmåga att skala för att effektivt uppfylla användarnas krav. Mer information finns i Checklista för designgranskning för prestandaeffektivitet.

Du kan lägga till eller ta bort virtuella datorer på varje nivå baserat på dina skalningskrav. Eftersom det här scenariot använder lastbalanserare kan du lägga till fler virtuella datorer på en nivå utan att påverka programmets drifttid.

Deltagare

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

Huvudförfattare:

Nästa steg

Mer referensarkitekturer för hög tillgänglighet och haveriberedskap finns i: