【文章內(nèi)容簡介】 件，并學(xué)習(xí)查閱相關(guān)節(jié)點的方法，我司也提供了豐富的標(biāo)準(zhǔn)及私有MIB節(jié)點供客戶部署SNMP監(jiān)控時使用。在阿里的運維中，有一個比較特色的功能就是其syslog服務(wù)器和SNMP網(wǎng)管系統(tǒng)實現(xiàn)了聯(lián)動功能，當(dāng)Syslog接受到的某些日志等級較高時，通過預(yù)先定義的風(fēng)險等級，SNMP系統(tǒng)可實現(xiàn)報警功能，另外采用專用的SNMP節(jié)點，網(wǎng)關(guān)軟件的配合也可以實現(xiàn)交換機配置文件的自動備份與上傳。當(dāng)然完善的網(wǎng)管系統(tǒng)，不僅僅依賴與設(shè)備軟件平臺的相關(guān)特性，網(wǎng)管軟件系統(tǒng)的智能化、圖形化、可用性也能夠極大的提高網(wǎng)絡(luò)管理監(jiān)控的效率，成為網(wǎng)絡(luò)管理人員的一個強有力輔助工具。 升級特性數(shù)據(jù)中心網(wǎng)絡(luò)對可用性要求很高，通常情況下不允許中斷，當(dāng)然一些必須的軟硬件升級時除外，所以設(shè)備如果支持ISSU（InService Software Upgrade，不中斷業(yè)務(wù)升級）將會最大的減少客戶計劃內(nèi)的設(shè)備/網(wǎng)絡(luò)停頓，大大提高網(wǎng)絡(luò)可用性。ISSU是在NSF（不間斷轉(zhuǎn)發(fā)）的基礎(chǔ)上實現(xiàn)的，需要依靠雙引擎的硬件特性，對于不支持冗余引擎的低端設(shè)備，我司提供了Warm Upgrade技術(shù)也可以有效減少設(shè)備重啟更新的時間。它將正常升級過程中BIN 鏡像加載和解壓縮的過程提前到設(shè)備復(fù)位前的正常工作時期，然后利用新程序的數(shù)據(jù)段的內(nèi)容覆蓋當(dāng)前數(shù)據(jù)段的內(nèi)容，最后跳到主程序入口，執(zhí)行新的程序，從而縮短了設(shè)備復(fù)位時間。在系統(tǒng)需要熱重啟的時候，Warm Reload技術(shù)可以大大減少設(shè)備啟動時間。Warm Reload 是一種快速重啟技術(shù)，它去掉了普通設(shè)備復(fù)位時從FLASH 中加載BIN 鏡像和解壓縮的過程，它用預(yù)先保存的程序數(shù)據(jù)段的內(nèi)容覆蓋當(dāng)前數(shù)據(jù)段的內(nèi)容，然后直接跳到程序入口運行的方式來實現(xiàn)復(fù)位，縮短了設(shè)備復(fù)位時間。視不同的產(chǎn)品，Warm Reload amp。 Upgrade 縮短斷流的時間從30 秒到60 秒不等。具體的細(xì)節(jié)技術(shù)大家可以參考我司提供的配置手冊中Warm Reload和Warm Upgrade部分。注意事項：Warm Reload amp。 Upgrade功能需要設(shè)備經(jīng)過一次冷啟動才能生效。目前我司ISSU功能已能實現(xiàn)基本功能，但由于部分協(xié)議的熱備份尚未完全支持，所以ISSU功能還有待繼續(xù)升級。本次阿里巴巴項目的實施中，即采用了Warm Reload技術(shù)實現(xiàn)熱啟動來有效減少設(shè)備重啟時間。 收斂特性網(wǎng)絡(luò)中鏈路故障/恢復(fù)、設(shè)備down機及恢復(fù)應(yīng)該是無法完全避免的事情了，當(dāng)出現(xiàn)此類異常時間時，收斂特性成為了衡量一個網(wǎng)絡(luò)是否具有高可靠性、容錯性的最直接的指標(biāo)。二三層數(shù)據(jù)的轉(zhuǎn)發(fā)收斂時間越短將給網(wǎng)絡(luò)應(yīng)用帶來的影響越小。收斂特性的提升一方面依賴于我們所采用的組網(wǎng)技術(shù)（舉個例子：服務(wù)器雙網(wǎng)卡聚合、接入層設(shè)備的雙上聯(lián)、核心設(shè)備的VSU（IRF、VSS）虛擬、環(huán)形拓?fù)涞榷紭O大的影響到網(wǎng)絡(luò)出現(xiàn)故障時的收斂時間），一方面依賴如設(shè)備的某些軟硬件特性（例如雙引擎熱備、BFD、DLDP、GR、VRRP、REUP、H3C的OAM，SmartLink等），充分、靈活的設(shè)計網(wǎng)絡(luò)架構(gòu)，并采用相關(guān)可靠性技術(shù)，將極大提高網(wǎng)絡(luò)的可用性及收斂指標(biāo)。下面我們以阿里巴巴項目中跟收斂特性相關(guān)的設(shè)計進(jìn)行介紹。阿里巴巴代號為“云梯”數(shù)據(jù)中心的拓?fù)湓O(shè)計如下：簡介如下：上圖中S2為我司S620048XS交換機，S13為我司S6080交換機，S2一共8臺，S13共38臺，每臺S13均采用8個萬兆口分別上聯(lián)至8臺S6200，通過運行OSPF路由協(xié)議，通過ECMP（交換設(shè)備最大支持8個下一跳，跟芯片支持相關(guān)）實現(xiàn)路由等價負(fù)載均衡。在光纖線路發(fā)生單通等異常時，OSPF路由協(xié)議正常的協(xié)議收斂時間約為40S，為了提高收斂特性，我們采用了OSPF+BFD技術(shù)，BFD（雙向轉(zhuǎn)發(fā)檢測）通過OSPF鄰居建立BFD會話，BFD協(xié)議提供一種輕負(fù)載、快速檢測網(wǎng)絡(luò)設(shè)備之間轉(zhuǎn)發(fā)路徑連通狀態(tài)的方法，其鄰居檢測時間最小可設(shè)置為50ms，可以將鏈路異常檢測控制在ms級，BFD在檢測到鏈路異常后，會通知OSPF路由協(xié)議重新進(jìn)行收斂計算，使得交換機可以通過ECMP進(jìn)行快速的路由切換，將收斂時間從40S減少到1S內(nèi)。服務(wù)器高可用區(qū)域采用了MSTP+VRRP的設(shè)計，使得當(dāng)出現(xiàn)鏈路故障或交換機故障時，能夠達(dá)到冗余備份的目標(biāo)，其最大收斂時間約為3S（VRRP Hello間隔為1S），由于VRRP也可關(guān)聯(lián)BFD，但由于目前BFD在AG口上的支持尚存在一些缺陷，所以目前沒有采用VRRP關(guān)聯(lián)BFD的方案。不同的網(wǎng)絡(luò)模型使用的相關(guān)可靠性特性各不相同，當(dāng)我們在面對各種不通的應(yīng)用模型時，一方面充分考慮冗余備份的設(shè)計，一方面選取適合的可靠性特性，設(shè)計方面的內(nèi)容我們稍后在第5章 設(shè)計實施與項目管理 中進(jìn)行講解。 數(shù)據(jù)中心特性數(shù)據(jù)中心相關(guān)特性是和數(shù)據(jù)中心特有的網(wǎng)絡(luò)/存儲結(jié)構(gòu)及應(yīng)用模決定的。目前總結(jié)來看：主要是三大部分的內(nèi)容：1. FCOE（早期流行的FC存儲和以太網(wǎng)的統(tǒng)一，有效減少服務(wù)器IO、布線、維護(hù)及管理復(fù)雜度）2. DCB特性（存儲FC網(wǎng)絡(luò)和以太網(wǎng)融合后的擁塞控制和帶寬保證技術(shù)） 3. 服務(wù)器虛擬化之后的虛擬機策略控制、動態(tài)遷移策略支持 FCOE支持這里先簡單介紹一下為什么新一代數(shù)據(jù)中心需要FCOE技術(shù)，由于歷史技術(shù)的發(fā)展與興衰及變更，F(xiàn)C技術(shù)一度流行（FC技術(shù)在90年代發(fā)展迅速，由于其高速度、高可靠、低延遲、高吞吐等特性，廣泛應(yīng)用于高性能存儲、大規(guī)模數(shù)據(jù)庫和數(shù)據(jù)倉庫、存儲備份與恢復(fù)、集群系統(tǒng)、網(wǎng)絡(luò)存儲系統(tǒng)、數(shù)字視頻網(wǎng)絡(luò)等領(lǐng)域），正是如此，當(dāng)今的較大型數(shù)據(jù)中心網(wǎng)絡(luò)普遍存在如下結(jié)構(gòu)：（詳見示意圖），存在多個完全不同類型的網(wǎng)絡(luò)區(qū)域。（以太網(wǎng)）（FC光纖網(wǎng)絡(luò)）（高性能計算Infiniband網(wǎng)絡(luò)）隨著歷史的發(fā)展，F(xiàn)C網(wǎng)絡(luò)出現(xiàn)了以下問題： 帶寬和傳輸速率發(fā)展緩慢。FC普及1Gbps的時候，以太網(wǎng)剛剛普及10Mbps；如今以太網(wǎng)進(jìn)入10G時代，F(xiàn)C才普及4G/8G 工程人員的匱乏。在IP/Ethernet網(wǎng)絡(luò)有成千上萬的開發(fā)工程師為其服務(wù)，而FC網(wǎng)絡(luò)只有不到一千名開發(fā)工程師 同時有FC 和以太網(wǎng)兩個網(wǎng)絡(luò)，線路結(jié)構(gòu)復(fù)雜，LAN和SAN資源沒有整合，無法實現(xiàn)復(fù)用FCoE技術(shù)標(biāo)準(zhǔn)可以將光纖FC網(wǎng)絡(luò)通道地映射到以太網(wǎng)，從而可以在以太網(wǎng)上傳輸SAN數(shù)據(jù)，它能夠保護(hù)客戶在現(xiàn)有FCSAN上的投資（如FCSAN的各種工具、員工的培訓(xùn)、已建設(shè)的FCSAN設(shè)施及相應(yīng)的管理架構(gòu)），目前以太網(wǎng)技術(shù)發(fā)展迅速，萬兆、100G平臺都在不斷發(fā)展，具有極大的速度優(yōu)勢。同時，F(xiàn)COE使得FC運行在一個無損的數(shù)據(jù)中心以太網(wǎng)絡(luò)上（需要無損的以太網(wǎng)（DCB特性）保證不丟包）。FCoE技術(shù)有以下的一些優(yōu)點：光纖存儲和以太網(wǎng)共享同一個端口。更少的線纜和適配器。軟件配置I/O。與現(xiàn)有的SAN環(huán)境可以互操作。這樣，F(xiàn)CoE能減少數(shù)據(jù)中心的接口卡、電纜和網(wǎng)絡(luò)設(shè)備，從而使數(shù)據(jù)中心變得比較簡單、綠色環(huán)保。在一些大公司，如果能減少電纜數(shù)量，將會對空氣流動產(chǎn)生積極作用，并減少降溫成本，同時可極大減少網(wǎng)絡(luò)配套設(shè)施投資成本及管理維護(hù)工作量。下圖為服務(wù)器在原有多套網(wǎng)絡(luò)中所需要的接口模型轉(zhuǎn)化到FCOE網(wǎng)絡(luò)之后的明顯變化FCOE技術(shù)的本質(zhì)就是將FC幀封裝到以太幀中，允許LAN和SAN的業(yè)務(wù)流量在同一個以太網(wǎng)中傳送?？偨Y(jié)一下，F(xiàn)COE技術(shù)模型需要的組件如下：1. 服務(wù)器使用新一代萬兆CNA網(wǎng)卡（例如BLADE、Brocade、Emulex、Intel、QLOGIC等）2. 交換機支持FCOE3. 存儲設(shè)備支持FCOE接口（例如NetAPP） 或 FCOE交換機采用FC模塊與原有FC網(wǎng)絡(luò)融合（3b3）軟件版本中正式支持FCOE，F(xiàn)COE技術(shù)尚有很多技術(shù)細(xì)分要點，如遇客戶在項目實施中，會使用FCOE技術(shù)，請及時聯(lián)系TAC工程師予以確認(rèn)。項目中涉及到FCOE技術(shù)的應(yīng)用，請?zhí)崆按_認(rèn)如下信息：1. 存儲設(shè)備廠家及型號2. 服務(wù)器廠家及型號、網(wǎng)卡廠家及型號3. 原有/規(guī)劃 FC/FCOE網(wǎng)絡(luò)連接拓?fù)鋱D4. 存儲設(shè)備數(shù)量、服務(wù)器數(shù)量、支持FCOE交換機數(shù)量K 備注：阿里巴巴本次的云梯網(wǎng)絡(luò)屬于新建網(wǎng)絡(luò)，服務(wù)器均采用自有硬盤，所以無需使用FCOE技術(shù)。 DCB特性有了FCOE技術(shù)后，如何保障存儲流量在以太網(wǎng)上無丟包成為一個挑戰(zhàn)。以太網(wǎng)作為一種盡力服務(wù)的網(wǎng)絡(luò)模型，網(wǎng)絡(luò)繁忙時可能發(fā)生丟包或傳輸故障，由于傳統(tǒng)以太網(wǎng)不可靠的傳輸特性，因此不適合在存儲信息傳輸過程中使用。例如：公共安全場所的監(jiān)控錄像，有研究表明，一個人掠過一個監(jiān)控攝像機最短的時間不到一秒鐘，如果關(guān)鍵數(shù)據(jù)在傳輸過程中丟失，就會給未來的調(diào)查取證造成極大困擾。IEEE數(shù)據(jù)中心網(wǎng)橋(Data Center Bridge，簡稱DCB)工作組提出一系列以太網(wǎng)擴展協(xié)議，來增強傳統(tǒng)以太網(wǎng)傳輸?shù)目煽啃?，解決上述可能的以太網(wǎng)丟包或擁塞問題。主要包括如下4種技術(shù)：1. Priority Flow Control(PFC)基于優(yōu)先級的流控：傳統(tǒng)的以太網(wǎng)是整條鏈路進(jìn)行流控的，它會暫停整條鏈路，阻止一條鏈路上的所有流量。，在一條物理鏈路上，分成了8個虛擬通道，每一個通道分配一個優(yōu)先級。這樣在一條鏈路上可以承載多種業(yè)務(wù)類型，包括FCoE和非FCoE的業(yè)務(wù)。當(dāng)發(fā)生擁塞時，接收端可以在特定的優(yōu)先級虛擬通道上發(fā)送XOFF和XON幀，抑制或者繼續(xù)特定的業(yè)務(wù)，保證高優(yōu)先級或者時延敏感的業(yè)務(wù)的傳輸。我們可以為光纖通道流量，也就是存儲流量，分配一個IEEE ，并為該優(yōu)先等級啟用PFC，從而有效控制存儲流量用于端口擁塞導(dǎo)致的丟包。 Enhanced Transmision Selection(ETS)增強傳輸選擇：IO整合后，多個網(wǎng)絡(luò)流量共享同一條物理鏈路，帶來了一個新的需求：在網(wǎng)絡(luò)繁忙的情況下，如何保證各個網(wǎng)絡(luò)能夠運行正常的最小帶寬。為此IEEE引入增強傳輸選擇（ETS）協(xié)議，來對不同網(wǎng)絡(luò)流量進(jìn)行帶寬分配，保證各個網(wǎng)絡(luò)正常運行所需的最小帶寬。ETS提供一個數(shù)據(jù)中心環(huán)境中的終端和設(shè)備端進(jìn)行帶寬分配的操作模型。ETS，即是對不同的數(shù)據(jù)流預(yù)定不同的帶寬比例，在帶寬不足時，預(yù)先保證高優(yōu)先級流量的比例。下圖，即預(yù)先保留帶寬比例是20：30：50。在t1/t2這個時刻，高優(yōu)先級報文可以擴大自己的比例。ETS算法提供傳輸類之間的帶寬分配功能，支持和低延遲的傳輸選擇算法{嚴(yán)格優(yōu)先級算法(strict priority)和令牌流量整形算法(creditbased shaper algorithms)}共用，ETS所分配的帶寬為其他QOS算法(主要是嚴(yán)格優(yōu)先級算法和令牌流量整形算法)處理后的帶寬。ETS的報文分類以及隊列調(diào)度算法的詳細(xì)配置可參考ETS配置手冊章節(jié)及ETS技術(shù)白皮書 notification IEEE ) CN擁塞通告在傳統(tǒng)的以太網(wǎng)環(huán)境中，網(wǎng)絡(luò)傳輸過程中，當(dāng)網(wǎng)絡(luò)流量達(dá)到最大帶寬后，不可能保證所有流量的傳輸，只能將部分流量丟棄掉。為了保證數(shù)據(jù)流在傳輸過程中不被丟棄，根源的辦法通知數(shù)據(jù)發(fā)送源端，降低數(shù)據(jù)發(fā)送的速率。，就是在這種背景下出現(xiàn)，服務(wù)于增強型以太網(wǎng)，用于提高以太網(wǎng)傳輸?shù)目煽啃栽砣缦拢寒?dāng)服務(wù)器網(wǎng)卡，即反應(yīng)點（CP）在發(fā)送數(shù)據(jù)報文時，會在報文中攜帶CNTag；當(dāng)擁塞點檢測到擁塞時，會將數(shù)據(jù)報文中的CNTag拷貝到擁塞通告消息，一并返回給數(shù)據(jù)源。 CNM(擁塞通告信息)的目的MAC直接是來源主機。CN用于避免網(wǎng)絡(luò)擁塞，以減少丟包和降低網(wǎng)絡(luò)的延遲（擁塞會導(dǎo)致丟包，丟包后重傳將增加報文的延遲）。為達(dá)到避免網(wǎng)絡(luò)擁塞的目的，以太網(wǎng)交換機和端點站（在數(shù)據(jù)中心當(dāng)中，通常指服務(wù)器）均需支持CN：u 當(dāng)以太網(wǎng)交換機檢測到擁塞時，會向數(shù)據(jù)源端點站發(fā)送擁塞通告消息，要求數(shù)據(jù)源端點站降低報文的發(fā)送速率。u 數(shù)據(jù)源端點站收到擁塞通告消息后，降低報文的發(fā)送速率，并周期性嘗試增加報文的發(fā)送速率，如果此時擁塞已經(jīng)消除，增加報文的發(fā)送速率并不會引起擁塞，也就不會再收到擁塞通告報文，報文的發(fā)送速率最終得以恢復(fù)到擁塞之前的值，以充分利用網(wǎng)絡(luò)帶寬。4. Data Center Bridging eXchange Protocol（DCBX）：DCB特性自動協(xié)商機制DCBX利用LLDP協(xié)議交換鏈路兩端的配置信息，發(fā)現(xiàn)對等的配置，并在符合DCB要求的橋接之間交換配置信息，同時DCBX能夠檢測出橋接之間錯誤的配置信息或用于引導(dǎo)對端進(jìn)行配置等。DCBX運行在點對點的鏈路上，它可用于通告本機的ETS、PFC等參數(shù)的配置信息，同時它也期望接收鄰居發(fā)送的配置信息以用于引導(dǎo)本機配置。典型的DCBX參數(shù)交換的過程如下圖所示：DCBX作為LLDP協(xié)議的擴展，它在LLDP協(xié)議的基礎(chǔ)上增加了數(shù)據(jù)中心相關(guān)參數(shù)的TLV信息，協(xié)議本身并不復(fù)雜。如果已支持了LLDP協(xié)議，則也應(yīng)能平滑地支持DCBX協(xié)議。如前所述，DCBX技術(shù)作為LLDP協(xié)議的擴展，依賴于LLDP。同時，DCBX運行在數(shù)據(jù)中心的網(wǎng)絡(luò)中，需要與數(shù)據(jù)中心的其它協(xié)議協(xié)同工作，進(jìn)行數(shù)據(jù)中心相關(guān)參數(shù)的配置和能力交換，方便了管理員部署和維護(hù)網(wǎng)絡(luò)的運行。DCBX的配置比較簡單，主要是一個自動發(fā)現(xiàn)及配置能力的設(shè)置，詳細(xì)內(nèi)容參考DCBX配置手冊章節(jié)，（3b3）軟件項目已經(jīng)支持以上DCB的所有特性?？偨Y(jié)如下：以上4個功能除DCBX自動協(xié)商機制外都是在FCOE網(wǎng)絡(luò)中必須應(yīng)用到的功能，以上功能的配合才能有效保障存儲流量的可靠傳輸，在遇到涉及FCOE項目時，需要了解客戶應(yīng)用模型，了解存儲流量、IP流量的分類（需要優(yōu)先保障的流量、普通業(yè)務(wù)流量），根據(jù)現(xiàn)場模型設(shè)計以上多種報文類型的分類及隊列調(diào)度方式。建議項目實施之前在需求調(diào)研階段了解如下需求：1. 業(yè)務(wù)流量模型（通過網(wǎng)管軟件、端口計數(shù)、業(yè)務(wù)規(guī)劃評估等多方面進(jìn)行了解）2. 需要高優(yōu)先級保障的業(yè)務(wù)及其特征（客戶期望）3. 網(wǎng)絡(luò)中相關(guān)設(shè)備對DCB相關(guān)功能的支持程度（例如：服務(wù)器網(wǎng)卡是否支持CN等）K 備注：阿里巴巴本次的云梯網(wǎng)絡(luò)屬于新建網(wǎng)絡(luò)，沒有FCOE技術(shù)，所以也就沒有DCB相關(guān)應(yīng)用 虛擬化支持這里先說明一下虛擬化技術(shù)在數(shù)據(jù)中心建設(shè)中的重要性