Azure Batch连接跨订阅Azure SQL故障及解决方案咨询

两种场景连接结果不一致的原因 #

核心是你司自有SQL Server和客户侧SQL Server的网络访问控制配置不同，常见差异点如下：

• 你司另一订阅下的SQL Server大概率开启了允许Azure服务和资源访问此服务器的默认规则，该规则会自动放行所有Azure公有云内的服务访问请求，即便Batch节点IP是动态的也能正常连通；而客户侧SQL Server没有开启该规则，只允许手动添加的固定IP访问，未备案的Batch节点IP自然会被拦截。
• 另一种可能是你司的SQL Server和Batch服务已经完成了内网打通配置，比如配置了VNet对等连接、私有端点，或者提前把Batch节点所属的VNet地址段加入了SQL白名单，访问走内网链路不经过公网防火墙拦截；而客户侧SQL Server没有做相关内网打通配置，公网访问请求被防火墙拦截。

动态Batch节点IP场景下的可行访问方案 #

以下是生产环境常用的4种落地方式，可根据双方的安全要求和配合度选择：

• 配置固定公网出口IP：将Azure Batch池部署在你司可控的VNet中，给该VNet绑定NAT网关并关联固定公网IP，所有Batch节点的对外访问流量都会通过该固定IP出口，只要把这个固定IP提供给客户加入防火墙允许列表即可，是目前适用范围最广的方案。
• 开启客户侧SQL的Azure服务访问规则：协调客户在SQL Server的防火墙配置中开启允许Azure服务和资源访问此服务器的开关，无需单独添加IP即可放行所有Azure内部服务的访问请求，适合对安全要求较低、配合度高的客户。
• 内网私有访问：协调客户为其SQL Server配置私有端点，再通过VNet对等连接打通你司Batch所在VNet和客户SQL所属VNet，整个访问链路走Azure内网，完全不经过公网，不需要配置公网IP白名单，安全性最高，适合对数据安全要求高的场景。
• 动态更新防火墙规则：如果Batch任务是周期性批次运行，可以在任务启动脚本中调用Azure SQL的管理接口，自动将当前运行任务的Batch节点公网IP添加到客户侧SQL的防火墙允许列表，任务执行完成后再调用接口删除该IP规则，该方案需要客户给你开放SQL防火墙的配置权限，适合双方信任度极高的合作场景。

内容的提问来源于stack exchange，提问作者Martin Staufcik