Creare e configurare un runtime di integrazione self-hosted

SI APPLICA A: Azure Data Factory Azure Synapse Analytics

Il runtime di integrazione è l'infrastruttura di calcolo usata da Azure Data Factory e dalle pipeline di Synapse per distribuire le funzionalità di integrazione di dati in ambienti di rete diversi. Per informazioni dettagliate sul runtime di integrazione, vedere Runtime di integrazione in Azure Data Factory.

Un runtime di integrazione self-hosted può eseguire attività di copia tra un archivio dati cloud e un archivio dati in una rete privata. Può anche inviare le attività di trasformazione a risorse di calcolo in una rete locale o in una rete virtuale di Azure. L'installazione del runtime di integrazione self-hosted è necessaria in un computer locale oppure in una macchina virtuale all'interno di una rete privata.

Questo articolo descrive come creare e configurare un runtime di integrazione self-hosted.

Considerazioni sull'uso del runtime di integrazione self-hosted

• È possibile usare un singolo runtime di integrazione self-hosted per più origini dati locali. È anche possibile condividerlo con un'altra data factory all'interno dello stesso tenant di Microsoft Entra. Per altre informazioni, vedere Condivisione di un runtime di integrazione self-hosted.
• In un computer può essere installata una sola istanza di un runtime di integrazione self-hosted. Se sono presenti due data factory che devono accedere alle origini dati locali, usare la funzionalità di condivisione del runtime di integrazione self-hosted per condividere il runtime di integrazione self-hosted o installarlo in due computer locali, uno per ogni data factory o area di lavoro Synapse. L'area di lavoro di Synapse non supporta la condivisione del runtime di integrazione.
• Il runtime di integrazione self-hosted non deve trovarsi nello stesso computer dell'origine dati. Se tuttavia il runtime di integrazione self-hosted è vicino all'origine dati, il tempo di connessione a quest'ultima è minore. Si consiglia di installare il runtime di integrazione self-hosted in un computer diverso da quello che ospita l'origine dati locale. Quando il runtime di integrazione self-hosted e l'origine dati si trovano in computer diversi, non competono per accedere alle risorse.
• È possibile che più runtime di integrazione self-hosted siano presenti in computer diversi che si connettono alla stessa origine dati locale. Ad esempio, se si hanno due runtime di integrazione self-hosted che servono due data factory, la stessa origine dati locale può essere registrata per entrambe le data factory.
• Usare un runtime di integrazione self-hosted per supportare l'integrazione dei dati in una rete virtuale di Azure.
• Considerare l'origine dati come un'origine dati locale protetta da firewall anche quando si usa Azure ExpressRoute. Usare il runtime di integrazione self-hosted per connettere il servizio all'origine dati.
• Usare il runtime di integrazione self-hosted anche se l'archivio dati si trova nel cloud su una macchina virtuale di infrastruttura distribuita come servizio (IaaS) di Azure.
• In un runtime di integrazione self-hosted installato in un'istanza di Windows Server per cui è abilitata la crittografia FIPS potrebbero verificarsi errori di esecuzione delle attività. Per risolvere questo problema, sono disponibili due opzioni: archiviare credenziali/valori segreti in Azure Key Vault o disabilitare la crittografia conforme FIPS nel server. Per disabilitare la crittografia conforme FIPS, modificare il valore della sottochiave del registro di sistema seguente da 1 (abilitato) a 0 (disabilitato): HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled. Se si usa il runtime di integrazione self-hosted come proxy per il runtime di integrazione SSIS, la crittografia conforme FIPS può essere abilitata e verrà usata quando si spostano i dati dall'ambiente locale ad Archiviazione BLOB di Azure come area di gestione temporanea.
• I dettagli completi sulle licenze vengono forniti nella prima pagina della configurazione del runtime di integrazione self-hosted.

Flusso dei comandi e flusso di dati

Quando si spostano dati tra un ambiente locale e il cloud, l'attività usa un runtime di integrazione self-hosted per trasferirli tra l'origine dati locale e il cloud.

Di seguito viene indicato un riepilogo generale dei passaggi del flusso di dati per eseguire la copia con il runtime di integrazione self-hosted:

1. Uno sviluppatore di dati crea innanzitutto un runtime di integrazione self-hosted in un'istanza di Azure Data Factory o in un'area di lavoro di Synapse tramite il portale di Azure o il cmdlet di PowerShell. Lo sviluppatore di dati crea quindi un servizio collegato per un archivio dati locale, specificando l'istanza del runtime di integrazione self-hosted che il servizio deve usare per la connessione agli archivi dati.

