Se aplica a SUSE Enterprise Storage 7

5 Distribución con cephadm #

SUSE Enterprise Storage 7 utiliza la herramienta ceph-salt basada en Salt para preparar el sistema operativo en cada nodo del clúster participante para la distribución a través de cephadm. cephadm distribuye y gestiona un clúster de Ceph conectándose a hosts desde el daemon de Ceph Manager a través de SSH. También gestiona el ciclo de vida completo de un clúster de Ceph. Comienza arrancando un clúster minúsculo en un único nodo (un servicio MON y MGR) y, a continuación, utiliza la interfaz de orquestación para expandir el clúster a fin de que incluya todos los hosts y para aprovisionar todos los servicios de Ceph. Puede realizar esta operación a través de la interfaz de línea de comandos de Ceph o parcialmente a través de la interfaz gráfica de usuario, Ceph Dashboard.

Importante

Tenga en cuenta que la documentación de la comunidad de Ceph utiliza el comando cephadm bootstrap durante la distribución inicial. ceph-salt llama al comando cephadm bootstrap y no se debe ejecutar directamente. No se admitirá ninguna distribución manual del clúster de Ceph mediante bootstrap cephadm.

Para distribuir un clúster de Ceph mediante cephadm, debe realizar las siguientes tareas:

Instale y realice la configuración básica del sistema operativo subyacente (SUSE Linux Enterprise Server 15 SP2) en todos los nodos del clúster.
Distribuya la infraestructura de Salt en todos los nodos del clúster para realizar los preparativos de la distribución inicial mediante ceph-salt.
Configure las propiedades básicas del clúster mediante ceph-salt e impleméntelo.
Añada nuevos nodos y funciones al clúster y distribuya servicios en ellos mediante cephadm.

5.1 Instalación y configuración de SUSE Linux Enterprise Server #

Instale y registre SUSE Linux Enterprise Server 15 SP2 en cada nodo del clúster. Durante la instalación de SUSE Enterprise Storage, se requiere acceso a los repositorios de actualización, por lo que el registro es obligatorio. Incluya al menos los siguientes módulos:
- Módulo de sistema base
- Módulo de aplicaciones de servidor
Obtenga más información sobre cómo instalar SUSE Linux Enterprise Server en https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-install.html.
Instale la extensión de SUSE Enterprise Storage 7 en cada nodo del clúster.
Sugerencia: instalación de SUSE Enterprise Storage junto con SUSE Linux Enterprise Server
Puede instalar la extensión de SUSE Enterprise Storage 7 por separado después de instalar SUSE Linux Enterprise Server 15 SP2, o bien añadirla durante el procedimiento de instalación de SUSE Linux Enterprise Server 15 SP2.
Encontrará más información sobre cómo instalar extensiones en https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-register-sle.html.
Configure los ajustes de red, incluida la resolución de nombre DNS adecuada en cada nodo. Para obtener más información acerca de cómo configurar una red, consulte https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-network.html#sec-network-yast. Para obtener más información sobre cómo configurar un servidor DNS, consulte https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-dns.html.

5.2 Distribución de Salt #

SUSE Enterprise Storage utiliza Salt y ceph-salt para la preparación inicial del clúster. Salt le ayuda a configurar y ejecutar comandos en varios nodos de clúster de forma simultánea desde un host dedicado llamado máster de Salt. Antes de distribuir Salt, tenga en cuenta los siguientes puntos importantes:

Los minions de Salt son los nodos que se controlan mediante un nodo dedicado denominado master de Salt.
Si el host del master de Salt debe formar parte del clúster de Ceph, debe ejecutar su propio minion de Salt, pero esto no es un requisito.
Sugerencia: uso compartido de varias funciones por servidor
Conseguirá el mejor rendimiento del clúster de Ceph si cada función se distribuye en un nodo independiente. Pero las distribuciones reales requieren en ocasiones que se comparta un nodo para varias funciones. Para evitar problemas de rendimiento y en el procedimiento de actualización, no distribuya las funciones de Ceph OSD, el servidor de metadatos ni Ceph Monitor al nodo de administración.
Los minions de Salt deben resolver correctamente el nombre de host del master de Salt en la red. Por defecto, buscan el nombre de host salt, pero puede especificar cualquier otro nombre de host al que se pueda acceder por la red en el archivo /etc/salt/minion.

