Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: DRBD: Users

protocol B in dual-primary mode

 

 

DRBD users RSS feed   Index | Next | Previous | View Threaded


jon at host-it

Dec 23, 2008, 4:57 AM

Post #1 of 15 (2580 views)
Permalink
protocol B in dual-primary mode

Hey guys,

What's the correct procedure for changing to protocol B? From a working
protocol C setup? (in dual primary? - i tried once a over the weekend but
the second node said it couldn't come back up as it needed protocol C? I
don't have the specific error to hand now)

The second box is at the end of a dedicated 100mbit backhaul (3 router hops,
2-3ms latency) so hopefully B will speed things up a little.

I searched documentation but didn't see anything specific to this.

Thanks

jduggan





_______________________________________________
drbd-user mailing list
drbd-user [at] lists
http://lists.linbit.com/mailman/listinfo/drbd-user


michael at gsc

Jan 6, 2009, 2:48 PM

Post #2 of 15 (2452 views)
Permalink
Re: protocol B in dual-primary mode [In reply to]

However, if you still decide you want to do it (clustered filesystem caveats ignored), I just did this by changing the drbd.conf, and using drbdadm adjust (must be done on both nodes). Though, I did not do this with a dual primary, you may need to take one node to secondary status.

Michael


lars.ellenberg at linbit

Jan 7, 2009, 12:53 AM

Post #3 of 15 (2420 views)
Permalink
Re: protocol B in dual-primary mode [In reply to]

On Tue, Jan 06, 2009 at 02:48:17PM -0800, Michael Moody wrote:
> However, if you still decide you want to do it (clustered filesystem
> caveats ignored), I just did this by changing the drbd.conf, and using
> drbdadm adjust (must be done on both nodes). Though, I did not do this
> with a dual primary, you may need to take one node to secondary
> status.

in dual primary mode, only protocol C is allowed.

cluster file system deals with cache coherence,
DRBD has to deal with storage coherence.
you cannot do that asynchronously.

to do that in protocol B, the receiving node would need to be able to
access data of in-flight requests, which is not implemented.

--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
__
please don't Cc me, but send to list -- I'm subscribed
_______________________________________________
drbd-user mailing list
drbd-user [at] lists
http://lists.linbit.com/mailman/listinfo/drbd-user


ff at mpexnet

Dec 13, 2011, 1:43 AM

Post #4 of 15 (1587 views)
Permalink
Re: protocol B in dual-primary mode [In reply to]

Hi,

On 12/13/2011 05:35 AM, Marcus Sorensen wrote:
> What if you're just
> exporting drbd block, active-active devices via say, iscsi or SAS
> target? Couldn't the initiator just treat them as the same disk,
> multipathed?

there was a lengthy discussion last week or the one prior on why you
cannot do that. Long story short, two state of the art iSCSI targets
cannot operate as one multipath target.
I can't seem to find it quite on the spot, but a quick trawl through the
archives should yield some info.

Cheers,
Felix
_______________________________________________
drbd-user mailing list
drbd-user [at] lists
http://lists.linbit.com/mailman/listinfo/drbd-user


lars.ellenberg at linbit

Dec 13, 2011, 3:40 AM

Post #5 of 15 (1587 views)
Permalink
Re: protocol B in dual-primary mode [In reply to]

On Mon, Dec 12, 2011 at 09:35:01PM -0700, Marcus Sorensen wrote:
> "in dual primary mode, only protocol C is allowed.
>
> cluster file system deals with cache coherence,
> DRBD has to deal with storage coherence.
> you cannot do that asynchronously.
>
> to do that in protocol B, the receiving node would need to be able to
> access data of in-flight requests, which is not implemented."
>
> But what if you're not using a filesystem?

Ok, so you are using "whatever", and you think you want dual-primary DRBD,
but you want it to replicate asynchronously despite of that.

What if "whatever" writes something to node A,
node A completes the write,
and "whatever" has all right to assume this actually hit stable storage.

Then (the same or a different instance of) "whatever" wants to read that
change from node B, but the change is not yet on B, because it
replicated async.

"whatever" would be slightly surprised,
and you would start screaming drbd ate my data.

Well, no, it did not. You screwed up.
And this particular screwup DRBD does not allow.

> What if you're just
> exporting drbd block, active-active devices via say, iscsi or SAS
> target?

As you will find in the archives of this ML, don't do that,
not even with protocol C.

> Couldn't the initiator just treat them as the same disk,
> multipathed? In which case if one of your two DRBD nodes goes down,
> all you care about is that the second node has the writes in memory

*in memory where no block device read can get to, yet*

> (because if the second goes down at the same time you're hosed
> anyway).

So feel free to use protocol B,
and get your "classic" "promote, start services and IPs" failover right.

Note that sometimes B is even slower as C (depends on the actual usage
pattern, the IO backend, and a lot of other things probably).

--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
_______________________________________________
drbd-user mailing list
drbd-user [at] lists
http://lists.linbit.com/mailman/listinfo/drbd-user


shadowsor at gmail

Dec 13, 2011, 7:52 AM

Post #6 of 15 (1589 views)
Permalink
Re: protocol B in dual-primary mode [In reply to]

On Tue, Dec 13, 2011 at 4:40 AM, Lars Ellenberg
<lars.ellenberg [at] linbit> wrote:
> On Mon, Dec 12, 2011 at 09:35:01PM -0700, Marcus Sorensen wrote:
>> "in dual primary mode, only protocol C is allowed.
>>
>> cluster file system deals with cache coherence,
>> DRBD has to deal with storage coherence.
>> you cannot do that asynchronously.
>>
>> to do that in protocol B, the receiving node would need to be able to
>> access data of in-flight requests, which is not implemented."
>>
>> But what if you're not using a filesystem?
>
> Ok, so you are using "whatever", and you think you want dual-primary DRBD,
> but you want it to replicate asynchronously despite of that.
>
> What if "whatever" writes something to node A,
> node A completes the write,
> and "whatever" has all right to assume this actually hit stable storage.
>
> Then (the same or a different instance of) "whatever" wants to read that
> change from node B, but the change is not yet on B, because it
> replicated async.
>
> "whatever" would be slightly surprised,
> and you would start screaming drbd ate my data.
>
> Well, no, it did not. You screwed up.
> And this particular screwup DRBD does not allow.

So you're saying that protocol B, in active-active, would not read
from memory on the second node. So even if we wait until a write to
block 213456 has replicated to memory on node B, if a read comes in
for block 213456 on node B, it's going to go to disk for the read, and
ignore the outstanding write until it's on disk. This is good to know,
and not what I would have expected.
_______________________________________________
drbd-user mailing list
drbd-user [at] lists
http://lists.linbit.com/mailman/listinfo/drbd-user


shadowsor at gmail

Dec 13, 2011, 8:11 AM

Post #7 of 15 (1585 views)
Permalink
Re: protocol B in dual-primary mode [In reply to]

On Tue, Dec 13, 2011 at 8:52 AM, Marcus Sorensen <shadowsor [at] gmail> wrote:
> On Tue, Dec 13, 2011 at 4:40 AM, Lars Ellenberg
> <lars.ellenberg [at] linbit> wrote:
>> On Mon, Dec 12, 2011 at 09:35:01PM -0700, Marcus Sorensen wrote:
>>> "in dual primary mode, only protocol C is allowed.
>>>
>>> cluster file system deals with cache coherence,
>>> DRBD has to deal with storage coherence.
>>> you cannot do that asynchronously.
>>>
>>> to do that in protocol B, the receiving node would need to be able to
>>> access data of in-flight requests, which is not implemented."
>>>
>>> But what if you're not using a filesystem?
>>
>> Ok, so you are using "whatever", and you think you want dual-primary DRBD,
>> but you want it to replicate asynchronously despite of that.
>>
>> What if "whatever" writes something to node A,
>> node A completes the write,
>> and "whatever" has all right to assume this actually hit stable storage.
>>
>> Then (the same or a different instance of) "whatever" wants to read that
>> change from node B, but the change is not yet on B, because it
>> replicated async.
>>
>> "whatever" would be slightly surprised,
>> and you would start screaming drbd ate my data.
>>
>> Well, no, it did not. You screwed up.
>> And this particular screwup DRBD does not allow.
>
> So you're saying that protocol B, in active-active, would not read
> from memory on the second node. So even if we wait until a write to
> block 213456 has replicated to memory on node B, if a read comes in
> for block 213456 on node B, it's going to go to disk for the read, and
> ignore the outstanding write until it's on disk. This is good to know,
> and not what I would have expected.

Ah, for clarification, in protocol B we're not talking about the write
being 'in buffer' waiting to be flushed to disk, but in drbd memory,
correct?
_______________________________________________
drbd-user mailing list
drbd-user [at] lists
http://lists.linbit.com/mailman/listinfo/drbd-user


shadowsor at gmail

Dec 13, 2011, 8:39 AM

Post #8 of 15 (1588 views)
Permalink
Re: protocol B in dual-primary mode [In reply to]

I notice I've hit a nerve ;-) DRBD is a great product, and I realize
it's not a panacea and shouldn't be used in braindead ways. I'm just
trying to understand how it works, and have come across some surprised
(e.g. the in-memory thing, normally when a write is 'in-memory', the
host will also assume that's what's on disk and service a read from
there, not apparently the case with active-active DRBD).

If you've got a target that will run in passthrough mode (where it
does nothing but relay scsi commands to the drbd device), for
infiniband or fibrechannel, and only one client reading/writing, is
there still an issue in protocol C? Everything is relying on the one
client to keep consistency.

