Hyperconverged vs server SAN – SvSAN Overview Part One

Published On: 18th May 2018//2.1 min read//

Welcome to part one of a three part blog, which aims to provide a technical overview of StorMagic SvSAN. Part one of the blog will provide a brief overview of SvSAN and outline how you can decide whether hyperconverged infrastructure or server SAN is right for you, part two will explore SvSAN in more depth, and part three will define options for deployment models.

StorMagic SvSAN is a software-defined storage solution designed to run on commodity x86 servers, with two servers being the minimum cluster size to provide high availability, and specifically designed with lightweight system requirements in order to deliver highly available, shared storage with centralized management.

Eliminating the need for physical SANs, SvSAN is simple, cost effective and flexible. There are a variety of ways in which it can be deployed, including a typical hyperconverged configuration or a storage-only cluster (also known as server SAN).

Not sure of which deployment model is suitable for you? Don’t worry, we’re here to help…

What is the hyperconverged model?

Consolidating the compute, storage and hypervisor functions into a single server footprint, the hyperconverged model of deployment allows the utilization of the server’s internal storage, creating a pool of highly available shared storage.

Hyperconverged configurations require each server to hold enough CPU and memory for the applications and virtual machines, as well as delivering storage and hypervisor features. Often used as a direct replacement of older storage arrays, these configurations are perfectly suited for environments that require a small footprint and high availability.

Server SAN

In contrast to a hyperconverged solution, server SAN is a direct alternative to a traditional storage array, delivering shared storage and similar data services. Server SAN differs from a hyperconverged system in that the compute and storage functions are segregated. his means that the storage and compute functions are separate to one another and can be scaled independently. However, this configuration requires more servers to deliver (application VMs do not run on the Server SAN – only storage functions.

Due to its similarity to older storage systems, the configuration fits well in environments where traditional storage was prevalent, including data centres, SMEs and environments that have non-virtualized workloads but require high availability and shared storage.

SvSAN can be deployed to fit either of these systems. Keep and eye out for part two of this blog to see how you could upgrade your virtual storage to SvSAN, or download our whitepaper, the full technical overview of SvSAN 6.2.

Share This Post, Choose Your Platform!

Recent Blog Posts
Go to Top