Aller au contenu principal
Dernière mise à jour le

Se connecter aux ressources on-premise à l’aide d’un tunnel inversé SSH

Connectez vos Ressources on-premise à Databricks sans ouvrir l'accès de pare-feu entrant. Un hôte de tunnel on-premise ouvre une connexion SSH sortante vers des machines virtuelles (VM) proxy dans AWS, permettant au compute classique et serverless de Databricks d'atteindre vos Ressources on-premise.

Comment cela fonctionne​

Un tunnel inverse SSH permet à un hôte de tunnel on-premise d’ouvrir des connexions SSH sortantes vers des machines virtuelles proxy cloud dans AWS. Databricks se connecte aux machines virtuelles proxy via un équilibreur de charge, et le trafic est acheminé en retour via le tunnel vers la ressource on-premise. Le réseau on-premise ne nécessite qu’un SSH sortant (port 22) vers AWS, donc aucun port entrant n’est requis.

Dans un tunnel inversé, l'hôte on-premise initie la connexion sortante (de l'on-premise vers le cloud) pour éviter d'assouplir les restrictions du pare-feu, et le trafic de retour est redirigé (du cloud vers l'on-premise) sur le chemin établi.

Le compute classique atteint les machines virtuelles proxy par appairage. Le compute serverless les atteint via une connexion d'Endpoint privé à l'aide du service de connectivité privée de votre fournisseur de cloud.

remarque

Il s'agit d'une solution autogérée. Vous provisionnez et maintenez les machines virtuelles proxy et l'hôte de tunnel on-premise.

Composants requis et facultatifs​

remarque

Cette configuration nécessite un circuit réseau dédié entre votre environnement cloud et votre réseau on-premise. Ce circuit permet à l'hôte de tunnel on-premise d'initier des connexions SSH sortantes vers les adresses IP privées des VM proxy. Les options courantes incluent AWS Direct Connect ou un tunnel VPN.

Obligatoire (configuration minimale fonctionnelle) :

  • Un hôte de tunnel on-premise exécutant autossh pour établir la connexion SSH sortante.
  • Une VM proxy dans le cloud exécutant socat pour accepter le tunnel et exposer le port de ressource sur son interface réseau.
  • Un chemin réseau de Databricks vers la VM proxy :
    • Compute classique : appairage entre le VPC Databricks et le VPC du hub de proxy.
    • Serverless compute : une connexion d'Endpoint privé utilisant le service de connectivité privée de votre fournisseur de cloud et une Configuration de connectivité réseau (CCN) avec une règle d'Endpoint privé.
    • Les deux types de compute : configurez les deux chemins.

Une seule machine virtuelle proxy sans équilibreur de charge est suffisante pour le développement et les tests.

Facultatif (ajoute une haute disponibilité et une robustesse de production) :

  • VMs proxy supplémentaires pour la redondance.
  • Un équilibreur de charge situé devant les VMs proxy. Fournit un endpoint stable et un basculement automatique lorsqu'un tunnel échoue.
  • Un service de contrôle de santé HTTP sur chaque machine virtuelle proxy. Ceci permet à l'équilibreur de charge de détecter les défaillances au niveau du tunnel, pas seulement la disponibilité des machines virtuelles ou des ports.

Databricks recommande cette configuration, mais adaptez-la à votre environnement et à vos exigences de sécurité.

Hub de proxy de tunnel​

Le hub proxy se compose des composants suivants.

  • **Machines virtuelles de proxy** (au moins deux pour une haute disponibilité). Chaque VM proxy exécute trois services :

    • **sshd** : Le démon SSH accepte les tunnels inverses entrants de l'hôte de tunnel on-premise et place l'écouteur de tunnel sur localhost (par exemple, localhost:13306 pour MySQL).
    • socat : établit une passerelle entre l'interface réseau de la machine virtuelle et l'écouteur du tunnel (par exemple, NIC:3306 → localhost:13306), afin que le trafic de Databricks puisse atteindre l'endpoint du tunnel.
    • **Service de vérification de l'état HTTP** : Renvoie HTTP 200 lorsque le tunnel est actif et HTTP 503 lorsqu'il ne l'est pas. Une sonde TCP simple détecte uniquement si socat est à l'écoute ; une sonde HTTP de niveau application détecte un tunnel mort même lorsque socat est toujours en cours d'exécution.

  • **Équilibreur de charge** :

    • Front-end : IP privée dans le sous-réseau de proxy.
    • Pool de backend : toutes les VM proxy.
    • Règle d'équilibrage de charge : TCP sur le port de ressource (par exemple, port 3306 pour MySQL).
    • Sonde d'intégrité : HTTP GET par rapport à l'Endpoint de vérification d'intégrité sur chaque VM proxy. Un point de départ recommandé est un intervalle de 5 secondes avec 2 défaillances consécutives pour marquer une VM comme étant défectueuse — ajustez-le en fonction de votre tolérance de récupération.

  • **Service de connectivité privée** (requis pour le compute serverless) : attaché au frontend de l'équilibreur de charge avec un sous-réseau NAT dédié. AWS utilise un service de Endpoint Virtual Private Cloud (VPC).

  • **Hôte de tunnel on-premise** : exécute un autossh processus par VM proxy. Une seule connexion autossh prend en charge plusieurs redirections de port -R (une connexion SSH, plusieurs tunnels) pour les configurations multi-ressources. Utilisez les services systemd avec Restart=always. Les tunnels interactifs prennent fin à la déconnexion et ne conviennent pas à la production.

