In an OpenStack environment, the network traffic can be divided into the following networks:
- Administration network
This network is not part of the OpenStack infrastructure. It provides Internet access for all nodes and is used for administration to install software packages and security updates from Oracle Unbreakable Linux Network or Oracle Yum Server, and to provide access to the Docker registry and other services such as NTP and DNS.
- Public network
This network provides the external access to OpenStack services. For instances (virtual machines), this network provides the route out to the external network and the IP addresses to enable inbound connections to the instances. This network can also provide the public API endpoints to connect to OpenStack services.
- Management/API network
This network is a private internal network used for communication between all the OpenStack services and for high availability. All nodes in the deployment must have an IPv4 address on this network.
- Virtual machine network
This network is a private internal network that is used for communication between the OpenStack instances (virtual machines), and also between the instances and the network nodes to provide inbound and outbound connections to the public network.
- Storage network
This network is a private internal network that is used for the communication between compute nodes and storage nodes to access the storage.
Once you have decided how you want to implement these networks, you configure the network interfaces for the networks and other network settings by setting properties with the kollacli property set command, as described in Section 4.2, “Setting up Services”.
Figure 3.1 shows the default network configuration and the properties that specify the network interfaces on the target nodes.
In the default configuration, the
neutron_external_interface property specifies
the name of the network interface on the public network. To make
it easier to get started with deploying OpenStack services, the
management/API, virtual machine, and storage networks are
consolidated into a single network. The
network_interface property specifies the name
of the network interface on this network. This configuration
requires the minimum number of network interfaces.
While consolidating the management/API, virtual machine, and storage networks into a single network makes it easier to deploy OpenStack services, for performance and security reasons it is best to separate and isolate these networks. Figure 3.2 shows a fully-expanded network configuration and the properties that specify the network interfaces on the target nodes.
With this configuration, the
neutron_external_interface property specifies
the name of the network interface on the public network, and there
are separate properties for specifying the names of network
interfaces on the management/API
(api_interface), virtual machine
(tunnel_interface), and storage
(storage_interface) networks. This
configuration requires the maximum number of network interfaces.
If you enable Neutron Distributed Virtual Routing (DVR), the
interface specified for the
neutron_external_interface property must also
be available on compute nodes. See
Section 4.9.3, “Enabling Distributed Virtual Routing (DVR)” for details.
If you are starting with a small OpenStack deployment, the network
configuration is flexible so you do not have to separate the
management/API, virtual machine, and storage networks in one go.
By default, the properties for these networks are mapped to the
network_interface property. So you could start
with the default consolidated network, and then separate the
networks as your deployment expands.
You specify the network interface names on the target nodes using a single property for each network. This works best where the hardware on the target nodes is identical. When this is not the case, you can handle the variations by setting properties that are specific to groups or hosts, see Section 4.5, “Setting Properties for Groups or Hosts”.