<div class="gmail_quote">On Mon, Aug 20, 2012 at 3:43 AM, Lars Ellenberg <span dir="ltr"><<a href="mailto:lars.ellenberg@linbit.com" target="_blank">lars.ellenberg@linbit.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Fri, Aug 17, 2012 at 03:46:12PM -0500, J.R. Lillard wrote:<br>
> On Fri, Aug 17, 2012 at 12:28 PM, Nik Martin <<a href="mailto:nik.martin@nfinausa.com">nik.martin@nfinausa.com</a>>wrote:<br>
><br>
> > On 2012-08-17, 11:38, "J.R. Lillard" (<a href="mailto:jlillard@ghfllc.com">jlillard@ghfllc.com</a>) wrote:<br>
> > I was wondering if it's possible to to create a DRBD resource on top of<br>
> > another one without using the stacked configuration options. I would like<br>
> > to establish a Protocol A with Proxy between node-b and node-c. This will<br>
> > be over a WAN. Then I want to establish a Protocol C between node-a and<br>
> > node-b. node-a will know nothing about the proxy or node-c. When I create<br>
> > the resource on node-b that syncs with node-a I will simply use the<br>
> > resource already established to sync with node-c. My goal is to make<br>
> > node-a operate as efficient as possible without the connection to node-c<br>
> > slowing it down.<br>
> ><br>
> ><br>
> > That is an interesting scenario for sure, but it seems you have designed a<br>
> > split brain scenario, and that's bad. The hole I see is what if node b is<br>
> > primary on Cluster A, but secondary on Cluster B, you are now pushing BAD<br>
> > data onto the Primary in Cluster A, and have just trashed all your data. I<br>
> > may be misinterpreting your use of the term Proxy, but I don't see how to<br>
> > maintain consistency.<br>
> ><br>
><br>
> Cluster A will use Protocol C but will only be one-way. Node 1 will always<br>
> be primary and Node 2 will always be secondary. Let's say Node 1 and Node<br>
> 2 both use r1 on /dev/drbd1. Cluster B will use Protocol A and DRBD Proxy<br>
> and will also be one-way. Node 2 will always be the primary and Node 3<br>
> will always be secondary. Both of these nodes will use r2 /dev/drbd2. The<br>
> question I have is when I configure r1 on Node 2 can I tell it to use<br>
> /dev/drbd2 without causing problems? This scenario doesn't give me<br>
> automatic failover capabilities but it does give me onsite and offsite<br>
> redundancy. Changes will only be made to Node 1. Those changes will be<br>
> pushed to Node 2. These changes will be written to /dev/drbd1 which is<br>
> actually on top of /dev/drbd2 which will be on top of a physical disk.<br>
> These changes will then flow from Node 2, through DRBD Proxy where they<br>
> will be compressed and sent off to Node 3 offsite. If Node 1 fails then I<br>
> can manually fall back to using /dev/drbd2 on Node 2 until Node 1 is<br>
> repaired. When I bring Cluster A back online I will make sure Node 2 is<br>
> primary at first to sync up Node 1. If Node 1 and Node 2 both fail then I<br>
> still have Node 3 as an offsite backup to restore from.<br>
<br>
</div></div>Right.<br>
So this pretty much looks like the typical scenario<br>
for stacked drbd and drbd-proxy.<br>
<br>
What is wrong with that?<br>
Why do you think you need anything like "manual stack",<br>
and what exactly is "manual" about that?<br>
<br>
Sorry, but I seem to miss the problem you are trying to solve.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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?</div>
</div><div><br></div>-- <br>J.R. Lillard<div>System / Network Admin</div><div>Web Programmer</div><div>Golden Heritage Foods</div><div>120 Santa Fe St.</div><div>Hillsboro, KS 67063</div><br>