This article covers single-node validation and three-node production deployment with cephadm. For architecture, operations, and functional testing, see Ceph Architecture and Operations. 1. Disk Preparation An OSD can only use a block device (/dev/sdX, a partition, /dev/loopN). 1.1 Inspecting Available Devices 1 2 3 4 5 6 7 lsblk -o

Ceph is a unified distributed storage system that supports block storage (RBD), object storage (RGW), and file storage (CephFS). The official cephadm can orchestrate each daemon as a container (Docker, or Podman + Containerd); see Deploying Ceph in Containers for details. 1. Architecture 1.1 Topology and Data Paths The diagram below shows a common five-node topology (3 MON + 2 MGR + 5 OSD): MONs only need to come in odd numbers, and in a five-node deployment 3 is enough (tolerating one MON failure); 5 MONs tolerate 2 failures, but the metadata overhead is larger, so there is generally no need to run a MON on every machine.

1. Different Kinds of Storage 1.1 File Storage File storage is storage based on files. When accessing data, you need to provide the corresponding lookup path. It is suitable for services such as FTP and NFS. 1.2 Block Storage Block storage splits data into blocks and stores each part separately. When accessing data, the underlying storage software reassembles these scattered pieces.