Recovering / Resyncing a distributed DRBD dual primary Split Brain – [servera] has a different data from [serverb]

Recovering / Resyncing  a distributed DRBD dual primary Split Brain – [servera] has a different data from [serverb]

A client had a pair of servers running drbd in order to keep a large file system syncronized and highly available.  However at some point in time the drbd failed and the two servers got out of sync and it went unnoticed for long enough,  that new files were written on both ‘servera’ and on ‘serverb’.

At this point both servers believe that they are the primary,  and the servers are running in what you call a ‘Split Brain’

To determine that split brain has happened you can run several commands.  In our scenario we have two servers servera and serverb

servera#drbd-overview
 0:r0/0 WFConnection Primary/Unknown UpToDate/DUnknown C r----- /data ocfs2 1.8T 1001G 799G 56%
serverb#drbd-overview
 0:r0/0  StandAlone Primary/Unknown UpToDate/DUnknown r----- /data ocfs2 1.8T 1.1T 757G 58%

From the output above (color added) we can see that servera knows that it is in StandAlone mode,   the server realizes that it can not connect.  We can research the logs and we can find out why it things it is in  StandAlone d.  To do this we grep the syslog.

serverb#grep split /var/log/syslog
Nov 2 10:15:26 serverb kernel: [41853948.860147] block drbd0: helper command: /sbin/drbdadm initial-split-brain minor-0
Nov 2 10:15:26 serverb kernel: [41853948.862910] block drbd0: helper command: /sbin/drbdadm initial-split-brain minor-0 exit code 0 (0x0)
Nov 2 10:15:26 serverb kernel: [41853948.862934] block drbd0: Split-Brain detected but unresolved, dropping connection! 
Nov 2 10:15:26 serverb kernel: [41853948.862950] block drbd0: helper command: /sbin/drbdadm split-brain minor-0
Nov 2 10:15:26 serverb kernel: [41853948.865829] block drbd0: helper command: /sbin/drbdadm split-brain minor-0 exit code 0 (0x0)

This set of log entries lets  us know that when serverb attempted to connect to servera,  it detected a situation where both file systems had been written to,  so it could no longer synchronize.  it made these entries and put itself into Standalone mode.

servera on the other hand says that it is waiting for a connection WFConnection.

The next step is to determine which of the two servers has the ‘master’ set of data.  This set of data will sync OVER THE TOP of the other server.

In our client’s case we had to do some investigation in order to determine what differences there were on the two servers.

After some discovery we realized that in our case serverb had the most up to date information, except in the case of one directory,  we simply copied that data from servera to serverb,  and then serverb was ready to become our primary.  In the terminology of DRBD,  servera is our ‘split-brain victim’ and serverb is our ‘splitbrain survivor’  we will need to run a set of commands which

  1. ensures the status of the victim to ‘Standalone’ (currently it is ‘WFConnection’)
  2. umount the drive on the victim(servera) so that the filesystem is no longer accessible
  3. sets the victim to be ‘secondary’ server,   this will allow us to sync from the survivor to victim KNOWING the direction the data will go.
  4. start the victim (servera) and let the let the ‘split brain detector’ know that it is okay to overwrite the data on the victim(servera) with the data on the survivor (serverb)
  5. start the survivor(serverb)  (if the serverb server was in WFConnection mode, it would not need to be started,  however ours was in StandAlone mode so it will need to be restarted)

At first we were concerned that we would have to resync 1.2 TB of data,  however we read here  that

The split brain victim is not subjected to a full device synchronization. Instead, it has its local modifications rolled back, and any modifications made on the split brain survivor propagate to the victim.

The client runs a dual primary,  however as we rebuild the synced pair, we need to ensure that the ‘victim’  is rebuilt from the survivor,  so we move the victim from a primary, to a secondary.   And it seems that we are unable to mount a drive (using our ocfs2 filesystem) while it is a secondary.  So we had to ‘umount’ the drive,  and we were unable to remount it while it is a secondary.  In a future test (in which restoring data redundancy primary / primary is less critical),  we will find out whether we are able to keep the primary/primary status while we are rebuilding from a split brain.

While the drbd-overview tool shows all of the ‘resources’ we are required to use a third parameter specifying the ‘resource’ to operate on .  If you have more than one drbd resource defined you will need to identify which resource you are working with.   You can look in your /etc/drbd.conf file or in your /etc/drbd.d/disk.res (your file may be named differently).  The file has the form of

resource r0 { 
....................
}

where r0 is your resource name,   you can also see this buried in your output of drbd-overview

