Para entrar a la sesión en Ceph Dashboard, abra su dirección URL en un navegador, incluido el número de puerto. Ejecute el comando siguiente para buscar la dirección:

cephuser@adm > ceph mgr services | grep dashboard
"dashboard": "https://host:port/",

El comando devuelve la URL donde se encuentra Ceph Dashboard. Si tiene problemas con este comando, consulte el Book “Troubleshooting Guide”, Chapter 10 “Troubleshooting the Ceph Dashboard”, Section 10.1 “Locating the Ceph Dashboard”.

Figura 2.1: Pantalla de entrada a Ceph Dashboard #

 

Entre a la sesión con las credenciales que creó durante la distribución del clúster (consulte el Book “Guía de distribución”, Chapter 5 “Distribución con cephadm”, Section 5.3.2.9 “Configuración de las credenciales de entrada de Ceph Dashboard”).

Sugerencia: cuenta de usuario personalizada

Si no desea utilizar la cuenta admin por defecto para acceder a Ceph Dashboard, cree una cuenta de usuario personalizada con privilegios de administrador. Consulte el Capítulo 11, Gestión de usuarios y funciones en la línea de comandos para obtener más información.

La interfaz de usuario de la consola se divide en varios bloques: el menú de utilidades en la parte superior derecha de la pantalla, el menú principal en la parte izquierda y el panel de contenido principal.

Figura 2.2: Página de inicio de Ceph Dashboard #

 

La parte superior derecha de la pantalla muestra un menú de utilidades. Incluye tareas generales relacionadas más con la consola que con el clúster de Ceph. Puede hacer clic en las opciones para acceder a los siguientes temas:

El menú principal de la consola ocupa la parte izquierda de la pantalla. Abarca los siguientes contenidos:

El panel de contenidos ocupa gran parte de la pantalla de la consola. La página de inicio de la consola muestra numerosos widgets útiles para informar brevemente sobre el estado actual del clúster, su capacidad y el rendimiento.

En Ceph Dashboard se suele trabajar con listas; por ejemplo, listas de repositorios, nodos de OSD o dispositivos RBD. Todas las listas se actualizan automáticamente por defecto cada cinco segundos. Los widgets comunes siguientes ayudan a gestionar o a ajustar estas listas:

Haga clic en para activar una actualización manual de la lista.

Haga clic en para mostrar u ocultar columnas individuales.

Haga clic en e introduzca o seleccione el número de filas que desea mostrar en cada página.

Haga clic dentro de y filtre las filas escribiendo una cadena de búsqueda.

Use para cambiar la página que se muestra si la lista se extiende por varias páginas.

Cada widget de consola muestra información de estado específica relacionada con un aspecto específico de un clúster de Ceph en ejecución. Algunos widgets son enlaces activos y, después de hacer clic en ellos, le redirigirán a una página con detalles sobre el tema que representan.

Sugerencia: obtener más información al pasar el ratón

Algunos widgets gráficos muestran más detalles al mover el ratón sobre ellos.

2.6.1 Widgets de Estado #

 

Los widgets de Estado ofrecen una breve descripción general sobre el estado actual del clúster.

Figura 2.3: Widgets de Estado #

 

Estado del clúster

Presenta información básica sobre el estado del clúster.

Hosts

Muestra el número total de nodos del clúster.

Monitores

Muestra el número de monitores en ejecución y su quórum.

OSDs

Muestra el número total de OSD, así como el número de OSD con los estados up e in.

Managers

Muestra el número de daemons de Ceph Manager activos y en espera.

Pasarelas de Object Gateway

Muestra el número de pasarelas Object Gateway en ejecución.

Servidores de metadatos

Muestra el número de servidores de metadatos.

Puertas de enlace iSCSI

Muestra el número de pasarelas iSCSI Gateway configuradas.

2.6.2 Widgets de Capacidad #

 

Los widgets de Capacidad muestran información breve sobre la capacidad de almacenamiento.

Figura 2.4: Widgets de Capacidad #

 

Capacidad en bruto

Muestra la proporción de capacidad de almacenamiento en bruto utilizada y disponible.

Objetos

Muestra el número de objetos de datos almacenados en el clúster.

Estado del grupo de colocación

Muestra un gráfico de los grupos de colocación según su estado.

Repositorios

Muestra el número de repositorios del clúster.

Grupos de colocación por OSD

Muestra el promedio de grupos de colocación por OSD.

2.6.3 Widgets de Rendimiento #

 

Los widgets de Rendimiento muestran datos básicos de rendimiento de los clientes de Ceph.

Figura 2.5: Widgets de Rendimiento #

 

Lectura/escritura de cliente

La cantidad de operaciones de lectura y escritura de los clientes por segundo.

Rendimiento del cliente

La cantidad de datos transferidos a y desde los clientes de Ceph en bytes por segundo.

Rendimiento de recuperación

El rendimiento de los datos recuperados por segundo.

Scrubbing

Muestra el estado de depuración (consulte la Sección 17.4.9, “Depuración de un grupo de colocación”). Puede ser inactivo, habilitado o activo.

Haga clic en en el menú de utilidades y seleccione Gestión de usuarios.

La lista contiene el nombre de usuario de cada usuario, el nombre completo, el correo electrónico, una lista de funciones asignadas, si la función está habilitada y la fecha de caducidad de la contraseña.

Figura 3.1: Gestión de usuarios #

 

Haga clic en Crear en la parte superior izquierda del encabezado de la tabla para añadir un nuevo usuario. Introduzca su nombre de usuario, contraseña y, opcionalmente, un nombre completo y un correo electrónico.

Figura 3.2: Adición de un usuario #

 

Haga clic en el icono de lápiz pequeño para asignar funciones predefinidas al usuario. Para confirmar, haga clic en Crear usuario.

Haga clic en la fila de un usuario para resaltarlo. Seleccione Editar para modificar los detalles del usuario. Para confirmar, haga clic en Editar usuario.

Haga clic en la fila de de un usuario para resaltarlo. Seleccione el botón desplegable situado junto a Editar y seleccione Suprimir en la lista para suprimir la cuenta de usuario. Active la casilla de verificación Sí, seguro y haga clic en Suprimir usuario para confirmar.

Haga clic en en el menú de utilidades y seleccione Gestión de usuarios. A continuación, haga clic en la pestaña Funciones.

La lista contiene el nombre y la descripción de cada función e indica si se trata de una función del sistema.

Figura 3.3: Funciones del usuario #

 

Haga clic en Crear en la parte superior izquierda del encabezado de la tabla para añadir una nueva función personalizada. Introduzca los datos correspondientes en Nombre y Descripción y, junto a Permisos, seleccione los permisos adecuados.

Sugerencia: limpieza de funciones personalizadas

Si crea funciones de usuario personalizadas y tiene previsto eliminar el clúster de Ceph con el comando ceph-salt purge más adelante, primero debe limpiar las funciones personalizadas. Más detalles en la Sección 13.9, “Eliminación de un clúster de Ceph completo”

Figura 3.4: Adición de una función #

 

Sugerencia: activación múltiple

Al activar la casilla de verificación que precede al nombre del tema, se activan todos los permisos para ese tema. Al activar la casilla de verificación Todos se activan todos los permisos para todos los temas.

Para confirmar, haga clic en Crear función.

Haga clic en la fila de un usuario para resaltarlo. Seleccione Editar en la parte superior izquierda del encabezado de la tabla para editar una descripción y los permisos de la función personalizada. Para confirmar, haga clic en Editar función.

Haga clic en la fila de una función para resaltarla. Seleccione el botón desplegable situado junto a Editar y seleccione Suprimir en la lista para suprimir la función. Active la casilla de verificación Sí, seguro y haga clic en Suprimir función para confirmar.

Haga clic en Clúster › Hosts para ver una lista de nodos de clúster.

Figura 4.1: Hosts #

 

Haga clic en la flecha desplegable situada junto al nombre de un nodo en la columna Nombre de host para ver los detalles de rendimiento del nodo.

La columna Servicios muestra todos los daemons que se ejecutan en cada nodo relacionado. Haga clic en un nombre de daemon para ver su configuración detallada.

Haga clic en Clúster › Inventario para ver una lista de dispositivos. La lista incluye la vía del dispositivo, el tipo, la disponibilidad, el proveedor, el modelo, el tamaño y los OSD.

Haga clic para seleccionar un nombre de nodo en la columna Nombre de host. Si está seleccionado, haga clic en Identificar para identificar el dispositivo en el que se ejecuta el host. Esto indica al dispositivo que haga parpadear sus LED. Seleccione la duración de esta acción, que puede ser 1, 2, 5, 10 o 15 minutos. Haga clic en Ejecutar.

Figura 4.2: Servicios #

 

Haga clic en Clúster › Monitores para ver una lista de nodos de clúster con monitores de Ceph en ejecución. El panel de contenido se divide en dos vistas: Estado y En quórum o Sin quórum.

La tabla Estado muestra estadísticas generales sobre los monitores Ceph Monitor en ejecución, incluido lo siguiente:

Los paneles Con quórum y Sin quórum incluyen el nombre de cada monitor, el número de rango, la dirección IP pública y el número de sesiones abiertas.

Haga clic en un nombre de nodo en la columna Nombre para ver la configuración relacionada de Ceph Monitor.

Figura 4.3: Monitores Ceph Monitor #

 

Haga clic en Clúster › Servicios para ver los detalles de cada uno de los servicios disponibles: crash, Ceph Manager y monitores Ceph Monitor. La lista incluye el nombre de la imagen del contenedor, el ID de la imagen del contenedor, el estado de lo que se está ejecutando, el tamaño y cuándo se actualizó por última vez.

Haga clic en la flecha desplegable situada junto al nombre de un servicio en la columna Servicio para ver los detalles del daemon. La lista de detalles incluye el nombre de host, el tipo de daemon, el ID de daemon, el ID de contenedor, el nombre de la imagen del contenedor, el ID de la imagen del contenedor, el número de versión, el estado y cuándo se actualizó por última vez.

Figura 4.4: Servicios #

 

Haga clic en Clúster › OSDs para ver una lista de nodos con daemons de OSD en ejecución. La lista incluye el nombre de cada nodo, el ID, su estado, la clase de dispositivo, el número de grupos de colocación, el tamaño, el uso, el gráfico de lecturas/escrituras en el tiempo y la tasa de operaciones de lectura/escritura por segundo.

Figura 4.5: Daemons Ceph OSD #

 

Seleccione Indicadores en el menú desplegable Configuración de todo el clúster en el encabezado de la tabla para abrir una ventana emergente. En ella verá una lista de indicadores que se aplican a todo el clúster. Puede activar o desactivar indicadores individuales. Para confirmar, haga clic en Enviar.

Figura 4.6: Indicadores de OSD #

 

Seleccione Prioridad de recuperación en el menú desplegable Configuración de todo el clúster en el encabezado de la tabla para abrir una ventana emergente. En ella verá una lista de prioridades de recuperación de OSD que se aplican a todo el clúster. Puede activar el perfil de prioridad preferido y después ajustar los valores individuales. Para confirmar, haga clic en Enviar.

Figura 4.7: Prioridad de recuperación de OSD #

 

Haga clic en la flecha desplegable situada junto a un nombre de nodo en la columna Host para ver una tabla extendida con detalles sobre la configuración y el rendimiento del dispositivo. En las distintas pestañas, es posible ver listas de atributos, metadatos, el estado del dispositivo, contadores de rendimiento y un histograma gráfico de lecturas y escrituras, así como detalles de rendimiento.

Figura 4.8: Detalles de OSD #

 

Sugerencia: realización de tareas específicas en los OSD

