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 completa per le aziende. Microsoft Fabric copre tutti gli elementi, dallo spostamento dei dati all'analisi scientifica dei dati, all'analisi in tempo reale, alla business intelligence e alla creazione di report. Scopri come avviare gratuitamente una nuova versione di valutazione .

Il runtime di integrazione è l'infrastruttura di calcolo usata dalle pipeline di Azure Data Factory e Synapse per fornire funzionalità di integrazione dei 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 oppure installare il runtime di integrazione self-hosted in due computer locali, uno per ogni data factory o area di lavoro di 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. Tuttavia, la presenza del runtime di integrazione self-hosted vicino all'origine dati riduce il tempo necessario per la connessione del runtime di integrazione self-hosted all'origine dati. È consigliabile 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, il runtime di integrazione self-hosted non è in competizione con l'origine dati per le 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 dispone di due runtime di integrazione self-hosted che servono due data factory, è possibile registrare la stessa origine dati locale con entrambe le data factory.
• Usare un runtime di integrazione self-hosted per supportare l'integrazione dei dati all'interno di 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 in una macchina virtuale IaaS (Infrastructure as a Service) di Azure.
• Le attività potrebbero non riuscire in un runtime di integrazione self-hosted installato in un server Windows per cui è abilitata la crittografia conforme a FIPS. Per risolvere questo problema, sono disponibili due opzioni: archiviare credenziali/valori segreti in un'istanza di Azure Key Vault o disabilitare la crittografia conforme a FIPS nel server. Per disabilitare la crittografia conforme a 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 a FIPS può essere abilitata e verrà usata quando si spostano dati dall'ambiente locale a 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 le 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 l'ambiente locale e il cloud, l'attività usa un runtime di integrazione self-hosted per trasferire i dati tra un'origine dati locale e il cloud.

Ecco un riepilogo generale dei passaggi del flusso di dati per la copia con un runtime di integrazione self-hosted:

1. Uno sviluppatore di dati crea prima di tutto un runtime di integrazione self-hosted in un'area di lavoro di Azure Data Factory o Synapse usando 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 connettersi 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 avviee tramite un canale di controllo che usa una connessione di inoltro di Azure condivisa. Quando è necessario eseguire un processo di attività, il servizio accoda la richiesta insieme alle informazioni sulle credenziali. In questo modo, 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 il polling della coda.

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

Prerequisiti

• Le versioni supportate di Windows sono:
  • Windows 8.1
  • Windows 10
  • Windows 11
  • Windows Server 2012
  • Windows Server 2012 R2
  • 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 versione successiva. Per informazioni dettagliate, vedere Requisiti di sistema di .NET Framework .
• La configurazione minima consigliata per il computer di 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 si iberna, 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 richiede un messaggio.
• Per installare e configurare correttamente il runtime di integrazione self-hosted, è necessario essere un amministratore del computer.
• Le esecuzioni dell'attività di copia vengono eseguite con una frequenza specifica. L'utilizzo del processore e della RAM nel computer segue lo stesso modello con picchi e tempi di inattività. L'utilizzo delle risorse dipende anche in modo elevato dalla quantità di dati spostati. Quando sono in corso più processi di copia, l'utilizzo delle risorse aumenta durante i periodi di picco.
• Le attività potrebbero non riuscire 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 Temlation 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 si esegue nel cloud per enti pubblici, vedere Connessione 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

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  
   
   

Nota

Eseguire il comando PowerShell in Azure per enti pubblici. Vedere Connessione per 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.

Azure Data Factory

1. Nella home page dell'interfaccia utente di Azure Data Factory selezionare la scheda Gestisci nel riquadro più a sinistra.

   

2. Selezionare Runtime di integrazione nel riquadro sinistro, quindi selezionare + Nuovo.

   

3. Nella pagina Configurazione del runtime di integrazione selezionare Azure, Self-Hosted e quindi selezionare Continua.

4. Nella pagina seguente selezionare Self-hosted per creare un runtime di integrazione self-hosted e quindi selezionare Continua.

