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

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 IR med egen värd.

Att tänka på när du använder en IR med egen värd

• Du kan använda en enda lokal Integration Runtime för flera lokala datakällor. Du kan också dela den med en annan datafabrik eller Synapse-arbetsyta i samma Azure Active Directory (Azure AD). Mer information finns i Dela en integrationskörning med egen värd.
• Du kan bara installera en instans av en integrationskörning med egen värd på en enskild dator. Om du har två datafabriker eller Synapse-arbetsytor som behöver åtkomst till lokala datakällor kan du antingen använda IR-delningsfunktionen med egen värd för att dela IR med egen värd eller installera IR med egen värd på två lokala datorer, en för varje datafabrik eller Synapse-arbetsyta.
• Integration Runtime med egen värd behöver inte finnas på samma dator som datakällan. Att ha integration runtime med egen värd nära datakällan minskar dock tiden för integrationskörning med egen värd att ansluta till datakällan. Vi rekommenderar att du installerar integration runtime med egen värd på en dator som skiljer sig från den som är värd för den lokala datakällan. När integration runtime med egen värd och datakällan finns på olika datorer, konkurrerar inte integration runtime med egen värd med datakällan för resurser.
• Du kan ha flera integrationskörningar med egen värd på olika datorer som ansluter till samma lokala datakälla. Om du till exempel har två integrationskörningar med egen värd som betjänar två datafabriker kan samma lokala datakälla registreras med båda datafabrikerna.
• Använd en integrationskörning med egen värd 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 integration runtime med egen värd för att ansluta tjänsten till datakällan.
• Använd integration runtime med egen värd även om datalagret finns i molnet på en virtuell IaaS-dator (Infrastruktur som en tjänst) i Azure.
• Aktiviteter kan misslyckas i en integrationskörning med egen värd som du har installerat på en Windows-server där FIPS-kompatibel kryptering är aktiverat. Du kan lösa det här problemet med två alternativ: lagra autentiseringsuppgifter/hemliga värden i en 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 (aktiverat) till 0 (inaktiverat): HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled . Om du använder integration runtime med egen värd som proxy för SSIS Integration Runtimekan FIPS-kompatibel kryptering aktiveras och används när du flyttar data från en lokal plats till Azure Blob Storage som ett mellanlagringsområde.

Kommandoflöde och dataflöde

När du flyttar data mellan den lokala platsen och molnet använder aktiviteten en lokal Integration Runtime för att överföra data mellan en lokal datakälla och molnet.

Här är en översikt över dataflödesstegen för att kopiera med en IR med egen värd:

1. En datautvecklare skapar först en integrationskörning med egen värd 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 Integration Runtime-instansen som tjänsten ska använda för att ansluta till datalager.

2. Noden Integration Runtime med egen värd krypterar autentiseringsuppgifterna med hjälp Windows DPAPI (Data Protection Application Programming Interface) 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 IR med egen värd.

3. Azure Data Factory och Synapse-pipelines kommunicerar med integration runtime med egen värd 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 autentiseringsinformation. Det gör det om autentiseringsuppgifterna inte redan lagras i integration runtime med egen värd. Integration Runtime med egen värd startar jobbet när kön har avsökts.

4. Integration Runtime med egen värd kopierar data mellan ett lokalt lager och molnlagring. Kopieringens riktning beror på hur kopieringsaktiviteten konfigureras i datapipelinen. I det här steget kommunicerar integration runtime med egen värd direkt med molnbaserade lagringstjänster som Azure Blob Storage via en säker HTTPS-kanal.

Förutsättningar

• De versioner av Windows är:
  • Windows 8,1
  • Windows 10
  • Windows Server 2012
  • Windows Server 2012 R2
  • Windows Server 2016
  • Windows Server 2019

Installation av integration runtime med egen värd på en domänkontrollant stöds inte.

