Herstellen einer Verbindung mit lokalen Ressourcen mithilfe eines SSH-Reversetunnels

Verbinden Sie Ihre lokalen Ressourcen mit Azure Databricks, ohne eingehenden Firewallzugriff zu öffnen. Ein lokaler Tunnelhost öffnet eine ausgehende SSH-Verbindung mit virtuellen Proxycomputern (VMs) in Azure, sodass Azure Databricks klassische und serverlose Berechnung Ihre lokalen Ressourcen erreichen kann.

So funktioniert es

Mit einem SSH-Reversetunnel kann ein lokaler Tunnelhost ausgehende SSH-Verbindungen mit Cloudproxy-VMs in Azure öffnen. Azure Databricks stellt eine Verbindung mit den Proxy-VMs über einen Lastenausgleich her und der Datenverkehr fließt durch den Tunnel zur lokalen Ressource zurück. Das lokale Netzwerk erfordert nur ausgehendes SSH (Port 22) zu Azure, sodass keine eingehenden Ports erforderlich sind.

In einem umgekehrten Tunnel initiiert der lokale Host die ausgehende Verbindung (lokal zur Cloud), um die Notwendigkeit zur Lockerung von Firewalleinschränkungen zu vermeiden, und der Rückdatenverkehr fließt über den etablierten Pfad zurück (Cloud zu lokal).

Klassische Rechenressourcen erreichen die Proxy-VMs über Peering. Serverless Compute erreicht sie über eine private Endpunktverbindung mithilfe des privaten Konnektivitätsdiensts Ihres Cloudanbieters.

Erforderliche und optionale Komponenten

Erforderlich (Mindestarbeitseinrichtung):

• Ein lokaler Tunnelhost mit autossh, um die ausgehende SSH-Verbindung herzustellen.
• Eine Proxy-VM in der Cloud, die socat ausführt, um den Tunnel anzunehmen und den Ressourcenport auf ihrer Netzwerkschnittstelle freizugeben.
• Ein Netzwerkpfad von Azure Databricks zur Proxy-VM:
  • Classic compute: Peering zwischen dem Azure Databricks VNet und dem Proxy-Hub-VNet.
  • Serverlose Berechnung: eine private Endpunktverbindung mit dem privaten Konnektivitätsdienst Ihres Cloudanbieters und einer Netzwerkkonnektivitätskonfiguration (Network Connectivity Configuration, NCC) mit einer privaten Endpunktregel.
  • Beide Berechnungstypen: Konfigurieren Sie beide Pfade.

Eine einzelne Proxy-VM ohne Lastenausgleich reicht für Entwicklung und Tests aus.

Optional (fügt hohe Verfügbarkeit und Produktionsfestigkeit hinzu):

• Zusätzliche Proxy-VMs für Redundanz.
• Ein Load Balancer, der vor den Proxy-VMs positioniert ist. Stellt einen stabilen Endpunkt und ein automatisches Failover bereit, wenn ein Tunnel fehlschlägt.
• Ein HTTP-Integritätsprüfungsdienst auf jeder Proxy-VM. Auf diese Weise kann der Load-Balancer Fehler auf Tunnelebene erkennen, nicht nur die Verfügbarkeit von VM- oder Port.

Azure Databricks empfiehlt diese Konfiguration, passt sie aber an Ihre Umgebung und Sicherheitsanforderungen an.

Tunnel-Proxy-Hub

Der Proxyhub besteht aus den folgenden Komponenten.

• Proxy-VMs (mindestens zwei für hohe Verfügbarkeit). Jede Proxy-VM führt drei Dienste aus:
  • sshd: Der SSH-Daemon akzeptiert eingehende Reversetunnel vom vor Ort befindlichen Tunnelhost und platziert den Tunnellistener auf localhost (z. B. localhost:13306 für MySQL).
  • socat: Überbrückt die Netzwerkschnittstelle des virtuellen Computers mit dem Tunnellistener (z. B. NIC:3306 → localhost:13306), sodass der Datenverkehr von Azure Databricks den Tunnelendpunkt erreichen kann.
  • HTTP-Integritätsprüfungsdienst: Gibt HTTP 200 zurück, wenn der Tunnel aktiv ist und HTTP 503 nicht. Ein einfacher TCP-Prüfpunkt erkennt nur, ob socat lauscht; Ein HTTP-Prüfpunkt auf Anwendungsebene erkennt auch dann einen inaktiven Tunnel, wenn socat noch ausgeführt wird.
• Lastenausgleich:
  • Frontend: Private IP im Proxy-Subnetz.
  • Back-End-Pool: Alle Proxy-VMs.
  • Lastenausgleichsregel: TCP für den Ressourcenport (z. B. Port 3306 für MySQL).
  • Integritätstest: HTTP GET für den Integritätsprüfungsendpunkt auf jeder Proxy-VM. Ein empfohlener Ausgangspunkt ist ein 5-Sekunden-Intervall mit zwei aufeinander folgenden Fehlern, um einen virtuellen Computer als fehlerhaft zu kennzeichnen – optimieren Sie Ihre Wiederherstellungstoleranz.
• Privater Konnektivitätsdienst (erforderlich für serverlose Berechnung): An das Front-End des Lastenausgleichs mit einem dedizierten NAT-Subnetz angefügt. Azure verwendet einen Private Link Service (PLS).
• Lokaler Tunnelhost: Führt einen autossh Prozess pro Proxy-VM aus. Eine einzelne autossh Verbindung unterstützt mehrere -R Portweiterleitungen (eine SSH-Verbindung, mehrere Tunnel) für Setups mit mehreren Ressourcen. Verwenden Sie systemd-Dienste mit Restart=always. Interaktive Tunnel enden bei Abmeldung und eignen sich nicht für die Produktion.

Konfigurieren von Azure Databricks

Erstellen Sie eine Verbindung mit Ihrer lokalen Ressource mithilfe der Frontend-IP des Load Balancers. Wählen Sie die Registerkarte für Ihren Computertyp aus.

Klassisches Rechnen

Vergewissern Sie sich vor dem Herstellen der Verbindung, dass Peering zwischen dem Proxyhub-VNet und Ihrem Azure Databricks Arbeitsbereich-VNet aktiv ist. Verwenden Sie dann die private IP des Lastenausgleichs-Frontends in Ihrer Verbindungskonfiguration:

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>');

Abfragen schlagen im freigegebenen Zugriffsmodus fehl, da die Klassenladeprogrammisolation verhindert, dass Executoren auf Maven-basierte JDBC-Treiber zugreifen. Verwenden Sie den Einzelbenutzerzugriffsmodus, um zu überprüfen, ob der Treiber im gesamten Cluster verfügbar ist. Fügen Sie vor dem Erstellen der Verbindung den JDBC-Treiber zur Zulassungsliste des Unity-Katalogs hinzu.

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

Serverloses Rechnen

1. Wechseln Sie als Kontoadministrator zur Kontokonsole.

2. Klicken Sie in der Randleiste auf "Sicherheit".

3. Klicken Sie auf Netzwerkkonnektivitätskonfigurationen , und erstellen Sie einen NCC für Ihre Arbeitsbereichsregion.

4. Fügen Sie in der NCC eine private Endpunktregel hinzu, und geben Sie die Dienstressourcen-ID ein.

5. Fügen Sie den NCC an Ihren Arbeitsbereich an, und warten Sie 10 bis 15 Minuten auf die Verteilung.

6. Genehmigen der privaten Endpunktverbindung für den privaten Verbindungsdienst:

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

7. Erstellen Sie die Verbindung mit der privaten Endpunktdomäne:

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

