Getting the core components of OpenStack comb (5) - Neutron articles

Getting the core components of OpenStack comb (5) - Neutron articles

Foreword

This article will explain the components of one of the core components of Neutron OpenStack. Want to read this article before, it is recommended for beginners to advance awareness of cloud computing, Linux operating system, server and cluster concepts and OpenStack architecture diagram. This article is mainly to organize their own knowledge of theories about OpenStack, but also to share their shallow understanding of OpenStack Neutron in the following with readers.

Links: The following three articles for beginners or less can help you understand the cloud and OpenStack in the macro.

Talking about cloud computing

OpenStack concepts and core components Overview

OpenStack deployment node types and architecture

First, the basic concept of Neutron

1.1Neutron Past and Present

Neutron, formerly known as Quantum, Quantum English quantum, neutron Neutron translated into English, although I do not know the specific reason for this name to the project, but the intuitive sense would think this stuff is not simple Ha!

In fact, the initial OpenStack is not the independent network components, to whom the establishment of a single core project, originally a Nova-network network model is called, this model is very simple, is a single flat network, as shown below :

However, if the familiar network knowledge will be issued this mode there is a big disadvantage, such as:

• Single network bottleneck, does not reflect the characteristics of the cloud (e.g., telescopic);
• Difficult to achieve isolation of the tenants;

So the need to constantly update technology development and related technical chiefs after thinking, try, finally worked out a scheme - independent network services, and then constantly optimize the establishment of the Neutron project. The Neutron network model has undergone great changes, it will go into the later introduction. This is mainly experience the charm of technological development, look at the predecessor of Neutron and development.

The basic concept of 1.2 Neutron

Neutron is one of the core OpenStack projects, mainly network services in the cloud computing environment. In OpenStack in, Neutron itself is also used in a distributed architecture that provides network services to a common external service or by a plurality of functional modules. Neutron is designed to achieve "network service", that is NaaS. Followed in the design is based on the principle of SDN (Software Defined Network) to achieve network virtualization, and the use in its implementation is related network technology linux system.

The main effect of 1.3 Neutron

In OpenStack, the specific role Neutron network service that allows users to create and manage network object, the object here refers to the network, subnet, port, etc., and these objects can be other OpenStack services use.

And, Neutron provides a support network for the entire OpenStack environment, covering the floor of the exchange, three routing and forwarding, load balancing, firewalls and other network communication technology ***.

In addition, Neutron project worth mentioning is the plug-in, plug-in means that there is OpenStack architecture scalability is very strong, and can adapt to different network equipment, stable work. Which ML2 regarded as a typical representative, will be introduced later article.

​

Second, the basic architecture of the Neutron

In the third article in the link given above, we introduced the concept of OpenStack architecture diagram and logic chart given by OpenStack official website. If you carefully look at the architecture diagram carefully, you will find logic chart in both the OpenStack Neutron components. The author of the interception, as shown below:

So how do you sort of understand the logic chart above?

In fact, this and our lives as familiar a thing or a person, you must first preliminary understanding, and understanding, and ultimately understand familiar, it is the same in our learning the truth. So, let's cognitive framework for understanding the concept and role of functional modules.

2.1Neutron module architecture introduced

2.1.1 neutron-server

The module is a process, and is the only major Neutron service process, usually running on the control node, provide the appropriate API (API such general principles based on REST-style) as the entrance of access Neutron.

2.1.2 neutron plugin

neutron plug-in, the core plugins (core plugin) and service plugins (service plug) components. Receiving a request to distribute tasks in similar roles.

• core plugins: providing basic layer 2 virtual network support, including network, subnet and port core resources; (after version of the update technology and make changes is discussed later)
• service plugins: refers to the core plugins in addition to other plug-ins, such as providing support for routers, firewalls, security groups and load balancing services.

2.1.3 neutron agent

neutron proxy module, the module responsible for executing tasks and receive messages, corresponding to the above-mentioned neutron plugin, playing the role of a real process work.

