© Vitaliy Vodolazskyy / 123rf.com

Obwohl sich derzeit die meisten Meldungen zu Open-Source-Storage eher auf Ceph & Co. konzentrieren, entwickelt Linbit in Wien DRBD behutsam weiter. Inzwischen existiert es sogar für Windows, kommt mit einem runderneuerten Tool zur Verwaltung daher, und DRBD Reactor soll sogar Pacemaker verdrängen.

Als IT-Journalist kommt man schnell in eine Zwickmühle: Auf der einen Seite findet sich bei den großen Projekten – also bei Kubernetes, OpenStack, Ansible & Co. – viel Innovatives und Neues. Auf der anderen Seite fehlt für viele Leserinnen und Leser dabei der Bezug zur eigenen Realität. Denn so toll Container und dynamisch provisionierbare virtuelle Instanzen auch sein mögen: Die Mehrzahl der Admins in deutschen Server-Räumen beschäftigt sich im Alltag mit konventionellen Systemen, unterschiedlichen Levels an Automation und oft genug mit klassischer Hochverfügbarkeit.

Nicht selten scheint es, als sei für diese alltäglichen Brot-und-Butter-Themen in den Medien kein Platz mehr. Außerdem entsteht der Eindruck, dass nur brandneue Technik zu wirklicher Innovation in der Lage ist, während konventionelle Technologie quasi wie selbstverständlich vor sich hin werkelt. Dass das so nicht stimmt, beweist einmal mehr der Wiener Linux-Spezialist Linbit: Dort hat man in den vergangenen Jahren die hausinterne Replikationslösung DRBD kontinuierlich weiterentwickelt. DRBD kommt bis heute in vielen Setups zum Einsatz, die Replikation auf der Datenebene benötigen. Ein Anknüpfungspunkt zur Realität vieler Administratoren ist damit also gegeben. Grund genug, genauer hinzusehen: Was kann DRBD mittlerweile, und wohin entwickelt es sich?

DRBD-Historie

Beschäftigt man sich 2022 mit DRBD, fällt schnell auf, dass es in gewisser Weise ein Aktualitäts- und PR-Problem hat. In Sachen Datenreplikation und skalierbarer Speicher hat in den vergangenen Jahren vor allem eine Lösung den Diskurs dominiert: Ceph. Das galt umso mehr, wenn es um einen Einsatz im Fahrwasser einer Cloud ging, etwa mit Kubernetes oder OpenStack. Oft genug kam DRBD hier gar nicht erst in die engere Wahl.

Dem historischen Verdienst der Lösung wird das kaum gerecht: Bereits Mitte der 2000er-Jahre galt DRBD als günstige und sehr stabile Alternative zu den damals klassischen SAN- und NAS-Konstrukten mit Replikation – lange, bevor Ceph oder andere hippe Lösungen der Gegenwart auch nur irgendwie produktiv zu nutzen waren. Gleichzeitig hat der Hersteller Linbit sich durchaus auch um den HA-Stack für Linux verdient gemacht, zum einen durch Entwicklungsarbeit an Pacemaker & Co., zum anderen, indem man Sorge dafür trug, DRBD mit Pacemaker sinnvoll zu integrieren.

Im Sog der modernen hyperskalierbaren Umgebungen drohte DRBD dann allerdings unterzugehen, nicht zuletzt, weil man in Wien ein zentrales Feature über Jahre verschlafen hatte: Erst 2016 erschien in Form von DRBD 9.0.1 eine DRBD-Version, die sich auf mehr als zwei Knoten nutzen ließ (Abbildung 1). Die Drei-Knoten-Replikation hatte sich zuvor mit DRBD 8 zwar als “schlimmer Hack” (so einer der Autoren von DRBD) einrichten lassen, zukunftssicher war dieser Ansatz aber keineswegs. DRBD 9 konnte bei der Erstveröffentlichung immerhin mit 32 Knoten umgehen und erlaubte mithin größere Speicher und ein gewisses Skalieren in die Breite.

Abbildung 1: DRBD 9 beherrscht Replikation über mehr als zwei Blockspeichergeräte und implementiert auf diese Weise die Skalierbarkeit in die Breite.

Verwaltungsprobleme