Instale salt-master en el nodo master de Salt:
```
root@master # zypper in salt-master
```
Compruebe que el servicio salt-master esté habilitado y se haya iniciado, y si no lo estuviera, habilítelo e inícielo:
```
root@master # systemctl enable salt-master.service
root@master # systemctl start salt-master.service
```
Si va a utilizar un cortafuegos, asegúrese de que el nodo master de Salt tiene los puertos 4505 y 4506 abiertos para todos los nodos minion de Salt. Si los puertos están cerrados, puede abrirlos con el comando yast2 firewall permitiendo el servicio salt-master para la zona oportuna. Por ejemplo, public.
Instale el paquete salt-minion en todos los nodos minion.
```
root@minion > zypper in salt-minion
```
Edite /etc/salt/minion y elimine el comentario de la siguiente línea:
```
#log_level_logfile: warning
```
Cambie el nivel de registro de warning a info.
Nota: log_level_logfile y log_level
Mientras que log_level controla qué mensajes de registro se mostrarán en la pantalla, log_level_logfile controla qué mensajes de registro se escribirán en /var/log/salt/minion.
Nota
Asegúrese de cambiar el nivel de registro en todos los nodos del clúster (minions).
Asegúrese de que todos los demás nodos pueden resolver el nombre de dominio completo de cada nodo en una dirección IP en la red pública del clúster.
Configure todos los minions para que se conecten con el master. Si el host denominado salt no puede acceder al master de Salt, edite el archivo /etc/salt/minion o cree un archivo nuevo /etc/salt/minion.d/master.conf con el siguiente contenido:
```
master: host_name_of_salt_master
```
Si ha realizado cambios en los archivos de configuración mencionados anteriormente, reinicie el servicio Salt en todos los minions de Salt:
```
root@minion > systemctl restart salt-minion.service
```
Compruebe que el servicio salt-minion está habilitado e iniciado en todos los nodos. Habilítelo e inícielo si fuera necesario:
```
root # systemctl enable salt-minion.service
root # systemctl start salt-minion.service
```
Verifique la huella digital de cada minion de Salt y acepte todas las claves salt del master de Salt si las huellas coinciden.
Nota
Si la huella digital del minion de Salt vuelve vacía, asegúrese de que el minion de Salt tenga una configuración de master de Salt y que pueda comunicarse con el master de Salt.
Para ver la huella digital de cada minion:
```
root@minion > salt-call --local key.finger
local:
3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...
```
Después de recopilar las huellas digitales de todos los minions de Salt, muestre las huellas de todas las claves de minion no aceptadas del master de Salt:
```
root@master # salt-key -F
[...]
Unaccepted Keys:
minion1:
3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...
```
Si las huellas digitales de los minions coinciden, acéptelas:
```
root@master # salt-key --accept-all
```
Verifique que las claves se han aceptado:
```
root@master # salt-key --list-all
```
Compruebe si todos los minions de Salt responden:
```
root@master # salt-run manage.status
```

5.3 Distribución del clúster de Ceph #

Esta sección le guía por el proceso de distribuir un clúster de Ceph básico. Lea atentamente las subsecciones y ejecute los comandos incluidos en el orden indicado.

5.3.1 Instalación de `ceph-salt` #

ceph-salt proporciona herramientas para distribuir clústeres de Ceph gestionados por cephadm. ceph-salt utiliza la infraestructura de Salt para realizar la gestión del sistema operativo (por ejemplo, las actualizaciones de software o la sincronización horaria) y para definir funciones para los minions de Salt.

En el master de Salt, instale el paquete ceph-salt :

root@master # zypper install ceph-salt

El comando anterior, ceph-salt-formula se ha instalado como una dependencia que modifica la configuración del master de Salt insertando archivos adicionales en el directorio /etc/salt/master.d. Para aplicar los cambios, reinicie salt-master.service y sincronice los módulos de Salt:

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

