Ir al contenidoIr a la navegación de la página: página anterior [tecla de acceso p]/página siguiente [tecla de acceso n]
documentation.suse.com / Documentación de SUSE Enterprise Storage 7 / Guía de distribución / Actualización desde versiones anteriores / Actualización desde una versión anterior
Se aplica a SUSE Enterprise Storage 7

7 Actualización desde una versión anterior

 

En este capítulo se presentan los pasos necesarios para actualizar SUSE Enterprise Storage 6 a la versión 7.

La actualización incluye las siguientes tareas:

  • Actualización de Ceph Nautilus a Octopus.

  • Cambio de la instalación y ejecución de Ceph a través de paquetes RPM a la ejecución en contenedores.

  • Eliminación completa de DeepSea y sustitución por ceph-salt y cephadm.

Aviso
Aviso

La información sobre actualización de este capítulo solo se aplica a las actualizaciones de DeepSea a cephadm. No intente seguir estas instrucciones si desea distribuir SUSE Enterprise Storage en la plataforma SUSE CaaS.

Importante
Importante

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

7.1 Antes de actualizar

 

Las siguientes tareas deben completarse antes de iniciar la actualización. Puede hacerlo en cualquier momento durante la vida útil de SUSE Enterprise Storage 6.

7.1.1 Puntos que se deben tener en cuenta

 

Antes de actualizar, lea atentamente las secciones siguientes para asegurarse de que comprende todas las tareas que deben ejecutarse.

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

    Encontrará las notas de la versión de SES 7 en línea en https://www.suse.com/releasenotes/.

    Asimismo, después de instalar el paquete release-notes-ses desde el repositorio de SES 7, 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/.

  • Lea el Capítulo 5, Distribución con cephadm para familiarizarse con ceph-salt y Ceph Orchestrator y, en particular, con la información sobre las especificaciones de servicio.

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

  • Primero debe actualizar el master de Salt, y después sustituir DeepSea con ceph-salt y cephadm. No podrá empezar a utilizar el módulo de orcephadm orchestrator al menos hasta que se hayan actualizado todos los de Ceph Manager.

  • La actualización de usar RPM de Nautilus a contenedores de Octopus debe realizarse en un solo paso. Esto significa que se debe actualizar un nodo completo a la vez, no de daemon en daemon.

  • La actualización de los servicios principales (MON, MGR, OSD) se produce de forma ordenada. Cada servicio está disponible durante la actualización. Los servicios de pasarela (servidor de metadatos, Object Gateway, NFS Ganesha e iSCSI Gateway) deben redistribuirse después de actualizar los servicios principales. Para los siguientes servicios se produce un cierto tiempo de inactividad:

    • Importante
      Importante

      Los servidores de metadatos y las pasarelas Object Gateway están inactivos desde el momento en que los nodos se actualizan de SUSE Linux Enterprise Server 15 SP1 a SUSE Linux Enterprise Server 15 SP2 hasta que los servicios se vuelven a distribuir al final del proceso de actualización. Es especialmente importante tener esto en cuenta si estos servicios se colocan junto a servicios MON, MGR u OSD, ya que en tal caso, pueden estar inactivos durante toda la actualización del clúster. Si se prevé que esto sea un problema, considere la posibilidad de distribuir estos servicios por separado en nodos adicionales antes de la actualización, de forma que permanezcan inactivos durante el menor tiempo posible; que será lo que tarden en actualizarse los nodos de pasarela, no lo que tarde todo el clúster en actualizarse.

    • NFS Ganesha y las pasarelas iSCSI Gateway solo están inactivos mientras los nodos se reinician durante la actualización de SUSE Linux Enterprise Server 15 SP1 a SUSE Linux Enterprise Server 15 SP2 y, de nuevo, brevemente, cuando cada servicio se vuelve a distribuir en modo de contenedores.

7.1.2 Copia de seguridad de la configuración y los datos del clúster

 

Se recomienda encarecidamente realizar una copia de seguridad de toda la configuración y los datos del clúster antes de iniciar la actualización a SUSE Enterprise Storage 7. Para obtener instrucciones sobre cómo realizar copias de seguridad de todos los datos, consulte https://documentation.suse.com/ses/6/html/ses-all/cha-deployment-backup.html.

7.1.3 Verificación de los pasos de la actualización anterior

 

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

Compruebe si el archivo /srv/salt/ceph/configuration/files/ceph.conf.import existe.