I'm only familiar with the basic function of DRBD, but without it, in
a classic multipath scenario you're treating everything as separate
block devices, even though they're the same. Independent target
processes that don't share information, exporting what look to be
separate block devices but same backing store, and the client is able
to write to them independently and expect consistency only because it
is in control of what goes there, just like OCFS2 is in control on top
of active-active DRBD.

I realize this has apparently been a hot button issue, and I apologize
if I sound argumentative, I just want to understand myself. I would
have expected reads to be consistent on both DRBD nodes, and writes to
be so as well (at least in protocol C), so the fact that adding DRBD
suddenly requires my various target threads to talk to each other and
be cluster aware, even though they were already independently acting
on the same storage is something I want to understand. Thanks for the
links and info.
_______________________________________________
drbd-user mailing list
drbd-user [at] lists
http://lists.linbit.com/mailman/listinfo/drbd-user


john.lauro at covenanteyes

Dec 13, 2011, 11:00 AM

Post #9 of 15 (1578 views)
Permalink
Re: protocol B in dual-primary mode [In reply to]

None of the open source targets will handle reservations or block locking.
However, that point is moot when you have a single client multi-pathing to
drbd pair, but reservations are very critical for SAN based filesystems...
Assuming only a single client to two DRBD nodes and doing failover, it is
very risky as the slightest network hiccup can cause a split brain as the
default timeout retries are extremely low and despite having protocol C,
one node might thing the other is down when it is not really. However, if
(and only if) you truly implement STONITH so split brain is impossible, as
far as I can tell you could do multi-pathing despite all of the comments
not to do it.

