思科高可擴展性的數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)為我們帶來了驚喜：一款完全開放的API。

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

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

ACI使用OpFlex與網(wǎng)絡(luò)設(shè)備進行通信，這是思科的操作控制協(xié)議，而非OpenFlow，其同時也是OpenDaylight的標準。關(guān)鍵的區(qū)別就在于，OpFlex是在網(wǎng)絡(luò)中，而非在控制器進行實際的網(wǎng)絡(luò)配置決策?？刂破鞒橄蟾呒墑e的配置來代替。您可以將其想象成是由控制器告訴架構(gòu)應(yīng)該執(zhí)行什么工作，而不是如何去做。該架構(gòu)負責執(zhí)行控制器的說明指示，并匯報成功或失敗。

思科表示這種方法規(guī)?；某潭纫萇penFlow更好，其依賴于控制器執(zhí)行網(wǎng)絡(luò)配置的任務(wù)。還允許用戶通過一個更高級別的策略模型，并根據(jù)應(yīng)用程序的需求來配置網(wǎng)絡(luò)，而無需擔心底層的配置細節(jié)。思科的OpFlex代理支持來自微軟、IBM、F5、思杰、紅帽和Canonical等等的承諾，并提出將OpFlex作為一項IETF標準，作為OpenDaylight的一部分。

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

具體細節(jié)

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

　　思科實驗室的大規(guī)模ACI基礎(chǔ)設(shè)施拓撲結(jié)構(gòu)概述，具有五脊和200多葉。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

構(gòu)建fabric

實施ACI非常簡單，甚至是在大規(guī)模的建設(shè)的情況下。最繁瑣的部分是布線，但這是任何fabric結(jié)構(gòu)典型的特點。在ACI環(huán)境下采用Nexus 9000系列交換機運行一款修改后的被稱為iNXOS的操作系統(tǒng)，具備ACI管理所要求的hooks腳本功能?！　?/p>

　　一個具備三個APICs，四個節(jié)點，兩個脊的ACI fabric架構(gòu)的拓撲圖。

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

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

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

配置與管理

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

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

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

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

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

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

這是ACI的開放性，腳本易編寫的一個例子。其結(jié)果將是其將直截了當?shù)谋恢苯蛹傻阶远x的ACI自動化和管理解決方案，如集中的管理工具和自助服務(wù)門戶網(wǎng)站。

故障排除與維護

ACI的政策驅(qū)動的性質(zhì)似乎對某些網(wǎng)絡(luò)管理員有點過于放手。有了這么多的實際網(wǎng)絡(luò)配置抽象出來，并隱藏在fabric中，問題檢測和故障排除工具變得非常重要?！　?/p>

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

　　ACI儀表盤顯示的ACI基礎(chǔ)設(shè)施健康統(tǒng)計一覽

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

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

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

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

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

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

外部整合

ACI管理虛擬化平臺的網(wǎng)絡(luò)功能，如Hyper-V，Xen和VMware，但不能管理虛擬機或提供服務(wù)器。為了實現(xiàn)了一個軟件驅(qū)動的數(shù)據(jù)中心，ACI可以與其他解決方案整合，提供更完整的業(yè)務(wù)流程解決方案。

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

通過與vCenter集成整合，ACI可以在一個VMware vSphere集群管理分布式交換機。

當然，ACI可以與思科統(tǒng)一計算系統(tǒng)(UCS)集成整合。結(jié)合ACI和UCS基礎(chǔ)設(shè)施，可以自動完成整個數(shù)據(jù)中心，采用了虛擬機和裸機服務(wù)器配置的UCS控制，并借鑒UCS Director與ACI API的整合以便于動態(tài)網(wǎng)絡(luò)fabric結(jié)構(gòu)配置。

也有使用ACI管理擴展與微軟的系統(tǒng)中心虛擬機管理器和Azure Pack集成整合的可能性。

思科ACI是一款強大的解決方案，是專為大規(guī)模部署服務(wù)的。這是設(shè)計和規(guī)模從傳統(tǒng)網(wǎng)絡(luò)邁出的重要的一步，更是思科網(wǎng)絡(luò)管理朝著開放和現(xiàn)代的API控制結(jié)構(gòu)邁進的重要一步。

ACI也代表著從OpenDaylight SDN項目方向的一個偏離，其帶來了一個面向應(yīng)用程序策略的模型和替代OpFlex的一項控制協(xié)議。思科及其客戶究竟能夠推動ACI走多遠，尚有待時間的檢驗。