SAN Virtualization

It is often difficult to work out how Storage Virtualisation, Server Virtualisation, Physical SANs and Virtual SANs fit together, especially in the context of HCI systems and VMware. This is my take on the technology, and I am afraid that the explanation will require a little bit of history.
Storage virtualisation, where physical disks were sliced up and the pieces put back together to form virtual disks, originated with UNIX servers and RAID subsystems. These virtual disks were connected as a direct attached disk. Now say you expected your server to eventually need 100GB (a lot of capacity in those days). You added that disk, but most of the space lay unused for several years. To improve efficiency, servers and disk subsystems were connected together with switches, so the servers could share the disks, and capacity could be added to individual disks as needed. This collection of switches and cabling was called a Storage Area Network, or SAN.

The next logical step was to look at the Windows servers themselves, which were racks and racks of physical boxes with dedicated CPU capacity and memory. In general, each application had its own dedicated Windows box, which was wasteful of both machine room space and resources as enough resource was allocated for peak demand. Along came VMware, which virtualised the Windows servers and so shared out the CPU and Memory resources and smoothed out the peak demand. This Server Virtualisation was later expanded to include Linux. In the meantime, lots of new facilites had arrived in the storage area, like snapshot copies and remote mirroring. However these were controlled by the storage subsystems, so snapshot would only work on the same subsystem and mirroring required that both storage substems be from the same vendor, if not the same model.

To fix these issues, and also to provide a common tool set and tiering of data between storage subsystems, virtualisation was added between the virtualised servers and the virtualisaed disks. This level of virtualisation was called a virtual SAN, although it worked alongside the SAN switches and did not replace them. Two different types of SAN virtualisation were proposed, In-band and Out-band.

In-band virtualisation, sometimes called Symmetric virtualisation or fabric based, sits in between the servers and the storage devices. The storage itself is split up into chunks or extents by the virtualisation device, then these chunks are concatenated together to make virtual volumes, which in turn are presented to the servers. Because the host servers are isolated from the physical storage, data can be migrated between storage systems on the fly, with no changes needed at the host. Copy services are also controlled by the virtualisation engine, and are both transparent to the hosts, and independent of the physical storage type. In fact, the virtualization engine directly controls both the data in the storage devices and all access to those devices, so it can provide locking mechanisms and a firewall which means that the data can be safely shared between file servers.
The main disadvantage of in-band virtualisaion is that it can be a performance bottleneck. I've actually seen performance gurus demand that a particularilty I/O intensive application be removed from SAN virtualisation and given its own dedicated and direct attached disks, although an argument could have been made about how well the application was designed. However, the virtualisation engine is a bottleneck and scalability can be a problem. The answer is to use an n-way cluster of virtualization engines that has failover capacity. In this way you can add additional processor power, cache memory, and adapter bandwidth to improve performance to an acceptable standard. If you run advanced services, such as Copy Services and caching you will need that additional memory and processing power.

Out-of-band virtualisation, sometimes called Asymmetric or controller based, sits outside the data path and the virtualisation engine works on metadata rather than the data itself. The virtualisation engine holds all of the mapping for the data segments on the physica storage, and the locking tables. The storage devices contain only data. Two distinct pathways are needed to the data, a dedicated network or SAN link for control and the SAN paths for the data flow itself. As the data paths are separated from the control path, data access uses the full bandwidth of the SAN.
Once several storage devices are under control, the metadata that manages those devices can become very complicated. Also, the file servers need to know how to access and interpret the metadata, which means that you need agent software installed on every server, or at least specialised device drivers. So the advantage of better scalability is offset by more complexity, and that the virtualisation server cannot run advanced functions, such as caching or Copy Services, because it has no control over the data itself, just the metadata.

