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

2022-12-24,,,,

 Joy
Qiao from MSFT Wed, Jan 21 2015 8:44 AM

很多用户在搭建混合架构时,会使用到微软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会自动恢复继续后台的数据同步。

如果你有任何疑问, 欢迎访问MSDN社区,由专家来为您解答Windows Azure各种技术问题,或者拨打世纪互联客户服务热线400-089-0365/010-84563652咨询各类服务信息。

本文转载自:

http://blogs.msdn.com/b/cciccat/archive/2014/12/09/integrated-hadoop-ecosystem-with-azure-hdinsight.aspx

基于VPN搭建混合云架构需要考虑的网络因素的相关教程结束。

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

下载本文的Word格式文档,以方便收藏与打印。