[DRBD-user] Manual Stack

Lars Ellenberg lars.ellenberg at linbit.com
Mon Aug 20 10:43:55 CEST 2012

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


On Fri, Aug 17, 2012 at 03:46:12PM -0500, J.R. Lillard wrote:
> On Fri, Aug 17, 2012 at 12:28 PM, Nik Martin <nik.martin at nfinausa.com>wrote:
> 
> > On 2012-08-17, 11:38, "J.R. Lillard" (jlillard at ghfllc.com) wrote:
> > I was wondering if it's possible to to create a DRBD resource on top of
> > another one without using the stacked configuration options.  I would like
> > to establish a Protocol A with Proxy between node-b and node-c.  This will
> > be over a WAN.  Then I want to establish a Protocol C between node-a and
> > node-b.  node-a will know nothing about the proxy or node-c.  When I create
> > the resource on node-b that syncs with node-a I will simply use the
> > resource already established to sync with node-c.  My goal is to make
> > node-a operate as efficient as possible without the connection to node-c
> > slowing it down.
> >
> >
> > That is an interesting scenario for sure, but it seems you have designed a
> > split brain scenario, and that's bad.  The hole I see is what if node b is
> > primary on Cluster A, but secondary on Cluster B, you are now pushing BAD
> > data onto the Primary in Cluster A, and have just trashed all your data. I
> > may be misinterpreting your use of the term Proxy, but I don't see how to
> > maintain consistency.
> >
> 
> Cluster A will use Protocol C but will only be one-way.  Node 1 will always
> be primary and Node 2 will always be secondary.  Let's say Node 1 and Node
> 2 both use r1 on /dev/drbd1.  Cluster B will use Protocol A and DRBD Proxy
> and will also be one-way.  Node 2 will always be the primary and Node 3
> will always be secondary.  Both of these nodes will use r2 /dev/drbd2.  The
> question I have is when I configure r1 on Node 2 can I tell it to use
> /dev/drbd2 without causing problems?  This scenario doesn't give me
> automatic failover capabilities but it does give me onsite and offsite
> redundancy.  Changes will only be made to Node 1.  Those changes will be
> pushed to Node 2.  These changes will be written to /dev/drbd1 which is
> actually on top of /dev/drbd2 which will be on top of a physical disk.
>  These changes will then flow from Node 2, through DRBD Proxy where they
> will be compressed and sent off to Node 3 offsite.  If Node 1 fails then I
> can manually fall back to using /dev/drbd2 on Node 2 until Node 1 is
> repaired.  When I bring Cluster A back online I will make sure Node 2 is
> primary at first to sync up Node 1.  If Node 1 and Node 2 both fail then I
> still have Node 3 as an offsite backup to restore from.

Right.
So this pretty much looks like the typical scenario
for stacked drbd and drbd-proxy.

What is wrong with that?
Why do you think you need anything like "manual stack",
and what exactly is "manual" about that?

Sorry, but I seem to miss the problem you are trying to solve.


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



More information about the drbd-user mailing list