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 7

13 Tareas operativas Edit source

13.1 Modificación de la configuración del clúster Edit source

Para modificar la configuración de un clúster de Ceph existente, siga estos pasos:

  1. Exporte la configuración actual del clúster a un archivo:

    cephuser@adm > ceph orch ls --export --format yaml > cluster.yaml
  2. Edite 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”.

  3. Aplique la nueva configuración:

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

13.2 Adición de nodos Edit source

Para añadir un nodo nuevo a un clúster de Ceph, siga estos pasos:

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

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

  3. 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.com
    root@master # ceph-salt config /ceph_cluster/roles/cephadm add ses-min5.example.com

    Consulte el Sección 5.3.2.2, “Adición de minions de Salt” para obtener más información.

  4. 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]
  5. Aplique la configuración al nuevo host del clúster:

    root@master # ceph-salt apply ses-min5.example.com
  6. Verifique 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 Edit source

Sugerencia
Sugerencia: eliminación de OSD

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:

  1. Para todos los tipos de servicio de Ceph, excepto node-exporter y crash, 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 denominado ses-min2, elimine todas las apariciones de - ses-min2 de todas las secciones placement:.

    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.yaml
  2. Elimine el nodo del entorno de cephadm:

    cephuser@adm > ceph orch host rm ses-min2
  3. Si el nodo ejecuta los servicios crash.osd.1 y crash.osd.2, elimínelos ejecutando el siguiente comando en el host:

    root@minion > cephadm rm-daemon --fsid CLUSTER_ID --name SERVICE_NAME

    Por ejemplo:

    root@minion > cephadm rm-daemon --fsid b4b30c6e... --name crash.osd.1
    root@minion > cephadm rm-daemon --fsid b4b30c6e... --name crash.osd.2
  4. Elimine todas las funciones del minion que desee suprimir:

    cephuser@adm > ceph-salt config /ceph_cluster/roles/tuned/throughput remove ses-min2
    cephuser@adm > ceph-salt config /ceph_cluster/roles/tuned/latency remove ses-min2
    cephuser@adm > ceph-salt config /ceph_cluster/roles/cephadm remove ses-min2
    cephuser@adm > ceph-salt config /ceph_cluster/roles/admin remove ses-min2

    Si 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 reset
  5. Después de eliminar todos los OSD de un solo host, elimine el host del mapa de CRUSH:

    cephuser@adm > ceph osd crush remove bucket-name
    Nota
    Nota

    El nombre del depósito debe ser el mismo que el nombre del host.

  6. Ahora puede eliminar el minion del clúster:

    cephuser@adm > ceph-salt config /ceph_cluster/minions remove ses-min2
Importante
Importante

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

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

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

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

13.4.3 Adición de OSD mediante la especificación DriveGroups Edit source

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

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

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
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.3 Filtrado de dispositivos de disco Edit source

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

    Escriba 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 Edit source

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

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

13.4.3.5 Ejemplos de DriveGroups Edit source

Esta sección incluye ejemplos de diferentes configuraciones de OSD.

Ejemplo 13.2: configuración sencilla

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'
Ejemplo 13.3: configuración avanzada

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
Ejemplo 13.4: configuración avanzada con nodos no uniformes

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
Ejemplo 13.5: configuración para expertos

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
Ejemplo 13.6: configuración compleja (e improbable)

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

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.

  1. 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 ...
  2. 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 2
  3. Puede 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 Edit source

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

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

13.5 Traslado del master de Salt a un nodo nuevo Edit source

Si necesita sustituir el host del master de Salt por uno nuevo, siga estos pasos:

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

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

  3. Detenga e inhabilite el servicio systemd del master de Salt en el nodo del master de Salt antiguo:

    root@master # systemctl stop salt-master.service
    root@master # systemctl disable salt-master.service
  4. Si 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.service
    root@master # systemctl disable salt-minion.service
    Aviso
    Aviso

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

  5. 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
    Sugerencia: transición de los minions de Salt

    Para 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.pub
    root@minion > systemctl restart salt-minion.service
  6. Instale el paquete salt-master y, si procede, el paquete salt-minion en el nuevo master de Salt.

  7. Instale ceph-salt en el nuevo nodo del master de Salt:

    root@master # zypper install ceph-salt
    root@master # systemctl restart salt-master.service
    root@master # salt '*' saltutil.sync_all
    Importante
    Importante

    Asegúrese de ejecutar los tres comandos antes de continuar. Los comandos son idempotentes; no importa si se repiten.

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

  9. Importe la copia de seguridad de la configuración del clúster y aplíquela:

    root@master # ceph-salt import CLUSTER_CONFIG.json
    root@master # ceph-salt apply
    Importante
    Importante

    Cambie el nombre del minion del master de Salt minion id del archivo CLUSTER_CONFIG.json exportado antes de importarlo.

13.6 Actualización de los nodos del clúster Edit source

Para mantener actualizados los nodos del clúster de Ceph, aplique actualizaciones periódicas.

13.6.1 Repositorios de software Edit source

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

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

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

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

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.

Nota
Nota

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

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

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

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

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:

  1. Indique al clúster de Ceph que no marque los OSD como "out":

    cephuser@adm > ceph osd set noout
  2. Detenga los daemons y los nodos en el siguiente orden:

    1. Clientes de almacenamiento

    2. Gateways, por ejemplo, NFS Ganesha u Object Gateway

    3. Servidor de metadatos

    4. Ceph OSD

    5. Ceph Manager

    6. Ceph Monitor

  3. Si es necesario, realice las tareas de mantenimiento.

  4. Inicie los nodos y los servidores en el orden inverso al del proceso de apagado:

    1. Ceph Monitor

    2. Ceph Manager

    3. Ceph OSD

    4. Servidor de metadatos

    5. Gateways, por ejemplo, NFS Ganesha u Object Gateway

    6. Clientes de almacenamiento

  5. Elimine el indicador de noout:

    cephuser@adm > ceph osd unset noout

13.9 Eliminación de un clúster de Ceph completo Edit source

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-safety
root@master # ceph-salt purge
Imprimir esta página