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

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

由DCI連接的應用需要使用以太網，這樣就會帶來巨大的挑戰，包括延時問題，還可能創建環路從而導致網絡崩潰。有多種方案可以應對這種挑戰，包括使用運營商服務，如VirtualPrivateLAN服務，但是這些方案也存在自身局限性。

例如，當VPLS可用來阻止運營商網絡中的循環時，它不會阻止客戶內部網絡中出現循環。VPLS可能帶來延時并因此影響應用的使用?？蛻艋蛟S想使用MultichassisLinkAggregation之類的技巧，在這種技巧中，兩到多個以太網交換機在本地合并到一起使兩條以太網連接成為一條。

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

數據中心互聯增強應用有效性

應用如果出現故障，對企業的損失是比較大的，特別那些關乎關鍵業務的系統。阻止應用故障的策略之一就是創建數據中心的互聯，或是用DCI連接兩個數據中心，這樣當故障出現在一個數據中心的時候，應用會繼續在另一個數據中心里運行。在ITIL推薦要發揮所有固有資產價值以及使用積極數據中心模式的倡導下，這種方法得到了進一步發展。

有兩種方法可在兩個數據中心中創建可用性較高的應用。第一是選擇一個應用，在其中一個數據中心中使用這個應用，而另外一個數據中心則作為備用。這樣，當第一個數據中心出現故障時，應用會轉換到另一個數據中心繼續運作。監控管理技術，如VMmare的vMotion，可以讓虛擬機從一個物理服務器轉移到另一個服務器上，通過此項操作來實現進程的持續運作。

第二種選擇是應用同步化，這樣就可以在兩個數據中心里同時運行應用。群集，共享和存儲復制等技術都有助于實現同步化。

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

問題在于，雖然以太網可在數據中心電纜上傳輸幾百米，但是它的局限性也會對企業創建DCI形成阻礙。這些阻礙包括延時和帶寬挑戰。

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

延時問題

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

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

你的企業有沒有為改善網絡制定預算?

▲圖一：改善網絡連接的預算

實踐結果是數據中心的距離在50-75公里范圍內可以進行可靠的VM遷移。

遺憾的是，這個距離對于較嚴重的災難恢復計劃而言還不夠(如颶風，地震或是區域性的電信故障)。因此企業要平衡應用應對災難恢復要求的彈性。

延時還會影響存儲復制，特別是在同步復制中，數據塊寫入必須在兩個站點間在5-10毫秒內復制完，這要取決于恢復點的目標恢復時間。

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

另一個導致延時的不顯著因素是運營商往往使用隧道協議，如MPLS，ATM或SONET。MPLS網絡的問題在于運營商不能保障網絡中兩站點之間的路徑。運營商網絡可能在一個城市的多個節點跳動，這樣以太網絡幀在轉發時會增加處理延時。

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

QoS挑戰

應用在兩個數據中心之間的有效性也會影響QoS設置的限制。以太網有五個可用的QoS類可以對數據流進行分類管理，這樣便能限制第二層數據中心互聯可以處理的服務量。

▲

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

注意，不論有多少帶寬可用，都可能出現瞬時數據爆發占用所有帶寬，從而使你的QoS設置失效。這種情況可能出現在數據路徑的任何一處，即便是以微秒來計算的數據爆發都嚴重影響整體傳輸性能。網絡阻滯可能導致各種數據回流，致使問題復雜化。

TrafficTrombone

創建DCI過程中以太網面臨的另一種挑戰是“TrafficTrombone(網絡內部的信息往返流動)”(圖3)。以在線商務為例：它有面向公眾的Web/應用服務器，該服務器可連接至內部數據庫服務器。假設，有一個VLAN已被擴展到第二個數據中心。

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

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

▲

阻止循環

以太網為DCI的創建帶來了另一個技術性障礙。以太網創建于30年前，是一種本地網絡協議，所以當時沒有考慮到跨機器擴展。就設計而言，以太網是一種多路存取技術，所以可通過網絡上的所有端點接收以太網廣播和多點傳播幀。

