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

2 Administración de un clúster de Salt Edit source

Después de distribuir un 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.

2.1 Adición de nuevos nodos de clúster Edit source

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 5, Distribución con DeepSea/Salt:

Sugerencia
Sugerencia: evitar el reequilibrio

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, añada al mismo tiempo todos los OSD que tenga previstos.

Otro método consiste en definir la opción osd crush initial weight = 0 en el archivo ceph.conf antes de añadir los OSD:

  1. Añada osd crush initial weight = 0 a /srv/salt/ceph/configuration/files/ceph.conf.d/global.conf.

  2. Cree la nueva configuración en el nodo master de Salt:

    root@master # salt 'SALT_MASTER_NODE' state.apply ceph.configuration.create
  3. Aplique la nueva configuración a los minions OSD de destino:

    root@master # salt 'OSD_MINIONS' state.apply ceph.configuration
  4. Después de que se hayan añadido los nuevos OSD, ajuste sus pesos según sea necesario con el comando ceph osd crush reweight.

  1. Instale SUSE Linux Enterprise Server 15 SP1 en el nuevo nodo y configure la red de modo que resuelva correctamente el nombre del master de Salt correctamente: Verifique que tiene una conexión adecuada con las redes públicas y de clúster y que la sincronización de hora está configurada correctamente. A continuación, 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. En el master de Salt, acepte la clave de Salt del nuevo nodo:

    root@master # salt-key --accept NEW_NODE_KEY
  3. Verifique que el destino de /srv/pillar/ceph/deepsea_minions.sls se asigna al nuevo minion de Salt o defina el grain de DeepSea adecuado. Consulte Sección 5.2.2.1, “Coincidencia del nombre del minion” o Procedimiento 5.1, “Ejecución de fases de distribución” para obtener más información.

  4. Ejecute la fase 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
    Importante
    Importante: posible reinicio de la fase 0 de DeepSea

    Si el master de Salt se reinicia después de su actualización del kernel, debe reiniciar la fase 0 de DeepSea.

  5. Ejecute la fase 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 5.5.1, “El archivo policy.cfg.

  7. Ejecute la fase 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
    Sugerencia
    Sugerencia: modificación del diseño del OSD

    Si desea modificar el diseño por defecto del OSD y cambiar la configuración de DriveGroups, siga el procedimiento descrito en la Sección 5.5.2, “DriveGroups”.

  8. Las fases 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

2.2 Adición de nuevas funciones a los nodos Edit source

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

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 5.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 fase 2 para actualizar el pilar:

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

2.3 Eliminación y reinstalación de nodos del clúster Edit source

Sugerencia
Sugerencia: eliminación temporal de un nodo de clúster

El master de Salt espera que todos los minions estén presentes en el clúster y respondan. Si un minion deja de funcionar y no responde, se producen problemas en la infraestructura de Salt, principalmente en DeepSea y Ceph Dashboard.

Antes de reparar el minion, suprima su clave temporalmente del master de Salt:

root@master # salt-key -d MINION_HOST_NAME

Después de reparar el minion, vuelva a añadir su clave al master de Salt:

root@master # salt-key -a MINION_HOST_NAME

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 fases 2 y 5, tal como se describe en Sección 5.3, “Distribución del clúster”.

Nota
Nota: eliminación de OSDs del 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.

Antes de ejecutar la fase 5 para llevar a cabo la eliminación en sí, compruebe siempre qué OSD va a eliminar DeepSea:

root@master # salt-run rescinded.ids

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 reclamar estas unidades manualmente.

Ejemplo 2.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
role-storage/cluster/data*.sls
[...]

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

[...]
# Hardware Profile
role-storage/cluster/data[1,3-6]*.sls
[...]

Tenga también en cuenta que debe adaptar su archivo drive_groups.yml para que coincida con los nuevos destinos.

    [...]
    drive_group_name:
      target: 'data[1,3-6]*'
    [...]

A continuación, ejecute la fase 2, compruebe qué OSD se van a quitar y, para terminar, ejecute la fase 5:

root@master # salt-run state.orch ceph.stage.2
root@master # salt-run rescinded.ids
root@master # salt-run state.orch ceph.stage.5
Ejemplo 2.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 fases 0 y 1 (consulte Procedimiento 5.1, “Ejecución de fases de distribución”) en el nuevo hardware, de a la pasarela nueva el nombre rgw1. 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
role-storage/cluster/data[1-7]*.sls

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