Philipp Reisner, der DRBD-Erfinder, hat in den vergangenen Jahren auf etlichen Messen persönlich erklärt, wieso DRBD 9 über eine so lange Zeit Ladehemmungen hatte. Das Problem war demnach gar nicht die Replikationslösung selbst. Zur Erinnerung: DRBD besteht heute aus mehreren Modulen im Linux-Kernel, einem für die Datenreplikation und weiteren, die verschiedene Netzwerkprotokolle als Transportschicht implementieren, etwa TCP/IP oder Infiniband. Das für die Replikation zuständige Modul war laut Reisner relativ einfach so zu verändern, dass es Replikation hin zu mehr Zielen als nur einem ermöglichte.

Dabei kam den Entwicklern zugute, dass DRBD im Gegensatz zu manch anderer Software auf dem Markt einer eher einfachen Architektur folgt, was kein Nachteil ist. Wo bei Ceph etwa mehrere Schichten zwischen den Daten für Abstraktion sorgen, leitet DRBD bis heute im Wesentlichen Daten zwischen zwei Blockspeichergeräten hin und her. Das sorgt nicht nur dafür, dass Debugging im Falle eines Problems einfacher ist – es verhindert von vorneherein auch, dass allzu viel Magie für erhöhte Latenzen sorgt, wie es bei Ceph etwa chronisch der Fall ist. In DRBD 9 hat sich daran nichts geändert.

Durchaus geändert hat sich allerdings die Art und Weise, wie man DRBD-Laufwerke verwaltet. Linbit wählte hier einen Weg, der Skalierbarkeit in die Breite einerseits und lokale Administration andererseits ermöglicht. Auf den einzelnen Systemen legt der Admin auf Basis der dortigen Blockspeichergeräte LVM-Volumes an, die dann Daten zwischen mindestens zwei Mitgliedern eines DRBD-Clusters replizieren. Ein durchaus schlüssiger Ansatz, denn in den wenigsten Fällen brauchen einzelne Anwendungen riesige Volumes mit 20 Terabyte und mehr. Die Skalierbarkeit in die Breite erreicht DRBD, indem der Admin zu jedem Zeitpunkt neue Server in den Cluster-Verbund integrieren kann, über deren Blockspeicher sich dann wie gehabt Volumes anlegen lassen.

Allerdings ist es in der Praxis undenkbar, dass der Admin das Verwalten der DRBD-Volumes in einem Verbund von 32 oder mehr Servern – die 32-Knoten-Grenze ist mittlerweile gefallen – zu Fuß erledigt. Das würde mangels Übersichtlichkeit früher oder später zu Chaos führen, was Linbit durchaus klar war. Ein erheblicher Teil der Entwicklung von DRBD 9 bestand deshalb darin, ein Framework zu stricken, das diese Art der Verwaltung übernehmen kann.

Zeitenwende

Insgesamt gelten das zweite Halbjahr 2016 und die erste Hälfte von 2017 in der DRBD-Geschichte heute als eine Art Zeitenwende – vor allem, weil DRBD 9 endlich auch offiziell das Licht der Welt erblickte. Mit dem notwendigen Management-Framework drumherum tat man sich bei Linbit allerdings schwer, und der erste Versuch scheiterte spektakulär.

Wie es damals durchaus üblich war, hatte man sich beim Entwickeln des Frameworks recht früh auf Python festgelegt. Dagegen spricht im Prinzip auch nichts, denn Python bewährt sich im Alltag hunderttausendfach als zuverlässige Skriptsprache für Aufgaben wie exakt jene, die DRBD zu meistern hatte. Beim Design der Management-Lösung unterliefen den Entwicklern allerdings ein paar Fehler, wie sie heute selbstkritisch zugeben.

So war die Architektur von Drbdmanage durchaus komplex. Das Werkzeug bestand aus einem Client und einem Server; der Server musste auf jedem Mitglied eines DRBD-Clusters laufen und tauschte dort kontinuierlich Statusinformationen mit allen anderen Servern von Drbdmanage aus. Das war notwendig, um jedem Cluster-Knoten jederzeit den aktuellsten Überblick über die konfigurierten DRBD-Ressourcen zu verschaffen. Es erzwang aber auch die Kreation eines recht komplexen Client-Server-Protokolls, bei dem der Hersteller sich teils verhaspelte.

Durchaus praktisch war, dass in Drbdmanage bereits Schnittstellen für das Steuern von außen vorgesehen waren. In den ersten Jahren legte Linbit den Fokus eher auf OpenStack als auf Kubernetes. Entsprechend entstanden Treiber für die OpenStack-Dienste Nova und Cinder, die das Provisionieren von Volumes aus OpenStack heraus ermöglichten. In der Hochphase des OpenStack-Hypes allerdings gelang es Linbit lange nicht, die nötigen Patches dafür auch in den OpenStack-Quelltext zu bekommen, sodass ein großer Teil der Funktionalität brachlag. Immerhin: Mit der vorhandenen Architektur wäre es auch möglich gewesen, DRBD 9 nahtlos in Kubernetes zu integrieren.

