El componente básico de Ceph se denomina RADOS (Reliable Autonomic Distributed Object Store, almacén de objetos distribuido autónomo fiable). Es el encargado de gestionar los datos almacenados en el clúster. Los datos de Ceph se almacenan normalmente como objetos. Cada objeto se compone de un identificador y datos.

RADOS proporciona los siguientes métodos de acceso para los objetos almacenados que abarcan muchos casos de uso:

librados se utiliza en Object Gateway y RBD, mientras que CephFS interactúa directamente con RADOS (Figura 1.1, “Interfaces con el almacén de objetos de Ceph”).

Figura 1.1: Interfaces con el almacén de objetos de Ceph #

 

En el núcleo de un clúster de Ceph se encuentra el algoritmo CRUSH. CRUSH es el acrónimo de Controlled Replication Under Scalable Hashing (réplica controlada bajo hash escalable). Es una función que gestiona la asignación del almacenamiento y, en comparación con otros algoritmos, necesita pocos parámetros. Es decir, que solo necesita una pequeña cantidad de información para calcular la posición de almacenamiento de un objeto. Los parámetros son un mapa actual del clúster, incluido el estado de actividad, algunas reglas de colocación definidas por el administrador y el nombre del objeto que se va a almacenar o recuperar. Con esta información, todos los nodos del clúster de Ceph pueden calcular dónde está almacenado un objeto y sus réplicas. De esta forma, la escritura o lectura de los datos se realiza de forma muy eficaz. CRUSH intenta distribuir homogéneamente los datos por todos los nodos del clúster.

El mapa de CRUSH contiene todos los nodos de almacenamiento y las reglas de colocación definidas por el administrador para almacenar los objetos en el clúster. Define una estructura jerárquica que se suele corresponder con la estructura física del clúster. Por ejemplo, los discos que contienen los datos están en hosts, los hosts están en bastidores, los bastidores en filas y las filas en centros de datos. Esta estructura se puede utilizar para definir dominios de fallo. Ceph se asegura de que las réplicas se almacenan en diferentes ramas de un dominio de fallo concreto.

Si el dominio de fallo se define en el bastidor, las réplicas de los objetos se distribuyen en distintos bastidores. Esto puede mitigar las interrupciones causadas por un conmutador que falle en un bastidor. Si una unidad de distribución de alimentación da energía a una fila de bastidores, el dominio de fallo se puede definir en la fila. Cuando se produce un fallo en la unidad de distribución de alimentación, los datos replicados siguen disponibles en las demás filas.

En Ceph, los nodos son servidores que trabajan para el clúster. Pueden ejecutar distintos tipos de daemons. Se recomienda ejecutar solo un tipo de daemon en cada nodo, excepto los daemons de Ceph Manager, que se pueden colocar junto con monitores Ceph Monitor. Cada clúster requiere al menos los daemons de Ceph Monitor, Ceph Manager y Ceph OSD:

Para utilizar CephFS, Object Gateway, NFS Ganesha o iSCSI Gateway se necesitan nodos adicionales:

Los objetos que se almacenan en un clúster de Ceph se colocan en repositorios. Los repositorios representan particiones lógicas del clúster hacia el mundo exterior. Por cada repositorio, es posible definir un conjunto de reglas; por ejemplo, cuántas réplicas de cada objeto deben existir. La configuración estándar de los repositorios se denomina repositorio replicado.

Los repositorios suelen contener objetos, pero también pueden configurarse para actuar como si fueran un sistema RAID 5. En esta configuración, los objetos se almacenan en porciones junto con porciones de código adicionales. Las porciones de código contienen información redundante. El administrador puede definir el número de datos y de porciones de código. En esta configuración, los repositorios se denominan repositorios codificados de borrado o repositorios EC.

Los grupos de colocación (PG) se utilizan para la distribución de datos dentro de un repositorio. Cuando se crea un repositorio, se define un número determinado de grupos de colocación. Los grupos de colocación se utilizan de modo interno para agrupar objetos y son un factor importante para el rendimiento de un clúster de Ceph. El grupo de colocación para un objeto se determina según el nombre del objeto.

Esta sección proporciona un ejemplo de cómo gestiona Ceph los datos (consulte la Figura 1.2, “Ejemplo de Ceph a pequeña escala”). El ejemplo no representa una configuración recomendada de un clúster de Ceph. El hardware está formado por tres nodos de almacenamiento o tres Ceph OSD (Host 1, Host 2 y Host 3). Cada nodo tiene tres discos duros que se utilizan como OSD (osd.1 a osd.9). Los nodos de Ceph Monitor no se tratan en este ejemplo.

Nota: diferencia entre Ceph OSD y OSD

Ceph OSD o daemon Ceph OSD hace referencia a un daemon que se ejecuta en un nodo, mientras que el término OSD hace referencia al disco lógico con el que interactúa el daemon.

El clúster tiene dos repositorios, Repositorio A y Repositorio B. Mientras Repositorio A replica objetos solo dos veces, la capacidad de recuperación de Repositorio B es más importante y tiene tres réplicas para cada objeto.

Cuando una aplicación coloca un objeto en un repositorio, por ejemplo, mediante la API REST, se selecciona un grupo de colocación (PG1 a PG4) según el repositorio y el nombre del objeto. El algoritmo CRUSH calcula en qué OSD se almacena el objeto, según el grupo de colocación que contiene el objeto.

En este ejemplo, el dominio de fallo está definido en el host. Esto garantiza que las réplicas de los objetos se almacenan en distintos hosts. Según el nivel de réplica que se defina para un repositorio, el objeto se almacenará en dos o en tres de los OSD que usa el grupo de colocación.

Una aplicación que escribe un objeto solo interactúa con un Ceph OSD: el Ceph OSD primario. El Ceph OSD primario se encarga de la réplica y confirma que el proceso de escritura ha terminado después de que todos los demás OSD hayan almacenado el objeto.

Si falla osd.5, todos los objetos de PG1 siguen estando disponibles en osd.1. En cuanto el clúster reconoce que un OSD ha fallado, otro OSD toma su lugar. En este ejemplo, osd.4 se utiliza como sustituto de osd.5. Los objetos almacenados en osd.1 se replican a osd.4 para restaurar el nivel de réplica.

Figura 1.2: Ejemplo de Ceph a pequeña escala #

 

Si se añade un nuevo nodo con nuevos OSD al clúster, el mapa del clúster cambia. La función CRUSH devuelve ubicaciones diferentes para los objetos. los objetos que reciben las nuevas ubicaciones se reubican. Este proceso da como resultado un uso equilibrado de todos los OSD.

Se recomienda tener una única red tolerante a fallos con suficiente ancho de banda para satisfacer sus necesidades. Para el entorno de red pública de Ceph, se recomiendan dos interfaces de red de 25 GbE (o más rápidas) asociadas mediante 802.3ad (LACP). Esto se considera la configuración mínima para Ceph. Si también utiliza una red de clúster, se recomiendan cuatro interfaces de red de 25 GbE asociadas. La asociación de dos o más interfaces de red proporciona un mejor rendimiento mediante la agregación de enlaces y, mediante enlaces y conmutadores redundantes, mejora la tolerancia a fallos y la facilidad de mantenimiento.

También puede crear VLAN para aislar diferentes tipos de tráfico a través de una asociación. Por ejemplo, puede crear una asociación para proporcionar dos interfaces VLAN, una para la red pública y la segunda para la red de clúster. Sin embargo, esto no es necesario al configurar la red de Ceph. Encontrará información detallada sobre la asociación de las interfaces en https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-network.html#sec-network-iface-bonding.

La tolerancia a fallos se puede mejorar aislando los componentes en dominios de fallo. Para mejorar la tolerancia a fallos de la red, la asociación de una interfaz desde dos tarjetas de interfaz de red (NIC) independientes ofrece protección contra fallos de una sola NIC. Del mismo modo, la creación de una asociación entre dos conmutadores protege contra el fallo de un conmutador. Se recomienda consultar con el proveedor del equipo de red para determinar el nivel de tolerancia a fallos necesario.

Importante: red de administración no compatible

La configuración de red de administración adicional (que permite, por ejemplo, separar las redes SSH, Salt o DNS) no se ha probado ni se admite.

Sugerencia: nodos configurados a través de DHCP

Si los nodos de almacenamiento se configuran a través de DHCP, es posible que los tiempos límite por defecto no sean suficientes para que la red se configure de forma correcta antes de que se inicien los daemons de Ceph. Si esto ocurre, los MON y los OSD de Ceph no se iniciarán correctamente (al ejecutar systemctl status ceph\* se producirán errores de tipo "no se puede asociar"). Para evitar este problema, se recomienda aumentar el tiempo límite del cliente DHCP a al menos 30 segundos en cada nodo del clúster de almacenamiento. Para hacerlo, hay que cambiar los valores siguientes en cada nodo:

