Hi, On Fri, 23 Aug 2013 10:41:21 +0200 Ferenc Wagner <[email protected]> wrote: > Arnold Krille <[email protected]> writes: > > On a side-note: I made the (sad) experience that its easier to > > configure such stuff outside of pacemaker/corosync and use the > > cluster only for the reliable ha things. > What do you mean by "reliable"? What did you experience (if you can > put it in a few sentences)?
I did use pacemaker to manage several things: 1) drbd and vms and the dependencies between them. And the clones service of libvirt. 2) drbd for a directory of configuration for "central services" like dhcp, named and an apache2 for some services. These where in one group depending on the drbd-master. The second turned out to be less optimal than I thought: Everytime you want to change something on the dhcp or named configuration, you first have to check on which node its active. Then when you restart dhcp, it has to be done through pacemaker. And you shouldn't be in the shared-config directory with your shell as otherwise pacemaker might decide to move the resource on the restart and fail because the directory can't be unmounted and then fail the cluster and/or fence the node. With desastrous results for the terminal-server-vm running on that node affecting all the co-workers... I already dropped the central apache2 and named and replaced them by an instance configured by chef to be the same on all nodes. Additionally the services aren't controlled by pacemaker anymore. So named is still available when I shut down the cluster for maintainance. And being able to run named on all three nodes is better then running it only on the two nodes sharing the configuration-drbd. Next thing to do is have dhcp configured by chef and take out of this group. Then the group will be empty:-) Additionally pacemaker gets slower in its behaviour the more resources you have. And when its 10-15 virtual machines each with one or more drbd-resources, well, currently its 63 resources pacemaker is watching... tl;dr: pacemaker is pretty cool at making sure the defined resources are running. But the simplier your resources are, the better. One vm depending on one or two drbd-masters is great. Synchronizing configuration and managing complicated dependencies can be done with pacemaker but there are better things to spend your time with. > > Configuring several systems into a sane state is more a job for > > configuration-management such as chef, puppet or at least csync2 (to > > sync the configs). > I'm not a big fan of configuration management systems, but they > probably have their place. None is present in the current setup, > though, so setting one up for bridge configuration seemed more > complicated than extending the cluster. We'll see... While automation has its advantage just by the fact that is automation, what made it appealing for us is the repeatability. If the automation has proven to work once in your setup, its easily portable to the clients setup. Even more so if the initial prove of "working" was in your test-setup and then re-used in your own production setup. And then re-used on the clients network... Take a look at Chef or Puppet or Ansible, its worth the time. Have fun, Arnold PS: Sorry, it became it bit longer.
signature.asc
Description: PGP signature
_______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
