Condividi tramite

Creare e gestire un runtime di integrazione self-hosted

  • Articolo

Il runtime di integrazione (IR) è l'infrastruttura di calcolo usata da Microsoft Purview per alimentare l'analisi dei dati in ambienti di rete diversi.

È possibile usare un runtime di integrazione self-hosted (SHIR) per analizzare l'origine dati in una rete locale o in una rete virtuale. L'installazione di un runtime di integrazione self-hosted richiede una macchina locale o una macchina virtuale all'interno di una rete privata.

Questo articolo illustra sia la configurazione di un runtime di integrazione self-hosted che la risoluzione dei problemi e la gestione.

Importante

Scaricare il runtime di integrazione self-hosted da: Microsoft Integration Runtime.

Argomento Sezione
Configurare un nuovo runtime di integrazione self-hosted Requisiti del computer
I requisiti del computer specifici dell'origine sono elencati in prerequisiti in ogni articolo di origine
Guida alla configurazione
Rete Requisiti di rete
Server proxy
Endpoint privati
Risolvere i problemi relativi a proxy e firewall
Risolvere i problemi di connettività
Gestione Generale

Nota

Il Integration Runtime Microsoft Purview non può essere condiviso con un Azure Synapse Analytics o Azure Data Factory Integration Runtime nello stesso computer. Deve essere installato in un computer separato.

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.

  • La modalità FIPS non è attualmente supportata per i computer SHIR.

Importante

L'analisi di alcune origini dati richiede una configurazione aggiuntiva nel computer di runtime di integrazione self-hosted. Ad esempio, JDK, Visual C++ Redistributable o driver specifico. Per informazioni sull'origine, vedere ogni articolo di origine per informazioni dettagliate sui prerequisiti. Tutti i requisiti verranno elencati nella sezione Prerequisiti .

  • Per aggiungere e gestire un SHIR in Microsoft Purview, sono necessarie le autorizzazioni di amministratore dell'origine dati in Microsoft Purview.

  • 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 8 core, 28 GB di RAM e 80 GB di spazio disponibile sul disco rigido. L'analisi di alcune origini dati potrebbe richiedere una specifica del computer più elevata in base al proprio scenario. Controllare anche i prerequisiti nell'articolo del connettore corrispondente.

  • Se il computer host viene ibernato, il runtime di integrazione self-hosted non risponde alle richieste di dati. Configurare una combinazione per il risparmio di energia appropriata 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.

  • È necessario essere un amministratore nel computer per installare e configurare correttamente il runtime di integrazione self-hosted.

  • Le esecuzioni di analisi vengono eseguite con una frequenza specifica in base alla pianificazione configurata. 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 analizzati. Quando sono in corso più processi di analisi, l'utilizzo delle risorse aumenta durante le ore di punta.

Importante

Se si usa il runtime di integrazione Self-Hosted per analizzare i file Parquet, è necessario installare JRE 8 a 64 bit (Java Runtime Environment) o OpenJDK nel computer a runtime di integrazione. Per una guida all'installazione, vedere la sezione Java Runtime Environment (Ambiente di runtime Java) nella parte inferiore della pagina .

Considerazioni sull'uso di un runtime di integrazione self-hosted

  • È possibile usare un singolo runtime di integrazione self-hosted per l'analisi di più origini dati.
  • È possibile installare una sola istanza del runtime di integrazione self-hosted in qualsiasi singolo computer. Se si dispone di due account Microsoft Purview che devono analizzare le origini dati locali, installare il runtime di integrazione self-hosted in due computer, uno per ogni account Microsoft Purview.
  • Il runtime di integrazione self-hosted non deve trovarsi nello stesso computer dell'origine dati, a meno che non venga specificato come prerequisito nel rispettivo articolo di origine. La prossimità del runtime di integrazione self-hosted all'origine dati riduce il tempo necessario per la connessione del runtime di integrazione self-hosted all'origine dati.

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

Nota

