很多用戶在搭建混合云架構(gòu)時，會使用到微軟Azure虛擬網(wǎng)絡(luò)中的 VPN功能，來實(shí)現(xiàn)Azure中的虛擬網(wǎng)絡(luò)與用戶本地數(shù)據(jù)中心的網(wǎng)絡(luò)連接。由于Azure VPN連接是基于公網(wǎng)Internet建立，而公網(wǎng)偶爾丟包的現(xiàn)象普遍存在，比如由于某臺交換機(jī)繁忙或者物理線路不穩(wěn)定等各種因素導(dǎo)致丟包。根據(jù)很多使用 Azure VPN客戶的網(wǎng)絡(luò)監(jiān)控經(jīng)驗(yàn)來看，基于互聯(lián)網(wǎng)的連接，偶爾的網(wǎng)絡(luò)丟包會造成Azure和用戶數(shù)據(jù)中心兩邊的服務(wù)器可能暫時通訊無響應(yīng)的現(xiàn)象，比如Ping request timed out ，注意這并不代表VPN鏈路的中斷，且通常也會在最長1-2分鐘內(nèi)自行恢復(fù)。
如需要判斷VPN鏈接是否真的中斷，則通常需要通過網(wǎng)絡(luò)抓包及日志的分析，確認(rèn)在問題發(fā)生前后IPSEC是否有進(jìn)行rekey，在IPSEC日志中 確認(rèn)是否有VPN re-negotiation的動作。如果問題發(fā)生前后SPI ID 沒有變化這代表著VPN使用的是同一Session。而如果VPN的IPSEC發(fā)生過中斷，那么SPI ID是一定會有變化的。
由于網(wǎng)絡(luò)丟包偶爾會造成VPN兩端服務(wù)器暫時通訊無響應(yīng)的現(xiàn)象，我們對基于VPN的混合云在應(yīng)用層面的架構(gòu)有以下幾點(diǎn)建議：
1. 應(yīng)用架構(gòu)中對于數(shù)據(jù)傳輸或交互的實(shí)時性、響應(yīng)速度、帶寬、延時等因素要求很高的組件，比如一個典型交易系統(tǒng)的web 應(yīng)用層和其對應(yīng)的數(shù)據(jù)庫，建議要放置在同一個數(shù)據(jù)中心里，而不是基于internet的VPN通道通訊。
2. 對于在Azure數(shù)據(jù)中心和用戶本地數(shù)據(jù)中心需要通過VPN通道進(jìn)行交互的系統(tǒng)，比如數(shù)據(jù)的訪問或同步等需求，建議應(yīng)用層面需要具備異步通訊以及重試的機(jī) 制，這樣即便是網(wǎng)絡(luò)偶爾丟包造成請求失敗，應(yīng)用層面也會有所準(zhǔn)備而不會由于一次連接不上就直接報錯。比如SQL Server的高可用技術(shù)如Always On, 數(shù)據(jù)庫鏡像等都是支持這種異步的數(shù)據(jù)同步以及重試機(jī)制的，在網(wǎng)絡(luò)偶爾丟包然后又恢復(fù)后，SQL Server會自動恢復(fù)繼續(xù)后臺的數(shù)據(jù)同步。
博文出處：http://blogs.msdn.com/b/azchina/archive/2015/02/15/vpn.aspx
京公網(wǎng)安備 11010502049343號