5.3.2 Configuración de las propiedades del clúster #

Utilice el comando ceph-salt config para configurar las propiedades básicas del clúster.

Importante

El archivo /etc/ceph/ceph.conf se gestiona mediante cephadm y los usuarios no deben editarlo. Los parámetros de configuración de Ceph deben definirse mediante el nuevo comando ceph config. Consulte el Sección 28.2, “Base de datos de configuración” para obtener más información.

5.3.2.1 Uso de la shell `ceph-salt` #

Si ejecuta ceph-salt config sin ninguna vía o subcomando, deberá introducir una shell ceph-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 ls de ceph-salt, 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:

Ejecute el comando desde la posición actual e introduzca la vía absoluta a la propiedad como primer argumento:

/> /cephadm_bootstrap/dashboard ls
o- dashboard ....................................................... [...]
  o- force_password_update ..................................... [enabled]
  o- password .................................................... [admin]
  o- ssl_certificate ........................................... [not set]
  o- ssl_certificate_key ....................................... [not set]
  o- username .................................................... [admin]
/> /cephadm_bootstrap/dashboard/username set ceph-admin
Value set.

Cambie a la vía cuya propiedad necesite configurar y ejecute el comando:

/> cd /cephadm_bootstrap/dashboard/
/ceph_cluster/minions> ls
o- dashboard ....................................................... [...]
  o- force_password_update ..................................... [enabled]
  o- password .................................................... [admin]
  o- ssl_certificate ........................................... [not set]
  o- ssl_certificate_key ....................................... [not set]
  o- username ................................................[ceph-admin]

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

5.3.2.2 Adición de minions de Salt #

Incluya todos los minions de Salt que se han distribuido y aceptado en la Sección 5.2, “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]

5.3.2.3 Especificación de minions de Salt gestionados por cephadm #

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 '*'

5.3.2.4 Especificación del nodo de administración #

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.

5.3.2.5 Especificación del primer nodo de MON/MGR #

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

5.3.2.6 Especificación de perfiles ajustados #

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.

5.3.2.7 Generación de un par de claves SSH #

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]

5.3.2.8 Configuración del servidor de hora #

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:

Si todos los nodos del clúster están ya configurados para sincronizar su hora mediante un servicio NTP de su elección, inhabilite la gestión del servidor horario:
```
root@master # ceph-salt config /time_server disable
```
Si su sitio ya tiene una única fuente horaria, especifique el nombre de host de esta:
```
 root@master # ceph-salt config /time_server/servers add time-server.example.com
```
Como alternativa, ceph-salt tiene la capacidad de configurar uno de los minions de Salt para que sirva como servidor horario para el resto del clúster. A veces se hace referencia a esto como un "servidor horario interno". En este escenario, ceph-salt configurará el servidor horario interno (que debe ser uno de los minions de Salt) para sincronizar su hora con un servidor horario externo, como pool.ntp.org, y configurará todos los demás minions para obtener su hora del servidor horario interno. Esto se puede lograr de la siguiente manera:
```
root@master # ceph-salt config /time_server/servers add ses-master.example.com
root@master # ceph-salt config /time_server/external_servers add pool.ntp.org
```
La opción /time_server/subnet especifica la subred desde la que los clientes NTP pueden acceder al servidor NTP. Se define automáticamente al especificar /time_server/servers. Si necesita cambiarlo o especificarlo manualmente, ejecute:
```
root@master # ceph-salt config /time_server/subnet set 10.20.6.0/24
```

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-SP2/html/SLES-all/cha-ntp.html#sec-ntp-yast.

5.3.2.9 Configuración de las credenciales de entrada de Ceph Dashboard #

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

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

cephadm necesita conocer una vía URI válida a las imágenes de contenedor que se utilizará durante el paso de distribución. Verifique si la vía por defecto está definida:

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

Si no hay ninguna vía por defecto definida. o si la distribución requiere una vía específica, añádala de la siguiente manera:

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

Nota