2. Il nodo del runtime di integrazione self-hosted crittografa le credenziali con Data Protection API (DPAPI) e le salva in locale. Se più nodi vengono impostati per la disponibilità elevata, le credenziali vengono ulteriormente sincronizzate negli altri nodi. Ogni nodo crittografa le credenziali con DPAPI e le archivia in locale. La sincronizzazione delle credenziali è trasparente allo sviluppatore di dati e viene gestita dal runtime di integrazione self-hosted.

3. Le pipeline di Azure Data Factory e Synapse comunicano con il runtime di integrazione self-hosted per pianificare e gestire i processi. La comunicazione avviene tramite un canale di controllo che usa una connessione condivisa a Inoltro di Azure. Quando occorre eseguire un processo di attività, il servizio accoda la richiesta insieme alle informazioni sulle credenziali. Questo avviene nel caso in cui le credenziali non siano già archiviate nel runtime di integrazione self-hosted. Il runtime di integrazione self-hosted avvia il processo dopo aver eseguito il polling della coda.

4. Il runtime di integrazione self-hosted copia i dati tra un archivio locale e l'archiviazione nel cloud. La direzione della copia dipende dalla modalità di configurazione dell'attività di copia nella pipeline di dati. Per eseguire questo passaggio, il runtime di integrazione self-hosted comunica direttamente con i servizi di archiviazione basati sul cloud, come Archiviazione BLOB di Azure, su un canale protetto (HTTPS).

Prerequisiti

• Le versioni di Windows supportate sono:
  • Windows 10
  • Windows 11
  • Windows Server 2016
  • Windows Server 2019
  • Windows Server 2022

L'installazione del runtime di integrazione self-hosted in un controller di dominio non è supportata.

• Il runtime di integrazione self-hosted richiede un sistema operativo a 64 bit con .NET Framework 4.7.2 o versioni successive. Per informazioni dettagliate, vedere Requisiti di sistema di .NET Framework .
• La configurazione minima consigliata per il computer del runtime di integrazione self-hosted è un processore a 2 GHz con 4 core, 8 GB di RAM e 80 GB di spazio disponibile sul disco rigido. Per informazioni dettagliate sui requisiti di sistema, vedere Download.
• Se il computer host entra in stato di ibernazione, il runtime di integrazione self-hosted non risponde alle richieste di dati. Configurare una combinazione appropriata per il risparmio di energia nel computer prima di installare il runtime di integrazione self-hosted. Se il computer è configurato per l'ibernazione, il programma di installazione del runtime di integrazione self-hosted invia un messaggio.
• È necessario essere un amministratore del computer per installare e configurare correttamente il runtime di integrazione self-hosted.
• Le attività di copia vengono eseguite con una frequenza specifica. L'uso del processore e della RAM nel computer segue lo stesso schema costituito da periodi di picco alternati a periodi di inattività. L'uso delle risorse dipende molto anche dalla quantità di dati che viene spostata. Quando sono in corso più processi di copia, l'utilizzo delle risorse aumenta durante i periodi di picco.
• Le attività potrebbero non andare a buon fine durante l'estrazione dei dati in formati Parquet, ORC o Avro. Per altre informazioni su Parquet, vedere Formato Parquet in Azure Data Factory. La creazione di file viene eseguita nel computer di integrazione self-hosted. Per funzionare come previsto, la creazione di file richiede i prerequisiti seguenti:
  • Java Runtime (JRE) versione 11 da un provider JRE, ad esempio Microsoft OpenJDK 11 o Eclipse Temurin 11. Assicurarsi che la variabile di ambiente di sistema JAVA_HOME sia impostata sulla cartella JDK (non solo sulla cartella JRE). Potrebbe anche essere necessario aggiungere la cartella bin alla variabile di ambiente PATH del sistema.

  Nota

  Potrebbe essere necessario modificare le impostazioni Java se si verificano errori di memoria, come descritto nella documentazione sul formato Parquet.

Configurazione di un runtime di integrazione self-hosted

Per creare e configurare un runtime di integrazione self-hosted, usare le procedure seguenti.

Creare un runtime di integrazione self-hosted tramite Azure PowerShell

1. Per questa attività è possibile usare Azure PowerShell. Ecco un esempio:

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

2. Scaricare e installare il runtime di integrazione self-hosted in un computer locale.

3. Recuperare la chiave di autenticazione e registrare il runtime di integrazione self-hosted con la chiave. Di seguito è illustrato un esempio di PowerShell:

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

Eseguire il comando PowerShell in Azure per enti pubblici. Vedere Connettersi ad Azure per enti pubblici con PowerShell.

Creare un runtime di integrazione self-hosted tramite l'interfaccia utente

Usare la procedura seguente per creare un runtime di integrazione self-hosted usando Azure Data Factory o l'interfaccia utente di Azure Synapse.

Configurare un runtime di integrazione self-hosted tramite l'interfaccia utente

1. Immettere un nome per il runtime di integrazione e selezionare Crea.

