[OmniOS-discuss] NFS Datastore vmware esxi failover

[Matt Weiss]

I believe most of you are correct.  Just because I failover the data, I 
have not actually failed over the NFS state and therefore my setup will 
not work as intended.

That being said, what are other people using in production for 
transparent failover using NFS?

I have heard of RSF-1, but I was looking to homebrew this.


On 11/8/2013 3:54 PM, Richard Elling wrote:
> Comment below...
>
> On Nov 8, 2013, at 8:17 AM, Matt Weiss <mweiss at cimlbr.com 
> <mailto: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 <mailto:Richard.Elling at RichardElling.com>
> +1-760-896-4422
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20131108/4ecd6b6e/attachment.html>