servera# drbd-overview
0:r0/0 WFConnection Primary/Unknown UpToDate/DUnknown C r----- /data ocfs2 1.8T 1001G 799G 56%

So we ran the following commands on servera to prepare it as the victim

servera# drbd-overview #check the starting status of the victim
 0:r0/0 WFConnection Primary/Unknown UpToDate/DUnknown C r----- /data ocfs2 1.8T 1001G 799G 56%
serverb# drbd-overview #check the starting status of the survivor
 0:r0/0 StandAlone Primary/Unknown UpToDate/DUnknown r----- /data ocfs2 1.8T 1.1T 760G 58%

From this above we can see that serverb has 58% usage and 760GB free, were server a has 56% usage and 799GB free.
Based on what I know about the difference between servera and serverb, this helps me to confirm that serverb has more data and is the ‘survivor’

servera# drbdadm disconnect r0 # 1. ensures the victim is standalone 
servera# drbd-overview #confirm it is now StandAlone 
 0:r0/0 StandAlone Primary/Unknown UpToDate/DUnknown r----- /data ocfs2 1.8T 1001G 799G 56%
servera# umount /data # 2. we can not mount the secondary drive with read write
servera# drbdadm secondary r0 # 3. ensures the victim is the secondary 
servera# drbd-overview #confirm it is now secondary 
  0:r0/0 StandAlone Secondary/Unknown UpToDate/DUnknown r-----
servera# drbdadm connect --discard-my-data r0 # 4. start / connect the victim up again knowing that its data should be overwritten with a primary 
servera# drbd-overview #confirm the status and that it it is now connected [WFConnection]
  0:r0/0 WFConnection Secondary/Unknown UpToDate/DUnknown C r-----


I also checked the logs to confirm the status change

servera#grep drbd /var/log/syslog|tail -4
Nov 4 05:14:03 servera kernel: [278068.555213] drbd r0: conn( StandAlone -> Unconnected )
Nov 4 05:14:03 servera kernel: [278068.555247] drbd r0: Starting receiver thread (from drbd_w_r0 [19105])
Nov 4 05:14:03 servera kernel: [278068.555331] drbd r0: receiver (re)started
Nov 4 05:14:03 servera kernel: [278068.555364] drbd r0: conn( Unconnected -> WFConnection )

Next we simply have to run this command on serverb to let it know that it can connect as the survivor (like I mentioned above,  if the survivor was in WFConnection mode,  it would automatically reconnect,  however we were in StandAlone mode)

serverb# drbd-overview #check one more time that serverb is not yet connected
 0:r0/0 StandAlone Primary/Unknown UpToDate/DUnknown r----- /data ocfs2 1.8T 1.1T 760G 58%
serverb# drbdadm connect r0 # 5. start the surviving server to ensure that it reconnects
serverb# drbd-overview #confirm serverb and servera are communicating again 
 0:r0/0 SyncSource Primary/Secondary UpToDate/Inconsistent C r----- /data ocfs2 1.8T 1.1T 760G 58%
 [>....................] sync'ed: 0.1% (477832/478292)M
servera# drbd-overview #check that servera confirms what serverb says about communicating again 
 0:r0/0 SyncTarget Secondary/Primary Inconsistent/UpToDate C r-----
 [>....................] sync'ed: 0.3% (477236/478292)M

Another way to confirm that the resync started happening is to check the logs

servera# grep drbd /var/log/syslog|grep resync
Nov 4 05:18:09 servera kernel: [278314.571951] block drbd0: Began resync as SyncTarget (will sync 489771348 KB [122442837 bits set]).
serverb# grep drbd /var/log/syslog|grep resync
Nov 4 05:18:09 serverb kernel: [42008909.652451] block drbd0: Began resync as SyncSource (will sync 489771348 KB [122442837 bits set]).


Finally,   we simply run a command to promote servera to be a primary again,  and then both servers will be writable

servera#drbdadm primary r0
servera# drbd-overview
 0:r0/0 Connected Primary/Primary UpToDate/UpToDate C r-----
servera# mount /data #remount the data drive we unmounted previously

 

 

Now that we ‘started’ recovering from the split-brain issue we just have to watch the two servers to confirm once they have fully recovered.  once that is complete we will put in place log watchers and FileSystem tests to send out a notification to the system administrator if it should happen again.

Setting up DRBD with OCSF2 on a Ubuntu 12.04 server for Primary/Primary

Setting up DRBD with OCSF2 on a Ubuntu 12.04 server for Primary/Primary

