13 Tareas operativas #
13.1 Modificación de la configuración del clúster #
Para modificar la configuración de un clúster de Ceph existente, siga estos pasos:
Exporte la configuración actual del clúster a un archivo:
cephuser@adm >
ceph orch ls --export --format yaml > cluster.yamlEdite el archivo con la configuración y actualice las líneas pertinentes. Encontrará ejemplos de especificaciones en el Sección 5.4, “Distribución de servicios y pasarelas” y en la Sección 13.4.3, “Adición de OSD mediante la especificación DriveGroups”.
Aplique la nueva configuración:
cephuser@adm >
ceph orch apply -i cluster.yaml
13.2 Adición de nodos #
Para añadir un nodo nuevo a un clúster de Ceph, siga estos pasos:
Instale SUSE Linux Enterprise Server y SUSE Enterprise Storage en el nuevo host. Consulte el Sección 5.1, “Instalación y configuración de SUSE Linux Enterprise Server” para obtener más información.
Configure el host como un minion de Salt de un master de Salt ya existente. Consulte el Sección 5.2, “Distribución de Salt” para obtener más información.
Añada el nuevo host a
ceph-salt
y haga que cephadm lo reconozca, por ejemplo:root@master #
ceph-salt config /ceph_cluster/minions add ses-min5.example.comroot@master #
ceph-salt config /ceph_cluster/roles/cephadm add ses-min5.example.comConsulte el Sección 5.3.2.2, “Adición de minions de Salt” para obtener más información.
Verifique que el nodo se ha añadido a
ceph-salt
:root@master #
ceph-salt config /ceph_cluster/minions ls o- minions ................................................. [Minions: 5] [...] o- ses-min5.example.com .................................... [no roles]Aplique la configuración al nuevo host del clúster:
root@master #
ceph-salt apply ses-min5.example.comVerifique que el host recién añadido pertenece ahora al entorno de cephadm:
cephuser@adm >
ceph orch host ls HOST ADDR LABELS STATUS [...] ses-min5.example.com ses-min5.example.com
13.3 Eliminación de nodos #
Si el nodo que va a eliminar ejecuta OSD, elimínelos primero y compruebe que no hay ningún OSD en ejecución en ese nodo. Consulte la Sección 13.4.4, “Eliminación de OSD” para obtener más información sobre la eliminación de OSD.
Para eliminar un nodo de un clúster, haga lo siguiente:
Para todos los tipos de servicio de Ceph, excepto
node-exporter
ycrash
, elimine el nombre de host del nodo del archivo de especificación de colocación del clúster (por ejemplo,cluster.yml
). Consulte Sección 5.4.2, “Especificación del servicio y la colocación” para obtener más información. Por ejemplo, si va a eliminar el host denominadoses-min2
, elimine todas las apariciones de- ses-min2
de todas las seccionesplacement:
.Actualice
service_type: rgw service_id: EXAMPLE_NFS placement: hosts: - ses-min2 - ses-min3
a
service_type: rgw service_id: EXAMPLE_NFS placement: hosts: - ses-min3
Aplique los cambios al archivo de configuración:
cephuser@adm >
ceph orch apply -i rgw-example.yamlElimine el nodo del entorno de cephadm:
cephuser@adm >
ceph orch host rm ses-min2Si el nodo ejecuta los servicios
crash.osd.1
ycrash.osd.2
, elimínelos ejecutando el siguiente comando en el host:root@minion >
cephadm rm-daemon --fsid CLUSTER_ID --name SERVICE_NAMEPor ejemplo:
root@minion >
cephadm rm-daemon --fsid b4b30c6e... --name crash.osd.1root@minion >
cephadm rm-daemon --fsid b4b30c6e... --name crash.osd.2Elimine todas las funciones del minion que desee suprimir:
cephuser@adm >
ceph-salt config /ceph_cluster/roles/tuned/throughput remove ses-min2cephuser@adm >
ceph-salt config /ceph_cluster/roles/tuned/latency remove ses-min2cephuser@adm >
ceph-salt config /ceph_cluster/roles/cephadm remove ses-min2cephuser@adm >
ceph-salt config /ceph_cluster/roles/admin remove ses-min2Si el minion que desea suprimir es el minion de arranque, también debe eliminar la función bootstrap:
cephuser@adm >
ceph-salt config /ceph_cluster/roles/bootstrap resetDespués de eliminar todos los OSD de un solo host, elimine el host del mapa de CRUSH:
cephuser@adm >
ceph osd crush remove bucket-nameNotaEl nombre del depósito debe ser el mismo que el nombre del host.
Ahora puede eliminar el minion del clúster:
cephuser@adm >
ceph-salt config /ceph_cluster/minions remove ses-min2
En caso de que se produzca un fallo y el minion que está intentando eliminar se encuentre apagado permanentemente, deberá eliminar el nodo del master de Salt:
root@master #
salt-key -d minion_id
A continuación, elimine manualmente el nodo de raíz_pilar/ceph-salt.sls
. Normalmente se encuentra en /srv/pillar/ceph-salt.sls
.
13.4 Gestión de OSD #
En esta sección se describe cómo añadir, borrar o eliminar OSD en un clúster de Ceph.
13.4.1 Listado de dispositivos de disco #
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
13.4.2 Borrado de dispositivos de disco #
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
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.
13.4.3 Adición de OSD mediante la especificación DriveGroups #
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 -idrive_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 -idrive_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
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')
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.3 Filtrado de dispositivos de disco #
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
SugerenciaEscriba siempre DISK_VENDOR_STRING en minúsculas.
Para obtener detalles sobre el modelo de disco y el proveedor, examine el resultado del siguiente comando:
cephuser@adm >
ceph orch device ls HOST PATH TYPE SIZE DEVICE_ID MODEL VENDOR ses-min1 /dev/sdb ssd 29.8G SATA_SSD_AF34075704240015 SATA SSD ATA ses-min2 /dev/sda ssd 223G Micron_5200_MTFDDAK240TDN Micron_5200_MTFD ATA [...]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
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.
service_type: osd service_id: example_drvgrp_name placement: host_pattern: '*' data_devices: size: '40TB:' db_devices: size: ':2TB'
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.
En lugar de gigabytes (G), puede especificar el tamaño en megabytes (M) o en terabytes (T).
13.4.3.5 Ejemplos de DriveGroups #
Esta sección incluye ejemplos de diferentes configuraciones de OSD.
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:
service_type: osd service_id: example_drvgrp_name placement: host_pattern: '*' 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:
service_type: osd service_id: example_drvgrp_name placement: host_pattern: '*' 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:
service_type: osd service_id: example_drvgrp_name placement: host_pattern: '*' data_devices: size: '2TB:' db_devices: size: ':2TB'
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:
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
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:
service_type: osd service_id: example_drvgrp_one2five placement: host_pattern: 'node[1-5]' data_devices: rotational: 1 db_devices: rotational: 0
seguido de
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
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
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
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:
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
Se conservará un disco duro porque el archivo se está analizando de arriba abajo.
13.4.4 Eliminación de OSD #
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.
Identifique qué OSD desea eliminar obteniendo su ID:
cephuser@adm >
ceph orch ps --daemon_type osd NAME HOST STATUS REFRESHED AGE VERSION osd.0 target-ses-090 running (3h) 7m ago 3h 15.2.7.689 ... osd.1 target-ses-090 running (3h) 7m ago 3h 15.2.7.689 ... osd.2 target-ses-090 running (3h) 7m ago 3h 15.2.7.689 ... osd.3 target-ses-090 running (3h) 7m ago 3h 15.2.7.689 ...Elimine uno o varios OSD del clúster:
cephuser@adm >
ceph orch osd rm OSD1_ID OSD2_ID ...Por ejemplo:
cephuser@adm >
ceph orch osd rm 1 2Puede consultar el estado de la operación de eliminación:
cephuser@adm >
ceph orch osd rm status OSD_ID HOST STATE PG_COUNT REPLACE FORCE STARTED_AT 2 cephadm-dev done, waiting for purge 0 True False 2020-07-17 13:01:43.147684 3 cephadm-dev draining 17 False True 2020-07-17 13:01:45.162158 4 cephadm-dev started 42 False True 2020-07-17 13:01:45.162158
13.4.4.1 Detención de la eliminación de OSD #
Después de programar la eliminación de un OSD, puede detener la eliminación si es necesario. El siguiente comando restablecerá el estado inicial del OSD y lo eliminará de la cola:
cephuser@adm >
ceph orch osd rm stop OSD_SERVICE_ID
13.4.5 Sustitución de OSD #
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.
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.
13.5 Traslado del master de Salt a un nodo nuevo #
Si necesita sustituir el host del master de Salt por uno nuevo, siga estos pasos:
Exporte la configuración del clúster y realice una copia de seguridad del archivo JSON exportado. Más detalles en el Sección 5.3.2.15, “Exportación de configuraciones de clúster”
Si el master de Salt antiguo es también el único nodo de administración del clúster, traslade manualmente
/etc/ceph/ceph.client.admin.keyring
y/etc/ceph/ceph.conf
al nuevo master de Salt.Detenga e inhabilite el servicio
systemd
del master de Salt en el nodo del master de Salt antiguo:root@master #
systemctl stop salt-master.serviceroot@master #
systemctl disable salt-master.serviceSi el nodo del master de Salt antiguo ya no está en el clúster, detenga e inhabilite también el servicio
systemd
del minion de Salt:root@master #
systemctl stop salt-minion.serviceroot@master #
systemctl disable salt-minion.serviceAvisono detenga ni inhabilite
salt-minion.service
si el nodo del master de Salt antiguo tiene algún daemon de Ceph (MON, MGR, OSD, MDS, pasarela, supervisión) en ejecución.Instale SUSE Linux Enterprise Server 15 SP2 en el nuevo master de Salt siguiendo el procedimiento descrito en el Sección 5.1, “Instalación y configuración de SUSE Linux Enterprise Server”.
Sugerencia: transición de los minions de SaltPara simplificar la transición de los minions de Salt al nuevo master de Salt, elimine la clave pública del master de Salt original de cada minion:
root@minion >
rm /etc/salt/pki/minion/minion_master.pubroot@minion >
systemctl restart salt-minion.serviceInstale el paquete salt-master y, si procede, el paquete salt-minion en el nuevo master de Salt.
Instale
ceph-salt
en el nuevo nodo del master de Salt:root@master #
zypper install ceph-saltroot@master #
systemctl restart salt-master.serviceroot@master #
salt '*' saltutil.sync_allImportanteAsegúrese de ejecutar los tres comandos antes de continuar. Los comandos son idempotentes; no importa si se repiten.
Incluya el nuevo master de Salt en el clúster, como se describe en el Sección 5.3.1, “Instalación de
ceph-salt
”, el Sección 5.3.2.2, “Adición de minions de Salt” y el Sección 5.3.2.4, “Especificación del nodo de administración”.Importe la copia de seguridad de la configuración del clúster y aplíquela:
root@master #
ceph-salt import CLUSTER_CONFIG.jsonroot@master #
ceph-salt applyImportanteCambie el nombre del minion del master de Salt
minion id
del archivoCLUSTER_CONFIG.json
exportado antes de importarlo.
13.6 Actualización de los nodos del clúster #
Para mantener actualizados los nodos del clúster de Ceph, aplique actualizaciones periódicas.
13.6.1 Repositorios de software #
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 7.1.5.1, “Repositorios de software” para obtener una lista completa de los repositorios necesarios.
13.6.2 División en etapas del repositorio #
Si utiliza una herramienta de división en etapas (por ejemplo, SUSE Manager, o la herramienta de gestión de repositorios 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.
13.6.3 Tiempo de inactividad de servicios de Ceph #
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.
13.6.4 Ejecución de la actualización #
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
13.7 Actualización de Ceph #
Puede indicar a cephadm que actualice Ceph a partir de una versión de corrección de errores a otra. La actualización automatizada de los servicios de Ceph respeta el orden recomendado: comienza con Ceph Managers, después Ceph Monitors y continúa con otros servicios como Ceph OSD, servidores de metadatos y Object Gateways. Cada daemon solo se reinicia después de que Ceph indique que el clúster seguirá estando disponible.
El siguiente procedimiento de actualización utiliza el comando ceph orch upgrade
. Tenga en cuenta que las instrucciones siguientes detallan cómo actualizar el clúster de Ceph con una versión de producto (por ejemplo, una actualización de mantenimiento), pero no proporcionan instrucciones sobre cómo actualizar el clúster de una versión de producto a otra.
13.7.1 Inicio de la actualización #
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/ceph/ceph:latest
Actualice los paquetes en los hosts:
cephuser@adm >
ceph-salt update
13.7.2 Supervisión de la actualización #
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/ceph/ceph:latest (00h 20m 12s)
[=======.....................] (time remaining: 01h 43m 31s)
También puede ver el registro de cephadm:
cephuser@adm >
ceph -W cephadm
13.7.3 Cancelación de una actualización #
Puede detener el proceso de actualización en cualquier momento:
cephuser@adm >
ceph orch upgrade stop
13.8 Detención o reinicio del clúster #
En algunos casos, puede ser necesario detener o reiniciar el clúster completo. Recomendamos comprobar atentamente las dependencias de los servicios en ejecución. Los siguientes pasos se pueden usar como esquema de inicio y detención del clúster:
Indique al clúster de Ceph que no marque los OSD como "out":
cephuser@adm >
ceph
osd set nooutDetenga los daemons y los nodos en el siguiente orden:
Clientes de almacenamiento
Gateways, por ejemplo, NFS Ganesha u Object Gateway
Servidor de metadatos
Ceph OSD
Ceph Manager
Ceph Monitor
Si es necesario, realice las tareas de mantenimiento.
Inicie los nodos y los servidores en el orden inverso al del proceso de apagado:
Ceph Monitor
Ceph Manager
Ceph OSD
Servidor de metadatos
Gateways, por ejemplo, NFS Ganesha u Object Gateway
Clientes de almacenamiento
Elimine el indicador de noout:
cephuser@adm >
ceph
osd unset noout
13.9 Eliminación de un clúster de Ceph completo #
El comando ceph-salt purge
elimina todo el clúster de Ceph. Si hay más clústeres de Ceph distribuidos, se limpia el notificado por ceph -s
. De esta manera, puede limpiar el entorno del clúster cuando pruebe diferentes configuraciones.
Para evitar la supresión accidental, la orquestación comprueba si la seguridad está desactivada. Puede desactivar las medidas de seguridad y eliminar el clúster de Ceph ejecutando:
root@master #
ceph-salt disengage-safetyroot@master #
ceph-salt purge