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

18 Consejos y sugerencias

Este capítulo proporciona información que le ayudará a mejorar el rendimiento de su clúster de Ceph y ofrece sugerencias sobre cómo configurarlo.

18.1 Ajuste del borrado seguro

Por defecto, Ceph realiza un borrado seguro ligero (encontrará más información en la Sección 6.5, “Borrado seguro”) a diario y un borrado más profundo semanalmente. El borrado seguro ligero comprueba el tamaño y la suma de comprobación de los objetos para asegurarse de que los grupos de colocación almacenan los datos de los mismos objetos. El borrado seguro profundo compara el contenido de un objeto con el de las réplicas para asegurarse de que el contenido real es el mismo. El inconveniente de comprobar la integridad de los datos es que aumenta la carga de E/S en el clúster durante el procedimiento de borrado.

La configuración por defecto permite que los Ceph OSD inicien el borrado seguro a horas inapropiadas, por ejemplo durante períodos de mucha carga. Los clientes pueden experimentar latencia y un rendimiento bajo cuando las operaciones de borrado seguro se producen al mismo tiempo que sus operaciones cotidianas. Ceph ofrece varias configuraciones que permiten limitar el borrado seguro solo a los períodos donde se produce menor carga o fuera de las horas de máxima actividad.

Si el clúster experimenta cargas elevadas durante el día, pero la carga baja de madrugada, puede restringir las operaciones de borrado seguro a esas horas, por ejemplo de las 23:00 a las 06:00:

[osd]
osd_scrub_begin_hour = 23
osd_scrub_end_hour = 6

Si la restricción horaria no supone un método eficaz para determinar la programación del borrado seguro, puede probar con la opción osd_scrub_load_threshold. El valor por defecto es 0,5, pero se puede modificar a condiciones de carga más baja:

[osd]
osd_scrub_load_threshold = 0.25

18.2 Detención de los OSD sin reequilibrio de carga

A veces es necesario detener periódicamente los OSD para realizar labores de mantenimiento. Si no desea que CRUSH reequilibre automáticamente la carga del clúster y evitar así enormes volúmenes de transferencia de datos, primero defina el valor noout en el clúster:

root@minion > ceph osd set noout

Si el clúster tiene definido el valor noout, puede empezar a detener los OSD en el dominio de fallo que requiere labores de mantenimiento:

root@minion > systemctl stop ceph-osd@OSD_NUMBER.service

Podrá obtener más información en la Sección 3.1.2, “Inicio, detención y reinicio de servicios individuales”.

Después de que se complete el mantenimiento, inicie de nuevo los OSD:

root@minion > systemctl start ceph-osd@OSD_NUMBER.service

Cuando los servicios de OSD se hayan iniciado, anule la definición del valor noout en el clúster:

root@minion > ceph osd unset noout

18.3 Sincronización horaria de nodos

Ceph requiere que la hora se sincronice de forma precisa entre los nodos individuales. Debe configurar un nodo con su propio servidor NTP. Aunque puede hacer que todas las instancias ntpd señalen a un servidor de hora público remoto, no se recomienda hacerlo con Ceph. Con esta configuración, cada nodo del clúster tiene su propio daemon NTP que se comunica de forma continua por Internet con un conjunto de tres o cuatro servidores de hora, los cuales pueden estar a mucha distancia. Esta solución introduce una gran variabilidad de latencia que dificulta o hace imposible que la diferencia de hora quede por debajo de los 0,05 segundos (que es lo que requieren los monitores de Ceph).

Por lo tanto, se debe utilizar un solo equipo como servidor NTP para todo el clúster. La instancia ntpd del servidor NTP sí puede señalar al servidor NTP (público) remoto, o puede tener su propia fuente horaria. Las instancias ntpd de todos los nodos señalarán a este servidor local. Esta solución ofrece varias ventajas: se elimina el tráfico de red innecesario y las diferencias de hora, y se reduce la carga en los servidores NTP públicos. Para obtener información sobre cómo configurar el servidor NTP, consulte la Guía de administración de SUSE Linux Enterprise Server.

Para cambiar la hora en el clúster, haga lo siguiente:

Importante
Importante: establecimiento de la hora