Per aggiungere o gestire un SHIR in Microsoft Purview, sono necessarie le autorizzazioni di amministratore dell'origine dati in Microsoft Purview.

  1. Nella home page del portale di governance di Microsoft Purview selezionare Mappa dati nel riquadro di spostamento a sinistra.

  2. In Origini e analisi nel riquadro sinistro selezionare Runtime di integrazione e quindi selezionare + Nuovo.

    Selezionare il runtime di integrazione.

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

    Creare un nuovo SHIR.

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

  5. Nella pagina Integration Runtime impostazioni seguire la procedura descritta nella sezione Configurazione manuale. Sarà necessario scaricare il runtime di integrazione dal sito di download in una macchina virtuale o in un computer in cui si intende eseguirlo.

    get key

    • Copiare e incollare la chiave di autenticazione.

    • Scaricare il runtime di integrazione self-hosted da Microsoft Integration Runtime in un computer Windows locale. Eseguire il programma di installazione. Sono supportate versioni self-hosted del runtime di integrazione, ad esempio 5.4.7803.1 e 5.6.7795.1.

    • Nella pagina Registra Integration Runtime (self-hosted) incollare una delle due chiavi salvate in precedenza e selezionare Registra.

      tasto di input.

    • Nella pagina Nuovo nodo Integration Runtime (self-hosted) selezionare Fine.

  6. Dopo aver registrato correttamente il runtime di integrazione self-hosted, viene visualizzata la finestra seguente:

    registrato correttamente.

È possibile registrare più nodi per un runtime di integrazione self-hosted usando la stessa chiave. Per altre informazioni, vedere Disponibilità elevata e scalabilità.

Gestire un runtime di integrazione self-hosted

È possibile modificare un runtime di integrazione self-hosted passando a Runtime di integrazione nel portale di governance di Microsoft Purview, passando il puntatore del mouse sul runtime di integrazione e quindi selezionando il pulsante Modifica .

modificare i dettagli del runtime di integrazione.

È possibile eliminare un runtime di integrazione self-hosted passando a Runtime di integrazione, passando il puntatore del mouse sul runtime di integrazione e quindi selezionando il pulsante Elimina .

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

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 Integration Runtime -> 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 -> Accedere come servizio

Screenshot dei criteri di sicurezza locali - Assegnazione diritti utente

Screenshot dell'assegnazione dei diritti utente di Accesso come servizio

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 di avere più nodi sono:

  • Disponibilità maggiore del runtime di integrazione self-hosted in modo che non sia più il singolo punto di errore per l'analisi. Questa disponibilità consente di garantire la continuità quando si usano fino a quattro nodi.
  • Eseguire più analisi simultanee. Ogni runtime di integrazione self-hosted può consentire molte esecuzioni di analisi contemporaneamente, determinate automaticamente in base alla CPU/memoria del computer. È possibile installare più nodi se è necessaria una maggiore concorrenza.
  • Quando si analizzano origini come BLOB di Azure, Azure Data Lake Storage Gen1, Azure Data Lake Storage Gen2 e File di Azure, ogni esecuzione di analisi può sfruttare tutti questi nodi per migliorare le prestazioni dell'analisi. Per altre origini, l'analisi verrà eseguita in uno dei nodi.

È possibile associare più nodi installando il software di runtime di integrazione self-hosted dall'Area download. Registrarlo quindi usando 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>Accesso remoto alla Rete Intranet.

Requisiti di rete

Il computer di runtime di integrazione self-hosted deve connettersi a diverse risorse per funzionare correttamente:

  • Servizi Microsoft Purview usati per gestire il runtime di integrazione self-hosted.
  • Origini dati da analizzare usando il runtime di integrazione self-hosted.
  • Se l'account è stato creato prima del 15 dicembre 2023, il runtime di integrazione deve essere in grado di connettersi all'account di archiviazione gestito creato da Microsoft Purview. Se l'account viene creato dopo questa data (o distribuito con la versione API 2023-05-01-preview in poi), viene usato un account di archiviazione di inserimento. Microsoft Purview usa questa risorsa per inserire i risultati dell'analisi, tra molte altre cose.

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

Di seguito sono riportati i domini e le porte in uscita che è necessario consentire nei firewall aziendali e windows/computer.

Consiglio

  • Per i domini elencati con "<managed_storage_account>", aggiungere il nome delle risorse gestite associate all'account Microsoft Purview. È possibile trovarli da portale di Azure-> account Microsoft Purview ->Impostazioni ->Risorse gestite scheda.
  • Se l'account non dispone di un account di archiviazione gestito, usa l'archiviazione di inserimento. Fare riferimento ai domini con "<ingestion_storage_account>" nella tabella seguente. È possibile trovare le informazioni di archiviazione da portale di Azure ->Properties ->Ingestion storage ID. Per controllare i dettagli dell'endpoint, passare alla proprietà Overview ->JSON View -> "primaryEndpoint".
