Best Practice for DSS Autofailover

Hello,

because the iSCSI failover thread is already very long I want to start a new one ...

I'm testing iSCSI autofailover with two DSS demo servers and I think it's a really good solution :) ! I tested it with SQL DB, streaming, copying files ... while doing the failover without any interruption (maybe video stucks for one second ...), great! Then I "killed" the primary (power off), powered on again, sync, failback, also without troubles. Next test is Hyper-V VHD on the iSCSI disk ...

But: I can't find any "best practice" whitepaper, e.g. how to do cluster-safe patching, upgrading, NIC layout ...

- What is the right patching practice? First patch the secondary, then primary ...? Are all coming patches autofailover-safe (running the cluster with different versions)?
- How to configure 2 DSS with e.g. 6 GBit-NICs (example: 2 virtual IPs for iSCSI MPIO, 2 bonded for quick replication, 1 management, 1 NAS ...)?
- Can I add more volumes to running cluster?

regards,
Lukas

We do not recommend running different versions of DSS with the auto failover enabled. All updates are safe to perform. You can update Primary or Secondary in any order just make sure that they are in Sync to original position of the Primary.

So if you update the Secondary first then reboot the Primary will state that its Service is running degraded mode (this is normal). Once the Secondary is back up w/ the update then go to the Failover manager and click the start button and perfrom the update to the Primary.

In order to add additional volumes to be replicated from the Failover task fields you will have to stop the Failover Manager then add from the Failover task then apply and start the Failover Manager again.
The link below provides details on how to setup your failover – click on the 5th one down.

http://www.open-e.com/library/product-presentations/

Quote:

---

Originally Posted by To-M

In order to add additional volumes to be replicated from the Failover task fields you will have to stop the Failover Manager then add from the Failover task then apply and start the Failover Manager again.

---

OK, but how can I do that WITHOUT iSCSI interruption? The virtual IP will go down when I stop the failover service and so I can't access the iSCSI target anymore ... Is there a solution/work-around? If I use a clustered SAN, I don't want to have any interruption in use (ever on) ...

Lukas

This is currently what we have available now. In future releases (no ETA) we will address this issue.

I haven't had a chance to get this up and running yet - simply because I want to understand all the caveats before moving forward. Seems like limitations are still being uncovered.

That being said, I'd like to understand the status of the iSCSI target on the secondary end. If the iSCSI target on the secondary was at the bare minimal readable - then it's possible use multipathd on Linux for active/passive.

Other than that - the only thing I can think of is an external load balancer. But the LB won't fully understand how to perform the switchover at purely layer 3 or layer4. You'd need an enhanced script.

If the virtual IP is now 'active' on the secondary (in otherwords, the secondary is now serving the data) and I stop the failover mgr on the primary, will that stop the virtual ip running on the secondary server?

Yes because you are completely stopping the service completely. When stopping the service a popup message will appear making you aware the this will cause the Virtual IP Address to be deactivated as well and all connections will be lost.