Ligue-se a recursos on-premises usando um túnel reverso SSH

Ligue os seus recursos on-premises ao Azure Databricks sem abrir o acesso ao firewall de entrada. Um host de túnel local abre uma ligação SSH de saída para máquinas virtuais proxy (VMs) no Azure, permitindo que o Azure Databricks clássico e a computação serverless acedam aos seus recursos locais.

Como funciona

Um túnel reverso SSH permite que um host de túnel local abra ligações SSH de saída para VMs proxy cloud no Azure. O Azure Databricks liga-se às VMs proxy através de um balanceador de carga, e o tráfego regressa pelo túnel para o recurso local. A rede local requer apenas SSH de saída (porta 22) para o Azure, pelo que não são necessárias portas de entrada.

Num túnel inverso, o host local inicia a ligação de saída (local para cloud) de forma a evitar relaxar as restrições do firewall, e o tráfego de retorno flui (cloud para local) pelo caminho estabelecido.

A computação clássica chega às VMs proxy através de peering. A computação serverless chega-lhes através de uma ligação privada ao endpoint usando o serviço de conectividade privada do seu fornecedor cloud.

Note

Esta é uma solução auto-gerida. Você configura e mantém as VMs proxy e o host do túnel nas suas instalações.

Componentes obrigatórios e opcionais

Note

Esta configuração requer um circuito de rede dedicado entre o seu ambiente cloud e a sua rede local. Este circuito permite que o host do túnel local inicie SSH de saída para os endereços IP privados das VMs proxy. Opções comuns incluem ExpressRoute ou um túnel VPN.

Obrigatório (configuração mínima de funcionamento):

  • Um host de túnel no local correndo autossh para estabelecer a ligação SSH de saída.
  • Uma VM proxy na nuvem a executar socat para aceitar o túnel e expor a porta de recurso na sua interface de rede.
  • Um caminho de rede do Azure Databricks para a VM proxy:
    • Classic compute: peering entre o Azure Databricks VNet e o VNet do hub proxy.
    • Computação serverless: uma ligação privada a um ponto final usando o serviço privado de conectividade do seu fornecedor de serviços em nuvem e uma Configuração de Conectividade de Rede (NCC) com uma regra de ponto final privado.
    • Ambos os tipos de computação: configurar ambos os caminhos.

Uma única VM proxy sem balanceador de carga é suficiente para desenvolvimento e testes.

Opcional (adiciona alta disponibilidade e robustez de produção):

  • VM proxy adicionais para redundância.
  • Um balanceador de carga posicionado à frente das VMs de proxy. Fornece um endpoint estável e failover automático quando um túnel falha.
  • Um serviço de verificação de saúde HTTP em cada VM proxy. Isto permite ao balanceador de carga detetar falhas ao nível do túnel, não apenas disponibilidade de VM ou portas.

O Azure Databricks recomenda esta configuração, mas adapta-a ao teu ambiente e necessidades de segurança.

Hub proxy de túnel

O hub proxy é composto pelos seguintes componentes.

  • VMs de proxy (pelo menos duas para alta disponibilidade). Cada VM proxy executa três serviços:
    • sshd: O daemon SSH aceita túneis reversos recebidos do host do túnel no local e coloca o ouvinte do túnel ( localhost por exemplo, localhost:13306 para MySQL).
    • socat: Faz a ponte entre a interface de rede da VM e o ouvinte do túnel (por exemplo, NIC:3306 → localhost:13306), para que o tráfego proveniente de Azure Databricks possa chegar ao ponto final do túnel.
    • Serviço de verificação de saúde HTTP: Devolve HTTP 200 quando o túnel está ativo e HTTP 503 quando não está. Uma sonda TCP simples apenas deteta se o socat está a ouvir; uma sonda HTTP ao nível da aplicação deteta um túnel morto mesmo quando o SOCAT ainda está a funcionar.
  • Balanceador de carga:
    • Frontend: IP privado na sub-rede do proxy.
    • Pool de backend: Todas as VMs proxy.
    • Regra de balanceamento de carga: TCP na porta de recursos (por exemplo, porta 3306 para MySQL).
    • Sonda de saúde: HTTP GET contra o endpoint de verificação de saúde em cada VM proxy. Um ponto de partida recomendado é um intervalo de 5 segundos com 2 falhas consecutivas para marcar uma VM como insalubre — ajuste à sua tolerância de recuperação.
  • Serviço de conectividade privada (necessário para computação serverless): Ligado ao frontend do balanceador de carga com uma sub-rede NAT dedicada. O Azure utiliza um Private Link Service (PLS).
  • Host de túnel local: Executa um autossh processo por VM proxy. Uma única autossh ligação suporta múltiplos -R encaminhamentos de portas (uma ligação SSH, múltiplos túneis) para configurações com múltiplos recursos. Use os serviços do systemd com Restart=always. Os túneis interativos terminam no logoff e não são adequados para ambientes de produção.

Configurar o Azure Databricks

