OpenStack Network Configuration Design

OpenStack provides a wide range of network configuration environments. This article describes how to design a cloud system to consider and design network requirements.

If this is the first time you deploy a cloud system in your organization, please contact your network O & M team after reading this section to learn about the current network conditions. The network used by the cloud system is different from the network deployment method used by the common system, and may affect network connectivity and network policies during deployment.

For example, the IP address resources required for the servers that make up the cloud system and Virtual Machine instances running on the cloud need to be properly planned and prepared in advance; the proxies involved in the cloud system network, the firewall also needs to be researched.

Network Management

Effective network management is usually an important consideration (for example, distributed switches and network interfaces ). By managing and monitoring system traffic and distributing actual cloud system user traffic, you can reduce the impact on your use.

For internal components of OpenStack, we recommend that you use a private network for communication, such as message queue and OpenStack computing nodes. VLAN is very suitable for this type of private network scenario.

Public Access Options

There are two IP Address Allocation Policies for Virtual Machine instances in the cloud system: fixed IP address and dynamic IP address. A fixed IP policy is assigned and bound to a fixed IP address when the VM instance is started, while a dynamic IP policy may change the IP address when the user operates differently. The two IP policies can be used for both the public and private networks as required.

OpenStack must use a fixed IP address, while dynamic IP addresses are not required. Two common application scenarios of Dynamic IP addresses are as follows: for private cloud environments with limited public IP addresses, Internet access to private clouds can be provided; or a public cloud user can have a static IP address to access cloud resources, and the actual instance in the cloud system has been migrated or upgraded.

A fixed IP address can be an intranet IP address in the private cloud or a public IP address in the public cloud. When the VM instance is terminated, the corresponding fixed IP address is recycled by the system. It should be noted that users who are using the cloud system at the beginning may be confused about the disappearance of fixed IP addresses.

IP address planning

The OpenStack environment may require many subnets, and each subnet may run different services. IP address planning provides better help for network separation and expansion. The Control Service requires both public and private IP addresses. For more information, see the public network configuration of virtual machines.

IP address planning can be divided into the following parts:

1. Subnet routing: Subnet data packets are transmitted through a dedicated route or the nova-network service.
2. Public interfaces for controlling services: swift-proxy, nova-api, glance-api, and horizon public access can be directed to a single server or after Server Load balancer.
3. Internal communication of the OSS cluster: communication between the services of the Object/account/container and the private network used by the internal interfaces of the proxy service.
4. Computing and storage communication: temporary storage and object storage are external services for computing nodes and require network connection and communication.
5. External Remote Management: If a dedicated external remote controller is used to manage servers, a separate network is usually used.
6. Internal Remote Management: computing or storage nodes usually require additional network interfaces (such as 1g interfaces) for system management or monitoring tools to access the server.
7. Reserved space for future expansion: Add new public-oriented control services, or add more virtual machine instance IP addresses to your plan.

For example, if the OpenStack computing and Object Storage Service is deployed on the private IP segment 172.22.42.0/24 and 172.22.87.0/26, you can configure the Service as follows:

172.22.42.0/24 172.22.42.1-172.22.42.3-subnet route 172.22.42.4-region-reserved region-172.22.42.104-compute node Remote Controller executor-compute node management interface executor-transport-Swift proxy Remote Controller executor- 172.22.42.228-Swift proxy management interface 172.22.42.229-172.22.42.252-Swift storage servers Remote Controller 172.22.42.253-172.22.42.254-reserved 172.22.87.0/26: 172.22.87.1-172.22.87.3-subnet route 172.22.87.4-172.22.87.24-Internal interface of Swift proxy server 172.22.87.25-172.22.87.63-Internal interface of Swift object server

You can also use a public IP address in a similar way. We recommend that you use a large range of IP addresses. Note that in some Openstack network configurations, the public IP address of the VM instance is allocated to the nova-compute host.

Network Topology

