Dada la creciente popularidad de Rook, vale la pena hablar sobre sus puntos problemáticos y las dificultades que pueden surgir en el camino.
Sobre mí: Experiencia en la administración de Ceph desde la versión Hammer, fundador de la comunidad. en Telegram.
Para no ser solo palabras vacías, me referiré a las publicaciones aceptadas por Habr (según la calificación) sobre los problemas con Ceph. También me he encontrado con la mayoría de estos problemas. Las referencias al material utilizado están al final del post.
En la publicación sobre Rook mencionamos Ceph no sin motivo: Rook es, en esencia, Ceph envuelto en Kubernetes, lo que significa que hereda todos sus problemas. Comencemos con los problemas de Ceph.
Simplificación de la gestión del clúster.
Una de las ventajas de Rook es la conveniencia de gestionar Ceph a través de Kubernetes.
Sin embargo, Ceph contiene más de 1000 parámetros de configuración, mientras que a través de Rook solo podemos modificar una parte menor de ellos.
Ejemplo en Luminous.
> ceph daemon mon.a config show | wc -l
1401
Rook se posiciona como una forma conveniente de instalar y actualizar Ceph.
No hay problemas para instalar Ceph sin Rook: un playbook de Ansible se puede escribir en 30 minutos, pero hay muchos problemas con la actualización.
Cita de la publicación de Krok.
Ejemplo: comportamiento incorrecto de los tunables de Crush después de actualizar de Hammer a Jewel.
> ceph osd crush show-tunables
{
…
"straw_calc_version": 1,
"allowed_bucket_algs": 22,
"profile": "unknown",
"optimal_tunables": 0,
…
}
Pero incluso dentro de versiones menores pueden surgir problemas.
Ejemplo: La actualización 12.2.6 provoca que el clúster esté en estado de health err y PG supuestamente dañado.
¿No actualizar, esperar y probar? Pero supuestamente estamos utilizando Rook por la conveniencia de las actualizaciones también.
Dificultades en la recuperación ante desastres del clúster en Rook.
Ejemplo: OSD falla arrojando errores, sospechas que el problema está en uno de los parámetros de configuración, quieres cambiar la configuración para un demonio específico, pero no puedes, porque tienes Kubernetes y un DaemonSet.
No hay alternativa. ceph tell osd.Num injectargs no funciona: el OSD está caído.
Dificultades en la depuración.
Para algunas configuraciones y pruebas de rendimiento, es necesario conectarse directamente al socket del demonio OSD. En el caso de Rook, primero debes encontrar el contenedor correcto, luego entrar en él, descubrir la falta de herramientas de depuración y decepcionarte enormemente.
Dificultades en el levantamiento secuencial del OSD.
Ejemplo: OSD cae por OOM, comienza la reequilibración, y después caen los siguientes.
Solución: Levantar OSD uno por uno, esperar a que se incluya completamente en el clúster y luego levantar los siguientes. (Más detalles en el informe Ceph. Anatomía de los desastres).
En el caso de las instalaciones baremetal, esto se hace fácilmente a mano; en el caso de Rook y con un OSD por nodo, no hay problemas especiales, pero surgirán problemas al levantar OSDs de forma secuencial si hay más de 1 OSD por nodo.
Por supuesto, son solucionables, pero estamos llevando Rook para simplificar, y terminamos complicando las cosas.
Complejidad para establecer límites para los demonios ceph.
Para la instalación baremetal de ceph, es bastante fácil calcular los recursos necesarios para el clúster; hay fórmulas y estudios disponibles. Al utilizar CPUs débiles, aún tendrá que realizar una serie de pruebas de rendimiento, conocer qué es Numa, pero aun así, es más sencillo que en Rook.
En el caso de Rook, además de los límites de memoria que se pueden calcular, surge la cuestión de establecer un límite de CPU.
Y aquí tendrá que esforzarse con las pruebas de rendimiento. Si establece límites demasiado bajos, obtendrá un clúster lento; si establece un límite ilimitado, obtendrá un uso activo de CPU durante el rebalanceo, lo que afectará negativamente a sus aplicaciones en kubernetes.
Problemas de interacción de red v1.
Se recomienda utilizar una red de 2x10 Gb para ceph. Una para el tráfico del cliente y otra para las necesidades operativas de ceph (rebalanceo). Si está utilizando ceph en baremetal, esta separación se configura fácilmente; si está utilizando Rook, dividir las redes le generará problemas, ya que no todos los configuraciones de clúster permiten presentar dos redes diferentes a un pod.
Problemas de interacción de red v2.
Si decides no separar las redes, durante el rebalanceo el tráfico de ceph saturará todo el canal y tus aplicaciones en kubernetes se ralentizarán o se caerán. Puedes reducir la velocidad de rebalanceo de ceph, pero entonces, debido al prolongado rebalanceo, obtienes un mayor riesgo de que el segundo nodo se salga del clúster por discos o OOM, y ahí ya tendrás un modo garantizado de solo lectura en el clúster.
Un rebalanceo prolongado significa un largo tiempo de espera para las aplicaciones.
Cita del post Ceph. Anatomía de los desastres.
Rendimiento del clúster de prueba:
Una operación de escritura de 4 KB toma 1 ms, con un rendimiento de 1000 operaciones/segundo en 1 hilo.
Una operación de 4 MB (tamaño del objeto) toma 22 ms, con un rendimiento de 45 operaciones/segundo.
Por lo tanto, cuando falla un dominio de tres, el clúster se encuentra en un estado degradado durante un tiempo, y la mitad de los objetos calientes se dispersa entre diferentes versiones, lo que significa que la mitad de las operaciones de escritura comenzará con una recuperación forzada.
El tiempo de recuperación forzada se calcula aproximadamente: operaciones de escritura en un objeto degradado.
Primero leemos 4 MB en 22 ms, escribimos 22 ms, y luego en 1 ms escribimos 4 Kb de datos propios. En total, sumamos 45 ms en una operación de escritura en un objeto degradado en SSD, cuando el rendimiento estándar era de 1 ms; una caída del rendimiento de 45 veces.
Cuanto mayor sea nuestro porcentaje de objetos degradados, más aterrador se vuelve todo.
Así que la velocidad de reequilibrio es críticamente importante para el correcto funcionamiento del clúster.
Configuraciones específicas de servidores para ceph
ceph a veces necesita un ajuste específico del host.
Ejemplo: configuraciones de sysctl y JumboFrame, algunas de estas configuraciones pueden afectar negativamente a tu carga útil.
La necesidad real de Rook sigue siendo cuestionable
Si estás en la nube, tienes almacenamiento de tu proveedor de nube, lo cual es mucho más conveniente.
Si estás en tus propios servidores, la gestión de ceph será más cómoda sin kubernetes.
¿Alquilas servidores en algún hosting de bajo costo? Entonces te espera mucha diversión con la red, sus latencias y ancho de banda, lo que afecta negativamente a ceph.
Total: La implementación de kubernetes y la implementación de almacenamiento son tareas diferentes con diferentes parámetros y diferentes opciones de soluciones; mezclarlas es hacer una posible compensación peligrosa en favor de uno u otro. Combinar estas soluciones será muy complicado incluso en la etapa de diseño, y aún hay un período de explotación.
Lista de literatura utilizada:
Pero ustedes dicen Ceph... ¿es tan bueno?
Ceph. Anatomía de un desastre
Fuente: habr.com
