打通數(shù)據(jù)天塹 重新進行廣域網(wǎng)傳輸定義

廣域網(wǎng)數(shù)據(jù)傳輸之痛

今年四月份，作者有幸跟隨一個云計算廠商去國家天文臺懷柔太陽觀測基地參觀。讓我震驚的有兩點，一是科研工作的艱苦，二是網(wǎng)絡(luò)環(huán)境的惡劣。科研雖然艱辛，但那些甘于為科學(xué)奉獻的科技工作者能以苦為樂；網(wǎng)絡(luò)環(huán)境的惡劣卻讓辛苦采集的科研數(shù)據(jù)無法及時向外傳輸。

忽然發(fā)現(xiàn)這是一個非常具有代表性的問題：隨著企業(yè)規(guī)模的拓展，企業(yè)總部與分支機構(gòu)間的信息溝通卻變得越來越有難度。一線城市之間的網(wǎng)絡(luò)傳輸質(zhì)量還可以保障，但二、三線城市或邊遠郊區(qū)的網(wǎng)絡(luò)傳輸就不容樂觀了。此外始終高高在上的專線費用也早已成為企業(yè)信息傳輸永久的痛。

如何解決，當(dāng)時想的很簡單，通過手機的4G無線。4G網(wǎng)絡(luò)的接入成本確實相對較低，但無線傳輸?shù)木W(wǎng)絡(luò)質(zhì)量很難得到保障，而且多一個接入節(jié)點，就會多增加一分網(wǎng)絡(luò)安全隱患。此類企業(yè)分支機構(gòu)的網(wǎng)絡(luò)管理能力必然不強，網(wǎng)絡(luò)安全防范意識也自然淡漠。一旦出現(xiàn)信息安全風(fēng)險，甚至由此做為跳板向總部入侵，損失將無法估量。

NetScaler SD-WAN 廣域網(wǎng)傳輸?shù)挠辛ΡＵ?/p>

有什么解決方案？還得用4G！但是要再加一個“小盒子”思杰的NetScaler SD-WAN。

 圖片附注：下面大盒子是適于企業(yè)總部或大型分支機構(gòu)應(yīng)用的思杰NetScaler SD-WAN 410，上面小盒子是適于企業(yè)小型分支機構(gòu)或小企業(yè)應(yīng)用的思杰NetScaler SD-WAN 210

在思杰官方網(wǎng)站上對NetScaler SD-WAN的介紹是這樣的：NetScaler SD-WAN 可將分組級實時路徑選擇、WAN 優(yōu)化、防火墻、路由和應(yīng)用程序分析整合成一個全面的解決方案。無論是訪問 SaaS 應(yīng)用程序、虛擬化桌面，還是傳統(tǒng)數(shù)據(jù)中心，NetScaler SD-WAN 始終能為客戶帶來持續(xù)的優(yōu)質(zhì)體驗和更簡單更靈活的分支網(wǎng)絡(luò)。

通俗點講，就是思杰的NetScaler SD-WAN產(chǎn)品，可以支持專線、4G等多種WAN網(wǎng)接入方式，將多種接入方式合成一條高帶寬的虛擬鏈路，減少WAN網(wǎng)管理負擔(dān)。并且可以對用戶的外網(wǎng)應(yīng)用訪問進行分級，對高優(yōu)先級的應(yīng)用訪問或數(shù)據(jù)傳輸優(yōu)先進行保障，從而確保企業(yè)核心業(yè)務(wù)數(shù)據(jù)傳輸不會中斷。同時還具有防火墻和應(yīng)用分析管理能力可以讓用戶高效、穩(wěn)定、安全的進行網(wǎng)絡(luò)業(yè)務(wù)應(yīng)用。下面我們就來看一下，如何通過思杰的這個“小盒子”解決網(wǎng)絡(luò)傳輸?shù)拇髥栴}。

NetScaler SD-WAN的真實展示

為了對NetScaler SD-WAN的動態(tài)路由、WAN虛擬化和WAN優(yōu)化功能進行了解，我們搭建了一個雙鏈路的模擬測試環(huán)境，來對NetScaler SD-WAN進行測試。

NetScaler SD-WAN測試拓撲

NetScaler SD-WAN測試場景

NetScaler SD-WAN的配置也十分簡單，將兩個WAN鏈路定義成同一個虛擬端口組，并設(shè)置成網(wǎng)橋模式實現(xiàn)兩條鏈路的透傳就可以了。并不需要更改原先的路由配置，就可以自動學(xué)習(xí)到原有的路由條目。

為了增加數(shù)據(jù)傳輸?shù)陌踩院涂煽啃?，NetScaler SD-WAN還支持IPsec隧道的建立，保證數(shù)據(jù)的傳輸安全。