Este archivo se crea en el proceso de importación durante la actualización de SUSE Enterprise Storage 5 a la versión 6. La opción configuration_init: default-import se define como /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.

7.1.4 Actualización de los nodos de clúster y verificación del estado del clúster

 

Verifique que todas las actualizaciones más recientes de SUSE Linux Enterprise Server 15 SP1 y SUSE Enterprise Storage 6 se han aplicado a todos los nodos de clúster: 

root # zypper refresh && zypper patch

Después de aplicar las actualizaciones, compruebe el estado del clúster: 

cephuser@adm > ceph -s

7.1.5 Verificación del acceso a repositorios de software e imágenes de contenedor

 

Verifique que cada nodo del clúster tenga acceso a los repositorios de software de SUSE Linux Enterprise Server 15 SP2 y SUSE Enterprise Storage 7, así como al registro de imágenes de contenedor.

7.1.5.1 Repositorios de software

 

Si todos los nodos están registrados con SCC, podrá utilizar el comando zypper migration para actualizar. Consulte https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-upgrade-online.html#sec-upgrade-online-zypper para obtener más información.

Si los nodos no están registrados con SCC, inhabilite todos los repositorios de software existentes y añada los repositorios Repositorio y Actualizaciones para cada una de las extensiones siguientes:

  • SLE-Product-SLES/15-SP2

  • SLE-Module-Basesystem/15-SP2

  • SLE-Module-Server-Applications/15-SP2

  • SUSE-Enterprise-Storage-7

7.1.5.2 Imágenes de contenedor

 

Todos los nodos de clúster necesitan acceso al registro de imágenes de contenedor. En la mayoría de los casos, utilizará el registro público de SUSE situado en registration.suse.com. Necesitará las siguientes imágenes:

  • registry.suse.com/ses/7/ceph/ceph

  • registry.suse.com/ses/7/ceph/grafana

  • registry.suse.com/caasp/v4.5/prometheus-server

  • registry.suse.com/caasp/v4.5/prometheus-node-exporter

  • registry.suse.com/caasp/v4.5/prometheus-alertmanager

Como alternativa, por ejemplo para las distribuciones en entornos aislados, configure un registro local y verifique que tiene el conjunto correcto de imágenes de contenedor. Consulte la Sección 5.3.2.11, “Configuración del registro del contenedor” para obtener más información sobre cómo configurar un registro de imagen de contenedor local.

7.2 Actualización del master de Salt

 

El procedimiento siguiente describe el proceso de actualización del master de Salt:

  1. Actualice el sistema operativo subyacente a SUSE Linux Enterprise Server 15 SP2:

    • En el caso de un clúster que tenga todos los nodos registrados con SCC, ejecute zypper migration.

    • Para un clúster cuyos nodos tienen repositorios de software asignados manualmente, ejecute zypper dup seguido de reboot.

  2. Inhabilite las fases de DeepSea para evitar un uso accidental. Añada el contenido siguiente a /srv/pillar/ceph/stack/global.yml: 

    stage_prep: disabled
stage_discovery: disabled
stage_configure: disabled
stage_deploy: disabled
stage_services: disabled
stage_remove: disabled

    Guarde el archivo y aplique los cambios: 

    root@master # salt '*' saltutil.pillar_refresh

  3. Si no utiliza imágenes de contenedor de registration.suse.com sino el registro configurado localmente, edite /srv/pillar/ceph/stack/global.yml para informar a DeepSea sobre qué imagen de contenedor de Ceph y qué registro de Ceph debe utilizar. Por ejemplo, para utilizar 192.168.121.1:5000/my/ceph/image, añada las siguientes líneas: 

    ses7_container_image: 192.168.121.1:5000/my/ceph/image
ses7_container_registries:
  - location: 192.168.121.1:5000

    Guarde el archivo y aplique los cambios: 

    root@master # salt '*' saltutil.refresh_pillar

  4. Asimile la configuración existente: 

    cephuser@adm > ceph config assimilate-conf -i /etc/ceph/ceph.conf

  5. Verifique el estado de la actualización. El resultado puede variar según la configuración del clúster: 

    root@master # salt-run upgrade.status
The newest installed software versions are:
 ceph: ceph version 15.2.2-60-gf5864377ab (f5864377abb5549f843784c93577980aa264b9bc) octopus (stable)
 os: SUSE Linux Enterprise Server 15 SP2
Nodes running these software versions:
 admin.ceph (assigned roles: master, prometheus, grafana)
