StarWind Virtual SAN® is entirely software-based, hypervisor-centric virtual machine storage. It creates a fault-tolerant and high-performing storage pool that is built for the virtualization workload “from scratch”. StarWind Virtual SAN® basically “mirrors” inexpensive internal storage between hosts. Virtual SAN completely eliminates any need for an expensive SAN or NAS or other physical shared storage. It seamlessly integrates into the hypervisor for the unbeatable performance and exceptional simplicity of use.
StarWind comes with a wide set of options and deployment scenarios. It allows implementation of:
- HyperConverged architecture which assumes running StarWind on the same physical host where the client is running
- Compute and Storage Separated architecture where StarWind is running on the dedicated physical box(es).
This guide is intended for highlighting the peculiarities of each implementation scenario, along with its pros and cons.
The full set of up-to-date technical documentation can always be found here, or by pressing the Help button in the StarWind Management Console.
In this scenario, Virtual SAN becomes a part of the hypervisor. This results in both outstanding performance and unified administration using hypervisor-specific management tools. Virtual SAN gets the job done with all major virtualization platforms covered, as a native application on Hyper-V and Windows, and nested inside a VM on VMware vSphere. Non-virtualized clusters typically deployed for performance-intensive SQL Server and Exchange installations are also fully supported.
Virtual SAN leverages all benefits of the local storage such as high performance and minimal latency. This is achieved by bonding all I/O to the local hypervisor node. This provides multiple benefits compared to a dedicated hardware solution:
- Hypervisor reads from local storage only. High-speed synchronization network links are used to replicate writes to the partner hypervisor nodes.
- The cache is local, so the performance gain is much better compared to the cache sitting behind a slow network.
- Hypervisor nodes do not interfere when accessing the LUN, which increases performance and eliminates unnecessary iSCSI lock overhead.
There are few options for deploying StarWind Virtual SAN in the HyperConverged scenario:
- Installation on the guest VM
- Installation directly on the hypervisor
Installation on Guest VM
This option assumes creating a Windows Server based virtual machine, installing StarWind Virtual SAN, and configuring all components manually. Such approach is mostly used in cases when quick storage deployment is required. An additional benefit of such approach is ability to run the system in an isolated environment, thus making this approach a perfect fit for VMware-based environment deployment or trialing the product on VMs.
The guide on configuring the basic two-node setup with the VMware ESXi hypervisor platform is available by the following link:
Installation on Hypervisor Directly
This option assumes that StarWind Virtual SAN is installed on the hypervisor’s physical partition, so the storage will run without any additional virtualization abstraction layer. As a result, this deployment type is considered to provide the highest performance among all hyperconverged options, while maintaining the benefits.
The guide configuring the basic two-node setup is available by the following link:
For VMware: option of deploying such configuration for VMware infrastructures is currently unavailable. If interested in such functionality, please let us know about this by emailing to email@example.com
Compute and Storage Separated Architecture
StarWind Virtual SAN can also run on a dedicated set of hosts, creating a separated storage layer used by client hypervisors. Though the hyperconverged scenario is an industry trend now, the differentiation of compute and storage layers makes sense if there is a need to grow by capacity only. Typical use cases are shared storage for huge clustered SQL Server and Oracle deployments.
While running StarWind in Compute and Storage Separated (or Dedicated) architecture, it is possible to scale compute and storage resources independently, with different leverages regardless of each other. As a result, the system fits the task better while CapEx and OpEx get lower, since there is no need to purchase hardware that will be essentially wasted. Thus, the system can be created specifically for a particular task.
Installation on Dedicated Host
This option assumes installation of StarWind Virtual SAN on the Windows Server that is running on a separate physical box and acts as a storage provider for the compute nodes. As mentioned before, it leverages really sensitive hardware utilization control. Unlike some cases of hyperconverged architecture, this type of deployment is usually considered for the large environments. This is caused by possible virtual resources underprovisioning that results in significant waste of budget on the hardware that could remain unused.
The guides on configuring the basic two-node setup with different hypervisor platforms are available by the following links: