Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Thu, Feb 16, 2012 at 11:37:48AM -0500, Digimer wrote: > On 02/16/2012 11:02 AM, Piotr Kandziora wrote: > > Digimer, > > > > > > Thanks for your answer. DRBD Proxy could be a solution, but it is not > > possible for today. > > > > I am thinking of trying DRBD with protocol A, but currently I am not > > able to test on my environment as it is in production. I will have > > maintenance window on the weekend. Do you think it can help? If yes, may > > you suggest values for tcp send buffer? > > > > Thanks in advance. > > > > Best regards > > Piotr Kandziora > > I am not the person to advise on tuning. For that, I would either ask on > #drbd or call Linbit and ask for tuning support. > > Protocol A is not ideal, as it prevents dual-primary use (which may not > be an issue) and is asynchronous, which means consistency on the > secondary node is not always guaranteed. I would not recommend it, but > it is an option is you are willing to assume the risk. That's not about consistency. The Secondary is consistent with protocol A as well. In case of Primary crash, some of the data that was in-flight to the Secondary will just not be there. But what is there is still consistent. It is however a very *bad* idea if you run NFS or SAMBA clients, or iSCSI or anything that is not restarted with the failover anyways: they assume that, if the storage said stuff was written, it was written. If then, after a failover with async replication, the last few (amount that fits in the socket buffers) is missing, they will all break in the most "interesting" ways. Async mirroring is intended to be used for desaster recovery purposes. After a "desaster" and failover, any clients would need to be rebooted, or unmounted, remounted or otherwise made aware of the fact that the data just "jumped back in time" a few (milli) seconds. > By far, the ideal solution is to use a wired connection. Accessing a storage with higher bandwidth than the storage has internally is a bad idea in general. So yes, make sure your DRBD internally has *at least* the bandwidth and link quality you want to see from the clients accessing it. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com