Dazu sollte es allerdings nicht mehr kommen, denn auch bei Administratoren stieß Drbdmanage eher nicht auf Gegenliebe. Viele Admins warfen zwar einen verstohlenen Blick auf DRBD 9, das zwangsläufig Drbdmanage im Gepäck hatte, gaben nach einer Weile allerdings entnervt wieder auf. In Summe entpuppte Drbdmanage sich nach langer Entwicklungsphase als Windei, das der Hersteller schließlich zugunsten einer ganz neuen Entwicklung verwarf. Der neuen Lösung verpasste man kurzerhand den Namen Linstor, und sie unterscheidet sich in vielerlei Details von ihrem erfolglosen Vorgänger. Bis heute ist Linstor der Dreh- und Angelpunkt der Verwaltung von DRBD-9-Ressourcen und bei dieser Aufgabe deutlich erfolgreicher als Drbdmanage.

Mit Java zum Erfolg

Ein zentraler Unterschied zwischen Linstor und Drbdmanage springt unmittelbar ins Auge: Linstor fußt nicht mehr auf Python, sondern ist vollständig in Java verfasst. Das wirkt im ersten Augenblick insofern eigenartig, als DRBD bis dato nicht im Verdacht stand, auf anderen Systemen als solchen unter Linux zum Einsatz zu kommen. Aber auch das hat sich mittlerweile geändert – doch dazu später mehr. Linbit selbst gibt jedenfalls an, die Möglichkeit, Linstor auch unter anderen Systemen als Linux zu betreiben, sei ein Grund für die Wahl der Programmiersprache. Vor allem aber, so der Hersteller, sei Linstor dank Java erheblich einfacher zu programmieren gewesen und funktioniere besser.

Was dabei verwundert: Die Architektur von Linstor unterscheidet sich auf den ersten Blick gar nicht so sehr von der von Drbdmanage. Auch hier gibt es ein Server-Client-Prinzip, und Teile des Kommunikationsprotokolls hat Linbit gar recycelt. Allerdings muss bei Linstor nicht mehr auf jedem Knoten eine Instanz des Diensts laufen. Stattdessen gibt es eine Linstor-Instanz, die Informationen über sämtliche Ressourcen des Clusters enthält und als zentrale Anlaufstelle dient. Im Kern nimmt sie damit ähnliche Aufgaben wahr wie etwa die MON-Server in Ceph. Allerdings können die Kontroll-Server von Linstor nativ nicht in die Breite skalieren. Hier muss stattdessen wieder klassische Hochverfügbarkeit her, üblicherweise auf Basis von Pacemaker.

Kommandozentrale

Ebenfalls erhalten geblieben ist in Linstor die Eigenschaft des Linstor-Servers, als eine Art Kommandozentrale für externe Dienste zu fungieren. Die Herausforderung, DRBD auch im Kontext von Kubernetes der eigenen Klientel schmackhaft zu machen, stellt sich Linbit schließlich weiterhin. Die übliche Anbindung dafür geht in Kubernetes heute mittels CSI-Modul, wobei das Kürzel CSI für Container Storage Infrastructure steht. Es handelt sich um eine Schnittstellendefinition, die externe Storage-Anbieter nutzen können, um Kubernetes per standardisiertem Protokoll Storage-Geräten anzubieten. Linbit hat diese Anbindung an Kubernetes inzwischen geschaffen, sodass sich DRBD 9 heute in Kubernetes nutzen lässt.

DRBD auch für Windows

Eine Binsenweisheit sagt, dass es erstens anders kommt und zweitens, als man denkt. So oder so ähnlich werden die Linbit-Leute wohl gedacht haben, als sie 2020 die erste Version von WinDRBD veröffentlichten. Die Software tut genau das, was der Name verspricht: Sie ermöglicht die Konfiguration von DRBD-Ressourcen unter Windows. Vor Jahren noch hatte Linbit selbst einen Aprilscherz veröffentlicht, wonach DRBD 8 zum damaligen Zeitpunkt als Modul für Windows erscheinen sollte. Manchmal überholt die Realität die Satire eben tatsächlich (Abbildung 2).

Abbildung 2: Früher noch ein Aprilscherz, heute Realität: DRBD funktioniert dank einer Kompatibilitätsschicht nun auch unter Windows.

Um ehrlich zu sein, ist die Idee, DRBD auf Windows zu betreiben, gar nicht originär auf Linbits Mist gewachsen. Weil es sich bei DRBD um Open-Source-Software handelt, geschah, was mit Software dieser Art früher oder später immer geschieht: Gescheite Entwickler sahen sich den Code genauer an und untersuchten ihn. Dabei stellten sie fest, dass DRBD 9 zwar etliche Systemaufrufe (Syscalls) des Linux-Kernels nutzt, doch diese zum Großteil auch in den existierenden und gut erprobten Kompatiblitätsbibliotheken zwischen Linux und Windows vorhanden waren, etwa in Cygwin.

Gedanklich ist die Reise zu DRBD unter Windows von hier aus schon nicht mehr sonderlich weit: Wenn es gelingt, dass alle von DRBD genutzten Systemaufrufe auch unter Windows adäquat funktionieren, kann DRBD 9 unter Windows so gut laufen wie unter Linux. Im Netz entstanden mehrere Projekte, deren Ziel eben das war, bis Linbit kam und selbst eine Windows-Version von DRBD auflegte. Die folgt aber demselben Prinzip: Sie erfindet nicht DRBD neu, sondern verlinkt lediglich den existierenden DRBD-Quelltext. Kernkomponente von WinDRBD ist eine Kompatibilitätsbibliothek, die Windows-Systemaufrufe für DRBD übersetzt und umgekehrt. Seit Anfang 2022 gilt WinDRBD offiziell als produktiv nutzbar, zumindest auf Servern mit X86_64-CPU.

Gründe für Windows

Kritiker mögen an dieser Stelle einwenden, dass es für DRBD in Windows wohl kaum einen Bedarf gebe. Schließlich existiert seit Jahren ein in Windows Server nativ integriertes, repliziertes Storage-Volume, das obendrein anders als DRBD 9 perfekt in die zu Windows gehörenden Cluster-Dienste integriert ist. Diese Aussage greift aus mehreren Gründen jedoch ein wenig zu kurz.

Denn zunächst steht das beschriebene Replikations-Device unter Windows nur in den teuren Editionen von Windows Server zur Verfügung. Wer die nicht nutzt, hat keine Möglichkeit, das Feature etwa nachträglich zu kaufen. Das wiederum schließt eine ganze Reihe von Anwendungsfällen a priori aus. Bis heute ist es beispielsweise so, dass Software verschiedener Hersteller zwangsweise unter Windows und mithin unter Hyper-V virtualisiert werden muss, will der Administrator seinen Support-Anspruch gegenüber dem Hersteller nicht verlieren. Für Hyper-V steht das genannte Replikationsgerät aber in keinem Fall bereit. Unter Hyper-V erfüllt DRBD 9 also einen Einsatzzweck, der mit Windows selbst gar nicht umsetzbar wäre.

Hinzu kommt: DRBD 9 ist im Augenblick noch nicht in Linstor implementiert, oder anders formuliert: Linstor funktioniert aktuell noch nicht unter Windows. Linbit arbeitet nach eigener Aussage allerdings genau daran. Das wäre im Alltag äußerst praktisch, denn DRBD-Geräte ließen sich dann unter Linux wie unter Windows mit denselben Konfigurationsdateien und Einstellungen betreiben. Ohnehin funktioniert Linstor auf den einzelnen Systemen nach einem denkbar einfachen Prinzip: Gilt es, lokal eine DRBD-Ressource für die Replikation zu einem anderen System anzulegen, erstellt Linstor dafür ganz einfach eine DRBD-Konfigurationsdatei. Die unterscheidet sich in DRBD 9 kaum von dem, was Admins noch von DRBD 8 gut kennen.

Das nützt letztlich auch der letztlich auch der Automation: Ansible unter Windows ist längst kein Hexenwerk mehr, und DRBD-Konfigurationsdateien, die dann auch mit Linstor durchaus nutzbar wären, ließen sich so selbst ohne Linstor unmittelbar auf die Hosts verteilen. Dass der Admin dabei besonders aufpassen muss, kein Chaos zu schaffen, gilt hier allerdings besonders.

Pacemaker unter Beschuss

