Creare e configurare un runtime di integrazione self-hosted

SI APPLICA A: Azure Data Factory Azure Synapse Analytics

Il runtime di integrazione (IR) è l'infrastruttura di calcolo usata Azure Data Factory e le pipeline di Synapse per offrire 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 Azure Active Directory (Azure AD). 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 o aree di lavoro di Synapse 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.
  • 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, la stessa origine dati locale può essere registrata in 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'Key Vault di Azure 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 da locale a Archiviazione BLOB di Azure come area di gestione temporanea.

Nota

Attualmente il runtime di integrazione self-hosted può essere condiviso solo con più data factory, non può essere condiviso tra 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:

Panoramica generale del flusso di dati

  1. Uno sviluppatore di dati crea prima di tutto un runtime di integrazione self-hosted all'interno di una data factory di Azure o di un'area di lavoro di 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. Azure Data Factory e le pipeline di Synapse comunicano con il runtime di integrazione self-hosted per pianificare e gestire i processi. La comunicazione avvierà 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 a tutte le informazioni sulle credenziali. In questo caso, le credenziali non sono 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 viene ibernato, 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 larga misura 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 nei 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:
    • Visual C++ 2010 Redistributable Pacchetto (x64)
    • Java Runtime (JRE) versione 8 da un provider JRE, ad esempio Adopt OpenJDK. Assicurarsi che la variabile di ambiente JAVA_HOME sia impostata sulla cartella JDK e non solo sulla cartella JRE.

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

  1. È possibile usare Azure PowerShell per questa attività. 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 di PowerShell in Azure per enti pubblici. Vedere Connettersi a 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 l'interfaccia utente Azure Data Factory o Azure Synapse.

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

    Pulsante Gestisci nella home page

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

    Creare un runtime di integrazione

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

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

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 Integration Runtime setup (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 sulla configurazione manuale:

    Configurazione del runtime di integrazione

    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 Integration Runtime (self-hosted) incollare la chiave salvata in precedenza e selezionare Registra.

      Registrare il runtime di integrazione

    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:

    Registrazione completata

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 dispone di funzionalità a disponibilità elevata e scalabilità, purché il numero di nodi sia impostato su 2 o versione successiva.

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\4.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 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 è true 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.
-toffau,
-TurnOffAutoUpdate
Disattivare l'aggiornamento automatico del runtime di integrazione self-hosted.
-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.

Installare e registrare un runtime di integrazione self-hosted dall'Area download di 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 di 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 selezionare 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 Integration Runtime (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 SERVICE\DIAHostService. È possibile visualizzarlo in Servizi -> Integration Runtime Servizio -> Proprietà -> Accesso.

Account del servizio per il runtime di integrazione self-hosted

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

Screenshot dei criteri di sicurezza locali - Assegnazione diritti utente

Screenshot dell'assegnazione dei 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.

Notifiche nell'area di notifica

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 derivanti dalla 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 alla intranet sia abilitata nel primo nodo. A tale scopo, selezionare Microsoft Integration Runtime Configuration Manager>Impostazioni>Accesso remoto 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 i 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 è in overload. Come illustrato nell'immagine seguente, è possibile aumentare la capacità massima di un nodo:

Aumentare il numero di processi simultanei che possono essere eseguiti in un nodo

Requisiti del certificato TLS/SSL

Se si vuole abilitare l'accesso remoto da Intranet con certificato TLS/SSL (Avanzato) 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 nodi.
  • Quando viene usato 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 archivieranno credenziali o valori segreti in un Key Vault 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 consentire il funzionamento di tutti i nodi, 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.

Specificare il proxy

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.

Impostare il proxy

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.
  • Usare il 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.
  • Usare il proxy personalizzato: configurare l'impostazione del proxy HTTP da usare per il runtime di integrazione self-hosted, anziché 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. Selezionare la scheda Settings (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 di gestione configurazione per visualizzare e aggiornare il proxy HTTP.

Visualizzare e aggiornare il proxy

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\4.0\Shared\diahost.exe.config come backup del file originale.

  2. Aprire blocco note in esecuzione come amministratore.

  3. Nel Blocco note aprire il file di testo C:\Programmi\Microsoft Integration Runtime\4.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> (Impostazioni di rete ).

    <proxy autoDetect="true|false|unspecified" bypassonlocal="true|false|unspecified" proxyaddress="uriString" scriptLocation="uriString" usesystemdefault="true|false|unspecified "/>
    
  5. Salvare il file di configurazione nel percorso originale. Riavviare quindi il servizio host del runtime di integrazione self-hosted, che seleziona 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 errata modificata.

Importante

Non dimenticare di aggiornare entrambi i file diahost.exe.config e diawp.exe.config.

È anche necessario assicurarsi che Microsoft Azure si trovi nell'elenco 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 nel cloud sono ora disponibili in MS Download:

Se vengono visualizzati messaggi di errore come quelli seguenti, è probabile che la configurazione del firewall o del server proxy non sia corretta. Questa configurazione impedisce al runtime di integrazione self-hosted di connettersi alle pipeline di Data Factory o Synapse per l'autenticazione. 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 seguente messaggio di errore: "Impossibile registrare questo nodo Integration Runtime. Verificare che la chiave di autenticazione sia valida e che il servizio host del 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>Application and Services Logs>Microsoft Integration Runtime vengono visualizzati messaggi di errore come questo:

    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 l'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 la configurazione 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 l'accesso remoto da Intranet nel computer di 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 New-AzDataFactoryV2LinkedServiceEncryptCredential PowerShell.

Porte e firewall

Esistono due firewall da considerare:

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

Firewall

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.
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 la nuova data factory creata nel cloud pubblico, trovare il nome di dominio completo dalla chiave di Integration Runtime self-hosted che è in formato {datafactory}.{ region}.datafactory.azure.net. Per data factory precedente e analisi di Azure Synapse, 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 dell'insieme di credenziali delle chiavi 443 Richiesto da Azure Key Vault se si archiviano le credenziali in Key Vault.

A livello di Windows Firewall o computer, queste porte in uscita sono normalmente abilitate. Se non sono, è possibile configurare i domini e le porte in un computer di runtime di integrazione self-hosted.

Nota

Poiché attualmente l'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 l'inoltro di Azure. Per la comunicazione con aree di lavoro Azure Data Factory e Synapse, è possibile usare DataFactoryManagement del tag di servizio nella configurazione della regola NSG.

In base all'origine e ai sink, potrebbe essere necessario consentire domini e porte in uscita aggiuntive 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 Azure SQL Database 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 sia Integration Runtime che il gateway Power BI nello stesso computer, perché principalmente Integration Runtime usa il numero di porta 443, che è una delle porte principali usate anche dal gateway di Power BI.

Ottenere l'URL dell'inoltro di Azure

Un dominio e una porta necessari che devono essere inseriti nell'elenco allowlist del firewall è per la comunicazione con l'inoltro di Azure. Il runtime di integrazione self-hosted lo usa per la creazione interattiva, ad esempio la connessione di test, l'elenco delle cartelle di esplorazione e l'elenco di tabelle, ottenere lo schema e visualizzare i dati di anteprima. Se non si vuole consentire .servicebus.windows.net e si vuole avere URL più specifici, è possibile visualizzare tutti gli FQDN necessari dal runtime di integrazione self-hosted dal portale di servizio. A tale scopo, seguire questa procedura:

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

  2. Nella pagina Modifica selezionare Nodi.

  3. Selezionare Visualizza URL del servizio per ottenere tutti gli FQDN.

    URL di inoltro di Azure

  4. È possibile aggiungere questi FQDN nell'elenco consentito delle regole del firewall.

Nota

Per informazioni dettagliate relative al protocollo connessioni di inoltro di Azure, vedere Protocollo connessioni ibride 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 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 a un sink database SQL o un sink di analisi di Azure Synapse, seguire questa procedura:

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

Archivio credenziali

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

  1. Usare Azure Key Vault. Si tratta del modo consigliato per archiviare le credenziali in Azure. Il runtime di integrazione self-hosted può ottenere direttamente le credenziali da Azure Key Vault che può evitare altamente alcuni potenziali problemi di sicurezza o eventuali problemi di sincronizzazione delle credenziali tra nodi di 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 quella 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 runtime di integrazione self-hosted.

Nota

Se si preferisce archiviare le credenziali in locale, è necessario inserire il dominio per la creazione interattiva nell'elenco allowlist del firewall e aprire la porta. Questo canale è anche per il runtime di integrazione self-hosted per 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 da Microsoft Download Center. Per istruzioni dettagliate, vedere l'articolo Spostare i dati tra locale e cloud .

  • Configurare un piano di alimentazione nel computer host per il runtime di integrazione self-hosted in modo che il computer non venga ibernato. 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 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 errori nei processi)
  • Condividere tra più origini dati
  • Condividere tra più data factory

Passaggi successivi

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