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

1 Administración de un clúster de Salt

Después de distribuir el clúster de Ceph, probablemente tendrá que realizar modificaciones ocasionalmente. Por ejemplo, añadir o eliminar nuevos nodos, discos o servicios. En este capítulo se describe cómo llevar a cabo estas tareas de administración.

1.1 Adición de nuevos nodos de clúster

El procedimiento de añadir nodos nuevos al clúster es casi idéntico a la distribución inicial de nodos del clúster que se describe en el Capítulo 4, Distribución con DeepSea/Salt:

  1. Instale SUSE Linux Enterprise Server 12 SP3 en el nuevo nodo, configure la red de modo que resuelva correctamente el nombre del master de Salt e instale el paquete salt-minion:

    root@minion > zypper in salt-minion

    Si el nombre del master de Salt no es salt, edite /etc/salt/minion y añada lo siguiente:

    master: DNS_name_of_your_salt_master

    Si ha realizado cambios en los archivos de configuración mencionados anteriormente, reinicie el servicio salt.minion:

    root@minion > systemctl restart salt-minion.service
  2. Acepte todas las claves de Salt en el master de Salt:

    root@master # salt-key --accept-all
  3. Compruebe que /srv/pillar/ceph/deepsea_minions.sls también tiene como objetivo el nuevo minion de Salt. Consulte el Sección 4.2.2.1, “Coincidencia del nombre del minion” del Procedimiento 4.1, “Ejecución de fases de distribución” para obtener más detalles.

  4. Ejecute la etapa de preparación. Se sincronizarán los módulos y grains para que el nuevo minion pueda proporcionar toda la información que espera DeepSea:

    root@master # salt-run state.orch ceph.stage.0
  5. Ejecute la etapa de descubrimiento. Se escribirán nuevas entradas de archivos en el directorio /srv/pillar/ceph/proposals, donde podrá editar los archivos .yml relevantes:

    root@master # salt-run state.orch ceph.stage.1
  6. Si lo desea, cambie /srv/pillar/ceph/proposals/policy.cfg si el host recién añadido no coincide con el esquema de denominación existente. Para obtener información detallada, consulte el Sección 4.5.1, “El archivo policy.cfg.

  7. Ejecute la etapa de configuración. Se leerá todo el contenido de /srv/pillar/ceph y el pillar se actualizará en consecuencia:

    root@master # salt-run state.orch ceph.stage.2

    El pillar almacenará los datos, a los que podrá acceder con el siguiente comando:

    root@master # salt target pillar.items
  8. Las etapas de distribución y configuración incluyen los nodos recién añadidos:

    root@master # salt-run state.orch ceph.stage.3
    root@master # salt-run state.orch ceph.stage.4

1.2 Adición de nuevas funciones a los nodos

Puede distribuir cualquier tipo de función compatible con DeepSea. Consulte el Sección 4.5.1.2, “Asignación de funciones” para obtener más información sobre los tipos de funciones compatibles y ejemplos de coincidencias.

Sugerencia
Sugerencia: etapas y funciones obligatorias y opcionales

Generalmente, recomendamos ejecutar todas las etapas de distribución de 0 a 5 al añadir una nueva función a un nodo del clúster. Para ahorrar tiempo, puede omitir las etapas 3 o 4, dependiendo del tipo de función que vaya a distribuir. Aunque las funciones OSD y MON incluyen servicios esenciales y son obligatorias para usar Ceph, otras funciones, como Object Gateway, son opcionales. Las etapas de distribución de DeepSea son jerárquicas: mientras que en la etapa 3 se distribuyen servicios esenciales, en la etapa 4 se distribuye los opcionales.

Por lo tanto, debe ejecutar la etapa 3 para distribuir las funciones esenciales, como MON, en un nodo OSD existente, y puede omitir la etapa 4.

De igual forma, puede omitir la etapa 3 al distribuir servicios opcionales, como Object Gateway, pero en ese caso, debe ejecutar la etapa 4.