Para la pila de supervisión, se necesitan más imágenes de contenedor. En el caso de una distribución para entornos aislados, así como para distribuir desde un registro local, es posible que desee obtener esas imágenes en este momento para preparar el registro local en consecuencia.

Tenga en cuenta que ceph-salt no utilizará esas imágenes de contenedor para la distribución. Es una preparación para un paso posterior en el que se utilizará cephadm para distribuir o migrar componentes de supervisión.

Para obtener más información acerca de las imágenes utilizadas por la pila de supervisión y cómo personalizarlas, visite Sección 16.1, “Configuración de imágenes personalizadas o locales”.

5.3.2.11 Configuración del registro del contenedor #

Opcionalmente, puede definir un registro de contenedor local. Servirá como duplicado del registro registry.suse.com. Recuerde que debe volver a sincronizar el registro local siempre que haya nuevos contenedores actualizados disponibles en registry.suse.com.

La creación de un registro local es útil en las siguientes situaciones:

Si tiene muchos nodos de clúster y desea ahorrar tiempo de descarga y ancho de banda creando un duplicado local de imágenes de contenedor.
Si el clúster no tiene acceso al registro en línea (una distribución en un entorno aislado) y necesita un duplicado local desde el que extraer las imágenes del contenedor.
Si los problemas de configuración o de red impiden que el clúster acceda a los registros remotos a través de un enlace seguro. En este caso, necesitará un registro local sin cifrar.

Importante

Para distribuir soluciones temporales de programa (PTF) en un sistema compatible, es necesario distribuir un registro de contenedor local.

Para configurar una URL de registro local junto con las credenciales de acceso, haga lo siguiente:

Configure la URL del registro local:

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

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

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

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

Ejecute ceph-salt apply para actualizar el pilar de Salt en todos los minions.

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.

Los métodos de entrega y desarrollo de aplicaciones nativas en la nube requieren un registro y una instancia de CI/CD (integración/entrega continua) para el desarrollo y la producción de imágenes de contenedor. Puede utilizar un registro privado en esta instancia.

5.3.2.12 Habilitación del cifrado en curso de datos (msgr2) #

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:

crc mode: Una autenticación inicial sólida cuando se establece la conexión y una comprobación de integridad CRC32C.
secure mode: Una autenticación inicial sólida cuando se establece la conexión y un cifrado completo de todo el tráfico posterior a la autenticación, incluida una comprobación de la integridad criptográfica.

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

ms_cluster_mode: El modo de conexión (o modos permitidos) utilizado para la comunicación dentro del clúster entre los daemons de Ceph. Si se muestran varios modos, se prefieren los que aparecen en primer lugar.
ms_service_mode: Una lista de los modos permitidos que pueden utilizar los clientes al conectarse al clúster.
ms_client_mode: Una lista de modos de conexión, en orden de preferencia, que los clientes pueden utilizar (o permitir) al comunicarse con un clúster de Ceph.

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.

ms_mon_cluster_mode: El modo de conexión (o modos permitidos) que se utilizará entre monitores.
ms_mon_service_mode: Una lista de modos permitidos para que los clientes u otros daemons de Ceph los utilicen al conectarse a los monitores.
ms_mon_client_mode: Una lista de modos de conexión, en orden de preferencia, para que los clientes o los daemons que no sean de monitor utilicen al conectarse a los 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 seguro, 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

5.3.2.13 Configuración de la red del clúster #

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

5.3.2.14 Verificación de la configuración del clúster #

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

5.3.2.15 Exportación de configuraciones de clúster #

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

5.3.3 Actualización de nodos y clúster mínimo de arranque #

Antes de distribuir el clúster, actualice todos los paquetes de software en todos los nodos:

root@master # ceph-salt update

Si un nodo informa de que es necesario reiniciar durante la actualización, los paquetes del sistema operativo importantes, como el kernel, se actualizaron a una versión más reciente y es necesario reiniciar el nodo para aplicar los cambios.

Para reiniciar todos los nodos que requieren reinicio, añada la opción --reboot

root@master # ceph-salt update --reboot

O bien, reinícielos en un paso independiente:

root@master # ceph-salt reboot

Importante

