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 6

5 Distribución con DeepSea/Salt Edit source

La combinación de Salt y DeepSea es una pila de componentes que ayudan a distribuir y gestionar la infraestructura de servidor. Tiene mucha capacidad de ampliación, es rápida y es relativamente fácil de poner en ejecución. Lea las consideraciones siguientes antes de empezar a distribuir el clúster con Salt:

  • Los minions de Salt son los nodos que se controlan mediante un nodo dedicado denominado master de Salt. Los minions de Salt tienen funciones, por ejemplo Ceph OSD, Ceph Monitor, Ceph Manager, Object Gateway, iSCSI Gateway o NFS Ganesha.

  • Un master de Salt ejecuta su propio minion de Salt. Esto es necesario para ejecutar tareas con privilegios, como la creación, autorización y copia de claves en minions, de forma que los minions remotos nunca tengan que ejecutar tareas con privilegios.

    Sugerencia
    Sugerencia: uso compartido de varias funciones por servidor

    Conseguirá el mejor rendimiento del clúster de Ceph si cada función se distribuye en un nodo independiente. Pero las distribuciones reales requieren en ocasiones que se comparta un nodo para varias funciones. Para evitar problemas de rendimiento y en el procedimiento de actualización, no distribuya las funciones de Ceph OSD, el servidor de metadatos ni Ceph Monitor al nodo de administración.

  • Los minions de Salt deben resolver correctamente el nombre de host del master de Salt en la red. Por defecto, buscan el nombre de host salt, pero puede especificar cualquier otro nombre de host al que se pueda acceder por la red en el archivo /etc/salt/minion, consulte la Sección 5.3, “Distribución del clúster”.

5.1 Lectura de las notas de la versión Edit source

En las notas de la versión puede encontrar información adicional sobre los cambios realizados desde la versión previa de SUSE Enterprise Storage. Consulte las notas de versión para comprobar lo siguiente:

  • si el hardware necesita consideraciones especiales,

  • si los paquetes de software usados han cambiado de forma significativa,

  • si es necesario tomar precauciones especiales para la instalación.

Las notas de la versión también proporcionan información que no pudo publicarse en el manual a tiempo y notas acerca de problemas conocidos.

Después de instalar el paquete release-notes-ses, encontrará las notas de la versión en el directorio /usr/share/doc/release-notes o en línea en https://www.suse.com/releasenotes/.

5.2 Introducción a DeepSea Edit source

El objetivo de DeepSea es ahorrar tiempo al administrador y llevar a cabo operaciones complejas en un clúster de Ceph con toda confianza.

Ceph es una solución de software muy configurable. Aumenta tanto la libertad como la responsabilidad de los administradores del sistema.

La configuración mínima de Ceph es adecuada con propósitos de demostración, pero no muestra las funciones más útiles de Ceph que se pueden disfrutar si hay un gran número de nodos.

DeepSea recopila y almacena datos acerca de servidores individuales, como las direcciones y los nombres de dispositivo. Para un sistema de almacenamiento distribuido como Ceph, puede haber cientos de esos elementos para recopilar y almacenar. Recopilar la información e introducir los datos manualmente en una herramienta de gestión de configuraciones es una labor tremendamente laboriosa y propensa a errores.

Los pasos necesarios para preparar los servidores, recopilar la configuración y configurar y distribuir Ceph son prácticamente los mismos. Sin embargo, eso no soluciona la gestión de funciones independientes. En las operaciones del día a día, es fundamental contar con la capacidad de añadir hardware fácilmente a una función determinada y eliminarlo sin problemas.

DeepSea resuelve este asunto con la estrategia siguiente: consolida las decisiones del administrador en un único archivo. Las decisiones incluyen la asignación del clúster, la asignación de la función y la asignación del perfil. Y DeepSea recopila cada conjunto de tareas en un único objetivo. Cada objetivo es una fase:

Descripción de las fases de DeepSea
  • Fase 0: la preparación. Durante esta fase se aplican todas las actualizaciones necesarias y puede que el sistema se rearranque.

    Importante
    Importante: nueva ejecución de la fase 0 después de reiniciar el nodo de administración

    Si durante la fase 0, el nodo de administración se reinicia para cargar la nueva versión del kernel, debe volver a ejecutar la fase 0; de lo contrario, no se asignará un destino a los minions.

  • Fase 1: el descubrimiento. Aquí se detecta todo el hardware del clúster y se recopila la información necesaria para la configuración de Ceph. Para obtener detalles sobre la configuración, consulte la Sección 5.5, “Configuración y personalización”.

  • Fase 2: la configuración. Debe preparar los datos de la configuración con un formato concreto.

  • Fase 3: la distribución. Se crea un clúster de Ceph básico con los servicios de Ceph obligatorios. Consulte una lista en la Sección 1.2.3, “Nodos y daemons de Ceph”.

  • Fase 4: los servicios. Las funciones adicionales de Ceph, como iSCSI Object Gateway y CephFS, se pueden instalar en esta fase. Todos son opcionales.

  • Fase 5: la etapa de eliminación. Esta fase no es obligatoria y durante la configuración inicial no suele ser necesaria. En esta fase, se eliminan las funciones de los minions y la configuración del clúster. Debe ejecutar esta fase si necesita eliminar un nodo de almacenamiento del clúster. Para obtener información detallada, consulte el Sección 2.3, “Eliminación y reinstalación de nodos del clúster”.

5.2.1 Organización y ubicaciones importantes Edit source

Salt tiene algunas ubicaciones estándar y varias convenciones de denominación que se emplean en el nodo máster:

/srv/pillar

En este directorio se almacenan datos de configuración para los minions del clúster. Pillar es una interfaz que proporciona valores de configuración globales para todos los minions del clúster.

/srv/salt/

En este directorio se almacenan archivos de estado de Salt (también denominados archivos sls). Los archivos de estado son descripciones con formato de los estados en los que debe estar el clúster.

/srv/module/runners

En este directorio se almacenan los guiones Python conocidos como runners. Los runners se ejecutan en el nodo master.

/srv/salt/_modules