Nodes running older software versions must be upgraded in the following order:
 1: mon1.ceph (assigned roles: admin, mon, mgr)
 2: mon2.ceph (assigned roles: admin, mon, mgr)
 3: mon3.ceph (assigned roles: admin, mon, mgr)
 4: data4.ceph (assigned roles: storage, mds)
 5: data1.ceph (assigned roles: storage)
 6: data2.ceph (assigned roles: storage)
 7: data3.ceph (assigned roles: storage)
 8: data5.ceph (assigned roles: storage, rgw)

7.3 Actualización de los nodos de MON, MGR y OSD

 

Actualice los nodos de Ceph Monitor, Ceph Manager y OSD de uno en uno. Para cada servicio, siga estos pasos:

  1. Si el nodo que está actualizando es un nodo de OSD, procure que no esté marcado como out durante la actualización ejecutando el comando siguiente: 

    cephuser@adm > ceph osd add-noout SHORT_NODE_NAME

    Sustituya SHORT_NODE_NAME por el nombre corto del nodo tal y como aparece en la salida del comando ceph osd. En la siguiente entrada, los nombres de host cortos son ses-min1 y ses-min2. 

    root@master # ceph osd tree
ID   CLASS  WEIGHT   TYPE NAME       STATUS  REWEIGHT  PRI-AFF
 -1         0.60405  root default
-11         0.11691      host ses-min1
  4    hdd  0.01949          osd.4       up   1.00000  1.00000
  9    hdd  0.01949          osd.9       up   1.00000  1.00000
 13    hdd  0.01949          osd.13      up   1.00000  1.00000
[...]
 -5         0.11691      host ses-min2
  2    hdd  0.01949          osd.2       up   1.00000  1.00000
  5    hdd  0.01949          osd.5       up   1.00000  1.00000
[...]

  2. Actualice el sistema operativo subyacente a SUSE Linux Enterprise Server 15 SP2:

    • Si todos los nodos de clúster están registrados con SCC, ejecute zypper migration.

    • Si los nodos de clúster tienen repositorios de software asignados manualmente, ejecute zypper dup seguido de reboot.

  3. Después de reiniciar el nodo, convierta en contenedores todos los daemons de MON, MGR y OSD existentes en ese nodo ejecutando el comando siguiente en el master de Salt: 

    root@master # salt MINION_ID state.apply ceph.upgrade.ses7.adopt

    Sustituya MINION_ID por el ID del minion que está actualizando. Puede obtener la lista de ID de minion ejecutando el comando salt-key -L en el master de Salt.

    Sugerencia
    Sugerencia

    Para ver el estado y el progreso de la adopción, compruebe Ceph Dashboard o ejecute uno de los comandos siguientes en el master de Salt: 

    root@master # ceph status
root@master # ceph versions
root@master # salt-run upgrade.status

  4. Después de que la adopción haya finalizado correctamente, desmarque el indicador noout si el nodo que está actualizando es un nodo de OSD: 

    cephuser@adm > ceph osd rm-noout SHORT_NODE_NAME

7.4 Actualización de nodos de pasarela

 

A continuación, actualice los nodos de pasarela independientes (servidor de metadatos, Object Gateway, NFS Ganesha o iSCSI Gateway). Actualice el sistema operativo subyacente a SUSE Linux Enterprise Server 15 SP2 para cada nodo:

  • Si todos los nodos de clúster están registrados en el Centro de servicios al cliente de SUSE, ejecute el comando zypper migration.

  • Si los nodos de clúster tienen repositorios de software asignados manualmente, ejecute zypper dup seguido de reboot.

Este paso también se aplica a los nodos que forman parte del clúster, pero que aún no tienen ninguna función asignada (en caso de duda, compruebe la lista de hosts en el master de Salt proporcionada por el comando salt-key -L y compárela con el resultado del comando salt-run upgrade.status).

Una vez que se actualiza el sistema operativo en todos los nodos de clúster, el siguiente paso es instalar el paquete ceph-salt y aplicar la configuración del clúster. Los servicios de pasarela reales se redistribuyen en un modo de contenedores al final del proceso de actualización.

Nota
Nota

Los servicios de servidor de metadatos y Object Gateway no están disponibles desde el momento de la actualización a SUSE Linux Enterprise Server 15 SP2 hasta que se redistribuyen al final del proceso de actualización.

7.5 Instalación de ceph-salt y aplicación de la configuración del clúster

 

Antes de iniciar el proceso de instalación de ceph-salt y aplicar la configuración del clúster, compruebe el estado del clúster y de la actualización ejecutando los comandos siguientes: 

root@master # ceph status
root@master # ceph versions
root@master # salt-run upgrade.status

  1. Elimine los trabajos cron rbd_exporter y rgw_exporter creados por DeepSea. En el master de Salt, como usuario root, ejecute el comando crontab -e para editar crontab. Suprima los siguientes elementos, si están presentes: 

    # SALT_CRON_IDENTIFIER:deepsea rbd_exporter cron job
*/5 * * * * /var/lib/prometheus/node-exporter/rbd.sh > \
 /var/lib/prometheus/node-exporter/rbd.prom 2> /dev/null
# SALT_CRON_IDENTIFIER:Prometheus rgw_exporter cron job
*/5 * * * * /var/lib/prometheus/node-exporter/ceph_rgw.py > \
 /var/lib/prometheus/node-exporter/ceph_rgw.prom 2> /dev/null

  2. Exporte la configuración del clúster desde DeepSea ejecutando los comandos siguientes: 

    root@master # salt-run upgrade.ceph_salt_config > ceph-salt-config.json
root@master # salt-run upgrade.generate_service_specs > specs.yaml

  3. Desinstale DeepSea e instale ceph-salt en el master de Salt: 

    root@master # zypper remove 'deepsea*'
root@master # zypper install ceph-salt

  4. Reinicie el master de Salt y sincronice los módulos de Salt: 

    root@master # systemctl restart salt-master.service
root@master # salt \* saltutil.sync_all

  5. Importe la configuración del clúster de DeepSea a ceph-salt: 

    root@master # ceph-salt import ceph-salt-config.json

  6. Genere las claves SSH para la comunicación del nodo de clúster: 

    root@master # ceph-salt config /ssh generate
    Sugerencia
    Sugerencia

    Verifique que la configuración del clúster se ha importado desde DeepSea y especifique las opciones que pudieran faltar: 

    root@master # ceph-salt config ls

    Para obtener una descripción completa de la configuración del clúster, consulte la Sección 5.3.2, “Configuración de las propiedades del clúster”.

  7. Aplique la configuración y habilite cephadm: 

    root@master # ceph-salt apply

  8. Si necesita proporcionar la URL del registro del contenedor local y las credenciales de acceso, siga los pasos descritos en la Sección 5.3.2.11, “Configuración del registro del contenedor”.

  9. Si no está utilizando imágenes de contenedor de registration.suse.com, sino el registro configurado localmente, informe a Ceph sobre qué imagen de contenedor debe utilizar ejecutando: 

    root@master # ceph config set global container_image IMAGE_NAME

    Por ejemplo: 

    root@master # ceph config set global container_image 192.168.121.1:5000/my/ceph/image

  10. Detenga e inhabilite los daemons ceph-crash de SUSE Enterprise Storage 6. Los nuevos formularios en contenedores de estos daemons se inician más tarde automáticamente. 

    root@master # salt '*' service.stop ceph-crash
root@master # salt '*' service.disable ceph-crash

7.6 Actualización y adopción de la pila de supervisión

 

El siguiente procedimiento adopta todos los componentes de la pila de supervisión (consulte el Capítulo 16, Supervisión y alertas para obtener más información).

  1. Ponga en pausa el orquestador: 

    cephuser@adm > ceph orch pause

  2. En cualquier nodo en el que se ejecute Prometheus, Grafana y Alertmanager (el master de Salt por defecto), ejecute los comandos siguientes: 

    cephuser@adm > cephadm adopt --style=legacy --name prometheus.$(hostname)
cephuser@adm > cephadm adopt --style=legacy --name alertmanager.$(hostname)
cephuser@adm > cephadm adopt --style=legacy --name grafana.$(hostname)
    Sugerencia
    Sugerencia

    Si no está ejecutando el registro de imágenes de contenedor por defecto, registration.suse.com, debe especificar la imagen que desea utilizar, por ejemplo: 

    cephuser@adm > cephadm --image 192.168.121.1:5000/caasp/v4.5/prometheus-server:2.18.0 \
  adopt --style=legacy --name prometheus.$(hostname)
cephuser@adm > cephadm --image 192.168.121.1:5000/caasp/v4.5/prometheus-alertmanager:0.16.2 \
  adopt --style=legacy --name alertmanager.$(hostname)
