思科ACI架構從2013年底被提出到現在，走過了2個年頭。選擇它的客戶已經近2000家，其中選擇其Nexus 9000系列的客戶有1700家，選擇了ACI核心應用策略基礎中心APIC的用戶，根據思科最新透露的數據已經有近500家。而且ACI的每次技術演進總能牽動產業的神經，即便是這樣，ACI的潛在價值還不為大多數用戶所知曉，尤其是中國用戶。近期IT168發表了關于思科ACI的系列文章《ACI是SDN技術嗎?》，這篇文章解讀了思科ACI對ONF白皮書《軟件定義網絡：網絡新常態》中所提及的SDN諸多挑戰的理解，以及詳細剖析了思科各部分組件如ACI Fabric、APIC(應用策略控制器)，GBP(組策略模型)等組件的實現方法和功能。
但ACI真如文章所闡述的那樣，完全可以滿足SDN目前所有的需求?以及ACI如何做到后發先至?與其他SDN架構相比，ACI自身的優勢如何體現?ACI構建之初的邏輯是怎樣的?等等話題，IT168獨家對話了思科大中華區首席解決方案架構師馬元騏和思科大中華區數據中心交換機產品線產品總監李少杰。
打破網絡架構底層的束縛
在網絡基礎協議，以及架構形成的過程中，有許多有趣的事情。比如早期的以太網等標準，在其誕生之初并沒有被業界廣泛認可，馬元騏談到，“當初最不被看好的，反而衍伸為最后被廣泛使用的標準，從而造成了網絡技術發展中產生了許多問題的來源。”這隱含的意思，就是在傳統網絡架構中，基于物理設備、固定IP、VLAN域等已經駕輕就熟的功能和手段，當面臨云、虛擬化的時候，反而使得網絡成為了制約其發展的因素。
在ONF的白皮書中也做了這樣的闡述，如豐富的網絡協議和功能顯著提高了網絡復雜性，VLAN的隔離策略，降低了業務變更的靈活性;而當虛擬機發生遷移的時候，在當前網絡需要跨數百或數千網絡設備手動配置安全和服務質量(QoS)策略，工程繁雜，而且手工配置容易出錯;當新業務需求來時，要對網絡架構進行擴展則意味著對端點、服務和帶寬等等大量的規劃和重新設計。
滿足云環境的基礎架構要更加靈活、彈性、規模擴展上更加簡單。馬元騏認為“SDN誕生之初，公認的是在廣域網中去調配路由的分配，而經過這些年的發展，SDN依然沒有形成在數據中心中比較理想的實現模型。”馬元騏在判斷目前SDN還不夠完善的同時，也隱約解釋了思科ACI后發的原因。因為要將已經廣泛使用的以太網、TCP/IP等技術標準打破，需要更多的思考。
所以思科希望將基礎架構，尤其是網絡底層的限制打破，特別是還要保證以太網、TCP/IP等邏輯還在。只是當網絡對業務商業化實現造成困擾時間，將它們打破。他舉例道，“今天服務器、虛擬機到底配置了怎樣的IP，應該處于哪個VLAN，這些對用戶都不重要。重要的是知道服務器A到服務器B之間應不應該產生關聯，下一跳是連到服務器C，或者其他。來完成用戶的業務流程，中間是需要安全、策略來滿足它的條件，才是業務實現最重要的。”
ACI在構建之初的邏輯就是，從應用部署的邏輯性、關聯性來談底層架構如何部署，ACI以這個為著眼點出來作為主要的設計理念。
打破策略變更的緊密耦合
傳統的網絡架構到底有什么束縛?答案是，網絡協議和功能、轉發和策略的緊密耦合。因為這種耦合，策略中的變更可能會給轉發帶來不利影響。在現網環境中，最大的沖突產生在了系統應用開發部門和IT運維部門之間，而且這種沖突越來越無法調和。
系統開發人員會考慮功能模式是怎樣的?如何串接起來?有幾個功能組件與下一級的功能組件溝通，在系統應用開發人員中就是這樣，他們對底層實現的IP、位置、VLAN這些根本不關心。而當系統開發人員與IT運維團隊談的時候，往往遇到的反饋是VLAN只剩多少?IP網段只剩幾個位置?你的這些需求在現網無法實現。
所以，為了在數據中心基礎設施提供靈活性和簡單性，需要新的語言描述連接的抽象化意圖，以使最終用戶不需要豐富的網絡知識來描述連接的需求。此外，這個意圖應該從網絡轉發語義中解耦，以便最終用戶可以描述策略，讓策略中的變更不會影響轉發行為。
所以思科提出了GBP的邏輯模型，全稱是(Group-Based Policy)，基于組的策略。它分離了關于應用連接要求的信息與關于底層網絡基礎設施的詳細信息。需要特別指出的是，思科創造了GBP的模型，還把它推送到了OpenStack和OpenDaylight中的工作項目中，OpenDaylight稱基于組的策略是“應用為中心的策略模型”。而在思科ACI的邏輯實現上被稱為ANP(Application Network Policy)。
馬元騏提到，“ANP是思科在ACI中的策略實現，GBP是思科將模型推送到開源社區的說法。也是希望開源社區能夠基于APIC獲得價值。”
GBP或ANP的優勢在于：
1.更簡單的以應用為中心的表達策略：通過創建策略來映射應用程序語義，這個框架提供了更簡單的自我記錄機制來捕捉策略要求，而不需要非常了解網絡。
2.提高自動化：分組結構允許更高級別的自動化工具簡單地同時操作網絡端點組。
3.一致性：通過分組端點和應用策略到各組，該框架提供了一致的方法來處理策略變更。
4.可擴展策略模型：由于這種策略模型是抽象的，沒有綁定到特定網絡部署，它可以簡單地捕捉連接、安全、QoS等。
圖：可更加直觀的理解GBP模型的實現。
理解了GBP，但它畢竟是一個邏輯，是一個模型。落實到實體上就是ACI的控制器APIC。APIC是通過基于組策略表示的基于策略配置的控制節點，就是ACI架構中的控制器。它的主要功能是為思科ACI架構及設備提供策略控制和策略解析機制。有了APIC，用戶不再需要觸碰每個網絡元素以及手動確保所有策略而得到適當的配置。
馬元騏特別提到了APIC的幾個關鍵點。“其一APIC并不直接參與數據平面轉發，因此集群中所有思科APIC元件的斷連并不會影響轉發功能，這提高了整個系統的可靠性。即便是APIC遭到安全威脅，那么除了新的策略和分發失效之外，其他數據轉發不受影響。其二APIC的可視化，透過APIC對底層的了解，讓用戶很直觀的了解的設備的等級、網絡的等級，應用端到端等級，如掉包率增加了與否，延時增加與否等等。其三，APIC可滿足用戶當前的應用開發邏輯需求，隨后當用戶梳理清楚自身的應用模型后，用戶可以用自己定義的應用模型轉述底層的基礎架構該怎么支撐。其四，APIC在策略的下發方面可以通過圖形化的方式，也可以將APIC的邏輯釋放給用戶，由用戶通過開發腳本來進行策略的下發。其五，關于OpFlex，它是思科專為交換基于組的策略信息而開發的新策略協議，它是南向API。Opflex是從邏輯到物理呈現的協議，是屬于APIC與物理設備溝通的對話機制，功能是將APIC的策略邏輯呈現在物理的Config上，物理設備也會反饋給APIC，邏輯功能是否能夠實現。OpFlex也可用于其他的控制器。”
此外APIC還支持多租戶和基于角色的訪問控制，具體可參考《ACI是SDN技術嗎?》一文。
對于ACI的基礎Fabric，馬元騏也表達了對數據中心扁平化的見解。目前思科ACI有成功的在網案例，Spine-Leaf結構中Leaf節點140臺的規模。
他談到，“在物理結構上，目前Spine-Leaf的結構跟傳統的三層結構差異性并不大，其實只是視覺邏輯上的感受不一樣，為什么OSI二層結構中需要那么多標準和協議?為什么談到高可用性就必須要主備，都以二為單位呢?其實組網協議和標準完全可以將這些拋開。那么二層的問題就會迎刃而解。Spine-Leaf是有固定的布線模型的要求，Spine與Spine之間不能有橫向連接，Leaf與Leaf之間中間不能有橫向連接，每個Leaf要能夠連接到每個Spine，這是數據中心網絡扁平化的絕對要求。這個是解決東西向流量增長的方法。這個模型是有數學模型可以驗證每個硬件盒子上聯和下聯端口各有多少，可以算出拓撲大概是怎樣的。”
通過以上的介紹，用戶就完全可以從網絡功能的虛擬資源實現層面、控制器層面和基礎架構連接層面完全理解思科在GBP、APIC和Fabric方面構建ACI的想法了。
打破業界對思科的固有認知?
不管是封閉，還是ACI是硬件架構，是思科在面對用戶，面對市場，都會被每每質疑的論調。雖然思科在公開或非公開的很多場合都會做出解釋，但往往會引來更多的解讀和批判。
在《ACI是SDN技術嗎?》一文中，對思科ACI的開放API、合作伙伴生態系統做了說明，引用到這里。后面還有思科二位專家的QA。
思科ACI支持可擴展的合作伙伴生態系統，其中包括4-7層網絡服務;虛擬機管理程序;以及管理、監測和云編排平臺。所有合作伙伴都使用思科ACI的開放API和開發工具包、設備封裝和插件，以及OpFlex。
開放API：思科ACI支持通過REST接口的API接入、GUI和CLI以及一些軟件開發工具包(包括Python和Ruby)。思科APIC支持跨HTTP/HTTPS的REST API，并綁定XML和JSON編碼。這個API同時提供類級別和樹級數據訪問。REST是分布式系統軟件架構，多年來，它一直是領先的Web服務設計模型，并已經逐漸取代簡單對象訪問(SOAP)和Web服務描述語言(WSDL)等其他設計模型。
合作伙伴生態系統和OpFlex：南向API—OpFlex是開放的可擴展策略協議，用于在策略控制器(例如思科APIC)和任何設備(包括管理程序交換機、物理交換機和4-7層網絡設備)之間的XML或JSON傳輸抽象策略。思科的合作伙伴包括英特爾、微軟、Red Hat、Citrix、F5、Embrane和Canonical，現在他們正與IETF和開源社區合作來規范OpFlex，并提供參考部署。
思科將APIC裝進了盒子，部署在了其UCS服務器上。每當思科要將其某項強大的功能和軟件綁定在硬件產品上時，業界總會吹毛求疵一些。李少杰指出了幾點，“其一，APIC部署在UCS服務器上，能夠給APIC更好的安全健壯性;其二，思科有UCS服務器產品，如果其他網絡供應商有自己的服務器產品，相信也會是這種解決方案;其三，APIC從誕生之初就沒有考慮過APIC單獨提供;其四，將APIC單獨以軟件形式提供給用戶，完全沒有技術上的問題。如果用戶接受ACI概念，還會在乎一臺UCS服務器嗎?”
在與思科兩位專家的interview之后，思科又對“將APIC放在UCS中，以硬件形式提供”做了進一步的郵件說明，回復如下：“在軟件領域的任何實現成果都極易受到安全威脅的影響。思科也確實考慮在軟件或者虛擬機環境中率先引入APIC控制器。然而，參與過alpha/beta測試的客戶們給出結論稱，思科需要提供更進一步的保護手段、而非單純對底層操作系統及應用程序進行強化。APIC設備當中通過TPM建立起基于硬件的安全密鑰機制，旨在進一步鞏固這套控制器平臺。借助這種方式，利用代碼插入方式攻擊該控制器的行為將在很大程度上得到避免。”
不過，APIC或其他廠商的控制器是通過軟件提供給用戶，還是落到標準化的服務器上，最終還是由市場和客戶決定吧，思科做出了硬件方式的選擇而已。
木秀于林，風必摧之;行高于人，眾必非之。
京公網安備 11010502049343號