Användningsfallsdefinition
För att stödja det här arbetsexemplet används det fiktiva företaget "Contoso" med en Azure Data Platform baserat på Microsofts referensarkitekturer.
Datatjänst – komponentvy
Contoso har implementerat följande grundläggande Azure-struktur, som är en delmängd av Enterprise Landing Zone.
Siffrorna i följande beskrivningar motsvarar föregående diagram ovan.
Contosos Azure Foundations – arbetsflöde
- Företagsregistrering – Contosos främsta överordnad företagsregistrering i Azure återspeglar det kommersiella avtalet med Microsoft, organisationens kontostruktur och tillgängliga Azure-prenumerationer. Det ger faktureringsgrunden för prenumerationer och hur den digitala egendomen administreras
- Identitets- och åtkomsthantering – de komponenter som krävs för att tillhandahålla identitets-, autentiserings-, resursåtkomst- och auktoriseringstjänster i Contosos Azure-fotavtryck
- Hanteringsgrupp och prenumerationsorganisation – En skalbar grupphierarki som är anpassad efter dataplattformens kärnfunktioner, vilket möjliggör driftsättning i stor skala med hjälp av centralt hanterad säkerhet och styrning där arbetsbelastningar har tydlig separation. Hanteringsgrupper tillhandahåller ett styrningsomfång över prenumerationer
- Hanteringsprenumeration – en dedikerad prenumeration för de olika hanteringsnivåfunktioner som krävs för att stödja dataplattformen
- Anslut ivity Subscription – En dedikerad prenumeration för dataplattformens anslutningsfunktioner så att den kan identifiera namngivna tjänster, fastställa säker routning och kommunikation mellan och mellan interna och externa tjänster
- Landningszonprenumeration – en-till-många-prenumerationer för azure-inbyggda, onlineprogram, interna och externa arbetsbelastningar och resurser
- DevOps Platform – DevOps-plattformen som stöder Azure Foundation & Data Platform. Den här plattformen innehåller lagringsplatsen för kodbasen för källkodskontroll och CI/CD-pipelines som möjliggör automatiserade distributioner av IaC
Kommentar
Många kunder har fortfarande ett stort IaaS-fotavtryck. För att tillhandahålla återställningsfunktioner i IaaS är den nyckelkomponent som ska läggas till Azure Site Recovery. Site Recovery samordnar och automatiserar replikeringen av virtuella Azure-datorer mellan regioner, lokala virtuella datorer och fysiska servrar till Azure och lokala datorer till ett sekundärt datacenter.
I den här grundläggande strukturen har Contoso implementerat följande element för att stödja företagets business intelligence-behov, anpassade till vägledningen i Analytics från slutpunkt till slutpunkt med Azure Synapse.
Contosos dataplattform – arbetsflöde
Arbetsflödet läss från vänster till höger efter dataflödet:
- Datakällor – Källor eller typer av data som dataplattformen kan använda från
- Inmatning – Plattformens förmåga att mata in data från olika källor med varierande struktur och hastighet. Den här designen återspeglar en Lambda-arkitektur
- Store – Möjligheten att på ett säkert sätt lagra data i stor skala som har matats in på plattformen
- Process – Plattformens förmåga att bearbeta data, vilket gör den "lämplig för ändamålet" för nedströmsprocesser som rensning, standardisering och modellering. Förbearbetningen av data säkerställer vanligtvis att de är i en "position och ett villkor, redo för användning"
- Enrich – Möjligheten att förbättra data som bearbetas på plattformen via statistik, Machine Learning eller andra modelleringstekniker eller fördefinierade Azure AI-tjänster
- Serve – Plattformens förmåga att forma och presentera data för nedströmsförbrukning
- Datakonsumenter – Enskilda användare, program eller nedströmsprocesser som använder data från plattformarnas olika betjänande beröringspunkter
- Upptäck och styr – Plattformens funktioner för att styra de data som den innehåller och se till att den är indexerad, identifierbar/sökbar, väl beskriven, med fullständig härkomst och är transparent för slutanvändarna och användningsprocesser.
- Plattform – Grunden som plattformen bygger på, det vill: Contosos Azure Foundations enligt beskrivningen ovan.
Kommentar
För många kunder justeras den konceptuella nivån för dataplattformsreferensarkitekturen som används, men den fysiska implementeringen kan variera. Till exempel kan ELT-processer (extrahera, läsa in, transformera) utföras via Azure Data Factory och datamodellering av Azure SQL Server. För att åtgärda detta problem ger avsnittet Stateless vs Stateful nedan vägledning.
För dataplattformen har Contoso valt de lägsta rekommenderade produktionstjänstnivåerna för alla komponenter och har valt att införa en dr-strategi för omdistribuering av haveri baserat på en metod för kostnadsminimering.
Följande avsnitt ger en baslinjeförstålning av DR-processen och hävstänger som är tillgängliga för kunder för att lyfta upp den här hållningen.
Azure-tjänst- och komponentvy
Följande tabeller visar en uppdelning av varje Azure-tjänst och -komponent som används i Contoso – Data-plattformen, med alternativ för DR-upplyftning.
Kommentar
Avsnitten nedan är ordnade efter tillståndskänsliga och tillståndslösa tjänster
Tillståndskänsliga grundläggande komponenter
Microsoft Entra-ID inklusive rollrättigheter
- Ansvar för komponentåterställning: Microsoft
- Ansvar för återställning av arbetsbelastning/konfiguration: Microsoft
- Contoso SKU-val: Premium P1
- DR Uplift-alternativ: Microsoft Entra ID:s återhämtning är en del av saaS-erbjudandet
- Anteckningar
Azure Key Vault
- Ansvar för komponentåterställning: Microsoft
- Ansvar för återställning av arbetsbelastning/konfiguration: Microsoft
- Contoso SKU-val: N/A
- DR Uplift-alternativ: N/A, omfattas som en del av Azure Service
Recovery Services-valv
- Ansvar för komponentåterställning: Microsoft
- Ansvar för återställning av arbetsbelastning/konfiguration: Microsoft
- Contoso SKU-val: Standard (GRS)
- DR Uplift-alternativ: Om du aktiverar återställning mellan regioner skapas dataåterställning i den sekundära, kopplade regionen
- Anteckningar
- Även om LRS och ZRS är tillgängliga krävs konfigurationsaktiviteter från standardinställningen
Azure DevOps
- Ansvar för komponentåterställning: Microsoft
- Ansvar för återställning av arbetsbelastning/konfiguration: Microsoft
- Contoso SKU-val: DevOps Services
- DR Uplift-alternativ: DevOps-tjänsten och dataåterhämtning är en del av saaS-erbjudandet
- Anteckningar
- DevOps Server som det lokala erbjudandet förblir kundens ansvar för haveriberedskap
- Om tjänster från tredje part (till exempel SonarCloud, Jfrog Artifactory, Jenkins build-servrar) används förblir kunden ansvarig för återställning efter en katastrof
- Om virtuella IaaS-datorer används i DevOps-verktygskedjan förblir de kundens ansvar för återställning efter en katastrof
Tillståndslösa grundläggande komponenter
Prenumerationer
- Ansvar för komponentåterställning: Microsoft
- Ansvar för återställning av arbetsbelastning/konfiguration: Microsoft
- Contoso SKU-val: N/A
- DR Uplift-alternativ: N/A, omfattas som en del av Azure Service
Hanteringsgrupper
- Ansvar för komponentåterställning: Microsoft
- Ansvar för återställning av arbetsbelastning/konfiguration: Microsoft
- Contoso SKU-val: N/A
- DR Uplift-alternativ: N/A, omfattas som en del av Azure Service
Azure Monitor
- Ansvar för komponentåterställning: Microsoft
- Ansvar för återställning av arbetsbelastning/konfiguration: Microsoft
- Contoso SKU-val: N/A
- DR Uplift-alternativ: N/A, omfattas som en del av Azure Service
Kostnadshantering
- Ansvar för komponentåterställning: Microsoft
- Ansvar för återställning av arbetsbelastning/konfiguration: Microsoft
- Contoso SKU-val: N/A
- DR Uplift-alternativ: N/A, omfattas som en del av Azure Service
Microsoft Defender för molnet
- Ansvar för komponentåterställning: Microsoft
- Ansvar för återställning av arbetsbelastning/konfiguration: Microsoft
- Contoso SKU-val: N/A
- DR Uplift-alternativ: N/A, omfattas som en del av Azure Service
Azure DNS
- Ansvar för komponentåterställning: Microsoft
- Ansvar för återställning av arbetsbelastning/konfiguration: Microsoft
- Contoso SKU-val: Enskild zon – offentlig
- DR Uplift-alternativ: N/A, DNS är mycket tillgängligt avsiktligt
Network Watcher
- Ansvar för komponentåterställning: Microsoft
- Ansvar för återställning av arbetsbelastning/konfiguration: Microsoft
- Contoso SKU-val: N/A
- DR Uplift-alternativ: N/A, omfattas som en del av Azure Service
Virtuella nätverk, inklusive undernät, UDR och NSG:er
- Ansvar för komponentåterställning: Contoso
- Ansvar för arbetsbelastning/konfigurationsåterställning: Contoso
- Contoso SKU-val: N/A
- DR Uplift-alternativ: Virtuella nätverk kan replikeras till den sekundära, parkopplade regionen
Azure Firewall
- Ansvar för komponentåterställning: Contoso
- Ansvar för arbetsbelastning/konfigurationsåterställning: Contoso
- Contoso SKU-val: Standard
- DR Uplift-alternativ: Azure Firewall är mycket tillgängligt avsiktligt och kan skapas med Tillgänglighetszoner för ökad tillgänglighet
Azure DDoS
- Ansvar för komponentåterställning: Microsoft
- Ansvar för arbetsbelastning/konfigurationsåterställning: Contoso
- Contoso SKU-val: DDoS Network Protection
- DR Uplift-alternativ: N/A, omfattas som en del av Azure-tjänsten
ExpressRoute-krets
- Ansvar för komponentåterställning: Contoso, anslutningspartner och Microsoft
- Ansvar för arbetsbelastning/konfigurationsåterställning: Anslut ivity-partner och Microsoft
- Contoso SKU-val: Standard
- DR Uplift-alternativ:
- ExpressRoute kan lyftas upp för att använda privat peering och leverera en geo-redundant tjänst
- ExpressRoute har också hög tillgänglighetsdesign tillgänglig
- Plats-till-plats-VPN-anslutning kan användas som en säkerhetskopia för ExpressRoute
- Anteckningar
- ExpressRoute har inbyggd redundans, där varje krets består av två anslutningar till två Microsoft Enterprise-gränsroutrar (MSEE) på en ExpressRoute-plats från anslutningsleverantören/klientens nätverksgräns
- ExpressRoute Premium-krets ger åtkomst till alla Azure-regioner globalt
VPN Gateway
- Ansvar för komponentåterställning: Contoso
- Ansvar för arbetsbelastning/konfigurationsåterställning: Contoso
- Contoso SKU-val: Enskild zon – VpnGw1
- DR Uplift-alternativ: En VPN-gateway kan distribueras till en tillgänglighetszon med VPNGw#AZ SKU:er för att tillhandahålla en zonredundant tjänst
Azure Load Balancer
- Ansvar för komponentåterställning: Contoso
- Ansvar för arbetsbelastning/konfigurationsåterställning: Contoso
- Contoso SKU-val: Standard
- DR Uplift-alternativ:
- En lastbalanserare kan konfigureras för zonredundans inom en region med tillgänglighetszoner. I så fall överlever datasökvägen så länge en zon i regionen förblir felfri
- Beroende på den primära regionen kan en lastbalanserare mellan regioner distribueras för en distribution mellan regioner med hög tillgänglighet
- Anteckningar
- Azure Traffic Manager är en DNS-baserad lastbalanserare för trafik. Den här tjänsten stöder distribution av trafik för offentliga program i de globala Azure-regionerna. Den här lösningen ger skydd mot ett regionalt avbrott i en design med hög tillgänglighet
Tillståndskänsliga dataplattformsspecifika tjänster
Lagringskonto: Azure Data Lake Gen2
- Ansvar för komponentåterställning: Microsoft
- Ansvar för arbetsbelastning/konfigurationsåterställning: Contoso
- Contoso SKU-val: LRS
- DR Uplift-alternativ: Lagringskonton har ett brett utbud av alternativ för dataredundans från redundans för primär region upp till redundans för sekundär region
- Anteckningar
- GRS rekommenderas för att öka redundansen och tillhandahålla en kopia av data i den kopplade regionen
Azure Event Hubs
- Ansvar för komponentåterställning: Microsoft
- Ansvar för arbetsbelastning/konfigurationsåterställning: Contoso
- Contoso SKU-val: Standard
- DR Uplift-alternativ: En händelsehubbnamnrymd kan skapas med tillgänglighetszoner aktiverade. Den här återhämtningsförmågan kan utökas för att täcka ett fullständigt regionstopp med geo-haveriberedskap
- Anteckningar
- Händelsehubbars geo-haveriberedskap replikerar inte data, därför finns det flera saker att tänka på vid redundans och återställning
Azure IoT Hubs
- Ansvar för komponentåterställning: Microsoft
- Ansvar för arbetsbelastning/konfigurationsåterställning: Contoso
- Contoso SKU-val: Standard
- DR Uplift-alternativ:
- IoT Hub Resiliency kan lyftas upp av en tvärregional HA-implementering
- Microsoft tillhandahåller följande vägledning för HA/DR-alternativ
- Anteckningar
- IoT Hub tillhandahåller Microsoft-initierad redundans och manuell redundans genom att replikera data till den kopplade regionen för varje IoT-hubb
- IoT Hub tillhandahåller ha för intraregion och använder automatiskt en tillgänglighetszon om den skapas i en fördefinierad uppsättning Azure-regioner
Azure Stream Analytics
- Ansvar för komponentåterställning: Microsoft
- Ansvar för arbetsbelastning/konfigurationsåterställning: Contoso
- Contoso SKU-val: Standard
- DR Uplift-alternativ: Även om Azure Stream Analytics är ett fullständigt hanterat PaaS-erbjudande ger det inte automatisk geo-redundans. Geo-redundans kan uppnås genom att distribuera identiska Stream Analytics-jobb i flera Azure-regioner
Azure Machine Learning
- Ansvar för komponentåterställning: Contoso och Microsoft
- Ansvar för arbetsbelastning/konfigurationsåterställning: Contoso
- Contoso SKU-val: Generell användning, D-seriens instanser
- DR Uplift-alternativ:
- Azure Machine Learning är beroende av flera Azure-tjänster, varav vissa etableras i kundens prenumeration. Därför är kunden fortfarande ansvarig för konfigurationen av dessa tjänster med hög tillgänglighet
- Återhämtning kan lyftas upp via en multiregional distribution
- Anteckningar:
- Själva Azure Machine Learning tillhandahåller inte automatisk redundans eller haveriberedskap
Power BI
- Ansvar för komponentåterställning: Microsoft
- Ansvar för återställning av arbetsbelastning/konfiguration: Microsoft
- Contoso SKU-val: Power BI Pro
- DR Uplift-alternativ: N/A, Power BI:s återhämtning är en del av saaS-erbjudandet
- Anteckningar
- Power BI finns i Office365-innehavet, inte i Azure
- Power BI använder Azure Tillgänglighetszoner för att skydda Power BI-rapporter, program och data från datacenterfel
- Vid regionala fel redundansväxlar Power BI till en ny region, vanligtvis på samma geografiska plats, som anges i Microsoft Trust Center
Azure Cosmos DB
- Ansvar för komponentåterställning: Microsoft
- Ansvar för återställning av arbetsbelastning/konfiguration: Microsoft
- Contoso SKU-val: Skrivning med enskild region med periodisk säkerhetskopiering
- DR Uplift-alternativ:
- Konton med en region kan förlora tillgängligheten efter ett regionalt avbrott. Återhämtning kan höjas till en enda skrivregion och minst en andra (läs)region och aktivera tjänsthanterad redundans
- Vi rekommenderar att Azure Cosmos-konton används för produktionsarbetsbelastningar för att aktivera automatisk redundans. I avsaknad av den här konfigurationen kommer kontot att uppleva förlust av skrivtillgänglighet under hela skrivningsregionens avbrott, eftersom manuell redundans inte lyckas på grund av bristande regionanslutning
- Anteckningar
- För att skydda mot dataförlust i en region tillhandahåller Azure Cosmos DB två olika säkerhetskopieringslägen – periodiska och kontinuerliga
- Regionala redundans identifieras och hanteras i Azure Cosmos DB-klienten. De kräver inga ändringar från programmet
- Följande vägledning beskriver effekten av ett regionstopp baserat på Cosmos DB-konfigurationen
Azure Data Share
- Ansvar för komponentåterställning: Microsoft
- Ansvar för återställning av arbetsbelastning/konfiguration: Microsoft
- Contoso SKU-val: N/A
- DR Uplift-alternativ: Azure Data Share-återhämtning kan lyftas upp av HA-distribution till en sekundär region
Microsoft Purview
- Ansvar för komponentåterställning: Microsoft
- Ansvar för arbetsbelastning/konfigurationsåterställning: Contoso
- Contoso SKU-val: N/A
- DR Uplift-alternativ: N/A
- Anteckningar
- Från och med december 2023 har Microsoft Purview inte stöd för automatiserad BCDR. Tills supporten har lagts till ansvarar kunden för alla säkerhetskopierings- och återställningsaktiviteter.
Plattformsspecifika tjänster för tillståndslösa data
Azure Synapse: Pipelines
- Ansvar för komponentåterställning: Microsoft
- Ansvar för arbetsbelastning/konfigurationsåterställning: Contoso
- Contoso SKU-val: Beräknad optimerad Gen2
- DR Uplift-alternativ: N/A, Synapse-återhämtning är en del av dess SaaS-erbjudande med hjälp av funktionen för automatisk redundans
- Anteckningar
- Om lokala datapipelines används förblir kunden ansvarig för återställning efter en katastrof
Azure Synapse: Data Explorer-pooler
- Ansvar för komponentåterställning: Microsoft
- Ansvar för arbetsbelastning/konfigurationsåterställning: Contoso
- Contoso SKU-val: Beräknad optimerad, Liten (4 kärnor)
- DR Uplift-alternativ: N/A, Synapse resiliency är en del av sitt SaaS-erbjudande
- Anteckningar
- Tillgänglighetszoner är aktiverade som standard för Synapse Data Explorer där det är tillgängligt.
Azure Synapse: Spark-pooler
- Ansvar för komponentåterställning: Microsoft
- Ansvar för arbetsbelastning/konfigurationsåterställning: Contoso
- Contoso SKU-val: Beräknad optimerad, Liten (4 kärnor)
- DR Uplift-alternativ: N/A, Synapse resiliency är en del av sitt SaaS-erbjudande
- Anteckningar
- För närvarande stöder Azure Synapse Analytics endast haveriberedskap för dedikerade SQL-pooler och stöder det inte för Apache Spark-pooler
Azure Synapse: Serverlösa och dedikerade SQL-pooler
- Ansvar för komponentåterställning: Microsoft
- Ansvar för arbetsbelastning/konfigurationsåterställning: Contoso
- Contoso SKU-val: Beräknad optimerad Gen2
- DR Uplift-alternativ: N/A, Synapse resiliency är en del av sitt SaaS-erbjudande
- Anteckningar
- Azure Synapse Analytics tar automatiskt ögonblicksbilder hela dagen för att skapa återställningspunkter som är tillgängliga i sju dagar
- Azure Synapse Analytics utför en vanlig geo-säkerhetskopiering en gång per dag till ett kopplat datacenter. RPO för en geo-återställning är 24 timmar
- Om lokala datapipelines används förblir kunderna ansvariga för återställning efter en katastrof
Azure AI-tjänster (tidigare Cognitive Services)
- Ansvar för komponentåterställning: Microsoft
- Ansvar för återställning av arbetsbelastning/konfiguration: Microsoft
- Contoso SKU-val: Betala per användning
- DR Uplift-alternativ: N/A, API:er för AI-tjänster hanteras av Microsoft-hanterade datacenter
- Anteckningar
- Om AI-tjänster har distribuerats via kunddistribuerade Docker-containrar förblir återställning kundens ansvar
Azure AI Search (tidigare Cognitive Search)
- Ansvar för komponentåterställning: Microsoft
- Ansvar för återställning av arbetsbelastning/konfiguration: Microsoft
- Contoso SKU-val: Standard S1
- DR Uplift-alternativ:
- AI-sökning kan höjas till en HA-design med hjälp av repliker i tillgänglighetszoner och regioner
- Flera tjänster i separata regioner kan utöka återhämtning ytterligare
- Anteckningar
- I AI Search uppnås affärskontinuitet (och haveriberedskap) genom flera AI-tjänsten Search.
- Det finns ingen inbyggd mekanism för haveriberedskap. Om kontinuerlig tjänst krävs vid ett oåterkalleligt fel är rekommendationen att ha en andra tjänst i en annan region och implementera en strategi för geo-replikering för att säkerställa att index är helt redundanta för alla tjänster
Tillståndskänsliga eller tillståndslösa komponenter
Innovationshastigheten i Microsofts produktsvit och i synnerhet Azure innebär att den komponentuppsättning som vi har använt för det här arbetsexemplet snabbt kommer att utvecklas. För att framtidssäkra mot att tillhandahålla inaktuell vägledning och utöka den här vägledningen till komponenter som inte uttryckligen beskrivs i det här dokumentet, innehåller avsnittet nedan vissa instruktioner baserade på grovkornig klassificering av tillstånd.
En komponent/tjänst kan beskrivas som tillståndskänslig om den är utformad för att komma ihåg föregående händelser eller användarinteraktioner. Tillståndslös innebär att det inte finns någon post för tidigare interaktioner, och varje interaktionsbegäran måste hanteras helt baserat på information som medföljer den.
För ett DR-scenario som kräver omdistribution:
- Komponenter/tjänster som är "tillståndslösa", till exempel Azure Functions- och Azure Data Factory-pipelines, kan distribueras om från källkontrollen med minst ett röktest för att verifiera tillgängligheten innan de introduceras i det bredare systemet
- Komponenter/tjänster som är "tillståndskänsliga", till exempel Azure SQL-databas- och lagringskonton, kräver mer uppmärksamhet
- När komponenten införskaffas kommer ett viktigt beslut att vara att välja funktionen för dataredundans. Det här beslutet fokuserar vanligtvis på en kompromiss mellan tillgänglighet och hållbarhet med driftskostnader
- Datalager behöver också en strategi för datasäkerhetskopiering. Funktionen för dataredundans i den underliggande lagringen minskar den här risken för vissa design, medan andra, till exempel SQL-databaser, behöver en separat säkerhetskopieringsprocess.
- Om det behövs kan komponenten omdistribueras från källkontrollen med en verifierad konfiguration via ett röktest
- Ett omdistribuerat datalager måste ha sin datauppsättning uttorkad. Rehydrering kan utföras genom dataredundans (när det är tillgängligt) eller en säkerhetskopieringsdatauppsättning. När rehydreringen har slutförts måste den verifieras för noggrannhet och fullständighet
- Beroende på typen av säkerhetskopieringsprocess kan säkerhetskopieringsdatauppsättningarna kräva validering innan de tillämpas. Skador/fel i säkerhetskopieringsprocessen kan leda till att en tidigare säkerhetskopia används i stället för den senaste tillgängliga versionen
- Alla delta mellan komponentens datum/tidsstämpel och det aktuella datumet bör åtgärdas genom att köra om eller spela upp datainmatningsprocesserna från och med den tidpunkten framåt
- När komponentens datauppsättning är uppdaterad kan den introduceras i det bredare systemet
Andra viktiga tjänster
Det här avsnittet innehåller HA/DR-vägledning för andra viktiga Azure Data-komponenter och -tjänster.
- Azure Databricks – DR-vägledning finns i produktdokumentationen
- Azure Analysis Services – HA-vägledning finns i produktdokumentationen
- Azure Database for MySQL
- SQL
Nästa steg
Nu när du har lärt dig om scenariots arkitektur kan du lära dig mer om scenarioinformationen