Cuando se hace clic en el nombre de un nodo de OSD, la fila de la tabla se resalta. Esto significa que ahora se puede realizar una tarea en el nodo. Puede realizar cualquiera de las siguientes acciones: Editar, Crear, Depuración, Depuración profunda, Reequilibrar peso, Marcar para excluir, Marcar para incluir, Marcar para desactivar, Marcar como perdido, Limpiar, Destruir o Suprimir.

Haga clic en la flecha hacia abajo situada en la parte superior izquierda del encabezado de la tabla, junto al botón Crear y seleccione la tarea que desea realizar.

Haga clic en Clúster › Configuración para ver una lista completa de las opciones de configuración del clúster de Ceph. La lista contiene el nombre de la opción, una descripción breve y sus valores actuales y por defecto. También se indica si la opción se puede editar.

Figura 4.14: Configuración del clúster #

 

Haga clic en la flecha desplegable situada junto a una opción de configuración en la columna Nombre para ver una tabla extendida con información detallada sobre la opción, como su tipo de valor, los valores mínimos y máximos permitidos, si se puede actualizar en el tiempo de ejecución y mucho más.

Después de resaltar una opción específica, puede editar sus valores haciendo clic en el botón Editar en la parte superior izquierda del encabezado de la tabla. Para confirmar los cambios, haga clic en Guardar.

Haga clic en Clúster › Mapa de CRUSH para ver un mapa de CRUSH del clúster. Para obtener información general sobre los mapas de CRUSH, consulte la Sección 17.5, “Manipulación del mapa de CRUSH”.

Haga clic en la raíz, los nodos o los OSD individuales para ver información más detallada, como el peso de CRUSH, la profundidad del árbol de mapa, la clase de dispositivo del OSD y mucho más.

Figura 4.15: Mapa de CRUSH #

 

Haga clic en Clúster › Módulos de gestor para ver una lista de los módulos de Ceph Manager disponibles. Cada línea está formada por nombre de módulo e información sobre si está habilitado actualmente.

Figura 4.16: Módulos de gestor #

 

Haga clic en la flecha desplegable situada junto a un módulo en la columna Nombre para ver una tabla extendida con detalles sobre la configuración en la tabla Detalles de abajo. Para editar los detalles, haciendo clic en Editar en la parte superior izquierda del encabezado de la tabla. Para confirmar los cambios, haga clic en Actualizar.

Haga clic en la flecha desplegable situada junto al botón Editar en la parte superior izquierda del encabezado de la tabla para habilitar o inhabilitar un módulo.

Haga clic en Clúster › Registros para ver una lista de las entradas de registro recientes del clúster. Cada línea está formada por una marca de tiempo, el tipo de la entrada de registro y el propio mensaje registrado.

Haga clic en la pestaña Registros de auditoría para ver las entradas de registro del subsistema de auditoría. Consulte en la Sección 11.5, “Auditoría de peticiones de API” los comandos necesarios para habilitar o inhabilitar la auditoría.

Figura 4.17: Registros #

 

Haga clic en Clúster › Supervisión para gestionar y ver los detalles de las alertas de Prometheus.

Si tiene Prometheus activo, en este panel de contenido puede ver información detallada sobre Alertas activas, Todas las alertas o Silencios.

Nota

Si no ha distribuido Prometheus, aparecerá un anuncio con información y un enlace a la documentación pertinente.

Para añadir un repositorio nuevo , haga clic en Crear en la parte superior izquierda de la tabla de repositorios. En el formulario del repositorio, puede introducir el nombre del repositorio, el tipo, sus aplicaciones, el modo de compresión y las cuotas, incluido el número máximo de bytes y el número máximo de objetos. El propio formulario calcula el número de grupos de colocación que mejor se adapta a este repositorio específico. El cálculo se basa en la cantidad de OSD del clúster y el tipo de repositorio seleccionado con su configuración específica. Si se define manualmente el número de grupos de colocación, el número calculado se sustituirá. Para confirmar, haga clic en Crear repositorio.

Figura 5.2: Adición de un repositorio nuevo #

 

Para suprimir un repositorio, selecciónelo en la fila de la tabla. Haga clic en la flecha desplegable situada junto al botón Crear y haga clic en Suprimir.

Para editar las opciones de un repositorio, seleccione el repositorio en la fila de la tabla y haga clic en Editar en la parte superior izquierda de la tabla.

Puede cambiar el nombre del repositorio, aumentar el número de grupos de colocación, cambiar la lista de aplicaciones del repositorio y la configuración de compresión. Para confirmar, haga clic en Editar repositorio.

Para ver información más detallada sobre un dispositivo, haga clic en su fila en la tabla:

Figura 6.2: Detalles de RBD #

 

Para ver la configuración detallada de un dispositivo, haga clic en su fila en la tabla y, a continuación, en la pestaña Configuración de la tabla inferior:

Figura 6.3: Configuración de RBD #

 

Para añadir un dispositivo nuevo, haga clic en Crear en la parte superior izquierda del encabezado de la tabla y haga lo siguiente en la pantalla Crear RBD:

Figura 6.4: Adición de un RBD nuevo #

 

Para suprimir un dispositivo, selecciónelo en la fila de la tabla. Haga clic en la flecha desplegable situada junto al botón Crear y haga clic en Suprimir. Para confirmar, haga clic en Suprimir RBD.

Sugerencia: traslado de los RBD a la papelera

Suprimir un RBD es una acción irreversible. Si en su lugar, usa la opción Mover a la papelera, podrá restaurar el dispositivo más adelante seleccionándolo en la pestaña Papelera de la tabla principal y haciendo clic en Restaurar en la parte superior izquierda del encabezado de la tabla.

Para crear una instantánea de dispositivo de bloques RADOS, seleccione el dispositivo en la fila de la tabla y aparecerá el panel de contenido de configuración detallada. Seleccione la pestaña Instantáneas y haga clic en Crear en la parte superior izquierda del encabezado de la tabla. Escriba el nombre de la instantánea y haga clic en Crear instantánea de RBD para confirmar.

Después de seleccionar una instantánea, puede realizar acciones adicionales en el dispositivo, como cambiar su nombre, protegerlo, clonarlo, copiarlo o suprimirlo. La opción Rollback (Deshacer) restaura el estado del dispositivo de la instantánea actual.

Figura 6.5: Instantáneas de RBD #

 

Los dispositivos de bloques de imágenes RADOS se pueden duplicar de forma asincrónica entre dos clústeres de Ceph. Puede usar Ceph Dashboard para configurar la réplica de imágenes RBD entre dos o más clústeres. Esta capacidad está disponible en dos modos:

La duplicación se configura en cada repositorio dentro de clústeres conectores y se puede configurar en un subconjunto específico de imágenes dentro del repositorio o para que refleje automáticamente todas las imágenes de un repositorio si se usa únicamente la duplicación transaccional.

La duplicación se configura mediante el comando rbd, que se instala por defecto en SUSE Enterprise Storage 7. El daemon rbd-mirror es el responsable de la extracción de actualizaciones de imágenes del clúster conector remoto y de aplicarlos a la imagen en el clúster local. Consulte la Sección 6.6.2, “Habilitación del daemon rbd-mirror” para obtener más información sobre cómo habilitar el daemon rbd-mirror.

Dependiendo de la necesidad de réplica, la duplicación del dispositivo de bloques RADOS se puede configurar para la réplica unidireccional o bidireccional:

Importante

Cada instancia del daemon rbd-mirror debe poder conectarse a los clústeres de Ceph locales y remotos simultáneamente; por ejemplo, a todos los monitores y los hosts OSD. Además, la red debe tener suficiente ancho de banda entre los dos centros de datos para poder gestionar la carga de trabajo de duplicación.

Sugerencia: información general

Para obtener información general y el enfoque de la línea de comandos para duplicar un dispositivo de bloques RADOS, consulte la Sección 20.4, “Duplicados de imagen RBD”.

6.6.1 Configuración de clústeres primarios y secundarios #

 

El clúster primario es aquel donde se crea el repositorio original con imágenes. El clúster secundario es donde se replican el repositorio o las imágenes desde el clúster primario.

Nota: nomenclatura relativa

Los términos primario y secundario pueden ser relativos en el contexto de la réplica, ya que están más relacionados con los repositorios individuales que con los clústeres. Por ejemplo, en la réplica bidireccional, un repositorio se puede duplicar desde el clúster primario al secundario, mientras que otro repositorio se puede duplicar desde el clúster secundario al primario.

cephuser@adm > rbd mirror pool disable POOL_NAME

cephuser@adm > rbd mirror pool peer bootstrap create [--site-name local-site-name] pool-name

cephuser@adm > rbd --cluster primary mirror pool peer bootstrap create --site-name primary
  image-pool eyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkL \
  W1pcnJvci1wZWVyIiwia2V5IjoiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1vbl9ob3N0I \
  joiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==

cephuser@adm > rbd mirror pool peer bootstrap import [--site-name local-site-name] \
[--direction rx-only or rx-tx] pool-name token-path

cephuser@adm > cat >>EOF < token
eyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkLW \
1pcnJvci1wZWVyIiwia2V5IjoiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1v \
bl9ob3N0IjoiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==
EOF
cephuser@adm > rbd --cluster secondary mirror pool peer bootstrap import --site-name secondary image-pool token

cephuser@adm > rbd mirror pool peer remove pool-name peer-uuid

Sugerencia: más información sobre las pasarelas iSCSI Gateway

Para obtener información general sobre las pasarelas iSCSI Gateway, consulte el Capítulo 22, Ceph iSCSI Gateway.

Para mostrar todas las pasarelas disponibles y las imágenes asignadas, haga clic en Bloque › iSCSI en el menú principal. Se abre una pestaña Resumen, que muestra las pasarelas iSCSI Gateway configuradas actualmente y las imágenes RBD asignadas.

La tabla Puertas de enlace iSCSI muestra el estado de cada pasarela, el número de destinos iSCSI y el número de sesiones. La tabla Imágenes muestra el nombre de cada imagen asignada, el nombre del repositorio relacionado, el tipo de almacén y otros detalles estadísticos.

La pestaña Destinos muestra los destinos iSCSI configurados actualmente.

Figura 6.14: Lista de destinos iSCSI #

 

Para ver información más detallada acerca de un destino, haga clic en la flecha desplegable de la fila de la tabla de destino. Se abre un esquema estructurado en forma de árbol con los discos, los portales, los iniciadores y los grupos incluidos. Haga clic en un elemento para expandirlo y ver su contenido detallado, opcionalmente con la configuración relacionada en la tabla de la derecha.

Figura 6.15: Detalles de destino iSCSI #

 

6.7.1 Adición de destinos iSCSI #

 

Para añadir un destino iSCSI nuevo, haga clic en Crear en la parte superior izquierda de la tabla Destinos e introduzca la información necesaria.

Figura 6.16: Adición de un destino nuevo #

 

1. Escriba la dirección de destino de la nueva pasarela.

2. Haga clic en Añadir portal y seleccione uno o varios portales iSCSI de la lista.

3. Haga clic en Añadir imagen y seleccione una o varias imágenes RBD para la pasarela.

4. Si necesita utilizar autenticación para acceder a la pasarela, marque la casilla de verificación Autenticación de ACL e introduzca las credenciales. Encontrará opciones de autenticación más avanzadas después de activar Autenticación mutua y Autenticación de descubrimiento.

5. Para confirmar, haga clic en Crear destino.

Sugerencia: información adicional

Para obtener información general y una descripción de las opciones de configuración de QoS de un RDB, consulte la Sección 20.6, “Ajuste de QoS”.

