Noodgevallen kunnen hardwarefouten, natuurrampen of softwarefouten zijn. Het proces voor het voorbereiden en herstellen van een noodgeval wordt herstel na noodgevallen genoemd. In dit artikel worden aanbevolen procedures besproken voor het bereiken van bedrijfscontinuïteit en herstel na noodgevallen (BCDR) voor Azure Data Factory- en Azure Synapse Analytics-pijplijnen.
BCDR-strategieën omvatten redundantie van beschikbaarheidszones, geautomatiseerd herstel dat wordt geboden door Herstel na noodgevallen van Azure en door de gebruiker beheerde herstel met behulp van continue integratie en continue levering (CI/CD).
Architectuur
Een Visio-bestand van deze architectuur downloaden.
Workflow
Data Factory- en Azure Synapse-pijplijnen bereiken tolerantie met behulp van Azure-regio's en Azure-beschikbaarheidszones.
- Elke Azure-regio heeft een set datacenters die worden geïmplementeerd binnen een door latentie gedefinieerde perimeter.
- Azure-beschikbaarheidszones zijn fysiek gescheiden locaties binnen elke Azure-regio die tolerant zijn voor lokale fouten.
- Alle Azure-regio's en beschikbaarheidszones zijn verbonden via een toegewezen, regionaal netwerk met lage latentie en door een netwerk met hoge prestaties.
- Alle regio's met beschikbaarheidszones hebben ten minste drie afzonderlijke beschikbaarheidszones om tolerantie te garanderen.
Wanneer een datacenter, een deel van een datacenter of een beschikbaarheidszone in een regio uitvalt, treedt failover op met nul downtime voor zone-tolerante Data Factory- en Azure Synapse-pijplijnen.
Onderdelen
- Azure Data Factory
- Azure Synapse Analytics - en Azure Synapse-pijplijnen
- GitHub
- Azure-opslagplaatsen
Scenariodetails
Met Data Factory- en Azure Synapse-pijplijnen worden artefacten opgeslagen die de volgende gegevens bevatten:
Metagegevens
- Pijplijn
- Gegevenssets
- Gekoppelde services
- Integration Runtime
- Triggers
Bewakingsgegevens
- Pijplijn
- Triggers
- Uitvoering van activiteiten
Rampen kunnen op verschillende manieren optreden, zoals hardwarefouten, natuurrampen of softwarefouten die het gevolg zijn van menselijke fouten of cyberaanvallen. Afhankelijk van de soorten storingen kan hun geografische impact regionaal of globaal zijn. Houd bij het plannen van een strategie voor herstel na noodgevallen rekening met zowel de aard van het noodgeval als de geografische impact ervan.
BCDR in Azure werkt op een model voor gedeelde verantwoordelijkheid. Voor veel Azure-services moeten klanten hun STRATEGIE voor herstel na noodgeval expliciet instellen, terwijl Azure de basisinfrastructuur en platformservices biedt, indien nodig.
U kunt de volgende aanbevolen procedures gebruiken om BCDR te bereiken voor Data Factory- en Azure Synapse-pijplijnen onder verschillende foutscenario's. Zie Dit scenario implementeren voor implementatie.
Geautomatiseerd herstel met Herstel na noodgevallen van Azure
Met geautomatiseerd herstel via Azure Backup en herstel na noodgevallen, wanneer er een volledige regionale storing is voor een Azure-regio met een gekoppelde regio, data factory- of Azure Synapse-pijplijnen, wordt automatisch een failover uitgevoerd naar de gekoppelde regio wanneer u geautomatiseerd herstel instelt. De uitzonderingen zijn regio's Azië - zuidoost en Brazilië, waarbij gegevenslocatievereisten vereisen dat gegevens in die regio's blijven.
Bij dr-failover herstelt Data Factory de productiepijplijnen. Als u uw herstelde pijplijnen wilt valideren, kunt u een back-up maken van de Azure Resource Manager-sjablonen voor uw productiepijplijnen in geheime opslag en de herstelde pijplijnen vergelijken met de back-ups.
Het Azure Global-team voert regelmatig BCDR-oefeningen uit en Azure Data Factory en Azure Synapse Analytics nemen deel aan deze oefeningen. De BCDR-analyse simuleert een regiofout en voert een failover uit van Azure-services naar een gekoppelde regio zonder tussenkomst van de klant. Zie Testen van services voor meer informatie over de BCDR-drills.
Door de gebruiker beheerde redundantie met CI/CD
Als u BCDR wilt bereiken in het geval van een hele regiofout, hebt u een data factory of een Azure Synapse-werkruimte in de secundaire regio nodig. In het geval van onbedoelde data factory- of Azure Synapse-pijplijnverwijdering, storingen of interne onderhoudsgebeurtenissen, kunt u Git en CI/CD gebruiken om de pijplijnen handmatig te herstellen.
U kunt eventueel een actieve/passieve implementatie gebruiken. De primaire regio verwerkt normale bewerkingen en blijft actief, terwijl voor de secundaire dr-regio vooraf geplande stappen vereist zijn, afhankelijk van specifieke implementatie, die moeten worden gepromoveerd naar primair. In dit geval zijn alle benodigde configuraties voor infrastructuur beschikbaar in de secundaire regio, maar worden ze niet ingericht.
Potentiële gebruikscases
Door de gebruiker beheerde redundantie is handig in scenario's zoals:
- Onbedoeld verwijderen van pijplijnartefacten via menselijke fout.
- Uitgebreide storingen of onderhoudsactiviteiten die BCDR niet activeren omdat er geen noodgeval is gerapporteerd.
U kunt uw productieworkloads snel verplaatsen naar andere regio's en niet worden beïnvloed.
Overwegingen
Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.
Betrouwbaarheid
Betrouwbaarheid zorgt ervoor dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie Overzicht van de betrouwbaarheidspijler voor meer informatie.
Data Factory- en Azure Synapse-pijplijnen zijn algemene Azure-services die beschikbaarheidszones ondersteunen en ze zijn ontworpen om het juiste niveau van tolerantie en flexibiliteit te bieden, samen met ultraarme latentie.
Met de door de gebruiker beheerde herstelbenadering kunt u blijven werken als er onderhoudsgebeurtenissen, storingen of menselijke fouten in de primaire regio zijn. Door CI/CD te gebruiken, kunnen de data factory- en Azure Synapse-pijplijnen worden geïntegreerd in een Git-opslagplaats en implementeren in een secundaire regio voor direct herstel.
Kostenoptimalisatie
Kostenoptimalisatie gaat over manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie Overzicht van de pijler kostenoptimalisatie voor meer informatie.
Door de gebruiker beheerd herstel integreert Data Factory met Git met behulp van CI/CD en maakt optioneel gebruik van een secundaire DR-regio met alle benodigde infrastructuurconfiguraties als back-up. In dit scenario kunnen extra kosten in rekening worden gebracht. Als u kosten wilt schatten, gebruikt u de Azure-prijscalculator.
Zie voor voorbeelden van prijzen voor Data Factory en Azure Synapse Analytics:
Operationele uitmuntendheid
Operationele uitmuntendheid omvat de operationele processen die een toepassing implementeren en deze in productie houden. Zie Overzicht van de operationele uitmuntendheidpijler voor meer informatie.
Met behulp van de door de gebruiker beheerde CI/CD-herstelbenadering kunt u integreren met Azure-opslagplaatsen of GitHub. Zie Best practices voor CI/CD voor meer informatie over aanbevolen CI/CD-procedures.
Dit scenario implementeren
Voer de volgende acties uit om geautomatiseerde of door de gebruiker beheerde herstel na noodgevallen in te stellen voor Data Factory- en Azure Synapse-pijplijnen.
Automatisch herstel instellen
In Data Factory kunt u de Azure Integration Runtime-regio (IR) instellen voor de uitvoering van uw activiteit of verzending in de installatie van Integration Runtime. Als u automatische failover wilt inschakelen in het geval van een volledige regionale storing, stelt u de regio in op Automatisch oplossen.
In de context van de integratieruntimes voert IR automatisch een failover uit naar de gekoppelde regio wanneer u Automatisch oplossen als de IR-regio selecteert. Voor andere specifieke locatieregio's kunt u een secundaire data factory in een andere regio maken en CI/CD gebruiken om uw data factory in te richten vanuit de Git-opslagplaats.
Voor beheerde virtuele netwerken moeten gebruikers handmatig overschakelen naar de secundaire regio.
Door Azure beheerde automatische failover is niet van toepassing op zelf-hostende Integration Runtime (SHIR), omdat de infrastructuur door de klant wordt beheerd. Zie Een zelf-hostende Integration Runtime maken en configureren voor hulp bij het instellen van meerdere knooppunten voor hogere beschikbaarheid met SHIR.
Als u BCDR wilt configureren voor Azure-SSIS IR, raadpleegt u Azure-SSIS Integration Runtime configureren voor bedrijfscontinuïteit en herstel na noodgevallen (BCDR).
Gekoppelde services zijn niet volledig ingeschakeld na een failover, vanwege in behandeling zijnde privé-eindpunten in het nieuwere netwerk van de regio. U moet privé-eindpunten configureren in de herstelde regio. U kunt het maken van privé-eindpunten automatiseren met behulp van de goedkeurings-API.
Door de gebruiker beheerde herstel instellen via CI/CD
U kunt Git en CI/CD gebruiken om pijplijnen handmatig te herstellen in het geval van data factory- of Azure Synapse-pijplijnverwijdering of -storing.
Zie Continue integratie en levering in Azure Data Factory en broncodebeheer in Azure Data Factory om CI/CD van Data Factory te gebruiken.
Zie Continue integratie en levering voor een Azure Synapse Analytics-werkruimte om CI/CD van Azure Synapse Pipeline te gebruiken. Zorg ervoor dat u eerst de Azure Synapse-werkruimte initialiseert. Zie Broncodebeheer in Synapse Studio voor meer informatie.
Wanneer u door de gebruiker beheerde redundantie implementeert met behulp van CI/CD, voert u de volgende acties uit:
Triggers uitschakelen
Schakel triggers in de oorspronkelijke primaire data factory uit zodra deze weer online is. U kunt de triggers handmatig uitschakelen of automatisering implementeren om periodiek de beschikbaarheid van de oorspronkelijke primaire te controleren. Schakel alle triggers uit op de oorspronkelijke primaire data factory direct nadat de fabriek is hersteld.
Als u Azure PowerShell wilt gebruiken om Data Factory-triggers uit of uit te schakelen, raadpleegt u Voorbeeldscript vóór en na de implementatie en CI/CD-verbeteringen met betrekking tot de implementatie van pijplijntriggers.
Dubbele schrijfbewerkingen verwerken
De meeste ETL-pijplijnen (extract, transform, load) zijn ontworpen voor het afhandelen van dubbele schrijfbewerkingen, omdat voor backfill en restatement deze nodig zijn. Gegevenssinks die transparante failover ondersteunen, kunnen dubbele schrijfbewerkingen verwerken met records samenvoegen of door alle records in het specifieke tijdsbereik te verwijderen en in te voegen.
Voor gegevenssinks die eindpunten wijzigen na een failover, kan de primaire en secundaire opslag dubbele of gedeeltelijke gegevens bevatten. U moet de gegevens handmatig samenvoegen.
Controleer de witness en beheer de pijplijnstroom (optioneel)
Over het algemeen moet u uw pijplijnen ontwerpen om activiteiten, zoals mislukte en opzoekactiviteiten, op te nemen voor het opnieuw starten van mislukte pijplijnen vanaf het punt van belang.
Voeg een globale parameter toe in uw data factory om de regio aan te geven, bijvoorbeeld
region='EastUS'in de primaire enregion='CentralUS'secundaire gegevensfactory.Maak een witness in een derde regio. De witness kan een REST-aanroep of elk type opslag zijn. De witness retourneert standaard
'EastUS'de huidige primaire regio.Wanneer er een noodgeval optreedt, werkt u de witness handmatig bij om bijvoorbeeld de nieuwe primaire regio
'CentralUS'te retourneren.Voeg een activiteit toe aan uw pijplijn om de witness op te zoeken en de huidige primaire waarde te vergelijken met de globale parameter.
- Als de parameters overeenkomen, wordt deze pijplijn uitgevoerd op de primaire regio. Ga verder met het echte werk.
- Als de parameters niet overeenkomen, wordt deze pijplijn uitgevoerd op de secundaire regio. U hoeft alleen het resultaat te retourneren.
Notitie
Deze benadering introduceert een afhankelijkheid van de witness-lookup in uw pijplijn. Als de witness niet wordt gelezen, worden alle pijplijnuitvoeringen gestopt.
Medewerkers
Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.
Belangrijkste auteurs:
Krishnakumar Rukmangathan | Senior Program Manager - Azure Data Factory-team
Sunil Sabat | Principal Program Manager - Azure Data Factory-team
Andere Inzenders:
Mario Zimmermann | Principal Software Engineering Manager - Azure Data Factory-team
Wee Hyong Tok | Principal Director van PM - Azure Data Factory-team
Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.
Volgende stappen
- Bedrijfscontinuïteitsbeheer in Azure
- Tolerantie in Azure
- Azure-tolerantieterminologie
- Regio’s en beschikbaarheidszones
- Replicatie in meerdere regio's in Azure
- Beslissingshandleiding voor Azure-regio's
- Azure-services die beschikbaarheidszones ondersteunen
- Gedeelde verantwoordelijkheid in de cloud
- Gegevensredundantie in Azure Data Factory
- Integratieruntime in Azure Data Factory
- Pijplijnen en activiteiten in Azure Data Factory en Azure Synapse Analytics
- Gegevensintegratie in Azure Synapse Analytics versus Azure Data Factory