El sistema de archivos de Ceph (CephFS) es un sistema de archivos conforme con POSIX que utiliza un clúster de almacenamiento de Ceph para almacenar sus datos. CephFS utiliza el mismo sistema de clúster para los dispositivos de bloques de Ceph, el almacenamiento de objetos de Ceph con sus API S3 y Swift o los enlaces nativos (librados
).
Para utilizar CephFS, debe disponer de un clúster de almacenamiento de Ceph en ejecución y al menos un servidor de metadatos de Ceph en ejecución.
Con SUSE Enterprise Storage 6, SUSE incluye compatibilidad oficial con muchos escenarios en los que se utiliza el componente de ampliación horizontal y distribuido CephFS. En esta entrada se describen los límites rígidos y se ofrecen directrices para los casos de uso sugeridos.
Una distribución de CephFS compatible debe cumplir estos requisitos:
Un mínimo de un servidor de metadatos. SUSE recomienda distribuir varios nodos con la función de servidor de metadatos. Solo uno estará activo
, mientras el resto estarán pasivos
. No olvide mencionar todos los nodos MON en el comando mount
cuando monte CephFS desde un cliente.
Los clientes deben ser SUSE Linux Enterprise Server 12 SP3 o posterior, o SUSE Linux Enterprise Server 15 o posterior, con el controlador del módulo del kernel cephfs
. No se admite el módulo FUSE.
En SUSE Enterprise Storage 6 se admiten las cuotas de CephFS y se pueden establecer en cualquier subdirectorio del sistema de archivos de Ceph. La cuota restringe el número de bytes
o los archivos
almacenados debajo del punto especificado en la jerarquía de directorios. Para obtener más información, consulte el Sección 19.6, “Configuración de cuotas de CephFS”.
CephFS admite cambios de diseño de archivos, como se describe en Sección 11.3.4, “Diseños de archivos”. Sin embargo, aunque el sistema de archivos se puede montar mediante cualquier cliente, no es posible añadir nuevos repositorios de datos a un sistema de archivos CephFS existente (ceph mds add_data_pool
). Solo se pueden añadir mientras el sistema de archivos está desmontado.
Un mínimo de un servidor de metadatos. SUSE recomienda distribuir varios nodos con la función de servidor de metadatos. Por defecto, se inician daemons adicionales del MDS como daemons en espera
, que actúan como copias de seguridad para el MDS activo. También se admiten varios daemons activos del MDS (consulte la Sección 11.3.2, “Tamaño del clúster del servidor de metadatos”).
El servidor de metadatos de Ceph (MDS) almacena los metadatos para CephFS. Los dispositivos de bloques de Ceph y el almacenamiento de objetos de Ceph no utilizan un servidor de metadatos. Gracias a los servidores de metadatos, los usuarios del sistema de archivos POSIX pueden ejecutar comandos básicos, como ls
o find
, sin que ello suponga una carga de trabajo enorme al clúster de almacenamiento de Ceph.
Es posible distribuir el servidor de metadatos durante el proceso de distribución inicial del clúster, tal como se describe en la Sección 5.3, “Distribución del clúster”, o añadirlos a un clúster ya distribuido como se describe en el Sección 2.1, “Adición de nuevos nodos de clúster”.
Después de distribuir el servidor de metadatos, permita el servicio Ceph OSD/MDS
en la configuración del cortafuegos del servidor donde se vaya a distribuir dicho servidor: inicie yast
, acceda a › › y, en el menú desplegable seleccione . Si no se permite el tráfico completo del nodo del servidor de metadatos de Ceph, el montaje de un sistema de archivos falla, aunque otras operaciones pueden funcionar correctamente.
Puede ajustar con más detalle el comportamiento del servidor de metadatos insertando las opciones relevantes en el archivo de configuración ceph.conf
.
Si se define el valor "true" (opción por defecto), los monitores imponen que la respuesta en espera esté activa. Defínalo en las secciones [mon]
o [global]
.
mds cache memory limit
La cantidad máxima de memoria (en bytes) que el servidor de metadatos aplicará para su caché. Los administradores deben utilizar este valor en lugar del antiguo ajuste mds cache size
. Por defecto es 1 GB.
mds cache reservation
La reserva de caché (memoria o inodos) que debe conservar el caché del servidor de metadatos. Cuando el servidor de metadatos empieza a utilizar su reserva, retendrá temporalmente el estado del cliente hasta que el tamaño de caché se reduzca para restaurar la reserva. El valor por defecto es 0,05.
El número de inodos que se van a almacenar en caché. El valor 0 (opción por defecto) indica un número ilimitado. Se recomienda utilizar mds cache memory limit
para limitar la cantidad de memoria que utiliza la memoria caché del MDS.
El punto de inserción de los nuevos elementos en la LRU de caché (desde la parte superior). El valor por defecto es 0.7.
La fracción del directorio que está sucia antes de que Ceph se confirme mediante una actualización completa en lugar de con una actualización parcial. El valor por defecto es 0,5.
El tamaño máximo de una actualización de directorio antes de que Ceph la divida en transacciones más pequeñas. El valor por defecto es 90 MB.
La vida media de la temperatura de caché del MDS. El valor por defecto es 5.
La frecuencia en segundos de los mensajes de baliza enviados al monitor. El valor por defecto es 4.
El intervalo sin balizas antes de que Ceph declare que un MDS tiene retrasos y, posiblemente, lo reemplace. El valor por defecto es 15.
La duración de la lista negra de los MDS con errores en el mapa de OSD. Este valor controla cuánto tiempo permanecerán los daemons del MDS con fallos en la lista negra del mapa de OSD. No tiene ningún efecto respecto a cuánto tiempo se incluye algo en la lista negra si el administrador lo ha incluido manualmente. Por ejemplo, el comando ceph osd blacklist add
seguirá utilizando el tiempo por defecto de la lista negra. El valor por defecto es 24*60.
Intervalo en segundos que se debe esperar a que los clientes se vuelvan a conectar durante el reinicio del MDS. El valor por defecto es 45.
Indica con qué frecuencia el MDS realiza tareas periódicas internas. El valor por defecto es 5.
El intervalo mínimo en segundos para tratar de evitar la propagación de estadísticas recursivas hacia arriba en el árbol. El valor por defecto es 1.
La rapidez con la que los cambios de dirstat se propagan. El valor por defecto es 5.
El número de inodos que se van a preasignar por sesión de cliente. El valor por defecto es 1000.
Determina si el MDS debe permitir que los clientes vean los resultados de la petición antes de que se confirmen en el diario. El valor por defecto es "true" (verdadero).
Utiliza el mapa trivial para las actualizaciones de directorios. El valor por defecto es "true" (verdadero).
La función que se va a utilizar para aplicar hash a los archivos en varios fragmentos de directorio. El valor por defecto es 2 (es decir, "rjenkins").
Determina si el MDS debe intentar omitir los eventos de diario dañados durante la respuesta del diario. El valor por defecto es "false".
El número máximo de eventos que puede haber en el diario antes de iniciar el recorte. Defina el valor -1 (opción por defecto) para inhabilitar los límites.
El número máximo de segmentos (objetos) que puede haber en el diario antes de iniciar el recorte. Defina el valor -1 para inhabilitar los límites. El valor por defecto es 30.
El número máximo de segmentos que pueden caducar en paralelo. El valor por defecto es 20.
El número máximo de inodos en un evento de EOpen. El valor por defecto es 100.
Determina la frecuencia con la que se debe realizar una muestra de la temperatura del directorio para las decisiones de fragmentación. El valor por defecto es 3.
La temperatura máxima que se puede alcanzar antes de que Ceph intente replicar metadatos a otros nodos. El valor por defecto es 8000.
La temperatura mínima que se debe alcanzar antes de Ceph deje de replicar metadatos a otros nodos. El valor por defecto es 0.
El tamaño máximo que puede alcanzar el directorio antes de que el MDS divida un fragmento de directorio en bits más pequeños. El valor por defecto es 10000.
La temperatura máxima de lectura del directorio que se puede alcanzar antes de que Ceph divida un fragmento de directorio. El valor por defecto es 25000.
La temperatura máxima de escritura del directorio que se puede alcanzar antes de que Ceph divida un fragmento de directorio. El valor por defecto es 10000.
El número de bits por los que se va a dividir un fragmento de directorio. El valor por defecto es 3.
El tamaño mínimo que puede alcanzar el directorio antes de que Ceph intente combinar fragmentos de directorio adyacentes. El valor por defecto es 50.
La frecuencia en segundos de los intercambios de carga de trabajo entre MDS. El valor por defecto es 10.
El retraso en segundos entre un fragmento que es capaz de dividirse o combinarse, y la ejecución del cambio de fragmentación. El valor por defecto es 5.
La proporción por la que los fragmentos pueden superar el tamaño de división antes de que se ejecute una división de inmediato, omitiendo el intervalo de fragmentos. El valor por defecto es 1.5.
El tamaño máximo que puede alcanzar un fragmento antes de que se rechacen las nuevas entradas con ENOSPC. El valor por defecto es 100000.
La temperatura mínima que se debe alcanzar antes de que Ceph migre un subárbol a su padre. El valor por defecto es 0.
El método para calcular la carga del MDS:
0 = Híbrido.
1 = Tasa de petición y latencia.
2 = Carga de CPU.
El valor por defecto es 0.
La temperatura mínima que puede alcanzar el subárbol antes de que Ceph migre. El valor por defecto es 0.1.
La temperatura mínima que puede alcanzar el subárbol antes de que Ceph busque en un subárbol. El valor por defecto es 0.2.
La fracción mínima del tamaño del subárbol de destino que se debe aceptar. El valor por defecto es 0.8.
La fracción máxima del tamaño del subárbol de destino que se debe aceptar. El valor por defecto es 1.2.
Ceph migrará cualquier subárbol que sea mayor que esta fracción del tamaño del subárbol de destino. El valor por defecto es 0.3.
Ceph ignorará cualquier subárbol que sea menor que esta fracción del tamaño del subárbol de destino. El valor por defecto es 0.001.
El número mínimo de iteraciones que debe tener el equilibrador antes de que Ceph quite un destino del MDS antiguo del mapa de MDS. El valor por defecto es 5.
El número máximo de iteraciones que debe tener el equilibrador antes de que Ceph quite un destino del MDS antiguo del mapa de MDS. El valor por defecto es 10.
El intervalo de sondeo del diario cuando está en modo de respuesta en espera ("hot standby"). El valor por defecto es 1.
El intervalo para sondear la memoria caché durante el apagado del MDS. El valor por defecto es 0.
Ceph fragmentará o combinará aleatoriamente los directorios. El valor por defecto es 0.
Ceph volcará el contenido del caché del MDS en un archivo de cada mapa de MDS. El valor por defecto es "false".
Ceph volcará el contenido del caché del MDS en un archivo después de volver a unirse a la memoria caché durante la recuperación. El valor por defecto es "false".
Un daemon del MDS quedará a la espera de otro daemon del MDS con el nombre especificado en este ajuste.
Un daemon del MDS quedará a la espera de un daemon del MDS de este rango. El valor por defecto es -1.
Determina si un daemon del MDS de Ceph debe sondear y responder al registro de un MDS activo ("hot standby"). El valor por defecto es "false".
Define el número mínimo de capacidades que puede tener un cliente. El valor por defecto es 100.
Defina la proporción máxima de capacidades actuales que se pueden recuperar durante la presión de caché del MDS. El valor por defecto es 0.8.
Indica con qué frecuencia se actualiza el objeto de titular de diario. El valor por defecto es 15.
Indica cuántos períodos de repartición se deben leer por adelantado en la respuesta del diario. El valor por defecto es 10.
Indica cuántos períodos de repartición se deben poner a cero delante de la posición de escritura. El valor por defecto es 10.
La latencia máxima adicional en segundos en la que se incurre artificialmente. El valor por defecto es 0.001.
El número máximo de bytes por el que se debe retrasar el vaciado. El valor por defecto es 0.
Si dispone de un clúster de almacenamiento de Ceph en buen estado con al menos un servidor de metadatos de Ceph, puede crear y montar el sistema de archivos de Ceph. Asegúrese de que su cliente cuenta con conectividad de red y de un anillo de claves de autenticación adecuado.
CephFS requiere al menos dos repositorios RADOS: uno para datos y otro para metadatos. A la hora de configurar estos repositorios, tenga en cuenta lo siguiente:
Use un nivel de réplica mayor para el repositorio de metadatos, ya que cualquier pérdida de datos en este repositorio puede producir que no sea posible acceder al sistema de archivos completo.
Use un almacenamiento de baja latencia, como discos SSD, para el repositorio de metadatos, ya que así mejorará la latencia observada de las operaciones del sistema de archivos en los clientes.
Los repositorios necesarios se crean automáticamente asignando una entrada role-mds
en el archivo policy.cfg
. Puede crear manualmente los repositorios cephfs_data
y cephfs_metadata
para ajustar el rendimiento de forma manual antes de configurar el servidor de metadatos. DeepSea no creará estos repositorios si ya existen.
Para obtener más información sobre cómo gestionar repositorios, consulte el Capítulo 11, Gestión de repositorios de almacenamiento.
Para crear los dos repositorios obligatorios (por ejemplo, "cephfs_data" y "cephfs_metadata") con los valores por defecto para usarlos con CephFS, ejecute los comandos siguientes:
cephadm@adm >
ceph osd pool create cephfs_data pg_numcephadm@adm >
ceph osd pool create cephfs_metadata pg_num
Es posible utilizar repositorios codificados de borrado en lugar de los repositorios replicados. Se recomienda usar los repositorios codificados de borrado solo si se requiere un rendimiento bajo y acceso aleatorio poco frecuente; por ejemplo, para el almacenamiento en frío, las copias de seguridad y el archivado. En los repositorios codificados de borrado, CephFS requiere que BlueStore esté habilitado y el repositorio debe tener la opción allow_ec_overwrite
definida. Esta opción puede definirse ejecutando ceph osd pool set ec_pool allow_ec_overwrites true
.
La codificación de borrado añade una sobrecarga considerable a las operaciones del sistema de archivos, especialmente en pequeñas actualizaciones. Esta sobrecarga es inherente al uso de la codificación de borrado como mecanismo de tolerancia a fallos. Este problema es un inconveniente necesario si se quiere reducir de forma significativa la sobrecarga del espacio de almacenamiento.
Cuando se crean los repositorios, puede habilitar el sistema de archivos con el comando ceph fs new
:
cephadm@adm >
ceph fs new fs_name metadata_pool_name data_pool_name
Por ejemplo:
cephadm@adm >
ceph fs new cephfs cephfs_metadata cephfs_data
Para comprobar que se ha creado el sistema de archivos, puede mostrar todos los sistemas de archivos CephFS disponibles:
cephadm@adm >
ceph
fs ls
name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]
Cuando se haya creado el sistema de archivos, el servidor de metadatos podrá entrar en un estado activo. Por ejemplo, en un único sistema de servidor de metadatos:
cephadm@adm >
ceph
mds stat
e5: 1/1/1 up
Encontrará más información sobre tareas específicas; por ejemplo, el montaje, el desmontaje y la configuración avanzada de CephFS, en el Capítulo 19, Sistema de archivos con agrupación en clúster.
Varios daemons activos de servidor de metadatos pueden dar servicio a una instancia de CephFS. Todos los daemons activos del servidor de metadatos que se asignan a una instancia de CephFS distribuirán el árbol del directorio del sistema de archivos entre sí y, por lo tanto, distribuirán la carga de los clientes simultáneos. Para poder añadir un daemon activo del servidor de metadatos a una instancia de CephFS, se necesita una reserva de repuesto. Es posible iniciar un daemon adicional o utilizar una instancia de reserva existente.
El comando siguiente muestra el número actual de daemons del servidor de metadatos activos y pasivos.
cephadm@adm >
ceph mds stat
El siguiente comando define el número de servidores de metadatos activos a dos en una instancia del sistema de archivos.
cephadm@adm >
ceph fs set fs_name max_mds 2
Con el fin de reducir el tamaño del clúster del servidor de metadatos antes de una actualización, es preciso llevar a cabo dos pasos. Primero, defina max_mds
para que solo quede una instancia:
cephadm@adm >
ceph fs set fs_name max_mds 1
y, después, desactive de forma explícita los demás daemons activos del servidor de metadatos:
cephadm@adm >
ceph mds deactivate fs_name:rank
donde rank es el número de un daemon activo del servidor de metadatos de una instancia del sistema de archivos, entre 0 y max_mds
-1.
Se recomienda que al menos un MDS se deje como daemon en espera.
Durante las actualizaciones de Ceph, los indicadores de función de una instancia del sistema de archivos pueden cambiar (normalmente, al añadir nuevas funciones). Los daemons incompatibles (por ejemplo, de versiones anteriores) no funcionan con un conjunto de funciones incompatible y no se iniciarán. Esto significa que actualizar y reiniciar un daemon pueden provocar que todos los otros daemons que aún no se han actualizado se detengan y no se puedan iniciar. Por este motivo, se recomienda reducir el clúster activo del servidor de metadatos a una sola instancia y detener todos los daemons en espera antes de actualizar Ceph. Los pasos manuales para este procedimiento de actualización son los siguientes:
Actualice los paquetes relacionados con Ceph mediante zypper
.
Reduzca el tamaño del clúster activo del servidor de metadatos como se describe anteriormente a una sola instancia y detenga todos los daemons en espera del servidor de metadatos con sus unidades systemd
en todos los otros nodos:
cephadm@mds >
systemctl stop ceph-mds\*.service ceph-mds.target
Solo entonces, reinicie el único daemon del servidor de metadatos de los que quedan, de forma que se reinicie con archivo binario actualizado.
cephadm@mds >
systemctl restart ceph-mds\*.service ceph-mds.target
Reinicie todos los demás daemons del servidor de metadatos y vuelva a definir el valor de max_mds
que desee.
cephadm@mds >
systemctl start ceph-mds.target
Si utiliza DeepSea, se seguirá este procedimiento en caso de que el paquete ceph se haya actualizado durante las fase de la 0 a la 4. Es posible llevar a cabo este procedimiento mientras los clientes tienen la instancia de CephFS montada y hay operaciones de E/S en curso. Sin embargo, tenga en cuenta que habrá una breve pausa de E/S mientras se reinicie el servidor de metadatos activo. Los clientes se recuperarán automáticamente.
Es recomendable reducir la carga de E/S tanto como sea posible antes de actualizar un clúster del servidor de metadatos. Este procedimiento es más rápido en los clústeres del servidor de metadatos inactivos. Por el contrario, en un clúster con mucha carga con varios daemons del servidor de metadatos es fundamental reducir la carga de antemano para evitar que un solo daemon del servidor de metadatos se vea desbordado por operaciones de E/S continuas.
El diseño de un archivo controla cómo se asigna su contenido a los objetos RADOS de Ceph. Puede leer y escribir el diseño de un archivo mediante atributos extendidos virtuales, o xattrs para abreviar.
El nombre del diseño xattrs depende de si se trata de un archivo normal o de un directorio. El diseño xattrs de los archivos normales se denomina ceph.file.layout
, mientras que el diseño xattrs de los directorios se denomina ceph.dir.layout
. En los ejemplos en los que se mencione ceph.file.layout
, sustituya la parte .dir.
según corresponda cuando se trate de directorios.
Se reconocen los siguientes campos de atributo:
El ID o nombre de un repositorio RADOS en el que se almacenarán los objetos de datos de un archivo.
El espacio de nombres RADOS dentro de un repositorio de datos en el que se escribirán los objetos. Está vacío por defecto, lo que significa que se usa el espacio de nombres por defecto.
El tamaño en bytes de un bloque de datos utilizado en la distribución RAID 0 de un archivo. Todas las unidades de partición de un archivo tienen el mismo tamaño. La última unidad de partición suele estar incompleta: representa los datos situados al final del archivo, así como el "espacio" no utilizado situado detrás hasta ocupar todo el espacio de la unidad de partición fija.
El número de unidades de partición consecutivas que constituyen una "partición" RAID 0 de datos de archivo.
El tamaño en bytes de los objetos RADOS en los que se fragmentan los datos del archivo.
RADOS aplica un límite configurable en los tamaños de los objetos. Si utiliza tamaños de objetos de CephFS superiores a ese límite, es posible que las escrituras no se realicen correctamente. El valor del OSD es osd_max_object_size
, que es de 128 MB por defecto. Los objetos RADOS muy grandes pueden impedir que el clúster funciona de forma fluida, por lo que no se recomienda aumentar el límite de tamaño del objeto más allá del valor por defecto.
getfattr
#
Utilice el comando getfattr
para leer la información de diseño de un archivo de archivo de ejemplo file
como una sola cadena:
root #
touch fileroot #
getfattr -n ceph.file.layout file # file: file ceph.file.layout="stripe_unit=4194304 stripe_count=1 object_size=419430
Lea los campos de diseño individuales:
root #
getfattr -n ceph.file.layout.pool file # file: file ceph.file.layout.pool="cephfs_data"root #
getfattr -n ceph.file.layout.stripe_unit file # file: file ceph.file.layout.stripe_unit="4194304"
Al leer los diseños, el repositorio normalmente se indicará por su nombre. Sin embargo, en raras ocasiones, cuando se acaban de crear los repositorios, podría generarse el ID.
Los directorios no tienen un diseño explícito hasta que se personalizan. Los intentos de leer el diseño fallarán si nunca se ha modificado: eso indica que se usará el diseño del siguiente directorio antecesor con un diseño explícito.
root #
mkdir dirroot #
getfattr -n ceph.dir.layout dir dir: ceph.dir.layout: No such attributeroot #
setfattr -n ceph.dir.layout.stripe_count -v 2 dirroot #
getfattr -n ceph.dir.layout dir # file: dir ceph.dir.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 pool=cephfs_data"
setfattr
#
Utilice el comando setfattr
para modificar los campos de diseño de un archivo de archivo de ejemplo file
:
cephadm@adm >
ceph osd lspools 0 rbd 1 cephfs_data 2 cephfs_metadataroot #
setfattr -n ceph.file.layout.stripe_unit -v 1048576 fileroot #
setfattr -n ceph.file.layout.stripe_count -v 8 file # Setting pool by ID:root #
setfattr -n ceph.file.layout.pool -v 1 file # Setting pool by name:root #
setfattr -n ceph.file.layout.pool -v cephfs_data file
Si los campos de diseño de un archivo se modifican mediante setfattr
, este archivo debe estar vacío, o se producirá un error.
Si desea quitar un diseño explícito de un directorio de ejemplo mydir
y volver a heredar el diseño de su antecesor, ejecute lo siguiente:
root #
setfattr -x ceph.dir.layout mydir
Del mismo modo, si ha definido el atributo "pool_namespace" y desea modificar el diseño para que se use el espacio de nombres por defecto, ejecute:
# Create a directory and set a namespace on itroot #
mkdir mydirroot #
setfattr -n ceph.dir.layout.pool_namespace -v foons mydirroot #
getfattr -n ceph.dir.layout mydir ceph.dir.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 \ pool=cephfs_data_a pool_namespace=foons" # Clear the namespace from the directory's layoutroot #
setfattr -x ceph.dir.layout.pool_namespace mydirroot #
getfattr -n ceph.dir.layout mydir ceph.dir.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 \ pool=cephfs_data_a"
Los archivos heredan el diseño de su directorio padre en el momento de la creación. Sin embargo, los cambios posteriores en el diseño del directorio padre no afectan a los hijos:
root #
getfattr -n ceph.dir.layout dir # file: dir ceph.dir.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data" # file1 inherits its parent's layoutroot #
touch dir/file1root #
getfattr -n ceph.file.layout dir/file1 # file: dir/file1 ceph.file.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data" # update the layout of the directory before creating a second fileroot #
setfattr -n ceph.dir.layout.stripe_count -v 4 dirroot #
touch dir/file2 # file1's layout is unchangedroot #
getfattr -n ceph.file.layout dir/file1 # file: dir/file1 ceph.file.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data" # ...while file2 has the parent directory's new layoutroot #
getfattr -n ceph.file.layout dir/file2 # file: dir/file2 ceph.file.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"
Los archivos creados como descendientes del directorio también heredan su diseño si los directorios intermedios no tienen diseños definidos:
root #
getfattr -n ceph.dir.layout dir # file: dir ceph.dir.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"root #
mkdir dir/childdirroot #
getfattr -n ceph.dir.layout dir/childdir dir/childdir: ceph.dir.layout: No such attributeroot #
touch dir/childdir/grandchildroot #
getfattr -n ceph.file.layout dir/childdir/grandchild # file: dir/childdir/grandchild ceph.file.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"
Antes de poder utilizar un repositorio con CephFS, debe añadirlo al servidor de metadatos:
cephadm@adm >
ceph fs add_data_pool cephfs cephfs_data_ssdcephadm@adm >
ceph fs ls # Pool should now show up .... data pools: [cephfs_data cephfs_data_ssd ]
Asegúrese de que sus claves cephx permiten que el cliente acceda a este nuevo repositorio.
Después, puede actualizar el diseño en un directorio de CephFS para utilizar el repositorio que ha añadido:
root #
mkdir /mnt/cephfs/myssddirroot #
setfattr -n ceph.dir.layout.pool -v cephfs_data_ssd /mnt/cephfs/myssddir
Todos los archivos nuevos creados dentro de ese directorio heredarán ahora su diseño y colocarán sus datos en el repositorio recién añadido. Es posible que observe que el número de objetos del repositorio de datos primario sigue aumentando, incluso si se están creando archivos en el repositorio que acaba de añadir. Esto es normal: los datos de archivo se almacenan en el repositorio especificado por el diseño, pero una pequeña cantidad de metadatos se conserva en el repositorio de datos primario para todos los archivos.