Las opciones de QoS se pueden configurar en diferentes niveles.

La configuración global se encuentra en la parte superior de la lista y se utiliza para todas las imágenes RBD recién creadas y para aquellas imágenes que no sustituyen estos valores en la capa del repositorio o de la imagen RBD. Un valor especificado globalmente se puede sustituir en cada repositorio o imagen. Las opciones especificadas en un repositorio se aplicarán a todas las imágenes RBD de ese repositorio a menos que se sustituyan por una opción de configuración definida en una imagen. Las opciones especificadas en una imagen sustituyen a las opciones especificadas en un repositorio y a las especificadas globalmente.

De esta manera, es posible definir valores por defecto globalmente, adaptarlos para todas las imágenes de RBD de un repositorio específico y sustituir la configuración del repositorio para imágenes RBD individuales.

6.8.2 Configuración de opciones en un nuevo repositorio #

 

Para crear un nuevo repositorio y configurar las opciones de configuración de RBD en él, haga clic en Repositorios › Crear. Seleccione replicado como tipo de repositorio. A continuación, deberá añadir la etiqueta de aplicación rbd al repositorio para poder configurar las opciones de QoS de RBD.

Nota

No es posible configurar las opciones de configuración de QoS de RBD en un repositorio codificado de borrado. Para configurar las opciones de QoS de RBD para los repositorios codificados de borrado, debe editar el repositorio de metadatos replicados de una imagen RBD. A continuación, la configuración se aplicará al repositorio codificado de borrado de esa imagen.

6.8.3 Configuración de opciones en un repositorio existente #

 

Para configurar las opciones de QoS de RBD en un repositorio existente, haga clic en Repositorios, haga clic en la fila del repositorio en la tabla y seleccione Editar en la parte superior izquierda de la tabla.

Debería ver la sección Configuración de RBD en el recuadro de diálogo, seguida de una sección Calidad del servicio.

Nota

Si no ve las secciones Configuración de RBD ni Calidad del servicio, es probable que esté editando un repositorio codificado de borrado, que no se puede usar para establecer opciones de configuración de RBD, o bien que el repositorio no esté configurado para que las imágenes RBD lo puedan usar. En este último caso, asigne la etiqueta de aplicación rbd al repositorio y aparecerán las secciones de configuración correspondientes.

Para añadir una exportación NFS nueva, haga clic en Crear en la parte superior izquierda de la tabla de exportaciones e introduzca la información necesaria.

Figura 7.3: Adición de una exportación NFS nueva #

 

Para suprimir una exportación, seleccione y resalte la exportación en la fila de la tabla. Haga clic en la flecha desplegable situada junto al botón Editar y seleccione Suprimir. Active la casilla de verificación Sí, seguro y haga clic en Suprimir exportación NFS para confirmar.

Para editar una exportación existente, seleccione y resalte la exportación en la fila de la tabla y haga clic en Editar en la parte superior izquierda de la tabla de exportaciones.

A continuación, puede ajustar todos los detalles de la exportación NFS.

Figura 7.4: Edición de una exportación NFS #

 

Haga clic en Sistemas de archivos en el menú principal para ver un resumen de los sistemas de archivos configurados. La tabla principal muestra el nombre de cada sistema de archivos, la fecha de creación y si está habilitado o no.

Al hacer clic en una fila de la tabla del sistema de archivos, se muestran detalles sobre su rango y los repositorios añadidos al sistema de archivos.

Figura 8.1: Detalles de CephFS #

 

En la parte inferior de la pantalla, se muestran estadísticas con el número de inodos MDS relacionados y las peticiones del cliente, recopiladas en tiempo real.

Figura 8.2: Detalles de CephFS #

 

Para ver una lista de pasarelas Object Gateway configuradas, haga clic en Object Gateway › Daemons. La lista incluye el ID de la pasarela, el nombre de host del nodo del clúster donde se ejecuta el daemon de la pasarela y el número de versión de la pasarela.

Haga clic en la flecha desplegable situada junto al nombre de la pasarela para ver información detallada sobre ella. La pestaña Contadores de rendimiento muestra detalles sobre las operaciones de lectura y escritura y las estadísticas de caché.

Figura 9.1: Detalles de la pasarela #

 

Haga clic en Object Gateway › Usuarios para ver una lista de los usuarios existentes de Object Gateway.

Haga clic en la flecha desplegable situada junto al nombre de usuario para ver los detalles de la cuenta de usuario, como el estado o detalles de la cuota del usuario y del depósito.

Figura 9.2: Usuarios de pasarela #

 

9.2.1 Adición de un nuevo usuario de pasarela #

 

Para añadir un nuevo usuario de pasarela, haga clic en Crear en la parte superior izquierda del encabezado de la tabla. Indique sus credenciales, los detalles sobre la clave S3 y las cuotas de usuario y depósito. A continuación, haga clic en Crear usuario para confirmar.

Figura 9.3: Adición de un nuevo usuario de pasarela #

 

Los depósitos de Object Gateway (OGW) implementan la funcionalidad de los contenedores de OpenStack Swift. Los depósitos de Object Gateway sirven como contenedores para almacenar objetos de datos.

Haga clic en Object Gateway › Depósitos para ver una lista de depósitos de Object Gateway.

9.3.1 Adición de un depósito nuevo #

 

Para añadir un depósito nuevo de Object Gateway, haga clic en Crear en la parte superior izquierda del encabezado de la tabla. Introduzca el nombre del depósito, seleccione el propietario y defina el destino de colocación. Para confirmar, haga clic en Crear depósito.

Nota

En esta fase también puede habilitar el bloqueo seleccionando Habilitado; sin embargo, se puede configurar después de la creación. Consulte la Sección 9.3.3, “Edición del depósito” para obtener más información.

9.3.2 Visualización de detalles del depósito #

 

Para ver información detallada sobre un depósito de Object Gateway, haga clic en la flecha desplegable situada junto al nombre del depósito

Figura 9.4: Detalles del depósito de pasarela #

 

Sugerencia: cuota de depósito

Debajo de la tabla Detalles, puede encontrar detalles sobre la cuota de depósito y la configuración de bloqueo.

9.3.3 Edición del depósito #

 

Seleccione y resalte un depósito y, a continuación, haga clic en Editar en la parte superior izquierda del encabezado de la tabla.

Puede actualizar el propietario del depósito o habilitar el control de versiones, la autenticación multifactor o el bloqueo. Para confirmar los cambios, haga clic en Editar depósito.

Figura 9.5: Edición de los detalles del depósito #

 

Todas las conexiones HTTP a la consola están protegidas por defecto con TLS/SSL. Una conexión segura requiere un certificado SSL. Puede usar un certificado autofirmado o generar un certificado y hacer que una entidad de certificación (CA) conocida lo firme.

Sugerencia: inhabilitación de SSL

A veces puede ser necesario inhabilitar SSL por algún motivo. Por ejemplo, si la consola se ejecuta mediante un proxy que no admite SSL.

Tenga cuidado al inhabilitar SSL, ya que los nombres de usuario y las contraseñas se enviarán a la consola sin cifrar.

Para inhabilitar SSL, ejecute:

cephuser@adm > ceph config set mgr mgr/dashboard/ssl false

Sugerencia: reinicio de los procesos de Ceph Manager

Debe reiniciar los procesos de Ceph Manager manualmente después de cambiar el certificado SSL y la clave. Puede hacerlo ejecutando:

cephuser@adm > ceph mgr fail ACTIVE-MANAGER-NAME

o inhabilitando y volviendo a habilitar el módulo de consola, lo que también activa que el gestor se vuelva a reproducir a sí mismo:

cephuser@adm > ceph mgr module disable dashboard
cephuser@adm > ceph mgr module enable dashboard

10.1.1 Creación de certificados autofirmados #

 

Crear un certificado autofirmado para establecer comunicaciones seguras es sencillo. Es una manera rápida de conseguir poner en funcionamiento la consola.

Nota: queja de los navegadores Web

La mayoría de los navegadores Web producen una advertencia sobre los certificados autofirmados y requerirán que se confirmen explícitamente antes de establecer una conexión segura con la consola.

Para generar e instalar un certificado autofirmado, utilice el siguiente comando integrado:

cephuser@adm > ceph dashboard create-self-signed-cert

10.1.2 Uso de certificados firmados por una CA #

 

Para proteger correctamente la conexión a la consola y eliminar las advertencias de los navegadores Web sobre los certificados autofirmados, se recomienda usar un certificado firmado por una CA.

Puede generar un par de claves de certificado con un comando similar al siguiente:

root # openssl req -new -nodes -x509 \
  -subj "/O=IT/CN=ceph-mgr-dashboard" -days 3650 \
  -keyout dashboard.key -out dashboard.crt -extensions v3_ca

El comando anterior genera los archivos dashboard.key y dashboard.crt. Después de que una CA haya firmado el archivo dashboard.crt, habilítelo para todas las instancias de Ceph Manager ejecutando los comandos siguientes:

cephuser@adm > ceph config-key set mgr/dashboard/crt -i dashboard.crt
cephuser@adm > ceph config-key set mgr/dashboard/key -i dashboard.key

Sugerencia: certificados diferentes para cada instancia del gestor

Si necesita certificados diferentes para cada instancia de Ceph Manager, modifique los comandos e incluya el nombre de la instancia de la siguiente manera. Sustituya NAME por el nombre de la instancia de Ceph Manager (normalmente es el nombre de host relacionado):

cephuser@adm > ceph config-key set mgr/dashboard/NAME/crt -i dashboard.crt
cephuser@adm > ceph config-key set mgr/dashboard/NAME/key -i dashboard.key

Ceph Dashboard se asocia con una dirección TCP/IP y un puerto TCP específicos. Por defecto, la instancia de Ceph Manager activa actualmente donde se aloja la consola se vincula al puerto TCP 8443 (o al 8080 si SSL está inhabilitado).

Nota

Si hay un cortafuegos habilitado en los hosts en los que se ejecuta Ceph Manager (y, por lo tanto, Ceph Dashboard), es posible que deba cambiar la configuración para habilitar el acceso a estos puertos. Para obtener más información sobre la configuración del cortafuegos para Ceph, consulte el Book “Troubleshooting Guide”, Chapter 13 “Hints and tips”, Section 13.7 “Firewall settings for Ceph”.

Ceph Dashboard se asocia por defecto con "::", que corresponde a todas las direcciones IPv4 e IPv6 disponibles. Es posible cambiar la dirección IP y el número de puerto de la aplicación Web para que se apliquen a todas las instancias de Ceph Manager mediante los siguientes comandos:

cephuser@adm > ceph config set mgr mgr/dashboard/server_addr IP_ADDRESS
cephuser@adm > ceph config set mgr mgr/dashboard/server_port PORT_NUMBER

Sugerencia: configuración por separado de instancias de Ceph Manager

Dado que cada daemon ceph-mgr aloja su propia instancia de la consola, es posible que deba configurarlos por separado. Cambie la dirección IP y el número de puerto de una instancia específica del gestor mediante los comandos siguientes (sustituya NAME por el ID de la instancia de ceph-mgr):

cephuser@adm > ceph config set mgr mgr/dashboard/NAME/server_addr IP_ADDRESS
cephuser@adm > ceph config set mgr mgr/dashboard/NAME/server_port PORT_NUMBER

Sugerencia: listado de puestos finales configurados

El comando ceph mgr services muestra todos los puestos finales que están configurados actualmente. Busque la clave dashboard para obtener la dirección URL con la que acceder a la consola.

