Re: [ClusterLabs] Best DRBD Setup
On Wed, 2023-04-26 at 21:12 +0200, Brian Jenkins wrote: > Hi all > > I’ve been working on my home cluster setup for a while now and tried > varying setups for DRBD resources and finally settled on one that I > think is the best but I’m still not completely satisfied with the > results. Biggest question is, did I set this up in the best way? Any > advice would be appreciated. I have multiple servers setup in groups > and the DRBDs are in separate clones like below. I added constraints > to hopefully ensure things work together well. If you have any > questions to clarify my setup let me know. > > >* Resource Group: git-server: > * gitea-mount (ocf:heartbeat:Filesystem): Started > node1 > * git-ip(ocf:heartbeat:IPaddr2): Started node1 > * gitea (systemd:gitea): Started node1 > * backup-gitea (systemd:backupgitea.timer): Started > node1 > * Resource Group: pihole-server: > * pihole-mount (ocf:heartbeat:Filesystem): Started > node2 > * pihole-ip (ocf:heartbeat:IPaddr2): Started node2 > * pihole-ftl(systemd:pihole-FTL):Started node2 > * pihole-web(systemd:lighttpd): Started node2 > * pihole-cron (ocf:heartbeat:symlink): Started > node2 > * pihole-backup (systemd:backupDRBD@pihole.timer): > Started node2 > * Clone Set: drbd-gitea-clone [drbd-gitea] (promotable): > * Promoted: [ node1 ] > * Unpromoted: [ node2 node3 node4 node5 ] > * Clone Set: drbd-pihole-clone [drbd-pihole] (promotable): > * Promoted: [ node2 ] > * Unpromoted: [ node1 node3 node4 node5 ] > > Ordering Constraints: > start drbd-gitea-clone then start gitea-mount (kind:Mandatory) > start drbd-pihole-clone then start pihole-mount (kind:Mandatory) You want promote then start; with this, the mounts can start before DRBD is promoted. It's best practice to refer to the group in constraints rather than a member, but it shouldn't be a problem. > > Colocation Constraints: > pihole-server with drbd-pihole-clone (score:INFINITY) (rsc- > role:Started) (with-rsc-role:Promoted) > git-server with drbd-gitea-clone (score:INFINITY) (rsc- > role:Started) (with-rsc-role:Promoted) > > My setup is on five raspberry pis running ubuntu server 22.10 with: > pacemaker 2.1.4-2ubuntu1 > pcs 0.11.3-1ubuntu1 > drbd 9.2.2-1ppa1~jammy1 > > Overall the setup works but it seems quite fragile. I suffer from > lots of fencing whenever I reboot a server and it doesn’t want to > restart correctly. Another thing I have noticed is that it will > sometimes take as long as 10-12 minutes to mount one of the DRBD > filesystems (XFS) so I have extended the start timeout for each *- > mount to 15 minutes. > > Thanks in advance for any advice to improve the setup. > > Brian -- Ken Gaillot ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
[ClusterLabs] Best DRBD Setup
Hi all I’ve been working on my home cluster setup for a while now and tried varying setups for DRBD resources and finally settled on one that I think is the best but I’m still not completely satisfied with the results. Biggest question is, did I set this up in the best way? Any advice would be appreciated. I have multiple servers setup in groups and the DRBDs are in separate clones like below. I added constraints to hopefully ensure things work together well. If you have any questions to clarify my setup let me know. * Resource Group: git-server: * gitea-mount (ocf:heartbeat:Filesystem): Started node1 * git-ip (ocf:heartbeat:IPaddr2): Started node1 * gitea (systemd:gitea): Started node1 * backup-gitea (systemd:backupgitea.timer): Started node1 * Resource Group: pihole-server: * pihole-mount (ocf:heartbeat:Filesystem): Started node2 * pihole-ip (ocf:heartbeat:IPaddr2): Started node2 * pihole-ftl (systemd:pihole-FTL): Started node2 * pihole-web (systemd:lighttpd): Started node2 * pihole-cron (ocf:heartbeat:symlink): Started node2 * pihole-backup (systemd:backupDRBD@pihole.timer): Started node2 * Clone Set: drbd-gitea-clone [drbd-gitea] (promotable): * Promoted: [ node1 ] * Unpromoted: [ node2 node3 node4 node5 ] * Clone Set: drbd-pihole-clone [drbd-pihole] (promotable): * Promoted: [ node2 ] * Unpromoted: [ node1 node3 node4 node5 ] Ordering Constraints: start drbd-gitea-clone then start gitea-mount (kind:Mandatory) start drbd-pihole-clone then start pihole-mount (kind:Mandatory) Colocation Constraints: pihole-server with drbd-pihole-clone (score:INFINITY) (rsc-role:Started) (with-rsc-role:Promoted) git-server with drbd-gitea-clone (score:INFINITY) (rsc-role:Started) (with-rsc-role:Promoted) My setup is on five raspberry pis running ubuntu server 22.10 with: pacemaker 2.1.4-2ubuntu1 pcs 0.11.3-1ubuntu1 drbd 9.2.2-1ppa1~jammy1 Overall the setup works but it seems quite fragile. I suffer from lots of fencing whenever I reboot a server and it doesn’t want to restart correctly. Another thing I have noticed is that it will sometimes take as long as 10-12 minutes to mount one of the DRBD filesystems (XFS) so I have extended the start timeout for each *-mount to 15 minutes. Thanks in advance for any advice to improve the setup. Brian___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] How to block/stop a resource from running twice?
On Wed, 2023-04-26 at 17:05 +, fs3000 via Users wrote: > --- Original Message --- > On Monday, April 24th, 2023 at 10:08, Andrei Borzenkov < > arvidj...@gmail.com> wrote: > > > > On Mon, Apr 24, 2023 at 11:52 AM Klaus Wenninger > > kwenn...@redhat.com wrote: > > > > > The checking for a running resource that isn't expected to be > > > running isn't done periodically (at > > > least not per default and I don't know a way to achieve that from > > > the top of my mind). > > > > op monitor role=Stopped interval=20s > > Thanks a lot for the tip. It works, Not perfect, but that's fine. > When it detects the service is also active on a second node, it stops > the service on all nodes, and restarts the service on the first node. > Would be better if only it stopped the service on the second none, > leaving the service on the first node untouched. I understand this is > due to the multiple-active setting however: > > > What should the cluster do if it ever finds the resource active on > more than one node? Allowed values: > > - block: mark the resource as unmanaged > - stop_only: stop all active instances and leave them that way > - stop_start: stop all active instances and start the resource in one > location only > > DEFAULT: stop_start > > > From: > https://clusterlabs.org/pacemaker/doc/deprecated/en-US/Pacemaker/1.1/html/Pacemaker_Explained/s-resource-options.html Since Pacemaker 2.1.4, multiple-active can be set to "stop_unexpected" to do what you want. It's not the default because some services may no longer operate correctly if an extra instance was started on the same host, so it's on the admin to be confident their services can handle it. -- Ken Gaillot ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] [EXT] manner in which cluster migrates VirtualDomain - ?
AFAIR pacemaker tries to migrate all at once (which is not the best idea performance-wise), but you can limit the number of concurrent migrations… migration-limit -1 (unlimited) The number of migration jobs that the cluster is allowed to execute in parallel on a node. From: Users On Behalf Of lejeczek via Users Sent: Tuesday, April 18, 2023 2:58 PM To: users@clusterlabs.org Cc: lejeczek Subject: [EXT] [ClusterLabs] manner in which cluster migrates VirtualDomain - ? Hi guys. When it's done by the cluster itself, eg. a node goes 'standby' - how do clusters migrate VirtualDomain resources? Do users have any control over it and if so then how? I'd imagine there must be some docs - I failed to find Especially in large deployments one obvious question would be - I'm guessing as my setup is rather SOHO - can VMs migrate in sequence or it is(always?) a kind of 'swarm' migration? many thanks, L. ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] How to block/stop a resource from running twice?
--- Original Message --- On Monday, April 24th, 2023 at 10:08, Andrei Borzenkov wrote: > On Mon, Apr 24, 2023 at 11:52 AM Klaus Wenninger kwenn...@redhat.com wrote: > > > The checking for a running resource that isn't expected to be running isn't > > done periodically (at > > least not per default and I don't know a way to achieve that from the top > > of my mind). > > > op monitor role=Stopped interval=20s Thanks a lot for the tip. It works, Not perfect, but that's fine. When it detects the service is also active on a second node, it stops the service on all nodes, and restarts the service on the first node. Would be better if only it stopped the service on the second none, leaving the service on the first node untouched. I understand this is due to the multiple-active setting however: What should the cluster do if it ever finds the resource active on more than one node? Allowed values: - block: mark the resource as unmanaged - stop_only: stop all active instances and leave them that way - stop_start: stop all active instances and start the resource in one location only DEFAULT: stop_start From: https://clusterlabs.org/pacemaker/doc/deprecated/en-US/Pacemaker/1.1/html/Pacemaker_Explained/s-resource-options.html ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
[ClusterLabs] PAF / pgsqlms - lags behind in terms of RA specs?
Hi guys. anybody here use PAF with up-to-date Centos? I see this RA fails from cluster perspective, I've failed a report over at github no comment there so thought I'd ask around. many thanks, L.___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