Die Schaltfläche Test Connection in der benutzeroberfläche Azure Databricks funktioniert nicht für private Endpunktverbindungen. Überspringen Sie sie, und erstellen Sie die Verbindung direkt.

Lakeflow Connect CDC

Das Lakeflow Connect-Gateway wird auf klassischer Rechenleistung in Ihrem Arbeitsbereich-VNet ausgeführt und erreicht die Proxy-VMs über Peering. Verwenden Sie die private IP des Lastenausgleichs-Frontends als Verbindungshost, nicht als IP-Adresse einer einzelnen Proxy-VM. Siehe Hohe Verfügbarkeit und Pipelineresilienz.

Führen Sie vor dem Erstellen einer CDC-Pipeline die folgenden Schritte für Ihr Datenbankmodul aus:

1. Änderungsprotokollierung aktivieren: Konfigurieren Sie Ihre Datenbank so, dass Änderungen auf Zeilenebene protokolliert werden (z. B. binäre Protokollierung in MySQL, logische Replikation in PostgreSQL oder ergänzende Protokollierung in Oracle).

2. Erteilen von Replikationsberechtigungen: Gewähren Sie dem Pipeline-Benutzer die benötigten Berechtigungen zum Lesen von Änderungsprotokollen und zum Ausführen von Snapshot-Operationen. Weitere Informationen finden Sie in der Connectordokumentation für Ihre spezifische Datenbank.

3. Festlegen der Protokollaufbewahrung: Konfigurieren der Protokollaufbewahrung auf mindestens sieben Tage. Wenn das CDC-Gateway offline ist, wenn Protokolle ablaufen, muss die Pipeline eine vollständige erneute Momentaufnahme aller Quelltabellen ausführen.

Informationen zur motorspezifischen Konfiguration finden Sie in der Dokumentation zum Lakeflow Connect-Connector.

Hohe Verfügbarkeit und Pipelineresilienz

Bei zwei oder mehr Proxy-VMs im Back-End-Pool unterbricht ein Tunnelfehler in einer einzelnen Instanz den Dienst nicht. Wenn ein Tunnel fehlschlägt, gibt der Gesundheitsprüfdienst HTTP 503 zurück. Der Lastenausgleich beendet dann das Routing neuer Verbindungen mit dieser VM innerhalb von ca. 10 Sekunden.

Legen Sie für Lakeflow Connect-CDC-Pipelines die Aufbewahrung von binären Protokollen auf mindestens 7 Tage fest. Wenn das CDC-Gateway offline ist, wenn die binären Logs ablaufen, muss die Pipeline eine vollständige wiederholte Aufnahme aller Quelltabellen ausführen.

Bekannte Einschränkungen

Diese Lösung hat die folgenden Einschränkungen.

• Jede lokale Ressource erfordert eine unterschiedliche Portzuordnung auf jeder Proxy-VM. Verwenden Sie für mehrere Ressourcen desselben Typs auf demselben Standardport unterschiedliche Ports auf der Netzwerkschnittstelle der Proxy-VM (z. B. 3306, 3307 oder 3308), oder verwenden Sie separate Proxy-VMs.
• Sie müssen die Proxy-VMs und den lokalen Tunnelhost bereitstellen und verwalten.
• Ein Lastenausgleich blockiert standardmäßige ausgehende Internetverbindung für VMs im Back-End-Pool. Installieren Sie die erforderlichen Pakete, bevor Sie dem Pool virtuelle Computer hinzufügen.
• Die Schaltfläche Test Connection in der benutzeroberfläche Azure Databricks funktioniert nicht für private Endpunktverbindungen.
• Im Modus des gemeinsamen Zugriffs sind Maven JDBC-Bibliotheken nur auf dem Treiberknoten verfügbar. Verwenden Sie den Einzelbenutzerzugriffsmodus für JDBC-Arbeitslasten.

Nächste Schritte

• Konfigurieren Sie die private Konnektivität mit Azure-Ressourcen