So two requirements:
1. No multi-node to same resource. (No SAN type filesystem).
2. STONITH must be implemented.
If you meet those two requirements, then it should technically be
possible, but comes down to a why bother with active/active multipath DRBD
at all, and why not just fail over the service on top of DRBD.


> -----Original Message-----
> From: drbd-user-bounces [at] lists [mailto:drbd-user-
> bounces [at] lists] On Behalf Of Felix Frank
> Sent: Tuesday, December 13, 2011 4:44 AM
> To: Marcus Sorensen
> Cc: drbd-user [at] lists
> Subject: Re: [DRBD-user] protocol B in dual-primary mode
>
> Hi,
>
> On 12/13/2011 05:35 AM, Marcus Sorensen wrote:
> > What if you're just
> > exporting drbd block, active-active devices via say, iscsi or SAS
> > target? Couldn't the initiator just treat them as the same disk,
> > multipathed?
>
> there was a lengthy discussion last week or the one prior on why you
> cannot do that. Long story short, two state of the art iSCSI targets
> cannot operate as one multipath target.
> I can't seem to find it quite on the spot, but a quick trawl through the
> archives should yield some info.
>
> Cheers,
> Felix
> _______________________________________________
> drbd-user mailing list
> drbd-user [at] lists
> http://lists.linbit.com/mailman/listinfo/drbd-user
_______________________________________________
drbd-user mailing list
drbd-user [at] lists
http://lists.linbit.com/mailman/listinfo/drbd-user


