There is now an updated version of the topic available, including LINSTOR!



Guest blog by Jason Mayoral.


DRBD works by inserting a thin layer in between the file system (and the buffer cache) and the disk driver. The DRBD kernel module captures all requests from the file system and splits them down into two paths.

So, how does the actual communication occur? How do two separate servers optimize data protection?

DRBD facilitates communication by mirroring two separate servers – one server, although passive, is usually a direct copy of the other. Any data written to the primary server is simultaneously copied to the secondary one through a real time communication system. The passive server also immediately replicates any change made in the data.

DRBD 8.x works on two nodes at a time – one is given the role of the primary node, the other – a secondary role. Reads and writes can only occur on the primary node.

The secondary node must not mount the file system, not even in read-only mode. While it’s true to say that the secondary node sees all updates on the primary node, it can’t expose these updates to the file system, as DRBD is completely file system agnostic.

One write goes to the actual disk and another to a mirrored disk on a peer node. If the first one fails, the file system can be displayed on the opposing node and the data will be available for use.

DRBD has no precise knowledge of the file system and, as such, it has no way of communicating the changes upstream to the file system driver. The two-at-a-time rule does not actually limit DRBD from operating on more than two nodes.

Moreover, DRBD-9.x supports multiple peer nodes, meaning one peer might be a synchronous mirror in the local datacenter while another secondary might be an asynchronous mirror in a remote site.

Again, the passive server only becomes functional when the primary one fails. When such a failure occurs, Pacemaker immediately recognizes the mishap and shifts to the secondary server. This shifting process, nevertheless, is optional- it can either be manual or automatic. For users who prefer manual, one is required to authorize the system to shift to the passive server when the primary one fails.


CEPH is open source software intended to provide highly scalable object, block, and file-based storage in a unified system.

CEPH storage clusters are designed to run on commodity hardware, using an algorithm called CRUSH (Controlled Replication Under Scalable Hashing) to ensure data is evenly distributed across the cluster and that all cluster nodes can retrieve data quickly without any centralized bottlenecks.

Ceph object storage is available through Amazon Simple Storage Service (S3) and OpenStack Swift Representational State Transfer (REST) – based application programming interfaces (APIs), and a native API for integration with software applications.

Ceph block storage uses a Ceph Block Device, which is a virtual disk that can be attached to bare-metal Linux-based servers or virtual machines. The Ceph Reliable Autonomic Distributed Object Store (RADOS) provides block storage capabilities, such as snapshots and replication. The Ceph RADOS Block Device is integrated to work as a back end with OpenStack Block Storage.

Object storage

Ceph implements distributed object storage. Ceph’s software libraries provide client applications with direct access to the reliable autonomic distributed object store (RADOS) object-based storage system, and also provide a foundation for some of Ceph’s features, including RADOS Block Device (RBD), RADOS Gateway, and the Ceph File System.

The librados software libraries provide access in C, C++, Java, PHP, and Python. The RADOS Gateway also exposes the object store as a RESTful interface which can present as both native Amazon S3 and OpenStack Swift APIs.

Block storage

Ceph’s object storage system allows users to mount Ceph as a thin-provisioned block device. When an application writes data to Ceph using a block device, Ceph automatically stripes and replicates the data across the cluster. Ceph’s RADOS Block Device (RBD) also integrates with Kernel-based Virtual Machines (KVMs).

Ceph RBD interfaces with the same Ceph object storage system that provides the librados interface and the CephFS file system, and it stores block device images as objects. Since RBD is built on librados, RBD inherits librados’s abilities, including read-only snapshots and revert to snapshot. By striping images across the cluster, Ceph improves read access performance for large block device images.

The block device can be virtualized, providing block storage to virtual machines, in virtualization platforms such as Apache CloudStack, OpenStack, OpenNebula, Ganeti, and Proxmox Virtual Environment.

Guest blog by Jason Mayoral (www.rebelbranding.us).

Don’t Settle for Downtime

Innovative Data Storage Can Save Cash, Headaches, and Your Data

Storage Downtime is Unacceptable