2. Nella pagina Configurazione del runtime di integrazione, selezionare il collegamento in Opzione 1 per aprire l'installazione rapida nel computer. In alternativa, seguire la procedura descritta in Opzione 2 per eseguire la configurazione manualmente. Le istruzioni seguenti sono basate sull'installazione manuale:

   

   1. Copiare e incollare la chiave di autenticazione. Selezionare Scaricare e installare il runtime di integrazione.

   2. Scaricare il runtime di integrazione self-hosted in un computer Windows locale. Eseguire il programma di installazione.

   3. Nella pagina Registrare runtime di integrazione (self-hosted), incollare la chiave salvata in precedenza e selezionare Registra.

      

   4. Nella pagina Nuovo nodo di Integration Runtime (self-hosted) fare clic su Fine.

3. Al termine della registrazione del runtime di integrazione self-hosted viene visualizzata la finestra seguente:

   

Configurare un runtime di integrazione self-hosted in una macchina virtuale di Azure tramite un modello di Azure Resource Manager

È possibile automatizzare l'installazione del runtime di integrazione self-hosted in una macchina virtuale di Azure usando Crea modello di runtime di integrazione self-hosted. Il modello offre un modo semplice per avere un runtime di integrazione self-hosted completamente funzionante all'interno di una rete virtuale di Azure. Il runtime di integrazione ha disponibilità elevata e funzionalità di scalabilità, purché il numero di nodi sia impostato almeno su 2.

Configurare un runtime di integrazione self-hosted esistente tramite PowerShell locale

È possibile usare una riga di comando per configurare o gestire un runtime di integrazione self-hosted esistente. Questo utilizzo può essere utile soprattutto per automatizzare l'installazione e la registrazione dei nodi del runtime di integrazione self-hosted.

Dmgcmd.exe è incluso nel programma di installazione self-hosted. Si trova in genere nella cartella C:\Programmi\Microsoft Integration Runtime\5.0\Shared\. Questa applicazione supporta vari parametri e può essere richiamata tramite una riga di comando usando script batch per l'automazione.

Usare l'applicazione come indicato di seguito:

dmgcmd ACTION args...

Ecco i dettagli delle azioni e degli argomenti dell'applicazione:

ACTION	args	Descrizione
-rn, -RegisterNewNode	"<AuthenticationKey>" ["<NodeName>"]	Registrare un nodo del runtime di integrazione self-hosted con la chiave di autenticazione e il nome del nodo specificati.
-era, -EnableRemoteAccess	"<port>" ["<thumbprint>"]	Abilitare l'accesso remoto nel nodo corrente per configurare un cluster a disponibilità elevata. In alternativa, abilitare l'impostazione delle credenziali direttamente sul runtime di integrazione self-hosted senza passare attraverso un'area di lavoro di Azure Data Factory o Azure Synapse. A tale scopo, usare il cmdlet New-AzDataFactoryV2LinkedServiceEncryptedCredential da un computer remoto nella stessa rete.
-erac, -EnableRemoteAccessInContainer	"<port>" ["<thumbprint>"]	Abilitare l'accesso remoto al nodo corrente quando il nodo è in esecuzione in un contenitore.
-dra, -DisableRemoteAccess		Disabilitare l'accesso remoto al nodo corrente. L'accesso remoto è necessario per la configurazione tra più nodi. Il cmdlet di PowerShell New-AzDataFactoryV2LinkedServiceEncryptedCredential funziona ancora anche quando l'accesso remoto è disabilitato. Questo comportamento è vero, purché il cmdlet venga eseguito nello stesso computer del nodo del runtime di integrazione self-hosted.
-k, -Key	"<AuthenticationKey>"	Sovrascrivere o aggiornare la chiave di autenticazione precedente. Prestare attenzione a questa azione. Il nodo del runtime di integrazione self-hosted precedente può essere offline se la chiave è di un nuovo runtime di integrazione.
-gbf, -GenerateBackupFile	"" "<filePath><password>"	Generare un file di backup per il nodo corrente. Il file di backup include la chiave del nodo e le credenziali dell'archivio dati.
-ibf, -ImportBackupFile	"" "<filePath><password>"	Ripristinare il nodo da un file di backup.
-r, -Restart		Riavviare il servizio host del runtime di integrazione self-hosted.
-s, -Start		Avviare il servizio host del runtime di integrazione self-hosted.
-t, -Stop		Arrestare il servizio host del runtime di integrazione self-hosted.
-sus, -StartUpgradeService		Avviare il servizio di aggiornamento del runtime di integrazione self-hosted.
-tus, -StopUpgradeService		Arrestare il servizio di aggiornamento del runtime di integrazione self-hosted.
-tonau, -TurnOnAutoUpdate		Abilitare l'aggiornamento automatico del runtime di integrazione self-hosted. Questo comando è solo per Azure Data Factory V1.
-toffau, -TurnOffAutoUpdate		Disabilitare l'aggiornamento automatico del runtime di integrazione self-hosted. Questo comando è solo per Azure Data Factory V1.
-ssa, -SwitchServiceAccount	"<domain\user>" ["<password>"]	Impostare DIAHostService per l'esecuzione come nuovo account. Usare la password vuota "" per gli account di sistema e gli account virtuali.
-elma, -EnableLocalMachineAccess		Abilitare l'accesso al computer locale (localhost, IP privato) nel nodo del runtime di integrazione self-hosted corrente. Nello scenario di disponibilità elevata del runtime di integrazione self-hosted, l'azione deve essere richiamata in ogni nodo del runtime di integrazione self-hosted.
-dlma, -DisableLocalMachineAccess		Disabilitare l'accesso al computer locale (localhost, IP privato) nel nodo del runtime di integrazione self-hosted corrente. Nello scenario di disponibilità elevata del runtime di integrazione self-hosted, l'azione deve essere richiamata in ogni nodo del runtime di integrazione self-hosted.
-DisableLocalFolderPathValidation		Disabilitare la convalida di sicurezza per abilitare l'accesso al file system del computer locale.
-EnableLocalFolderPathValidation		Abilitare la convalida di sicurezza per disabilitare l'accesso al file system del computer locale.
-eesp, -EnableExecuteSsisPackage		Abilitare l'esecuzione del pacchetto SSIS nel nodo del runtime di integrazione self-hosted.
-desp, -DisableExecuteSsisPackage		Disabilitare l'esecuzione del pacchetto SSIS nel nodo del runtime di integrazione self-hosted.
-gesp, -GetExecuteSsisPackage		Ottenere il valore se l'opzione ExecuteSsisPackage è abilitata nel nodo del runtime di integrazione self-hosted. Se il valore restituito è true, ExecuteSSISPackage è abilitato; se il valore restituito è false o null, ExecuteSSISPackage è disabilitato.

Installare e registrare un runtime di integrazione self-hosted dall'Area download Microsoft

1. Accedere alla pagina di download di Microsoft Integration Runtime.

2. Selezionare Scaricare, selezionare la versione a 64 bit e selezionare Successivo. La versione a 32 bit non è supportata.

3. Eseguire il file MSI direttamente oppure salvarlo sul disco rigido ed eseguirlo.

4. Nella finestra di benvenuto selezionare una lingua e quindi selezionare Avanti.

5. Accettare le condizioni di licenza software Microsoft e quindi selezionare Avanti.

6. Selezionare la cartella in cui installare il runtime di integrazione self-hosted e quindi selezionare Avanti.

7. Nella pagina Pronto per l'installazione, seleziona Installa.

8. Selezionare Fine per completare l'installazione.

9. Ottenere la chiave di autenticazione tramite PowerShell. Di seguito viene indicato un esempio di PowerShell per recuperare la chiave di autenticazione:

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

10. Nella finestra Registra Integration Runtime (self-hosted) di Gestione configurazione di Microsoft Integration Runtime in esecuzione sul computer, seguire questa procedura:

    1. Incollare la chiave di autenticazione nell'area di testo.

    2. Facoltativamente, selezionare Mostra chiave di autenticazione per visualizzare il testo della chiave.

    3. Selezionare Registra.

Account del servizio per il runtime di integrazione self-hosted

L'account del servizio di accesso predefinito del runtime di integrazione self-hosted è NT SERVICE\DIAHostService. È possibile visualizzarlo in Servizi -> Servizio del runtime di integrazione -> Proprietà -> Accesso.

Assicurarsi che l'account disponga dell'autorizzazione Accesso come servizio. In caso contrario, il runtime di integrazione self-hosted non può essere avviato correttamente. È possibile controllare l'autorizzazione in Criteri di sicurezza locali -> Impostazioni di sicurezza -> Criteri locali -> Assegnazione diritti utente -> Accesso come servizio

Icone e notifiche dell'area di notifica

Se si sposta il cursore sul messaggio di notifica o sull'icona nell'area di notifica, vengono visualizzati i dettagli sullo stato del runtime di integrazione self-hosted.

Disponibilità elevata e scalabilità

È possibile associare un runtime di integrazione self-hosted a più macchine locali o macchine virtuali in Azure. Questi computer sono chiamati nodi. È possibile avere fino a quattro nodi associati a un runtime di integrazione self-hosted. Di seguito vengono indicati i vantaggi della presenza di più nodi su computer locali con un gateway installato per un gateway logico:

• Disponibilità più elevata del runtime di integrazione self-hosted in modo che non sia più il singolo punto di guasto nella soluzione per Big Data o nell'integrazione dei dati cloud. Questa disponibilità consente di garantire la continuità quando si usano fino a quattro nodi.
• Miglioramento delle prestazioni e della velocità effettiva durante lo spostamento dati tra archivi dati locali e cloud. Ottenere altre informazioni sui confronti delle prestazioni.

