We are a small manufacturing company with about 50 workstations, and I am the only IT person. We currently run one Lenovo ThinkSystem SR650 with a Xeon Silver 4210R, 32 GB RAM, and a VM datastore made up of two 2.4 TB 10K SAS disks in RAID1. The datastore is already about 94% full. The server also has a separate RAID1 SSD boot/local pool, a hardware RAID controller, and no 10GbE adapter yet. Our switch has 10GbE SFP+ uplinks.
The current VMs include domain services, monitoring, several internal web applications, a UniFi controller, GLPI, and an API gateway. CPU usage is below 5% and actual memory usage is around 17 GB, although nearly all available vCPU and RAM are allocated. An internal ERP with a MySQL database is planned. Veeam runs on a separate machine, and backups are stored offsite, so backup infrastructure is not part of this storage decision.
I have a total budget of roughly R$100,000, or about US$19,400, for a second node and either local disks or shared storage. Import costs make enterprise hardware particularly expensive here.
The first option is two full nodes with local ZFS storage and Proxmox replication. The new node would have two SSDs and three 3.2 TB SAS disks, while the existing node would receive more RAM and an HBA to replace its hardware RAID controller. The nodes would replicate over a direct 10GbE connection, with a QDevice for quorum. This gives each node its own copy and local disk latency, but asynchronous replication could lose up to the replication interval of changes during a failover.
The second option is a business-class NAS connected to both nodes over 10GbE. The new node would use SSDs only for the hypervisor, and both hosts would place their VM disks on the NAS. This would provide shared storage, live migration, and no replication gap, while avoiding the HBA replacement and a new ZFS design. The downside is that one NAS and its controllers would become a major dependency for the entire virtual environment.
How capable does the NAS need to be for this workload? Is a small ERP MySQL database likely to expose problems with network-backed storage, or would it be acceptable at this scale? Would you use iSCSI with LVM-thin or NFS with qcow2, and what tradeoffs matter in production? Is avoiding the HBA and ZFS work a genuine advantage, or just exchanging one manageable problem for a larger failure domain? If using local storage, are three SAS disks reasonable for VM workloads, or should the VM pool be all SSD with spinning disks reserved for archives? Given the budget and the fact that downtime matters more than data loss because backups are separate, which design would you choose?
5 Answers
A third option is a small three-node hyperconverged cluster using something such as Ceph, which avoids making a separate NAS the single point of failure. However, Ceph is not automatically the best answer here. It needs three suitable nodes, fast networking, enough disks and RAM, and ongoing operational knowledge. For one administrator and a modest workload, it may add more complexity than it removes unless the hardware and support plan are very solid.
Before spending on storage, fill the existing server's memory properly. Running 32 GB in one DIMM leaves a lot of performance and capacity on the table, and RAM is likely the cheapest upgrade in the entire plan. Add 10GbE to both hosts as well.
With this budget, I would lean toward two hosts with local ZFS and scheduled Proxmox replication, plus a small always-on third device providing quorum. The replication gap is a known and bounded risk, while a shared NAS creates one failure domain for all running VMs. Since Veeam already provides independent backups, local replication is mainly about reducing downtime rather than protecting the only copy of the data.
A business NAS can absolutely handle a small two-node environment, especially when the current workload is light and the existing VM storage is only two 10K disks. I would not buy a consumer desktop NAS, though. Look for a rackmount business or entry-level enterprise unit with redundant power supplies, dual controllers or at least a well-supported redundant design, enterprise SSDs or a properly tiered pool, snapshots, monitoring, spare-drive availability in Brazil, and multiple 10GbE paths. The support and replacement situation may matter more than the headline IOPS.
The important catch is that the NAS becomes the single storage dependency for every VM. RAID and redundant components reduce the chance of failure, but they do not eliminate controller, firmware, filesystem, or replacement-delay risk. Make sure the VMs can be restored onto local storage if the NAS is unavailable, and test that process.
For this workload, the network database concern is probably being overstated. A MySQL VM should be fine over shared storage if the NAS has low latency, fast disks, redundant networking, and a properly configured 10GbE path. Heavy logging, synchronous writes, or a badly designed all-HDD pool would be a different story.
If you choose local storage, three SAS hard drives in a small pool are workable but not ideal for a database-heavy VM datastore. They will be a substantial improvement over the nearly full two-disk RAID1, but random writes and latency will still be much worse than SSDs. I would put the ERP and other latency-sensitive VMs on mirrored enterprise SSDs and use the SAS disks for less demanding VMs, file data, or archives. Keep adequate free space rather than running another pool near full capacity.
For shared storage, NFS is often simpler to operate and integrates cleanly with file-level snapshots, while iSCSI can provide good block performance but adds more complexity around multipath, thin provisioning, and snapshot behavior. Either can work; the NAS implementation, disks, networking, and operational discipline matter more than choosing the theoretically faster protocol.
Do not overlook hosted private infrastructure as a comparison. A reputable provider could spread the capital expense over a year or two and remove the immediate burden of buying an array, maintaining spares, and handling a storage failure alone. It may not be the cheapest long-term option, especially with ongoing bandwidth and licensing costs, but it is worth pricing against the real cost of downtime and support in a small company.
A third quorum device is important with only two nodes. Without it, losing one host can leave the surviving host unable to make safe cluster decisions. It does not need to be another virtualization server; it just needs to be reliable and independent enough to provide the quorum service.