Dela via


Välj rätt integreringskörningskonfiguration för ditt scenario

Integreringskörningen är en viktig del av infrastrukturen för dataintegreringslösningen som tillhandahålls av Azure Data Factory. Detta kräver att du fullt ut överväger hur du ska anpassa dig till den befintliga nätverksstrukturen och datakällan i början av utformningen av lösningen, samt överväga prestanda, säkerhet och kostnad.

Jämförelse av olika typer av integrationskörningar

I Azure Data Factory har vi tre typer av integreringskörningar: Azure Integration Runtime, den lokalt installerade integrationskörningen och Azure-SSIS-integreringskörningen. För Azure Integration Runtime kan du även aktivera ett hanterat virtuellt nätverk, vilket gör dess arkitektur annorlunda än den globala Azure-integreringskörningen.

I den här tabellen visas skillnaderna i vissa aspekter av alla integrationskörningar. Du kan välja lämplig efter dina faktiska behov. För Azure-SSIS-integreringskörningen kan du läsa mer i artikeln Skapa en Azure-SSIS-integreringskörning.

Funktion Azure integration runtime Azure Integration Runtime med hanterat virtuellt nätverk Lokal Integration Runtime
Hantera databearbetning Y Y N
Automatisk skalning Y Y* N
Dataflöde Y Y N
Lokal dataåtkomst N Y** Y
Private Link/privat slutpunkt N Y*** Y
Anpassad komponent/drivrutin N N Y

* När time-to-live (TTL) är aktiverat reserveras beräkningsstorleken för integreringskörningen enligt konfigurationen och kan inte skalas automatiskt.

** Lokala miljöer måste vara anslutna till Azure via Express Route eller VPN. Anpassade komponenter och drivrutiner stöds inte.

De privata slutpunkterna hanteras av Azure Data Factory-tjänsten.

