5.4 upgrade from 5.3

peter.auchincloss · Mon Jul 26, 2010 4:44 pm

Is there an upgrade document available for HA deployment?
Peter

peter.auchincloss · Tue Jul 27, 2010 9:17 pm

ok - found updated document for most current version
I also noticed updated TCP / NIC optimazation etc for 2008 r2 (thanks)

after upgrading both nodes how do you enable options for caching and autosync after failures for existing targets?

Wed Jul 28, 2010 10:50 am

[quote="peter.auchincloss" after upgrading both nodes how do you enable options for caching and autosync after failures for existing targets?[/quote]
The steps are the following:
1. Disconnect all HA targets from the clients
2. Resynchronize targets (if unsynchronized)
3. Remove the targets
4. Recreate the targets using exisiting images, set the desired options.
5. Select "do not synchronize virtual disks" initialization option.

peter.auchincloss · Wed Jul 28, 2010 1:22 pm

i have ha iscsi target connected to two nodes of cluster as cluster shared volume
after performing steps (deleting and recreating targets) the csv comes up with redirected access on the cluster - to get the redirected access off the after disconnecting iscsi targets the favorites for primary and secondary targets have to be deleted and recreated

Is there anyway to avoid this - obstacle if target changes require cluster iscsi reconfiguration!
(toggle HA options on original targets at Starwind Management Console level)

Wed Jul 28, 2010 3:04 pm

I wold like to recommend you to change owner of the CSV in order to bring it to normal state,
Another way to avoid this is to create the targets with different names.

peter.auchincloss · Wed Jul 28, 2010 5:27 pm

figured that out - extra work if you have 10+ targets ..

It would be a useful feature if this could be toggled from the Starwind management Console for a future revision !

Wed Jul 28, 2010 8:16 pm

We are already working on this, in a few month things will become completely different

peter.auchincloss · Thu Jul 29, 2010 1:59 pm

Also noticed on restart if auto-synchronization enabled with 10+ targets
(replication nic saturated - I still need to do some nic optimization with this) sync much slower than manually doing in groups of 2

It might be a useful feature to permit synchronization priorities (or delay for targets) to minimize network collisions for given replication link bandwith?

Thu Jul 29, 2010 7:38 pm

You're right! But it's quite a rare situation (for now) so we'd prefer to fix another things before adding this feature

peter.auchincloss wrote:Also noticed on restart if auto-synchronization enabled with 10+ targets
(replication nic saturated - I still need to do some nic optimization with this) sync much slower than manually doing in groups of 2

It might be a useful feature to permit synchronization priorities (or delay for targets) to minimize network collisions for given replication link bandwith?

peter.auchincloss · Fri Jul 30, 2010 12:47 pm

After Upgrade and restart on secondary is it usual behaviour for iscsi connections to see two on secondary target

primary
iqn.2008-08.com.starwindsoftware:haip001.itu.xx.xx-hahvT1Partner

secondary
iqn.2008-08.com.starwindsoftware:hagw001.itu.xx.xx-hahvT1
iqn.2008-08.com.starwindsoftware:hagw001.itu.xx.xx-hahvT1

Is the autosync process equivalent to a fast sync?

Fri Jul 30, 2010 2:18 pm

This is an iSCSI initiator issue which does not affect the HA configuration or functionality. You should disconnect the node which has 2 connections from the client server, stop the Starwind service, disconnect both HA targets from the server, remove them from the favourites list and then start the service.

peter.auchincloss · Fri Jul 30, 2010 2:51 pm

these are on the replication link btw the primary and sceondary HA nodes - initiated by the starwind setup - they don't appear in favorites

Fri Jul 30, 2010 3:11 pm

The how-to for removing the second session remains the same, you just need to disconnect the targets when the service is stopped. After refreshing the iSCSI initiator one of the targets should disappear.
Second phantom connection is harmless. Things could be much worse if there were no connections listed

peter.auchincloss · Sun Aug 01, 2010 5:04 am

back to earlier question -
What is the auto sychronization method for targets with write-back cache enabled?

It appears to be going thru full sync -
amount of data across replication link and time required to get second node online

Sun Aug 01, 2010 6:56 pm

Cache mode (write back or write thru) has nothing to do with sync mode. It's completely up to how target was shut down. If we can - we'll do fast sync. If not - full sync path is going to be used.

peter.auchincloss wrote:back to earlier question -
What is the auto sychronization method for targets with write-back cache enabled?

It appears to be going thru full sync -
amount of data across replication link and time required to get second node online