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 5

13 Sistema de archivos con agrupación 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 Capítulo 11, Instalación de CephFS.

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

13.1.1 Preparación del cliente

Si el host de cliente ejecuta SUSE Linux Enterprise 12 SP2 o SP3, puede omitir esta sección, ya que el sistema 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 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.

13.1.2 Creación de un archivo de 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:

Procedimiento 13.1: Creación de una clave de secreto
  1. Muestre la clave para el usuario concreto en un archivo de anillo de claves:

    cat /etc/ceph/ceph.client.admin.keyring
  2. Copie 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==
  3. Cree un archivo con el nombre de usuario como parte del nombre de archivo; por ejemplo, /etc/ceph/admin.secret para el usuario admin.

  4. Pegue el valor de la clave en el archivo creado en el paso anterior.

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

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

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

sudo mount -t ceph ceph_mon1:6789:/ /mnt/cephfs \
 -o name=admin,secretfile=/etc/ceph/admin.secret

Tenga en cuenta que el archivo de secreto solo debe contener el secreto del anillo de claves actual. En nuestro ejemplo, el archivo solo contendrá la línea siguiente:

AQATSKdNGBnwLhAAnNDKnH65FmVKpXZJVasUeQ==
Sugerencia
Sugerencia: especificación de varios monitores

Resulta recomendable especificar varios monitores separados por comas en la línea del comando mount por si un monitor se desactiva en algún momento del montaje. Las direcciones de los monitores tiene el formato host[:puerto]. Si no se especifica el puerto, se utiliza por defecto el 6789.

Cree el punto de montaje en el host local:

sudo mkdir /mnt/cephfs

Monte CephFS:

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

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

sudo mount -t ceph ceph_mon1,ceph_mon2,ceph_mon3:6789:/ /mnt/cephfs \
 -o name=admin,secretfile=/etc/ceph/admin.secret
Importante
Importante: acceso de lectura al directorio raíz

Si se usan clientes con restricciones de vía, es preciso incluir acceso de lectura al directorio raíz en los permisos del servidor de metadatos. Por ejemplo, un anillo de claves puede tener este aspecto:

client.bar
 key: supersecretkey
 caps: [mds] allow rw path=/barjail, allow r path=/
 caps: [mon] allow r
 caps: [osd] allow rwx

La parte allow r path=/ significa que los clientes que tienen vías restringidas podrán ver el volumen raíz, pero no escribir en él. Esto puede ser un problema para los casos en los que se requiera aislamiento completo.

13.2 Desmontaje de CephFS

Para desmontar CephFS, utilice el comando umount:

sudo umount /mnt/cephfs

13.3 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

