Dela via

Skapa och konfigurera lokalt installerad integrationskörning

  • Artikel

GÄLLER FÖR: Azure Data Factory Azure Synapse Analytics

Dricks

Prova Data Factory i Microsoft Fabric, en allt-i-ett-analyslösning för företag. Microsoft Fabric omfattar allt från dataflytt till datavetenskap, realtidsanalys, business intelligence och rapportering. Lär dig hur du startar en ny utvärderingsversion kostnadsfritt!

Integration Runtime (IR) är den beräkningsinfrastruktur som Azure Data Factory- och Synapse-pipelines använder för att tillhandahålla dataintegreringsfunktioner i olika nätverksmiljöer. Mer information om IR finns i Översikt över integrationskörning.

En lokalt installerad IR kan köra kopieringsaktiviteter mellan ett molndatalager och ett datalager i ett privat nätverk. Den kan också skicka transformeringsaktiviteter mot beräkningsresurser i ett lokalt nätverk eller ett virtuellt Azure-nätverk. För installation av en lokalt installerad IR krävs en lokal dator eller en virtuell dator i ett privat nätverk.

Den här artikeln beskriver hur du kan skapa och konfigurera en lokalt installerad IR.

Kommentar

Vi rekommenderar att du använder Azure Az PowerShell-modulen för att interagera med Azure. Se Installera Azure PowerShell för att komma igång. Information om hur du migrerar till Az PowerShell-modulen finns i artikeln om att migrera Azure PowerShell från AzureRM till Az.

Överväganden för att använda en lokalt installerad IR

  • Du kan använda en enda lokalt installerad integrationskörning för flera lokala datakällor. Du kan också dela den med en annan datafabrik i samma Microsoft Entra-klientorganisation. Mer information finns i Dela en lokalt installerad integrationskörning.
  • Du kan bara installera en instans av en lokalt installerad integrationskörning på en enskild dator. Om du har två datafabriker som behöver åtkomst till lokala datakällor använder du antingen den lokalt installerade IR-delningsfunktionen för att dela den lokalt installerade IR:en eller installera den lokalt installerade IR:en på två lokala datorer, en för varje datafabrik eller Synapse-arbetsyta. Synapse-arbetsytan stöder inte integreringskörningsdelning.
  • Den lokalt installerade integrationskörningen behöver inte finnas på samma dator som datakällan. Att ha den lokalt installerade integrationskörningen nära datakällan minskar dock tiden för den lokalt installerade integrationskörningen att ansluta till datakällan. Vi rekommenderar att du installerar den lokala integrationskörningen på en dator som skiljer sig från den som är värd för den lokala datakällan. När den lokalt installerade integrationskörningen och datakällan finns på olika datorer konkurrerar inte den lokalt installerade integrationskörningen med datakällan om resurser.
  • Du kan ha flera lokalt installerade integrationskörningar på olika datorer som ansluter till samma lokala datakälla. Om du till exempel har två lokalt installerade integrationskörningar som hanterar två datafabriker kan samma lokala datakälla registreras med båda datafabrikerna.
  • Använd en lokalt installerad integrationskörning för att stödja dataintegrering i ett virtuellt Azure-nätverk.
  • Behandla din datakälla som en lokal datakälla som finns bakom en brandvägg, även när du använder Azure ExpressRoute. Använd den lokalt installerade integrationskörningen för att ansluta tjänsten till datakällan.
  • Använd den lokala integrationskörningen även om datalagret finns i molnet på en virtuell IaaS-dator (Azure Infrastructure as a Service).
  • Uppgifter kan misslyckas i en lokalt installerad integrationskörning som du har installerat på en Windows-server som FIPS-kompatibel kryptering är aktiverad för. För att undvika det här problemet har du två alternativ: lagra autentiseringsuppgifter/hemliga värden i ett Azure Key Vault eller inaktivera FIPS-kompatibel kryptering på servern. Om du vill inaktivera FIPS-kompatibel kryptering ändrar du följande registerundernyckels värde från 1 (aktiverad) till 0 (inaktiverad): HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled. Om du använder den lokalt installerade integrationskörningen som proxy för SSIS-integreringskörning kan FIPS-kompatibel kryptering aktiveras och används när du flyttar data från en lokal plats till Azure Blob Storage som mellanlagringsområde.
  • Fullständig licensieringsinformation finns på den första sidan i installationsprogrammet för lokalt installerad integrationskörning.

Kommentar

För närvarande kan lokalt installerad integrationskörning endast delas med flera datafabriker, den kan inte delas mellan Synapse-arbetsytor eller mellan datafabriken och Synapse-arbetsytan.

Kommandoflöde och dataflöde

När du flyttar data mellan lokalt och molnet använder aktiviteten en lokalt installerad integrationskörning för att överföra data mellan en lokal datakälla och molnet.

Här är en översikt över dataflödesstegen för kopiering med en lokalt installerad IR:

Översikt över dataflöde på hög nivå

  1. En datautvecklare skapar först en lokalt installerad integrationskörning i en Azure-datafabrik eller Synapse-arbetsyta med hjälp av Azure Portal eller PowerShell-cmdleten. Sedan skapar datautvecklaren en länkad tjänst för ett lokalt datalager och anger den lokala integrationskörningsinstansen som tjänsten ska använda för att ansluta till datalager.

  2. Den lokalt installerade integrationskörningsnoden krypterar autentiseringsuppgifterna med hjälp av Windows Data Protection Application Programming Interface (DPAPI) och sparar autentiseringsuppgifterna lokalt. Om flera noder har angetts för hög tillgänglighet synkroniseras autentiseringsuppgifterna ytterligare mellan andra noder. Varje nod krypterar autentiseringsuppgifterna med hjälp av DPAPI och lagrar dem lokalt. Synkronisering av autentiseringsuppgifter är transparent för datautvecklaren och hanteras av den lokalt installerade IR:en.

  3. Azure Data Factory- och Synapse-pipelines kommunicerar med den lokala integrationskörningen för att schemalägga och hantera jobb. Kommunikationen sker via en kontrollkanal som använder en delad Azure Relay-anslutning . När ett aktivitetsjobb måste köras köar tjänsten begäran tillsammans med eventuell information om autentiseringsuppgifter. Det gör det om autentiseringsuppgifterna inte redan lagras på den lokalt installerade integrationskörningen. Den lokalt installerade integrationskörningen startar jobbet när det avsöker kön.

  4. Den lokalt installerade integrationskörningen kopierar data mellan ett lokalt lager och molnlagring. Kopieringens riktning beror på hur kopieringsaktiviteten konfigureras i datapipelinen. För det här steget kommunicerar den lokalt installerade integrationskörningen direkt med molnbaserade lagringstjänster som Azure Blob Storage via en säker HTTPS-kanal.

