在Sagemaker中解决Jupyter Notebook运行的Vertica连接/VPN问题

先做基础连通性校验，排除代码硬错误 #

• 核对连接配置的基础参数：确认host填写的是Vertica实际可访问的地址、port填写的是Vertica客户端监听端口（默认5433，注意和管理端口5434区分），避免脱敏占位符被误填到正式运行代码里。
• 注意当前代码里写入的schema参数，不是vertica_python的合法连接参数，传入后会被自动忽略，不影响连通性但容易干扰排查方向。
• 不要直接运行业务连接代码，先在SageMaker Notebook环境下跑原生TCP连通性测试，定位问题是代码层还是网络层：

  import socket
  vertica_host = "替换为实际的Vertica地址"
  vertica_port = 替换为实际的Vertica端口
  try:
      sock = socket.create_connection((vertica_host, vertica_port), timeout=10)
      print("TCP端口连通测试通过")
      sock.close()
  except Exception as e:
      print(f"连通测试失败：{e}")
  

  只要这个测试超时、报无路由、连接拒绝，就和vertica_python库本身无关，问题出在网络访问层。

VPN关联的核心网络配置排查 #

你本地代码能成功连接Vertica，本质是本地网络通过企业VPN打通了到Vertica所在网段的隧道，但SageMaker默认运行在AWS公有云网络环境下，没有自动接入这条VPN隧道，这是触发当前报错的最常见原因

• 第一类场景：Vertica部署在企业自有IDC/自有VPC内，未对公网开放访问
  这类场景不能靠在Notebook里手动装VPN客户端解决（Notebook是无状态容器，重启后配置会丢失，批处理作业也无法读取手动配置的VPN），正确的解决路径是：
  • 把SageMaker运行实例部署到AWS侧和Vertica所在网络做了VPN/Transit Gateway打通的对等子网段，确保SageMaker实例发出的访问Vertica的流量，能通过已有的企业VPN隧道到达Vertica服务器，不需要在实例内单独配置VPN。
  • 排查两端防火墙/安全组规则：确认SageMaker实例所属的安全组放通了到Vertica端口的出站规则，Vertica侧的防火墙、安全组放通了SageMaker实例所在网段的入站访问规则，避免路由通了但被防火墙拦截。
• 第二类场景：Vertica集群配置了负载均衡、多节点备份
  就算主节点连通，vertica_python默认会自动拉取Vertica集群返回的所有节点的内网地址列表尝试连接，如果列表里存在SageMaker网络路由不到的备节点地址，也会触发“连不上主备地址”的报错。这类问题可以通过修改连接配置固定可访问的节点列表解决：

  conn_info = {
      'host': 确认可连通的Vertica主节点地址,
      'port': 确认可连通的Vertica端口,
      'user': 你的数据库账号,
      'password': 你的数据库密码,
      'database': 你的数据库名,
      # 明确指定当前网络可连通的备份节点列表，格式为(节点地址, 端口)
      'backup_server_node': [('可连通的Vertica备节点地址', 对应端口)],
      # 关闭自动负载均衡拉取全集群节点地址的逻辑
      'connection_load_balance': False
  }
  

避坑提醒 #

• 不要依赖在Notebook实例内手动安装VPN客户端做连接：这类配置是临时的，一旦Notebook重启、内核重置、切换到批处理运行模式，VPN配置就会丢失，最终还是会触发连接失败。
• 不要用临时公网端口映射当长期连接方案：临时把Vertica端口映射到公网的方式很容易被防火墙拦截，稳定性没有保障，长期运行必须走内网路由打通的方式。

内容的提问来源于stack exchange，提问作者Hua Lu