What upgrades and support cover for Ceph
Ceph's source is licensed under LGPL-2.1 or LGPL-3, and the project does not sell a paid edition. Every maintained release, upgrade and support arrangement is therefore run by your own team, by a partner, or by both. The actively maintained releases are Tentacle (20.2.x, first released November 18, 2025, latest 20.2.4, estimated end of life June 1, 2027) and Squid (19.2.x, first released September 26, 2024, latest 19.2.7, estimated end of life October 31, 2026). Actively maintained releases receive periodic backports and security fixes, so a cluster on Squid has a fixed window to move.
Several events start an upgrade decision. The most common is an approaching end of life, but a published security advisory, a cluster found on a release that no longer receives fixes, a planned cephadm migration, and a new hardware generation joining the cluster each have the same effect. Cephadm does not support releases older than v15.2.0 (Octopus), so a cluster on an old release may need a staged path before cephadm management is possible. Start by listing each cluster's running version, its cephadm status and the estimated end of life that applies to it.
Teams with an experienced Ceph operator often keep routine minor updates in-house, because they are repetitive and well documented. A partner is more useful for the major move, for the first upgrade on a production cluster, and for a health review before either. Ask any provider to state in writing what a health review checks, who holds the rollback plan, how the upgrade order across monitors, managers, OSDs and gateways is set, and who is on call during the window.
What the engagement includes
Each Ceph upgrade engagement is scoped in writing before work starts, and its deliverables are documents plus a cluster that has been verified in a stated state. The items below cover the path from assessment to handover and the support options that follow.
Pre-upgrade assessment
We record the current Ceph version, cephadm orchestrator status, cluster health, and capacity headroom, so the upgrade starts from a known baseline. We also check client and gateway compatibility, including RBD clients, CephFS mounts and Object Gateway consumers, because a cluster can be healthy and still break its callers after an upgrade.
Upgrade and rollback plan
The plan sets the daemon upgrade order across monitors, managers, OSDs, metadata servers and gateways, along with the pause points where the team checks health before continuing. The rollback plan states which steps can be reversed, which cannot, and what evidence triggers a stop. Both documents are written for the people who will run the change.
Rehearsal in a non-production cluster
We run the same upgrade path on a non-production cluster that matches production's release, daemon layout and client mix as closely as the environment allows. The rehearsal exposes timing, failed health checks and client issues before they reach production. Its findings feed back into the plan and the change window.
Rolling production upgrade
The production upgrade runs daemon by daemon under a written change window, with health checks at each stage and a named decision owner for any pause. Your team should confirm the window, the approval chain and the communication path to application owners before the day begins. Data stays online throughout when replication and failure domains are sized for the restart pattern.
Post-upgrade validation
After the last daemon restarts, we verify cluster health, placement group states, client connectivity and gateway behavior against the baseline from the assessment. The result is a dated record of the cluster state at handover, not a verbal confirmation. Open items are logged with an owner and a follow-up date.
Runbook and handover
The runbook covers routine health checks, the upgrade procedure used, rollback steps, known alert thresholds and escalation contacts. We walk your operators through it and record the handover so the next upgrade can be planned by your team or by a partner without rebuilding the knowledge.
Support and patch review options
Support is available as scheduled patch reviews, where we assess backports and security fixes for the maintained Ceph releases and plan when to apply them. Incident response covers cluster-level faults during agreed hours. Each option is defined in a written agreement that states what is covered, how requests are raised and what is excluded.
What drives cost and duration
This table lists the factors that change the size of a Ceph upgrade and support engagement, why each one matters, and what you can do to keep it contained.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Number of clusters and their sizes | Each cluster needs its own pre-checks, rolling sequence, health verification and rollback plan, and larger clusters take longer to drain and recover between daemon restarts. | Group clusters by release and hardware so one upgrade pattern covers several, and confirm host and OSD counts before scoping. |
| Starting release and distance to the target | A cluster several releases behind may need intermediate upgrade steps and more compatibility checks than one already on Squid. | Record the exact current release for every cluster, and plan to move onto a maintained release before Squid reaches end of life. |
| Deployed with cephadm or not | cephadm does not support older releases, so a pre-Octopus or non-cephadm estate needs a different first step, such as redeployment or migration to cephadm, before a normal upgrade. | Confirm how each cluster was deployed and which release it runs, then decide whether the first task is an orchestration change or a straight upgrade. |
| Number of hosts and OSDs | More hosts and OSDs mean more daemons to restart, more data to rebalance and longer health checks at each stage of the rolling order. | Use a maintenance window sized to the cluster, keep recovery and backfill settings reviewed, and benchmark a test cluster before production. |
| RGW multisite and Dashboard SSO configuration | Multisite zones and Dashboard authentication (SAML 2.0 or OAuth2 through the Management Gateway and OAuth2 Proxy) add configuration to validate after each step, and the Dashboard SSO path depends on which services cephadm runs. | Document the realm, zonegroup and zone layout and the identity provider settings before the upgrade, and include them in post-upgrade checks. |
| Client and hypervisor versions that depend on the storage | Virtualization hosts, Kubernetes nodes and RBD or CephFS clients may need their own updates or compatibility checks, which can extend the schedule beyond the Ceph cluster itself. | Inventory every client that mounts or maps Ceph storage and confirm supported combinations with the vendors of those platforms. |
| Kubernetes or Rook involvement | Rook-managed clusters follow the operator's upgrade path, and its version constraints must be matched to the Ceph release, adding a second change to coordinate. | Confirm whether the cluster runs under Rook or cephadm, and check the Rook and Ceph compatibility notes before setting the upgrade order. |
| Air-gapped or change-controlled environments | Offline container images, package mirrors and formal change approvals add preparation work and lead time that do not appear in the technical steps. | Stage images and packages in the internal registry early, and agree the change calendar and approvers at the start of the engagement. |
| Number of environments (lab, staging, production) | Each environment is upgraded and verified separately, so a three-environment path roughly multiplies the testing and sign-off effort. | Use the lab and staging runs to refine the procedure, and reuse the same runbook and health checks in production. |
How an upgrade engagement runs
The sequence moves from an inventory of the live cluster to a rehearsed, checkpointed production upgrade and a handover your team can operate.
Inventory the cluster and its history
We record the running Ceph version, cephadm state, host and daemon layout, OSD and pool configuration, hardware and network topology, and the health history over recent weeks. The output is a written inventory your team confirms as accurate before any risk work starts.
Review compatibility and risk against release notes
We check the inventory against the target release notes, including supported starting versions, required pre-upgrade steps, deprecations and known issues for your hardware and configuration. The output is a risk register with each item assigned an owner and a mitigation or an explicit acceptance.
Rehearse the upgrade on a non-production copy
We run the planned upgrade on a non-production cluster built to match production as closely as practical, using the same procedure and the same health checks. The output is a rehearsal log with timings, issues found and runbook changes, which feeds the go or no-go decision.
Hold a go or no-go checkpoint
Before any production change, we review the inventory, risk register and rehearsal results with your team and confirm the rollback position, backup state and maintenance window. The output is a recorded go or no-go decision, and no production change proceeds without it.
Run the rolling production upgrade
We upgrade production in the daemon order the upgrade documentation sets for the target release, confirming that exact sequence against that release's notes, and check cluster health between stages. The output is a timestamped change record showing each stage completed with cluster health confirmed.
Verify and hand over
We verify client access, RGW and Dashboard functions, recovery and scrub activity, and health status against the baseline, then document the final state and runbooks. The output is a verification report and a handover session in which your operators run through the procedures themselves.
What usually goes wrong
Most Ceph upgrade problems come from decisions made before the first daemon restarts. Each pattern below has a specific check that prevents it.
Upgrading without a health baseline
If the cluster already shows warnings, it becomes hard to tell which problem came from the upgrade. Capture ceph health detail, placement group states, OSD and monitor status, and recent error logs before the first step. Store that output with the change record so any regression can be compared against a known starting point.
Skipping the required upgrade path
Ceph documents supported upgrade paths between releases. Jumping over an intermediate release can leave daemons or on-disk formats in a state the next step does not expect. Read the release notes for every release between your current version and the target, and treat each required step as a gate that must pass before the next one starts.
Client and gateway incompatibility after cutover
A cluster can upgrade cleanly while older RBD kernel clients, CephFS mounts, client libraries, or applications using the Object Gateway fail afterward. Inventory every client by type and version, including hypervisors, Kubernetes CSI drivers, and backup tools. Check each against the target release's compatibility notes and test one representative of each class before the cluster moves.
Too little recovery headroom
Recovery after an OSD restart or a host drain consumes disk and network throughput and needs free space to rebuild data. Without spare capacity, client I/O can slow sharply and OSDs can approach full thresholds. Review raw and usable capacity, per-OSD utilization, and network paths, and confirm the cluster can absorb one host outage during the rolling restart.
Unplanned cephadm configuration drift
cephadm keeps service specifications and configuration in the cluster, but manual edits on hosts or ad hoc setting changes can persist unnoticed. Over time, these differences make the same upgrade behave differently on some hosts. Export service specs and the current configuration, compare them with the change record, and review administrative access before each upgrade window.
Treating end of life dates as soft
The Ceph releases page lists estimated end of life dates of October 31, 2026 for Squid and June 1, 2027 for Tentacle. Estimates can change, but waiting for a date to pass leaves little room for testing and rollback. Build a dated plan from these estimates, confirm current dates on the releases page, and schedule client testing with time to spare before the cutoff.
Recurring costs after go-live
This table lists the recurring cost components of running Ceph after go-live, who usually pays for each, what recurs, and what to request in a quote so one-time upgrade work and ongoing support can be compared.
| Cost component | Who pays | What recurs | What to ask for in a quote |
|---|---|---|---|
| Internal operator time for health checks and patch reviews | Your platform or storage team | Regular cluster health reviews, reading release notes and backport announcements, and deciding which fixes to apply | Estimated hours per month for health checks and patch review, and who performs them if the work is outsourced |
| Upgrade cadence as each release reaches end of life | Your organization, with a partner if contracted | Planned major upgrades as the current release nears its end of life, such as Squid (estimated end of life October 31, 2026) moving toward Tentacle | The release path assumed, the estimated end of life dates used, and whether each upgrade is priced as a separate one-time project |
| Support retainer versus per-incident support | Your organization, paid to a support provider | A retainer recurs on a fixed term. Per-incident support is billed only when an issue occurs, so cost is less predictable | Retainer scope, response expectations in writing, what is excluded, and the rate for out-of-scope or per-incident work |
| Test environment hardware | Your organization | Hardware and power for a non-production cluster used to rehearse upgrades and test fixes before production | Whether the quote assumes a test cluster, its size relative to production, and who maintains it between upgrades |
| Monitoring and alerting | Your organization, often with tooling you already run | Metrics collection, alert tuning, log retention and storage for monitoring data | Which monitoring stack the quote assumes, who owns alert rules, and whether dashboards and runbooks are included |
| Licensing position | Not charged by the project | The Ceph source is LGPL licensed and there is no paid edition from the project itself, so recurring cost is people, hardware and any contracted support | Confirmation that the quote contains no license fee, and a list of any commercial component or subscription it includes |
| One-time upgrade work versus recurring support | Your organization or a contracted partner | Upgrade projects recur at each release cycle, while support fees recur on their own term | A quote that separates one-time upgrade work from recurring support, with the release path and end of life dates named |
How the work differs by starting point
Start here if the cluster already runs Squid under cephadm. The scope is mostly the upgrade itself, plus the checks that show the cluster is healthy before and after the change. Squid's estimated end of life is October 31, 2026, so that date usually sets the schedule.
- Confirm the cluster is on the latest Squid point release before the move, and read the Tentacle release notes for deprecations and changed defaults.
- Check which settings touch your pools, Object Gateway or Dashboard configuration, and record any option that changes behavior in Tentacle.
- Confirm that every host, OSD and daemon reports a healthy state and that no recovery or rebalancing is still running.
- Plan the rolling order for monitors, managers, OSDs, metadata servers and gateways as the cephadm documentation describes.
- Ask the vendor documentation which client versions are supported with Tentacle, and test RBD, CephFS and S3 clients that reconnect afterward.
Use this path when the cluster runs cephadm on a release older than Squid. Depending on the starting version, a direct jump to Tentacle may not be supported, so the work includes planning intermediate upgrades and testing each one. The exact stops come from the official release notes for your starting version, so confirm them before any date is set.
- Identify the current release and the supported upgrade path to Tentacle in the release notes.
- Run each intermediate upgrade as its own change window, with a health check and a documented rollback point.
- Find deprecated options and features in your configuration and migrate them before the first upgrade step.
- Verify that the operating system and container runtime on each host are supported by each target release.
- Ask for a written list of upgrade stops and the test evidence for each stop before production work begins.
Use this path when the cluster was deployed with other tooling or was managed by hand. cephadm was introduced in v15.2.0 and does not support older releases, so the cluster must be on v15.2.0 or later before it can be brought under cephadm. If it is older than that, the first stage is an upgrade to a release cephadm supports, followed by adoption and then the Tentacle upgrade.
- Confirm the running release is v15.2.0 or later, and plan a separate upgrade stage if it is not.
- Inventory daemons, configuration files, keyrings and host layout, because adoption must match what is already running.
- Adopt daemons in stages and check orchestrator status after each stage before moving to the next.
- Verify container images, host prerequisites and network settings against the cephadm documentation for your release.
- Confirm in the vendor documentation whether adoption steps differ for your exact release, and schedule the Tentacle upgrade only after adoption is stable.
Use this path when Ceph runs inside Kubernetes under the Rook operator. The Ceph version change is sequenced by the Rook operator, so it runs inside that workflow and must be planned with the Kubernetes platform. Rook has been a CNCF Graduated project since October 7, 2020, and its own documentation sets which Ceph versions each Rook release supports.
- Confirm which Rook release supports Tentacle and which Kubernetes version that Rook release requires.
- Upgrade the Rook operator first if the Rook documentation requires it, then update the Ceph image in the cluster resource.
- Check node drains, pod disruption budgets and storage class consumers, because OSD pods restart during rolling updates.
- Back up cluster and custom resource manifests, and confirm that storage class and pool definitions still match the desired state.
- Coordinate the change with the team that owns Kubernetes node upgrades, since the two can block each other.
What you need to provide
The upgrade goes faster and safer when the client supplies access, records and decisions before the first change window is planned. Read access to the cluster should come through an agreed account, with the cephadm version, the host inventory and the current cluster health history available at the start. Recent incident records matter as much as the live state, because a warning that has appeared before a previous failed recovery changes the preflight plan. Network diagrams should show the bonded links across two switches, as the Ceph hardware recommendations describe, along with the public and cluster networks and any routing between them. Equally important is the list of clients, hypervisors and Ceph Object Gateway (RGW) consumers, including which RBD images, CephFS mounts and S3 applications depend on the cluster and how each one reconnects after a daemon restart.
Several decisions must be made before work starts. The client should choose the target release, which for a cluster currently on Squid means weighing the estimated end of life for Squid against the estimated end of life for Tentacle, and confirm the acceptable downtime for each service class. They should also set the support hours that apply during the window and after it, and agree who is on call when a rolling step stalls. Someone in the client organization must hold a named owner for go or no-go decisions, with written rollback authority for the change window. Access to a non-production environment for rehearsal is also required. Ask the client to confirm that this environment matches production closely enough to test the upgrade order, cephadm behavior and client reconnection, and to say how far its hardware and data volume differ from production.
Common questions about Ceph upgrades and support
Can our own team upgrade Ceph without outside help?
Yes, your team can perform the upgrade itself if it has a tested runbook, a rehearsal in a non-production environment and staff who can read Ceph health output at each step. The main question is capacity and risk tolerance: whether your people can keep normal operations running while daemons restart in rolling order, and whether a failed step has an agreed rollback path. A written plan covers the release path, the cephadm steps, the health checks between stages and the points where the team stops and escalates.
How long does a Ceph upgrade take for our cluster?
The duration depends on cluster size, the release you start from and how many environments must be upgraded, so it is set in the written scope rather than guessed. Larger clusters have more daemons to restart and more data to rebalance, and each environment adds its own rehearsal and validation. Ask the scope to list the environments, the starting release, the host count and the change windows you can use, and confirm whether rehearsal and post-upgrade checks are included.
What does our team need to provide for a Ceph upgrade?
Your team provides the access, decisions and information the upgrade depends on. Expect to supply administrative access to the hosts and the cephadm environment, a current inventory of hosts, drives and network links, recent health and performance baselines, and agreed change windows. You will also need a named approver for each stage, representatives who can test your client workloads after the upgrade, and contacts at your hardware vendors in case a drive or host fails during the work.
What if we are still on Squid when it reaches end of life?
Squid's estimated end of life is October 31, 2026, according to the Ceph releases page, so schedule the move to Tentacle before that date. Tentacle's estimated end of life is June 1, 2027. Actively maintained releases receive periodic backports and security fixes, so a release past its end of life will not get the same fixes. Confirm the current dates on the Ceph releases page before you set a plan, and include the move in your change calendar early.
Does a Ceph support agreement cover hardware failures and replacements?
No, a support agreement does not take over hardware. It covers the software operation of your Ceph cluster and advice on it, including upgrades, health checks and configuration questions. Hardware, its warranty, replacement parts and any vendor support contracts stay with you and your hardware vendors. Ask the scope to name which hosts, drives and network components are included, who opens hardware tickets, and how DeployOpen will work with your vendor when a failed drive affects the cluster.
Is DeployOpen an official Ceph vendor partner or reseller?
No, DeployOpen is not an official partner, reseller or certified provider of the Ceph project. Ceph's source is licensed under LGPL, and the project itself offers no paid edition, so DeployOpen works on self-hosted Ceph inside your infrastructure. When you compare providers, ask for the written scope, the upgrade and rehearsal method, who will do the work and how support is delivered, and ask each provider to explain its relationship with the project in writing.
How DeployOpen delivers Ceph upgrades and support
DeployOpen plans and carries out Ceph upgrades inside infrastructure you control, from a written scope through to documented handover. Ongoing support for a maintained release is available as a retainer.
How we scope
- We inventory your current Ceph release, deployment method, daemons, pools and client types before proposing any upgrade path.
- The written scope names the source and target releases, including the move from Squid to Tentacle, and the hosts and services in each upgrade wave.
- Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before any change window is booked.
How we build
- We test the planned upgrade in a non-production copy of your cluster using cephadm, then record each step and its rollback point.
- The rolling order for monitors, managers, OSDs, metadata servers and gateways is written down and checked against cluster health before work begins.
- We run pre-upgrade and post-upgrade health checks, client compatibility checks and workload tests, and log the results for your review.
How we hand over
- Handover covers the as-built cluster state, the upgrade runbook, the health check scripts and the rollback procedure used during the work.
- We document any configuration changes, deprecated settings and open follow-up items so your team can operate the cluster after the engagement ends.
- We walk your operators through monitoring, alert review and the steps for the next upgrade so responsibility transfers with a clear record.
How we support
- Ongoing support can be set up as a retainer covering periodic maintenance, patch-level updates and release planning for the maintained Ceph release you run.
- Support scope, response expectations and reporting are defined in the agreement, so you can confirm exactly what is included before signing.
- Retainers can include planned upgrades to later point releases and reviews ahead of the Squid end of life date, which you should confirm against the Ceph releases page.