Förutsättningar

  • De versioner av Windows som stöds är:
    • Windows 10
    • Windows 11
    • Windows Server 2016
    • Windows Server 2019
    • Windows Server 2022

Installation av den lokalt installerade integrationskörningen på en domänkontrollant stöds inte.

  • Lokalt installerad integrationskörning kräver ett 64-bitars operativsystem med .NET Framework 4.7.2 eller senare. Mer information finns i Systemkrav för .NET Framework.
  • Den rekommenderade minsta konfigurationen för den lokalt installerade integrationskörningsdatorn är en 2 GHz-processor med 4 kärnor, 8 GB RAM-minne och 80 GB tillgängligt hårddiskutrymme. Mer information om systemkrav finns i Ladda ned.
  • Om värddatorn viloläge, svarar inte den lokalt installerade integrationskörningen på databegäranden. Konfigurera ett lämpligt energischema på datorn innan du installerar den lokalt installerade integrationskörningen. Om datorn är konfigurerad för viloläge uppmanas installationsprogrammet för lokalt installerad integrationskörning med ett meddelande.
  • Du måste vara administratör på datorn för att kunna installera och konfigurera den lokalt installerade integrationskörningen.
  • Kopieringsaktivitetskörningar sker med en specifik frekvens. Processor- och RAM-användning på datorn följer samma mönster med toppar och inaktiva tider. Resursanvändningen beror också mycket på mängden data som flyttas. När flera kopieringsjobb pågår ser du resursanvändningen öka under tider med hög belastning.
  • Uppgifter kan misslyckas vid extrahering av data i Parquet-, ORC- eller Avro-format. Mer information om Parquet finns i Parquet-format i Azure Data Factory. Filskapande körs på den lokala integrationsdatorn. För att fungera som förväntat kräver filskapande följande krav:
    • Java Runtime (JRE) version 11 från en JRE-provider, till exempel Microsoft OpenJDK 11 eller Eclipse Temurin 11. Kontrollera att JAVA_HOME-systemmiljövariabeln är inställd på JDK-mappen (inte bara JRE-mappen) du kan också behöva lägga till mappen bin i systemets PATH-miljövariabel.

    Kommentar

    Det kan vara nödvändigt att justera Java-inställningarna om minnesfel uppstår, enligt beskrivningen i dokumentationen för Parquet-format .

Kommentar

Om du kör i myndighetsmolnet läser du Anslut till myndighetsmoln.

Konfigurera en lokalt installerad integrationskörning

Använd följande procedurer för att skapa och konfigurera en lokalt installerad integrationskörning.

Skapa en lokalt installerad IR via Azure PowerShell

  1. Du kan använda Azure PowerShell för den här uppgiften. Här är ett exempel:

    Set-AzDataFactoryV2IntegrationRuntime -ResourceGroupName $resourceGroupName -DataFactoryName $dataFactoryName -Name $selfHostedIntegrationRuntimeName -Type SelfHosted -Description "selfhosted IR description"

  2. Ladda ned och installera den lokalt installerade integrationskörningen på en lokal dator.

  3. Hämta autentiseringsnyckeln och registrera den lokala integrationskörningen med nyckeln. Här är ett PowerShell-exempel:

    
Get-AzDataFactoryV2IntegrationRuntimeKey -ResourceGroupName $resourceGroupName -DataFactoryName $dataFactoryName -Name $selfHostedIntegrationRuntimeName

Kommentar

Kör PowerShell-kommandot i Azure Government. Mer information finns i Ansluta till Azure Government med PowerShell.

Skapa en lokalt installerad IR via användargränssnittet

Använd följande steg för att skapa en lokalt installerad IR med hjälp av Azure Data Factory eller Azure Synapse-användargränssnittet.

  1. På startsidan i Användargränssnittet för Azure Data Factory väljer du fliken Hantera i det vänstra fönstret.

    Knappen Hantera startsida

  2. Välj Integreringskörningar i det vänstra fönstret och välj sedan +Nytt.

    Skapa Integration Runtime

  3. På sidan Installation av integrationskörning väljer du Azure, Lokalt värd och väljer sedan Fortsätt.

  4. På följande sida väljer du Lokalt värd för att skapa en lokalt installerad IR och väljer sedan Fortsätt. Skapa en IR med egen värd

Konfigurera en lokalt installerad IR via användargränssnittet

  1. Ange ett namn för din IR och välj Skapa.

  2. På sidan Installation av integrationskörning väljer du länken under Alternativ 1 för att öppna expresskonfigurationen på datorn. Eller följ stegen under Alternativ 2 för att konfigurera manuellt. Följande instruktioner baseras på manuell konfiguration:

    Installation av Integration Runtime

    1. Kopiera och klistra in autentiseringsnyckeln. Välj Ladda ned och installera integrationskörning.

    2. Ladda ned Integration Runtime med egen värd på en lokal Windows-dator. Kör installationsprogrammet.

    3. På sidan Registrera Integration Runtime (lokal installation) klistrar du in nyckeln som du sparade tidigare och väljer Registrera.

      Registrera Integration Runtime

    4. På sidan Ny Integration Runtime (lokal installation) Nod väljer du Slutför.

  3. När den lokalt installerade integrationskörningen har registrerats visas följande fönster:

    Lyckad registrering

