5.0 KiB
Highly available Identity API
You should be familiar with OpenStack Identity service before proceeding, which is used by many services.
Making the OpenStack Identity service highly available in active / passive mode involves:
identity-pacemaker
identity-config-identity
identity-services-config
Add OpenStack Identity resource to Pacemaker
SUSE
SUSE Enterprise Linux and SUSE-based distributions, such as openSUSE, use a set of OCF agents for controlling OpenStack services.
You must first download the OpenStack Identity resource to Pacemaker by running the following commands:
# cd /usr/lib/ocf/resource.d # mkdir openstack # cd openstack # wget https://git.openstack.org/cgit/openstack/openstack-resource-agents/plain/ocf/keystone # chmod a+rx *
You can now add the Pacemaker configuration for the OpenStack Identity resource by running the
crm configure
command to connect to the Pacemaker cluster. Add the following cluster resources:clone p_keystone ocf:openstack:keystone \ params config="/etc/keystone/keystone.conf" os_password="secretsecret" os_username="admin" os_tenant_name="admin" os_auth_url="http://10.0.0.11:5000/v2.0/" \ op monitor interval="30s" timeout="30s"
This configuration creates
p_keystone
, a resource for managing the OpenStack Identity service.crm configure
supports batch input so you may copy and paste the above lines into your live Pacemaker configuration, and then make changes as required. For example, you may enter editp_ip_keystone
from thecrm configure
menu and edit the resource to match your preferred virtual IP address.After you add these resources, commit your configuration changes by entering
commit
from thecrm configure
menu. Pacemaker then starts the OpenStack Identity service and its dependent resources on all of your nodes.
Red Hat
For Red Hat Enterprise Linux and Red Hat-based Linux distributions, the process is simpler as they use the standard Systemd unit files.
# pcs resource create openstack-keystone systemd:openstack-keystone --clone interleave=true
Configure OpenStack Identity service
Edit the
keystone.conf
file to change the values of thebind(2)
parameters:bind_host = 10.0.0.12 public_bind_host = 10.0.0.12 admin_bind_host = 10.0.0.12
The
admin_bind_host
parameter lets you use a private network for admin access.To be sure that all data is highly available, ensure that everything is stored in the MySQL database (which is also highly available):
[catalog] driver = keystone.catalog.backends.sql.Catalog ... [identity] driver = keystone.identity.backends.sql.Identity ...
If the Identity service will be sending ceilometer notifications and your message bus is configured for high availability, you will need to ensure that the Identity service is correctly configured to use it. For details on how to configure the Identity service for this kind of deployment, see
shared-messaging
.
Configure OpenStack services to use the highly available OpenStack Identity
Your OpenStack services must now point their OpenStack Identity configuration to the highly available virtual cluster IP address rather than point to the physical IP address of an OpenStack Identity server as you would do in a non-HA environment.
For OpenStack Compute, for example, if your OpenStack Identity service IP address is 10.0.0.11, use the following configuration in your
api-paste.ini
file:auth_host = 10.0.0.11
You also need to create the OpenStack Identity Endpoint with this IP address.
Note
If you are using both private and public IP addresses, you should create two virtual IP addresses and define your endpoint like this:
$ openstack endpoint create --region $KEYSTONE_REGION \ $service-type public http://PUBLIC_VIP:5000/v2.0 $ openstack endpoint create --region $KEYSTONE_REGION \ $service-type admin http://10.0.0.11:35357/v2.0 $ openstack endpoint create --region $KEYSTONE_REGION \ $service-type internal http://10.0.0.11:5000/v2.0
If you are using the horizon dashboard, edit the
local_settings.py
file to include the following:OPENSTACK_HOST = 10.0.0.11