網際網路公司的生存根本是服務安全、高效、穩定，這三個條件也是網際網路運維從業者的工作基礎，而這些基礎工作絕大部分都依賴于底層網絡服務的健壯性。網際網路行業的網絡服務與傳統行業的網絡服務還是有所差別的。
傳統行業由于業務單一。增加趨勢平穩，是以對于網絡隻有安全性和健壯性的需求；但網際網路行業的特點是服務多元化、業務無規律增加、熱點内容等，是以網際網路行業的網絡服務除了具備安全性、健壯性特點外，還需要支援較高的擴容能力和靈活的按需變化能力。
初期公司創業初期，一方面沒有專職的網絡運維人員，另一方面對未來網絡容量規劃缺少可以參考的曆史資料（伺服器數量、帶寬資料等），是以第一階段的網絡建設是在對未來規劃毫無資料支撐的情況下進行的。并且這裡有個更重要的因素就是在公司産品還沒有盈利的情況下，基礎建設往往都會處于滞後狀态，這應該也是絕大部分創業公司都會面臨的問題。
在一窮二白的時候對網絡方案的選擇更看重以下三個因素。◎ 組網方案的成熟性。◎ 可靠性（主要依賴産品）。◎ 運維便利性。
組網方案和産品選擇初期網絡産品自身的穩定性決定了整體網絡的穩定性，選擇一家業界靠譜的網絡裝置廠商如H3C、Cisco等，是保障初期網絡穩定性的必要條件。初期組網拓撲結構圖如圖9-1所示。
圖9-1 初期組網拓撲結構圖
第一階段的網絡結構采用了傳統分層的Layer 2組網網絡，實體上區分了網際網路接入層、核心層、接入層裝置。自上而下，我們先看網際網路接入層。
網際網路接入層網際網路接入層裝置可以選擇路由器，也可以選擇三層交換機，這裡就不展開介紹這兩種裝置的功能差別了。在某案例中，第一階段的網際網路接入層裝置采用的是三層交換機，主要基于兩個因素考慮。
（1）端口密度：在流量未形成規模時，同時對網際網路接入層裝置沒有過多功能要求時（初期隻運作簡單的靜态路由），三層交換機的端口密度名額作為優先考慮的條件。
（2）成本問題：同樣的成本，端口使用量是路由器的幾倍，三層交換機的成本效益更高。通常在資料中心接入網際網路線路時，線路提供商可以提供如下幾種不同的接入方式（不同的網際網路供應商可能提供的方式有所差別）。◎ VRRP主備線路◎ ECMP雙主線路
在初期網絡建設中，網際網路接入層裝置采用的是雙上聯接口VRRP主備方式，在網際網路流量較小的情況下基本可以滿足對業務帶寬和備援的需求。關于網際網路接入線路的選擇，由于不同資料中心的規模和承建方、人力投入、技術支援、營運能力都不一樣，導緻資料中心提供的線路也有所差別。
國内比較常見的現象是，一級營運商直接提供資料中心資源，那麼資料中心内隻能有一級營運商的線路資源。例如，中國聯通的資料中心隻能提供中國聯通的網際網路線路。在由二級營運商承建或由不同的一級營運商聯合建設的資料中心（此類較少）是可以提供多線或多種單線線路資源的。
線路資源可以分為如下兩類。◎ 單營運商線路：中國聯通、中國電信、中國移動等國内一級營運商線路。◎ 多營運商BGP線路：雙線、四線、六線、八線國内二級營運商提供的線路。
單營運商線路由于是一級營運商直接提供的，是以單線資源在品質、擴容、故障、成本這4個方面要略優于多線資源。但由于中國各營運商自治和網間結算流量費昂貴，導緻業務層面需要使用額外技術手段（如DNS排程、全局負載均衡、CDN等）來提升不同區域和不同營運商使用者的通路品質。
多營運商BGP線路是由二級營運商和各一級營運商建立的BGP鄰居關系，将自有IP位址通過BGP在已建立鄰居關系的一級營運商線路内廣播。從應用角度來看，可以輕松地實作IP多線路的運作模式，不受骨幹網各營運商之間的通路限制，提升了應用通路的速度和品質。
目前國内家用寬帶接入營運商以中國電信、中國聯通為主，例如，主營用戶端遊戲的公司通常選擇雙線（中國電信、中國聯通）的線路為主。但随着2008年中國移動和中國鐵通的合并和移動網際網路的興起，移動線路和教育網在各資料中心中所占的比重也越來越重要了。各營運商流量占比如圖9-2所示。
圖9-2 各營運商流量占比
在使用者至上的時代，顯然在初期使用多線BGP線路這種複合型線路資源解決使用者的問題是立竿見影的。但随着業務規模的擴張、排程系統的完善，以及對成本方面的考慮，多線BGP線路的弊端也逐漸顯現出來。
首先就是成本的壓力 ，随着使用者量的增加，帶寬數量也呈現突飛猛進的增長态勢，以四線BGP線路和單營運商線路為例，它們的成本差距在5倍左右，在強調“節能環保”的今天，這種成本的差距顯然是不可接受的。
其次是故障率和備援切換能力 ，由于多線BGP線路主要是二級營運商承建的，從網絡角度來看，多一跳就意味着多一個故障的隐患。
再者是備援切換能力 ，多線BGP線路在備援切換上分為兩類，業内稱為真BGP多線和僞BGP多線，兩者的差別在于真BGP多線實作了各大一級營運商線路路由的互相備份，當多線BGP線路中其中一個營運商線路出現故障時，故障營運商線路上的路由可以通過其他線路進行繞行通路；然而，僞BGP多線則隻能實作多線路的使用者通路覆寫，無法做到各線路路由的互相備份，當僞BGP多線其中一個營運商線路出現故障時，網絡工程師能做的隻是等待營運商進行故障修複。
還有就是多線BGP線路定向擴容能力。多線BGP線路的優勢在于它具備優秀的線路整合能力，将原本複雜的網際網路環境簡單化。這種複合型線路資源勢必會産生多資源配比的問題，例如，我們購買了1Gbps的四線BGP線路，這是不是代表這4個營運商線路我們單獨都能跑到1Gbps呢？
答案肯定不是這樣的。通常BGP帶寬資源池中的中國電信、中國聯通的帶寬會比較富裕，但一些相對占比較少營運商的帶寬往往會很少。比如某真實案例中，業務移動端流量爆發，導緻移動營運商流量突增，從帶寬監控圖上看帶寬Buffer空間仍然有很多富餘，但論壇總是能收到使用者投訴逾時、連接配接不上伺服器等問題。
最後梳理使用者投訴發現均為移動使用者，協同二級營運商排查後才确定為是由于二級營運商中的移動線路帶寬瓶頸導緻的。對于這個問題，由于多線BGP線路每家提供商的資源都有所不同，業界也沒有一個固定配比原則，是以這部分依然是盲區，不容易規避。
核心接入層和伺服器接入層初期在對業務發展毫無概念的情況下，選擇一套簡單的通用的組網方案和使用相對靠譜的網絡裝置是保障網絡可用性的兩個關鍵條件。
初期核心接入層和伺服器接入層采用Layer 2傳統二層互聯的方式。這種Layer 2傳統組網方式，接入交換機後端伺服器的預設網關都在核心交換機上運作，核心交換機采用VRRP/HSRP（熱備份備援路由協定）提供一個虛拟位址為伺服器預設網關。
核心接入層和伺服器接入層運作STP（生成樹協定）提供伺服器接入層交換機雙上聯核心交換機備援性。STP協定需要生成一個無環并且備援的網絡拓撲，基于 STP協定的特性，需要通過算法在核心和接入層之間選擇一個接口将其置為Blocking狀态，在預設情況下使用Forwarding狀态的接口進行資料轉發，當Forwarding狀态的接口出現故障時，則再次進行STP計算，然後将原Blocking狀态的接口置為（預設35秒完成）Forwarding狀态後恢複資料傳輸。
Layer 2傳統組網方式提供了便捷的伺服器接入能力，伺服器隻需要接入交換機接口，并将接口歸屬到指定的VLAN即可完成伺服器上線。但如果在此階段沒有良好的IP位址規劃，以及在業務爆發期無規律地上線伺服器，再加上某些特殊的應用需要在二層環境下才可以工作，如資料叢集（Keepalived）、LVS-DR模式等，這樣的需求和現狀會導緻需要頻繁的對接口VLAN資訊進行變更，工作量巨大。
為了避免此類操作，初期網絡采取了比較粗暴的方式進行處理，在核心交換機SVI（Switch Virtual Interface）以輔助位址的形式運作多IP，這樣可以解決因伺服器上線和接口變更所帶來的網絡裝置的變更問題（不過是以也為後期埋下了禍根）。interface vlan 100ip policy route-map LVS-DR（坑1）ip address 192.168.1.254 255.255.255.0（坑2）ip address 10.0.1.254 255.255.255.0 secondary（坑3）ip address 10.0.2.254 255.255.255.0 secondary大體上來看，這時的網絡結構滿足了業務需求，并且通過“技術手段”減少了煩瑣的伺服器上線和其他業務需要的網絡裝置變更問題，彌補了初期人力不足的短闆。但實際上該階段的網絡規劃并沒有看起來那麼美好和健壯。
比如在該案例中，使用了192.168.1.0/24位址給忘了運維帶來了困擾。現在做IP位址規劃大家一定不會選擇B類192.168.0.0/16私有位址作為内網的主要位址。原因不止是B類位址比A類位址可使用的位址數少這麼簡單。這裡面所帶來的問題是，如果資料中心存在192.168.1.0/24這個網段的伺服器，我們如何通過遠端VPN的方式管理這台伺服器呢？因為這個位址段預設被D-Link、TP-Link這些家用無線路由器廠商當作初始化的IP位址段。當我們使用PPTP或L2TP遠端撥号VPN遠端通路目标伺服器時，由于本地直連路由比靜态路由的優先級更高，是以通路遠端目标伺服器的資料不會通過VPN發往資料中心目标伺服器，資料包會在本地區域網路進行二層查詢。
上面這個小問題隻是讓遠端辦公的同學們有些不爽而已，還沒有真正地對生産網絡産生影響。下面兩個問題對初期網絡造成了不可小觑的影響，一個是單SVI多IP工作模式引起的問題，二是LVS-DR工作模式引起的問題。
網絡裝置對不同的資料處理分别是基于控制層面和轉發層面進行的。這部分内容在網絡裝置廠商官網有大量的介紹，這裡就不詳細講解了。簡單來說，進入資料控制層面的封包主要靠CPU能力進行處理，轉發平面主要靠硬體能力進行處理。控制層面：控制層面就是各種協定工作的層面。
它的作用是控制和管理各種網絡協定的運作。控制層面主要處理兩類封包，一是抵達裝置自身的，如Telnet、SSH、SNMP；二是負責網絡選路和拓撲變化所使用的協定，如生成樹協定、動态路由協定、多點傳播協定，這些都是由控制層面直接進行處理的。控制層面的處理能力依賴裝置自身的CPU性能，是以在網絡優化中也需要對控制層面進行特殊的防護，如CoPP（Control Plane Policing，控制層面政策）。 總結：控制層面通過軟體（CPU）處理，效率低。
轉發平面：轉發平面的工作主要是對穿越網絡裝置的封包進行處理，Layer 2資料包、Layer 3資料包、通路政策、QoS這些都屬于轉發平面的任務範疇。轉發平面主要依賴裝置接口晶片的處理能力。總結：轉發平面通過硬體（晶片）處理，效率高。
在初期，某案例中，應用時常出現逾時和通路失敗等問題，排查後确定是由于核心交換機CPU負載高引起的（見圖9-3），那麼到底是什麼原因引起的CPU負載高呢？
圖9-3 核心交換機CPU負載高
原因一：
交換機在進行三層轉發時，如果路由下一跳在一個二層網段或者在相同的VLAN下，則會産生ICMP Redirects封包，這種封包是直接進入交換機的控制層面處理的，這類流量由交換機CPU直接處理。單SVI多IP工作模式會過度産生直接由交換機CPU處理的封包，這是導緻核心交換機CPU負載高的一個主因。High CPU Due to Excessive ICMP RedirectsYou can get ICMP dropped redirects when one VLAN (or any Layer 3 port) receives a packet where the source IP is on one subnet, the destination IP is on another subnet, and the next hop is on the same VLAN or layer 3 segment.
原因二：由于LVS-DR工作模式的特性，Real Server（後端目标伺服器，後續簡稱RS）在進行響應時，需要使用伺服器自身Lo綁定的VIP位址進行回包。LVS後端伺服器存在兩種部署模式，第一種為後端RS配置公網IP；第二種為後端RS配置内網IP。第一種模式下可以依賴後端RS自身的預設網關完成資料包的回包工作；第二種模式下則需要網絡層通過PBR（Policy-Base Route，政策路由）對流量進行特殊的處理。
由于第一種部署模式會将後端伺服器直接暴露在網際網路上，存在安全風險，是以當初出于安全的考慮，後端伺服器采用了第二種部署模式。這就導緻需要在網絡層使用PBR對這部分特殊的流量進行處理。某些低端核心交換機在開啟PBR這個特性時存在一些限制，會導緻導緻核心交換機CPU負載過高。High CPU Due to Policy Based RoutingPolicy Based Routing (PBR) implementation in Cisco Catalyst 3750 switches has some limitations. If these restrictions are not followed, it can cause high CPU utilization.l You can enable PBR on a routed port or an SVI.l The switch does not support route-map deny statements for PBR.l Multicast traffic is not policy-routed. PBR applies only to unicast traffic.l Do not match ACLs that permit packets destined for a local address. PBR forwards these packets, which can cause ping or Telnet failure or route protocol flapping.l Do not match ACLs with deny ACEs. Packets that match a deny ACE are sent to the CPU, which can cause high CPU utilization.l In order to use PBR, you must first enable the routing template with the sdm prefer routing global configuration command. PBR is not supported with the VLAN or default template.
但随着大資料和分布式計算的應用，業務層面給網絡帶來的挑戰還遠遠不止這些。分布式計算類型的服務會存在大量的資料互動和複制，其特點是：高帶寬、大突發。它們在一定時間裡被我們親切地稱之為“内網殺手”。以Hadoop為例，從圖9-4可以看出，使用者在推送資料塊時資料節點之間的複制操作需要頻繁地消耗接入層交換機的上行帶寬，在初期上行收斂比還是12:1時（8口千兆上行，48口千兆下行），這部分流量必然會給相同機架的其他服務造成影響。
圖9-4 分布式計算大量消耗内網上行寬帶
針對此類業務的大資料互動的特性，在該案例中，做了以下兩個方面的調整。
◎ 優化資料節點，減少跨機櫃的互動。◎ 擴容接入層交換機，達到核心上行帶寬。
剛才我們談到收斂比時，應該有讀者看出初期階段核心和接入層之間存在的問題。8口千兆上行收斂比應該是6:1，為什麼這裡寫的是12:1呢？就如之前所介紹的一樣，核心和接入層之間運作的生成樹協定（STP），天生就會浪費50%的帶寬資源。STP會帶來兩個問題，一是資源浪費，二是備援切換能力，如果當上行接口聚合組其中一個接口出現異常關閉時，那麼接入層交換機的上行收斂比就又會減少1/4，并且這時STP并不會重新進行拓撲計算。
我們在處理Hadoop大流量的問題時，意識到STP這種古老的協定已經不适用于目前資料中心網絡了。提升收斂比的首要任務就是将STP備份線路充分利用起來。
業界替代STP的組網方式有很多，如Layer 3組網、網絡虛拟化、大二層。但這種在原有網絡基礎上改造的方式，不同于建立，更多的是需要考慮原有裝置利用、割接視窗時長等客觀因素。
是以在考慮上述因素後，改造方案選擇使用網絡虛拟化的方式替代STP組網方式（見圖9-5）。這樣可以在不更換接入層交換機的情況下，将原有收斂比提升一倍，并且很好地規避了前面提到的STP存在帶寬浪費、備援切換的問題。
圖9-5 網絡虛拟化
網絡虛拟化技術有兩個技術類别分支，分别是整機虛拟化和接口虛拟化。
整機虛拟化以Cisco VSS(Virtual Switching System) 和H3C IRF(Intelligent Resilient Framework)為代表，這類整機控制層面虛拟化已經是比較成熟的技術，已有很多商用案例。控制層面虛拟化提供了兩種工作模式，分别是一虛多和多虛一，分别應對不同的場景。
多虛一的主要作用是簡化網絡結構，提升網絡橫向擴充能力。通常是兩台裝置進行多虛一，但目前也有部分廠商實作了N:1的整機虛拟化，如H3C IRFv2（Intelligent Resilient Framework 2，第二代智能彈性架構）技術目前最多可4台核心裝置N:1虛拟化，H3C等較為主流的交換機産品線均支援IRFv2技術S1250、S9500E、S7500E、S5800等。一虛多技術多數用在虛拟化多租戶環境下，整體提升硬體資源的使用率。此類技術多使用在金融和虛拟化公有雲環境中。
接口虛拟化以Cisco VPC(Virtual Port Channel)和Arista MLAG（Multi-Chassis Link Aggregation）為代表，接口虛拟化和整機虛拟化在網絡結構上沒有太大的變化，都進行了跨裝置的接口聚合操作。但由于接口虛拟化隻關注跨裝置的接口聚合，是以在核心層面依然需要使用HSRP/VRRP技術提供備援支援。
在實際部署中對接口虛拟化各家廠商限制的條條框框較多，相比IRFv2整機虛拟化技術部署起來比較複雜，反觀整機虛拟化提供最多4台核心裝置的虛拟化能力，接口密度為乘的關系，去除了複雜的VRRP/HSRP配置和大量的位址配置，邏輯上隻管理和監控一台裝置，提供了良好的管理便利性（見圖9-6）。
圖9-6 整機虛拟化和接口虛拟化部署圖
基于以上的分析，在應對初期Hadoop高帶寬需求時，我們的解決方法是通過替換核心交換機裝置，提升一倍的帶寬收斂比，短暫性滿足帶寬需求，并且盡可能地将Hadoop業務放置在單獨的機櫃，以防止影響到其他業務。
初期網絡運維總結在沒有明确需求做資料支撐的前提下，組網方案隻停留在了簡單的裝置堆砌階段。應用存在不确定增長或大規模爆發情況時，對基礎網絡造成的沖擊非常大。網絡運維工程師這時主要承擔了救火隊的角色。
但這一階段也有不少收獲：第一，逐漸摸清了公司業務流量模型和特點，為後續的規劃積累了資料；第二，通過不斷的網絡平台擴容、改建，總結出以下兩條真理。◎ 改造的難度遠大于建立。◎ 對于增長不确定的網絡規劃，核心交換機的規格和投入适當超前。
中期在該案例中，總裝置數量的增長，推動了建設新資料中心的需求，讓網絡工程師有機會在“白紙”上重新建構基礎網絡，規避初期遇到的問題，重新梳理需求。網絡建設和資料中心規模有着密切的關系，如原計劃建設一個約500台伺服器規模的資料中心，網絡的設計容量為支援1000台裝置，但如果業務增長超過資料中心規劃，這樣就導緻又要去規劃新的資料中心。
這種情況所帶來的問題有以下幾點。◎ 大量小規模資料中心管理複雜。◎ 資料中心網絡裝置投入成本大。◎ 小規模資料中心間互聯是難題。
當發現這個現象後，為了避免後期出現上述幾個問題，采取了“脫殼前進”的資料中心擴容方式。當存在更大規模的資料中心時，将規模小的進行撤離融合到大規模的資料中心去，整體的網絡結構、建設成本、運維成本均得到了提升。但這裡痛點不在網絡層面，而是在業務層面。在這個階段大量業務還不支援雙資料中心備援切換，需要有損地進行業務遷移。是以需要推動業務架構支援雙資料中心部署，為後期雙資料中心備援打好基礎。
中期階段的網絡規劃在業務分區、邊界安全、線路層等方面都進行了相應的優化。同時業務部門也對網絡安全提出了更明确的需求，如業務線間安全隔離、網際網路通路安全隔離等。下面讓我們來看看中期階段到底為什麼這樣規劃？還遇到了什麼挑戰？
組網方案為将來建設支撐萬台以上裝置的大型網絡積累經驗，在中期規劃了兩套不同的組網方案，來對比各自的優缺點。但基礎的業務分區、安全需求、LVS區域的實作是一緻的。 中期組網結構如圖9-7所示。
圖9-7 中期組網結構圖
我們在網絡中明确了區域的概念，對公司的不同業務劃分了區域。各區域使用不同的實體層裝置進行實體和邏輯的雙重隔離，做了IP位址段的分區規劃，不同IP位址對應不同業務。這樣做的好處是邏輯結構清晰，并且便于後續運維及權限劃分。可以分為以下三大類：
◎ 網際網路區域◎ 内網區域◎ DCI（Data Center Interconnection）區域
網際網路區域網際網路區域示意圖如圖9-8所示。主要功能是接入多條營運商線路，各線路入網對應不同的負載均衡叢集（LVS），出網對應SNAT叢集。入網、出網實作統一化、服務化。
圖9-8 網際網路區域示意圖
如前文所述，該階段，業務對網絡的可用性、安全性都提出了更高的要求，是以營運商線路接入都是采用雙上聯ECMP方式進行的，并且在每條營運商線路的入向接口提供網際網路接口白名單的規則。
LVS/SNAT叢集和網絡一起規劃了OSFP的方式關聯部署。LVS也更新到了FULLNAT模式，相比DR模式對網絡的要求降低很多。從網絡角度來看，FULLNAT的資料流是一個正常的從哪裡來從哪裡回的資料包，在網絡層可以不用對這些封包做特殊的處理（政策路由）。這也極大地簡化了網絡的複雜程度，LVS的部署和詳細内容可以參考LVS章節。
在某案例中，此階段，網際網路線路上更多的是關注品質、故障、成本三個因素，是以我們設計多線路的LVS叢集方式，并建議應用盡量運作在網際網路單線資源上。這裡分享一些線路選擇和帶寬預留的原則。
1．網際網路線路使用指引（1）可排程業務的電信、聯通、移動使用者使用單線資源覆寫。（2）可排程業務非三大營運商的使用者使用多線BGP資源覆寫。（3）SNAT預設隻提供BGP出網線路。 2．帶寬預留原則（1）實體接口：實體接口使用總和的50%（單10Gbps接口帶寬使用範圍為5Gbps，雙10Gbps負載接口帶寬使用範圍為10Gbps）。（2）邏輯帶寬：帶寬Buffer數量為最近一周帶寬峰值的50%。
内網區域在某案例中，初期階段在收斂比上吃了虧，在中期階段專門規避了這個問題，收斂比初期設計為1:2，但随着采購量的增加和裝置成本的下降，逐漸地擴容到1:1。根據監控資料看非分布式計算業務機櫃在2:1的收斂比下也可以良好地工作，這和業務自身調優也有比較大的關系。但分布式計算業務如Hadoop機櫃則建議1:1收斂。
在實際部署中内網區域使用了兩套當時比較主流的組網方案，這主要集中在核心接入層和伺服器接入層之間。其中一種是Layer 3互聯組網方案；另一種則是以Cisco Nexus系列為代表的Pod Design互聯組網方案。這兩套組網方案各有優劣勢。
1．Layer 3互聯組網Layer 3互聯組網，顧名思義，是核心層和接入層運作OSPF或者BGP路由協定進行互聯。業内一直有一種說法是，Layer 3互聯組網是一種臨時資料中心組網的過渡方案。這種說法其實沒有錯。我們可以設想一下，在核心裝置不支援網絡虛拟化或現在主推的大二層解決方案的年代之前（2009年Cisco Catalyst 6500平台開始支援網絡虛拟化技術VSS），除了這種Layer 3互聯組網方案，核心裝置在當時是沒有技術支援橫向擴充的。
換個角度來說，就是一個資料中心可承載的伺服器數量其實局限于核心裝置的接口密度。Layer 3的解決方案在滿足扁平化的基礎上将資料中心可承載的伺服器數量提升了8～16倍（主要參考ECMP的數量決定）。當然，Layer 3互聯組網方式也完全規避了STP産生資源浪費和備援切換時間長的問題。
（1）Layer 3互聯組網的挑戰Layer 3互聯組網方式也對運維管理、成本提升、二層應用的部署帶來了一定程度的挑戰。◎ 運維管理首先，運維管理的挑戰是IP位址管理、基礎服務應用、接入交換機上限三個方面。可想而知，IP位址管理将變得很複雜。以4個核心為例，每台接入交換機上都會配置4個P2P（Point-To-Point）互聯IP位址和一個伺服器網段。如果伺服器使用共享ILO（Integrated Lights-Out）管理方式，那麼還将有伺服器管理卡網段。在正常情況下每個接入交換機上将産生5～6個小網段。假設我們有200台接入交換機，在沒有良好的CMDB系統協助管理記錄的話，運維這種類型的網絡難度可想而知。
其次，是基礎服務應用。例如伺服器上架和裝機，因為每台接入交換機自治的原因，是以就需要伺服器上架人員和裝機人員對此類網絡有充分的了解。但在實際環境中往往是負責上述工作的人員和建構網絡人員分屬兩個不同的組或者部門，所屬不同的專業次元，要求他們對網絡結構、IP位址與網絡工程師有一樣的認識顯然不太合适。最終就變成一些伺服器上架和變更需要主機人員和網絡人員配合，費時、費力，效率極低。
最後，是接入交換機上線。就如剛才所提到的IP位址管理的複雜性，在初期沒有Netconf和Poap（Netconf和Poap實作網絡裝置加電後自動下發配置的功能）技術支援的情況下，一台接入交換機的初始化配置涉及大量的人工修改，配置的準确性和上線效率都潛在隐患。
◎ 接入交換機成本的提升在傳輸二層環境下，我們進行接入交換機選型主要關注接口密度、接口Buffer、背闆帶寬、轉發能力、MAC位址容量這幾個性能名額即可。但對于Layer 3互聯組網，我們在關注上述名額之外，還需要關注裝置是否支援三層功能、路由表的容量等資訊。這樣勢必會帶來接入交換機的成本提升。這部分裝置在資料中心基數較大時，産生的成本量級還是比較大的。
◎ 二層應用部署典型的二層應用就是VRRP（熱備份備援路由協定），如需要提供虛位址方式進行叢集備援的應用，均依賴此協定（如Linux Keepalived）。這樣導緻依賴此協定的叢集服務需要部署在相同的交換機上或者相同的機櫃上。顯然這樣的部署方案在備援上并不是那麼完美。針對這種業務，在Layer 3互聯組網方案中，通常的處理方式是将前後排背靠背兩個機櫃做成多虛一的虛拟機交換機，來滿足不同的接入交換機和不同的機櫃達到備援的效果。這裡還涉及一個現實的問題是，通常研發或應用運維送出伺服器使用申請時是不會标注應用類型的。這樣導緻負責主機的人員在傳遞後還要針對使用這種類型的服務進行單獨的機櫃調整操作，涉及的工作量可想而知。
（2）Layer 3互聯組網的優勢不可否認，在特定的階段Layer 3互聯組網方案提供了良好的擴充性、備援性、安全性，這也是此類組網方案的優勢所在。擴充性主要展現在可以針對核心層面進行橫向擴容；備援性展現在支援多條備援上行線路，并且有着良好的切換能力；安全性展現在衆所周知的安全性最差的資料鍊路層上，減少了資料鍊路層廣播風暴的可能性，降低了受廣播風暴的影響，但是對特定應用存在一定的部署難題。Layer 3互聯組網方式在核心裝置與接入層裝置品牌選擇上提供了差異性支援。接觸網絡較早的讀者一定清楚不同廠商的裝置工作在STP環境下會産生莫名其妙的問題。這種組網方式可以規避此類問題，讓不同品牌的核心裝置和接入層裝置工作在網絡中。
2．Pod Design互聯組網Pod Design互聯組網方式，是Cisco Nexus交換平台上推出的組網方案，在實體結構上類似于傳統的核心、彙聚、接入三層。實際部署的差別主要在彙聚和接入兩層。傳統的彙聚和接入采用Layer 2或Layer 3進行互聯。 Pod Design以Pod概念替代傳統區域的概念，在結構上差異并不大，但功能上略有差别，傳統區域定義除了劃分區域外，區域彙聚可以提供安全、負載均衡、流量控制等功能，這主要依賴彙聚交換機的裝置産品形态。但目前資料中心的網絡需求已經從多功能向高帶寬、低延遲方向轉變，這些較為複雜的功能已經不适合目前資料中心的網絡需求了。Pod Design互聯組網方案在這兩層采用了俗稱遠端闆卡接入方式（Fex），類似于在彙聚層和接入層進行縱向虛拟化，Pod内所有接口的操作、監控、變更在Pod兩台核心裝置上進行，簡化網絡結構、減少網絡中可管理裝置的台數。
（1）Pod Design互聯組網的挑戰Pod Design的設計思想是将網絡按子產品進行歸類，這種思想和我們設計網絡時提到的IP關聯業務線不謀而合，甚至是天生就實作的。但此類組網方式也同樣面臨着Layer 3組網所遇到的三個挑戰。◎ 運維管理運維管理所帶來的挑戰是布線系統 、Pod容量、管理風險三個方面。傳統的資料中心核心到接入層布線有兩種方式，即EoR（該方式指伺服器機櫃中所有的伺服器接口，都通過跳線連接配接到機櫃上的配線架，再由配線架上的銅纜延伸到網絡機櫃（位于一組機櫃尾部）中的接入交換機）和ToR（該方式将接入交換機放置在每個伺服器機櫃頂部，機櫃内伺服器直接通過短跳線連接配接到頂部的交換機，再經由光纖從交換機的上行鍊路接口連接配接到核心交換機）這兩種方式的優劣勢網上分析文章很多，這裡就不做過多的分析了。
目前主流的是ToR布線方式。但Pod互聯組網模式的布線方式還和ToR方式略有不同，主要是在彙聚交換機提供到接入交換機的接口方式上有所差別。傳統的ToR方式彙聚和接入裝置分别提供4個10Gbps SFP+線纜接口互聯接口，但Pod Design出于機架空間和端口密度的考慮，多數是提供如圖9-9所示的40Gbps MPO線纜類型的接口。此時我們需要通過MPO-to-41C 針對彙聚和接入裝置線纜進行跳接。
圖9-9 40Gbps MPO線纜類型的接口
這帶來了一個問題，就是線纜長度的問題。在設計此類型組網方式時，為了避免單一40Gbps接口故障影響過多的接入層上行帶寬的容量，在實際環境中40Gbps接口是分别接入4台不同的接入層裝置的，這樣當彙聚單裝置單40Gbps接口故障時，隻是4台接入交換機上行帶寬從40Gbps減少到30Gbps而已，這個帶寬減少的比例還是可以接受的。
但根據機櫃位置的不同，線纜長度也不同，在實際采購過程中發現MPO-to-4lc線纜都不提供定做LC側超過10m以上規格的線纜。在部署和線纜備件的處理上都比較麻煩，是以采取的是彙聚交換機機架頂部配線架的方式，如圖9-10所示。
圖9-10 彙聚交換機機架頂部配線架
兩個配線架以背靠背48端口LC方式對接，在這樣的布線方式下，彙聚交換機使用短距MPO-TO-4LC線纜和配線架1對接，接入層裝置根據機櫃實際位置選擇不同長度的線纜與配線架2互聯完成對接。
這樣的布線方式較為簡單地解決了線纜長度和備件所帶來的問題，同時也增加了管理成本，并且配線架背靠背對接存在後期維修故障的難度。這樣的配線架模式在後期如果其中一對接口出現問題，那麼基本上是不可維修的，因為在配線架上直接進行光纖熔接操作非常容易誤碰到其他線纜引起不必要的損失。針對這個問題，布線廠商在後期提供了預端接布線方案，大家可以自行百度檢視技術細節，主要是以子產品化思路處理了這部分對接，出現異常可以通過更換預端接子產品進行簡單處理。
Pod内伺服器容量設計依賴于廠商限定的條件，以Cisco Nexus為例，在主流千兆伺服器接入環境下，根據彙聚交換機工作模式的不同，單Pod容量可分為1152台和2304台伺服器兩種規格。受限于這樣的條件，我們面臨Pod内部署什麼樣的業務，以及業務超過Pod容量後Pod間帶寬如何計算配比等問題。
此類組網方式減少了網絡可管理的裝置台數，全網裝置管理集中在幾台核心裝置上。這樣帶來的管理是一些較為輕量級的操作，如接入層接口配置變更等都需要登入核心彙聚裝置進行。但是為後期的權限劃分增加了難度。
◎ 成本問題Pod Design在成本問題上可以分為兩塊内容，分别是成本提升和成本優化。成本提升主要是在這類組網方案中多了一層彙聚交換機的成本投入。成本優化則展現在業務流量模型清晰化上，可以減少Pod間收斂比、裝置闆卡及子產品的投入，但這個需要視實際業務情況而定。
◎ 二層應用部署二層應用部署其實面臨着跟Layer 3互聯組網一樣的問題，隻是在Layer 3二層環境中以接入交換機為機關，Pod Design以彙聚交換機為機關。
（2）Pod Design互聯組網的優勢Pod Design采用類似多虛一的虛拟化技術，剝離傳統接入交換機的控制層面。這樣的優勢是以Pod為機關隻管理兩台彙聚交換機，劣勢就是接入交換機隻能工作在Pod Design工作模式下，因為它自身不具備控制層面，無法單獨使用，如Cisco Nexus 2000系列。
安全的挑戰安全是任何一家網際網路公司都不能忽視的問題，但安全需求在執行落地時都會給業務發展和基礎架構帶來一定的挑戰，在此階段安全對網絡提出了以下需求。
1．網際網路端口白名單随着LVS平台對運維工程師的管理權限下放，以及一些LVS無法支援的業務直接暴露在公網上，需要在網際網路入口做防護，其規則制定和通路控制是保障業務安全的第一要素。
網絡和安全人員一起制定了預設的白名單端口範圍，以及特殊端口的申請及審批流程。在某案例中，這個功能在讨論初期存在兩種方案，其中一種是在各LVS叢集生效通路控制；另一種是在網絡裝置如防火牆、交換機生效通路控制。在網絡裝置層面生效的優勢是可以在最初的入口完成通路控制，這也是通路規則就近生效的原則。另外，對于部分直接暴露在網際網路上的業務，在網絡裝置層面統一入口生效也有助于對這類業務的保護。
網際網路端口白名單可以選擇在出口網際網路接入層交換機層面生效，也可以通過上層增加硬體防火牆生效。從安全角度出發，使用硬體防火牆是最好的選擇，因為硬體防火牆自身是可以實作如Syn Flood、Ack Flood等攻擊的防禦的，并且基于會話的硬體防火牆可以非常輕松地實作業務單向通路的需求。反觀交換機傳輸ACL隔離，僅可以實作單純的通路控制，在單向通路和防禦Syn Flood、Ack Flood攻擊方面則顯得無可奈何。
但最終我們還是選擇在交換機層面實施網際網路端口白名單，其中一個主要原因是裝置性能，因為交換機不記錄會話，是以會話的多少是不會直接影響交換機的轉發性能的。反觀硬體防火牆裝置，防火牆裝置在選型時考慮的兩個重要名額就是并發數和每秒建立連接配接數。當存在高并發業務時，防火牆裝置對此類業務的安全過濾顯得有些力不從心。另一個原因是成本，在出口并發數為200萬，支援200萬并發的場景下，防火牆産品和交換機的價格可是天壤之别。
網際網路端口白名單有兩種實作模式，其中一種是黑名單即明确拒絕特定端口；另一種是白名單即明确允許特定端口。第二種模式明顯限制得更為嚴格，并且具備完善的審批和記錄機制，如果遇到安全問題，可以快速地進行事件追溯（也可以通過全流量分析完成）。但這也在一定程度上帶來了人力成本的上升。可以根據實際情況酌情選擇。
2．内網隔離内網隔離在金融和軍政網絡中存在比較多，坦白地講，金融和軍政内網隔離相對較容易實作，因為此類網絡對伺服器數量和未來流量的預期相對有據可依，是以對這類網絡可以選擇防火牆隔離或網閘等手段來完成内網隔離。
但網際網路公司業務存在很多不确定性和高突發流量的情況，在安全和性能之間很難找到一個平衡點，是以在網際網路公司内網隔離就變得難以實作。
需要實施内網隔離一般有以下場景。（1）第三方評審如PCI-DSS，全稱為Payment Card Industry（PCI）Data Security Standard，第三方支付行業(支付卡行業PCI-DSS)資料安全标準。（2）非授信區域部署第三方開源應用區域，如Discuz、Phpwind等開源程式。（3）業務線間不同業務線均存在不同類型的敏感資料，并互相不信任其對方的安全性，要求不同業務線間進行内網隔離。
針對不同的場景，應當采用不同的隔離方案。首先，安全合規應用屬于第三方評審要求，此類内網隔離建議采用硬體防火牆裝置，在這種安全至上的業務面前，性能反而不是第一考慮因素了；其次，針對後兩種場景的這類安全需求屬于公司内部需求，且對網絡性能要求很高，這類需求建議采取交換機ACL方式進行安全隔離。
但采取交換機ACL方式實作内網隔離困難和問題依然很多，這主要展現在功能、容量、管理與變更三個方面。① 功能比如ACL實作單向通路困難。在網際網路端口白名單中問題不大，因為網際網路涉及的IP較少，類型也比較單一。但應用在内網隔離中這部分缺陷就顯現出來，内網應用協定繁多，如FTP、DNS這兩類應用是不能通過傳統ACL實作單向通路的。是以一個折衷的做法是将此類無法實作單向通路的應用和必要的服務（如YUM/NTP等）進行梳理全部放行，同時将此類服務定義為基礎設施白名單，該名單中的服務預設在所有生效的ACL區域放行，進入此名單的服務需要通過完善的安全稽核機制和流程，保障其安全性。
② 容量 這方面問題主要是因為後期業務之間調用繁多，超過交換機自身裝置所能承載ACL條目的規格。交換機ACL規格和防火牆ACL規格不在一個數量級上，防火牆ACL規格在幾萬甚至幾十萬級别，但交換機ACL規格往往隻在千級别。
③ 管理與變更設想一下，上千條通路規則分别應用在不同的裝置上，管理與變更這麼龐大的通路規則不是件容易的事情。
中期網絡運維總結在這個階段我們完成了資料中心網絡标準化的雛形規劃和建設，通過與業務磨合，清晰地了解了業務對網絡的需求。随着業務從不規律到逐漸穩定上升，業務部門可以提供一定的可參考資料，這對後期建設标準化資料中心網絡提供了良好的資料積累。業務部分對網絡可提供的服務也有了一定的了解，如資料中心容量、線路資源、安全特性等。在這個階段資料中心網絡模型滿足目前業務的需求。
總結前兩個階段，是某真實案例中，從初期到目前現狀的核心網絡的進化史和血淚史，期間所使用的組網技術和方案不是業界先進的技術和解決方案，都是一些傳統的技術群組網解決方案，是以在介紹中并沒有過多的技術描述，涉及的技術大家可以自行搜尋，有大量的技術文檔可供參考。希望通過我們的介紹，讓大家對處理不同業務需求和初期網絡建設少走一些彎路。
近兩年随着雲計算的發力，公司在初期階段和對網絡自主性要求不高時，雲主機的解決方案是一個非常不錯的選擇。但随着Docker和OpenStack這些虛拟化服務的大量應用，後期需要考慮的是如何在網絡架構中更好地支援虛拟化業務。傳統的網絡架構提供的擴充性和穩定性已經遠遠不能滿足雲計算中心對網絡的需求，除了擴充性和穩定性這些基本需求外，對網絡靈活性和網絡快速适配能力都有較高的要求。
業界應對主流雲計算網絡架構的技術有很多，如SPB、TRILL、FabricPath、VXLAN、OTV、SDN等，希望這些技術在我們正式應用後繼續分享給大家。當然，這個階段的網絡還存在一些問題，如監控的精準度、網絡管理自動化等。這些問題和業務無關，是網絡自身的運維管理問題，我們希望後續通過平台化以及對上述新技術的研究解決這類問題。