cephuser@adm > cephadm --image 192.168.121.1:5000/ses/7/ceph/grafana:7.0.3 \
 adopt --style=legacy --name grafana.$(hostname)

    Para obtener más información sobre el uso de imágenes de contenedor personalizadas o locales, consulte el Sección 16.1, “Configuración de imágenes personalizadas o locales”.

  3. Elimine Node-Exporter. No es necesario migrarlo y se volverá a instalar como contenedor cuando se aplique el archivo specs.yaml. 

    tux > sudo zypper rm golang-github-prometheus-node_exporter

  4. Aplique las especificaciones de servicio que exportó anteriormente desde DeepSea: 

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

  5. Reanude el orquestador: 

    cephuser@adm > ceph orch resume

7.7 Redistribución del servicio de pasarela

 

7.7.1 Actualización de Object Gateway

 

En SUSE Enterprise Storage 7, las pasarelas Object Gateway siempre se configuran con un dominio, lo que permite utilizar varios sitios en el futuro (consulte el Sección 21.13, “Pasarelas Object Gateway de varios sitios” para obtener más información). Si ha utilizado una configuración de Object Gateway de un solo sitio en SUSE Enterprise Storage 6, siga estos pasos para añadir un dominio. Si no tiene previsto utilizar la funcionalidad de varios sitios, puede utilizar el valor por defecto para los nombres de dominio, grupo de zonas y zona.

  1. Cree un dominio nuevo: 

    cephuser@adm > radosgw-admin realm create --rgw-realm=REALM_NAME --default

  2. Opcionalmente, cambie el nombre de la zona y el grupo de zonas por defecto. 

    cephuser@adm > radosgw-admin zonegroup rename \
 --rgw-zonegroup default \
 --zonegroup-new-name=ZONEGROUP_NAME
cephuser@adm > radosgw-admin zone rename \
 --rgw-zone default \
 --zone-new-name ZONE_NAME \
 --rgw-zonegroup=ZONEGROUP_NAME

  3. Configure el grupo de zona principal: 

    cephuser@adm > radosgw-admin zonegroup modify \
 --rgw-realm=REALM_NAME \
 --rgw-zonegroup=ZONEGROUP_NAME \
 --endpoints http://RGW.EXAMPLE.COM:80 \
 --master --default

  4. Configure la zona principal. Para ello, necesitará los valores de ACCESS_KEY y SECRET_KEY de un usuario de Object Gateway con el indicador system habilitado. Suele ser el usuario admin. Para obtener los valores de ACCESS_KEY y SECRET_KEY, ejecute radosgw-admin user info --uid admin. 

    cephuser@adm > radosgw-admin zone modify \
 --rgw-realm=REALM_NAME \
 --rgw-zonegroup=ZONEGROUP_NAME \
 --rgw-zone=ZONE_NAME \
 --endpoints http://RGW.EXAMPLE.COM:80 \
 --access-key=ACCESS_KEY \
 --secret=SECRET_KEY \
 --master --default

  5. Asigne la configuración actualizada: 

    cephuser@adm > radosgw-admin period update --commit

Para que el servicio Object Gateway se convierta en contenedores, cree su archivo de especificación como se describe en la Sección 5.4.3.4, “Distribución de pasarelas Object Gateways” y aplíquelo. 

cephuser@adm > ceph orch apply -i RGW.yml

7.7.2 Actualización de NFS Ganesha

 

A continuación se muestra cómo migrar un servicio existente de NFS Ganesha con Ceph Nautilus a un contenedor de NFS Ganesha con Ceph Octopus.

Aviso
Aviso

Para los pasos siguientes es preciso que haya actualizado correctamente los servicios principales de Ceph.

NFS Ganesha almacena configuraciones adicionales por daemon y exporta la configuración en un repositorio RADOS. El repositorio RADOS configurado se puede encontrar en la línea watch_url del bloque RADOS_URLS en el archivo ganesha.conf. Por defecto, este repositorio se llamará ganesha_config.

Antes de iniciar cualquier migración, se recomienda encarecidamente realizar una copia de los objetos de exportación y de configuración del daemon ubicados en el repositorio RADOS. Para localizar el repositorio RADOS configurado, ejecute el comando siguiente: 

cephuser@adm > grep -A5 RADOS_URLS /etc/ganesha/ganesha.conf

Para mostrar el contenido del repositorio RADOS: 