OpenStack provides several network management methods, each of which has its own advantages and disadvantages. Choosing different network management methods will affect your network topology. Therefore, you must be careful when selecting the appropriate method. Advantages of the Flat method: it is simple and does not require DHCP broadcast. Disadvantages: file injection must be performed in Virtual Machine instances, which is limited to a limited Linux release version. It is difficult to configure and is not recommended for FlatDHCP. Advantages: the configuration is relatively simple. The standard network protocol can be used in any operating system. Disadvantages: You need to have your own DHCP broadcast domain VlanManager. Advantages: each tenant can be isolated from its own VLAn. Disadvantages: complicated configurations, you need to have your own DHCP broadcast domain. You need to configure transmission ports for many VLANs. The number of VLANs is limited. The switch must support 802.1q VLAN tagging FlatDHCP Multi-host. Advantages: network faults can be isolated by virtual machines. Disadvantages: complicated configuration HA advantages: running on the hypervisor affected. (do not know what it means? Run on the host, can be migrated ?), DHCP communication can be isolated from a single host, and network traffic can be distributed to different computing nodes. Disadvantages: by default, the computing node must be assigned a public IP address. During online expansion, you must be careful to modify the configuration in the network area.

VLANs

VLAN configurations can be from simple to complex. VLAN enables each project to have its own subnet and network broadcast can be separated from other projects. To enable OpenStack to better use VLANs, You need to divide VLANs (one VLAN for each project), and the switch ports connected to each computing node must be bound to the VLAN's transmission port (trunck port ).

For example, if your cloud needs to support a maximum of 100 projects, select a VLAN range (for example, VLAN 200-299) that is not used in the current network architecture ), then, configure OpenStack to use the VLAN range and the switch port allows the VLAN range to communicate.

Multiple Network Interfaces

OpenStack supports allocating multiple network interfaces to a virtual machine instance. Although this is an uncommon advanced feature, it can be supported through simple configuration. Note that the second network interface uses the entire Subnet or VLAN, reducing the number of projects that can be supported.

Multi-host and single-host Networks

The nova-network service can run in multi-host or single-host mode. In the multi-host network mode, each computing node runs a nova-network service, which serves as a gateway for Connecting Virtual Machine instances on the same node to the Internet. At the same time, the computing node also provides dynamic IP addresses and Security Groups (Security Groups) for the local Virtual Machine instances ). A single-host network mode uses a centralized server, such as a cloud controller, to run the nova-network SERVICE independently. All computing nodes forward the network communication of Virtual Machine instances to the cloud controller, which is responsible for connecting to the Internet. Dynamic IP addresses and Security Groups (Security Groups) used by all Virtual Machine instances on all computing nodes in the cloud are supported by cloud controllers.

Both modes have their own advantages and disadvantages. The single host network mode has the disadvantages of single point of failure. When the Cloud Controller fails, all Virtual Machine instances cannot communicate over the network. This problem does not occur in the multi-host network mode, but in the multi-host mode, each computing node must have a public IP address used to connect to the Internet. If you do not have enough public IP addresses, you cannot use the multi-host network mode.

NETWORK SERVICE

OpenStack applies many standard services like other network applications, such as DNS and NTP.

NTP

Time Synchronization is a key factor to ensure that all components of OpenStack can work normally. Scheduling in Virtual Machine instances, object replication in Object Storage and timestamp matching in logs must have a correct time.

All servers running the OpenStack component must be able to access the appropriate NTP service. You can build an NTP service locally or use a public NTP service. Visit http://www.pool.ntp.org/to renew the public ntpservice.

DNS

OpenStack does not provide DNS services except for running dnsmasq on the nova-network server. You can consider providing a dynamic DNS service for Virtual Machine instances to update DNS records pointing to new IP addresses, you can also provide forward or reverse DNS mappings with virtual machine instance IP addresses, such as: vm-203-0-113-123.example.com.

Install and deploy Openstack on Ubuntu 12.10

Ubuntu 12.04 OpenStack Swift single-node deployment Manual

Implementation of Corosync + DRBD + Pacemaker in the HA cluster of MySQL Server

Corosync + DRBD + Pacemaker Implementation of the HA cluster on the MySQL server-Part 1

Corosync + DRBD + Pacemaker Implementation of the HA cluster on the MySQL server-Part 2