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 6

6 Actualización desde versiones anteriores Edit source

En este capítulo se presentan los pasos necesarios para actualizar SUSE Enterprise Storage 5.5 a la versión 6. Tenga en cuenta que la versión 5.5 es básicamente la 5 con todos los parches más recientes aplicados.

Nota
Nota: actualización desde versiones anteriores no admitidas

No se admite la actualización desde versiones de SUSE Enterprise Storage anteriores a la 5.5. En primer lugar, debe actualizar a la versión más reciente de SUSE Enterprise Storage 5.5 y, a continuación, siga los pasos de este capítulo.

6.1 Puntos que se deben tener en cuenta antes de la actualización Edit source

  • Lea las notas de la versión. En ellas encontrará información adicional sobre los cambios realizados desde la versión previa de SUSE Enterprise Storage. Consulte las notas de versión para comprobar lo siguiente:

    • si el hardware necesita consideraciones especiales,

    • si los paquetes de software usados han cambiado de forma significativa,

    • si es necesario tomar precauciones especiales para la instalación.

    Las notas de la versión también proporcionan información que no pudo publicarse en el manual a tiempo y notas acerca de problemas conocidos.

    Después de instalar el paquete release-notes-ses, encontrará las notas de la versión en el directorio /usr/share/doc/release-notes o en línea en https://www.suse.com/releasenotes/.

  • En caso de que haya actualizado previamente desde la versión 4, compruebe que la actualización a la versión 5 se haya completado correctamente:

    • Compruebe que el archivo exista:

      /srv/salt/ceph/configuration/files/ceph.conf.import

      Es creado por el proceso de importación durante la actualización de SES 4 a SES 5. Además, la opción configuration_init: default-import se define en el archivo

      /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml

      Si configuration_init todavía está definido como default-import, el clúster está utilizando ceph.conf.import como su archivo de configuración y no el archivo ceph.conf por defecto de DeepSea que se compila a partir de los archivos de:

      /srv/salt/ceph/configuration/files/ceph.conf.d/

      Por lo tanto, debe inspeccionar si hay alguna configuración personalizada en ceph.conf.import y, posiblemente, trasladar la configuración a uno de los archivos de:

      /srv/salt/ceph/configuration/files/ceph.conf.d/

      A continuación, elimine la línea configuration_init: default‑import de:

      /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml
      Aviso
      Aviso: configuración por defecto de DeepSea

      Si no combina la configuración de ceph.conf.import y elimina la opción configuration_init: default‑import, no se aplicará al clúster ningún valor de configuración por defecto que hayamos enviado como parte de DeepSea (almacenado en /srv/salt/ceph/configuration/files/ceph.conf.j2).

    • Compruebe si el clúster utiliza el nuevo tipo de depósito "straw2":

      cephadm@adm > ceph osd crush dump | grep straw
    • Compruebe que se utiliza el perfil de Ceph "jewel":

      cephadm@adm > ceph osd crush dump | grep profile
  • En caso de que se utilicen clientes de kernel del RBD antiguos (anteriores a SUSE Linux Enterprise Server 12 SP3), consulte Sección 12.9, “Asignación del RBD utilizando clientes de kernel antiguos”. Se recomienda actualizar los clientes del kernel del RBD antiguo, si es posible.

  • Si openATTIC se encuentra en el nodo de administración, no estará disponible después de actualizar el nodo. La nueva Ceph Dashboard no estará disponible hasta que la distribuya mediante DeepSea.

  • La actualización del clúster puede tardar mucho tiempo, aproximadamente el que se tarda en actualizar un equipo multiplicado por el número de nodos del clúster.

  • No es posible actualizar un solo nodo mientras se ejecuta la versión anterior de SUSE Linux Enterprise Server: debe reiniciarse en el programa de instalación de la nueva versión. Por lo tanto, los servicios que proporciona el nodo no estarán disponibles durante un tiempo. Los servicios de clúster principales seguirán estando disponibles; por ejemplo, si una instancia de MON está inactiva durante la actualización, seguirá habiendo al menos dos activas. Desafortunadamente, los servicios de una sola instancia, como una única pasarela iSCSI Gateway, no estarán disponibles.

  • Algunos tipos de daemons dependen de otros. Por ejemplo, los daemons de Object Gateway dependen de los daemons de Ceph MON y OSD. Se recomienda actualizar en este orden:

    1. Nodo de administración

    2. Ceph Monitor/Ceph Manager

    3. Servidores de metadatos

    4. Daemons Ceph OSD

    5. Pasarelas Object Gateway

    6. Pasarelas iSCSI Gateway

    7. NFS Ganesha

    8. Pasarelas Samba Gateway

  • Si ha usado AppArmor en el modo "complain" o "enforce", debe establecer una variable de pilar de Salt antes de actualizar. Dado que SUSE Linux Enterprise Server 15 SP1 se suministra con AppArmor por defecto, la gestión de AppArmor se ha integrado en la fase 0 de DeepSea. El comportamiento por defecto en SUSE Enterprise Storage 6 es eliminar AppArmor y los perfiles relacionados. Si desea conservar el comportamiento configurado en SUSE Enterprise Storage 5.5, compruebe que haya una de las siguientes líneas presente en el archivo /srv/pillar/ceph/stack/global.yml antes de iniciar la actualización:

    apparmor_init: default-enforce

    O bien

    apparmor_init: default-complain
  • Desde SUSE Enterprise Storage 6, los nombres del MDS que comienzan con un dígito ya no se permiten y los daemons del MDS no se iniciarán. Puede comprobar si los daemons tienen este tipo de nombre ejecutando el comando ceph fs status o reiniciando un MDS y buscando en sus registros el siguiente mensaje:

    deprecation warning: MDS id 'mds.1mon1' is invalid and will be forbidden in
    a future version.  MDS names may not start with a numeric digit.

    Si ve el mensaje anterior, los nombres del MDS deben migrarse antes de intentar actualizar a SUSE Enterprise Storage 6. DeepSea proporciona orquestación para automatizar dicha migración. A los nombres del MDS que comiencen con un dígito se les añadirá "mds." al principio:

    root@master # salt-run state.orch ceph.mds.migrate-numerical-names
    Sugerencia
    Sugerencia: configuración personalizada vinculada a nombres del MDS

    Si tiene valores de configuración vinculados a nombres del MDS y los daemons del MDS tienen nombres que comienzan con un dígito, verifique que los valores de configuración también se aplique a los nuevos nombres (con el prefijo "mds." ). Observe la siguiente sección de ejemplo del archivo /etc/ceph/ceph.conf:

    [mds.123-my-mds] # config setting specific to MDS name with a name starting with a digit
    mds cache memory limit = 1073741824
    mds standby for name = 456-another-mds

    El orquestador ceph.mds.migrate-numerical-names cambiará el nombre del daemon del MDS "123-my-mds" a "mds.123-my-mds". Es necesario ajustar la configuración para reflejar el nuevo nombre:

    [mds.mds,123-my-mds] # config setting specific to MDS name with the new name
    mds cache memory limit = 1073741824
    mds standby for name = mds.456-another-mds

    Esto añadirá daemons del MDS con los nuevos nombres antes de eliminar los antiguos. El número de daemons del MDS se duplicará durante un breve periodo de tiempo. Los clientes podrán acceder a CephFS tras una breve pausa para el failover. Por lo tanto, planifique la migración en horas en las que espere poca o ninguna carga de CephFS.

