Lokales Datengateway: Häufig gestellte Fragen

Nein, Dienste können allgemein und ohne Gateway Verbindungen mit Datenquellen in der Cloud herstellen. Möglicherweise benötigen Sie jedoch ein Datengateway, wenn sich Ihre Datenquellen hinter einer Firewall befinden, ein VPN erfordern oder sich in virtuellen Netzwerken befinden.

Wenn Sie OAuth2-Anmeldeinformationen in Dataflows Gen1 verwenden, unterstützt das Gateway das Automatische Aktualisieren von Token nicht, wenn Zugriffstoken ablaufen. Token laufen in der Regel 1 Stunde nach dem Start der Aktualisierung ab, können jedoch je nach Datenquelle und Mandantenrichtlinien in weniger als 1 Stunde ablaufen. Dataflows Gen2, Semantic models, Data pipelines are able to refresh tokens mid-stream and should not be impacted due this.

Lesen Sie den Abschnitt „Anforderungen“ im Artikel zur Installation.

Nein, das Gateway stellt eine Verbindung mit der Datenquelle her, indem es die bereitgestellten Verbindungsinformationen verwendet. Stellen Sie sich das Gateway in diesem Zusammenhang als Clientanwendung vor. Das Gateway muss nur eine Verbindung mit dem angegebenen Server herstellen.

Derzeit unterstützt Microsoft aktiv nur die letzten sechs Versionen des lokalen Datengateways. Wir veröffentlichen jeden Monat ein neues Update für Datengateways.

Es gibt keine Lizenzbeschränkungen für die Installation und Registrierung von Gateways.

Überprüfen Sie, ob die Netzwerkverbindung einen guten Durchsatz ermöglicht. Jede Umgebung ist anders, und der Durchsatz ist abhängig von der Menge der gesendeten Daten. Um einen Mindestdurchsatz zwischen Ihrer lokalen Datenquelle und Azure-Rechenzentren sicherzustellen, verwenden Sie Azure ExpressRoute. Zum Messen Ihres Durchsatzes können Sie die Azure-Geschwindigkeitstest-App verwenden.

Die Anmeldeinformationen, die Sie für eine Datenquelle eingeben, werden verschlüsselt und im Gatewayclouddienst gespeichert. Die Anmeldeinformationen werden auf dem Gateway lokal entschlüsselt. Weitere Informationen zur Verschlüsselung von Anmeldeinformationen in Power BI finden Sie im Whitepaper zur Power BI-Sicherheit.

Auf Ihrem lokalen Computer wird der Dienst in der Dienst-App als "Lokaler Datengatewaydienst" bezeichnet. Im Task-Manager lautet der Dienstname auf der Registerkarte "Dienste" "PBIEgwService". Standardmäßig verwendet der Windows-Dienst „NT SERVICE\PBIEgwService“ als Dienst-SID (SSID).

Nein, der Windows-Dienst benötigt ein gültiges Windows-Konto.

Nein, das Gateway nutzt ausgehende Verbindungen mit Azure Relay.

Weitere Informationen finden Sie unter Aktivieren von ausgehenden Azure-Verbindungen.

Wenn Sie ausgehenden IP-Datenverkehr blockieren, müssen Sie möglicherweise die IP-Adressliste des Azure-Rechenzentrums entsperren. Das Gateway kommuniziert mit Azure Relay unter Verwendung einer IP-Adresse und eines vollqualifizierten Domänennamens. Die Liste der Azure Datacenter-IP-Adressen wird wöchentlich aktualisiert. Weitere Informationen finden Sie unter Aktivieren von ausgehenden Azure-Verbindungen.

Installieren Sie das Gateway so nah wie möglich an der Datenquelle, um Netzwerklatenzen zu vermeiden. Wenn Sie das Gateway in der tatsächlichen Datenquelle installieren können, minimiert dieser nähere Standort die Latenz.

Berücksichtigen Sie auch die Nähe zu den Azure-Rechenzentren. Wenn Ihr Dienst beispielsweise das Rechenzentrum in „USA, Westen“ verwendet und der SQL Server auf einer Azure-VM gehostet wird, sollte Ihre Azure-VM sich idealerweise auch in der Region „USA, Westen“ befinden. Diese Konfiguration minimiert die Latenz und vermeidet ausufernde Kosten für die Azure-VM.

Die Ergebnisse werden über Azure Relay gesendet. Weitere Informationen finden Sie unter Architektur eines lokalen Datengateways.

Das Gateway erfordert eine Verbindung mit der Datenquelle. Wenn die Datenquelle in Ihrem Umkreisnetzwerk nicht erreichbar ist, hat das Gateway möglicherweise keinen Zugriff.

Angenommen, Ihr SQL Server-Computer befindet sich nicht in Ihrem Umkreisnetzwerk. Angenommen, Sie können darüber hinaus keine Verbindung mit diesem Computer über das Umkreisnetzwerk herstellen. Wenn Sie das Gateway in Ihrem Umkreisnetzwerk platzieren, kann das Gateway den SQL Server-Computer nicht erreichen.

Ja.

Diese Priorität hängt von Windows oder den entsprechenden Datenquellentreibern ab. Dieses Verhalten ist sowohl unter Windows als auch in verschiedenen Treibern konfigurierbar, unterliegt jedoch nicht der Kontrolle des Gateways.

Nein, der mandantenübergreifende Microsoft Entra ID-Zugriff wird nicht unterstützt. Ein Power BI-Semantimodell in einem Mandanten kann nicht mit einem Microsoft Entra ID-Konto eine Verbindung mit Datenquellen in einem anderen Mandanten herstellen. Diese Einschränkung gilt unabhängig davon, ob die Datenquelle ein lokales Datengateway verwendet. Um diese Einschränkung zu umgehen, verwenden Sie einen anderen Authentifizierungstyp als OAuth.

