基于VPN搭建混合云架构需要考虑的网络因素

很多用户在搭建混合云架构时，会使用到微软Azure虚拟网络中的 VPN功能，来实现Azure中的虚拟网络与用户本地数据中心的网络连接。由于Azure VPN连接是基于公网Internet建立，而公网偶尔丢包的现象普遍存在，比如由于某台交换机繁忙或者物理线路不稳定等各种因素导致丢包。根据很多使用Azure VPN客户的网络监控经验来看，基于互联网的连接，偶尔的网络丢包会造成Azure和用户数据中心两边的服务器可能暂时通讯无响应的现象，比如Ping request timed out ，注意这并不代表VPN链路的中断，且通常也会在最长1-2分钟内自行恢复。

如需要判断VPN链接是否真的中断，则通常需要通过网络抓包及日志的分析，确认在问题发生前后IPSEC是否有进行rekey，在IPSEC日志中确认是否有VPN re-negotiation的动作。如果问题发生前后SPI ID 没有变化这代表着VPN使用的是同一Session。而如果VPN的IPSEC发生过中断，那么SPI ID是一定会有变化的。

由于网络丢包偶尔会造成VPN两端服务器暂时通讯无响应的现象，我们对基于VPN的混合云在应用层面的架构有以下几点建议：

1. 应用架构中对于数据传输或交互的实时性、响应速度、带宽、延时等因素要求很高的组件，比如一个典型交易系统的web 应用层和其对应的数据库，建议要放置在同一个数据中心里，而不是基于internet的VPN通道通讯。

2. 对于在Azure数据中心和用户本地数据中心需要通过VPN通道进行交互的系统，比如数据的访问或同步等需求，建议应用层面需要具备异步通讯以及重试的机制，这样即便是网络偶尔丢包造成请求失败，应用层面也会有所准备而不会由于一次连接不上就直接报错。比如SQL Server的高可用技术如Always On, 数据库镜像等都是支持这种异步的数据同步以及重试机制的，在网络偶尔丢包然后又恢复后，SQL Server会自动恢复继续后台的数据同步。