We've been tossing around ideas like this for many many years, its very cool that you've been able to make it a reality. I'm both excited and scared to see what people do with it :)
Good work! On 16/05/2013, at 4:17 AM, David Vossel <[email protected]> wrote: > Hi, > > I'm excited to announce the initial development phase of the Pacemaker Remote > daemon is complete and ready for testing in Pacemaker v1.1.10rc2 > > Below is the first draft of a deployment guide that outlines the initial > supported Pacemaker Remote use-cases and provides walk-through examples. > Note however that Fedora 18 does not have the pacemaker-remote subpackage rpm > available even though I do reference it in the documentation (this will be > changed in a future draft) You'll have to use the 1.1.10rc2 tag in github for > now. > > Documentation: > http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Remote/index.html > > For those of you unfamiliar with Pacemake Remote, the pacemaker_remote > service is a new daemon introduced in Pacemaker v1.1.10 that allows nodes not > running the cluster stack (pacemaker+corosync) to integrate into the cluster > and have the cluster manage their resources just as if they were a real > cluster node. This means that Pacemaker clusters are now capable of managing > both launching virtual environments (KVM/LXC) as well as launching the > resources that live within those virtual environments without requiring the > virtual environments to run pacemaker or corosync. > > Usage of the pacemaker_remote daemon is currently limited to virtual guests > such as KVM and Linux Containers, but several future enhancements to include > additional use-cases are in the works. These planned future enhancements > include the following. > > - Libvirt Sandbox Support > Once the libvirt-sandbox project is integrated with pacemaker_remote, we will > gain the ability to preform per-resource linux container isolation with very > little performance impact. This functionality will allow resources living on > a single node to be isolated from one another. At that point CPU and memory > limits could be set per-resource in the cluster dynamically just using the > cluster config. > > - Bare-metal Support > The pacemaker_remote daemon already has the ability to run on bare-metal > hardware nodes, but the policy engine logic for integrating bare-metal nodes > is not complete. There are some complications involved with understanding a > bare-metal node's state that virtual nodes don't have. Once this logic is > complete, pacemaker will be able to integrate bare-metal nodes in the same > way virtual remote-nodes currently are. Some special considerations for > fencing will need to be addressed. > > - Virtual Remote-node Migration Support > Pacemaker's policy engine is limited in its ability to perform live > migrations of KVM resources when resource dependencies are involved. This > limitation affects how resources living within a KVM remote-node are handled > when a live migration takes place. Currently when a live migration is > performed on a KVM remote-node, all the resources within that remote-node > have to be stopped before the migration takes place and started once again > after migration has finished. This policy engine limitation is fully > explained in this bug report, > http://bugs.clusterlabs.org/show_bug.cgi?id=5055#c3 > > -- > David Vossel <[email protected]> > irc: dvossel on irc.freenode.net > > _______________________________________________ > Pacemaker mailing list: [email protected] > http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org _______________________________________________ Pacemaker mailing list: [email protected] http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
