En relación con la creciente popularidad de Rook, me gustaría hablar sobre sus trampas y problemas que le esperan en el camino.
Acerca de mí: Experiencia en administración de ceph de la versión Hammer, fundador de la comunidad. en telegrama.
Para no ser infundado, me referiré a las publicaciones aceptadas por Habr (a juzgar por la calificación) sobre problemas con ceph. También encontré la mayoría de los problemas en estas publicaciones. Los enlaces al material utilizado se encuentran al final del post.
En la publicación sobre Rook, mencionamos ceph por una razón: Rook es esencialmente ceph envuelto en kubernetes, lo que significa que hereda todos sus problemas. Comencemos con los problemas ceph.
Simplifique la gestión de clústeres
Una de las ventajas de Rook es la facilidad de gestionar ceph a través de kuberentes.
Sin embargo, ceph contiene más de 1000 parámetros para configuración, mientras que a través de rook solo podemos editar una minoría de ellos.
Ejemplo de Luminoso
> espectáculo de configuración ceph daemon mon.a | baño -l
1401
Rook se posiciona como una forma conveniente de instalar y actualizar ceph
No hay problemas con la instalación de ceph sin Rook: el libro de jugadas de Ansible se escribe en 30 minutos, pero hay muchos problemas con la actualización.
Cita de la publicación de Krok
Ejemplo: Crush Tunables no funciona correctamente después de actualizar de Hummer a Jewel
> ceph osd Crush show-tunables
{
...
"straw_calc_version": 1,
"allowed_bucket_algs": 22,
"perfil": "desconocido",
"optimal_tunables": 0,
...
}
Pero incluso en las versiones menores hay problemas.
Ejemplo: la actualización 12.2.6 lleva el clúster al estado de error de salud y PG condicionalmente roto
¿No actualizar, esperar y probar? Pero parece que utilizamos Rook para facilitar las actualizaciones, entre otras cosas.
Complejidad del clúster de recuperación ante desastres en Rook
Ejemplo: OSD cae con una racha de errores a sus pies. Sospechas que el problema está en uno de los parámetros de la configuración, quieres cambiar la configuración de un demonio específico, pero no puedes porque tienes kubernetes y DaemonSet.
No hay alternativa. ceph le dice a osd.Num injectargs que no funciona: el OSD miente.
Depuración de dificultad
Algunas configuraciones y pruebas de rendimiento requieren conectarse directamente al socket osd del demonio. En el caso de Rook, primero necesitas encontrar el contenedor deseado, luego entrar en él, encontrar las herramientas que faltan para depurar y enojarte mucho.
Dificultad para subir OSD secuencialmente
Ejemplo: OSD cae en OOM, comienza el reequilibrio, después del cual caen los siguientes.
Solución: levante los OSD uno a la vez, espere hasta que esté completamente incluido en el clúster y levante los siguientes. (Más detalles en el informe Ceph. Anatomía de un desastre).
En el caso de una instalación baremetal, esto se hace simplemente a mano; en el caso de Rook y un OSD por nodo, no hay problemas particulares; surgirán problemas con la elevación alternativa si OSD > 1 por nodo.
Por supuesto, se pueden resolver, pero usamos Rook para simplificar las cosas, pero obteniendo más complejidad.
Dificultad para seleccionar límites para los demonios ceph.
Para una instalación básica de ceph, es bastante fácil calcular los recursos necesarios para un clúster: existen fórmulas y hay investigaciones disponibles. Si estás usando una CPU débil, aún tendrás que ejecutar algunas pruebas de rendimiento para descubrir qué es Numa, pero sigue siendo más fácil que Rook.
En el caso de Rook, además de los límites de memoria que se pueden calcular, existe la cuestión de establecer un límite de CPU.
Y aquí tendrás que trabajar duro con las pruebas de rendimiento. Si reduce los límites, obtendrá un clúster lento; si configura unlim, obtendrá un uso activo de la CPU durante el reequilibrio, lo que tendrá un efecto negativo en sus aplicaciones en Kubernetes.
Problemas de red v1
Para ceph se recomienda utilizar una red de 2x10 GB. Uno para el tráfico de clientes y el otro para las necesidades del servicio ceph (reequilibrio). Si vive con ceph en baremetal, entonces esta división se configura fácilmente, si vive con Rook, entonces la división por redes le causará problemas, debido al hecho de que no todas las configuraciones de clúster le permiten alimentar dos redes diferentes al pod. .
Problemas de red v2
Si se niega a separar las redes, al reequilibrar, el tráfico ceph obstruirá todo el canal y sus aplicaciones en Kubernetes se ralentizarán o bloquearán. Puede reducir la velocidad del reequilibrio ceph, pero luego, debido al largo reequilibrio, aumenta el riesgo de que el segundo nodo se caiga del clúster a través de discos o OOM, y ya hay una lectura garantizada de solo para el clúster.
Reequilibrio prolongado: retrasos prolongados en la aplicación
Cita de la publicación de Ceph. Anatomía de un desastre.
Rendimiento del clúster de prueba:
Una operación de escritura de 4 KB de tamaño tarda 1 ms, el rendimiento es de 1000 operaciones/segundo en 1 subproceso.
Una operación de 4 MB (tamaño de objeto) tarda 22 ms, el rendimiento es de 45 operaciones/segundo.
En consecuencia, cuando uno de cada tres dominios falla, el clúster permanece en un estado degradado durante algún tiempo y la mitad de los objetos activos se distribuyen en diferentes versiones, entonces la mitad de las operaciones de escritura comenzarán con una recuperación forzada.
Calculamos aproximadamente el tiempo de recuperación forzada: 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 reales. Un total de 45 ms por operación de escritura en un objeto degradado en un SSD, cuando el rendimiento estándar era de 1 ms, una caída del rendimiento de 45 veces.
Cuanto mayor es el porcentaje de objetos degradados que tenemos, peor se vuelve todo.
Resulta que la velocidad de reequilibrio es crítica para el correcto funcionamiento del cluster.
Configuración de servidor específica para ceph
ceph puede requerir un ajuste de host específico.
Ejemplo: configuración de sysctl y el mismo JumboFrame, algunas de estas configuraciones pueden afectar negativamente su carga útil.
La verdadera necesidad de Rook sigue en duda
Si estás en la nube tienes almacenamiento de tu proveedor de nube, lo cual es mucho más conveniente.
Si está en sus propios servidores, administrar ceph será más conveniente sin kubernetes.
¿Alquilas servidores de algún hosting low cost? Entonces te divertirás mucho con la red, sus retrasos y el ancho de banda, lo que claramente afecta negativamente a ceph.
Total: La implementación de kuberentes y la implementación del almacenamiento son tareas diferentes con diferentes entradas y diferentes opciones de solución; mezclarlas significa hacer una compensación posiblemente peligrosa por el bien de uno u otro. Combinar estas soluciones será muy difícil incluso en la fase de diseño, y todavía queda un período de funcionamiento.
Lista de literatura usada:
Pero dices Ceph... ¿realmente es tan bueno?
Cefe. Anatomía de un desastre
Fuente: habr.com