6.2 Copia de seguridad de los datos del clúster Edit source

Aunque la creación de copias de seguridad de la configuración y los datos de un clúster no es obligatoria, se recomienda encarecidamente realizarla. Consulte Capítulo 3, Copia de seguridad de la configuración y los datos del clúster para obtener más información.

6.3 Migración de ntpd a chronyd Edit source

SUSE Linux Enterprise Server 15 SP1 ya no utiliza ntpd para sincronizar la hora del host local. En su lugar, se utiliza chronyd. Debe migrar el daemon de sincronización de hora en cada nodo del clúster. Puede migrar a chronyd antes que el clúster o actualizar el clúster y migrar a chronyd después.

Procedimiento 6.1: Migración a chronyd antes de la actualización del clúster
  1. Instale el paquete chrony:

    root@minion > zypper install chrony
  2. Edite el archivo de configuración chronyd /etc/chrony.conf y añada orígenes NTP desde la configuración ntpd actual en /etc/ntp.conf.

    Sugerencia
    Sugerencia: más detalles sobre la configuración de chronyd

    En https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-ntp.html encontrará más detalles sobre cómo incluir las fuentes de hora en la configuración de chronyd.

  3. Inhabilite y detenga el servicio ntpd:

    root@minion > systemctl disable ntpd.service && systemctl stop ntpd.service
  4. Inicie y habilite el servicio chronyd:

    root@minion > systemctl start chronyd.service && systemctl enable chronyd.service
  5. Verifique el estado de chrony:

    root@minion > chronyc tracking
Procedimiento 6.2: Migración a chronyd después de la actualización del clúster
  1. Durante la actualización del clúster, añada los siguientes repositorios de software:

    • SLE-Module-Legacy15-SP1-Pool

    • SLE-Module-Legacy15-SP1-Updates

  2. Actualice el clúster a la versión 6.

  3. Edite el archivo de configuración chronyd /etc/chrony.conf y añada orígenes NTP desde la configuración ntpd actual en /etc/ntp.conf.

    Sugerencia
    Sugerencia: más detalles sobre la configuración de chronyd

    En https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-ntp.html encontrará más detalles sobre cómo incluir las fuentes de hora en la configuración de chronyd.

  4. Inhabilite y detenga el servicio ntpd:

    root@minion > systemctl disable ntpd.service && systemctl stop ntpd.service
  5. Inicie y habilite el servicio chronyd:

    root@minion > systemctl start chronyd.service && systemctl enable chronyd.service
  6. Migre de ntpd a chronyd.

  7. Verifique el estado de chrony:

    root@minion > chronyc tracking
  8. Elimine los repositorios de software heredados que agregó para mantener ntpd en el sistema durante el proceso de actualización.

6.4 Aplicación de parches al clúster antes de la actualización Edit source

Aplique los parches más recientes a todos los nodos del clúster antes de la actualización.

6.4.1 Repositorios de software requeridos Edit source

Compruebe que los repositorios necesarios están configurados en todos los nodos del clúster. Para mostrar todos los repositorios disponibles, ejecute:

root@minion > zypper lr

SUSE Enterprise Storage 5.5 requiere:

  • SLES12-SP3-Installer-Updates

  • SLES12-SP3-Pool

  • SLES12-SP3-Updates

  • SUSE-Enterprise-Storage-5-Pool

  • SUSE-Enterprise-Storage-5-Updates

NFS/SMB Gateway en SLE-HA en SUSE Linux Enterprise Server 12 SP3 requiere lo siguiente:

  • SLE-HA12-SP3-Pool

  • SLE-HA12-SP3-Updates

6.4.2 Sistemas de fases de repositorio Edit source

Si utiliza un sistemas de fases de repositorio (SMT, RMT o SUSE Manager), cree un nuevo nivel de parche inmovilizado para la versión actual y la versión nueva de SUSE Enterprise Storage.

Encontrará más información en:

6.4.3 Aplicación de los parches más recientes a todo el clúster Edit source

  1. Aplique los parches más recientes de SUSE Enterprise Storage 5.5 y SUSE Linux Enterprise Server 12 SP3 a todos los nodos del clúster de Ceph. Verifique que se han conectado los repositorios de software correctos a cada nodo del clúster (consulte la Sección 6.4.1, “Repositorios de software requeridos”) y ejecute la fase 0 de DeepSea:

    root@master # salt-run state.orch ceph.stage.0
  2. Después de completar la fase 0, verifique que el estado de cada nodo del clúster incluya "HEALTH_OK". Si no es así, resuelva el problema antes de que se produzcan los posibles reinicios en los pasos siguientes.

  3. Ejecute zypper ps para comprobar si hay procesos que podría ejecutar con bibliotecas o archivos binarios obsoletos y reinicie si los hay.

  4. Verifique que el kernel en ejecución es el último disponible y reinicie si no lo es. Compruebe el resultado de los siguientes comandos:

    cephadm@adm > uname -a
    cephadm@adm > rpm -qa kernel-default
  5. Verifique que el paquete ceph es de la versión 12.2.12 o posterior. Verifique que el paquete deepsea es de la versión 0.8.9 o posterior.

  6. Si anteriormente usó cualquier valor de bluestore_cache, tenga en cuenta que no están en vigor desde la versión 12.2.10 de Ceph. El nuevo ajuste bluestore_cache_autotune, que se define por defecto como "true", inhabilita el cambio de tamaño manual del caché. Para activar el comportamiento anterior, debe definir bluestore_cache_autotune=false. Consulte Sección 16.2.1, “Tamaño automático de caché” para obtener más detalles.

6.5 Verificación del entorno actual Edit source

  • Si el sistema tiene problemas evidentes, soluciónelos antes de iniciar la actualización. La actualización nunca soluciona los problemas existentes del sistema.

  • Compruebe el rendimiento del clúster. Puede utilizar comandos como rados bench, ceph tell osd.* bench o iperf3.

  • Compruebe el acceso a las pasarelas (como iSCSI Gateway o Object Gateway) y al dispositivos de bloques RADOS.

  • Tome documentación sobre las partes específicas de la configuración del sistema, como la configuración de red, la partición o los detalles de la instalación.

  • Utilice supportconfig para recopilar información importante del sistema y guardarla fuera de los nodos del clúster. Encontrará más información en https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_admsupport_supportconfig.html.

  • Asegúrese de que haya suficiente espacio libre en disco en cada nodo del clúster. Compruebe el espacio libre en disco con df -h. Cuando sea necesario, libere espacio en disco eliminando archivos o directorios innecesarios o eliminando instantáneas obsoletas del sistema operativo. Si no hay suficiente espacio libre en disco, no continúe con la actualización hasta que haya liberado suficiente.

6.6 Comprobación del estado del clúster Edit source

  • Compruebe el comando cluster health antes de iniciar el procedimiento de actualización. No inicie la actualización a menos que todos los nodos del clúster notifiquen el estado "HEALTH_OK".

  • Verifique que todos los servicios se estén ejecutando:

    • El master de Salt y los daemons del master de Salt.

    • Los daemons de Ceph Monitor y Ceph Manager.

    • Los daemons del servidor de metadatos.

    • Los daemons de Ceph OSD.

    • Los daemons de Object Gateway.

    • Los daemons de iSCSI Gateway.

Los comandos siguientes proporcionan detalles sobre el estado del clúster y la configuración específica:

ceph -s

Muestra un breve resumen del estado del clúster de Ceph, los servicios en ejecución, el uso de datos y las estadísticas de E/S. Verifique que notifica el estado "HEALTH_OK" antes de iniciar la actualización.

ceph health detail

Muestra detalles si el estado del clúster de Ceph no es correcto.

ceph versions

Muestra las versiones de los daemons de Ceph en ejecución.

ceph df

Muestra el espacio en disco total y libre del clúster. No inicie la actualización si el espacio libre en disco del clúster es inferior al 25 % del espacio total en disco.

salt '*' cephprocesses.check results=true

Muestra los procesos de Ceph y en ejecución sus PID ordenados por minion de Salt.

ceph osd dump | grep ^flags

Verifique que los indicadores "recovery_deletes" y "purged_snapdirs" estén presentes. Si no es así, puede aplicar un borrado seguro de todos los grupos de colocación ejecutando el comando siguiente. Tenga en cuenta que este borrado seguro impuesto posiblemente afecte de forma negativa al rendimiento de los clientes de Ceph.

cephadm@adm > ceph pg dump pgs_brief | cut -d " " -f 1 | xargs -n1 ceph pg scrub

6.7 Actualización sin conexión de los clústeres CTDB Edit source

CTDB proporciona una base de datos en clúster que se utiliza en las pasarelas Samba Gateway. El protocolo CTDB es muy sencillo y no admite clústeres de nodos que se comuniquen con versiones distintas del protocolo. Por lo tanto, los nodos CTDB deben desconectarse antes de realizar una actualización.

6.8 Actualización por nodo: procedimiento básico Edit source

Para asegurarse de que los servicios principales del clúster están disponibles durante la actualización, debe actualizar los nodos del clúster secuencialmente uno por uno. Hay dos formas de realizar la actualización de un nodo: mediante el DVD del instalador o mediante el sistema de migración de distribución.

Después de actualizar cada nodo, se recomienda ejecutar rpmconfigcheck para comprobar si hay archivos de configuración actualizados que se hayan editado localmente. Si el comando devuelve una lista de nombres de archivo con el sufijo.rpmnew, .rpmorig o .rpmsave, compare estos archivos con los archivos de configuración actuales para asegurarse de que no se ha perdido ningún cambio local. Si fuera necesario, actualice los archivos afectados. Para obtener más información sobre cómo trabajar con archivos .rpmnew, .rpmorig y .rpmsave, consulte https://documentation.suse.com/sles/15-SP1/single-html/SLES-admin/#sec-rpm-packages-manage.