cephuser@adm > rados --pool ganesha_config --namespace ganesha ls | sort
  conf-node3
  export-1
  export-2
  export-3
  export-4

Para copiar los objetos RADOS: 

cephuser@adm > RADOS_ARGS="--pool ganesha_config --namespace ganesha"
cephuser@adm > OBJS=$(rados $RADOS_ARGS ls)
cephuser@adm > for obj in $OBJS; do rados $RADOS_ARGS get $obj $obj; done
cephuser@adm > ls -lah
total 40K
drwxr-xr-x 2 root root 4.0K Sep 8 03:30 .
drwx------ 9 root root 4.0K Sep 8 03:23 ..
-rw-r--r-- 1 root root 90 Sep 8 03:30 conf-node2
-rw-r--r-- 1 root root 90 Sep 8 03:30 conf-node3
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-1
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-2
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-3
-rw-r--r-- 1 root root 358 Sep 8 03:30 export-4

Es necesario detener el servicio de NFS Ganesha existente en cada nodo de uno en uno y, a continuación, sustituirlo por un contenedor gestionado por cephadm.

  1. Detenga e inhabilite el servicio de NFS Ganesha existente: 

    cephuser@adm > systemctl stop nfs-ganesha
cephuser@adm > systemctl disable nfs-ganesha

  2. Después de detener el servicio de NFS Ganesha existente, se puede distribuir uno nuevo en un contenedor mediante cephadm. Para ello, debe crear una especificación de servicio que contenga un service_id que se utilizará para identificar este nuevo clúster de NFS, el nombre de host del nodo que estamos migrando mostrado como host en la especificación de colocación, y el repositorio RADOS y el espacio de nombres que contiene los objetos de exportación NFS configurados. Por ejemplo: 

    service_type: nfs
service_id: SERVICE_ID
placement:
  hosts:
  - node2
  pool: ganesha_config
  namespace: ganesha

    Para obtener más información sobre cómo crear una especificación de colocación, consulte la Sección 5.4.2, “Especificación del servicio y la colocación”.

  3. Aplique la especificación de colocación: 

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

  4. Confirme que el daemon de NFS Ganesha se está ejecutando en el host: 

    cephuser@adm > ceph orch ps --daemon_type nfs
NAME           HOST   STATUS         REFRESHED  AGE  VERSION  IMAGE NAME                                IMAGE ID      CONTAINER ID
nfs.foo.node2  node2  running (26m)  8m ago     27m  3.3      registry.suse.com/ses/7/ceph/ceph:latest  8b4be7c42abd  c8b75d7c8f0d

  5. Repita estos pasos para cada nodo de NFS Ganesha. No es necesario crear una especificación de servicio independiente para cada nodo. Basta con añadir el nombre de host de cada nodo a la especificación del servicio NFS existente y volver a aplicarlo.

Las exportaciones existentes se pueden migrar de dos formas distintas:

  • Volviéndolas a crear o a asignar manualmente mediante Ceph Dashboard.

  • Copiando manualmente el contenido de cada objeto RADOS por daemon en la configuración común de NFS Ganesha recién creada.

Procedimiento 7.1: Copia manual de las exportaciones al archivo de configuración común de NFS Ganesha
 

  1. Determine la lista de objetos RADOS por daemon: 

    cephuser@adm > RADOS_ARGS="--pool ganesha_config --namespace ganesha"
cephuser@adm > DAEMON_OBJS=$(rados $RADOS_ARGS ls | grep 'conf-')

  2. Realice una copia de los objetos RADOS por daemon: 

    cephuser@adm > for obj in $DAEMON_OBJS; do rados $RADOS_ARGS get $obj $obj; done
cephuser@adm > ls -lah
total 20K
drwxr-xr-x 2 root root 4.0K Sep 8 16:51 .
drwxr-xr-x 3 root root 4.0K Sep 8 16:47 ..
-rw-r--r-- 1 root root 90 Sep 8 16:51 conf-nfs.SERVICE_ID
-rw-r--r-- 1 root root 90 Sep 8 16:51 conf-node2
-rw-r--r-- 1 root root 90 Sep 8 16:51 conf-node3

  3. Ordene y fusione en una sola lista de exportaciones: 

    cephuser@adm > cat conf-* | sort -u > conf-nfs.SERVICE_ID