En este directorio se almacenan los guiones Python denominados módulos. Los módulos se aplican a todos los minions del clúster.

/srv/pillar/ceph

Este directorio lo utiliza DeepSea para guardar los datos de configuración recopilados.

/srv/salt/ceph

En este directorio usado por DeepSea se almacenan archivos sls que pueden tener distintos formatos. Todos los subdirectorios contienen archivos sls, pero cada subdirectorio contiene solo un tipo de archivo sls. Por ejemplo, /srv/salt/ceph/stage contiene archivos de organización que se ejecutan mediante salt-run state.orchestrate.

5.2.2 Asignación de destino de los minions Edit source

Los comandos de DeepSea se ejecutan a través de la infraestructura de Salt. Cuando se utiliza el comando salt, es preciso especificar un conjunto de minions de Salt a los que afectará el comando. El conjunto de minions se describe como un target (destino) para el comando Salt. En las secciones siguientes se describen métodos posibles para asignar el destino de los minions.

5.2.2.1 Coincidencia del nombre del minion Edit source

Puede asignar destino para un minion o un grupo de minions haciendo coincidir sus nombres. El nombre de un minion suele ser el nombre de host corto del nodo donde se ejecuta el minion. Este método de asignación de destinos es general de Salt y no está relacionado con DeepSea. Es posible usar comodines, expresiones regulares o listas para limitar el rango de los nombres de minion. A continuación se muestra la sintaxis general:

root@master # salt target example.module
Sugerencia
Sugerencia: clúster solo de Ceph

Si todos los minions de Salt del entorno pertenecen al clúster de Ceph, puede sustituir con seguridad target por '*' para incluir todos los minions registrados.

Para obtener todos los minions del dominio example.net (suponiendo que los nombres de los minions sean idénticos a sus nombres de host "completos"):

root@master # salt '*.example.net' test.ping

Para obtener los minions entre "web1" y "web5":

root@master # salt 'web[1-5]' test.ping

Para obtener los minions "web1 prod" y "web1-devel" con una expresión regular:

root@master # salt -E 'web1-(prod|devel)' test.ping

Para obtener una lista sencilla de minions:

root@master # salt -L 'web1,web2,web3' test.ping

Para obtener todos los minions del clúster:

root@master # salt '*' test.ping

5.2.2.2 Asignación de destino con un grain DeepSea Edit source

En un entorno heterogéneo gestionado mediante Salt donde SUSE Enterprise Storage 6 se distribuya en un subconjunto de nodos junto con otras soluciones de clúster, es necesario marcar los minions relevantes aplicándoles un grain "deepsea" antes de ejecutar la fase 0 de DeepSea. De este modo, puede asignar fácilmente minions de DeepSea en entornos donde sea difícil que los nombres de los minions coincidan.

Para aplicar el grain "deepsea" a un grupo de minions, ejecute:

root@master # salt target grains.append deepsea default

Para eliminar el grain "deepsea" de un grupo de minions, ejecute:

root@master # salt target grains.delval deepsea destructive=True

Después de aplicar el grain "deepsea" a los minions relevantes, puede asignarlos como destino de la siguiente forma:

root@master # salt -G 'deepsea:*' test.ping

El comando siguiente es equivalente:

root@master # salt -C 'G@deepsea:*' test.ping

5.2.2.3 Definición de la opción deepsea_minions Edit source

En las distribuciones de DeepSea, es obligatorio definir el destino de la opción deepsea_minions. DeepSea lo usa para dar instrucciones a los minions durante la ejecución de las fases (consulte Descripción de las fases de DeepSea para obtener más información).

Para definir o cambiar la opción deepsea_minions, edite el archivo /srv/pillar/ceph/deepsea_minions.sls en el master de Salt y añada o sustituya la línea siguiente:

deepsea_minions: target
Sugerencia
Sugerencia: destino deepsea_minions

Como target (destino) para la opción deepsea_minions, puede utilizar cualquier método: tanto Coincidencia del nombre del minion como Asignación de destino con un grain DeepSea.

Para obtener todos los minions de Salt del clúster:

deepsea_minions: '*'

Para obtener todos los minions con el grain "deepsea":

deepsea_minions: 'G@deepsea:*'

5.2.2.4 Información adicional Edit source

Puede utilizar métodos más avanzados para asignar destinos a los minions con la infraestructura de Salt. La página man "deepsea minions" ofrece más detalles sobre la asignación de destinos de DeepSea (man 7 deepsea_minions).

5.3 Distribución del clúster Edit source

El proceso de distribución del clúster tiene varias fases. En primer lugar, debe preparar todos los nodos del clúster configurando Salt y, a continuación, distribuir y configurar Ceph.

Sugerencia
Sugerencia: distribución de nodos de monitor sin definir perfiles de OSD

Si necesita omitir la definición de funciones de almacenamiento para OSD, como se describe en Sección 5.5.1.2, “Asignación de funciones”, y distribuir primero los nodos de Ceph Monitor, puede hacerlo definiendo la variable DEV_ENV.

De esta forma puede distribuir monitores sin la presencia del directorio role-storage/, además de distribuir un clúster de Ceph con al menos una función de almacenamiento, monitor y gestión.

Para definir la variable de entorno, puede habilitarla globalmente definiéndola en el archivo /srv/pillar/ceph/stack/global.yml, o bien definirla solo para la sesión actual de shell:

root@master # export DEV_ENV=true

Por ejemplo, /srv/pillar/ceph/stack/global.yml se puede crear con el siguiente contenido:

DEV_ENV: True

El siguiente procedimiento describe los detalles para preparar el clúster.

  1. Instale y registre SUSE Linux Enterprise Server 15 SP1 junto con la extensión SUSE Enterprise Storage 6 en cada nodo del clúster.

  2. Verifique que los productos adecuados están instalados y registrados mostrando los repositorios de software existentes. Ejecute zypper lr -E y compare el resultado con la siguiente lista:

     SLE-Product-SLES15-SP1-Pool
     SLE-Product-SLES15-SP1-Updates
     SLE-Module-Server-Applications15-SP1-Pool
     SLE-Module-Server-Applications15-SP1-Updates
     SLE-Module-Basesystem15-SP1-Pool
     SLE-Module-Basesystem15-SP1-Updates
     SUSE-Enterprise-Storage-6-Pool
     SUSE-Enterprise-Storage-6-Updates
  3. Configure los ajustes de red, incluida la resolución de nombre DNS adecuada en cada nodo. El master de Salt y todos los minions de Salt deben resolverse entre sí mediante sus nombres de host. Para obtener más información acerca de cómo configurar una red, consulte https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_network_yast.html. Para obtener más información sobre cómo configurar un servidor DNS, consulte https://www.suse.com/documentation/sles-15/book_sle_admin/data/cha_dns.html.

  4. Seleccione uno o más servidores o repositorios de hora y sincronice la hora local con ellos. Verifique que el servicio de sincronización de hora está habilitado en cada inicio del sistema. Puede utilizar el comando yast ntp-client, que se encuentra en un paquete yast2-ntp-client para configurar la sincronización de hora.

    Sugerencia
    Sugerencia

    Las máquinas virtuales no son fuentes NTP de confianza.

    Encontrará más información sobre la configuración de NTP en https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_ntp_yast.html.

  5. Instale los paquetes salt-master y salt-minion en el nodo master de Salt:

    root@master # zypper in salt-master salt-minion

    Compruebe que el servicio salt-master esté habilitado y se haya iniciado, y si no lo estuviera, habilítelo e inícielo:

    root@master # systemctl enable salt-master.service
    root@master # systemctl start salt-master.service
  6. Si va a utilizar un cortafuegos, asegúrese de que el nodo master de Salt tiene los puertos 4505 y 4506 abiertos para todos los nodos minion de Salt. Si los puertos están cerrados, puede abrirlos con el comando yast2 firewall permitiendo el servicio SaltStack.

    Aviso
    Aviso: las fases de DeepSea fallan con un 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 firewalld.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
  7. Instale el paquete salt-minion en todos los nodos minion.

    root@minion > zypper in salt-minion

    Asegúrese de que el nombre completo de todos los demás nodos pueden resolver el nombre de cada nodo en la dirección IP pública.

  8. Configure todos los minions (incluido el minion master) para que se conecten con el principal. Si el nombre de host salt no puede acceder al master de Salt, edite el archivo /etc/salt/minion o cree un archivo nuevo /etc/salt/minion.d/master.conf con el siguiente contenido:

    master: host_name_of_salt_master

    Si realiza cambios en los archivos de configuración mencionados anteriormente, reinicie el servicio Salt en todos los minions de Salt:

    root@minion > systemctl restart salt-minion.service
  9. Compruebe que el servicio salt-minion está habilitado e iniciado en todos los nodos. Habilítelo e inícielo si fuera necesario:

    root # systemctl enable salt-minion.service
    root # systemctl start salt-minion.service
  10. Verifique la huella digital de cada minion de Salt y acepte todas las claves salt del master de Salt si las huellas coinciden.

    Nota
    Nota

    Si la huella digital del minion de Salt vuelve vacía, asegúrese de que el minion de Salt tenga una configuración de master de Salt y que pueda comunicarse con el master de Salt.

    Para ver la huella digital de cada minion:

    root@master # salt-call --local key.finger
    local:
    3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...

    Después de recopilar las huellas digitales de todos los minions de Salt, muestre las huellas de todas las claves de minion no aceptadas del master de Salt:

    root@master # salt-key -F
    [...]
    Unaccepted Keys:
    minion1:
    3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...

    Si las huellas digitales de los minions coinciden, acéptelas:

    root@master # salt-key --accept-all
  11. Verifique que las claves se han aceptado:

    root@master # salt-key --list-all
  12. Antes de distribuir SUSE Enterprise Storage 6, borre manualmente todos los discos. No olvide sustituir la "X" con la letra de disco correcta:

    1. Detenga todos los procesos que utilicen el disco específico.

    2. Verifique si hay montada alguna partición del disco y, de ser así, desmóntela.

    3. Si el disco está gestionado mediante LVM, desactive y suprima toda la infraestructura de LVM. Consulte https://www.suse.com/documentation/sles-15/book_storage/data/cha_lvm.html para obtener más información.

    4. Si el disco es parte de MD RAID, desactive el dispositivo RAID. Consulte https://www.suse.com/documentation/sles-15/book_storage/data/part_software_raid.html para obtener más información.

    5. Sugerencia
      Sugerencia: rearranque del servidor

      Si recibe mensajes de error de tipo "la partición está en uso" o "el kernel no se puede actualizar con la nueva tabla de particiones" durante los pasos siguientes, rearranque el servidor.

      Limpie el principio de cada partición (como usuario root):

      for partition in /dev/sdX[0-9]*
      do
        dd if=/dev/zero of=$partition bs=4096 count=1 oflag=direct
      done
    6. Limpie el principio de la unidad:

      root # dd if=/dev/zero of=/dev/sdX bs=512 count=34 oflag=direct
    7. Limpie el final de la unidad:

      root # dd if=/dev/zero of=/dev/sdX bs=512 count=33 \
        seek=$((`blockdev --getsz /dev/sdX` - 33)) oflag=direct
    8. Verifique que la unidad está vacía (sin estructuras GPT) con:

      root # parted -s /dev/sdX print free

      O bien

      root # dd if=/dev/sdX bs=512 count=34 | hexdump -C
      root # dd if=/dev/sdX bs=512 count=33 \
        skip=$((`blockdev --getsz /dev/sdX` - 33)) | hexdump -C
  13. Opcionalmente, si necesita preconfigurar los valores de red del clúster antes de que se instale el paquete deepsea, cree manualmente /srv/pillar/ceph/stack/ceph/cluster.yml y defina las opciones cluster_network: y public_network:. Tenga en cuenta que el archivo no se sobrescribirá después de instalar deepsea.

    Sugerencia
    Sugerencia: habilitación de IPv6

    Si necesita habilitar el direccionamiento de red IPv6, consulte la Sección 7.2.1, “Habilitación de IPv6 para la distribución del clúster de Ceph”.

  14. Instale DeepSea en el nodo master de Salt:

    root@master # zypper in deepsea
  15. El valor del parámetro master_minion se deriva dinámicamente del archivo /etc/salt/minion_id del master de Salt. Si necesita sustituir el valor descubierto, edite el archivo /srv/pillar/ceph/stack/global.yml y defina un valor relevante:

    master_minion: MASTER_MINION_NAME

    Si se puede acceder al master de Salt a través de otros nombres de host, utilice el nombre del minion de Salt que devuelve el comando salt-key -L para el clúster de almacenamiento. Si ha utilizado el nombre de host por defecto para el master de Salt (salt) en el dominio ses, el archivo tiene el aspecto siguiente:

    master_minion: salt.ses