Para añadir un nuevo servicio a un nodo existente, siga estos pasos:

  1. Adapte /srv/pillar/ceph/proposals/policy.cfg para que se adapte al host existente con una función nueva. Para obtener más información, consulte el Sección 4.5.1, “El archivo policy.cfg. Por ejemplo, si necesita ejecutar un Object Gateway en un nodo MON, la línea será similar a la siguiente:

    role-rgw/xx/x/example.mon-1.sls
  2. Ejecute la etapa 2 para actualizar el pillar:

    root@master # salt-run state.orch ceph.stage.2
  3. Ejecute la etapa 3 para distribuir los servicios esenciales o la etapa 4 para los opcionales. No es perjudicial ejecutar ambas etapas.

Sugerencia
Sugerencia

Al añadir un OSD al clúster existente, tenga en cuenta que el clúster tardará un tiempo en reequilibrarse. Para minimizar los períodos de reequilibrio, recomendamos añadir al mismo tiempo todos los OSD que tenga previstos.

1.3 eliminación y reinstalación de nodos del clúster

Para eliminar una función de un clúster, edite /srv/pillar/ceph/proposals/policy.cfg y elimine las líneas correspondientes. A continuación, ejecute las etapas 2 y 5, tal como se describe en el Sección 4.3, “Distribución del clúster”.

Nota
Nota: Eliminación de OSD de su clúster

En caso de que deba eliminar un nodo OSD en concreto del clúster, asegúrese de que el clúster tenga más espacio de disco disponible que el disco que pretende eliminar. Tenga en cuenta que la eliminación de un OSD da lugar al reequilibrado de todo el clúster.

Al eliminar una función de un minion, el objetivo es deshacer todos los cambios relacionados con dicha función. Para la mayoría de las funciones, la tarea es sencilla, pero puede haber algunos problemas con las dependencias de paquetes. Al desinstalar un paquete, no se desinstalan sus dependencias.

Los OSD eliminados se muestran como unidades vacías. Las tareas relacionadas sobrescriben el principio de los sistemas de archivos y eliminan las particiones de copia de seguridad, además de borrar las tablas de particiones.

Nota
Nota: conservación de particiones creadas mediante otros métodos

Las unidades de disco configuradas previamente mediante otros métodos, como ceph-deploy, aún podrían contener particiones. DeepSea no las destruirá automáticamente. El administrador debe recuperar estas unidades.

Ejemplo 1.1: Eliminación de un minion de Salt del clúster

Si sus minions de almacenamiento se denominan, por ejemplo, "data1.ceph", "data2.ceph" ... "data6.ceph", y las líneas relacionadas del archivo policy.cfg son similares a las siguientes:

[...]
# Hardware Profile
profile-default/cluster/data*.sls
profile-default/stack/default/ceph/minions/data*.yml
[...]

Para eliminar el minion de Salt "data2.ceph", cambie las líneas por las siguientes:

[...]
# Hardware Profile
profile-default/cluster/data[1,3-6]*.sls
profile-default/stack/default/ceph/minions/data[1,3-6]*.yml
[...]

A continuación, ejecute las etapas 2 y 5:

root@master # salt-run state.orch ceph.stage.2
root@master # salt-run state.orch ceph.stage.5
Ejemplo 1.2: Migración de nodos

Supongamos que se da la siguiente situación: durante la instalación de un nuevo clúster, usted (el administrador) asigna uno de los nodos de almacenamiento como Object Gateway mientras espera la llegada del hardware del gateway. Ahora que ha llegado el hardware permanente para el gateway, por fin puede asignar la función deseada al nodo de almacenamiento de copia de seguridad y eliminar la función de gateway.

Después de ejecutar las etapas 0 y 1 (consulte Procedimiento 4.1, “Ejecución de fases de distribución”) en el nuevo hardware, ha asignado el nombre rgw1 al nuevo gateway. Si el nodo data8 necesita que se añada la función de almacenamiento y se elimine la de Object Gateway y el archivo policy.cfg tiene una configuración semejante a esta:

# Hardware Profile
profile-default/cluster/data[1-7]*.sls
profile-default/stack/default/ceph/minions/data[1-7]*.sls

# Roles
role-rgw/cluster/data8*.sls

Cámbielo a:

# Hardware Profile
profile-default/cluster/data[1-8]*.sls
profile-default/stack/default/ceph/minions/data[1-8]*.sls

# Roles
role-rgw/cluster/rgw1*.sls

Ejecute las etapas 2 a 5. En la etapa 3, se añadirá data8 como nodo de almacenamiento. Durante un momento, data8 tendrá ambas funciones. En la etapa 4, se añadirá la función de Object Gateway a rgw1. En la etapa 5, se eliminará la función de Object Gateway de data8.

1.4 Redistribución de nodos de Monitor

Si uno o varios nodos de Monitor presentan errores y no responden, debe eliminar los monitores fallidos del clúster y, si es posible, volver a añadirlos a continuación.

Importante
Importante: debe haber al menos tres nodos de Monitor

El número de nodos de Monitor no debe ser inferior a tres. Si se produce un error en un nodo de Monitor y el clúster solo cuenta con uno o dos nodos de Monitor, deberá asignar temporalmente la función de Monitor a otros nodos del clúster antes de redistribuir los nodos fallidos. Después de redistribuir los nodos fallidos, puede desinstalar las funciones de Monitor temporales.

Para obtener más información acerca de cómo añadir nodos o funciones al clúster de Ceph, consulte la Sección 1.1, “Adición de nuevos nodos de clúster” y la Sección 1.2, “Adición de nuevas funciones a los nodos”.

Para obtener más información sobre la eliminación de nodos del clúster, consulte la Sección 1.3, “eliminación y reinstalación de nodos del clúster”.

Existen dos grados básicos de fallo de un nodo de Ceph:

  • El host del minion de Salt está averiado físicamente o a nivel de sistema operativo y no responde a la llamada salt 'nombre_minion' test.ping. En ese caso, debe volver a distribuir el servidor completamente siguiendo las instrucciones que encontrará en Sección 4.3, “Distribución del clúster”.

  • Los servicios relacionados con el monitor fallan y no se recuperan, pero el host responde a la llamada salt 'nombre_minion' test.ping. Si se da esta situación, siga estos pasos:

  1. Edite /srv/pillar/ceph/proposals/policy.cfg en el master de Salt y elimine o actualice las líneas correspondientes a los nodos de Monitor fallidos, de modo que lleven a nodos de Monitor en funcionamiento.

  2. Ejecute las etapas 2 a 5 de DeepSea para aplicar los cambios:

    root@master # deepsea stage run ceph.stage.2
    root@master # deepsea stage run ceph.stage.3
    root@master # deepsea stage run ceph.stage.4
    root@master # deepsea stage run ceph.stage.5

1.5 Adición de un OSD a un nodo

Para añadir un disco a un nodo OSD existente, compruebe que todas las particiones del disco se hayan eliminado y borrado. Consulte el Paso 13 de Sección 4.3, “Distribución del clúster” para obtener más información. Cuando el disco esté vacío, añádalo al archivo YAML del nodo. La vía al archivo es /srv/pillar/ceph/proposals/profile-default/stack/default/ceph/minions/nombre_nodo.yml. Después de guardar el archivo, ejecute las etapas 2 y 3 de DeepSea:

root@master # deepsea stage run ceph.stage.2
root@master # deepsea stage run ceph.stage.3
Sugerencia
Sugerencia: actualización automática de los perfiles

En lugar de editar manualmente el archivo YAML, DeepSea puede crear nuevos perfiles automáticamente. Para que DeepSea pueda crear nuevos perfiles, es necesario mover los existentes:

root@master # old /srv/pillar/ceph/proposals/profile-default/
root@master # deepsea stage run ceph.stage.1
root@master # deepsea stage run ceph.stage.2
root@master # deepsea stage run ceph.stage.3

1.6 Eliminación de un OSD

Puede eliminar un OSD de Ceph del clúster ejecutando el siguiente comando:

root@master # salt-run disengage.safety
root@master # salt-run remove.osd OSD_ID

OSD_ID debe ser el número del OSD sin el término osd. Por ejemplo, para osd.3, utilice solo el dígito 3.

Sugerencia
Sugerencia: eliminación de varios OSD

No es posible eliminar varios OSD en paralelo con el comando salt-run remove.osd. Para automatizar la eliminación de varios OSD, puede emplear el siguiente bucle (5, 21, 33 y 19 son números de ID de OSD que se deben eliminar):

for i in 5 21 33 19
do
 echo $i
 salt-run disengage.safety
 salt-run remove.osd $i
done

1.6.1 Eliminación forzosa de OSD dañados

Existen casos en que el procedimiento de eliminación ordenada de un OSD (consulte la Sección 1.6, “Eliminación de un OSD”) produce un error. Por ejemplo, esto puede ocurrir si el OSD o su caché están dañados, cuando hay operaciones de E/S pendientes o si no es posible desmontar el disco del OSD. En ese caso, debe forzar la eliminación del OSD:

root@master # target osd.remove OSD_ID force=True

Este comando permite eliminar la partición de datos y el diario transaccional o las particiones WAL/DB.

Para identificar los posibles dispositivos de diario transaccional/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).

1.7 Recuperación de un nodo OSD reinstalado

Si el sistema operativo se interrumpe y no se puede recuperar en uno de los nodos OSD, lleve a cabo estos pasos para recuperarlo y volver a distribuir su función de OSD con los datos del clúster intactos:

  1. Vuelva a instalar el sistema operativo en el nodo.

  2. Instale los paquetes salt-minion en el nodo OSD, suprima la antigua clave del minion de Salt en el master de Salt y registre la nueva. Para obtener más información acerca de la distribución de minions de Salt, consulte Sección 4.3, “Distribución del clúster”.

  3. En lugar de ejecutar la etapa 0 completa, ejecute los siguientes elementos:

    root@master # salt 'osd_node' state.apply ceph.sync
    root@master # salt 'osd_node' state.apply ceph.packages.common
    root@master # salt 'osd_node' state.apply ceph.mines
    root@master # salt 'osd_node' state.apply ceph.updates
  4. Ejecute las etapas 1 a 5 de DeepSea:

    root@master # salt-run state.orch ceph.stage.1
    root@master # salt-run state.orch ceph.stage.2
    root@master # salt-run state.orch ceph.stage.3
    root@master # salt-run state.orch ceph.stage.4
    root@master # salt-run state.orch ceph.stage.5
  5. Ejecute la etapa 0 de DeepSea:

    root@master # salt-run state.orch ceph.stage.0
  6. Reinicie el nodo OSD relevante. Todos los discos del OSD se redescubrirán y se reutilizarán.

1.8 Instalación automatizada mediante Salt

La instalación se puede automatizar mediante el reactor de Salt. En entornos virtuales o entornos de hardware coherentes, esta configuración permitirá la creación de un clúster de Ceph con el comportamiento especificado.

Aviso
Aviso

Salt no puede realizar comprobaciones de dependencias basadas en eventos del reactor. Existe un riesgo real de introducir al master Salt en una espiral potencialmente letal.

La instalación automatizada requiere lo siguiente:

  • Un archivo /srv/pillar/ceph/proposals/policy.cfg creado correctamente.

  • Una configuración personalizada preparada situada en el directorio /srv/pillar/ceph/stack.

La configuración por defecto del reactor solo ejecutará las etapas 0 y 1. Esto permite probar el reactor sin esperar a que se completen las etapas siguientes.

Cuando se inicie el primer salt-minion, comenzará la etapa 0. Un bloqueo impide que existan varias instancias. Cuando todos los minions completen la etapa 0, empezará la etapa 1.

Si la operación se lleva a cabo correctamente, cambie la última línea en el archivo /etc/salt/master.d/reactor.conf:

- /srv/salt/ceph/reactor/discovery.sls

por

- /srv/salt/ceph/reactor/all_stages.sls

1.9 Actualización de los nodos del clúster

Es recomendable aplicar las actualizaciones periódicas a los nodos del clúster regularmente. Para aplicar las actualizaciones, ejecute la etapa 0:

root@master # salt-run state.orch ceph.stage.0

