思科ACI撼動了SDN

責任編輯：editor006 作者：litao984lt編譯 |來源：企業網D1Net 2015-11-17 14:36:23 本文摘自：機房360

思科高可擴展性的數據中心網絡架構為我們帶來了驚喜：一款完全開放的API。

軟件定義的網絡的承諾——即通過集中的、軟件驅動的控制，實現更簡單、更靈活的網絡操作其實已經實實在在的為我們服務了好幾年了。雖然像許多其他新的概念一樣，由于各種營銷團隊的大肆行銷和鼓吹使得其缺乏一個統一的定義，造成其遭受了各種的誤解和混亂。但在眾多不同的定義之外，我們也看到了一系列不同的方法，其中OpenFlow模型從一開始就一路領先。

而思科則采用了另一種方式來開發SDN。思科的以應用為中心的基礎架構 (ACI)是與OpenFlow的方法不一樣的一種SDN解決方案。正因為如此，其偏離了原來的OpenDaylight SDN項目的方向，而思科曾經是該項目的創始成員。當然，思科仍將繼續在OpenDaylight項目計劃中扮演相當重要的角色，但顯然他們會更偏向于自己的ACI技術。

ACI使用OpFlex與網絡設備進行通信，這是思科的操作控制協議，而非OpenFlow，其同時也是OpenDaylight的標準。關鍵的區別就在于，OpFlex是在網絡中，而非在控制器進行實際的網絡配置決策。控制器抽象更高級別的配置來代替。您可以將其想象成是由控制器告訴架構應該執行什么工作，而不是如何去做。該架構負責執行控制器的說明指示，并匯報成功或失敗。

思科表示這種方法規模化的程度要比OpenFlow更好，其依賴于控制器執行網絡配置的任務。還允許用戶通過一個更高級別的策略模型，并根據應用程序的需求來配置網絡，而無需擔心底層的配置細節。思科的OpFlex代理支持來自微軟、IBM、F5、思杰、紅帽和Canonical等等的承諾，并提出將OpFlex作為一項IETF標準，作為OpenDaylight的一部分。

雖然ACI的SDN內部可能與OpFlex而非OpenFlow進行兼容操作，但這肯定不是傳統的網絡。其也標志了思科希望走向更加開放的集成，A CI的建立是圍繞著一個完整的RESTful API，并在很大程度上依賴于Python編程語言，提供了一個開源SDK和工具，并已經公開發布在GitHub上了。

具體細節

ACI是專為大型數據中心的網絡設計的。其是基于思科Nexus交換機架構，在脊/葉布局(spine/leaf layout)具有10G、40G、100G的連通性。一款fabric架構可以小到幾個節點或大到五個脊，200葉和180000個端點——思科目前已配置在其實驗室中運行。 ACI是為了承載重荷工作。　　

　　思科實驗室的大規模ACI基礎設施拓撲結構概述，具有五脊和200多葉。

ACI也意味著重塑數據中心網絡的概念，引入一個模型，本質上是L2和L3獨立的，而不是使用租戶的概念來劃分流量固有的應用程序和服務到邏輯分組，同時在這些分組外使用VXLAN。這意味著您可以在多個不同的租戶使用相同的IP子網、VLAN、甚至MAC地址，而不發生任何沖突。在基礎設施中的每個租戶存在于其自己的邏輯島，而且每個租戶可以托管應用程序，劃分為不同的層，或邏輯端點組(EPG)。EPG之間的通信在ACI中通過分層策略控制。

EPG不是服務器或虛擬機，但本質上子網包含這些資源。這些子網可以被分配到VLAN配置在裸機服務器物理交換端口或hypervisors管理程序的虛擬交換機內。它們被設計為包含針對特定服務器實例類型的流量，例如Web服務器或數據庫服務器。

