Detailed introduction and summary of Openstack network knowledge materials

Summary of network knowledge materials of Openstack:

Openstack concept

When I first heard that I was going to do openstack development, I was really excited. I don't know what openstack is, but I do know it has to do with cloud computing. Cloud computing this thing, it sounds lofty, each big Internet company has cast a person to go in to do, so the general direction must affirm. So I couldn't resist deploying openstack on my own computer to get a feel for what it was. After a lot of trouble, openstack was finally deployed in the virtual machine using devstack (in the deployment process, the most vulnerable is the domestic firewall).

Deployment is the process of installing a stack of Python packages onto the host system. openstack has an python package called Dashboard, which provides an Web interface from which I really get to experience what openstack is. The process of creating a virtual machine on Dashboard is interesting and involves a number of steps, many of which are similar to the steps of installing a real computer.

Openstack	Real Life
创建 ubuntu 镜像	使用 Ultraiso 刻录好1个 ubuntu 系统 的 U 盘
创建 provider 网络	叫电信的来给家里开通网络
创建 Instance 主机	买了1台主机，并用刚刚的 U 盘给它装好 Ubuntu 系统
启动 Instance 主机	把电信的网口插到主机网卡上

I created two Instance hosts on Dashboard, and the two hosts worked fine. For now, this effect is very similar to VMware Workstation software, which can run multiple virtual hosts on one physical machine. While VMware Workstation is for a single physical machine, openstack can manage and virtualize clusters of physical machines. The concept of a private cloud comes into play when hundreds or thousands of physical machines are managed by openstack and end users only have to face a single Dashboard interface with only one.

Once you have an emotional understanding, go to the openstack website to define yourself:

Open source software for creating private and public clouds.

OpenStack software controls large pools of compute, storage, and networking resources throughout a datacenter, managed through a dashboard or via the OpenStack API. OpenStack works with popular enterprise and open source technologies making it ideal for heterogeneous infrastructure.

Hundreds of the world's largest brands rely on OpenStack to run their businesses every day, reducing costs and helping them move faster. OpenStack has a strong ecosystem, and users seeking commercial support can choose from different OpenStack-powered products and services in the Marketplace.

The software is built by a thriving community of developers, in collaboration with users, and is designed in the open at our Summits.

The OpenStack software controls large computing, storage and network resources throughout the data center, which users can manage through Dashboard or OpenStack API. As I understand it, Openstack is more like an operating system, a powerful cloud computing operating system.

Openstack network concept

The two Instance virtual machines I created earlier through Dashboard can communicate with each other through ping, because they are in the same layer 1 and 2 network, and they are directly connected to Provider network.

 |  VM1 |       | VM2 |
 | -------|       |-------|
  |           |
  | Eth(172.24.4.2)   | Eth(172.24.4.3)
____|______________________|___________
- - - - - - - - - - - - - - - - - - - - Provider (172.24.4.0/24)

The above topology already covers the three core network concepts in openstack: Network, Subnet, Port. We map these three concepts to the network topology 1 above:

The name "Provider" corresponds to Network of openstack The IP address pool "172.24.4.0/24" corresponds to Subnet of openstack "Eth(172.24.4.2)" this Instance network card corresponds to Port of openstack

In fact, we can also make VM1 and VM2 not on a 2-tier network, but at this time, we need to introduce Router, another core concept of openstack network.

 | VM2 |
            |-------|
              |
              | Eth(10.0.0.2)
           _______|_______
           - - - - - - - - Private (10.0.0.0/24)
              |
              | If(10.0.0.1)
              |
 | VM1 |       | Router1 |
 |-------|       |----------|
  |            |
  | Eth(172.24.4.2)    | Gw(172.24.4.3)
____|_______________________|__________
- - - - - - - - - - - - - - - - - - - - Provider (172.24.4.0/24)