cephuser@adm > cat conf-nfs.foo
%url "rados://ganesha_config/ganesha/export-1"
%url "rados://ganesha_config/ganesha/export-2"
%url "rados://ganesha_config/ganesha/export-3"
%url "rados://ganesha_config/ganesha/export-4"

  4. Escriba el nuevo archivo de configuración común de NFS Ganesha: 

    cephuser@adm > rados $RADOS_ARGS put conf-nfs.SERVICE_ID conf-nfs.SERVICE_ID

  5. Notifíqueselo al daemon de NFS Ganesha: 

    cephuser@adm > rados $RADOS_ARGS notify conf-nfs.SERVICE_ID conf-nfs.SERVICE_ID
    Nota
    Nota

    Esta acción hará que el daemon vuelva a cargar la configuración.

Después de que el servicio se haya migrado correctamente, se puede eliminar el servicio de NFS Ganesha basado en Nautilus.

  1. Elimine NFS Ganesha: 

    cephuser@adm > zypper rm nfs-ganesha
Reading installed packages...
Resolving package dependencies...
The following 5 packages are going to be REMOVED:
  nfs-ganesha nfs-ganesha-ceph nfs-ganesha-rados-grace nfs-ganesha-rados-urls nfs-ganesha-rgw
5 packages to remove.
After the operation, 308.9 KiB will be freed.
Continue? [y/n/v/...? shows all options] (y): y
(1/5) Removing nfs-ganesha-ceph-2.8.3+git0.d504d374e-3.3.1.x86_64 .................................................................................................................................................................................................................................................................................................[done]
(2/5) Removing nfs-ganesha-rgw-2.8.3+git0.d504d374e-3.3.1.x86_64 ..................................................................................................................................................................................................................................................................................................[done]
(3/5) Removing nfs-ganesha-rados-urls-2.8.3+git0.d504d374e-3.3.1.x86_64 ...........................................................................................................................................................................................................................................................................................[done]
(4/5) Removing nfs-ganesha-rados-grace-2.8.3+git0.d504d374e-3.3.1.x86_64 ..........................................................................................................................................................................................................................................................................................[done]
(5/5) Removing nfs-ganesha-2.8.3+git0.d504d374e-3.3.1.x86_64 ......................................................................................................................................................................................................................................................................................................[done]
Additional rpm output:
warning: /etc/ganesha/ganesha.conf saved as /etc/ganesha/ganesha.conf.rpmsave

  2. Elimine la configuración del clúster heredada de Ceph Dashboard: 

    cephuser@adm > ceph dashboard reset-ganesha-clusters-rados-pool-namespace

7.7.3 Actualización del servidor de metadatos

 

A diferencia de los servicios MON, MGR y OSD, el servidor de metadatos no se puede adoptar in situ. En su lugar, debe volver a distribuirlo en contenedores mediante Ceph Orchestrator.

  1. Ejecute el comando ceph fs ls para obtener el nombre del sistema de archivos, por ejemplo: 

    cephuser@adm > ceph fs ls
name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]

  2. Cree un nuevo archivo de especificación de servicio mds.yml tal como se describe en la Sección 5.4.3.3, “Distribución de servidores de metadatos” utilizando el nombre del sistema de archivos como service_id y especificando los hosts que ejecutarán los daemons de MDS. Por ejemplo: 

    service_type: mds
service_id: cephfs
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3

  3. Ejecute el comando ceph orch apply -i mds.yml para aplicar la especificación de servicio e iniciar los daemons de MDS.

7.7.4 Actualización de iSCSI Gateway

 

Para actualizar iSCSI Gateway, debe volver a distribuirlo en contenedores mediante Ceph Orchestrator. Si dispone de varias pasarelas iSCSI Gateway, deberá volver a distribuirlas una a una para reducir el tiempo de inactividad del servicio.

  1. Detenga e inhabilite los daemons iSCSI existentes en cada nodo iSCSI Gateway: 

    tux > sudo systemctl stop rbd-target-gw
tux > sudo systemctl disable rbd-target-gw
tux > sudo systemctl stop rbd-target-api
tux > sudo systemctl disable rbd-target-api

  2. Cree una especificación de servicio para iSCSI Gateway como se describe en la Sección 5.4.3.5, “Distribución de pasarelas iSCSI Gateway”. Para ello, necesita los ajustes pool, trusted_ip_list y api_* del archivo /etc/ceph/iscsi-gateway.cfg existente. Si tiene habilitada la compatibilidad con SSL (api_secure = true), también necesitará el certificado SSL (/etc/ceph/iscsi-gateway.crt) y la clave (/etc/ceph/iscsi-gateway.key).

    Por ejemplo, si /etc/ceph/iscsi-gateway.cfg contiene lo siguiente: 

    [config]