Si no desea utilizar la cuenta de administrador por defecto, cree una cuenta de usuario diferente y asóciela con al menos una función. Proporcionamos un conjunto de funciones de sistema predefinidos que puede usar. Para obtener más información, consulte el Capítulo 11, Gestión de usuarios y funciones en la línea de comandos.

Para crear un usuario con privilegios de administrador, utilice el comando siguiente:

cephuser@adm > ceph dashboard ac-user-create USER_NAME PASSWORD administrator

Para utilizar la funcionalidad de gestión de Object Gateway de la consola, debe proporcionar las credenciales de entrada de un usuario con el indicador system habilitado:

Nota

Por defecto, el cortafuegos está habilitado en SUSE Linux Enterprise Server 15 SP2. Para obtener más información acerca de la configuración del cortafuegos, consulte Book “Troubleshooting Guide”, Chapter 13 “Hints and tips”, Section 13.7 “Firewall settings for Ceph”.

Se deben tener en cuenta varios puntos:

Ceph Dashboard gestiona los destinos iSCSI mediante la API REST proporcionada por el servicio rbd-target-api de Ceph iSCSI Gateway. Asegúrese de que está instalado y habilitado en las pasarelas iSCSI.

Nota

La funcionalidad de gestión de iSCSI de Ceph Dashboard depende de la última versión 3 del proyecto ceph-iscsi. Asegúrese de que el sistema operativo proporciona la versión correcta; de lo contrario, Ceph Dashboard no habilitará las funciones de gestión.

Si la API REST ceph-iscsi está configurada en modo HTTPS y utiliza un certificado autofirmado, configure la consola para evitar la verificación del certificado SSL al acceder a la API ceph-iscsi.

Inhabilite la verificación SSL de la API:

cephuser@adm > ceph dashboard set-iscsi-api-ssl-verification false

Defina las pasarelas iSCSI disponibles:

cephuser@adm > ceph dashboard iscsi-gateway-list
cephuser@adm > ceph dashboard iscsi-gateway-add scheme://username:password@host[:port]
cephuser@adm > ceph dashboard iscsi-gateway-rm gateway_name

Single Sign-On (SSO) es un método de control de acceso que permite a los usuarios entrar a la sesión mediante un único identificador y una contraseña en varias aplicaciones simultáneamente.

Ceph Dashboard admite la autenticación externa de usuarios a través del protocolo SAML 2.0. Dado que la autorización la sigue realizando la consola, primero debe crear cuentas de usuario y asociarlas a las funciones deseadas. Sin embargo, el proceso de autenticación lo puede realizar un proveedor de identidades (IdP) existente.

Para configurar Single Sign-On, utilice el siguiente comando:

cephuser@adm > ceph dashboard sso setup saml2 CEPH_DASHBOARD_BASE_URL \
 IDP_METADATA IDP_USERNAME_ATTRIBUTE \
 IDP_ENTITY_ID SP_X_509_CERT \
 SP_PRIVATE_KEY

Parámetros:

Nota: peticiones SAML

Este patrón irá seguido del valor del emisor de las peticiones SAML:

CEPH_DASHBOARD_BASE_URL/auth/saml2/metadata

Para mostrar la configuración actual de SAML 2.0, ejecute:

cephuser@adm > ceph dashboard sso show saml2

Para inhabilitar Single Sign-On, ejecute:

cephuser@adm > ceph dashboard sso disable

Para comprobar si SSO está habilitado, ejecute:

cephuser@adm > ceph dashboard sso status

Para habilitar SSO, ejecute:

cephuser@adm > ceph dashboard sso enable saml2

Por defecto, la función de directiva de contraseñas está habilitada, incluidas las siguientes comprobaciones:

La función de directiva de contraseñas se puede activar o desactivar por completo:

cephuser@adm > ceph dashboard set-pwd-policy-enabled true|false

Las siguientes comprobaciones individuales se pueden activar o desactivar:

cephuser@adm > ceph dashboard set-pwd-policy-check-length-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-oldpwd-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-username-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-exclusion-list-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-complexity-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-sequential-chars-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-repetitive-chars-enabled true|false

Además, las siguientes opciones están disponibles para configurar el comportamiento de la directiva de contraseñas.

Ceph Dashboard admite la gestión de varias cuentas de usuario. Cada cuenta de usuario está formada por un nombre de usuario, una contraseña (almacenada cifrada mediante bcrypt), un nombre opcional y una dirección de correo electrónico opcional.

Las cuentas de usuario se almacenan en la base de datos de configuración de Ceph Monitor y se comparten de forma global entre todas las instancias de Ceph Manager.

Utilice los comandos siguientes para gestionar cuentas de usuario:

En esta sección se describen los ámbitos de seguridad que puede asignar a una función de usuario, y se explica cómo gestionar funciones de usuario y cómo asignarlas a cuentas de usuario.

11.3.2 Especificación de funciones de usuario #

 

Una función especifica un conjunto de asignaciones entre un ámbito de seguridad y un conjunto de permisos. Hay cuatro tipos de permisos: "leer", "crear", "actualizar" y "suprimir".

En el ejemplo siguiente se especifica una función en la que un usuario tiene los permisos "leer" y "crear" para las características relacionadas con la gestión de repositorios, y tiene permisos completos para las características relacionadas con la gestión de imágenes RBD:

{
  'role': 'my_new_role',
  'description': 'My new role',
  'scopes_permissions': {
    'pool': ['read', 'create'],
    'rbd-image': ['read', 'create', 'update', 'delete']
  }
}

La consola ya proporciona un conjunto de funciones predefinidas que llamamos funciones del sistema. Puede usarlas de inmediato después de instalar la Ceph Dashboard:

administrator

Proporciona permisos completos para todos los ámbitos de seguridad.

read-only

Proporciona permiso de lectura para todos los ámbitos de seguridad, excepto para la configuración de la consola.

block-manager

Proporciona permisos completos para los ámbitos "rbd-image", "rbd-mirroring" e "iscsi".

rgw-manager

Proporciona permisos completos para el ámbito "rgw".

cluster-manager

Proporciona permisos completos para los ámbitos "hosts", "osd", "monitor", "manager" y "config-opt".

pool-manager

Proporciona permisos completos para el ámbito "pool".

cephfs-manager

Proporciona permisos completos para el ámbito "cephfs".

11.3.2.1 Gestión de funciones personalizadas #

 

Puede crear nuevas funciones de usuario mediante los siguientes comandos:

Crear una función:

cephuser@adm > ceph dashboard ac-role-create ROLENAME [DESCRIPTION]

Suprimir una función:

cephuser@adm > ceph dashboard ac-role-delete ROLENAME

Añadir permisos de ámbito a una función:

cephuser@adm > ceph dashboard ac-role-add-scope-perms ROLENAME SCOPENAME PERMISSION [PERMISSION...]

Suprimir permisos de ámbito de una función:

cephuser@adm > ceph dashboard ac-role-del-perms ROLENAME SCOPENAME

11.3.2.2 Asignación de funciones a cuentas de usuario #

 

Utilice los comandos siguientes para asignar funciones a los usuarios:

Definir funciones de usuario:

cephuser@adm > ceph dashboard ac-user-set-roles USERNAME ROLENAME [ROLENAME ...]

Añadir funciones adicionales a un usuario:

cephuser@adm > ceph dashboard ac-user-add-roles USERNAME ROLENAME [ROLENAME ...]

Suprimir funciones de un usuario:

cephuser@adm > ceph dashboard ac-user-del-roles USERNAME ROLENAME [ROLENAME ...]

Sugerencia: limpieza de funciones personalizadas

Si crea funciones de usuario personalizadas y tiene previsto eliminar el clúster de Ceph con el runner ceph.purge más adelante, primero debe limpiar las funciones personalizadas. Más detalles en la Sección 13.9, “Eliminación de un clúster de Ceph completo”

11.3.2.3 Ejemplo: creación de un usuario y una función personalizada #

 

En esta sección se describe un procedimiento para crear una cuenta de usuario capaz de gestionar imágenes RBD, ver y crear repositorios de Ceph y tener acceso de solo lectura a cualquier otro ámbito.

1. Cree un usuario llamado tux:

    cephuser@adm > ceph dashboard ac-user-create tux PASSWORD

2. Cree una función y especifique los permisos de ámbito:

   cephuser@adm > ceph dashboard ac-role-create rbd/pool-manager
   cephuser@adm > ceph dashboard ac-role-add-scope-perms rbd/pool-manager \
    rbd-image read create update delete
   cephuser@adm > ceph dashboard ac-role-add-scope-perms rbd/pool-manager pool read create

3. Asocie las funciones con el usuario tux:

   cephuser@adm > ceph dashboard ac-user-set-roles tux rbd/pool-manager read-only

Si desea establecer una URL fija para acceder a Ceph Dashboard, o si no desea permitir conexiones directas con los nodos del gestor, puede configurar un servidor proxy que reenvíe automáticamente las peticiones entrantes a la instancia de ceph-mgr activa.

  cephuser@adm > ceph config set mgr mgr/dashboard/url_prefix URL_PREFIX

cephuser@adm > ceph config set mgr mgr/dashboard/standby_behaviour "error"

cephuser@adm > ceph config set mgr mgr/dashboard/standby_behaviour "redirect"

cephuser@adm > ceph config set mgr mgr/dashboard/standby_error_status_code 503

11.4.4 Configuración de ejemplo de HAProxy #

 

El siguiente ejemplo de configuración es para la transferencia directa TLS/SSL mediante HAProxy.

Nota

La configuración funciona en las siguientes condiciones: si la consola falla, el cliente de procesador frontal puede recibir una respuesta de redirección HTTP (303) y se le redirigirá a un host que no se puede resolver.

Esto ocurre cuando se produce un failover durante dos comprobaciones de estado de HAProxy. En este caso, el nodo de consola anteriormente activo responderá ahora con un 303, que señala al nuevo nodo activo. Para evitarlo, puede inhabilitar el comportamiento de redirección en los nodos en espera.

  defaults
    log global
    option log-health-checks
    timeout connect 5s
    timeout client 50s
    timeout server 450s

  frontend dashboard_front
    mode http
    bind *:80
    option httplog
    redirect scheme https code 301 if !{ ssl_fc }

  frontend dashboard_front_ssl
    mode tcp
    bind *:443
    option tcplog
    default_backend dashboard_back_ssl

  backend dashboard_back_ssl
    mode tcp
    option httpchk GET /
    http-check expect status 200
    server x HOST:PORT ssl check verify none
    server y HOST:PORT ssl check verify none
    server z HOST:PORT ssl check verify none

La API REST de Ceph Dashboard puede registrar peticiones PUT, POST y DELETE en el registro de auditoría de Ceph. El registro está inhabilitado por defecto, pero es posible habilitarlo con el siguiente comando:

cephuser@adm > ceph dashboard set-audit-api-enabled true

Si está habilitado, se registran los parámetros siguientes por cada petición:

Una entrada de registro de ejemplo tiene este aspecto:

2019-02-06 10:33:01.302514 mgr.x [INF] [DASHBOARD] \
 from='https://[::ffff:127.0.0.1]:37022' path='/api/rgw/user/exu' method='PUT' \
 user='admin' params='{"max_buckets": "1000", "display_name": "Example User", "uid": "exu", "suspended": "0", "email": "user@example.com"}'

Sugerencia: inhabilitación del registro de la carga útil de la petición

El registro de la carga útil de la petición (la lista de argumentos y sus valores) está habilitado por defecto. Puede inhabilitarlo de la siguiente manera:

cephuser@adm > ceph dashboard set-audit-api-log-payload false