例如，我們可能有一個租戶，去可能是一個商業集團，也可能是一個金融集團。我們可以使用ACI定義一款應用程序并創建EPG，將包含不同層的應用程序堆棧——Web、應用程序和數據庫。我們為EPG定義了一個子網和VLAN，指定其將連接到的資源，如哪些VMware vSphere集群或域。ACI在需要的地方執行所有的工作來創建網絡對象，如在vSphere基礎設施的虛擬分布式交換機以及在Nexus fabric本身。一旦我們租戶的EPG創建完畢，虛擬機或裸機的資源就可以打開，并分配給這些網絡。

摘要：軟件定義的網絡的承諾——即通過集中的、軟件驅動的控制，實現更簡單、更靈活的網絡操作其實已經實實在在的為我們服務了好幾年了。雖然像許多其他新的概念一樣，由于各種營銷團隊的大肆行銷和鼓吹使得其缺乏一個統一的定義，造成其遭受了各種的誤解和混亂。但在眾多不同的定義之外，我們也看到了一系列不同的方法，其中OpenFlow模型從一開始就一路領先。

然而，我們也需要明確地啟用這些EPG之間的通信，甚至在同一EPG內的主機之間的通信。在我們的一個三層應用程序的例子中，我們可能需要允許流量在一個特定的TCP端口從Web服務器EPG傳輸到應用程序的EPG，而數據庫的流量從應用程序EPG傳輸到數據庫的EPG。我們使用一個被稱為合同的概念來實現，一套在EPG之間簡單適用的規則，規定了怎樣的流量被允許在駐留在這些EPG上的主機之間傳輸。我們也可以讓這里的規定適用于外部設備，如防火墻和負載均衡器。除了思科自己的解決方案，ACI還可以與多家第三方供應商的L4至L7的設備集成，如來自F5、思杰和帕洛阿爾托網絡的設備。　　

一個包含了端點組的三層應用程序，以及適用于它們之間的流量合同的詳細視圖。

然后，我們可以清理和重復每一個租戶所需的每一款應用程序，我們在租戶定義中定義的一切都將包含在該租戶的保護傘之下。我們可以在其他租戶之間有重復的子網，重復的VLAN，甚至重復的MAC地址，而不會發生沖突。此外，我們可以讓EPG共享相同的子網或超級網絡，并仍舊在主機之間執行流量規則。因此，我們的三層應用程序可以有連續IP地址的網絡、應用程序和數據庫服務器，而我們的流量管理合同仍然適用。

租戶可能是企業集團，比如在我們的例子中，或客戶在主機托管或服務環境，或者只是最適合部署邏輯分組的集合。由于每個租戶都是在自己的筒倉內存在，在網絡層不會與其他租戶重疊。這就是說，有一些特殊領域可用于向多個租戶分發共同服務。這些服務可能是DNS、NTP和被所有租戶使用的目錄服務。

所有這些后端配置都是由ACI控制器處理，稱為應用策略基礎架構控制器(Application Policy Infrastructure Controllers，APICs)。這些都是在一個集群中運行的物理服務器，用于負載平衡和冗余的目的。一般來說，每個ACI fabric您將至少有三個APICs。

APICs在數據路徑之外，他們不是fabric功能所必需的。如果沒有可用的APICs，ACI fabric將繼續正常運行，但不能做任何更改。APICs為fabric提供配置，提供管理Web UI，及托管ACI圍繞建立的RESTful API。任何一個APICs都可以服務Web UI或API的請求，而其功能與其他控制器相呼應。ACI的配置和狀態數據存儲在控制器的SQLite并能夠跨控制器集群共享。　　

運行在思科實驗室的大型ACI基礎設施容量儀表板圖。請注意，運營商已經超過其規定的三類限制。

ACI fabric使得所有基于上面圖表的流量決策保持在fabric本身，無論是在本地端點的葉還是在fabric的剩余部分的脊。針對線上的每個數據包，fabric都會根據這些規則做出將其發送到何處的決策，并以線速執行。這便是ACI如何規避傳統的IP子網和VLAN的邊界，以及東西走向的流量可以通過合同的配置控制的原因了，即使是在同一個子網中的主機之間。

此外，這種設計消除了對于地址解析協議(ARP)和broadcast flooding的需要，所以流量被默認撤銷了——fabric已經知道每一個端點的位置。如果所需的是特定的應用程序，就會在橋域級別有允許ARP 和broadcast flooding的規定。

在一個較高的水平，這就是ACI了——其是建立和維持一個網絡fabric架構的方法，省去了傳統網絡的概念和方法，以非常大的規模提供了重要的軟件控制、自動化和線速的交換機。

構建fabric

實施ACI非常簡單，甚至是在大規模的建設的情況下。最繁瑣的部分是布線，但這是任何fabric結構典型的特點。在ACI環境下采用Nexus 9000系列交換機運行一款修改后的被稱為iNXOS的操作系統，具備ACI管理所要求的hooks腳本功能。　　

　　一個具備三個APICs，四個節點，兩個脊的ACI fabric架構的拓撲圖。

一旦您的Nexus脊和葉進行了正確的連接，通過葉連接到多個脊，然后脊又彼此連接，您就可以連接和啟動APIC服務器，這是建立在思科UCS 1U服務器硬件上的。如果當前的服務器是APIC集群的第一個成員，該APIC啟動到一個非常簡單的命令行(CLI)配置腳本，要求基本的IP子網和名稱信息。

第一個APIC控制器開始自動發現fabric的其余部分。這種情況發生得很快，甚至是在大規模的fabric上。一旦自動發現完成，ACI的Web UI顯示整個fabric的邏輯布局，以及可以配置的解決方案。與此同時，其他APIC控制器可以被啟動，并通過初始安裝腳本分配IP地址。然后，他們將自動加入APIC集群。

假設布線完成后，ACI fabric從開始到結束的整個過程可能只需要幾分鐘的時間。加上第三方元件如負載平衡器和防火墻，一款功能性fabric可通過Web UI或API來完成。

配置與管理

這是ACI所帶來的一些真正的驚喜。ACI的每一部分都可以通過RESTful API來控制。事實上，思科ACI客戶不使用CLI或Web UI管理工具，而是僅用API完全照本宣科即可。此外，思科還發布了一個完整的Python SDK，使腳本ACI直截了當。

這應該是非常清楚的：這不是一個扣在提供的管理工具上的API，或并排運行的解決方案。API是管理工具。CLI 與Web UI均需使用API以執行每一項任務。事實上，從CLI到ACI對于思科管理員都非常熟悉，都具備通常的IOS權限和配置模式，而其只是一個使用API 的Python腳本。

如果您企業參與了開源社區和現代開發社區，這似乎沒什么大不了的，但對思科而言，這是一個非常重要的一步。不僅是ACI成為了非常開放的架構，同時也意味著思科正在積極通過服務客戶及為其他感興趣的ACI維護代碼而做出貢獻。思科的GitHub的資源庫包含了大量非思科雇用的開發人員所提交的資源。思科正在積極支持各地ACI社區聚會，而該社區也已經收獲了思科的開放姿態所帶來的回報。這是思科邁出的一大步，并為ACI帶來了一個非常正面的立場。

使用SDK，一個Python腳本實現一個新租戶的基本功能可能只有幾行代碼。Python的方法是精心布置、易于理解的。此外，思科還參考APIC的Web UI內置了整個API和SDK，所以他們很容易被發現。思科公司也已經在ACI Web UI內置了非常便利的開發工具。例如，有一款對象瀏覽器，允許開發人員通過ACI基礎設施搜索和查看任何對象的所有要素，以便在腳本中使用。　　

此示例中的Python代碼將通過Python SDK在 ACI創建一個租戶。該代碼是通過思科維護的一個開放源碼的Python腳本傳遞的一個JSON對象編程生成的。