cluster_client_name = client.igw.ses-min5
pool = iscsi-images
trusted_ip_list = 10.20.179.203,10.20.179.201,10.20.179.205,10.20.179.202
api_port = 5000
api_user = admin
api_password = admin
api_secure = true

    Debe crear el siguiente archivo de especificación de servicio iscsi.yml: 

    service_type: iscsi
service_id: igw
placement:
  hosts:
  - ses-min5
spec:
  pool: iscsi-images
  trusted_ip_list: "10.20.179.203,10.20.179.201,10.20.179.205,10.20.179.202"
  api_port: 5000
  api_user: admin
  api_password: admin
  api_secure: true
  ssl_cert: |
    -----BEGIN CERTIFICATE-----
    MIIDtTCCAp2gAwIBAgIYMC4xNzc1NDQxNjEzMzc2MjMyXzxvQ7EcMA0GCSqGSIb3
    DQEBCwUAMG0xCzAJBgNVBAYTAlVTMQ0wCwYDVQQIDARVdGFoMRcwFQYDVQQHDA5T
    [...]
    -----END CERTIFICATE-----
  ssl_key: |
    -----BEGIN PRIVATE KEY-----
    MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC5jdYbjtNTAKW4
    /CwQr/7wOiLGzVxChn3mmCIF3DwbL/qvTFTX2d8bDf6LjGwLYloXHscRfxszX/4h
    [...]
    -----END PRIVATE KEY-----
    Nota
    Nota

    Los ajustes pool, trusted_ip_list, api_port, api_user, api_password y api_secure son idénticos a los del archivo /etc/ceph/iscsi-gateway.cfg. Los ajustes ssl_cert y ssl_key se pueden copiar desde el certificado SSL existente y los archivos de clave. Compruebe que están sangrados correctamente y que el carácter de barra vertical (|) aparece al final de las líneas ssl_cert: y ssl_key: (consulte el contenido del archivo iscsi.yml más arriba).

  3. Ejecute el comando ceph orch apply -i iscsi.yml para aplicar la especificación del servicio e iniciar los daemons de iSCSI Gateway.

  4. Elimine el paquete ceph-iscsi antiguo de todos los nodos de iSCSI Gateway existentes: 

    cephuser@adm > zypper rm -u ceph-iscsi

7.8 Limpieza posterior a la actualización

 

Después de la actualización, realice los siguientes pasos de limpieza:

  1. Verifique que el clúster se haya actualizado correctamente comprobando la versión actual de Ceph: 

    cephuser@adm > ceph versions

  2. Asegúrese de que ningún OSD antiguo se va a unir al clúster: 

    cephuser@adm > ceph osd require-osd-release octopus

  3. Habilite el módulo de escalador automático: 

    cephuser@adm > ceph mgr module enable pg_autoscaler
    Importante
    Importante

    Los repositorios de SUSE Enterprise Storage 6 tenían el valor pg_autoscale_mode definido por defecto como warn. Esto daba como resultado un mensaje de advertencia en caso de que hubiera un número de grupos de colocación que no fuera óptimo, pero el ajuste automático de escala no se producía. El ajuste por defecto en SUSE Enterprise Storage 7 es que la opción pg_autoscale_mode está en on para los nuevos repositorios, y los grupos de colocación se autoescalan. El proceso de actualización no cambia automáticamente el valor de pg_autoscale_mode de los repositorios existentes. Si desea cambiarlo a on para obtener todas las ventajas del escalador automático, consulte las instrucciones del Sección 17.4.12, “Habilitación del escalador automático de grupos de colocación”.

    Más detalles en el Sección 17.4.12, “Habilitación del escalador automático de grupos de colocación”.

  4. Impida los clientes anteriores a Luminous: 

    cephuser@adm > ceph osd set-require-min-compat-client luminous

  5. Habilite el módulo de equilibrador: 

    cephuser@adm > ceph balancer mode upmap
cephuser@adm > ceph balancer on

    Más detalles en el Sección 29.1, “Equilibrador”.

  6. También puede habilitar el módulo de telemetría: 

    cephuser@adm > ceph mgr module enable telemetry
cephuser@adm > ceph telemetry on

    Más detalles en el Sección 29.2, “Habilitación del módulo de telemetría”.