Azure Synapse

1. Nella home page dell'interfaccia utente di Azure Synapse selezionare la scheda Gestisci nel riquadro più a sinistra.

   

2. Selezionare Runtime di integrazione nel riquadro sinistro, quindi selezionare + Nuovo.

   

3. Nella pagina seguente selezionare Self-hosted per creare un runtime di integrazione self-hosted e quindi selezionare Continua.

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 nell'opzione 2 per configurare manualmente. Le istruzioni seguenti sono basate sull'installazione manuale:

   

   1. Copiare e incollare la chiave di autenticazione. Selezionare Scarica e installa 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 Registra 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 la configurazione del runtime di integrazione self-hosted in una macchina virtuale di Azure usando il modello Crea runtime di integrazione self-host. 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 funzionalità di disponibilità elevata e scalabilità, purché il numero di nodi sia impostato su 2 o superiore.

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

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 viene eseguito in un contenitore.
-dra, -DisableRemoteAccess		Disabilitare l'accesso remoto al nodo corrente. L'accesso remoto è necessario per la configurazione multinodo. 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		Attivare l'aggiornamento automatico del runtime di integrazione self-hosted. Questo comando è solo per Azure Data Factory V1.
-toffau, -TurnOffAutoUpdate		Disattivare 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 della sicurezza per abilitare l'accesso al file system del computer locale.
-EnableLocalFolderPathValidation		Abilitare la convalida della sicurezza per disabilitare l'accesso al file system del computer locale.
-eesp, -EnableExecuteSsisPackage		Abilitare l'esecuzione di pacchetti 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 Scarica, selezionare la versione a 64 bit e selezionare Avanti. La versione a 32 bit non è supportata.

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

4. Nella finestra benvenuto selezionare una lingua e 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 usando 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 runtime di integrazione (self-hosted) di Microsoft Integration Runtime Configuration Manager in esecuzione nel 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.

Nota

Le note sulla versione sono disponibili nella stessa pagina di download del runtime di integrazione Microsoft.

Account del servizio per il runtime di integrazione self-hosted

L'account del servizio di accesso predefinito del runtime di integrazione self-hosted è NT edizione Standard RVICE\DIAHostService. È possibile visualizzarlo in Services -> Integration Runtime Service -> 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 -> Sicurezza Impostazioni - Criteri locali ->> Assegnazione diritti utente -> Accesso come servizio

Icone e notifiche dell'area di notifica

Se si sposta il cursore sull'icona o sul messaggio nell'area di notifica, è possibile visualizzare 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 virtuali o macchine virtuali locali in Azure. Questi computer sono chiamati nodi. È possibile avere fino a quattro nodi associati a un runtime di integrazione self-hosted. I vantaggi della presenza di più nodi in computer locali in cui è installato un gateway per un gateway logico sono:

• Maggiore disponibilità del runtime di integrazione self-hosted in modo che non sia più il singolo punto di errore nella soluzione 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.

È possibile associare più nodi installando il software di runtime di integrazione self-hosted dall'Area download. Registrarlo quindi 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à elevata e la scalabilità, assicurarsi che l'opzione Accesso remoto a Intranet sia abilitata nel primo nodo. A tale scopo, selezionare Microsoft Integration Runtime Configuration Manager> Impostazioni> Remote access to Intranet (Accesso a Intranet).

Considerazioni sulla scalabilità

Aumentare il numero di istanze

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

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 aumentando il numero di processi simultanei che un nodo può eseguire. È anche possibile aumentare le prestazioni quando si verifica il 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 dalla 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 da 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 privata non è sicuro o se si vuole proteggere la comunicazione tra nodi all'interno della rete privata.

Lo spostamento dei 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 questo certificato sia impostato o meno.

Sincronizzazione delle credenziali

Se non si archiviano credenziali o valori segreti in un insieme di credenziali delle chiavi 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 l'installazione iniziale.

Sono disponibili tre opzioni di configurazione:

