# [OmniOS-discuss] NFS Datastore vmware esxi failover

Richard Elling richard.elling at richardelling.com
Fri Nov 8 21:54:50 UTC 2013

- Previous message: [OmniOS-discuss] NFS Datastore vmware esxi failover
- Next message: [OmniOS-discuss] NFS Datastore vmware esxi failover
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    Comment below...

    On Nov 8, 2013, at 8:17 AM, Matt Weiss <mweiss at cimlbr.com> wrote:

    > I am working on a failover script using OmniOS as a NFS server.
    >
    > According to VMware, if I mount and nfs datastore via its IP Address then I should be able to move the IP around and still mount it, however it is not working right.
    >
    > For example:
    >
    > On an ESXi instance (5.1U1) I mount the following NFS Datastore
    > 172.16.50.100
    > /tank/vmrep
    > which amounts to a UUID of 6c0c1d0d-928ef591 in /vmfs/volumes
    >
    >
    > omni-rep1: 172.16.50.1
    > omni-rep2: 172.16.50.2
    >
    > I am using zrep to failover my zfs dataset.
    > http://www.bolthole.com/solaris/zrep/zrep.documentation.html
    >
    > Essential, it puts primary into read-only, does a zfs send/receive, then sets the secondary to rw.
    >
    >
    > To expose my dataset (tank/vmrep) I am using sharenfs property of zfs. I have created a virtual ip to use for this purpose.
    >
    > #setnfsip.sh
    > ipadm create-addr -T static -a 172.16.50.100/24 vmxnet3s0/nfs
    >
    > #removenfsip.sh
    > ipadm delete-addr vmxnet3s0/nfs
    >
    >
    > So, when I want to failover, I just do the following:
    >
    > #!/bin/sh
    > #zfs unshare tank/vmrep
    > #sleep 5
    > /scripts/removenfsip.sh
    > sync
    > sleep 5
    > #zrep sync tank/vmrep
    > #sleep 5
    > #the following does the zfs snapshot/send/receive
    > zrep failover tank/vmrep
    > sleep 5
    > #ssh 172.16.50.2 /usr/sbin/zfs share tank/vmrep
    > #sleep 5
    > ssh 172.16.50.2 /scripts/setnfsip.sh
    >
    >
    > So, all goes well, omni-rep2 is now exporting tank/vmrep with NFS, it has the 172.16.50.100 ip address, it is the exact replica of omni-rep1.

    It is a replica, but it isn't the same from an NFS perspective. The files may have the
    same contents, but the NFSv3 file handles are different because they are in two different
    file systems.  For this to work, the clients would have to remount, which blows your
    requirement for transparency.

    >
    > The problem is in ESXi the datastore goes inaccessable.  I can fail back and the datastore comes back online like fine.  I can mount the nfs datastore as a new one with the .100 ip on omni-rep2 so it is being exported properly.

    Yes, works as designed.

    >
    > According to the last paragraph of this
    >
    > https://communities.netapp.com/community/netapp-blogs/getvirtical/blog/2011/09/28/nfs-datastore-uuids-how-they-work-and-what-changed-in-vsphere-5
    >
    > It should work, I have merely changed which host is broadcasting my datastore's IP address.
    >
    > I know a guy named saso? did some iScsi failover recently and noted it worked with NFS.  I am just wondering what I am missing here.

    Saso's solution, and indeed most failover cluster solutions, use shared storage and not
    ZFS replication between the nodes. One good reason to do this is so you can transparently
    failover NFS service.

    NB, the replication method is used often for disaster recovery, because in DR there often is
    no transparent failover requirement.
     -- richard

    --

    Richard.Elling at RichardElling.com
    +1-760-896-4422

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20131108/e9b7d40b/attachment.html>

- Previous message: [OmniOS-discuss] NFS Datastore vmware esxi failover
- Next message: [OmniOS-discuss] NFS Datastore vmware esxi failover
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the OmniOS-discuss mailing list