documentation.suse.com / Documentación de SUSE Enterprise Storage 7.1 / Guía de distribución / Distribución del clúster de Ceph / Distribución de los servicios principales restantes mediante cephadm
Se aplica a SUSE Enterprise Storage 7.1

8 Distribución de los servicios principales restantes mediante cephadm

 

Después de distribuir el clúster de Ceph básico, distribuya los servicios principales a más nodos del clúster. Para que los clientes puedan acceder a los datos del clúster, distribuya también servicios adicionales.

Actualmente, se admite la distribución de servicios de Ceph en la línea de comandos mediante Ceph Orchestrator (subcomandos de ceph orch).

8.1 El comando ceph orch

 

El comando ceph orch de Ceph Orchestrator, que es una interfaz para el módulo cephadm, se encarga de mostrar los componentes del clúster y de distribuir los servicios de Ceph en los nuevos nodos del clúster.

8.1.1 Visualización del estado del orquestador

 

El comando siguiente muestra el modo y el estado actuales de Ceph Orchestrator. 

cephuser@adm > ceph orch status

8.1.2 Listado de dispositivos, servicios y daemons

 

Para mostrar todos los dispositivos del disco, ejecute lo siguiente: 

cephuser@adm > ceph orch device ls
Hostname   Path      Type  Serial  Size   Health   Ident  Fault  Available
ses-master /dev/vdb  hdd   0d8a... 10.7G  Unknown  N/A    N/A    No
ses-min1   /dev/vdc  hdd   8304... 10.7G  Unknown  N/A    N/A    No
ses-min1   /dev/vdd  hdd   7b81... 10.7G  Unknown  N/A    N/A    No
[...]
Sugerencia
Sugerencia: servicios y daemons

Un servicio es un término general que se usa para un servicio de Ceph de un tipo específico, por ejemplo, Ceph Manager.

Un daemon es una instancia específica de un servicio, por ejemplo, un proceso mgr.ses-min1.gdlcik que se ejecuta en un nodo llamado ses-min1.

Para mostrar todos los servicios conocidos por cephadm, ejecute: 

cephuser@adm > ceph orch ls
NAME  RUNNING  REFRESHED  AGE  PLACEMENT  IMAGE NAME                  IMAGE ID
mgr       1/0  5m ago     -    <no spec>  registry.example.com/[...]  5bf12403d0bd
mon       1/0  5m ago     -    <no spec>  registry.example.com/[...]  5bf12403d0bd
Sugerencia
Sugerencia

Puede limitar la lista a los servicios de un nodo concreto con el parámetro opcional ‑‑host, y los servicios de un tipo concreto con el parámetro opcional --service-type. Los tipos admitidos son mon, osd, mgr, mds y rgw.

Para mostrar todos los daemons en ejecución distribuidos por cephadm, ejecute: 

cephuser@adm > ceph orch ps
NAME            HOST     STATUS   REFRESHED AGE VERSION    IMAGE ID     CONTAINER ID
mgr.ses-min1.gd ses-min1 running) 8m ago    12d 15.2.0.108 5bf12403d0bd b8104e09814c
mon.ses-min1    ses-min1 running) 8m ago    12d 15.2.0.108 5bf12403d0bd a719e0087369
Sugerencia
Sugerencia

Para consultar el estado de un daemon concreto, utilice --daemon_type y --daemon_id. Para los OSD, el ID es el ID de OSD numérico. Para MDS, el ID es el nombre del de archivos: 

cephuser@adm > ceph orch ps --daemon_type osd --daemon_id 0
cephuser@adm > ceph orch ps --daemon_type mds --daemon_id my_cephfs

8.2 Especificación del servicio y la colocación

 

La forma recomendada de especificar la distribución de los servicios de Ceph es crear un archivo con formato YAML con la especificación de los servicios que desea distribuir.

8.2.1 Creación de especificaciones de servicio

 

Puede crear un archivo de especificación independiente para cada tipo de servicio, por ejemplo: 

root@master # cat nfs.yml
service_type: nfs
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min1
  - ses-min2
spec:
  pool: EXAMPLE_POOL
  namespace: EXAMPLE_NAMESPACE

Como alternativa, puede especificar varios tipos de servicios, o todos ellos en un archivo (por ejemplo, cluster.yml) que describe qué nodos ejecutarán servicios específicos. Recuerde separar los tipos de servicios individuales con tres guiones (---): 

cephuser@adm > cat cluster.yml
service_type: nfs
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min1
  - ses-min2
spec:
  pool: EXAMPLE_POOL
  namespace: EXAMPLE_NAMESPACE
---
service_type: rgw
service_id: REALM_NAME.ZONE_NAME
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
---
[...]

Las propiedades mencionadas anteriormente tienen el siguiente significado:

service_type

El tipo de servicio. Puede ser un servicio de Ceph (mon, mgr, mds, crash, osd o rbd-mirror), una pasarela (nfs o rgw) o parte de la pila de supervisión (alertmanager, grafana, node-exporter o prometheus).

service_id

El nombre del servicio. Las especificaciones de tipo mon, mgr, alertmanager, grafana, node-exporter y prometheus no requieren la propiedad service_id.

placement

Especifica qué nodos ejecutarán el servicio. Consulte la Sección 8.2.2, “Creación de especificaciones de colocación” para obtener más información.

spec

Especificación adicional relevante para el tipo de servicio.

Sugerencia
Sugerencia: aplicación de servicios específicos

Los servicios del clúster de Ceph suelen tener varias propiedades específicas. Para obtener ejemplos y detalles de cada especificación de servicios, consulte la Sección 8.3, “Distribución de servicios de Ceph”.

8.2.2 Creación de especificaciones de colocación

 

Para distribuir los servicios de Ceph, cephadm necesita saber en qué nodos debe distribuirlos. Utilice la propiedad placement y muestre los nombres de host cortos de los nodos a los que se aplica el servicio: 

cephuser@adm > cat cluster.yml
[...]
placement:
  hosts:
  - host1
  - host2
  - host3
[...]

8.2.3 Aplicación de la especificación del clúster

 

Después de crear un archivo cluster.yml completo con las especificaciones de todos los servicios y su colocación, puede aplicar el clúster ejecutando el comando siguiente: 

cephuser@adm > ceph orch apply -i cluster.yml

Para ver el estado del clúster, ejecute el comando ceph orch status. Para obtener más información, consulte la Sección 8.1.1, “Visualización del estado del orquestador”.

8.2.4 Exportación de la especificación de un clúster en ejecución

 

Aunque ha distribuido servicios al clúster de Ceph mediante los archivos de especificación como se describe en la Sección 8.2, “Especificación del servicio y la colocación”, la configuración del clúster puede diferir de la original durante su funcionamiento. Además, es posible que haya eliminado los archivos de especificación accidentalmente.

Para recuperar una especificación completa de un clúster en ejecución, ejecute: 

cephuser@adm > ceph orch ls --export
placement:
  hosts:
  - hostname: ses-min1
    name: ''
    network: ''
service_id: my_cephfs
service_name: mds.my_cephfs
service_type: mds
---
placement:
  count: 2
service_name: mgr
service_type: mgr
---
[...]
Sugerencia
Sugerencia

Puede añadir la opción --format para cambiar el formato de salida yaml por defecto. Puede seleccionar json, json-pretty o yaml. Por ejemplo: 

ceph orch ls --export --format json

8.3 Distribución de servicios de Ceph

 

Cuando el clúster básico esté en ejecución, puede distribuir los servicios de Ceph a nodos adicionales.

8.3.1 Distribución de monitores Ceph Monitor y gestores Ceph Manager

 

El clúster de Ceph tiene tres o cinco MON distribuidos en distintos nodos. Si hay cinco o más nodos en el clúster, se recomienda distribuir cinco MON. Una práctica recomendada consiste en distribuir los MGR en los mismos nodos que los MON.

Importante
Importante: inclusión de MON de arranque

Al distribuir MON y MGR, recuerde incluir el primer MON que haya añadido al configurar el clúster básico en la Sección 7.2.5, “Especificación del primer nodo de MON/MGR”.

Para distribuir MON, aplique la siguiente especificación: 

service_type: mon
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
Nota
Nota

Si necesita añadir otro nodo, añada el nombre de host al final de la misma lista de YAML. Por ejemplo: 

service_type: mon
placement:
 hosts:
 - ses-min1
 - ses-min2
 - ses-min3
 - ses-min4

Del mismo modo, para distribuir MGR, aplique la siguiente especificación:

Importante
Importante

Asegúrese de que la distribución tenga al menos tres Ceph Manager en cada distribución. 

service_type: mgr
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
Sugerencia
Sugerencia

Si los MON o MGR no se encuentran en la misma subred, deberá añadir las direcciones de subred al final. Por ejemplo: 

service_type: mon
placement:
  hosts:
  - ses-min1:10.1.2.0/24
  - ses-min2:10.1.5.0/24
  - ses-min3:10.1.10.0/24

8.3.2 Distribución de los OSD de Ceph

 
Importante
Importante: cuando el dispositivo de almacenamiento está disponible

Un dispositivo de almacenamiento se considera que está disponible si se cumplen todas las condiciones siguientes:

  • El dispositivo no tiene particiones.

  • El dispositivo no tiene ningún estado de LVM.

  • El dispositivo no está montado.

  • El dispositivo no contiene un sistema de archivos.

  • El dispositivo no contiene un OSD de BlueStore.

  • El dispositivo tiene más de 5 GB.

Si no se cumplen las condiciones anteriores, Ceph se niega a aprovisionar dichos OSD.

Hay dos formas de distribuir los OSD:

  • Indique a Ceph que consuma todos los dispositivos de almacenamiento disponibles y no utilizados: 

    cephuser@adm > ceph orch apply osd --all-available-devices

  • Utilice DriveGroups (consulte el Sección 13.4.3, “Adición de OSD mediante la especificación DriveGroups”) para crear una especificación de OSD que describa los dispositivos que se distribuirán en función de sus propiedades, como el tipo de dispositivo (SSD o HDD), el nombre de modelo del dispositivo, el tamaño o los nodos en los que existen los dispositivos. A continuación, aplique la especificación ejecutando el comando siguiente: 

    cephuser@adm > ceph orch apply osd -i drive_groups.yml

8.3.3 Distribución de servidores de metadatos

 

CephFS requiere uno o varios servicios de servidor de metadatos (MDS). Para crear un CephFS, primero cree servidores MDS aplicando la siguiente especificación:

Nota
Nota

Asegúrese de tener al menos dos repositorios creados, uno para los datos de CephFS y otro para los metadatos de CephFS, antes de aplicar la siguiente especificación. 

service_type: mds
service_id: CEPHFS_NAME
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3

Después de que los MDS sean funcionales, cree el CephFS: 

ceph fs new CEPHFS_NAME metadata_pool data_pool

8.3.4 Distribución de pasarelas Object Gateways

 

cephadm distribuye una pasarela Object Gateway como una colección de daemons que gestionan un dominio y una zona concretos.

Puede relacionar un servicio de Object Gateway con un dominio y una zona ya existentes (consulte el Sección 21.13, “Pasarelas Object Gateway de varios sitios” para obtener más información), o puede especificar un REALM_NAME y ZONE_NAME que no existan y se crearán automáticamente después de aplicar la siguiente configuración: 

service_type: rgw
service_id: REALM_NAME.ZONE_NAME
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
spec:
  rgw_realm: RGW_REALM
  rgw_zone: RGW_ZONE

8.3.4.1 Uso del acceso SSL seguro

 

Para utilizar una conexión SSL segura con Object Gateway, necesita un par de archivos de clave y certificado SSL válidos (consulte el Sección 21.7, “Habilitación de HTTPS/SSL para pasarelas Object Gateway” para obtener más información). Debe habilitar SSL, especificar un número de puerto para las conexiones SSL y especificar los archivos de certificado SSL y de clave.

Para habilitar SSL y especificar el número de puerto, incluya lo siguiente en la especificación: 

spec:
  ssl: true
  rgw_frontend_port: 443

Para especificar el certificado SSL y la clave, puede pegar su contenido directamente en el archivo de especificación YAML. El signo de barra vertical (|) al final de la línea indica al analizador que debe esperar una cadena de varias líneas como valor. Por ejemplo: 

spec:
  ssl: true
  rgw_frontend_port: 443
  rgw_frontend_ssl_certificate: |
   -----BEGIN CERTIFICATE-----
   MIIFmjCCA4KgAwIBAgIJAIZ2n35bmwXTMA0GCSqGSIb3DQEBCwUAMGIxCzAJBgNV
   BAYTAkFVMQwwCgYDVQQIDANOU1cxHTAbBgNVBAoMFEV4YW1wbGUgUkdXIFNTTCBp
   [...]
   -----END CERTIFICATE-----
   rgw_frontend_ssl_key: |
   -----BEGIN PRIVATE KEY-----
   MIIJRAIBADANBgkqhkiG9w0BAQEFAASCCS4wggkqAgEAAoICAQDLtFwg6LLl2j4Z
   BDV+iL4AO7VZ9KbmWIt37Ml2W6y2YeKX3Qwf+3eBz7TVHR1dm6iPpCpqpQjXUsT9
   [...]
   -----END PRIVATE KEY-----
Sugerencia
Sugerencia

En lugar de pegar el contenido del certificado SSL y los archivos de clave, puede omitir las palabras clave rgw_frontend_ssl_certificate: y rgw_frontend_ssl_key: y cargarlos en la base de datos de configuración 

cephuser@adm > ceph config-key set rgw/cert/REALM_NAME/ZONE_NAME.crt \
 -i SSL_CERT_FILE
cephuser@adm > ceph config-key set rgw/cert/REALM_NAME/ZONE_NAME.key \
 -i SSL_KEY_FILE
8.3.4.1.1 Configuración de Object Gateway para que escuche en los puertos 443 y 80
 

Si desea configurar Object Gateway para que escuche en los puertos 443 (HTTPS) y 80 (HTTP), siga estos pasos:

Nota
Nota

Los comandos del procedimiento utilizan el dominio y la zona default.

  1. Distribuya Object Gateway proporcionando un archivo de especificación. Consulte la Sección 8.3.4, “Distribución de pasarelas Object Gateways” para obtener más información sobre la especificación de Object Gateway. Utilice el comando siguiente: 

    cephuser@adm > ceph orch apply -i SPEC_FILE

  2. Si no se proporcionan certificados SSL en el archivo de especificación, añádalos mediante el siguiente comando: 

    cephuser@adm > ceph config-key set rgw/cert/default/default.crt -i certificate.pem
cephuser@adm > ceph config-key set rgw/cert/default/default.key -i key.pem

  3. Cambie el valor por defecto de la opción rgw_frontends: 

    cephuser@adm > ceph config set client.rgw.default.default rgw_frontends \
 "beast port=80 ssl_port=443"

  4. Elimine la configuración específica creada por cephadm. Identifique para qué destino se ha configurado la opción rgw_frontends ejecutando el comando: 

    cephuser@adm > ceph config dump | grep rgw

    Por ejemplo, el destino es client.rgw.default.default.node4.yiewdu. Elimine el valor rgw_frontends específico actual: 

    cephuser@adm > ceph config rm client.rgw.default.default.node4.yiewdu rgw_frontends
    Sugerencia
    Sugerencia

    En lugar de eliminar un valor para rgw_frontends, puede especificarlo. Por ejemplo: 

    cephuser@adm > ceph config set client.rgw.default.default.node4.yiewdu \
 rgw_frontends "beast port=80 ssl_port=443"

  5. Reinicie las instancias de Object Gateway: 

    cephuser@adm > ceph orch restart rgw.default.default

8.3.4.2 Distribución con un subclúster

 

Los subclústeres ayudan a organizar los nodos de los clústeres para aislar las cargas de trabajo y facilitar el escalado elástico. Si va a distribuir con un subclúster, aplique la siguiente configuración: 

service_type: rgw
service_id: REALM_NAME.ZONE_NAME.SUBCLUSTER
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
spec:
  rgw_realm: RGW_REALM
  rgw_zone: RGW_ZONE
  subcluster: SUBCLUSTER

8.3.5 Distribución de pasarelas iSCSI Gateway

 

cephadm distribuye una instancia de iSCSI Gateway, que es un protocolo de red de área de almacenamiento (SAN) que permite a los clientes (denominados iniciadores) enviar comandos SCSI a dispositivos de almacenamiento SCSI (destinos) en servidores remotos.

Aplique la siguiente configuración para la distribución. Asegúrese de que trusted_ip_list contiene las direcciones IP de todos los nodos de iSCSI Gateway y de Ceph Manager (consulte el resultado de ejemplo a continuación).

Nota
Nota

Asegúrese de crear el repositorio antes de aplicar la siguiente especificación. 

service_type: iscsi
service_id: EXAMPLE_ISCSI
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
spec:
  pool: EXAMPLE_POOL
  api_user: EXAMPLE_USER
  api_password: EXAMPLE_PASSWORD
  trusted_ip_list: "IP_ADDRESS_1,IP_ADDRESS_2"
Nota
Nota

Asegúrese de que las direcciones IP mostradas para trusted_ip_list no tienen un espacio después de la separación por comas.

8.3.5.1 Configuración SSL segura

 

Para utilizar una conexión SSL segura entre Ceph Dashboard y la API de destino iSCSI, necesita un par de archivos de clave y certificado SSL válidos. Estos pueden ser emitidos por una autoridad certificadora o autofirmados (consulte el Sección 10.1.1, “Creación de certificados autofirmados”). Para habilitar SSL, incluya el ajuste api_secure: true en el archivo de especificación: 

spec:
  api_secure: true

Para especificar el certificado SSL y la clave, puede pegar el contenido directamente en el archivo de especificación YAML. El signo de barra vertical (|) al final de la línea indica al analizador que debe esperar una cadena de varias líneas como valor. Por ejemplo: 

spec:
  pool: EXAMPLE_POOL
  api_user: EXAMPLE_USER
  api_password: EXAMPLE_PASSWORD
  trusted_ip_list: "IP_ADDRESS_1,IP_ADDRESS_2"
  api_secure: true
  ssl_cert: |
    -----BEGIN CERTIFICATE-----
    MIIDtTCCAp2gAwIBAgIYMC4xNzc1NDQxNjEzMzc2MjMyXzxvQ7EcMA0GCSqGSIb3
    DQEBCwUAMG0xCzAJBgNVBAYTAlVTMQ0wCwYDVQQIDARVdGFoMRcwFQYDVQQHDA5T
    [...]
    -----END CERTIFICATE-----
  ssl_key: |
    -----BEGIN PRIVATE KEY-----
    MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC5jdYbjtNTAKW4
    /CwQr/7wOiLGzVxChn3mmCIF3DwbL/qvTFTX2d8bDf6LjGwLYloXHscRfxszX/4h
    [...]
    -----END PRIVATE KEY-----

8.3.6 Distribución de NFS Ganesha

 
Importante
Importante

NFS Ganesha admite la versión 4.1 y posteriores de NFS. No es compatible con NFS versión 3.

cephadm distribuye NFS Ganesha mediante un repositorio RADOS predefinido y un espacio de nombres opcional. Para distribuir NFS Ganesha, aplique la siguiente especificación:

Nota
Nota

Debe tener un repositorio RADOS predefinido; de lo contrario, la operación ceph orch apply fallará. Para obtener más información sobre cómo crear un repositorio, consulte el Sección 18.1, “Creación de un repositorio”. 

service_type: nfs
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min1
  - ses-min2
spec:
  pool: EXAMPLE_POOL
  namespace: EXAMPLE_NAMESPACE

  • Sustituya EXAMPLE_NFS con una cadena arbitraria que identifique la exportación de NFS.

  • Sustituya EXAMPLE_POOL con el nombre del repositorio en el que se almacenará el objeto de configuración RADOS de NFS Ganesha.

  • Sustituya EXAMPLE_NAMESPACE (opcional) con el espacio de nombres NFS de Object Gateway deseado (por ejemplo, ganesha)

8.3.7 Distribuyendo rbd-mirror

 

El servicio rbd-mirror se encarga de sincronizar las imágenes del dispositivo de bloques RADOS entre dos clústeres de Ceph (para obtener más información, consulte el Sección 20.4, “Duplicados de imagen RBD”). Para distribuir rbd-mirror, utilice la siguiente especificación: 

service_type: rbd-mirror
service_id: EXAMPLE_RBD_MIRROR
placement:
  hosts:
  - ses-min3

8.3.8 Distribución de la pila de supervisión

 

La pila de supervisión está formada por Prometheus, los exportadores de Prometheus, Prometheus Alertmanager y Grafana. Ceph Dashboard utiliza estos componentes para almacenar y visualizar métricas detalladas sobre el uso y el rendimiento del clúster.

Sugerencia
Sugerencia

Si la distribución requiere imágenes de contenedor personalizadas o servidas localmente de los servicios de la pila de supervisión, consulte el Sección 16.1, “Configuración de imágenes personalizadas o locales”.

Para distribuir la pila de supervisión, siga estos pasos:

  1. Habilite el módulo prometheus en el daemon de Ceph Manager. Esto expone las métricas internas de Ceph para que Prometheus pueda leerlas: 

    cephuser@adm > ceph mgr module enable prometheus
    Nota
    Nota

    Asegúrese de que este comando se ejecuta antes de distribuir Prometheus. Si el comando no se ejecutó antes de la distribución, debe volver a distribuir Prometheus para actualizar la configuración de Prometheus: 

    cephuser@adm > ceph orch redeploy prometheus

  2. Cree un archivo de especificación (por ejemplo, monitoring.yaml) con un contenido similar al siguiente: 

    service_type: prometheus
placement:
  hosts:
  - ses-min2
---
service_type: node-exporter
---
service_type: alertmanager
placement:
  hosts:
  - ses-min4
---
service_type: grafana
placement:
  hosts:
  - ses-min3

  3. Aplique los servicios de supervisión ejecutando: 

    cephuser@adm > ceph orch apply -i monitoring.yaml

    La distribución de los servicios de supervisión puede tardar uno o dos minutos.

Importante
Importante

Prometheus, Grafana y Ceph Dashboard se configuran automáticamente para comunicarse entre sí, lo que da como resultado una integración totalmente funcional de Grafana en Ceph Dashboard cuando se distribuyen como se describe anteriormente.

La única excepción a esta regla es la supervisión con imágenes RBD. Consulte el Sección 16.5.4, “Habilitación de la supervisión de imágenes RBD” para obtener más información.