Let’s imagine a situation: a power outage went out and an incorrect server shutdown has occurred. Everything is aggravated by the fact that you have no power backup. What will happen to your write operations? They sink into oblivion and data will be lost. But StarWind says “no” to these troubles! Log-structured Write-Back Cache (LSWBC) is a StarWind feature which speeds up the processing of write requests and saves data when the server is incorrectly shut down. What about RAM caching? Your data also will be saved.

Let’s be honest, any system administrator may face the need of hot-adding the network interfaces to the guest VMs in his Microsoft Hyper-V environment one day. And that’s no problem as Windows Server 2016 brought in a whole set of useful features, one of which is the ability to add and remove network adapters on the running VMs. Moreover, you can do that in two ways – GUI, if you’re looking for a straightforward process and PowerShell if you are a fan of automation.

Today I will deal with data deduplication analysis. Data deduplication is a technique that helps to avoid storing repeated identical data blocks. Basically, during the deduplication process, unique data blocks, or byte patterns, are identified and written to the storage array after being analyzed. While such analysis is a continuous process, other data blocks are processed and compared to the initially stored patterns. If a match is found, instead of storing a data block, the system stores a little reference to the original data block. In case of small environments, this is not crucial mostly, yet for those with dozens or hundreds of VMs, the same patterns can be met numerous times. Thus, due to the advanced algorithms used, data deduplication allows storing more information on the same physical storage volume compared to traditional data storage methods. This can be achieved in several ways, one of which is StarWind LSFS (Log Structured File System), which offers inline deduplication of data on LSFS-powered virtual storage devices.

If you have a single environment with only several iSCSI targets discovered from a couple of target portals, messing with automation may not be worth it. Yet, if you have multiple environments with a bunch of portals and targets that need to be discovered and connected, and all of them are more or less similar in terms of configuration, you might find your resort in automating the whole process. I hope to post some other automation things here, so tune in and check the StarWind blog from time to time.

During its lifetime, any system reaches a point when it needs to be upgraded, either in terms of hardware or software. Today, I will talk about such changes, in particular, about upgrading Windows Failover Cluster nodes from Windows Server 2012 R2 to Windows Server 2016 with no production interruption. Thanks to Microsoft, we do have a Cluster Rolling Upgrade procedure at our fingertips, and I am going to get through it and confirm it works for virtualized disks as cluster shared volumes in Windows Failover Cluster. This procedure assumes rebuilding nodes with clean OS deployment one by one, while the production keeps running from the other cluster node.