為了實現(xiàn)重要商業(yè)應(yīng)用的零誤工，一些企業(yè)把數(shù)據(jù)中心也聯(lián)合起來，這樣一來當(dāng)某個數(shù)據(jù)中心出現(xiàn)故障時，上面的應(yīng)用可以切換到另外一個數(shù)據(jù)中心。服務(wù)器虛擬化技術(shù)的出現(xiàn)，如VM遷移，使這一選擇更具靈活性。有些企業(yè)更勝一籌，通過創(chuàng)建相互連接的數(shù)據(jù)中心同時在兩個不同的數(shù)據(jù)中心里運行相同的應(yīng)用。

雖然有許多關(guān)于此部署的架構(gòu)決策，但或許最關(guān)鍵的是兩個數(shù)據(jù)中心如何通過DCI連接。應(yīng)用與虛擬化軟件的要保持同步，則需要兩個數(shù)據(jù)中心之間的延時非常短，通常要控制在毫秒范圍。這一要求在IT和數(shù)據(jù)中心設(shè)計師創(chuàng)建DCI架構(gòu)性時起到了舉足輕重的作用。

由DCI連接的應(yīng)用需要使用以太網(wǎng)，這樣就會帶來巨大的挑戰(zhàn)，包括延時問題，還可能創(chuàng)建環(huán)路從而導(dǎo)致網(wǎng)絡(luò)崩潰。有多種方案可以應(yīng)對這種挑戰(zhàn)，包括使用運營商服務(wù)，如Virtual Private LAN服務(wù)，但是這些方案也存在自身局限性。

例如，當(dāng)VPLS 可用來阻止運營商網(wǎng)絡(luò)中的循環(huán)時，它不會阻止客戶內(nèi)部網(wǎng)絡(luò)中出現(xiàn)循環(huán)。VPLS可能帶來延時并因此影響應(yīng)用的使用?？蛻艋蛟S想使用Multichassis Link Aggregation之類的技巧，在這種技巧中，兩到多個以太網(wǎng)交換機在本地合并到一起使兩條以太網(wǎng)連接成為一條。

其他選擇還包括使用暗光纖和DWDM，二者都可以提供很快的連接。雖然暗光纖和DWDM都很貴，但是它們能為DCI提供最優(yōu)連接。

數(shù)據(jù)中心互聯(lián)增強應(yīng)用有效性

應(yīng)用如果出現(xiàn)故障，對企業(yè)的損失是比較大的，特別那些關(guān)乎關(guān)鍵業(yè)務(wù)的系統(tǒng)。阻止應(yīng)用故障的策略之一就是創(chuàng)建數(shù)據(jù)中心的互聯(lián)，或是用DCI連接兩個數(shù)據(jù)中心，這樣當(dāng)故障出現(xiàn)在一個數(shù)據(jù)中心的時候，應(yīng)用會繼續(xù)在另一個數(shù)據(jù)中心里運行。在ITIL推薦要發(fā)揮所有固有資產(chǎn)價值以及使用積極數(shù)據(jù)中心模式的倡導(dǎo)下，這種方法得到了進(jìn)一步發(fā)展。

有兩種方法可在兩個數(shù)據(jù)中心中創(chuàng)建可用性較高的應(yīng)用。第一是選擇一個應(yīng)用，在其中一個數(shù)據(jù)中心中使用這個應(yīng)用，而另外一個數(shù)據(jù)中心則作為備用。這樣，當(dāng)?shù)谝粋€數(shù)據(jù)中心出現(xiàn)故障時，應(yīng)用會轉(zhuǎn)換到另一個數(shù)據(jù)中心繼續(xù)運作。監(jiān)控管理技術(shù)，如VMmare的vMotion，可以讓虛擬機從一個物理服務(wù)器轉(zhuǎn)移到另一個服務(wù)器上，通過此項操作來實現(xiàn)進(jìn)程的持續(xù)運作。

第二種選擇是應(yīng)用同步化，這樣就可以在兩個數(shù)據(jù)中心里同時運行應(yīng)用。群集，共享和存儲復(fù)制等技術(shù)都有助于實現(xiàn)同步化。

但是許多有應(yīng)用運行的群集和復(fù)制技術(shù)都需要共享一個以太網(wǎng)，而且以太網(wǎng)數(shù)據(jù)會通過單點播放/多點播放或廣播的形式發(fā)送給集群中的所有要素（服務(wù)器，數(shù)據(jù)庫和存儲）。

問題在于，雖然以太網(wǎng)可在數(shù)據(jù)中心電纜上傳輸幾百米，但是它的局限性也會對企業(yè)創(chuàng)建DCI形成阻礙。這些阻礙包括延時和帶寬挑戰(zhàn)。

運營商也提供了一些服務(wù)期望能應(yīng)對諸如此類的挑戰(zhàn)，但是這些服務(wù)在部署方面仍然存在局限性，而且還不足以保障應(yīng)用的高可用性。我們將審查這些挑戰(zhàn)并介紹一些可創(chuàng)建DCI連接的替代物。最佳選擇是使用Multichassis Link Aggregation （MLAG）等技術(shù)，因為它們使用了暗光纖和DWDM服務(wù)。

延時問題

延時是一個比較麻煩的問題。造成延時的原因主要有三個，最主要的就是距離。距離越遠(yuǎn)，電子信號的傳輸時間就越長。

兩個數(shù)據(jù)中心之間最常見的延時底線由VM遷移來決定，如用于VMware vSphere服務(wù)器的vMotion，它可以讓虛擬機從一個物理機組遷移到另一個機組。VMware稱，源服務(wù)器和目標(biāo)服務(wù)器之間的延時必須小于5毫秒 （vMotion Metro 許可證更改了vMotion TCP堆棧使其支持動態(tài)套接緩沖，這樣便調(diào)整了TCP協(xié)議堆棧中里的內(nèi)存數(shù)據(jù)包緩沖，按照延時/帶寬情況優(yōu)化性能，可以容許稍長一點的延時）。

你的企業(yè)有沒有為改善網(wǎng)絡(luò)制定預(yù)算？

▲圖一：改善網(wǎng)絡(luò)連接的預(yù)算

實踐結(jié)果是數(shù)據(jù)中心的距離在50-75 公里范圍內(nèi)可以進(jìn)行可靠的VM遷移。

遺憾的是，這個距離對于較嚴(yán)重的災(zāi)難恢復(fù)計劃而言還不夠（如颶風(fēng)，地震或是區(qū)域性的電信故障）。因此企業(yè)要平衡應(yīng)用應(yīng)對災(zāi)難恢復(fù)要求的彈性。

延時還會影響存儲復(fù)制，特別是在同步復(fù)制中，數(shù)據(jù)塊寫入必須在兩個站點間在5-10毫秒內(nèi)復(fù)制完，這要取決于恢復(fù)點的目標(biāo)恢復(fù)時間。

對于同步操作而言，延時的影響比較小，因為寫入確認(rèn)可以在不影響存儲源的情況下被接收到，而且請求/響應(yīng)順序沒有通過寫入確認(rèn)來限制。但是如果你計劃進(jìn)行亞秒故障轉(zhuǎn)移，通常需要進(jìn)行同步存儲來確保數(shù)據(jù)不被丟失。

另一個導(dǎo)致延時的不顯著因素是運營商往往使用隧道協(xié)議，如MPLS，ATM或SONET.MPLS網(wǎng)絡(luò)的問題在于運營商不能保障網(wǎng)絡(luò)中兩站點之間的路徑。運營商網(wǎng)絡(luò)可能在一個城市的多個節(jié)點跳動，這樣以太網(wǎng)絡(luò)幀在轉(zhuǎn)發(fā)時會增加處理延時。

最后一個導(dǎo)致延時的要素是帶寬。網(wǎng)速快當(dāng)然延時就短；例如，1G接口的延時為5.7毫秒，但是10G接口的延時僅為0.57毫秒。簡而言之，改善延時問題的簡單方法就是使用高帶寬網(wǎng)絡(luò)。

QoS挑戰(zhàn)

應(yīng)用在兩個數(shù)據(jù)中心之間的有效性也會影響QoS設(shè)置的限制。以太網(wǎng)有五個可用的QoS類可以對數(shù)據(jù)流進(jìn)行分類管理，這樣便能限制第二層數(shù)據(jù)中心互聯(lián)可以處理的服務(wù)量。

同時，在DCI上你還有兩股不同類型的數(shù)據(jù)來維持應(yīng)用的有效性：突發(fā)性，高帶寬應(yīng)用和低延時，持續(xù)爆發(fā)的監(jiān)控遷移數(shù)據(jù)流。因此，你必須設(shè)計好QoS設(shè)置使其滿足兩種數(shù)據(jù)的需求。

