Miles Fidelman wrote: > Igor Chudov wrote: > >> I would like to know if there are relatively straightforward Linux >> based alternatives to DRBD and heartbeat. >> >> >> > It occurs to me that I've yet to see an actual answer to the original > poster's question. I've seen lots of dicussion about DRBD, heartbeat, > and pacemaker/corosync - but not a single alternative. > > Now I use DRBD/heartbeat/pacemaker myself - and it pretty much works for > me - but at the same time it's also somewhat overkill and complicated > for what I do (hot-failover of a couple of Xen VMs), and I'm somewhat > curious about whether there are alternatives. > > So far, in my own searching, all I've found is the Remus package that > comes with newer versions of Xen - but Remus seems awfully immature, and > I've yet to come across anybody using it in production (if I'm wrong, > can somebody please pipe up). > > Is it really the case that DRBD/heartbeat/pacemaker/corosync is really > the only solution in this space? > > Miles Fidelman > There are alternatives, they fit the general purpose of building a cluster, there is the RedHat Cluster Suite as an alternative to heartbeat, there are filesystems such as GFS2 and OCFS, you can consider them as alternatives to DRBD. Related to the RHCS however, it started using corosync with cman being a plugin for corosync. Anyways, you can find more information by Googling "chrissie caulfield redhat cman"
> DRBD/Pacemaker was complicated, documentation did not exist >> >> Oh really? >> You never saw http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >> or the linbit site? When I started working with Pacemaker, there was no Cluster from Scratch document, there was no how-to on the clusterlabs.org website about configuring resources via the crm shell or editing the XML. I needed to setup 4 nodes, 2 Active-Passive clusters running in geographically separate locations providing failover between sites. Despite the odds, I did the setup with Pacemaker, OpenAIS and DRBD, failover worked, everybody was happy. Steep learning curve? It all depends on what you consider as being steep, I for one took it as a challenge, not a chore and the best part of it is that I actually learned how this technology works in the process. I think that it's one thing to say there was no documentation and another thing to say you didn't read/follow the documentation. In both cases, having documentation or the lack thereof shouldn't be an impediment when trying to achieve a goal, but some people want the quick way in and out, don't want to go through all the steps. That's why, to make an analogy, in the certification world there is the term "paper [insert certification name here]". So you hear a lot about "paper CCNA", "paper MCSE", paper this, paper that, referring to a person that passed a certification, but does not possess the knowledge that the learning process of that particular certification should have bestowed upon him/her. It took me 11 months and two 900-page books with all the practice I could get to pass the CCNA and 6 years to get my RHCE, but on both of them, I passed on the first try. On the other hand, I know people that passed [insert low end certification name here] after cramming for one week on the exam results they got from the internet, always complain that copy+pasting the commands from tutorial x and y found on Google does not work as it says there and wonder why no one would hire them, even though they have [insert certification name here]. In the same sense, even having documentation is most of the time not enough, as the documentation would cover some general configuration examples, and not specific setups that users might require. So the documentation should provide a general overview of the configuration and by reading it one should know enough about the individual configuration components to build their own custom setup. Sorry for digressing away from the main topic. -- Dan FRINCU Systems Engineer CCNA, RHCE Streamwide Romania _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
