Adding a region to a deployed topology

After you deploy your topology, you can add a region to your cloud environment to create or expand a multi-region cloud environment.

About this task

Each region is set up as a separate deployment that uses the same OpenStack Keystone server, but uses a different region and possibly a different hypervisor type. Use the following instructions to add a region to your cloud environment.

This example uses a single deployment server to manage all of the regions. However, you can use a separate deployment server for each region. If separate deployment servers are used, they must have the same version of IBM® Cloud Manager with OpenStack installed, but are allowed to have different fix pack levels. For more information about updates and release upgrades in these configurations, see Best practices for maintaining a multi-region cloud or test cloud.

To begin, you must prepare the first region as described.

Procedure

  1. Log in to the deployment system as the root user.
    This is the system where IBM Cloud Manager with OpenStack was installed.
  2. Copy the appropriate example cloud file as the base structure for your cloud deployment. Rename it for your cloud environment.
    example-multiregion-controller-n-compute-kvm-cloud.yml
  3. Change the required YAML attributes in your cloud file, your-cloud.yml.
    Note: There must be a space between the colon and the field value. For example, name: cloudname. If not, you receive an error.
    • Cloud Information (cloud): Customize the cloud information.
      1. name: Set the name for your cloud. The name cannot contain spaces or special characters. This name is also used as the OpenStack region name.
      2. password: Set the cloud administrator (admin) user's password. This value is not required or supported for the minimal topology. The minimal topology defaults the password to admin.
    • Node Information (nodes): Customize the information for each node system in your cloud. For the controller +n compute or distributed database topologies, you can copy the kvm_compute node section to include more KVM compute nodes in your cloud.
      1. name and description: Leave these set to the default values provided.
      2. fqdn: Set to the fully qualified domain name of the node system. The deployment system must be able to SSH by using the fully qualified domain name. You can also set to the public IP address, private IP address, or host name.
      3. password or identity_file: Set to the appropriate SSH root user authentication for the node system. You can use either a password or an SSH identity file for authentication.
      4. nics.management_network: Set to the management network interface card for the node system. This network is used for IBM Cloud Manager with OpenStack communication between the nodes in the cloud. The fqdn setting for the node must resolve to the IP address of this network. The default is eth0.
      5. nics.data_network: Set to the data network interface card for the node system. The default is eth1. If the node system does not have a second network interface card that can be used as a data network, then set to ~. Do not set to the same value as nics.management_network. Also, do not set to a network interface card that provides an alternative management network or an external network for the node, for example, a private or public IP address. A data network is required to use VLAN or Flat networks in your cloud.
    • First_region Information (first_region):
      1. first_region_topology_file: Your existing region topology file name. If you provide a topology file, you do not need to provide the following attributes. These attributes are overwritten by the attributes in an existing topology file.
      2. keystone_endpoint_host: The Keystone identity service endpoint host. Enter either the host fully qualified domain name or its IP address. There is one shared Keystone endpoint within the multi-region cloud. You can choose to provide this value or provide an existing topology file.
      3. shared_password_file: The password file that is used to store the necessary Keystone password and secrets. Copy the shared password file example, as the base structure for your shared password file, and change the passwords to your multi-region shared passwords. You can choose to provide this value or provide an existing topology file.
  4. Optional: Complete any optional customization by changing the appropriate YAML attributes in your cloud file, your-cloud.yml.
    1. Optional: Cloud Information (cloud): Customize the cloud information.
      • database_service_type: You can change the database that is used by OpenStack from DB2® (default) to MariaDB by setting this attribute to mariadb. You can also change the database to MySQL by setting this attribute to mysql. For more information about using MySQL, see Changing the database from DB2 (default) to MySQL. This attribute must be the same across the multiple regions. You can choose to provide the attribute type here or provide an existing topology file.
      • messaging_service_type: You can change the messaging queue that is used by OpenStack from RabbitMQ (default) to Qpid by setting this attribute to qpid. This attribute must be the same across the multiple regions. You can choose to provide the message service type here or provide an existing topology file.
      • self_service_portal and self_service_portal_node_name: IBM Cloud Manager with OpenStack features an easy to use self-service portal for cloud operations. You can disable the self-service portal cloud feature by setting the self_service_portal attribute to disabled and the self_service_portal_node_name attribute to ~. This attribute must be the same across the multiple regions. You can choose to provide self_service_portal or provide an existing topology file. If you enable the self-service portal feature, you must set self_service_portal_node_name to be your existing, shared self-service node region:node.
      • platform_resource_scheduler: IBM Cloud Manager with OpenStack features an enhanced OpenStack compute scheduler, IBM Platform Resource Scheduler. You can disable Platform Resource Scheduler and use the default OpenStack compute scheduler filters by setting this attribute to disabled. For more information about Platform Resource Scheduler, see Platform Resource Scheduler product information.
      • docker_controller_node_name and docker_compute_node_names: IBM Cloud Manager with OpenStack features container services. You can specify Docker compute nodes and controller node. For more information, see Docker cloud YAML configuration file.
      Note: If you are using the deployment server as one of the nodes in your cloud (not recommended), then you must use the Qpid messaging service type.
    2. Optional: Environment Information (environment): Customize the environment information.
      • ntp.servers: Set to the NTP servers that are accessible to your deployment. The list of NTP servers must be comma separated, for example, [your.0.ntpserver.com, your.1.ntpserver.com]. The default is [0.pool.ntp.org, 1.pool.ntp.org, 2.pool.ntp.org, 3.pool.ntp.org].
  5. (Optional) Check the detailed status of the IBM Cloud Manager with OpenStack services that are deployed.
    $ knife os manage services status --topology-file your-topology-name.json
    For more information about managing IBM Cloud Manager with OpenStack services, see Managing IBM Cloud Manager with OpenStack services.
  6. If the self-service portal is installed, restart the self-service portal.
    Restart the self-service portal service on the node where it is installed. Run the service sce restart command to restart the service. After you restart the service, you can add an OpenStack cloud connection for the additional region.

Results

You are ready to start using IBM Cloud Manager with OpenStack services in the new region.