Microsoft Azure Tillgänglighetszoner är separata fysiska platser i en Azure-region, var och en med ett eller flera datacenter som har oberoende ström, kylning och nätverk. Den fysiska avgränsningen av tillgänglighetszoner inom en region begränsar effekten av zonfel på program och data. Referensarkitekturen som presenteras i den här artikeln demonstrerar metodtips för en zonindelade distribution – en distribution som använder Tillgänglighetszoner för att öka programmets tillgänglighet. En zonindead distribution är lämplig för många typer av program. Det specifika exemplet som visas här är zonindead distribution av ett webbprogram som körs på virtuella datorer (VM) och använder Microsoft SQL Server databas.
Den här metoden används i scenarier med hög tillgänglighet där återhämtning är mycket viktigt. Med HA-arkitekturen finns det en balans mellan hög återhämtning, låg latens och kostnad. Den här arkitekturen använder redundanta resurser som är utspridda mellan zoner för att ge hög återhämtning. Trafik kan dirigeras mellan zoner för att minimera effekten av ett zonfel. Om en zon misslyckas absorberar resurser i andra zoner trafiken tills den felande zonen återställs. Detta ger en hög återhämtningsnivå.
Den här arkitekturen ger en effektiv användning av resurser, eftersom de flesta av resurserna används aktivt. Alla resurser, förutom de passiva SQL Server, används för att hantera begäranden. Passiva SQL Server aktiveras bara om den aktiva SQL Server misslyckas.
Den zonredundant Azure Application Gateway och zonredundant lastbalanserare distribuerar trafiken till de tillgängliga resurserna.
Ladda ned en Visio-fil med den här arkitekturen.
Arkitektur
Arkitekturen använder resurser som är utspridda över flera zoner för att tillhandahålla hög tillgänglighet till en IaaS-webbapp (Infrastruktur som en tjänst) som använder en SQL Server databas. En zonredundant Application Gateway dirigerar trafik till virtuella datorer på webbnivån. En zonredundant lastbalanserare dirigerar trafik från de virtuella datorerna på webbnivån till den aktiva SQL Server. Om det uppstår ett zonfel dirigerar Application Gateway virtuella datorer i andra tillgängliga zoner. Routning mellan zoner har längre svarstid än routning i zonen.
Om den aktiva SQL Server blir otillgänglig, antingen på grund av ett zonfel eller ett lokalt fel, blir en passiv SQL Server den aktiva SQL Server. Den zonredundanta lastbalanseraren identifierar redundansen till den nyligen SQL Server och dirigerar trafik till den.
Följande illustrerar ett fel på Zon 1.
Ladda ned en Visio-fil med den här arkitekturen.
Den Application Gateway är zonredundant. Den påverkas inte av felet i Zon 1 och använder hälsoavsökningar för att fastställa de tillgängliga virtuella datorerna. När Zon 1 inte är tillgänglig dirigerar den endast trafik till de återstående två zonerna. Den zonredundanta lastbalanseraren påverkas inte heller av felet i Zon 1 och använder hälsoavsökningar för att fastställa platsen för den aktiva SQL Server. I det här exemplet identifierar lastbalanseraren att den aktiva SQL Server finns i Zon 3 dirigerar trafik till den.
Att sprida resurser Tillgänglighetszoner skyddar även ett program mot planerat underhåll. När virtuella datorer distribueras över tre Tillgänglighetszoner de i praktiken sprids över tre uppdateringsdomäner. Azure-plattformen identifierar den här distributionen mellan uppdateringsdomäner för att säkerställa att virtuella datorer i olika zoner inte uppdateras samtidigt.
Genom att replikera virtuella datorer Tillgänglighetszoner kan du skydda dina program och data mot zonfel. Så här uppfyller Azure det bransch bästa serviceavtalet med 99,99 % drifttid för virtuella datorer (SLA). Se Skapa lösningar för hög tillgänglighet med hjälp av Tillgänglighetszoner.
Arkitekturen har följande komponenter:
Allmänt
Resursgrupper. Resursgrupper används för att gruppera Azure-resurser så att de kan hanteras efter livslängd, ägare eller andra kriterier.
Azure-tillgänglighetszoner. Tillgänglighetszoner är separata fysiska platser i en Azure-region, var och en med ett eller flera datacenter som har oberoende ström, kylning och nätverk. Genom att placera virtuella datorer mellan zoner blir programmet motståndskraftigt mot fel i en zon.
Nätverk och belastningsutjämning
- Virtuellt nätverk och undernät. Varje virtuell Azure-dator distribueras till ett virtuellt nätverk som kan delas upp i undernät, ett undernät för varje nivå.
- Application Gateway. Azure Application Gateway är en Layer 7-lastbalanserare. I den här arkitekturen dirigerar en zonredundant Application Gateway HTTP-begäranden till webbwebbdelen. Application Gateway också en Web Application Firewall (WAF) som skyddar programmet mot vanliga kryphål och sårbarheter. V2-SKU:n för Application Gateway stöder redundans mellan zoner. En enda Application Gateway kan köra flera gatewayinstanser. För produktionsarbetsbelastningar kör du minst två. Mer information finns i Autoskalning och Zonredundant Application Gateway v2 och Hur stöder Application Gateway hög tillgänglighet och skalbarhet?.
- Azure Load Balancer. Azure Load Balancer är en Layer 4-lastbalanserare. I den här arkitekturen dirigerar en zonredundant Azure Standard Load Balancer nätverkstrafik från webbnivån till SQL Server. Eftersom en zonredundant lastbalanserare inte är fäst i en specifik zon fortsätter programmet att distribuera nätverkstrafiken i händelse av zonfel. En zonredundant lastbalanserare används för att tillhandahålla tillgänglighet om de aktiva SQL Server blir otillgängliga. Standard-SKU för Azure Load Balancer stöder redundans mellan zoner. Mer information finns i Standard Load Balancer och Tillgänglighetszoner.
- Nätverkssäkerhetsgrupper (NSG:er). En nätverkssäkerhetsgrupp används för att begränsa nätverkstrafiken i det virtuella nätverket. I den här arkitekturen accepterar webbnivån endast trafik från den offentliga IP-slutpunkten. Dessutom accepterar inte databasnivån trafik från något annat undernät än undernätet på webbnivå.
- DDoS-skydd. Azure-plattformen ger skydd mot distribuerade doS-attacker (Denial of Service). För ytterligare skydd rekommenderar vi att du använder Azure DDoS Protection Standard, som har förbättrade DDoS-skyddsfunktioner. Se Säkerhetsöverväganden.
- Azure Bastion. Azure Bastion ger säker och sömlös Remote Desktop Protocol (RDP) och Secure Shell (SSH) åtkomst till de virtuella datorerna i det virtuella nätverket. Detta ger åtkomst samtidigt som de exponerade offentliga IP-adresserna för de virtuella datorerna i det virtuella nätverket begränsas. Azure Bastion ett kostnadseffektivt alternativ till en etablerad virtuell dator för att ge åtkomst till alla virtuella datorer i samma virtuella nätverk.
Microsoft SQL Server
SQL Server Always On-tillgänglighetsgrupper. En SQL Server Always On-tillgänglighetsgrupp ger hög tillgänglighet på datanivån genom att aktivera replikering och redundans. Den använder Windows Server Failover Cluster (WSFC)-teknik för redundans.
Molnvittne. Ett redundanskluster kräver att mer än hälften av noderna körs, ett villkor som kallas kvorum. Om klustret bara har två noder kan en nätverkspartition göra så att varje nod tror att det är den primära noden. I så fall behöver du ett vittne för att bryta oavgjort och upprätta kvorum. Ett vittne är en resurs, till exempel en delad disk som kan fungera som en oavgjord brytare för att upprätta kvorum. Molnvittne är en typ av vittne som använder Azure Blob Storage. Azure Blob-Storage måste använda zonredundant Storage (ZRS) för att inte påverkas av ett zonfel.
Mer information om kvorumbegreppet finns i Förstå kluster- och poolkvorum. Mer information om molnvittne finns i Distribuera ett molnvittne för ett redundanskluster.
Rekommendationer
Dina krav kan vara annorlunda från den arkitektur som beskrivs här. Använd de här rekommendationerna som utgångspunkt.
Rekommendationer om hur du konfigurerar de virtuella datorerna finns i Köra en Windows virtuell dator på Azure.
Mer information om hur du utformar virtuella nätverk och undernät finns i Planera och utforma virtuella Azure-nätverk.
Nätverkssäkerhetsgrupper
Använd NSG-regler för att begränsa trafiken mellan nivåer. I den här arkitekturen kan endast webbnivån kommunicera direkt med databasnivån. För att framtvinga den här regeln ska databasnivån blockera all inkommande trafik utom undernätet på webbnivå.
- Neka all inkommande trafik från det virtuella nätverket. (Använd VIRTUAL_NETWORK taggen i regeln.)
- Tillåt inkommande trafik från undernätet på webbnivå.
- Tillåt inkommande trafik från själva undernätet på databasnivå. Den här regeln tillåter kommunikation mellan de virtuella databas datorerna, vilket krävs för databasreplikering och redundans.
Skapa regler 2–3 med högre prioritet än den första regeln så att de åsidosätter den.
SQL Server AlwaysOn-tillgänglighetsgrupper
Vi rekommenderar Always On-tillgänglighetsgrupper för Microsoft SQL Server hög tillgänglighet. Andra nivåer ansluts till databasen via en lyssningsfunktion för tillgänglighetsgrupp. Genom lyssningsfunktionen kan en SQL-klient ansluta utan att känna till namnet på den fysiska instansen av SQL-servern. Virtuella datorer med åtkomst till databasen måste vara anslutna till domänen. Klienten (i det här fallet en annan nivå) använder DNS för att omvandla namnet på lyssningsfunktionens virtuella nätverk till IP-adresser.
Konfigurera SQL Server Always On-tillgänglighetsgruppen på följande sätt:
- Skapa ett Windows WSFC-kluster (Server Failover Clustering), en SQL Server Always On-tillgänglighetsgrupp och en primär replik. Mer information finns i Komma igång Always On-tillgänglighetsgrupper.
- Skapa en intern lastbalanserare med en statisk, privat IP-adress.
- Skapa en tillgänglighetsgruppslyssnare och mappa lyssnarens DNS-namn till IP-adressen för en intern lastbalanserare.
- Skapa en lastbalanseringsregel för SQL Server-lyssningsporten (TCP-port 1433 som standard). Lastbalanseringsregeln måste aktivera flytande IP, även kallat direkt serverreturnering. Det här gör att den virtuella datorn svarar direkt på klienten, vilket möjliggör en direkt anslutning till den primära repliken.
Anteckning
När flytande IP är aktiverat måste portnumret för klientdelen vara samma som backend-portnumret i lastbalanseringsregeln.
När en SQL-klient försöker ansluta dirigerar lastbalanseraren anslutningsbegäran till den primära repliken. Om det finns en redundans till en annan replik dirigerar lastbalanseraren automatiskt nya begäranden till en ny primär replik. Mer information finns i Konfigurera en lastbalanserare för en tillgänglighetsgrupp på virtuella Azure SQL Server-datorer.
En redundans stänger befintliga klientanslutningar. När redundansen är klar dirigeras nya anslutningar till den nya primära repliken.
Om programmet läser betydligt mer än det skriver omdirigerar du några av de skrivskyddade frågorna till en sekundär replik. Se Anslut till en skrivskyddade replik.
Testa distributionen genom att framtvinga en manuell redundansväxling av tillgänglighetsgruppen.
Överväganden för tillgänglighet
Tillgänglighetszoner ger hög motståndskraft inom en enda region. Om du behöver ännu högre tillgänglighet bör du överväga att replikera programmet mellan två regioner med hjälp Azure Traffic Manager för redundans. Mer information finns i Köra ett N-nivåprogram i flera Azure-regioner för hög tillgänglighet.
Alla regioner stöder inte Tillgänglighetszoner, och alla VM-storlekar stöds inte i alla zoner. Kör följande Azure CLI-kommando för att hitta de zoner som stöds för varje VM-storlek inom en region:
az vm list-skus --resource-type virtualMachines --zone false --location eastus -o table
Virtual Machine Scale Sets automatiskt placeringsgrupper, som fungerar som en implicit tillgänglighetsuppsättning. Mer information om placeringsgrupper finns i Arbeta med stora skalningsuppsättningar för virtuella datorer.
Hälsotillståndsavsökningar
Application Gateway och Azure Load Balancer använder både hälsoavsökningar för att övervaka tillgängligheten för VM-instanser.
- Application Gateway använder alltid en HTTP-avsökning.
- Load Balancer kan avse med HTTP eller TCP. Om en virtuell dator kör en HTTP-server använder du i allmänhet en HTTP-avsökning. Annars använder du TCP.
Om en avsökning inte kan nå en instans inom en tidsgräns, slutar gatewayen eller lastbalanseraren att skicka trafik till den virtuella datorn. Avsökningen fortsätter att kontrollera och returnerar den virtuella datorn till backend-poolen när den virtuella datorn blir tillgänglig igen.
HTTP-avsökningar skickar en HTTP GET-begäran till en angiven sökväg och lyssnar efter ett HTTP 200-svar. Den här sökvägen kan vara rotsökvägen ("/") eller en slutpunkt för hälsoövervakning som implementerar anpassad logik för att kontrollera hälsotillståndet för programmet. Slutpunkten måste tillåta anonyma HTTP-begäranden.
Mer information om hälsoavsökningar finns i:
Överväganden om hur du utformar en slutpunkt för hälsoavsökning finns i Health Endpoint Monitoring pattern (Övervakningsmönster för slutpunktshälsa).
Kostnadsöverväganden
Använd Priskalkylatorn för Azure för att beräkna kostnader. Här är några andra överväganden.
Virtual Machine Scale Sets
Virtual Machine Scale Sets är tillgängliga på alla Windows VM-storlekar. Du debiteras endast för de virtuella Azure-datorer som du distribuerar och för eventuella ytterligare underliggande infrastrukturresurser som förbrukas, till exempel lagring och nätverk. Det finns inga inkrementella avgifter för Virtual Machine Scale Sets tjänsten.
Prisalternativ för enskilda virtuella datorer finns i Windows för virtuella datorer.
SQL Server
Om du väljer Azure SQL DBaaS kan du minska kostnaderna eftersom du inte behöver konfigurera en Always On-tillgänglighetsgrupp och domänkontrollantdatorer. Det finns flera distributionsalternativ från enkel databas upp till hanterad instans eller elastiska pooler. Mer information finns i Priser för Azure SQL .
Mer SQL för virtuella server-datorer finns i SQL för virtuella datorer.
Azure Load Balancer
Du debiteras bara för antalet konfigurerade regler för belastningsutjämning och utgående trafik. Ingående NAT-regler är kostnadsfria. Det debiteras ingen timkostnad för Standard Load Balancer inga regler har konfigurerats.
Mer information finns i kostnadsavsnittet i Azure Architecture Framework.
Application Gateway
Den Application Gateway ska etableras med v2-SKU:n och kan sträcka sig över flera Tillgänglighetszoner. Med v2-SKU:n drivs prismodellen av förbrukning och har två komponenter: Fast pris per timme och en förbrukningsbaserad kostnad.
Mer information finns i avsnittet om priser i Autoskalning och Zonredundant lagring Application Gateway v2.
Säkerhetsöverväganden
Virtuella nätverk utgör en gräns för isolering av trafik i Azure. Som standard kan virtuella datorer i ett virtuellt nätverk inte kommunicera direkt med virtuella datorer i ett annat virtuellt nätverk. Du kan dock uttryckligen ansluta virtuella nätverk med hjälp av peering för virtuella nätverk.
Trafikbegränsning
Använd nätverkssäkerhetsgrupper (NSG:er) för att begränsa trafiken till och från Internet. Mer information finns i Microsofts molntjänster och nätverkssäkerhet.
DMZ
Överväg att lägga till en virtuell nätverksinstallation (NVA) för att skapa en DMZ mellan Internet och det virtuella Azure-nätverket. NVA är ett allmänt begrepp för en virtuell installation som kan utföra nätverksrelaterade uppgifter, till exempel för brandväggen, paketinspektion, granskning och anpassad routning. Mer information finns i Network DMZ between Azure and an on-premises datacenter (Nätverks-DMZ mellan Azure och ett lokalt datacenter).
Kryptering
Kryptera känsliga, vilande data och hantera krypteringsnycklar för databasen med Azure Key Vault. Key Vault kan lagra krypteringsnycklar i maskinvarusäkerhetsmoduler (HSM:er). Mer information finns i Konfigurera Azure Key Vault-integrering för SQL Server på Azure Virtual Machines. Vi rekommenderar också att du lagrar programhemligheter, till exempel databasanslutningssträngar, i Key Vault.
DDoS-skydd
Azure-plattformen tillhandahåller grundläggande DDoS-skydd som standard. Det här grundläggande skyddet är riktat mot att skydda Azure-infrastrukturen. Även om grundläggande DDoS-skydd aktiveras automatiskt, rekommenderar vi att du Azure DDoS Protection Standard. Standardskydd använder anpassningsbar justering, baserat på programmets nätverkstrafikmönster, för att identifiera hot. På så sätt kan den tillämpa åtgärder mot DDoS-attacker som kan gå obemärkt förbi av de infrastrukturomfattande DDoS-principerna. Standardskydd tillhandahåller även aviseringar, telemetri och analys via Azure Monitor. Mer information finns i Azure DDoS Protection: Metodtips och referensarkitekturer.