Konfigurera en lokalt installerad IR på en virtuell Azure-dator via en Azure Resource Manager-mall

Du kan automatisera installation av lokalt installerad IR på en virtuell Azure-dator med hjälp av IR-mallen Skapa egen värd. Mallen är ett enkelt sätt att ha en fullt fungerande lokalt installerad IR i ett virtuellt Azure-nätverk. IR har funktioner för hög tillgänglighet och skalbarhet, så länge du anger antalet noder till 2 eller högre.

Konfigurera en befintlig lokalt installerad IR via lokal PowerShell

Du kan använda en kommandorad för att konfigurera eller hantera en befintlig lokalt installerad IR. Den här användningen kan särskilt hjälpa till att automatisera installationen och registreringen av lokalt installerade IR-noder.

Dmgcmd.exe ingår i installationsprogrammet med egen värd. Den finns vanligtvis i mappen C:\Program\Microsoft Integration Runtime\5.0\Shared\. Det här programmet stöder olika parametrar och kan anropas via en kommandorad med hjälp av batchskript för automatisering.

Använd programmet på följande sätt:

dmgcmd ACTION args...

Här följer information om programmets åtgärder och argument:

ÅTGÄRD args beskrivning
-rn,
-RegisterNewNode		 "<AuthenticationKey>" ["<NodeName>"] Registrera en lokalt installerad integrationskörningsnod med den angivna autentiseringsnyckeln och nodnamnet.
-era,
-EnableRemoteAccess		 "<port>" ["<thumbprint>"] Aktivera fjärråtkomst på den aktuella noden för att konfigurera ett kluster med hög tillgänglighet. Eller aktivera inställningen av autentiseringsuppgifter direkt mot den lokalt installerade IR:en utan att gå igenom en Azure Data Factory- eller Azure Synapse-arbetsyta. Du gör det senare med hjälp av cmdleten New-AzDataFactoryV2LinkedServiceEncryptedCredEntial från en fjärrdator i samma nätverk.
-erac,
-EnableRemoteAccessInContainer		 "<port>" ["<thumbprint>"] Aktivera fjärråtkomst till den aktuella noden när noden körs i en container.
-dra,
-DisableRemoteAccess		 Inaktivera fjärråtkomst till den aktuella noden. Fjärråtkomst krävs för installation av flera nod. PowerShell-cmdleten New-AzDataFactoryV2LinkedServiceEncryptedCredential fungerar fortfarande även när fjärråtkomst är inaktiverat. Det här beteendet gäller så länge cmdleten körs på samma dator som den lokalt installerade IR-noden.
-k,
-Key		 "<AuthenticationKey>" Skriv över eller uppdatera den tidigare autentiseringsnyckeln. Var försiktig med den här åtgärden. Din tidigare lokalt installerade IR-nod kan gå offline om nyckeln är av en ny integrationskörning.
-gbf,
-GenerateBackupFile		 "<filePath>" "<password>" Generera en säkerhetskopieringsfil för den aktuella noden. Säkerhetskopieringsfilen innehåller nodnyckeln och autentiseringsuppgifterna för datalager.
-ibf,
-ImportBackupFile		 "<filePath>" "<password>" Återställ noden från en säkerhetskopia.
-r,
-Restart		 Starta om värdtjänsten för lokalt installerad integrationskörning.
-s,
-Start		 Starta värdtjänsten för lokalt installerad integrationskörning.
-t,
-Stop		 Stoppa värdtjänsten för lokalt installerad integrationskörning.
-sus,
-StartUpgradeService		 Starta uppgraderingstjänsten för lokalt installerad integrationskörning.
-tus,
-StopUpgradeService		 Stoppa uppgraderingstjänsten för lokalt installerad integrationskörning.
-tonau,
-TurnOnAutoUpdate		 Aktivera automatisk uppdatering av lokalt installerad integrationskörning. Det här kommandot är endast för Azure Data Factory V1.
-toffau,
-TurnOffAutoUpdate		 Inaktivera automatisk uppdatering av lokalt installerad integrationskörning. Det här kommandot är endast för Azure Data Factory V1.
-ssa,
-SwitchServiceAccount		 "<domain\user>" ["<password>"] Ställ in DIAHostService så att det körs som ett nytt konto. Använd det tomma lösenordet för systemkonton och virtuella konton.
-elma,
-EnableLocalMachineAccess		 Aktivera lokal datoråtkomst (localhost, privat IP) på den aktuella lokala IR-noden. I ett scenario med hög IR-tillgänglighet med egen värd måste åtgärden anropas på varje lokalt installerad IR-nod.
-dlma,
-DisableLocalMachineAccess		 Inaktivera lokal datoråtkomst (localhost, privat IP) på den aktuella lokala IR-noden. I ett scenario med hög IR-tillgänglighet med egen värd måste åtgärden anropas på varje lokalt installerad IR-nod.
-DisableLocalFolderPathValidation Inaktivera säkerhetsverifiering för att aktivera åtkomst till filsystemet på den lokala datorn.
-EnableLocalFolderPathValidation Aktivera säkerhetsverifiering för att inaktivera åtkomst till filsystemet på den lokala datorn.
-eesp,
-EnableExecuteSsisPackage		 Aktivera SSIS-paketkörning på lokalt installerad IR-nod.
-desp,
-DisableExecuteSsisPackage		 Inaktivera SSIS-paketkörning på lokalt installerad IR-nod.
-gesp,
-GetExecuteSsisPackage		 Hämta värdet om alternativet ExecuteSsisPackage är aktiverat på en lokalt installerad IR-nod.
Om det returnerade värdet är sant aktiveras ExecuteSSISPackage. Om det returnerade värdet är falskt eller null inaktiveras ExecuteSSISPackage.