lars.ellenberg at linbit

Dec 13, 2011, 1:13 PM

Post #10 of 15 (1579 views)
Permalink
Re: protocol B in dual-primary mode [In reply to]

On Tue, Dec 13, 2011 at 09:11:25AM -0700, Marcus Sorensen wrote:
> On Tue, Dec 13, 2011 at 8:52 AM, Marcus Sorensen <shadowsor [at] gmail> wrote:
> > On Tue, Dec 13, 2011 at 4:40 AM, Lars Ellenberg
> > <lars.ellenberg [at] linbit> wrote:
> >> On Mon, Dec 12, 2011 at 09:35:01PM -0700, Marcus Sorensen wrote:
> >>> "in dual primary mode, only protocol C is allowed.
> >>>
> >>> cluster file system deals with cache coherence,
> >>> DRBD has to deal with storage coherence.
> >>> you cannot do that asynchronously.
> >>>
> >>> to do that in protocol B, the receiving node would need to be able to
> >>> access data of in-flight requests, which is not implemented."

^^^
You even quoted the paragraph.
Anything unclear about that?


> >>>
> >>> But what if you're not using a filesystem?
> >>
> >> Ok, so you are using "whatever", and you think you want dual-primary DRBD,
> >> but you want it to replicate asynchronously despite of that.
> >>
> >> What if "whatever" writes something to node A,
> >> node A completes the write,
> >> and "whatever" has all right to assume this actually hit stable storage.
> >>
> >> Then (the same or a different instance of) "whatever" wants to read that
> >> change from node B, but the change is not yet on B, because it
> >> replicated async.
> >>
> >> "whatever" would be slightly surprised,
> >> and you would start screaming drbd ate my data.
> >>
> >> Well, no, it did not. You screwed up.
> >> And this particular screwup DRBD does not allow.
> >
> > So you're saying that protocol B, in active-active, would not read
> > from memory on the second node. So even if we wait until a write to
> > block 213456 has replicated to memory on node B, if a read comes in
> > for block 213456 on node B, it's going to go to disk for the read, and
> > ignore the outstanding write until it's on disk. This is good to know,
> > and not what I would have expected.
>
> Ah, for clarification, in protocol B we're not talking about the write
> being 'in buffer' waiting to be flushed to disk, but in drbd memory,
> correct?
> _______________________________________________
> drbd-user mailing list
> drbd-user [at] lists
> http://lists.linbit.com/mailman/listinfo/drbd-user

--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
__
please don't Cc me, but send to list -- I'm subscribed
_______________________________________________
drbd-user mailing list
drbd-user [at] lists
http://lists.linbit.com/mailman/listinfo/drbd-user


john.lauro at covenanteyes

Dec 13, 2011, 1:25 PM

Post #11 of 15 (1581 views)
Permalink
Re: protocol B in dual-primary mode [In reply to]

IMHO, the web site should make it a little clearer that protocol B is not
safe for active/active even when there is no failure, as from the
description it could (wrongly) be assumed that in memory buffers are in
sync on both nodes:

Protocol B. Memory synchronous (semi-synchronous) replication protocol.
Local write operations on the primary node are considered completed as
soon as the local disk write has occurred, and the replication packet has
reached the peer node. Normally, no writes are lost in case of forced
fail-over. However, in the event of simultaneous power failure on both
nodes and concurrent, irreversible destruction of the primary's data
store, the most recent writes completed on the primary may be lost.



