SUSE Enterprise Storage 5 Guía De Distribución Guía De Distribución SUSE Enterprise Storage 5 Por Tomáš Bažant, Jana Haláčková, Y Sven Seeberg

SUSE Enterprise Storage 5 Guía de distribución Guía de distribución SUSE Enterprise Storage 5 por Tomáš Bažant, Jana Haláčková, y Sven Seeberg

Fecha de publicación: 04/07/2021

SUSE LLC 1800 South Novell Place Provo, UT 84606 USA https://documentation.suse.com

El texto y las ilustraciones de este documento tienen licencia Creative Commons Attribution-Share Alike 4.0 International ("CC-BY-SA"). Hay disponible una descripción de CC-BY-SA en http://creativecommons.org/ licenses/by-sa/4.0/legalcode . En conformidad con la licencia CC-BY-SA, si distribuye este documento o una adaptación del mismo, debe proporcionar la URL de la versión original.

Red Hat, Red Hat Enterprise Linux, el logotipo de Shadowman, JBoss, MetaMatrix, Fedora, el logotipo de Innity y RHCE son marcas registradas de Red Hat, Inc. en los Estados Unidos y otros países. Linux® es una marca comercial registrada de Linus Torvalds en los Estados Unidos y otros países. Java® es una marca comercial registrada de Oracle y sus liales. XFS® es una marca comercial de Silicon Graphics International Corporation o sus liales en los Estados Unidos y otros países. MySQL® es una marca comercial registrada de MySQL AB en los Estados Unidos, la Unión Europea y otros países. Todas las demás marcas comerciales pertenecen a sus respectivos propietarios. Para obtener información sobre las marcas comerciales de SUSE, consulte http://www.suse.com/company/ legal/ . Todas las marcas comerciales de otros fabricantes son propiedad de sus respectivas empresas. Los símbolos de marca comercial (®,™ etc.) indican marcas comerciales de SUSE y sus aliados. Los asteriscos (*) indican marcas comerciales de otros fabricantes.

Toda la información recogida en esta publicación se ha compilado prestando toda la atención posible al más mínimo detalle. Sin embargo, esto no garantiza una precisión total. Ni SUSE LLC, ni sus liales, ni los autores o traductores serán responsables de los posibles errores o las consecuencias que de ellos pudieran derivarse. Tabla de contenidos

Acerca de esta guía ix 1 Documentación disponible ix

2 Comentarios x

3 Convenciones de la documentación x

4 Acerca de la elaboración de este manual xi

5 Ceph Contributors xi

I SUSE ENTERPRISE STORAGE 1 1 SUSE Enterprise Storage y Ceph 2 1.1 Características de Ceph 2

1.2 Componentes básicos 3 RADOS 3 • CRUSH 4 • Nodos y daemons de Ceph 5

1.3 Estructura de almacenamiento 6 Repositorio 6 • Grupo de colocación 7 • Ejemplo 7

1.4 BlueStore 8

1.5 Información adicional 10

2 Requisitos y recomendaciones de hardware 11

2.1 Nodos de almacenamiento de objetos 11 Requisitos mínimos 11 • Tamaño mínimo de disco 12 • Tamaño recomendado para el dispositivo WAL y DB de BlueStore 12 • Uso de unidades SSD para diarios OSD 13 • Número máximo de discos recomendados 14

2.2 Nodos de monitor 14

2.3 Nodos de Object Gateway 15

iv Guía de distribución 2.4 Nodos del servidor de metadatos 15

2.5 Master de Salt 15

2.6 Nodos iSCSI 16

2.7 Recomendaciones de red 16 Adición de una red privada a un clúster en ejecución 17 • Nodos de monitor en subredes diferentes 17

2.8 Limitaciones de denominación 18

2.9 Un servidor compartido por varios OSD y monitores 18

2.10 Conﬁguración mínima del clúster 19

2.11 Conﬁguración de clúster de producción recomendada 20

2.12 SUSE Enterprise Storage y otros productos SUSE 21 SUSE Manager 21

3 Conﬁguración de alta disponibilidad del nodo de administración de Ceph 22 3.1 Esquema del clúster de alta disponibilidad para el nodo de administración de Ceph 22

3.2 Vinculación del clúster de alta disponibilidad con nodo de administración de Ceph 23

II DISTRIBUCIÓN Y ACTUALIZACIÓN DEL CLÚSTER 25 4 Distribución con DeepSea/Salt 26 4.1 Lectura de las notas de la versión 27

4.2 Introducción a DeepSea 27 Organización y ubicaciones importantes 29 • Asignación de destino de los minions 29

4.3 Distribución del clúster 32

v Guía de distribución 4.4 Interfaz de línea de comandos de DeepSea 40 Interfaz de línea de comandos de DeepSea: modo de monitor 40 • Interfaz de línea de comandos de DeepSea: modo autónomo 41

4.5 Conﬁguración y personalización 43 El archivo policy.cfg 43 • Archivo ceph.conf personalizado 50

5 Actualización desde versiones anteriores 51

5.1 Lectura de las notas de la versión 51

5.2 Procedimiento de actualización general 51

5.3 Cifrado de OSD durante la actualización 53

5.4 Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la versión 5 55 Migración de OSD a BlueStore 62

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

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

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

6 Copia de seguridad de la conﬁguración del clúster 78

6.1 Copia de seguridad de la conﬁguración de Salt 78

6.2 Copia de seguridad de la conﬁguración de DeepSea 78

7 Personalización de la conﬁguración por defecto 80

7.1 Uso de archivos de configuración personalizados 80 Inhabilitación de un paso de la distribución 80 • Sustitución de un paso de la distribución 81 • Modificación de un paso de la distribución 83 • Modificación de una etapa de la distribución 84 • Inhabilitación de actualizaciones y reinicios durante la fase 0 85

vi Guía de distribución 7.2 Modiﬁcación de la conﬁguración descubierta 86

III INSTALACIÓN DE SERVICIOS ADICIONALES 89 8 Instalación de servicios para acceder a los datos 90

9 Ceph Object Gateway 91

9.1 Instalación manual de Object Gateway 91 Conﬁguración de Object Gateway 92

10 Instalación de iSCSI Gateway 98

10.1 Almacenamiento de bloques iSCSI 98 Destino iSCSI de kernel de Linux 99 • Iniciadores iSCSI 99

10.2 Información general sobre lrbd 100

10.3 Consideraciones de distribución 102

10.4 Instalación y conﬁguración 102 Distribución de iSCSI Gateway en un clúster de Ceph 103 • Creación de imágenes RBD 103 • Exportación de imágenes RBD a través de iSCSI 103 • Valores opcionales 106 • Valores avanzados 107

10.5 Exportación de imágenes del dispositivo de bloques RADOS mediante tcmu-runner 111 Instalación 112 • Conﬁguración y distribución 112 • Uso 114

11 Instalación de CephFS 115

11.1 Escenarios admitidos de CephFS y directrices 115

11.2 Servidor de metadatos de Ceph 116 Adición de un servidor de metadatos 116 • Conﬁguración de un servidor de metadatos 116

11.3 CephFS 117 Creación de CephFS 117 • Tamaño del clúster del servidor de metadatos 119 • Clúster de servidor de metadatos y actualizaciones 120

vii Guía de distribución 12 Instalación de NFS Ganesha 121

12.1 Preparación 121 Información general 121 • Resumen de requisitos 122

12.2 Instalación de ejemplo 122

12.3 Conﬁguración activa-pasiva de alta disponibilidad 123 Instalación básica 124 • Limpieza de recursos 126 • Conﬁguración del recurso de Ping 126 • Alta disponibilidad de NFS Ganesha y DeepSea 127

12.4 Más información 127

13 Exportación de CephFS mediante Samba 128

13.1 Instalación de ejemplo 128

13.2 Conﬁguración de alta disponibilidad 129

A Actualizaciones de la documentación 134 A.1 Octubre de 2018 (lanzamiento de SUSE Enterprise Storage 5.5) 134

A.2 Noviembre de 2017 (actualización de mantenimiento) 137

A.3 Octubre de 2017 (lanzamiento de SUSE Enterprise Storage 5) 139

viii Guía de distribución Acerca de esta guía