Det är viktigt att välja en lämplig typ av integrationskörning. Det måste inte bara vara lämpligt för din befintliga arkitektur och krav för dataintegrering, utan du måste också överväga hur du ytterligare ska uppfylla växande affärsbehov och eventuell framtida ökning av arbetsbelastningen. Men det finns ingen metod som passar alla. Följande överväganden kan hjälpa dig att navigera i beslutet:

  1. Vilka är platserna för integrationskörning och datalager?
    Platsen för integreringskörning definierar platsen för dess serverdelsberäkning och var dataflytt, aktivitetssändning och datatransformering utförs. För att få bättre prestanda och överföringseffektivitet bör integreringskörningen ligga närmare datakällan eller mottagaren.

    • Azure-integreringskörningen identifierar automatiskt den lämpligaste platsen baserat på vissa regler (kallas även autolösning). Se information här: Azure IR-plats.
    • Azure-integreringskörningen med ett hanterat virtuellt nätverk har samma region som din datafabrik. Det kan inte lösas automatiskt som Azure-integreringskörningen.
    • Den lokala integrationskörningen finns i regionen för dina lokala datorer eller virtuella Azure-datorer.
  2. Är datalagret offentligt tillgängligt?
    Om datalagret är offentligt tillgängligt är skillnaden mellan de olika typerna av integrationskörningar inte stor. Om butiken finns bakom en brandvägg eller i ett privat nätverk, till exempel ett lokalt eller virtuellt nätverk, är de bättre alternativen Azure Integration Runtime med ett hanterat virtuellt nätverk eller en lokalt installerad integrationskörning.

    • Det krävs lite extra installation, till exempel Private Link Service och Load Balancer när du använder Azure Integration Runtime med ett hanterat virtuellt nätverk för att få åtkomst till ett datalager bakom en brandvägg eller i ett privat nätverk. Du kan läsa den här självstudien Access on-premises SQL Server from Data Factory Managed VNet using Private Endpoint (Åtkomst till lokal SQL Server från Data Factory Managed VNet med privat slutpunkt som exempel). Om datalagret finns i en lokal miljö måste den lokala miljön vara ansluten till Azure via Express Route eller ett S2S VPN.
    • Den lokalt installerade integrationskörningen är mer flexibel och kräver inte extra inställningar, Express Route eller VPN. Men du måste tillhandahålla och underhålla datorn själv.
    • Du kan också lägga till de offentliga IP-adresserna för Azure-integreringskörningen i listan över tillåtna brandväggar och tillåta åtkomst till datalagret, men det är inte en önskvärd lösning i mycket säkra produktionsmiljöer.
  3. Vilken säkerhetsnivå behöver du under dataöverföringen?
    Om du behöver bearbeta strikt konfidentiella data vill du försvara dig mot till exempel man-in-the-middle-attacker under dataöverföring. Sedan kan du välja att använda en privat slutpunkt och en privat länk för att säkerställa datasäkerhet.

    • Du kan skapa hanterade privata slutpunkter till dina datalager när du använder Azure Integration Runtime med ett hanterat virtuellt nätverk. De privata slutpunkterna underhålls av Azure Data Factory-tjänsten i det hanterade virtuella nätverket.
    • Du kan också skapa privata slutpunkter i ditt virtuella nätverk och den lokalt installerade integrationskörningen kan använda dem för att komma åt datalager.
    • Azure-integreringskörningen stöder inte privat slutpunkt och Private Link.
  4. Vilken underhållsnivå kan du tillhandahålla?
    Att underhålla infrastruktur, servrar och utrustning är en av de viktiga uppgifterna för IT-avdelningen i ett företag. Det tar vanligtvis mycket tid och ansträngning.

    • Du behöver inte bekymra dig om underhållet, till exempel uppdatering, korrigering och version av Azure Integration Runtime och Azure Integration Runtime med ett hanterat virtuellt nätverk. Azure Data Factory-tjänsten tar hand om alla underhållsinsatser.
    • Eftersom den lokalt installerade integrationskörningen är installerad på kunddatorer måste underhållet hanteras av slutanvändarna. Du kan dock aktivera automatisk uppdatering för att automatiskt hämta den senaste versionen av den lokalt installerade integrationskörningen när det finns en uppdatering. Om du vill veta mer om hur du aktiverar automatisk uppdatering och hantering av versionskontroll för den lokalt installerade integrationskörningen kan du läsa artikeln Automatisk uppdatering och upphörande av integrationskörning via lokalt installerad integrationskörning. Vi tillhandahåller också ett diagnostikverktyg för den lokalt installerade integrationskörningen för att kontrollera några vanliga problem. Mer information om diagnostikverktyget finns i artikeln Diagnostikverktyg för lokalt installerad integrationskörning. Dessutom rekommenderar vi att du använder Azure Monitor och Azure Log Analytics specifikt för att samla in dessa data och aktivera en enda fönsterruta med övervakning för dina lokala integrationskörningar. Läs mer om hur du konfigurerar detta i artikeln Konfigurera den lokalt installerade integrationskörningen för log analytics-samling för instruktioner.
  5. Vilka samtidighetskrav har du?
    När vi bearbetar storskaliga data, till exempel storskalig datamigrering, hoppas vi kunna förbättra bearbetningens effektivitet och hastighet så mycket som möjligt. Samtidighet är ofta ett stort krav för dataintegrering.

    • Azure Integration Runtime har det högsta samtidighetsstödet bland alla integrationskörningstyper. Dataintegreringsenhet (DIU) är den funktionsenhet som ska köras på Azure Data Factory. Du kan välja önskat antal DIU:er, till exempel aktiviteten Kopiera. Inom diu-omfånget kan du köra flera aktiviteter samtidigt. För olika regiongrupper har vi olika övre begränsningar. Läs mer om de här gränserna i artikeln Data Factory-gränser.
    • Azure-integreringskörningen med ett hanterat virtuellt nätverk har en liknande mekanism som Azure-integreringskörningen, men på grund av vissa arkitekturbegränsningar är samtidigheten den kan stödja mindre än Azure-integreringskörningen.
    • De samtidiga aktiviteter som den lokalt installerade integrationskörningen kan köra beror på datorns storlek och klusterstorlek. Du kan välja en större dator eller använda fler lokalt installerade integrationsnoder i klustret om du behöver större samtidighet.
  6. Behöver du några specifika funktioner?
    Det finns vissa funktionella skillnader mellan olika typer av integrationskörningar.

    • Dataflöde stöds av Azure Integration Runtime och Azure Integration Runtime med ett hanterat virtuellt nätverk. Du kan dock inte köra Dataflöde med hjälp av lokalt installerad integrationskörning.
    • Om du behöver installera anpassade komponenter, till exempel ODBC-drivrutiner, en JVM eller ett SQL Server-certifikat, är den lokala integrationskörningen ditt enda alternativ. Anpassade komponenter stöds inte av Azure Integration Runtime eller Azure Integration Runtime med ett hanterat virtuellt nätverk.

