Pianificazione dell'implementazione di Power BI: Gateway dati

Nota

Questo articolo fa parte della serie di articoli sulla pianificazione dell'implementazione di Power BI. Questa serie è incentrata principalmente sul carico di lavoro di Power BI all'interno di Microsoft Fabric. Per un'introduzione alla serie, vedere Pianificazione dell'implementazione di Power BI.

Questo articolo illustra come pianificare e implementare gateway dati locali e gateway dati di rete virtuale (VNet) per Microsoft Fabric. È destinato principalmente a:

  • Amministratori dell'infrastruttura: amministratori responsabili della supervisione dell'infrastruttura nell'organizzazione. Gli amministratori dell'infrastruttura potrebbero dover collaborare con amministratori di Power Platform, amministratori di database, team di sicurezza delle informazioni, team di rete e altri team pertinenti.
  • Amministratori del gateway: utenti responsabili dell'implementazione, della gestione e del monitoraggio dei gateway e delle connessioni all'origine dati.
  • Collaboratori del gateway: i team decentralizzati e gli utenti responsabili dell'aggiunta e della gestione delle connessioni all'origine dati del gateway.
  • Centro di eccellenza (COE), team IT e BI: i team responsabili del supporto degli utenti che devono accedere, connettersi e aggiornare i dati.
  • Proprietari e creatori di contenuti: i team e gli utenti che usano i gateway per connettersi alle origini dati e aggiornare gli elementi di dati di Fabric.

Per accedere ai dati di origine per modelli semantici di Power BI, flussi di dati e altri elementi di dati di Fabric, potrebbe essere necessario un gateway dati. Un gateway dati trasferisce in modo sicuro i dati tra reti private o origini dati locali e servizi cloud, tra cui Fabric.

Nota

Questo articolo offre una panoramica dei gateway. Si concentra sulle considerazioni chiave e sulle azioni per la pianificazione e l'implementazione di gateway per supportare il contenuto di Fabric.

Per altre informazioni sul funzionamento dei gateway, vedere:

Pianificare le decisioni chiave

I gateway sono spesso integrali alle implementazioni di Power BI e Fabric riuscite. Un coe o un team di business intelligence centrale e in genere pianifica e gestisce centralmente i gateway, anche se alcune organizzazioni usano team decentralizzati per gestire i gateway. Per attenuare la possibilità di future interruzioni e rischi di governance, è importante pianificare attentamente come e quando si useranno i gateway.

In genere si pianifica l'implementazione del gateway durante due fasi distinte.

  • Configurazione del tenant: quando si prepara a implementare o eseguire la migrazione a Fabric, è necessario valutare se le origini dati necessitano di un gateway. Le attività di pianificazione del gateway sono rilevanti anche per la pianificazione a livello di tenant della sicurezza, delle aree di lavoro e del controllo e del monitoraggio.
  • Pianificazione della soluzione BI: quando si pianifica una nuova soluzione di business intelligence, è necessario valutare se la soluzione richiede un gateway durante la raccolta dei requisiti tecnici per la nuova soluzione. Potrebbe anche essere necessario un gateway quando si aggiunge una nuova origine dati a una soluzione esistente.

La pianificazione di un'implementazione del gateway inizia prendendo decisioni chiave, a partire dal fatto che sia necessario o meno un gateway.

Suggerimento

Creare prima di tutto un inventario delle origini dati. È consigliabile valutare le decisioni chiave seguenti per ogni origine dati. Assicurarsi di documentare i risultati e archiviarli in una posizione centrale facilmente accessibile, ad esempio un hub di comunicazione o il portale centralizzato.

Identificare se è necessario un gateway

In generale, è necessario un gateway per l'origine dati quando:

  • L'origine dati si trova in locale.
  • L'origine dati si trova in una rete privata.
  • È necessario un host per il software connettore.
  • È necessario l'isolamento della sicurezza per determinati connettori o funzioni.

In queste situazioni è necessario un gateway per:

  • Aggiornare i dati nel portale di Infrastruttura. Questo scenario si applica quando un creatore di contenuti configura l'aggiornamento dati nel servizio Power BI per un'origine dati che richiede un gateway.
  • Creare contenuto nel portale di Fabric. Questo scenario si applica quando un autore del contenuto crea o modifica gli elementi di dati (ad esempio un modello semantico o un flusso di dati) nel servizio Power BI che richiedono un gateway.
  • Supportare le connessioni DirectQuery. Questo scenario si applica quando un autore di contenuti pubblica un modello semantico che include tabelle in modalità di archiviazione DirectQuery (o Doppia) e l'origine dati per tali tabelle richiede un gateway. Questo scenario di utilizzo illustra anche la possibilità di applicare autorizzazioni per dati per utente definite nell'origine dati. Ad esempio, un database di SQL Server può applicare la sicurezza a livello di riga e Power BI può gestire la connettività Single Sign-On (SSO). Per altre informazioni, vedere Applicare la sicurezza dei dati in base all'identità consumer.
  • Connessione dinamica a SQL Server Analysis Services. Questo scenario si applica quando un autore del contenuto pubblica un report che usa una connessione dinamica a un database di SQL Server Analysis Services (SSAS).

Le sezioni seguenti descrivono quando è necessario un gateway.

Origini dati locali

È necessario un gateway per connettersi alle origini dati locali dal portale di Fabric. Il gateway funge da bridge, valutando le espressioni di query nel computer gateway e trasferendo in modo sicuro i dati locali nel cloud.

Questo scenario è rilevante per la connessione a:

  • Origini dati che risiedono in computer locali.
  • File archiviati in una directory locale.
  • Origini dati cloud e locali combinate in una singola query.
  • Una macchina virtuale basata sul cloud, nota come infrastruttura come servizio o IaaS.

Origini dati di rete privata

È necessario un gateway per connettersi alle origini dati che si trovano in una rete privata, ad esempio un'Rete virtuale di Azure (rete virtuale di Azure). Una rete virtuale, o rete virtuale, è un segmento isolato logicamente di una rete che isola il traffico dalla rete Internet pubblica. Una rete virtuale offre una sicurezza di rete avanzata.

Questo scenario è rilevante quando l'origine dati:

  • Si trova in un data center all'interno di una rete privata, ad esempio la rete organizzativa (o si trova dietro un firewall).
  • È una macchina virtuale basata sul cloud all'interno di una rete virtuale (nota come infrastruttura come servizio o IaaS).
  • È un servizio di database basato sul cloud all'interno di una rete virtuale (noto come piattaforma come servizio o PaaS).

Nota

È un malinteso comune che non è necessario un gateway per le origini dati cloud. Quando un'origine dati cloud si trova all'interno di una rete aziendale privata, è necessario un gateway.

Software del connettore host

A volte potrebbe essere necessario un gateway per ospitare elementi di supporto necessari per connettersi all'origine dati. Questo software può includere connettori dati personalizzati, driver o librerie installati nel computer gateway. Il servizio Power BI non ha accesso a questo software, quindi non è in grado di aggiornare le origini dati che lo usano senza basarsi sul gateway, anche quando ci si connette a un'origine dati cloud.

Questo scenario è rilevante quando ci si connette a un'origine dati con connettori come:

  • Autista. Un connettore ufficiale potrebbe richiedere l'installazione di driver prerequisiti. Ad esempio, quando ci si connette a un database Oracle , potrebbe essere necessario il software client Oracle Data Access.
  • Connettore personalizzato. Alcune origini dati potrebbero richiedere connettori personalizzati o di terze parti. Ad esempio, potrebbe essere necessario un connettore personalizzato per connettersi a un sistema legacy o proprietario.
  • Libreria client. Alcune origini dati potrebbero richiedere una libreria di supporto per consentire la connessione degli strumenti client. Ad esempio, quando ci si connette a un database di Analysis Services, è necessario installare una libreria client.
  • Connettore ODBC o OLE DB. Un connettore ufficiale potrebbe richiedere un driver ODBC o un provider OLE DB. Ad esempio, quando ci si connette a SAP HANA, è necessario un driver ODBC.

