組合技術(shù)加速企業(yè)應(yīng)用

申請(qǐng)免費(fèi)試用、咨詢電話：400-8352-114

應(yīng)用加速解決方案可減少服務(wù)器集中化造成的許多問(wèn)題，而無(wú)須采用以前購(gòu)買(mǎi)更多帶寬的昂貴方法。同時(shí)，加速解決方案還可以將帶寬方面的投資回報(bào)最大化，使網(wǎng)絡(luò)管理和問(wèn)題解決變得更加容易，并且，即使在實(shí)時(shí)數(shù)據(jù)包服務(wù)的情況下也能改善通訊流量性能。

服務(wù)器集中化是當(dāng)前企業(yè)信息化的一種趨勢(shì)，產(chǎn)生這種趨勢(shì)的原因包括節(jié)約成本、減輕管理負(fù)擔(dān)、采取更為有力的IT安全措施、以及通過(guò)數(shù)據(jù)和應(yīng)用冗余建立企業(yè)穩(wěn)定性。但是，這種實(shí)踐并不能夠解決性能方面的問(wèn)題。通過(guò)將全部應(yīng)用和數(shù)據(jù)存儲(chǔ)服務(wù)分配到離散和集中的站點(diǎn)，企業(yè)能夠減少員工人數(shù)和他們管理、保護(hù)服務(wù)器所需的時(shí)間和精力，并且相對(duì)于服務(wù)器廣泛分布于多個(gè)分支機(jī)構(gòu)的情況來(lái)說(shuō)，還能夠最大限度地降低場(chǎng)地、電力和連接成本。但這種“星形”拓?fù)浞植迹ㄈ坑脩糁苯优c一個(gè)或幾個(gè)中央服務(wù)器連接）的集中化布置也意味著對(duì)這些“數(shù)據(jù)中心”提供的有限帶寬的集中化需求。

面對(duì)有限的預(yù)算，IT管理者沒(méi)有選擇，只有采取節(jié)約成本的各種集中化措施，特別在擔(dān)負(fù)遵循業(yè)務(wù)法規(guī)任務(wù)時(shí)更是如此。所謂的業(yè)務(wù)法規(guī)是指，包括安然事件在內(nèi)的重大金融崩潰案和其它重大的華爾街金融失敗案，以及包括9·11事件和2004年海嘯在內(nèi)的人為和自然災(zāi)害之后制定的企業(yè)法規(guī)。這些法規(guī)要求包括數(shù)據(jù)冗余和其它連續(xù)性措施，以保護(hù)關(guān)鍵的信息和業(yè)務(wù)架構(gòu)，還包括數(shù)據(jù)保留政策，如：為資料恢復(fù)而對(duì)電子郵件進(jìn)行長(zhǎng)期存檔的政策。

全網(wǎng)安全也是服務(wù)器集中化的一個(gè)主要推動(dòng)力。在如今多樣化的環(huán)境中，網(wǎng)絡(luò)攻擊來(lái)自世界各地（也來(lái)自公司內(nèi)部——無(wú)論是否故意）。在這種情況下，服務(wù)器布置的地點(diǎn)越少，就越容易保護(hù)和修理。當(dāng)網(wǎng)絡(luò)侵入或其它硬件或軟件問(wèn)題造成故障時(shí)，IT響應(yīng)團(tuán)隊(duì)需要檢查的機(jī)器越少，故障的解決就越簡(jiǎn)單。

按照前述標(biāo)準(zhǔn)，集中數(shù)據(jù)管理和訪問(wèn)是唯一合理的解決方案，但直到最近才出現(xiàn)了性能問(wèn)題的解決方案。此前解決性能問(wèn)題的“強(qiáng)力”措施費(fèi)用高昂且過(guò)分單一――從提供商那里購(gòu)買(mǎi)更多的帶寬。之所以費(fèi)用高昂，是因?yàn)榻o所有聯(lián)網(wǎng)用戶提供滿意的響應(yīng)速度所須的額外帶寬，通常大大超乎想象；之所以過(guò)分單一，是因?yàn)闆](méi)有考慮網(wǎng)絡(luò)通訊不斷變化的特點(diǎn)，特別是當(dāng)設(shè)備支持延遲敏感型和帶寬消耗型服務(wù)時(shí)，網(wǎng)絡(luò)通訊流量更是不斷變化。

幸運(yùn)的是，我們有了更好的辦法?，F(xiàn)在可以采用應(yīng)用加速解決方案，減少服務(wù)器集中化造成的許多問(wèn)題，而無(wú)須采用以前購(gòu)買(mǎi)更多帶寬的昂貴方法。加速解決 方案還可以將帶寬方面的投資回報(bào)最大化，使網(wǎng)絡(luò)管理和問(wèn)題解決變得更加容易，并且，即使在實(shí)時(shí)數(shù)據(jù)包服務(wù)的情況下也能改善通訊流量性能。

