Release Notes

Dell PowerEdge R730xd Performance and Sizing Guide for Red Hat Ceph Storage - A Dell Red Hat Technical White Paper 27
The file is divided in two sections: cluster and benchmarks . The first describes the cluster with the most
essential data. The
user specified here is a system user which needs to be present on all nodes and needs
passwordless sudo access without the requirement for an interactive terminal. The
head nodes, clients
and
osds are listed by their domain name of IP address. The MONs are specified in a syntax that
distinguishes between a front-end and back-end network for Ceph. This is not used further here as the
cluster setup is not done via CBT. This is expressed with the
use_existing parameter set to true . The
clusterid is provided based on what is described in the
ceph.conf file. The tmp_dir v ariable specifies a
directory on all the nodes that CBT access under
user in which intermediate data is stored, mostly
consisting of benchmark telemetry. The
pool_profiles is a YAML list item which allows the user to employ
different RADOS pool configurations referred to by name in the benchmark descriptions.
benchmarks enlists various benchmark runs (the amount of repeated execution is specified in iterations in
the
clusters section) that are processed in a sequential order. The name refers to a benchmark driver that
ships with CBT. In this example,
radosbench is the driver that executes low-level tests on the core librados
layer of Ceph by using the
rados utility. The parameters specified below are directly handed over to the
rados bench call executed on the client systems, whereas list items such as
op_sizes , concurrent_ops or
osd_ra each trigger individual runs with one of their entries as the respective parameters. As a result, in
the example above, the benchmark configuration will launch 4 subsequent benchmarks using the
rados
utility, each with a different
op_size parameter. The description of these parameters can be found in the
help output of the
rados binary.
The same set of tunables were applied throughout the benchmarks. Ansible-ceph basically ships with the
most recommended tunings out of the box. In this benchmark, adjustments to ceph.conf were made only
to reflect the cluster setup in the test bed; which is configuration of Front-End and Back-End network and
the journal size.
The
ceph.conf used throughout this benchmark is found at https://github.com/red-hat-storage/dell-
ceph-psg.
A functionality that CBT currently does not provide is to sequence the repeated benchmark execution with
an increasing amount of parallelism in each run. The goal of this benchmark is also to find the high water
mark of the cluster’s aggregated throughput, which is the point beyond which the performance increase is
becoming zero or negative. Each benchmark scenario is run in 10 iterations, with the first executing the
benchmark only from a single client, the second iteration with two clients, the third with three clients in
parallel and so on. To achieve this, multiple instances of a benchmark job file were created; each with an
increasing amount of clients. The benchmarks were then started with CBT individually by looping over a
continuous set of job files.
The job specifications can be found at https://github.com/red-hat-storage/dell-ceph-psg. The structure
of the job files are as follows:
 Common configuration
o Write benchmarks, followed by sequential read benchmarks
o Tested block sizes: 4M, 1M, 512K and 128K
o Execution of each benchmark run: 5 minutes
o 128 concurrent threads per client
o 1 rados bench instance per client
o Pool name: cbt-librados
 rados_ec_seq_suite_<1..10>_clients.yml
o librados-level benchmark on an erasure-coded pool
o erasure-coding scheme used was 3:2 using the ISA driver