Conectar-se a recursos locais usando um túnel reverso SSH

Conecte seus recursos locais a Azure Databricks sem abrir o acesso de firewall de entrada. Um host de túnel local abre uma conexão SSH de saída com VMs (máquinas virtuais) proxy no Azure, permitindo que o Azure Databricks com computação clássica e sem servidor acesse seus recursos no local.

Como funciona

Um túnel reverso SSH permite que um host de túnel local abra conexões SSH de saída para VMs proxy de nuvem em Azure. Azure Databricks se conecta às VMs proxy por meio de um balanceador de carga e o tráfego flui de volta pelo túnel para o recurso local. A rede local requer apenas SSH de saída (porta 22) para Azure, portanto, nenhuma porta de entrada é necessária.

Em um túnel inverso, o host local inicia a conexão de saída (local para a nuvem) para evitar a necessidade de flexibilizar as restrições de firewall, e o tráfego de retorno flui (nuvem para local) sobre o caminho estabelecido.

A computação clássica atinge as VMs proxy por meio do emparelhamento. A computação sem servidor os alcança por meio de uma conexão de endpoint privado usando o serviço de conectividade privada do provedor de nuvem.

Componentes obrigatórios e opcionais

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

• Um host de túnel no local que está executando autossh para estabelecer a conexão de saída via SSH.
• Uma VM proxy na nuvem em execução socat para aceitar o túnel e expor a porta de recurso em sua interface de rede.
• Um caminho de rede de Azure Databricks para a VM proxy:
  • Classic compute: conexão por emparelhamento entre a VNet do Azure Databricks e a VNet do hub proxy.
  • Computação sem servidor: uma conexão de ponto de extremidade privado usando o serviço de conectividade privada do provedor de nuvem e uma NCC (Configuração de Conectividade de Rede) com uma regra de ponto de extremidade privado.
  • Ambos os tipos de computação: configurar ambos os caminhos.

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

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

• VMs proxy adicionais para redundância.
• Um balanceador de carga à frente das VMs proxy. Fornece um ponto de extremidade estável e failover automático quando um túnel falha.
• Um serviço de verificação de integridade HTTP em cada VM proxy. Isso permite que o balanceador de carga detecte falhas no nível do túnel, não apenas a disponibilidade da VM ou da porta.

Azure Databricks recomenda essa configuração, mas adapte-a aos requisitos de segurança e ambiente.

Hub proxy de túnel

O hub proxy consiste nos seguintes componentes.

• VMs proxy (pelo menos duas para alta disponibilidade). Cada VM proxy executa três serviços:
  • sshd: daemon SSH aceita túneis reversos de entrada do host do túnel no local e coloca o ouvinte do túnel em localhost por exemplo, localhost:13306 para MySQL.
  • socat: conecta o adaptador de rede da VM ao ouvinte do túnel (por exemplo, NIC:3306 → localhost:13306), de modo que o tráfego de Azure Databricks pode chegar ao ponto de extremidade do túnel.
  • Serviço de verificação de integridade HTTP: retorna HTTP 200 quando o túnel está ativo e HTTP 503 quando não está. Uma investigação TCP simples detecta apenas se o socat está escutando; uma investigação HTTP no nível do aplicativo detecta um túnel morto mesmo quando o socat ainda está em execução.
• Balanceador de carga:
  • Front-end: IP privado na sub-rede proxy.
  • Pool de back-end: todas as máquinas virtuais proxy.
  • Regra de balanceamento de carga: TCP na porta de recurso (por exemplo, porta 3306 para MySQL).
  • Sonda de saúde: HTTP GET no endpoint de verificação de integridade em cada VM proxy. Um ponto de partida recomendado é um intervalo de 5 segundos com duas falhas consecutivas para marcar uma VM não saudável – ajuste conforme a sua tolerância de recuperação.
• Serviço de conectividade privada (necessário para computação sem servidor): anexado ao front-end do balanceador de carga com uma sub-rede NAT dedicada. Azure usa um PLS (Serviço de Link Privado).
• Host de túnel local: executa um autossh processo por VM proxy. Uma única autossh conexão dá suporte a vários -R encaminhamentos de porta (uma conexão SSH, vários túneis) para configurações de vários recursos. Use serviços do systemd com Restart=always. Os túneis interativos terminam no logoff e não são adequados para produção.