El master de Salt nunca se reinicia mediante los comandos ceph-salt update --reboot o ceph-salt reboot. Si es necesario reiniciar el master de Salt, deberá hacerlo manualmente.

Después de actualizar los nodos, arranque el clúster mínimo:

root@master # ceph-salt apply

Nota

Cuando se complete el proceso, el clúster tendrá un monitor Ceph Monitor y una instancia de Ceph Manager.

El comando anterior abrirá una interfaz de usuario interactiva que muestra el progreso actual de cada minion.

Figura 5.1: Distribución de un clúster mínimo #

Sugerencia: modo no interactivo

Si necesita aplicar la configuración desde un guion, también existe un modo de distribución no interactivo. Esto también resulta útil cuando se distribuye el clúster desde un equipo remoto, ya que la actualización constante de la información de progreso en la pantalla a través de la red puede resultar una distracción:

root@master # ceph-salt apply --non-interactive

5.3.4 Revisión de los pasos finales #

Después de que se haya completado el comando ceph-salt apply, debe tener un monitor de Ceph Monitor y una instancia de Ceph Manager. Debería poder ejecutar el comando ceph status correctamente en cualquiera de los minions a los que se les haya asignado la función de administrador como usuario root o como usuario cephadm mediante sudo.

Los siguientes pasos implican el uso de cephadm para distribuir Ceph Monitor, Ceph Manager, los OSD, la pila de supervisión y pasarelas adicionales.

Antes de continuar, revise la configuración de red del nuevo clúster. En este punto, el ajuste public_network se ha completado en función de lo que se haya introducido para /cephadm_bootstrap/mon_ip en la configuración de ceph-salt. Sin embargo, este ajuste solo se ha aplicado a Ceph Monitor. Puede revisar este ajuste con el comando siguiente:

root@master # ceph config get mon public_network

Esto es lo mínimo que Ceph requiere para funcionar, pero se recomienda convertir este ajuste public_network como global, lo que significa que se aplicará a todos los tipos de daemons de Ceph, y no solo a los MON:

root@master # ceph config set global public_network "$(ceph config get mon public_network)"

Nota

Este paso no es obligatorio. Sin embargo, si no utiliza este ajuste, los OSD de Ceph y otros daemons (excepto Ceph Monitor) escucharán en todas las direcciones.

Si desea que los OSD se comuniquen entre sí mediante una red completamente independiente, ejecute el comando siguiente:

root@master # ceph config set global cluster_network "cluster_network_in_cidr_notation"

La ejecución de este comando garantizará que los OSD creados en la distribución utilicen la red de clúster deseada desde el principio.

Si el clúster está configurado para tener nodos densos (más de 62 OSD por host), asegúrese de asignar suficientes puertos para los OSD de Ceph. El rango por defecto (6800-7300) no permite actualmente más de 62 OSD por host. Para un clúster con nodos densos, ajuste ms_bind_port_max con un valor adecuado. Cada OSD consumirá ocho puertos adicionales. Por ejemplo, si se configura un host para que ejecute 96 OSD, se necesitarán 768 puertos. ms_bind_port_max debe definirse al menos en 7568 ejecutando el comando siguiente:

root@master # ceph config set osd.* ms_bind_port_max 7568

Deberá ajustar la configuración del cortafuegos en consecuencia para que esto funcione. Consulte el Sección 13.7, “Firewall settings for Ceph” para obtener más información.

5.4 Distribución de servicios y pasarelas #

Después de distribuir el clúster de Ceph básico, distribuya los servicios principales a más nodos del clúster. Para que los clientes puedan acceder a los datos del clúster, distribuya también servicios adicionales.

Actualmente, se admite la distribución de servicios de Ceph en la línea de comandos mediante Ceph Orchestrator (subcomandos de ceph orch).

5.4.1 El comando `ceph orch` #

El comando ceph orch de Ceph Orchestrator, que es una interfaz para el módulo cephadm, se encarga de mostrar los componentes del clúster y de distribuir los servicios de Ceph en los nuevos nodos del clúster.

5.4.1.1 Visualización del estado del orquestador #

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

