Embed Size (px)
Citation preview
Guía de distribución
SUSE Enterprise Storage 6
Guía de distribuciónSUSE Enterprise Storage 6por Tomáš Bažant, Jana Haláčková, Alexandra Settle, y Sven Seeberg
Fecha de publicación: 22/05/2020
SUSE LLC1800 South Novell PlaceProvo, UT 84606USA
https://documentation.suse.com
Copyright © 2020 SUSE LLC
Copyright © 2016, RedHat, Inc. y colaboradores.
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://creative-
commons.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
Innity 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 Interna-
tional Corporation o sus liales en los Estados Unidos 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 aliados. 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 x
I SUSE ENTERPRISE STORAGE 1
1 SUSE Enterprise Storage 6 y Ceph 21.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 7
Repositorio 7 • Grupo de colocación 7 • Ejemplo 7
1.4 BlueStore 9
1.5 Información adicional 10
2 Requisitos y recomendaciones de hardware 11
2.1 Configuraciones de varias arquitecturas 11
2.2 Configuración mínima del clúster 11
2.3 Nodos de almacenamiento de objetos 12
Requisitos mínimos 12 • Tamaño mínimo de disco 13 • Tamaño
recomendado para el dispositivo WAL y DB de BlueStore 13 • Uso
de unidades SSD para diarios OSD 14 • Número máximo de discos
recomendados 14
2.4 Nodos de monitor 15
2.5 Nodos de Object Gateway 15
2.6 Nodos del servidor de metadatos 16
2.7 Master de Salt 16
2.8 Nodos iSCSI 16
iv Guía de distribución
2.9 Recomendaciones de red 16
Adición de una red privada a un clúster en ejecución 17 • Nodos de monitor
en subredes diferentes 18
2.10 Limitaciones de denominación 18
2.11 Un servidor compartido por varios OSD y monitores 19
2.12 Configuración de clúster de producción recomendada 19
2.13 SUSE Enterprise Storage 6 y otros productos SUSE 20
SUSE Manager 20
3 Configuración de alta disponibilidad del nodo deadministración 21
3.1 Esquema del clúster de alta disponibilidad para el nodo deadministración 21
3.2 Vinculación de un clúster de alta disponibilidad con un nodo deadministración 22
4 Privilegios de usuario y comandos de símbolos delsistema 24
4.1 Comandos relativos a Salt/DeepSea 24
4.2 Comandos relativos a Ceph 24
4.3 Comandos generales de Linux 25
4.4 Información adicional 25
II DISTRIBUCIÓN Y ACTUALIZACIÓN DEL CLÚSTER 26
5 Distribución con DeepSea/Salt 275.1 Lectura de las notas de la versión 28
5.2 Introducción a DeepSea 28
Organización y ubicaciones importantes 30 • Asignación de destino de los
minions 30
5.3 Distribución del clúster 33
v Guía de distribución
5.4 Interfaz de línea de comandos de DeepSea 42
Interfaz de línea de comandos de DeepSea: modo de monitor 43 • Interfaz
de línea de comandos de DeepSea: modo autónomo 43
5.5 Configuración y personalización 45
El archivo policy.cfg 45 • DriveGroups 51 • Ajuste de ceph.conf con
valores personalizados 60
6 Actualización desde versiones anteriores 61
6.1 Puntos que se deben tener en cuenta antes de la actualización 61
6.2 Copia de seguridad de los datos del clúster 65
6.3 Migración de ntpd a chronyd 65
6.4 Aplicación de parches al clúster antes de la actualización 67
Repositorios de software requeridos 67 • Sistemas de fases de
repositorio 68 • Aplicación de los parches más recientes a todo el
clúster 68
6.5 Verificación del entorno actual 69
6.6 Comprobación del estado del clúster 70
6.7 Actualización sin conexión de los clústeres CTDB 71
6.8 Actualización por nodo: procedimiento básico 71
Actualización manual de nodo mediante el DVD del
instalador 72 • Actualización de nodos con el sistema de migración de
distribución de SUSE 74
6.9 Actualización del nodo de administración 75
6.10 Actualización de nodos de Ceph Monitor/Ceph Manager 77
6.11 Actualización de servidores de metadatos 77
6.12 Actualización de los OSD Ceph 79
6.13 Migración de OSDs a BlueStore 82
6.14 Actualización de nodos de aplicación 84
vi Guía de distribución
6.15 Actualización de policy.cfg y distribución de Ceph Dashboard conDeepSea 85
6.16 Migración de distribuciones basadas en perfiles a DriveGroups 87
Análisis del diseño actual 88 • Creación de DriveGroups que coincidan con
el diseño actual 88 • Distribución de OSD 89 • Configuraciones más
complejas 90
7 Personalización de la configuración por defecto 91
7.1 Uso de archivos de configuración personalizados 91
Inhabilitación de un paso de la distribución 91 • Sustitución
de un paso de la distribución 92 • Modificación de un
paso de la distribución 94 • Modificación de una fase de la
distribución 95 • Actualizaciones y reinicios durante la fase 0 96
7.2 Modificación de la configuración descubierta 97
Habilitación de IPv6 para la distribución del clúster de Ceph 100
III INSTALACIÓN DE SERVICIOS ADICIONALES 101
8 Instalación de servicios para acceder a los datos 102
9 Ceph Object Gateway 103
9.1 Instalación manual de Object Gateway 104
Configuración de Object Gateway 104
10 Instalación de iSCSI Gateway 111
10.1 Almacenamiento de bloques iSCSI 111
Destino iSCSI de kernel de Linux 112 • Iniciadores iSCSI 112
10.2 Información general sobre ceph-iscsi 113
10.3 Consideraciones de distribución 115
10.4 Instalación y configuración 115
Distribución de iSCSI Gateway en un clúster de Ceph 116 • Creación
de imágenes RBD 116 • Exportación de imágenes RBD a través
vii Guía de distribución
de iSCSI 116 • Autenticación y control de acceso 118 • Valores
avanzados 119
10.5 Exportación de imágenes del dispositivo de bloques RADOS mediantetcmu-runner 123
11 Instalación de CephFS 125
11.1 Escenarios admitidos de CephFS y directrices 125
11.2 Servidor de metadatos de Ceph 126
Adición de un servidor de metadatos 126 • Configuración de un servidor de
metadatos 127
11.3 CephFS 133
Creación de CephFS 133 • Tamaño del clúster del servidor
de metadatos 135 • Clúster de servidor de metadatos y
actualizaciones 135 • Diseños de archivos 136
12 Instalación de NFS Ganesha 142
12.1 Preparación 142
Información general 142 • Resumen de requisitos 143
12.2 Instalación de ejemplo 143
12.3 Configuración activa-pasiva de alta disponibilidad 144
Instalación básica 144 • Limpieza de recursos 147 • Configuración del
recurso de Ping 147 • Alta disponibilidad de NFS Ganesha y DeepSea 148
12.4 Configuración activa-activa 148
Requisitos previos 149 • Configuración de NFS Ganesha 149 • Relleno
de la base de datos de gracia del clúster 151 • Reinicio de servicios de NFS
Ganesha 151 • Conclusión 152
12.5 Más información 152
viii Guía de distribución
IV DISTRIBUCIÓN DE CLÚSTERES SOBRE LA PLATAFORMA SUSE CAAS 4(VERSIÓN PRELIMINAR DE TECNOLOGÍA) 153
13 SUSE Enterprise Storage 6 sobre clúster de Kubernetesde SUSE CaaS Platform 4 154
13.1 Observaciones 154
13.2 Requisitos previos 154
13.3 Obtención de manifiestos de Rook 155
13.4 Instalación 155
Configuración 155 • Creación del operador de Rook 157 • Creación del
clúster de Ceph 157
13.5 Uso de Rook como almacenamiento para la carga de trabajo deKubernetes 158
13.6 Desinstalación de Rook 159
A Actualizaciones de mantenimiento de Ceph basadasen versiones secundarias superiores de Nautilus 160
Glosario 163
B Actualizaciones de la documentación 166
B.1 Actualización de mantenimiento de la documentación de SUSEEnterprise Storage 6 166
B.2 Junio de 2019 (lanzamiento de SUSE Enterprise Storage 6) 167
ix Guía de distribución
Acerca de esta guía
SUSE Enterprise Storage 6 es una extensión de SUSE Linux Enterprise Server 15 SP1. Combina lasfunciones del proyecto de almacenamiento Ceph (http://ceph.com/ ) con la ingeniería empre-sarial y la asistencia de SUSE. SUSE Enterprise Storage 6 proporciona a las organizaciones deTI la capacidad de distribuir una arquitectura de almacenamiento distribuida que admite varioscasos de uso mediante plataformas de hardware básicas.
En esta guía se explican los conceptos de SUSE Enterprise Storage 6 con el objetivo principalde gestionar y administrar la infraestructura de Ceph. También se muestra cómo usar Ceph conotras 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óna la que se accede desde Internet.
Para obtener una descripción general acerca de la documentación disponible en relación con elproducto y de las actualizaciones más recientes, consulte http://www.suse.com/documentation .
1 Documentación disponibleLos 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ésde la instalación. Esta guía también incluye los pasos necesarios para integrar Ceph consoluciones de virtualización como libvirt , Xen o KVM; así como formas para acceder aobjetos 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 todoslos servicios relacionados con Ceph. También muestra una estructura de clúster de Cephbá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 envarios formatos.
x Documentación disponible SES 6
2 ComentariosExisten 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 dispo-nibles para el producto, consulte http://www.suse.com/support/ .Para informar sobre errores en un componente de producto, entre en el Centro de serviciosal cliente de Novell desde http://www.suse.com/support/ y seleccione Mi asistenciatécnica Petición de servicio.
Comentarios del usuario
Nos gustaría recibir sus comentarios o sugerencias sobre este manual y el resto de ladocumentación incluida junto con el producto. Utilice la función de comentarios delusuario, situada en la parte inferior de las páginas de la documentación en línea, obien diríjase a http://www.suse.com/documentation/feedback.html e introduzca ahí suscomentarios.
Correo
Para hacernos llegar comentarios sobre la documentación del producto, también puedeenviar un mensaje de correo a [email protected] . No olvide incluir el título deldocumento, la versión del producto y la fecha de publicación de la documentación. Parainformar de errores o sugerir mejoras, proporcione una descripción concisa del problemay haga referencia a la sección y página (o URL) en concreto donde lo ha encontrado.
3 Convenciones de la documentaciónEn este manual se utilizan las siguientes convenciones tipográficas:
/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 muestranen mayúsculas, tal y como aparecen en el teclado
xi Comentarios SES 6
Archivo, Archivo Guardar como: elementos de menú, botones_
Pingüinos que bailan (Capítulo Pingüinos, ↑Otro manual): referencia a un capítulo de otromanual.
4 Acerca de la elaboración de este manualEste libro se ha redactado en GeekoDoc, un subconjunto de DocBook (consulte http://www.doc-
book.org ). Los archivos de origen XML fueron validados mediante xmllint , procesados porxsltproc y convertidos a XSL-FO gracias a una versión personalizada de las hojas de estilo deNorman Walsh. El formato PDF nal se puede aplicar mediante FOP de Apache o mediante XEPde RenderX. Las herramientas de creación y publicación usadas para crear este manual estándisponibles en el paquete daps . El conjunto de aplicaciones DocBook Authoring and PublishingSuite (DAPS) se ha desarrollado como software de código abierto. Para obtener más información,consulte: http://daps.sf.net/ .
5 Colaboradores de CephEl proyecto Ceph y su documentación son el resultado del trabajo de cientos de colaboradoresy organizaciones. Consulte https://ceph.com/contributors/ para obtener más información.
xii Acerca de la elaboración de este manual SES 6
I SUSE Enterprise Storage
1 SUSE Enterprise Storage 6 y Ceph 2
2 Requisitos y recomendaciones de hardware 11
3 Configuración de alta disponibilidad del nodo de administración 21
4 Privilegios de usuario y comandos de símbolos del sistema 24
1 SUSE Enterprise Storage 6 y Ceph
SUSE Enterprise Storage 6 es un sistema de almacenamiento distribuido basado en la tecnologíaCeph 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 denomi-nados nodos) y almacenar petabytes de información. A diferencia de los sistemas convencio-nales que cuentan con tablas de asignación para almacenar y recuperar datos, Ceph utiliza unalgoritmo determinista para asignar el almacenamiento de datos y no tiene ninguna estructurade información centralizada. Ceph entiende que en los clústeres de almacenamiento la adición oeliminación de hardware es la norma, no la excepción. El clúster de Ceph automatiza las tareasde gestión, como la distribución, redistribución y réplica de datos; la detección de fallos y larecuperación. Ceph se autorrepara y se autoadministra, con lo que se consigue una reducciónde las tareas administrativas y del presupuesto necesario.
Este capítulo proporciona una visión general de SUSE Enterprise Storage 6 y describe breve-mente los componentes más importantes.
SugerenciaA partir de SUSE Enterprise Storage 5, el único método de distribución de clústeresadmitido es DeepSea. Consulte el Capítulo 5, Distribución con DeepSea/Salt para obtener másinformación sobre el proceso de distribución.
1.1 Características de CephEl 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 obtenerinformación, consulte el Capítulo 2, Requisitos y recomendaciones de hardware
Autoadministración
2 Características de Ceph SES 6
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 esconsciente de los discos sobrecargados.
Sin un punto único de error
Ningún nodo de un clúster almacena información importante por sí solo. El número deredundancias se puede configurar.
Software de código abierto
Ceph es una solución de software de código abierto e independiente de hardware o provee-dores específicos.
1.2 Componentes básicosPara aprovechar al máximo las ventajas de Ceph, es necesario comprender algunos de sus compo-nentes y conceptos básicos. Esta sección presenta algunas partes de Ceph a las que se hacereferencia 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 almace-nados en el clúster. Los datos de Ceph se almacenan normalmente como objetos. Cada objetose compone de un identificador y datos.
RADOS proporciona los siguientes métodos de acceso para los objetos almacenados que abarcanmuchos casos de uso:
Object Gateway
Object Gateway es una pasarela REST HTTP para el almacén de objetos RADOS. Permiteel 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 otrodispositivo de bloques. Por ejemplo, se pueden usar en combinación con libvirt connes de virtualización.
CephFS
3 Componentes básicos SES 6
El sistema de archivos de Ceph tiene conformidad con POSIX.
librados
librados es una biblioteca que se puede utilizar con varios lenguajes de programacióna n de crear una aplicación capaz de interactuar directamente con el clúster de almace-namiento.
librados se utiliza en Object Gateway y RBD, mientras que CephFS interactúa directamentecon 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ónimode Controlled Replication Under Scalable Hashing (réplica controlada bajo hash escalable). Es unafunció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 paracalcular la posición de almacenamiento de un objeto. Los parámetros son un mapa actual delclúster, incluido el estado de actividad, algunas reglas de colocación denidas por el adminis-trador y el nombre del objeto que se va a almacenar o recuperar. Con esta información, todoslos 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 ecaz. CRUSH intentadistribuir 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óndenidas por el administrador para almacenar los objetos en el clúster. Dene una estructurajerárquica que se suele corresponder con la estructura física del clúster. Por ejemplo, los discos
4 CRUSH SES 6
que contienen los datos están en hosts, los hosts están en bastidores, los bastidores en las y laslas en centros de datos. Esta estructura se puede utilizar para denir dominios de fallo. Ceph seasegura de que las réplicas se almacenan en diferentes ramas de un dominio de fallo concreto.
Si el dominio de fallo se dene en el bastidor, las réplicas de los objetos se distribuyen endistintos bastidores. Esto puede mitigar las interrupciones causadas por un conmutador que falleen 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 denir en la la. Cuando se produce un fallo en la unidad dedistribució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 tiposde daemons. Se recomienda ejecutar solo un tipo de daemon en cada nodo, excepto los daemonsde Ceph Manager, que se pueden colocar junto con los monitores Ceph Monitor. Cada clústerrequiere al menos los daemons de Ceph Monitor, Ceph Manager y Ceph OSD:
Nodo de administración
El nodo de administración es un nodo de clúster de Ceph donde se ejecuta el servicio masterde Salt. El nodo de administración es un punto central del clúster de Ceph porque gestionael resto de los nodos del clúster consultando y dando instrucciones a los servicios minionde Salt. Normalmente también incluye otros servicios como la interfaz de usuario Web deCeph Dashboard con la consola Grafana respaldada por el kit de herramientas de super-visión Prometheus.
Ceph Monitor
Los nodos de Ceph Monitor (a menudo abreviado como MON) guardan información sobreel estado de la actividad del clúster: un mapa de todos los nodos y las reglas de distribuciónde los datos (consulte la Sección 1.2.2, “CRUSH”).Si se producen fallos o conictos, los nodos de Ceph Monitor del clúster decidenpor mayoría qué información es la correcta. Para formar una mayoría cualificada, serecomienda 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úmeroimpar de sitios. El número de nodos de Ceph Monitor por sitio debe ser superior al 50 % delos nodos de Ceph Monitor que permanecen operativos si se produce un fallo en un sitio.
Ceph Manager
5 Nodos y daemons de Ceph SES 6
Ceph Manager (MGR) recopila la información de estado de todo el clúster. El daemonde Ceph Manager se ejecuta junto con los daemons de monitor. Proporciona supervisiónadicional y sirve de interfaz entre los sistemas de supervisión y gestión externos.Ceph Manager no requiere configuración adicional, aparte de asegurarse de que está enejecució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 sonunidades de almacenamiento físicas o lógicas (discos duros o particiones). Los dispositivosde 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 casode que se añadan o se eliminen nodos.Los daemons Ceph OSD se comunican con los daemons de monitor y les proporcionan elestado de los demás daemons de OSD.
Para utilizar CephFS, Object Gateway, NFS Ganesha o iSCSI Gateway se necesitan nodos adicio-nales:
Servidor de metadatos (MDS)
Los servidores de metadatos almacenan metadatos para CephFS. Mediante un servidorde metadatos es posible ejecutar comandos básicos del sistema de archivos como ls sinsobrecargar el clúster.
Object Gateway
Object Gateway es una pasarela REST HTTP para el almacén de objetos RADOS. Es compa-tible 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 elespacio del usuario, en lugar de en el espacio del kernel, e interactúa directamente conObject Gateway o CephFS.
iSCSI Gateway
iSCSI es un protocolo de red de almacenamiento que permite a los clientes enviar comandosSCSI a dispositivos de almacenamiento SCSI (destinos) en servidores remotos.
Samba Gateway
Samba Gateway proporciona un acceso SAMBA a los datos almacenados en CephFS.
6 Nodos y daemons de Ceph SES 6
1.3 Estructura de almacenamiento
1.3.1 RepositorioLos objetos que se almacenan en un clúster de Ceph se colocan en repositorios. Los repositoriosrepresentan particiones lógicas del clúster hacia el mundo exterior. Por cada repositorio, esposible denir un conjunto de reglas; por ejemplo, cuántas réplicas de cada objeto deben existir.La configuración estándar de los repositorios se denomina repositorio replicado.
Los repositorios suelen contener objetos, pero también pueden configurarse para actuar como sifueran un sistema RAID 5. En esta configuración, los objetos se almacenan en porciones junto conporciones de código adicionales. Las porciones de código contienen información redundante. Eladministrador puede denir el número de datos y de porciones de código. En esta configuración,los repositorios se denominan repositorios codificados de borrado.
1.3.2 Grupo de colocaciónLos grupos de colocación (PG) se utilizan para la distribución de datos dentro de un repositorio.Cuando se crea un repositorio, se dene un número determinado de grupos de colocación. Losgrupos de colocación se utilizan de modo interno para agrupar objetos y son un factor importantepara el rendimiento de un clúster de Ceph. El grupo de colocación para un objeto se determinasegún el nombre del objeto.
1.3.3 EjemploEsta sección proporciona un ejemplo de cómo gestiona Ceph los datos (consulte la Figura 1.2,
“Ejemplo de Ceph a pequeña escala”). El ejemplo no representa una configuración recomendada deun clúster de Ceph. El hardware está formado por tres nodos de almacenamiento o tres CephOSD ( Host 1 , Host 2 y Host 3 ). Cada nodo tiene tres discos duros que se utilizan como OSD( osd.1 a osd.9 ). Los nodos de Ceph Monitor no se tratan en este ejemplo.
Nota: diferencia entre Ceph OSD y OSDCeph 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 eldaemon.
7 Estructura de almacenamiento SES 6
El clúster tiene dos repositorios, Repositorio A y Repositorio B . Mientras Repositorio Areplica objetos solo dos veces, la capacidad de recuperación de Repositorio B es más importantey 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ónque contiene el objeto.
En este ejemplo, el dominio de fallo está denido en el host. Esto garantiza que las réplicasde los objetos se almacenan en distintos hosts. Según el nivel de réplica que se dena para unrepositorio, 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. ElCeph OSD primario se encarga de la réplica y conrma que el proceso de escritura ha terminadodespués de que todos los demás OSD hayan almacenado el objeto.
Si falla osd.5 , todos los objetos de PG1 siguen estando disponibles en osd.1 . En cuanto elclúster reconoce que un OSD ha fallado, otro OSD toma su lugar. En este ejemplo, osd.4 seutiliza como sustituto de osd.5 . Los objetos almacenados en osd.1 se replican a osd.4 pararestaurar el nivel de réplica.
FIGURA 1.2: EJEMPLO DE CEPH A PEQUEÑA ESCALA
8 Ejemplo SES 6
Si se añade un nuevo nodo con nuevos OSD al clúster, el mapa del clúster cambia. La funciónCRUSH devuelve ubicaciones diferentes para los objetos. los objetos que reciben las nuevasubicaciones se reubican. Este proceso da como resultado un uso equilibrado de todos los OSD.
1.4 BlueStoreBlueStore es el procesador nal de almacenamiento por defecto para Ceph desde SUSE EnterpriseStorage 5. Su rendimiento es mejor que el de FireStore y cuenta con suma de comprobación delos datos completos y compresión integrada.
BlueStore puede gestionar uno, dos o tres dispositivos de almacenamiento. En el caso mássencillo, 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 dearchivos requeridas por RocksDB.
2. El resto del dispositivo suele estar ocupado por una partición de gran tamaño. Se gestionadirectamente mediante BlueStore y contiene todos los datos reales. Este dispositivoprimario normalmente se identica mediante un enlace simbólico de bloque en el direc-torio 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 anticipadade BlueStore. Se identica 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 queel 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 dedatos es una unidad SSD o un disco duro.
Los dispositivos WAL y DB están en unidades SSD independientes, y el dispositivo de datosestá 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 quepueda en el dispositivo DB para mejorar el rendimiento. De nuevo, provisionar un dispositivoDB compartido solo resulta útil si es más rápido que el dispositivo primario.
9 BlueStore SES 6
Sugerencia: planificación del tamaño del dispositivo DBDebe realizar una planificación exhaustiva para garantizar un tamaño suciente al dispo-sitivo DB. Si el dispositivo DB se llena, los metadatos se diseminarán por todo el dispo-sitivo 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 elcomando ceph daemon osd.ID perf dump . El valor slow_used_bytes muestra lacantidad de datos que se han desbordado:
cephadm@adm > ceph daemon osd.ID perf dump | jq '.bluefs'"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íneacompleta. Para obtener información sobre temas que no encuentre en este manual, consultehttp://docs.ceph.com/docs/master/ .
La publicación original CRUSH: Controlled, Scalable, Decentralized Placement of ReplicatedData (CRUSH: colocación controlada, ampliable y descentralizada de datos replicados) deS.A. Weil, S.A. Brandt, E.L. Miller y C. Maltzahn proporciona información útil sobre el funcio-namiento interno de Ceph. Se recomienda su lectura sobre todo al distribuir clústeres agran escala. Encontrará la publicación en http://www.ssrc.ucsc.edu/papers/weil-sc06.pdf .
SUSE Enterprise Storage se puede utilizar con distribuciones OpenStack que no sean deSUSE. Los clientes de Ceph deben estar en un nivel que sea compatible con SUSE EnterpriseStorage.
NotaSUSE admite el componente de servidor de la distribución de Ceph y el proveedorde distribución de OpenStack debe admitir el cliente.
10 Información adicional SES 6
2 Requisitos y recomendaciones de hardware
Los requisitos de hardware de Ceph dependen en gran medida de la carga de trabajo de E/S. Sedeben tener en cuenta los requisitos y recomendaciones de hardware siguientes como punto departida para realizar una planificación detallada.
En general, las recomendaciones proporcionadas en esta sección dependerán de los procesos quehaya activos. Si hay varios procesos en el mismo equipo, los requisitos de CPU, RAM, espacioen disco y red deben sumarse.
2.1 Configuraciones de varias arquitecturasSUSE Enterprise Storage admite arquitecturas x86 y Arm. Al considerar cada arquitectura, esimportante tener en cuenta que desde la perspectiva de los núcleos por OSD, la frecuencia y laRAM, no hay diferencia real entre las arquitecturas de CPU en lo que respecta al tamaño.
como ocurre con los procesadores x86 más pequeños (que no son de servidor), los núcleosbasados en Arm de menor rendimiento podrían no proporcionar una experiencia óptima,especialmente si se utilizan para repositorios codificados de borrado.
2.2 Configuración mínima del clúster
Se necesitan al menos cuatro nodos OSD, con ocho discos OSD cada uno.
Tres nodos de Ceph Monitor (se requiere que la unidad de sistema operativo dedicada seaSSD).
Las instancias de iSCSI Gateway, Object Gateway y los servidores de metadatos requieren4 GB de RAM incremental y cuatro núcleos.
Los nodos de Ceph Monitor, Object Gateway y de los servidores de metadatos requierenuna distribución redundante.
Un nodo de administración independiente con 4 GB de RAM, cuatro núcleos y 1 TB decapacidad. Normalmente, se trata del nodo master Salt. Los servicios y pasarelas de Ceph,como Ceph Monitor, Ceph Manager, el servidor de metadatos, Ceph OSD, Object Gatewayo NFS Ganesha no se admiten en el nodo de administración.
11 Configuraciones de varias arquitecturas SES 6
2.3 Nodos de almacenamiento de objetos
2.3.1 Requisitos mínimos
Recomendaciones de CPU:
1 subproceso de CPU de 2 GHz por disco giratorio
2 subprocesos de CPU de 2 GHz por SSD
4 subprocesos de CPU de 2 GHz por NVMe
Redes 10 GbE separadas (público/cliente y procesador nal de almacenamiento), serequieren 4 de 10 GbE, se recomiendan 2 de 25 GbE.
Total de RAM requerida = número de OSD x (1 GB + osd_memory_target ) + 16 GBConsulte Libro “Guía de administración”, Capítulo 16 “Configuración del clúster de Ceph”,
Sección 16.2.1 “Tamaño automático de caché” para obtener más detalles sobre el valor deosd_memory_target .
Discos OSD en configuraciones JBOD o configuraciones RAID-0 individuales.
El diario del OSD puede encontrarse en el disco del OSD.
Los discos OSD deben utilizarse exclusivamente para SUSE Enterprise Storage.
Disco o unidad SSD dedicado para el sistema operativo, preferiblemente en una configu-ración de RAID 1.
Si este host OSD va a alojar parte de un repositorio de caché que se utilice para la clasifi-cación en niveles del caché, asigne al menos 4 GB de RAM adicionales.
Los monitores Ceph Monitor, la pasarela y los servidores de metadatos pueden encontrarseen los nodos de almacenamiento de objeto.
Por motivos de rendimiento del disco, se recomienda usar nodos OSD instalados desdecero, y no máquinas virtuales.
12 Nodos de almacenamiento de objetos SES 6
2.3.2 Tamaño mínimo de disco
Existen dos tipos de espacio de disco necesarios para ejecutarse en OSD: el espacio para el diariodel disco (para FileStore) o dispositivo WAL/DB (para BlueStore), y el espacio primario paralos datos almacenados. El valor mínimo (y por defecto) para el diario/WAL/DB es de 6 GB. Elespacio mínimo para los datos es de 5 GB, ya que a las particiones de menos de 5 GB se lesasigna 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 recomiendausar discos de menos de 20 GB, ni siquiera con nes de prueba.
2.3.3 Tamaño recomendado para el dispositivo WAL y DB deBlueStore
Sugerencia: más informaciónConsulte la Sección 1.4, “BlueStore” para obtener más información sobre BlueStore.
Se recomienda reservar 4 GB para el dispositivo WAL. El tamaño recomendado para DB esde 64 GB para la mayoría de las cargas de trabajo.
Si tiene previsto colocar el dispositivo WAL y el dispositivo DB en el mismo disco, serecomienda usar una partición única para ambos dispositivos, en lugar de tener unapartición independiente para cada uno. Esto permite a Ceph utilizar también el dispositivoDB para el funcionamiento de WAL. Por lo tanto, la gestión del espacio de disco es másecaz, ya que Ceph utiliza la partición de DB para WAL solo si es necesario. Otra ventajaes que la probabilidad de que la partición WAL se llene es muy pequeña, y si no se utilizapor completo, su espacio no se desperdicia, sino que se usa para el funcionamiento deldispositivo DB.Para compartir el dispositivo DB con el dispositivo WAL, no especifique el dispositivo WAL:especifique solo el dispositivo DB.Encontrará más información sobre cómo especificar un diseño de OSD en la Sección 5.5.2,
“DriveGroups”.
13 Tamaño mínimo de disco SES 6
2.3.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 accesoaleatorio y la latencia de lectura, a la vez que acelera el rendimiento de los datos. Dado que suprecio por MB es mucho mayor que el de los discos duros giratorios, las unidades SSD solo sonadecuadas para almacenamiento de menor tamaño.
Los OSD pueden tener una mejora significativa del rendimiento si almacenan su diario en unaunidad SSD y los datos del objeto en un disco duro independiente.
Sugerencia: cómo compartir un SSD para varios diariosLos datos del diario ocupan relativamente poco espacio, por lo que puede montar variosdirectorios de diario en un único disco SSD. Tenga en cuenta que con cada diariocompartido, el rendimiento del disco SSD se resiente. No es recomendable compartir másde seis diarios en el mismo disco SSD o 12 en discos NVMe.
2.3.5 Número máximo de discos recomendados
Puede tener tantos discos como permita un servidor. Pero existen algunos asuntos que debetener en cuenta a la hora de planificar el número de discos por servidor:
Ancho de banda de red. Cuantos más discos haya en un servidor, más datos deben transfe-rirse a través de las tarjetas de red para las operaciones de escritura del disco.
Memoria. La RAM que supere los 2 GB se utiliza para el caché de BlueStore. Con el valorpor defecto de osd_memory_target de 4 GB, el sistema tiene un tamaño de caché inicialrazonable para los medios giratorios. Si utiliza SSD o NVME, plantéese la posibilidad deaumentar el tamaño de la memoria caché y la asignación de RAM por OSD para maximizarel rendimiento.
Tolerancia a fallos. Si el servidor falla por completo, cuantos más discos tenga, másOSD perderá temporalmente el clúster. Además, para mantener las reglas de réplica enejecución, necesita copiar todos los datos desde el servidor que ha fallado a los demásnodos del clúster.
14 Uso de unidades SSD para diarios OSD SES 6
2.4 Nodos de monitor
Se necesitan al menos tres nodos de Ceph Monitor. El número de monitores debe sersiempre impar (1+2n).
4 GB de RAM.
Procesador con cuatro núcleos lógicos.
Se recomienda un disco SSD u otro tipo de almacenamiento suficientemente rápido paralos monitores, específicamente para la vía /var/lib/ceph de cada nodo de monitor, yaque el quórum puede ser inestable con latencias elevadas de disco. Se recomiendan dosdiscos con configuración RAID 1 para aportar redundancia. Se recomienda utilizar discosdistintos, o al menos particiones de disco independientes para los procesos de monitor an de proteger el espacio disponible en el monitor frente a estados como la ralentizacióndel 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 dehardware disponibles son sucientes. Esto signica que deberán sumarse los requisitos detodos los servicios.
Dos interfaces de red vinculadas a varios conmutadores.
2.5 Nodos de Object GatewayLos nodos de Object Gateway deben tener de seis a ocho núcleos de CPU y 32 GB de RAM (serecomiendan 64 GB). Si hay otros procesos ubicados en el mismo equipo, deben sumarse susrequisitos.
15 Nodos de monitor SES 6
2.6 Nodos del servidor de metadatosEl 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 CPUy RAM se necesitará. Los requisitos mínimos de son los descritos a continuación:
3 GB de RAM para cada daemon de servidor de metadatos.
Interfaz de red vinculada.
2,5 GHz de CPU con un mínimo de 2 núcleos.
2.7 Master de SaltSe requieren al menos 4 GB de RAM y una CPU de cuatro núcleos. Esto incluye la ejecución deCeph Dashboard en el nodo de administración. Para clústeres de gran tamaño con cientos denodos, se recomiendan 6 GB de RAM.
2.8 Nodos iSCSILos nodos iSCSI deben tener de seis a ocho núcleos de CPU y 16 GB de RAM.
2.9 Recomendaciones de redEs recomendable que el entorno de redes donde tenga previsto ejecutar Ceph sea un conjuntovinculado de al menos dos interfaces de red divididas lógicamente en una parte pública y unaparte interna de conanza mediante VLAN. Se recomienda que el modo de vinculación sea802.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 internaproporciona 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 clavessecretas están aplicadas, los mensajes que se utilizan para configurar estas claves podrían trans-ferirse de forma abierta y son vulnerables.
16 Nodos del servidor de metadatos SES 6
Sugerencia: nodos configurados a través de DHCPSi los nodos de almacenamiento se configuran a través de DHCP, es posible que lostiempos límite por defecto no sean sucientes para que la red se congure de formacorrecta antes de que se inicien los daemons de Ceph. Si esto ocurre, los MON y los OSD deCeph no se iniciarán correctamente (si se ejecuta systemctl status ceph\* se produ-cirá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 encada nodo del clúster de almacenamiento. Para hacerlo, hay que cambiar los valoressiguientes en cada nodo:
En /etc/sysconfig/network/dhcp , dena
DHCLIENT_WAIT_AT_BOOT="30"
En /etc/sysconfig/network/config , dena
WAIT_FOR_INTERFACES="60"
2.9.1 Adición de una red privada a un clúster en ejecución
Si no especica una red de clúster durante la distribución de Ceph, se considera que se trata deun ú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. Paraque 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 esrelativamente rápido, pero si el clúster está formado por cientos o miles de nodos, puede tardarsemucho 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 denir la red de clúster, por ejemplo:
cluster network = 10.0.0.0/24
Si necesita asignar específicamente direcciones IP estáticas o anular los valores decluster network (red del clúster), puede hacerlo con el comando opcional clusteraddr .
17 Adición de una red privada a un clúster en ejecución SES 6
2. Compruebe que la red de clúster privada funciona según lo previsto en el nivel de sistemaoperativo.
3. Inicie los servicios relacionados con Ceph en cada nodo del clúster.
root # systemctl start ceph.target
2.9.2 Nodos de monitor en subredes diferentes
Si los nodos de monitor se encuentran en varias subredes, por ejemplo, se encuentran endistintas salas y emplean conmutadores distintos, es necesario ajustar el archivo ceph.confsegún corresponda. Por ejemplo, si los nodos tienen las direcciones IP 192.168.123.12, 1.2.3.4y 242.12.33.12, añada las líneas siguientes a su sección global :
[global][...]mon host = 192.168.123.12, 1.2.3.4, 242.12.33.12mon initial members = MON1, MON2, MON3[...]
Asimismo, si debe especificar una dirección pública o red por cada monitor, deberá añadir unasecció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.10 Limitaciones de denominaciónEn general, Ceph no admite caracteres no ASCII en los archivos de configuración, los nombresde repositorio, los nombres de usuario, etc. Cuando congure un clúster de Ceph, se recomiendautilizar 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 configuración de Ceph.
18 Nodos de monitor en subredes diferentes SES 6
2.11 Un servidor compartido por varios OSD ymonitoresAunque es técnicamente posible ejecutar varios Ceph OSD y Ceph Monitor en el mismo servidoren entornos de prueba, se recomienda encarecidamente disponer de un servidor independientepara 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 deE/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, unnodo 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 discodedicado distinto al que se use para el sistema operativo.
SugerenciaSi 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.12 Configuración de clúster de producciónrecomendada
Siete nodos de almacenamiento de objeto
Ningún nodo individual debe superar aproximadamente el 15 % del almacenamientototal
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
19 Un servidor compartido por varios OSD y monitores SES 6
1,5 GB de RAM por TB de capacidad OSD en bruto para cada nodo de almacenamientode 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 1para el disco
Un nodo de gestión de SES: 4 GB de RAM, procesador de 4 núcleos, SSD RAID 1para 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 parael disco
Nodos de iSCSI Gateway: 16 GB de RAM, procesador de 4 núcleos, SSD parael disco
Nodos de servidor de metadatos (uno activo y uno en hot standby): 32 GB deRAM, procesador de 8 núcleos, SSD RAID 1 para el disco
2.13 SUSE Enterprise Storage 6 y otros productosSUSEEsta sección contiene información importante acerca de la integración de SUSE EnterpriseStorage 6 con otros productos SUSE.
2.13.1 SUSE Manager
SUSE Manager y SUSE Enterprise Storage no están integrados; por lo tanto, SUSE Manager nopuede gestionar actualmente un clúster de SUSE Enterprise Storage.
20 SUSE Enterprise Storage 6 y otros productos SUSE SES 6
3 Configuración de alta disponibilidad del nodo deadministración
El nodo de administración es un nodo de clúster de Ceph donde se ejecuta el servicio master deSalt. El nodo de administración es un punto central del clúster de Ceph porque gestiona el restode los nodos del clúster consultando y dando instrucciones a los servicios minion de Salt. Normal-mente también incluye otros servicios como la interfaz de usuario Web de Ceph Dashboard conla consola Grafana respaldada por el kit de herramientas de supervisión Prometheus.
En caso de que el nodo de administración falle, lo habitual es que deba proporcionar un nuevohardware que funcione para el nodo y que tenga que restaurar la pila de configuración delclúster completa a partir de una copia de seguridad reciente. Este método lleva bastante tiempoy provoca interrupciones del clúster.
Para evitar tiempos de inactividad del clúster de Ceph debido a fallos en el nodo de adminis-tración, se recomienda usar un clúster de alta disponibilidad (HA) para el nodo de adminis-tración de Ceph.
3.1 Esquema del clúster de alta disponibilidad para elnodo de administraciónLa 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ónvirtualizado. De este modo, los otros nodos del clúster no notan que el nodo de administraciónde Ceph ha fallado.
21 Esquema del clúster de alta disponibilidad para el nodo de administración SES 6
La solución de alta disponibilidad mínima para el nodo de administración requiere el siguientehardware:
Dos servidores instalados desde cero donde se pueda ejecutar SUSE Linux Enterprise conla extensión de alta disponibilidad y donde se pueda virtualizar el nodo de administración.
Dos o más vías de comunicación de red redundantes; por ejemplo, mediante vínculos dedispositivos de red.
Almacenamiento compartido para alojar las imágenes de disco de la máquina virtual delnodo de administración. Debe ser posible acceder al almacenamiento compartido desdeambos servidores. Puede ser, por ejemplo, una exportación NFS, un recurso compartidoSamba o el destino iSCSI.
Encontrará más información sobre los requisitos del clúster en https://www.suse.com/documen-
tation/sle-ha-15/book_sleha_quickstarts/data/sec_ha_inst_quick_req.html .
FIGURA 3.1: CLÚSTER DE ALTA DISPONIBILIDAD DE 2 NODOS PARA EL NODO DE ADMINISTRACIÓN
3.2 Vinculación de un clúster de alta disponibilidadcon un nodo de administraciónEl procedimiento siguiente resume los pasos más importantes a la hora de crear el clúster dealta disponibilidad para la virtualización del nodo de administración. Para obtener más detalles,consulte los enlaces indicados.
22 Vinculación de un clúster de alta disponibilidad con un nodo de administración SES 6
1. Congure un clúster de alta disponibilidad básico de 2 nodos con almacena-miento compartido, como se describe en https://www.suse.com/documentation/sle-ha-15/
book_sleha_quickstarts/data/art_sleha_install_quick.html .
2. En ambos nodos del clúster, instale todos los paquetes necesarios para ejecutar el hiper-visor KVM y el kit de herramientas libvirt , como se describe en https://www.su-
se.com/documentation/sles-15/book_virt/data/sec_vt_installation_kvm.html .
3. En el primer nodo del clúster, cree una máquina virtual KVM nueva mediantelibvirt , como se describe en https://www.suse.com/documentation/sles-15/book_virt/
data/sec_libvirt_inst_vmm.html . Utilice el almacenamiento compartido preconfiguradopara almacenar las imágenes de disco de la máquina virtual.
4. Después de que se haya completado la configuración de la máquina virtual, exporte suconfiguración a un archivo XML en el almacenamiento compartido. Utilice la siguientesintaxis:
root # virsh dumpxml VM_NAME > /path/to/shared/vm_name.xml
5. Cree un recurso para la máquina virtual del nodo de adminis-tración. Consulte https://www.suse.com/documentation/sle-ha-15/book_sleha_guide/data/
cha_conf_hawk2.html para obtener información general sobre cómo crear recursosde alta disponibilidad. Encontrará información detallada sobre cómo crear recursospara una máquina virtual KVM en http://www.linux-ha.org/wiki/VirtualDomain_%28resour-
ce_agent%29 .
6. En la máquina virtual invitada que acaba de crear, distribuya el nodo de adminis-tración, incluidos los servicios adicionales que necesite allí. Siga los pasos relevantes dela Sección 5.3, “Distribución del clúster”. Al mismo tiempo, distribuya los demás nodos delclúster de Ceph en los servidores del clúster que no sean de alta disponibilidad.
23 Vinculación de un clúster de alta disponibilidad con un nodo de administración SES 6
4 Privilegios de usuario y comandos de símbolos delsistema
Como administrador de clústeres de Ceph, va a configurar y ajustar el comportamiento delclúster ejecutando comandos específicos. Necesitará varios tipos de comandos:
4.1 Comandos relativos a Salt/DeepSeaEstos comandos ayudan a distribuir o actualizar el clúster de Ceph, a ejecutar comandos envarios nodos de clúster al mismo tiempo (o en todos ellos) o a ayudarle a añadir o quitar nodosde clúster. Los más utilizados son salt , salt-run y deepsea . Los comandos de Salt se debenejecutar en el nodo master de Salt (consulte Sección 5.2, “Introducción a DeepSea” para obtenermás detalles) como usuario root . Estos comandos se introducen con el siguiente símbolo delsistema:
root@master #
Por ejemplo:
root@master # salt '*.example.net' test.ping
4.2 Comandos relativos a CephSe trata de comandos de nivel inferior para configurar y ajustar todos los aspectos del clústery sus pasarelas en la línea de comandos. Algunos de ellos son ceph , rbd , radosgw-admin ocrushtool .
Para ejecutar comandos relativos a Ceph, debe tener acceso de lectura a una clave de Ceph. Losprivilegios que tiene en el entorno Ceph se denen en las capacidades de la clave. Una opción esejecutar comandos de Ceph como usuario root (o mediante sudo ) y utilizar el anillo de clavessin restricciones por defecto "ceph.client.admin.key".
La opción más segura y recomendada es crear una clave individual más restrictiva para cadausuario administrador y colocarla en un directorio donde los usuarios puedan leerla, porejemplo:
~/.ceph/ceph.client.USERNAME.keyring
24 Comandos relativos a Salt/DeepSea SES 6
Sugerencia: vía a claves de CephPara utilizar un usuario administrador y un anillo de claves personalizados, debe especi-ficar el nombre de usuario y la vía a la clave cada vez que ejecute el comando cephmediante las opciones -n client.NOMBRE_USUARIO y ‑‑keyring VÍA/A/ANILLO/DE/CLAVES .
Para evitarlo, incluya estas opciones en la variable CEPH_ARGS en los archivos~/.bashrc de los usuarios individuales.
Aunque puede ejecutar comandos relativos a Ceph en cualquier nodo de clúster, se recomiendahacerlo en el nodo de administración. Esta documentación utiliza al usuario cephadm paraejecutar los comandos, por lo tanto, se introducen con el siguiente símbolo del sistema:
cephadm@adm >
Por ejemplo:
cephadm@adm > ceph auth list
Sugerencia: comandos para nodos específicosSi la documentación indica que ejecute un comando en un nodo de clúster con una funciónespecíca, el símbolo del sistema se encargará. Por ejemplo:
cephadm@mon >
4.3 Comandos generales de LinuxLos comandos de Linux no relacionados con Ceph o DeepSea, como mount , cat o opensslse introducen con los símbolos del sistema cephadm@adm > o root # , dependiendo de losprivilegios que requiera el comando relacionado.
4.4 Información adicionalPara obtener más información sobre la gestión de claves de Ceph, consulte la Libro “Guía de
administración”, Capítulo 8 “Autenticación con cephx”, Sección 8.2 “Gestión de claves”.
25 Comandos generales de Linux SES 6
II Distribución y actualización delclúster
5 Distribución con DeepSea/Salt 27
6 Actualización desde versiones anteriores 61
7 Personalización de la configuración por defecto 91
5 Distribución con DeepSea/Salt
La combinación de Salt y DeepSea es una pila de componentes que ayudan a distribuir y gestionarla infraestructura de servidor. Tiene mucha capacidad de ampliación, es rápida y es relati-vamente fácil de poner en ejecución. Lea las consideraciones siguientes antes de empezar adistribuir el clúster con Salt:
Los minions de Salt son los nodos que se controlan mediante un nodo dedicado denominadomaster 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 tareascon privilegios, como la creación, autorización y copia de claves en minions, de forma quelos minions remotos nunca tengan que ejecutar tareas con privilegios.
Sugerencia: uso compartido de varias funciones porservidorConseguirá el mejor rendimiento del clúster de Ceph si cada función se distribuyeen un nodo independiente. Pero las distribuciones reales requieren en ocasiones quese comparta un nodo para varias funciones. Para evitar problemas de rendimientoy en el procedimiento de actualización, no distribuya las funciones de Ceph OSD, elservidor de metadatos ni Ceph Monitor al nodo de administración.
Los minions de Salt deben resolver correctamente el nombre de host del master de Salten la red. Por defecto, buscan el nombre de host salt , pero puede especificar cualquierotro nombre de host al que se pueda acceder por la red en el archivo /etc/salt/minion ,consulte la Sección 5.3, “Distribución del clúster”.
27 SES 6
5.1 Lectura de las notas de la versiónEn las notas de la versión puede encontrar información adicional sobre los cambios realizadosdesde la versión previa de SUSE Enterprise Storage. Consulte las notas de versión para comprobarlo siguiente:
si el hardware necesita consideraciones especiales,
si los paquetes de software usados han cambiado de forma significativa,
si es necesario tomar precauciones especiales para la instalación.
Las notas de la versión también proporcionan información que no pudo publicarse en el manuala tiempo y notas acerca de problemas conocidos.
Después de instalar el paquete release-notes-ses , encontrará las notas de la versión enel directorio /usr/share/doc/release-notes o en línea en https://www.suse.com/release-
notes/ .
5.2 Introducción a DeepSeaEl objetivo de DeepSea es ahorrar tiempo al administrador y llevar a cabo operaciones complejasen un clúster de Ceph con toda conanza.
Ceph es una solución de software muy configurable. Aumenta tanto la libertad como la respon-sabilidad de los administradores del sistema.
La configuración mínima de Ceph es adecuada con propósitos de demostración, pero no muestralas 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 ylos nombres de dispositivo. Para un sistema de almacenamiento distribuido como Ceph, puedehaber cientos de esos elementos para recopilar y almacenar. Recopilar la información e intro-ducir los datos manualmente en una herramienta de gestión de configuraciones es una labortremendamente laboriosa y propensa a errores.
Los pasos necesarios para preparar los servidores, recopilar la configuración y configurar ydistribuir Ceph son prácticamente los mismos. Sin embargo, eso no soluciona la gestión defunciones independientes. En las operaciones del día a día, es fundamental contar con lacapacidad de añadir hardware fácilmente a una función determinada y eliminarlo sin problemas.
28 Lectura de las notas de la versión SES 6
DeepSea resuelve este asunto con la estrategia siguiente: consolida las decisiones del adminis-trador en un único archivo. Las decisiones incluyen la asignación del clúster, la asignación dela función y la asignación del perl. Y DeepSea recopila cada conjunto de tareas en un únicoobjetivo. 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 necesariasy puede que el sistema se rearranque.
Importante: nueva ejecución de la fase 0 después dereiniciar el nodo de administraciónSi durante la fase 0, el nodo de administración se reinicia para cargar la nuevaversió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 recopilala información necesaria para la configuración de Ceph. Para obtener detalles sobre laconfiguración, consulte la Sección 5.5, “Configuración y personalización”.
Fase 2: la configuración. Debe preparar los datos de la configuración con un formatoconcreto.
Fase 3: la distribución. Se crea un clúster de Ceph básico con los servicios de Ceph obliga-torios. 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 yCephFS, se pueden instalar en esta fase. Todos son opcionales.
Fase 5: la etapa de eliminación. Esta fase no es obligatoria y durante la configuracióninicial no suele ser necesaria. En esta fase, se eliminan las funciones de los minions y laconfiguración del clúster. Debe ejecutar esta fase si necesita eliminar un nodo de almace-namiento del clúster. Para obtener información detallada, consulte el Libro “Guía de adminis-
tración”, Capítulo 2 “Administración de un clúster de Salt”, Sección 2.3 “Eliminación y reinstalación
de nodos del clúster”.
29 Introducción a DeepSea SES 6
5.2.1 Organización y ubicaciones importantes
Salt tiene algunas ubicaciones estándar y varias convenciones de denominación que se empleanen el nodo máster:
/srv/pillar
En este directorio se almacenan datos de configuración para los minions del clúster. Pillares una interfaz que proporciona valores de configuración globales para todos los minionsdel clúster.
/srv/salt/
En este directorio se almacenan archivos de estado de Salt (también denominados archivossls). Los archivos de estado son descripciones con formato de los estados en los que debeestar el clúster.
/srv/module/runners
En este directorio se almacenan los guiones Python conocidos como runners. Los runnersse ejecutan en el nodo master.
/srv/salt/_modules
En este directorio se almacenan los guiones Python denominados módulos. Los módulosse aplican a todos los minions del clúster.
/srv/pillar/ceph
Este directorio lo utiliza DeepSea para guardar los datos de configuración recopilados.
/srv/salt/ceph
En este directorio usado por DeepSea se almacenan archivos sls que pueden tener distintosformatos. Todos los subdirectorios contienen archivos sls, pero cada subdirectorio contienesolo un tipo de archivo sls. Por ejemplo, /srv/salt/ceph/stage contiene archivos deorganización que se ejecutan mediante salt-run state.orchestrate .
5.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 utilizael comando salt , es preciso especificar un conjunto de minions de Salt a los que afectará elcomando. 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.
30 Organización y ubicaciones importantes SES 6
5.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. Esposible usar comodines, expresiones regulares o listas para limitar el rango de los nombres deminion. A continuación se muestra la sintaxis general:
root@master # salt target example.module
Sugerencia: clúster solo de CephSi todos los minions de Salt del entorno pertenecen al clúster de Ceph, puede sustituircon seguridad target por '*' para incluir todos los minions registrados.
Para obtener todos los minions del dominio example.net (suponiendo que los nombres de losminions 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
5.2.2.2 Asignación de destino con un grain DeepSea
En un entorno heterogéneo gestionado mediante Salt donde SUSE Enterprise Storage 6 sedistribuya en un subconjunto de nodos junto con otras soluciones de clúster, es necesario marcarlos minions relevantes aplicándoles un grain "deepsea" antes de ejecutar la fase 0 de DeepSea.De este modo, puede asignar fácilmente minions de DeepSea en entornos donde sea difícil quelos nombres de los minions coincidan.
31 Asignación de destino de los minions SES 6
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 destinode la siguiente forma:
root@master # salt -G 'deepsea:*' test.ping
El comando siguiente es equivalente:
root@master # salt -C 'G@deepsea:*' test.ping
5.2.2.3 Definición de la opción deepsea_minions
En las distribuciones de DeepSea, es obligatorio denir el destino de la opción deepsea_mi-nions . 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 denir 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_minionsComo target (destino) para la opción deepsea_minions , puede utilizar cualquiermé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:*'
32 Asignación de destino de los minions SES 6
5.2.2.4 Información adicional
Puede utilizar métodos más avanzados para asignar destinos a los minions con la infraestructurade Salt. La página man "deepsea minions" ofrece más detalles sobre la asignación de destinosde DeepSea ( man 7 deepsea_minions ).
5.3 Distribución del clústerEl proceso de distribución del clúster tiene varias fases. En primer lugar, debe preparar todoslos nodos del clúster configurando Salt y, a continuación, distribuir y configurar Ceph.
Sugerencia: distribución de nodos de monitor sin definirperfiles de OSDSi necesita omitir la denición de funciones de almacenamiento para OSD, como sedescribe en Sección 5.5.1.2, “Asignación de funciones”, y distribuir primero los nodos de CephMonitor, puede hacerlo deniendo la variable DEV_ENV .
De esta forma puede distribuir monitores sin la presencia del directorio role-storage/ ,además de distribuir un clúster de Ceph con al menos una función de almacenamiento,monitor y gestión.
Para denir la variable de entorno, puede habilitarla globalmente deniéndola en elarchivo /srv/pillar/ceph/stack/global.yml , o bien denirla solo para la sesiónactual de shell:
root@master # export DEV_ENV=true
Por ejemplo, /srv/pillar/ceph/stack/global.yml se puede crear con el siguientecontenido:
DEV_ENV: True
El siguiente procedimiento describe los detalles para preparar el clúster.
1. Instale y registre SUSE Linux Enterprise Server 15 SP1 junto con la extensión SUSE Enter-prise Storage 6 en cada nodo del clúster.
33 Distribución del clúster SES 6
2. Verique que los productos adecuados están instalados y registrados mostrando los reposi-torios de software existentes. Ejecute zypper lr -E y compare el resultado con lasiguiente lista:
SLE-Product-SLES15-SP1-Pool SLE-Product-SLES15-SP1-Updates SLE-Module-Server-Applications15-SP1-Pool SLE-Module-Server-Applications15-SP1-Updates SLE-Module-Basesystem15-SP1-Pool SLE-Module-Basesystem15-SP1-Updates SUSE-Enterprise-Storage-6-Pool SUSE-Enterprise-Storage-6-Updates
3. Congure los ajustes de red, incluida la resolución de nombre DNS adecuada encada 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 confi-gurar una red, consulte https://www.suse.com/documentation/sles-15/book_sle_admin/
data/sec_network_yast.html . Para obtener más información sobre cómo configurarun servidor DNS, consulte https://www.suse.com/documentation/sles-15/book_sle_admin/
data/cha_dns.html .
4. Seleccione uno o más servidores o repositorios de hora y sincronice la hora local conellos. Verique que el servicio de sincronización de hora está habilitado en cada inicio delsistema. Puede utilizar el comando yast ntp-client , que se encuentra en un paqueteyast2-ntp-client para configurar la sincronización de hora.
SugerenciaLas máquinas virtuales no son fuentes NTP de conanza.
Encontrará más información sobre la configuración de NTP en https://www.su-
se.com/documentation/sles-15/book_sle_admin/data/sec_ntp_yast.html .
5. 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 loestuviera, habilítelo e inícielo:
root@master # systemctl enable salt-master.service
34 Distribución del clúster SES 6
root@master # systemctl start salt-master.service
6. Si va a utilizar un cortafuegos, asegúrese de que el nodo master de Salt tiene los puertos4505 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.
Aviso: las fases de DeepSea fallan con un cortafuegosLas fases de distribución de DeepSea fallan si el cortafuegos está activo (e inclusosolo si está configurado). Para superar las fases correctamente, debe desactivar elcortafuegos ejecutando
root # systemctl stop firewalld.service
o denir el valor "False" (Falso) en la opción FAIL_ON_WARNING en /srv/pillar/ceph/stack/global.yml :
FAIL_ON_WARNING: False
7. 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 nombrede cada nodo en la dirección IP pública.
8. Congure todos los minions (incluido el minion master) para que se conecten con elprincipal. 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 elsiguiente contenido:
master: host_name_of_salt_master
Si realiza cambios en los archivos de configuración mencionados anteriormente, reinicieel servicio Salt en todos los minions de Salt:
root@minion > systemctl restart salt-minion.service
35 Distribución del clúster SES 6
9. Compruebe que el servicio salt-minion está habilitado e iniciado en todos los nodos.Habilítelo e inícielo si fuera necesario:
root # systemctl enable salt-minion.serviceroot # systemctl start salt-minion.service
10. Verique la huella digital de cada minion de Salt y acepte todas las claves salt del masterde Salt si las huellas coinciden.
NotaSi la huella digital del minion de Salt vuelve vacía, asegúrese de que el minion deSalt tenga una configuración de master de Salt y que pueda comunicarse con elmaster de Salt.
Para ver la huella digital de cada minion:
root@master # salt-call --local key.fingerlocal: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 huellasde todas las claves de minion no aceptadas del master de Salt:
root@master # salt-key -F[...]Unaccepted Keys:minion1:3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...
Si las huellas digitales de los minions coinciden, acéptelas:
root@master # salt-key --accept-all
11. Verique que las claves se han aceptado:
root@master # salt-key --list-all
12. Antes de distribuir SUSE Enterprise Storage 6, borre manualmente todos los discos. Noolvide sustituir la "X" con la letra de disco correcta:
a. Detenga todos los procesos que utilicen el disco especíco.
36 Distribución del clúster SES 6
b. Verique 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 infraestructurade LVM. Consulte https://www.suse.com/documentation/sles-15/book_storage/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-15/book_storage/data/part_soft-
ware_raid.html para obtener más información.
e. Sugerencia: rearranque del servidorSi recibe mensajes de error de tipo "la partición está en uso" o "el kernelno se puede actualizar con la nueva tabla de particiones" durante los pasossiguientes, rearranque el servidor.
Limpie el principio de cada partición (como usuario root ):
for partition in /dev/sdX[0-9]*do dd if=/dev/zero of=$partition bs=4096 count=1 oflag=directdone
f. Limpie el principio de la unidad:
root # dd if=/dev/zero of=/dev/sdX bs=512 count=34 oflag=direct
g. Limpie el nal de la unidad:
root # dd if=/dev/zero of=/dev/sdX bs=512 count=33 \ seek=$((`blockdev --getsz /dev/sdX` - 33)) oflag=direct
h. Verique que la unidad está vacía (sin estructuras GPT) con:
root # parted -s /dev/sdX print free
O bien
root # dd if=/dev/sdX bs=512 count=34 | hexdump -Croot # dd if=/dev/sdX bs=512 count=33 \ skip=$((`blockdev --getsz /dev/sdX` - 33)) | hexdump -C
37 Distribución del clúster SES 6
13. Opcionalmente, si necesita preconfigurar los valores de red del clúster antes de quese instale el paquete deepsea, cree manualmente /srv/pillar/ceph/stack/ceph/cluster.yml y dena las opciones cluster_network: y public_network: . Tenga encuenta que el archivo no se sobrescribirá después de instalar deepsea .
Sugerencia: habilitación de IPv6Si necesita habilitar el direccionamiento de red IPv6, consulte la Sección 7.2.1, “Habili-
tación de IPv6 para la distribución del clúster de Ceph”.
14. Instale DeepSea en el nodo master de Salt:
root@master # zypper in deepsea
15. El valor del parámetro master_minion se deriva dinámicamente del archivo /etc/salt/minion_id del master de Salt. Si necesita sustituir el valor descubierto, edite el archivo/srv/pillar/ceph/stack/global.yml y dena un valor relevante:
master_minion: MASTER_MINION_NAME
Si se puede acceder al master de Salt a través de otros nombres de host, utilice el nombredel minion de Salt que devuelve el comando salt-key -L para el clúster de almacena-miento. Si ha utilizado el nombre de host por defecto para el master de Salt (salt) en eldominio ses, el archivo tiene el aspecto siguiente:
master_minion: salt.ses
Ahora, distribuya y congure Ceph. A menos que se especifique lo contrario, todos los pasosson obligatorios.
Nota: convenciones de comandos de saltExisten dos maneras posibles de ejecutar salt-run state.orch : una es con"stage. NÚMERO_FASE ", la otra es con el nombre de la fase. Ambas notaciones tienen elmismo efecto y elegir un comando u otro es puramente preferencial.
38 Distribución del clúster SES 6
PROCEDIMIENTO 5.1: EJECUCIÓN DE FASES DE DISTRIBUCIÓN
1. Asegúrese de que los minions de Salt que pertenecen al clúster de Ceph estén correc-tamente asignados a un destino mediante la opción deepsea_minions de /srv/
pillar/ceph/deepsea_minions.sls . Consulte la Sección 5.2.2.3, “Definición de la opción
deepsea_minions” para obtener más información.
2. Por defecto, DeepSea distribuye clústeres de Ceph con perles ajustados activos en nodosde Ceph Monitor, Ceph Manager y Ceph OSD. En algunos casos, puede ser necesariodistribuir sin perles ajustados. Para ello, coloque las líneas siguientes en /srv/pillar/ceph/stack/global.yml antes de ejecutar las fases de DeepSea:
alternative_defaults: tuned_mgr_init: default-off tuned_mon_init: default-off tuned_osd_init: default-off
3. Opcional: cree subvolúmenes de Btrfs para /var/lib/ceph/ . Este paso debe ejecutarseantes de la fase 0 de DeepSea. Para migrar directorios existentes o para obtener másinformación, consulte Libro “Guía de administración”, Capítulo 25 “Consejos y sugerencias”,
Sección 25.6 “Subvolumen Btrfs para /var/lib/ceph en nodos de Ceph Monitor”.Aplique los comandos siguientes a cada uno de los minions de Salt:
root@master # salt 'MONITOR_NODES' saltutil.sync_allroot@master # salt 'MONITOR_NODES' state.apply ceph.subvolume
NotaEl comando Ceph.subvolume crea /var/lib/ceph como un subvolumen Btrfs de@/var/lib/ceph .
El nuevo subvolumen se monta ahora y /etc/fstab se actualiza.
4. Prepare el clúster. Consulte Descripción de las fases de DeepSea para obtener más infor-mación.
root@master # salt-run state.orch ceph.stage.0
O bien
root@master # salt-run state.orch ceph.stage.prep
39 Distribución del clúster SES 6
Nota: ejecución o supervisión de fases mediante la interfazde línea de comandos de DeepSeaCon la interfaz de línea de comandos de DeepSea puede realizar un seguimiento entiempo real del progreso de la ejecución de las fases, ya sea ejecutando la interfazen modo de supervisión, o bien ejecutando las fases directamente a través de dichainterfaz. Para obtener información detallada, consulte la Sección 5.4, “Interfaz de línea
de comandos de DeepSea”.
5. La fase de descubrimiento recopila datos de todos los minions y crea fragmentos de confi-guración que se almacenan en el directorio /srv/pillar/ceph/proposals . Los datos sealmacenan en formato de YAML en archivos *.sls o *.yml.Ejecute el comando siguiente para activar la fase de descubrimiento:
root@master # salt-run state.orch ceph.stage.1
O bien
root@master # salt-run state.orch ceph.stage.discovery
6. Después de que el comando anterior nalice correctamente, cree un archivo policy.cfgen /srv/pillar/ceph/proposals . Para obtener información detallada, consulte laSección 5.5.1, “El archivo policy.cfg”.
SugerenciaSi necesita cambiar la configuración de red del clúster, edite /srv/
pillar/ceph/stack/ceph/cluster.yml y ajuste las líneas que comienzan concluster_network: y public_network: .
7. La fase de configuración analiza el archivo policy.cfg y combina los archivos incluidosen 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 configuración:
root@master # salt-run state.orch ceph.stage.2
40 Distribución del clúster SES 6
O bien
root@master # salt-run state.orch ceph.stage.configure
El paso de configuración puede tardar varios segundos. Cuando nalice el comando,podrá ver los datos de Pillar de los minions especificados (por ejemplo, ceph_minion1 ,ceph_minion2 , etc.) ejecutando:
root@master # salt 'ceph_minion*' pillar.items
Sugerencia: modificación del diseño del OSDSi desea modicar el diseño por defecto del OSD y cambiar la configuración deDriveGroups, siga el procedimiento descrito en el Sección 5.5.2, “DriveGroups”.
Nota: sobrescritura de valores por defectoTan pronto como nalice el comando, puede ver la configuración por defecto ycambiarla para adaptarla a sus necesidades. Para obtener información detallada,consulte el Capítulo 7, Personalización de la configuración por defecto.
8. Ahora se ejecuta la fase de distribución. En esta fase, se valida el pilar y se inician losdaemons de Ceph Monitor y Ceph OSD:
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 elproblema y volver a ejecutar las fases anteriores. Cuando el comando se ejecute correcta-mente, ejecute lo siguiente para comprobar el estado:
cephadm@adm > ceph -s
41 Distribución del clúster SES 6
9. El último paso de la distribución del clúster de Ceph es la fase services. Aquí se crea unainstancia de cualquiera de los servicios admitidos actualmente: iSCSI Gateway, CephFS,Object Gateway y NFS Ganesha. En esta fase, se crean los repositorios necesarios, losanillos de claves de autorización y los servicios de inicio. Para iniciar la fase, ejecute losiguiente:
root@master # salt-run state.orch ceph.stage.4
O bien
root@master # salt-run state.orch ceph.stage.services
Según la configuración, puede que la ejecución del comando tarde varios minutos.
10. Antes de continuar, se recomienda habilitar el módulo de telemetría de Ceph. Paraobtener más información, consulte Libro “Guía de administración”, Capítulo 10 “Módulos de
Ceph Manager”, Sección 10.2 “Módulo de telemetría”.
5.4 Interfaz de línea de comandos de DeepSeaDeepSea también proporciona una interfaz de línea de comandos que permite al usuario super-visar o ejecutar fases mientras observa el progreso de la ejecución en tiempo real. Verique queel paquete deepsea-cli esté instalado antes de ejecutar el archivo ejecutable deepsea .
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 activadapor 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 tiemporeal de los pasos incluidos mientras se ejecutan.
Importante: comandos de la interfaz de línea de comandos deDeepSeaLos comandos de la interfaz de línea de comandos de DeepSea solo se pueden ejecutar enel nodo master de Salt con privilegios de usuario root .
42 Interfaz de línea de comandos de DeepSea SES 6
5.4.1 Interfaz de línea de comandos de DeepSea: modo demonitor
El monitor de progreso ofrece una visualización detallada en tiempo real de lo que sucededurante la ejecución de las fases. Para ello, usa los comandos salt-run state.orch de otrassesiones de terminal.
Sugerencia: inicio del monitor en una nueva sesión de terminalDebe iniciar el monitor en una ventana de terminal nueva antes de ejecutar cualquiercomando salt-run state.orch para que el monitor pueda detectar el inicio de laejecución de la fase.
Si inicia el monitor después de emitir el comando salt-run state.orch , no se mostrará ningúnprogreso 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 elcomando deepsea monitor , consulte su página man:
root@master # man deepsea-monitor
5.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 ejecutaruna 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 elformato 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 estadode 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 deDeepSea (o cualquier archivo de estado de organización de DeepSea).
43 Interfaz de línea de comandos de DeepSea: modo de monitor SES 6
El comando deepsea stage run ceph.stage.0 es equivalente a salt-run state.orchceph.stage.0 .
Para obtener más información sobre las opciones de línea de comandos disponibles aceptadaspor el comando deepsea stage run , consulte su página man:
root@master # man deepsea-stage run
En la ilustración siguiente se muestra un ejemplo de la interfaz de línea de comandos de DeepSeacuando se ejecuta Stage 2:
FIGURA 5.1: PANTALLA DE PROGRESO DE LA EJECUCIÓN DE FASE EN LA INTERFAZ DE LÍNEA DE COMANDOS DEDEEPSEA
44 Interfaz de línea de comandos de DeepSea: modo autónomo SES 6
5.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 DeepSeaque toma el comando de Salt que se usa para ejecutar una fase; por ejemplo, salt-runstate.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
5.5 Configuración y personalización
5.5.1 El archivo policy.cfg
El archivo de configuración /srv/pillar/ceph/proposals/policy.cfg se utiliza para deter-minar las funciones de los nodos de clúster individuales. Por ejemplo, qué nodos actúan comodaemons de Ceph OSD o como monitores Ceph Monitor. Edite policy.cfg para reejar laconfiguración de clúster que desee. El orden de las secciones es arbitrario, pero el contenido delas líneas incluidas sobrescribe las claves que coincidan con el contenido de las líneas anteriores.
Sugerencia: ejemplos de policy.cfgEncontrará varios ejemplos de archivos de directiva completos en el directorio /usr/share/doc/packages/deepsea/examples/ .
5.5.1.1 Asignación de clúster
En la sección cluster, se seleccionan los minions para el clúster. Puede seleccionar todos losminions o crear una lista negra o una lista blanca de minions. A continuación, se muestranejemplos 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
45 Configuración y personalización SES 6
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
5.5.1.2 Asignación de funciones
En esta sección se proporciona información sobre cómo asignar "funciones" a los nodos delclúster. En este contexto, una función es el servicio que se debe ejecutar en el nodo, como CephMonitor, Object Gateway o iSCSI Gateway. Ninguna función se asigna automáticamente y sololas 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 significado y los valores siguientes:
ROLE_NAME es uno de los siguientes elementos: "master", "admin", "mon", "mgr", "storage","mds", "igw", "rgw", "ganesha", "grafana" o "prometheus".
PATH es una vía relativa a los archivos .sls o .yml. En el caso de los archivos .sls, normal-mente 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 configu-ració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íficos.
46 El archivo policy.cfg SES 6
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 obliga-toria, 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 denir lafunción de la siguiente forma:
role-admin/cluster/abc*.sls
mon: el minion proporcionará el servicio de monitor al clúster de Ceph. Esta funciónrequiere 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 el pilarde Salt.
role-mon/cluster/mon*.sls
El ejemplo asigna la función de monitor a un grupo de minions.
mgr: el daemon de Ceph Manager que recopila toda la información de estado de todo elclúster. Distribúyalo en todos los minions en los que tenga previsto distribuir la funciónde monitor de Ceph.
role-mgr/cluster/mgr*.sls
storage: use esta función para especificar nodos de almacenamiento.
role-storage/cluster/data*.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 direccionesde los minions asignados, así que debe incluir también los archivos del directorio stack :
role-igw/cluster/*.sls
47 El archivo policy.cfg SES 6
rgw: el minion actuará como pasarela Object Gateway:
role-rgw/cluster/rgw*.sls
ganesha: el minion actuará como servidor de NFS Ganesha. La función "ganesha" requiereque la función "rgw" o "mds" esté en el clúster, o de lo contrario fallará la validación enla fase 3.
role-ganesha/cluster/ganesha*.sls
Para instalar correctamente NFS Ganesha, se requiere configuración adicional. Si deseautilizar NFS Ganesha, lea el Capítulo 12, Instalación de NFS Ganesha antes de ejecutar las fases2 y 4. Sin embargo, es posible instalar NFS Ganesha más adelante.En algunas ocasiones, puede ser útil denir funciones personalizadas para nodos de NFSGanesha. Para obtener información, consulte: Libro “Guía de administración”, Capítulo 21 “NFS
Ganesha: exportación de datos de Ceph a través de NFS”, Sección 21.3 “Funciones personalizadas
de NFS Ganesha”.
grafana, prometheus: este nodo añade grácos de Grafana basados en Prometheusque aportan información a la Ceph Dashboard. Consulte Libro “Guía de administración”,
Capítulo 22 “Ceph Dashboard” para obtener su descripción detallada.
role-grafana/cluster/grafana*.sls
role-prometheus/cluster/prometheus*.sls
Nota: varias funciones de nodos del clústerPuede asignar varias funciones a un único nodo. Por ejemplo, puede asignar las funciones"mds" a los nodos de monitor:
role-mds/cluster/mon[1,2]*.sls
48 El archivo policy.cfg SES 6
5.5.1.3 Configuración común
La sección de configuración común incluye archivos de configuración generados durante eldescubrimiento (fase 1). Estos archivos de configuración almacenan parámetros como fsid opublic_network . Para incluir la configuración común de Ceph necesaria, añada las líneassiguientes:
config/stack/default/global.ymlconfig/stack/default/ceph/cluster.yml
5.5.1.4 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 avanzadasEn esta sección se describen técnicas de ltrado para usuarios avanzados. Si no se utilizacorrectamente, el ltrado puede causar problemas, por ejemplo en caso de cambios denumeración del nodo.
slice=[start:end]
Utilice el ltro slice para incluir solo los elementos desde start hasta end-1. Tenga en cuentaque los elementos del directorio indicado se ordenan alfanuméricamente. La línea siguienteincluye del tercer al quinto archivo del subdirectorio role-mon/cluster/ :
role-mon/cluster/*.sls slice[3:6]
re=regexp
Utilice el ltro de expresión regular para incluir solo los elementos que coincidan con lasexpresiones indicadas. Por ejemplo:
role-mon/cluster/mon*.sls re=.*1[135]\.subdomainX\.sls$
5.5.1.5 Archivo policy.cfg de ejemplo
A continuación se muestra un ejemplo de un archivo policy.cfg básico:
## Cluster Assignment
49 El archivo policy.cfg SES 6
cluster-ceph/cluster/*.sls 1
## Roles# ADMINrole-master/cluster/examplesesadmin.sls 2
role-admin/cluster/sesclient*.sls 3
# MONrole-mon/cluster/ses-example-[123].sls 4
# MGRrole-mgr/cluster/ses-example-[123].sls 5
# STORAGErole-storage/cluster/ses-example-[5,6,7,8].sls 6
# MDSrole-mds/cluster/ses-example-4.sls 7
# IGWrole-igw/cluster/ses-example-4.sls 8
# RGWrole-rgw/cluster/ses-example-4.sls 9
# COMMONconfig/stack/default/global.yml 10
config/stack/default/ceph/cluster.yml 11
1 Indica que todos los minions están incluidos en el clúster de Ceph. Si tiene minions que nodesea incluir en el clúster de Ceph, utilice:
cluster-unassigned/cluster/*.slscluster-ceph/cluster/ses-example-*.sls
La primera línea marca todos los minions como no asignados. La segunda línea anula losminions 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, estosignica 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 adminis-tració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 configurarán como nodos MON.
50 El archivo policy.cfg SES 6
5 Todos los minions que coincidan con "ses-example-[123]" (todos los nodos MON delejemplo) se configurarán como nodos MGR.
6 Todos los minions que coincidan con "ses-example-[5,6,7,8]" se configurarán como nodosde almacenamiento.
7 El minion "ses-example-4" tendrá la función de servidor de metadatos.
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 Signica que se aceptan los valores por defecto para los parámetros de configuracióncomunes, como fsid y public_network .
11 Signica que se aceptan los valores por defecto para los parámetros de configuracióncomunes, como fsid y public_network .
5.5.2 DriveGroups
DriveGroups especica los diseños de los OSD del clúster de Ceph. Se denen en un único archivo/srv/salt/ceph/configuration/files/drive_groups.yml .
Un administrador debe especificar manualmente un grupo de OSD que estén interrelacionados(OSD híbridos que se distribuyen en unidades de estado sólido y giratorias) o que compartan lasmismas opciones de distribución (deben ser idénticas, por ejemplo, el mismo almacén de objetos,la misma opción de cifrado y varios OSD independientes). Para no tener que mostrar explícita-mente los dispositivos, DriveGroups utiliza una lista de elementos de ltro que corresponden aalgunos campos seleccionados de los informes de inventario de ceph-volume . En el caso mássimple, podría tratarse del indicador "rotational" (todas las unidades de estado sólido debenser dispositivos DB y todas las unidades giratorias deben ser dispositivos de datos) o algo másespecíco, como cadenas de tipo "modelo" o tamaños. DeepSea proporciona código que traduceestos DriveGroups en listas de dispositivos reales para que el usuario las pueda inspeccionar.
A continuación se muestra un procedimiento sencillo que muestra el ujo de trabajo básico paraconfigurar DriveGroups:
1. Inspeccione cómo se muestran las propiedades de los discos con el comando ceph-volume . DriveGroups solo acepta estas propiedades:
root@master # salt-run disks.details
51 DriveGroups SES 6
2. Abra el archivo YAML /srv/salt/ceph/configuration/files/drive_groups.yml yajústelo según sus necesidades. Consulte la Sección 5.5.2.1, “Especificación”. Recuerde usarespacios en lugar de tabuladores. Encontrará ejemplos más avanzados en la Sección 5.5.2.4,
“Ejemplos”. En el ejemplo siguiente se incluyen todas las unidades disponibles para Cephcomo OSDs:
default_drive_group_name: target: '*' data_devices: all: true
3. Verique los nuevos diseños:
root@master # salt-run disks.list
Este runner devuelve una estructura de discos que coinciden basada en DriveGroups. Sino le satisface el resultado, repita el paso anterior.
Sugerencia: informe detalladoAdemás del runner disks.list , hay un runner disks.report que muestra uninforme detallado de lo que sucederá en la próxima invocación de la fase 3 deDeepSea.
root@master # salt-run disks.report
4. Distribuya los OSD. En la siguiente invocación de la fase 3 de DeepSea, los discos OSD sedistribuirán de acuerdo con las especificaciones del grupo de unidades.
5.5.2.1 Especificación
/srv/salt/ceph/configuration/files/drive_groups.yml acepta las siguientes opciones:
drive_group_default_name: target: * data_devices: drive_spec: DEVICE_SPECIFICATION db_devices: drive_spec: DEVICE_SPECIFICATION wal_devices:
52 DriveGroups SES 6
drive_spec: DEVICE_SPECIFICATION block_wal_size: '5G' # (optional, unit suffixes permitted) block_db_size: '5G' # (optional, unit suffixes permitted) osds_per_device: 1 # number of osd daemons per device format: # 'bluestore' or 'filestore' (defaults to 'bluestore') encryption: # 'True' or 'False' (defaults to 'False')
Para las configuraciones de FileStore, drive_groups.yml puede tener este aspecto:
drive_group_default_name: target: * data_devices: drive_spec: DEVICE_SPECIFICATION journal_devices: drive_spec: DEVICE_SPECIFICATION format: filestore encryption: True
5.5.2.2 Dispositivos de disco que coinciden
Puede describir la especificación utilizando los ltros siguientes:
Por modelo del disco:
model: DISK_MODEL_STRING
Por proveedor del disco:
vendor: DISK_VENDOR_STRING
Sugerencia: cadena de proveedor en minúsculasUse siempre minúsculas para DISK_VENDOR_STRING .
Indica si un disco es giratorio o no. Las unidades SSD y NVME no son giratorias.
rotational: 0
Distribuya un nodo utilizando todas las unidades disponibles para los OSD:
data_devices:
53 DriveGroups SES 6
all: true
También puede limitar el número de discos que coinciden:
limit: 10
5.5.2.3 Filtrado de dispositivos por tamaño
Es posible ltrar los dispositivos de disco por su tamaño, ya sea por un tamaño exacto o por unintervalo de tamaños. El parámetro size: acepta argumentos con el formato siguiente:
'10G': incluye discos de un tamaño exacto.
'10G:40G': incluye discos cuyo tamaño está dentro del intervalo indicado.
':10G': incluye discos de 10 GB o menos.
'40G:': incluye discos de 40 GB o más.
EJEMPLO 5.1: COINCIDENCIA POR TAMAÑO DE DISCO
drive_group_default: target: '*' data_devices: size: '40TB:' db_devices: size: ':2TB'
Nota: comillas obligatoriasSi se usa el delimitador ":", debe incluir el tamaño entre comillas simples, de lo contrarioel signo ":" se interpretará como un nuevo hash de configuración.
Sugerencia: accesos directos a unidadesEn lugar de (G)igabytes, también puede especificar los tamaños en (M)egabytes o en(T)erabytes.
5.5.2.4 Ejemplos
Esta sección incluye ejemplos de diferentes configuraciones de OSD.
54 DriveGroups SES 6
EJEMPLO 5.2: CONFIGURACIÓN SENCILLA
Este ejemplo describe dos nodos con la misma configuración:
20 discos duros
Proveedor: Intel
Modelo: SSD-123-foo
Tamaño: 4 TB
2 discos SSD
Proveedor: Micron
Modelo: MC-55-44-ZX
Tamaño: 512 GB
El archivo drive_groups.yml correspondiente será el siguiente:
drive_group_default: target: '*' data_devices: model: SSD-123-foo db_devices: model: MC-55-44-XZ
Esta configuración es sencilla y válida. El problema es que un administrador puede añadirdiscos de diferentes proveedores en el futuro, y estos no se incluirán. Puede mejorarlareduciendo los ltros en las propiedades principales de las unidades:
drive_group_default: target: '*' data_devices: rotational: 1 db_devices: rotational: 0
En el ejemplo anterior, estamos imponiendo que se declaren todos los dispositivosgiratorios como "dispositivos de datos" y todos los dispositivos no giratorios se utilizaráncomo "dispositivos compartidos" (wal, db).
Si sabe que las unidades de más de 2 TB siempre serán los dispositivos de datos más lentos,puede ltrar por tamaño:
drive_group_default:
55 DriveGroups SES 6
target: '*' data_devices: size: '2TB:' db_devices: size: ':2TB'
EJEMPLO 5.3: CONFIGURACIÓN AVANZADA
En este ejemplo se describen dos configuraciones distintas: 20 discos duros debencompartir 2 unidades SSD, mientras que 10 unidades SSD deben compartir 2 NVMe.
20 discos duros
Proveedor: Intel
Modelo: SSD-123-foo
Tamaño: 4 TB
12 discos SSD
Proveedor: Micron
Modelo: MC-55-44-ZX
Tamaño: 512 GB
2 NVMe
Proveedor: Samsung
Modelo: NVME-QQQQ-987
Tamaño: 256 GB
Esta configuración se puede denir con dos diseños de la siguiente manera:
drive_group: target: '*' data_devices: rotational: 0 db_devices: model: MC-55-44-XZ
drive_group_default: target: '*'
56 DriveGroups SES 6
data_devices: model: MC-55-44-XZ db_devices: vendor: samsung size: 256GB
EJEMPLO 5.4: CONFIGURACIÓN AVANZADA CON NODOS NO UNIFORMES
En los ejemplos anteriores se suponía que todos los nodos tienen las mismas unidades. Sinembargo, eso no siempre es así:
Nodos 1-5:
20 discos duros
Proveedor: Intel
Modelo: SSD-123-foo
Tamaño: 4 TB
2 discos SSD
Proveedor: Micron
Modelo: MC-55-44-ZX
Tamaño: 512 GB
Nodos 6-10:
5 NVMe
Proveedor: Intel
Modelo: SSD-123-foo
Tamaño: 4 TB
20 discos SSD
Proveedor: Micron
Modelo: MC-55-44-ZX
Tamaño: 512 GB
57 DriveGroups SES 6
Puede utilizar la clave "target" en el diseño para asignar nodos específicos a un destino.La notación del destino de Salt ayuda a simplificar las cosas:
drive_group_node_one_to_five: target: 'node[1-5]' data_devices: rotational: 1 db_devices: rotational: 0
seguido de
drive_group_the_rest: target: 'node[6-10]' data_devices: model: MC-55-44-XZ db_devices: model: SSD-123-foo
EJEMPLO 5.5: CONFIGURACIÓN PARA EXPERTOS
En todos los casos anteriores se presuponía que los WAL y DB usaban el mismo dispositivo.Sin embargo, también es posible distribuir el WAL en un dispositivo dedicado:
20 discos duros
Proveedor: Intel
Modelo: SSD-123-foo
Tamaño: 4 TB
2 discos SSD
Proveedor: Micron
Modelo: MC-55-44-ZX
Tamaño: 512 GB
2 NVMe
Proveedor: Samsung
Modelo: NVME-QQQQ-987
Tamaño: 256 GB
58 DriveGroups SES 6
drive_group_default: target: '*' data_devices: model: MC-55-44-XZ db_devices: model: SSD-123-foo wal_devices: model: NVME-QQQQ-987
EJEMPLO 5.6: CONFIGURACIÓN COMPLEJA (E IMPROBABLE)
En la siguiente configuración, tratamos de denir lo siguiente:
20 discos duros respaldados por 1 NVMe
2 discos duros respaldados por 1 SSD (db) y 1 NVMe (wal)
8 discos SSD respaldados por 1 NVMe
2 discos SSD independientes (cifrados)
1 disco duro es de repuesto y no debe distribuirse
El resumen de las unidades usadas es el siguiente:
23 discos duros
Proveedor: Intel
Modelo: SSD-123-foo
Tamaño: 4 TB
10 discos SSD
Proveedor: Micron
Modelo: MC-55-44-ZX
Tamaño: 512 GB
1 NVMe
Proveedor: Samsung
Modelo: NVME-QQQQ-987
Tamaño: 256 GB
59 DriveGroups SES 6
La denición de DriveGroups será la siguiente:
drive_group_hdd_nvme: target: '*' data_devices: rotational: 0 db_devices: model: NVME-QQQQ-987
drive_group_hdd_ssd_nvme: target: '*' data_devices: rotational: 0 db_devices: model: MC-55-44-XZ wal_devices: model: NVME-QQQQ-987
drive_group_ssd_nvme: target: '*' data_devices: model: SSD-123-foo db_devices: model: NVME-QQQQ-987
drive_group_ssd_standalone_encrypted: target: '*' data_devices: model: SSD-123-foo encryption: True
Se conservará un disco duro porque el archivo se está analizando de arriba abajo.
5.5.3 Ajuste de ceph.conf con valores personalizados
Si es necesario establecer valores personalizados en el archivo de configuración ceph.conf ,consulte el Libro “Guía de administración”, Capítulo 2 “Administración de un clúster de Salt”, Sección 2.13
“Ajuste de ceph.conf con valores personalizados” para obtener más detalles.
60 Ajuste de ceph.conf con valores personalizados SES 6
6 Actualización desde versiones anteriores
En este capítulo se presentan los pasos necesarios para actualizar SUSE Enterprise Storage 5.5a la versión 6. Tenga en cuenta que la versión 5.5 es básicamente la 5 con todos los parchesmás recientes aplicados.
Nota: actualización desde versiones anteriores no admitidasNo se admite la actualización desde versiones de SUSE Enterprise Storage anteriores ala 5.5. En primer lugar, debe actualizar a la versión más reciente de SUSE EnterpriseStorage 5.5 y, a continuación, siga los pasos de este capítulo.
6.1 Puntos que se deben tener en cuenta antes de laactualización
Lea las notas de la versión. En ellas encontrará información adicional sobre los cambiosrealizados desde la versión previa de SUSE Enterprise Storage. Consulte las notas de versiónpara comprobar lo siguiente:
si el hardware necesita consideraciones especiales,
si los paquetes de software usados han cambiado de forma significativa,
si es necesario tomar precauciones especiales para la instalación.
Las notas de la versión también proporcionan información que no pudo publicarse en elmanual a tiempo y notas acerca de problemas conocidos.Después de instalar el paquete release-notes-ses , encontrará las notas de la versión enel directorio /usr/share/doc/release-notes o en línea en https://www.suse.com/relea-
senotes/ .
En caso de que haya actualizado previamente desde la versión 4, compruebe que la actua-lización a la versión 5 se haya completado correctamente:
Compruebe que el archivo exista:
/srv/salt/ceph/configuration/files/ceph.conf.import
61 Puntos que se deben tener en cuenta antes de la actualización SES 6
Es creado por el proceso de importación durante la actualización de SES 4 a SES 5.Además, la opción configuration_init: default-import se dene en el archivo
/srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml
Si configuration_init todavía está denido como default-import , el clústerestá utilizando ceph.conf.import como su archivo de configuración y no el archivoceph.conf por defecto de DeepSea que se compila a partir de los archivos de:
/srv/salt/ceph/configuration/files/ceph.conf.d/
Por lo tanto, debe inspeccionar si hay alguna configuración personalizada enceph.conf.import y, posiblemente, trasladar la configuración a uno de los archivosde:
/srv/salt/ceph/configuration/files/ceph.conf.d/
A continuación, elimine la línea configuration_init: default‑import de:
/srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml
Aviso: configuración por defecto de DeepSeaSi no combina la configuración de ceph.conf.import y elimina laopción configuration_init: default‑import , no se aplicará al clústerningún valor de configuración por defecto que hayamos enviado comoparte de DeepSea (almacenado en /srv/salt/ceph/configuration/files/ceph.conf.j2 ).
Compruebe si el clúster utiliza el nuevo tipo de depósito "straw2":
cephadm@adm > ceph osd crush dump | grep straw
Compruebe que se utiliza el perl de Ceph "jewel":
cephadm@adm > ceph osd crush dump | grep profile
62 Puntos que se deben tener en cuenta antes de la actualización SES 6
En caso de que se utilicen clientes de kernel del RBD antiguos (anteriores a SUSE LinuxEnterprise Server 12 SP3), consulte Libro “Guía de administración”, Capítulo 12 “Dispositivo
de bloques RADOS”, Sección 12.9 “Asignación del RBD utilizando clientes de kernel antiguos”. Serecomienda actualizar los clientes del kernel del RBD antiguo, si es posible.
Si openATTIC se encuentra en el nodo de administración, no estará disponible después deactualizar el nodo. La nueva Ceph Dashboard no estará disponible hasta que la distribuyamediante DeepSea.
La actualización del clúster puede tardar mucho tiempo, aproximadamente el que se tardaen actualizar un equipo multiplicado por el número de nodos del clúster.
No es posible actualizar un solo nodo mientras se ejecuta la versión anterior de SUSE LinuxEnterprise Server: debe reiniciarse en el programa de instalación de la nueva versión. Por lotanto, los servicios que proporciona el nodo no estarán disponibles durante un tiempo. Losservicios de clúster principales seguirán estando disponibles; por ejemplo, si una instanciade MON está inactiva durante la actualización, seguirá habiendo al menos dos activas.Desafortunadamente, los servicios de una sola instancia, como una única pasarela iSCSIGateway, no estarán disponibles.
Algunos tipos de daemons dependen de otros. Por ejemplo, los daemons de Object Gatewaydependen de los daemons de Ceph MON y OSD. Se recomienda actualizar en este orden:
1. Nodo de administración
2. Ceph Monitor/Ceph Manager
3. Servidores de metadatos
4. Daemons Ceph OSD
5. Pasarelas Object Gateway
6. Pasarelas iSCSI Gateway
7. NFS Ganesha
8. Pasarelas Samba Gateway
Si ha usado AppArmor en el modo "complain" o "enforce", debe establecer una variablede pilar de Salt antes de actualizar. Dado que SUSE Linux Enterprise Server 15 SP1 sesuministra con AppArmor por defecto, la gestión de AppArmor se ha integrado en la fase 0
63 Puntos que se deben tener en cuenta antes de la actualización SES 6
de DeepSea. El comportamiento por defecto en SUSE Enterprise Storage 6 es eliminarAppArmor y los perles relacionados. Si desea conservar el comportamiento configuradoen SUSE Enterprise Storage 5.5, compruebe que haya una de las siguientes líneas presenteen el archivo /srv/pillar/ceph/stack/global.yml antes de iniciar la actualización:
apparmor_init: default-enforce
O bien
apparmor_init: default-complain
Desde SUSE Enterprise Storage 6, los nombres del MDS que comienzan con un dígito yano se permiten y los daemons del MDS no se iniciarán. Puede comprobar si los daemonstienen este tipo de nombre ejecutando el comando ceph fs status o reiniciando un MDSy buscando en sus registros el siguiente mensaje:
deprecation warning: MDS id 'mds.1mon1' is invalid and will be forbidden ina future version. MDS names may not start with a numeric digit.
Si ve el mensaje anterior, los nombres del MDS deben migrarse antes de intentar actualizara SUSE Enterprise Storage 6. DeepSea proporciona orquestación para automatizar dichamigración. A los nombres del MDS que comiencen con un dígito se les añadirá "mds." alprincipio:
root@master # salt-run state.orch ceph.mds.migrate-numerical-names
Sugerencia: configuración personalizada vinculada anombres del MDSSi tiene valores de configuración vinculados a nombres del MDS y los daemonsdel MDS tienen nombres que comienzan con un dígito, verique que los valoresde configuración también se aplique a los nuevos nombres (con el prejo "mds." ).Observe la siguiente sección de ejemplo del archivo /etc/ceph/ceph.conf :
[mds.123-my-mds] # config setting specific to MDS name with a name starting with a digitmds cache memory limit = 1073741824mds standby for name = 456-another-mds
64 Puntos que se deben tener en cuenta antes de la actualización SES 6
El orquestador ceph.mds.migrate-numerical-names cambiará el nombre deldaemon del MDS "123-my-mds" a "mds.123-my-mds". Es necesario ajustar la confi-guración para reejar el nuevo nombre:
[mds.mds,123-my-mds] # config setting specific to MDS name with the new namemds cache memory limit = 1073741824mds standby for name = mds.456-another-mds
Esto añadirá daemons del MDS con los nuevos nombres antes de eliminar los antiguos. Elnúmero de daemons del MDS se duplicará durante un breve periodo de tiempo. Los clientespodrán acceder a CephFS tras una breve pausa para el failover. Por lo tanto, planifique lamigración en horas en las que espere poca o ninguna carga de CephFS.
6.2 Copia de seguridad de los datos del clústerAunque la creación de copias de seguridad de la configuración y los datos de un clúster no esobligatoria, se recomienda encarecidamente realizarla. Consulte Libro “Guía de administración”,
Capítulo 3 “Copia de seguridad de la configuración y los datos del clúster” para obtener más infor-mación.
6.3 Migración de ntpd a chronydSUSE Linux Enterprise Server 15 SP1 ya no utiliza ntpd para sincronizar la hora del host local.En su lugar, se utiliza chronyd . Debe migrar el daemon de sincronización de hora en cadanodo del clúster. Puede migrar a chronyd antes que el clúster o actualizar el clúster y migrara chronyd después.
PROCEDIMIENTO 6.1: MIGRACIÓN A chronyd ANTES DE LA ACTUALIZACIÓN DEL CLÚSTER
1. Instale el paquete chrony:
root@minion > zypper install chrony
2. Edite el archivo de configuración chronyd /etc/chrony.conf y añada orígenes NTPdesde la configuración ntpd actual en /etc/ntp.conf .
65 Copia de seguridad de los datos del clúster SES 6
Sugerencia: más detalles sobre la configuración dechronydEn https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-ntp.html encon-trará más detalles sobre cómo incluir las fuentes de hora en la configuración dechronyd .
3. Inhabilite y detenga el servicio ntpd :
root@minion > systemctl disable ntpd.service && systemctl stop ntpd.service
4. Inicie y habilite el servicio chronyd :
root@minion > systemctl start chronyd.service && systemctl enable chronyd.service
5. Verique el estado de chrony:
root@minion > chronyc tracking
PROCEDIMIENTO 6.2: MIGRACIÓN A chronyd DESPUÉS DE LA ACTUALIZACIÓN DEL CLÚSTER
1. Durante la actualización del clúster, añada los siguientes repositorios de software:
SLE-Module-Legacy15-SP1-Pool
SLE-Module-Legacy15-SP1-Updates
2. Actualice el clúster a la versión 6.
3. Edite el archivo de configuración chronyd /etc/chrony.conf y añada orígenes NTPdesde la configuración ntpd actual en /etc/ntp.conf .
Sugerencia: más detalles sobre la configuración dechronydEn https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-ntp.html encon-trará más detalles sobre cómo incluir las fuentes de hora en la configuración dechronyd .
66 Migración de ntpd a chronyd SES 6
4. Inhabilite y detenga el servicio ntpd :
root@minion > systemctl disable ntpd.service && systemctl stop ntpd.service
5. Inicie y habilite el servicio chronyd :
root@minion > systemctl start chronyd.service && systemctl enable chronyd.service
6. Migre de ntpd a chronyd .
7. Verique el estado de chrony:
root@minion > chronyc tracking
8. Elimine los repositorios de software heredados que agregó para mantener ntpd en elsistema durante el proceso de actualización.
6.4 Aplicación de parches al clúster antes de laactualizaciónAplique los parches más recientes a todos los nodos del clúster antes de la actualización.
6.4.1 Repositorios de software requeridos
Compruebe que los repositorios necesarios están configurados en todos los nodos del clúster.Para mostrar todos los repositorios disponibles, ejecute:
root@minion > zypper lr
SUSE Enterprise Storage 5.5 requiere:
SLES12-SP3-Installer-Updates
SLES12-SP3-Pool
SLES12-SP3-Updates
SUSE-Enterprise-Storage-5-Pool
SUSE-Enterprise-Storage-5-Updates
67 Aplicación de parches al clúster antes de la actualización SES 6
NFS/SMB Gateway en SLE-HA en SUSE Linux Enterprise Server 12 SP3 requiere lo siguiente:
SLE-HA12-SP3-Pool
SLE-HA12-SP3-Updates
6.4.2 Sistemas de fases de repositorio
Si utiliza un sistemas de fases de repositorio (SMT, RMT o SUSE Manager), cree un nuevo nivelde parche inmovilizado para la versión actual y la versión nueva de SUSE Enterprise Storage.
Encontrará más información en:
https://www.suse.com/documentation/sles-12/book_smt/data/book_smt.html ,
https://www.suse.com/documentation/sles-15/book_rmt/data/book_rmt.html ,
https://www.suse.com/documentation/suse-manager-3/index.html .
6.4.3 Aplicación de los parches más recientes a todo el clúster
1. Aplique los parches más recientes de SUSE Enterprise Storage 5.5 y SUSE Linux EnterpriseServer 12 SP3 a todos los nodos del clúster de Ceph. Verique que se han conectadolos repositorios de software correctos a cada nodo del clúster (consulte la Sección 6.4.1,
“Repositorios de software requeridos”) y ejecute la fase 0 de DeepSea:
root@master # salt-run state.orch ceph.stage.0
2. Después de completar la fase 0, verique que el estado de cada nodo del clúster incluya"HEALTH_OK". Si no es así, resuelva el problema antes de que se produzcan los posiblesreinicios en los pasos siguientes.
3. Ejecute zypper ps para comprobar si hay procesos que podría ejecutar con bibliotecaso archivos binarios obsoletos y reinicie si los hay.
4. Verique que el kernel en ejecución es el último disponible y reinicie si no lo es.Compruebe el resultado de los siguientes comandos:
cephadm@adm > uname -acephadm@adm > rpm -qa kernel-default
68 Sistemas de fases de repositorio SES 6
5. Verique que el paquete ceph es de la versión 12.2.12 o posterior. Verique que elpaquete deepsea es de la versión 0.8.9 o posterior.
6. Si anteriormente usó cualquier valor de bluestore_cache , tenga en cuenta que noestán en vigor desde la versión 12.2.10 de Ceph. El nuevo ajuste bluestore_cache_au-totune , que se dene por defecto como "true", inhabilita el cambio de tamaño manualdel caché. Para activar el comportamiento anterior, debe denir bluestore_cache_au-totune=false . Consulte Libro “Guía de administración”, Capítulo 16 “Configuración del clúster
de Ceph”, Sección 16.2.1 “Tamaño automático de caché” para obtener más detalles.
6.5 Verificación del entorno actual
Si el sistema tiene problemas evidentes, soluciónelos antes de iniciar la actualización. Laactualización nunca soluciona los problemas existentes del sistema.
Compruebe el rendimiento del clúster. Puede utilizar comandos como rados bench , cephtell osd.* bench o iperf3 .
Compruebe el acceso a las pasarelas (como iSCSI Gateway o Object Gateway) y al dispo-sitivos de bloques RADOS.
Tome documentación sobre las partes específicas de la configuración del sistema, como laconfiguración de red, la partición o los detalles de la instalación.
Utilice supportconfig para recopilar información importante del sistemay guardarla fuera de los nodos del clúster. Encontrará más infor-mación en https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_adm-
support_supportconfig.html .
Asegúrese de que haya suciente espacio libre en disco en cada nodo del clúster.Compruebe el espacio libre en disco con df -h . Cuando sea necesario, libere espacio endisco eliminando archivos o directorios innecesarios o eliminando instantáneas obsoletasdel sistema operativo. Si no hay suciente espacio libre en disco, no continúe con la actua-lización hasta que haya liberado suciente.
69 Verificación del entorno actual SES 6
6.6 Comprobación del estado del clúster
Compruebe el comando cluster health antes de iniciar el procedimiento de actuali-zación. No inicie la actualización a menos que todos los nodos del clúster notiquen elestado "HEALTH_OK".
Verique que todos los servicios se estén ejecutando:
El master de Salt y los daemons del master de Salt.
Los daemons de Ceph Monitor y Ceph Manager.
Los daemons del servidor de metadatos.
Los daemons de Ceph OSD.
Los daemons de Object Gateway.
Los daemons de iSCSI Gateway.
Los comandos siguientes proporcionan detalles sobre el estado del clúster y la configuraciónespecíca:
ceph -s
Muestra un breve resumen del estado del clúster de Ceph, los servicios en ejecución, eluso de datos y las estadísticas de E/S. Verique que notica el estado "HEALTH_OK" antesde iniciar la actualización.
ceph health detail
Muestra detalles si el estado del clúster de Ceph no es correcto.
ceph versions
Muestra las versiones de los daemons de Ceph en ejecución.
ceph df
Muestra el espacio en disco total y libre del clúster. No inicie la actualización si el espaciolibre en disco del clúster es inferior al 25 % del espacio total en disco.
salt '*' cephprocesses.check results=true
Muestra los procesos de Ceph y en ejecución sus PID ordenados por minion de Salt.
ceph osd dump | grep ^flags
70 Comprobación del estado del clúster SES 6
Verique que los indicadores "recovery_deletes" y "purged_snapdirs" estén presentes. Si noes así, puede aplicar un borrado seguro de todos los grupos de colocación ejecutando elcomando siguiente. Tenga en cuenta que este borrado seguro impuesto posiblemente afectede forma negativa al rendimiento de los clientes de Ceph.
cephadm@adm > ceph pg dump pgs_brief | cut -d " " -f 1 | xargs -n1 ceph pg scrub
6.7 Actualización sin conexión de los clústeres CTDBCTDB proporciona una base de datos en clúster que se utiliza en las pasarelas Samba Gateway.El protocolo CTDB es muy sencillo y no admite clústeres de nodos que se comuniquen conversiones distintas del protocolo. Por lo tanto, los nodos CTDB deben desconectarse antes derealizar una actualización.
6.8 Actualización por nodo: procedimiento básicoPara asegurarse de que los servicios principales del clúster están disponibles durante la actuali-zación, debe actualizar los nodos del clúster secuencialmente uno por uno. Hay dos formas derealizar la actualización de un nodo: mediante el DVD del instalador o mediante el sistema demigración de distribución.
Después de actualizar cada nodo, se recomienda ejecutar rpmconfigcheck para comprobar sihay archivos de configuración actualizados que se hayan editado localmente. Si el comandodevuelve una lista de nombres de archivo con el sujo .rpmnew , .rpmorig o .rpmsave ,compare estos archivos con los archivos de configuración actuales para asegurarse de queno se ha perdido ningún cambio local. Si fuera necesario, actualice los archivos afectados.Para obtener más información sobre cómo trabajar con archivos .rpmnew , .rpmorig y.rpmsave , consulte https://documentation.suse.com/sles/15-SP1/single-html/SLES-admin/#sec-
rpm-packages-manage .
Sugerencia: paquetes huérfanosDespués de actualizar un nodo, varios paquetes estarán en estado "huérfano" sin un reposi-torio padre. Esto sucede porque los paquetes relacionados con python3 no hacen que lospaquetes python2 queden obsoletos.
71 Actualización sin conexión de los clústeres CTDB SES 6
Encontrará más información sobre cómo mostrar los paqueteshuérfanos en https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_zyp-
per.html#sec_zypper_softup_orphaned .
6.8.1 Actualización manual de nodo mediante el DVD delinstalador
1. Reinicie el nodo desde el DVD o la imagen del instalador de SUSE Linux EnterpriseServer 15 SP1.
2. Seleccione Actualizar en el menú de arranque.
3. En la pantalla Seleccionar el destino de migración, verique que "SUSE Linux EnterpriseServer 15 SP1" esté seleccionado y marque la casilla Ajustar manualmente los repositoriospara la migración.
FIGURA 6.1: SELECCIONAR EL DESTINO DE MIGRACIÓN
4. Seleccione los siguientes módulos para instalarlos:
SUSE Enterprise Storage 6 x86_64
Basesystem Module 15 SP1 x86_64
72 Actualización manual de nodo mediante el DVD del instalador SES 6
Desktop Applications Module 15 SP1 x86_64
Legacy Module 15 SP1 x86_64
Server Applications Module 15 SP1 x86_64
5. En la pantalla Repositorios usados anteriormente, verique que estén seleccionados losrepositorios correctos. Si el sistema no está registrado con SCC/SMT, debe añadir losrepositorios manualmente.SUSE Enterprise Storage 6 requiere:
SLE-Module-Basesystem15-SP1-Pool
SLE-Module-Basesystem15-SP1-Updates
SLE-Module-Server-Applications15-SP1-Pool
SLE-Module-Server-Applications15-SP1-Updates
SLE-Module-Desktop-Applications15-SP1-Pool
SLE-Module-Desktop-Applications15-SP1-Updates
SLE-Product-SLES15-SP1-Pool
SLE-Product-SLES15-SP1-Updates
SLE15-SP1-Installer-Updates
SUSE-Enterprise-Storage-6-Pool
SUSE-Enterprise-Storage-6-Updates
Si tiene previsto migrar ntpd a chronyd después de la migración de SES (consulte laSección 6.3, “Migración de ntpd a chronyd”), incluya los siguientes repositorios:
SLE-Module-Legacy15-SP1-Pool
SLE-Module-Legacy15-SP1-Updates
73 Actualización manual de nodo mediante el DVD del instalador SES 6
NFS/SMB Gateway en SLE-HA en SUSE Linux Enterprise Server 15 SP1 requiere losiguiente:
SLE-Product-HA15-SP1-Pool
SLE-Product-HA15-SP1-Updates
6. Revise los valores de instalación e inicie el procedimiento de instalación haciendo clic enActualizar.
6.8.2 Actualización de nodos con el sistema de migración dedistribución de SUSE
El sistema de migración de distribución (DMS, por su siglas en inglés) proporciona una vía deactualización de una versión principal a otra para los sistemas SUSE Linux Enterprise insta-lados. El siguiente procedimiento utiliza el DMS para actualizar SUSE Enterprise Storage 5.5 ala versión 6, incluida la migración subyacente de SUSE Linux Enterprise Server 12 SP3 a SUSELinux Enterprise Server 15 SP1.
Consulte en https://documentation.suse.com/suse-distribution-migration-system/1.0/single-html/
distribution-migration-system/ la información general y detallada sobre el DMS.
1. Instale los paquetes RPM de migración. Sirven para ajustar el cargador de arranque GRUBa n de activar automáticamente la actualización en el siguiente reinicio. Instale lospaquetes SLES15-SES-Migration y suse-migration-sle15-activation :
root@minion > zypper install SLES15-SES-Migration suse-migration-sle15-activation
2. a. Si el nodo que se está actualizando está registrado con un sistema de fases de reposi-torio como SCC, SMT, RMT o SUSE Manager, cree /etc/sle-migration-servi-ce.yml con el siguiente contenido:
use_zypper_migration: truepreserve: rules: - /etc/udev/rules.d/70-persistent-net.rules
74 Actualización de nodos con el sistema de migración de distribución de SUSE SES 6
b. Si el nodo que se está actualizando no está registrado con un sistema de fases derepositorio como SCC, SMT, RMT o SUSE Manager, realice los siguientes cambios:
i. Cree /etc/sle-migration-service.yml con el siguiente contenido:
use_zypper_migration: falsepreserve: rules: - /etc/udev/rules.d/70-persistent-net.rules
ii. Inhabilite o elimine los repositorios SLE 12 SP3 y SES 5 y añada los reposi-torios SLE 15 SP1 y SES6. Encontrará la lista de repositorios relacionados en laSección 6.4.1, “Repositorios de software requeridos”.
3. Reinicie para iniciar la actualización. Mientras se ejecuta la actualización, puedeentrar a la sesión en el nodo actualizado a través de ssh como usuariode migración utilizando la clave SSH existente del sistema host como sedescribe en https://documentation.suse.com/suse-distribution-migration-system/1.0/single-
html/distribution-migration-system/ . Para SUSE Enterprise Storage, si tiene acceso físicoo acceso directo de consola al equipo, también puede entrar a la sesión como usuario rooten la consola del sistema con la contraseña sesupgrade . El nodo se reiniciará automáti-camente después de la actualización.
Sugerencia: fallo de actualizaciónSi se produce un error en la actualización, inspeccione el registro /var/log/distro_migration.log . Solucione el problema, vuelva a instalar los paquetesRPM de migración y reinicie el nodo.
6.9 Actualización del nodo de administración
Los siguientes comandos seguirán funcionando, aunque los minions de Salt estén ejecu-tando versiones antiguas de Ceph y Salt: salt '*' test.ping y ceph status
Después de actualizar el nodo de administración, openATTIC ya no se instalará.
75 Actualización del nodo de administración SES 6
Si el nodo de administración alojaba SMT, complete su migración a RMT (consulte https://
www.suse.com/documentation/sles-15/book_rmt/data/cha_rmt_migrate.html ).
Utilice el procedimiento descrito en la Sección 6.8, “Actualización por nodo: procedi-
miento básico”.
Sugerencia: estado de los nodos de clústerDespués de actualizar el nodo de administración, puede ejecutar el comando salt-runupgrade.status para obtener información útil sobre los nodos del clúster. El comandomuestra las versiones de Ceph y del OS de todos los nodos y recomienda el orden en elque se deberán actualizar los nodos que todavía ejecuten versiones antiguas.
root@master # salt-run upgrade.statusThe newest installed software versions are: ceph: ceph version 14.2.1-468-g994fd9e0cc (994fd9e0ccc50c2f3a55a3b7a3d4e0ba74786d50) nautilus (stable) os: SUSE Linux Enterprise Server 15 SP1
Nodes running these software versions: admin.ceph (assigned roles: master) mon2.ceph (assigned roles: admin, mon, mgr)
Nodes running older software versions must be upgraded in the following order: 1: mon1.ceph (assigned roles: admin, mon, mgr) 2: mon3.ceph (assigned roles: admin, mon, mgr) 3: data1.ceph (assigned roles: storage)[...]
76 Actualización del nodo de administración SES 6
6.10 Actualización de nodos de Ceph Monitor/CephManager
Si el clúster no utiliza funciones del MDS, actualice los nodos MON/MGR uno por uno.
Si el clúster utiliza funciones del MDS y las funciones MON/MGR y MDS se recolocan deforma automática, debe reducir el tamaño del clúster del MDS y, a continuación, actualizarlos nodos recolocados. Consulte la Sección 6.11, “Actualización de servidores de metadatos” paraobtener más información.
Si el clúster utiliza funciones del MDS y se ejecutan en servidores dedicados, actualicetodos los nodos MON/MGR uno por uno, reduzca el tamaño del clúster del MDS y actua-lícelo. Consulte la Sección 6.11, “Actualización de servidores de metadatos” para obtener másinformación.
Nota: actualización de Ceph MonitorDebido a una limitación en el diseño de Ceph Monitor, una vez que se han actualizado dosMON a SUSE Enterprise Storage 6 y se ha formado un quórum, el tercer MON (mientrassigue en SUSE Enterprise Storage 5.5) no se reincorporará al clúster de MON si se reiniciapor cualquier motivo, incluso si se reinicia el nodo. Por lo tanto, si se han actualizado dosMON, es mejor actualizar el resto tan pronto como sea posible.
Utilice el procedimiento descrito en la Sección 6.8, “Actualización por nodo: procedimiento
básico”.
6.11 Actualización de servidores de metadatosDebe reducir el tamaño del clúster del servidor de metadatos (MDS). Dado que hay caracterís-ticas incompatibles entre las versiones 5.5 y 6 de SUSE Enterprise Storage, los daemons del MDSanteriores se apagarán tan pronto como vean a un solo MDS de nivel SES 6 unirse al clúster. Porlo tanto, es necesario reducir el tamaño del clúster del MDS a un solo MDS activo (y sin esperas)durante todo el proceso de actualización de los nodos del MDS. Tan pronto como se actualiceel segundo nodo, podrá ampliar de nuevo el clúster del MDS.
77 Actualización de nodos de Ceph Monitor/Ceph Manager SES 6
SugerenciaEn un clúster del MDS con carga muy elevada, es posible que deba reducir la carga (porejemplo, deteniendo clientes) para que un único MDS activo pueda controlarla.
1. Anote el valor actual de la opción max_mds :
cephadm@adm > ceph fs get cephfs | grep max_mds
2. Reduzca el tamaño del clúster del MDS si tiene más de 1 daemon del MDS activo, es decir,si max_mds es > 1. Para reducir el tamaño del clúster del MDS, ejecute:
cephadm@adm > ceph fs set FS_NAME max_mds 1
donde FS_NAME es el nombre de la instancia de CephFS ("cephfs" por defecto).
3. Busque el nodo donde se aloja uno de los daemons del MDS en espera. Consulte el resultadodel comando ceph fs status e inicie la actualización del clúster del MDS en este nodo.
cephadm@adm > ceph fs statuscephfs - 2 clients======+------+--------+--------+---------------+-------+-------+| Rank | State | MDS | Activity | dns | inos |+------+--------+--------+---------------+-------+-------+| 0 | active | mon1-6 | Reqs: 0 /s | 13 | 16 |+------+--------+--------+---------------+-------+-------++-----------------+----------+-------+-------+| Pool | type | used | avail |+-----------------+----------+-------+-------+| cephfs_metadata | metadata | 2688k | 96.8G || cephfs_data | data | 0 | 96.8G |+-----------------+----------+-------+-------++-------------+| Standby MDS |+-------------+| mon3-6 || mon2-6 |+-------------+
En este ejemplo, necesita iniciar el procedimiento de actualización en el nodo "mon3-6"o en el "mon2-6".
78 Actualización de servidores de metadatos SES 6
4. Actualice el nodo con el daemon en espera del MDS. Después de que se inicie el nodo actua-lizado del MDS, los daemons obsoletos del MDS se apagarán automáticamente. En estemomento, los clientes pueden experimentar un breve tiempo de inactividad del servicioCephFS.Utilice el procedimiento descrito en la Sección 6.8, “Actualización por nodo: procedi-
miento básico”.
5. Actualice los nodos restantes del MDS.
6. Restablezca la configuración deseada en max_mds :
cephadm@adm > ceph fs set FS_NAME max_mds ACTIVE_MDS_COUNT
6.12 Actualización de los OSD CephSiga estos pasos para cada nodo de almacenamiento:
1. Identifique qué daemons del OSD se ejecutan en un nodo determinado:
cephadm@osd > ceph osd tree
2. Establezca el indicador "noout" para cada daemon del OSD del nodo que se está actuali-zando:
cephadm@osd > ceph osd add-noout osd.OSD_ID
Por ejemplo:
cephadm@osd > for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd add-noout osd.$i; done
Verifíquelo con:
cephadm@osd > ceph health detail | grep noout
O bien
cephadm@osd > ceph –scluster: id: 44442296-033b-3275-a803-345337dc53da health: HEALTH_WARN
79 Actualización de los OSD Ceph SES 6
6 OSDs or CRUSH {nodes, device-classes} have {NOUP,NODOWN,NOIN,NOOUT} flags set
3. Cree archivos /etc/ceph/osd/*.json para todos los OSD existentes ejecutando elsiguiente comando en el nodo que se va a actualizar:
cephadm@osd > ceph-volume simple scan --force
4. Actualice el nodo del OSD. Utilice el procedimiento descrito en la Sección 6.8, “Actua-
lización por nodo: procedimiento básico”.
5. Active todos los OSD que se encuentran en el sistema:
cephadm@osd > ;ceph-volume simple activate --all
Sugerencia: activación individual de particiones de datosSi desea activar las particiones de datos individualmente, debe encontrar elcomando ceph-volume correcto de cada partición para activarla. Sustituya X1 porla letra o número correcto de la partición:
cephadm@osd > ceph-volume simple scan /dev/sdX1
Por ejemplo:
cephadm@osd > ceph-volume simple scan /dev/vdb1[...]--> OSD 8 got scanned and metadata persisted to file:/etc/ceph/osd/8-d7bd2685-5b92-4074-8161-30d146cd0290.json--> To take over management of this scanned OSD, and disable ceph-diskand udev, run:--> ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290
La última línea del resultado contiene el comando para activar la partición:
cephadm@osd > ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290[...]--> All ceph-disk systemd units have been disabled to prevent OSDsgetting triggered by UDEV events[...]Running command: /bin/systemctl start ceph-osd@8--> Successfully activated OSD 8 with FSID
80 Actualización de los OSD Ceph SES 6
d7bd2685-5b92-4074-8161-30d146cd0290
6. Verique que el nodo del OSD se inicia correctamente después del reinicio.
7. Fíjese en el mensaje "Legacy BlueStore stats reporting detected on XX OSD(s)" (Se handetectado informes de estadísticas de BlueStore heredados en XX OSD):
cephadm@osd > ceph –scluster: id: 44442296-033b-3275-a803-345337dc53da health: HEALTH_WARN Legacy BlueStore stats reporting detected on 6 OSD(s)
La advertencia es normal al actualizar Ceph a la versión 14.2.2. Puede desactivarla confi-gurando lo siguiente:
bluestore_warn_on_legacy_statfs = false
La solución adecuada es ejecutar el siguiente comando en todos los OSD mientras estándetenidos:
cephadm@osd > ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-XXX
A continuación se muestra un guion auxiliar que ejecuta ceph-bluestore-tool repairpara todos los OSD del nodo NODE_NAME :
OSDNODE=OSD_NODE_NAME;\ for OSD in $(ceph osd ls-tree $OSDNODE);\ do echo "osd=" $OSD;\ salt $OSDNODE cmd.run 'systemctl stop ceph-osd@$OSD';\ salt $OSDNODE cmd.run 'ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-$OSD';\ salt $OSDNODE cmd.run 'systemctl start ceph-osd@$OSD';\ done
8. Desactive el indicador "noout" en cada daemon del OSD del nodo que se actualiza:
cephadm@osd > ceph osd rm-noout osd.OSD_ID
Por ejemplo:
cephadm@osd > for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd rm-noout osd.$i; done
81 Actualización de los OSD Ceph SES 6
Verifíquelo con:
cephadm@osd > ceph health detail | grep noout
Nota:
cephadm@osd > ceph –scluster: id: 44442296-033b-3275-a803-345337dc53da health: HEALTH_WARN Legacy BlueStore stats reporting detected on 6 OSD(s)
9. verique el estado del clúster. Mostrará un aspecto similar al siguiente:
cephadm@osd > ceph statuscluster: id: e0d53d64-6812-3dfe-8b72-fd454a6dcf12 health: HEALTH_WARN 3 monitors have not enabled msgr2
services: mon: 3 daemons, quorum mon1,mon2,mon3 (age 2h) mgr: mon2(active, since 22m), standbys: mon1, mon3 osd: 30 osds: 30 up, 30 in
data: pools: 1 pools, 1024 pgs objects: 0 objects, 0 B usage: 31 GiB used, 566 GiB / 597 GiB avail pgs: 1024 active+clean
10. Compruebe que todos los nodos del OSD se han reiniciado y que los OSD se han iniciadoautomáticamente después del reinicio.
6.13 Migración de OSDs a BlueStoreOSD BlueStore es un nuevo back-end para los daemons del OSD. Es la opción por defectodesde SUSE Enterprise Storage 5. En comparación con FileStore, que almacena los objetos comoarchivos en un sistema de archivos XFS, BlueStore puede ofrecer un mayor rendimiento debidoa que almacena los objetos directamente en el dispositivo de bloques subyacente. BlueStoretambién permite otras funciones, como la compresión integrada y la sobrescritura de codifi-cación de borrado, que no están disponibles con FileStore.
82 Migración de OSDs a BlueStore SES 6
Específicamente 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 datosRocksDB almacena los metadatos de un OSD BlueStore. Estos dos dispositivos se encuentran pordefecto en el mismo dispositivo que un OSD, pero cualquiera de ellos se puede colocar en otrolugar, por ejemplo en un medio más rápido.
En SUSE Enterprise Storage 5, se admite tanto FileStore como BlueStore y es posible que ambossistemas coexistan en un mismo clúster. Durante el procedimiento de actualización de SUSEEnterprise Storage, los OSD de FileStore no se convierten automáticamente a BlueStore. Tengaen cuenta que las funciones específicas de BlueStore no estarán disponibles en los OSD que nose hayan migrado a BlueStore.
Antes de convertirlos a BlueStore, los OSD deben disponer ya de SUSE Enterprise Storage enejecució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 ningunainterrupció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 dela 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 seguridadLos comandos de Salt necesarios para ejecutar la migración se bloquean por motivos deseguridad. Para desactivar estas medidas de seguridad, ejecute el siguiente comando:
root@master # salt-run disengage.safety
Reconstruya los nodos antes de continuar:
root@master # salt-run rebuild.node TARGET
También puede reconstruir cada nodo individualmente. Por ejemplo:
root@master # salt-run rebuild.node data1.ceph
El comando rebuild.node siempre elimina y vuelve a crear todos los OSD del nodo.
83 Migración de OSDs a BlueStore SES 6
ImportanteSi un OSD no se puede convertir, al volver a ejecutar la reconstrucción se destruyenlos BlueStore OSD ya convertidos. En lugar de volver a ejecutar la reconstrucción,puede ejecutar:
root@master # salt-run disks.deploy TARGET
Después de la migración a BlueStore, el recuento de objetos seguirá siendo el mismo y el usode disco será prácticamente igual.
6.14 Actualización de nodos de aplicaciónActualice los nodos de aplicación en el siguiente orden:
1. Pasarelas Object Gateway
Si las pasarelas Object Gateway están respaldadas por un equilibrador de carga,debería de ser posible realizar una actualización gradual de las pasarelas sin interrup-ciones.
Compruebe que los daemons de Object Gateway se están ejecutando después de cadaactualización y pruebe con el cliente S3/Swift.
Utilice el procedimiento descrito en la Sección 6.8, “Actualización por nodo: proce-
dimiento básico”.
2. Pasarelas iSCSI Gateway
84 Actualización de nodos de aplicación SES 6
Si los iniciadores iSCSI están configurados con múltiples rutas, debería de ser posiblerealizar una actualización gradual de las pasarelas iSCSI Gateway sin que hayainterrupciones.
Compruebe que el daemon lrbd se está ejecutando después de cada actualizacióny pruebe con el iniciador.
Utilice el procedimiento descrito en la Sección 6.8, “Actualización por nodo: proce-
dimiento básico”.
3. NFS Ganesha. Utilice el procedimiento descrito en la Sección 6.8, “Actualización por
nodo: procedimiento básico”.
4. Pasarelas Samba Gateway. Utilice el procedimiento descrito en la Sección 6.8, “Actuali-
zación por nodo: procedimiento básico”.
6.15 Actualización de policy.cfg y distribución deCeph Dashboard con DeepSeaEn el nodo de administración, edite /srv/pillar/ceph/proposals/policy.cfg y aplique lossiguientes cambios:
Importante: sin nuevos serviciosDurante la actualización del clúster, no añada nuevos servicios al archivo policy.cfg .Cambie la arquitectura del clúster solo después de completar la actualización.
1. Elimine role-openattic .
2. Añada role-prometheus y role-grafana al nodo que tenía instalados Prometheus yGrafana; normalmente se trata del nodo de administración.
3. Ahora se ignora la función profile‑NOMBRE_PERFIL . Añada la nueva función correspon-diente en la línea role-storage . Por ejemplo, para
profile-default/cluster/*.sls
añada
85 Actualización de policy.cfg y distribución de Ceph Dashboard con DeepSea SES 6
role-storage/cluster/*.sls
4. Sincronice todos los módulos de Salt:
root@master # salt '*' saltutil.sync_all
5. Actualice el pilar de Salt ejecutando las fases 1 y 2 de DeepSea:
root@master # salt-run state.orch ceph.stage.1root@master # salt-run state.orch ceph.stage.2
6. Limpie openATTIC:
root@master # salt OA_MINION state.apply ceph.rescind.openatticroot@master # salt OA_MINION state.apply ceph.remove.openattic
7. Desactive el grain "restart_igw" para evitar que la fase 0 reinicie iSCSI Gateway, que aúnno se ha instalado:
Salt mastersalt '*' grains.delkey restart_igw
8. Por último, ejecute las fases 0 a 4 de DeepSea:
root@master # salt-run state.orch ceph.stage.0root@master # salt-run state.orch ceph.stage.1root@master # salt-run state.orch ceph.stage.2root@master # salt-run state.orch ceph.stage.3root@master # salt-run state.orch ceph.stage.4
Sugerencia: errores de "falta un subvolumen" durante lafase 3La fase 3 de DeepSea puede fallar con un error similar al siguiente:
subvolume : ['/var/lib/ceph subvolume missing on 4510-2', \'/var/lib/ceph subvolume missing on 4510-1', \[...]'See /srv/salt/ceph/subvolume/README.md']
En tal caso, debe editar /srv/pillar/ceph/stack/global.yml y añadir lasiguiente línea:
subvolume_init: disabled
86 Actualización de policy.cfg y distribución de Ceph Dashboard con DeepSea SES 6
A continuación, actualice el pilar de Salt y vuelva a ejecutar la fase 3 de DeepSea:
root@master # salt '*' saltutil.refresh_pillar root@master # salt-run state.orch ceph.stage.3
Después de que DeepSea haya completado correctamente la fase 3, la CephDashboard se estará ejecutando. Consulte Libro “Guía de administración”, Capítulo 22
“Ceph Dashboard” para obtener una descripción detallada de las funciones de CephDashboard.
Para mostrar los nodos en los que se ejecuta la consola, ejecute:
cephadm@adm > ceph mgr services | grep dashboard
Para mostrar las credenciales de administrador, ejecute:
root@master # salt-call grains.get dashboard_creds
9. Reinicie secuencialmente los servicios de Object Gateway para utilizar el servidor Web"beast" en lugar del servidor "civetweb" obsoleto:
root@master # salt-run state.orch ceph.restart.rgw.force
10. Antes de continuar, se recomienda habilitar el módulo de telemetría de Ceph. Paraobtener más información, consulte Libro “Guía de administración”, Capítulo 10 “Módulos de
Ceph Manager”, Sección 10.2 “Módulo de telemetría”.
6.16 Migración de distribuciones basadas en perfilesa DriveGroupsEn SUSE Enterprise Storage 5.5, DeepSea ofrecía los llamados "perles" para describir el diseñode los OSD. A partir de SUSE Enterprise Storage 6, hemos pasado a un enfoque diferentedenominado DriveGroups (encontrará más detalles en la Sección 5.5.2, “DriveGroups”).
87 Migración de distribuciones basadas en perfiles a DriveGroups SES 6
NotaLa migración al nuevo enfoque no es obligatoria de inmediato. Las operaciones destruc-tivas como salt‑run osd.remove , salt‑run osd.replace o salt‑run osd.purge siguen estando disponibles. Sin embargo, para añadir nuevos OSD se requerirá su inter-vención.
Debido al diferente enfoque de estas implementaciones, no se ofrece una vía de migraciónautomatizada. Sin embargo, se ofrecen varias herramientas (runners de Salt) para que lamigración sea lo más sencilla posible.
6.16.1 Análisis del diseño actual
Para ver información sobre los OSD distribuidos actualmente, utilice el siguiente comando:
root@master # salt-run disks.discover
Como alternativa, puede inspeccionar el contenido de los archivos en los directorios /srv/pillar/ceph/proposals/profile-*/ . Tienen una estructura similar a la siguiente:
ceph: storage: osds: /dev/disk/by-id/scsi-drive_name: format: bluestore /dev/disk/by-id/scsi-drive_name2: format: bluestore
6.16.2 Creación de DriveGroups que coincidan con el diseño actual
Consulte la Sección 5.5.2.1, “Especificación” para obtener más información sobre la especificaciónDriveGroups.
La diferencia entre una distribución nueva y una actualización es que las unidades que se vana migrar ya están "utilizadas". Dado que
root@master # salt-run disks.list
solo busca discos no utilizados, use:
root@master # salt-run disks.list include_unavailable=True
88 Análisis del diseño actual SES 6
Ajuste DriveGroups hasta que coincida con la configuración actual. Para obtener una represen-tación más visual de lo que sucederá, utilice el siguiente comando. Tenga en cuenta que nohabrá resultado alguno si no hay discos libres:
root@master # salt-run disks.report bypass_pillar=True
Si ha vericado que DriveGroups está configurado correctamente y desea aplicar elnuevo enfoque, elimine los archivos del directorio /srv/pillar/ceph/proposals/profile-NOMBRE_PERFIL/ , elimine las líneas profile‑NOMBRE_PERFIL/cluster/*.sls correspon-dientes del archivo del archivo /srv/pillar/ceph/proposals/policy.cfg y ejecute la fase 2de DeepSea para actualizar el pilar de Salt.
root@master # salt-run state.orch ceph.stage.2
Verique el resultado ejecutando los siguientes comandos:
root@master # salt target_node pillar.get ceph:storageroot@master # salt-run disks.report
Aviso: configuración incorrecta de DriveGroupsSi DriveGroups no está configurado correctamente y hay discos de repuesto en la confi-guración, se distribuirán de la forma en que los especicó. Se recomienda ejecutar losiguiente:
root@master # salt-run disks.report
6.16.3 Distribución de OSD
En los casos sencillos, como con un OSD independiente, la migración se realizará progresiva-mente. Cada vez que elimine o sustituya un OSD del clúster, se sustituirá por un nuevo basadoen LVM.
Sugerencia: migración al formato LVMCada vez que un único OSD "heredado" necesita reemplazarse en un nodo, todos los OSDque comparten dispositivos con él deberán migrarse al formato basado en LVM.
Para no dejarse ninguno, lo mejor es migrar los OSD de todo el nodo.
89 Distribución de OSD SES 6
6.16.4 Configuraciones más complejas
Si tiene una configuración más sofisticada (no solo OSD independientes), por ejemplo, WAL/DB dedicados o OSD cifrados, la migración solo puede producirse cuando se hayan eliminadotodos los OSD asignados a ese dispositivo WAL/DB. Esto se debe al comando ceph-volume ,que crea volúmenes lógicos en los discos antes de la distribución. Se evita así que el usuariomezcle distribuciones basadas en particiones con distribuciones basadas en volúmenes lógicos.En tales casos, es mejor eliminar manualmente todos los OSD asignados a un dispositivo WAL/DB y volver a distribuirlos mediante el enfoque DriveGroups.
90 Configuraciones más complejas SES 6
7 Personalización de la configuración por defecto
Es posible cambiar la configuración por defecto del clúster generada en la fase 2 (consulteDescripción de las fases de DeepSea). Por ejemplo, quizás sea necesario cambiar los valores dered o el software que se instala en el nodo de administración por defecto. Lo primero se puedellevar a cabo modificando la versión actualizada de Pillar después de la fase 2, mientras que losegundo 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 configuración personalizadosEn esta sección se muestran varias tareas para las que es necesario añadir o cambiar un archivosls propio. Normalmente, tal procedimiento se utiliza si es preciso cambiar el proceso de distri-bución por defecto.
Sugerencia: prefijo para los archivos .sls personalizadosLos archivos personalizados .sls se encuentran en el mismo subdirectorio que losarchivos .sls de DeepSea. Para evitar que se sobrescriban con los que se añadan despuésa partir del paquete de DeepSea, añada el prejo 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
91 Uso de archivos de configuración personalizados SES 6
3. Para vericar, actualice Pillar y ejecute el paso:
root@master # salt target saltutil.pillar_refreshroot@master # salt 'admin.ceph' state.apply ceph.timeadmin.ceph: Name: disable time setting - Function: test.nop - Result: Clean
Summary for admin.ceph------------Succeeded: 1Failed: 0------------Total states run: 1
Nota: ID exclusivoEl ID de tarea "disable time setting" (inhabilitar valor de hora) puede ser cualquiermensaje único dentro de un archivo sls . Cómo evitar conictos de ID especifi-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
92 Sustitución de un paso de la distribución SES 6
- 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 estadoHEALTH_ERR . En las instalaciones nuevas, un clúster de Ceph puede tener este estadohasta que haya un número suciente de OSD disponibles y haya terminado la creaciónde los repositorios.
2 El comando rbd no es idempotente. Si se vuelve a ejecutar el mismo comando decreación cuando la imagen exista, se producirá un error en el estado de Salt. Ladeclaració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íneasiguiente y guardarlo:
pool_init: custom
3. Para vericar, actualice Pillar y ejecute el paso:
root@master # salt target saltutil.pillar_refreshroot@master # salt 'admin.ceph' state.apply ceph.pool
Nota: autorizaciónLa creación de repositorios o imágenes requiere disponer de autorización suciente. Elminion admin.ceph dispone de un anillo de claves de administración.
Sugerencia: alternativaOtra 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 Pillarpara otros minions.
93 Sustitución de un paso de la distribución SES 6
7.1.3 Modificació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 modicar el archivo de estado relacionado, ya que complicaría una futuraactualización. En su lugar, para llevar a cabo las tareas adicionales cree un archivo independienteidé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ágenesrbd 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 prioridadEn este ejemplo, Salt va a crear las imágenes archive y la imagen demo. El ordenno importa en este ejemplo. Para cambiar el orden, invierta las líneas después dela directiva include: .
Puede añadir la línea include directamente en archive.sls y, así, se crearán todaslas 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 comportamientopuede anularse con las declaraciones requires y order, al usar un archivo indepen-diente que incluya a los demás se garantiza el orden y se reducen las posibilidadesde que haya confusiones.
2. Edite /srv/pillar/ceph/stack/ceph/cluster.yml , añada la línea siguiente yguárdelo:
pool_init: custom
3. Para vericar, actualice Pillar y ejecute el paso:
root@master # salt target saltutil.pillar_refreshroot@master # salt 'admin.ceph' state.apply ceph.pool
94 Modificación de un paso de la distribución SES 6
7.1.4 Modificación de una fase de la distribución
Si necesita añadir un paso de distribución completamente independiente, cree tres archivosnuevos: un archivo sls para ejecutar el comando, un archivo de organización y un archivopersonalizado 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 depreparació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. Verique 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 yguárdelo:
logrotate: salt.state: - tgt: '*' - sls: ceph.logrotate
2. Verique 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: - .logrotate
95 Modificación de una fase de la distribución SES 6
- .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 preere el archivo global.yml en lugar del archivo cluster.yml porque durantela fase prep ningún minion pertenece al clúster de Ceph y este no tiene acceso a ningunode los valores de cluster.yml .
7.1.5 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 sobrelas fase de DeepSea), el master y los minions de Salt pueden reiniciarse opcionalmente debidoa los paquetes recién actualizados, por ejemplo kernel , requiere que se reinicie el sistema.
El comportamiento por defecto es instalar las nuevas actualizaciones disponibles y no reiniciarlos nodos incluso en caso de actualizaciones del kernel.
Es posible cambiar el comportamiento de actualización/reinicio por defecto de la fase 0 deDeepSea añadiendo o cambiando las opciones stage_prep_master y stage_prep_minion enel archivo /srv/pillar/ceph/stack/global.yml . _prep_master dene el comportamientode la fase del master Salt y stage_prep_minion dene el comportamiento de todos los minions.Los parámetros disponibles son los siguientes:
default
Instalar las actualizaciones sin reiniciar.
default-update-reboot
Instalar las actualizaciones y reiniciar después de la actualización.
default-no-update-reboot
Reiniciar sin instalar las actualizaciones.
96 Actualizaciones y reinicios durante la fase 0 SES 6
default-no-update-no-reboot
No instalar las actualizaciones ni reiniciar.
Por ejemplo, para evitar que los nodos del clúster instalen actualizaciones y reinicien, edite /srv/pillar/ceph/stack/global.yml y añada las líneas siguientes:
stage_prep_master: default-no-update-no-rebootstage_prep_minion: default-no-update-no-reboot
Sugerencia: valores y archivos correspondientesLos valores de stage_prep_master corresponden a los nombres de archivo ubicados en/srv/salt/ceph/stage/0/master , mientras que los valores de stage_prep_minioncorresponden a archivos de /srv/salt/ceph/stage/0/minion :
root@master # ls -l /srv/salt/ceph/stage/0/masterdefault-no-update-no-reboot.slsdefault-no-update-reboot.slsdefault-update-reboot.sls[...]
root@master # ls -l /srv/salt/ceph/stage/0/miniondefault-no-update-no-reboot.slsdefault-no-update-reboot.slsdefault-update-reboot.sls[...]
7.2 Modificación de la configuración descubiertaDespués de completada la fase 2, puede ser necesario cambiar la configuración descubierta. Paraver los valores actuales, ejecute:
root@master # salt target pillar.items
El resultado de la configuración por defecto para un único minion es normalmente similar alsiguiente:
---------- available_roles: - admin
97 Modificación de la configuración descubierta SES 6
- 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 public_address: 172.16.21.11 public_network: 172.16.21.0/24 roles: - admin - mon - mds time_server: admin.ceph time_service: ntp
98 Modificación de la configuración descubierta SES 6
Los valores mencionados anteriormente están distribuidos en varios archivos de configuración.La estructura de directorio con estos archivos se dene 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ústerde Salt.
/srv/pillar/ceph/stack/ceph/cluster.yml : el archivo afecta a todos los minions delclúster de Ceph denominado ceph .
/srv/pillar/ceph/stack/ceph/roles/función.yml : afecta a todos los minions quetienen asignada la función especíca en el clúster ceph .
/srv/pillar/ceph/stack/cephminions/ID_DE_MINION/yml : afecta a ese minion parti-cular.
Nota: sobrescritura de directorios con los valores por defectoHay un árbol de directorios paralelo donde se almacena la configuración por defecto en/srv/pillar/ceph/stack/default . No cambie los valores aquí presentes, ya que sesobrescriben.
El procedimiento habitual para cambiar la configuración recopilada es el siguiente:
1. Busque la ubicación del elemento de configuración que debe cambiar. Por ejemplo, sinecesita cambiar los valores relacionados con el clúster, como la red del clúster, edite elarchivo /srv/pillar/ceph/stack/ceph/cluster.yml .
2. Guarde el archivo.
3. Para vericar los cambios, ejecute:
root@master # salt target saltutil.pillar_refresh
y a continuación:
root@master # salt target pillar.items
99 Modificación de la configuración descubierta SES 6
7.2.1 Habilitación de IPv6 para la distribución del clúster de Ceph
Puesto que el direccionamiento de red IPv4 es prevalente, debe habilitar IPv6 como una perso-nalización. DeepSea no cuenta con detección automática de direccionamiento IPv6.
Para configurar IPv6, dena las variables public_network y cluster_network del archivo /srv/pillar/ceph/stack/global.yml en subredes IPv6 válidas. Por ejemplo:
public_network: fd00:10::/64cluster_network: fd00:11::/64
A continuación, ejecute la fase 2 de DeepSea y verique que la información de red coincide conla configuración. La fase 3 generará ceph.conf con los indicadores necesarios.
Importante: sin compatibilidad con pila dualCeph no admite la pila dual: no es posible ejecutar Ceph simultáneamente en IPv4 e IPv6.La validación de DeepSea rechazará que haya una discordancia entre public_networky cluster_network o dentro de cualquiera de las variables. En el ejemplo siguiente seproducirá un error de validación.
public_network: "192.168.10.0/24 fd00:10::/64"
Sugerencia: evite el uso de direcciones fe80::/10 link-localProcure no usar direcciones fe80::/10 link-local . Todas las interfaces de red tienenuna dirección fe80 asignada y requieren un calificador de interfaz para el enrutamientoadecuado. Asigne direcciones IPv6 asignadas al sitio o utilice direcciones fd00::/8 . Sonparte de ULA y no se pueden enrutar globalmente.
100 Habilitación de IPv6 para la distribución del clúster de Ceph SES 6
III Instalación de servicios adicionales
8 Instalación de servicios para acceder a los datos 102
9 Ceph Object Gateway 103
10 Instalación de iSCSI Gateway 111
11 Instalación de CephFS 125
12 Instalación de NFS Ganesha 142
8 Instalación de servicios para acceder a los datos
Después de distribuir el clúster de SUSE Enterprise Storage 6, puede que deba instalar softwareadicional para acceder a los datos, por ejemplo Object Gateway o iSCSI Gateway; o tambiénpuede distribuir un sistema de archivos agrupados en clústeres encima del clúster de Ceph. Estecapítulo se centra principalmente en la instalación manual. Si dispone de un clúster distribuidomediante Salt, consulte en el Capítulo 5, Distribución con DeepSea/Salt como instalar pasarelasconcretas o CephFS.
102 SES 6
9 Ceph Object Gateway
Ceph Object Gateway es una interfaz de almacenamiento de objetos creada en librgw a nde proporcionar aplicaciones con una pasarela RESTful a los clústeres de Ceph. Admite dosinterfaces:
Compatible con S3: proporciona la función de almacenamiento de objetos con una interfazque 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 interfazque es compatible con un subconjunto extenso de la API de OpenStack Swift.
El daemon Object Gateway utiliza el front-end HTTP "Beast" por defecto. Utiliza la bibliotecaBoost.Beast para el análisis HTTP y la biblioteca Boost.Asio para operaciones de E/S de redasíncronas.
Puesto que proporciona interfaces compatibles con OpenStack Swift y Amazon S3, ObjectGateway tiene su propia de gestión de usuarios. Object Gateway puede almacenar datos en elmismo clúster que se utiliza para almacenar datos de clientes de CephFS o clientes del dispo-sitivo de bloques RADOS. Las API S3 y Swift comparten un espacio de nombre común, de formaque es posible escribir datos con una API y recuperarlos con la otra.
Importante: Object Gateway distribuida por DeepSeaObject Gateway se instala como una función de DeepSea; por lo tanto, no es necesariorealizar una instalación manual.
Para instalar Object Gateway durante la distribución del clúster, consulte la Sección 5.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 2 “Administración de un clúster de Salt”, Sección 2.2 “Adición de nuevas
funciones a los nodos”.
103 SES 6
9.1 Instalación manual de Object Gateway
1. Instale Object Gateway en un nodo que no esté utilizando el puerto 80. El comandosiguiente instala todos los componentes necesarios:
cephadm@ogw > sudo zypper ref && zypper in ceph-radosgw
2. Si se está ejecutando el servidor Apache de la instancia anterior de Object Gateway,deténgalo e inhabilite el servicio correspondiente:
cephadm@ogw > 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 = "beast port=80"
SugerenciaSi desea configurar Object Gateway/Beast para su uso con el cifrado SSL, modiquela línea así:
rgw frontends = beast ssl_port=7480 ssl_certificate=PATH_TO_CERTIFICATE.PEM
4. Reinicie el servicio de Object Gateway.
cephadm@ogw > sudo systemctl restart [email protected]_host
9.1.1 Configuración de Object Gateway
Se requieren varios pasos para configurar una instancia de Object Gateway.
104 Instalación manual de Object Gateway SES 6
9.1.1.1 Configuración básica
Para configurar una instancia de Ceph Object Gateway se requiere que haya un clúster dealmacenamiento de Ceph en ejecución. Ceph Object Gateway es un cliente del clúster de almace-namiento 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 permisosadecuados.
Repositorios para almacenar sus datos.
Un directorio de datos para la instancia de la pasarela.
Una entrada de la instancia en el archivo de configuración de Ceph.
Cada instancia debe tener un nombre de usuario y una clave para comunicarse con un clúster dealmacenamiento de Ceph. En los pasos siguientes, se utiliza un nodo de monitor para crear unanillo de claves bootstrap y, a continuación, se crea el anillo de claves del usuario de la instanciade Object Gateway según el anillo de claves bootstrap. Después, se crea un nombre de usuarioy 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@adm > ceph-authtool --create-keyring /etc/ceph/ceph.client.rgw.keyringcephadm@adm > 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. Porejemplo, se utilizará el nombre gateway después de client.radosgw :
cephadm@adm > ceph-authtool /etc/ceph/ceph.client.rgw.keyring \ -n client.rgw.gateway --gen-key
3. Añada funciones a la clave:
cephadm@adm > ceph-authtool -n client.rgw.gateway --cap osd 'allow rwx' \ --cap mon 'allow rwx' /etc/ceph/ceph.client.rgw.keyring
105 Configuración de Object Gateway SES 6
4. Después de que haya creado un anillo de claves y la clave para dar acceso a Ceph ObjectGateway al clúster de almacenamiento de Ceph, añada la clave al clúster de almacena-miento de Ceph. Por ejemplo:
cephadm@adm > 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@adm > scp /etc/ceph/ceph.client.rgw.keyring ceph@HOST_NAME:/home/cephcephadm@adm > ssh ceph@HOST_NAMEcephadm@ogw > mv ceph.client.rgw.keyring /etc/ceph/ceph.client.rgw.keyring
Sugerencia: uso del anillo de claves bootstrapUn método alternativo consiste en crear el anillo de claves bootstrap de Object Gatewayy, 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 demonitor:
cephadm@mon > 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-NOMBRE_RGW para almacenar elanillo de claves bootstrap:
cephadm@mon > mkdir \/var/lib/ceph/radosgw/ceph-RGW_NAME
3. Cree un anillo de claves de Object Gateway a partir del anillo de claves bootstraprecién creado:
cephadm@mon > ceph \ auth get-or-create client.rgw.RGW_NAME osd 'allow rwx' mon 'allow rw' \ --connect-timeout=25 \ --cluster=ceph \
106 Configuración de Object Gateway SES 6
--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@mon > scp \/var/lib/ceph/radosgw/ceph-RGW_NAME/keyring \RGW_HOST:/var/lib/ceph/radosgw/ceph-RGW_NAME/keyring
9.1.1.2 Creación de repositorios (opcional)
Ceph Object Gateway requiere repositorios del clúster de almacenamiento de Ceph paraalmacenar datos específicos de la pasarela. Si el usuario que ha creado tiene los permisosadecuados, la pasarela creará automáticamente los repositorios. Sin embargo, asegúrese de queha configurado un número por defecto adecuado de grupos de colocación por cada repositoriopresente en el archivo de configuración de Ceph.
Los nombres de repositorio tienen la sintaxis: NOMBRE_DE_ZONA.NOMBRE_DE_REPOSITORIO .Cuando congure una pasarela con la región y la zona por defecto, el nombre de la zona pordefecto es "default", como en este ejemplo:
.rgw.rootdefault.rgw.controldefault.rgw.metadefault.rgw.logdefault.rgw.buckets.indexdefault.rgw.buckets.data
Para crear manualmente los repositorios, consulte el Libro “Guía de administración”, Capítulo 11
“Gestión de repositorios de almacenamiento”, Sección 11.2.2 “Creación de repositorios”.
Importante: Object Gateway y repositorios codificados deborradoSolo el repositorio default.rgw.buckets.data puede tener codificación de borrado. Espreciso replicar todos los demás repositorios; de lo contrario, no será posible acceder ala pasarela.
107 Configuración de Object Gateway SES 6
9.1.1.3 Adición de la configuración de la pasarela a Ceph
Añada la configuración de Ceph Object Gateway al archivo de configuración de Ceph. La confi-guración de Ceph Object Gateway requiere que identifique la instancia de Ceph Object Gateway.A continuación, especifique el nombre de host donde ha instalado el daemon de Ceph ObjectGateway, un anillo de claves (para usar con cephx) y, opcionalmente, un archivo de registro.Por ejemplo:
[client.rgw.INSTANCE_NAME]host = HOST_NAMEkeyring = /etc/ceph/ceph.client.rgw.keyring
Sugerencia: archivo de registro de Object GatewayPara 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 identica esta parte del archivo deconfiguración de Ceph y sirve para configurar un cliente del clúster de almacenamiento de Cephdonde el tipo de cliente es Ceph Object Gateway (radosgw). Después se incluye el nombre deinstancia. Por ejemplo:
[client.rgw.gateway]host = ceph-gatewaykeyring = /etc/ceph/ceph.client.rgw.keyring
NotaNOMBRE_DE_HOST debe ser el nombre de host del equipo, excluido el nombre del dominio.
Desactive print continue . Si tiene denido el valor true (verdadero) para este parámetro,pueden producirse problemas con las operaciones PUT:
rgw print continue = false
108 Configuración de Object Gateway SES 6
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 configuración de Ceph:
[client.rgw.gateway]...rgw dns name = HOST_NAME
También debe plantearse la instalación de un servidor DNS como Dnsmasq en los equipos clientecuando utilice la sintaxis http://NOMBRE_DEPÓSITO.NOMBRE_HOST . El archivo dnsmasq.confdebe incluir los siguientes ajustes:
address=/HOST_NAME/HOST_IP_ADDRESSlisten-address=CLIENT_LOOPBACK_IP
A continuación, añada la dirección IP CLIENT_LOOPBACK_IP como primer servidor DNS en losequipos cliente.
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 CephObject Gateway. Si no se han creado ya, cree directorios de datos para cada instancia de undaemon radosgw. Las variables host del archivo de configuración de Ceph determinan qué hostejecuta cada instancia de un daemon radosgw. El formato típico especica el daemon radosgw,el nombre de clúster y el ID del daemon.
root # mkdir -p /var/lib/ceph/radosgw/CLUSTER_ID
Con el ejemplo del valor de ceph.conf descrito anteriormente, debería ejecutarse lo siguiente:
root # 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 configuraciones, serecomienda reiniciar el servicio del clúster de almacenamiento de Ceph. A continuación, inicieel servicio radosgw . Para obtener más información, consulte la Libro “Guía de administración”,
Capítulo 4 “Introducción” y la Libro “Guía de administración”, Capítulo 17 “Ceph Object Gateway”,
Sección 17.3 “Funcionamiento del servicio de Object Gateway”.
109 Configuración de Object Gateway SES 6
Cuando el servicio esté activo y en ejecución, puede realizar una petición GET anónima paracomprobar si la pasarela devuelve una respuesta. Una petición HTTP sencilla del nombre deldominio debe devolver la información siguiente:
<ListAllMyBucketsResult> <Owner> <ID>anonymous</ID> <DisplayName/> </Owner> <Buckets/></ListAllMyBucketsResult>
110 Configuración de Object Gateway SES 6
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 6 incluye una utilidad que permitegestionar el almacenamiento de Ceph en diversos clientes, como Microsoft Windows* yVMware* vSphere, mediante el protocolo iSCSI. El acceso iSCSI de múltiples rutas aporta dispo-nibilidad y capacidad de ampliación para estos clientes, mientras que el protocolo iSCSI estan-darizado también proporciona una capa adicional de aislamiento de seguridad entre los clientesy el clúster de SUSE Enterprise Storage 6. La utilidad de configuración se denomina ceph-iscsi . Mediante ceph-iscsi , los administradores de almacenamiento de Ceph pueden denirvolúmenes de provisión ligera, replicados y de alta disponibilidad compatibles con las instan-táneas de solo lectura, los clones de lectura y escritura y el cambio de tamaño automático conel dispositivo de bloques RADOS (RBD) de Ceph. Los administradores pueden, a continuación,exportar volúmenes a través de un host de pasarela ceph-iscsi único o a través de varios hostsde pasarela que admitan failover de múltiples rutas. Los hosts de Linux, Microsoft Windows yVMware pueden conectarse a los volúmenes mediante el protocolo iSCSI, por lo que están dispo-nibles igual que cualquier otro dispositivo de bloques SCSI. Esto signica que los clientes deSUSE Enterprise Storage 6 pueden ejecutar de forma ecaz un subsistema completo de infraes-tructura de almacenamiento de bloques en Ceph que proporcione todas las funciones y ventajasde una SAN convencional, lo que permite el crecimiento en el futuro.
Este capítulo presenta información detallada para configurar una infraestructura de clúster deCeph junto con una pasarela iSCSI para que los hosts del cliente puedan utilizar los datos almace-nados de forma remota como dispositivos de almacenamiento local mediante el protocolo iSCSI.
10.1 Almacenamiento de bloques iSCSIiSCSI es una implementación del conjunto de comandos Small Computer System Interface (SCSI,interfaz de sistema informático pequeño) que usa el protocolo de Internet (IP) especificado enla RFC 3720. iSCSI se implementa como un servicio en el que un cliente (iniciador) se comunicacon un servidor (destino) a través de una sesión en el puerto TCP 3260. La dirección IP y elpuerto de un destino iSCSI se denominan "portal iSCSI", y un destino puede quedar expuestomediante uno o varios portales. La combinación de un destino y uno o más portales se denomina"grupo de portal de destino" (TPG).
111 Almacenamiento de bloques iSCSI SES 6
El protocolo de capa de enlace de datos subyacente para iSCSI suele ser Ethernet. Más concreta-mente, las infraestructuras iSCSI modernas utilizan 10 Gigabit Ethernet o redes más rápidas paraun rendimiento óptimo. Se recomienda encarecidamente usar conectividad 10 Gigabit Ethernetentre 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, eldominio y sitio Web originales del proyecto. Durante cierto tiempo, había al menos cuatro imple-mentaciones de destino iSCSI compitiendo para la plataforma Linux, pero, al nal, LIO preva-leció como el único destino iSCSI de referencia. El código de kernel de la línea principal deLIO utiliza el sencillo, aunque algo ambiguo, nombre de "destino" y distingue entre "núcleo dedestino" 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. Sinembargo, LIO también admite Fibre Channel (FC), Fibre Channel over Ethernet (FCoE) y otrosprotocolos de interfaz de usuario. En este momento, SUSE Enterprise Storage solo admite elprotocolo iSCSI.
El módulo de procesador nal de destino más utilizado es simplemente, cualquiera capaz dereexportar cualquier dispositivo de bloques disponible en el host de destino. Este módulo sedenomina iblock. Sin embargo, LIO también tiene un módulo de procesador nal RBD especícoque 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 plataformasLinux, 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, entraren los destinos y asignar volúmenes iSCSI. iscsid se comunica con la capa intermedia SCSI paracrear dispositivos de bloques en el kernel que este, a continuación, puede tratar como cualquier
112 Destino iSCSI de kernel de Linux SES 6
otro dispositivo de bloques SCSI del sistema. El iniciador open-iscsi se puede distribuir juntocon la utilidad Device Mapper Multipath ( dm-multipath ) para proporcionar un dispositivo debloques 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 iniciadoriSCSI de Microsoft. El servicio iSCSI se puede configurar a través de una interfaz gráca deusuario (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 VMwareESX, vmkiscsi . Si está habilitado, puede configurarse desde el cliente de vSphere o a travésdel comando vmkiscsi-tool . A continuación, puede dar formato a los volúmenes de almace-namiento conectados a través del adaptador de almacenamiento iSCSI de vSphere con VMFS yutilizarlos como cualquier otro dispositivo de almacenamiento de máquina virtual. El iniciadorde VMware también es compatible con E/S de múltiples vías para la alta disponibilidad.
10.2 Información general sobre ceph-iscsiceph-iscsi combina las ventajas de los dispositivos de bloques RADOS con la versatilidadextendida de iSCSI. Si se emplea ceph-iscsi en un host de destino iSCSI (conocido como iSCSIGateway), cualquier aplicación que necesite hacer uso del almacenamiento de bloques puedebeneficiarse 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 destinopara conectarse a un destino LIO, que traduce todas las comunicaciones de E/S de destino enoperaciones de almacenamiento RBD.
113 Información general sobre ceph-iscsi SES 6
FIGURA 10.1: CLÚSTER DE CEPH CON UNA SOLA INSTANCIA DE ISCSI GATEWAY
Por naturaleza, ceph-iscsi es de alta disponibilidad y admite operaciones de múltiplesrutas. Por lo tanto, los hosts de iniciador descendentes pueden utilizar varias instancias deiSCSI Gateway para obtener tanto alta disponibilidad como capacidad de ampliación. Cuandose comunican con una configuración iSCSI con más de un pasarela, los iniciadores puedenequilibrar 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, lascomunicaciones 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
114 Información general sobre ceph-iscsi SES 6
10.3 Consideraciones de distribuciónUna configuración mínima de SUSE Enterprise Storage 6 con ceph-iscsi consta de lossiguientes componentes:
Un clúster de almacenamiento de Ceph. El clúster de Ceph está formado por un mínimo decuatro servidores físicos que alojan al menos ocho daemons de almacenamiento de objetos(OSD) cada uno. En una configuración de este tipo, tres nodos de OSD también funcionancomo host de monitor (MON).
Un servidor de destino iSCSI con el destino iSCSI LIO en ejecución, configurado medianteceph-iscsi .
Un host de iniciador iSCSI, con open-iscsi (Linux) en ejecución, el iniciador iSCSI deMicrosoft (Microsoft Windows) o cualquier otra distribución de iniciador iSCSI compatible.
Una configuración de producción recomendada de SUSE Enterprise Storage 6 con ceph-iscsiconsta de:
Un clúster de almacenamiento de Ceph. Un clúster de producción de Ceph formado porcualquier número de nodos de OSD (normalmente más de 10), que por lo general ejecutande 10 a 12 daemons de almacenamiento de objetos (OSD) cada uno, con no menos de treshosts MON dedicados.
Varios servidores de destino iSCSI en los que se ejecuta el destino iSCSI LIO, configuradomediante ceph-iscsi . Para el failover y el equilibrio de carga iSCSI, estos servidoresdeben ejecutar un kernel que admita el módulo target_core_rbd . Hay disponiblespaquetes 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, eliniciador iSCSI de Microsoft (Microsoft Windows) o cualquier otra implementación deiniciador iSCSI compatible.
10.4 Instalación y configuraciónEn esta sección se describen los pasos necesarios para instalar y configurar una instancia deiSCSI Gateway en SUSE Enterprise Storage.
115 Consideraciones de distribución SES 6
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 oañadiéndolo a un clúster existente mediante DeepSea.
Para incluir iSCSI Gateway durante el proceso de distribución del clúster, consulte laSección 5.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 2 “Administración de un clúster de Salt”, Sección 2.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. Serecomienda utilizar un repositorio RADOS dedicado para este propósito. Es posible crear unvolumen desde cualquier host que sea posible conectar al clúster de almacenamiento mediantela utilidad de línea de comandos rbd de Ceph. Esto requiere que el cliente tenga al menosun archivo de configuración ceph.conf mínimo y credenciales de autenticación adecuadas paraCephX.
Para crear un volumen nuevo y exportarlo posteriormente a través de iSCSI, use el comandorbd create especificando el tamaño del volumen en megabytes. Por ejemplo, para crear unvolumen de 100 GB denominado "testvol" en el repositorio denominado "iscsi-images", ejecute:
cephadm@adm > rbd --pool iscsi-images create --size=102400 'testvol'
10.4.3 Exportación de imágenes RBD a través de iSCSI
Para exportar imágenes RBD mediante iSCSI, puede utilizar la interfaz Web de Ceph Dashboardo la utilidad de línea de comandos de pasarela ceph-iscsi . En esta sección nos centraremossolo en esta utilidad y se mostrará cómo crear un destino iSCSI que exporte una imagen RBDmediante la línea de comandos.
NotaSolo se admiten las siguientes características de la imagen RBD: layering , striping(v2) , exclusive-lock , fast-diff y data-pool . Las imágenes RBD con cualquierotra característica habilitada no se pueden exportar.
116 Distribución de iSCSI Gateway en un clúster de Ceph SES 6
Como usuario root , inicie la interfaz de línea de comandos de pasarela iSCSI:
root # gwcli
Diríjase a iscsi-targets y cree un destino con el nombre iqn.2003-01.org.linux-
iscsi.iscsi.x86:testvol :
gwcli > /> cd /iscsi-targetsgwcli > /iscsi-targets> create iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol
Cree las pasarelas iSCSI especificando el nombre y la dirección IP de la pasarela:
gwcli > /iscsi-targets> cd iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/gatewaysgwcli > /iscsi-target...tvol/gateways> create iscsi1 192.168.124.104gwcli > /iscsi-target...tvol/gateways> create iscsi2 192.168.124.105
SugerenciaUtilice el comando help para mostrar la lista de comandos disponibles en el nodo deconfiguración actual.
Añada la imagen RBD con el nombre "testvol" en el repositorio "iscsi-images":
gwcli > /iscsi-target...tvol/gateways> cd /disksgwcli > /disks> attach iscsi-images/testvol
Asigne la imagen RBD al destino:
gwcli > /disks> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/disksgwcli > /iscsi-target...testvol/disks> add iscsi-images/testvol
NotaPuede utilizar herramientas de nivel inferior, como targetcli , para consultar la confi-guración local, pero no para modificarla.
SugerenciaPuede utilizar el comando ls para revisar la configuración. Algunos nodos de confi-guración también admiten el comando info , que se puede utilizar para mostrar infor-mación más detallada.
117 Exportación de imágenes RBD a través de iSCSI SES 6
Tenga en cuenta que, por defecto, la autenticación de ACL está habilitada para que no se puedaacceder aún a este destino. Consulte la Sección 10.4.4, “Autenticación y control de acceso” paraobtener más información sobre la autenticación y el control de acceso.
10.4.4 Autenticación y control de acceso
La autenticación iSCSI es exible y cubre muchas posibilidades de autenticación.
10.4.4.1 Sin autenticación
"Sin autenticación" signica que cualquier iniciador podrá acceder a cualquier LUN en el destinocorrespondiente. Para habilitar "sin autenticación", hay que inhabilitar la autenticación de ACL:
gwcli > /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/hostsgwcli > /iscsi-target...testvol/hosts> auth disable_acl
10.4.4.2 Autenticación de ACL
Si se utiliza la autenticación de ACL basada en el nombre del iniciador, solo se permite que seconecten los iniciadores denidos. Para denir un iniciador, haga lo siguiente:
gwcli > /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/hostsgwcli > /iscsi-target...testvol/hosts> create iqn.1996-04.de.suse:01:e6ca28cc9f20
Los iniciadores denidos podrán conectarse, pero solo tendrán acceso a las imágenes RBD quese hayan añadido explícitamente al iniciador:
gwcli > /iscsi-target...:e6ca28cc9f20> disk add rbd/testvol
10.4.4.3 Autenticación CHAP
Además de ACL, puede habilitar la autenticación CHAP especificando un nombre de usuario yuna contraseña para cada iniciador:
gwcli > /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/hosts/iqn.1996-04.de.suse:01:e6ca28cc9f20gwcli > /iscsi-target...:e6ca28cc9f20> auth username=common12 password=pass12345678
118 Autenticación y control de acceso SES 6
NotaLos nombres de usuario deben tener una longitud de entre 8 a 64 caracteres y solo puedenincluir letras o estos caracteres ".", "@", "-", "_" o ":".
Las contraseñas deben tener entre 12 y 16 caracteres y solo pueden incluir letras o estoscaracteres: "@", "-", "_" o "/".
Opcionalmente, también puede habilitar la autenticación CHAP mutua especificando losparámetros mutual_username y CHAPmutual_password en el comando auth .
10.4.4.4 Descubrimiento y autenticación mutua
la autenticación de descubrimiento es independiente de los métodos de autenticación anteriores.Requiere credenciales para la navegación, es opcional y se puede configurar mediante:
gwcli > /> cd /iscsi-targetsgwcli > /iscsi-targets> discovery_auth username=du123456 password=dp1234567890
NotaLos nombres de usuario deben tener entre 8 y 64 caracteres y solo pueden incluir letrasy estos caracteres: ".", "@", "-", "_" o ":".
Las contraseñas deben tener entre 12 y 16 caracteres y solo pueden incluir letras o estoscaracteres: "@", "-", "_" o "/".
Opcionalmente, también puede especificar los parámetros mutual_username ymutual_password en el comando discovery_auth .
La autenticación de descubrimiento se puede inhabilitar mediante el siguiente comando:
gwcli > /iscsi-targets> discovery_auth nochap
10.4.5 Valores avanzados
ceph-iscsi puede configurarse con parámetros avanzados que posteriormente se pasan aldestino de E/S LIO. Los parámetros se dividen en parámetros de "destino" y de "disco".
119 Valores avanzados SES 6
AvisoA no ser que se indique lo contrario, no se recomienda cambiar los valores por defectode estos parámetros.
10.4.5.1 Configuración de destino
Puede ver el valor de estos ajustes mediante el comando info :
gwcli > /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvolgwcli > /iscsi-target...i.x86:testvol> info
Y para cambiar un valor se usa el comando reconfigure :
gwcli > /iscsi-target...i.x86:testvol> reconfigure login_timeout 20
Los valores de "destino" disponibles son:
default_cmdsn_depth
Profundidad de CmdSN (número de secuencia de comando) por defecto. Limita la cantidadde peticiones que un iniciador iSCSI puede tener pendientes en cualquier momento.
default_erl
Nivel de recuperación de error por defecto.
login_timeout
Valor de tiempo límite de entrada a la sesión en segundos.
netif_timeout
Tiempo límite de fallo de NIC en segundos.
prod_mode_write_protect
Si se establece en 1, se impide que se pueda escribir en los LUN.
10.4.5.2 Configuración de disco
Puede ver el valor de estos ajustes mediante el comando info :
gwcli > /> cd /disks/rbd/testvol
120 Valores avanzados SES 6
gwcli > /disks/rbd/testvol> info
Y para cambiar un valor se usa el comando reconfigure :
gwcli > /disks/rbd/testvol> reconfigure rbd/testvol emulate_pr 0
Los valores de "disco" disponibles son:
block_size
Tamaño de bloque del dispositivo subyacente.
emulate_3pc
Si se establece en 1, se habilita la opción Third Party Copy (Copia por parte de terceros).
emulate_caw
Si se establece en 1, se habilita la opción Compare and Write (Comparar y escribir).
emulate_dpo
Si se establece en 1, se activa la opción Disable Page Out (Inhabilitar página saliente).
emulate_fua_read
Si se establece en 1, se habilita la lectura de Force Unit Access (Forzar acceso a la unidad).
emulate_fua_write
Si se establece en 1, se habilita la escritura de Force Unit Access (Forzar acceso a la unidad).
emulate_model_alias
Si se establece en 1, se utiliza el nombre del dispositivo de procesador nal para el aliasdel modelo.
emulate_pr
Si se dene en 0, se inhabilita la compatibilidad con las reservas SCSI, incluidas las reservasde grupo persistente. Mientras está inhabilitada, la pasarela iSCSI Gateway de SES puedeignorar el estado de la reserva, lo que mejora la latencia de las peticiones.
SugerenciaSe recomienda denir el valor 0 en backstore_emulate_pr si los iniciadores iSCSI norequieren compatibilidad con la reserva SCSI.
emulate_rest_reord
121 Valores avanzados SES 6
Si se establece en 0, la opción Queue Algorithm Modier (Modificador de algoritmo decola) tiene restringido el cambio de orden.
emulate_tas
Si se establece en 1, se habilita la opción Task Aborted Status (Estado cancelado de tarea).
emulate_tpu
Si se establece en 1, se habilita la opción Thin Provisioning Unmap (Anular asignación deprovisión ligera).
emulate_tpws
Si se establece en 1, se habilita la opción Thin Provisioning Write Same (Misma escrituraen provisión ligera).
emulate_ua_intlck_ctrl
Si se establece en 1, se habilita la opción Unit Attention Interlock (Interbloqueo de atenciónen la unidad).
emulate_write_cache
Si se establece en 1, se activa la opción Write Cache Enable (Habilitar caché de escritura).
enforce_pr_isids
Si se establece en 1, se fuerzan los ISID de reserva persistente.
is_nonrot
Si se establece en 1, el almacén de respaldo es un dispositivo sin rotación.
max_unmap_block_desc_count
Número máximo de descriptores de bloque para UNMAP.
max_unmap_lba_count:
Número máximo de LBA para UNMAP.
max_write_same_len
Longitud máxima de WRITE_SAME.
optimal_sectors
Tamaño de la petición óptima en sectores.
pi_prot_type
Tipo de garantía de DIF.
queue_depth
122 Valores avanzados SES 6
Profundidad de la cola.
unmap_granularity
Granularidad de UNMAP.
unmap_granularity_alignment
Alineación de la granularidad de UNMAP.
force_pr_aptpl
Si está habilitado, LIO siempre escribirá el estado reserva persistente en el almacenamientopersistente, independientemente de si el cliente lo ha pedido a través de aptpl=1 . Estono tiene ningún efecto en el back-end RBD del kernel para LIO, ya que siempre persiste elestado PR. En circunstancias ideales, la opción target_core_rbd debería aplicar el valor"1" y producir un error si alguien intenta inhabilitarlo a través de congfs.
unmap_zeroes_data
Afecta a si LIO anunciará LBPRZ a los iniciadores SCSI, lo que indica que los ceros se leerándesde una región después de UNMAP o WRITE SAME con un bit de desasignación.
10.5 Exportación de imágenes del dispositivo debloques RADOS mediante tcmu-runnerceph-iscsi admite los almacenes rbd (basado en el kernel) y user:rbd (tcmu-runner), loque hace que toda la gestión sea transparente e independiente del almacén.
Aviso: tecnología en fase preliminarLas distribuciones de iSCSI Gateway basadas en tcmu-runner son actualmente una tecno-logía en fase preliminar.
A diferencia de las distribuciones de iSCSI Gateway basadas en kernel, las basadas en tcmu-runner no ofrecen compatibilidad con E/S de múltiples rutas ni con las reservas persistentesSCSI.
Para exportar una imagen de dispositivo de bloque RADOS mediante tcmu-runner , todo lo quenecesita hacer es especificar el almacén user:rbd al conectar el disco:
gwcli > /disks> attach rbd/testvol backstore=user:rbd
123 Exportación de imágenes del dispositivo de bloques RADOS mediante tcmu-runner SES 6
NotaSi utiliza tcmu-runner , la imagen RBD exportada debe tener habilitada la funciónexclusive-lock .
124 Exportación de imágenes del dispositivo de bloques RADOS mediante tcmu-runner SES 6
11 Instalación de CephFS
El sistema de archivos de Ceph (CephFS) es un sistema de archivos conforme con POSIX queutiliza un clúster de almacenamiento de Ceph para almacenar sus datos. CephFS utiliza el mismosistema de clúster para los dispositivos de bloques de Ceph, el almacenamiento de objetos deCeph 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 yal menos un servidor de metadatos de Ceph en ejecución.
11.1 Escenarios admitidos de CephFS y directricesCon SUSE Enterprise Storage 6, SUSE incluye compatibilidad ocial con muchos escenarios enlos que se utiliza el componente de ampliación horizontal y distribuido CephFS. En esta entradase 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 conla función de servidor de metadatos. Solo uno estará activo , mientras el resto estaránpasivos . No olvide mencionar todos los nodos MON en el comando mount cuando monteCephFS desde un cliente.
Los clientes deben ser SUSE Linux Enterprise Server 12 SP3 o posterior, o SUSE LinuxEnterprise Server 15 o posterior, con el controlador del módulo del kernel cephfs . Nose admite el módulo FUSE.
En SUSE Enterprise Storage 6 se admiten las cuotas de CephFS y se pueden estableceren cualquier subdirectorio del sistema de archivos de Ceph. La cuota restringe el númerode bytes o los archivos almacenados debajo del punto especificado en la jerarquíade directorios. Para obtener más información, consulte el Libro “Guía de administración”,
Capítulo 19 “Sistema de archivos con agrupación en clúster”, Sección 19.6 “Configuración de cuotas
de CephFS”.
125 Escenarios admitidos de CephFS y directrices SES 6
CephFS admite cambios de diseño de archivos, como se describe en Sección 11.3.4, “Diseños
de archivos”. Sin embargo, aunque el sistema de archivos se puede montar mediantecualquier cliente, no es posible añadir nuevos repositorios de datos a un sistema de archivosCephFS existente ( ceph mds add_data_pool ). Solo se pueden añadir mientras el sistemade archivos está desmontado.
Un mínimo de un servidor de metadatos. SUSE recomienda distribuir varios nodos con lafunción de servidor de metadatos. Por defecto, se inician daemons adicionales del MDScomo daemons en espera , que actúan como copias de seguridad para el MDS activo.También se admiten varios daemons activos del MDS (consulte la Sección 11.3.2, “Tamaño
del clúster del servidor de metadatos”).
11.2 Servidor de metadatos de CephEl servidor de metadatos de Ceph (MDS) almacena los metadatos para CephFS. Los disposi-tivos de bloques de Ceph y el almacenamiento de objetos de Ceph no utilizan un servidor demetadatos. Gracias a los servidores de metadatos, los usuarios del sistema de archivos POSIXpueden ejecutar comandos básicos, como ls o find , sin que ello suponga una carga de trabajoenorme 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 delclúster, tal como se describe en la Sección 5.3, “Distribución del clúster”, o añadirlos a un clúster yadistribuido como se describe en el Libro “Guía de administración”, Capítulo 2 “Administración de un
clúster de Salt”, Sección 2.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 configu-ración del cortafuegos del servidor donde se vaya a distribuir dicho servidor: inicie yast , accedaa Seguridad y usuarios Cortafuegos Servicios autorizados y, en el menú desplegable Servicio quese va a autorizar seleccione Ceph OSD/MDS. Si no se permite el tráco completo del nodo delservidor de metadatos de Ceph, el montaje de un sistema de archivos falla, aunque otras opera-ciones pueden funcionar correctamente.
126 Servidor de metadatos de Ceph SES 6
11.2.2 Configuración de un servidor de metadatos
Puede ajustar con más detalle el comportamiento del servidor de metadatos insertando lasopciones relevantes en el archivo de configuración ceph.conf .
CONFIGURACIÓN DEL SERVIDOR DE METADATOS
mon force standby active
Si se dene el valor "true" (opción por defecto), los monitores imponen que la respuestaen espera esté activa. Defínalo en las secciones [mon] o [global] .
mds cache memory limit
La cantidad máxima de memoria (en bytes) que el servidor de metadatos aplicará para sucaché. Los administradores deben utilizar este valor en lugar del antiguo ajuste mds cachesize . Por defecto es 1 GB.
mds cache reservation
La reserva de caché (memoria o inodos) que debe conservar el caché del servidor demetadatos. Cuando el servidor de metadatos empieza a utilizar su reserva, retendrá tempo-ralmente el estado del cliente hasta que el tamaño de caché se reduzca para restaurar lareserva. El valor por defecto es 0,05.
mds cache size
El número de inodos que se van a almacenar en caché. El valor 0 (opción por defecto)indica un número ilimitado. Se recomienda utilizar mds cache memory limit para limitarla cantidad de memoria que utiliza la memoria caché del MDS.
mds cache mid
El punto de inserción de los nuevos elementos en la LRU de caché (desde la parte superior).El valor por defecto es 0.7.
mds dir commit ratio
La fracción del directorio que está sucia antes de que Ceph se conrme mediante unaactualización completa en lugar de con una actualización parcial. El valor por defecto es0,5.
mds dir max commit size
El tamaño máximo de una actualización de directorio antes de que Ceph la divida entransacciones más pequeñas. El valor por defecto es 90 MB.
mds decay halflife
La vida media de la temperatura de caché del MDS. El valor por defecto es 5.
127 Configuración de un servidor de metadatos SES 6
mds beacon interval
La frecuencia en segundos de los mensajes de baliza enviados al monitor. El valor pordefecto es 4.
mds beacon grace
El intervalo sin balizas antes de que Ceph declare que un MDS tiene retrasos y, posible-mente, lo reemplace. El valor por defecto es 15.
mds blacklist interval
La duración de la lista negra de los MDS con errores en el mapa de OSD. Este valor controlacuánto tiempo permanecerán los daemons del MDS con fallos en la lista negra del mapa deOSD. No tiene ningún efecto respecto a cuánto tiempo se incluye algo en la lista negra si eladministrador lo ha incluido manualmente. Por ejemplo, el comando ceph osd blacklistadd seguirá utilizando el tiempo por defecto de la lista negra. El valor por defecto es 24*60.
mds reconnect timeout
Intervalo en segundos que se debe esperar a que los clientes se vuelvan a conectar duranteel reinicio del MDS. El valor por defecto es 45.
mds tick interval
Indica con qué frecuencia el MDS realiza tareas periódicas internas. El valor por defectoes 5.
mds dirstat min interval
El intervalo mínimo en segundos para tratar de evitar la propagación de estadísticas recur-sivas hacia arriba en el árbol. El valor por defecto es 1.
mds scatter nudge interval
La rapidez con la que los cambios de dirstat se propagan. El valor por defecto es 5.
mds client prealloc inos
El número de inodos que se van a preasignar por sesión de cliente. El valor por defectoes 1000.
mds early reply
Determina si el MDS debe permitir que los clientes vean los resultados de la petición antesde que se conrmen en el diario. El valor por defecto es "true" (verdadero).
mds use tmap
Utiliza el mapa trivial para las actualizaciones de directorios. El valor por defecto es"true" (verdadero).
128 Configuración de un servidor de metadatos SES 6
mds default dir hash
La función que se va a utilizar para aplicar hash a los archivos en varios fragmentos dedirectorio. El valor por defecto es 2 (es decir, "rjenkins").
mds log skip corrupt events
Determina si el MDS debe intentar omitir los eventos de diario dañados durante la respuestadel diario. El valor por defecto es "false".
mds log max events
El número máximo de eventos que puede haber en el diario antes de iniciar el recorte.Dena el valor -1 (opción por defecto) para inhabilitar los límites.
mds log max segments
El número máximo de segmentos (objetos) que puede haber en el diario antes de iniciarel recorte. Dena el valor -1 para inhabilitar los límites. El valor por defecto es 30.
mds log max expiring
El número máximo de segmentos que pueden caducar en paralelo. El valor por defectoes 20.
mds log eopen size
El número máximo de inodos en un evento de EOpen. El valor por defecto es 100.
mds bal sample interval
Determina la frecuencia con la que se debe realizar una muestra de la temperatura deldirectorio para las decisiones de fragmentación. El valor por defecto es 3.
mds bal replicate threshold
La temperatura máxima que se puede alcanzar antes de que Ceph intente replicarmetadatos a otros nodos. El valor por defecto es 8000.
mds bal unreplicate threshold
La temperatura mínima que se debe alcanzar antes de Ceph deje de replicar metadatos aotros nodos. El valor por defecto es 0.
mds bal split size
El tamaño máximo que puede alcanzar el directorio antes de que el MDS divida unfragmento de directorio en bits más pequeños. El valor por defecto es 10000.
mds bal split rd
La temperatura máxima de lectura del directorio que se puede alcanzar antes de que Cephdivida un fragmento de directorio. El valor por defecto es 25000.
129 Configuración de un servidor de metadatos SES 6
mds bal split wr
La temperatura máxima de escritura del directorio que se puede alcanzar antes de queCeph divida un fragmento de directorio. El valor por defecto es 10000.
mds bal split bits
El número de bits por los que se va a dividir un fragmento de directorio. El valor pordefecto es 3.
mds bal merge size
El tamaño mínimo que puede alcanzar el directorio antes de que Ceph intente combinarfragmentos de directorio adyacentes. El valor por defecto es 50.
mds bal interval
La frecuencia en segundos de los intercambios de carga de trabajo entre MDS. El valorpor defecto es 10.
mds bal fragment interval
El retraso en segundos entre un fragmento que es capaz de dividirse o combinarse, y laejecución del cambio de fragmentación. El valor por defecto es 5.
mds bal fragment fast factor
La proporción por la que los fragmentos pueden superar el tamaño de división antes deque se ejecute una división de inmediato, omitiendo el intervalo de fragmentos. El valorpor defecto es 1.5.
mds bal fragment size max
El tamaño máximo que puede alcanzar un fragmento antes de que se rechacen las nuevasentradas con ENOSPC. El valor por defecto es 100000.
mds bal idle threshold
La temperatura mínima que se debe alcanzar antes de que Ceph migre un subárbol a supadre. El valor por defecto es 0.
mds bal mode
El método para calcular la carga del MDS:
0 = Híbrido.
1 = Tasa de petición y latencia.
2 = Carga de CPU.
El valor por defecto es 0.
130 Configuración de un servidor de metadatos SES 6
mds bal min rebalance
La temperatura mínima que puede alcanzar el subárbol antes de que Ceph migre. El valorpor defecto es 0.1.
mds bal min start
La temperatura mínima que puede alcanzar el subárbol antes de que Ceph busque en unsubárbol. El valor por defecto es 0.2.
mds bal need min
La fracción mínima del tamaño del subárbol de destino que se debe aceptar. El valor pordefecto es 0.8.
mds bal need max
La fracción máxima del tamaño del subárbol de destino que se debe aceptar. El valor pordefecto es 1.2.
mds bal midchunk
Ceph migrará cualquier subárbol que sea mayor que esta fracción del tamaño del subárbolde destino. El valor por defecto es 0.3.
mds bal minchunk
Ceph ignorará cualquier subárbol que sea menor que esta fracción del tamaño del subárbolde destino. El valor por defecto es 0.001.
mds bal target removal min
El número mínimo de iteraciones que debe tener el equilibrador antes de que Ceph quiteun destino del MDS antiguo del mapa de MDS. El valor por defecto es 5.
mds bal target removal max
El número máximo de iteraciones que debe tener el equilibrador antes de que Ceph quiteun destino del MDS antiguo del mapa de MDS. El valor por defecto es 10.
mds replay interval
El intervalo de sondeo del diario cuando está en modo de respuesta en espera ("hotstandby"). El valor por defecto es 1.
mds shutdown check
El intervalo para sondear la memoria caché durante el apagado del MDS. El valor pordefecto es 0.
mds thrash fragments
Ceph fragmentará o combinará aleatoriamente los directorios. El valor por defecto es 0.
131 Configuración de un servidor de metadatos SES 6
mds dump cache on map
Ceph volcará el contenido del caché del MDS en un archivo de cada mapa de MDS. Elvalor por defecto es "false".
mds dump cache after rejoin
Ceph volcará el contenido del caché del MDS en un archivo después de volver a unirse ala memoria caché durante la recuperación. El valor por defecto es "false".
mds standby for name
Un daemon del MDS quedará a la espera de otro daemon del MDS con el nombre especi-ficado en este ajuste.
mds standby for rank
Un daemon del MDS quedará a la espera de un daemon del MDS de este rango. El valorpor defecto es -1.
mds standby replay
Determina si un daemon del MDS de Ceph debe sondear y responder al registro de un MDSactivo ("hot standby"). El valor por defecto es "false".
mds min caps per client
Dene el número mínimo de capacidades que puede tener un cliente. El valor por defectoes 100.
mds max ratio caps per client
Dena la proporción máxima de capacidades actuales que se pueden recuperar durante lapresión de caché del MDS. El valor por defecto es 0.8.
CONFIGURACIÓN DEL CREADOR DE DIARIOS DEL SERVIDOR DE METADATOS
journaler write head interval
Indica con qué frecuencia se actualiza el objeto de titular de diario. El valor por defectoes 15.
journaler prefetch periods
Indica cuántos períodos de repartición se deben leer por adelantado en la respuesta deldiario. El valor por defecto es 10.
journal prezero periods
Indica cuántos períodos de repartición se deben poner a cero delante de la posición deescritura. El valor por defecto es 10.
132 Configuración de un servidor de metadatos SES 6
journaler batch interval
La latencia máxima adicional en segundos en la que se incurre artificialmente. El valorpor defecto es 0.001.
journaler batch max
El número máximo de bytes por el que se debe retrasar el vaciado. El valor por defecto es 0.
11.3 CephFSSi dispone de un clúster de almacenamiento de Ceph en buen estado con al menos un servidorde metadatos de Ceph, puede crear y montar el sistema de archivos de Ceph. Asegúrese de quesu 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 lahora de configurar estos repositorios, tenga en cuenta lo siguiente:
Use un nivel de réplica mayor para el repositorio de metadatos, ya que cualquier pérdida dedatos en este repositorio puede producir que no sea posible acceder al sistema de archivoscompleto.
Use un almacenamiento de baja latencia, como discos SSD, para el repositorio demetadatos, ya que así mejorará la latencia observada de las operaciones del sistema dearchivos en los clientes.
Los repositorios necesarios se crean automáticamente asignando una entrada role-mds en elarchivo policy.cfg . Puede crear manualmente los repositorios cephfs_data y cephfs_me-tadata para ajustar el rendimiento de forma manual antes de configurar el servidor demetadatos. 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 11 “Gestión de repositorios de almacenamiento”.
Para crear los dos repositorios obligatorios (por ejemplo, "cephfs_data" y "cephfs_metadata") conlos valores por defecto para usarlos con CephFS, ejecute los comandos siguientes:
cephadm@adm > ceph osd pool create cephfs_data pg_numcephadm@adm > ceph osd pool create cephfs_metadata pg_num
133 CephFS SES 6
Es posible utilizar repositorios codificados de borrado en lugar de los repositorios replicados.Se recomienda usar los repositorios codificados de borrado solo si se requiere un rendimientobajo y acceso aleatorio poco frecuente; por ejemplo, para el almacenamiento en frío, las copiasde seguridad y el archivado. En los repositorios codificados de borrado, CephFS requiere queBlueStore esté habilitado y el repositorio debe tener la opción allow_ec_overwrite denida.Esta opción puede denirse ejecutando ceph osd pool set ec_pool allow_ec_overwritestrue .
La codificación de borrado añade una sobrecarga considerable a las operaciones del sistema dearchivos, especialmente en pequeñas actualizaciones. Esta sobrecarga es inherente al uso de lacodificación de borrado como mecanismo de tolerancia a fallos. Este problema es un inconve-niente necesario si se quiere reducir de forma significativa la sobrecarga del espacio de almace-namiento.
Cuando se crean los repositorios, puede habilitar el sistema de archivos con el comando cephfs new :
cephadm@adm > ceph fs new fs_name metadata_pool_name data_pool_name
Por ejemplo:
cephadm@adm > ceph fs new cephfs cephfs_metadata cephfs_data
Para comprobar que se ha creado el sistema de archivos, puede mostrar todos los sistemas dearchivos CephFS disponibles:
cephadm@adm > 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 unestado activo. Por ejemplo, en un único sistema de servidor de metadatos:
cephadm@adm > ceph mds state5: 1/1/1 up
Sugerencia: otros temasEncontrará más información sobre tareas específicas; por ejemplo, el montaje, eldesmontaje y la configuración avanzada de CephFS, en el Libro “Guía de administración”,
Capítulo 19 “Sistema de archivos con agrupación en clúster”.
134 Creación de CephFS SES 6
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 CephFSdistribuirán el árbol del directorio del sistema de archivos entre sí y, por lo tanto, distribuirán lacarga de los clientes simultáneos. Para poder añadir un daemon activo del servidor de metadatosa una instancia de CephFS, se necesita una reserva de repuesto. Es posible iniciar un daemonadicional o utilizar una instancia de reserva existente.
El comando siguiente muestra el número actual de daemons del servidor de metadatos activosy pasivos.
cephadm@adm > ceph mds stat
El siguiente comando dene el número de servidores de metadatos activos a dos en una instanciadel sistema de archivos.
cephadm@adm > 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, dena max_mds para que solo quede una instancia:
cephadm@adm > 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:
cephadm@adm > ceph mds deactivate fs_name:rank
donde rank es el número de un daemon activo del servidor de metadatos de una instancia delsistema de archivos, entre 0 y max_mds -1.
Se recomienda que al menos un MDS se deje como daemon en espera.
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 sistemade archivos pueden cambiar (normalmente, al añadir nuevas funciones). Los daemons incompa-tibles (por ejemplo, de versiones anteriores) no funcionan con un conjunto de funciones incom-patible y no se iniciarán. Esto signica que actualizar y reiniciar un daemon pueden provocarque todos los otros daemons que aún no se han actualizado se detengan y no se puedan iniciar.
135 Tamaño del clúster del servidor de metadatos SES 6
Por este motivo, se recomienda reducir el clúster activo del servidor de metadatos a una solainstancia y detener todos los daemons en espera antes de actualizar Ceph. Los pasos manualespara 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 anterior-mente a una sola instancia y detenga todos los daemons en espera del servidor demetadatos con sus unidades systemd en todos los otros nodos:
cephadm@mds > systemctl stop ceph-mds\*.service ceph-mds.target
3. Solo entonces, reinicie el único daemon del servidor de metadatos de los que quedan, deforma que se reinicie con archivo binario actualizado.
cephadm@mds > systemctl restart ceph-mds\*.service ceph-mds.target
4. Reinicie todos los demás daemons del servidor de metadatos y vuelva a denir el valorde max_mds que desee.
cephadm@mds > systemctl start ceph-mds.target
Si utiliza DeepSea, se seguirá este procedimiento en caso de que el paquete ceph se haya actua-lizado durante las fase de la 0 a la 4. Es posible llevar a cabo este procedimiento mientras losclientes 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 metadatosactivo. Los clientes se recuperarán automáticamente.
Es recomendable reducir la carga de E/S tanto como sea posible antes de actualizar un clústerdel servidor de metadatos. Este procedimiento es más rápido en los clústeres del servidor demetadatos inactivos. Por el contrario, en un clúster con mucha carga con varios daemons delservidor de metadatos es fundamental reducir la carga de antemano para evitar que un solodaemon del servidor de metadatos se vea desbordado por operaciones de E/S continuas.
11.3.4 Diseños de archivos
El diseño de un archivo controla cómo se asigna su contenido a los objetos RADOS de Ceph.Puede leer y escribir el diseño de un archivo mediante atributos extendidos virtuales, o xattrs paraabreviar.
136 Diseños de archivos SES 6
El nombre del diseño xattrs depende de si se trata de un archivo normal o de un directorio. Eldiseño xattrs de los archivos normales se denomina ceph.file.layout , mientras que el diseñoxattrs de los directorios se denomina ceph.dir.layout . En los ejemplos en los que se mencioneceph.file.layout , sustituya la parte .dir. según corresponda cuando se trate de directorios.
11.3.4.1 Campos de diseño
Se reconocen los siguientes campos de atributo:
pool
El ID o nombre de un repositorio RADOS en el que se almacenarán los objetos de datosde un archivo.
pool_namespace
El espacio de nombres RADOS dentro de un repositorio de datos en el que se escribiránlos objetos. Está vacío por defecto, lo que signica que se usa el espacio de nombres pordefecto.
stripe_unit
El tamaño en bytes de un bloque de datos utilizado en la distribución RAID 0 de un archivo.Todas las unidades de partición de un archivo tienen el mismo tamaño. La última unidadde partición suele estar incompleta: representa los datos situados al nal del archivo, asícomo el "espacio" no utilizado situado detrás hasta ocupar todo el espacio de la unidadde partición ja.
stripe_count
El número de unidades de partición consecutivas que constituyen una "partición" RAID 0de datos de archivo.
object_size
El tamaño en bytes de los objetos RADOS en los que se fragmentan los datos del archivo.
Sugerencia: tamaños de los objetosRADOS aplica un límite configurable en los tamaños de los objetos. Si utilizatamaños de objetos de CephFS superiores a ese límite, es posible que las escriturasno se realicen correctamente. El valor del OSD es osd_max_object_size , que es
137 Diseños de archivos SES 6
de 128 MB por defecto. Los objetos RADOS muy grandes pueden impedir que elclúster funciona de forma uida, por lo que no se recomienda aumentar el límite detamaño del objeto más allá del valor por defecto.
11.3.4.2 Diseño de lectura con getfattr
Utilice el comando getfattr para leer la información de diseño de un archivo de archivo deejemplo file como una sola cadena:
root # touch fileroot # getfattr -n ceph.file.layout file# file: fileceph.file.layout="stripe_unit=4194304 stripe_count=1 object_size=419430
Lea los campos de diseño individuales:
root # getfattr -n ceph.file.layout.pool file# file: fileceph.file.layout.pool="cephfs_data"root # getfattr -n ceph.file.layout.stripe_unit file# file: fileceph.file.layout.stripe_unit="4194304"
Sugerencia: ID o nombre del repositorioAl leer los diseños, el repositorio normalmente se indicará por su nombre. Sin embargo,en raras ocasiones, cuando se acaban de crear los repositorios, podría generarse el ID.
Los directorios no tienen un diseño explícito hasta que se personalizan. Los intentos de leerel diseño fallarán si nunca se ha modicado: eso indica que se usará el diseño del siguientedirectorio antecesor con un diseño explícito.
root # mkdir dirroot # getfattr -n ceph.dir.layout dirdir: ceph.dir.layout: No such attributeroot # setfattr -n ceph.dir.layout.stripe_count -v 2 dirroot # getfattr -n ceph.dir.layout dir# file: dirceph.dir.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 pool=cephfs_data"
138 Diseños de archivos SES 6
11.3.4.3 Diseños de escritura con setfattr
Utilice el comando setfattr para modicar los campos de diseño de un archivo de archivode ejemplo file :
cephadm@adm > ceph osd lspools0 rbd1 cephfs_data2 cephfs_metadataroot # setfattr -n ceph.file.layout.stripe_unit -v 1048576 fileroot # setfattr -n ceph.file.layout.stripe_count -v 8 file# Setting pool by ID:root # setfattr -n ceph.file.layout.pool -v 1 file# Setting pool by name:root # setfattr -n ceph.file.layout.pool -v cephfs_data file
Nota: archivo vacíoSi los campos de diseño de un archivo se modican mediante setfattr , este archivodebe estar vacío, o se producirá un error.
11.3.4.4 Limpieza de diseños
Si desea quitar un diseño explícito de un directorio de ejemplo mydir y volver a heredar eldiseño de su antecesor, ejecute lo siguiente:
root # setfattr -x ceph.dir.layout mydir
Del mismo modo, si ha denido el atributo "pool_namespace" y desea modicar el diseño paraque se use el espacio de nombres por defecto, ejecute:
# Create a directory and set a namespace on itroot # mkdir mydirroot # setfattr -n ceph.dir.layout.pool_namespace -v foons mydirroot # getfattr -n ceph.dir.layout mydirceph.dir.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 \ pool=cephfs_data_a pool_namespace=foons"
# Clear the namespace from the directory's layoutroot # setfattr -x ceph.dir.layout.pool_namespace mydirroot # getfattr -n ceph.dir.layout mydirceph.dir.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 \
139 Diseños de archivos SES 6
pool=cephfs_data_a"
11.3.4.5 Herencia de diseños
Los archivos heredan el diseño de su directorio padre en el momento de la creación. Sin embargo,los cambios posteriores en el diseño del directorio padre no afectan a los hijos:
root # getfattr -n ceph.dir.layout dir# file: dirceph.dir.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data"
# file1 inherits its parent's layoutroot # touch dir/file1root # getfattr -n ceph.file.layout dir/file1# file: dir/file1ceph.file.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data"
# update the layout of the directory before creating a second fileroot # setfattr -n ceph.dir.layout.stripe_count -v 4 dirroot # touch dir/file2
# file1's layout is unchangedroot # getfattr -n ceph.file.layout dir/file1# file: dir/file1ceph.file.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data"
# ...while file2 has the parent directory's new layoutroot # getfattr -n ceph.file.layout dir/file2# file: dir/file2ceph.file.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"
Los archivos creados como descendientes del directorio también heredan su diseño si los direc-torios intermedios no tienen diseños denidos:
root # getfattr -n ceph.dir.layout dir# file: dirceph.dir.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"root # mkdir dir/childdirroot # getfattr -n ceph.dir.layout dir/childdirdir/childdir: ceph.dir.layout: No such attribute
140 Diseños de archivos SES 6
root # touch dir/childdir/grandchildroot # getfattr -n ceph.file.layout dir/childdir/grandchild# file: dir/childdir/grandchildceph.file.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"
11.3.4.6 Adición de un repositorio de datos al servidor de metadatos
Antes de poder utilizar un repositorio con CephFS, debe añadirlo al servidor de metadatos:
cephadm@adm > ceph fs add_data_pool cephfs cephfs_data_ssdcephadm@adm > ceph fs ls # Pool should now show up.... data pools: [cephfs_data cephfs_data_ssd ]
Sugerencia: claves cephxAsegúrese de que sus claves cephx permiten que el cliente acceda a este nuevo repositorio.
Después, puede actualizar el diseño en un directorio de CephFS para utilizar el repositorio queha añadido:
root # mkdir /mnt/cephfs/myssddirroot # setfattr -n ceph.dir.layout.pool -v cephfs_data_ssd /mnt/cephfs/myssddir
Todos los archivos nuevos creados dentro de ese directorio heredarán ahora su diseño ycolocarán sus datos en el repositorio recién añadido. Es posible que observe que el número deobjetos del repositorio de datos primario sigue aumentando, incluso si se están creando archivosen el repositorio que acaba de añadir. Esto es normal: los datos de archivo se almacenan en elrepositorio especificado por el diseño, pero una pequeña cantidad de metadatos se conserva enel repositorio de datos primario para todos los archivos.
141 Diseños de archivos SES 6
12 Instalación de NFS Ganesha
NFS Ganesha proporciona acceso NFS para Object Gateway o CephFS. En SUSE EnterpriseStorage 6, se admiten las versiones 3 y 4 de NFS. NFS Ganesha se ejecuta en el espacio delusuario, en lugar de en el espacio del kernel, e interactúa directamente con Object Gateway oCephFS.
Aviso: acceso con varios protocolosLos clientes nativos de CephFS y NFS no están restringidos por los bloqueos de archivosobtenidos a través de Samba, y viceversa. Las aplicaciones que se basan en el bloqueode archivos con varios protocolos pueden sufrir daños en los datos si se accede a las víascompartidas de Samba respaldadas por CephFS a través de otros medios.
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 5.5.1, “El
archivo policy.cfg”. NFS Ganesha también necesita que role-rgw o role-mds estén presentesen policy.cfg .
Aunque es posible instalar y ejecutar el servidor de NFS Ganesha en un nodo de Ceph yaexistente, se recomienda ejecutarlo en un host dedicado con acceso al clúster de Ceph. Los hostsdel cliente por lo general no forman parte del clúster, pero deben tener acceso de red al servidorde NFS Ganesha.
Para habilitar el servidor de NFS Ganesha en cualquier momento tras la instalación inicial, añadarole-ganesha a policy.cfg y vuelva a ejecutar al menos las fases 2 y 4 de DeepSea. Paraobtener información, consulte: Sección 5.3, “Distribución del clúster”.
NFS Ganesha se congura mediante el archivo /etc/ganesha/ganesha.conf , presente en elnodo de NFS Ganesha. Sin embargo, este archivo se sobrescribe cada vez que se ejecuta la fase 4de DeepSea. Por lo tanto, se recomienda editar la plantilla que utiliza Salt, que es el archivo
142 Preparación SES 6
/srv/salt/ceph/ganesha/files/ganesha.conf.j2 del master de Salt. Para obtener infor-mación sobre el archivo de configuración, consulte el Libro “Guía de administración”, Capítulo 21
“NFS Ganesha: exportación de datos de Ceph a través de NFS”, Sección 21.2 “Configuración”.
12.1.2 Resumen de requisitos
Los siguientes requisitos deben cumplirse antes de ejecutar las fases 2 y 4 de DeepSea a n deinstalar NFS Ganesha:
Debe haber al menos un nodo asignado a role-ganesha .
Solo puede denir un role-ganesha por minion.
Para funcionar, NFS Ganesha necesita una instancia de Object Gateway o CephFS.
El protocolo NFS basado en kernel debe inhabilitarse en los minions con la función role-ganesha .
12.2 Instalación de ejemploEste procedimiento proporciona una instalación de ejemplo que usa tanto Object Gateway comocapas 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 esteprocedimiento.
root@master # salt-run state.orch ceph.stage.0root@master # 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. Ejecute al menos las fases 2 y 4 de DeepSea. Se recomienda ejecutar la fase 3 en medio.
root@master # salt-run state.orch ceph.stage.2
143 Resumen de requisitos SES 6
root@master # salt-run state.orch ceph.stage.3 # optional but recommendedroot@master # salt-run state.orch ceph.stage.4
4. Verique que NFS Ganesha funciona comprobando que el servicio NFS Ganesha se estáejecutando en el nodo de minion:
root@master # salt -I roles:ganesha service.status nfs-ganeshaMINION_ID: True
12.3 Configuración activa-pasiva de altadisponibilidadEn esta sección se proporciona un ejemplo de cómo establecer una configuración activa-pasivade dos nodos de los servidores de NFS Ganesha. El programa de instalación requiere SUSE LinuxEnterprise High Availability Extension. Los dos nodos se denominan earth y mars .
Importante: coubicación de serviciosLos servicios que tienen su propia tolerancia a errores y su propio equilibrio de carga nodeben ejecutarse en nodos de clúster que se aíslan para los servicios de failover. Por lotanto, no ejecute los servicios de Ceph Monitor, el servidor de metadatos, iSCSI ni CephOSD en configuraciones de alta disponibilidad.
Para obtener información sobre SUSE Linux Enterprise High Availability Extension, consultehttps://www.suse.com/documentation/sle-ha-15/ .
12.3.1 Instalación básica
En esta configuración earth tiene la dirección IP 192.168.1.1 y mars tiene la dirección192.168.1.2 .
Asimismo, se usan dos direcciones IP virtuales otantes que permiten a los clientes conectarseal servicio independientemente del nodo físico en el que se estén ejecutando. 192.168.1.10 seusa para la administración del clúster con Hawk2 y 192.168.2.1 se usa exclusivamente paralas exportaciones NFS. De esta forma es más fácil aplicar más tarde restricciones de seguridad.
144 Configuración activa-pasiva de alta disponibilidad SES 6
El procedimiento siguiente describe la instalación de ejemplo. Encontrará másinformación en https://www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/
art_sleha_install_quick.html .
1. Prepare los nodos de NFS Ganesha en el master de Salt:
a. Ejecute las fases 0 y 1 de DeepSea.
root@master # salt-run state.orch ceph.stage.0root@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*.slsrole-ganesha/cluster/mars*.sls
c. Ejecute las fases 2 a 4 de DeepSea.
root@master # salt-run state.orch ceph.stage.2root@master # salt-run state.orch ceph.stage.3root@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. Instale 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
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
145 Instalación básica SES 6
6. En ambos nodos, inhabilite el inicio automático del servicio NFS Ganesha durante elarranque:
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 configurarel 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=30scrm(live)configure# clone nfs-ganesha-clone nfs-ganesha-server meta interleave=truecrm(live)configure# commitcrm(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)# statusOnline: [ earth mars ]Full list of resources: Clone Set: nfs-ganesha-clone [nfs-ganesha-server] Started: [ earth mars ] ganesha-ip (ocf::heartbeat:IPaddr2): Started earth
10. Para configurar una relación entre el servidor de NFS Ganesha y la dirección IP virtualotante, utilice la colocación y el orden.
146 Instalación básica SES 6
crm(live)configure# colocation ganesha-ip-with-nfs-ganesha-server inf: ganesha-ip nfs-ganesha-clonecrm(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 configuración delclú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, elrecurso 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 earthroot@earth # crm resource cleanup ganesha-ip earth
12.3.3 Configuración del recurso de Ping
Puede suceder que el servidor no pueda acceder al cliente debido a un problema de red. Unrecurso de ping puede detectar y solucionar este problema. La configuración de este recursoes opcional.
1. Dena 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
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 dela red. Si un cliente debe tener acceso continuo al servidor de NFS, añádalo a host_list .
147 Limpieza de recursos SES 6
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 servicioa 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 configuración de alta disponibilidad de NFS Ganesha. Para evitar queDeepSea falle después de configurar la alta disponibilidad de NFS Ganesha, excluya el inicio yla 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 quedecomo sigue:
include:- .keyring- .install- .configure
3. Añada la línea siguiente a /srv/pillar/ceph/stack/global.yml :
ganesha_init: ha
12.4 Configuración activa-activaEsta sección proporciona un ejemplo de configuración activa-activa sencilla de NFS Ganesha.El objetivo es distribuir dos servidores de NFS Ganesha en capas sobre el mismo CephFSexistente. Los servidores serán dos nodos de clúster de Ceph con direcciones independientes. Losclientes deben distribuirse entre ellos manualmente. En esta configuración, “failover” signicadesmontar y volver a montar manualmente el otro servidor en el cliente.
148 Alta disponibilidad de NFS Ganesha y DeepSea SES 6
12.4.1 Requisitos previos
Para nuestra configuración de ejemplo, necesita lo siguiente:
El clúster de Ceph en ejecución. Consulte la Sección 5.3, “Distribución del clúster” para obtenermás información sobre la distribución y configuración del clúster de Ceph medianteDeepSea.
Al menos un CephFS configurado. Consulte el Capítulo 11, Instalación de CephFS para obtenermás información sobre la distribución y configuración de CephFS.
Dos nodos de clúster de Ceph con NFS Ganesha distribuido. Consulte el Capítulo 12, Insta-
lación de NFS Ganesha para obtener más información sobre la distribución de NFS Ganesha.
Sugerencia: uso de servidores dedicadosAunque los nodos de NFS Ganesha pueden compartir recursos con otros serviciosrelacionados con Ceph, se recomienda usar servidores dedicados para mejorar elrendimiento.
Después de distribuir los nodos de NFS Ganesha, verique que el clúster está operativo y quelos repositorios CephFS por defecto están allí:
cephadm@adm > rados lspoolscephfs_datacephfs_metadata
12.4.2 Configuración de NFS Ganesha
Compruebe que ambos nodos de NFS Ganesha tengan instalado el archivo /etc/ganesha/ganesha.conf . Añada los bloques siguientes, si aún no existen, al archivo de configuración parahabilitar RADOS como back-end de recuperación de NFS Ganesha.
NFS_CORE_PARAM{ Enable_NLM = false; Enable_RQUOTA = false; Protocols = 4;}NFSv4{
149 Requisitos previos SES 6
RecoveryBackend = rados_cluster; Minor_Versions = 1,2;}CACHEINODE { Dir_Chunk = 0; NParts = 1; Cache_Size = 1;}RADOS_KV{ pool = "rados_pool"; namespace = "pool_namespace"; nodeid = "fqdn" UserId = "cephx_user_id"; Ceph_Conf = "path_to_ceph.conf"}
Puede averiguar los valores para rados_pool y pool_namespace comprobando la línea yaexistente en la configuración del formulario:
%url rados://rados_pool/pool_namespace/...
El valor para la opción nodeid corresponde al nombre completo de la máquina. Los valores delas opciones UserId y Ceph_Conf se pueden encontrar en el bloque RADOS_URLS ya existente.
Debido a que las versiones heredadas de NFS impiden levantar el período de gracia antes detiempo y, por lo tanto, prolongan el reinicio del servidor, se han inhabilitado las opciones corres-pondientes a versiones de NFS anteriores a la 4.2. También se ha inhabilitado la mayor partedel almacenamiento en caché de NFS Ganesha, ya que las bibliotecas de Ceph ya realizan unalmacenamiento en caché agresivo.
El back-end de recuperación "rados_cluster" almacena su información en objetos RADOS. Aunqueno es una gran cantidad de datos, queremos que tenga alta disponibilidad. Con este objetivose usa el repositorio de metadatos de cephFS y se declara en él un nuevo espacio de nombres"ganesha" para mantenerlo diferenciado de los objetos CephFS.
Nota: IDs de nodo de clústerLa mayor parte de la configuración es idéntica entre los dos hosts, sin embargo, la opciónnodeid del bloque "RADOS_KV" debe ser una cadena exclusiva para cada nodo. Pordefecto, NFS Ganesha dene en nodeid el nombre de host del nodo.
Si necesita utilizar valores jos diferentes a los nombres de host, puede por ejemplo denirnodeid = 'a' en un nodo y nodeid = 'b' en el otro.
150 Configuración de NFS Ganesha SES 6
12.4.3 Relleno de la base de datos de gracia del clúster
Necesitamos vericar que todos los nodos del clúster son conscientes de los demás. Eso se hacemediante un objeto RADOS que se comparte entre los hosts. NFS Ganesha utiliza este objetopara comunicar el estado actual en relación a un período de gracia.
El paquete nfs-ganesha-rados-grace contiene una herramienta de línea de comandos paraconsultar y manipular esta base de datos. Si el paquete no está instalado en al menos uno delos nodos, instálelo con:
root # zypper install nfs-ganesha-rados-grace
El comando se usa para crear la base de datos y añadir ambos nodeid . En nuestro ejemplo, losdos nodos NFS Ganesha se denominan ses6min1.example.com y ses6min2.example.com . Enuno de los hosts de NFS Ganesha, ejecute:
cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha add ses6min1.example.comcephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha add ses6min2.example.comcephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganeshacur=1 rec=0======================================================ses6min1.example.com Eses6min2.example.com E
Esto crea la base de datos de gracia y le añade "ses6min1.example.com" y "ses6min2.exam-ple.com". El último comando vuelca el estado actual. Los hosts recién añadidos siempre se consi-deran que aplican el período de gracia, por lo que ambos tienen el indicador "E" denido. Losvalores "cur" y "rec" muestran las épocas actuales y de recuperación, que es cómo se realiza unseguimiento de qué hosts pueden realizar la recuperación y cuándo.
12.4.4 Reinicio de servicios de NFS Ganesha
En ambos nodos de NFS Ganesha, reinicie los servicios relacionados:
root # systemctl restart nfs-ganesha.service
Después de reiniciar los servicios, compruebe la base de datos de gracia:
cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganeshacur=3 rec=0======================================================ses6min1.example.com
151 Relleno de la base de datos de gracia del clúster SES 6
ses6min2.example.com
Nota: se ha borrado el indicador "E"Tenga en cuenta que en ambos nodos se ha borrado el indicador "E", lo que indica que yano están aplicando el período de gracia y ahora están en modo de funcionamiento normal.
12.4.5 Conclusión
Después de completar todos los pasos anteriores, puede montar el NFS exportado desdecualquiera de los dos servidores de NFS Ganesha y realizar operaciones NFS normales en ellos.
En la configuración de ejemplo se supone que si uno de los dos servidores de NFS Ganesha seapaga, se reiniciará manualmente en 5 minutos. Después de 5 minutos, el servidor de metadatospuede cancelar la sesión del cliente de NFS Ganesha y todo el estado asociado a él. Si las capaci-dades de la sesión se cancelan antes de que el resto del clúster entre en el período de gracia, esposible que los clientes del servidor no puedan recuperar todo su estado.
12.5 Más informaciónEncontrará más información en Libro “Guía de administración”, Capítulo 21 “NFS Ganesha: exportación
de datos de Ceph a través de NFS”.
152 Conclusión SES 6
IV Distribución de clústeres sobre laplataforma SUSE CaaS 4 (versiónpreliminar de tecnología)
13 SUSE Enterprise Storage 6 sobre clúster de Kubernetes de SUSE CaaSPlatform 4 154
13 SUSE Enterprise Storage 6 sobre clúster de Kuber-netes de SUSE CaaS Platform 4
Aviso: tecnología en fase preliminarEjecutar clústeres de Ceph en contenedores en SUSE CaaS Platform es una tecnología enfase preliminar. No realice la distribución en un clúster de Kubernetes de producción.
En este capítulo se describe cómo distribuir SUSE Enterprise Storage 6 en contenedores sobreel clúster de Kubernetes de SUSE CaaS Platform 4.
13.1 ObservacionesAntes de iniciar la distribución, tenga en cuenta los puntos siguientes:
Para ejecutar Ceph en Kubernetes, SUSE Enterprise Storage 6 utiliza un proyecto de fasesanteriores denominado Rook (https://rook.io/ ).
Dependiendo de la configuración, Rook puede consumir todos los discos sin utilizar detodos los nodos de un clúster de Kubernetes.
La configuración requiere contenedores con privilegios.
13.2 Requisitos previosAntes de iniciar la distribución, debe tener lo siguiente:
Un clúster de SUSE CaaS Platform 4 en ejecución.
Nodos de trabajo de SUSE CaaS Platform 4 con varios discos adicionales conectados comoalmacenamiento para el clúster de Ceph.
154 Observaciones SES 6
13.3 Obtención de manifiestos de RookEl orquestador Rook utiliza archivos de configuración en formato YAML denominadosmaniestos. Los maniestos que se necesitan están incluidos en el paquete RPM rook-k8s-yaml .Para instalarlo, ejecute:
root # zypper install rook-k8s-yaml
13.4 InstalaciónRook-Ceph incluye dos componentes principales: el "operador" que es ejecutado por Kubernetesy permite la creación de clústeres de Ceph, y el propio "clúster" de Ceph que es creado y adminis-trado parcialmente por el operador.
13.4.1 Configuración
13.4.1.1 Configuración global
Los maniestos utilizados en esta configuración instalan todos los componentes de Rook y Cephen el espacio de nombres "rook-ceph". Si necesita cambiarlo, adopte en consecuencia todas lasreferencias al espacio de nombres en los maniestos de Kubernetes.
Dependiendo de las características de Rook que tenga previstas usar, modique la configuraciónde "Política de seguridad de pods" en common.yaml para limitar los requisitos de seguridad deRook. Consulte los comentarios del archivo de maniesto.
13.4.1.2 Configuración del operador
El maniesto operator.yaml congura el operador de Rook. Por lo general, no es necesarioefectuar ningún cambio. Encontrará más información en los comentarios del archivo demaniesto.
155 Obtención de manifiestos de Rook SES 6
13.4.1.3 Configuración del clúster de Ceph
El maniesto cluster.yaml es el responsable de configurar el clúster de Ceph actual que seejecutará en Kubernetes. Encontrará una descripción detallada de todas las opciones disponiblesen la documentación de Rook en https://rook.io/docs/rook/v1.0/ceph-cluster-crd.html .
Por defecto, Rook está configurado para utilizar todos los nodos que no están contaminadoscon node-role.kubernetes.io/master:NoSchedule y aceptará los ajustes de colocaciónconfigurados (consulte https://rook.io/docs/rook/v1.0/ceph-cluster-crd.html#placement-configu-
ration-settings ). En el ejemplo siguiente, se inhabilita este comportamiento y solo se utilizanlos nodos mostrados explícitamente en la sección de nodos:
storage: useAllNodes: false nodes: - name: caasp4-worker-0 - name: caasp4-worker-1 - name: caasp4-worker-2
NotaPor defecto, Rook está configurado para usar todos los discos libres y vacíos de cada nodopara su uso como almacenamiento de Ceph.
13.4.1.4 Documentación
La documentación de Rook-Ceph de https://rook.github.io/docs/rook/master/ceph-stora-
ge.html contiene información más detallada sobre la configuración de distribuciones másavanzadas. Utilícela como referencia para comprender los conceptos básicos de Rook-Cephantes de realizar configuraciones más avanzadas.
Encontrará más detalles sobre el producto SUSE CaaS Platform en https://www.su-
se.com/documentation/suse-caasp .
156 Configuración SES 6
13.4.2 Creación del operador de Rook
Para instalar los componentes comunes de Rook-Ceph, las funciones CSI y el operador Rook-Ceph, ejecute el comando siguiente en el nodo master de SUSE CaaS Platform:
root # kubectl apply -f common.yaml -f operator.yaml
common.yaml creará el espacio de nombres "rook-ceph"; definiciones de recursos personalizadosde Ceph (CRD, consulte https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/
custom-resources/ ) para que Kubernetes tenga constancia de los objetos de Ceph (por ejemplo,"CephCluster"), y las funciones RBAC y las directivas de seguridad de pods (consulte https://
kubernetes.io/docs/concepts/policy/pod-security-policy/ ), que son necesarias para permitir queRook gestione los recursos específicos del clúster.
Sugerencia: uso de hostNetwork y hostPortsSi en la denición de recursos del clúster se usa hostNetwork: true es necesario usarhostNetwork . También es necesario usar hostPorts en PodSecurityPolicy .
Verique la instalación ejecutando kubectl get pods -n rook-ceph en el nodo master deSUSE CaaS Platform, por ejemplo:
root # kubectl get pods -n rook-cephNAME READY STATUS RESTARTS AGErook-ceph-agent-57c9j 1/1 Running 0 22hrook-ceph-agent-b9j4x 1/1 Running 0 22hrook-ceph-operator-cf6fb96-lhbj7 1/1 Running 0 22hrook-discover-mb8gv 1/1 Running 0 22hrook-discover-tztz4 1/1 Running 0 22h
13.4.3 Creación del clúster de Ceph
Después de modicar cluster.yaml según sus necesidades, puede crear el clúster de Ceph.Ejecute el comando siguiente en el nodo master de SUSE CaaS Platform:
root # kubectl apply -f cluster.yaml
Observe el espacio de nombres "rook-ceph" para comprobar qué clúster de Ceph se va a crear.Verá tantos monitores Ceph Monitor como haya configurados en el maniesto cluster.yaml(el valor por defecto es 3), una instancia de Ceph Manager y tantos daemons Ceph OSD comodiscos libres tenga.
157 Creación del operador de Rook SES 6
Sugerencia: pods OSD temporalesAl arrancar el clúster de Ceph, verá ejecutarse algunos pods con el nombre rook-ceph-osd-prepare-NOMBRE-NODO durante un tiempo que, después, terminarán con el estado"Completado". Como su nombre indica, estos pods sirven para provisionar los Ceph OSD.No se suprimen para que pueda inspeccionar sus registros cuando terminen. Por ejemplo:
root # kubectl get pods --namespace rook-cephNAME READY STATUS RESTARTS AGErook-ceph-agent-57c9j 1/1 Running 0 22hrook-ceph-agent-b9j4x 1/1 Running 0 22hrook-ceph-mgr-a-6d48564b84-k7dft 1/1 Running 0 22hrook-ceph-mon-a-cc44b479-5qvdb 1/1 Running 0 22hrook-ceph-mon-b-6c6565ff48-gm9wz 1/1 Running 0 22hrook-ceph-operator-cf6fb96-lhbj7 1/1 Running 0 22hrook-ceph-osd-0-57bf997cbd-4wspg 1/1 Running 0 22hrook-ceph-osd-1-54cf468bf8-z8jhp 1/1 Running 0 22hrook-ceph-osd-prepare-caasp4-worker-0-f2tmw 0/2 Completed 0 9m35srook-ceph-osd-prepare-caasp4-worker-1-qsfhz 0/2 Completed 0 9m33srook-ceph-tools-76c7d559b6-64rkw 1/1 Running 0 22hrook-discover-mb8gv 1/1 Running 0 22hrook-discover-tztz4 1/1 Running 0 22h
13.5 Uso de Rook como almacenamiento para lacarga de trabajo de KubernetesRook permite utilizar tres tipos diferentes de almacenamiento:
Almacenamiento de objeto
El almacenamiento de objeto expone una API de S3 al clúster de almacenamiento para quelas aplicaciones coloquen y obtengan datos. Consulte https://rook.io/docs/rook/v1.0/ceph-
object.html para obtener una descripción detallada.
Sistema de archivos compartido
Es posible montar un sistema de archivos compartido con permisos de lectura y escrituradesde varios pods. Esto resulta útil para las aplicaciones que se agrupan en clúster medianteun sistema de archivos compartido. Consulte https://rook.io/docs/rook/v1.0/ceph-filesys-
tem.html para obtener una descripción detallada.
158 Uso de Rook como almacenamiento para la carga de trabajo de Kubernetes SES 6
Almacenamiento de bloques
El almacenamiento de bloques permite montar el almacenamiento en un solo pod. Consultehttps://rook.io/docs/rook/v1.0/ceph-block.html para obtener una descripción detallada.
13.6 Desinstalación de RookPara desinstalar Rook, siga estos pasos:
1. Suprima todas las aplicaciones de Kubernetes que consuman almacenamiento de Rook.
2. Suprima todos los objetos, archivos o artefactos de almacenamiento de bloques que hayacreado siguiendo las instrucciones de la Sección 13.5, “Uso de Rook como almacenamiento para
la carga de trabajo de Kubernetes”.
3. Suprima el clúster de Ceph, el operador y los recursos relacionados:
root # kubectl delete -f cluster.yamlroot # kubectl delete -f operator.yamlroot # kubectl delete -f common.yaml
4. Suprima los datos de los hosts:
root # rm -rf /var/lib/rook
5. Si fuera necesario, limpie los discos utilizados por Rook. Consulte https://rook.io/docs/
rook/master/ceph-teardown.html para obtener más información.
159 Desinstalación de Rook SES 6
A Actualizaciones de mantenimiento de Cephbasadas en versiones secundarias superiores deNautilus
Varios paquetes clave de SUSE Enterprise Storage 6 se basan en las distintas versiones de Nautilusde Ceph. Cuando el proyecto Ceph (https://github.com/ceph/ceph ) publica nuevas versionessecundarias de la serie Nautilus, SUSE Enterprise Storage 6 se actualiza para garantizar que elproducto se benecia de las últimas correcciones de errores y actualizaciones retroactivas decaracterísticas de esas versiones.
Este capítulo contiene un resumen de los principales cambios incluidos en cada versión secun-daria posterior que se ha incluido en el producto, o que se tiene previsto incluir.
Nautilus 14.2.4En esta versión se corrige una regresión grave que se publicó por error en la versión 14.2.3. Estaregresión no afecta a los clientes de SUSE Enterprise Storage, ya que no enviamos una versiónbasada en 14.2.3.
Nautilus 14.2.3
Se ha corregido una vulnerabilidad de denegación de servicio en la que un cliente noautenticado de Ceph Object Gateway podía desencadenar una detención por fallo a partirde una excepción no detectada.
Los clientes de librbd basados en Nautilus ahora pueden abrir imágenes en clústeres deJewel.
Se ha eliminado num_rados_handles de Object Gateway. Si en num_rados_handlesutilizaba un valor mayor que 1, multiplique los parámetros actuales de objec-
ter_inflight_ops y objecter_inflight_op_bytes por el valor antiguo de num_ra-dos_handles para obtener el mismo comportamiento de transmisión.
El modo seguro del protocolo Messenger v2 ya no está en fase experimental en esta versión.Ahora es el modo de conexión preferido para los monitores.
160 Nautilus 14.2.4 SES 6
El valor de osd_deep_scrub_large_omap_object_key_threshold se ha reducido paraque detecte un objeto con un gran número de claves omap más fácilmente.
Ceph Dashboard ahora admite que se silencien las notificaciones de Prometheus.
Nautilus 14.2.2
Los comandos relacionados con no{up,down,in,out} se han renovado. Ahora hay dosformas de denir los indicadores no{up,down,in,out} : el comando antiguo
ceph osd [un]set FLAG
que establece indicadores para todo el clúster, y el comando nuevo
ceph osd [un]set-group FLAGS WHO
que establece indicadores en lote al nivel de detalle de cualquier nodo de CRUSH o declase de dispositivo.
En radosgw-admin se incluyen dos subcomandos que permiten la gestión de objetoscaducados que, en versiones anteriores de Object Gateway, podían quedarse olvidadosdespués de volver a fragmentar un depósito. Un subcomando muestra estos objetos y elotro los suprime.
Las versiones anteriores de Nautilus (14.2.1 y 14.2.0) tienen un problema por el que aldistribuir un nuevo OSD de Nautilus BlueStore en un clúster actualizado (es decir, enun clúster distribuido originalmente antes que Nautilus), las estadísticas de utilizacióndel repositorio que emite ceph df son incorrectas. Hasta que todos los OSD se hayanreaprovisionado o actualizado (mediante ceph-bluestore-tool repair ), las estadísticasdel repositorio mostrarán valores inferiores al verdadero. Este problema se resolvió en laversión 14.2.2, de modo que el clúster solo empieza a usar las estadísticas más precisaspor repositorio después de que todos los OSD sean de la versión 14.2.2 o posterior, seanalmacenamiento en bloque y se hayan actualizado mediante la función de reparación sise crearon antes que Nautilus.
El valor por defecto para mon_crush_min_required_version ha cambiado de fireflya hammer , lo que signica que el clúster emitirá una advertencia de estado si los CRUSHoptimizables son anteriores a Hammer. Al cambiar a elementos optimizables de Hammer,generalmente hay una pequeña cantidad de datos (siempre hay alguno) que se moverá.
161 Nautilus 14.2.2 SES 6
Si es posible, se recomienda denir el cliente permitido más antiguo a hammer o unaversión posterior. Para mostrar cuál es el cliente más antiguo permitido actual, ejecute:
cephadm@adm > ceph osd dump | grep min_compat_client
Si el valor actual es anterior a hammer , ejecute el comando siguiente para determinarsi es seguro realizar este cambio verificando que no hay clientes anteriores a Hammerconectados actualmente al clúster:
cephadm@adm > ceph features
El tipo de depósito CRUSH más reciente, straw2 , se incluyó en Hammer. Si verica quetodos los clientes son Hammer o de una versión posterior, solo permite que se usen lasfunciones nuevas compatibles para las papeleas straw2 , incluido el modo crush-compatpara el equilibrador (Libro “Guía de administración”, Capítulo 10 “Módulos de Ceph Manager”,
Sección 10.1 “Equilibrador”).
Encontrará más información sobre el parche en https://download.suse.com/Download?
buildid=D38A7mekBz4~ .
Nautilus 14.2.1Esta fue la primera versión secundaria después de la publicación original de Nautilus (14.2.0).La versión original ("Disponibilidad general" o "GA") de SUSE Enterprise Storage 6 se basabaen esta versión secundaria.
162 Nautilus 14.2.1 SES 6
Glosario
General
Árbol de enrutamientoUn término dado a cualquier diagrama que muestre las diversas rutas que un receptor puedeejecutar.
Conjunto de reglasLas reglas para determinar la ubicación de los datos de un repositorio.
CRUSH, mapa de CRUSHCRUSH: Controlled Replication Under Scalable Hashing (réplica controlada bajo hashescalable) es un algoritmo que determina cómo se deben almacenar y recuperar los datoscalculando las ubicaciones de almacenamiento de los datos. CRUSH requiere un mapa delclúster para almacenar de forma pseudoaleatoria y recuperar los datos de los OSD con unadistribución uniforme de los datos por el clúster.
DepósitoUn punto que añade otros nodos en una jerarquía de ubicaciones físicas.
Importante: no confundir con los depósitos S3Los depósitos o contenedores S3 representan diferentes términos que significan carpetaspara almacenar objetos.
NodoCualquier equipo o servidor único de un clúster de Ceph.
Nodo de administraciónEl nodo en el que se ejecuta la utilidad ceph-deploy para distribuir Ceph en los nodos OSD.
Nodo de monitor, MONUn nodo de clúster donde se guardan los mapas de estado del clúster, incluida la asignaciónde monitor o la asignación de OSD.
163 SES 6
Nodo OSDUn nodo de clúster donde se almacenan los datos; se gestiona la réplica de los datos, larecuperación, la reposición y el reequilibrio, y que proporciona detalles de supervisión a losmonitores Ceph Monitor mediante la comprobación de otros daemons Ceph OSD.
OSDDependiendo del contexto, Object Storage Device (dispositivo de almacenamiento de objeto)u Object Storage Daemon (daemon de almacenamiento de objeto). El daemon ceph-osd esel componente de Ceph responsable de almacenar objetos en un sistema de archivos local yde proporcionar acceso a ellos a través de la red.
PGGrupo de colocación: una subdivisión de un repositorio que se utiliza para ajustar el rendi-miento.
RepositorioLas particiones lógicas para almacenar los objetos, como las imágenes de disco.
Términos específicos de Ceph
AlertmanagerUn binario que gestiona las alertas enviadas por el servidor Prometheus y notica al usuarional.
Clúster de almacenamiento de CephEl conjunto principal de software de almacenamiento donde se almacenan los datos delusuario. Dicho conjunto está formado por los monitores Ceph Monitor y los OSD.
También conocido como “almacén de objetos de Ceph”.
GrafanaSolución de análisis y supervisión de bases de datos.
PrometheusKit de herramientas de supervisión y alerta de sistemas.
164 SES 6
Términos específicos de Object Gateway
Módulo de sincronización de archivosMódulo que permite crear una zona de Object Gateway para mantener el historial deversiones de objetos de S3.
Object GatewayEl componente de pasarela S3/Swift para el almacén de objetos de Ceph.
165 SES 6
B Actualizaciones de la documentación
En este capítulo se indican los cambios realizados en el contenido de este documento desdeel lanzamiento de la última actualización de mantenimiento de SUSE Enterprise Storage 5.Encontrará los cambios relacionados con la distribución del clúster que se aplican a versionesanteriores en https://www.suse.com/documentation/suse-enterprise-storage-5/book_storage_de-
ployment/data/ap_deploy_docupdate.html .
El documento se actualizó en las fechas siguientes:
Sección B.1, “Actualización de mantenimiento de la documentación de SUSE Enterprise Storage 6”
Sección B.2, “Junio de 2019 (lanzamiento de SUSE Enterprise Storage 6)”
B.1 Actualización de mantenimiento de ladocumentación de SUSE Enterprise Storage 6ACTUALIZACIONES GENERALES
Se sugiere que se ejecute rpmconfigcheck para evitar la pérdida de los cambios localesen la Sección 6.8, “Actualización por nodo: procedimiento básico” (https://jira.suse.com/browse/
SES-348 ).
Se ha añadido la Libro “Guía de administración”, Capítulo 15 “Mejora del rendimiento con el caché
de LVM” (https://jira.suse.com/browse/SES-269 ).
Se ha añadido el Capítulo 13, SUSE Enterprise Storage 6 sobre clúster de Kubernetes de SUSE CaaS
Platform 4 (https://jira.suse.com/browse/SES-720 ).
SOLUCIÓN DE ERRORES
Se ha añadido una sugerencia sobre la supervisión del estado de los nodos del clústerdurante la actualización en la Sección 6.9, “Actualización del nodo de administración” (https://
bugzilla.suse.com/show_bug.cgi?id=1154568 ).
Se ha añadido la Sección 6.8.2, “Actualización de nodos con el sistema de migración de distribución
de SUSE” (https://bugzilla.suse.com/show_bug.cgi?id=1154438 ).
El capítulo sobre actualizaciones se ha hecho secuencial, Capítulo 6, Actualización desde
versiones anteriores (https://bugzilla.suse.com/show_bug.cgi?id=1144709 ).
166 Actualización de mantenimiento de la documentación de SUSE Enterprise Storage 6 SES 6
Se ha añadido una entrada del registro de cambios para Ceph 14.2.4 (https://bugzilla.su-
se.com/show_bug.cgi?id=1151881 ).
Se ha unicado el nombre del repositorio "cephfs_metadata" en los ejemplos del Capítulo 12,
Instalación de NFS Ganesha (https://bugzilla.suse.com/show_bug.cgi?id=1148548 ).
Se ha actualizado la Sección 5.5.2.1, “Especificación” para que incluya valores más realistas(https://bugzilla.suse.com/show_bug.cgi?id=1148216 ).
Se han añadido dos nuevos repositorios para "Module-Desktop", ya que nuestros clientesutilizan principalmente la GUI en la Sección 6.8.1, “Actualización manual de nodo mediante el
DVD del instalador” (https://bugzilla.suse.com/show_bug.cgi?id=1144897 ).
deepsea-cli no es una dependencia de deepsea en la Sección 5.4, “Interfaz de línea de
comandos de DeepSea” (https://bugzilla.suse.com/show_bug.cgi?id=1143602 ).
Se ha añadido una sugerencia para migrar ntpd a chronyd en la Sección 6.1, “Puntos
que se deben tener en cuenta antes de la actualización” (https://bugzilla.suse.com/show_bug.cgi?
id=1135185 ).
Se ha añadido la Libro “Guía de administración”, Capítulo 2 “Administración de un clúster de
Salt”, Sección 2.15 “Desactivación de perfiles ajustados” (https://bugzilla.suse.com/show_bug.cgi?
id=1130430 ).
Se plantea la posibilidad de migrar todo el nodo OSD en la Sección 6.16.3, “Distribución de
OSD” (https://bugzilla.suse.com/show_bug.cgi?id=1138691 ).
Se ha añadido un punto sobre la migración de nombres del MDS en la Sección 6.1, “Puntos
que se deben tener en cuenta antes de la actualización” (https://bugzilla.suse.com/show_bug.cgi?
id=1138804 ).
B.2 Junio de 2019 (lanzamiento de SUSE EnterpriseStorage 6)ACTUALIZACIONES GENERALES
Se ha añadido la Sección 5.5.2, “DriveGroups” (jsc n.º SES-548).
Se ha reescrito el Capítulo 6, Actualización desde versiones anteriores (jsc n.º SES-88).
167 Junio de 2019 (lanzamiento de SUSE Enterprise Storage 6) SES 6
Se ha añadido la Sección 7.2.1, “Habilitación de IPv6 para la distribución del clúster de Ceph” (jscn.º SES-409).
Block Storage se ha convertido en el motor de almacenamiento por defecto (Fate n.º325658).
Se han eliminado todas las referencias a la documentación en línea externa y se hanreemplazado por el contenido pertinente (Fate n.º 320121).
SOLUCIÓN DE ERRORES
Se ha añadido información sobre AppArmor durante la actualización en la Sección 6.1,
“Puntos que se deben tener en cuenta antes de la actualización” (https://bugzilla.su-
se.com/show_bug.cgi?id=1137945 ).
Se ha añadido información sobre los clústeres CDTB que no admiten la actualización enlínea en la Sección 6.1, “Puntos que se deben tener en cuenta antes de la actualización” (https://
bugzilla.suse.com/show_bug.cgi?id=1129108 ).
Se ha añadido información sobre la coubicación de los servicios de Ceph en configuracionesde alta disponibilidad en la Sección 12.3, “Configuración activa-pasiva de alta disponibilidad”
(https://bugzilla.suse.com/show_bug.cgi?id=1136871 ).
Se ha añadido una sugerencia sobre los paquetes huérfanos en la Sección 6.8, “Actualización
por nodo: procedimiento básico” (https://bugzilla.suse.com/show_bug.cgi?id=1136624 ).
Se ha actualizado profile-* con role-storage en Sugerencia: distribución de nodos de
monitor sin definir perfiles de OSD (https://bugzilla.suse.com/show_bug.cgi?id=1138181 ).
Se ha añadido la Sección 6.16, “Migración de distribuciones basadas en perfiles a DriveGroups”
(https://bugzilla.suse.com/show_bug.cgi?id=1135340 ).
Se ha añadido la Sección 6.11, “Actualización de servidores de metadatos” (https://bugzilla.su-
se.com/show_bug.cgi?id=1135064 ).
Se debe reducir el tamaño del clúster del MDS en la Sección 6.1, “Puntos que se deben tener
en cuenta antes de la actualización” (https://bugzilla.suse.com/show_bug.cgi?id=1134826 ).
Se ha cambiado el archivo de configuración a /srv/pillar/ceph/stack/global.yml(https://bugzilla.suse.com/show_bug.cgi?id=1129191 ).
Se han actualizado varias partes de Libro “Guía de administración”, Capítulo 20 “Exportación de
datos de Ceph a través de Samba” (https://bugzilla.suse.com/show_bug.cgi?id=1101478 ).
168 Junio de 2019 (lanzamiento de SUSE Enterprise Storage 6) SES 6
master_minion.sls se ha eliminado en la Sección 5.3, “Distribución del clúster” (https://
bugzilla.suse.com/show_bug.cgi?id=1090921 ).
Se menciona el paquete deepsea-cli en la Sección 5.4, “Interfaz de línea de comandos de
DeepSea” (https://bugzilla.suse.com/show_bug.cgi?id=1087454 ).
169 Junio de 2019 (lanzamiento de SUSE Enterprise Storage 6) SES 6
