Connettersi alle risorse locali usando un tunnel inverso SSH

Connettere le risorse locali a Azure Databricks senza aprire l'accesso al firewall in ingresso. Un host di tunnel on-premises apre una connessione SSH in uscita alle macchine virtuali proxy in Azure, consentendo al calcolo classico e serverless di Azure Databricks di raggiungere le risorse on-premises.

Come funziona

Un tunnel inverso SSH consente a un host del tunnel locale di aprire connessioni SSH in uscita alle macchine virtuali proxy cloud in Azure. Azure Databricks si connette alle macchine virtuali proxy tramite un servizio di bilanciamento del carico e il traffico passa attraverso il tunnel alla risorsa locale. La rete locale richiede solo SSH in uscita (porta 22) per Azure, quindi non sono necessarie porte in ingresso.

In un tunnel inverso, l'host locale avvia la connessione verso l'esterno (da locale a cloud) per evitare di ridurre le restrizioni del firewall e il traffico di ritorno (da cloud a locale) lungo il percorso stabilito.

Il calcolo classico raggiunge le macchine virtuali proxy tramite peering. Il calcolo serverless li raggiunge tramite una connessione a endpoint privato usando il servizio di connettività privata del provider di cloud.

Componenti obbligatori e facoltativi

Obbligatorio (configurazione minima di lavoro):

• Host tunnel locale utilizzato autossh per stabilire la connessione SSH in uscita.
• Una macchina virtuale proxy nel cloud in esecuzione socat per accettare il tunnel ed esporre la porta della risorsa nella relativa interfaccia di rete.
• Percorso di rete da Azure Databricks alla macchina virtuale proxy:
  • Classic compute: peering tra la VNet di Azure Databricks e la VNet dell'hub proxy.
  • Calcolo serverless: una connessione endpoint privato usando il servizio di connettività privata del provider di servizi cloud e una configurazione di connettività di rete (NCC) con una regola dell'endpoint privato.
  • Entrambi i tipi di calcolo: configurare entrambi i percorsi.

Una singola macchina virtuale proxy senza un servizio di bilanciamento del carico è sufficiente per lo sviluppo e il test.

Facoltativo (aggiunge disponibilità elevata e affidabilità di produzione):

• Macchine virtuali proxy aggiuntive per la ridondanza.
• Un bilanciatore del carico che fronteggia le macchine virtuali proxy. Fornisce un endpoint stabile e il failover automatico in caso di errore di un tunnel.
• Un servizio di controllo dell'integrità HTTP in ogni macchina virtuale proxy. Ciò consente al servizio di bilanciamento del carico di rilevare gli errori a livello di tunnel, non solo la disponibilità di macchine virtuali o porte.

Azure Databricks consiglia questa configurazione, ma adattarla ai requisiti di sicurezza e dell'ambiente.

Hub proxy del tunnel

L'hub proxy è costituito dai componenti seguenti.

• Macchine virtuali proxy (almeno due per la disponibilità elevata). Ogni macchina virtuale proxy esegue tre servizi:
  • sshd: il daemon SSH accetta tunnel inversi in ingresso dall'host del tunnel locale interno e inserisce il servizio di ascolto del tunnel in localhost (ad esempio, localhost:13306 per MySQL).
  • socat: collega l'interfaccia di rete della macchina virtuale al listener del tunnel (ad esempio, NIC:3306 → localhost:13306), in modo che il traffico proveniente da Azure Databricks possa raggiungere l'endpoint del tunnel.
  • Servizio controllo integrità HTTP: restituisce HTTP 200 quando il tunnel è attivo e HTTP 503 quando non lo è. Un probe TCP normale rileva solo se socat è in ascolto; un probe HTTP a livello di applicazione rileva un tunnel inattivo anche quando socat è ancora in esecuzione.
• Bilanciamento del carico:
  • Front-end: indirizzo IP privato nella sottorete proxy.
  • Pool backend: tutte le VM proxy.
  • Regola di bilanciamento del carico: TCP sulla porta della risorsa (ad esempio, porta 3306 per MySQL).
  • Probe di integrità: HTTP GET verso l'endpoint di controllo dell'integrità in ogni macchina virtuale proxy. Un punto di partenza consigliato è un intervallo di 5 secondi con 2 errori consecutivi per contrassegnare una macchina virtuale non sana, regolando in base alla tolleranza di ripristino.
• Servizio di connettività privata (obbligatorio per il calcolo serverless): collegato al front-end del servizio di bilanciamento del carico con una subnet NAT dedicata. Azure usa un servizio collegamento privato (PLS).
• Host del tunnel locale: esegue un autossh processo per ogni macchina virtuale proxy. Una singola autossh connessione supporta più -R port forward (una connessione SSH, più tunnel) per le configurazioni a più risorse. Usa i servizi systemd con Restart=always. I tunnel interattivi terminano al logout e non sono adatti per l'ambiente di produzione.