En /etc/sysconfig/network/dhcp, defina

DHCLIENT_WAIT_AT_BOOT="30"

En /etc/sysconfig/network/config, defina

WAIT_FOR_INTERFACES="60"

2.1.1.2 Nodos de monitor en subredes diferentes #

 

Si los nodos de monitor se encuentran en varias subredes, por ejemplo, se encuentran en distintas salas y emplean conmutadores distintos, es necesario especificar la dirección de la red pública con notación CIDR.

cephuser@adm > ceph config set mon public_network "MON_NETWORK_1, MON_NETWORK_2, MON_NETWORK_N

Por ejemplo:

cephuser@adm > ceph config set mon public_network "192.168.1.0/24, 10.10.0.0/16"

Aviso

Si especifica más de un segmento de red para la red pública (o de clúster) como se describe en esta sección, cada una de estas subredes debe ser capaz de encaminarse a todas las demás; de lo contrario, los MON y otros daemons de Ceph en diferentes segmentos de la red no podrán comunicarse entre sí y se producirá una situación de clústeres malinformados. Además, si está utilizando un cortafuegos, asegúrese de incluir cada dirección IP o subred en sus iptables y abrir puertos para ellos en todos los nodos según sea necesario.

Una configuración de clúster mínima para el producto consta de:

Una configuración detallada está formada por:

Figura 2.2: Configuración de clúster mínima #

 

Si el tamaño del clúster ha aumentado, se recomienda reubicar los monitores Ceph Monitor, los servidores de metadatos y las pasarelas en nodos independientes para mejorar la tolerancia a fallos.

Si desea utilizar hardware de múltiples rutas, asegúrese de que LVM puede acceder a multipath_component_detection = 1 en el archivo de configuración en la sección devices (dispositivos). Esto se puede comprobar mediante el comando lvm config.

Como alternativa, asegúrese de que LVM filtre los componentes de múltiples rutas de un dispositivo mediante la configuración de filtro de LVM. Esto será específico para cada host.

Nota

Esta configuración no se recomienda y solo debe plantearse si no es posible definir multipath_component_detection = 1.

Para obtener más información acerca de la configuración de múltiples rutas, consulte https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-multipath.html#sec-multipath-lvm.

Existen dos tipos de espacio de disco necesarios para ejecutarse en OSD: el espacio para el dispositivo WAL/DB, y el espacio principal para los datos almacenados. El valor mínimo (y por defecto) para WAL/DB es de 6 GB. El espacio mínimo para los datos es de 5 GB, ya que a las particiones de menos de 5 GB se les asigna automáticamente un peso de 0.

Por lo tanto, aunque el espacio mínimo de disco para un OSD es de 11 GB, no se recomienda usar discos de menos de 20 GB, ni siquiera con fines de prueba.

Las unidades de estado sólido (SSD) no tienen piezas móviles. Esto reduce el tiempo de acceso aleatorio y la latencia de lectura, a la vez que acelera el rendimiento de los datos. Dado que su precio por MB es mucho mayor que el de los discos duros giratorios, las unidades SSD solo son adecuadas para almacenamiento de menor tamaño.

Los OSD pueden tener una mejora significativa del rendimiento si almacenan sus particiones WAL/DB en una unidad SSD y los datos del objeto en un disco duro independiente.

Sugerencia: uso compartido de una unidad SSD para varias particiones WAL/DB

Dado que las particiones WAL/DB ocupan relativamente poco espacio, puede compartir un disco SSD con varias particiones WAL/DB. Tenga en cuenta que con cada partición WAL/DB, el rendimiento del disco SSD se resiente. No es recomendable compartir más de seis particiones WAL/DB en el mismo disco SSD, o 12 en discos NVMe.

Puede tener tantos discos como permita un servidor. Pero existen algunos asuntos que debe tener en cuenta a la hora de planificar el número de discos por servidor:

SUSE Manager y SUSE Enterprise Storage no están integrados; por lo tanto, SUSE Manager no puede gestionar actualmente un clúster de SES.

Si ejecuta config sin ninguna vía o subcomando, deberá introducir una shell ceph-saltceph-salt interactiva. La shell es útil si necesita configurar varias propiedades en un lote y no desea escribir la sintaxis completa del comando.

root@master # ceph-salt config
/> ls
o- / ............................................................... [...]
  o- ceph_cluster .................................................. [...]
  | o- minions .............................................. [no minions]
  | o- roles ....................................................... [...]
  |   o- admin .............................................. [no minions]
  |   o- bootstrap ........................................... [no minion]
  |   o- cephadm ............................................ [no minions]
  |   o- tuned ..................................................... [...]
  |     o- latency .......................................... [no minions]
  |     o- throughput ....................................... [no minions]
  o- cephadm_bootstrap ............................................. [...]
  | o- advanced .................................................... [...]
  | o- ceph_conf ................................................... [...]
  | o- ceph_image_path .................................. [ no image path]
  | o- dashboard ................................................... [...]
  | | o- force_password_update ................................. [enabled]
  | | o- password ................................................ [admin]
  | | o- ssl_certificate ....................................... [not set]
  | | o- ssl_certificate_key ................................... [not set]
  | | o- username ................................................ [admin]
  | o- mon_ip .................................................. [not set]
  o- containers .................................................... [...]
  | o- registries_conf ......................................... [enabled]
  | | o- registries .............................................. [empty]
  | o- registry_auth ............................................... [...]
  |   o- password .............................................. [not set]
  |   o- registry .............................................. [not set]
  |   o- username .............................................. [not set]
  o- ssh ............................................... [no key pair set]
  | o- private_key .................................. [no private key set]
  | o- public_key .................................... [no public key set]
  o- time_server ........................... [enabled, no server host set]
    o- external_servers .......................................... [empty]
    o- servers ................................................... [empty]
    o- subnet .................................................. [not set]

Como puede ver en el resultado del comando ceph-saltls de , la configuración del clúster está organizada en una estructura de árbol. Para configurar una propiedad específica del clúster en la shell ceph-salt, tiene dos opciones:

Sugerencia: autocompletado de fragmentos de configuración

En una shell ceph-salt, puede utilizar la función de autocompletado de forma similar a la de una shell de Linux normal (Bash). Completa vías de configuración, subcomandos o nombres de minions de Salt. Para autocompletar una vía de configuración, tiene dos opciones:

• Para permitir que la shell termine una vía relativa a su posición actual, pulse la tecla TAB →| dos veces.

• Para permitir que la shell termine una vía absoluta, introduzca / y pulse la tecla TAB →| dos veces.

Sugerencia: navegación con las teclas del cursor

Si escribe cd desde la shell ceph-salt sin ninguna vía, el comando producirá una estructura de árbol de la configuración del clúster con la línea de la vía actual activa. Puede utilizar las teclas de cursor arriba y abajo para desplazarse por cada línea. Después de confirmar con Intro, la vía de configuración cambiará a la última activa.

Importante: convención

Para mantener la coherencia de la documentación, se utilizará una sintaxis de comando única sin entrar en la shell ceph-salt. Por ejemplo, puede mostrar el árbol de configuración del clúster mediante el comando siguiente:

root@master # ceph-salt config ls

Incluya todos los minions de Salt que se han distribuido y aceptado en la Capítulo 6, Distribución de Salt, o un subconjunto de ellos, en la configuración del clúster de Ceph. Puede especificar los minions de Salt por sus nombres completos o utilizar las expresiones globales "*" y "?" para incluir varios minions de Salt a la vez. Utilice el subcomando add en la vía /ceph_cluster/minions. El comando siguiente incluye todos los minions de Salt aceptados:

root@master # ceph-salt config /ceph_cluster/minions add '*'

Compruebe que se han añadido los minions de Salt especificados:

root@master # ceph-salt config /ceph_cluster/minions ls
o- minions ................................................. [Minions: 5]
  o- ses-master.example.com .................................. [no roles]
  o- ses-min1.example.com .................................... [no roles]
  o- ses-min2.example.com .................................... [no roles]
  o- ses-min3.example.com .................................... [no roles]
  o- ses-min4.example.com .................................... [no roles]

Especifique qué nodos pertenecerán al clúster de Ceph y se gestionarán mediante cephadm. Incluya todos los nodos que ejecutarán servicios de Ceph, así como el nodo de administración:

root@master # ceph-salt config /ceph_cluster/roles/cephadm add '*'