Puede darse el caso de que haya que retrasar la hora, por ejemplo si cambia del horario de verano al estándar. No se recomienda retrasar la hora más tiempo del que el clúster pase inactivo. Adelantar la hora no provoca ningún problema.

Procedimiento 18.1: Sincronización de hora en el clúster
  1. Detenga todos los clientes que acceden al clúster de Ceph, especialmente los que usen iSCSI.

  2. Apague el clúster de Ceph. En cada nodo ejecute:

    systemctl stop ceph.target
    Nota
    Nota

    Si utiliza Ceph y SUSE OpenStack Cloud, detenga también SUSE OpenStack Cloud.

  3. Verifique que el servidor NTP está configurado correctamente: todos los daemons ntpd obtienen la hora de fuentes en la red local.

  4. Defina la hora correcta en el servidor NTP.

  5. Verifique que NTP se está ejecutando y funciona correctamente. Para ello, en todos los nodos, ejecute:

    status ntpd.service

    O bien

    ntpq -p
  6. Inicie todos los nodos de supervisión y verifique que no hay diferencia de hora:

    systemctl start target
  7. Inicie todos los nodos OSD.

  8. Inicie los demás servicios de Ceph.

  9. Inicie SUSE OpenStack Cloud, si lo tiene instalado.

18.4 Comprobación de escritura de datos desequilibrada

Cuando se escriben datos en los OSD de forma uniforme, se considera que el clúster está equilibrado. A cada OSD de un clúster se le asigna su peso. El peso es un número relativo que indica a Ceph qué cantidad de datos debe escribirse en el OSD relacionado. Cuanto mayor sea el peso, más datos se escribirán. Si un OSD tiene un peso de cero, no se escribirán datos en él. Si el peso de un OSD es relativamente alto en comparación con otros OSD, una gran parte de los datos se escribirá allí, lo que provoca que el clúster esté desequilibrado.

Los clústeres desequilibrados tienen un rendimiento pobre y, en caso de que un OSD con un peso alto se detenga por error de repente, habrá que mover un gran volumen de datos a otros OSD, lo que ralentizará también el clúster.

Para evitar este problema, debe comprobar con regularidad la cantidad de datos que se escriben en los OSD. Si la cantidad se encuentra entre el 30 % y el 50 % de la capacidad de un grupo de OSD especificados por un conjunto determinado de reglas, debe repartir el peso de los OSD. Compruebe cada disco y descubra cuál de ellos se llena más rápido que los demás (o suele ser más lento) y reduzca su peso. Lo mismo es válido para los OSD donde no se escriben suficientes datos: puede aumentar su peso para que Ceph escriba más datos en ellos. En el ejemplo siguiente, descubrirá el peso del OSD con el ID 13 y cambiará su peso de 3 a 3,05:

$ ceph osd tree | grep osd.13
 13  3                   osd.13  up  1

 $ ceph osd crush reweight osd.13 3.05
 reweighted item id 13 name 'osd.13' to 3.05 in crush map

 $ ceph osd tree | grep osd.13
 13  3.05                osd.13  up  1
Sugerencia
Sugerencia: cambio de peso de los OSD por utilización

El comando ceph osd reweight-by-utilization umbral automatiza el proceso de reducir el peso de los OSD que se usan muy por encima de los demás. Por defecto, reduce los pesos de los OSD que alcanzan un 120 % del uso promedio; pero si incluye un umbral, utilizará ese porcentaje en su lugar.

18.5 Subvolumen Btrfs para /var/lib/ceph

SUSE Linux Enterprise se instala por defecto en una partición Btrfs. El directorio /var/lib/ceph debería excluirse de las instantáneas y las reversiones de Btrfs, sobre todo cuando se ejecuta un monitor en el nodo. DeepSea proporciona el runner fs, que puede configurar un subvolumen para esta vía.

18.5.1 Requisitos para una instalación nueva

Si va a configurar el clúster por primera vez, deben cumplirse los siguientes requisitos antes de poder utilizar el runner de DeepSea:

  • Salt y DeepSea deben estar correctamente instalados y en funcionamiento según las especificaciones de esta documentación.

  • salt-run state.orch ceph.stage.0 se debe haber invocado para sincronizar todos los módulos de Salt y DeepSea con los minions

  • Ceph no está instalado aún, por lo que ceph.stage.3 aún no se ha ejecutado y /var/lib/ceph no existe.

18.5.2 Requisitos para una instalación existente

Si el clúster ya está instalado, deben cumplirse los siguientes requisitos antes de poder utilizar el runner de DeepSea:

  • Los nodos se deben actualizar a SUSE Enterprise Storage y el clúster debe estar bajo control de DeepSea.

  • El clúster de Ceph debe estar activado y en buen estado.

  • El proceso de actualización debe haber sincronizado los módulos de Salt y DeepSea con todos los nodos de minion.

18.5.3 Configuración automática

  • En el master de Salt, ejecute:

    root@master # salt-run state.orch ceph.migrate.subvolume

    En los nodos que no tengan el directorio /var/lib/ceph, esta operación realizará las siguientes acciones en un nodo cada vez:

    • creará /var/lib/ceph como subvolumen @/var/lib/ceph de Btrfs;

    • montará el nuevo subvolumen y actualizará en consecuencia /etc/fstab;

    • inhabilitará la copia de escritura para /var/lib/ceph.

    En los nodos que ya tengan una instalación de Ceph, esta operación realizará las siguientes acciones en un nodo cada vez:

    • interrumpirá la ejecución de los procesos de Ceph;

    • desmontará los OSD del nodo;

    • creará el subvolumen @/var/lib/ceph de Btrfs y migrará los datos existentes de /var/lib/ceph;

    • montará el nuevo subvolumen y actualizará en consecuencia /etc/fstab;

    • inhabilitará la copia de escritura para /var/lib/ceph/*, omitiendo /var/lib/ceph/osd/*;

    • volverá a montar los OSD;

    • volverá a iniciar los daemons de Ceph.

18.5.4 Configuración manual

Aquí se usa el nuevo runner fs.

  1. Revise el estado de /var/lib/ceph en todos los nodos e imprima las sugerencias sobre cómo continuar:

    root@master # salt-run fs.inspect_var

    Aparecerá uno de los comandos siguientes:

    salt-run fs.create_var
    salt-run fs.migrate_var
    salt-run fs.correct_var_attrs
  2. Ejecute el comando que se ha devuelto en el paso anterior.

    Si se produce un error en uno de los nodos, la ejecución de los demás nodos se detiene y el runner intentará revertir los cambios realizados. Para determinar cuál ha sido el problema, consulte los archivos de registro de los minions que han fallado. El runner se puede volver a ejecutar después de que se haya resuelto el problema.

El comando salt-run fs.help proporciona una lista de todos los comandos de runner y de módulo para el módulo fs.

18.6 Aumento de los descriptores de archivo

Para los daemons de OSD, las operaciones de lectura/escritura son esenciales para mantener el clúster de Ceph equilibrado. A menudo, necesitan tener muchos archivos abiertos para leer y escribir al mismo tiempo. En el nivel del sistema operativo, el número máximo de archivos abiertos al mismo tiempo se denomina "número máximo de descriptores de archivo".

Para evitar que los OSD se queden sin descriptores de archivo, puede sustituir el valor por defecto del sistema operativo y especificar el número en /etc/ceph/ceph.conf; por ejemplo:

max_open_files = 131072

Después de cambiar max_open_files, es necesario reiniciar el servicio de OSD en el nodo de Ceph pertinente.

18.7 Cómo usar las particiones existentes para los OSD, incluidos los diarios de OSD

Importante
Importante

En esta sección se describe un tema avanzado solo dirigido a expertos y desarrolladores. Es necesario sobre todo si se usan tamaños de diario de OSD no estándar. Si el tamaño de la partición de OSD es de menos de 10 GB, su peso inicial se redondea a 0 y, por lo tanto, no se coloca en ella ningún dato, por lo que deberá aumentar su peso. No aceptamos ninguna responsabilidad por diarios saturados.

Si necesita utilizar las particiones de disco existentes como nodo de OSD, el diario de OSD y las particiones de datos deben estar en una tabla de particiones GPT.

Debe definir los tipos de partición correctos para las particiones de OSD, de forma que udev los reconozca correctamente y defina su propiedad a ceph:ceph.

Por ejemplo, para definir el tipo de partición de la partición de diario como /dev/vdb1 y la partición de datos como /dev/vdb2, ejecute lo siguiente:

sudo sgdisk --typecode=1:45b0969e-9b03-4f30-b4c6-b4b80ceff106 /dev/vdb
sudo sgdisk --typecode=2:4fbd7e29-9d25-41b8-afd0-062c0ceff05d /dev/vdb
Sugerencia
Sugerencia

Los tipos de tablas de particiones de Ceph se muestran en /usr/lib/udev/rules.d/95-ceph-osd.rules:

cat /usr/lib/udev/rules.d/95-ceph-osd.rules
# OSD_UUID
ACTION=="add", SUBSYSTEM=="block", \
  ENV{DEVTYPE}=="partition", \
  ENV{ID_PART_ENTRY_TYPE}=="4fbd7e29-9d25-41b8-afd0-062c0ceff05d", \
  OWNER:="ceph", GROUP:="ceph", MODE:="660", \
  RUN+="/usr/sbin/ceph-disk --log-stdout -v trigger /dev/$name"
ACTION=="change", SUBSYSTEM=="block", \
  ENV{ID_PART_ENTRY_TYPE}=="4fbd7e29-9d25-41b8-afd0-062c0ceff05d", \
  OWNER="ceph", GROUP="ceph", MODE="660"

# JOURNAL_UUID
ACTION=="add", SUBSYSTEM=="block", \
  ENV{DEVTYPE}=="partition", \
  ENV{ID_PART_ENTRY_TYPE}=="45b0969e-9b03-4f30-b4c6-b4b80ceff106", \
  OWNER:="ceph", GROUP:="ceph", MODE:="660", \
  RUN+="/usr/sbin/ceph-disk --log-stdout -v trigger /dev/$name"
ACTION=="change", SUBSYSTEM=="block", \
  ENV{ID_PART_ENTRY_TYPE}=="45b0969e-9b03-4f30-b4c6-b4b80ceff106", \
  OWNER="ceph", GROUP="ceph", MODE="660"
[...]

18.8 Integración con software de virtualización

18.8.1 Almacenamiento de discos KVM en el clúster de Ceph

Puede crear una imagen de disco para una máquina virtual basada en KVM, almacenarla en un repositorio de Ceph, convertir en ella opcionalmente el contenido de una imagen existente y, a continuación, ejecutar la máquina virtual con qemu-kvm haciendo uso de la imagen de disco almacenada en el clúster. Para obtener más detalles, consulte el Capítulo 17, Ceph como procesador final para la instancia de QEMU KVM.

18.8.2 Almacenamiento de discos libvirt en el clúster de Ceph

Como ocurre con KVM (consulte la Sección 18.8.1, “Almacenamiento de discos KVM en el clúster de Ceph”), puede utilizar Ceph para almacenar máquinas virtuales gestionadas con libvirt. La ventaja es que puede ejecutar cualquier solución de virtualización compatible con libvirt, como KVM, Xen o LXC. Para obtener más información, consulte el Capítulo 16, Uso de libvirt con Ceph.

18.8.3 Almacenamiento de discos Xen en el clúster de Ceph

Una manera de utilizar Ceph para almacenar discos Xen es hacer uso de libvirt, como se describe en el Capítulo 16, Uso de libvirt con Ceph.

Otra opción consiste en hacer que Xen se comunique directamente con el controlador del dispositivo de bloques rbd:

  1. Si no tiene ninguna imagen de disco preparada para Xen, cree una nueva:

    rbd create myimage --size 8000 --pool mypool
  2. Muestre las imágenes del repositorio mypool y compruebe si ya existe la nueva imagen:

    rbd list mypool
  3. Cree un dispositivo de bloques nuevo asignando la imagen myimage al módulo de kernel rbd:

    sudo rbd map --pool mypool myimage
    Sugerencia
    Sugerencia: nombre de usuario y autenticación

    Para especificar un nombre de usuario, utilice --id nombre-usuario. Además, si utiliza la autenticación de cephx, también debe especificar un secreto. Puede provenir de un anillo de claves o de un archivo que contenga el secreto:

    sudo rbd map --pool rbd myimage --id admin --keyring /path/to/keyring

    O bien

    sudo rbd map --pool rbd myimage --id admin --keyfile /path/to/file
  4. Muestre todos los dispositivos asignados:

    rbd showmapped
     id pool   image   snap device
     0  mypool myimage -    /dev/rbd0
  5. Ahora puede configurar Xen para que utilice este dispositivo como disco para ejecutar una máquina virtual. Por ejemplo, puede añadir la siguiente línea al archivo de configuración de dominio de estilo xl:

    disk = [ '/dev/rbd0,,sda', '/dev/cdrom,,sdc,cdrom' ]

18.9 Configuración del cortafuegos para Ceph

Aviso
Aviso: las fases de DeepSea fallan con el cortafuegos

Las fases de distribución de DeepSea fallan si el cortafuegos está activo (e incluso solo si está configurado). Para superar las fases correctamente, debe desactivar el cortafuegos ejecutando

root@master # systemctl stop SuSEfirewall2.service

o definir el valor "False" (Falso) en la opción FAIL_ON_WARNING en /srv/pillar/ceph/stack/global.yml:

FAIL_ON_WARNING: False

Se recomienda proteger la comunicación del clúster de red con el cortafuegos de SUSE. Para editar su configuración, seleccione YaST › Security and Users › Firewall › Allowed Services (YaST - Seguridad y usuarios - Cortafuegos - Servicios permitidos).

A continuación se muestra una lista de los servicios relacionados con Ceph y los números de puertos que usan normalmente:

Ceph Monitor

Habilite el servicio Ceph MON o el puerto 6789 (TCP).

Ceph OSD o servidor de metadatos

Habilite el servicio Ceph OSD/MDS o los puerto 6800-7300 (TCP).

iSCSI Gateway

Abra el puerto 3260 (TCP).

Object Gateway

Abra el puerto donde se produce la comunicación de Object Gateway. Se define en /etc/ceph.conf, en la línea que empieza con rgw frontends =. Por defecto es el 80 para HTTP y el 443 para HTTPS (TCP).

NFS Ganesha

Por defecto, NFS Ganesha usa los puertos 2049 (servicio NFS, TCP) y 875 (compatibilidad con rquota, TCP). Consulte la Sección 14.2.3, “Cambio de los puertos por defecto de NFS Ganesha” para obtener más información sobre cómo cambiar los puertos por defecto de NFS Ganesha.

Servicios basados en Apache, como openATTIC, SMT o SUSE Manager

Abra los puertos 80 para HTTP y 443 para HTTPS (TCP).

SSH

Abra el puerto 22 (TCP).

NTP

Abra el puerto 123 (UDP).

Salt

Abra los puertos 4505 y 4506 (TCP).

Grafana

Abra el puerto 3000 (TCP).

Prometheus

Abra el puerto 9100 (TCP).

18.10 Prueba del rendimiento de la red

Para probar el rendimiento de la red, el runner net de DeepSea proporciona los siguientes comandos.

  • Un ping sencillo a todos los nodos:

    root@master # salt-run net.ping
    Succeeded: 9 addresses from 9 minions average rtt 1.35 ms
  • Un ping jumbo a todos los nodos:

    root@master # salt-run net.jumbo_ping
    Succeeded: 9 addresses from 9 minions average rtt 2.13 ms
  • Una prueba de ancho de banda:

    root@master # salt-run net.iperf
    Fastest 2 hosts:
        |_
          - 192.168.58.106
          - 2981 Mbits/sec
        |_
          - 192.168.58.107
          - 2967 Mbits/sec
    Slowest 2 hosts:
        |_
          - 192.168.58.102
          - 2857 Mbits/sec
        |_
          - 192.168.58.103
          - 2842 Mbits/sec

18.11 Sustitución del disco de almacenamiento

Si fuera necesario sustituir un disco de almacenamiento en un clúster de Ceph, puede hacerlo durante el funcionamiento normal del clúster. La sustitución provocará un aumento temporal de la transferencia de datos.

Si el disco falla por completo, Ceph debe reescribir al menos la misma cantidad de datos que la capacidad del disco que ha fallado. Si el disco se extrae correctamente y se vuelve a añadir para evitar la pérdida de redundancia durante el proceso, la cantidad de datos que se reescriben es del doble. Si el nuevo disco tiene un tamaño diferente que el sustituido, se redistribuirán datos adicionales para equilibrar el uso de todos los OSD.

Imprimir esta página