Cámbielo a:

# Hardware Profile
role-storage/cluster/data[1-8]*.sls

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

Ejecute las fases 2 a 4, compruebe qué OSD se van a quitar posiblemente y, para terminar, ejecute la fase 5. En la fase 3, se Si en el disco que se está eliminando sigue montada una partición, añadirá data8 como nodo de almacenamiento. Durante un momento, data8 tendrá ambas funciones. En la fase 4, se añadirá la función de Object Gateway a rgw1. En la fase 5, se eliminará la función de Object Gateway de data8:

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 rescinded.ids
root@master # salt-run state.orch ceph.stage.5

2.4 Redistribución de nodos de Monitor Edit source

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 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 2.1, “Adición de nuevos nodos de clúster” y la Sección 2.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 2.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 5.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. Por ejemplo:

    [...]
    # MON
    #role-mon/cluster/ses-example-failed1.sls
    #role-mon/cluster/ses-example-failed2.sls
    role-mon/cluster/ses-example-new1.sls
    role-mon/cluster/ses-example-new2.sls
    [...]
  2. Ejecute las fases 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

2.5 Adición de un disco OSD a un nodo Edit source

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 12 de Sección 5.3, “Distribución del clúster” para obtener más información. Adapte /srv/salt/ceph/configuration/files/drive_groups.yml en consecuencia (consulte Sección 5.5.2, “DriveGroups” para obtener más información). Después de guardar el archivo, ejecute la fase 3 de DeepSea:

root@master # deepsea stage run ceph.stage.3

2.6 Eliminación de un OSD Edit source

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

root@master # salt-run osd.remove OSD_ID

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

2.6.1 Eliminación de varios OSD Edit source

Utilice el mismo procedimiento que se explicó en la Sección 2.6, “Eliminación de un OSD”, pero proporcione varios ID de OSD:

root@master # salt-run osd.remove 2 6 11 15
Removing osd 2 on host data1
Draining the OSD
Waiting for ceph to catch up.
osd.2 is safe to destroy
Purging from the crushmap
Zapping the device


Removing osd 6 on host data1
Draining the OSD
Waiting for ceph to catch up.
osd.6 is safe to destroy
Purging from the crushmap
Zapping the device


Removing osd 11 on host data1
Draining the OSD
Waiting for ceph to catch up.
osd.11 is safe to destroy
Purging from the crushmap
Zapping the device


Removing osd 15 on host data1
Draining the OSD
Waiting for ceph to catch up.
osd.15 is safe to destroy
Purging from the crushmap
Zapping the device


2:
True
6:
True
11:
True
15:
True

2.6.2 Eliminación de todos los OSD de un host Edit source

Para eliminar todos los OSD de un host específico, ejecute el comando siguiente:

root@master # salt-run osd.remove OSD_HOST_NAME

2.6.3 Eliminación forzosa de OSD dañados Edit source

Existen casos en que el procedimiento de eliminación ordenada de un OSD (consulte la Sección 2.6, “Eliminación de un OSD”) produce un error. Por ejemplo, esto puede ocurrir si el OSD o su diario, WAL o DB están dañados, cuando hay operaciones de E/S pendientes o si no es posible desmontar el disco del OSD.

root@master # salt-run osd.remove OSD_ID force=True
Sugerencia
Sugerencia: montajes pendientes

Si en el disco que se está eliminando sigue montada una partición, el comando fallará y se mostrará un mensaje de tipo: "Error al desmontar: compruebe los procesos de DISPOSITIVO". Puede mostrar todos los procesos que acceden al sistema de archivos con el comando fuser -m DISPOSITIVO. Si el comando fuser no devuelve nada, pruebe con a introducir manualmente unmount DISPOSITIVO y consulte el resultado de los comandos dmesg o journalctl.

2.6.4 Validación de metadatos de los LVM del OSD Edit source

Después de eliminar un OSD con el comando salt-run osd.remove ID o mediante otros comandos de Ceph, es posible que los metadatos de los LVM no se eliminen por completo. Eso significa que si desea volver a distribuir un nuevo OSD, se usarían metadatos de los LVM antiguos.

  1. En primer lugar, compruebe si se ha eliminado el OSD:

    cephadm@osd > ceph-volume lvm list

    Incluso si uno de los OSD se ha eliminado correctamente, puede que siga apareciendo en la lista. Por ejemplo, si elimina osd.2, el resultado sería el siguiente:

      ====== osd.2 =======
    
      [block] /dev/ceph-a2189611-4380-46f7-b9a2-8b0080a1f9fd/osd-data-ddc508bc-6cee-4890-9a42-250e30a72380
    
      block device /dev/ceph-a2189611-4380-46f7-b9a2-8b0080a1f9fd/osd-data-ddc508bc-6cee-4890-9a42-250e30a72380
      block uuid kH9aNy-vnCT-ExmQ-cAsI-H7Gw-LupE-cvSJO9
      cephx lockbox secret
      cluster fsid 6b6bbac4-eb11-45cc-b325-637e3ff9fa0c
      cluster name ceph
      crush device class None
      encrypted 0
      osd fsid aac51485-131c-442b-a243-47c9186067db
      osd id 2
      type block
      vdo 0
      devices /dev/sda

    En este ejemplo, puede ver que osd.2 sigue en /dev/sda.

  2. Valide los metadatos de los LVM en el nodo OSD:

    cephadm@osd > ceph-volume inventory

    El resultado de ejecutar el comando ceph-volume inventory indica que el valor de disponibilidad de dev/sda es False (Falso). Por ejemplo:

      Device Path Size rotates available Model name
      /dev/sda 40.00 GB True False QEMU HARDDISK
      /dev/sdb 40.00 GB True False QEMU HARDDISK
      /dev/sdc 40.00 GB True False QEMU HARDDISK
      /dev/sdd 40.00 GB True False QEMU HARDDISK
      /dev/sde 40.00 GB True False QEMU HARDDISK
      /dev/sdf 40.00 GB True False QEMU HARDDISK
      /dev/vda 25.00 GB True False
  3. Ejecute el comando siguiente en el nodo OSD para eliminar por completo los metadatos de los LVM:

    cephadm@osd > ceph-volume lvm zap --osd-id ID --destroy
  4. Ejecute el comando inventory de nuevo para verificar que la disponibilidad de /dev/sda vuelve a ser True (Verdadero). Por ejemplo:

    cephadm@osd > ceph-volume inventory
    Device Path Size rotates available Model name
    /dev/sda 40.00 GB True True QEMU HARDDISK
    /dev/sdb 40.00 GB True False QEMU HARDDISK
    /dev/sdc 40.00 GB True False QEMU HARDDISK
    /dev/sdd 40.00 GB True False QEMU HARDDISK
    /dev/sde 40.00 GB True False QEMU HARDDISK
    /dev/sdf 40.00 GB True False QEMU HARDDISK
    /dev/vda 25.00 GB True False

    Los metadatos de los LVM ya se han eliminado. Ahora es seguro usar el comando dd en el dispositivo.

  5. El OSD se puede volver a distribuir sin necesidad de reiniciar el nodo OSD:

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

2.7 Sustitución de un disco OSD Edit source

Puede haber varios motivos para que sea necesario reemplazar un disco OSD, por ejemplo:

  • El disco OSD ha fallado o va a fallar pronto, según la información de SMART, y ya no se puede utilizar para almacenar datos de forma segura.

  • Debe actualizar el disco OSD; por ejemplo, para aumentar su tamaño.

El procedimiento de sustitución es el mismo en ambos casos. También es válido para los mapas de CRUSH personalizados y por defecto.

  1. Supongamos que el ID del OSD cuyo disco debe sustituirse es "5". El comando siguiente lo marca con el estado destroyed en el mapa de CRUSH, pero deja su ID original:

    root@master # salt-run osd.replace 5
    Sugerencia
    Sugerencia: osd.replace y osd.remove

    Los comandos osd.replace y osd.remove de Salt (consulte la Sección 2.6, “Eliminación de un OSD”) son idénticos, excepto en que osd.replace deja el OSD con el estado "destroyed" en el mapa de CRUSH, mientras que osd.remove elimina toda traza del OSD del mapa de CRUSH.

  2. Sustituya manualmente la unidad OSD con errores o actualizada.

  3. Si desea modificar el diseño por defecto del OSD y cambiar la configuración de los grupos de unidades, siga el procedimiento descrito en Sección 5.5.2, “DriveGroups”.

  4. Ejecute la fase 3, distribución, para distribuir el disco OSD sustituido:

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