Per associare più nodi, installare il software di runtime di integrazione self-hosted dall'Area download. e quindi registrarlo usando una delle chiavi di autenticazione ottenute dal cmdlet New-AzDataFactoryV2IntegrationRuntimeKey, come descritto nell'esercitazione.

Considerazioni sulla scalabilità

Aumentare il numero di istanze

Quando l'utilizzo del processore è elevato e la memoria disponibile è ridotta nel runtime di integrazione self-hosted, aggiungere un nuovo nodo per aumentare il carico nei computer. Se le attività hanno esito negativo perché si verifica un timeout o il nodo del runtime di integrazione self-hosted è offline, è utile aggiungere un nodo al gateway. Per aggiungere un nodo, eseguire la procedura seguente:

1. Scaricare la configurazione SHIR dal portale Azure Data Factory.
2. Eseguire il programma di installazione sul nodo da aggiungere al cluster.
3. Durante l'installazione, selezionare l'opzione per aggiungere un rutime di integrazione esistente e fornire la chiave di autenticazione dal SHIR esistente per collegare il nuovo nodo al cluster SHIR esistente.

Aumentare le prestazioni

Quando il processore e la RAM disponibile non vengono usati correttamente, ma l'esecuzione di processi simultanei raggiunge i limiti di un nodo, aumentare il numero di processi simultanei che possono essere eseguiti da un nodo. È anche possibile aumentare le prestazioni quando si verifica un timeout delle attività perché il runtime di integrazione self-hosted è sovraccarico. Come illustrato nell'immagine seguente, è possibile aumentare la capacità massima di un nodo:

Requisiti del certificato TLS/SSL

Se si vuole abilitare l'accesso remoto dall'Intranet con il certificato TLS/SSL (Advanced) per proteggere la comunicazione tra i nodi del runtime di integrazione, è possibile seguire la procedura descritta in Abilitare l'accesso remoto dall'Intranet con certificato TLS/SSL.

Sincronizzazione delle credenziali

Se non si archiviano credenziali o valori dei segreti in un insieme di credenziali chiave di Azure, le credenziali o i valori dei segreti verranno archiviati nei computer in cui viene individuato il runtime di integrazione self-hosted. Ogni nodo avrà una copia delle credenziali con una determinata versione. Per fare in modo che tutti i nodi funzionino insieme, il numero di versione deve essere lo stesso per tutti i nodi.

Considerazioni sui server proxy

Se nell'ambiente di rete aziendale è presente un server proxy per accedere a Internet, configurare il runtime di integrazione self-hosted per usare le impostazioni proxy appropriate. È possibile impostare il proxy durante la fase di registrazione iniziale.

Se configurato, il runtime di integrazione self-hosted usa il server proxy per connettersi all'origine e alla destinazione del servizio cloud (che usano il protocollo HTTP o HTTPS). Questo è il motivo per cui si seleziona Modifica collegamento durante la configurazione iniziale.

Sono disponibili tre opzioni di configurazione:

• Non usare proxy: il runtime di integrazione self-hosted non usa in modo esplicito alcun proxy per connettersi ai servizi cloud.
• Usa il proxy di sistema: il runtime di integrazione self-hosted usa l'impostazione del proxy configurata in diahost.exe.config e diawp.exe.config. Se questi file non specificano alcuna configurazione di proxy, il runtime di integrazione self-hosted si connette al servizio cloud direttamente senza usare il proxy.
• Usa proxy personalizzato: configurare le impostazioni del proxy HTTP che il runtime di integrazione self-hosted deve usare al posto delle configurazioni in diahost.exe.config e diawp.exe.config. I valori Indirizzo e Porta sono obbligatori. I valori Nome utente e Password sono facoltativi e dipendono dalle impostazioni di autenticazione del proxy. Tutte le impostazioni vengono crittografate con Windows DPAPI nel runtime di integrazione self-hosted e archiviate localmente nel computer.

Il servizio host di runtime di integrazione viene riavviato automaticamente dopo avere salvato le impostazioni proxy aggiornate.

Dopo aver registrato il runtime di integrazione self-hosted, se si intende visualizzare o aggiornare le impostazioni proxy, usare Gestione configurazione di Microsoft Integration Runtime.

1. Aprire Gestione configurazione di Microsoft Integration Runtime.
2. Seleziona la scheda Impostazioni.
3. Da Proxy HTTP, selezionare il collegamento Modifica per aprire la finestra di dialogo Imposta proxy HTTP.
4. Selezionare Avanti. Viene visualizzato un avviso che richiede l'autorizzazione per salvare le impostazioni del proxy e riavviare il servizio host di runtime di integrazione.

