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
