The most common question we hear from companies moving an accounting system, document management or an internal website to the cloud is a simple one: “How much does a server cost?” It is an understandable question, but it is asked too early. Until it is clear what load the system actually generates, the price tells you nothing. A cheap server that freezes on Monday morning for twenty accountants is the most expensive solution of all.
The choice between a virtual server (VPS), a dedicated physical server and a virtualisation cluster is an engineering decision, not a commercial one. It depends on how much processor time, memory and disk operations your applications use at peak, how that demand changes over a month and what downtime means for your business.
In this article we explain how to measure the load before choosing, what CPU, RAM and disk figures in offers really mean, and when each of the three models is the right one.
What CPU, RAM and disk in an offer really mean
In provider offers you see three numbers: processor cores, memory and disk capacity. But behind each of them are more important things that the offer often leaves out.
Processor
A virtual server “core” (vCPU) is almost never a whole physical core. It is a thread of a physical processor shared by several virtual servers. What matters is not so much the number as the guarantee: does the provider reserve processor time, or does it oversell it several times over? For an accounting system with ten users, two or four vCPUs are enough, if they are truly available at peak. If the physical server is overloaded, even eight vCPUs will not help.
Memory
RAM is the parameter whose shortage shows up fastest. When an application runs out of memory, the operating system starts using the disk as a substitute for memory, and everything slows down tenfold. For database servers, memory is the most important resource: the larger the share of the database that fits in RAM, the fewer disk operations are needed.
Disk and why NVMe is not just marketing
Disk capacity is the least important number. The most important is disk speed, measured in input/output operations per second (IOPS) and latency. Three technologies differ here:
- HDD (spinning disks) are suitable for archives and backups, but not for databases.
- SATA SSD is several times faster than HDD and is enough for most file servers and internal websites.
- NVMe SSD connects directly to the processor bus, bypassing the old SATA interface. Latency is counted in microseconds and IOPS in the hundreds of thousands.
An accounting system with a large database, or an ERP or document management system with many small files, runs noticeably faster on NVMe than on SATA SSD, even if the processor and memory are the same. In our experience it is the disk change, rather than adding cores, that most often resolves “slow server” complaints.
How to measure the load before choosing
If the system is already running in your office or at another provider, you have the best possible data source: the system itself. There is no need to guess.
We recommend collecting metrics for at least two weeks, so that the sample includes month-end closing, payroll calculation or other peaks. On Windows servers Performance Monitor does this, on Linux the standard system tools. The important metrics:
- CPU utilisation: the average and the 95th percentile. If utilisation constantly exceeds 80 percent at peak, you are short of cores.
- Memory usage and swap activity. Any sustained swap use means there is too little RAM.
- Disk queue length and latency. If the disk queue is constantly above two operations and latency exceeds 20 milliseconds, the disk is the bottleneck.
- Network traffic at peak, especially if users connect remotely.
Compare the result not with the average but with the peak plus headroom. A server that is enough for the average load will be too small exactly when it is needed most.
If the system is new and there is nothing to measure, start from the software vendor’s recommendations and choose a model in which resources are easy to change. This is one of the strongest arguments for a virtual server at the start.
When a virtual server is enough
A virtual server suits most systems of small and mid-sized companies: accounting, document management, CRM, internal websites and file servers for up to a few dozen users. Its advantages:
- Resources can be changed in hours, not weeks. Short on memory? It is added without a migration.
- You pay only for what you need now, not for a physical machine with three years of headroom.
- The virtualisation platform handles hardware failures itself: when a physical server fails, the virtual one moves to another.
Managed CLOUD servers add updates, monitoring, backups and Bitdefender GravityZone protection to this, so the company does not need its own server administrator.
A virtual server is not suitable when an application requires a whole physical processor without sharing, special hardware (for example, licensing dongles or a GPU), or when licence terms are counted by physical cores and virtualisation makes them more expensive.
When you need a dedicated server
A dedicated server is a physical machine used by you alone. It makes sense in three cases:
- Constant, high load. If a system uses a lot of processor and disk around the clock, the virtualisation layer and shared resources become a hindrance rather than an advantage.
- Large databases with strict latency requirements. A dedicated NVMe array without neighbours gives predictable speed.
- Licensing or compliance requirements. Some software licences or internal security policies require that the physical hardware is not shared with other customers.
The drawbacks are just as clear: changing resources means changing hardware, a hardware failure without a cluster means downtime, and you always pay for unused capacity. A dedicated server without professional server management is a risk, not an investment.
When a VMware cluster is worth it
Between these two options there is a third, often the best one for mid-sized and larger companies: a virtualisation cluster. VMware cloud servers run on several physical servers joined into one whole with shared storage.
It provides what neither a simple VPS nor a single dedicated server can:
- High availability. When a physical node fails, the virtual servers restart automatically on another node within minutes, with no human intervention.
- Reserved resources. You can guarantee a specific server processor time and memory, as with a dedicated one, while keeping the flexibility of virtualisation.
- Multi-server environments. When you have separate application, database, terminal and test servers, a cluster lets you manage them as one system.
A cluster makes sense when you have several servers, or one whose downtime during the working day is unacceptable. For a single small accounting server it would be oversized.
| Criterion | Virtual server | Dedicated server | VMware cluster |
|---|---|---|---|
| Changing resources | Hours | Days or weeks | Hours |
| Protection against hardware failure | At platform level | None without a spare | Automatic failover |
| Guaranteed resources | Depends on the provider | Always | As configured |
| Suitable for | Up to a few dozen users | Constantly high load | Multi-server environments |
Scaling: plan for growth, not for the start
The main mistake in choosing is to size a server for today’s load and forget what happens in a year. In a virtual environment this is not a problem: you start with the measured need plus headroom and add resources as you grow. In a dedicated environment you have to plan for growth right away or accept a migration.
A tip from our practice: choose the model by how often your needs will change. If you do not know, choose virtual and measure. Moving from a virtual server to a dedicated one or a cluster after six months, with real data, is far cheaper than guessing at the start.
Where to start
- For two weeks, collect processor, memory and disk metrics from your current system, including a month end.
- Identify the peak and add at least 30 percent headroom. That is your starting resource requirement.
- Estimate what an hour of downtime costs your business. If it is a lot, consider a cluster rather than a single server.
- Check the software licence terms for virtualisation.
- Discuss the results with a provider that offers all three models, not just one. We help measure the load, choose the right solution and, after the migration, maintain it under an agreed service level.
