[DRBD-user] Complete decoupling of LINSTOR from DRBD (Q1 2019)

[Lars Ellenberg]

On Fri, Nov 23, 2018 at 11:55:32AM +0100, Robert Altnoeder wrote:
> On 11/23/18 11:00 AM, Michael Hierweck wrote:
> > Linbit announces the complete decoupling of LINSTOR from DRBD (Q1 2019).
> > [...]
> > Does this mean Linbit will abandon DRBD?
> 
> Not at all,

TL;DR:

Marketing:
	AllThingsNew Corp. announces that SuperCoolCocktailMixer will
	decouple the Mixer from the Cocktail part in Q1 2019.

Reader: Does that mean that AllThingsNew Corp. will abandon Cocktails?

Techie: Not at all, [long text]

Lars:
	Cocktails not longer required means
	SuperCoolMixer can now do *more* things, not less.

	SuperCoolMixer will be able to mix stuff other than Cocktails.
	But it can still mix cocktails as well.

> it just means that LINSTOR will be able to run on systems
> where DRBD is not installed, and will be able to manage storage devices
> that do not use DRBD for replication.
> Originally, LINSTOR was designed to manage DRBD storage, and the
> Satellite currently tracks (and requires tracking of) the DRBD event
> streams. Future versions will still be able to manage DRBD storage, but
> could also be used to manage different kinds of storage.
> 
> This affects the LINSTOR Satellite module primarily. The LINSTOR
> Controller has not been particularly dependent on specific platforms or
> on the availability of DRBD from the beginning (in fact, I've run the
> Controller on Mac OS X a couple times during development).
> 
> > (What technologies might replace or co-exist DBRD
> > in an LINSTOR cluster?)
> 
> Typically any kind of block storage, the required storage management
> drivers are dynamically loadable in LINSTOR (they are plugins, more or
> less).
> The future storage management will work in multiple layers, e.g. you
> could have a DRBD on top of an encrypted, deduplicated ZFS volume by
> means of stacking the various storage drivers. Or maybe you'll just run
> a non-replicated local LVM logical volume, but still managed by LINSTOR.