2.1.4 neutron provider

neutron network providers, the main role is to provide network services OpenStack virtual machine or physical network devices, such as Linux Bridge, OVS (Open vSwitch) (which is also the focus of both) or other normal Neutron physical switch.

2.1.5 Queue

Queue-- queue, the message queue is here --MQ, for mutual communication between the various modules Neutron, generally the default coordinate communications problem is achieved based on the language RabbitMQ Erlang.

2.1.6 neutron database

Here we all know is a database, but this information is stored in the network database, the default database used is Mariadb.

Well, after reading the above content, presumably understand the architecture of the various modules. So how these modules to link it?

This requires time to talk about the process of the architecture work, the author of this process is called "plug-speak."

2.2Neutron workflow

FIG here to tell the operating principle of the architecture and an example of the entire process by binding.

Now suppose you want to create a virtual network. The whole process is this:

(1) Neutron-server received a request to create a virtual network, through a message queue that a corresponding plug (not considered ML2) assume that the network provider (neutron provider) is OVS (Open vSwitch), then the corresponding plug-in here OVS is a plug-in;

(2) OVS plug after receiving the message, information (name, ID values, etc.) to create a virtual network need to be saved to Neutron database and run through the message queue a notification agent on each node;

(3) agent, creates a corresponding device on the node receiving the message after the agent i.e., e.g. vlan device.

Three, Neutron-server hierarchical model to explain

This section will talk in detail about the Neutron-server service. The following figure shows Neutron-server hierarchy.

3.1 Neutron-server hierarchy DESCRIPTION

Neutron-server layered structure shown above, they are from top to bottom:

3.1.1 Core API API Extension 和

• Core API: provide external management network (network), subnet (subnet) and port (port) of the RESTful API;
• Extension API: provide external management routing (router), load balancing (LB), RESTful API firewall (firewall) and other resources;

3.1.2 Common Service

• API requests for authentication and verification;

3.1.3 Neutron Core

• Neutron-server processor core in, plug-ins corresponding to call processing request;

3.1.4 Core Plugin API 和 Extension Plugin API

• Core Plugin API: Core Plugin used to call interface to the kernel handler;
• Extension Plugin API: with a core handler calls Extension Plugin interface;

3.1.5 Core Plugin 和 Service Plugin

• Corresponding core service plug-ins and the core plug core in response to the API, the API service plug in response to expansion;

Among them, the core plug is maintained in the database main state network, subnet and port and is responsible for calling the appropriate agent perform actions on the network provider, such as creating network; mainly maintenance service plug-in router, load balance in the database, the security group and other state resources, and is responsible for calling the appropriate agent perform actions on the network provider, such as creating router.

3.1.6 Database

A database for storing information corresponding to the data.

In fact, in the final analysis, Neutron-server that white can be understood as a combination of API and Plugins, that provide services API and plug-ins to run two tasks.

Flow 3.2 Neutron-server response

In fact, Neutron-server in response to a service request process is not complicated, can be divided into the following steps:

Neutron-server receive the assumption case to create a network client sends requests:

1, first of all, the object according to user needs to create a call corresponding API (core or extended API);

2, after the corresponding API issued in response to a request, this time to be authenticated and authorized by the verification Common Service;

After 3, authentication and authorization operations are performed through, delivered to Neutron Core core processing program by calling the plug-type process corresponding to the request.

Fourth, the basic concept of Neutron network

Neutron management of network resources, including network, subnet and port, introduced in turn below.

4.1 network

Layer network is an isolated broadcast domain. Neutron supports several types of network, including local, fla, VLAN, VxLAN and GRE and Geneve.

local

local network to other network nodes and isolation. The only instance in the local network and communication instance, local networks on the same node on the same network primarily for stand-alone testing.

Features:

1. Vlan not have the characteristics, the layer 2 network can not be isolated;
2. Virtual machine instance with a local network will be connected to the same virtual switch can communicate between instances;
3. The virtual switch is not bound to any physical NIC, can not communicate with the outside of the host network;

