Re: [DRBD-user] DRBD versus bcache and caching in general.Amen

2017-09-06 Thread Christian Balzer 

Hello,

On Wed, 6 Sep 2017 14:23:05 +0200 Emmanuel Florac wrote:

> Le Wed, 6 Sep 2017 10:37:42 +0900
> Christian Balzer  écrivait:
> 
> > And once again, the deafening silence shall be broken by replying to
> > myself.  
> 
> Don't be bitter :)
>  
It's therapeutic. ^o^

> > The below is all on Debian Stretch with a 4.11 kernel.
> > 
> > I tested bcache w/o DRBD initially and the performance as well as
> > default behavior (not caching large IOs) was quite good and a perfect
> > fit for my use case (mailbox servers). 
> > 
> > This was true in combination with DRBD as well.
> > 
> > However it turns out that bcache will not work out of the box with
> > DRBD thanks to the slightly inane requirement by its udev helper to
> > identify things with lsblk. 
> > Which identifies the backing device as DRBD after a reboot and thus
> > doesn't auto-assemble the bcache device.
> > Hacking that udev rule or simply registering the backing device in
> > rc.local will do the trick, but it felt crude.  
> 
> In the contrary, this looks like perfectly sane Unix-fu to me. Worse is
> better, remember? Seriously, udev rules are made easy to write
> precisely for all these possible border cases.
>
I wasn't particular intimidated by the prospect of changing that udev
rule, but potentially having it overwritten by an upgrade left me with the
rc.local hack. 
Incidentally if I wouldn't be using pacemaker and thus DRBD being started 
very late in the game, the sequencing of udev rules might prevent things
from working anyway:
65-drbd.rules
69-bcache.rules
 
> > So I tried dm-cache, which doesn't have that particular issue.
> > But then again, the complexity of it (lvm in general), the vast
> > changes between versions and documentation gotchas, the fact that a
> > package required to assemble things at boot time wasn't
> > "required" (thin-provisioning-tools) also made this a rather painful
> > and involved experience compared to bache.   
> 
> That, and its performance sucks. In fact I couldn't get any significant
> gain using dm-cache, while bcache is very easily tuned to provide high
> gains. Hail bcache.
> 
> > Its performance is significantly lower and very spiky, with fio stdev
> > an order of magnitude higher than bcache.  
> 
> My opinion precisely.
> 
> > For example I could run 2 fio processes doing 4k randwrites capped to
> > 5k IOPS each (so 10k total) on top of the bcache DRBD indefinitely
> > with the backing device never getting busier than 10% when flushing
> > commenced. This test on the same HW with dm-cache yielded 8K IOPS
> > max, with high fluctuations and both the cache and backing devices
> > getting pegged at 100% busy at times.
> > 
> > What finally broke the straw was that with dm-cache, formatting the
> > drbd device with ext4 hung things to the point of requiring a forced
> > reboot. This was caused by mkfs.ext4 trying to discard blocks (same
> > for bcache), which is odd, but then again should just work (it does
> > for bcache). Formatting with nodiscard works and the dm-cache drbd
> > device then doesn't support fstrim when mounted, unlike bcache.
> >  
> > So I've settled for bcache at this time, the smoother performance is
> > worth the rc.local hack in my book.  
> 
> Amen to that.
> 
Another update to that, I managed to crash/reboot the primary DRBD node
when doing an e4defrag against the bcache'ed DRBD device. 
So don't do that, I guess.

> As I missed your previous post I'll reply below just in case my opinion
> may matter :)
> 
See below.