cephuser@adm > ceph orch status

5.4.1.2 Listado de dispositivos, servicios y daemons #

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

5.4.2 Especificación del servicio y la colocación #

La forma recomendada de especificar la distribución de los servicios de Ceph es crear un archivo con formato YAML con la especificación de los servicios que desea distribuir.

5.4.2.1 Creación de especificaciones de servicio #

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:

service_type: El tipo de servicio. Puede ser un servicio de Ceph (mon, mgr, mds, crash, osd o rbd-mirror), una pasarela (nfs o rgw) o parte de la pila de supervisión (alertmanager, grafana, node-exporter o prometheus).
service_id: El nombre del servicio. Las especificaciones de tipo mon, mgr, alertmanager, grafana, node-exporter y prometheus no requieren la propiedad service_id.
placement: Especifica qué nodos ejecutarán el servicio. Consulte la Sección 5.4.2.2, “Creación de especificaciones de colocación” para obtener más información.
spec: Especificación adicional relevante para el tipo de servicio.

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 5.4.3, “Distribución de servicios de Ceph”.

5.4.2.2 Creación de especificaciones de colocación #

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

5.4.2.3 Aplicación de la especificación del clúster #

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 5.4.1.1, “Visualización del estado del orquestador”.

5.4.2.4 Exportación de la especificación de un clúster en ejecución #

Aunque ha distribuido servicios al clúster de Ceph mediante los archivos de especificación como se describe en la Sección 5.4.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

5.4.3 Distribución de servicios de Ceph #

Cuando el clúster básico esté en ejecución, puede distribuir los servicios de Ceph a nodos adicionales.

5.4.3.1 Distribución de monitores Ceph Monitor y gestores Ceph Manager #

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

5.4.3.2 Distribución de los OSD de Ceph #

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:

Indique a Ceph que consuma todos los dispositivos de almacenamiento disponibles y no utilizados:
```
cephuser@adm > ceph orch apply osd --all-available-devices
```
Utilice DriveGroups (consulte el Sección 13.4.3, “Adición de OSD mediante la especificación DriveGroups”) para crear una especificación de OSD que describa los dispositivos que se distribuirán en función de sus propiedades, como el tipo de dispositivo (SSD o HDD), el nombre de modelo del dispositivo, el tamaño o los nodos en los que existen los dispositivos. A continuación, aplique la especificación ejecutando el comando siguiente:
```
cephuser@adm > ceph orch apply osd -i drive_groups.yml
```

5.4.3.3 Distribución de servidores de metadatos #

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

5.4.3.4 Distribución de pasarelas Object Gateways #

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 Sección 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

5.4.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 Sección 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 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

5.4.3.4.2 Distribución con un subclúster #

Los subclústeres ayudan a organizar los nodos de los clústeres para aislar las cargas de trabajo y facilitar el escalado elástico. Si va a distribuir con un subclúster, aplique la siguiente configuración:

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

5.4.3.5 Distribución de pasarelas iSCSI Gateway #

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.

5.4.3.5.1 Configuración SSL segura #

Para utilizar una conexión SSL segura entre Ceph Dashboard y la API de destino iSCSI, necesita un par de archivos de clave y certificado SSL válidos. Estos pueden ser emitidos por una autoridad certificadora o autofirmados (consulte el Sección 10.1.1, “Creación de certificados autofirmados”). Para habilitar SSL, incluya el ajuste api_secure: true en el archivo de especificación:

spec:
  api_secure: true

Para especificar el certificado SSL y la clave, puede pegar el 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:
  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-----

5.4.3.6 Distribución de NFS Ganesha #

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 Sección 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

Sustituya EXAMPLE_NFS con una cadena arbitraria que identifique la exportación de NFS.
Sustituya EXAMPLE_POOL con el nombre del repositorio en el que se almacenará el objeto de configuración RADOS de NFS Ganesha.
Sustituya EXAMPLE_NAMESPACE (opcional) con el espacio de nombres NFS de Object Gateway deseado (por ejemplo, ganesha)

5.4.3.7 Distribución de `rbd-mirror` #

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 Sección 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

5.4.3.8 Distribución de la pila de supervisión #

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 Sección 16.1, “Configuración de imágenes personalizadas o locales”.

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

Habilite el módulo prometheus en el daemon de Ceph Manager. Esto expone las métricas internas de Ceph para que Prometheus pueda leerlas:
```
cephuser@adm > ceph mgr module enable prometheus
```
Nota
Asegúrese de que este comando se ejecuta antes de distribuir Prometheus. Si el comando no se ejecutó antes de la distribución, debe volver a distribuir Prometheus para actualizar la configuración de Prometheus:
```
cephuser@adm > ceph orch redeploy prometheus
```

Cree un archivo de especificación (por ejemplo, monitoring.yaml) con un contenido similar al siguiente:

service_type: prometheus
placement:
  hosts:
  - ses-min2
---
service_type: node-exporter
---
service_type: alertmanager
placement:
  hosts:
  - ses-min4
---
service_type: grafana
placement:
  hosts:
  - ses-min3

Aplique los servicios de supervisión ejecutando:
```
cephuser@adm > ceph orch apply -i monitoring.yaml
```
La distribución de los servicios de supervisión puede tardar uno o dos minutos.

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 Sección 16.5.4, “Habilitación de la supervisión de imágenes RBD” para obtener más información.

5 Distribución con cephadm #

5.1 Instalación y configuración de SUSE Linux Enterprise Server #

5.2 Distribución de Salt #

5.3 Distribución del clúster de Ceph #

5.3.1 Instalación de ceph-salt #

5.3.2 Configuración de las propiedades del clúster #

5.3.2.1 Uso de la shell ceph-salt #

5.3.2.2 Adición de minions de Salt #

5.3.2.3 Especificación de minions de Salt gestionados por cephadm #

5.3.2.4 Especificación del nodo de administración #

5.3.2.5 Especificación del primer nodo de MON/MGR #

5.3.2.6 Especificación de perfiles ajustados #

5.3.2.7 Generación de un par de claves SSH #

5.3.2.8 Configuración del servidor de hora #

5.3.2.9 Configuración de las credenciales de entrada de Ceph Dashboard #

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

5.3.2.11 Configuración del registro del contenedor #

5.3.2.12 Habilitación del cifrado en curso de datos (msgr2) #

5.3.2.13 Configuración de la red del clúster #

5.3.2.14 Verificación de la configuración del clúster #

5.3.2.15 Exportación de configuraciones de clúster #

5.3.3 Actualización de nodos y clúster mínimo de arranque #

5.3.4 Revisión de los pasos finales #

5.4 Distribución de servicios y pasarelas #

5.4.1 El comando ceph orch #

5.4.1.1 Visualización del estado del orquestador #

5.4.1.2 Listado de dispositivos, servicios y daemons #

5.4.2 Especificación del servicio y la colocación #

5.4.2.1 Creación de especificaciones de servicio #

5.4.2.2 Creación de especificaciones de colocación #

5.4.2.3 Aplicación de la especificación del clúster #

5.4.2.4 Exportación de la especificación de un clúster en ejecución #

5.4.3 Distribución de servicios de Ceph #

5.4.3.1 Distribución de monitores Ceph Monitor y gestores Ceph Manager #

5.4.3.2 Distribución de los OSD de Ceph #

5.4.3.3 Distribución de servidores de metadatos #

5.4.3.4 Distribución de pasarelas Object Gateways #

5.4.3.4.1 Uso del acceso SSL seguro #

5.4.3.4.2 Distribución con un subclúster #

5.4.3.5 Distribución de pasarelas iSCSI Gateway #

5.4.3.5.1 Configuración SSL segura #

5.4.3.6 Distribución de NFS Ganesha #

5.4.3.7 Distribución de rbd-mirror #

5.4.3.8 Distribución de la pila de supervisión #

5.3.1 Instalación de `ceph-salt` #

5.3.2.1 Uso de la shell `ceph-salt` #

5.4.1 El comando `ceph orch` #

5.4.3.7 Distribución de `rbd-mirror` #