En relación con la creciente popularidad de Rook, quiero hablar sobre sus trampas y los problemas que le esperan en el camino.
Acerca de mí: experiencia de administración de Ceph con la versión hammer, fundador de la comunidad
t.me/ceph_ru en telegramas.
Para no ser infundado, me referiré a publicaciones aceptadas por Habr (a juzgar por la calificación) sobre problemas con ceph. Encontré la mayoría de los problemas en estas publicaciones también. Enlaces al material utilizado al final de la publicación.
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. Comenzaremos con problemas cefálicos.
Simplifique la gestión de clústeres
Una de las ventajas de Rook es la conveniencia de administrar ceph a través de kuberentes.
Sin embargo, ceph contiene más de 1000 parámetros para afinar, al mismo tiempo a través de la torre podemos editar solo una pequeña parte de ellos.
Ejemplo luminoso
> ceph daemon mon.a config show | wc -l
1401
Rook se posiciona como una forma conveniente de instalar y actualizar cephNo hay problemas con la instalación de ceph sin Rook: el libro de jugadas se escribe en 30 minutos, pero hay muchos problemas con la actualización de los problemas.
Cita de la publicación de KrokEjemplo: operación incorrecta de los elementos ajustables después de actualizar de hummer a joya
> ceph osd crush show-tunables
{
...
"Straw_calc_version": 1,
"Allowed_bucket_algs": 22,
"Perfil": "desconocido",
Óptimas optimizables: 0,
...
}
Pero incluso dentro de las versiones menores hay problemas.
Ejemplo: la actualización 12.2.6 lleva el clúster al error de salud y PG condicionalmente roto
ceph.com/releases/v12-2-8-releasedNo actualizar, esperar y probar? Pero también utilizamos Rook para la comodidad de las actualizaciones.
La complejidad del clúster de recuperación ante desastres en Rook
Ejemplo: OSD bloquea errores de erupción bajo sus pies. Sospecha que el problema está en uno de los parámetros en la configuración, desea cambiar la configuración para un demonio específico, pero no puede, porque tiene kubernetes y DaemonSet.
No hay alternativa ceph tell osd. Num injectargs no funciona - OSD miente.
Complejidad de depuración
Para algunas configuraciones y pruebas de rendimiento, debe conectarse directamente al zócalo del demonio osd. En el caso de Rook, primero debe encontrar el contenedor correcto, luego entrar en él, encontrar los que faltan para la optimización de depuración y estar muy molesto.
La dificultad de elevar secuencialmente el OSD
Ejemplo: OSD cae en OOM, comienza el reequilibrio, luego el siguiente otoño.
Solución: aumente el OSD de uno en uno, espere a que se incluya por completo en el clúster y aumente los siguientes. (Más en el informe de Ceph. Anatomy of a disaster.)
En el caso de la instalación de metal desnudo, esto se hace simplemente a mano, en el caso de Rook y una OSD en el nodo no hay problemas particulares, ocurrirán problemas con el levantamiento sucesivo si OSD> 1 en el nodo.
Por supuesto, son solucionables, pero llevamos Rook para simplificar, pero tenemos complicaciones.
La dificultad de seleccionar límites para ceph demonios
Para instalaciones cefálicas de metal desnudo, es bastante fácil calcular los recursos necesarios por conglomerado: hay fórmulas y hay estudios. Cuando se utilizan CPU débiles, aún debe realizar una serie de pruebas de rendimiento para descubrir qué es Numa, pero sigue siendo más simple 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 el límite de la CPU.
Y luego tienes que sudar con las pruebas de rendimiento. En caso de subestimar los límites, obtendrá un clúster lento, en el caso de no establecer límites, obtendrá un uso activo de la CPU con reequilibrio, lo que afectará gravemente sus aplicaciones en kubernetes.
Problemas de red v1
Para ceph, se recomienda usar una red de 2x10gb. Uno para tráfico de clientes, otro para uso de oficina ceph (reequilibrio). Si vives con ceph en baremetal, entonces esta separación es fácil de configurar, si vives con Rook, entonces con la separación por redes te causará problemas, porque lejos de cada configuración de clúster te permite alimentar dos redes diferentes a pod.
Problemas de red v2
Si se niega a compartir redes, con el reequilibrio, el tráfico ceph obstruirá todo el canal y sus aplicaciones en kubernetes se ralentizarán o se bloquearán. Puede reducir la tasa de reequilibrio cefálico, pero luego, debido al reequilibrio prolongado, aumenta el riesgo de que el segundo nodo se caiga del clúster en discos u OOM, y ya se garantiza la lectura solo en el clúster.
Reequilibrio largo: frenos de aplicación larga
Cita de una publicación de Ceph. Anatomía del desastre.Prueba de rendimiento del clúster:
Una operación de escritura de 4 KB toma 1 ms, rendimiento 1000 operaciones / segundo en 1 flujo.
Una operación de 4 MB de tamaño (tamaño de objeto) toma 22 ms, rendimiento 45 operaciones / segundo.
Por lo tanto, cuando uno de los tres dominios falla, el clúster se encuentra en un estado degradado durante algún tiempo y la mitad de los objetos calientes se propagarán según las diferentes versiones, luego la mitad de las operaciones de escritura comenzarán 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 1 ms escribimos 4 KB de datos en sí. En total, 45 ms para una operación de escritura en un objeto degradado en el SSD, cuando el rendimiento estándar fue de 1 ms, una caída de rendimiento de 45 veces.
Cuanto más tengamos el porcentaje de objetos degradados, peor será.
Resulta que la tasa de reequilibrio es crítica para el correcto funcionamiento del clúster.
Configuraciones específicas del servidor para ceph
ceph puede necesitar 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 una torre sigue en cuestión
Si está en la nube, tiene almacenamiento de su proveedor de nube, lo cual es mucho más conveniente.
Si está en sus servidores, entonces la administración de ceph será más conveniente sin kubernetes.
¿Alquila un servidor en algún alojamiento de bajo costo? Entonces encontrará mucha diversión con la red, sus retrasos y ancho de banda, lo que obviamente afecta negativamente a ceph.
Total: La introducción de kuberentes y la introducción del repositorio son tareas diferentes con diferentes opciones introductorias y diferentes soluciones: mezclarlas y luego hacer una compensación peligrosa por el bien de esto o aquello. Combinar estas soluciones será muy difícil incluso en la etapa de diseño, y todavía hay un período de operación.
Lista de literatura utilizada:
Post # 1 Pero tú dices Ceph ... pero ¿es bueno?
Puesto # 2 Ceph. Anatomía del desastre