Configurar o Azure Databricks

Crie uma conexão com seu recurso local usando o IP de front-end do balanceador de carga. Selecione a guia para o tipo de computação.

Computação clássica

Antes de se conectar, confirme se o emparelhamento entre a VNet do hub proxy e a VNet do Azure Databricks workspace está ativo. Em seguida, use o IP privado de front-end do balanceador de carga na configuração de conexã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 compartilhado porque o isolamento do classloader impede que os executores acessem drivers JDBC baseados em Maven. Use o modo de acesso de usuário único para verificar se o driver está disponível em todo o cluster. Antes de criar a conexão, adicione o driver JDBC à lista de permissões do Catálogo do Unity:

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

Computação sem servidor

1. Como administrador de conta, vá para o console da conta.

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

3. Clique nas configurações de conectividade de rede e crie um NCC para sua região de workspace.

4. No NCC, adicione uma regra de ponto de extremidade privado e insira a ID do recurso de serviço.

5. Anexe o NCC ao workspace e aguarde de 10 a 15 minutos para propagação.

6. Aprove a conexão de 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 conexão usando o domínio do ponto de extremidade 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 usuário do Azure Databricks não funciona para conexões de ponto de extremidade privado. Ignore-o e crie a conexão diretamente.

Lakeflow Connect CDC

O gateway do Lakeflow Connect é executado na computação clássica em sua VNet do workspace e alcança as VMs proxy por meio do emparelhamento. Use o IP privado de front-end do balanceador de carga como o host de conexão, não o IP de uma VM de proxy individual. Consulte alta disponibilidade e resiliência de canalização.

Antes de criar um pipeline CDC, realize os seguintes passos para o mecanismo de banco de dados:

1. Habilitar o registro em log de alterações: configure seu banco de dados para registrar alterações no nível de linha (por exemplo, registro em log binário no MySQL, replicação lógica no PostgreSQL ou log suplementar no Oracle).

2. Conceder permissões de replicação: conceda ao usuário do pipeline as permissões necessárias para ler logs de alterações e realizar instantâneos. Consulte a documentação do conector para seu banco de dados específico.

3. Defina a retenção de log: configure a retenção de log para pelo menos sete dias. Se o gateway CDC estiver indisponível quando os logs expirarem, o pipeline deverá executar um instantâneo completo de todas as tabelas de origem.

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

Alta disponibilidade e resiliência em pipelines

Com duas ou mais VMs proxy no pool de back-end, uma falha de túnel em uma única instância não interrompe o serviço. Se um túnel falhar, o serviço de verificação de integridade retornará HTTP 503. Em seguida, o balanceador de carga interrompe o roteamento de novas conexões para essa VM dentro de aproximadamente 10 segundos.

Para pipelines do tipo CDC do Lakeflow Connect, configure a retenção de log binário para pelo menos 7 dias. Se o gateway CDC estiver offline quando os logs binários expirarem, o pipeline deverá realizar um novo instantâneo completo de todas as tabelas de origem.

Limitações conhecidas

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

• Cada recurso local requer um mapeamento de porta distinto em cada VM proxy. Para vários recursos do mesmo tipo na mesma porta padrão, use portas diferentes no adaptador de rede da VM proxy (por exemplo, 3306, 3307 ou 3308) ou use VMs proxy separadas.
• Você deve provisionar e manter as VMs proxy e o host de túnel local.
• Um balanceador de carga bloqueia a conectividade de internet de saída padrão para VMs no pool de back-end. Instale os pacotes necessários antes de adicionar VMs ao pool.
• O botão Test Connection na interface do usuário do Azure Databricks não funciona para conexões de ponto de extremidade privado.
• Em modo de acesso compartilhado, as bibliotecas JDBC do Maven só estão disponíveis no nó principal. Use o modo de acesso de usuário único para cargas de trabalho JDBC.

Próximas Etapas 

• Configurar conectividade privada com recursos do Azure