StarWind Virtual SAN: Architecture Overview
- July 26, 2022
- 6 min read
- Download as PDF
Introduction
StarWind Virtual SAN is an entirely software-based hypervisor-centric shared storage provider. This solution provides a fault-tolerant high-performing storage pool that is tailored for virtualization workloads. StarWind Virtual SAN basically “mirrors” inexpensive internal storage between hosts. StarWind VSAN completely eliminates any need for expensive SAN, NAS, or other physical shared storage. It seamlessly integrates with the hypervisor for unbeatable performance and exceptional simplicity of use.
StarWind VSAN comes with a wide set of features and can be used for two main deployment scenarios:
- HyperConverged – StarWind VSAN is deployed on the same physical host where the client, VMs, and other roles are running
- Compute and Storage Separated – StarWind VSAN is deployed on the dedicated physical storage server(s)
This technical paper discusses both architecture types and StarWind VSAN deployment scenarios.
The full set of up-to-date technical documentation can always be found here, or by pressing the Help button in StarWind Management Console.
For any technical inquiries, please visit our online community, Frequently Asked Questions page, or use the support form to contact our technical support department.
HyperConverged Architecture
In hyperconverged environments, StarWind VSAN becomes a part of a hypervisor host. This deployment scenario enables to achieve both outstanding performance and unified administration with hypervisor-specific management tools. StarWind VSAN gets the job done with all major virtualization platforms: it can be installed as an application on Windows Hyper-V or nested inside a VM on VMware ESXi. Non-virtualized clusters typically deployed for performance-intensive SQL Server and Exchange installations are also fully supported.
In hyperconverged setup, StarWind VSAN leverages all benefits of the local storage such as high performance and low latency. This is achieved by bonding all I/O to the local hypervisor node. Such a design provides multiple benefits over a dedicated hardware solution:
- Hypervisor reads from local storage only. Synchronization network links are used to replicate writes to the partner hypervisor nodes.
- The cache is local, so the performance gain is much higher 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 a Guest VM
This option implies creating a Windows Server-based VM and installing StarWind Virtual SAN on it or deploying a Linux-based VM with StarWind Virtual SAN inside from the OVF template. Installing StarWind VSAN on a guest VM, i.e., running the solution in an isolated environment is a perfect fit for cases when quick storage deployment is required or trialing the product on VMs.
Guides on configuring a two-node setup with the VMware ESXi are available at the following links:
Windows Server-based VM: https://www.starwindsoftware.com/resource-library/starwind-virtual-san-hyperconverged-2-node-scenario-with-vmware-vsphere-7/
Linux-based VM: https://www.starwindsoftware.com/resource-library/starwind-virtual-san-for-vsphere/
Installation Directly on a Hypervisor Host
This option implies that StarWind Virtual SAN is installed on the hypervisor’s physical partition so the storage can be accessed 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 on configuring a two-node setup is available at the following link: https://www.starwindsoftware.com/resource-library/starwind-virtual-san-hyperconverged-2-node-scenario-with-hyper-v-cluster-on-windows-server-2016
This deployment option is currently not available for VMware ESXi. You are always welcome to contact us at support@starwind.com if such a deployment option is needed.
Compute and Storage Separated Architecture
StarWind Virtual SAN can also run on dedicated servers, creating a separated storage layer for client hypervisor hosts. Even though the hyperconverged scenario is an industry trend now, differentiation of compute and storage layers is still a viable option when it is necessary to scale storage capacity or compute resources independently. A typical use case of this architecture is shared storage for clustered SQL Server or Oracle deployments.
While running StarWind VSAN in a compute and storage separated (or dedicated) architecture, it is possible to scale compute and storage resources independently. Such systems fit the task better while CapEx and OpEx get lower since there is no hardware underutilization. Thus, the system can be created specifically for a particular task.
Installation on a Dedicated Host
This option implies the installation of StarWind Virtual SAN as a Windows-based application or Linux VM. The storage server is a separate physical box and acts as a storage provider for the compute nodes. As mentioned above, dedicated infrastructure provides sensitive control over hardware utilization. Unlike some cases of hyperconverged architecture, this deployment type is often 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.
Guides on configuring a two-node setup are available at the following links:
For Windows Server (Hyper-V): StarWind Virtual SAN® Compute and Storage Separated 2-Node Scenario with Windows Server 2016
For VMware ESXi: StarWind Virtual SAN® 2-node Compute and Storage Separated scenario with VMware vSphere 6.5
