[DRBD-user] Avoid blocking IO when node fails

[Roberto Munoz Gomez]

-----Digimer <lists at alteeve.ca> escribió: -----

>Para: Roberto Munoz Gomez/ES/DIA/DIAGROUP at DIAGROUP,
>drbd-user at lists.linbit.com
>De: Digimer <lists at alteeve.ca>
>Fecha: 12/02/2014 20:47
>Asunto: Re: [DRBD-user] Avoid blocking IO when node fails
>
>On 12/02/14 11:34 AM, Roberto Munoz Gomez wrote:
>> Hi,
>>
>> I have configured an Active/Active cluster with Dual Primary DRBD.
>All works fine and fast.
>>
>> But when a node fails, the DRBD status goes to WFConnection and all
>IO is blocked on the other node. In this scenario I need the survivor
>to continue using the DRBD partition. It would be great if when the
>other node comes back, the synchronization begins automatically and
>both become Primary automatically.
>>
>> I have search the doc and google, but have not found any of this.
>Only the ko-count option, but does not seem to make a difference.
>>
>> Any ideas?
>>
>> Thanks in advance.
>>
>> Regards.
>
>You need fencing to safely proceed after a node loss. Are you using
>cman 
>or pacemaker? If so, you can setup fencing in those (pacemaker calls
>it 
>stonith, same thing) and then hook DRBD into it.
>


I'm using pacemaker and corosync. The fencing device is working correctly and is configured with:

handlers {
	      fence-peer              "/usr/lib/drbd/crm-fence-peer.sh";
	      after-resync-target     "/usr/lib/drbd/crm-unfence-peer.sh";
	}


The problem is that while the other node is being fenced, the active one cannot access the DRBD and all the IO calls are blocked until the fenced node comes alive again. And that is what I want to avoid. I want the survival node to continue working.


Regards.This e-mail and any attachment are confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system. Unauthorized publication, use, dissemination, forwarding, printing or copying of this e-mail and its associated attachments is strictly prohibited.  
http://disclaimer.diacorporate.com