Importante

Quando gli autori di contenuti usano uno strumento client come Power BI Desktop e le relative soluzioni si basano su driver, connettori o provider, è necessario installare gli stessi componenti nel computer gateway installati nei computer creatori di contenuti. I componenti mancanti o non corrispondenti tra computer creator e gateway dati sono un motivo comune per gli errori di aggiornamento dei dati del contenuto pubblicato. Per altre informazioni, vedere Strumenti e dispositivi utente.

Isolamento della sicurezza

È necessario un gateway per usare determinati connettori o funzioni di Power Query, ad esempio il connettore Web o la funzione Web.BrowserContents. Questi connettori e funzioni richiedono un gateway per molti motivi, incluso l'isolamento della sicurezza.

Suggerimento

Quando ci si connette alle origini dati della pagina Web, prendere in considerazione le alternative seguenti.

  • Funzione Web.Contents: se ci si connette al contenuto Web a cui non è necessario accedere tramite un browser, è consigliabile usare la funzione Web.Contents . Questa funzione non richiede un gateway perché non usa un controllo browser.
  • Notebook: se si ha capacità di Infrastruttura, è consigliabile usare i notebook di Fabric per trasformare i dati. I notebook non richiedono un gateway per i dati della pagina Web e possono offrire prestazioni migliori quando si recuperano informazioni sulla pagina Web rispetto a Power Query.

Questo scenario è rilevante quando ci si connette a un'origine dati usando connettori e driver, ad esempio:

Determinare il tipo di gateway necessario

Dopo aver rilevato che è necessario un gateway, è necessario determinare il tipo di gateway da installare. Esistono tre tipi di gateway.

  • Gateway dati locale (modalità standard)
  • Gateway dati locale (modalità personale), noto come gateway personale
  • Servizio gateway di rete virtuale

Il tipo di gateway scelto dipenderà dai requisiti e dalle origini dati. Le sezioni seguenti descrivono ognuno dei tre tipi di gateway.

Gateway dati locale (modalità standard)

Un gateway dati locale (modalità standard) consente a più utenti di connettersi a origini dati che tramite un singolo gateway condiviso. In genere, i gateway in modalità standard vengono installati e gestiti centralmente in una macchina virtuale always-on. Con un gateway in modalità standard è possibile connettersi ai dati da più servizi, ad esempio Infrastruttura, Power BI e altri servizi power platform.

Il diagramma seguente illustra una panoramica generale di un gateway in modalità standard.

Diagramma che mostra il gateway dati locale (modalità standard). Gli elementi nel diagramma sono descritti nella tabella seguente.

Importante

Questo diagramma non illustra l'architettura di un gateway dati locale.

Il diagramma illustra i concetti seguenti.

Articolo Descrizione
Articolo 1. Il gateway dati locale (modalità standard) trasferisce in modo sicuro i dati dall'origine dati locale ai servizi cloud.
Articolo 2. Un gateway dati in modalità standard è necessario per le origini dati cloud in scenari specifici (descritto nella sezione precedente).
Articolo 3. Il gateway dati in modalità standard viene installato in una macchina virtuale always-on. Amministrazione istrators gestiscono centralmente la macchina virtuale e il gateway dati. Gli amministratori del gateway installano il software necessario per le connessioni all'origine dati, se necessario.
Articolo 4. Più utenti possono connettersi alle origini dati del gateway dati.
Articolo 5. Gli utenti possono usare il gateway dati per gli elementi pubblicati nelle aree di lavoro di Fabric, ad esempio modelli semantici, flussi di dati, pipeline o report impaginati.
Articolo 6. Gli utenti possono usare il gateway dati per altri servizi cloud di Power Platform, ad esempio flussi di dati di Power Platform.

Nelle situazioni specifiche seguenti è necessario un gateway in modalità standard.

  • Diversi servizi cloud Microsoft (ad esempio Power Apps e Infrastruttura) e elementi di dati di Fabric (ad esempio i flussi di dati) devono eseguire query su origini dati locali (o origini dati cloud che richiedono un gateway).
  • I report impaginati devono eseguire query su origini dati locali (o origini dati cloud che richiedono un gateway).
  • I modelli semantici usano la modalità di archiviazione DirectQuery che deve connettersi a origini dati locali (o origini dati cloud che richiedono un gateway).
  • Connessioni SSAS dinamiche.
  • Le origini dati dipendono da connettori dati personalizzati, driver o librerie.
  • Quando si prevede la necessità di rilocare o eseguire la migrazione del gateway.

Gateway personale

Un gateway locale (modalità personale), comunemente noto come gateway personale, consente a un utente di connettersi a origini dati locali che risiedono nello stesso computer. Un utente installa e gestisce in genere un gateway personale dal proprio computer. Con un gateway personale, gli utenti non possono connettersi ai dati da altri servizi Power Platform. Non possono anche condividere il gateway o le connessioni con altri utenti.

Un gateway personale è destinato a un uso personale limitato da parte di un singolo utente. In genere, gli autori di contenuti installano e usano questi gateway per condurre business intelligence personale. Questi gateway sono limitati alla business intelligence personale perché non possono essere condivisi. Inoltre, un gateway personale richiede che l'utente disponga dei diritti del computer e dell'approvazione dei criteri per scaricare e installare il software gateway personale.

Suggerimento

Non usare un gateway personale con soluzioni di business intelligence per team, reparto o aziendale.

Per la maggior parte degli scenari in cui ci si connette ai dati locali, è consigliabile usare un gateway in modalità standard (descritto nella sezione precedente). Ciò è dovuto al fatto che è possibile condividere un gateway in modalità standard con più utenti, supporta query DirectQuery e connessioni dinamiche e offre altre opzioni per centralizzare la governance e la gestione dei gateway.

Attenzione

Poiché un gateway personale viene in genere installato in un computer utente, è più difficile gestire e gestire. Se è necessario usare un gateway personale, è consigliabile spostarlo in una macchina virtuale gestita centralmente che usa un account del servizio. Questo approccio garantisce che la disponibilità del gateway non dipende da un computer utente (che potrebbe essere disattivato) e migliora la governance e la gestione del gateway.

Il diagramma seguente illustra una panoramica generale di un gateway personale.

Il diagramma mostra il gateway personale. Gli elementi nel diagramma sono descritti nella tabella seguente.

Importante

Questo diagramma non illustra l'architettura di un gateway dati locale.

Il diagramma illustra i concetti seguenti.

Articolo Descrizione
Articolo 1. Un gateway personale viene in genere installato in un computer utente.
Articolo 2. Il gateway personale trasferisce in modo sicuro i dati dalle origini dati locali nel computer utente ai servizi cloud.
Articolo 3. Il gateway personale viene in genere gestito dall'utente che lo ha installato.
Articolo 4. Un singolo utente usa il gateway personale per uso personale limitato. Non è possibile condividere un gateway in modalità personale.
Articolo 5. Un gateway personale può essere usato solo per gli elementi pubblicati in un'area di lavoro di Power BI, ad esempio modelli semantici o flussi di dati di Power BI.

Per ribadire, un gateway personale è destinato a un uso personale limitato da parte di un singolo utente. Esistono tuttavia due scenari specifici che richiedono l'uso di un gateway personale.

  • Gli autori di contenuti self-service devono aggiornare il contenuto pubblicato connesso alle origini dati locali nel computer o in altre origini dati locali.
  • I modelli semantici usano codice Python o R in Power Query.

Suggerimento

Quando possibile, evitare di usare un gateway personale. Si considerino invece le alternative seguenti.

  • SharePoint: se è necessario connettersi ai file locali, è consigliabile caricare tali file in SharePoint o OneDrive for Work o School. È possibile connettersi a questi file usando il connettore di cartelle di SharePoint, che non richiede un gateway.
  • OneLake: se è necessario connettersi ai file locali e si ha capacità di Infrastruttura, è anche possibile usare Esplora file OneLake per caricare e sincronizzare i file con una lakehouse. Connessione a un'infrastruttura lakehouse non richiede un gateway.
  • Notebook: se è necessario trasformare i dati con Python o R e si dispone della capacità di Fabric, è consigliabile usare i notebook di Fabric per trasformare i dati e scriverli in tabelle archiviate in OneLake. I notebook non richiedono un gateway per eseguire codice Python o R. È anche possibile sfruttare le prestazioni migliorate e le funzionalità aggiuntive disponibili nei notebook.

Gateway di rete virtuale

Un gateway di rete virtuale consente a più utenti di connettersi a origini dati protette con reti private, incluse le origini dati che usano endpoint privati. Con un gateway di rete virtuale è possibile connettersi ai dati con più servizi ed è possibile condividere il gateway o le connessioni con più utenti.

Un gateway di rete virtuale è un servizio gestito da Microsoft. Se l'organizzazione usa reti private, è necessario un gateway di rete virtuale.

Importante

Se si sta valutando l'uso del servizio gateway di rete virtuale, discuterne con i team IT che gestiscono la rete e la sicurezza. Questi team possono contribuire a garantire che tutto sia configurato, ad esempio endpoint privati (se applicabile) e comunicazione gateway.

Un gateway di rete virtuale è supportato solo per le capacità di Power BI Fabric o Premium. Il gateway di rete virtuale viene fatturato come addebito aggiuntivo per l'infrastruttura Premium per tale capacità.

Il diagramma seguente illustra una panoramica generale di un gateway di rete virtuale.

Diagramma che mostra il gateway di rete virtuale.Diagram shows the virtual network (VNet) gateway. Gli elementi nel diagramma sono descritti nella tabella seguente.

Importante

Questo diagramma non illustra l'architettura di un gateway dati della rete virtuale.

Il diagramma illustra i concetti seguenti.

Articolo Descrizione
Articolo 1. Si usa un gateway di rete virtuale (VNet) per connettersi alle origini dati in una rete privata, ad esempio quelle in una rete virtuale di Azure.
Articolo 2. Il gateway dati della rete virtuale è un servizio gestito da Microsoft. È possibile gestire centralmente il gateway dati della rete virtuale dal portale di Azure e dal portale di amministrazione di Power Platform.
Articolo 3. Più utenti possono usare un gateway dati di rete virtuale.
Articolo 4. Gli utenti possono usare un gateway dati della rete virtuale per gli elementi pubblicati in un'area di lavoro infrastruttura, ad esempio modelli semantici.
Articolo 5. Gli utenti possono usare un gateway dati di rete virtuale per altri servizi Power Platform, ad esempio flussi di dati di Power Platform.

Avviso

I gateway di rete virtuale presentano alcune limitazioni e non supportano tutte le origini dati o gli scenari. Verificare che le origini dati e gli scenari siano supportati e consultare le domande frequenti prima di procedere con l'implementazione del gateway di rete virtuale e la pianificazione della soluzione.

Determinare il numero di gateway

Dopo aver determinato che è necessario un gateway e quale tipo di gateway, è necessario determinare il numero di gateway necessari.

A seconda delle esigenze, potrebbero essere necessari più gateway. Quando si decide quanti gateway installare e usare, prendere in considerazione i fattori seguenti.

Disponibilità e prestazioni

È importante che i gateway abbiano disponibilità elevata per evitare interruzioni causate da ritardi di aggiornamento o query. Un modo per garantire la disponibilità del gateway consiste nell'installare più gateway in un cluster gateway a disponibilità elevata. Un cluster di gateway è una raccolta di gateway installati in macchine virtuali diverse e associate logicamente come singola unità funzionale (il cluster). Ogni computer gateway viene talvolta chiamato nodo.

Ecco i vantaggi dell'uso di un cluster gateway.

  • Evitare un singolo punto di errore: il failover evita un singolo punto di errore quando il computer gateway primario non è disponibile. Se non è disponibile, le query vengono inviate a un altro nodo del cluster. L'uso di un cluster di più computer riduce i rischi. Aumenta anche il tempo di attività, che consente di soddisfare i requisiti di disponibilità elevata e ripristino di emergenza.
  • Prestazioni migliori: il bilanciamento del carico migliora le prestazioni quando è presente un utilizzo simultaneo elevato. Il bilanciamento del carico distribuisce il carico di lavoro inviando query ad altri nodi del cluster. Ciò è utile quando il gateway primario è occupato o quando una singola operazione (ad esempio un aggiornamento dati lungo) utilizza molte risorse.
  • Evitare tempi di inattività: quando si installano gli aggiornamenti software del gateway, è possibile eseguire l'installazione in un nodo del cluster alla volta. In questo modo, evita di portare offline l'intero cluster.

Importante

È consigliabile usare cluster gateway per carichi di lavoro business critical.

Per altre informazioni e indicazioni sulla configurazione di un cluster gateway, vedere Pianificare, ridimensionare e gestire una soluzione gateway business critical.

Ambienti

Gli autori di contenuti usano in genere ambienti separati per sviluppare e gestire soluzioni critiche per l'azienda, ad esempio sviluppo, test e produzione. A seconda del numero di ambienti usati e del modo in cui vengono usati, potrebbe essere necessario disporre di cluster gateway separati per ogni ambiente.

La separazione dei cluster gateway in ambienti diversi può:

  • Separare e ridurre al minimo le interruzioni causate dalle attività di sviluppo e test.
  • Migliorare la disponibilità e le prestazioni dei carichi di lavoro di produzione.
  • Fornire un ambiente sicuro per installare e testare gli aggiornamenti software del gateway.

Importante

È consigliabile disporre di cluster gateway separati per i carichi di lavoro di produzione. Se si dispone di un cluster gateway in tutti gli ambienti, questo può rappresentare un rischio aggiuntivo. Per ridurre al minimo i costi e le attività di gestione, è comune allocare meno risorse (ad esempio memoria e CPU) a un cluster del gateway di sviluppo.

Aree

Per garantire prestazioni ottimali degli aggiornamenti dei dati, è importante considerare la posizione delle origini dati, dei gateway e della posizione degli utenti. Per ridurre la latenza, è necessario installare i gateway il più vicino possibile alle origini dati. Per questo motivo, potrebbe essere necessario installare più cluster gateway per supportare aree o tenant diversi.

Attenzione

Assicurarsi che l'installazione del gateway sia conforme ai requisiti di residenza dei dati per l'organizzazione.

Importante

Per ridurre al minimo la latenza, è consigliabile installare i gateway nei computer che si trovano nella stessa area delle origini dati. Inoltre, per i gateway di rete virtuale, i gateway e le origini dati devono trovarsi nella stessa subnet.

Elenco di controllo : quando si pianifica l'implementazione di un gateway, le decisioni chiave e le azioni includono:

  • Creare un inventario delle origini dati: un inventario delle origini dati consente di verificare e documentare le origini dati necessarie per un gateway.
  • Determinare quali situazioni richiedono un gateway: valutare il funzionamento dei creatori di contenuti e dei consumer. Assicurarsi di avere familiarità con quando è necessario un gateway. Creare documentazione e formazione per la community degli utenti.
  • Decidere il tipo di gateway necessario: assicurarsi di convalidare eventuali presupposti e valutare le possibili limitazioni in modo che il tipo di gateway selezionato soddisfi i requisiti.
  • Evitare gateway personali: è consigliabile usare un gateway in modalità standard. Determinare se sono presenti origini dati del gateway personale che possono essere reindirizzate per l'uso di un gateway in modalità standard (in modo che non sia limitato all'uso da parte di un singolo utente).
  • Decidere se è necessario un cluster gateway: usare i cluster gateway per le soluzioni business critical. I cluster gateway offrono disponibilità elevata e bilanciamento del carico. Consentono inoltre di evitare un singolo punto di errore e migliorare le prestazioni durante i periodi di utilizzo simultaneo elevato.
  • Decidere il numero di gateway necessari: prendere in considerazione cluster gateway separati per ambienti diversi per evitare interruzioni. Prendere in considerazione altri fattori, ad esempio l'utilizzo o le aree.

Installare i gateway

A questo punto, si conoscono i tipi di gateway necessari e quanti. Successivamente, è necessario pianificare l'installazione del gateway. In genere, i gateway vengono installati nelle macchine virtuali dedicate a questo scopo (spesso denominate computer gateway). Ogni computer nel cluster gateway deve essere sempre attivo per garantire il supporto continuo delle operazioni di attività utente e aggiornamento dati.

Nota

Poiché un gateway di rete virtuale è un servizio gestito, non è possibile scaricarlo e installarlo. È invece possibile effettuare il provisioning e configurare un gateway di rete virtuale nel portale di Azure e quindi associarlo a una capacità Fabric o Power BI Premium. Per altre informazioni, vedere Creare gateway dati di rete virtuale.

Identificare i proprietari e i programmi di installazione del gateway

Prima di installare il gateway, identificare chi installerà e sarà proprietario del gateway.

Proprietari del gateway

In genere, il proprietario del gateway è una persona tecnica che installa, possiede e gestisce il gateway. I proprietari del gateway sono responsabili di varie attività.

  • Pianificazione: prendere decisioni chiave come descritto in precedenza e definire le specifiche tecniche per un computer gateway, incluse le risorse di sistema iniziali. Il proprietario del gateway deve anche assicurarsi che sia attivo un piano di supporto.
  • Installazione: selezionare un computer appropriato per installare il software gateway ed eseguire l'installazione e la configurazione per la prima volta.
  • Gestione: modificare le impostazioni o le preferenze del gateway per l'ottimizzazione , ad esempio la configurazione del flusso anziché lo spooling dei dati, o scopi di monitoraggio (ad esempio la configurazione della registrazione delle prestazioni). Il proprietario del gateway prende anche decisioni su quando aumentare le prestazioni (aggiungere altre risorse ai computer gateway) o aumentare il numero di istanze (installare più gateway nel cluster).
  • Test: convalidare l'utilizzo del gateway durante la prima configurazione, assicurandosi che siano disponibili risorse sufficienti per i computer gateway. Il proprietario del gateway deve anche testare gli aggiornamenti mensili prima di installarli.
  • Aggiornamento: aggiornare e installare il software gateway e gli elementi di supporto (ad esempio il software connettore) in modo tempestivo.
  • Monitoraggio:Monitorare il tempo di attività e l'integrità del gateway, inclusa la raccolta dei file di log del gateway che consentono il monitoraggio di problemi e attività anomale.
  • Migrazione: archiviare le chiavi di ripristino in un luogo sicuro accessibile a un team più ampio. Il proprietario del gateway deve anche essere la persona che deve usare queste chiavi per eseguire la migrazione, il ripristino o rilocare il gateway, se necessario.

Importante

Assicurarsi che il proprietario del gateway sia a conoscenza e che accetti queste responsabilità. Se il proprietario del gateway non è pronto a gestire il gateway, può diventare rapidamente una dipendenza che blocca proprietari e creatori di contenuti. Inoltre, identificare se il proprietario del gateway comprende come installare e gestire un gateway e, in caso contrario, come eseguirne il training per eseguire questa operazione.

Suggerimento

Alcune organizzazioni consentono correttamente la proprietà del gateway all'interno di business unit e reparti, mentre altre riservano la proprietà del gateway per un team centralizzato (ad esempio IT). Un modo per gestirlo consiste nel creare una partnership in cui l'IT gestisce i nodi del cluster del gateway e la business unit gestisce le connessioni all'origine dati.

Poiché la proprietà del gateway è una responsabilità importante, è necessario definire chiaramente chi può installare i gateway nell'organizzazione.

Programmi di installazione del gateway

Per ridurre il sovraccarico di gestione e ridurre il rischio di governance, è importante limitare il numero di gateway attivi nell'organizzazione. A questo scopo, è consigliabile limitare il numero di utenti che possono installare i gateway.

Avviso

I proprietari del gateway hanno il controllo completo sui gateway gestiti. Ciò significa che i proprietari di gateway malintenzionati potrebbero potenzialmente intercettare le informazioni durante il flusso attraverso un gateway dati locale. Per questo motivo, è essenziale limitare la possibilità di installare i gateway a persone attendibili.

Per i gateway in modalità standard, è possibile gestire i programmi di installazione del gateway dal portale di Infrastruttura o dall'interfaccia di amministrazione di Power Platform. È anche possibile gestire chi può creare gateway dati di rete virtuale usando l'impostazione del programma di installazione del gateway.

È anche possibile gestire i programmi di installazione del gateway a livello di codice usando i cmdlet di PowerShell per la gestione del gateway locale. Per i gateway personali e i gateway in modalità standard, è possibile usare questi cmdlet per impostare i criteri del tenant del gateway. L'impostazione dei criteri del tenant del gateway tramite PowerShell è l'unico modo per gestire chi può installare gateway personali nel tenant.

Importante

È consigliabile regolare attentamente chi può installare gateway personali, limitandone l'installazione e l'uso per casi aziendali validi e approvati.

Preparare l'installazione del gateway

Dopo aver identificato chi installa e possiede il gateway, è necessario prepararsi per l'installazione del gateway. È necessario effettuare le operazioni seguenti:

  • Identificare dove installare il gateway.
  • Decidere le risorse necessarie per il computer gateway.
  • Accettare come assegnare un nome al gateway quando viene installato.

Le sezioni seguenti descrivono queste considerazioni chiave per la pianificazione di un'installazione del gateway.

Identificare dove installare il gateway

In genere, si installa un gateway in una macchina virtuale always-on (detta anche computer gateway). È possibile installare un solo gateway di ogni tipo (modalità personale o modalità standard) in un computer.

Ecco i fattori chiave per determinare dove installare un gateway.

  • Percorso: in genere, il computer gateway deve trovarsi vicino all'origine dati per ridurre al minimo la latenza. In genere, è necessario installare un gateway standard nell'area dati predefinita. Tuttavia, se la posizione della capacità Premium è diversa dall'area dati predefinita per il tenant, esaminare l'uso di un inoltro di Azure come opzione per soddisfare i requisiti di residenza dei dati.
  • Elementi di supporto: determinare quali connettori, driver o librerie è necessario installare nel computer gateway.
  • Dominio: determinare la relazione tra il computer gateway e il dominio di destinazione. La macchina virtuale deve essere un computer aggiunto a un dominio con una relazione di trust con il dominio di destinazione. Non può essere un controller di dominio.

Suggerimento

Per evitare conflitti di risorse, non installare software non correlato in un computer gateway. Il computer gateway deve essere completamente dedicato all'hosting del gateway dati locale.

Decidere le risorse del computer gateway

Il computer gateway deve avere risorse sufficienti per gestire il carico di lavoro di query previsto.

Ecco i fattori chiave per determinare le risorse del computer gateway.

  • Utilizzo: determinare il numero di elementi e il tipo di elementi che useranno il gateway e quale concorrenza di query (da molti utenti) sarà. Un utilizzo più elevato richiede computer gateway con più risorse.
  • tipo di Connessione ion: determinare se i modelli semantici di Power BI importano dati, usano DirectQuery o una connessione dinamica. Per i modelli semantici di importazione, è importante controllare il numero di aggiornamenti dei dati per stimare le esigenze delle risorse del gateway, ad esempio la RAM. Per le connessioni DirectQuery o dinamiche, è necessario valutare il numero di consumer di report per stimare le esigenze delle risorse, ad esempio la CPU.

Suggerimento

Convalidare le risorse del computer gateway eseguendo test di carico. È possibile eseguire questo tipo di test monitorando l'integrità del computer gateway durante l'esecuzione degli aggiornamenti del set di dati e simulando un utilizzo simultaneo elevato di DirectQuery o report di connessione dinamica.

Accettare le convenzioni di denominazione

È importante assegnare un nome al gateway e alle relative connessioni all'origine dati. Il nome deve rendere più semplice per gli autori di contenuti sapere a cosa connettersi. Per garantire che i gateway e le connessioni all'origine dati abbiano nomi chiari, è necessario usare una convenzione di denominazione logica.

Quando si definiscono le convenzioni di denominazione, prendere in considerazione i punti seguenti.

  • Includere una variante di Gateway o DataGW nel nome per identificare il gateway per scopi di controllo, registrazione e risoluzione dei problemi.
  • Includere lo scopo specifico del gateway quando supporta specifici elementi, operazioni, aree geografiche o aree aziendali specifici.
  • Usare una variante di Sviluppo, Test o Prod nel nome quando il gateway supporta un ambiente specifico.
  • Assegnare al gateway un nome allineato al nome del cluster a cui appartiene. Ad esempio, assegnare a ogni computer gateway all'interno del cluster un nome univoco, ad esempio Node1, Node2 e così via.

Ecco alcuni esempi di nomi di gateway logici.

  • DataGW-Prod-Node1
  • Gateway-DevTest-Node1
  • Gateway-FinanceTeam-Prod-Node1

Installare e configurare i gateway

Dopo aver prese decisioni chiave e preparazione, il proprietario del gateway installa i gateway ed esegue la prima configurazione.

Nota

Per informazioni su come scaricare e installare un gateway, vedere:

Quando si installano e si configurano i gateway, considerare i fattori seguenti.

  • Percorso di installazione: quando si vuole installare il gateway in un percorso diverso dal percorso di installazione predefinito, è possibile modificare il percorso di installazione.
  • Chiave di ripristino: quando si vuole eseguire la migrazione, il ripristino o l'acquisizione di un gateway esistente, è necessario usare la chiave di ripristino del gateway. Assicurarsi di mantenere la chiave di ripristino in un luogo sicuro e sicuro accessibile ad altri amministratori del gateway.
  • Area del data center: quando si vuole che l'area sia diversa dal tenant del servizio registrato, è possibile modificare l'area del data center.
  • Inoltro di Azure: quando si vuole usare il proprio inoltro anziché l'impostazione predefinita, è possibile specificare i propri dettagli di inoltro.
  • Impostazioni proxy: quando l'ambiente aziendale richiede che il gateway attraversi un server proxy per connettersi al portale di Fabric, è necessario configurare le impostazioni proxy.
  • Account del servizio gateway: quando si vuole usare un account di dominio esplicito, è possibile modificare l'account del servizio gateway dall'impostazione predefinita, ovvero PBIEgwService.
  • Impostazioni di comunicazione: quando un firewall blocca le connessioni in uscita, i team di sicurezza e rete possono configurare il firewall per consentire le connessioni in uscita dal gateway all'area di Azure associata.
  • Registrazione del tenant: quando si vuole limitare i tenant autorizzati a registrare l'applicazione gateway dati locale per impedire l'esfiltrazione dei dati.
  • Impostazioni del tenant di integrazione: quando si vuole assicurarsi che il gateway funzioni con l'accesso Single Sign-On (SSO), ad esempio con l'autenticazione basata su ID di Microsoft Entra, nel modo desiderato.

Importante

È consigliabile limitare la registrazione del tenant solo ai tenant all'interno dell'organizzazione. Questo passaggio consente di migliorare la sicurezza del gateway perché l'impostazione predefinita non prevede restrizioni per la registrazione del tenant.

Elenco di controllo : durante la preparazione e l'installazione di un gateway, le decisioni chiave e le azioni includono:

  • Identificare il proprietario e i programmi di installazione del gateway: assicurarsi che il proprietario del gateway sia a conoscenza delle proprie responsabilità. Limitare l'installazione del gateway alle persone appropriate.
  • Eseguire il training: se necessario, eseguire il training dei proprietari e dei programmi di installazione del gateway per installare, gestire e supportare il gateway in modo efficace. Eseguire il training incrociato per un backup quando necessario.
  • Creare convenzioni di denominazione: creare convenzioni di denominazione del gateway che corrispondono allo scopo, all'ambiente, al nodo del cluster e ai casi d'uso supportati o alle operazioni eseguite.
  • Prendere in considerazione le esigenze delle risorse: determinare il carico di lavoro e l'utilizzo per determinare le risorse iniziali, ad esempio memoria e CPU.
  • Impostare le impostazioni del tenant di integrazione: esaminare e impostare le impostazioni del tenant di integrazione per assicurarsi che il gateway funzioni con l'accesso Single Sign-On (SSO) nel modo previsto.
  • Effettuare il provisioning del computer gateway: configurare una macchina virtuale always-on con risorse sufficienti per supportare le operazioni del gateway.
  • Installare il gateway: eseguire la prima configurazione del gateway nel computer gateway.
  • Installare elementi di supporto: installare connettori dati personalizzati o software dipendente per supportare lo scenario.

Gestire i gateway

Dopo aver installato i gateway, è necessario aggiungere connessioni all'origine dati. Quando si aggiungono queste connessioni, è necessario pianificare anche come gestire l'accesso al gateway e alle relative connessioni.

Aggiungere connessioni all'origine dati

Prima di poter usare il gateway, è necessario aggiungere le connessioni iniziali all'origine dati. È possibile aggiungere le connessioni manualmente dalla servizio Power BI o dall'interfaccia di amministrazione di Power Platform o a livello di codice con le API REST di Power BI.

Quando si aggiungono connessioni, prendere in considerazione i punti seguenti.

  • Credenziali archiviate: considerare quali credenziali verranno usate per connettersi all'origine dati. Quando si aggiunge una connessione, è necessario fornire le credenziali per l'origine dati , a meno che non supporti l'autenticazione anonima. È una decisione importante, perché tutte le query all'origine dati vengono eseguite usando queste credenziali, a meno che non si usi l'accesso Single Sign-On (SSO) di Microsoft Entra per il gateway dati.
  • Convenzioni di denominazione: come i gateway, le connessioni devono usare anche convenzioni di denominazione logiche e coerenti. Verificare che i nomi di connessione corrispondano al nome dell'origine dati. Ad esempio: FinanceDB-Prod è un nome logico che indica l'origine dati.
  • Single Sign-On: nelle impostazioni di amministratore di Fabric è necessario abilitare l'opzione Single Sign-On (SSO) di Microsoft Entra per il gateway quando si vuole usare l'accesso Single Sign-On (SSO) con DirectQuery (tramite SSO di Active Directory o Microsoft Entra SSO). È consigliabile usare l'accesso Single Sign-On quando si vuole applicare la sicurezza dei dati nel sistema di origine dati in base all'identità utente del report.
  • Livelli di privacy: per le connessioni all'origine dati di importazione, è necessario impostare il livello di privacy. Assicurarsi di selezionare il livello di privacy appropriato per isolare in modo appropriato l'origine dati, se necessario. È importante comprendere che i livelli di privacy impostati in Power BI Desktop non vengono rispettati dai gateway.

Nota

Il nome dell'origine dati può essere modificato in seguito, ma i nomi del server e del database non possono essere modificati dopo la configurazione. Per evitare errori, assicurarsi che le informazioni sull'origine dati corrispondano a ciò che verrà usato in Power BI Desktop.

Suggerimento

Per migliorare l'efficienza e l'accuratezza, è consigliabile automatizzare la creazione di connessioni all'origine dati usando le API REST di Power BI. In questo caso, è consigliabile includere processi di revisione e approvazione anziché elaborare automaticamente ogni richiesta che crea o aggiorna una connessione.

Effettuare il provisioning dell'accesso al gateway

Dopo aver aggiunto le connessioni iniziali all'origine dati, è necessario decidere come gestire l'accesso sia al gateway che alle relative connessioni.

Gli autori di contenuti dovranno accedere a una connessione gateway per connettersi correttamente a un'origine dati. L'accesso utente alle connessioni gateway viene eseguito per ogni connessione, quindi considerare chi deve accedere a ogni connessione gateway e come gestire tale accesso. È consigliabile gestire l'accesso usando i ruoli di sicurezza sia per i gateway che per leconnessioni.

Ruoli del gateway

I ruoli del gateway consentono di controllare chi può gestire il gateway e le relative connessioni all'origine dati. Questi ruoli funzionano in modo analogo ai ruoli dell'area di lavoro, consentendo autorizzazioni diverse a seconda del ruolo. L'uso dei ruoli consente di gestire l'accesso al gateway in modo più efficace.

Suggerimento

È consigliabile usare i gruppi di sicurezza per gestire l'appartenenza ai ruoli anziché i singoli account. In questo modo, è più facile gestire gli utenti, in particolare tra più gateway. È possibile usare gli stessi gruppi di sicurezza per gestire altri controlli di accesso, ad esempio l'appartenenza ai ruoli di sicurezza a livello di riga e l'appartenenza ai gruppi di destinatari delle app.

Importante

Un utente che deve solo usare il gateway per connettersi a un'origine dati non deve appartenere a un ruolo del gateway. In questo caso, avranno solo il ruolo Connessione utente .

Esistono tre ruoli del gateway per la gestione di un gateway standard locale.

  • Amministrazione: I membri di questo ruolo possono gestire e aggiornare il gateway. Un amministratore del gateway è in genere il proprietario del gateway, ma può essere presente anche più amministratori per un gateway. Gli amministratori del gateway devono essere amministratori dell'infrastruttura o membri del team di BUSINESS intelligence centrale o COE. Le responsabilità di un amministratore sono le stesse di un proprietario del gateway.
  • Connessione creatore con condivisione: I membri di questo ruolo possono creare connessioni gateway, testare lo stato del gateway e condividere il gateway con altri utenti. Questo ruolo non può rimuovere gli utenti dal gateway. Prendere in considerazione l'aggiunta di un utente a questo ruolo quando sono responsabili di un subset di soluzioni analitiche, ad esempio in un team decentralizzato per una business unit. Le responsabilità di un utente con questo ruolo includono:
    • Configurazione e test di nuove connessioni.
    • Gestione delle connessioni di cui sono proprietari, ad esempio l'impostazione delle credenziali.
    • Condivisione del gateway con altri utenti che ne hanno bisogno.
    • Verifica regolarmente chi ha accesso a un gateway, convalidando se è ancora necessario e rimuovendoli quando non ne hanno bisogno.
  • Connessione creatore: I membri di questo ruolo possono creare connessioni nel gateway e testarne lo stato. L'autore della connessione deve essere un proprietario del contenuto che può configurare in modo appropriato le connessioni corrette per l'uso del gateway. Le responsabilità di un ruolo creatore di Connessione ion sono le stesse dell'autore Connessione ion con ruolo di condivisione, ad eccezione del fatto che non possono condividere l'accesso al gateway.

Nota

I gateway di rete virtuale supportano solo il ruolo del gateway Amministrazione.

Ruoli di connessione all'origine dati

I ruoli di connessione all'origine dati consentono di controllare chi può usare, gestire e condividere le connessioni. Un utente con un ruolo di connessione non deve appartenere a un ruolo del gateway.

Esistono tre ruoli di connessione all'origine dati.

  • Proprietario: i membri di questo ruolo possono gestire la connessione o eliminarla quando non è più necessaria. I proprietari possono gestire i ruoli di connessione, inclusa l'aggiunta di altri proprietari di connessione. Un proprietario è in genere anche un creatore di connessioni. Prendere in considerazione la possibilità di rendere un proprietario di una connessione quando è l'amministratore o l'amministratore di tale origine dati oppure avere una conoscenza significativa dell'origine dati e del relativo contenuto. Le responsabilità di un proprietario includono:
    • Gestione delle connessioni, ad esempio l'aggiornamento delle credenziali, se necessario.
    • Eliminazione della connessione quando non è più necessaria.
    • Gestione dei ruoli di connessione dall'interfaccia di amministrazione di Power Platform.
  • Utente con condivisione: i membri di questo ruolo possono usare e condividere l'origine dati aggiungendo altri utenti. Prendere in considerazione l'aggiunta di un utente a questo ruolo quando svolgono un ruolo importante nella community degli utenti. I promotori possono essere candidati validi per questo ruolo. Le responsabilità di un utente con questo ruolo includono:
    • Condivisione della connessione con altri utenti che ne hanno bisogno.
    • Verifica regolarmente chi può accedere a una connessione, convalidando se è ancora necessario e rimuovendoli quando non ne hanno bisogno.
  • Utente: i membri di questo ruolo possono usare l'origine dati nei report di Power BI e nei flussi di dati di Power BI. Gli utenti sono responsabili solo dell'esecuzione di query sui dati dai carichi di lavoro e dagli strumenti client.

Suggerimento

Per evitare l'oversharing del rischio di governance, è necessario limitare chi può condividere gateway e connessioni a utenti specifici che possono eseguire questa attività in modo efficace e responsabile.

Gateway e connessioni documento

Dopo aver configurato il cluster gateway, è necessario documentarlo. È consigliabile documentare i gateway in modo che siano facili da trovare per gli autori di contenuti e semplificare la gestione degli amministratori del gateway. Prendere in considerazione l'archiviazione della documentazione del gateway in una posizione accessibile, ad esempio il portale centralizzato della community di pratica pertinente.

