Guía de distribución
- Acerca de esta guía
- I SUSE Enterprise Storage
- II Distribución y actualización del clúster
- III Instalación de servicios adicionales
- IV Distribución de clústeres sobre la plataforma SUSE CaaS 4 (versión preliminar de tecnología)
- A Actualizaciones de mantenimiento de Ceph basadas en versiones secundarias superiores de Nautilus
- Glosario
- B Actualizaciones de la documentación
11 Instalación de CephFS #Edit source
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.
11.1 Escenarios admitidos de CephFS y directrices #Edit source
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ánpasivos. No olvide mencionar todos los nodos MON en el comandomountcuando 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
byteso losarchivosalmacenados 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”).
11.2 Servidor de metadatos de Ceph #Edit source
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.
11.2.1 Adición de un servidor de metadatos #Edit source
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.
11.2.2 Configuración de un servidor de metadatos #Edit source
Puede ajustar con más detalle el comportamiento del servidor de metadatos insertando las opciones relevantes en el archivo de configuración ceph.conf.
Configuración del servidor de metadatos #
- mon force standby active
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 limitLa 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 reservationLa 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.
- mds cache size
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 limitpara limitar la cantidad de memoria que utiliza la memoria caché del MDS.- mds cache mid
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.
- mds dir commit ratio
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.
- mds dir max commit size
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.
- mds decay halflife
La vida media de la temperatura de caché del MDS. El valor por defecto es 5.
- mds beacon interval
La frecuencia en segundos de los mensajes de baliza enviados al monitor. El valor por defecto es 4.
- mds beacon grace
El intervalo sin balizas antes de que Ceph declare que un MDS tiene retrasos y, posiblemente, lo reemplace. El valor por defecto es 15.
- mds blacklist interval
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 addseguirá utilizando el tiempo por defecto de la lista negra. El valor por defecto es 24*60.- mds reconnect timeout
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.
- mds tick interval
Indica con qué frecuencia el MDS realiza tareas periódicas internas. El valor por defecto es 5.
- mds dirstat min interval
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.
- mds scatter nudge interval
La rapidez con la que los cambios de dirstat se propagan. El valor por defecto es 5.
- mds client prealloc inos
El número de inodos que se van a preasignar por sesión de cliente. El valor por defecto es 1000.
- mds early reply
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).
- mds use tmap
Utiliza el mapa trivial para las actualizaciones de directorios. El valor por defecto es "true" (verdadero).
- mds default dir hash
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").
- mds log skip corrupt events
Determina si el MDS debe intentar omitir los eventos de diario dañados durante la respuesta del diario. El valor por defecto es "false".
- mds log max events
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.
- mds log max segments
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.
- mds log max expiring
El número máximo de segmentos que pueden caducar en paralelo. El valor por defecto es 20.
- mds log eopen size
El número máximo de inodos en un evento de EOpen. El valor por defecto es 100.
- mds bal sample interval
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.
- mds bal replicate threshold
La temperatura máxima que se puede alcanzar antes de que Ceph intente replicar metadatos a otros nodos. El valor por defecto es 8000.
- mds bal unreplicate threshold
La temperatura mínima que se debe alcanzar antes de Ceph deje de replicar metadatos a otros nodos. El valor por defecto es 0.
- mds bal split size
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.
- mds bal split rd
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.
- mds bal split wr
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.
- mds bal split bits
El número de bits por los que se va a dividir un fragmento de directorio. El valor por defecto es 3.
- mds bal merge size
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.
- mds bal interval
La frecuencia en segundos de los intercambios de carga de trabajo entre MDS. El valor por defecto es 10.
- mds bal fragment interval
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.
- mds bal fragment fast factor
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.
- mds bal fragment size max
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.
- mds bal idle threshold
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.
- mds bal mode
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.
- mds bal min rebalance
La temperatura mínima que puede alcanzar el subárbol antes de que Ceph migre. El valor por defecto es 0.1.
- mds bal min start
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.
- mds bal need min
La fracción mínima del tamaño del subárbol de destino que se debe aceptar. El valor por defecto es 0.8.
- mds bal need max
La fracción máxima del tamaño del subárbol de destino que se debe aceptar. El valor por defecto es 1.2.
- mds bal midchunk
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.
- mds bal minchunk
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.
- mds bal target removal min
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.
- mds bal target removal max
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.
- mds replay interval
El intervalo de sondeo del diario cuando está en modo de respuesta en espera ("hot standby"). El valor por defecto es 1.
- mds shutdown check
El intervalo para sondear la memoria caché durante el apagado del MDS. El valor por defecto es 0.
- mds thrash fragments
Ceph fragmentará o combinará aleatoriamente los directorios. El valor por defecto es 0.
- mds dump cache on map
Ceph volcará el contenido del caché del MDS en un archivo de cada mapa de MDS. El valor por defecto es "false".
- mds dump cache after rejoin
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".
- mds standby for name
Un daemon del MDS quedará a la espera de otro daemon del MDS con el nombre especificado en este ajuste.
- mds standby for rank
Un daemon del MDS quedará a la espera de un daemon del MDS de este rango. El valor por defecto es -1.
- mds standby replay
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".
- mds min caps per client
Define el número mínimo de capacidades que puede tener un cliente. El valor por defecto es 100.
- mds max ratio caps per client
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.
Configuración del creador de diarios del servidor de metadatos #
- journaler write head interval
Indica con qué frecuencia se actualiza el objeto de titular de diario. El valor por defecto es 15.
- journaler prefetch periods
Indica cuántos períodos de repartición se deben leer por adelantado en la respuesta del diario. El valor por defecto es 10.
- journal prezero periods
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.
- journaler batch interval
La latencia máxima adicional en segundos en la que se incurre artificialmente. El valor por defecto es 0.001.
- journaler batch max
El número máximo de bytes por el que se debe retrasar el vaciado. El valor por defecto es 0.
11.3 CephFS #Edit source
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.
11.3.1 Creación de CephFS #Edit source
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_namePor ejemplo:
cephadm@adm > ceph fs new cephfs cephfs_metadata cephfs_dataPara comprobar que se ha creado el sistema de archivos, puede mostrar todos los sistemas de archivos CephFS disponibles:
cephadm@adm >cephfs lsname: 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 >cephmds state5: 1/1/1 up
Sugerencia: otros temas
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.
11.3.2 Tamaño del clúster del servidor de metadatos #Edit source
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 statEl 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 1y, 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.
11.3.3 Clúster de servidor de metadatos y actualizaciones #Edit source
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
systemden todos los otros nodos:cephadm@mds >systemctl stop ceph-mds\*.service ceph-mds.targetSolo 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.targetReinicie todos los demás daemons del servidor de metadatos y vuelva a definir el valor de
max_mdsque 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.
11.3.4 Diseños de archivos #Edit source
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.
11.3.4.1 Campos de diseño #Edit source
Se reconocen los siguientes campos de atributo:
- pool
El ID o nombre de un repositorio RADOS en el que se almacenarán los objetos de datos de un archivo.
- pool_namespace
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.
- stripe_unit
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.
- stripe_count
El número de unidades de partición consecutivas que constituyen una "partición" RAID 0 de datos de archivo.
- object_size
El tamaño en bytes de los objetos RADOS en los que se fragmentan los datos del archivo.
Sugerencia: tamaños de los objetos
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.
11.3.4.2 Diseño de lectura con getfattr #Edit source
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"
Sugerencia: ID o nombre del repositorio
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"
11.3.4.3 Diseños de escritura con setfattr #Edit source
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
Nota: archivo vacío
Si los campos de diseño de un archivo se modifican mediante setfattr, este archivo debe estar vacío, o se producirá un error.
11.3.4.4 Limpieza de diseños #Edit source
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 mydirDel 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"
11.3.4.5 Herencia de diseños #Edit source
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"
11.3.4.6 Adición de un repositorio de datos al servidor de metadatos #Edit source
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 ]
Sugerencia: claves cephx
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.