Creare e gestire un runtime di integrazione self-hosted

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

È 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 un computer locale o una macchina virtuale all'interno di una rete privata.

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

Importante

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

Per altre informazioni Vedi
Configurazione di un nuovo runtime di integrazione self-hosted Requisiti del computer
I requisiti del computer specifici dell'origine sono elencati nei 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
Risoluzione dei 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 su 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
    • Windows Server 2025
  • 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

La scansione di alcune origini dati richiede una configurazione aggiuntiva nel computer del runtime di integrazione self-hosted. Ad esempio, JDK, Visual C++ Redistributable o driver specifico. Per la fonte, fare riferimento a ogni articolo di origine per i dettagli sui prerequisiti. Tutti i requisiti saranno elencati nella sezione Prerequisiti .

  • Per aggiungere e gestire uno 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 del runtime di integrazione self-hosted è un processore a 2 GHz con 8 core, 28 GB di RAM e 80 GB di spazio disponibile su disco. L'analisi di alcune origini dati potrebbe richiedere specifiche del computer più elevate in base allo scenario. Verificare anche i prerequisiti nell'articolo relativo al connettore.

  • 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 viene visualizzato un messaggio.

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

  • Le esecuzioni delle analisi vengono eseguite con una frequenza specifica in base alla pianificazione configurata. L'utilizzo del processore e della RAM sulla macchina segue lo stesso schema con i tempi di picco e 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.

  • Abilita il percorso lungo di Windows per impostazione predefinita seguendo questa procedura.

Importante

Se si utilizza il runtime di integrazione Self-Hosted per analizzare i file Parquet, è necessario installare JRE 8 (Java Runtime Environment) a 64 bit o OpenJDK sul computer IR. Controlla la nostra sezione Java Runtime Environment in fondo alla pagina per una guida all'installazione .

Considerazioni per l'uso di un runtime di integrazione self-hosted

  • È possibile usare un singolo runtime di integrazione self-hosted per la scansione di più origini dati.
  • È possibile installare una sola istanza di Integration Runtime self-hosted in ogni singolo computer. Se si dispone di due account di Microsoft Purview che devono analizzare le origini dati locali, installare il runtime di integrazione self-hosted in due computer, uno per ogni account di Microsoft Purview.
  • Il runtime di integrazione self-hosted non deve trovarsi nello stesso computer dell'origine dati, a meno che non sia espressamente indicato come prerequisito nel rispettivo articolo di origine. La presenza del runtime di integrazione self-hosted vicino all'origine dati riduce il tempo di connessione del runtime di integrazione self-hosted all'origine dati.
  • Per ottimizzare lo spazio su disco, è consigliabile pulire periodicamente le cartelle numeriche, insieme alle cartelle numeriche nella cartella Analisi dati e MITIlib più vecchie di sette giorni, nella cartella Temp generata nel computer.

Configurazione di un runtime di integrazione self-hosted

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

Creare un runtime di integrazione self-hosted

Nota

Per aggiungere o gestire uno 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 classico selezionare Mapping dati nel riquadro di spostamento sinistro.

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

    Selezionare su IR.

  3. Nella pagina di configurazione del runtime di integrazione , selezionare Self-Hosted per creare un runtime di integrazione self-hosted, quindi selezionare Continua.

    Creare un nuovo SHIR.

  4. Immettere un nome per il proprio IR e selezionare Crea.

  5. Nella pagina delle impostazioni di Integration Runtime, seguire i passaggi nella sezione Configurazione manuale. È necessario scaricare il runtime di integrazione dal sito di download in una macchina virtuale o in un computer in cui si intende eseguirlo.

    ottenere la chiave

    • 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 le 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 immissione.

    • Nella pagina New Integration Runtime (Self-hosted) Node selezionare Fine.

  6. Dopo aver completato la registrazione del runtime di integrazione self-hosted, viene visualizzata la finestra seguente:

    Registrato con successo.

È 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 Integration Runtime nel portale di governance di Microsoft Purview classico passando il puntatore sul runtime di integrazione e quindi selezionando Modifica.

modificare i dettagli IR.

È possibile eliminare un runtime di integrazione self-hosted passando a Runtime di integrazione, passando il puntatore del mouse sull'IR e 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 di 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 Service -> Proprietà -> Accedi.

