Condividi tramite

Creare e gestire un runtime di integrazione self-hosted supportato da Kubernetes

  • Articolo

Questo articolo illustra i dettagli per la nuova funzionalità SHIR basata su Kubernetes per Linux che migliora l'infrastruttura sottostante per offrire diversi vantaggi:

  • Scalabilità: possibilità di ridimensionare fino a centinaia di computer.
  • Prestazioni: prestazioni migliorate nei carichi di lavoro di analisi.
  • Sicurezza (in contenitori): possibilità di avere una sicurezza in contenitori in un cluster Kubernetes, anziché ospitare direttamente SHIR in un computer Windows

Questo articolo illustra i dettagli per installare e gestire un runtime di integrazione self-hosted supportato da Kubernetes.

Origini dati supportate

Per un elenco di tutte le origini supportate, vedere le origini dati supportate per ogni tabella di runtime di integrazione.

Architettura

In una visualizzazione architetturale generale, quando viene installato un file SHIR basato su Kubernetes, diversi pod vengono creati automaticamente nei nodi del cluster Kubernetes degli utenti. Questa installazione può essere attivata da uno strumento da riga di comando denominato IRCTL (più in dettaglio nelle sezioni seguenti). IRCTL si connette al servizio Microsoft Purview per registrare SHIR e connettersi al cluster Kubernetes per installare SHIR. 

Durante l'installazione, le immagini SHIR vengono scaricate da MCR (Registri contenitori Microsoft) nei pod SHIR. Al termine dell'installazione, i pod nel cluster degli utenti si connetteranno al servizio Microsoft Purview per eseguire il pull dei processi di analisi. Durante il pull di un processo di analisi, è possibile connettere l'origine dati locale degli utenti per l'analisi dei dati.

Infografica dell'architettura di rete per il runtime di integrazione self-hosted supportato da Kubernetes.

Prerequisiti

  • Un account Microsoft Purview che usa soluzioni di governance dei dati aziendali .

  • Cluster Kubernetes: è necessario avere un cluster Kubernetes basato su Linux esistente o prepararne uno. I nodi possono essere identificati dal selettore di nodi, che segue la definizione del selettore di nodi Kubernetes. Configurazione minima:

    • Tipo di contenitore: Linux
    • Versione di Kubernetes: 1.24.9 o versione successiva
    • Sistema operativo nodo: sistema operativo basato su Linux in esecuzione nell'architettura x86
    • Specifica del nodo: CPU minima di otto core, 32 GB di memoria e almeno 80 GB di spazio disponibile su disco rigido
    • Numero di nodi: >=1 (deve essere fisso, non abilitare il ridimensionatore automatico del cluster)
    • Numero di pod per nodo: >= 20 (numero massimo pod - numero di altri pod non appartenenti a Self-Hosted IR)

    Nota

    La cartella /var/irstorage/ di ogni nodo è riservata a SHIR. È leggibile e scrivibile per SHIR. È possibile ottenere che i log vengano salvati in modo permanente da questa cartella o caricare driver esterni in questa cartella. Verrà creato da SHIR se non esiste e non verrà eliminato dopo l'eliminazione di SHIR. Le immagini del contenitore usate da SHIR vengono gestite da Kubernetes Garbage Collection, che non verrà pulito da SHIR. Configurare la soglia appropriata per il cluster Kubernetes.

  • Rete cluster Kubernetes: il cluster Kubernetes di cui si dispone dovrebbe essere in grado di connettersi all'endpoint elencato nei requisiti di rete.

  • Strumento da riga di comando del runtime di integrazione: per gestire microsoft Purview Kubernetes SHIR in locale, è necessario uno strumento da riga di comando denominato IRCTL. È possibile scaricare questo strumento durante il processo di creazione di SHIR. IRCTL è uno strumento da riga di comando per gestire microsoft Purview SHIR. Per altre informazioni, vedere la documentazione di IRCTL.

  • Contesto Kubernetes: il contesto Kubernetes, che contiene le informazioni sul cluster Kubernetes e le autorizzazioni e le credenziali dell'utente per questo cluster, è necessario per comunicare con il cluster Kubernetes. Per semplificare la configurazione per le autorizzazioni dell'utente per la gestione SHIR, è possibile iniziare con Kubernetes Amministrazione ruolo. Questo contesto viene generato con l'installazione del cluster Kubernetes e salvato in un file di configurazione. Dove e come è possibile ottenere questo file dipende dalla configurazione del cluster Kubernetes.
    • Se si usa kubeadm init per configurare il cluster Kubernetes, è possibile trovare il file di configurazione in /etc/Kubernetes/admin.conf.
    • Se si usa il servizio Azure Kubernetes, è possibile seguire le indicazioni del servizio Azure Kubernetes per usare il comando del modulo Az PowerShell per ottenere le credenziali di questo cluster nel computer locale. Il contesto può essere unito direttamente al file di configurazione in $HOME/.kube/config .
    • Se si usano altri strumenti per configurare un cluster Kubernetes, vedere la documentazione di Kubernetes.
    • Poiché si dispone del file di configurazione del contesto Kubernetes, unirlo al file di configurazione, ovvero $HOME/.kube/config, nel computer in cui si vuole eseguire il comando IRCTL. In alternativa, è possibile impostare il file di configurazione del contesto Kubernetes anche in una variabile di ambiente denominata KUBECONFIG. Per altre informazioni sul contesto Kubernetes, vedere Configurare l'accesso a più cluster.