Ceph Dashboard puede gestionar las exportaciones de NFS Ganesha que utilizan CephFS u Object Gateway como almacén secundario. La consola gestiona los archivos de configuración de NFS Ganesha almacenados en objetos RADOS en el clúster de CephFS. NFS Ganesha debe almacenar parte de su configuración en el clúster de Ceph.

Ejecute el comando siguiente para configurar la ubicación del objeto de configuración de NFS Ganesha:

cephuser@adm > ceph dashboard set-ganesha-clusters-rados-pool-namespace pool_name[/namespace]

Ahora puede gestionar las exportaciones de NFS Ganesha mediante Ceph Dashboard.

cephuser@adm > ceph dashboard set-ganesha-clusters-rados-pool-namespace cluster_id:pool_name[/namespace](,cluster_id:pool_name[/namespace])*

Los complementos de Ceph Dashboard amplían la funcionalidad de la consola. El complemento de depuración permite personalizar el comportamiento de la consola según el modo de depuración. Puede habilitarse, inhabilitarse o comprobarse con el comando siguiente:

cephuser@adm > ceph dashboard debug status
Debug: 'disabled'
cephuser@adm > ceph dashboard debug enable
Debug: 'enabled'
cephuser@adm > dashboard debug disable
Debug: 'disabled'

Por defecto, está inhabilitado. Este es el valor recomendado para las distribuciones de producción. Si es necesario, se puede habilitar el modo de depuración sin necesidad de reiniciar.

Puede averiguar el estado inmediato del clúster mediante ceph status o ceph -s:

cephuser@adm > ceph -s
cluster:
    id:     b4b30c6e-9681-11ea-ac39-525400d7702d
    health: HEALTH_OK

  services:
    mon: 5 daemons, quorum ses-min1,ses-master,ses-min2,ses-min4,ses-min3 (age 2m)
    mgr: ses-min1.gpijpm(active, since 3d), standbys: ses-min2.oopvyh
    mds: my_cephfs:1 {0=my_cephfs.ses-min1.oterul=up:active}
    osd: 3 osds: 3 up (since 3d), 3 in (since 11d)
    rgw: 2 daemons active (myrealm.myzone.ses-min1.kwwazo, myrealm.myzone.ses-min2.jngabw)

  task status:
    scrub status:
        mds.my_cephfs.ses-min1.oterul: idle

  data:
    pools:   7 pools, 169 pgs
    objects: 250 objects, 10 KiB
    usage:   3.1 GiB used, 27 GiB / 30 GiB avail
    pgs:     169 active+clean

La salida proporciona la siguiente información:

Sugerencia: cómo calcula Ceph el uso de datos

El valor used (utilizado) refleja la cantidad real de almacenamiento en bruto utilizado. El número menor del valor xxx GB / xxx GB indica la cantidad disponible de la capacidad de almacenamiento global del clúster. El número teórico refleja el tamaño de los datos almacenados antes de que se repliquen, se clonen o se capturen en una instantánea. Por lo tanto, la cantidad de datos que se almacena realmente suele superar el almacenamiento teórico, dado que Ceph crea réplicas de los datos y también puede utilizar la capacidad de almacenamiento para tareas de clonación y de captura de instantáneas.

Otros comandos que muestran la información de estado inmediato son los siguientes:

Para obtener la información actualizada en tiempo real, coloque cualquiera de estos comandos (incluyendo ceph -s) como argumento del comando watch:

root # watch -n 10 'ceph -s'

Pulse Control–C cuando quiera detener la visualización.

Una vez iniciado el clúster y antes de empezar a leer o escribir datos, compruebe su estado:

cephuser@adm > ceph health
HEALTH_WARN 10 pgs degraded; 100 pgs stuck unclean; 1 mons down, quorum 0,2 \
node-1,node-2,node-3

Sugerencia

Si ha especificado ubicaciones distintas de las establecidas por defecto para la configuración o el anillo de claves, puede indicarlas:

cephuser@adm > ceph -c /path/to/conf -k /path/to/keyring health

El clúster de Ceph devolverá uno de los siguientes códigos de estado:

Sugerencia

Si ha especificado ubicaciones distintas de las establecidas por defecto para la configuración o el anillo de claves, puede indicarlas:

root # ceph -c /path/to/conf -k /path/to/keyring health

Para comprobar el uso de datos de un clúster y la distribución de datos entre los repositorios, utilice el comando ceph df. Para obtener más detalles, utilice ceph df detail.

cephuser@adm > ceph df
--- RAW STORAGE ---
CLASS  SIZE    AVAIL   USED     RAW USED  %RAW USED
hdd    30 GiB  27 GiB  121 MiB   3.1 GiB      10.40
TOTAL  30 GiB  27 GiB  121 MiB   3.1 GiB      10.40

--- POOLS ---
POOL                   ID  STORED   OBJECTS  USED     %USED  MAX AVAIL
device_health_metrics   1      0 B        0      0 B      0    8.5 GiB
cephfs.my_cephfs.meta   2  1.0 MiB       22  4.5 MiB   0.02    8.5 GiB
cephfs.my_cephfs.data   3      0 B        0      0 B      0    8.5 GiB
.rgw.root               4  1.9 KiB       13  2.2 MiB      0    8.5 GiB
myzone.rgw.log          5  3.4 KiB      207    6 MiB   0.02    8.5 GiB
myzone.rgw.control      6      0 B        8      0 B      0    8.5 GiB
myzone.rgw.meta         7      0 B        0      0 B      0    8.5 GiB

La sección RAW STORAGE del resultado proporciona una descripción general de la cantidad de almacenamiento que utiliza el clúster para los datos.

La sección POOLS de la salida proporciona una lista de los repositorios y el uso teórico de cada uno de ellos. La salida de esta sección no refleja las réplicas, las clonaciones ni las instantáneas. Por ejemplo, si almacena un objeto con 1 MB de datos, el uso teórico es de 1 MB, pero el uso real puede ser de 2 MB o más, según el número de réplicas, clonaciones e instantáneas.

Nota

Las cifras de la sección POOLS son teóricas. No incluyen el número de réplicas, clonaciones o instantáneas. Por lo tanto, la suma de las cantidades de USED y %USED no se sumará a las cantidades de RAW USED y %RAW USED de la sección RAW STORAGE del resultado.

Para comprobar los OSD y asegurarse de que estén activos y conectados, ejecute:

cephuser@adm > ceph osd stat

O bien

cephuser@adm > ceph osd dump

También puede ver los OSD según su posición en la asignación de CRUSH.

ceph osd tree imprime un árbol de CRUSH con un host, sus OSD, su estado de funcionamiento y su peso:

   cephuser@adm > ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME              STATUS  REWEIGHT  PRI-AFF
-1      3  0.02939  root default
-3      3  0.00980    rack mainrack
-2      3  0.00980            host osd-host
0       1  0.00980                    osd.0   up   1.00000   1.00000
1       1  0.00980                    osd.1   up   1.00000   1.00000
2       1  0.00980                    osd.2   up   1.00000   1.00000

Ceph impide escribir en un OSD lleno para que no se pierden datos. En un clúster en funcionamiento, debería aparecer una advertencia cuando el clúster se esté aproximando al máximo de su capacidad. El valor por defecto de mon osd full ratio es de 0,95 o un 95 % de capacidad para impedir la escritura de datos a los clientes. El valor por defecto de mon osd nearfull ratio es de 0,85 o 85 % de capacidad para generar una advertencia de estado.

El comando ceph health informa de los nodos de OSD llenos:

cephuser@adm > ceph health
  HEALTH_WARN 1 nearfull osds
  osd.2 is near full at 85%

O bien

cephuser@adm > ceph health
  HEALTH_ERR 1 nearfull osds, 1 full osds
  osd.2 is near full at 85%
  osd.3 is full at 97%

La mejor forma de ocuparse de un clúster lleno es añadir hosts de OSD o discos para que el clúster redistribuya los datos en el nuevo espacio de almacenamiento disponible.

Sugerencia: cómo evitar que los OSD se llenen

Si un OSD se llena (usa el 100 % de su espacio de disco), normalmente se bloqueará de inmediato y sin previo aviso. A continuación indicamos algunos consejos que conviene recordar al administrar nodos de OSD.

• El espacio de disco de cada OSD (normalmente montado en /var/lib/ceph/osd/osd-{1,2..}) debe colocarse en un disco o en una partición de uso dedicado.

• Compruebe los archivos de configuración de Ceph y asegúrese de que Ceph no almacena el archivo de registro en las particiones o los discos cuyo uso esté dedicado a los OSD.

• Asegúrese de que ningún otro proceso escribe en los discos o en las particiones de uso dedicado de los OSD.

Después de iniciar el clúster y antes de leer o escribir datos por primera vez, compruebe el estado de quórum de los monitores Ceph Monitor. Si el clúster ya está sirviendo peticiones, compruebe periódicamente el estado de los monitores Ceph Monitor para asegurarse de que se están ejecutando.

Para ver la asignación de monitores, ejecute lo siguiente:

cephuser@adm > ceph mon stat

O bien

cephuser@adm > ceph mon dump

Para comprobar el estado de quórum del clúster de monitores, ejecute lo siguiente:

cephuser@adm > ceph quorum_status

Ceph devolverá el estado de quórum. Por ejemplo, un clúster de Ceph que consta de tres monitores podría devolver lo siguiente:

{ "election_epoch": 10,
  "quorum": [
        0,
        1,
        2],
  "monmap": { "epoch": 1,
      "fsid": "444b489c-4f16-4b75-83f0-cb8097468898",
      "modified": "2011-12-12 13:28:27.505520",
      "created": "2011-12-12 13:28:27.505520",
      "mons": [
            { "rank": 0,
              "name": "a",
              "addr": "192.168.1.10:6789\/0"},
            { "rank": 1,
              "name": "b",
              "addr": "192.168.1.11:6789\/0"},
            { "rank": 2,
              "name": "c",
              "addr": "192.168.1.12:6789\/0"}
           ]
    }
}

Los grupos de colocación asignan objetos a los OSD. Al supervisar los grupos de colocación, es conveniente que tengan los estados active (activo) y clean (limpio). Para obtener información detallada, consulte la Sección 12.9, “Supervisión de los OSD y los grupos de colocación”.

Cuando un clúster de almacenamiento de Ceph se acerca a su capacidad máxima, Ceph impide escribir o leer desde los Ceph OSD como medida de seguridad para evitar la pérdida de datos. Por lo tanto, permitir que un clúster de producción se acerque a su máximo de capacidad no es una buena práctica, ya que se sacrifica la alta disponibilidad. El máximo de capacidad por defecto se define en .95, lo que significa el 95 % de la capacidad. Se trata de un valor muy agresivo para un clúster de pruebas con un número pequeño de OSD.

Sugerencia: aumento de la capacidad de almacenamiento

Al supervisar el clúster, esté alerta a las advertencias relacionadas con la proporción de nearfull (casi lleno). Significa que un error de algunos OSD podría dar lugar a una interrupción temporal del servicio si se produce un error en uno o más OSD. Considere la posibilidad de añadir más OSD para aumentar la capacidad de almacenamiento.

Un escenario habitual para los clústeres de prueba es la de un administrador del sistema que elimina un Ceph OSD del clúster de almacenamiento de Ceph para observar el reequilibrio del clúster. A continuación, quita otro Ceph OSD, y así sucesivamente hasta que el clúster finalmente alcanza su máxima capacidad y se bloquea. Se recomienda cierta planificación de la capacidad incluso en el caso de un clúster de pruebas. La planificación permite estimar la capacidad de repuesto que se necesitará para poder mantener la alta disponibilidad. En una situación ideal, desea planear una serie de errores del Ceph OSD en los que el clúster puede recuperarse a un estado activo + limpio sin tener que sustituir esos Ceph OSD de inmediato. Puede ejecutar un clúster en un estado activo + degradado, pero no es lo ideal para condiciones de funcionamiento normales.