Si DeepSea detecta un clúster de Ceph en ejecución, aplicará las actualizaciones y reiniciará los nodos secuencialmente. DeepSea sigue la recomendación oficial de Ceph de actualizar primero los monitores, luego los OSD y, por último, los servicios adicionales, como MDS, Object Gateway, iSCSI Gateway o NFS Ganesha. Si DeepSea detecta algún problema en el clúster, detendrá el proceso de actualización. Un activador potencial puede ser el siguiente:

  • Ceph informa del error "HEALTH_ERR" durante más de 300 segundos.

  • Se envía una consulta a los minions de Salt para que sus servicios asignados sigan ejecutándose después de una actualización. La actualización falla si los servicios están inactivos durante más de 900 segundos.

Esta configuración permite que incluso en caso de que haya actualizaciones fallidas o dañadas, el clúster de Ceph permanezca operativo.

La etapa 0 de DeepSea actualiza el sistema mediante zypper update y vuelve a arrancar el sistema si se actualiza el kernel. Si desea eliminar la posibilidad de un posible reinicio forzoso de todos los nodos, asegúrese de que el kernel más reciente esté instalado y en ejecución antes de iniciar la etapa 0 de DeepSea.

Sugerencia
Sugerencia: zypper patch

Si prefiere actualizar el sistema mediante el comando zypper patch, edite /srv/pillar/ceph/stack/global.yml y añada la siguiente línea:

update_method_init: zypper-patch

Puede cambiar el comportamiento de reinicio predeterminado de la etapa 0 de DeepSea añadiendo las siguientes líneas al archivo /srv/pillar/ceph/stack/global.yml:

stage_prep_master: default-update-no-reboot
stage_prep_minion: default-update-no-reboot

stage_prep_master define el comportamiento de la etapa 0 del master Salt y stage_prep_minion define el comportamiento de todos los minions. Los parámetros disponibles son los siguientes:

default

Instalar las actualizaciones y reiniciar después de la actualización.

default-update-no-reboot

Instalar las actualizaciones sin reiniciar.

default-no-update-reboot

Reiniciar sin instalar las actualizaciones.

default-no-update-no-reboot

No instalar las actualizaciones ni reiniciar.

1.10 Detención o reinicio del clúster

En algunos casos, puede ser necesario detener o reiniciar el clúster completo. Recomendamos comprobar atentamente las dependencias de los servicios en ejecución. Los siguientes pasos se pueden usar como esquema de inicio y detención del clúster:

  1. Indique al clúster de Ceph que no marque los OSD como "out":

    root # ceph osd set noout
  2. Detenga los daemons y los nodos en el siguiente orden:

    1. Clientes de almacenamiento

    2. Gateways, por ejemplo, NFS Ganesha u Object Gateway

    3. Servidor de metadatos

    4. Ceph OSD

    5. Ceph Manager

    6. Ceph Monitor

  3. Si es necesario, realice las tareas de mantenimiento.

  4. Inicie los nodos y los servidores en el orden inverso al del proceso de apagado:

    1. Ceph Monitor

    2. Ceph Manager

    3. Ceph OSD

    4. Servidor de metadatos

    5. Gateways, por ejemplo, NFS Ganesha u Object Gateway

    6. Clientes de almacenamiento

  5. Elimine el indicador de noout:

    root # ceph osd unset noout

1.11 Archivo ceph.conf personalizado

Si es necesario añadir una configuración personalizada al archivo ceph.conf, puede hacerlo modificando los archivos de configuración del directorio /srv/salt/ceph/configuration/files/ceph.conf.d:

  • global.conf

  • mon.conf

  • mgr.conf

  • mds.conf

  • osd.conf

  • client.conf

  • rgw.conf

Nota
Nota: archivo rgw.conf único

Object Gateway ofrece mucha flexibilidad y es único en comparación con el resto de secciones de ceph.conf. Todos los demás componentes de Ceph tienen encabezados estáticos, como [mon] u [osd]. El Object Gateway tiene encabezados únicos, como [client.rgw.rgw1]. Esto significa que el archivo rgw.conf necesita una entrada de encabezado. Consulte /srv/salt/ceph/configuration/files/rgw.conf para ver un ejemplo.

Importante
Importante: ejecute la etapa 3

