Why Proxmox VE Ceph storage design is harder than it looks
Hyper-converged Ceph on Proxmox VE places storage, networking, HA and guest workloads on the same hardware, so node count, disk layout and network separation have to be decided together rather than one after another. Teams that want shared VM storage for live migration and HA, without buying an external SAN or NAS, usually reach this design. The attraction is real, but the same nodes that run guests also absorb replication traffic, rebuild load and failover, and a choice that looks minor on one component can limit the others. The design is harder than a single-host ZFS setup for three reasons. First, failure domains multiply: a single node failure removes both compute and a share of storage at once, so you must decide how many nodes and disks can fail before data availability or guest recovery is at risk. Second, rebuild traffic competes with guest traffic on the same links after a disk or node loss, which makes network separation and sustained recovery throughput design inputs, not afterthoughts. Third, quorum governs both the cluster and the storage layer, so an even split of nodes or a weak witness arrangement can stop writes or stall failover.
Proxmox VE high availability sets its own floor. The HA documentation calls for at least three cluster nodes for reliable quorum, shared storage that every node can reach for guests, redundant hardware, and watchdog-based fencing so that a failed node is reset before its guests are restarted elsewhere. Ceph does not remove any of these requirements. A three-node cluster that meets the HA minimum is not automatically a well-sized Ceph cluster, and a Ceph cluster with more nodes does not automatically give you HA if fencing or quorum is misconfigured. Before you commit to this model, confirm the following with your own hardware and vendor documentation: how many nodes you can lose and still keep quorum and data available, whether your network can carry replication and client traffic at the same time during a rebuild, whether your disks and controllers are supported for the Ceph version you intend to run, and how you will watch for slow or failing OSDs. These questions shape the effort and the risk of the project more than the hypervisor installation does.
Which Proxmox VE and Ceph components the design touches
A hyper-converged Ceph design on Proxmox VE depends on several layers that must agree: cluster management, shared VM storage, HA fencing, local boot storage and an independent backup target. Each card below names one layer, what it means for the design, and what to confirm in the current Proxmox VE and Ceph documentation before sizing hardware.
Proxmox VE cluster and cluster file system
A Proxmox VE cluster uses a multi-master design, so every node can perform management tasks, and the Proxmox Cluster File System replicates configuration to all nodes in real time. For Ceph storage, this means the cluster membership and quorum rules shape how many nodes must stay up before storage and guests remain manageable. Confirm the node count, corosync network requirements and quorum behavior for your planned topology in the current Proxmox VE administration guide.
Ceph RBD for VM disks
Ceph RADOS Block Device (RBD) storage is the usual shared backing for VM disks in a hyper-converged design, so every guest disk write crosses the storage network and lands on replicated OSDs. Replication factor, pool layout, minimum replica settings and the number of OSDs per node determine usable capacity and how the cluster behaves when a disk or node fails. Confirm pool replication and recovery settings in the current Ceph and Proxmox VE documentation before fixing node counts.
CephFS for shared files
CephFS provides a shared POSIX file system for content such as ISO images, templates or shared application files, and it is a separate Ceph service from the RBD pools used for VM disks. It needs metadata servers and its own pools, so it adds components to size and monitor. Decide whether the design needs CephFS at all, and confirm metadata server placement and the Proxmox VE storage definition for CephFS in the current documentation.
HA manager and watchdog fencing
The Proxmox VE HA manager restarts guests from a failed node on healthy nodes, but only after watchdog-based fencing resets the failed node so it cannot keep writing to shared storage. The HA wiki calls for at least three cluster nodes for reliable quorum, shared storage for guests and redundant hardware. Check that the watchdog hardware or software option is active on every node, and test fencing before relying on automatic recovery.
Local storage for boot and non-Ceph data
Proxmox VE supports local storage on LVM, directories and ZFS, which the design can use for the boot disks, the system installation and any data that should stay off the Ceph cluster. Keeping boot and local data separate from Ceph OSD disks prevents a storage fault in one layer from taking down the other. Confirm which disks are dedicated to Ceph, how the installer lays out the system disks, and whether ZFS memory and disk requirements fit the node specification.
Proxmox Backup Server as a separate target
Ceph replication protects against disk and node failure but is not a backup, because a deleted or corrupted VM disk is replicated too. Proxmox Backup Server gives the design a separate backup target with incremental backups, deduplication and encryption, so at least one copy of guest data sits outside the Ceph pools. Confirm the backup server placement, retention settings, network path and restore testing procedure in the current documentation.
Proxmox VE Ceph storage design choices and their trade-offs
This table compares the main Ceph design decisions for a Proxmox VE cluster and the operational cost of each option. Read each row for when an option fits and what it costs in rebuild impact, upgrades, blast radius, hardware and support entitlement. Confirm replica and pool values in the Ceph documentation before you size capacity, because they drive raw disk spend and recovery time.
| Decision | When it fits | Operational cost |
|---|---|---|
| Hyper-converged Ceph or a separate Ceph cluster | Hyper-converged: one platform with fewer nodes. Separate cluster: storage scales or is shared independently of compute. | Hyper-converged: recovery load shares node CPU, RAM and disks with guests. Separate: extra hardware, networking and a second upgrade plan. |
| Ceph RBD only or adding CephFS | RBD alone covers VM disks, the common Proxmox VE case. Add CephFS only when workloads need a shared file namespace. | CephFS adds metadata services to size, monitor and upgrade, plus separate pool and client access planning. |
| One shared network or separate public and cluster networks | A shared network suits small or low-traffic builds. Separate networks suit clusters with heavy replication and recovery traffic. | Separate networks need more NICs, switch ports and addressing. A shared link means rebuild traffic can slow guest traffic. |
| Bonded uplinks or single links | Bonds fit production nodes where a single link failure must not isolate storage or guest traffic. | Bonds need matching switch configuration and monitoring. Single links are simpler, but a link fault cuts off that node's storage path. |
| Node count beyond the HA minimum | Three nodes is the documented HA minimum for quorum. Extra nodes fit when losing one node must not reduce capacity. | Each node adds hardware, Ceph recovery to coordinate during maintenance, and a per-socket subscription cost where subscriptions apply. |
| Enterprise repository or no-subscription repository | Enterprise repository fits production. No-subscription repository suits testing and non-production use, per Proxmox package repository guidance. | Enterprise access requires a valid subscription key billed per CPU socket per year. Support tiers differ, and the Community tier includes no tickets. |
| Replication size and pool settings | Confirm replica count and minimum replicas per pool in the Ceph documentation before sizing usable capacity. | Higher replica counts raise raw disk spend and rebuild time. Check failure-domain settings against your actual node and disk layout. |
How many nodes, disks and networks the cluster needs
Size a hyper-converged Ceph cluster from the failures it must survive, not from the capacity it must hold. Capacity tells you how much usable space you need, but the node count, disk layout and network design decide whether a single host failure leaves your virtual machines running, degraded or down. Start by writing down the outcome you want: how many node failures the cluster should absorb while guests keep running, how long a rebuild may take, and how much performance loss is acceptable during recovery. Those answers drive every count that follows. Proxmox VE high availability needs at least three cluster nodes for reliable quorum. With two nodes, losing one leaves the survivor unable to prove it holds the majority, so the cluster cannot safely decide which guests may restart elsewhere. Three is therefore the floor for HA, not the recommended design for shared Ceph storage. Each node also needs watchdog-based fencing, redundant hardware and access to the same shared storage, so confirm that your chosen hardware supports a working watchdog before you order it. A three-node hyper-converged cluster leaves little room for node loss during rebuilds. When one node fails, Ceph must re-create the copies it held on the two survivors, and the surviving nodes also carry their own guests and the recovery traffic. Plan for the cluster to run with one node missing, with enough free capacity and CPU headroom on each remaining host to absorb the load. Ask your hardware vendor and Ceph sizing guidance to confirm how much free space and throughput the rebuild requires for your replication factor. Spread disks evenly across nodes so no single host holds a disproportionate share of data. Use the same number and class of OSD disks in each node where you can. Uneven disks or an extra-large node concentrate placement and rebuild work on a few devices, and the cluster is only as balanced as its fullest host. Separate management, guest and Ceph traffic onto distinct networks to reduce contention. Management traffic stays responsive during storage activity, guest traffic is not starved by replication, and Ceph public and cluster networks carry client I/O and replication separately. Dedicated Ceph replication links with adequate bandwidth matter most during rebuilds. Illustrative layout only: three nodes, each with the same set of OSD disks, one management interface, one guest bridge, and separate Ceph public and cluster interfaces. Confirm the exact disk count, network speed and replication settings against Ceph sizing guidance and your hardware vendor's specifications for your workload before purchase.
Proxmox VE Ceph storage design build steps in order
This sequence takes a Proxmox VE cluster from matched hardware to a hyper-converged Ceph storage pool that supports HA failover and backups. Each step closes with an observable check, so the team knows when to move on. The order matters because each later step depends on the earlier ones being verified.
Confirm hardware and firmware consistency across nodes
The infrastructure engineer compares every node's CPU model, memory size, network adapters, HBA and disk controller models, and BIOS and firmware versions against a written baseline. Mismatches are resolved before the cluster is formed, because uneven nodes cause uneven Ceph performance and surprises during failover. The step closes when a side-by-side inventory export shows matching models and firmware for each node role, and every node runs the same Proxmox VE version.
Configure bonded networks for management, guest and Ceph traffic
The network engineer creates separate bonds or VLAN-tagged interfaces for cluster management, guest traffic, and the Ceph public and cluster networks. The bonding mode and switch configuration follow the vendor documentation for the chosen aggregation method. Ceph replication traffic should run on links separate from guest traffic wherever the hardware allows it. The step closes when every bond shows all members active on every node, the switch side reports matching aggregation, and each node reaches every other node on every network.
Validate MTU and latency end to end before installing Ceph
If jumbo frames are used on the Ceph network, the engineer sets the same MTU on every node interface, every switch port, and any intermediate device. Then they send non-fragmenting pings at that packet size between every pair of nodes. Latency is measured on the same paths and recorded as a baseline for later comparison. The step closes when every node pair passes the large non-fragmenting test with no drops, and the latency results are within a similar range across all paths. Any failing path is fixed before Ceph is installed.
Deploy Ceph monitors and managers across at least three nodes
The platform engineer installs Ceph on each node through the Proxmox VE interface or command line, then creates monitors on at least three nodes so quorum survives the loss of one node. Standby managers are added on additional nodes where the design calls for them. The step closes when the cluster status shows all monitors in quorum, at least one active manager with standbys listed, and a health state of OK or only warnings that the team has reviewed and accepted.
Add OSDs with a consistent disk layout
Each node receives the same count and class of OSD devices, built with the same layout, such as one OSD per drive. If separate devices are used for database or write-ahead log placement, the placement is identical on every node. The engineer adds OSDs in small batches and waits for data to rebalance between batches to keep client load manageable. The step closes when every OSD reports up and in, the per-node OSD counts match the design, and the cluster returns to a healthy state after the final batch.
Create pools, set replica values and register storage
The storage engineer creates replicated pools as specified in the design and sets the size and minimum-replica values according to the Ceph documentation for the chosen replica count. Each pool is enabled for RADOS block device use and then added as Proxmox VE storage, limited to the nodes that should access it. The step closes when pools report active and clean placement groups, the storage entries show available capacity on every node, and a test virtual disk can be created and removed without errors.
Enable HA with watchdog fencing and test failover
The cluster engineer enables HA for test guests and confirms that every node has a working watchdog, since Proxmox VE relies on watchdog-based fencing so a failed node is reset before its guests restart elsewhere. HA groups are defined with node priorities for each group. During a controlled test, the engineer powers off or isolates one node and observes recovery. The step closes when the test guest restarts on a healthy node, the failed node is fenced, and a live migration of a test guest between the remaining nodes completes successfully.
Configure Proxmox Backup Server for Ceph-backed guests
The backup engineer adds Proxmox Backup Server as backup storage, creates backup jobs for test guests on the Ceph pool, and sets retention and encryption according to the backup design. Restore testing is scheduled as a separate activity. The step closes when a backup job completes successfully, a restored test guest boots and passes a basic functional check, and the backup datastore lists the expected number of snapshots for the test guests.
How the design changes for small, expanded and isolated environments
At the three-node floor, Proxmox VE and Ceph both depend on every node. Three nodes give the cluster the quorum it needs for high availability, but they leave little room to absorb a failure. When one node is lost, the surviving nodes must restore redundancy for the data that node held, while guests restart on the remaining hosts. That rebuild competes with production I/O on the same disks and links, so the central design question is how much headroom the survivors have and how long a degraded state the business can tolerate. Proxmox VE expects at least three nodes for reliable quorum, shared storage for guests and watchdog-based fencing, so the cluster cannot shrink below that floor without losing its high availability guarantees.
Points to design around:
- Rebuild pressure: recovery traffic and guest I/O share the same disks and network paths after a node loss.
- Spare capacity: confirm how full the pools can run before a single node failure leaves the survivors unable to re-create redundancy.
- Disk count per node: with few disks per host, one failed drive can remove a large share of a node's storage.
- Network separation: with few nodes, a shared network path becomes a larger single point of failure, so confirm dedicated replication links.
- Fencing behavior: test that a lost node is reset before its guests start elsewhere.
Confirm the drive count per node, the usable capacity that remains after one node is lost, and whether the business accepts a degraded period while the cluster rebuilds.
Adding nodes and disks changes the problem from surviving a failure to placing data so that a failure stays contained. With more hosts, Ceph can spread replicas across failure domains such as individual disks, hosts, racks or power feeds, and the placement rules decide what a single rack or switch outage can take with it. The gain is more spare capacity and a smaller share of data affected by any one event. The cost is more complexity: the team must define the failure domains, keep hardware in each domain comparable, and avoid placing all replicas behind one power or network path. Rack placement becomes a design input rather than an afterthought, because a cluster that spans racks with shared power or uplinks can look redundant on paper while still failing together.
Points to design around:
- Failure domain map: agree which levels, such as host, rack or room, the replica placement must respect.
- Power and uplinks: confirm that each rack has independent power and that nodes in different domains do not share a single switch.
- Hardware consistency: mixed disk sizes and speeds across nodes can skew data placement and create hot spots.
- Growth path: decide how new nodes join, how data rebalances, and how long that rebalancing runs during business hours.
- Monitoring of placement: verify that health checks report degraded placement, not only failed disks.
Confirm the failure domains with facilities and network owners before hardware is ordered, and ask the team to document which single event each domain is designed to survive.
In an air-gapped or isolated environment, the storage design is shaped as much by software delivery as by hardware. Proxmox VE and its Ceph packages reach each node through Proxmox package repositories. The enterprise repository requires a valid subscription key and is the recommended repository for production, while the no-subscription repository is intended for testing and non-production use. In a restricted network, the team must decide how packages, security updates and subscription validation reach the cluster, and whether that path is acceptable for a production system that must stay patched. Offline updates change the cadence of patching, the testing burden for each package set, and the way the team proves which versions run on which node. Confirm these mechanics with Proxmox and with your own security and change management teams before the design is fixed.
Points to design around:
- Package sourcing: confirm how the enterprise repository is reached, mirrored or transferred into the isolated network.
- Subscription key workflow: confirm how the key is validated and what happens when the cluster cannot reach the validation service.
- Offline update cadence: plan a repeatable process for moving and verifying package sets across all nodes.
- Version consistency: keep Proxmox VE and Ceph package versions matched across hosts, and record them for audit.
- Support access: confirm how support tickets and diagnostic data leave an isolated network, if they must.
Confirm the package transfer path, the subscription validation method and the approval steps for each update with the security owner before procurement of hardware begins.
What drives Proxmox VE Ceph storage design effort and cost
This table lists the main drivers of effort and recurring cost in a Proxmox VE Ceph design, with how each one raises or lowers the work and what to request in a written quote. Read each row as a question to settle before scoping. Node count, disk layout and network design shape most of the build, while subscription tier is a separate recurring line.
| Driver | How it changes effort or cost | How to keep it down | What to request in a quote |
|---|---|---|---|
| Node and socket count | More nodes add OSD hosts, network ports and checks. Subscriptions are priced per CPU socket per year, so sockets set recurring cost. | Size nodes to the failure domain you need. Choose the lowest socket count that meets CPU demand. | Node count, sockets per node, subscription tier, and whether pricing covers every node. |
| Subscription tier | Tiers differ in support, not software. Community 120, Basic 370, Standard 550, Premium 1,100 euros per socket per year (Proxmox pricing page). | Match the tier to your support need. Test the same features in non-production first. | Tier for each socket, billing term, currency, and whether tax is included. |
| Number and type of disks | More OSDs raise build, benchmarking and monitoring work. Mixed models or sizes complicate balance and performance tests. | Standardize drive models per node group. Validate firmware and controller mode early. | Drive count per node, models, capacity, controller type, and the failed-drive replacement plan. |
| Network complexity | Separate Ceph traffic, VM traffic and management VLANs multiply switch, bonding and MTU work. Replication is network heavy. | Document a VLAN and IP plan. Agree on bonding and MTU before racking hardware. | Switch models, port count, bonding mode, MTU, VLAN plan, and who applies switch configuration. |
| Existing data migration onto Ceph | Moving VM disks from LVM, ZFS or other stores adds cutover windows and verification. Data volume and downtime tolerance drive the plan. | Pilot with a few non-critical guests. Keep the source copy until restores are verified. | Source storage types, data volume, acceptable downtime per guest, and the rollback plan. |
| Number of pools and workloads | Each pool needs its own replication, quota and performance checks. Databases and file shares need separate testing. | Create pools only for real isolation or performance needs. Document naming and quotas. | Pool list with purpose, replication setting per pool, and latency or throughput targets per workload. |
| Compliance evidence needs | Assessors may ask for encryption settings, access records, change logs and restore test results. Each item adds collection work. | Agree the evidence list at scoping. Export configurations and logs on a schedule where possible. | Named framework or controls, evidence list, and confirmation that auditors issue the assessment. |
| Backup and monitoring integration | Backups must cover Ceph-backed guests. Monitoring must cover OSD, monitor and network health. Both add integration and test effort. | Choose one backup target early. Use Proxmox Backup Server if deduplication and restore testing are needed. | Backup tool, retention, target storage, restore test frequency, monitoring stack and alert ownership. |
How to secure Ceph traffic, keys and the management plane
A hyper-converged Ceph cluster on Proxmox VE puts storage traffic, administrative access, authentication keys and backup copies on the same hosts, so a weakness in one area exposes the others. The four controls below address the network paths, the people who can change storage, the key material that grants access to data, and the backups that hold a copy of that data.
Separate Ceph networks from user traffic
Ceph uses a public network for client and monitor traffic and a cluster network for replication and recovery between OSDs. Keep both on dedicated interfaces or VLANs, away from guest bridges and the Proxmox VE web and API interface. Check that monitors and OSDs do not listen on management addresses, that the cluster network is not routed to user segments, and that firewall rules allow only the Ceph ports between nodes. Confirm this in the Ceph and Proxmox VE network configuration before go-live, because recovery traffic can saturate a shared link.
Limit who can administer storage
Proxmox VE roles and pools control which users can create, resize or delete Ceph pools, OSDs and storage definitions. Grant storage administration to a small named group rather than to the root account, and use API tokens with narrow privileges for automation. Choose an authentication realm that fits your identity source, such as Linux PAM for local accounts, LDAP or Active Directory, or OpenID Connect, and require a second factor for every account with storage rights. The supported second factors include TOTP, WebAuthn, YubiKey OTP and recovery keys. Review role assignments on a fixed schedule.
Protect Ceph keys and keyrings
Ceph authentication keys and keyrings grant cephx access to monitors, OSDs and clients, so a copied keyring can read or alter pool data without any login to Proxmox VE. Confirm that keyring files on each node are readable only by root and the Ceph service accounts, and that client keyrings used by guests or scripts are scoped to the pools they need. Decide in advance which key files are included in configuration backups, store those copies encrypted, and restrict who can restore them. Rotating keys after staff changes or host decommissioning should be part of the operating procedure.
Control access to backup copies
Backups of VM disks stored in Proxmox Backup Server contain a full copy of guest data, often including data that was stored on Ceph. Enable the encryption options that Proxmox Backup Server provides and keep encryption keys in a location separate from the backup datastore. Restrict datastore and namespace permissions so that backup operators can run jobs without being able to delete or read every backup. Confirm which accounts can restore, where restored disks land, and whether restore tests are performed on an isolated network. Document who holds the encryption key material and how it is recovered if a host fails.
How to test that the storage fails safely before go-live
Before go-live, run a written failure test sequence against the Ceph design and the Proxmox VE cluster together. The goal is to prove two things: the storage keeps guest data intact through each failure, and the cluster behaves in the way the design says it will. Each test needs an expected result written down in advance, a recorded actual result, and a clear pass or fail decision. Agree the pass criteria with the platform owner and the storage owner before the first test starts, so that nobody adjusts the bar after seeing the outcome.
Start with a planned node reboot. Put one node into maintenance mode so that its running guests are live-migrated to other nodes, then reboot it. Confirm that migrations complete without guest downtime beyond what your application tolerates, that Ceph reports the affected OSDs as down and then returns them to service, and that placement groups finish recovering with no data loss. Then run the unplanned test: cut power to a node without a clean shutdown. The critical check is ordering. The node's watchdog should fence it before HA restarts its guests on healthy nodes. If HA starts a guest while the failed node could still write to the same Ceph volume, the design has failed, regardless of how quickly the guest came back. Record the time from power loss to fencing and from fencing to guest start.
Next, pull a single data disk from a node and observe the Ceph response. Note how long the cluster stays in a degraded state, how long the rebuild takes on your hardware and network, and whether client I/O latency stays within the range your applications accept during recovery. Rebuild duration depends on disk size, network throughput, and recovery settings, so ask your storage engineer to confirm the expected range for your configuration rather than relying on a general figure. Then disable one link of a bonded network path and confirm that traffic fails over to the surviving link with no Ceph flapping or quorum loss. Finally, stop one Ceph monitor. The cluster should keep quorum with the remaining monitors, and the monitor should rejoin cleanly when restarted.
For every test, confirm three things beyond the storage state. First, that guests return and their data is intact. Check file system consistency inside the guests and run an application-level verification against known test records, not only a successful boot. Second, that alerts fire. Confirm which alerts your monitoring stack should raise for node loss, fencing, degraded placement groups, a down monitor, and link loss, and that each one reaches the on-call channel within the time your operations team requires. An alert that never arrives is a failed test even if the cluster recovered. Third, that the event log and HA status show what happened in order, so that an operator can reconstruct the incident later.
Plan the test window and the rollback before you begin. Run the tests on a production-equivalent cluster with representative data, and make sure backups from Proxmox Backup Server or your chosen backup tool are verified first. Record every result in a single test log with the date, the software versions in use, the pass criteria, and the observed behavior. Any failed test should be investigated and re-run after the fix, not waived. Ask your implementation partner to confirm which tests they will run, which they expect you to witness, and how they will handle a test that causes data loss on a non-production dataset.
What to monitor, upgrade and document after go-live
After go-live, a Ceph-backed Proxmox VE cluster stays dependable only if someone watches it, patches it in order, tests its recovery and keeps an accurate record of how it is built. The four cards cover those routines and the checks that connect them.
Monitor Ceph and cluster health
Watch Ceph health, OSD state, capacity headroom and recovery activity together with Proxmox node, quorum and HA status. A degraded OSD during a planned node reboot is expected, but the same OSD still down after recovery finishes needs action. Alert on pools approaching full, because Ceph writes slow or stop before the cluster looks unhealthy in other views. Set alert thresholds against your own pool design, and review recovery traffic after every disk replacement.
Upgrade one node at a time
Move each node through maintenance in sequence, checking Ceph health before starting and again before moving to the next node. Let recovery finish between steps so the cluster returns to full redundancy before another host goes down. Plan major Proxmox VE upgrades against Debian support timelines, since Proxmox VE versions are supported at least as long as the matching Debian release has security support. Proxmox VE 8 on Debian 12 reached end of life in August 2026, so treat that date as the planning deadline for any remaining Proxmox VE 8 hosts.
Back up with tested restores
Keep guest backups in Proxmox Backup Server, which adds incremental backups, deduplication, encryption, and tape and S3 support. A job that reports success only shows that the copy was written, so restore a sample of VMs to an isolated network on a fixed schedule and time each restore. Include the Ceph pool layout, Proxmox configuration and any encryption keys in the recovery runbook. Confirm which storage holds backup targets, because backups kept on the same Ceph cluster share its failure domain.
Document the storage design
Keep a current record of the node inventory, disk map, network diagram, pool settings and failover test results. The disk map should tie each OSD to its host, bay, device path and serial number so that replacements go to the correct drive. Record replication size, minimum size and CRUSH rules for each pool, along with the date and outcome of every failover test. Update the record after each hardware or pool change, and store a copy outside the cluster it describes.
Questions teams ask before designing Proxmox VE Ceph storage
How much does a Proxmox VE Ceph storage design project cost?
The cost comes from several separate components, and only some of them are paid to a services partner. Proxmox VE subscriptions are priced per CPU socket per year, and the Proxmox VE pricing page lists Community at 120 euros, Basic at 370 euros, Standard at 550 euros and Premium at 1,100 euros per socket per year. The software can run without a subscription, and the subscription adds support entitlements and enterprise repository access. Other components are server hardware, drives, network switches and adapters for the storage and cluster networks, design and deployment labor, and internal staff time. Design, deployment, testing and documentation are usually one-time costs. Subscriptions, drive replacements, hardware support and staff time recur. Ask any partner for a written quote that separates hardware, licenses, labor and recurring items.
How long does a hyper-converged Ceph storage project take?
The schedule is set by the agreed written scope, and the main drivers are hardware lead times, network changes, change windows and the number of workloads to move. Node and disk counts affect how much testing and tuning is needed. Approval cycles for firewall, switch and VLAN changes often take longer than the technical build. A pilot phase, failure testing and handover documentation add time but reduce risk. DeployOpen does not publish fixed timelines. Ask for a milestone plan that lists dependencies, the client tasks each phase needs, and the acceptance tests that close each phase.
Can our internal team build Ceph on Proxmox VE without outside help?
Yes, many teams can, provided they have solid Linux, networking and storage skills and enough time to test failure scenarios before production use. The work needs knowledge of Ceph pool and replication settings, separate public and cluster networks, OSD and disk failure handling, capacity planning and upgrade order across nodes. Production clusters should use the enterprise repository with a valid subscription key, while the no-subscription repository suits testing. Teams often bring in outside help for a design review, a fixed-scope build with knowledge transfer, or a failure drill before go-live. Assess your team's experience with each of these tasks before deciding.
What does our organization need to provide for a Ceph storage project?
Plan for physical or remote access to the hosts, network changes, maintenance windows and accounts. Access includes racks or cloud hosts, console access and out-of-band management where available. Network work includes VLAN definitions, switch port configuration and jumbo frame settings if you use them, and firewall rules for cluster and management traffic. Maintenance windows are needed for node reboots, firmware updates and the rebalancing that follows drive changes, which can load the storage network for long periods. Provide named administrator accounts with defined roles, representative test workloads and a named approver for each change. Missing any of these usually moves the schedule more than the build itself.
Does Ceph work on a two-node Proxmox VE cluster?
A two-node cluster can run Ceph in a lab, but it does not meet the design most teams expect for shared VM storage with high availability. Proxmox VE high availability needs at least three cluster nodes for reliable quorum, shared storage, redundant hardware and watchdog-based fencing. Ceph monitors also depend on majority quorum, so the monitor count and placement must be checked against the Ceph documentation for your release and the Proxmox VE documentation for your version. Confirm whether any external vote arrangement is supported for your Proxmox VE version and what it means for Ceph monitors before you commit to a two-node layout. A third node is the common path to reliable quorum.
What should a written scope for Ceph storage design include?
A useful written scope lists the node count, drive count and type per node, and the network layout with separate storage and cluster traffic. It should state replication and failure domain settings with the reason for each choice, and the capacity assumptions behind them. Deliverables should name configuration documents, runbooks and the test plan, including disk failure, node failure and network loss tests with pass criteria. The scope should split responsibilities between your team and the partner, cover change control, state what is excluded, and say who holds the Proxmox VE subscriptions. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and ongoing support can be set up as a retainer.
How DeployOpen scopes, builds and hands over Ceph storage on Proxmox VE
DeployOpen plans, implements, documents and supports Proxmox VE Ceph storage inside your own infrastructure, whether that is your cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, so node and disk counts, network layout, replication settings and acceptance tests are agreed in writing before build work starts.
How we scope
- Review planned node count, disk types and workloads before recommending a Ceph layout for Proxmox VE.
- Document the written scope for public and cluster networks, replication settings and capacity targets.
- Agree in writing which hardware, Proxmox VE subscription tier and acceptance tests are in and out of scope.
How we build
- Install and configure hyper-converged Ceph on the Proxmox VE cluster nodes in your environment.
- Separate client, replication and management traffic onto the networks agreed during scoping.
- Test failure of a disk, node and network path, then record the observed recovery behavior against the acceptance criteria.
How we hand over
- Deliver as-built documentation covering pool settings, CRUSH and replication rules, network mapping and capacity figures.
- Provide runbooks for adding OSDs, replacing failed disks and planning capacity growth.
- Walk your operations team through the day-two procedures and confirm they can run them without DeployOpen.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Support can cover Ceph health reviews, capacity reviews and Proxmox VE upgrades that affect the storage layer.
- Ask your quote to state which support tasks recur, who performs them and how changes are requested.