Sugerencia
Sugerencia: paquetes huérfanos

Después de actualizar un nodo, varios paquetes estarán en estado "huérfano" sin un repositorio padre. Esto sucede porque los paquetes relacionados con python3 no hacen que los paquetes python2 queden obsoletos.

Encontrará más información sobre cómo mostrar los paquetes huérfanos en https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_zypper.html#sec_zypper_softup_orphaned.

6.8.1 Actualización manual de nodo mediante el DVD del instalador Edit source

  1. Reinicie el nodo desde el DVD o la imagen del instalador de SUSE Linux Enterprise Server 15 SP1.

  2. Seleccione Actualizar en el menú de arranque.

  3. En la pantalla Seleccionar el destino de migración, verifique que "SUSE Linux Enterprise Server 15 SP1" esté seleccionado y marque la casilla Ajustar manualmente los repositorios para la migración.

    Seleccionar el destino de migración
    Figura 6.1: Seleccionar el destino de migración
  4. Seleccione los siguientes módulos para instalarlos:

    • SUSE Enterprise Storage 6 x86_64

    • Basesystem Module 15 SP1 x86_64

    • Desktop Applications Module 15 SP1 x86_64

    • Legacy Module 15 SP1 x86_64

    • Server Applications Module 15 SP1 x86_64

  5. En la pantalla Repositorios usados anteriormente, verifique que estén seleccionados los repositorios correctos. Si el sistema no está registrado con SCC/SMT, debe añadir los repositorios manualmente.

    SUSE Enterprise Storage 6 requiere:

    • SLE-Module-Basesystem15-SP1-Pool

    •  SLE-Module-Basesystem15-SP1-Updates

    •  SLE-Module-Server-Applications15-SP1-Pool

    •  SLE-Module-Server-Applications15-SP1-Updates

    • SLE-Module-Desktop-Applications15-SP1-Pool

    • SLE-Module-Desktop-Applications15-SP1-Updates

    •  SLE-Product-SLES15-SP1-Pool

    •  SLE-Product-SLES15-SP1-Updates

    •  SLE15-SP1-Installer-Updates

    •  SUSE-Enterprise-Storage-6-Pool

    •  SUSE-Enterprise-Storage-6-Updates

    Si tiene previsto migrar ntpd a chronyd después de la migración de SES (consulte la Sección 6.3, “Migración de ntpd a chronyd), incluya los siguientes repositorios:

    • SLE-Module-Legacy15-SP1-Pool

    • SLE-Module-Legacy15-SP1-Updates

    NFS/SMB Gateway en SLE-HA en SUSE Linux Enterprise Server 15 SP1 requiere lo siguiente:

    • SLE-Product-HA15-SP1-Pool

    • SLE-Product-HA15-SP1-Updates

  6. Revise los valores de instalación e inicie el procedimiento de instalación haciendo clic en Actualizar.

6.8.2 Actualización de nodos con el sistema de migración de distribución de SUSE Edit source

El sistema de migración de distribución (DMS, por su siglas en inglés) proporciona una vía de actualización de una versión principal a otra para los sistemas SUSE Linux Enterprise instalados. El siguiente procedimiento utiliza el DMS para actualizar SUSE Enterprise Storage 5.5 a la versión 6, incluida la migración subyacente de SUSE Linux Enterprise Server 12 SP3 a SUSE Linux Enterprise Server 15 SP1.

Consulte en https://documentation.suse.com/suse-distribution-migration-system/1.0/single-html/distribution-migration-system/ la información general y detallada sobre el DMS.

  1. Instale los paquetes RPM de migración. Sirven para ajustar el cargador de arranque GRUB a fin de activar automáticamente la actualización en el siguiente reinicio. Instale los paquetes SLES15-SES-Migration y suse-migration-sle15-activation :

    root@minion > zypper install SLES15-SES-Migration suse-migration-sle15-activation
    1. Si el nodo que se está actualizando está registrado con un sistema de fases de repositorio como SCC, SMT, RMT o SUSE Manager, cree /etc/sle-migration-service.yml con el siguiente contenido:

      use_zypper_migration: true
      preserve:
        rules:
          - /etc/udev/rules.d/70-persistent-net.rules
    2. Si el nodo que se está actualizando no está registrado con un sistema de fases de repositorio como SCC, SMT, RMT o SUSE Manager, realice los siguientes cambios:

      1. Cree /etc/sle-migration-service.yml con el siguiente contenido:

        use_zypper_migration: false
        preserve:
          rules:
            - /etc/udev/rules.d/70-persistent-net.rules
      2. Inhabilite o elimine los repositorios SLE 12 SP3 y SES 5 y añada los repositorios SLE 15 SP1 y SES6. Encontrará la lista de repositorios relacionados en la Sección 6.4.1, “Repositorios de software requeridos”.

  2. Reinicie para iniciar la actualización. Mientras se ejecuta la actualización, puede entrar a la sesión en el nodo actualizado a través de ssh como usuario de migración utilizando la clave SSH existente del sistema host como se describe en https://documentation.suse.com/suse-distribution-migration-system/1.0/single-html/distribution-migration-system/. Para SUSE Enterprise Storage, si tiene acceso físico o acceso directo de consola al equipo, también puede entrar a la sesión como usuario root en la consola del sistema con la contraseña sesupgrade. El nodo se reiniciará automáticamente después de la actualización.

    Sugerencia
    Sugerencia: fallo de actualización

    Si se produce un error en la actualización, inspeccione el registro /var/log/distro_migration.log. Solucione el problema, vuelva a instalar los paquetes RPM de migración y reinicie el nodo.