13.4 Varios daemons de servidor de metadatos activos (servidor de metadatos 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í.

13.4.1 Cuándo debe utilizarse un 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.

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

root@master # ceph status
  [...]
  services:
    [...]
    mds: cephfs-1/1/1 up  {0=node2=up:active}, 1 up:standby
    [...]
root@master # ceph mds set max_mds 2
root@master # ceph status
  [...]
  services:
    [...]
    mds: cephfs-2/2/2 up  {0=node2=up:active,1=node1=up:active}
    [...]

El rango recién creado (1) pasa por el estado de "creación" y entra en su estado "activo".

Importante
Importante: daemons en espera

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.

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

root@master # ceph status
  [...]
  services:
    [...]
    mds: cephfs-2/2/2 up  {0=node2=up:active,1=node1=up:active}
    [...]
root@master # ceph mds set max_mds 1
root@master # ceph status
  [...]
  services:
    [...]
    mds: cephfs-1/1/1 up  {0=node2=up:active}, 1 up:standby
    [...]

Fíjese en que sigue teniendo dos servidores de metadatos activos. Los rangos aún existen, aunque hemos reducido el número de max_mds, ya que max_mds solo restringe la creación de nuevos rangos.

A continuación, use el comando ceph mds deactivate rango para eliminar el rango que no se necesita:

root@master # ceph status
  [...]
  services:
    [...]
    mds: cephfs-2/2/1 up  {0=node2=up:active,1=node1=up:active}
root@master # ceph mds deactivate 1
telling mds.1:1 192.168.58.101:6805/2799214375 to deactivate

root@master # ceph status
  [...]
  services:
    [...]
    mds: cephfs-2/2/1 up  {0=node2=up:active,1=node1=up:stopping}

root@master # ceph status
  [...]
  services:
    [...]
    mds: cephfs-1/1/1 up  {0=node2=up:active}, 1 up:standby

El rango desactivado entrará primero en estado de detención durante el tiempo que tarda en entregar sus metadatos a los restantes daemons activos. Esta fase puede tardar entre unos segundos y varios minutos. Si parece que el servidor de metadatos se ha bloqueado en el estado de detención, investigue si existe algún error.

Si un daemon de servidor de metadatos se bloquea o se interrumpe mientras se encuentra en estado de "detención", un daemon en espera ocupará su lugar y el rango volverá al estado "activo". Puede probar a desactivarlo de nuevo cuando se haya recuperado.

Cuando el daemon termina la fase de detención, se inicia y vuelve a un estado de espera.

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

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:

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.

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

13.5.1 Configuración de daemons en espera

Existen varios valores de configuración que controlan el comportamiento de un daemon en espera. Puede especificarlos en el archivo ceph.conf del host donde se ejecuta el daemon de servidor de metadatos. El daemon carga estos valores cuando se inicia y los envía al monitor.

Por defecto, si no se usa ninguno de estos valores, todos los daemons de servidor de metadatos que no tengan un rango se utilizarán como daemons en espera para cualquier rango.

Los valores que asocian un daemon en espera con un nombre o rango en concreto no garantizan que el daemon solo se use para ese rango. Esto significa que si hay varios daemons en espera disponibles, se utilizará el daemon en espera asociado. Si un rango falla y hay un daemon en espera disponible, se utilizará aunque esté asociado a un rango o un nombre distinto.

mds_standby_replay

Si se define como verdadero, el daemon en espera leerá de forma continua el diario de metadatos de un rango superior. De esta forma, su caché de metadatos estará listo y se acelera el proceso de recuperación tras fallo si el daemon que presta servicios al rango falla.

Un rango superior solo puede tener un daemon de respuesta en espera asignado. Si se definen dos daemons para que sean daemons de respuesta en espera, uno de ellos se asignará de forma arbitraria y el otro se convertirá en un daemon no de respuesta en espera normal.

Si un daemon ha entrado en estado de respuesta en espera, solo se utilizará como daemon en espera para el rango al que sigue. Si otro rango falla, este daemon de respuesta en espera no se utilizará como sustituto, aunque no haya ningún otro daemon en espera disponible.

mds_standby_for_name

Defina esta opción para que el daemon en espera solo asuma el puesto de un rango que ha fallado si el último daemon que lo aloja coincide con este nombre.

mds_standby_for_rank

Defina esta opción para que el daemon en espera solo asuma el puesto del rango especificado. Si falla otro rango, este daemon no se utilizará para sustituirlo.

Úselo junto con mds_standby_for_fscid para especificar claramente a qué rango del sistema de archivos se debe dirigir en caso de que haya varios sistemas de archivos.

mds_standby_for_fscid

Si mds_standby_for_rank está definido, se trata simplemente de un calificador para indicar a qué rango del sistema de archivos se hace referencia.

Si mds_standby_for_rank no está definido, el valor FSCID provocará que este daemon se dirija a cualquier rango del FSCID especificado. Utilice esta opción si tiene un daemon que desea utilizar para cualquier rango, pero solo en un sistema de archivos concreto.

mon_force_standby_active

Este valor se utiliza en los hosts de monitor. Por defecto, su valor es true (verdadero).

Si es false (falso), los daemons configurados con standby_replay=true solo se convertirán en activos si falla el rango o el nombre que tienen configurado para seguir. Por otro lado, si el valor es true (verdadero), un daemon configurado con standby_replay=true se puede asignar a otro rango.

13.5.2 Ejemplos

A continuación se muestran varios ejemplos de configuraciones de ceph.conf. Puede copiar un ceph.conf con la configuración de todos los daemons en todos los servidores, o bien puede tener un archivo diferente en cada servidor que contenga la configuración del daemon de dicho servidor.

13.5.2.1 Par simple

Hay dos daemons de servidor de metadatos "a" y "b" que actúan como un par. Si alguno de ellos no se ha asignado a un rango, será el seguidor de respuesta en espera del otro.

[mds.a]
mds standby replay = true
mds standby for rank = 0

[mds.b]
mds standby replay = true
mds standby for rank = 0
Imprimir esta página