Redirecting filesystem activity to replica

Given two Isilon clusters with SyncIQ replication configured to copy content from primary to alternate location ...

What are best options to transfer client filesystem activity to the alternate?  Any pitfalls to avoid?

Primary interest is NFS service that is used by multiple physical and virtual client systems in the data center running applications supporting services which have short RTO.  My current understanding of options is as follows:

• Moving smartconnect zone (aka fileserver) name between clusters is less than ideal for a couple of reasons
  • Clients with active mounts need intervention (remount?) to select IP address from new cluster.  Resetting mount, typically triggers requirement for restarting applications that use the NAS.
  • Changing registered DNS server for NS records can be more time consuming than modifying A record's IP address (mostly an issue for DNS appliance)
• Unix NFSv4 servers define a specification to configure replicas and refer paths in /etc/exports.  The nfsv4 replica server function appears to be a perfect match for informing clients of replicas (SyncIQ or otherwise) and the refer path mechanism  seems like a good way to specify cluster which has read-write copy of application share when writable access is required.   I see no documentation for a mechanism to specify this in User Guide or Command Line Reference.  Am I missing this or is it not there?  Not sure about NFSv4 client implementation status for this functiionality
• NFS client replica configuration; this appears to be an option for RO service with both NFS v3 and v4
  • Linux clients have support for automounter "replicated server" config  [ autofs(5) ]
    • This requires monitoring to detect failure condition and unmount, mount/remount is automatic
  • Solaris clients accept multi-server specification in /etc/vfstab.  Documentation suggests that failover is fairly automatic
• Explicit NFS client configuration change
  • Modify fstab/vfstab, remount, and restart service(s).  This works and can be automated, but may have scaling issues for short Recovery Time Objectives.
  • Solve problem at application layer by moving application activity from primary to alternate service stack (aka the vmware sprawl solution).  Have VM app servers configured to use the alternate fileserver on standby

--CWB