6.9 Actualización del nodo de administración Edit source

Sugerencia
Sugerencia: estado de los nodos de clúster

Después de actualizar el nodo de administración, puede ejecutar el comando salt-run upgrade.status para obtener información útil sobre los nodos del clúster. El comando muestra las versiones de Ceph y del OS de todos los nodos y recomienda el orden en el que se deberán actualizar los nodos que todavía ejecuten versiones antiguas.

root@master # salt-run upgrade.status
The newest installed software versions are:
  ceph: ceph version 14.2.1-468-g994fd9e0cc (994fd9e0ccc50c2f3a55a3b7a3d4e0ba74786d50) nautilus (stable)
  os: SUSE Linux Enterprise Server 15 SP1

Nodes running these software versions:
  admin.ceph (assigned roles: master)
  mon2.ceph (assigned roles: admin, mon, mgr)

Nodes running older software versions must be upgraded in the following order:
   1: mon1.ceph (assigned roles: admin, mon, mgr)
   2: mon3.ceph (assigned roles: admin, mon, mgr)
   3: data1.ceph (assigned roles: storage)
[...]

6.10 Actualización de nodos de Ceph Monitor/Ceph Manager Edit source

  • Si el clúster no utiliza funciones del MDS, actualice los nodos MON/MGR uno por uno.

  • Si el clúster utiliza funciones del MDS y las funciones MON/MGR y MDS se recolocan de forma automática, debe reducir el tamaño del clúster del MDS y, a continuación, actualizar los nodos recolocados. Consulte la Sección 6.11, “Actualización de servidores de metadatos” para obtener más información.

  • Si el clúster utiliza funciones del MDS y se ejecutan en servidores dedicados, actualice todos los nodos MON/MGR uno por uno, reduzca el tamaño del clúster del MDS y actualícelo. Consulte la Sección 6.11, “Actualización de servidores de metadatos” para obtener más información.

Nota
Nota: actualización de Ceph Monitor

Debido a una limitación en el diseño de Ceph Monitor, una vez que se han actualizado dos MON a SUSE Enterprise Storage 6 y se ha formado un quórum, el tercer MON (mientras sigue en SUSE Enterprise Storage 5.5) no se reincorporará al clúster de MON si se reinicia por cualquier motivo, incluso si se reinicia el nodo. Por lo tanto, si se han actualizado dos MON, es mejor actualizar el resto tan pronto como sea posible.

Utilice el procedimiento descrito en la Sección 6.8, “Actualización por nodo: procedimiento básico”.

6.11 Actualización de servidores de metadatos Edit source

Debe reducir el tamaño del clúster del servidor de metadatos (MDS). Dado que hay características incompatibles entre las versiones 5.5 y 6 de SUSE Enterprise Storage, los daemons del MDS anteriores se apagarán tan pronto como vean a un solo MDS de nivel SES 6 unirse al clúster. Por lo tanto, es necesario reducir el tamaño del clúster del MDS a un solo MDS activo (y sin esperas) durante todo el proceso de actualización de los nodos del MDS. Tan pronto como se actualice el segundo nodo, podrá ampliar de nuevo el clúster del MDS.

Sugerencia
Sugerencia

En un clúster del MDS con carga muy elevada, es posible que deba reducir la carga (por ejemplo, deteniendo clientes) para que un único MDS activo pueda controlarla.

  1. Anote el valor actual de la opción max_mds:

    cephadm@adm > ceph fs get cephfs | grep max_mds
  2. Reduzca el tamaño del clúster del MDS si tiene más de 1 daemon del MDS activo, es decir, si max_mds es > 1. Para reducir el tamaño del clúster del MDS, ejecute:

    cephadm@adm > ceph fs set FS_NAME max_mds 1

    donde FS_NAME es el nombre de la instancia de CephFS ("cephfs" por defecto).

  3. Busque el nodo donde se aloja uno de los daemons del MDS en espera. Consulte el resultado del comando ceph fs status e inicie la actualización del clúster del MDS en este nodo.

    cephadm@adm > ceph fs status
    cephfs - 2 clients
    ======
    +------+--------+--------+---------------+-------+-------+
    | Rank | State  |  MDS   |    Activity   |  dns  |  inos |
    +------+--------+--------+---------------+-------+-------+
    |  0   | active | mon1-6 | Reqs:    0 /s |   13  |   16  |
    +------+--------+--------+---------------+-------+-------+
    +-----------------+----------+-------+-------+
    |       Pool      |   type   |  used | avail |
    +-----------------+----------+-------+-------+
    | cephfs_metadata | metadata | 2688k | 96.8G |
    |   cephfs_data   |   data   |    0  | 96.8G |
    +-----------------+----------+-------+-------+
    +-------------+
    | Standby MDS |
    +-------------+
    |    mon3-6   |
    |    mon2-6   |
    +-------------+

    En este ejemplo, necesita iniciar el procedimiento de actualización en el nodo "mon3-6" o en el "mon2-6".

  4. Actualice el nodo con el daemon en espera del MDS. Después de que se inicie el nodo actualizado del MDS, los daemons obsoletos del MDS se apagarán automáticamente. En este momento, los clientes pueden experimentar un breve tiempo de inactividad del servicio CephFS.

    Utilice el procedimiento descrito en la Sección 6.8, “Actualización por nodo: procedimiento básico”.

  5. Actualice los nodos restantes del MDS.

  6. Restablezca la configuración deseada en max_mds:

    cephadm@adm > ceph fs set FS_NAME max_mds ACTIVE_MDS_COUNT

