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 los 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-SP2/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-SP2/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.

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

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 Book “Guía de administración y operaciones”, Chapter 28 “Configuración del clúster de Ceph”, Section 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

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

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]

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.

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]

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.

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]

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]

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

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:

1. Configure la URL del registro local:

   cephuser@adm > ceph-salt config /containers/registry_auth/registry set REGISTRY_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 REGISTRY_USERNAME

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

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

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

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

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 Book “Troubleshooting Guide”, Chapter 13 “Hints and tips”, Section 13.7 “Firewall settings for Ceph” para obtener más información.

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.

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

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

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

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

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

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 Book “Guía de administración y operaciones”, Chapter 13 “Tareas operativas”, Section 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 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

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 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 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 Book “Guía de administración y operaciones”, Chapter 10 “Configuración manual”, Section 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 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

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

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

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

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

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

El destino iSCSI de kernel de Linux se denominaba originalmente LIO para linux-iscsi.org, el dominio y sitio Web originales del proyecto. Durante cierto tiempo, había al menos cuatro implementaciones de destino iSCSI compitiendo para la plataforma Linux, pero, al final, LIO prevaleció como el único destino iSCSI de referencia. El código de kernel de la línea principal de LIO utiliza el sencillo, aunque algo ambiguo, nombre de "destino" y distingue entre "núcleo de destino" y una variedad de módulos de destino de interfaz de usuario y procesador final.

El módulo de interfaz de usuario utilizado con mayor frecuencia es, posiblemente, iSCSI. Sin embargo, LIO también admite Fibre Channel (FC), Fibre Channel over Ethernet (FCoE) y otros protocolos de interfaz de usuario. En este momento, SUSE Enterprise Storage solo admite el protocolo iSCSI.

El módulo de procesador final de destino más utilizado es simplemente, cualquiera capaz de reexportar cualquier dispositivo de bloques disponible en el host de destino. Este módulo se denomina iblock. Sin embargo, LIO también tiene un módulo de procesador final RBD específico que admite el acceso de E/S de múltiples rutas paralelizado a imágenes RBD.

Esta sección presenta una breve descripción de los iniciadores iSCSI utilizados en plataformas Linux, Microsoft Windows y VMware.

La distribución de Ceph iSCSI Gateway sigue el mismo procedimiento que la distribución de otros servicios de Ceph mediante cephadm. Para obtener más información, consulte la Sección 5.4.3.5, “Distribución de pasarelas iSCSI Gateway”.

Las imágenes RBD se crean en el almacén de Ceph y, posteriormente, se exportan a iSCSI. Se recomienda utilizar un repositorio RADOS dedicado para este propósito. Es posible crear un volumen desde cualquier host que sea posible conectar al clúster de almacenamiento mediante la utilidad de línea de comandos rbd de Ceph. Esto requiere que el cliente tenga al menos un archivo de configuración ceph.conf mínimo y credenciales de autenticación adecuadas para CephX.

Para crear un volumen nuevo y exportarlo posteriormente a través de iSCSI, use el comando rbd create especificando el tamaño del volumen en megabytes. Por ejemplo, para crear un volumen de 100 GB denominado testvol en el repositorio denominado iscsi-images ejecute:

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

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:

root # cephadm enter --name CONTAINER_NAME

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

root # 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 6.4.4, “Autenticación y control de acceso” para obtener más información sobre la autenticación y el control de acceso.

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

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

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

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

6.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 a 64 caracteres y pueden incluir caracteres alfanuméricos, ., @, -, _ o bien :.

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.

6.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 a 64 caracteres y solo pueden incluir letras, ., @, -, _ o bien :.

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

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.

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

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

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

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

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. Para obtener instrucciones sobre cómo realizar copias de seguridad de todos los datos, consulte https://documentation.suse.com/ses/6/html/ses-all/cha-deployment-backup.html.

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:

root # zypper refresh && zypper patch

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

cephuser@adm > ceph -s

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

En SUSE Enterprise Storage 7, las pasarelas Object Gateway siempre se configuran con un dominio, lo que permite utilizar varios sitios en el futuro (consulte el 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, grupo de zonas y zona.

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

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

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

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

Para mostrar el contenido del repositorio RADOS:

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

Para copiar los objetos RADOS:

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

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

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.