In this way, VM1 and VM2 will no longer have the same 2-layer network, and the network environment of the two Instance virtual machines will be isolated. As can be seen from the topology, there are three new parts:

Router: that is, Router1 in the topology Router-Gateway: Gw(172.24.4.3) in the topology, mainly for the virtual machine behind Router1 to access the Provider network. Router-Interface: If(10.0.0.1) in the topology, make Router1 the gateway to L3 on the Private network.

The above two network topologies cover the core concepts of openstack network. Of course, there are only four core concepts mentioned above, which cannot adapt to the complex network topology requirements of actual Data Center. For this reason, there are other virtual network concepts such as FloatingIP, SecurityGroup, ServiceFunctionChain and so on.

Introduction to the Openstack network component

Openstack contains a large number of sub-projects. Currently, several core sub-projects are as follows:

Nova: provide compute computing power (virtual machine) Neutron: provides networking network connectivity Glance: provides image image storage capability Keystone: provides identity authentication capabilities Cinder/Swift: provides storage storage capability

Network virtualization is a fast developing field. So far, Neutron has been well supported by L2, L3, HA, SecurityGroup, LBaas, FWaas, VPNaas, DVR and so on. It's just that I read some articles that said the development direction of Neutron should be to focus on the customization of API standard. Let the various network functions be separated from Neutron, and let the SDN Controller Plugin of various network equipment vendors focus and realize this part of functions. Neutron needs to design a good set of northbound interface specifications to make itself a pure API Server (I am not sure about the correctness of these views, but it is a good thing to look at things from a different height).

There are two interesting frameworks in Neutron, the ML2 framework and the Extension Plugin framework. ML2 is an abstraction of L2's network capabilities, which allows different L2 virtualization technologies (LinuxBridge, OpenvSwitch...) You just need to connect the 1 pair to ML2. Extension Plugin is one of the SDN Controler or Network Function Virtual under development, which can be conveniently connected to Neutron for deployment testing, and then integrated into Neutron project after it has incubated and matured. The Openstack (Neutron + OVN) I deployed on the host was actually implemented by making full use of Neutron ML2 and ExtensionPlugin, which also shows the great flexibility of Neutron.

Neutron (Open Virtual Network for OpenvSwitch) is a subproject hatched by the OpenvSwitch team itself. The purpose of OpenvSwitch is to make OVS support the virtual network more friendly. Let me quote a wonderful point of view from IBM's blog:

How can Pick up from leverage OVN to improve OVS performance in cloud computing environments

As we all know, OpenvSwitch has become the most popular virtual switch in Openstack deployment due to its rich functions and good performance. The architecture of Openstack Neutron introduces some performance problems. For example, neutron-server has to communicate with a lot of agent. RPC is a performance bottleneck, and namespace USES a lot of namespace in neutron, while namespace has limited resources and high system overhead, which is also a performance bottleneck. The OVS community felt that in the long run, Neutron should let one other project do the control plane of the virtual network. Neutron only needs to provide the processing of API, so the OVS community launched the project OVN (Open Virtual Network). OVN is the control plane of OVS, which adds native support for the virtual network to OVS. The performance and scale of OVS in practical application environment are greatly improved.

If you want to integrate OVN and Neutron, you'll also need Networking-ovn Plugin's help. Networking-ovn is a relatively simple Plugin. Its job is to translate the definition of virtual network in Neutron into the definition of virtual network in OVN. Its simplicity derives from the elegant Neutron API interface design, and the compact OVN northbound database table design.

|   OPENSTACK   |
|           |
|   (neutron)   | API Server
-----------------------
     | |
     v v
---> networing-ovn <--- Service and Plugin
     | |
     v v
   |----------|
   |  OVN  |    SDN Controller for OpenvSwitch
   |----------|
     |
     v
----------------------
|  OpenvSwitch   |  DataPlan support for Virtual Networking Function
|          |

Thank you for reading, I hope to help you, thank you for your support of this site!