Se connecter à des ressources locales à l’aide d’un tunnel inverse SSH

Connectez vos ressources locales à Azure Databricks sans ouvrir l’accès au pare-feu entrant. Un hôte de tunnel local ouvre une connexion SSH sortante vers des machines virtuelles proxy dans Azure, ce qui permet à Azure Databricks calcul classique et serverless d’atteindre vos ressources locales.

Fonctionnement

Un tunnel inverse SSH permet à un hôte de tunnel local d’ouvrir des connexions SSH sortantes vers des machines virtuelles proxy cloud dans Azure. Azure Databricks se connecte aux machines virtuelles proxy via un équilibreur de charge, et le trafic revient dans le tunnel vers la ressource locale. Le réseau local ne nécessite que le protocole SSH sortant (port 22) pour Azure, de sorte qu’aucun port entrant n’est requis.

Dans un tunnel inverse, l’hôte local lance la connexion sortante (localement vers le cloud) afin d’éviter de assouplir les restrictions de pare-feu et de retourner les flux de trafic (cloud vers local) sur le chemin établi.

Le calcul classique atteint les machines virtuelles proxy via le peering. Le calcul serverless est acheminé vers eux via une connexion de point de terminaison privé grâce au service de connectivité privée de votre fournisseur de cloud.

Note

Il s’agit d’une solution auto-gérée. Vous approvisionnez et gérez les machines virtuelles proxy et l’hôte de tunnel local.

Composants obligatoires et facultatifs

Note

Cette configuration nécessite un circuit réseau dédié entre votre environnement cloud et votre réseau local. Ce circuit permet à l’hôte de tunnel local de lancer ssh sortant vers les adresses IP privées des machines virtuelles proxy. Les options courantes incluent ExpressRoute ou un tunnel VPN.

Obligatoire (configuration minimale de travail) :

  • Hôte de tunnel sur site fonctionnant autossh pour établir la connexion SSH sortante.
  • Une machine virtuelle proxy dans le cloud s’exécutant socat pour accepter le tunnel et exposer le port de ressource sur son interface réseau.
  • Chemin d’accès réseau de Azure Databricks à la machine virtuelle proxy :
    • Classic compute : peering entre le réseau virtuel Azure Databricks et le réseau virtuel du hub proxy.
    • Calcul serverless : connexion de point de terminaison privé à l’aide du service de connectivité privée de votre fournisseur de cloud et d’une configuration de connectivité réseau (CCN) avec une règle de point de terminaison privé.
    • Les deux types de calcul : configurez les deux chemins.

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

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

  • Machines virtuelles proxy supplémentaires pour la redondance.
  • Équilibreur de charge devant les machines virtuelles proxy. Fournit un point de terminaison stable et un basculement automatique lorsqu’un tunnel échoue.
  • Un service de contrôle d’intégrité HTTP sur chaque machine virtuelle proxy. Cela permet à l’équilibreur de charge de détecter les défaillances au niveau du tunnel, et non seulement la disponibilité des machines virtuelles ou des ports.

Azure Databricks recommande cette configuration, mais l’adapte à vos exigences en matière d’environnement et de sécurité.

Hub de proxy de tunnel

Le hub proxy se compose des composants suivants.

  • Machines virtuelles proxy (au moins deux pour la haute disponibilité). Chaque machine virtuelle proxy exécute trois services :
    • sshd : le démon SSH accepte les tunnels inverses entrants à partir de l’hôte de tunnel local et place l’écouteur de tunnel sur localhost (par exemple, localhost:13306 pour MySQL).
    • socat : relie l'interface réseau de la machine virtuelle à l'écouteur de tunnel (par exemple, NIC:3306 → localhost:13306), afin que le trafic de Azure Databricks puisse atteindre le point de terminaison du tunnel.
    • Service de contrôle d’intégrité HTTP : retourne HTTP 200 lorsque le tunnel est actif et HTTP 503 lorsqu’il n’est pas. Une sonde TCP simple détecte uniquement si socat écoute ; Une sonde HTTP au niveau de l’application détecte un tunnel mort même quand socat est toujours en cours d’exécution.
  • Équilibreur de charge :
    • Frontend : adresse IP privée dans le sous-réseau proxy.
    • Pool principal : toutes les machines virtuelles 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 au point de terminaison de contrôle d’intégrité sur chaque machine virtuelle proxy. Un point de départ recommandé est un intervalle de 5 secondes avec 2 échecs consécutifs pour marquer une machine virtuelle non saine , paramétrez votre tolérance de récupération.
  • Service de connectivité privée (requis pour le calcul serverless) : attaché au serveur frontal de l’équilibreur de charge avec un sous-réseau NAT dédié. Azure utilise un service Private Link (PLS).
  • Hôte de tunnel local : exécute un autossh processus par machine virtuelle proxy. Une seule autossh connexion prend en charge plusieurs -R transferts de port (une connexion SSH, plusieurs tunnels) pour les configurations multi-ressources. Utilisez les services systemd avec Restart=always. Les tunnels interactifs se terminent à la déconnexion et ne conviennent pas à la production.

Configurer Azure Databricks

Créez une connexion à votre ressource locale à l’aide de l’adresse IP frontale de l’équilibreur de charge. Sélectionnez l’onglet de votre type de calcul.

Note

Les exemples suivants utilisent MySQL. Pour d’autres bases de données, remplacez le type de connexion, le port et la coordonnée Maven du pilote JDBC.

Calcul classique

Avant de vous connecter, vérifiez que le peering entre le réseau virtuel du hub proxy et votre Azure Databricks réseau virtuel d’espace de travail est actif. Utilisez ensuite l’adresse IP privée frontale de l’équilibreur de charge dans votre configuration de connexion :

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 requêtes échouent en mode d’accès partagé, car l’isolation du chargeur de classes empêche les exécuteurs d’accéder aux pilotes JDBC basés sur Maven. Utilisez le mode d’accès mono-utilisateur pour vérifier que le pilote est disponible dans l’ensemble du cluster. Avant de créer la connexion, ajoutez le pilote JDBC à la liste d'autorisation du catalogue Unity :

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

Informatique sans serveur

  1. En tant qu’administrateur de compte, accédez à la console de compte.

  2. Dans la barre latérale, cliquez sur Sécurité.

  3. Cliquez sur Configurations de connectivité réseau et créez une CCN pour votre région d’espace de travail.

  4. Dans le NCC, ajoutez une règle de point de terminaison privé, puis entrez l’ID de ressource du service.

  5. Joignez la CCN à votre espace de travail et attendez 10 à 15 minutes pour la propagation.

  6. Approuvez la connexion de point de terminaison privé sur le service de connectivité privée :

    az network private-link-service connection update \
  --service-name <pls-name> \
  --resource-group <rg> \
  --name "<connection-name>" \
  --connection-status Approved

  7. Créez la connexion à l’aide du domaine de point de terminaison privé :

    CREATE CONNECTION mysql_onprem_serverless TYPE mysql
OPTIONS (
  host '<pe-domain>',
  port '3306',
  user '<db-user>',
  password '<db-password>'
);

Le bouton Test Connection dans l’interface utilisateur Azure Databricks ne fonctionne pas pour les connexions de point de terminaison privé. Ignorez-le et créez la connexion directement.

Lakeflow Connect CDC

La passerelle Lakeflow Connect fonctionne sur une infrastructure de calcul classique dans votre VNet d'espace de travail et accède aux machines virtuelles proxy via le peering. Utilisez l’adresse IP privée frontale de l’équilibreur de charge comme hôte de connexion, et non l’adresse IP d’une machine virtuelle proxy individuelle. Consultez la haute disponibilité et la résilience des pipelines.

Avant de créer un pipeline CDC, effectuez les étapes suivantes pour votre moteur de base de données :

  1. Activer la journalisation des modifications : configurez votre base de données pour consigner les modifications au niveau des lignes (par exemple, la journalisation binaire dans MySQL, la réplication logique dans PostgreSQL ou la journalisation supplémentaire dans Oracle).

  2. Accorder des autorisations de réplication : fournissez à l’utilisateur du pipeline les autorisations nécessaires pour lire les journaux de modification et effectuer des instantanés. Reportez-vous à la documentation du connecteur pour votre base de données spécifique.

  3. Définir la rétention des journaux : configurez la rétention des journaux sur au moins sept jours. Si la passerelle CDC est hors connexion lorsque les journaux expirent, le pipeline doit effectuer une nouvelle capture instantanée complète de toutes les tables sources.

Pour obtenir une configuration spécifique au moteur, consultez la documentation du connecteur Lakeflow Connect.

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. En cas d’échec d’un tunnel, le service de contrôle d’intégrité retourne HTTP 503. L’équilibreur de charge arrête ensuite le routage de nouvelles connexions vers cette machine virtuelle dans un délai d’environ 10 secondes.

Note

Utilisez l’adresse IP frontale de l’équilibreur de charge dans votre chaîne de connexion, et non l’adresse IP d’une machine virtuelle proxy individuelle. Si un tunnel tombe, l’équilibreur de charge redirige automatiquement le trafic sans intervention manuelle ou temps d’arrêt du pipeline.

Scénario d’échec Sans contrôle d’intégrité de l’application Vérification de l'état de santé de l'application
La machine virtuelle proxy cesse de répondre L'équilibreur de charge détecte le basculement. → L’équilibreur de charge détecte le basculement →
Arrêt du transférateur de port L’équilibreur de charge détecte le basculement → L’équilibreur de charge détecte le basculement →
Échec du tunnel SSH, redirecteur de port en cours d’exécution L’équilibreur de charge ne peut pas détecter → échecs intermittents L’équilibreur de charge détecte (HTTP 503) → basculement

Pour les pipelines CDC Lakeflow Connect, définissez la rétention des journaux binaires sur au moins 7 jours. Si la passerelle CDC est hors connexion lorsque les journaux binaires expirent, le pipeline doit effectuer une nouvelle capture instantanée complète de toutes les tables sources.

Limitations connues

Cette solution présente les limitations suivantes.

  • Chaque ressource locale nécessite un mappage de port distinct sur chaque machine virtuelle proxy. Pour plusieurs ressources du même type sur le même port par défaut, utilisez différents ports sur l’interface réseau de la machine virtuelle proxy (par exemple, 3306, 3307 ou 3308) ou utilisez des machines virtuelles proxy distinctes.
  • Vous devez provisionner et gérer les machines virtuelles proxy et l’hôte de tunnel local.
  • Un équilibreur de charge bloque la connectivité Internet sortante par défaut pour les machines virtuelles du pool principal. Installez les packages requis avant d’ajouter des machines virtuelles au pool.
  • Le bouton Test Connection dans l’interface utilisateur Azure Databricks ne fonctionne pas pour les connexions de point de terminaison privé.
  • En mode d’accès partagé, les bibliothèques JDBC Maven sont disponibles uniquement sur le nœud du pilote. Utilisez le mode d’accès mono-utilisateur pour les charges de travail JDBC.

Étapes suivantes

  • Last updated on