CPU
===
-Ceph metadata servers dynamically redistribute their load, which is CPU
-intensive. So your metadata servers should have significant processing power
-(e.g., quad core or better CPUs). Ceph OSDs run the :term:`RADOS` service, calculate
+CephFS metadata servers are CPU intensive, so they should have significant
+processing power (e.g., quad core or better CPUs) and benefit from higher clock
+rate (frequency in GHz). Ceph OSDs run the :term:`RADOS` service, calculate
data placement with :term:`CRUSH`, replicate data, and maintain their own copy of the
-cluster map. Therefore, OSDs should have a reasonable amount of processing power
-(e.g., dual core processors). Monitors simply maintain a master copy of the
-cluster map, so they are not CPU intensive. You must also consider whether the
+cluster map. Therefore, OSD nodes should have a reasonable amount of processing
+power. Requirements vary by use-case; a starting point might be one core per
+OSD for light / archival usage, and two cores per OSD for heavy workloads such
+as RBD volumes attached to VMs. Monitor / manager nodes do not have heavy CPU
+demands so a modest processor can be chosen for them. Also consider whether the
host machine will run CPU-intensive processes in addition to Ceph daemons. For
example, if your hosts will run computing VMs (e.g., OpenStack Nova), you will
need to ensure that these other processes leave sufficient processing power for
Ceph daemons. We recommend running additional CPU-intensive processes on
-separate hosts.
+separate hosts to avoid resource contention.
RAM
===
-Generally, more RAM is better.
+Generally, more RAM is better. Monitor / manager nodes for a modest cluster
+might do fine with 64GB; for a larger cluster with hundreds of OSDs 128GB
+is a reasonable target. There is a memory target for BlueStore OSDs that
+defaults to 4GB. Factor in a prudent margin for the operating system and
+administrative tasks (like monitoring and metrics) as well as increased
+consumption during recovery: provisioning ~8GB per BlueStore OSD
+is advised.
Monitors and managers (ceph-mon and ceph-mgr)
---------------------------------------------
Monitor and manager daemon memory usage generally scales with the size of the
-cluster. For small clusters, 1-2 GB is generally sufficient. For
-large clusters, you should provide more (5-10 GB). You may also want
-to consider tuning settings like ``mon_osd_cache_size`` or
-``rocksdb_cache_size``.
+cluster. Note that at boot-time and during topology changes and recovery these
+daemons will need more RAM than they do during steady-state operation, so plan
+for peak usage. For very small clusters, 32 GB suffices. For
+clusters of up to, say, 300 OSDs go with 64GB. For clusters built with (or
+which will grow to) even more OSDS you should provision
+128GB. You may also want to consider tuning settings like ``mon_osd_cache_size``
+or ``rocksdb_cache_size`` after careful research.
Metadata servers (ceph-mds)
---------------------------
configured to consume. We recommend 1 GB as a minimum for most systems. See
``mds_cache_memory``.
-OSDs (ceph-osd)
----------------
Memory
======
OS operations, and simultaneous request for read and write operations from
multiple daemons against a single drive can slow performance considerably.
-.. important:: Since Ceph has to write all data to the journal before it can
- send an ACK (for XFS at least), having the journal and OSD
- performance in balance is really important!
-
-
Hard Disk Drives
----------------
foregoing example, using the 1 terabyte disks would generally increase the cost
per gigabyte by 40%--rendering your cluster substantially less cost efficient.
-.. tip:: Running multiple OSDs on a single disk--irrespective of partitions--is
- **NOT** a good idea.
+.. tip:: Running multiple OSDs on a single SAS / SATA drive
+ is **NOT** a good idea. NVMe drives, however, can achieve
+ improved performance by being split into two or more OSDs.
.. tip:: Running an OSD and a monitor or a metadata server on a single
- disk--irrespective of partitions--is **NOT** a good idea either.
+ drive is also **NOT** a good idea.
Storage drives are subject to limitations on seek time, access time, read and
write times, as well as total throughput. These physical limitations affect
overall system performance--especially during recovery. We recommend using a
-dedicated drive for the operating system and software, and one drive for each
-Ceph OSD Daemon you run on the host. Most "slow OSD" issues arise due to running
-an operating system, multiple OSDs, and/or multiple journals on the same drive.
-Since the cost of troubleshooting performance issues on a small cluster likely
-exceeds the cost of the extra disk drives, you can optimize your cluster
-design planning by avoiding the temptation to overtax the OSD storage drives.
-
-You may run multiple Ceph OSD Daemons per hard disk drive, but this will likely
-lead to resource contention and diminish the overall throughput. You may store a
-journal and object data on the same drive, but this may increase the time it
-takes to journal a write and ACK to the client. Ceph must write to the journal
-before it can ACK the write.
-
-Ceph best practices dictate that you should run operating systems, OSD data and
-OSD journals on separate drives.
+dedicated (ideally mirrored) drive for the operating system and software, and
+one drive for each Ceph OSD Daemon you run on the host (modulo NVMe above).
+Many "slow OSD" issues not attributable to hardware failure arise from running
+an operating system and multiple OSDs on the same drive. Since the cost of troubleshooting performance issues on a small cluster likely exceeds the cost of the extra disk drives, you can optimize your cluster design planning by avoiding the temptation to overtax the OSD storage drives.
+You may run multiple Ceph OSD Daemons per SAS / SATA drive, but this will likely
+lead to resource contention and diminish the overall throughput.
Solid State Drives
------------------
SSDs do not have moving mechanical parts so they are not necessarily subject to
the same types of limitations as hard disk drives. SSDs do have significant
limitations though. When evaluating SSDs, it is important to consider the
-performance of sequential reads and writes. An SSD that has 400MB/s sequential
-write throughput may have much better performance than an SSD with 120MB/s of
-sequential write throughput when storing multiple journals for multiple OSDs.
+performance of sequential reads and writes.
.. important:: We recommend exploring the use of SSDs to improve performance.
However, before making a significant investment in SSDs, we **strongly
recommend** both reviewing the performance metrics of an SSD and testing the
SSD in a test configuration to gauge performance.
-Since SSDs have no moving mechanical parts, it makes sense to use them in the
-areas of Ceph that do not use a lot of storage space (e.g., journals).
Relatively inexpensive SSDs may appeal to your sense of economy. Use caution.
-Acceptable IOPS are not enough when selecting an SSD for use with Ceph. There
-are a few important performance considerations for journals and SSDs:
-
-- **Write-intensive semantics:** Journaling involves write-intensive semantics,
- so you should ensure that the SSD you choose to deploy will perform equal to
- or better than a hard disk drive when writing data. Inexpensive SSDs may
- introduce write latency even as they accelerate access time, because
- sometimes high performance hard drives can write as fast or faster than
- some of the more economical SSDs available on the market!
-
-- **Sequential Writes:** When you store multiple journals on an SSD you must
- consider the sequential write limitations of the SSD too, since they may be
- handling requests to write to multiple OSD journals simultaneously.
-
-- **Partition Alignment:** A common problem with SSD performance is that
- people like to partition drives as a best practice, but they often overlook
- proper partition alignment with SSDs, which can cause SSDs to transfer data
- much more slowly. Ensure that SSD partitions are properly aligned.
-
-While SSDs are cost prohibitive for object storage, OSDs may see a significant
-performance improvement by storing an OSD's journal on an SSD and the OSD's
-object data on a separate hard disk drive. The ``osd journal`` configuration
-setting defaults to ``/var/lib/ceph/osd/$cluster-$id/journal``. You can mount
-this path to an SSD or to an SSD partition so that it is not merely a file on
-the same disk as the object data.
+Acceptable IOPS are not enough when selecting an SSD for use with Ceph.
+
+SSDs have historically been cost prohibitive for object storage, though
+emerging QLC drives are closing the gap. HDD OSDs may see a significant
+performance improvement by offloading WAL+DB onto an SSD.
One way Ceph accelerates CephFS file system performance is to segregate the
storage of CephFS metadata from the storage of the CephFS file contents. Ceph
provides a default ``metadata`` pool for CephFS metadata. You will never have to
create a pool for CephFS metadata, but you can create a CRUSH map hierarchy for
your CephFS metadata pool that points only to a host's SSD storage media. See
-`Mapping Pools to Different Types of OSDs`_ for details.
+:ref:`CRUSH Device Class<crush-map-device-class>` for details.
Controllers
-----------
-Disk controllers also have a significant impact on write throughput. Carefully,
-consider your selection of disk controllers to ensure that they do not create
-a performance bottleneck.
+Disk controllers (HBAs) can have a significant impact on write throughput.
+Carefully consider your selection to ensure that they do not create
+a performance bottleneck. Notably RAID-mode (IR) HBAs may exhibit higher
+latency than simpler "JBOD" (IT) mode HBAs, and the RAID SoC, write cache,
+and battery backup can substantially increase hardware and maintenance
+costs. Some RAID HBAs can be configured with an IT-mode "personality".
.. tip:: The `Ceph blog`_ is often an excellent source of information on Ceph
performance issues. See `Ceph Write Throughput 1`_ and `Ceph Write
Throughput 2`_ for additional details.
+Benchmarking
+------------
+
+BlueStore opens block devices in O_DIRECT and uses fsync frequently to ensure
+that data is safely persisted to media. You can evaluate a drive's low-level
+write performance using ``fio``. For example, 4kB random write performance is
+measured as follows:
+
+.. code-block:: console
+
+ # fio --name=/dev/sdX --ioengine=libaio --direct=1 --fsync=1 --readwrite=randwrite --blocksize=4k --runtime=300
+
+Write Caches
+------------
+
+Enterprise SSDs and HDDs normally include power loss protection features which
+use multi-level caches to speed up direct or synchronous writes. These devices
+can be toggled between two caching modes -- a volatile cache flushed to
+persistent media with fsync, or a non-volatile cache written synchronously.
+
+These two modes are selected by either "enabling" or "disabling" the write
+(volatile) cache. When the volatile cache is enabled, Linux uses a device in
+"write back" mode, and when disabled, it uses "write through".
+
+The default configuration (normally caching enabled) may not be optimal, and
+OSD performance may be dramatically increased in terms of increased IOPS and
+decreased commit_latency by disabling the write cache.
+
+Users are therefore encouraged to benchmark their devices with ``fio`` as
+described earlier and persist the optimal cache configuration for their
+devices.
+
+The cache configuration can be queried with ``hdparm``, ``sdparm``,
+``smartctl`` or by reading the values in ``/sys/class/scsi_disk/*/cache_type``,
+for example:
+
+.. code-block:: console
+
+ # hdparm -W /dev/sda
+
+ /dev/sda:
+ write-caching = 1 (on)
+
+ # sdparm --get WCE /dev/sda
+ /dev/sda: ATA TOSHIBA MG07ACA1 0101
+ WCE 1 [cha: y]
+ # smartctl -g wcache /dev/sda
+ smartctl 7.1 2020-04-05 r5049 [x86_64-linux-4.18.0-305.19.1.el8_4.x86_64] (local build)
+ Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org
+
+ Write cache is: Enabled
+
+ # cat /sys/class/scsi_disk/0\:0\:0\:0/cache_type
+ write back
+
+The write cache can be disabled with those same tools:
+
+.. code-block:: console
+
+ # hdparm -W0 /dev/sda
+
+ /dev/sda:
+ setting drive write-caching to 0 (off)
+ write-caching = 0 (off)
+
+ # sdparm --clear WCE /dev/sda
+ /dev/sda: ATA TOSHIBA MG07ACA1 0101
+ # smartctl -s wcache,off /dev/sda
+ smartctl 7.1 2020-04-05 r5049 [x86_64-linux-4.18.0-305.19.1.el8_4.x86_64] (local build)
+ Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org
+
+ === START OF ENABLE/DISABLE COMMANDS SECTION ===
+ Write cache disabled
+
+Normally, disabling the cache using ``hdparm``, ``sdparm``, or ``smartctl``
+results in the cache_type changing automatically to "write through". If this is
+not the case, you can try setting it directly as follows. (Users should note
+that setting cache_type also correctly persists the caching mode of the device
+until the next reboot):
+
+.. code-block:: console
+
+ # echo "write through" > /sys/class/scsi_disk/0\:0\:0\:0/cache_type
+
+ # hdparm -W /dev/sda
+
+ /dev/sda:
+ write-caching = 0 (off)
+
+.. tip:: This udev rule (tested on CentOS 8) will set all SATA/SAS device cache_types to "write
+ through":
+
+ .. code-block:: console
+
+ # cat /etc/udev/rules.d/99-ceph-write-through.rules
+ ACTION=="add", SUBSYSTEM=="scsi_disk", ATTR{cache_type}:="write through"
+
+.. tip:: This udev rule (tested on CentOS 7) will set all SATA/SAS device cache_types to "write
+ through":
+
+ .. code-block:: console
+
+ # cat /etc/udev/rules.d/99-ceph-write-through-el7.rules
+ ACTION=="add", SUBSYSTEM=="scsi_disk", RUN+="/bin/sh -c 'echo write through > /sys/class/scsi_disk/$kernel/cache_type'"
+
+.. tip:: The ``sdparm`` utility can be used to view/change the volatile write
+ cache on several devices at once:
+
+ .. code-block:: console
+
+ # sdparm --get WCE /dev/sd*
+ /dev/sda: ATA TOSHIBA MG07ACA1 0101
+ WCE 0 [cha: y]
+ /dev/sdb: ATA TOSHIBA MG07ACA1 0101
+ WCE 0 [cha: y]
+ # sdparm --clear WCE /dev/sd*
+ /dev/sda: ATA TOSHIBA MG07ACA1 0101
+ /dev/sdb: ATA TOSHIBA MG07ACA1 0101
+
Additional Considerations
-------------------------
-You may run multiple OSDs per host, but you should ensure that the sum of the
-total throughput of your OSD hard disks doesn't exceed the network bandwidth
+You typically will run multiple OSDs per host, but you should ensure that the
+aggregate throughput of your OSD drives doesn't exceed the network bandwidth
required to service a client's need to read or write data. You should also
consider what percentage of the overall data the cluster stores on each host. If
the percentage on a particular host is large and the host fails, it can lead to
Networks
========
-Consider starting with a 10Gbps+ network in your racks. Replicating 1TB of data
+Provision at least 10Gbps+ networking in your racks. Replicating 1TB of data
across a 1Gbps network takes 3 hours, and 10TBs takes 30 hours! By contrast,
-with a 10Gbps network, the replication times would be 20 minutes and 1 hour
-respectively. In a petabyte-scale cluster, failure of an OSD disk should be an
+with a 10Gbps network, the replication times would be 20 minutes and 1 hour
+respectively. In a petabyte-scale cluster, failure of an OSD drive is an
expectation, not an exception. System administrators will appreciate PGs
recovering from a ``degraded`` state to an ``active + clean`` state as rapidly
as possible, with price / performance tradeoffs taken into consideration.
and Switches. The added hardware expense may be offset by the operational cost
savings for network setup and maintenance. When using VLANs to handle VM
traffic between the cluster and compute stacks (e.g., OpenStack, CloudStack,
-etc.), it is also worth considering using 10G Ethernet. Top-of-rack routers for
-each network also need to be able to communicate with spine routers that have
-even faster throughput--e.g., 40Gbps to 100Gbps.
+etc.), there is additional value in using 10G Ethernet or better; 40Gb or
+25/50/100 Gb networking as of 2020 is common for production clusters.
+
+Top-of-rack routers for each network also need to be able to communicate with
+spine routers that have even faster throughput, often 40Gbp/s or more.
+
Your server hardware should have a Baseboard Management Controller (BMC).
-Administration and deployment tools may also use BMCs extensively, so consider
+Administration and deployment tools may also use BMCs extensively, especially
+via IPMI or Redfish, so consider
the cost/benefit tradeoff of an out-of-band network for administration.
Hypervisor SSH access, VM image uploads, OS image installs, management sockets,
etc. can impose significant loads on a network. Running three networks may seem
===============
A failure domain is any failure that prevents access to one or more OSDs. That
-could be a stopped daemon on a host; a hard disk failure, an OS crash, a
+could be a stopped daemon on a host; a hard disk failure, an OS crash, a
malfunctioning NIC, a failed power supply, a network outage, a power outage, and
so forth. When planning out your hardware needs, you must balance the
temptation to reduce costs by placing too many responsibilities into too few
| | | * ARM processors specifically may |
| | | require additional cores. |
| | | * Actual performance depends on many |
-| | | factors including disk, network, and |
+| | | factors including drives, net, and |
| | | client throughput and latency. |
| | | Benchmarking is highly recommended. |
| +----------------+-----------------------------------------+
| +----------------+-----------------------------------------+
| | Network | 1x 1GbE+ NICs (10GbE+ recommended) |
+--------------+----------------+-----------------------------------------+
-| ``ceph-mon`` | Processor | - 1 core minimum |
+| ``ceph-mon`` | Processor | - 2 cores minimum |
| +----------------+-----------------------------------------+
-| | RAM | 2GB+ per daemon |
+| | RAM | 2-4GB+ per daemon |
| +----------------+-----------------------------------------+
-| | Disk Space | 10 GB per daemon |
+| | Disk Space | 60 GB per daemon |
| +----------------+-----------------------------------------+
| | Network | 1x 1GbE+ NICs |
+--------------+----------------+-----------------------------------------+
-| ``ceph-mds`` | Processor | - 1 core minimum |
+| ``ceph-mds`` | Processor | - 2 cores minimum |
| +----------------+-----------------------------------------+
| | RAM | 2GB+ per daemon |
| +----------------+-----------------------------------------+
projects / ceph.git / blobdiff