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 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. -- 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/20120817/ed31c8ff/attachment.htm>