This section discusses some preliminary considerations before you implement the multinode OpenStack configuration.
In a multinode configuration, you would use multiple network interfaces to service the different subnets that you create for the cloud. Ensure that you have prepared host names for these interfaces. Include these names and their IP addresses in the systems' /etc/hosts file or in the DNS configuration.
For example, you might create the following host names to handle different types of network traffic.
host-on for the OpenStack network that hosts administrative and API traffic.
host-tn for the project network that hosts traffic between Compute nodes and the L3 router.
host-en for the external network traffic.
When you configure the OpenStack services in different nodes, create variables to facilitate the task, such as the following examples:
$CONTROLLER_ADMIN_NODE - the host name of the interface or IP address in the Controller node to which OpenStack administrative services are attached.
$CONTROLLER_ADMIN_NODE_IP - the IP address of the Controller port that handles the OpenStack administrative services and traffic.
$COMPUTE_ADMIN_NODE_IP - the IP address of the Compute port that handles the OpenStack administrative services and traffic.
$VOLUME_IP - the host name of the Storage node.
Passwords are also required in the configuration processes. The following is a sample list of passwords you need to prepare.
Root password for the MySQL database
Password of the user guest of RabbitMQ
Password of user admin
Database passwords of the OpenStack services:
Identity service
Image service
Compute service
Dashboard database
Block storage database
Networking database
Orchestration database
Passwords of OpenStack service users:
glance
nova
cinder
neutron
heat
To quickly populate the Keystone database, you can use a sample script /usr/demo/openstack/keystone/sample_data.sh. The script performs the following basic tasks to help you get started:
Creates the following initial projects:
service under which basic or core services are created.
demo under which the user admin is created with secrete as the default password.
Populates the Keystone database.
Creates the following core services with corresponding user names and passwords.
cinder
ec2
glance
keystone
neutron
nova
swift
The corresponding user names and passwords are identical with the service names. For example, cinder is the user name and password for the Cinder service, ec2 for the ec2 service, and so on. These passwords are publicly known and therefore insecure. For a production setting, you should create customized passwords to replace these default ones in the script. Optionally, you can set a single password for all services in the script. Apply all the necessary changes to the script before you run it to bootstrap Keystone.
Throughout this document, the procedures assume that except for passwords, the sample data script is used without revision and all script's default settings are applied to the cloud configuration.
A major part of OpenStack configuration involves editing the components' configuration files. In this document, only selected parameters are identified for configuration in each *.conf or *.ini file. These selected parameters are the minimum required to make the cloud configuration work. However, review the entire contents of each configuration file to ensure that all the parameters relevant to your specific cloud setup are properly configured.
To better manage memory use between ZFS and applications in Oracle Solaris 11, set the usr_reserve_hint_pct parameter on the node, as shown in the following example:
# echo "set user_reserve_hint_pct=80" >>/etc/system.d/site:kernel-zones-reserve # reboot
where site can refer to your company.
Set this parameter on the different OpenStack nodes as well.
For more information about this parameter, log in to your MOS account in https://support.oracle.com and review Document 1663862.1, Memory Management Between ZFS and Applications in Oracle Solaris 11.2.