> -----Original Message-----
> From: drbd-user-bounces [at] lists [mailto:drbd-user-
> bounces [at] lists] On Behalf Of Lars Ellenberg
> Sent: Tuesday, December 13, 2011 4:14 PM
> To: drbd-user [at] lists
> Subject: Re: [DRBD-user] protocol B in dual-primary mode
>
> On Tue, Dec 13, 2011 at 09:11:25AM -0700, Marcus Sorensen wrote:
> > On Tue, Dec 13, 2011 at 8:52 AM, Marcus Sorensen <shadowsor [at] gmail>
> wrote:
> > > On Tue, Dec 13, 2011 at 4:40 AM, Lars Ellenberg
> > > <lars.ellenberg [at] linbit> wrote:
> > >> On Mon, Dec 12, 2011 at 09:35:01PM -0700, Marcus Sorensen wrote:
> > >>> "in dual primary mode, only protocol C is allowed.
> > >>>
> > >>> cluster file system deals with cache coherence,
> > >>> DRBD has to deal with storage coherence.
> > >>> you cannot do that asynchronously.
> > >>>
> > >>> to do that in protocol B, the receiving node would need to be able
to
> > >>> access data of in-flight requests, which is not implemented."
>
> ^^^
> You even quoted the paragraph.
> Anything unclear about that?
>
>
> > >>>
> > >>> But what if you're not using a filesystem?
> > >>
> > >> Ok, so you are using "whatever", and you think you want
dual-primary
> DRBD,
> > >> but you want it to replicate asynchronously despite of that.
> > >>
> > >> What if "whatever" writes something to node A,
> > >> node A completes the write,
> > >> and "whatever" has all right to assume this actually hit stable
> storage.
> > >>
> > >> Then (the same or a different instance of) "whatever" wants to read
> that
> > >> change from node B, but the change is not yet on B, because it
> > >> replicated async.
> > >>
> > >> "whatever" would be slightly surprised,
> > >> and you would start screaming drbd ate my data.
> > >>
> > >> Well, no, it did not. You screwed up.
> > >> And this particular screwup DRBD does not allow.
> > >
> > > So you're saying that protocol B, in active-active, would not read
> > > from memory on the second node. So even if we wait until a write to
> > > block 213456 has replicated to memory on node B, if a read comes in
> > > for block 213456 on node B, it's going to go to disk for the read,
and
> > > ignore the outstanding write until it's on disk. This is good to
know,
> > > and not what I would have expected.
> >
> > Ah, for clarification, in protocol B we're not talking about the write
> > being 'in buffer' waiting to be flushed to disk, but in drbd memory,
> > correct?
> > _______________________________________________
> > drbd-user mailing list
> > drbd-user [at] lists
> > http://lists.linbit.com/mailman/listinfo/drbd-user
>
> --
> : Lars Ellenberg
> : LINBIT | Your Way to High Availability
> : DRBD/HA support and consulting http://www.linbit.com
>
> DRBDR and LINBITR are registered trademarks of LINBIT, Austria.
> __
> please don't Cc me, but send to list -- I'm subscribed
> _______________________________________________
> drbd-user mailing list
> drbd-user [at] lists
> http://lists.linbit.com/mailman/listinfo/drbd-user
_______________________________________________
drbd-user mailing list
drbd-user [at] lists
http://lists.linbit.com/mailman/listinfo/drbd-user


lars.ellenberg at linbit

Dec 13, 2011, 1:41 PM

Post #12 of 15 (1580 views)
Permalink
Re: protocol B in dual-primary mode [In reply to]

On Tue, Dec 13, 2011 at 04:25:18PM -0500, John Lauro wrote:
> IMHO, the web site should make it a little clearer that protocol B is not
> safe for active/active even when there is no failure, as from the

As you also quoted already:

> > > >>> "in dual primary mode, only protocol C is allowed.

Does not get much clearer than that, does it.

You can not use protocol b for dual primary.
DRBD will not allow you to do so.

If it does, tell me, as that would be a bug, and needs to be fixed.