Nomi di dominio Porte in uscita Descrizione
Cloud pubblico: *.frontend.clouddatahub.net
Azure per enti pubblici:*.frontend.datamovement.azure.us
Cina: *.frontend.datamovement.azure.cn		 443 Necessario per connettersi al servizio Microsoft Purview. Attualmente è necessario il carattere jolly perché non è disponibile alcuna risorsa dedicata.
Cloud pubblico: *.servicebus.windows.net
Azure per enti pubblici:*.servicebus.usgovcloudapi.net
Cina: *.servicebus.chinacloudapi.cn		 443 Obbligatorio per la configurazione dell'analisi nel portale di governance di Microsoft Purview. Questo endpoint viene usato per la creazione interattiva dall'interfaccia utente, ad esempio per testare la connessione, esplorare l'elenco di cartelle e l'elenco di tabelle per l'analisi dell'ambito. Per evitare l'uso di caratteri jolly, vedere Ottenere l'URL dell'inoltro di Azure.
Cloud pubblico: <tenantId>-api.purview-service.microsoft.com
Azure per enti pubblici:<tenantId>-api.purview-service.microsoft.us
Cina: <tenantId>-api.purview-service.microsoft.cn		 443 Necessario per connettersi al servizio Microsoft Purview. Se si usano endpoint privati Purview, questo endpoint è coperto dall'endpoint privato della piattaforma.
Cloud pubblico: <purview_account>.purview.azure.com
Azure per enti pubblici:<purview-account>.purview.azure.us
Cina: <purview_account>.purview.azure.cn		 443 Necessario per connettersi al servizio Microsoft Purview. Se si usano endpoint privati Purview, questo endpoint è coperto dall'endpoint privato dell'account.
Cloud pubblico: <managed_storage_account>.blob.core.windows.net o <ingestion_storage_account>.*.blob.storage.azure.net
Azure per enti pubblici: <managed_storage_account>. blob.core.usgovcloudapi.net o<ingestion_storage_account>. blob.core.usgovcloudapi.net
Cina: <managed_storage_account>.blob.core.chinacloudapi.cno <ingestion_storage_account>.blob.core.chinacloudapi.cn		 443 Necessario per connettersi all'account di archiviazione BLOB di Azure gestito da Microsoft Purview. Se si usano gli endpoint privati di Purview, questo endpoint è coperto dall'endpoint privato di inserimento.
Cloud pubblico: <managed_storage_account>.queue.core.windows.net o <ingestion_storage_account>.*.queue.storage.azure.net
Azure per enti pubblici: <managed_storage_account>. queue.core.usgovcloudapi.net o<ingestion_storage_account>. queue.core.usgovcloudapi.net
Cina: <managed_storage_account>.queue.core.chinacloudapi.cno <ingestion_storage_account>.queue.core.chinacloudapi.cn		 443 Necessario per connettersi all'account di archiviazione code di Azure gestito da Microsoft Purview. Se si usano gli endpoint privati di Purview, questo endpoint è coperto dall'endpoint privato di inserimento.
download.microsoft.com 443 Necessario per scaricare gli aggiornamenti del runtime di integrazione self-hosted. Se l'aggiornamento automatico è stato disabilitato, è possibile ignorare la configurazione di questo dominio.
Cloud pubblico: login.windows.net e login.microsoftonline.com
Azure per enti pubblici:login.microsoftonline.us
Cina: login.partner.microsoftonline.cn		 443 Necessario per accedere al Microsoft Entra ID.

Nota

Poiché attualmente Inoltro di Azure non supporta il tag di servizio, è necessario usare il tag di servizio AzureCloud o Internet nelle regole del gruppo di sicurezza di rete per la comunicazione con Inoltro di Azure.

A seconda delle origini da analizzare, è anche necessario consentire altri domini e porte in uscita per altre origini di Azure o esterne. Di seguito sono riportati alcuni esempi:

Nomi di dominio Porte in uscita Descrizione
<your_storage_account>.dfs.core.windows.net 443 Durante l'analisi di Azure Data Lake Store Gen 2.
<your_storage_account>.blob.core.windows.net 443 Durante l'analisi dell'archiviazione BLOB di Azure.
<your_sql_server>.database.windows.net 1433 Durante l'analisi Azure SQL database.
*.powerbi.com e *.analysis.windows.net 443 Durante l'analisi del tenant di Power BI.
<your_ADLS_account>.azuredatalakestore.net 443 Durante l'analisi di Azure Data Lake Store Gen 1.
Vari domini Dipendente Domini e porte per qualsiasi altra origine che verrà analizzata da SHIR.

