Ya hablamos sobre cómo / por qué nos gusta Rook: en gran medida, simplifica el trabajo con almacenamiento en clústeres de Kubernetes. Sin embargo, con esta simplicidad surgen ciertas dificultades. Esperamos que el nuevo material ayude a comprender mejor tales dificultades incluso antes de que se manifiesten.
Y para leerlo fue más interesante, comenzamos con las
consecuencias de un problema hipotético en el grupo.
"¡Todo se ha ido!"
Imagine que una vez que configuró y lanzó Rook en el clúster de su K8, estaba satisfecho con su trabajo, pero en algún momento "maravilloso" sucede lo siguiente:
- Las nuevas vainas no pueden montar Ceph RBD.
- Los comandos como
lsblk y df no funcionan en los hosts Kubernetes. Esto significa automáticamente "algo está mal" con las imágenes RBD montadas en el nodo. No puedo leerlos, lo que indica la inaccesibilidad de los monitores ... - Sí, no hay monitores operativos en el clúster. Además, ni siquiera hay vainas con OSD, ni vainas de MGR.
¿Cuándo se lanzó el
rook-ceph-operator pod
rook-ceph-operator ? No hace mucho tiempo que fue desplegado. Por qué Rook-operator decidió crear un nuevo clúster ... ¿Cómo podemos restaurar el clúster y los datos que contiene?
Para comenzar, vamos por un camino
más largo e interesante, después de haber llevado a cabo una investigación reflexiva sobre los "aspectos internos" de Rook y una restauración paso a paso de sus componentes. Por supuesto, hay una forma correcta
más corta : usar copias de seguridad. Como saben, los administradores se dividen en dos tipos: los que no hacen copias de seguridad y los que ya los hacen ... Pero más sobre esto después de la investigación.
Un poco de práctica o un largo camino
Echa un vistazo y restaura los monitores
Entonces, echemos un vistazo a la lista de mapas de configuración: hay
rook-ceph-config y
rook-config-override necesarios para la copia de seguridad. Aparecen tras la implementación exitosa del clúster.
NB : en las nuevas versiones, después de la adopción de este PR , ConfigMaps ha dejado de ser un indicador del éxito de una implementación de clúster.Para realizar más acciones, necesitamos un reinicio completo de todos los servidores que tienen imágenes RBD montadas (
ls /dev/rbd* ). Debe hacerse a través de sysrq (o "a pie" al centro de datos). Este requisito es causado por la tarea de desconectar los RBD montados, para lo cual un reinicio regular no funcionará (intentará sin éxito desmontarlos normalmente).
El teatro comienza con una percha, y el grupo Ceph comienza con monitores. Miremos a ellos.
Rook monta las siguientes entidades en el pod de monitor:
Volumes: rook-ceph-config: Type: ConfigMap (a volume populated by a ConfigMap) Name: rook-ceph-config rook-ceph-mons-keyring: Type: Secret (a volume populated by a Secret) SecretName: rook-ceph-mons-keyring rook-ceph-log: Type: HostPath (bare host directory volume) Path: /var/lib/rook/kube-rook/log ceph-daemon-data: Type: HostPath (bare host directory volume) Path: /var/lib/rook/mon-a/data Mounts: /etc/ceph from rook-ceph-config (ro) /etc/ceph/keyring-store/ from rook-ceph-mons-keyring (ro) /var/lib/ceph/mon/ceph-a from ceph-daemon-data (rw) /var/log/ceph from rook-ceph-log (rw)
Veamos cuál es el secreto de
rook-ceph-mons-keyring :
kind: Secret data: keyring: LongBase64EncodedString=
Decodificamos y obtenemos el llavero habitual con derechos para el administrador y los monitores:
[mon.] key = AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA== caps mon = "allow *" [client.admin] key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp== caps mds = "allow *" caps mon = "allow *" caps osd = "allow *" caps mgr = "allow *"
Recuerda Ahora mira el llavero en el secreto
rook-ceph-admin-keyring :
kind: Secret data: keyring: anotherBase64EncodedString=
Que hay en el
[client.admin] key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp== caps mds = "allow *" caps mon = "allow *" caps osd = "allow *" caps mgr = "allow *"
El mismo Veamos más ... Aquí, por ejemplo, está el secreto de
rook-ceph-mgr-a-keyring :
[mgr.a] key = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew== caps mon = "allow *" caps mds = "allow *" caps osd = "allow *"
Al final, encontramos algunos secretos más en ConfigMap
rook-ceph-mon :
kind: Secret data: admin-secret: AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp== cluster-name: a3ViZS1yb29r fsid: ZmZiYjliZDMtODRkOS00ZDk1LTczNTItYWY4MzZhOGJkNDJhCg== mon-secret: AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==
Y esta es la lista inicial con llavero, de donde provienen todos los secretos descritos anteriormente.
Como sabes (ver
dataDirHostPath en la
documentación ), Rook almacena estos datos en dos lugares. Por lo tanto, vayamos a los nodos para ver el llavero que se encuentra en los directorios que están montados en pods con monitores y OSD. Para hacer esto, busque los nodos
/var/lib/rook/mon-a/data/keyring y vea:
# cat /var/lib/rook/mon-a/data/keyring [mon.] key = AXAbS19d8NNUXOBB+XyYwXqXI1asIzGcGlzMGg== caps mon = "allow *"
De repente, el secreto resultó ser diferente, no como en ConfigMap.
¿Qué pasa con el llavero de administrador? También lo tenemos:
# cat /var/lib/rook/kube-rook/client.admin.keyring [client.admin] key = AXAbR19d8GGSMUBN+FyYwEqGI1aZizGcJlHMLgx= caps mds = "allow *" caps mon = "allow *" caps osd = "allow *" caps mgr = "allow *"
Aquí está el problema. Hubo un error: el clúster fue recreado ... pero en realidad no.
Queda claro que el llavero recién generado se almacena en secretos, y no son de nuestro antiguo clúster. Por lo tanto:
- tomamos llavero del monitor del archivo
/var/lib/rook/mon-a/data/keyring (o de la copia de seguridad); - cambie el llavero en el secreto
rook-ceph-mons-keyring ; - registre el llavero del administrador y monitoree en ConfigMap'e
rook-ceph-mon ; - retire los controladores de pod con monitores.
El milagro no tomará mucho tiempo: aparecerán monitores y se iniciarán. ¡Hurra, un comienzo!
Restaurar OSD
Entramos en el pod
rook-operator : llamar a
ceph mon dump muestra que todos los monitores están en su lugar, y
ceph -s que están en un quórum. Sin embargo, si observa el árbol OSD (árbol
ceph osd tree ), verá algo extraño en él: OSD comenzó a aparecer, pero están vacíos. Resulta que también necesitan ser restaurados de alguna manera. Pero como?
Mientras tanto,
rook-ceph-config y
rook-config-override , así como muchos otros ConfigMap con nombres como
rook-ceph-osd-$nodename-config , aparecieron en ConfigMap's tan necesarios. Echemos un vistazo a ellos:
kind: ConfigMap data: osd-dirs: '{"/mnt/osd1":16,"/mnt/osd2":18}'
¡Todo está mal, todo está mezclado!
Escale el pod del operador a cero, elimine los pods de implementación generados del OSD y repare estos ConfigMaps. ¿Pero dónde obtener el mapa OSD
correcto por nodos?
- Intentemos profundizar en los directorios
/mnt/osd[1-2] en los nodos nuevamente, con la esperanza de que podamos encontrar algo allí. - Hay 2 subdirectorios en el directorio
/mnt/osd1 : osd0 y osd16 . ¿El último es solo esa ID que se especifica en ConfigMap (16)? osd0 tamaño y veamos que osd0 mucho más grande que osd16 .
Llegamos a la conclusión de que
osd0 es el OSD requerido, que se especificó como
/mnt/osd1 en ConfigMap (porque usamos el
directorio basado en osd ).
Paso a paso, verificamos todos los nodos y editamos los ConfigMap. Después de todas las instrucciones, puede ejecutar el pod del operador Rook y leer sus registros. Y todo es maravilloso en ellos:
- Soy un operador de clúster;
- Encontré unidades en los nodos;
- Encontré monitores;
- los monitores se hicieron amigos, es decir formó un quórum;
- ejecutar implementaciones de OSD ...
Volvamos al pod del operador Rook y verifiquemos la vida del clúster ... sí, ¡cometimos un pequeño error con las conclusiones sobre los nombres de OSD en algunos nodos! No importa: nuevamente corrigieron ConfigMaps, eliminaron los directorios adicionales de los nuevos OSD y llegaron al tan esperado estado de
HEALTH_OK .
Verifique las imágenes en la piscina:
Todo está en su lugar: ¡el clúster está guardado!
Soy perezoso haciendo copias de seguridad, o la forma rápida
Si se hicieron copias de seguridad para Rook, el procedimiento de recuperación se vuelve mucho más simple y se reduce a lo siguiente:
- Despliegue a escala a cero del operador Rook;
- Eliminamos todas las implementaciones excepto el operador Rook;
- Restauramos todos los secretos y ConfigMaps de la copia de seguridad;
- Restaurar el contenido de los
/var/lib/rook/mon-* en los nodos; - Restaurar (si se pierde de repente) CRD
CephCluster , CephFilesystem , CephBlockPool , CephNFS , CephObjectStore ; - Escale el despliegue del operador Rook de nuevo a 1.
Consejos útiles
¡Haz copias de seguridad!
Y para evitar situaciones en las que necesite recuperarse de ellas:
- Antes de trabajar a gran escala con el clúster, que consiste en reiniciar el servidor, escale el operador Rook a cero para que no haga demasiado.
- En los monitores, agregue nodeAffinity por adelantado.
- Preste atención a la
ROOK_MON_HEALTHCHECK_INTERVAL de los tiempos de espera ROOK_MON_HEALTHCHECK_INTERVAL y ROOK_MON_OUT_TIMEOUT .
En lugar de una conclusión
No tiene sentido argumentar que Rook, al ser una "capa" adicional (en el esquema general de organización del almacenamiento en Kubernetes), simplifica mucho, también agrega nuevas dificultades y problemas potenciales en la infraestructura. La cosa sigue siendo "pequeña": hacer una elección equilibrada e informada entre estos riesgos, por un lado, y los beneficios que la solución trae en su caso particular, por el otro.
Por cierto, la sección "Adoptar un clúster Rook Ceph existente en un nuevo clúster de Kubernetes" se
ha agregado recientemente
a la documentación de Rook. Describe con más detalle lo que debe hacerse para mover los datos existentes a un nuevo clúster de Kubernetes o para restaurar un clúster que se ha colapsado por una razón u otra.
PS
Lea también en nuestro blog: