[DRBD-user] Manual Stack

J.R. Lillard jlillard at ghfllc.com
Fri Aug 31 04:43:01 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 Mon, Aug 20, 2012 at 3:43 AM, Lars Ellenberg
<lars.ellenberg at linbit.com>wrote:

> 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
> > > 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.

Maybe I have it wrong but my understanding of the stacked scenario is that
the top level connects to the proxy and the lower level is the other node
on the LAN.  I am wanting to two independent pair of nodes where the
secondary in a protocol c is actually layered on top of the primary of a
protocol a.  I call it manual because one node won't know about the other.

I am attempting this because I'm having problems with the proxy slowing
down my primary node when it's in play.  I have narrowed down the problem
since my original post though.  I put the proxy on its own server.  This
didn't solve my problem.  Then I disabled compression.  This has allowed it
to run perfectly smooth.  I rewatched your proxy tuning webinar from this
spring.  I cam to realize that the memlimit that I setup for proxy is only
used for the WAN side of the connection.  The slowdowns I'm seeing are
because the proxy is not able to compress incoming data fast enough to even
get it onto that WAN stack.  What I really need is another buffer on the
proxy between accepting the data from the primary node and compressing it
for the WAN buffer.  Suggestions?

J.R. Lillard
System / Network Admin
Web Programmer
Golden Heritage Foods
120 Santa Fe St.
Hillsboro, KS  67063
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20120830/d8c830af/attachment.htm>

More information about the drbd-user mailing list