OpenStack Neutron Network Guide

Since the beginning of cloud computing, the basic process of deploying applications in the cloud has barely changed, by first Deploying application components and database elements, and then connecting them to users over the network. However, the details of how to connect these applications have changed. Because the way you define "network as a service" changes.

All along, OpenStack has a clear Naas model in quantum (now Neutron), which is a good example of Naas evolution, and it can be seen that we are constantly moving forward.

Cloud administrators often do not have advanced networking skills when setting up a cloud application connectivity service, and in order to avoid becoming a permanent middleman, they need to understand OpenStack neutron and often deal with OpenStack neutron. If cloud administrators can keep up with the pace of OpenStack Neutron, the more likely the network, the service, will become the real framework for building the cloud without the technical support of network professionals or vendors.

Understanding the Naas Architecture model

OpenStack Network is a model and plug-in process, and in some important aspects, changes have taken place. OpenStack follows the general principles of Naas Architecture Virtualization: Abstraction and specificity.

Abstraction means that Naas defines "models" that represent abstract network elements. For example, almost all cloud applications are deployed in IP subnets and represent OpenStack Neutron network or subnet models. The network is a virtual local area network (LAN) where you can add DHCP and domain Name System (DNS) services to provide addressing and define ports/gateways, and then connect subnets to users.

Virtualization and Naas the "concrete" part, that is, the process of neutron abstraction and model into the real network behavior. This is done through a plug-in that sends a sequence of commands to the device or management system, executes the command, and finally creates the desired network behavior.

In terms of models, the early experiments of cloud computing reveal the fact that it is not enough to build Naas (networks, ports, and interfaces) using Neutron's basic model. Therefore, when OpenStack update, each base version may add some new abstract model Oneutron.

With the development of the OpenStack network, the NAAS model of cloud application is no longer required to enter the network management system, each step without network professionals. With the latest neutron abstraction and latest plug-ins, only the OpenStack tool allows administrators to define and deploy fully connected cloud applications or applications. If an administrator adds DevOps tools, such as Chef,puppet or juju, you can deploy and redeploy a script based cloud application without special network skills.

Strive to keep the OpenStack plugin updated in real time

While the OpenStack plug-in has some benefits for cloud administrators, the question is whether the enterprise can keep the OpenStack plug-in in real time in a complex cloud environment. Because OpenStack assumes that each OpenStack domain has only one neutron server and plug-in, there is a large risk in multi-vendor networks that you cannot tailor plug-ins for the entire cloud management environment. Using standard network control frameworks, such as OpenFlow or opendaylight, can alleviate this problem, but it is difficult for large enterprises to find plug-ins to control suppliers and equipment.

The problem is hard to solve-but the OpenStack Foundation is trying to solve the problem. A progress project, each execution neutron, supporting multiple plug-ins, can solve the problem of multi-vendor network to provide standardized neutron Naas abstraction. When neutron activates the parameter, the other plug-in project sends the parameter to the virtual element to obtain the correct port or interface or device. Cloud administrators have to get such setting parameters from the network organization and configure the virtual elements by deploying these parameters, which will help cloud administrators.

Data show that most cloud administrators do not review OpenStack's neutron project, which is wrong. Some projects have significant impact, such as adding models/abstractions or supporting multiple plug-ins at the same time. Other projects refine current plug-ins or abstractions to improve performance or add new functionality. The OpenStack Code review site provides cloud administrators with the current status of the OpenStack Neutron project to prepare for testing. This may affect cloud implementation or cloud planning.