Ceph Fundamentals
Ceph is an open-source distributed storage system that provides object, block, and file storage in a single unified cluster. It scales horizontally by spreading data across commodity hardware and self-heals when drives or nodes fail.
itStorage, backup, and data protection | OpenSkills.info
Intro
Ceph Fundamentals
Ceph turns a group of servers and storage devices into one distributed storage system. It can present block devices, a shared file system, and object APIs from the same underlying cluster.
That range is useful, but it can hide the central idea. Ceph stores data as objects in RADOS, its distributed object store. The block, file, and object services translate client requests into RADOS operations.
Use this mental model:
applications
-> RBD block devices | CephFS files | RGW object APIs
-> RADOS pools and placement groups
-> OSD daemons and storage devices
Ceph is not a storage appliance with one controller. Clients obtain a cluster map from monitors. They use that map and the CRUSH algorithm to calculate where data belongs. They then communicate with the responsible OSD daemons.
Why Ceph exists
A single storage server has finite capacity and creates a failure boundary. Traditional shared-storage designs often place controllers in the data path. Those controllers must handle every request and remain available.
Ceph distributes storage and placement work across the cluster. You add capacity by adding OSDs and hosts. CRUSH changes the placement calculation when the topology changes, so the cluster can move affected placement groups instead of consulting a central object-location table.
This design targets large, fault-tolerant storage systems. It also creates operational work. You must plan failure domains, networks, media, capacity, protection, upgrades, monitoring, and recovery.
The RADOS foundation
RADOS is Ceph's reliable, autonomic distributed object store. All client interfaces ultimately store data as RADOS objects in pools.
An object has an identifier, binary data, and metadata. OSD daemons store those objects and handle reads, writes, replication, recovery, and scrubbing.
A pool is a logical partition of the RADOS object space. A pool defines placement and protection settings. It also forms an authorization boundary for many client capabilities.
Ceph maps every object to a placement group. A placement group collects many objects into a unit that Ceph can place, peer, recover, and rebalance. CRUSH then maps the placement group to an ordered set of OSDs.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://docs.ceph.com/en/latest/releases/tentacle/
Supports
- Tentacle as Ceph's twentieth stable release
- Version 20.2.2 release date of June 16, 2026
- Current update recommendation for Tentacle users
- https://docs.ceph.com/en/tentacle/architecture/
Supports
- RADOS as the distributed object-store foundation
- Monitor, OSD, Manager, and Metadata Server responsibilities
- Cluster maps, monitor quorum, and direct client-to-OSD data access
- Object-to-pool-to-placement-group-to-OSD mapping
- CRUSH placement and failure-domain hierarchy
- Replication, erasure coding, peering, recovery, and scrubbing
- RBD, CephFS, RGW, and librados client interfaces
- Cephx authentication scope and limits
- https://docs.ceph.com/en/tentacle/start/beginners-guide/
Supports
- Introductory relationship among daemons, maps, pools, placement groups, and client interfaces
- Pool-level data-protection model
- Manager module and monitor responsibilities
- https://docs.ceph.com/en/tentacle/rados/operations/crush-map/
Supports
- CRUSH device and bucket hierarchy
- Failure-domain types such as host and rack
- CRUSH rules that select replica or chunk locations
- https://docs.ceph.com/en/tentacle/rados/operations/placement-groups/
Supports
- Placement groups as subsets of pools
- Mapping RADOS objects into placement groups and placement groups onto OSDs
- Placement-group autoscaling and distribution considerations
- https://docs.ceph.com/en/tentacle/rados/operations/pools/
Supports
- Pool creation and management
- Replicated and erasure-coded pool behavior
- Pool application associations, quotas, and settings
- https://docs.ceph.com/en/tentacle/rbd/
Supports
- RBD thin-provisioned block images
- Kernel and virtual-machine integration
- Snapshots and layering
- https://docs.ceph.com/en/tentacle/cephfs/
Supports
- CephFS as a POSIX-compatible file system
- MDS handling of file-system metadata
- Kernel and Filesystem in Userspace client access
- https://docs.ceph.com/en/tentacle/radosgw/
Supports
- RGW as Ceph's object gateway
- Amazon S3 and OpenStack Swift API compatibility
- Gateway deployment and object-service administration scope
- https://docs.ceph.com/en/tentacle/cephadm/install/
Supports
- Cephadm host requirements and bootstrap behavior
- Initial Monitor and Manager deployment
- Host, monitor, OSD, and client expansion path
- Typical three-monitor or five-monitor production layout
- Time-synchronization and container-runtime requirements
- https://docs.ceph.com/en/tentacle/rados/operations/health-checks/
Supports
- Named monitor and manager health checks
- Health-check identifiers and subsystem conditions
- Clock, capacity, daemon, and placement-group health reporting
- https://docs.ceph.com/en/tentacle/rados/operations/monitoring-osd-pg/
Supports
- OSD up, down, in, and out state dimensions
- Placement-group state including active, clean, degraded, peering, and recovering
- Cluster status and placement-group monitoring concepts
- https://docs.ceph.com/en/tentacle/rados/operations/user-management/
Supports
- Ceph client identities and keyrings
- Authentication and authorization capabilities
- Pool access and least-privilege client administration
- Cephx limits for human and front-end authentication
- https://docs.ceph.com/en/tentacle/start/hardware-recommendations/
Supports
- CPU, memory, media, and network planning factors
- Failure-domain planning and host capacity concentration
- Dedicated device recommendations for OSD data
- Recovery traffic and aggregate network considerations