È possibile usare lo strumento Gestione configurazione per visualizzare e aggiornare il proxy HTTP.

Configurare le impostazioni del server proxy

Se si seleziona l'opzione Usa il proxy di sistema per il proxy HTTP, il runtime di integrazione self-hosted usa l'impostazione proxy contenuta in diahost.exe.config e diawp.exe.config. Se questi file non specificano alcun proxy, il runtime di integrazione self-hosted si connette al servizio cloud direttamente senza usare il proxy. La procedura seguente contiene le istruzioni per aggiornare il file diahost.exe.config:

1. In Esplora file creare una copia sicura di C:\Programmi\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config come backup del file originale.

2. Aprire Blocco note in esecuzione come amministratore.

3. Nel Blocco note, aprire il file di testo C:\Programmi\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config.

4. Trovare il tag predefinito system.net come indicato nel codice seguente:

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

   È quindi possibile aggiungere i dettagli del server proxy, come illustrato nell'esempio seguente:

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

   Il tag proxy consente alle proprietà aggiuntive di specificare le impostazioni necessarie, ad esempio scriptLocation. Per informazioni sulla sintassi, vedere Elemento <proxy> (Impostazioni di rete).

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

5. Salvare il file di configurazione nel percorso originale, quindi riavviare il servizio host di runtime di integrazione self-hosted per rilevare le modifiche.

   Per riavviare il servizio, usare l'applet dei servizi da Pannello di controllo. In alternativa, in Gestione configurazione di Integration Runtime selezionare il pulsante Arresta servizio e quindi selezionare Avvia servizio.

   Se il servizio non viene avviato, è probabile che nel file di configurazione dell'applicazione sia stata aggiunta una sintassi di tag XML non corretta modificata.

È anche necessario verificare che Microsoft Azure sia presente nell'elenco elementi consentiti dell'azienda. È possibile scaricare l'elenco degli indirizzi IP di Azure validi. Gli intervalli IP per ogni cloud, suddivisi in base all'area e ai servizi contrassegnati in tale cloud, sono ora disponibili in MS Download:

• Pubblico: https://www.microsoft.com/download/details.aspx?id=56519
• US Gov: https://www.microsoft.com/download/details.aspx?id=57063
• Germania: https://www.microsoft.com/download/details.aspx?id=57064
• Cina: https://www.microsoft.com/download/details.aspx?id=57062

Configurare le impostazioni del server proxy quando si usa un endpoint privato

Se l'architettura di rete dell'azienda prevede l'uso di endpoint privati per motivi di sicurezza e i criteri dell'azienda non consentono una connessione Internet diretta dalla macchina virtuale che ospita il runtime di integrazione self-hosted all'URL del servizio Azure Data Factory, sarà necessario consentire di ignorare l'URL del servizio Azure Data Factory per avere una connettività completa. La procedura seguente fornisce istruzioni per l'aggiornamento del file diahost.exe.config. È anche necessario ripetere questi passaggi per il file diawp.exe.config.

1. In Esplora file creare una copia sicura di C:\Programmi\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config come backup del file originale.

2. Aprire Blocco note in esecuzione come amministratore.

3. Nel Blocco note, aprire C:\Programmi\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config.

4. Trovare il tag system.net predefinito, come illustrato di seguito:

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

   È quindi possibile aggiungere i dettagli della bypasslist, come illustrato nell'esempio seguente:

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

Possibili sintomi di problemi correlati al firewall e al server proxy

Se vengono visualizzati messaggi di errore come quelli seguenti, il motivo probabile è una configurazione non corretta del firewall o del server proxy. Questa configurazione impedisce al runtime di integrazione self-hosted di connettersi alle pipeline di Data Factory o Synapse per autenticarsi. Per verificare che la configurazione del firewall e del server proxy sia corretta, vedere la sezione precedente.

• Quando si prova a registrare il runtime di integrazione self-hosted, viene visualizzato il messaggio di errore seguente: "Non è stato possibile registrare questo nodo di runtime di integrazione. Verificare la validità della chiave di autenticazione e che il servizio host servizio di integrazione sia in esecuzione nel computer".

• Quando si apre Gestione configurazione di Integration Runtime, lo stato del gateway visualizzato può essere Disconnesso o Connessione. Quando si visualizzano i log eventi di Windows, in Visualizzatore eventi>Registri applicazioni e servizi>Microsoft Integration Runtime vengono visualizzati messaggi di errore simili ai seguenti:

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

Abilitare l'accesso remoto da un Intranet

Se si usa PowerShell per crittografare le credenziali da un computer in rete diverso da quello in cui è stato installato il runtime di integrazione self-hosted, è possibile abilitare l'opzione Accesso remoto da Intranet. Se si esegue PowerShell per crittografare le credenziali su computer in cui è stato installato il runtime di integrazione self-hosted, non è possibile abilitare l'opzione Accesso remoto da Intranet.

Abilitare Accesso remoto da Intranet prima di aggiungere un altro nodo per la disponibilità e la scalabilità elevate.

Quando si esegue la configurazione del runtime di integrazione self-hosted versione 3.3, per impostazione predefinita il programma di installazione del runtime di integrazione self-hosted disabilita l'opzione Accesso remoto da Intranet nel computer in cui il runtime è installato.

Quando si usa un firewall da un partner o da altri utenti, è possibile aprire manualmente la porta 8060 o la porta configurata dall'utente. Se si verificano problemi di firewall durante la configurazione del runtime di integrazione self-hosted, usare il comando seguente per installare il runtime di integrazione self-hosted senza configurare il firewall:

msiexec /q /i IntegrationRuntime.msi NOFIREWALL=1

Se si sceglie di non aprire la porta 8060 nel computer del runtime di integrazione self-hosted, usare meccanismi diversi dall'uso dell'applicazione di impostazione credenziali per configurare le credenziali dell'archivio dati. È possibile ad esempio usare il cmdlet di PowerShell New-AzDataFactoryV2LinkedServiceEncryptCredential.

Porte e firewall

Esistono due firewall da considerare:

• Il firewall aziendale eseguito nel router centrale dell'organizzazione
• Il firewall di Windows configurato come daemon nel computer locale in cui è installato il runtime di integrazione self-hosted

A livello di firewall aziendale è necessario configurare le porte in uscita e i domini seguenti:

Nomi di dominio	Porte in uscita	Descrizione
Cloud pubblico: *.servicebus.windows.net Azure per enti pubblici: *.servicebus.usgovcloudapi.net Cina: *.servicebus.chinacloudapi.cn	443	Richiesta dal runtime di integrazione self-hosted per la creazione interattiva. Non obbligatorio se la creazione interattiva autonoma è abilitata.
Cloud pubblico: {datafactory}.{region}.datafactory.azure.net oppure *.frontend.clouddatahub.net Azure per enti pubblici: {datafactory}.{region}.datafactory.azure.us Cina: {datafactory}.{region}.datafactory.azure.cn	443	Richiesta dal runtime di integrazione self-hosted per connettersi al servizio Data Factory. Per la nuova data factory creata nel cloud pubblico, trovare il nome di dominio completo (FQDN) dalla chiave del runtime di integrazione self-hosted, che è nel formato {data factory}. {region}.datafactory.azure.net. Per la data factory precedente e qualsiasi versione di Azure Synapse Analytics, se non viene visualizzato il nome di dominio completo nella chiave di integrazione self-hosted, usare invece *.frontend.clouddatahub.net.
download.microsoft.com	443	Richiesta dal runtime di integrazione self-hosted per il download degli aggiornamenti. Se l'aggiornamento automatico è stato disabilitato, è possibile ignorare la configurazione di questo dominio.
URL Key Vault	443	Obbligatorio per Azure Key Vault se si archiviano le credenziali in Key Vault.

A livello di Windows Firewall o a livello di computer, queste porte in uscita sono in genere abilitate. In caso contrario, è possibile configurare le porte e i domini in un computer del runtime di integrazione self-hosted.

In base all'origine oppure ai sink, potrebbe essere necessario consentire altri domini e porte in uscita nel firewall aziendale o in Windows Firewall.

Nomi di dominio	Porte in uscita	Descrizione
*.core.windows.net	443	Usata dal runtime di integrazione self-hosted per connettersi all'account di archiviazione di Azure quando si usa la funzionalità di copia temporanea.
*.database.windows.net	1433	Obbligatori solo quando si esegue la copia da o nel database SQL di Azure o in Azure Synapse Analytics, facoltativi in caso contrario. Usare la funzionalità di copia temporanea per copiare i dati nel database SQL o in Azure Synapse Analytics senza aprire la porta 1433.
*.azuredatalakestore.net login.microsoftonline.com/<tenant>/oauth2/token	443	Obbligatori solo quando si esegue la copia da o in Azure Data Lake Store, facoltativi in caso contrario.

Per alcuni database cloud, ad esempio Database SQL di Azure, Azure Data Lake e così via, potrebbe essere necessario consentire gli indirizzi IP del computer del runtime di integrazione self-hosted nella configurazione del firewall.

Creazione interattiva autonoma (anteprima)

Per eseguire azioni di creazione interattiva, ad esempio l'anteprima dei dati e i test di connessione, il runtime di integrazione self-hosted richiede una connessione a Inoltro di Azure. Se la connessione non viene stabilita, esistono due possibili soluzioni per garantire funzionalità senza interruzioni. La prima opzione consiste nell'aggiungere gli endpoint di Inoltro di Azure all'elenco elementi consentiti del firewall Ottenere l'URL di Inoltro di Azure. In alternativa, è possibile abilitare la creazione interattiva autonoma.