Per alcuni archivi dati cloud, ad esempio Azure SQL Database e Archiviazione di Azure, potrebbe essere necessario consentire l'indirizzo IP del computer di runtime di integrazione self-hosted nella configurazione del firewall oppure è possibile creare un endpoint privato del servizio nella rete del runtime di integrazione self-hosted.

Importante

Nella maggior parte degli ambienti, è anche necessario assicurarsi che il DNS sia configurato correttamente. Per confermare, è possibile usare nslookup dal computer SHIR per controllare la connettività a ognuno dei domini. Ogni nslookup deve restituire l'IP della risorsa. Se si usano endpoint privati, l'IP privato deve essere restituito e non l'IP pubblico. Se non viene restituito alcun indirizzo IP o se quando si usano endpoint privati viene restituito l'INDIRIZZO IP pubblico, è necessario indirizzare l'associazione DNS/rete virtuale o il peering di endpoint privato/rete virtuale.

Ottenere l'URL dell'inoltro di Azure

Un dominio e una porta necessari che devono essere inseriti nell'elenco consentiti del firewall è per la comunicazione con Inoltro di Azure. Il runtime di integrazione self-hosted lo usa per la creazione interattiva, ad esempio la connessione di test e l'elenco cartelle/tabelle di esplorazione. Se non si vuole consentire .servicebus.windows.net e si desidera avere URL più specifici, è possibile visualizzare tutti gli FQDN richiesti dal runtime di integrazione self-hosted. attenersi alla seguente procedura:

  1. Passare al portale di governance di Microsoft Purview -> Mapping dei dati -> Runtime di integrazione e modificare il runtime di integrazione self-hosted.

  2. Nella pagina Modifica selezionare la scheda Nodi .

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

    Screenshot che mostra come ottenere gli URL di inoltro di Azure per un runtime di integrazione.

  4. È possibile aggiungere questi FQDN nell'elenco di regole del firewall consentiti.

Nota

Per i dettagli relativi al protocollo di connessioni di inoltro di Azure, vedere Protocollo di Connections ibrido di Inoltro di Azure.

Considerazioni sul server proxy

Se l'ambiente di rete aziendale usa 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 o dopo la registrazione.

Specificare il proxy

Quando è configurato, il runtime di integrazione self-hosted usa il server proxy per connettersi ai servizi che usano il protocollo HTTP o HTTPS. Questo è il motivo per cui si seleziona Modifica collegamento durante l'installazione iniziale.

Impostare il proxy

Microsoft Purview supporta due 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.
  • Usare il proxy di sistema: il runtime di integrazione self-hosted usa l'impostazione del proxy configurata nei file di configurazione del file eseguibile. Se in questi file non viene specificato alcun proxy, il runtime di integrazione self-hosted si connette direttamente ai servizi senza passare attraverso un proxy.
  • Usa proxy personalizzato: configurare l'impostazione del proxy HTTP da usare per il runtime di integrazione self-hosted, anziché usare 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.

Nota

La connessione alle origini dati tramite proxy non è supportata per i connettori diversi dalle origini dati di Azure e da Power BI.

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 Microsoft Integration Runtime Configuration Manager.
  2. Selezionare la scheda Impostazioni.
  3. In Proxy HTTP selezionare il collegamento Modifica per aprire la finestra di dialogo Imposta proxy HTTP .
  4. Seleziona Avanti. Viene quindi visualizzato un avviso che richiede l'autorizzazione per salvare l'impostazione del proxy e riavviare il servizio host del runtime di integrazione.

Nota

Se si configura un server proxy con 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.

Se si usa il proxy di sistema, assicurarsi che il server proxy consenta il traffico in uscita verso le regole di rete.

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 nei quattro file seguenti nel percorso C:\Programmi\Microsoft Integration Runtime\5.0\ per eseguire operazioni diverse:

  • .\Shared\diahost.exe.config
  • .\Shared\diawp.exe.config
  • .\Gateway\DataScan\Microsoft.DataMap.Agent.exe.config
  • .\Gateway\DataScan\DataTransfer\Microsoft.DataMap.Agent.Connectors.Azure.DataFactory.ServiceHost.exe.config

