Hardware-less VM Storage
Sign In Contact us
After both nodes of the HA cluster were down simultaneously in some cases StarWind is not able to determine which node holds the most recent data. So it blocks all the incoming connections until the synchronization begins to prevent the data corruption. If you know for sure which node was shut down last – choose it as the synchronization source in the drop down menu of the HA device – Synchronization, or mark as synchronized the node with actual data choose from the dropbox by right clicking on the HA device and choosing the corresponding option.
The second option assumes automatic start of the synchronization. If you are not sure about it – delete the HA targets from the StarWind Management console, mount HA images as basic targets. Important notice: keep in mind that you just need to find out if the data is consistent, so make sure that any new data won`t be written to the target on this step. Check which node has the most recent data, remove the target and recreate the HA device running the synchronization in appropriate direction.
Unlike file-level protocols like used in NAS, iSCSI is a block-level protocol. Thus it cannot arbiter read-write access to the iSCSI device connected to multiple servers. Thus, to provide access to one device from multiple servers the device needs to have a clustered file system. 3rd party arbiter SAN management software (DataPlow SFS, MelioFS, MetaSAN etc) should be used for individual client servers. If using vSphere 3rd party management software is not necessary since VMFS is a clustered file system. At the same time Microsoft failover clustering allows to share single storage device between the nodes of the cluster. For instance, Hyper-V failover clustering is achieved by converting the iSCSI storage to a Cluster Shared Volume (CSV).
Click on the corresponding device in the Starwind management console. In the right side window find Replication Node Interface and click on it. In the window that will appear you can edit heartbeat and synchronization channels settings on the fly.
This information can be found in our press release section and on the forum. This information is also included in our newsletter.
Changelog can be found on the forum. It can be also reviewed during StarWind installation process and later as a changelog.txt file in the StarWind installation folder.
We highly recommend using Write-Back caching. Write-Back caching improves write speed and lowers the latency unlike Write-Through caching which improves only the read speed. Cache expiry period is the timeframe data is kept in cache from the moment of the last access till the moment it is flushed to the disk.
Heartbeat is an advanced mechanism which is used to avoid data corruption in case of synchronization channel failure. If data can`t be transferred through the synchronization channel StarWind checks availability of the second node through the alternate network interface, and shuts down secondary node in case of synchronization channel failure.
Please note that upgrading from version 6 to version 8 requires having the version 8 license key.
Strong notice: Mirror, IBV and Deduplication devices of version 6.x and earlier versions are not fully supported in v8.0! Data from existing Mirror, IBV and Deduplication devices must be migrated to new ImageFile or LSFS devices after installation.
In StarWind console choose the device that you want to modify and click on Extending Size of HA (High availability) Device/Image File Size button in the right side window. Then specify disk space that you want to add and click "Finish" button.
We strongly recommend connecting every data link to a dedicated subnetwork (every synchronization channel and heartbeat). When you select one IP, the wizard automatically reserves all IPs in the subnet. This is intended to protect the StarWind users from misconfiguring HA by assigning Heartbeat and Synchronization Channel to the same data link.
Hardware update does not require downtime. We recommend the following sequence that assumes that Windows, its roles and features are already installed and configured on new Node 1 and Node 2.
To migrate StarWind HA to new hardware:
Note: It is recommended to add the next device replicas after the previous device has finished to synchronize)
Note: It is recommended to add the next device replicas after the previous device has finished synchronization.
You can change cache size on fly only for HA. In Starwind console you need to open *.swdsk of corresponding device in your Storage pool and edit the line:
<- cache type="write-back" size="128" units="MB" level="1" -> * by setting required size.
Then you need to restart service, wait for synchronization process to end and repeat abovementioned steps on each StarWind node one-by-one.
Note: in HA if you change cache mode it is necessary to change it on all the nodes.
For non-HA it will cause downtime, because you need to turn into offline your storage.
Note: in HA if you change cache mode it is necessary to change cache mode on all nodes. Cache size can be different.
The storage pool is default path to place StarWind virtual disks (LSFS proprietary files, *.img, etc. )
Please, edit StarWind.cfg file as described in the following manual and restart the service.
You need to install MPIO (MultiPath I/O) Feature to make Windows recognize the HA devices properly.
You can find how to do it in the following manual for Windows 2003(R2), Windows Server 2008 (R2).
Yes, StarWind iSCSI target fully supports SCSI-3 required to build a Hyper-V cluster. You can find how to make CSV in the following manual.
Yes, StarWind fully supports both hypervizors.