Prendere in considerazione la possibilità di documentare le informazioni seguenti.

  • Nome e GUID del gateway
  • Nome del computer gateway (e qualsiasi identificatore)
  • Proprietario del gateway
  • Data ultimo aggiornamento software (versione del gateway)
  • Scopo del cluster gateway (ad esempio l'ambiente, l'area geografica, l'area aziendale)
  • Quali connessioni all'origine dati devono essere mantenute in questo gateway
  • Indica se il gateway usa un'identità utente o credenziali archiviate
  • Criteri di gestione degli accessi (come si intende usare i ruoli del gateway e i ruoli di connessione)

Importante

Assicurarsi di documentare le chiavi di ripristino del gateway per i gateway in modalità standard. Queste chiavi di ripristino sono necessarie se è necessario ripristinare o individuare nuovamente il gateway. Mantenere queste informazioni in un luogo sicuro e sicuro accessibile a più persone attendibili in un team centrale. Se si dispone di un insieme di credenziali delle password dell'organizzazione, si tratta di una posizione ideale.

Aggiorna gateway

Per garantire che i gateway rimangano funzionali e funzionino correttamente, è necessario eseguire diverse attività.

  • Installare gli aggiornamenti di Windows ed eseguire altre operazioni di manutenzione del server.
  • Aggiornare il software del gateway. Il software gateway viene aggiornato mensilmente e Microsoft supporta solo le ultime sei versioni del gateway locale.
  • Aggiornare connettori dati personalizzati, driver e librerie, se necessario.

Nota

Il proprietario del gateway deve applicare manualmente gli aggiornamenti del gateway a ogni gateway. Per questo motivo, è importante pianificare periodicamente un processo per aggiornare i gateway.

Suggerimento

Quando si usa l'esperienza Power Query Online, il motore di Power Query usa la versione più recente di Power Query disponibile. Tuttavia, quando si usa un gateway per applicare trasformazioni, viene usata la versione installata nel computer gateway. Per garantire un'esperienza utente coerente, è importante mantenere aggiornati i computer gateway.

Nella parte restante di questa sezione viene descritto come aggiornare il software gateway.

Installare gli aggiornamenti nei gateway di sviluppo o test

È importante mantenere aggiornati i gateway per evitare interruzioni impreviste e anche per trarre vantaggio dai miglioramenti più recenti. Tuttavia, gli aggiornamenti possono avere conseguenze impreviste per le prestazioni e la funzione del gateway. Per evitare di influire sulle soluzioni critiche per l'azienda, è necessario installare gli aggiornamenti software del gateway in un gateway di sviluppo o di test prima che vengano applicati ai gateway che supportano gli ambienti di produzione.

Convalidare gli aggiornamenti

È possibile testare i gateway applicando prima l'aggiornamento ai gateway che supportano ambienti di sviluppo e test.

Quando si convalidano gli aggiornamenti del gateway, tenere presente quanto segue.

  • Definire condizioni di test ripetibili: è necessario definire un elenco di condizioni di test ripetibili per assicurarsi di testare tutte le operazioni e le origini dati del gateway pertinenti. Ad esempio, è possibile identificare i report e i modelli semantici considerati critici e richiedere la convalida. Potrebbero essere soddisfatti anche alcuni requisiti di conformità che si qualificano come condizioni di test ripetibili.
  • Usare un set di report di test: mantenere un set di report da usare per i test funzionali ogni volta che il gateway viene aggiornato. Questi report consentono di convalidare rapidamente le condizioni di test ripetibili. Questi report di test spesso mostrano solo totali e conteggi. L'obiettivo è assicurarsi di testare l'accesso, il rendering e l'aggiornamento per:
    • Ogni origine dati usata comunemente.
    • Ogni tipo di chiave dell'elemento di dati, ad esempio i modelli semantici più critici.
    • Modalità di archiviazione diverse, ad esempio l'importazione e DirectQuery.
  • Identificare i report critici per l'azienda: avere accesso a (o copie di) report business critical che è possibile testare per il nuovo aggiornamento. Questi report consentono di garantire che i dati possano essere aggiornati e che i report DirectQuery funzionino come previsto.
  • Automatizzare i processi di test: usare le API REST di Power BI per testare l'aggiornamento dei dati per importare gli elementi di dati e valutare le query DAX. Assicurarsi che sia possibile rilevare e registrare errori di aggiornamento o errori di query.

Importante

È consigliabile testare gli aggiornamenti del gateway nel cluster di sviluppo e test prima di applicarli all'ambiente di produzione. I test degli aggiornamenti sono importanti, perché non è presente alcun processo di rollback. In alternativa, prima di avviare l'aggiornamento è possibile creare un'immagine di macchina virtuale, ovvero una copia completa della struttura del file system e dei dati nel computer.

Installare gli aggiornamenti nell'ambiente di produzione

Dopo aver convalidato l'aggiornamento del gateway, è necessario applicare l'aggiornamento a tutti i gateway che supportano gli ambienti di produzione. Un gateway non è disponibile durante l'aggiornamento, quindi è consigliabile essere coerenti in quando e come aggiornare i gateway.

Considerare i punti seguenti sull'aggiornamento dei gateway.

  • Nel portale centralizzato documentare la versione corrente del gateway.
  • Applicare gli aggiornamenti durante i periodi di utilizzo del gateway storicamente basso.
  • Usare una pianificazione coerente quando si testano e si applicano gli aggiornamenti. Se gli aggiornamenti mensili sono troppo spesso, assicurarsi che i gateway vengano aggiornati almeno trimestralmente.
  • Aggiornare un computer del cluster gateway alla volta. Ruotando attraverso ogni computer, è possibile evitare tempi di inattività.

Aggiornare le credenziali

Per le connessioni all'origine dati che richiedono credenziali archiviate, potrebbe essere necessario ruotare regolarmente le credenziali. Ad esempio, l'organizzazione potrebbe avere un criterio che richiede la reimpostazione frequente delle password. Questa procedura è utile anche quando un membro del team chiave lascia l'organizzazione. Per migliorare l'efficienza, è possibile usare le API REST di Power BI per aggiornare le credenziali.

Elenco di controllo : quando si gestiscono i gateway dati, le decisioni chiave e le azioni includono:

  • Creare connessioni all'origine dati: configurare le connessioni all'origine dati per le origini dati aziendali comuni. Assicurarsi che le connessioni seguano convenzioni di denominazione chiare e coerenti.
  • Documentare gateway e origini dati: creare una documentazione concisa sui gateway e sulle connessioni. Assicurarsi che questa documentazione sia facilmente accessibile dal portale centralizzato per i proprietari e gli amministratori dei gateway.
  • Gestire le richieste di connessione: creare un processo per raccogliere e gestire le richieste di connessione. Determinare se è necessario un processo di approvazione per le richieste di connessione. Valutare la possibilità di automatizzare il processo usando le API REST di Power BI.
  • Effettuare il provisioning dei ruoli del gateway: usare il principio dei privilegi minimi per assegnare utenti ai ruoli del gateway. Prendere in considerazione l'aggiunta di amministratori dell'origine dati all'autore di Connessione ion o all'autore di Connessione ion con ruolo di condivisione in modo che possano contribuire alla gestione delle connessioni.
  • Effettuare il provisioning dei ruoli di connessione: assegnare autori di contenuti (e consumer, se applicabile) ai ruoli di connessione in modo che possano usare il gateway. Limitare gli utenti con la condivisione a tali utenti che condivideranno in modo responsabile la connessione e aiuteranno a esaminare e gestire regolarmente l'accesso.
  • Creare una documentazione utente concisa: documentare gli elementi chiave importanti per gli autori di contenuti per trovare e usare il gateway e le relative connessioni. Inserire la documentazione in un punto centrale e facilmente accessibile alla community degli utenti, ad esempio un portale centralizzato o un sito di supporto di SharePoint.
  • Documentare e archiviare con attenzione le chiavi di ripristino: archiviare le chiavi di ripristino in una posizione sicura e sicura accessibile a più membri del team. Assicurarsi che possano essere facilmente trovati se è necessario ripristinare il gateway.
  • Creare un processo per l'installazione degli aggiornamenti: determinare la frequenza con cui verranno installati gli aggiornamenti software del gateway e il processo da seguire. Mirare ad aggiornare i gateway entro uno o tre mesi dalla versione dell'aggiornamento.
  • Installare prima gli aggiornamenti del gateway in fase di sviluppo e test: assicurarsi che i gateway di sviluppo e test vengano aggiornati prima dell'ambiente di produzione e usati per i test iniziali.
  • Testare gli aggiornamenti del gateway prima che vengano applicati ai gateway di produzione: configurare un processo per testare gli aggiornamenti mensili del gateway usando condizioni di test ripetibili ed elementi.
  • Installare gli aggiornamenti del gateway tempestivamente e regolarmente nell'ambiente di produzione: assicurarsi che i gateway di produzione siano sempre aggiornati.
  • Aggiornare le credenziali di connessione: se necessario, aggiornare le credenziali archiviate usate dalle connessioni.

Monitorare, controllare e ottimizzare i gateway

I gateway sono una parte fondamentale dell'integrazione dei dati di Fabric. Per evitare interruzioni e ridurre i rischi, è necessario monitorare e controllare regolarmente i gateway nel tenant.

Il monitoraggio dei gateway consente di:

  • Attenuare i rischi di governance.
  • Evitare problemi.
  • Analizzare gli eventi imprevisti, ad esempio problemi di prestazioni o errori di aggiornamento dei dati.

La tabella seguente offre una panoramica dei problemi tipici che possono verificarsi durante la gestione di un cluster del gateway dati e come monitorare o analizzare i problemi.

Potenziale problema Tipo di problema Come monitorare o analizzare il problema
Troppi gateway Governance • Interfaccia di amministrazione di Power Platform

• Cmdlet di PowerShell per gateway

• API REST di Power BI
Oversharing del gateway Governance • Interfaccia di amministrazione di Power Platform

• Cmdlet di PowerShell per gateway

• API REST di Power BI

• Log attività di Power BI
Il gateway è offline Prestazioni e disponibilità • Interfaccia di amministrazione di Power Platform

• Monitoraggio del computer gateway

• Log del gateway
Errori del gateway Prestazioni e disponibilità • Log del gateway
Errori di query Prestazioni e disponibilità • Log del gateway

• Log del gateway (registrazione aggiuntiva)
Aggiornamenti lenti o query Prestazioni e disponibilità • Monitoraggio del computer gateway

• Registro eventi di Windows

• Contatori delle prestazioni di Windows

• Log del gateway

• Log del gateway (registrazione aggiuntiva)

• Strumenti di monitoraggio del server

Suggerimento

Se si usa la capacità di Infrastruttura, gli strumenti in Fabric possono fornire i componenti ideali per creare e orchestrare una soluzione di monitoraggio del gateway aziendale. Ad esempio, è possibile:

  • Usare Data Factory per copiare i log del gateway e inserirli in OneLake.
  • Usare i notebook per raccogliere informazioni sul gateway a livello di codice usando le API REST di Power BI e trasformare i file di log del gateway in tabelle.
  • Usare Power BI per creare un modello semantico e un report sull'integrità del gateway.
  • Usare Data Activator per inviare avvisi a proprietari e amministratori del gateway in caso di anomalie o interruzioni.

Monitorare i gateway

È consigliabile esaminare regolarmente il numero di gateway installati nel tenant e gli utenti che li hanno installati. È possibile monitorare la prevalenza dalla pagina connessioni e gateway del portale di Infrastruttura e dall'interfaccia di amministrazione di Power Platform. Entrambe le viste offrono una panoramica concisa e funzionale di tutti i gateway a cui si ha accesso. Amministrazione istrators dovrebbero esaminare regolarmente queste informazioni.

Nota

È anche possibile recuperare un elenco di gateway a livello di codice usando i cmdlet di PowerShell o usando le API REST di Power BI. È anche possibile identificare gli eventi di installazione del gateway usando il log attività.

Valutare la possibilità di combinare queste informazioni con l'analisi aggregata sul numero e sul tipo di origini dati del gateway. È possibile presentare queste informazioni in report consolidati, a livello di tenant o di controllo e monitoraggio.

Quando si monitora la prevalenza del gateway, concentrarsi sulle metriche seguenti.

  • Aumento del numero di gateway o programmi di installazione: assicurarsi di analizzare nuovi gateway o programmi di installazione imprevisti.
  • Ridondanza nelle connessioni tra i gateway: provare a consolidare le connessioni per evitare interventi di manutenzione aggiuntivi dei gateway.
  • Programmi di installazione o gateway imprevisti: assicurarsi che tutti i nuovi programmi di installazione o gateway abbiano subito un processo di approvazione prima dell'installazione.
  • Computer gateway, connessioni o configurazione imprevisti: assicurarsi di identificare eventuali proprietà del gateway anomale, ad esempio i gateway installati nei computer utente o le connessioni ai file locali. Identificare anche le impostazioni che creano rischi, ad esempio ignorando il livello di privacy.

Raccogliere e analizzare i log del gateway

Ogni computer gateway produce log dettagliati che è possibile usare per identificare e risolvere i problemi. Questi log sono una raccolta di file tecnici dettagliati archiviati nel computer gateway. È anche possibile abilitare temporaneamente log aggiuntivi dall'app gateway locale per raccogliere informazioni più dettagliate sulle query e sui relativi tempi.

Per evitare ritardi di rete, è consigliabile consentire la scrittura dei log del gateway nel computer gateway locale. È tuttavia possibile scegliere di modificare il percorso in cui vengono scritti i log con i file di configurazione del gateway. È anche possibile aggiornare per quanto tempo vengono conservati i log. Creare sempre una copia dei file di configurazione prima di modificarli.

Creare una soluzione di integrazione dei dati per raccogliere e consolidare i file di log da ogni computer gateway in modo da poter analizzare i dati. Idealmente, questo processo deve essere automatizzato e restituito in un report analitico per visualizzare facilmente tutti i gateway e identificare le anomalie.

Suggerimento

Prendere in considerazione l'uso degli avvisi dati per notificare agli amministratori del gateway e agli autori di connessioni all'origine dati le attività anomale rispettivamente per i gateway e le connessioni. In questo modo, possono eseguire azioni correttive immediate.

Monitorare l'integrità del computer gateway

L'integrità del gateway dipende dall'integrità del server. Per evitare interruzioni, è necessario monitorare i computer gateway per rilevare quando un computer non funziona correttamente o è offline.

Suggerimento

Assicurarsi che il computer gateway venga aggiunto a qualsiasi strumento di monitoraggio aziendale usato dall'organizzazione per monitorare i server.

Ottimizzare e risolvere i problemi dei gateway

Quando si verificano problemi con un gateway, è necessario analizzare e identificare il problema. In genere, la risoluzione dei problemi comporta l'analisi dei log del gateway descritti nella sezione precedente e il test di varie ottimizzazioni per verificare se risolvono il problema.

Ecco alcune ottimizzazioni del gateway comuni.

Importante

I gateway di rete virtuale hanno una singola configurazione hardware, che non può essere ridimensionata o modificata.

Elenco di controllo : quando si monitora i gateway, le decisioni chiave e le azioni includono:

  • Monitorare i computer gateway: verificare che i gateway siano installati nei computer monitorati dalle soluzioni di monitoraggio aziendali. In caso contrario, assicurarsi di poter rilevare quando questi computer non funzionano correttamente.
  • Misurare la prevalenza del gateway: monitorare l'evoluzione del numero di gateway installati nel tenant nel tempo.
  • Raccogliere e analizzare i log del gateway: creare una soluzione per raccogliere e combinare automaticamente i file di log dai diversi computer gateway. Analizzare questi file per estrarre informazioni significative. Valutare la possibilità di configurare due tipi di soluzioni di monitoraggio analitico: una per avvisi e azioni e un'altra per l'analisi esplorativa della causa radice quando si verificano problemi.
  • Verificare ruoli e responsabilità: assicurarsi che i ruoli e le responsabilità siano definiti per il monitoraggio, l'ottimizzazione e la risoluzione dei problemi.

Per altre considerazioni, azioni, criteri decisionali e consigli utili per prendere decisioni di implementazione di Power BI, vedere Pianificazione dell'implementazione di Power BI.