When the network goes down, everyone is mildly annoyed, but when the storage goes down,  “Everyone loses their mind, ” as the Joker would say.  And for good reason. No one likes losing payroll data, shipments, customer information, financial transactions, or CRM information… And they certainly don’t like waiting while you roll back to your latest backup. Internally and externally, data-loss and downtime wastes valuable resources and it hurts company reputation. Downtime is becoming less acceptable every day, and data-loss, even more so. Stable, safe, and secure storage should be a priority for those responsible for protecting their business (just ask Equifax).

Traditional Solutions

Due to the increasing need for high availability (HA) and disaster recovery (DR), proprietary storage companies like NetApp and Dell EMC have provided SAN and NAS technologies to protect your organization’s most important data. These hardware appliances, many times, have no single point of failure, synchronous data replication and even a nice GUI so that users can point-and-click their way around. The downside? These storage appliances aren’t scalable and they are expensive. Really expensive.

The Obvious (or not so obvious) Alternative

Did you know that resiliency is built into your Linux OS? That’s right, built into the mainline linux kernel is everything you need to replace your shared storage. For over 15 years, LINBIT has been creating the DRBD software, designed to synchronously replicate data between Linux servers seamlessly just like your SAN. It can even trick the application above to believing they are writing to a SAN, when in reality, it is standard X86, ARM, or Power boxes. The full LINBIT HA solution combines the DRBD software with open source fail-over software as well. This combination eliminates the need for proprietary shared storage solutions. So, why aren’t you using it? You probably didn’t know that it existed.


For the past 20 years, those with IT know-how, and small budgets found that HA clustering, using commodity off-the-shelf hardware, was an affordable alternative to traditional storage methods. This crowd consisted of the standard Linux hacker rolling out a home-brewed web-server, and the hyperscale players who didn’t want to rely on outside vendors to build their cloud. Being that these hyperscale companies are using the software to create a competative advantage against their competitors they aren’t all-that-eager to share their stories. They have kept the mid-market in the dark.

Almost all of the major players (including Google, Cisco, Deka Bank, HP, Porsche, and the BBC) have realized that using standard hardware instead of proprietary appliances creates a competitive advantage. Namely: inexpensive resilient storage that their competitors are paying an arm and a leg for. Now, the storage industry’s best kept secret is finally out.

It Doesn’t Stop There

LINBIT is pioneering open source SDS. In development for over 7 years, the new solution will create standard High Availability clusters like described above, and also work perfectly for cloud storage. The LINBIT SDS software introduces performance advantages scalability to the  design. LINBIT’s created a sort of “Operating System based,” Open Source, Software Defined Storage technology that is already built into your existing operating system and ready to use with any Linux system.

The Default Replication Option

LINBIT’s DRBD software receives about 10,000 confirmed downloads per month (people who opt-in to show their statistics). LINBIT is far more engineering and development focused than sales focused so if you aren’t solving a real-world problem you have probably never ran into them. LINBIT’s software popularity is user driven, and due to 3 main reasons:

Flexibility: Since the DRBD software replicates data at the block level, it works with any filesystem, VM, or application that writes data to a hard drive. It can replicate multiple resources simultaneously so users don’t have to choose different replication technologies for every application/database running on the server.

Stability: Being accepted into the mainline Linux kernel is a very stringent process. DRBD has been in the kernel since 2009, version 2.6.33

Synchronous: Prior to DRBD’s availability (no pun intended), the only option for synchronous replication was hardware (SAN, NAS devices). The DRBD software can run in synchronous or asynchronous mode, and be used for local replication or Geo Clustering across long distances.

Now that DRBD has tools to provision your storage, scaling out has never been easier. Interested in how this might apply for your projects? Check out some of LINBIT’s  (free) innovative technical documents which describe how to set up a cluster for your specific environment. Have an idea that isn’t covered in the documentation? Reach out to [email protected] and ask if your idea is sane. They’ll consult the LINBIT engineering team, and will point you in the right direction. Most importantly, NEVER settle for unplanned downtime.

Find out more about the costs of downtime in the podcast, The OrionX Download with LINBIT CEO, Brian Hellman.

DRBD and Randtronics DPM

Today we’re happy to announce a new document titled “Block Replication with Filesystem Encryption” which showcases another wonderful use case for DRBD.

Block Replication with Filesystem Encryption