• Integration Runtime med egen värd kräver ett 64-bitars operativsystem med .NET Framework 4.7.2 eller högre. Mer .NET Framework finns i .NET Framework systemkrav.
• Den rekommenderade minsta konfigurationen för den lokala 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 försättas i viloläge svarar inte integration Runtime med egen värd på databegäranden. Konfigurera ett lämpligt energischema på datorn innan du installerar integration runtime med egen värd. Om datorn är konfigurerad för viloläge visas ett meddelande i installationsprogrammet för integration runtime med egen värd.
• Du måste vara administratör på datorn för att kunna installera och konfigurera integration runtime med egen värd.
• Kopieringsaktivitetskörningar sker med en viss frekvens. Processor- och RAM-användningen på datorn följer samma mönster med hög belastning och inaktivitetstider. Resursanvändningen beror också mycket på mängden data som flyttas. När flera kopieringsjobb pågår ser du att resursanvändningen ökar under tider med hög belastning.
• Uppgifter kan misslyckas under extrahering av data i Parquet-, ORC- eller Avro-format. Mer information om Parquet finns i Parquet-format i Azure Data Factory. Filskapandet körs på integrationsdatorn med egen värd. För att fungera som förväntat kräver filskapandet följande krav:
  • Visual C++ 2010 Redistributable Paket (x64)
  • Java Runtime (JRE) version 8 från en JRE-provider, till exempel Adopt OpenJDK. Kontrollera att JAVA_HOME miljövariabeln är inställd på JDK-mappen (och inte bara JRE-mappen).

  Anteckning

  Det kan vara nödvändigt att justera Java-inställningarna om minnesfel uppstår, enligt beskrivningen i dokumentationen [Parquet-format] (format-parquet#using-self-hosted-integration-runtime).

Konfigurera integration runtime med egen värd

Använd följande procedurer för att skapa och konfigurera en integration runtime med egen värd.

Skapa en IR med egen värd 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 integration runtime med egen värd på en lokal dator.

3. Hämta autentiseringsnyckeln och registrera integration runtime med egen värd med nyckeln. Här är ett PowerShell-exempel:

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

Skapa en IR med egen värd via användargränssnittet

Använd följande steg för att skapa en IR med egen värd med hjälp Azure Data Factory eller Azure Synapse användargränssnitt.

Konfigurera en IR med egen värd via användargränssnittet

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

2. På sidan För installation av Integration Runtime väljer du länken under Alternativ 1 för att öppna expressinstallationen på datorn. Du kan också följa stegen under Alternativ 2 för att konfigurera manuellt. Följande instruktioner baseras på manuell installation:

   

   1. Kopiera och klistra in autentiseringsnyckeln. Välj Ladda ned och installera Integration Runtime.

   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 den nyckel 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 integration Runtime med egen värd har registrerats visas följande fönster:

   

Konfigurera en IR med egen värd på en virtuell Azure-dator via en Azure Resource Manager mall

Du kan automatisera IR-installation med egen värd på en virtuell Azure-dator med hjälp av mallen Skapa IR med egen värd. Mallen är ett enkelt sätt att ha en fullt fungerande IR med egen värd 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 lokal IR via lokal PowerShell

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

Dmgcmd.exe ingår i installationsprogrammet med egen värd. Den finns vanligtvis i mappen C:\Program Files\Microsoft Integration Runtime\4.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 är information om programmets åtgärder och argument:

Installera och registrera en IR med egen värd 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 sedan Nästa.

5. Acceptera Licensvillkor för Programvara från Microsoft och välj Nästa.

6. Välj mapp för att installera integration runtime med egen värd och välj Nästa.

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

8. Slutför installationen genom att välja Slutför.

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

10. I fönstret Registrera Integration Runtime (lokal installation) för Microsoft Integration Runtime Konfigurationshanteraren som körs på datorn gör du följande:

    1. Klistra in autentiseringsnyckeln i textområdet.

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

    3. Välj Register (Registrera).

Tjänstkonto för integrationskörning med egen värd

Standardkontot för integrationskörning med egen värd är NT SERVICE\DIAHostService. Du kan se den i Services -> Integration Runtime Service -> Properties -> Log on.

Kontrollera att kontot har behörigheten Logga in som en tjänst. Annars kan integration runtime med egen värd inte starta korrekt. Du kan kontrollera behörigheten i Local Security Policy -> Security Inställningar -> Local Policies -> User Rights Assignment -> Log on as a service

Ikoner och meddelanden för meddelandefältet

Om du flyttar markören över ikonen eller meddelandet i meddelandefältet kan du se information om tillståndet för integrationskörningen med egen värd.

Hög tillgänglighet och skalbarhet

Du kan associera en lokal integrationskörning med flera lokala datorer eller virtuella datorer i Azure. Dessa datorer kallas noder. Du kan ha upp till fyra noder som är associerade med en integrationskörning med egen värd. 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 integrationskörning med egen värd så att det inte längre är den enskilda felpunkten i din stordatalösning eller integrering av molndata. Den här tillgängligheten säkerställer kontinuiteten när du använder upp till fyra noder.
• Bättre prestanda och dataflöde vid dataförflyttning mellan lokala datalager och molndatalager. Få mer information om prestandajämförelser.

Du kan associera flera noder genom att installera integration runtime-programvaran med egen värd från Download Center. Registrera den sedan med någon av autentiseringsnycklarna som erhölls från cmdleten New-AzDataFactoryV2IntegrationRuntimeKey, enligt beskrivningen i självstudien.

Överväganden för skalning

Skala ut

När processoranvändningen är hög och det finns ont om tillgängligt minne på den lokala IR:en lägger du till en ny nod för att skala ut belastningen mellan datorer. Om aktiviteter misslyckas på grund av att de tar slut eller om den lokala IR-noden är offline hjälper det om du lägger till en nod i gatewayen.

Skala upp

När processorn och tillgängligt RAM-minne 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 aktiviteternas time out eftersom den lokala IR:en är överbelastad. Som du ser i följande bild kan du öka den maximala kapaciteten för en nod:

Krav för TLS/SSL-certifikat

Här är kraven för TLS/SSL-certifikatet som du använder för att skydda kommunikationen mellan Integration Runtime-noder:

• Certifikatet måste vara ett offentligt betrott X509 v3-certifikat. Vi rekommenderar att du använder certifikat som utfärdats av en offentlig partnercertifikatutfärdare (CA).
• Varje Integration Runtime-nod måste ha förtroende för det här certifikatet.
• Vi rekommenderar inte SAN-certifikat (Alternativt namn för certifikat), eftersom endast det sista SAN-objektet används. Alla andra SAN-objekt ignoreras. Om du till exempel har ett SAN-certifikat vars SAN är node1.domain.contoso.com och node2.domain.contoso.com kan du bara använda det här certifikatet på en dator vars fullständiga domännamn (FQDN) är node2.domain.contoso.com.
• Certifikatet kan använda valfri nyckelstorlek som stöds av Windows Server 2012 R2 för TLS/SSL-certifikat.
• Certifikat som använder CNG-nycklar stöds inte.

Synkronisering av autentiseringsuppgifter

Om du inte lagrar autentiseringsuppgifter eller hemliga värden i en Azure Key Vault lagras autentiseringsuppgifterna eller hemliga värdena på de datorer där din integrationskörning med egen värd 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.

Överväganden för proxyserver

Om företagets nätverksmiljö använder en proxyserver för att få åtkomst till Internet konfigurerar du den lokala integreringskörningen så att den använder lämpliga proxyinställningar. Du kan ange proxyn under den inledande registreringsfasen.

När den har konfigurerats använder den lokala 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 länken Ändra under den första installationen.

Det finns tre konfigurationsalternativ:

• Använd inte proxy: Integration Runtime med egen värd använder inte någon proxy för att ansluta till molntjänster.
• Använd systemproxy: Den lokala integrationskörningen använder proxyinställningen som konfigureras i diahost.exe.config och diawp.exe.config. Om de här filerna inte anger någon proxykonfiguration ansluter integration runtime med egen värd direkt till molntjänsten utan att gå via en proxyserver.
• Använd anpassad proxy: Konfigurera DEN HTTP-proxyinställning som ska användas för integration runtime med egen värd, i stället för att använda konfigurationer i diahost.exe.config och diawp.exe.config. Adress- och portvärden krävs. Värdena Användarnamn och Lösenord är valfria, beroende på proxyns autentiseringsinställning. Alla inställningar krypteras med Windows DPAPI på den lokala integrationskörningen och lagras lokalt på datorn.

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

Om du vill visa eller uppdatera proxyinställningar när du har registrerat integration runtime med egen värd använder du Microsoft Integration Runtime Konfigurationshanteraren.

1. Öppna Microsoft Integration Runtime Konfigurationshanteraren.
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. Sedan visas en varning som ber om din behörighet att spara proxyinställningen och starta om integration Runtime-värdtjänsten.

Du kan använda verktyget Configuration Manager 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 lokala integreringskörningen proxyinställningarna i diahost.exe.config och diawp.exe.config. När de här filerna inte anger någon proxy ansluter integration runtime med egen värd direkt till molntjänsten utan att gå via en proxyserver. Följande procedur innehåller instruktioner för att uppdatera diahost.exe.config fil:

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

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

3. I Anteckningar du textfilen C:\Program Files\Microsoft Integration Runtime\4.0\Shared\diahost.exe.config.

4. Hitta standardtaggen system.net som visas i 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 . Syntax <proxy> finns i Element (Instä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 värdtjänsten integration runtime med egen värd, som hämtar ändringarna.

   Om du vill starta om tjänsten använder du tjänst-appleten från Kontrollpanelen. Eller Integration Runtime Konfigurationshanteraren 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 den programkonfigurationsfil som du redigerade.

Du måste också kontrollera att Microsoft Azure finns 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 taggade tjänster i molnet, är nu tillgängliga på MS Download:

• Offentliga: 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

Möjliga symptom för problem som rör brandväggen och proxyservern

Om du ser felmeddelanden som liknar följande är den troliga orsaken felaktig konfiguration av brandväggen eller proxyservern. Den här konfigurationen förhindrar att integration runtime med egen värd ansluter till Data Factory eller Synapse-pipelines för att autentisera sig själv. Information om hur du ser till att brandväggen och proxyservern är korrekt konfigurerade finns i föregående avsnitt.

• När du försöker registrera integration runtime med egen värd visas följande felmeddelande: "Det gick inte att registrera den här Integration Runtime noden! Bekräfta att autentiseringsnyckeln är giltig och att integrationstjänstens värdtjänst körs på den här datorn."

• När du öppnar Integration Runtime Konfigurationshanteraren visas statusen Frånkopplad eller Ansluta. När du visar Windows-händelseloggar, under Loggboken program- och Microsoft Integration Runtime, visas felmeddelanden > > som den här:

  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ätverksdator ä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 integration runtime med egen värd version 3.3 eller senare inaktiverar installationsprogrammet för integration runtime med egen värd fjärråtkomst från intranätet på den lokalt värdbaserade Integration Runtime-datorn.

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

msiexec /q /i IntegrationRuntime.msi NOFIREWALL=1

Om du väljer att inte öppna port 8060 på den egen värdbaserade 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 överväga:

• Företagets brandvägg som körs på den centrala routern i organisationen
• Den Windows brandväggen som är konfigurerad som en daemon på den lokala datorn där integration runtime med egen värd är installerad

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

På Windows eller datornivå är dessa utgående portar normalt aktiverade. Om de inte är det kan du konfigurera domäner och portar på en IR-dator med egen värd.

Baserat på din källa och dina 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 lokala Integration Runtime-datorer i deras brandväggskonfiguration.

Hämta URL för Azure Relay

En obligatorisk domän och port som måste finnas i brandväggens lista över tillåtna är att kommunikationen till Azure Relay. Integration Runtime med egen värd använder den för interaktiv redigering, till exempel testanslutning, bläddringsmapplista 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 som krävs av din lokala Integration Runtime från tjänstportalen. Följ de här stegen:

1. Gå till tjänstportalen och välj integration runtime med egen värd.

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

3. Välj Visa tjänst-URL:er för att hämta alla FQDN.

   

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 korrekt i företagets brandvägg, Windows för den lokala integrationskörningsdatorn och själva datalagret. När du aktiverar de här reglerna kan den lokala integreringskörningen ansluta till både källan och mottagaren. 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 gör du följande:

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 att lägga till IP-adressen för den egen värdbaserade integrationskörningsdatorn i listan över tillåtna IP-adresser.

Metodtips för installation

Du kan installera integration runtime med egen värd 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 moln.

• Konfigurera ett energischema på värddatorn för integration runtime med egen värd så att datorn inte försättas i viloläge. Om värddatorn försättas i viloläge förkopplas integrationskörningen med egen värd.
• Återkommande återkommande autentiseringsuppgifter som är associerade med integration runtime med egen värd.
• Om du vill automatisera IR-installationsåtgärder med egen värd kan du gå till Konfigurera en befintlig IR med egen värd via PowerShell.

Nästa steg

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