23 Sistema de archivos en clúster #

Si el host del cliente ejecuta SUSE Linux Enterprise 12 SP2 o una versión posterior, el sistema ya 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 7 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.

Importante

Sin el paquete ceph-common (y, por tanto, sin el ayudante mount.ceph), será necesario utilizar las direcciones IP de los monitores en lugar de sus nombres. Esto se debe a que el cliente del kernel no podrá resolver los nombres.

La sintaxis básica de montaje es:

root # mount -t ceph MON1_IP[:PORT],MON2_IP[:PORT],...:CEPHFS_MOUNT_TARGET \
MOUNT_POINT -o name=CEPHX_USER_NAME,secret=SECRET_STRING

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:

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: 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: 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.

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.

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:

cephuser@adm > ceph status
  [...]
  services:
    [...]
    mds: cephfs-1/1/1 up  {0=node2=up:active}, 1 up:standby
    [...]
cephuser@adm > ceph fs set cephfs max_mds 2
cephuser@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: daemons de reserva

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.

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:

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

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.

Cada sistema de archivos CephFS puede configurarse para añadir daemons de reserva-respuesta. Estos daemons de reserva siguen el registro de metadatos del MDS activo para reducir el tiempo de failover en caso de que el MDS activo deje de estar disponible. Cada MDS activo puede tener solo un daemon de reserva-respuesta siguiéndolo.

Para configurar un daemon de reserva-respuesta en un sistema de archivos, ejecute el comando siguiente:

cephuser@adm > ceph fs set FS-NAME allow_standby_replay BOOL

Cuando se definen los monitores, se asignan daemons de reserva-respuesta disponibles para seguir los MDS activos en ese sistema de archivos.

Si un MDS ha entrado en estado de reserva-respuesta, solo se utilizará como daemon de reserva para el rango al que sigue. Si otro rango falla, este daemon de reserva-respuesta no se utilizará como sustituto, aunque no haya ningún otro daemon de reserva disponible. Por este motivo, se recomienda que si se utiliza este sistema, todos los MDS activos deben tener un daemon de reserva-respuesta.

El uso de cuotas con CephFS tiene las siguientes limitaciones:

Puede configurar cuotas de CephFS mediante atributos extendidos virtuales:

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:

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

Para establecer una cuota de 10.000 archivos, ejecute:

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

Para ver la configuración de cuota, ejecute:

cephuser@mds > getfattr -n ceph.quota.max_bytes /SOME/DIRECTORY

cephuser@mds > getfattr -n ceph.quota.max_files /SOME/DIRECTORY

Nota: cuota no configurada

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

Para eliminar una cuota, ejecute:

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

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:

cephuser@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.

Nota

Este es un subdirectorio virtual. No aparece en la lista de directorios del directorio padre, pero el nombre .snap no se puede utilizar como nombre de archivo ni directorio. Para acceder al directorio .snap es necesario acceder a él explícitamente, por ejemplo:

tux > ls -la /CEPHFS_MOUNT/.snap/

Importante: limitación de los clientes del kernel

Los clientes del kernel de CephFS tienen una limitación: no pueden gestionar más de 400 instantáneas en un sistema de archivos. 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: 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

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

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