In previous articles, I introduced the architectures of OpenStack using Linux Bridge and Open vSwitch plug-ins. In this post, we will introduce OVN, a newer Neutron Plug-in with a different architecture. Overview: OVN can be described as a distributed SDN controller that creates virtual networks through OVS. Here are some of the features OVN provides: It provides an abstraction layer for OVS through L2 and L3 overlays while managing connections to physical networks; supports flexible ACLs implemented using OVS connection tracking; supports distributed L3 routing implemented via OVS flows, supporting both IPv4 and IPv6; utilizes OVS connection tracking for NAT and Load balancing; and provides distributed DHCP [...]
From Bare Metal to Cloud: OpenStack Neutron Introduction — OVS Self-service Networks
The previous article introduced the architecture and packet flow of Open vSwitch with Provider Networks. Today, this post will introduce Open vSwitch with self-service networks. Open vSwitch: Self-service Networks Architecture. The image above provides an overview of the entire architecture under the Open vSwitch – Self-service networks model. You can see which components run on the controller node, compute node, and network node. This diagram illustrates how the components are interconnected within a single untagged (flat) provider network and a single self-service network. In this example, the Instance and the DHCP agent are on the same machine, but in practice, the DHCP agent might reside on another compute node. Traffic Flow [...]
From Bare Metal to Cloud: OpenStack Neutron Introduction — OVS Provider Networks
The previous article introduced the architecture and flow of Neutron using the Linux Bridge plug-in under different scenarios. Over the next few days, I will introduce the architecture and traffic flow when using the OVS plug-in. First, I will introduce Open vSwitch with Provider Networks. Open vSwitch: Provider networks architecture. The image above shows the overall architecture overview under the Linux Bridge – Provider Networks model. You can see which components run on the controller node and which run on the compute node. This diagram illustrates how components within the compute node are interconnected under a single provider network (untagged/flat). In this example, the Instance and the DHCP agent are on the same machine, but in practice, the DHCP agent might be on another compute node. When there are multiple Provider networks [...]
From Bare Metal to Cloud: OpenStack Neutron Introduction — Linux Bridge – Self-Service Networks
The previous article introduced the architecture and packet flow of Linux Bridge with Provider Networks. Today, this post will introduce Linux Bridge with self-service networks. Linux bridge: Self-service Networks. Self-service networks provide users with an almost unlimited number of virtual networks. Although Neutron supports VLAN self-service networks, this example uses VXLAN self-service networks. Architecture. The image above provides an overview of the entire architecture under the Linux Bridge – Self-service networks model. You can see which components run on the controller node, compute node, and network node. This diagram illustrates how the components used in self-service networks are interconnected under a single provider network. In this example, the Instance and DHCP [...]
From Bare Metal to Cloud: Introduction to OpenStack Neutron — Linux Bridge Provider Networks
The previous article introduced the architecture of Neutron. Over the next few days, I will introduce the architecture and traffic flow of Neutron when using Linux Bridge and OVS plug-ins. First, I will introduce Linux Bridge with Provider Network. Linux bridge: Provider networks. The Provider network architecture example uses VLAN (802.1q) tagging to provide L2 connectivity between instances and the physical network infrastructure. It supports one non-tagged (flat) network and up to 4,095 tagged (VLAN) networks. The actual number of VLAN networks depends on the physical network infrastructure. Architecture: The image above provides an overview of the entire architecture under Linux Bridge – Provider Networks. You can see which components run on the controller node and which run on the compute node. This diagram illustrates a single [...]
From Bare Metal to Cloud: Introduction to OpenStack Neutron 3
The previous article introduced the concepts of Neutron networking. Next, I will continue by introducing some Neutron terminology. Neutron Concepts (Terminology): Subnets. A subnet is a set of IP addresses and associated configuration states, providing IPAM (IP Address Management) for provider/project networks. Subnets are used to assign IP addresses when creating ports on a network. Subnet pools: Users can typically create subnets using any valid IP address without other restrictions. However, in some cases, administrators or projects may want to pre-define an IP address pool so that a range of addresses is automatically allocated when a subnet is created. In some situations, administrators might want to avoid IP address duplication; subnet pools can be used to prevent address overlaps between two subnets from the same pool. Port: A port is a connection point that attaches a single device (such as a virtual server's NIC) to a virtual network. The port also describes associated network settings, such as the MAC and IP addresses to be used on that port. Router: Routers provide virtual L3 functionality, such as between self-service and provider networks or [...]
From Bare Metal to Cloud: Introduction to OpenStack Neutron 2
The previous article introduced the architecture of Neutron. The next two articles will continue to introduce some of Neutron's concepts and terminology. Neutron Concepts: Neutron allows users to create networks and their subnets, and enables other OpenStack services (such as Compute) to connect virtual devices to ports on these networks—the most common example being connecting an Instance to a network. Neutron supports multiple private networks per project and allows projects to choose their own IP addressing schemes, even if IP addresses in different networks overlap with those used by other projects. There are two types of networks: provider networks and self-service networks, which can be shared across projects. Provider Networks: Provider networks provide L2 network connectivity for instances and support DHCP and metadata services. These networks connect to existing L2 networks in the data center, typically using VLAN (802.1q) tagging for identification and isolation. [...]
From Bare Metal to Cloud: Introduction to OpenStack Neutron 1
Yesterday, I introduced Keystone, which is considered the most core component in OpenStack. Today, I will introduce what I believe to be the most complex component in OpenStack: Neutron, the component that provides networking services. Neutron Architecture: OpenStack Networking (Neutron) allows you to create network interfaces and attach them to services managed by other OpenStack components (such as Nova VMs), enabling them to connect to the network. It provides flexibility for OpenStack architecture and deployment through various backend plugins that accommodate different networking equipment and software. It includes the following components: Neutron-server: Accepts API requests and routes them to the appropriate OpenStack Networking plugin for operation. OpenStack Networking backend plug-ins and agents: These plug and unplug ports, create networks or subnets, and provide IP addresses. These plug-ins and agents vary depending on the vendors and technologies used in different clouds. Common plug-ins include OVS, Linux Bridge, and OVN, whose architectures will be introduced later. Common agents [...]
From Bare Metal to Cloud: An Introduction to OpenStack Keystone
The previous article introduced Nova, the oldest OpenStack component. This article will introduce Keystone, which is currently considered the most core component in OpenStack. What is Keystone? The official documentation describes it as follows: Keystone is an OpenStack service that provides API client authentication, service discovery, and distributed multi-tenant authorization by implementing OpenStack's Identity API. Simply put, you can think of it as the authentication service in OpenStack, which also records the locations (endpoints) of all OpenStack APIs. Keystone Architecture: Keystone is composed of several different internal services, which are typically used in combination. For example, an authentication request is first verified through the Identity service using the credentials provided by the user; upon success, a token is generated for the user via the Token service. Keystone includes the following services: Identity, Resource, Assignment, Token, and Catalog. We will introduce the functions of these services one by one. [...]
From Bare Metal to Cloud: Introduction to OpenStack 2
The previous article introduced the OpenStack project from a non-technical perspective. Starting today, we will explore OpenStack from a more technical standpoint. This post will provide a general overview of the components that comprise OpenStack, followed by in-depth introductions to each component in subsequent articles.