Account di servizio per il runtime di integrazione self-hosted

Assicurarsi che l'account disponga dell'autorizzazione di 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 -> Accedi come servizio

Screenshot di Criteri di sicurezza locali - Assegnazione diritti utente

Screenshot dell'assegnazione dei diritti utente di accesso come servizio

Disponibilità e scalabilità elevate

È possibile associare un runtime di integrazione self-hosted a più macchine locali o macchine virtuali in Azure. Queste macchine sono chiamate nodi. È possibile avere fino a quattro nodi associati a un runtime di integrazione self-hosted. I vantaggi di avere più nodi sono:

  • Maggiore disponibilità 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 utilizzano fino a quattro nodi.
  • Esegui più analisi simultanee. Ogni runtime di integrazione self-hosted può consentire più esecuzioni di analisi contemporaneamente, determinate automaticamente in base alla CPU/memoria del computer. Puoi installare più nodi se hai più necessità di concorrenza.
  • Quando si analizzano origini come Azure Blob, Azure Data Lake Storage Gen1, Azure Data Lake Storage Gen2 e File di Azure, ogni esecuzione di analisi può usare tutti quei nodi per migliorare le prestazioni di analisi. Per altre origini, la scansione verrà eseguita su uno dei nodi.

È possibile associare più nodi installando il software di runtime di integrazione self-hosted dall'Area download. Registralo quindi usando la stessa chiave di autenticazione.

Nota

Prima di aggiungere un altro nodo per la disponibilità elevata e la scalabilità, verificare che l'opzione Accesso remoto alla rete Intranet sia abilitata nel primo nodo. A tale scopo, seleziona Microsoft Integration Runtime Gestione configurazione>Impostazioni>Accesso remoto alla rete Intranet.

Requisiti di rete

Per funzionare correttamente, il computer del runtime di integrazione self-hosted deve connettersi a diverse risorse:

  • I servizi Microsoft Purview usati per gestire il runtime di integrazione self-hosted.
  • Le origini dati da analizzare utilizzando 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 utilizzando l'API versione 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 le altre cose.

Esistono due firewall da considerare:

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

Di seguito sono elencati i domini e le porte in uscita che è necessario consentire sia ai firewall aziendali che a quelli Windows/computer.

Consiglio

  • Per i domini elencati con "<managed_storage_account>", aggiungere il nome delle risorse gestite associate all'account Microsoft Purview. È possibile trovarli nel portale di Azure -> Account Microsoft Purview ->Impostazioni ->Scheda Risorse gestite.
  • Se l'account non ha un account di archiviazione gestito, usa lo spazio di archiviazione di inserimento. Fare riferimento ai domini con "<ingestion_storage_account>" nella tabella seguente. Le informazioni di archiviazione sono disponibili in portale di Azure ->Proprietà ->ID archiviazione di inserimento. Per controllare i dettagli dell'endpoint, vai a Panoramica ->Visualizzazione JSON -> proprietà "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 un carattere jolly perché non esiste una risorsa dedicata.
Cloud pubblico: *.servicebus.windows.net
Azure per enti pubblici:*.servicebus.usgovcloudapi.net
Cina: *.servicebus.chinacloudapi.cn
443 Necessario per configurare l'analisi nel portale di governance classico di Microsoft Purview. Questo endpoint viene usato per la creazione interattiva dall'interfaccia utente, ad esempio connessione di test, elenco di cartelle e tabelle per l'analisi dell'ambito. Per evitare l'uso di caratteri jolly, vedere Ottenere l'URL di 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 endpoint privati 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 endpoint privati 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 a Microsoft Entra ID.

Nota

Poiché attualmente l'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 l'inoltro di Azure.

A seconda delle origini da analizzare, è necessario consentire anche 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 Quando eseguire l'analisi di Azure Data Lake Store Gen 2.
<your_storage_account>.blob.core.windows.net 443 Quando analizzare l'archiviazione BLOB di Azure.
<your_sql_server>.database.windows.net 1433 Quando analizzare il database Azure SQL.
*.powerbi.com e *.analysis.windows.net 443 Quando si analizza il tenant di Power BI.
<your_ADLS_account>.azuredatalakestore.net 443 Quando analizzare Azure Data Lake Store Gen 1.
Vari domini Dipendente Domini e porte per qualsiasi altra origine analizzata da SHIR.

