StarWind Resource Library

StarWind Virtual SAN Getting Started

Published: August 5, 2015

Introduction

StarWind Virtual SAN is entirely software-based, hypervisor-centric virtual machine storage. It creates a fully 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 unbeatable performance and exceptional simplicity of use.

StarWind comes with the different set of options and deployment scenarios. It allows implementation of:
• Hyper-Converged 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.

This guide is intended to highlight the specific of each implementation, its pros and cons.

A full set of up-to-date technical documentation can always be found here, or by pressing the Help button in the StarWind Management Console.

For any technical inquiries, please visit our online communityFrequently Asked Questions page, or use the support form to contact our technical support department.

Hyper-Converged architecture

With this scenario Virtual SAN is a natural part of the hypervisor. The result is both outstanding performance and unified administration using hypervisor-specific management tools. Virtual SAN “gets the job done” with all major virtualization platforms running on Hyper-V and Windows as a native application and on vSphere or Xen nested inside a VM. 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 like high performance and minimal latency. It 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 cache.
• Cache is local, so the performance gain is much better compared to cache sitting behind slow network.
• Hypervisor nodes don’t fight for LUN ownership, which increases performance and eliminates unnecessary iSCSI lock overhead.

There are few options of deploying of the StarWind Virtual SAN in the Hyper-Converged scenario:

• Manual installation on the guest VM
• Manual installation directly on the hypervisor

Manual installation on guest VM

This option assumes creating the Windows Server based Virtual Machine, installing StarWind Virtual SAN and configuration of all the components manually. Such approach is most recently used in cases when it is required to perform quick storage deployment, which achieved as the result of absence of need to install the drivers as an example. Additional benefit of such approach is ability to run the system in isolated environment, thus making this approach perfect fit for fast and safe trialing

Below you can find the link to the manual that explains how to configure the basic two node setup with different hypervisor platforms. Hyper-V: coming soon VMware: https://www.starwindsoftware.com/starwind-virtual-san-hyper-converged-2-nodecluster-vmware-vsphere

Manual installation directly on the hypervisor

This option assumes installation of the StarWind Virtual SAN on the parent partition of the hypervisor, so the storage will run without possible additional virtualization abstraction layer. As the result, this deployment type is considered to be the most highly performable one of all the hyper-converged options, while keeping all the benefits.

Below you can find the link to the manual that explains how to configure the basic two node setup with different hypervisor platforms.

Hyper-V: https://www.starwindsoftware.com/starwind-virtual-san-hyper-converged-2-nodesscenario-2-nodes-with-hyper-v-cluster
VMware: option of deploying such configuration for VMware infrastructures is currently unavailable. Please let us know if you are interested in seeing such functionality by emailing to support@starwind.com.

Compute and Storage Separated architecture

StarWind Virtual SAN can also run on a dedicated set of hosts creating a separated storage layer being used by consumers. Though a hyper-converged scenario is an industry trend now, the differentiation of compute and storage layers makes sense if there’s need to grow by capacity only. Typical use cases are shared storage for huge clustered SQL Server and Oracle deployments and an inexpensive block back-end for Scale-Out File Servers.

While running StarWind in Compute and Storage architecture, it is possible to scale compute and storage resources independently, with different leverages regardless from each other. As a result, the system better fits the task while CapEx and OpEx go through the floor, since there is no need to purchase hardware that will be essentially wasted. Thus the system can be created specifically for a particular task.

Manual installation on the dedicated host

This option assumes installation of the StarWind Virtual SAN on the Windows Server that is running on the separate physical box. As mentioned previously it really sensitive hardware utilization control leverages, such deployment usually considered for the big deployments, where underprovisioning may result in significant waste of budget on the hardware that wouldn`t be actually used, as in some case of hyper-converged architecture usage.

Below you can find the link to the manual that explains how to configure the basic two node setup with different hypervisor platforms.

Hyper-V: https://www.starwindsoftware.com/starwind-virtual-san-compute-and-storageseparated-2-nodes-with-hyper-v-cluster
VMware: https://www.starwindsoftware.com/starwind-virtual-san-compute-and-storageseparated-2-node-cluster-iscsi-vmware-vsphere