Linbit zeigt durchaus, dass auch eine vermeintlich unterkomplexe Lösung wie DRBD einiges an Innovation auf die Reihe bekommt. Und fertig sind die Entwickler laut eigenen Aussagen noch lange nicht: Im nächsten Schritt will man sogar dem Linux-Standard-Cluster-Manager Pacemaker an den Kragen, zumindest ein bisschen. Um die Beweggründe dahinter zu verstehen, ist historisches Wissen hilfreich.

Seit Jahrzehnten tritt DRBD quasi immer im Gespann mit Heartbeat 1 oder dessen Nachfolger Pacemaker auf. Das liegt vor allem daran, dass DRBD “nur” ein Storage-Dienst ist. In den meisten Fällen genügt es nicht, auf einem System den Speicher bereitzustellen – im Falle von DRBD also in den Primary-Modus zu schalten –, um einen Dienst anzubieten. Das Beispiel MariaDB macht das gut deutlich: Nachdem DRBD im Primary-Modus läuft, gilt es zunächst, das Dateisystem mit den Datenbankdaten ins lokale System einzuhängen. Dann folgt der Start der Datenbank. Damit diese unter einer gleichbleibenden IP-Adresse erreichbar ist, bedarf es auch noch einer klassischen Cluster-IP, die dem Dienst auf den gerade aktiven Knoten folgt. Bei virtuellen Instanzen ist der Ablauf etwas glatter: Hier muss man nach dem Aktivieren der DRBD-Ressource nur die VM starten.

Das Problem: Pacemaker ist nicht besonders benutzerfreundlich. Zwar hat die Situation sich in der vergangenen Dekade stark verbessert, weil Red Hat und Suse eigene Administrationswerkzeuge beisteuerten. Red Hats PCS etwa war auch hier im Linux-Magazin bereits Thema [1]. Einen Preis für das tollste Endanwendererlebnis gewinnt Pacemaker aber bis heute eher nicht, schon weil seine eigenartige interne Syntax für diverse Arten von Anweisungen (Abhängigkeiten zwischen Ressourcen, Reihenfolgen etc.) viele Admins zur Verzweiflung bringt (Abbildung 3). Red Hat geht mittlerweile gar so weit, das Produkt vor den Augen des Admins so gut wie möglich zu verstecken. Wer beispielsweise Red Hat OpenStack Platform (RHOP) kauft, bekommt vom Hersteller einen kompletten Pacemaker-Cluster mit hochkomplexer Konfiguration in Form des Controller-Clusters untergejubelt. Den wird er im Klein-Klein der alltäglichen Systemadministration aber kaum bemerken.

Abbildung 3: Ein klassisches Pacemaker-Setup mit etlichen virtuellen Instanzen, wie es bis heute nur bei den wenigsten Admins auf Gegenliebe stößt.

Bei Linbit hat man freilich weniger Möglichkeiten, die User Experience in Sachen Pacemaker zu steuern. Wegen der beschriebenen Komplexität war der Dienst den Wienern auch bisher schon ein Dorn im Auge. Linbit hat deshalb nun DRBD Reactor an den Start gebracht, das nicht weniger vorhat, als Pacemaker zumindest in einfachen Anwendungsszenarien mit DRBD 9 zu ersetzen.

Reactor, weil er reagiert

Im Kern handelt es sich bei DRBD Reactor um einen in Rust geschriebenen Daemon, der auf den einzelnen Knoten eines DRBD-9-Clusters die Events der DRBD-Ressourcen verfolgt und je nach Konfiguration eingreift. Bricht die Verbindung zwischen zwei Reactor-Instanzen ab, weil einer der Knoten crasht, sorgen die verbliebenen Reactor-Instanzen beispielsweise dafür, dass nun ausgefallene Dienste erneut gestartet werden. Praktisch: Reactor greift dabei auf vorhandene Systemd-Units zurück, kann wahlweise aber auch die zu Pacemaker gehörenden Resource Agents nutzen. Die Kompatibilitätsschicht dürfte man in Wien vorrangig erdacht haben, um gut gereifte Ressource Agents wie jenen für virtuelle Instanzen weiter verwenden zu können.

Vorteilhaft ist in den Augen der Linbit-Entwickler vor allem der Umstand, dass der Reactor anders als Pacemaker keine eigene Cluster-Kommunikation etabliert, sondern die normalen Netzwerkverbindungen der Systeme nutzt. Anders als für Pacemaker ergibt sich für Reactor so stets derselbe Blick auf die Netzwerksituation wie für alle anderen Dienste.