另一款工具，稱為ACI Inspector，本質上是一種對所有進入ACI API請求的現場調試。因此，您可以打開這款工具，看看被發送到API的到底是什么請求，并能夠很容易地在其他地方復制它們的代碼。此外，您可以剝離API并奪取通過的JSON。然后，使用一款稱為arya的工具，該工具在GitHub上的ACI工具包可找到，您可以將JSON數據合并到Python代碼的功能，使用Python SDK重新創建事件。因此，您可以在用戶界面中執行一個操作，并且在幾分鐘內就可以重新創建這個動作的功能腳本。

這是ACI的開放性，腳本易編寫的一個例子。其結果將是其將直截了當的被直接集成到自定義的ACI自動化和管理解決方案，如集中的管理工具和自助服務門戶網站。

故障排除與維護

ACI的政策驅動的性質似乎對某些網絡管理員有點過于放手。有了這么多的實際網絡配置抽象出來，并隱藏在fabric中，問題檢測和故障排除工具變得非常重要。　　

對象健康的概念是在整個ACI存在的。當檢測到問題時，一個對象的健康評分從100下降，得分越低說明問題越嚴重。這是分層的，因此，雖然在一個單一端點的一個被斷開的端口會顯示健康評分為0，包含該端口的fabric的健康評分可能顯示50，而包含下行端點上的應用程序則可能顯示得分為 80。這可以通過Web UI選擇受影響的應用程序來進行健康視覺跟蹤。這使得非常容易在一個巨大的fabric中查明問題。　　

　　ACI儀表盤顯示的ACI基礎設施健康統計一覽

ACI提供了一些工具，幫助問題的檢測，并在Web UI中的操作部分進行解決。從這里您可以通過應用程序和IP地址在fabric選擇兩個端點，ACI會告訴您他們是如何通過數據包遍歷識別葉和脊跨fabric連接的。

ACI甚至提供了一種回到過去的方法，看看哪里出現故障或問題可能已經開始。此操作在一個令人驚訝的低水平，其可能在fabric中選擇幾個對象，顯示過去的幾個小時數據包級別流量相關的對象的細節。ACI在fabric中為所有對象存儲，默認時間為240分鐘，但數據可以保留長達24小時。此外，如果需要較長時間的數據，您可以導出統計數據。這個工具在故障排除工作時被證明是非常有用的。　　

使用的應用程序的顯示健康來定位問題的根源。在這種情況下，是一個在node-101/eth1/3的下行鏈路。

還有交換機端口分析器(SPAN)和封裝的遠程SPAN(ERSPAN)功能，可用于兩個端點或fabric對象之間的所有流量，指示到fabric在別處的端口上。因此，在該端口的一個服務器監聽可以通過識別SPAN配置捕捉到跨所有流量。在一個大的fabric，這種方法使得跟蹤數據包級別的問題遠比傳統的方法簡單得多。

與大多數思科網絡產品一樣，ACI的配置可以濃縮成一個JSON或XML文件進行備份，并定期上傳到服務器。同樣，每個獨立的租戶配置可以獨立備份和重新導入。此方法可用于導出/導入全部租戶配置，可在其它地方修改，所以模板創建和導入文件一樣簡單。

就維修保養而言，固件升級到fabric硬件可以進行自動安排和管理，而不需要影響生產系統(假設所有端點有多個冗余路徑到fabric)。這種方法可以顯著地減少執行大的fabric所需的時間和精力。

外部整合

ACI管理虛擬化平臺的網絡功能，如Hyper-V，Xen和VMware，但不能管理虛擬機或提供服務器。為了實現了一個軟件驅動的數據中心，ACI可以與其他解決方案整合，提供更完整的業務流程解決方案。

利用RESTful API，ACI可與業務流程和管理解決方案，如VMware的vRealize Orchestrator和vRealize Automation進行整合。以便在每一個層面實現自動化服務部署。這包括配置虛擬服務器，存儲，網絡，以及資源的控制，資源成本，自動扣款，自動淘汰等等，管理虛擬機資源以及配置fabric。　　