Quando non viene specificato alcun proxy in questi file, il runtime di integrazione self-hosted si connette direttamente ai servizi senza passare attraverso un proxy.

La procedura seguente fornisce istruzioni per l'aggiornamento del file diahost.exe.config .

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

  2. Aprire Blocco note in esecuzione come amministratore.

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

  4. Trovare il tag 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>
    <proxy bypassonlocal="true" proxyaddress="<your proxy server e.g. http://proxy.domain.org:8888/>" />
  </defaultProxy>
</system.net>

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

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

  5. Salvare il file di configurazione nel percorso originale.

Ripetere la stessa procedura per aggiornare i filediawp.exe.config e Microsoft.DataMap.Agent.exe.config .

Passare quindi al percorso C:\Programmi\Microsoft Integration Runtime\5.0\Gateway\DataScan\DataTransfer, creare un file denominato "Microsoft.DataMap.Agent.Connectors.Azure.DataFactory.ServiceHost.exe.config" e configurare l'impostazione del proxy come indicato di seguito. È anche possibile estendere le impostazioni come descritto in precedenza.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.net>
    <defaultProxy>
      <proxy bypassonlocal="true" proxyaddress="<your proxy server e.g. http://proxy.domain.org:8888/>" />
    </defaultProxy>
  </system.net>
</configuration>

Il traffico locale deve essere escluso dal proxy, ad esempio se l'account Microsoft Purview si trova dietro gli endpoint privati. In questi casi, aggiornare i quattro file seguenti nel percorso per includere l'elenco di bypass C:\Programmi\Microsoft Integration Runtime\5.0\ con l'elenco di bypass obbligatorio:

  • .\Shared\diahost.exe.config
  • .\Shared\diawp.exe.config
  • .\Gateway\DataScan\Microsoft.DataMap.Agent.exe.config
  • .\Gateway\DataScan\DataTransfer\Microsoft.DataMap.Agent.Connectors.Azure.DataFactory.ServiceHost.exe.config

Esempio per l'elenco di bypass per l'analisi di un database Azure SQL e dell'archiviazione ADLS gen 2:

 <system.net>
   <defaultProxy>
     <bypasslist>
       <add address="scaneastus4123.blob.core.windows.net" />
       <add address="scaneastus4123.queue.core.windows.net" />
       <add address="Atlas-abc12345-1234-abcd-a73c-394243a566fa.servicebus.windows.net" />
       <add address="contosopurview123.purview.azure.com" />
       <add address="contososqlsrv123.database.windows.net" />
       <add address="contosoadls123.dfs.core.windows.net" />
       <add address="contosoakv123.vault.azure.net" />
     </bypasslist>
     <proxy proxyaddress=http://proxy.domain.org:8888 bypassonlocal="True" />
   </defaultProxy>
 </system.net>

Riavviare il servizio host del runtime di integrazione self-hosted, che raccoglie le modifiche. Per riavviare il servizio, usare l'applet dei servizi da Pannello di controllo. In alternativa, in Integration Runtime Configuration Manager selezionare il pulsante Arresta servizio e quindi selezionare Avvia servizio. Se il servizio non viene avviato, è probabile che la sintassi del tag XML non sia corretta nel file di configurazione dell'applicazione modificato.

Importante

Non dimenticare di aggiornare tutti e quattro i file indicati in precedenza.

È anche necessario assicurarsi che Microsoft Azure sia incluso nell'elenco di utenti consentiti dell'azienda. È possibile scaricare l'elenco di indirizzi IP di Azure validi. Gli intervalli IP per ogni cloud, suddivisi per area e per i servizi contrassegnati in tale 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 ai servizi Microsoft Purview. Per assicurarsi che il firewall e il server proxy siano configurati correttamente, fare riferimento alla sezione precedente.

  • Quando si prova a registrare il runtime di integrazione self-hosted, viene visualizzato il messaggio di errore seguente: "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 Integration Runtime Configuration Manager, viene visualizzato lo stato 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 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)

Installazione dell'ambiente di runtime Java

Se si analizzano i file Parquet usando il runtime di integrazione self-hosted con Microsoft Purview, sarà necessario installare Java Runtime Environment o OpenJDK nel computer a runtime di integrazione self-hosted.

