[DRBD-user] Removing DRBD Kernel Module Blocks

Felix Frank ff at mpexnet.de
Tue Jan 31 16:04:53 CET 2012

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


Hi,

On 01/31/2012 03:54 PM, Andrew Martin wrote:
> Hi Felix,
> 
> I was attempting to failover from node1 to node2 by putting node1 into
> standby mode. I have not been able to get crm resource migrate to work -

That's unfortunate, see below.

> e.g. I'll instruct it to migrate the DRBD resource (which should cause
> all other resources to migrate as well) with crm resource migrate
> ms_drbd_mount1 node2, but this doesn't seem to have any effect.

It can't. You need to migrate a primitive or group that depends on DRBD
being in the master role, e.g. your Filesystem resource.

Your DRBD state wasn't clean, that's why putting node1 in standby
effectively broke your cluster:

On 01/30/2012 11:27 PM, Andrew Martin wrote:
> Jan 30 15:11:15 node2 kernel: [ 1075.519415] block drbd0: conn(
> WFBitMapS -> SyncSource ) pdsk( Outdated -> Inconsistent ) Jan 30
...
> Jan 30 15:11:16 node2 kernel: [ 1076.060200] block drbd0:
> conn( SyncSource -> Connected ) pdsk( Inconsistent -> UpToDate )

There, that went well. drbd0 became SyncSource on node2, made the resync
and finally became StandAlone primary. No problems.

> 15:11:15 node2 kernel: [ 1075.809934] block drbd1: conn( WFSyncUUID ->
> SyncTarget )

Oops. drbd1 didn't fare so well. It was outdated and needed to sync from
node1:

> Jan 30 15:11:15 node2 kernel: [ 1075.809942] block drbd1: Began resync
> as SyncTarget (will sync 838514728 KB [209628682 bits set]).

That's a lot of kilobytes :-( Syncing this will take a while. You're
still not in trouble, though. node2 can be primary while still syncing
data over from node1.

However, seeing as you issued a crm node standby, DRBD is being stopped
on node1! Oops again - node2 lost access to the only consistent copy
(it's in a half-synced state itself).

Long story short: You need to make certain that your DRBDs are healthy
(Connected and UpToDate/UpToDate) before trying at failover scenarios.
I recommend Nagios or similar to always stay in touch with your DRBD health.
Sadly, pacemaker is not currently capable of protecting you from
shooting your foot this way.

HTH,
Felix



More information about the drbd-user mailing list