應(yīng)用加速解決方案通過(guò)整合“WEB層”加速解決方案和WAN加速解決方案而發(fā)揮作用。這些解決方案包括負(fù)載平衡、數(shù)據(jù)壓縮、高速緩存、TCP多路技術(shù)、SSL協(xié)議加速、網(wǎng)絡(luò)和協(xié)議安全措施等，這些作為臨時(shí)性補(bǔ)救措施而采用的解決方案可提高WEB和應(yīng)用服務(wù)器以及WAN連接的生產(chǎn)率。應(yīng)用加速解決方案的不同之處在于：新的加速架構(gòu)將各種不同的技術(shù)整合為一個(gè)無(wú)縫的、協(xié)作式的模型，并提供最大可能的優(yōu)化。通過(guò)截取遠(yuǎn)程請(qǐng)求并動(dòng)態(tài)管理這些請(qǐng)求，新的加速架構(gòu)僅支持那些最有效的和減少服務(wù)器集群負(fù)載的請(qǐng)求。通過(guò)加速可以有效地增加服務(wù)器的容量，一般可以將現(xiàn)有服務(wù)器的可用容量加倍，而將頁(yè)面下載時(shí)間減半。

加速組合中最常見(jiàn)的技術(shù)包括：

數(shù)據(jù)壓縮和應(yīng)用加速
廣域鏈接提供的帶寬一般只有LAN的百分之一或更少，但業(yè)務(wù)卻更多地通過(guò)WAN運(yùn)行應(yīng)用程序。壓縮技術(shù)幫助克服帶寬的部分限制，但延遲又是一個(gè)問(wèn)題。延遲采用數(shù)據(jù)包在網(wǎng)絡(luò)上從發(fā)送者到接收者之間的往返時(shí)間（RTT）來(lái)衡量?；ヂ?lián)網(wǎng)上運(yùn)行的所有應(yīng)用程序無(wú)一例外都有延遲。某些應(yīng)用協(xié)議的延遲和“乒乓”動(dòng)作，如Microsoft Exchange和Windows文件共享，直接造成了分支結(jié)構(gòu)員工的應(yīng)用程序性能下降。通過(guò)應(yīng)用加速技術(shù)，可以大大減少數(shù)據(jù)傳輸?shù)难舆t時(shí)間，保證用戶體驗(yàn)的響應(yīng)速度。

流量?jī)?yōu)先級(jí)設(shè)定
除了流量壓縮之外，優(yōu)先級(jí)設(shè)定也可以利用緩解網(wǎng)絡(luò)爭(zhēng)用情況而實(shí)現(xiàn)加速。應(yīng)用程序爭(zhēng)用寶貴的WAN帶寬。除非IT管理者采取主動(dòng)措施，否則低優(yōu)先級(jí)的應(yīng)用程序?qū)?huì)阻擋重要的應(yīng)用程序。控制爭(zhēng)用的一個(gè)有效手段就是實(shí)施帶寬分配和采取服務(wù)質(zhì)量（QoS）措施。IT管理者可以申請(qǐng)業(yè)務(wù)政策，規(guī)定哪些應(yīng)用程序在WAN上擁有優(yōu)先級(jí)，保證必要的帶寬總處于可用狀態(tài)，從而在關(guān)鍵的時(shí)候提高生產(chǎn)率。

網(wǎng)絡(luò)可視性
除加速網(wǎng)絡(luò)之外，統(tǒng)一的加速平臺(tái)還可以提供另外一個(gè)非立竿見(jiàn)影的好處。以前，WAN是一個(gè)IT“黑洞”。WAN活動(dòng)缺乏可視性，給應(yīng)用程序響應(yīng)時(shí)間的診斷造成困難。WAN監(jiān)視和報(bào)告工具昂貴而復(fù)雜，在實(shí)踐上只能對(duì)網(wǎng)絡(luò)或者應(yīng)用程序性能提供非常有限的監(jiān)控，。但是，通過(guò)將所有的流量管理技術(shù)整合成一個(gè)系統(tǒng)，加速平臺(tái)就可以提供系統(tǒng)范圍的監(jiān)視，并以圖形點(diǎn)擊式的執(zhí)行和管理方式進(jìn)行報(bào)告，使流量活動(dòng)更加透明。

隨著企業(yè)在面臨業(yè)務(wù)法規(guī)、支出控制和安全防護(hù)需求的背景情況下著手實(shí)施服務(wù)器集中計(jì)劃，應(yīng)用加速的出現(xiàn)將成為連接集中化優(yōu)點(diǎn)和用戶滿意體驗(yàn)之間的一個(gè)重要橋梁。將WAN與數(shù)據(jù)中心優(yōu)化解決方案整合，能夠加速最大范圍的公司應(yīng)用程序，增加發(fā)送選項(xiàng)，提供無(wú)與倫比的監(jiān)視和報(bào)告工具，以跟蹤性能情況。實(shí)際上，應(yīng)用加速解決方案非常有優(yōu)勢(shì)，市場(chǎng)已迅速地意識(shí)到它的好處。Frost & Sullivan咨詢公司預(yù)計(jì)：亞太應(yīng)用前端加速市場(chǎng)復(fù)合年均增長(zhǎng)率（CAGR）將達(dá)到30%（2004-2011），預(yù)期將成長(zhǎng)為一個(gè)10億美元的產(chǎn)業(yè)。 （ZDNET）