Saltar a contenidoSaltar a navegación de páginas: página anterior [tecla acceso p]/página siguiente [tecla acceso n]
ContenidoContenido
Guía de administración
  1. Acerca de esta guía
  2. I Gestión en clúster
    1. 1 Privilegios de usuario y comandos de símbolos del sistema
    2. 2 Administración de un clúster de Salt
    3. 3 Copia de seguridad de la configuración y los datos del clúster
  3. II Funcionamiento de un clúster
    1. 4 Introducción
    2. 5 Gestión de los servicios de Ceph
    3. 6 Determinación del estado del clúster
    4. 7 Supervisión y alertas
    5. 8 Autenticación con cephx
    6. 9 Gestión de datos almacenados
    7. 10 Módulos de Ceph Manager
    8. 11 Gestión de repositorios de almacenamiento
    9. 12 Dispositivo de bloques RADOS
    10. 13 Repositorios codificados de borrado
    11. 14 Niveles de caché
    12. 15 Mejora del rendimiento con el caché de LVM
    13. 16 Configuración del clúster de Ceph
  4. III Acceso a los datos del clúster
    1. 17 Ceph Object Gateway
    2. 18 Ceph iSCSI Gateway
    3. 19 Sistema de archivos con agrupación en clúster
    4. 20 Exportación de datos de Ceph a través de Samba
    5. 21 NFS Ganesha: exportación de datos de Ceph a través de NFS
  5. IV Gestión del clúster con herramientas de interfaz gráfica de usuario
    1. 22 Ceph Dashboard
  6. V Integración con herramientas de virtualización
    1. 23 Uso de libvirt con Ceph
    2. 24 Ceph como procesador final para la instancia de QEMU KVM
  7. VI Preguntas frecuentes, consejos y solución de problemas
    1. 25 Consejos y sugerencias
    2. 26 Preguntas más frecuentes
    3. 27 Solución de problemas
  8. A Ejemplo personalizado de la fase 1 de DeepSea
  9. B Alertas por defecto para SUSE Enterprise Storage 6
  10. C Actualizaciones de mantenimiento de Ceph basadas en versiones secundarias superiores de Nautilus
  11. Glosario
  12. D Actualizaciones de la documentación
Navegación
Se aplica a SUSE Enterprise Storage 6

25 Consejos y sugerencias Edit source

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.

25.1 Identificación de particiones huérfanas Edit source

Para identificar los posibles dispositivos de diario/WAL/DB huérfanos, lleve a cabo estos pasos:

  1. Elija el dispositivo que puede tener particiones huérfanas y guarde la lista de particiones en un archivo:

    root@minion > ls /dev/sdd?* > /tmp/partitions
  2. Ejecute readlink para todos los dispositivos block.wal, block.db y de diario transaccional y compare la salida con la lista de particiones guardada anteriormente:

    root@minion > readlink -f /var/lib/ceph/osd/ceph-*/{block.wal,block.db,journal} \
     | sort | comm -23 /tmp/partitions -

    La salida es la lista de particiones que Ceph no utiliza.

  3. Elimine las particiones huérfanas que no pertenecen a Ceph con el comando que prefiera (por ejemplo, fdisk, parted o sgdisk).

25.2 Ajuste del borrado seguro Edit source

Por defecto, Ceph realiza un borrado seguro ligero a diario (encontrará más información en la Sección 9.6, “Borrado seguro”) 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

25.3 Detención de los OSD sin reequilibrio de carga Edit source

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

cephadm@adm > ceph osd unset noout

25.4 Sincronización horaria de nodos Edit source

Ceph requiere que la hora se sincronice de forma precisa entre todos los nodos.

Se recomienda sincronizar todos los nodos del clúster de Ceph con al menos tres fuentes de hora de confianza que se encuentren en la red interna. Las fuentes de hora internas pueden dirigir a un servidor de hora público o tener su propia fuente de hora.

Importante
Importante: servidores de hora públicos

No sincronice todos los nodos del clúster de Ceph directamente con servidores de hora públicos remotos. 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 proporcionar horas ligeramente distintas. 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.

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

    root # 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 chronyd 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:

    root # systemctl status chronyd.service
  6. Inicie todos los nodos de supervisión y verifique que no hay diferencia de hora:

    root # 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.

25.5 Comprobación de escritura de datos desequilibrada Edit source

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.

25.6 Subvolumen Btrfs para /var/lib/ceph en nodos de Ceph Monitor Edit source