At Hosting Con, back in April of this year, some colleagues of mine ran into some representatives from Randtronics. Randtronics is the company responsible for the DPM (Data Privacy Management) software suite. This software suite provides file encryption, user management, ACLs, and more. I could imagine this software would prove useful to those in fields where data privacy is an absolute must. Fields such as the medical, legal, human resources, or intellectual property, quickly come to mind.

(Graphic is property of Randtronics)

After a brief discussion with us regarding just how versatile DRBD can be it was decided to see if perhaps DRBD could work seamlessly with DPM. Randtronic’s DPM can help protect your data from prying eyes, or those who may wish to steal it, but can it protect your data from system failures? When teamed up with DRBD you can be assured that your data is both secure and available.

I worked briefly with Gary Lansdown of Randtronics to introduce him to asciidoc, but I must give credit to Randtronics for this document.

Secure Linux: Atomicorp includes DRBD for replication

Every so often we get a chance to test new¹ software. Usually this opportunity is driven by the question: Does DRBD play nicely with it?

At HostingCon this year, we met a team from Atomicorp and decided that it would be interesting to see if we could get DRBD running on this hardened version of Linux. Overall, LINBIT’s broad client-base loosly includes “security” since “Availability” is one of the 3 Security pillars of the CIA triad.


Image Source: Panmore Institute

Security certainly fits with Atomicorp since they focus on clients in the federal, financial, healthcare, and hosting space. Their HQ is based in the same business park as Raytheon, Boeing, and Booz Allen Hamilton, if that tells you anything about their market.

We frequently take on the challenge of seeing if we can get DRBD compiled and working correctly, like that time we installed it on 2 raspberry pi’s, and this case was no different. While we were confident that there wouldn’t be issues with installation, — after all, it’s Linux — we needed to verify compatibility with the ASL (Atomic Secured Linux™) hardened kernel before announcing that it works.

After speaking with the Atomicorp team, they let us know that some of their clients were already running DRBD and Pacemaker for High Availability within their data centers. That’s great news! We anticipated that the testing would go quickly since we already had verified users.

Upon installing DRBD on a pair of RHEL 7 systems, we found something unexpected. DRBD is already included in the ASL kernel. This means Atomicorp is hardening and packaging a newer mainline kernel instead of hardening that which the distribution supplies. Nice work Atomicorp! The DRBD 8.4.5 version in the ASL kernel is pretty recent too.

It’s funny. Clients often ask us if we have seen DRBD used for their specific use case. DRBD is so versatile that we’re not always familiar with every situation. If we had been asked if anyone was using DRBD with Atomicorp’s ASL product, we would have said “I don’t know.” The irony here is that when you install the ASL hardened kernel, you may automatically get DRBD on a distribution where you otherwise may have not. It is available for everyone who runs Atomicorp’s ASL kernel whether the end user leverages the replication functionality or not².

This isn’t just a fun, internal office story; this is the essence of how Open Source Software works. We now know that there is a connection between ASL and DRBD, and are delighted to work with Atomicorp moving forward. It just makes sense since end-clients of both Atomicorp and LINBIT achieve feature-sets that they wouldn’t have otherwise. Altogether, our partners help advocate for our open source software and when our solutions are combined, everyone keeps inching toward bigger and better solutions, while maintaining focus on their core competencies.

So does the DRBD software work with Atomicorp and the Atomic Secured Linux™ kernel? Of course it does; and now, for the next few weeks, I get to be mocked by my coworkers for having our engineers test something which already had our software baked into it. 😉


1: New to us.
2: You’ll still need the userland utilities to manage and initialize DRBD, but that’s less of security concern than compiling and inserting a kernel module.

Configuring an HA+DR Apache ActiveMQ™ Cluster

To quote the Apache Software Foundation:

Apache ActiveMQ™ is the most popular and powerful open source messaging and Integration Patterns server. Apache ActiveMQ is fast, supports many Cross Language Clients and Protocols, comes with easy to use Enterprise Integration Patterns and many advanced features while fully supporting JMS 1.1 and J2EE 1.4. Apache ActiveMQ is released under the Apache 2.0 License.

Deploying a synchronously replicated shared-nothing storage cluster (DRBD) as outlined in this guide, is a supported method for achieving HA without requiring a clustered filesystem or shared database. This method also mitigates the risk of a SAN, clustered filesystem, or shared database being a single point of failure in our persistent storage layer. Read more


