Today is an exciting day for us. We have announced that with the upcoming DRBD 8.3 release (currently scheduled for the end of this year), all those features that are currently commercially licensed in our DRBD+ add on will be merged into the GPL DRBD main source tree. That means that stacked device support, huge device support (larger than 4TB per device), and checksum-based resync are all coming to DRBD.

Is this something that we haven’t done before? No it’s not. We have, in the past, repeatedly merged DRBD+ features into DRBD. We have not, however, done so previously on this scale. That is new.

How will this affect our customers and users?

• First of all, if there ever was any relevant functionality gap between proprietary storage replication solutions and DRBD (there wasn’t — we had DRBD+ for that), not even a trace of any such gap will soon be left in DRBD as a fully open source, GPL-licensed solution.
• Secondly, for those would-be customers that previously had to back away from DRBD+ because it was not open source, and instead had to rely on open source drivers for proprietary hardware, that concern is now gone.
• And thirdly, it makes for much easier integration of DRBD into certified, fully open source high availability source software stacks, even for huge storage sizes. Whether that stack is maintained exclusively by us, by a partner, or by both jointly.

Has this been an easy decision? No, it took some contemplation. But we’re absolutely confident that it’s the right step in the right direction. So do watch our DRBD community web site for announcements regarding the 8.3 pre-release cycle and release.

As part of our partnership with Dolphin Interconnect Solutions, we are presenting two webinars on DRBD for Dolphin Express on Nov. 5 (European business hours) and Nov. 12 (American business hours).

Both DRBD and Dolphin Express already being a fixture in the MySQL universe, this webinar should be particularly interesting to those of you who want to minimize database write latency while maintaining fully redundant and transaction-safe high availability. However, it’s also a must see for virtualization and mail service DRBD users, who also typically have a need for low latency.

This is, of course, a technical presentation detailing the ins and outs of DRBD for Dolphin Express configuration, performance benchmarks, and possible pitfalls. Don’t expect a lot of marketing blah-blah.

Attending these webinars is completely free of charge. You can sign up immediately.

During a recent discussion on the drbd-user and linux-ha-dev mailing lists, one point raised was the proliferation of Floating Peer DRBD/Heartbeat setups. As we currently can’t estimate how widespread the use of this Heartbeat feature actually is, I’ve created this poll. Please do respond if you are a DRBD/Heartbeat user. Your help is much appreciated. Thank you very much!

Update: the third option was originally termed “No, heard of it but never considered“; I rephrased to make the option more clear.

Today we announced (German press release, English press release) a partner deal with Dolphin Interconnect Solutions, makers of the Dolphin Express highspeed interconnect technology. Like DRBD, Dolphin Express and Dolphin SuperSockets are well established within the MySQL customer base — the latter as a low-latency interconnect for MySQL Cluster. As part of the deal, DRBD will soon be available in a version supporting SuperSockets — which means you’ll be able to use Dolphin Express cards as a drop-in replacement for the Gigabit Ethernet cards you now typically run DRBD replication over. And you’ll be able to use Dolphin Express for MySQL High Availability in applications where MySQL Cluster is not the ideal choice, too.

This is really exciting stuff as it opens DRBD to a whole new class of database applications, namely those where low latency is critical. This used to be a common concern for some users. Especially with battery-backed write cache being ubiquitous these days, the fact that Gigabit Ethernet is actually quite high in latency caused surprises to some.

But do we stop at MySQL? Absolutely not. This is also a great addition to highly available PostgreSQL and Oracle databases. Do we stop at databases? Even less so. DRBD for Dolphin Express is a great low-latency, high-throughput replication solution for any highly available application. Think virtualization or petabyte file storage, for example.

We’re extremely happy to have Dolphin among our growing list of technology partners, and greatly enjoy working with them. Thanks guys for the work so far, and let’s continue full steam ahead!

A recording of the August 27 webinar on DRBD Performance Tuning is now available from our website.

Viewing this webinar is free of charge. Enjoy!

For those of you interested in getting maximum performance out of your DRBD-based HA clusters, I am hosting a webinar on the subject on Wednesday, 8/27 at 1800 UTC (2pm Eastern, 11am Pacific).

The webinar is offered free of charge and it’s already pretty tight in terms of attendance, the event being limited to a maximum of 60 attendees. But if you’re quick, you might still stand a chance of grabbing a front-row seat. Check out this page on our website, it has all the relevant information.

Last Friday and Saturday I had the pleasure of presenting DRBD-based high availability at the 2008 Zarafa Summer Camp. What’s this Zarafa thing, you ask? Here’s a quick introduction.

Zarafa is a fully LAMP-based, drop-in replacement for Microsoft Exchange developed by a Delft, Netherlands-based company. Yes, that means that all those Windows desktop users out there can use their beloved Microsoft Outlook to connect to a full-fledged collaboration solution, including email, calendaring, contact management, a global address book, and task sharing. Using native MAPI. And the server components are 100% built on Linux, Apache, MySQL, and PHP. They even use an Embedded MySQL database for off-line storage and synchronization.

