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
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ättningarna ser till att de virtuella datorer du distribuerar i Azure distribueras över flera isolerade maskinvarunoder i ett kluster. Om ett maskinvaru- eller programvarufel inträffar i Azure påverkas endast en delmängd av dina virtuella datorer och hela lösningen är tillgänglig och fungerar fortfarande.
- Tillgänglighetszoner skyddar dina program och data från datacenterfel. Tillgänglighetszoner är separata fysiska platser i en Azure-region. Varje zon består av ett eller flera datacenter som är utrustade med oberoende ström, kylning och nätverk.
- Med Azure Site Recovery kan du replikera virtuella datorer till en annan Azure-region för behov av affärskontinuitet och haveriberedskap. Du kan utföra regelbundna haveriberedskapstest för att säkerställa att du uppfyller efterlevnadsbehoven. Den virtuella datorn replikeras med de angivna inställningarna till den valda regionen så att du kan återställa dina program i händelse av driftstopp i källregionen.
- Azure Traffic Manager är en DNS-baserad trafiklastbalanserare som distribuerar trafik optimalt till tjänster i globala Azure-regioner samtidigt som den ger hög tillgänglighet och svarstider.
- Azure Load Balancer distribuerar inkommande trafik enligt definierade regler och hälsoavsökningar. En lastbalanserare ger låg svarstid och högt dataflöde och skalar upp till miljontals flöden för alla TCP- och UDP-program. En offentlig lastbalanserare används i det här scenariot för att distribuera inkommande klienttrafik till webbnivån. En intern lastbalanserare används i det här scenariot för att distribuera trafik från affärsnivån till serverdelens SQL Server-kluster.
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
- 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 används av Microsoft.
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å
Skalbarhet
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.
Andra avsnitt om skalbarhet finns i checklistan för prestandaeffektivitet i Azure Architecture Center.
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.
Prissättning
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.
Deltagare
Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.
Huvudförfattare:
- Sujay Talasila | Huvudproduktsledare
Nästa steg
Relaterade resurser
Mer referensarkitekturer för hög tillgänglighet och haveriberedskap finns i: