De juiste integration runtime-configuratie voor uw scenario kiezen

De integratieruntime is een belangrijk onderdeel van de infrastructuur voor de oplossing voor gegevensintegratie die wordt geleverd door Azure Data Factory. Hiervoor moet u zich volledig aanpassen aan de bestaande netwerkstructuur en gegevensbron aan het begin van het ontwerpen van de oplossing, en moet u rekening houden met prestaties, beveiliging en kosten.

Vergelijking van verschillende typen integratieruntimes

In Azure Data Factory hebben we drie soorten integratieruntimes: de Azure Integration Runtime, de zelf-hostende integratieruntime en de Azure-SSIS-integratieruntime. Voor de Azure Integration Runtime kunt u ook een beheerd virtueel netwerk inschakelen, waardoor de architectuur anders is dan de globale Azure Integration Runtime.

Deze tabel bevat de verschillen in sommige aspecten van alle integratieruntimes. U kunt de juiste kiezen op basis van uw werkelijke behoeften. Voor de Azure-SSIS-integratieruntime vindt u meer informatie in het artikel Een Azure-SSIS-integratieruntime maken.

Functie	Integratie-runtime Azure	Azure Integration Runtime met beheerd virtueel netwerk	Zelf-hostende Integration Runtime
Volledig beheerde rekenprocessen	J	Y	N
Automatisch schalen	J	Y*	N
Gegevensstroom	J	Y	N
Toegang tot on-premises gegevens	N	Y**	J
Private Link/Privé-eindpunt	N	Y***	J
Aangepast onderdeel/stuurprogramma	N	N	J

* Wanneer time-to-live (TTL) is ingeschakeld, wordt de rekenkracht van integration runtime gereserveerd volgens de configuratie en kan niet automatisch worden geschaald.

** On-premises omgevingen moeten zijn verbonden met Azure via Express Route of VPN. Aangepaste onderdelen en stuurprogramma's worden niet ondersteund.

De privé-eindpunten worden beheerd door de Azure Data Factory-service.

Het is belangrijk om een geschikt type Integration Runtime te kiezen. Het moet niet alleen geschikt zijn voor uw bestaande architectuur en vereisten voor gegevensintegratie, maar u moet ook bedenken hoe u verder moet voldoen aan de groeiende bedrijfsbehoeften en eventuele toekomstige toename van de workload. Maar er is geen één-size-fits-all benadering. De volgende overwegingen kunnen u helpen bij het navigeren in de beslissing:

1. Wat zijn de locaties voor integratieruntime en gegevensopslag?
   De locatie van de Integration Runtime definieert de locatie van de back-end-berekening en waar de gegevensverplaatsing, activiteitsverzending en gegevenstransformatie worden uitgevoerd. Om betere prestaties en transmissieefficiëntie te verkrijgen, moet de integratieruntime dichter bij de gegevensbron of sink zijn.

   • De Azure Integration Runtime detecteert automatisch de meest geschikte locatie op basis van bepaalde regels (ook wel autoresolve genoemd). Zie hier de details: Azure IR-locatie.
   • De Azure Integration Runtime met een beheerd virtueel netwerk heeft dezelfde regio als uw data factory. Het kan niet automatisch worden opgelost, zoals de Azure Integration Runtime.
   • De zelf-hostende Integration Runtime bevindt zich in de regio van uw lokale machines of virtuele Azure-machines.

2. Is het gegevensarchief openbaar toegankelijk?
   Als het gegevensarchief openbaar toegankelijk is, is het verschil tussen de verschillende typen integratieruntimes niet groot. Als de store zich achter een firewall of in een particulier netwerk bevindt, zoals een on-premises of virtueel netwerk, zijn de betere keuzes de Azure Integration Runtime met een beheerd virtueel netwerk of de zelf-hostende Integration Runtime.

   • Er is een aantal extra instellingen nodig, zoals Private Link Service en Load Balancer bij het gebruik van de Azure Integration Runtime met een beheerd virtueel netwerk voor toegang tot een gegevensarchief achter een firewall of in een particulier netwerk. Raadpleeg deze zelfstudie : Toegang tot on-premises SQL Server vanuit het beheerde VNet van Data Factory met behulp van een privé-eindpunt als voorbeeld. Als het gegevensarchief zich in een on-premises omgeving bevindt, moet de on-premises zijn verbonden met Azure via Express Route of een S2S VPN.
   • De zelf-hostende Integration Runtime is flexibeler en vereist geen extra instellingen, Express Route of VPN. Maar u moet de machine zelf leveren en onderhouden.
   • U kunt ook de openbare IP-adressen van de Azure Integration Runtime toevoegen aan de acceptatielijst van uw firewall en toegang geven tot het gegevensarchief, maar het is geen wenselijke oplossing in zeer veilige productieomgevingen.

3. Welk beveiligingsniveau hebt u nodig tijdens het verzenden van gegevens?
   Als u zeer vertrouwelijke gegevens wilt verwerken, wilt u zich beschermen tegen bijvoorbeeld man-in-the-middle-aanvallen tijdens gegevensoverdracht. Vervolgens kunt u ervoor kiezen om een privé-eindpunt en Private Link te gebruiken om gegevensbeveiliging te garanderen.

   • U kunt beheerde privé-eindpunten maken voor uw gegevensarchieven wanneer u de Azure Integration Runtime gebruikt met een beheerd virtueel netwerk. De privé-eindpunten worden onderhouden door de Azure Data Factory-service binnen het beheerde virtuele netwerk.
   • U kunt ook privé-eindpunten maken in uw virtuele netwerk en de zelf-hostende Integration Runtime kan deze gebruiken voor toegang tot gegevensarchieven.
   • De Azure Integration Runtime biedt geen ondersteuning voor Private Endpoint en Private Link.

4. Welk onderhoudsniveau kunt u bieden?
   Het onderhouden van infrastructuur, servers en apparatuur is een van de belangrijke taken van de IT-afdeling van een onderneming. Het kost meestal veel tijd en moeite.

   • U hoeft zich geen zorgen te maken over het onderhoud, zoals update, patch en versie van de Azure Integration Runtime en de Azure Integration Runtime met een beheerd virtueel netwerk. De Azure Data Factory-service zorgt voor alle onderhoudswerkzaamheden.
   • Omdat de zelf-hostende Integration Runtime is geïnstalleerd op klantcomputers, moet het onderhoud worden verzorgd door eindgebruikers. U kunt autoupdate echter inschakelen om automatisch de nieuwste versie van de zelf-hostende Integration Runtime op te halen wanneer er een update is. Voor meer informatie over het inschakelen van automatisch bijwerken en het beheren van versiebeheer van de zelf-hostende Integration Runtime, raadpleegt u het artikel Zelf-hostende Integration Runtime autoupdate en verlopen melding. We bieden ook een diagnostisch hulpprogramma voor de zelf-hostende Integration Runtime om een aantal veelvoorkomende problemen te controleren. Raadpleeg het artikel Zelf-hostende integration runtime diagnostic tool voor meer informatie over het diagnostische hulpprogramma voor diagnostische gegevens van het diagnostische hulpprogramma voor diagnostische gegevens. Daarnaast raden we u aan om Azure Monitor en Azure Log Analytics specifiek te gebruiken om die gegevens te verzamelen en één deelvenster glasbewaking in te schakelen voor uw zelf-hostende integratieruntimes. Meer informatie over het configureren hiervan vindt u in het artikel De zelf-hostende Integration Runtime configureren voor log analytics-verzameling voor instructies.

5. Welke gelijktijdigheidsvereisten hebt u?
   Bij het verwerken van grootschalige gegevens, zoals grootschalige gegevensmigratie, hopen we de efficiëntie en snelheid van verwerking zoveel mogelijk te verbeteren. Gelijktijdigheid is vaak een belangrijke vereiste voor gegevensintegratie.

   • De Azure Integration Runtime biedt de hoogste gelijktijdigheidsondersteuning voor alle typen integration runtime. Data Integration Unit (DIU) is de mogelijkheid om te worden uitgevoerd in Azure Data Factory. U kunt het gewenste aantal DIU's selecteren, bijvoorbeeld Copy-activiteit. Binnen het bereik van DIU kunt u meerdere activiteiten tegelijk uitvoeren. Voor verschillende regiogroepen hebben we verschillende bovengrens. Meer informatie over de details van deze limieten vindt u in het artikel Data Factory-limieten.
   • De Azure Integration Runtime met een beheerd virtueel netwerk heeft een vergelijkbaar mechanisme als de Azure Integration Runtime, maar vanwege een aantal architecturale beperkingen is de gelijktijdigheid die het kan ondersteunen minder dan Azure Integration Runtime.
   • De gelijktijdige activiteiten die door de zelf-hostende Integration Runtime kunnen worden uitgevoerd, zijn afhankelijk van de grootte en clustergrootte van de computer. U kunt een grotere machine kiezen of meer zelf-hostende integratieknooppunten in het cluster gebruiken als u meer gelijktijdigheid nodig hebt.

6. Hebt u specifieke functies nodig?
   Er zijn enkele functionele verschillen tussen de typen integratieruntimes.

   • De gegevensstroom wordt ondersteund door de Azure Integration Runtime en de Azure Integration Runtime met een beheerd virtueel netwerk. U kunt echter geen gegevensstroom uitvoeren met behulp van zelf-hostende Integration Runtime.
   • Als u aangepaste onderdelen, zoals ODBC-stuurprogramma's, een JVM of een SQL Server-certificaat, moet installeren, is de zelf-hostende Integration Runtime de enige optie. Aangepaste onderdelen worden niet ondersteund door de Azure Integration Runtime of de Azure Integration Runtime met een beheerd virtueel netwerk.

Architectuur voor integration runtime

Op basis van de kenmerken van elke integratieruntime zijn verschillende architecturen vereist om te voldoen aan de zakelijke behoeften van gegevensintegratie. Hier volgen enkele typische architecturen die als referentie kunnen worden gebruikt.

Integratie-runtime Azure

De Azure Integration Runtime is een volledig beheerde, automatisch geschaalde berekening die u kunt gebruiken om gegevens van Azure- of niet-Azure-gegevensbronnen te verplaatsen.

1. Het verkeer van de Azure Integration Runtime naar gegevensarchieven bevindt zich via een openbaar netwerk.
2. We bieden een reeks statische openbare IP-adressen voor de Azure Integration Runtime en deze IP-adressen kunnen worden toegevoegd aan de acceptatielijst van de firewall voor het doelgegevensarchief. Raadpleeg het artikel IP-adressen van Azure Integration Runtime voor meer informatie over het ophalen van openbare IP-adressen van de Azure Integration Runtime.
3. De Azure Integration Runtime kan automatisch worden opgelost op basis van de regio van de gegevensbron en de gegevenssink. U kunt ook een specifieke regio kiezen. U wordt aangeraden de regio te kiezen die zich het dichtst bij uw gegevensbron of sink bevindt, wat betere uitvoeringsprestaties kan bieden. Meer informatie over prestatieoverwegingen vindt u in het artikel Problemen met kopieeractiviteiten in Azure IR oplossen.

Azure Integration Runtime met beheerd virtueel netwerk

Wanneer u de Azure Integration Runtime gebruikt met een beheerd virtueel netwerk, moet u beheerde privé-eindpunten gebruiken om uw gegevensbronnen te verbinden om de gegevensbeveiliging tijdens de overdracht te garanderen. Met enkele extra instellingen, zoals Private Link Service en Load Balancer, kunnen beheerde privé-eindpunten ook worden gebruikt voor toegang tot on-premises gegevensbronnen.

1. Een beheerd privé-eindpunt kan niet opnieuw worden gebruikt in verschillende omgevingen. U moet voor elke omgeving een set beheerde privé-eindpunten maken. Raadpleeg het artikel Ondersteunde gegevensbronnen en -services voor alle gegevensbronnen die worden ondersteund door beheerde privé-eindpunten.
2. U kunt ook beheerde privé-eindpunten gebruiken voor verbindingen met externe rekenresources die u wilt organiseren, zoals Azure Databricks en Azure Functions. Raadpleeg het artikel Ondersteunde gegevensbronnen en -services voor een volledige lijst met ondersteunde externe rekenresources.
3. Beheerd virtueel netwerk wordt beheerd door de Azure Data Factory-service. VNET-peering wordt niet ondersteund tussen een beheerd virtueel netwerk en een virtueel netwerk van de klant.
4. Klanten kunnen configuraties zoals de NSG-regel in een beheerd virtueel netwerk niet rechtstreeks wijzigen.
5. Als een eigenschap van een beheerd privé-eindpunt verschilt tussen omgevingen, kunt u deze overschrijven door die eigenschap te parameteriseren en de respectieve waarde op te geven tijdens de implementatie. Zie de details in het artikel Aanbevolen procedures voor CI/CD.

Zelf-hostende Integration Runtime

Om te voorkomen dat gegevens uit verschillende omgevingen elkaar verstoren en de beveiliging van de productieomgeving garanderen, moeten we een bijbehorende zelf-hostende Integration Runtime maken voor elke omgeving. Dit zorgt voor voldoende isolatie tussen verschillende omgevingen.

Aangezien de zelf-hostende Integration Runtime wordt uitgevoerd op een door de klant beheerde machine, om de kosten, het onderhoud en de upgrade zoveel mogelijk te verlagen, kunnen we gebruikmaken van de gedeelde functies van de zelf-hostende Integration Runtime voor verschillende projecten in dezelfde omgeving. Raadpleeg het artikel Een gedeelde zelf-hostende Integration Runtime maken in Azure Data Factory voor meer informatie over het delen van zelf-hostende Integration Runtime. Tegelijkertijd, om de gegevens veiliger te maken tijdens verzending, kunnen we ervoor kiezen om een privékoppeling te gebruiken om de gegevensbronnen en sleutelkluis te verbinden en de communicatie tussen de zelf-hostende Integration Runtime en de Azure Data Factory-service te verbinden.

1. Express Route is niet verplicht. Zonder Express Route bereiken de gegevens de sink niet via privénetwerken, zoals een virtueel netwerk of een privékoppeling, maar via het openbare netwerk.
2. Als het on-premises netwerk is verbonden met het virtuele Azure-netwerk via Express Route of VPN, kan de zelf-hostende Integration Runtime worden geïnstalleerd op virtuele machines in een Hub-VNET.
3. De hub-spoke-architectuur voor virtuele netwerken kan niet alleen worden gebruikt voor verschillende projecten, maar ook voor verschillende omgevingen (Prod, QA en Dev).
4. De zelf-hostende Integration Runtime kan worden gedeeld met meerdere data factory's. De primaire data factory verwijst ernaar als een gedeelde zelf-hostende Integration Runtime en anderen verwijzen ernaar als een gekoppelde zelf-hostende Integration Runtime. Een fysieke zelf-hostende Integration Runtime kan meerdere knooppunten in een cluster hebben. Communicatie vindt alleen plaats tussen de primaire zelf-hostende Integration Runtime en het primaire knooppunt, waarbij werk wordt gedistribueerd naar secundaire knooppunten vanaf het primaire knooppunt.
5. Referenties van on-premises gegevensarchieven kunnen worden opgeslagen op de lokale computer of een Azure Key Vault. Azure Key Vault wordt ten zeerste aanbevolen.
6. Communicatie tussen de zelf-hostende Integration Runtime en data factory kan via een privékoppeling worden uitgevoerd. Maar op dit moment biedt interactieve creatie via Azure Relay en automatisch bijwerken naar de nieuwste versie vanuit het downloadcentrum geen ondersteuning voor private link. Het verkeer gaat via de firewall van de on-premises omgeving. Zie het artikel Azure Private Link voor Azure Data Factory voor meer informatie.
7. De privékoppeling is alleen vereist voor de primaire data factory. Al het verkeer gaat door de primaire data factory en vervolgens naar andere data factory's.
8. Dezelfde naam van de zelf-hostende Integration Runtime in alle fasen van CI/CD wordt verwacht. U kunt overwegen om een ternaire factory te gebruiken om alleen de gedeelde zelf-hostende integratieruntimes te bevatten en gekoppelde zelf-hostende Integration Runtime te gebruiken in de verschillende productiefasen. Zie het artikel Continue integratie en levering voor meer informatie.
9. U kunt bepalen hoe het verkeer naar het downloadcentrum en Azure Relay gaat met behulp van configuraties van uw on-premises netwerk en Express Route, hetzij via een on-premises proxy of virtueel hubnetwerk. Zorg ervoor dat het verkeer is toegestaan door proxy- of NSG-regels.
10. Als u de communicatie tussen zelf-hostende Integration Runtime-knooppunten wilt beveiligen, kunt u externe toegang via het intranet inschakelen met een TLS/SSL-certificaat. Zie het artikel Externe toegang via intranet inschakelen met TLS/SSL-certificaat (geavanceerd) voor meer informatie.