6.12 Actualización de los OSD Ceph Edit source

Siga estos pasos para cada nodo de almacenamiento:

  1. Identifique qué daemons del OSD se ejecutan en un nodo determinado:

    cephadm@osd > ceph osd tree
  2. Establezca el indicador "noout" para cada daemon del OSD del nodo que se está actualizando:

    cephadm@osd > ceph osd add-noout osd.OSD_ID

    Por ejemplo:

    cephadm@osd > for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd add-noout osd.$i; done

    Verifíquelo con:

    cephadm@osd > ceph health detail | grep noout

    O bien

    cephadm@osd > ceph –s
    cluster:
     id:     44442296-033b-3275-a803-345337dc53da
     health: HEALTH_WARN
          6 OSDs or CRUSH {nodes, device-classes} have {NOUP,NODOWN,NOIN,NOOUT} flags set
  3. Cree archivos /etc/ceph/osd/*.json para todos los OSD existentes ejecutando el siguiente comando en el nodo que se va a actualizar:

    cephadm@osd > ceph-volume simple scan --force
  4. Actualice el nodo del OSD. Utilice el procedimiento descrito en la Sección 6.8, “Actualización por nodo: procedimiento básico”.

  5. Active todos los OSD que se encuentran en el sistema:

    cephadm@osd > ;ceph-volume simple activate --all
    Sugerencia
    Sugerencia: activación individual de particiones de datos

    Si desea activar las particiones de datos individualmente, debe encontrar el comando ceph-volume correcto de cada partición para activarla. Sustituya X1 por la letra o número correcto de la partición:

     cephadm@osd > ceph-volume simple scan /dev/sdX1

    Por ejemplo:

    cephadm@osd > ceph-volume simple scan /dev/vdb1
    [...]
    --> OSD 8 got scanned and metadata persisted to file:
    /etc/ceph/osd/8-d7bd2685-5b92-4074-8161-30d146cd0290.json
    --> To take over management of this scanned OSD, and disable ceph-disk
    and udev, run:
    -->     ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290

    La última línea del resultado contiene el comando para activar la partición:

    cephadm@osd > ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290
    [...]
    --> All ceph-disk systemd units have been disabled to prevent OSDs
    getting triggered by UDEV events
    [...]
    Running command: /bin/systemctl start ceph-osd@8
    --> Successfully activated OSD 8 with FSID
    d7bd2685-5b92-4074-8161-30d146cd0290
  6. Verifique que el nodo del OSD se inicia correctamente después del reinicio.

  7. Fíjese en el mensaje "Legacy BlueStore stats reporting detected on XX OSD(s)" (Se han detectado informes de estadísticas de BlueStore heredados en XX OSD):

    cephadm@osd > ceph –s
    cluster:
     id:     44442296-033b-3275-a803-345337dc53da
     health: HEALTH_WARN
     Legacy BlueStore stats reporting detected on 6 OSD(s)

    La advertencia es normal al actualizar Ceph a la versión 14.2.2. Puede desactivarla configurando lo siguiente:

    bluestore_warn_on_legacy_statfs = false

    La solución adecuada es ejecutar el siguiente comando en todos los OSD mientras están detenidos:

    cephadm@osd > ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-XXX

    A continuación se muestra un guion auxiliar que ejecuta ceph-bluestore-tool repair para todos los OSD del nodo NODE_NAME:

    OSDNODE=OSD_NODE_NAME;\
     for OSD in $(ceph osd ls-tree $OSDNODE);\
     do echo "osd=" $OSD;\
     salt $OSDNODE cmd.run 'systemctl stop ceph-osd@$OSD';\
     salt $OSDNODE cmd.run 'ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-$OSD';\
     salt $OSDNODE cmd.run 'systemctl start ceph-osd@$OSD';\
     done
  8. Desactive el indicador "noout" en cada daemon del OSD del nodo que se actualiza:

    cephadm@osd > ceph osd rm-noout osd.OSD_ID

    Por ejemplo:

    cephadm@osd > for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd rm-noout osd.$i; done

    Verifíquelo con:

    cephadm@osd > ceph health detail | grep noout

    Nota:

    cephadm@osd > ceph –s
    cluster:
     id:     44442296-033b-3275-a803-345337dc53da
     health: HEALTH_WARN
     Legacy BlueStore stats reporting detected on 6 OSD(s)
  9. verifique el estado del clúster. Mostrará un aspecto similar al siguiente:

    cephadm@osd > ceph status
    cluster:
      id:     e0d53d64-6812-3dfe-8b72-fd454a6dcf12
      health: HEALTH_WARN
              3 monitors have not enabled msgr2
    
    services:
      mon: 3 daemons, quorum mon1,mon2,mon3 (age 2h)
      mgr: mon2(active, since 22m), standbys: mon1, mon3
      osd: 30 osds: 30 up, 30 in
    
    data:
      pools:   1 pools, 1024 pgs
      objects: 0 objects, 0 B
      usage:   31 GiB used, 566 GiB / 597 GiB avail
      pgs:     1024 active+clean
  10. Compruebe que todos los nodos del OSD se han reiniciado y que los OSD se han iniciado automáticamente después del reinicio.

6.13 Migración de OSDs a BlueStore Edit source

OSD BlueStore es un nuevo back-end para los daemons del OSD. Es la opción por defecto desde SUSE Enterprise Storage 5. En comparación con FileStore, que almacena los objetos como archivos en un sistema de archivos XFS, BlueStore puede ofrecer un mayor rendimiento debido a que almacena los objetos directamente en el dispositivo de bloques subyacente. BlueStore también permite otras funciones, como la compresión integrada y la sobrescritura de codificación de borrado, que no están disponibles con FileStore.

Específicamente para BlueStore, un OSD dispone de un dispositivo "wal" (Write Ahead Log, registro de escritura predictiva) y un dispositivo "db" (base de datos RocksDB). La base de datos RocksDB almacena los metadatos de un OSD BlueStore. Estos dos dispositivos se encuentran por defecto en el mismo dispositivo que un OSD, pero cualquiera de ellos se puede colocar en otro lugar, por ejemplo en un medio más rápido.

En SUSE Enterprise Storage 5, se admite tanto FileStore como BlueStore y es posible que ambos sistemas coexistan en un mismo clúster. Durante el procedimiento de actualización de SUSE Enterprise Storage, los OSD de FileStore no se convierten automáticamente a BlueStore. Tenga en cuenta que las funciones específicas de BlueStore no estarán disponibles en los OSD que no se hayan migrado a BlueStore.

Antes de convertirlos a BlueStore, los OSD deben disponer ya de SUSE Enterprise Storage en ejecución. La conversión es un proceso lento, ya que todos los datos se reescriben dos veces. Aunque el proceso de migración puede tardar mucho tiempo en completarse, no hay ninguna interrupción del clúster y todos los clientes pueden seguir accediendo a él durante ese período. No obstante, el rendimiento será inferior durante la migración. Esto es debido al reequilibrio de la carga y la reposición de datos del clúster.

Utilice el procedimiento siguiente para migrar los OSD de FileStore a BlueStore:

Sugerencia
Sugerencia: desactivación de las medidas de seguridad

Los comandos de Salt necesarios para ejecutar la migración se bloquean por motivos de seguridad. Para desactivar estas medidas de seguridad, ejecute el siguiente comando:

 root@master # salt-run disengage.safety

Reconstruya los nodos antes de continuar:

 root@master #  salt-run rebuild.node TARGET

También puede reconstruir cada nodo individualmente. Por ejemplo:

root@master #  salt-run rebuild.node data1.ceph

El comando rebuild.node siempre elimina y vuelve a crear todos los OSD del nodo.

Importante
Importante

Si un OSD no se puede convertir, al volver a ejecutar la reconstrucción se destruyen los BlueStore OSD ya convertidos. En lugar de volver a ejecutar la reconstrucción, puede ejecutar:

root@master # salt-run disks.deploy TARGET

Después de la migración a BlueStore, el recuento de objetos seguirá siendo el mismo y el uso de disco será prácticamente igual.

6.14 Actualización de nodos de aplicación Edit source

Actualice los nodos de aplicación en el siguiente orden:

  1. Pasarelas Object Gateway

    • Si las pasarelas Object Gateway están respaldadas por un equilibrador de carga, debería de ser posible realizar una actualización gradual de las pasarelas sin interrupciones.

    • Compruebe que los daemons de Object Gateway se están ejecutando después de cada actualización y pruebe con el cliente S3/Swift.

    • Utilice el procedimiento descrito en la Sección 6.8, “Actualización por nodo: procedimiento básico”.

  2. Pasarelas iSCSI Gateway

    • Si los iniciadores iSCSI están configurados con múltiples rutas, debería de ser posible realizar una actualización gradual de las pasarelas iSCSI Gateway sin que haya interrupciones.

    • Compruebe que el daemon lrbd se está ejecutando después de cada actualización y pruebe con el iniciador.

    • Utilice el procedimiento descrito en la Sección 6.8, “Actualización por nodo: procedimiento básico”.

  3. NFS Ganesha. Utilice el procedimiento descrito en la Sección 6.8, “Actualización por nodo: procedimiento básico”.

  4. Pasarelas Samba Gateway. Utilice el procedimiento descrito en la Sección 6.8, “Actualización por nodo: procedimiento básico”.

6.15 Actualización de policy.cfg y distribución de Ceph Dashboard con DeepSea Edit source

En el nodo de administración, edite /srv/pillar/ceph/proposals/policy.cfg y aplique los siguientes cambios:

Importante
Importante: sin nuevos servicios

Durante la actualización del clúster, no añada nuevos servicios al archivo policy.cfg. Cambie la arquitectura del clúster solo después de completar la actualización.

  1. Elimine role-openattic.

  2. Añada role-prometheus y role-grafana al nodo que tenía instalados Prometheus y Grafana; normalmente se trata del nodo de administración.

  3. Ahora se ignora la función profile‑NOMBRE_PERFIL. Añada la nueva función correspondiente en la línea role-storage. Por ejemplo, para

    profile-default/cluster/*.sls

    añada

    role-storage/cluster/*.sls
  4. Sincronice todos los módulos de Salt:

    root@master # salt '*' saltutil.sync_all
  5. Actualice el pilar de Salt ejecutando las fases 1 y 2 de DeepSea:

    root@master # salt-run state.orch ceph.stage.1
    root@master # salt-run state.orch ceph.stage.2
  6. Limpie openATTIC:

    root@master # salt OA_MINION state.apply ceph.rescind.openattic
    root@master # salt OA_MINION state.apply ceph.remove.openattic
  7. Desactive el grain "restart_igw" para evitar que la fase 0 reinicie iSCSI Gateway, que aún no se ha instalado:

    Salt mastersalt '*' grains.delkey restart_igw
  8. Por último, ejecute las fases 0 a 4 de DeepSea:

    root@master # salt-run state.orch ceph.stage.0
    root@master # salt-run state.orch ceph.stage.1
    root@master # salt-run state.orch ceph.stage.2
    root@master # salt-run state.orch ceph.stage.3
    root@master # salt-run state.orch ceph.stage.4
    Sugerencia
    Sugerencia: errores de "falta un subvolumen" durante la fase 3

    La fase 3 de DeepSea puede fallar con un error similar al siguiente:

    subvolume : ['/var/lib/ceph subvolume missing on 4510-2', \
    '/var/lib/ceph subvolume missing on 4510-1', \
    [...]
    'See /srv/salt/ceph/subvolume/README.md']

    En tal caso, debe editar /srv/pillar/ceph/stack/global.yml y añadir la siguiente línea:

    subvolume_init: disabled

    A continuación, actualice el pilar de Salt y vuelva a ejecutar la fase 3 de DeepSea:

    root@master # salt '*' saltutil.refresh_pillar
     root@master # salt-run state.orch ceph.stage.3

    Después de que DeepSea haya completado correctamente la fase 3, la Ceph Dashboard se estará ejecutando. Consulte Capítulo 22, Ceph Dashboard para obtener una descripción detallada de las funciones de Ceph Dashboard.

    Para mostrar los nodos en los que se ejecuta la consola, ejecute:

    cephadm@adm > ceph mgr services | grep dashboard

    Para mostrar las credenciales de administrador, ejecute:

    root@master # salt-call grains.get dashboard_creds
  9. Reinicie secuencialmente los servicios de Object Gateway para utilizar el servidor Web "beast" en lugar del servidor "civetweb" obsoleto:

    root@master # salt-run state.orch ceph.restart.rgw.force
  10. Antes de continuar, se recomienda habilitar el módulo de telemetría de Ceph. Para obtener más información, consulte Sección 10.2, “Módulo de telemetría”.

6.16 Migración de distribuciones basadas en perfiles a DriveGroups Edit source

En SUSE Enterprise Storage 5.5, DeepSea ofrecía los llamados "perfiles" para describir el diseño de los OSD. A partir de SUSE Enterprise Storage 6, hemos pasado a un enfoque diferente denominado DriveGroups (encontrará más detalles en la Sección 5.5.2, “DriveGroups”).

Nota
Nota

La migración al nuevo enfoque no es obligatoria de inmediato. Las operaciones destructivas como salt‑run osd.remove, salt‑run osd.replace o salt‑run osd.purge siguen estando disponibles. Sin embargo, para añadir nuevos OSD se requerirá su intervención.

Debido al diferente enfoque de estas implementaciones, no se ofrece una vía de migración automatizada. Sin embargo, se ofrecen varias herramientas (runners de Salt) para que la migración sea lo más sencilla posible.

6.16.1 Análisis del diseño actual Edit source

Para ver información sobre los OSD distribuidos actualmente, utilice el siguiente comando:

root@master # salt-run disks.discover

Como alternativa, puede inspeccionar el contenido de los archivos en los directorios /srv/pillar/ceph/proposals/profile-*/. Tienen una estructura similar a la siguiente:

ceph:
  storage:
    osds:
      /dev/disk/by-id/scsi-drive_name: format: bluestore
      /dev/disk/by-id/scsi-drive_name2: format: bluestore

6.16.2 Creación de DriveGroups que coincidan con el diseño actual Edit source

Consulte la Sección 5.5.2.1, “Especificación” para obtener más información sobre la especificación DriveGroups.

La diferencia entre una distribución nueva y una actualización es que las unidades que se van a migrar ya están "utilizadas". Dado que

root@master # salt-run disks.list

solo busca discos no utilizados, use:

root@master # salt-run disks.list include_unavailable=True

Ajuste DriveGroups hasta que coincida con la configuración actual. Para obtener una representación más visual de lo que sucederá, utilice el siguiente comando. Tenga en cuenta que no habrá resultado alguno si no hay discos libres:

root@master # salt-run disks.report bypass_pillar=True

Si ha verificado que DriveGroups está configurado correctamente y desea aplicar el nuevo enfoque, elimine los archivos del directorio /srv/pillar/ceph/proposals/profile-NOMBRE_PERFIL/, elimine las líneas profile‑NOMBRE_PERFIL/cluster/*.sls correspondientes del archivo del archivo /srv/pillar/ceph/proposals/policy.cfg y ejecute la fase 2 de DeepSea para actualizar el pilar de Salt.

root@master # salt-run state.orch ceph.stage.2

Verifique el resultado ejecutando los siguientes comandos:

root@master # salt target_node pillar.get ceph:storage
root@master # salt-run disks.report
Aviso
Aviso: configuración incorrecta de DriveGroups

Si DriveGroups no está configurado correctamente y hay discos de repuesto en la configuración, se distribuirán de la forma en que los especificó. Se recomienda ejecutar lo siguiente:

root@master # salt-run disks.report

6.16.3 Distribución de OSD Edit source

En los casos sencillos, como con un OSD independiente, la migración se realizará progresivamente. Cada vez que elimine o sustituya un OSD del clúster, se sustituirá por un nuevo basado en LVM.

Sugerencia
Sugerencia: migración al formato LVM

Cada vez que un único OSD "heredado" necesita reemplazarse en un nodo, todos los OSD que comparten dispositivos con él deberán migrarse al formato basado en LVM.

Para no dejarse ninguno, lo mejor es migrar los OSD de todo el nodo.

6.16.4 Configuraciones más complejas Edit source

Si tiene una configuración más sofisticada (no solo OSD independientes), por ejemplo, WAL/DB dedicados o OSD cifrados, la migración solo puede producirse cuando se hayan eliminado todos los OSD asignados a ese dispositivo WAL/DB. Esto se debe al comando ceph-volume, que crea volúmenes lógicos en los discos antes de la distribución. Se evita así que el usuario mezcle distribuciones basadas en particiones con distribuciones basadas en volúmenes lógicos. En tales casos, es mejor eliminar manualmente todos los OSD asignados a un dispositivo WAL/DB y volver a distribuirlos mediante el enfoque DriveGroups.

Imprimir esta página