Per alcuni archivi dati cloud, ad esempio il database Azure SQL e Archiviazione di Azure, potrebbe essere necessario consentire l'indirizzo IP del computer del 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, dovrai anche assicurarti che il tuo DNS sia configurato correttamente. Per verificare, è possibile usare nslookup dal computer SHIR per controllare la connettività a ogni dominio. Ogni nslookup deve restituire l'IP della risorsa. Se si usano endpoint privati, deve essere restituito l'indirizzo IP privato e non l'indirizzo 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 endpoint privato/rete virtuale.

Ottenere l'URL dell'inoltro di Azure

Un dominio e una porta obbligatori che devono essere inseriti nell'elenco dei consentiti del firewall sono quelli per la comunicazione con l'inoltro di Azure. Il runtime di integrazione self-hosted lo utilizza per la creazione interattiva, ad esempio la connessione di test e l'esplorazione di elenchi di cartelle/tabelle. Se non si vuole consentire .servicebus.windows.net e si vogliono avere URL più specifici, è possibile visualizzare tutti i nomi di dominio completi necessari per il runtime di integrazione self-hosted. attenersi alla seguente procedura:

  1. Passare al portale di governance di Microsoft Purview classico -> Data Map -> Integration runtime e modificare il runtime di integrazione self-hosted.

  2. Nella pagina Modifica, seleziona la scheda Nodi .

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

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

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

Nota

Per i dettagli relativi al protocollo delle connessioni di inoltro di Azure, vedere Protocollo delle connessioni ibride di inoltro di Azure.

Considerazioni sui server proxy

Se l'ambiente di rete aziendale utilizza un server proxy per accedere a Internet, configurare il runtime di integrazione self-hosted in modo da utilizzare le impostazioni proxy appropriate. È possibile impostare il proxy durante la fase di registrazione iniziale o dopo la registrazione.

Specificare il proxy

Una volta configurato, il runtime di integrazione self-hosted usa il server proxy per connettersi ai servizi che usano il protocollo HTTP o HTTPS. Per questo motivo è possibile selezionare Cambia collegamento durante la configurazione iniziale.

Impostare il proxy

Microsoft Purview supporta due opzioni di configurazione:

  • Non usare proxy: il runtime di integrazione self-hosted non usa in modo esplicito alcun proxy per connettersi ai servizi cloud.
  • Usa proxy di sistema: il runtime di integrazione self-hosted usa l'impostazione proxy configurata nei file di configurazione dell'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, invece di usare le configurazioni in diahost.exe.config e diawp.exe.config. I valori di indirizzo e porta 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 connettori diversi da Origini dati di Azure e 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 del proxy, utilizzare Microsoft Integration Runtime Gestione configurazione.

  1. Aprire Microsoft Integration Runtime Gestione configurazione.
  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 chiede l'autorizzazione per salvare l'impostazione 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 dell'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 richieda 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 utilizza le impostazioni proxy nei quattro file seguenti nel percorso C:\Program Files\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

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.

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

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

  2. Aprire il Blocco note in esecuzione come amministratore.

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

  4. Individuare 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 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.

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

Quindi, passare al percorso C:\Program Files\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 proxy come segue. È anche possibile estendere le impostazioni come descritto sopra.

<?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 endpoint privati. In questi casi, aggiornare i quattro file seguenti nel percorso per includere l'elenco di esclusione C:\Program Files\Microsoft Integration Runtime\5.0\ con l'elenco di esclusione obbligatoria:

  • .\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 di elenco di bypass per la scansione di un database Azure SQL e di uno spazio di 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 servizi dal Pannello di controllo. In alternativa, da Integration Runtime Gestione configurazione, selezionare il pulsante Interrompi servizio e quindi Avvia servizio. Se il servizio non viene avviato, è probabile che sia stata aggiunta una sintassi del tag XML non corretta nel file di configurazione dell'applicazione modificato.

Importante

Non dimenticare di aggiornare tutti e quattro i file menzionati sopra.

Devi anche assicurarti che Microsoft Azure sia nell'elenco consentito della tua azienda. È possibile scaricare l'elenco degli indirizzi IP di Azure validi. Gli intervalli IP per ogni cloud, suddivisi per regione e per i servizi contrassegnati in quel cloud, sono ora disponibili su MS Download:

Se vengono visualizzati messaggi di errore come i seguenti, il motivo probabile è una configurazione errata del firewall o del server proxy. Tale configurazione impedisce al runtime di integrazione self-hosted di connettersi ai servizi Microsoft Purview. Per verificare che il firewall e il server proxy siano configurati correttamente, fare riferimento alla sezione precedente.

  • Quando si tenta di registrare il runtime di integrazione self-hosted, viene visualizzato il messaggio di errore seguente: "Impossibile registrare questo nodo di Integration Runtime! Verificare che la chiave di autenticazione sia valida e che il servizio host del servizio di integrazione sia in esecuzione su questo computer".

  • Quando si apre Integration Runtime Gestione configurazione, viene visualizzato lo stato Disconnesso o Connesso. Quando si visualizzano i registri eventi di Windows, in Visualizzatore eventi> Registri >applicazioni e servizi 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)
    

Installazione dell'ambiente Java Runtime

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 infrarossi self-hosted.

Durante la scansione dei file Parquet utilizzando l'IR self-hosted, il servizio individua il runtime Java controllando prima il registro (HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\{Current Version}\JavaHome) per JRE, se non trovato, in secondo luogo controllando la variabile JAVA_HOME di sistema per OpenJDK. È possibile impostare JAVA_HOME in Impostazioni di sistema, Variabili d'ambiente sul computer. Creare o modificare la variabile JAVA_HOME in modo che punti al Java jre nel computer. Ad esempio: C:\Program Files\Java\jdk1.8\jre

  • Per usare JRE: L'IR a 64 bit richiede JRE a 64 bit. Puoi trovarlo da qui.
  • Per usare OpenJDK: È supportato dalla versione IR 3.13. Impacchettare il jvm.dll con tutti gli altri assembly necessari di OpenJDK in un computer IR 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 classico di Microsoft Purview -> Mapping dei dati -> Runtime di integrazione:

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

È anche possibile controllare la versione nel client di Integration Runtime self-hosted -> scheda Guida.

Aggiornamento automatico di 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 mantenimento manuale. In genere, Microsoft Purview rilascia due nuove versioni del runtime di integrazione self-hosted ogni mese, che include nuove funzionalità, correzioni di bug o miglioramenti. Pertanto, consigliamo agli utenti di eseguire l'aggiornamento alla versione più recente per ottenere le funzionalità e i miglioramenti più recenti.

Il runtime di integrazione self-hosted viene aggiornato automaticamente alla versione più recente. Quando è disponibile una nuova versione 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 hanno più nodi di Integration Runtime self-hosted, non si verifica alcun tempo di inattività durante l'aggiornamento automatico. L'aggiornamento automatico viene eseguito prima in un nodo, mentre gli altri stanno lavorando alle attività. Quando il primo nodo termina l'aggiornamento, assume le attività rimanenti quando altri nodi vengono aggiornati. Se si dispone di un solo nodo di runtime di integrazione self-hosted, si verificherà un tempo di inattività durante l'aggiornamento automatico.

Versione di AutoUpdate vs versione più recente

Per garantire la stabilità del runtime di integrazione self-hosted, anche se rilasciamo due versioni, ne pubblichiamo solo una al mese. In alcuni casi, quindi, si scopre che la versione autoupdate è la versione precedente dell'ultima versione effettiva. Se desideri ottenere l'ultima versione, puoi andare al centro download e farlo manualmente. Inoltre, l'aggiornamento automatico a una nuova versione è gestito dal servizio e non è possibile modificarlo.

La scheda Versione del runtime di integrazione self-hosted nel portale di governance di Microsoft Purview classico mostra la versione più recente, se la versione corrente è vecchia. Quando il runtime di integrazione self-hosted è online, questa versione è la versione autoupdate e aggiorna automaticamente il runtime di integrazione self-hosted nel tempo pianificato. Tuttavia, se il runtime di integrazione self-hosted è offline, nella pagina viene visualizzata solo la versione più recente.

Se hai più nodi e per qualche motivo per cui alcuni di essi non vengono aggiornati automaticamente correttamente. Questi nodi eseguono quindi il rollback alla versione, che era la stessa in tutti i nodi prima dell'aggiornamento automatico.

Scadenza di Integration Runtime self-hosted

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

Passaggi successivi