> > Christian
> > 
> > On Wed, 16 Aug 2017 12:37:21 +0900 Christian Balzer wrote:
> >   
> > > Hello,
> > > 
> > > firstly let me state that I of course read the old thread from 2014
> > > and all the other bits I could find.
> > > 
> > > If anybody in the last 3 years actually deployed bcache or any of
> > > the other SSD caching approaches with DRBD, I'd love to hear about
> > > it.
> > > 
> > > I'm looking to use bcache with DRBD in the near future and was
> > > pondering the following scenarios, not all bcache specific.
> > > 
> > > The failure case I'm most interested in is a node going down due to
> > > HW or kernel issues, as that's the only case I encountered in 10
> > > years. ^.^
> > > 
> > > 
> > > 1. DRBD -> RAID HW cache -> HDD
> > > 
> > > This is what I've been using for long time (in some cases w/o RAID
> > > controller and thus HW cache). 
> > > If node A spontaneously reboots due to a HW failure or kernel crash,
> > > things will fail over to node B, which is in best possible and up to
> > > date state at this point.
> > > Data in the HW cache (and the HDD local cache) is potentially lost.
> > > From the DRBD perspective block X has been successfully written to
> > > node A and B, even though it just reached the HW cache of the RAID
> > > controller. So in the worst case scenario (HW cache
> > > lost/invalidated, HDD caches also lost), we've just lost up to
> > > 4-5GB worth of in-flight data. And unless something changed

Re: [DRBD-user] DRBD over ZFS - or the other way around?

2017-09-06 Thread Gionatan Danti 

Il 06-09-2017 16:22 David Bruzos ha scritto:

I've used DRBD devices on top of ZFS zvols for years now and have been
very satisfied with the performance and possibilities that that
configuration allows for.  I use DRBD 8.x on ZFS latest mainly on Xen
hypervisors running a mix a Linux and Windows VMs with both SSD and
mechanical drives.  I've also done similar things in the past with
DRBD and LVM.  The DRBD on ZFS conbination is the most flexible and
elegant.  You can use snapshotting and streams to do data migrations
across the Internet with minimal down time while getting storage level
redundancy and integrity from ZFS and realtime replication from DRBD.
A few scripts can automate the creation/removal of devices and
coordinate VM migrations and things will just work.  Also, you can
then use ZFS streams for offsite backups (if you need that kind of
thing).
Another thing is that you may not need the realtime replication for
some workloads, so in those cases you can just run directly on ZFS and
omit the DRBD device.  At least for me, that great flexibility is what
makes running my own configuration worth it.

Just my 25 cents!

David


Hi David,
thank you for your input. It was greatly appreciated.

Regards.

--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.da...@assyoma.it - i...@assyoma.it
GPG public key ID: FF5F32A8
___
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user

Re: [DRBD-user] DRBD over ZFS - or the other way around?

2017-09-06 Thread Gionatan Danti 

Il 06-09-2017 16:03 Yannis Milios ha scritto:

...I mean by cloning it first, since snapshot does not appear as
blockdev to the system but the clone does.


Hi, this is incorrect: ZVOL snapshots surely can appear as regular block 
devices. You simply need to set the "snapdev=visible" property.


Regards.

--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.da...@assyoma.it - i...@assyoma.it
GPG public key ID: FF5F32A8
___
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user

Re: [DRBD-user] DRBD over ZFS - or the other way around?

2017-09-06 Thread David Bruzos 
I've used DRBD devices on top of ZFS zvols for years now and have been very 
satisfied with the performance and possibilities that that configuration allows 
for.  I use DRBD 8.x on ZFS latest mainly on Xen hypervisors running a mix a 
Linux and Windows VMs with both SSD and mechanical drives.  I've also done 
similar things in the past with DRBD and LVM.  The DRBD on ZFS conbination is 
the most flexible and elegant.  You can use snapshotting and streams to do data 
migrations across the Internet with minimal down time while getting storage 
level redundancy and integrity from ZFS and realtime replication from DRBD.
A few scripts can automate the creation/removal of devices and coordinate VM 
migrations and things will just work.  Also, you can then use ZFS streams for 
offsite backups (if you need that kind of thing).
Another thing is that you may not need the realtime replication for some 
workloads, so in those cases you can just run directly on ZFS and omit the DRBD 
device.  At least for me, that great flexibility is what makes running my own 
configuration worth it.

Just my 25 cents!

David

-- 
David Bruzos (Systems Administrator)
Jacksonville Port Authority
2831 Talleyrand Ave.
Jacksonville, FL  32206
Cell: (904) 625-0969
Office: (904) 357-3069
Email: david.bru...@jaxport.com