El nodo de administración es el nodo en el que se instalan el archivo de configuración ceph.conf y el anillo de claves de administración de Ceph. Normalmente, los comandos relacionados con Ceph se ejecutan en el nodo de administración.

Sugerencia: master de Salt y nodo de administración en el mismo nodo

En un entorno homogéneo en el que todos o la mayoría de los hosts pertenezcan a SUSE Enterprise Storage, se recomienda tener el nodo de administración en el mismo host que el master de Salt.

En un entorno heterogéneo en el que una infraestructura de Salt aloje más de un clúster, por ejemplo, SUSE Enterprise Storage junto con SUSE Manager, no coloque el nodo de administración en el mismo host que el master de Salt.

Para especificar el nodo de administración, ejecute el comando siguiente:

root@master # ceph-salt config /ceph_cluster/roles/admin add ses-master.example.com
1 minion added.
root@master # ceph-salt config /ceph_cluster/roles/admin ls
o- admin ................................................... [Minions: 1]
  o- ses-master.example.com ...................... [Other roles: cephadm]

Sugerencia: instalación de ceph.conf y el anillo de claves de administración en varios nodos

Puede instalar el archivo de configuración de Ceph y el anillo de claves del administrador en varios nodos si la distribución lo requiere. Por motivos de seguridad, evite instalarlos en todos los nodos del clúster.

Debe especificar cuál de los minions de Salt del clúster arrancará el clúster. Este minion se convertirá en el primero en ejecutar los servicios de Ceph Monitor y Ceph Manager.

root@master # ceph-salt config /ceph_cluster/roles/bootstrap set ses-min1.example.com
Value set.
root@master # ceph-salt config /ceph_cluster/roles/bootstrap ls
o- bootstrap ..................................... [ses-min1.example.com]

Además, debe especificar la dirección IP de carga del monitor en la red pública para asegurarse de que el parámetro public_network está definido correctamente, por ejemplo:

root@master # ceph-salt config /cephadm_bootstrap/mon_ip set 192.168.10.20

Debe especificar qué minions del clúster tienen perfiles ajustados de forma activa. Para ello, añada estas funciones explícitamente con los comandos siguientes:

Nota

Un minion no puede tener las funciones latency (latencia) y throughput (rendimiento).

root@master # ceph-salt config /ceph_cluster/roles/tuned/latency add ses-min1.example.com
Adding ses-min1.example.com...
1 minion added.
root@master # ceph-salt config /ceph_cluster/roles/tuned/throughput add ses-min2.example.com
Adding ses-min2.example.com...
1 minion added.

cephadm utiliza el protocolo SSH para comunicarse con los nodos del clúster. Se crea automáticamente una cuenta de usuario denominada cephadm que se utiliza para la comunicación SSH.

Debe generar la parte privada y la pública del par de claves SSH:

root@master # ceph-salt config /ssh generate
Key pair generated.
root@master # ceph-salt config /ssh ls
o- ssh .................................................. [Key Pair set]
  o- private_key ..... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]
  o- public_key ...... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]

Todos los nodos del clúster deben tener su hora sincronizada con un origen horario fiable. Existen varios escenarios para abordar la sincronización horaria:

Compruebe los ajustes del servidor horario:

root@master # ceph-salt config /time_server ls
o- time_server ................................................ [enabled]
  o- external_servers ............................................... [1]
  | o- pool.ntp.org ............................................... [...]
  o- servers ........................................................ [1]
  | o- ses-master.example.com ..................................... [...]
  o- subnet .............................................. [10.20.6.0/24]

Encontrará más información sobre cómo configurar la sincronización horaria en https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-ntp.html#sec-ntp-yast.

Ceph Dashboard estará disponible después de la distribución del clúster básico. Para acceder a la consola, debe definir un nombre de usuario y una contraseña válidos, por ejemplo:

root@master # ceph-salt config /cephadm_bootstrap/dashboard/username set admin
root@master # ceph-salt config /cephadm_bootstrap/dashboard/password set PWD

Sugerencia: forzar la actualización de la contraseña

Por defecto, el primer usuario de la consola se verá obligado a cambiar su contraseña la primera vez que entre a la consola. Para inhabilitar esta función, ejecute el comando siguiente:

root@master # ceph-salt config /cephadm_bootstrap/dashboard/force_password_update disable

El clúster de Ceph debe tener acceso a un registro del contenedor para que pueda descargar y distribuir servicios de Ceph en contenedor. Existen dos formas de acceder al registro:

7.2.10.1 Creación y configuración del registro local (opcional) #

 

Importante

Existen numerosos métodos para crear un registro local. Las instrucciones de esta sección son ejemplos para crear registros seguros y no seguros. Para obtener información general sobre cómo ejecutar un registro de imágenes de contenedor, consulte https://documentation.suse.com/sles/15-SP3/single-html/SLES-container/#sec-docker-registry-installation.

Sugerencia: colocación y uso de puertos

Distribuya el registro en un equipo al que puedan acceder todos los nodos del clúster. Recomendamos el nodo de administración. Por defecto, el registro escucha en el puerto 5000.

En el nodo de registro, utilice el siguiente comando para asegurarse de que el puerto está libre:

ss -tulpn | grep :5000

Si otros procesos (como iscsi-tcmu) ya están escuchando en el puerto 5000, determine otro puerto libre que se pueda utilizar para asignar al puerto 5000 en el contenedor de registro.

Procedimiento 7.1: Creación del registro local #

 

1. Verifique que la extensión Containers Module esté habilitada:

   > SUSEConnect --list-extensions | grep -A2 "Containers Module"
   Containers Module 15 SP3 x86_64 (Activated)

2. Verifique que los siguientes paquetes están instalados: apache2-utils (si se habilita un registro seguro), cni, cni-plugins, podman, podman-cni-config y skopeo.

3. Recopile la siguiente información:

   • Nombre de dominio completo del host de registro (REG_HOST_FQDN).

   • Un número de puerto disponible utilizado para asignar al puerto del contenedor de registro 5000 (REG_HOST_PORT).

   • Si el registro será seguro o no seguro (insecure=[true|false]).

4. Para iniciar un registro no seguro (sin cifrado SSL), siga estos pasos:

   1. Configure ceph-salt para el registro no seguro:

      cephuser@adm > ceph-salt config containers/registries_conf enable
      cephuser@adm > ceph-salt config containers/registries_conf/registries \
       add prefix=REG_HOST_FQDN insecure=true \
       location=REG_HOST_PORT:5000

   2. Inicie el registro no seguro creando el directorio necesario (por ejemplo, /var/lib/registry) e inicie el registro con el comando podman:

      # mkdir -p /var/lib/registry
      # podman run --privileged -d --name registry \
       -p REG_HOST_PORT:5000 -v /var/lib/registry:/var/lib/registry \
       --restart=always registry:2

   3. Para que el registro se inicie después de rearrancar, cree un archivo de unidad systemd para él y habilítelo:

      > sudo podman generate systemd --files --name registry
      > sudo mv container-registry.service /etc/systemd/system/
      > sudo systemctl enable container-registry.service

5. Para iniciar un registro seguro, siga estos pasos:

   1. Cree los directorios necesarios:

      # mkdir -p /var/lib/registry/{auth,certs}

   2. Genere un certificado SSL:

      # openssl req -newkey rsa:4096 -nodes -sha256 \
       -keyout /var/lib/registry/certs/domain.key -x509 -days 365 \
       -out /var/lib/registry/certs/domain.crt

      

      Nota

      Defina el valor CN=[valor] en el nombre de dominio completo del host ([REG_HOST_FQDN]).

   3. Copie el certificado en todos los nodos del clúster y actualice el caché de certificados:

      # salt-cp '*' /var/lib/registry/certs/domain.crt \
       /etc/pki/trust/anchors/
      # salt '*' cmd.shell "update-ca-certificates"

   4. Genere una combinación de nombre de usuario y contraseña para la autenticación en el registro:

      # htpasswd2 -bBc /var/lib/registry/auth/htpasswd \
       REG_USERNAME REG_PASSWORD

   5. Inicie el registro seguro. Utilice el indicador REGISTRY_STORAGE_DELETE_ENABLED=true para poder suprimir las imágenes posteriormente con el comando skopeo delete.

      podman run --name myregistry -p REG_HOST_PORT:5000 \
       -v /var/lib/registry:/var/lib/registry \
       -v /var/lib/registry/auth:/auth:z \
       -e "REGISTRY_AUTH=htpasswd" \
       -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \
       -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \
       -v /var/lib/registry/certs:/certs:z \
       -e "REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt" \
       -e "REGISTRY_HTTP_TLS_KEY=/certs/domain.key" \
       -e REGISTRY_STORAGE_DELETE_ENABLED=true \
       -e REGISTRY_COMPATIBILITY_SCHEMA1_ENABLED=true -d registry:2

   6. Pruebe el acceso seguro al registro:

      > curl https://REG_HOST_FQDN:REG_HOST_PORT/v2/_catalog \
       -u REG_USERNAME:REG_PASSWORD