DRBD Top is about to make your life easier! Once you install this utility, you can expect to see an easy to read, simplified overview of your resources and their status. This is especially useful if you have a large number of resources and don’t want to be overwhelmed with information, yet still want key details. Read more

True Cost of Data Loss

When you hear the word ‘data,’ what does it make you think?  Something interesting and exciting?  Probably not.  But, what if you lost your customer database, your employee healthcare information, or your organization’s website transactions?  Now, that might make you think twice.  

Read more

Oracle DynDNS with Booth Geo-Clustering

Pacemaker was never designed to operate across the WAN, or any high latency networks. However, there has always been a need and desire to orchestrate active/passive failovers between data centers and across long distances. To address this issue the Booth Pacemaker add-on was conceived back in late 2011. LINBIT has been involved in the development of Booth since 2013, and has been offering it as a supported solution since 2015.

Booth addresses the shortcomings of Pacemaker by introducing the concept of “tickets”. We constrain particular resources to tickets, and only the site which holds the ticket may start the particular resources. This can be thought of like the old token ring networks of days past. In order for Booth to ensure there is no cluster split, and two sites never possess the ticket at the same time, we utilize arbitration nodes to achieve quorum, and set an expiration period upon the tickets. If a site loses communication with the rest of the Booth cluster its ticket will not renew and it will stop resources within the expected time frame.

While Pacemaker with Booth addresses the issues of High Availability across the WAN, one issue which has always proven difficult is redirecting client traffic to the new site. In most of our demonstrations of Booth we have simply used a round-robin DNS (such as in my demonstration here: Booth Geo Cluster Demo). While round-robin DNS is easy to configure and simple, it is quite inefficient as every other request is discarded.

LINBIT has recently been working with Oracle DynDNS in order to find a more efficient and better solution. Fortunately, Oracle DynDNS offers a Managed DNS service toting a feature aptly named, “Active Failover”. The Active Failover feature can be configured to monitor several things for health. The managed Oracle DynDNS servers can monitor an IP address via ping, SMTP, HTTP(S) or a particular listening TCP port, and then update the DNS destinations only when the service fails and Pacemaker switches the sites. This makes it much more efficient and a perfect match for Pacemaker clusters utilizing Booth.

To demonstrate this solution in detail we have developed a tech-guide which outlines, step-by-step, how to configure this using RHEL 7, Pacemaker, Booth, and Oracle DynDNS Managed DNS, to provide a Highly Available, Geo-Clustered, MariaDB service. This document can be found in the documentation section of our website.

Would you want to be your own car mechanic?

Data seems to be on everyone’s mind these days.  From employee to financial data, your company has to keep it available through seamless replication — without downtime. LINBIT DRBD is the open source software that ensures High Availability for your enterprise.

Read more

Red Hat Summit KeyNote: How to survive rapid change – Jim Whitehurst

In Jim Whitehurst’s Red Hat Summit 2017 keynote, he opened by making a bold claim: planning is dead. He followed up his statement with predictions from the past that have turned out to be grossly inaccurate. He referred to a prominent example from 1899 when the US Patent office stated that “Everything that can be invented has been invented,” a quote that received soft laughs from the audience of 10,000.

Following the claim that traditional planning is dead, Jim backed it up with a statement of fact when he stated that “cognitive bias makes us terrible at predicting the future. The faster the rate of change, the worse we are at planning.” So, how do companies succeed if they can’t plan linearly? Both companies and people are fighting to keep pace with change, and change is coming from every direction. For example: how would car manufacturers have planned for Uber? Uber came out of nowhere with a few dollars of venture funding. Now, car companies are building their businesses around providing cars for new-age taxi services like Uber. No doubt that your industry has a similar analogy.

Because things are no longer planned, but rather “emerge,” the key is to participate in the communities who are initiating change, and help drive the forward-moving innovation.  Think about the “Big Data” market where tons of companies making small steps forward are creating massive market changes. The same is happening with AI.
Organizing humans is now about creating context for individual action. The new model for industry success is “Try, Learn, & Modify.” Organizations who figure out how to reward fast failure, continually adapt to changing plans, and participate inside their respective market communities at scale will thrive. If you embrace, rather than fear the rapid change in the world, you will have the chance to be apart of it.