Ja, weitere Informationen finden Sie unter Erzwingen der HTTPS-Kommunikation mit Azure Relay. Das Aktivieren dieser Funktion hat nur geringe Auswirkungen auf die Leistung.

Nein, es sind unterschiedliche Produkte. Weitere Informationen zum Datenverwaltungsgateway, das jetzt als selbstgehostete Integration Runtime bezeichnet wird, finden Sie unter Erstellen und Konfigurieren einer selbstgehosteten Integration Runtime.

Ja, Sie müssen PowerShell verwenden, um demselben Gateway andere Besitzer*innen hinzuzufügen. Diese Benutzer*innen können das Gateway im Azure-Portal erstellen. Sie sollten jedoch mit demselben Mandanten eine Verbindung mit dem Portal und dem Gateway herstellen.

Nein. Für die Verbindung mit lokalen Datenquellen ist weiterhin ein Gateway erforderlich.

Weitere Informationen finden Sie unter Aufbewahren von Daten in der Region, in der sie gespeichert sind.

Um einen Single Point of Failure zu vermeiden, können Sie für Hochverfügbarkeit lokale Datengateways als Cluster festlegen. Standardmäßig verwenden Clouddienste wie Power Apps und Power BI das primäre Gateway und greifen auf das sekundäre Gateway zurück, wenn das primäre nicht verfügbar ist.

Sie geben bei der Installation des Gateways einen Wiederherstellungsschlüssel an. Sie können ein Gateway mithilfe des Schlüssels wiederherstellen oder migrieren.

Der Schlüssel bietet eine Möglichkeit, einem Cluster ein neues Gateway hinzuzufügen oder ein Gateway zu migrieren, wiederherzustellen oder zu übernehmen.

Problembehandlung

Weitere Informationen finden Sie unter Problembehandlung beim lokalen Datengateway.

Navigieren Sie zu Tools für die Problembehandlung.

Sie können die Abfrageverfolgung aktivieren, indem Sie Zusätzliche Protokollierung aktivieren. Die Protokolle enthalten die gesendeten Abfragen. Denken Sie daran, die Abfrageverfolgung zu deaktivieren, wenn Sie mit der Problembehandlung fertig sind. Wenn die Abfrageverfolgung aktiviert ist, werden die Protokolle größer.

Sie können sich auch die Tools Ihrer Datenquelle zum Verfolgen von Abfragen ansehen. Wenn SQL Server und SQL Server Analysis Services beispielsweise Datenquellen sind, können Sie SQL Server Extended Events oder SQL Server Profiler verwenden, um Abfragen zu verfolgen.

Benutzer sind auf 1.000 Datenquellen pro Benutzer beschränkt.

Wenn Sie die maximale Anzahl von Datenquellen erreichen, überprüfen Sie, ob die Anzahl der Datenquellen pro Benutzer nicht über dem Grenzwert liegt. Um verwandte Probleme zu beheben, können Sie das Admin Center verwenden, um die Datenquellen manuell zu entfernen, oder alternativ das folgende Gateway-PowerShell-Skript verwenden, um alle Datenquellen zu finden, die den Grenzwert überschreiten, und zusammen zu löschen.

## 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
  }
}

Wie kann ich das Überschreiten dieses Grenzwerts vermeiden? Wenn Sie ein ISV oder Besitzer*in anderer Power BI Embedded-Apps mit vielen Kund*innen sind, verwenden Sie Dienstprinzipalprofile für mehrinstanzenfähige Apps in Power BI Embedded. Wenn Sie kein ISV sind, erreichen Sie diesen Grenzwert möglicherweise, da Sie für jede CSV- oder Excel-Datei eine neue Datenquelle erstellen. Um dies zu beheben, sollten Sie das Feld „Datei hochladen“ in Power BI Desktop verwenden, um mehrere Excel-Dateien auszuwählen, da dadurch mehrere Datenquellenverbindungen erstellt werden. Wenn Sie in diesem Szenario sicherstellen möchten, dass nur eine einzelne Datenquelle ausgewählt ist, empfehlen wir, stattdessen den Ordner auszuwählen, der diese Excel-Dateien enthält.

Ja, wenn Sie ein Gateway verwalten, können Sie auf der Registerkarte „Administrator“ weitere Administrator*innen hinzufügen. Sie können auch Sicherheitsgruppen als Administrator*innen festlegen.

Nein, Gatewayadministrator*innen verwalten das Gateway aus dem Dienst heraus.

Wenn der Migrationsprozess auf dem neuen Server fehlschlägt, ist das lokale Datengateway weiterhin auf dem alten Server vorhanden. Sie können dieses Gateway weiterhin ausführen, es sei denn, der Server ist offline oder die Gatewaysoftware wurde deinstalliert. Um das Gateway auf dem alten Server wiederherzustellen, werden Sie jedoch möglicherweise aufgefordert, Ihren Wiederherstellungsschlüssel für das Gateway zu verwenden.

Da die Migration nur zwei Aufgaben umfasst – die Installation des Gateways und die Wiederherstellung und Konfiguration auf dem neuen Server –, kann die Migration normalerweise in 10 bis 15 Minuten abgeschlossen werden.

Ja. Während dieser Zeit besteht jedoch eine hohe Fehlerwahrscheinlichkeit, und Migrationsvorgänge wie diese sollten in einem Ausfallzeitfenster durchgeführt werden. Weitere Informationen finden Sie unter Minimieren der Ausfallzeit bei der Migration.

Nächste Schritte

• Problembehandlung für das lokale Datengateway