6 Hyperconverged Architectures: Different Solutions for Different Needs

A small and brief introduction into StarWind: we’ve been a software-defined storage company since 2003, when we released our first product – StarWind iSCSI SAN – and since that moment we had a long way of evolution from just a software SAN into the first hyperconverged storage offer, which is StarWind Virtual SAN. Last year, at the beginning of spring, we shifted focus from just selling and offering software to providing turnkey hardware solution – StarWind HyperConverged Appliance.

The idea is pretty simple. We all know that hyperconverged infrastructure is essentially hardware combined with software and configured properly. The biggest question is what is the right hardware, what is the right software and how to configure it properly. We try to answer all those questions for our customers and deliver pre-configured turnkey solution with the hypervisor of their choice. Essentially, we provide an easy way for people to build their IT environment either from scratch or expand their existing IT environment with unified building blocks which easily fit into the infrastructure.

We take best-of-breed components for our appliance. We currently use Dell servers, Intel solid-state storage, and networking from Mellanox. StarWind handles software storage management part. Then, it’s either Microsoft or VMware acting as the hypervisor. We have Veeam Backup to cover disaster recovery and business continuity, and 5nine Manager offering unified management for Hyper-V. In case of vSphere, we use standard vCenter console, as this is a preferred method of managing VMware.

The whole idea we bring with the HyperConverged Appliance is to move away from the traditional low-end expensive infrastructure. Lots of companies, especially SMB and ROBO, need highly available and reliable infrastructure. This is because SMB just start their way and cannot allow failure, and ROBO are usually the locations of businesses that meet the customers. For example, there is a huge company doing car rental, and if it has a problem or outage in the main office, customers will not be able to rent a car because the system is broken, so that will be a huge problem for the company. We tend to solve that problem by delivering small but really dense configurations, which are highly reliable and configured for maximum availability. And again, this is possible to do with just two servers, and we try to move away from the concept that where we use a SAN we need switches, we need all that infrastructure to support our applications. In case of StarWind HyperConverged Appliance we need only two servers and no dedicated switching to have a fully highly available and redundant infrastructure.

Though only 2 nodes are needed to start, the system allows scale-out. In general, there are two ways to scale: scale-out and scale-up. Scale-out is adding ready nodes or different models to the configuration. Scale-up is really unique to the appliance’s model configurations, especially when we’re talking about hardware and have not recommended a hardware list. We do allow customers to upgrade their individual appliances by adding more recourses, like network cards, disks, RAM or even change the CPUs.

To imagine a starter kit, a standard configuration of StarWind Large-Short is a one-unit server, two 6-core CPUs, 64GB RAM, 4 NL SAS hard drives and 2 SSDs. It’s very easy to upgrade it, you can just add CPUs, it can be RAM or hard drives. To illustrate the scale-out, you can start with 2 nodes, then easily add 2 more nodes to that configuration, and you can also upgrade resources of individual appliances. You can add more storage to them and spin up a file server there or have some storage connected to those nodes. And, of course, this is possible to do for every node in the cluster, so you can upgrade individual resources as well as storage for the entire cluster.

There is no lock-in to the model, like when you buy 2 or 3 or 4 servers, and every extra GB of RAM or every extra GB of storage costs you an additional appliance. This is something we’re trying to prevent in our model, and that’s why we allow customizing the appliance.

The whole storage redundancy and reliability in the HyperConverged Appliance are delivered by StarWind Virtual SAN. The role of StarWind is to mirror the whole storage of the servers, as well as their RAM, which is used for live caching, and then present it to the same servers (in our case it can be all nodes of this cluster) as a single highly available storage resource. This is then recognized by the cluster as the preferred cluster storage and this is where all of your applications are launched. So, by default all applications running on StarWind HyperConverged Appliance are highly available, and whenever a third, fourth or any other node is added, it automatically gets access to that initial storage and you get more storage in the added nodes as well.

The hypervisors we support are vSphere and Hyper-V. With vSphere it is really easy to get unified management, as vCenter console is currently the default tool for managing vSphere, and there is no alternative there. For Hyper-V, there are lots of ways to go: you can either work with the Hyper-V Failover Cluster Manager for really small deployments, or with the System Center Virtual Machine Manager for bigger environments.

But for some environments having a dedicated machine running system center to manage an infrastructure can be a bit an overkill. It’s a great set of tools, but not everyone uses it. Therefore, we decided to go with an intermediate model and allow people who want to use Hyper-V virtualization to have a single pane of glass management console. And for that we employ 5nine manager. We work together with 5nine to add StarWind management of storage and Veeam backup into the management console, and thus customers can manage all of their resources in one place without resorting to go to different consoles for different functions. 5nine also did a really good job of doing it closer to vSphere look in the Hyper-V management, so the console is centralized, really easy to operate and it’s really the case where instead of looking for manuals or how-to guides you just look at the thing and you already know how to operate it.

The management console is Veeam integrated. Veeam is currently one of the industry-standard backup tools. It also provides additional features like monitoring and disaster recovery replication. Veeam controls are integrated into the management allowing you to see the status of your protected virtual machines, run jobs and also get job alerts for the virtual machines. Thus, your whole backup infrastructure is monitored and configured from one place.