En el diagrama siguiente se muestra un clúster de almacenamiento de Ceph simplificado que contiene 33 nodos Ceph con un Ceph OSD por host. Cada uno de ellos lee y escribe en una unidad de 3 TB. Este clúster de ejemplo tiene una capacidad real máxima de 99 TB. La opción mon osd full ratio se define en 0,95. Si el clúster cae por debajo de los 5 TB de capacidad restante, no permitirá que los clientes lean y escriban datos. Por lo tanto, la capacidad operativa del clúster de almacenamiento es de 95 TB, no de 99 TB.

Figura 12.1: Clúster de Ceph #

 

En este tipo de clúster, es normal que uno o dos OSD fallen. Un escenario menos frecuente, aunque razonable, implica que el router o la fuente de alimentación de un bastidor falle, lo que desactiva varios OSD simultáneamente (por ejemplo, los OSD del 7 al 12). En esa situación, debe seguir intentando que un clúster pueda permanecer operativo y logre un estado activo + limpio, incluso si eso significa añadir algunos hosts con OSD adicionales a corto plazo. Si el uso de la capacidad es demasiado alto, es posible que no pierda datos. Sin embargo, aún podría sacrificar la disponibilidad de los datos y resolver al mismo tiempo una interrupción dentro de un dominio de error si el uso de capacidad del clúster supera el máximo. Por este motivo, se recomienda que se realice al menos una planificación aproximada de la capacidad.

Identifique dos valores para el clúster:

Si divide la capacidad total del clúster por el número de OSD del clúster, encontrará la capacidad media de un OSD dentro del clúster. También puede multiplicar ese número por el número de OSD que espera que fallen simultáneamente durante las operaciones normales (un número relativamente pequeño). Por último, multiplique la capacidad del clúster por la capacidad máxima para descubrir la capacidad operativa máxima. A continuación, reste la cantidad de datos de los OSD que espera que no lleguen al máximo de capacidad razonable. Repita el proceso anterior con un mayor número de errores de OSD (un bastidor de OSD) para llegar a un número razonable capacidad casi máxima.

Los valores siguiente solo se aplica durante la creación del clúster y, después, se almacena en el mapa de OSD:

[global]
 mon osd full ratio = .80
 mon osd backfillfull ratio = .75
 mon osd nearfull ratio = .70

Sugerencia

Estos valores solo se aplican durante la creación del clúster. Después deben cambiarse en el mapa de OSD utilizando los comandos ceph osd set-nearfull-ratio y ceph osd set-full-ratio.

Sugerencia: comprobación del peso del OSD

Si algunos OSD están casi llenos, pero otros tienen mucha capacidad, es posible que tenga un problema con el peso de CRUSH para los OSD casi llenos.

La alta disponibilidad y la alta confiabilidad requieren un enfoque tolerante a fallos para gestionar problemas de hardware y software. Ceph no tiene un único punto de error y puede atender peticiones de datos en un modo "degradado". La colocación de datos de Ceph introduce una capa de direccionamiento indirecto para garantizar que los datos no se enlacen directamente a determinadas direcciones de OSD. Eso significa que para el seguimiento de los errores del sistema es necesario buscar el grupo de colocación y los OSD subyacentes en la raíz del problema.

Sugerencia: acceso en caso de fallo

Un error en una parte del clúster puede impedir que se acceda a un objeto determinado. Eso no significa que no se pueda acceder a otros objetos. Si encuentra un error, siga los pasos para supervisar los OSD y los grupos de colocación. A continuación, comience el proceso de solución de problemas.

Ceph, generalmente, se puede autorreparar. Sin embargo, si los problemas persisten, la supervisión de los OSD y los grupos de colocación ayudará a identificar el problema.

12.9.1 Supervisión de OSD #

 

El estado de un OSD se encuentra en el clúster ("in") o fuera del clúster ("out"). Al mismo tiempo, está en activo y en ejecución ("up") o desactivado y sin ejecutarse ("down"). Si un OSD está "up", puede estar en el clúster (es posible leer y escribir datos) o fuera del clúster. Si estaba en el clúster y se movió recientemente fuera del clúster, Ceph migrará los grupos de colocación a otros OSD. Si un OSD está fuera del clúster, CRUSH no le asignará grupos de colocación. Si un OSD está "down", también debe estar "out".

Nota: estado incorrecto

Si un OSD está "down" e "in", hay un problema y el clúster no estará en un estado correcto.

Si ejecuta un comando como ceph health, ceph -s o ceph -w, puede darse el caso de que el clúster no siempre devuelva el estado HEALTH OK. Con respecto a los OSD, debe esperar que el clúster no devuelva HEALTH OK en las siguientes circunstancias:

• Todavía no ha iniciado el clúster (no responderá).

• Ha iniciado o reiniciado el clúster y aún no está listo, ya que se están creando los grupos de colocación y los OSD están en proceso de emparejamiento.

• Ha añadido o eliminado un OSD.

• Ha modificado el mapa del clúster.

Un aspecto importante de la supervisión de los OSD es asegurarse de que cuando el clúster está activo y en ejecución, todos los OSD del clúster también lo estén. Para comprobar si todos los OSD se están ejecutando, ejecute:

root # ceph osd stat
x osds: y up, z in; epoch: eNNNN

El resultado debería indicarle el número total de OSD (x), cuántos están "up" (y), cuántos están "in" (z) y la época del mapa (eNNNN). Si el número de OSD que están "in" en el clúster es mayor que el número de OSD que están "up", ejecute el comando siguiente para identificar los daemons ceph-osd que no se están ejecutando:

root # ceph osd tree
#ID CLASS WEIGHT  TYPE NAME             STATUS REWEIGHT PRI-AFF
-1       2.00000 pool openstack
-3       2.00000 rack dell-2950-rack-A
-2       2.00000 host dell-2950-A1
0   ssd 1.00000      osd.0                up  1.00000 1.00000
1   ssd 1.00000      osd.1              down  1.00000 1.00000

Por ejemplo, si un OSD con ID 1 está inactivo, para iniciarlo:

cephuser@osd > sudo systemctl start ceph-CLUSTER_ID@osd.0.service

Consulte el Book “Troubleshooting Guide”, Chapter 4 “Troubleshooting OSDs”, Section 4.3 “OSDs not running” para consultar los problemas asociados con los OSD que se han detenido o que no se reinician.

12.9.2 Asignación de conjuntos de grupos de colocación #

 

Cuando CRUSH asigna grupos de colocación a los OSD, examina el número de réplicas del repositorio y asigna el grupo de colocación a los OSD de forma que cada réplica del grupo de colocación se asigne a un OSD diferente. Por ejemplo, si el repositorio requiere tres réplicas de un grupo de colocación, CRUSH puede asignarlas a osd.1, osd.2 y osd.3 respectivamente. CRUSH en realidad intenta realizar una colocación seudoaleatoria que tenga en cuenta los dominios de error que establezca en su mapa de CRUSH, por lo que rara vez verá grupos de colocación asignados a los OSD vecinos más cercanos en un clúster grande. El conjunto de OSD que deben contener las réplicas de un grupo de colocación determinado se conoce como conjunto que actúa. En algunos casos, un OSD del conjunto que actúa está inactivo o no puede atender las peticiones de objetos del grupo de colocación. Si se da ese caso, puede deberse a uno de los siguientes escenarios:

• Ha añadido o eliminado un OSD. En tal caso, CRUSH reasignó el grupo de colocación a otros OSD y, por lo tanto, cambió la composición del conjunto que actúa, lo que provocó la migración de datos con un proceso de "reposición".

• Un OSD con el estado "down", se ha reiniciado y ahora se está recuperando.

• Un OSD del conjunto que actúa tiene el estado "down" o no puede atender peticiones, y otro OSD ha asumido temporalmente sus funciones.

  Ceph procesa la petición de un cliente con conjunto activo, que es el conjunto de OSD que realmente controlarán las peticiones. En la mayoría de los casos, el conjunto activo y el conjunto que actúa son prácticamente idénticos. Cuando no lo son, puede indicar que Ceph está migrando datos, que un OSD se está recuperando o que hay un problema (por ejemplo, Ceph suele responde a un estado HEALTH WARN con un mensaje "bloqueo obsoleto" en tales casos).

Para recuperar una lista de grupos de colocación, ejecute:

cephuser@adm > ceph pg dump

Para ver qué OSD están dentro del conjunto que actúa o del conjunto activo para un grupo de colocación determinado, ejecute:

cephuser@adm > ceph pg map PG_NUM
osdmap eNNN pg RAW_PG_NUM (PG_NUM) -> up [0,1,2] acting [0,1,2]

El resultado debe indicar la época de osdmap (eNNN), el número del grupo de colocación (PG_NUM), los OSD del conjunto activo ("up") y los OSD del conjunto que actúa ("acting"):

Sugerencia: indicador de problema del clúster

Si el conjunto activo y el conjunto que actúa no coinciden, puede ser un indicador de que el clúster se está reequilibrando o de que hay un posible problema con el clúster.

12.9.3 Emparejamiento #

 

Para poder escribir datos en un grupo de colocación, este debe estar en un estado activo y es recomendable que esté en un estado limpio. Para que Ceph determine el estado actual de un grupo de colocación, el OSD primario del grupo de colocación (el primer OSD del conjunto que actúa) se empareja con los OSD secundario y terciario para establecer un acuerdo sobre el estado actual del grupo de colocación (suponiendo que el repositorio tenga tres réplicas del grupo de colocación).

Figura 12.2: Esquema de emparejamiento #

 

12.9.4 Supervisión de los estados del grupo de colocación #

 

Si ejecuta un comando como ceph health, ceph -s o ceph -w, puede darse el caso de que el clúster no siempre devuelva el mensaje HEALTH OK. Después de comprobar si los OSD se están ejecutando, también debe comprobar los estados del grupo de colocación.

Es previsible que el clúster no devuelva HEALTH OK en varias circunstancias relacionadas con el emparejamiento del grupo de colocación:

• Ha creado un repositorio y los grupos de colocación aún no se han emparejado.

• Los grupos de colocación se están recuperando.

• Ha añadido o ha eliminado un OSD del clúster.

• Ha modificado el mapa de CRUSH y los grupos de colocación están migrando.

• Hay datos incoherentes en diferentes réplicas de un grupo de colocación.

• Ceph está borrando de forma segura las réplicas de un grupo de colocación.

• Ceph no tiene suficiente capacidad de almacenamiento para completar las operaciones de reposición.

Si una de las circunstancias mencionadas hace que Ceph devuelva el estado HEALTH WARN, no se preocupe. En muchos casos, el clúster se recuperará por sí solo. En algunos casos, es posible que deba tomar alguna medida. Un aspecto importante a la hora de supervisar los grupos de colocación es que debe asegurarse de que cuando el clúster esté activo y en funcionamiento, todos los grupos de colocación deben estar "activos" y, preferiblemente, en un "estado limpio". Para ver el estado de todos los grupos de colocación, ejecute:

cephuser@adm > ceph pg stat
x pgs: y active+clean; z bytes data, aa MB used, bb GB / cc GB avail

El resultado debe indicar el número total de grupos de colocación (x); cuántos grupos de colocación están en un estado determinado, como "activo+limpio" (y) y la cantidad de datos almacenados (z).