下面，我們通過JPerf、FTP、文件傳輸和視頻會議分別對NetScaler SD-WAN的數(shù)據(jù)傳輸能力進行測試。

首先看一下在JPerf下的鏈路聚合情況：

Jperf測試-1

從Jperf測試-1中可以看出，在Jperf的網(wǎng)絡(luò)帶寬統(tǒng)計為10,682Kbps，而在下方NetScaler SD-WAN控制臺的虛擬鏈路傳輸統(tǒng)計中，兩條鏈路的傳輸速率分別為9499.34Kbps和1902.18Kbps（由于數(shù)據(jù)包頭和管控協(xié)議，兩個統(tǒng)計數(shù)據(jù)會存在一定誤差）。從統(tǒng)計數(shù)據(jù)可以清晰的了解，Jperf所傳輸數(shù)據(jù)確實被的分配到了這兩條不同帶寬的物理鏈路之中，并且有效的進行數(shù)據(jù)傳輸。

Jperf測試-2

為了對傳輸性能進行驗證，我們手工斷掉10M的鏈路，在Jperf測試-2的統(tǒng)計結(jié)果中可以看出經(jīng)過2-3秒的鏈路重新規(guī)劃，NetScaler SD-WAN的網(wǎng)絡(luò)傳輸又重新穩(wěn)定在了1889Kbps。

Jperf測試-3

反之亦然，當(dāng)我們恢復(fù)鏈接后重新斷掉2M鏈路時，NetScaler SD-WAN的網(wǎng)絡(luò)傳輸最后穩(wěn)定在9450Kbps。在整個過程中，測試數(shù)據(jù)連接并未出現(xiàn)中斷情況。

接下來我們又對NetScaler SD-WAN在FTP和文件共享傳輸時的數(shù)據(jù)傳輸情況進行了測試。從下面測試截圖可以看出，無論是FTP還是文件共享，當(dāng)10M鏈路斷開時，NetScaler SD-WAN的傳輸速率有所下降，但數(shù)據(jù)傳輸均未發(fā)生中止。

FTP傳輸測試

共享文件傳輸

損傷鏈路的數(shù)據(jù)傳輸

在實際的網(wǎng)絡(luò)應(yīng)用過程中，像“挖斷光纖”這樣的斷網(wǎng)行為還是很少出現(xiàn)，但是網(wǎng)絡(luò)中的高丟包、大延時現(xiàn)象還是常有出現(xiàn)。尤其像是4G這種無線網(wǎng)絡(luò)傳輸，丟包、延時問題更是時有出現(xiàn)。傳線的網(wǎng)絡(luò)傳輸情況較好，但傳輸距離過遠的話，還是會不可避免的產(chǎn)生延時現(xiàn)象。這時候的網(wǎng)絡(luò)數(shù)據(jù)傳輸應(yīng)當(dāng)如何保障？

下面我們借用知名測試儀表公司IXIA的鏈路損傷測試儀表——Network Emulator II來模擬丟包和時延的狀況，來對思杰NetScaler SD-WAN在鏈路損傷情況下的數(shù)據(jù)傳輸能力同樣進行了測試。

在本次測試過程中，我們將10M鏈路接入到IXIA Network Emulator II的Port 1和Port 2接口，并在其中分別制造了10%和50%的丟包。并且將2M鏈路接入到IXIA Network Emulator II的Port 5和Port 6接口，并在其中分別制造100ms和500ms的延時。

Network Emulator II Port 1口50%丟包設(shè)置

Network Emulator II Port 5口500ms延時設(shè)置

隨后，我們分別在10M鏈路10%丟包、2M鏈路100ms延時和10M鏈路50%丟包、2M鏈路500ms延時條件下，采用Polycom軟件進行視頻通訊。

10M+2M帶寬  10M+10%丟包、2M 100ms延時

10M+2M帶寬  10M+50%丟包、2M 500ms延時

從測試截圖可以看出，即便是在50%丟包、500ms延時的惡劣網(wǎng)絡(luò)環(huán)境下，視頻傳輸依然清晰。在實際測試過程中也未曾有花屏、卡頓等現(xiàn)象出現(xiàn)。充分體現(xiàn)出NetScaler SD-WAN在鏈路損傷條件下所具備的優(yōu)秀數(shù)據(jù)傳輸體驗。

應(yīng)用識別、帶寬保障 讓數(shù)據(jù)傳輸有法可依

上面各項傳輸測試，都是對單一應(yīng)用的網(wǎng)絡(luò)傳輸能力進行測試的。但是在用戶實際應(yīng)用中，即便是一個小規(guī)模的分支機構(gòu)，也難免有六、七個人的上網(wǎng)需求，網(wǎng)絡(luò)應(yīng)用也各不相同。在這個時候需要如何保障關(guān)系業(yè)務(wù)的穩(wěn)定傳輸？NetScaler SD-WAN所提供的應(yīng)用識別和帶寬保障（QoS）功能可以有效解決這個問題。下面我們再對NetScaler SD-WAN的網(wǎng)絡(luò)傳輸帶寬保障能力進行一下驗證。

