And here’s a couple of ideas for making the process easy:

• Please please please send patches. Working in a Mercurial checkout and then using hg export or hg email makes reviewing and merging your patch a breeze.
• If you really do not want to familiarize yourself with Mercurial, then please take your version of the RA, diff -u it against a released version, and send that diff to the mailing list. Be sure to state the exact version of the resource-agents package (cluster-agents package on Debian) that it applies to.

You see, resource agents change. All the time. This may not affect the functionality of the RA at all. We might just add auto-generation of man pages. Or change an internal interface. Or streamline some functions. Bottom line, the code changes. If you just send us your version of the RA “with all relevant changes applied,” then it’s quite likely that the RA you are changing has been modified a bit since the most recent release.

And suddenly, when we diff your version against the one in the upstream repository, we see a bunch of differences which, if applied, would roll back changes made in the meantime. And singling out which of your changes were actually meant to be applied becomes a truly tedious task for anyone who reviews your submission.

If, by contrast, you send a patch, we see only the changes you meant to apply. And even if upstream has changed in the meantime, chances are that we can wiggle your patch in with minimal fiddling.

The first distro to sport the new kernel, to the best of our knowledge, will be Fedora 13, whose default kernel build will of course have the DRBD module enabled. That gives Fedora 13 users the ability to just say yum install drbd, and get the full DRBD userland package and no extra kernel module.

We are expecting other distributions to follow suit shortly. And even if your favorite distribution does not adopt a 2.6.33+ kernel anytime soon, don’t despair! Chances are that it has carried DRBD as an add-on kernel module all along, and will continue to do so. And then of course, LINBIT DRBD support comes with DRBD certified binaries for a multitude of distros.

Heartbeat 3.0.2 is the first official Heartbeat release since 2.1.3, released over 2 years ago. There have been a number of intermediate releases in the interim, including some Fedora releases labeled 3.0.0 and 3.0.1, but this is the first official Heartbeat 3.0 release. This means that Pacemaker, the definitive Linux cluster stack, continues to be fully supported on both the Heartbeat and Corosync/OpenAIS messaging layers.

The release tarball may be downloaded directly from the Mercurial repository, or from the Linux-HA web site. Debian packages will soon be available from Martin Loschwitz’ people.debian.org repository and are expected to make their way into Squeeze shortly.

And yes, we had planned to make this release in January. But 2/1/2010 just looked so neat as a release date.

High availability, that’s us. Bottom to top.

That makes DRBD an integral part of Linux, starting with the 2.6.33 release expected in a few weeks’ time.

We have something to celebrate.

Publican packages have been available in Debian squeeze for a while, but as of today are not included in Ubuntu. Thus, I built packages for karmic, which you may fetch by adding the following line to your /etc/apt/sources.list file:

deb http://people.linbit.com/~florian/ubuntu/publican karmic main

Then fetch my GnuPG key so you can verify the Release file’s integrity:

apt-key adv --keyserver pgp.mit.edu --recv-keys 7349B897BC759CF1

Now you can install with

aptitude update
aptitude install publican

… and then hack away.

Ubuntu folks (Andres, that means you!), can we have this in the upstream Ubuntu distros please?

This is to announce that LINBIT, with the kind permission from the Linux-HA project board, will act as the “steward” of the Heartbeat cluster messaging layer code base, from this point forward. This is a summary of our motivation and plans related to that role.

What does this entail?

• LINBIT will assume responsibility for bug fixes for the Heartbeat code base, currently hosted at http://hg.linux-ha.org/dev/.
• LINBIT will bundle up the 3.0 beta codebase, make a 3.0 final release (currently this is planned for the month of January 2010), and subsequently make bugfix releases as deemed necessary.
• LINBIT will further collaborate with the Pacemaker project to keep the existing dual-stack capability in Pacemaker.
• LINBIT will continue making the public Mercurial repository available at the present location (any eventual relocation, if desired by the Board, would be publicly announced with ample advance notice).
• LINBIT will administer the public mailing lists (linux-ha and linux-ha-dev) on the servers currently hosting them (again, any eventual relocation, would be publicly announced with ample advance notice).
• LINBIT intends to offer improved documentation for the Heartbeat messaging layer. This is meant to consolidate the content currently found on the linux-ha.org wiki site.
• LINBIT intends to offer support services for the Heartbeat/Pacemaker cluster stack (i.e. the Pacemaker cluster resource manager running on top of the Heartbeat cluster communication layer).
• LINBIT will continue to respect he Board as the final authority on matters affecting the project as a whole.

What does this not entail?

• LINBIT has no intention to add significant features to the Heartbeat code base, or extend its functionality significantly.
• LINBIT has no intention to apply changes to the licensing, development model, or collaboration model for the Linux-HA code base.
• LINBIT has no intention to establish the Heartbeat code base as a long-term alternative or competition to the OpenAIS/Corosync cluster messaging layer. However, we do believe that it is a valid alternative for the short to mid term, and for some configurations where OpenAIS/Corosync is currently suffering from some growing pains.
• LINBIT has no intention to support or advocate continued use of Heartbeat in v1 (haresources) configurations. We will continue to recommend to switch to the Pacemaker cluster stack, now that two (technically and commercially) supported cluster messaging layers are available.

At this time, the primary contact in charge of Heartbeat development matters at LINBIT is Lars Ellenberg, the person in charge of documentation is myself. The best means of relaying comments and asking questions continues to be the public mailing list.

We hope that this is a useful service to the Heartbeat user community. I want to reiterate that we have no intention whatsoever to change the current, proven, community centric approach to how the Heartbeat code base is managed. We continue to welcome, and depend on, community suggestions, feedback, and collaboration. Heartbeat is a community project and will remain so.

If you have any questions about our intentions and plans, please post them on the mailing list, or peruse the comment fields below.

Last weekend, seven employees of LINBIT’s European division participated in the World Games of Mountain Biking in Saalbach-Hinterglemm, Austria. We took part as Marathon race participants and co-sponsors of Biking for Butterfly Children, a charity dedicated to the fight against epidermolysis bullosa (EB).

Currently, no cure for any of the over 30 subtypes of EB exists — dermatologists and care givers can, however, greatly improve patients’
quality of life. Still, EB can be an excruciatingly painful, disfiguring, and debilitating disease that affects one in 20,000 live births and as such, makes the condition an orphan disease. The health care industry has little incentive to research the condition (as there is little money to be made off of it), and those who dedicate their careers to EB patient care and research rely on charitable donations for funding. Biking for Butterfly Children acts as a reliable fund raiser rounding up much-needed donations in the course of amateur cycling events (such as the World Games).

During this year’s World Games, B4BC raised a total of about 7,000 euros in donations — a respectable sum for an all-amateur event, but a lot more money is needed to improve the quality of life of EB patients, and potentially discover a cure to the disease. If you consider joining the fight against EB, please contact your local DebRA chapter.

• Use a SAN. Well, SANs are great in terms of management, even though they’re sometimes prohibitively expensive. But your regular SAN box does not offer physically distributed redundancy at the data level. In order words, if your SAN box goes down, all your beautiful high availability infrastructure turns to shreds. And even if you naïvely believe (and you shouldn’t) that a storage box can never crash, just think about air conditioning going down in just that part of your data center where your storage shelf is at. Repair time of several hours means down time of several hours, even though your servers in a different cabinet may be up and running. You’re dealing with a single point of failure. Not high availability in my book.
• Use a SAN with native replication. This means using two separate storage boxes with synchronous block-level replication between them. This eliminates the above-mentioned SPOF and is available from just about any SAN vendor (using proprietary implementations under various product names). The downside is that it costs you serious bucks, and I am not referring to just the additional piece of hardware. Those firmware licenses can hit six figures. Plus, switchover times (changing the direction of replication) can be extremely long, up to 4 minutes in some cases. And there is little to no support for replication management from open source cluster management software.
• Use a SAN with host-based mirroring. This means that you have two separate SAN boxes, hosts import LUNs from both, and mirror those pairs using software RAID (such as md). Eliminates the SPOF and saves you dollars on firmware licensing. Downsides: you still need a SAN (and the associated infrastructure — fibre channel, for example, isn’t exactly cheap), and as such your clusters are still not shared-nothing. And the integration with open source cluster management is also lacking.
• Use host-based mirroring between a local device, and a network block device. In this case, you have one disk that is local, and another that is exported from a remote host using NBD or iSCSI. Those two disks are then mirrored with software RAID. Now this one is really terrible in terms of management. Role reversal always requires some custom glue, no support from cluster manages is available whatsoever, and split brain detection is poor or non existant. So if you really want to go down that alley then do — but please don’t call it a high availability cluster.

Compare this to DRBD: no need for a SAN, so you can use it to operate a fully shared-nothing cluster. No firmware licensing cost. No need for expensive infrastructure as everything can replicate over regular IP networks. Role switch in a matter of seconds. Tight integration with both Pacemaker and Red Hat Cluster Suite.  Excellent split brain detection to make sure you don’t wreck your data accidentally. So if you are considering alternatives then that’s perfectly fine, but our soaring usage numbers are there for a reason.