What’s particularly nice about the solution is that it has a pretty clean-cut modular architecture. The developers are really making a point of implementing just what they need — a central SOAP-based server instance, an MDA, a spooler, a POP3/IMAP gateway, a mobile synchronization agent — and using existing software for non-essential components: Postfix as the MTA, Apache and PHP for the central application components, OpenLDAP for centralized directory storage, MySQL with InnoDB as the back end database.

Myself with Steve Hardy (Zarafa), Jens Bollmann (Sun Microsystems) and Quinten Laureijs (Red Hat) during the panel discussion.
Photo credit: Michel de Ron

Needless to say, DRBD/Heartbeat is a perfect addition to that stack. Full High Availability plus shared-nothing storage replication for any component — MySQL, Postfix, Apache, the Zarafa services proper, everything.

The Zarafa guys were nice enough to invite me for a 45-minute presentation, panel discussion covering various “multi-server” deployment options, and a 2 1/2 hour hands-on session with interested partners and customers. I had a blast. Dank u wel — graag tot volgende jaar!

I ought to state that Microsoft, Microsoft Outlook, and Microsoft Exchange are trademarks or registered trademarks of Microsoft Corp. Zarafa is a trademark of Zarafa (who would’ve guessed!). MySQL is a trademark of Sun Microsystems.

Effective immediately, Thirdware, Inc. is the first DRBD Certified Partner in Japan. We are thrilled to have Motoharo Kubo-san and his team as our valued partner in this market, and are very excited that Japanese customers will have access to native-language DRBD support and consultancy as early as June.

News of this exciting partnership has been hitting the presses in Japan since this morning. We (LINBIT) followed up with our own press release later in the day.

I recently came across this blog post with the catchy title of “DRBD and MySQL: Just Say No”. Now while I have absolutely no issue with people not liking DRBD or finding that it doesn’t fit their needs, I couldn’t help but notice that the post recycles some persistent myths about DRBD, which could use some correction.

I’ve tried to reply using a blog comment, but alas it seems I was moderated to /dev/null. Enter the “Write Post” button on my trusted WordPress dashboard.

So let’s look at the alleged “MySQL with DRBD Minuses” mentioned in said post I am referring to:

DRBD partition corruption means failover node would be unusable (disadvantage of shared storage) and failback could destroy original master too.

If the filesystem that sits on top of DRBD gets corrupted, it will be equally corrupted on the peer node after failover. DRBD is a block device; it is agnostic of layers above it. That much is correct. Which incidentally is also the reason why you can use DRBD to add HA not only to databases, but to file services, virtualization, storage, etc. But I’m going off on a tangent.

“Failback could destroy the original master too”, however, is plain false. DRBD won’t “destroy the original master” any more than it already was if the filesystem on top of DRBD was fried beforehand.

Now as for the actual partition (meaning the backing device DRBD resides upon), DRBD adds to data security, not the opposite. DRBD will automatically detach from backing devices that throw I/O errors. And if you happen to get random errors (”bit flips”) in local data blocks due to I/O subsystem malfunction, online verify will catch that.

If the master panics, then after failover both fsck and transaction logs replay must be performed.

Transaction log replay, yes. But fsck? These days this amounts to running a journal replay. Takes under a second in most circumstances.

NIC and network corruption is also propagated.

False again. We have end-to-end replication integrity checking to prevent just that.

Failover node is a cold standby, cannot accept database traffic if that would change the DRBD partition.

The failover node is a hot standby, it’s just not a running slave node from the database’s standpoint. And, nothing stops you from running two databases on two servers on two DRBD devices laid out in a “criss-cross” fashion, converging on one node in case of node failure.

Could generate a lot of network traffic.

On a busy database, yes. But if you follow our design guidelines that always recommend a separate DRBD replication connection, this won’t hurt your application at all.

Cannot do maintenance on cold standby database.

But you can do anything you want with a database that you run off a DRBD LVM snapshot. Works on a Secondary node too.

2 heartbeats needed on a reliable, local network.

So I don’t see how this would be a minus, but then maybe that’s just me.

So to sum up yes we’ve seen all this before, and surprise surprise Eric Bergen’s “DRBD in the real world” has been quoted in that post as well. Now while I concede that some of the points Eric had made were valid at the time (and some continue to be), a lot of what he said then is now outdated, superseded, or has been addressed in DRBD releases made months ago. But to Eric’s credit, he fostered a lively discussion in the comments to his post, so I do encourage you to take a look.

We’re thrilled to see Canonical fully integrate DRBD into the new Long-Term Support (LTS) Ubuntu Server Edition release, 8.04 “Hardy Heron”. This is the first stable Debian-based release to come with full binary package support for DRBD, so module-assistant invocations are a thing of the past on this platform. The Canonical press release is here for you to read.

We expect the “original” Debian GNU/Linux to follow suit when the next Debian release (lenny) goes stable.