Además de los estados del grupo de colocación, Ceph también devolverá la cantidad de capacidad de almacenamiento utilizada (aa), la cantidad de capacidad de almacenamiento restante (bb) y la capacidad de almacenamiento total para el grupo de colocación. Estos valores pueden ser importantes en algunos casos:

• Cuando se está alcanzando la capacidad casi máxima o la capacidad máxima.

• Cuando los datos no se están distribuyendo por el clúster debido a un error en la configuración de CRUSH.

Sugerencia: ID de grupos de colocación

Los ID de grupo de colocación constan del número de repositorio (no el nombre del repositorio ) seguido de un punto (.) y el ID del grupo de colocación (un número hexadecimal). Puede ver los números de repositorio y sus nombres en el resultado de ceph osd lspools. Por ejemplo, el repositorio por defecto rbd corresponde al número de repositorio 0. Un ID de grupo de colocación completo tiene el siguiente formato:

POOL_NUM.PG_ID

Y, normalmente, este aspecto:

0.1f

Para recuperar una lista de grupos de colocación, ejecute lo siguiente:

cephuser@adm > ceph pg dump

También puede dar al resultado formato JSON y guardarlo en un archivo:

cephuser@adm > ceph pg dump -o FILE_NAME --format=json

Para consultar un grupo de colocación determinado, ejecute lo siguiente:

cephuser@adm > ceph pg POOL_NUM.PG_ID query

En la lista siguiente se describen en detalle los estados habituales del grupo de colocación.

CREATING (CREACIÓN)

Cuando se crea un repositorio, se crea el número de grupos de colocación especificados. Ceph devolverá el mensaje "creating" cuando está creando uno o más grupos de colocación. Cuando se creen, los OSD que formen parte del conjunto que actúa del grupo de colocación se emparejarán. Cuando el emparejamiento se haya completado, el estado del grupo de colocación debe ser "activo+limpio", lo que significa que un cliente de Ceph puede comenzar a escribir en el grupo de colocación.

Figura 12.3: Estado de los grupos de colocación #

 

PEERING (EMPAREJAMIENTO)

Cuando Ceph empareja un grupo de colocación, está poniendo de acuerdo los OSD donde se almacenan las réplicas del grupo de colocación sobre el estado de los objetos y los metadatos del grupo de colocación. Cuando Ceph completa el emparejamiento, significa que los OSD donde se almacenan el grupo de colocación están de acuerdo sobre el estado actual de dicho grupo. Sin embargo, que el proceso de emparejamiento haya finalizado no significa que cada réplica tenga el contenido más reciente.

Nota: historial oficial

Ceph no reconocerá una operación de escritura a un cliente hasta que todos los OSD del conjunto que actúa persistan en la operación de escritura. Esta práctica garantiza que al menos un miembro del conjunto que actúa tendrá un registro de cada operación de escritura reconocida desde la última operación de emparejamiento correcta.

Con un registro preciso de cada operación de escritura reconocida, Ceph puede construir y ampliar un nuevo historial oficial del grupo de colocación: un conjunto completo y completamente ordenado de operaciones que, si se realiza, actualizaría una copia del OSD de un grupo de colocación.

ACTIVE (ACTIVO)

Cuando Ceph completa el proceso de emparejamiento, un grupo de colocación puede convertirse en activo. El estado activo significa que los datos del grupo de colocación están generalmente disponibles en el grupo de colocación primario y en las réplicas para las operaciones de lectura y escritura.

CLEAN (LIMPIO)

Cuando un grupo de colocación está en estado limpio, el OSD primario y los OSD de réplica se han emparejado correctamente y no hay réplicas perdidas para el grupo de colocación. Ceph ha replicado todos los objetos del grupo de colocación el número correcto de veces.

DEGRADED (DEGRADADO)

Si un cliente escribe un objeto en el OSD primario, este es responsable de escribir las réplicas en los OSD de réplica. Después de que el OSD primario escriba el objeto en el almacenamiento, el grupo de colocación permanecerá en un estado "degradado" hasta que el OSD primario haya recibido una confirmación de los OSD de réplica de que Ceph ha creado los objetos de réplica correctamente.

La razón por la que un grupo de colocación puede tener el estado "activo+degradado" es que un OSD puede estar "activo" aunque aún no contenga todos los objetos. Si un OSD deja de estar activo, Ceph marca cada grupo de colocación asignado al OSD como "degradado". Los OSD deben emparejarse de nuevo cuando el OSD vuelva a funcionar. Sin embargo, un cliente todavía puede escribir un objeto nuevo en un grupo de colocación degradado si su estado es "activo".

Si un OSD está "inactivo" y la condición "degradado" persiste, Ceph puede marcar el OSD inactivo como "externo" al clúster y volver a asignar los datos del OSD "inactivo" a otro OSD. El tiempo que transcurre entre que se marca como "inactivo" y se marca como "externo" se controla mediante la opción mon osd out interval, que se establece en 600 segundos por defecto.

Un grupo de colocación también puede estar "degradado" porque Ceph no pueda encontrar uno o varios objetos que deberían estar en el grupo de colocación. Aunque no puede leer ni escribir en objetos no encontrados, puede acceder a todos los demás objetos del grupo de colocación "degradado".

RECOVERING (EN RECUPERACIÓN)

Ceph se ha diseñado para la tolerancia a fallos a una escala en la que los problemas de hardware y software son continuos. Cuando un OSD está "inactivo", su contenido puede quedar obsoleto respecto al de otras réplicas de los grupos de colocación. Cuando el OSD vuelve a estar "activo", el contenido de los grupos de colocación debe actualizarse para reflejar el estado actual. Durante ese período de tiempo, el OSD puede mostrar el estado de "en recuperación".

La recuperación no siempre es sencilla, ya que un error de hardware puede provocar un error en cascada de varios OSD. Por ejemplo, puede fallar un conmutador de red de un bastidor o un archivador, lo que puede provocar que el estado actual de los OSD de varias máquinas host quede retrasado respecto al clúster. Cada uno de los OSD debe recuperarse cuando se resuelva el error.

Ceph proporciona varios ajustes para equilibrar la contención de los recursos entre las peticiones de servicio nuevas y la necesidad de recuperar objetos de datos y restaurar los grupos de colocación al estado actual. El valor osd recovery delay start permite que un OSD se reinicie, vuelva a emparejarse e, incluso, que procese algunas peticiones de respuesta antes de iniciar el proceso de recuperación. El valor osd recovery thread timeout define un tiempo límite del hilo, ya que varios OSD pueden fallar, reiniciarse y volver a emparejarse escalonadamente. El valor osd recovery max active limita el número de peticiones de recuperación que un OSD procesará simultáneamente para evitar que el OSD no pueda atender las peticiones. El valor osd recovery max chunk limita el tamaño de los fragmentos de datos recuperados para evitar la congestión de la red.

BACK FILLING (EN REPOSICIÓN)

Cuando un nuevo OSD se une al clúster, CRUSH reasignará los grupos de colocación de los OSD del clúster al OSD recién añadido. Forzar al nuevo OSD a aceptar los grupos de colocación reasignados de inmediato, podría suponer una carga excesiva en el OSD nuevo. Al reponer los grupos de colocación en el OSD, este proceso puede comenzar en segundo plano. Una vez completado la reposición, el nuevo OSD comenzará a atender las peticiones cuando esté listo.

Durante las operaciones de reposición, es posible que vea uno de estos estados: "backfill_wait" indica que una operación de reposición está pendiente, pero aún no está en curso; "backfill" indica que una operación de reposición está en curso; "backfill_too_full" indica que se ha solicitado una operación de reposición, pero no se ha podido completar debido a que no hay capacidad de almacenamiento suficiente. Si no se puede realizar la reposición de un grupo de colocación, puede considerarse como "incompleto".

Ceph proporciona varios ajustes para gestionar la carga asociada con la reasignación de grupos de colocación a un OSD (especialmente un OSD nuevo). Por defecto, osd max backfills define que el número máximo de reposiciones simultáneas hacia o desde un OSD sea de 10. El valor backfill full ratio permite que un OSD rechace una petición de reposición si el OSD se acerca a su capacidad máxima (90 %, por defecto), que se cambia con ceph osd set-backfillfull-ratio. Si un OSD rechaza una petición de reposición, el valor osd backfill retry interval permite que un OSD vuelva a intentar la petición (después de 10 segundos, por defecto). También es posible definir en los OSD los valores osd backfill scan min y osd backfill scan max para gestionar los intervalos de escaneo (64 y 512, por defecto).

REMAPPED (REASIGNADO)

Cuando cambia el conjunto que actúa que atiende a un grupo de colocación, los datos migran del conjunto que actúa antiguo al nuevo. El nuevo OSD primario puede tardar algún tiempo en atender las peticiones de servicio. Por lo tanto, puede pedir al OSD primario antiguo que continúe atendiendo las peticiones hasta que se complete la migración del grupo de colocación. Cuando se completa la migración de los datos, la asignación utiliza el OSD primario del conjunto que actúa nuevo.

STALE (OBSOLETO)

Mientras Ceph utiliza subejecución de réplica para asegurarse de que los hosts y los daemons se están ejecutando, los daemons ceph-osd también pueden entrar en estado "bloqueo", en el que no informan sobre las estadísticas a tiempo (por ejemplo, si se produce un error temporal de la red). Por defecto, los daemons de OSD informan de las estadísticas de su grupo de colocación, del arranque y de los errores cada medio segundo (0,5), que es una frecuencia mayor a la de los umbrales de subejecución de réplica. Si el OSD primario del conjunto que actúa de un grupo de colocación no informa al monitor, o si otros OSD han informado de que el OSD primario está "inactivo", los monitores marcarán el grupo de colocación como "obsoleto".

Al iniciar el clúster, es común ver el estado "obsoleto" hasta que se completa el proceso de emparejamiento. Después de que el clúster se haya estado ejecutando durante un tiempo, ver grupos de colocación con el estado "obsoleto" indica que el OSD primario para esos grupos de colocación está inactivo o no informa sobre las estadísticas del grupo de colocación al monitor.

cephuser@adm > ceph osd map POOL_NAME OBJECT_NAME [NAMESPACE]

cephuser@adm > rados put test-object-1 testfile.txt --pool=data

cephuser@adm > rados -p data ls

cephuser@adm > ceph osd map data test-object-1
osdmap e537 pool 'data' (0) object 'test-object-1' -> pg 0.d1743484 \
(0.4) -> up ([1,0], p0) acting ([1,0], p0)

cephuser@adm > rados rm test-object-1 --pool=data

Para modificar la configuración de un clúster de Ceph existente, siga estos pasos:

Para añadir un nodo nuevo a un clúster de Ceph, siga estos pasos:

Sugerencia: eliminación de OSD

Si el nodo que va a eliminar ejecuta OSD, elimínelos primero y compruebe que no hay ningún OSD en ejecución en ese nodo. Consulte la Sección 13.4.4, “Eliminación de OSD” para obtener más información sobre la eliminación de OSD.

Para eliminar un nodo de un clúster, haga lo siguiente:

Importante

En caso de que se produzca un fallo y el minion que está intentando eliminar se encuentre apagado permanentemente, deberá eliminar el nodo del master de Salt:

root@master # salt-key -d minion_id

A continuación, elimine manualmente el nodo de raíz_pilar/ceph-salt.sls. Normalmente se encuentra en /srv/pillar/ceph-salt.sls.

En esta sección se describe cómo añadir, borrar o eliminar OSD en un clúster de Ceph.