Installera och registrera en lokalt installerad IR från Microsoft Download Center

  1. Gå till nedladdningssidan för Microsoft Integration Runtime.

  2. Välj Ladda ned, välj 64-bitarsversionen och välj Nästa. 32-bitarsversionen stöds inte.

  3. Kör MSI-filen direkt eller spara den på hårddisken och kör den.

  4. I välkomstfönstret väljer du ett språk och väljer Nästa.

  5. Godkänn Licensvillkoren för Microsoft-programvara och välj Nästa.

  6. Välj mapp för att installera den lokalt installerade integrationskörningen och välj Nästa.

  7. På sidan Klar att installera väljer du Installera.

  8. Välj Slutför för att slutföra installationen.

  9. Hämta autentiseringsnyckeln med hjälp av PowerShell. Här är ett PowerShell-exempel för att hämta autentiseringsnyckeln:

    Get-AzDataFactoryV2IntegrationRuntimeKey -ResourceGroupName $resourceGroupName -DataFactoryName $dataFactoryName -Name $selfHostedIntegrationRuntimeName

  10. I fönstret Registrera Integration Runtime (lokal installation) i Microsoft Integration Runtime Configuration Manager som körs på datorn utför du följande steg:

    1. Klistra in autentiseringsnyckeln i textområdet.

    2. Du kan också välja Visa autentiseringsnyckel för att se nyckeltexten.

    3. Välj Registrera.

Kommentar

Viktig information finns på samma nedladdningssida för Microsoft Integration Runtime.

Tjänstkonto för lokalt installerad integrationskörning

Standardloggen på tjänstkontot för den lokalt installerade integrationskörningen är NT SERVICE\DIAHostService. Du kan se den i Services –> Integration Runtime Service –> Egenskaper –> Logga in.

Tjänstkonto för lokalt installerad integrationskörning

Kontrollera att kontot har behörigheten Logga in som en tjänst. Annars kan inte lokalt installerad integrationskörning startas. Du kan kontrollera behörigheten i Lokal säkerhetsprincip –> Säkerhetsinställningar –> Lokala principer –> Tilldelning av användarrättigheter –> Logga in som en tjänst

Skärmbild av lokal säkerhetsprincip – Tilldelning av användarrättigheter

Skärmbild av inloggning som en tilldelning av användarrättigheter för tjänsten

Ikoner och meddelanden i meddelandefältet

Om du flyttar markören över ikonen eller meddelandet i meddelandefältet kan du se information om tillståndet för den lokalt installerade integrationskörningen.

Meddelanden i meddelandefältet

Hög tillgänglighet och skalbarhet

Du kan associera en lokalt installerad integrationskörning med flera lokala datorer eller virtuella datorer i Azure. Dessa datorer kallas noder. Du kan ha upp till fyra noder associerade med en lokalt installerad integrationskörning. Fördelarna med att ha flera noder på lokala datorer som har en gateway installerad för en logisk gateway är:

  • Högre tillgänglighet för den lokalt installerade integrationskörningen så att den inte längre är den enda felpunkten i din stordatalösning eller molndataintegrering. Den här tillgängligheten säkerställer kontinuitet när du använder upp till fyra noder.
  • Bättre prestanda och dataflöde under dataflytt mellan lokala datalager och molndatalager. Få mer information om prestandajämförelser.

Du kan associera flera noder genom att installera den lokalt installerade integrationskörningsprogramvaran från Download Center. Registrera den sedan med någon av de autentiseringsnycklar som hämtades från cmdleten New-AzDataFactoryV2IntegrationRuntimeKey enligt beskrivningen i självstudien.

Kommentar

Du behöver inte skapa en ny lokalt installerad integrationskörning för att associera varje nod. Du kan installera den lokalt installerade integrationskörningen på en annan dator och registrera den med samma autentiseringsnyckel.

Kommentar

Innan du lägger till en annan nod för hög tillgänglighet och skalbarhet kontrollerar du att alternativet Fjärråtkomst till intranät är aktiverat på den första noden. Det gör du genom att välja Inställningar för Microsoft Integration Runtime Configuration Manager>>Fjärråtkomst till intranät.

Skalningsöverväganden

Skala ut

När processoranvändningen är hög och det tillgängliga minnet är lågt på den lokalt installerade IR:n lägger du till en ny nod för att skala ut belastningen mellan datorer. Om aktiviteter misslyckas på grund av tidsgränsen eller om den lokalt installerade IR-noden är offline, hjälper det om du lägger till en nod i gatewayen. Utför följande steg för att lägga till en nod:

  1. Ladda ned SHIR-installationen från Azure Data Factory-portalen.
  2. Kör installationsprogrammet på den nod som du vill lägga till i klustret.
  3. Under installationen väljer du alternativet att ansluta till en befintlig integrationskörning och anger autentiseringsnyckeln från den befintliga SHIR:n för att länka den nya noden till det befintliga SHIR-klustret.

Skala upp

När processorn och det tillgängliga RAM-minnet inte används väl, men körningen av samtidiga jobb når en nods gränser, skalar du upp genom att öka antalet samtidiga jobb som en nod kan köra. Du kanske också vill skala upp när aktiviteter överskrider tidsgränsen eftersom den lokalt installerade IR:en är överbelastad. Som du ser i följande bild kan du öka den maximala kapaciteten för en nod:

Öka antalet samtidiga jobb som kan köras på en nod

TLS/SSL-certifikatkrav

Om du vill aktivera fjärråtkomst från intranät med TLS/SSL-certifikat (Avancerat) för att skydda kommunikationen mellan integrationskörningsnoder kan du följa stegen i Aktivera fjärråtkomst från intranät med TLS/SSL-certifikat.

Kommentar

