En relación coa crecente popularidade de Rook, gustaríame falar das súas trampas e problemas que che esperan no camiño.
Sobre min: experiencia en administración de ceph desde a versión hammer, fundador da comunidade en telegrama.
Para non ser infundada, voume referir ás publicacións aceptadas por Habr (a xulgar pola valoración) sobre problemas co ceph. Tamén atopei a maioría dos problemas nestas publicacións. As ligazóns ao material empregado están ao final da publicación.
Na publicación sobre Rook, mencionamos ceph por un motivo: Rook é esencialmente ceph envolto en kubernetes, o que significa que herda todos os seus problemas. Comecemos cos problemas de ceph.
Simplifique a xestión do clúster
Unha das vantaxes de Rook é a facilidade de xestionar ceph a través de kuberentes.
Non obstante, ceph contén máis de 1000 parámetros para a configuración, mentres que, ao mesmo tempo, a través de rook só podemos editar unha minoría deles.
Exemplo sobre luminoso
> ceph daemon mon.a config show | wc -l
1401
Rook sitúase como unha forma cómoda de instalar e actualizar ceph
Non hai problemas coa instalación de ceph sen Rook: o libro de xogos ansible escribe en 30 minutos, pero hai moitos problemas coa actualización.
Cita da publicación de Krok
Exemplo: Crush tunables non funciona correctamente despois de actualizar de Hummer a Jewel
> ceph osd crush show-tunables
{
...
"straw_calc_version": 1,
"allowed_bucket_algs": 22,
"profile": "descoñecido",
"optimal_tunables": 0,
...
}
Pero incluso dentro das versións menores hai problemas.
Exemplo: a actualización 12.2.6 leva o clúster ao estado de erro de saúde e PG roto condicionalmente
Non actualizas, esperas e probas? Pero parece que usamos Rook para a comodidade das actualizacións, entre outras cousas.
Complexidade do clúster de recuperación ante desastres en Rook
Exemplo: OSD cae cunha serie de erros aos seus pés. Sospeitas que o problema está nun dos parámetros da configuración, queres cambiar a configuración para un daemon específico, pero non podes porque tes kubernetes e DaemonSet.
Non hai alternativa. ceph tell osd.Num injectargs non funciona - o OSD está mentindo.
Dificultade para depurar
Algunhas configuracións e probas de rendemento requiren conectarse directamente ao socket osd do daemon. No caso de Rook, primeiro cómpre atopar o recipiente desexado, despois entrar nel, atopar as ferramentas que faltan para a depuración e estar moi molesto.
Dificultade para elevar OSD secuencialmente
Exemplo: OSD cae en OOM, comeza o reequilibrio, despois de que caen os seguintes.
Solución: eleve o OSD un a un, agarde ata que estea completamente incluído no clúster e eleve os seguintes. (Máis detalles no informe Ceph. Anatomía dun desastre).
No caso dunha instalación baremetal, isto faise simplemente a man; no caso de Rook e un OSD por nodo, non hai problemas particulares; xurdirán problemas coa elevación alternativa se OSD > 1 por nodo.
Por suposto, pódense resolver, pero usamos Rook para simplificar as cousas, pero conseguir máis complexidade.
Dificultade para seleccionar límites para os demos ceph
Para unha instalación sen metal de ceph, é bastante sinxelo calcular os recursos necesarios para un clúster: hai fórmulas e hai investigacións dispoñibles. Se estás a usar unha CPU débil, aínda terás que realizar algunhas probas de rendemento para descubrir o que é Numa, pero aínda así é máis fácil que Rook.
No caso de Rook, ademais dos límites de memoria que se poden calcular, tes a cuestión de establecer un límite de CPU.
E aquí terás que traballar duro coas probas de rendemento. Se baixas os límites, obterás un clúster lento; se estableces unlim, obterás un uso activo da CPU durante o reequilibrio, o que terá un mal efecto nas túas aplicacións en kubernetes.
Problemas de rede v1
Para ceph recoméndase utilizar unha rede de 2x10 GB. Un para o tráfico de clientes, o outro para as necesidades do servizo ceph (reequilibrio). Se vives con ceph en baremetal, entón esta división pódese configurar facilmente, se vives con Rook, entón a división por redes causarache problemas, debido ao feito de que non todas as configuracións do clúster che permiten alimentar dúas redes diferentes ao pod. .
Problemas de rede v2
Se rexeitas separar as redes, ao reequilibrar, o tráfico ceph atascará toda a canle e as túas aplicacións en kubernetes ralentizarán ou fallarán. Podes reducir a velocidade do reequilibrio de ceph, pero debido ao longo reequilibrio tes un maior risco de que o segundo nodo caia do clúster a través de discos ou OOM, e xa hai unha só lectura garantida para o clúster.
Reequilibrio longo - longos retrasos de aplicación
Cita da publicación de Ceph. Anatomía dun desastre.
Proba o rendemento do clúster:
Unha operación de escritura de 4 KB de tamaño leva 1 ms, o rendemento é de 1000 operacións/segundo en 1 fío.
Unha operación de 4 MB (tamaño do obxecto) leva 22 ms, o rendemento é de 45 operacións/segundo.
En consecuencia, cando falla un dominio de cada tres, o clúster está en estado degradado durante algún tempo e a metade dos obxectos quentes distribúense en diferentes versións, entón a metade das operacións de escritura comezarán cunha recuperación forzada.
Calculamos aproximadamente o tempo de recuperación forzada: operacións de escritura nun obxecto degradado.
Primeiro lemos 4 MB en 22 ms, escribimos 22 ms e despois en 1 ms escribimos 4 KB de datos reais. Un total de 45 ms por operación de escritura nun obxecto degradado nun SSD, cando o rendemento estándar era de 1 ms - unha caída de rendemento de 45 veces.
Canto maior sexa a porcentaxe de obxectos degradados que temos, peor se fai todo.
Resulta que a velocidade de reequilibrio é fundamental para o correcto funcionamento do clúster.
Configuración específica do servidor para ceph
ceph pode requirir axustes específicos do host.
Exemplo: configuración sysctl e o mesmo JumboFrame, algunhas destas configuracións poden afectar negativamente á súa carga útil.
A necesidade real de Rook segue sendo cuestionada
Se estás na nube tes almacenamento do teu provedor de nube, o que é moito máis cómodo.
Se estás nos teus propios servidores, xestionar ceph será máis cómodo sen kubernetes.
Alugas servidores dalgún hospedaxe de baixo custo? Entón vaise divertir moito coa rede, os seus atrasos e ancho de banda, o que claramente afecta negativamente a ceph.
Total: Implementar kuberentes e implementar o almacenamento son tarefas diferentes con diferentes entradas e diferentes opcións de solución; mesturalos significa facer unha compensación posiblemente perigosa polo ben dun ou doutro. Será moi difícil combinar estas solucións mesmo na fase de deseño, e aínda hai un período de funcionamento.
Lista de literatura usada:
Pero dis que Ceph... é realmente tan bo?
Ceph. Anatomía dun desastre
Fonte: www.habr.com