On Wed, Sep 06, 2017 at 03:03:32PM +0100, Yannis Milios wrote:
> ...I mean by cloning it first, since snapshot does not appear as blockdev
> to the system but the clone does.
> 
> On Wed, Sep 6, 2017 at 2:58 PM, Yannis Milios 
> wrote:
> 
> > Even in that case I would prefer to assemble a new DRBD device ontop of
> > the ZVOL snapshot and then mount the DRBD device instead :)
> >
> > On Wed, Sep 6, 2017 at 2:56 PM, Gionatan Danti  wrote:
> >
> >> On 06/09/2017 15:31, Yannis Milios wrote:
> >>
> >>> If your topology is like the following:  HDD -> ZFS (ZVOL) -> DRBD ->
> >>> XFS then I believe it should make sense to always mount at the DRBD level
> >>> and not at the ZVOL level which happens to be the underlying blockdev for
> >>> DRBD.
> >>>
> >> Sure! Directly mounting the DRBD-backing ZVOL would, at the bare minumum,
> >> ruin the replication with the peer.
> >>
> >> I was speaking about mounting ZVOLs *snapshots* to access previous data
> >> version.
> >>
> >> Regards.
> >>
> >>
> >> --
> >> Danti Gionatan
> >> Supporto Tecnico
> >> Assyoma S.r.l. - www.assyoma.it
> >> email: g.da...@assyoma.it - i...@assyoma.it
> >> GPG public key ID: FF5F32A8
> >>
> >
> >

> ___
> drbd-user mailing list
> drbd-user@lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/drbd-user


-- 


Please note that under Florida's public records law (F.S. 668.6076), most 
written communications 
to or from the Jacksonville Port Authority are public records, available to 
the public and media 
upon request. Your email communications may therefore be subject to public 
disclosure. If you have 
received this email in error, please notify the sender by return email and 
delete immediately 
without forwarding to others.
___
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user

Re: [DRBD-user] DRBD over ZFS - or the other way around?

2017-09-06 Thread Yannis Milios 
...I mean by cloning it first, since snapshot does not appear as blockdev
to the system but the clone does.

On Wed, Sep 6, 2017 at 2:58 PM, Yannis Milios 
wrote:

> Even in that case I would prefer to assemble a new DRBD device ontop of
> the ZVOL snapshot and then mount the DRBD device instead :)
>
> On Wed, Sep 6, 2017 at 2:56 PM, Gionatan Danti  wrote:
>
>> On 06/09/2017 15:31, Yannis Milios wrote:
>>
>>> If your topology is like the following:  HDD -> ZFS (ZVOL) -> DRBD ->
>>> XFS then I believe it should make sense to always mount at the DRBD level
>>> and not at the ZVOL level which happens to be the underlying blockdev for
>>> DRBD.
>>>
>> Sure! Directly mounting the DRBD-backing ZVOL would, at the bare minumum,
>> ruin the replication with the peer.
>>
>> I was speaking about mounting ZVOLs *snapshots* to access previous data
>> version.
>>
>> Regards.
>>
>>
>> --
>> Danti Gionatan
>> Supporto Tecnico
>> Assyoma S.r.l. - www.assyoma.it
>> email: g.da...@assyoma.it - i...@assyoma.it
>> GPG public key ID: FF5F32A8
>>
>
>
___
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user

Re: [DRBD-user] DRBD over ZFS - or the other way around?

2017-09-06 Thread Yannis Milios 
Even in that case I would prefer to assemble a new DRBD device ontop of the
ZVOL snapshot and then mount the DRBD device instead :)

On Wed, Sep 6, 2017 at 2:56 PM, Gionatan Danti  wrote:

> On 06/09/2017 15:31, Yannis Milios wrote:
>
>> If your topology is like the following:  HDD -> ZFS (ZVOL) -> DRBD -> XFS
>> then I believe it should make sense to always mount at the DRBD level and
>> not at the ZVOL level which happens to be the underlying blockdev for DRBD.
>>
> Sure! Directly mounting the DRBD-backing ZVOL would, at the bare minumum,
> ruin the replication with the peer.
>
> I was speaking about mounting ZVOLs *snapshots* to access previous data
> version.
>
> Regards.
>
>
> --
> Danti Gionatan
> Supporto Tecnico
> Assyoma S.r.l. - www.assyoma.it
> email: g.da...@assyoma.it - i...@assyoma.it
> GPG public key ID: FF5F32A8
>
___
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user