因此，當主機發送以太網廣播或多點播幀時，這個幀必須通過所有以太網進行轉發，包括DCI。當廣播幀循環回到以太網網絡時，它就會被所有交換機轉發，即便它此前已被廣播。這就制造了一種快速消耗所有網絡帶寬的條件，而結果便是導致網絡癱瘓。

數年前開發的生成樹協議就是為了阻止這種循環，而且它現在仍在沿用，盡管RapidSpanningTreeProtocol(RSTP)已經在可靠性和速度方面有所超越。

問題是SpanningTree不能在長距離傳輸中效果不好。當網絡延時超過250毫秒時，RSTP就不再能阻止循環。

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

供應商開發出了很多技術復雜的方案用于解決循環問題。三種最常見的方案就是VPLS，MLAG/PortChannel和OTV。

#p#副標題#e#

MPLS的變體

被廣泛用于網路電路管理的MPLS協議已經擴展為添加Layer2的方法，包括VPLS，Layer2Pseudowires和MPLS以太網。

VPLS是多協議標記交換的一種形式，可以在使用MPLS的網絡中進行提供透明化的LAN服務。它最顯著的性能是運營商可以輕易將這個服務部署到現有網絡上，因此可用較少的精力和成本銷售新服務。

VPLS比較普遍，因為許多人都會向運營商尋求解決方案。根據2010年InformationWeek對334位IT專業人士進行的調查發現有30%的企業已經部署了VPLS，另外有4%的企業打算在未來12個月里進行部署。

▲WAN服務的使用

雖然這對于運營商來說是件好事，但是如果你想通過創建DCI來提高應用的可用性，那么VPLS的作用是有限的，因為基礎MPLS網絡仍然不穩定，且延時會超過5毫秒。如前所述，延時對VM遷移或其他集群具有極壞的影響。

一個運營商的MPLS網絡容易受到這些問題的影響，因為當網絡被改變，擴展的時候，它會隨時間發生變化。MPLS也讓運營商訂購超量帶寬。雖然每個運營商的的訂購水平不同，但是客戶對帶寬可用性或性能并不確定。這些條件都為客戶網絡帶來了不確定性，而且用來監控Layer2性能的工具也極少。

簡而言之，雖然VPLS是一種可承受網絡延時與不穩定的方案，但是它不適合你想在DCI上運行的重要應用。

Layer2Pseudowires(L2PW)，是對其他與MPLS相關技術(L2TP,，VPWS，L2TPv3等)的統稱，這些技術都是Layer2點對點連接。許多運營商都提供L2PW服務是因為便于他們在現有網絡上進行部署。

對于所有VPLS和L2PW服務而言，客戶必須部署自己的阻止循環方案，因為沒有哪項服務可以阻止客戶網絡中的循環，只能在運營商的網絡中進行阻止?？蛻舯仨毚_保端對端網絡中循環的安全。

▲新WAN方案的部署情況

EoMPLS在常被運營商使用。許多客戶使用EoMPLS在現有企業或私有MPLS網絡上創建自己的L2DIC，特別是使用DWDM/暗光纖的時候。

但是VPLS只適用于EoMPLS：缺少確定性，路徑服務不穩定和服務性能的可視性較差。建議將其作為備用方案或是當你確信運營商提供的服務可以達到協定水平而且你可以對此進行監督時才使用。

超越MPLS

當談到應用可用性的要求時，雖然MPLS及其擴展存在問題，但企業可能想找到它的替代物，包括MultichassisLinkAggregation和OverlayTransportVirtualization。

MultichassisLinkAggregation是用兩個端到端L2服務連接兩個數據中心的最常見方案，大多數網絡供應商都具備MLAG功能，包括Avaya，思科，Dell/Force10，惠普和Juniper。

MLAG是指把兩個或兩個以上以太網交換裝置連成一個單獨的操作裝置的過程。其基本概念是兩個兩個交換機架都有單獨的控制面板，因此可以使用鏈接或聚合實現兩個以太網的連接。

可使用LinkAggregationControlProtocol把機架之間的以太網連接整合成邏輯水平的單獨連接。MLAG最適合短距離網路電路或是DWDM，在這樣的網路電路中可以訪問暗光纖，而且可以同時進行本地L2VLAN和L3路由服務。

思科熱衷于針對非常見問題研發出解決方案，然后以專屬性能的方式提供給客戶。OverlayTransportVirtualization(OTV)也不例外。OTV將以太網幀包裝到IP數據包中，因此可以較低的運營商成本在數據中心之間使用任意Layer3傳輸。

OTV為企業提供了一種很好的方式對使用現有L3MPLS服務的Layer2DCI進行管理，控制和查看。雖然其部署和維護都簡便但是卻需要小心設計才能確保運營商的服務能處理OTV數據。

但是OTV的優勢是可以抵消許可證和硬件成本。OTV僅限于思科Nexus7000交換機和ASR9000路由。其性能取決于運營商的基礎服務滿足你服務目標的程度。

暗光纖和光波

客戶的另一個選擇是在使用暗光纖的數據中心之間部署自己的電纜。雖然這辦法可能因為政府規定而難以實施，但是它卻具穩定性而且不復雜。

如果你可以訪問自己的暗光纖，MLAG就是用于L2服務的最佳選擇。

如果暗光纖不在考慮之列，你可以搜尋DenseWavelengthDivisionMultiplexing來購買不受MPLS網絡問題限制的以太網服務。DWDM將網路電路多元化為鐳射波長，然后在網絡上復制其物理信號。你的數據沒有被轉發，橋接或封裝。你的帶寬可以得到保障，而且可以完全掌控QoS，流量等。

▲無效WAN服務

不過DWDM和暗光纖的資金成本意味著必須有高回報才可行，因此許多客戶選擇同時運行Layer3和Layer2服務。因為DWDM/暗光纖服務是端到端的可靠帶寬而且不會與其他服務共享，你可以控制系統中的所有要素，而且可決定QoS，流量控制和性能。

從技術層面來講，暗光纖/DWDM是實現可靠和可預測網絡傳輸的最實用選擇。L2鏈接控制可通過LLDP/UDLD來創建，而使用EoMPLS與MPLS的L3服務也可用來進行數據隔離以滿足網絡安全需求。一旦你完全控制住網路電路，就可使用MPLS為數據中心里多個層級提供安全保障/隔離。

從商業角度來講，用于暗光纖/DWDM服務的SLA是通過確定性建立聯系。其結果是小型緊湊的MPLS網絡且具有一個MLAG方案的最佳性能。

注意此前我們提到運營商的MPLS服務不是非常有力的選擇，因為用戶缺少控制且對操作缺乏可視性。當你可以自己控制帶寬時——可能是使用暗光纖/DMDW——MPLS成為了數據中心相互連接的實用工具。

▲正確連接

了解自己的局限性

或許使用Layer2DCI應參考的建議是：規模小，結構簡單，了解自己的局限性。如果你資金雄厚，可以選擇暗光纖或DWDM進行關鍵任務安裝，因為有了服務的所有權與控制權就會有產出。

如果光纖或DWDM對你而言太貴了，可以尋求端到端EoMPLS服務或OTV。

注意對于很多企業而言，L2DCI都需要執行配套的培訓和調查研究，因為企業的網絡設計師可能不熟悉MPLS，MLAG和DWDM。

還要注意Layer2DCI可支持少量VLAN。但是如果要擴展到10到20個VLAN，那么規劃與對硬件供應商和運營商的調查就需要更多資金。誤差與錯誤可能摧毀數據中心的網絡，因此不推薦使用大量VLAN。

盡管DCI的使用存在極大挑戰，但是可從操作能力，恢復能力和應用可用性方面對其進行平衡。

花點時間研究和了解相關事宜，特別是運營商服務的可靠性問題上年要進行了解。在通往項目成功與長期可靠性的道路上，你得有個好的開始。

原文鏈接：http://net.it168.com/a2011/1229/1296/000001296127.shtml