Saltar a contenidoSaltar a navegación de páginas: página anterior [tecla acceso p]/página siguiente [tecla acceso n]
ContenidoContenido
Guía de administración
  1. Acerca de esta guía
  2. I Gestión en clúster
    1. 1 Privilegios de usuario y comandos de símbolos del sistema
    2. 2 Administración de un clúster de Salt
    3. 3 Copia de seguridad de la configuración y los datos del clúster
  3. II Funcionamiento de un clúster
    1. 4 Introducción
    2. 5 Gestión de los servicios de Ceph
    3. 6 Determinación del estado del clúster
    4. 7 Supervisión y alertas
    5. 8 Autenticación con cephx
    6. 9 Gestión de datos almacenados
    7. 10 Módulos de Ceph Manager
    8. 11 Gestión de repositorios de almacenamiento
    9. 12 Dispositivo de bloques RADOS
    10. 13 Repositorios codificados de borrado
    11. 14 Niveles de caché
    12. 15 Mejora del rendimiento con el caché de LVM
    13. 16 Configuración del clúster de Ceph
  4. III Acceso a los datos del clúster
    1. 17 Ceph Object Gateway
    2. 18 Ceph iSCSI Gateway
    3. 19 Sistema de archivos con agrupación en clúster
    4. 20 Exportación de datos de Ceph a través de Samba
    5. 21 NFS Ganesha: exportación de datos de Ceph a través de NFS
  5. IV Gestión del clúster con herramientas de interfaz gráfica de usuario
    1. 22 Ceph Dashboard
  6. V Integración con herramientas de virtualización
    1. 23 Uso de libvirt con Ceph
    2. 24 Ceph como procesador final para la instancia de QEMU KVM
  7. VI Preguntas frecuentes, consejos y solución de problemas
    1. 25 Consejos y sugerencias
    2. 26 Preguntas más frecuentes
    3. 27 Solución de problemas
  8. A Ejemplo personalizado de la fase 1 de DeepSea
  9. B Alertas por defecto para SUSE Enterprise Storage 6
  10. C Actualizaciones de mantenimiento de Ceph basadas en versiones secundarias superiores de Nautilus
  11. Glosario
  12. D Actualizaciones de la documentación
Navegación
Se aplica a SUSE Enterprise Storage 6

19 Sistema de archivos con agrupación en clúster Edit source

En este capítulo se describen las tareas de administración que normalmente se llevan a cabo después de configurar el clúster y exportar CephFS. Si necesita más información sobre cómo configurar CephFS, consulte Capítulo 11, Instalación de CephFS.

19.1 Montaje de CephFS Edit source

Cuando se crea el sistema de archivos y el servidor de metadatos está activo, estará preparado para montar el sistema de archivos desde un host de cliente.

19.1.1 Preparación del cliente Edit source

Si el host de cliente ejecuta SUSE Linux Enterprise 12 SP2 o SP3, puede omitir esta sección, ya que el sistema está preparado para montar CephFS sin preparativos adicionales.

Si el host de cliente ejecuta SUSE Linux Enterprise 12 SP1, debe aplicar todos los parches más recientes antes de montar CephFS.

En cualquier caso, todo lo necesario para montar CephFS se incluye en SUSE Linux Enterprise. El producto SUSE Enterprise Storage 6 no es necesario.

Para admitir la sintaxis completa de mount, el paquete ceph-common (que se incluye con SUSE Linux Enterprise) debe estar instalado antes de intentar montar CephFS.

19.1.2 Creación de un archivo de secreto Edit source

El clúster de Ceph se ejecuta con la autenticación activada por defecto. Debe crear un archivo donde se almacene la clave de secreto (no el anillo de claves en sí). Para obtener la clave de secreto para un usuario concreto y, a continuación, crear el archivo, haga lo siguiente:

Procedimiento 19.1: Creación de una clave de secreto
  1. Muestre la clave para el usuario concreto en un archivo de anillo de claves:

    cephadm@adm > cat /etc/ceph/ceph.client.admin.keyring
  2. Copie la clave del usuario que va a utilizar el sistema de archivos CephFS montado. Normalmente, la clave tiene un aspecto similar al siguiente:

    AQCj2YpRiAe6CxAA7/ETt7Hcl9IyxyYciVs47w==
  3. Cree un archivo con el nombre de usuario como parte del nombre de archivo; por ejemplo, /etc/ceph/admin.secret para el usuario admin.

  4. Pegue el valor de la clave en el archivo creado en el paso anterior.

  5. Defina los derechos de acceso adecuados en el archivo. El usuario debe ser el único que pueda leer el archivo: los demás usuarios no deben tener ningún derecho de acceso.

19.1.3 Montaje de CephFS Edit source

Puede montar CephFS con el comando mount. Es preciso especificar el nombre de host o la dirección IP del monitor. Dado que la autenticación cephx está habilitada por defecto en SUSE Enterprise Storage, debe especificar también un nombre de usuario y su secreto relacionado:

root # mount -t ceph ceph_mon1:6789:/ /mnt/cephfs \
 -o name=admin,secret=AQATSKdNGBnwLhAAnNDKnH65FmVKpXZJVasUeQ==

Como el comando anterior permanece en el historial de shell, un enfoque más seguro es leer el secreto desde un archivo:

root # mount -t ceph ceph_mon1:6789:/ /mnt/cephfs \
 -o name=admin,secretfile=/etc/ceph/admin.secret

Tenga en cuenta que el archivo de secreto solo debe contener el secreto del anillo de claves actual. En nuestro ejemplo, el archivo solo contendrá la línea siguiente:

AQATSKdNGBnwLhAAnNDKnH65FmVKpXZJVasUeQ==
Sugerencia
Sugerencia: especificación de varios monitores

Resulta recomendable especificar varios monitores separados por comas en la línea del comando mount por si un monitor se desactiva en algún momento del montaje. Las direcciones de los monitores tiene el formato host[:puerto]. Si no se especifica el puerto, se utiliza por defecto el 6789.

Cree el punto de montaje en el host local:

root # mkdir /mnt/cephfs

Monte CephFS:

root # mount -t ceph ceph_mon1:6789:/ /mnt/cephfs \
 -o name=admin,secretfile=/etc/ceph/admin.secret

Es posible especificar un subdirectorio subdir si se va a montar un subconjunto del sistema de archivos:

root # mount -t ceph ceph_mon1:6789:/subdir /mnt/cephfs \
 -o name=admin,secretfile=/etc/ceph/admin.secret

Puede especificar más de un host de monitor en el comando mount:

root # mount -t ceph ceph_mon1,ceph_mon2,ceph_mon3:6789:/ /mnt/cephfs \
 -o name=admin,secretfile=/etc/ceph/admin.secret
Importante
Importante: acceso de lectura al directorio raíz

Si se usan clientes con restricciones de vía, es preciso incluir acceso de lectura al directorio raíz en los permisos del servidor de metadatos. Por ejemplo, un anillo de claves puede tener este aspecto:

client.bar
 key: supersecretkey
 caps: [mds] allow rw path=/barjail, allow r path=/
 caps: [mon] allow r
 caps: [osd] allow rwx

La parte allow r path=/ significa que los clientes que tienen vías restringidas podrán ver el volumen raíz, pero no escribir en él. Esto puede ser un problema para los casos en los que se requiera aislamiento completo.

19.2 Desmontaje de CephFS Edit source

Para desmontar CephFS, utilice el comando umount:

root # umount /mnt/cephfs

19.3 CephFS en /etc/fstab Edit source

Para montar CephFS automáticamente durante el inicio del cliente, inserte la línea correspondiente en la tabla de su sistema de archivos /etc/fstab:

mon1:6790,mon2:/subdir /mnt/cephfs ceph name=admin,secretfile=/etc/ceph/secret.key,noatime,_netdev 0 2

19.4 Varios daemons de servidor de metadatos activos (servidor de metadatos activo-activo) Edit source

CephFS está configurado por defecto para un solo daemon de servidor de metadatos activo. Para ampliar el rendimiento de los metadatos en sistemas a gran escala, puede habilitar varios daemons de servidor de metadatos activos: compartirán la carga de trabajo de los metadatos entre sí.

19.4.1 Cuándo debe utilizarse un servidor de metadatos activo-activo Edit source

Puede ser útil usar varios daemons de servidor de metadatos activos si el rendimiento de los metadatos sufre un cuello de botella en el servidor de metadatos único por defecto.

Añadir más daemons no mejora el rendimiento de todos los tipos de cargas de trabajo. Por ejemplo, una única aplicación que se ejecute en un único cliente no se beneficiará de un número mayor de daemons de servidor de metadatos; a menos que la aplicación lleve a cabo muchas operaciones de metadatos en paralelo.

Las cargas de trabajo que suelen beneficiarse de que haya un número mayor de daemons de servidor de metadatos activos son las que tienen muchos clientes, quizás funcionando en muchos directorios diferentes.

19.4.2 Aumento del tamaño del clúster activo del servidor de metadatos Edit source

Cada sistema de archivos CephFS tiene un valor max_mds que controla el número de rangos que se van a crear. El número real de rangos en el sistema de archivos solo aumentará si hay un daemon de repuesto disponible para hacerse cargo del nuevo rango. Por ejemplo, si hay solo un daemon de servidor de metadatos en ejecución y en max_mds se define el valor 2, no se creará un segundo rango.

En el ejemplo siguiente, la opción max_mds se define con el valor 2 para crear un nuevo rango aparte del rango por defecto. Para ver los cambios, ejecute ceph status antes y, después de definir max_mds, observe la línea que contiene fsmap:

cephadm@adm > ceph status
  [...]
  services:
    [...]
    mds: cephfs-1/1/1 up  {0=node2=up:active}, 1 up:standby
    [...]
cephadm@adm > ceph mds set max_mds 2
cephadm@adm > ceph status
  [...]
  services:
    [...]
    mds: cephfs-2/2/2 up  {0=node2=up:active,1=node1=up:active}
    [...]

El rango recién creado (1) pasa por el estado de "creación" y entra en su estado "activo".

Importante
Importante: daemons en espera

Incluso con varios daemons de servidor de metadatos activos, un sistema de alta disponibilidad sigue necesitando daemons en espera para que entren en acción si falla alguno de los servidores en los que se ejecuta un daemon activo.

En consecuencia, el número máximo práctico de max_mds para sistemas de alta disponibilidad es uno menos que el número total de servidores de metadatos del sistema. Para seguir estando disponible en caso de que varios servidores fallen, aumente el número de daemons en espera del sistema para que sea igual al número de servidores que se pueda admitir que fallen.

19.4.3 Reducción del número de rangos Edit source

Todos los rangos, incluidos los que se van a eliminar, deben estar activos en primer lugar. Esto significa que debe tener al menos el número de max_mds de daemons de servidor de metadatos disponibles.

En primer lugar, defina en max_mds un número inferior. Por ejemplo, vuelva a tener un único servidor de metadatos activo:

cephadm@adm > ceph status
  [...]
  services:
    [...]
    mds: cephfs-2/2/2 up  {0=node2=up:active,1=node1=up:active}
    [...]
cephadm@adm > ceph mds set max_mds 1
cephadm@adm > ceph status
  [...]
  services:
    [...]
    mds: cephfs-1/1/1 up  {0=node2=up:active}, 1 up:standby
    [...]

Fíjese en que sigue teniendo dos servidores de metadatos activos. Los rangos aún existen, aunque hemos reducido el número de max_mds, ya que max_mds solo restringe la creación de nuevos rangos.

A continuación, use el comando ceph mds deactivate rango para eliminar el rango que no se necesita:

cephadm@adm > ceph status
  [...]
  services:
    [...]
    mds: cephfs-2/2/1 up  {0=node2=up:active,1=node1=up:active}
cephadm@adm > ceph mds deactivate 1
telling mds.1:1 192.168.58.101:6805/2799214375 to deactivate

cephadm@adm > ceph status
  [...]
  services:
    [...]
    mds: cephfs-2/2/1 up  {0=node2=up:active,1=node1=up:stopping}

cephadm@adm > ceph status
  [...]
  services:
    [...]
    mds: cephfs-1/1/1 up  {0=node2=up:active}, 1 up:standby