SUSE Linux Enterprise se instala por defecto en una partición Btrfs. Los monitores Ceph Monitor almacenan su estado y la base de datos en el directorio /var/lib/ceph. Para evitar que un monitor Ceph Monitor se dañe al realizar una reversión del sistema de una instantánea anterior, cree un subvolumen Btrfs para /var/lib/ceph. Un subvolumen dedicado excluye los datos del monitor de las instantáneas del subvolumen raíz.

Sugerencia
Sugerencia

Cree el subvolumen /var/lib/ceph antes de ejecutar la fase 0 de DeepSea, ya que esa fase instala paquetes relacionados con Ceph y crea el directorio /var/lib/ceph.

A continuación, la fase 3 de DeepSea verifica si @/var/lib/ceph es un subvolumen Btrfs y falla si es un directorio normal.

25.6.1 Requisitos Edit source

25.6.1.1 Distribuciones nuevas Edit source

Salt y DeepSea deben instalarse y funcionar correctamente.

25.6.1.2 Distribuciones existentes Edit source

Si el clúster ya está instalado, se deben cumplir los siguientes requisitos:

  • Los nodos se deben actualizar a SUSE Enterprise Storage 6 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.

25.6.2 Pasos necesarios durante una nueva distribución de clúster Edit source

25.6.2.1 Antes de ejecutar la fase 0 de DeepSea Edit source

Antes de ejecutar la fase 0 de DeepSea, aplique los siguientes comandos a cada minion de Salt para que se conviertan en monitores Ceph Monitor:

root@master # salt 'MONITOR_NODES' saltutil.sync_all
root@master # salt 'MONITOR_NODES' state.apply ceph.subvolume

El comando ceph.subvolume hace lo siguiente:

  • Crea /var/lib/ceph como subvolumen Btrfs @/var/lib/ceph.

  • Monta el nuevo subvolumen y actualiza /etc/fstab adecuadamente.

25.6.2.2 La validación de la fase 3 de DeepSea falla Edit source

Si olvidó ejecutar los comandos mencionados en la Sección 25.6.2.1, “Antes de ejecutar la fase 0 de DeepSea” antes de ejecutar la fase 0, el subdirectorio /var/lib/ceph ya existe, lo que provoca un error de validación de la fase 3 de DeepSea. Para convertirlo en un subvolumen, haga lo siguiente:

  1. Cambie el directorio a /var/lib:

    cephadm@mon > cd /var/lib
  2. Realice una copia de seguridad del contenido actual del subdirectorio ceph:

    cephadm@mon > sudo mv ceph ceph-
  3. Cree el subvolumen, móntelo y actualice /etc/fstab:

    root@master # salt 'MONITOR_NODES' state.apply ceph.subvolume
  4. Cambie al subdirectorio de copia de seguridad, sincronice su contenido con el nuevo subvolumen y, a continuación, elimínelo:

    cephadm@mon > cd /var/lib/ceph-
    cephadm@mon > rsync -av . ../ceph
    cephadm@mon > cd ..
    cephadm@mon > rm -rf ./ceph-

25.6.3 Pasos necesarios durante la actualización del clúster Edit source

En SUSE Enterprise Storage 5.5, el directorio /var no está en un subvolumen Btrfs, sino que sus subcarpetas (como /var/log o /var/cache) son subvolúmenes Btrfs en "@". Para crear subvolúmenes @/var/lib/ceph se requiere montar primero el subvolumen "@" (no está montado por defecto) y crear el subvolumen @/var/lib/ceph en él.

A continuación se muestran comandos de ejemplo que ilustran el proceso:

root # mkdir -p /mnt/btrfs
root # mount -o subvol=@ ROOT_DEVICE /mnt/btrfs
root # btrfs subvolume create /mnt/btrfs/var/lib/ceph
root # umount /mnt/btrfs

En este punto, se crea el subvolumen @/var/lib/ceph y es posible continuar como se describe en la Sección 25.6.2, “Pasos necesarios durante una nueva distribución de clúster”.

25.6.4 Configuración manual Edit source

La configuración automática del subvolumen Btrfs de /var/lib/ceph en los nodos de Ceph Monitor puede no ser adecuada para todos los escenarios. Es posible migrar el directorio /var/lib/ceph a un subvolumen /var/lib/ceph siguiendo estos pasos:

  1. Interrumpa la ejecución de los procesos de Ceph.

  2. Desmonte los OSD del nodo.

  3. Cambie al subdirectorio de copia de seguridad, sincronice su contenido con el nuevo subvolumen y, a continuación, elimínelo:

    cephadm@mon > cd /var/lib/ceph-
    cephadm@mon > rsync -av . ../ceph
    cephadm@mon > cd ..
    cephadm@mon > rm -rf ./ceph-
  4. Vuelva a montar los OSD.

  5. Reinicie los daemons de Ceph.

