Chapter 3. Installing and configuring Instance HA

From Red Hat OpenStack Platform 13 and later, Instance HA is deployed and configured with the director. However, there are a few additional steps that you need to perform to prepare for the deployment.

Note

You can configure Instance HA for your overcloud at any time after creating the undercloud.

  1. Add the ComputeInstanceHA role to your roles data file and regenerate the file. For example: 

    $ openstack overcloud roles generate -o ~/my_roles_data.yaml Controller Compute ComputeInstanceHA

    The ComputeInstanceHA role includes all the services in the default Compute role as well as the ComputeInstanceHA and the PacemakerRemote services. For general information about custom roles and about the roles-data.yaml, see the Roles section in the Advanced Overcloud Customization guide.

  2. Create the compute-instance-ha flavor to tag Compute nodes that you want to designate for Instance HA. For example: 

    $ source ~/stackrc
$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 compute-instance-ha
$ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="compute-instance-ha" compute-instance-ha

  3. Tag each Compute node that you want to designate for Instance HA with the compute-instance-ha profile. 

    $ openstack baremetal node set --property capabilities='profile:compute-instance-ha,boot_option:local' <NODE UUID>

  4. Map the ComputeInstanceHA role to the compute-instance-ha flavor by creating an environment file with the following content: 

    parameter_defaults:
  OvercloudComputeInstanceHAFlavor: compute-instance-ha

  5. Enable fencing on all Controller and Compute nodes in the overcloud by creating an environment file with fencing information. Make sure to create the environment file in an accessible location, such as ~/templates. For example: 

    parameter_defaults:
  EnableFencing: true
  FencingConfig:
    devices:
    - agent: fence_ipmilan
      host_mac: 00:ec:ad:cb:3c:c7
      params:
        login: admin
        ipaddr: 192.168.24.1
        ipport: 6230
        passwd: password
        lanplus: 1
    - agent: fence_ipmilan
      host_mac: 00:ec:ad:cb:3c:cb
      params:
        login: admin
        ipaddr: 192.168.24.1
        ipport: 6231
        passwd: password
        lanplus: 1
    - agent: fence_ipmilan
      host_mac: 00:ec:ad:cb:3c:cf
      params:
        login: admin
        ipaddr: 192.168.24.1
        ipport: 6232
        passwd: password
        lanplus: 1
    - agent: fence_ipmilan
      host_mac: 00:ec:ad:cb:3c:d3
      params:
        login: admin
        ipaddr: 192.168.24.1
        ipport: 6233
        passwd: password
        lanplus: 1
    - agent: fence_ipmilan
      host_mac: 00:ec:ad:cb:3c:d7
      params:
        login: admin
        ipaddr: 192.168.24.1
        ipport: 6234
        passwd: password
        lanplus: 1

    For more information about fencing and STONITH configuration, see the Fencing the Controller Nodes section of the Advanced Overcloud Customization guide.

  6. By default, Instance HA uses shared storage. If you already defined shared storage separately, you can disable shared storage by adding a parameter to the environment file that you created in the previous step. 

    parameter_defaults:
  ExtraConfig:
    tripleo::instanceha::no_shared_storage: false

  7. Run the openstack overcloud deploy command with the -e option and specify all the environment files that you created, as well as the compute-instanceha.yaml environment file. For example: 

    $ openstack overcloud deploy -e <FLAVOR_ENV_FILE> <FENCING_ENV_FILE>  /usr/share/openstack-tripleo-heat-templates/environments/compute-instanceha.yaml
    Note

    Do not modify the compute-instanceha.yaml environment file.

After the deployment is complete, each Compute node should include a STONITH device and a GuestNode service.

3.1. Considerations for Shared Storage

Typically, Instance HA requires that you configure shared storage for disk images of instances. Therefore, if you attempt to use the no-shared-storage option, you might receive an InvalidSharedStorage error during evacuation, and the instances will not boot on another Compute node.

However, if all your instances are configured to boot from an OpenStack Block Storage (cinder) volume, you do not need to configure shared storage for the disk image of instances, and you can still evacuate all instances using the no-shared-storage option.

During evacuation, if your instances are configured to boot from a Block Storage volume, any evacuated instances should boot from the same volume on another Compute node. As a result, the evacuated instances immediately restart their jobs because the OS image and the application data are stored on the OpenStack Block Storage volume..