Re: [DRBD-user] DRBD over ZFS - or the other way around?

2017-09-06 Thread Gionatan Danti 

On 06/09/2017 15:31, Yannis Milios wrote:
If your topology is like the following:  HDD -> ZFS (ZVOL) -> DRBD -> 
XFS then I believe it should make sense to always mount at the DRBD 
level and not at the ZVOL level which happens to be the underlying 
blockdev for DRBD.
Sure! Directly mounting the DRBD-backing ZVOL would, at the bare 
minumum, ruin the replication with the peer.


I was speaking about mounting ZVOLs *snapshots* to access previous data 
version.


Regards.

--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.da...@assyoma.it - i...@assyoma.it
GPG public key ID: FF5F32A8
___
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user

Re: [DRBD-user] DRBD over ZFS - or the other way around?

2017-09-06 Thread Gionatan Danti 

Hi,

On 06/09/2017 13:28, Jan Schermer wrote:

Not sure you can mount snapshot (I always create a clone).


the only difference is that snapshots are read-only, while clones are 
read-write. This is why I used the "-o ro,norecovery" option while 
mounting XFS.



However I never saw anything about “drbd” filesystem - what distribution is 
this? Apparently it tries to be too clever…


It is a CentOS 7.3 x86_64. Actually, I *really* like what the mount 
command is doing: by checking at the device end and discovering the DRBD 
metadata, it prevent accidental double mounts of the main (DRBD-backing) 
block device.


I was only wondering if it is something that only happens to me, or it 
is "normal" to specify the mounting filesystem when using snapshot 
volumes with DRBD.


Regards.


--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.da...@assyoma.it - i...@assyoma.it
GPG public key ID: FF5F32A8
___
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user

Re: [DRBD-user] DRBD over ZFS - or the other way around?

2017-09-06 Thread Yannis Milios 
If your topology is like the following:  HDD -> ZFS (ZVOL) -> DRBD -> XFS
then I believe it should make sense to always mount at the DRBD level and
not at the ZVOL level which happens to be the underlying blockdev for DRBD.

On Wed, Sep 6, 2017 at 12:28 PM, Jan Schermer  wrote:

> Not sure you can mount snapshot (I always create a clone).
> However I never saw anything about “drbd” filesystem - what distribution
> is this? Apparently it tries to be too clever…
> Try creating a clone and mounting it instead, it’s safer anyway (saw bug
> in issue tracker that ZFS panics if you try to write to the snapshot or
> something like that…)
>
> Other than that - yes, this should work fine.
>
> Jan
>
>
> > On 6 Sep 2017, at 13:23, Gionatan Danti  wrote:
> >
> > On 19/08/2017 10:24, Yannis Milios wrote:
> >> Option (b) seems more suitable for a 2 node drbd8 cluster in a
> primary/secondary setup. Haven't tried it so I cannot tell if there are any
> clurpits. My only concern in such setup would be if drbd corrupts silently
> the data on the lower level and zfs is not aware of that.Also, if you are
> *not* going to use live migration, and you can affort loosing some seconds
> of data on the secondary node in favor of better performance in the primary
> node, then you could consider using protocol A instead of C for the
> replication link.
> >
> > Hi all,
> > I "revive" this old thread to let you know I settled to use DRBD 8.4 on
> top of ZVOLs.
> >
> > I have a question for anyone using DRBD on top of a snapshot-capable
> backend (eg: ZFS, LVM, etc)...
> >
> > When snapshotting a DRBD block device, trying to mount it (the snapshot,
> not the original volume!) results in the following error message:
> >
> > [root@master7 tank]# mount /dev/zvol/tank/vol1\@snap1 /mnt/
> > mount: unknown filesystem type 'drbd'
> >
> > To successfully mount the snapshot volume, I need to specify the volume
> filesystem, for example (the other options are xfs-specific):
> >
> > [root@master7 tank]# mount -t xfs /dev/zvol/tank/vol1\@snap1 /mnt/ -o
> ro,norecovery,nouuid
> >
> > Is that the right approach? Or I am missing something?
> > Thanks.
> >
> > --
> > Danti Gionatan
> > Supporto Tecnico
> > Assyoma S.r.l. - www.assyoma.it
> > email: g.da...@assyoma.it - i...@assyoma.it
> > GPG public key ID: FF5F32A8
> > ___
> > drbd-user mailing list
> > drbd-user@lists.linbit.com
> > http://lists.linbit.com/mailman/listinfo/drbd-user
>
>
___
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user