> description it could (wrongly) be assumed that in memory buffers are in
> sync on both nodes:
>
> Protocol B. Memory synchronous (semi-synchronous) replication protocol.
> Local write operations on the primary node are considered completed as
> soon as the local disk write has occurred, and the replication packet has
> reached the peer node. Normally, no writes are lost in case of forced
> fail-over. However, in the event of simultaneous power failure on both
> nodes and concurrent, irreversible destruction of the primary's data
> store, the most recent writes completed on the primary may be lost.
>
>
>
> > -----Original Message-----
> > From: drbd-user-bounces [at] lists [mailto:drbd-user-
> > bounces [at] lists] On Behalf Of Lars Ellenberg
> > Sent: Tuesday, December 13, 2011 4:14 PM
> > To: drbd-user [at] lists
> > Subject: Re: [DRBD-user] protocol B in dual-primary mode
> >
> > On Tue, Dec 13, 2011 at 09:11:25AM -0700, Marcus Sorensen wrote:
> > > On Tue, Dec 13, 2011 at 8:52 AM, Marcus Sorensen <shadowsor [at] gmail>
> > wrote:
> > > > On Tue, Dec 13, 2011 at 4:40 AM, Lars Ellenberg
> > > > <lars.ellenberg [at] linbit> wrote:
> > > >> On Mon, Dec 12, 2011 at 09:35:01PM -0700, Marcus Sorensen wrote:
> > > >>> "in dual primary mode, only protocol C is allowed.
> > > >>>
> > > >>> cluster file system deals with cache coherence,
> > > >>> DRBD has to deal with storage coherence.
> > > >>> you cannot do that asynchronously.
> > > >>>
> > > >>> to do that in protocol B, the receiving node would need to be able
> to
> > > >>> access data of in-flight requests, which is not implemented."
> >
> > ^^^
> > You even quoted the paragraph.
> > Anything unclear about that?
> >
> >
> > > >>>
> > > >>> But what if you're not using a filesystem?
> > > >>
> > > >> Ok, so you are using "whatever", and you think you want
> dual-primary
> > DRBD,
> > > >> but you want it to replicate asynchronously despite of that.
> > > >>
> > > >> What if "whatever" writes something to node A,
> > > >> node A completes the write,
> > > >> and "whatever" has all right to assume this actually hit stable
> > storage.
> > > >>
> > > >> Then (the same or a different instance of) "whatever" wants to read
> > that
> > > >> change from node B, but the change is not yet on B, because it
> > > >> replicated async.
> > > >>
> > > >> "whatever" would be slightly surprised,
> > > >> and you would start screaming drbd ate my data.
> > > >>
> > > >> Well, no, it did not. You screwed up.
> > > >> And this particular screwup DRBD does not allow.
> > > >
> > > > So you're saying that protocol B, in active-active, would not read
> > > > from memory on the second node. So even if we wait until a write to
> > > > block 213456 has replicated to memory on node B, if a read comes in
> > > > for block 213456 on node B, it's going to go to disk for the read,
> and
> > > > ignore the outstanding write until it's on disk. This is good to
> know,
> > > > and not what I would have expected.
> > >
> > > Ah, for clarification, in protocol B we're not talking about the write
> > > being 'in buffer' waiting to be flushed to disk, but in drbd memory,
> > > correct?
> > > _______________________________________________
> > > drbd-user mailing list
> > > drbd-user [at] lists
> > > http://lists.linbit.com/mailman/listinfo/drbd-user
> >
> > --
> > : Lars Ellenberg
> > : LINBIT | Your Way to High Availability
> > : DRBD/HA support and consulting http://www.linbit.com
> >
> > DRBDR and LINBITR are registered trademarks of LINBIT, Austria.
> > __
> > please don't Cc me, but send to list -- I'm subscribed
> > _______________________________________________
> > drbd-user mailing list
> > drbd-user [at] lists
> > http://lists.linbit.com/mailman/listinfo/drbd-user

--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
__
please don't Cc me, but send to list -- I'm subscribed
_______________________________________________
drbd-user mailing list
drbd-user [at] lists
http://lists.linbit.com/mailman/listinfo/drbd-user


shadowsor at gmail

Dec 13, 2011, 8:44 PM

Post #13 of 15 (1573 views)
Permalink
Re: protocol B in dual-primary mode [In reply to]

>> > You even quoted the paragraph.
>> > Anything unclear about that?

Yes, actually, on the face of it, but thanks for helping to remove any
ambiguity. It is clear now that DRBD does not write to disk
asynchronously (even though the term "memory synchronous" could
suggest it) and that 'in-flight requests' refers to replication that
has occurred between DRBD daemons on nodes but nothing else on the
system sees it on disk yet, rather than something generated by
generic_make_request.
_______________________________________________
drbd-user mailing list
drbd-user [at] lists
http://lists.linbit.com/mailman/listinfo/drbd-user


shadowsor at gmail

Dec 13, 2011, 8:51 PM

Post #14 of 15 (1573 views)
Permalink
Re: protocol B in dual-primary mode [In reply to]

