8 Distribución de los servicios principales restantes mediante cephadm #

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

cephuser@adm > ceph orch status

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

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

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

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:

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

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
[...]

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

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

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

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

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

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

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

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:

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

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

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

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

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

   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

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

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

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

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

spec:
  api_secure: true

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

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

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

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

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

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:

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.