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. StarWind VSAN 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 VSAN comes with a wide set of options and deployment scenarios. It allows implementation of:
- HyperConverged architecture which assumes running StarWind VSAN on the same physical host where the client, roles, and VMs are running;
- Compute and Storage Separated architecture where StarWind VSAN is running on the dedicated physical box(es) as storage;
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, StarWind VSAN becomes a part of the hypervisor host. This results in both outstanding performance and unified administration using hypervisor-specific management tools. StarWind VSAN gets the job done with all major virtualization platforms covered, as an installed application on Windows Hyper-V, or nested inside a VM on VMware vSphere. Non-virtualized clusters typically deployed for performance-intensive SQL Server and Exchange installations are also fully supported.
StarWind VSAN 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 host
Installation on Guest VM
This option assumes creating a Windows Server-based VM and installing StarWind Virtual SAN on it, or deploying from the OVF template a Linux-based VM with StarWind Virtual SAN inside. 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 links:
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 firstname.lastname@example.org
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 VSAN 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 (as Windows-based application or as Linux-based VM on ESXi) 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 large environments. This is caused by possible virtual resources underprovisioning that results in a 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:
For Windows Server (Hyper-V): StarWind Virtual SAN® Compute and Storage Separated 2-Node Scenario with Windows Server 2016