Three-Node Architecture Overview
Single-node configurations are useful to test OpenStack as a product, and to familiarize yourself with its features. However, a single-node configuration is not suitable in a production environment. For this environment, you would install and configure OpenStack across multiple systems or nodes.
Each cloud needs only one dashboard instance, one image store, and one identity service. Each cloud can have any number of storage and compute instances. Evaluate each component with respect to your needs for a particular cloud deployment to determine whether that component should be installed on a separate node and how many of that type of node you need.
The architecture described in this chapter is deployed on the following three systems:
-
Controller node – node where most of the shared OpenStack services and other tools run. The Controller node supplies API, scheduling, and other shared services for the cloud. The Controller node has the dashboard, the image store, and the identity service. Additionally, Nova compute management service as well as the Neutron server are also configured in this node.
-
Compute node – node where VM instances, also known as Nova compute instances, are installed. The node runs the compute daemon that manages these VM instances.
-
Storage node – node that hosts the data.
This three-node architecture is only one way of deploying OpenStack on multiple systems. Because of its flexibility, you can distribute OpenStack components in other ways than this architecture. Thus, you must plan the cloud configuration before you begin installation. For information that would guide your planning, refer to Planning for an OpenStack Configuration.
Note - To partition a single Oracle SPARC server and configure multinode OpenStack on the server running OVM Server for SPARC (LDoms), see Multi-node Solaris 11.2 OpenStack on SPARC Servers. The article specifically refers to the Havana version of OpenStack. However, the general steps also apply to the current version.
The following figure shows a high-level view of the architecture described in this chapter.
Figure 2 Three-Node Configuration Reference Architecture
This figure uses Cinder to illustrate the Storage node. However, the Swift object storage service can be similarly configured.
In Oracle Solaris, the elastic virtual switch (EVS) forms the back end for OpenStack networking. EVS facilitates communication between VM instances that are either on VLANs or VXLANs. The VM instances can be on the same Compute node or across multiple Compute nodes. For more information about EVS, refer to Managing Network Virtualization and Network Resources in Oracle Solaris about the virtual switch. This book is in your Oracle Solaris version's library in Operating Systems Documentation.
In order for the different nodes to communicate with one another, the SSH public keys of evsuser, neutron, and root in the Controller node must be in each of the evsuser's authorized_keys file in all configured Compute nodes. Refer to the following image that shows the distribution of the SSH public keys. The image assumes that multiple Compute nodes have been configured.
Figure 3 EVS Controller SSH Key Distribution
For a list of OpenStack configuration parameters that are useful for OpenStack deployments on Oracle Solaris systems, see Common OpenStack Configuration Files and Services.