Quando si analizzano i file Parquet usando il runtime di integrazione self-hosted, il servizio individua il runtime Java controllando innanzitutto il Registro di sistema (HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\{Current Version}\JavaHome) per individuare JRE, se non viene trovato, in secondo luogo verificando la presenza di OpenJDK nella variabile JAVA_HOME di sistema. È possibile impostare JAVA_HOME in Impostazioni di sistema, Variabili di ambiente nel computer. Creare o modificare la variabile JAVA_HOME in modo che punti alla jre Java nel computer. Ad esempio: C:\Program Files\Java\jdk1.8\jre

  • Per usare JRE: il runtime di integrazione a 64 bit richiede JRE a 64 bit. È possibile trovarlo da qui.
  • Per usare OpenJDK: è supportato dalla versione 3.13 del runtime di integrazione. Creare il pacchetto del jvm.dll con tutti gli altri assembly necessari di OpenJDK in un computer a runtime di integrazione self-hosted e impostare la variabile di ambiente di sistema JAVA_HOME di conseguenza.

Come controllare la versione del runtime di integrazione self-hosted

È possibile controllare la versione del runtime di integrazione self-hosted nel portale di governance di Microsoft Purview -> Mappa dati -> Runtime di integrazione:

Screenshot che mostra la versione nel portale di governance di Microsoft Purview.

È anche possibile controllare la versione nella scheda Guida del client> di runtime di integrazione self-hosted.

Aggiornamento automatico Integration Runtime self-hosted

L'aggiornamento automatico è abilitato per impostazione predefinita quando si installa un runtime di integrazione self-hosted. Sono disponibili due opzioni per gestire la versione del runtime di integrazione self-hosted: aggiornamento automatico o gestione manuale. In genere, Microsoft Purview rilascia due nuove versioni del runtime di integrazione self-hosted ogni mese, che include la nuova versione delle funzionalità, la correzione di bug o il miglioramento. È quindi consigliabile che gli utenti si aggiornino alla versione più recente per ottenere la funzionalità e il miglioramento più recenti.

Il runtime di integrazione self-hosted viene aggiornato automaticamente alla versione più recente. Quando la nuova versione è disponibile mentre non è ancora pianificata per l'istanza, è anche possibile attivare l'aggiornamento dal portale.

Screenshot del controllo della versione del runtime di integrazione self-hosted e dell'aggiornamento del trigger.

Nota

Se si dispone di più nodi di runtime di integrazione self-hosted, non si verificano tempi di inattività durante l'aggiornamento automatico. L'aggiornamento automatico viene eseguito prima in un nodo mentre altri lavorano sulle attività. Al termine dell'aggiornamento, il primo nodo assumerà il controllo delle attività rimanenti durante l'aggiornamento di altri nodi. Se si dispone di un solo nodo di runtime di integrazione self-hosted, il tempo di inattività si verifica durante l'aggiornamento automatico.

Aggiornamento automatico della versione rispetto alla versione più recente

Per garantire la stabilità del runtime di integrazione self-hosted, anche se vengono rilasciate due versioni, viene eseguito il push di una sola versione ogni mese. Quindi, a volte si scopre che la versione di aggiornamento automatico è la versione precedente dell'ultima versione effettiva. Se si vuole ottenere la versione più recente, è possibile passare all'area download e farlo manualmente. Inoltre, l'aggiornamento automatico a una nuova versione viene gestito dal servizio e non è possibile modificarlo.

La scheda Versione del runtime di integrazione self-hosted nel portale di governance di Microsoft Purview mostra la versione più recente se la versione corrente è precedente. Quando il runtime di integrazione self-hosted è online, questa versione è la versione di aggiornamento automatico e aggiorna automaticamente il runtime di integrazione self-hosted nell'ora pianificata. Tuttavia, se il runtime di integrazione self-hosted è offline, la pagina mostra solo la versione più recente.

Se sono presenti più nodi e per alcuni motivi alcuni di essi non vengono aggiornati automaticamente correttamente. Questi nodi vengono quindi rollback alla versione, che era la stessa in tutti i nodi prima dell'aggiornamento automatico.

Scadenza Integration Runtime self-hosted

Ogni versione del runtime di integrazione self-hosted scade tra un anno. Il messaggio in scadenza viene visualizzato nel portale di governance di Microsoft Purview e nel client del runtime di integrazione self-hosted 90 giorni prima della scadenza.

Passaggi successivi