Considérations sur la passerelle de données sur site pour les destinations de données dans Dataflow Gen2

Cet article tente de répertorier les limitations et les considérations relatives à l’utilisation de la passerelle de données avec des scénarios de destinations de données dans Dataflow Gen2.

Expiration de l’évaluation

Les flux de données qui utilisent une passerelle et la fonctionnalité de destination des données sont limités à une durée d’évaluation ou d’actualisation d’une heure.

Pour en savoir plus sur cette limitation, consultez l’article Résolution des problèmes de passerelle de données locale.

Problèmes de réseau avec le port 1433

Lorsque vous utilisez Microsoft Fabric Dataflow Gen2 avec une passerelle de données sur site, vous pouvez rencontrer des problèmes avec le processus d'actualisation du flux de données. Le problème sous-jacent se produit lorsque la passerelle ne parvient pas à se connecter au flux de données intermédiaire Lakehouse afin de lire les données avant de les copier vers la destination de données souhaitée. Ce problème peut se produire quel que soit le type de destination de données utilisé.

Lors de l'actualisation globale du flux de données, l'actualisation des tables peut s'afficher comme "Succeeded", mais la section des activités s'affiche comme "Failed". Les détails de l'erreur pour l'activité WriteToDatabaseTableFrom_... indiquent l'erreur suivante :

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

Remarque

Du point de vue architectural, le moteur de flux de données utilise un point de terminaison HTTPS sortant (port 443) pour écrire des données dans un lakehouse. Cependant, la lecture des données du Lakehouse nécessite l'utilisation du protocole TDS (TCP sur le port 1433). Ce protocole est utilisé pour copier les données du lac intermédiaire vers la destination des données. Cela explique pourquoi l'étape de chargement des tables réussit alors que l'activité de destination des données échoue, même lorsque les deux Lakehouses se trouvent dans la même instance OneLake.

Résolution des problèmes

Pour résoudre le problème, procédez comme suit :

  1. Vérifiez que le flux de données est configuré avec une destination de données.

    Capture d'écran de l'éditeur Power Query avec la destination des données Lakehouse mise en évidence.

  2. Vérifiez que l'actualisation du flux de données échoue, avec l'actualisation des tables indiquant "Succeeded" et les activités indiquant "Failed".

    Capture d'écran des détails du flux de données avec des tableaux indiquant les réussites et les échecs des activités.

  3. Passez en revue les détails de l'erreur pour l' activité WriteToDatabaseTableFrom_..., qui fournit des informations sur l'erreur rencontrée.

    Capture d'écran de l'activité WriteToDatabaseTablefrom affichant le message d'erreur.

Solution : définir de nouvelles règles de pare-feu sur le serveur exécutant la passerelle

Les règles de pare-feu sur le serveur de passerelle et/ou les serveurs proxy du client doivent être mises à jour pour autoriser le trafic sortant du serveur de passerelle vers les éléments suivants :

  • Protocole : TCP
  • Points de terminaison : *.datawarehouse.pbidedicated.windows.net, *.datawarehouse.fabric.microsoft.com, *.dfs.fabric.microsoft.com
  • Port: 1433

Remarque

Dans certains scénarios, notamment lorsque la capacité est située dans une région qui n’est pas la plus proche de la passerelle, il peut être nécessaire de configurer le pare-feu pour autoriser l’accès à plusieurs points de terminaison (*cloudapp.azure.com). Cet ajustement est nécessaire pour tenir compte des redirections qui peuvent se produire dans ces conditions. Si le trafic destiné à *.cloudapp.azure.com n’est pas intercepté par la règle, vous pouvez également autoriser les adresses IP de votre région de données dans votre pare-feu.

Si vous souhaitez limiter la portée du point de terminaison à l'instance réelle de OneLake dans un espace de travail (au lieu du caractère générique *.datawarehouse.pbidedicated.windows.net), cette URL peut être trouvée en accédant à l'espace de travail Fabric, en localisant DataflowsStagingLakehouse, et en sélectionnant Afficher les détails. Ensuite, copiez et collez la chaîne de connexion SQL.

Capture d'écran de l'espace de travail Fabric avec DataflowsStagingLakehouse, avec les points de suspension sélectionnés et l'option Afficher les détails en surbrillance.

Capture d'écran des informations détaillées de DataflowsStagingLakehouse, avec la chaîne de connexion SQL mise en évidence.

Le nom complet du point de terminaison ressemble à l'exemple suivant :

x6eps4xrq2xudenlfv6naeo3i4-l27nd6wdk4oephe4gz4j7mdzka.datawarehouse.pbidedicated.windows.net

Solution de contournement : fractionner le flux de données dans un flux de données d’ingestion et de chargement distinct

Si vous ne parvenez pas à mettre à jour les règles de pare-feu, vous pouvez fractionner le flux de données en deux flux de données distincts. Le premier flux de données est responsable de l’ingestion des données dans le lakehouse intermédiaire. Le deuxième flux de données est chargé de charger les données du lakehouse intermédiaire dans la destination des données. Cette solution de contournement n’est pas idéale, car elle nécessite l’utilisation de deux flux de données distincts, mais elle peut être utilisée comme solution temporaire jusqu’à ce que les règles de pare-feu puissent être mises à jour.

Pour implémenter cette solution de contournement, procédez comme suit :

  1. Supprimez la destination des données de votre flux de données actuel qui ingère des données via votre passerelle.

    Capture d’écran de l’éditeur Power Query avec la destination des données Lakehouse supprimée.

  2. Créez un flux de données qui utilise le connecteur de flux de données pour vous connecter au flux de données d’ingestion. Ce flux de données est responsable de l’ingestion des données de la préproduction dans la destination des données.

    Capture d’écran de l’éditeur Power Query avec l’option Obtenir des données sélectionnée et l’option Connecteur de flux de données mise en évidence.

    Capture d’écran de la boîte de dialogue Obtenir des données avec l’option Connecteur de flux de données sélectionnée.

  3. Définissez la destination des données comme destination de données de votre choix pour ce nouveau flux de données.

    Capture d’écran de l’éditeur Power Query avec la destination des données Lakehouse définie.

  4. Si vous le souhaitez, vous pouvez désactiver la mise en lots pour ce nouveau flux de données. Cette modification empêche la copie des données vers le lakehouse intermédiaire et copie les données directement du flux de données d’ingestion vers la destination des données.

    Capture d’écran de l’éditeur Power Query avec l’option de mise en lots désactivée.