Setting Ceph placement group counts and the PG autoscaler

The effort depends mainly on how many pools the cluster will hold, how many of them will grow, and how much the OSD count may change over the planning horizon. A single pool on a small, stable cluster is a short exercise. A cluster with block, file and object pools, each with its own growth rate, device class and replication or erasure coding profile, takes longer because every pool's PG count has to be checked against the others on the same OSDs. Effort also rises when the hardware list is still changing, since PG targets depend on how many OSDs will exist and on how their capacity is distributed.

Yes, many platform teams do this themselves, provided someone on the team understands CRUSH rules, pool types and how the autoscaler makes its decisions. The work is mostly analysis and documentation: inventorying pools, writing down the expected growth of each one, and checking the autoscaler's recommendations before accepting them. Teams that find this difficult usually lack a second reviewer, not the technical knowledge. A partner review adds an outside check on the assumptions, which is most useful before the cluster takes production data, when a wrong target is cheap to correct.

Prepare three inputs. First, a pool inventory listing each planned pool, its purpose, its protection scheme, the device class it will use and the application that consumes it. Second, a growth forecast for each pool over the period you plan for, with the assumptions stated, such as expected tenant onboarding or dataset size. Third, a hardware list with the number of hosts, OSDs per host, drive sizes and media types, and the planned network layout. The Ceph hardware recommendations help confirm that the list matches how the cluster will be built. Missing forecasts are the most common reason a review stalls.

The duration follows the number of pools, the number of OSDs and how many decisions remain open. A small cluster with a few stable pools and a settled hardware list can be reviewed in a short working session. A larger cluster with many pools, several device classes and a multi-site plan needs more time for each pool's assumptions and for testing the resulting layout. The schedule also depends on how quickly your team can answer questions about forecasts. Ask any provider for a written timeline tied to the agreed scope, and confirm which inputs must be complete before the review begins.

A PG review is usually one part of a larger cluster design or deployment engagement, so the cost depends on its scope within that work. The main drivers are the number of pools, the number of distinct device classes and CRUSH rules, whether the review includes checking the cluster after data is loaded, and how much forecasting work falls to the provider. Recurring costs are separate and appear only if you retain someone to review PG counts as the cluster grows. DeployOpen does not publish a price list. A quote follows from the written scope, so ask for the deliverables, assumptions and any follow-up reviews to be listed.

After go-live, PG counts change as data grows, OSDs are added or removed, and pools are created or retired. If the autoscaler is active, it can adjust PG counts on its own, which moves data between OSDs and creates recovery load while it does so. Operators need to schedule that activity around client traffic and watch for backfill during working hours. Growth forecasts also drift, so the target settings you chose at the start should be reviewed when a pool's real usage departs from its plan, when hardware is added, or when a new application starts using the cluster.

Start in warn mode on a new cluster unless you have already reviewed the recommendations for every pool. In warn mode the autoscaler reports the PG count it would choose and raises a health warning, but it does not change anything, so your team can compare its suggestions with the pool plan. on mode lets the autoscaler apply changes automatically, which suits pools whose growth you understand well. Per-pool behavior is set with pg_autoscale_mode, and the current recommendations appear in the output of ceph osd pool autoscale-status. Confirm the mode you choose against the documentation for your Ceph release before you apply it to production pools.

Usually yes, if the pool will hold a large share of the cluster's data later and is empty or small at go-live. Without a hint, the autoscaler sizes a pool by its current usage, so a pool that will grow may start with too few PGs and then need large data movements as it fills. Setting target_size_ratio tells the autoscaler what fraction of the cluster the pool is expected to use. Set the ratio for every growing pool at the same time, so the values together describe the whole cluster, and record the reasoning so a later reviewer can see why each value was chosen.

Treat the output of ceph osd pool autoscale-status as a suggestion built from the data present at that moment, not as a final answer. Check the current PG count, the suggested PG count, the target ratio and the pool's effective size before accepting a change. Compare the suggestion with your pool inventory, since an empty pool that will hold most of the cluster's data later will show a low suggestion now. Also check that the pools share the same device class and CRUSH rule, because pools on different media compete for different OSDs. Record each accepted change with its reason.