Starwind released recently a new version of their iSCSI SAN solution, Starwind 5.7. It includes several new features that scale up this already great SAN solution, providing some important improvements regarding performance, monitoring and usability for IT administrators.
Some of the improvements included:
-
Re-worked and re-designed completely from the scratch all-new HA (high-availability) engine 2x-3x faster compared to previous versions.
-
Quality of Service (QoS) options added.
-
Data de-duplication with variable block size (512 byte – 256 KB) to save on storage especially in hypervisor scenarios.
-
Performance monitor included in Starwind console.
-
Snapshot manager.
-
Targets and servers can be arranged in groups.
-
Event notification in system tray.
Within this post we’ll review some of the newest features included, testing them in some scenarios. Here’s what we are going to do:
1. Reviewing Starwind iSCSI SAN 5.7 installation
2. Reviewing improvements in Starwind management console.
3. Reviewing usability and GUI new features.
4. Configuring HA and synchronization priority.
You can download Starwind iSCSI SAN software using this link, previous registration required.
For a detailed step-by-step of creating and configuring a Windows Server 2008 R2 cluster using Starwind check my previous article: Five Easy Steps to Configure Windows Server 2008 R2 Failover Cluster using Starwind iSCSI SAN.
Reviewing Starwind iSCSI SAN 5.7 Installation
As any other version of this solution, the installation steps are pretty simple. Just completing the wizard we’ll have it ready to use it.
We can also install the components separately, in case we want to remotely manage the iSCSI platform.
Once installed, to get started we need to use the “Connect” option and as a reminder, the default credentials used in Starwind are:
User: root
Password: starwind
Reviewing Improvements in Starwind
The management console looks pretty much the same, but adding some interesting tweaks that will be very helpful for IT admins.
The first one is one of the most important ones, the “Performance” tab included. Within this window we can monitor in real time the performance in the current load of the server and targets.
We can retrieve the following graphics: CPU/RAM load (for a quick comparison), CPU load, RAM load, total IOPS and total bandwidth.
The second one is a really simple one, but very helpful. The possibility to create target groups, this lets us easily identify in our servers the right collection.
As a third improvement in the usability of this management console we have the Event notifications in system tray, with this tweak we can receive notification as soon as there is a change in the configuration and availability of our servers and targets.
Configuring HA and synchronization Priorities
As mentioned earlier, the main feature regarding performance changes is the one represented by including asynchronous mode for HA targets.
If you are taking your initial steps with Starwind you are probably wondering about HA targets and asynchronous options, let’s take a quick look about the definitions on each of these concepts:
What are HA (High Availability) Targets?
As we’ve reviewed in my previous chapter, creating clusters and provide high availability for a Windows Server service using Starwind is one of the main purposes of this solution and a very simple task to do. But Starwind also includes the possibility to apply high availability in the shared storage we are providing.
When we are creating our Starwind device (basically the LUN we are going to share among hosts) we can configure it as a “High Availability device”, which can be present in two different Starwind servers. In case the primary server fails, the second one (partner server) can still offer the device without affecting availability.
What about synchronization of the device?
When we are using HA devices, there are two shared disks: one in primary server and the other one in partner server. These are two different devices, meaning that they must be replicated and synchronized.
Here is when the synchronous/asynchronous mode appears.
If the replication is presented synchronous, every change (“write”) in the device must be replicated to the partner device to complete the operation. If we don’t have a good design or the bandwidth presented between these two is not a good one, the performance of HA targets reduces significantly.
Synchronous replication example (image taken from cisco.com):
If we are using asynchronous replication, the “write” operation does not have to wait for the replication between the two devices to be completed, improving performance.
Asynchronous replication example (image taken from cisco.com):
The use of synchronous or asynchronous replication must be carefully studied analyzing all factors.
Using HA devices and synchronization options
Creating a target requires only running a simple wizard (as seen in my previous chapter); using HA devices only differs in a few options:
1. Select the “Add target” option.
2. Select “Target Alias” and using “Hard Disk” to create our HA device.
3. Select “Advanced Virtual”.
4. Select “High Availability device” and click on “Next”.
5. Specify the partner server options by providing IP address (or FQDN), port, type of authentication and credentials.
6. In “Virtual Disk Parameters” complete the path for these two devices, primary and partner.
7. In “Data synchronization channel parameters” configure the synchronization interface, heartbeat interface and priority of each server.
8. Select the option “Clear virtual disks” if we are using devices we’ve just created.
Note that these options available here can be very helpful if we created a non-HA device and later we decide to convert it in HA.
9. Select the desired option in “HA device cache parameters”.
10. Complete the wizard and we’ll have our high available device ready.
Once completed the wizard, we get the chance to configure the synchronization options.
Where we can set the synchronization priorities: “Faster synchronization” represents the synchronous mode (waiting the replication to complete the operation) or “Faster client requests processing” represents the asynchronous mode.
The improvements regarding performance will vary depending on the environment we are using, but it could represent 2 or 3 times faster than previous implementations. Cheers to that!
Note:
There are some reports about slow performance in cluster environments using iSCSI, pass-through disks on Hyper-V hosts; this is a known issue in Windows Server 2008 R2 and there’s a Microsoft KB available to solve this problem: http://support.microsoft.com/kb/2020559
More Resources
Here are more resources you can find to take a deep dive in Starwind and Windows Server cluster solutions:
