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.

Bei Verwendung von OAuth2-Anmeldeinformationen unterstützt das Gateway derzeit keine automatische Aktualisierung von Token, wenn Zugriffstoken ablaufen (eine Stunde nach Beginn der Aktualisierung). Diese Einschränkung für zeitintensive Aktualisierungen gilt für VNet-Gateways und lokale Datengateways.

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. Für die einzelnen Clouddienste gelten jedoch möglicherweise Lizenzbeschränkungen für die Verwendung von Gateways innerhalb des jeweiligen Diensts. Für Power BI ist eine Premium-Lizenz erforderlich. Alle Fabric-Lizenzen unterstützen das Gateway. Andere Dienste können auch Lizenzbeschränkungen besitzen.

Ü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 in der App „Dienste“ heißt der Dienst „Lokaler Datengatewaydienst“. Im Task-Manager auf der Registerkarte „Dienste“ lautet der Dienstname „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.

Es gilt eine Beschränkung von 1.000 Datenquellen pro Benutzer*in.

Wenn Sie die maximale Anzahl von Datenquellen erreicht haben, vergewissern Sie sich, dass die Anzahl der Datenquellen pro Benutzer*in den Grenzwert nicht überschritten hat. 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, sollten Sie stattdessen den Ordner auswä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 fehlerhaft war, ist das lokale Datengateway noch auf dem alten Server vorhanden, und 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.

• Wenn eine OAuth-Aktualisierung, die länger als eine Stunde dauert, mit dem Fehler „Ungültige Anmeldeinformationen für die Verbindung“ oder wegen einer Zeitüberschreitung abgebrochen wird, liegt das Problem wahrscheinlich darin, dass die Anmeldeinformationen abgelaufen sind.

Nächste Schritte

• Problembehandlung für das lokale Datengateway