cephuser@adm > ceph orch device ls
HOST       PATH      TYPE SIZE  DEVICE  AVAIL REJECT REASONS
ses-master /dev/vda  hdd  42.0G         False locked
ses-min1   /dev/vda  hdd  42.0G         False locked
ses-min1   /dev/vdb  hdd  8192M  387836 False locked, LVM detected, Insufficient space (<5GB) on vgs
ses-min2   /dev/vdc  hdd  8192M  450575 True

13.4.2 Borrado de dispositivos de disco #

 

Para reutilizar un dispositivo de disco, primero debe borrarlo (comando zap):

ceph orch device zap HOST_NAME DISK_DEVICE

Por ejemplo:

cephuser@adm > ceph orch device zap ses-min2 /dev/vdc

Nota

Si ha distribuido previamente los OSD mediante DriveGroups o con la opción --all-available-devices sin que se haya definido el indicador unmanaged, cephadm distribuirá estos OSD automáticamente después de borrarlos.

13.4.3 Adición de OSD mediante la especificación DriveGroups #

 

DriveGroups especifica los diseños de los OSD del clúster de Ceph. Se definen en un único archivo YAML. En esta sección, utilizaremos drive_groups.yml como ejemplo.

Un administrador debe especificar manualmente un grupo de OSD que estén interrelacionados (OSD híbridos que se distribuyen en una mezcla de unidades HDD y SDD) o que compartan opciones de distribución idénticas (por ejemplo, el mismo almacén de objetos, la misma opción de cifrado y varios OSD independientes). Para no tener que mostrar explícitamente los dispositivos, DriveGroups utiliza una lista de elementos de filtro que corresponden a algunos campos seleccionados de los informes de inventario de ceph-volume. cephadm proporciona código que traduce esta especificación DriveGroups en listas de dispositivos reales para que el usuario las pueda inspeccionar.

El comando para aplicar la especificación de OSD al clúster es:

cephuser@adm > ceph orch apply osd -i drive_groups.yml

Para ver una vista previa de las acciones y probar la aplicación, puede utilizar la opción --dry-run junto con el comando ceph orch apply osd. Por ejemplo:

cephuser@adm > ceph orch apply osd -i drive_groups.yml --dry-run
...
+---------+------+------+----------+----+-----+
|SERVICE  |NAME  |HOST  |DATA      |DB  |WAL  |
+---------+------+------+----------+----+-----+
|osd      |test  |mgr0  |/dev/sda  |-   |-    |
|osd      |test  |mgr0  |/dev/sdb  |-   |-    |
+---------+------+------+----------+----+-----+

Si el resultado de --dry-run cumple sus expectativas, solo tiene que volver a ejecutar el comando sin la opción --dry-run.

13.4.3.1 OSD no gestionados #

 

Todos los dispositivos de disco limpios disponibles que coincidan con la especificación DriveGroups se utilizarán automáticamente como OSD después de añadirlos al clúster. Este comportamiento se denomina modo gestionado.

Para inhabilitar el modo gestionado, añada la línea unmanaged: true a las especificaciones relevantes, por ejemplo:

service_type: osd
service_id: example_drvgrp_name
placement:
 hosts:
 - ses-min2
 - ses-min3
encrypted: true
unmanaged: true

Sugerencia

Para cambiar los OSD ya distribuidos del modo gestionado al modo no gestionado, añada las líneas unmanaged: true cuando corresponda durante el procedimiento descrito en la Sección 13.1, “Modificación de la configuración del clúster”.

13.4.3.2 Especificación DriveGroups #

 

A continuación se muestra un ejemplo de archivo de especificación DriveGroups:

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  drive_spec: DEVICE_SPECIFICATION
db_devices:
  drive_spec: DEVICE_SPECIFICATION
wal_devices:
  drive_spec: DEVICE_SPECIFICATION
block_wal_size: '5G'  # (optional, unit suffixes permitted)
block_db_size: '5G'   # (optional, unit suffixes permitted)
encrypted: true       # 'True' or 'False' (defaults to 'False')

Nota

La opción denominada anteriormente "encryption" en DeepSea ahora se llama "encrypted". Al aplicar DriveGroups en SUSE Enterprise Storage 7, asegúrese de utilizar esta nueva terminología en la especificación del servicio; de lo contrario, la operación ceph orch apply fallará.

13.4.3.3 Filtrado de dispositivos de disco #

 

Puede describir la especificación utilizando los filtros siguientes:

• Por modelo del disco:

  model: DISK_MODEL_STRING

• Por proveedor del disco:

  vendor: DISK_VENDOR_STRING

  

  Sugerencia

  Escriba siempre DISK_VENDOR_STRING en minúsculas.

  Para obtener detalles sobre el modelo de disco y el proveedor, examine el resultado del siguiente comando:

  cephuser@adm > ceph orch device ls
  HOST     PATH     TYPE  SIZE DEVICE_ID                  MODEL            VENDOR
  ses-min1 /dev/sdb ssd  29.8G SATA_SSD_AF34075704240015  SATA SSD         ATA
  ses-min2 /dev/sda ssd   223G Micron_5200_MTFDDAK240TDN  Micron_5200_MTFD ATA
  [...]

• Indica si un disco es giratorio o no. Las unidades SSD y NVMe no son giratorias.

  rotational: 0

• Distribuya un nodo utilizando todas las unidades disponibles para los OSD:

  data_devices:
    all: true

• También puede limitar el número de discos que coinciden:

  limit: 10

13.4.3.4 Filtrado de dispositivos por tamaño #

 

Es posible filtrar los dispositivos de disco por su tamaño, ya sea por un tamaño exacto o por un intervalo de tamaños. El parámetro size: acepta argumentos con el formato siguiente:

• '10G': incluye discos de un tamaño exacto.

• '10G:40G': incluye discos cuyo tamaño está dentro del intervalo indicado.

• ':10G': incluye discos de 10 GB o menos.

• '40G:': incluye discos de 40 GB o más.

Ejemplo 13.1: Filtrado por tamaño de disco #

 

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  size: '40TB:'
db_devices:
  size: ':2TB'

Nota: comillas obligatorias

Si se usa el delimitador ":", debe incluir el tamaño entre comillas simples, de lo contrario el signo ":" se interpretará como un nuevo hash de configuración.

Sugerencia: accesos directos a unidades

En lugar de gigabytes (G), puede especificar el tamaño en megabytes (M) o en terabytes (T).

13.4.3.5 Ejemplos de DriveGroups #

 

Esta sección incluye ejemplos de diferentes configuraciones de OSD.

Ejemplo 13.2: configuración sencilla #

 

Este ejemplo describe dos nodos con la misma configuración:

• 20 discos duros

  • Proveedor: Intel

  • Modelo: SSD-123-foo

  • Tamaño: 4 TB

• 2 discos SSD

  • Proveedor: Micron

  • Modelo: MC-55-44-ZX

  • Tamaño: 512 GB

El archivo drive_groups.yml correspondiente será el siguiente:

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
db_devices:
  model: MC-55-44-XZ

Esta configuración es sencilla y válida. El problema es que un administrador puede añadir discos de diferentes proveedores en el futuro, y estos no se incluirán. Puede mejorarla reduciendo los filtros en las propiedades principales de las unidades:

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  rotational: 1
db_devices:
  rotational: 0

En el ejemplo anterior, estamos imponiendo que se declaren todos los dispositivos giratorios como "dispositivos de datos" y todos los dispositivos no giratorios se utilizarán como "dispositivos compartidos" (wal, db).

Si sabe que las unidades de más de 2 TB siempre serán los dispositivos de datos más lentos, puede filtrar por tamaño:

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  size: '2TB:'
db_devices:
  size: ':2TB'

Ejemplo 13.3: configuración avanzada #

 

En este ejemplo se describen dos configuraciones distintas: 20 discos duros deben compartir 2 unidades SSD, mientras que 10 unidades SSD deben compartir 2 NVMe.

• 20 discos duros

  • Proveedor: Intel

  • Modelo: SSD-123-foo

  • Tamaño: 4 TB

• 12 discos SSD

  • Proveedor: Micron

  • Modelo: MC-55-44-ZX

  • Tamaño: 512 GB

• 2 NVMe

  • Proveedor: Samsung

  • Modelo: NVME-QQQQ-987

  • Tamaño: 256 GB

Esta configuración se puede definir con dos diseños de la siguiente manera:

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: MC-55-44-XZ

service_type: osd
service_id: example_drvgrp_name2
placement:
  host_pattern: '*'
data_devices:
  model: MC-55-44-XZ
db_devices:
  vendor: samsung
  size: 256GB

Ejemplo 13.4: configuración avanzada con nodos no uniformes #

 

En los ejemplos anteriores se suponía que todos los nodos tienen las mismas unidades. Sin embargo, eso no siempre es así:

Nodos 1-5:

• 20 discos duros

  • Proveedor: Intel

  • Modelo: SSD-123-foo

  • Tamaño: 4 TB

• 2 discos SSD

  • Proveedor: Micron

  • Modelo: MC-55-44-ZX

  • Tamaño: 512 GB

Nodos 6-10:

• 5 NVMe

  • Proveedor: Intel

  • Modelo: SSD-123-foo

  • Tamaño: 4 TB

• 20 discos SSD

  • Proveedor: Micron

  • Modelo: MC-55-44-ZX

  • Tamaño: 512 GB

Puede utilizar la clave "target" en el diseño para asignar nodos específicos a un destino. La notación del destino de Salt ayuda a simplificar las cosas:

service_type: osd
service_id: example_drvgrp_one2five
placement:
  host_pattern: 'node[1-5]'
data_devices:
  rotational: 1
db_devices:
  rotational: 0

seguido de

service_type: osd
service_id: example_drvgrp_rest
placement:
  host_pattern: 'node[6-10]'
data_devices:
  model: MC-55-44-XZ
db_devices:
  model: SSD-123-foo

Ejemplo 13.5: configuración para expertos #

 

En todos los casos anteriores se presuponía que los WAL y DB usaban el mismo dispositivo. Sin embargo, también es posible distribuir el WAL en un dispositivo dedicado:

• 20 discos duros

  • Proveedor: Intel

  • Modelo: SSD-123-foo

  • Tamaño: 4 TB

• 2 discos SSD

  • Proveedor: Micron

  • Modelo: MC-55-44-ZX

  • Tamaño: 512 GB

• 2 NVMe

  • Proveedor: Samsung

  • Modelo: NVME-QQQQ-987

  • Tamaño: 256 GB

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  model: MC-55-44-XZ
db_devices:
  model: SSD-123-foo
wal_devices:
  model: NVME-QQQQ-987

Ejemplo 13.6: configuración compleja (e improbable) #

 

En la siguiente configuración, tratamos de definir lo siguiente:

• 20 discos duros respaldados por 1 NVMe

• 2 discos duros respaldados por 1 SSD (db) y 1 NVMe (wal)

• 8 discos SSD respaldados por 1 NVMe

• 2 discos SSD independientes (cifrados)

• 1 disco duro es de repuesto y no debe distribuirse

El resumen de las unidades usadas es el siguiente:

• 23 discos duros

  • Proveedor: Intel

  • Modelo: SSD-123-foo

  • Tamaño: 4 TB

• 10 discos SSD

  • Proveedor: Micron

  • Modelo: MC-55-44-ZX

  • Tamaño: 512 GB

• 1 NVMe

  • Proveedor: Samsung

  • Modelo: NVME-QQQQ-987

  • Tamaño: 256 GB

La definición de DriveGroups será la siguiente:

service_type: osd
service_id: example_drvgrp_hdd_nvme
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_hdd_ssd_nvme
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: MC-55-44-XZ
wal_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_ssd_nvme
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
db_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_standalone_encrypted
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
encrypted: True

Se conservará un disco duro porque el archivo se está analizando de arriba abajo.