When CephFS and NFS exports fit your shared file storage
Choose CephFS when several machines need to read and write the same directory tree at once and the workload expects a file system rather than object or block storage. Typical cases are shared home directories, HPC scratch space and application storage where software opens paths, locks files and relies on directory semantics. Object storage through the S3 API does not provide that namespace, and block volumes can only be attached to one host at a time unless you add a cluster file system on top. CephFS gives you a POSIX-style namespace on top of RADOS, the object layer under Ceph. Metadata servers (MDS daemons) hold the directory tree and file attributes, while file data is stored as objects in data pools.
That split drives the design. Metadata performance determines how quickly directory-heavy workloads feel, so you need to plan MDS placement, standby daemons and the metadata pool's media before you think about raw capacity. Clients mount the file system with the native kernel client or FUSE, and both need network reach to the monitors, MDS daemons and OSDs. Confirm which client versions your Linux distributions ship and whether your applications depend on features that differ between kernel and FUSE mounts. The Ceph releases page lists the actively maintained Tentacle and Squid releases, and your version choice should start there.
NFS exports are the next step when some clients cannot run a Ceph client at all, such as appliances, older hypervisors, or workstations under a policy that bars installing third-party storage software. NFS-Ganesha serves CephFS over NFS so those clients can mount through standard NFS while the cluster keeps its native access path. The trade-off is an extra service to size, secure and make highly available, plus a second set of permissions to align with CephFS capabilities. Decide early which clients need native mounts, which need NFS, and who owns the export configuration, because that answer shapes the cluster layout and the support model.
Which client path fits each workload
This table compares the native kernel client, the FUSE client and NFS-Ganesha exports across home directories, HPC scratch, application storage and clients without Ceph support. Read each row as a question about your clients: what must be installed on them, what you operate, and where the path tends to strain. The main takeaway is that the choice is usually driven by which client operating systems you must support and who manages them, not by a single performance rule.
| Workload | Client path | What the client needs | Trade-offs and when it fits |
|---|---|---|---|
| Home directories for managed Linux desktops and servers | Native kernel client | A kernel mount with CephFS support, a Ceph client keyring, and network access to the monitors and MDS daemons | Usually the most familiar mount for administrators. Confirm that your distribution kernels match the client versions you plan to support before standardizing. |
| Home directories on hosts you cannot patch quickly | FUSE client | The ceph-fuse package and a keyring, with no kernel module dependency on the host kernel | Fits hosts with older or locked kernels. Expect more user-space overhead and plan updates for the FUSE package as a separate maintenance item. |
| HPC scratch on compute nodes | Native kernel client | A kernel mount on every compute image, with keyrings distributed through your provisioning system | Commonly chosen for parallel job I/O on images you control. Test metadata-heavy workloads against your MDS layout before committing, since many small file operations stress the metadata path. |
| Application storage for containers on Kubernetes | Native kernel client or CSI driver | A CSI driver on the cluster nodes that mounts CephFS volumes for pods | Ceph-CSI handles provisioning for pods, so the client path is set by the driver. Confirm driver and Ceph release compatibility with your upgrade plan. |
| Clients with no Ceph client support, such as legacy Unix or appliances | NFS-Ganesha export | Only an NFS client on the consuming host, with network access to the Ganesha gateway | Keeps Ceph client software off the consumers, but adds a gateway tier to size, load balance, and fail over. Confirm NFS protocol versions and locking behavior with the applications that depend on them. |
| Mixed estate with Windows or macOS users | Not a CephFS client path | Depends on the access protocol chosen for that tier | Native clients and NFS do not cover these users directly. Review the separate SMB file share option before designing around it. |
| Multi-tenant or shared trees with strict isolation | Native kernel client or NFS-Ganesha | Per-client CephX capabilities scoped to paths, or per-export access rules on the gateway | Scope access at the client or export level and test that each tenant cannot reach other directories. Confirm the capability syntax for your Ceph release in the documentation. |
How metadata server sizing changes with file counts and clients
Workloads that create, stat and delete very large numbers of small files place the heaviest load on the metadata server. Every file, directory entry and capability the MDS hands to a client consumes memory in the MDS cache, and most of the work is metadata operations rather than data transfer. For this situation, the number of files and directories you hold matters more than the total capacity you store, so sizing starts from a file count estimate and the rate at which clients open and close files.
- Cache is the main memory consumer: the MDS keeps metadata for active inodes in memory, so a tree with many millions of small files needs far more RAM than the same capacity held in a few large files.
- Operation rate drives CPU and latency: creates, lookups and renames from many clients serialize through one active daemon unless you scale out.
- Directory size matters: very large single directories concentrate load and make listing operations expensive.
- Standby capacity still needs memory: a standby that takes over must be able to rebuild a comparable cache, so size it like the active daemon.
- Test with your file profile: run a metadata benchmark that mirrors your file sizes, directory depth and client count before you buy hardware.
Before committing to hardware, ask the vendor or integrator to confirm the cache size and CPU needs for your expected file count, and check the Ceph hardware recommendations on memory sizing for peak use.
Large sequential HPC jobs usually read and write big files from many compute nodes at once. The data path carries most of the traffic, so the metadata server sees comparatively few operations per byte moved. The MDS load comes mainly from opens, closes and capability requests at job start and job end, not from steady I/O. Sizing for this situation therefore emphasizes OSD throughput and network capacity, with the MDS sized for bursts of session setup from many nodes.
- Few operations per byte: once a file is open and its capabilities are granted, data I/O bypasses the MDS.
- Job start storms: thousands of nodes mounting or opening files at the same moment can briefly load the MDS more than steady running does.
- Scratch churn: if jobs create and delete large numbers of temporary files, the MDS still handles those metadata operations even though the data is large.
- Network and OSD limits: bandwidth between clients, OSDs and the MDS often sets the practical ceiling before metadata does.
- Benchmark job patterns: replay a representative job start and a checkpoint write to observe the MDS under realistic bursts.
Ask the team running the HPC scheduler to describe peak concurrent client counts and job start patterns, since these numbers determine how much session headroom the MDS needs.
Home directories serve many users who each generate a mix of small file operations, editor saves, shell lookups and application configuration reads. Load is spread across many clients and tends to follow working hours, so the MDS sees sustained, mixed metadata traffic. Client count and session count often matter more than raw file count, because each active client holds sessions and capabilities that the daemon must track and renew.
- Session count: each mounted client creates a session on the MDS, and idle clients still consume some resources.
- Mixed workload: lookups, attribute reads and small writes arrive together, which keeps the cache hot and the CPU busy.
- Daily peaks: login periods and scheduled jobs such as backups or indexing can push load above the average.
- Snapshots and quotas: snapshot counts and quota checks add metadata work that grows with the tree.
- Plan for failover: a standby daemon that takes over during a restart must reload state, so user-facing pauses depend on standby readiness.
Confirm with your identity and desktop teams how many users and clients will mount the share at once, and ask for a load test that reflects a normal working day and a login peak.
Across all three situations, the MDS needs memory for its cache, CPU for request handling, and at least one standby daemon so that a failure does not stop the file system for long. Standby daemons are part of the availability design, not spare capacity you can leave unsized. Keeping one standby is the baseline for most sites, and the decision about how many active daemons to run is a separate step that depends on whether one active MDS becomes the bottleneck.
- Size memory for peak use: the hardware recommendations advise sizing for peak use rather than calm periods, since cache growth follows the busiest hour.
- Standby for failover: keep at least one standby so that an active daemon failure triggers a takeover instead of an outage.
- Benchmark before buying: the hardware recommendations say no two clusters are alike, so measure your own workload on candidate hardware.
- Scale beyond one active daemon: when one active MDS is saturated, the multi-active MDS sibling topic covers max_mds, standbys and directory pinning.
- Keep metadata media fast: the hardware recommendations advise enterprise-class SSDs for metadata pools.
Before buying, ask your integrator to state the cache memory, standby count and benchmark method they will use, and to show how the design changes if your file count doubles.
How a CephFS build runs from pools to mounted clients
This sequence takes a cephadm-managed Ceph cluster from a confirmed release line to a CephFS file system that Linux clients mount directly and, where needed, NFS-Ganesha exports to clients that cannot run Ceph clients. Each step closes with a check so the next one starts from a known state.
Confirm the release line and cluster baseline
Before any pool is created, confirm which actively maintained Ceph release line the cluster will run and record it in the build plan. The Ceph releases page lists Tentacle (20.2.x) and Squid (19.2.x) as the active lines, with published end-of-life estimates for each, so the choice should reflect how long the platform must stay supported. Your team or DeployOpen confirms the target release, the Linux distribution and kernel versions on the clients, and whether NFS-Ganesha will be deployed through cephadm. The step is done when the release, client kernel versions and export requirements are written into the approved design.
Deploy the cluster with cephadm
Bootstrap the cluster with cephadm, which runs Ceph daemons as containers, then add hosts and place Monitors, Managers and OSDs according to the hardware design. Ceph's hardware recommendations call for a dedicated drive per OSD and bonded network links across two switches, so confirm both before hosts are added. Ask the cluster to report its state, including the Monitor quorum and the OSDs that have joined. The step is complete when
ceph -sreports a healthy cluster with the expected number of OSDs up and in, and no health warnings that would block pool creation.Create metadata and data pools on suitable device classes
Create a replicated metadata pool on enterprise-class SSDs, since the hardware recommendations advise that class of media for metadata, and a data pool that matches the workload. Replicated data pools are the simpler choice for shared home directories and small files. Erasure-coded data pools reduce capacity overhead for large, mostly sequential HPC or archive data, but they need a separate design for overwrites and failure domains. Pin each pool to a CRUSH device class so SSD and HDD data stay apart. The step is done when both pools appear in the pool list with the intended replication or coding profile and device class, and placement groups reach an active and clean state.
Create the file system with standby MDS daemons
Create the CephFS file system on the metadata and data pools, then deploy metadata server (MDS) daemons through cephadm with at least one standby. A single active MDS is the default starting point, and standbys take over if the active daemon fails. Confirm the placement of the MDS daemons across hosts so that a single host failure does not remove every daemon. The step is complete when the file system is listed, one MDS reports active and the others report standby, and the file system is not degraded. Multi-active MDS is a later decision covered separately.
Create client users with scoped capabilities
Create a dedicated Ceph client user for each mount point or application, granting read and write access only to the directories and file system it needs. Ceph client capabilities scope access by path and pool, so a home directory client should not hold rights to the whole file system. Record the key in your secrets store rather than in shared configuration files. The step is done when the user's capabilities list the intended path and pool, and a test client can authenticate with the keyring and see only its permitted directory.
Mount with the kernel or FUSE client
Mount CephFS on a Linux client using the kernel client where the kernel version supports the required features, or the FUSE client where it does not or where user-space behavior is preferred. Mount only the directory the user is scoped to, using the keyring created in the previous step, and set the mount options your team has approved. Write and read a test file, check free space reporting, and confirm that the MDS shows the session. The step is complete when the test file persists across remount and the client session appears in the MDS session list.
Configure NFS-Ganesha exports for non-Ceph clients
For clients that cannot run a Ceph client, such as certain appliances or older systems, deploy NFS-Ganesha through cephadm and export a CephFS path over NFS. Define the export with its allowed client networks, access mode and squash settings, and confirm that the export path sits inside a scoped Ceph user's permitted tree. Test access from a non-Ceph client and confirm that write permissions behave as the design requires. The step is done when the NFS export is listed, the test client mounts it, and the access results match the approved permissions. Confirm the NFS protocol versions and authentication options supported by your Ganesha release before finalizing the design.
Verify health and record the working state
Run a final check across the cluster, the file system and each client path. Confirm that the cluster reports healthy, the MDS daemons are in their expected active and standby states, client sessions are visible, and each export responds from its permitted networks. Save the outputs, the capability definitions and the export configuration in the runbook so that later changes can be compared against a known baseline. The step is complete when the signed-off checklist matches the approved design and the health checks pass with no unexplained warnings.
Securing CephFS clients, exports and the network
CephFS and NFS exports share one cluster, so a weak client credential, an unencrypted path or a single network link can expose or stall every share at once. The cards below cover the controls to decide before go-live and the checks to repeat after each change.
Scope client capabilities per file system
Give each client a CephX identity that can reach only the file system and path it needs. Read-only or path-restricted capabilities keep a home directory client or an NFS gateway away from other tenants' trees. Keep one key per consuming system rather than sharing a key, so you can revoke one host without touching the rest. Review the capability strings during onboarding and again whenever a share is added. Ask your team which identity the NFS-Ganesha gateway uses and confirm it cannot mount the whole file system.
Enable msgr2 secure mode
Messenger v2 listens on port 3300 and its secure mode encrypts all traffic after authentication with AES-GCM and adds integrity checks. Set the connection mode for clients and daemons deliberately, and confirm that kernel and FUSE clients on your target distributions support it before you enforce it. Plan for mixed-version clients during the change window, because a client that cannot negotiate secure mode will fail to connect. Test a single client mount first and record the negotiated mode.
Separate the storage network
Keep client traffic, replication and recovery traffic on distinct networks where the hardware allows it, so a large rebuild does not starve file reads. Bond links across two switches so that losing one switch or one cable does not isolate a host. Confirm the bond mode, MTU and VLAN layout on every OSD, monitor and metadata server host. Ask the vendor or your network team to test failover of each switch under load before the cluster carries production data.
Restrict who can reach the NFS gateway
NFS-Ganesha exports are only as protected as the client list on each export. Limit each export to the subnets or hosts that need it, and avoid wildcard access for read-write shares. Decide which clients may mount as root and whether root is squashed to an anonymous user. Place the gateway on a client-facing network that cannot reach the Ceph monitor and OSD networks directly. Ask your team to document the export access list as a reviewed file, not as a set of ad hoc changes.
Control the management and monitor paths
Monitors, managers and the MDS daemons are the control plane for every share, so their reachability matters more than any single client. Restrict access to the monitor ports and the cephadm host SSH path to administrative subnets, and keep the dashboard off the client network. Record who holds administrative keys and rotate them when staff change. Confirm with your team which hosts can run cephadm commands and how those hosts are authenticated.
Verify access after every change
Access controls drift as shares are added, clients are rebuilt and gateways are upgraded. Schedule a check that lists each client identity, its capabilities and its export list, then compares them with the approved register. Test that a client outside its path is refused and that a read-only mount cannot write. Keep the results with the change record so an auditor or incident responder can see what was allowed and when. Agree on the review frequency in writing with your operations team.
Questions buyers ask before building CephFS and NFS exports
What drives the cost of a CephFS and NFS export project?
The scope of the cluster and the number of clients drive most of the cost. The main components are hardware, metadata server (MDS) layout, pool design, the number of NFS exports you need, and the client migration effort. Hardware is usually a one-time purchase, while support and upgrades recur. Ask for a quote that lists each component separately, including who buys the hardware, who builds the cluster, who configures each export, and who moves each client. Ask how many clients, directories and exports the quote covers, since adding more usually adds cost in proportion.
Which parts of a CephFS deployment are one-time and which recur?
One-time work includes hardware selection and procurement, cluster deployment with cephadm, pool and file system design, MDS configuration, NFS-Ganesha setup, identity integration, client migration and initial testing. Recurring work includes monitoring, capacity planning, patching, Ceph upgrades to supported releases, snapshot and backup verification, and handling new exports or users. The Ceph releases page lists actively maintained releases and their estimated end-of-life dates, so plan recurring upgrade work around those dates. Ask the provider which items sit in the fixed fee and which fall under a retainer.
Can our internal team build CephFS and NFS exports without a partner?
Yes, if your team has storage engineers who can run cephadm, tune MDS and pools, and debug NFS and Kerberos or LDAP integration. The hardest parts are usually hardware sizing, which the Ceph hardware recommendations say to benchmark before buying, and client migration across many workstations or HPC nodes. Assess your team against those skills first. A partner is most useful when the team lacks capacity, needs a fixed-scope delivery with written acceptance criteria, or wants documented runbooks handed over at the end.
How much time does the client team need to give this project?
The client side usually needs named owners for the network, identity, storage and each group of data. Network staff must confirm the bonded links and switch layout described in the Ceph hardware recommendations. Identity staff must provide the directory and Kerberos settings that NFS clients will use. Data owners must agree on directory layout, quotas, ownership and cutover windows. Ask the provider for a schedule that shows when each of these people is needed, because delays in those reviews often extend the project more than technical work does.
What does the work need from our network, identity and data owners?
The network team needs to provide separate public and cluster networks, bonded links across two switches, and firewall rules for Ceph monitor, OSD and MDS traffic, plus the NFS client subnets. The identity team needs to define which users and groups map to which directories and how NFS clients authenticate. Data owners need to confirm what each share holds, who may read or write it, how long it is retained and what backup expectations apply. Ask the provider to document these inputs in writing before build work starts.
How do NFS exports change the support model?
NFS exports add a layer between CephFS and clients that cannot run Ceph clients. NFS-Ganesha becomes part of the path, so support must cover its configuration, its version alignment with the cluster, export permissions, and failover behavior for the NFS service. Your support staff will need to diagnose both Ceph and NFS symptoms, such as stale handles or permission errors. Ask whether the quote includes runbooks for each export type, monitoring of the NFS service and a named escalation path for client-side problems.
What should we check in MDS sizing and pool design before buying hardware?
Check how many clients and directories will access CephFS, how many metadata operations those clients generate, and whether one active MDS will be enough or whether you need standbys for failover. Ask for a plan that names the metadata pool media, the data pool layout and the expected growth of files. The Ceph hardware recommendations advise enterprise-class SSDs for metadata and sizing memory for peak use rather than quiet periods, so ask the provider to show the benchmark method they will use before any purchase order is placed.
Limits to confirm in your environment before you commit
CephFS and NFS-Ganesha behavior depends on the Ceph release, the client kernel, the NFS protocol you enable and how your scheduler and quotas are set up. The cards below list the items to verify against the Ceph documentation for your release and in your own test cluster before you sign a scope.
Kernel and FUSE client versions
Native kernel CephFS clients ship with your Linux distribution, and their feature set depends on the kernel version rather than on the Ceph release alone. FUSE clients follow the Ceph packages you install on each node. Confirm which client version each distribution provides, which CephFS features that client supports, and whether your Ceph release is compatible with it. Run your real workload, including reconnect after an MDS failover, on each client build you plan to standardize on.
NFS-Ganesha features and protocol versions
NFS exports through NFS-Ganesha are only as capable as the Ganesha build, the NFS protocol versions enabled and the export options you set. Confirm which NFS versions your release supports, how locking and delegations behave for your applications, and whether Kerberos integration fits your identity setup. Test every client OS that mounts the export, because some clients negotiate protocol features differently.
Multiple file systems in one cluster
Running more than one CephFS file system in a cluster affects how you isolate tenants, how many metadata servers you need and how failover is assigned between them. Confirm in the documentation for your release whether multiple file systems are enabled by default, how standby daemons are allocated across them, and what client authentication scoping you can apply to each. Test a failover of one file system while the other stays under load.
Snapshot and quota interactions
Quotas and snapshots interact in ways that affect home directory and scratch policies. Confirm how quota limits are enforced on directories that contain snapshots, whether deleted data still counts toward usage until snapshots expire and how quotas apply to NFS exports served by Ganesha. Ask your team to write down the expected user-visible behavior, then verify it on a test directory with a filled quota and an active snapshot schedule.
HPC scheduler integration
HPC scratch use depends on how your scheduler mounts CephFS on compute nodes, cleans up job directories and handles file ownership across nodes. Confirm which mount method your scheduler can run in prolog and epilog hooks, how credentials are issued to job users and how many concurrent clients your metadata servers handle during large array jobs. Benchmark with a job mix close to production before you size the metadata tier.
Metadata server sizing for your workload
Metadata server memory and CPU needs depend on the number of open files, client count and directory sizes in your data, not only on capacity. Confirm the cache and memory settings for your release, the number of standby daemons you need for failover and when a second active daemon is worth the added complexity. Use benchmarks on your own directory tree rather than relying on generic guidance, and record the results so the sizing decision can be reviewed later.
How existing NFS or home directory data moves onto CephFS
Moving an existing NFS server or file server onto CephFS is a copy and cutover project, not a switch you flip. The first decision is how the data will be copied while users keep working. Most teams run an initial bulk copy with a tool such as rsync or a parallel copy utility, then a final incremental pass during a freeze window in which writes to the old export stop. Confirm with your storage team how much change the source sees per day, because that determines how long the final pass takes and how many incremental passes you need before the freeze is short enough to accept. Preserve ownership, modes, ACLs and extended attributes during every pass, and verify with checksums on a sample of files and with directory-level comparisons on the rest.
Permission and identity mapping is where most home directory migrations fail. CephFS enforces POSIX ownership by numeric UID and GID, so the copy only stays correct if those IDs match the identity source your clients use. If the old server used LDAP, FreeIPA or Active Directory with a different ID scheme, map the old UIDs and GIDs to the new ones before the copy, or the files arrive owned by numbers nobody can log in as. Check how CephFS authorization is granted to clients (through cephx capabilities scoped to a file system and path), and confirm that the NFS gateway's export settings, including squash rules, match what users had before. Test with a small set of accounts, including group-shared project directories and root-squashed service accounts, before any bulk data moves.
Cutover and rollback need to be planned as two separate procedures. For cutover, decide whether clients will remount to a new export path, or whether the old server name will be repointed to the new gateway, and rehearse the mount change on a test host with the same client OS and automount configuration as production. For rollback, keep the old export read-only and intact until users have worked on the new system for an agreed period, and write down the exact steps to repoint clients back, along with who has authority to trigger it. Ask your partner or internal team to state in writing what happens to writes made on CephFS during a rollback, since data written after cutover will not automatically flow back to the old server.
How CephFS is operated after go-live
Once CephFS serves home directories, scratch or application shares, ongoing operations keep metadata servers, clients and capacity within limits, apply supported releases on time, and prove that recovery works. The sequence below lists the recurring work and the evidence that each part is under control.
Monitor MDS and client health
Your operations team watches the active and standby metadata servers, cache pressure, request latency and the session list for each client mount. Alerts go to the on-call rotation with a documented first response for common warnings, such as a slow or unresponsive client holding capabilities. The step is complete when dashboards, alert routes and the first-response runbook have been tested against a planned failover and the team has acknowledged each alert path.
Plan capacity and metadata growth
The storage owner reviews raw and usable capacity per pool, the growth of the file count in the metadata pool, and the trend in directory size and client count. Projections drive decisions on adding OSDs, adjusting quotas on home or project trees, and whether a single active MDS remains sufficient for the workload. The output is a written capacity review with thresholds that trigger purchase or design changes, agreed with the people who own the data.
Schedule release upgrades on supported lines
Platform engineering tracks the Squid line (19.2.x, estimated end of life October 31, 2026) and the Tentacle line (20.2.x, estimated end of life June 1, 2027) on the Ceph releases page. Each upgrade is rehearsed in a non-production cluster using the same cephadm orchestration, client kernels and NFS-Ganesha versions as production, then scheduled in a change window. Confirm the upgrade path with the release notes before work starts, because the end-of-life dates set the deadline for moving to a supported line.
Apply backports and security fixes on cadence
The project publishes periodic backports and security fixes for actively maintained releases. Your team records which point release each cluster runs, reviews new point releases against the CephFS and NFS components you use, and applies them through cephadm after a staging run. The step closes when a patch register shows the running version for every MDS, OSD host, gateway and client group, and any deferred fix has a written reason and an owner.
Review client and export configuration
Operators audit which clients mount CephFS natively through the kernel or FUSE client, which hosts reach the NFS-Ganesha exports, and which client versions are running. They confirm that authentication keys carry only the capabilities each share needs, that export access lists match current group membership, and that clients have been moved off versions no longer covered by the plan. The output is a current inventory of clients, exports and credentials, reviewed on a schedule the owner sets.
Test backup and recovery on a schedule
The recovery owner restores a sample of CephFS snapshots or backed-up directories into an isolated location and checks file counts, permissions and checksums against the source. The test also covers a metadata server failover and a documented procedure for a damaged file system, with timings written down for the business owner. Recovery is only considered proven when a restore has been completed, measured and signed off, and the results have changed the runbook where gaps appeared.
Record findings and adjust the operating plan
After each review, upgrade, or recovery test, the operations lead records incidents, configuration drift, and open risks in one register with owners and due dates. Findings feed back into alert thresholds, capacity triggers and the upgrade calendar. Ask any partner offering ongoing support to define how these reviews are delivered, who signs off on them, and how the register is handed over, so the process continues if the engagement ends.
How DeployOpen scopes, builds and supports CephFS
Each CephFS engagement starts with a written scope that names the pools, metadata server layout, client types and NFS exports before any work begins. The same scope then drives the build on your infrastructure, the handover documentation and, if you choose, an ongoing retainer. The cards below follow that sequence from agreement to operation.
Written scope before any build
Scope and deliverables are agreed in writing before work starts, and most engagements are fixed-scope. For CephFS, the scope should name the file systems, the directories they serve, the expected number of concurrent clients and the failure behavior you expect. A written scope gives you a basis for comparing quotes from your own team or other partners, and it defines what changes would require a new agreement.
Pool and metadata layout
The plan sets the data pool and metadata pool layout, the placement of the CephFS metadata pool on enterprise-class SSDs and how directories map to pools. These choices determine recovery behavior and performance under load, so they are fixed in the design rather than adjusted later. Ask for the reasoning behind each pool and the capacity assumptions behind it.
MDS layout and standby planning
The plan sizes the metadata servers, sets the number of standby daemons and records how failover should behave for your workload. Memory for metadata caching should be sized for peak use, not average use, and confirmed by benchmarking on your hardware. Ask how the plan will change if you later add active metadata servers.
Client access and NFS exports
The plan maps each client type to its access path: native kernel clients, FUSE clients where kernel support is not suitable, and NFS exports through NFS-Ganesha for systems that cannot run Ceph clients. Each path carries its own authentication, network reach and permission model. Ask which clients will mount directly, which will use NFS and how client keys are scoped per directory.
Build on your infrastructure
Implementation runs in your data centers or cloud accounts, using cephadm for deployment and your own identity, network and monitoring tools. The build includes bonded network links across two switches, dedicated drives per OSD and the verification steps agreed in the scope. Ask who holds administrative credentials at the end of the engagement and where configuration is stored.
Documentation, handover and retainers
Handover includes documentation of the layout, client mount procedures, export settings and recovery steps, so your team can operate the file system without the partner. Ongoing support, upgrades and continuous testing are available as retainers when your team wants them. Ask which runbooks are delivered, how upgrades between Ceph releases will be planned and whether the retainer covers out-of-hours response.
