Saltar a contenidoSaltar a navegación de páginas: página anterior [tecla acceso p]/página siguiente [tecla acceso n]
Se aplica a SUSE Enterprise Storage 6

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á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”).

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 Seguridad y usuarios › Cortafuegos › Servicios autorizados y, en el menú desplegable Servicio que se va a autorizar seleccione Ceph OSD/MDS. 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 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.

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 limit para 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 add seguirá 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_num
cephadm@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
Sugerencia
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 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.

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:

  1. Actualice los paquetes relacionados con Ceph mediante zypper.

  2. 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
  3. 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
  4. 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.

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
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 file
root # 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
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 dir
root # getfattr -n ceph.dir.layout dir
dir: ceph.dir.layout: No such attribute
root # setfattr -n ceph.dir.layout.stripe_count -v 2 dir
root # 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_metadata
root # setfattr -n ceph.file.layout.stripe_unit -v 1048576 file
root # 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
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 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 it
root # mkdir mydir
root # setfattr -n ceph.dir.layout.pool_namespace -v foons mydir
root # 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 layout
root # setfattr -x ceph.dir.layout.pool_namespace mydir
root # 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 layout
root # touch dir/file1
root # 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 file
root # setfattr -n ceph.dir.layout.stripe_count -v 4 dir
root # touch dir/file2

# file1's layout is unchanged
root # 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 layout
root # 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/childdir
root # getfattr -n ceph.dir.layout dir/childdir
dir/childdir: ceph.dir.layout: No such attribute
root # touch dir/childdir/grandchild
root # 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_ssd
cephadm@adm > ceph fs ls  # Pool should now show up
.... data pools: [cephfs_data cephfs_data_ssd ]
Sugerencia
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/myssddir
root # 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.

Imprimir esta página