2.8 Recuperación de un nodo OSD reinstalado Edit source

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 base SUSE Linux Enterprise en el nodo donde el sistema operativo ha dejado de funcionar. Instale los paquetes salt-minion en el nodo OSD, suprima la antigua clave del minion de Salt del master de Salt y registre la nueva. Para obtener más información sobre la distribución inicial, consulte Sección 5.3, “Distribución del clúster”.

  2. En lugar de ejecutar la fase 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
  3. Ejecute las fases 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
  4. Ejecute la fase 0 de DeepSea:

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

  6. Instale o ejecute el exportador del nodo de Prometheus:

    root@master # salt 'RECOVERED_MINION' \
     state.apply ceph.monitoring.prometheus.exporters.node_exporter
  7. Actualice los grains de Salt:

    root@master # salt 'RECOVERED_MINION' osd.retain

2.9 Traslado del nodo de administración a un nuevo servidor Edit source

Si necesita sustituir el host del nodo de administración por uno nuevo, debe mover el master de Salt y los archivos de DeepSea. Utilice su herramienta de sincronización favorita para transferir los archivos. En este procedimiento, se usa rsync porque es una herramienta estándar disponible en los repositorios de software de SUSE Linux Enterprise Server 15 SP1.

  1. Detenga los servicios salt-master y salt-minion en el nodo de administración antiguo:

    root@master # systemctl stop salt-master.service
    root@master # systemctl stop salt-minion.service
  2. Configure Salt en el nodo de administración nuevo para que el master y los minions de Salt se comuniquen. Más detalles en Sección 5.3, “Distribución del clúster”

    Sugerencia
    Sugerencia: transición de los minions de Salt

    Para facilitar la transición de los minions de Salt al nuevo nodo de administración, elimine la clave pública del master de Salt original de cada minion:

    root@minion > rm /etc/salt/pki/minion/minion_master.pub
    root@minion > systemctl restart salt-minion.service
  3. Verifique que el paquete deepsea esté instalado, e instálelo si fuera necesario.

    root@master # zypper install deepsea
  4. Personalice el archivo policy.cfg cambiando la línea role-master. Encontrará más detalles en Sección 5.5.1, “El archivo policy.cfg

  5. Sincronice los directorios /srv/pillar y /srv/salt del antiguo nodo de administración al nuevo.

    Sugerencia
    Sugerencia: ejecución de simulación de rsync y enlaces simbólicos

    Si es posible, intente sincronizar primero los archivos en una ejecución de simulación para ver qué archivos se transferirán (opción -n de rsync). Incluya también enlaces simbólicos (opción -a de rsync). Para rsync, el comando de sincronización tendrá el siguiente aspecto:

    root@master # rsync -avn /srv/pillar/ NEW-ADMIN-HOSTNAME:/srv/pillar
  6. Si ha realizado cambios personalizados en archivos fuera de /srv/pillar y /srv/salt, por ejemplo en /etc/salt/master o /etc/salt/master.d, sincronícelos también.

  7. Ahora puede ejecutar fases de DeepSea desde el nuevo nodo de administración. Consulte Sección 5.2, “Introducción a DeepSea” para obtener su descripción detallada.

2.10 Instalación automatizada mediante Salt Edit source

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 fases 0 y 1. Esto permite probar el reactor sin esperar a que se completen las fases siguientes.

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

Si la operación se realiza correctamente, edite el archivo

/etc/salt/master.d/reactor.conf

y sustituya la línea siguiente

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

por

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

Verifique que la línea no está comentada.

2.11 Actualización de los nodos del clúster Edit source

Para mantener actualizados los nodos del clúster de Ceph, aplique actualizaciones periódicas.

2.11.1 Repositorios de software Edit source

Antes de aplicar al clúster los paquetes de software más recientes como parches, compruebe que todos los nodos del clúster tienen acceso a los repositorios relevantes. Consulte Sección 6.8.1, “Actualización manual de nodo mediante el DVD del instalador” para obtener una lista completa de los repositorios necesarios.

2.11.2 Fases del repositorio Edit source

Si utiliza una herramienta de fases (por ejemplo, SUSE Manager, la Herramienta de gestión de suscripciones o la Herramienta de duplicación de repositorios) que provea repositorios de software a los nodos del clúster, verifique que las fases de los repositorios "de actualizaciones" de SUSE Linux Enterprise Server y SUSE Enterprise Storage se crean en el mismo momento.

Se recomienda encarecidamente utilizar una herramienta de fases para aplicar parches con niveles de parches inmovilizados/preconfigurados. Esto garantiza que los nuevos nodos que se unen al clúster tengan el mismo nivel de parche que los nodos que ya se ejecutan en el clúster. De ese modo, no será necesario aplicar los parches más recientes a todos los nodos del clúster antes de que los nuevos nodos se puedan unir al clúster.

2.11.3 zypper patch o zypper dup Edit source

Por defecto, los nodos del clúster se actualizan mediante el comando zypper dup. Si prefiere actualizar el sistema mediante zypper patch, edite /srv/pillar/ceph/stack/global.yml y añada la siguiente línea:

update_method_init: zypper-patch

2.11.4 Reinicios del nodo de clúster Edit source

Durante la actualización, los nodos del clúster pueden reiniciarse opcionalmente si su kernel se ha actualizado. Si desea eliminar la posibilidad de que se produzca un reinicio impuesto de todos los nodos, verifique que el kernel más reciente está instalado y en ejecución en los nodos de Ceph, o bien inhabilite los reinicios automáticos de nodos como se describe en Sección 7.1.5, “Actualizaciones y reinicios durante la fase 0”.

2.11.5 Tiempo de inactividad de servicios de Ceph Edit source

Dependiendo de la configuración, los nodos del clúster podrían reiniciarse durante la actualización, como se describe en la Sección 2.11.4, “Reinicios del nodo de clúster”. Si hay un punto único de error para servicios como Object Gateway, Samba Gateway, NFS Ganesha o iSCSI, los equipos cliente podrían desconectarse temporalmente de los servicios cuyos nodos se van a reiniciar.

2.11.6 Ejecución de la actualización Edit source

Para actualizar los paquetes de software de todos los nodos del clúster a la versión más reciente, siga estos pasos:

  1. Actualice los paquetes deepsea, salt-mastery salt-minion y reinicie los servicios relevantes en el master de Salt:

    root@master # salt -I 'roles:master' state.apply ceph.updates.master
  2. Actualice y reinicie el paquete salt-minion en todos los nodos del clúster:

    root@master # salt -I 'cluster:ceph' state.apply ceph.updates.salt
  3. Actualice todos los demás paquetes de software del clúster:

    root@master # salt-run state.orch ceph.maintenance.upgrade

2.12 Detención o reinicio del clúster Edit source

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

    cephadm@adm > 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:

    cephadm@adm > ceph osd unset noout

2.13 Ajuste de ceph.conf con valores personalizados Edit source

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. Para obtener ejemplos, consulte:

/srv/salt/ceph/configuration/files/rgw.conf

o

/srv/salt/ceph/configuration/files/rgw-ssl.conf
Importante
Importante: ejecución de la fase 3

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

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

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.

2.13.1 Sustitución de los valores por defecto Edit source

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

Al redefinir los valores por defecto, las herramientas relacionadas con Ceph, como rados, pueden emitir advertencias de que los valores específicos de ceph.conf.j2 se han redefinido en global.conf. Estas advertencias son causadas por un parámetro asignado dos veces en el archivo ceph.conf resultante.

Como solución alternativa para este caso específico, siga estos pasos:

  1. Cambie el directorio actual a /srv/salt/ceph/configuration/create:

    root@master # cd /srv/salt/ceph/configuration/create
  2. Copie default.sls en custom.sls:

    root@master # cp default.sls custom.sls
  3. Edite custom.sls y cambie ceph.conf.j2 a custom-ceph.conf.j2.

  4. Cambie el directorio actual a /srv/salt/ceph/configuration/files:

    root@master # cd /srv/salt/ceph/configuration/files
  5. Copie ceph.conf.j2 en custom-ceph.conf.j2:

    root@master # cp ceph.conf.j2 custom-ceph.conf.j2
  6. Edite custom-ceph.conf.j2 y suprima la línea siguiente:

    {% include "ceph/configuration/files/rbd.conf" %}

    Edite global.yml y añada la línea siguiente:

    configuration_create: custom
  7. Actualice el pilar:

    root@master # salt target saltutil.pillar_refresh
  8. Ejecute la fase 3:

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

