一直以來，OpenStack 在Quantum（現(xiàn)在為Neutron）中具備明確的NAAS模型，這也是一個NAAS演變很好的例子，并且可以看出我們在不斷向前發(fā)展。
當設(shè)立云應(yīng)用的連接服務(wù)時，云管理員往往不具備高級的網(wǎng)絡(luò)技能，為了避免成為永久的中間人，需要了解OpenStack Neutron，以后會經(jīng)常與OpenStack Neutron打交道。如果云管理員能夠跟上OpenStack Neutron的發(fā)展步伐，網(wǎng)絡(luò)即服務(wù)就越有可能成為構(gòu)建云的真正框架，而不需要網(wǎng)絡(luò)專業(yè)人員或者供應(yīng)商的技術(shù)支持。
了解NAAS架構(gòu)模型
OpenStack網(wǎng)絡(luò)是一個模型與插件過程，并且在一些重要的方面，發(fā)生著改變。 OpenStack遵循NAAS架構(gòu)虛擬化的一般原則：抽象和具體。
抽象意味著NAAS定義了一些代表抽象網(wǎng)絡(luò)元素的“模型”。 例如，幾乎所有的云應(yīng)用程序，都部署在IP子網(wǎng)內(nèi)，并代表著OpenStack Neutron的網(wǎng)絡(luò)或者子網(wǎng)模型。網(wǎng)絡(luò)是虛擬的本地局域網(wǎng)（LAN），你可以添加DHCP和域名系統(tǒng) （DNS）服務(wù)，以提供尋址和定義端口/網(wǎng)關(guān)，然后將子網(wǎng)與用戶連接。
虛擬化和NAAS “具體”的部分，即Neutron抽象、模型轉(zhuǎn)化為現(xiàn)實網(wǎng)絡(luò)行為的過程。 這是通過一個插件完成的，這個插件向設(shè)備或管理系統(tǒng)發(fā)送一串命令，然后執(zhí)行命令，最后創(chuàng)建所需的網(wǎng)絡(luò)行為。
關(guān)于模型方面，云計算的早期實驗揭示了一個事實，即要想建立NAAS（網(wǎng)絡(luò)，端口和接口），使用Neutron的基本模型，還遠遠不夠。 因此，當OpenStack更新時，每一個基礎(chǔ)版本可能會增加一些新的抽象模型ONeutron。
隨著OpenStack網(wǎng)絡(luò)不斷發(fā)展，創(chuàng)建云應(yīng)用的NAAS模型，不再需要進入網(wǎng)絡(luò)管理系統(tǒng)，每一步無需網(wǎng)絡(luò)專業(yè)人員。有了最新的Neutron抽 象和最 新插件，僅僅使用OpenStack工具，管理員就可以定義和部署完全連接的云應(yīng)用程序或應(yīng)用系統(tǒng)。如果管理員添加DevOps工具，如 Chef,Puppet 或者 Juju，那么，無需特殊的網(wǎng)絡(luò)技能，就可以部署和重新部署基于腳本的云應(yīng)用程序。
力爭保持OpenStack插件實時更新
盡管OpenStack插件會為云管理員帶來某些好處，但問題是，企業(yè)在復雜的云環(huán)境下，能否保持OpenStack插件實時更新。 因為OpenStack假定，每個OpenStack域，只有一個Neutron服務(wù)器和插件，在多廠商網(wǎng)絡(luò)中存在很大風險，即不能為整個云管理環(huán)境量身 定制插件。 使用標準的網(wǎng)絡(luò)控制框架，如OpenFlow或OpenDaylight ，可以緩解此問題，但是對大型企業(yè)來說，找到控制供應(yīng)商和設(shè)備的插件，有一定困難。
這個問題很難解決-但是OpenStack基金會正在設(shè)法解決這個問題。一個進展中的項目，每次執(zhí)行Neutron，支持多個插件，可以解決多廠商 網(wǎng)絡(luò)提 供標準化的Neutron NAAS抽象這一問題。 當Neutron激活參數(shù)時，其它插件項目再將參數(shù)發(fā)送到虛擬元素，從而獲得正確的端口或接口或設(shè)備。 云管理員不得不從網(wǎng)絡(luò)組織中獲得這樣的設(shè)置參數(shù)，并且通過部署這些參數(shù)，來配置虛擬元素，這對云管理員來說，起到一定幫助。
數(shù)據(jù)顯示，大多數(shù)云管理員不去審查OpenStack的Neutron項目，這種做法是錯誤的。有些項目具有重大影響，如添加模型/抽象或同時支持 多種插 件。 其他項目則細化目前的插件或抽象，以提高性能或增加新的功能。 像OpenStack代碼審查網(wǎng)站為云管理員提供了準備測試的OpenStack Neutron項目的當前現(xiàn)狀。 這可能會影響到云實施或云計劃。