5.4 upgrade from 5.3

[peter.auchincloss]

Is there an upgrade document available for HA deployment?
Peter

[peter.auchincloss]

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?

[Max (staff)]

[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]

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)

[Max (staff)]

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]

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 !

[Max (staff)]

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

[peter.auchincloss]

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?

[anton (staff)]

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

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]

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?

[Max (staff)]

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]

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

[Max (staff)]

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]

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

[anton (staff)]

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.

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