El rango desactivado entrará primero en estado de detención durante el tiempo que tarda en entregar sus metadatos a los restantes daemons activos. Esta fase puede tardar entre unos segundos y varios minutos. Si parece que el servidor de metadatos se ha bloqueado en el estado de detención, investigue si existe algún error.

Si un daemon de servidor de metadatos se bloquea o se interrumpe mientras se encuentra en estado de "detención", un daemon en espera ocupará su lugar y el rango volverá al estado "activo". Puede probar a desactivarlo de nuevo cuando se haya recuperado.

Cuando el daemon termina la fase de detención, se inicia y vuelve a un estado de espera.

19.4.4 Fijación manual de árboles de directorio a un rango Edit source

En las configuraciones con varios servidores de metadatos activos, se ejecuta un mecanismo de equilibrio que funciona para distribuir la carga de los metadatos de forma uniforme en el clúster. Esto suele ser suficientemente para la mayoría de los usuarios pero, en ocasiones, es aconsejable sustituir el mecanismo de equilibrio dinámico por asignaciones explícitas de metadatos para rangos concreto. De esta forma, se permite que el administrador o los usuarios puedan distribuir uniformemente la carga de la aplicación o limitar el impacto de las peticiones de metadatos de los usuarios en todo el clúster.

El mecanismo proporcionado para este propósito se denomina "fijación de exportación". Se trata de un atributo extendido de los directorios. El nombre de este atributo extendido es ceph.dir.pin. Los usuarios pueden definir este atributo mediante comandos estándar:

root # setfattr -n ceph.dir.pin -v 2 /path/to/dir

El valor (- v) del atributo extendido es el rango al que se debe asignar el subárbol de directorio. Un valor por defecto de -1 indica que el directorio no está fijado.

La fijación de exportación de directorio se hereda de su padre más próximo que cuente con una fijación de exportación definido. Por lo tanto, definir la fijación de exportación en un directorio, afecta a todos sus hijos. Sin embargo, la fijación padre se puede sustituir definiendo fijaciones de exportación en el directorio hijo. Por ejemplo:

root # mkdir -p a/b                      # "a" and "a/b" start with no export pin set.
setfattr -n ceph.dir.pin -v 1 a/  # "a" and "b" are now pinned to rank 1.
setfattr -n ceph.dir.pin -v 0 a/b # "a/b" is now pinned to rank 0
                                  # and "a/" and the rest of its children
                                  # are still pinned to rank 1.

19.5 Gestión del failover Edit source

Si un daemon de servidor de metadatos deja de comunicarse con el monitor, este espera el número de segundos definido en mds_beacon_grace (por defecto, 15 segundos) antes de marcar el daemon como retrasado. Es posible configurar uno o varios daemons en espera que se harán cargo del trabajo durante un failover del daemon de servidor de metadatos.

19.5.1 Configuración de daemons en espera Edit source

Existen varios valores de configuración que controlan el comportamiento de un daemon en espera. Puede especificarlos en el archivo ceph.conf del host donde se ejecuta el daemon de servidor de metadatos. El daemon carga estos valores cuando se inicia y los envía al monitor.

Por defecto, si no se usa ninguno de estos valores, todos los daemons de servidor de metadatos que no tengan un rango se utilizarán como daemons en espera para cualquier rango.

Los valores que asocian un daemon en espera con un nombre o rango en concreto no garantizan que el daemon solo se use para ese rango. Esto significa que si hay varios daemons en espera disponibles, se utilizará el daemon en espera asociado. Si un rango falla y hay un daemon en espera disponible, se utilizará aunque esté asociado a un rango o un nombre distinto.

mds_standby_replay

Si se define como verdadero, el daemon en espera leerá de forma continua el diario de metadatos de un rango superior. De esta forma, su caché de metadatos estará listo y se acelera el proceso de recuperación tras fallo si el daemon que presta servicios al rango falla.

Un rango superior solo puede tener un daemon de respuesta en espera asignado. Si se definen dos daemons para que sean daemons de respuesta en espera, uno de ellos se asignará de forma arbitraria y el otro se convertirá en un daemon no de respuesta en espera normal.

