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 5

5 Actualización desde versiones anteriores

Este capítulo presenta los pasos necesarios para actualizar SUSE Enterprise Storage desde las versiones anteriores a la actual.

5.1 Lectura de las notas de la versión

En las notas de la versión puede 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/.

5.2 Procedimiento de actualización general

Antes de iniciar el procedimiento de actualización, tenga en cuenta los siguientes elementos:

Orden de la actualización

Antes de actualizar el clúster de Ceph, debe tener debidamente registrados en el SCC o en SMT tanto SUSE Linux Enterprise Server como SUSE Enterprise Storage. Puede actualizar los daemons del clúster mientras este esté en línea y en servicio. Algunos tipos de daemons dependen de otros. Por ejemplo, los daemons de Ceph Object Gateway dependen de los daemons de los Ceph Monitor y los Ceph OSD. Se recomienda actualizar en este orden:

  1. Monitores Ceph Monitor

  2. Gestores Ceph Manager

  3. Daemons Ceph OSD

  4. Servidores de metadatos

  5. Pasarelas Object Gateway

  6. Pasarelas iSCSI Gateway

  7. NFS Ganesha

Supresión de las instantáneas innecesarias del sistema operativo

Elimine las instantáneas del sistema de archivos que no se necesiten de las particiones del sistema operativo de nodos. De esta forma se garantiza que haya suficiente espacio libre en disco durante la actualización.

Comprobación del estado del clúster

Se recomienda comprobar el estado del clúster antes de iniciar el procedimiento de actualización.

Actualización de uno en uno

Se recomienda actualizar todos los daemons de un tipo específico, por ejemplo todos los daemons de monitor o todos los daemons de OSD, uno a uno para asegurarse de que todos tienen la misma versión. También se recomienda actualizar todos los daemons del clúster antes de intentar utilizar las nuevas funciones de una versión.

Después de actualizar todos los daemons de un tipo concreto, compruebe su estado.

Asegúrese de que cada monitor se ha vuelto a unir al quórum después de que se actualicen todos los monitores:

root # ceph mon stat

Asegúrese de que cada daemon Ceph OSD se ha vuelto a unir al clúster después de que se actualicen todos los OSD:

root # ceph osd stat
Definición del indicador require-osd-release luminous

Cuando se actualice el último OSD a SUSE Enterprise Storage 5, los nodos de monitor detectarán que todos los OSD tienen la versión "luminous" de Ceph y podrían mostrar la advertencia de que el indicador osdmap require-osd-release luminous no está definido. En tal caso, deberá definir este indicador manualmente para confirmar que, ahora que el clúster se ha actualizado a la versión "luminous", no es posible volver a la versión anterior de Ceph: "jewel". Defina el indicador ejecutando el comando siguiente:

root@minion > sudo ceph osd require-osd-release luminous

Después de que se complete el comando, la advertencia desaparece.

En las instalaciones nuevas de SUSE Enterprise Storage 5, este indicador se define automáticamente cuando los Ceph Monitor crean el osdmap inicial, por lo que no se necesita acción alguna por parte del usuario final.

5.3 Cifrado de OSD durante la actualización

A partir de SUSE Enterprise Storage 5, los OSD se distribuyen por defecto mediante BlueStore, en lugar de mediante FileStore. Aunque BlueStore admite el cifrado, los Ceph OSD se distribuyen sin cifrar por defecto. El procedimiento siguiente describe los pasos necesarios para cifrar los OSD durante el proceso de actualización. En él se presupone que tanto los datos como los discos WAL/DB que se van a usar para la distribución de los OSD están limpios y no tienen particiones. Si el disco se ha utilizado anteriormente, bórrelo con el procedimiento descrito en el Paso 13.

Importante
Importante: un OSD cada vez

