13 Tareas operativas #

Para identificar los dispositivos de disco usados y sin usar en todos los nodos del clúster, muéstrelos ejecutando el comando siguiente:

cephuser@adm > ceph orch device ls
HOST       PATH      TYPE SIZE  DEVICE  AVAIL REJECT REASONS
ses-master /dev/vda  hdd  42.0G         False locked
ses-min1   /dev/vda  hdd  42.0G         False locked
ses-min1   /dev/vdb  hdd  8192M  387836 False locked, LVM detected, Insufficient space (<5GB) on vgs
ses-min2   /dev/vdc  hdd  8192M  450575 True

Para reutilizar un dispositivo de disco, primero debe borrarlo (comando zap):

ceph orch device zap HOST_NAME DISK_DEVICE

Por ejemplo:

cephuser@adm > ceph orch device zap ses-min2 /dev/vdc

Nota

Si ha distribuido previamente los OSD mediante DriveGroups o con la opción --all-available-devices sin que se haya definido el indicador unmanaged, cephadm distribuirá estos OSD automáticamente después de borrarlos.

DriveGroups especifica los diseños de los OSD del clúster de Ceph. Se definen en un único archivo YAML. En esta sección, utilizaremos drive_groups.yml como ejemplo.

Un administrador debe especificar manualmente un grupo de OSD que estén interrelacionados (OSD híbridos que se distribuyen en una mezcla de unidades HDD y SDD) o que compartan opciones de distribución 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. cephadm proporciona código que traduce esta especificación DriveGroups en listas de dispositivos reales para que el usuario las pueda inspeccionar.

El comando para aplicar la especificación de OSD al clúster es:

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

Para ver una vista previa de las acciones y probar la aplicación, puede utilizar la opción --dry-run junto con el comando ceph orch apply osd. Por ejemplo:

cephuser@adm > ceph orch apply osd -i drive_groups.yml --dry-run
...
+---------+------+------+----------+----+-----+
|SERVICE  |NAME  |HOST  |DATA      |DB  |WAL  |
+---------+------+------+----------+----+-----+
|osd      |test  |mgr0  |/dev/sda  |-   |-    |
|osd      |test  |mgr0  |/dev/sdb  |-   |-    |
+---------+------+------+----------+----+-----+

Si el resultado de --dry-run cumple sus expectativas, solo tiene que volver a ejecutar el comando sin la opción --dry-run.

13.4.3.1 OSD no gestionados #

 

Todos los dispositivos de disco limpios disponibles que coincidan con la especificación DriveGroups se utilizarán automáticamente como OSD después de añadirlos al clúster. Este comportamiento se denomina modo gestionado.

Para inhabilitar el modo gestionado, añada la línea unmanaged: true a las especificaciones relevantes, por ejemplo:

service_type: osd
service_id: example_drvgrp_name
placement:
 hosts:
 - ses-min2
 - ses-min3
encrypted: true
unmanaged: true

Sugerencia

Para cambiar los OSD ya distribuidos del modo gestionado al modo no gestionado, añada las líneas unmanaged: true cuando corresponda durante el procedimiento descrito en la Sección 13.1, “Modificación de la configuración del clúster”.

13.4.3.2 Especificación DriveGroups #

 

A continuación se muestra un ejemplo de archivo de especificación DriveGroups:

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
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)
encrypted: true       # 'True' or 'False' (defaults to 'False')

Nota

La opción denominada anteriormente "encryption" en DeepSea ahora se llama "encrypted". Al aplicar DriveGroups en SUSE Enterprise Storage 7, asegúrese de utilizar esta nueva terminología en la especificación del servicio; de lo contrario, la operación ceph orch apply fallará.

13.4.3.4 Filtrado de dispositivos por tamaño #

 

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 13.1: Filtrado por tamaño de disco #

 

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  size: '40TB:'
db_devices:
  size: ':2TB'

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: accesos directos a unidades

En lugar de gigabytes (G), puede especificar el tamaño en megabytes (M) o en terabytes (T).

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
db_devices:
  model: MC-55-44-XZ

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  rotational: 1
db_devices:
  rotational: 0

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  size: '2TB:'
db_devices:
  size: ':2TB'

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: MC-55-44-XZ