Ahora, distribuya y configure Ceph. A menos que se especifique lo contrario, todos los pasos son obligatorios.

Nota
Nota: convenciones de comandos de salt

Existen dos maneras posibles de ejecutar salt-run state.orch: una es con "stage.NÚMERO_FASE", la otra es con el nombre de la fase. Ambas notaciones tienen el mismo efecto y elegir un comando u otro es puramente preferencial.

Procedimiento 5.1: Ejecución de fases de distribución
  1. Asegúrese de que los minions de Salt que pertenecen al clúster de Ceph estén correctamente asignados a un destino mediante la opción deepsea_minions de /srv/pillar/ceph/deepsea_minions.sls. Consulte la Sección 5.2.2.3, “Definición de la opción deepsea_minions para obtener más información.

  2. 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 distribuir sin perfiles ajustados. Para ello, coloque las líneas siguientes en /srv/pillar/ceph/stack/global.yml antes de ejecutar las fases de DeepSea:

    alternative_defaults:
     tuned_mgr_init: default-off
     tuned_mon_init: default-off
     tuned_osd_init: default-off
  3. Opcional: cree subvolúmenes de Btrfs para /var/lib/ceph/. Este paso debe ejecutarse antes de la fase 0 de DeepSea. Para migrar directorios existentes o para obtener más información, consulte Sección 25.6, “Subvolumen Btrfs para /var/lib/ceph en nodos de Ceph Monitor”.

    Aplique los comandos siguientes a cada uno de los minions de Salt:

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

    El comando Ceph.subvolume crea /var/lib/ceph como un subvolumen Btrfs de @/var/lib/ceph.

    El nuevo subvolumen se monta ahora y /etc/fstab se actualiza.

  4. Prepare el clúster. Consulte Descripción de las fases de DeepSea para obtener más información.

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

    O bien

    root@master # salt-run state.orch ceph.stage.prep
    Nota
    Nota: ejecución o supervisión de fases mediante la interfaz de línea de comandos de DeepSea

    Con la interfaz de línea de comandos de DeepSea puede realizar un seguimiento en tiempo real del progreso de la ejecución de las fases, ya sea ejecutando la interfaz en modo de supervisión, o bien ejecutando las fases directamente a través de dicha interfaz. Para obtener información detallada, consulte la Sección 5.4, “Interfaz de línea de comandos de DeepSea”.

  5. La fase de descubrimiento recopila datos de todos los minions y crea fragmentos de configuración que se almacenan en el directorio /srv/pillar/ceph/proposals. Los datos se almacenan en formato de YAML en archivos *.sls o *.yml.

    Ejecute el comando siguiente para activar la fase de descubrimiento:

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

    O bien

    root@master # salt-run state.orch ceph.stage.discovery
  6. Después de que el comando anterior finalice correctamente, cree un archivo policy.cfg en /srv/pillar/ceph/proposals. Para obtener información detallada, consulte la Sección 5.5.1, “El archivo policy.cfg.

    Sugerencia
    Sugerencia

    Si necesita cambiar la configuración de red del clúster, edite /srv/pillar/ceph/stack/ceph/cluster.yml y ajuste las líneas que comienzan con cluster_network: y public_network:.

  7. La fase de configuración analiza el archivo policy.cfg y combina los archivos incluidos en su formato final. El contenido relacionado con el clúster y la función se coloca en /srv/pillar/ceph/cluster, mientras que el contenido específico de Ceph se guarda en /srv/pillar/ceph/stack/default.

    Ejecute el comando siguiente para activar la fase de configuración:

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

    O bien

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

    El paso de configuración puede tardar varios segundos. Cuando finalice el comando, podrá ver los datos de Pillar de los minions especificados (por ejemplo, ceph_minion1, ceph_minion2, etc.) ejecutando:

    root@master # salt 'ceph_minion*' 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 el Sección 5.5.2, “DriveGroups”.

    Nota
    Nota: sobrescritura de valores por defecto

    Tan pronto como finalice el comando, puede ver la configuración por defecto y cambiarla para adaptarla a sus necesidades. Para obtener información detallada, consulte el Capítulo 7, Personalización de la configuración por defecto.

  8. Ahora se ejecuta la fase de distribución. En esta fase, se valida el pilar y se inician los daemons de Ceph Monitor y Ceph OSD:

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

    O bien

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

    El comando puede tardar varios minutos. Si se produce un error, debe solucionar el problema y volver a ejecutar las fases anteriores. Cuando el comando se ejecute correctamente, ejecute lo siguiente para comprobar el estado:

    cephadm@adm > ceph -s
  9. El último paso de la distribución del clúster de Ceph es la fase services. Aquí se crea una instancia de cualquiera de los servicios admitidos actualmente: iSCSI Gateway, CephFS, Object Gateway y NFS Ganesha. En esta fase, se crean los repositorios necesarios, los anillos de claves de autorización y los servicios de inicio. Para iniciar la fase, ejecute lo siguiente:

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

    O bien

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

    Según la configuración, puede que la ejecución del comando tarde varios minutos.

  10. Antes de continuar, se recomienda habilitar el módulo de telemetría de Ceph. Para obtener más información, consulte Sección 10.2, “Módulo de telemetría”.

5.4 Interfaz de línea de comandos de DeepSea Edit source

DeepSea también proporciona una interfaz de línea de comandos que permite al usuario supervisar o ejecutar fases mientras observa el progreso de la ejecución en tiempo real. Verifique que el paquete deepsea-cli esté instalado antes de ejecutar el archivo ejecutable deepsea.

