自从云计算开始以来，云中部署应用程序的基本过程几乎没有发生变化，即首先部署应用组件和数据库元素，然后通过网络，将它们与用户连接。 然而，如何连接这些应用的细节发生了改变。因为定义“网络即服务”的方式改变了。 一直以来，OpenStack 在Quantum(现在为Neutron)中具备明确的NAAS模型，这也是一个NAAS演变很好的例子，并且可以看出我们在不断向前发展。 当设立云应用的连接服务时，云管理员往往不具备高级的网络技能，为了避免成为永久的中间人，需要了解OpenStack Neutron，以后会经常与OpenStack Neutron打交道。如果云管理员能够跟上OpenStack Neutron的发展步伐，网络即服务就越有可能成为构建云的真正框架，而不需要网络专业人员或者供应商的技术支持。 了解NAAS架构模型 OpenStack网络是一个模型与插件过程，并且在一些重要的方面，发生着改变。 OpenStack遵循NAAS架构虚拟化的一般原则：抽象和具体。 抽象意味着NAAS定义了一些代表抽象网络元素的“模型”。 例如，几乎所有的云应用程序，都部署在IP子网内，并代表着OpenStack Neutron的网络或者子网模型。网络是虚拟的本地局域网(LAN)，你可以添加DHCP和域名系统 (DNS)服务，以提供寻址和定义端口/网关，然后将子网与用户连接。 虚拟化和NAAS “具体”的部分，即Neutron抽象、模型转化为现实网络行为的过程。 这是通过一个插件完成的，这个插件向设备或管理系统发送一串命令，然后执行命令，最后创建所需的网络行为。 关于模型方面，云计算的早期实验揭示了一个事实，即要想建立NAAS(网络，端口和接口)，使用Neutron的基本模型，还远远不够。 因此，当OpenStack更新时，每一个基础版本可能会增加一些新的抽象模型ONeutron。 随着OpenStack网络不断发展，创建云应用的NAAS模型，不再需要进入网络管理系统，每一步无需网络专业人员。有了最新的Neutron抽 象和最新插件，仅仅使用OpenStack工具，管理员就可以定义和部署完全连接的云应用程序或应用系统。如果管理员添加DevOps工具，如 Chef,Puppet 或者 Juju，那么，无需特殊的网络技能，就可以部署和重新部署基于脚本的云应用程序。 力争保持OpenStack插件实时更新 尽管OpenStack插件会为云管理员带来某些好处，但问题是，企业在复杂的云环境下，能否保持OpenStack插件实时更新。 因为OpenStack假定，每个OpenStack域，只有一个Neutron服务器和插件，在多厂商网络中存在很大风险，即不能为整个云管理环境量身 定制插件。 使用标准的网络控制框架，如OpenFlow或OpenDaylight ，可以缓解此问题，但是对大型企业来说，找到控制供应商和设备的插件，有一定困难。 这个问题很难解决-但是OpenStack基金会正在设法解决这个问题。一个进展中的项目，每次执行Neutron，支持多个插件，可以解决多厂商 网络提供标准化的Neutron NAAS抽象这一问题。 当Neutron激活参数时，其它插件项目再将参数发送到虚拟元素，从而获得正确的端口或接口或设备。 云管理员不得不从网络组织中获得这样的设置参数，并且通过部署这些参数，来配置虚拟元素，这对云管理员来说，起到一定帮助。 数据显示，大多数云管理员不去审查OpenStack的Neutron项目，这种做法是错误的。有些项目具有重大影响，如添加模型/抽象或同时支持 多种插件。 其他项目则细化目前的插件或抽象，以提高性能或增加新的功能。 像OpenStack代码审查网站为云管理员提供了准备测试的OpenStack Neutron项目的当前现状。 这可能会影响到云实施或云计划。 |
