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

4 Distribución con DeepSea/Salt

Nota
Nota: ceph-deploy se ha eliminado en SUSE Enterprise Storage 5

La herramienta de distribución de clúster ceph-deploy quedó obsoleta en SUSE Enterprise Storage 4 y se ha eliminado por completo para sustituirse por DeepSea a partir de SUSE Enterprise Storage 5.

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, servidor de metadatos o Ceph Monitor al master de Salt.

  • 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 4.3, “Distribución del clúster”.

4.1 Lectura de las notas de la versión

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/.

4.2 Introducción a DeepSea

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: vuelva a ejecutar la fase 0 siempre que se rearranque el master de Salt

    Si durante la fase 0, el master de Salt se rearranca 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 4.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 1.3, “eliminación y reinstalación de nodos del clúster”.

Encontrará una introducción más detallada sobre DeepSea en https://github.com/suse/deepsea/wiki.

4.2.1 Organización y ubicaciones importantes

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. Para obtener más información, consulte la documentación de Salt.

/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.

4.2.2 Asignación de destino de los minions

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.

4.2.2.1 Coincidencia del nombre del minion

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

4.2.2.2 Asignación de destino con un grain "deepsea"

En un entorno heterogéneo gestionado mediante Salt donde SUSE Enterprise Storage se distribuya en un subconjunto de nodos junto con otras soluciones de clúster, es buena idea "marcar" los minions relevantes aplicándoles un grain "deepsea". De este modo, puede asignar fácilmente minions de DeepSea en entornos donde sea difícil obtener los nombres de los minions haciéndolos coincidir.

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

4.2.2.3 Definición de la opción deepsea_minions

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:*'

4.2.2.4 Información adicional

Puede utilizar métodos más avanzados para asignar destinos a los minions con la infraestructura de Salt. Consulte https://docs.saltstack.com/en/latest/topics/targeting/ para obtener una descripción de todas las técnicas de asignación de destinos.

Asimismo, la página man "deepsea minions" ofrece más detalles sobre la asignación de destinos de DeepSea (man 7 deepsea_minions).

4.3 Distribución del clúster

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 perfiles de OSD y distribuir primero los nodos de monitor, puede hacerlo definiendo la variable DEV_ENV. De esta forma puede distribuir monitores sin la presencia del directorio profile/, además de distribuir un clúster con al menos un nodo 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

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

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

  2. Verifique que los productos adecuados están instalados y registrados mostrando los repositorios de software existentes. La lista será similar a esta:

     root@minion > zypper lr -E
    #  | Alias   | Name                              | Enabled | GPG Check | Refresh
    ---+---------+-----------------------------------+---------+-----------+--------
     4 | [...]   | SUSE-Enterprise-Storage-5-Pool    | Yes     | (r ) Yes  | No
     6 | [...]   | SUSE-Enterprise-Storage-5-Updates | Yes     | (r ) Yes  | Yes
     9 | [...]   | SLES12-SP3-Pool                   | Yes     | (r ) Yes  | No
    11 | [...]   | SLES12-SP3-Updates                | Yes     | (r ) Yes  | Yes
  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-12/book_sle_admin/data/sec_basicnet_yast.html. Para obtener más información sobre cómo configurar un servidor DNS, consulte https://www.suse.com/documentation/sles-12/book_sle_admin/data/cha_dns.html.

  4. Configure, habilite e inicie el servidor de sincronización horaria NTP:

    root@master # systemctl enable ntpd.service
    root@master # systemctl start ntpd.service

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

  5. Compruebe si se está ejecutando el servicio AppArmor e inhabilítelo en todos los nodos del clúster. Inicie el módulo AppArmor de YaST, seleccione Settings (Configuración) y desactive la casilla de verificación Enable Apparmor (Habilitar Apparmor). Confirme haciendo clic en Done (Terminado).

    Tenga en cuenta que SUSE Enterprise Storage no funcionará si AppArmor está habilitado.

  6. 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
  7. 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@master # systemctl stop SuSEfirewall2.service

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

    FAIL_ON_WARNING: False
  8. 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.

  9. 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
  10. Compruebe que el servicio salt-minion está habilitado e iniciado en todos los nodos. Habilítelo e inícielo si fuera necesario:

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

    Para ver la huella digital de cada minion:

    root@minion > 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 la huella digital de los minions coinciden, acéptelas:

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

    root@master # salt-key --list-all
  13. Antes de distribuir SUSE Enterprise Storage, asegúrese de que todos los discos que se han utilizado como OSD por los clústeres anteriores están vacíos y sin particiones. Para ello, deberá borrar manualmente la tabla de particiones de 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-12/stor_admin/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-12/stor_admin/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:

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

      sgdisk -Z --clear -g /dev/sdX
    7. Limpie las tablas de particiones de copia de seguridad:

      size=`blockdev --getsz /dev/sdX`
      position=$((size/4096 - 33))
      dd if=/dev/zero of=/dev/sdX bs=4M count=33 seek=$position oflag=direct
  14. Instale DeepSea en el nodo master de Salt:

    root@master # zypper in deepsea
  15. Compruebe que el archivo /srv/pillar/ceph/master_minion.sls del master de Salt apunta a su master de Salt. Si es posible acceder a su master de Salt a través de otros nombres de host, utilice el adecuado 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 de 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 4.1: Ejecución de fases de distribución
  1. Incluya los minions de Salt que pertenezcan al clúster de Ceph que va a distribuir. Consulte la Sección 4.2.2.1, “Coincidencia del nombre del minion” para obtener más información sobre cómo asignar destinos a los minions.

  2. 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 4.4, “Interfaz de línea de comandos de DeepSea”.

  3. Opcional: cree subvolúmenes de Btrfs para /var/lib/ceph/. Este paso solo se debe ejecutar antes de que se hayan ejecutado las fases siguientes de DeepSea. Para migrar los directorios existentes, o para obtener más información, consulte el Sección 18.5, “Subvolumen Btrfs para /var/lib/ceph”.

    root@master # salt-run state.orch ceph.migrate.subvolume
  4. 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.

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

    O bien

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

  6. 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
    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.

  7. Ahora se ejecuta la fase de distribución. En esta fase, se valida Pillar y los monitores y los daemons de OSD se inician en los nodos de almacenamiento. Ejecute lo siguiente para iniciar la fase:

    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:

    root@master # ceph -s
  8. 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, openATTIC 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.

4.4 Interfaz de línea de comandos de DeepSea

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.

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.

4.4.1 Interfaz de línea de comandos de DeepSea: modo de monitor

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.

Debe iniciar el monitor 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

4.4.2 Interfaz de línea de comandos de DeepSea: modo autónomo

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 4.1: Pantalla de progreso de la ejecución de fase en la interfaz de línea de comandos de DeepSea

4.4.2.1 Alias de stage run de la interfaz de línea de comandos de DeepSea

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

4.5 Configuración y personalización

4.5.1 El archivo policy.cfg

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é nodo actúa como un OSD o cuál actúa como 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/.

4.5.1.1 Asignación de clúster

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

4.5.1.2 Asignación de funciones

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 debe ejecutar en el nodo, como Ceph Monitor, Object Gateway, iSCSI Gateway u openATTIC. 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", "mds", "igw", "rgw", "ganesha" o "openattic".

  • 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 supervisión 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 Pillar de Salt.

    role-mon/cluster/mon*.sls

    El ejemplo asigna la función de supervisión 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
  • 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/stack/default/ceph/minions/xyz.domain.yml
    role-igw/cluster/*.sls
  • rgw: el minion actuará como pasarela Object Gateway:

    role-rgw/cluster/rgw*.sls
  • openattic: el minion actuará como servidor de openATTIC:

    role-openattic/cluster/openattic*.sls

    Para obtener más información, consulte: Capítulo 15, openATTIC.

  • 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.

    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 14.3, “Funciones personalizadas de NFS Ganesha”.

Nota
Nota: varias funciones de nodos del clúster

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

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

4.5.1.3 Configuración común

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

4.5.1.4 Asignación de perfil

En Ceph, una función de almacenamiento única no sería suficiente para describir las numerosas configuraciones de disco disponibles con el mismo hardware. La fase 1 de DeepSea generará una propuesta de perfil de almacenamiento por defecto. Esta propuesta será por defecto un perfil bluestore e intentará proponer la configuración de mayor rendimiento para la configuración de hardware determinada. Por ejemplo, se preferirán diarios externos a un único disco que contenga objetos y metadatos. El almacenamiento de estado sólido se priorizará sobre los discos rotatorios. Los perfiles se asignan en policy.cfg, igual que las funciones.

La propuesta por defecto se encuentra en el árbol de directorios por defecto del perfil. Para incluirlo, añada estas dos líneas a policy.cfg.

profile-default/cluster/*.sls
profile-default/stack/default/ceph/minions/*.yml

También puede crear un perfil de almacenamiento personalizado a su gusto utilizando el runner de propuestas. Este runner ofrece tres métodos: help, peek y populate.

salt-run proposal.help imprime el texto de ayuda del runner sobre los distintos argumentos que acepta.

salt-run proposal.peek muestra la propuesta generada según los argumentos pasados.

salt-run proposal.populate escribe la propuesta en el subdirectorio /srv/pillar/ceph/proposals. Pasa name=myprofile para asignar un nombre al perfil de almacenamiento. Esto dará como resultado un subdirectorio profile-myprofile.

Para todos los demás argumentos, consulte el resultado de salt-run proposal.help.

4.5.1.5 Distribución de OSD cifrados

A partir de SUSE Enterprise Storage 5, los OSD se distribuyen por defecto mediante BlueStore, en lugar de mediante FileStore. Aunque BlueStore admite el cifrado, los Ceph OSD se distribuyen sin cifrar por defecto. En él se presupone que tanto los datos como los discos WAL/DB que se van a usar para la distribución de los OSD están limpios y no tienen particiones. Si el disco se ha utilizado anteriormente, bórrelo con el procedimiento descrito en el Paso 13.

Para utilizar OSD cifrados para la distribución nueva, use el runner proposal.populate con el argumento encryption=dmcrypt:

root@master # salt-run proposal.populate encryption=dmcrypt

4.5.1.6 Filtrado de elementos

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$

4.5.1.7 Archivo policy.cfg de ejemplo

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

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

# IGW
role-igw/stack/default/ceph/minions/ses-example-4.yml 7
role-igw/cluster/ses-example-4.sls 8

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

# openATTIC
role-openattic/cluster/openattic*.sls 10

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

## Profiles
profile-default/cluster/*.sls 13
profile-default/stack/default/ceph/minions/*.yml 14

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

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

7

Asegúrese de que DeepSea conozca la dirección IP del nodo de IGW.

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

Indica que se va a distribuir la interfaz de usuario openATTIC para administrar el clúster de Ceph. Consulte el Capítulo 15, openATTIC para obtener más información.

11

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

12

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

13

Se indica a DeepSea que use el perfil de hardware por defecto para cada minion. Elegir el perfil de hardware por defecto significa que queremos que todos los discos adicionales (que no sean el disco raíz) sean OSD.

14

Se indica a DeepSea que use el perfil de hardware por defecto para cada minion. Elegir el perfil de hardware por defecto significa que queremos que todos los discos adicionales (que no sean el disco raíz) sean OSD.

4.5.2 Archivo ceph.conf personalizado

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

Imprimir esta página