A plain explanation of what hyperconverged infrastructure is, when it is the right call, when it is not, and where the money goes. Written by the managed service provider who would run it, not a vendor selling nodes.
If your SAN is coming out of warranty and somebody has suggested hyperconverged, this is the conversation we would have anyway.
Traditional server infrastructure is three separate purchases. Servers for compute. A SAN or NAS for storage. Switching to connect the two. Each has its own warranty, firmware, support contract and usually its own specialist.
Hyperconverged collapses those into one thing. You buy nodes: ordinary servers with their own local disks. Software pools those disks across every node into shared storage and runs the virtual machines on top. Add a node and you add compute and storage together. No separate array to buy, cable, zone or patch.
That is the whole idea. Everything else is detail sitting on top of a fairly simple change in how the parts are arranged.
Compute, storage and the software that manages both arrive on the same node. No storage array behind its own fabric, and no separate skill set to look after it.
Running short? Add a node. Growth becomes a predictable line item rather than a redesign, which is the part finance cares about.
When performance is bad there is one vendor to call, rather than a three-way argument between the server, storage and switch suppliers.
Hyperconverged answers a specific set of conditions well and others badly. The second list is the more useful one.
We would rather talk you out of a cluster now than sell you one you have to live with for five years. If the honest answer is a new host and better backups, that is what the report will say.
We are not going to put a price on this page: it moves with node count, disk type, licensing edition and redundancy. What is worth knowing is where the money goes, and which parts catch people out.
| Where the money goes | What to expect |
|---|---|
| Nodes | Priced per node, and clusters usually start at three. The third node is there for quorum and resilience rather than capacity, which surprises most people. |
| Platform licensing | Licensed per node, socket or core depending on the vendor, and renewed annually. Over five years it often adds up to more than the hardware. |
| Operating systems | Windows Server and SQL Server licensing follow their own rules and sit outside the platform licence. Easy to under-count when comparing quotes. |
| Networking | Storage traffic now runs across the network, so nodes need fast switching between them. If your switches are 1GbE, budget for replacing them. |
| Implementation | Design, build, migration of the existing virtual machines, and the cutover. Normally a fixed-price project rather than hourly. |
| Running it | Vendor support renewal, plus whoever monitors, patches and capacity-plans it. Under a managed agreement this is a monthly line. |
| The refresh | Nodes come off support after roughly five years. Because the cluster is built from matched nodes, the refresh arrives as one event rather than a trickle. |
The hardware quote is the smaller half. Licensing and the refresh are where the long-term commitment sits, and they are the two numbers worth arguing about before you sign.
Hyperconverged is one of four reasonable answers to the same problem. We price it against the other three rather than assuming it wins.
If you run one or two hosts and the only real issue is that they are old, replacing them like for like is often the cheapest correct answer. Same design, newer hardware, no extra platform licensing.
For file, email and most line-of-business applications, cloud removes the hardware question entirely. It suits small estates and variable demand, and heavy constant storage-hungry workloads less well. The bill never stops, so compare over five years.
Sometimes the real problem is that people need the same desktop from the office, from home and from a client site. That is a session problem, not a storage problem. Hosted Citrix and remote desktop may answer it for less than a cluster would.
Often the worry underneath the question is what happens if this dies. That is a backup and recovery question, and it is far cheaper to answer directly than by rebuilding the platform. Cloud backup and disaster recovery is usually where we would start.
We are a managed service provider in Ontario. We do not manufacture hyperconverged systems and are not tied to one platform, so we have no reason to talk you into it.
Our part is the unglamorous part. We size the cluster against what you actually run rather than what the sizing tool suggests, get competing quotes, place the order, build it, migrate the virtual machines and run the cutover, scheduled around your tolerance for downtime with a documented way back.
After that it goes under a managed agreement: monitoring, firmware and patching, capacity reporting so you see the next node coming before it is urgent, and the support renewals tracked so nothing lapses quietly. Our engineers hold ITIL certification, and the company holds a SOC 2 Type 2 attestation, which tends to matter when your own customers or insurers ask how your provider is controlled.
What we will not do is present hyperconverged as the answer to a question you did not ask. If the assessment says a host refresh, or cloud, or simply better backups, that is what we will put in writing.
The questions we are actually asked, rather than the ones brochures answer.
The simplest is a three-node cluster from one vendor, bought as a pre-validated appliance, with the storage software and hypervisor from that same vendor, so there is one number to call. Simplicity comes from reducing the number of parties involved, not from the feature list. For a single-site company with a modest number of users, the simplest option is often not hyperconverged at all: two well-specified hosts with replication, or cloud.
Three entry-level nodes, the vendor's lowest licensing tier, standard rather than premium support, and reusing your switching if it is fast enough. That is the floor, and it is still a real capital purchase. If price is the deciding factor, hyperconverged is usually the wrong answer: what it buys is resilience and predictable expansion, and those are the expensive parts. The cheaper routes are refreshing one host and spending the difference on backup, or moving to cloud.
Some platforms support a two-node configuration with a witness elsewhere, and it is a legitimate design for a small or branch site. It is not usually cheaper per unit of capacity, and it narrows what you can do later. Ask what the path to three nodes looks like before committing.
No. Replication between nodes protects you from a node failing. It does not protect you from ransomware, a deleted file or a bad change, because all three replicate happily. Backup stays separate, and should live somewhere the cluster cannot reach.
Virtual machines move to the new cluster in batches, and each one is down only while it moves. Hardware lead time is usually the longest part of the project rather than the technical work. You get a dated plan, and the rollback, before anything is ordered.
Send us the shape of the current environment: how many hosts, roughly how much storage, how old, and what prompted the question. We will come back with what we would actually do, including the version where you buy nothing.
We reply within one business day. If hyperconverged is the wrong answer for your situation, that is what we will tell you.
We respect your privacy. We will not send you marketing you did not ask for.
%20(1).avif){kind=logo}
%201.avif)
