Re: [ClusterLabs] Coming in Pacemaker 1.1.17: container bundles
On 06/30/2017 12:10 PM, Valentin Vidic wrote: > On Fri, Mar 31, 2017 at 05:43:02PM -0500, Ken Gaillot wrote: >> Here's an example of the CIB XML syntax (higher-level tools will likely >> provide a more convenient interface): >> >> >> >> > > Would it be possible to make this a bit more generic like: > > > > so we have support for other container engines like rkt? The challenge is that some properties are docker-specific and other container engines will have their own specific properties. We decided to go with a tag for each supported engine -- so if we add support for rkt, we'll add a tag with whatever properties it needs. Then a would need to contain either a tag or a tag. We did consider a generic alternative like: ... ... But it was decided that using engine-specific tags would allow for schema enforcement, and would be more readable. The and tags were kept under because we figured those are essential to the concept of a bundle, and any engine should support some way of mapping those. ___ Users mailing list: Users@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Coming in Pacemaker 1.1.17: container bundles
On Fri, Mar 31, 2017 at 05:43:02PM -0500, Ken Gaillot wrote: > Here's an example of the CIB XML syntax (higher-level tools will likely > provide a more convenient interface): > > > > Would it be possible to make this a bit more generic like: so we have support for other container engines like rkt? -- Valentin ___ Users mailing list: Users@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
[ClusterLabs] pcs 0.9.159 released
I am happy to announce the latest release of pcs, version 0.9.159. Source code is available at: https://github.com/ClusterLabs/pcs/archive/0.9.159.tar.gz or https://github.com/ClusterLabs/pcs/archive/0.9.159.zip This is mainly a bug-fix release to 0.9.158. There is one new feature added and that is support for meta attributes in bundle resources. Complete change log for this release: ### Added - Option to create a cluster with or without corosync encryption enabled, by default the encryption is disabled ([rhbz#1165821]) - It is now possible to disable, enable, unmanage and manage bundle resources and set their meta attributes ([rhbz#1447910]) - Pcs now warns against using the `action` option of stonith devices ([rhbz#1421702]) ### Fixed - Fixed crash of the `pcs cluster setup` command when the `--force` flag was used ([rhbz#1176018]) - Fixed crash of the `pcs cluster destroy --all` command when the cluster was not running ([rhbz#1176018]) - Fixed crash of the `pcs config restore` command when restoring pacemaker authkey ([rhbz#1176018]) - Fixed "Error: unable to get cib" when adding a node to a stopped cluster ([rhbz#1176018]) - Fixed a crash in the `pcs cluster node add-remote` command when an id conflict occurs ([rhbz#1386114]) - Fixed creating a new cluster from the web UI ([rhbz#1284404]) - `pcs cluster node add-guest` now works with the flag `--skip-offline` ([rhbz#1176018]) - `pcs cluster node remove-guest` can be run again when the guest node was unreachable first time ([rhbz#1176018]) - Fixed "Error: Unable to read /etc/corosync/corosync.conf" when running `pcs resource create`([rhbz#1386114]) - It is now possible to set `debug` and `verbose` parameters of stonith devices ([rhbz#1432283]) - Resource operation ids are now properly validated and no longer ignored in `pcs resource create`, `pcs resource update` and `pcs resource op add` commands ([rhbz#1443418]) - Flag `--force` works correctly when an operation is not successful on some nodes during `pcs cluster node add-remote` or `pcs cluster node add-guest` ([rhbz#1464781]) ### Changed - Binary data are stored in corosync authkey ([rhbz#1165821]) - It is now mandatory to specify container type in the `resource bundle create` command - When creating a new cluster, corosync communication encryption is disabled by default (in 0.9.158 it was enabled by default, in 0.9.157 and older it was disabled) Thanks / congratulations to everyone who contributed to this release, including Ivan Devat, Ondrej Mular and Tomas Jelinek. Cheers, Tomas [rhbz#1165821]: https://bugzilla.redhat.com/show_bug.cgi?id=1165821 [rhbz#1176018]: https://bugzilla.redhat.com/show_bug.cgi?id=1176018 [rhbz#1284404]: https://bugzilla.redhat.com/show_bug.cgi?id=1284404 [rhbz#1386114]: https://bugzilla.redhat.com/show_bug.cgi?id=1386114 [rhbz#1421702]: https://bugzilla.redhat.com/show_bug.cgi?id=1421702 [rhbz#1432283]: https://bugzilla.redhat.com/show_bug.cgi?id=1432283 [rhbz#1443418]: https://bugzilla.redhat.com/show_bug.cgi?id=1443418 [rhbz#1447910]: https://bugzilla.redhat.com/show_bug.cgi?id=1447910 [rhbz#1464781]: https://bugzilla.redhat.com/show_bug.cgi?id=1464781 ___ Users mailing list: Users@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Question about STONITH for VM HA cluster in shared hosts environment
On 06/29/2017 07:23 PM, Ken Gaillot wrote: > On 06/29/2017 12:08 PM, Digimer wrote: >> On 29/06/17 12:39 PM, Andrés Pozo Muñoz wrote: >>> Hi all, >>> >>> I am a newbie to Pacemaker and I can't find the perfect solution for my >>> problem (probably I'm missing something), maybe someone can give me some >>> hint :) >>> >>> My scenario is the following: I want to make a HA cluster composed of 2 >>> virtual machines running on top of SHARED virtualization hosts. That is, >>> I have a bunch of hosts running multiple VMs, and I would like to create >>> an HA cluster with 2 VMs (Ubuntus running some app) running in >>> (different) hosts. >>> >>> About the resources, I have no problem, I'll configure some VIP and some >>> lsb services in a group. >>> >>> My concern is about the STONITH, I can't find the perfect config: >>> * If I disable STONITH I may have the split brain problem. >>> * If I enable STONITH with external/libvirt fence, I'll have a >>> single point of failure if the host with the Active VM dies, right? >>> (Imagine the host running that active VMs dies, the STONITH operation >>> from the other VM will fail and the switch-over will not happen, right?) >>> * I can't use a 'hardware' (ILO/DRAC) fence, because the host is >>> running a lot of VMs, not only the ones in HA cluster :( I can't reboot >>> it because of some failure in our HA. If for whatever reason, be it physically separated networks or the unwillingness to share the credentials with you / respective your VMs, you don't have access to the ILO/DRAC/powerswitch ... or even worse you don't even have access to VM-management for similar reasons going with SBD (Storage-Based Death) might be something to consider under certain circumstances. The usefulness of SBD stands and falls with the availability of a reliable watchdog on each of the cluster-nodes. Although it has storage in the name the really important part is a watchdog - in fact under certain circumstances there wouldn't even have to be (a) storage device(s). Anyway given that the implementation of the virtual watchdog in a VM is reliable enough - e.g. guarded by a hardware watchdog on the host - SBD can be used inside virtual machines as well. Basic idea that makes the difference in your case is that you don't have to have a positive feedback about a node being fenced but that you have something reliable enough in place so that if you don't have a reply within a certain time you can be sure the other side has committed suicide and thus has brought all resources down the hard way. SBD can run on a watchdog + pacemaker-quorum on 3 and up nodes, on a watchdog + cluster-membership + a disk on 2 and up nodes (very recent snapshot of SBD required) or without relying on input from the cluster on 3 disks. Of course the disks can be virtual as well as long as they are shared - and that is something you might rather get than access to VM-Management or even fencing-devices that kill the hosts. Regards, Klaus >>> >>> Is there an optimal configuration for such scenario? >>> >>> I think I'd rather live with the split brain problem, but I just want to >>> know if I missed any config option. >>> >>> Thanks in advance! >>> >>> Cheers, >>> Andrés >> You've realized why a production cluster on VMs is generally not >> recommended. :) >> >> If the project is important enough to make HA, then management needs to >> allocate the budget to get the proper hardware for the effort, I would >> argue. If you want to keep the services in VMs, that's fine, get a pair >> of nodes and make them an HA cluster to protect the VMs as the services >> (we do this all the time). >> >> With that, then you pair IPMI and switched PDUs for complete coverage >> (IPMI alone isn't enough, because if the host is destroyed, it will take >> the IPMI BMC with it). > To elaborate on this approach, the underlying hosts could be the cluster > nodes, and the VMs could be resources. If you make all the VMs into > resources, then you get HA for all of them. You can also run Pacemaker > Remote in any of the VMs if you want to monitor resources running inside > them (or move resources from one VM to another). > > Commenting on your original question, I'd point out that if pacemaker > chooses to fence one of the underlying hosts, it's not responding > normally, so any other VMs on it are likely toast anyway. You may > already be familiar, but you can set a fencing topology so that > pacemaker tries libvirt first, then kills the host only if that fails. > > ___ > Users mailing list: Users@clusterlabs.org > http://lists.clusterlabs.org/mailman/listinfo/users > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org ___ Users mailing list: Users@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.cluste
