A hyperconverged system allows the integrated technologies to be managed as a single system through a common toolset. Most hyperconverged systems require a minimum of three hardware nodes for high availability and can be expanded through the addition of nodes to the base unit. A grouping of nodes is known as a cluster.
To fully understand how hyperconvergence works, you need to create a mock-up design of your own environment to have a more realistic idea. You must start by asking yourself some basic questions:
- How much compute power do I need (CPU and memory for VMs)?
- How much usable storage capacity do I need in total (across the HCI cluster)?
- How many replicas of my data do I want actively available (for high availability)?
- Do I need to spread the data across two separate data centers for greater redundancy (metro-cluster)?
- How many hypervisor flavors do I have (ESXi, Hyper-V, XenServer, etc.)?
Based on your answers, you will need to do some basic math to figure out the hardware specs for each node in your HCI cluster. You can also contact our HCI technical experts to help you make these calculations to build out the exact hardware specs per node.
Once you determine your hardware requirements, your next step is to figure out how many nodes will be required to keep your VMs running around the clock, even if there is an unexpected disaster and you lose a few nodes. The number of nodes that can fail within a cluster varies across different HCI vendors.
Each node will need a hypervisor installed and configured. Next step is to also configure the internal networks for VM traffic, storage I/O traffic and VM management. The best practice is to separate all the different types of traffic and not try to push them through one or two network links. It will simply get oversaturated at some point and will cause major latencies.
If you are buying a hyperconverged appliance, it will likely come pre-installed with virtual SAN controllers on each node, which controls the local storage and handles the I/O traffic using the internal virtual network paths. Each virtual SAN controller is essentially a regular VM running in your hypervisor, and it manages the local node hardware resources.
This virtual SAN controller also executes all storage-level functionalities such as auto-tiering, I/O caching, thin provisioning, snapshots, deduplication, erasure coding, QoS, data migrations, synchronous mirroring, and asynchronous replication. This is in addition to cloud integrations and data protection checkpoints for your tier-1 databases.
Normally, there is a single management console that connects to all nodes in the cluster and allows you to manage every virtual SAN controller. This makes it easier to execute daily tasks from one window instead of needing to log in to multiple SAN environments.
If you were to go with the software-only approach, you will need to verify your existing servers can meet the minimum requirements before you install the software on such hosts. Hyperconverged software is a flavor of SDS (software-defined storage), and it needs the proper hardware to maximize the benefits it provides.