Re: [DRBD-user] DRBD versus bcache and caching in general.Amen

2017-09-06 Thread Emmanuel Florac 
Le Wed, 6 Sep 2017 10:37:42 +0900
Christian Balzer  écrivait:

> And once again, the deafening silence shall be broken by replying to
> myself.

Don't be bitter :)
 
> The below is all on Debian Stretch with a 4.11 kernel.
> 
> I tested bcache w/o DRBD initially and the performance as well as
> default behavior (not caching large IOs) was quite good and a perfect
> fit for my use case (mailbox servers). 
> 
> This was true in combination with DRBD as well.
> 
> However it turns out that bcache will not work out of the box with
> DRBD thanks to the slightly inane requirement by its udev helper to
> identify things with lsblk. 
> Which identifies the backing device as DRBD after a reboot and thus
> doesn't auto-assemble the bcache device.
> Hacking that udev rule or simply registering the backing device in
> rc.local will do the trick, but it felt crude.

In the contrary, this looks like perfectly sane Unix-fu to me. Worse is
better, remember? Seriously, udev rules are made easy to write
precisely for all these possible border cases.

> So I tried dm-cache, which doesn't have that particular issue.
> But then again, the complexity of it (lvm in general), the vast
> changes between versions and documentation gotchas, the fact that a
> package required to assemble things at boot time wasn't
> "required" (thin-provisioning-tools) also made this a rather painful
> and involved experience compared to bache. 

That, and its performance sucks. In fact I couldn't get any significant
gain using dm-cache, while bcache is very easily tuned to provide high
gains. Hail bcache.

> Its performance is significantly lower and very spiky, with fio stdev
> an order of magnitude higher than bcache.

My opinion precisely.

> For example I could run 2 fio processes doing 4k randwrites capped to
> 5k IOPS each (so 10k total) on top of the bcache DRBD indefinitely
> with the backing device never getting busier than 10% when flushing
> commenced. This test on the same HW with dm-cache yielded 8K IOPS
> max, with high fluctuations and both the cache and backing devices
> getting pegged at 100% busy at times.
> 
> What finally broke the straw was that with dm-cache, formatting the
> drbd device with ext4 hung things to the point of requiring a forced
> reboot. This was caused by mkfs.ext4 trying to discard blocks (same
> for bcache), which is odd, but then again should just work (it does
> for bcache). Formatting with nodiscard works and the dm-cache drbd
> device then doesn't support fstrim when mounted, unlike bcache.
>  
> So I've settled for bcache at this time, the smoother performance is
> worth the rc.local hack in my book.

Amen to that.

As I missed your previous post I'll reply below just in case my opinion
may matter :)