Si un daemon ha entrado en estado de respuesta en espera, solo se utilizará como daemon en espera para el rango al que sigue. Si otro rango falla, este daemon de respuesta en espera no se utilizará como sustituto, aunque no haya ningún otro daemon en espera disponible.

mds_standby_for_name

Defina esta opción para que el daemon en espera solo asuma el puesto de un rango que ha fallado si el último daemon que lo aloja coincide con este nombre.

mds_standby_for_rank

Defina esta opción para que el daemon en espera solo asuma el puesto del rango especificado. Si falla otro rango, este daemon no se utilizará para sustituirlo.

Úselo junto con mds_standby_for_fscid para especificar claramente a qué rango del sistema de archivos se debe dirigir en caso de que haya varios sistemas de archivos.

mds_standby_for_fscid

Si mds_standby_for_rank está definido, se trata simplemente de un calificador para indicar a qué rango del sistema de archivos se hace referencia.

Si mds_standby_for_rank no está definido, el valor FSCID provocará que este daemon se dirija a cualquier rango del FSCID especificado. Utilice esta opción si tiene un daemon que desea utilizar para cualquier rango, pero solo en un sistema de archivos concreto.

mon_force_standby_active

Este valor se utiliza en los hosts de monitor. Por defecto, su valor es true (verdadero).

Si es false (falso), los daemons configurados con standby_replay=true solo se convertirán en activos si falla el rango o el nombre que tienen configurado para seguir. Por otro lado, si el valor es true (verdadero), un daemon configurado con standby_replay=true se puede asignar a otro rango.

19.5.2 Ejemplos Edit source

A continuación se muestran varios ejemplos de configuraciones de ceph.conf. Puede copiar un ceph.conf con la configuración de todos los daemons en todos los servidores, o bien puede tener un archivo diferente en cada servidor que contenga la configuración del daemon de dicho servidor.

19.5.2.1 Par simple Edit source

Hay dos daemons de servidor de metadatos "a" y "b" que actúan como un par. Si alguno de ellos no se ha asignado a un rango, será el seguidor de respuesta en espera del otro.

[mds.a]
mds standby replay = true
mds standby for rank = 0

[mds.b]
mds standby replay = true
mds standby for rank = 0

19.6 Configuración de cuotas de CephFS Edit source

Puede establecer cuotas en cualquier subdirectorio del sistema de archivos de Ceph. La cuota restringe el número de bytes o de archivos almacenados debajo del punto especificado en la jerarquía de directorios.

19.6.1 Limitaciones Edit source

El uso de cuotas con CephFS tiene las siguientes limitaciones:

Las cuotas son cooperativas y no compiten.

Las cuotas de Ceph dependen de que el cliente que está montando el sistema de archivos deje de escribir en él cuando se alcance un límite. La parte del servidor no puede impedir que un cliente malintencionado escriba tantos datos como necesite. No utilice cuotas para evitar que se rellene el sistema de archivos en entornos en los que los clientes no sean de total confianza.

Las cuotas son imprecisas.

Los procesos que se escriben en el sistema de archivos se detienen poco después de que se alcance el límite de cuota. Inevitablemente se les permitirá escribir cierta cantidad de datos por encima del límite configurado. Los escritores del cliente se detendrán décimas de segundos después de superar el límite configurado.

Las cuotas se implementan en el cliente del kernel a partir de la versión 4.17.

Las cuotas son compatibles con el cliente de espacio de usuario (libcephfs, ceph-fuse). Los clientes del kernel de Linux de la versión 4.17 y superiores admiten cuotas de CephFS en clústeres de SUSE Enterprise Storage 6. Los clientes del kernel (incluso de las versiones recientes) no podrán controlar las cuotas en clústeres más antiguos, incluso si son capaces de establecer los atributos extendidos de las cuotas.

Configure las cuotas cuidadosamente cuando se utilicen con restricciones de montaje basadas en vías.