flat

flat network is no vlan tagging network. instance flat network can be located in the same instance of communication with the network, and may span multiple nodes.

vlan

vlan 802.1q tagging is a network of networks. vlan broadcast domain is a Layer, the same instance can communicate vlan, only different vlan router communication. vlan node across the network, is the most widely used type of network.

vxlan

vxlan overlay network is based on tunnel technology. vxlan network by a unique segmentation ID (also called VNI) vxlan distinguished from other networks. vxlan packets are encapsulated by the VNI to UPD packets for transmission. Because the floor of the three transmission packets, and can overcome the physical limitations vlan network infrastructure through the package.

vxlan and vlan compared advantages:

• The number of tenants increased from 4K to increase the number of 16M-- support;
• Tenants internal communications across any IP network, supports any virtual machine migration - communication across a network;
• Generally, each tenant has a logical gateway instance, IP addresses can be multiplexed between the tenant - repeated use does not conflict;
• SDN technologies can be combined to optimize the flow - and other technologies to support application

it

gre is vxlan a similar overlay network. The main difference is that instead of using an IP packet encapsulated in UDP.

On the floor between different network it is isolated.

​

4.2 Subnet

subnet is an IPv4 or IPv6 addresses. instance an IP subnet from the distribution. Each subnet mask to define the scope and IP addresses.

4.3 Port

port can be viewed as a port on the virtual switch. It defines the MAC address and IP address of the port, when the instance of the virtual network card VIF (Virtual Interface) to bind to the port, port will be assigned to the MAC and IP VIF.
port and subnet is one to many relationship. A port must belong to a subnet; a subnet can have multiple port.

Five, Neutron main function

The first section previously mentioned main role of Neutron, indeed, for the entire OpenStack Neutron provide the environment with network support, including the floor of the exchange, three routing, load balancing, firewalls and so on. Neutron and provides a corresponding frame, so that the user may be implemented through the configuration function. These functions are briefly described below.

5.1 floor of the exchange VSwitch

Neutron supports multiple virtual switches, including Linux Bridge Linux native and Open vSwitch.

Open vSwitch (OVS) is an open source virtual switch that supports standard management interfaces and protocols.

Use Linux Bridge and OVS, Neutron can be created in addition to the traditional VLAN network, you can also create Overlay Network-based tunneling technologies, such as VxLAN and GRE (Linux Bridge currently only supports VxLAN).

5.2 three-routing VRouter

Examples of different IP subnet can be configured, Neutron the vrouter (virtual router) to achieve inter-network communication examples. Generally may be achieved by routing and NAT IP forwarding, iptables technology.

5.3 Load Balancing Load Balance

In the version Openstack Grizzly first introduced Load-Balancing-as-a-Service (LBaaS), provides the ability to distribute the load of multiple instances. LBaaS support a variety of load-balancing products and solutions differently to achieve integration in the form of Neutron Plugin, the current default Plugin is HAProxy (personal understanding is that it belongs to the seven load).

5.4 Firewall Firewall

Neutron instance to protect the security of the network and by the following two ways.

• Security Group: Examples of restricted access by iptables network packets.
• Firewall-as-a-Service: FWaaS, restricted access virtual router network packets, but also to achieve by iptables.

VI Summary

This paper describes in OpenStack Neutron one of the core subprojects, Neutron projects covering a very broad principle, we were told for the first part of its foundation, understanding Neutron as a whole, for the neutron provider, neutron plugins (focus on ML2), network principle, the relevant agency (L3) deep-seated principles (such as Linux, network virtualization, namespaces, and other professional vocabulary of understanding) will continue to update later.

This paper describes the basic concepts of the role of the core components introduction (course focuses on the response of Neutron-server), Neutron architecture and explain the main features and network type Neutron provided (remember the previous four kinds!)

Thanks for reading!