Det här certifikatet används:

  • För att kryptera portar på en lokalt installerad IR-nod.
  • För nod-till-nod-kommunikation för tillståndssynkronisering, vilket inkluderar synkronisering av autentiseringsuppgifter för länkade tjänster mellan noder.
  • När en PowerShell-cmdlet används för autentiseringsinställningar för länkad tjänst inifrån ett lokalt nätverk.

Vi rekommenderar att du använder det här certifikatet om din privata nätverksmiljö inte är säker eller om du vill skydda kommunikationen mellan noder i ditt privata nätverk.

Dataflytt under överföring från en lokalt installerad IR till andra datalager sker alltid i en krypterad kanal, oavsett om certifikatet har angetts eller inte.

Synkronisering av autentiseringsuppgifter

Om du inte lagrar autentiseringsuppgifter eller hemliga värden i ett Azure Key Vault lagras autentiseringsuppgifterna eller de hemliga värdena på de datorer där din lokala integrationskörning finns. Varje nod har en kopia av autentiseringsuppgifter med en viss version. För att alla noder ska fungera tillsammans bör versionsnumret vara detsamma för alla noder.

Att tänka på gällande proxyservrar

Om företagsnätverksmiljön använder en proxyserver för att komma åt Internet konfigurerar du den lokalt installerade integrationskörningen så att den använder lämpliga proxyinställningar. Du kan ange proxyn under den inledande registreringsfasen.

Ange proxyn

När den konfigureras använder den lokalt installerade integrationskörningen proxyservern för att ansluta till molntjänstens källa och mål (som använder HTTP- eller HTTPS-protokollet). Det är därför du väljer Ändra länk under den första installationen.

Ange proxyn

Det finns tre konfigurationsalternativ:

  • Använd inte proxy: Den lokalt installerade integrationskörningen använder inte uttryckligen någon proxy för att ansluta till molntjänster.
  • Använd systemproxy: Den lokalt installerade integrationskörningen använder proxyinställningen som konfigureras i diahost.exe.config och diawp.exe.config. Om dessa filer inte anger någon proxykonfiguration ansluter den lokalt installerade integrationskörningen direkt till molntjänsten utan att gå via en proxy.
  • Använd anpassad proxy: Konfigurera HTTP-proxyinställningen så att den används för den lokalt installerade integrationskörningen i stället för att använda konfigurationer i diahost.exe.config och diawp.exe.config. Adress- och portvärden krävs. Värden för användarnamn och lösenord är valfria, beroende på proxyns autentiseringsinställning. Alla inställningar krypteras med Windows DPAPI på den lokalt installerade integrationskörningen och lagras lokalt på datorn.

Integration Runtime-värdtjänsten startas om automatiskt när du har sparat de uppdaterade proxyinställningarna.

När du har registrerat den lokalt installerade integrationskörningen använder du Microsoft Integration Runtime Configuration Manager om du vill visa eller uppdatera proxyinställningar.

  1. Öppna Microsoft Integration Runtime Configuration Manager.
  2. Välj fliken Inställningar.
  3. Under HTTP-proxy väljer du länken Ändra för att öppna dialogrutan Ange HTTP-proxy .
  4. Välj Nästa. Du ser sedan en varning som ber om din behörighet att spara proxyinställningen och starta om integration Runtime-värdtjänsten.

Du kan använda configuration manager-verktyget för att visa och uppdatera HTTP-proxyn.

Visa och uppdatera proxyn

Kommentar

Om du konfigurerar en proxyserver med NTLM-autentisering körs integration runtime-värdtjänsten under domänkontot. Om du senare ändrar lösenordet för domänkontot ska du komma ihåg att uppdatera konfigurationsinställningarna för tjänsten och starta om tjänsten. På grund av detta krav rekommenderar vi att du kommer åt proxyservern med hjälp av ett dedikerat domänkonto som inte kräver att du uppdaterar lösenordet ofta.

Konfigurera proxyserverinställningar

Om du väljer alternativet Använd systemproxy för HTTP-proxyn använder den lokalt installerade integrationskörningen proxyinställningarna i diahost.exe.config och diawp.exe.config. När dessa filer inte anger någon proxy ansluter den lokalt installerade integrationskörningen direkt till molntjänsten utan att gå via en proxy. Följande procedur innehåller instruktioner för att uppdatera filen diahost.exe.config:

  1. I Utforskaren gör du en säker kopia av C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config som en säkerhetskopia av den ursprungliga filen.

  2. Öppna Anteckningar som körs som administratör.

  3. Öppna textfilen C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config i Anteckningar.

  4. Hitta standardtaggen system.net enligt följande kod:

    <system.net>
    <defaultProxy useDefaultCredentials="true" />
</system.net>

    Du kan sedan lägga till information om proxyservern enligt följande exempel:

    <system.net>
    <defaultProxy enabled="true">
          <proxy bypassonlocal="true" proxyaddress="http://proxy.domain.org:8888/" />
    </defaultProxy>
</system.net>

    Med proxytaggen kan ytterligare egenskaper ange nödvändiga inställningar som scriptLocation. Se <proxyelement> (nätverksinställningar) för syntax.

    <proxy autoDetect="true|false|unspecified" bypassonlocal="true|false|unspecified" proxyaddress="uriString" scriptLocation="uriString" usesystemdefault="true|false|unspecified "/>

  5. Spara konfigurationsfilen på den ursprungliga platsen. Starta sedan om den lokalt installerade integrationskörningsvärdtjänsten, som hämtar ändringarna.

    Om du vill starta om tjänsten använder du tjänstens applet från Kontrollpanelen. Eller från Integration Runtime Configuration Manager väljer du knappen Stoppa tjänst och sedan Starta tjänst.

    Om tjänsten inte startar har du förmodligen lagt till felaktig XML-taggsyntax i programkonfigurationsfilen som du redigerade.

Viktigt!

Glöm inte att uppdatera både diahost.exe.config och diawp.exe.config.