> Christian
> 
> On Wed, 16 Aug 2017 12:37:21 +0900 Christian Balzer wrote:
> 
> > Hello,
> > 
> > firstly let me state that I of course read the old thread from 2014
> > and all the other bits I could find.
> > 
> > If anybody in the last 3 years actually deployed bcache or any of
> > the other SSD caching approaches with DRBD, I'd love to hear about
> > it.
> > 
> > I'm looking to use bcache with DRBD in the near future and was
> > pondering the following scenarios, not all bcache specific.
> > 
> > The failure case I'm most interested in is a node going down due to
> > HW or kernel issues, as that's the only case I encountered in 10
> > years. ^.^
> > 
> > 
> > 1. DRBD -> RAID HW cache -> HDD
> > 
> > This is what I've been using for long time (in some cases w/o RAID
> > controller and thus HW cache). 
> > If node A spontaneously reboots due to a HW failure or kernel crash,
> > things will fail over to node B, which is in best possible and up to
> > date state at this point.
> > Data in the HW cache (and the HDD local cache) is potentially lost.
> > From the DRBD perspective block X has been successfully written to
> > node A and B, even though it just reached the HW cache of the RAID
> > controller. So in the worst case scenario (HW cache
> > lost/invalidated, HDD caches also lost), we've just lost up to
> > 4-5GB worth of in-flight data. And unless something changed those
> > blocks on node B before node A comes back up, they will not be
> > replicated back.
> > 
> > Is the above a correct, possible scenario?

As I understand this scenario, you suppose that both your DRBD nodes
have HW RAID controllers, that the node 1 fails, prompting a fail
over to node B, then node B fails immediately? You shouldn't lose
anything, provided that your HW RAID controller has a BBU, therefore
CAN'T lose its cache.

Really, use a BBU. Or did I miss something?

> > 
> > As far as read caches are concerned, I'm pretty sure the HW caches
> > get invalidated in regards to reads when a crash/reboot happens.
> > 
> > 
> > 2. Bcache -> DRBD -> HW cache -> HDD
> > 
> > With bcache in writeback mode things become interesting in the
> > Chinese sense. 
> > If node A crashes, not only do we loose all the dirty

Re: [DRBD-user] DRBD over ZFS - or the other way around?

2017-09-06 Thread Jan Schermer 
Not sure you can mount snapshot (I always create a clone).
However I never saw anything about “drbd” filesystem - what distribution is 
this? Apparently it tries to be too clever…
Try creating a clone and mounting it instead, it’s safer anyway (saw bug in 
issue tracker that ZFS panics if you try to write to the snapshot or something 
like that…)

Other than that - yes, this should work fine.

Jan


> On 6 Sep 2017, at 13:23, Gionatan Danti  wrote:
> 
> On 19/08/2017 10:24, Yannis Milios wrote:
>> Option (b) seems more suitable for a 2 node drbd8 cluster in a 
>> primary/secondary setup. Haven't tried it so I cannot tell if there are any 
>> clurpits. My only concern in such setup would be if drbd corrupts silently 
>> the data on the lower level and zfs is not aware of that.Also, if you are 
>> *not* going to use live migration, and you can affort loosing some seconds 
>> of data on the secondary node in favor of better performance in the primary 
>> node, then you could consider using protocol A instead of C for the 
>> replication link.
> 
> Hi all,
> I "revive" this old thread to let you know I settled to use DRBD 8.4 on top 
> of ZVOLs.
> 
> I have a question for anyone using DRBD on top of a snapshot-capable backend 
> (eg: ZFS, LVM, etc)...
> 
> When snapshotting a DRBD block device, trying to mount it (the snapshot, not 
> the original volume!) results in the following error message:
> 
> [root@master7 tank]# mount /dev/zvol/tank/vol1\@snap1 /mnt/
> mount: unknown filesystem type 'drbd'
> 
> To successfully mount the snapshot volume, I need to specify the volume 
> filesystem, for example (the other options are xfs-specific):
> 
> [root@master7 tank]# mount -t xfs /dev/zvol/tank/vol1\@snap1 /mnt/ -o 
> ro,norecovery,nouuid
> 
> Is that the right approach? Or I am missing something?
> Thanks.
> 
> -- 
> Danti Gionatan
> Supporto Tecnico
> Assyoma S.r.l. - www.assyoma.it
> email: g.da...@assyoma.it - i...@assyoma.it
> GPG public key ID: FF5F32A8
> ___
> drbd-user mailing list
> drbd-user@lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/drbd-user

___
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user

Re: [DRBD-user] DRBD over ZFS - or the other way around?

2017-09-06 Thread Gionatan Danti 

