很多用戶在搭建混合云架構時，會使用到微軟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會自動恢復繼續后臺的數據同步。
博文出處：http://blogs.msdn.com/b/azchina/archive/2015/02/15/vpn.aspx
京公網安備 11010502049343號