during a normal upgrade process, support upgrades and reboot the standby datamover first, then they upgrade the primary one. I have always used failover/failback ..did not have to halt anything.

Its your choice – a reboot takes a bit longer than a failover but then you don’t need a failback.

So it’s a choice of one slightly longer downtime vs. two smaller ones

For example from recent testing with a small sized VNX 5500 the protocol downtime for a warm reboot is 30s vs. for failover/failback it is 20s

In my experience a properly setup VMware NFS data store will have no problems with up to 180 seconds

Okay, so failover and failback will reload the code and I don’t need to do a reboot. That is what you are saying correct?

Gabe Heinisch

919-280-7112

okay, thanks.  I will do the following:

#upgrade standby DM (server_3)
server_cpu server_3 -reboot -monitor now

#failover to standby DM
server_standby server_2 -activate mover

#upgrade primary DM
server_cpu server_3.server_2.failed -reboot -monitor now

#failback to primary
server_standby server_2 -restore mover

Great, it’s all done and no issues at all with the NFS. the longest cutover was from secondary back to primary. it took a total of 1 minute 7 seconds.

many thanks

Gabe

Just curious – how did you measure the „1 minute and 7 seconds“ ?

sorry for not responding earlier to your other inquiry. the customer has 4 NFS fs and we started a ping session before we swapped the movers. so at the very least, he measured a minute seven from the moment we lost ping until we had ping back…not exactly stating the DM was back up but to some extent.

Ok – it does sound a bit long for just 4 fs though