Hi! So did you configure anything in the cluster yet? As I understand it the virtual IP is a floating resource, but who needs that? Are galera and rabit also "floating" resources? As I understand it cinder,nova, and neutron run on both nodes independently; is that right?
I was expecting to see a configuration with primitves, colocations and orderings, etc. Basically a group is just some syntactic sugar or colocation and ordering, while the later are more flexible. Kind regards, Ulrich Windl > -----Original Message----- > From: Users <users-boun...@clusterlabs.org> On Behalf Of Eugen Block > Sent: Friday, January 31, 2025 3:16 PM > To: Cluster Labs - All topics related to open-source clustering welcomed > <users@clusterlabs.org> > Subject: [EXT] Re: [ClusterLabs] Re: Clarification on resource groups > > Hi, > > thanks again for taking the time to look into this, I appreciate it! > Currently, I don't have any resource groups. I wanted to understand if > resource groups can achieve what I currently do with a script. But I > have the impression that they cannot. I can still try to clarify more, > I'll only a few services to keep it brief. > > controller01: > - virtual-ip > - galera > - rabbit > - clone-cinder (systemd) > - clone-nova (systemd) > - clone-neutron (systemd) > > controller02: > - galera > - rabbit > - clone-cinder (systemd) > - clone-nova (systemd) > - clone-neutron (systemd) > > The systemd services are multi-active. Now I would like to put only > the cloned resources into maintenance mode, not the entire node. I > thought I could define a resource group containing only the systemd > services, so I could put only them into maintenance mode. That way, > when controller01 would lose the virtual-ip, it could be moved to > controller02. But the cloned resources would still be unmanaged so I > could upgrade them safely. I don't even want to move the group, just > put it into maintenance mode since the remaining node still has an > active group of systemd resources. > But from my current understanding, I would have had to create those > groups during cluster bootstrap, maybe I misunderstood though. I'm > fine with my script solution for the time being, I was just curious if > this scenario was already covered by pacemaker. > > Thanks, > Eugen > > Zitat von "Windl, Ulrich" <u.wi...@ukr.de>: > > > Hi! > > > > Maybe you should show the resources and their dependencies. If the > > VIP is in a group, what else is in that group? > > In my first reading I thought you want to manage one resource in a > > group, but still want the group to move. Is that right? > > > > Kind regards, > > Ulrich Windl > > > >> -----Original Message----- > >> From: Users <users-boun...@clusterlabs.org> On Behalf Of Eugen Block > >> Sent: Monday, January 27, 2025 3:41 PM > >> To: Cluster Labs - All topics related to open-source clustering welcomed > >> <users@clusterlabs.org> > >> Subject: [EXT] Re: [ClusterLabs] Clarification on resource groups > >> > >> 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.wi...@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-boun...@clusterlabs.org> On Behalf Of Eugen > Block > >> >> Sent: Monday, January 13, 2025 1:17 PM > >> >> To: users@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/ > >> > >> > >> > >> _______________________________________________ > >> 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/ > > > > _______________________________________________ > 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/