StarWind storage management is also embedded in the management console, where you can look at the IOPS, your current bandwidth, your deduplication statistics, uplink errors, anything you need at the storage level. That also provides the reporting for your storage, so it’s really easy to stay tuned and on the same page with your infrastructure. Should anything happen, you’ll get notifications about every component in one place.

Hyperconvergence for us is a way to deliver better service and provide better performance for the applications running on the HyperConverged Appliance. We just work with the local storage and local RAM used as write caching and thereby eliminate any bottlenecks, which typically appear in the traditional SAN model. So instead of writing the data all the way down through the storage infrastructure and to the SAN, with StarWind Appliance your application writes the data to the local RAM, where StarWind intercepts that and puts it on the local storage. Thus, that’s the fastest possible route. The only way to make it faster is not to replicate it to the second StarWind Appliance for high availability, which is critical because as we move to flash storage, latency becomes a huge issue, and working with local resources is the preferred way to operate rather than building a dedicated storage resource.

StarWind HyperConverged Appliance also supports additional protocols. By default, we operate iSCSI and direct memory access protocols, but we also support SMB3, NFS and we are rolling out VVOLs on iSCSI shortly and few other technologies – later this year you’ll see NVMe over Fabrics capabilities and iSER which is iSCSI extension for RDMA coming soon. iSER is something which will allow StarWind to get one step closer to latency and performance of the local NVMe with all the benefits of hyperconverged infrastructure and redundant infrastructure. So, you basically have your data highly available, and at that point even fault-tolerance, performance and latency would still be like ones of the local storage.

Talking about server-side cache, we’re one of the few companies who employ a local RAM as write cache, and to keep that volatile resource resilient and fault-tolerant we replicate the RAM cache between the boxes. So, every block is confirmed written only after it has been synchronized with the partner nodes of the appliance.

Our primary focus is fault-tolerance and high availability, so by default all the data and caches are mirrored between the appliances participating in the cluster. On top of that, customers really need to have a solution for disaster recovery and business continuity, so we also offer asynchronous replication to DR or to Public Cloud and the replication is available on a per-virtual machine or a per-volume basis, so you can have your VMs replicated to a building cross the street or you can have your whole database also replicated, let’s say, to Azure and there Azure will make a job of keeping it geographically separated, let’s say, between East Coast and West Coast. So, if something really-really bad happens, your data will be safe.

Snapshots and Automated Storage Tiering are storage-centric features. However, storage is a key to a good application performance, so we try to keep our HyperConverged Appliance as fast as possible without packing too much storage into it and keeping it rational. What we do is we pinpoint the primary data to flash and then we have additional node where you can offload all the cold data like write log, snapshots and backups. So, it’s not necessary to keep that cold data on the primary node, it can be completely offloaded from it, not even kept on the cold storage on the primary nodes, but just loaded to a whole different server. This allows us to build an infrastructure where we have all-flash nodes running along with accelerated cold storage nodes. Our virtual machines and applications always work with flash, but we still have that luxury of keeping unlimited snapshots and having our backups in place without doing a huge tiered infrastructure and impact our production with tiering, performance, and implications.

A big thing which differentiates StarWind HyperConverged Appliance from do-it-yourself kits or even reference architectures is our approach to support. Lots of companies who try to build a multivendor environment have a huge issue because they need to contact multiple companies for support. What we try to do is to aggregate support contracts on our end, and if customer has any issue, be it a hardware problem, a software problem or a hypervisor problem, they contact StarWind (we’ve got a 24/7 call center available for that), and we solve all their issues. Should there be any vendor finger-pointing, you will never see it, because it happens behind the scenes or, in our case, we just employ direct contact at hypervisor and hardware vendor companies, so there is no finger-pointing and problems are solved fast and easy.

The smallest configuration we provide is for the companies who do not even need a rack or who do not have a rack. It consists of two servers, which provide enough horsepower to bring up to 40 VDIs. They already have beyond E5 26 series CPUs and up to 128 GB of RAM. And on top of that there is hybrid storage with 4 to 6 TB of usable capacity.

The two one-unit servers are Large model. This is the typical scale-out box, which starts with just 2 6-core CPUs and the top configuration for the Large model has 2 10-core CPUs, 256 GB of RAM and about 5 TB of usable hybrid space.

The X-Large – the two two-unit servers are more dense deployment where you can have up to 22 TB of highly available hybrid space in just 4-unit footprints along with maximum CPU horsepower of 32 cores per cluster.

And we also have the Ultra model which currently employs the maximum possible Intel CPU configuration, and the storage is mixed of NVMe and standard SSD to deliver maximum possible performance. These two boxes also employ Mellanox 100GbE networking backbone to deliver maximum possible performance and they’re currently in benchmarks, but we already managed to squeeze about 1.5 mln IOPS out of that configuration, and we’re working on making that result better.

All of our models are available with hybrid storage, but there is also a way to purchase them in all-flash configurations. With some environments, you cannot predict how your load will grow or there is no way to work with hybrid and consistent performance is needed all the time, so there is always a way to purchase the configuration in all-flash.