• Non usare il proxy: il runtime di integrazione self-hosted non usa in modo esplicito alcun proxy per connettersi ai servizi cloud.
• Usa proxy di sistema: il runtime di integrazione self-hosted usa l'impostazione proxy configurata in diahost.exe.config e diawp.exe.config. Se questi file non specificano alcuna configurazione proxy, il runtime di integrazione self-hosted si connette direttamente al servizio cloud senza passare attraverso un proxy.
• Usa proxy personalizzato: configurare l'impostazione proxy HTTP da usare per il runtime di integrazione self-hosted, invece di usare le configurazioni in diahost.exe.config e diawp.exe.config. I valori address e Port sono obbligatori. I valori di Nome utente e Password sono facoltativi, a seconda dell'impostazione 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 del runtime di integrazione viene riavviato automaticamente dopo aver salvato le impostazioni proxy aggiornate.

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

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

È possibile usare lo strumento configuration manager per visualizzare e aggiornare il proxy HTTP.

Nota

Se si configura un server proxy con l'autenticazione NTLM, il servizio host del runtime di integrazione viene eseguito con l'account di dominio. Se in seguito si modifica la password per l'account di dominio, ricordarsi di aggiornare le impostazioni di configurazione per il servizio e riavviare il servizio. A causa di questo requisito, è consigliabile accedere al server proxy usando un account di dominio dedicato che non richiede l'aggiornamento frequente della password.

Configurare le impostazioni del server proxy

Se si seleziona l'opzione Usa proxy di sistema per il proxy HTTP, il runtime di integrazione self-hosted usa le impostazioni proxy in diahost.exe.config e diawp.exe.config. Quando questi file non specificano alcun proxy, il runtime di integrazione self-hosted si connette direttamente al servizio cloud senza passare attraverso un 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. In Blocco note aprire il file di testo C:\Programmi\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config.

4. Trovare il tag system.net predefinito, come illustrato 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 la sintassi, vedere <Elemento proxy> (Network Impostazioni).

   <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. Riavviare quindi il servizio host del runtime di integrazione self-hosted, che rileva 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 assicurarsi che Microsoft Azure sia incluso nell'elenco di elementi consentiti dell'azienda. È possibile scaricare l'elenco di 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'architura di rete dell'azienda prevede l'uso di endpoint privati e 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 la connettività completa. La procedura seguente fornisce istruzioni per l'aggiornamento del file diahost.exe.config. È anche consigliabile 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. In Blocco note aprire C:\Programmi\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config.

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

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

   È quindi possibile aggiungere dettagli 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 per i problemi relativi 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 tenta di registrare il runtime di integrazione self-hosted, viene visualizzato il messaggio di errore seguente: "Failed to register this Integration Runtime node! Verificare che la chiave di autenticazione sia valida e che il servizio host del servizio di integrazione sia in esecuzione in questo computer".

• Quando si apre Gestione configurazione di Integration Runtime, lo stato del gateway visualizzato può essere Disconnesso o Connessione. Quando si visualizzano i registri eventi di Windows, in Visualizzatore eventi> Application and Services Logs>Microsoft Integration Runtime vengono visualizzati messaggi di errore simili al seguente:

  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 una 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 nel computer in cui è stato installato il runtime di integrazione self-hosted, non è possibile abilitare Accesso remoto da Intranet.

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

Quando si esegue il programma di installazione del runtime di integrazione self-hosted versione 3.3 o successiva, per impostazione predefinita, il programma di installazione del runtime di integrazione self-hosted disabilita Accesso remoto da Intranet nel computer del runtime di integrazione self-hosted.

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 verifica un problema del 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 di runtime di integrazione self-hosted, usare meccanismi diversi dall'applicazione Impostazioni credenziali per configurare le credenziali dell'archivio dati. Ad esempio, è possibile usare il cmdlet PowerShell New-AzDataFactoryV2LinkedServiceEncryptCredential .

Porte e firewall

Esistono due firewall da considerare:

