Skapa och konfigurera lokalt installerad integrationskörning
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:
En datautvecklare skapar först en lokalt installerad integrationskörning i en Azure-datafabrik eller Synapse-arbetsyta med hjälp av Azure-portalen 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.
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.
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.
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 8.1
- Windows 10
- Windows 11
- Windows Server 2012
- Windows Server 2012 R2
- 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 myndighetsmoln granskar du Anslut till myndighetsmolnet.
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
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"Ladda ned och installera den lokalt installerade integrationskörningen på en lokal dator.
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. Se Anslut 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.
På startsidan i Användargränssnittet för Azure Data Factory väljer du fliken Hantera i det vänstra fönstret.
Välj Integreringskörningar i det vänstra fönstret och välj sedan +Nytt.
På sidan Installation av integrationskörning väljer du Azure, Lokalt värd och väljer sedan Fortsätt.
På följande sida väljer du Lokalt värd för att skapa en lokalt installerad IR och väljer sedan Fortsätt.
Konfigurera en lokalt installerad IR via användargränssnittet
Ange ett namn för din IR och välj Skapa.
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:
Kopiera och klistra in autentiseringsnyckeln. Välj Ladda ned och installera integrationskörning.
Ladda ned Integration Runtime med egen värd på en lokal Windows-dator. Kör installationsprogrammet.
På sidan Registrera Integration Runtime (lokal installation) klistrar du in nyckeln som du sparade tidigare och väljer Registrera.
På sidan Ny Integration Runtime (lokal installation) Nod väljer du Slutför.
När den lokalt installerade integrationskörningen har registrerats visas följande fönster:
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
Gå till nedladdningssidan för Microsoft Integration Runtime.
Välj Ladda ned, välj 64-bitarsversionen och välj Nästa. 32-bitarsversionen stöds inte.
Kör MSI-filen direkt eller spara den på hårddisken och kör den.
I välkomstfönstret väljer du ett språk och väljer Nästa.
Godkänn Licensvillkoren för Microsoft-programvara och välj Nästa.
Välj mapp för att installera den lokalt installerade integrationskörningen och välj Nästa.
På sidan Klar att installera väljer du Installera.
Välj Slutför för att slutföra installationen.
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 $selfHostedIntegrationRuntimeNameI fönstret Registrera Integration Runtime (lokal installation) i Microsoft Integration Runtime Configuration Manager som körs på datorn utför du följande steg:
Klistra in autentiseringsnyckeln i textområdet.
Du kan också välja Visa autentiseringsnyckel för att se nyckeltexten.
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.
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äkerhet Inställningar –> Lokala principer –> Tilldelning av användarrättigheter –> Logga in som en tjänst
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.
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 Microsoft Integration Runtime Configuration Manager> Inställningar> Emote-åtkomst till intranätet.
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.
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:
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.
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.
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 är konfigurerad 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 som ska användas 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.
- Öppna Microsoft Integration Runtime Configuration Manager.
- Välj fliken Inställningar.
- Under HTTP-proxy väljer du länken Ändra för att öppna dialogrutan Ange HTTP-proxy .
- 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.
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:
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.
Öppna Anteckningar körs som administratör.
I Anteckningar öppnar du textfilen C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config.
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> (Inställningar) för syntax.<proxy autoDetect="true|false|unspecified" bypassonlocal="true|false|unspecified" proxyaddress="uriString" scriptLocation="uriString" usesystemdefault="true|false|unspecified "/>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:
- Offentlig: https://www.microsoft.com/download/details.aspx?id=56519
- US Gov: https://www.microsoft.com/download/details.aspx?id=57063
- Tyskland: https://www.microsoft.com/download/details.aspx?id=57064
- Kina: https://www.microsoft.com/download/details.aspx?id=57062
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.
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.
Öppna Anteckningar körs som administratör.
I Anteckningar öppnar du C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config.
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>
Möjliga symtom för problem som rör brandväggs- och proxyservern
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 Anslut ing. 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
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. Det krävs inte om fristående interaktiv redigering är aktiverad. |
Offentligt moln: {datafactory}.{region}.datafactory.azure.neteller *.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 FQDN från din lokalt installerad integrationskörningsnyckel, som är i formatet {datafactory}. {region}.datafactory.azure.net. För gamla Data Factory och Azure Synapse Analytics använder du *.frontend.clouddatahub.net i stället om du inte ser det fullständiga domännamnet i din lokalt installerad integrationsnyckel. |
download.microsoft.com |
443 | Krävs av den lokalt installerade integrationskörningen för nedladdning av uppdateringarna. Om du har inaktiverat automatisk uppdatering 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.netlogin.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".
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. Följ dessa steg:
Gå till tjänstportalen och välj din lokala integrationskörning.
På sidan Redigera väljer du Noder.
Välj Visa tjänst-URL:er för att hämta alla fullständiga domännamn.
Du kan lägga till dessa FQDN i listan över tillåtna brandväggsregler.
Kommentar
Mer information om Azure Relay-anslutningsprotokoll finns i Azure Relay Hybrid Anslut ions protocol.
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:
- Tillåt utgående TCP-kommunikation på port 1433 för både Windows-brandväggen och företagets brandvägg.
- 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:
- 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.