Después de hacer cambios personalizados en los archivos de configuración mencionados, ejecute la etapa 3 para aplicar dichos cambios a los nodos del clúster:

root@master # salt-run state.orch ceph.stage.3

Estos archivos se incluyen desde el archivo de plantilla /srv/salt/ceph/configuration/files/ceph.conf.j2 y se corresponden con las diferentes secciones que acepta el archivo de configuración de Ceph. Un fragmento de configuración en el archivo correcto permite que DeepSea lo coloque en la sección adecuada. No es necesario que añada ninguno de los encabezados de sección.

Sugerencia
Sugerencia

Para aplicar las opciones de configuración solo a instancias específicas de un daemon, añada un encabezado como [osd.1]. Las siguientes opciones de configuración solo se aplicarán al daemon OSD con el ID 1.

1.11.1 Sustitución de los valores por defecto

Las declaraciones posteriores de una sección sustituyen a las anteriores. Por lo tanto, es posible anular la configuración por defecto especificada en la plantilla /srv/salt/ceph/configuration/files/ceph.conf.j2. Por ejemplo, para desactivar la autenticación de cephx, añade las tres líneas siguientes al archivo /srv/salt/ceph/configuration/files/ceph.conf.d/global.conf:

auth cluster required = none
auth service required = none
auth client required = none

1.11.2 Inclusión de los archivos de configuración

Si necesita aplicar muchas configuraciones personalizadas, utilice las siguientes declaraciones include dentro de los archivos de configuración personalizados para facilitar la gestión de archivos. A continuación encontrará un ejemplo del archivo osd.conf:

[osd.1]
{% include "ceph/configuration/files/ceph.conf.d/osd1.conf" ignore missing %}
[osd.2]
{% include "ceph/configuration/files/ceph.conf.d/osd2.conf" ignore missing %}
[osd.3]
{% include "ceph/configuration/files/ceph.conf.d/osd3.conf" ignore missing %}
[osd.4]
{% include "ceph/configuration/files/ceph.conf.d/osd4.conf" ignore missing %}

En el ejemplo anterior, los archivos osd1.conf, osd2.conf, osd3.conf y osd4.conf contienen las opciones de configuración específicas del OSD relacionado.

Sugerencia
Sugerencia: configuración de tiempo de ejecución

Los cambios realizados en los archivos de configuración de Ceph surten efecto después de reiniciar los daemons de Ceph relacionados. Consulte la Sección 1.12, “Configuración del tiempo de ejecución de Ceph” para obtener más información sobre cómo cambiar la configuración del tiempo de ejecución de Ceph.

1.12 Configuración del tiempo de ejecución de Ceph

En la Sección 1.11, “Archivo ceph.conf personalizado” se describe cómo hacer cambios en el archivo de configuración de Ceph ceph.conf. Sin embargo, el comportamiento real del clúster no está determinado por el estado actual del archivo ceph.conf, sino por la configuración de los daemons de Ceph en ejecución, que se almacena en la memoria.

Puede consultar a un daemon individual de Ceph un valor de configuración en concreto a través del zócalo de administración en el nodo en el que se esté ejecutando el daemon. Por ejemplo, el siguiente comando obtiene el valor del parámetro de configuración osd_max_write_size para el daemon denominado osd.0:

root # ceph --admin-daemon /var/run/ceph/ceph-osd.0.asok \
config get osd_max_write_size
{
  "osd_max_write_size": "90"
}

También puede cambiar la configuración de los daemons durante el tiempo de ejecución. Recuerde que este cambio es temporal y se perderá después del siguiente reinicio del daemon. Por ejemplo, el siguiente comando cambia el parámetro osd_max_write_size a "50" para todos los OSD del clúster:

root # ceph tell osd.* injectargs --osd_max_write_size 50
Aviso
Aviso: injectargs no es fiable

Lamentablemente, cambiar la configuración del clúster mediante el comando injectargs no es un proceso fiable al 100 %. Si necesita estar seguro de que el parámetro modificado está activo, cámbielo en el archivo de configuración y reinicie todos los daemons del clúster.

Imprimir esta página