documentation.suse.com · Para obtener información sobre las marcas comerciales de SUSE, consulte ...
155
Guía de distribución SUSE Enterprise Storage 5
Transcript of documentation.suse.com · Para obtener información sobre las marcas comerciales de SUSE, consulte ...
Guía de distribución
SUSE Enterprise Storage 5
Guía de distribuciónSUSE Enterprise Storage 5por Tomáš Bažant, Jana Haláčková, y Sven Seeberg
Fecha de publicación: 02/09/2019
SUSE LLC10 Canal Park DriveSuite 200Cambridge MA 02141USA
https://www.suse.com/documentation
Copyright © 2019 SUSE LLC
Copyright © 2016, RedHat, Inc, and contributors.
El texto y las ilustraciones de este documento tienen licencia Creative Commons Attribution-Share Alike 4.0
International ("CC-BY-SA"). Hay disponible una descripción de CC-BY-SA en http://creativecommons.org/licenses/
by-sa/4.0/legalcode . En conformidad con la licencia CC-BY-SA, si distribuye este documento o una adaptación
del mismo, debe proporcionar la URL de la versión original.
Red Hat, Red Hat Enterprise Linux, el logotipo de Shadowman, JBoss, MetaMatrix, Fedora, el logotipo de 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 International Corporation
o sus liales en los Estados Unidos y otros países. MySQL® es una marca comercial registrada de MySQL AB
en los Estados Unidos, la Unión Europea y otros países. Todas las demás marcas comerciales pertenecen a sus
respectivos propietarios.
Para obtener información sobre las marcas comerciales de SUSE, consulte http://www.suse.com/company/legal/ .
Todas las marcas comerciales de otros fabricantes son propiedad de sus respectivas empresas. Los símbolos de
marca comercial (®,™ etc.) indican marcas comerciales de SUSE y sus 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 ix
I SUSE ENTERPRISE STORAGE 1
1 SUSE Enterprise Storage 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 Nodos de almacenamiento de objetos 11
Requisitos mínimos 11 • Tamaño mínimo de disco 12 • Tamaño
recomendado para el dispositivo WAL y DB de BlueStore 12 • Uso
de unidades SSD para diarios OSD 13 • Número máximo de discos
recomendados 14
2.2 Nodos de monitor 14
2.3 Nodos de Object Gateway 15
2.4 Nodos del servidor de metadatos 15
2.5 Master de Salt 15
2.6 Nodos iSCSI 16
iv Guía de distribución
2.7 Recomendaciones de red 16
Adición de una red privada a un clúster en ejecución 17 • Nodos de monitor
en subredes diferentes 17
2.8 Limitaciones de denominación 18
2.9 Un servidor compartido por varios OSD y monitores 18
2.10 Configuración mínima del clúster 19
2.11 Configuración de clúster de producción recomendada 20
2.12 SUSE Enterprise Storage y otros productos SUSE 21
SUSE Manager 21
3 Configuración de alta disponibilidad del nodo deadministración de Ceph 22
3.1 Esquema del clúster de alta disponibilidad para el nodo deadministración de Ceph 22
3.2 Vinculación del clúster de alta disponibilidad con nodo deadministración de Ceph 23
II DISTRIBUCIÓN Y ACTUALIZACIÓN DEL CLÚSTER 25
4 Distribución con DeepSea/Salt 264.1 Lectura de las notas de la versión 27
4.2 Introducción a DeepSea 27
Organización y ubicaciones importantes 29 • Asignación de destino de los
minions 29
4.3 Distribución del clúster 32
4.4 Interfaz de línea de comandos de DeepSea 39
Interfaz de línea de comandos de DeepSea: modo de monitor 40 • Interfaz
de línea de comandos de DeepSea: modo autónomo 41
4.5 Configuración y personalización 43
El archivo policy.cfg 43 • Archivo ceph.conf personalizado 50
v Guía de distribución
5 Actualización desde versiones anteriores 51
5.1 Lectura de las notas de la versión 51
5.2 Procedimiento de actualización general 51
5.3 Cifrado de OSD durante la actualización 53
5.4 Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea)a la versión 5 55
Migración de OSD a BlueStore 62
5.5 Actualización desde SUSE Enterprise Storage 4 (distribución de ceph-deploy) a la versión 5 64
5.6 Actualización desde SUSE Enterprise Storage 4 (distribución de Crowbar)a la versión 5 70
5.7 Actualización desde SUSE Enterprise Storage 3 a la versión 5 77
6 Copia de seguridad de la configuración delclúster 78
6.1 Copia de seguridad de la configuración de Salt 78
6.2 Copia de seguridad de la configuración de DeepSea 78
7 Personalización de la configuración por defecto 80
7.1 Uso de archivos de configuración personalizados 80
Inhabilitación de un paso de la distribución 80 • Sustitución
de un paso de la distribución 81 • Modificación de un paso
de la distribución 83 • Modificación de una etapa de la
distribución 84 • Inhabilitación de actualizaciones y reinicios durante la
fase 0 85
7.2 Modificación de la configuración descubierta 86
vi Guía de distribución
III INSTALACIÓN DE SERVICIOS ADICIONALES 89
8 Instalación de servicios para acceder a los datos 90
9 Ceph Object Gateway 91
9.1 Instalación manual de Object Gateway 91
Configuración de Object Gateway 92
10 Instalación de iSCSI Gateway 98
10.1 Almacenamiento de bloques iSCSI 98
Destino iSCSI de kernel de Linux 99 • Iniciadores iSCSI 99
10.2 Información general sobre lrbd 100
10.3 Consideraciones de distribución 102
10.4 Instalación y configuración 102
Distribución de iSCSI Gateway en un clúster de Ceph 103 • Creación
de imágenes RBD 103 • Exportación de imágenes RBD a través de
iSCSI 103 • Valores opcionales 106 • Valores avanzados 107
10.5 Exportación de imágenes del dispositivo de bloques RADOS mediantetcmu-runner 111
Instalación 112 • Configuración y distribución 112 • Uso 114
11 Instalación de CephFS 115
11.1 Escenarios admitidos de CephFS y directrices 115
11.2 Servidor de metadatos de Ceph 116
Adición de un servidor de metadatos 116 • Configuración de un servidor de
metadatos 116
11.3 CephFS 117
Creación de CephFS 117 • Tamaño del clúster del servidor de
metadatos 119 • Clúster de servidor de metadatos y actualizaciones 120
12 Instalación de NFS Ganesha 121
12.1 Preparación 121
Información general 121 • Resumen de requisitos 122
vii Guía de distribución
12.2 Instalación de ejemplo 122
12.3 Configuración activa-pasiva de alta disponibilidad 123
Instalación básica 124 • Limpieza de recursos 126 • Configuración del
recurso de Ping 126 • Alta disponibilidad de NFS Ganesha y DeepSea 127
12.4 Más información 127
13 Exportación de CephFS mediante Samba 128
13.1 Instalación de ejemplo 128
13.2 Configuración de alta disponibilidad 129
A Actualizaciones de la documentación 134A.1 Octubre de 2018 (lanzamiento de SUSE Enterprise Storage 5.5) 134
A.2 Noviembre de 2017 (actualización de mantenimiento) 137
A.3 Octubre de 2017 (lanzamiento de SUSE Enterprise Storage 5) 139
viii Guía de distribución
Acerca de esta guía
SUSE Enterprise Storage es una extensión de SUSE Linux Enterprise. Combina las funcionesdel proyecto de almacenamiento Ceph (http://ceph.com/ ) con la ingeniería empresarial y laasistencia de SUSE. SUSE Enterprise Storage proporciona a las organizaciones de TI la capacidadde implementar una arquitectura de almacenamiento distribuida que admite varios casos de usomediante plataformas de hardware básicas.
En esta guía se explican los conceptos de SUSE Enterprise Storage con el objetivo principal degestionar 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 disponible
Los manuales disponibles para este producto son los siguientes:
Libro “Guía de administración”
La guía describe varias tareas de administración que normalmente se llevan a cabo despué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.
ix Documentación disponible SES 5
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 acerca de este manual y del restode la documentación incluida junto con el producto. Utilice la función de comentariosdel usuario, 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
x Comentarios SES 5
Archivo, Archivo Guardar como: elementos de menú, botones_
Pingüinos que bailan (Capítulo Pingüinos, ↑Otro manual): referencia a un capítulo de 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 Ceph ContributorsThe Ceph project and its documentation is a result of hundreds of contributors and organizations.See https://ceph.com/contributors/ for more details.
xi Acerca de la elaboración de este manual SES 5
I SUSE Enterprise Storage
1 SUSE Enterprise Storage y Ceph 2
2 Requisitos y recomendaciones de hardware 11
3 Configuración de alta disponibilidad del nodo de administración deCeph 22
1 SUSE Enterprise Storage y Ceph
SUSE Enterprise Storage 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 y describe brevementelos 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 4, Distribución con DeepSea/Salt para obtener másinformación sobre el proceso de distribución.
1.1 Características de Ceph
El entorno Ceph incluye las siguientes características:
Capacidad de ampliación
Ceph puede ampliarse a miles de nodos y gestionar petabytes de almacenamiento.
Hardware básico
Para ejecutar un clúster de Ceph no se requiere ningún hardware especial. Para obtenerinformación, consulte el Capítulo 2, Requisitos y recomendaciones de hardware
2 Características de Ceph SES 5
Autoadministración
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 único punto 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.
3 Componentes básicos SES 5
CephFS
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 5
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 MGR, que se pueden colocar junto con daemons de MON. Cada clúster requiere al menosdaemons de MON, MGR y OSD:
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
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.
5 Nodos y daemons de Ceph SES 5
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
Ceph Object Gateway es una pasarela HTTP REST para el almacén de objetos RADOS. Escompatible 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.
6 Nodos y daemons de Ceph SES 5
1.3 Estructura de almacenamiento
1.3.1 Repositorio
Los objetos que se almacenan en un clúster de Ceph se colocan en repositorios. Los 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ón
Los grupos de colocación (PG) se utilizan para la distribución de datos dentro de un repositorio.Cuando se crea un repositorio, se 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 Ejemplo
Esta sección proporciona un ejemplo de cómo gestiona Ceph los datos (consulte la Figura 1.2,
“Ejemplo de Ceph a pequeña escala”). El ejemplo no representa una 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.0 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 5
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 5
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 5
Sugerencia: planificación del tamaño del dispositivo DBDebe realizar una planificación exhaustiva para asignar 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:
root@minion > 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 .
10 Información adicional SES 5
2 Requisitos y recomendaciones de hardware
Los requisitos de hardware de Ceph dependen en gran medida de la carga de trabajo de E/S. 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 Nodos de almacenamiento de objetos
2.1.1 Requisitos mínimos
Se necesitan al menos 4 nodos OSD, con 8 discos OSD cada uno.
Para los OSD que no usen BlueStore, se requiere como mínimo 1 GB de RAM por terabyte decapacidad OSD en bruto para cada nodo de almacenamiento OSD. Se recomiendan 1,5 GBde RAM por terabyte de capacidad OSD en bruto. Durante la recuperación, lo óptimo serían2 GB de RAM por terabyte de capacidad OSD en bruto.Para los OSD que utilicen BlueStore, calcule primero el tamaño de RAM que se recomiendapara los OSD que no utilizan BlueStore y, a continuación, calcule 2 GB más el tamaño delcaché de RAM de BlueStore para cada proceso de OSD. Elija el valor más alto de RAM deesos dos resultados. Tenga en cuenta que el caché de BlueStore por defecto es de 1 GB paraunidades HDD y 3 GB para unidades SSD. En resumen, elija el valor máximo de:
[1GB * OSD count * OSD size]
O
[(2 + BS cache) * OSD count]
Se requiere como mínimo 1,5 GHz de núcleo CPU lógico por OSD para cada proceso dedaemon de OSD. Se recomiendan 2 GHz por proceso de daemon de OSD. Tenga en cuentaque Ceph ejecuta un proceso de daemon de OSD por cada disco de almacenamiento; nocuente los discos reservados exclusivamente para usarse como diarios OSD, diarios WAL,metadatos omap o cualquier combinación de estos tres casos.
11 Nodos de almacenamiento de objetos SES 5
Ethernet de 10 Gb (dos interfaces de red vinculadas a varios conmutadores).
Discos OSD en configuraciones JBOD.
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.
Por motivos de rendimiento del disco, los nodos OSD deben instalarse desde cero y nodeben estar virtualizados.
2.1.2 Tamaño mínimo de disco
Existen dos tipos de espacio de disco necesarios para ejecutarse en OSD: el espacio para el 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.1.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.
A continuación se indican varias reglas para determinar el tamaño del dispositivo WAL/DB. Sise usa DeepSea para implementar los OSD con BlueStore, se aplican automáticamente las reglasrecomendadas y se notica el administrador al respecto.
12 Tamaño mínimo de disco SES 5
10 GB del dispositivo DB por cada terabyte de capacidad OSD (1/100 del OSD).
Entre 500 MB y 2 GB para el dispositivo WAL. El tamaño del WAL depende del tráco dedatos y la carga de trabajo, no del tamaño del OSD. Si sabe que un OSD es físicamente capazde gestionar pequeñas acciones de escritura y sobrescritura a un rendimiento muy elevado,es preferible disponer de dispositivos WAL en exceso a que su número sea insuficiente.Un dispositivo WAL de 1 GB es una opción equilibrada válida para la mayoría de lasdistribuciones.
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:
bluestore_block_db_path = "/path/to/db/device"bluestore_block_db_size = 10737418240bluestore_block_wal_path = ""bluestore_block_wal_size = 0
Si lo preere, puede colocar el dispositivo WAL en su propio dispositivo independiente.En tal caso, se recomienda usar el dispositivo más rápido para el funcionamiento de WAL.
2.1.4 Uso de unidades SSD para diarios OSD
Las unidades de estado sólido (SSD) no tienen piezas móviles. Esto reduce el tiempo de 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.
13 Uso de unidades SSD para diarios OSD SES 5
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.1.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. Para obtener un rendimiento óptimo, reserve al menos 2 GB de RAM por terabytede espacio de disco instalado.
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.
2.2 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 discos
14 Número máximo de discos recomendados SES 5
distintos, 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.3 Nodos de Object Gateway
Los nodos de Object Gateway deben tener de seis a ocho núcleos de CPU y 32 GB de RAM (serecomiendan 64 GB). Si hay otros procesos ubicados en el mismo equipo, deben sumarse susrequisitos.
2.4 Nodos del servidor de metadatos
El tamaño correcto de los nodos del servidor de metadatos depende del caso de uso especíco.Por lo general, cuantos más archivos abiertos deba gestionar el servidor de metadatos, más CPUy RAM se necesitará. A continuación se muestran los requisitos mínimos:
3 G de RAM por cada daemon del servidor de metadatos.
Interfaz de red vinculada.
2,5 GHz de CPU con un mínimo de 2 núcleos.
2.5 Master de Salt
Se requieren al menos 4 GB de RAM y una CPU de cuatro núcleos. Esto incluye la ejecuciónde openATTIC en el master de Salt. Para clústeres de gran tamaño con cientos de nodos, serecomiendan 6 GB de RAM.
15 Nodos de Object Gateway SES 5
2.6 Nodos iSCSI
Los nodos iSCSI deben tener de seis a ocho núcleos de CPU y 16 GB de RAM.
2.7 Recomendaciones de red
Es recomendable que el entorno de redes donde tenga previsto ejecutar Ceph sea un 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.
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"
16 Nodos iSCSI SES 5
2.7.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 .
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.
sudo systemctl start ceph.target
2.7.2 Nodos de monitor en subredes diferentes
Si los nodos de monitor se encuentran en varias subredes, por ejemplo, se encuentran 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 la sección global:
[global][...]mon host = 192.168.123.12, 1.2.3.4, 242.12.33.12mon initial members = MON1, MON2, MON3[...]
17 Adición de una red privada a un clúster en ejecución SES 5
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.8 Limitaciones de denominación
En 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.
2.9 Un servidor compartido por varios OSD ymonitores
Aunque 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.
18 Limitaciones de denominación SES 5
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.10 Configuración mínima del clúster
Cuatro nodos de almacenamiento de objetos
Ethernet de 10 Gb (dos redes vinculadas a varios conmutadores)
32 OSD por clúster de almacenamiento
El diario de OSD puede encontrarse en el disco de OSD
Un disco de SO dedicado para cada nodo de almacenamiento de objeto
1 GB de RAM por TB de capacidad de OSD en bruto para cada nodo de almacena-miento de objeto
1,5 GHz por OSD para cada nodo de almacenamiento de objeto
Los monitores Ceph Monitor, la pasarela y los servidores de metadatos pueden encon-trarse en los nodos de almacenamiento de objeto
Tres nodos de Ceph Monitor (se requiere SSD para la unidad de sistemaoperativo dedicada)
Los nodos de Ceph Monitor, de Object Gateway y de servidores de metadatosrequieren una distribución redundante
Las instancias de iSCSI Gateway, Object Gateway y los servidores de metadatosrequieren 4 GB de RAM incremental y cuatro núcleos
Nodo de gestión independiente con 4 GB de RAM, cuatro núcleos y 1 TB de capacidad
19 Configuración mínima del clúster SES 5
2.11 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
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
20 Configuración de clúster de producción recomendada SES 5
2.12 SUSE Enterprise Storage y otros productos SUSEEsta sección contiene información importante acerca de la integración de SUSE EnterpriseStorage con otros productos SUSE.
2.12.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.
21 SUSE Enterprise Storage y otros productos SUSE SES 5
3 Configuración de alta disponibilidad del nodo deadministración de Ceph
El nodo de administración de Ceph es un nodo de clúster de Ceph donde se ejecuta el serviciodel master de Salt. El nodo de administración es un punto central del clúster de Ceph porquegestiona el resto de los nodos del clúster consultando y dando instrucciones a los serviciosminion de Salt. Normalmente también incluye otros servicios; por ejemplo, la interfaz de usuarioWeb openATTIC con la consola Grafana respaldada por el kit de herramientas de supervisiónPrometheus.
En caso de que el nodo de administración de Ceph falle, lo habitual es que deba proporcionar unnuevo hardware que funcione para el nodo y que tenga que restaurar la pila de configuracióndel clúster completa a partir de una copia de seguridad reciente. Este método lleva bastantetiempo y 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 el clúster de alta disponibilidad (HA) para el nodo de administraciónde Ceph.
3.1 Esquema del clúster de alta disponibilidad para elnodo de administración de Ceph
La idea de un clúster de alta disponibilidad consiste en que, en caso de fallo del nodo del clúster,el otro nodo se haga cargo automáticamente de su función, incluido el nodo de administraciónde Ceph virtualizado. De este modo, los otros nodos del clúster de Ceph no notan que el nodode administración de Ceph ha fallado.
22 Esquema del clúster de alta disponibilidad para el nodo de administración de Ceph SES 5
La solución de alta disponibilidad mínima para el nodo de administración de Ceph requiere elsiguiente hardware:
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ónde Ceph.
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 de Ceph. Debe ser posible acceder al almacenamiento compartidodesde ambos servidores. Puede ser, por ejemplo, una exportación NFS, un recursocompartido Samba o el destino iSCSI.
Encontrará más información sobre los requisitos del clúster en https://www.suse.com/documen-
tation/sle-ha-12/install-quick/data/install-quick.html#sec_ha_inst_quick_req .
FIGURA 3.1: CLÚSTER DE ALTA DISPONIBILIDAD DE 2 NODOS PARA EL NODO DE ADMINISTRACIÓN DE CEPH
3.2 Vinculación del clúster de alta disponibilidad connodo de administración de CephEl 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 de Ceph. Para obtener másdetalles, consulte los enlaces indicados.
23 Vinculación del clúster de alta disponibilidad con nodo de administración de Ceph SES 5
1. Congure un clúster de alta disponibilidad básico de 2 nodos con almacenamientocompartido, como se describe en https://www.suse.com/documentation/sle-ha-12/install-
quick/data/install-quick.html .
2. En ambos nodos del clúster, instale todos los paquetes necesarios para ejecutar el hiper-visor KVM y el kit de herramientas libvirt , como se describe en https://www.su-
se.com/documentation/sles-12/book_virt/data/sec_vt_installation_kvm.html .
3. En el primer nodo del clúster, cree una máquina virtual KVM nueva mediantelibvirt , como se describe en https://www.suse.com/documentation/sles-12/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 administraciónde Ceph. Consulte https://www.suse.com/documentation/sle-ha-12/book_sleha/data/
cha_conf_hawk2.html para obtener información general sobre cómo crear recursosde alta disponibilidad. Encontrará información detallada sobre cómo crear un recursopara 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 administraciónde Ceph, incluidos los servicios adicionales que necesite allí. Siga los pasos relevantes dela Sección 4.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.
24 Vinculación del clúster de alta disponibilidad con nodo de administración de Ceph SES 5
II Distribución y actualización delclúster
4 Distribución con DeepSea/Salt 26
5 Actualización desde versiones anteriores 51
6 Copia de seguridad de la configuración del clúster 78
7 Personalización de la configuración por defecto 80
4 Distribución con DeepSea/Salt
Nota: ceph-deploy se ha eliminado en SUSE Enterprise Storage 5La herramienta de distribución de clúster ceph-deploy quedó obsoleta en SUSE Enter-prise Storage 4 y se ha eliminado por completo para sustituirse por DeepSea a partir deSUSE Enterprise Storage 5.
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 por servidorConseguirá 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,servidor de metadatos o Ceph Monitor al master de Salt.
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 4.3, “Distribución del clúster”.
26 SES 5
4.1 Lectura de las notas de la versión
En las notas de la versión puede encontrar información adicional sobre los cambios 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/ .
4.2 Introducción a DeepSea
El 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.
27 Lectura de las notas de la versión SES 5
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: vuelva a ejecutar la fase 0 siempre que serearranque el master de SaltSi durante la fase 0, el master de Salt se rearranca para cargar la nueva versión delkernel, debe volver a ejecutar la fase 0; de lo contrario, no se asignará un destinoa 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 4.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 1 “Administración de un clúster de Salt”, Sección 1.3 “eliminación y reinstalación
de nodos del clúster”.
Encontrará una introducción más detallada sobre DeepSea en https://github.com/suse/deepsea/
wiki .
28 Introducción a DeepSea SES 5
4.2.1 Organización y ubicaciones importantes
Salt tiene algunas ubicaciones estándar y varias convenciones de denominación que se 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. Para obtener más información, consulte la documentación de Salt (https://
docs.saltstack.com/en/latest/topics/tutorials/starting_states.html) .
/srv/module/runners
En este directorio se almacenan los guiones Python conocidos como runners. Los 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 .
4.2.2 Asignación de destino de los minions
Los comandos de DeepSea se ejecutan a través de la infraestructura de Salt. Cuando se 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.
29 Organización y ubicaciones importantes SES 5
4.2.2.1 Coincidencia del nombre del minion
Puede asignar destino para un minion o un grupo de minions haciendo coincidir sus nombres.El nombre de un minion suele ser el nombre de host corto del nodo donde se ejecuta el minion.Este método de asignación de destinos es general de Salt y no está relacionado con DeepSea. 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
4.2.2.2 Asignación de destino con un grain "deepsea"
En un entorno heterogéneo gestionado mediante Salt donde SUSE Enterprise Storage sedistribuya en un subconjunto de nodos junto con otras soluciones de clúster, es buena idea"marcar" los minions relevantes aplicándoles un grain "deepsea". De este modo, puede asignarfácilmente minions de DeepSea en entornos donde sea difícil obtener los nombres de los minionshaciéndolos coincidir.
30 Asignación de destino de los minions SES 5
Para aplicar el grain "deepsea" a un grupo de minions, ejecute:
root@master # salt target grains.append deepsea default
Para eliminar el grain "deepsea" de un grupo de minions, ejecute:
root@master # salt target grains.delval deepsea destructive=True
Después de aplicar el grain "deepsea" a los minions relevantes, puede asignarlos como destinode la siguiente forma:
root@master # salt -G 'deepsea:*' test.ping
El comando siguiente es equivalente:
root@master # salt -C 'G@deepsea:*' test.ping
4.2.2.3 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:*'
31 Asignación de destino de los minions SES 5
4.2.2.4 Información adicional
Puede utilizar métodos más avanzados para asignar destinos a los minions con la infraes-tructura de Salt. Consulte https://docs.saltstack.com/en/latest/topics/targeting/ para obteneruna descripción de todas las técnicas de asignación de destinos.
Asimismo, la página man "deepsea minions" ofrece más detalles sobre la asignación de destinosde DeepSea ( man 7 deepsea_minions ).
4.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 definir perfilesde OSDSi necesita omitir la denición de perles de OSD y distribuir primero los nodos demonitor, puede hacerlo deniendo la variable DEV_ENV . De esta forma puede distribuirmonitores sin la presencia del directorio profile/ , además de distribuir un clúster conal menos un nodo 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
El siguiente procedimiento describe los detalles para preparar el clúster.
1. Instale y registre SUSE Linux Enterprise Server 12 SP3 junto con la extensión SUSE Enter-prise Storage en cada nodo del clúster.
2. Verique que los productos adecuados están instalados y registrados mostrando los reposi-torios de software existentes. La lista será similar a esta:
root@minion > zypper lr -E# | Alias | Name | Enabled | GPG Check | Refresh---+---------+-----------------------------------+---------+-----------+--------
32 Distribución del clúster SES 5
4 | [...] | SUSE-Enterprise-Storage-5-Pool | Yes | (r ) Yes | No 6 | [...] | SUSE-Enterprise-Storage-5-Updates | Yes | (r ) Yes | Yes 9 | [...] | SLES12-SP3-Pool | Yes | (r ) Yes | No11 | [...] | SLES12-SP3-Updates | Yes | (r ) Yes | Yes
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-12/book_sle_admin/
data/sec_basicnet_yast.html . Para obtener más información sobre cómo configurarun servidor DNS, consulte https://www.suse.com/documentation/sles-12/book_sle_admin/
data/cha_dns.html .
4. Congure, habilite e inicie el servidor de sincronización horaria NTP:
root@master # systemctl enable ntpd.serviceroot@master # systemctl start ntpd.service
Encontrará más información sobre la configuración de NTP en https://www.su-
se.com/documentation/sles-12/book_sle_admin/data/sec_netz_xntp_yast.html .
5. Compruebe si se está ejecutando el servicio AppArmor e inhabilítelo en todos los nodosdel clúster. Inicie el módulo AppArmor de YaST, seleccione Settings (Configuración)y desactive la casilla de verificación Enable Apparmor (Habilitar Apparmor). Conrmehaciendo clic en Done (Terminado).Tenga en cuenta que SUSE Enterprise Storage no funcionará si AppArmor está habilitado.
6. Instale los paquetes salt-master y salt-minion en el nodo master de Salt:
root@master # zypper in salt-master salt-minion
Compruebe que el servicio salt-master esté habilitado y se haya iniciado, y si no loestuviera, habilítelo e inícielo:
root@master # systemctl enable salt-master.serviceroot@master # systemctl start salt-master.service
7. 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.
33 Distribución del clúster SES 5
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@master # systemctl stop SuSEfirewall2.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
8. Instale el paquete salt-minion en todos los nodos minion.
root@minion > zypper in salt-minion
Asegúrese de que el nombre completo de todos los demás nodos pueden resolver el nombrede cada nodo en la dirección IP pública.
9. 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
10. Compruebe que el servicio salt-minion está habilitado e iniciado en todos los nodos.Habilítelo e inícielo si fuera necesario:
root@minion > systemctl enable salt-minion.serviceroot@minion > systemctl start salt-minion.service
11. Verique la huella digital de cada minion de Salt y acepte todas las claves salt del masterde Salt si las huellas coinciden.
34 Distribución del clúster SES 5
Para ver la huella digital de cada minion:
root@minion > salt-call --local key.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 la huella digital de los minions coinciden, acéptelas:
root@master # salt-key --accept-all
12. Verique que las claves se han aceptado:
root@master # salt-key --list-all
13. Antes de distribuir SUSE Enterprise Storage, asegúrese de que todos los discos que se hanutilizado como OSD por los clústeres anteriores están vacíos y sin particiones. Para ello,deberá borrar manualmente la tabla de particiones de todos los discos. No olvide sustituirla "X" con la letra de disco correcta:
a. Detenga todos los procesos que utilicen el disco especíco.
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 infraes-tructura de LVM. Consulte https://www.suse.com/documentation/sles-12/stor_admin/
data/cha_lvm.html para obtener más información.
d. Si el disco es parte de MD RAID, desactive el dispositivo RAID.Consulte https://www.suse.com/documentation/sles-12/stor_admin/data/part_softwa-
re_raid.html para obtener más información.
35 Distribución del clúster SES 5
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:
for partition in /dev/sdX[0-9]*do dd if=/dev/zero of=$partition bs=4096 count=1 oflag=directdone
f. Limpie la tabla de particiones:
sgdisk -Z --clear -g /dev/sdX
g. Limpie las tablas de particiones de copia de seguridad:
size=`blockdev --getsz /dev/sdX`position=$((size/4096 - 33))dd if=/dev/zero of=/dev/sdX bs=4M count=33 seek=$position oflag=direct
14. Instale DeepSea en el nodo master de Salt:
root@master # zypper in deepsea
15. Compruebe que el archivo /srv/pillar/ceph/master_minion.sls del master de Saltapunta a su master de Salt. Si es posible acceder a su master de Salt a través de otrosnombres de host, utilice el adecuado para el clúster de almacenamiento. Si ha utilizadoel nombre de host por defecto para el master de Salt (salt) en el dominio ses, el archivotiene el aspecto siguiente:
master_minion: salt.ses
Ahora, distribuya y congure Ceph. A menos que se especifique lo contrario, todos los pasosson obligatorios.
36 Distribución del clúster SES 5
Nota: convenciones de comandos de saltExisten dos maneras posibles de ejecutar salt-run state.orch : una es constage.<número de fase> , la otra es con el nombre de la fase. Ambas notaciones tienenel mismo efecto y elegir un comando u otro es puramente preferencial.
PROCEDIMIENTO 4.1: EJECUCIÓN DE FASES DE DISTRIBUCIÓN
1. Incluya los minions de Salt que pertenezcan al clúster de Ceph que va a distribuir. Consultela Sección 4.2.2.1, “Coincidencia del nombre del minion” para obtener más información sobrecómo asignar destinos a los minions.
2. 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
Nota: ejecución o supervisión de fases mediante la interfaz delí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 4.4, “Interfaz de línea
de comandos de DeepSea”.
3. Opcional: cree subvolúmenes de Btrfs para /var/lib/ceph/ . Este paso solo se debeejecutar antes de que se hayan ejecutado las fases siguientes de DeepSea. Para migrar losdirectorios existentes, o para obtener más información, consulte el Libro “Guía de adminis-
tración”, Capítulo 18 “Consejos y sugerencias”, Sección 18.5 “Subvolumen Btrfs para /var/lib/ceph”.
root@master # salt-run state.orch ceph.migrate.subvolume
4. 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.
37 Distribución del clúster SES 5
root@master # salt-run state.orch ceph.stage.1
O bien
root@master # salt-run state.orch ceph.stage.discovery
5. Después de que el comando anterior nalice correctamente, cree un archivo policy.cfgen /srv/pillar/ceph/proposals . Para obtener información detallada, consulte laSección 4.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: .
6. 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
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
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.
38 Distribución del clúster SES 5
7. Ahora se ejecuta la fase de distribución. En esta fase, se valida Pillar y los monitores ylos daemons de OSD se inician en los nodos de almacenamiento. Ejecute lo siguiente parainiciar la fase:
root@master # salt-run state.orch ceph.stage.3
O bien
root@master # salt-run state.orch ceph.stage.deploy
El comando puede tardar varios minutos. Si se produce un error, debe solucionar elproblema y volver a ejecutar las fases anteriores. Cuando el comando se ejecute correcta-mente, ejecute lo siguiente para comprobar el estado:
root@master # ceph -s
8. El último paso de la distribución del clúster de Ceph es la fase services. Aquí se crea unainstancia de cualquiera de los servicios admitidos actualmente: iSCSI Gateway, CephFS,Object Gateway, openATTIC y NFS Ganesha. En esta fase, se crean los repositoriosnecesarios, los anillos de claves de autorización y los servicios de inicio. Para iniciar lafase, ejecute lo siguiente:
root@master # salt-run state.orch ceph.stage.4
O bien
root@master # salt-run state.orch ceph.stage.services
Según la configuración, puede que la ejecución del comando tarde varios minutos.
4.4 Interfaz de línea de comandos de DeepSea
DeepSea también proporciona una interfaz de línea de comandos que permite al usuario super-visar o ejecutar fases mientras observa el progreso de la ejecución en tiempo real.
39 Interfaz de línea de comandos de DeepSea SES 5
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 .
4.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.
Debe iniciar el monitor antes de ejecutar cualquier comando salt-run state.orch para queel monitor pueda detectar el inicio de la ejecución de la fase.
Si inicia el monitor después de emitir el comando salt-run state.orch , no se mostrará ningú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
40 Interfaz de línea de comandos de DeepSea: modo de monitor SES 5
4.4.2 Interfaz de línea de comandos de DeepSea: modo autónomo
En el modo autónomo, la interfaz de línea de comandos de DeepSea se puede usar para 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).
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
41 Interfaz de línea de comandos de DeepSea: modo autónomo SES 5
En la ilustración siguiente se muestra un ejemplo de la interfaz de línea de comandos de DeepSeacuando se ejecuta Stage 2:
FIGURA 4.1: PANTALLA DE PROGRESO DE LA EJECUCIÓN DE FASE EN LA INTERFAZ DE LÍNEA DE COMANDOS DEDEEPSEA
4.4.2.1 Alias de stage run de la interfaz de línea de comandos de DeepSea
Para usuarios avanzados de Salt, también se admite un alias para ejecutar una fase de 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
42 Interfaz de línea de comandos de DeepSea: modo autónomo SES 5
4.5 Configuración y personalización
4.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é nodo actúa como unOSD o cuál actúa como monitor. Edite policy.cfg para reejar la configuración de clúster quedesee. El orden de las secciones es arbitrario, pero el contenido de las líneas incluidas sobres-cribe 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/ .
4.5.1.1 Asignación de clúster
En la sección cluster, se seleccionan los minions para el clúster. Puede seleccionar todos 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
O un grupo de minions (se pueden usar comodines):
cluster-ceph/cluster/mon*.sls
Para añadir minions a una lista negra, defínalos como unassigned :
cluster-unassigned/cluster/client*.sls
43 Configuración y personalización SES 5
4.5.1.2 Asignación de funciones
En esta sección se proporciona información sobre cómo asignar "funciones" a los nodos delclúster. En este contexto, una función es el servicio que debe ejecutar en el nodo, como CephMonitor, Object Gateway, iSCSI Gateway u openATTIC. Ninguna función se asigna automática-mente y solo las funciones que se añadan a policy.cfg se distribuirán.
La asignación sigue este patrón:
role-ROLE_NAME/PATH/FILES_TO_INCLUDE
Donde los elementos tienen el significado y los valores siguientes:
ROLE_NAME es uno de los siguientes elementos: "master", "admin", "mon", "mgr", "mds","igw", "rgw", "ganesha" o "openattic".
PATH es una vía relativa a los archivos .sls o .yml. En el caso de los archivos .sls, 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.
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 supervisión al clúster de Ceph. Esta funciónrequiere las direcciones de los minions asignados. A partir de SUSE Enterprise Storage 5, lasdirecciones públicas se calculan de forma dinámica y ya no son necesarias en Pillar de Salt.
role-mon/cluster/mon*.sls
44 El archivo policy.cfg SES 5
El ejemplo asigna la función de supervisión a un grupo de minions.
mgr: el daemon de Ceph Manager que recopila toda la información de estado de todo 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
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/stack/default/ceph/minions/xyz.domain.ymlrole-igw/cluster/*.sls
rgw: el minion actuará como pasarela Object Gateway:
role-rgw/cluster/rgw*.sls
openattic: el minion actuará como servidor de openATTIC:
role-openattic/cluster/openattic*.sls
Para obtener más información, consulte: Libro “Guía de administración”, Capítulo 15
“openATTIC”.
ganesha: el minion actuará como servidor de NFS Ganesha. La función "ganesha" requiereque la función "rgw" o "mds" esté en el clúster, o de lo contrario fallará la validación enla fase 3.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 14 “NFS
Ganesha: exportación de datos de Ceph a través de NFS”, Sección 14.3 “Funciones personalizadas
de NFS Ganesha”.
45 El archivo policy.cfg SES 5
Nota: varias funciones de nodos del clústerPuede asignar varias funciones a un único nodo. Por ejemplo, puede asignar las funcionesde servidor de metadatos a los nodos de monitor:
role-mds/cluster/mon[1,2]*.sls
4.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
4.5.1.4 Asignación de perfil
En Ceph, una función de almacenamiento única no sería suciente para describir las numerosasconfiguraciones de disco disponibles con el mismo hardware. La fase 1 de DeepSea generará unapropuesta de perl de almacenamiento por defecto. Esta propuesta será por defecto un perlbluestore e intentará proponer la configuración de mayor rendimiento para la configuraciónde hardware determinada. Por ejemplo, se preferirán diarios externos a un único disco quecontenga objetos y metadatos. El almacenamiento de estado sólido se priorizará sobre los discosrotatorios. Los perles se asignan en policy.cfg , igual que las funciones.
La propuesta por defecto se encuentra en el árbol de directorios por defecto del perl. Paraincluirlo, añada estas dos líneas a policy.cfg .
profile-default/cluster/*.slsprofile-default/stack/default/ceph/minions/*.yml
También puede crear un perl de almacenamiento personalizado a su gusto utilizando el runnerde propuestas. Este runner ofrece tres métodos: help, peek y populate.
salt-run proposal.help imprime el texto de ayuda del runner sobre los distintos argumentosque acepta.
46 El archivo policy.cfg SES 5
salt-run proposal.peek muestra la propuesta generada según los argumentos pasados.
salt-run proposal.populate escribe la propuesta en el subdirectorio /srv/pillar/ceph/proposals . Pasa name=myprofile para asignar un nombre al perl de almacenamiento. Estodará como resultado un subdirectorio prole-myprole.
Para todos los demás argumentos, consulte el resultado de salt-run proposal.help .
4.5.1.5 Distribución de OSD cifrados
A partir de SUSE Enterprise Storage 5, los OSD se distribuyen por defecto mediante BlueStore,en lugar de mediante FileStore. Aunque BlueStore admite el cifrado, los Ceph OSD se distribuyensin cifrar por defecto. En él se presupone que tanto los datos como los discos WAL/DB que sevan a usar para la distribución de los OSD están limpios y no tienen particiones. Si el disco seha utilizado anteriormente, bórrelo con el procedimiento descrito en el Paso 13.
Para utilizar OSD cifrados para la distribución nueva, use el runner proposal.populate conel argumento encryption=dmcrypt :
root@master # salt-run proposal.populate encryption=dmcrypt
4.5.1.6 Filtrado de elementos
A veces no resulta práctico incluir todos los archivos de un directorio concreto con comodines*.sls. El analizador del archivo policy.cfg comprende los siguientes ltros:
Aviso: técnicas 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]
47 El archivo policy.cfg SES 5
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$
4.5.1.7 Archivo policy.cfg de ejemplo
A continuación se muestra un ejemplo de un archivo policy.cfg básico:
## Cluster Assignmentcluster-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
# MDSrole-mds/cluster/ses-example-4.sls 6
# IGWrole-igw/stack/default/ceph/minions/ses-example-4.yml 7
role-igw/cluster/ses-example-4.sls 8
# RGWrole-rgw/cluster/ses-example-4.sls 9
# openATTICrole-openattic/cluster/openattic*.sls 10
# COMMONconfig/stack/default/global.yml 11
config/stack/default/ceph/cluster.yml 12
## Profilesprofile-default/cluster/*.sls 13
profile-default/stack/default/ceph/minions/*.yml 14
48 El archivo policy.cfg SES 5
1 Indica que todos los minions están incluidos en el clúster de Ceph. Si tiene minions que 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.
5 Todos los minions que coincidan con "ses-example-[123]" (todos los nodos MON delejemplo) se configurarán como nodos MGR.
6 El minion "ses-example-4" tendrá la función de servidor de metadatos.
7 Asegúrese de que DeepSea conozca la dirección IP del nodo de IGW.
8 El minion "ses-example-4" tendrá la función de IGW.
9 El minion "ses-example-4" tendrá la función de RGW.
10 Indica que se va a distribuir la interfaz de usuario openATTIC para administrar el clústerde Ceph. Consulte el Libro “Guía de administración”, Capítulo 15 “openATTIC” para obtener másinformación.
11 Signica que se aceptan los valores por defecto para los parámetros de configuracióncomunes, como fsid y public_network .
12 Signica que se aceptan los valores por defecto para los parámetros de configuracióncomunes, como fsid y public_network .
13 Se indica a DeepSea que use el perl de hardware por defecto para cada minion. Elegirel perl de hardware por defecto signica que queremos que todos los discos adicionales(que no sean el disco raíz) sean OSD.
14 Se indica a DeepSea que use el perl de hardware por defecto para cada minion. Elegirel perl de hardware por defecto signica que queremos que todos los discos adicionales(que no sean el disco raíz) sean OSD.
49 El archivo policy.cfg SES 5
4.5.2 Archivo ceph.conf personalizado
Si es necesario establecer valores personalizados en el archivo de configuración ceph.conf ,consulte el Libro “Guía de administración”, Capítulo 1 “Administración de un clúster de Salt”, Sección 1.11
“Archivo ceph.conf personalizado” para obtener más detalles.
50 Archivo ceph.conf personalizado SES 5
5 Actualización desde versiones anteriores
Este capítulo presenta los pasos necesarios para actualizar SUSE Enterprise Storage desde lasversiones anteriores a la actual.
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 Procedimiento de actualización generalAntes de iniciar el procedimiento de actualización, tenga en cuenta los siguientes elementos:
Orden de la actualización
Antes de actualizar el clúster de Ceph, debe tener debidamente registrados en el SCC o enSMT tanto SUSE Linux Enterprise Server como SUSE Enterprise Storage. Puede actualizarlos daemons del clúster mientras este esté en línea y en servicio. Algunos tipos de daemonsdependen de otros. Por ejemplo, los daemons de Ceph Object Gateway dependen de losdaemons de los Ceph Monitor y los Ceph OSD. Se recomienda actualizar en este orden:
1. Monitores Ceph Monitor
2. Gestores Ceph Manager
3. Daemons Ceph OSD
51 Lectura de las notas de la versión SES 5
4. Servidores de metadatos
5. Pasarelas Object Gateway
6. Pasarelas iSCSI Gateway
7. NFS Ganesha
Supresión de las instantáneas innecesarias del sistema operativo
Elimine las instantáneas del sistema de archivos que no se necesiten de las particiones delsistema operativo de nodos. De esta forma se garantiza que haya suciente espacio libreen disco durante la actualización.
Comprobación del estado del clúster
Se recomienda comprobar el estado del clúster antes de iniciar el procedimiento de actua-lización.
Actualización de uno en uno
Se recomienda actualizar todos los daemons de un tipo especíco, por ejemplo todos losdaemons de monitor o todos los daemons de OSD, uno a uno para asegurarse de que todostienen la misma versión. También se recomienda actualizar todos los daemons del clústerantes de intentar utilizar las nuevas funciones de una versión.Después de actualizar todos los daemons de un tipo concreto, compruebe su estado.Asegúrese de que cada monitor se ha vuelto a unir al quórum después de que se actualicentodos los monitores:
root # ceph mon stat
Asegúrese de que cada daemon Ceph OSD se ha vuelto a unir al clúster después de quese actualicen todos los OSD:
root # ceph osd stat
Definición del indicador require-osd-release luminous
Cuando se actualice el último OSD a SUSE Enterprise Storage 5, los nodos de monitor detec-tarán que todos los OSD tienen la versión "luminous" de Ceph y podrían mostrar la adver-tencia de que el indicador osdmap require-osd-release luminous no está denido.En tal caso, deberá denir este indicador manualmente para conrmar que, ahora que elclúster se ha actualizado a la versión "luminous", no es posible volver a la versión anteriorde Ceph: "jewel". Dena el indicador ejecutando el comando siguiente:
root@minion > sudo ceph osd require-osd-release luminous
52 Procedimiento de actualización general SES 5
Después de que se complete el comando, la advertencia desaparece.En las instalaciones nuevas de SUSE Enterprise Storage 5, este indicador se dene automá-ticamente cuando los Ceph Monitor crean el osdmap inicial, por lo que no se necesitaacción alguna por parte del usuario nal.
5.3 Cifrado de OSD durante la actualización
A partir de SUSE Enterprise Storage 5, los OSD se distribuyen por defecto mediante BlueStore,en lugar de mediante FileStore. Aunque BlueStore admite el cifrado, los Ceph OSD se distribuyensin cifrar por defecto. El procedimiento siguiente describe los pasos necesarios para cifrar losOSD durante el proceso de actualización. En él se presupone que tanto los datos como los discosWAL/DB que se van a usar para la distribución de los OSD están limpios y no tienen particiones.Si el disco se ha utilizado anteriormente, bórrelo con el procedimiento descrito en el Paso 13.
Importante: un OSD cada vezDebe distribuir los OSD cifrados de uno en uno, no de forma simultánea. El motivo es quelos datos del OSD se borran y que el clúster pasa por varias repeticiones de reequilibrio.
1. Determine los valores de bluestore block db size y bluestore block wal sizepara la distribución y añádalos en el archivo /srv/salt/ceph/configuration/files/ceph.conf.d/global.conf en el master de Salt. Es preciso especificar los valores enbytes.
[global]bluestore block db size = 48318382080bluestore block wal size = 2147483648
Para obtener más información sobre cómo personalizar el archivo ceph.conf , consulteel Libro “Guía de administración”, Capítulo 1 “Administración de un clúster de Salt”, Sección 1.11
“Archivo ceph.conf personalizado”.
2. Ejecute la fase 3 de DeepSea para distribuir los cambios:
root@master # salt-run state.orch ceph.stage.3
53 Cifrado de OSD durante la actualización SES 5
3. Verique que el archivo ceph.conf está actualizado en los nodos de OSD pertinentes:
root@minion > cat /etc/ceph/ceph.conf
4. Edite los archivos *.yml del directorio /srv/pillar/ceph/proposals/profile-
default/stack/default/ceph/minions que sean relevantes para los OSD que va acifrar. Vuelva a comprobar que la vía es la denida en el archivo /srv/pillar/ceph/proposals/policy.cfg y asegúrese de que modica los archivos *.yml correctos.
Importante: identificadores de disco largosA la hora de identificar los discos de OSD en los archivos /srv/pillar/
ceph/proposals/profile-default/stack/default/ceph/minions/*.yml , useidentificadores de disco largos.
A continuación se muestra un ejemplo de una configuración de OSD. Tenga en cuenta quedebido a que es necesario el cifrado, las opciones db_size y wal_size se han eliminado:
ceph: storage: osds: /dev/disk/by-id/scsi-SDELL_PERC_H730_Mini_007027b1065faa972100d34d7aa06d86: format: bluestore encryption: dmcrypt db: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN wal: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN /dev/disk/by-id/scsi-SDELL_PERC_H730_Mini_00d146b1065faa972100d34d7aa06d86: format: bluestore encryption: dmcrypt db: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN wal: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN
5. Distribuya los nuevos OSD de almacenamiento de bloques con cifrado ejecutando lasfases 2 y 3 de DeepSea:
root@master # salt-run state.orch ceph.stage.2root@master # salt-run state.orch ceph.stage.3
54 Cifrado de OSD durante la actualización SES 5
Puede observar el progreso con los comandos ceph -s o ceph osd tree . Es fundamentalque se permita un reequilibrio del clúster antes de repetir el proceso en el nodo de OSDsiguiente.
5.4 Actualización desde SUSE Enterprise Storage 4(distribución de DeepSea) a la versión 5
Importante: requisitos de softwareDebe tener el siguiente software instalado y actualizado con las últimas versiones de lospaquetes en todos los nodos de Ceph que desee actualizar antes de iniciar el procedimientode actualización:
SUSE Linux Enterprise Server 12 SP2
SUSE Enterprise Storage 4
Además, antes de iniciar la actualización, debe actualizar el nodo master de Salt aSUSE Linux Enterprise Server 12 SP3 y SUSE Enterprise Storage 5 ejecutando zyppermigration (o su método de actualización preferido).
Aviso: puntos que se deben tener en cuenta antes de laactualización
Compruebe si se está ejecutando el servicio AppArmor e inhabilítelo en todos losnodos del clúster. Inicie el módulo AppArmor de YaST, seleccione Settings (Configu-ración) y desactive la casilla de verificación Enable Apparmor (Habilitar Apparmor).Conrme haciendo clic en Done (Terminado).Tenga en cuenta que SUSE Enterprise Storage no funcionará si AppArmor estáhabilitado.
Aunque el clúster sea completamente funcional durante la actualización, DeepSeaestablece el indicador "noout", que impide a Ceph reequilibrar los datos durante eltiempo de inactividad y, por lo tanto, impide las transferencias de datos innecesarias.
55
Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la
versión 5 SES 5
Para optimizar el proceso de actualización, DeepSea actualiza los nodos en esteorden basado en la función que tiene asignada según recomiende Ceph en fasesanteriores: Monitor, Manager, OSD, servidores de metadatos, Object Gateway, ISCSIGateway y NFS Ganesha.Tenga en cuenta que DeepSea no puede impedir que el orden prescrito se infrinjasi un nodo ejecuta varios servicios.
Aunque el clúster de Ceph esté en funcionamiento durante la actualización, losnodos podrían rearrancarse a n de aplicar, por ejemplo, nuevas versiones delkernel. Para reducir las operaciones de E/S en espera, se recomienda rechazar laspeticiones entrantes durante el proceso de actualización.
La actualización del clúster puede tardar mucho tiempo, aproximadamente el quese tarda en actualizar un equipo multiplicado por el número de nodos del clúster.
A partir de la versión Ceph Luminous, la opción de configuración osd crush
location ya no se admite. Actualice los archivos de configuración de DeepSea paraque usen crush location antes de proceder con la actualización.
Para actualizar el clúster de SUSE Enterprise Storage 4 a la versión 5, siga estos pasos:
1. Dena el nuevo orden de clasificación de objetos interno. Para ello, ejecute:
root # ceph osd set sortbitwise
SugerenciaPara vericar que el comando se ha ejecutado correctamente, se recomiendaejecutar:
root # ceph osd dump --format json-pretty | grep sortbitwise "flags": "sortbitwise,recovery_deletes,purged_snapdirs",
2. Con el comando rpm -q deepsea , verique que la versión del paquete de DeepSea en elnodo master de Salt empieza con al menos 0.7 . Por ejemplo:
root # rpm -q deepseadeepsea-0.7.27+git.0.274c55d-5.1
56
Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la
versión 5 SES 5
Si el número de versión del paquete de DeepSea empieza con 0.6, vuelva a comprobar siel nodo master de Salt se ha migrado correctamente a SUSE Linux Enterprise Server 12SP3 y SUSE Enterprise Storage 5 (consulte Importante: requisitos de software al principio deesta sección). Este es un requisito previo que debe completarse antes de iniciar el proce-dimiento de actualización.
3. a. Si ha registrado los sistemas con SUSEConnect y usa el SCC/SMT, no necesita llevara cabo ninguna otra acción. Continúe con el Paso 4.
b. Si no usa el SCC/SMT, sino una imagen ISO de medios u otro origen de paquete,añada los siguientes repositorios manualmente: SLE12-SP3 Base, SLE12-SP3 Update,SES5 Base y SES5 Update. Puede hacerlo con el comando zypper . Antes, eliminetodos los repositorios de software existentes y, a continuación, añada los nuevosrepositorios necesarios. Por último, actualice los orígenes de los repositorios:
root # zypper sd {0..99}root # zypper ar \ http://172.17.2.210:82/repo/SUSE/Products/Storage/5/x86_64/product/ SES5-POOLroot # zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATESroot # zypper ar \ http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOLroot # zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATESroot # zypper ref
Cambie los datos de Pillar para utilizar una estrategia diferente. Edite:
/srv/pillar/ceph/stack/name_of_cluster/cluster.yml
Y añada la línea siguiente:
upgrade_init: zypper-dup
57
Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la
versión 5 SES 5
SugerenciaLa estrategia zypper-dup requiere que se añadan manualmente los reposi-torios de software más recientes, mientras que la opción por defecto zypper-migration se basa en los repositorios proporcionados por el SCC/SMT.
4. Actualice Pillar:
root@master # salt target saltutil.sync_all
Consulte la Sección 4.2.2, “Asignación de destino de los minions” para obtener informaciónsobre cómo asignar destinos a los minions de Salt.
5. Verique si se ha escrito correctamente en Pillar:
root@master # salt target pillar.get upgrade_init
El resultado del comando debe reejar la entrada que ha añadido.
6. Actualice los minions de Salt:
root@master # salt target state.apply ceph.updates.salt
7. Verique que todos los minions de Salt se han actualizado:
root@master # salt target test.version
8. Incluya los minions de Salt del clúster. Consulte la Sección 4.2.2, “Asignación de destino de
los minions” de Procedimiento 4.1, “Ejecución de fases de distribución” para obtener más infor-mación.
9. Inicie la actualización de SUSE Linux Enterprise Server y Ceph:
root@master # salt-run state.orch ceph.maintenance.upgrade
Sugerencia: nueva ejecución durante el rearranqueSi en el proceso se produce un reinicio del master de Salt, vuelva a ejecutar elcomando para iniciar de nuevo el proceso de actualización de los minions de Salt.
58
Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la
versión 5 SES 5
10. Compruebe que AppArmor está inhabilitado y detenga todos los nodos después de la actua-lización:
root # systemctl disable apparmor.servicesystemctl stop apparmor.service
11. Después de la actualización, los gestores Ceph Manager aún no están instalados. Para queel estado del clúster sea el correcto, haga lo siguiente:
a. Ejecute la fase 0 para habilitar la API REST de Salt:
root@master # salt-run state.orch ceph.stage.0
b. Ejecute la fase 1 para crear el subdirectorio role-mgr/ :
root@master # salt-run state.orch ceph.stage.1
c. Edite el archivo policy.cfg como se describe en la Sección 4.5.1, “El archivo policy.cfg”
y añada una función de Ceph Manager a los nodos a los que va a distribuir losmonitores Ceph Monitor. Asimismo, puede añadir la función openATTIC a uno delos nodos del clúster. Consulte el Libro “Guía de administración”, Capítulo 15 “openATTIC”
para obtener más información.
d. Ejecute la fase 2 para actualizar Pillar:
root@master # salt-run state.orch ceph.stage.2
e. DeepSea utiliza ahora un enfoque diferente para generar el archivo de configuraciónceph.conf , consulte el Libro “Guía de administración”, Capítulo 1 “Administración de un
clúster de Salt”, Sección 1.11 “Archivo ceph.conf personalizado” para obtener más infor-mación.
f. Ejecute la fase 3 para distribuir los gestores Ceph Manager:
root@master # salt-run state.orch ceph.stage.3
g. Ejecute la fase 4 para configurar openATTIC correctamente:
root@master # salt-run state.orch ceph.stage.4
59
Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la
versión 5 SES 5
Nota: error de coincidencia de capacidades de clave de CephSi ceph.stage.3 falla con el "Error EINVAL: entity client.bootstrap-osd exists butcaps do not match" (Error EINVAL: la entidad client.bootstrap-osd existe, pero lascapacidades de clave no coinciden), signica que las capacidades de clave (caps) dela clave client.bootstrap.osd del clúster existente no coinciden con las caps queDeepSea está intentando establecer. Encima del mensaje de error, en texto rojo, veráun volcado del comando ceph auth que ha fallado. Consulte en este comando elID de clave y el archivo que se están utilizando. En el caso de client.bootstrap-osd , el comando será:
root # ceph auth add client.bootstrap-osd \ -i /srv/salt/ceph/osd/cache/bootstrap.keyring
Para solucionar los errores de coincidencia de capacidades de clave, compruebe elcontenido del archivo de anillo de claves que DeepSea está intentando distribuir;por ejemplo:
cephadm > cat /srv/salt/ceph/osd/cache/bootstrap.keyring[client.bootstrap-osd] key = AQD6BpVZgqVwHBAAQerW3atANeQhia8m5xaigw== caps mgr = "allow r" caps mon = "allow profile bootstrap-osd"
Compárelo con el resultado de ceph auth get client.bootstrap-osd :
root # ceph auth get client.bootstrap-osdexported keyring for client.bootstrap-osd[client.bootstrap-osd] key = AQD6BpVZgqVwHBAAQerW3atANeQhia8m5xaigw== caps mon = "allow profile bootstrap-osd"
Fíjese en que falta la última clave caps mgr = "allow r" . Para solucionar elproblema, ejecute:
root # ceph auth caps client.bootstrap-osd mgr \ "allow r" mon "allow profile bootstrap-osd"
Si se ejecuta ceph.stage.3 ahora, el problema se debe haber solucionado.
60
Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la
versión 5 SES 5
El mismo problema puede producirse con los anillos de claves del servidor demetadatos y de Object Gateway cuando se ejecuta ceph.stage.4 . Se aplica elmismo procedimiento anterior: compruebe qué comando ha fallado, el archivo deanillo de claves que se está distribuyendo y las capacidades de la clave existente. Acontinuación, ejecute ceph auth caps para actualizar las caps de claves existentesa n de que coincidan con las que DeepSea está distribuyendo.
Importante: fallo de actualizaciónSi el clúster está en estado "HEALTH_ERR" durante más de 300 segundos o uno de losservicios para cada función asignada está inactivo durante más de 900 segundos, la actua-lización falla. En tal caso, busque el problema, resuélvalo y vuelva a ejecutar el proce-dimiento de actualización. Tenga en cuenta que en entornos virtualizados, los tiemposlímite son más cortos.
Importante: rearranque de los OSDDespués de actualizar a SUSE Enterprise Storage 5, los OSD de FileStore necesitan aproxi-madamente cinco minutos más para iniciarse, ya que el OSD realizará una conversiónuna sola vez de sus archivos en disco.
Sugerencia: comprobación de la versión de los componentes ynodos del clústerSi necesita averiguar las versiones de los componentes y nodos individuales del clúster(por ejemplo, para comprobar si todos los nodos se encuentran realmente en el mismonivel de parches después de la actualización), puede ejecutar:
root@master # salt-run status.report
El comando recorre los minions de Salt conectados y busca los números de versión deCeph, Salt y SUSE Linux Enterprise Server. A continuación, ofrece un informe donde semuestra la versión que tienen la mayoría de los nodos y también los nodos cuya versiónes diferente a los de esa mayoría.
61
Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la
versión 5 SES 5
5.4.1 Migración de OSD a BlueStore
OSD BlueStore es un nuevo procesador nal para los daemons de OSD. Es la opción por 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.
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 unmedio más rápido o en uno distinto.
En SES5, se admite tanto FileStore como BlueStore y es posible que ambos sistemas coexistanen un mismo clúster. Durante el procedimiento de actualización de SUSE Enterprise Storage,los OSD de FileStore no se convierten automáticamente a BlueStore. Tenga en cuenta que lasfunciones específicas de BlueStore no estarán disponibles en los OSD que no se hayan migradoa 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
1. Migre los perles de hardware:
root@master # salt-run state.orch ceph.migrate.policy
62 Migración de OSD a BlueStore SES 5
Este servicio migra los perles de hardware que usa actualmente el archivo policy.cfg .Procesa policy.cfg , encuentra cualquier perl de hardware que use la estructura dedatos original y lo convierte a la nueva estructura de datos. El resultado es un perlde hardware nuevo denominado "migrated- nombre_original ". También se actualizapolicy.cfg .Si la configuración original tenía diarios independientes, la configuración de BlueStoreutilizará el mismo dispositivo para los dispositivos "wal" y "db" de ese OSD.
2. DeepSea migra los OSD deniendo su peso en 0, lo que "vacía" los datos hasta que el OSDestá vacío. Los OSD se pueden migrar uno por uno o todos a la vez. En cualquier caso,cuando el OSD está vacío, la organización lo elimina y lo vuelve a crear con la nuevaconfiguración.
Sugerencia: método recomendadoUse ceph.migrate.nodes si tiene un gran número de nodos de almacenamientofísicos o casi ningún dato. Si un nodo representa menos de 10 % de su capacidad,ceph.migrate.nodes puede ser ligeramente más rápido que mover todos los datosde esos OSD en paralelo.
Si no tiene claro qué método debe utilizar, o si el sitio tiene menos nodos de almace-namiento (por ejemplo, cada nodo tiene más del 10 % de los datos del clúster),seleccione ceph.migrate.osds .
a. Para migrar los OSD a la vez, ejecute:
root@master # salt-run state.orch ceph.migrate.osds
b. Para migrar todos los OSD de cada nodo en paralelo, ejecute:
root@master # salt-run state.orch ceph.migrate.nodes
SugerenciaComo la organización no aporta información sobre el progreso de la migración,utilice
root # ceph osd tree
63 Migración de OSD a BlueStore SES 5
para ver qué OSD tiene periódicamente un peso cero.
Después de la migración a BlueStore, el recuento de objetos seguirá siendo el mismo y el usode disco será prácticamente igual.
5.5 Actualización desde SUSE Enterprise Storage 4(distribución de ceph-deploy) a la versión 5
Importante: requisitos de softwareDebe tener el siguiente software instalado y actualizado con las últimas versiones de lospaquetes en todos los nodos de Ceph que desee actualizar antes de iniciar el procedimientode actualización:
SUSE Linux Enterprise Server 12 SP2
SUSE Enterprise Storage 4
Seleccione al master de Salt para el clúster. Si el clúster tiene Calamari distribuido, elnodo de Calamari ya es el master de Salt. Como alternativa, el nodo de administracióndesde el que se ha ejecutado el comando ceph-deploy se convertirá en el master de Salt.
Antes de iniciar el proceso siguiente, debe actualizar el nodo master de Salt a SUSE LinuxEnterprise Server 12 SP3 y SUSE Enterprise Storage 5 ejecutando zypper migration (osu método de actualización preferido).
Para actualizar el clúster de SUSE Enterprise Storage 4 que se ha distribuido con ceph-deploya la versión 5, siga estos pasos:
PROCEDIMIENTO 5.1: PASOS QUE SE DEBEN APLICAR A TODOS LOS NODOS DEL CLÚSTER (INCLUIDO EL NODODE CALAMARI)
1. Instale el paquete salt desde SLE-12-SP2/SES4:
root # zypper install salt
64
Actualización desde SUSE Enterprise Storage 4 (distribución de ceph-deploy) a la
versión 5 SES 5
2. Instale el paquete salt-minion desde SLE-12-SP2/SES4 y habilite e inicie el serviciorelacionado:
root # zypper install salt-minionroot # systemctl enable salt-minionroot # systemctl start salt-minion
3. Asegúrese de que el nombre de host "salt" se resuelve en la dirección IP del nodo masterde Salt. Si el nombre de host salt no puede acceder al master de Salt, edite el archivo /etc/salt/minion o cree un archivo /etc/salt/minion.d/master.conf nuevo con elcontenido siguiente:
master: host_name_of_salt_master
SugerenciaLos minions de Salt existentes tienen la opción master: ya denida en /etc/salt/minion.d/calamari.conf . No importa el nombre de archivo de configuración quese use, pero el directorio /etc/salt/minion.d/ sí es importante.
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
4. a. Si ha registrado los sistemas con SUSEConnect y usa el SCC/SMT, no necesita llevara cabo ninguna otra acción.
b. Si no usa el SCC/SMT, sino una imagen ISO de medios u otro origen de paquete,añada los siguientes repositorios manualmente: SLE12-SP3 Base, SLE12-SP3 Update,SES5 Base y SES5 Update. Puede hacerlo con el comando zypper . Antes, eliminetodos los repositorios de software existentes y, a continuación, añada los nuevosrepositorios necesarios. Por último, actualice los orígenes de los repositorios:
root # zypper sd {0..99}root # zypper ar \ http://172.17.2.210:82/repo/SUSE/Products/Storage/5/x86_64/product/ SES5-POOLroot # zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATESroot # zypper ar \
65
Actualización desde SUSE Enterprise Storage 4 (distribución de ceph-deploy) a la
versión 5 SES 5
http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOLroot # zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATESroot # zypper ref
PROCEDIMIENTO 5.2: PASOS QUE SE DEBEN APLICAR EN EL NODO MASTER DE SALT
1. Dena el nuevo orden de clasificación de objetos interno. Para ello, ejecute:
root@master # ceph osd set sortbitwise
SugerenciaPara vericar que el comando se ha ejecutado correctamente, se recomiendaejecutar:
root@master # ceph osd dump --format json-pretty | grep sortbitwise "flags": "sortbitwise,recovery_deletes,purged_snapdirs",
2. Actualice el nodo master de Salt a SUSE Linux Enterprise Server 12 SP3 y SUSE EnterpriseStorage 5. Para sistemas registrados en el SCC, use zypper migration . Si proporcionamanualmente los repositorios de software necesarios, use zypper dup . Después de laactualización, asegúrese de que solo los repositorios de SUSE Linux Enterprise Server 12SP3 y SUSE Enterprise Storage 5 estén activos (y actualizados) en el nodo master de Saltantes de continuar.
3. Si no están ya presentes, instale el paquete salt-master y habilite e inicie el serviciorelacionado:
root@master # zypper install salt-masterroot@master # systemctl enable salt-masterroot@master # systemctl start salt-master
4. Verique que todos los minions de Salt están presentes mostrando sus claves:
root@master # salt-key -L
66
Actualización desde SUSE Enterprise Storage 4 (distribución de ceph-deploy) a la
versión 5 SES 5
5. Añada todas las claves de los minions de Salt al master de Salt, incluido el master de losminions:
root@master # salt-key -A -y
6. Asegúrese de que se han aceptado todas las claves de los minions de Salt:
root@master # salt-key -L
7. Asegúrese de que el software del nodo master de Salt está actualizado:
root@master # zypper migration
8. Instale el paquete deepsea :
root@master # zypper install deepsea
9. Incluya los minions de Salt del clúster. Consulte la Sección 4.2.2, “Asignación de destino de
los minions” de Procedimiento 4.1, “Ejecución de fases de distribución” para obtener más infor-mación.
10. Importe el clúster instalado ceph-deploy existente:
root@master # salt-run populate.engulf_existing_cluster
El comando hará lo siguiente:
Distribuir todos los módulos necesarios de Salt y DeepSea a todos los minions de Salt.
Inspeccionar el clúster de Ceph en ejecución y completar /srv/pillar/ceph/proposals con un diseño del clúster.Se creará /srv/pillar/ceph/proposals/policy.cfg con funciones que coincidancon todos los servicios de Ceph en ejecución detectados. Consulte este archivopara vericar que todos los nodos de Monitor, OSD, Object Gateway y servidorde metadatos existentes tienen las funciones adecuadas. Los nodos de OSD seimportarán en el subdirectorio profile-import/ , por lo que puede examinar losarchivos de /srv/pillar/ceph/proposals/profile-import/cluster/ y /srv/pillar/ceph/proposals/profile-import/stack/default/ceph/minions/ paraconrmar que los OSD se han recogido correctamente.
67
Actualización desde SUSE Enterprise Storage 4 (distribución de ceph-deploy) a la
versión 5 SES 5
NotaEl archivo policy.cfg generado solo aplicará funciones a los serviciosde Ceph detectados "role-mon", "role-mgr", "role-mds", "role-rgw", "role-admin" y "role-master" para el nodo master de Salt. Las otras funciones quedesee deberán añadirse manualmente al archivo (consulte la Sección 4.5.1.2,
“Asignación de funciones”).
El archivo ceph.conf del clúster existente se guardará en /srv/salt/ceph/confi-guration/files/ceph.conf.import .
srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml
incluirá las redes fsid, de clúster y pública del clúster, y también especificarála opción configuration_init: default-import , por lo que DeepSea usaráel archivo de configuración ceph.conf.import mencionado anteriormente, enlugar de utilizar la plantilla por defecto de DeepSea /srv/salt/ceph/configu-ration/files/ceph.conf.j2 .
Nota: archivo ceph.conf personalizadoSi necesita integrar el archivo ceph.conf con cambios personalizados, esperea que el proceso de actualización o importación nalice correctamente. Acontinuación, modique el archivo /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml y convierta en comentario la líneasiguiente:
configuration_init: default-import
Guarde el archivo y siga las instrucciones del Libro “Guía de administración”,
Capítulo 1 “Administración de un clúster de Salt”, Sección 1.11 “Archivo ceph.conf
personalizado”.
Los distintos anillos de claves del clúster se guardan en los directorios siguientes:
/srv/salt/ceph/admin/cache//srv/salt/ceph/mon/cache//srv/salt/ceph/osd/cache//srv/salt/ceph/mds/cache/
68
Actualización desde SUSE Enterprise Storage 4 (distribución de ceph-deploy) a la
versión 5 SES 5
/srv/salt/ceph/rgw/cache/
Verique que existen los archivos de anillos de claves y que no hay ningún archivode anillo de claves en el siguiente directorio (Ceph Manager no existía en versionesanteriores a SUSE Enterprise Storage 5):
/srv/salt/ceph/mgr/cache/
11. El comando salt-run populate.engulf_existing_cluster no gestiona la impor-tación de la configuración de openATTIC. Tendrá que editar manualmente el archivopolicy.cfg y añadir una línea role-openattic . Consulte la Sección 4.5.1, “El archivo
policy.cfg” para obtener más información.
12. El comando salt-run populate.engulf_existing_cluster no gestiona la importaciónde las configuraciones de iSCSI Gateway. Si el clúster incluye instancias de iSCSI Gateway,importe manualmente sus configuraciones:
a. En uno de los nodos de iSCSI Gateway, exporte el archivo lrbd.conf actual ycópielo en el nodo master de Salt:
root@minion > lrbd -o >/tmp/lrbd.confroot@minion > scp /tmp/lrbd.conf admin:/srv/salt/ceph/igw/cache/lrbd.conf
b. En el nodo master de Salt, añada la configuración por defecto de iSCSI Gateway enla configuración de DeepSea:
root@master # mkdir -p /srv/pillar/ceph/stack/ceph/root@master # echo 'igw_config: default-ui' >> /srv/pillar/ceph/stack/ceph/cluster.ymlroot@master # chown salt:salt /srv/pillar/ceph/stack/ceph/cluster.yml
c. Añada las funciones de iSCSI Gateway en policy.cfg y guarde el archivo:
role-igw/stack/default/ceph/minions/ses-1.ses.suse.ymlrole-igw/cluster/ses-1.ses.suse.sls[...]
13. Ejecute la fase 1 para crear todas las funciones posibles:
root@master # salt-run state.orch ceph.stage.1
69
Actualización desde SUSE Enterprise Storage 4 (distribución de ceph-deploy) a la
versión 5 SES 5
14. Genere los subdirectorios necesarios en /srv/pillar/ceph/stack :
root@master # salt-run push.proposal
15. Verique que hay un clúster gestionado por DeepSea en funcionamiento con las funcionesasignadas correctamente:
root@master # salt target pillar.get roles
Compare el resultado con el diseño real del clúster.
16. Calamari deja un trabajo de Salt programado en ejecución y comprueba el estado delclúster. Elimine el trabajo:
root@minion > salt target schedule.delete ceph.heartbeat
17. A partir de este punto, siga el procedimiento que se describe en la Sección 5.4, “Actualización
desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la versión 5”.
5.6 Actualización desde SUSE Enterprise Storage 4(distribución de Crowbar) a la versión 5
Importante: requisitos de softwareDebe tener el siguiente software instalado y actualizado con las últimas versiones de lospaquetes en todos los nodos de Ceph que desee actualizar antes de iniciar el procedimientode actualización:
SUSE Linux Enterprise Server 12 SP2
SUSE Enterprise Storage 4
Para actualizar la instancia de SUSE Enterprise Storage 4 distribuida mediante Crowbar a laversión 5, siga estos pasos:
1. Para cada nodo de Ceph (incluido el nodo de Calamari), detenga e inhabilite todos losservicios relacionados con Crowbar:
root@minion > sudo systemctl stop chef-client
70
Actualización desde SUSE Enterprise Storage 4 (distribución de Crowbar) a la
versión 5 SES 5
root@minion > sudo systemctl disable chef-clientroot@minion > sudo systemctl disable crowbar_joinroot@minion > sudo systemctl disable crowbar_notify_shutdown
2. Para cada nodo de Ceph (incluido el nodo de Calamari), verique que los repositoriosde software señalan a los productos SUSE Enterprise Storage 5 y SUSE Linux EnterpriseServer 12 SP3. Si todavía hay repositorios que señalen a versiones anteriores del producto,inhabilítelos.
3. Para cada nodo de Ceph (incluido el nodo de Calamari), verique que salt-minion estáinstalado. Si no lo está, instálelo:
root@minion > sudo zypper in salt salt-minion
4. Para los nodos de Ceph que no tengan el paquete salt-minion instalado, cree el archivo/etc/salt/minion.d/master.conf y haga que la opción master señale al nombre dehost completo del nodo de Calamari:
master: full_calamari_hostname
SugerenciaLos minions de Salt existentes tienen la opción master: ya denida en /etc/salt/minion.d/calamari.conf . No importa el nombre de archivo de configuración quese use, pero el directorio /etc/salt/minion.d/ sí es importante.
Habilite e inicie el servicio salt-minion :
root@minion > sudo systemctl enable salt-minionroot@minion > sudo systemctl start salt-minion
5. En el nodo de Calamari, acepte las claves de los minions de Salt restantes:
root@master # salt-key -L[...]Unaccepted Keys:d52-54-00-16-45-0a.example.comd52-54-00-70-ac-30.example.com[...]
root@master # salt-key -AThe following keys are going to be accepted:
71
Actualización desde SUSE Enterprise Storage 4 (distribución de Crowbar) a la
versión 5 SES 5
Unaccepted Keys:d52-54-00-16-45-0a.example.comd52-54-00-70-ac-30.example.comProceed? [n/Y] yKey for minion d52-54-00-16-45-0a.example.com accepted.Key for minion d52-54-00-70-ac-30.example.com accepted.
6. Si se ha distribuido Ceph en la red pública y no existe ninguna interfaz VLAN, añada unainterfaz VLAN en la red pública de Crowbar al nodo de Calamari.
7. Actualice el nodo de Calamari a SUSE Linux Enterprise Server 12 SP3 y SUSE EnterpriseStorage 5, ya sea mediante zypper migration o con el método que preera. A partirde este punto, el nodo de Calamari se convierte en el master de Salt. Después de la actua-lización, reinicie el master de Salt.
8. Instale DeepSea en el master de Salt:
root@master # zypper in deepsea
9. Especifique la opción deepsea_minions para incluir el grupo correcto de minions de Salten fases de distribución. Consulte Sección 4.2.2.3, “Definición de la opción deepsea_minions”
para obtener más información.
10. DeepSea espera que todos los nodos de Ceph tengan un archivo /etc/ceph/ceph.confidéntico. Crowbar distribuye una versión ligeramente distinta de ceph.conf a cada nodo,por lo que deberá consolidarlas:
Elimine la opción osd crush location hook que incluyó Calamari.
Elimine la opción public addr de la sección [mon] .
Elimine los números de puerto de la opción mon host .
72
Actualización desde SUSE Enterprise Storage 4 (distribución de Crowbar) a la
versión 5 SES 5
11. Si se estaba ejecutando Object Gateway, Crowbar habrá distribuido un archivo /
etc/ceph/ceph.conf.radosgw independiente para mantener los secretos de Keystoneseparados del archivo ceph.conf normal. Crowbar también habrá añadido un archivo /etc/systemd/system/[email protected] personalizado. Dado que DeepSea no loadmite, deberá eliminarlo:
Añada al nal de todas las secciones [client.rgw...] del archivo ceph.conf.ra-dosgw a /etc/ceph/ceph.conf en todos los nodos.
En el nodo de Object Gateway, ejecute lo siguiente:
root@minion > rm /etc/systemd/system/[email protected] reenable [email protected].$hostname
12. Asegúrese de que ceph status funciona cuando se ejecuta desde el master de Salt:
root@master # ceph statuscluster a705580c-a7ae-4fae-815c-5cb9c1ded6c2health HEALTH_OK[...]
13. Importe el clúster existente:
root@master # salt-run populate.engulf_existing_clusterroot@master # salt-run state.orch ceph.stage.1root@master # salt-run push.proposal
14. El comando salt-run populate.engulf_existing_cluster no gestiona la importaciónde las configuraciones de iSCSI Gateway. Si el clúster incluye instancias de iSCSI Gateway,importe manualmente sus configuraciones:
a. En uno de los nodos de iSCSI Gateway, exporte el archivo lrbd.conf actual ycópielo en el nodo master de Salt:
root@minion > lrbd -o > /tmp/lrbd.confroot@minion > scp /tmp/lrbd.conf admin:/srv/salt/ceph/igw/cache/lrbd.conf
b. En el nodo master de Salt, añada la configuración por defecto de iSCSI Gateway enla configuración de DeepSea:
root@master # mkdir -p /srv/pillar/ceph/stack/ceph/root@master # echo 'igw_config: default-ui' >> /srv/pillar/ceph/stack/ceph/cluster.yml
73
Actualización desde SUSE Enterprise Storage 4 (distribución de Crowbar) a la
versión 5 SES 5
root@master # chown salt:salt /srv/pillar/ceph/stack/ceph/cluster.yml
c. Añada las funciones de iSCSI Gateway en policy.cfg y guarde el archivo:
role-igw/stack/default/ceph/minions/ses-1.ses.suse.ymlrole-igw/cluster/ses-1.ses.suse.sls[...]
15. a. Si ha registrado los sistemas con SUSEConnect y usa el SCC/SMT, no necesita llevara cabo ninguna otra acción.
b. Si no usa el SCC/SMT, sino una imagen ISO de medios u otro origen de paquete,añada los siguientes repositorios manualmente: SLE12-SP3 Base, SLE12-SP3 Update,SES5 Base y SES5 Update. Puede hacerlo con el comando zypper . Antes, eliminetodos los repositorios de software existentes y, a continuación, añada los nuevosrepositorios necesarios. Por último, actualice los orígenes de los repositorios:
root # zypper sd {0..99}root # zypper ar \ http://172.17.2.210:82/repo/SUSE/Products/Storage/5/x86_64/product/ SES5-POOLroot # zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATESroot # zypper ar \ http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOLroot # zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATESroot # zypper ref
Cambie los datos de Pillar para utilizar una estrategia diferente. Editar
/srv/pillar/ceph/stack/name_of_cluster/cluster.yml
Y añada la línea siguiente:
upgrade_init: zypper-dup
74
Actualización desde SUSE Enterprise Storage 4 (distribución de Crowbar) a la
versión 5 SES 5
SugerenciaLa estrategia zypper-dup requiere que se añadan manualmente los reposi-torios de software más recientes, mientras que la opción por defecto zypper-migration se basa en los repositorios proporcionados por el SCC/SMT.
16. Arregle los elementos grain del host para hacer que DeepSea utilice nombres de hostcortos en la red pública para los ID de instancia del daemon de Ceph. Para cada nodo,debe ejecutar grains.set con el nombre de host (corto) nuevo. Antes de ejecutargrains.set , verique las instancias del monitor actual ejecutando ceph status . Semuestra un ejemplo del antes y el después:
root@master # salt target grains.get hostd52-54-00-16-45-0a.example.com: d52-54-00-16-45-0ad52-54-00-49-17-2a.example.com: d52-54-00-49-17-2ad52-54-00-76-21-bc.example.com: d52-54-00-76-21-bcd52-54-00-70-ac-30.example.com: d52-54-00-70-ac-30
root@master # salt d52-54-00-16-45-0a.example.com grains.set \ host public.d52-54-00-16-45-0aroot@master # salt d52-54-00-49-17-2a.example.com grains.set \ host public.d52-54-00-49-17-2aroot@master # salt d52-54-00-76-21-bc.example.com grains.set \ host public.d52-54-00-76-21-bcroot@master # salt d52-54-00-70-ac-30.example.com grains.set \ host public.d52-54-00-70-ac-30
root@master # salt target grains.get hostd52-54-00-76-21-bc.example.com: public.d52-54-00-76-21-bcd52-54-00-16-45-0a.example.com: public.d52-54-00-16-45-0ad52-54-00-49-17-2a.example.com: public.d52-54-00-49-17-2ad52-54-00-70-ac-30.example.com: public.d52-54-00-70-ac-30
75
Actualización desde SUSE Enterprise Storage 4 (distribución de Crowbar) a la
versión 5 SES 5
17. Ejecute la actualización:
root@master # salt target state.apply ceph.updatesroot@master # salt target test.versionroot@master # salt-run state.orch ceph.maintenance.upgrade
Se reiniciarán todos los nodos. El clúster se volverá a activar con una advertencia de queno hay ninguna instancia de Ceph Manager activa. Esto es normal. Calamari no debe estarinstalado ni en ejecución ya en este punto.
18. Ejecute todas las fases de distribución necesarias para hacer que el clúster tenga un estadocorrecto:
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.3
19. Para distribuir openATTIC (consulte el Libro “Guía de administración”, Capítulo 15
“openATTIC”), añada una línea role-openattic adecuada (consulte la Sección 4.5.1.2,
“Asignación de funciones”) a /srv/pillar/ceph/proposals/policy.cfg y ejecute:
root@master # salt-run state.orch ceph.stage.2root@master # salt-run state.orch ceph.stage.4
20. Durante la actualización, es posible que reciba errores de tipo "Error EINVAL: entity [...]exists but caps do not match" (Error EINVAL: la entidad [...] existe pero las caps nocoinciden). Para solucionarlos, consulte la Sección 5.4, “Actualización desde SUSE Enterprise
Storage 4 (distribución de DeepSea) a la versión 5”.
76
Actualización desde SUSE Enterprise Storage 4 (distribución de Crowbar) a la
versión 5 SES 5
21. Lleve a cabo la limpieza restante:
Crowbar crea entradas en /etc/fstab para cada OSD. No son necesarias, así quesuprímalas.
Calamari deja un trabajo de Salt programado en ejecución y comprueba el estadodel clúster. Elimine el trabajo:
root@master # salt target schedule.delete ceph.heartbeat
Aún hay algunos paquetes innecesarios instalados, principalmente gemas de ruby yrelacionados con chef. Su eliminación no es obligatoria, pero puede hacerlo ejecu-tando zypper rm nombre_paquete .
5.7 Actualización desde SUSE Enterprise Storage 3 ala versión 5
Importante: requisitos de softwareDebe tener el siguiente software instalado y actualizado con las últimas versiones de lospaquetes en todos los nodos de Ceph que desee actualizar antes de iniciar el procedimientode actualización:
SUSE Linux Enterprise Server 12 SP1
SUSE Enterprise Storage 3
Para actualizar el clúster de SUSE Enterprise Storage 3 a la versión 5, siga los pasos descritosen el Procedimiento 5.1, “Pasos que se deben aplicar a todos los nodos del clúster (incluido el nodo de
Calamari)” y, a continuación, los descritos en el Procedimiento 5.2, “Pasos que se deben aplicar en
el nodo master de Salt”.
77 Actualización desde SUSE Enterprise Storage 3 a la versión 5 SES 5
6 Copia de seguridad de la configuración del clúster
Este capítulo explica de qué archivos del nodo de administración se debe realizar una copia deseguridad. En cuanto termine con la distribución o la migración del clúster, cree una copia deseguridad de estos directorios.
6.1 Copia de seguridad de la configuración de Salt
Se puede realizar una copia de seguridad del directorio /etc/salt/ . Contiene los archivos deconfiguración de Salt, por ejemplo la clave maestra de Salt y las claves de cliente aceptadas.
No es estrictamente necesario incluir los archivos de Salt al realizar una copia de seguridad delnodo de administración, pero facilita la posterior redistribución del clúster de Salt. Si no se haceuna copia de seguridad de estos archivos, los minions de Salt deben registrarse de nuevo en elnuevo nodo de administración.
Nota: seguridad de la clave privada de master de SaltAsegúrese de que la copia de seguridad de la clave privada del master de Salt se guardaen una ubicación segura. La clave del master de Salt puede emplearse para manipulartodos los nodos del clúster.
Después de restaurar el directorio /etc/salt desde una copia de seguridad, reinicie losservicios de Salt:
root@master # systemctl restart salt-masterroot@master # systemctl restart salt-minion
6.2 Copia de seguridad de la configuración deDeepSea
Todos los archivos requeridos por DeepSea se almacenan en /srv/pillar/ , en /srv/salt/y en /etc/salt/master.d .
78 Copia de seguridad de la configuración de Salt SES 5
Si necesita volver a distribuir el nodo de administración, instale el paquete de DeepSea en elnodo nuevo y mueva los datos copiados de vuelta a los directorios. DeepSea puede usarse denuevo sin realizar más cambios. Antes de volver a utilizar DeepSea, asegúrese de que todos losminions de Salt están registrados correctamente en el nodo de administración.
79 Copia de seguridad de la configuración de DeepSea SES 5
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 de redo el software que se instala en el master de Salt por defecto. Lo primero se puede llevar a cabomodificando la versión actualizada de Pillar después de la fase 2, mientras que lo segundo serealiza normalmente creando un archivo sls personalizado y añadiéndolo a Pillar. Los detallesse 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
80 Uso de archivos de configuración personalizados SES 5
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
81 Sustitución de un paso de la distribución SES 5
- unless: "rbd -p rbd ls | grep -q archive1$" - fire_event: True
archive2: cmd.run: - name: "rbd -p rbd create archive2 --size=768" - unless: "rbd -p rbd ls | grep -q archive2$" - fire_event: True
1 El módulo wait se pondrá en pausa hasta que el clúster de Ceph no tenga el 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.
82 Sustitución de un paso de la distribución SES 5
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
83 Modificación de un paso de la distribución SES 5
7.1.4 Modificación de una etapa 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:
84 Modificación de una etapa de la distribución SES 5
- .logrotate - .master - .minion
2. Sustituya el comportamiento por defecto. Edite /srv/pillar/ceph/stack/global.yml ,añada la siguiente línea y guarde el archivo:
stage_prep: custom
3. Compruebe que la fase 0 funciona:
root@master # salt-run state.orch ceph.stage.0
Nota: ¿por qué global.yml?Se 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 Inhabilitación de actualizaciones y reinicios durante la fase 0
Durante la fase 0 (consulte Descripción de las fases de DeepSea para obtener más informaciónacerca de las fases de DeepSea) el master y los minions de Salt pueden reiniciarse debido a quelos paquetes se actualizan; por ejemplo, kernel , requiere que se reinicie el sistema.
Para evitar que los nodos de clúster se actualicen o se reinicien durante la fase 0, edite/srv/pillar/ceph/stack/ceph/cluster.yml y añada la opciones stage_prep_master ostage_prep_minion , según si debe modicar el comportamiento del master de Salt, de todoslos minions o de todos los nodos.
Ambas opciones aceptan los valores siguientes:
default-no-update-no-reboot
Impide que el formulario de nodos actualice y reinicie sus paquetes.
default-no-update-reboot
Impide que los nodos actualicen sus paquetes, pero se permiten los reinicios.
default-update-no-reboot
Impide que los nodos se reinicien, pero se permite la actualización de sus paquetes.
85 Inhabilitación de actualizaciones y reinicios durante la fase 0 SES 5
default
Permite actualizar los paquetes de los nodos y reiniciarlos.
7.2 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 - mon - storage - mds - igw - rgw - client-cephfs - client-radosgw - client-iscsi - mds-nfs - rgw-nfs - master cluster: ceph cluster_network: 172.16.22.0/24 fsid: e08ec63c-8268-3f04-bcdb-614921e94342 master_minion: admin.ceph mon_host: - 172.16.21.13 - 172.16.21.11 - 172.16.21.12 mon_initial_members: - mon3 - mon1 - mon2
86 Modificación de la configuración descubierta SES 5
public_address: 172.16.21.11 public_network: 172.16.21.0/24 roles: - admin - mon - mds time_server: admin.ceph time_service: ntp
Los valores mencionados anteriormente están distribuidos en varios archivos de 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.
87 Modificación de la configuración descubierta SES 5
3. Para vericar los cambios, ejecute:
root@master # salt target saltutil.pillar_refresh
y a continuación:
root@master # salt target pillar.items
88 Modificación de la configuración descubierta SES 5
III Instalación de servicios adicionales
8 Instalación de servicios para acceder a los datos 90
9 Ceph Object Gateway 91
10 Instalación de iSCSI Gateway 98
11 Instalación de CephFS 115
12 Instalación de NFS Ganesha 121
13 Exportación de CephFS mediante Samba 128
8 Instalación de servicios para acceder a los datos
Después de distribuir el clúster de SUSE Enterprise Storage, puede que deba instalar softwareadicional para acceder a los datos, por ejemplo Object Gateway o iSCSI Gateway; o también bienpuede distribuir un sistema de archivos agrupados en clúster 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 4, Distribución con DeepSea/Salt como instalar pasarelasconcretas o CephFS.
90 SES 5
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 de Object Gateway utiliza un servidor HTTP incrustado (CivetWeb) para interactuarcon el clúster de Ceph. Puesto que proporciona interfaces compatible con OpenStack Swift yAmazon S3, Object Gateway tiene su propia de gestión de usuarios. Object Gateway puedealmacenar datos en el mismo clúster que se utiliza para almacenar datos de clientes de CephFS oclientes del dispositivo de bloques RADOS. Las API S3 y Swift comparten un espacio de nombrecomún, de forma que es posible escribir datos con una API y recuperarlos con la otra.
Importante: Object Gateway distribuida por DeepSeaDesde SUSE Enterprise Storage 5, Object Gateway se instala como una función deDeepSea; por lo tanto, no es necesario realizar una instalación manual.
Para instalar Object Gateway durante la distribución del clúster, consulte la Sección 4.3,
“Distribución del clúster”.
Para añadir un nodo nuevo con Object Gateway para el clúster, consulte el Libro “Guía de
administración”, Capítulo 1 “Administración de un clúster de Salt”, Sección 1.2 “Adición de nuevas
funciones a los nodos”.
9.1 Instalación manual de Object Gateway
1. Instale Object Gateway en un nodo que no esté utilizando el puerto 80. Por ejemplo, en unnodo donde se ejecute openATTIC ya se está utilizando el puerto 80. El comando siguienteinstala todos los componentes necesarios:
cephadm > sudo zypper ref && sudo zypper in ceph-radosgw
91 Instalación manual de Object Gateway SES 5
2. Si se está ejecutando el servidor Apache de la instancia anterior de Object Gateway,deténgalo e inhabilite el servicio correspondiente:
cephadm > sudo systemctl stop disable apache2.service
3. Edite /etc/ceph/ceph.conf y añada las líneas siguientes:
[client.rgw.gateway_host] rgw frontends = "civetweb port=80"
SugerenciaSi desea configurar Object Gateway/CivetWeb para su uso con el cifrado SSL,modique la línea así:
rgw frontends = civetweb port=7480s ssl_certificate=path_to_certificate.pem
4. Reinicie el servicio de Object Gateway.
cephadm > sudo systemctl restart [email protected]_host
9.1.1 Configuración de Object Gateway
Se requieren varios pasos para configurar una instancia de Object Gateway.
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.
92 Configuración de Object Gateway SES 5
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 > sudo ceph-authtool --create-keyring /etc/ceph/ceph.client.rgw.keyringcephadm > 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 > sudo ceph-authtool /etc/ceph/ceph.client.rgw.keyring \ -n client.rgw.gateway --gen-key
3. Añada funciones a la clave:
cephadm > sudo ceph-authtool -n client.rgw.gateway --cap osd 'allow rwx' \ --cap mon 'allow rwx' /etc/ceph/ceph.client.rgw.keyring
4. Después de que haya creado un anillo de claves y la clave para dar acceso a Ceph ObjectGateway al clúster de almacenamiento de Ceph, añada la clave al clúster de almacena-miento de Ceph. Por ejemplo:
cephadm > sudo ceph -k /etc/ceph/ceph.client.admin.keyring auth add client.rgw.gateway \ -i /etc/ceph/ceph.client.rgw.keyring
5. Distribuya el anillo de claves al nodo que contiene la instancia de la pasarela:
cephadm > sudo scp /etc/ceph/ceph.client.rgw.keyring ceph@hostname:/home/cephcephadm > ssh hostnamecephadm > sudo mv ceph.client.rgw.keyring /etc/ceph/ceph.client.rgw.keyring
93 Configuración de Object Gateway SES 5
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 > sudo ceph \ auth get-or-create client.bootstrap-rgw mon 'allow profile bootstrap-rgw' \ --connect-timeout=25 \ --cluster=ceph \ --name mon. \ --keyring=/var/lib/ceph/mon/ceph-node_host/keyring \ -o /var/lib/ceph/bootstrap-rgw/keyring
2. Cree el directorio /var/lib/ceph/radosgw/ceph-rgw_name para almacenar elanillo de claves bootstrap:
cephadm > sudo mkdir \/var/lib/ceph/radosgw/ceph-rgw_name
3. Cree un anillo de claves de Object Gateway a partir del anillo de claves bootstraprecién creado:
cephadm > sudo ceph \ auth get-or-create client.rgw.rgw_name osd 'allow rwx' mon 'allow rw' \ --connect-timeout=25 \ --cluster=ceph \ --name client.bootstrap-rgw \ --keyring=/var/lib/ceph/bootstrap-rgw/keyring \ -o /var/lib/ceph/radosgw/ceph-rgw_name/keyring
4. Copie el anillo de claves de Object Gateway en el host de Object Gateway:
cephadm > sudo scp \/var/lib/ceph/radosgw/ceph-rgw_name/keyring \rgw_host:/var/lib/ceph/radosgw/ceph-rgw_name/keyring
94 Configuración de Object Gateway SES 5
9.1.1.2 Creación de repositorios (opcional)
Ceph Object Gateway requiere repositorios del clúster de almacenamiento de Ceph 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 7
“Gestión de repositorios de almacenamiento”, Sección 7.2.2 “Creación de repositorios”.
Importante: Object Gateway y repositorios codificados de borradoSolo 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.
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 = hostnamekeyring = /etc/ceph/ceph.client.rgw.keyring
95 Configuración de Object Gateway SES 5
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
NotaEl 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
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 = hostname
También debe plantearse la instalación de un servidor DNS como Dnsmasq en los equiposcliente cuando utilice la sintaxis http://bucketname.hostname . El archivo dnsmasq.confdebe incluir los siguientes ajustes:
address=/hostname/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.
96 Configuración de Object Gateway SES 5
9.1.1.4 Creación del directorio de datos
Puede que los guiones de distribución no creen el directorio de datos por defecto de 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.
cephadm > sudo mkdir -p /var/lib/ceph/radosgw/cluster-id
Con el ejemplo del valor de ceph.conf descrito anteriormente, debería ejecutarse lo siguiente:
cephadm > sudo mkdir -p /var/lib/ceph/radosgw/ceph-radosgw.gateway
9.1.1.5 Reinicio de los servicios e inicio de la pasarela
Para asegurarse de que todos los componentes vuelven a cargar sus 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 2 “Introducción” y la Libro “Guía de administración”, Capítulo 11 “Ceph Object Gateway”,
Sección 11.3 “Funcionamiento del servicio de Object Gateway”.
Cuando el servicio esté activo y en ejecución, puede realizar una petición GET anónima 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>
97 Configuración de Object Gateway SES 5
10 Instalación de iSCSI Gateway
iSCSI es un protocolo de red de área de almacenamiento (SAN) que permite a los clientes(denominados iniciadores) enviar comandos SCSI a dispositivos de almacenamiento SCSI(destinos) en servidores remotos. SUSE Enterprise Storage incluye una utilidad que 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 estanda-rizado también proporciona una capa adicional de aislamiento de seguridad entre los clientes yel clúster de SUSE Enterprise Storage. La utilidad de configuración se denomina lrbd . Mediantelrbd , los administradores de almacenamiento de Ceph pueden denir volúmenes de provisiónligera, replicados y de alta disponibilidad compatibles con las instantáneas de solo lectura, losclones de lectura y escritura y el cambio de tamaño automático con el dispositivo de bloquesRADOS (RBD) de Ceph. Los administradores pueden, a continuación, exportar volúmenes através de un host de pasarela lrbd único o a través de varios hosts de pasarela que admitanfailover de múltiples rutas. Los hosts de Linux, Microsoft Windows y VMware pueden conectarsea los volúmenes mediante el protocolo iSCSI, por lo que están disponibles igual que cualquierotro dispositivo de bloques SCSI. Esto signica que los clientes de SUSE Enterprise Storagepueden ejecutar de forma ecaz un subsistema completo de infraestructura de almacenamientode bloques en Ceph que proporcione todas las funciones y ventajas de una SAN convencional,lo que permite el crecimiento en el futuro.
Este capítulo presenta información detallada para 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 iSCSI
iSCSI es una implementación del conjunto de comandos Small Computer System Interface (SCSI,interfaz de sistema informático pequeño) que usa el protocolo de Internet (IP) 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).
98 Almacenamiento de bloques iSCSI SES 5
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
99 Destino iSCSI de kernel de Linux SES 5
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 lrbd
lrbd combina las ventajas de los dispositivos de bloques RADOS con la versatilidad extendidade iSCSI. Si se emplea lrbd en un host de destino iSCSI (conocido como pasarela lrbd ),cualquier aplicación que necesite hacer uso del almacenamiento de bloques puede beneficiarsede Ceph, incluso si no utiliza ningún protocolo de cliente de Ceph. En su lugar, los usuariospueden utilizar iSCSI o cualquier otro protocolo de interfaz de usuario de destino para conec-tarse a un destino LIO, que traduce todas las comunicaciones de E/S de destino en operacionesde almacenamiento RBD.
100 Información general sobre lrbd SES 5
FIGURA 10.1: CLÚSTER DE CEPH CON UNA SOLA INSTANCIA DE ISCSI GATEWAY
Por naturaleza, lrbd es de alta disponibilidad y admite operaciones de múltiples rutas. Por lotanto, los hosts de iniciador descendentes pueden utilizar varias instancias de iSCSI Gatewaypara obtener tanto alta disponibilidad como capacidad de ampliación. Cuando se comunicancon una configuración iSCSI con más de un pasarela, los iniciadores pueden equilibrar la cargade las peticiones iSCSI entre varias pasarelas. En caso de fallo de una pasarela, por ejemplo si nose pueda acceder temporalmente o si está inhabilitada por mantenimiento, las comunicacionesde E/S continuarán de forma transparente a través de otra pasarela.
FIGURA 10.2: CLÚSTER DE CEPH CON VARIAS INSTANCIAS DE ISCSI GATEWAY
101 Información general sobre lrbd SES 5
10.3 Consideraciones de distribución
Una configuración mínima de SUSE Enterprise Storage con lrbd consta de los siguientes compo-nentes:
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 mediantelrbd .
Un host de iniciador iSCSI, con open-iscsi (Linux) en ejecución, el iniciador iSCSI deMicrosoft (Microsoft Windows) o cualquier otra implementación de iniciador iSCSI compa-tible.
Una configuración de producción recomendada de SUSE Enterprise Storage con lrbd consta de:
Un clúster de almacenamiento de Ceph. Un clúster de producción de Ceph formado 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 lrbd . Para el failover y el equilibrio de carga iSCSI, estos servidores debenejecutar un kernel que admita el módulo target_core_rbd . Hay disponibles paquetes deactualizació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ón
En esta sección se describen los pasos necesarios para instalar y configurar una instancia deiSCSI Gateway en SUSE Enterprise Storage.
102 Consideraciones de distribución SES 5
10.4.1 Distribución de iSCSI Gateway en un clúster de Ceph
Es posible distribuir iSCSI Gateway durante el proceso de distribución del clúster de Ceph 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 4.5.1.2, “Asignación de funciones”.
Para añadir iSCSI Gateway a un clúster existente, consulte el Libro “Guía de administración”,
Capítulo 1 “Administración de un clúster de Salt”, Sección 1.2 “Adición de nuevas funciones a los nodos”.
10.4.2 Creación de imágenes RBD
Las imágenes RBD se crean en el almacén de Ceph y, posteriormente, se exportan a iSCSI. 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 , ejecute:
root # rbd --pool iscsi create --size=102400 testvol
El comando anterior crea un volumen RBD con el formato 2 por defecto.
NotaA partir de SUSE Enterprise Storage 3, el formato de volumen por defecto es el 2 y elformato 1 ha quedado obsoleto. Sin embargo, aún es posible crear volúmenes con elformato obsoleto 1 mediante la opción --image-format 1 .
10.4.3 Exportación de imágenes RBD a través de iSCSI
Para exportar imágenes RBD a través de iSCSI, utilice la utilidad lrbd . lrbd permite crear,revisar y modicar la configuración del destino iSCSI, que utiliza un formato JSON.
103 Distribución de iSCSI Gateway en un clúster de Ceph SES 5
Sugerencia: importación de cambios en openATTICCualquier cambio realizado en la configuración de iSCSI Gateway mediante el comandolrbd no será visible para DeepSea ni openATTIC. Para importar los cambios manuales,hay que exportar la configuración de iSCSI Gateway a un archivo:
root@minion > lrbd -o /tmp/lrbd.conf
A continuación, copie ese archivo en el master de Salt para que DeepSea y openATTICpuedan verlo:
root@minion > scp /tmp/lrbd.conf ses5master:/srv/salt/ceph/igw/cache/lrbd.conf
Por último, edite /srv/pillar/ceph/stack/global.yml y dena:
igw_config: default-ui
Para editar la configuración, utilice lrbd -e o lrbd --edit . Este comando invocará el editorpor defecto, denido por la variable de entorno EDITOR . Puede anular este comportamiento;para ello, dena la opción -E además de la opción -e .
A continuación se muestra una configuración de ejemplo para:
dos hosts de iSCSI Gateway denominados iscsi1.example.com y iscsi2.example.com ,
que denen un solo destino iSCSI con el nombre completo iSCSI (IQN)iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol ,
con una sola unidad lógica iSCSI,
con el respaldo de una imagen RBD denominada testvol en el repositorio RADOS rbd ,
y que exporta el destino a través de dos portales denominados "east" y "west":
{ "auth": [ { "target": "iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol", "authentication": "none" } ], "targets": [
104 Exportación de imágenes RBD a través de iSCSI SES 5
{ "target": "iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol", "hosts": [ { "host": "iscsi1.example.com", "portal": "east" }, { "host": "iscsi2.example.com", "portal": "west" } ] } ], "portals": [ { "name": "east", "addresses": [ "192.168.124.104" ] }, { "name": "west", "addresses": [ "192.168.124.105" ] } ], "pools": [ { "pool": "rbd", "gateways": [ { "target": "iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol", "tpg": [ { "image": "testvol" } ] } ] } ] }
Tenga en cuenta que cada vez que haga referencia a un nombre de host de la configuración, esenombre de host debe coincidir con el resultado del comando uname - n de iSCSI Gateway.
105 Exportación de imágenes RBD a través de iSCSI SES 5
El código JSON editado se almacena en los atributos extendidos (xattrs) de un único objetoRADOS por repositorio. Este objeto está disponible para los hosts de pasarela en los que se haeditado el código JSON, así como en todos los hosts de pasarela conectados al mismo clúster deCeph. Localmente, en la pasarela lrbd , no se almacena ninguna información de configuración.
Para activar la configuración, almacénela en el clúster de Ceph y lleve a cabo una de las accionessiguientes (como usuario root ):
Ejecute el comando lrbd (sin opciones adicionales) en la línea de comandos.
O bien
Reinicie el servicio lrbd con service lrbd restart .
El "servicio" lrbd no activa ningún daemon en segundo plano; simplemente invoca el comandolrbd . Este tipo de servicio se conoce como servicio "único" (one-shot).
También debe permitir que lrbd se congure automáticamente al iniciar el sistema. Para ello,ejecute el comando systemctl enable lrbd .
La configuración anterior muestra una implementación sencilla de una pasarela. La configu-ración lrbd puede ser mucho más compleja y potente. El paquete RPM de lrbd incluye unamplio conjunto de ejemplos de configuración que puede consultar en el directorio /usr/share/doc/packages/lrbd/samples después de la instalación. También hay ejemplos dispo-nibles en https://github.com/SUSE/lrbd/tree/master/samples .
10.4.4 Valores opcionales
Los siguientes valores pueden ser útiles en algunos entornos. Para las imágenes, están losatributos uuid , lun , retries , sleep y retry_errors . Los dos primeros, uuid y lun ,permiten denir de un modo predeterminado e inamovible del "uuid" o el "lun" de una imagenconcreta. Puede especificar cualquiera de esos valores para una imagen. Los atributos retries ,sleep y retry_errors afectan a los intentos de asignar una imagen rbd.
"pools": [ { "pool": "rbd", "gateways": [ { "host": "igw1", "tpg": [ {
106 Valores opcionales SES 5
"image": "archive", "uuid": "12345678-abcd-9012-efab-345678901234", "lun": "2", "retries": "3", "sleep": "4", "retry_errors": [ 95 ], [...] } ] } ] }]
10.4.5 Valores avanzados
lrbd puede configurarse con parámetros avanzados que posteriormente se pasan al destino deE/S LIO. Los parámetros se dividen en componentes iSCSI y de almacén de respaldo, que a suvez se pueden especificar en las secciones "targets" y "tpg", respectivamente, en la configuraciónde lrbd .
AvisoNo se recomienda cambiar los valores por defecto de estos parámetros.
"targets": [ { [...] "tpg_default_cmdsn_depth": "64", "tpg_default_erl": "0", "tpg_login_timeout": "10", "tpg_netif_timeout": "2", "tpg_prod_mode_write_protect": "0", }]
A continuación se muestra una descripción de las opciones:
tpg_default_cmdsn_depth
Profundidad de CmdSN (número de secuencia de comando) por defecto. Limita la cantidadde peticiones que un iniciador iSCSI puede tener pendientes en cualquier momento.
107 Valores avanzados SES 5
tpg_default_erl
Nivel de recuperación de error por defecto.
tpg_login_timeout
Valor de tiempo límite de entrada a la sesión en segundos.
tpg_netif_timeout
Tiempo límite de fallo de NIC en segundos.
tpg_prod_mode_write_protect
Si se establece en 1, se impide que se pueda escribir en los LUN.
"pools": [ { "pool": "rbd", "gateways": [ { "host": "igw1", "tpg": [ { "image": "archive", "backstore_block_size": "512", "backstore_emulate_3pc": "1", "backstore_emulate_caw": "1", "backstore_emulate_dpo": "0", "backstore_emulate_fua_read": "0", "backstore_emulate_fua_write": "1", "backstore_emulate_model_alias": "0", "backstore_emulate_rest_reord": "0", "backstore_emulate_tas": "1", "backstore_emulate_tpu": "0", "backstore_emulate_tpws": "0", "backstore_emulate_ua_intlck_ctrl": "0", "backstore_emulate_write_cache": "0", "backstore_enforce_pr_isids": "1", "backstore_fabric_max_sectors": "8192", "backstore_hw_block_size": "512", "backstore_hw_max_sectors": "8192", "backstore_hw_pi_prot_type": "0", "backstore_hw_queue_depth": "128", "backstore_is_nonrot": "1", "backstore_max_unmap_block_desc_count": "1", "backstore_max_unmap_lba_count": "8192", "backstore_max_write_same_len": "65535", "backstore_optimal_sectors": "8192", "backstore_pi_prot_format": "0",
108 Valores avanzados SES 5
"backstore_pi_prot_type": "0", "backstore_queue_depth": "128", "backstore_unmap_granularity": "8192", "backstore_unmap_granularity_alignment": "4194304" } ] } ] }]
A continuación se muestra una descripción de las opciones:
backstore_block_size
Tamaño de bloque del dispositivo subyacente.
backstore_emulate_3pc
Si se establece en 1, se habilita la opción Third Party Copy (Copia por parte de terceros).
backstore_emulate_caw
Si se establece en 1, se habilita la opción Compare and Write (Comparar y escribir).
backstore_emulate_dpo
Si se establece en 1, se activa la opción Disable Page Out (Inhabilitar página saliente).
backstore_emulate_fua_read
Si se establece en 1, se habilita la lectura de Force Unit Access (Forzar acceso a la unidad).
backstore_emulate_fua_write
Si se establece en 1, se habilita la escritura de Force Unit Access (Forzar acceso a la unidad).
backstore_emulate_model_alias
Si se establece en 1, se utiliza el nombre del dispositivo de procesador nal para el aliasdel modelo.
backstore_emulate_rest_reord
Si se establece en 0, la opción Queue Algorithm Modier (Modificador de algoritmo decola) tiene restringido el cambio de orden.
backstore_emulate_tas
Si se establece en 1, se habilita la opción Task Aborted Status (Estado cancelado de tarea).
backstore_emulate_tpu
Si se establece en 1, se habilita la opción Thin Provisioning Unmap (Anular asignación deprovisión ligera).
109 Valores avanzados SES 5
backstore_emulate_tpws
Si se establece en 1, se habilita la opción Thin Provisioning Write Same (Misma escrituraen provisión ligera).
backstore_emulate_ua_intlck_ctrl
Si se establece en 1, se habilita la opción Unit Attention Interlock (Interbloqueo de atenciónen la unidad).
backstore_emulate_write_cache
Si se establece en 1, se activa la opción Write Cache Enable (Habilitar caché de escritura).
backstore_enforce_pr_isids
Si se establece en 1, se fuerzan los ISID de reserva persistente.
backstore_fabric_max_sectors
Número máximo de sectores que la estructura puede transferir al mismo tiempo.
backstore_hw_block_size
Tamaño del bloque de hardware en bytes.
backstore_hw_max_sectors
Número máximo de sectores que el hardware puede transferir al mismo tiempo.
backstore_hw_pi_prot_type
Si es distinto de cero, la protección de DIF está habilitada en el hardware subyacente.
backstore_hw_queue_depth
Profundidad de la cola de hardware.
backstore_is_nonrot
Si se establece en 1, el almacén de respaldo es un dispositivo sin rotación.
backstore_max_unmap_block_desc_count
Número máximo de descriptores de bloque para UNMAP.
backstore_max_unmap_lba_count:
Número máximo de LBA para UNMAP.
backstore_max_write_same_len
Longitud máxima de WRITE_SAME.
backstore_optimal_sectors
Tamaño de la petición óptima en sectores.
110 Valores avanzados SES 5
backstore_pi_prot_format
Formato de la protección DIF.
backstore_pi_prot_type
Tipo de garantía de DIF.
backstore_queue_depth
Profundidad de la cola.
backstore_unmap_granularity
Granularidad de UNMAP.
backstore_unmap_granularity_alignment
Alineación de la granularidad de UNMAP.
Para los destinos, los atributos de tpg permiten ajustar los parámetros del kernel. Utilice estaopción con precaución.
"targets": [{ "host": "igw1", "target": "iqn.2003-01.org.linux-iscsi.generic.x86:sn.abcdefghijk", "tpg_default_cmdsn_depth": "64", "tpg_default_erl": "0", "tpg_login_timeout": "10", "tpg_netif_timeout": "2", "tpg_prod_mode_write_protect": "0", "tpg_t10_pi": "0"}
SugerenciaSi un sitio necesita LUN asignados de forma estática, asigne números a cada LUN.
10.5 Exportación de imágenes del dispositivo debloques RADOS mediante tcmu-runnerA partir de la versión 5, SUSE Enterprise Storage incluye un procesador nal RBD de espacio deusuario para tcmu-runner (consulte la página man 8 tcmu-runner para obtener más infor-mación).
111 Exportación de imágenes del dispositivo de bloques RADOS mediante tcmu-runner SES 5
Aviso: tecnología en fase preliminarLas distribuciones de iSCSI Gateway basadas en tcmu-runner son actualmente una tecno-logía en fase preliminar. Consulte el Capítulo 10, Instalación de iSCSI Gateway para obtenerinstrucciones sobre la distribución de iSCSI Gateway basada en kernel con lrbd .
A diferencia de las distribuciones de iSCSI Gateway lrbd basadas en kernel, las basadas entcmu-runner no ofrecen compatibilidad con E/S de múltiples rutas ni con las reservas persis-tentes SCSI.
Dado que ni DeepSea ni openATTIC admiten actualmente distribuciones tcmu-runner , debegestionar la instalación, la distribución y la supervisión de forma manual.
10.5.1 Instalación
En el nodo de iSCSI Gateway, instale el paquete tcmu-runner-handler-rbd desde los mediosde SUSE Enterprise Storage 5, junto con las dependencias de los paquetes libtcmu1 y tcmu-runner . Instale el paquete targetcli-fb por motivos de configuración. Tenga en cuenta queel paquete targetcli-fb no es compatible con la versión "no fb" del paquete targetcli .
Conrme que el servicio tcmu-runner de systemd está ejecutándose:
root # systemctl enable tcmu-runnertcmu-gw:~ # systemctl status tcmu-runner● tcmu-runner.service - LIO Userspace-passthrough daemon Loaded: loaded (/usr/lib/systemd/system/tcmu-runner.service; static; vendor preset: disabled) Active: active (running) since ...
10.5.2 Configuración y distribución
Cree una imagen del dispositivo de bloques RADOS en su clúster de Ceph existente. En elsiguiente ejemplo, se utilizará una imagen 10G denominada "tcmu-lu" situada en el repositorio"rbd".
Después de crear la imagen del dispositivo de bloques RADOS, ejecute targetcli y asegúresede que el gestor RBD tcmu-runner (un complemento) esté disponible:
root # targetclitargetcli shell version 2.1.fb46
112 Instalación SES 5
Copyright 2011-2013 by Datera, Inc and others.For help on commands, type 'help'.
/> lso- / ................................... [...] o- backstores ........................ [...]... | o- user:rbd ......... [Storage Objects: 0]
Cree una entrada de configuración en el almacén de respaldo para la imagen RBD:
/> cd backstores/user:rbd/backstores/user:rbd> create tcmu-lu 10G /rbd/tcmu-luCreated user-backed storage object tcmu-lu size 10737418240.
Cree una entrada de configuración de transporte de iSCSI. En el siguiente ejemplo,targetcli genera automáticamente el IQN de destino "iqn.2003-01.org.linux-iscsi.tcmu-gw.x8664:sn.cb3d2a3a" para su uso como identificador de destino iSCSI exclusivo:
/backstores/user:rbd> cd /iscsi/iscsi> createCreated target iqn.2003-01.org.linux-iscsi.tcmu-gw.x8664:sn.cb3d2a3a.Created TPG 1.Global pref auto_add_default_portal=trueCreated default portal listening on all IPs (0.0.0.0), port 3260.
Cree una entrada de ACL para los iniciadores iSCSI que desee conectar al destino. En el ejemplosiguiente, se usa el IQN de iniciador "iqn.1998-01.com.vmware:esxi-872c4888":
/iscsi> cdiqn.2003-01.org.linux-iscsi.tcmu-gw.x8664:sn.cb3d2a3a/tpg1/acls//iscsi/iqn.20...a3a/tpg1/acls> create iqn.1998-01.com.vmware:esxi-872c4888
Por último, enlace la configuración del almacén de respaldo RBD creada previamente en eldestino iSCSI:
/iscsi/iqn.20...a3a/tpg1/acls> cd ../luns/iscsi/iqn.20...a3a/tpg1/luns> create /backstores/user:rbd/tcmu-luCreated LUN 0.Created LUN 0->0 mapping in node ACL iqn.1998-01.com.vmware:esxi-872c4888
Salga de la shell para guardar la configuración existente:
/iscsi/iqn.20...a3a/tpg1/luns> exitGlobal pref auto_save_on_exit=true
113 Configuración y distribución SES 5
Last 10 configs saved in /etc/target/backup.Configuration saved to /etc/target/saveconfig.json
10.5.3 Uso
Desde el nodo (cliente) del iniciador iSCSI, conéctese al destino iSCSI recién provisionado utili-zando el IQN y el nombre de host que ha configurado anteriormente.
114 Uso SES 5
11 Instalación de CephFS
El sistema de archivos de Ceph (CephFS) es un sistema de archivos conforme con POSIX 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 directrices
Con SUSE Enterprise Storage, SUSE incluye compatibilidad ocial con muchos escenarios en losque se utiliza el componente de ampliación horizontal y distribuido CephFS. En esta entrada sedescriben 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án"pasivos". No olvide mencionar todos los nodos del servidor de metadatos en el comandomount cuando monte CephFS desde un cliente.
Las instantáneas de CephFS están inhabilitadas (por defecto) y no se admiten en estaversión.
Los clientes se basan en SUSE Linux Enterprise Server 12 SP2 o SP3 y usan el controladorde módulo de kernel cephfs . No se admite el módulo FUSE.
Las cuotas de CephFS no se admiten en SUSE Enterprise Storage, ya que la compatibilidadcon las cuotas se implementa únicamente en el cliente de FUSE.
CephFS admite cambios de diseño de archivos, como se describe en http://docs.ceph.com/
docs/jewel/cephfs/file-layouts/ . Sin embargo, aunque el sistema de archivos se puedemontar mediante cualquier cliente, no es posible añadir nuevos repositorios de datos a unsistema de archivos CephFS existente ( ceph mds add_data_pool ). Solo se pueden añadirmientras el sistema de archivos está desmontado.
115 Escenarios admitidos de CephFS y directrices SES 5
11.2 Servidor de metadatos de Ceph
El servidor de metadatos de Ceph (MDS) almacena los metadatos para CephFS. Los 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 4.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 1 “Administración de un
clúster de Salt”, Sección 1.1 “Adición de nuevos nodos de clúster”.
Después de distribuir el servidor de metadatos, permita el servicio Ceph OSD/MDS en la 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.
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 .
TAMAÑO DE CACHÉ DEL SERVIDOR DE METADATOS
mds cache memory limit
La cantidad máxima de memoria (en bytes) que el servidor de metadatos aplicará para sucaché. Los administradores deben utilizar este valor en lugar del antiguo ajuste mds cachesize . Por defecto es 1 GB.
116 Servidor de metadatos de Ceph SES 5
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.
Para obtener una lista detallada de opciones de configuración relacionadas con el servidor demetadatos, consulte http://docs.ceph.com/docs/master/cephfs/mds-config-ref/ .
Para obtener una lista detallada de opciones de configuración del creador de diarios del servidorde metadatos, consulte http://docs.ceph.com/docs/master/cephfs/journaler/ .
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 7 “Gestión de repositorios de almacenamiento”.
117 CephFS SES 5
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:
root # ceph osd pool create cephfs_data pg_numroot # ceph osd pool create cephfs_metadata pg_num
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 :
root # ceph fs new fs_name metadata_pool_name data_pool_name
Por ejemplo:
root # ceph fs new cephfs cephfs_metadata cephfs_data
Para comprobar que se ha creado el sistema de archivos, puede mostrar todos los sistemas dearchivos CephFS disponibles:
root # ceph fs ls name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]
Cuando se haya creado el sistema de archivos, el servidor de metadatos podrá entrar en unestado activo. Por ejemplo, en un único sistema de servidor de metadatos:
root # ceph mds state5: 1/1/1 up
118 Creación de CephFS SES 5
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 13 “Sistema de archivos con agrupación en clúster”.
11.3.2 Tamaño del clúster del servidor de metadatos
Varios daemons activos de servidor de metadatos pueden dar servicio a una instancia de CephFS.Todos los daemons activos del servidor de metadatos que se asignan a una instancia de 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.
root # ceph mds stat
El siguiente comando dene el número de servidores de metadatos activos a dos en una instanciadel sistema de archivos.
root # ceph fs set fs_name max_mds 2
Con el n de reducir el tamaño del clúster del servidor de metadatos antes de una actualización,es preciso llevar a cabo dos pasos. Primero, dena max_mds para que solo quede una instancia:
root # ceph fs set fs_name max_mds 1
y, después, desactive de forma explícita los demás daemons activos del servidor de metadatos:
root # ceph mds deactivate fs_name:rank
donde rank es el número de un daemon activo del servidor de metadatos de una instancia delsistema de archivos, entre 0 y max_mds -1. Consulte http://docs.ceph.com/docs/luminous/cephfs/
multimds/ para obtener más información.
119 Tamaño del clúster del servidor de metadatos SES 5
11.3.3 Clúster de servidor de metadatos y actualizaciones
Durante las actualizaciones de Ceph, los indicadores de función de una instancia del 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.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:
root # 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.
root # 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.
root # 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.
120 Clúster de servidor de metadatos y actualizaciones SES 5
12 Instalación de NFS Ganesha
NFS Ganesha proporciona acceso NFS para Object Gateway o CephFS. En SUSE EnterpriseStorage 5, 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.
12.1 Preparación
12.1.1 Información general
Para distribuir correctamente NFS Ganesha, debe añadir role-ganesha al archivo /srv/pillar/ceph/proposals/policy.cfg . Para obtener información, consulte: Sección 4.5.1, “El
archivo policy.cfg”. NFS Ganesha también necesita que role-rgw o role-mds estén 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 4.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/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 14
“NFS Ganesha: exportación de datos de Ceph a través de NFS”, Sección 14.2 “Configuración”.
121 Preparación SES 5
12.1.2 Resumen de requisitos
Los siguientes requisitos deben cumplirse antes de ejecutar las fases 2 y 4 de DeepSea a n 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.
Si se espera que NFS Ganesha utilice Object Gateway como interfaz con el clúster, se debecompletar el archivo /srv/pillar/ceph/rgw.sls en el master de Salt.
12.2 Instalación de ejemplo
Este procedimiento proporciona una instalación de ejemplo que usa tanto Object Gateway 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 # salt-run state.orch ceph.stage.0root # salt-run state.orch ceph.stage.1
2. Después de ejecutar la fase 1 de DeepSea, edite el archivo /srv/pillar/ceph/
proposals/policy.cfg y añada la línea:
role-ganesha/cluster/NODENAME
Sustituya NODENAME con el nombre de un nodo del clúster.Asegúrese también de que hay asignados un role-mds y un role-rgw .
3. Cree el archivo /srv/pillar/ceph/rgw.sls e inserte el contenido siguiente:
rgw_configurations: rgw: users: - { uid: "demo", name: "Demo", email: "[email protected]" } - { uid: "demo1", name: "Demo1", email: "[email protected]" }
122 Resumen de requisitos SES 5
Estos usuarios se crean más adelante como usuarios de Object Gateway y se generan clavesde API. En el nodo de Object Gateway, puede ejecutar más tarde radosgw-admin userlist para mostrar todos los usuarios creados y radosgw-admin user info --uid=demopara obtener información acerca de usuarios individuales.DeepSea garantiza que Object Gateway y NFS Ganesha reciben las credenciales de todoslos usuarios mostrados en la sección rgw del archivo rgw.sls .El NFS exportado utiliza los nombres de usuario en el primer nivel del sistema de archivos;en este ejemplo, las vías /demo y /demo1 se exportarán.
4. Ejecute al menos las fases 2 y 4 de DeepSea. Se recomienda ejecutar la fase 3 en medio.
root # salt-run state.orch ceph.stage.2root # salt-run state.orch ceph.stage.3 # optional but recommendedroot # salt-run state.orch ceph.stage.4
5. Verique que NFS Ganesha funciona montando el recurso compartido NFS desde un nodode cliente:
root # mount -o sync -t nfs GANESHA_NODE:/ /mntroot # ls /mntcephfs demo demo1
/mnt debe contener todas las vías exportadas. Deben existir directorios para CephFS ypara ambos usuarios de Object Gateway. Para cada depósito que posea un usuario, seexportará una vía /mnt/NOMBREUSUARIO/NOMBREDEPÓSITO .
12.3 Configuración activa-pasiva de altadisponibilidad
En 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 .
Para obtener información sobre SUSE Linux Enterprise High Availability Extension, consultehttps://www.suse.com/documentation/sle-ha-12/ .
123 Configuración activa-pasiva de alta disponibilidad SES 5
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.
El procedimiento siguiente describe la instalación de ejemplo. Encontrará más información enhttps://www.suse.com/documentation/sle-ha-12/install-quick/data/install-quick.html .
1. Prepare los nodos de NFS Ganesha en el master de Salt:
a. Ejecute las fases 0 y 1 de DeepSea en el master de Salt.
root@master # salt-run state.orch ceph.stage.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 3 y 4 de DeepSea en el master de Salt.
root@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. Instalación ha-cluster-bootstrap en ambos nodos:
root # zypper in ha-cluster-bootstrap
4. a. Inicialice el clúster en earth :
root@earth # ha-cluster-init
124 Instalación básica SES 5
b. Deje que mars se una al clúster:
root@mars # ha-cluster-join -c earth
5. Compruebe el estado del clúster. Debería observar que se han añadido dos nodos al clúster:
root@earth # crm status
6. En ambos nodos, inhabilite el inicio automático del servicio NFS Ganesha durante 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:
125 Instalación básica SES 5
Clone Set: nfs-ganesha-clone [nfs-ganesha-server] Started: [ earth mars ] ganesha-ip (ocf::heartbeat:IPaddr2): Started earth
10. Para configurar una relación entre el servidor de NFS Ganesha y la dirección IP virtualotante, utilice la colocación y el orden.
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
126 Limpieza de recursos SES 5
host_list es una lista de direcciones IP separadas por caracteres de espacio. Se haráping a las direcciones IP con regularidad para comprobar si se producen interrupciones dela red. Si un cliente debe tener acceso continuo al servidor de NFS, añádalo a host_list .
2. Cree un clon:
crm(live)configure# clone ganesha-ping-clone ganesha-ping \ meta interleave=true
3. El siguiente comando crea una restricción para el servicio NFS Ganesha. Fuerza al 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 Más informaciónEncontrará más información en Libro “Guía de administración”, Capítulo 14 “NFS Ganesha: exportación
de datos de Ceph a través de NFS”.
127 Alta disponibilidad de NFS Ganesha y DeepSea SES 5
13 Exportación de CephFS mediante Samba
Esta sección describe cómo exportar CephFS mediante un recurso compartido de Samba/CIFS.Los recursos compartidos de Samba se pueden utilizar con clientes de Windows*.
Aviso: tecnología en fase preliminarA partir de SUSE Enterprise Storage 5, la exportación de recursos compartidos de Sambase considera una tecnología en fase preliminar y no se admite.
13.1 Instalación de ejemploLa exportación de CephFS es una tecnología en fase preliminar y no se admite. Para exportarun recurso compartido de Samba, deberá instalar manualmente Samba en un nodo de clúster yconfigurarlo. Es posible proporcionar funcionalidad de failover con CTDB y SUSE Linux Enter-prise High Availability Extension.
1. Asegúrese de que ya existe una instancia de CephFS en funcionamiento en el clúster. Paraobtener información, consulte: Capítulo 11, Instalación de CephFS.
2. Cree un anillo de claves especíco de la pasarela de Samba en el master de Salt y cópieloen el nodo de pasarela de Samba:
root@master # ceph auth get-or-create client.samba.gw mon 'allow r' \ osd 'allow *' mds 'allow *' -o ceph.client.samba.gw.keyringroot@master # scp ceph.client.samba.gw.keyring SAMBA_NODE:/etc/ceph/
Sustituya SAMBA_NODE con el nombre del nodo de pasarela de Samba.
3. Los siguientes pasos se ejecutan en el nodo de pasarela de Samba. Instale el daemon deSamba en el nodo de pasarela de Samba:
root # zypper in samba samba-ceph
4. Edite el archivo /etc/samba/smb.conf y añada la sección siguiente:
[SHARE_NAME] path = / vfs objects = ceph ceph:config_file = /etc/ceph/ceph.conf
128 Instalación de ejemplo SES 5
ceph: user_id = samba.gw read only = no
5. Inicie y habilite el daemon de Samba:
root # systemctl start smb.serviceroot # systemctl enable smb.serviceroot # systemctl start nmb.serviceroot # systemctl enable nmb.service
13.2 Configuración de alta disponibilidadEn esta sección se proporciona un ejemplo de cómo establecer una configuración de dos nodosde alta disponibilidad de los servidores de Samba. La configuración requiere SUSE Linux Enter-prise High Availability Extension. Los dos nodos se denominan earth ( 192.168.1.1 ) y mars( 192.168.1.2 ).
Para obtener información sobre SUSE Linux Enterprise High Availability Extension, consultehttps://www.suse.com/documentation/sle-ha-12/ .
Asimismo, dos direcciones IP virtuales otantes permiten a los clientes conectarse al servicioindependientemente del nodo físico en el que se estén ejecutando. 192.168.1.10 se usa parala administración del clúster con Hawk2 y 192.168.2.1 se usa exclusivamente para las expor-taciones CIFS. De esta forma es más fácil aplicar más tarde restricciones de seguridad.
El procedimiento siguiente describe la instalación de ejemplo. Encontrará más información enhttps://www.suse.com/documentation/sle-ha-12/install-quick/data/install-quick.html .
1. Cree un anillo de claves especíco de la pasarela de Samba en el master de Salt y cópieloen ambos nodos:
root@master # ceph auth get-or-create client.samba.gw mon 'allow r' \ osd 'allow *' mds 'allow *' -o ceph.client.samba.gw.keyringroot@master # scp ceph.client.samba.gw.keyring earth:/etc/ceph/root@master # scp ceph.client.samba.gw.keyring mars:/etc/ceph/
2. Prepare earth y mars para que alojen el servicio de Samba:
a. Asegúrese de que los paquetes siguientes están instalados antes de continuar: ctdb ,tdb-tools y samba (se necesitan para los recursos smb y nmb).
root # zypper in ctdb tdb-tools samba samba-ceph
129 Configuración de alta disponibilidad SES 5
b. Asegúrese de que los servicios ctdb , smb y nmb están detenidos e inhabilitados:
root # systemctl disable ctdbroot # systemctl disable smbroot # systemctl disable nmbroot # systemctl stop smbroot # systemctl stop nmb
c. Abra el puerto 4379 del cortafuegos en todos los nodos. Esto es necesario para queCTDB pueda comunicarse con los demás nodos del clúster.
d. Cree un directorio para el bloqueo CTDB en el sistema de archivos compartido:
root # mkdir -p /srv/samba/
3. En earth , cree los archivos de configuración de Samba. Más adelante, se sincronizaránautomáticamente con mars .
a. En /etc/ctdb/nodes , inserte todos los nodos que contienen todas las direccionesIP privadas de cada nodo del clúster:
192.168.1.1192.168.1.2
b. Congure Samba. Añada las líneas siguientes en la sección [global] de /
etc/samba/smb.conf . Utilice el nombre de host que desee en lugar de "CTDB-SERVER" (en realidad, todos los nodos del clúster aparecerán como un nodo extensocon este nombre):
[global] netbios name = CTDB-SERVER clustering = yes idmap config * : backend = tdb2 passdb backend = tdbsam ctdbd socket = /var/lib/ctdb/ctdb.socket
Para obtener más información sobre csync2 , consulte https://www.su-
se.com/documentation/sle-ha-12/singlehtml/book_sleha/
book_sleha.html#pro.ha.installation.setup.csync2.start .
4. Instale y cargue el clúster de SUSE Linux Enterprise High Availability.
a. Registre SUSE Linux Enterprise High Availability Extension en earth y mars .
130 Configuración de alta disponibilidad SES 5
root@earth # SUSEConnect -r ACTIVATION_CODE -e E_MAIL
root@mars # SUSEConnect -r ACTIVATION_CODE -e E_MAIL
b. Instale ha-cluster-bootstrap en ambos nodos:
root@earth # zypper in ha-cluster-bootstrap
root@mars # zypper in ha-cluster-bootstrap
c. Inicialice el clúster en earth :
root@earth # ha-cluster-init
d. Deje que mars se una al clúster:
root@mars # ha-cluster-join -c earth
5. Compruebe el estado del clúster. Debería observar que se han añadido dos nodos en elclúster:
root@earth # crm status2 nodes configured1 resource configured
Online: [ earth mars ]
Full list of resources:
admin-ip (ocf::heartbeat:IPaddr2): Started earth
6. Ejecute los comandos siguientes en earth para configurar el recurso CTDB:
root@earth # crm configurecrm(live)configure# primitive ctdb ocf:heartbeat:CTDB params \ ctdb_manages_winbind="false" \ ctdb_manages_samba="false" \ ctdb_recovery_lock="!/usr/lib64/ctdb/ctdb_mutex_ceph_rados_helper ceph client.samba.gw cephfs_metadata ctdb-mutex" ctdb_socket="/var/lib/ctdb/ctdb.socket" \ op monitor interval="10" timeout="20" \ op start interval="0" timeout="90" \ op stop interval="0" timeout="100"crm(live)configure# primitive nmb systemd:nmb \
131 Configuración de alta disponibilidad SES 5
op start timeout="60" interval="0" \ op stop timeout="60" interval="0" \ op monitor interval="60" timeout="60"crm(live)configure# primitive smb systemd:smb \ op start timeout="60" interval="0" \ op stop timeout="60" interval="0" \ op monitor interval="60" timeout="60"crm(live)configure# group g-ctdb ctdb nmb smbcrm(live)configure# clone cl-ctdb g-ctdb meta interleave="true"crm(live)configure# commit
El archivo binario /usr/lib64/ctdb/ctdb_mutex_ceph_rados_helper de la opción deconfiguración ctdb_recovery_lock tiene los parámetros CLUSTER_NAME CEPHX_USERCEPH_POOL y CEPHX_USER , en este orden.
7. Añada una dirección IP agrupada en clúster:
crm(live)configure# primitive ip ocf:heartbeat:IPaddr2 params ip=192.168.2.1 \ unique_clone_address="true" \ op monitor interval="60" \ meta resource-stickiness="0"crm(live)configure# clone cl-ip ip \ meta interleave="true" clone-node-max="2" globally-unique="true"crm(live)configure# colocation col-with-ctdb 0: cl-ip cl-ctdbcrm(live)configure# order o-with-ctdb 0: cl-ip cl-ctdbcrm(live)configure# commit
Si unique_clone_address se dene como true (verdadero), el agente de recursoIPaddr2 añade un ID de clonación a la dirección especificada, lo que da como resultadoque haya tres direcciones IP distintas. Normalmente, no son necesarias, pero ayudan ala hora de equilibrar la carga. Para obtener más información sobre este tema, consultehttps://www.suse.com/documentation/sle-ha-12/book_sleha/data/cha_ha_lb.html .
8. Compruebe el resultado:
root@earth # crm statusClone Set: base-clone [dlm] Started: [ factory-1 ] Stopped: [ factory-0 ] Clone Set: cl-ctdb [g-ctdb] Started: [ factory-1 ] Started: [ factory-0 ] Clone Set: cl-ip [ip] (unique) ip:0 (ocf:heartbeat:IPaddr2): Started factory-0 ip:1 (ocf:heartbeat:IPaddr2): Started factory-1
132 Configuración de alta disponibilidad SES 5
9. Realice una prueba desde un equipo cliente. En un cliente Linux, ejecute el comandosiguiente para comprobar si puede copiar archivos desde el sistema y en el sistema:
root # smbclient //192.168.2.1/myshare
133 Configuración de alta disponibilidad SES 5
A Actualizaciones de la documentación
En este capítulo se describen los cambios del contenido de este documento desde la publicacióninicial de SUSE Enterprise Storage 4. Encontrará los cambios relacionados con la distribucióndel clúster que se aplican a versiones anteriores en https://www.suse.com/documentation/ses-4/
book_storage_admin/data/ap_adm_docupdate.html .
El documento se actualizó en las fechas siguientes:
Sección A.1, “Octubre de 2018 (lanzamiento de SUSE Enterprise Storage 5.5)”
Sección A.2, “Noviembre de 2017 (actualización de mantenimiento)”
Sección A.3, “Octubre de 2017 (lanzamiento de SUSE Enterprise Storage 5)”
A.1 Octubre de 2018 (lanzamiento de SUSEEnterprise Storage 5.5)
Actualizaciones generales
Se ha añadido el Capítulo 3, Configuración de alta disponibilidad del nodo de administración
de Ceph (Fate n.º 325622).
OSD cifrados durante la distribución y actualización en la Sección 4.5.1.5, “Distribución
de OSD cifrados” y la Sección 5.3, “Cifrado de OSD durante la actualización” (Fate n.º321665).
Solución de errores
Los repositorios no de datos de Object Gateway deben replicarseen la Sección 9.1.1.2, “Creación de repositorios (opcional)” (https://bugzilla.su-
se.com/show_bug.cgi?id=1095743 ).
Debe ser posible resolver el nombre de dominio completo de todos los nodos enla red IP pública. Consulte la Sección 4.3, “Distribución del clúster” (https://bugzilla.su-
se.com/show_bug.cgi?id=1067113 ).
Se ha añadido una sugerencia sobre cómo compartir varias funciones en el Capítulo 4,
Distribución con DeepSea/Salt (https://bugzilla.suse.com/show_bug.cgi?id=1093824 ).
134 Octubre de 2018 (lanzamiento de SUSE Enterprise Storage 5.5) SES 5
Se ha añadido la Sección 2.4, “Nodos del servidor de metadatos” (https://bugzilla.su-
se.com/show_bug.cgi?id=1047230 ).
Edición manual de policy.cfg para openATTIC (https://bugzilla.su-
se.com/show_bug.cgi?id=1073331 ).
Se recomienda /var/lib/ceph en SSD en la Sección 2.2, “Nodos de monitor” (https://bugzi-
lla.suse.com/show_bug.cgi?id=1056322 ).
Se han añadido la Sección 1.4, “BlueStore” y la Sección 2.1.3, “Tamaño recomendado
para el dispositivo WAL y DB de BlueStore” (https://bugzilla.suse.com/show_bug.cgi?
id=1072502 ).
Se ha aplicado la distribución de OSD cifrados en la Sección 4.5.1.5, “Distribución de
OSD cifrados” (https://bugzilla.suse.com/show_bug.cgi?id=1093003 ).
Se ha aumentado el número de bytes para borrar a 4 millones en el Paso 13 (https://
bugzilla.suse.com/show_bug.cgi?id=1093331 ).
El cortafuegos interrumpe las fases de DeepSea, en la Sección 4.3, “Distribución del
clúster” (https://bugzilla.suse.com/show_bug.cgi?id=1090683 ).
Se ha añadido la lista de repositorios en la Sección 4.3, “Distribución del clúster” (https://
bugzilla.suse.com/show_bug.cgi?id=1088170 ).
Se han añadido instrucciones para añadir manualmente repositorios mediantezypper en la Sección 5.4, “Actualización desde SUSE Enterprise Storage 4 (distribución
de DeepSea) a la versión 5”, la Sección 5.5, “Actualización desde SUSE Enterprise Storage 4
(distribución de ceph-deploy) a la versión 5” y la Sección 5.6, “Actualización desde
SUSE Enterprise Storage 4 (distribución de Crowbar) a la versión 5” (https://bugzilla.su-
se.com/show_bug.cgi?id=1073308 ).
Se ha añadido una lista de repositorios de actualización y una explicación brevede la opción upgrade_init de DeepSea en la Sección 5.4, “Actualización desde
SUSE Enterprise Storage 4 (distribución de DeepSea) a la versión 5” (https://bugzilla.su-
se.com/show_bug.cgi?id=1073372 ).
Se ha añadido la Sección 7.1.5, “Inhabilitación de actualizaciones y reinicios durante la
fase 0” (https://bugzilla.suse.com/show_bug.cgi?id=1081524 ).
Se han corregido los guiones en el Procedimiento 5.2, “Pasos que se deben aplicar en el
nodo master de Salt” (https://bugzilla.suse.com/show_bug.cgi?id=1084307 ).
135 Octubre de 2018 (lanzamiento de SUSE Enterprise Storage 5.5) SES 5
Se ha añadido la Sección 2.12, “SUSE Enterprise Storage y otros productos SUSE” (https://
bugzilla.suse.com/show_bug.cgi?id=1089717 ).
Se ha añadido una nota en las secciones de configuración de ObjectGateway en el Libro “Guía de administración”, Capítulo 1 “Administración de un
clúster de Salt”, Sección 1.11 “Archivo ceph.conf personalizado” (https://bugzilla.su-
se.com/show_bug.cgi?id=1089300 ).
Se han añadido fragmentos sobre WAL/DB en la Sección 2.1.2, “Tamaño mínimo de disco”
(https://bugzilla.suse.com/show_bug.cgi?id=1057797 ).
Las direcciones públicas de MON se calculan de forma dinámica (https://bugzilla.su-
se.com/show_bug.cgi?id=1089151 ).
Se ha corregido la ubicación de los anillos de claves en la Sección 5.5, “Actualización
desde SUSE Enterprise Storage 4 (distribución de ceph-deploy) a la versión 5” (https://
bugzilla.suse.com/show_bug.cgi?id=1073368 ).
Se proporcionan varios fragmentos sobre el ayudante en la Sección 4.5.1.2, “Asignación
de funciones” (https://bugzilla.suse.com/show_bug.cgi?id=1061629 ).
Se ha importado el ceph.conf personalizado en el Procedimiento 5.2, “Pasos que
se deben aplicar en el nodo master de Salt” (https://bugzilla.suse.com/show_bug.cgi?
id=1085443 ).
Se ha actualizado el valor de RAM recomendado para la distribución de BlueStoreen la Sección 2.1.1, “Requisitos mínimos” (https://bugzilla.suse.com/show_bug.cgi?
id=1076385) ).
Se han añadido pasos manuales para actualizar las instancias de iSCSI Gatewaydespués de importar el comando en la Sección 5.5, “Actualización desde SUSE Enterprise
Storage 4 (distribución de ceph-deploy) a la versión 5” y la Sección 5.6, “Actualización
desde SUSE Enterprise Storage 4 (distribución de Crowbar) a la versión 5” (https://bugzilla.su-
se.com/show_bug.cgi?id=1073327) ).
Se ha actualizado la distribución de iSCSI Gateway según el método de DeepSeaen la Sección 10.4, “Instalación y configuración” (https://bugzilla.suse.com/show_bug.cgi?
id=1073327 ).
136 Octubre de 2018 (lanzamiento de SUSE Enterprise Storage 5.5) SES 5
No se admiten las cuotas de CephFS. Consulte la Sección 11.1, “Escenarios admitidos de
CephFS y directrices” (https://bugzilla.suse.com/show_bug.cgi?id=1077269 ).
Se incluyen particiones con números superiores a 9 en el paso de puesta a cero,consulte el Paso 13 (https://bugzilla.suse.com/show_bug.cgi?id=1050230 ).
A.2 Noviembre de 2017 (actualización demantenimiento)
Actualizaciones generales
Se han añadido la Sección 11.3.2, “Tamaño del clúster del servidor de metadatos” y laSección 11.3.3, “Clúster de servidor de metadatos y actualizaciones”.
Solución de errores
Se ha mejorado la estrategia de borrado de disco en el Paso 13 de la Sección 4.3,
“Distribución del clúster” (https://bugzilla.suse.com/show_bug.cgi?id=1073897 ).
Se ha añadido una sugerencia para desactivar las medidas de seguridad en laSección 5.4.1, “Migración de OSD a BlueStore” (https://bugzilla.suse.com/show_bug.cgi?
id=1073720 ).
Se hace referencia a la Sección 4.2.2.1, “Coincidencia del nombre del minion” en elProcedimiento 4.1, “Ejecución de fases de distribución” y en el Libro “Guía de adminis-
tración”, Capítulo 1 “Administración de un clúster de Salt”, Sección 1.1 “Adición de nuevos
nodos de clúster” para unicar el origen de la información (https://bugzilla.su-
se.com/show_bug.cgi?id=1073374 ).
En la Sección 5.2, “Procedimiento de actualización general” solo se actualiza el master yel minion de Salt y no todos los paquetes. Por lo tanto, se ha sustituido salt targetstate.apply ceph.updates por salt target state.apply ceph.updates.salt(https://bugzilla.suse.com/show_bug.cgi?id=1073373 ).
Se ha añadido la Sección 5.6, “Actualización desde SUSE Enterprise Storage 4 (distribución de
Crowbar) a la versión 5” (https://bugzilla.suse.com/show_bug.cgi?id=1073317 y https://
bugzilla.suse.com/show_bug.cgi?id=1073701 ).
137 Noviembre de 2017 (actualización de mantenimiento) SES 5
Se ha sustituido "*" por target y se ha ampliado la introducción dedestino en la Sección 4.2.2, “Asignación de destino de los minions” (https://bugzilla.su-
se.com/show_bug.cgi?id=1068956 ).
Se ha añadido la verificación de huellas digitales de minions de Salt en la Sección 4.3,
“Distribución del clúster” (https://bugzilla.suse.com/show_bug.cgi?id=1064045 ).
Se ha eliminado el consejo para copiar el archivo refactor.conf de ejemploen el Libro “Guía de administración”, Capítulo 1 “Administración de un clúster
de Salt”, Sección 1.8 “Instalación automatizada mediante Salt” (https://bugzilla.su-
se.com/show_bug.cgi?id=1065926 ).
Se ha corregido la vía al archivo YAML de configuración de red en el Procedi-
miento 4.1, “Ejecución de fases de distribución” (https://bugzilla.suse.com/show_bug.cgi?
id=1067730 ).
Se verica el diseño de clúster en el Procedimiento 5.2, “Pasos que se deben aplicar en el
nodo master de Salt” (https://bugzilla.suse.com/show_bug.cgi?id=1067189 ).
Se ha añadido ceph osd set sortbitwise a la Sección 5.4, “Actualización desde SUSE
Enterprise Storage 4 (distribución de DeepSea) a la versión 5” y el Procedimiento 5.2, “Pasos
que se deben aplicar en el nodo master de Salt” (https://bugzilla.suse.com/show_bug.cgi?
id=1067146 ).
Se ha eliminado osd crush location , ceph.conf se personaliza de formadistinta en Importante: requisitos de software (https://bugzilla.suse.com/show_bug.cgi?
id=1067381 ).
Se ha corregido "role-admin", en lugar de "role-master", en la Sección 4.5.1.2, “Asignación
de funciones” (https://bugzilla.suse.com/show_bug.cgi?id=1064056 ).
Se ha corregido la vía a cluster.yml en el Procedimiento 4.1, “Ejecución de fases de
distribución” (https://bugzilla.suse.com/show_bug.cgi?id=1066711 ).
Se ha añadido la Sección 12.3.4, “Alta disponibilidad de NFS Ganesha y DeepSea” (https://
bugzilla.suse.com/show_bug.cgi?id=1058313 ).
Se ha vuelto a añadir la Sección 2.7.2, “Nodos de monitor en subredes diferentes” (https://
bugzilla.suse.com/show_bug.cgi?id=1050115 ).
El archivo deepsea_minions.sls solo debe contener una entrada deepsea_mi-nions . Consulte el Procedimiento 4.1, “Ejecución de fases de distribución” (https://bugzi-
lla.suse.com/show_bug.cgi?id=1065403 ).
138 Noviembre de 2017 (actualización de mantenimiento) SES 5
Se ha cambiado el orden de los pasos en el primer procedimiento de la Sección 4.3,
“Distribución del clúster” (https://bugzilla.suse.com/show_bug.cgi?id=1064770 ).
Se ha aclarado la Sección 5.4.1, “Migración de OSD a BlueStore” (https://bugzilla.su-
se.com/show_bug.cgi?id=1063250 ).
A.3 Octubre de 2017 (lanzamiento de SUSEEnterprise Storage 5)
Actualizaciones generales
Se ha añadido la Sección 5.7, “Actualización desde SUSE Enterprise Storage 3 a la versión 5”
(Fate n.º 323072).
Se ha eliminado la herramienta de instalación Crowbar obsoleta y se ha sustituidopor DeepSea.
Se ha eliminado la herramienta ceph-deploy obsoleta y se ha sustituido porDeepSea.
Se ha actualizado el Capítulo 2, Requisitos y recomendaciones de hardware (https://bugzi-
lla.suse.com/show_bug.cgi?id=1029544 y https://bugzilla.suse.com/show_bug.cgi?
id=1042283 ).
Se ha actualizado el Capítulo 12, Instalación de NFS Ganesha (https://bugzi-
lla.suse.com/show_bug.cgi?id=1036495 , https://bugzilla.suse.com/show_bug.cgi?
id=1031444 , Fate n.º 322464).
Ha cambiado el esquema de denominación de perles de DeepSea. Consultela Sección 4.5.1.4, “Asignación de perfil” (https://bugzilla.suse.com/show_bug.cgi?
id=1046108 ).
CephFS se puede utilizar en repositorios codificados de borrado, consulte laSección 11.3.1, “Creación de CephFS” (Fate n.º 321617).
139 Octubre de 2017 (lanzamiento de SUSE Enterprise Storage 5) SES 5
Solución de errores
Se ha añadido la Sección 10.5, “Exportación de imágenes del dispositivo de bloques RADOS
mediante tcmu-runner” (https://bugzilla.suse.com/show_bug.cgi?id=1064467 ).
Se ha mejorado el procedimiento de actualización para incluir la función openATTICen la Sección 5.4, “Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a
la versión 5” (https://bugzilla.suse.com/show_bug.cgi?id=1064621 ).
Se ha añadido una referencia al Procedimiento 4.1, “Ejecución de fases de distribución” enel Paso 4 (https://bugzilla.suse.com/show_bug.cgi?id=1064276 ).
Se ha modicado el procedimiento de actualización en el Procedimiento 5.2, “Pasos
que se deben aplicar en el nodo master de Salt” (https://bugzilla.suse.com/show_bug.cgi?
id=1061608 y https://bugzilla.suse.com/show_bug.cgi?id=1048959 ).
Se ha añadido rgw.conf en el Libro “Guía de administración”, Capítulo 1 “Administración
de un clúster de Salt”, Sección 1.11 “Archivo ceph.conf personalizado” (https://bugzilla.su-
se.com/show_bug.cgi?id=1062109 ).
Se ha movido la instalación de DeepSea al nal de la Sección 4.3, “Distribución del
clúster” (https://bugzilla.suse.com/show_bug.cgi?id=1056292 ).
Se ha añadido la Sección 4.5.1.5, “Distribución de OSD cifrados” (https://bugzilla.su-
se.com/show_bug.cgi?id=1061751 ).
Se ha actualizado y simplificado el procedimiento de actualización en la Sección 5.4,
“Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la versión 5”
(https://bugzilla.suse.com/show_bug.cgi?id=1059362 ).
Se debe comprobar la versión de DeepSea antes de la actualización en Importante:
requisitos de software (https://bugzilla.suse.com/show_bug.cgi?id=1059331 ).
Se añade un prejo a los archivos .sls personalizados con custom- en laSección 7.1, “Uso de archivos de configuración personalizados” (https://bugzilla.su-
se.com/show_bug.cgi?id=1048568 ).
Se ha añadido una nota sobre las discrepancias de las capacidades de clave en laSección 5.4, “Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la
versión 5” (https://bugzilla.suse.com/show_bug.cgi?id=1054186 ).
Se han combinado elementos de lista redundantes en la Sección 4.3, “Distribución del
clúster” (https://bugzilla.suse.com/show_bug.cgi?id=1055140 ).
140 Octubre de 2017 (lanzamiento de SUSE Enterprise Storage 5) SES 5
Se ha añadido una nota sobre el tiempo prolongado que puede tardar la actualizacióndel clúster en la Sección 5.4, “Actualización desde SUSE Enterprise Storage 4 (distribución de
DeepSea) a la versión 5” (https://bugzilla.suse.com/show_bug.cgi?id=1054079 ).
Es obligatoria la asignación de destinos de los minions de Salt con deepsea_mi-nions: (https://bugzilla.suse.com/show_bug.cgi?id=1054229 ).
Se ha insertado la fase 1 después de la importación en el Procedimiento 5.2, “Pasos
que se deben aplicar en el nodo master de Salt” (https://bugzilla.suse.com/show_bug.cgi?
id=1054155 ).
Se ha añadido el Libro “Guía de administración”, Capítulo 1 “Administración de un
clúster de Salt”, Sección 1.11 “Archivo ceph.conf personalizado” (https://bugzilla.su-
se.com/show_bug.cgi?id=1052806 ).
Se han añadido pasos que faltaban en la Sección 5.4, “Actualización desde SUSE
Enterprise Storage 4 (distribución de DeepSea) a la versión 5” (https://bugzilla.su-
se.com/show_bug.cgi?id=1052597 ).
Se ha corregido la sintaxis del comando radosgw-admin en la Sección 12.2, “Instalación
de ejemplo” (https://bugzilla.suse.com/show_bug.cgi?id=1052698 ).
No es obligatorio que "salt" sea el nombre del master de Salt durante la actualizaciónen el Procedimiento 5.1, “Pasos que se deben aplicar a todos los nodos del clúster (incluido
el nodo de Calamari)” (https://bugzilla.suse.com/show_bug.cgi?id=1052907 ).
Se ha mejorado la redacción del texto en la sección "Importante" de la Sección 5.4,
“Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la versión 5”
(https://bugzilla.suse.com/show_bug.cgi?id=1052147 ).
Se ha añadido una nota sobre la asignación de funciones manuales durante la impor-tación en el Procedimiento 5.2, “Pasos que se deben aplicar en el nodo master de Salt”
(https://bugzilla.suse.com/show_bug.cgi?id=1050554 ).
Se ha añadido la Sección 5.4.1, “Migración de OSD a BlueStore” (https://bugzilla.su-
se.com/show_bug.cgi?id=1052210 ).
Se explica en detalle salt-run populate.engulf_existing_cluster en el Proce-
dimiento 5.2, “Pasos que se deben aplicar en el nodo master de Salt” (https://bugzilla.su-
se.com/show_bug.cgi?id=1051258 ).
Se ha añadido la función openATTIC en la Sección 4.5.1.7, “Archivo policy.cfg de
ejemplo” (https://bugzilla.suse.com/show_bug.cgi?id=1052076 ).
141 Octubre de 2017 (lanzamiento de SUSE Enterprise Storage 5) SES 5
Se han corregido las vías profile-default en la Sección 4.5.1.7, “Archivo policy.cfg
de ejemplo” (https://bugzilla.suse.com/show_bug.cgi?id=1051760 ).
Se ha separado la sección anterior en un nuevo capítulo, Capítulo 7, Personalización de
la configuración por defecto (https://bugzilla.suse.com/show_bug.cgi?id=1050238 ).
Se hace referencia a la Sección 1.2.3, “Nodos y daemons de Ceph” en Descripción de las
fases de DeepSea para mantener actualizada la lista de servicios de Ceph (https://bugzi-
lla.suse.com/show_bug.cgi?id=1050221 ).
Se ha mejorado la descripción del master de Salt y la redacción en el Capítulo 4,
Distribución con DeepSea/Salt (https://bugzilla.suse.com/show_bug.cgi?id=1050214 ).
Se ha añadido una descripción de las funciones de nodo opcionales en la Sección 1.2.3,
“Nodos y daemons de Ceph” (https://bugzilla.suse.com/show_bug.cgi?id=1050085 ).
Se ha actualizado el procedimiento de actualización en general (https://bugzi-
lla.suse.com/show_bug.cgi?id=1048436 , https://bugzilla.suse.com/show_bug.cgi?
id=1048959 y https://bugzilla.suse.com/show_bug.cgi?id=104i7085 ).
Se ha añadido un nuevo Ceph Manager de función de DeepSea (https://bugzilla.su-
se.com/show_bug.cgi?id=1047472 ).
Se ha añadido la Sección 5.5, “Actualización desde SUSE Enterprise Storage 4 (distribución de
ceph-deploy) a la versión 5” (https://bugzilla.suse.com/show_bug.cgi?id=1048436 ).
La fase 0 se ha hecho completamente opcional en Descripción de las fases de DeepSea
(https://bugzilla.suse.com/show_bug.cgi?id=1045845 ).
Se ha actualizado la lista de repositorios por defecto en la Sección 9.1.1, “Configuración
de Object Gateway” (https://bugzilla.suse.com/show_bug.cgi?id=1034039 ).
Se ha añadido un fragmento "Importante" sobre que DeepSea distribuye ahora ObjectGateway en el Capítulo 9, Ceph Object Gateway (https://bugzilla.suse.com/show_bug.cgi?
id=1044928 ).
Se ha corregido el guion de shell en la Sección 4.3, “Distribución del clúster” (https://
bugzilla.suse.com/show_bug.cgi?id=1044684 ).
Se ha añadido "Denición del indicador require-osd-release luminous "en la Sección 5.2, “Procedimiento de actualización general” (https://bugzilla.su-
se.com/show_bug.cgi?id=1040750 ).
142 Octubre de 2017 (lanzamiento de SUSE Enterprise Storage 5) SES 5
Se ha añadido una anotación en el ejemplo policy.cfg en la Sección 4.5.1.7, “Archivo
policy.cfg de ejemplo” (https://bugzilla.suse.com/show_bug.cgi?id=1042691 ).
Se han mejorado los comandos para el borrado de la tabla de particiones del discoOSD en la Sección 4.3, “Distribución del clúster” (https://bugzilla.suse.com/show_bug.cgi?
id=1042074 ).
Se ha eliminado el consejo para instalar salt-minion en el master de Salten la Sección 4.3, “Distribución del clúster” (https://bugzilla.suse.com/show_bug.cgi?
id=1041590 ).
Se ha inhabilitado AppArmor en la Sección 4.3, “Distribución del clúster” y la Sección 5.4,
“Actualización desde SUSE Enterprise Storage 4 (distribución de DeepSea) a la versión 5”
(https://bugzilla.suse.com/show_bug.cgi?id=1039852 ).
Se ha añadido una recomendación de cortafuegos en la Sección 4.3, “Distribución del
clúster” (https://bugzilla.suse.com/show_bug.cgi?id=1039344 ).
Se han eliminado las referencias a XML-RPC de las líneas de comandos systemd deopenATTIC en la Sección 7.1, “Uso de archivos de configuración personalizados” (https://
bugzilla.suse.com/show_bug.cgi?id=1037371 ).
Se ha corregido la sintaxis de YAML en la Sección 4.3, “Distribución del clúster” (https://
bugzilla.suse.com/show_bug.cgi?id=1035498 ).
Se ha añadido una explicación de la función "ganesha" en la Sección 4.5.1.2, “Asignación
de funciones” (https://bugzilla.suse.com/show_bug.cgi?id=1037365 ).
Se ha aclarado y mejorado la redacción de la Sección 4.5.1, “El archivo policy.cfg”
(https://bugzilla.suse.com/show_bug.cgi?id=1037360 ).
Se ha añadido el procedimiento de actualización de SUSE Enterprise Storage 4 a laversión 5 en la Sección 5.4, “Actualización desde SUSE Enterprise Storage 4 (distribución de
DeepSea) a la versión 5” (https://bugzilla.suse.com/show_bug.cgi?id=1036266 ).
Se ha sustituido el término "provisión" por "preparación" en la Sección 4.3, “Distribución
del clúster” (https://bugzilla.suse.com/show_bug.cgi?id=1036400 y https://bugzilla.su-
se.com/show_bug.cgi?id=1036492 ).
Se ha añadido una advertencia sobre técnicas avanzadas en la Sección 4.5.1.6, “Filtrado
de elementos” (https://bugzilla.suse.com/show_bug.cgi?id=1036278 ).
143 Octubre de 2017 (lanzamiento de SUSE Enterprise Storage 5) SES 5
Se han sustituido asignaciones de role-admin redundantes enla Sección 4.5.1.7, “Archivo policy.cfg de ejemplo” (https://bugzilla.su-
se.com/show_bug.cgi?id=1036506 ).
Se ha mejorado Descripción de las fases de DeepSea y la Sección 4.3, “Distribución del
clúster” (https://bugzilla.suse.com/show_bug.cgi?id=1036278 ).
Se han añadido cambios en los pasos de la distribución en la Sección 7.1, “Uso
de archivos de configuración personalizados” (https://bugzilla.suse.com/show_bug.cgi?
id=1026782 ).
Se ha aclarado y mejorado el Capítulo 4, Distribución con DeepSea/Salt como se sugiereen (https://bugzilla.suse.com/show_bug.cgi?id=1020920 ).
Se recomienda habilitar los servicios openATTIC personalizados en la Sección 7.1, “Uso
de archivos de configuración personalizados” (https://bugzilla.suse.com/show_bug.cgi?
id=989349 ).
Se han movido las recomendaciones de red al Capítulo 2, Requisitos y recomendaciones
de hardware y se ha incluido la Sección 2.7.1, “Adición de una red privada a un clúster en
ejecución” (https://bugzilla.suse.com/show_bug.cgi?id=1026569 ).
144 Octubre de 2017 (lanzamiento de SUSE Enterprise Storage 5) SES 5
![Utilización - Sony · Especificaciones [305] Marcas comerciales Marcas comerciales [306] Solución de problemas Si tiene problemas Si tiene problemas Solución de problemas [307]](https://static.fdocuments.net/doc/165x107/5e5bed8d698e5569cb59f922/utilizacin-sony-especificaciones-305-marcas-comerciales-marcas-comerciales.jpg)