Para ver el progreso de la ejecución de una fase, se admiten dos modos:

Modos de la interfaz de línea de comandos de DeepSea
  • Modo de supervisión: muestra el progreso de la ejecución de una fase de DeepSea activada por el comando salt-run emitido en otra sesión de terminal.

  • Modo autónomo: ejecuta una fase de DeepSea y proporciona una visualización en tiempo real de los pasos incluidos mientras se ejecutan.

Importante
Importante: comandos de la interfaz de línea de comandos de DeepSea

Los comandos de la interfaz de línea de comandos de DeepSea solo se pueden ejecutar en el nodo master de Salt con privilegios de usuario root.

5.4.1 Interfaz de línea de comandos de DeepSea: modo de monitor Edit source

El monitor de progreso ofrece una visualización detallada en tiempo real de lo que sucede durante la ejecución de las fases. Para ello, usa los comandos salt-run state.orch de otras sesiones de terminal.

Sugerencia
Sugerencia: inicio del monitor en una nueva sesión de terminal

Debe iniciar el monitor en una ventana de terminal nueva antes de ejecutar cualquier comando salt-run state.orch para que el monitor pueda detectar el inicio de la ejecución de la fase.

Si inicia el monitor después de emitir el comando salt-run state.orch, no se mostrará ningún progreso de la ejecución.

El modo de monitor se puede iniciar ejecutando el comando siguiente:

root@master # deepsea monitor

Para obtener más información sobre las opciones de línea de comandos disponibles para el comando deepsea monitor, consulte su página man:

root@master # man deepsea-monitor

5.4.2 Interfaz de línea de comandos de DeepSea: modo autónomo Edit source

En el modo autónomo, la interfaz de línea de comandos de DeepSea se puede usar para ejecutar una fase de DeepSea y mostrar su ejecución en tiempo real.

El comando para ejecutar una fase de DeepSea desde la interfaz de línea de comandos tiene el formato siguiente:

root@master # deepsea stage run stage-name

donde stage-name corresponde a la forma a la que se hace referencia a los archivos de estado de organización de Salt. Por ejemplo, a la fase deploy, que corresponde al directorio situado en /srv/salt/ceph/stage/deploy, se hace referencia como ceph.stage.deploy.

Este comando es una alternativa a los comandos basados en Salt para ejecutar las fases de DeepSea (o cualquier archivo de estado de organización de DeepSea).

El comando deepsea stage run ceph.stage.0 es equivalente a salt-run state.orch ceph.stage.0.

Para obtener más información sobre las opciones de línea de comandos disponibles aceptadas por el comando deepsea stage run, consulte su página man:

root@master # man deepsea-stage run

En la ilustración siguiente se muestra un ejemplo de la interfaz de línea de comandos de DeepSea cuando se ejecuta Stage 2:

Pantalla de progreso de la ejecución de fase en la interfaz de línea de comandos de DeepSea
Figura 5.1: Pantalla de progreso de la ejecución de fase en la interfaz de línea de comandos de DeepSea

5.4.2.1 Alias de stage run de la interfaz de línea de comandos de DeepSea Edit source

Para usuarios avanzados de Salt, también se admite un alias para ejecutar una fase de DeepSea que toma el comando de Salt que se usa para ejecutar una fase; por ejemplo, salt-run state.orch stage-name, como un comando de la interfaz de línea de comandos de DeepSea.

Ejemplo:

root@master # deepsea salt-run state.orch stage-name

5.5 Configuración y personalización Edit source

5.5.1 El archivo policy.cfg Edit source

El archivo de configuración /srv/pillar/ceph/proposals/policy.cfg se utiliza para determinar las funciones de los nodos de clúster individuales. Por ejemplo, qué nodos actúan como daemons de Ceph OSD o como monitores Ceph Monitor. Edite policy.cfg para reflejar la configuración de clúster que desee. El orden de las secciones es arbitrario, pero el contenido de las líneas incluidas sobrescribe las claves que coincidan con el contenido de las líneas anteriores.

Sugerencia
Sugerencia: ejemplos de policy.cfg

Encontrará varios ejemplos de archivos de directiva completos en el directorio /usr/share/doc/packages/deepsea/examples/.

5.5.1.1 Asignación de clúster Edit source

En la sección cluster, se seleccionan los minions para el clúster. Puede seleccionar todos los minions o crear una lista negra o una lista blanca de minions. A continuación, se muestran ejemplos para un clúster denominado ceph.

Para incluir todos los minions, añada las líneas siguientes:

cluster-ceph/cluster/*.sls

Para añadir un minion concreto a una lista blanca:

cluster-ceph/cluster/abc.domain.sls

O un grupo de minions (se pueden usar comodines):

cluster-ceph/cluster/mon*.sls

Para añadir minions a una lista negra, defínalos como unassigned:

cluster-unassigned/cluster/client*.sls

5.5.1.2 Asignación de funciones Edit source

En esta sección se proporciona información sobre cómo asignar "funciones" a los nodos del clúster. En este contexto, una función es el servicio que se debe ejecutar en el nodo, como Ceph Monitor, Object Gateway o iSCSI Gateway. Ninguna función se asigna automáticamente y solo las funciones que se añadan a policy.cfg se distribuirán.

La asignación sigue este patrón:

role-ROLE_NAME/PATH/FILES_TO_INCLUDE

Donde los elementos tienen el significado y los valores siguientes:

  • ROLE_NAME es uno de los siguientes elementos: "master", "admin", "mon", "mgr", "storage", "mds", "igw", "rgw", "ganesha", "grafana" o "prometheus".

  • PATH es una vía relativa a los archivos .sls o .yml. En el caso de los archivos .sls, normalmente es cluster, mientras que los archivos .yml se encuentran en stack/default/ceph/minions.

  • FILES_TO_INCLUDE son los archivos de estado de Salt o los archivos de configuración YAML. Normalmente, son nombres de host de los minions de Salt; por ejemplo, ses5min2.yml. Es posible usar comodines para obtener resultados más específicos.

A continuación se muestra un ejemplo de cada función:

  • master: el nodo tiene anillos de claves de administración para todos los clústeres de Ceph. Actualmente, solo se admite un único clúster de Ceph. Como la función master es obligatoria, añada siempre una línea similar a la siguiente:

    role-master/cluster/master*.sls
  • admin: el minion dispondrá de un anillo de claves de administración. Debe definir la función de la siguiente forma:

    role-admin/cluster/abc*.sls
  • mon: el minion proporcionará el servicio de monitor al clúster de Ceph. Esta función requiere las direcciones de los minions asignados. A partir de SUSE Enterprise Storage 5, las direcciones públicas se calculan de forma dinámica y ya no son necesarias en el pilar de Salt.

    role-mon/cluster/mon*.sls

    El ejemplo asigna la función de monitor a un grupo de minions.

  • mgr: el daemon de Ceph Manager que recopila toda la información de estado de todo el clúster. Distribúyalo en todos los minions en los que tenga previsto distribuir la función de monitor de Ceph.

    role-mgr/cluster/mgr*.sls
  • storage: use esta función para especificar nodos de almacenamiento.

    role-storage/cluster/data*.sls
  • mds: el minion proporcionará el servicio de metadatos para admitir CephFS.

    role-mds/cluster/mds*.sls
  • igw: el minion actuará como pasarela iSCSI Gateway. Esta función requiere las direcciones de los minions asignados, así que debe incluir también los archivos del directorio stack:

    role-igw/cluster/*.sls
  • rgw: el minion actuará como pasarela Object Gateway:

    role-rgw/cluster/rgw*.sls
  • ganesha: el minion actuará como servidor de NFS Ganesha. La función "ganesha" requiere que la función "rgw" o "mds" esté en el clúster, o de lo contrario fallará la validación en la fase 3.

    role-ganesha/cluster/ganesha*.sls

    Para instalar correctamente NFS Ganesha, se requiere configuración adicional. Si desea utilizar NFS Ganesha, lea el Capítulo 12, Instalación de NFS Ganesha antes de ejecutar las fases 2 y 4. Sin embargo, es posible instalar NFS Ganesha más adelante.

    En algunas ocasiones, puede ser útil definir funciones personalizadas para nodos de NFS Ganesha. Para obtener información, consulte: Sección 21.3, “Funciones personalizadas de NFS Ganesha”.

  • grafana, prometheus: este nodo añade gráficos de Grafana basados en Prometheus que aportan información a la Ceph Dashboard. Consulte Capítulo 22, Ceph Dashboard para obtener su descripción detallada.

    role-grafana/cluster/grafana*.sls
    role-prometheus/cluster/prometheus*.sls
Nota
Nota: varias funciones de nodos del clúster

Puede asignar varias funciones a un único nodo. Por ejemplo, puede asignar las funciones "mds" a los nodos de monitor:

role-mds/cluster/mon[1,2]*.sls

5.5.1.3 Configuración común Edit source

La sección de configuración común incluye archivos de configuración generados durante el descubrimiento (fase 1). Estos archivos de configuración almacenan parámetros como fsid o public_network. Para incluir la configuración común de Ceph necesaria, añada las líneas siguientes:

config/stack/default/global.yml
config/stack/default/ceph/cluster.yml

5.5.1.4 Filtrado de elementos Edit source

A veces no resulta práctico incluir todos los archivos de un directorio concreto con comodines *.sls. El analizador del archivo policy.cfg comprende los siguientes filtros:

Aviso
Aviso: técnicas avanzadas

En esta sección se describen técnicas de filtrado para usuarios avanzados. Si no se utiliza correctamente, el filtrado puede causar problemas, por ejemplo en caso de cambios de numeración del nodo.

slice=[start:end]

Utilice el filtro slice para incluir solo los elementos desde start hasta end-1. Tenga en cuenta que los elementos del directorio indicado se ordenan alfanuméricamente. La línea siguiente incluye del tercer al quinto archivo del subdirectorio role-mon/cluster/:

role-mon/cluster/*.sls slice[3:6]
re=regexp

Utilice el filtro de expresión regular para incluir solo los elementos que coincidan con las expresiones indicadas. Por ejemplo:

role-mon/cluster/mon*.sls re=.*1[135]\.subdomainX\.sls$

5.5.1.5 Archivo policy.cfg de ejemplo Edit source

A continuación se muestra un ejemplo de un archivo policy.cfg básico:

## Cluster Assignment
cluster-ceph/cluster/*.sls 1

## Roles
# ADMIN
role-master/cluster/examplesesadmin.sls 2
role-admin/cluster/sesclient*.sls 3

# MON
role-mon/cluster/ses-example-[123].sls 4

# MGR
role-mgr/cluster/ses-example-[123].sls 5

# STORAGE
role-storage/cluster/ses-example-[5,6,7,8].sls 6

# MDS
role-mds/cluster/ses-example-4.sls 7

# IGW
role-igw/cluster/ses-example-4.sls 8

# RGW
role-rgw/cluster/ses-example-4.sls 9

# COMMON
config/stack/default/global.yml 10
config/stack/default/ceph/cluster.yml 11

1

Indica que todos los minions están incluidos en el clúster de Ceph. Si tiene minions que no desea incluir en el clúster de Ceph, utilice:

cluster-unassigned/cluster/*.sls
cluster-ceph/cluster/ses-example-*.sls

La primera línea marca todos los minions como no asignados. La segunda línea anula los minions que coinciden con "ses-example-*.sls" y los asigna al clúster de Ceph.

2

El minion denominado "examplesesadmin" tiene la función "master". Por cierto, esto significa que obtendrá las claves de administración para el clúster.

3

Todos los minions que coincidan con "sesclient*" obtendrán también las claves de administración.

4

Todos los minions que coincidan con "ses-example-[123]" (posiblemente tres minions: ses-example-1, ses-example-2 y ses-example-3) se configurarán como nodos MON.

5

Todos los minions que coincidan con "ses-example-[123]" (todos los nodos MON del ejemplo) se configurarán como nodos MGR.

6

Todos los minions que coincidan con "ses-example-[5,6,7,8]" se configurarán como nodos de almacenamiento.

7

El minion "ses-example-4" tendrá la función de servidor de metadatos.

8

El minion "ses-example-4" tendrá la función de IGW.

9

El minion "ses-example-4" tendrá la función de RGW.

10

Significa que se aceptan los valores por defecto para los parámetros de configuración comunes, como fsid y public_network.

11

Significa que se aceptan los valores por defecto para los parámetros de configuración comunes, como fsid y public_network.

5.5.2 DriveGroups Edit source

DriveGroups especifica los diseños de los OSD del clúster de Ceph. Se definen en un único archivo /srv/salt/ceph/configuration/files/drive_groups.yml.

Un administrador debe especificar manualmente un grupo de OSD que estén interrelacionados (OSD híbridos que se distribuyen en unidades de estado sólido y giratorias) o que compartan las mismas opciones de distribución (deben ser idénticas, por ejemplo, el mismo almacén de objetos, la misma opción de cifrado y varios OSD independientes). Para no tener que mostrar explícitamente los dispositivos, DriveGroups utiliza una lista de elementos de filtro que corresponden a algunos campos seleccionados de los informes de inventario de ceph-volume. En el caso más simple, podría tratarse del indicador "rotational" (todas las unidades de estado sólido deben ser dispositivos DB y todas las unidades giratorias deben ser dispositivos de datos) o algo más específico, como cadenas de tipo "modelo" o tamaños. DeepSea proporciona código que traduce estos DriveGroups en listas de dispositivos reales para que el usuario las pueda inspeccionar.

A continuación se muestra un procedimiento sencillo que muestra el flujo de trabajo básico para configurar DriveGroups:

  1. Inspeccione cómo se muestran las propiedades de los discos con el comando ceph-volume. DriveGroups solo acepta estas propiedades:

    root@master # salt-run disks.details
  2. Abra el archivo YAML /srv/salt/ceph/configuration/files/drive_groups.yml y ajústelo según sus necesidades. Consulte la Sección 5.5.2.1, “Especificación”. Recuerde usar espacios en lugar de tabuladores. Encontrará ejemplos más avanzados en la Sección 5.5.2.4, “Ejemplos”. En el ejemplo siguiente se incluyen todas las unidades disponibles para Ceph como OSDs:

    default_drive_group_name:
      target: '*'
      data_devices:
        all: true
  3. Verifique los nuevos diseños:

    root@master # salt-run disks.list

    Este runner devuelve una estructura de discos que coinciden basada en DriveGroups. Si no le satisface el resultado, repita el paso anterior.

    Sugerencia
    Sugerencia: informe detallado

    Además del runner disks.list, hay un runner disks.report que muestra un informe detallado de lo que sucederá en la próxima invocación de la fase 3 de DeepSea.

    root@master # salt-run disks.report
  4. Distribuya los OSD. En la siguiente invocación de la fase 3 de DeepSea, los discos OSD se distribuirán de acuerdo con las especificaciones del grupo de unidades.

5.5.2.1 Especificación Edit source

/srv/salt/ceph/configuration/files/drive_groups.yml acepta las siguientes opciones:

drive_group_default_name:
  target: *
  data_devices:
    drive_spec: DEVICE_SPECIFICATION
  db_devices:
    drive_spec: DEVICE_SPECIFICATION
  wal_devices:
    drive_spec: DEVICE_SPECIFICATION
  block_wal_size: '5G'  # (optional, unit suffixes permitted)
  block_db_size: '5G'   # (optional, unit suffixes permitted)
  osds_per_device: 1   # number of osd daemons per device
  format:              # 'bluestore' or 'filestore' (defaults to 'bluestore')
  encryption:           # 'True' or 'False' (defaults to 'False')

Para las configuraciones de FileStore, drive_groups.yml puede tener este aspecto:

drive_group_default_name:
  target: *
  data_devices:
    drive_spec: DEVICE_SPECIFICATION
  journal_devices:
    drive_spec: DEVICE_SPECIFICATION
  format: filestore
  encryption: True

5.5.2.2 Dispositivos de disco que coinciden Edit source

Puede describir la especificación utilizando los filtros siguientes:

  • Por modelo del disco:

    model: DISK_MODEL_STRING
  • Por proveedor del disco:

    vendor: DISK_VENDOR_STRING
    Sugerencia
    Sugerencia: cadena de proveedor en minúsculas

    Use siempre minúsculas para DISK_VENDOR_STRING.

  • Indica si un disco es giratorio o no. Las unidades SSD y NVME no son giratorias.

    rotational: 0
  • Distribuya un nodo utilizando todas las unidades disponibles para los OSD:

    data_devices:
      all: true
  • También puede limitar el número de discos que coinciden:

    limit: 10

5.5.2.3 Filtrado de dispositivos por tamaño Edit source

Es posible filtrar los dispositivos de disco por su tamaño, ya sea por un tamaño exacto o por un intervalo de tamaños. El parámetro size: acepta argumentos con el formato siguiente:

  • '10G': incluye discos de un tamaño exacto.

  • '10G:40G': incluye discos cuyo tamaño está dentro del intervalo indicado.

  • ':10G': incluye discos de 10 GB o menos.

  • '40G:': incluye discos de 40 GB o más.

Ejemplo 5.1: Coincidencia por tamaño de disco
drive_group_default:
  target: '*'
  data_devices:
    size: '40TB:'
  db_devices:
    size: ':2TB'
Nota
Nota: comillas obligatorias

Si se usa el delimitador ":", debe incluir el tamaño entre comillas simples, de lo contrario el signo ":" se interpretará como un nuevo hash de configuración.

Sugerencia
Sugerencia: accesos directos a unidades

En lugar de (G)igabytes, también puede especificar los tamaños en (M)egabytes o en (T)erabytes.

5.5.2.4 Ejemplos Edit source

Esta sección incluye ejemplos de diferentes configuraciones de OSD.

Ejemplo 5.2: Configuración sencilla

Este ejemplo describe dos nodos con la misma configuración:

  • 20 discos duros

    • Proveedor: Intel

    • Modelo: SSD-123-foo

    • Tamaño: 4 TB

  • 2 discos SSD

    • Proveedor: Micron

    • Modelo: MC-55-44-ZX

    • Tamaño: 512 GB

El archivo drive_groups.yml correspondiente será el siguiente:

drive_group_default:
  target: '*'
  data_devices:
    model: SSD-123-foo
  db_devices:
    model: MC-55-44-XZ

Esta configuración es sencilla y válida. El problema es que un administrador puede añadir discos de diferentes proveedores en el futuro, y estos no se incluirán. Puede mejorarla reduciendo los filtros en las propiedades principales de las unidades:

drive_group_default:
  target: '*'
  data_devices:
    rotational: 1
  db_devices:
    rotational: 0

En el ejemplo anterior, estamos imponiendo que se declaren todos los dispositivos giratorios como "dispositivos de datos" y todos los dispositivos no giratorios se utilizarán como "dispositivos compartidos" (wal, db).

Si sabe que las unidades de más de 2 TB siempre serán los dispositivos de datos más lentos, puede filtrar por tamaño:

drive_group_default:
  target: '*'
  data_devices:
    size: '2TB:'
  db_devices:
    size: ':2TB'
Ejemplo 5.3: Configuración avanzada

En este ejemplo se describen dos configuraciones distintas: 20 discos duros deben compartir 2 unidades SSD, mientras que 10 unidades SSD deben compartir 2 NVMe.

  • 20 discos duros

    • Proveedor: Intel

    • Modelo: SSD-123-foo

    • Tamaño: 4 TB

  • 12 discos SSD

    • Proveedor: Micron

    • Modelo: MC-55-44-ZX

    • Tamaño: 512 GB

  • 2 NVMe

    • Proveedor: Samsung

    • Modelo: NVME-QQQQ-987

    • Tamaño: 256 GB

Esta configuración se puede definir con dos diseños de la siguiente manera:

drive_group:
  target: '*'
  data_devices:
    rotational: 0
  db_devices:
    model: MC-55-44-XZ
drive_group_default:
  target: '*'
  data_devices:
    model: MC-55-44-XZ
  db_devices:
    vendor: samsung
    size: 256GB
Ejemplo 5.4: Configuración avanzada con nodos no uniformes

En los ejemplos anteriores se suponía que todos los nodos tienen las mismas unidades. Sin embargo, eso no siempre es así:

Nodos 1-5:

  • 20 discos duros

    • Proveedor: Intel

    • Modelo: SSD-123-foo

    • Tamaño: 4 TB

  • 2 discos SSD

    • Proveedor: Micron

    • Modelo: MC-55-44-ZX

    • Tamaño: 512 GB

Nodos 6-10:

  • 5 NVMe

    • Proveedor: Intel

    • Modelo: SSD-123-foo

    • Tamaño: 4 TB

  • 20 discos SSD

    • Proveedor: Micron

    • Modelo: MC-55-44-ZX

    • Tamaño: 512 GB

Puede utilizar la clave "target" en el diseño para asignar nodos específicos a un destino. La notación del destino de Salt ayuda a simplificar las cosas:

drive_group_node_one_to_five:
  target: 'node[1-5]'
  data_devices:
    rotational: 1
  db_devices:
    rotational: 0

seguido de

drive_group_the_rest:
  target: 'node[6-10]'
  data_devices:
    model: MC-55-44-XZ
  db_devices:
    model: SSD-123-foo
Ejemplo 5.5: Configuración para expertos

En todos los casos anteriores se presuponía que los WAL y DB usaban el mismo dispositivo. Sin embargo, también es posible distribuir el WAL en un dispositivo dedicado:

  • 20 discos duros

    • Proveedor: Intel

    • Modelo: SSD-123-foo

    • Tamaño: 4 TB

  • 2 discos SSD

    • Proveedor: Micron

    • Modelo: MC-55-44-ZX

    • Tamaño: 512 GB

  • 2 NVMe

    • Proveedor: Samsung

    • Modelo: NVME-QQQQ-987

    • Tamaño: 256 GB

drive_group_default:
  target: '*'
  data_devices:
    model: MC-55-44-XZ
  db_devices:
    model: SSD-123-foo
  wal_devices:
    model: NVME-QQQQ-987
Ejemplo 5.6: Configuración compleja (e improbable)

En la siguiente configuración, tratamos de definir lo siguiente:

  • 20 discos duros respaldados por 1 NVMe

  • 2 discos duros respaldados por 1 SSD (db) y 1 NVMe (wal)

  • 8 discos SSD respaldados por 1 NVMe

  • 2 discos SSD independientes (cifrados)

  • 1 disco duro es de repuesto y no debe distribuirse

El resumen de las unidades usadas es el siguiente:

  • 23 discos duros

    • Proveedor: Intel

    • Modelo: SSD-123-foo

    • Tamaño: 4 TB

  • 10 discos SSD

    • Proveedor: Micron

    • Modelo: MC-55-44-ZX

    • Tamaño: 512 GB

  • 1 NVMe

    • Proveedor: Samsung

    • Modelo: NVME-QQQQ-987

    • Tamaño: 256 GB

La definición de DriveGroups será la siguiente:

drive_group_hdd_nvme:
  target: '*'
  data_devices:
    rotational: 0
  db_devices:
    model: NVME-QQQQ-987
drive_group_hdd_ssd_nvme:
  target: '*'
  data_devices:
    rotational: 0
  db_devices:
    model: MC-55-44-XZ
  wal_devices:
    model: NVME-QQQQ-987
drive_group_ssd_nvme:
  target: '*'
  data_devices:
    model: SSD-123-foo
  db_devices:
    model: NVME-QQQQ-987
drive_group_ssd_standalone_encrypted:
  target: '*'
  data_devices:
    model: SSD-123-foo
  encryption: True

Se conservará un disco duro porque el archivo se está analizando de arriba abajo.

5.5.3 Ajuste de ceph.conf con valores personalizados Edit source

Si es necesario establecer valores personalizados en el archivo de configuración ceph.conf, consulte el Sección 2.13, “Ajuste de ceph.conf con valores personalizados” para obtener más detalles.

Imprimir esta página