Creare il runtime di integrazione self-hosted supportato da Kubernetes

Per controllare e gestire un SHIR Kubernetes, gli utenti possono scaricare uno strumento da riga di comando denominato IRCTL. Di seguito sono riportati i passaggi per il runtime di integrazione self-hosted supportato da Kubernetes.

La procedura prevede il download di IRCTL, ma per i collegamenti diretti, vedere la documentazione di IRCTL.

Configurare un runtime di integrazione self-hosted supportato da Kubernetes

  1. Aprire la finestra Runtime di integrazione nel Microsoft Purview Data Map

  2. Selezionare il pulsante + Nuovo

    Screenshot della finestra runtime di integrazione nel Microsoft Purview Data Map.

  3. Selezionare Self-hosted (Self-hosted ) e quindi Continue (Continua)

    Screenshot della nuova finestra di runtime di integrazione, con l'opzione self-hosted selezionata.

  4. Assegnare un nome al runtime, quindi selezionare l'interruttore supporto del servizio Kubernetes per abilitare

    Screenshot della nuova finestra di runtime di integrazione con l'interruttore Kubernetes abilitato.

  5. Selezionare Crea.

  6. Selezionare Recupera chiave di registrazione

    Screenshot della pagina di runtime di integrazione della visualizzazione con il pulsante Ottieni chiave di registrazione evidenziato.

  7. Copiare il valore della chiave. È necessario eseguire i comandi in IRCTL in un secondo momento.

    Consiglio

    Se necessario, è possibile rigenerare una chiave o revocare una chiave generata.

  8. Selezionare il collegamento Scarica IRCTL e installa runtime di integrazione per scaricare lo strumento IRCTL. È anche possibile seguire questa procedura per scaricare direttamente IRCTL.

  9. Nel computer in cui si vuole eseguire la riga di comando IRCTL installare IRCTL dal download. IRCTL si connette al cluster Kubernetes in base al contesto della configurazione di Kube. Se il contesto non è specificato, IRCTL usa il contesto corrente. È possibile impostare il contesto in uno dei due modi seguenti:

    • Eseguire la riga di comando kubectl ed eseguire questo comando per confermare il contesto corrente:

      kubectl config get-contexts – List all contexts configured on the machine

      kubectl config current-context – Get the current context name

      kubectl config use-context <name of context>

    • Eseguire IRCTL ed eseguire --context per specificare il contesto nella configurazione di Kube

  10. Eseguire la riga di comando IRCTL ed eseguire questo comando con la chiave di registrazione copiata.

    ./irctl create --registration-key <registration key copied from the portal>

    Nota

    Se il selettore di nodo non è specificato, userà tutti i nodi del cluster Kubernetes. Per il servizio Azure Kubernetes, è consigliabile usare l'etichetta del pool di nodi del servizio Azure Kubernetes come selettore di nodi oppure personalizzare etichette diverse per i nodi SHIR.

  11. Verrà visualizzata questa stampa:

    [Info] Start to create SHIR with Kubernetes context [your-context]......
[Info] Environment validation passed!
[Info] Registering SHIR[example-k8s-shir] for Microsoft Purview Account [yourpurviewaccount]......
[Info] SHIR Registration done!
[Info] Provisioning SHIR, it may take about 5-30 minutes......done!
[Info] SHIR creation succeeded!

    Consiglio

    Se lo stato di avanzamento dell'installazione è interrotto da CTRL-C o da altri motivi, è possibile usare il comando seguente per monitorare lo stato di avanzamento dell'installazione: ./irctl install status

  12. Al termine dell'installazione, per controllare lo stato corrente di SHIR, eseguire questo comando:

    ./irctl describe

  13. È anche possibile controllare lo stato di SHIR nel portale di Microsoft Purview nella pagina Runtime di integrazione .

Configurare un'analisi con driver esterni

Quando si analizzano alcune origini dati, è necessario installare il driver corrispondente nel computer in cui è installato SHIR per consentire a Microsoft Purview di connettersi all'origine dati. Di seguito è riportato un esempio per l'analisi Db2. Per i prerequisiti specifici, vedere il rispettivo articolo del connettore.

Nota

Le origini dati che necessitano di questi driver esterni avranno le informazioni elencate nei prerequisiti.

In questo esempio verrà installato il driver Db2. I passaggi per altri driver saranno simili.

  1. Installare prima di tutto il runtime di integrazione.

  2. Scaricare il driver (ogni origine avrà elencato il proprio driver singolo). Ad esempio, è possibile trovare il driver DB2 qui: Connettersi a Db2 e gestirlo.

  3. Caricare il driver in ogni nodo per il runtime di integrazione. È possibile usare un comando simile al seguente:

    ./irctl storage upload --source jdbc_sqlj/db2_driver --destination driver/db2

    Una conferma di caricamento riuscita sarà simile alla seguente:

    ========== Context ========== 
Kubernetes Context             : k8s-shir-test-cluster 
Purview Account                : test-purview-1 
Self-hosted Intrgration Runtime: k8s-shir-demo 
========== Progress ========== 
Processing 2/2 nodes... 
aks-shirpool-27141791-vmss000000: SUCCEEDED 
aks-shirpool-27141791-vmss000001: SUCCEEDED 
========== Results ========== 
jdbc_sqlj/db2_driver -> /var/irstorage/driver/db2

    Nota

    Se si sostituiscono i nodi o si esegue la scalabilità orizzontale in nuovi nodi, sarà necessario caricare di nuovo il driver esterno.

  4. Verificare i file caricati con questo comando:

    ./irctl storage list driver/db2

    Verrà visualizzata una risposta simile alla seguente:

    ========== Context ========== 
Kubernetes Context             : k8s-shir-test-cluster 
Purview Account                : test-purview-1 
Self-hosted Intrgration Runtime: k8s-shir-demo 
========== Progress ========== 
Processing 2/2 nodes... 
aks-shirpool-27141791-vmss000000: SUCCEEDED 
aks-shirpool-27141791-vmss000001: SUCCEEDED 
========== Results ========== 
Node: aks-shirpool-27141791-vmss000000 - Succeeded 
/var/irstorage/driver/db2 
total 9364 
drwxr-xr-x    2 root     root          4096 May 15 14:23 . 
drwxr-xr-x    3 root     root          4096 May 15 14:23 .. 
-rwxrwxr-x    1 root     root       6568346 May 15 14:23 db2jcc4.jar 
Node: aks-shirpool-27141791-vmss000001 - Succeeded 
/var/irstorage/driver/db2 
total 9364 
drwxr-xr-x    2 root     root          4096 May 15 14:23 . 
drwxr-xr-x    3 root     root          4096 May 15 14:23 .. 
-rwxrwxr-x    1 root     root       6568346 May 15 14:23 db2jcc4.jar

  5. Creare l'analisi con il valore di DriverLocation con il valore Destination del passaggio 3.

    Screenshot della finestra di configurazione dell'analisi, che mostra il percorso del driver elencato come driver/db2.

