Q:

DRDB and NFS: NFS downtime during failover restoration

I'm pretty new to DRBD and NFS, and am in the process of testing a DRDB server with heartbeat to use for our company's NFS share.
The entire setup is running fine, with the NFS state directory running on the DRDB share as together with the actual share.
The problem I'm having comes from the failover scenario I'm testing. 
In the failover scenario, I create a problem where I disable the  the network connection (ifconfig eth0 down) on node1. The failover works awesome and does its job in about 5 seconds, but when I bring it back up (ifconfig eth0 up, and service heartbeat start if it's stopped) it takes upward of 3-5 minutes to get it back up during which the NFS share is unavailable.
In a web environment, this 3-5 minutes is pretty significant for downtime. Is this normal? What am I doing wrong?
I pasted our drbd.conf file below.
resource r0 {
 protocol C;
 startup {
    degr-wfc-timeout 60;    # 1 minute.
  }
  disk {
    on-io-error   detach;
  }
  net {
  }
  syncer {
    rate 10M;
    al-extents 257;
  }
 on tsa-dev-nfstest1 {                # ** EDIT ** the hostname of server 1 (un
   device     /dev/drbd0;        #
   disk       /dev/sdc1;         # ** EDIT ** data partition on server 1
   address    10.61.2.176:7788; # ** EDIT ** IP address on server 1
   meta-disk  /dev/sdb1[0];      # ** EDIT ** 128MB partition for DRBD on serve
  }
 on tsa-dev-nfstest2 {                # ** EDIT ** the hostname of server 2 (un
   device    /dev/drbd0;         #
   disk      /dev/sdc1;          # ** EDIT ** data partition on server 2
   address   10.61.2.177:7788;  # ** EDIT ** IP address on server 2
   meta-disk /dev/sdb1[0];       # ** EDIT ** 128MB partition for DRBD on serve
  }
}

A:

Does your heartbeat resource group include a logical IP for you NFS-service?
It should be your last resource that comes "up" and the first that goes "down".
Your clients should use this IP for accessing the NFS-service.
If you have an IP defined you might try to use the other resource type for IPAddr (IPAddr2 as far as I remember). That one behaves a little bit different on the IP-stack.
Basically both types should to an arp-broadcast after the IP comes up - to make sure the connected routers and switches relearn their mac-tables so they know where to forward the packets to after the failover happened.
On some NFS implementations you should also explicitly arp your already connected clients. For this you have to mirror the connected client data to your stand-by-node as well.

