Redigera

Share via


DR för Azure Data Platform – Arkitektur

Azure Synapse Analytics
Azure Machine Learning
Azure Cosmos DB
Azure Data Lake
Azure Event Hubs

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. Diagram that shows an example Enterprise Azure landing zone.

Siffrorna i följande beskrivningar motsvarar föregående diagram ovan.

Contosos Azure Foundations – arbetsflöde

  1. 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
  2. Identitets- och åtkomsthantering – de komponenter som krävs för att tillhandahålla identitets-, autentiserings-, resursåtkomst- och auktoriseringstjänster i Contosos Azure-fotavtryck
  3. 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
  4. Hanteringsprenumeration – en dedikerad prenumeration för de olika hanteringsnivåfunktioner som krävs för att stödja dataplattformen
  5. 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
  6. Landningszonprenumeration – en-till-många-prenumerationer för azure-inbyggda, onlineprogram, interna och externa arbetsbelastningar och resurser
  7. 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.

Diagram that shows architecture for a modern data platform using Azure data services.Contosos dataplattform

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:
    • 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:
    • 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:
    • 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:
    • Anteckningar:
  • 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
  • Azure Cosmos DB

  • 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

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
  • 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 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:
    • 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
    • Vägledning för flexibel server-HA finns i produktdokumentationen
    • Vägledning för ha för enskild server finns i produktdokumentationen
  • SQL
    • Vägledning om virtuella SQL-datorer i Azure finns i produktdokumentationen
    • Vägledning för Azure SQL och Azure SQL Managed Instance finns i produktdokumentationen

Nästa steg

Nu när du har lärt dig om scenariots arkitektur kan du lära dig mer om scenarioinformationen