Du måste också se till att Microsoft Azure finns med i företagets lista över tillåtna. Du kan ladda ned listan över giltiga Azure IP-adresser. IP-intervall för varje moln, uppdelade efter region och efter taggade tjänster i molnet är nu tillgängliga på MS Download:

Konfigurera proxyserverinställningar när du använder en privat slutpunkt

Om företagets nätverksvalvering omfattar användning av privata slutpunkter och av säkerhetsskäl, och företagets princip inte tillåter en direkt internetanslutning från den virtuella datorn som är värd för lokalt installerad integrationskörning till Azure Data Factory-tjänstens URL, måste du tillåta att ADF-tjänstens URL kringgås för fullständig anslutning. Följande procedur innehåller instruktioner för att uppdatera filen diahost.exe.config. Du bör också upprepa de här stegen för filen diawp.exe.config.

  1. I Utforskaren gör du en säker kopia av C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config som en säkerhetskopia av den ursprungliga filen.

  2. Öppna Anteckningar som körs som administratör.

  3. Öppna C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config i Anteckningar.

  4. Hitta standardtaggen system.net som visas här:

    <system.net>
    <defaultProxy useDefaultCredentials="true" />
</system.net>

    Du kan sedan lägga till information om bypasslist som du ser i följande exempel:

    <system.net>
  <defaultProxy>
      <bypasslist>
          <add address = "[adfresourcename].[adfresourcelocation].datafactory.azure.net" />
      </bypasslist>
      <proxy 
      usesystemdefault="True"
      proxyaddress="http://proxy.domain.org:8888/"
      bypassonlocal="True"
      />
  </defaultProxy>
</system.net>

Om du ser felmeddelanden som följande är den troliga orsaken felaktig konfiguration av brandväggen eller proxyservern. En sådan konfiguration förhindrar att den lokalt installerade integrationskörningen ansluter till Data Factory- eller Synapse-pipelines för att autentisera sig själv. Se föregående avsnitt för att säkerställa att brandväggen och proxyservern är korrekt konfigurerade.

  • När du försöker registrera den lokalt installerade integrationskörningen får du följande felmeddelande: "Det gick inte att registrera den här Integration Runtime-noden! Bekräfta att autentiseringsnyckeln är giltig och att värdtjänsten för integrationstjänsten körs på den här datorn."

  • När du öppnar Integration Runtime Configuration Manager visas statusen Frånkopplad eller Ansluta. När du visar Windows-händelseloggar visas felmeddelanden som den här under Loggboken> Application and Services Logs>Microsoft Integration Runtime:

    Unable to connect to the remote server
A component of Integration Runtime has become unresponsive and restarts automatically. Component name: Integration Runtime (self-hosted).

Aktivera fjärråtkomst från ett intranät

Om du använder PowerShell för att kryptera autentiseringsuppgifter från en annan nätverksbaserad dator än där du installerade integrationskörningen med egen värd kan du aktivera alternativet Fjärråtkomst från intranät . Om du kör PowerShell för att kryptera autentiseringsuppgifter på den dator där du installerade integrationskörningen med egen värd kan du inte aktivera fjärråtkomst från intranätet.

Aktivera fjärråtkomst från intranätet innan du lägger till en annan nod för hög tillgänglighet och skalbarhet.

När du kör installationsprogrammet för lokalt installerad integrationskörning version 3.3 eller senare inaktiverar som standard installationsprogrammet för lokalt installerad integrationskörning fjärråtkomst från intranätet på den lokalt installerade integrationskörningsdatorn.

När du använder en brandvägg från en partner eller andra kan du manuellt öppna port 8060 eller den användarkonfigurerade porten. Om du har ett brandväggsproblem när du konfigurerar integrationskörningen med egen värd använder du följande kommando för att installera den lokalt installerade integrationskörningen utan att konfigurera brandväggen:

msiexec /q /i IntegrationRuntime.msi NOFIREWALL=1

Om du väljer att inte öppna port 8060 på den lokalt installerade integrationskörningsdatorn använder du andra mekanismer än programmet Ange autentiseringsuppgifter för att konfigurera autentiseringsuppgifter för datalager. Du kan till exempel använda PowerShell-cmdleten New-AzDataFactoryV2LinkedServiceEncryptCredential .

Portar och brandväggar

Det finns två brandväggar att tänka på:

  • Företagsbrandväggen som körs på organisationens centrala router
  • Windows-brandväggen som är konfigurerad som en daemon på den lokala datorn där den lokalt installerade integrationskörningen är installerad

Brandväggarna

På företagets brandväggsnivå måste du konfigurera följande domäner och utgående portar:

Domännamn Utgående portar beskrivning
Offentligt moln: *.servicebus.windows.net
Azure Government: *.servicebus.usgovcloudapi.net
Kina: *.servicebus.chinacloudapi.cn		 443 Krävs av den lokalt installerade integrationskörningen för interaktiv redigering. Krävs inte om fristående interaktiv redigering är aktiverad.
Offentligt moln: {datafactory}.{region}.datafactory.azure.net
eller *.frontend.clouddatahub.net
Azure Government: {datafactory}.{region}.datafactory.azure.us
Kina: {datafactory}.{region}.datafactory.azure.cn		 443 Krävs av den lokalt installerade integrationskörningen för att ansluta till Data Factory-tjänsten.
För nyskapad Data Factory i det offentliga molnet hittar du det fullständigt kvalificerade domännamnet (FQDN) från din lokalt installerad Integration Runtime-nyckel, som är i formatet {data factory}. {region}.datafactory.azure.net. Om du inte ser FQDN i din lokala integrationsnyckel använder du *.frontend.clouddatahub.net i stället för gamla datafabriker och valfri version av Azure Synapse Analytics.
download.microsoft.com 443 Krävs av den lokalt installerade integrationskörningen för nedladdning av uppdateringarna. Om du har inaktiverat autouppdate kan du hoppa över att konfigurera den här domänen.
Key Vault-URL 443 Krävs av Azure Key Vault om du lagrar autentiseringsuppgifterna i Key Vault.

