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!
Fuente obtenida de: https://blackhold.nusepas.com/2021/12/27/benchmarking-y-tunning-de-servidores-para-ceph/