6. Después de crear el registro local, debe sincronizar las imágenes de contenedor desde el registro oficial de SUSE en registry.suse.com con el registro local. Puede utilizar el comando skopeo sync que se encuentra en el paquete skopeo para ese fin. Para obtener más información, consulte la página de manual (man 1 skopeo-sync). Considere los siguientes ejemplos:

   Ejemplo 7.1: Visualización de archivos de manifiesto #

    

   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/ceph | jq .RepoTags
   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/grafana | jq .RepoTags
   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/prometheus-server:2.32.1 | jq .RepoTags
   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/prometheus-node-exporter:1.1.2 | jq .RepoTags
   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/prometheus-alertmanager:0.21.0 | jq .RepoTags

   Ejemplo 7.2: Sincronización con un directorio #

    

   Sincroniza todas las imágenes de Ceph:

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/ceph /root/images/

   Sincroniza solo las imágenes más recientes:

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/ceph:latest /root/images/

   Ejemplo 7.3: Sincronización de imágenes de Grafana #

    

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/grafana /root/images/

   Sincroniza solo las imágenes de Grafana más recientes:

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/grafana:latest /root/images/

   Ejemplo 7.4: Sincronización de las imágenes más recientes de Prometheus #

    

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/prometheus-server:2.32.1 /root/images/
   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/prometheus-node-exporter:1.1.2 /root/images/
   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/prometheus-alertmanager:0.21.0 /root/images/

Procedimiento 7.2: Configuración del registro local y las credenciales de acceso #

 

1. Configure la URL del registro local:

   cephuser@adm > ceph-salt config /containers/registry_auth/registry set REG_HOST_URL

2. Configure el nombre de usuario y la contraseña para acceder al registro local:

   cephuser@adm > ceph-salt config /containers/registry_auth/username set REG_USERNAME

   cephuser@adm > ceph-salt config /containers/registry_auth/password set REG_PASSWORD

Sugerencia: caché de registro

Para evitar que se deba sincronizar de nuevo el registro local cuando aparezcan nuevos contenedores actualizados, puede configurar un caché de registro.

7.2.10.2 Configuración de la vía a las imágenes de contenedor #

 

Importante

Esta sección ayuda a configurar la vía a las imágenes de contenedor del clúster de bootstrap (distribución del primer par de Ceph Monitor y Ceph Manager). La vía no se aplica a las imágenes de contenedor de servicios adicionales, por ejemplo, la pila de supervisión.

Sugerencia: configuración del proxy HTTPS

Si necesita utilizar un servidor proxy para comunicarse con el servidor de registro del contenedor, realice los siguientes pasos de configuración en todos los nodos del clúster:

1. Copie el archivo de configuración de los contenedores:

   > sudo cp /usr/share/containers/containers.conf /etc/containers/containers.conf

2. Edite el archivo recién copiado y añada el ajuste http_proxy a su sección [engine], por ejemplo:

   > cat /etc/containers/containers.conf
    [engine]
    http_proxy=proxy.example.com
    [...]

cephadm necesita conocer una vía de URI válida a las imágenes del contenedor. Verifique el ajuste por defecto ejecutando:

root@master # ceph-salt config /cephadm_bootstrap/ceph_image_path ls

Si no necesita un registro alternativo o local, especifique el registro de contenedor de SUSE por defecto:

root@master # ceph-salt config /cephadm_bootstrap/ceph_image_path set registry.suse.com/ses/7.1/ceph/ceph

Si la distribución requiere una vía específica, por ejemplo, una vía a un registro local, configúrela de la siguiente manera:

root@master # ceph-salt config /cephadm_bootstrap/ceph_image_path set LOCAL_REGISTRY_PATH

El protocolo Messenger v2 (MSGR2) es el protocolo con conexión de Ceph. Proporciona un modo de seguridad que cifra todos los datos que pasan por la red, encapsula las cargas útiles de autenticación y permite la integración futura de nuevos modos de autenticación (como Kerberos).

Importante

msgr2 no es compatible actualmente con los clientes de Ceph del kernel de Linux, como CephFS y el dispositivo de bloques RADOS.

Los daemons de Ceph se pueden asociar a varios puertos, lo que permite que tanto los clientes de Ceph legados como los nuevos clientes compatibles con v2 se conecten al mismo clúster. Por defecto, los MON se asocian ahora al nuevo puerto 3300 asignado por IANA (CE4h o 0xCE4) para el nuevo protocolo v2, y además se asocian al antiguo puerto por defecto 6789 para el protocolo legado v1.

El protocolo v2 (MSGR2) admite dos modos de conexión:

Para la mayoría de las conexiones, existen opciones que controlan los modos que se utilizan:

Existe un conjunto paralelo de opciones que se aplican específicamente a los monitores, lo que permite a los administradores establecer distintos requisitos (normalmente más seguros) en la comunicación con esos monitores.

Para habilitar el modo de cifrado MSGR2 durante la distribución, debe añadir algunas opciones a la configuración de ceph-salt antes de ejecutar ceph-salt apply.

Para utilizar el modo secure, ejecute los comandos siguientes.

Añada la sección global a ceph_conf en la herramienta de configuración ceph-salt:

root@master # ceph-salt config /cephadm_bootstrap/ceph_conf add global

Defina las opciones siguientes:

root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_cluster_mode "secure crc"
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_service_mode "secure crc"
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_client_mode "secure crc"

Nota

Asegúrese de que secure vaya delante de crc.

Para forzar el modo secure, ejecute los comandos siguientes:

root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_cluster_mode secure
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_service_mode secure
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_client_mode secure

Sugerencia: actualización de ajustes

Si desea cambiar alguno de los ajustes anteriores, defina los cambios de configuración en el almacén de configuración del monitor. Esto se consigue mediante el comando ceph config set.

root@master # ceph config set global CONNECTION_OPTION CONNECTION_MODE [--force]

Por ejemplo:

root@master # ceph config set global ms_cluster_mode "secure crc"

Si desea comprobar el valor actual, incluido el valor por defecto, ejecute el comando siguiente:

root@master # ceph config get CEPH_COMPONENT CONNECTION_OPTION

Por ejemplo, para obtener el modo ms_cluster_mode para los OSD, ejecute:

root@master # ceph config get osd ms_cluster_mode

Opcionalmente, si ejecuta una red de clúster independiente, es posible que deba definir la dirección IP de la red del clúster seguida de la parte de la máscara de subred después de la barra inclinada, por ejemplo: 192.168.10.22/24.

Ejecute los comandos siguientes para habilitar cluster_network:

root@master # ceph-salt config /cephadm_bootstrap/ceph_conf add global
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set cluster_network NETWORK_ADDR

La configuración mínima del clúster ha finalizado. Examínela en busca de errores obvios:

root@master # ceph-salt config ls
o- / ............................................................... [...]
  o- ceph_cluster .................................................. [...]
  | o- minions .............................................. [Minions: 5]
  | | o- ses-master.example.com .................................. [admin]
  | | o- ses-min1.example.com ......................... [bootstrap, admin]
  | | o- ses-min2.example.com ................................. [no roles]
  | | o- ses-min3.example.com ................................. [no roles]
  | | o- ses-min4.example.com ................................. [no roles]
  | o- roles ....................................................... [...]
  |   o- admin .............................................. [Minions: 2]
  |   | o- ses-master.example.com ....................... [no other roles]
  |   | o- ses-min1.example.com ................. [other roles: bootstrap]
  |   o- bootstrap ................................ [ses-min1.example.com]
  |   o- cephadm ............................................ [Minions: 5]
  |   o- tuned ..................................................... [...]
  |     o- latency .......................................... [no minions]
  |     o- throughput ....................................... [no minions]
  o- cephadm_bootstrap ............................................. [...]
  | o- advanced .................................................... [...]
  | o- ceph_conf ................................................... [...]
  | o- ceph_image_path .............. [registry.suse.com/ses/7.1/ceph/ceph]
  | o- dashboard ................................................... [...]
  |   o- force_password_update ................................. [enabled]
  |   o- password ................................... [randomly generated]
  |   o- username ................................................ [admin]
  | o- mon_ip ............................................ [192.168.10.20]
  o- containers .................................................... [...]
  | o- registries_conf ......................................... [enabled]
  | | o- registries .............................................. [empty]
  | o- registry_auth ............................................... [...]
  |   o- password .............................................. [not set]
  |   o- registry .............................................. [not set]
  |   o- username .............................................. [not set]
  o- ssh .................................................. [Key Pair set]
  | o- private_key ..... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]
  | o- public_key ...... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]
  o- time_server ............................................... [enabled]
    o- external_servers .............................................. [1]
    | o- 0.pt.pool.ntp.org ......................................... [...]
    o- servers ....................................................... [1]
    | o- ses-master.example.com .................................... [...]
    o- subnet ............................................. [10.20.6.0/24]

