Aller au contenu principal
Dernière mise à jour le

Recommandations réseau pour Lakehouse Federation

Cet article fournit des conseils pour la mise en place d'un chemin réseau viable entre vos clusters Databricks ou vos SQL Warehouses et le système de base de données externe auquel vous vous connectez à l'aide de Lakehouse Federation.

Veuillez prendre en compte les points suivants lors de la configuration de la connectivité réseau pour Lakehouse Federation :

  • Tout le trafic réseau pour les queries fédérées est directement entre les clusters Databricks (ou SQL Warehouse) et le système de base de données externe. Ni Unity Catalog ni le plan de contrôle Databricks ne se trouvent sur le chemin du réseau.
  • Les connexions qui utilisent OAuth ont une exigence supplémentaire. Lorsqu'une connexion s'authentifie avec OAuth, l'échange de jetons OAuth s'effectue à partir du plan de contrôle Databricks, et non du plan de compute. Le plan de contrôle doit pouvoir atteindre l'Endpoint OAuth du système externe. L'inscription sur liste blanche du plan de compute uniquement n'est pas suffisante pour ces connexions. Pour des conseils spécifiques aux connecteurs, consultez la section sur la mise en réseau ou les limitations de la page de connexion pertinente, telle que Exécuter des requêtes fédérées sur Snowflake (OAuth) ou Exécuter des requêtes fédérées sur Microsoft SQL Server. Les connexions HTTP constituent une exception ; elles acheminent l'OAuth via le plan de calcul serverless plutôt que le plan de contrôle.
  • Le compute Databricks (c'est-à-dire, les clusters et les SQL Warehouse) se déploie toujours dans le cloud, mais le système de base de données externe peut être on-premise ou hébergé sur n'importe quel fournisseur de cloud, tant qu'il existe un chemin réseau viable entre votre compute Databricks et la base de données externe.
  • Si vous avez des restrictions réseau entrantes ou sortantes sur le compute Databricks ou le système de base de données externe, reportez-vous aux sections suivantes pour obtenir des conseils généraux afin de vous aider à créer un chemin réseau viable.

Pour plus d'informations sur le réseautage dans les workspaces Databricks, consultez Réseautage.

Le système de base de données et le compute Databricks sont tous deux accessibles depuis Internet​

La connexion devrait fonctionner sans configuration.

Le système de base de données a des restrictions d'accès au réseau​

Si le système de base de données externe présente des restrictions d'accès réseau entrantes ou sortantes et que le cluster Databricks ou le SQL Warehouse est accessible depuis Internet, configurez l'une des solutions réseau suivantes pour vous connecter à partir de ressources de compute classiques :

  • Adresse IP de sortie stable sur le compute Databricks.

    Depuis le plan de compute classique, configurez une adresse IP stable avec un équilibreur de charge, une passerelle NAT, une passerelle Internet ou un équivalent, et connectez-la au sous-réseau où le compute Databricks est déployé. Ceci permet à la ressource de compute de partager une adresse IP publique stable qui peut être mise en liste blanche côté base de données externe.

À partir du plan de compute serverless, Databricks publie son IP sortante, que le système de base de données externe peut ajouter à une liste verte. Vous devez maintenir ces adresses IP à jour en mettant en place une automatisation. Consultez la configuration du pare-feu du compute Serverless.

Depuis le plan de compute classique, le système de base de données externe doit ajouter à la liste blanche l'IP stable du compute Databricks pour le trafic entrant et sortant.

  • Private Link (uniquement lorsque la base de données externe se trouve sur le même cloud que le compute Databricks)

    À partir du plan de compute classique, configurez une connexion de Private Link entre le réseau où la base de données est déployée et le réseau où le compute Databricks est déployé.

Le compute Databricks a des restrictions d'accès au réseau​

Si le système de base de données externe est accessible depuis Internet et que le compute Databricks a des restrictions d'accès réseau entrantes ou sortantes (ce qui n'est possible que si vous êtes sur un réseau géré par le client), alors effectuez l'une des configurations suivantes :

  • Autorisez le hostname de la base de données externe dans les règles de pare-feu du sous-réseau où le compute Databricks est déployé.

    Si vous choisissez de mettre sur liste blanche l'adresse IP de la base de données externe plutôt que le Hostname, assurez-vous que la base de données externe dispose d'une adresse IP stable.

  • Private Link (uniquement lorsque la base de données externe est sur le même cloud que le compute Databricks)

    Configurer une connexion Private Link entre le réseau où la base de données est déployée et le réseau où le compute Databricks est déployé.

