*New 11.3 series Release:
2019-10-19: XigmaNAS 11.3.0.4.7014 - released

*New 12.0 series Release:
2019-10-05: XigmaNAS 12.0.0.4.6928 - released!

*New 11.2 series Release:
2019-09-23: XigmaNAS 11.2.0.4.6881 - released!

We really need "Your" help on XigmaNAS https://translations.launchpad.net/xigmanas translations. Please help today!

Producing and hosting XigmaNAS costs money. Please consider donating for our project so that we can continue to offer you the best.
We need your support! eg: PAYPAL

HAST+CARP+iSCSI6+ZFS

Highly Available Storage.
Forum rules
Set-Up GuideFAQsForum Rules
Post Reply
joebell
NewUser
NewUser
Posts: 5
Joined: 09 Jan 2015 10:37
Status: Offline

HAST+CARP+iSCSI6+ZFS

#1

Post by joebell » 15 Feb 2015 23:24

Hi guys,

I created a testing lab in VMWare Workstation by configuring two NAS4Free nodes in a failover storage cluster using HAST+CARP+iSCSI on ZFS volumes. The iSCSI targets shall provide virtual disks for another HA cluster of two Hyper-V Servers 2012 R2 providing redundant virtual machines I have had an idea to create as per this guide. Before it is going to be implemented in a production environment, I made some tests of my NAS4Free HA storage cluster. The failover of HAST resources seems to be OK including the iSCSI failover from one to another node. However, after shutting down both nodes, my Hyper-V servers had lost, of course the connection to the iSCSI targets presented via CARP interfaces. After restarting the NAS4Free nodes, the HAST resources (PRIMARY and BACKUP) had to be manually initiated again, and the same applies to the iSCSI target that had to be started, as well. This is normal I think and can be understood. What is weird, however, was the lost of all data on the ZFS volumes after the iSCSI targets were reconnected again, as I was forced to re-initiate all the virtual disks on the Hyper-V machines from the scratch. Is this correct behavior of a Highly Available Cluster Storage built in NAS4Free OS? Or have I missed something in the configuration someone among you can explain and point out?

Many thanks for any comments in advance.

User avatar
daoyama
Developer
Developer
Posts: 423
Joined: 25 Aug 2012 09:28
Location: Japan
Status: Offline

Re: HAST+CARP+iSCSI6+ZFS

#2

Post by daoyama » 02 Mar 2015 21:27

Hi,
joebell wrote:However, after shutting down both nodes
In HA, it should not occur. This is same as cut off all power without anything.
You must protect the server and the switching HUB by UPS.
If you want shutdown both nodes, you must stop all servers using HAST volume before shutdown.

NAS4Free supports failover automatically. (master -> backup)
You must run failback by manually. (master <- backup)
NAS4Free 10.2.0.2.2115 (x64-embedded), 10.2.0.2.2258 (arm), 10.2.0.2.2258(dom0)
GIGABYTE 5YASV-RH, Celeron E3400 (Dual 2.6GHz), ECC 8GB, Intel ET/CT/82566DM (on-board), ZFS mirror (2TBx2)
ASRock E350M1/USB3, 16GB, Realtek 8111E (on-board), ZFS mirror (2TBx2)
MSI MS-9666, Core i7-860(Quad 2.8GHz/HT), 32GB, Mellanox ConnectX-2 EN/Intel 82578DM (on-board), ZFS mirror (3TBx2+L2ARC/ZIL:SSD128GB)
Develop/test environment:
VirtualBox 512MB VM, ESXi 512MB-8GB VM, Raspberry Pi, Pi2, ODROID-C1

joebell
NewUser
NewUser
Posts: 5
Joined: 09 Jan 2015 10:37
Status: Offline

Re: HAST+CARP+iSCSI6+ZFS

#3

Post by joebell » 04 Mar 2015 17:40

Hi daoyama,

Many thanks for your reply. Everything is understood, incl. UPS. Anyhow, what if I need to shutdown both nodes one by one for some unpredictable reason temporarily? I mean the storage cluster service (HA iSCSI target) will have to be interrupted for a short period of time. After I start them again, why a Microsoft Hyper-V server cannot connect to the target even if I restore the cluster manually after both storage cluster nodes are online? Please keep in mind the MS Hyper-V servers configured as Microsoft Failover Cluster (for failing over the VM machines) were online all the time during this procedure. After this happens, I mean both storage cluster nodes were down and restarted again, I must also re-initiate all the virtual disks on the Hyper-V machines from the scratch, and of course during this procedure all the data in the storage cluster/VM machines that were running on iSCSI target are gone. This strange behavior has been the crucial point of my post.

Post Reply

Return to “HAST”