When a NAS server fails over, it sends out IIRC 8 gratuitous ARPs to the switch from the target array, basically registering it into the CAM table (aka MAC-ADDRESS-TABLE) on the target switch (that is if the IP isn't changing). If your 2 Unity boxes are at the same site, or if you are taking the IP with you to the other side by spanning the VLAN across sites then the trace route might not look very different. If the IP on the target site is different, then the NAS Server would be dynamically re-registering in DNS. Then you should be doing nslookups, and seeing if the IP changes.
Thank you Chris! The 2 Unity boxes are not at the same site, however they are in the same VLAN. I believe the failover takes the NAS server IP with it to the DR Unity box at the other site. Do you know a simple way to "prove" the DR test failover and failback actually happened, maybe outside of Unity Unisphere? This is for CIFs and NFS.
1. Start a continuous ping before you failover. Watch it closely, you'll probably see a couple of packets drop as the failover happens. The goal is to complete the failover within a standard SMB/CIFS time-out window which is about 45 seconds.
2. Use ARP from some other machine in the same broadcast domain (same VLAN). Because although the IP may not change as you're spanning VLANs, the physical adapter will have a different MAC address.
Here is it's Mac address as reported from another system using 'arp'
hostname-1# arp iiq.vdc1.dobi
iiq.vdc1.dobi (192.168.11.61) at 00:50:56:85:90:fb on eth1 expires in 633 seconds [ethernet]
Now all you would have to do for your NAS server, is run this command before failover, and after failover, and ensure that it changed. Moving it from 1 SP to another would have the same effect.
Awesome, thanks. I was able to see the MAC address changes for the failover using ARP. The only thing still weird is the ping does not timeout for the original failover. It only times out for the failback.
Sure, YW. I guess that is interesting, but as long as you only miss a few packets, and the total offline period is not more than 45 seconds, most clients won't notice the difference at all. Which is of-course ideal.
I was able to "prove" the DR test with the CIFs share, using the arp table as you suggested. However I can't seem to find the NFS share IP in the arp table. I believe it is because the NFS share is mounted on a Linux VMware host on my local PC. I'm trying to think of other ways to prove the DR test actually happened for the NFS share now.
crklosterman
450 Posts
1
May 8th, 2018 08:00
When a NAS server fails over, it sends out IIRC 8 gratuitous ARPs to the switch from the target array, basically registering it into the CAM table (aka MAC-ADDRESS-TABLE) on the target switch (that is if the IP isn't changing). If your 2 Unity boxes are at the same site, or if you are taking the IP with you to the other side by spanning the VLAN across sites then the trace route might not look very different. If the IP on the target site is different, then the NAS Server would be dynamically re-registering in DNS. Then you should be doing nslookups, and seeing if the IP changes.
~Chris
Merlinn789
1 Rookie
•
11 Posts
0
May 8th, 2018 08:00
Thank you Chris! The 2 Unity boxes are not at the same site, however they are in the same VLAN. I believe the failover takes the NAS server IP with it to the DR Unity box at the other site. Do you know a simple way to "prove" the DR test failover and failback actually happened, maybe outside of Unity Unisphere? This is for CIFs and NFS.
crklosterman
450 Posts
1
May 8th, 2018 09:00
Well a few ways,
1. Start a continuous ping before you failover. Watch it closely, you'll probably see a couple of packets drop as the failover happens. The goal is to complete the failover within a standard SMB/CIFS time-out window which is about 45 seconds.
2. Use ARP from some other machine in the same broadcast domain (same VLAN). Because although the IP may not change as you're spanning VLANs, the physical adapter will have a different MAC address.
Here is an example. A linux server's Mac address:
[administrator@iiq ~]$ /sbin/ifconfig | grep HWaddr
eth0 Link encap:Ethernet HWaddr 00:50:56:85:90:FB
Here is it's Mac address as reported from another system using 'arp'
hostname-1# arp iiq.vdc1.dobi
iiq.vdc1.dobi (192.168.11.61) at 00:50:56:85:90:fb on eth1 expires in 633 seconds [ethernet]
Now all you would have to do for your NAS server, is run this command before failover, and after failover, and ensure that it changed. Moving it from 1 SP to another would have the same effect.
~Chris
Merlinn789
1 Rookie
•
11 Posts
0
May 8th, 2018 12:00
Awesome, thanks. I was able to see the MAC address changes for the failover using ARP. The only thing still weird is the ping does not timeout for the original failover. It only times out for the failback.
crklosterman
450 Posts
0
May 8th, 2018 13:00
Sure, YW. I guess that is interesting, but as long as you only miss a few packets, and the total offline period is not more than 45 seconds, most clients won't notice the difference at all. Which is of-course ideal.
~Chris
Merlinn789
1 Rookie
•
11 Posts
0
May 16th, 2018 07:00
I was able to "prove" the DR test with the CIFs share, using the arp table as you suggested. However I can't seem to find the NFS share IP in the arp table. I believe it is because the NFS share is mounted on a Linux VMware host on my local PC. I'm trying to think of other ways to prove the DR test actually happened for the NFS share now.
-John H