Betrouwbaarheid in Azure Data Factory

Met Azure Data Factory kunt u flexibele en krachtige gegevenspijplijnen maken voor serverloze gegevensintegratie en gegevenstransformatie. Als Azure-service biedt Data Factory een scala aan mogelijkheden ter ondersteuning van uw betrouwbaarheidsvereisten.

Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.

In dit artikel wordt beschreven hoe u Data Factory bestand maakt tegen verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten, storingen in de beschikbaarheidszone en regiostoringen. Er wordt ook beschreven hoe u back-ups kunt gebruiken om andere soorten problemen op te lossen en er wordt belangrijke informatie over de Service Level Agreement (SLA) van Data Factory uitgelicht.

Opmerking

Wanneer u rekening houdt met de betrouwbaarheid van uw data factory, moet u ook rekening houden met de betrouwbaarheid van de gegevensarchieven waarmee deze verbinding maakt. Het verbeteren van de tolerantie van de data factory alleen kan een beperkte impact hebben als de gegevensarchieven niet even tolerant zijn. Afhankelijk van uw tolerantievereisten moet u mogelijk configuratiewijzigingen aanbrengen in meerdere gebieden. Raadpleeg de documentatie en richtlijnen voor productbetrouwbaarheid om ervoor te zorgen dat gegevensarchieven voldoen aan uw vereisten voor bedrijfscontinuïteit.

Overzicht van betrouwbaarheidsarchitectuur

Data Factory bestaat uit meerdere infrastructuuronderdelen. Elk onderdeel ondersteunt de betrouwbaarheid van de infrastructuur op verschillende manieren.

De onderdelen van Data Factory zijn onder andere:

• De data factory-kernservice, die pijplijntriggers beheert en toezicht houdt op de coördinatie van pijplijnactiviteiten. De kernservice beheert ook metagegevens voor elk onderdeel in de data factory. Microsoft beheert de kernservice.

