Upcoming High Availability Clustering miniconf at Linux Plumbers Conference

This year’s Linux Plumbers Conference is taking place November 3-5, in Cambridge, MA, United States. The CfP is already closed and the program is due any day now, but the co-located miniconference on high availability clustering is still accepting proposals. This is your chance to get involved!

So if you plan to attend Plumbers or just happen to be in the area, please submit your talk! Miniconference talks are not expected to be full-blown presentations. Instead, you can float an idea in just a 5-10 minute talk and then stimulate a vibrant group discussion.

Even if you are not attending, you can still help! We are always eager to hear from our user community. What HA problems are you currently facing that the existing Linux clustering stack does not solve? How well does your application integrate with HA? Where can we improve? What’s already good, and can be made better? What sucks?

Feel free to comment below. Or send us an email on one of the mailing lists. Or grab us in #linux-ha or #linux-cluster on freenode. Make yourself heard!

6 Responses to Upcoming High Availability Clustering miniconf at Linux Plumbers Conference

  1. Plumber Cambridge says:

    For all plumbing emergencies in Cambridge we can provide professional service within an hour and we are available 24 hours a day, 7 days a week. We specialise in all aspects of plumbing, including kitchen plumbing, boiler installation and servicing, bathroom plumbing, toilet plumbing, shower plumbing, drainage clearing & repairs, central heating, and radiator heating.

  2. Anonymous Coward says:

    The two biggest problems Linux-HA faces right now is the lack of documentation and the fragmentation of the cluster stack. Each makes the other more painful. With respect to the stack, there are problems like:

    1. Still too many overlapping parts of OpenAIS and Corosync. I understand the reasoning for the fork, but the execution/implementation has been dreadfully confusing.
    2. No unified consensus on what components should be in the stack. Every Linux distro has a different mix of packages to accomplish the goal, and even within single distributions there are many different mutually exclusive packages that do the same thing. It’s a mess. Which of the myriad package combinations should we be using from the choices available is very much an open-ended question, and you’ll get a different answer depending on who you ask, which distro you use, and what phase of the moon it is. These include: openais, heartbeat, corosync, pacemaker, cluster-glue, cluster-agents, fence-agents, stonith, cman, resource-agents, redhat-cluster-suite, cman, cpg, quorumd, mcp, and others, and that is in addition to all the clustering filesystem specific packages, which include gfs2, ocfs2, glusterfs, and so on.

    The above clusterfuck (pun intended) is further frustrating because of the lack of documentation. Have you seen the corosync.org? It’s mostly empty, and what’s there mostly references OpenAIS, adding to the overwhelming sense of confusion. In my opinion, the only thing holding back Linux-HA is Linux-HA. What’s needed is unified support of a clearly defined stack and decent documentation to support it. Clusters involve a lot of moving parts, and it’s critical that folks are crystal clear on exactly what those parts are and how they should be used. Otherwise, the mailing lists will continue to be full of the same endless cycle of frustrations and simple questions that get repeated over and over and over.

    • Florian Haas says:

      Thanks — I’ll not respond to the points you’re making for the time being, in the hope that others might comment without being pre-influenced by my own opinion.

      There’s actually no need at all to make such comments anonymously; everyone’s entitled to their own opinion — and even in case someone chooses to flame you to a crisp, it will be about what you say, not about who you are. If you choose to not identify yourself publicly, you might want to do so in private email. My address in on the “About me” page.

    • Tim Serong says:

      I understand that there is clearly a problem here, so I will try to address some of the issues you raise, starting with the second one.

      There is a unified consensus on the core components to use, at least going forwards, although it’s apparent that this isn’t being effectively communicated. These core components are corosync and pacemaker. The rest of the packages tend to vary from disto to distro (RHEL uses cman for example, while SLES does not), or on what features you need (right now, you need openais to run DLM and OCFS2, although eventually this will go away, and you will only need corosync).

      There is convergence happening between the RH and SUSE stacks (corosync + pacemaker as mentioned above), also the separate resource agents packages are in the process of being combined into a single upstream repository. Some of this is mentioned in the LPC2010 HA Etherpad that was produced while at LPC.

      Don’t get me wrong, I do understand that there is a lot of (potentially conflicting) information to assimilate, I’m just saying that things are now, or should be, moving in the right direction.

      As for documentation, this is a more curious issue. We do actually have some very good community documentation, including

      * Clusters from Scratch
      * The Linux-HA User’s Guide
      * The DRBD User’s Guide

      This is in addition to things like the SUSE Linux Enterprise High Availability Extension Guide, which is obviously specific to SLES, but does describe this cluster stack.

      My question to you would thus be: what happened when you went looking for documentation? I assume you didn’t just give up after reading the corosync.org site. Was the current documentation (mentioned above) impossible to find using google? Was it swamped by conflicting information? Because whatever roadblock is in place to finding and assimilating our documentation, it obviously needs to be removed somehow.

      • Anonymous Coward says:

        If a unified consensus exists, I agree it has not been effectively communicated. If we need several different stacks for different needs, that’s fine, but there needs to be an authoritative source of documentation clearly distinguishing what they are, and for which circumstances each is the appropriate choice. The Linux-HA User’s guide only goes over Heartbeat clusters, the Clusters from Scratch guide makes no mention of many of the available pieces of software being created by developers and package maintainers (e.g., cman, cpg, quorumd, and others), and the DRBD users guide mentions utilities that are not referenced in either of the aforementioned (e.g., ccsd). In fact, that’s precisely the problem – there is no consistency in the information being put forth (which one could interpret as being “conflicting”, as you mention). Everybody has their own slant on things, and as a new user, I could look at any one of the three and get a completely different picture of what stack is recommended.

        It’s not that any of the documentation resources mentioned is “bad”, they just all document something different, and it’s not clear which is the most appropriate toolset/approach. So, in my mind, the solution is three-fold:

        1. Define a finite set of tools/software with which stacks should be constructed
        2. Authoritatively document the list of approved stacks and why each represents the best choice for the problem it is designed to solve
        3. Explain the ways in which the components of each individual recommended stack work together, and how they should be configured to do so optimally.

        The third already has a lot of existing work that can be brought into the fold, but the material is very fragmented and inconsistent because the first two have not been effectively addressed. Once they are, package maintainers will know what stacks need to be available so they can create consistent naming schemes and dependencies for the packages. That, combined with an authoritative source of recommended toolsets, stacks, and documentation (which each distro can use as a base for their own versions), the end-users will have a much clearer picture of what should be done.

        To be clear, I, like many others in the community, am very grateful for the work that has been done, and applaud the developers for the fantastic software they have developed and the many hours they have spent doing so. But, the way it’s being marketed is a source of incredible confusion, from the litany of tools and stacks that are being packaged to the fragmented bits of documentation that describe each different incantation. The reason I prefer to stay anonymous is that I don’t feel it’s relevant. It’s nothing personal, I just want the message to be the focus, not the messenger.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: