[kolla-ansible][xena] Cell database HA/redundancy?

Norrie, Andrew Andrew.Norrie at cgg.com
Mon Jun 6 14:13:22 UTC 2022


Hi Mark,

Thanks for the reply.

I'll look into the HAProxy "custom config" as suggested and using different ports for the cell databases.
Maybe that can be worked in.

We are expanding our OpenStack/kolla-ansible personnel/knowledge so will look into the possibility for
us to contribute as reviewers/testers as a start.

Best regards .... Andrew

From: Mark Goddard <mark at stackhpc.com>
Sent: Monday, June 6, 2022 2:22 AM
To: Norrie, Andrew <Andrew.Norrie at cgg.com>
Cc: openstack-discuss at lists.openstack.org
Subject: Re: [kolla-ansible][xena] Cell database HA/redundancy?



On Fri, 3 Jun 2022 at 14:10, Norrie, Andrew <Andrew.Norrie at cgg.com<mailto:Andrew.Norrie at cgg.com>> wrote:

Hi,

We are currently planning some large OpenStack deployments utilizing kolla-ansible and
I'm curious what folks are doing with the cell database HA/redundancy.

With kolla-ansible (xena) it appears that a loadbalancer setup is only allowed for the
default database shard (shard 0)... reference: https://docs.openstack.org/kolla-ansible/latest/reference/databases/mariadb-guide.html<https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.openstack.org%2Fkolla-ansible%2Flatest%2Freference%2Fdatabases%2Fmariadb-guide.html&data=05%7C01%7CAndrew.Norrie%40cgg.com%7Cf493c7380a8342b0eb9408da4795b553%7C307ea68275e14701a1146c42f9ff0d24%7C0%7C0%7C637901005570096176%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QvBz9RObPfwW3PsIeM1whZjaT2LOwrj5Iylgh2wfeTo%3D&reserved=0>

If we are setting up separate cell database shards with Galera, I'm wondering if there is a convenient work-around or configuration for implementation of HA for these cell databases.

In the inventory group_vars directory you can specify the group variables (for each cell database) as:

nova_cell_database_address:
nova_cell_database_group:

but these aren't virtual IP hosts/addresses (non default db shard). This works perfectly fine with
a single server cell database but not Galera. If that db server goes down the cell instance information is lost.


Hi Andrew,

You are correct - only the first shard is load balanced. The sharding feature was actually just the first patch in a series intended to support proxysql. I believe this would add the functionality you are looking for. In fact, the proposed test case for proxysql in our CI is a multi-cell deployment.

Here is the patch series:

https://review.opendev.org/q/topic:proxysql<https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.opendev.org%2Fq%2Ftopic%3Aproxysql&data=05%7C01%7CAndrew.Norrie%40cgg.com%7Cf493c7380a8342b0eb9408da4795b553%7C307ea68275e14701a1146c42f9ff0d24%7C0%7C0%7C637901005570096176%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ooeBJE5Wsxuz1yNR%2F94Nk4ZK7wEx8nv4Jztl6Tk%2BbAg%3D&reserved=0>

Unfortunately it has been stuck for a while, largely due to core reviewer bandwidth. The author is Michael Arbet, who is often on IRC as kevko. I'd suggest registering your interest in these patches via gerrit, and at one of the weekly kolla IRC meetings (this week is cancelled due to the summit). If you have time available, then testing and providing reviews could help to get the patches moving.

In the meantime, you can configure HAProxy to load balance additional services, by placing an HAProxy config snippet in /etc/kolla/config/haproxy/services.d/*.cfg.

Regards,
Mark

Many thanks ... Andrew
________________________________
"This e-mail and any accompanying attachments are confidential. The information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution, or use of the email by others is strictly prohibited. If you are not the intended recipient, you must not review, disclose, copy, distribute or use this e-mail; please delete it from your system and notify the sender immediately."
________________________________
"This e-mail and any accompanying attachments are confidential. The information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution, or use of the email by others is strictly prohibited. If you are not the intended recipient, you must not review, disclose, copy, distribute or use this e-mail; please delete it from your system and notify the sender immediately."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220606/7d38573f/attachment-0001.htm>


More information about the openstack-discuss mailing list