Crie uma ligação ao seu recurso local usando o IP frontend do balanceador de carga. Selecione o separador para o seu tipo de computação.

Note

Os exemplos seguintes utilizam MySQL. Para outras bases de dados, substitua o tipo de ligação, a porta e a coordenada Maven do driver JDBC.

Computação clássica

Antes de ligar, confirme se o peering entre o VNet do hub proxy e o VNet do seu espaço de trabalho Azure Databricks está ativo. Depois usa o IP privado frontend do balanceador de carga na configuração da tua ligação:

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

As consultas falham no modo de acesso partilhado porque o isolamento do classloader impede os executores de aceder a drivers JDBC baseados em Maven. Use o modo de acesso de utilizador único para verificar se o driver está disponível em todo o cluster. Antes de criar a ligação, adicione o driver JDBC à lista de permissões do Unity Catalog:

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

Computação sem servidor

  1. Como administrador de conta, vá ao painel de administração da conta.

  2. Na barra lateral, clique em Segurança.

  3. Clique em Configurações de conectividade de rede e crie um NCC para a sua região de espaço de trabalho.

  4. No NCC, adicione uma regra de endpoint privado e introduza o ID do recurso do serviço.

  5. Anexe o NCC ao seu espaço de trabalho e espere 10–15 minutos pela propagação.

  6. Aprove a ligação ao endpoint privado no serviço de conectividade privada:

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

  7. Crie a ligação usando o domínio do endpoint privado:

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

O botão Test Connection na interface do Azure Databricks não funciona para ligações privadas de endpoint. Ignora e cria a ligação diretamente.

Lakeflow Connect CDC

O gateway Lakeflow Connect corre em classic compute na workspace VNet e alcança as VMs proxy através de peering. Use o IP privado do frontend do balanceador de carga como anfitrião de ligação, não o IP de uma VM proxy individual. Veja Alta disponibilidade e resiliência de oleodutos.

Antes de criar um pipeline CDC, complete os seguintes passos para o seu motor de base de dados:

  1. Ative o registo de alterações: Configure a sua base de dados para registar alterações ao nível das linhas (por exemplo, registo binário no MySQL, replicação lógica no PostgreSQL ou registo suplementar no Oracle).

  2. Conceder permissões de replicação: Fornecer ao utilizador do pipeline as permissões necessárias para ler registos de alterações e realizar snapshots. Consulte a documentação do conector relativa à sua base de dados específica.

  3. Defina a retenção de registos: Configure a retenção de registos para pelo menos sete dias. Se o gateway CDC estiver offline quando os registos expiram, o pipeline deve realizar uma re-snapshot completa de todas as tabelas de origem.

Para configuração específica do motor, consulte a documentação do conector Lakeflow Connect.

Alta disponibilidade e resiliência do oleoduto

Com duas ou mais VMs proxy no pool backend, uma falha de túnel numa única instância não interrompe o serviço. Se um túnel falhar, o serviço de verificação de saúde devolve HTTP 503. O balanceador de carga para então de encaminhar novas ligações para essa VM em aproximadamente 10 segundos.

Note

Usa o IP frontend do balanceador de carga na tua cadeia de ligação, não o IP de uma VM proxy individual. Se um túnel cair, o balanceador de carga redireciona automaticamente o tráfego sem intervenção manual ou tempo de inatividade no pipeline.

Cenário de falha Sem monitorização de saúde da aplicação Com verificação de saúde da candidatura
A VM proxy deixa de responder O balanceador de carga deteta → failover O balanceador de carga deteta → failover
Paragens de reencaminhamento de porto O balanceador de carga deteta → failover O balanceador de carga deteta → failover
Túnel SSH falha, encaminhador de portas em execução O balanceador de carga não consegue detetar falhas intermitentes → Balanceador de carga deteta (HTTP 503) → failover

Para os pipelines Lakeflow Connect CDC, defina a retenção do log binário para pelo menos 7 dias. Se o gateway CDC estiver offline quando os registos binários expiram, o pipeline deve realizar uma re-snapshot completa de todas as tabelas de origem.

Limitações conhecidas

Esta solução tem as seguintes limitações.

  • Cada recurso local requer um mapeamento de portas distinto em cada VM proxy. Para múltiplos recursos do mesmo tipo na mesma porta predefinida, use portas diferentes na interface de rede da VM proxy (por exemplo, 3306, 3307 ou 3308) ou use VMs proxy separadas.
  • Deve provisionar e manter as VMs proxy e o host do túnel local.
  • Um balanceador de carga bloqueia a conectividade de internet de saída padrão para as VMs no grupo de servidores. Instale os pacotes necessários antes de adicionar VMs ao pool.
  • O botão Test Connection na interface do Azure Databricks não funciona para ligações privadas de endpoint.
  • No modo de acesso partilhado, as bibliotecas JDBC do Maven só estão disponíveis no nó do driver. Use o modo de acesso de utilizador único para cargas de trabalho JDBC.

Passos seguintes

  • Last updated on