Debe distribuir los OSD cifrados de uno en uno, no de forma simultánea. El motivo es que los datos del OSD se borran y que el clúster pasa por varias repeticiones de reequilibrio.

  1. Determine los valores de bluestore block db size y bluestore block wal size para la distribución y añádalos en el archivo /srv/salt/ceph/configuration/files/ceph.conf.d/global.conf en el master de Salt. Es preciso especificar los valores en bytes.

    [global]
    bluestore block db size = 48318382080
    bluestore block wal size = 2147483648

    Para obtener más información sobre cómo personalizar el archivo ceph.conf, consulte el Sección 1.11, “Archivo ceph.conf personalizado”.

  2. Ejecute la fase 3 de DeepSea para distribuir los cambios:

    root@master # salt-run state.orch ceph.stage.3
  3. Verifique que el archivo ceph.conf está actualizado en los nodos de OSD pertinentes:

    root@minion > cat /etc/ceph/ceph.conf
  4. Edite los archivos *.yml del directorio /srv/pillar/ceph/proposals/profile-default/stack/default/ceph/minions que sean relevantes para los OSD que va a cifrar. Vuelva a comprobar que la vía es la definida en el archivo /srv/pillar/ceph/proposals/policy.cfg y asegúrese de que modifica los archivos *.yml correctos.

    Importante
    Importante: identificadores de disco largos

    A la hora de identificar los discos de OSD en los archivos /srv/pillar/ceph/proposals/profile-default/stack/default/ceph/minions/*.yml, use identificadores de disco largos.

    A continuación se muestra un ejemplo de una configuración de OSD. Tenga en cuenta que debido a que es necesario el cifrado, las opciones db_size y wal_size se han eliminado:

    ceph:
     storage:
       osds:
         /dev/disk/by-id/scsi-SDELL_PERC_H730_Mini_007027b1065faa972100d34d7aa06d86:
           format: bluestore
           encryption: dmcrypt
           db: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN
           wal: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN
         /dev/disk/by-id/scsi-SDELL_PERC_H730_Mini_00d146b1065faa972100d34d7aa06d86:
           format: bluestore
           encryption: dmcrypt
           db: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN
           wal: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN
  5. Distribuya los nuevos OSD de almacenamiento de bloques con cifrado ejecutando las fases 2 y 3 de DeepSea:

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

    Puede observar el progreso con los comandos ceph -s o ceph osd tree. Es fundamental que se permita un reequilibrio del clúster antes de repetir el proceso en el nodo de OSD siguiente.

5.4 Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la versión 5

Importante
Importante: requisitos de software

Debe tener el siguiente software instalado y actualizado con las últimas versiones de los paquetes en todos los nodos de Ceph que desee actualizar antes de iniciar el procedimiento de actualización:

  • SUSE Linux Enterprise Server 12 SP2

  • SUSE Enterprise Storage 4

Además, antes de iniciar la actualización, debe actualizar el nodo master de Salt a SUSE Linux Enterprise Server 12 SP3 y SUSE Enterprise Storage 5 ejecutando zypper migration (o su método de actualización preferido).

Aviso
Aviso: puntos que se deben tener en cuenta antes de la actualización
  • Compruebe si se está ejecutando el servicio AppArmor e inhabilítelo en todos los nodos del clúster. Inicie el módulo AppArmor de YaST, seleccione Settings (Configuración) y desactive la casilla de verificación Enable Apparmor (Habilitar Apparmor). Confirme haciendo clic en Done (Terminado).

    Tenga en cuenta que SUSE Enterprise Storage no funcionará si AppArmor está habilitado.

  • Aunque el clúster sea completamente funcional durante la actualización, DeepSea establece el indicador "noout", que impide a Ceph reequilibrar los datos durante el tiempo de inactividad y, por lo tanto, impide las transferencias de datos innecesarias.

  • Para optimizar el proceso de actualización, DeepSea actualiza los nodos en este orden basado en la función que tiene asignada según recomiende Ceph en fases anteriores: Monitor, Manager, OSD, servidores de metadatos, Object Gateway, ISCSI Gateway y NFS Ganesha.

    Tenga en cuenta que DeepSea no puede impedir que el orden prescrito se infrinja si un nodo ejecuta varios servicios.

  • Aunque el clúster de Ceph esté en funcionamiento durante la actualización, los nodos podrían rearrancarse a fin de aplicar, por ejemplo, nuevas versiones del kernel. Para reducir las operaciones de E/S en espera, se recomienda rechazar las peticiones entrantes durante el proceso de actualización.

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

  • A partir de la versión Ceph Luminous, la opción de configuración osd crush location ya no se admite. Actualice los archivos de configuración de DeepSea para que usen crush location antes de proceder con la actualización.

Para actualizar el clúster de SUSE Enterprise Storage 4 a la versión 5, siga estos pasos:

  1. Defina el nuevo orden de clasificación de objetos interno. Para ello, ejecute:

    root # ceph osd set sortbitwise
    Sugerencia
    Sugerencia

    Para verificar que el comando se ha ejecutado correctamente, se recomienda ejecutar:

    root # ceph osd dump --format json-pretty | grep sortbitwise
     "flags": "sortbitwise,recovery_deletes,purged_snapdirs",
  2. Con el comando rpm -q deepsea, verifique que la versión del paquete de DeepSea en el nodo master de Salt empieza con al menos 0.7. Por ejemplo:

    root # rpm -q deepsea
    deepsea-0.7.27+git.0.274c55d-5.1

    Si el número de versión del paquete de DeepSea empieza con 0.6, vuelva a comprobar si el nodo master de Salt se ha migrado correctamente a SUSE Linux Enterprise Server 12 SP3 y SUSE Enterprise Storage 5 (consulte Importante: requisitos de software al principio de esta sección). Este es un requisito previo que debe completarse antes de iniciar el procedimiento de actualización.

    1. Si ha registrado los sistemas con SUSEConnect y usa el SCC/SMT, no necesita llevar a cabo ninguna otra acción. Continúe con el Paso 4.

    2. Si no usa el SCC/SMT, sino una imagen ISO de medios u otro origen de paquete, añada los siguientes repositorios manualmente: SLE12-SP3 Base, SLE12-SP3 Update, SES5 Base y SES5 Update. Puede hacerlo con el comando zypper. Antes, elimine todos los repositorios de software existentes y, a continuación, añada los nuevos repositorios necesarios. Por último, actualice los orígenes de los repositorios:

      root # zypper sd {0..99}
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/Storage/5/x86_64/product/ SES5-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATES
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATES
      root # zypper ref

      Cambie los datos de Pillar para utilizar una estrategia diferente. Edite:

      /srv/pillar/ceph/stack/name_of_cluster/cluster.yml

      Y añada la línea siguiente:

      upgrade_init: zypper-dup
      Sugerencia
      Sugerencia

      La estrategia zypper-dup requiere que se añadan manualmente los repositorios de software más recientes, mientras que la opción por defecto zypper-migration se basa en los repositorios proporcionados por el SCC/SMT.

  3. Actualice Pillar:

    root@master # salt target saltutil.sync_all

    Consulte la Sección 4.2.2, “Asignación de destino de los minions” para obtener información sobre cómo asignar destinos a los minions de Salt.

  4. Verifique si se ha escrito correctamente en Pillar:

    root@master # salt target pillar.get upgrade_init

    El resultado del comando debe reflejar la entrada que ha añadido.

  5. Actualice los minions de Salt:

    root@master # salt target state.apply ceph.updates.salt
  6. Verifique que todos los minions de Salt se han actualizado:

    root@master # salt target test.version
  7. Incluya los minions de Salt del clúster. Consulte la Sección 4.2.2, “Asignación de destino de los minions” de Procedimiento 4.1, “Ejecución de fases de distribución” para obtener más información.

  8. Inicie la actualización de SUSE Linux Enterprise Server y Ceph:

    root@master # salt-run state.orch ceph.maintenance.upgrade
    Sugerencia
    Sugerencia: nueva ejecución durante el rearranque

    Si en el proceso se produce un reinicio del master de Salt, vuelva a ejecutar el comando para iniciar de nuevo el proceso de actualización de los minions de Salt.

  9. Compruebe que AppArmor está inhabilitado y detenga todos los nodos después de la actualización:

    root # systemctl disable apparmor.service
    systemctl stop apparmor.service
  10. Después de la actualización, los gestores Ceph Manager aún no están instalados. Para que el estado del clúster sea el correcto, haga lo siguiente:

    1. Ejecute la fase 0 para habilitar la API REST de Salt:

      root@master # salt-run state.orch ceph.stage.0
    2. Ejecute la fase 1 para crear el subdirectorio role-mgr/:

      root@master # salt-run state.orch ceph.stage.1
    3. Edite el archivo policy.cfg como se describe en la Sección 4.5.1, “El archivo policy.cfg y añada una función de Ceph Manager a los nodos a los que va a distribuir los monitores Ceph Monitor. Asimismo, puede añadir la función openATTIC a uno de los nodos del clúster. Consulte el Capítulo 15, openATTIC para obtener más información.

    4. Ejecute la fase 2 para actualizar Pillar:

      root@master # salt-run state.orch ceph.stage.2
    5. DeepSea utiliza ahora un enfoque diferente para generar el archivo de configuración ceph.conf, consulte el Sección 1.11, “Archivo ceph.conf personalizado” para obtener más información.

    6. Ejecute la fase 3 para distribuir los gestores Ceph Manager:

      root@master # salt-run state.orch ceph.stage.3
    7. Ejecute la fase 4 para configurar openATTIC correctamente:

      root@master # salt-run state.orch ceph.stage.4
    Nota
    Nota: error de coincidencia de capacidades de clave de Ceph

    Si ceph.stage.3 falla con el "Error EINVAL: entity client.bootstrap-osd exists but caps do not match" (Error EINVAL: la entidad client.bootstrap-osd existe, pero las capacidades de clave no coinciden), significa que las capacidades de clave (caps) de la clave client.bootstrap.osd del clúster existente no coinciden con las caps que DeepSea está intentando establecer. Encima del mensaje de error, en texto rojo, verá un volcado del comando ceph auth que ha fallado. Consulte en este comando el ID de clave y el archivo que se están utilizando. En el caso de client.bootstrap-osd, el comando será:

    root # ceph auth add client.bootstrap-osd \
     -i /srv/salt/ceph/osd/cache/bootstrap.keyring

    Para solucionar los errores de coincidencia de capacidades de clave, compruebe el contenido del archivo de anillo de claves que DeepSea está intentando distribuir; por ejemplo:

    cephadm > cat /srv/salt/ceph/osd/cache/bootstrap.keyring
    [client.bootstrap-osd]
         key = AQD6BpVZgqVwHBAAQerW3atANeQhia8m5xaigw==
         caps mgr = "allow r"
         caps mon = "allow profile bootstrap-osd"

    Compárelo con el resultado de ceph auth get client.bootstrap-osd:

    root # ceph auth get client.bootstrap-osd
    exported keyring for client.bootstrap-osd
    [client.bootstrap-osd]
         key = AQD6BpVZgqVwHBAAQerW3atANeQhia8m5xaigw==
         caps mon = "allow profile bootstrap-osd"

    Fíjese en que falta la última clave caps mgr = "allow r". Para solucionar el problema, ejecute:

    root # ceph auth caps client.bootstrap-osd mgr \
     "allow r" mon "allow profile bootstrap-osd"

    Si se ejecuta ceph.stage.3 ahora, el problema se debe haber solucionado.

    El mismo problema puede producirse con los anillos de claves del servidor de metadatos y de Object Gateway cuando se ejecuta ceph.stage.4. Se aplica el mismo procedimiento anterior: compruebe qué comando ha fallado, el archivo de anillo de claves que se está distribuyendo y las capacidades de la clave existente. A continuación, ejecute ceph auth caps para actualizar las caps de claves existentes a fin de que coincidan con las que DeepSea está distribuyendo.

Importante
Importante: fallo de actualización

Si el clúster está en estado "HEALTH_ERR" durante más de 300 segundos o uno de los servicios para cada función asignada está inactivo durante más de 900 segundos, la actualización falla. En tal caso, busque el problema, resuélvalo y vuelva a ejecutar el procedimiento de actualización. Tenga en cuenta que en entornos virtualizados, los tiempos límite son más cortos.

Importante
Importante: rearranque de los OSD

Después de actualizar a SUSE Enterprise Storage 5, los OSD de FileStore necesitan aproximadamente cinco minutos más para iniciarse, ya que el OSD realizará una conversión una sola vez de sus archivos en disco.

Sugerencia
Sugerencia: comprobación de la versión de los componentes y nodos del clúster

Si necesita averiguar las versiones de los componentes y nodos individuales del clúster (por ejemplo, para comprobar si todos los nodos se encuentran realmente en el mismo nivel de parches después de la actualización), puede ejecutar:

root@master # salt-run status.report

El comando recorre los minions de Salt conectados y busca los números de versión de Ceph, Salt y SUSE Linux Enterprise Server. A continuación, ofrece un informe donde se muestra la versión que tienen la mayoría de los nodos y también los nodos cuya versión es diferente a los de esa mayoría.

5.4.1 Migración de OSD a BlueStore

OSD BlueStore es un nuevo procesador final para los daemons de 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 un medio más rápido o en uno distinto.

En SES5, 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
  1. Migre los perfiles de hardware:

    root@master # salt-run state.orch ceph.migrate.policy

    Este servicio migra los perfiles de hardware que usa actualmente el archivo policy.cfg. Procesa policy.cfg, encuentra cualquier perfil de hardware que use la estructura de datos original y lo convierte a la nueva estructura de datos. El resultado es un perfil de hardware nuevo denominado "migrated-nombre_original". También se actualiza policy.cfg.

    Si la configuración original tenía diarios independientes, la configuración de BlueStore utilizará el mismo dispositivo para los dispositivos "wal" y "db" de ese OSD.

  2. DeepSea migra los OSD definiendo su peso en 0, lo que "vacía" los datos hasta que el OSD está vacío. Los OSD se pueden migrar uno por uno o todos a la vez. En cualquier caso, cuando el OSD está vacío, la organización lo elimina y lo vuelve a crear con la nueva configuración.

    Sugerencia
    Sugerencia: método recomendado

    Use ceph.migrate.nodes si tiene un gran número de nodos de almacenamiento físicos o casi ningún dato. Si un nodo representa menos de 10 % de su capacidad, ceph.migrate.nodes puede ser ligeramente más rápido que mover todos los datos de esos OSD en paralelo.

    Si no tiene claro qué método debe utilizar, o si el sitio tiene menos nodos de almacenamiento (por ejemplo, cada nodo tiene más del 10 % de los datos del clúster), seleccione ceph.migrate.osds.

    1. Para migrar los OSD a la vez, ejecute:

      root@master # salt-run state.orch ceph.migrate.osds
    2. Para migrar todos los OSD de cada nodo en paralelo, ejecute:

      root@master # salt-run state.orch ceph.migrate.nodes
    Sugerencia
    Sugerencia

    Como la organización no aporta información sobre el progreso de la migración, utilice

    root # ceph osd tree

    para ver qué OSD tiene periódicamente un peso cero.

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.

5.5 Actualización desde SUSE Enterprise Storage 4 (distribución de ceph-deploy) a la versión 5

Importante
Importante: requisitos de software

Debe tener el siguiente software instalado y actualizado con las últimas versiones de los paquetes en todos los nodos de Ceph que desee actualizar antes de iniciar el procedimiento de actualización:

  • SUSE Linux Enterprise Server 12 SP2

  • SUSE Enterprise Storage 4

Seleccione al master de Salt para el clúster. Si el clúster tiene Calamari distribuido, el nodo de Calamari ya es el master de Salt. Como alternativa, el nodo de administración desde el que se ha ejecutado el comando ceph-deploy se convertirá en el master de Salt.

Antes de iniciar el proceso siguiente, debe actualizar el nodo master de Salt a SUSE Linux Enterprise Server 12 SP3 y SUSE Enterprise Storage 5 ejecutando zypper migration (o su método de actualización preferido).

Para actualizar el clúster de SUSE Enterprise Storage 4 que se ha distribuido con ceph-deploy a la versión 5, siga estos pasos:

Procedimiento 5.1: Pasos que se deben aplicar a todos los nodos del clúster (incluido el nodo de Calamari)
  1. Instale el paquete salt desde SLE-12-SP2/SES4:

    root # zypper install salt
  2. Instale el paquete salt-minion desde SLE-12-SP2/SES4 y habilite e inicie el servicio relacionado:

    root # zypper install salt-minion
    root # systemctl enable salt-minion
    root # systemctl start salt-minion
  3. Asegúrese de que el nombre de host "salt" se resuelve en la dirección IP del nodo master de Salt. Si el nombre de host salt no puede acceder al master de Salt, edite el archivo /etc/salt/minion o cree un archivo /etc/salt/minion.d/master.conf nuevo con el contenido siguiente:

    master: host_name_of_salt_master
    Sugerencia
    Sugerencia

    Los minions de Salt existentes tienen la opción master: ya definida en /etc/salt/minion.d/calamari.conf. No importa el nombre de archivo de configuración que se use, pero el directorio /etc/salt/minion.d/ sí es importante.

    Si realiza cambios en los archivos de configuración mencionados anteriormente, reinicie el servicio Salt en todos los minions de Salt:

    root@minion > systemctl restart salt-minion.service
    1. Si ha registrado los sistemas con SUSEConnect y usa el SCC/SMT, no necesita llevar a cabo ninguna otra acción.

    2. Si no usa el SCC/SMT, sino una imagen ISO de medios u otro origen de paquete, añada los siguientes repositorios manualmente: SLE12-SP3 Base, SLE12-SP3 Update, SES5 Base y SES5 Update. Puede hacerlo con el comando zypper. Antes, elimine todos los repositorios de software existentes y, a continuación, añada los nuevos repositorios necesarios. Por último, actualice los orígenes de los repositorios:

      root # zypper sd {0..99}
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/Storage/5/x86_64/product/ SES5-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATES
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATES
      root # zypper ref
Procedimiento 5.2: Pasos que se deben aplicar en el nodo master de Salt
  1. Defina el nuevo orden de clasificación de objetos interno. Para ello, ejecute:

    root@master # ceph osd set sortbitwise
    Sugerencia
    Sugerencia

    Para verificar que el comando se ha ejecutado correctamente, se recomienda ejecutar:

    root@master # ceph osd dump --format json-pretty | grep sortbitwise
     "flags": "sortbitwise,recovery_deletes,purged_snapdirs",
  2. Actualice el nodo master de Salt a SUSE Linux Enterprise Server 12 SP3 y SUSE Enterprise Storage 5. Para sistemas registrados en el SCC, use zypper migration. Si proporciona manualmente los repositorios de software necesarios, use zypper dup. Después de la actualización, asegúrese de que solo los repositorios de SUSE Linux Enterprise Server 12 SP3 y SUSE Enterprise Storage 5 estén activos (y actualizados) en el nodo master de Salt antes de continuar.

  3. Si no están ya presentes, instale el paquete salt-master y habilite e inicie el servicio relacionado:

    root@master # zypper install salt-master
    root@master # systemctl enable salt-master
    root@master # systemctl start salt-master
  4. Verifique que todos los minions de Salt están presentes mostrando sus claves:

    root@master # salt-key -L
  5. Añada todas las claves de los minions de Salt al master de Salt, incluido el master de los minions:

    root@master # salt-key -A -y
  6. Asegúrese de que se han aceptado todas las claves de los minions de Salt:

    root@master # salt-key -L
  7. Asegúrese de que el software del nodo master de Salt está actualizado:

    root@master # zypper migration
  8. Instale el paquete deepsea:

    root@master # zypper install deepsea
  9. Incluya los minions de Salt del clúster. Consulte la Sección 4.2.2, “Asignación de destino de los minions” de Procedimiento 4.1, “Ejecución de fases de distribución” para obtener más información.

  10. Importe el clúster instalado ceph-deploy existente:

    root@master # salt-run populate.engulf_existing_cluster

    El comando hará lo siguiente:

    • Distribuir todos los módulos necesarios de Salt y DeepSea a todos los minions de Salt.

    • Inspeccionar el clúster de Ceph en ejecución y completar /srv/pillar/ceph/proposals con un diseño del clúster.

      Se creará /srv/pillar/ceph/proposals/policy.cfg con funciones que coincidan con todos los servicios de Ceph en ejecución detectados. Consulte este archivo para verificar que todos los nodos de Monitor, OSD, Object Gateway y servidor de metadatos existentes tienen las funciones adecuadas. Los nodos de OSD se importarán en el subdirectorio profile-import/, por lo que puede examinar los archivos de /srv/pillar/ceph/proposals/profile-import/cluster/ y /srv/pillar/ceph/proposals/profile-import/stack/default/ceph/minions/ para confirmar que los OSD se han recogido correctamente.

      Nota
      Nota

      El archivo policy.cfg generado solo aplicará funciones a los servicios de Ceph detectados "role-mon", "role-mgr", "role-mds", "role-rgw", "role-admin" y "role-master" para el nodo master de Salt. Las otras funciones que desee deberán añadirse manualmente al archivo (consulte la Sección 4.5.1.2, “Asignación de funciones”).

    • El archivo ceph.conf del clúster existente se guardará en /srv/salt/ceph/configuration/files/ceph.conf.import.

    • srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml incluirá las redes fsid, de clúster y pública del clúster, y también especificará la opción configuration_init: default-import, por lo que DeepSea usará el archivo de configuración ceph.conf.import mencionado anteriormente, en lugar de utilizar la plantilla por defecto de DeepSea /srv/salt/ceph/configuration/files/ceph.conf.j2.

      Nota
      Nota: archivo ceph.conf personalizado

      Si necesita integrar el archivo ceph.conf con cambios personalizados, espere a que el proceso de actualización o importación finalice correctamente. A continuación, modifique el archivo /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml y convierta en comentario la línea siguiente:

      configuration_init: default-import

      Guarde el archivo y siga las instrucciones del Sección 1.11, “Archivo ceph.conf personalizado”.

    • Los distintos anillos de claves del clúster se guardan en los directorios siguientes:

      /srv/salt/ceph/admin/cache/
      /srv/salt/ceph/mon/cache/
      /srv/salt/ceph/osd/cache/
      /srv/salt/ceph/mds/cache/
      /srv/salt/ceph/rgw/cache/

      Verifique que existen los archivos de anillos de claves y que no hay ningún archivo de anillo de claves en el siguiente directorio (Ceph Manager no existía en versiones anteriores a SUSE Enterprise Storage 5):

      /srv/salt/ceph/mgr/cache/
  11. El comando salt-run populate.engulf_existing_cluster no gestiona la importación de la configuración de openATTIC. Tendrá que editar manualmente el archivo policy.cfg y añadir una línea role-openattic. Consulte la Sección 4.5.1, “El archivo policy.cfg para obtener más información.

  12. El comando salt-run populate.engulf_existing_cluster no gestiona la importación de las configuraciones de iSCSI Gateway. Si el clúster incluye instancias de iSCSI Gateway, importe manualmente sus configuraciones:

    1. En uno de los nodos de iSCSI Gateway, exporte el archivo lrbd.conf actual y cópielo en el nodo master de Salt:

      root@minion > lrbd -o >/tmp/lrbd.conf
      root@minion > scp /tmp/lrbd.conf admin:/srv/salt/ceph/igw/cache/lrbd.conf
    2. En el nodo master de Salt, añada la configuración por defecto de iSCSI Gateway en la configuración de DeepSea:

      root@master # mkdir -p /srv/pillar/ceph/stack/ceph/
      root@master # echo 'igw_config: default-ui' >> /srv/pillar/ceph/stack/ceph/cluster.yml
      root@master # chown salt:salt /srv/pillar/ceph/stack/ceph/cluster.yml
    3. Añada las funciones de iSCSI Gateway en policy.cfg y guarde el archivo:

      role-igw/stack/default/ceph/minions/ses-1.ses.suse.yml
      role-igw/cluster/ses-1.ses.suse.sls
      [...]
  13. Ejecute la fase 1 para crear todas las funciones posibles:

    root@master # salt-run state.orch ceph.stage.1
  14. Genere los subdirectorios necesarios en /srv/pillar/ceph/stack:

    root@master # salt-run push.proposal
  15. Verifique que hay un clúster gestionado por DeepSea en funcionamiento con las funciones asignadas correctamente:

    root@master # salt target pillar.get roles

    Compare el resultado con el diseño real del clúster.

  16. Calamari deja un trabajo de Salt programado en ejecución y comprueba el estado del clúster. Elimine el trabajo:

    root@minion > salt target schedule.delete ceph.heartbeat
  17. A partir de este punto, siga el procedimiento que se describe en la Sección 5.4, “Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la versión 5”.

5.6 Actualización desde SUSE Enterprise Storage 4 (distribución de Crowbar) a la versión 5

Importante
Importante: requisitos de software

Debe tener el siguiente software instalado y actualizado con las últimas versiones de los paquetes en todos los nodos de Ceph que desee actualizar antes de iniciar el procedimiento de actualización:

  • SUSE Linux Enterprise Server 12 SP2

  • SUSE Enterprise Storage 4

Para actualizar la instancia de SUSE Enterprise Storage 4 distribuida mediante Crowbar a la versión 5, siga estos pasos:

  1. Para cada nodo de Ceph (incluido el nodo de Calamari), detenga e inhabilite todos los servicios relacionados con Crowbar:

    root@minion > sudo systemctl stop chef-client
    root@minion > sudo systemctl disable chef-client
    root@minion > sudo systemctl disable crowbar_join
    root@minion > sudo systemctl disable crowbar_notify_shutdown
  2. Para cada nodo de Ceph (incluido el nodo de Calamari), verifique que los repositorios de software señalan a los productos SUSE Enterprise Storage 5 y SUSE Linux Enterprise Server 12 SP3. Si todavía hay repositorios que señalen a versiones anteriores del producto, inhabilítelos.

  3. Para cada nodo de Ceph (incluido el nodo de Calamari), verifique que salt-minion está instalado. Si no lo está, instálelo:

    root@minion > sudo zypper in salt salt-minion
  4. Para los nodos de Ceph que no tengan el paquete salt-minion instalado, cree el archivo /etc/salt/minion.d/master.conf y haga que la opción master señale al nombre de host completo del nodo de Calamari:

    master: full_calamari_hostname
    Sugerencia
    Sugerencia

    Los minions de Salt existentes tienen la opción master: ya definida en /etc/salt/minion.d/calamari.conf. No importa el nombre de archivo de configuración que se use, pero el directorio /etc/salt/minion.d/ sí es importante.

    Habilite e inicie el servicio salt-minion:

    root@minion > sudo systemctl enable salt-minion
    root@minion > sudo systemctl start salt-minion
  5. En el nodo de Calamari, acepte las claves de los minions de Salt restantes:

    root@master # salt-key -L
    [...]
    Unaccepted Keys:
    d52-54-00-16-45-0a.example.com
    d52-54-00-70-ac-30.example.com
    [...]
    
    root@master # salt-key -A
    The following keys are going to be accepted:
    Unaccepted Keys:
    d52-54-00-16-45-0a.example.com
    d52-54-00-70-ac-30.example.com
    Proceed? [n/Y] y
    Key for minion d52-54-00-16-45-0a.example.com accepted.
    Key for minion d52-54-00-70-ac-30.example.com accepted.
  6. Si se ha distribuido Ceph en la red pública y no existe ninguna interfaz VLAN, añada una interfaz VLAN en la red pública de Crowbar al nodo de Calamari.

  7. Actualice el nodo de Calamari a SUSE Linux Enterprise Server 12 SP3 y SUSE Enterprise Storage 5, ya sea mediante zypper migration o con el método que prefiera. A partir de este punto, el nodo de Calamari se convierte en el master de Salt. Después de la actualización, reinicie el master de Salt.

  8. Instale DeepSea en el master de Salt:

    root@master # zypper in deepsea
  9. Especifique la opción deepsea_minions para incluir el grupo correcto de minions de Salt en fases de distribución. Consulte Sección 4.2.2.3, “Definición de la opción deepsea_minions para obtener más información.

  10. DeepSea espera que todos los nodos de Ceph tengan un archivo /etc/ceph/ceph.conf idéntico. Crowbar distribuye una versión ligeramente distinta de ceph.conf a cada nodo, por lo que deberá consolidarlas:

    • Elimine la opción osd crush location hook que incluyó Calamari.

    • Elimine la opción public addr de la sección [mon].

    • Elimine los números de puerto de la opción mon host.

  11. Si se estaba ejecutando Object Gateway, Crowbar habrá distribuido un archivo /etc/ceph/ceph.conf.radosgw independiente para mantener los secretos de Keystone separados del archivo ceph.conf normal. Crowbar también habrá añadido un archivo /etc/systemd/system/ceph-radosgw@.service personalizado. Dado que DeepSea no lo admite, deberá eliminarlo:

    • Añada al final de todas las secciones [client.rgw...] del archivo ceph.conf.radosgw a /etc/ceph/ceph.conf en todos los nodos.

    • En el nodo de Object Gateway, ejecute lo siguiente:

      root@minion > rm /etc/systemd/system/ceph-radosgw@.service
      systemctl reenable ceph-radosgw@rgw.public.$hostname
  12. Asegúrese de que ceph status funciona cuando se ejecuta desde el master de Salt:

    root@master # ceph status
    cluster a705580c-a7ae-4fae-815c-5cb9c1ded6c2
    health HEALTH_OK
    [...]
  13. Importe el clúster existente:

    root@master # salt-run populate.engulf_existing_cluster
    root@master # salt-run state.orch ceph.stage.1
    root@master # salt-run push.proposal
  14. El comando salt-run populate.engulf_existing_cluster no gestiona la importación de las configuraciones de iSCSI Gateway. Si el clúster incluye instancias de iSCSI Gateway, importe manualmente sus configuraciones:

    1. En uno de los nodos de iSCSI Gateway, exporte el archivo lrbd.conf actual y cópielo en el nodo master de Salt:

      root@minion > lrbd -o > /tmp/lrbd.conf
      root@minion > scp /tmp/lrbd.conf admin:/srv/salt/ceph/igw/cache/lrbd.conf
    2. En el nodo master de Salt, añada la configuración por defecto de iSCSI Gateway en la configuración de DeepSea:

      root@master # mkdir -p /srv/pillar/ceph/stack/ceph/
      root@master # echo 'igw_config: default-ui' >> /srv/pillar/ceph/stack/ceph/cluster.yml
      root@master # chown salt:salt /srv/pillar/ceph/stack/ceph/cluster.yml
    3. Añada las funciones de iSCSI Gateway en policy.cfg y guarde el archivo:

      role-igw/stack/default/ceph/minions/ses-1.ses.suse.yml
      role-igw/cluster/ses-1.ses.suse.sls
      [...]
    1. Si ha registrado los sistemas con SUSEConnect y usa el SCC/SMT, no necesita llevar a cabo ninguna otra acción.

    2. Si no usa el SCC/SMT, sino una imagen ISO de medios u otro origen de paquete, añada los siguientes repositorios manualmente: SLE12-SP3 Base, SLE12-SP3 Update, SES5 Base y SES5 Update. Puede hacerlo con el comando zypper. Antes, elimine todos los repositorios de software existentes y, a continuación, añada los nuevos repositorios necesarios. Por último, actualice los orígenes de los repositorios:

      root # zypper sd {0..99}
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/Storage/5/x86_64/product/ SES5-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATES
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATES
      root # zypper ref

      Cambie los datos de Pillar para utilizar una estrategia diferente. Editar

      /srv/pillar/ceph/stack/name_of_cluster/cluster.yml

      Y añada la línea siguiente:

      upgrade_init: zypper-dup
      Sugerencia
      Sugerencia

      La estrategia zypper-dup requiere que se añadan manualmente los repositorios de software más recientes, mientras que la opción por defecto zypper-migration se basa en los repositorios proporcionados por el SCC/SMT.

  15. Arregle los elementos grain del host para hacer que DeepSea utilice nombres de host cortos en la red pública para los ID de instancia del daemon de Ceph. Para cada nodo, debe ejecutar grains.set con el nombre de host (corto) nuevo. Antes de ejecutar grains.set, verifique las instancias del monitor actual ejecutando ceph status. Se muestra un ejemplo del antes y el después:

    root@master # salt target grains.get host
    d52-54-00-16-45-0a.example.com:
        d52-54-00-16-45-0a
    d52-54-00-49-17-2a.example.com:
        d52-54-00-49-17-2a
    d52-54-00-76-21-bc.example.com:
        d52-54-00-76-21-bc
    d52-54-00-70-ac-30.example.com:
        d52-54-00-70-ac-30
    root@master # salt d52-54-00-16-45-0a.example.com grains.set \
     host public.d52-54-00-16-45-0a
    root@master # salt d52-54-00-49-17-2a.example.com grains.set \
     host public.d52-54-00-49-17-2a
    root@master # salt d52-54-00-76-21-bc.example.com grains.set \
     host public.d52-54-00-76-21-bc
    root@master # salt d52-54-00-70-ac-30.example.com grains.set \
     host public.d52-54-00-70-ac-30
    root@master # salt target grains.get host
    d52-54-00-76-21-bc.example.com:
        public.d52-54-00-76-21-bc
    d52-54-00-16-45-0a.example.com:
        public.d52-54-00-16-45-0a
    d52-54-00-49-17-2a.example.com:
        public.d52-54-00-49-17-2a
    d52-54-00-70-ac-30.example.com:
        public.d52-54-00-70-ac-30
  16. Ejecute la actualización:

    root@master # salt target state.apply ceph.updates
    root@master # salt target test.version
    root@master # salt-run state.orch ceph.maintenance.upgrade

    Se reiniciarán todos los nodos. El clúster se volverá a activar con una advertencia de que no hay ninguna instancia de Ceph Manager activa. Esto es normal. Calamari no debe estar instalado ni en ejecución ya en este punto.

  17. Ejecute todas las fases de distribución necesarias para hacer que el clúster tenga un estado correcto:

    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
  18. Para distribuir openATTIC (consulte el Capítulo 15, openATTIC), añada una línea role-openattic adecuada (consulte la Sección 4.5.1.2, “Asignación de funciones”) a /srv/pillar/ceph/proposals/policy.cfg y ejecute:

    root@master # salt-run state.orch ceph.stage.2
    root@master # salt-run state.orch ceph.stage.4
  19. Durante la actualización, es posible que reciba errores de tipo "Error EINVAL: entity [...] exists but caps do not match" (Error EINVAL: la entidad [...] existe pero las caps no coinciden). Para solucionarlos, consulte la Sección 5.4, “Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la versión 5”.

  20. Lleve a cabo la limpieza restante:

    • Crowbar crea entradas en /etc/fstab para cada OSD. No son necesarias, así que suprímalas.

    • Calamari deja un trabajo de Salt programado en ejecución y comprueba el estado del clúster. Elimine el trabajo:

      root@master # salt target schedule.delete ceph.heartbeat
    • Aún hay algunos paquetes innecesarios instalados, principalmente gemas de ruby y relacionados con chef. Su eliminación no es obligatoria, pero puede hacerlo ejecutando zypper rm nombre_paquete.

5.7 Actualización desde SUSE Enterprise Storage 3 a la versión 5

Importante
Importante: requisitos de software

Debe tener el siguiente software instalado y actualizado con las últimas versiones de los paquetes en todos los nodos de Ceph que desee actualizar antes de iniciar el procedimiento de actualización:

  • SUSE Linux Enterprise Server 12 SP1

  • SUSE Enterprise Storage 3

Para actualizar el clúster de SUSE Enterprise Storage 3 a la versión 5, siga los pasos descritos en el Procedimiento 5.1, “Pasos que se deben aplicar a todos los nodos del clúster (incluido el nodo de Calamari)” y, a continuación, los descritos en el Procedimiento 5.2, “Pasos que se deben aplicar en el nodo master de Salt”.

Imprimir esta página