Sugerencia: estado de la configuración del clúster

Puede comprobar si la configuración del clúster es válida ejecutando el comando siguiente:

root@master # ceph-salt status
cluster: 5 minions, 0 hosts managed by cephadm
config: OK

Después de haber configurado el clúster básico y comprobar que su configuración es válida, es recomendable exportar la configuración a un archivo:

root@master # ceph-salt export > cluster.json

Aviso

El resultado de ceph-salt export incluye la clave privada SSH. Si le preocupan las implicaciones de seguridad, no ejecute este comando sin tomar las precauciones oportunas.

En caso de que se interrumpa la configuración del clúster y necesite volver a un estado de copia de seguridad, ejecute:

root@master # ceph-salt import cluster.json

El comando siguiente muestra el modo y el estado actuales de Ceph Orchestrator.

cephuser@adm > ceph orch status

Para mostrar todos los dispositivos del disco, ejecute lo siguiente:

cephuser@adm > ceph orch device ls
Hostname   Path      Type  Serial  Size   Health   Ident  Fault  Available
ses-master /dev/vdb  hdd   0d8a... 10.7G  Unknown  N/A    N/A    No
ses-min1   /dev/vdc  hdd   8304... 10.7G  Unknown  N/A    N/A    No
ses-min1   /dev/vdd  hdd   7b81... 10.7G  Unknown  N/A    N/A    No
[...]

Sugerencia: servicios y daemons

Un servicio es un término general que se usa para un servicio de Ceph de un tipo específico, por ejemplo, Ceph Manager.

Un daemon es una instancia específica de un servicio, por ejemplo, un proceso mgr.ses-min1.gdlcik que se ejecuta en un nodo llamado ses-min1.

Para mostrar todos los servicios conocidos por cephadm, ejecute:

cephuser@adm > ceph orch ls
NAME  RUNNING  REFRESHED  AGE  PLACEMENT  IMAGE NAME                  IMAGE ID
mgr       1/0  5m ago     -    <no spec>  registry.example.com/[...]  5bf12403d0bd
mon       1/0  5m ago     -    <no spec>  registry.example.com/[...]  5bf12403d0bd

Sugerencia

Puede limitar la lista a los servicios de un nodo concreto con el parámetro opcional ‑‑host, y los servicios de un tipo concreto con el parámetro opcional --service-type. Los tipos admitidos son mon, osd, mgr, mds y rgw.

Para mostrar todos los daemons en ejecución distribuidos por cephadm, ejecute:

cephuser@adm > ceph orch ps
NAME            HOST     STATUS   REFRESHED AGE VERSION    IMAGE ID     CONTAINER ID
mgr.ses-min1.gd ses-min1 running) 8m ago    12d 15.2.0.108 5bf12403d0bd b8104e09814c
mon.ses-min1    ses-min1 running) 8m ago    12d 15.2.0.108 5bf12403d0bd a719e0087369

Sugerencia

Para consultar el estado de un daemon concreto, utilice --daemon_type y --daemon_id. Para los OSD, el ID es el ID de OSD numérico. Para MDS, el ID es el nombre del de archivos:

cephuser@adm > ceph orch ps --daemon_type osd --daemon_id 0
cephuser@adm > ceph orch ps --daemon_type mds --daemon_id my_cephfs

Puede crear un archivo de especificación independiente para cada tipo de servicio, por ejemplo:

root@master # cat nfs.yml
service_type: nfs
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min1
  - ses-min2
spec:
  pool: EXAMPLE_POOL
  namespace: EXAMPLE_NAMESPACE

Como alternativa, puede especificar varios tipos de servicios, o todos ellos en un archivo (por ejemplo, cluster.yml) que describe qué nodos ejecutarán servicios específicos. Recuerde separar los tipos de servicios individuales con tres guiones (---):

cephuser@adm > cat cluster.yml
service_type: nfs
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min1
  - ses-min2
spec:
  pool: EXAMPLE_POOL
  namespace: EXAMPLE_NAMESPACE
---
service_type: rgw
service_id: REALM_NAME.ZONE_NAME
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
---
[...]

Las propiedades mencionadas anteriormente tienen el siguiente significado:

Sugerencia: aplicación de servicios específicos

Los servicios del clúster de Ceph suelen tener varias propiedades específicas. Para obtener ejemplos y detalles de cada especificación de servicios, consulte la Sección 8.3, “Distribución de servicios de Ceph”.

Para distribuir los servicios de Ceph, cephadm necesita saber en qué nodos debe distribuirlos. Utilice la propiedad placement y muestre los nombres de host cortos de los nodos a los que se aplica el servicio:

cephuser@adm > cat cluster.yml
[...]
placement:
  hosts:
  - host1
  - host2
  - host3
[...]

Después de crear un archivo cluster.yml completo con las especificaciones de todos los servicios y su colocación, puede aplicar el clúster ejecutando el comando siguiente:

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

Para ver el estado del clúster, ejecute el comando ceph orch status. Para obtener más información, consulte la Sección 8.1.1, “Visualización del estado del orquestador”.

Aunque ha distribuido servicios al clúster de Ceph mediante los archivos de especificación como se describe en la Sección 8.2, “Especificación del servicio y la colocación”, la configuración del clúster puede diferir de la original durante su funcionamiento. Además, es posible que haya eliminado los archivos de especificación accidentalmente.

Para recuperar una especificación completa de un clúster en ejecución, ejecute:

cephuser@adm > ceph orch ls --export
placement:
  hosts:
  - hostname: ses-min1
    name: ''
    network: ''
service_id: my_cephfs
service_name: mds.my_cephfs
service_type: mds
---
placement:
  count: 2
service_name: mgr
service_type: mgr
---
[...]

Sugerencia

Puede añadir la opción --format para cambiar el formato de salida yaml por defecto. Puede seleccionar json, json-pretty o yaml. Por ejemplo:

ceph orch ls --export --format json

El clúster de Ceph tiene tres o cinco MON distribuidos en distintos nodos. Si hay cinco o más nodos en el clúster, se recomienda distribuir cinco MON. Una práctica recomendada consiste en distribuir los MGR en los mismos nodos que los MON.

Importante: inclusión de MON de arranque

Al distribuir MON y MGR, recuerde incluir el primer MON que haya añadido al configurar el clúster básico en la Sección 7.2.5, “Especificación del primer nodo de MON/MGR”.

Para distribuir MON, aplique la siguiente especificación:

service_type: mon
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3

Nota

Si necesita añadir otro nodo, añada el nombre de host al final de la misma lista de YAML. Por ejemplo:

service_type: mon
placement:
 hosts:
 - ses-min1
 - ses-min2
 - ses-min3
 - ses-min4

Del mismo modo, para distribuir MGR, aplique la siguiente especificación:

Importante

Asegúrese de que la distribución tenga al menos tres Ceph Manager en cada distribución.

service_type: mgr
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3

Sugerencia

Si los MON o MGR no se encuentran en la misma subred, deberá añadir las direcciones de subred al final. Por ejemplo:

service_type: mon
placement:
  hosts:
  - ses-min1:10.1.2.0/24
  - ses-min2:10.1.5.0/24
  - ses-min3:10.1.10.0/24

Importante: cuando el dispositivo de almacenamiento está disponible

Un dispositivo de almacenamiento se considera que está disponible si se cumplen todas las condiciones siguientes:

• El dispositivo no tiene particiones.

• El dispositivo no tiene ningún estado de LVM.

• El dispositivo no está montado.

• El dispositivo no contiene un sistema de archivos.

• El dispositivo no contiene un OSD de BlueStore.

• El dispositivo tiene más de 5 GB.

Si no se cumplen las condiciones anteriores, Ceph se niega a aprovisionar dichos OSD.

Hay dos formas de distribuir los OSD:

CephFS requiere uno o varios servicios de servidor de metadatos (MDS). Para crear un CephFS, primero cree servidores MDS aplicando la siguiente especificación:

Nota

Asegúrese de tener al menos dos repositorios creados, uno para los datos de CephFS y otro para los metadatos de CephFS, antes de aplicar la siguiente especificación.

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

Después de que los MDS sean funcionales, cree el CephFS:

ceph fs new CEPHFS_NAME metadata_pool data_pool

cephadm distribuye una pasarela Object Gateway como una colección de daemons que gestionan un dominio y una zona concretos.

Puede relacionar un servicio de Object Gateway con un dominio y una zona ya existentes (consulte el Book “Guía de administración y operaciones”, Chapter 21 “Ceph Object Gateway”, Section 21.13 “Pasarelas Object Gateway de varios sitios” para obtener más información), o puede especificar un REALM_NAME y ZONE_NAME que no existan y se crearán automáticamente después de aplicar la siguiente configuración:

service_type: rgw
service_id: REALM_NAME.ZONE_NAME
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
spec:
  rgw_realm: RGW_REALM
  rgw_zone: RGW_ZONE

8.3.4.1 Uso del acceso SSL seguro #

 

Para utilizar una conexión SSL segura con Object Gateway, necesita un par de archivos de clave y certificado SSL válidos (consulte el Book “Guía de administración y operaciones”, Chapter 21 “Ceph Object Gateway”, Section 21.7 “Habilitación de HTTPS/SSL para pasarelas Object Gateway” para obtener más información). Debe habilitar SSL, especificar un número de puerto para las conexiones SSL y especificar los archivos de certificado SSL y de clave.

Para habilitar SSL y especificar el número de puerto, incluya lo siguiente en la especificación:

spec:
  ssl: true
  rgw_frontend_port: 443

Para especificar el certificado SSL y la clave, puede pegar su contenido directamente en el archivo de especificación YAML. El signo de barra vertical (|) al final de la línea indica al analizador que debe esperar una cadena de varias líneas como valor. Por ejemplo:

spec:
  ssl: true
  rgw_frontend_port: 443
  rgw_frontend_ssl_certificate: |
   -----BEGIN CERTIFICATE-----
   MIIFmjCCA4KgAwIBAgIJAIZ2n35bmwXTMA0GCSqGSIb3DQEBCwUAMGIxCzAJBgNV
   BAYTAkFVMQwwCgYDVQQIDANOU1cxHTAbBgNVBAoMFEV4YW1wbGUgUkdXIFNTTCBp
   [...]
   -----END CERTIFICATE-----
   rgw_frontend_ssl_key: |
   -----BEGIN PRIVATE KEY-----
   MIIJRAIBADANBgkqhkiG9w0BAQEFAASCCS4wggkqAgEAAoICAQDLtFwg6LLl2j4Z
   BDV+iL4AO7VZ9KbmWIt37Ml2W6y2YeKX3Qwf+3eBz7TVHR1dm6iPpCpqpQjXUsT9
   [...]
   -----END PRIVATE KEY-----

Sugerencia

En lugar de pegar el contenido del certificado SSL y los archivos de clave, puede omitir las palabras clave rgw_frontend_ssl_certificate: y rgw_frontend_ssl_key: y cargarlos en la base de datos de configuración

cephuser@adm > ceph config-key set rgw/cert/REALM_NAME/ZONE_NAME.crt \
 -i SSL_CERT_FILE
cephuser@adm > ceph config-key set rgw/cert/REALM_NAME/ZONE_NAME.key \
 -i SSL_KEY_FILE

8.3.4.1.1 Configuración de Object Gateway para que escuche en los puertos 443 y 80 #

 

Si desea configurar Object Gateway para que escuche en los puertos 443 (HTTPS) y 80 (HTTP), siga estos pasos:

Nota

Los comandos del procedimiento utilizan el dominio y la zona default.

1. Distribuya Object Gateway proporcionando un archivo de especificación. Consulte la Sección 8.3.4, “Distribución de pasarelas Object Gateways” para obtener más información sobre la especificación de Object Gateway. Utilice el comando siguiente:

   cephuser@adm > ceph orch apply -i SPEC_FILE

2. Si no se proporcionan certificados SSL en el archivo de especificación, añádalos mediante el siguiente comando:

   cephuser@adm > ceph config-key set rgw/cert/default/default.crt -i certificate.pem
   cephuser@adm > ceph config-key set rgw/cert/default/default.key -i key.pem

3. Cambie el valor por defecto de la opción rgw_frontends:

   cephuser@adm > ceph config set client.rgw.default.default rgw_frontends \
    "beast port=80 ssl_port=443"

4. Elimine la configuración específica creada por cephadm. Identifique para qué destino se ha configurado la opción rgw_frontends ejecutando el comando:

   cephuser@adm > ceph config dump | grep rgw

   Por ejemplo, el destino es client.rgw.default.default.node4.yiewdu. Elimine el valor rgw_frontends específico actual:

   cephuser@adm > ceph config rm client.rgw.default.default.node4.yiewdu rgw_frontends

   

   Sugerencia

   En lugar de eliminar un valor para rgw_frontends, puede especificarlo. Por ejemplo:

   cephuser@adm > ceph config set client.rgw.default.default.node4.yiewdu \
    rgw_frontends "beast port=80 ssl_port=443"

5. Reinicie las instancias de Object Gateway:

   cephuser@adm > ceph orch restart rgw.default.default

service_type: rgw
service_id: REALM_NAME.ZONE_NAME.SUBCLUSTER
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
spec:
  rgw_realm: RGW_REALM
  rgw_zone: RGW_ZONE
  subcluster: SUBCLUSTER

cephadm distribuye una instancia de iSCSI Gateway, que es un protocolo de red de área de almacenamiento (SAN) que permite a los clientes (denominados iniciadores) enviar comandos SCSI a dispositivos de almacenamiento SCSI (destinos) en servidores remotos.

Aplique la siguiente configuración para la distribución. Asegúrese de que trusted_ip_list contiene las direcciones IP de todos los nodos de iSCSI Gateway y de Ceph Manager (consulte el resultado de ejemplo a continuación).

Nota

Asegúrese de crear el repositorio antes de aplicar la siguiente especificación.

service_type: iscsi
service_id: EXAMPLE_ISCSI
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
spec:
  pool: EXAMPLE_POOL
  api_user: EXAMPLE_USER
  api_password: EXAMPLE_PASSWORD
  trusted_ip_list: "IP_ADDRESS_1,IP_ADDRESS_2"

Nota

Asegúrese de que las direcciones IP mostradas para trusted_ip_list no tienen un espacio después de la separación por comas.

spec:
  api_secure: true

spec:
  pool: EXAMPLE_POOL
  api_user: EXAMPLE_USER
  api_password: EXAMPLE_PASSWORD
  trusted_ip_list: "IP_ADDRESS_1,IP_ADDRESS_2"
  api_secure: true
  ssl_cert: |
    -----BEGIN CERTIFICATE-----
    MIIDtTCCAp2gAwIBAgIYMC4xNzc1NDQxNjEzMzc2MjMyXzxvQ7EcMA0GCSqGSIb3
    DQEBCwUAMG0xCzAJBgNVBAYTAlVTMQ0wCwYDVQQIDARVdGFoMRcwFQYDVQQHDA5T
    [...]
    -----END CERTIFICATE-----
  ssl_key: |
    -----BEGIN PRIVATE KEY-----
    MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC5jdYbjtNTAKW4
    /CwQr/7wOiLGzVxChn3mmCIF3DwbL/qvTFTX2d8bDf6LjGwLYloXHscRfxszX/4h
    [...]
    -----END PRIVATE KEY-----

Importante

NFS Ganesha admite la versión 4.1 y posteriores de NFS. No es compatible con NFS versión 3.

cephadm distribuye NFS Ganesha mediante un repositorio RADOS predefinido y un espacio de nombres opcional. Para distribuir NFS Ganesha, aplique la siguiente especificación:

Nota

Debe tener un repositorio RADOS predefinido; de lo contrario, la operación ceph orch apply fallará. Para obtener más información sobre cómo crear un repositorio, consulte el Book “Guía de administración y operaciones”, Chapter 18 “Gestión de repositorios de almacenamiento”, Section 18.1 “Creación de un repositorio”.

service_type: nfs
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min1
  - ses-min2
spec:
  pool: EXAMPLE_POOL
  namespace: EXAMPLE_NAMESPACE

El servicio rbd-mirror se encarga de sincronizar las imágenes del dispositivo de bloques RADOS entre dos clústeres de Ceph (para obtener más información, consulte el Book “Guía de administración y operaciones”, Chapter 20 “Dispositivo de bloques RADOS”, Section 20.4 “Duplicados de imagen RBD”). Para distribuir rbd-mirror, utilice la siguiente especificación:

