Creare e configurare un runtime di integrazione self-hosted
SI APPLICA A: 
Azure Data Factory Azure Synapse Analytics
Suggerimento
Provare Data Factory in Microsoft Fabric, una soluzione di analisi all-in-one per le aziende. Microsoft Fabric copre tutto, dallo spostamento dati al data science, all'analisi in tempo reale, alla business intelligence e alla creazione di report. Vedere le informazioni su come iniziare una nuova prova gratuita!
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.
Nota
È consigliabile usare il modulo Azure Az PowerShell per interagire con Azure. Per iniziare, vedere Installare Azure PowerShell. Per informazioni su come eseguire la migrazione al modulo AZ PowerShell, vedere Eseguire la migrazione di Azure PowerShell da AzureRM ad Az.
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.
Nota
Attualmente il runtime di integrazione self-hosted può essere condiviso solo con più data factory; non può essere condiviso tra più aree di lavoro di Synapse o tra data factory e area di lavoro Synapse.
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:
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.
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.
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.
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.
Nota
Se l'esecuzione avviene nel cloud per enti pubblici, vedere Connettersi al cloud per enti pubblici.
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
Per questa attività è possibile usare Azure PowerShell. Ecco un esempio:
Set-AzDataFactoryV2IntegrationRuntime -ResourceGroupName $resourceGroupName -DataFactoryName $dataFactoryName -Name $selfHostedIntegrationRuntimeName -Type SelfHosted -Description "selfhosted IR description"Scaricare e installare il runtime di integrazione self-hosted in un computer locale.
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
Nota
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.
Nella pagina iniziale dell'interfaccia utente di Azure Data Factory selezionare la scheda Gestisci nel riquadro all'estrema sinistra.
Selezionare Runtime di integrazione nel riquadro sinistro, quindi selezionare + Nuovo.
Nella pagina Configurazione del runtime di integrazione, selezionare Azure e quindi Continua.
Nella pagina successiva, selezionare Self-hosted per creare un runtime di integrazione self-hosted, quindi selezionare Continua.
Configurare un runtime di integrazione self-hosted tramite l'interfaccia utente
Immettere un nome per il runtime di integrazione e selezionare Crea.
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:
Copiare e incollare la chiave di autenticazione. Selezionare Scaricare e installare il runtime di integrazione.
Scaricare il runtime di integrazione self-hosted in un computer Windows locale. Eseguire il programma di installazione.
Nella pagina Registrare runtime di integrazione (self-hosted), incollare la chiave salvata in precedenza e selezionare Registra.
Nella pagina Nuovo nodo di Integration Runtime (self-hosted) fare clic su Fine.
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
Accedere alla pagina di download di Microsoft Integration Runtime.
Selezionare Scaricare, selezionare la versione a 64 bit e selezionare Successivo. La versione a 32 bit non è supportata.
Eseguire il file MSI direttamente oppure salvarlo sul disco rigido ed eseguirlo.
Nella finestra di benvenuto selezionare una lingua e quindi selezionare Avanti.
Accettare le condizioni di licenza software Microsoft e quindi selezionare Avanti.
Selezionare la cartella in cui installare il runtime di integrazione self-hosted e quindi selezionare Avanti.
Nella pagina Pronto per l'installazione, seleziona Installa.
Selezionare Fine per completare l'installazione.
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 $selfHostedIntegrationRuntimeNameNella finestra Registra Integration Runtime (self-hosted) di Gestione configurazione di Microsoft Integration Runtime in esecuzione sul computer, seguire questa procedura:
Incollare la chiave di autenticazione nell'area di testo.
Facoltativamente, selezionare Mostra chiave di autenticazione per visualizzare il testo della chiave.
Selezionare Registra.
Nota
Le note sulla versione sono disponibili nella stessa pagina di download di Microsoft Integration Runtime.
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.
Nota
Non è necessario creare un nuovo runtime di integrazione self-hosted per associare ogni nodo. È possibile installare il runtime di integrazione self-hosted in un altro computer e registrarlo con la stessa chiave di autenticazione.
Nota
Prima di aggiungere un altro nodo per la disponibilità e la scalabilità elevate, verificare che l'opzione Accesso remoto all'Intranet sia abilitata sul primo nodo. A tale scopo, selezionare Gestione configurazione di Microsoft Integration Runtime>Impostazioni>Accesso remoto all'Intranet.
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:
- Scaricare la configurazione SHIR dal portale Azure Data Factory.
- Eseguire il programma di installazione sul nodo da aggiungere al cluster.
- 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.
Nota
Questo certificato viene usato:
- Per crittografare le porte in un nodo del runtime di integrazione self-hosted.
- Per la comunicazione da nodo a nodo per la sincronizzazione dello stato, che include la sincronizzazione delle credenziali dei servizi collegati tra i nodi.
- Quando si usa un cmdlet di PowerShell per le impostazioni delle credenziali del servizio collegato dall'interno di una rete locale.
È consigliabile usare questo certificato se l'ambiente di rete privato non è protetto o se si vuole proteggere la comunicazione tra nodi all'interno della rete privata.
Lo spostamento dati in transito da un runtime di integrazione self-hosted ad altri archivi dati avviene sempre all'interno di un canale crittografato, indipendentemente dal fatto che il certificato sia stato impostato o meno.
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.
- Aprire Gestione configurazione di Microsoft Integration Runtime.
- Seleziona la scheda Impostazioni.
- Da Proxy HTTP, selezionare il collegamento Modifica per aprire la finestra di dialogo Imposta proxy HTTP.
- 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.
Nota
Se si configura un server proxy con autenticazione NTLM, il servizio host di runtime di integrazione viene eseguito nell'account di dominio. Se in un secondo momento si modifica la password per l'account di dominio, aggiornare le impostazioni di configurazione per il servizio e riavviarlo. Per questo requisito, si consiglia di accedere al server proxy usando un account di dominio dedicato che non richieda l'aggiornamento frequente della password.
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:
In Esplora file creare una copia sicura di C:\Programmi\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config come backup del file originale.
Aprire Blocco note in esecuzione come amministratore.
Nel Blocco note, aprire il file di testo C:\Programmi\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config.
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 "/>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.
Importante
Non dimenticare di aggiornare entrambi i file diahost.exe.config e diawp.exe.config.
È 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.
In Esplora file creare una copia sicura di C:\Programmi\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config come backup del file originale.
Aprire Blocco note in esecuzione come amministratore.
Nel Blocco note, aprire C:\Programmi\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config.
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.netoppure *.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.
Nota
Poiché attualmente Inoltro di Azure non supporta il tag del servizio, è necessario usare il tag del servizio AzureCloud o Internet nelle regole del gruppo di sicurezza di rete per la comunicazione con Inoltro di Azure. Per la comunicazione con le aree di lavoro di Azure Data Factory e Synapse, è possibile usare il tag del servizio DataFactoryManagement nella configurazione della regola del gruppo di sicurezza di rete.
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.netlogin.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.
Nota
Non è corretto installare il runtime di integrazione e Power BI gateway nello stesso computer, perché il runtime di integrazione usa principalmente il numero di porta 443, ovvero una delle porte principali usate anche da Power BI Gateway.
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.
Nota
Se il runtime di integrazione self-hosted non riesce a stabilire una connessione a Inoltro di Azure, il relativo stato verrà contrassegnato come "limitato".
Nota
Anche se la creazione interattiva autonoma è abilitata, tutto il traffico di creazione interattiva verrà instradato esclusivamente tramite questa funzionalità, ignorando Inoltro di Azure. Il traffico verrà reindirizzato a Inoltro di Azure solo dopo aver scelto di disabilitare questa funzionalità.
Nota
"Ottieni IP" e "Invia log" non sono supportate quando è abilitata 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:
Passare al portale del servizio e selezionare il runtime di integrazione self-hosted.
Nella pagina Modifica, selezionare Nodi.
Selezionare Visualizza URL del servizio per ottenere tutti i nomi di dominio completi.
È possibile aggiungere questi nomi di dominio completi all'elenco elementi consentiti delle regole del firewall.
Nota
Per informazioni dettagliate relative al protocollo di connessioni di Inoltro di Azure, vedere Protocollo per le connessioni ibride di inoltro di Azure.
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 $synapseRresourceGroupName `
--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:
- Consentire comunicazioni TCP in uscita sulla porta 1433 sia per Windows Firewall che per il firewall aziendale.
- 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.
Nota
Se il firewall non consente la porta in uscita 1433, il runtime di integrazione self-hosted non può accedere direttamente al database SQL. In questo caso è possibile usare una copia di gestione temporanea nel database SQL e in Azure Synapse Analytics. Per lo spostamento dei dati, in questo scenario è necessario solo il protocollo HTTPS (porta 443).
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:
- 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.
Nota
Se si preferisce archiviare le credenziali in locale, è necessario inserire il dominio per la creazione interattiva nell'elenco elementi consentiti del firewall e aprire la porta. Questo canale consente anche al runtime di integrazione self-hosted di ottenere le credenziali. Per il dominio e la porta necessari per la creazione interattiva, vedere Porte e firewall
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.