Configurare Azure Databricks

Crea una connessione alla risorsa locale usando l'indirizzo IP front-end del servizio di bilanciamento del carico. Selezionare la scheda per il tipo di calcolo.

Calcolo classico

Prima di connettersi, verificare che il peering tra la rete virtuale dell'hub proxy e la rete virtuale dell'area di lavoro Azure Databricks sia attiva. Usare quindi l'IP privato del front-end del bilanciamento del carico nella configurazione della connessione.

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

Le interrogazioni non riescono in modalità di accesso condiviso perché l'isolamento del classloader impedisce agli esecutori di accedere ai driver JDBC basati su Maven. Usare la modalità di accesso utente singolo per verificare che il driver sia disponibile nell'intero cluster. Prima di creare la connessione, aggiungere il driver JDBC all'elenco elementi consentiti del catalogo Unity:

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

Calcolo serverless

1. In qualità di amministratore dell'account, accedere alla console dell'account.

2. Nella barra laterale fare clic su Sicurezza.

3. Fare clic su Configurazioni di connettività di rete e creare un NCC per l'area dell'area di lavoro.

4. In NCC aggiungere una regola dell'endpoint privato e immettere l'ID risorsa del servizio.

5. Collegare il NCC all'area di lavoro e attendere 10-15 minuti per la propagazione.

6. Approvare la connessione all'endpoint privato nel servizio di connettività privata:

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

7. Creare la connessione usando il dominio dell'endpoint privato:

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

Il pulsante Test Connection nell'interfaccia utente di Azure Databricks non funziona per le connessioni dell'endpoint privato. Ignorarlo e creare direttamente la connessione.

Lakeflow Connect CDC

Il gateway Lakeflow Connect viene eseguito sui servizi di calcolo classici nella VNet dell'area di lavoro e raggiunge le VM proxy tramite peering. Usare l'indirizzo IP privato front-end del servizio di bilanciamento del carico come host di connessione, non l'INDIRIZZO IP di una singola macchina virtuale proxy. Vedere Disponibilità elevata e resilienza della pipeline.

Prima di creare una pipeline CDC, segui i passaggi seguenti per il motore di database:

1. Abilitare la registrazione delle modifiche: configurare il database per registrare le modifiche a livello di riga, ad esempio la registrazione binaria in MySQL, la replica logica in PostgreSQL o la registrazione supplementare in Oracle.

2. Concedere le autorizzazioni di replica: fornire all'utente della pipeline le autorizzazioni necessarie per leggere i log delle modifiche ed eseguire snapshot. Fare riferimento alla documentazione del connettore per il database specifico.

3. Impostare la conservazione dei log: configurare la conservazione dei log su almeno sette giorni. Se il gateway CDC è offline quando i log scadono, la pipeline deve eseguire un nuovo snapshot completo di tutte le tabelle di origine.

Per la configurazione specifica del motore, vedere la documentazione del connettore Lakeflow Connect.

Disponibilità elevata e resilienza della pipeline

Con due o più macchine virtuali proxy nel pool back-end, un errore del tunnel in una singola istanza non interrompe il servizio. Se un tunnel non riesce, il servizio controllo integrità restituisce HTTP 503. Il servizio di bilanciamento del carico arresta quindi il routing di nuove connessioni alla macchina virtuale entro circa 10 secondi.

Per le pipeline di Lakeflow Connect CDC, impostare la conservazione dei log binari su almeno 7 giorni. Se il gateway CDC è offline quando i log binari scadono, la pipeline deve rieseguire uno snapshot completo di tutte le tabelle di origine.

Limitazioni note

Questa soluzione presenta le limitazioni seguenti.

• Ogni risorsa locale richiede un mapping di porte distinto in ogni macchina virtuale proxy. Per più risorse dello stesso tipo sulla stessa porta predefinita, usare porte diverse nell'interfaccia di rete della macchina virtuale proxy (ad esempio, 3306, 3307 o 3308) o usare macchine virtuali proxy separate.
• È necessario effettuare il provisioning e gestire le macchine virtuali proxy e l'host del tunnel locale.
• Un servizio di bilanciamento del carico blocca la connettività Internet in uscita predefinita per le macchine virtuali nel pool back-end. Installare i pacchetti necessari prima di aggiungere macchine virtuali al pool.
• Il pulsante Test Connection nell'interfaccia utente di Azure Databricks non funziona per le connessioni dell'endpoint privato.
• In modalità di accesso condiviso, le librerie JDBC di Maven sono disponibili solo nel nodo driver. Usare la modalità di accesso utente singolo per i carichi di lavoro JDBC.

Passaggi successivi

• Configurare la connettività privata alle risorse di Azure