Skapa och konfigurera lokalt installerad integrationskörning

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

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.

Ö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.

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:

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 .

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  
   
   

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.

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:

   

   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.

      

   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:

   

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:

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.

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äkerhetsinstä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.

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:

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.

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 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.

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.

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.

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>
   

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 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

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

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.

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.

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.

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.

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 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.

   

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

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.

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.

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.