Benchmarking y tunning de servidores para ceph

Una vez tenemos una infraestructura de servidores funcionando bajo ceph, nos podemos preguntar ¿Cómo compruebo que mi cluster está funcionando a máximo rendimiento? En este post vamos a ver algunas herramientas para comprobar el rendimiento y tunning que podemos realizar en nuestros servidores para sacarle mas partido a Ceph.

Comprobar la escritura de disco
La forma mas sencilla para hacer un benchmark del disco es usando el comando dd. Para ello vamos a usar el siguiente comando, añadiendo la etiqueta oflag para bypassear la cache del disco:

# dd if=/dev/zero of=here bs=1G count=1 oflag=direct

Esta es la salida de uno de mis servidores, la primera sobre /root y la otra sobre /mnt/pve/ceph_data que es donde está montado un pool de ceph

root@wezen3D:~# dd if=/dev/zero of=here bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 11.1835 s, 96.0 MB/s

root@wezen3D:/mnt/pve/ceph_data# dd if=/dev/zero of=here bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 46.5157 s, 23.1 MB/s

Comprobar la velocidad de la red
Cuando estamos usando ceph, la red es un factor muy importante. En mi actual infraestructura estoy usando puertos ethernet a 1Gbps. En los foros de proxmox muchos de los administradores usan varios puertos ethernet en bonding o incluso puertos de fibra de 10Gbps. Espero que en unas semanas pueda tener funcionando la segunda opción, de mientras todo el tunning que puedo hacer es tocar parámetros y configuración (ahora entraremos en ello).

La herramienta por excelencia para comprobar la velocidad de la red es iperf. Para hacer las pruebas necesitaremos un mínimo de 2 servidores, uno al que le pondremos el iperf como servidor y al otro como cliente. En el ejemplo estoy haciendo el iperf sobre 2 redes distintas, el primero sobre la red vmbr0 (red de comunicación) y el segundo sobre la red vmbr1 que es la que tengo dedicada a la comunicación de los servidores para el ceph (red de datos ceph).

SERVIDOR

root@wezen3D:~# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:  128 KByte (default)
------------------------------------------------------------
[  4] local 10.90.234.174 port 5001 connected with 10.90.234.173 port 50362
[ ID] Interval       Transfer     Bandwidth
[  4] 0.0000-10.0239 sec  1.10 GBytes   941 Mbits/sec
[  5] local 192.168.10.8 port 5001 connected with 192.168.10.7 port 55208
[ ID] Interval       Transfer     Bandwidth
[  5] 0.0000-10.0131 sec  1.15 GBytes   984 Mbits/sec

CLIENTE

root@wezen3C:~# iperf -c 10.90.234.174
------------------------------------------------------------
Client connecting to 10.90.234.174, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 10.90.234.173 port 50362 connected with 10.90.234.174 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3] 0.0000-10.0069 sec  1.10 GBytes   943 Mbits/sec
root@wezen3C:~# iperf -c 192.168.10.8
------------------------------------------------------------
Client connecting to 192.168.10.8, TCP port 5001
TCP window size:  325 KByte (default)
------------------------------------------------------------
[  3] local 192.168.10.7 port 55208 connected with 192.168.10.8 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3] 0.0000-10.0013 sec  1.15 GBytes   985 Mbits/sec

Entre la primera red y la segunda hay un par de diferencias:

La primera que están en dos switches distintos, el de la red de comunicación (vmbr0) es un D-Link DGS-1100-16 y el de la red de datos ceph (vmbr1) es un D-Link GO-SW-16G.

La segunda que la red vmbr1, al ser el switch compatible con jumbo frames, he puesto la MTU a 9000, además de aumentar el tamaño de los paquetes:

root@wezen3D:~# apt -y install ethtool

root@wezen3D:~# ethtool -g eth1
Ring parameters for eth1:
Pre-set maximums:
RX:		4096
RX Mini:	n/a
RX Jumbo:	n/a
TX:		4096
Current hardware settings:
RX:		256
RX Mini:	n/a
RX Jumbo:	n/a
TX:		256

root@wezen3D:~# ethtool -G eth1 rx 4096 tx 4096

root@wezen3D:~# ip link set eth1 mtu 9000