Ottenere l'URL di Inoltro di Azure

Un dominio e una porta che devono essere inseriti nell'elenco elementi consenti del firewall sono necessari per la comunicazione con Inoltro di Azure. Il runtime di integrazione self-hosted lo usa per la creazione interattiva, ad esempio per testare la connessione, sfogliare l'elenco di cartelle e l'elenco di tabelle, ottenere uno schema e visualizzare dati in anteprima. Se non si vuole consentire .servicebus.windows.net e si vogliono avere URL più specifici, è possibile visualizzare tutti i nomi di dominio completi richiesti dal runtime di integrazione self-hosted dal portale del servizio.

Ottenere l'URL dell'inoltro di Azure tramite l'interfaccia utente:

Seguire questa procedura:

1. Passare al portale del servizio e selezionare il runtime di integrazione self-hosted.

2. Nella pagina Modifica, selezionare Nodi.

3. Selezionare Visualizza URL del servizio per ottenere tutti i nomi di dominio completi.

   

4. È possibile aggiungere questi nomi di dominio completi all'elenco elementi consentiti delle regole del firewall.

Ottenere l'URL dell'inoltro di Azure tramite script:

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

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

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

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

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

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

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

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

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

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

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

Copiare i dati da un'origine a un sink

Verificare di aver abilitato correttamente le regole del firewall nel firewall aziendale, Windows Firewall nel computer del runtime di integrazione self-hosted e l'archivio dati stesso, per poter consentire al runtime di integrazione self-hosted di connettersi all'origine e al sink. Abilitare le regole per ogni archivio dati interessato dall'operazione di copia.

Per eseguire la copia da un archivio dati locale a un sink di database SQL o a un sink di Azure Synapse Analytics, ad esempio, seguire questa procedura:

1. Consentire comunicazioni TCP in uscita sulla porta 1433 sia per Windows Firewall che per il firewall aziendale.
2. Configurare le impostazioni del firewall del database SQL per aggiungere l'indirizzo IP del computer del runtime di integrazione self-hosted all'elenco degli indirizzi IP consentiti.

Se tutte le origini dati e il sink e il runtime di integrazione self-hosted si trovano nell'ambiente locale, i dati copiati non passeranno al cloud, ma rimarranno rigorosamente all'interno dell'ambiente locale.

Archivio credenziali

Esistono due modi per archiviare le credenziali quando si usa il runtime di integrazione self-hosted:

1. Usare l'Insieme di credenziali delle chiavi di Azure.

Questo è il modo consigliato per archiviare le credenziali in Azure. Il runtime di integrazione self-hosted può ottenere direttamente le credenziali da Azure Key Vault, in modo da evitare problemi di sicurezza potenziali o eventuali problemi di sincronizzazione delle credenziali tra i nodi del runtime di integrazione self-hosted. 2. Archiviare le credenziali in locale.

Verrà eseguito il push delle credenziali nel computer del runtime di integrazione self-hosted e le stesse verranno crittografate. Quando il runtime di integrazione self-hosted viene ripristinato dall'arresto anomalo, è possibile ripristinare le credenziali dal backup eseguito prima o modificare il servizio collegato e consentire nuovamente il push delle credenziali al runtime di integrazione self-hosted. In caso contrario, la pipeline non funziona a causa della mancanza di credenziali durante l'esecuzione tramite il runtime di integrazione self-hosted.

Procedure consigliate per l'installazione

Per installare il runtime di integrazione self-hosted, è possibile scaricare un pacchetto di installazione dell'identità gestita nell'Area download Microsoft. Vedere l'articolo Spostare i dati tra ambienti locali e cloud per le istruzioni dettagliate.

• Configurare una combinazione per il risparmio di energia nel computer host del runtime di integrazione self-hosted in modo che il computer non entri in stato di ibernazione. Se il computer host entra in stato di ibernazione, il runtime di integrazione self-hosted passa in modalità offline.
• Eseguire regolarmente un backup delle credenziali associate al runtime di integrazione self-hosted.
• Per automatizzare le operazioni di configurazione del runtime di integrazione self-hosted, vedere Configurare un runtime di integrazione self-hosted esistente tramite PowerShell.

Considerazioni importanti

Quando si installa un runtime di integrazione self-hosted, tenere presente quanto segue

• Mantenerlo vicino all'origine dati, ma non necessariamente nello stesso computer
• Non installarlo nello stesso computer di Power BI Gateway
• Solo Windows Server (i server di crittografia conformi a FIPS potrebbero causare l'esito negativo dei processi)
• Eseguire la condivisione tra più origini dati
• Eseguire la condivisione tra più data factory

Contenuto correlato

Per istruzioni dettagliate, vedere Esercitazione: Copiare dati da un ambiente locale al cloud.