Überlegungen zu lokalen Datengateways für Datenziele in Dataflow Gen2
Dieser Artikel versucht, die Einschränkungen und Überlegungen bei der Verwendung des Datengateways mit Datenzielszenarien in Dataflow Gen2 aufzulisten.
Auswertungstimeouts
Dataflows, die ein Gateway und das Datenzielfeature verwenden, sind auf eine Auswertungs- oder Aktualisierungszeit von einer Stunde beschränkt.
Weitere Informationen zu dieser Einschränkung finden Sie im Artikel über die Problembehandlung für das lokale Datengateway.
Netzwerkprobleme mit Port 1433
Wenn Sie Microsoft Fabric Dataflow Gen2 mit einem lokalen Datengateway verwenden, können Probleme mit dem Aktualisierungsprozess des Dataflows auftreten. Das zugrunde liegende Problem tritt auf, wenn das Gateway keine Verbindung mit dem Staging-Lakehouse des Dataflows herstellen kann, um die Daten vor dem Kopieren in das gewünschte Datenziel zu lesen. Dieses Problem kann unabhängig vom Typ des verwendeten Datenziels auftreten.
Während der gesamten Dataflowaktualisierung kann die Tabellenaktualisierung als „Erfolgreich“ angezeigt werden, aber der Abschnitt „Aktivitäten“ wird als „Fehler“ angezeigt. Die Fehlerdetails für die Aktivität WriteToDatabaseTableFrom_...
weisen auf den folgenden Fehler hin:
Mashup Exception Error: Couldn't refresh the entity because of an issue with the mashup document MashupException.Error: Microsoft SQL: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 - An attempt was made to access a socket in a way forbidden by its access permissions.) Details: DataSourceKind = Lakehouse;DataSourcePath = Lakehouse;Message = A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 - An attempt was made to access a socket in a way forbidden by its access permissions.);ErrorCode = -2146232060;Number = 10013
Hinweis
Aus architektonischer Sicht verwendet die Dataflow-Engine einen HTTPS-Endpunkt (Port 443), um Daten in ein Lakehouse zu schreiben. Das Lesen von Daten aus dem Lakehouse erfordert jedoch die Verwendung des TDS-Protokolls (TCP über Port 1433). Dieses Protokoll wird verwendet, um die Daten aus dem Staging-Lakehouse in das Datenziel zu kopieren. Dies erklärt, warum der Schritt zum Laden von Tabellen erfolgreich ist, während die Datenzielaktivität fehlschlägt, auch wenn sich beide Lakehouses in der gleichen OneLake-Instanz befinden.
Problembehandlung
Um das Problem zu beheben, führen Sie die folgenden Schritte aus:
Vergewissern Sie sich, dass der Dataflow mit einem Datenziel konfiguriert ist.
Stellen Sie sicher, dass die Dataflowaktualisierung fehlschlägt, wobei die Tabellenaktualisierung als „Erfolgreich und Aktivitäten als „Fehler“ angezeigt werden.
Überprüfen Sie die Fehlerdetails für die Aktivität
WriteToDatabaseTableFrom_...
, die Informationen zum aufgetretenen Fehler bereitstellen.
Lösung: Festlegen neuer Firewallregeln auf dem Server, auf dem das Gateway ausgeführt wird
Die Firewallregeln auf dem Gatewayserver und/oder den Proxyservern des Kunden müssen aktualisiert werden, um ausgehenden Datenverkehr vom Gatewayserver zu den folgenden Endpunkten zuzulassen. Wenn Ihre Firewall keine Wildcards unterstützt, verwenden Sie die IP-Adressen aus Azure-IP-Bereiche und -Diensttags. Beachten Sie, dass sie jeden Monat synchronisiert werden müssen.
- Protokoll: TCP
- Endpunkte: *.datawarehouse.pbidedicated.windows.net, *.datawarehouse.fabric.microsoft.com, *.dfs.fabric.microsoft.com
- Port: 1433
Hinweis
In bestimmten Szenarien, insbesondere wenn sich die Kapazität in einer Region befindet, die nicht am nächsten zum Gateway ist, muss die Firewall möglicherweise so konfiguriert werden, dass der Zugriff auf mehrere Endpunkte (*cloudapp.azure.com) ermöglicht wird. Diese Anpassung ist erforderlich, um Umleitungen aufzunehmen, die unter diesen Bedingungen auftreten können. Wenn der Datenverkehr, der an *.cloudapp.azure.com gerichtet ist, nicht von der Regel abgefangen wird, können Sie alternativ die IP-Adressen für Ihre Datenregion in Ihrer Firewall zulassen.
Wenn Sie den Bereich des Endpunkts auf die tatsächliche OneLake-Instanz in einem Arbeitsbereich eingrenzen möchten (anstelle des Platzhalters *.datawarehouse.pbidedicated.windows.net), können Sie diese URL ermitteln, indem Sie zum Fabric-Arbeitsbereich navigieren, nach DataflowsStagingLakehouse
suchen und Details anzeigen auswählen. Kopieren Sie dann die SQL-Verbindungszeichenfolge, und fügen Sie sie ein.
Der vollständige Endpunktname sieht in etwa wie im folgenden Beispiel aus:
x6eps4xrq2xudenlfv6naeo3i4-l27nd6wdk4oephe4gz4j7mdzka.datawarehouse.pbidedicated.windows.net
Problemumgehung: Teilen des Dataflow in separate Dataflows für Erfassung und Laden
Wenn Sie die Firewallregeln nicht aktualisieren können, können Sie den Dataflow in zwei separate Dataflows aufteilen. Der erste Dataflow ist für die Erfassung der Daten in das Staging-Lakehouse verantwortlich. Der zweite Dataflow ist für das Laden der Daten aus dem Staging-Lakehouse in das Datenziel verantwortlich. Diese Problemumgehung ist nicht ideal, da sie die Verwendung von zwei separaten Dataflows erfordert, aber sie kann als temporäre Lösung verwendet werden, bis die Firewallregeln aktualisiert werden können.
Um diese Problemumgehung zu implementieren, führen Sie die folgenden Schritte aus:
Entfernen Sie das Datenziel aus Ihrem aktuellen Dataflow, der Daten über Ihr Gateway erfasst.
Erstellen Sie einen neuen Dataflow, der den Dataflowconnector zum Herstellen einer Verbindung mit dem Dataflow für die Erfassung verwendet. Dieser Dataflow ist für das Erfassen der Daten aus dem Stagingprozess in das Datenziel verantwortlich.
Legen Sie das Datenziel so fest, dass es für diesen neuen Dataflow das Datenziel Ihrer Wahl ist.
Optional können Sie den Stagingprozess für diesen neuen Dataflow deaktivieren. Durch diese Änderung wird verhindert, dass die Daten erneut in das Staging-Lakehouse kopiert werden, und die Daten stattdessen direkt vom Dataflow für die Erfassung in das Datenziel kopiert werden.