[ClusterLabs] [EXT] Clarification on resource groups

[Eugen Block]

Thanks for your response.

Maybe I didn't explain myself well enough, I can go into more detail  
if necessary. I wanted to focus on resource groups first. But let me  
give an example from a recent upgrade that didn't go as smooth as  
planned.

We have a virtual IP colocated with haproxy, which redirects  
(OpenStack) API calls to the backend servers. Since there are multiple  
instances of those API services running, the services are still  
responsive and functioning properly.
So I put one node in maintenance mode to be able to stop all the  
systemd units wrt OpenStack, but not Galera and RabbitMQ. This node  
didn't have the VIP at the time. When I was done with the first node,  
everything was still good. But putting the node with the VIP into  
maintenance mode was a mistake:

During the system update there were also updates for network related  
packages (I hadn't noticed that on the first node), leading to a  
restart of the network service, causing the VIP to vanish. But since  
pacemaker couldn't move the resource, we had an API outage for  
OpenStack. To avoid that in the future, I will only put some of the  
resources into maintenance mode, not all of them. That way pacemaker  
will be able to move the VIP and HAProxy to the already upgraded node,  
so there will only be a tiny disruption, but most clients won't  
notice. I successfully tested that behavior on a test cloud, hence I'm  
confident that this is the right approach in my case.

If I put the entire cluster into maintenance mode, the VIP wouldn't be  
moved away when the network gets interrupted, that would cause a  
client disruption.

Thanks!
Eugen


Zitat von "Windl, Ulrich" <u.windl at ukr.de>:

> Hi!
>
> Assuming you know what "location" refers to. What you are doing  
> makes very little sense IMHO:
> When working on a service that needs some IP, it makes little sense  
> to put the service in maintenance mode, but not the IP:
> Imagine something bad happens to the network and the cluster wants  
> to move the IP while you are working on the service. Would you want  
> that to happen? Also (as I see it), to move the group, the cluster  
> would stop the service first, but when it's in maintenance mode, it  
> can't. So it can't move the group (and thus the IP neither).
> Pertsonally I put the cluster in maintenance mode as a whole,  
> preferably for a rather short time. Unless services fail very  
> frequently, this seems to be a safe mode of operation to me.
>
> Kind regards,
> Ulrich Windl
>
>> -----Original Message-----
>> From: Users <users-bounces at clusterlabs.org> On Behalf Of Eugen Block
>> Sent: Monday, January 13, 2025 1:17 PM
>> To: users at clusterlabs.org
>> Subject: [EXT] [ClusterLabs] Clarification on resource groups
>>
>> Hi,
>>
>> I'm hoping to get some clarification on my understanding of resource
>> groups [0]. It states:
>>
>> > One of the most common elements of a cluster is a set of resources
>> > that need to be located together, start sequentially, and stop in
>> > the reverse order.
>>
>> Especially the "located together" attribute confuses me.
>>
>> I'll try to provide some context:
>> I have a couple of systemd services as clones and some multi-state
>> resources such as galera and rabbitmq, running on two pacemaker nodes.
>> In case of an upgrade or any kind of maintenance, I want to use the
>> maintenance mode for some resources, but not all of them. For example,
>> I want the virtual IP, galera and rabbitmq to be still managed while
>> the rest is in maintenance mode. So currently, I would run a for loop
>> on the systemd services only, putting them into maintenance. This way,
>> if the network stack is updated or something, the virtual IP would be
>> moved to the other node. IIUC, this is not covered by the resource
>> groups, is it?
>>
>> Or should I have used it when building the cluster from scratch,
>> creating groups containing my systemd services as primitives? And then
>> clone a group?
>>
>> Is there another way of achieving that? I'd appreciate any comments!
>>
>> Thanks!
>> Eugen
>>
>> [0]
>> https://clusterlabs.org/projects/pacemaker/doc/2.1/Pacemaker_Explained/
>> singlehtml/index.html#group-resources
>>
>> _______________________________________________
>> Manage your subscription:
>> https://lists.clusterlabs.org/mailman/listinfo/users
>>
>> ClusterLabs home: https://www.clusterlabs.org/
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users
>
> ClusterLabs home: https://www.clusterlabs.org/