23 Sistema de archivos en clúster #
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 Sección 5.4.3.3, “Distribución de servidores de metadatos”.
23.1 Montaje de CephFS #
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.
23.1.1 Preparación del cliente #
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.
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
23.1.2 Creación de un archivo secreto #
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:
Muestre la clave para el usuario concreto en un archivo de anillo de claves:
cephuser@adm >
cat /etc/ceph/ceph.client.admin.keyringCopie 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==
Cree un archivo con el nombre de usuario como parte del nombre de archivo; por ejemplo,
/etc/ceph/admin.secret
para el usuario admin.Pegue el valor de la clave en el archivo creado en el paso anterior.
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.
23.1.3 Montaje de CephFS #
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==
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
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.
23.2 Desmontaje de CephFS #
Para desmontar CephFS, utilice el comando umount
:
root #
umount /mnt/cephfs
23.3 Montaje de CephFS en /etc/fstab
#
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
23.4 Varios daemons de servidor de metadatos activos (MDS activo-activo) #
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í.
23.4.1 Uso de servidor de metadatos activo-activo #
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.
23.4.2 Aumento del tamaño del clúster activo del servidor de metadatos #
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 2cephuser@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".
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.
23.4.3 Reducción del número de rangos #
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 1cephuser@adm >
ceph
status [...] services: [...] mds: cephfs-1/1/1 up {0=node2=up:active}, 1 up:standby [...]
23.4.4 Fijación manual de árboles de directorio a un rango #
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.
23.5 Gestión del failover #
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.
23.5.1 Configuración reserva-respuesta #
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.
23.6 Configuración de cuotas de CephFS #
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.
23.6.1 Limitaciones de cuotas de CephFS #
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 7. 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. Los kernel SLE12-SP3 (y versiones posteriores) ya incluyen las adaptaciones necesarias para gestionar 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á. Si utiliza restricciones de acceso basadas en vías, asegúrese de configurar la cuota en el directorio al que puede acceder el cliente (por ejemplo,/home/user
o/home/user/quota_dir
).
23.6.2 Configuración de cuotas de CephFS #
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:
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
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/DIRECTORYcephuser@mds >
setfattr -n ceph.quota.max_files -v 0 /SOME/DIRECTORY
23.7 Gestión de instantáneas de CephFS #
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.
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.
23.7.1 Creación de instantáneas #
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.
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/
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.
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
23.7.2 Supresión de instantáneas #
Para suprimir una instantánea, elimine su subdirectorio dentro del directorio .snap
:
tux >
rmdir /CEPHFS_MOUNT/2/3/.snap/CUSTOM_SNAPSHOT_NAME