På Windows-brandväggsnivå eller datornivå är dessa utgående portar normalt aktiverade. Om de inte är det kan du konfigurera domänerna och portarna på en lokalt installerad integrationskörningsdator.

Kommentar

Eftersom Azure Relay för närvarande inte stöder tjänsttagg måste du använda tjänsttaggen AzureCloud eller Internet i NSG-regler för kommunikation till Azure Relay. För kommunikationen till Azure Data Factory- och Synapse-arbetsytor kan du använda tjänsttaggen DataFactoryManagement i NSG-regelkonfigurationen.

Baserat på källan och mottagare kan du behöva tillåta ytterligare domäner och utgående portar i företagets brandvägg eller Windows-brandväggen.

Domännamn Utgående portar beskrivning
*.core.windows.net 443 Används av den lokalt installerade integrationskörningen för att ansluta till Azure Storage-kontot när du använder den mellanlagrade kopieringsfunktionen.
*.database.windows.net 1433 Krävs endast när du kopierar från eller till Azure SQL Database eller Azure Synapse Analytics och på annat sätt är valfritt. Använd funktionen för stegvis kopiering för att kopiera data till SQL Database eller Azure Synapse Analytics utan att öppna port 1433.
*.azuredatalakestore.net
login.microsoftonline.com/<tenant>/oauth2/token		 443 Krävs endast när du kopierar från eller till Azure Data Lake Store och annat valfritt.

För vissa molndatabaser, till exempel Azure SQL Database och Azure Data Lake, kan du behöva tillåta IP-adresser för lokalt installerade integrationskörningsdatorer i brandväggskonfigurationen.

Kommentar

Det är inte rätt att installera både Integration Runtime och Power BI-gatewayen på samma dator, eftersom främst Integration Runtime använder portnummer 443, vilket också är en av de viktigaste portarna som används av Power BI-gatewayen.

Fristående interaktiv redigering (förhandsversion)

För att kunna utföra interaktiva redigeringsåtgärder som förhandsversion av data och anslutningstestning kräver den lokalt installerade integrationskörningen en anslutning till Azure Relay. Om anslutningen inte upprättas finns det två möjliga lösningar för att säkerställa oavbrutna funktioner. Det första alternativet är att lägga till Azure Relay-slutpunkterna i brandväggens tillåtna lista Hämta URL för Azure Relay. Du kan också aktivera fristående interaktiv redigering.

Kommentar

Om den lokalt installerade integrationskörningen inte kan upprätta en anslutning till Azure Relay markeras dess status som "begränsad".

Skärmbild av fristående interaktiv redigering.

Kommentar

Medan fristående interaktiv redigering är aktiverad dirigeras all interaktiv redigeringstrafik uteslutande via den här funktionen, vilket kringgår Azure Relay. Trafiken omdirigeras bara tillbaka till Azure Relay när du väljer att inaktivera den här funktionen.

Kommentar

Både "Hämta IP" och "Skicka logg" stöds inte när fristående interaktiv redigering är aktiverad.

Hämta URL för Azure Relay

En nödvändig domän och port som måste placeras i listan över tillåtna brandväggar är för kommunikationen till Azure Relay. Den lokalt installerade integrationskörningen använder den för interaktiv redigering, till exempel testanslutning, bläddra i mapplista och tabelllista, hämta schema och förhandsgranskningsdata. Om du inte vill tillåta .servicebus.windows.net och vill ha mer specifika URL:er kan du se alla FQDN:er som krävs av din lokala integrationskörning från tjänstportalen.

Hämta URL för Azure Relay via användargränssnittet:

Följ de här stegen:

  1. Gå till tjänstportalen och välj din lokala integrationskörning.

  2. På sidan Redigera väljer du Noder.

  3. Välj Visa tjänst-URL:er för att hämta alla fullständiga domännamn.

    Url:er för Azure Relay

  4. Du kan lägga till dessa FQDN i listan över tillåtna brandväggsregler.

Kommentar

Mer information om Azure Relay-anslutningsprotokollet finns i Azure Relay Hybrid Connections Protocol.

Hämta URL för Azure Relay via skript:

# The documentation of Synapse self hosted integration runtime (SHIR) mentions that the SHIR requires access to the Azure Service Bus IP addresses
# https://learn.microsoft.com/en-us/azure/data-factory/create-self-hosted-integration-runtime
# It is a requirement to use a wildcard (*.servicebus.windows.net) in your firewalls.
# While this is the easiest way to clear the firewall, it also opens the firewall to all Azure Service Bus IP addresses, including malicious_actor.servicebus.windows.net.
# This might be restricted by your security policies.
# This script resolves the Azure Service Bus IP addresses used by an integration runtime and adds them to the network security group (NSG) rule for the Synapse self-hosted integration runtime (SHIR).
# As the mapping of IP addresses to Domain Names might change, we recommend to run at least once a day to keep the NSG up to date.
# An alternative to running this script is to use the "Self-contained interactive authoring" feature of the self hosted integration runtime.

# Prerequisites:
# - PowerShell installed
# - Azure CLI (az) installed and logged in (https://learn.microsoft.com/en-us/cli/azure/)
# - signed in user needs rights to modify NSG (e.g. Network contributor) and to read status of the SHIR (e.g. reader), plus reader on the subscription

param (
    [string]$synapseRresourceGroupName = "synapse_test",
    [string]$nsgResourceGroupName = "adf_shir_rg",
    [string]$synapseWorkspaceName = "synapse-test-jugi2",
    [string]$integrationRuntimeName = "IntegrationRuntime2",
    [string]$networkSecurityGroupName = "jugis-shir-nsg",
    [string]$securityRuleName = "AllowSynapseServiceBusIPs",
    [int]$priority = 100
)