> As you also quoted already:
>
>> > > >>> "in dual primary mode, only protocol C is allowed.
>
> Does not get much clearer than that, does it.
>
> You can not use protocol b for dual primary.
> DRBD will not allow you to do so.
>
> If it does, tell me, as that would be a bug, and needs to be fixed.

That works well, and I'm sure catches 98% of questions, which is
probably good enough. For the rest of us, we're glad to have the
mailing list to pound it into us. Some people need to push the
envelope, sticking to a documented procedure and an entry-level wage
is not for everyone. There are some that need to explore what's
beyond, ask the whys, come up with novel solutions, and that's
probably the reason why DRBD was developed in the first place. I'm in
a position now where if I just said "well, we can't do protocol B
because it says so in the documentation", I'd be asked the reason for
the limitation, and whether we could patch it, as in passing it sounds
like it could work for special scenarios. I'm glad that I don't have
to resort to hours worth of tracing through code to find out.
_______________________________________________
drbd-user mailing list
drbd-user [at] lists
http://lists.linbit.com/mailman/listinfo/drbd-user


shadowsor at gmail

Dec 13, 2011, 8:56 PM

Post #15 of 15 (1572 views)
Permalink
Re: protocol B in dual-primary mode [In reply to]

Actually, the target we're playing with does handle reservations.
Thanks for confirming my suspicions, that this seems technically
feasible, but a bit hairy. Certainly would require a better
interconnect than ethernet and a simple crossover cable. I don't think
we'll end up going this route, but it sounds like it's at least worth
putting into lab and playing with it a bit.

I actually wouldn't mind doing failover, I'm just not aware of any way
to do it with fibrechannel short of some hardware that can share FC
cards between servers. We could perhaps spoof the wwpn of the target
and bring it up on the secondary in a failover, but that wouldn't
account for outstanding credits on the other device, and I certainly
don't think it would be as forgiving as TCP.

On Tue, Dec 13, 2011 at 12:00 PM, John Lauro
<john.lauro [at] covenanteyes> wrote:
> None of the open source targets will handle reservations or block locking.
> However, that point is moot when you have a single client multi-pathing to
> drbd pair, but reservations are very critical for SAN based filesystems...
> Assuming only a single client to two DRBD nodes and doing failover, it is
> very risky as the slightest network hiccup can cause a split brain as the
> default timeout retries are extremely low and despite having protocol C,
> one node might thing the other is down when it is not really.  However, if
> (and only if) you truly implement STONITH so split brain is impossible, as
> far as I can tell you could do multi-pathing despite all of the comments
> not to do it.
>
> So two requirements:
>        1. No multi-node to same resource.  (No SAN type filesystem).
>        2. STONITH must be implemented.
> If you meet those two requirements, then it should technically be
> possible, but comes down to a why bother with active/active multipath DRBD
> at all, and why not just fail over the service on top of DRBD.
>
>
>> -----Original Message-----
>> From: drbd-user-bounces [at] lists [mailto:drbd-user-
>> bounces [at] lists] On Behalf Of Felix Frank
>> Sent: Tuesday, December 13, 2011 4:44 AM
>> To: Marcus Sorensen
>> Cc: drbd-user [at] lists
>> Subject: Re: [DRBD-user] protocol B in dual-primary mode
>>
>> Hi,
>>
>> On 12/13/2011 05:35 AM, Marcus Sorensen wrote:
>> > What if you're just
>> > exporting drbd block, active-active devices via say, iscsi or SAS
>> > target? Couldn't the initiator just treat them as the same disk,
>> > multipathed?
>>
>> there was a lengthy discussion last week or the one prior on why you
>> cannot do that. Long story short, two state of the art iSCSI targets
>> cannot operate as one multipath target.
>> I can't seem to find it quite on the spot, but a quick trawl through the
>> archives should yield some info.
>>
>> Cheers,
>> Felix
>> _______________________________________________
>> drbd-user mailing list
>> drbd-user [at] lists
>> http://lists.linbit.com/mailman/listinfo/drbd-user
_______________________________________________
drbd-user mailing list
drbd-user [at] lists
http://lists.linbit.com/mailman/listinfo/drbd-user

DRBD users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.