El cliente necesita tener acceso al inodo del directorio en el cual se configuran las cuotas para aplicarlas. Si el cliente tiene acceso restringido a una vía específica (por ejemplo /home/user) según la capacidad del MDS y se configura una cuota en un directorio antecesor al que no tienen acceso (/home), el cliente no la aplicará. Cuando se usan restricciones de acceso basadas en vías, asegúrese de configurar la cuota en el directorio al que el cliente tenga acceso (/home/user) o en el que haya algo anidado.

19.6.2 Configuración Edit source

Puede configurar cuotas de CephFS mediante atributos extendidos virtuales:

ceph.quota.max_files

Configura un límite de archivos.

ceph.quota.max_bytes

Configura un límite debytes.

Si los atributos aparecen en un inodo de directorio, allí se configura una cuota. Si no están presentes, no se establece ninguna cuota en ese directorio (aunque se podría configurar una en un directorio padre).

Para establecer una cuota de 100 MB, ejecute:

cephadm@mds > setfattr -n ceph.quota.max_bytes -v 100000000 /SOME/DIRECTORY

Para establecer una cuota de 10.000 archivos, ejecute:

cephadm@mds > setfattr -n ceph.quota.max_files -v 10000 /SOME/DIRECTORY

Para ver la configuración de cuota, ejecute:

cephadm@mds > getfattr -n ceph.quota.max_bytes /SOME/DIRECTORY
cephadm@mds > getfattr -n ceph.quota.max_files /SOME/DIRECTORY
Nota
Nota: cuota no establecida

Si el valor del atributo extendido es "0", no se establece la cuota.

Para eliminar una cuota, ejecute:

cephadm@mds > setfattr -n ceph.quota.max_bytes -v 0 /SOME/DIRECTORY
cephadm@mds > setfattr -n ceph.quota.max_files -v 0 /SOME/DIRECTORY

19.7 Gestión de instantáneas de CephFS Edit source

Las instantáneas de CephFS crean una vista de solo lectura del sistema de archivos del momento en que se toman. Puede crear una instantánea en cualquier directorio. La instantánea cubrirá todos los datos del sistema de archivos del directorio especificado. Después de crear una instantánea, los datos almacenados en búfer se vacían de forma asincrónica desde varios clientes. Como resultado, crear una instantánea es muy rápido.

Importante
Importante: múltiples sistemas de archivos

Si tiene varios sistemas de archivos CephFS que comparten un único repositorio (mediante espacios de nombres), sus instantáneas tendrán un conflicto y si se suprime una instantánea, faltarán datos de archivo en otras instantáneas que compartan el mismo repositorio.

19.7.1 Creación de instantáneas Edit source

La función de instantáneas de CephFS está habilitada por defecto en los nuevos sistemas de archivos. Para habilitarla en sistemas de archivos existentes, ejecute:

cephadm@adm > ceph fs set CEPHFS_NAME allow_new_snaps true

Después de habilitar las instantáneas, todos los directorios de CephFS tendrán un subdirectorio .snap especial.

Los clientes del kernel de CephFS tienen una limitación: no pueden gestionar más de 400 instantáneas en un árbol de directorios. El número de instantáneas siempre debe mantenerse por debajo de este límite, independientemente del cliente que se esté utilizando. Si se utilizan clientes de CephFS más antiguos, como SLE12-SP3, tenga en cuenta que tener más 400 instantáneas es perjudicial para las operaciones, ya que el cliente se detendrá por fallo.

Sugerencia
Sugerencia: nombre del subdirectorio de instantáneas personalizado

Puede configurar un nombre diferente para el subdirectorio de instantáneas definiendo el valor client snapdir.

Para crear una instantánea, cree un subdirectorio en el directorio .snap con un nombre personalizado. Por ejemplo, para crear una instantánea del directorio /CEPHFS_MOUNT/2/3/, ejecute:

tux > mkdir /CEPHFS_MOUNT/2/3/.snap/CUSTOM_SNAPSHOT_NAME

19.7.2 Supresión de instantáneas Edit source

Para suprimir una instantánea, elimine su subdirectorio dentro del directorio .snap:

tux > rmdir /CEPHFS_MOUNT/2/3/.snap/CUSTOM_SNAPSHOT_NAME
Imprimir esta página