• Integratieruntimes (IR's) die verbinding maken met gegevensarchieven en activiteiten uitvoeren die zijn gedefinieerd in uw pijplijn. Er zijn verschillende typen IR's.

  • Door Microsoft beheerde IR's, waaronder de Azure IR en de Azure-SQL Server Integration Services (Azure-SSIS) IR. Microsoft beheert de onderdelen waaruit deze runtimes bestaan. In sommige scenario's configureert u instellingen die van invloed zijn op de tolerantie van uw IR's.

  • Zelfgehoste Integration Runtimes (SHIRs). Microsoft biedt software die u op uw eigen rekeninfrastructuur kunt uitvoeren om bepaalde onderdelen van uw Data Factory-pijplijnen uit te voeren. U bent verantwoordelijk voor de implementatie en het beheer van rekenresources en voor de tolerantie van deze rekenresources.

Tolerantie voor tijdelijke fouten

Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle in de cloud gehoste toepassingen moeten de richtlijnen voor tijdelijke foutafhandeling van Azure volgen wanneer ze communiceren met eventuele in de cloud gehoste API's, databases en andere onderdelen. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

Wanneer u Data Factory gebruikt, is het belangrijk dat u zich voorbereidt op tijdelijke fouten, met name wanneer u pijplijnen en activiteiten ontwerpt.

Idempotentie

Uw pijplijnactiviteiten moeten idempotent zijn, wat betekent dat ze meerdere keren kunnen worden uitgevoerd zonder nadelige effecten te veroorzaken. Als een tijdelijke fout, zoals een netwerkfout of een storing in de beschikbaarheidszone, zich voordoet, kan Data Factory pijplijnactiviteiten opnieuw uitvoeren. Een herhaling kan dubbele records genereren.

Implementeer de volgende aanbevolen procedures om dubbele recordinvoeging vanwege een tijdelijke fout te voorkomen:

• Gebruik unieke id's voor elke record voordat u naar de database schrijft. Met deze methode kunt u dubbele records vinden en elimineren.

• Gebruik een upsert-strategie voor connectors die upsert ondersteunen. Voordat dubbele recordinvoeging plaatsvindt, gebruikt u deze methode om te controleren of er al een record bestaat. Als deze bestaat, werkt u deze bij. Als deze niet bestaat, voegt u deze in. SQL-opdrachten zoals MERGE of ON DUPLICATE KEY UPDATE gebruiken bijvoorbeeld deze upsert-benadering.

• Gebruik strategieën voor het kopiëren. Zie Verificatie van gegevensconsistentie in kopieeractiviteit voor meer informatie.

Beleid opnieuw proberen

U kunt beleid voor opnieuw proberen gebruiken om onderdelen van uw pijplijn te configureren om het opnieuw te proberen als er een probleem is, zoals tijdelijke fouten in verbonden resources. In Data Factory kunt u beleid voor opnieuw proberen configureren voor de volgende pijplijnobjecttypen:

• Triggers voor vallende vensters
• Uitvoeringsactiviteiten

Zie Pijplijnuitvoeringen en -triggers voor meer informatie over het wijzigen of uitschakelen van beleid voor opnieuw proberen voor uw data factory-triggers en -activiteiten.

Tolerantie voor fouten in beschikbaarheidszones

Beschikbaarheidszones zijn fysiek gescheiden groepen datacenters binnen een Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

Data Factory biedt ondersteuning voor zoneredundantie, wat tolerantie biedt voor fouten in beschikbaarheidszones.

Elk onderdeel van Data Factory ondersteunt zoneredundantie:

• Kernservice: Microsoft beheert de onderdelen in de Data Factory-kernservice en verspreidt deze over beschikbaarheidszones.

  Na een zonefout garandeert Microsoft echter niet de toestand van tumbling window-triggers.

• Irs: Ondersteuning voor zoneredundantie is afhankelijk van het type IR dat u gebruikt.

  • Een Azure IR ondersteunt zoneredundantie en Microsoft beheert deze mogelijkheid.

    

  • Voor een Azure-SSIS IR moet u ten minste twee knooppunten implementeren. Deze knooppunten worden automatisch toegewezen aan verschillende beschikbaarheidszones.

    In het volgende diagram ziet u een zone-redundante pijplijn en een Azure-SSIS Integration Runtime met twee knooppunten die in verschillende zones zijn geïmplementeerd:

    

  • Een SHIR geeft u de verantwoordelijkheid voor het implementeren van de rekeninfrastructuur om de runtime te hosten. U kunt meerdere knooppunten implementeren, zoals afzonderlijke virtuele machines (VM's) en deze configureren voor hoge beschikbaarheid. U kunt deze knooppunten vervolgens distribueren over meerdere beschikbaarheidszones. Zie Hoge beschikbaarheid en schaalbaarheid voor meer informatie.

Requirements

Zone-redundante Data Factory-resources kunnen worden geïmplementeerd in elke regio die beschikbaarheidszones ondersteunt.

Kosten

• Kernservice: Er zijn geen extra kosten van toepassing op zoneredundantie.

• Irs: De kosten van zoneredundantie zijn afhankelijk van het type IR dat u gebruikt.

  • Een Azure IR omvat zoneredundantie zonder extra kosten.

  • Voor een Azure-SSIS IR moet u ten minste twee knooppunten implementeren om zoneredundantie te bereiken. Zie het prijsvoorbeeld: SSIS-pakketten uitvoeren op een Azure-SSIS IR voor meer informatie over hoe elk knooppunt wordt gefactureerd.

  • Voor een SHIR moet u de rekeninfrastructuur implementeren en beheren. Als u zonetolerantie wilt bereiken, moet u uw rekenresources over meerdere zones verdelen. Afhankelijk van het aantal knooppunten dat u implementeert en hoe u deze configureert, kunnen er extra kosten in rekening worden gebracht van de onderliggende rekenservices en andere ondersteunende services. Er zijn geen extra kosten verbonden aan het uitvoeren van de SHIR op meerdere knooppunten.

Ondersteuning voor beschikbaarheidszones configureren

• Kernservice: Er is geen configuratie vereist. De Data Factory-kernservice ondersteunt automatisch zoneredundantie.

• Irs:

  • Een Azure IR: Er is geen configuratie vereist. De Azure IR schakelt automatisch zoneredundantie in.

  • Een Azure-SSIS IR: Er is geen configuratie vereist. Met een Azure-SSIS IR wordt zoneredundantie automatisch ingeschakeld wanneer deze wordt geïmplementeerd met twee of meer knooppunten.

  • Een SHIR vereist dat u uw eigen tolerantie configureert, waaronder het spreiden van uw knooppunten in meerdere beschikbaarheidszones.

Capaciteitsplanning en -beheer

• Kernservice: De Data Factory-kernservice wordt automatisch geschaald op basis van vraag en u hoeft geen capaciteit te plannen of te beheren.

• Irs:

  • Een Azure IR wordt automatisch geschaald op basis van vraag en u hoeft geen capaciteit te plannen of te beheren.

  • Voor een Azure-SSIS IR moet u specifiek het aantal knooppunten configureren dat u gebruikt. nl-NL: Als u zich wilt voorbereiden op een uitval van de beschikbaarheidszone, kunt u overwegen om de capaciteit van uw IR te vergroten door middel van overprovisionering. Met overinrichting kan de oplossing enige mate van capaciteitsverlies tolereren en toch blijven functioneren zonder verminderde prestaties. Zie Capaciteit beheren door overprovisioning voor meer informatie.

  • Voor een SHIR moet u uw eigen capaciteit en schaalaanpassing configureren. Overweeg overprovisionering wanneer u een SHIR implementeert.

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer Data Factory-resources zijn geconfigureerd voor zoneredundantie en alle beschikbaarheidszones operationeel zijn.

• Verkeersroutering tussen zones: Tijdens normale bewerkingen distribueert Data Factory automatisch pijplijnactiviteiten, triggers en ander werk tussen gezonde exemplaren in elke beschikbaarheidszone.

• Gegevensreplicatie tussen zones: Over het algemeen is Data Factory een staatloze service, dus er hoeft geen status te worden gerepliceerd tussen zones.

  Tumbling window triggers bevatten echter een status, die mogelijk niet volledig tussen zones wordt gerepliceerd.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer Data Factory-resources zijn geconfigureerd voor zoneredundantie en er een storing in de beschikbaarheidszone is.

• Detectie en reactie: Het Data Factory-platform is verantwoordelijk voor het detecteren van een fout in een beschikbaarheidszone en reageert. U hoeft niets te doen om een zonefailover te starten in uw pijplijnen of andere onderdelen.

• Melding: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt Azure Resource Health echter gebruiken om te controleren op de status van een afzonderlijke resource en u kunt Resource Health-waarschuwingen instellen om u op de hoogte te stellen van problemen. U kunt Azure Service Health ook gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele zonefouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

• Actieve aanvragen: Eventuele pijplijnen en triggers die in uitvoering zijn, blijven doorgaan en u ondervindt geen onmiddellijke verstoring door een storing in een zone. Activiteiten die worden uitgevoerd tijdens een zonefout kunnen echter mislukken en opnieuw worden gestart. Het is belangrijk om activiteiten te ontwerpen die idempotent zijn, zodat ze kunnen herstellen van zonefouten en andere fouten. Zie Tolerantie voor tijdelijke fouten voor meer informatie.

• Verwachte downtime: Er wordt geen downtime verwacht tijdens een zonefout.

• Verwachte gegevensverlies: Over het algemeen is Data Factory een staatloze service, dus er wordt geen gegevensverlies verwacht tijdens een zonefout.

  Als u echter een tumbling window-trigger gebruikt, kan de status van de trigger verloren raken na een zonefout. U moet alle triggers die werden uitgevoerd op het moment van de zonefout opnieuw starten of opnieuw uitvoeren.

Zoneherstel

Wanneer de beschikbaarheidszone wordt hersteld, wordt in Data Factory automatisch een failback uitgevoerd naar de oorspronkelijke zone. U hoeft niets te doen om een zone-failback te starten in uw pijplijnen of andere onderdelen.

Als u echter een SHIR gebruikt, moet u uw rekenresources mogelijk opnieuw opstarten als deze zijn gestopt.

Testen op zonefouten

Voor de kernservice en voor Azure en Azure-SSIS IRs beheert Data Factory verkeersroutering, failover en failback voor zone-redundante resources. Omdat deze functie volledig wordt beheerd, hoeft u geen processen voor fouten in de beschikbaarheidszone te initiëren of valideren.

Voor SHIR's kunt u Azure Chaos Studio gebruiken om een fout in de beschikbaarheidszone op een Azure-VM te simuleren.

Tolerantie voor storingen in de hele regio

Data Factory-resources worden geïmplementeerd in één Azure-regio. Als de regio niet meer beschikbaar is, is uw data factory ook niet beschikbaar. Er zijn echter benaderingen die u kunt gebruiken om tolerantie voor storingen in regio's te garanderen. Deze benaderingen zijn afhankelijk van of de data factory zich in een gekoppelde of niet-gepaareerde regio bevindt en aan uw specifieke vereisten en configuratie.

Microsoft-beheerd failover naar een gekoppelde regio

Data Factory ondersteunt door Microsoft beheerde failover voor gegevensfactory's in gekoppelde regio's, met uitzondering van Brazilië - zuid en Zuidoost-Azië. In het onwaarschijnlijke geval van een langdurige regiofout kan Microsoft een regionale failover van uw Data Factory-exemplaar initiëren.

Vanwege vereisten voor gegevenslocatie in Brazilië - zuid en Zuidoost-Azië worden gegevens alleen opgeslagen in de lokale regio met behulp van zone-redundante opslag van Azure Storage. Voor Zuidoost-Azië worden alle gegevens opgeslagen in Singapore. Voor Brazilië - zuid worden alle gegevens opgeslagen in Brazilië.

Voor gegevensfabrieken in niet-gepaarde regio's, of in Brazilië Zuid of Zuidoost-Azië, voert Microsoft geen regionale failover namens u uit.

Belangrijk

Microsoft activeert door Microsoft beheerde failover. Het is waarschijnlijk na een aanzienlijke vertraging en wordt uitgevoerd op basis van best effort. Er zijn ook enkele uitzonderingen op dit proces. Mogelijk ondervindt u een verlies van de metagegevens van uw data factory. De failover van Data Factory-resources kan optreden op een tijdstip dat verschilt van de failovertijd van andere Azure-services.

Als u bestand moet zijn tegen storingen in regio's, kunt u overwegen een van de aangepaste oplossingen voor meerdere regio's te gebruiken voor tolerantie.

Overschakelen van IR-apparaten

Om een failover voor te bereiden, zijn er mogelijk enkele extra overwegingen, afhankelijk van de IR die u gebruikt.

• U kunt de Azure IR configureren om automatisch de regio op te lossen die wordt gebruikt. Als de regio is ingesteld op automatisch oplossen en er sprake is van een storing in de primaire regio, voert de Azure IR automatisch een failover uit naar de gekoppelde regio. Deze failover is onderhevig aan beperkingen. Als u de Azure IR-regio wilt configureren voor de implementatie of verzending van uw activiteit in de ir-installatie, stelt u de regio in op automatisch oplossen.

• Azure-SSIS IR-failover wordt afzonderlijk beheerd van een door Microsoft beheerde failover van de data factory. Zie Aangepaste oplossingen voor meerdere regio's voor tolerantie voor meer informatie.

• Een SHIR wordt uitgevoerd op de infrastructuur waarvoor u verantwoordelijk bent, zodat een door Microsoft beheerde failover niet van toepassing is op SHIR's. Zie Aangepaste oplossingen voor meerdere regio's voor tolerantie voor meer informatie.

Herconfiguratie na een failover-situatie

Nadat een door Microsoft beheerde failover is voltooid, hebt u toegang tot uw Data Factory-pijplijn in de gekoppelde regio. Nadat de failover is voltooid, moet u mogelijk een aantal herconfiguraties uitvoeren voor IR's of andere onderdelen. Dit proces omvat het opnieuw tot stand brengen van de netwerkconfiguratie.

Aangepaste oplossingen voor meerdere regio's voor veerkracht

Als u wilt dat uw pijplijnen bestand zijn tegen regionale storingen en u controle nodig hebt over het failoverproces, kunt u overwegen om een pijplijn op basis van metagegevens te gebruiken.

• Stel broncodebeheer in voor Data Factory om wijzigingen in uw metagegevens bij te houden en te controleren. U kunt deze methode gebruiken om toegang te krijgen tot uw JSON-metagegevensbestanden voor pijplijnen, gegevenssets, gekoppelde services en triggers. Data Factory ondersteunt verschillende typen Git-opslagplaatsen, zoals Azure DevOps en GitHub. Zie Broncodebeheer in Data Factory voor meer informatie.

• Gebruik een CI/CD-systeem (continue integratie en continue levering), zoals Azure DevOps, om de metagegevens en implementaties van uw pijplijn te beheren. U kunt CI/CD gebruiken om snel bewerkingen te herstellen naar een exemplaar in een andere regio. Als een regio niet beschikbaar is, kunt u handmatig of via automatisering een nieuwe data factory inrichten. Nadat de nieuwe datafabriek is aangemaakt, kunt u uw pijplijnen, gegevenssets en gekoppelde services herstellen vanuit de bestaande Git-opslagplaats. Zie BCDR (Bedrijfscontinuïteit en herstel na noodgevallen) voor Data Factory- en Azure Synapse Analytics-pijplijnen voor meer informatie.

Afhankelijk van de IR die u gebruikt, zijn er mogelijk andere overwegingen.

• Een Azure-SSIS IR maakt gebruik van een database die is opgeslagen in Azure SQL Database of Azure SQL Managed Instance. U kunt geo-replicatie of een failovergroep voor deze database configureren. De Azure-SSIS-database bevindt zich in een primaire Azure-regio met lees-/schrijftoegang. De database wordt continu gerepliceerd naar een secundaire regio met alleen-lezentoegang. Als de primaire regio niet beschikbaar is, wordt er een failover geactiveerd, waardoor de primaire en secundaire databases rollen kunnen wisselen.

  U kunt ook een dubbel stand-by Azure SSIS IR-paar configureren dat synchroon werkt met een Azure SQL Database- of SQL Managed Instance-failovergroep.

  Zie Een Azure-SSIS IR configureren voor BCDR voor meer informatie.

• Een SHIR wordt uitgevoerd op infrastructuur die u beheert. Als de SHIR is geïmplementeerd op een Virtuele Azure-machine, kunt u Azure Site Recovery gebruiken om een VM-failover naar een andere regio te activeren.

Backups en herstel

Data Factory ondersteunt CI/CD via broncodebeheerintegratie, zodat u een back-up kunt maken van de metagegevens van een data factory-exemplaar. CI/CD-pijplijnen implementeren deze metagegevens naadloos in een nieuwe omgeving. Zie CI/CD in Data Factory voor meer informatie.

Diensteniveauovereenkomst

De SLA (Service Level Agreement) voor Azure-services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen om die beschikbaarheidsverwachting te bereiken. Zie SLA's voor onlineservices voor meer informatie.

Data Factory biedt afzonderlijke beschikbaarheidS-SLA's voor:

• Het succespercentage van API-aanroepen die u maakt, zoals die voor het beheren van uw data factory.
• Het aantal uitvoeringen van activiteiten dat begint.

Uitvoeringen van activiteit mogen kort worden uitgesteld en vereisen dat aan alle afhankelijkheden voor het uitvoeren van de taak is voldaan.

Verwante inhoud

• Betrouwbaarheid in Azure