Arkitektur för integrationskörning

Baserat på egenskaperna för varje integrationskörning krävs olika arkitekturer för att uppfylla affärsbehoven för dataintegrering. Följande är några typiska arkitekturer som kan användas som referens.

Azure integration runtime

Azure Integration Runtime är en fullständigt hanterad, autoskalningsberäkning som du kan använda för att flytta data från Azure- eller icke-Azure-datakällor.

Skärmbild av integreringskörningen är en fullständigt hanterad.

  1. Trafiken från Azure Integration Runtime till datalager sker via det offentliga nätverket.
  2. Vi tillhandahåller ett intervall med statiska offentliga IP-adresser för Azure-integreringskörningen och dessa IP-adresser kan läggas till i listan över tillåtna datalagerbrandväggar. Mer information om hur du hämtar offentliga IP-adresser för Azure Integration-körningen finns i artikeln Azure Integration Runtime IP-adresser.
  3. Azure-integreringskörningen kan lösas automatiskt enligt regionen för datakällan och datamottagaren. Eller så kan du välja en viss region. Vi rekommenderar att du väljer den region som är närmast din datakälla eller mottagare, vilket kan ge bättre körningsprestanda. Läs mer om prestandaöverväganden i artikeln Felsöka kopieringsaktivitet i Azure IR.

Azure Integration Runtime med hanterat virtuellt nätverk

När du använder Azure Integration Runtime med ett hanterat virtuellt nätverk bör du använda hanterade privata slutpunkter för att ansluta dina datakällor för att säkerställa datasäkerhet under överföringen. Med vissa extra inställningar, till exempel Private Link Service och Load Balancer, kan hanterade privata slutpunkter också användas för att komma åt lokala datakällor.

Skärmbild av integreringskörning med ett hanterat virtuellt nätverk.

  1. En hanterad privat slutpunkt kan inte återanvändas i olika miljöer. Du måste skapa en uppsättning hanterade privata slutpunkter för varje miljö. Alla datakällor som stöds av hanterade privata slutpunkter finns i artikeln Datakällor och tjänster som stöds.
  2. Du kan också använda hanterade privata slutpunkter för anslutningar till externa beräkningsresurser som du vill orkestrera, till exempel Azure Databricks och Azure Functions. En fullständig lista över externa beräkningsresurser som stöds finns i artikeln Datakällor och tjänster som stöds.
  3. Hanterat virtuellt nätverk hanteras av Azure Data Factory-tjänsten. VNET-peering stöds inte mellan ett hanterat virtuellt nätverk och ett virtuellt kundnätverk.
  4. Kunder kan inte ändra konfigurationer direkt, till exempel NSG-regeln i ett hanterat virtuellt nätverk.
  5. Om någon egenskap för en hanterad privat slutpunkt skiljer sig mellan miljöer kan du åsidosätta den genom att parameterisera den egenskapen och ange respektive värde under distributionen. Mer information finns i artikeln Metodtips för CI/CD.