On 19/08/2017 10:24, Yannis Milios wrote:
Option (b) seems more suitable for a 2 node drbd8 cluster in a 
primary/secondary setup. Haven't tried it so I cannot tell if there are 
any clurpits. My only concern in such setup would be if drbd corrupts 
silently the data on the lower level and zfs is not aware of that.Also, 
if you are *not* going to use live migration, and you can affort loosing 
some seconds of data on the secondary node in favor of better 
performance in the primary node, then you could consider using protocol 
A instead of C for the replication link.


Hi all,
I "revive" this old thread to let you know I settled to use DRBD 8.4 on 
top of ZVOLs.


I have a question for anyone using DRBD on top of a snapshot-capable 
backend (eg: ZFS, LVM, etc)...


When snapshotting a DRBD block device, trying to mount it (the snapshot, 
not the original volume!) results in the following error message:


[root@master7 tank]# mount /dev/zvol/tank/vol1\@snap1 /mnt/
mount: unknown filesystem type 'drbd'

To successfully mount the snapshot volume, I need to specify the volume 
filesystem, for example (the other options are xfs-specific):


[root@master7 tank]# mount -t xfs /dev/zvol/tank/vol1\@snap1 /mnt/ -o 
ro,norecovery,nouuid


Is that the right approach? Or I am missing something?
Thanks.

--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.da...@assyoma.it - i...@assyoma.it
GPG public key ID: FF5F32A8
___
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user

[DRBD-user] DRDB9 slaves hang on wait-connect

2017-09-06 Thread Zbigniew Kostrzewa 

Hi all,

I am trying to setup a 3-node cluster with DRBD9. The nodes are VMs on 
KVM with CentOS 7.2. I followed manual from 
http://docs.linbit.com/docs/users-guide-9.0/#ch-admin-drbdmanage to 
initialize the cluster and add nodes to it. I don't have password-less 
SSH authentication between the nodes so I first add the slave nodes on 
the master node and call the join command returned by `drbdmanage 
add-node` on the slave nodes. Storage is LVM with non-default pool name 
configured in /etc/drbdmanaged.cfg.


RPMs with DRBD are built from latest tags (drbd: 9.0.9, drbd-utils: 
9.1.0, drbdmanage: 0.99.10).


To setup the cluster automatically I use ansible. The roles for master 
and slave are very simple, the commands they run are pretty much these:


master
--

drbdmanage init --quiet [IP_ADDRESS]

slaves
--

drbdmanage add-node -j [HOSTNAME] [IP_ADDRESS] (executed on master)

[JOIN COMMAND PRINTED BY "ADD NODE"]

drbdadm wait-connect .drbdctrl

drbdadm wait-sync .drbdctrl

I use `wait-connect`/`wait-sync` because I need to be sure that when 
ansible is done the cluster is fully operational. The problem is that 
quite often the commands block indefinitely (sometimes `wait-connect`, 
sometimes `wait-sync`). What helps, most of the time, is to run `drbdadm 
adjust all` on master node. After that the cluster synchronizes and 
calls to `wait-connect`/`wait-sync` return. However, I assume that this 
step should not be needed - it is not mentioned in the manual at least. 
But since DRBD is a new thing for me it is highly likely that I am 
missing something, some options in the configuration I should set(?) 
some commands I should additionally execute (or maybe `adjust all` is 
needed after all?). I would appreciate any help with this, thanks.


Anything related to DRBD found in syslog:
- master: 
https://raw.githubusercontent.com/localghost/issues/master/drbd/wait_connect_hangs/10.9.4.216/syslog_drbd.log

- slaves:
* 
https://raw.githubusercontent.com/localghost/issues/master/drbd/wait_connect_hangs/10.9.4.166/syslog_drbd.log
* 
https://raw.githubusercontent.com/localghost/issues/master/drbd/wait_connect_hangs/10.9.4.231/syslog_drbd.log


I have also collected DRBD configuration, output from `drbd-overview`, 
`drbdadm status`, `drbdsetup show` on 
https://github.com/localghost/issues/tree/master/drbd/wait_connect_hangs. 
If any other logs could be helpful I can re-produce the issue and upload 
more logs anytime.


Regards,

Zbigniew Kostrzewa

___
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user