SUSE Enterprise Storage es una extensión de SUSE Linux Enterprise. Combina las funciones del proyecto de almacenamiento Ceph (http://ceph.com/ ) con la ingeniería empresarial y la asistencia de SUSE. SUSE Enterprise Storage proporciona a las organizaciones de TI la capacidad de implementar una arquitectura de almacenamiento distribuida que admite varios casos de uso mediante plataformas de hardware básicas. En esta guía se explican los conceptos de SUSE Enterprise Storage con el objetivo principal de gestionar y administrar la infraestructura de Ceph. También se muestra cómo usar Ceph con otras soluciones relacionados, como OpenStack o KVM. Muchos capítulos de este manual contienen vínculos a recursos de documentación adicionales. Se incluye documentación adicional que está disponible en el sistema, así como documentación a la que se accede desde Internet. Para obtener una descripción general acerca de la documentación disponible en relación con el producto y de las actualizaciones más recientes, consulte http://www.suse.com/documentation .

1 Documentación disponible

Los manuales disponibles para este producto son los siguientes:

Libro “Guía de administración” La guía describe varias tareas de administración que normalmente se llevan a cabo después de la instalación. Esta guía también incluye los pasos necesarios para integrar Ceph con soluciones de virtualización como libvirt , Xen o KVM; así como formas para acceder a objetos almacenados en el clúster mediante pasarelas iSCSI y RADOS.

Guía de distribución Este manual sirve de guía para los pasos de instalación del clúster de Ceph y de todos los servicios relacionados con Ceph. También muestra una estructura de clúster de Ceph básica y proporciona la terminología relacionada.

Encontrará las versiones en formato HTML de los manuales de productos en el sistema instalado, en /usr/share/doc/manual . Las últimas actualizaciones de la documentación están en http:// www.suse.com/documentation , donde puede descargar los manuales para el producto en varios formatos.

ix Documentación disponible SES 5 2 Comentarios

Existen varios canales disponibles para hacernos llegar los comentarios:

Errores y peticiones de mejoras Para obtener más información sobre los servicios y las opciones de asistencia técnica disponibles para el producto, consulte http://www.suse.com/support/ . Para informar sobre errores en un componente de producto, entre en el Centro de servicios al cliente de Novell desde http://www.suse.com/support/ y seleccione Mi asistencia técnica Petición de servicio.

Comentarios del usuario Nos gustaría recibir sus comentarios o sugerencias acerca de este manual y del resto de la documentación incluida junto con el producto. Utilice la función de comentarios del usuario, situada en la parte inferior de las páginas de la documentación en línea, o bien diríjase a http://www.suse.com/documentation/feedback.html e introduzca ahí sus comentarios.

Correo Para hacernos llegar comentarios sobre la documentación del producto, también puede enviar un mensaje de correo a [email protected] . No olvide incluir el título del documento, la versión del producto y la fecha de publicación de la documentación. Para informar de errores o sugerir mejoras, proporcione una descripción concisa del problema y haga referencia a la sección y página (o URL) en concreto donde lo ha encontrado.

3 Convenciones de la documentación

En este manual se utilizan las siguientes convenciones tipográcas:

/etc/passwd : nombres de directorio y nombres de archivos

espacio reservado : se sustituye espacio reservado con el valor real

PATH : variable de entorno PATH

ls , --help : comandos, opciones y parámetros

usuario : usuarios o grupos

Alt , Alt – F1 : tecla o combinación de teclas que se deben pulsar; las teclas se muestran en mayúsculas, tal y como aparecen en el teclado

x Comentarios SES 5 Archivo, Archivo Guardar como: elementos de menú, botones_

Pingüinos que bailan (Capítulo Pingüinos, ↑Otro manual): referencia a un capítulo de otro manual.

4 Acerca de la elaboración de este manual

Este libro se ha redactado en GeekoDoc, un subconjunto de DocBook (consulte http:// www.docbook.org ). Los archivos de origen XML fueron validados mediante xmllint , procesados por xsltproc y convertidos a XSL-FO gracias a una versión personalizada de las hojas de estilo de Norman Walsh. El formato PDF nal se puede aplicar mediante FOP de Apache o mediante XEP de RenderX. Las herramientas de creación y publicación usadas para crear este manual están disponibles en el paquete daps . El conjunto de aplicaciones DocBook Authoring and Publishing Suite (DAPS) se ha desarrollado como software de código abierto. Para obtener más información, consulte: http://daps.sf.net/ .

5 Ceph Contributors

The Ceph project and its documentation is a result of hundreds of contributors and organizations. See https://ceph.com/contributors/ for more details.

xi Acerca de la elaboración de este manual SES 5 I SUSE Enterprise Storage

1 SUSE Enterprise Storage y Ceph 2

2 Requisitos y recomendaciones de hardware 11

3 Conﬁguración de alta disponibilidad del nodo de administración de

Ceph 22 1 SUSE Enterprise Storage y Ceph

SUSE Enterprise Storage es un sistema de almacenamiento distribuido basado en la tecnología Ceph diseñado para que tenga capacidad de ampliación, sea able y aporte alto rendimiento. Los clústeres de Ceph se pueden ejecutar en servidores básicos en una red común como Ethernet. Es posible ampliar fácilmente el clúster hasta miles de servidores (a partir de ahora denominados nodos) y almacenar petabytes de información. A diferencia de los sistemas convencionales que cuentan con tablas de asignación para almacenar y recuperar datos, Ceph utiliza un algoritmo determinista para asignar el almacenamiento de datos y no tiene ninguna estructura de información centralizada. Ceph entiende que en los clústeres de almacenamiento la adición o eliminación de hardware es la norma, no la excepción. El clúster de Ceph automatiza las tareas de gestión, como la distribución, redistribución y réplica de datos; la detección de fallos y la recuperación. Ceph se autorrepara y se autoadministra, con lo que se consigue una reducción de las tareas administrativas y del presupuesto necesario. Este capítulo proporciona una visión general de SUSE Enterprise Storage y describe brevemente los componentes más importantes.

Sugerencia A partir de SUSE Enterprise Storage 5, el único método de distribución de clústeres admitido es DeepSea. Consulte el Capítulo 4, Distribución con DeepSea/Salt para obtener más información sobre el proceso de distribución.

1.1 Características de Ceph

El entorno Ceph incluye las siguientes características:

Capacidad de ampliación Ceph puede ampliarse a miles de nodos y gestionar petabytes de almacenamiento.

Hardware básico Para ejecutar un clúster de Ceph no se requiere ningún hardware especial. Para obtener información, consulte el Capítulo 2, Requisitos y recomendaciones de hardware

Autoadministración

2 Características de Ceph SES 5 El clúster de Ceph se gestiona automáticamente. Cuando se añaden o se eliminan nodos, o cuando estos fallan, el clúster redistribuye los datos automáticamente. También es consciente de los discos sobrecargados.

Sin un único punto de error Ningún nodo de un clúster almacena información importante por sí solo. El número de redundancias se puede congurar.

Software de código abierto Ceph es una solución de software de código abierto e independiente de hardware o proveedores especícos.

1.2 Componentes básicos

Para aprovechar al máximo las ventajas de Ceph, es necesario comprender algunos de sus componentes y conceptos básicos. Esta sección presenta algunas partes de Ceph a las que se hace referencia con frecuencia en otros capítulos.

1.2.1 RADOS

El componente básico de Ceph se denomina RADOS (Reliable Autonomic Distributed Object Store, almacén de objetos distribuido autónomo able). 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 identicador y datos. RADOS proporciona los siguientes métodos de acceso para los objetos almacenados que abarcan muchos casos de uso:

Object Gateway Object Gateway es una pasarela REST HTTP para el almacén de objetos RADOS. Permite el acceso directo a los objetos almacenados en el clúster de Ceph.

Dispositivo de bloques RADOS Es posible acceder a los dispositivos de bloques RADOS (RBD) igual que a cualquier otro dispositivo de bloques. Por ejemplo, se pueden usar en combinación con libvirt con nes de virtualización.

CephFS El sistema de archivos de Ceph tiene conformidad con POSIX.

3 Componentes básicos SES 5 librados librados es una biblioteca que se puede utilizar con varios lenguajes de programación a n de crear una aplicación capaz de interactuar directamente con el clúster de almacenamiento. 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”).

RADOS

FIGURA 1.1: INTERFACES CON EL ALMACÉN DE OBJETOS DE CEPH

1.2.2 CRUSH

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 denidas 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 ecaz. 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 denidas por el administrador para almacenar los objetos en el clúster. Dene 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 las y las las en centros de datos. Esta estructura se puede utilizar para denir dominios de fallo. Ceph se asegura de que las réplicas se almacenan en diferentes ramas de un dominio de fallo concreto.

4 CRUSH SES 5 Si el dominio de fallo se dene 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 la de bastidores, el dominio de fallo se puede denir en la la. Cuando se produce un fallo en la unidad de distribución de alimentación, los datos replicados siguen disponibles en las demás las.

1.2.3 Nodos y daemons de Ceph

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 MGR, que se pueden colocar junto con daemons de MON. Cada clúster requiere al menos daemons de MON, MGR y OSD:

Ceph Monitor Los nodos de Ceph Monitor (a menudo abreviado como MON) guardan información sobre el estado de la actividad del clúster: un mapa de todos los nodos y las reglas de distribución de los datos (consulte la Sección 1.2.2, “CRUSH”). Si se producen fallos o conictos, los nodos de Ceph Monitor del clúster deciden por mayoría qué información es la correcta. Para formar una mayoría cualicada, se recomienda tener un número impar de nodos de Ceph Monitor, y tres como mínimo. Si se utiliza más de un sitio, los nodos de Ceph Monitor deben distribuirse en un número impar de sitios. El número de nodos de Ceph Monitor por sitio debe ser superior al 50 % de los nodos de Ceph Monitor que permanecen operativos si se produce un fallo en un sitio.

Ceph Manager Ceph Manager (MGR) recopila la información de estado de todo el clúster. El daemon de Ceph Manager se ejecuta junto con los daemons de monitor. Proporciona supervisión adicional y sirve de interfaz entre los sistemas de supervisión y gestión externos. Ceph Manager no requiere conguración adicional, aparte de asegurarse de que está en ejecución. Se puede distribuir como una función independiente con DeepSea.

Ceph OSD Un Ceph OSD es un daemon que gestiona dispositivos de almacenamiento de objetos, que son unidades de almacenamiento físicas o lógicas (discos duros o particiones). Los dispositivos de almacenamiento de objetos pueden ser discos físicos/particiones o volúmenes lógicos. El daemon se encarga también de la réplica de datos y del reequilibrio de la carga en caso de que se añadan o se eliminen nodos.

5 Nodos y daemons de Ceph SES 5 Los daemons Ceph OSD se comunican con los daemons de monitor y les proporcionan el estado de los demás daemons de OSD.

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

Servidor de metadatos (MDS) Los servidores de metadatos almacenan metadatos para CephFS. Mediante un servidor de metadatos es posible ejecutar comandos básicos del sistema de archivos como ls sin sobrecargar el clúster.

Object Gateway Ceph Object Gateway es una pasarela HTTP REST para el almacén de objetos RADOS. Es compatible con OpenStack Swift y Amazon S3 y tiene su propia de gestión de usuarios.

NFS Ganesha NFS Ganesha proporciona acceso NFS para Object Gateway o CephFS. Se ejecuta en el espacio del usuario, en lugar de en el espacio del kernel, e interactúa directamente con Object Gateway o CephFS. iSCSI Gateway iSCSI es un protocolo de red de almacenamiento que permite a los clientes enviar comandos SCSI a dispositivos de almacenamiento SCSI (destinos) en servidores remotos.

1.3 Estructura de almacenamiento

1.3.1 Repositorio

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 denir un conjunto de reglas; por ejemplo, cuántas réplicas de cada objeto deben existir. La conguración estándar de los repositorios se denomina repositorio replicado. Los repositorios suelen contener objetos, pero también pueden congurarse para actuar como si fueran un sistema RAID 5. En esta conguració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 denir el número de datos y de porciones de código. En esta conguración, los repositorios se denominan repositorios codicados de borrado.

6 Estructura de almacenamiento SES 5 1.3.2 Grupo de colocación

Los grupos de colocación (PG) se utilizan para la distribución de datos dentro de un repositorio. Cuando se crea un repositorio, se dene 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.

1.3.3 Ejemplo

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 conguració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.0 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á denido 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 dena 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 conrma que el proceso de escritura ha terminado después de que todos los demás OSD hayan almacenado el objeto.

7 Grupo de colocación SES 5 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.

1.4 BlueStore

BlueStore es el procesador nal de almacenamiento por defecto para Ceph desde SUSE Enterprise Storage 5. Su rendimiento es mejor que el de FireStore y cuenta con suma de comprobación de los datos completos y compresión integrada.

8 BlueStore SES 5 BlueStore puede gestionar uno, dos o tres dispositivos de almacenamiento. En el caso más sencillo, BlueStore consume un único dispositivo de almacenamiento primario. Normalmente, el dispositivo de almacenamiento se divide en dos partes:

1. Una pequeña partición denominada BlueFS que implementa las funciones de sistema de archivos requeridas por RocksDB.

2. El resto del dispositivo suele estar ocupado por una partición de gran tamaño. Se gestiona directamente mediante BlueStore y contiene todos los datos reales. Este dispositivo primario normalmente se identica mediante un enlace simbólico de bloque en el directorio de datos.

También es posible distribuir BlueStore en dos dispositivos adicionales: Un dispositivo WAL que se puede usar para el diario interno o el registro de escritura anticipada de BlueStore. Se identica mediante el enlace simbólico block.wal en el directorio de datos. Solo resulta útil emplear un dispositivo WAL independiente si el dispositivo es más rápido que el dispositivo primario o que el dispositivo DB, por ejemplo en estos casos:

Si el dispositivo WAL es un NVMe, el dispositivo DB es una unidad SSD y el dispositivo de datos es una unidad SSD o un disco duro.

Los dispositivos WAL y DB están en unidades SSD independientes, y el dispositivo de datos está en un SSD o un disco duro.

Es posible utilizar un dispositivo DB para almacenar los metadatos internos de BlueStore. BlueStore (o en su lugar, la instancia incrustada de RocksDB) colocará todos los metadatos que pueda en el dispositivo DB para mejorar el rendimiento. De nuevo, provisionar un dispositivo DB compartido solo resulta útil si es más rápido que el dispositivo primario.

Sugerencia: planiﬁcación del tamaño del dispositivo DB Debe realizar una planicación exhaustiva para asignar un tamaño suciente al dispositivo DB. Si el dispositivo DB se llena, los metadatos se diseminarán por todo el dispositivo primario, lo que afectará muy negativamente al rendimiento del OSD. Puede comprobar si una partición WAL/BD se está llenando y desbordándose con el comando ceph daemon osd.ID perf dump . El valor slow_used_bytes muestra la cantidad de datos que se han desbordado:

root@minion > ceph daemon osd.ID perf dump | jq '.bluefs'

9 BlueStore SES 5 "db_total_bytes": 1073741824, "db_used_bytes": 33554432, "wal_total_bytes": 0, "wal_used_bytes": 0, "slow_total_bytes": 554432, "slow_used_bytes": 554432,

1.5 Información adicional

Ceph es un proyecto comunitario que cuenta con su propia documentación en línea completa. Para obtener información sobre temas que no encuentre en este manual, consulte http://docs.ceph.com/docs/master/ .

La publicación original CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data (CRUSH: colocación controlada, ampliable y descentralizada de datos replicados) de S.A. Weil, S.A. Brandt, E.L. Miller y C. Maltzahn proporciona información útil sobre el funcionamiento interno de Ceph. Se recomienda su lectura sobre todo al distribuir clústeres a gran escala. Encontrará la publicación en http://www.ssrc.ucsc.edu/papers/weil- sc06.pdf .

10 Información adicional SES 5 2 Requisitos y recomendaciones de hardware

Los requisitos de hardware de Ceph dependen en gran medida de la carga de trabajo de E/S. Se deben tener en cuenta los requisitos y recomendaciones de hardware siguientes como punto de partida para realizar una planicación detallada. En general, las recomendaciones proporcionadas en esta sección dependerán de los procesos que haya activos. Si hay varios procesos en el mismo equipo, los requisitos de CPU, RAM, espacio en disco y red deben sumarse.

2.1 Nodos de almacenamiento de objetos

2.1.1 Requisitos mínimos

Se necesitan al menos 4 nodos OSD, con 8 discos OSD cada uno.

Para los OSD que no usen BlueStore, se requiere como mínimo 1 GB de RAM por terabyte de capacidad OSD en bruto para cada nodo de almacenamiento OSD. Se recomiendan 1,5 GB de RAM por terabyte de capacidad OSD en bruto. Durante la recuperación, lo óptimo serían 2 GB de RAM por terabyte de capacidad OSD en bruto. Para los OSD que utilicen BlueStore, calcule primero el tamaño de RAM que se recomienda para los OSD que no utilizan BlueStore y, a continuación, calcule 2 GB más el tamaño del caché de RAM de BlueStore para cada proceso de OSD. Elija el valor más alto de RAM de esos dos resultados. Tenga en cuenta que el caché de BlueStore por defecto es de 1 GB para unidades HDD y 3 GB para unidades SSD. En resumen, elija el valor máximo de:

[1GB * OSD count * OSD size]

[(2 + BS cache) * OSD count]

Se requiere como mínimo 1,5 GHz de núcleo CPU lógico por OSD para cada proceso de daemon de OSD. Se recomiendan 2 GHz por proceso de daemon de OSD. Tenga en cuenta que Ceph ejecuta un proceso de daemon de OSD por cada disco de almacenamiento; no cuente los discos reservados exclusivamente para usarse como diarios OSD, diarios WAL, metadatos omap o cualquier combinación de estos tres casos.

11 Nodos de almacenamiento de objetos SES 5 Ethernet de 10 Gb (dos interfaces de red vinculadas a varios conmutadores).

Discos OSD en conguraciones JBOD.

Los discos OSD deben utilizarse exclusivamente para SUSE Enterprise Storage.

Disco o unidad SSD dedicado para el sistema operativo, preferiblemente en una conguración de RAID 1.

Si este host OSD va a alojar parte de un repositorio de caché que se utilice para la clasicación en niveles del caché, asigne al menos 4 GB de RAM adicionales.

Por motivos de rendimiento del disco, los nodos OSD deben instalarse desde cero y no deben estar virtualizados.

2.1.2 Tamaño mínimo de disco

Existen dos tipos de espacio de disco necesarios para ejecutarse en OSD: el espacio para el diario del disco (para FileStore) o dispositivo WAL/DB (para BlueStore), y el espacio primario para los datos almacenados. El valor mínimo (y por defecto) para el diario/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 nes de prueba.

2.1.3 Tamaño recomendado para el dispositivo WAL y DB de BlueStore

Sugerencia: más información Consulte la Sección 1.4, “BlueStore” para obtener más información sobre BlueStore.

A continuación se indican varias reglas para determinar el tamaño del dispositivo WAL/DB. Si se usa DeepSea para implementar los OSD con BlueStore, se aplican automáticamente las reglas recomendadas y se notica el administrador al respecto.

12 Tamaño mínimo de disco SES 5 10 GB del dispositivo DB por cada terabyte de capacidad OSD (1/100 del OSD).

Entre 500 MB y 2 GB para el dispositivo WAL. El tamaño del WAL depende del tráco de datos y la carga de trabajo, no del tamaño del OSD. Si sabe que un OSD es físicamente capaz de gestionar pequeñas acciones de escritura y sobrescritura a un rendimiento muy elevado, es preferible disponer de dispositivos WAL en exceso a que su número sea insuciente. Un dispositivo WAL de 1 GB es una opción equilibrada válida para la mayoría de las distribuciones.

Si tiene previsto colocar el dispositivo WAL y el dispositivo DB en el mismo disco, se recomienda usar una partición única para ambos dispositivos, en lugar de tener una partición independiente para cada uno. Esto permite a Ceph utilizar también el dispositivo DB para el funcionamiento de WAL. Por lo tanto, la gestión del espacio de disco es más ecaz, ya que Ceph utiliza la partición de DB para WAL solo si es necesario. Otra ventaja es que la probabilidad de que la partición WAL se llene es muy pequeña, y si no se utiliza por completo, su espacio no se desperdicia, sino que se usa para el funcionamiento del dispositivo DB. Para compartir el dispositivo DB con el dispositivo WAL, no especique el dispositivo WAL: especique solo el dispositivo DB:

bluestore_block_db_path = "/path/to/db/device" bluestore_block_db_size = 10737418240 bluestore_block_wal_path = "" bluestore_block_wal_size = 0

Si lo preere, puede colocar el dispositivo WAL en su propio dispositivo independiente. En tal caso, se recomienda usar el dispositivo más rápido para el funcionamiento de WAL.

2.1.4 Uso de unidades SSD para diarios OSD

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 signicativa del rendimiento si almacenan su diario en una unidad SSD y los datos del objeto en un disco duro independiente.

13 Uso de unidades SSD para diarios OSD SES 5 Sugerencia: cómo compartir un SSD para varios diarios Los datos del diario ocupan relativamente poco espacio, por lo que puede montar varios directorios de diario en un único disco SSD. Tenga en cuenta que con cada diario compartido, el rendimiento del disco SSD se resiente. No es recomendable compartir más de seis diarios en el mismo disco SSD o 12 en discos NVMe.

2.1.5 Número máximo de discos recomendados

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

Ancho de banda de red. Cuantos más discos haya en un servidor, más datos deben transferirse a través de las tarjetas de red para las operaciones de escritura del disco.

Memoria. Para obtener un rendimiento óptimo, reserve al menos 2 GB de RAM por terabyte de espacio de disco instalado.

Tolerancia a fallos. Si el servidor falla por completo, cuantos más discos tenga, más OSD perderá temporalmente el clúster. Además, para mantener las reglas de réplica en ejecución, necesita copiar todos los datos desde el servidor que ha fallado a los demás nodos del clúster.

2.2 Nodos de monitor

Se necesitan al menos tres nodos de Ceph Monitor. El número de monitores debe ser siempre impar (1+2n).

4 GB de RAM.

Procesador con cuatro núcleos lógicos.

Se recomienda un disco SSD u otro tipo de almacenamiento sucientemente rápido para los monitores, especícamente para la vía /var/lib/ceph de cada nodo de monitor, ya que el quórum puede ser inestable con latencias elevadas de disco. Se recomiendan dos discos con conguración RAID 1 para aportar redundancia. Se recomienda utilizar discos

14 Número máximo de discos recomendados SES 5 distintos, o al menos particiones de disco independientes para los procesos de monitor a n de proteger el espacio disponible en el monitor frente a estados como la ralentización del archivo de registro.

Solo debe haber un proceso de monitor por nodo.

La mezcla de nodos de OSD, monitor y Object Gateway solo se admite si los recursos de hardware disponibles son sucientes. Esto signica que deberán sumarse los requisitos de todos los servicios.

Dos interfaces de red vinculadas a varios conmutadores.

2.3 Nodos de Object Gateway

Los nodos de Object Gateway deben tener de seis a ocho núcleos de CPU y 32 GB de RAM (se recomiendan 64 GB). Si hay otros procesos ubicados en el mismo equipo, deben sumarse sus requisitos.

2.4 Nodos del servidor de metadatos

El tamaño correcto de los nodos del servidor de metadatos depende del caso de uso especíco. Por lo general, cuantos más archivos abiertos deba gestionar el servidor de metadatos, más CPU y RAM se necesitará. A continuación se muestran los requisitos mínimos:

3 G de RAM por cada daemon del servidor de metadatos.

Interfaz de red vinculada.

2,5 GHz de CPU con un mínimo de 2 núcleos.

2.5 Master de Salt

Se requieren al menos 4 GB de RAM y una CPU de cuatro núcleos. Esto incluye la ejecución de openATTIC en el master de Salt. Para clústeres de gran tamaño con cientos de nodos, se recomiendan 6 GB de RAM.

15 Nodos de Object Gateway SES 5 2.6 Nodos iSCSI

Los nodos iSCSI deben tener de seis a ocho núcleos de CPU y 16 GB de RAM.

2.7 Recomendaciones de red

Es recomendable que el entorno de redes donde tenga previsto ejecutar Ceph sea un conjunto vinculado de al menos dos interfaces de red divididas lógicamente en una parte pública y una parte interna de conanza mediante VLAN. Se recomienda que el modo de vinculación sea 802.3ad, si es posible, para proporcionar el máximo ancho de banda y mayor estabilidad. La VLAN pública sirve para proporcionar el servicio a los clientes, mientras que la parte interna proporciona la comunicación de red Ceph autenticada. El principal motivo para esto es que, aunque Ceph proporciona autenticación y protección contra los ataques cuando las claves secretas están aplicadas, los mensajes que se utilizan para congurar estas claves podrían transferirse de forma abierta y son vulnerables.

Sugerencia: nodos conﬁgurados a través de DHCP Si los nodos de almacenamiento se conguran a través de DHCP, es posible que los tiempos límite por defecto no sean sucientes para que la red se congure 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 (si se ejecuta systemctl status ceph\* se producirán errores de tipo "unable to bind" [no es posible vincular]). Para evitar este problema, se recomienda aumentar el tiempo límite del cliente DHCP al menos a 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 , dena

DHCLIENT_WAIT_AT_BOOT="30"

En /etc/sysconfig/network/config , dena

WAIT_FOR_INTERFACES="60"

16 Nodos iSCSI SES 5 2.7.1 Adición de una red privada a un clúster en ejecución

Si no especica una red de clúster durante la distribución de Ceph, se considera que se trata de un único entorno de redes público. Aunque Ceph funciona correctamente con una red pública, su rendimiento y la seguridad mejoran si se establece una segunda red de clúster privada. Para que admitan dos redes, cada nodo de Ceph debe tener al menos dos tarjetas de red. Debe aplicar los cambios siguientes a cada nodo de Ceph. Hacerlo en un clúster pequeño es relativamente rápido, pero si el clúster está formado por cientos o miles de nodos, puede tardarse mucho tiempo.

1. Detenga los servicios relacionados con Ceph en cada nodo del clúster. Añada una línea a /etc/ceph/ceph.conf para denir la red de clúster, por ejemplo:

cluster network = 10.0.0.0/24

Si necesita asignar especícamente direcciones IP estáticas o anular los valores de cluster network (red del clúster), puede hacerlo con el comando opcional cluster addr .

2. Compruebe que la red de clúster privada funciona según lo previsto en el nivel de sistema operativo.

3. Inicie los servicios relacionados con Ceph en cada nodo del clúster.

sudo systemctl start ceph.target

2.7.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 ajustar el archivo ceph.conf según corresponda. Por ejemplo, si los nodos tienen las direcciones IP 192.168.123.12, 1.2.3.4 y 242.12.33.12, añada las líneas siguientes a la sección global:

[global] [...] mon host = 192.168.123.12, 1.2.3.4, 242.12.33.12 mon initial members = MON1, MON2, MON3 [...]

17 Adición de una red privada a un clúster en ejecución SES 5 Asimismo, si debe especicar una dirección pública o red por cada monitor, deberá añadir una sección [mon.X] por cada monitor:

[mon.MON1] public network = 192.168.123.0/24

[mon.MON2] public network = 1.2.3.0/24

[mon.MON3] public network = 242.12.33.12/0

2.8 Limitaciones de denominación

En general, Ceph no admite caracteres no ASCII en los archivos de conguración, los nombres de repositorio, los nombres de usuario, etc. Cuando congure un clúster de Ceph, se recomienda utilizar solo caracteres alfanuméricos sencillos (A-z, a-z, 0-9) y la puntuación mínima (".", "" o "_") en todos los nombres de objeto y conguración de Ceph.

2.9 Un servidor compartido por varios OSD y monitores

Aunque es técnicamente posible ejecutar varios Ceph OSD y Ceph Monitor en el mismo servidor en entornos de prueba, se recomienda encarecidamente disponer de un servidor independiente para cada nodo de monitor en entornos de producción. El motivo principal es el rendimiento: cuantos más OSD tenga el clúster, más operaciones de E/S deberán realizar los nodos de monitor. Y cuando se comparte un servidor entre un nodo de monitor y varios OSD, las operaciones de E/S de los OSD suponen un factor limitador para el nodo de monitor. Otra consideración importante a tener en cuenta es si se comparten discos entre un OSD, un nodo de monitor y el sistema operativo en el servidor. La respuesta es sencilla: si es posible, dedique un disco independiente al OSD y un servidor independiente a un nodo de monitor. Aunque Ceph admite los OSD basados en directorios, un OSD siempre debe tener un disco dedicado distinto al que se use para el sistema operativo.

18 Limitaciones de denominación SES 5 Sugerencia Si es realmente necesario ejecutar el OSD y el nodo de monitor en el mismo servidor, ejecute el monitor en un disco independiente montando ese disco en el directorio /var/ lib/ceph/mon para mejorar ligeramente el rendimiento.

2.10 Conﬁguración mínima del clúster

Cuatro nodos de almacenamiento de objetos

Ethernet de 10 Gb (dos redes vinculadas a varios conmutadores)

32 OSD por clúster de almacenamiento

El diario de OSD puede encontrarse en el disco de OSD

Un disco de SO dedicado para cada nodo de almacenamiento de objeto

1 GB de RAM por TB de capacidad de OSD en bruto para cada nodo de almacenamiento de objeto

1,5 GHz por OSD para cada nodo de almacenamiento de objeto

Los monitores Ceph Monitor, la pasarela y los servidores de metadatos pueden encontrarse en los nodos de almacenamiento de objeto

Tres nodos de Ceph Monitor (se requiere SSD para la unidad de sistema operativo dedicada)

Los nodos de Ceph Monitor, de Object Gateway y de servidores de metadatos requieren una distribución redundante

Las instancias de iSCSI Gateway, Object Gateway y los servidores de metadatos requieren 4 GB de RAM incremental y cuatro núcleos

Nodo de gestión independiente con 4 GB de RAM, cuatro núcleos y 1 TB de capacidad

19 Conﬁguración mínima del clúster SES 5 2.11 Conﬁguración de clúster de producción recomendada

Siete nodos de almacenamiento de objeto

Ningún nodo individual debe superar aproximadamente el 15 % del almacenamiento total

Ethernet de 10 Gb (cuatro redes vinculadas a varios conmutadores)

Más de 56 OSD por clúster de almacenamiento

Discos de SO RAID 1 para cada nodo de almacenamiento OSD

Discos SSD para el diario con una proporción de 6:1 entre el diario de SSD y los OSD

1,5 GB de RAM por TB de capacidad OSD en bruto para cada nodo de almacenamiento de objeto

2 GHz por OSD para cada nodo de almacenamiento de objeto

Nodos de infraestructura física dedicados

Tres nodos de Ceph Monitor: 4 GB de RAM, procesador de 4 núcleos, SSD RAID 1 para el disco

Un nodo de gestión de SES: 4 GB de RAM, procesador de 4 núcleos, SSD RAID 1 para el disco

Distribución física redundante de los nodos de pasarela o de servidor de metadatos:

Nodos de Object Gateway: 32 GB de RAM, procesador de 8 núcleos, SSD para el disco

Nodos de iSCSI Gateway: 16 GB de RAM, procesador de 4 núcleos, SSD para el disco

Nodos de servidor de metadatos (uno activo y uno en hot standby): 32 GB de RAM, procesador de 8 núcleos, SSD RAID 1 para el disco

20 Conﬁguración de clúster de producción recomendada SES 5 2.12 SUSE Enterprise Storage y otros productos SUSE

Esta sección contiene información importante acerca de la integración de SUSE Enterprise Storage con otros productos SUSE.

2.12.1 SUSE Manager

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

21 SUSE Enterprise Storage y otros productos SUSE SES 5 3 Conﬁguración de alta disponibilidad del nodo de administración de Ceph

El nodo de administración de Ceph es un nodo de clúster de Ceph donde se ejecuta el servicio del master de Salt. El nodo de administración es un punto central del clúster de Ceph porque gestiona el resto de los nodos del clúster consultando y dando instrucciones a los servicios minion de Salt. Normalmente también incluye otros servicios; por ejemplo, la interfaz de usuario Web openATTIC con la consola Grafana respaldada por el kit de herramientas de supervisión Prometheus. En caso de que el nodo de administración de Ceph falle, lo habitual es que deba proporcionar un nuevo hardware que funcione para el nodo y que tenga que restaurar la pila de conguración del clúster completa a partir de una copia de seguridad reciente. Este método lleva bastante tiempo y provoca interrupciones del clúster. Para evitar tiempos de inactividad del clúster de Ceph debido a fallos en el nodo de administración, se recomienda usar el clúster de alta disponibilidad (HA) para el nodo de administración de Ceph.

3.1 Esquema del clúster de alta disponibilidad para el nodo de administración de Ceph

La idea de un clúster de alta disponibilidad consiste en que, en caso de fallo del nodo del clúster, el otro nodo se haga cargo automáticamente de su función, incluido el nodo de administración de Ceph virtualizado. De este modo, los otros nodos del clúster de Ceph no notan que el nodo de administración de Ceph ha fallado.

22 Esquema del clúster de alta disponibilidad para el nodo de administración de Ceph SES 5 La solución de alta disponibilidad mínima para el nodo de administración de Ceph requiere el siguiente hardware:

Dos servidores instalados desde cero donde se pueda ejecutar SUSE Linux Enterprise con la extensión de alta disponibilidad y donde se pueda virtualizar el nodo de administración de Ceph.

Dos o más vías de comunicación de red redundantes; por ejemplo, mediante vínculos de dispositivos de red.

Almacenamiento compartido para alojar las imágenes de disco de la máquina virtual del nodo de administración de Ceph. Debe ser posible acceder al almacenamiento compartido desde ambos servidores. Puede ser, por ejemplo, una exportación NFS, un recurso compartido Samba o el destino iSCSI.

Encontrará más información sobre los requisitos del clúster en https://www.suse.com/ documentation/sle-ha-12/install-quick/data/install-quick.html#sec_ha_inst_quick_req .

FIGURA 3.1: CLÚSTER DE ALTA DISPONIBILIDAD DE 2 NODOS PARA EL NODO DE ADMINISTRACIÓN DE CEPH

3.2 Vinculación del clúster de alta disponibilidad con nodo de administración de Ceph

El procedimiento siguiente resume los pasos más importantes a la hora de crear el clúster de alta disponibilidad para la virtualización del nodo de administración de Ceph. Para obtener más detalles, consulte los enlaces indicados.

23 Vinculación del clúster de alta disponibilidad con nodo de administración de Ceph SES 5 1. Congure un clúster de alta disponibilidad básico de 2 nodos con almacenamiento compartido, como se describe en https://www.suse.com/documentation/sle-ha-12/install- quick/data/install-quick.html .

2. En ambos nodos del clúster, instale todos los paquetes necesarios para ejecutar el hipervisor KVM y el kit de herramientas libvirt , como se describe en https:// www.suse.com/documentation/sles-12/book_virt/data/sec_vt_installation_kvm.html .

3. En el primer nodo del clúster, cree una máquina virtual KVM nueva mediante libvirt , como se describe en https://www.suse.com/documentation/sles-12/book_virt/ data/sec_libvirt_inst_vmm.html . Utilice el almacenamiento compartido precongurado para almacenar las imágenes de disco de la máquina virtual.

4. Después de que se haya completado la conguración de la máquina virtual, exporte su conguración a un archivo XML en el almacenamiento compartido. Utilice la siguiente sintaxis:

root # virsh dumpxml VM_NAME > /path/to/shared/vm_name.xml

5. Cree un recurso para la máquina virtual del nodo de administración de Ceph. Consulte https://www.suse.com/documentation/sle-ha-12/book_sleha/data/ cha_conf_hawk2.html para obtener información general sobre cómo crear recursos de alta disponibilidad. Encontrará información detallada sobre cómo crear un recurso para una máquina virtual KVM en http://www.linux-ha.org/wiki/VirtualDomain_ %28resource_agent%29 .

6. En la máquina virtual invitada que acaba de crear, distribuya el nodo de administración de Ceph, incluidos los servicios adicionales que necesite allí. Siga los pasos relevantes de la Sección 4.3, “Distribución del clúster”. Al mismo tiempo, distribuya los demás nodos del clúster de Ceph en los servidores del clúster que no sean de alta disponibilidad.

24 Vinculación del clúster de alta disponibilidad con nodo de administración de Ceph SES 5 II Distribución y actualización del clúster

4 Distribución con DeepSea/Salt 26

5 Actualización desde versiones anteriores 51

6 Copia de seguridad de la conﬁguración del clúster 78

7 Personalización de la conﬁguración por defecto 80 4 Distribución con DeepSea/Salt

Nota: ceph-deploy se ha eliminado en SUSE Enterprise Storage 5 La herramienta de distribución de clúster ceph-deploy quedó obsoleta en SUSE Enterprise Storage 4 y se ha eliminado por completo para sustituirse por DeepSea a partir de SUSE Enterprise Storage 5.

La combinación de Salt y DeepSea es una pila de componentes que ayudan a distribuir y gestionar la infraestructura de servidor. Tiene mucha capacidad de ampliación, es rápida y es relativamente fácil de poner en ejecución. Lea las consideraciones siguientes antes de empezar a distribuir el clúster con Salt:

Los minions de Salt son los nodos que se controlan mediante un nodo dedicado denominado master de Salt. Los minions de Salt tienen funciones, por ejemplo Ceph OSD, Ceph Monitor, Ceph Manager, Object Gateway, iSCSI Gateway o NFS Ganesha.

Un master de Salt ejecuta su propio minion de Salt. Esto es necesario para ejecutar tareas con privilegios, como la creación, autorización y copia de claves en minions, de forma que los minions remotos nunca tengan que ejecutar tareas con privilegios.

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, servidor de metadatos o Ceph Monitor al master de Salt.

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 especicar cualquier otro nombre de host al que se pueda acceder por la red en el archivo /etc/salt/minion , consulte la Sección 4.3, “Distribución del clúster”.

26 SES 5 4.1 Lectura de las notas de la versión

En las notas de la versión puede encontrar información adicional sobre los cambios realizados desde la versión previa de SUSE Enterprise Storage. Consulte las notas de versión para comprobar lo siguiente:

si el hardware necesita consideraciones especiales,

si los paquetes de software usados han cambiado de forma signicativa,

si es necesario tomar precauciones especiales para la instalación.

Las notas de la versión también proporcionan información que no pudo publicarse en el manual a tiempo y notas acerca de problemas conocidos. Después de instalar el paquete release-notes-ses , encontrará las notas de la versión en el directorio /usr/share/doc/release-notes o en línea en https://www.suse.com/ releasenotes/ .

4.2 Introducción a DeepSea

El objetivo de DeepSea es ahorrar tiempo al administrador y llevar a cabo operaciones complejas en un clúster de Ceph con toda conanza. Ceph es una solución de software muy congurable. Aumenta tanto la libertad como la responsabilidad de los administradores del sistema. La conguración mínima de Ceph es adecuada con propósitos de demostración, pero no muestra las funciones más útiles de Ceph que se pueden disfrutar si hay un gran número de nodos. DeepSea recopila y almacena datos acerca de servidores individuales, como las direcciones y los nombres de dispositivo. Para un sistema de almacenamiento distribuido como Ceph, puede haber cientos de esos elementos para recopilar y almacenar. Recopilar la información e introducir los datos manualmente en una herramienta de gestión de conguraciones es una labor tremendamente laboriosa y propensa a errores. Los pasos necesarios para preparar los servidores, recopilar la conguración y congurar y distribuir Ceph son prácticamente los mismos. Sin embargo, eso no soluciona la gestión de funciones independientes. En las operaciones del día a día, es fundamental contar con la capacidad de añadir hardware fácilmente a una función determinada y eliminarlo sin problemas.

27 Lectura de las notas de la versión SES 5 DeepSea resuelve este asunto con la estrategia siguiente: consolida las decisiones del administrador en un único archivo. Las decisiones incluyen la asignación del clúster, la asignación de la función y la asignación del perl. Y DeepSea recopila cada conjunto de tareas en un único objetivo. Cada objetivo es una fase:

DESCRIPCIÓN DE LAS FASES DE DEEPSEA

Fase 0: la preparación. Durante esta fase se aplican todas las actualizaciones necesarias y puede que el sistema se rearranque.

Importante: vuelva a ejecutar la fase 0 siempre que se rearranque el master de Salt Si durante la fase 0, el master de Salt se rearranca para cargar la nueva versión del kernel, debe volver a ejecutar la fase 0; de lo contrario, no se asignará un destino a los minions.

Fase 1: el descubrimiento. Aquí se detecta todo el hardware del clúster y se recopila la información necesaria para la conguración de Ceph. Para obtener detalles sobre la conguración, consulte la Sección 4.5, “Conﬁguración y personalización”.

Fase 2: la conguración. Debe preparar los datos de la conguración con un formato concreto.

Fase 3: la distribución. Se crea un clúster de Ceph básico con los servicios de Ceph obligatorios. Consulte una lista en la Sección 1.2.3, “Nodos y daemons de Ceph”.

Fase 4: los servicios. Las funciones adicionales de Ceph, como iSCSI Object Gateway y CephFS, se pueden instalar en esta fase. Todos son opcionales.

Fase 5: la etapa de eliminación. Esta fase no es obligatoria y durante la conguración inicial no suele ser necesaria. En esta fase, se eliminan las funciones de los minions y la conguración del clúster. Debe ejecutar esta fase si necesita eliminar un nodo de almacenamiento del clúster. Para obtener información detallada, consulte el Libro “Guía de administración”, Capítulo 1 “Administración de un clúster de Salt”, Sección 1.3 “eliminación y reinstalación de nodos del clúster”.

Encontrará una introducción más detallada sobre DeepSea en https://github.com/suse/deepsea/ wiki .

28 Introducción a DeepSea SES 5 4.2.1 Organización y ubicaciones importantes

Salt tiene algunas ubicaciones estándar y varias convenciones de denominación que se emplean en el nodo máster:

/srv/pillar En este directorio se almacenan datos de conguración para los minions del clúster. Pillar es una interfaz que proporciona valores de conguración globales para todos los minions del clúster.

/srv/salt/ En este directorio se almacenan archivos de estado de Salt (también denominados archivos sls). Los archivos de estado son descripciones con formato de los estados en los que debe estar el clúster. Para obtener más información, consulte la documentación de Salt (https:// docs.saltstack.com/en/latest/topics/tutorials/starting_states.html) .

/srv/module/runners En este directorio se almacenan los guiones Python conocidos como runners. Los runners se ejecutan en el nodo master.

/srv/salt/_modules En este directorio se almacenan los guiones Python denominados módulos. Los módulos se aplican a todos los minions del clúster.

/srv/pillar/ceph Este directorio lo utiliza DeepSea para guardar los datos de conguración recopilados.

/srv/salt/ceph En este directorio usado por DeepSea se almacenan archivos sls que pueden tener distintos formatos. Todos los subdirectorios contienen archivos sls, pero cada subdirectorio contiene solo un tipo de archivo sls. Por ejemplo, /srv/salt/ceph/stage contiene archivos de organización que se ejecutan mediante salt-run state.orchestrate .

4.2.2 Asignación de destino de los minions

Los comandos de DeepSea se ejecutan a través de la infraestructura de Salt. Cuando se utiliza el comando salt , es preciso especicar un conjunto de minions de Salt a los que afectará el comando. El conjunto de minions se describe como un target (destino) para el comando Salt . En las secciones siguientes se describen métodos posibles para asignar el destino de los minions.

29 Organización y ubicaciones importantes SES 5 4.2.2.1 Coincidencia del nombre del minion

Puede asignar destino para un minion o un grupo de minions haciendo coincidir sus nombres. El nombre de un minion suele ser el nombre de host corto del nodo donde se ejecuta el minion. Este método de asignación de destinos es general de Salt y no está relacionado con DeepSea. Es posible usar comodines, expresiones regulares o listas para limitar el rango de los nombres de minion. A continuación se muestra la sintaxis general:

root@master # salt target example.module

Sugerencia: clúster solo de Ceph Si todos los minions de Salt del entorno pertenecen al clúster de Ceph, puede sustituir con seguridad target por '*' para incluir todos los minions registrados.

Para obtener todos los minions del dominio example.net (suponiendo que los nombres de los minions sean idénticos a sus nombres de host "completos"):

root@master # salt '*.example.net' test.ping

Para obtener los minions entre "web1" y "web5":

root@master # salt 'web[1-5]' test.ping

Para obtener los minions "web1 prod" y "web1-devel" con una expresión regular:

root@master # salt -E 'web1-(prod|devel)' test.ping

Para obtener una lista sencilla de minions:

root@master # salt -L 'web1,web2,web3' test.ping

Para obtener todos los minions del clúster:

root@master # salt '*' test.ping

4.2.2.2 Asignación de destino con un grain "deepsea"

En un entorno heterogéneo gestionado mediante Salt donde SUSE Enterprise Storage se distribuya en un subconjunto de nodos junto con otras soluciones de clúster, es buena idea "marcar" los minions relevantes aplicándoles un grain "deepsea". De este modo, puede asignar fácilmente minions de DeepSea en entornos donde sea difícil obtener los nombres de los minions haciéndolos coincidir.

30 Asignación de destino de los minions SES 5 Para aplicar el grain "deepsea" a un grupo de minions, ejecute:

root@master # salt target grains.append deepsea default

Para eliminar el grain "deepsea" de un grupo de minions, ejecute:

root@master # salt target grains.delval deepsea destructive=True

Después de aplicar el grain "deepsea" a los minions relevantes, puede asignarlos como destino de la siguiente forma:

root@master # salt -G 'deepsea:*' test.ping

El comando siguiente es equivalente:

root@master # salt -C 'G@deepsea:*' test.ping

4.2.2.3 Deﬁnición de la opción deepsea_minions

En las distribuciones de DeepSea, es obligatorio denir el destino de la opción deepsea_minions . DeepSea lo usa para dar instrucciones a los minions durante la ejecución de las fases (consulte Descripción de las fases de DeepSea para obtener más información). Para denir o cambiar la opción deepsea_minions , edite el archivo /srv/pillar/ceph/ deepsea_minions.sls en el master de Salt y añada o sustituya la línea siguiente:

deepsea_minions: target

Sugerencia: destino deepsea_minions Como target (destino) para la opción deepsea_minions , puede utilizar cualquier método: tanto Coincidencia del nombre del minion como Asignación de destino con un grain "deepsea". Para obtener todos los minions de Salt del clúster:

deepsea_minions: '*'

Para obtener todos los minions con el grain "deepsea":

deepsea_minions: 'G@deepsea:*'

31 Asignación de destino de los minions SES 5 4.2.2.4 Información adicional

Puede utilizar métodos más avanzados para asignar destinos a los minions con la infraestructura de Salt. Consulte https://docs.saltstack.com/en/latest/topics/targeting/ para obtener una descripción de todas las técnicas de asignación de destinos. Asimismo, la página man "deepsea minions" ofrece más detalles sobre la asignación de destinos de DeepSea ( man 7 deepsea_minions ).

4.3 Distribución del clúster

El proceso de distribución del clúster tiene varias fases. En primer lugar, debe preparar todos los nodos del clúster congurando Salt y, a continuación, distribuir y congurar Ceph.

Sugerencia: distribución de nodos de monitor sin deﬁnir perﬁles de OSD Si necesita omitir la denición de perles de OSD y distribuir primero los nodos de monitor, puede hacerlo deniendo la variable DEV_ENV . De esta forma puede distribuir monitores sin la presencia del directorio profile/ , además de distribuir un clúster con al menos un nodo de almacenamiento, monitor y gestión. Para denir la variable de entorno, puede habilitarla globalmente deniéndola en el archivo /srv/pillar/ceph/stack/global.yml , o bien denirla solo para la sesión actual de shell:

root@master # export DEV_ENV=true

El siguiente procedimiento describe los detalles para preparar el clúster.

1. Instale y registre SUSE Linux Enterprise Server 12 SP3 junto con la extensión SUSE Enterprise Storage en cada nodo del clúster.

2. Verique que los productos adecuados están instalados y registrados mostrando los repositorios de software existentes. La lista será similar a esta:

32 Distribución del clúster SES 5 4 | [...] | SUSE-Enterprise-Storage-5-Pool | Yes | (r ) Yes | No 6 | [...] | SUSE-Enterprise-Storage-5-Updates | Yes | (r ) Yes | Yes 9 | [...] | SLES12-SP3-Pool | Yes | (r ) Yes | No 11 | [...] | SLES12-SP3-Updates | Yes | (r ) Yes | Yes

3. Congure los ajustes de red, incluida la resolución de nombre DNS adecuada en cada nodo. El master de Salt y todos los minions de Salt deben resolverse entre sí mediante sus nombres de host. Para obtener más información acerca de cómo congurar una red, consulte https://www.suse.com/documentation/sles-12/ book_sle_admin/data/sec_basicnet_yast.html . Para obtener más información sobre cómo congurar un servidor DNS, consulte https://www.suse.com/documentation/sles-12/ book_sle_admin/data/cha_dns.html .

4. Congure, habilite e inicie el servidor de sincronización horaria NTP:

root@master # systemctl enable ntpd.service root@master # systemctl start ntpd.service

Encontrará más información sobre la conguración de NTP en https://www.suse.com/ documentation/sles-12/book_sle_admin/data/sec_netz_xntp_yast.html .

5. Compruebe si se está ejecutando el servicio AppArmor e inhabilítelo en todos los nodos del clúster. Inicie el módulo AppArmor de YaST, seleccione Settings (Conguración) y desactive la casilla de vericación Enable Apparmor (Habilitar Apparmor). Conrme haciendo clic en Done (Terminado). Tenga en cuenta que SUSE Enterprise Storage no funcionará si AppArmor está habilitado.

6. Instale los paquetes salt-master y salt-minion en el nodo master de Salt:

root@master # zypper in salt-master salt-minion

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

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

33 Distribución del clúster SES 5 Aviso: las fases de DeepSea fallan con un cortafuegos Las fases de distribución de DeepSea fallan si el cortafuegos está activo (e incluso solo si está congurado). Para superar las fases correctamente, debe desactivar el cortafuegos ejecutando

root@master # systemctl stop SuSEfirewall2.service

o denir el valor "False" (Falso) en la opción FAIL_ON_WARNING en /srv/pillar/ ceph/stack/global.yml :

FAIL_ON_WARNING: False

8. Instale el paquete salt-minion en todos los nodos minion.

root@minion > zypper in salt-minion

Asegúrese de que el nombre completo de todos los demás nodos pueden resolver el nombre de cada nodo en la dirección IP pública.

9. Congure todos los minions (incluido el minion master) para que se conecten con el principal. Si el nombre de host 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 realiza cambios en los archivos de conguración mencionados anteriormente, reinicie el servicio Salt en todos los minions de Salt:

root@minion > systemctl restart salt-minion.service

10. Compruebe que el servicio salt-minion está habilitado e iniciado en todos los nodos. Habilítelo e inícielo si fuera necesario:

root@minion > systemctl enable salt-minion.service root@minion > systemctl start salt-minion.service

11. Verique la huella digital de cada minion de Salt y acepte todas las claves salt del master de Salt si las huellas coinciden.

34 Distribución del clúster SES 5 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 la huella digital de los minions coinciden, acéptelas:

root@master # salt-key --accept-all

12. Verique que las claves se han aceptado:

root@master # salt-key --list-all

13. Antes de distribuir SUSE Enterprise Storage, asegúrese de que todos los discos que se han utilizado como OSD por los clústeres anteriores están vacíos y sin particiones. Para ello, deberá borrar manualmente la tabla de particiones de todos los discos. No olvide sustituir la "X" con la letra de disco correcta:

a. Detenga todos los procesos que utilicen el disco especíco.

b. Verique si hay montada alguna partición del disco y, de ser así, desmóntela.

c. Si el disco está gestionado mediante LVM, desactive y suprima toda la infraestructura de LVM. Consulte https://www.suse.com/documentation/sles-12/stor_admin/data/ cha_lvm.html para obtener más información.

d. Si el disco es parte de MD RAID, desactive el dispositivo RAID. Consulte https://www.suse.com/documentation/sles-12/stor_admin/data/ part_software_raid.html para obtener más información.

35 Distribución del clúster SES 5 e. Sugerencia: rearranque del servidor Si recibe mensajes de error de tipo "la partición está en uso" o "el kernel no se puede actualizar con la nueva tabla de particiones" durante los pasos siguientes, rearranque el servidor.

Limpie el principio de cada partición:

for partition in /dev/sdX[0-9]* do dd if=/dev/zero of=$partition bs=4096 count=1 oflag=direct done

f. Limpie la tabla de particiones:

sgdisk -Z --clear -g /dev/sdX

g. Limpie las tablas de particiones de copia de seguridad:

size=`blockdev --getsz /dev/sdX` position=$((size/4096 - 33)) dd if=/dev/zero of=/dev/sdX bs=4M count=33 seek=$position oflag=direct

14. Instale DeepSea en el nodo master de Salt:

root@master # zypper in deepsea

15. Compruebe que el archivo /srv/pillar/ceph/master_minion.sls del master de Salt apunta a su master de Salt. Si es posible acceder a su master de Salt a través de otros nombres de host, utilice el adecuado para el clúster de almacenamiento. Si ha utilizado el nombre de host por defecto para el master de Salt (salt) en el dominio ses, el archivo tiene el aspecto siguiente:

master_minion: salt.ses

Ahora, distribuya y congure Ceph. A menos que se especique lo contrario, todos los pasos son obligatorios.

36 Distribución del clúster SES 5 Nota: convenciones de comandos de salt Existen dos maneras posibles de ejecutar salt-run state.orch : una es con stage. , la otra es con el nombre de la fase. Ambas notaciones tienen el mismo efecto y elegir un comando u otro es puramente preferencial.

PROCEDIMIENTO 4.1: EJECUCIÓN DE FASES DE DISTRIBUCIÓN

1. Incluya los minions de Salt que pertenezcan al clúster de Ceph que va a distribuir. Consulte la Sección 4.2.2.1, “Coincidencia del nombre del minion” para obtener más información sobre cómo asignar destinos a los minions.

2. Prepare el clúster. Consulte Descripción de las fases de DeepSea para obtener más información.

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

O bien

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

Nota: ejecución o supervisión de fases mediante la interfaz de línea de comandos de DeepSea Con la interfaz de línea de comandos de DeepSea puede realizar un seguimiento en tiempo real del progreso de la ejecución de las fases, ya sea ejecutando la interfaz en modo de supervisión, o bien ejecutando las fases directamente a través de dicha interfaz. Para obtener información detallada, consulte la Sección 4.4, “Interfaz de línea de comandos de DeepSea”.

3. Opcional: cree subvolúmenes de Btrfs para /var/lib/ceph/ . Este paso solo se debe ejecutar antes de que se hayan ejecutado las fases siguientes de DeepSea. Para migrar los directorios existentes, o para obtener más información, consulte el Libro “Guía de administración”, Capítulo 18 “Consejos y sugerencias”, Sección 18.5 “Subvolumen Btrfs para /var/ lib/ceph”.

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

37 Distribución del clúster SES 5 4. La fase de descubrimiento recopila datos de todos los minions y crea fragmentos de conguración que se almacenan en el directorio /srv/pillar/ceph/proposals . Los datos se almacenan en formato de YAML en archivos *.sls o *.yml.

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

O bien

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

5. Después de que el comando anterior nalice correctamente, cree un archivo policy.cfg en /srv/pillar/ceph/proposals . Para obtener información detallada, consulte la Sección 4.5.1, “El archivo policy.cfg”.

Sugerencia Si necesita cambiar la conguración de red del clúster, edite /srv/ pillar/ceph/stack/ceph/cluster.yml y ajuste las líneas que comienzan con cluster_network: y public_network: .

6. La fase de conguración analiza el archivo policy.cfg y combina los archivos incluidos en su formato nal. El contenido relacionado con el clúster y la función se coloca en / srv/pillar/ceph/cluster , mientras que el contenido especíco de Ceph se guarda en /srv/pillar/ceph/stack/default . Ejecute el comando siguiente para activar la fase de conguración:

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

O bien

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

El paso de conguración puede tardar varios segundos. Cuando nalice el comando, podrá ver los datos de Pillar de los minions especicados (por ejemplo, ceph_minion1 , ceph_minion2 , etc.) ejecutando:

root@master # salt 'ceph_minion*' pillar.items

38 Distribución del clúster SES 5 Nota: sobrescritura de valores por defecto Tan pronto como nalice el comando, puede ver la conguración por defecto y cambiarla para adaptarla a sus necesidades. Para obtener información detallada, consulte el Capítulo 7, Personalización de la conﬁguración por defecto.

7. Ahora se ejecuta la fase de distribución. En esta fase, se valida Pillar y los monitores y los daemons de OSD se inician en los nodos de almacenamiento. Ejecute lo siguiente para iniciar la fase:

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

O bien

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

El comando puede tardar varios minutos. Si se produce un error, debe solucionar el problema y volver a ejecutar las fases anteriores. Cuando el comando se ejecute correctamente, ejecute lo siguiente para comprobar el estado:

root@master # ceph -s

8. El último paso de la distribución del clúster de Ceph es la fase services. Aquí se crea una instancia de cualquiera de los servicios admitidos actualmente: iSCSI Gateway, CephFS, Object Gateway, openATTIC y NFS Ganesha. En esta fase, se crean los repositorios necesarios, los anillos de claves de autorización y los servicios de inicio. Para iniciar la fase, ejecute lo siguiente:

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

O bien

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

Según la conguración, puede que la ejecución del comando tarde varios minutos.

39 Distribución del clúster SES 5 4.4 Interfaz de línea de comandos de DeepSea

DeepSea también proporciona una interfaz de línea de comandos que permite al usuario supervisar o ejecutar fases mientras observa el progreso de la ejecución en tiempo real. Para ver el progreso de la ejecución de una fase, se admiten dos modos:

MODOS DE LA INTERFAZ DE LÍNEA DE COMANDOS DE DEEPSEA

Modo de supervisión: muestra el progreso de la ejecución de una fase de DeepSea activada por el comando salt-run emitido en otra sesión de terminal.

Modo autónomo: ejecuta una fase de DeepSea y proporciona una visualización en tiempo real de los pasos incluidos mientras se ejecutan.

Importante: comandos de la interfaz de línea de comandos de DeepSea Los comandos de la interfaz de línea de comandos de DeepSea solo se pueden ejecutar en el nodo master de Salt con privilegios de usuario root .

4.4.1 Interfaz de línea de comandos de DeepSea: modo de monitor

El monitor de progreso ofrece una visualización detallada en tiempo real de lo que sucede durante la ejecución de las fases. Para ello, usa los comandos salt-run state.orch de otras sesiones de terminal. Debe iniciar el monitor antes de ejecutar cualquier comando salt-run state.orch para que el monitor pueda detectar el inicio de la ejecución de la fase. Si inicia el monitor después de emitir el comando salt-run state.orch , no se mostrará ningún progreso de la ejecución. El modo de monitor se puede iniciar ejecutando el comando siguiente:

root@master # deepsea monitor

Para obtener más información sobre las opciones de línea de comandos disponibles para el comando deepsea monitor , consulte su página man:

root@master # man deepsea-monitor

40 Interfaz de línea de comandos de DeepSea SES 5 4.4.2 Interfaz de línea de comandos de DeepSea: modo autónomo

En el modo autónomo, la interfaz de línea de comandos de DeepSea se puede usar para ejecutar una fase de DeepSea y mostrar su ejecución en tiempo real. El comando para ejecutar una fase de DeepSea desde la interfaz de línea de comandos tiene el formato siguiente:

root@master # deepsea stage run stage-name donde stage-name corresponde a la forma a la que se hace referencia a los archivos de estado de organización de Salt. Por ejemplo, a la fase deploy, que corresponde al directorio situado en /srv/salt/ceph/stage/deploy , se hace referencia como ceph.stage.deploy. Este comando es una alternativa a los comandos basados en Salt para ejecutar las fases de DeepSea (o cualquier archivo de estado de organización de DeepSea). El comando deepsea stage run ceph.stage.0 es equivalente a salt-run state.orch ceph.stage.0 . Para obtener más información sobre las opciones de línea de comandos disponibles aceptadas por el comando deepsea stage run , consulte su página man:

root@master # man deepsea-stage run

41 Interfaz de línea de comandos de DeepSea: modo autónomo SES 5 En la ilustración siguiente se muestra un ejemplo de la interfaz de línea de comandos de DeepSea cuando se ejecuta Stage 2:

FIGURA 4.1: PANTALLA DE PROGRESO DE LA EJECUCIÓN DE FASE EN LA INTERFAZ DE LÍNEA DE COMANDOS DE DEEPSEA

4.4.2.1 Alias de stage run de la interfaz de línea de comandos de DeepSea

Para usuarios avanzados de Salt, también se admite un alias para ejecutar una fase de DeepSea que toma el comando de Salt que se usa para ejecutar una fase; por ejemplo, salt-run state.orch stage-name , como un comando de la interfaz de línea de comandos de DeepSea. Ejemplo:

root@master # deepsea salt-run state.orch stage-name

42 Interfaz de línea de comandos de DeepSea: modo autónomo SES 5 4.5 Conﬁguración y personalización

4.5.1 El archivo policy.cfg

El archivo de conguración /srv/pillar/ceph/proposals/policy.cfg se utiliza para determinar las funciones de los nodos de clúster individuales. Por ejemplo, qué nodo actúa como un OSD o cuál actúa como monitor. Edite policy.cfg para reejar la conguración de clúster que desee. El orden de las secciones es arbitrario, pero el contenido de las líneas incluidas sobrescribe las claves que coincidan con el contenido de las líneas anteriores.

Sugerencia: ejemplos de policy.cfg Encontrará varios ejemplos de archivos de directiva completos en el directorio /usr/ share/doc/packages/deepsea/examples/ .

4.5.1.1 Asignación de clúster

En la sección cluster, se seleccionan los minions para el clúster. Puede seleccionar todos los minions o crear una lista negra o una lista blanca de minions. A continuación, se muestran ejemplos para un clúster denominado ceph. Para incluir todos los minions, añada las líneas siguientes:

cluster-ceph/cluster/*.sls

Para añadir un minion concreto a una lista blanca:

cluster-ceph/cluster/abc.domain.sls

O un grupo de minions (se pueden usar comodines):

cluster-ceph/cluster/mon*.sls

Para añadir minions a una lista negra, defínalos como unassigned :

cluster-unassigned/cluster/client*.sls

43 Conﬁguración y personalización SES 5 4.5.1.2 Asignación de funciones

En esta sección se proporciona información sobre cómo asignar "funciones" a los nodos del clúster. En este contexto, una función es el servicio que debe ejecutar en el nodo, como Ceph Monitor, Object Gateway, iSCSI Gateway u openATTIC. Ninguna función se asigna automáticamente y solo las funciones que se añadan a policy.cfg se distribuirán. La asignación sigue este patrón:

role-ROLE_NAME/PATH/FILES_TO_INCLUDE

Donde los elementos tienen el signicado y los valores siguientes:

ROLE_NAME es uno de los siguientes elementos: "master", "admin", "mon", "mgr", "mds", "igw", "rgw", "ganesha" o "openattic".

PATH es una vía relativa a los archivos .sls o .yml. En el caso de los archivos .sls, normalmente es cluster , mientras que los archivos .yml se encuentran en stack/ default/ceph/minions .

FILES_TO_INCLUDE son los archivos de estado de Salt o los archivos de conguración YAML. Normalmente, son nombres de host de los minions de Salt; por ejemplo, ses5min2.yml . Es posible usar comodines para obtener resultados más especícos.

A continuación se muestra un ejemplo de cada función:

master: el nodo tiene anillos de claves de administración para todos los clústeres de Ceph. Actualmente, solo se admite un único clúster de Ceph. Como la función master es obligatoria, añada siempre una línea similar a la siguiente:

role-master/cluster/master*.sls

admin: el minion dispondrá de un anillo de claves de administración. Debe denir la función de la siguiente forma:

role-admin/cluster/abc*.sls

mon: el minion proporcionará el servicio de supervisión al clúster de Ceph. Esta función requiere las direcciones de los minions asignados. A partir de SUSE Enterprise Storage 5, las direcciones públicas se calculan de forma dinámica y ya no son necesarias en Pillar de Salt.

role-mon/cluster/mon*.sls

44 El archivo policy.cfg SES 5 El ejemplo asigna la función de supervisión a un grupo de minions.

mgr: el daemon de Ceph Manager que recopila toda la información de estado de todo el clúster. Distribúyalo en todos los minions en los que tenga previsto distribuir la función de monitor de Ceph.

role-mgr/cluster/mgr*.sls

mds: el minion proporcionará el servicio de metadatos para admitir CephFS.

role-mds/cluster/mds*.sls

igw: el minion actuará como pasarela iSCSI Gateway. Esta función requiere las direcciones de los minions asignados, así que debe incluir también los archivos del directorio stack :

role-igw/stack/default/ceph/minions/xyz.domain.yml role-igw/cluster/*.sls

rgw: el minion actuará como pasarela Object Gateway:

role-rgw/cluster/rgw*.sls

openattic: el minion actuará como servidor de openATTIC:

role-openattic/cluster/openattic*.sls

Para obtener más información, consulte: Libro “Guía de administración”, Capítulo 15 “openATTIC”.

ganesha: el minion actuará como servidor de NFS Ganesha. La función "ganesha" requiere que la función "rgw" o "mds" esté en el clúster, o de lo contrario fallará la validación en la fase 3. Para instalar correctamente NFS Ganesha, se requiere conguración adicional. Si desea utilizar NFS Ganesha, lea el Capítulo 12, Instalación de NFS Ganesha antes de ejecutar las fases 2 y 4. Sin embargo, es posible instalar NFS Ganesha más adelante. En algunas ocasiones, puede ser útil denir funciones personalizadas para nodos de NFS Ganesha. Para obtener información, consulte: Libro “Guía de administración”, Capítulo 14 “NFS Ganesha: exportación de datos de Ceph a través de NFS”, Sección 14.3 “Funciones personalizadas de NFS Ganesha”.

45 El archivo policy.cfg SES 5 Nota: varias funciones de nodos del clúster Puede asignar varias funciones a un único nodo. Por ejemplo, puede asignar las funciones de servidor de metadatos a los nodos de monitor:

role-mds/cluster/mon[1,2]*.sls

4.5.1.3 Conﬁguración común

La sección de conguración común incluye archivos de conguración generados durante el descubrimiento (fase 1). Estos archivos de conguración almacenan parámetros como fsid o public_network . Para incluir la conguración común de Ceph necesaria, añada las líneas siguientes:

config/stack/default/global.yml config/stack/default/ceph/cluster.yml

4.5.1.4 Asignación de perﬁl

En Ceph, una función de almacenamiento única no sería suciente para describir las numerosas conguraciones de disco disponibles con el mismo hardware. La fase 1 de DeepSea generará una propuesta de perl de almacenamiento por defecto. Esta propuesta será por defecto un perl bluestore e intentará proponer la conguración de mayor rendimiento para la conguración de hardware determinada. Por ejemplo, se preferirán diarios externos a un único disco que contenga objetos y metadatos. El almacenamiento de estado sólido se priorizará sobre los discos rotatorios. Los perles se asignan en policy.cfg , igual que las funciones. La propuesta por defecto se encuentra en el árbol de directorios por defecto del perl. Para incluirlo, añada estas dos líneas a policy.cfg .

profile-default/cluster/*.sls profile-default/stack/default/ceph/minions/*.yml

También puede crear un perl de almacenamiento personalizado a su gusto utilizando el runner de propuestas. Este runner ofrece tres métodos: help, peek y populate. salt-run proposal.help imprime el texto de ayuda del runner sobre los distintos argumentos que acepta.

46 El archivo policy.cfg SES 5 salt-run proposal.peek muestra la propuesta generada según los argumentos pasados. salt-run proposal.populate escribe la propuesta en el subdirectorio /srv/pillar/ceph/ proposals . Pasa name=myprofile para asignar un nombre al perl de almacenamiento. Esto dará como resultado un subdirectorio prole-myprole. Para todos los demás argumentos, consulte el resultado de salt-run proposal.help .

4.5.1.5 Distribución de OSD cifrados

A partir de SUSE Enterprise Storage 5, los OSD se distribuyen por defecto mediante BlueStore, en lugar de mediante FileStore. Aunque BlueStore admite el cifrado, los Ceph OSD se distribuyen sin cifrar por defecto. En él se presupone que tanto los datos como los discos WAL/DB que se van a usar para la distribución de los OSD están limpios y no tienen particiones. Si el disco se ha utilizado anteriormente, bórrelo con el procedimiento descrito en el Paso 13. Para utilizar OSD cifrados para la distribución nueva, use el runner proposal.populate con el argumento encryption=dmcrypt :

root@master # salt-run proposal.populate encryption=dmcrypt

4.5.1.6 Filtrado de elementos

A veces no resulta práctico incluir todos los archivos de un directorio concreto con comodines *.sls. El analizador del archivo policy.cfg comprende los siguientes ltros:

Aviso: técnicas avanzadas En esta sección se describen técnicas de ltrado para usuarios avanzados. Si no se utiliza correctamente, el ltrado puede causar problemas, por ejemplo en caso de cambios de numeración del nodo.

slice=[start:end] Utilice el ltro slice para incluir solo los elementos desde start hasta end-1. Tenga en cuenta que los elementos del directorio indicado se ordenan alfanuméricamente. La línea siguiente incluye del tercer al quinto archivo del subdirectorio role-mon/cluster/ :

role-mon/cluster/*.sls slice[3:6]

47 El archivo policy.cfg SES 5 re=regexp Utilice el ltro de expresión regular para incluir solo los elementos que coincidan con las expresiones indicadas. Por ejemplo:

role-mon/cluster/mon*.sls re=.*1[135]\.subdomainX\.sls$

4.5.1.7 Archivo policy.cfg de ejemplo

A continuación se muestra un ejemplo de un archivo policy.cfg básico:

## Cluster Assignment cluster-ceph/cluster/*.sls 1

## Roles # ADMIN role-master/cluster/examplesesadmin.sls 2 role-admin/cluster/sesclient*.sls 3

# MON role-mon/cluster/ses-example-[123].sls 4

# MGR role-mgr/cluster/ses-example-[123].sls 5

# MDS role-mds/cluster/ses-example-4.sls 6

# IGW role-igw/stack/default/ceph/minions/ses-example-4.yml 7 role-igw/cluster/ses-example-4.sls 8

# RGW role-rgw/cluster/ses-example-4.sls 9

# openATTIC role-openattic/cluster/openattic*.sls 10

# COMMON config/stack/default/global.yml 11 config/stack/default/ceph/cluster.yml 12

## Profiles profile-default/cluster/*.sls 13 profile-default/stack/default/ceph/minions/*.yml 14

48 El archivo policy.cfg SES 5 1 Indica que todos los minions están incluidos en el clúster de Ceph. Si tiene minions que no desea incluir en el clúster de Ceph, utilice:

cluster-unassigned/cluster/*.sls cluster-ceph/cluster/ses-example-*.sls

La primera línea marca todos los minions como no asignados. La segunda línea anula los minions que coinciden con "ses-example-*.sls" y los asigna al clúster de Ceph. 2 El minion denominado "examplesesadmin" tiene la función "master". Por cierto, esto signica que obtendrá las claves de administración para el clúster. 3 Todos los minions que coincidan con "sesclient*" obtendrán también las claves de administración. 4 Todos los minions que coincidan con "ses-example-[123]" (posiblemente tres minions: ses- example-1, ses-example-2 y ses-example-3) se congurarán como nodos MON. 5 Todos los minions que coincidan con "ses-example-[123]" (todos los nodos MON del ejemplo) se congurarán como nodos MGR. 6 El minion "ses-example-4" tendrá la función de servidor de metadatos. 7 Asegúrese de que DeepSea conozca la dirección IP del nodo de IGW. 8 El minion "ses-example-4" tendrá la función de IGW. 9 El minion "ses-example-4" tendrá la función de RGW. 10 Indica que se va a distribuir la interfaz de usuario openATTIC para administrar el clúster de Ceph. Consulte el Libro “Guía de administración”, Capítulo 15 “openATTIC” para obtener más información. 11 Signica que se aceptan los valores por defecto para los parámetros de conguración comunes, como fsid y public_network . 12 Signica que se aceptan los valores por defecto para los parámetros de conguración comunes, como fsid y public_network . 13 Se indica a DeepSea que use el perl de hardware por defecto para cada minion. Elegir el perl de hardware por defecto signica que queremos que todos los discos adicionales (que no sean el disco raíz) sean OSD. 14 Se indica a DeepSea que use el perl de hardware por defecto para cada minion. Elegir el perl de hardware por defecto signica que queremos que todos los discos adicionales (que no sean el disco raíz) sean OSD.

49 El archivo policy.cfg SES 5 4.5.2 Archivo ceph.conf personalizado

Si es necesario establecer valores personalizados en el archivo de conguración ceph.conf , consulte el Libro “Guía de administración”, Capítulo 1 “Administración de un clúster de Salt”, Sección 1.11 “Archivo ceph.conf personalizado” para obtener más detalles.

50 Archivo ceph.conf personalizado SES 5 5 Actualización desde versiones anteriores

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

5.1 Lectura de las notas de la versión

si el hardware necesita consideraciones especiales,

si los paquetes de software usados han cambiado de forma signicativa,

si es necesario tomar precauciones especiales para la instalación.

5.2 Procedimiento de actualización general

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

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

1. Monitores Ceph Monitor

2. Gestores Ceph Manager

3. Daemons Ceph OSD

51 Lectura de las notas de la versión SES 5 4. Servidores de metadatos

5. Pasarelas Object Gateway

6. Pasarelas iSCSI Gateway

7. NFS Ganesha

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

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

Actualización de uno en uno Se recomienda actualizar todos los daemons de un tipo especíco, por ejemplo todos los daemons de monitor o todos los daemons de OSD, uno a uno para asegurarse de que todos tienen la misma versión. También se recomienda actualizar todos los daemons del clúster antes de intentar utilizar las nuevas funciones de una versión. Después de actualizar todos los daemons de un tipo concreto, compruebe su estado. Asegúrese de que cada monitor se ha vuelto a unir al quórum después de que se actualicen todos los monitores:

root # ceph mon stat

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

root # ceph osd stat

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

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

52 Procedimiento de actualización general SES 5 Después de que se complete el comando, la advertencia desaparece. En las instalaciones nuevas de SUSE Enterprise Storage 5, este indicador se dene automáticamente cuando los Ceph Monitor crean el osdmap inicial, por lo que no se necesita acción alguna por parte del usuario nal.

5.3 Cifrado de OSD durante la actualización

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

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

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

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

Para obtener más información sobre cómo personalizar el archivo ceph.conf , consulte el Libro “Guía de administración”, Capítulo 1 “Administración de un clúster de Salt”, Sección 1.11 “Archivo ceph.conf personalizado”.

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

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

3. Verique que el archivo ceph.conf está actualizado en los nodos de OSD pertinentes:

root@minion > cat /etc/ceph/ceph.conf

53 Cifrado de OSD durante la actualización SES 5 4. Edite los archivos *.yml del directorio /srv/pillar/ceph/proposals/profile- default/stack/default/ceph/minions que sean relevantes para los OSD que va a cifrar. Vuelva a comprobar que la vía es la denida en el archivo /srv/pillar/ceph/ proposals/policy.cfg y asegúrese de que modica los archivos *.yml correctos.

Importante: identiﬁcadores de disco largos A la hora de identicar los discos de OSD en los archivos /srv/pillar/ ceph/proposals/profile-default/stack/default/ceph/minions/*.yml , use identicadores de disco largos.

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

ceph: storage: osds: /dev/disk/by-id/scsi-SDELL_PERC_H730_Mini_007027b1065faa972100d34d7aa06d86: format: bluestore encryption: dmcrypt db: /dev/disk/by-id/nvme- INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN wal: /dev/disk/by-id/nvme- INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN /dev/disk/by-id/scsi-SDELL_PERC_H730_Mini_00d146b1065faa972100d34d7aa06d86: format: bluestore encryption: dmcrypt db: /dev/disk/by-id/nvme- INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN wal: /dev/disk/by-id/nvme- INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN

5. Distribuya los nuevos OSD de almacenamiento de bloques con cifrado ejecutando las fases 2 y 3 de DeepSea:

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

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

54 Cifrado de OSD durante la actualización SES 5 5.4 Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la versión 5

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

SUSE Linux Enterprise Server 12 SP2

SUSE Enterprise Storage 4

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

Aviso: puntos que se deben tener en cuenta antes de la actualización

Compruebe si se está ejecutando el servicio AppArmor e inhabilítelo en todos los nodos del clúster. Inicie el módulo AppArmor de YaST, seleccione Settings (Conguración) y desactive la casilla de vericación Enable Apparmor (Habilitar Apparmor). Conrme haciendo clic en Done (Terminado). Tenga en cuenta que SUSE Enterprise Storage no funcionará si AppArmor está habilitado.

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

Para optimizar el proceso de actualización, DeepSea actualiza los nodos en este orden basado en la función que tiene asignada según recomiende Ceph en fases anteriores: Monitor, Manager, OSD, servidores de metadatos, Object Gateway, ISCSI Gateway y NFS Ganesha. Tenga en cuenta que DeepSea no puede impedir que el orden prescrito se infrinja si un nodo ejecuta varios servicios.

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

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

La actualización del clúster puede tardar mucho tiempo, aproximadamente el que se tarda en actualizar un equipo multiplicado por el número de nodos del clúster.

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

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

1. Dena el nuevo orden de clasicación de objetos interno. Para ello, ejecute:

root # ceph osd set sortbitwise

Sugerencia Para vericar que el comando se ha ejecutado correctamente, se recomienda ejecutar:

root # ceph osd dump --format json-pretty | grep sortbitwise "flags": "sortbitwise,recovery_deletes,purged_snapdirs",

2. Con el comando rpm -q deepsea , verique que la versión del paquete de DeepSea en el nodo master de Salt empieza con al menos 0.7 . Por ejemplo:

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

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

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

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

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

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

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

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

Y añada la línea siguiente:

upgrade_init: zypper-dup

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

4. Actualice Pillar:

root@master # salt target saltutil.sync_all

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

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

5. Verique si se ha escrito correctamente en Pillar:

root@master # salt target pillar.get upgrade_init

El resultado del comando debe reejar la entrada que ha añadido.

6. Actualice los minions de Salt:

root@master # salt target state.apply ceph.updates.salt

7. Verique que todos los minions de Salt se han actualizado:

root@master # salt target test.version

8. Incluya los minions de Salt del clúster. Consulte la Sección 4.2.2, “Asignación de destino de los minions” de Procedimiento 4.1, “Ejecución de fases de distribución” para obtener más información.

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

root@master # salt-run state.orch ceph.maintenance.upgrade

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

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

root # systemctl disable apparmor.service systemctl stop apparmor.service

11. Después de la actualización, los gestores Ceph Manager aún no están instalados. Para que el estado del clúster sea el correcto, haga lo siguiente:

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

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

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

58 versión 5 SES 5 b. Ejecute la fase 1 para crear el subdirectorio role-mgr/ :

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

c. Edite el archivo policy.cfg como se describe en la Sección 4.5.1, “El archivo policy.cfg” y añada una función de Ceph Manager a los nodos a los que va a distribuir los monitores Ceph Monitor. Asimismo, puede añadir la función openATTIC a uno de los nodos del clúster. Consulte el Libro “Guía de administración”, Capítulo 15 “openATTIC” para obtener más información.

d. Ejecute la fase 2 para actualizar Pillar:

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

e. DeepSea utiliza ahora un enfoque diferente para generar el archivo de conguración ceph.conf , consulte el Libro “Guía de administración”, Capítulo 1 “Administración de un clúster de Salt”, Sección 1.11 “Archivo ceph.conf personalizado” para obtener más información.

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

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

g. Ejecute la fase 4 para congurar openATTIC correctamente:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

root@master # salt-run status.report

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

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

61 versión 5 SES 5 5.4.1 Migración de OSD a BlueStore

OSD BlueStore es un nuevo procesador nal para los daemons de OSD. Es la opción por defecto desde SUSE Enterprise Storage 5. En comparación con FileStore, que almacena los objetos como archivos en un sistema de archivos XFS, BlueStore puede ofrecer un mayor rendimiento debido a que almacena los objetos directamente en el dispositivo de bloques subyacente. BlueStore también permite otras funciones, como la compresión integrada y la sobrescritura de codicación de borrado, que no están disponibles con FileStore. Especícamente para BlueStore, un OSD dispone de un dispositivo "wal" (Write Ahead Log, registro de escritura predictiva) y un dispositivo "db" (base de datos RocksDB). La base de datos RocksDB almacena los metadatos de un OSD BlueStore. Estos dos dispositivos se encuentran por defecto en el mismo dispositivo que un OSD, pero cualquiera de ellos se puede colocar en un medio más rápido o en uno distinto. En SES5, se admite tanto FileStore como BlueStore y es posible que ambos sistemas coexistan en un mismo clúster. Durante el procedimiento de actualización de SUSE Enterprise Storage, los OSD de FileStore no se convierten automáticamente a BlueStore. Tenga en cuenta que las funciones especícas de BlueStore no estarán disponibles en los OSD que no se hayan migrado a BlueStore. Antes de convertirlos a BlueStore, los OSD deben disponer ya de SUSE Enterprise Storage en ejecución. La conversión es un proceso lento, ya que todos los datos se reescriben dos veces. Aunque el proceso de migración puede tardar mucho tiempo en completarse, no hay ninguna interrupción del clúster y todos los clientes pueden seguir accediendo a él durante ese período. No obstante, el rendimiento será inferior durante la migración. Esto es debido al reequilibrio de la carga y la reposición de datos del clúster. Utilice el procedimiento siguiente para migrar los OSD de FileStore a BlueStore:

Sugerencia: desactivación de las medidas de seguridad Los comandos de Salt necesarios para ejecutar la migración se bloquean por motivos de seguridad. Para desactivar estas medidas de seguridad, ejecute el siguiente comando:

root@master # salt-run disengage.safety

1. Migre los perles de hardware:

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

62 Migración de OSD a BlueStore SES 5 Este servicio migra los perles de hardware que usa actualmente el archivo policy.cfg . Procesa policy.cfg , encuentra cualquier perl de hardware que use la estructura de datos original y lo convierte a la nueva estructura de datos. El resultado es un perl de hardware nuevo denominado "migrated- nombre_original ". También se actualiza policy.cfg . Si la conguración original tenía diarios independientes, la conguración de BlueStore utilizará el mismo dispositivo para los dispositivos "wal" y "db" de ese OSD.

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

Sugerencia: método recomendado Use ceph.migrate.nodes si tiene un gran número de nodos de almacenamiento físicos o casi ningún dato. Si un nodo representa menos de 10 % de su capacidad, ceph.migrate.nodes puede ser ligeramente más rápido que mover todos los datos de esos OSD en paralelo. Si no tiene claro qué método debe utilizar, o si el sitio tiene menos nodos de almacenamiento (por ejemplo, cada nodo tiene más del 10 % de los datos del clúster), seleccione ceph.migrate.osds .

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

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

b. Para migrar todos los OSD de cada nodo en paralelo, ejecute:

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

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

root # ceph osd tree

63 Migración de OSD a BlueStore SES 5 para ver qué OSD tiene periódicamente un peso cero.

Después de la migración a BlueStore, el recuento de objetos seguirá siendo el mismo y el uso de disco será prácticamente igual.

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

SUSE Linux Enterprise Server 12 SP2

SUSE Enterprise Storage 4

Seleccione al master de Salt para el clúster. Si el clúster tiene Calamari distribuido, el nodo de Calamari ya es el master de Salt. Como alternativa, el nodo de administración desde el que se ha ejecutado el comando ceph-deploy se convertirá en el master de Salt. Antes de iniciar el proceso siguiente, debe actualizar el nodo master de Salt a SUSE Linux Enterprise Server 12 SP3 y SUSE Enterprise Storage 5 ejecutando zypper migration (o su método de actualización preferido).

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

PROCEDIMIENTO 5.1: PASOS QUE SE DEBEN APLICAR A TODOS LOS NODOS DEL CLÚSTER (INCLUIDO EL NODO DE CALAMARI)

1. Instale el paquete salt desde SLE-12-SP2/SES4:

root # zypper install salt

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

64 versión 5 SES 5 2. Instale el paquete salt-minion desde SLE-12-SP2/SES4 y habilite e inicie el servicio relacionado:

root # zypper install salt-minion root # systemctl enable salt-minion root # systemctl start salt-minion

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

master: host_name_of_salt_master

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

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

root@minion > systemctl restart salt-minion.service

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

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

65 versión 5 SES 5 http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOL root # zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATES root # zypper ref

PROCEDIMIENTO 5.2: PASOS QUE SE DEBEN APLICAR EN EL NODO MASTER DE SALT

1. Dena el nuevo orden de clasicación de objetos interno. Para ello, ejecute:

root@master # ceph osd set sortbitwise

Sugerencia Para vericar que el comando se ha ejecutado correctamente, se recomienda ejecutar:

root@master # ceph osd dump --format json-pretty | grep sortbitwise "flags": "sortbitwise,recovery_deletes,purged_snapdirs",

2. Actualice el nodo master de Salt a SUSE Linux Enterprise Server 12 SP3 y SUSE Enterprise Storage 5. Para sistemas registrados en el SCC, use zypper migration . Si proporciona manualmente los repositorios de software necesarios, use zypper dup . Después de la actualización, asegúrese de que solo los repositorios de SUSE Linux Enterprise Server 12 SP3 y SUSE Enterprise Storage 5 estén activos (y actualizados) en el nodo master de Salt antes de continuar.

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

root@master # zypper install salt-master root@master # systemctl enable salt-master root@master # systemctl start salt-master

4. Verique que todos los minions de Salt están presentes mostrando sus claves:

root@master # salt-key -L

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

66 versión 5 SES 5 5. Añada todas las claves de los minions de Salt al master de Salt, incluido el master de los minions:

root@master # salt-key -A -y

6. Asegúrese de que se han aceptado todas las claves de los minions de Salt:

root@master # salt-key -L

7. Asegúrese de que el software del nodo master de Salt está actualizado:

root@master # zypper migration

8. Instale el paquete deepsea :

root@master # zypper install deepsea

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

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

root@master # salt-run populate.engulf_existing_cluster

El comando hará lo siguiente:

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

Inspeccionar el clúster de Ceph en ejecución y completar /srv/pillar/ceph/ proposals con un diseño del clúster. Se creará /srv/pillar/ceph/proposals/policy.cfg con funciones que coincidan con todos los servicios de Ceph en ejecución detectados. Consulte este archivo para vericar que todos los nodos de Monitor, OSD, Object Gateway y servidor de metadatos existentes tienen las funciones adecuadas. Los nodos de OSD se importarán en el subdirectorio profile-import/ , por lo que puede examinar los archivos de /srv/pillar/ceph/proposals/profile-import/cluster/ y /srv/ pillar/ceph/proposals/profile-import/stack/default/ceph/minions/ para conrmar que los OSD se han recogido correctamente.

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

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

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

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

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

configuration_init: default-import

Guarde el archivo y siga las instrucciones del Libro “Guía de administración”, Capítulo 1 “Administración de un clúster de Salt”, Sección 1.11 “Archivo ceph.conf personalizado”.

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

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

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

68 versión 5 SES 5 /srv/salt/ceph/rgw/cache/

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

/srv/salt/ceph/mgr/cache/

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

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

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

root@minion > lrbd -o >/tmp/lrbd.conf root@minion > scp /tmp/lrbd.conf admin:/srv/salt/ceph/igw/cache/lrbd.conf

b. En el nodo master de Salt, añada la conguración por defecto de iSCSI Gateway en la conguración de DeepSea:

root@master # mkdir -p /srv/pillar/ceph/stack/ceph/ root@master # echo 'igw_config: default-ui' >> /srv/pillar/ceph/stack/ceph/ cluster.yml root@master # chown salt:salt /srv/pillar/ceph/stack/ceph/cluster.yml

c. Añada las funciones de iSCSI Gateway en policy.cfg y guarde el archivo:

role-igw/stack/default/ceph/minions/ses-1.ses.suse.yml role-igw/cluster/ses-1.ses.suse.sls [...]

13. Ejecute la fase 1 para crear todas las funciones posibles:

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

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

69 versión 5 SES 5 14. Genere los subdirectorios necesarios en /srv/pillar/ceph/stack :

root@master # salt-run push.proposal

15. Verique que hay un clúster gestionado por DeepSea en funcionamiento con las funciones asignadas correctamente:

root@master # salt target pillar.get roles

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

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

root@minion > salt target schedule.delete ceph.heartbeat

17. A partir de este punto, siga el procedimiento que se describe en la Sección 5.4, “Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la versión 5”.

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

SUSE Linux Enterprise Server 12 SP2

SUSE Enterprise Storage 4

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

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

root@minion > sudo systemctl stop chef-client

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

70 versión 5 SES 5 root@minion > sudo systemctl disable chef-client root@minion > sudo systemctl disable crowbar_join root@minion > sudo systemctl disable crowbar_notify_shutdown

2. Para cada nodo de Ceph (incluido el nodo de Calamari), verique que los repositorios de software señalan a los productos SUSE Enterprise Storage 5 y SUSE Linux Enterprise Server 12 SP3. Si todavía hay repositorios que señalen a versiones anteriores del producto, inhabilítelos.

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

root@minion > sudo zypper in salt salt-minion

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

master: full_calamari_hostname

Habilite e inicie el servicio salt-minion :

root@minion > sudo systemctl enable salt-minion root@minion > sudo systemctl start salt-minion

5. En el nodo de Calamari, acepte las claves de los minions de Salt restantes:

root@master # salt-key -L [...] Unaccepted Keys: d52-54-00-16-45-0a.example.com d52-54-00-70-ac-30.example.com [...]

root@master # salt-key -A The following keys are going to be accepted: Unaccepted Keys:

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

71 versión 5 SES 5 d52-54-00-16-45-0a.example.com d52-54-00-70-ac-30.example.com Proceed? [n/Y] y Key for minion d52-54-00-16-45-0a.example.com accepted. Key for minion d52-54-00-70-ac-30.example.com accepted.

6. Si se ha distribuido Ceph en la red pública y no existe ninguna interfaz VLAN, añada una interfaz VLAN en la red pública de Crowbar al nodo de Calamari.

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

8. Instale DeepSea en el master de Salt:

root@master # zypper in deepsea

9. Especique la opción deepsea_minions para incluir el grupo correcto de minions de Salt en fases de distribución. Consulte Sección 4.2.2.3, “Deﬁnición de la opción deepsea_minions” para obtener más información.

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

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

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

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

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

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

En el nodo de Object Gateway, ejecute lo siguiente:

root@minion > rm /etc/systemd/system/[email protected]

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

72 versión 5 SES 5 systemctl reenable [email protected].$hostname

12. Asegúrese de que ceph status funciona cuando se ejecuta desde el master de Salt:

root@master # ceph status cluster a705580c-a7ae-4fae-815c-5cb9c1ded6c2 health HEALTH_OK [...]

13. Importe el clúster existente:

root@master # salt-run populate.engulf_existing_cluster root@master # salt-run state.orch ceph.stage.1 root@master # salt-run push.proposal

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

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

root@minion > lrbd -o > /tmp/lrbd.conf root@minion > scp /tmp/lrbd.conf admin:/srv/salt/ceph/igw/cache/lrbd.conf

b. En el nodo master de Salt, añada la conguración por defecto de iSCSI Gateway en la conguración de DeepSea:

c. Añada las funciones de iSCSI Gateway en policy.cfg y guarde el archivo:

role-igw/stack/default/ceph/minions/ses-1.ses.suse.yml role-igw/cluster/ses-1.ses.suse.sls [...]

15. a. Si ha registrado los sistemas con SUSEConnect y usa el SCC/SMT, no necesita llevar a cabo ninguna otra acción.

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

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

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

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

Y añada la línea siguiente:

upgrade_init: zypper-dup

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

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

root@master # salt target grains.get host d52-54-00-16-45-0a.example.com: d52-54-00-16-45-0a d52-54-00-49-17-2a.example.com: d52-54-00-49-17-2a d52-54-00-76-21-bc.example.com: d52-54-00-76-21-bc d52-54-00-70-ac-30.example.com: d52-54-00-70-ac-30

root@master # salt d52-54-00-16-45-0a.example.com grains.set \ host public.d52-54-00-16-45-0a root@master # salt d52-54-00-49-17-2a.example.com grains.set \ host public.d52-54-00-49-17-2a root@master # salt d52-54-00-76-21-bc.example.com grains.set \ host public.d52-54-00-76-21-bc root@master # salt d52-54-00-70-ac-30.example.com grains.set \ host public.d52-54-00-70-ac-30

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

17. Ejecute la actualización:

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

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

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

75 versión 5 SES 5 18. Ejecute todas las fases de distribución necesarias para hacer que el clúster tenga un estado correcto:

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

19. Para distribuir openATTIC (consulte el Libro “Guía de administración”, Capítulo 15 “openATTIC”), añada una línea role-openattic adecuada (consulte la Sección 4.5.1.2, “Asignación de funciones”) a /srv/pillar/ceph/proposals/policy.cfg y ejecute:

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

20. Durante la actualización, es posible que reciba errores de tipo "Error EINVAL: entity [...] exists but caps do not match" (Error EINVAL: la entidad [...] existe pero las caps no coinciden). Para solucionarlos, consulte la Sección 5.4, “Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la versión 5”.

21. Lleve a cabo la limpieza restante:

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

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

root@master # salt target schedule.delete ceph.heartbeat

Aún hay algunos paquetes innecesarios instalados, principalmente gemas de ruby y relacionados con chef. Su eliminación no es obligatoria, pero puede hacerlo ejecutando zypper rm nombre_paquete .

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

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

SUSE Linux Enterprise Server 12 SP1

SUSE Enterprise Storage 3

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

77 Actualización desde SUSE Enterprise Storage 3 a la versión 5 SES 5 6 Copia de seguridad de la conﬁguración del clúster

Este capítulo explica de qué archivos del nodo de administración se debe realizar una copia de seguridad. En cuanto termine con la distribución o la migración del clúster, cree una copia de seguridad de estos directorios.

6.1 Copia de seguridad de la conﬁguración de Salt

Se puede realizar una copia de seguridad del directorio /etc/salt/ . Contiene los archivos de conguración de Salt, por ejemplo la clave maestra de Salt y las claves de cliente aceptadas. No es estrictamente necesario incluir los archivos de Salt al realizar una copia de seguridad del nodo de administración, pero facilita la posterior redistribución del clúster de Salt. Si no se hace una copia de seguridad de estos archivos, los minions de Salt deben registrarse de nuevo en el nuevo nodo de administración.

Nota: seguridad de la clave privada de master de Salt Asegúrese de que la copia de seguridad de la clave privada del master de Salt se guarda en una ubicación segura. La clave del master de Salt puede emplearse para manipular todos los nodos del clúster.

Después de restaurar el directorio /etc/salt desde una copia de seguridad, reinicie los servicios de Salt:

root@master # systemctl restart salt-master root@master # systemctl restart salt-minion

6.2 Copia de seguridad de la conﬁguración de DeepSea

Todos los archivos requeridos por DeepSea se almacenan en /srv/pillar/ , en /srv/salt/ y en /etc/salt/master.d .

78 Copia de seguridad de la conﬁguración de Salt SES 5 Si necesita volver a distribuir el nodo de administración, instale el paquete de DeepSea en el nodo nuevo y mueva los datos copiados de vuelta a los directorios. DeepSea puede usarse de nuevo sin realizar más cambios. Antes de volver a utilizar DeepSea, asegúrese de que todos los minions de Salt están registrados correctamente en el nodo de administración.

79 Copia de seguridad de la conﬁguración de DeepSea SES 5 7 Personalización de la conﬁguración por defecto

Es posible cambiar la conguración por defecto del clúster generada en la fase 2 (consulte Descripción de las fases de DeepSea). Por ejemplo, quizás sea necesario cambiar los valores de red o el software que se instala en el master de Salt por defecto. Lo primero se puede llevar a cabo modicando la versión actualizada de Pillar después de la fase 2, mientras que lo segundo se realiza normalmente creando un archivo sls personalizado y añadiéndolo a Pillar. Los detalles se describen en las secciones siguientes.

7.1 Uso de archivos de conﬁguración personalizados

En esta sección se muestran varias tareas para las que es necesario añadir o cambiar un archivo sls propio. Normalmente, tal procedimiento se utiliza si es preciso cambiar el proceso de distribución por defecto.

Sugerencia: preﬁjo para los archivos .sls personalizados Los archivos personalizados .sls se encuentran en el mismo subdirectorio que los archivos .sls de DeepSea. Para evitar que se sobrescriban con los que se añadan después a partir del paquete de DeepSea, añada el prejo custom- a su nombre.

7.1.1 Inhabilitación de un paso de la distribución

Si lleva a cabo una tarea especíca fuera del proceso de distribución de DeepSea y, por lo tanto, necesita omitir ese paso, cree un archivo "no operation" siguiendo este ejemplo:

PROCEDIMIENTO 7.1: INHABILITACIÓN DE LA SINCRONIZACIÓN HORARIA

1. Cree /srv/salt/ceph/time/disabled.sls con el contenido siguiente y guárdelo:

disable time setting: test.nop

2. Edite /srv/pillar/ceph/stack/global.yml , añada la línea siguiente y guárdelo:

time_init: disabled

80 Uso de archivos de conﬁguración personalizados SES 5 3. Para vericar, actualice Pillar y ejecute el paso:

root@master # salt target saltutil.pillar_refresh root@master # salt 'admin.ceph' state.apply ceph.time admin.ceph: Name: disable time setting - Function: test.nop - Result: Clean

Summary for admin.ceph ------Succeeded: 1 Failed: 0 ------Total states run: 1

Nota: ID exclusivo El ID de tarea "disable time setting" (inhabilitar valor de hora) puede ser cualquier mensaje único dentro de un archivo sls . Cómo evitar conictos de ID especicando descripciones exclusivas.

7.1.2 Sustitución de un paso de la distribución

Si necesita sustituir el comportamiento por defecto de un paso especíco por otro personalizado, cree un archivo sls personalizado con el contenido de sustitución. Por defecto, /srv/salt/ceph/pool/default.sls crea una imagen rbd denominada "demo". En nuestro ejemplo, no queremos crear esta imagen, ya que necesitamos dos imágenes: "archive1" y "archive2".

PROCEDIMIENTO 7.2: SUSTITUCIÓN DE LA IMAGEN RBD DEMO POR DOS IMÁGENES RBD PERSONALIZADAS

1. Cree /srv/salt/ceph/pool/custom.sls con el contenido siguiente y guárdelo:

wait: module.run: - name: wait.out - kwargs: 'status': "HEALTH_ERR" 1 - fire_event: True

archive1: cmd.run: - name: "rbd -p rbd create archive1 --size=1024" 2

81 Sustitución de un paso de la distribución SES 5 - unless: "rbd -p rbd ls | grep -q archive1$" - fire_event: True

archive2: cmd.run: - name: "rbd -p rbd create archive2 --size=768" - unless: "rbd -p rbd ls | grep -q archive2$" - fire_event: True

1 El módulo wait se pondrá en pausa hasta que el clúster de Ceph no tenga el estado HEALTH_ERR . En las instalaciones nuevas, un clúster de Ceph puede tener este estado hasta que haya un número suciente de OSD disponibles y haya terminado la creación de los repositorios. 2 El comando rbd no es idempotente. Si se vuelve a ejecutar el mismo comando de creación cuando la imagen exista, se producirá un error en el estado de Salt. La declaración unless lo impide.

2. Para llamar al archivo personalizado recién creado en lugar del archivo por defecto, debe editar el archivo /srv/pillar/ceph/stack/ceph/cluster.yml , añadir la línea siguiente y guardarlo:

pool_init: custom

3. Para vericar, actualice Pillar y ejecute el paso:

root@master # salt target saltutil.pillar_refresh root@master # salt 'admin.ceph' state.apply ceph.pool

Nota: autorización La creación de repositorios o imágenes requiere disponer de autorización suciente. El minion admin.ceph dispone de un anillo de claves de administración.

Sugerencia: alternativa Otra opción consiste en cambiar la variable presente en /srv/pillar/ceph/stack/ ceph/roles/master.yml . Mediante este archivo, se reduce la cantidad de datos de Pillar para otros minions.

82 Sustitución de un paso de la distribución SES 5 7.1.3 Modiﬁcación de un paso de la distribución

En ocasiones, puede ser preciso que un paso especíco lleve a cabo algunas tareas adicionales. No se recomienda modicar el archivo de estado relacionado, ya que complicaría una futura actualización. En su lugar, para llevar a cabo las tareas adicionales cree un archivo independiente idéntico al que se describe en la Sección 7.1.2, “Sustitución de un paso de la distribución”. Asigne un nombre descriptivo al nuevo archivo sls . Por ejemplo, si necesita crear dos imágenes rbd además de la imagen demo, asigne al archivo el nombre archive.sls .

PROCEDIMIENTO 7.3: CREACIÓN DE DOS IMÁGENES RBD ADICIONALES

1. Cree /srv/salt/ceph/pool/custom.sls con el contenido siguiente y guárdelo:

include: - .archive - .default

Sugerencia: incluir prioridad En este ejemplo, Salt va a crear las imágenes archive y la imagen demo. El orden no importa en este ejemplo. Para cambiar el orden, invierta las líneas después de la directiva include: . Puede añadir la línea include directamente en archive.sls y, así, se crearán todas las imágenes. No obstante, con independencia de dónde se coloque la línea include, Salt procesa primero los pasos del archivo incluido. Aunque este comportamiento puede anularse con las declaraciones requires y order, al usar un archivo independiente que incluya a los demás se garantiza el orden y se reducen las posibilidades de que haya confusiones.

2. Edite /srv/pillar/ceph/stack/ceph/cluster.yml , añada la línea siguiente y guárdelo:

pool_init: custom

3. Para vericar, actualice Pillar y ejecute el paso:

root@master # salt target saltutil.pillar_refresh root@master # salt 'admin.ceph' state.apply ceph.pool

83 Modiﬁcación de un paso de la distribución SES 5 7.1.4 Modiﬁcación de una etapa de la distribución

Si necesita añadir un paso de distribución completamente independiente, cree tres archivos nuevos: un archivo sls para ejecutar el comando, un archivo de organización y un archivo personalizado que adapte el paso nuevo a los pasos de la distribución original. Por ejemplo, si necesita ejecutar logrotate en todos los minions como parte de la fase de preparación: Cree primero un archivo sls e incluya el comando logrotate .

PROCEDIMIENTO 7.4: EJECUCIÓN DE logrotate EN TODOS LOS MINIONS DE SALT

1. Cree un directorio /srv/salt/ceph/logrotate .

2. Cree /srv/salt/ceph/logrotate/init.sls con el contenido siguiente y guárdelo:

rotate logs: cmd.run: - name: "/usr/sbin/logrotate /etc/logrotate.conf"

3. Verique que el comando funciona en un minion:

root@master # salt 'admin.ceph' state.apply ceph.logrotate

Dado que el archivo de organización debe ejecutarse antes que los demás pasos de preparación, añádalo a la fase 0 Prep:

1. Cree /srv/salt/ceph/stage/prep/logrotate.sls con el contenido siguiente y guárdelo:

logrotate: salt.state: - tgt: '*' - sls: ceph.logrotate

2. Verique que el archivo de organización funciona:

root@master # salt-run state.orch ceph.stage.prep.logrotate

El último archivo es el personalizado, que añade el paso adicional a los pasos originales:

1. Cree /srv/salt/ceph/stage/prep/custom.sls con el contenido siguiente y guárdelo:

include:

84 Modiﬁcación de una etapa de la distribución SES 5 - .logrotate - .master - .minion

2. Sustituya el comportamiento por defecto. Edite /srv/pillar/ceph/stack/global.yml , añada la siguiente línea y guarde el archivo:

stage_prep: custom

3. Compruebe que la fase 0 funciona:

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

Nota: ¿por qué global.yml? Se preere el archivo global.yml en lugar del archivo cluster.yml porque durante la fase prep ningún minion pertenece al clúster de Ceph y este no tiene acceso a ninguno de los valores de cluster.yml .

7.1.5 Inhabilitación de actualizaciones y reinicios durante la fase 0

Durante la fase 0 (consulte Descripción de las fases de DeepSea para obtener más información acerca de las fases de DeepSea) el master y los minions de Salt pueden reiniciarse debido a que los paquetes se actualizan; por ejemplo, kernel , requiere que se reinicie el sistema. Para evitar que los nodos de clúster se actualicen o se reinicien durante la fase 0, edite /srv/pillar/ceph/stack/ceph/cluster.yml y añada la opciones stage_prep_master o stage_prep_minion , según si debe modicar el comportamiento del master de Salt, de todos los minions o de todos los nodos. Ambas opciones aceptan los valores siguientes: default-no-update-no-reboot Impide que el formulario de nodos actualice y reinicie sus paquetes. default-no-update-reboot Impide que los nodos actualicen sus paquetes, pero se permiten los reinicios. default-update-no-reboot Impide que los nodos se reinicien, pero se permite la actualización de sus paquetes.

85 Inhabilitación de actualizaciones y reinicios durante la fase 0 SES 5 default Permite actualizar los paquetes de los nodos y reiniciarlos.

7.2 Modiﬁcación de la conﬁguración descubierta

Después de completada la fase 2, puede ser necesario cambiar la conguración descubierta. Para ver los valores actuales, ejecute:

root@master # salt target pillar.items

El resultado de la conguración por defecto para un único minion es normalmente similar al siguiente:

------available_roles: - admin - mon - storage - mds - igw - rgw - client-cephfs - client-radosgw - client-iscsi - mds-nfs - rgw-nfs - master cluster: ceph cluster_network: 172.16.22.0/24 fsid: e08ec63c-8268-3f04-bcdb-614921e94342 master_minion: admin.ceph mon_host: - 172.16.21.13 - 172.16.21.11 - 172.16.21.12 mon_initial_members: - mon3 - mon1 - mon2

86 Modiﬁcación de la conﬁguración descubierta SES 5 public_address: 172.16.21.11 public_network: 172.16.21.0/24 roles: - admin - mon - mds time_server: admin.ceph time_service: ntp

Los valores mencionados anteriormente están distribuidos en varios archivos de conguración. La estructura de directorio con estos archivos se dene en el directorio /srv/pillar/ceph/ stack/stack.cfg . Normalmente, los archivos siguientes describen el clúster:

/srv/pillar/ceph/stack/global.yml : el archivo afecta a todos los minions del clúster de Salt.

/srv/pillar/ceph/stack/ceph/cluster.yml : el archivo afecta a todos los minions del clúster de Ceph denominado ceph .

/srv/pillar/ceph/stack/ceph/roles/función.yml : afecta a todos los minions que tienen asignada la función especíca en el clúster ceph .

/srv/pillar/ceph/stack/cephminions/ID de minion/yml : afecta a ese minion particular.

Nota: sobrescritura de directorios con los valores por defecto Hay un árbol de directorios paralelo donde se almacena la conguración por defecto en /srv/pillar/ceph/stack/default . No cambie los valores aquí presentes, ya que se sobrescriben.

El procedimiento habitual para cambiar la conguración recopilada es el siguiente:

1. Busque la ubicación del elemento de conguración que debe cambiar. Por ejemplo, si necesita cambiar los valores relacionados con el clúster, como la red del clúster, edite el archivo /srv/pillar/ceph/stack/ceph/cluster.yml .

2. Guarde el archivo.

87 Modiﬁcación de la conﬁguración descubierta SES 5 3. Para vericar los cambios, ejecute:

root@master # salt target saltutil.pillar_refresh

y a continuación:

root@master # salt target pillar.items

88 Modiﬁcación de la conﬁguración descubierta SES 5 III Instalación de servicios adicionales

8 Instalación de servicios para acceder a los datos 90

9 Ceph Object Gateway 91

10 Instalación de iSCSI Gateway 98

11 Instalación de CephFS 115

12 Instalación de NFS Ganesha 121

13 Exportación de CephFS mediante Samba 128 8 Instalación de servicios para acceder a los datos

Después de distribuir el clúster de SUSE Enterprise Storage, puede que deba instalar software adicional para acceder a los datos, por ejemplo Object Gateway o iSCSI Gateway; o también bien puede distribuir un sistema de archivos agrupados en clúster encima del clúster de Ceph. Este capítulo se centra principalmente en la instalación manual. Si dispone de un clúster distribuido mediante Salt, consulte en el Capítulo 4, Distribución con DeepSea/Salt como instalar pasarelas concretas o CephFS.

90 SES 5 9 Ceph Object Gateway

Ceph Object Gateway es una interfaz de almacenamiento de objetos creada en librgw a n de proporcionar aplicaciones con una pasarela RESTful a los clústeres de Ceph. Admite dos interfaces:

Compatible con S3: proporciona la función de almacenamiento de objetos con una interfaz que es compatible con un subconjunto extenso de la API RESTful de Amazon S3.

Compatible con Swift: proporciona la función de almacenamiento de objetos con una interfaz que es compatible con un subconjunto extenso de la API de OpenStack Swift.

El daemon de Object Gateway utiliza un servidor HTTP incrustado (CivetWeb) para interactuar con el clúster de Ceph. Puesto que proporciona interfaces compatible con OpenStack Swift y Amazon S3, Object Gateway tiene su propia de gestión de usuarios. Object Gateway puede almacenar datos en el mismo clúster que se utiliza para almacenar datos de clientes de CephFS o clientes del dispositivo de bloques RADOS. Las API S3 y Swift comparten un espacio de nombre común, de forma que es posible escribir datos con una API y recuperarlos con la otra.

Importante: Object Gateway distribuida por DeepSea Desde SUSE Enterprise Storage 5, Object Gateway se instala como una función de DeepSea; por lo tanto, no es necesario realizar una instalación manual. Para instalar Object Gateway durante la distribución del clúster, consulte la Sección 4.3, “Distribución del clúster”. Para añadir un nodo nuevo con Object Gateway para el clúster, consulte el Libro “Guía de administración”, Capítulo 1 “Administración de un clúster de Salt”, Sección 1.2 “Adición de nuevas funciones a los nodos”.

9.1 Instalación manual de Object Gateway

1. Instale Object Gateway en un nodo que no esté utilizando el puerto 80. Por ejemplo, en un nodo donde se ejecute openATTIC ya se está utilizando el puerto 80. El comando siguiente instala todos los componentes necesarios:

cephadm > sudo zypper ref && sudo zypper in ceph-radosgw

91 Instalación manual de Object Gateway SES 5 2. Si se está ejecutando el servidor Apache de la instancia anterior de Object Gateway, deténgalo e inhabilite el servicio correspondiente:

cephadm > sudo systemctl stop disable apache2.service

3. Edite /etc/ceph/ceph.conf y añada las líneas siguientes:

[client.rgw.gateway_host] rgw frontends = "civetweb port=80"

Sugerencia Si desea congurar Object Gateway/CivetWeb para su uso con el cifrado SSL, modique la línea así:

rgw frontends = civetweb port=7480s ssl_certificate=path_to_certificate.pem

4. Reinicie el servicio de Object Gateway.

cephadm > sudo systemctl restart [email protected]_host

9.1.1 Conﬁguración de Object Gateway

Se requieren varios pasos para congurar una instancia de Object Gateway.

9.1.1.1 Conﬁguración básica

Para congurar una instancia de Ceph Object Gateway se requiere que haya un clúster de almacenamiento de Ceph en ejecución. Ceph Object Gateway es un cliente del clúster de almacenamiento de Ceph y, por lo tanto, requiere lo siguiente:

Un nombre de host para la instancia de la pasarela; por ejemplo, gateway .

Un nombre de usuario del clúster de almacenamiento con un anillo de claves y los permisos adecuados.

Repositorios para almacenar sus datos.

Un directorio de datos para la instancia de la pasarela.

Una entrada de la instancia en el archivo de conguración de Ceph.

92 Conﬁguración de Object Gateway SES 5 Cada instancia debe tener un nombre de usuario y una clave para comunicarse con un clúster de almacenamiento de Ceph. En los pasos siguientes, se utiliza un nodo de monitor para crear un anillo de claves bootstrap y, a continuación, se crea el anillo de claves del usuario de la instancia de Object Gateway según el anillo de claves bootstrap. Después, se crea un nombre de usuario y una clave de cliente. A continuación, se añade la clave al clúster de almacenamiento de Ceph. Por último, se distribuye el anillo de claves al nodo que contiene la instancia de la pasarela.

1. Cree un anillo de claves para la pasarela:

cephadm > sudo ceph-authtool --create-keyring /etc/ceph/ceph.client.rgw.keyring cephadm > sudo chmod +r /etc/ceph/ceph.client.rgw.keyring

2. Genere un nombre de usuario de Ceph Object Gateway y la clave para cada instancia. Por ejemplo, se utilizará el nombre gateway después de client.radosgw :

cephadm > sudo ceph-authtool /etc/ceph/ceph.client.rgw.keyring \ -n client.rgw.gateway --gen-key

3. Añada funciones a la clave:

cephadm > sudo ceph-authtool -n client.rgw.gateway --cap osd 'allow rwx' \ --cap mon 'allow rwx' /etc/ceph/ceph.client.rgw.keyring

4. Después de que haya creado un anillo de claves y la clave para dar acceso a Ceph Object Gateway al clúster de almacenamiento de Ceph, añada la clave al clúster de almacenamiento de Ceph. Por ejemplo:

cephadm > sudo ceph -k /etc/ceph/ceph.client.admin.keyring auth add client.rgw.gateway \ -i /etc/ceph/ceph.client.rgw.keyring

5. Distribuya el anillo de claves al nodo que contiene la instancia de la pasarela:

cephadm > sudo scp /etc/ceph/ceph.client.rgw.keyring ceph@hostname:/home/ceph cephadm > ssh hostname cephadm > sudo mv ceph.client.rgw.keyring /etc/ceph/ceph.client.rgw.keyring

93 Conﬁguración de Object Gateway SES 5 Sugerencia: uso del anillo de claves bootstrap Un método alternativo consiste en crear el anillo de claves bootstrap de Object Gateway y, a continuación, crear el anillo de claves de Object Gateway a partir de aquel:

1. Cree un anillo de claves bootstrap de Object Gateway en uno de los nodos de monitor:

cephadm > sudo ceph \ auth get-or-create client.bootstrap-rgw mon 'allow profile bootstrap-rgw' \ --connect-timeout=25 \ --cluster=ceph \ --name mon. \ --keyring=/var/lib/ceph/mon/ceph-node_host/keyring \ -o /var/lib/ceph/bootstrap-rgw/keyring

2. Cree el directorio /var/lib/ceph/radosgw/ceph-rgw_name para almacenar el anillo de claves bootstrap:

cephadm > sudo mkdir \ /var/lib/ceph/radosgw/ceph-rgw_name

3. Cree un anillo de claves de Object Gateway a partir del anillo de claves bootstrap recién creado:

cephadm > sudo ceph \ auth get-or-create client.rgw.rgw_name osd 'allow rwx' mon 'allow rw' \ --connect-timeout=25 \ --cluster=ceph \ --name client.bootstrap-rgw \ --keyring=/var/lib/ceph/bootstrap-rgw/keyring \ -o /var/lib/ceph/radosgw/ceph-rgw_name/keyring

4. Copie el anillo de claves de Object Gateway en el host de Object Gateway:

cephadm > sudo scp \ /var/lib/ceph/radosgw/ceph-rgw_name/keyring \ rgw_host:/var/lib/ceph/radosgw/ceph-rgw_name/keyring

94 Conﬁguración de Object Gateway SES 5 9.1.1.2 Creación de repositorios (opcional)

Ceph Object Gateway requiere repositorios del clúster de almacenamiento de Ceph para almacenar datos especícos de la pasarela. Si el usuario que ha creado tiene los permisos adecuados, la pasarela creará automáticamente los repositorios. Sin embargo, asegúrese de que ha congurado un número por defecto adecuado de grupos de colocación por cada repositorio presente en el archivo de conguración de Ceph. Los nombres de repositorio tienen la sintaxis: NOMBRE_DE_ZONA.NOMBRE_DE_REPOSITORIO . Cuando congure una pasarela con la región y la zona por defecto, el nombre de la zona por defecto es "default", como en este ejemplo:

.rgw.root default.rgw.control default.rgw.meta default.rgw.log default.rgw.buckets.index default.rgw.buckets.data

Para crear manualmente los repositorios, consulte el Libro “Guía de administración”, Capítulo 7 “Gestión de repositorios de almacenamiento”, Sección 7.2.2 “Creación de repositorios”.

Importante: Object Gateway y repositorios codiﬁcados de borrado Solo el repositorio default.rgw.buckets.data puede tener codicación de borrado. Es preciso replicar todos los demás repositorios; de lo contrario, no será posible acceder a la pasarela.

9.1.1.3 Adición de la conﬁguración de la pasarela a Ceph

Añada la conguración de Ceph Object Gateway al archivo de conguración de Ceph. La conguración de Ceph Object Gateway requiere que identique la instancia de Ceph Object Gateway. A continuación, especique el nombre de host donde ha instalado el daemon de Ceph Object Gateway, un anillo de claves (para usar con cephx) y, opcionalmente, un archivo de registro. Por ejemplo:

[client.rgw.instance-name] host = hostname keyring = /etc/ceph/ceph.client.rgw.keyring

95 Conﬁguración de Object Gateway SES 5 Sugerencia: archivo de registro de Object Gateway Para sustituir el archivo de registro de Object Gateway por defecto, incluya lo siguiente:

log file = /var/log/radosgw/client.rgw.instance-name.log

La sección [client.rgw.*] de la instancia de la pasarela identica esta parte del archivo de conguración de Ceph y sirve para congurar un cliente del clúster de almacenamiento de Ceph donde el tipo de cliente es Ceph Object Gateway (radosgw). Después se incluye el nombre de instancia. Por ejemplo:

[client.rgw.gateway] host = ceph-gateway keyring = /etc/ceph/ceph.client.rgw.keyring

Nota El host debe ser el nombre de host del equipo, excluido el nombre del dominio.

Desactive print continue . Si tiene denido el valor true (verdadero) para este parámetro, pueden producirse problemas con las operaciones PUT:

rgw print continue = false

Para utilizar Ceph Object Gateway con llamadas S3 de subdominio (por ejemplo http:// bucketname.hostname ), debe añadir el nombre DNS de Ceph Object Gateway en la sección [client.rgw.gateway] del archivo de conguración de Ceph:

[client.rgw.gateway] ... rgw dns name = hostname

También debe plantearse la instalación de un servidor DNS como Dnsmasq en los equipos cliente cuando utilice la sintaxis http://bucketname.hostname . El archivo dnsmasq.conf debe incluir los siguientes ajustes:

address=/hostname/host-ip-address listen-address=client-loopback-ip

A continuación, añada la dirección IP client-loopback-ip como primer servidor DNS en los equipos cliente.

96 Conﬁguración de Object Gateway SES 5 9.1.1.4 Creación del directorio de datos

Puede que los guiones de distribución no creen el directorio de datos por defecto de Ceph Object Gateway. Si no se han creado ya, cree directorios de datos para cada instancia de un daemon radosgw. Las variables host del archivo de conguración de Ceph determinan qué host ejecuta cada instancia de un daemon radosgw. El formato típico especica el daemon radosgw, el nombre de clúster y el ID del daemon.

cephadm > sudo mkdir -p /var/lib/ceph/radosgw/cluster-id

Con el ejemplo del valor de ceph.conf descrito anteriormente, debería ejecutarse lo siguiente:

cephadm > sudo mkdir -p /var/lib/ceph/radosgw/ceph-radosgw.gateway

9.1.1.5 Reinicio de los servicios e inicio de la pasarela

Para asegurarse de que todos los componentes vuelven a cargar sus conguraciones, se recomienda reiniciar el servicio del clúster de almacenamiento de Ceph. A continuación, inicie el servicio radosgw . Para obtener más información, consulte la Libro “Guía de administración”, Capítulo 2 “Introducción” y la Libro “Guía de administración”, Capítulo 11 “Ceph Object Gateway”, Sección 11.3 “Funcionamiento del servicio de Object Gateway”. Cuando el servicio esté activo y en ejecución, puede realizar una petición GET anónima para comprobar si la pasarela devuelve una respuesta. Una petición HTTP sencilla del nombre del dominio debe devolver la información siguiente:

anonymous

97 Conﬁguración de Object Gateway SES 5 10 Instalación de iSCSI Gateway iSCSI 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. SUSE Enterprise Storage incluye una utilidad que permite gestionar el almacenamiento de Ceph en diversos clientes, como Microsoft Windows* y VMware* vSphere, mediante el protocolo iSCSI. El acceso iSCSI de múltiples rutas aporta disponibilidad y capacidad de ampliación para estos clientes, mientras que el protocolo iSCSI estandarizado también proporciona una capa adicional de aislamiento de seguridad entre los clientes y el clúster de SUSE Enterprise Storage. La utilidad de conguración se denomina lrbd . Mediante lrbd , los administradores de almacenamiento de Ceph pueden denir volúmenes de provisión ligera, replicados y de alta disponibilidad compatibles con las instantáneas de solo lectura, los clones de lectura y escritura y el cambio de tamaño automático con el dispositivo de bloques RADOS (RBD) de Ceph. Los administradores pueden, a continuación, exportar volúmenes a través de un host de pasarela lrbd único o a través de varios hosts de pasarela que admitan failover de múltiples rutas. Los hosts de Linux, Microsoft Windows y VMware pueden conectarse a los volúmenes mediante el protocolo iSCSI, por lo que están disponibles igual que cualquier otro dispositivo de bloques SCSI. Esto signica que los clientes de SUSE Enterprise Storage pueden ejecutar de forma ecaz un subsistema completo de infraestructura de almacenamiento de bloques en Ceph que proporcione todas las funciones y ventajas de una SAN convencional, lo que permite el crecimiento en el futuro. Este capítulo presenta información detallada para congurar una infraestructura de clúster de Ceph junto con una pasarela iSCSI para que los hosts del cliente puedan utilizar los datos almacenados de forma remota como dispositivos de almacenamiento local mediante el protocolo iSCSI.

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

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

10.1.1 Destino iSCSI de kernel de Linux

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 nal, 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 nal. 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 nal 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 nal RBD especíco que admite el acceso de E/S de múltiples rutas paralelizado a imágenes RBD.

10.1.2 Iniciadores iSCSI

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

10.1.2.1 Linux

El iniciador estándar para la plataforma Linux es open-iscsi . open-iscsi lanza un daemon, iscsid , que el usuario puede utilizar para descubrir destinos iSCSI en cualquier portal, entrar en los destinos y asignar volúmenes iSCSI. iscsid se comunica con la capa intermedia SCSI para crear dispositivos de bloques en el kernel que este, a continuación, puede tratar como cualquier

99 Destino iSCSI de kernel de Linux SES 5 otro dispositivo de bloques SCSI del sistema. El iniciador open-iscsi se puede distribuir junto con la utilidad Device Mapper Multipath ( dm-multipath ) para proporcionar un dispositivo de bloques iSCSI de alta disponibilidad.

10.1.2.2 Microsoft Windows e Hyper-V

El iniciador de iSCSI por defecto para el sistema operativo Microsoft Windows es el iniciador iSCSI de Microsoft. El servicio iSCSI se puede congurar a través de una interfaz gráca de usuario (GUI) y es compatible con E/S de múltiples rutas para la alta disponibilidad.

10.1.2.3 VMware

El iniciador iSCSI por defecto para VMware vSphere y ESX es el iniciador iSCSI de VMware ESX, vmkiscsi . Si está habilitado, puede congurarse desde el cliente de vSphere o a través del comando vmkiscsi-tool . A continuación, puede dar formato a los volúmenes de almacenamiento conectados a través del adaptador de almacenamiento iSCSI de vSphere con VMFS y utilizarlos como cualquier otro dispositivo de almacenamiento de máquina virtual. El iniciador de VMware también es compatible con E/S de múltiples vías para la alta disponibilidad.

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

100 Información general sobre lrbd SES 5 FIGURA 10.1: CLÚSTER DE CEPH CON UNA SOLA INSTANCIA DE ISCSI GATEWAY

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

FIGURA 10.2: CLÚSTER DE CEPH CON VARIAS INSTANCIAS DE ISCSI GATEWAY

101 Información general sobre lrbd SES 5 10.3 Consideraciones de distribución

Una conguración mínima de SUSE Enterprise Storage con lrbd consta de los siguientes componentes:

Un clúster de almacenamiento de Ceph. El clúster de Ceph está formado por un mínimo de cuatro servidores físicos que alojan al menos ocho daemons de almacenamiento de objetos (OSD) cada uno. En una conguración de este tipo, tres nodos de OSD también funcionan como host de monitor (MON).

Un servidor de destino iSCSI con el destino iSCSI LIO en ejecución, congurado mediante lrbd .

Un host de iniciador iSCSI, con open-iscsi (Linux) en ejecución, el iniciador iSCSI de Microsoft (Microsoft Windows) o cualquier otra implementación de iniciador iSCSI compatible.

Una conguración de producción recomendada de SUSE Enterprise Storage con lrbd consta de:

Un clúster de almacenamiento de Ceph. Un clúster de producción de Ceph formado por cualquier número de nodos de OSD (normalmente más de 10), que por lo general ejecutan de 10 a 12 daemons de almacenamiento de objetos (OSD) cada uno, con no menos de tres hosts MON dedicados.

Varios servidores de destino iSCSI en los que se ejecuta el destino iSCSI LIO, congurado mediante lrbd . Para el failover y el equilibrio de carga iSCSI, estos servidores deben ejecutar un kernel que admita el módulo target_core_rbd . Hay disponibles paquetes de actualización en el canal de mantenimiento de SUSE Linux Enterprise Server.

Cualquier número de hosts de iniciador iSCSI, con open-iscsi (Linux) en ejecución, el iniciador iSCSI de Microsoft (Microsoft Windows) o cualquier otra implementación de iniciador iSCSI compatible.

10.4 Instalación y conﬁguración

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

102 Consideraciones de distribución SES 5 10.4.1 Distribución de iSCSI Gateway en un clúster de Ceph

Es posible distribuir iSCSI Gateway durante el proceso de distribución del clúster de Ceph o añadiéndolo a un clúster existente mediante DeepSea. Para incluir iSCSI Gateway durante el proceso de distribución del clúster, consulte la Sección 4.5.1.2, “Asignación de funciones”. Para añadir iSCSI Gateway a un clúster existente, consulte el Libro “Guía de administración”, Capítulo 1 “Administración de un clúster de Salt”, Sección 1.2 “Adición de nuevas funciones a los nodos”.

10.4.2 Creación de imágenes RBD

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 conguració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 especicando el tamaño del volumen en megabytes. Por ejemplo, para crear un volumen de 100 GB denominado testvol en el repositorio denominado iscsi , ejecute:

root # rbd --pool iscsi create --size=102400 testvol

El comando anterior crea un volumen RBD con el formato 2 por defecto.

Nota A partir de SUSE Enterprise Storage 3, el formato de volumen por defecto es el 2 y el formato 1 ha quedado obsoleto. Sin embargo, aún es posible crear volúmenes con el formato obsoleto 1 mediante la opción --image-format 1 .

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

Para exportar imágenes RBD a través de iSCSI, utilice la utilidad lrbd . lrbd permite crear, revisar y modicar la conguración del destino iSCSI, que utiliza un formato JSON.

103 Distribución de iSCSI Gateway en un clúster de Ceph SES 5 Sugerencia: importación de cambios en openATTIC Cualquier cambio realizado en la conguración de iSCSI Gateway mediante el comando lrbd no será visible para DeepSea ni openATTIC. Para importar los cambios manuales, hay que exportar la conguración de iSCSI Gateway a un archivo:

root@minion > lrbd -o /tmp/lrbd.conf

A continuación, copie ese archivo en el master de Salt para que DeepSea y openATTIC puedan verlo:

root@minion > scp /tmp/lrbd.conf ses5master:/srv/salt/ceph/igw/cache/lrbd.conf

Por último, edite /srv/pillar/ceph/stack/global.yml y dena:

igw_config: default-ui

Para editar la conguración, utilice lrbd -e o lrbd --edit . Este comando invocará el editor por defecto, denido por la variable de entorno EDITOR . Puede anular este comportamiento; para ello, dena la opción -E además de la opción -e . A continuación se muestra una conguración de ejemplo para:

dos hosts de iSCSI Gateway denominados iscsi1.example.com y iscsi2.example.com ,

que denen un solo destino iSCSI con el nombre completo iSCSI (IQN) iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol ,

con una sola unidad lógica iSCSI,

con el respaldo de una imagen RBD denominada testvol en el repositorio RADOS rbd ,

y que exporta el destino a través de dos portales denominados "east" y "west":

{ "auth": [ { "target": "iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol", "authentication": "none" } ], "targets": [ {

104 Exportación de imágenes RBD a través de iSCSI SES 5 "target": "iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol", "hosts": [ { "host": "iscsi1.example.com", "portal": "east" }, { "host": "iscsi2.example.com", "portal": "west" } ] } ], "portals": [ { "name": "east", "addresses": [ "192.168.124.104" ] }, { "name": "west", "addresses": [ "192.168.124.105" ] } ], "pools": [ { "pool": "rbd", "gateways": [ { "target": "iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol", "tpg": [ { "image": "testvol" } ] } ] } ] }

Tenga en cuenta que cada vez que haga referencia a un nombre de host de la conguración, ese nombre de host debe coincidir con el resultado del comando uname - n de iSCSI Gateway.

105 Exportación de imágenes RBD a través de iSCSI SES 5 El código JSON editado se almacena en los atributos extendidos (xattrs) de un único objeto RADOS por repositorio. Este objeto está disponible para los hosts de pasarela en los que se ha editado el código JSON, así como en todos los hosts de pasarela conectados al mismo clúster de Ceph. Localmente, en la pasarela lrbd , no se almacena ninguna información de conguración. Para activar la conguración, almacénela en el clúster de Ceph y lleve a cabo una de las acciones siguientes (como usuario root ):

Ejecute el comando lrbd (sin opciones adicionales) en la línea de comandos.

O bien

Reinicie el servicio lrbd con service lrbd restart .

El "servicio" lrbd no activa ningún daemon en segundo plano; simplemente invoca el comando lrbd . Este tipo de servicio se conoce como servicio "único" (one-shot). También debe permitir que lrbd se congure automáticamente al iniciar el sistema. Para ello, ejecute el comando systemctl enable lrbd . La conguración anterior muestra una implementación sencilla de una pasarela. La conguración lrbd puede ser mucho más compleja y potente. El paquete RPM de lrbd incluye un amplio conjunto de ejemplos de conguración que puede consultar en el directorio /usr/share/doc/packages/lrbd/samples después de la instalación. También hay ejemplos disponibles en https://github.com/SUSE/lrbd/tree/master/samples .

10.4.4 Valores opcionales

Los siguientes valores pueden ser útiles en algunos entornos. Para las imágenes, están los atributos uuid , lun , retries , sleep y retry_errors . Los dos primeros, uuid y lun , permiten denir de un modo predeterminado e inamovible del "uuid" o el "lun" de una imagen concreta. Puede especicar cualquiera de esos valores para una imagen. Los atributos retries , sleep y retry_errors afectan a los intentos de asignar una imagen rbd.

"pools": [ { "pool": "rbd", "gateways": [ { "host": "igw1", "tpg": [ {

106 Valores opcionales SES 5 "image": "archive", "uuid": "12345678-abcd-9012-efab-345678901234", "lun": "2", "retries": "3", "sleep": "4", "retry_errors": [ 95 ], [...] } ] } ] } ]

10.4.5 Valores avanzados lrbd puede congurarse con parámetros avanzados que posteriormente se pasan al destino de E/S LIO. Los parámetros se dividen en componentes iSCSI y de almacén de respaldo, que a su vez se pueden especicar en las secciones "targets" y "tpg", respectivamente, en la conguración de lrbd .

Aviso No se recomienda cambiar los valores por defecto de estos parámetros.

"targets": [ { [...] "tpg_default_cmdsn_depth": "64", "tpg_default_erl": "0", "tpg_login_timeout": "10", "tpg_netif_timeout": "2", "tpg_prod_mode_write_protect": "0", } ]

A continuación se muestra una descripción de las opciones: tpg_default_cmdsn_depth Profundidad de CmdSN (número de secuencia de comando) por defecto. Limita la cantidad de peticiones que un iniciador iSCSI puede tener pendientes en cualquier momento.

107 Valores avanzados SES 5 tpg_default_erl Nivel de recuperación de error por defecto. tpg_login_timeout Valor de tiempo límite de entrada a la sesión en segundos. tpg_netif_timeout Tiempo límite de fallo de NIC en segundos. tpg_prod_mode_write_protect Si se establece en 1, se impide que se pueda escribir en los LUN.

"pools": [ { "pool": "rbd", "gateways": [ { "host": "igw1", "tpg": [ { "image": "archive", "backstore_block_size": "512", "backstore_emulate_3pc": "1", "backstore_emulate_caw": "1", "backstore_emulate_dpo": "0", "backstore_emulate_fua_read": "0", "backstore_emulate_fua_write": "1", "backstore_emulate_model_alias": "0", "backstore_emulate_rest_reord": "0", "backstore_emulate_tas": "1", "backstore_emulate_tpu": "0", "backstore_emulate_tpws": "0", "backstore_emulate_ua_intlck_ctrl": "0", "backstore_emulate_write_cache": "0", "backstore_enforce_pr_isids": "1", "backstore_fabric_max_sectors": "8192", "backstore_hw_block_size": "512", "backstore_hw_max_sectors": "8192", "backstore_hw_pi_prot_type": "0", "backstore_hw_queue_depth": "128", "backstore_is_nonrot": "1", "backstore_max_unmap_block_desc_count": "1", "backstore_max_unmap_lba_count": "8192", "backstore_max_write_same_len": "65535", "backstore_optimal_sectors": "8192", "backstore_pi_prot_format": "0",

108 Valores avanzados SES 5 "backstore_pi_prot_type": "0", "backstore_queue_depth": "128", "backstore_unmap_granularity": "8192", "backstore_unmap_granularity_alignment": "4194304" } ] } ] } ]

A continuación se muestra una descripción de las opciones: backstore_block_size Tamaño de bloque del dispositivo subyacente. backstore_emulate_3pc Si se establece en 1, se habilita la opción Third Party Copy (Copia por parte de terceros). backstore_emulate_caw Si se establece en 1, se habilita la opción Compare and Write (Comparar y escribir). backstore_emulate_dpo Si se establece en 1, se activa la opción Disable Page Out (Inhabilitar página saliente). backstore_emulate_fua_read Si se establece en 1, se habilita la lectura de Force Unit Access (Forzar acceso a la unidad). backstore_emulate_fua_write Si se establece en 1, se habilita la escritura de Force Unit Access (Forzar acceso a la unidad). backstore_emulate_model_alias Si se establece en 1, se utiliza el nombre del dispositivo de procesador nal para el alias del modelo. backstore_emulate_rest_reord Si se establece en 0, la opción Queue Algorithm Modier (Modicador de algoritmo de cola) tiene restringido el cambio de orden. backstore_emulate_tas Si se establece en 1, se habilita la opción Task Aborted Status (Estado cancelado de tarea). backstore_emulate_tpu Si se establece en 1, se habilita la opción Thin Provisioning Unmap (Anular asignación de provisión ligera).

109 Valores avanzados SES 5 backstore_emulate_tpws Si se establece en 1, se habilita la opción Thin Provisioning Write Same (Misma escritura en provisión ligera). backstore_emulate_ua_intlck_ctrl Si se establece en 1, se habilita la opción Unit Attention Interlock (Interbloqueo de atención en la unidad). backstore_emulate_write_cache Si se establece en 1, se activa la opción Write Cache Enable (Habilitar caché de escritura). backstore_enforce_pr_isids Si se establece en 1, se fuerzan los ISID de reserva persistente. backstore_fabric_max_sectors Número máximo de sectores que la estructura puede transferir al mismo tiempo. backstore_hw_block_size Tamaño del bloque de hardware en bytes. backstore_hw_max_sectors Número máximo de sectores que el hardware puede transferir al mismo tiempo. backstore_hw_pi_prot_type Si es distinto de cero, la protección de DIF está habilitada en el hardware subyacente. backstore_hw_queue_depth Profundidad de la cola de hardware. backstore_is_nonrot Si se establece en 1, el almacén de respaldo es un dispositivo sin rotación. backstore_max_unmap_block_desc_count Número máximo de descriptores de bloque para UNMAP. backstore_max_unmap_lba_count: Número máximo de LBA para UNMAP. backstore_max_write_same_len Longitud máxima de WRITE_SAME. backstore_optimal_sectors Tamaño de la petición óptima en sectores.

110 Valores avanzados SES 5 backstore_pi_prot_format Formato de la protección DIF. backstore_pi_prot_type Tipo de garantía de DIF. backstore_queue_depth Profundidad de la cola. backstore_unmap_granularity Granularidad de UNMAP. backstore_unmap_granularity_alignment Alineación de la granularidad de UNMAP.

Para los destinos, los atributos de tpg permiten ajustar los parámetros del kernel. Utilice esta opción con precaución.

"targets": [ { "host": "igw1", "target": "iqn.2003-01.org.linux-iscsi.generic.x86:sn.abcdefghijk", "tpg_default_cmdsn_depth": "64", "tpg_default_erl": "0", "tpg_login_timeout": "10", "tpg_netif_timeout": "2", "tpg_prod_mode_write_protect": "0", "tpg_t10_pi": "0" }

Sugerencia Si un sitio necesita LUN asignados de forma estática, asigne números a cada LUN.

10.5 Exportación de imágenes del dispositivo de bloques RADOS mediante tcmu-runner

A partir de la versión 5, SUSE Enterprise Storage incluye un procesador nal RBD de espacio de usuario para tcmu-runner (consulte la página man 8 tcmu-runner para obtener más información).

111 Exportación de imágenes del dispositivo de bloques RADOS mediante tcmu-runner SES 5 Aviso: tecnología en fase preliminar Las distribuciones de iSCSI Gateway basadas en tcmu-runner son actualmente una tecnología en fase preliminar. Consulte el Capítulo 10, Instalación de iSCSI Gateway para obtener instrucciones sobre la distribución de iSCSI Gateway basada en kernel con lrbd .

A diferencia de las distribuciones de iSCSI Gateway lrbd basadas en kernel, las basadas en tcmu-runner no ofrecen compatibilidad con E/S de múltiples rutas ni con las reservas persistentes SCSI. Dado que ni DeepSea ni openATTIC admiten actualmente distribuciones tcmu-runner , debe gestionar la instalación, la distribución y la supervisión de forma manual.

10.5.1 Instalación

En el nodo de iSCSI Gateway, instale el paquete tcmu-runner-handler-rbd desde los medios de SUSE Enterprise Storage 5, junto con las dependencias de los paquetes libtcmu1 y tcmu- runner . Instale el paquete targetcli-fb por motivos de conguración. Tenga en cuenta que el paquete targetcli-fb no es compatible con la versión "no fb" del paquete targetcli . Conrme que el servicio tcmu-runner de systemd está ejecutándose:

root # systemctl enable tcmu-runner tcmu-gw:~ # systemctl status tcmu-runner ● tcmu-runner.service - LIO Userspace-passthrough daemon Loaded: loaded (/usr/lib/systemd/system/tcmu-runner.service; static; vendor preset: disabled) Active: active (running) since ...

10.5.2 Conﬁguración y distribución

Cree una imagen del dispositivo de bloques RADOS en su clúster de Ceph existente. En el siguiente ejemplo, se utilizará una imagen 10G denominada "tcmu-lu" situada en el repositorio "rbd". Después de crear la imagen del dispositivo de bloques RADOS, ejecute targetcli y asegúrese de que el gestor RBD tcmu-runner (un complemento) esté disponible:

root # targetcli targetcli shell version 2.1.fb46

/> ls o- / ...... [...] o- backstores ...... [...] ... | o- user:rbd ...... [Storage Objects: 0]

Cree una entrada de conguración en el almacén de respaldo para la imagen RBD:

/> cd backstores/user:rbd /backstores/user:rbd> create tcmu-lu 10G /rbd/tcmu-lu Created user-backed storage object tcmu-lu size 10737418240.

Cree una entrada de conguración de transporte de iSCSI. En el siguiente ejemplo, targetcli genera automáticamente el IQN de destino "iqn.2003-01.org.linux-iscsi.tcmu- gw.x8664:sn.cb3d2a3a" para su uso como identicador de destino iSCSI exclusivo:

/backstores/user:rbd> cd /iscsi /iscsi> create Created target iqn.2003-01.org.linux-iscsi.tcmu-gw.x8664:sn.cb3d2a3a. Created TPG 1. Global pref auto_add_default_portal=true Created default portal listening on all IPs (0.0.0.0), port 3260.

Cree una entrada de ACL para los iniciadores iSCSI que desee conectar al destino. En el ejemplo siguiente, se usa el IQN de iniciador "iqn.1998-01.com.vmware:esxi-872c4888":

/iscsi> cd iqn.2003-01.org.linux-iscsi.tcmu-gw.x8664:sn.cb3d2a3a/tpg1/acls/ /iscsi/iqn.20...a3a/tpg1/acls> create iqn.1998-01.com.vmware:esxi-872c4888

Por último, enlace la conguración del almacén de respaldo RBD creada previamente en el destino iSCSI:

/iscsi/iqn.20...a3a/tpg1/acls> cd ../luns /iscsi/iqn.20...a3a/tpg1/luns> create /backstores/user:rbd/tcmu-lu Created LUN 0. Created LUN 0->0 mapping in node ACL iqn.1998-01.com.vmware:esxi-872c4888

Salga de la shell para guardar la conguración existente:

/iscsi/iqn.20...a3a/tpg1/luns> exit Global pref auto_save_on_exit=true Last 10 configs saved in /etc/target/backup.

113 Conﬁguración y distribución SES 5 Configuration saved to /etc/target/saveconfig.json

10.5.3 Uso

Desde el nodo (cliente) del iniciador iSCSI, conéctese al destino iSCSI recién provisionado utilizando el IQN y el nombre de host que ha congurado anteriormente.

114 Uso SES 5 11 Instalación de CephFS

El sistema de archivos de Ceph (CephFS) es un sistema de archivos conforme con POSIX que utiliza un clúster de almacenamiento de Ceph para almacenar sus datos. CephFS utiliza el mismo sistema de clúster para los dispositivos de bloques de Ceph, el almacenamiento de objetos de Ceph con sus API S3 y Swift o los enlaces nativos ( librados ). Para utilizar CephFS, debe disponer de un clúster de almacenamiento de Ceph en ejecución y al menos un servidor de metadatos de Ceph en ejecución.

11.1 Escenarios admitidos de CephFS y directrices

Con SUSE Enterprise Storage, SUSE incluye compatibilidad ocial con muchos escenarios en los que se utiliza el componente de ampliación horizontal y distribuido CephFS. En esta entrada se describen los límites rígidos y se ofrecen directrices para los casos de uso sugeridos. Una distribución de CephFS compatible debe cumplir estos requisitos:

Un mínimo de un servidor de metadatos. SUSE recomienda distribuir varios nodos con la función de servidor de metadatos. Solo uno estará "activo", mientras el resto estarán "pasivos". No olvide mencionar todos los nodos del servidor de metadatos en el comando mount cuando monte CephFS desde un cliente.

Las instantáneas de CephFS están inhabilitadas (por defecto) y no se admiten en esta versión.

Los clientes se basan en SUSE Linux Enterprise Server 12 SP2 o SP3 y usan el controlador de módulo de kernel cephfs . No se admite el módulo FUSE.

Las cuotas de CephFS no se admiten en SUSE Enterprise Storage, ya que la compatibilidad con las cuotas se implementa únicamente en el cliente de FUSE.

CephFS admite cambios de diseño de archivos, como se describe en http://docs.ceph.com/ docs/jewel/cephfs/ﬁle-layouts/ . Sin embargo, aunque el sistema de archivos se puede montar mediante cualquier cliente, no es posible añadir nuevos repositorios de datos a un sistema de archivos CephFS existente ( ceph mds add_data_pool ). Solo se pueden añadir mientras el sistema de archivos está desmontado.

115 Escenarios admitidos de CephFS y directrices SES 5 11.2 Servidor de metadatos de Ceph

El servidor de metadatos de Ceph (MDS) almacena los metadatos para CephFS. Los dispositivos de bloques de Ceph y el almacenamiento de objetos de Ceph no utilizan un servidor de metadatos. Gracias a los servidores de metadatos, los usuarios del sistema de archivos POSIX pueden ejecutar comandos básicos, como ls o find , sin que ello suponga una carga de trabajo enorme al clúster de almacenamiento de Ceph.

11.2.1 Adición de un servidor de metadatos

Es posible distribuir el servidor de metadatos durante el proceso de distribución inicial del clúster, tal como se describe en la Sección 4.3, “Distribución del clúster”, o añadirlos a un clúster ya distribuido como se describe en el Libro “Guía de administración”, Capítulo 1 “Administración de un clúster de Salt”, Sección 1.1 “Adición de nuevos nodos de clúster”. Después de distribuir el servidor de metadatos, permita el servicio Ceph OSD/MDS en la conguración del cortafuegos del servidor donde se vaya a distribuir dicho servidor: inicie yast , acceda a Seguridad y usuarios Cortafuegos Servicios autorizados y, en el menú desplegable Servicio que se va a autorizar seleccione Ceph OSD/MDS. Si no se permite el tráco completo del nodo del servidor de metadatos de Ceph, el montaje de un sistema de archivos falla, aunque otras operaciones pueden funcionar correctamente.

11.2.2 Conﬁguración de un servidor de metadatos

Puede ajustar con más detalle el comportamiento del servidor de metadatos insertando las opciones relevantes en el archivo de conguración ceph.conf .

TAMAÑO DE CACHÉ DEL SERVIDOR DE METADATOS mds cache memory limit La cantidad máxima de memoria (en bytes) que el servidor de metadatos aplicará para su caché. Los administradores deben utilizar este valor en lugar del antiguo ajuste mds cache size . Por defecto es 1 GB. mds cache reservation

116 Servidor de metadatos de Ceph SES 5 La reserva de caché (memoria o inodos) que debe conservar el caché del servidor de metadatos. Cuando el servidor de metadatos empieza a utilizar su reserva, retendrá temporalmente el estado del cliente hasta que el tamaño de caché se reduzca para restaurar la reserva. El valor por defecto es 0,05.

Para obtener una lista detallada de opciones de conguración relacionadas con el servidor de metadatos, consulte http://docs.ceph.com/docs/master/cephfs/mds-conﬁg-ref/ . Para obtener una lista detallada de opciones de conguración del creador de diarios del servidor de metadatos, consulte http://docs.ceph.com/docs/master/cephfs/journaler/ .

11.3 CephFS

Si dispone de un clúster de almacenamiento de Ceph en buen estado con al menos un servidor de metadatos de Ceph, puede crear y montar el sistema de archivos de Ceph. Asegúrese de que su cliente cuenta con conectividad de red y de un anillo de claves de autenticación adecuado.

11.3.1 Creación de CephFS

CephFS requiere al menos dos repositorios RADOS: uno para datos y otro para metadatos. A la hora de congurar estos repositorios, tenga en cuenta lo siguiente:

Use un nivel de réplica mayor para el repositorio de metadatos, ya que cualquier pérdida de datos en este repositorio puede producir que no sea posible acceder al sistema de archivos completo.

Use un almacenamiento de baja latencia, como discos SSD, para el repositorio de metadatos, ya que así mejorará la latencia observada de las operaciones del sistema de archivos en los clientes.

Los repositorios necesarios se crean automáticamente asignando una entrada role-mds en el archivo policy.cfg . Puede crear manualmente los repositorios cephfs_data y cephfs_metadata para ajustar el rendimiento de forma manual antes de congurar el servidor de metadatos. DeepSea no creará estos repositorios si ya existen. Para obtener más información sobre cómo gestionar repositorios, consulte el Libro “Guía de administración”, Capítulo 7 “Gestión de repositorios de almacenamiento”.

117 CephFS SES 5 Para crear los dos repositorios obligatorios (por ejemplo, "cephfs_data" y "cephfs_metadata") con los valores por defecto para usarlos con CephFS, ejecute los comandos siguientes:

root # ceph osd pool create cephfs_data pg_num root # ceph osd pool create cephfs_metadata pg_num

Es posible utilizar repositorios codicados de borrado en lugar de los repositorios replicados. Se recomienda usar los repositorios codicados de borrado solo si se requiere un rendimiento bajo y acceso aleatorio poco frecuente; por ejemplo, para el almacenamiento en frío, las copias de seguridad y el archivado. En los repositorios codicados de borrado, CephFS requiere que BlueStore esté habilitado y el repositorio debe tener la opción allow_ec_overwrite denida. Esta opción puede denirse ejecutando ceph osd pool set ec_pool allow_ec_overwrites true . La codicación de borrado añade una sobrecarga considerable a las operaciones del sistema de archivos, especialmente en pequeñas actualizaciones. Esta sobrecarga es inherente al uso de la codicación de borrado como mecanismo de tolerancia a fallos. Este problema es un inconveniente necesario si se quiere reducir de forma signicativa la sobrecarga del espacio de almacenamiento. Cuando se crean los repositorios, puede habilitar el sistema de archivos con el comando ceph fs new :

root # ceph fs new fs_name metadata_pool_name data_pool_name

Por ejemplo:

root # ceph fs new cephfs cephfs_metadata cephfs_data

Para comprobar que se ha creado el sistema de archivos, puede mostrar todos los sistemas de archivos CephFS disponibles:

root # ceph fs ls name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]

Cuando se haya creado el sistema de archivos, el servidor de metadatos podrá entrar en un estado activo. Por ejemplo, en un único sistema de servidor de metadatos:

root # ceph mds stat e5: 1/1/1 up

118 Creación de CephFS SES 5 Sugerencia: otros temas Encontrará más información sobre tareas especícas; por ejemplo, el montaje, el desmontaje y la conguración avanzada de CephFS, en el Libro “Guía de administración”, Capítulo 13 “Sistema de archivos con agrupación en clúster”.

11.3.2 Tamaño del clúster del servidor de metadatos

Varios daemons activos de servidor de metadatos pueden dar servicio a una instancia de CephFS. Todos los daemons activos del servidor de metadatos que se asignan a una instancia de CephFS distribuirán el árbol del directorio del sistema de archivos entre sí y, por lo tanto, distribuirán la carga de los clientes simultáneos. Para poder añadir un daemon activo del servidor de metadatos a una instancia de CephFS, se necesita una reserva de repuesto. Es posible iniciar un daemon adicional o utilizar una instancia de reserva existente. El comando siguiente muestra el número actual de daemons del servidor de metadatos activos y pasivos.

root # ceph mds stat

El siguiente comando dene el número de servidores de metadatos activos a dos en una instancia del sistema de archivos.

root # ceph fs set fs_name max_mds 2

Con el n de reducir el tamaño del clúster del servidor de metadatos antes de una actualización, es preciso llevar a cabo dos pasos. Primero, dena max_mds para que solo quede una instancia:

root # ceph fs set fs_name max_mds 1 y, después, desactive de forma explícita los demás daemons activos del servidor de metadatos:

root # ceph mds deactivate fs_name:rank donde rank es el número de un daemon activo del servidor de metadatos de una instancia del sistema de archivos, entre 0 y max_mds -1. Consulte http://docs.ceph.com/docs/luminous/cephfs/ multimds/ para obtener más información.

119 Tamaño del clúster del servidor de metadatos SES 5 11.3.3 Clúster de servidor de metadatos y actualizaciones

Durante las actualizaciones de Ceph, los indicadores de función de una instancia del sistema de archivos pueden cambiar (normalmente, al añadir nuevas funciones). Los daemons incompatibles (por ejemplo, de versiones anteriores) no funcionan con un conjunto de funciones incompatible y no se iniciarán. Esto signica que actualizar y reiniciar un daemon pueden provocar que todos los otros daemons que aún no se han actualizado se detengan y no se puedan iniciar. Por este motivo, se recomienda reducir el clúster activo del servidor de metadatos a una sola instancia y detener todos los daemons en espera antes de actualizar Ceph. Los pasos manuales para este procedimiento de actualización son los siguientes:

1. Actualice los paquetes relacionados con Ceph mediante zypper .

2. Reduzca el tamaño del clúster activo del servidor de metadatos como se describe anteriormente a una sola instancia y detenga todos los daemons en espera del servidor de metadatos con sus unidades systemd en todos los otros nodos:

root # systemctl stop ceph-mds\*.service ceph-mds.target

3. Solo entonces, reinicie el único daemon del servidor de metadatos de los que quedan, de forma que se reinicie con archivo binario actualizado.

root # systemctl restart ceph-mds\*.service ceph-mds.target

4. Reinicie todos los demás daemons del servidor de metadatos y vuelva a denir el valor de max_mds que desee.

root # systemctl start ceph-mds.target

Si utiliza DeepSea, se seguirá este procedimiento en caso de que el paquete ceph se haya actualizado durante las fase de la 0 a la 4. Es posible llevar a cabo este procedimiento mientras los clientes tienen la instancia de CephFS montada y hay operaciones de E/S en curso. Sin embargo, tenga en cuenta que habrá una breve pausa de E/S mientras se reinicie el servidor de metadatos activo. Los clientes se recuperarán automáticamente. Es recomendable reducir la carga de E/S tanto como sea posible antes de actualizar un clúster del servidor de metadatos. Este procedimiento es más rápido en los clústeres del servidor de metadatos inactivos. Por el contrario, en un clúster con mucha carga con varios daemons del servidor de metadatos es fundamental reducir la carga de antemano para evitar que un solo daemon del servidor de metadatos se vea desbordado por operaciones de E/S continuas.

120 Clúster de servidor de metadatos y actualizaciones SES 5 12 Instalación de NFS Ganesha

NFS Ganesha proporciona acceso NFS para Object Gateway o CephFS. En SUSE Enterprise Storage 5, se admiten las versiones 3 y 4 de NFS. NFS Ganesha se ejecuta en el espacio del usuario, en lugar de en el espacio del kernel, e interactúa directamente con Object Gateway o CephFS.

12.1 Preparación

12.1.1 Información general

Para distribuir correctamente NFS Ganesha, debe añadir role-ganesha al archivo /srv/ pillar/ceph/proposals/policy.cfg . Para obtener información, consulte: Sección 4.5.1, “El archivo policy.cfg”. NFS Ganesha también necesita que role-rgw o role-mds estén presentes en policy.cfg . Aunque es posible instalar y ejecutar el servidor de NFS Ganesha en un nodo de Ceph ya existente, se recomienda ejecutarlo en un host dedicado con acceso al clúster de Ceph. Los hosts del cliente por lo general no forman parte del clúster, pero deben tener acceso de red al servidor de NFS Ganesha. Para habilitar el servidor de NFS Ganesha en cualquier momento tras la instalación inicial, añada role-ganesha a policy.cfg y vuelva a ejecutar al menos las fases 2 y 4 de DeepSea. Para obtener información, consulte: Sección 4.3, “Distribución del clúster”. NFS Ganesha se congura mediante el archivo /etc/ganesha/ganesha.conf , presente en el nodo de NFS Ganesha. Sin embargo, este archivo se sobrescribe cada vez que se ejecuta la fase 4 de DeepSea. Por lo tanto, se recomienda editar la plantilla que utiliza Salt, que es el archivo /srv/salt/ceph/ganesha/files/ganesha.conf.j2 del master de Salt. Para obtener información sobre el archivo de conguración, consulte el Libro “Guía de administración”, Capítulo 14 “NFS Ganesha: exportación de datos de Ceph a través de NFS”, Sección 14.2 “Conﬁguración”.

121 Preparación SES 5 12.1.2 Resumen de requisitos

Los siguientes requisitos deben cumplirse antes de ejecutar las fases 2 y 4 de DeepSea a n de instalar NFS Ganesha:

Debe haber al menos un nodo asignado a role-ganesha .

Solo puede denir un role-ganesha por minion.

Para funcionar, NFS Ganesha necesita una instancia de Object Gateway o CephFS.

Si se espera que NFS Ganesha utilice Object Gateway como interfaz con el clúster, se debe completar el archivo /srv/pillar/ceph/rgw.sls en el master de Salt.

12.2 Instalación de ejemplo

Este procedimiento proporciona una instalación de ejemplo que usa tanto Object Gateway como capas de abstracción del sistema de archivos (FSAL) de CephFS de NFS Ganesha.

1. Si aún no lo ha hecho, ejecute las fases 0 y 1 de DeepSea antes de continuar con este procedimiento.

root # salt-run state.orch ceph.stage.0 root # salt-run state.orch ceph.stage.1

2. Después de ejecutar la fase 1 de DeepSea, edite el archivo /srv/pillar/ceph/ proposals/policy.cfg y añada la línea:

role-ganesha/cluster/NODENAME

Sustituya NODENAME con el nombre de un nodo del clúster. Asegúrese también de que hay asignados un role-mds y un role-rgw .

3. Cree el archivo /srv/pillar/ceph/rgw.sls e inserte el contenido siguiente:

rgw_configurations: rgw: users: - { uid: "demo", name: "Demo", email: "[email protected]" } - { uid: "demo1", name: "Demo1", email: "[email protected]" }

122 Resumen de requisitos SES 5 Estos usuarios se crean más adelante como usuarios de Object Gateway y se generan claves de API. En el nodo de Object Gateway, puede ejecutar más tarde radosgw-admin user list para mostrar todos los usuarios creados y radosgw-admin user info --uid=demo para obtener información acerca de usuarios individuales. DeepSea garantiza que Object Gateway y NFS Ganesha reciben las credenciales de todos los usuarios mostrados en la sección rgw del archivo rgw.sls . El NFS exportado utiliza los nombres de usuario en el primer nivel del sistema de archivos; en este ejemplo, las vías /demo y /demo1 se exportarán.

4. Ejecute al menos las fases 2 y 4 de DeepSea. Se recomienda ejecutar la fase 3 en medio.

root # salt-run state.orch ceph.stage.2 root # salt-run state.orch ceph.stage.3 # optional but recommended root # salt-run state.orch ceph.stage.4

5. Verique que NFS Ganesha funciona montando el recurso compartido NFS desde un nodo de cliente:

root # mount -o sync -t nfs GANESHA_NODE:/ /mnt root # ls /mnt cephfs demo demo1

/mnt debe contener todas las vías exportadas. Deben existir directorios para CephFS y para ambos usuarios de Object Gateway. Para cada depósito que posea un usuario, se exportará una vía /mnt/NOMBREUSUARIO/NOMBREDEPÓSITO .

12.3 Conﬁguración activa-pasiva de alta disponibilidad

En esta sección se proporciona un ejemplo de cómo establecer una conguración activa-pasiva de dos nodos de los servidores de NFS Ganesha. El programa de instalación requiere SUSE Linux Enterprise High Availability Extension. Los dos nodos se denominan earth y mars . Para obtener información sobre SUSE Linux Enterprise High Availability Extension, consulte https://www.suse.com/documentation/sle-ha-12/ .

123 Conﬁguración activa-pasiva de alta disponibilidad SES 5 12.3.1 Instalación básica

En esta conguración earth tiene la dirección IP 192.168.1.1 y mars tiene la dirección 192.168.1.2 . Asimismo, se usan dos direcciones IP virtuales otantes que permiten a los clientes conectarse al servicio independientemente del nodo físico en el que se estén ejecutando. 192.168.1.10 se usa para la administración del clúster con Hawk2 y 192.168.2.1 se usa exclusivamente para las exportaciones NFS. De esta forma es más fácil aplicar más tarde restricciones de seguridad. El procedimiento siguiente describe la instalación de ejemplo. Encontrará más información en https://www.suse.com/documentation/sle-ha-12/install-quick/data/install-quick.html .

1. Prepare los nodos de NFS Ganesha en el master de Salt:

a. Ejecute las fases 0 y 1 de DeepSea en el master de Salt.

root@master # salt-run state.orch ceph.stage.0 root@master # salt-run state.orch ceph.stage.1

b. Asigne a los nodos earth y mars la función role-ganesha en el archivo /srv/ pillar/ceph/proposals/policy.cfg :

role-ganesha/cluster/earth*.sls role-ganesha/cluster/mars*.sls

c. Ejecute las fases 3 y 4 de DeepSea en el master de Salt.

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

2. Registre SUSE Linux Enterprise High Availability Extension en earth y mars .

root # SUSEConnect -r ACTIVATION_CODE -e E_MAIL

3. Instalación ha-cluster-bootstrap en ambos nodos:

root # zypper in ha-cluster-bootstrap

4. a. Inicialice el clúster en earth :

root@earth # ha-cluster-init

124 Instalación básica SES 5 b. Deje que mars se una al clúster:

root@mars # ha-cluster-join -c earth

5. Compruebe el estado del clúster. Debería observar que se han añadido dos nodos al clúster:

root@earth # crm status

6. En ambos nodos, inhabilite el inicio automático del servicio NFS Ganesha durante el arranque:

root # systemctl disable nfs-ganesha

7. Inicie la shell crm en earth :

root@earth # crm configure

Los comandos siguientes se ejecutan en la shell crm.

8. En earth , ejecute la shell crm para ejecutar los comandos siguientes a n de congurar el recurso para los daemons de NFS Ganesha como clones de tipo de recurso systemd:

crm(live)configure# primitive nfs-ganesha-server systemd:nfs-ganesha \ op monitor interval=30s crm(live)configure# clone nfs-ganesha-clone nfs-ganesha-server meta interleave=true crm(live)configure# commit crm(live)configure# status 2 nodes configured 2 resources configured

Online: [ earth mars ]

Full list of resources: Clone Set: nfs-ganesha-clone [nfs-ganesha-server] Started: [ earth mars ]

9. Cree una IPAddr2 primitiva con la shell crm:

crm(live)configure# primitive ganesha-ip IPaddr2 \ params ip=192.168.2.1 cidr_netmask=24 nic=eth0 \ op monitor interval=10 timeout=20

crm(live)# status Online: [ earth mars ] Full list of resources:

125 Instalación básica SES 5 Clone Set: nfs-ganesha-clone [nfs-ganesha-server] Started: [ earth mars ] ganesha-ip (ocf::heartbeat:IPaddr2): Started earth

10. Para congurar una relación entre el servidor de NFS Ganesha y la dirección IP virtual otante, utilice la colocación y el orden.

crm(live)configure# colocation ganesha-ip-with-nfs-ganesha-server inf: ganesha-ip nfs-ganesha-clone crm(live)configure# order ganesha-ip-after-nfs-ganesha-server Mandatory: nfs- ganesha-clone ganesha-ip

11. Utilice el comando mount desde el cliente para asegurarse de que la conguración del clúster está completa:

root # mount -t nfs -v -o sync,nfsvers=4 192.168.2.1:/ /mnt

12.3.2 Limpieza de recursos

En caso de que se produzca un fallo en NFS Ganesha en uno de los nodos, por ejemplo en earth , solucione el problema y limpie el recurso. Solo después de que el recurso se haya limpiado, el recurso podrá recuperarse tras el fallo en earth , en caso de que NFS Ganesha falle en mars . Para limpiar el recurso:

root@earth # crm resource cleanup nfs-ganesha-clone earth root@earth # crm resource cleanup ganesha-ip earth

12.3.3 Conﬁguración del recurso de Ping

Puede suceder que el servidor no pueda acceder al cliente debido a un problema de red. Un recurso de ping puede detectar y solucionar este problema. La conguración de este recurso es opcional.

1. Dena el recurso de ping:

crm(live)configure# primitive ganesha-ping ocf:pacemaker:ping \ params name=ping dampen=3s multiplier=100 host_list="CLIENT1 CLIENT2" \ op monitor interval=60 timeout=60 \ op start interval=0 timeout=60 \ op stop interval=0 timeout=60

126 Limpieza de recursos SES 5 host_list es una lista de direcciones IP separadas por caracteres de espacio. Se hará ping a las direcciones IP con regularidad para comprobar si se producen interrupciones de la red. Si un cliente debe tener acceso continuo al servidor de NFS, añádalo a host_list .

2. Cree un clon:

crm(live)configure# clone ganesha-ping-clone ganesha-ping \ meta interleave=true

3. El siguiente comando crea una restricción para el servicio NFS Ganesha. Fuerza al servicio a moverse a otro nodo cuando no sea posible acceder a host_list .

crm(live)configure# location nfs-ganesha-server-with-ganesha-ping nfs-ganesha-clone \ rule -inf: not_defined ping or ping lte 0

12.3.4 Alta disponibilidad de NFS Ganesha y DeepSea

DeepSea no admite la conguración de alta disponibilidad de NFS Ganesha. Para evitar que DeepSea falle después de congurar la alta disponibilidad de NFS Ganesha, excluya el inicio y la detención del servicio NFS Ganesha de la fase 4 de DeepSea:

1. Copie /srv/salt/ceph/ganesha/default.sls en /srv/salt/ceph/ganesha/ha.sls .

2. Elimine la entrada .service de /srv/salt/ceph/ganesha/ha.sls de forma que quede como sigue:

include: - .keyring - .install - .configure

3. Añada la línea siguiente a /srv/pillar/ceph/stack/global.yml :

ganesha_init: ha

12.4 Más información

Encontrará más información en Libro “Guía de administración”, Capítulo 14 “NFS Ganesha: exportación de datos de Ceph a través de NFS”.

127 Alta disponibilidad de NFS Ganesha y DeepSea SES 5 13 Exportación de CephFS mediante Samba

Esta sección describe cómo exportar CephFS mediante un recurso compartido de Samba/CIFS. Los recursos compartidos de Samba se pueden utilizar con clientes de Windows*.

Aviso: tecnología en fase preliminar A partir de SUSE Enterprise Storage 5, la exportación de recursos compartidos de Samba se considera una tecnología en fase preliminar y no se admite.

13.1 Instalación de ejemplo

La exportación de CephFS es una tecnología en fase preliminar y no se admite. Para exportar un recurso compartido de Samba, deberá instalar manualmente Samba en un nodo de clúster y congurarlo. Es posible proporcionar funcionalidad de failover con CTDB y SUSE Linux Enterprise High Availability Extension.

1. Asegúrese de que ya existe una instancia de CephFS en funcionamiento en el clúster. Para obtener información, consulte: Capítulo 11, Instalación de CephFS.

2. Cree un anillo de claves especíco de la pasarela de Samba en el master de Salt y cópielo en el nodo de pasarela de Samba:

root@master # ceph auth get-or-create client.samba.gw mon 'allow r' \ osd 'allow *' mds 'allow *' -o ceph.client.samba.gw.keyring root@master # scp ceph.client.samba.gw.keyring SAMBA_NODE:/etc/ceph/

Sustituya SAMBA_NODE con el nombre del nodo de pasarela de Samba.

3. Los siguientes pasos se ejecutan en el nodo de pasarela de Samba. Instale el daemon de Samba en el nodo de pasarela de Samba:

root # zypper in samba samba-ceph

4. Edite el archivo /etc/samba/smb.conf y añada la sección siguiente:

[SHARE_NAME] path = / vfs objects = ceph ceph:config_file = /etc/ceph/ceph.conf

128 Instalación de ejemplo SES 5 ceph: user_id = samba.gw read only = no

5. Inicie y habilite el daemon de Samba:

root # systemctl start smb.service root # systemctl enable smb.service root # systemctl start nmb.service root # systemctl enable nmb.service

13.2 Conﬁguración de alta disponibilidad

En esta sección se proporciona un ejemplo de cómo establecer una conguración de dos nodos de alta disponibilidad de los servidores de Samba. La conguración requiere SUSE Linux Enterprise High Availability Extension. Los dos nodos se denominan earth ( 192.168.1.1 ) y mars ( 192.168.1.2 ). Para obtener información sobre SUSE Linux Enterprise High Availability Extension, consulte https://www.suse.com/documentation/sle-ha-12/ . Asimismo, dos direcciones IP virtuales otantes permiten a los clientes conectarse al servicio independientemente del nodo físico en el que se estén ejecutando. 192.168.1.10 se usa para la administración del clúster con Hawk2 y 192.168.2.1 se usa exclusivamente para las exportaciones CIFS. De esta forma es más fácil aplicar más tarde restricciones de seguridad. El procedimiento siguiente describe la instalación de ejemplo. Encontrará más información en https://www.suse.com/documentation/sle-ha-12/install-quick/data/install-quick.html .

1. Cree un anillo de claves especíco de la pasarela de Samba en el master de Salt y cópielo en ambos nodos:

root@master # ceph auth get-or-create client.samba.gw mon 'allow r' \ osd 'allow *' mds 'allow *' -o ceph.client.samba.gw.keyring root@master # scp ceph.client.samba.gw.keyring earth:/etc/ceph/ root@master # scp ceph.client.samba.gw.keyring mars:/etc/ceph/

2. Prepare earth y mars para que alojen el servicio de Samba:

a. Asegúrese de que los paquetes siguientes están instalados antes de continuar: ctdb , tdb-tools y samba (se necesitan para los recursos smb y nmb).

root # zypper in ctdb tdb-tools samba samba-ceph

129 Conﬁguración de alta disponibilidad SES 5 b. Asegúrese de que los servicios ctdb , smb y nmb están detenidos e inhabilitados:

root # systemctl disable ctdb root # systemctl disable smb root # systemctl disable nmb root # systemctl stop smb root # systemctl stop nmb

c. Abra el puerto 4379 del cortafuegos en todos los nodos. Esto es necesario para que CTDB pueda comunicarse con los demás nodos del clúster.

d. Cree un directorio para el bloqueo CTDB en el sistema de archivos compartido:

root # mkdir -p /srv/samba/

3. En earth , cree los archivos de conguración de Samba. Más adelante, se sincronizarán automáticamente con mars .

a. En /etc/ctdb/nodes , inserte todos los nodos que contienen todas las direcciones IP privadas de cada nodo del clúster:

192.168.1.1 192.168.1.2

b. Congure Samba. Añada las líneas siguientes en la sección [global] de / etc/samba/smb.conf . Utilice el nombre de host que desee en lugar de "CTDB- SERVER" (en realidad, todos los nodos del clúster aparecerán como un nodo extenso con este nombre):

[global] netbios name = CTDB-SERVER clustering = yes idmap config * : backend = tdb2 passdb backend = tdbsam ctdbd socket = /var/lib/ctdb/ctdb.socket

Para obtener más información sobre csync2 , consulte https://www.suse.com/ documentation/sle-ha-12/singlehtml/book_sleha/ book_sleha.html#pro.ha.installation.setup.csync2.start .

4. Instale y cargue el clúster de SUSE Linux Enterprise High Availability.

a. Registre SUSE Linux Enterprise High Availability Extension en earth y mars .

130 Conﬁguración de alta disponibilidad SES 5 root@earth # SUSEConnect -r ACTIVATION_CODE -e E_MAIL

root@mars # SUSEConnect -r ACTIVATION_CODE -e E_MAIL

b. Instale ha-cluster-bootstrap en ambos nodos:

root@earth # zypper in ha-cluster-bootstrap

root@mars # zypper in ha-cluster-bootstrap

c. Inicialice el clúster en earth :

root@earth # ha-cluster-init

d. Deje que mars se una al clúster:

root@mars # ha-cluster-join -c earth

5. Compruebe el estado del clúster. Debería observar que se han añadido dos nodos en el clúster:

root@earth # crm status 2 nodes configured 1 resource configured

Online: [ earth mars ]

Full list of resources:

admin-ip (ocf::heartbeat:IPaddr2): Started earth

6. Ejecute los comandos siguientes en earth para congurar el recurso CTDB:

root@earth # crm configure crm(live)configure# primitive ctdb ocf:heartbeat:CTDB params \ ctdb_manages_winbind="false" \ ctdb_manages_samba="false" \ ctdb_recovery_lock="!/usr/lib64/ctdb/ctdb_mutex_ceph_rados_helper ceph client.samba.gw cephfs_metadata ctdb-mutex" ctdb_socket="/var/lib/ctdb/ctdb.socket" \ op monitor interval="10" timeout="20" \ op start interval="0" timeout="90" \ op stop interval="0" timeout="100" crm(live)configure# primitive nmb systemd:nmb \ op start timeout="60" interval="0" \

131 Conﬁguración de alta disponibilidad SES 5 op stop timeout="60" interval="0" \ op monitor interval="60" timeout="60" crm(live)configure# primitive smb systemd:smb \ op start timeout="60" interval="0" \ op stop timeout="60" interval="0" \ op monitor interval="60" timeout="60" crm(live)configure# group g-ctdb ctdb nmb smb crm(live)configure# clone cl-ctdb g-ctdb meta interleave="true" crm(live)configure# commit

El archivo binario /usr/lib64/ctdb/ctdb_mutex_ceph_rados_helper de la opción de conguración ctdb_recovery_lock tiene los parámetros CLUSTER_NAME CEPHX_USER CEPH_POOL y CEPHX_USER , en este orden.

7. Añada una dirección IP agrupada en clúster:

crm(live)configure# primitive ip ocf:heartbeat:IPaddr2 params ip=192.168.2.1 \ unique_clone_address="true" \ op monitor interval="60" \ meta resource-stickiness="0" crm(live)configure# clone cl-ip ip \ meta interleave="true" clone-node-max="2" globally-unique="true" crm(live)configure# colocation col-with-ctdb 0: cl-ip cl-ctdb crm(live)configure# order o-with-ctdb 0: cl-ip cl-ctdb crm(live)configure# commit

Si unique_clone_address se dene como true (verdadero), el agente de recurso IPaddr2 añade un ID de clonación a la dirección especicada, lo que da como resultado que haya tres direcciones IP distintas. Normalmente, no son necesarias, pero ayudan a la hora de equilibrar la carga. Para obtener más información sobre este tema, consulte https://www.suse.com/documentation/sle-ha-12/book_sleha/data/cha_ha_lb.html .

8. Compruebe el resultado:

root@earth # crm status Clone Set: base-clone [dlm] Started: [ factory-1 ] Stopped: [ factory-0 ] Clone Set: cl-ctdb [g-ctdb] Started: [ factory-1 ] Started: [ factory-0 ] Clone Set: cl-ip [ip] (unique) ip:0 (ocf:heartbeat:IPaddr2): Started factory-0 ip:1 (ocf:heartbeat:IPaddr2): Started factory-1

132 Conﬁguración de alta disponibilidad SES 5 9. Realice una prueba desde un equipo cliente. En un cliente Linux, ejecute el comando siguiente para comprobar si puede copiar archivos desde el sistema y en el sistema:

root # smbclient //192.168.2.1/myshare

133 Conﬁguración de alta disponibilidad SES 5 A Actualizaciones de la documentación

En este capítulo se describen los cambios del contenido de este documento desde la publicación inicial de SUSE Enterprise Storage 4. Encontrará los cambios relacionados con la distribución del clúster que se aplican a versiones anteriores en https://www.suse.com/documentation/ses-4/ book_storage_admin/data/ap_adm_docupdate.html . El documento se actualizó en las fechas siguientes:

Sección A.1, “Octubre de 2018 (lanzamiento de SUSE Enterprise Storage 5.5)”

Sección A.2, “Noviembre de 2017 (actualización de mantenimiento)”

Sección A.3, “Octubre de 2017 (lanzamiento de SUSE Enterprise Storage 5)”

A.1 Octubre de 2018 (lanzamiento de SUSE Enterprise Storage 5.5)

Actualizaciones generales

Se ha añadido el Capítulo 3, Conﬁguración de alta disponibilidad del nodo de administración de Ceph (Fate n.º 325622).

OSD cifrados durante la distribución y actualización en la Sección 4.5.1.5, “Distribución de OSD cifrados” y la Sección 5.3, “Cifrado de OSD durante la actualización” (Fate n.º 321665).

Solución de errores

Los repositorios no de datos de Object Gateway deben replicarse en la Sección 9.1.1.2, “Creación de repositorios (opcional)” (https://bugzilla.suse.com/ show_bug.cgi?id=1095743 ).

Debe ser posible resolver el nombre de dominio completo de todos los nodos en la red IP pública. Consulte la Sección 4.3, “Distribución del clúster” (https://bugzilla.suse.com/ show_bug.cgi?id=1067113 ).

Se ha añadido una sugerencia sobre cómo compartir varias funciones en el Capítulo 4, Distribución con DeepSea/Salt (https://bugzilla.suse.com/show_bug.cgi?id=1093824 ).

134 Octubre de 2018 (lanzamiento de SUSE Enterprise Storage 5.5) SES 5 Se ha añadido la Sección 2.4, “Nodos del servidor de metadatos” (https:// bugzilla.suse.com/show_bug.cgi?id=1047230 ).

Edición manual de policy.cfg para openATTIC (https://bugzilla.suse.com/ show_bug.cgi?id=1073331 ).

Se recomienda /var/lib/ceph en SSD en la Sección 2.2, “Nodos de monitor” (https:// bugzilla.suse.com/show_bug.cgi?id=1056322 ).

Se han añadido la Sección 1.4, “BlueStore” y la Sección 2.1.3, “Tamaño recomendado para el dispositivo WAL y DB de BlueStore” (https://bugzilla.suse.com/show_bug.cgi? id=1072502 ).

Se ha aplicado la distribución de OSD cifrados en la Sección 4.5.1.5, “Distribución de OSD cifrados” (https://bugzilla.suse.com/show_bug.cgi?id=1093003 ).

Se ha aumentado el número de bytes para borrar a 4 millones en el Paso 13 (https:// bugzilla.suse.com/show_bug.cgi?id=1093331 ).

El cortafuegos interrumpe las fases de DeepSea, en la Sección 4.3, “Distribución del clúster” (https://bugzilla.suse.com/show_bug.cgi?id=1090683 ).

Se ha añadido la lista de repositorios en la Sección 4.3, “Distribución del clúster” (https:// bugzilla.suse.com/show_bug.cgi?id=1088170 ).

Se han añadido instrucciones para añadir manualmente repositorios mediante zypper en la Sección 5.4, “Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la versión 5”, la Sección 5.5, “Actualización desde SUSE Enterprise Storage 4 (distribución de ceph-deploy) a la versión 5” y la Sección 5.6, “Actualización desde SUSE Enterprise Storage 4 (distribución de Crowbar) a la versión 5” (https://bugzilla.suse.com/ show_bug.cgi?id=1073308 ).

Se ha añadido una lista de repositorios de actualización y una explicación breve de la opción upgrade_init de DeepSea en la Sección 5.4, “Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la versión 5” (https://bugzilla.suse.com/ show_bug.cgi?id=1073372 ).

Se ha añadido la Sección 7.1.5, “Inhabilitación de actualizaciones y reinicios durante la fase 0” (https://bugzilla.suse.com/show_bug.cgi?id=1081524 ).

Se han corregido los guiones en el Procedimiento 5.2, “Pasos que se deben aplicar en el nodo master de Salt” (https://bugzilla.suse.com/show_bug.cgi?id=1084307 ).

135 Octubre de 2018 (lanzamiento de SUSE Enterprise Storage 5.5) SES 5 Se ha añadido la Sección 2.12, “SUSE Enterprise Storage y otros productos SUSE” (https:// bugzilla.suse.com/show_bug.cgi?id=1089717 ).

Se ha añadido una nota en las secciones de conguración de Object Gateway en el Libro “Guía de administración”, Capítulo 1 “Administración de un clúster de Salt”, Sección 1.11 “Archivo ceph.conf personalizado” (https://bugzilla.suse.com/ show_bug.cgi?id=1089300 ).

Se han añadido fragmentos sobre WAL/DB en la Sección 2.1.2, “Tamaño mínimo de disco” (https://bugzilla.suse.com/show_bug.cgi?id=1057797 ).

Las direcciones públicas de MON se calculan de forma dinámica (https:// bugzilla.suse.com/show_bug.cgi?id=1089151 ).

Se ha corregido la ubicación de los anillos de claves en la Sección 5.5, “Actualización desde SUSE Enterprise Storage 4 (distribución de ceph-deploy ) a la versión 5” (https:// bugzilla.suse.com/show_bug.cgi?id=1073368 ).

Se proporcionan varios fragmentos sobre el ayudante en la Sección 4.5.1.2, “Asignación de funciones” (https://bugzilla.suse.com/show_bug.cgi?id=1061629 ).

Se ha importado el ceph.conf personalizado en el Procedimiento 5.2, “Pasos que se deben aplicar en el nodo master de Salt” (https://bugzilla.suse.com/show_bug.cgi? id=1085443 ).

Se ha actualizado el valor de RAM recomendado para la distribución de BlueStore en la Sección 2.1.1, “Requisitos mínimos” (https://bugzilla.suse.com/show_bug.cgi? id=1076385) ).

Se han añadido pasos manuales para actualizar las instancias de iSCSI Gateway después de importar el comando en la Sección 5.5, “Actualización desde SUSE Enterprise Storage 4 (distribución de ceph-deploy ) a la versión 5” y la Sección 5.6, “Actualización desde SUSE Enterprise Storage 4 (distribución de Crowbar) a la versión 5” (https:// bugzilla.suse.com/show_bug.cgi?id=1073327) ).

Se ha actualizado la distribución de iSCSI Gateway según el método de DeepSea en la Sección 10.4, “Instalación y conﬁguración” (https://bugzilla.suse.com/show_bug.cgi? id=1073327 ).

136 Octubre de 2018 (lanzamiento de SUSE Enterprise Storage 5.5) SES 5 No se admiten las cuotas de CephFS. Consulte la Sección 11.1, “Escenarios admitidos de CephFS y directrices” (https://bugzilla.suse.com/show_bug.cgi?id=1077269 ).

Se incluyen particiones con números superiores a 9 en el paso de puesta a cero, consulte el Paso 13 (https://bugzilla.suse.com/show_bug.cgi?id=1050230 ).

A.2 Noviembre de 2017 (actualización de mantenimiento)

Actualizaciones generales

Se han añadido la Sección 11.3.2, “Tamaño del clúster del servidor de metadatos” y la Sección 11.3.3, “Clúster de servidor de metadatos y actualizaciones”.

Solución de errores

Se ha mejorado la estrategia de borrado de disco en el Paso 13 de la Sección 4.3, “Distribución del clúster” (https://bugzilla.suse.com/show_bug.cgi?id=1073897 ).

Se ha añadido una sugerencia para desactivar las medidas de seguridad en la Sección 5.4.1, “Migración de OSD a BlueStore” (https://bugzilla.suse.com/show_bug.cgi? id=1073720 ).

Se hace referencia a la Sección 4.2.2.1, “Coincidencia del nombre del minion” en el Procedimiento 4.1, “Ejecución de fases de distribución” y en el Libro “Guía de administración”, Capítulo 1 “Administración de un clúster de Salt”, Sección 1.1 “Adición de nuevos nodos de clúster” para unicar el origen de la información (https://bugzilla.suse.com/ show_bug.cgi?id=1073374 ).

En la Sección 5.2, “Procedimiento de actualización general” solo se actualiza el master y el minion de Salt y no todos los paquetes. Por lo tanto, se ha sustituido salt target state.apply ceph.updates por salt target state.apply ceph.updates.salt (https://bugzilla.suse.com/show_bug.cgi?id=1073373 ).

Se ha añadido la Sección 5.6, “Actualización desde SUSE Enterprise Storage 4 (distribución de Crowbar) a la versión 5” (https://bugzilla.suse.com/show_bug.cgi?id=1073317 y https:// bugzilla.suse.com/show_bug.cgi?id=1073701 ).

137 Noviembre de 2017 (actualización de mantenimiento) SES 5 Se ha sustituido "*" por target y se ha ampliado la introducción de destino en la Sección 4.2.2, “Asignación de destino de los minions” (https://bugzilla.suse.com/ show_bug.cgi?id=1068956 ).

Se ha añadido la vericación de huellas digitales de minions de Salt en la Sección 4.3, “Distribución del clúster” (https://bugzilla.suse.com/show_bug.cgi?id=1064045 ).

Se ha eliminado el consejo para copiar el archivo refactor.conf de ejemplo en el Libro “Guía de administración”, Capítulo 1 “Administración de un clúster de Salt”, Sección 1.8 “Instalación automatizada mediante Salt” (https://bugzilla.suse.com/ show_bug.cgi?id=1065926 ).

Se ha corregido la vía al archivo YAML de conguración de red en el Procedimiento 4.1, “Ejecución de fases de distribución” (https://bugzilla.suse.com/ show_bug.cgi?id=1067730 ).

Se verica el diseño de clúster en el Procedimiento 5.2, “Pasos que se deben aplicar en el nodo master de Salt” (https://bugzilla.suse.com/show_bug.cgi?id=1067189 ).

Se ha añadido ceph osd set sortbitwise a la Sección 5.4, “Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la versión 5” y el Procedimiento 5.2, “Pasos que se deben aplicar en el nodo master de Salt” (https://bugzilla.suse.com/show_bug.cgi? id=1067146 ).

Se ha eliminado osd crush location , ceph.conf se personaliza de forma distinta en Importante: requisitos de software (https://bugzilla.suse.com/show_bug.cgi? id=1067381 ).

Se ha corregido "role-admin", en lugar de "role-master", en la Sección 4.5.1.2, “Asignación de funciones” (https://bugzilla.suse.com/show_bug.cgi?id=1064056 ).

Se ha corregido la vía a cluster.yml en el Procedimiento 4.1, “Ejecución de fases de distribución” (https://bugzilla.suse.com/show_bug.cgi?id=1066711 ).

Se ha añadido la Sección 12.3.4, “Alta disponibilidad de NFS Ganesha y DeepSea” (https:// bugzilla.suse.com/show_bug.cgi?id=1058313 ).

Se ha vuelto a añadir la Sección 2.7.2, “Nodos de monitor en subredes diferentes” (https:// bugzilla.suse.com/show_bug.cgi?id=1050115 ).

El archivo deepsea_minions.sls solo debe contener una entrada deepsea_minions . Consulte el Procedimiento 4.1, “Ejecución de fases de distribución” (https://bugzilla.suse.com/show_bug.cgi?id=1065403 ).

138 Noviembre de 2017 (actualización de mantenimiento) SES 5 Se ha cambiado el orden de los pasos en el primer procedimiento de la Sección 4.3, “Distribución del clúster” (https://bugzilla.suse.com/show_bug.cgi?id=1064770 ).

Se ha aclarado la Sección 5.4.1, “Migración de OSD a BlueStore” (https://bugzilla.suse.com/ show_bug.cgi?id=1063250 ).

A.3 Octubre de 2017 (lanzamiento de SUSE Enterprise Storage 5)

Actualizaciones generales

Se ha añadido la Sección 5.7, “Actualización desde SUSE Enterprise Storage 3 a la versión 5” (Fate n.º 323072).

Se ha eliminado la herramienta de instalación Crowbar obsoleta y se ha sustituido por DeepSea.

Se ha eliminado la herramienta ceph-deploy obsoleta y se ha sustituido por DeepSea.

Se ha actualizado el Capítulo 2, Requisitos y recomendaciones de hardware (https://bugzilla.suse.com/show_bug.cgi?id=1029544 y https://bugzilla.suse.com/ show_bug.cgi?id=1042283 ).

Se ha actualizado el Capítulo 12, Instalación de NFS Ganesha (https://bugzilla.suse.com/ show_bug.cgi?id=1036495 , https://bugzilla.suse.com/show_bug.cgi?id=1031444 , Fate n.º 322464).

Ha cambiado el esquema de denominación de perles de DeepSea. Consulte la Sección 4.5.1.4, “Asignación de perﬁl” (https://bugzilla.suse.com/show_bug.cgi? id=1046108 ).

CephFS se puede utilizar en repositorios codicados de borrado, consulte la Sección 11.3.1, “Creación de CephFS” (Fate n.º 321617).

Solución de errores

139 Octubre de 2017 (lanzamiento de SUSE Enterprise Storage 5) SES 5 Se ha añadido la Sección 10.5, “Exportación de imágenes del dispositivo de bloques RADOS mediante tcmu-runner” (https://bugzilla.suse.com/show_bug.cgi?id=1064467 ).

Se ha mejorado el procedimiento de actualización para incluir la función openATTIC en la Sección 5.4, “Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la versión 5” (https://bugzilla.suse.com/show_bug.cgi?id=1064621 ).

Se ha añadido una referencia al Procedimiento 4.1, “Ejecución de fases de distribución” en el Paso 4 (https://bugzilla.suse.com/show_bug.cgi?id=1064276 ).

Se ha modicado el procedimiento de actualización en el Procedimiento 5.2, “Pasos que se deben aplicar en el nodo master de Salt” (https://bugzilla.suse.com/show_bug.cgi? id=1061608 y https://bugzilla.suse.com/show_bug.cgi?id=1048959 ).

Se ha añadido rgw.conf en el Libro “Guía de administración”, Capítulo 1 “Administración de un clúster de Salt”, Sección 1.11 “Archivo ceph.conf personalizado” (https:// bugzilla.suse.com/show_bug.cgi?id=1062109 ).

Se ha movido la instalación de DeepSea al nal de la Sección 4.3, “Distribución del clúster” (https://bugzilla.suse.com/show_bug.cgi?id=1056292 ).

Se ha añadido la Sección 4.5.1.5, “Distribución de OSD cifrados” (https://bugzilla.suse.com/ show_bug.cgi?id=1061751 ).

Se ha actualizado y simplicado el procedimiento de actualización en la Sección 5.4, “Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la versión 5” (https://bugzilla.suse.com/show_bug.cgi?id=1059362 ).

Se debe comprobar la versión de DeepSea antes de la actualización en Importante: requisitos de software (https://bugzilla.suse.com/show_bug.cgi?id=1059331 ).

Se añade un prejo a los archivos .sls personalizados con custom- en la Sección 7.1, “Uso de archivos de conﬁguración personalizados” (https://bugzilla.suse.com/ show_bug.cgi?id=1048568 ).

Se ha añadido una nota sobre las discrepancias de las capacidades de clave en la Sección 5.4, “Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la versión 5” (https://bugzilla.suse.com/show_bug.cgi?id=1054186 ).

Se han combinado elementos de lista redundantes en la Sección 4.3, “Distribución del clúster” (https://bugzilla.suse.com/show_bug.cgi?id=1055140 ).

140 Octubre de 2017 (lanzamiento de SUSE Enterprise Storage 5) SES 5 Se ha añadido una nota sobre el tiempo prolongado que puede tardar la actualización del clúster en la Sección 5.4, “Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la versión 5” (https://bugzilla.suse.com/show_bug.cgi?id=1054079 ).

Es obligatoria la asignación de destinos de los minions de Salt con deepsea_minions: (https://bugzilla.suse.com/show_bug.cgi?id=1054229 ).

Se ha insertado la fase 1 después de la importación en el Procedimiento 5.2, “Pasos que se deben aplicar en el nodo master de Salt” (https://bugzilla.suse.com/show_bug.cgi? id=1054155 ).

Se ha añadido el Libro “Guía de administración”, Capítulo 1 “Administración de un clúster de Salt”, Sección 1.11 “Archivo ceph.conf personalizado” (https://bugzilla.suse.com/ show_bug.cgi?id=1052806 ).

Se han añadido pasos que faltaban en la Sección 5.4, “Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la versión 5” (https://bugzilla.suse.com/ show_bug.cgi?id=1052597 ).

Se ha corregido la sintaxis del comando radosgw-admin en la Sección 12.2, “Instalación de ejemplo” (https://bugzilla.suse.com/show_bug.cgi?id=1052698 ).

No es obligatorio que "salt" sea el nombre del master de Salt durante la actualización en el Procedimiento 5.1, “Pasos que se deben aplicar a todos los nodos del clúster (incluido el nodo de Calamari)” (https://bugzilla.suse.com/show_bug.cgi?id=1052907 ).

Se ha mejorado la redacción del texto en la sección "Importante" de la Sección 5.4, “Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la versión 5” (https://bugzilla.suse.com/show_bug.cgi?id=1052147 ).

Se ha añadido una nota sobre la asignación de funciones manuales durante la importación en el Procedimiento 5.2, “Pasos que se deben aplicar en el nodo master de Salt” (https://bugzilla.suse.com/show_bug.cgi?id=1050554 ).

Se ha añadido la Sección 5.4.1, “Migración de OSD a BlueStore” (https://bugzilla.suse.com/ show_bug.cgi?id=1052210 ).

Se explica en detalle salt-run populate.engulf_existing_cluster en el Procedimiento 5.2, “Pasos que se deben aplicar en el nodo master de Salt” (https:// bugzilla.suse.com/show_bug.cgi?id=1051258 ).

Se ha añadido la función openATTIC en la Sección 4.5.1.7, “Archivo policy.cfg de ejemplo” (https://bugzilla.suse.com/show_bug.cgi?id=1052076 ).

141 Octubre de 2017 (lanzamiento de SUSE Enterprise Storage 5) SES 5 Se han corregido las vías profile-default en la Sección 4.5.1.7, “Archivo policy.cfg de ejemplo” (https://bugzilla.suse.com/show_bug.cgi?id=1051760 ).

Se ha separado la sección anterior en un nuevo capítulo, Capítulo 7, Personalización de la conﬁguración por defecto (https://bugzilla.suse.com/show_bug.cgi?id=1050238 ).

Se hace referencia a la Sección 1.2.3, “Nodos y daemons de Ceph” en Descripción de las fases de DeepSea para mantener actualizada la lista de servicios de Ceph (https:// bugzilla.suse.com/show_bug.cgi?id=1050221 ).

Se ha mejorado la descripción del master de Salt y la redacción en el Capítulo 4, Distribución con DeepSea/Salt (https://bugzilla.suse.com/show_bug.cgi?id=1050214 ).

Se ha añadido una descripción de las funciones de nodo opcionales en la Sección 1.2.3, “Nodos y daemons de Ceph” (https://bugzilla.suse.com/show_bug.cgi?id=1050085 ).

Se ha actualizado el procedimiento de actualización en general (https://bugzilla.suse.com/show_bug.cgi?id=1048436 , https://bugzilla.suse.com/ show_bug.cgi?id=1048959 y https://bugzilla.suse.com/show_bug.cgi?id=104i7085 ).

Se ha añadido un nuevo Ceph Manager de función de DeepSea (https:// bugzilla.suse.com/show_bug.cgi?id=1047472 ).

Se ha añadido la Sección 5.5, “Actualización desde SUSE Enterprise Storage 4 (distribución de ceph-deploy) a la versión 5” (https://bugzilla.suse.com/show_bug.cgi?id=1048436 ).

La fase 0 se ha hecho completamente opcional en Descripción de las fases de DeepSea (https://bugzilla.suse.com/show_bug.cgi?id=1045845 ).

Se ha actualizado la lista de repositorios por defecto en la Sección 9.1.1, “Conﬁguración de Object Gateway” (https://bugzilla.suse.com/show_bug.cgi?id=1034039 ).

Se ha añadido un fragmento "Importante" sobre que DeepSea distribuye ahora Object Gateway en el Capítulo 9, Ceph Object Gateway (https://bugzilla.suse.com/show_bug.cgi? id=1044928 ).

Se ha corregido el guion de shell en la Sección 4.3, “Distribución del clúster” (https:// bugzilla.suse.com/show_bug.cgi?id=1044684 ).

Se ha añadido "Denición del indicador require-osd-release luminous " en la Sección 5.2, “Procedimiento de actualización general” (https://bugzilla.suse.com/ show_bug.cgi?id=1040750 ).

142 Octubre de 2017 (lanzamiento de SUSE Enterprise Storage 5) SES 5 Se ha añadido una anotación en el ejemplo policy.cfg en la Sección 4.5.1.7, “Archivo policy.cfg de ejemplo” (https://bugzilla.suse.com/show_bug.cgi?id=1042691 ).

Se han mejorado los comandos para el borrado de la tabla de particiones del disco OSD en la Sección 4.3, “Distribución del clúster” (https://bugzilla.suse.com/show_bug.cgi? id=1042074 ).

Se ha eliminado el consejo para instalar salt-minion en el master de Salt en la Sección 4.3, “Distribución del clúster” (https://bugzilla.suse.com/show_bug.cgi? id=1041590 ).

Se ha inhabilitado AppArmor en la Sección 4.3, “Distribución del clúster” y la Sección 5.4, “Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la versión 5” (https://bugzilla.suse.com/show_bug.cgi?id=1039852 ).

Se ha añadido una recomendación de cortafuegos en la Sección 4.3, “Distribución del clúster” (https://bugzilla.suse.com/show_bug.cgi?id=1039344 ).

Se han eliminado las referencias a XML-RPC de las líneas de comandos systemd de openATTIC en la Sección 7.1, “Uso de archivos de conﬁguración personalizados” (https:// bugzilla.suse.com/show_bug.cgi?id=1037371 ).

Se ha corregido la sintaxis de YAML en la Sección 4.3, “Distribución del clúster” (https:// bugzilla.suse.com/show_bug.cgi?id=1035498 ).

Se ha añadido una explicación de la función "ganesha" en la Sección 4.5.1.2, “Asignación de funciones” (https://bugzilla.suse.com/show_bug.cgi?id=1037365 ).

Se ha aclarado y mejorado la redacción de la Sección 4.5.1, “El archivo policy.cfg” (https://bugzilla.suse.com/show_bug.cgi?id=1037360 ).

Se ha añadido el procedimiento de actualización de SUSE Enterprise Storage 4 a la versión 5 en la Sección 5.4, “Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la versión 5” (https://bugzilla.suse.com/show_bug.cgi?id=1036266 ).

Se ha sustituido el término "provisión" por "preparación" en la Sección 4.3, “Distribución del clúster” (https://bugzilla.suse.com/show_bug.cgi?id=1036400 y https://bugzilla.suse.com/show_bug.cgi?id=1036492 ).

Se ha añadido una advertencia sobre técnicas avanzadas en la Sección 4.5.1.6, “Filtrado de elementos” (https://bugzilla.suse.com/show_bug.cgi?id=1036278 ).

143 Octubre de 2017 (lanzamiento de SUSE Enterprise Storage 5) SES 5 Se han sustituido asignaciones de role-admin redundantes en la Sección 4.5.1.7, “Archivo policy.cfg de ejemplo” (https://bugzilla.suse.com/ show_bug.cgi?id=1036506 ).

Se ha mejorado Descripción de las fases de DeepSea y la Sección 4.3, “Distribución del clúster” (https://bugzilla.suse.com/show_bug.cgi?id=1036278 ).

Se han añadido cambios en los pasos de la distribución en la Sección 7.1, “Uso de archivos de conﬁguración personalizados” (https://bugzilla.suse.com/show_bug.cgi? id=1026782 ).

Se ha aclarado y mejorado el Capítulo 4, Distribución con DeepSea/Salt como se sugiere en (https://bugzilla.suse.com/show_bug.cgi?id=1020920 ).

Se recomienda habilitar los servicios openATTIC personalizados en la Sección 7.1, “Uso de archivos de conﬁguración personalizados” (https://bugzilla.suse.com/show_bug.cgi? id=989349 ).

Se han movido las recomendaciones de red al Capítulo 2, Requisitos y recomendaciones de hardware y se ha incluido la Sección 2.7.1, “Adición de una red privada a un clúster en ejecución” (https://bugzilla.suse.com/show_bug.cgi?id=1026569 ).

144 Octubre de 2017 (lanzamiento de SUSE Enterprise Storage 5) SES 5