
Creé Openstack basado en MAAS usando juju. He creado instancias, proyectos, etc. He realizado copias de seguridad de la base de datos y de los archivos de configuración de openstack. Estoy intentando probar la recuperación destruyendo y eliminando el servicio.piedra clave, sólo para ver si era recuperable. También dejo la base de datos Keystone. (está respaldado) Entonces, con juju destruyo la antigua piedra angular que estaba rota y despliegue una nueva piedra angular. En realidad, esto me permite volver a ejecutar, excepto por el hecho de que todos los proyectos (inquilinos) desaparecieron y las instancias no pertenecen a ningún proyecto. Entonces restauro la base de datos de Keystone pero sin los tokens, pero cuando lo hago, aparece un error en el horizonte que me dice que Keystone no autorizará al cliente.
¿Cuál sería la mejor manera de restaurar un nodo clave roto...? Parece que cuando rehaces Keystone con Juju obtienes nuevas fichas. ¿Puede juju de alguna manera inyectar los viejos en la nueva piedra angular?
Respuesta1
El problema al que se enfrenta es que el acceso Keystone almacena cierta información fuera de la base de datos Keystone; específicamente, los nombres de usuario y las contraseñas de los servicios se almacenan localmente en el disco de modo que cuando haya unidades de servicio adicionales relacionadas con Keystone, el servicio Keystone pueda entregar la contraseña correcta para el usuario solicitado al servicio relacionado.
También tendrá problemas si no ha proporcionado la contraseña de administrador y la configuración del token de administrador al implementar Keystone; las unidades de servicio Keystone las generarán aleatoriamente si no se configuran explícitamente, por lo que cambiarán cuando elimine y luego agregue una nueva unidad de servicio Keystone.
Lo que termina es un conjunto de contraseñas hash en la base de datos (creada por la primera unidad de servicio) que no coinciden con las contraseñas generadas en el disco en la segunda unidad de servicio Keystone.
Lo ideal sería solucionar este problema mediante algún tipo de función genérica de almacenamiento de objetos en juju (piense en poner objetos/obtener objetos), pero esta no es una función compatible.
Todo el almacenamiento en disco de contraseñas y tokens se realiza en /var/lib/keystone; es posible que pueda seleccionarlos como parte de una copia de seguridad de la propia unidad de servicio Keystone; sin embargo, llegará a las carreras cuando agregue la nueva unidad de servicio, ya que las relaciones de servicio se activarán antes de que pueda restaurar estos archivos.
Como uno de los mantenedores del encanto de OpenStack, pensaré un poco más en esto y veré si se nos ocurre algo más elegante.