【正文】 y標準歸標準，真正建設時候最重要的參考條件還是應用的需求，像銀行可以直接去調研儲戶能容忍多長時間取不出來錢，騰訊去問問用戶能容忍多長時間上不了線，就都知道該怎么設計容災恢復時間了。真正在玩多中心災備的行業(yè)，國內集中在金融系統(tǒng)（尤其是銀行），政府和能源電力等公字頭產(chǎn)業(yè)，國外的不太清楚，但我想以盈利為主要目的企業(yè)不會有太強烈意愿去建設這種純備份的低效益站點，更多的是在不同站點內建設一些應用服務級別的備份，所有站點都會對外提供服務。小結在云計算規(guī)模的數(shù)據(jù)中心中，對于LB類型的多虛一集群技術，執(zhí)行者（概念參見文檔前面集中云部分）少上幾個不會影響全局任務處理的，只要在擴容時做到數(shù)據(jù)中心間大二層互通，所有站點內都有計算任務的執(zhí)行者，并且配合HA技術將協(xié)調者在不同站點做幾個備份，就已經(jīng)達到了應用容災的效果。針對一虛多的VM備份，VMware/XEN等都提出了虛擬機集群HA技術，此時同樣需要在主中心站點與備份中心站點的服務器間提供二層通道以完成HA監(jiān)控管理流量互通，可以達到基于應用層面的備份。云計算數(shù)據(jù)中心多站點主要涉及的還是擴容，會部署部分針對VM做HA的后備服務器，但是不會搞純?yōu)膫湔军c。針對多站點間網(wǎng)絡互聯(lián)的主要需求就是能夠做而二層互聯(lián)，當站點數(shù)量超過兩個時所有站點需要二層可達，并部署相關技術提供冗余避免環(huán)路。 多站點選擇數(shù)據(jù)中心建設多站點后，由于同一應用服務可以跑在多個站點內部，對Client來說就面臨著選擇的問題。 首先要記住的是一個Client去往一個應用服務的流量必須被指向一臺物理或虛擬的 Server。你可以想象一個TCP請求的SYN到ServerA，而ACK到了ServerB時，ServerA和B為了同步會話信息都會瘋掉。想辦法維持一對ClientServer通信時的持續(xù)專一是必須的。Client到Server的訪問過程一般分為如下兩步： Client訪問域名服務器得到Server IP地址（很少人會去背IP地址，都是靠域名查找） Client訪問Server IP，建立會話，傳遞數(shù)據(jù)。當前的站點選擇技術也可以對應上面兩個步驟分為兩大類。第一類是在域名解析時做文章，原理簡單來說就是域名服務器去探測多個站點內IP地址不同的服務器狀態(tài)，再根據(jù)探測結果將同一域名對應不同IP返回給不同的Client。這樣一是可以在多個Client訪問同一應用時，對不同站點的服務器進行負載均擔，二是可以當域名服務器探測到主站點服務器故障時，解析其他站點的服務器IP地址給Client達到故障冗余目的。這時要求不同站點的服務地址必須在不同的三層網(wǎng)段，否則核心網(wǎng)沒法提供路由。缺點很明顯，對域名解析服務器的計算壓力太大，需要經(jīng)常去跟蹤所有服務器狀態(tài)并Hash分配Client請求的地址。此類解決方案的代表是F5/Radware/Cisco等廠商的3DNS/GSLB/GSS等技術。第二類就是把多個站點的服務IP地址配置成一樣，而各個站點向外發(fā)布路由時聚合成不同位數(shù)的掩碼（如主中心發(fā)布/25位路由，備中心發(fā)布/24位路由），或通過相同路由部署不同路由協(xié)議Cost值以達到主備路由目的。使用掩碼的問題是太細則核心網(wǎng)轉發(fā)設備上的路由數(shù)量壓力大，太粗則地址使用不好規(guī)劃很浪費。使用Cost則需要全網(wǎng)IP路由協(xié)議統(tǒng)一，節(jié)點規(guī)模受到很大限制。另外這種方式只能將所有Client訪問同一服務IP的流量指向同一個站點，負載分擔只能針對不同的服務。好處則是這種站點選擇技術誰都能用，不需要專門設備支持，部署成本低成為其存活的根據(jù)。在云計算大二層數(shù)據(jù)中心部署下，各個站點提供同一服務的Server都處于一個二層網(wǎng)絡內，且不能地址沖突，與前面描述的兩種站點選擇技術對服務器IP設置要求都不匹配，因此需要配合SLB設備一起使用?？梢岳斫馄錇橐环N基于IP粒度的多虛一技術，使用專門LB硬件設備作為協(xié)調者，基于IP地址來分配任務給服務組中不同的Server執(zhí)行成員。LB設備通常將多個Server對應到一個NAT組中，外部訪問到一個NAT Server虛擬IP地址，由LB設備按照一定算法分擔給各個成員。LB設備同時會探測維護所有Server成員狀態(tài)。當各個站點內LB設備將同一服務對外映射為不同的虛擬IP地址時，可以配合域名解析方式提供Client選路；而配置為相同時則可以配合路由發(fā)布方式使用。現(xiàn)有的站點選擇技術都不盡如人意，即使是下文介紹的Cisco新技術LISP也只是部分的解決了路由發(fā)布技術中，發(fā)布服務器地址掩碼粒度過細時，給核心網(wǎng)帶來較大壓力的問題，目前還不算是一套完整的站點選擇解決方案。個人感覺，最好的路還是得想法改造DNS的處理流程，目前的DNS機制并不完備，在攻擊面前脆弱不堪，后面的安全附加章節(jié)中會對此再深入討論。 數(shù)據(jù)中心小結又到了小結部分，云計算數(shù)據(jù)中心相比較傳統(tǒng)數(shù)據(jù)中心對網(wǎng)絡的要求有以下變化： ServerServer流量成為主流，而且要求二層流量為主。 站點內部物理服務器和虛擬機數(shù)量增大，導致二層拓撲變大。 擴容、災備和VM遷移要求數(shù)據(jù)中心多站點間大二層互通。 數(shù)據(jù)中心多站點的選路問題受大二層互通影響更加復雜。題內話，F(xiàn)CoE并不是云計算的需求，而是數(shù)據(jù)中心以網(wǎng)絡為核心演進的需求，至于云計算里面是不是一定要實現(xiàn)以網(wǎng)絡為核心，就看你是站在哪個設備商的角度來看了。4 網(wǎng)絡說到網(wǎng)絡，這里關注的重點是前文提到的數(shù)據(jù)中心內部服務器前后端網(wǎng)絡，對于廣泛意義上的數(shù)據(jù)中心，如園區(qū)網(wǎng)、廣域網(wǎng)和接入網(wǎng)等內容，不做過多擴散。 路由與交換網(wǎng)絡世界永遠的主題，至少目前看來還沒有出現(xiàn)能取代這二者技術的影子，擴展開足夠寫好幾本書的了。數(shù)據(jù)中心的網(wǎng)絡以交換以太網(wǎng)為主，只有傳統(tǒng)意義的匯聚層往上才是IP的天下。參考前文的需求可以看出，數(shù)據(jù)中心的以太網(wǎng)絡會逐步擴大，IP轉發(fā)的層次也會被越推越高。數(shù)據(jù)中心網(wǎng)絡從設計伊始，主要著眼點就是轉發(fā)性能，因此基于CPU/NP轉發(fā)的路由器自然會被基于ASIC轉發(fā)的三層交換機所淘汰。傳統(tǒng)的Ethernet交換技術中，只有MAC一張表要維護，地址學習靠廣播，沒有什么太復雜的網(wǎng)絡變化需要關注，所以速率可以很快。而在IP路由轉發(fā)時，路由表、FIB表、ARP表一個都不能少，效率自然也低了很多。云計算數(shù)據(jù)中心對轉發(fā)帶寬的需求更是永無止境，因此會以部署核心接入二層網(wǎng)絡結構為主。層次越多，故障點越多、延遲越高、轉發(fā)瓶頸也會越多。目前在一些ISP（Internet Service Provider）的二層結構大型數(shù)據(jù)中心里，由于傳統(tǒng)的STP需要阻塞鏈路浪費帶寬，而新的二層多路徑L2MP技術還不夠成熟，因此會采用全三層IP轉發(fā)來暫時作為過渡技術，如前面提到過的接入層與核心層之間跑OSPF動態(tài)路由協(xié)議的方式。這樣做的缺點顯而易見，組網(wǎng)復雜，路由計算繁多，以后勢必會被Ethernet L2MP技術所取代。新的二層多路徑技術會在下文做更詳細的介紹，不管是TRILL還是SPB都引入了二層ISIS控制平面協(xié)議來作為轉發(fā)路徑計算依據(jù)，這樣雖然可以避免當前以太網(wǎng)單路徑轉發(fā)和廣播環(huán)路的問題，但畢竟是增加了控制平面拓撲選路計算的工作，能否使其依然如以往Ethernet般高效還有待觀察。MPLS就是一個尷尬的前車之鑒，本想著幫IP提高轉發(fā)效率而生根發(fā)芽，沒想到卻在