Lokal Integration Runtime

För att förhindra att data från olika miljöer stör varandra och säkerställer säkerheten i produktionsmiljön måste vi skapa en motsvarande integrationskörning med egen värd för varje miljö. Detta säkerställer tillräcklig isolering mellan olika miljöer.

Skärmbild av hur du skapar en motsvarande lokalt installerad integrationskörning för varje miljö.

Eftersom integrationskörningen med egen värd körs på en kundhanterad dator kan vi, för att minska kostnaderna, underhållet och uppgraderingen så mycket som möjligt, använda de delade funktionerna i den lokalt installerade integrationskörningen för olika projekt i samma miljö. Mer information om lokalt installerad integreringskörningsdelning finns i artikeln Skapa en delad lokalt installerad integrationskörning i Azure Data Factory. För att göra data säkrare under överföringen kan vi samtidigt välja att använda en privat länk för att ansluta datakällorna och nyckelvalvet och ansluta kommunikationen mellan den lokala integrationskörningen och Azure Data Factory-tjänsten.

Skärmbild av hur du använder delade funktioner i den lokalt installerade integrationskörningen för olika projekt i samma miljö.

  1. Express Route är inte obligatoriskt. Utan Express Route når data inte mottagaren via privata nätverk, till exempel ett virtuellt nätverk eller en privat länk, utan via det offentliga nätverket.
  2. Om det lokala nätverket är anslutet till det virtuella Azure-nätverket via Express Route eller VPN kan den lokala integrationskörningen installeras på virtuella datorer i ett virtuellt hubbnätverk.
  3. Den virtuella nätverksarkitekturen hub-spoke kan användas inte bara för olika projekt utan även för olika miljöer (Prod, QA och Dev).
  4. Den lokalt installerade integrationskörningen kan delas med flera datafabriker. Den primära datafabriken refererar till den som en delad lokalt installerad integrationskörning och andra refererar till den som en länkad integrationskörning med egen värd. En fysisk lokalt installerad integrationskörning kan ha flera noder i ett kluster. Kommunikationen sker bara mellan den primära lokala integrationskörningen och den primära noden, där arbetet distribueras till sekundära noder från den primära noden.
  5. Autentiseringsuppgifter för lokala datalager kan lagras antingen på den lokala datorn eller i ett Azure Key Vault. Azure Key Vault rekommenderas starkt.
  6. Kommunikationen mellan den lokala integrationskörningen och datafabriken kan gå via en privat länk. Men för närvarande stöder interaktiv redigering via Azure Relay och automatisk uppdatering till den senaste versionen från nedladdningscentret inte privat länk. Trafiken går genom brandväggen för den lokala miljön. Mer information finns i artikeln Azure Private Link för Azure Data Factory.
  7. Den privata länken krävs endast för den primära datafabriken. All trafik går via den primära datafabriken och sedan till andra datafabriker.
  8. Samma namn på den lokalt installerade integrationskörningen i alla faser av CI/CD förväntas. Du kan överväga att använda en ternary-fabrik bara för att innehålla de delade lokalt installerade integrationskörningarna och använda länkad lokalt installerad integrationskörning i de olika produktionsfaserna. Mer information finns i artikeln Kontinuerlig integrering och leverans.
  9. Du kan styra hur trafiken går till nedladdningscentret och Azure Relay med hjälp av konfigurationer av ditt lokala nätverk och Express Route, antingen via en lokal proxy eller ett virtuellt navnätverk. Kontrollera att trafiken tillåts av proxy- eller NSG-regler.
  10. Om du vill skydda kommunikationen mellan lokalt installerade integrationskörningsnoder kan du aktivera fjärråtkomst från intranätet med ett TLS/SSL-certifikat. Mer information finns i artikeln Aktivera fjärråtkomst från intranät med TLS/SSL-certifikat (Avancerat).