# Check if the user is already logged in
$azAccount = az account show 2>$null

if (-not $azAccount) {
    # Run az login with managed identity if not logged in
    az login --identity
}

# Retrieve the URLs of the connections from the Synapse self-hosted integration runtime
$urls = az synapse integration-runtime get-status `
    --resource-group $synapseResourceGroupName `
    --workspace-name $synapseWorkspaceName `
    --name $integrationRuntimeName `
    --query "properties.serviceUrls" -o tsv

# Initialize an empty array to hold the IP addresses
$ipAddresses = @()

# Iterate over the URLs to resolve and collect the IP addresses
# The proper DNS resolution might only work within Azure, not locally
foreach ($url in $urls) {
    Write-Output "Processing URL: $url"
    $ip = [System.Net.Dns]::GetHostAddresses($url) | Where-Object { $_.AddressFamily -eq 'InterNetwork' } | Select-Object -ExpandProperty IPAddressToString
    if ($ip) {
        $ipAddresses += $ip
    }
}

# Remove duplicate IP addresses from the array
$ipAddresses = $ipAddresses | Sort-Object -Unique

# Convert the array of IP addresses to a space-separated string
$ipAddressesString = $ipAddresses -join ' '

# Create or update the network security group rule to allow outbound traffic for the collected IP addresses
# Using Invoke-Expression to handle the command string
$az_cmd = "az network nsg rule create --resource-group $nsgResourceGroupName --nsg-name $networkSecurityGroupName --name $securityRuleName --priority $priority --destination-address-prefixes $ipAddressesString --destination-port-ranges '443' --direction Outbound --access Allow --protocol '*' --description 'Allow outbound access to Synapse servicebus IPs'"
Invoke-Expression $az_cmd

Kopiera data från en källa till en mottagare

Se till att du aktiverar brandväggsregler på företagets brandvägg, Windows-brandväggen för den lokalt installerade integrationskörningsdatorn och själva datalagret. Genom att aktivera dessa regler kan den lokalt installerade integrationskörningen ansluta till både källa och mottagare. Aktivera regler för varje datalager som ingår i kopieringsåtgärden.

Om du till exempel vill kopiera från ett lokalt datalager till en SQL Database-mottagare eller en Azure Synapse Analytics-mottagare utför du följande steg:

  1. Tillåt utgående TCP-kommunikation på port 1433 för både Windows-brandväggen och företagets brandvägg.
  2. Konfigurera brandväggsinställningarna för SQL Database för att lägga till IP-adressen för den lokalt installerade integrationskörningsdatorn i listan över tillåtna IP-adresser.

Kommentar

Om brandväggen inte tillåter utgående port 1433 kan den lokalt installerade integrationskörningen inte komma åt SQL-databasen direkt. I det här fallet kan du använda en mellanlagrad kopia till SQL Database och Azure Synapse Analytics. I det här scenariot behöver du bara HTTPS (port 443) för dataflytten.

Om alla datakällor och mottagare och lokalt installerad integrationskörning finns i en lokal miljö kommer kopierade data inte att gå till molnet utan strikt ligga kvar lokalt.

Arkiv för autentiseringsuppgifter

Det finns två sätt att lagra autentiseringsuppgifterna när du använder lokalt installerad integrationskörning:

  1. Använd Azure Key Vault.

Det här är det rekommenderade sättet att lagra dina autentiseringsuppgifter i Azure. Den lokalt installerade integrationskörningen kan direkt hämta autentiseringsuppgifterna från Azure Key Vault, vilket kan undvika vissa potentiella säkerhetsproblem eller eventuella problem med synkronisering av autentiseringsuppgifter mellan lokalt installerade integrationskörningsnoder. 2. Lagra autentiseringsuppgifter lokalt.

Autentiseringsuppgifterna skickas till datorn för din lokala integrationskörning och krypteras. När din lokala integrationskörning återställs från krasch kan du antingen återställa autentiseringsuppgifter från den som du säkerhetskopierade före eller redigera den länkade tjänsten och låta autentiseringsuppgifterna skickas till lokalt installerad integrationskörning igen. Annars fungerar inte pipelinen på grund av bristen på autentiseringsuppgifter när den körs via lokalt installerad integrationskörning.

Kommentar

Om du föredrar att lagra autentiseringsuppgifterna lokalt måste du placera domänen för interaktiv redigering i listan över tillåtna autentiseringsuppgifter i brandväggen och öppna porten. Den här kanalen är också till för den lokalt installerade integrationskörningen för att hämta autentiseringsuppgifterna. Den domän och port som behövs för interaktiv redigering finns i Portar och brandväggar

Metodtips för installation

Du kan installera den lokalt installerade integrationskörningen genom att ladda ned ett konfigurationspaket för hanterad identitet från Microsoft Download Center. Stegvisa instruktioner finns i artikeln Flytta data mellan lokalt och molnet .

  • Konfigurera en energiplan på värddatorn för den lokalt installerade integrationskörningen så att datorn inte viloläge. Om värddatorn försätts i viloläge går den lokalt installerade integrationskörningen offline.
  • Säkerhetskopiera regelbundet de autentiseringsuppgifter som är associerade med den lokala integrationskörningen.
  • Information om hur du automatiserar installationsåtgärder för lokalt installerad IR finns i Konfigurera en befintlig lokalt installerad IR via PowerShell.

Viktigt!

När du installerar en lokalt installerad integrationskörning bör du överväga att följa

  • Håll den nära datakällan men inte nödvändigtvis på samma dator
  • Installera den inte på samma dator som Power BI-gatewayen
  • Endast Windows Server (FIPS-kompatibla krypteringsservrar kan orsaka att jobb misslyckas)
  • Dela mellan flera datakällor
  • Dela över flera datafabriker

Relaterat innehåll

Stegvisa instruktioner finns i Självstudie: Kopiera lokala data till molnet.