思科高可擴展性的數(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走多遠,尚有待時間的檢驗。