• Firewall aziendale eseguito sul router centrale dell'organizzazione
• Windows Firewall 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 è necessario se la creazione interattiva autonoma è abilitata.
Cloud pubblico: {datafactory}.{region}.datafactory.azure.net o *.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 una nuova data factory creata nel cloud pubblico, trovare il nome di dominio completo dalla chiave del runtime di integrazione self-hosted, in formato {datafactory}. {region}.datafactory.azure.net. Per la data factory precedente e 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 evitare di configurare questo dominio.
URL Key Vault	443	Obbligatorio da Azure Key Vault se si archivia la credenziale in Key Vault.

A livello di windows firewall o computer, queste porte in uscita sono normalmente abilitate. In caso contrario, è possibile configurare i domini e le porte in un computer di 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 e ai sink, potrebbe essere necessario consentire domini aggiuntivi 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 e Azure Data Lake, potrebbe essere necessario consentire gli indirizzi IP dei computer di runtime di integrazione self-hosted nella configurazione del firewall.

Nota

Non è giusto installare il runtime di integrazione e il gateway Power BI nello stesso computer, perché principalmente Integration Runtime usa il numero di porta 443, ovvero una delle porte principali usate anche da Power BI Gateway.

Creazione interattiva autonoma (anteprima)

Per eseguire azioni interattive di creazione, ad esempio l'anteprima dei dati e i test di connessione, il runtime di integrazione self-hosted richiede una connessione all'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 di indirizzi consentiti del firewall Get 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 all'inoltro di Azure, il relativo stato verrà contrassegnato come "limitato".

Nota

Anche se la creazione interattiva autonoma è abilitata, tutto il traffico interattivo di creazione 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

L'opzione "Get IP" e "Send log" (Ottieni IP) e "Invia log" non sono supportate quando è abilitata la creazione interattiva autonoma.

Ottenere l'URL dell'inoltro di Azure

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

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 nell'elenco di regole del firewall consentite.

Nota

Per informazioni dettagliate relative al protocollo di connessioni di inoltro di Azure, vedere Protocollo Connessione ions di Inoltro di Azure.

Copiare i dati da un'origine a un sink

Assicurarsi di abilitare correttamente le regole del firewall nel firewall aziendale, windows firewall del computer di runtime di integrazione self-hosted e l'archivio dati stesso. L'abilitazione di queste regole consente al runtime di integrazione self-hosted di connettersi correttamente sia all'origine che al sink. Abilitare le regole per ogni archivio dati interessato dall'operazione di copia.

Ad esempio, per copiare da un archivio dati locale in un sink database SQL o in un sink di Azure Synapse Analytics, seguire questa procedura:

1. Consentire la comunicazione 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 di 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 staging per database SQL e Azure Synapse Analytics. In questo scenario è necessario solo HTTPS (porta 443) per lo spostamento dei dati.

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 Azure Key Vault.

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.

Le credenziali verranno push nel computer del runtime di integrazione self-hosted e crittografate. Quando il runtime di integrazione self-hosted viene ripristinato dall'arresto anomalo, è possibile ripristinare le credenziali da quello di cui si esegue il backup prima o modificare il servizio collegato e consentire 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 di 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

È possibile installare il runtime di integrazione self-hosted scaricando un pacchetto di installazione dell'identità gestita dall'Area download Microsoft. Per istruzioni dettagliate, vedere l'articolo Spostare i dati tra l'ambiente locale e il cloud .

• Configurare una combinazione per il risparmio di energia nel computer host per il runtime di integrazione self-hosted in modo che il computer non si iberni. Se il computer host entra in stato di ibernazione, il runtime di integrazione self-hosted passa in modalità offline.
• Eseguire regolarmente il backup delle credenziali associate al runtime di integrazione self-hosted.
• Per automatizzare le operazioni di installazione 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)
• Condividere tra più origini dati
• Condividere tra più data factory

Contenuto correlato

Per istruzioni dettagliate, vedere Esercitazione: Copiare dati locali nel cloud.