注意，不論有多少帶寬可用，都可能出現(xiàn)瞬時數(shù)據(jù)爆發(fā)占用所有帶寬，從而使你的QoS設(shè)置失效。這種情況可能出現(xiàn)在數(shù)據(jù)路徑的任何一處，即便是以微秒來計算的數(shù)據(jù)爆發(fā)都嚴(yán)重影響整體傳輸性能。網(wǎng)絡(luò)阻滯可能導(dǎo)致各種數(shù)據(jù)回流，致使問題復(fù)雜化。

Traffic Trombone

創(chuàng)建DCI過程中以太網(wǎng)面臨的另一種挑戰(zhàn)是“Traffic Trombone（網(wǎng)絡(luò)內(nèi)部的信息往返流動）”（圖3）。以在線商務(wù)為例： 它有面向公眾的Web/應(yīng)用服務(wù)器，該服務(wù)器可連接至內(nèi)部數(shù)據(jù)庫服務(wù)器。假設(shè)，有一個VLAN已被擴(kuò)展到第二個數(shù)據(jù)中心。

如果該Web服務(wù)器在兩個數(shù)據(jù)中心間徘徊，它會保留相同的IP地址，所有數(shù)據(jù)都必須穿過DCI鏈接。如圖3所示，里面包括了出入外部用戶端的數(shù)據(jù)以及出入數(shù)據(jù)庫的數(shù)據(jù)。

另需增加的帶寬嚴(yán)重限制了該方案的可擴(kuò)展性而且還增加了帶寬的成本。供應(yīng)商正推出DNS負(fù)載平衡之類的傳輸系統(tǒng)，因為這樣的系統(tǒng)可以隨時將數(shù)據(jù)流發(fā)送到新地址，不過它們的實用性還不足。例如，如果你的數(shù)據(jù)庫沒有用類似Web服務(wù)器這樣的監(jiān)管平臺進(jìn)行虛擬化，你如何能對推動數(shù)據(jù)庫服務(wù)器及其相關(guān)應(yīng)用和Web服務(wù)器機制進(jìn)行管理呢？

阻止循環(huán)

以太網(wǎng)為DCI的創(chuàng)建帶來了另一個技術(shù)性障礙。以太網(wǎng)創(chuàng)建于30年前，是一種本地網(wǎng)絡(luò)協(xié)議，所以當(dāng)時沒有考慮到跨機器擴(kuò)展。就設(shè)計而言，以太網(wǎng)是一種多路存取技術(shù)，所以可通過網(wǎng)絡(luò)上的所有端點接收以太網(wǎng)廣播和多點傳播幀。

因此，當(dāng)主機發(fā)送以太網(wǎng)廣播或多點播幀時，這個幀必須通過所有以太網(wǎng)進(jìn)行轉(zhuǎn)發(fā)，包括DCI.當(dāng)廣播幀循環(huán)回到以太網(wǎng)網(wǎng)絡(luò)時，它就會被所有交換機轉(zhuǎn)發(fā)，即便它此前已被廣播。這就制造了一種快速消耗所有網(wǎng)絡(luò)帶寬的條件，而結(jié)果便是導(dǎo)致網(wǎng)絡(luò)癱瘓。

數(shù)年前開發(fā)的生成樹協(xié)議就是為了阻止這種循環(huán)，而且它現(xiàn)在仍在沿用，盡管Rapid Spanning Tree Protocol （RSTP）已經(jīng)在可靠性和速度方面有所超越。

問題是Spanning Tree不能在長距離傳輸中效果不好。當(dāng)網(wǎng)絡(luò)延時超過250毫秒時，RSTP就不再能阻止循環(huán)。

結(jié)論便是Spanning Tree不能在創(chuàng)建DCI時有效阻止循環(huán)。試一下你就會發(fā)現(xiàn)它易受單向數(shù)據(jù)流的影響，而其他操作都會出現(xiàn)故障。雖然存在單向鏈路檢測協(xié)議（UDLD）這樣的補丁，但是運營商的服務(wù)很有可能會攔截UDLD或是其他減少STP限制的功能。

供應(yīng)商開發(fā)出了很多技術(shù)復(fù)雜的方案用于解決循環(huán)問題。三種最常見的方案就是VPLS，MLAG/PortChannel和OTV.