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