Ahora solo debe tener una entrada para cada definición de valor. Para volver a crear la configuración, ejecute:

root@master # salt-run state.orch ceph.configuration.create

A continuación, verifique el contenido de /srv/salt/ceph/configuration/cache/ceph.conf.

2.13.2 Inclusión de los archivos de configuración Edit source

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 16.1, “Configuración de tiempo de ejecución” para obtener más información sobre cómo cambiar la configuración del tiempo de ejecución de Ceph.

2.14 Habilitación de perfiles de AppArmor Edit source

AppArmor es una solución de seguridad que confina los programas según un perfil específico. Para obtener más información, consulte https://www.suse.com/documentation/sles-15/book_security/data/part_apparmor.html.

DeepSea proporciona tres estados para los perfiles de AppArmor: "enforce", "complain" y "disable". Para activar un estado de AppArmor determinado, ejecute:

salt -I "deepsea_minions:*" state.apply ceph.apparmor.default-STATE

Para poner los perfiles de AppArmor en el estado "enforce":

root@master # salt -I "deepsea_minions:*" state.apply ceph.apparmor.default-enforce

Para poner los perfiles de AppArmor en el estado "complain":

root@master # salt -I "deepsea_minions:*" state.apply ceph.apparmor.default-complain

Para inhabilitar los perfiles de AppArmor:

root@master # salt -I "deepsea_minions:*" state.apply ceph.apparmor.default-disable
Sugerencia
Sugerencia: habilitación del servicio de AppArmor

Cada una de estas tres llamadas verifica si AppArmor está instalado y, si no lo está, lo instala. También inicia y habilita el servicio systemd relacionado. DeepSea le avisará si AppArmor se ha instalado e iniciado/habilitado de otra manera y, por lo tanto, se ejecuta sin perfiles de DeepSea.

2.15 Desactivación de perfiles ajustados Edit source

Por defecto, DeepSea distribuye clústeres de Ceph con perfiles ajustados activos en nodos de Ceph Monitor, Ceph Manager y Ceph OSD. En algunos casos, puede ser necesario desactivar de forma permanente los perfiles ajustados. Para ello, coloque las líneas siguientes en /srv/pillar/ceph/stack/global.yml y ejecute de nuevo la fase 3:

alternative_defaults:
 tuned_mgr_init: default-off
 tuned_mon_init: default-off
 tuned_osd_init: default-off
root@master # salt-run state.orch ceph.stage.3

2.16 Eliminación de un clúster de Ceph completo Edit source

El runner ceph.purge elimina todo el clúster de Ceph. De esta manera, puede limpiar el entorno del clúster cuando pruebe diferentes configuraciones. Una vez completado el runner ceph.purge, el clúster de Salt se revierte al estado que tenía al final de la fase 1 de DeepSea. A continuación, puede cambiar policy.cfg (consulte Sección 5.5.1, “El archivo policy.cfg), o pasar a la fase 2 de DeepSea con la misma configuración.

Para evitar la supresión accidental, la orquestación comprueba si la seguridad está desactivada. Puede desactivar las medidas de seguridad y eliminar el clúster de Ceph ejecutando:

root@master # salt-run disengage.safety
root@master # salt-run state.orch ceph.purge
Sugerencia
Sugerencia: cómo inhabilitar la eliminación del clúster de Ceph

Si desea evitar que alguien ejecute el runner ceph.purge, cree un archivo denominado disabled.sls en el directorio /srv/salt/ceph/purge e inserte la siguiente línea en el archivo /srv/pillar/ceph/stack/global.yml:

purge_init: disabled
Importante
Importante: rescisión de funciones personalizadas

Si ha creado previamente funciones personalizadas para Ceph Dashboard (consulte la Sección 22.2.6, “Adición de funciones personalizadas” y la Sección 22.10.2, “Funciones y permisos de usuario” para obtener información detallada), debe realizar pasos manuales para borrarlas antes de ejecutar el runner ceph.purge. Por ejemplo, si la función personalizado para Object Gateway se denomina "us-east-1", siga estos pasos:

root@master # cd /srv/salt/ceph/rescind
root@master # rsync -a rgw/ us-east-1
root@master # sed -i 's!rgw!us-east-1!' us-east-1/*.sls