Domande frequenti sul gateway dati locale

No, i servizi possono in genere connettersi a origini dati cloud senza un gateway. Potrebbe tuttavia essere necessario un gateway dati se le origini dati si trovano dietro un firewall, richiedono una VPN o si trovano in reti virtuali.

Quando si usano le credenziali OAuth2 in Dataflows Gen1, il gateway non supporta l'aggiornamento automatico dei token di aggiornamento alla scadenza dei token di accesso. I token in genere scadono 1 ora dopo l'avvio dell'aggiornamento, ma possono scadere in meno di 1 ora, a seconda dell'origine dati e dei criteri del tenant. I flussi di dati Gen2, i modelli semantici, le pipeline di dati sono in grado di aggiornare i token a metà flusso e non devono essere interessati a causa di questo problema.

Esaminare la sezione requisiti nell'articolo sull'installazione.

No, il gateway si connette all'origine dati usando le informazioni di connessione fornite. In questo senso, considerare il gateway come applicazione client. Il gateway deve solo connettersi al server specificato.

Attualmente, Microsoft supporta attivamente solo le ultime sei versioni del gateway dati locale. Viene rilasciato un nuovo aggiornamento per i gateway dati ogni mese.

Non sono previste restrizioni di licenza per l'installazione e la registrazione di un gateway.

Controllare che la connessione di rete abbia una buona velocità effettiva. Ogni ambiente è diverso e la velocità effettiva dipende dalla quantità di dati inviati. Per garantire un livello minimo di velocità effettiva tra l'origine dati locale e i data center di Azure, usare Azure ExpressRoute. Per misurare la velocità effettiva, usare l'app per i test della velocità Azure.

Le credenziali immesse per un'origine dati vengono crittografate e archiviate nel servizio cloud gateway. Le credenziali vengono decrittografate nel gateway locale. Per altre informazioni sulla crittografia delle credenziali in Power BI, vedere White paper sulla sicurezza di Power BI.

Nel computer locale, nell'app Servizi, il servizio è denominato "Servizio gateway dati locale". In Gestione attività, nella scheda Servizi, il nome del servizio è "PBIEgwService". Per impostazione predefinita, il servizio Windows usa "NT SERVICE\PBIEgwService" come SID del servizio (SSID).

No, il servizio Windows necessita di un account di Windows valido.

No, il gateway usa connessioni in uscita all'inoltro di Azure.

Passare a Abilita connessioni di Azure in uscita.

Se si blocca il traffico IP in uscita, potrebbe essere necessario sbloccare l'elenco di indirizzi IP del data center di Azure. Il gateway comunica con Inoltro di Azure usando un indirizzo IP e un nome di dominio completo. L'elenco di indirizzi IP del data center di Azure viene aggiornato ogni settimana. Per altre informazioni, vedere Abilitare le connessioni di Azure in uscita.

Per evitare la latenza di rete, installare il gateway il più vicino possibile all'origine dati. Se è possibile installare il gateway nell'origine dati effettiva, questo percorso più vicino riduce al minimo la latenza.

Considerare anche la prossimità ai data center di Azure. Ad esempio, se il servizio usa il data center Stati Uniti occidentali e SQL Server è ospitato in una macchina virtuale di Azure, è anche possibile che la macchina virtuale di Azure si trovi nell'area Stati Uniti occidentali. Questa configurazione riduce al minimo la latenza ed evita addebiti in uscita nella macchina virtuale di Azure.

I risultati vengono inviati tramite Inoltro di Azure. Per altre informazioni, vedere Architettura del gateway dati locale.

Il gateway richiede la connettività all'origine dati. Pertanto, se l'origine dati non è raggiungibile nella rete perimetrale, il gateway potrebbe non avere accesso.

Si supponga, ad esempio, che il computer SQL Server non si trova nella rete perimetrale. Si supponga inoltre di non potersi connettere al computer dalla rete perimetrale. Se si posiziona il gateway nella rete perimetrale, il gateway non riesce a raggiungere il computer SQL Server.

Sì.

Questa priorità dipende da Windows o dai driver dell'origine dati pertinenti. Questo comportamento è configurabile sia in Windows che in vari driver, ma non è sotto il controllo del gateway.

No, l'accesso microsoft Entra ID multi-tenant non è supportato. Un modello semantico di Power BI in un tenant non può connettersi alle origini dati da un tenant diverso usando un account MICROSOFT Entra ID. Questa limitazione si applica se l'origine dati usa o meno un gateway dati locale. Per superare questa limitazione, usare un tipo di autenticazione diverso da OAuth.

Sì, per altre informazioni, vedere Forzare la comunicazione HTTPS con Inoltro di Azure. L'attivazione di questa funzionalità ha un effetto minimo sulle prestazioni.

No, sono prodotti diversi. Per altre informazioni su Gestione dati Gateway, denominato runtime di integrazione self-hosted, vedere Creare e configurare un runtime di integrazione self-hosted.

Sì, è necessario usare PowerShell per aggiungere altri proprietari allo stesso gateway. Questi utenti possono creare il gateway nel portale di Azure. Tuttavia, devono connettersi al portale e al gateway usando lo stesso tenant.

No. Quando ci si connette a origini dati locali, è ancora necessario un gateway.

Altre informazioni: Mantenere i dati nell'area in cui sono archiviati

Per evitare un singolo punto di errore, è possibile configurare i gateway dati locali come cluster per la disponibilità elevata. Per impostazione predefinita, i servizi cloud come Power Apps e Power BI usano il gateway primario e fallback al gateway secondario se il database primario non è disponibile.

Quando si installa il gateway, si fornisce una chiave di ripristino. È possibile usare la chiave per ripristinare o eseguire la migrazione di un gateway.

La chiave consente di aggiungere un nuovo gateway a un cluster o di eseguire la migrazione, il ripristino o la gestione di un gateway.

Risoluzione dei problemi

Per altre informazioni, vedere Risolvere i problemi del gateway dati locale.

Passare a Strumenti di risoluzione dei problemi.

È possibile abilitare la traccia delle query attivando la registrazione aggiuntiva. I log includono le query inviate. Ricordarsi di disattivare la traccia delle query al termine della risoluzione dei problemi. Se la traccia delle query è abilitata, i log saranno più grandi.

È anche possibile esaminare gli strumenti dell'origine dati per le query di traccia. Ad esempio, se SQL Server e SQL Server Analysis Services sono origini dati, è possibile usare eventi estesi di SQL Server o SQL Server Profiler per tracciare le query.

Gli utenti sono limitati a 1.000 origini dati per utente.

Se si raggiunge il numero massimo di origini dati, verificare che il numero di origini dati per utente non sia superiore al limite. Per risolvere eventuali problemi correlati, è possibile rimuovere manualmente le origini dati dall'interfaccia di amministrazione o, in alternativa, usare lo script di PowerShell gateway seguente per trovare ed eliminare in blocco tutte le origini dati che superano il limite.

## https://learn.microsoft.com/powershell/module/datagateway/?view=datagateway-ps
## PowerShell version of '7.0.0' to run
## required module "DataGateway" Install-Module -Name DataGateway and sign in the same user who exceeded the 1000 limit
Connect-DataGatewayServiceAccount

## get the gateway information per the sign in person
$gatewayClusters = Get-DataGatewayCluster | where-Object {$_.Type -EQ 'Personal'}; 
foreach ($gw in $gatewayClusters)
{
  $datasources = Get-DataGatewayClusterDatasource -GatewayClusterId $gw.Id;
  foreach ($datasource in $datasources)
  {
    $datasource
    "gateway cluster id={0}, Personal Gateway={1}, datasource id={2}, datasourceType={3}, datasource connection details={4}" -f $gw.Id, $datasource.OnPremGatewayRequired, $datasource.Id, $datasource.DatasourceType, $datasource.ConnectionDetails 
   
    ## conditional logic to determine if name matches set
    ## Remove-DataGatewayClusterDatasource -GatewayClusterId $gw.Id -GatewayClusterDatasourceId $datasource.Id
  }
}

Ricerca per categorie evitare di raggiungere questo limite? Se si è un ISV o un altro proprietario di app Power BI Embedded con molti clienti, usare i profili dell'entità servizio per le app multi-tenancy in Power BI embedded. Se non si è un ISV, è possibile raggiungere questo limite perché si sta creando una nuova origine dati per ogni file CSV o Excel. Per risolvere questo problema, è possibile usare la "casella di caricamento file" in Power BI Desktop per selezionare più file di Excel, che crea più connessioni all'origine dati. In questo scenario, per assicurarsi che sia selezionata solo una singola origine dati, è consigliabile selezionare invece la cartella contenente tali file di Excel.

Sì, quando si gestisce un gateway, è possibile passare alla scheda dell'amministratore per aggiungere altri amministratori. È anche possibile avere gruppi di sicurezza come amministratori.

No, l'amministratore del gateway gestisce il gateway dall'interno del servizio.

Se il processo di migrazione non riesce nel nuovo server, il gateway dati locale esiste ancora nel server precedente. È comunque possibile eseguire il gateway a meno che il server non sia offline o che il software del gateway sia stato disinstallato. Tuttavia, per ripristinare il gateway nel server precedente, potrebbe essere richiesto di usare la chiave di ripristino del gateway.

Poiché la migrazione include solo due attività, l'installazione del gateway e il ripristino e la configurazione nel nuovo server, la migrazione può in genere essere completata tra 10 e 15 minuti.

Sì. Tuttavia, è possibile che durante questo periodo si verifichino errori e le migrazioni come queste dovrebbero essere eseguite in un intervallo di tempo di inattività. Altre informazioni: Ridurre al minimo i tempi di inattività della migrazione

Passaggi successivi

• Risolvere i problemi del gateway dati locale