首先，在NetScaler SD-WAN上對網(wǎng)絡(luò)應(yīng)用傳輸?shù)膬?yōu)先級進行一下設(shè)置（通常NetScaler SD-WAN的默認設(shè)置就可以滿足用戶需要，在這個設(shè)置中，主要是對我們采用的Jperf測試工具的網(wǎng)絡(luò)傳輸優(yōu)先級進行一下設(shè)置）。

然后我們只使用2M的鏈路進行Jperf的數(shù)據(jù)傳輸，在鏈接基本跑滿后，我們同樣在這條2M鏈路上開始進行Polycom視頻會議，人為造成“帶寬爭搶”情況，對NetScaler SD-WAN的帶寬保障能力進行測試。

從視頻傳輸截圖上可以看出，雖然鏈路傳輸已經(jīng)產(chǎn)生擁堵，但視頻傳輸依然未受到影響，視頻畫面依舊清晰。

通過Jperf的傳輸帶寬中可以看出在視頻會議開始前，傳輸帶寬平穩(wěn)。視頻會議進行時，NetScaler SD-WAN優(yōu)先保障視頻通話，Jperf傳輸帶寬處于上下波動狀態(tài)。當(dāng)視頻會議結(jié)束，Jperf重新利用最大帶寬，傳輸趨于平穩(wěn)。

同步配置，統(tǒng)一管理 可視化的全局監(jiān)控

雖然在NetScaler SD-WAN的整個測試過程中，除了帶寬保障之外均未對設(shè)備進行過多的配置，就可以自動的根據(jù)鏈路狀態(tài)，智能對流量進行分配。但在使用初期還是要對設(shè)備進行一下配置。況且企業(yè)分支機構(gòu)眾多的話，設(shè)備的統(tǒng)一配置管理也會變成一項非常繁雜的工作，尤其是出于數(shù)據(jù)傳輸?shù)陌踩钥紤]，在公司總部與分支機構(gòu)間往往會建立一些VPN隧道進行數(shù)據(jù)的可靠傳輸，此時設(shè)備的配置管理難度會出現(xiàn)大幅度的增長。

對此NetScaler SD-WAN也有著全盤的考慮，利用同步配置功能可以輕松的將總部的NetScaler SD-WAN設(shè)備配置直接下發(fā)到分支機構(gòu)之中，分支機構(gòu)設(shè)備無需再進行任何配置工作。

在實際操作中，只需生成配置文件，將文件推送到Clients設(shè)備，然后重啟并激活配置。通過這三步就可完成遠程設(shè)備配置管理工作。

除了同步配置之外，利用NetScaler SD-WAN所提供的4000多種應(yīng)用識別能力，還可以對各分支機構(gòu)的應(yīng)用流量進行可視化管理。

并且可以對各分支機構(gòu)的鏈路質(zhì)量和帶寬使用率進行統(tǒng)計。從而對全網(wǎng)的鏈路質(zhì)量進行全局掌控。并通過過濾器，查看有哪些客戶端正在使用哪些應(yīng)用（如Mail），統(tǒng)計命中次數(shù)、所選擇的線路、以及每個客戶端甚至每個會話產(chǎn)生的流量大小，這可為內(nèi)網(wǎng)DDoS、帶寬占用原因的排查提供極佳的便利性。

最終繪制出一張全局可視化的網(wǎng)絡(luò)地圖，可以從地圖上點擊每個節(jié)點對其鏈路應(yīng)用狀況進行查詢。

數(shù)據(jù)傳輸云端拓展

通過上述測試和功能性展示我們可以了解，NetScaler SD-WAN具備著高度智能的自動化網(wǎng)絡(luò)鏈路傳輸管理功能，和著良好的數(shù)據(jù)傳輸抗干擾能力。除此之外，為了滿足企業(yè)業(yè)務(wù)上云需求，思杰還在各大云市場上（例如阿里云和中國Azure）推出了NetScaler的虛擬設(shè)備版本，可以輕松滿足用戶數(shù)據(jù)的上云需求。

比如現(xiàn)在阿里云正與國家天文臺合作，共同完成中國虛擬天文臺上云項目，屆時懷柔太陽觀測基地只需要安裝上這樣一個“小盒子”就可以滿足高帶寬共享上網(wǎng)，天文數(shù)據(jù)上云傳輸?shù)葘嶋H網(wǎng)絡(luò)需求，并且無需對網(wǎng)絡(luò)安全、傳輸效率和鏈路損傷等問題再度擔(dān)憂了。

生成海報

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責(zé)任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。