Best Practice for initiator's when target has to reboot

[bgarlock]

Hi,

I'm a bit of a newbie to all of this, so please bear with me. I am just beginning to test out iSCSI in our environment, and it looks like to really have any kind of HA, you need two of everything.

For cash strapped folks, what is a best practice for when a target needs to be rebooted (like for Windows updates) - should you shutdown the initiators first, or just reboot the target?

How does everyone handle the monthly Windows updates? I know in a HA environment, the storage is essentially in two locations, so you can restart one server, wait for everything to come back up, and restart the other.

Also, most of my testing has been with Linux initiators; and with tuning the kernel, I'm getting about 85 MB/s to a Win2k3 server, with a 'Virtual Hard Disk Image' with StarWind. Not too bad, as the local disk only gets 90 on that particular machine.

Many thanks,

Bruce

[kmax]

Depends on what you are most comfortable with and of course test everything before production.

When I do updates to a node I basically run what I want manually and reboot. The HA part will cover the failover part without issue. At worse, users will get a slight pause. When it comes back up the node will resync.

Now what you don't want to do is to reboot the other node during a resync. So don't do automatic updates which could cause both to reboot at about the same time.

In short, for hyper-v, disconnecting the targets on the hosts before rebooting the target node will be no different than just rebooting the node.

[bgarlock]

Very good to know, kmax! Thanks so much for your insight. Now I need to come up with some sort of extended outage plan. Our area is notorious for blackouts - sometimes lasting up to 4 hours. Although our entire town is completely being upgraded for the electrical infrastructure, I'm going to put in for a generator. I don't trust UPS's to manage automatic shutdowns - I've never had them work like I want.

As far as a "Who should be shutdown first" - it sounds like I would want to shutdown all the initiators first, and then the target storage, to keep everything clean. Which is what we do right now, but let's say something happens unexpectedly, and we were to lose all power to the target storage node, but not the initiator - how do they handle that? i.e. how long until the initiators start really throwing fits about the target being unavailable? (I'm sure a lot of that's configurable)

I know our local hospital had a major issue getting their SAN up and running, as we had a major power outage here like 4 years ago, where an ice storm brought everything down for 8 days! I've heard the horror stories about getting the VM's up and running again, because things were not shutdown properly, and since we are adding a few extra layers with iSCSI, and virtualization, I just want to live through these in testing before pushing to production

Many thanks,

Bruce

[kmax]

No problem Bruce.

Last summer we suffered a major storm that knocked power out for several days. Fortunately (or wishing I was in the Bahamas) I was there. So I did my best to do a clean shutdown on the vm guests and then power off the HA nodes. Not all of us have generators to keep one node alive 24/7. So basically, if running off UPS one would want to use an agent that would shut down a HA node earlier than the first. That way when you come back to the disaster you know what node to synchronize off of. One of those features they added that helps a lot...picking the good node you know has the last written data.

I've given my gripes several times, but this is a solid product that once is setup right you can trust. It has bailed me out many of times.

[Max (staff)]

Kmax, thanks for sharing this with us!
I would only add that shutting down one HA node before the other also extends the lifetime of your remaining node.
So it's also few more minutes to do a clean shutdown of the VMs and apps that depend on this SAN.