Le compute Databricks dispose d'un serveur DNS personnalisé​

Si le système de base de données externe est accessible depuis Internet et que le compute Databricks dispose d'un serveur DNS personnalisé (ce qui n'est possible que si vous êtes sur un réseau géré par le client), ajoutez le hostname du système de base de données à votre serveur DNS personnalisé afin qu'il puisse être résolu.

Considérations de mise en réseau AWS Glue​

Si vous utilisez le compute serverless avec la fédération Glue, aucune configuration n'est requise. Si vous utilisez le compute classique avec la fédération Glue, Databricks recommande d'utiliser le réseau privé avec un catalogue fédéré pour une sécurité et des performances améliorées.

Lorsque vous déployez Databricks avec un catalogue fédéré, la mise en réseau entre le plan de données Databricks et l'AWS Glue Data Catalog dans votre AWS Virtual Private Cloud (VPC) est essentiel. Cela implique généralement l'établissement d'une connectivité privée entre le Virtual Private Cloud (VPC) du Workspace Databricks et le VPC AWS à l'aide d'AWS Private Link ou d'un Endpoint VPC d'interface.

Un Endpoint d'interface Virtual Private Cloud (VPC) dans le Virtual Private Cloud (VPC) AWS agit comme un point d'entrée pour le trafic vers le data catalog AWS Glue. Il est associé à un groupe de sécurité qui contrôle l'accès au catalogue. Le workspace Databricks est ensuite configuré pour utiliser cet endpoint. Les groupes de sécurité et les listes de contrôle d'accès réseau doivent autoriser le trafic sur les ports requis (généralement 443). La résolution DNS pour le data catalog AWS Glue utilisant l'Endpoint pourrait nécessiter des zones DNS privées ou un redirecteur DNS. Assurer une haute disponibilité et le monitoring du trafic réseau est crucial pour une configuration résiliente.

Fédération vers AWS Glue Catalog à l'aide de NAT​

Le trafic vers le data catalog AWS Glue peut traverser l'Internet public, mais la connectivité privée est recommandée à des fins de sécurité. Si vous utilisez le compute serverless, la mise en réseau vers le data catalog Glue est automatiquement acheminée vers l'endpoint public Glue glue.us-west-2.amazonaws.com. Si l'identifiant de service dispose des autorisations IAM correctes, cela fonctionne sans aucune configuration requise.

Parce que NAT entraîne des coûts supplémentaires et expose le trafic à l'internet public, il s'agit d'un fallback et non d'une bonne pratique. Si le compute Databricks et l'Endpoint du service AWS Glue Data Catalog se trouvent tous deux sur AWS dans la même région, le trafic reste sur le backbone AWS plutôt que de transiter par l'internet public. Cependant, il se résout toujours en une adresse IP publique au lieu d'une adresse IP privée.

Considérations relatives à la mise en réseau Snowflake​

  • Si le compute Databricks ne peut pas atteindre le répondeur OCSP Snowflake, les tentatives de connexion peuvent échouer pendant la validation du certificat. Préférez autoriser le trafic sortant vers le répondeur OCSP Snowflake. Si votre configuration de connectivité à sortie restreinte ou privée ne peut pas autoriser ce trafic, définissez l'option de connexion Snowflake disableOCSPChecks sur true. Consultez les options de connexion avancées.

  • Snowflake prend en charge la sortie Private Link en tant que fonctionnalité d'aperçu. Sur AWS, Snowflake publie également des adresses IP de sortie que vous pouvez mettre sur liste blanche.

Sur cette page