25.6.5 Información adicional Edit source

Encontrará información más detallada sobre la configuración manual en el archivo /srv/salt/ceph/subvolume/README.md del nodo master de Salt.

25.7 Aumento de los descriptores de archivo Edit source

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.

25.8 Integración con software de virtualización Edit source

25.8.1 Almacenamiento de discos KVM en el clúster de Ceph Edit source

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 24, Ceph como procesador final para la instancia de QEMU KVM.

25.8.2 Almacenamiento de discos libvirt en el clúster de Ceph Edit source

Como ocurre con KVM (consulte la Sección 25.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 23, Uso de libvirt con Ceph.

25.8.3 Almacenamiento de discos Xen en el clúster de Ceph Edit source

Una manera de utilizar Ceph para almacenar discos Xen es hacer uso de libvirt, como se describe en el Capítulo 23, 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:

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

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

    cephadm@adm > rbd map --pool mypool myimage
    Sugerencia
    Sugerencia: nombre de usuario y autenticación

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

    cephadm@adm > rbd map --pool rbd myimage --id admin --keyring /path/to/keyring

    O bien

    cephadmrbd 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' ]

25.9 Configuración del cortafuegos para Ceph Edit source

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 # 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 puertos 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 21.2.1.4, “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 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).

25.10 Prueba del rendimiento de la red Edit source

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
    Sugerencia
    Sugerencia: detención manual de procesos "iperf3"

    Al ejecutar una prueba con el runner net.iperf, los procesos de servidor "iperf3" que están iniciados no se detienen automáticamente cuando se completa una prueba. Para detener los procesos, utilice el siguiente runner:

    root@master # salt '*' multi.kill_iperf_cmd

25.11 Cómo localizar discos físicos mediante luces LED Edit source

En esta sección se describe cómo usar libstoragemgmt y otras herramientas de terceros para ajustar las luces LED en los discos físicos. Es posible que esta capacidad no esté disponible para todas las plataformas de hardware.

Hacer coincidir un disco OSD con un disco físico puede ser difícil, especialmente en nodos con alta densidad de discos. Algunos entornos de hardware incluyen luces LED que se pueden ajustar mediante software para que parpadeen o se iluminen en un color diferente para fines de identificación. SUSE Enterprise Storage ofrece compatibilidad con esta capacidad a través de Salt, libstoragemgmt y herramientas de terceros específicas para el hardware que se use. La configuración de esta capacidad se define en el pilar de Salt /srv/pillar/ceph/disk_led.sls:

root #  cat /srv/pillar/ceph/disk_led.sls
# This is the default configuration for the storage enclosure LED blinking.
# The placeholder {device_file} will be replaced with the device file of
# the disk when the command is executed.
#
# Have a look into the /srv/pillar/ceph/README file to find out how to
# customize this configuration per minion/host.

disk_led:
  cmd:
    ident:
      'on': lsmcli local-disk-ident-led-on --path '{device_file}'
      'off': lsmcli local-disk-ident-led-off --path '{device_file}'
    fault:
      'on': lsmcli local-disk-fault-led-on --path '{device_file}'
      'off': lsmcli local-disk-fault-led-off --path '{device_file}'

La configuración por defecto para disk_led.sls ofrece compatibilidad con las luces LED de discos a través de la capa libstoragemgmt. Sin embargo, libstoragemgmt proporciona esta compatibilidad a través de un complemento y herramientas de terceros específicos para el hardware. A menos que se instalen tanto el complemento libstoragemgmt como las herramientas de terceros adecuadas para el hardware, libstoragemgmt no podrá ajustar las luces LED.

Con o sin libstoragemgmt, es posible que se necesiten herramientas de terceros para ajustar las luces LED. Estas herramientas de terceros están disponibles de varios proveedores de hardware. Algunos de los proveedores y herramientas habituales son:

Tabla 25.1: Herramientas de almacenamiento de terceros
Proveedor/Controlador de discosHerramienta
HPE SmartArrayhpssacli
LSI MegaRAIDstorcli

SUSE Linux Enterprise Server también proporciona el paquete ledmon y la herramienta ledctl. Esta herramienta también puede funcionar para entornos de hardware que utilicen carcasas de almacenamiento Intel. La sintaxis adecuada al utilizar esta herramienta es la siguiente:

root #  cat /srv/pillar/ceph/disk_led.sls
disk_led:
  cmd:
    ident:
      'on': ledctl locate='{device_file}'
      'off': ledctl locate_off='{device_file}'
    fault:
      'on': ledctl locate='{device_file}'
      'off': ledctl locate_off='{device_file}'

Si el hardware es compatible, con todas las herramientas de terceros necesarias, los LED se pueden habilitar o inhabilitar mediante la siguiente sintaxis de comandos del nodo master Salt:

root # salt-run disk_led.device NODE DISK fault|ident on|off

Por ejemplo, para habilitar o inhabilitar la identificación LED o las luces de error en /dev/sdd en el nodo OSD srv16.ceph, ejecute lo siguiente:

root # salt-run disk_led.device srv16.ceph sdd ident on
root # salt-run disk_led.device srv16.ceph sdd ident off
root # salt-run disk_led.device srv16.ceph sdd fault on
root # salt-run disk_led.device srv16.ceph sdd fault off
Nota
Nota: nomenclatura de dispositivos

El nombre del dispositivo usado en el comando salt-run debe coincidir con el nombre reconocido por Salt. El comando siguiente se puede utilizar para mostrar estos nombres:

root@master # salt 'minion_name' grains.get disks

En muchos entornos, la configuración /srv/pillar/ceph/disk_led.sls requerirá cambios para ajustar las luces LED para necesidades específicas del hardware. Los cambios simples se pueden realizar reemplazando lsmcli por otra herramienta o ajustando los parámetros de la línea de comandos. Los cambios complejos se pueden realizar llamando a un guion externo en lugar de al comando lsmcli. Al realizar cualquier cambio en /srv/pillar/ceph/disk_led.sls, siga estos pasos:

  1. Realice los cambios necesarios en /srv/pillar/ceph/disk_led.sls en el nodo master de Salt.

  2. Verifique que los cambios se reflejan correctamente en los datos del pilar:

    root # salt 'SALT MASTER*' pillar.get disk_led
  3. Actualice los datos del pilar en todos los nodos mediante:

    root # salt '*' saltutil.pillar_refresh

Es posible utilizar un guion externo para utilizar directamente herramientas de terceros a fin de ajustar las luces LED. Los siguientes ejemplos muestran cómo ajustar /srv/pillar/ceph/disk_led.sls para admitir un guion externo, así como dos guiones de ejemplo para entornos HP y LSI.

/srv/pillar/ceph/disk_led.sls modificado que llama a un guion externo:

root # cat /srv/pillar/ceph/disk_led.sls
disk_led:
  cmd:
    ident:
      'on': /usr/local/bin/flash_led.sh '{device_file}' on
      'off': /usr/local/bin/flash_led.sh '{device_file}' off
    fault:
      'on': /usr/local/bin/flash_led.sh '{device_file}' on
      'off': /usr/local/bin/flash_led.sh '{device_file}' off

Guion de ejemplo para luces LED intermitentes en hardware HP utilizando las utilidades hpssacli:

root # cat /usr/local/bin/flash_led_hp.sh
#!/bin/bash
# params:
#   $1 device (e.g. /dev/sda)
#   $2 on|off

FOUND=0
MAX_CTRLS=10
MAX_DISKS=50

for i in $(seq 0 $MAX_CTRLS); do
  # Search for valid controllers
  if hpssacli ctrl slot=$i show summary >/dev/null; then
    # Search all disks on the current controller
    for j in $(seq 0 $MAX_DISKS); do
      if hpssacli ctrl slot=$i ld $j show | grep -q $1; then
        FOUND=1
        echo "Found $1 on ctrl=$i, ld=$j. Turning LED $2."
        hpssacli ctrl slot=$i ld $j modify led=$2
        break;
      fi
    done
    [[ "$FOUND" = "1" ]] && break
  fi
done

Guion de ejemplo para luces LED intermitentes en hardware LSI utilizando las utilidades storcli:

root # cat /usr/local/bin/flash_led_lsi.sh
#!/bin/bash
# params:
#   $1 device (e.g. /dev/sda)
#   $2 on|off

[[ "$2" = "on" ]] && ACTION="start" || ACTION="stop"

# Determine serial number for the disk
SERIAL=$(lshw -class disk | grep -A2 $1 | grep serial | awk '{print $NF}')
if [ ! -z "$SERIAL" ]; then
  # Search for disk serial number across all controllers and enclosures
  DEVICE=$(/opt/MegaRAID/storcli/storcli64 /call/eall/sall show all | grep -B6 $SERIAL | grep Drive | awk '{print $2}')
  if [ ! -z "$DEVICE" ]; then
    echo "Found $1 on device $DEVICE. Turning LED $2."
    /opt/MegaRAID/storcli/storcli64 $DEVICE $ACTION locate
  else
    echo "Device not found!"
    exit -1
  fi
else
  echo "Disk serial number not found!"
  exit -1
fi
Imprimir esta página