Configurer Databricks​

Créez une connexion à votre ressource on-premise à l’aide de l’adresse IP front-end de l’équilibreur de charge. Sélectionnez le tab pour votre type de compute.

remarque

Les exemples suivants utilisent MySQL. Pour les autres bases de données, remplacez le type de connexion, le port et les coordonnées Maven du Driver JDBC.

Avant de vous connecter, confirmez que le peering entre le Virtual Private Cloud (VPC) du hub proxy et le VPC de votre Workspace Databricks est actif. Utilisez ensuite l'IP privée front-end de l'équilibreur de charge dans votre configuration de connexion :

SQL
CREATE CONNECTION mysql_onprem TYPE mysql
OPTIONS (
  host '<lb-frontend-ip>',
  port '3306',
  user '<db-user>',
  password '<db-password>'
);

CREATE FOREIGN CATALOG onprem_catalog
USING CONNECTION mysql_onprem
OPTIONS (database '<db-name>');

Les queries échouent en mode d'accès partagé car l'isolation des chargeurs de classes empêche les exécuteurs d'accéder aux drivers JDBC basés sur Maven. Utilisez le mode d'accès mono-utilisateur pour vérifier que le Driver est disponible sur l'ensemble du cluster. Avant de créer la connexion, ajoutez le Driver JDBC à la liste d'autorisation de Unity Catalog :

SQL
ALTER METASTORE ADD ALLOWLIST maven ('mysql:mysql-connector-java:8.0.33');

Haute disponibilité et résilience des pipelines​

Avec deux machines virtuelles proxy ou plus dans le pool principal, une défaillance de tunnel sur une seule instance n'interrompt pas le service. Si un tunnel échoue, le service de vérification de l'état renvoie HTTP 503. L'équilibreur de charge cesse alors d'acheminer les nouvelles connexions vers cette VM dans un délai d'environ 10 secondes.

remarque

Utilisez l'IP frontend de l'équilibreur de charge dans votre chaîne de connexion, et non l'IP d'une machine virtuelle proxy individuelle. Si un tunnel tombe, l'équilibreur de charge réachemine automatiquement le trafic sans intervention manuelle ni temps d'arrêt du pipeline.

Scénario d'échec

Sans vérification de l'état de santé de l'application

Avec vérification de l'état de santé de l'application.

La VM proxy ne répond plus

L'équilibreur de charge détecte → basculement

L'équilibreur de charge détecte → basculement

Le redirecteur de port s'arrête

L'équilibreur de charge détecte → basculement

L'équilibreur de charge détecte → basculement

SSH tunnel échoue, le redirecteur de port est en cours d'exécution.

L'équilibreur de charge ne peut pas détecter, ce qui entraîne des défaillances intermittentes.

Le répartiteur de charge détecte (HTTP 503) → basculement

Scénario d'échec

Sans vérification de l'état de santé de l'application

Avec vérification de l'état de santé de l'application.

La VM proxy ne répond plus

L'équilibreur de charge détecte → basculement

L'équilibreur de charge détecte → basculement

Le redirecteur de port s'arrête

L'équilibreur de charge détecte → basculement

L'équilibreur de charge détecte → basculement

SSH tunnel échoue, le redirecteur de port est en cours d'exécution.

L'équilibreur de charge ne peut pas détecter, ce qui entraîne des défaillances intermittentes.

Le répartiteur de charge détecte (HTTP 503) → basculement

Pour les pipelines CDC de Lakeflow Connect, définissez la conservation des logs binaires sur au moins 7 jours. Si la passerelle CDC est hors ligne lorsque les logs binaires expirent, le pipeline doit effectuer une resynchronisation complète de toutes les tables source.

Limitations connues​

Cette solution présente les limitations suivantes.

  • Chaque ressource on-premise nécessite un mappage de port distinct sur chaque machine virtuelle proxy. Pour plusieurs ressources du même type sur le même port default, utilisez des ports différents sur l'interface réseau de la VM proxy (par exemple, 3306, 3307 ou 3308) ou utilisez des VM proxy distinctes.
  • Vous devez provisionner et maintenir les VMs proxy et l’hôte de tunnel on-premise.
  • Un équilibreur de charge bloque la connectivité Internet sortante par default pour les machines virtuelles du pool back-end. Installez les packages requis avant d'ajouter des machines virtuelles au pool.
  • Le bouton Tester la connexion dans l'interface utilisateur de Databricks ne fonctionne pas pour les connexions d'Endpoint privés.
  • En mode d'accès partagé, les bibliothèques Maven JDBC ne sont disponibles que sur le nœud Driver. Utilisez le mode d'accès mono-utilisateur pour les charges de travail JDBC.

Étapes suivantes​

Sur cette page