So we have two contrasting types of solutions, one which delivers a lot of functions but lacks scalability, and another that is scalable, but lacks functions. In the early days there was a lot of competing products, but the traditional vendors settled down to two main options, IBM's SVC and Dell/EMC's VPLEX. These two are discussed in detail in this section of the site. However a number of new vendors have appeared recently.
A further iteration of virtualisation is to take all the components, servers, network and storage and virtualise the lot into a HyperConverged Appliance (HCA), a solution that is easy to install, but locks you into a single vendor. Exactly how this works is open for discussion as different vendors call their products HCA, but the actual offering might not virtualise all the components. An example of software defined SAN virtualisation is VSAN or VMware virtual SAN, also discussed in this section.

DataCore SANsymphony

DataCore SANsymphony is an in-band solution that runs on storage domain servers. The following is a list of some of the facilities that SANsymphony provides.


StarWind Software Inc. was founded in 2003 and its main product is the StarWind virtual SAN. It offers both software-only and storage appliance variants of its product. It achieves high availabilty by simply 'mirroring' internal hard disks and flash between hypervisor servers. Hypervisor supported includes Microsoft Hyper-V, VMware vSphere/ ESXi, Linux KVM, and Zen. StarWind is designed for SMBs and remote offices where it would be uneconomic to install a full hardware SAN.

At entry level, the StarWind Virtual SAN software based solution works with VMware to create a shared storage environment for a VMware ESXi hypervisor. It can also provide synchronous data mirroring and automatic failover between hypervisors.
It would be possible for a small business to enter the virtualisation market for free with a VMware Essentials entry package and a free 2-node Starwind Virtual SAN, then as the business grows, function can be added at cost later. This entry point would consist of a two-node ESXi configuration with only local disks on every host. The StarWind Virtual SAN software is installed on a VM on each hypervisor. High Availabilty with automatic VM failover between the hosts can be achieved.

Imagine you have two offices. Install an ESXi with StarWind in each office, run StarWind on each side, define one office as the 'production' site with higher spec servers and storage and the other as 'DR' with maybe lower specs and you have a robust DR solution to protect from loss of one site, with automatic failover. The StarWind software looks after mirroring the VMDKs. Cheap and cheerful and a good starting point.
This solution can be expanded as StarWind Vitual SAN scales out and supports an unlimited amount of nodes in a cluster and either 2-way or 3-way replication between HA LUNs. StarWind has a roadmap to enhance the software with individual VM policy support allowing to control not just individual LUNs/datastores but VMs directly by specifying different storage policies.

At a more advanced level, StarWind offers a line of Microsoft Windows based HyperConverged Appliances (HCA), turnkey solutions designed to meet the needs of SMBs that are generally budget constrained. They offer a number of products, including HCA All-Flash, HCA Hybrid, and HCA Disk. These HCA appliances are a 100% software-defined hyperconverged platforms, with different models for different workloads depending on the performance requirement.
The All-Flash is designed for small and mid-size SMB virtualised environments and this configuration provides the best performance.
The Hybrid models are built to provide a high storage capacity and good performance at a reduced cost. They achieve that performance by using automated storage tiering, so performance-intensive workloads are held on the flash tiers, while data which can manage a reduced performance is held on disk.
The Disk models are built for applications which require a lot of capacity, where Flash could be too expensive.

While a two node solution will provide DR protection between sites, or for server failure within a site, StarWind HCA offers protection from disk failure with just a single physical node. This can be extended later by adding more nodes to build a cluster.
For best HA protection, StarWind recommends that you use a Hardware RAID controller, with RAID 10 for SAS or SATA hard drives and RAID 1, 5, 6, 10 for SAS for SATA SSD devices. Software RAID implementations are NOT supported.

Storage Area Networks

Disk Protocols

Lascon updTES

I retired 2 years ago, and so I'm out of touch with the latest in the data storage world. The Lascon site has not been updated since July 2021, and probably will not get updated very much again. The site hosting is paid up until early 2023 when it will almost certainly disappear.
Lascon Storage was conceived in 2000, and technology has changed massively over those 22 years. It's been fun, but I guess it's time to call it a day. Thanks to all my readers in that time. I hope you managed to find something useful in there.
All the best

back to top