service_type: rbd-mirror
service_id: EXAMPLE_RBD_MIRROR
placement:
  hosts:
  - ses-min3

La pila de supervisión está formada por Prometheus, los exportadores de Prometheus, Prometheus Alertmanager y Grafana. Ceph Dashboard utiliza estos componentes para almacenar y visualizar métricas detalladas sobre el uso y el rendimiento del clúster.

Sugerencia

Si la distribución requiere imágenes de contenedor personalizadas o servidas localmente de los servicios de la pila de supervisión, consulte el Book “Guía de administración y operaciones”, Chapter 16 “Supervisión y alertas”, Section 16.1 “Configuración de imágenes personalizadas o locales”.

Para distribuir la pila de supervisión, siga estos pasos:

Importante

Prometheus, Grafana y Ceph Dashboard se configuran automáticamente para comunicarse entre sí, lo que da como resultado una integración totalmente funcional de Grafana en Ceph Dashboard cuando se distribuyen como se describe anteriormente.

La única excepción a esta regla es la supervisión con imágenes RBD. Consulte el Book “Guía de administración y operaciones”, Chapter 16 “Supervisión y alertas”, Section 16.5.4 “Habilitación de la supervisión de imágenes RBD” para obtener más información.

iSCSI es una implementación del conjunto de comandos Small Computer System Interface (SCSI, interfaz de sistema informático pequeño) que usa el protocolo de Internet (IP) especificado en la RFC 3720. iSCSI se implementa como un servicio en el que un cliente (iniciador) se comunica con un servidor (destino) a través de una sesión en el puerto TCP 3260. La dirección IP y el puerto de un destino iSCSI se denominan portal iSCSI, y un destino puede quedar expuesto mediante uno o varios portales. La combinación de un destino y uno o más portales se denomina grupo de portal de destino (TPG).

El protocolo de capa de enlace de datos subyacente para iSCSI suele ser Ethernet. Más concretamente, las infraestructuras iSCSI modernas utilizan 10 GigE Ethernet o redes más rápidas para un rendimiento óptimo. Se recomienda encarecidamente usar conectividad 10 Gigabit Ethernet entre iSCSI Gateway y el clúster de procesador final de Ceph.

ceph-iscsi combina las ventajas de los dispositivos de bloques RADOS con la versatilidad extendida de iSCSI. Si se emplea ceph-iscsi en un host de destino iSCSI (conocido como iSCSI Gateway), cualquier aplicación que necesite hacer uso del almacenamiento de bloques puede beneficiarse de Ceph, incluso si no utiliza ningún protocolo de cliente de Ceph. En su lugar, los usuarios pueden utilizar iSCSI o cualquier otro protocolo de interfaz de usuario de destino para conectarse a un destino LIO, que traduce todas las comunicaciones de E/S de destino en operaciones de almacenamiento RBD.

Figura 9.1: Clúster de Ceph con una sola instancia de iSCSI Gateway #

 

Por naturaleza, ceph-iscsi es de alta disponibilidad y admite operaciones de múltiples rutas. Por lo tanto, los hosts de iniciador descendentes pueden utilizar varias instancias de iSCSI Gateway para obtener tanto alta disponibilidad como capacidad de ampliación. Cuando se comunican con una configuración iSCSI con más de un pasarela, los iniciadores pueden equilibrar la carga de las peticiones iSCSI entre varias pasarelas. En caso de fallo de una pasarela, por ejemplo si no se pueda acceder temporalmente o si está inhabilitada por mantenimiento, las comunicaciones de E/S continuarán de forma transparente a través de otra pasarela.

Figura 9.2: Clúster de Ceph con varias instancias de iSCSI Gateway #

 

Una configuración mínima de SUSE Enterprise Storage 7.1 con ceph-iscsi consta de los siguientes componentes:

Una configuración de producción recomendada de SUSE Enterprise Storage 7.1 con ceph-iscsi consta de:

En esta sección se describen los pasos necesarios para instalar y configurar una instancia de iSCSI Gateway en SUSE Enterprise Storage.

cephuser@adm > rbd --pool iscsi-images create --size=102400 testvol

9.1.4.3 Exportación de imágenes RBD a través de iSCSI #

 

Para exportar imágenes RBD mediante iSCSI, puede utilizar la interfaz Web de Ceph Dashboard o la utilidad de línea de comandos de pasarela ceph-iscsi. En esta sección nos centraremos solo en esta utilidad y se mostrará cómo crear un destino iSCSI que exporte una imagen RBD mediante la línea de comandos.

Nota

Las imágenes RBD con las siguientes propiedades no se pueden exportar mediante iSCSI:

• Imágenes con el registro transaccional habilitado.

• Imágenes con una unidad de franja de menos de 4096 bytes

Como usuario root, introduzca el contenedor de iSCSI Gateway:

# cephadm enter --name CONTAINER_NAME

Como usuario root, inicie la interfaz de línea de comandos de iSCSI Gateway:

# gwcli

Diríjase a iscsi-targets y cree un destino con el nombre iqn.2003-01.org.linux-iscsi.iscsi.ARQUITECTURA-SISTEMA:testvol:

gwcli >  /> cd /iscsi-targets
gwcli >  /iscsi-targets> create iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol

Cree las pasarelas iSCSI especificando el nombre y la dirección IP de la pasarela:

gwcli >  /iscsi-targets> cd iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/gateways
gwcli >  /iscsi-target...tvol/gateways> create iscsi1 192.168.124.104
gwcli >  /iscsi-target...tvol/gateways> create iscsi2 192.168.124.105

Sugerencia

Utilice el comando help para mostrar la lista de comandos disponibles en el nodo de configuración actual.

Añada la imagen RBD con el nombre testvol en el repositorio iscsi-images:

gwcli >  /iscsi-target...tvol/gateways> cd /disks
gwcli >  /disks> attach iscsi-images/testvol

Asigne la imagen RBD al destino:

gwcli >  /disks> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/disks
gwcli >  /iscsi-target...testvol/disks> add iscsi-images/testvol

Nota

Puede utilizar herramientas de nivel inferior, como targetcli, para consultar la configuración local, pero no para modificarla.

Sugerencia

Puede utilizar el comando ls para revisar la configuración. Algunos nodos de configuración también admiten el comando info, que se puede utilizar para mostrar información más detallada.

Tenga en cuenta que, por defecto, la autenticación de ACL está habilitada para que no se pueda acceder aún a este destino. Consulte la Sección 9.1.4.4, “Autenticación y control de acceso” para obtener más información sobre la autenticación y el control de acceso.

9.1.4.4 Autenticación y control de acceso #

 

La autenticación iSCSI es flexible y cubre muchas posibilidades de autenticación.

9.1.4.4.1 Inhabilitación de la autenticación de ACL #

 

Sin autenticación significa que cualquier iniciador podrá acceder a cualquier LUN en el destino correspondiente. Para habilitar Sin autenticación, inhabilite la autenticación de ACL:

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hosts
gwcli >  /iscsi-target...testvol/hosts> auth disable_acl

9.1.4.4.2 Uso de la autenticación de ACL #

 

Si se utiliza la autenticación de ACL basada en el nombre del iniciador, solo se permite que se conecten los iniciadores definidos. Para definir un iniciador, haga lo siguiente:

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hosts
gwcli >  /iscsi-target...testvol/hosts> create iqn.1996-04.de.suse:01:e6ca28cc9f20

Los iniciadores definidos podrán conectarse, pero solo tendrán acceso a las imágenes RBD que se hayan añadido explícitamente al iniciador:

gwcli >  /iscsi-target...:e6ca28cc9f20> disk add rbd/testvol

9.1.4.4.3 Habilitación de la autenticación CHAP #

 

Además de ACL, puede habilitar la autenticación CHAP especificando un nombre de usuario y una contraseña para cada iniciador:

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hosts/iqn.1996-04.de.suse:01:e6ca28cc9f20
gwcli >  /iscsi-target...:e6ca28cc9f20> auth username=common12 password=pass12345678

Nota

Los nombres de usuario deben tener entre 8 y 64 caracteres y pueden incluir letras, números y estos caracteres: ., @, -, _ o :.

Las contraseñas deben tener entre 12 y 16 caracteres y pueden incluir caracteres alfanuméricos, @, -, _ o /.

Opcionalmente, también puede habilitar la autenticación CHAP mutua especificando los parámetros mutual_username y mutual_password en el comando auth.

9.1.4.4.4 Configuración de la autenticación de descubrimiento y mutua #

 

la autenticación de descubrimiento es independiente de los métodos de autenticación anteriores. Requiere credenciales para la navegación, es opcional y se puede configurar mediante:

gwcli >  /> cd /iscsi-targets
gwcli >  /iscsi-targets> discovery_auth username=du123456 password=dp1234567890

Nota

Los nombres de usuario deben tener una longitud de entre 8 y 64 caracteres y solo pueden incluir letras o estos caracteres: ., @, -, _ o :.

Las contraseñas deben tener entre 12 y 16 caracteres y solo pueden incluir letras, @, -, _ o /.

Opcionalmente, también puede especificar los parámetros mutual_username y mutual_password en el comando discovery_auth.

La autenticación de descubrimiento se puede inhabilitar mediante el siguiente comando:

gwcli >  /iscsi-targets> discovery_auth nochap

9.1.4.5 Configuración avanzada #

 

ceph-iscsi puede configurarse con parámetros avanzados que posteriormente se pasan al destino de E/S LIO. Los parámetros se dividen en parámetros de destino y de disco.

Aviso

A no ser que se indique lo contrario, no se recomienda cambiar los valores por defecto de estos parámetros.

9.1.4.5.1 Visualización de los ajustes de destino #

 

Puede ver el valor de estos ajustes mediante el comando info:

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol
gwcli >  /iscsi-target...i.SYSTEM-ARCH:testvol> info

Y para cambiar un valor se usa el comando reconfigure:

gwcli >  /iscsi-target...i.SYSTEM-ARCH:testvol> reconfigure login_timeout 20

Los ajustes de destino disponibles son:

default_cmdsn_depth

Profundidad de CmdSN (número de secuencia de comando) por defecto. Limita la cantidad de peticiones que un iniciador iSCSI puede tener pendientes en cualquier momento.

default_erl

Nivel de recuperación de error por defecto.

login_timeout

Valor de tiempo límite de entrada a la sesión en segundos.

netif_timeout

Tiempo límite de fallo de NIC en segundos.

prod_mode_write_protect

Si se establece en 1, se impide que se pueda escribir en los LUN.

9.1.4.5.2 Visualización de los ajustes de disco #

 

Puede ver el valor de estos ajustes mediante el comando info:

gwcli >  /> cd /disks/rbd/testvol
gwcli >  /disks/rbd/testvol> info

Y para cambiar un valor se usa el comando reconfigure:

gwcli >  /disks/rbd/testvol> reconfigure rbd/testvol emulate_pr 0

Los ajustes de disco disponibles son:

block_size

Tamaño de bloque del dispositivo subyacente.

emulate_3pc

Si se establece en 1, se habilita la opción Third Party Copy (Copia por parte de terceros).

emulate_caw

Si se establece en 1, se habilita la opción Compare and Write (Comparar y escribir).

emulate_dpo

Si se establece en 1, se activa la opción Disable Page Out (Inhabilitar página saliente).

emulate_fua_read

Si se establece en 1, se habilita la lectura de Force Unit Access (Forzar acceso a la unidad).

emulate_fua_write

Si se establece en 1, se habilita la escritura de Force Unit Access (Forzar acceso a la unidad).

emulate_model_alias

Si se establece en 1, se utiliza el nombre del dispositivo de procesador final para el alias del modelo.

emulate_pr

Si se define en 0, se inhabilita la compatibilidad con las reservas SCSI, incluidas las reservas de grupo persistente. Mientras está inhabilitada, la pasarela iSCSI Gateway de SES puede ignorar el estado de la reserva, lo que mejora la latencia de las peticiones.

Sugerencia

Se recomienda definir en backstore_emulate_pr el valor 0 si los iniciadores iSCSI no requieren compatibilidad con la reserva SCSI.

emulate_rest_reord

Si se establece en 0, la opción Queue Algorithm Modifier (Modificador de algoritmo de cola) tiene restringido el cambio de orden.

emulate_tas

Si se establece en 1, se habilita la opción Task Aborted Status (Estado cancelado de tarea).

emulate_tpu

Si se establece en 1, se habilita la opción Thin Provisioning Unmap (Anular asignación de provisión ligera).

emulate_tpws

Si se establece en 1, se habilita la opción Thin Provisioning Write Same (Misma escritura en provisión ligera).

emulate_ua_intlck_ctrl

Si se establece en 1, se habilita la opción Unit Attention Interlock (Interbloqueo de atención en la unidad).

emulate_write_cache

Si se establece en 1, se activa la opción Write Cache Enable (Habilitar caché de escritura).

enforce_pr_isids

Si se establece en 1, se fuerzan los ISID de reserva persistente.

is_nonrot

Si se establece en 1, el almacén de respaldo es un dispositivo sin rotación.

max_unmap_block_desc_count

Número máximo de descriptores de bloque para UNMAP.

max_unmap_lba_count:

Número máximo de LBA para UNMAP.

max_write_same_len

Longitud máxima de WRITE_SAME.

optimal_sectors

Tamaño de la petición óptima en sectores.

pi_prot_type

Tipo de garantía de DIF.

queue_depth

Profundidad de la cola.

unmap_granularity

Granularidad de UNMAP.

unmap_granularity_alignment

Alineación de la granularidad de UNMAP.

force_pr_aptpl

Si está habilitado, LIO siempre escribirá el estado reserva persistente en el almacenamiento persistente, independientemente de si el cliente lo ha pedido a través de aptpl=1. Esto no tiene ningún efecto en el back-end RBD del kernel para LIO, ya que siempre persiste el estado PR. En circunstancias ideales, la opción target_core_rbd debería aplicar el valor "1" y producir un error si alguien intenta inhabilitarlo a través de la configuración.

unmap_zeroes_data

Afecta a si LIO anunciará LBPRZ a los iniciadores SCSI, lo que indica que los ceros se leerán desde una región después de UNMAP o WRITE SAME con un bit de desasignación.

ceph-iscsi admite los almacenes rbd (basado en el kernel) y user:rbd (tcmu-runner), lo que hace que toda la gestión sea transparente e independiente del almacén.

Aviso: tecnología en fase preliminar

Las distribuciones de iSCSI Gateway basadas en tcmu-runner son actualmente una tecnología en fase preliminar.

A diferencia de las distribuciones de iSCSI Gateway basadas en kernel, las basadas en tcmu-runner no ofrecen compatibilidad con E/S de múltiples rutas ni con las reservas persistentes SCSI.

Para exportar una imagen de dispositivo de bloque RADOS mediante tcmu-runner, todo lo que necesita hacer es especificar el almacén user:rbd al conectar el disco:

gwcli >  /disks> attach rbd/testvol backstore=user:rbd

Nota

Si utiliza tcmu-runner, la imagen RBD exportada debe tener habilitada la función exclusive-lock.

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

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.1. Para obtener más información sobre cómo realizar copias de seguridad de todos los datos, consulte el https://documentation.suse.com/ses/6/single-html/ses-admin/#cha-deployment-backup.

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.

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:

# zypper refresh && zypper patch

Sugerencia

Consulte https://documentation.suse.com/ses/6/html/ses-all/storage-salt-cluster.html#deepsea-rolling-updates para obtener información detallada sobre la actualización de los nodos del clúster.

Después de aplicar las actualizaciones, reinicie el master de Salt, sincronice los nuevos módulos de Salt y compruebe el estado del clúster:

root@master # systemctl restart salt-master.service
root@master # salt '*' saltutil.sync_all
cephuser@adm > ceph -s

 cephuser@adm > ceph status
 cluster:
   id:     3fe8b35a-689f-4970-819d-0e6b11f6707c
   health: HEALTH_WARN
   mons are allowing insecure global_id reclaim
 [...]

cephuser@adm > ceph config set mon auth_allow_insecure_global_id_reclaim false

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

En SUSE Enterprise Storage 7.1, las pasarelas Object Gateway siempre se configuran con un dominio, lo que permite utilizar varios sitios en el futuro (consulte el Book “Guía de administración y operaciones”, Chapter 21 “Ceph Object Gateway”, Section 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, de grupo de zonas y de zona.

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

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

Importante

NFS Ganesha admite la versión 4.1 y posteriores de NFS. No es compatible con NFS versión 3.

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

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 intentar cualquier migración, se recomienda encarecidamente realizar una copia de los objetos de exportación y configuración del daemon ubicados en el repositorio RADOS. Para localizar el repositorio RADOS configurado, ejecute el siguiente comando:

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 cualquiera contenedor gestionado por cephadm.

Las exportaciones existentes se pueden migrar de dos formas distintas:

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

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.

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.

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

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. Para obtener instrucciones sobre cómo realizar copias de seguridad de todos los datos, consulte el Book “Guía de administración y operaciones”, Chapter 15 “Copia de seguridad y recuperación”.

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