Soy un gran fan de Ceph, la solución de almacenamiento definida por software de código abierto y masivamente escalable. Su capacidad de auto-reparación y de hacer frente a eventos de clúster que de otro modo serían traumáticos (¿has perdido un nodo? ¡no hay problema!), combinada con la ausencia de puntos únicos de fallo, hace que sea uno de mis favoritos.
A continuación se exponen tres sencillos principios que pueden ayudar a dirigir el diseño de clústeres grandes o pequeños.
Si su principal objetivo son los dólares por megabyte de almacenamiento, entonces, naturalmente, podría gravitar hacia los servidores que pueden tomar el mayor número de discos, y los discos más grandes que puede obtener.
Tenga cuidado aquí. Hay algunas consideraciones con los clusters «estrechos y profundos»:
- Cada nodo contiene un porcentaje mayor de los datos de su cluster. Ejemplo: en un cluster de tres nodos cada nodo contiene el 33% de sus datos. En un clúster de diez nodos, es sólo el 10% por nodo. La pérdida de un solo nodo en un clúster pequeño resultará en una migración de datos sustancialmente mayor, particularmente cuando el clúster comience a llenarse, y potencialmente una interrupción si no ha configurado correctamente los ratios de llenado y casi llenado de su clúster.
- Forzando más tráfico de red a través de menos nodos. Ceph es un sistema de almacenamiento basado en la red, por lo que con menos nodos está forzando una gran cantidad de tráfico de clientes sobre menos NICs. Esto se agrava a medida que aumenta el número de discos por nodo, ya que tienes más OSDs compitiendo por un ancho de banda limitado. Peor aún, durante los eventos de recuperación su tráfico de recuperación compite con la E/S del cliente a través de su red, impactando aún más la experiencia del usuario.
- Para un alto número de discos por nodo, el controlador de disco puede ser un cuello de botella si no tiene suficiente ancho de banda para llevar todos sus discos a toda velocidad.
- Aumenta el tiempo de recuperación y curación cuando se pierde un nodo entero, ya que hay que replicar y recuperar más datos.
El rendimiento del cluster agregado escala muy bien a medida que aumenta el número de nodos. Aquí puede encontrar una comparación de un clúster de 3 nodos frente a uno de 5 nodos con BlueStore.
Si su objetivo es un clúster grande, resista la tentación de empaquetar todos los discos en el menor número de nodos posible.
En resumen:
- Ceph escala muy bien a medida que aumenta el número de nodos.
- Tener muy pocos nodos en el clúster coloca más datos de su clúster en cada nodo, aumentando la E/S de recuperación y los tiempos de recuperación.
- Puede empezar con tan sólo tres nodos, pero si puede permitirse repartir sus discos entre más nodos, es mejor hacerlo.
Sea generoso con la red
No tiene sentido poner medios rápidos en un servidor y luego coartarlos con una conexión de red de 1GbE. Apunte a 10GbE para la producción, como mínimo, y mejor aún busque tener múltiples interfaces de 10Gb enlazadas con Link Aggregation Control Protocol (LACP) para aumentar el ancho de banda. Ceph es un sistema de almacenamiento basado en la red, por lo que algo que no debe faltar en el cluster es el ancho de banda de la red.
Siempre separe su red pública de la red interna del cluster. La red pública llevará el tráfico de clientes, mientras que la red interna llevará el tráfico de heartbeat, replicación y recuperación entre los OSD. Si puede prescindir de las NIC, lleve estas dos redes por interfaces separadas. Separarlas mejora la capacidad de respuesta para los clientes durante los eventos de recuperación, y ayuda a que los eventos de recuperación se completen más rápido ya que la E/S de recuperación no compite con la E/S del cliente en la misma NIC.
Recuerde también que la red interna lleva su tráfico de replicación, por lo que cada escritura en la red pública causará (n-1) escrituras en la red interna, donde n es el número de réplicas. Ceph sólo reconocerá una escritura en el cliente cuando se haya escrito en el diario/WAL de todas las réplicas, por lo que no querrás que las escrituras de replicación se cuelen en la red. Si hace un uso intensivo de pools replicados, considere dimensionar la red de su cluster para que sea n-1 veces mayor que la red pública.
Por último, para la redundancia asegúrese de que está cableando sus nodos a switches redundantes de la parte superior del rack. No querrá perder un nodo entero, o un conjunto de nodos, porque un solo conmutador haya fallado.
En resumen:
- 10Gbit Ethernet para producción como mínimo.
- Separe sus redes públicas y de cluster, idealmente en diferentes NICs pero al menos en diferentes VLANs/subredes.
- Recuerde la regla general (n-1) para datos replicados – considere dimensionar su red interna para que sea n-1 veces mayor que la pública.
- No olvide cablear para la redundancia, y establecer sus enlaces correctamente a nivel de sistema operativo.
- Y como extra: ¡no olvide las tramas jumbo en sus interfaces!
Medios flash para los metadatos de BlueStore.
Ceph reconoce una escritura en el cliente sólo una vez que los datos se han escrito en el registro de escritura anticipada (WAL) del OSD primario y en los WAL de todas las réplicas. Por lo tanto, cuanto más rápida sea la escritura en el WAL, más rápido reconocerá Ceph la escritura, y mejores serán las IOPS de escritura para el cliente.
Sus WALs, e idealmente sus metadatos BlueStore RocksDB, deberían estar en los medios más rápidos que pueda conseguir – SSD como mínimo, y NVMe si es posible. Si está construyendo un clúster con todos los discos duros, considere gastar un poco más por nodo y añadir al menos dos dispositivos de medios rápidos para metadatos y WAL.
Para evitar cuellos de botella en su dispositivo de medios rápidos, considere la velocidad de escritura sostenida de sus discos de datos y compárela con la escritura sostenida de su dispositivo rápido. Si su HDD puede escribir a 100MB/s sostenidos, y su SSD puede manejar 500MB/s sostenidos, entonces más de 4-5 OSDs por SSD y usted será embotellado por el SSD para las escrituras. NVMe es perfecto para este caso de uso, dado que sus velocidades de escritura sostenida pueden llegar a los gigabytes por segundo.
Por último, tenga siempre más de un dispositivo SSD/NVMe por nodo para los metadatos/WAL para asegurarse de que no perderá todos los OSD en el nodo si falla un dispositivo de metadatos.
En resumen:
- Ceph reconoce una escritura a un cliente cuando se ha escrito en el WAL del OSD primario y en los WALs de todas las réplicas. Hace esto para preservar la integridad de sus datos.
- El WAL y el RocksDB deben estar en el medio más rápido que pueda conseguir – idealmente NVMe – para obtener una respuesta al cliente lo más rápido posible.
- No sobresuscriba sus dispositivos rápidos para su WAL/RocksDB. Si lo hace, sólo está trasladando el cuello de botella a su dispositivo rápido.
- Tenga más de un dispositivo rápido para evitar perder todos los OSD en un nodo si su dispositivo WAL falla.
Resumiendo
Ceph es un sistema de almacenamiento definido por software basado en la red que escala horizontalmente de forma excepcional. Los anteriores son sólo algunos principios que le ayudarán a montar un sistema de alto rendimiento: no se quede demasiado estrecho o profundo, mantenga el clúster alimentado con ancho de banda y utilice medios rápidos para sus metadatos y WAL.