root@wezen3D:~# ip a |grep vmbr1
3: eth1:  mtu 9000 qdisc mq master vmbr1 state UP group default qlen 1000
5: vmbr1:  mtu 9000 qdisc noqueue state UP group default qlen 1000
    inet 192.168.10.8/24 brd 192.168.10.255 scope global vmbr1

en una sola línea

root@wezen3D:~# apt -y install ethtool && ethtool -G eth1 rx 4096 tx 4096 && ip link set eth1 mtu 9000

Para hacer permanente esta configuración la ejecutaremos cuando se levante la interfaz vmbr1 modificando el fichero /etc/network/interfaces:

# vi /etc/network/interfaces
auto vmbr1
iface vmbr1 inet static
        address 192.168.10.8/24
        bridge-ports eth1
        bridge-stp off
        bridge-fd 0
        post-up ethtool -G eth1 rx 4096 tx 4096 && ip link set eth1 mtu 9000

Además tenemos la opción de tunear el comportamiento de los paquetes TCP en nuestro sistema:

root@wezen3D:~# vi /etc/sysctl.conf
net.core.rmem_max = 33554432
net.core.wmem_max = 33554432
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432

Para verificar que se aplican los cambios y aplicarlos:

root@wezen3D:~# sysctl net.ipv4.tcp_window_scaling
root@wezen3D:~# sysctl net.ipv4.tcp_timestamps
root@wezen3D:~# sysctl net.ipv4.tcp_sack
root@wezen3D:~# sysctl -p

En uno de los servidores que apliqué esta configuración hacía que tuviese una respuesta mas lenta. Como siempre, en cada cambio que apliques, recomiendo comprobar el comportamiento y rendimiento del sistema y deshacer los cambios en caso que algo vaya mal.

Ya que estamos tocando el fichero /etc/sysctl.conf otro tunning que podríamos hacer es el de indicarle como debe comportarse la swap. Si hemos montado un cluster de servidores, lo mas seguro es que te hayas hecho con un montón de RAM para tu infraestructura, aún así, al ser sistemas que suelen reiniciarse mas bien poco se van acumulando datos y vemos que el servidor termina swapeando, cosa que hace que vaya todo un poquitín mas lento de lo que realmente nos gustaría. Para ello podemos comprobar la configuración del servidor para ver a qué % debe quedar disponible de RAM para empezar a swapear, esto se hace mirando el fichero:

# cat /proc/sys/vm/swappiness
60

Este valor por defecto es muy alto, así que para ello le pondremos que el 10%

# vi /etc/sysctl.conf
vm.swappiness = 10

A continuación pararemos la swap para pasar lo que esté en la swap a la RAM y la volveremos a activar para permitir volver a usar la swap

# swapoff -a
# swapon -a

Para estos tunnings, doy las gracias a craem por sus recomendaciones :)

Si seguimos con éste artículo de la wiki de ceph, veremos que nos muestran algunos comandos mas para comprobar la salud de nuestro cluster ceph. De momento hago un copy/paste a pelo ya que esta parte aún no la he ejecutado; cosas de estas que ejecutar en un servidor en producción no hacen mucha gracia hehe, espero en los próximos días actualizar esta parte y dar mis propias explicaciones.

Benchmarking de un cluster de almacenamiento Ceph

Ceph includes the rados bench command, designed specifically to benchmark a RADOS storage cluster. To use it, create a storage pool and then use rados bench to perform a write benchmark, as shown below.

The rados command is included with Ceph.

shell> ceph osd pool create scbench 128 128
shell> rados bench -p scbench 10 write --no-cleanup

This creates a new pool named ‘scbench’ and then performs a write benchmark for 10 seconds. Notice the –no-cleanup option, which leaves behind some data. The output gives you a good indicator of how fast your cluster can write data.
Two types of read benchmarks are available: seq for sequential reads and rand for random reads. To perform a read benchmark, use the commands below:

shell> rados bench -p scbench 10 seq
shell> rados bench -p scbench 10 rand

You can also add the -t parameter to increase the concurrency of reads and writes (defaults to 16 threads), or the -b parameter to change the size of the object being written (defaults to 4 MB). It’s also a good idea to run multiple copies of this benchmark against different pools, to see how performance changes with multiple clients.
Once you have the data, you can begin comparing the cluster read and write statistics with the disk-only benchmarks performed earlier, identify how much of a performance gap exists (if any), and start looking for reasons.
You can clean up the benchmark data left behind by the write benchmark with this command:

shell> rados -p scbench cleanup

BENCHMARK A CEPH BLOCK DEVICE
If you’re a fan of Ceph block devices, there are two tools you can use to benchmark their performance. Ceph already includes the rbd bench command, but you can also use the popular I/O benchmarking tool fio, which now comes with built in support for RADOS block devices.

The rbd command is included with Ceph. RBD support in fio is relatively new, therefore you will need to download it from its repository and then compile and install it using_ configure && make && make install_. Note that you must install the librbd-dev development package with apt-get install librbd-dev or yum install librbd-dev before compiling fio in order to activate its RBD support.

Before using either of these two tools, though, create a block device using the commands below:

shell> ceph osd pool create rbdbench 128 128
shell> rbd create image01 --size 1024 --pool rbdbench
shell> sudo rbd map image01 --pool rbdbench --name client.admin
shell> sudo /sbin/mkfs.ext4 -m0 /dev/rbd/rbdbench/image01
shell> sudo mkdir /mnt/ceph-block-device
shell> sudo mount /dev/rbd/rbdbench/image01 /mnt/ceph-block-device

The rbd bench-write command generates a series of sequential writes to the image and measure the write throughput and latency. Here’s an example:

shell> rbd bench-write image01 --pool=rbdbench

Or, you can use fio to benchmark your block device. An example rbd.fio template is included with the fio source code, which performs a 4K random write test against a RADOS block device via librbd. Note that you will need to update the template with the correct names for your pool and device, as shown below.

[global]
ioengine=rbd
clientname=admin
pool=rbdbench
rbdname=image01
rw=randwrite
bs=4k
[rbd_iodepth32]
iodepth=32

Then, run fio as follows:

shell> fio examples/rbd.fio

BENCHMARK A CEPH OBJECT GATEWAY
When it comes to benchmarking the Ceph object gateway, look no further than swift-bench, the benchmarking tool included with OpenStack Swift. The swift-bench tool tests the performance of your Ceph cluster by simulating client PUT and GET requests and measuring their performance.

You can install swift-bench using pip install swift && pip install swift-bench.

To use swift-bench, you need to first create a gateway user and subuser, as shown below:

shell> sudo radosgw-admin user create --uid="benchmark" --display-name="benchmark"
shell> sudo radosgw-admin subuser create --uid=benchmark --subuser=benchmark:swift
--access=full
shell> sudo radosgw-admin key create --subuser=benchmark:swift --key-type=swift
--secret=guessme
shell> radosgw-admin user modify --uid=benchmark --max-buckets=0

Next, create a configuration file for swift-bench on a client host, as below. Remember to update the authentication URL to reflect that of your Ceph object gateway and to use the correct user name and credentials.

[bench]
auth = http://gateway-node/auth/v1.0
user = benchmark:swift
key = guessme
auth_version = 1.0

You can now run a benchmark as below. Use the -c parameter to adjust the number of concurrent connections (this example uses 64) and the -s parameter to adjust the size of the object being written (this example uses 4K objects). The -n and -g parameters control the number of objects to PUT and GET respectively.

shell> swift-bench -c 64 -s 4096 -n 1000 -g 100 /tmp/swift.conf

Although swift-bench measures performance in number of objects/sec, it’s easy enough to convert this into MB/sec, by multiplying by the size of each object. However, you should be wary of comparing this directly with the baseline disk performance statistics you obtained earlier, since a number of other factors also influence these statistics, such as:
– the level of replication (and latency overhead)
– full data journal writes (offset in some situations by journal data coalescing)
– fsync on the OSDs to guarantee data safety
– metadata overhead for keeping data stored in RADOS
– latency overhead (network, ceph, etc) makes readahead more important

TIP: When it comes to object gateway performance, there’s no hard and fast rule you can use to easily improve performance. In some cases, Ceph engineers have been able to obtain better-than-baseline performance using clever caching and coalescing strategies, whereas in other cases, object gateway performance has been lower than disk performance due to latency, fsync and metadata overhead.

CONCLUSION
There are a number of tools available to benchmark a Ceph cluster, at different levels: disk, network, cluster, device and gateway. You should now have some insight into how to approach the benchmarking process and begin generating performance data for your cluster. Good luck!