Die meisten Standardszenarien, für die heute Pacemaker zum Einsatz kommt, lassen sich laut Philipp Reisner von Linbit mit Reactor problemlos bewerkstelligen. Das beschriebene MariaDB-Szenario etwa lässt sich ohne Schwierigkeiten darstellen, und auch das Verwalten virtueller Instanzen stellt Reactor nicht vor Probleme. Auch iSCSI-Targets, ein weiterer regelmäßiger Einsatzbereich für DRBD, seien aus Reactor heraus leicht zu betreiben, betont Reisner. Zudem wäre Reactor nicht Reactor, könnte es nicht auch den Linstor-Controller hochverfügbar betreiben, sodass an dieser Stelle ebenfalls kein Pacemaker mehr zum Einsatz kommt.

Eine Einschränkung gibt es allerdings: Linstor kann nur DRBD-Ressourcen mit aktiviertem Quorum verwalten. Das bedeutet bei DRBD 9 im Augenblick, dass das Volume mindestens drei Mal repliziert sein muss, jeweils also eine Kopie auf einem von drei Systemen vorliegen muss. Wer einen Drei-Knoten-Cluster mit DRBD 9 sein Eigen nennt, kann Reactor testen [2]. Neben den HA-Fähigkeiten bietet Reactor übrigens auch noch ein paar andere Features: Für Prometheus sammelt das Programm beispielsweise Metrikdaten und stellt diese zum Download bereit (Abbildung 4). Dazu greift es intern auf eine Plugin-Architektur zu, die weitere künftige Erweiterungen erlaubt.

Abbildung 4: DRBD Reactor schickt sich nicht nur an, Pacemaker an den Kragen zu gehen, sondern bietet für DRBD auch nützliche Features, etwa das Bereitstellen von Metrikdaten für Prometheus. Quelle: Linbit

Fazit

Es muss nicht immer Ceph sein, wenn es um das Replizieren von Daten zwischen Systemen mit Linux (oder Windows) geht. DRBD 9 stellt das recht eindrucksvoll klar und punktet im Vergleich mit dem Klassenprimus in gleich mehreren Belangen. Die bereits beschriebene, bei DRBD 9 viel geringere implizite Komplexität erweist sich gerade dann als wichtiger Faktor, wenn Dinge mal schiefgehen und Debugging angesagt ist. In mancher Hinsicht lässt DRBD die Konkurrenz gerade durch die geringere Komplexität weit hinter sich, etwa in Sachen Latenz. Das gilt bei Ethernet und noch viel mehr bei RDMA over Infiniband (Abbildung 5), das DRBD 9 ebenfalls unterstützt.

Abbildung 5: In mancherlei Hinsicht ist DRBD anderen Lösungen wie Ceph klar überlegen, zum Beispiel bei der Latenz, die sich durch andere Transport-Layer wie RDMA over Infiniband noch besser optimieren lässt. Quelle: Linbit

Dass Linbit parallel DRBD 9 zumindest in einfacher Form auf Windows portiert hat und eine Riege von runderneuerten Userspace-Werkzeugen anbietet, wirkt da nur konsequent und ist auch die Reaktion auf einen tatsächlichen Bedarf. Ob Reactor wirklich Pacemaker in irgendeiner Form gefährlich werden kann, muss sich erst herausstellen. Die Bereitschaft bei Pacemaker-geplagten Admins, sich Alternativen anzusehen, dürfte jedenfalls gegeben sein. Wenn es Linbit nun noch gelingt, das Produkt zu vermarkten – eine Aufgabe, mit der sich die Firma chronisch schwertut – könnte aus Reactor etwas werden.

Apropos Schwäche: Ausruhen sollte Linbit sich auf den Erfolgen der jüngsten Vergangenheit jedenfalls nicht, denn wo Licht ist, ist auch Schatten. Bis heute ist es dem Anbieter etwa nicht gelungen, die Quellen für DRBD 9 endlich zum Bestandteil des offiziellen Linux-Kernels zu machen: Dort gammelt bis heute DRBD 8 vor sich hin. Anstrengungen in diese Richtung hat Linbit bereits Mitte 2019 unternommen, als man den DRBD-Quelltext auf ein neues Build-System umstellte. Groteskerweise ist es laut Aussage der Entwickler seither sogar schwieriger, DRBD 9 out of tree zu kompilieren; dafür soll das Framework die Integration in den offiziellen Kernel vereinfachen. Geliefert hat man hier bis heute aber nicht – schade eigentlich. (jcb)