At least 4 OSD nodes, with 8 OSD disks each, are required.

For OSDs that do not use BlueStore, 1 GB of RAM per terabyte of raw OSD capacity is minimally required for each OSD storage node. 1.5 GB of RAM per terabyte of raw OSD capacity is recommended. During recovery, 2 GB of RAM per terabyte of raw OSD capacity may be optimal.

For OSDs that use BlueStore, first calculate the size of RAM that is recommended for OSDs that do not use BlueStore, then calculate 2 GB plus the size of the BlueStore cache of RAM is recommended for each OSD process, and choose the bigger value of RAM of the two results. Note that the default BlueStore cache is 1 GB for HDD and 3 GB for SSD drives by default. In summary, pick the greater of:

[1GB * OSD count * OSD size]

or

[(2 + BS cache) * OSD count]

1.5 GHz of a logical CPU core per OSD is minimally required for each OSD daemon process. 2 GHz per OSD daemon process is recommended. Note that Ceph runs one OSD daemon process per storage disk; do not count disks reserved solely for use as OSD journals, WAL journals, omap metadata, or any combination of these three cases.

10 Gb Ethernet (two network interfaces bonded to multiple switches).

OSD disks in JBOD configurations.

OSD disks should be exclusively used by SUSE Enterprise Storage 5.5.

Dedicated disk/SSD for the operating system, preferably in a RAID 1 configuration.

If this OSD host will host part of a cache pool used for cache tiering, allocate at least an additional 4 GB of RAM.

For disk performance reasons, we recommend using bare metal for OSD nodes and not virtual machines.

10GB of the DB device for each Terabyte of the OSD capacity (1/100th of the OSD).

Between 500MB and 2GB for the WAL device. The WAL size depends on the data traffic and workload, not on the OSD size. If you know that an OSD is physically able to handle small writes and overwrites at a very high throughput, more WAL is preferred rather than less WAL. 1GB WAL device is a good compromise that fulfills most deployments.

If you intend to put the WAL and DB device on the same disk, then we recommend using a single partition for both devices, rather than having a separate partition for each. This allows Ceph to use the DB device for the WAL operation as well. Management of the disk space is therefore more effective as Ceph uses the DB partition for the WAL only if there is a need for it. Another advantage is that the probability that the WAL partition gets full is very small, and when it is not entirely used then its space is not wasted but used for DB operation.

To share the DB device with the WAL, do not specify the WAL device, and specify only the DB device:

bluestore_block_db_path = "/path/to/db/device"
bluestore_block_db_size = 10737418240
bluestore_block_wal_path = ""
bluestore_block_wal_size = 0

Alternatively, you can put the WAL on its own separate device. In such case, we recommend the fastest device for the WAL operation.

Network bandwidth. The more disks you have in a server, the more data must be transferred via the network card(s) for the disk write operations.

Memory. For optimum performance, reserve at least 2 GB of RAM per terabyte of disk space installed.

Fault tolerance. If the complete server fails, the more disks it has, the more OSDs the cluster temporarily loses. Moreover, to keep the replication rules running, you need to copy all the data from the failed server among the other nodes in the cluster.