Disponibilità elevata e scalabilità

È possibile assegnare più nodi del cluster Kubernetes per avere disponibilità elevata usando il selettore di nodi durante l'installazione del runtime di integrazione self-hosted supportata da Kubernetes. 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 le analisi.
  • Eseguire più analisi simultanee. Ogni nodo può consentire molte esecuzioni di analisi contemporaneamente. È possibile aumentare manualmente i nodi del cluster Kubernetes se sono necessarie più analisi simultanee.
  • Durante l'analisi di alcune origini, ad esempio BLOB di Azure, Azure Data Lake Storage Gen2 e File di Azure, ogni esecuzione di analisi può usare più nodi per migliorare le prestazioni dell'analisi. Per altre origini, le analisi vengono eseguite solo su uno dei nodi.

La funzionalità del runtime di integrazione self-hosted supportato da Kubernetes può essere aggiornata scalando manualmente i nodi del cluster Kubernetes.The capability of Kubernetes supported self-hosted integration runtime can be updated by manually scaling out/in nodes of the Kubernetes cluster.

Nota

È necessario caricare tutti i driver necessari per l'analisi in ogni nuovo nodo.

Requisiti di rete

Nome di dominio Porte in uscita Descrizione
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 gli endpoint privati di Microsoft Purview, questo endpoint è coperto dall'endpoint privato dell'account.
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 gli endpoint privati di Microsoft 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.
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.
Cloud pubblico: *.compute.governance.azure.com
Azure per enti pubblici:*.compute.governance.azure.us
Cina: *.compute.governance.azure.cn		 443 Necessario per connettersi al servizio Microsoft Purview. Attualmente è necessario il carattere jolly perché non è disponibile alcuna risorsa dedicata.
mcr.microsoft.com 443 Necessario per scaricare le immagini.
*.data.mcr.microsoft.com 443 Necessario per scaricare le immagini.

Nota

A seconda delle origini che gli utenti vogliono analizzare, devono anche consentire altri domini e porte in uscita per altre origini di Azure o esterne.

Versione

In genere, viene rilasciata una nuova versione secondaria del runtime di integrazione self-hosted ogni mese, che include funzionalità, miglioramenti e correzioni di bug.

Ogni versione del runtime di integrazione self-hosted scade tra un anno.

Come controllare la versione corrente

È possibile controllare la versione del runtime di integrazione self-hosted di Kubernetes nel portale o con l'IRCTL.

Portale

  1. Nel portale di Microsoft Purview passare alla mappa dati.
  2. Selezionare Runtime di integrazione
  3. La quarta colonna nella riga di descrizione del runtime di integrazione sarà Version ed è possibile controllare la versione.

IRCTL (1.1.0 e versioni successive)

Il comando describe restituirà la versione del runtime di integrazione.

./irctl describe

Aggiornamento automatico

A partire dalla versione 1.1.0, il runtime di integrazione self-hosted kubernetes supporta l'aggiornamento automatico, che è abilitato per impostazione predefinita. Questa funzionalità garantisce che il runtime di integrazione venga aggiornato automaticamente alla versione più recente gestita da Microsoft circa una volta al mese.

Rifiuto esplicito

È consigliabile mantenere abilitato l'aggiornamento automatico per trarre vantaggio dalle funzionalità e dai miglioramenti più recenti. Tuttavia, è possibile rifiutare esplicitamente l'aggiornamento automatico usando IRCTL. La configurazione dell'aggiornamento automatico viene mantenuta tramite la reinstallazione, quindi non è necessario disabilitarla a ogni installazione.

./irctl config set autoUpdate.enabled false
./irctl config view

Aggiornamento automatico della versione rispetto alla versione più recente

Per garantire la stabilità, l'aggiornamento automatico si trova in genere dietro l'ultima versione con un ritardo di un mese. La versione di aggiornamento automatico è gestita da Microsoft.

Se si vuole aggiornare il runtime di integrazione a versioni più recenti, è necessario eseguire un aggiornamento manuale con IRCTL della versione specifica.

Operazioni successive