We run in a virtual environment and so we thought we would go with the virtual kernel for the latest linux kernls
We learned that we should NOT not in the case we want to use the OCFS2 distributed locking files system because ocfs2 did not have the correct modules so we would have had to doa  custom build of the modules so we decided against it.   we just went with the latest kernel,   and would install ocfs2 tools from the package manager.

DRBD on the other hand had to be downloaded, compiled and installed regardless of kernel,   here are the procedures,  these must be run on each of a pair of machines.
We assume that /dev/xvdb has a similar sized device on both machines.

apt-get install make gcc flex
wget http://oss.linbit.com/drbd/8.4/drbd-8.4.4.tar.gztar xzvf drbd-8.4.4.tar.gz 
cd drbd-8.4.4/
./configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc --with-km
make all

Connfigure both systems to be aware of eachother without dns /etc/hosts

192.168.100.10 server1
192.168.100.11 server2

Create a configuration file at /etc/drbd.d/disk.res

resource r0 {
protocol C;
syncer { rate 1000M; }
startup {
wfc-timeout 15;
degr-wfc-timeout 60;
become-primary-on both;
}
net {
#requires a clustered filesystem ocfs2 for 2 prmaries, mounted simultaneously
allow-two-primaries;
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
cram-hmac-alg sha1;
shared-secret "sharedsanconfigsecret";
}
on server1 {
device /dev/drbd0;
disk /dev/xvdb;
address 192.168.100.10:7788;
meta-disk internal;
}
on server2 {
device /dev/drbd0;
disk /dev/xvdb;
address 192.168.100.11:7788;
meta-disk internal;
}
}

 

configure drbd to start on reboot verify that DRBD is running on both machines and reboot,  and verify again

update-rc.d drbd defaults
/etc/init.d/drbd start
drbdadm -- --force create-md r0
drbdadm up r0
cat /proc/drbd

at this point  you should see that both devices are connected Secondary/Secondary and Inconsistent/Inconsistent.
Now we start the sync fresh,   on server1 only both sides are blank so drbd should manage any changes from here on.  cat /proc/drbd will show UpToDate/UpToDate
Then we mark both primary and reboot to verify everything comes back up

server1>drbdadm -- --clear-bitmap new-current-uuid r0
server1>drbdadm primary r0
server2>drbdadm primary r0
server2>reboot
server1>reboot

I took a snapshot at this point
Now it is time to setup the OCFS2 clustered file system on top of the device first setup a /etc/ocfs2/cluster.conf

cluster:
node_count = 2
name = mycluster
node:
ip_port = 7777
ip_address = 192.168.100.10
number = 1
name = server1
cluster = mycluster
node:
ip_port = 7777
ip_address = 192.168.100.11
number = 2
name = server2
cluster = mycluster

get the needed packages, configure them and setup for reboot,  when reconfiguring,   remember to put the name  of the cluster you want to start at boot up mycluster run the below on both machines

apt-get install ocfs2-tools
dpkg-reconfigure ocfs2-tools
mkfs.ocfs2 -L mycluster /dev/drbd0 #only run this on server1
mkdir -p /data
echo "/dev/drbd0  /data  ocfs2  noauto,noatime,nodiratime,_netdev  0 0" >> /etc/fstab
mount /data
touch /data/testfile.`hostname`
stat /data/testfile.*
rm /data/testfile* # you will only have to run this on one machine
reboot

So,  everything should be running on both computers at this point when things come backup make sure everythign is connected.
You can run these commands from either server

/etc/init.d/o2cb status
cat /proc/drbd

			

Setting DRBD in Primary / Primary — common commands to sync resync and make changes

Setting DRBD in Primary / Primary — common commands to sync resync and make changes

As we have been setting up our farm with an NFS share the DRBD primary / primary connection between servers is important.

We are setting up a group of /customcommands/ that we will be able to run to help us keep track of all of the common status and maintenance commands we use,  but  when we have to create, make changes to the structure,  sync and resync, recover, grow or move the servers,  We need to document our ‘Best Practices’ and how we can recover.

From base Server install

apt-get install gcc make flex
wget http://oss.linbit.com/drbd/8.4/drbd-8.4.1.tar.gz
tar xvfz drbd-8.4.1.tar.gz
cd drbd-8.4.1/
./configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc --with-km
make KDIR=/lib/modules/3.2.0-58-virtual/build
make install

Setup in/etc/drbd.d/disk.res

resource r0 {
protocol C;
syncer { rate 1000M; }
startup {
wfc-timeout 15;
degr-wfc-timeout 60;
become-primary-on both;
}
net {
#requires a clustered filesystem ocfs2 for 2 prmaries, mounted simultaneously
allow-two-primaries;
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
cram-hmac-alg sha1;
shared-secret "sharedsanconfigsecret";
}
on server1{
device /dev/drbd0;
disk /dev/xvdb;
address 192.168.100.10:7788;
meta-disk internal;
}

on riofarm-base-san2 {
device /dev/drbd0;
disk /dev/xvdb;
address 192.168.100.11:7788;
meta-disk internal;
}
}

 

Setup your /etc/hosts

192.168.100.10 server1
192.168.100.11 server2

Setup /etc/hostname with

server1

reboot,  verify your settings and SAVE A DRBDVMTEMPLATE clone your VM to a new server called server2

Setup /etc/hostname with

server2

start drbd with /etc/init.d/drbd  this will likely try and create the connection,  but this is where we are going to ‘play’ to learn the commands and how we can sync,  etc.

cat /proc/drbd   #shows the status of the connections
server1> drbdadm down r0   #turns of the drbdresource and connection
server2> drbdadm down r0   #turns of the drbd resource and connection
server1> drbdadm -- --force create-md r0  #creates a new set of meta data on the drive,  which 'erases drbds memory of the sync status in the past
server2> drbdadm -- --force create-md r0  #creates a new set of meta data on the drive,  which 'erases drbds memory of the sync status in the past
server1> drbdadm up r0   #turns on the drbdresource and connection and they shoudl connect without a problem,   with no memory of a past sync history
server2> drbdadm up r0    #turns on the drbdresource and connection and they shoudl connect without a problem,   with no memory of a past sync history
server1> drbdadm -- --clear-bitmap new-current-uuid r0  # this create a new 'disk sync image' essentially telling drbd that the servers are blank so no sync needs to be done  both servers are immediately UpToDate/UptoDate in /proc/drbd
server1> drbdadm primary r0
server2> drbdadm primary r0    #make both servers primary and  now when you put an a filesystem on /dev/drbd0 you will be able to read and write on both systems as though they are local

So,    lets do some failure scenarios,    Say, we loose a server,  it doesn’t matter which one since they are both primaries,  in this case though we will say server2 failed.  Create a new VM from DRBDVMTEMPLATE  which already had drbd made on it with the configuration or create another one using the instructions above.

Open /etc/hostname and set it to

server2

reboot.    Make sure /etc/init.d/drbd start is running

server1>watch cat /proc/drbd  #watch the status of dtbd,  it is very useful and telling about what is happening,   you will want DRBD to be Connected Primary/Unknown  UpToDate/DUnknown  
server2>drbdadm down
server2>dbadm wipe-md r0  #this is an optional step that is used to wipe out the meta data,  I have not seen that it does anything different than creating the metadata using the command below,  but it is useful to know the command in case you want to get rid of md  on your disk
server2>drbdadm -- --force create-md r0  ##this makes sure that their is no partial resync data left over from where you cloned it from
server2>drbdadm up r0 # this brings drbd server2 back into the resource and connects them,  it will immediately sart syncing you should see SyncSource Primary/Secondary UpToDate/Inconsistent on server1,     for me it was soing to to 22 hours for my test of a 1TM  (10 MB / second)

Lets get funky,  what happens if you stop everything in the middle of a sync

server1>drbdadm down r0 #we shut down the drdb resource that has the most up to date information,   on server2 /proc/drbd shows Secondary/Unknown  Inconsitent/DUnknown ,  server2 does not know about server1 any more,  but server2 still knows that server2 is inconsitent,   (insertable step here could be on server2: drbdadm down ro; drbdadm up ro,  with no change to the effect)
server1>drbdadm up ro #  this brings server1 back on line and /proc/drbd on server1 shows  SyncSource,  server2 shows SyncTarget,   server1 came backup as the UpToDate server,  server2 was Inconsistent,  it figured it out

 

Where things started to go wrong and become less ‘syncable’  was when servers were both down and had to be brought back up again separately with a new uuid was created on them separately.  so lets simulate that the drbd config fell apart,  and we have to put it together again.

server2>drbdadm disconnect ro;  drdbadm -- --force create-md r0 ; drbd connect ro;   #start the sync process over
Call Now Button(208) 344-1115

SIGN UP TO
GET OUR 
FREE
 APP BLUEPRINT

Join our email list

and get your free whitepaper