service_type: osd
service_id: example_drvgrp_name2
placement:
  host_pattern: '*'
data_devices:
  model: MC-55-44-XZ
db_devices:
  vendor: samsung
  size: 256GB

service_type: osd
service_id: example_drvgrp_one2five
placement:
  host_pattern: 'node[1-5]'
data_devices:
  rotational: 1
db_devices:
  rotational: 0

service_type: osd
service_id: example_drvgrp_rest
placement:
  host_pattern: 'node[6-10]'
data_devices:
  model: MC-55-44-XZ
db_devices:
  model: SSD-123-foo

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  model: MC-55-44-XZ
db_devices:
  model: SSD-123-foo
wal_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_hdd_nvme
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_hdd_ssd_nvme
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: MC-55-44-XZ
wal_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_ssd_nvme
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
db_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_standalone_encrypted
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
encrypted: True

Antes de eliminar un nodo de OSD del clúster, verifique que el clúster tiene más espacio libre en disco que el disco del OSD que va a eliminar. Tenga en cuenta que, si se elimina un OSD, todo el clúster se reequilibra.

cephuser@adm > ceph orch osd rm stop OSD_SERVICE_ID

Puede haber varios motivos para que sea necesario reemplazar un disco OSD. Por ejemplo:

Para sustituir un OSD conservando su ID, ejecute:

cephuser@adm > ceph orch osd rm OSD_SERVICE_ID --replace

Por ejemplo:

cephuser@adm > ceph orch osd rm 4 --replace

Sustituir un OSD es igual que eliminar un OSD (consulte la Sección 13.4.4, “Eliminación de OSD” para obtener más información), con la excepción de que el OSD no se elimina permanentemente de la jerarquía de CRUSH y se le asigna un indicador destroyed.

El indicador destroyed se utiliza para determinar los ID de OSD que se reutilizarán durante la siguiente distribución de OSD. A los discos recién añadidos que coincidan con la especificación DriveGroups (consulte la Sección 13.4.3, “Adición de OSD mediante la especificación DriveGroups” para obtener más información) se les asignarán los ID de OSD de su equivalente sustituido.

Sugerencia

Al añadir la opción --dry-run no se ejecutará la sustitución real, pero se mostrarán los pasos que se llevarían a cabo normalmente.

Nota

Si va a sustituir un OSD después de un fallo, se recomienda encarecidamente activar un borrado profundo de los grupos de colocación. Consulte la Sección 17.6, “Depuración de grupos de colocación” para obtener más información.

Ejecute el siguiente comando para iniciar un borrado profundo:

cephuser@adm > ceph osd deep-scrub osd.OSD_NUMBER

Importante: fallo del dispositivo compartido

Si falla un dispositivo compartido para DB/WAL, deberá realizar el procedimiento de sustitución para todos los OSD que compartan el dispositivo que ha fallado.

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

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

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

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

Para actualizar los paquetes de software de todos los nodos del clúster a la versión más reciente, ejecute el comando siguiente:

root@master # ceph-salt update

Antes de iniciar la actualización, compruebe que todos los nodos están en línea y que el clúster funciona correctamente:

cephuser@adm > cephadm shell -- ceph -s

Para actualizar a una versión de Ceph específica:

cephuser@adm > ceph orch upgrade start --image REGISTRY_URL

Por ejemplo:

cephuser@adm > ceph orch upgrade start --image registry.suse.com/ses/7.1/ceph/ceph:latest

Actualice los paquetes en los hosts:

cephuser@adm > ceph-salt update

Ejecute el comando siguiente para determinar si hay una actualización en curso:

cephuser@adm > ceph orch upgrade status

Mientras la actualización está en curso, verá una barra de progreso en el estado de Ceph:

cephuser@adm > ceph -s
[...]
  progress:
    Upgrade to registry.suse.com/ses/7.1/ceph/ceph:latest (00h 20m 12s)
      [=======.....................] (time remaining: 01h 43m 31s)

También puede ver el registro de cephadm:

cephuser@adm > ceph -W cephadm

Puede detener el proceso de actualización en cualquier momento:

cephuser@adm > ceph orch upgrade stop