Guía de administración y operaciones - SUSE Enterprise ...
459
SUSE Enterprise Storage 7 Guía de administración y operaciones
Transcript of Guía de administración y operaciones - SUSE Enterprise ...
SUSE Enterprise Storage 7
Guía de administración yoperaciones
Guía de administración y operacionesSUSE Enterprise Storage 7por Tomáš Bažant, Alexandra Settle, y Liam Proven
Fecha de publicación: 02/11/2021
SUSE LLC1800 South Novell PlaceProvo, UT 84606USA
https://documentation.suse.com
Copyright © 2020–2021 SUSE LLC y colaboradores. Reservados todos los derechos.
Salvo que se indique lo contrario, este documento está sujeto a la licencia Creative Commons Attribution-
ShareAlike 4.0 International (CC-BY-SA 4.0): https://creativecommons.org/licenses/by-sa/4.0/legalcode .
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 propietarios respectivos.
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 xviii1 Documentación disponible xviii
2 Proporcionar comentarios xix
3 Convenciones de la documentación xx
4 Ciclo de vida y asistencia del producto xxii
Definiciones de asistencia técnica de SUSE xxii • Declaración de
asistencia técnica para SUSE Enterprise Storage xxii • Tecnología en fase
preliminar xxiii
5 Colaboradores de Ceph xxiv
6 Comandos e indicadores de comandos utilizados en esta guía xxv
Comandos relacionados con Salt xxv • Comandos relacionados con
Ceph xxv • Comandos generales de Linux xxvii • Información
adicional xxvii
I CEPH DASHBOARD 1
1 Acerca de Ceph Dashboard 2
2 Interfaz de usuario Web de la consola 3
2.1 Conexión 3
2.2 Menú de utilidades 4
2.3 Menú principal 5
2.4 Panel de contenido 6
2.5 Características comunes de la interfaz del usuario Web 6
iii Guía de administración y operaciones
2.6 Widgets de consola 6
Widgets de Estado 7 • Widgets de Capacidad 8 • Widgets de
Rendimiento 8
3 Gestión de usuarios y funciones de CephDashboard 10
3.1 Listas de usuarios 10
3.2 Adición de nuevos usuarios 10
3.3 Edición de usuarios 11
3.4 Supresión de usuarios 11
3.5 Listado de las funciones de usuario 12
3.6 Adición de funciones personalizadas 12
3.7 Edición de funciones personalizadas 14
3.8 Supresión de funciones personalizadas 14
4 Visualización de elementos internos del clúster 15
4.1 Visualización de nodos de clúster 15
4.2 Acceso al inventario del clúster 15
4.3 Visualización de monitores Ceph Monitor 16
4.4 Visualización de servicios 17
4.5 Visualización de los OSD de Ceph 18
Adición de OSD 21
4.6 Visualización de la configuración del clúster 24
4.7 Visualización del mapa de CRUSH 24
4.8 Visualización de módulos del gestor 25
4.9 Visualización de registros 26
4.10 Visualización de la supervisión 26
iv Guía de administración y operaciones
5 Gestión de repositorios 27
5.1 Adición de un repositorio nuevo 28
5.2 Supresión de repositorios 28
5.3 Edición de las opciones de un repositorio 29
6 Gestión de dispositivos de bloques RADOS 30
6.1 Visualización de detalles de los RBD 31
6.2 Visualización de la configuración de RBD 32
6.3 Creación de RBD 33
6.4 Supresión de RBD 34
6.5 Creación de instantáneas de dispositivos de bloques RADOS 34
6.6 Duplicación de un RBD 35
Configuración de clústeres primarios y secundarios 36 • Habilitación
del daemon rbd-mirror 37 • Inhabilitación de la
duplicación 38 • Conectores de carga 38 • Eliminación de un
clúster conector 39 • Configuración de la réplica de repositorios en Ceph
Dashboard 39 • Verificación del funcionamiento de la réplica de la imagen
RBD 44
6.7 Gestión de pasarelas iSCSI Gateway 47
Adición de destinos iSCSI 48 • Edición de destinos iSCSI 50 • Supresión
de destinos iSCSI 50
6.8 Calidad del servicio (QoS) de un RBD 50
Configuración global de opciones 51 • Configuración de opciones en
un nuevo repositorio 52 • Configuración de opciones en un repositorio
existente 52 • Opciones de configuración 53 • Creación de opciones
de QoS de RBD con una imagen RBD nueva 53 • Edición de las opciones
de QoS de RBD en imágenes existentes 53 • Cambio de las opciones de
configuración al copiar o clonar imágenes 53
7 Gestión de NFS Ganesha 55
7.1 Creación de exportaciones NFS 55
v Guía de administración y operaciones
7.2 Supresión de exportaciones NFS 57
7.3 Edición de exportaciones NFS 57
8 Gestión de CephFS 59
8.1 Visualización del resumen de CephFS 59
9 Gestión de Object Gateway 61
9.1 Visualización de pasarelas Object Gateway 61
9.2 Gestión de usuarios de Object Gateway 62
Adición de un nuevo usuario de pasarela 63 • Supresión de usuarios de
pasarela 65 • Edición de los detalles del usuario de pasarela 65
9.3 Gestión de depósitos de Object Gateway 65
Adición de un depósito nuevo 65 • Visualización de detalles del
depósito 66 • Edición del depósito 67 • Supresión de un
depósito 68
10 Configuración manual 69
10.1 Configuración de la compatibilidad con TLS/SSL 69
Creación de certificados autofirmados 70 • Uso de certificados firmados por
una CA 70
10.2 Cambio del nombre del host y el número del puerto 71
10.3 Ajuste de nombres de usuario y contraseñas 72
10.4 Habilitación del procesador frontal de gestión de Object Gateway 73
10.5 Habilitación de la gestión de iSCSI 74
10.6 Habilitación de Single Sign-On 75
11 Gestión de usuarios y funciones en la línea decomandos 77
11.1 Gestión de la directiva de contraseñas 77
11.2 Gestión de cuentas de usuario 78
vi Guía de administración y operaciones
11.3 Funciones y permisos de usuario 79
Definición de ámbitos de seguridad 79 • Especificación de funciones de
usuario 80
11.4 Configuración de proxy: 83
Acceso a la consola con proxies inversos 83 • Inhabilitación
de redirecciones 83 • Configuración de códigos de estado de
error 83 • Configuración de ejemplo de HAProxy 84
11.5 Auditoría de peticiones de API 85
11.6 Configuración de NFS Ganesha en Ceph Dashboard 86
Configuración de varios clústeres de NFS Ganesha 86
11.7 Depuración de complementos 86
II OPERACIÓN DEL CLÚSTER 88
12 Determinación del estado del clúster 8912.1 Comprobación del estado de un clúster 89
12.2 Comprobación del estado del clúster 91
12.3 Comprobación de las estadísticas de uso de un clúster 101
12.4 Comprobación del estado de los OSD 103
12.5 Comprobación de OSD llenos 103
12.6 Comprobación del estado del monitor 104
12.7 Comprobación del estado de los grupos de colocación 105
12.8 Capacidad de almacenamiento 105
12.9 Supervisión de los OSD y los grupos de colocación 108
Supervisión de OSD 109 • Asignación de conjuntos de grupos de
colocación 110 • Emparejamiento 112 • Supervisión de los estados del
grupo de colocación 112 • Búsqueda de una ubicación de objeto 118
13 Tareas operativas 120
13.1 Modificación de la configuración del clúster 120
vii Guía de administración y operaciones
13.2 Adición de nodos 120
13.3 Eliminación de nodos 121
13.4 Gestión de OSD 123
Listado de dispositivos de disco 123 • Borrado de dispositivos
de disco 124 • Adición de OSD mediante la especificación
DriveGroups 124 • Eliminación de OSD 134 • Sustitución de OSD 135
13.5 Traslado del master de Salt a un nodo nuevo 136
13.6 Actualización de los nodos del clúster 137
Repositorios de software 138 • División en etapas del
repositorio 138 • Tiempo de inactividad de servicios de
Ceph 138 • Ejecución de la actualización 138
13.7 Actualización de Ceph 139
Inicio de la actualización 139 • Supervisión de la
actualización 139 • Cancelación de una actualización 140
13.8 Detención o reinicio del clúster 140
13.9 Eliminación de un clúster de Ceph completo 141
14 Funcionamiento de los servicios de Ceph 142
14.1 Funcionamiento de servicios individuales 142
14.2 Funcionamiento de tipos de servicios 143
14.3 Funcionamiento de servicios en un único nodo 143
Identificación de servicios y destinos 143 • Funcionamiento de todos los
servicios en un nodo 144 • Funcionamiento de un servicio individual en un
nodo 144 • Consulta del estado del servicio 145
14.4 Apagado y reinicio de todo el clúster de Ceph 145
15 Copia de seguridad y recuperación 147
15.1 Copia de seguridad de la configuración y los datos del clúster 147
Copia de seguridad de la configuración de ceph-salt 147 • Copia de
seguridad de la configuración de Ceph 147 • Copia de seguridad de
viii Guía de administración y operaciones
la configuración de Salt 147 • Copia de seguridad de configuraciones
personalizadas 148
15.2 Restauración de un nodo de Ceph 148
16 Supervisión y alertas 150
16.1 Configuración de imágenes personalizadas o locales 151
16.2 Actualización de los servicios de supervisión 152
16.3 Inhabilitación de la supervisión 153
16.4 Configuración de Grafana 154
16.5 Configuración del módulo de gestor de Prometheus 154
Configuración de la interfaz de red 155 • Configuración de
scrape_interval 155 • Configuración de caché 155 • Habilitación de la
supervisión de imágenes RBD 156
16.6 Modelo de seguridad de Prometheus 157
16.7 Receptor de alertas SNMP Alertmanager de Prometheus 157
Configuración del servicio prometheus-webhook-snmp 158 • Configuración
de Alertmanager de Prometheus para SNMP 159
III ALMACENAMIENTO DE DATOS EN UN CLÚSTER 160
17 Gestión de datos almacenados 16117.1 Dispositivos OSD 162
Clases de dispositivos 162
17.2 Depósitos 170
17.3 Conjuntos de reglas 174
Iteración del árbol de nodos 175 • firstn e indep 177
17.4 Grupos de colocación 178
Uso de los grupos de colocación 178 • Determinación del
valor de PG_NUM 180 • Definición del número de grupos
de colocación 182 • Obtención del número de grupos de
colocación 182 • Obtención de estadísticas del grupo de
ix Guía de administración y operaciones
colocación de un clúster 183 • Obtención de estadísticas de los
grupos de colocación atascados 183 • Búsqueda de un mapa
de grupos de colocación 183 • Obtención de estadísticas de
los grupos de colocación 184 • Depuración de un grupo de
colocación 184 • Priorización de la reposición y la recuperación de los grupos
de colocación 184 • Reversión de objetos perdidos 185 • Habilitación del
escalador automático de grupos de colocación 185
17.5 Manipulación del mapa de CRUSH 186
Edición de un mapa de CRUSH 187 • Adición o traslado de un
OSD 188 • Diferencia entre ceph osd reweight y ceph osd crushreweight 189 • Eliminación de un OSD 189 • Adición de un
depósito 190 • Traslado de un depósito 190 • Eliminación de un
depósito 190
17.6 Depuración de grupos de colocación 190
18 Gestión de repositorios de almacenamiento 193
18.1 Creación de un repositorio 194
18.2 Listado de repositorios 195
18.3 Cambio de nombre de un repositorio 196
18.4 Supresión de un repositorio 196
18.5 Otras operaciones 197
Asociación de repositorios a una aplicación 197 • Definición
de cuotas de repositorio 197 • Visualización de estadísticas de
repositorios 198 • Obtención de valores de repositorio 200 • Definición
de valores de repositorio 200 • Definición del número de réplicas de
objetos 204
18.6 Migración de repositorios 206
Limitaciones 206 • Migración mediante el nivel de caché 207 • Migración
de imágenes RBD 209
x Guía de administración y operaciones
18.7 Instantáneas de repositorios 210
Creación de una instantánea de un repositorio 210 • Lista de las
instantáneas de un repositorio 210 • Eliminación de una instantánea de un
repositorio 211
18.8 Compresión de datos 211
Habilitación de la compresión 211 • Opciones de compresión de
repositorios 212 • Opciones de compresión global 213
19 Repositorios codificados de borrado 215
19.1 Requisitos previos para los repositorios codificados de borrado 215
19.2 Creación de un repositorio codificado de borrado de ejemplo 216
19.3 Perfiles de código de borrado 216
Creación de un nuevo perfil codificado de borrado 219 • Eliminación de un
perfil codificado de borrado 220 • Visualización de los detalles de un perfil
codificado de borrado 221 • Listado de perfiles codificados de borrado 221
19.4 Marcado de repositorios codificados de borrado con un dispositivo debloques RADOS 221
20 Dispositivo de bloques RADOS 222
20.1 Comandos del dispositivo de bloques 222
Creación de una imagen del dispositivo de bloques en un repositorio
replicado 223 • Creación de una imagen del dispositivo de bloques
en un repositorio codificado de borrado 223 • Listado de imágenes
de dispositivos de bloques 224 • Recuperación de información de la
imagen 224 • Cambio de tamaño de la imagen de un dispositivo de
bloques 224 • Eliminación de una imagen de dispositivo de bloques 225
20.2 Montaje y desmontaje 225
Creación de una cuenta de usuario de Ceph 225 • Autenticación de
usuarios 226 • Preparación de un dispositivo de bloques RADOS
para su uso 226 • rbdmap: asignación de dispositivos RBD durante el
arranque 228 • Aumento del tamaño de dispositivos RBD 230
xi Guía de administración y operaciones
20.3 Instantáneas 230
Habilitación y configuración de cephx 231 • Conceptos básicos sobre
instantáneas 231 • Capas de instantáneas 233
20.4 Duplicados de imagen RBD 237
Configuración del repositorio 238 • Configuración de la imagen
RBD 243 • Comprobación del estado de la duplicación 247
20.5 Ajustes de caché 248
20.6 Ajuste de QoS 250
20.7 Ajustes de lectura anticipada 251
20.8 Funciones avanzadas 252
20.9 Asignación del RBD utilizando clientes de kernel antiguos 254
20.10 Habilitación de dispositivos de bloques y Kubernetes 255
Uso de dispositivos de bloques de Ceph en Kubernetes 258
IV ACCESO A LOS DATOS DEL CLÚSTER 262
21 Ceph Object Gateway 26321.1 Restricciones y limitaciones de denominación de Object Gateway 263
Limitaciones de los depósitos 263 • Limitaciones de los objetos
almacenados 263 • Limitaciones de los encabezados HTTP 264
21.2 Distribución de Object Gateway 264
21.3 Funcionamiento del servicio de Object Gateway 264
21.4 Opciones de configuración 264
21.5 Gestión del acceso a Object Gateway 265
Acceso a Object Gateway 265 • Gestión de cuentas de S3 y Swift 267
21.6 Procesadores frontales HTTP 271
21.7 Habilitación de HTTPS/SSL para pasarelas Object Gateway 271
Creación de certificados autofirmados 271 • Configuración de Object
Gateway con SSL 272
xii Guía de administración y operaciones
21.8 Módulos de sincronización 273
Configuración de módulos de sincronización 273 • Sincronización de
zonas 274 • Módulo de sincronización ElasticSearch 276 • Módulo
de sincronización en la nube 279 • Módulo de sincronización de
archivador 284
21.9 Autenticación LDAP 284
Mecanismo de autenticación 285 • Requisitos 285 • Configuración de
Object Gateway para utilizar la autenticación LDAP 286 • Uso de un filtro de
búsqueda personalizado para limitar el acceso de usuario 287 • Generación
de un testigo de acceso para la autenticación LDAP 288
21.10 Partición del índice de depósito 288
Nueva partición del índice de depósito 288 • Partición de índice de depósito
para depósitos nuevos 291
21.11 Integración con OpenStack Keystone 292
Configuración de OpenStack 293 • Configuración de Ceph Object
Gateway 293
21.12 Colocación de repositorios y clases de almacenamiento 296
Visualización de destinos de colocación 296 • Clases de
almacenamiento 297 • Configuración de grupos de zonas y
zonas 297 • Personalización de colocación 299 • Uso de clases de
almacenamiento 301
21.13 Pasarelas Object Gateway de varios sitios 301
Requisitos y supuestos 302 • Configuración de una zona
principal 303 • Configuración de zonas secundarias 309 • Mantenimiento
general de Object Gateway 315 • Realización de failover y recuperación tras
fallos 316
22 Ceph iSCSI Gateway 318
22.1 Destinos gestionados con ceph-iscsi 318
Conexión a open-iscsi 318 • Conexión de Microsoft Windows (iniciador de
Microsoft iSCSI) 322 • Conexión de VMware 329
22.2 Conclusión 335
xiii Guía de administración y operaciones
23 Sistema de archivos en clúster 336
23.1 Montaje de CephFS 336
Preparación del cliente 336 • Creación de un archivo
secreto 337 • Montaje de CephFS 337
23.2 Desmontaje de CephFS 339
23.3 Montaje de CephFS en /etc/fstab 339
23.4 Varios daemons de servidor de metadatos activos (MDS activo-activo) 339
Uso de servidor de metadatos activo-activo 339 • Aumento del tamaño del
clúster activo del servidor de metadatos 340 • Reducción del número de
rangos 341 • Fijación manual de árboles de directorio a un rango 341
23.5 Gestión del failover 342
Configuración reserva-respuesta 342
23.6 Configuración de cuotas de CephFS 343
Limitaciones de cuotas de CephFS 343 • Configuración de cuotas de
CephFS 344
23.7 Gestión de instantáneas de CephFS 345
Creación de instantáneas 345 • Supresión de instantáneas 346
24 Exportación de datos de Ceph a través de Samba 347
24.1 Exportación de CephFS mediante un recurso compartido Samba 347
Configuración y exportación de paquetes de Samba 347 • Ejemplo de
pasarela única 348 • Configuración de alta disponibilidad 351
24.2 Unión de pasarela Samba y Active Directory 357
Preparación de la instalación de Samba 357 • Verificación de
DNS 358 • Resolución de registros SRV 358 • Configuración de
Kerberos 359 • Resolución del nombre del host local 359 • Configuración
de Samba 360 • Unión al dominio de Active Directory 363 • Configuración
del conmutador de servicio de nombres 363 • Inicio de los
servicios 364 • Prueba de la conectividad de winbindd 364
xiv Guía de administración y operaciones
25 NFS Ganesha 366
25.1 Creación de un servicio NFS 367
25.2 Inicio o reinicio de NFS Ganesha 367
25.3 Listado de objetos en el repositorio de recuperación NFS 368
25.4 Creación de una exportación NFS 368
25.5 Verificación de la exportación NFS 369
25.6 Montaje de la exportación NFS 369
25.7 Varios clústeres de NFS Ganesha 369
V INTEGRACIÓN CON HERRAMIENTAS DE VIRTUALIZACIÓN 370
26 libvirt y Ceph 37126.1 Configuración de Ceph con libvirt 371
26.2 Preparación del gestor de máquina virtual 372
26.3 Creación de una máquina virtual 373
26.4 Configuración de la máquina virtual 373
26.5 Resumen 376
27 Ceph como procesador final para la instancia deQEMU KVM 377
27.1 Instalación de qemu-block-rbd 377
27.2 Uso de QEMU 377
27.3 Creación de imágenes con QEMU 378
27.4 Cambio de tamaño de las imágenes con QEMU 378
27.5 Recuperación de información de la imagen con QEMU 378
27.6 Ejecución de QEMU con RBD 379
27.7 Habilitación de descartes y TRIM 379
xv Guía de administración y operaciones
27.8 Configuración de las opciones de caché de QEMU 380
VI CONFIGURACIÓN DE UN CLÚSTER 382
28 Configuración del clúster de Ceph 38328.1 Configuración del archivo ceph.conf 383
Acceso a ceph.conf dentro de imágenes de contenedor 383
28.2 Base de datos de configuración 384
Configuración de secciones y máscaras 384 • Ajuste y lectura de opciones de
configuración 385 • Configuración de daemons en tiempo de ejecución 386
28.3 Almacén config-key 388
iSCSI Gateway 389
28.4 Ceph OSD y BlueStore 389
Configuración del tamaño automático del caché 389
28.5 Ceph Object Gateway 390
Valores generales 390 • Configuración de procesadores frontales HTTP 401
29 Módulos de Ceph Manager 404
29.1 Equilibrador 404
Modo "crush-compat" 405 • Planificación y ejecución del equilibrado de
datos 405
29.2 Habilitación del módulo de telemetría 407
30 Autenticación con cephx 409
30.1 Arquitectura de autenticación 409
30.2 Áreas clave de gestión 412
Información básica 413 • Gestión de usuarios 416 • Gestión de anillos de
claves 420 • Uso de la línea de comandos 423
xvi Guía de administración y operaciones
A Actualizaciones de mantenimiento de Ceph basadasen versiones secundarias superiores de Octopus 425
B Actualizaciones de la documentación 428
Glosario 429
xvii Guía de administración y operaciones
Acerca de esta guía
Esta guía se centra en las tareas rutinarias de las que usted, como administrador, debe ocuparsedespués de que se haya distribuido el clúster de Ceph básico (operaciones del día 2). Tambiéndescribe todas las formas admitidas para acceder a los datos almacenados en un clúster de Ceph.
SUSE Enterprise Storage 7 es una extensión para SUSE Linux Enterprise Server 15 SP2. Combinalas funciones del proyecto de almacenamiento Ceph (http://ceph.com/ ) con la ingenieríaempresarial y la asistencia de SUSE. SUSE Enterprise Storage 7 proporciona a las organizacionesde TI la capacidad de distribuir una arquitectura de almacenamiento distribuida que admitevarios casos de uso mediante plataformas de hardware básicas.
1 Documentación disponible
Nota: documentación en línea y actualizaciones más recientesLa documentación de nuestros productos está disponible en https://
documentation.suse.com , donde también encontrará las actualizaciones más recientesy podrá explorar o descargar la documentación en diferentes formatos. Las últimasactualizaciones de la documentación se pueden encontrar en la versión en inglés.
Además, la documentación del producto también estará disponible en el sistema instalado,en la vía /usr/share/doc/manual . Se incluye en un paquete de RPM denominado ses-manual_CÓDIGO_DE_IDIOMA . Instálelo si aún no está en el sistema, por ejemplo:
root # zypper install ses-manual_en
La documentación disponible para este producto es la siguiente:
Guía de distribución (https://documentation.suse.com/ses/html/ses-all/book-storage-
deployment.html)
Esta guía se centra en la distribución de un clúster de Ceph básico y en cómo distribuirservicios adicionales. También se describen los pasos necesarios para actualizar a SUSEEnterprise Storage 7 desde la versión anterior del producto.
Guía de administración y operaciones (https://documentation.suse.com/ses/html/ses-all/book-
storage-admin.html)
xviii Documentación disponible SES 7
Esta guía se centra en las tareas rutinarias de las que usted, como administrador, debeocuparse después de que se haya distribuido el clúster de Ceph básico (operaciones deldía 2). También describe todas las formas admitidas para acceder a los datos almacenadosen un clúster de Ceph.
Guía de protección de la seguridad (https://documentation.suse.com/ses/html/ses-all/book-
storage-security.html)
Esta guía se centra en cómo garantizar la seguridad del clúster.
Guía de resolución de problemas (https://documentation.suse.com/ses/html/ses-all/book-
storage-troubleshooting.html)
Esta guía describe varios problemas comunes al ejecutar SUSE Enterprise Storage 7 y otrosproblemas relacionados con los componentes relevantes, como Ceph u Object Gateway.
Guía de SUSE Enterprise Storage para Windows (https://documentation.suse.com/ses/html/ses-all/
book-storage-windows.html)
Esta guía describe la integración, instalación y conguración de entornos MicrosoftWindows y SUSE Enterprise Storage mediante el controlador de Windows.
2 Proporcionar comentarios
Agradecemos sus comentarios y contribuciones sobre esta documentación. Existen varios canalespara enviarlos:
Peticiones de servicio y asistencia técnica
Para obtener más información sobre los servicios y las opciones de asistencia técnicadisponibles para el producto, consulte http://www.suse.com/support/ .Para abrir una petición de servicio, necesita una suscripción de SUSE registrada en elCentro de servicios al cliente de SUSE. Diríjase a https://scc.suse.com/support/requests ,entre a la sesión y haga clic en Create New (Crear nueva).
Informes de errores
Puede informar sobre errores de la documentación en https://bugzilla.suse.com/ . Parainformar sobre errores, se requiere una cuenta de Bugzilla.
xix Proporcionar comentarios SES 7
Para simplicar el proceso, puede utilizar los enlaces Report Documentation Bug (Informarsobre errores de la documentación) que aparecen junto a los titulares de la versión HTMLde este documento. De esta forma, se preseleccionan el producto y la categoría correctosen Bugzilla y se añade un enlace a la sección actual. Así, podrá empezar a escribirdirectamente el informe.
Contribuciones
Para contribuir a esta documentación, utilice los enlaces Edit Source (Editar origen)situados junto a los titulares de la versión HTML de este documento. Llevan al código fuentede GitHub, donde puede abrir una petición de extracción. Para contribuir, se requiere unacuenta de GitHub.Para obtener más información sobre el entorno utilizado en esta documentación, consulteel archivo README (Léame) en https://github.com/SUSE/doc-ses .
Correo
También puede informar sobre errores y enviar comentarios sobre la documentación [email protected] . Por favor, incluya el título del documento, la versión del producto yla fecha de publicación de la documentación. También puede incluir el número de seccióny título correspondientes (o proporcionar la URL), así como una descripción concisa delproblema.
3 Convenciones de la documentaciónEn este documento se utilizan los siguientes avisos y convenciones tipográcas:
/etc/passwd : nombres de directorio y nombres de archivos.
ESPACIO RESERVADO : sustituya ESPACIO RESERVADO con el valor real.
VÍA : una variable de entorno.
ls , ‑‑help : comandos, opciones y parámetros.
usuario : el nombre del usuario o grupo.
nombre_de_paquete : el nombre de un paquete de software.
Alt , Alt – F1 : tecla o combinación de teclas que pulsar. Las teclas se muestran enmayúsculas como en un teclado.
xx Convenciones de la documentación SES 7
Archivo, Archivo Guardar como: elementos de menú, botones.
AMD/Intel Este párrafo solo es relevante para la arquitectura Intel 64/AMD64. Las echasmarcan el principio y el nal del bloque de texto. IBM Z, POWER Este párrafo solo es relevante para las arquitecturas IBM Z y POWER . Las
echas marcan el principio y el nal del bloque de texto.
Capítulo 1, “capítulo de ejemplo”: referencia cruzada a otro capítulo de esta guía.
Comandos que se deben ejecutar con privilegios de usuario root . A menudo, también esposible añadir estos comandos como prejos con el comando sudo para que un usuariosin privilegios los puedan ejecutar.
root # commandtux > sudo command
Comandos que pueden ejecutar los usuarios sin privilegios.
tux > command
Noticaciones
Aviso: aviso de advertenciaInformación vital que debe tener en cuenta antes de continuar. Advierte acerca deproblemas de seguridad, pérdida de datos potenciales, daños del hardware o peligrosfísicos.
Importante: aviso importanteInformación importante que debe tener en cuenta antes de continuar.
Nota: aviso de notaInformación adicional, por ejemplo sobre las diferencias en las versiones desoftware.
xxi Convenciones de la documentación SES 7
Sugerencia: aviso de sugerenciaInformación útil, como una directriz o un consejo práctico.
Avisos compactos
Información adicional, por ejemplo sobre las diferencias en las versiones desoftware.
Información útil, como una directriz o un consejo práctico.
4 Ciclo de vida y asistencia del productoLos distintos productos de SUSE tienen distintos ciclos de vida. Para comprobar las fechas exactasdel ciclo de vida de SUSE Enterprise Storage, consulte https://www.suse.com/lifecycle/ .
4.1 Definiciones de asistencia técnica de SUSE
Para obtener información sobre nuestra directiva de asistencia técnica y las opciones disponibles,consulte https://www.suse.com/support/policy.html y https://www.suse.com/support/programs/
long-term-service-pack-support.html .
4.2 Declaración de asistencia técnica para SUSE Enterprise Storage
Para recibir asistencia técnica, necesita disponer de una suscripción adecuada de SUSE. Paraver las ofertas de asistencia técnica especícas que tiene a su disposición, diríjase a https://
www.suse.com/support/ y seleccione su producto.
Los niveles de asistencia se denen así:
L1
Determinación de problemas; lo que signica que se ofrece asistencia técnica diseñadapara proporcionar información de compatibilidad, asistencia sobre el uso, mantenimientocontinuo, recopilación de información y resolución de problemas básicos con ladocumentación disponible.
xxii Ciclo de vida y asistencia del producto SES 7
L2
Aislamiento de problemas; lo que signica que se ofrece asistencia técnica diseñadapara analizar datos, reproducir los problemas del cliente, aislar el área del problema yproporcionar una resolución a los problemas que no se pueden resolver en el nivel 1 (L1)ni preparar para el nivel 3 (L3).
L3
Resolución de problemas; lo que signica que se ofrece asistencia técnica diseñada pararesolver los problemas mediante ingeniería y resolver los defectos que se han identicadoen la asistencia de nivel 2 (L2).
En el caso de los clientes y socios con contrato, SUSE Enterprise Storage se suministra conasistencia L3 para todos los paquetes, excepto en los siguientes casos:
Tecnología en fase preliminar.
Sonido, grácos, fuentes y material gráco.
Paquetes que precisan de un contrato de clientes adicional.
Algunos paquetes incluidos como parte del módulo de extensión de estación de trabajo soloadmiten asistencia L2.
Los paquetes con nombres que terminan en -devel (que contienen archivos deencabezado y recursos similares para desarrolladores) solo incluyen asistencia si vanacompañados de sus paquetes principales.
SUSE solo admite el uso de paquetes originales. Es decir, paquetes que no hayan sido modicadosni recompilados.
4.3 Tecnología en fase preliminar
Se considera como "tecnología en fase preliminar" cualquier paquete, pila o funciónproporcionada por SUSE para ofrecer un adelanto de las próximas innovaciones. Estos elementosse incluyen para ofrecer la oportunidad de probar nuevas tecnologías en su entorno. Leagradeceremos mucho sus comentarios. Si se dispone a probar una tecnología en fase preliminar,póngase en contacto con su representante de SUSE e infórmele de su experiencia y sus casos deuso. Sus comentarios nos resultarán útiles para desarrollar el producto.
xxiii Tecnología en fase preliminar SES 7
Las tecnologías en fase preliminar tienen las limitaciones siguientes:
Están aún en proceso de desarrollo. En consecuencia, sus funciones pueden estarincompletas, ser inestables o no ser adecuadas de alguna otra forma para su uso enproducción.
No se ofrece asistencia técnica para ellas.
Es posible que solo estén disponibles para arquitecturas de hardware especícas.
Sus detalles y funciones están sujetos a cambios. Como resultado, quizás no sea posibleactualizar estas tecnologías en las versiones posteriores o que sea necesario realizar unainstalación nueva.
Las tecnologías en fase preliminar se pueden eliminar de un producto en cualquiermomento. SUSE no se compromete a facilitar una versión con asistencia técnica de dichastecnologías en el futuro. Esto puede suceder, por ejemplo, si SUSE descubre que latecnología en fase preliminar no cumple las necesidades del cliente o del mercado, o queno cumple con los estándares empresariales.
Para ver una descripción general de las tecnologías en fase preliminar incluidas con el producto,consulte la notas de la versión en https://www.suse.com/releasenotes/x86_64/SUSE-Enterprise-
Storage/7 .
5 Colaboradores de Ceph
El proyecto Ceph y su documentación son el resultado del trabajo de cientos de colaboradoresy organizaciones. Consulte https://ceph.com/contributors/ para obtener más información.
xxiv Colaboradores de Ceph SES 7
6 Comandos e indicadores de comandos utilizadosen esta guía
Como administrador de clústeres de Ceph, va a congurar y ajustar el comportamiento delclúster ejecutando comandos especícos. Necesitará varios tipos de comandos:
6.1 Comandos relacionados con Salt
Estos comandos ayudan a distribuir los nodos de clúster de Ceph, a ejecutar comandos en variosnodos de clúster al mismo tiempo (o en todos ellos) o a ayudarle a añadir o quitar nodos declúster. Los comandos más utilizados son ceph-salt y ceph-salt config . Los comandosde Salt se deben ejecutar en el nodo master de Salt como usuario root . Estos comandos seintroducen con el siguiente símbolo del sistema:
root@master #
Por ejemplo:
root@master # ceph-salt config ls
6.2 Comandos relacionados con Ceph
Se trata de comandos de nivel inferior para congurar y ajustar todos los aspectos del clúster ysus pasarelas en la línea de comandos, por ejemplo ceph , cephadm , rbd o radosgw-admin .
Para ejecutar comandos relacionados con Ceph, debe tener acceso de lectura a una clave deCeph. Los privilegios que tiene en el entorno Ceph se denen en las capacidades de la clave.Una opción es ejecutar comandos de Ceph como usuario root (o mediante sudo ) y utilizar elanillo de claves sin restricciones por defecto "ceph.client.admin.key".
La opción más segura y recomendada es crear una clave individual más restrictiva para cadausuario administrador y colocarla en un directorio donde los usuarios puedan leerla, porejemplo:
~/.ceph/ceph.client.USERNAME.keyring
xxv Comandos e indicadores de comandos utilizados en esta guía SES 7
Sugerencia: vía a claves de CephPara utilizar un usuario administrador y un anillo de claves personalizados, debeespecicar el nombre de usuario y la vía a la clave cada vez que ejecute el comando cephmediante las opciones -n client.NOMBRE_USUARIO y ‑‑keyring VÍA/A/ANILLO/DE/CLAVES .
Para evitarlo, incluya estas opciones en la variable CEPH_ARGS en los archivos~/.bashrc de los usuarios individuales.
Aunque puede ejecutar comandos relacionados con Ceph en cualquier nodo de clúster, serecomienda hacerlo en el nodo de administración. Esta documentación utiliza al usuariocephuser para ejecutar los comandos, por lo tanto, se introducen con el siguiente símbolo delsistema:
cephuser@adm >
Por ejemplo:
cephuser@adm > ceph auth list
Sugerencia: comandos para nodos específicosSi la documentación indica que ejecute un comando en un nodo de clúster con una funciónespecíca, el símbolo del sistema se encargará. Por ejemplo:
cephuser@mon >
6.2.1 Ejecución de ceph-volume
A partir de SUSE Enterprise Storage 7, los servicios de Ceph se ejecutan en contenedores. Sinecesita ejecutar ceph-volume en un nodo de OSD, debe anteponer el comando cephadm , porejemplo:
cephuser@adm > cephadm ceph-volume simple scan
xxvi Comandos relacionados con Ceph SES 7
6.3 Comandos generales de Linux
Los comandos de Linux no relacionados con Ceph, como mount , cat o openssl se introducencon los símbolos del sistema cephuser@adm > o root # , dependiendo de los privilegios querequiera el comando relacionado.
6.4 Información adicional
Para obtener más información sobre la gestión de claves de Ceph, consulte el Sección 30.2, “Áreas
clave de gestión”.
xxvii Comandos generales de Linux SES 7
I Ceph Dashboard
1 Acerca de Ceph Dashboard 2
2 Interfaz de usuario Web de la consola 3
3 Gestión de usuarios y funciones de Ceph Dashboard 10
4 Visualización de elementos internos del clúster 15
5 Gestión de repositorios 27
6 Gestión de dispositivos de bloques RADOS 30
7 Gestión de NFS Ganesha 55
8 Gestión de CephFS 59
9 Gestión de Object Gateway 61
10 Configuración manual 69
11 Gestión de usuarios y funciones en la línea de comandos 77
1 Acerca de Ceph Dashboard
Ceph Dashboard es una aplicación de supervisión y gestión de Ceph basada en Web queadministra varios aspectos y objetos del clúster. La consola se habilita automáticamente despuésde distribuir el clúster básico en Libro “Guía de distribución”, Capítulo 5 “Distribución con cephadm”,
Sección 5.3 “Distribución del clúster de Ceph”.
En Ceph Dashboard para SUSE Enterprise Storage 7 se han añadido más funciones degestión basadas en Web para facilitar la administración de Ceph, incluida la supervisión yla administración de aplicaciones en Ceph Manager. Ya no es necesario conocer comandoscomplejos relacionados con Ceph para gestionar y supervisar el clúster de Ceph. Puede utilizarla intuitiva interfaz de Ceph Dashboard o su API REST integrada.
El módulo Ceph Dashboard muestra información y estadísticas sobre el clúster de Ceph medianteun servidor Web alojado por ceph-mgr . Consulte Libro “Guía de distribución”, Capítulo 1 “SES y
Ceph”, Sección 1.2.3 “Nodos y daemons de Ceph” para obtener más información sobre Ceph Manager.
2 SES 7
2 Interfaz de usuario Web de la consola
2.1 ConexiónPara entrar a la sesión en Ceph Dashboard, abra su dirección URL en un navegador, incluido elnúmero de puerto. Ejecute el comando siguiente para buscar la dirección:
cephuser@adm > ceph mgr services | grep dashboard"dashboard": "https://host:port/",
El comando devuelve la URL donde se encuentra Ceph Dashboard. Si tiene problemas con estecomando, consulte el Libro “Troubleshooting Guide”, Capítulo 10 “Troubleshooting the Ceph Dashboard”,
Sección 10.1 “Locating the Ceph Dashboard”.
FIGURA 2.1: PANTALLA DE ENTRADA A CEPH DASHBOARD
Entre a la sesión con las credenciales que creó durante la distribución del clúster (consulte elLibro “Guía de distribución”, Capítulo 5 “Distribución con cephadm”, Sección 5.3.2.9 “Configuración de las
credenciales de entrada de Ceph Dashboard”).
3 Conexión SES 7
Sugerencia: cuenta de usuario personalizadaSi no desea utilizar la cuenta admin por defecto para acceder a Ceph Dashboard, cree unacuenta de usuario personalizada con privilegios de administrador. Consulte el Capítulo 11,
Gestión de usuarios y funciones en la línea de comandos para obtener más información.
La interfaz de usuario de la consola se divide en varios bloques: el menú de utilidades en la partesuperior derecha de la pantalla, el menú principal en la parte izquierda y el panel de contenidoprincipal.
FIGURA 2.2: PÁGINA DE INICIO DE CEPH DASHBOARD
2.2 Menú de utilidadesLa parte superior derecha de la pantalla muestra un menú de utilidades. Incluye tareas generalesrelacionadas más con la consola que con el clúster de Ceph. Puede hacer clic en las opcionespara acceder a los siguientes temas:
Cambiar la interfaz de idioma de la consola a: alemán, checo, chino, coreano, español,francés, indonesio, inglés, italiano, japonés, polaco o portugués (brasileño).
Tareas y noticaciones
Consultar la documentación, la información acerca de la API REST o información adicionalacerca de la consola.
4 Menú de utilidades SES 7
Gestionar a los usuarios y la conguración de telemetría.
NotaPara obtener una descripción más detalladas de las funciones de usuario de la líneade comandos, consulte el Capítulo 11, Gestión de usuarios y funciones en la línea de
comandos.
Conguración de entrada a la sesión; cambiar la contraseña o cerrar la sesión.
2.3 Menú principalEl menú principal de la consola ocupa la parte izquierda de la pantalla. Abarca los siguientescontenidos:
Consola
Vuelve a la página de inicio de Ceph Dashboard.
Clúster
Muestra información detallada sobre los hosts, el inventario, los monitores Ceph Monitor,los servicios, los OSD de Ceph, la conguración del clúster, el mapa de CRUSH, los módulosde Ceph Manager, los registros y la supervisión.
Repositorios
Permite ver y gestionar repositorios de clústeres.
Bloque
Muestra información detallada y permite gestionar las imágenes de dispositivos de bloquesRADOS, la duplicación e iSCSI.
NFS
Permite ver y gestionar las distribuciones de NFS Ganesha.
NotaSi no se distribuye NFS Ganesha, aparece un aviso informativo. Consulte laSección 11.6, “Configuración de NFS Ganesha en Ceph Dashboard”.
Sistemas de archivos
5 Menú principal SES 7
Permite ver y gestionar sistemas de archivos CephFS.
Object Gateway
Permite ver y gestionar los daemons, usuarios y depósitos de Object Gateway.
NotaSi no se distribuye Object Gateway, aparece un aviso informativo. Consulte laSección 10.4, “Habilitación del procesador frontal de gestión de Object Gateway”.
2.4 Panel de contenidoEl panel de contenidos ocupa gran parte de la pantalla de la consola. La página de inicio de laconsola muestra numerosos widgets útiles para informar brevemente sobre el estado actual delclúster, su capacidad y el rendimiento.
2.5 Características comunes de la interfaz del usuarioWebEn Ceph Dashboard se suele trabajar con listas; por ejemplo, listas de repositorios, nodos deOSD o dispositivos RBD. Todas las listas se actualizan automáticamente por defecto cada cincosegundos. Los widgets comunes siguientes ayudan a gestionar o a ajustar estas listas:
Haga clic en para activar una actualización manual de la lista.
Haga clic en para mostrar u ocultar columnas individuales.
Haga clic en e introduzca o seleccione el número de las que desea mostrar en cada página.
Haga clic dentro de y ltre las las escribiendo una cadena de búsqueda.
Use para cambiar la página que se muestra si la lista se extiende por varias páginas.
2.6 Widgets de consolaCada widget de consola muestra información de estado especíca relacionada con un aspectoespecíco de un clúster de Ceph en ejecución. Algunos widgets son enlaces activos y, despuésde hacer clic en ellos, le redirigirán a una página con detalles sobre el tema que representan.
6 Panel de contenido SES 7
Sugerencia: obtener más información al pasar el ratónAlgunos widgets grácos muestran más detalles al mover el ratón sobre ellos.
2.6.1 Widgets de Estado
Los widgets de Estado ofrecen una breve descripción general sobre el estado actual del clúster.
FIGURA 2.3: WIDGETS DE ESTADO
Estado del clúster
Presenta información básica sobre el estado del clúster.
Hosts
Muestra el número total de nodos del clúster.
Monitores
Muestra el número de monitores en ejecución y su quórum.
OSDs
Muestra el número total de OSD, así como el número de OSD con los estados up e in.
Managers
Muestra el número de daemons de Ceph Manager activos y en espera.
Pasarelas de Object Gateway
Muestra el número de pasarelas Object Gateway en ejecución.
Servidores de metadatos
Muestra el número de servidores de metadatos.
Puertas de enlace iSCSI
Muestra el número de pasarelas iSCSI Gateway conguradas.
7 Widgets de Estado SES 7
2.6.2 Widgets de Capacidad
Los widgets de Capacidad muestran información breve sobre la capacidad de almacenamiento.
FIGURA 2.4: WIDGETS DE CAPACIDAD
Capacidad en bruto
Muestra la proporción de capacidad de almacenamiento en bruto utilizada y disponible.
Objetos
Muestra el número de objetos de datos almacenados en el clúster.
Estado del grupo de colocación
Muestra un gráco de los grupos de colocación según su estado.
Repositorios
Muestra el número de repositorios del clúster.
Grupos de colocación por OSD
Muestra el promedio de grupos de colocación por OSD.
2.6.3 Widgets de Rendimiento
Los widgets de Rendimiento muestran datos básicos de rendimiento de los clientes de Ceph.
FIGURA 2.5: WIDGETS DE RENDIMIENTO
Lectura/escritura de cliente
La cantidad de operaciones de lectura y escritura de los clientes por segundo.
8 Widgets de Capacidad SES 7
Rendimiento del cliente
La cantidad de datos transferidos a y desde los clientes de Ceph en bytes por segundo.
Rendimiento de recuperación
El rendimiento de los datos recuperados por segundo.
Scrubbing
Muestra el estado de depuración (consulte la Sección 17.4.9, “Depuración de un grupo de
colocación”). Puede ser inactivo , habilitado o activo .
9 Widgets de Rendimiento SES 7
3 Gestión de usuarios y funciones de CephDashboard
En el Capítulo 11, Gestión de usuarios y funciones en la línea de comandos ya se describió la gestión deusuarios de la consola que se realiza mediante los comandos de Ceph en la línea de comandos.
En esta sección se describe cómo gestionar cuentas de usuario mediante la interfaz de usuarioWeb de la consola.
3.1 Listas de usuarios
Haga clic en en el menú de utilidades y seleccione Gestión de usuarios.
La lista contiene el nombre de usuario de cada usuario, el nombre completo, el correoelectrónico, una lista de funciones asignadas, si la función está habilitada y la fecha de caducidadde la contraseña.
FIGURA 3.1: GESTIÓN DE USUARIOS
3.2 Adición de nuevos usuarios
Haga clic en Crear en la parte superior izquierda del encabezado de la tabla para añadir un nuevousuario. Introduzca su nombre de usuario, contraseña y, opcionalmente, un nombre completoy un correo electrónico.
10 Listas de usuarios SES 7
FIGURA 3.2: ADICIÓN DE UN USUARIO
Haga clic en el icono de lápiz pequeño para asignar funciones predenidas al usuario. Paraconrmar, haga clic en Crear usuario.
3.3 Edición de usuarios
Haga clic en la la de un usuario para resaltarlo. Seleccione Editar para modicar los detallesdel usuario. Para conrmar, haga clic en Editar usuario.
3.4 Supresión de usuarios
Haga clic en la la de de un usuario para resaltarlo. Seleccione el botón desplegable situadojunto a Editar y seleccione Suprimir en la lista para suprimir la cuenta de usuario. Active la casillade vericación Sí, seguro y haga clic en Suprimir usuario para conrmar.
11 Edición de usuarios SES 7
3.5 Listado de las funciones de usuario
Haga clic en en el menú de utilidades y seleccione Gestión de usuarios. A continuación, hagaclic en la pestaña Funciones.
La lista contiene el nombre y la descripción de cada función e indica si se trata de una funcióndel sistema.
FIGURA 3.3: FUNCIONES DEL USUARIO
3.6 Adición de funciones personalizadas
Haga clic en Crear en la parte superior izquierda del encabezado de la tabla para añadir unanueva función personalizada. Introduzca los datos correspondientes en Nombre y Descripción y,junto a Permisos, seleccione los permisos adecuados.
Sugerencia: limpieza de funciones personalizadasSi crea funciones de usuario personalizadas y tiene previsto eliminar el clúster de Cephcon el comando ceph-salt purge más adelante, primero debe limpiar las funcionespersonalizadas. Más detalles en la Sección 13.9, “Eliminación de un clúster de Ceph completo”
12 Listado de las funciones de usuario SES 7
FIGURA 3.4: ADICIÓN DE UNA FUNCIÓN
Sugerencia: activación múltipleAl activar la casilla de vericación que precede al nombre del tema, se activan todos lospermisos para ese tema. Al activar la casilla de vericación Todos se activan todos lospermisos para todos los temas.
Para conrmar, haga clic en Crear función.
13 Adición de funciones personalizadas SES 7
3.7 Edición de funciones personalizadasHaga clic en la la de un usuario para resaltarlo. Seleccione Editar en la parte superiorizquierda del encabezado de la tabla para editar una descripción y los permisos de la funciónpersonalizada. Para conrmar, haga clic en Editar función.
3.8 Supresión de funciones personalizadasHaga clic en la la de una función para resaltarla. Seleccione el botón desplegable situado juntoa Editar y seleccione Suprimir en la lista para suprimir la función. Active la casilla de vericaciónSí, seguro y haga clic en Suprimir función para conrmar.
14 Edición de funciones personalizadas SES 7
4 Visualización de elementos internos del clúster
El elemento de menú Clúster permite ver información detallada acerca de los hosts del clústerde Ceph, el inventario, los monitores Ceph Monitor, los servicios, los OSD, la conguración, elmapa de CRUSH, Ceph Manager, los registros y los archivos de supervisión.
4.1 Visualización de nodos de clúster
Haga clic en Clúster Hosts para ver una lista de nodos de clúster.
FIGURA 4.1: HOSTS
Haga clic en la echa desplegable situada junto al nombre de un nodo en la columna Nombrede host para ver los detalles de rendimiento del nodo.
La columna Servicios muestra todos los daemons que se ejecutan en cada nodo relacionado. Hagaclic en un nombre de daemon para ver su conguración detallada.
4.2 Acceso al inventario del clúster
Haga clic en Clúster Inventario para ver una lista de dispositivos. La lista incluye la vía deldispositivo, el tipo, la disponibilidad, el proveedor, el modelo, el tamaño y los OSD.
Haga clic para seleccionar un nombre de nodo en la columna Nombre de host. Si está seleccionado,haga clic en Identicar para identicar el dispositivo en el que se ejecuta el host. Esto indica aldispositivo que haga parpadear sus LED. Seleccione la duración de esta acción, que puede ser1, 2, 5, 10 o 15 minutos. Haga clic en Ejecutar.
15 Visualización de nodos de clúster SES 7
FIGURA 4.2: SERVICIOS
4.3 Visualización de monitores Ceph Monitor
Haga clic en Clúster Monitores para ver una lista de nodos de clúster con monitores de Ceph enejecución. El panel de contenido se divide en dos vistas: Estado y En quórum o Sin quórum.
La tabla Estado muestra estadísticas generales sobre los monitores Ceph Monitor en ejecución,incluido lo siguiente:
ID del clúster
Mapa de supervisión modicado
Época de mapa de supervisión
quórum de con
quórum de mon
con requerido
mon requerido
Los paneles Con quórum y Sin quórum incluyen el nombre de cada monitor, el número derango, la dirección IP pública y el número de sesiones abiertas.
Haga clic en un nombre de nodo en la columna Nombre para ver la conguración relacionadade Ceph Monitor.
16 Visualización de monitores Ceph Monitor SES 7
FIGURA 4.3: MONITORES CEPH MONITOR
4.4 Visualización de serviciosHaga clic en Clúster Servicios para ver los detalles de cada uno de los servicios disponibles:crash , Ceph Manager y monitores Ceph Monitor. La lista incluye el nombre de la imagen delcontenedor, el ID de la imagen del contenedor, el estado de lo que se está ejecutando, el tamañoy cuándo se actualizó por última vez.
Haga clic en la echa desplegable situada junto al nombre de un servicio en la columna Serviciopara ver los detalles del daemon. La lista de detalles incluye el nombre de host, el tipo dedaemon, el ID de daemon, el ID de contenedor, el nombre de la imagen del contenedor, el ID dela imagen del contenedor, el número de versión, el estado y cuándo se actualizó por última vez.
FIGURA 4.4: SERVICIOS
17 Visualización de servicios SES 7
4.5 Visualización de los OSD de Ceph
Haga clic en Clúster OSDs para ver una lista de nodos con daemons de OSD en ejecución. Lalista incluye el nombre de cada nodo, el ID, su estado, la clase de dispositivo, el número degrupos de colocación, el tamaño, el uso, el gráco de lecturas/escrituras en el tiempo y la tasade operaciones de lectura/escritura por segundo.
FIGURA 4.5: DAEMONS CEPH OSD
Seleccione Indicadores en el menú desplegable Conguración de todo el clúster en el encabezadode la tabla para abrir una ventana emergente. En ella verá una lista de indicadores que se aplicana todo el clúster. Puede activar o desactivar indicadores individuales. Para conrmar, haga clicen Enviar.
18 Visualización de los OSD de Ceph SES 7
FIGURA 4.6: INDICADORES DE OSD
Seleccione Prioridad de recuperación en el menú desplegable Conguración de todo el clúster en elencabezado de la tabla para abrir una ventana emergente. En ella verá una lista de prioridadesde recuperación de OSD que se aplican a todo el clúster. Puede activar el perl de prioridadpreferido y después ajustar los valores individuales. Para conrmar, haga clic en Enviar.
19 Visualización de los OSD de Ceph SES 7
FIGURA 4.7: PRIORIDAD DE RECUPERACIÓN DE OSD
Haga clic en la echa desplegable situada junto a un nombre de nodo en la columna Host para veruna tabla extendida con detalles sobre la conguración y el rendimiento del dispositivo. En lasdistintas pestañas, es posible ver listas de atributos, metadatos, el estado del dispositivo, contadoresde rendimiento y un histograma gráco de lecturas y escrituras, así como detalles de rendimiento.
FIGURA 4.8: DETALLES DE OSD
20 Visualización de los OSD de Ceph SES 7
Sugerencia: realización de tareas específicas en los OSDCuando se hace clic en el nombre de un nodo de OSD, la la de la tabla se resalta. Estosignica que ahora se puede realizar una tarea en el nodo. Puede realizar cualquiera delas siguientes acciones: Editar, Crear, Depuración, Depuración profunda, Reequilibrar peso,Marcar para excluir, Marcar para incluir, Marcar para desactivar, Marcar como perdido,Limpiar, Destruir o Suprimir.
Haga clic en la echa hacia abajo situada en la parte superior izquierda del encabezadode la tabla, junto al botón Crear y seleccione la tarea que desea realizar.
4.5.1 Adición de OSD
Para añadir nuevos OSD, siga estos pasos:
1. Verique que algunos nodos del clúster tengan dispositivos de almacenamiento cuyoestado sea disponible. A continuación, haga clic en la echa hacia abajo situada en laparte superior izquierda del encabezado de la tabla y seleccione Crear. Se abrirá la ventanaCrear OSDs.
FIGURA 4.9: CREAR OSDS
2. Para añadir dispositivos de almacenamiento primarios para los OSD, haga clic en Añadir.Antes de poder añadir dispositivos de almacenamiento, debe especicar criterios deltrado en la parte superior derecha de la tabla Dispositivos primarios; por ejemplo, Tipohdd. Para conrmar, haga clic en Añadir.
21 Adición de OSD SES 7
FIGURA 4.10: ADICIÓN DE DISPOSITIVOS PRIMARIOS
3. En la ventana Crear OSDs actualizada, tiene la opción de añadir dispositivos WAL y BDcompartidos, o bien de habilitar el cifrado de dispositivos.
FIGURA 4.11: CREAR OSDS CON DISPOSITIVOS PRIMARIOS AÑADIDOS
4. Haga clic en Vista previa para ver la vista previa de la especicación DriveGroups para losdispositivos que ha añadido anteriormente. Para conrmar, haga clic en Crear.
22 Adición de OSD SES 7
FIGURA 4.12:
5. Los dispositivos nuevos se añadirán a la lista de OSD.
FIGURA 4.13: OSD RECIÉN AÑADIDOS
NotaNo es posible visualizar el progreso del proceso de creación de los OSD. Setarda algún tiempo en crearlos. Los OSD aparecerán en la lista cuando se hayandistribuido. Si desea comprobar el estado de distribución, consulte los registroshaciendo clic en Clúster Registros.
23 Adición de OSD SES 7
4.6 Visualización de la configuración del clúster
Haga clic en Clúster Conguración para ver una lista completa de las opciones de conguracióndel clúster de Ceph. La lista contiene el nombre de la opción, una descripción breve y sus valoresactuales y por defecto. También se indica si la opción se puede editar.
FIGURA 4.14: CONFIGURACIÓN DEL CLÚSTER
Haga clic en la echa desplegable situada junto a una opción de conguración en la columnaNombre para ver una tabla extendida con información detallada sobre la opción, como su tipode valor, los valores mínimos y máximos permitidos, si se puede actualizar en el tiempo deejecución y mucho más.
Después de resaltar una opción especíca, puede editar sus valores haciendo clic en el botónEditar en la parte superior izquierda del encabezado de la tabla. Para conrmar los cambios,haga clic en Guardar.
4.7 Visualización del mapa de CRUSH
Haga clic en Clúster Mapa de CRUSH para ver un mapa de CRUSH del clúster. Para obtenerinformación general sobre los mapas de CRUSH, consulte la Sección 17.5, “Manipulación del mapa
de CRUSH”.
Haga clic en la raíz, los nodos o los OSD individuales para ver información más detallada, comoel peso de CRUSH, la profundidad del árbol de mapa, la clase de dispositivo del OSD y muchomás.
24 Visualización de la configuración del clúster SES 7
FIGURA 4.15: MAPA DE CRUSH
4.8 Visualización de módulos del gestorHaga clic en Clúster Módulos de gestor para ver una lista de los módulos de Ceph Managerdisponibles. Cada línea está formada por nombre de módulo e información sobre si estáhabilitado actualmente.
FIGURA 4.16: MÓDULOS DE GESTOR
Haga clic en la echa desplegable situada junto a un módulo en la columna Nombre para veruna tabla extendida con detalles sobre la conguración en la tabla Detalles de abajo. Para editarlos detalles, haciendo clic en Editar en la parte superior izquierda del encabezado de la tabla.Para conrmar los cambios, haga clic en Actualizar.
25 Visualización de módulos del gestor SES 7
Haga clic en la echa desplegable situada junto al botón Editar en la parte superior izquierdadel encabezado de la tabla para habilitar o inhabilitar un módulo.
4.9 Visualización de registrosHaga clic en Clúster Registros para ver una lista de las entradas de registro recientes del clúster.Cada línea está formada por una marca de tiempo, el tipo de la entrada de registro y el propiomensaje registrado.
Haga clic en la pestaña Registros de auditoría para ver las entradas de registro del subsistemade auditoría. Consulte en la Sección 11.5, “Auditoría de peticiones de API” los comandos necesariospara habilitar o inhabilitar la auditoría.
FIGURA 4.17: REGISTROS
4.10 Visualización de la supervisiónHaga clic en Clúster Supervisión para gestionar y ver los detalles de las alertas de Prometheus.
Si tiene Prometheus activo, en este panel de contenido puede ver información detallada sobreAlertas activas, Todas las alertas o Silencios.
NotaSi no ha distribuido Prometheus, aparecerá un anuncio con información y un enlace ala documentación pertinente.
26 Visualización de registros SES 7
5 Gestión de repositorios
Sugerencia: más información sobre los repositoriosPara obtener información general sobre los repositorios de Ceph, consulte el Capítulo 18,
Gestión de repositorios de almacenamiento. Para obtener información especíca sobre losrepositorios codicados de borrado, consulte el Capítulo 19, Repositorios codificados de
borrado.
Para ver una lista de todos los repositorios disponibles, haga clic en Repositorios en el menúprincipal.
La lista muestra el nombre y el tipo del repositorio, la aplicación relacionada, el estado delgrupo de colocación, el tamaño de réplica, el último cambio, el perl codicado de borrado, elconjunto de reglas de CRUSH y el uso y las estadísticas de lectura y escritura.
FIGURA 5.1: LISTA DE REPOSITORIOS
Haga clic en la echa desplegable situada junto al nombre de un repositorio en la columnaNombre para ver una tabla extendida con información detallada sobre el repositorio, como losdetalles generales, los detalles de rendimiento y la conguración.
27 SES 7
5.1 Adición de un repositorio nuevo
Para añadir un repositorio nuevo , haga clic en Crear en la parte superior izquierda de la tablade repositorios. En el formulario del repositorio, puede introducir el nombre del repositorio,el tipo, sus aplicaciones, el modo de compresión y las cuotas, incluido el número máximo debytes y el número máximo de objetos. El propio formulario calcula el número de grupos decolocación que mejor se adapta a este repositorio especíco. El cálculo se basa en la cantidadde OSD del clúster y el tipo de repositorio seleccionado con su conguración especíca. Si sedene manualmente el número de grupos de colocación, el número calculado se sustituirá. Paraconrmar, haga clic en Crear repositorio.
FIGURA 5.2: ADICIÓN DE UN REPOSITORIO NUEVO
5.2 Supresión de repositorios
Para suprimir un repositorio, selecciónelo en la la de la tabla. Haga clic en la echa desplegablesituada junto al botón Crear y haga clic en Suprimir.
28 Adición de un repositorio nuevo SES 7
5.3 Edición de las opciones de un repositorioPara editar las opciones de un repositorio, seleccione el repositorio en la la de la tabla y hagaclic en Editar en la parte superior izquierda de la tabla.
Puede cambiar el nombre del repositorio, aumentar el número de grupos de colocación, cambiarla lista de aplicaciones del repositorio y la conguración de compresión. Para conrmar, hagaclic en Editar repositorio.
29 Edición de las opciones de un repositorio SES 7
6 Gestión de dispositivos de bloques RADOS
Para mostrar todos los dispositivos de bloques RADOS (RBD) disponibles, haga clic enBloque Imágenes en el menú principal.
La lista muestra información breve sobre el dispositivo, como el nombre del dispositivo, elnombre del repositorio relacionado, el espacio de nombres, el tamaño del dispositivo, el númeroy el tamaño de los objetos del dispositivo, detalles sobre la provisión de los detalles y el padre.
FIGURA 6.1: LISTA DE IMÁGENES RBD
30 SES 7
6.1 Visualización de detalles de los RBD
Para ver información más detallada sobre un dispositivo, haga clic en su la en la tabla:
FIGURA 6.2: DETALLES DE RBD
31 Visualización de detalles de los RBD SES 7
6.2 Visualización de la configuración de RBD
Para ver la conguración detallada de un dispositivo, haga clic en su la en la tabla y, acontinuación, en la pestaña Conguración de la tabla inferior:
FIGURA 6.3: CONFIGURACIÓN DE RBD
32 Visualización de la configuración de RBD SES 7
6.3 Creación de RBDPara añadir un dispositivo nuevo, haga clic en Crear en la parte superior izquierda delencabezado de la tabla y haga lo siguiente en la pantalla Crear RBD:
FIGURA 6.4: ADICIÓN DE UN RBD NUEVO
1. Introduzca el nombre del dispositivo nuevo. Consulte el Libro “Guía de distribución”,
Capítulo 2 “Requisitos y recomendaciones de hardware”, Sección 2.11 “Limitaciones de nombres”
para conocer las limitaciones a la hora de asignar un nombre.
33 Creación de RBD SES 7
2. Seleccione el repositorio con la aplicación rbd asignada desde la que se creará el nuevodispositivo RBD.
3. Especique el tamaño del nuevo dispositivo.
4. Especique las opciones adicionales para el dispositivo. Para ajustar los parámetros deldispositivo, haga clic en Avanzado e introduzca valores para el tamaño del objeto, launidad de repartición o el recuento de repartición. Para especicar los límites de calidadde servicio (QoS), haga clic en Calidad del servicio e introdúzcalos.
5. Para conrmar, haga clic en Crear RBD.
6.4 Supresión de RBD
Para suprimir un dispositivo, selecciónelo en la la de la tabla. Haga clic en la echa desplegablesituada junto al botón Crear y haga clic en Suprimir. Para conrmar, haga clic en Suprimir RBD.
Sugerencia: traslado de los RBD a la papeleraSuprimir un RBD es una acción irreversible. Si en su lugar, usa la opción Mover ala papelera, podrá restaurar el dispositivo más adelante seleccionándolo en la pestañaPapelera de la tabla principal y haciendo clic en Restaurar en la parte superior izquierdadel encabezado de la tabla.
6.5 Creación de instantáneas de dispositivos debloques RADOS
Para crear una instantánea de dispositivo de bloques RADOS, seleccione el dispositivo en la lade la tabla y aparecerá el panel de contenido de conguración detallada. Seleccione la pestañaInstantáneas y haga clic en Crear en la parte superior izquierda del encabezado de la tabla.Escriba el nombre de la instantánea y haga clic en Crear instantánea de RBD para conrmar.
Después de seleccionar una instantánea, puede realizar acciones adicionales en el dispositivo,como cambiar su nombre, protegerlo, clonarlo, copiarlo o suprimirlo. La opción Rollback(Deshacer) restaura el estado del dispositivo de la instantánea actual.
34 Supresión de RBD SES 7
FIGURA 6.5: INSTANTÁNEAS DE RBD
6.6 Duplicación de un RBD
Los dispositivos de bloques de imágenes RADOS se pueden duplicar de forma asincrónica entredos clústeres de Ceph. Puede usar Ceph Dashboard para congurar la réplica de imágenes RBDentre dos o más clústeres. Esta capacidad está disponible en dos modos:
Basada en registro
Este modo utiliza las imágenes RBD transaccionales para garantizar la réplica protegidacontra bloqueos de un momento concreto entre los clústeres.
Basada en instantáneas
Este modo utiliza instantáneas de duplicación de imágenes RBD creadas de formaprogramada periódicamente o manualmente para replicar imágenes de RBD protegidascontra bloqueos entre clústeres.
La duplicación se congura en cada repositorio dentro de clústeres conectores y se puedecongurar en un subconjunto especíco de imágenes dentro del repositorio o para que reejeautomáticamente todas las imágenes de un repositorio si se usa únicamente la duplicacióntransaccional.
La duplicación se congura mediante el comando rbd , que se instala por defecto enSUSE Enterprise Storage 7. El daemon rbd-mirror es el responsable de la extracción deactualizaciones de imágenes del clúster conector remoto y de aplicarlos a la imagen en elclúster local. Consulte la Sección 6.6.2, “Habilitación del daemon rbd-mirror” para obtener másinformación sobre cómo habilitar el daemon rbd-mirror .
35 Duplicación de un RBD SES 7
Dependiendo de la necesidad de réplica, la duplicación del dispositivo de bloques RADOS sepuede congurar para la réplica unidireccional o bidireccional:
Réplica unidireccional
Cuando los datos solo se duplican desde un clúster primario a un clúster secundario, eldaemon rbd-mirror se ejecuta solo en el clúster secundario.
Réplica bidireccional
Cuando los datos se duplican desde imágenes primarias de un clúster a imágenes noprimarias de otro clúster (y viceversa), el daemon rbd-mirror se ejecuta en ambosclústeres.
ImportanteCada instancia del daemon rbd-mirror debe poder conectarse a los clústeres de Cephlocales y remotos simultáneamente; por ejemplo, a todos los monitores y los hosts OSD.Además, la red debe tener suciente ancho de banda entre los dos centros de datos parapoder gestionar la carga de trabajo de duplicación.
Sugerencia: información generalPara obtener información general y el enfoque de la línea de comandos para duplicar undispositivo de bloques RADOS, consulte la Sección 20.4, “Duplicados de imagen RBD”.
6.6.1 Configuración de clústeres primarios y secundarios
El clúster primario es aquel donde se crea el repositorio original con imágenes. El clústersecundario es donde se replican el repositorio o las imágenes desde el clúster primario.
Nota: nomenclatura relativaLos términos primario y secundario pueden ser relativos en el contexto de la réplica, yaque están más relacionados con los repositorios individuales que con los clústeres. Porejemplo, en la réplica bidireccional, un repositorio se puede duplicar desde el clústerprimario al secundario, mientras que otro repositorio se puede duplicar desde el clústersecundario al primario.
36 Configuración de clústeres primarios y secundarios SES 7
6.6.2 Habilitación del daemon rbd-mirror
Los siguientes procedimientos demuestran cómo llevar a cabo las tareas administrativas básicaspara congurar la duplicación mediante el comando rbd . La duplicación se congura de formaindependiente para cada repositorio dentro de los clústeres de Ceph.
Los pasos para congurar el repositorio deben realizarse en ambos clústeres conectores.Para simplicar los ejemplos, en estos procedimientos se presupone que hay dos clústeres,denominados "primario" y "secundario, a los que se puede acceder desde un único host.
El daemon rbd-mirror realiza la réplica de los datos del clúster.
1. Cambie el nombre de ceph.conf y de los archivos de anillo de claves y cópielos del hostprimario al secundario:
cephuser@secondary > cp /etc/ceph/ceph.conf /etc/ceph/primary.confcephuser@secondary > cp /etc/ceph/ceph.admin.client.keyring \ /etc/ceph/primary.client.admin.keyringcephuser@secondary > scp PRIMARY_HOST:/etc/ceph/ceph.conf \ /etc/ceph/secondary.confcephuser@secondary > scp PRIMARY_HOST:/etc/ceph/ceph.client.admin.keyring \ /etc/ceph/secondary.client.admin.keyring
2. Para habilitar la duplicación en un repositorio con rbd , especique el comando mirrorpool enable , el nombre del repositorio y el modo de duplicación:
cephuser@adm > rbd mirror pool enable POOL_NAME MODE
NotaEl modo de duplicación puede ser image o pool . Por ejemplo:
cephuser@secondary > rbd --cluster primary mirror pool enable image-pool imagecephuser@secondary > rbd --cluster secondary mirror pool enable image-pool image
3. En Ceph Dashboard diríjase a Bloque Duplicación. La tabla Daemons de la izquierdamuestra los daemons rbd-mirror que se ejecutan activamente y su estado.
37 Habilitación del daemon rbd-mirror SES 7
FIGURA 6.6: EJECUCIÓN DE DAEMONS rbd-mirror
6.6.3 Inhabilitación de la duplicación
Para inhabilitar la duplicación en un repositorio con rbd , especique el comando mirror pooldisable y el nombre del repositorio:
cephuser@adm > rbd mirror pool disable POOL_NAME
Cuando se inhabilita la duplicación en un repositorio de esta forma, la duplicación tambiénse inhabilitará en cualquier imagen (dentro del repositorio) para la que se haya habilitado laduplicación explícitamente.
6.6.4 Conectores de carga
Para que rbd-mirror descubra su clúster conector, este debe estar registrado en el repositorioy debe crearse una cuenta de usuario. Este proceso se puede automatizar con rbd mediante loscomandos mirror pool peer bootstrap create y mirror pool peer bootstrap import .
Para crear manualmente un nuevo testigo de arranque con rbd , especique el comando mirrorpool peer bootstrap create , un nombre de repositorio y un nombre de sitio opcional paradescribir el clúster local:
cephuser@adm > rbd mirror pool peer bootstrap create [--site-name local-site-name] pool-name
El resultado del comando mirror pool peer bootstrap create será un testigo que se debeproporcionar al comando mirror pool peer bootstrap import . Por ejemplo, en el clústerprimario:
cephuser@adm > rbd --cluster primary mirror pool peer bootstrap create --site-name primary
38 Inhabilitación de la duplicación SES 7
image-pool eyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkL \ W1pcnJvci1wZWVyIiwia2V5IjoiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1vbl9ob3N0I \ joiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==
Para importar manualmente el testigo de arranque creado por otro clúster con el comando rbd ,especique el comando mirror pool peer bootstrap import , el nombre del repositorio, unavía de archivo al testigo creado (o "-" para leer desde la entrada estándar), junto con un nombrede sitio opcional para describir el clúster local y una dirección de duplicación (por defecto esrx-tx para la duplicación bidireccional, pero también se puede denir como rx-only parala duplicación unidireccional):
cephuser@adm > rbd mirror pool peer bootstrap import [--site-name local-site-name] \[--direction rx-only or rx-tx] pool-name token-path
Por ejemplo, en el clúster secundario:
cephuser@adm > cat >>EOF < tokeneyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkLW \1pcnJvci1wZWVyIiwia2V5IjoiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1v \bl9ob3N0IjoiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==EOFcephuser@adm > rbd --cluster secondary mirror pool peer bootstrap import --site-name secondary image-pool token
6.6.5 Eliminación de un clúster conector
Para eliminar un clúster conector duplicado de Ceph con el comando rbd , especique elcomando mirror pool peer remove , el nombre del repositorio y el UUID del conector(disponible mediante el comando rbd mirror pool info ):
cephuser@adm > rbd mirror pool peer remove pool-name peer-uuid
6.6.6 Configuración de la réplica de repositorios en CephDashboard
El daemon rbd-mirror debe tener acceso al clúster primario para poder duplicar imágenesRBD. Antes de continuar, asegúrese de que ha seguido los pasos descritos en la Sección 6.6.4,
“Conectores de carga”.
39 Eliminación de un clúster conector SES 7
1. Tanto en el clúster primario como en el secundario, cree repositorios con un nombreidéntico y asígneles la aplicación rbd . Consulte la Sección 5.1, “Adición de un repositorio
nuevo” para obtener más información sobre cómo crear un repositorio.
40 Configuración de la réplica de repositorios en Ceph Dashboard SES 7
FIGURA 6.7: CREACIÓN DE UN REPOSITORIO CON LA APLICACIÓN RBD
41 Configuración de la réplica de repositorios en Ceph Dashboard SES 7
2. Tanto en la consola primaria como en la secundaria del clúster, diríjase aBloque Duplicación. En la tabla Repositorio de la derecha, haga clic en el nombre delrepositorio que desea replicar y, después de hacer clic en Editar modo, seleccione elmodo de réplica. En este ejemplo, trabajaremos con un modo de réplica de repositorio, loque signica que se replicarán todas las imágenes de un repositorio determinado. Paraconrmar, haga clic en Actualizar.
FIGURA 6.8: CONFIGURACIÓN DEL MODO DE RÉPLICA
Importante: error o advertencia en el clúster primarioDespués de actualizar el modo de réplica, aparecerá un indicador de error oadvertencia en la columna correspondiente de la derecha. Esto se debe a que elrepositorio no tiene asignado todavía ningún usuario par para la réplica. Ignoreeste indicador para el clúster primario, ya que solo se asignará un usuario par alclúster secundario.
42 Configuración de la réplica de repositorios en Ceph Dashboard SES 7
3. En la consola del clúster secundario, diríjase a Bloque Duplicación. Añada el par deduplicación del repositorio seleccionando Añadir par. Proporcione los detalles del clústerprimario:
FIGURA 6.9: ADICIÓN DE CREDENCIALES DEL PAR
Nombre del clúster
Se trata de una cadena arbitraria exclusiva que identica al clúster primario; porejemplo, "primario". El nombre del clúster debe ser distinto del nombre real delclúster secundario.
ID de CephX
El ID de usuario de Ceph que creó como par de duplicación. En este ejemplo es "rbd-mirror-peer".
Direcciones de monitores
Lista separada por comas de direcciones IP o nombres de host de los nodos de CephMonitor del clúster principal.
43 Configuración de la réplica de repositorios en Ceph Dashboard SES 7
Clave de CephX
La clave relacionada con el ID de usuario par. Puede recuperarla ejecutando elsiguiente comando de ejemplo en el clúster primario:
cephuser@adm > ceph auth print_key pool-mirror-peer-name
Para conrmar, haga clic en Enviar.
FIGURA 6.10: LISTA DE REPOSITORIOS REPLICADOS
6.6.7 Verificación del funcionamiento de la réplica de la imagenRBD
Cuando el daemon rbd-mirror esté en ejecución y la réplica de la imagen RBD esté conguradaen Ceph Dashboard, podrá vericar si la réplica realmente funciona:
1. En Ceph Dashboard del clúster primario, cree una imagen RBD cuyo repositorio primariosea el repositorio que ya creó con nes de réplica. Habilite las funciones Bloqueoexclusivo y En diario de la imagen. Consulte la Sección 6.3, “Creación de RBD” paraobtener más información sobre cómo crear imágenes RBD.
44 Verificación del funcionamiento de la réplica de la imagen RBD SES 7
FIGURA 6.11: NUEVA IMAGEN RBD
45 Verificación del funcionamiento de la réplica de la imagen RBD SES 7
2. Después de crear la imagen que desea replicar, abra la Ceph Dashboard del clústersecundario y diríjase a Bloque Duplicación. La tabla Repositorios de la derecha reejará elcambio en el número de imágenes de N.º remotos y sincronizará el número de imágenesde N.º locales.
FIGURA 6.12: NUEVA IMAGEN RBD SINCRONIZADA
Sugerencia: progreso de la réplicaLa tabla Imágenes de la parte inferior de la página muestra el estado de la réplica delas imágenes RBD. La pestaña Problemas incluye los problemas que se han podidoproducir, Sincronización muestra el progreso de la réplica de la imagen y Listomuestra todas las imágenes cuya réplica se ha realizado correctamente.
FIGURA 6.13: ESTADO DE RÉPLICA DE LAS IMÁGENES RBD
46 Verificación del funcionamiento de la réplica de la imagen RBD SES 7
3. En el clúster primario, escriba datos en la imagen RBD. En la Ceph Dashboard delclúster secundario, diríjase a Bloque Imágenes y supervise si el tamaño de la imagencorrespondiente aumenta a medida que se escriben los datos en el clúster primario.
6.7 Gestión de pasarelas iSCSI Gateway
Sugerencia: más información sobre las pasarelas iSCSI GatewayPara obtener información general sobre las pasarelas iSCSI Gateway, consulte elCapítulo 22, Ceph iSCSI Gateway.
Para mostrar todas las pasarelas disponibles y las imágenes asignadas, haga clic en Bloque iSCSIen el menú principal. Se abre una pestaña Resumen, que muestra las pasarelas iSCSI Gatewayconguradas actualmente y las imágenes RBD asignadas.
La tabla Puertas de enlace iSCSI muestra el estado de cada pasarela, el número de destinos iSCSI yel número de sesiones. La tabla Imágenes muestra el nombre de cada imagen asignada, el nombredel repositorio relacionado, el tipo de almacén y otros detalles estadísticos.
La pestaña Destinos muestra los destinos iSCSI congurados actualmente.
FIGURA 6.14: LISTA DE DESTINOS ISCSI
Para ver información más detallada acerca de un destino, haga clic en la echa desplegable de lala de la tabla de destino. Se abre un esquema estructurado en forma de árbol con los discos, losportales, los iniciadores y los grupos incluidos. Haga clic en un elemento para expandirlo y ver sucontenido detallado, opcionalmente con la conguración relacionada en la tabla de la derecha.
47 Gestión de pasarelas iSCSI Gateway SES 7
FIGURA 6.15: DETALLES DE DESTINO ISCSI
6.7.1 Adición de destinos iSCSI
Para añadir un destino iSCSI nuevo, haga clic en Crear en la parte superior izquierda de la tablaDestinos e introduzca la información necesaria.
48 Adición de destinos iSCSI SES 7
FIGURA 6.16: ADICIÓN DE UN DESTINO NUEVO
49 Adición de destinos iSCSI SES 7
1. Escriba la dirección de destino de la nueva pasarela.
2. Haga clic en Añadir portal y seleccione uno o varios portales iSCSI de la lista.
3. Haga clic en Añadir imagen y seleccione una o varias imágenes RBD para la pasarela.
4. Si necesita utilizar autenticación para acceder a la pasarela, marque la casilla devericación Autenticación de ACL e introduzca las credenciales. Encontrará opciones deautenticación más avanzadas después de activar Autenticación mutua y Autenticación dedescubrimiento.
5. Para conrmar, haga clic en Crear destino.
6.7.2 Edición de destinos iSCSI
Para editar un destino iSCSI existente, haga clic en su la en la tabla Destinos y haga clic enEditar en la parte superior izquierda de la tabla.
A continuación, puede modicar el destino iSCSI, añadir o suprimir portales y añadir o suprimirimágenes RBD relacionadas. También puede ajustar la información de autenticación para lapasarela.
6.7.3 Supresión de destinos iSCSI
Para suprimir un destino iSCSI, seleccione la la de la tabla, haga clic en la echa desplegablesituada junto al botón Editar y seleccione Suprimir. Active la casilla de vericación Sí, seguro yhaga clic en Suprimir destino iSCSI para conrmar.
6.8 Calidad del servicio (QoS) de un RBD
Sugerencia: información adicionalPara obtener información general y una descripción de las opciones de conguración deQoS de un RDB, consulte la Sección 20.6, “Ajuste de QoS”.
Las opciones de QoS se pueden congurar en diferentes niveles.
50 Edición de destinos iSCSI SES 7
Globalmente
En cada repositorio
En cada imagen
La conguración global se encuentra en la parte superior de la lista y se utiliza para todas lasimágenes RBD recién creadas y para aquellas imágenes que no sustituyen estos valores en lacapa del repositorio o de la imagen RBD. Un valor especicado globalmente se puede sustituiren cada repositorio o imagen. Las opciones especicadas en un repositorio se aplicarán a todaslas imágenes RBD de ese repositorio a menos que se sustituyan por una opción de conguracióndenida en una imagen. Las opciones especicadas en una imagen sustituyen a las opcionesespecicadas en un repositorio y a las especicadas globalmente.
De esta manera, es posible denir valores por defecto globalmente, adaptarlos para todas lasimágenes de RBD de un repositorio especíco y sustituir la conguración del repositorio paraimágenes RBD individuales.
6.8.1 Configuración global de opciones
Para congurar las opciones del dispositivo de bloques RADOS de forma global, seleccioneClúster Conguración en el menú principal.
1. Para mostrar todas las opciones de conguración global disponibles, junto a Nivel,seleccione Avanzado en el menú desplegable.
2. Los resultados de la tabla se pueden ltrar por rbd_qos en el campo de búsqueda. Estomuestra todas las opciones de conguración disponibles para QoS.
3. Para cambiar un valor, haga clic en la la de la tabla y seleccione Editar en la parte superiorizquierda de la tabla. El recuadro de diálogo Editar contiene seis campos diferentes paraespecicar valores. Los valores de la opción de conguración de RBD se deben indicar enel recuadro de texto mgr.
NotaA diferencia de otros recuadros de diálogo, este no permite especicar el valoren unidades según convenga. Debe establecer estos valores en bytes o IOPS,dependiendo de la opción que esté editando.
51 Configuración global de opciones SES 7
6.8.2 Configuración de opciones en un nuevo repositorio
Para crear un nuevo repositorio y congurar las opciones de conguración de RBD en él, hagaclic en Repositorios Crear. Seleccione replicado como tipo de repositorio. A continuación, deberáañadir la etiqueta de aplicación rbd al repositorio para poder congurar las opciones de QoSde RBD.
NotaNo es posible congurar las opciones de conguración de QoS de RBD en un repositoriocodicado de borrado. Para congurar las opciones de QoS de RBD para los repositorioscodicados de borrado, debe editar el repositorio de metadatos replicados de una imagenRBD. A continuación, la conguración se aplicará al repositorio codicado de borradode esa imagen.
6.8.3 Configuración de opciones en un repositorio existente
Para congurar las opciones de QoS de RBD en un repositorio existente, haga clic en Repositorios,haga clic en la la del repositorio en la tabla y seleccione Editar en la parte superior izquierdade la tabla.
Debería ver la sección Conguración de RBD en el recuadro de diálogo, seguida de una secciónCalidad del servicio.
NotaSi no ve las secciones Conguración de RBD ni Calidad del servicio, es probable que estéeditando un repositorio codicado de borrado, que no se puede usar para estableceropciones de conguración de RBD, o bien que el repositorio no esté congurado para quelas imágenes RBD lo puedan usar. En este último caso, asigne la etiqueta de aplicaciónrbd al repositorio y aparecerán las secciones de conguración correspondientes.
52 Configuración de opciones en un nuevo repositorio SES 7
6.8.4 Opciones de configuración
Haga clic en el signo + de Calidad del servicio para abrir todas las opciones de conguracióndisponibles. Aparecerá una lista de todas las opciones disponibles. Las unidades de las opcionesde conguración ya se muestran en los recuadros de texto. En el caso de las opciones de bytespor segundo (BPS), es posible utilizar accesos directos tales como "1M" o "5G". Se convertiránautomáticamente a "1 MB/s" y "5 GB/s", respectivamente.
Al hacer clic en el botón de restablecimiento situado a la derecha de cada recuadro de texto,se eliminará cualquier valor establecido en el repositorio. Esta acción no elimina los valores deconguración de las opciones conguradas globalmente o en una imagen RBD.
6.8.5 Creación de opciones de QoS de RBD con una imagen RBDnueva
Para crear una imagen RBD con las opciones de QoS de RBD establecidas en esa imagen,seleccione Bloque Imágenes y haga clic en Crear. Haga clic en Avanzado para expandir la secciónde conguración avanzada. Haga clic en Calidad del servicio para abrir todas las opciones deconguración disponibles.
6.8.6 Edición de las opciones de QoS de RBD en imágenesexistentes
Para editar las opciones de QoS de RBD en una imagen existente, seleccione Bloque Imágenes,haga clic en la la del repositorio en la tabla y, por último, haga clic en Editar. Aparecerá elrecuadro de diálogo de edición. Haga clic en Avanzado para expandir la sección de conguraciónavanzada. Haga clic en Calidad del servicio para abrir todas las opciones de conguracióndisponibles.
6.8.7 Cambio de las opciones de configuración al copiar o clonarimágenes
Si se clona o se copia una imagen RBD, los valores establecidos en esa imagen en particulartambién se copiarán por defecto. Si desea cambiarlos durante la copia o la clonación, puedehacerlo especicando los valores de conguración actualizados en el recuadro de diálogo
53 Opciones de configuración SES 7
correspondiente, del mismo modo que cuando se crear o se edita una imagen RBD. Al realizaresta acción, solo establecerá (o restablecerá) los valores de la imagen RBD que se va a copiaro clonar. Esta operación no cambia ni la conguración de la imagen RBD de origen ni laconguración global.
Si decide restablecer el valor de la opción durante la copia o clonación, no se estableceráningún valor para esa opción en esa imagen. Eso signica que cualquier valor de esa opciónespecicada para el repositorio padre se usará si el repositorio padre tiene el valor congurado.De lo contrario, se usará el valor por defecto global.
54 Cambio de las opciones de configuración al copiar o clonar imágenes SES 7
7 Gestión de NFS Ganesha
Sugerencia: más información sobre NFS GaneshaPara obtener información general sobre NFS Ganesha, consulte el Capítulo 25, NFS Ganesha.
Para mostrar todas las exportaciones NFS disponibles, haga clic en NFS en el menú principal.
La lista muestra el directorio de cada exportación, el nombre de host del daemon, el tipo deprocesador nal de almacenamiento y el tipo de acceso.
FIGURA 7.1: LISTA DE EXPORTACIONES NFS
Para ver información más detallada sobre una exportación NFS, haga clic en su la en la tabla:
FIGURA 7.2: DETALLES DE LA EXPORTACIÓN NFS
7.1 Creación de exportaciones NFSPara añadir una exportación NFS nueva, haga clic en Crear en la parte superior izquierda de latabla de exportaciones e introduzca la información necesaria.
55 Creación de exportaciones NFS SES 7
FIGURA 7.3: ADICIÓN DE UNA EXPORTACIÓN NFS NUEVA
1. Seleccione uno o más daemons NFS Ganesha que ejecutarán la exportación.
2. Seleccione un procesador nal de almacenamiento.
56 Creación de exportaciones NFS SES 7
ImportanteEn este momento, solo se admiten las exportaciones NFS respaldadas por CephFS.
3. Seleccione un ID de usuario y otras opciones relacionadas con el procesador nal dealmacenamiento.
4. Introduzca la vía de la exportación NFS. Si el directorio no existe en el servidor, se creará.
5. Especique las demás opciones relacionadas con NFS, como la versión del protocolo NFScompatible, las opciones de Pseudo, el tipo de acceso, la opción de squash o el protocolode transporte.
6. Si necesita limitar el acceso solo a determinados clientes, haga clic en Añadir clientes yañada sus direcciones IP junto con el tipo de acceso y las opciones de squash.
7. Para conrmar, haga clic en Crear exportación NFS.
7.2 Supresión de exportaciones NFS
Para suprimir una exportación, seleccione y resalte la exportación en la la de la tabla. Hagaclic en la echa desplegable situada junto al botón Editar y seleccione Suprimir. Active la casillade vericación Sí, seguro y haga clic en Suprimir exportación NFS para conrmar.
7.3 Edición de exportaciones NFS
Para editar una exportación existente, seleccione y resalte la exportación en la la de la tabla yhaga clic en Editar en la parte superior izquierda de la tabla de exportaciones.
A continuación, puede ajustar todos los detalles de la exportación NFS.
57 Supresión de exportaciones NFS SES 7
FIGURA 7.4: EDICIÓN DE UNA EXPORTACIÓN NFS
58 Edición de exportaciones NFS SES 7
8 Gestión de CephFS
Sugerencia: información adicionalPara obtener información detallada sobre CephFS, consulte el Capítulo 23, Sistema de
archivos en clúster
8.1 Visualización del resumen de CephFS
Haga clic en Sistemas de archivos en el menú principal para ver un resumen de los sistemas dearchivos congurados. La tabla principal muestra el nombre de cada sistema de archivos, lafecha de creación y si está habilitado o no.
Al hacer clic en una la de la tabla del sistema de archivos, se muestran detalles sobre su rangoy los repositorios añadidos al sistema de archivos.
FIGURA 8.1: DETALLES DE CEPHFS
En la parte inferior de la pantalla, se muestran estadísticas con el número de inodos MDSrelacionados y las peticiones del cliente, recopiladas en tiempo real.
59 Visualización del resumen de CephFS SES 7
FIGURA 8.2: DETALLES DE CEPHFS
60 Visualización del resumen de CephFS SES 7
9 Gestión de Object Gateway
ImportanteAntes de empezar, es posible que aparezca la siguiente noticación al intentar acceder alprocesador frontal de Object Gateway en Ceph Dashboard:
InformationNo RGW credentials found, please consult the documentation on how to enable RGW for the dashboard.Please consult the documentation on how to configure and enable the Object Gateway management functionality.
Esto se debe a que cephadm no ha congurado automáticamente Object Gateway paraCeph Dashboard. Si se muestra esta noticación, siga las instrucciones de la Sección 10.4,
“Habilitación del procesador frontal de gestión de Object Gateway” para habilitar manualmenteel procesador frontal de Object Gateway para Ceph Dashboard.
Sugerencia: más información sobre Object GatewayPara obtener información general sobre Object Gateway, consulte el Capítulo 21, Ceph
Object Gateway.
9.1 Visualización de pasarelas Object Gateway
Para ver una lista de pasarelas Object Gateway conguradas, haga clic en ObjectGateway Daemons. La lista incluye el ID de la pasarela, el nombre de host del nodo del clústerdonde se ejecuta el daemon de la pasarela y el número de versión de la pasarela.
Haga clic en la echa desplegable situada junto al nombre de la pasarela para ver informacióndetallada sobre ella. La pestaña Contadores de rendimiento muestra detalles sobre las operacionesde lectura y escritura y las estadísticas de caché.
61 Visualización de pasarelas Object Gateway SES 7
FIGURA 9.1: DETALLES DE LA PASARELA
9.2 Gestión de usuarios de Object Gateway
Haga clic en Object Gateway Usuarios para ver una lista de los usuarios existentes de ObjectGateway.
Haga clic en la echa desplegable situada junto al nombre de usuario para ver los detalles de lacuenta de usuario, como el estado o detalles de la cuota del usuario y del depósito.
62 Gestión de usuarios de Object Gateway SES 7
FIGURA 9.2: USUARIOS DE PASARELA
9.2.1 Adición de un nuevo usuario de pasarela
Para añadir un nuevo usuario de pasarela, haga clic en Crear en la parte superior izquierda delencabezado de la tabla. Indique sus credenciales, los detalles sobre la clave S3 y las cuotas deusuario y depósito. A continuación, haga clic en Crear usuario para conrmar.
63 Adición de un nuevo usuario de pasarela SES 7
FIGURA 9.3: ADICIÓN DE UN NUEVO USUARIO DE PASARELA
64 Adición de un nuevo usuario de pasarela SES 7
9.2.2 Supresión de usuarios de pasarela
Para suprimir un usuario de pasarela, seleccione y resalte al usuario. Haga clic en el botóndesplegable situado junto a Editar y seleccione Suprimir en la lista para suprimir la cuenta deusuario. Active la casilla de vericación Sí, seguro y haga clic en Suprimir usuario para conrmar.
9.2.3 Edición de los detalles del usuario de pasarela
Para cambiar los detalles del usuario de pasarela, seleccione y resalte al usuario. Haga clic enEditar en la parte superior izquierda del encabezado de la tabla.
Puede modicar la información básica o adicional del usuario, como sus capacidades, las claves,los subusuarios y la información de cuota. Para conrmar, haga clic en Editar usuario.
La pestaña Claves incluye una lista de solo lectura de los usuarios de la pasarela y sus clavesde acceso y secreta. Para ver las claves, haga clic en el nombre de un usuario en la lista y, acontinuación, seleccione Mostrar en la parte superior izquierda del encabezado de la tabla. Enrecuadro de diálogo Clave S3, haga clic en el icono del "ojo" para mostrar las claves, o bien hagaclic en el icono del portapapeles para copiar la clave relacionada en el portapapeles.
9.3 Gestión de depósitos de Object Gateway
Los depósitos de Object Gateway (OGW) implementan la funcionalidad de los contenedores deOpenStack Swift. Los depósitos de Object Gateway sirven como contenedores para almacenarobjetos de datos.
Haga clic en Object Gateway Depósitos para ver una lista de depósitos de Object Gateway.
9.3.1 Adición de un depósito nuevo
Para añadir un depósito nuevo de Object Gateway, haga clic en Crear en la parte superiorizquierda del encabezado de la tabla. Introduzca el nombre del depósito, seleccione elpropietario y dena el destino de colocación. Para conrmar, haga clic en Crear depósito.
65 Supresión de usuarios de pasarela SES 7
NotaEn esta fase también puede habilitar el bloqueo seleccionando Habilitado; sin embargo,se puede congurar después de la creación. Consulte la Sección 9.3.3, “Edición del depósito”
para obtener más información.
9.3.2 Visualización de detalles del depósito
Para ver información detallada sobre un depósito de Object Gateway, haga clic en la echadesplegable situada junto al nombre del depósito
FIGURA 9.4: DETALLES DEL DEPÓSITO DE PASARELA
66 Visualización de detalles del depósito SES 7
Sugerencia: cuota de depósitoDebajo de la tabla Detalles, puede encontrar detalles sobre la cuota de depósito y laconguración de bloqueo.
9.3.3 Edición del depósito
Seleccione y resalte un depósito y, a continuación, haga clic en Editar en la parte superiorizquierda del encabezado de la tabla.
Puede actualizar el propietario del depósito o habilitar el control de versiones, la autenticaciónmultifactor o el bloqueo. Para conrmar los cambios, haga clic en Editar depósito.
FIGURA 9.5: EDICIÓN DE LOS DETALLES DEL DEPÓSITO
67 Edición del depósito SES 7
9.3.4 Supresión de un depósito
Para suprimir un depósito de Object Gateway, selecciónelo y resáltelo. Haga clic en el botóndesplegable situado junto a Editar y seleccione Suprimir en la lista para suprimir el depósito.Active la casilla de vericación Sí seguro y haga clic en Suprimir depósito para conrmar.
68 Supresión de un depósito SES 7
10 Configuración manual
En esta sección se presenta información avanzada para los usuarios que preeren congurarmanualmente los valores de la consola en la línea de comandos.
10.1 Configuración de la compatibilidad con TLS/SSL
Todas las conexiones HTTP a la consola están protegidas por defecto con TLS/SSL. Unaconexión segura requiere un certicado SSL. Puede usar un certicado autormado o generarun certicado y hacer que una entidad de certicación (CA) conocida lo rme.
Sugerencia: inhabilitación de SSLA veces puede ser necesario inhabilitar SSL por algún motivo. Por ejemplo, si la consolase ejecuta mediante un proxy que no admite SSL.
Tenga cuidado al inhabilitar SSL, ya que los nombres de usuario y las contraseñas seenviarán a la consola sin cifrar.
Para inhabilitar SSL, ejecute:
cephuser@adm > ceph config set mgr mgr/dashboard/ssl false
Sugerencia: reinicio de los procesos de Ceph ManagerDebe reiniciar los procesos de Ceph Manager manualmente después de cambiar elcerticado SSL y la clave. Puede hacerlo ejecutando:
cephuser@adm > ceph mgr fail ACTIVE-MANAGER-NAME
o inhabilitando y volviendo a habilitar el módulo de consola, lo que también activa queel gestor se vuelva a reproducir a sí mismo:
cephuser@adm > ceph mgr module disable dashboardcephuser@adm > ceph mgr module enable dashboard
69 Configuración de la compatibilidad con TLS/SSL SES 7
10.1.1 Creación de certificados autofirmados
Crear un certicado autormado para establecer comunicaciones seguras es sencillo. Es unamanera rápida de conseguir poner en funcionamiento la consola.
Nota: queja de los navegadores WebLa mayoría de los navegadores Web producen una advertencia sobre los certicadosautormados y requerirán que se conrmen explícitamente antes de establecer unaconexión segura con la consola.
Para generar e instalar un certicado autormado, utilice el siguiente comando integrado:
cephuser@adm > ceph dashboard create-self-signed-cert
10.1.2 Uso de certificados firmados por una CA
Para proteger correctamente la conexión a la consola y eliminar las advertencias de losnavegadores Web sobre los certicados autormados, se recomienda usar un certicado rmadopor una CA.
Puede generar un par de claves de certicado con un comando similar al siguiente:
root # openssl req -new -nodes -x509 \ -subj "/O=IT/CN=ceph-mgr-dashboard" -days 3650 \ -keyout dashboard.key -out dashboard.crt -extensions v3_ca
El comando anterior genera los archivos dashboard.key y dashboard.crt . Después de queuna CA haya rmado el archivo dashboard.crt , habilítelo para todas las instancias de CephManager ejecutando los comandos siguientes:
cephuser@adm > ceph config-key set mgr/dashboard/crt -i dashboard.crtcephuser@adm > ceph config-key set mgr/dashboard/key -i dashboard.key
70 Creación de certificados autofirmados SES 7
Sugerencia: certificados diferentes para cada instancia delgestorSi necesita certicados diferentes para cada instancia de Ceph Manager, modique loscomandos e incluya el nombre de la instancia de la siguiente manera. Sustituya NAMEpor el nombre de la instancia de Ceph Manager (normalmente es el nombre de hostrelacionado):
cephuser@adm > ceph config-key set mgr/dashboard/NAME/crt -i dashboard.crtcephuser@adm > ceph config-key set mgr/dashboard/NAME/key -i dashboard.key
10.2 Cambio del nombre del host y el número delpuerto
Ceph Dashboard se asocia con una dirección TCP/IP y un puerto TCP especícos. Por defecto,la instancia de Ceph Manager activa actualmente donde se aloja la consola se vincula al puertoTCP 8443 (o al 8080 si SSL está inhabilitado).
NotaSi hay un cortafuegos habilitado en los hosts en los que se ejecuta Ceph Manager (y, porlo tanto, Ceph Dashboard), es posible que deba cambiar la conguración para habilitarel acceso a estos puertos. Para obtener más información sobre la conguración delcortafuegos para Ceph, consulte el Libro “Troubleshooting Guide”, Capítulo 13 “Hints and tips”,
Sección 13.7 “Firewall settings for Ceph”.
Ceph Dashboard se asocia por defecto con "::", que corresponde a todas las direcciones IPv4 eIPv6 disponibles. Es posible cambiar la dirección IP y el número de puerto de la aplicación Webpara que se apliquen a todas las instancias de Ceph Manager mediante los siguientes comandos:
cephuser@adm > ceph config set mgr mgr/dashboard/server_addr IP_ADDRESScephuser@adm > ceph config set mgr mgr/dashboard/server_port PORT_NUMBER
71 Cambio del nombre del host y el número del puerto SES 7
Sugerencia: configuración por separado de instancias de CephManagerDado que cada daemon ceph-mgr aloja su propia instancia de la consola, es posible quedeba congurarlos por separado. Cambie la dirección IP y el número de puerto de unainstancia especíca del gestor mediante los comandos siguientes (sustituya NAME por elID de la instancia de ceph-mgr ):
cephuser@adm > ceph config set mgr mgr/dashboard/NAME/server_addr IP_ADDRESScephuser@adm > ceph config set mgr mgr/dashboard/NAME/server_port PORT_NUMBER
Sugerencia: listado de puestos finales configuradosEl comando ceph mgr services muestra todos los puestos nales que están conguradosactualmente. Busque la clave dashboard para obtener la dirección URL con la queacceder a la consola.
10.3 Ajuste de nombres de usuario y contraseñas
Si no desea utilizar la cuenta de administrador por defecto, cree una cuenta de usuario diferentey asóciela con al menos una función. Proporcionamos un conjunto de funciones de sistemapredenidos que puede usar. Para obtener más información, consulte el Capítulo 11, Gestión de
usuarios y funciones en la línea de comandos.
Para crear un usuario con privilegios de administrador, utilice el comando siguiente:
cephuser@adm > ceph dashboard ac-user-create USER_NAME PASSWORD administrator
72 Ajuste de nombres de usuario y contraseñas SES 7
10.4 Habilitación del procesador frontal de gestiónde Object GatewayPara utilizar la funcionalidad de gestión de Object Gateway de la consola, debe proporcionarlas credenciales de entrada de un usuario con el indicador system habilitado:
1. Si no tiene ningún usuario con el indicador system , cree uno:
cephuser@adm > radosgw-admin user create --uid=USER_ID --display-name=DISPLAY_NAME --system
Tome nota de las claves access_key y secret_key del resultado del comando.
2. También puede obtener las credenciales de un usuario existente mediante el comandoradosgw-admin :
cephuser@adm > radosgw-admin user info --uid=USER_ID
3. Proporcione las credenciales recibidas a la consola:
cephuser@adm > ceph dashboard set-rgw-api-access-key ACCESS_KEYcephuser@adm > ceph dashboard set-rgw-api-secret-key SECRET_KEY
NotaPor defecto, el cortafuegos está habilitado en SUSE Linux Enterprise Server 15 SP2.Para obtener más información acerca de la conguración del cortafuegos, consulte Libro
“Troubleshooting Guide”, Capítulo 13 “Hints and tips”, Sección 13.7 “Firewall settings for Ceph”.
Se deben tener en cuenta varios puntos:
El nombre de host y el número de puerto de Object Gateway se determinanautomáticamente.
Si se utilizan varias zonas, el host se determinará automáticamente dentro del grupo dezonas maestras y la zona maestra. Esto es suciente para la mayoría de conguraciones,pero en algunas circunstancias es posible que sea necesario denir el nombre de host yel puerto manualmente:
cephuser@adm > ceph dashboard set-rgw-api-host HOST
73 Habilitación del procesador frontal de gestión de Object Gateway SES 7
cephuser@adm > ceph dashboard set-rgw-api-port PORT
Podría necesitar estos ajustes adicionales:
cephuser@adm > ceph dashboard set-rgw-api-scheme SCHEME # http or httpscephuser@adm > ceph dashboard set-rgw-api-admin-resource ADMIN_RESOURCEcephuser@adm > ceph dashboard set-rgw-api-user-id USER_ID
Si utiliza un certicado autormado (Sección 10.1, “Configuración de la compatibilidad con TLS/
SSL”) en la conguración de Object Gateway, inhabilite la vericación del certicado en laconsola para evitar que se rechacen conexiones debido a que haya certicados rmadospor una CA desconocida o a que no coincidan con el nombre de host:
cephuser@adm > ceph dashboard set-rgw-api-ssl-verify False
Si Object Gateway tarda demasiado en procesar las peticiones y se agota el tiempo deespera en la consola, el valor del tiempo de espera se puede ajustar (por defecto es de 45segundos):
cephuser@adm > ceph dashboard set-rest-requests-timeout SECONDS
10.5 Habilitación de la gestión de iSCSICeph Dashboard gestiona los destinos iSCSI mediante la API REST proporcionada por el serviciorbd-target-api de Ceph iSCSI Gateway. Asegúrese de que está instalado y habilitado en laspasarelas iSCSI.
NotaLa funcionalidad de gestión de iSCSI de Ceph Dashboard depende de la última versión 3del proyecto ceph-iscsi . Asegúrese de que el sistema operativo proporciona la versióncorrecta; de lo contrario, Ceph Dashboard no habilitará las funciones de gestión.
Si la API REST ceph-iscsi está congurada en modo HTTPS y utiliza un certicadoautormado, congure la consola para evitar la vericación del certicado SSL al acceder a laAPI ceph-iscsi.
Inhabilite la vericación SSL de la API:
cephuser@adm > ceph dashboard set-iscsi-api-ssl-verification false
74 Habilitación de la gestión de iSCSI SES 7
Dena las pasarelas iSCSI disponibles:
cephuser@adm > ceph dashboard iscsi-gateway-listcephuser@adm > ceph dashboard iscsi-gateway-add scheme://username:password@host[:port]cephuser@adm > ceph dashboard iscsi-gateway-rm gateway_name
10.6 Habilitación de Single Sign-OnSingle Sign-On (SSO) es un método de control de acceso que permite a los usuariosentrar a la sesión mediante un único identicador y una contraseña en varias aplicacionessimultáneamente.
Ceph Dashboard admite la autenticación externa de usuarios a través del protocolo SAML 2.0.Dado que la autorización la sigue realizando la consola, primero debe crear cuentas de usuarioy asociarlas a las funciones deseadas. Sin embargo, el proceso de autenticación lo puede realizarun proveedor de identidades (IdP) existente.
Para congurar Single Sign-On, utilice el siguiente comando:
cephuser@adm > ceph dashboard sso setup saml2 CEPH_DASHBOARD_BASE_URL \ IDP_METADATA IDP_USERNAME_ATTRIBUTE \ IDP_ENTITY_ID SP_X_509_CERT \ SP_PRIVATE_KEY
Parámetros:
CEPH_DASHBOARD_BASE_URL
La URL base desde la que se puede acceder a la Ceph Dashboard (por ejemplo, "https://consolaceph.local").
IDP_METADATA
La URL, la vía o el contenido del XML de metadatos del IdP (por ejemplo, "https://miidp/metadatos").
IDP_USERNAME_ATTRIBUTE
Opcional. El atributo que se usará para obtener el nombre de usuario de la respuesta deautenticación. El valor por defecto es "uid".
IDP_ENTITY_ID
Opcional. Se usa cuando existe más de un ID de entidad en los metadatos del IdP.
SP_X_509_CERT / SP_PRIVATE_KEY
75 Habilitación de Single Sign-On SES 7
Opcional. Vía o contenido del certicado que usará la Ceph Dashboard (el proveedor deservicios) para la rma y el cifrado.
Nota: peticiones SAMLEste patrón irá seguido del valor del emisor de las peticiones SAML:
CEPH_DASHBOARD_BASE_URL/auth/saml2/metadata
Para mostrar la conguración actual de SAML 2.0, ejecute:
cephuser@adm > ceph dashboard sso show saml2
Para inhabilitar Single Sign-On, ejecute:
cephuser@adm > ceph dashboard sso disable
Para comprobar si SSO está habilitado, ejecute:
cephuser@adm > ceph dashboard sso status
Para habilitar SSO, ejecute:
cephuser@adm > ceph dashboard sso enable saml2
76 Habilitación de Single Sign-On SES 7
11 Gestión de usuarios y funciones en la línea decomandos
En esta sección se describe cómo gestionar las cuentas de usuario utilizadas por la CephDashboard. Sirve de ayuda para crear o modicar cuentas de usuario, así como para establecerlas funciones y permisos de usuario adecuados.
11.1 Gestión de la directiva de contraseñasPor defecto, la función de directiva de contraseñas está habilitada, incluidas las siguientescomprobaciones:
¿La contraseña tiene más de N caracteres?
¿Son iguales la contraseña antigua y la nueva?
La función de directiva de contraseñas se puede activar o desactivar por completo:
cephuser@adm > ceph dashboard set-pwd-policy-enabled true|false
Las siguientes comprobaciones individuales se pueden activar o desactivar:
cephuser@adm > ceph dashboard set-pwd-policy-check-length-enabled true|falsecephuser@adm > ceph dashboard set-pwd-policy-check-oldpwd-enabled true|falsecephuser@adm > ceph dashboard set-pwd-policy-check-username-enabled true|falsecephuser@adm > ceph dashboard set-pwd-policy-check-exclusion-list-enabled true|falsecephuser@adm > ceph dashboard set-pwd-policy-check-complexity-enabled true|falsecephuser@adm > ceph dashboard set-pwd-policy-check-sequential-chars-enabled true|falsecephuser@adm > ceph dashboard set-pwd-policy-check-repetitive-chars-enabled true|false
Además, las siguientes opciones están disponibles para congurar el comportamiento de ladirectiva de contraseñas.
La longitud mínima de la contraseña (por defecto es 8):
cephuser@adm > ceph dashboard set-pwd-policy-min-length N
La complejidad mínima de la contraseña (por defecto es 10):
cephuser@adm > ceph dashboard set-pwd-policy-min-complexity N
77 Gestión de la directiva de contraseñas SES 7
La complejidad de la contraseña se calcula clasicando cada carácter de la contraseña.
Una lista de palabras separadas por comas que no se pueden utilizar en una contraseña:
cephuser@adm > ceph dashboard set-pwd-policy-exclusion-list word[,...]
11.2 Gestión de cuentas de usuarioCeph Dashboard admite la gestión de varias cuentas de usuario. Cada cuenta de usuario estáformada por un nombre de usuario, una contraseña (almacenada cifrada mediante bcrypt ), unnombre opcional y una dirección de correo electrónico opcional.
Las cuentas de usuario se almacenan en la base de datos de conguración de Ceph Monitor y secomparten de forma global entre todas las instancias de Ceph Manager.
Utilice los comandos siguientes para gestionar cuentas de usuario:
Mostrar usuarios existentes:
cephuser@adm > ceph dashboard ac-user-show [USERNAME]
Crear un usuario:
cephuser@adm > ceph dashboard ac-user-create USERNAME [PASSWORD] [ROLENAME] [NAME] [EMAIL]
Suprimir un usuario:
cephuser@adm > ceph dashboard ac-user-delete USERNAME
Cambiar la contraseña de un usuario:
cephuser@adm > ceph dashboard ac-user-set-password USERNAME PASSWORD
Modificar el nombre y el correo electrónico de un usuario:
cephuser@adm > ceph dashboard ac-user-set-info USERNAME NAME EMAIL
Inhabilitar un usuario:
cephuser@adm > ceph dashboard ac-user-disable USERNAME
Habilitar un usuario:
cephuser@adm > ceph dashboard ac-user-enable USERNAME
78 Gestión de cuentas de usuario SES 7
11.3 Funciones y permisos de usuarioEn esta sección se describen los ámbitos de seguridad que puede asignar a una función deusuario, y se explica cómo gestionar funciones de usuario y cómo asignarlas a cuentas de usuario.
11.3.1 Definición de ámbitos de seguridad
Las cuentas de usuario están asociadas a un conjunto de funciones que denen a qué partes de laconsola puede tener acceso el usuario. Las distintas partes de la consola se agrupan dentro de unámbito de seguridad. Los ámbitos de seguridad están predenidos y son estáticos. Actualmenteestán disponibles los siguientes ámbitos de seguridad:
hosts
Incluye todas las características relacionadas con la entrada del menú Hosts.
config-opt
Incluye todas las características relacionadas con las gestión de las opciones deconguración de Ceph.
pool
Incluye todas las características relacionadas con la gestión de repositorios.
osd
Incluye todas las funciones relacionadas con la gestión de Ceph OSD.
monitor
Incluye todas las características relacionadas con la gestión de Ceph Monitor.
rbd-image
Incluye todas las funciones relacionadas con la gestión de imágenes de dispositivos debloques RADOS.
rbd-mirroring
Incluye todas las funciones relacionadas con la gestión de duplicados de dispositivos debloques RADOS.
iscsi
Incluye todas las características relacionadas con la gestión de iSCSI.
rgw
79 Funciones y permisos de usuario SES 7
Incluye todas las características relacionadas con la gestión de Object Gateway.
cephfs
Incluye todas las características relacionadas con la gestión de CephFS.
manager
Incluye todas las características relacionadas con la gestión de Ceph Manager.
log
Incluye todas las características relacionadas con la gestión de los registros de Ceph.
grafana
Incluye todas las características relacionadas con el proxy de Grafana.
prometheus
Incluye todas las funciones relacionadas con la gestión de alertas Prometheus.
dashboard-settings
Permite cambiar la conguración de la consola.
11.3.2 Especificación de funciones de usuario
Una función especica un conjunto de asignaciones entre un ámbito de seguridad y un conjuntode permisos. Hay cuatro tipos de permisos: "leer", "crear", "actualizar" y "suprimir".
En el ejemplo siguiente se especica una función en la que un usuario tiene los permisos "leer"y "crear" para las características relacionadas con la gestión de repositorios, y tiene permisoscompletos para las características relacionadas con la gestión de imágenes RBD:
{ 'role': 'my_new_role', 'description': 'My new role', 'scopes_permissions': { 'pool': ['read', 'create'], 'rbd-image': ['read', 'create', 'update', 'delete'] }}
La consola ya proporciona un conjunto de funciones predenidas que llamamos funciones delsistema. Puede usarlas de inmediato después de instalar la Ceph Dashboard:
administrator
80 Especificación de funciones de usuario SES 7
Proporciona permisos completos para todos los ámbitos de seguridad.
read-only
Proporciona permiso de lectura para todos los ámbitos de seguridad, excepto para laconguración de la consola.
block-manager
Proporciona permisos completos para los ámbitos "rbd-image", "rbd-mirroring" e "iscsi".
rgw-manager
Proporciona permisos completos para el ámbito "rgw".
cluster-manager
Proporciona permisos completos para los ámbitos "hosts", "osd", "monitor", "manager" y"cong-opt".
pool-manager
Proporciona permisos completos para el ámbito "pool".
cephfs-manager
Proporciona permisos completos para el ámbito "cephfs".
11.3.2.1 Gestión de funciones personalizadas
Puede crear nuevas funciones de usuario mediante los siguientes comandos:
Crear una función:
cephuser@adm > ceph dashboard ac-role-create ROLENAME [DESCRIPTION]
Suprimir una función:
cephuser@adm > ceph dashboard ac-role-delete ROLENAME
Añadir permisos de ámbito a una función:
cephuser@adm > ceph dashboard ac-role-add-scope-perms ROLENAME SCOPENAME PERMISSION [PERMISSION...]
Suprimir permisos de ámbito de una función:
cephuser@adm > ceph dashboard ac-role-del-perms ROLENAME SCOPENAME
81 Especificación de funciones de usuario SES 7
11.3.2.2 Asignación de funciones a cuentas de usuario
Utilice los comandos siguientes para asignar funciones a los usuarios:
Definir funciones de usuario:
cephuser@adm > ceph dashboard ac-user-set-roles USERNAME ROLENAME [ROLENAME ...]
Añadir funciones adicionales a un usuario:
cephuser@adm > ceph dashboard ac-user-add-roles USERNAME ROLENAME [ROLENAME ...]
Suprimir funciones de un usuario:
cephuser@adm > ceph dashboard ac-user-del-roles USERNAME ROLENAME [ROLENAME ...]
Sugerencia: limpieza de funciones personalizadasSi crea funciones de usuario personalizadas y tiene previsto eliminar el clúster deCeph con el runner ceph.purge más adelante, primero debe limpiar las funcionespersonalizadas. Más detalles en la Sección 13.9, “Eliminación de un clúster de Ceph completo”
11.3.2.3 Ejemplo: creación de un usuario y una función personalizada
En esta sección se describe un procedimiento para crear una cuenta de usuario capaz de gestionarimágenes RBD, ver y crear repositorios de Ceph y tener acceso de solo lectura a cualquier otroámbito.
1. Cree un usuario llamado tux :
cephuser@adm > ceph dashboard ac-user-create tux PASSWORD
2. Cree una función y especique los permisos de ámbito:
cephuser@adm > ceph dashboard ac-role-create rbd/pool-managercephuser@adm > ceph dashboard ac-role-add-scope-perms rbd/pool-manager \ rbd-image read create update deletecephuser@adm > ceph dashboard ac-role-add-scope-perms rbd/pool-manager pool read create
3. Asocie las funciones con el usuario tux :
cephuser@adm > ceph dashboard ac-user-set-roles tux rbd/pool-manager read-only
82 Especificación de funciones de usuario SES 7
11.4 Configuración de proxy:Si desea establecer una URL ja para acceder a Ceph Dashboard, o si no desea permitirconexiones directas con los nodos del gestor, puede congurar un servidor proxy que reenvíeautomáticamente las peticiones entrantes a la instancia de ceph-mgr activa.
11.4.1 Acceso a la consola con proxies inversos
Si accede a la consola a través de una conguración de proxy inverso, es posible que deba darleservicio mediante un prejo de URL. Para que la consola pueda usar hipervínculos que incluyanel prejo, puede denir el valor de url_prefix :
cephuser@adm > ceph config set mgr mgr/dashboard/url_prefix URL_PREFIX
A continuación, podrá acceder a la consola en http://NOMBRE_HOST:NÚMERO_PUERTO/
PREFIJO_URL/ .
11.4.2 Inhabilitación de redirecciones
Si Ceph Dashboard se encuentra detrás de un servidor proxy de equilibrio de carga comoHAProxy, inhabilite el comportamiento de redirección para evitar situaciones en las que las URLinternas (que no se pueden resolver) se publiquen en el cliente de procesador frontal. Utiliceel comando siguiente para que la consola responda con un error HTTP ( 500 por defecto) enlugar de redirigir a la consola activa:
cephuser@adm > ceph config set mgr mgr/dashboard/standby_behaviour "error"
Para restablecer el ajuste al comportamiento de redirección por defecto, utilice el comandosiguiente:
cephuser@adm > ceph config set mgr mgr/dashboard/standby_behaviour "redirect"
11.4.3 Configuración de códigos de estado de error
Si el comportamiento de redirección está inhabilitado, debe personalizar el código de estadoHTTP de las consolas en espera. Para ello, ejecute el comando siguiente:
cephuser@adm > ceph config set mgr mgr/dashboard/standby_error_status_code 503
83 Configuración de proxy: SES 7
11.4.4 Configuración de ejemplo de HAProxy
El siguiente ejemplo de conguración es para la transferencia directa TLS/SSL medianteHAProxy.
NotaLa conguración funciona en las siguientes condiciones: si la consola falla, el clientede procesador frontal puede recibir una respuesta de redirección HTTP ( 303 ) y se leredirigirá a un host que no se puede resolver.
Esto ocurre cuando se produce un failover durante dos comprobaciones de estado deHAProxy. En este caso, el nodo de consola anteriormente activo responderá ahora con un303, que señala al nuevo nodo activo. Para evitarlo, puede inhabilitar el comportamientode redirección en los nodos en espera.
defaults log global option log-health-checks timeout connect 5s timeout client 50s timeout server 450s
frontend dashboard_front mode http bind *:80 option httplog redirect scheme https code 301 if !{ ssl_fc }
frontend dashboard_front_ssl mode tcp bind *:443 option tcplog default_backend dashboard_back_ssl
backend dashboard_back_ssl mode tcp option httpchk GET / http-check expect status 200 server x HOST:PORT ssl check verify none server y HOST:PORT ssl check verify none server z HOST:PORT ssl check verify none
84 Configuración de ejemplo de HAProxy SES 7
11.5 Auditoría de peticiones de API
La API REST de Ceph Dashboard puede registrar peticiones PUT, POST y DELETE en el registrode auditoría de Ceph. El registro está inhabilitado por defecto, pero es posible habilitarlo conel siguiente comando:
cephuser@adm > ceph dashboard set-audit-api-enabled true
Si está habilitado, se registran los parámetros siguientes por cada petición:
from
El origen de la petición, por ejemplo "https://[::1]:44410".
path
La vía de la API REST, por ejemplo /api/auth .
method
"PUT", "POST" o "DELETE".
user
El nombre del usuario (o "Ninguno").
Una entrada de registro de ejemplo tiene este aspecto:
2019-02-06 10:33:01.302514 mgr.x [INF] [DASHBOARD] \ from='https://[::ffff:127.0.0.1]:37022' path='/api/rgw/user/exu' method='PUT' \ user='admin' params='{"max_buckets": "1000", "display_name": "Example User", "uid": "exu", "suspended": "0", "email": "[email protected]"}'
Sugerencia: inhabilitación del registro de la carga útil de lapeticiónEl registro de la carga útil de la petición (la lista de argumentos y sus valores) estáhabilitado por defecto. Puede inhabilitarlo de la siguiente manera:
cephuser@adm > ceph dashboard set-audit-api-log-payload false
85 Auditoría de peticiones de API SES 7
11.6 Configuración de NFS Ganesha en CephDashboardCeph Dashboard puede gestionar las exportaciones de NFS Ganesha que utilizan CephFS u ObjectGateway como almacén secundario. La consola gestiona los archivos de conguración de NFSGanesha almacenados en objetos RADOS en el clúster de CephFS. NFS Ganesha debe almacenarparte de su conguración en el clúster de Ceph.
Ejecute el comando siguiente para congurar la ubicación del objeto de conguración de NFSGanesha:
cephuser@adm > ceph dashboard set-ganesha-clusters-rados-pool-namespace pool_name[/namespace]
Ahora puede gestionar las exportaciones de NFS Ganesha mediante Ceph Dashboard.
11.6.1 Configuración de varios clústeres de NFS Ganesha
Ceph Dashboard admite la gestión de exportaciones de NFS Ganesha que pertenecen a diferentesclústeres de NFS Ganesha. Se recomienda que cada clúster de NFS Ganesha almacene susobjetos de conguración en un repositorio o espacio de nombres RADOS diferente para aislarlas conguraciones entre sí.
Utilice el comando siguiente para especicar las ubicaciones de la conguración de cada clústerde NFS Ganesha:
cephuser@adm > ceph dashboard set-ganesha-clusters-rados-pool-namespace cluster_id:pool_name[/namespace](,cluster_id:pool_name[/namespace])*
La cadena cluster_id es arbitraria e identica de forma exclusiva el clúster de NFS Ganesha.
Al congurar Ceph Dashboard con varios clústeres de NFS Ganesha, la interfaz de usuario Webpermite elegir automáticamente a qué clúster pertenece una exportación.
11.7 Depuración de complementosLos complementos de Ceph Dashboard amplían la funcionalidad de la consola. El complementode depuración permite personalizar el comportamiento de la consola según el modo dedepuración. Puede habilitarse, inhabilitarse o comprobarse con el comando siguiente:
cephuser@adm > ceph dashboard debug status
86 Configuración de NFS Ganesha en Ceph Dashboard SES 7
Debug: 'disabled'cephuser@adm > ceph dashboard debug enableDebug: 'enabled'cephuser@adm > dashboard debug disableDebug: 'disabled'
Por defecto, está inhabilitado. Este es el valor recomendado para las distribuciones deproducción. Si es necesario, se puede habilitar el modo de depuración sin necesidad de reiniciar.
87 Depuración de complementos SES 7
II Operación del clúster
12 Determinación del estado del clúster 89
13 Tareas operativas 120
14 Funcionamiento de los servicios de Ceph 142
15 Copia de seguridad y recuperación 147
16 Supervisión y alertas 150
12 Determinación del estado del clúster
Si dispone de un clúster en ejecución, puede utilizar la herramienta ceph para supervisarlo.Normalmente, determinar el estado del clúster implica el estado de los daemons Ceph OSD, losmonitores Ceph Monitor, los grupos de colocación y los servidores de metadatos.
Sugerencia: modo interactivoPara ejecutar la herramienta ceph en el modo interactivo, escriba ceph en la línea decomandos sin ningún argumento. El modo interactivo es más cómodo si se van a introducirmás comandos ceph en una la. Por ejemplo:
cephuser@adm > cephceph> healthceph> statusceph> quorum_statusceph> mon stat
12.1 Comprobación del estado de un clústerPuede averiguar el estado inmediato del clúster mediante ceph status o ceph -s :
cephuser@adm > ceph -scluster: id: b4b30c6e-9681-11ea-ac39-525400d7702d health: HEALTH_OK
services: mon: 5 daemons, quorum ses-min1,ses-master,ses-min2,ses-min4,ses-min3 (age 2m) mgr: ses-min1.gpijpm(active, since 3d), standbys: ses-min2.oopvyh mds: my_cephfs:1 {0=my_cephfs.ses-min1.oterul=up:active} osd: 3 osds: 3 up (since 3d), 3 in (since 11d) rgw: 2 daemons active (myrealm.myzone.ses-min1.kwwazo, myrealm.myzone.ses-min2.jngabw)
task status: scrub status: mds.my_cephfs.ses-min1.oterul: idle
data:
89 Comprobación del estado de un clúster SES 7
pools: 7 pools, 169 pgs objects: 250 objects, 10 KiB usage: 3.1 GiB used, 27 GiB / 30 GiB avail pgs: 169 active+clean
La salida proporciona la siguiente información:
ID del clúster
Estado del clúster
Valor epoch de la asignación de monitores y estado del quórum de monitores
Valor epoch de asignación de OSD y estado de los OSD
El estado de las instancias de Ceph Manager
El estado de las pasarelas Object Gateway
La versión de asignación del grupo de colocación
El número de grupos de colocación y de repositorios
La cantidad teórica de datos almacenados y el número de objetos almacenados
La cantidad total de datos almacenados
Sugerencia: cómo calcula Ceph el uso de datosEl valor used (utilizado) reeja la cantidad real de almacenamiento en bruto utilizado. Elnúmero menor del valor xxx GB / xxx GB indica la cantidad disponible de la capacidadde almacenamiento global del clúster. El número teórico reeja el tamaño de los datosalmacenados antes de que se repliquen, se clonen o se capturen en una instantánea. Por lotanto, la cantidad de datos que se almacena realmente suele superar el almacenamientoteórico, dado que Ceph crea réplicas de los datos y también puede utilizar la capacidadde almacenamiento para tareas de clonación y de captura de instantáneas.
Otros comandos que muestran la información de estado inmediato son los siguientes:
ceph pg stat
ceph osd pool stats
90 Comprobación del estado de un clúster SES 7
ceph df
ceph df detail
Para obtener la información actualizada en tiempo real, coloque cualquiera de estos comandos(incluyendo ceph -s ) como argumento del comando watch :
root # watch -n 10 'ceph -s'
Pulse Control – C cuando quiera detener la visualización.
12.2 Comprobación del estado del clústerUna vez iniciado el clúster y antes de empezar a leer o escribir datos, compruebe su estado:
cephuser@adm > ceph healthHEALTH_WARN 10 pgs degraded; 100 pgs stuck unclean; 1 mons down, quorum 0,2 \node-1,node-2,node-3
SugerenciaSi ha especicado ubicaciones distintas de las establecidas por defecto para laconguración o el anillo de claves, puede indicarlas:
cephuser@adm > ceph -c /path/to/conf -k /path/to/keyring health
El clúster de Ceph devolverá uno de los siguientes códigos de estado:
OSD_DOWN
Uno o varios OSD están señalados como inactivos. Se ha detenido el daemon OSD o lospares OSD no pueden acceder al OSD a través de la red. Algunas de las causas pueden serun daemon detenido o bloqueado, un host caído o una interrupción de la red.Compruebe que el host está en buen estado, el daemon se inicia y la red está funcionando.Si el daemon se ha bloqueado, el archivo de registro de daemon ( /var/log/ceph/ceph-osd.* ) puede contener información de depuración.
OSD_ tipo de bloqueo _DOWN; por ejemplo: OSD_HOST_DOWN
Todos los OSD con un determinado subárbol CRUSH se marcan como inactivos, porejemplo, todos los OSD de un host.
91 Comprobación del estado del clúster SES 7
OSD_ORPHAN
Se hace referencia a un OSD en la jerarquía de asignaciones CRUSH, pero no existe. ElOSD se puede quitar de la jerarquía CRUSH con:
cephuser@adm > ceph osd crush rm osd.ID
OSD_OUT_OF_ORDER_FULL
Los umbrales de uso para backllfull (el valor por defecto es 0,90), nearfull (por defecto,0,85), full (por defecto, 0,95) o failsafe_full no son ascendentes. En concreto, esperamosbackllfull < nearfull, nearfull < full y full < failsafe_full.Para leer los valores actuales, ejecute:
cephuser@adm > ceph health detailHEALTH_ERR 1 full osd(s); 1 backfillfull osd(s); 1 nearfull osd(s)osd.3 is full at 97%osd.4 is backfill full at 91%osd.2 is near full at 87%
Los umbrales se pueden ajustar con los comandos siguientes:
cephuser@adm > ceph osd set-backfillfull-ratio ratiocephuser@adm > ceph osd set-nearfull-ratio ratiocephuser@adm > ceph osd set-full-ratio ratio
OSD_FULL
Uno o varios OSD han excedido el umbral full, lo que impide que el clúster de servicio alas operaciones de escritura. El uso del repositorio se puede comprobar con:
cephuser@adm > ceph df
La proporción de full denida actualmente se puede consultar con:
cephuser@adm > ceph osd dump | grep full_ratio
Una solución a corto plazo para restaurar la disponibilidad de las operaciones de escrituraes aumentar el umbral "full" en una pequeña cantidad:
cephuser@adm > ceph osd set-full-ratio ratio
Añada nuevo espacio de almacenamiento al clúster mediante la implantación de más OSDo suprima datos existentes para liberar espacio.
OSD_BACKFILLFULL
92 Comprobación del estado del clúster SES 7
Uno o varios OSD han excedido el umbral backllfull, lo que impide que los datos se puedanreequilibrar en este dispositivo. Se trata de una advertencia previa de que podría resultarimposible completar el reequilibrio y de que el clúster está casi lleno. El uso del repositoriose puede comprobar con:
cephuser@adm > ceph df
OSD_NEARFULL
Uno o varios OSD han excedido el umbral nearfull. Se trata de una advertencia previa deque el clúster está casi lleno. El uso del repositorio se puede comprobar con:
cephuser@adm > ceph df
OSDMAP_FLAGS
Se han denido uno o varios indicadores de interés en el clúster. Con la excepción de full,estos indicadores se pueden establecer o borrar con:
cephuser@adm > ceph osd set flagcephuser@adm > ceph osd unset flag
Los indicadores son los siguientes:
full
El clúster se marca como lleno y no permite realizar operaciones de escritura.
pauserd, pausewr
Operaciones de lectura o de escritura en pausa.
noup
No se pueden iniciar los OSD.
nodown
Se omiten los informes de fallo de los OSD, de modo que los monitores no marquenlos OSD como caídos (down).
noin
Los OSD que se hayan marcado como out (fuera) no se volverán a marcar como in(dentro) cuando se inicien.
noout
Los OSD caídos (down) no se marcarán automáticamente como out (fuera) despuésdel intervalo congurado.
93 Comprobación del estado del clúster SES 7
nobackfill, norecover, norebalance
Las operaciones de recuperación o de reequilibrio de datos están suspendidas.
noscrub, nodeep_scrub
Las operaciones de borrado seguro (consulte la Sección 17.6, “Depuración de grupos de
colocación”) están inhabilitadas.
notieragent
Las actividades de niveles de caché están suspendidas.
OSD_FLAGS
Uno o varios OSD tienen establecido un indicador de interés por OSD. Los indicadores sonlos siguientes:
noup
El OSD no se puede iniciar.
nodown
Se omitirán los informes de errores para este OSD.
noin
Si este OSD se ha marcado anteriormente como out (fuera) tras un fallo, no se marcarácomo in (dentro) cuando se inicie.
noout
Si este OSD está apagado, no se marcará automáticamente como out (fuera) despuésdel intervalo congurado.
Los indicadores por OSD se pueden denir y desactivar con:
cephuser@adm > ceph osd add-flag osd-IDcephuser@adm > ceph osd rm-flag osd-ID
OLD_CRUSH_TUNABLES
La asignación CRUSH utiliza una conguración muy antigua y se debe actualizar. Lostunables más antiguos que se pueden utilizar (es decir, es la versión más antigua delcliente que se puede conectar al clúster) sin que se active esta advertencia de estado estádeterminada por la opción de conguración mon_crush_min_required_version .
OLD_CRUSH_STRAW_CALC_VERSION
La asignación CRUSH utiliza un método más antiguo y no óptimo para calcular losvalores de peso intermedio para el ordenamiento por casilleros. La asignación CRUSH debeactualizarse para utilizar el método más reciente ( straw_calc_version=1).
94 Comprobación del estado del clúster SES 7
CACHE_POOL_NO_HIT_SET
Uno o varios repositorios de caché no están congurados con un conjunto de resultadospara realizar el seguimiento del uso, lo que impide que el agente de niveles de cachéidentique los objetos fríos que debe limpiar y expulsar del caché. Los conjuntos deresultados se pueden congurar en el repositorio de caché con:
cephuser@adm > ceph osd pool set poolname hit_set_type typecephuser@adm > ceph osd pool set poolname hit_set_period period-in-secondscephuser@adm > ceph osd pool set poolname hit_set_count number-of-hitsetscephuser@adm > ceph osd pool set poolname hit_set_fpp target-false-positive-rate
OSD_NO_SORTBITWISE
No hay ningún OSD anterior a Luminous versión 12 en ejecución, pero no se ha denidoel indicador sortbitwise . Debe denir el indicador sortbitwise para que se puedaniniciar los OSD de Luminous 12 o versiones más recientes:
cephuser@adm > ceph osd set sortbitwise
POOL_FULL
Uno o varios repositorios han alcanzado su cuota y ya no permiten más operaciones deescritura. Es posible denir cuotas de repositorio y límites de uso con:
cephuser@adm > ceph df detail
Puede aumentar la cuota de repositorio con
cephuser@adm > ceph osd pool set-quota poolname max_objects num-objectscephuser@adm > ceph osd pool set-quota poolname max_bytes num-bytes
o suprimir algunos datos para reducir el uso.
PG_AVAILABILITY
Hay una disponibilidad reducida de los datos, lo que signica que el clúster no puederesponder a posibles peticiones de lectura o escritura de algunos de los datos del clúster. Enparticular, uno o varios grupos de colocación se encuentran en un estado que no permiteatender las peticiones de E/S. Los estados de los grupos de colocación afectados son peering(emparejando), stale (detenido), incomplete (incompleto) y la ausencia de active (activo) (sidichos estados no desaparecen rápidamente). Encontrará información detallada sobre losgrupos de colocación afectados en:
cephuser@adm > ceph health detail
95 Comprobación del estado del clúster SES 7
En la mayoría de los casos, la causa raíz es que uno o varios OSD están caídos. Se puedeconsultar el estado de los grupos de colocación afectados especícos con:
cephuser@adm > ceph tell pgid query
PG_DEGRADED
Se reduce la redundancia de algunos datos, lo que signica que el clúster no tiene el númerodeseado de réplicas de todos los datos (para los repositorios replicados) o fragmentos decódigo de borrado (para los repositorios codicados de borrado). En concreto, uno o variosgrupos de colocación tienen establecido el indicador degraded (degradado) o undersized(tamaño insuciente) (no hay sucientes instancias de ese grupo de colocación en elclúster), o bien hace tiempo que no cuenta con el indicador clean (limpio). Encontraráinformación detallada sobre los grupos de colocación afectados en:
cephuser@adm > ceph health detail
En la mayoría de los casos, la causa raíz es que uno o varios OSD están caídos. Se puedeconsultar el estado de los grupos de colocación afectados especícos con:
cephuser@adm > ceph tell pgid query
PG_DEGRADED_FULL
La redundancia de datos se puede reducir o estar en peligro para algunos datos debido ala falta de espacio disponible en el clúster. En concreto, uno o varios grupos de colocacióntienen establecidos los indicadores backll_toofull o recovery_toofull, lo que signica queel clúster no puede migrar o recuperar datos debido a que uno o varios OSD superan elumbral backllfull.
PG_DAMAGED
El proceso de borrado seguro de datos (consulte la Sección 17.6, “Depuración de grupos
de colocación”) ha detectado problemas con la coherencia de los datos en el clúster.Especícamente, hay uno o varios grupos de colocación con el indicador inconsistent osnaptrim_error, que indican que una operación anterior de borrado seguro ha detectadoun problema, o bien se ha establecido el indicador repair, lo que signica que hay unareparación de dicha incoherencia en curso.
OSD_SCRUB_ERRORS
Los procesos de borrado seguro de OSD recientes han revelado incoherencias.
CACHE_POOL_NEAR_FULL
96 Comprobación del estado del clúster SES 7
Un repositorio de nivel de caché está casi lleno. La capacidad en este contexto estádeterminada por las propiedades target_max_bytes y target_max_objects que aparecen en elrepositorio de caché. Cuando el repositorio alcanza el umbral objetivo, las peticiones deescritura para el repositorio podrían bloquearse hasta que los datos se limpien y se expulsendel caché, un estado que suele producir latencias muy altas y un rendimiento deciente.El objetivo de tamaño del repositorio de caché se puede ajustar con:
cephuser@adm > ceph osd pool set cache-pool-name target_max_bytes bytescephuser@adm > ceph osd pool set cache-pool-name target_max_objects objects
Las actividades normales de limpieza y expulsión del caché también se pueden atascar poruna reducción de la disponibilidad o el rendimiento del nivel base o por la carga globaldel clúster.
TOO_FEW_PGS
El número de grupos de colocación en uso está por debajo del umbral congurable degrupos de colocación por OSD ( mon_pg_warn_min_per_osd ). Esto puede producir unadistribución y reequilibrio de datos subóptimo entre los OSD del clúster y reducir elrendimiento general.
TOO_MANY_PGS
El número de grupos de colocación en uso está por encima del umbral congurablede grupos de colocación por OSD ( mon_pg_warn_max_per_osd ). Esto puede dar lugara un uso más elevado de memoria para los daemons de OSD, un emparejamiento máslento después de cambios de estado del clúster (por ejemplo, reinicios, incorporaciones oeliminaciones de OSD) y una mayor carga mayor en los gestores y monitores de Ceph.Aunque no es posible reducir el valor de pg_num para los repositorios existentes, sí sepuede reducir el valor de pgp_num . A efectos prácticos, esto sitúa algunos grupos decolocación en los mismos conjuntos de OSD, mitigando algunos de los impactos negativosdescritos anteriormente. El valor pgp_num se puede ajustar con:
cephuser@adm > ceph osd pool set pool pgp_num value
SMALLER_PGP_NUM
Uno o varios repositorios tienen un valor pgp_num inferior a pg_num . Por lo general, estosuele indicar que se ha aumentado el número de grupos de colocación sin aumentar almismo tiempo el comportamiento de colocación. Normalmente, el problema se resuelvedeniendo pgp_num para que coincida con pg_num , lo que activa la migración de datos:
cephuser@adm > ceph osd pool set pool pgp_num pg_num_value
97 Comprobación del estado del clúster SES 7
MANY_OBJECTS_PER_PG
Uno o varios repositorios tienen un número medio de objetos por grupo de colocaciónsignicativamente superior al promedio general del clúster. El umbral especíco secontrola mediante el valor de conguración mon_pg_warn_max_object_skew . Esto sueleindicar que los repositorios que contienen la mayoría de los datos del clúster disponende muy pocos grupos de colocación o que los demás repositorios, que no contienentantos datos, tienen demasiados grupos de colocación. Se puede elevar el umbralpara silenciar la advertencia de estado; para ello, ajuste la opción de conguraciónmon_pg_warn_max_object_skew en los monitores.
POOL_APP_NOT_ENABLED
Existe un repositorio que contiene uno o varios objetos, pero no se ha etiquetado parasu uso por parte de una aplicación determinada. Para resolver esta advertencia, etiqueteel repositorio para su uso por parte de una aplicación. Por ejemplo, si el repositorio loutiliza RBD:
cephuser@adm > rbd pool init pool_name
Si el repositorio está siendo utilizado por una aplicación personalizada "foo", también sepuede etiquetar mediante el comando de bajo nivel:
cephuser@adm > ceph osd pool application enable foo
POOL_FULL
Uno o varios repositorios han alcanzado su cuota (o van a alcanzarla muy pronto). Elumbral para que se active esta situación de error depende de la opción de conguraciónmon_pool_quota_crit_threshold . Las cuotas del repositorio se pueden aumentar,reducir o eliminar con:
cephuser@adm > ceph osd pool set-quota pool max_bytes bytescephuser@adm > ceph osd pool set-quota pool max_objects objects
Si dene el valor de la cuota como 0, la cuota se inhabilitará.
POOL_NEAR_FULL
Uno o varios repositorios se están aproximando a su cuota. El umbral para quese active esta situación de advertencia depende de la opción de conguraciónmon_pool_quota_warn_threshold . Las cuotas del repositorio se pueden aumentar,reducir o eliminar con:
cephuser@adm > ceph osd osd pool set-quota pool max_bytes bytes
98 Comprobación del estado del clúster SES 7
cephuser@adm > ceph osd osd pool set-quota pool max_objects objects
Si dene el valor de la cuota como 0, la cuota se inhabilitará.
OBJECT_MISPLACED
Uno o varios objetos del clúster no se almacenan en el nodo en el que clúster pretendehacerlo. Esto indica que una migración de datos debida a algunos cambios recientes delclúster aún no se ha completado. El almacenamiento de datos en el lugar equivocado noes una situación peligrosa por sí misma. La coherencia de los datos nunca corre peligro ylas copias antiguas de los objetos no se eliminan hasta que se alcanza el número de copiasnuevas deseadas (en las ubicaciones correctas).
OBJECT_UNFOUND
No es posible encontrar uno o más objetos en el clúster. En concreto, los OSD saben quedebe existir una copia nueva o actualizada de un objeto, pero no se ha encontrado ningunacopia de esa versión del objeto en los OSD que están actualmente activos. Las peticionesde lectura o escritura a los objetos "unfound" (no encontrados) se bloquean. Idealmente,el OSD inactivo que tiene la copia más reciente del objeto no encontrado se puede volvera activar. Los OSD candidatos se pueden identicar a partir del estado de emparejamientode los grupos de colocación responsables del objeto no encontrado:
cephuser@adm > ceph tell pgid query
REQUEST_SLOW
Una o varias peticiones de OSD tardan mucho tiempo en procesarse. Esto puede indicarun nivel de carga extremo, un dispositivo de almacenamiento lento o un fallo de software.Puede consultar la cola de peticiones de los OSD en cuestión ejecutando el siguientecomando desde el host OSD:
cephuser@adm > ceph daemon osd.id ops
Puede consultar un resumen de las peticiones más lentas realizadas recientemente:
cephuser@adm > ceph daemon osd.id dump_historic_ops
Puede consultar la ubicación de un OSD con:
cephuser@adm > ceph osd find osd.id
REQUEST_STUCK
99 Comprobación del estado del clúster SES 7
Una o más peticiones de OSD se han bloqueado durante un tiempo relativamente largo, porejemplo 4096 segundos. Esto indica que el clúster lleva un periodo prolongado de tiempoen un estado incorrecto (por ejemplo, no hay sucientes OSD en ejecución o grupos decolocación inactivos) o que hay algún problema interno con el OSD.
PG_NOT_SCRUBBED
A uno o varios de los grupos de colocación no se les ha aplicado el borrado seguro(consulte la Sección 17.6, “Depuración de grupos de colocación”) recientemente. Normalmente,a los grupos de colocación se les aplica el borrado seguro cuando transcurre el númerode segundos indicado en mon_scrub_interval ; esta advertencia se activa cuandotranscurren los intervalos indicados en mon_warn_not_scrubbed sin que se realice unborrado seguro. A los grupos de colocación no se les aplicará el borrado seguro si noestán marcados como limpios; esto puede ocurrir si se extravían o se degradan (consultePG_AVAILABILITY y PG_DEGRADED más arriba). Puede iniciar manualmente el borradoseguro de un grupo de colocación limpio con:
cephuser@adm > ceph pg scrub pgid
PG_NOT_DEEP_SCRUBBED
Uno o varios grupos de colocación no se han sometido a un borrado seguro profundo(consulte la Sección 17.6, “Depuración de grupos de colocación”) recientemente. Normalmente,a los grupos de colocación se les aplica un borrado seguro profundo cuando transcurreel número de segundos indicado en osd_deep_mon_scrub_interval ; esta advertencia seactiva cuando transcurren los segundos indicados en mon_warn_not_deep_scrubbed sinque se realice un borrado seguro profundo. A los grupos de colocación no se les aplicaráel borrado seguro profundo si no están marcados como limpios; esto puede ocurrir si seextravían o se degradan (consulte PG_AVAILABILITY y PG_DEGRADED más arriba). Puedeiniciar manualmente el borrado seguro de un grupo de colocación limpio con:
cephuser@adm > ceph pg deep-scrub pgid
SugerenciaSi ha especicado ubicaciones distintas de las establecidas por defecto para laconguración o el anillo de claves, puede indicarlas:
root # ceph -c /path/to/conf -k /path/to/keyring health
100 Comprobación del estado del clúster SES 7
12.3 Comprobación de las estadísticas de uso de unclústerPara comprobar el uso de datos de un clúster y la distribución de datos entre los repositorios,utilice el comando ceph df . Para obtener más detalles, utilice ceph df detail .
cephuser@adm > ceph df--- RAW STORAGE ---CLASS SIZE AVAIL USED RAW USED %RAW USEDhdd 30 GiB 27 GiB 121 MiB 3.1 GiB 10.40TOTAL 30 GiB 27 GiB 121 MiB 3.1 GiB 10.40
--- POOLS ---POOL ID STORED OBJECTS USED %USED MAX AVAILdevice_health_metrics 1 0 B 0 0 B 0 8.5 GiBcephfs.my_cephfs.meta 2 1.0 MiB 22 4.5 MiB 0.02 8.5 GiBcephfs.my_cephfs.data 3 0 B 0 0 B 0 8.5 GiB.rgw.root 4 1.9 KiB 13 2.2 MiB 0 8.5 GiBmyzone.rgw.log 5 3.4 KiB 207 6 MiB 0.02 8.5 GiBmyzone.rgw.control 6 0 B 8 0 B 0 8.5 GiBmyzone.rgw.meta 7 0 B 0 0 B 0 8.5 GiB
La sección RAW STORAGE del resultado proporciona una descripción general de la cantidad dealmacenamiento que utiliza el clúster para los datos.
CLASS : la clase de almacenamiento del dispositivo. Consulte la Sección 17.1.1, “Clases de
dispositivos” para obtener más información sobre las clases de dispositivos.
SIZE : capacidad de almacenamiento global del clúster.
AVAIL : cantidad de espacio disponible en el clúster.
USED : el espacio (acumulado en todos los OSD) asignado exclusivamente para objetos dedatos conservados en el dispositivo de bloques.
RAW USED : la suma del espacio "USED" y el espacio asignado/reservado en el dispositivode bloques para propósitos de Ceph, por ejemplo la parte BlueFS para BlueStore.
% RAW USED : porcentaje de almacenamiento en bruto utilizado. Utilice este número juntocon full ratio (lleno) y near full ratio (casi lleno) para asegurarse de que no sealcanza la capacidad de su clúster. Consulte la Sección 12.8, “Capacidad de almacenamiento”
para obtener más información.
101 Comprobación de las estadísticas de uso de un clúster SES 7
Nota: nivel de llenado de clústerCuando un nivel de llenado de almacenamiento en bruto se acerca al 100 %,debe añadir nuevo almacenamiento al clúster. Un nivel de uso más elevado puedeprovocar que algunos OSD se llenen y se produzcan problemas de estado del clúster.
Utilice el comando ceph osd df tree para que se muestre el nivel de llenadode todos los OSD.
La sección POOLS de la salida proporciona una lista de los repositorios y el uso teórico de cadauno de ellos. La salida de esta sección no reeja las réplicas, las clonaciones ni las instantáneas.Por ejemplo, si almacena un objeto con 1 MB de datos, el uso teórico es de 1 MB, pero el usoreal puede ser de 2 MB o más, según el número de réplicas, clonaciones e instantáneas.
POOL : el nombre del repositorio.
ID : ID del repositorio.
STORED : la cantidad de datos almacenados por el usuario.
OBJECTS : el número teórico de objetos almacenados por repositorio.
USED : la cantidad de espacio asignado exclusivamente para los datos por todos los nodosde OSD, en kB.
%USED : el porcentaje teórico del almacenamiento utilizado por repositorio.
MAX AVAIL : el espacio máximo disponible en el repositorio especicado.
NotaLas cifras de la sección POOLS son teóricas. No incluyen el número de réplicas,clonaciones o instantáneas. Por lo tanto, la suma de las cantidades de USED y %USEDno se sumará a las cantidades de RAW USED y %RAW USED de la sección RAW STORAGEdel resultado.
102 Comprobación de las estadísticas de uso de un clúster SES 7
12.4 Comprobación del estado de los OSDPara comprobar los OSD y asegurarse de que estén activos y conectados, ejecute:
cephuser@adm > ceph osd stat
O bien
cephuser@adm > ceph osd dump
También puede ver los OSD según su posición en la asignación de CRUSH.
ceph osd tree imprime un árbol de CRUSH con un host, sus OSD, su estado de funcionamientoy su peso:
cephuser@adm > ceph osd treeID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF-1 3 0.02939 root default-3 3 0.00980 rack mainrack-2 3 0.00980 host osd-host0 1 0.00980 osd.0 up 1.00000 1.000001 1 0.00980 osd.1 up 1.00000 1.000002 1 0.00980 osd.2 up 1.00000 1.00000
12.5 Comprobación de OSD llenosCeph impide escribir en un OSD lleno para que no se pierden datos. En un clúster enfuncionamiento, debería aparecer una advertencia cuando el clúster se esté aproximando almáximo de su capacidad. El valor por defecto de mon osd full ratio es de 0,95 o un 95 %de capacidad para impedir la escritura de datos a los clientes. El valor por defecto de mon osdnearfull ratio es de 0,85 o 85 % de capacidad para generar una advertencia de estado.
El comando ceph health informa de los nodos de OSD llenos:
cephuser@adm > ceph health HEALTH_WARN 1 nearfull osds osd.2 is near full at 85%
O bien
cephuser@adm > ceph health HEALTH_ERR 1 nearfull osds, 1 full osds osd.2 is near full at 85%
103 Comprobación del estado de los OSD SES 7
osd.3 is full at 97%
La mejor forma de ocuparse de un clúster lleno es añadir hosts de OSD o discos para que elclúster redistribuya los datos en el nuevo espacio de almacenamiento disponible.
Sugerencia: cómo evitar que los OSD se llenenSi un OSD se llena (usa el 100 % de su espacio de disco), normalmente se bloqueará deinmediato y sin previo aviso. A continuación indicamos algunos consejos que convienerecordar al administrar nodos de OSD.
El espacio de disco de cada OSD (normalmente montado en /var/lib/ceph/osd/osd-{1,2..} ) debe colocarse en un disco o en una partición de uso dedicado.
Compruebe los archivos de conguración de Ceph y asegúrese de que Ceph noalmacena el archivo de registro en las particiones o los discos cuyo uso esté dedicadoa los OSD.
Asegúrese de que ningún otro proceso escribe en los discos o en las particiones deuso dedicado de los OSD.
12.6 Comprobación del estado del monitorDespués de iniciar el clúster y antes de leer o escribir datos por primera vez, compruebe elestado de quórum de los monitores Ceph Monitor. Si el clúster ya está sirviendo peticiones,compruebe periódicamente el estado de los monitores Ceph Monitor para asegurarse de que seestán ejecutando.
Para ver la asignación de monitores, ejecute lo siguiente:
cephuser@adm > ceph mon stat
O bien
cephuser@adm > ceph mon dump
Para comprobar el estado de quórum del clúster de monitores, ejecute lo siguiente:
cephuser@adm > ceph quorum_status
104 Comprobación del estado del monitor SES 7
Ceph devolverá el estado de quórum. Por ejemplo, un clúster de Ceph que consta de tresmonitores podría devolver lo siguiente:
{ "election_epoch": 10, "quorum": [ 0, 1, 2], "monmap": { "epoch": 1, "fsid": "444b489c-4f16-4b75-83f0-cb8097468898", "modified": "2011-12-12 13:28:27.505520", "created": "2011-12-12 13:28:27.505520", "mons": [ { "rank": 0, "name": "a", "addr": "192.168.1.10:6789\/0"}, { "rank": 1, "name": "b", "addr": "192.168.1.11:6789\/0"}, { "rank": 2, "name": "c", "addr": "192.168.1.12:6789\/0"} ] }}
12.7 Comprobación del estado de los grupos decolocación
Los grupos de colocación asignan objetos a los OSD. Al supervisar los grupos de colocación,es conveniente que tengan los estados active (activo) y clean (limpio). Para obtenerinformación detallada, consulte la Sección 12.9, “Supervisión de los OSD y los grupos de colocación”.
12.8 Capacidad de almacenamiento
Cuando un clúster de almacenamiento de Ceph se acerca a su capacidad máxima, Ceph impideescribir o leer desde los Ceph OSD como medida de seguridad para evitar la pérdida de datos.Por lo tanto, permitir que un clúster de producción se acerque a su máximo de capacidad no
105 Comprobación del estado de los grupos de colocación SES 7
es una buena práctica, ya que se sacrica la alta disponibilidad. El máximo de capacidad pordefecto se dene en .95, lo que signica el 95 % de la capacidad. Se trata de un valor muyagresivo para un clúster de pruebas con un número pequeño de OSD.
Sugerencia: aumento de la capacidad de almacenamientoAl supervisar el clúster, esté alerta a las advertencias relacionadas con la proporción denearfull (casi lleno). Signica que un error de algunos OSD podría dar lugar a unainterrupción temporal del servicio si se produce un error en uno o más OSD. Considerela posibilidad de añadir más OSD para aumentar la capacidad de almacenamiento.
Un escenario habitual para los clústeres de prueba es la de un administrador del sistema queelimina un Ceph OSD del clúster de almacenamiento de Ceph para observar el reequilibrio delclúster. A continuación, quita otro Ceph OSD, y así sucesivamente hasta que el clúster nalmentealcanza su máxima capacidad y se bloquea. Se recomienda cierta planicación de la capacidadincluso en el caso de un clúster de pruebas. La planicación permite estimar la capacidadde repuesto que se necesitará para poder mantener la alta disponibilidad. En una situaciónideal, desea planear una serie de errores del Ceph OSD en los que el clúster puede recuperarsea un estado activo + limpio sin tener que sustituir esos Ceph OSD de inmediato. Puedeejecutar un clúster en un estado activo + degradado , pero no es lo ideal para condicionesde funcionamiento normales.
En el diagrama siguiente se muestra un clúster de almacenamiento de Ceph simplicado quecontiene 33 nodos Ceph con un Ceph OSD por host. Cada uno de ellos lee y escribe en unaunidad de 3 TB. Este clúster de ejemplo tiene una capacidad real máxima de 99 TB. La opciónmon osd full ratio se dene en 0,95. Si el clúster cae por debajo de los 5 TB de capacidadrestante, no permitirá que los clientes lean y escriban datos. Por lo tanto, la capacidad operativadel clúster de almacenamiento es de 95 TB, no de 99 TB.
106 Capacidad de almacenamiento SES 7
FIGURA 12.1: CLÚSTER DE CEPH
En este tipo de clúster, es normal que uno o dos OSD fallen. Un escenario menos frecuente,aunque razonable, implica que el router o la fuente de alimentación de un bastidor falle, lo quedesactiva varios OSD simultáneamente (por ejemplo, los OSD del 7 al 12). En esa situación,debe seguir intentando que un clúster pueda permanecer operativo y logre un estado activo+ limpio , incluso si eso signica añadir algunos hosts con OSD adicionales a corto plazo. Si eluso de la capacidad es demasiado alto, es posible que no pierda datos. Sin embargo, aún podríasacricar la disponibilidad de los datos y resolver al mismo tiempo una interrupción dentro deun dominio de error si el uso de capacidad del clúster supera el máximo. Por este motivo, serecomienda que se realice al menos una planicación aproximada de la capacidad.
Identique dos valores para el clúster:
1. El número de OSD.
2. La capacidad total del clúster.
Si divide la capacidad total del clúster por el número de OSD del clúster, encontrará la capacidadmedia de un OSD dentro del clúster. También puede multiplicar ese número por el númerode OSD que espera que fallen simultáneamente durante las operaciones normales (un númerorelativamente pequeño). Por último, multiplique la capacidad del clúster por la capacidadmáxima para descubrir la capacidad operativa máxima. A continuación, reste la cantidad dedatos de los OSD que espera que no lleguen al máximo de capacidad razonable. Repita el procesoanterior con un mayor número de errores de OSD (un bastidor de OSD) para llegar a un númerorazonable capacidad casi máxima.
Los valores siguiente solo se aplica durante la creación del clúster y, después, se almacena enel mapa de OSD:
[global]
107 Capacidad de almacenamiento SES 7
mon osd full ratio = .80 mon osd backfillfull ratio = .75 mon osd nearfull ratio = .70
SugerenciaEstos valores solo se aplican durante la creación del clúster. Después deben cambiarseen el mapa de OSD utilizando los comandos ceph osd set-nearfull-ratio y cephosd set-full-ratio .
mon osd full ratio
El porcentaje de espacio en disco utilizado antes de un OSD se considera que está lleno .El valor por defecto es .95.
mon osd backfillfull ratio
El porcentaje de espacio en disco utilizado antes de un OSD se considera que estádemasiado lleno para la reposición. El valor por defecto es .90.
mon osd nearfull ratio
El porcentaje de espacio en disco utilizado antes de un OSD se considera que está casilleno . El valor por defecto es .85.
Sugerencia: comprobación del peso del OSDSi algunos OSD están casi llenos , pero otros tienen mucha capacidad, es posible quetenga un problema con el peso de CRUSH para los OSD casi llenos .
12.9 Supervisión de los OSD y los grupos decolocaciónLa alta disponibilidad y la alta conabilidad requieren un enfoque tolerante a fallos paragestionar problemas de hardware y software. Ceph no tiene un único punto de error y puedeatender peticiones de datos en un modo "degradado". La colocación de datos de Ceph introduceuna capa de direccionamiento indirecto para garantizar que los datos no se enlacen directamentea determinadas direcciones de OSD. Eso signica que para el seguimiento de los errores delsistema es necesario buscar el grupo de colocación y los OSD subyacentes en la raíz del problema.
108 Supervisión de los OSD y los grupos de colocación SES 7
Sugerencia: acceso en caso de falloUn error en una parte del clúster puede impedir que se acceda a un objeto determinado.Eso no signica que no se pueda acceder a otros objetos. Si encuentra un error, siga lospasos para supervisar los OSD y los grupos de colocación. A continuación, comience elproceso de solución de problemas.
Ceph, generalmente, se puede autorreparar. Sin embargo, si los problemas persisten, lasupervisión de los OSD y los grupos de colocación ayudará a identicar el problema.
12.9.1 Supervisión de OSD
El estado de un OSD se encuentra en el clúster ("in") o fuera del clúster ("out"). Al mismo tiempo,está en activo y en ejecución ("up") o desactivado y sin ejecutarse ("down"). Si un OSD está "up",puede estar en el clúster (es posible leer y escribir datos) o fuera del clúster. Si estaba en elclúster y se movió recientemente fuera del clúster, Ceph migrará los grupos de colocación aotros OSD. Si un OSD está fuera del clúster, CRUSH no le asignará grupos de colocación. Si unOSD está "down", también debe estar "out".
Nota: estado incorrectoSi un OSD está "down" e "in", hay un problema y el clúster no estará en un estado correcto.
Si ejecuta un comando como ceph health , ceph -s o ceph -w , puede darse el caso de queel clúster no siempre devuelva el estado HEALTH OK . Con respecto a los OSD, debe esperar queel clúster no devuelva HEALTH OK en las siguientes circunstancias:
Todavía no ha iniciado el clúster (no responderá).
Ha iniciado o reiniciado el clúster y aún no está listo, ya que se están creando los gruposde colocación y los OSD están en proceso de emparejamiento.
Ha añadido o eliminado un OSD.
Ha modicado el mapa del clúster.
109 Supervisión de OSD SES 7
Un aspecto importante de la supervisión de los OSD es asegurarse de que cuando el clúster estáactivo y en ejecución, todos los OSD del clúster también lo estén. Para comprobar si todos losOSD se están ejecutando, ejecute:
root # ceph osd statx osds: y up, z in; epoch: eNNNN
El resultado debería indicarle el número total de OSD (x), cuántos están "up" (y), cuántos están"in" (z) y la época del mapa (eNNNN). Si el número de OSD que están "in" en el clúster es mayorque el número de OSD que están "up", ejecute el comando siguiente para identicar los daemonsceph-osd que no se están ejecutando:
root # ceph osd tree#ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF-1 2.00000 pool openstack-3 2.00000 rack dell-2950-rack-A-2 2.00000 host dell-2950-A10 ssd 1.00000 osd.0 up 1.00000 1.000001 ssd 1.00000 osd.1 down 1.00000 1.00000
Por ejemplo, si un OSD con ID 1 está inactivo, para iniciarlo:
cephuser@osd > sudo systemctl start [email protected]
Consulte el Libro “Troubleshooting Guide”, Capítulo 4 “Troubleshooting OSDs”, Sección 4.3 “OSDs not
running” para consultar los problemas asociados con los OSD que se han detenido o que no sereinician.
12.9.2 Asignación de conjuntos de grupos de colocación
Cuando CRUSH asigna grupos de colocación a los OSD, examina el número de réplicas delrepositorio y asigna el grupo de colocación a los OSD de forma que cada réplica del grupo decolocación se asigne a un OSD diferente. Por ejemplo, si el repositorio requiere tres réplicas deun grupo de colocación, CRUSH puede asignarlas a osd.1 , osd.2 y osd.3 respectivamente.CRUSH en realidad intenta realizar una colocación seudoaleatoria que tenga en cuenta losdominios de error que establezca en su mapa de CRUSH, por lo que rara vez verá grupos decolocación asignados a los OSD vecinos más cercanos en un clúster grande. El conjunto de OSDque deben contener las réplicas de un grupo de colocación determinado se conoce como conjunto
110 Asignación de conjuntos de grupos de colocación SES 7
que actúa. En algunos casos, un OSD del conjunto que actúa está inactivo o no puede atenderlas peticiones de objetos del grupo de colocación. Si se da ese caso, puede deberse a uno de lossiguientes escenarios:
Ha añadido o eliminado un OSD. En tal caso, CRUSH reasignó el grupo de colocación aotros OSD y, por lo tanto, cambió la composición del conjunto que actúa, lo que provocóla migración de datos con un proceso de "reposición".
Un OSD con el estado "down", se ha reiniciado y ahora se está recuperando.
Un OSD del conjunto que actúa tiene el estado "down" o no puede atender peticiones, y otroOSD ha asumido temporalmente sus funciones.Ceph procesa la petición de un cliente con conjunto activo, que es el conjunto de OSD querealmente controlarán las peticiones. En la mayoría de los casos, el conjunto activo y elconjunto que actúa son prácticamente idénticos. Cuando no lo son, puede indicar que Cephestá migrando datos, que un OSD se está recuperando o que hay un problema (por ejemplo,Ceph suele responde a un estado HEALTH WARN con un mensaje "bloqueo obsoleto" entales casos).
Para recuperar una lista de grupos de colocación, ejecute:
cephuser@adm > ceph pg dump
Para ver qué OSD están dentro del conjunto que actúa o del conjunto activo para un grupo decolocación determinado, ejecute:
cephuser@adm > ceph pg map PG_NUMosdmap eNNN pg RAW_PG_NUM (PG_NUM) -> up [0,1,2] acting [0,1,2]
El resultado debe indicar la época de osdmap (eNNN), el número del grupo de colocación( PG_NUM ), los OSD del conjunto activo ("up") y los OSD del conjunto que actúa ("acting"):
Sugerencia: indicador de problema del clústerSi el conjunto activo y el conjunto que actúa no coinciden, puede ser un indicador de queel clúster se está reequilibrando o de que hay un posible problema con el clúster.
111 Asignación de conjuntos de grupos de colocación SES 7
12.9.3 Emparejamiento
Para poder escribir datos en un grupo de colocación, este debe estar en un estado activo yes recomendable que esté en un estado limpio . Para que Ceph determine el estado actual deun grupo de colocación, el OSD primario del grupo de colocación (el primer OSD del conjuntoque actúa) se empareja con los OSD secundario y terciario para establecer un acuerdo sobreel estado actual del grupo de colocación (suponiendo que el repositorio tenga tres réplicas delgrupo de colocación).
FIGURA 12.2: ESQUEMA DE EMPAREJAMIENTO
12.9.4 Supervisión de los estados del grupo de colocación
Si ejecuta un comando como ceph health , ceph -s o ceph -w , puede darse el caso de que elclúster no siempre devuelva el mensaje HEALTH OK . Después de comprobar si los OSD se estánejecutando, también debe comprobar los estados del grupo de colocación.
Es previsible que el clúster no devuelva HEALTH OK en varias circunstancias relacionadas conel emparejamiento del grupo de colocación:
Ha creado un repositorio y los grupos de colocación aún no se han emparejado.
Los grupos de colocación se están recuperando.
Ha añadido o ha eliminado un OSD del clúster.
Ha modicado el mapa de CRUSH y los grupos de colocación están migrando.
112 Emparejamiento SES 7
Hay datos incoherentes en diferentes réplicas de un grupo de colocación.
Ceph está borrando de forma segura las réplicas de un grupo de colocación.
Ceph no tiene suciente capacidad de almacenamiento para completar las operaciones dereposición.
Si una de las circunstancias mencionadas hace que Ceph devuelva el estado HEALTH WARN , nose preocupe. En muchos casos, el clúster se recuperará por sí solo. En algunos casos, es posibleque deba tomar alguna medida. Un aspecto importante a la hora de supervisar los grupos decolocación es que debe asegurarse de que cuando el clúster esté activo y en funcionamiento,todos los grupos de colocación deben estar "activos" y, preferiblemente, en un "estado limpio".Para ver el estado de todos los grupos de colocación, ejecute:
cephuser@adm > ceph pg statx pgs: y active+clean; z bytes data, aa MB used, bb GB / cc GB avail
El resultado debe indicar el número total de grupos de colocación (x); cuántos grupos decolocación están en un estado determinado, como "activo+limpio" (y) y la cantidad de datosalmacenados (z).
Además de los estados del grupo de colocación, Ceph también devolverá la cantidad decapacidad de almacenamiento utilizada (aa), la cantidad de capacidad de almacenamientorestante (bb) y la capacidad de almacenamiento total para el grupo de colocación. Estos valorespueden ser importantes en algunos casos:
Cuando se está alcanzando la capacidad casi máxima o la capacidad máxima .
Cuando los datos no se están distribuyendo por el clúster debido a un error en laconguración de CRUSH.
Sugerencia: ID de grupos de colocaciónLos ID de grupo de colocación constan del número de repositorio (no el nombre delrepositorio ) seguido de un punto (.) y el ID del grupo de colocación (un númerohexadecimal). Puede ver los números de repositorio y sus nombres en el resultado deceph osd lspools . Por ejemplo, el repositorio por defecto rbd corresponde al númerode repositorio 0. Un ID de grupo de colocación completo tiene el siguiente formato:
POOL_NUM.PG_ID
113 Supervisión de los estados del grupo de colocación SES 7
Y, normalmente, este aspecto:
0.1f
Para recuperar una lista de grupos de colocación, ejecute lo siguiente:
cephuser@adm > ceph pg dump
También puede dar al resultado formato JSON y guardarlo en un archivo:
cephuser@adm > ceph pg dump -o FILE_NAME --format=json
Para consultar un grupo de colocación determinado, ejecute lo siguiente:
cephuser@adm > ceph pg POOL_NUM.PG_ID query
En la lista siguiente se describen en detalle los estados habituales del grupo de colocación.
CREATING (CREACIÓN)
Cuando se crea un repositorio, se crea el número de grupos de colocación especicados.Ceph devolverá el mensaje "creating" cuando está creando uno o más grupos de colocación.Cuando se creen, los OSD que formen parte del conjunto que actúa del grupo de colocaciónse emparejarán. Cuando el emparejamiento se haya completado, el estado del grupode colocación debe ser "activo+limpio", lo que signica que un cliente de Ceph puedecomenzar a escribir en el grupo de colocación.
FIGURA 12.3: ESTADO DE LOS GRUPOS DE COLOCACIÓN
PEERING (EMPAREJAMIENTO)
Cuando Ceph empareja un grupo de colocación, está poniendo de acuerdo los OSD dondese almacenan las réplicas del grupo de colocación sobre el estado de los objetos y losmetadatos del grupo de colocación. Cuando Ceph completa el emparejamiento, signicaque los OSD donde se almacenan el grupo de colocación están de acuerdo sobre el estadoactual de dicho grupo. Sin embargo, que el proceso de emparejamiento haya nalizado nosignica que cada réplica tenga el contenido más reciente.
114 Supervisión de los estados del grupo de colocación SES 7
Nota: historial oficialCeph no reconocerá una operación de escritura a un cliente hasta que todos losOSD del conjunto que actúa persistan en la operación de escritura. Esta prácticagarantiza que al menos un miembro del conjunto que actúa tendrá un registro de cadaoperación de escritura reconocida desde la última operación de emparejamientocorrecta.
Con un registro preciso de cada operación de escritura reconocida, Ceph puedeconstruir y ampliar un nuevo historial ocial del grupo de colocación: un conjuntocompleto y completamente ordenado de operaciones que, si se realiza, actualizaríauna copia del OSD de un grupo de colocación.
ACTIVE (ACTIVO)
Cuando Ceph completa el proceso de emparejamiento, un grupo de colocación puedeconvertirse en activo . El estado activo signica que los datos del grupo de colocaciónestán generalmente disponibles en el grupo de colocación primario y en las réplicas paralas operaciones de lectura y escritura.
CLEAN (LIMPIO)
Cuando un grupo de colocación está en estado limpio , el OSD primario y los OSD deréplica se han emparejado correctamente y no hay réplicas perdidas para el grupo decolocación. Ceph ha replicado todos los objetos del grupo de colocación el número correctode veces.
DEGRADED (DEGRADADO)
Si un cliente escribe un objeto en el OSD primario, este es responsable de escribir lasréplicas en los OSD de réplica. Después de que el OSD primario escriba el objeto en elalmacenamiento, el grupo de colocación permanecerá en un estado "degradado" hasta queel OSD primario haya recibido una conrmación de los OSD de réplica de que Ceph hacreado los objetos de réplica correctamente.La razón por la que un grupo de colocación puede tener el estado "activo+degradado" esque un OSD puede estar "activo" aunque aún no contenga todos los objetos. Si un OSD dejade estar activo, Ceph marca cada grupo de colocación asignado al OSD como "degradado".Los OSD deben emparejarse de nuevo cuando el OSD vuelva a funcionar. Sin embargo,un cliente todavía puede escribir un objeto nuevo en un grupo de colocación degradadosi su estado es "activo".
115 Supervisión de los estados del grupo de colocación SES 7
Si un OSD está "inactivo" y la condición "degradado" persiste, Ceph puede marcar el OSDinactivo como "externo" al clúster y volver a asignar los datos del OSD "inactivo" a otro OSD.El tiempo que transcurre entre que se marca como "inactivo" y se marca como "externo" secontrola mediante la opción mon osd out interval , que se establece en 600 segundospor defecto.Un grupo de colocación también puede estar "degradado" porque Ceph no pueda encontraruno o varios objetos que deberían estar en el grupo de colocación. Aunque no puede leerni escribir en objetos no encontrados, puede acceder a todos los demás objetos del grupode colocación "degradado".
RECOVERING (EN RECUPERACIÓN)
Ceph se ha diseñado para la tolerancia a fallos a una escala en la que los problemas dehardware y software son continuos. Cuando un OSD está "inactivo", su contenido puedequedar obsoleto respecto al de otras réplicas de los grupos de colocación. Cuando el OSDvuelve a estar "activo", el contenido de los grupos de colocación debe actualizarse parareejar el estado actual. Durante ese período de tiempo, el OSD puede mostrar el estadode "en recuperación".La recuperación no siempre es sencilla, ya que un error de hardware puede provocar unerror en cascada de varios OSD. Por ejemplo, puede fallar un conmutador de red de unbastidor o un archivador, lo que puede provocar que el estado actual de los OSD de variasmáquinas host quede retrasado respecto al clúster. Cada uno de los OSD debe recuperarsecuando se resuelva el error.Ceph proporciona varios ajustes para equilibrar la contención de los recursos entre laspeticiones de servicio nuevas y la necesidad de recuperar objetos de datos y restaurar losgrupos de colocación al estado actual. El valor osd recovery delay start permiteque un OSD se reinicie, vuelva a emparejarse e, incluso, que procese algunas peticionesde respuesta antes de iniciar el proceso de recuperación. El valor osd recovery threadtimeout dene un tiempo límite del hilo, ya que varios OSD pueden fallar, reiniciarsey volver a emparejarse escalonadamente. El valor osd recovery max active limita elnúmero de peticiones de recuperación que un OSD procesará simultáneamente para evitarque el OSD no pueda atender las peticiones. El valor osd recovery max chunk limita eltamaño de los fragmentos de datos recuperados para evitar la congestión de la red.
BACK FILLING (EN REPOSICIÓN)
Cuando un nuevo OSD se une al clúster, CRUSH reasignará los grupos de colocación delos OSD del clúster al OSD recién añadido. Forzar al nuevo OSD a aceptar los grupos decolocación reasignados de inmediato, podría suponer una carga excesiva en el OSD nuevo.
116 Supervisión de los estados del grupo de colocación SES 7
Al reponer los grupos de colocación en el OSD, este proceso puede comenzar en segundoplano. Una vez completado la reposición, el nuevo OSD comenzará a atender las peticionescuando esté listo.Durante las operaciones de reposición, es posible que vea uno de estos estados:"backll_wait" indica que una operación de reposición está pendiente, pero aún no está encurso; "backll" indica que una operación de reposición está en curso; "backll_too_full"indica que se ha solicitado una operación de reposición, pero no se ha podido completardebido a que no hay capacidad de almacenamiento suciente. Si no se puede realizar lareposición de un grupo de colocación, puede considerarse como "incompleto".Ceph proporciona varios ajustes para gestionar la carga asociada con la reasignación degrupos de colocación a un OSD (especialmente un OSD nuevo). Por defecto, osd maxbackfills dene que el número máximo de reposiciones simultáneas hacia o desde unOSD sea de 10. El valor backfill full ratio permite que un OSD rechace una peticiónde reposición si el OSD se acerca a su capacidad máxima (90 %, por defecto), que se cambiacon ceph osd set-backfillfull-ratio . Si un OSD rechaza una petición de reposición,el valor osd backfill retry interval permite que un OSD vuelva a intentar la petición(después de 10 segundos, por defecto). También es posible denir en los OSD los valoresosd backfill scan min y osd backfill scan max para gestionar los intervalos deescaneo (64 y 512, por defecto).
REMAPPED (REASIGNADO)
Cuando cambia el conjunto que actúa que atiende a un grupo de colocación, los datos migrandel conjunto que actúa antiguo al nuevo. El nuevo OSD primario puede tardar algún tiempoen atender las peticiones de servicio. Por lo tanto, puede pedir al OSD primario antiguoque continúe atendiendo las peticiones hasta que se complete la migración del grupo decolocación. Cuando se completa la migración de los datos, la asignación utiliza el OSDprimario del conjunto que actúa nuevo.
STALE (OBSOLETO)
Mientras Ceph utiliza subejecución de réplica para asegurarse de que los hosts y losdaemons se están ejecutando, los daemons ceph-osd también pueden entrar en estado"bloqueo", en el que no informan sobre las estadísticas a tiempo (por ejemplo, si se produceun error temporal de la red). Por defecto, los daemons de OSD informan de las estadísticasde su grupo de colocación, del arranque y de los errores cada medio segundo (0,5), que esuna frecuencia mayor a la de los umbrales de subejecución de réplica. Si el OSD primario
117 Supervisión de los estados del grupo de colocación SES 7
del conjunto que actúa de un grupo de colocación no informa al monitor, o si otros OSDhan informado de que el OSD primario está "inactivo", los monitores marcarán el grupode colocación como "obsoleto".Al iniciar el clúster, es común ver el estado "obsoleto" hasta que se completa el procesode emparejamiento. Después de que el clúster se haya estado ejecutando durante untiempo, ver grupos de colocación con el estado "obsoleto" indica que el OSD primario paraesos grupos de colocación está inactivo o no informa sobre las estadísticas del grupo decolocación al monitor.
12.9.5 Búsqueda de una ubicación de objeto
Para almacenar datos de objetos en el almacén de objetos de Ceph, es preciso que un clientede Ceph dena un nombre de objeto y que especique un repositorio relacionado. El cliente deCeph recupera el mapa más reciente del clúster y el algoritmo CRUSH calcula cómo asignar elobjeto a un grupo de colocación. A continuación, calcula cómo asignar el grupo de colocacióna un OSD dinámicamente. Para localizar la ubicación del objeto, solo se necesita el nombre delobjeto y el nombre del repositorio. Por ejemplo:
cephuser@adm > ceph osd map POOL_NAME OBJECT_NAME [NAMESPACE]
EJEMPLO 12.1: LOCALIZACIÓN DE UN OBJETO
Como ejemplo, vamos a crear un objeto. Especique el nombre de objeto "test-object-1",una vía al archivo de ejemplo "testle.txt" que contiene algunos datos de objeto y elnombre de repositorio "data". Para ellos utilizaremos el comando rados put en la líneade comandos:
cephuser@adm > rados put test-object-1 testfile.txt --pool=data
Para vericar que el almacén de objetos de Ceph ha almacenado el objeto, ejecute losiguiente:
cephuser@adm > rados -p data ls
Ahora, identique la ubicación del objeto. Ceph generará la ubicación del objeto:
cephuser@adm > ceph osd map data test-object-1osdmap e537 pool 'data' (0) object 'test-object-1' -> pg 0.d1743484 \(0.4) -> up ([1,0], p0) acting ([1,0], p0)
118 Búsqueda de una ubicación de objeto SES 7
Para eliminar el objeto de ejemplo, basta con eliminarlo usando el comando rados rm :
cephuser@adm > rados rm test-object-1 --pool=data
119 Búsqueda de una ubicación de objeto SES 7
13 Tareas operativas
13.1 Modificación de la configuración del clústerPara modicar la conguración de un clúster de Ceph existente, siga estos pasos:
1. Exporte la conguración actual del clúster a un archivo:
cephuser@adm > ceph orch ls --export --format yaml > cluster.yaml
2. Edite el archivo con la conguración y actualice las líneas pertinentes. Encontraráejemplos de especicaciones en el Libro “Guía de distribución”, Capítulo 5 “Distribución con
cephadm”, Sección 5.4 “Distribución de servicios y pasarelas” y en la Sección 13.4.3, “Adición de
OSD mediante la especificación DriveGroups”.
3. Aplique la nueva conguración:
cephuser@adm > ceph orch apply -i cluster.yaml
13.2 Adición de nodosPara añadir un nodo nuevo a un clúster de Ceph, siga estos pasos:
1. Instale SUSE Linux Enterprise Server y SUSE Enterprise Storage en el nuevo host. Consulteel Libro “Guía de distribución”, Capítulo 5 “Distribución con cephadm”, Sección 5.1 “Instalación y
configuración de SUSE Linux Enterprise Server” para obtener más información.
2. Congure el host como un minion de Salt de un master de Salt ya existente. Consulte elLibro “Guía de distribución”, Capítulo 5 “Distribución con cephadm”, Sección 5.2 “Distribución de
Salt” para obtener más información.
3. Añada el nuevo host a ceph-salt y haga que cephadm lo reconozca, por ejemplo:
root@master # ceph-salt config /ceph_cluster/minions add ses-min5.example.comroot@master # ceph-salt config /ceph_cluster/roles/cephadm add ses-min5.example.com
Consulte el Libro “Guía de distribución”, Capítulo 5 “Distribución con cephadm”, Sección 5.3.2.2
“Adición de minions de Salt” para obtener más información.
120 Modificación de la configuración del clúster SES 7
4. Verique que el nodo se ha añadido a ceph-salt :
root@master # ceph-salt config /ceph_cluster/minions lso- minions ................................................. [Minions: 5][...] o- ses-min5.example.com .................................... [no roles]
5. Aplique la conguración al nuevo host del clúster:
root@master # ceph-salt apply ses-min5.example.com
6. Verique que el host recién añadido pertenece ahora al entorno de cephadm:
cephuser@adm > ceph orch host lsHOST ADDR LABELS STATUS[...]ses-min5.example.com ses-min5.example.com
13.3 Eliminación de nodos
Sugerencia: eliminación de OSDSi el nodo que va a eliminar ejecuta OSD, elimínelos primero y compruebe que no hayningún OSD en ejecución en ese nodo. Consulte la Sección 13.4.4, “Eliminación de OSD” paraobtener más información sobre la eliminación de OSD.
Para eliminar un nodo de un clúster, haga lo siguiente:
1. Para todos los tipos de servicio de Ceph, excepto node-exporter y crash , elimineel nombre de host del nodo del archivo de especicación de colocación del clúster(por ejemplo, cluster.yml ). Consulte Libro “Guía de distribución”, Capítulo 5 “Distribución
con cephadm”, Sección 5.4.2 “Especificación del servicio y la colocación” para obtener másinformación. Por ejemplo, si va a eliminar el host denominado ses-min2 , elimine todaslas apariciones de - ses-min2 de todas las secciones placement: .Actualice
service_type: rgwservice_id: EXAMPLE_NFSplacement:
121 Eliminación de nodos SES 7
hosts: - ses-min2 - ses-min3
a
service_type: rgwservice_id: EXAMPLE_NFSplacement: hosts: - ses-min3
Aplique los cambios al archivo de conguración:
cephuser@adm > ceph orch apply -i rgw-example.yaml
2. Elimine el nodo del entorno de cephadm:
cephuser@adm > ceph orch host rm ses-min2
3. Si el nodo ejecuta los servicios crash.osd.1 y crash.osd.2 , elimínelos ejecutando elsiguiente comando en el host:
root@minion > cephadm rm-daemon --fsid CLUSTER_ID --name SERVICE_NAME
Por ejemplo:
root@minion > cephadm rm-daemon --fsid b4b30c6e... --name crash.osd.1root@minion > cephadm rm-daemon --fsid b4b30c6e... --name crash.osd.2
4. Elimine todas las funciones del minion que desee suprimir:
cephuser@adm > ceph-salt config /ceph_cluster/roles/tuned/throughput remove ses-min2cephuser@adm > ceph-salt config /ceph_cluster/roles/tuned/latency remove ses-min2cephuser@adm > ceph-salt config /ceph_cluster/roles/cephadm remove ses-min2cephuser@adm > ceph-salt config /ceph_cluster/roles/admin remove ses-min2
Si el minion que desea suprimir es el minion de arranque, también debe eliminar la funciónbootstrap:
cephuser@adm > ceph-salt config /ceph_cluster/roles/bootstrap reset
5. Después de eliminar todos los OSD de un solo host, elimine el host del mapa de CRUSH:
cephuser@adm > ceph osd crush remove bucket-name
122 Eliminación de nodos SES 7
NotaEl nombre del depósito debe ser el mismo que el nombre del host.
6. Ahora puede eliminar el minion del clúster:
cephuser@adm > ceph-salt config /ceph_cluster/minions remove ses-min2
ImportanteEn caso de que se produzca un fallo y el minion que está intentando eliminar se encuentreapagado permanentemente, deberá eliminar el nodo del master de Salt:
root@master # salt-key -d minion_id
A continuación, elimine manualmente el nodo de raíz_pilar/ceph-salt.sls .Normalmente se encuentra en /srv/pillar/ceph-salt.sls .
13.4 Gestión de OSD
En esta sección se describe cómo añadir, borrar o eliminar OSD en un clúster de Ceph.
13.4.1 Listado de dispositivos de disco
Para identicar los dispositivos de disco usados y sin usar en todos los nodos del clúster,muéstrelos ejecutando el comando siguiente:
cephuser@adm > ceph orch device lsHOST PATH TYPE SIZE DEVICE AVAIL REJECT REASONSses-master /dev/vda hdd 42.0G False lockedses-min1 /dev/vda hdd 42.0G False lockedses-min1 /dev/vdb hdd 8192M 387836 False locked, LVM detected, Insufficient space (<5GB) on vgsses-min2 /dev/vdc hdd 8192M 450575 True
123 Gestión de OSD SES 7
13.4.2 Borrado de dispositivos de disco
Para reutilizar un dispositivo de disco, primero debe borrarlo (comando zap):
ceph orch device zap HOST_NAME DISK_DEVICE
Por ejemplo:
cephuser@adm > ceph orch device zap ses-min2 /dev/vdc
NotaSi ha distribuido previamente los OSD mediante DriveGroups o con la opción --all-available-devices sin que se haya denido el indicador unmanaged , cephadmdistribuirá estos OSD automáticamente después de borrarlos.
13.4.3 Adición de OSD mediante la especificación DriveGroups
DriveGroups especica los diseños de los OSD del clúster de Ceph. Se denen en un único archivoYAML. En esta sección, utilizaremos drive_groups.yml como ejemplo.
Un administrador debe especicar manualmente un grupo de OSD que estén interrelacionados(OSD híbridos que se distribuyen en una mezcla de unidades HDD y SDD) o que compartanopciones de distribución idénticas (por ejemplo, el mismo almacén de objetos, la mismaopción de cifrado y varios OSD independientes). Para no tener que mostrar explícitamente losdispositivos, DriveGroups utiliza una lista de elementos de ltro que corresponden a algunoscampos seleccionados de los informes de inventario de ceph-volume . cephadm proporcionacódigo que traduce esta especicación DriveGroups en listas de dispositivos reales para que elusuario las pueda inspeccionar.
El comando para aplicar la especicación de OSD al clúster es:
cephuser@adm > ceph orch apply osd -i drive_groups.yml
Para ver una vista previa de las acciones y probar la aplicación, puede utilizar la opción --dry-run junto con el comando ceph orch apply osd . Por ejemplo:
cephuser@adm > ceph orch apply osd -i drive_groups.yml --dry-run...+---------+------+------+----------+----+-----+|SERVICE |NAME |HOST |DATA |DB |WAL |+---------+------+------+----------+----+-----+|osd |test |mgr0 |/dev/sda |- |- |
124 Borrado de dispositivos de disco SES 7
|osd |test |mgr0 |/dev/sdb |- |- |+---------+------+------+----------+----+-----+
Si el resultado de --dry-run cumple sus expectativas, solo tiene que volver a ejecutar elcomando sin la opción --dry-run .
13.4.3.1 OSD no gestionados
Todos los dispositivos de disco limpios disponibles que coincidan con la especicaciónDriveGroups se utilizarán automáticamente como OSD después de añadirlos al clúster. Estecomportamiento se denomina modo gestionado.
Para inhabilitar el modo gestionado, añada la línea unmanaged: true a las especicacionesrelevantes, por ejemplo:
service_type: osdservice_id: example_drvgrp_nameplacement: hosts: - ses-min2 - ses-min3encrypted: trueunmanaged: true
SugerenciaPara cambiar los OSD ya distribuidos del modo gestionado al modo no gestionado, añadalas líneas unmanaged: true cuando corresponda durante el procedimiento descrito enla Sección 13.1, “Modificación de la configuración del clúster”.
13.4.3.2 Especificación DriveGroups
A continuación se muestra un ejemplo de archivo de especicación DriveGroups:
service_type: osdservice_id: example_drvgrp_nameplacement: host_pattern: '*'data_devices: drive_spec: DEVICE_SPECIFICATIONdb_devices: drive_spec: DEVICE_SPECIFICATION
125 Adición de OSD mediante la especificación DriveGroups SES 7
wal_devices: drive_spec: DEVICE_SPECIFICATIONblock_wal_size: '5G' # (optional, unit suffixes permitted)block_db_size: '5G' # (optional, unit suffixes permitted)encrypted: true # 'True' or 'False' (defaults to 'False')
NotaLa opción denominada anteriormente "encryption" en DeepSea ahora se llama"encrypted". Al aplicar DriveGroups en SUSE Enterprise Storage 7, asegúrese de utilizaresta nueva terminología en la especicación del servicio; de lo contrario, la operaciónceph orch apply fallará.
13.4.3.3 Filtrado de dispositivos de disco
Puede describir la especicación utilizando los ltros siguientes:
Por modelo del disco:
model: DISK_MODEL_STRING
Por proveedor del disco:
vendor: DISK_VENDOR_STRING
SugerenciaEscriba siempre DISK_VENDOR_STRING en minúsculas.
Para obtener detalles sobre el modelo de disco y el proveedor, examine el resultado delsiguiente comando:
cephuser@adm > ceph orch device lsHOST PATH TYPE SIZE DEVICE_ID MODEL VENDORses-min1 /dev/sdb ssd 29.8G SATA_SSD_AF34075704240015 SATA SSD ATAses-min2 /dev/sda ssd 223G Micron_5200_MTFDDAK240TDN Micron_5200_MTFD ATA[...]
Indica si un disco es giratorio o no. Las unidades SSD y NVMe no son giratorias.
rotational: 0
126 Adición de OSD mediante la especificación DriveGroups SES 7
Distribuya un nodo utilizando todas las unidades disponibles para los OSD:
data_devices: all: true
También puede limitar el número de discos que coinciden:
limit: 10
13.4.3.4 Filtrado de dispositivos por tamaño
Es posible ltrar los dispositivos de disco por su tamaño, ya sea por un tamaño exacto o por unintervalo de tamaños. El parámetro size: acepta argumentos con el formato siguiente:
'10G': incluye discos de un tamaño exacto.
'10G:40G': incluye discos cuyo tamaño está dentro del intervalo indicado.
':10G': incluye discos de 10 GB o menos.
'40G:': incluye discos de 40 GB o más.
EJEMPLO 13.1: FILTRADO POR TAMAÑO DE DISCO
service_type: osdservice_id: example_drvgrp_nameplacement: host_pattern: '*'data_devices: size: '40TB:'db_devices: size: ':2TB'
Nota: comillas obligatoriasSi se usa el delimitador ":", debe incluir el tamaño entre comillas simples, de lo contrarioel signo ":" se interpretará como un nuevo hash de conguración.
Sugerencia: accesos directos a unidadesEn lugar de gigabytes (G), puede especicar el tamaño en megabytes (M) o en terabytes(T).
127 Adición de OSD mediante la especificación DriveGroups SES 7
13.4.3.5 Ejemplos de DriveGroups
Esta sección incluye ejemplos de diferentes conguraciones de OSD.
EJEMPLO 13.2: CONFIGURACIÓN SENCILLA
Este ejemplo describe dos nodos con la misma conguración:
20 discos duros
Proveedor: Intel
Modelo: SSD-123-foo
Tamaño: 4 TB
2 discos SSD
Proveedor: Micron
Modelo: MC-55-44-ZX
Tamaño: 512 GB
El archivo drive_groups.yml correspondiente será el siguiente:
service_type: osdservice_id: example_drvgrp_nameplacement: host_pattern: '*'data_devices: model: SSD-123-foodb_devices: model: MC-55-44-XZ
Esta conguración es sencilla y válida. El problema es que un administrador puede añadirdiscos de diferentes proveedores en el futuro, y estos no se incluirán. Puede mejorarlareduciendo los ltros en las propiedades principales de las unidades:
service_type: osdservice_id: example_drvgrp_nameplacement: host_pattern: '*'data_devices: rotational: 1db_devices:
128 Adición de OSD mediante la especificación DriveGroups SES 7
rotational: 0
En el ejemplo anterior, estamos imponiendo que se declaren todos los dispositivosgiratorios como "dispositivos de datos" y todos los dispositivos no giratorios se utilizaráncomo "dispositivos compartidos" (wal, db).
Si sabe que las unidades de más de 2 TB siempre serán los dispositivos de datos más lentos,puede ltrar por tamaño:
service_type: osdservice_id: example_drvgrp_nameplacement: host_pattern: '*'data_devices: size: '2TB:'db_devices: size: ':2TB'
EJEMPLO 13.3: CONFIGURACIÓN AVANZADA
En este ejemplo se describen dos conguraciones distintas: 20 discos duros debencompartir 2 unidades SSD, mientras que 10 unidades SSD deben compartir 2 NVMe.
20 discos duros
Proveedor: Intel
Modelo: SSD-123-foo
Tamaño: 4 TB
12 discos SSD
Proveedor: Micron
Modelo: MC-55-44-ZX
Tamaño: 512 GB
2 NVMe
Proveedor: Samsung
Modelo: NVME-QQQQ-987
Tamaño: 256 GB
129 Adición de OSD mediante la especificación DriveGroups SES 7
Esta conguración se puede denir con dos diseños de la siguiente manera:
service_type: osdservice_id: example_drvgrp_nameplacement: host_pattern: '*'data_devices: rotational: 0db_devices: model: MC-55-44-XZ
service_type: osdservice_id: example_drvgrp_name2placement: host_pattern: '*'data_devices: model: MC-55-44-XZdb_devices: vendor: samsung size: 256GB
EJEMPLO 13.4: CONFIGURACIÓN AVANZADA CON NODOS NO UNIFORMES
En los ejemplos anteriores se suponía que todos los nodos tienen las mismas unidades. Sinembargo, eso no siempre es así:
Nodos 1-5:
20 discos duros
Proveedor: Intel
Modelo: SSD-123-foo
Tamaño: 4 TB
2 discos SSD
Proveedor: Micron
Modelo: MC-55-44-ZX
Tamaño: 512 GB
Nodos 6-10:
5 NVMe
130 Adición de OSD mediante la especificación DriveGroups SES 7
Proveedor: Intel
Modelo: SSD-123-foo
Tamaño: 4 TB
20 discos SSD
Proveedor: Micron
Modelo: MC-55-44-ZX
Tamaño: 512 GB
Puede utilizar la clave "target" en el diseño para asignar nodos especícos a un destino.La notación del destino de Salt ayuda a simplicar las cosas:
service_type: osdservice_id: example_drvgrp_one2fiveplacement: host_pattern: 'node[1-5]'data_devices: rotational: 1db_devices: rotational: 0
seguido de
service_type: osdservice_id: example_drvgrp_restplacement: host_pattern: 'node[6-10]'data_devices: model: MC-55-44-XZdb_devices: model: SSD-123-foo
EJEMPLO 13.5: CONFIGURACIÓN PARA EXPERTOS
En todos los casos anteriores se presuponía que los WAL y DB usaban el mismo dispositivo.Sin embargo, también es posible distribuir el WAL en un dispositivo dedicado:
20 discos duros
131 Adición de OSD mediante la especificación DriveGroups SES 7
Proveedor: Intel
Modelo: SSD-123-foo
Tamaño: 4 TB
2 discos SSD
Proveedor: Micron
Modelo: MC-55-44-ZX
Tamaño: 512 GB
2 NVMe
Proveedor: Samsung
Modelo: NVME-QQQQ-987
Tamaño: 256 GB
service_type: osdservice_id: example_drvgrp_nameplacement: host_pattern: '*'data_devices: model: MC-55-44-XZdb_devices: model: SSD-123-foowal_devices: model: NVME-QQQQ-987
EJEMPLO 13.6: CONFIGURACIÓN COMPLEJA (E IMPROBABLE)
En la siguiente conguración, tratamos de denir lo siguiente:
20 discos duros respaldados por 1 NVMe
2 discos duros respaldados por 1 SSD (db) y 1 NVMe (wal)
8 discos SSD respaldados por 1 NVMe
2 discos SSD independientes (cifrados)
1 disco duro es de repuesto y no debe distribuirse
132 Adición de OSD mediante la especificación DriveGroups SES 7
El resumen de las unidades usadas es el siguiente:
23 discos duros
Proveedor: Intel
Modelo: SSD-123-foo
Tamaño: 4 TB
10 discos SSD
Proveedor: Micron
Modelo: MC-55-44-ZX
Tamaño: 512 GB
1 NVMe
Proveedor: Samsung
Modelo: NVME-QQQQ-987
Tamaño: 256 GB
La denición de DriveGroups será la siguiente:
service_type: osdservice_id: example_drvgrp_hdd_nvmeplacement: host_pattern: '*'data_devices: rotational: 0db_devices: model: NVME-QQQQ-987
service_type: osdservice_id: example_drvgrp_hdd_ssd_nvmeplacement: host_pattern: '*'data_devices: rotational: 0db_devices: model: MC-55-44-XZwal_devices:
133 Adición de OSD mediante la especificación DriveGroups SES 7
model: NVME-QQQQ-987
service_type: osdservice_id: example_drvgrp_ssd_nvmeplacement: host_pattern: '*'data_devices: model: SSD-123-foodb_devices: model: NVME-QQQQ-987
service_type: osdservice_id: example_drvgrp_standalone_encryptedplacement: host_pattern: '*'data_devices: model: SSD-123-fooencrypted: True
Se conservará un disco duro porque el archivo se está analizando de arriba abajo.
13.4.4 Eliminación de OSD
Antes de eliminar un nodo de OSD del clúster, verique que el clúster tiene más espacio libreen disco que el disco del OSD que va a eliminar. Tenga en cuenta que, si se elimina un OSD,todo el clúster se reequilibra.
1. Identique qué OSD desea eliminar obteniendo su ID:
cephuser@adm > ceph orch ps --daemon_type osdNAME HOST STATUS REFRESHED AGE VERSIONosd.0 target-ses-090 running (3h) 7m ago 3h 15.2.7.689 ...osd.1 target-ses-090 running (3h) 7m ago 3h 15.2.7.689 ...osd.2 target-ses-090 running (3h) 7m ago 3h 15.2.7.689 ...osd.3 target-ses-090 running (3h) 7m ago 3h 15.2.7.689 ...
2. Elimine uno o varios OSD del clúster:
cephuser@adm > ceph orch osd rm OSD1_ID OSD2_ID ...
Por ejemplo:
cephuser@adm > ceph orch osd rm 1 2
134 Eliminación de OSD SES 7
3. Puede consultar el estado de la operación de eliminación:
cephuser@adm > ceph orch osd rm statusOSD_ID HOST STATE PG_COUNT REPLACE FORCE STARTED_AT2 cephadm-dev done, waiting for purge 0 True False 2020-07-17 13:01:43.1476843 cephadm-dev draining 17 False True 2020-07-17 13:01:45.1621584 cephadm-dev started 42 False True 2020-07-17 13:01:45.162158
13.4.4.1 Detención de la eliminación de OSD
Después de programar la eliminación de un OSD, puede detener la eliminación si es necesario.El siguiente comando restablecerá el estado inicial del OSD y lo eliminará de la cola:
cephuser@adm > ceph orch osd rm stop OSD_SERVICE_ID
13.4.5 Sustitución de OSD
Para sustituir un OSD conservando su ID, ejecute:
cephuser@adm > ceph orch osd rm OSD_SERVICE_ID --replace
Por ejemplo:
cephuser@adm > ceph orch osd rm 4 --replace
Sustituir un OSD es igual que eliminar un OSD (consulte la Sección 13.4.4, “Eliminación de OSD”
para obtener más información), con la excepción de que el OSD no se elimina permanentementede la jerarquía de CRUSH y se le asigna un indicador destroyed .
El indicador destroyed se utiliza para determinar los ID de OSD que se reutilizarán durante lasiguiente distribución de OSD. A los discos recién añadidos que coincidan con la especicaciónDriveGroups (consulte la Sección 13.4.3, “Adición de OSD mediante la especificación DriveGroups” paraobtener más información) se les asignarán los ID de OSD de su equivalente sustituido.
SugerenciaAl añadir la opción --dry-run no se ejecutará la sustitución real, pero se mostrarán lospasos que se llevarían a cabo normalmente.
135 Sustitución de OSD SES 7
13.5 Traslado del master de Salt a un nodo nuevoSi necesita sustituir el host del master de Salt por uno nuevo, siga estos pasos:
1. Exporte la conguración del clúster y realice una copia de seguridad del archivoJSON exportado. Más detalles en el Libro “Guía de distribución”, Capítulo 5 “Distribución con
cephadm”, Sección 5.3.2.15 “Exportación de configuraciones de clúster”
2. Si el master de Salt antiguo es también el único nodo de administración del clúster, traslademanualmente /etc/ceph/ceph.client.admin.keyring y /etc/ceph/ceph.conf alnuevo master de Salt.
3. Detenga e inhabilite el servicio systemd del master de Salt en el nodo del master de Saltantiguo:
root@master # systemctl stop salt-master.serviceroot@master # systemctl disable salt-master.service
4. Si el nodo del master de Salt antiguo ya no está en el clúster, detenga e inhabilite tambiénel servicio systemd del minion de Salt:
root@master # systemctl stop salt-minion.serviceroot@master # systemctl disable salt-minion.service
Avisono detenga ni inhabilite salt-minion.service si el nodo del master de Saltantiguo tiene algún daemon de Ceph (MON, MGR, OSD, MDS, pasarela, supervisión)en ejecución.
5. Instale SUSE Linux Enterprise Server 15 SP2 en el nuevo master de Salt siguiendo elprocedimiento descrito en el Libro “Guía de distribución”, Capítulo 5 “Distribución con cephadm”,
Sección 5.1 “Instalación y configuración de SUSE Linux Enterprise Server”.
Sugerencia: transición de los minions de SaltPara simplicar la transición de los minions de Salt al nuevo master de Salt, eliminela clave pública del master de Salt original de cada minion:
root@minion > rm /etc/salt/pki/minion/minion_master.pub
136 Traslado del master de Salt a un nodo nuevo SES 7
root@minion > systemctl restart salt-minion.service
6. Instale el paquete salt-master y, si procede, el paquete salt-minion en el nuevomaster de Salt.
7. Instale ceph-salt en el nuevo nodo del master de Salt:
root@master # zypper install ceph-saltroot@master # systemctl restart salt-master.serviceroot@master # salt '*' saltutil.sync_all
ImportanteAsegúrese de ejecutar los tres comandos antes de continuar. Los comandos sonidempotentes; no importa si se repiten.
8. Incluya el nuevo master de Salt en el clúster, como se describe en el Libro “Guía de
distribución”, Capítulo 5 “Distribución con cephadm”, Sección 5.3.1 “Instalación de ceph-salt”,el Libro “Guía de distribución”, Capítulo 5 “Distribución con cephadm”, Sección 5.3.2.2 “Adición
de minions de Salt” y el Libro “Guía de distribución”, Capítulo 5 “Distribución con cephadm”,
Sección 5.3.2.4 “Especificación del nodo de administración”.
9. Importe la copia de seguridad de la conguración del clúster y aplíquela:
root@master # ceph-salt import CLUSTER_CONFIG.jsonroot@master # ceph-salt apply
ImportanteCambie el nombre del minion del master de Salt minion id del archivoCLUSTER_CONFIG.json exportado antes de importarlo.
13.6 Actualización de los nodos del clúster
Para mantener actualizados los nodos del clúster de Ceph, aplique actualizaciones periódicas.
137 Actualización de los nodos del clúster SES 7
13.6.1 Repositorios de software
Antes de aplicar al clúster los paquetes de software más recientes como parches, compruebe quetodos los nodos del clúster tienen acceso a los repositorios relevantes. Consulte el Libro “Guía
de distribución”, Capítulo 7 “Actualización desde una versión anterior”, Sección 7.1.5.1 “Repositorios de
software” para obtener una lista completa de los repositorios necesarios.
13.6.2 División en etapas del repositorio
Si utiliza una herramienta de división en etapas (por ejemplo, SUSE Manager, o la herramientade gestión de repositorios o RMT) que provea repositorios de software a los nodos del clúster,verique que las etapas de los repositorios "de actualizaciones" de SUSE Linux Enterprise Servery SUSE Enterprise Storage se crean en el mismo momento.
Se recomienda encarecidamente utilizar una herramienta de división en etapas para aplicarparches con los niveles de parches inmovilizados o preconfigurados . Esto garantiza quelos nuevos nodos que se unen al clúster tengan el mismo nivel de parche que los nodos que ya seejecutan en el clúster. De ese modo, no será necesario aplicar los parches más recientes a todoslos nodos del clúster antes de que los nuevos nodos se puedan unir al clúster.
13.6.3 Tiempo de inactividad de servicios de Ceph
Dependiendo de la conguración, los nodos del clúster podrían reiniciarse durante laactualización. Si hay un punto único de error para servicios como Object Gateway, SambaGateway, NFS Ganesha o iSCSI, los equipos cliente podrían desconectarse temporalmente de losservicios cuyos nodos se van a reiniciar.
13.6.4 Ejecución de la actualización
Para actualizar los paquetes de software de todos los nodos del clúster a la versión más reciente,ejecute el comando siguiente:
root@master # ceph-salt update
138 Repositorios de software SES 7
13.7 Actualización de CephPuede indicar a cephadm que actualice Ceph a partir de una versión de corrección de erroresa otra. La actualización automatizada de los servicios de Ceph respeta el orden recomendado:comienza con Ceph Managers, después Ceph Monitors y continúa con otros servicios como CephOSD, servidores de metadatos y Object Gateways. Cada daemon solo se reinicia después de queCeph indique que el clúster seguirá estando disponible.
NotaEl siguiente procedimiento de actualización utiliza el comando ceph orch upgrade .Tenga en cuenta que las instrucciones siguientes detallan cómo actualizar el clúster deCeph con una versión de producto (por ejemplo, una actualización de mantenimiento),pero no proporcionan instrucciones sobre cómo actualizar el clúster de una versión deproducto a otra.
13.7.1 Inicio de la actualización
Antes de iniciar la actualización, compruebe que todos los nodos están en línea y que el clústerfunciona correctamente:
cephuser@adm > cephadm shell -- ceph -s
Para actualizar a una versión de Ceph especíca:
cephuser@adm > ceph orch upgrade start --image REGISTRY_URL
Por ejemplo:
cephuser@adm > ceph orch upgrade start --image registry.suse.com/ses/7/ceph/ceph:latest
Actualice los paquetes en los hosts:
cephuser@adm > ceph-salt update
13.7.2 Supervisión de la actualización
Ejecute el comando siguiente para determinar si hay una actualización en curso:
cephuser@adm > ceph orch upgrade status
139 Actualización de Ceph SES 7
Mientras la actualización está en curso, verá una barra de progreso en el estado de Ceph:
cephuser@adm > ceph -s[...] progress: Upgrade to registry.suse.com/ses/7/ceph/ceph:latest (00h 20m 12s) [=======.....................] (time remaining: 01h 43m 31s)
También puede ver el registro de cephadm:
cephuser@adm > ceph -W cephadm
13.7.3 Cancelación de una actualización
Puede detener el proceso de actualización en cualquier momento:
cephuser@adm > ceph orch upgrade stop
13.8 Detención o reinicio del clústerEn algunos casos, puede ser necesario detener o reiniciar el clúster completo. Recomendamoscomprobar atentamente las dependencias de los servicios en ejecución. Los siguientes pasos sepueden usar como esquema de inicio y detención del clúster:
1. Indique al clúster de Ceph que no marque los OSD como "out":
cephuser@adm > ceph osd set noout
2. Detenga los daemons y los nodos en el siguiente orden:
1. Clientes de almacenamiento
2. Gateways, por ejemplo, NFS Ganesha u Object Gateway
3. Servidor de metadatos
4. Ceph OSD
5. Ceph Manager
6. Ceph Monitor
140 Cancelación de una actualización SES 7
3. Si es necesario, realice las tareas de mantenimiento.
4. Inicie los nodos y los servidores en el orden inverso al del proceso de apagado:
1. Ceph Monitor
2. Ceph Manager
3. Ceph OSD
4. Servidor de metadatos
5. Gateways, por ejemplo, NFS Ganesha u Object Gateway
6. Clientes de almacenamiento
5. Elimine el indicador de noout:
cephuser@adm > ceph osd unset noout
13.9 Eliminación de un clúster de Ceph completoEl comando ceph-salt purge elimina todo el clúster de Ceph. Si hay más clústeres de Cephdistribuidos, se limpia el noticado por ceph -s . De esta manera, puede limpiar el entorno delclúster cuando pruebe diferentes conguraciones.
Para evitar la supresión accidental, la orquestación comprueba si la seguridad está desactivada.Puede desactivar las medidas de seguridad y eliminar el clúster de Ceph ejecutando:
root@master # ceph-salt disengage-safetyroot@master # ceph-salt purge
141 Eliminación de un clúster de Ceph completo SES 7
14 Funcionamiento de los servicios de Ceph
Puede hacer funcionar los servicios de Ceph en el nivel de los daemons, los nodos o los clústeres.Según el enfoque que necesite, utilice cephadm o el comando systemctl .
14.1 Funcionamiento de servicios individualesSi necesita hacer funcionar un servicio individual, identifíquelo primero:
cephuser@adm > ceph orch psNAME HOST STATUS REFRESHED [...]mds.my_cephfs.ses-min1.oterul ses-min1 running (5d) 8m agomgr.ses-min1.gpijpm ses-min1 running (5d) 8m agomgr.ses-min2.oopvyh ses-min2 running (5d) 8m agomon.ses-min1 ses-min1 running (5d) 8m agomon.ses-min2 ses-min2 running (5d) 8m agomon.ses-min4 ses-min4 running (5d) 7m agoosd.0 ses-min2 running (61m) 8m agoosd.1 ses-min3 running (61m) 7m agoosd.2 ses-min4 running (61m) 7m agorgw.myrealm.myzone.ses-min1.kwwazo ses-min1 running (5d) 8m agorgw.myrealm.myzone.ses-min2.jngabw ses-min2 error 8m ago
Para identicar un servicio en un nodo especíco, ejecute:
ceph orch ps NODE_HOST_NAME
Por ejemplo:
cephuser@adm > ceph orch ps ses-min2NAME HOST STATUS REFRESHEDmgr.ses-min2.oopvyh ses-min2 running (5d) 3m agomon.ses-min2 ses-min2 running (5d) 3m agoosd.0 ses-min2 running (67m) 3m ago
SugerenciaEl comando ceph orch ps admite varios formatos de salida. Para cambiarlo, añada laopción --format FORMAT al nal, donde FORMAT es uno de estas opciones: json , json-pretty o yaml . Por ejemplo:
cephuser@adm > ceph orch ps --format yaml
142 Funcionamiento de servicios individuales SES 7
Una vez que sepa el nombre del servicio, puede iniciarlo, reiniciarlo o detenerlo:
ceph orch daemon COMMAND SERVICE_NAME
Por ejemplo, para reiniciar el servicio OSD con el ID 0, ejecute:
cephuser@adm > ceph orch daemon restart osd.0
14.2 Funcionamiento de tipos de serviciosSi necesita hacer funcionar un tipo especíco de servicio en todo el clúster de Ceph, utilice elcomando siguiente:
ceph orch COMMAND SERVICE_TYPE
Sustituya COMMAND por start , stop o restart .
Por ejemplo, el comando siguiente reinicia todos los MON del clúster, independientemente delos nodos en los que se ejecuten:
cephuser@adm > ceph orch restart mon
14.3 Funcionamiento de servicios en un único nodoMediante el comando systemctl , puede hacer funcionar los servicios y destinos de systemdrelacionados con Ceph en un único nodo.
14.3.1 Identificación de servicios y destinos
Antes de hacer funcionar los servicios y destinos de systemd relacionados con Ceph, debeidenticar los nombres de archivo de sus archivos de unidad. Los nombres de archivo de losservicios tienen el siguiente patrón:
ceph-FSID@SERVICE_TYPE.ID.service
Por ejemplo:
ceph-b4b30c6e-9681-11ea-ac39-525400d7702d@mon.doc-ses-min1.service
143 Funcionamiento de tipos de servicios SES 7
ceph-b4b30c6e-9681-11ea-ac39-525400d7702d@rgw.myrealm.myzone.doc-ses-min1.kwwazo.service
FSID
ID exclusivo del clúster de Ceph. Lo encontrará en el resultado del comando ceph fsid .
SERVICE_TYPE
El tipo de servicio, por ejemplo, osd , mon o rgw .
ID
Cadena de identicación del servicio. Para los OSD, es el número de ID del servicio. Paraotros servicios, puede ser un nombre de host del nodo o cadenas adicionales relevantespara el tipo de servicio.
SugerenciaLa parte de SERVICE_TYPE . ID es idéntica al contenido de la columna NAME del resultadodel comando ceph orch ps .
14.3.2 Funcionamiento de todos los servicios en un nodo
Al usar los destinos de systemd de Ceph, puede hacer funcionar simultáneamente todos losservicios en un nodo, o bien todos los servicios que pertenecen a un clúster identicado por suFSID .
Por ejemplo, para detener todos los servicios de Ceph en un nodo independientemente del clústeral que pertenezcan los servicios, ejecute:
root@minion > systemctl stop ceph.target
Para reiniciar todos los servicios que pertenecen a un clúster de Ceph con el IDb4b30c6e-9681-11ea-ac39-525400d7702d , ejecute:
root@minion > systemctl restart ceph-b4b30c6e-9681-11ea-ac39-525400d7702d.target
14.3.3 Funcionamiento de un servicio individual en un nodo
Después de identicar el nombre de un servicio especíco, utilícelo de la siguiente manera:
systemctl COMMAND SERVICE_NAME
144 Funcionamiento de todos los servicios en un nodo SES 7
Por ejemplo, para reiniciar un único servicio OSD con el ID 1 en un clúster con el IDb4b30c6e-9681-11ea-ac39-525400d7702d , ejecute:
root # systemctl restart [email protected]
14.3.4 Consulta del estado del servicio
Puede consultar systemd para conocer el estado de los servicios. Por ejemplo:
root # systemctl status [email protected]
14.4 Apagado y reinicio de todo el clúster de CephEs posible que sea necesario apagar y reiniciar el clúster en caso de que se vaya a producir uncorte de energía programado. Para detener todos los servicios relacionados con Ceph y reiniciarsin problemas, siga los pasos siguientes.
PROCEDIMIENTO 14.1: APAGADO DE TODO EL CLÚSTER DE CEPH
1. Apague o desconecte cualquier cliente que acceda al clúster.
2. Para evitar que CRUSH reequilibre automáticamente el clúster, dena el clúster en noout :
cephuser@adm > ceph osd set noout
3. Detenga todos los servicios de Ceph en todos los nodos del clúster:
root@master # ceph-salt stop
4. todos los nodos del clúster:
root@master # salt -G 'ceph-salt:member' cmd.run "shutdown -h"
PROCEDIMIENTO 14.2: INICIO DE TODO EL CLÚSTER DE CEPH
1. Encienda el nodo de administración.
2. Encienda los nodos de Ceph Monitor.
3. Encienda los nodos de OSD de Ceph.
145 Consulta del estado del servicio SES 7
4. Anule la denición del indicador noout denido anteriormente:
root@master # ceph osd unset noout
5. Encienda todas las pasarelas conguradas.
6. Encienda o conecte los clientes del clúster.
146 Apagado y reinicio de todo el clúster de Ceph SES 7
15 Copia de seguridad y recuperación
En este capítulo se explica de qué partes del clúster de Ceph se debe realizar una copia deseguridad para poder restaurarlo.
15.1 Copia de seguridad de la configuración y losdatos del clúster
15.1.1 Copia de seguridad de la configuración de ceph-salt
Exporte la conguración del clúster. Encontrará más información en Libro “Guía de distribución”,
Capítulo 5 “Distribución con cephadm”, Sección 5.3.2.15 “Exportación de configuraciones de clúster”.
15.1.2 Copia de seguridad de la configuración de Ceph
Realice una copia de seguridad del directorio /etc/ceph . Contiene conguración crucial delclúster. Por ejemplo, necesitará una copia de seguridad de /etc/ceph cuando deba sustituirel nodo de administración.
15.1.3 Copia de seguridad de la configuración de Salt
Debe realizar una copia de seguridad del directorio /etc/salt/ . Contiene los archivos deconguración de Salt, por ejemplo la clave del master 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.
147 Copia de seguridad de la configuración y los datos del clúster SES 7
15.1.4 Copia de seguridad de configuraciones personalizadas
Datos y personalizaciones de Prometheus.
Personalizaciones de Grafana.
Cambios manuales en la conguración de iSCSI.
Claves de ceph.
Mapa y reglas de CRUSH. Guarde el mapa de CRUSH descompilado, incluidas las reglasde CRUSH, en crushmap-backup.txt ejecutando el siguiente comando:
cephuser@adm > ceph osd getcrushmap | crushtool -d - -o crushmap-backup.txt
Conguración de Samba Gateway. Si utiliza una única pasarela, realice una copia deseguridad de /etc/samba/smb.conf . Si utiliza una conguración de alta disponibilidad,realice también una copia de seguridad de los archivos de conguración de CTDB yPacemaker. Consulte el Capítulo 24, Exportación de datos de Ceph a través de Samba para verdetalles sobre la conguración que se usa en las pasarelas Samba Gateway.
Conguración de NFS Ganesha. Solo se necesita si se utiliza una conguración de altadisponibilidad. Consulte el Capítulo 25, NFS Ganesha para ver detalles sobre la conguraciónque se usa en NFS Ganesha.
15.2 Restauración de un nodo de CephEl procedimiento para recuperar un nodo de la copia de seguridad consiste en volver a instalarel nodo, sustituir sus archivos de conguración y, a continuación, volver a organizar el clústerpara que se vuelva a añadir el nodo de sustitución.
Si necesita volver a distribuir el nodo de administración, consulte la Sección 13.5, “Traslado del
master de Salt a un nodo nuevo”.
En el caso de los minions, suele ser más fácil volver a crearlos y distribuirlos.
1. Vuelva a instalar el nodo. Encontrará más información en Libro “Guía de distribución”,
Capítulo 5 “Distribución con cephadm”, Sección 5.1 “Instalación y configuración de SUSE Linux
Enterprise Server”
2. Instale Salt. Encontrará más información en Libro “Guía de distribución”, Capítulo 5
“Distribución con cephadm”, Sección 5.2 “Distribución de Salt”
148 Copia de seguridad de configuraciones personalizadas SES 7
3. Después de restaurar el directorio /etc/salt desde una copia de seguridad, habilite yreinicie los servicios de Salt aplicables, por ejemplo:
root@master # systemctl enable salt-masterroot@master # systemctl start salt-masterroot@master # systemctl enable salt-minionroot@master # systemctl start salt-minion
4. Elimine la clave principal pública del nodo del master de Salt de todos los minions.
root@master # rm /etc/salt/pki/minion/minion_master.pubroot@master # systemctl restart salt-minion
5. Restaure cualquier elemento que fuera local en el nodo de administración.
6. Importe la conguración del clúster desde el archivo JSON exportado anteriormente.Consulte el Libro “Guía de distribución”, Capítulo 5 “Distribución con cephadm”, Sección 5.3.2.15
“Exportación de configuraciones de clúster” para obtener más información.
7. Aplique la conguración de clúster importada:
root@master # ceph-salt apply
149 Restauración de un nodo de Ceph SES 7
16 Supervisión y alertas
En SUSE Enterprise Storage 7, cephadm distribuye una pila de alertas y supervisión. Los usuariosdeben denir los servicios (como Prometheus, Alertmanager y Grafana) que desean distribuircon cephadm en un archivo de conguración YAML, o bien pueden utilizar la interfaz de línea decomandos para distribuirlos. Cuando se distribuyen varios servicios del mismo tipo, se distribuyeuna conguración de alta disponibilidad. El exportador de nodos es una excepción a esta regla.
Los siguientes servicios de supervisión se pueden distribuir con cephadm:
Prometheus es el kit de herramientas de supervisión y alertas. Recopila los datosproporcionados por los exportadores de Prometheus y activa alertas preconguradas si sealcanzan los umbrales predenidos.
Alertmanager gestiona las alertas enviadas por el servidor de Prometheus. Desduplica,agrupa y dirige las alertas al receptor correcto. Por defecto, Ceph Dashboard se conguraautomáticamente como receptor.
Grafana es el software de visualización y alertas. Esta pila de supervisión no utiliza lafunción de alertas de Grafana. Para las alertas, se utiliza Alertmanager.
El exportador de nodos es un exportador de Prometheus que proporciona datos sobreel nodo en el que está instalado. Se recomienda instalar el exportador de nodos en todoslos nodos.
El módulo de gestor de Prometheus proporciona un exportador de Prometheus para pasar loscontadores de rendimiento de Ceph desde el punto de recopilación en ceph-mgr .
La conguración de Prometheus, incluidos los destinos de scrape (métricas que proporcionandaemons), se congura automáticamente mediante cephadm. cephadm también distribuye unalista de alertas por defecto, por ejemplo, error de estado , 10% de OSD inactivos o pgsinactivos .
Por defecto, el tráco a Grafana se cifra con TLS. Puede proporcionar su propio certicado TLSo utilizar uno autormado. Si no se ha congurado ningún certicado personalizado antes dela distribución de Grafana, se crea y se congura automáticamente un certicado autormadopara Grafana.
Los certicados personalizados para Grafana se pueden congurar mediante los comandossiguientes:
cephuser@adm > ceph config-key set mgr/cephadm/grafana_key -i $PWD/key.pem
150 SES 7
cephuser@adm > ceph config-key set mgr/cephadm/grafana_crt -i $PWD/certificate.pem
Alertmanager gestiona las alertas enviadas por el servidor de Prometheus. Se encarga dedesduplicarlos, agruparlos y enrutarlos al receptor correcto. Las alertas se pueden silenciarmediante el Alertmanager, pero los silencios también se pueden gestionar mediante CephDashboard.
Se recomienda que el exportador de nodos se distribuya en todos los nodos. Esto se puedehacer mediante el archivo monitoring.yaml con el tipo de servicio node-exporter . Consulteel Libro “Guía de distribución”, Capítulo 5 “Distribución con cephadm”, Sección 5.4.3.8 “Distribución de la
pila de supervisión” para obtener más información sobre la distribución de servicios.
16.1 Configuración de imágenes personalizadas olocales
SugerenciaEn esta sección se describe cómo cambiar la conguración de las imágenes de contenedorque se utilizan al distribuir o actualizar los servicios. No incluye los comandos necesariospara distribuir o volver a distribuir servicios.
El método recomendado para distribuir la pila de supervisión consiste en aplicar suespecicación como se describe en el Libro “Guía de distribución”, Capítulo 5 “Distribución con
cephadm”, Sección 5.4.3.8 “Distribución de la pila de supervisión”.
Para distribuir imágenes de contenedor personalizadas o locales, las imágenes deben denirseen cephadm. Para ello, deberá ejecutar el comando siguiente:
cephuser@adm > ceph config set mgr mgr/cephadm/OPTION_NAME VALUE
Donde OPTION_NAME es uno de estos nombres:
container_image_prometheus
container_image_node_exporter
container_image_alertmanager
container_image_grafana
151 Configuración de imágenes personalizadas o locales SES 7
Si no se ha denido ninguna opción o si se ha eliminado el ajuste, se utilizan las imágenessiguientes como VALUE :
registry.suse.com/caasp/v4.5/prometheus-server:2.18.0
registry.suse.com/caasp/v4.5/prometheus-node-exporter:0.18.1
registry.suse.com/caasp/v4.5/prometheus-alertmanager:0.16.2
registry.suse.com/ses/7/ceph/grafana:7.0.3
Por ejemplo:
cephuser@adm > ceph config set mgr mgr/cephadm/container_image_prometheus prom/prometheus:v1.4.1
NotaAl denir una imagen personalizada, el valor por defecto se anula (pero no se sobrescribe).El valor por defecto cambia cuando hay actualizaciones disponibles. Al denir unaimagen personalizada, no podrá actualizar automáticamente el componente para el queha denido la imagen personalizada. Deberá actualizar manualmente la conguración (elnombre de la imagen y la etiqueta) para poder instalar actualizaciones.
Si decide seguir las recomendaciones, puede restablecer la imagen personalizada que hayadenido anteriormente. Después, se volverá a utilizar el valor por defecto. Utilice cephconfig rm para restablecer la opción de conguración:
cephuser@adm > ceph config rm mgr mgr/cephadm/OPTION_NAME
Por ejemplo:
cephuser@adm > ceph config rm mgr mgr/cephadm/container_image_prometheus
16.2 Actualización de los servicios de supervisiónComo se menciona en la Sección 16.1, “Configuración de imágenes personalizadas o locales”, cephadmincluye las URL de las imágenes de contenedor recomendadas y probadas, que se utilizan pordefecto.
152 Actualización de los servicios de supervisión SES 7
Al actualizar los paquetes de Ceph, se pueden incluir nuevas versiones de estas URL. Esto soloactualiza de dónde se extraen las imágenes del contenedor, pero no actualiza ningún servicio.
Después de actualizar las URL de las nuevas imágenes de contenedor, ya sea manualmentecomo se describe en la Sección 16.1, “Configuración de imágenes personalizadas o locales”, oautomáticamente mediante una actualización del paquete de Ceph, los servicios de supervisiónse pueden actualizar.
Para ello, utilice ceph orch redeploy así:
cephuser@adm > ceph orch redeploy node-exportercephuser@adm > ceph orch redeploy prometheuscephuser@adm > ceph orch redeploy alertmanagercephuser@adm > ceph orch redeploy grafana
Actualmente no existe un comando único para actualizar todos los servicios de supervisión. Elorden en el que se actualizan estos servicios no es importante.
NotaSi utiliza imágenes de contenedor personalizadas, las URL especicadas para los serviciosde supervisión no cambiarán automáticamente si se actualizan los paquetes de Ceph. Siha especicado imágenes de contenedor personalizadas, deberá especicar manualmentelas URL de las nuevas imágenes de contenedor. Este puede ser el caso si utiliza un registrode contenedor local.
En la Sección 16.1, “Configuración de imágenes personalizadas o locales”, encontrará las URLde las imágenes de contenedor recomendadas.
16.3 Inhabilitación de la supervisión
Para inhabilitar la pila de supervisión, ejecute los comandos siguientes:
cephuser@adm > ceph orch rm grafanacephuser@adm > ceph orch rm prometheus --force # this will delete metrics data collected so farcephuser@adm > ceph orch rm node-exportercephuser@adm > ceph orch rm alertmanagercephuser@adm > ceph mgr module disable prometheus
153 Inhabilitación de la supervisión SES 7
16.4 Configuración de GrafanaEl procesador nal de Ceph Dashboard requiere la URL de Grafana para poder vericar laexistencia de consolas de Grafana antes de que el procesador frontal las cargue. Debido a cómose implementa Grafana en Ceph Dashboard, esto signica que se requieren dos conexiones enfuncionamiento para poder ver los grácos de Grafana en Ceph Dashboard:
El procesador nal (módulo Ceph MGR) debe vericar la existencia del gráco solicitado.Si esta petición se realiza correctamente, el procesador frontal sabe que puede acceder aGrafana de forma segura.
A continuación, el procesador frontal pide los grácos de Grafana directamente desde elnavegador del usuario mediante un iframe . Se accede directamente a la instancia deGrafana sin ningún desvío a través de Ceph Dashboard.
Ahora bien, puede darse el caso de que su entorno diculte el acceso directo del navegador delusuario a la URL congurada en Ceph Dashboard. Para solucionar este problema, es posiblecongurar una URL independiente que se utilizará únicamente para indicar al procesador frontal(el navegador del usuario) qué URL debe utilizar para acceder a Grafana.
Para cambiar la URL que se devuelve al procesador frontal, emita el comando siguiente:
cephuser@adm > ceph dashboard set-grafana-frontend-api-url GRAFANA-SERVER-URL
Si no se dene ningún valor para esa opción, simplemente se recurrirá al valor de la opciónGRAFANA_API_URL , que cephadm dene de forma automática y actualiza periódicamente. Si sedene, indicará al navegador que utilice esta URL para acceder a Grafana.
16.5 Configuración del módulo de gestor dePrometheusEl módulo de gestor de Prometheus es un módulo de Ceph que amplía la funcionalidad de Ceph.El módulo lee metadatos de Ceph acerca de su estado y actividad, proporcionando los datosextraídos en un formato que Prometheus puede consumir.
NotaEs necesario reiniciar el módulo de gestor de Prometheus para que se apliquen los cambiosde conguración.
154 Configuración de Grafana SES 7
16.5.1 Configuración de la interfaz de red
Por defecto, el módulo de gestor de Prometheus acepta peticiones HTTP en el puerto 9283en todas las direcciones IPv4 e IPv6 del host. El puerto y la dirección de escucha se puedencongurar con ceph config-key set , con las claves mgr/prometheus/server_addr y mgr/prometheus/server_port . Este puerto está indicado en el registro de Prometheus.
Para actualizar server_addr , ejecute el comando siguiente:
cephuser@adm > ceph config set mgr mgr/prometheus/server_addr 0.0.0.0
Para actualizar server_port , ejecute el comando siguiente:
cephuser@adm > ceph config set mgr mgr/prometheus/server_port 9283
16.5.2 Configuración de scrape_interval
Por defecto, el módulo de gestor de Prometheus se congura con un intervalo de scrape de15 segundos. No se recomienda utilizar un intervalo inferior a 10 segundos. Para denir unintervalo diferente en el módulo de Prometheus, dena el valor que desee en scrape_interval :
ImportantePara que funcione correctamente y no se produzcan problemas, el valor descrape_interval de este módulo siempre debe coincidir con el intervalo de scrape dePrometheus.
cephuser@adm > ceph config set mgr mgr/prometheus/scrape_interval 15
16.5.3 Configuración de caché
En clústeres grandes (de más de 1000 OSD), el tiempo necesario para obtener las métricas puedeser considerable. Sin la memoria caché, el módulo de gestor de Prometheus puede sobrecargarel gestor y provocar que las instancias de Ceph Manager no respondan o se bloqueen. Comoresultado, la memoria caché está habilitada por defecto y no se puede inhabilitar, pero estosignica que la caché puede quedarse obsoleta. Se considera obsoleta cuando el tiempo paraobtener las métricas de Ceph supera el valor de scrape_interval congurado.
155 Configuración de la interfaz de red SES 7
Si este es el caso, se registrará una advertencia y el módulo:
Responde con un código de estado HTTP 503 (servicio no disponible).
Devuelve el contenido de la caché, aunque esté obsoleta.
Este comportamiento se puede congurar mediante los comandos ceph config set .
Para pedirle al módulo que responda con la indicación de que los datos posiblemente esténobsoletos, añada return :
cephuser@adm > ceph config set mgr mgr/prometheus/stale_cache_strategy return
Para pedirle al módulo que responda con servicio no disponible , añada fail :
cephuser@adm > ceph config set mgr mgr/prometheus/stale_cache_strategy fail
16.5.4 Habilitación de la supervisión de imágenes RBD
El módulo de gestor de Prometheus puede recopilar, opcionalmente, estadísticas de E/Spor imagen RBD habilitando contadores de rendimiento de OSD dinámicos. Las estadísticasse recopilan para todas las imágenes de los repositorios especicados en el parámetro deconguración mgr/prometheus/rbd_stats_pools .
El parámetro es una lista separada por comas o espacios de entradas pool[/namespace] . Sino se especica el espacio de nombres, las estadísticas se recopilan para todos los espacios denombres del repositorio.
Por ejemplo:
cephuser@adm > ceph config set mgr mgr/prometheus/rbd_stats_pools "pool1,pool2,poolN"
El módulo explora los repositorios y espacios de nombres especicados, crea una listade todas las imágenes disponibles y la actualiza periódicamente. El intervalo se puedecongurar mediante el parámetro mgr/prometheus/rbd_stats_pools_refresh_interval(en segundos) y es de 300 segundos (cinco minutos) por defecto
Por ejemplo, si cambia el intervalo de sincronización a 10 minutos:
cephuser@adm > ceph config set mgr mgr/prometheus/rbd_stats_pools_refresh_interval 600
156 Habilitación de la supervisión de imágenes RBD SES 7
16.6 Modelo de seguridad de PrometheusEl modelo de seguridad de Prometheus presupone que los usuarios que no son de conanzatienen acceso al puesto nal HTTP y los registros de Prometheus. Los usuarios que no son deconanza tienen acceso a todos los metadatos que Prometheus recopila y que se encuentran enla base de datos, además de a distinta información operativa y de depuración.
Sin embargo, la API HTTP de Prometheus está limitada a operaciones de solo lectura. Lasconguraciones no se pueden cambiar mediante la API y los secretos no se revelan. Además,Prometheus tiene medidas integradas para mitigar el impacto de los ataques de denegación deservicio.
16.7 Receptor de alertas SNMP Alertmanager dePrometheusSi desea recibir una noticación sobre las alertas de Prometheus mediante alertas SNMP, puedeinstalar el receptor de alertas SNMP Alertmanager de Prometheus a través de cephadm. Paraello, debe crear un archivo de especicación de servicio y colocación con el contenido siguiente:
NotaPara obtener más información sobre los archivos de servicio y colocación, consulte Libro
“Guía de distribución”, Capítulo 5 “Distribución con cephadm”, Sección 5.4.2 “Especificación del
servicio y la colocación”.
service_type: containerservice_id: prometheus-webhook-snmpplacement: ADD_PLACEMENT_HEREimage: registry.suse.com/ses/7/prometheus-webhook-snmp:latestargs: - "--publish 9099:9099"envs: - ARGS="--debug --snmp-host=ADD_HOST_GATEWAY_HERE" - RUN_ARGS="--metrics"EOF
Utilice esta especicación de servicio para que el servicio se ejecute con sus ajustes por defecto.
157 Modelo de seguridad de Prometheus SES 7
Debe publicar el puerto en el que escucha el receptor de Prometheus mediante el argumento delínea de comandos --publish PUERTO_DE_HOST:PUERTO_DE_CONTENEDOR cuando se ejecutael servicio, ya que el contenedor no expone automáticamente el puerto. Esto se puede hacerañadiendo las líneas siguientes a la especicación:
args: - "--publish 9099:9099"
Como alternativa, conecte el contenedor a la red del host mediante el argumento de línea decomandos --network=host .
args: - "--network=host"
Si el receptor de mensajes de alerta SNMP no está instalado en el mismo host que el contenedor,también debe especicar el nombre completo del host SNMP. Utilice la pasarela de red delcontenedor para poder recibir mensajes de alerta SNMP fuera del contenedor/host:
envs: - ARGS="--debug --snmp-host=CONTAINER_GATEWAY"
16.7.1 Configuración del servicio prometheus-webhook-snmp
El contenedor se puede congurar mediante variables de entorno o mediante un archivo deconguración.
Para las variables de entorno, utilice ARGS para denir las opciones globales y RUN_ARGS paralas opciones del comando run . Debe adaptar la especicación de servicio de la siguiente manera:
envs: - ARGS="--debug --snmp-host=CONTAINER_GATEWAY" - RUN_ARGS="--metrics --port=9101"
Para utilizar un archivo de conguración, la especicación de servicio debe adaptarse de lasiguiente forma:
files: etc/prometheus-webhook-snmp.conf: - "debug: True" - "snmp_host: ADD_HOST_GATEWAY_HERE" - "metrics: True"volume_mounts:
158 Configuración del servicio prometheus-webhook-snmp SES 7
etc/prometheus-webhook-snmp.conf: /etc/prometheus-webhook-snmp.conf
Para distribuir, ejecute el comando siguiente:
cephuser@adm > ceph orch apply -i SERVICE_SPEC_FILE
Consulte el Libro “Guía de distribución”, Capítulo 5 “Distribución con cephadm”, Sección 5.4.3
“Distribución de servicios de Ceph” para obtener más información.
16.7.2 Configuración de Alertmanager de Prometheus para SNMP
Por último, Alertmanager de Prometheus debe congurarse especícamente para las alertasSNMP. Si este servicio aún no se ha distribuido, cree un archivo de especicación de servicio.Debe sustituir IP_OR_FQDN por la dirección IP o el nombre completo del host en el que se hainstalado el receptor de alertas SNMP Alertmanager de Prometheus. Por ejemplo:
NotaSi ya ha distribuido este servicio, para asegurarse de que Alertmanager está conguradocorrectamente para SNMP, vuelva a distribuirlo con los ajustes siguientes:
service_type: alertmanager placement: hosts: - HOSTNAME webhook_configs: - 'http://IP_OR_FQDN:9099/'
Aplique la especicación de servicio con el comando siguiente:
cephuser@adm > ceph orch apply -i SERVICE_SPEC_FILE
159 Configuración de Alertmanager de Prometheus para SNMP SES 7
III Almacenamiento de datos en unclúster
17 Gestión de datos almacenados 161
18 Gestión de repositorios de almacenamiento 193
19 Repositorios codificados de borrado 215
20 Dispositivo de bloques RADOS 222
17 Gestión de datos almacenados
El algoritmo CRUSH determina cómo se deben almacenar y recuperar los datos. Para ello,calcula las ubicaciones de almacenamiento. CRUSH aporta a los clientes de Ceph la capacidad decomunicarse con los OSD directamente, en lugar de hacerlo a través de un servidor centralizadoo un intermediario. Con un método de almacenamiento y recuperación de datos determinadomediante un algoritmo, Ceph evita que haya un punto único de error, un cuello de botella derendimiento y un límite físico a su capacidad de ampliación.
CRUSH requiere un mapa del clúster y usa el mapa de CRUSH para almacenar y recuperar deforma pseudoaleatoria los datos de los OSD con una distribución uniforme de los datos por elclúster.
Los mapas de CRUSH contienen una lista de los OSD, una lista de "depósitos" para agregarlos dispositivos en ubicaciones físicas, y una lista de reglas que indican a CRUSH cómo sedeben replicar los datos en los repositorios del clúster de Ceph. Al reejar la organizaciónfísica subyacente de la instalación, CRUSH puede modelar, y por lo tanto solucionar, causaspotenciales de errores de dispositivo correlacionados. Las causas habituales suelen ser laproximidad física, una fuente de alimentación compartida y una red compartida. Mediante lacodicación de esta información en un mapa del clúster, las directivas de colocación de CRUSHpueden separar las réplicas del objeto en dominios de fallo diferentes, al tiempo que se mantienela distribución que se desea. Por ejemplo, para prepararse en caso de que se produzcan fallossimultáneos, puede ser conveniente asegurarse de que las réplicas de datos se encuentran endispositivos que utilizan diferentes estantes, bastidores, fuente de alimentación, controladoreso ubicaciones físicas.
Después de distribuir un clúster de Ceph, se genera un mapa de CRUSH por defecto. Resultaadecuado para el entorno de la zona protegida de Ceph. Sin embargo, si se distribuye un clústerde datos a gran escala, debe planicarse concienzudamente cómo desarrollar un mapa de CRUSHpersonalizado, ya que le ayudará a gestionar el clúster de Ceph, a mejorar el rendimiento y agarantizar la seguridad de los datos.
Por ejemplo, si falla un OSD, un mapa de CRUSH puede ayudarle a localizar el centro de datosfísico, la sala, la la y el bastidor del host donde se encuentra el OSD que ha fallado, en caso deque necesite asistencia técnica in situ o sustituir el hardware.
Del mismo modo, CRUSH puede ayudarle a identicar los errores más rápidamente. Por ejemplo,si todos los OSD en un bastidor determinado fallan al mismo tiempo, el error podría encontrarseen un conmutador de red o en la fuente de alimentación del bastidor, o en el conmutador dered, en lugar de estar en los propios OSD.
161 SES 7
Un mapa de CRUSH personalizado también ayuda a identicar las ubicaciones físicas dondeCeph almacena las copias redundantes de los datos si los grupos de colocación (consulte laSección 17.4, “Grupos de colocación”) asociados con un host que falla se encuentran en un estadodegradado.
Hay tres secciones principales en un mapa de CRUSH.
Los Dispositivos OSD son cualquier dispositivo de almacenamiento de objetoscorrespondiente a un daemon ceph osd .
Los Depósitos están formados por una agregación jerárquica de ubicaciones dealmacenamiento (por ejemplo, las, bastidores, hosts, etc.) y sus pesos asignados.
Los Conjuntos de reglas son una forma de seleccionar depósitos.
17.1 Dispositivos OSDPara asignar grupos de colocación a los OSD, un mapa de CRUSH requiere una lista de losdispositivos OSD (el nombre del daemon OSD). La lista de dispositivos aparece primero en elmapa de CRUSH.
#devicesdevice NUM osd.OSD_NAME class CLASS_NAME
Por ejemplo:
#devicesdevice 0 osd.0 class hdddevice 1 osd.1 class ssddevice 2 osd.2 class nvmedevice 3 osd.3class ssd
Como regla general, un daemon OSD se asigna a un solo disco.
17.1.1 Clases de dispositivos
La exibilidad del mapa de CRUSH para controlar la colocación de los datos es uno de los puntosfuertes de Ceph. También es una de las partes más difíciles de gestionar del clúster. Las clasesde dispositivos automatizan los cambios más comunes en los mapas de CRUSH que, antes, eladministrador debía realizar manualmente.
162 Dispositivos OSD SES 7
17.1.1.1 El problema de la gestión de CRUSH
Los clústeres de Ceph se crean con frecuencia con varios tipos de dispositivos dealmacenamiento: discos duros, unidades SSD, NVMe o incluso con combinaciones de estos.Llamamos a estos diferentes tipos de dispositivos de almacenamiento clases de dispositivos, paraevitar confusiones entre la propiedad type de las depósitos CRUSH (por ejemplo, host, bastidoro la; consulte la Sección 17.2, “Depósitos” para obtener detalles). Los Ceph OSD respaldados porunidades SSD son mucho más rápidos que los respaldados por discos giratorios, por lo que sonmás adecuados para ciertas cargas de trabajo. Ceph facilita la creación de repositorios RADOSpara diferentes conjuntos de datos o cargas de trabajo, así como para asignar las diferentes reglasde CRUSH que sirven para controlar la colocación de datos para esos repositorios.
FIGURA 17.1: OSDS CON CLASES DE DISPOSITIVOS MIXTOS
Sin embargo, congurar las reglas de CRUSH para colocar datos solo en una determinada clasede dispositivo resulta tedioso. Las reglas funcionan en términos de la jerarquía de CRUSH, perosi los dispositivos se mezclan en los mismos hosts o bastidores (como en la jerarquía de ejemploanterior), se mezclarán (por defecto) y aparecerán en los mismos subárboles de la jerarquía.Separarlos manualmente en árboles independientes implicaba crear varias versiones de cadanodo intermedio para cada clase de dispositivo en las versiones anteriores de SUSE EnterpriseStorage.
163 Clases de dispositivos SES 7
17.1.1.2 Clases de dispositivos
Una solución elegante que ofrece Ceph es añadir una propiedad denominada clase de dispositivoa cada OSD. Por defecto, los OSD denirán automáticamente sus clases de dispositivo como"hdd", "ssd" o "nvme", en función de las propiedades de hardware expuestas por el kernel deLinux. Estas clases de dispositivo se indican en una columna nueva del resultado del comandoceph osd tree :
cephuser@adm > ceph osd tree ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF -1 83.17899 root default -4 23.86200 host cpach 2 hdd 1.81898 osd.2 up 1.00000 1.00000 3 hdd 1.81898 osd.3 up 1.00000 1.00000 4 hdd 1.81898 osd.4 up 1.00000 1.00000 5 hdd 1.81898 osd.5 up 1.00000 1.00000 6 hdd 1.81898 osd.6 up 1.00000 1.00000 7 hdd 1.81898 osd.7 up 1.00000 1.00000 8 hdd 1.81898 osd.8 up 1.00000 1.00000 15 hdd 1.81898 osd.15 up 1.00000 1.00000 10 nvme 0.93100 osd.10 up 1.00000 1.00000 0 ssd 0.93100 osd.0 up 1.00000 1.00000 9 ssd 0.93100 osd.9 up 1.00000 1.00000
Si se produce un error al detectar automáticamente la clase de dispositivo, por ejemplo porqueel controlador del dispositivo no exponga correctamente la información sobre el dispositivomediante /sys/block , puede ajustar las clases de dispositivo desde la línea de comandos:
cephuser@adm > ceph osd crush rm-device-class osd.2 osd.3done removing class of osd(s): 2,3cephuser@adm > ceph osd crush set-device-class ssd osd.2 osd.3set osd(s) 2,3 to class 'ssd'
17.1.1.3 Definición de las reglas de colocación de CRUSH
Las reglas de CRUSH pueden restringir la colocación a una clase de dispositivo especíca. Porejemplo, puede crear un repositorio "fast" (rápido) replicado que distribuya datos solo a travésde discos SSD ejecutando el siguiente comando:
cephuser@adm > ceph osd crush rule create-replicated RULE_NAME ROOT FAILURE_DOMAIN_TYPE DEVICE_CLASS
164 Clases de dispositivos SES 7
Por ejemplo:
cephuser@adm > ceph osd crush rule create-replicated fast default host ssd
Cree un repositorio denominado "fast_pool" y asígnelo a la regla "fast":
cephuser@adm > ceph osd pool create fast_pool 128 128 replicated fast
El proceso para crear reglas codicadas de borrado es ligeramente diferente. En primer lugar,cree un perl codicado de borrado que incluya una propiedad para la clase de dispositivodeseada. A continuación, utilice ese perl al crear el repositorio codicado de borrado:
cephuser@adm > ceph osd erasure-code-profile set myprofile \ k=4 m=2 crush-device-class=ssd crush-failure-domain=hostcephuser@adm > ceph osd pool create mypool 64 erasure myprofile
En caso de que necesite editar manualmente el mapa de CRUSH para personalizar la regla, lasintaxis se ha ampliado para permitir que se especique la clase de dispositivo. Por ejemplo, laregla de CRUSH generada por los comandos anteriores tiene el siguiente aspecto:
rule ecpool { id 2 type erasure min_size 3 max_size 6 step set_chooseleaf_tries 5 step set_choose_tries 100 step take default class ssd step chooseleaf indep 0 type host step emit}
La diferencia importante aquí es que el comando "take" incluye el sujo adicional "classNOMBRE_CLASE" .
17.1.1.4 Comandos adicionales
Para mostrar las clases de dispositivo utilizadas en un mapa de CRUSH, ejecute:
cephuser@adm > ceph osd crush class ls[ "hdd",
165 Clases de dispositivos SES 7
"ssd"]
Para mostrar las reglas de CRUSH existentes, ejecute:
cephuser@adm > ceph osd crush rule lsreplicated_rulefast
Para ver los detalles de la regla de CRUSH denominada "fast", ejecute:
cephuser@adm > ceph osd crush rule dump fast{ "rule_id": 1, "rule_name": "fast", "ruleset": 1, "type": 1, "min_size": 1, "max_size": 10, "steps": [ { "op": "take", "item": -21, "item_name": "default~ssd" }, { "op": "chooseleaf_firstn", "num": 0, "type": "host" }, { "op": "emit" } ]}
Para mostrar los OSD que pertenecen a una clase "ssd", ejecute:
cephuser@adm > ceph osd crush class ls-osd ssd01
166 Clases de dispositivos SES 7
17.1.1.5 Migración de una regla de SSD heredada a las clases de dispositivos
En versiones de SUSE Enterprise Storage anteriores a la 5 era necesario editar manualmente elmapa de CRUSH y mantener una jerarquía paralela para cada tipo de dispositivo especializado(como SSD) para poder escribir reglas que se aplicaran a esos dispositivos. Desde SUSE EnterpriseStorage 5, la característica de clase de dispositivo hace que escribir esas reglas se pueda hacerde forma transparente.
Es posible transformar una regla y una jerarquía heredadas a las nuevas reglas basadas en clasesmediante el comando crushtool . Hay varios tipos de transformación posibles:
crushtool ‑‑reclassify‑root ROOT_NAME DEVICE_CLASS
Este comando toma todos los elementos de la jerarquía situados bajo ROOT_NAME (nombrede raíz) y ajusta las reglas que hacen referencia a esa raíz mediante
take ROOT_NAME
y las sustituya por
take ROOT_NAME class DEVICE_CLASS
Vuelve a numerar los depósitos para que los ID anteriores se utilicen para el "árbol paralelo"de la clase especicada. Como consecuencia, no se produce ningún movimiento de datos.
EJEMPLO 17.1: crushtool ‑‑reclassify‑root
Veamos la siguiente regla existente:
rule replicated_ruleset { id 0 type replicated min_size 1 max_size 10 step take default step chooseleaf firstn 0 type rack step emit}
Si reclasica la raíz "default" como clase "hdd", la regla se convertirá en:
rule replicated_ruleset { id 0 type replicated min_size 1
167 Clases de dispositivos SES 7
max_size 10 step take default class hdd step chooseleaf firstn 0 type rack step emit}
crushtool ‑‑set‑subtree‑class BUCKET_NAME DEVICE_CLASS
Este método marca todos los dispositivos del subárbol enraizados en BUCKET_NAME con laclase de dispositivo especicada.‑‑set-subtree-class se utiliza normalmente junto con la opción ‑‑reclassify-rootpara garantizar que todos los dispositivos de esa raíz están etiquetados con la clase correcta.Sin embargo, algunos de esos dispositivos pueden tener una clase diferente de formaintencionada y, por lo tanto, no desea volver a etiquetarlos. En tales casos, excluya laopción ‑‑set-subtree-class . Tenga en cuenta que dicha reasignación no será perfecta,ya que la regla anterior se distribuye entre dispositivos de varias clases, pero las reglasajustadas solo se asignan a los dispositivos de la clase de dispositivo especicada.
crushtool ‑‑reclassify‑bucket MATCH_PATTERN DEVICE_CLASS DEFAULT_PATTERN
Este método permite combinar una jerarquía paralela especíca de tipo con la jerarquíanormal. Por ejemplo, muchos usuarios tienen mapas de CRUSH similares a los siguientes:
EJEMPLO 17.2: crushtool ‑‑reclassify‑bucket
host node1 { id -2 # do not change unnecessarily # weight 109.152 alg straw hash 0 # rjenkins1 item osd.0 weight 9.096 item osd.1 weight 9.096 item osd.2 weight 9.096 item osd.3 weight 9.096 item osd.4 weight 9.096 item osd.5 weight 9.096 [...]}
host node1-ssd { id -10 # do not change unnecessarily # weight 2.000 alg straw hash 0 # rjenkins1 item osd.80 weight 2.000 [...]
168 Clases de dispositivos SES 7
}
root default { id -1 # do not change unnecessarily alg straw hash 0 # rjenkins1 item node1 weight 110.967 [...]}
root ssd { id -18 # do not change unnecessarily # weight 16.000 alg straw hash 0 # rjenkins1 item node1-ssd weight 2.000 [...]}
Esta función reclasica cada depósito que coincide con un patrón determinado. El patrónpuede ser de tipo %sufijo o prefijo% . En el ejemplo anterior, se usaría el patrón %-ssd .Para cada depósito coincidente, la parte restante del nombre que coincida con el comodín"%" especica el depósito base. Todos los dispositivos del depósito coincidente se etiquetancon la clase de dispositivo especicada y, a continuación, se mueven al depósito base. Si eldepósito base no existe (por ejemplo, si "node12-ssd" existe, pero "node12" no), se crea yse vincula debajo del depósito padre por defecto especicado. Los ID de depósito antiguosse conservan para los nuevos depósitos paralelos a n de evitar que haya que mover datos.Las reglas con los pasos take (tomar) que hagan referencia a depósitos antiguos se ajustan.
crushtool ‑‑reclassify‑bucket BUCKET_NAME DEVICE_CLASS BASE_BUCKET
Puede utilizar la opción ‑‑reclassify-bucket sin un comodín para asignar un solodepósito. Por ejemplo, en el ejemplo anterior, queremos que el depósito "ssd" se asigne aldepósito por defecto.El comando nal para convertir el mapa compuesto por los fragmentos anteriores seríael siguiente:
cephuser@adm > ceph osd getcrushmap -o originalcephuser@adm > crushtool -i original --reclassify \ --set-subtree-class default hdd \ --reclassify-root default hdd \ --reclassify-bucket %-ssd ssd default \ --reclassify-bucket ssd ssd default \ -o adjusted
169 Clases de dispositivos SES 7
Para vericar que la conversión sea correcta, hay una opción ‑‑compare que pruebauna muestra cuantiosa de entradas al mapa de CRUSH y comprueba si vuelve a salir elmismo resultado. Estas entradas se controlan mediante las mismas opciones que se aplicana ‑‑test . Para el ejemplo anterior, el comando sería el siguiente:
cephuser@adm > crushtool -i original --compare adjustedrule 0 had 0/10240 mismatched mappings (0)rule 1 had 0/10240 mismatched mappings (0)maps appear equivalent
SugerenciaSi hubiera diferencias, vería qué proporción de entradas se reasignan entreparéntesis.
Si el mapa de CRUSH ajustado es el que desea, puede aplicarlo al clúster:
cephuser@adm > ceph osd setcrushmap -i adjusted
17.1.1.6 información adicional
Encontrará más detalles sobre los mapas de CRUSH en la Sección 17.5, “Manipulación del mapa
de CRUSH”.
Encontrará más detalles sobre los repositorios de Ceph en general en el Capítulo 18, Gestión de
repositorios de almacenamiento.
Encontrará más detalles sobre los repositorios codicados de borrado en el Capítulo 19,
Repositorios codificados de borrado.
17.2 DepósitosLos mapas de CRUSH contienen una lista de los OSD, que se pueden organizar en unaestructura de árbol de los depósitos para agregar los dispositivos en ubicaciones físicas. Los OSDindividuales forman las hojas del árbol.
0 osd Un dispositivo u OSD especíco ( osd.1 , osd.2 , etc.).
1 host El nombre de un host que contiene uno o más OSD.
170 Depósitos SES 7
2 chassis Identicador del chasis del bastidor que contiene elhost .
3 rack El bastidor de un equipo. El valor por defecto esunknownrack .
4 row Una la de una serie de bastidores.
5 pdu Abreviatura de "Power Distribution Unit", unidad dedistribución de energía.
6 pod Abreviatura de "Point of Delivery", punto de entrega. Eneste contexto, un grupo de PDU o un grupo de las debastidores.
7 room Una sala que contiene las de bastidores.
8 datacenter Un centro de datos físico que contiene una o más salas.
9 region Región geográca del mundo (por ejemplo, NAM, LAM,EMEA, APAC, etc.).
10 root El nodo raíz del árbol de depósitos OSD (normalmentedenido como default ).
SugerenciaPuede modicar los tipos existentes y crear los suyos propios.
Las herramientas de distribución de Ceph generan un mapa de CRUSH que contiene un depósitopara cada host y una raíz denominada "default", lo que resulta útil para el repositorio rbd pordefecto. El resto de tipos de depósitos ofrecen un medio para almacenar información acerca dela ubicación física de los nodos/depósitos, lo que facilita la administración del clúster cuandolos OSD, los hosts, o el hardware de red funcionan erróneamente y el administrador necesitaacceder al hardware físico.
Una depósito tiene un tipo, un nombre exclusivo (cadena), un ID único que se expresa comoun número entero negativo, un peso relativo a la capacidad total dividida entre la capacidadde sus elementos, el algoritmo de depósito (por defecto, straw2 ) y el hash ( 0 por defecto, que
171 Depósitos SES 7
reeja el hash de CRUSH rjenkins1 ). Un depósito puede tener uno o varios elementos. Loselementos pueden estar formados por otros depósitos o por OSD. Los elementos pueden tenerun peso relativo.
[bucket-type] [bucket-name] { id [a unique negative numeric ID] weight [the relative capacity/capability of the item(s)] alg [the bucket type: uniform | list | tree | straw2 | straw ] hash [the hash type: 0 by default] item [item-name] weight [weight]}
En el siguiente ejemplo se muestra cómo se pueden utilizar depósitos para agregar un repositorioy ubicaciones físicas como un centro de datos, una sala, un bastidor y una la.
host ceph-osd-server-1 { id -17 alg straw2 hash 0 item osd.0 weight 0.546 item osd.1 weight 0.546}
row rack-1-row-1 { id -16 alg straw2 hash 0 item ceph-osd-server-1 weight 2.00}
rack rack-3 { id -15 alg straw2 hash 0 item rack-3-row-1 weight 2.00 item rack-3-row-2 weight 2.00 item rack-3-row-3 weight 2.00 item rack-3-row-4 weight 2.00 item rack-3-row-5 weight 2.00}
rack rack-2 { id -14 alg straw2 hash 0 item rack-2-row-1 weight 2.00 item rack-2-row-2 weight 2.00
172 Depósitos SES 7
item rack-2-row-3 weight 2.00 item rack-2-row-4 weight 2.00 item rack-2-row-5 weight 2.00}
rack rack-1 { id -13 alg straw2 hash 0 item rack-1-row-1 weight 2.00 item rack-1-row-2 weight 2.00 item rack-1-row-3 weight 2.00 item rack-1-row-4 weight 2.00 item rack-1-row-5 weight 2.00}
room server-room-1 { id -12 alg straw2 hash 0 item rack-1 weight 10.00 item rack-2 weight 10.00 item rack-3 weight 10.00}
datacenter dc-1 { id -11 alg straw2 hash 0 item server-room-1 weight 30.00 item server-room-2 weight 30.00}
root data { id -10 alg straw2 hash 0 item dc-1 weight 60.00 item dc-2 weight 60.00}
173 Depósitos SES 7
17.3 Conjuntos de reglasLos mapas de CRUSH admiten la noción de "reglas de CRUSH", que son las reglas que determinanla colocación de los datos de un repositorio. En clústeres de gran tamaño, es probable que creemuchos repositorios y que cada uno de ellos tenga sus propios conjuntos de reglas y reglas deCRUSH. El mapa de CRUSH por defecto tiene una regla para la raíz por defecto. Si desea másraíces y más reglas, debe crearlas más adelante o se crearán automáticamente cuando se creennuevos repositorios.
NotaEn la mayoría de los casos, no será necesario modicar las reglas por defecto. Cuando secrea un repositorio nuevo, el conjunto de reglas por defecto es 0.
Una regla tiene el siguiente formato:
rule rulename {
ruleset ruleset type type min_size min-size max_size max-size step step
}
ruleset
Un número entero. Clasica una regla para que pertenezca a un conjunto de reglas. Seactiva deniendo el conjunto de reglas en un repositorio. Esta opción es obligatoria. Elvalor por defecto es 0 .
type
Una cadena. Describe una regla para un repositorio codicado de réplica ("replicated)"o de borrado ("erasure"). Esta opción es obligatoria. El valor por defecto es replicated(replicada).
min_size
Un número entero. Si un grupo de repositorios realiza un número inferior de réplicas queel indicado por este número, CRUSH NO selecciona esta regla. Esta opción es obligatoria.El valor por defecto es 2 .
174 Conjuntos de reglas SES 7
max_size
Un número entero. Si un grupo de repositorios realiza un número superior de réplicas queel indicado por este número, CRUSH NO selecciona esta regla. Esta opción es obligatoria.El valor por defecto es 10 .
step take bucket
Toma un depósito especicado por su nombre e inicia una iteración hacia abajo por elárbol. Esta opción es obligatoria. Para obtener una explicación acerca de la iteración porel árbol, consulte la Sección 17.3.1, “Iteración del árbol de nodos”.
step target mode num type bucket-type
target puede ser choose o chooseleaf . Si se dene como choose , se seleccionanvarios depósitos. chooseleaf selecciona directamente los OSD (nodos hoja) del subárbolde cada depósito en el conjunto de depósitos.mode puede ser firstn o indep . Consulte la Sección 17.3.2, “firstn e indep”.Selecciona el número de depósitos del tipo especicado. Donde N es el número de opcionesdisponibles, si num > 0 && < N, seleccione ese número de depósitos; si num < 0, signicaN - num ; y si num == 0, selecciona N depósitos (todos los disponibles). Se usa despuésde step take o a step choose .
step emit
Devuelve el valor actual y vacía la pila. Se suele usar al nal de una regla, pero tambiénpuede utilizarse para formar árboles diferentes en la misma regla. Se usa después de stepchoose .
17.3.1 Iteración del árbol de nodos
La estructura denida con los depósitos se puede ver como un árbol de nodos. Los depósitos sonnodos y los OSD son hojas de ese árbol.
Las reglas del mapa de CRUSH denen cómo se seleccionan los OSD del árbol. Una regla empiezacon un nodo y se itera hacia abajo por el árbol para devolver un conjunto de OSD. No es posibledenir la rama que se debe seleccionar. En su lugar, el algoritmo CRUSH garantiza que elconjunto de OSD cumple los requisitos de réplica y distribuye los datos de forma homogénea.
Con step take bucket , la iteración por el árbol de nodos comienza en el depósito indicado(no en el tipo de depósito). Si se deben devolver OSD de todas las ramas del árbol, se debeindicar el depósito raíz. De lo contrario, la iteración de los pasos siguientes solo se producirápor un subárbol.
175 Iteración del árbol de nodos SES 7
Después de step take , se usan una o varias entradas step choose en la denición de la regla.Cada step choose elige un número denido de nodos (o ramas) del nodo superior seleccionadoanteriormente.
Al nal, los OSD seleccionados se devuelven con step emit .
step chooseleaf es una función de conveniencia que selecciona directamente los OSD deramas de un depósito determinado.
En la Figura 17.2, “Árbol de ejemplo” se proporciona un ejemplo de cómo se usa step para producirla iteración por un árbol. Las echas naranjas y los números corresponden a example1a yexample1b , mientras que las azules corresponden a example2 en las siguientes denicionesde regla.
FIGURA 17.2: ÁRBOL DE EJEMPLO
# orange arrowsrule example1a { ruleset 0 type replicated min_size 2 max_size 10 # orange (1) step take rack1 # orange (2) step choose firstn 0 host # orange (3)
176 Iteración del árbol de nodos SES 7
step choose firstn 1 osd step emit}
rule example1b { ruleset 0 type replicated min_size 2 max_size 10 # orange (1) step take rack1 # orange (2) + (3) step chooseleaf firstn 0 host step emit}
# blue arrowsrule example2 { ruleset 0 type replicated min_size 2 max_size 10 # blue (1) step take room1 # blue (2) step chooseleaf firstn 0 rack step emit}
17.3.2 firstn e indep
Una regla de CRUSH dene las sustituciones de los nodos o los OSD que fallan (consulte laSección 17.3, “Conjuntos de reglas”). La palabra clave step requiere el parámetro firstn oindep . En la Figura 17.3, “Métodos de sustitución de nodos” se muestra un ejemplo.
Con firstn se añaden nodos de sustitución al nal de la lista de nodos activos. En el caso deun nodo que ha fallado, los nodos en buen estado siguientes se desplazan a la izquierda paracubrir el hueco del nodo erróneo. Se trata del método por defecto, y el recomendado, para losrepositorios replicados, ya que un nodo secundario ya tiene todos los datos y, por lo tanto, puedehacerse cargo de las tareas del nodo principal de inmediato.
Con indep se seleccionan nodos de sustitución jos para cada nodo activo. La sustituciónde un nodo con fallos no cambia el orden de los nodos restantes. Este es el comportamientorecomendado para los repositorios codicados de borrado. En los repositorios codicados de
177 firstn e indep SES 7
borrado, los datos almacenados en un nodo dependen de su posición en la selección denodos. Cuando se cambia el orden de los nodos, todos los datos de los nodos afectados debenrecolocarse.
FIGURA 17.3: MÉTODOS DE SUSTITUCIÓN DE NODOS
17.4 Grupos de colocación
Ceph asigna objetos a los grupos de colocación. Los grupos de colocación son fragmentos deun repositorio de objetos lógicos que colocan objetos como un grupo en los OSD. Los gruposde colocación reducen la cantidad de metadatos por objeto cuando Ceph almacena los datos enlos OSD. Disponer de un mayor número de grupos de colocación (por ejemplo, 100 por OSD)produce que haya un mejor equilibrio.
17.4.1 Uso de los grupos de colocación
Un grupo de colocación (PG) agrega objetos dentro de un repositorio. La razón principal es querealizar un seguimiento de la ubicación de los objetos y de los metadatos de cada objeto escostoso desde el punto de vista computacional. Por ejemplo, un sistema con millones de objetosno puede realizar directamente un seguimiento de la ubicación de cada uno de esos objetos.
178 Grupos de colocación SES 7
FIGURA 17.4: GRUPOS DE COLOCACIÓN EN UN REPOSITORIO
El cliente de Ceph calculará a qué grupo de colocación pertenecerá un objeto. Para ello, aplicael hash del ID de objeto y aplica una operación basada en el número grupos de colocación delrepositorio denido y el ID del repositorio.
El contenido de un objeto situado dentro de un grupo de colocación se almacena en un conjuntode OSDs. Por ejemplo, en un repositorio replicado con un tamaño de dos, cada grupo decolocación almacenará objetos en dos OSD:
FIGURA 17.5: GRUPOS DE COLOCACIÓN Y OSDS
Si se produce un error en el OSD 2, otro OSD se asignará al grupo de colocación 1 y se rellenarácon copias de todos los objetos de OSD 1. Si el tamaño del repositorio cambia de dos a tres,se asignará un OSD adicional al grupo de colocación y recibirá copias de todos los objetos delgrupo de colocación.
Los grupos de colocación no son propietarios del OSD; lo comparten con otros grupos decolocación del mismo repositorio, o incluso con otros repositorios. Si se produce un error en elOSD 2, el grupo de colocación 2 también tendrá que restaurar copias de los objetos, medianteel OSD 3.
179 Uso de los grupos de colocación SES 7
Cuando aumenta el número de grupos de colocación, se asignan OSD a los nuevos grupos decolocación. El resultado de la función CRUSH también cambia y algunos objetos de los grupos decolocación anteriores se copian en los nuevos grupos de colocación y se eliminan de los antiguos.
17.4.2 Determinación del valor de PG_NUM
NotaDesde Ceph Nautilus (v14.x), puede utilizar el módulo pg_autoscaler de Ceph Managerpara escalar automáticamente los grupos de colocación según sea necesario. Si deseahabilitar esta función, consulte el Libro “Deploying and Administering SUSE Enterprise Storage
with Rook”, Capítulo 6 “Configuration”, Sección 6.1.1.1 “Default PG and PGP counts”.
Al crear un repositorio nuevo, se puede elegir el valor de PG_NUM manualmente:
root # ceph osd pool create POOL_NAME PG_NUM
El valor de PG_NUM no se puede calcular automáticamente. A continuación se muestran algunosvalores de uso común según el número de OSDs del clúster:
Menos de 5 OSD:
En PG_NUM , dena el valor 128.
Entre 5 y 10 OSD:
En PG_NUM , dena el valor 512.
Entre 10 y 50 OSD:
En PG_NUM , dena el valor 1024.
A medida que aumenta el número de OSD, seleccionar el valor adecuado para PG_NUM se vuelvecada vez más importante. El valor de PG_NUM afecta considerablemente al comportamiento delclúster, así como a la durabilidad de los datos en caso de error del OSD.
180 Determinación del valor de PG_NUM SES 7
17.4.2.1 Cálculo de los grupos de colocación para más de 50 OSD
Si tiene menos de 50 OSD, utilice el valor preseleccionado descrito en la Sección 17.4.2,
“Determinación del valor de PG_NUM”. Si tiene más de 50 OSD, se recomienda disponer de entre50 y 100 grupos de colocación por OSD para equilibrar el uso de los recursos, la durabilidadde los datos y la distribución. Para un único repositorio de objetos, puede utilizar la siguientefórmula para obtener una línea base:
total PGs = (OSDs * 100) / POOL_SIZE
Donde POOL_SIZE es el número de réplicas para repositorios replicados o la suma "k"+"m" paralo repositorios codicados de borrado, según el resultado del comando ceph osd erasure-code-profile get . Debe redondear el resultado hasta la potencia más cercana de 2. Serecomienda redondear hacia arriba para que el algoritmo CRUSH equilibre uniformemente elnúmero de objetos entre los grupos de colocación.
Por ejemplo, para un clúster con 200 OSD y un tamaño de repositorio de 3 réplicas, el númerode grupos de colocación se calcularía de la siguiente manera:
(200 * 100) / 3 = 6667
La potencia más cercana de 2 es 8192.
Si se usan varios repositorios de datos para almacenar objetos, debe equilibrar el número degrupos de colocación por repositorio con el número de grupos de colocación por OSD. Se debealcanzar un número total razonable de grupos de colocación que proporcione una varianzarazonablemente baja por OSD sin que afecte negativamente a los recursos del sistema ni provocarque el proceso de emparejamiento sea demasiado lento.
Por ejemplo, un clúster de 10 repositorios, cada uno con 512 grupos de colocación en 10 OSDda un total de 5120 grupos de colocación repartidos en 10 OSD; es decir, 512 grupos decolocación por OSD. Tal conguración no utilizaría demasiados recursos. Sin embargo, sise crearan 1000 repositorios con 512 grupos de colocación cada uno, los OSD controlaríanaproximadamente 50 000 grupos de colocación cada uno y requerirían muchos más recursos ytiempo para el emparejamiento.
181 Determinación del valor de PG_NUM SES 7
17.4.3 Definición del número de grupos de colocación
NotaDesde Ceph Nautilus (v14.x), puede utilizar el módulo pg_autoscaler de Ceph Managerpara escalar automáticamente los grupos de colocación según sea necesario. Si deseahabilitar esta función, consulte el Libro “Deploying and Administering SUSE Enterprise Storage
with Rook”, Capítulo 6 “Configuration”, Sección 6.1.1.1 “Default PG and PGP counts”.
Si aún necesita especicar el número de grupos de colocación en un repositorio manualmente,deberá especicarlos en el momento en el que cree el repositorio (consulte la Sección 18.1,
“Creación de un repositorio”). Después de haber establecido los grupos de colocación para unrepositorio, puede aumentar el número de grupos de colocación ejecutando el comandosiguiente:
root # ceph osd pool set POOL_NAME pg_num PG_NUM
Después de aumentar el número de grupos de colocación, también debe aumentar el número degrupos de colocación de la ubicación ( PGP_NUM ) antes de que el clúster se reequilibre. El valorde PGP_NUM será el número de grupos de colocación que el algoritmo CRUSH tendrá en cuentapara la colocación. Al aumentar el valor de PG_NUM , se dividen los grupos de colocación, perolos datos no se migran a los grupos de colocación más recientes hasta que se aumenta este valorde PG_NUM . El valor de PGP_NUM debe ser igual al de PG_NUM . Para aumentar el número degrupos de colocación de la ubicación, ejecute lo siguiente:
root # ceph osd pool set POOL_NAME pgp_num PGP_NUM
17.4.4 Obtención del número de grupos de colocación
Para averiguar el número de grupos de colocación de un repositorio, ejecute el comando getsiguiente:
root # ceph osd pool get POOL_NAME pg_num
182 Definición del número de grupos de colocación SES 7
17.4.5 Obtención de estadísticas del grupo de colocación de unclúster
Para obtener las estadísticas de los grupos de colocación del clúster, ejecute el comandosiguiente:
root # ceph pg dump [--format FORMAT]
Los formatos válidos son "plain" (por defecto) y "json".
17.4.6 Obtención de estadísticas de los grupos de colocaciónatascados
Para obtener las estadísticas de todos los grupos de colocación atascados en un estadoespecicado, ejecute lo siguiente:
root # ceph pg dump_stuck STATE \ [--format FORMAT] [--threshold THRESHOLD]
El valor de STATE puede ser "inactive" (inactivo, los grupos de colocación no puedenprocesar lecturas ni escrituras porque están a la espera de que aparezca un OSD con losdatos más actualizados), "unclean" (no limpio, los grupos de colocación contienen objetosque no se replican el número deseado de veces), "stale" (obsoleto, los grupos de colocaciónestán en un estado desconocido: los OSD donde se alojan no han informado al clúster desupervisión en un intervalo de tiempo especicado por la opción mon_osd_report_timeout ,"undersized" (tamaño insuciente) o "degraded" (degradado).
Los formatos válidos son "plain" (por defecto) y "json".
El umbral dene el número mínimo de segundos que el grupo de colocación debe estar atascadoantes de que se incluya en las estadísticas (300 segundos por defecto).
17.4.7 Búsqueda de un mapa de grupos de colocación
Para obtener el mapa de un grupo de colocación determinado, ejecute lo siguiente:
root # ceph pg map PG_ID
Ceph devolverá el mapa del grupo de colocación, el grupo de colocación y el estado del OSD:
root # ceph pg map 1.6c
183 Obtención de estadísticas del grupo de colocación de un clúster SES 7
osdmap e13 pg 1.6c (1.6c) -> up [1,0] acting [1,0]
17.4.8 Obtención de estadísticas de los grupos de colocación
Para recuperar estadísticas de un grupo de colocación determinado, ejecute lo siguiente:
root # ceph pg PG_ID query
17.4.9 Depuración de un grupo de colocación
Para borrar de forma segura un grupo de colocación (Sección 17.6, “Depuración de grupos de
colocación”), ejecute lo siguiente:
root # ceph pg scrub PG_ID
Ceph comprueba los nodos primario y de réplica, genera un catálogo de todos los objetosdel grupo de colocación y los compara para asegurarse de que no falta ningún objeto, queno coinciden y que su contenido es coherente. Suponiendo que todas las réplicas coincidan,un barrido semántico nal garantiza que todos los metadatos de objetos relacionados coninstantáneas sean coherentes. Los errores se notican a través de los registros.
17.4.10 Priorización de la reposición y la recuperación de losgrupos de colocación
Puede encontrarse con una situación en la que varios grupos de colocación requieran unarecuperación o una reposición, y algunos grupos contienen datos más importantes que otros.Por ejemplo, unos grupos de colocación pueden contener datos para las imágenes utilizadaspor las máquinas en ejecución, mientras que otros pueden ser utilizados por máquinas inactivaso contener datos menos relevantes. En este caso, es posible que desee dar prioridad a larecuperación de los primeros grupos para que el rendimiento y la disponibilidad de los datosalmacenados en aquellos grupos se restaure antes. Para marcar grupos de colocación concretoscomo prioritarios durante la reposición o la recuperación, ejecute lo siguiente:
root # ceph pg force-recovery PG_ID1 [PG_ID2 ... ]root # ceph pg force-backfill PG_ID1 [PG_ID2 ... ]
184 Obtención de estadísticas de los grupos de colocación SES 7
Esto hará que Ceph lleve a cabo la recuperación o la reposición en los grupos de colocaciónespecicados, antes que en los demás. No se interrumpen las operaciones de reposición orecuperación que haya en curso, sino que los grupos de colocación especicados se procesanlo antes posible. Si cambia de opinión o se equivoca de grupo para priorizar, puede cancelarla priorización:
root # ceph pg cancel-force-recovery PG_ID1 [PG_ID2 ... ]root # ceph pg cancel-force-backfill PG_ID1 [PG_ID2 ... ]
Los comandos cancel‑* eliminan el indicador "force" de los grupos de colocación para quese procesen en el orden por defecto. Una vez más, esto no afecta a los grupos de colocaciónque ya se están procesando, solo a los que todavía están en cola. El indicador "force" se borraautomáticamente después de que se realice la recuperación o la reposición del grupo.
17.4.11 Reversión de objetos perdidos
Si el clúster ha perdido uno o más objetos y ha decidido abandonar la búsqueda de los datosperdidos, debe marcar los objetos no encontrados como "perdidos".
Si los objetos siguen perdidos después de haber consultado todas las ubicaciones posibles,es posible que deba darlos denitivamente por perdidos. Esto puede ocurrir si se da unacombinación inusual de errores en la que se permite al clúster obtener información sobre lasescrituras que se realizaron antes de que se recuperaran las escrituras en sí.
Actualmente, la única opción admitida es "revert", que revertirá a una versión anterior del objeto,o que se ignorará por completo en caso de un objeto nuevo. Para marcar los objetos "unfound" (noencontrados) como "lost" (perdidos), ejecute lo siguiente:
cephuser@adm > ceph pg PG_ID mark_unfound_lost revert|delete
17.4.12 Habilitación del escalador automático de grupos decolocación
Los grupos de colocación (PG) son un detalle de implementación interno de cómo Cephdistribuye los datos. Al habilitar pg-autoscaling, puede permitir que el clúster cree o ajusteautomáticamente los grupos de colocación en función de cómo se utilice el clúster.
185 Reversión de objetos perdidos SES 7
Cada repositorio del sistema tiene una propiedad pg_autoscale_mode que se puede estableceren off , on o warn :
El escalador automático se congura para cada repositorio y se puede ejecutar en tres modos:
off
Inhabilita la escala automática para este repositorio. Depende del administrador elegir unnúmero de grupos de colocación adecuado para cada repositorio.
on
Habilita los ajustes automáticos del recuento de grupos de colocación para el repositorioindicado.
warn
Genera alertas de estado que indican cuando se debe ajustar el recuento de grupos decolocación.
Para denir el modo escala automático para los repositorios existentes:
cephuser@adm > ceph osd pool set POOL_NAME pg_autoscale_mode mode
También puede congurar la propiedad por defecto de pg_autoscale_mode que se aplica acualquier repositorio que se cree en el futuro con:
cephuser@adm > ceph config set global osd_pool_default_pg_autoscale_mode MODE
Puede ver cada repositorio, su utilización relativa y los cambios sugeridos en el recuento degrupos de colocación con este comando:
cephuser@adm > ceph osd pool autoscale-status
17.5 Manipulación del mapa de CRUSH
En esta sección se describen formas para manipular de forma básica el mapa de CRUSH: porejemplo, para editar un mapa de CRUSH; cambiar los parámetros del mapa de CRUSH y añadir,mover o eliminar un OSD.
186 Manipulación del mapa de CRUSH SES 7
17.5.1 Edición de un mapa de CRUSH
Para editar un mapa de CRUSH existente, haga lo siguiente:
1. Obtenga un mapa de CRUSH. Para obtener el mapa de CRUSH de su clúster, ejecute losiguiente:
cephuser@adm > ceph osd getcrushmap -o compiled-crushmap-filename
Ceph da como resultado ( -o ) un mapa de CRUSH compilado con el nombre de archivoque especique. Puesto que el mapa de CRUSH está compilado, debe descompilarlo antesde que se pueda editar.
2. Descompilación de un mapa de CRUSH. Para descompilar un mapa de CRUSH, ejecutelo siguiente:
cephuser@adm > crushtool -d compiled-crushmap-filename \ -o decompiled-crushmap-filename
Ceph descompilará ( -d ) el mapa de CRUSH compilado y lo obtendrá como resultado ( ‑o )con el nombre de archivo que especique.
3. Edite al menos uno de los parámetros de dispositivos, depósitos o reglas.
4. Compile un mapa de CRUSH. Para hacerlo, ejecute lo siguiente:
cephuser@adm > crushtool -c decompiled-crush-map-filename \ -o compiled-crush-map-filename
Ceph almacenará un mapa de CRUSH compilado con el nombre de archivo que especique.
5. Dena un mapa de CRUSH. Para denir el mapa de CRUSH de su clúster, ejecute losiguiente:
cephuser@adm > ceph osd setcrushmap -i compiled-crushmap-filename
Ceph introducirá el mapa de CRUSH compilado con el nombre de archivo que haespecicado como el mapa de CRUSH del clúster.
Sugerencia: uso de un sistema de control de versionesUtilice un sistema de control de versiones, como git o svn, para los archivos de mapa deCRUSH exportados y modicados. Con ellos, una posible reversión es más sencilla.
187 Edición de un mapa de CRUSH SES 7
Sugerencia: prueba del nuevo mapa de CRUSHPruebe el nuevo mapa de CRUSH ajustado con el comando crushtool‑‑test y compárelo con el estado anterior a la aplicación delnuevo mapa de CRUSH. Encontrará útiles los siguientes conmutadoresde comandos: ‑‑show‑statistics , ‑‑show‑mappings , ‑‑show‑bad‑mappings ,‑‑show‑utilization , ‑‑show‑utilization‑all , ‑‑show‑choose‑tries .
17.5.2 Adición o traslado de un OSD
Para añadir o trasladar un OSD en el mapa de CRUSH de un clúster en ejecución, ejecute losiguiente:
cephuser@adm > ceph osd crush set id_or_name weight root=pool-namebucket-type=bucket-name ...
id
Un número entero. El ID numérico del OSD. Esta opción es obligatoria.
name
Una cadena. El nombre completo del OSD. Esta opción es obligatoria.
weight
Un valor doble. El peso de CRUSH para el OSD. Esta opción es obligatoria.
root
Un par de clave y valor. Por defecto, la jerarquía de CRUSH contiene como raíz elrepositorio por defecto. Esta opción es obligatoria.
bucket-type
Pares clave-valor. Puede especicar la ubicación del OSD en la jerarquía de CRUSH.
El ejemplo siguiente añade osd.0 a la jerarquía, o traslada el OSD desde una ubicación anterior.
cephuser@adm > ceph osd crush set osd.0 1.0 root=data datacenter=dc1 room=room1 \row=foo rack=bar host=foo-bar-1
188 Adición o traslado de un OSD SES 7
17.5.3 Diferencia entre ceph osd reweight y ceph osd crushreweightHay dos comandos similares que cambian el "peso" de un Ceph OSD. El contexto en el que seusan es diferente y puede causar confusión.
17.5.3.1 ceph osd reweight
Uso:
cephuser@adm > ceph osd reweight OSD_NAME NEW_WEIGHT
ceph osd reweight dene un peso de sustitución en el Ceph OSD. Este valor está en el intervaloentre 0 y 1 e impone a CRUSH que recoloque los datos que de otro modo estarían en esta unidad.No cambia los pesos asignados a los depósitos situados por encima del OSD. Se trata de unamedida correctiva en caso de que la distribución normal de CRUSH no funcione del todo bien.Por ejemplo, si uno de los OSD está al 90 % y los demás están al 40 %, podría reducir este pesopara tratar de compensarlos.
Nota: el peso del OSD es temporalTenga en cuenta que ceph osd reweight no es un ajuste persistente. Cuando un OSDse excluye, su peso se dene en 0, y cuando se incluye de nuevo, el peso cambia a 1.
17.5.3.2 ceph osd crush reweight
Uso:
cephuser@adm > ceph osd crush reweight OSD_NAME NEW_WEIGHT
El valor ceph osd crush reweight permite denir el peso de CRUSH del OSD. Este peso esun valor arbitrario (generalmente el tamaño del disco en TB) y controla la cantidad de datosque el sistema intenta asignar al OSD.
17.5.4 Eliminación de un OSD
Para eliminar un OSD del mapa de CRUSH de un clúster en ejecución, ejecute lo siguiente:
cephuser@adm > ceph osd crush remove OSD_NAME
189 Diferencia entre ceph osd reweight y ceph osd crush reweight SES 7
17.5.5 Adición de un depósito
Para añadir un depósito al mapa de CRUSH de un clúster en ejecución, ejecute el comando cephosd crush add-bucket :
cephuser@adm > ceph osd crush add-bucket BUCKET_NAME BUCKET_TYPE
17.5.6 Traslado de un depósito
Para trasladar un depósito a una ubicación diferente o colocarlo en la jerarquía del mapa deCRUSH, ejecute lo siguiente:
cephuser@adm > ceph osd crush move BUCKET_NAME BUCKET_TYPE=BUCKET_NAME [...]
Por ejemplo:
cephuser@adm > ceph osd crush move bucket1 datacenter=dc1 room=room1 row=foo rack=bar host=foo-bar-1
17.5.7 Eliminación de un depósito
Para eliminar un depósito de la jerarquía del mapa de CRUSH, ejecute lo siguiente:
cephuser@adm > ceph osd crush remove BUCKET_NAME
Nota: solo depósitos vacíosun depósito debe estar vacío para que se pueda eliminar de la jerarquía de CRUSH.
17.6 Depuración de grupos de colocaciónAdemás de realizar varias copias de los objetos, Ceph garantiza la integridad de los datosrealizando un borrado seguro de los grupos de colocación (encontrará más información sobrelos grupos de colocación en el Libro “Guía de distribución”, Capítulo 1 “SES y Ceph”, Sección 1.3.2
“Grupos de colocación”). El borrado seguro de Ceph es análogo a ejecutar fsck en la capa dealmacenamiento de objetos. Para cada grupo de colocación, Ceph genera un catálogo de todoslos objetos y compara cada objeto primario y sus réplicas para asegurarse de que no falta ningún
190 Adición de un depósito SES 7
objeto o que hay objetos que no coinciden. Un borrado seguro ligero diario comprueba el tamañoy los atributos del objeto, mientras que el borrado seguro profundo semanal lee los datos yutiliza sumas de comprobación para garantizar la integridad de los datos.
El borrado seguro es importante para mantener la integridad de los datos, pero puede reducir elrendimiento. Es posible ajustar los valores siguientes para aumentar o disminuir las operacionesde borrado seguro:
osd max scrubs
El número máximo de operaciones de borrado seguro simultáneas para un Ceph OSD. Elvalor por defecto es 1.
osd scrub begin hour , osd scrub end hour
Las horas del día (de las 0 a 24) con las que se dene una ventana temporal en la que sepuede producir el borrado seguro. Por defecto, empieza a las 0 y termina a las 24.
ImportanteSi el intervalo de depuración del grupo de colocación supera el valor indicado enosd scrub max interval , el borrado seguro se producirá independientemente dela ventana temporal que se dena.
osd scrub during recovery
Permite el borrado seguro durante la recuperación. Si se establece el valor "false" (falso),se inhabilita la programación de borrados seguros nuevos mientras haya una recuperaciónactiva. Los borrados seguros que ya estén en ejecución continuarán. Esta opción resulta útilpara reducir la carga en clústeres muy ocupados. El valor por defecto es "true" (verdadero).
osd scrub thread timeout
El tiempo máximo en segundos que debe transcurrir para que un hilo de borrado segurollegue a su tiempo límite. El valor por defecto es 60.
osd scrub finalize thread timeout
El tiempo máximo en segundos que debe transcurrir para que un hilo de nalización deborrado seguro llegue a su tiempo límite. El valor por defecto es 60*10.
osd scrub load threshold
La carga máxima normalizada. Ceph no llevará a cabo un borrado seguro cuando la cargadel sistema (como se dene por el coeciente de getloadavg() /número de CPUs enlínea ) sea superior a este número. El valor por defecto es 0,5.
191 Depuración de grupos de colocación SES 7
osd scrub min interval
El intervalo mínimo en segundos para el borrado seguro de Ceph OSD cuando la carga delclúster de Ceph sea pequeña. Por defecto es 60*60*24 (una vez al día).
osd scrub max interval
El intervalo máximo en segundos para el borrado seguro del Ceph OSD,independientemente de la carga del clúster. Por defecto es 7*60*60*24 (una vez a lasemana).
osd scrub chunk min
El número mínimo de porciones de almacenamiento de objetos que se deben borrar deforma segura durante una única operación. Ceph bloquea la escritura en una única porcióndurante el borrado seguro. El valor por defecto es 5.
osd scrub chunk max
El número máximo de porciones de almacenamiento de objetos que se deben borrar deforma segura durante una única operación. El valor por defecto es 25.
osd scrub sleep
El tiempo de reposo antes de realizar el borrado seguro en el siguiente grupo de porciones.Al aumentar este valor, se ralentiza toda la operación de borrado seguro, mientras que lasoperaciones del cliente se ven menos afectadas. El valor por defecto es 0.
osd deep scrub interval
El intervalo entre borrados seguros "profundos" (con lectura completa de todos los datos).La opción osd scrub load threshold no afecta a este valor. Por defecto es 60*60*24*7(una vez a la semana).
osd scrub interval randomize ratio
Añade un retraso aleatorio al valor osd scrub min interval cuando se programa lasiguiente tarea de borrado seguro para un grupo de colocación. El retraso es un valoraleatorio menor que el resultado de osd scrub min interval * osd scrub intervalrandomized ratio . Por lo tanto, el valor por defecto difunde de forma prácticamentealeatoria los procesos de borrado seguro durante la ventana temporal permitida de [1, 1,5]* osd scrub min interval . El valor por defecto es 0,5.
osd deep scrub stride
El tamaño de lectura cuando se realiza un borrado seguro profundo. El valor por defectoes 524288 (512 kB).
192 Depuración de grupos de colocación SES 7
18 Gestión de repositorios de almacenamiento
Ceph almacena los datos en repositorios. Los repositorios son grupos lógicos en los que sealmacenan objetos. Al distribuir un clúster por primera vez sin crear un repositorio, Ceph utilizalos repositorios por defecto para almacenar los datos. Los siguientes aspectos importantes estánrelacionados con los repositorios de Ceph:
Resiliencia: los repositorios de Ceph proporcionan resiliencia al replicar o codicar los datosque contienen. Cada repositorio se puede denir como replicated (replicado) o comoerasure coding (codicación de borrado). En el caso de los repositorios replicados, debedenir el número de réplicas o copias que tendrá cada objeto de datos en el repositorio. Elnúmero de copias (OSD, depósitos/hojas de CRUSH) que se pueden perder es uno menosque el número de réplicas. Con la codicación de borrado, se denen los valores de ky m , donde k es el número de fragmentos de datos y m es el número de fragmentos decodicación. Para los repositorios codicados de borrado, es el número de fragmentos decodicación lo que determina cuántos OSD (depósitos/hojas de CRUSH) se pueden perdersin perder datos.
Grupos de colocación: puede establecer el número de grupos de colocación del repositorio.En una conguración típica, se utilizan aproximadamente 100 grupos de colocación porOSD para proporcionar el equilibrio óptimo sin necesidad de utilizar demasiados recursosinformáticos. Al congurar varios repositorios, asegúrese de que ha denido un númerorazonable de grupos de colocación para el conjunto de repositorio y clúster.
Reglas de CRUSH: cuando se almacenan datos en un repositorio, los objetos y sus réplicas(o los fragmentos en caso de los repositorios codicados de borrado) se colocan según elconjunto de reglas de CRUSH asignado al repositorio. Puede crear una regla de CRUSHpersonalizada para el repositorio.
Instantáneas: al crear instantáneas con ceph osd pool mksnap , se realiza una instantáneade un repositorio concreto.
Para organizar los datos en repositorios, puede enumerar, crear y eliminar repositorios. Tambiénpuede ver las estadísticas de uso para cada repositorio.
193 SES 7
18.1 Creación de un repositorioLos repositorios se pueden crear de tipo replicated (replicado) para recuperar los OSDperdidos manteniendo varias copias de los objetos o de tipo erasure (de borrado) paraobtener capacidad de tipo RAID5/6 generalizada. Los repositorios replicados requieren másalmacenamiento en bruto, mientras que los repositorios codicados de borrado requierenmenos. El tipo por defecto es replicated . Para obtener más información sobre los repositorioscodicados de borrado, consulte el Capítulo 19, Repositorios codificados de borrado.
Para crear un repositorio replicado, ejecute:
cephuser@adm > ceph osd pool create POOL_NAME
NotaEl escalador automático se encargará del resto de los argumentos opcionales. Para obtenermás información, consulte la Sección 17.4.12, “Habilitación del escalador automático de grupos
de colocación”.
Para crear un repositorio codicado de borrado, ejecute:
cephuser@adm > ceph osd pool create POOL_NAME erasure CRUSH_RULESET_NAME \EXPECTED_NUM_OBJECTS
El comando ceph osd pool create puede fallar si supera el límite de grupos de colocaciónpor OSD. El límite se establece con la opción mon_max_pg_per_osd .
POOL_NAME
Nombre del repositorio. Debe ser único. Esta opción es obligatoria.
POOL_TYPE
El tipo de repositorio, que puede ser replicated (replicado) para recuperar los OSDperdidos manteniendo varias copias de los objetos o erasure (de borrado) para obtenerun tipo de capacidad RAID5 generalizada. Los repositorios replicados requieren másespacio de almacenamiento en bruto, pero implementan todas las operaciones de Ceph.Los repositorios de borrado requieren menos espacio de almacenamiento en bruto, perosolo implementan un subconjunto de las operaciones disponibles. El tipo POOL_TYPE pordefecto es replicated .
CRUSH_RULESET_NAME
194 Creación de un repositorio SES 7
El nombre de conjunto de reglas de CRUSH para el repositorio. Si el conjunto de reglasespecicado no existe, se producirá un error -ENOENT al crear los repositorios replicados.Para los repositorios replicados es el conjunto de reglas especicado por la variable deconguración osd pool default CRUSH replicated ruleset . Este conjunto de reglasdebe existir. Para los repositorios de borrado, es "erasure-code" si se utiliza el perl decódigo de borrado por defecto o POOL_NAME de lo contrario. Este conjunto de reglas decreará de forma implícita si aún no existe.
erasure_code_profile=perfil
Solo para los repositorios codicados de borrado. Utiliza el perl de código de borrado.Debe ser un perl existente, según se haya denido mediante osd erasure-code-profileset .
NotaSi por algún motivo el escalador automático se ha inhabilitado( pg_autoscale_mode desactivado) en un repositorio, puede calcular y denir elnúmero de grupos de colocación manualmente. Consulte la Sección 17.4, “Grupos de
colocación” (Grupos de colocación) para obtener información sobre cómo calcular elnúmero adecuado de grupos de colocación para su repositorio.
EXPECTED_NUM_OBJECTS
El número previsto de objetos para este repositorio. Al denir este valor (junto con unvalor negativo en filestore merge threshold ), la división de carpetas del grupo decolocación se produce en el momento de la creación del repositorio. Esto evita el impactode latencia cuando se divide una carpeta en tiempo de ejecución.
18.2 Listado de repositorios
Para enumerar los repositorios de su clúster, ejecute:
cephuser@adm > ceph osd pool ls
195 Listado de repositorios SES 7
18.3 Cambio de nombre de un repositorioPara renombrar un repositorio, ejecute:
cephuser@adm > ceph osd pool rename CURRENT_POOL_NAME NEW_POOL_NAME
Si ha renombrado de un repositorio y existen permisos por repositorio para los usuariosautenticados, debe actualizar los permisos con el nuevo nombre de repositorio.
18.4 Supresión de un repositorio
Aviso: la supresión de un repositorio no se puede deshacerLos repositorios pueden contener datos importantes. Si suprime un repositorio,desaparecerán todos sus datos y no habrá forma de recuperarlo.
Dado que la supresión accidental de un repositorio es un peligro real, Ceph implementa dosmecanismos que impiden suprimir los repositorios. Para suprimir un repositorio, primero esnecesario inhabilitar ambos mecanismos.
El primero es el indicador NODELETE . Todos los repositorios lo tienen y el valor por defecto es"false". Para averiguar el valor de este indicador en un repositorio, ejecute el siguiente comando:
cephuser@adm > ceph osd pool get pool_name nodelete
Si la salida es nodelete: true , no podrá suprimir el repositorio hasta que cambie el indicadormediante el siguiente comando:
cephuser@adm > ceph osd pool set pool_name nodelete false
El segundo mecanismo es el parámetro de conguración para todo el clúster mon allow pooldelete , que es "false" por defecto. Esto signica que, por defecto, no es posible suprimir unrepositorio. El mensaje de error que se muestra es:
Error EPERM: pool deletion is disabled; you must first set themon_allow_pool_delete config option to true before you can destroy a pool
Para suprimir el repositorio a pesar de la conguración de seguridad, puede denirtemporalmente mon allow pool delete como "true", suprimir el repositorio y, a continuación,volver a denir el parámetro como "false":
cephuser@adm > ceph tell mon.* injectargs --mon-allow-pool-delete=true
196 Cambio de nombre de un repositorio SES 7
cephuser@adm > ceph osd pool delete pool_name pool_name --yes-i-really-really-mean-itcephuser@adm > ceph tell mon.* injectargs --mon-allow-pool-delete=false
El comando injectargs muestra el siguiente mensaje:
injectargs:mon_allow_pool_delete = 'true' (not observed, change may require restart)
Es una simple conrmación de que el comando se ha ejecutado correctamente. No es un error.
Si ha creado sus propios conjuntos de reglas y reglas para un repositorio que ha creado, plantéesela posibilidad de eliminar estos elementos cuando ya no necesite el repositorio.
18.5 Otras operaciones
18.5.1 Asociación de repositorios a una aplicación
Para utilizar los grupos, debe asociarlos a una aplicación. Los repositorios que se utilizarán conCephFS y los creados automáticamente por Object Gateway se asocian de forma automática.
En otros casos, se puede asociar manualmente un nombre de aplicación de formato libre alrepositorio:
cephuser@adm > ceph osd pool application enable POOL_NAME APPLICATION_NAME
Sugerencia: nombres de las aplicaciones por defectoCephFS utiliza el nombre de aplicación cephfs , el dispositivo de bloques RADOS utilizarbd y Object Gateway utiliza rgw .
Un repositorio se puede asociar a varias aplicaciones y cada aplicación puede tener sus propiosmetadatos. Para mostrar la aplicación (o las aplicaciones) asociadas a un repositorio, emita elcomando siguiente:
cephuser@adm > ceph osd pool application get pool_name
18.5.2 Definición de cuotas de repositorio
Puede denir cuotas de repositorio para el número máximo de bytes o el número máximo deobjetos por repositorio.
197 Otras operaciones SES 7
cephuser@adm > ceph osd pool set-quota POOL_NAME MAX_OBJECTS OBJ_COUNT MAX_BYTES BYTES
Por ejemplo:
cephuser@adm > ceph osd pool set-quota data max_objects 10000
Para eliminar una cuota, establezca su valor en 0.
18.5.3 Visualización de estadísticas de repositorios
Para mostrar las estadísticas de uso de un repositorio, ejecute:
cephuser@adm > rados df POOL_NAME USED OBJECTS CLONES COPIES MISSING_ON_PRIMARY UNFOUND DEGRADED RD_OPS RD WR_OPS WR USED COMPR UNDER COMPR .rgw.root 768 KiB 4 0 12 0 0 0 44 44 KiB 4 4 KiB 0 B 0 B cephfs_data 960 KiB 5 0 15 0 0 0 5502 2.1 MiB 14 11 KiB 0 B 0 B cephfs_metadata 1.5 MiB 22 0 66 0 0 0 26 78 KiB 176 147 KiB 0 B 0 B default.rgw.buckets.index 0 B 1 0 3 0 0 0 4 4 KiB 1 0 B 0 B 0 B default.rgw.control 0 B 8 0 24 0 0 0 0 0 B 0 0 B 0 B 0 B default.rgw.log 0 B 207 0 621 0 0 0 5372132 5.1 GiB 3579618 0 B 0 B 0 B default.rgw.meta 961 KiB 6 0 18 0 0 0 155 140 KiB 14 7 KiB 0 B 0 B example_rbd_pool 2.1 MiB 18 0 54 0 0 0 3350841 2.7 GiB 118 98 KiB 0 B 0 B iscsi-images 769 KiB 8 0 24 0 0 0 1559261 1.3 GiB 61 42 KiB 0 B 0 B mirrored-pool 1.1 MiB 10 0 30 0 0 0 475724 395 MiB 54 48 KiB 0 B 0 B pool2 0 B 0 0 0 0 0 0 0 0 B 0 0 B 0 B 0 B pool3 333 MiB 37 0 111 0 0 0 3169308 2.5 GiB 14847 118 MiB 0 B 0 B pool4 1.1 MiB 13 0 39 0 0 0 1379568 1.1 GiB 16840 16 MiB 0 B 0 B
A continuación se ofrece una descripción de cada columna:
USED
El número de bytes utilizados por el repositorio.
198 Visualización de estadísticas de repositorios SES 7
OBJECTS
El número de objetos almacenados en el repositorio.
CLONES
El número de clones almacenados en el repositorio. Cuando se crea una instantánea y seescribe en un objeto, en lugar de modicar el objeto original, se crea su clon para que nose modique el contenido del objeto original del que se ha hecho la instantánea.
COPIES
El número de réplicas del objeto. Por ejemplo, si un repositorio replicado con el factor deréplica 3 tiene x objetos, normalmente tendrá 3 * x copias.
MISSING_ON_PRIMARY
El número de objetos en estado degradado (no existen todas las copias) mientras falta lacopia en el OSD primario.
UNFOUND
El número de objetos no encontrados.
DEGRADED
El número de objetos degradados.
RD_OPS
El número total de operaciones de lectura pedidas para este repositorio.
RD
El número total de bytes leídos de este repositorio.
WR_OPS
El número total de operaciones de escritura pedidas para este repositorio.
WR
El número total de bytes escritos en el repositorio. Tenga en cuenta que no es lo mismoque el uso del repositorio, ya que es posible escribir en el mismo objeto muchas veces. Elresultado es que el uso del repositorio seguirá siendo el mismo, pero el número de bytesescritos en el repositorio aumentará.
USED COMPR
El número de bytes asignados para datos comprimidos.
UNDER COMPR
El número de bytes que ocupan los datos comprimidos cuando no están comprimidos
199 Visualización de estadísticas de repositorios SES 7
18.5.4 Obtención de valores de repositorio
Para obtener un valor de un repositorio, ejecute el comando get siguiente:
cephuser@adm > ceph osd pool get POOL_NAME KEY
Puede obtener los valores de las claves indicadas en la Sección 18.5.5, “Definición de valores de
repositorio”, además de las siguientes:
PG_NUM
El número de grupos de colocación del repositorio.
PGP_NUM
El número efectivo de grupos de colocación que se deben utilizar para calcular lacolocación de los datos. El intervalo válido es igual o menor que PG_NUM .
Sugerencia: todos los valores de un repositorioPara mostrar todos los valores relacionados con un repositorio especíco, ejecute:
cephuser@adm > ceph osd pool get POOL_NAME all
18.5.5 Definición de valores de repositorio
Para denir un valor para un repositorio, ejecute:
cephuser@adm > ceph osd pool set POOL_NAME KEY VALUE
A continuación se muestra una lista de valores de repositorio ordenados por tipo de repositorio:
VALORES DE REPOSITORIO COMUNES
crash_replay_interval
El número de segundos que se debe permitir a los clientes que reproduzcan peticionesreconocidas, pero no conrmadas.
pg_num
El número de grupos de colocación del repositorio. Si añade nuevos OSD al clúster,verique el valor de los grupos de colocación en todos los repositorios de destino paralos nuevos OSD.
pgp_num
200 Obtención de valores de repositorio SES 7
El número efectivo de grupos de colocación que se deben utilizar para calcular lacolocación de los datos.
crush_ruleset
El conjunto de reglas que se debe utilizar para asignar la colocación en el clúster.
hashpspool
Establece (1) o anula (0) el indicador HASHPSPOOL en un repositorio. Cuando sehabilita este indicador, el algoritmo cambia para mejorar la distribución de los grupos decolocación a los OSD. Después de habilitar el indicador en un repositorio cuyo indicadorHASHPSPOOL se ha denido con el valor por defecto, 0, el clúster inicia la reposiciónpara que todos los grupos vuelvan a la colocación correcta. Tenga en cuenta que estopuede crear una carga de E/S bastante sustancial en un clúster; por lo tanto, no habilite elindicador de 0 a 1 en clústeres de producción con mucha carga.
nodelete
Impide la eliminación del repositorio.
nopgchange
Impide que se modiquen los valores pg_num y pgp_num del repositorio.
noscrub,nodeep-scrub
Inhabilita la depuración (profunda) de los datos para el repositorio especíco, a n deresolver un pico temporal de carga de E/S.
write_fadvise_dontneed
Dena o anule la denición del indicador WRITE_FADVISE_DONTNEED en las peticiones delectura/escritura de un repositorio determinado para omitir la colocación de datos en elcaché. El valor por defecto es false (falso). Se aplica tanto a los repositorios replicadoscomo a los codicados de borrado.
scrub_min_interval
El intervalo mínimo en segundos para el borrado seguro de datos del repositorio cuandola carga del clúster es reducida. El valor 0 por defecto signica que se utiliza el valorosd_scrub_min_interval del archivo de conguración de Ceph.
scrub_max_interval
El intervalo máximo en segundos para el borrado seguro de datos del repositorio,independientemente de la carga del clúster. El valor 0 por defecto signica que se utilizael valor osd_scrub_max_interval del archivo de conguración de Ceph.
201 Definición de valores de repositorio SES 7
deep_scrub_interval
El intervalo en segundos para el borrado seguro profundo del repositorio. El valor 0 pordefecto signica que se utiliza el valor osd_deep_scrub del archivo de conguración deCeph.
VALORES DE REPOSITORIO REPLICADOS
size
Dene el número de réplicas para los objetos del repositorio. Consulte la Sección 18.5.6,
“Definición del número de réplicas de objetos” para obtener más información. Solo pararepositorios replicados.
min_size
Dene el número mínimo de réplicas obligatorias para E/S. Consulte la Sección 18.5.6,
“Definición del número de réplicas de objetos” para obtener más información. Solo pararepositorios replicados.
nosizechange
Impide que se modique el tamaño del repositorio. Cuando se crea un repositorio, el valorpor defecto se toma del valor del parámetro osd_pool_default_flag_nosizechange ,que es false por defecto. Se aplica a los repositorios replicados solo porque no se puedecambiar el tamaño de los repositorios codicados de borrado.
hit_set_type
Habilita el seguimiento de conjuntos de resultados para repositorios de caché. Consulteeste artículo sobre los filtros de Bloom (http://en.wikipedia.org/wiki/Bloom_filter) paraobtener más información. Esta opción puede tener los valores siguientes: bloom ,explicit_hash o explicit_object . El valor por defecto es bloom , los demás solo seemplean para realizar pruebas.
hit_set_count
El número de conjuntos de resultados que se deben almacenar en los repositorios de caché.Cuanto mayor sea el número, más RAM consumirá el daemon ceph-osd . El valor pordefecto es 0 .
hit_set_period
La duración en segundos de un periodo de conjunto de resultados para los repositoriosde caché. Cuanto mayor sea el número, más RAM consumirá el daemon ceph-osd .Cuando se crea un repositorio, el valor por defecto se toma del valor del parámetro
202 Definición de valores de repositorio SES 7
osd_tier_default_cache_hit_set_period , que es 1200 por defecto. Se aplica a losrepositorios replicados solo porque los repositorios codicados de borrado no se puedenusar como nivel de caché.
hit_set_fpp
La probabilidad de falsos positivos para el tipo de conjunto de resultados del ltrode Bloom. Consulte este artículo sobre los filtros de Bloom (http://en.wikipedia.org/wiki/
Bloom_filter) para obtener más información. El intervalo válido es de 0.0 a 1.0; el valorpredeterminado es 0.05
use_gmt_hitset
Forzar a los OSD para que utilicen marcas horarias GMT (hora del meridiano de Greenwich)al crear un conjunto de resultados para los niveles de caché. Esto garantiza que los nodosde distintas zonas horarias devuelvan el mismo resultado. El valor por defecto es 1 . Estevalor no debe cambiarse.
cache_target_dirty_ratio
El porcentaje del repositorio de caché que debe contener objetos modicados (sucios) paraque el agente de niveles de caché los vacíe en el repositorio de almacenamiento. El valorpor defecto es 0.4 .
cache_target_dirty_high_ratio
El porcentaje del repositorio de caché que debe contener objetos modicados (sucios) paraque el agente de niveles de caché los vacíe en el repositorio de almacenamiento a mayorvelocidad. El valor por defecto es 0.6 .
cache_target_full_ratio
El porcentaje del repositorio de caché que debe contener objetos no modicados (limpios)para que el agente de niveles de caché los expulse del repositorio de caché. El valor pordefecto es 0.8 .
target_max_bytes
Ceph comenzará a expulsar o limpiar objetos cuando se active el umbral establecido enmax_bytes .
target_max_objects
Ceph comenzará a expulsar o limpiar objetos cuando se active el umbral establecido enmax_objects .
hit_set_grade_decay_rate
203 Definición de valores de repositorio SES 7
Velocidad de caída de temperatura entre dos hit_set s sucesivos. El valor por defectoes 20 .
hit_set_search_last_n
Deben contarse como máximo N apariciones en hit_set s para calcular la temperatura.El valor por defecto es 1 .
cache_min_flush_age
El tiempo (en segundos) que debe transcurrir para que el agente de niveles de caché muevaun objeto del repositorio de caché al de almacenamiento.
cache_min_evict_age
El tiempo (en segundos) que debe transcurrir para que el agente de niveles de caché expulseun objeto del repositorio de caché.
VALORES DE REPOSITORIO CODIFICADO DE BORRADO
fast_read
Si este indicador está habilitado en los repositorios codicados de borrado, las peticionesde lectura emite sublecturas a todos los shards y espera a recibir sucientes shards quedescodicar para ofrecer servicio al cliente. En el caso de los complementos de borradojerasure e isa, cuando vuelve la respuesta K , la petición del cliente se atiende de inmediatocon los datos descodicados a partir de estas respuestas. Este enfoque provoca más cargade CPU y menos carga de disco/red. Actualmente, este indicador solo se admite para losrepositorios codicados de borrado. El valor por defecto es 0 .
18.5.6 Definición del número de réplicas de objetos
Para establecer el número de réplicas de objetos en un repositorio replicado, ejecute lo siguiente:
cephuser@adm > ceph osd pool set poolname size num-replicas
El valor num-replicas incluye el objeto en sí. Por ejemplo, si quiere que existan el objeto ydos copias (tres instancias en total), especique 3.
Aviso: no defina menos de 3 réplicasSi establece un valor de 2 en num-replicas , solo habrá una copia de los datos. Si pierdeuna instancia de un objeto, para recuperarlo debe poder conar en que la otra copia nohaya sufrido daños, por ejemplo, desde el último borrado seguro (consulte la Sección 17.6,
“Depuración de grupos de colocación” para obtener más detalles).
204 Definición del número de réplicas de objetos SES 7
Si establece solo una réplica en el repositorio, signica que habrá exactamente una únicainstancia del objeto de datos. Si el OSD falla, se perderán los datos. Un posible uso de unrepositorio con una réplica es el almacenamiento temporal de datos durante poco tiempo.
Sugerencia: definición de más de 3 réplicasSi se denen 4 réplicas para un repositorio, la abilidad aumenta en un 25%.
En el caso de dos centros de datos, debe denir al menos 4 réplicas para que un repositoriotenga dos copias en cada centro de datos. De este modo, si se pierde un centro de datos,aún existen dos copias y se puede perder un disco más sin que se pierdan datos.
NotaUn objeto puede aceptar operaciones de E/S en modo degradado con menos réplicas delas indicadas en pool size . Para congurar un número mínimo de réplicas necesariaspara las operaciones de E/S, debe utilizar el valor min_size . Por ejemplo:
cephuser@adm > ceph osd pool set data min_size 2
Esto garantiza que ningún objeto del repositorio de datos recibirá operaciones de E/S conmenos réplicas de las indicadas en min_size .
Sugerencia: obtención del número de réplicas de objetosPara obtener el número de réplicas de objetos, ejecute lo siguiente:
cephuser@adm > ceph osd dump | grep 'replicated size'
Ceph enumerará los grupos con el atributo replicated size destacado. Ceph crea pordefecto dos réplicas de cada objeto (un total de tres copias o un tamaño de 3).
205 Definición del número de réplicas de objetos SES 7
18.6 Migración de repositorios
Al crear un repositorio (consulte la Sección 18.1, “Creación de un repositorio”) debe especicar susparámetros iniciales, como el tipo de repositorio o el número de grupos de colocación. Si másadelante decide cambiar cualquiera de estos parámetros (por ejemplo, al convertir un repositorioreplicado en uno codicado de borrado o al disminuir el número de grupos de colocación), debemigrar los datos del repositorio a otro cuyos parámetros se adapten a la distribución.
En esta sección se describen dos métodos de migración: un método de nivel de caché parala migración de datos de repositorios generales y un método que utiliza los subcomandosrbd migrate para migrar imágenes RBD a un repositorio nuevo. Cada método tiene susparticularidades y limitaciones.
18.6.1 Limitaciones
Puede usar el método de niveles de caché para migrar desde un repositorio replicado a unrepositorio codicado de borrado o a otro repositorio replicado. No se admite la migracióndesde un repositorio codicado de borrado.
No se pueden migrar imágenes RBD ni exportaciones de CephFS de un repositorio replicadoa un repositorio codicado de borrado. La razón es que los repositorios codicados deborrado no admiten omap , mientras que RBD y CephFS utilizan omap para almacenar susmetadatos. Por ejemplo, el objeto de encabezado del RBD no se podrá vaciar. Sin embargo,es posible migrar los datos al repositorio codicado de borrado y dejar los metadatos enel repositorio replicado.
El método rbd migration permite migrar imágenes con el mínimo tiempo de inactividaddel cliente. Solo es necesario detener el cliente antes del paso de preparación e iniciarlodespués. Tenga en cuenta que solo un cliente librbd que admita esta característica (CephNautilus o posterior) podrá abrir la imagen justo después del paso de preparación ,mientras que los clientes librbd más antiguos o los clientes krbd no podrán abrir laimagen hasta que ejecute el paso de asignación .
206 Migración de repositorios SES 7
18.6.2 Migración mediante el nivel de caché
El principio básico es simple: incluir el repositorio que quiere migrar en un nivel de caché enorden inverso. En el ejemplo siguiente se migra un repositorio replicado denominado "testpool"a un repositorio codicado de borrado:
PROCEDIMIENTO 18.1: MIGRACIÓN DE UN REPOSITORIO REPLICADO A UN REPOSITORIO CODIFICADO DEBORRADO
1. Cree un nuevo repositorio codicado de borrado y llámelo "newpool". Consulte laSección 18.1, “Creación de un repositorio” para obtener una explicación detallada de losparámetros de creación de repositorios.
cephuser@adm > ceph osd pool create newpool erasure default
Verique que el anillo de claves de cliente utilizado proporcione al menos las mismascapacidades para "newpool" que para "testpool".Ahora tiene dos repositorios: el original replicado y lleno de datos ("testpool") y el nuevorepositorio codicado de borrado vacío ("newpool"):
FIGURA 18.1: REPOSITORIOS ANTES DE LA MIGRACIÓN
2. Congure los niveles de caché y establezca el repositorio replicado "testpool" comorepositorio de caché. La opción -force-nonempty permite añadir un nivel de cachéincluso si el repositorio ya tiene datos:
cephuser@adm > ceph tell mon.* injectargs \ '--mon_debug_unsafe_allow_tier_with_nonempty_snaps=1'cephuser@adm > ceph osd tier add newpool testpool --force-nonemptycephuser@adm > ceph osd tier cache-mode testpool proxy
207 Migración mediante el nivel de caché SES 7
FIGURA 18.2: CONFIGURACIÓN DE LOS NIVELES DE CACHÉ
3. Ejecute un traslado forzoso de todos los objetos del repositorio de caché al nuevorepositorio:
cephuser@adm > rados -p testpool cache-flush-evict-all
FIGURA 18.3: LIMPIEZA DE DATOS
4. Hasta que todos los datos se hayan movido al nuevo repositorio codicado de borrado,es preciso especicar una superposición para que los objetos se busquen en el repositorioantiguo:
cephuser@adm > ceph osd tier set-overlay newpool testpool
Con la superposición, todas las operaciones se reenvían al repositorio replicado antiguo("testpool"):
FIGURA 18.4: CONFIGURACIÓN DE LA SUPERPOSICIÓN
Ahora puede congurar todos los clientes para que accedan a los objetos en el nuevorepositorio.
208 Migración mediante el nivel de caché SES 7
5. Una vez migrados todos los datos al repositorio codicado de borrado "newpool", eliminela superposición y el repositorio de caché antiguo ("testpool"):
cephuser@adm > ceph osd tier remove-overlay newpoolcephuser@adm > ceph osd tier remove newpool testpool
FIGURA 18.5: MIGRACIÓN COMPLETADA
6. Ejecute:
cephuser@adm > ceph tell mon.* injectargs \ '--mon_debug_unsafe_allow_tier_with_nonempty_snaps=0'
18.6.3 Migración de imágenes RBD
A continuación se muestra la forma recomendada de migrar imágenes RBD de un repositorioreplicado a otro repositorio replicado.
1. Detenga el acceso de los clientes (como una máquina virtual) a la imagen RBD.
2. Cree una nueva imagen en el repositorio de destino, con la imagen de origen comoelemento padre:
cephuser@adm > rbd migration prepare SRC_POOL/IMAGE TARGET_POOL/IMAGE
Sugerencia: migración solo de datos a un repositoriocodificado de borradoSi necesita migrar solo los datos de imagen a un nuevo repositorio codicadode borrado y dejar los metadatos en el repositorio replicado original, ejecute elsiguiente comando:
cephuser@adm > rbd migration prepare SRC_POOL/IMAGE \ --data-pool TARGET_POOL/IMAGE
209 Migración de imágenes RBD SES 7
3. Permita que los clientes accedan a la imagen en el repositorio de destino.
4. Migre los datos al repositorio de destino:
cephuser@adm > rbd migration execute SRC_POOL/IMAGE
5. Elimine la imagen antigua:
cephuser@adm > rbd migration commit SRC_POOL/IMAGE
18.7 Instantáneas de repositoriosLas instantáneas de repositorios son instantáneas del estado del repositorio Ceph completo. Conlas instantáneas de repositorios, es posible conservar el historial de estado del repositorio. Crearinstantáneas de repositorio consume un espacio de almacenamiento proporcional al tamaño delrepositorio. Compruebe siempre que hay espacio de almacenamiento suciente antes de crearla instantánea de un repositorio.
18.7.1 Creación de una instantánea de un repositorio
Para crear una instantánea de un repositorio, ejecute:
cephuser@adm > ceph osd pool mksnap POOL-NAME SNAP-NAME
Por ejemplo:
cephuser@adm > ceph osd pool mksnap pool1 snap1created pool pool1 snap snap1
18.7.2 Lista de las instantáneas de un repositorio
Para mostrar las instantáneas existentes de un repositorio, ejecute:
cephuser@adm > rados lssnap -p POOL_NAME
Por ejemplo:
cephuser@adm > rados lssnap -p pool11 snap1 2018.12.13 09:36:202 snap2 2018.12.13 09:46:032 snaps
210 Instantáneas de repositorios SES 7
18.7.3 Eliminación de una instantánea de un repositorio
Para eliminar una instantánea de un repositorio, ejecute:
cephuser@adm > ceph osd pool rmsnap POOL-NAME SNAP-NAME
18.8 Compresión de datosBlueStore (encontrará más información en Libro “Guía de distribución”, Capítulo 1 “SES y Ceph”,
Sección 1.4 “BlueStore”) proporciona compresión de datos sobre la marcha para ahorrar espacioen disco. La relación de compresión depende de los datos almacenados en el sistema. Tenga encuenta que la compresión/descompresión requiere potencia de CPU adicional.
Puede congurar la compresión de datos a nivel global (consulte la Sección 18.8.3, “Opciones de
compresión global”) y, a continuación, sustituir la conguración especíca para cada repositorioindividual.
Es posible habilitar o inhabilitar la compresión de datos del repositorio o cambiar el algoritmo yel modo de compresión en cualquier momento, independientemente de si el repositorio contienedatos o no.
No se aplicará ninguna compresión a los datos existentes después de habilitar la compresióndel repositorio.
Después de inhabilitar la compresión de un repositorio, todos sus datos se descomprimirán.
18.8.1 Habilitación de la compresión
Para habilitar la compresión de datos para un repositorio denominado POOL_NAME , ejecute elsiguiente comando:
cephuser@adm > ceph osd pool set POOL_NAME compression_algorithm COMPRESSION_ALGORITHMcephuser@adm > ceph osd pool set POOL_NAME compression_mode COMPRESSION_MODE
Sugerencia: inhabilitación de la compresión de repositoriosPara inhabilitar la compresión de datos para un repositorio, utilice "none" como algoritmode compresión:
cephuser@adm > ceph osd pool set POOL_NAME compression_algorithm none
211 Eliminación de una instantánea de un repositorio SES 7
18.8.2 Opciones de compresión de repositorios
Este es un listado completo de las opciones de compresión:
compression_algorithm
Los valores posibles son none , zstd y snappy . El valor por defecto es snappy .El algoritmo de compresión utilizado depende del caso de uso especíco. A continuacións ofrecen varias recomendaciones:
Utilice el valor por defecto, snappy , si no tiene una buena razón para cambiarlo.
zstd ofrece una buena relación de compresión, pero causa una alta sobrecarga deCPU cuando comprime pequeñas cantidades de datos.
Ejecute una comparativa de estos algoritmos en una muestra de sus datos reales yobserve el uso de CPU y memoria en su clúster.
compression_mode
Los valores posibles son none , aggressive , passive y force . El valor por defecto esnone .
none : no comprimir nunca
passive : comprimir si se sugiere COMPRESSIBLE
aggressive : comprimir a menos que se sugiera INCOMPRESSIBLE
force : comprimir siempre
compression_required_ratio
Valor: doble, proporción = SIZE_COMPRESSED / SIZE_ORIGINAL. El valor por defecto es0.875 , lo que signica que si la compresión no reduce el espacio ocupado en al menosun 12,5 %, el objeto no se comprimirá.Los objetos por encima de esta proporción no se almacenarán comprimidos, ya que elbenecio neto es bajo.
compression_max_blob_size
Valor: entero sin rmar, tamaño en bytes. Por defecto: 0El tamaño máximo de los objetos comprimidos.
compression_min_blob_size
Valor: entero sin rmar, tamaño en bytes. Por defecto: 0El tamaño mínimo de los objetos comprimidos.
212 Opciones de compresión de repositorios SES 7
18.8.3 Opciones de compresión global
Las siguientes opciones de conguración se pueden denir en la conguración de Ceph y seaplican a todos los OSD y no a un solo repositorio. La conguración especíca del repositorioindicada en la Sección 18.8.2, “Opciones de compresión de repositorios” tendrá prioridad.
bluestore_compression_algorithm
Consulte compression_algorithm
bluestore_compression_mode
Consulte compression_mode
bluestore_compression_required_ratio
Consulte compression_required_ratio
bluestore_compression_min_blob_size
Valor: entero sin rmar, tamaño en bytes. Por defecto: 0El tamaño mínimo de los objetos comprimidos. La conguración seomite por defecto si se usa bluestore_compression_min_blob_size_hdd ybluestore_compression_min_blob_size_ssd . Tiene prioridad cuando se dene unvalor distinto a cero.
bluestore_compression_max_blob_size
Valor: entero sin rmar, tamaño en bytes. Por defecto: 0El tamaño máximo de los objetos que se comprimen antes dedividirse en fragmentos más pequeños. La conguración se omitepor defecto si se usa bluestore_compression_max_blob_size_hdd ybluestore_compression_max_blob_size_ssd . Tiene prioridad cuando se dene unvalor distinto a cero.
bluestore_compression_min_blob_size_ssd
Valor: entero sin rmar, tamaño en bytes. Por defecto: 8KTamaño mínimo de los objetos comprimidos y almacenados en la unidad de estado sólido.
bluestore_compression_max_blob_size_ssd
Valor: entero sin rmar, tamaño en bytes. Por defecto: 64KEl tamaño máximo de los objetos que se comprimen y se almacenan en unidades de estadosólido antes de dividirse en fragmentos más pequeños.
bluestore_compression_min_blob_size_hdd
Valor: entero sin rmar, tamaño en bytes. Por defecto: 128K
213 Opciones de compresión global SES 7
Tamaño mínimo de los objetos comprimidos y almacenados en los discos duros.
bluestore_compression_max_blob_size_hdd
Valor: entero sin rmar, tamaño en bytes. Por defecto: 512KEl tamaño máximo de los objetos que se comprimen y se almacenan en discos duros antesde dividirse en fragmentos más pequeños.
214 Opciones de compresión global SES 7
19 Repositorios codificados de borrado
Ceph ofrece una alternativa a la réplica normal de datos en repositorios denominada borrado orepositorio codicado de borrado. Los repositorios de borrado no proporcionan todas las funcionesde los repositorios replicados (por ejemplo, no pueden almacenar metadatos para los repositoriosRBD), pero requieren menos almacenamiento en bruto. Un repositorio de borrado por defectocapaz de almacenar 1 TB de datos requiere 1,5 TB de almacenamiento en bruto, lo que permiteun único fallo del disco. Esto es una ventaja respecto a un repositorio replicado, que necesita2 TB de almacenamiento en bruto para el mismo propósito.
Para obtener información básica sobre la codicación de borrado, consulte https://
en.wikipedia.org/wiki/Erasure_code .
Para obtener una lista de los valores de repositorio relacionados con los repositorios codicadosde borrado, consulte Valores de repositorio codificado de borrado.
19.1 Requisitos previos para los repositorioscodificados de borrado
Para hacer uso de la codicación de borrado, debe hacer lo siguiente:
Dena una regla de borrado en el mapa de CRUSH.
Dena un perl codicado de borrado que especique el algoritmo de codicación quese debe utilizar.
Cree un repositorio utilizando la regla y el perl mencionados anteriormente.
Tenga en cuenta que cambiar el perl y sus detalles no será posible después de que se cree elrepositorio y de que tenga datos.
Asegúrese de que las reglas de CRUSH para los repositorios de borrado utilizan indep para step .Para obtener información, consulte la Sección 17.3.2, “firstn e indep”.
215 Requisitos previos para los repositorios codificados de borrado SES 7
19.2 Creación de un repositorio codificado deborrado de ejemploEl repositorio codicado de borrado más sencillo es equivalente a RAID5 y requiere al menostres hosts. Este procedimiento describe cómo crear un repositorio con nes de prueba.
1. El comando ceph osd pool create se utiliza para crear un repositorio de tipo erasure.El 12 signica el número de grupos de colocación. Con los parámetros por defecto, elrepositorio es capaz de gestionar situaciones en las que falle un OSD.
cephuser@adm > ceph osd pool create ecpool 12 12 erasurepool 'ecpool' created
2. La cadena ABCDEFGHI se escribe en un objeto denominado NYAN .
cephuser@adm > echo ABCDEFGHI | rados --pool ecpool put NYAN -
3. Con nes de prueba, los OSD se pueden inhabilitar ahora, por ejemplo, desconectándolosde la red.
4. Para probar si el repositorio puede gestionar el fallo de dispositivos, se puede acceder alcontenido del archivo con el comando rados .
cephuser@adm > rados --pool ecpool get NYAN -ABCDEFGHI
19.3 Perfiles de código de borradoCuando se invoca el comando ceph osd pool create para crear un repositorio de borrado, seutiliza el perl por defecto, a menos que se especique otro perl distinto. Los perles denen laredundancia de los datos. Para ello se denen dos parámetros, que reciben el nombre arbitrariode k y m . Los parámetros k y m denen en cuántas porciones se divide un dato y cuántasporciones de codicación se crean. Las porciones redundantes se almacenan en diferentes OSD.
Deniciones necesarias para los perles de repositorio de borrado:
porción
Cuando se llama a la función de codicación, se devuelven porciones del mismo tamaño:porciones de datos que pueden concatenarse para reconstruir el objeto original y porcionesde codicación que se pueden usar para reconstruir una porción perdida.
216 Creación de un repositorio codificado de borrado de ejemplo SES 7
k
El número de porciones de datos, que es el número de porciones en las que se divide elobjeto original. Por ejemplo, si k = 2 , un objeto de 10 kB se divide en k objetos de 5 kB.El valor de min_size por defecto en los repositorios codicados de borrado es k + 1 .Sin embargo, se recomienda que min_size sea k + 2 o más para evitar la pérdida deescrituras y datos.
m
El número de porciones de codicación, que es el número de porciones adicionalescalculadas por las funciones de codicación. Si hay 2 porciones de codicación, signicaque pueden fallar dos OSD sin que se pierda ningún dato.
crush-failure-domain
Dene a qué dispositivos se distribuyen las porciones. Como valor se debe denir un tipode depósito. Para ver todos los tipos de depósitos, consulte la Sección 17.2, “Depósitos”. Siel dominio de fallo es rack , las porciones se almacenarán en bastidores diferentes paraaumentar la capacidad de recuperación en caso de fallos del bastidor. Tenga en cuenta queesto requiere bastidores k + m.
Con el perl codicado de borrado por defecto utilizado en la Sección 19.2, “Creación de un
repositorio codificado de borrado de ejemplo”, no perderá datos del clúster si se produce un erroren un único OSD o host. Por lo tanto, para almacenar 1 TB de datos, necesita otros 0,5 TBde almacenamiento en bruto. Eso signica que se necesitan 1,5 TB de almacenamiento enbruto para 1 TB de datos (dado que k = 2, m = 1). Esto equivale a una conguración RAID5común. En comparación, un repositorio replicado necesita 2 TB de almacenamiento en brutopara almacenar 1 TB de datos.
Para mostrar los valores del perl por defecto:
cephuser@adm > ceph osd erasure-code-profile get defaultdirectory=.libsk=2m=1plugin=jerasurecrush-failure-domain=hosttechnique=reed_sol_van
Es importante elegir el perl correcto, ya que no se puede modicar después de que se creeel repositorio. Se debe crear un repositorio nuevo con un perl distinto y todos los objetos delrepositorio anterior se deben pasar al nuevo (consulte la Sección 18.6, “Migración de repositorios”).
217 Perfiles de código de borrado SES 7
Los parámetros más importantes del perl son k , m y crush-failure-domain , ya que denenla sobrecarga de almacenamiento y la duración de los datos. Por ejemplo, si la arquitectura debeaguantar la pérdida de dos bastidores con una sobrecarga de almacenamiento del 66 %, puededenir el perl siguiente. Tenga en cuenta que esto solo es válido con un mapa de CRUSH quetenga depósitos de tipo "bastidor":
cephuser@adm > ceph osd erasure-code-profile set myprofile \ k=3 \ m=2 \ crush-failure-domain=rack
El ejemplo de la Sección 19.2, “Creación de un repositorio codificado de borrado de ejemplo” se puederepetir con este nuevo perl:
cephuser@adm > ceph osd pool create ecpool 12 12 erasure myprofilecephuser@adm > echo ABCDEFGHI | rados --pool ecpool put NYAN -cephuser@adm > rados --pool ecpool get NYAN -ABCDEFGHI
El objeto NYAN se dividirá en tres ( k=3 ) y se crearán dos porciones adicionales ( m=2 ). El valorde m dene cuántos OSD pueden fallar al mismo tiempo sin que se pierda ningún dato. El valorcrush-failure-domain=rack crea un conjunto de reglas de CRUSH que garantiza que no sealmacenarán dos porciones en el mismo bastidor.
218 Perfiles de código de borrado SES 7
19.3.1 Creación de un nuevo perfil codificado de borrado
El siguiente comando crea un nuevo perl codicado de borrado:
root # ceph osd erasure-code-profile set NAME \ directory=DIRECTORY \ plugin=PLUGIN \ stripe_unit=STRIPE_UNIT \ KEY=VALUE ... \ --force
DIRECTORY
Opcional. Dena el nombre del directorio desde el que se carga el complemento codicadode borrado. El valor por defecto es /usr/lib/ceph/erasure-code .
219 Creación de un nuevo perfil codificado de borrado SES 7
PLUGIN
Opcional. Utilice el complemento codicado de borrado para calcular fragmentos decodicación y recuperar fragmentos que falten. Los complementos disponibles son"jerasure", "isa", "lrc" y "shes". El valor por defecto es "jerasure".
STRIPE_UNIT
Opcional. Indica la cantidad de datos de un fragmento de datos, por repartición. Porejemplo, un perl con 2 fragmentos de datos y el valor stripe_unit=4K colocaría elrango 0-4K en el fragmento 0, el rango 4K-8K en el fragmento 1 y el rango 8K-12Ken el fragmento 0 de nuevo. Debe ser un múltiplo de 4K para obtener el mejorrendimiento. El valor por defecto se toma de la opción de conguración del monitorosd_pool_erasure_code_stripe_unit cuando se crea un repositorio. El valor de"stripe_width" de un repositorio que utilice este perl será el número de fragmentos dedatos multiplicado por este valor de "stripe_unit".
KEY=VALUE
Los pares clave/valor de las opciones especícas del complemento codicado de borradoseleccionado.
##force
Opcional. Sustituye un perl existente con el mismo nombre y permite denir un valor destripe_unit no alineado con 4K.
19.3.2 Eliminación de un perfil codificado de borrado
El comando siguiente elimina un perl codicado de borrado identicado por el valor de NAME(Nombre):
root # ceph osd erasure-code-profile rm NAME
ImportanteSi un repositorio hace referencia al perl, la supresión fallará.
220 Eliminación de un perfil codificado de borrado SES 7
19.3.3 Visualización de los detalles de un perfil codificado deborrado
El comando siguiente muestra los detalles de un perl codicado de borrado identicado porel valor de NAME (Nombre):
root # ceph osd erasure-code-profile get NAME
19.3.4 Listado de perfiles codificados de borrado
El comando siguiente muestra los nombres de todos los perles codicado de borrado:
root # ceph osd erasure-code-profile ls
19.4 Marcado de repositorios codificados de borradocon un dispositivo de bloques RADOSPara marcar un repositorio codicado de borrado como un repositorio RBD, etiquételo enconsecuencia:
cephuser@adm > ceph osd pool application enable rbd ec_pool_name
RBD puede almacenar datos de imagen en repositorios codicados de borrado. Sin embargo, elencabezado de la imagen y los metadatos deberán almacenarse aún en un repositorio replicado.Suponiendo que el nombre del repositorio sea "rbd":
cephuser@adm > rbd create rbd/image_name --size 1T --data-pool ec_pool_name
Puede utilizar la imagen con normalidad como cualquier otra, excepto por el hecho de que todoslos datos se almacenarán en el repositorio ec_pool_name , en lugar de en el repositorio "rbd".
221 Visualización de los detalles de un perfil codificado de borrado SES 7
20 Dispositivo de bloques RADOS
Un bloque es una secuencia de bytes, por ejemplo, un bloque de 4 MB de datos. Las interfacesde almacenamiento basadas en bloques son la forma más habitual de almacenar los datos ensoportes de uso rotativo, como discos duros, CD o disquetes. La ubicuidad de las interfaces dedispositivos de bloques hacen que un dispositivo de bloques virtual sea el candidato idóneo parainteractuar con un sistema de almacenamiento masivo de datos como Ceph.
Los dispositivos de bloques de Ceph permiten compartir recursos físicos y se puede modicar sutamaño. Los datos se almacenan repartidos en varios OSD en un clúster de Ceph. Los dispositivosde bloques de Ceph aprovechan las funciones de RADOS, como la realización de instantáneas,las réplicas y la comprobación de coherencia. Los dispositivos de bloques RADOS (RBD) de Cephinteractúan con los OSD mediante módulos del kernel o la biblioteca librbd .
FIGURA 20.1: PROTOCOLO RADOS
Los dispositivos de bloques de Ceph ofrecen un alto rendimiento con innitas posibilidades deescalabilidad para los módulos de kernel. Son compatibles con soluciones de virtualización comoQEMU o sistemas informáticos basados en la nube que dependen de libvirt , como OpenStack.Puede utilizar el mismo clúster para gestionar Object Gateway, CephFS y los dispositivos debloques RADOS al mismo tiempo.
20.1 Comandos del dispositivo de bloques
El comando rbd permite crear, enumerar, examinar y eliminar imágenes de los dispositivosde bloques. También se puede emplear, por ejemplo, para clonar imágenes, crear instantáneas,revertir una imagen al estado de una instantánea o ver una instantánea.
222 Comandos del dispositivo de bloques SES 7
20.1.1 Creación de una imagen del dispositivo de bloques en unrepositorio replicado
Antes de poder añadir un dispositivo de bloques a un cliente, debe crear una imagen relacionadaen un repositorio existente (consulte el Capítulo 18, Gestión de repositorios de almacenamiento):
cephuser@adm > rbd create --size MEGABYTES POOL-NAME/IMAGE-NAME
Por ejemplo, para crear una imagen de 1 GB denominada "myimage" que almacena informaciónen un repositorio llamado "mypool", ejecute lo siguiente:
cephuser@adm > rbd create --size 1024 mypool/myimage
Sugerencia: unidades de tamaño de imagenSi omite un acceso directo de unidad de tamaño ("G" o "T"), el tamaño de la imagen seindicará en megabytes. Utilice "G" o "T" después del número de tamaño para especicargigabytes o terabytes.
20.1.2 Creación de una imagen del dispositivo de bloques en unrepositorio codificado de borrado
Es posible almacenar datos de una imagen de dispositivo de bloques directamente en repositorioscodicados de borrado. Una imagen de dispositivo de bloques RADOS está formada porelementos de datos y metadatos. Solo se puede almacenar la parte de datos de una imagen dedispositivo de bloques RADOS en un repositorio codicado de borrado. El repositorio debe teneren el indicador overwrite el valor true denido, y eso solo es posible si todos los OSD dondese almacena el repositorio utilizan BlueStore.
No es posible almacenar la parte de metadatos de la imagen en un repositorio codicado deborrado. Puede especicar el repositorio replicado para almacenar los metadatos de la imagencon la opción --pool= del comando rbd create o especicar pool/ como prejo del nombrede la imagen.
Cree un repositorio codicado de borrado:
cephuser@adm > ceph osd pool create EC_POOL 12 12 erasurecephuser@adm > ceph osd pool set EC_POOL allow_ec_overwrites true
223 Creación de una imagen del dispositivo de bloques en un repositorio replicado SES 7
Especique el repositorio replicado para almacenar los metadatos:
cephuser@adm > rbd create IMAGE_NAME --size=1G --data-pool EC_POOL --pool=POOL
O bien:
cephuser@adm > rbd create POOL/IMAGE_NAME --size=1G --data-pool EC_POOL
20.1.3 Listado de imágenes de dispositivos de bloques
Para mostrar los dispositivos de bloques en un repositorio denominado "mypool", ejecute losiguiente:
cephuser@adm > rbd ls mypool
20.1.4 Recuperación de información de la imagen
Para recuperar información de una imagen denominada "myimage" dentro de un repositoriodenominado "mypool", ejecute lo siguiente:
cephuser@adm > rbd info mypool/myimage
20.1.5 Cambio de tamaño de la imagen de un dispositivo debloques
Las imágenes de los dispositivos de bloques RADOS emplean un sistema de provisión ligera, loque signica que no emplean espacio físico real hasta que empieza a guardar datos en ellos.No obstante, tienen una capacidad máxima que se dene mediante la opción ‑‑size . Si deseaaumentar (o reducir) el tamaño máximo de la imagen (o disminuir), ejecute lo siguiente:
cephuser@adm > rbd resize --size 2048 POOL_NAME/IMAGE_NAME # to increasecephuser@adm > rbd resize --size 2048 POOL_NAME/IMAGE_NAME --allow-shrink # to decrease
224 Listado de imágenes de dispositivos de bloques SES 7
20.1.6 Eliminación de una imagen de dispositivo de bloques
Para eliminar un dispositivo de bloques que se corresponde con una imagen llamada "myimage"en un repositorio denominado "mypool", ejecute lo siguiente:
cephuser@adm > rbd rm mypool/myimage
20.2 Montaje y desmontaje
Después de crear un dispositivo de bloques RADOS, puede usarlo como cualquier otro dispositivode disco: formatearlo, montarlo para que permita el intercambio de archivos y desmontarlocuando haya terminado.
El comando rbd accede por defecto al clúster mediante la cuenta de usuario admin de Ceph.Esta cuenta tiene acceso administrativo completo al clúster. Esto aumenta el riesgo de causardaños accidentalmente, como ocurre cuando se entra en una estación de trabajo Linux comousuario root . Por lo tanto, es preferible crear cuentas de usuario con menos privilegios y utilizarestas cuentas para el acceso normal de lectura/escritura a dispositivos de bloques RADOS.
20.2.1 Creación de una cuenta de usuario de Ceph
Para crear una nueva cuenta de usuario con las capacidades de Ceph Manager, Ceph Monitor yCeph OSD, utilice el comando ceph con el subcomando auth get-or-create :
cephuser@adm > ceph auth get-or-create client.ID mon 'profile rbd' osd 'profile profile name \ [pool=pool-name] [, profile ...]' mgr 'profile rbd [pool=pool-name]'
Por ejemplo, para crear un usuario llamado qemu con acceso de lectura y escritura al repositoriovms y acceso de solo lectura al repositorio images , ejecute lo siguiente:
ceph auth get-or-create client.qemu mon 'profile rbd' osd 'profile rbd pool=vms, profile rbd-read-only pool=images' \ mgr 'profile rbd pool=images'
El resultado del comando ceph auth get-or-create será el anillo de claves del usuarioespecicado, que se puede escribir en /etc/ceph/ceph.client.ID.keyring .
225 Eliminación de una imagen de dispositivo de bloques SES 7
NotaAl utilizar el comando rbd , puede especicar el ID de usuario proporcionando elargumento opcional --id ID .
Para obtener más información sobre la gestión de cuentas de usuario de Ceph, consulte elCapítulo 30, Autenticación con cephx.
20.2.2 Autenticación de usuarios
Para especicar un nombre de usuario, utilice ‑‑id nombre de usuario . Si utiliza laautenticación de cephx , también debe especicar un secreto. Puede proceder de un anillo declaves o de un archivo que contenga el secreto:
cephuser@adm > rbd device map --pool rbd myimage --id admin --keyring /path/to/keyring
O bien
cephuser@adm > rbd device map --pool rbd myimage --id admin --keyfile /path/to/file
20.2.3 Preparación de un dispositivo de bloques RADOS para suuso
1. Asegúrese de que el clúster de Ceph incluye un repositorio con la imagen de disco quedesea asignar. Supongamos que el repositorio se denomina mypool y la imagen myimage .
cephuser@adm > rbd list mypool
2. Asigne la imagen a un nuevo dispositivo de bloques:
cephuser@adm > rbd device map --pool mypool myimage
3. Enumerar todos los dispositivos asignados:
cephuser@adm > rbd device listid pool image snap device0 mypool myimage - /dev/rbd0
El dispositivo en el que queremos trabajar es /dev/rbd0 .
226 Autenticación de usuarios SES 7
Sugerencia: vía del dispositivo RBDEn lugar de /dev/rbdNÚMERO_DISPOSITIVO , puede utilizar /dev/rbd/
NOMBRE_REPOSITORIO/NOMBRE_IMAGEN como vía persistente del dispositivo. Porejemplo:
/dev/rbd/mypool/myimage
4. Cree un sistema de archivos XFS en el dispositivo /dev/rbd0:
root # mkfs.xfs /dev/rbd0 log stripe unit (4194304 bytes) is too large (maximum is 256KiB) log stripe unit adjusted to 32KiB meta-data=/dev/rbd0 isize=256 agcount=9, agsize=261120 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 finobt=0 data = bsize=4096 blocks=2097152, imaxpct=25 = sunit=1024 swidth=1024 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=0 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=8 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0
5. Sustituyendo /mnt por el punto de montaje, monte el dispositivo y compruebe que estámontado correctamente:
root # mount /dev/rbd0 /mnt root # mount | grep rbd0 /dev/rbd0 on /mnt type xfs (rw,relatime,attr2,inode64,sunit=8192,...
Ya puede mover datos al dispositivo y desde él como si fuese un directorio local.
Sugerencia: aumento del tamaño del dispositivo RBDSi descubre que el tamaño del dispositivo RBD es insuciente, puede aumentarlocon facilidad.
1. Aumente el tamaño de la imagen RBD, por ejemplo, hasta 10 GB.
cephuser@adm > rbd resize --size 10000 mypool/myimage
227 Preparación de un dispositivo de bloques RADOS para su uso SES 7
Resizing image: 100% complete...done.
2. Aumente el sistema de archivos hasta llenar el nuevo tamaño del dispositivo:
root # xfs_growfs /mnt[...]data blocks changed from 2097152 to 2560000
6. Cuando termine de acceder al dispositivo, puede desasignarlo y desmontarlo.
cephuser@adm > rbd device unmap /dev/rbd0root # unmount /mnt
Sugerencia: montaje y desmontaje manualSe proporciona un guion rbdmap y una unidad systemd para facilitar el proceso deasignación y montaje de los RBD después del arranque, así como de desmontarlos antesdel apagado. Consulte la Sección 20.2.4, “rbdmap: asignación de dispositivos RBD durante el
arranque”.
20.2.4 rbdmap: asignación de dispositivos RBD durante elarranque
rbdmap es un guion de shell que automatiza las operaciones rbd map y rbd device unmapen una o varias imágenes RBD. Aunque es posible ejecutar el guion manualmente en cualquiermomento, la ventaja principal consiste en asignar y montar automáticamente las imágenes RBDdurante el arranque (y desmontarlas y desasignarlas al apagar el equipo), activándose medianteel sistema Init. Con este n, el paquete ceph-common incluye el archivo de unidad systemdrbdmap.service .
El guion solo acepta un argumento, que puede ser map o unmap . En ambos casos, el guionanaliza un archivo de conguración. Se utiliza /etc/ceph/rbdmap por defecto, pero se puedeanular mediante una variable de entorno RBDMAPFILE . Cada línea del archivo de conguraciónse corresponde con una imagen RBD que se debe asignar o desasignar.
El archivo de conguración tiene el formato siguiente:
image_specification rbd_options
228 rbdmap: asignación de dispositivos RBD durante el arranque SES 7
image_specification
Vía a una imagen dentro de un repositorio. Se debe especicar comonombre_repositorio / nombre_imagen .
rbd_options
Una lista opcional de parámetros que se puedan pasar al comando rbd device mapsubyacente. Estos parámetros y sus valores se deben especicar como una cadena separadapor comas, por ejemplo:
PARAM1=VAL1,PARAM2=VAL2,...
El ejemplo hace que el guion rbdmap ejecute el siguiente comando:
cephuser@adm > rbd device map POOL_NAME/IMAGE_NAME --PARAM1 VAL1 --PARAM2 VAL2
En el ejemplo siguiente puede se explica cómo especicar un nombre de usuario y un anillode claves con un secreto correspondiente:
cephuser@adm > rbdmap device map mypool/myimage id=rbd_user,keyring=/etc/ceph/ceph.client.rbd.keyring
Si se ejecuta como rbdmap map , el guion analiza el archivo de conguración y, para cada imagenRBD especicada, primero intenta asignar la imagen (mediante el comando rbd device map )y luego montarla.
Si se ejecuta como rbdmap unmap , las imágenes enumeradas en el archivo de conguración sedesmontarán y se desasignarán.
rbdmap unmap-all intenta desmontar y posteriormente desasignar todas las imágenes RBDasignadas actualmente, independientemente de que estén enumeradas o no en el archivo deconguración.
Si la operación se realiza correctamente, rbd device map asigna la imagen a un dispositivo /dev/rbdX , momento en el que se activa una regla udev para crear un enlace simbólico de nombrede dispositivo de conanza /dev/rbd/nombre_repositorio/nombre_imagen que señala aldispositivo real asignado.
Para que las operaciones de montaje y desmontaje se lleven a cabo correctamente, el nombredel dispositivo de conanza debe tener una entrada correspondiente en /etc/fstab . Alescribir entradas /etc/fstab para imágenes RBD, especique la opción de montaje "noauto" (o"nofail"). Esto impide que el sistema Init intente montar el dispositivo demasiado pronto, antesde que el dispositivo en cuestión aún exista, ya que rbdmap.service normalmente se activabastante tarde en la secuencia de arranque.
229 rbdmap: asignación de dispositivos RBD durante el arranque SES 7
Para una lista completa de opciones de rbd , consulte la página man de rbd ( man 8 rbd ).
Para consultar ejemplos de uso de rbdmap , consulte la página man de rbdmap ( man 8 rbdmap ).
20.2.5 Aumento del tamaño de dispositivos RBD
Si descubre que el tamaño del dispositivo RBD es insuciente, puede aumentarlo con facilidad.
1. Aumente el tamaño de la imagen RBD, por ejemplo, hasta 10 GB.
cephuser@adm > rbd resize --size 10000 mypool/myimage Resizing image: 100% complete...done.
2. Aumente el sistema de archivos hasta llenar el nuevo tamaño del dispositivo.
root # xfs_growfs /mnt [...] data blocks changed from 2097152 to 2560000
20.3 Instantáneas
Una instantánea RBD es una instantánea de una imagen de dispositivo de bloques RADOS.Las instantáneas permiten conservar un historial de los estados de la imagen. Ceph también escompatible con capas de instantáneas, lo que permite clonar imágenes de máquinas virtualesde forma rápida y sencilla. Ceph admite las instantáneas de dispositivos de bloques medianteel comando rbd y muchas interfaces de alto nivel, incluidas QEMU, libvirt , OpenStack yCloudStack.
NotaDetenga las operaciones de entrada y salida y vacíe todas las escrituras pendientes antesde tomar una instantánea de una imagen. Si la imagen contiene un sistema de archivos,este debe tener un estado coherente en el momento de realizar la instantánea.
230 Aumento del tamaño de dispositivos RBD SES 7
20.3.1 Habilitación y configuración de cephx
Si cephx está habilitado, debe especicar un nombre de usuario o ID y una vía al anillo de clavesque contiene la clave correspondiente para el usuario. Consulte el Capítulo 30, Autenticación con
cephx para obtener más información. También puede añadir la variable de entorno CEPH_ARGSpara evitar la reintroducción de los siguientes parámetros.
cephuser@adm > rbd --id user-ID --keyring=/path/to/secret commandscephuser@adm > rbd --name username --keyring=/path/to/secret commands
Por ejemplo:
cephuser@adm > rbd --id admin --keyring=/etc/ceph/ceph.keyring commandscephuser@adm > rbd --name client.admin --keyring=/etc/ceph/ceph.keyring commands
SugerenciaAñada el usuario y el secreto a la variable de entorno CEPH_ARGS para no tener queintroducir estos datos en cada ocasión.
20.3.2 Conceptos básicos sobre instantáneas
Los procedimientos siguientes muestran cómo crear, enumerar y eliminar instantáneas medianteel comando rbd en la línea de comandos.
20.3.2.1 Creación de instantáneas
Para crear una instantánea con rbd , especique la opción snap create , el nombre delrepositorio y el nombre de la imagen.
cephuser@adm > rbd --pool pool-name snap create --snap snap-name image-namecephuser@adm > rbd snap create pool-name/image-name@snap-name
Por ejemplo:
cephuser@adm > rbd --pool rbd snap create --snap snapshot1 image1cephuser@adm > rbd snap create rbd/image1@snapshot1
231 Habilitación y configuración de cephx SES 7
20.3.2.2 Listado de instantáneas
Para enumerar las instantáneas de una imagen, especique el nombre del repositorio y el dela imagen.
cephuser@adm > rbd --pool pool-name snap ls image-namecephuser@adm > rbd snap ls pool-name/image-name
Por ejemplo:
cephuser@adm > rbd --pool rbd snap ls image1cephuser@adm > rbd snap ls rbd/image1
20.3.2.3 Reversión de instantáneas
Para revertir una instantánea con rbd , especique la opción snap rollback , el nombre delrepositorio, el nombre de la imagen y el nombre de la instantánea.
cephuser@adm > rbd --pool pool-name snap rollback --snap snap-name image-namecephuser@adm > rbd snap rollback pool-name/image-name@snap-name
Por ejemplo:
cephuser@adm > rbd --pool pool1 snap rollback --snap snapshot1 image1cephuser@adm > rbd snap rollback pool1/image1@snapshot1
NotaRevertir una imagen a una instantánea signica sobrescribir la versión actual de la imagencon los datos de la instantánea. El tiempo necesario para ejecutar una reversión aumentasegún el tamaño de la imagen. Es más rápido clonar una instantánea que revertir unaimagen a una instantánea, por lo que es el método preferible para volver a un estadopreexistente.
20.3.2.4 Supresión de una instantánea
Para suprimir una instantánea con rbd , especique la opción snap rm , el nombre delrepositorio, el nombre de la imagen y el nombre de usuario.
cephuser@adm > rbd --pool pool-name snap rm --snap snap-name image-namecephuser@adm > rbd snap rm pool-name/image-name@snap-name
232 Conceptos básicos sobre instantáneas SES 7
Por ejemplo:
cephuser@adm > rbd --pool pool1 snap rm --snap snapshot1 image1cephuser@adm > rbd snap rm pool1/image1@snapshot1
NotaLos OSD de Ceph suprimen los datos de forma asíncrona, por lo que al suprimir unainstantánea, no se libera el espacio de disco inmediatamente.
20.3.2.5 Limpieza de instantáneas
Para suprimir todas las instantáneas de una imagen con rbd , especique la opción snap purgey el nombre de la imagen.
cephuser@adm > rbd --pool pool-name snap purge image-namecephuser@adm > rbd snap purge pool-name/image-name
Por ejemplo:
cephuser@adm > rbd --pool pool1 snap purge image1cephuser@adm > rbd snap purge pool1/image1
20.3.3 Capas de instantáneas
Ceph admite la posibilidad de crear varios clones de copia de escritura (COW, por sus siglas eninglés) de una instantánea de dispositivo de bloques. Las capas de instantáneas permiten quelos clientes de dispositivos de bloques de Ceph creen imágenes muy rápidamente. Por ejemplo,puede crear una imagen de dispositivo de bloques con una máquina virtual Linux escrita en él y,a continuación, realizar una instantánea de la imagen, protegerla y crear tantos clones de copiade escritura como desee. Las instantáneas son de solo lectura, por lo que clonar una instantáneasimplica la semántica y permite crear clones rápidamente.
NotaLos términos "parent" (padre) y "child" (hijo) mencionados en los siguientes ejemplos dela línea de comandos hacen referencia a una instantánea de un dispositivo de bloques deCeph (padre) y la imagen correspondiente clonada de la instantánea (hijo).
233 Capas de instantáneas SES 7
Cada imagen clonada (hijo) almacena una referencia a su imagen padre que permite que laimagen clonada abra la instantánea padre y la lea.
Un clon COW de una instantánea se comporta exactamente igual que cualquier otra imagen dedispositivo de bloques de Ceph. Puede leer las imágenes clonadas, escribir en ellas, clonarlas yredimensionarlas. No existen restricciones especiales que afecten a las imágenes clonadas. Noobstante, la clonación de copia de escritura de una instantánea hace referencia a la instantánea,por lo que debe proteger la instantánea antes de clonarla.
Nota: ‑‑image-format 1 no se admiteNo es posible crear instantáneas de imágenes creadas con la opción obsoleta rbd create‑‑image-format 1 . Ceph solo admite la clonación de las imágenes format 2 por defecto.
20.3.3.1 Procedimientos iniciales con las capas
La aplicación de capas a un dispositivo de bloques de Ceph es un proceso sencillo. Debe disponerde una imagen. Debe crear una instantánea de la imagen. Debe proteger la instantánea. Una vezrealizados estos pasos, puede empezar a clonar la instantánea.
La imagen clonada tendrá una referencia a la instantánea padre e incluirá el ID del repositorio,el ID de la imagen y el ID de la instantánea. La inclusión del ID del repositorio signica que sepueden clonar instantáneas de un repositorio como imágenes en un repositorio distinto.
Plantilla de imagen: un ejemplo de uso habitual para crear capas de dispositivos de bloqueses crear una imagen principal y una instantánea que sirva como plantilla para los clones.Por ejemplo, un usuario puede crear una imagen de una distribución de Linux (como SUSELinux Enterprise Server) y crear una instantánea para ella. El usuario puede actualizarperiódicamente la imagen y crear una instantánea nueva (por ejemplo, zypper ref &&zypper patch , seguido de rbd snap create ). A medida que la imagen crezca, el usuariopuede clonar cualquiera de las instantáneas.
Plantilla extendida: un ejemplo de uso más avanzado implica la posibilidad de extenderuna imagen de plantilla para que proporcione más información que una imagen base. Porejemplo, un usuario puede clonar una imagen (una plantilla de máquina virtual) e instalarotro software (por ejemplo, una base de datos, un sistema de gestión de contenido o unsistema de análisis) y, a continuación, realizar una instantánea de la imagen extendida,que a su vez se puede actualizar de la misma manera que la imagen base.
234 Capas de instantáneas SES 7
Repositorio de plantillas: una manera de utilizar capas de dispositivos de bloques es crear unrepositorio que contenga imágenes principales que actúen como plantillas e instantáneasde dichas plantillas. A continuación, puede ampliar los privilegios de solo lectura a losusuarios, de modo que tengan la posibilidad de clonar las instantáneas sin la capacidad deescribir o ejecutar dentro del repositorio.
Migración y recuperación de imágenes: una manera de utilizar capas de dispositivos debloques consiste en migrar o recuperar datos de un repositorio a otro.
20.3.3.2 Protección de una instantánea
Los clones acceden a las instantáneas padre. Todos los clones dejarán de funcionar si un usuariosuprime por error la instantánea padre. Para evitar la pérdida de datos, debe proteger lainstantánea antes de clonarla.
cephuser@adm > rbd --pool pool-name snap protect \ --image image-name --snap snapshot-namecephuser@adm > rbd snap protect pool-name/image-name@snapshot-name
Por ejemplo:
cephuser@adm > rbd --pool pool1 snap protect --image image1 --snap snapshot1cephuser@adm > rbd snap protect pool1/image1@snapshot1
NotaNo es posible suprimir una instantánea protegida.
20.3.3.3 Clonación de una instantánea
Para clonar una instantánea, debe especicar el repositorio padre, la imagen, la instantánea, elrepositorio hijo y el nombre de la imagen. Debe proteger la instantánea para poder clonarla.
cephuser@adm > rbd clone --pool pool-name --image parent-image \ --snap snap-name --dest-pool pool-name \ --dest child-imagecephuser@adm > rbd clone pool-name/parent-image@snap-name \pool-name/child-image-name
Por ejemplo:
cephuser@adm > rbd clone pool1/image1@snapshot1 pool1/image2
235 Capas de instantáneas SES 7
NotaPuede clonar una instantánea de un repositorio como una imagen de otro repositorio. Porejemplo, puede mantener imágenes e instantáneas de solo lectura como plantillas en unrepositorio y clones con acceso de escritura en otro.
20.3.3.4 Desprotección de una instantánea
Para suprimir una instantánea, primero debe desprotegerla. Además, no puede suprimirinstantáneas que tengan referencias de clones. Debe aplanar todos los clones de una instantáneapara poder eliminarla.
cephuser@adm > rbd --pool pool-name snap unprotect --image image-name \ --snap snapshot-namecephuser@adm > rbd snap unprotect pool-name/image-name@snapshot-name
Por ejemplo:
cephuser@adm > rbd --pool pool1 snap unprotect --image image1 --snap snapshot1cephuser@adm > rbd snap unprotect pool1/image1@snapshot1
20.3.3.5 Listado de los hijos de una instantánea
Para enumerar los hijos de una instantánea, ejecute lo siguiente:
cephuser@adm > rbd --pool pool-name children --image image-name --snap snap-namecephuser@adm > rbd children pool-name/image-name@snapshot-name
Por ejemplo:
cephuser@adm > rbd --pool pool1 children --image image1 --snap snapshot1cephuser@adm > rbd children pool1/image1@snapshot1
20.3.3.6 Aplanamiento de una imagen clonada
Las imágenes clonadas retienen una referencia a la instantánea padre. Si elimina la referenciadel clon a la instantánea padre, la imagen se "aplana" copiando la información de la instantáneaen el clon. El tiempo que se tarda en aplanar un clon aumenta según el tamaño de la instantánea.Para suprimir una instantánea, primero debe aplanar las imágenes hijo.
236 Capas de instantáneas SES 7
cephuser@adm > rbd --pool pool-name flatten --image image-namecephuser@adm > rbd flatten pool-name/image-name
Por ejemplo:
cephuser@adm > rbd --pool pool1 flatten --image image1cephuser@adm > rbd flatten pool1/image1
NotaDado que una imagen plana contiene toda la información de la instantánea, ocupará másespacio de almacenamiento que un clon con capas.
20.4 Duplicados de imagen RBDLas imágenes RBD se pueden duplicar de forma asincrónica entre dos clústeres de Ceph. Estacapacidad está disponible en dos modos:
Basada en registro
Este modo utiliza las imágenes RBD transaccionales para garantizar la réplica protegidacontra bloqueos de un momento concreto entre los clústeres. Cada escritura en la imagenRBD se guarda primero en el registro asociado antes de modicar la imagen real. El clústerremoto leerá el registro y reproducirá las actualizaciones en su copia local de la imagen.Dado que cada escritura en la imagen RBD dará como resultado dos escrituras en el clústerde Ceph, se espera que la latencia de escritura casi se duplique cuando se utiliza la funciónde imagen RBD transaccional.
Basada en instantáneas
Este modo utiliza instantáneas de duplicación de imágenes RBD creadas de formaprogramada periódicamente o manualmente para replicar imágenes de RBD protegidascontra bloqueos entre clústeres. El clúster remoto determinará las actualizaciones de datoso metadatos entre dos instantáneas de duplicación y copiará los deltas en su copia localde la imagen. Con la ayuda de la función de imagen fast-di de RBD, los bloques dedatos actualizados se pueden calcular rápidamente sin necesidad de explorar la imagenRBD completa. Dado que este modo no es coherente en un momento determinado, seránecesario sincronizar el delta completo de la instantánea antes de utilizarlo durante unasituación de failover. Cualquier delta de instantánea aplicado parcialmente se revertirá ala última instantánea totalmente sincronizada antes de su uso.
237 Duplicados de imagen RBD SES 7
La duplicación se congura de forma independiente para cada repositorio dentro de los clústeresconectores. Esto se puede congurar en un subconjunto especíco de imágenes dentro delrepositorio, o para que reeje automáticamente todas las imágenes de un repositorio si se usaúnicamente la duplicación transaccional. La duplicación se congura mediante el comando rbd .El daemon rbd-mirror es el responsable de la extracción de actualizaciones de imágenes delclúster conector remoto y de aplicarlos a la imagen en el clúster local .
Dependiendo de las necesidades de réplica, la duplicación del RBD se puede congurar para laréplica unidireccional o bidireccional:
Réplica unidireccional
Cuando los datos solo se duplican desde un clúster primario a un clúster secundario, eldaemon rbd-mirror se ejecuta solo en el clúster secundario.
Réplica bidireccional
Cuando los datos se duplican desde imágenes primarias de un clúster a imágenes noprimarias de otro clúster (y viceversa), el daemon rbd-mirror se ejecuta en ambosclústeres.
ImportanteCada instancia del daemon rbd-mirror debe poder conectarse a los clústeres de Cephlocales y remotos simultáneamente. Por ejemplo, todos los hosts de monitor y OSD.Además, la red debe tener suciente ancho de banda entre los dos centros de datos parapoder gestionar la carga de trabajo de duplicación.
20.4.1 Configuración del repositorio
Los siguientes procedimientos demuestran cómo llevar a cabo las tareas administrativas básicaspara congurar la duplicación mediante el comando rbd . La duplicación se congura de formaindependiente para cada repositorio dentro de los clústeres de Ceph.
Debe llevar a cabo los pasos de conguración del repositorio en ambos clústeres conectores.Para simplicar los ejemplos, en estos procedimientos se presupone que hay dos clústeres,denominados local y remote a los que se puede acceder desde un único host.
Consulte la página man de rbd ( man 8 rbd ) para obtener información adicional acerca decómo conectarse a clústeres de Ceph diferentes.
238 Configuración del repositorio SES 7
Sugerencia: varios clústeresEn los siguientes ejemplos, el nombre del clúster corresponde a un archivode conguración de Ceph con el mismo nombre /etc/ceph/remote.conf y aun archivo de anillo de claves de Ceph con el mismo nombre /etc/ceph/
remote.client.admin.keyring .
20.4.1.1 Habilitación de la duplicación en un repositorio
Para habilitar la duplicación en un repositorio, especique el subcomando mirror poolenable , el nombre del repositorio y el modo de duplicación. El modo de duplicación puede serde repositorio o de imagen:
pool
Se duplican todas las imágenes del repositorio con el registro transaccional habilitado.
image
La duplicación se debe habilitar explícitamente en cada imagen. Consulte la Sección 20.4.2.1,
“Habilitación de la duplicación de imágenes” para obtener más información.
Por ejemplo:
cephuser@adm > rbd --cluster local mirror pool enable POOL_NAME poolcephuser@adm > rbd --cluster remote mirror pool enable POOL_NAME pool
20.4.1.2 Inhabilitación de la duplicación
Para inhabilitar la duplicación en un repositorio, especique el subcomando mirror pooldisable y el nombre del repositorio. Cuando se inhabilita la duplicación en un repositorio deesta forma, la duplicación también se inhabilitará en cualquier imagen (dentro del repositorio)para la que se haya habilitado la duplicación explícitamente.
cephuser@adm > rbd --cluster local mirror pool disable POOL_NAMEcephuser@adm > rbd --cluster remote mirror pool disable POOL_NAME
239 Configuración del repositorio SES 7
20.4.1.3 Conectores de carga
Para que el daemon rbd-mirror descubra su clúster conector, el conector debe estar registradoen el repositorio y se debe crear una cuenta de usuario. Este proceso se puede automatizarcon rbd y con los comandos mirror pool peer bootstrap create y mirror pool peerbootstrap import .
Para crear manualmente un nuevo testigo de arnque con rbd , especique el comando mirrorpool peer bootstrap create , un nombre de repositorio y un nombre de sitio descriptivoopcional para describir el clúster local :
cephuser@local > rbd mirror pool peer bootstrap create \ [--site-name LOCAL_SITE_NAME] POOL_NAME
El resultado del comando mirror pool peer bootstrap create será un testigo que se debeproporcionar al comando mirror pool peer bootstrap import . Por ejemplo, en el clústerlocal :
cephuser@local > rbd --cluster local mirror pool peer bootstrap create --site-name local image-pooleyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkLW \1pcnJvci1wZWVyIiwia2V5IjoiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1v \bl9ob3N0IjoiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==
Para importar manualmente el testigo de arranque creado por otro clúster con el comando rbd ,utilice la siguiente sintaxis:
rbd mirror pool peer bootstrap import \ [--site-name LOCAL_SITE_NAME] \ [--direction DIRECTION \ POOL_NAME TOKEN_PATH
Dónde:
LOCAL_SITE_NAME
Un nombre de sitio descriptivo opcional para describir el clúster local .
DIRECTION
Una dirección de duplicación. El valor por defecto es rx-tx para la duplicaciónbidireccional, pero también se puede denir como rx-only para la duplicaciónunidireccional.
POOL_NAME
El nombre del repositorio.
240 Configuración del repositorio SES 7
TOKEN_PATH
Una vía de archivo al testigo creado (o - para leerlo desde la entrada estándar).
Por ejemplo, en el clúster remote :
cephuser@remote > cat <<EOF > tokeneyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkLW \1pcnJvci1wZWVyIiwia2V5IjoiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1v \bl9ob3N0IjoiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==EOF
cephuser@adm > rbd --cluster remote mirror pool peer bootstrap import \ --site-name remote image-pool token
20.4.1.4 Adición manual de un conector de clúster
Como alternativa al procedimiento descrito en la Sección 20.4.1.3, “Conectores de carga”, puedeespecicar conectores de forma manual. El daemon remoto rbd-mirror necesitará acceso alclúster local para realizar la duplicación. Cree un nuevo usuario local de Ceph, que utilizará eldaemon remoto rbd-mirror ; por ejemplo, rbd-mirror-peer :
cephuser@adm > ceph auth get-or-create client.rbd-mirror-peer \ mon 'profile rbd' osd 'profile rbd'
Utilice la siguiente sintaxis para añadir un clúster de Ceph conector duplicado con el comandorbd :
rbd mirror pool peer add POOL_NAME CLIENT_NAME@CLUSTER_NAME
Por ejemplo:
cephuser@adm > rbd --cluster site-a mirror pool peer add image-pool client.rbd-mirror-peer@site-bcephuser@adm > rbd --cluster site-b mirror pool peer add image-pool client.rbd-mirror-peer@site-a
Por defecto, el daemon rbd-mirror debe tener acceso al archivo de conguración de Cephubicado en /etc/ceph/.NOMBRE_CLÚSTER.conf . Proporciona las direcciones IP de los MONdel clúster conector y un anillo de claves para un cliente denominado NOMBRE_CLIENTE ubicadoen las vías de búsqueda por defecto o personalizadas del anillo de claves; por ejemplo /etc/ceph/NOMBRE_CLUSTER.NOMBRE_CLIENTE.keyring .
241 Configuración del repositorio SES 7
Como alternativa, el MON del clúster conector o la clave de cliente se pueden almacenar deforma segura en el almacén de claves de conguración de Ceph local. Para especicar losatributos de conexión del clúster conector al añadir un conector de duplicación, utilice lasopciones --remote-mon-host y --remote-key-file . Por ejemplo:
cephuser@adm > rbd --cluster site-a mirror pool peer add image-pool \ client.rbd-mirror-peer@site-b --remote-mon-host 192.168.1.1,192.168.1.2 \ --remote-key-file /PATH/TO/KEY_FILEcephuser@adm > rbd --cluster site-a mirror pool info image-pool --allMode: poolPeers: UUID NAME CLIENT MON_HOST KEY 587b08db... site-b client.rbd-mirror-peer 192.168.1.1,192.168.1.2 AQAeuZdb...
20.4.1.5 Eliminación de un clúster conector
Para eliminar un clúster conector duplicado, especique el subcomando mirror pool peerremove , el nombre del repositorio y el UUID del conector (disponible mediante el comando rbdmirror pool info ):
cephuser@adm > rbd --cluster local mirror pool peer remove POOL_NAME \ 55672766-c02b-4729-8567-f13a66893445cephuser@adm > rbd --cluster remote mirror pool peer remove POOL_NAME \ 60c0e299-b38f-4234-91f6-eed0a367be08
20.4.1.6 Repositorios de datos
Al crear imágenes en el clúster de destino, rbd-mirror selecciona un repositorio de datos dela siguiente manera:
Si el clúster de destino tiene un repositorio de datos por defecto congurado (con la opciónde conguración rbd_default_data_pool ), se utilizará.
De lo contrario, si la imagen de origen utiliza un repositorio de datos independiente y existeun repositorio con el mismo nombre en el clúster de destino, se utilizará dicho repositorio.
Si no se cumple ninguna de estas condiciones, no se denirá ningún repositorio de datos.
242 Configuración del repositorio SES 7
20.4.2 Configuración de la imagen RBD
A diferencia de la conguración del repositorio, la conguración de la imagen solo se deberealizar en un único clúster conector duplicado de Ceph.
Las imágenes RBD duplicadas se designan como primary (principal) o non-primary (no principal).Se trata de una propiedad de la imagen, no del repositorio. Las imágenes designadas como noprincipales no se pueden modicar.
Las imágenes suben de nivel a principal automáticamente cuando la duplicación se habilitapor primera vez en una imagen (ya sea implícita, si el modo de duplicación del repositorioes "pool" [repositorio] y la imagen cuenta con la función de imagen transaccional habilitada,o explícita [consulte la Sección 20.4.2.1, “Habilitación de la duplicación de imágenes”], mediante elcomando rbd ).
20.4.2.1 Habilitación de la duplicación de imágenes
Si la duplicación está congurada en el modo image , es necesario habilitar explícitamentela duplicación para cada imagen del repositorio. Para habilitar la duplicación de una imagenconcreta con rbd , especique el subcomando mirror image enable junto con el nombre delrepositorio y el de la imagen:
cephuser@adm > rbd --cluster local mirror image enable \ POOL_NAME/IMAGE_NAME
El modo de imagen duplicada puede ser journal (registro) o snapshot (instantánea):
journal (modo por defecto)
Cuando se congura en el modo journal , la duplicación utilizará la función de imagenRBD transaccional para replicar el contenido de la imagen. Si esta función aún no estáhabilitada en la imagen, se habilitará automáticamente.
snapshot
Cuando se congura en el modo de snapshot , la duplicación utilizará instantáneasde duplicación de la imagen RBD para replicar el contenido de la imagen. Una vezhabilitada, se creará automáticamente una instantánea de duplicación inicial. Se puedencrear instantáneas adicionales mediante el comando rbd .
Por ejemplo:
cephuser@adm > rbd --cluster local mirror image enable image-pool/image-1 snapshotcephuser@adm > rbd --cluster local mirror image enable image-pool/image-2 journal
243 Configuración de la imagen RBD SES 7
20.4.2.2 Habilitación de la función transaccional de imágenes
La duplicación RBD utiliza las imágenes RBD transaccionales para garantizar que la imagenreplicada siempre esté protegida contra fallos. Cuando se utiliza el modo de duplicación image ,la función transaccional se habilita automáticamente si la duplicación está habilitada en laimagen. Cuando se utiliza el modo de duplicación pool , antes de que una imagen se puedaduplicar en un clúster conector, la función de imagen RBD transaccional debe estar habilitada. Sepuede habilitar en el momento de crear la imagen proporcionando la opción ‑‑image-featureexclusive-lock,journaling al comando rbd .
Como alternativa, la función de registro transaccional se puede habilitar de forma dinámicaen las imágenes RBD preexistentes. Para habilitar el registro transaccional, especique elsubcomando feature enable , el nombre del repositorio y la imagen y el nombre de la función:
cephuser@adm > rbd --cluster local feature enable POOL_NAME/IMAGE_NAME exclusive-lockcephuser@adm > rbd --cluster local feature enable POOL_NAME/IMAGE_NAME journaling
Nota: dependencia de opcionesLa función journaling (registro transaccional) depende de la función exclusive-lock(bloqueo exclusivo). Si la función exclusive-lock no está habilitada, deberá habilitarlaantes que la función journaling .
SugerenciaPuede habilitar la función transaccional en todas las imágenes nuevas por defectoañadiendo rbd default features = layering,exclusive-lock,object-map,deep-flatten,journaling al archivo de conguración de Ceph.
20.4.2.3 Creación de instantáneas de duplicación de la imagen
Si se utiliza la duplicación basada en instantáneas, será necesario crear instantáneas deduplicación siempre que se desee duplicar el contenido modicado de la imagen RBD. Para crearuna instantánea de duplicación manualmente con rbd , especique el comando mirror imagesnapshot junto con el nombre del repositorio y la imagen:
cephuser@adm > rbd mirror image snapshot POOL_NAME/IMAGE_NAME
244 Configuración de la imagen RBD SES 7
Por ejemplo:
cephuser@adm > rbd --cluster local mirror image snapshot image-pool/image-1
Por defecto, solo se crearán tres instantáneas de duplicación por imagen. La instantánea deduplicación más reciente se elimina automáticamente si se alcanza el límite. El límite se puedeanular mediante la opción de conguración rbd_mirroring_max_mirroring_snapshots si esnecesario. Además, las instantáneas de duplicación se suprimen automáticamente cuando seelimina la imagen o cuando se inhabilita la duplicación.
Las instantáneas de duplicación también se pueden crear automáticamente de forma periódicasi se programa. La instantánea de duplicación se puede programar a nivel global, por repositorioo por imagen. Se pueden denir varias programaciones de instantáneas de duplicación encualquier nivel, pero solo se ejecutarán las programaciones más especícas que coincidan conuna imagen duplicada individual.
Para crear una programación de instantáneas de duplicación con rbd , especique el comandomirror snapshot schedule add junto con un nombre de repositorio o imagen opcional, unintervalo y una hora de inicio opcional.
El intervalo se puede especicar en días, horas o minutos mediante los sujos d , h o m ,respectivamente. La hora de inicio opcional se puede especicar mediante el formato de horaISO 8601. Por ejemplo:
cephuser@adm > rbd --cluster local mirror snapshot schedule add --pool image-pool 24h 14:00:00-05:00cephuser@adm > rbd --cluster local mirror snapshot schedule add --pool image-pool --image image1 6h
Para eliminar una programación de instantáneas de duplicación con rbd , especique elcomando mirror snapshot schedule remove con opciones que coincidan con el comandocorrespondiente para añadir una programación.
Para todas las programaciones de instantáneas para un nivel especíco (global, repositorio oimagen) con rbd , especique el comando mirror snapshot schedule ls junto con un nombrede repositorio o imagen opcional. Además, se puede especicar la opción --recursive paramostrar todas las programaciones en el nivel especicado e inferior. Por ejemplo:
cephuser@adm > rbd --cluster local mirror schedule ls --pool image-pool --recursivePOOL NAMESPACE IMAGE SCHEDULEimage-pool - - every 1d starting at 14:00:00-05:00image-pool image1 every 6h
245 Configuración de la imagen RBD SES 7
Para saber cuándo se crearán las siguientes instantáneas para las imágenes RBD de duplicaciónbasadas en instantáneas con rbd , especique el comando mirror snapshot schedule statusjunto con un nombre de repositorio o imagen opcional. Por ejemplo:
cephuser@adm > rbd --cluster local mirror schedule statusSCHEDULE TIME IMAGE2020-02-26 18:00:00 image-pool/image1
20.4.2.4 Inhabilitación de la duplicación de imágenes
Para habilitar la duplicación de una imagen concreta, especique el subcomando mirror imagedisable junto con el nombre del repositorio y el de la imagen:
cephuser@adm > rbd --cluster local mirror image disable POOL_NAME/IMAGE_NAME
20.4.2.5 Subida y bajada de nivel de imágenes
En una situación de failover en la que sea necesario mover la designación primara a la imagendel clúster conector, debe detener el acceso a la imagen principal, bajarla de nivel, subir el nivelde la nueva imagen principal y reanudar el acceso a la imagen en el clúster alternativo.
Nota: subida de nivel forzosaPuede forzar la subida de nivel mediante la opción ‑‑force . Es necesario forzar lasubida de nivel cuando la bajada de nivel no se puede propagar al clúster conector (porejemplo, en caso de fallo del clúster o interrupción de la comunicación). Esto provocaráuna situación de división entre ambos conectores y la imagen dejará de sincronizarsehasta que se emita un subcomando resync .
Para bajar de nivel una imagen y convertirla en no principal, especique el subcomando mirrorimage demote junto con el nombre del repositorio y el de la imagen:
cephuser@adm > rbd --cluster local mirror image demote POOL_NAME/IMAGE_NAME
Para bajar de nivel todas las imágenes principales de un repositorio a no principales, especiqueel subcomando mirror pool demote junto con el nombre del repositorio:
cephuser@adm > rbd --cluster local mirror pool demote POOL_NAME
246 Configuración de la imagen RBD SES 7
Para subir de nivel una imagen y convertirla en principal, especique el subcomando mirrorimage promote junto con el nombre del repositorio y el de la imagen:
cephuser@adm > rbd --cluster remote mirror image promote POOL_NAME/IMAGE_NAME
Para subir de nivel todas las imágenes de un repositorio a principales, especique el subcomandomirror pool promote junto con el nombre del repositorio:
cephuser@adm > rbd --cluster local mirror pool promote POOL_NAME
Sugerencia: división de la carga de E/SPuesto que el estado primario o no primario se establece para cada imagen, es posibleque haya dos clústeres que dividan la carga de E/S y el failover o failback por fases.
20.4.2.6 Forzado de la resincronización de la imagen
Si el daemon rbd-mirror detecta un evento dividido, no intentará duplicar la imagen afectadahasta que se corrija. Para reanudar la duplicación de una imagen, primero baje de nivel la imagenconsiderada obsoleta y, a continuación, realice una petición de resincronización de la imagenprincipal. Para pedir una resincronización de la imagen, especique el subcomando mirrorimage resync junto con el nombre del repositorio y el de la imagen:
cephuser@adm > rbd mirror image resync POOL_NAME/IMAGE_NAME
20.4.3 Comprobación del estado de la duplicación
El estado de replicación de clúster conector se almacena para cada imagen principal duplicada.Este estado se puede recuperar mediante los subcomandos mirror image status y mirrorpool status :
Para pedir el estado de la imagen duplicada, especique el subcomando mirror image statusjunto con el nombre del repositorio y el de la imagen:
cephuser@adm > rbd mirror image status POOL_NAME/IMAGE_NAME
Para pedir el estado resumido del repositorio de duplicación, especique el subcomando mirrorpool status junto con el nombre del repositorio:
cephuser@adm > rbd mirror pool status POOL_NAME
247 Comprobación del estado de la duplicación SES 7
Sugerencia:Si se añade la opción ‑‑verbose al subcomando mirror pool status , también semostrará la información de estado de todas las imágenes duplicadas del repositorio.
20.5 Ajustes de cachéLa implementación del espacio de usuario del dispositivo de bloques Ceph ( librbd ) no puedehacer uso del caché de paginación de Linux. Por lo tanto, incluye su propio almacenamientoen caché en memoria. El almacenamiento en caché de RBD tiene un comportamiento similaral almacenamiento en caché del disco duro. Cuando el sistema operativo envía una barrera ouna petición de vaciado, todos los datos "sucios" se escriben en los OSD. Esto signica que eluso del almacenamiento en caché en modo write-back es tan seguro como usar un disco durofísico de buen comportamiento con una máquina virtual que envía correctamente los vaciados.La memoria caché utiliza un algoritmo LRU (del inglés Least Recently Used, menos usadasrecientemente) y, en el modo write-back, puede combinar peticiones adyacentes para obtenerun mejor rendimiento.
Ceph admite el modo write-back de almacenamiento en caché para los RBD. Para habilitarlo,ejecute:
cephuser@adm > ceph config set client rbd_cache true
Por defecto, librbd no realiza ningún almacenamiento en caché. Las escrituras y lecturas vandirectamente al clúster de almacenamiento. Las escrituras solo se devuelven cuando los datosestán en el disco en todas las réplicas. Con el almacenamiento en caché habilitado, las escriturasse devuelven de inmediato, a menos que haya más bytes sin vaciar de los denidos en la opciónrbd cache max dirty . En tal caso, la escritura activa la escritura diferida y se bloquea hastaque se vacían sucientes bytes.
Ceph admite el modo write-through de almacenamiento en caché para los RBD. Es posible denirel tamaño de la memoria caché y establecer destinos y límites para cambiar del modo write-back al modo write-through de almacenamiento en caché. Para habilitar el modo write-through,ejecute:
cephuser@adm > ceph config set client rbd_cache_max_dirty 0
Esto signica que las escrituras solo se devuelven cuando los datos están en el disco en todaslas réplicas, pero las lecturas pueden provenir de la memoria caché. La memoria caché está enmemoria en el cliente y cada imagen RBD tiene su propia memoria caché. Puesto que la memoria
248 Ajustes de caché SES 7
caché es local para el cliente, si hay otros usuarios que acceden a la imagen, la coherencia sepierde. Ejecutar GFS u OCFS sobre el RBD no funcionará si el almacenamiento en caché estáhabilitado.
Los siguientes parámetros afectan al comportamiento de los dispositivos de bloques RADOS.Para denirlos, utilice la categoría client :
cephuser@adm > ceph config set client PARAMETER VALUE
rbd cache
Habilita el almacenamiento en caché para el dispositivo de bloques RADOS (RBD). El valorpor defecto es "true" (verdadero).
rbd cache size
El tamaño de la memoria caché del RBD en bytes. El valor por defecto es 32 MB.
rbd cache max dirty
El límite de bytes "sucios" en el que la memoria caché activa el modo write-back. El valorde rbd cache max dirty debe ser menor que el de rbd cache size . Si se dene en 0, seutiliza el almacenamiento en caché en modo write-through. El valor por defecto es 24 MB.
rbd cache target dirty
El "destino sucio" antes de que la memoria caché comience a escribir datos en elalmacenamiento de datos. No bloquea las escrituras en la memoria caché. El valor pordefecto es 16 MB.
rbd cache max dirty age
El número de segundos que los datos sucios están en la memoria caché antes de que seinicie la escritura diferida. El valor por defecto es 1.
rbd cache writethrough until flush
Comienza en modo write-through y cambia al modo write-back después de que se recibala primera petición de vaciado. Habilitar esta opción es una medida conservadora perosegura en caso de que las máquinas virtuales que se ejecutan en rbd sean demasiadoantiguas para enviar vaciados (por ejemplo, el controlador virtio de Linux antes del kernel2.6.32). El valor por defecto es "true" (verdadero).
249 Ajustes de caché SES 7
20.6 Ajuste de QoSPor norma general, la calidad de servicio (QoS) hace referencia a los métodos de priorizacióndel tráco y de reserva de recursos. Es particularmente importante para el transporte del trácocon requisitos especiales.
Importante: no es compatible con iSCSILos ajustes de QoS siguientes solo se utilizan en la implementación librbd del RBD deespacio de nombres, pero no por la implementación kRBD . Dado que iSCSI utiliza kRBD ,no utiliza los valores de QoS. Sin embargo, para iSCSI puede congurar QoS en la capade dispositivo de bloques del kernel mediante instalaciones del kernel estándar.
rbd qos iops limit
El límite deseado de operaciones de E/S por segundo. El valor por defecto es 0 (sin límite).
rbd qos bps limit
El límite deseado de bytes de E/S por segundo. El valor por defecto es 0 (sin límite).
rbd qos read iops limit
El límite deseado de operaciones de lectura por segundo. El valor por defecto es 0 (sinlímite).
rbd qos write iops limit
El límite deseado de operaciones de escritura por segundo. El valor por defecto es 0 (sinlímite).
rbd qos read bps limit
El límite deseado de bytes de lectura por segundo. El valor por defecto es 0 (sin límite).
rbd qos write bps limit
El límite deseado de bytes de escritura por segundo. El valor por defecto es 0 (sin límite).
rbd qos iops burst
El límite de ráfaga deseado de operaciones de E/S. El valor por defecto es 0 (sin límite).
rbd qos bps burst
El límite de ráfaga deseado de bytes de E/S. El valor por defecto es 0 (sin límite).
rbd qos read iops burst
250 Ajuste de QoS SES 7
El límite de ráfaga deseado de operaciones de lectura. El valor por defecto es 0 (sin límite).
rbd qos write iops burst
El límite de ráfaga deseado de operaciones de escritura. El valor por defecto es 0 (sinlímite).
rbd qos read bps burst
El límite de ráfaga deseado de bytes de lectura. El valor por defecto es 0 (sin límite).
rbd qos write bps burst
El límite de ráfaga deseado de bytes de escritura. El valor por defecto es 0 (sin límite).
rbd qos schedule tick min
La pulsación de programación mínima (en milisegundos) para QoS. El valor por defectoes 50.
20.7 Ajustes de lectura anticipada
El dispositivo de bloques RADOS admite la lectura anticipada y la captura previa para optimizarlas lecturas pequeñas y secuenciales. Normalmente, el sistema operativo invitado se encargaríade gestionar esta función en una máquina virtual, pero es posible que los cargadores dearranque no emitan lecturas ecientes. La lectura anticipada se inhabilita automáticamente siel almacenamiento en caché está inhabilitado.
Importante: no es compatible con iSCSILos ajustes de lectura anticipada siguientes solo se utilizan en la implementación librbddel RBD de espacio de nombres, pero no por la implementación kRBD . Dado que iSCSIutiliza kRBD , no utiliza los ajustes de lectura anticipada. Sin embargo, para iSCSI puedecongurar la lectura anticipada en la capa de dispositivo de bloques del kernel medianteinstalaciones del kernel estándar.
rbd readahead trigger requests
El número de peticiones de lectura secuenciales necesarias para activar la lecturaanticipada. El valor por defecto es 10.
rbd readahead max bytes
251 Ajustes de lectura anticipada SES 7
El tamaño máximo de una petición de lectura anticipada. Si se dene en 0, la lecturaanticipada estará inhabilitada. El valor por defecto es 512 kB.
rbd readahead disable after bytes
Después de que se hayan leído este número de bytes de una imagen RBD, la lecturaanticipada se inhabilita para esa imagen hasta que se cierra. Esto permite que el sistemaoperativo invitado recupere la función de lectura anticipada cuando se arranca. Si se deneen 0, la lectura anticipada sigue habilitada. El valor por defecto es 50 MB.
20.8 Funciones avanzadasEl dispositivo de bloques RADOS admite funciones avanzadas que mejoran la funcionalidadde las imágenes RBD. Puede especicar las funciones en la línea de comandos cuandose crea una imagen RBD o en el archivo de conguración de Ceph mediante la opciónrbd_default_features .
Es posible especicar los valores de la opción rbd_default_features de dos maneras:
Como una suma de los valores internos de las funciones. Cada función tiene su propio valorinterno; por ejemplo, la "layering" tiene 1 y "fast-di" tiene 16. Por lo tanto, para activarestas dos funciones por defecto, incluya lo siguiente:
rbd_default_features = 17
Como una lista separada por comas de funciones. El ejemplo anterior tendrá el siguienteaspecto:
rbd_default_features = layering,fast-diff
Nota: funciones no compatibles con iSCSILas imágenes RBD con las siguientes funciones no son compatibles con iSCSI: deep-flatten , object-map , journaling , fast-diff y striping
A continuación se muestra una lista de funciones avanzadas de RBD:
layering
La disposición en capas permite utilizar la clonación.
252 Funciones avanzadas SES 7
El valor interno es 1, el valor por defecto es "sí".
striping
La repartición striping distribuye los datos entre varios objetos y ayuda a las cargas detrabajo de lectura y escritura secuenciales mediante paralelismo. Evita los cuellos debotella en un solo nodo en dispositivos de bloques RADOS de gran volumen u ocupación.El valor interno es 2, el valor por defecto es "sí".
exclusive-lock
Si está habilitado, requiere que un cliente obtenga un bloqueo en un objeto antes de realizaruna escritura. Habilita el bloqueo exclusivo solo si un único cliente accede a una imagenal mismo tiempo. El valor interno es 4. El valor por defecto es "sí".
object-map
La compatibilidad con el mapa de objetos depende de la compatibilidad con el bloqueoexclusivo. Los dispositivos de bloque son de provisión ligera, lo que signica que soloalmacenan datos que realmente existen. La compatibilidad con el mapa de objetosayuda a realizar un seguimiento de los objetos que realmente existen (que tienen datosalmacenados en una unidad). Al habilitar la compatibilidad con el mapa de objetos, seaceleran las operaciones de E/S para clonar, importar y exportar una imagen escasamentepoblada y suprimirla.El valor interno es 8, el valor por defecto es "sí".
fast-diff
La compatibilidad con di rápida depende de la compatibilidad con el mapa de objetos ycon el bloqueo exclusivo. Añade otra propiedad al mapa de objetos, lo que hace que seamucho más rápido generar dis entre las instantáneas de una imagen y el uso de datosreal de una instantánea.El valor interno es 16, el valor por defecto es "sí".
deep-flatten
El aplanamiento profundo hace que rbd flatten (consulte la Sección 20.3.3.6,
“Aplanamiento de una imagen clonada”) funcione en todas las instantáneas de una imagen,además de en la propia imagen. Sin él, las instantáneas de una imagen seguiríandependiendo de la imagen padre y, por lo tanto, no se podría suprimir la imagen padrehasta que se eliminaran las instantáneas. El aplanamiento profundo provoca que unaimagen padre sea independiente de sus clones, incluso si tienen instantáneas.El valor interno es 32, el valor por defecto es "sí".
journaling
253 Funciones avanzadas SES 7
La compatibilidad con el registro transaccional depende de la compatibilidad con elbloqueo exclusivo. El registro transaccional guarda todas las modicaciones en una imagenen el orden en el que se producen. La duplicación del RBD (consulte la Sección 20.4,
“Duplicados de imagen RBD”) utiliza el diario para replicar una imagen coherente con ladetención por fallo en un clúster remoto.El valor interno es 64 y el valor por defecto es "no".
20.9 Asignación del RBD utilizando clientes de kernelantiguosEs posible que los clientes antiguos (por ejemplo, SLE11 SP4) no puedan asignar imágenesRBD porque un clúster distribuido con SUSE Enterprise Storage 7 aplica algunas funciones(tanto funciones de nivel de imagen RBD como funciones de nivel de RADOS) que estos clientesantiguos no admiten. Si esto sucede, los registros del OSD mostrarán mensajes similares a lossiguientes:
2019-05-17 16:11:33.739133 7fcb83a2e700 0 -- 192.168.122.221:0/1006830 >> \192.168.122.152:6789/0 pipe(0x65d4e0 sd=3 :57323 s=1 pgs=0 cs=0 l=1 c=0x65d770).connect \protocol feature mismatch, my 2fffffffffff < peer 4010ff8ffacffff missing 401000000000000
Aviso: el cambio de tipos de depósito del mapa de CRUSHprovoca un reequilibrio masivoSi tiene previsto cambiar los tipos de depósito del mapa de CRUSH entre "straw" y"straw2", hágalo de una manera planicada. Tenga previsto que el impacto en la cargadel clúster será signicativo, ya que provocará un reequilibrio masivo del clúster.
1. Inhabilite las funciones de la imagen RBD que no sean compatibles. Por ejemplo:
cephuser@adm > rbd feature disable pool1/image1 object-mapcephuser@adm > rbd feature disable pool1/image1 exclusive-lock
2. Cambie los tipos de depósito del mapa de CRUSH de "straw2" a "straw":
a. Guarde el mapa de CRUSH:
cephuser@adm > ceph osd getcrushmap -o crushmap.original
254 Asignación del RBD utilizando clientes de kernel antiguos SES 7
b. Descompile el mapa de CRUSH.
cephuser@adm > crushtool -d crushmap.original -o crushmap.txt
c. Edite el mapa de CRUSH y sustituya "straw2" por "straw".
d. Vuelva a compilar el mapa de CRUSH:
cephuser@adm > crushtool -c crushmap.txt -o crushmap.new
e. Dena el nuevo mapa de CRUSH:
cephuser@adm > ceph osd setcrushmap -i crushmap.new
20.10 Habilitación de dispositivos de bloques yKubernetes
Puede usar RBD de Ceph con Kubernetes 1.13 y versiones posteriores mediante el controladorceph-csi . Este controlador proporciona imágenes RBD de forma dinámica para respaldar losvolúmenes de Kubernetes y asigna estas imágenes RBD como dispositivos de bloques (montandoopcionalmente un sistema de archivos incluido en la imagen) en nodos de trabajo que ejecutanpods que hacen referencia a un volumen respaldado por RBD.
Para utilizar dispositivos de bloques de Ceph con Kubernetes, debe instalar y congurar ceph-csi en el entorno de Kubernetes.
Importanteceph-csi utiliza los módulos del kernel de RBD por defecto, que quizás no admitantodos los elementos ajustables de Ceph CRUSH o las funciones de imagen RBD.
1. Por defecto, los dispositivos de bloques de Ceph utilizan el repositorio de RBD. Cree unrepositorio para el almacenamiento de volúmenes de Kubernetes. Asegúrese de que elclúster de Ceph se está ejecutando y, a continuación, cree el repositorio:
cephuser@adm > ceph osd pool create kubernetes
255 Habilitación de dispositivos de bloques y Kubernetes SES 7
2. Utilice la herramienta RBD para inicializar el repositorio:
cephuser@adm > rbd pool init kubernetes
3. Cree un nuevo usuario para Kubernetes y ceph-csi . Ejecute lo siguiente y guarde la clavegenerada:
cephuser@adm > ceph auth get-or-create client.kubernetes mon 'profile rbd' osd 'profile rbd pool=kubernetes' mgr 'profile rbd pool=kubernetes'[client.kubernetes] key = AQD9o0Fd6hQRChAAt7fMaSZXduT3NWEqylNpmg==
4. ceph-csi requiere un objeto CongMap almacenado en Kubernetes para denir lasdirecciones del monitor de Ceph para el clúster de Ceph. Recopile tanto el fsid exclusivodel clúster de Ceph como las direcciones del monitor:
cephuser@adm > ceph mon dump<...>fsid b9127830-b0cc-4e34-aa47-9d1a2e9949a8<...>0: [v2:192.168.1.1:3300/0,v1:192.168.1.1:6789/0] mon.a1: [v2:192.168.1.2:3300/0,v1:192.168.1.2:6789/0] mon.b2: [v2:192.168.1.3:3300/0,v1:192.168.1.3:6789/0] mon.c
5. Genere un archivo csi-config-map.yaml similar al ejemplo siguiente, sustituyendo elFSID por clusterID y las direcciones de monitor por monitors .
kubectl@adm > cat <<EOF > csi-config-map.yaml---apiVersion: v1kind: ConfigMapdata: config.json: |- [ { "clusterID": "b9127830-b0cc-4e34-aa47-9d1a2e9949a8", "monitors": [ "192.168.1.1:6789", "192.168.1.2:6789", "192.168.1.3:6789" ] } ]metadata: name: ceph-csi-config
256 Habilitación de dispositivos de bloques y Kubernetes SES 7
EOF
6. Cuando se genere, almacene el nuevo objeto CongMap en Kubernetes:
kubectl@adm > kubectl apply -f csi-config-map.yaml
7. ceph-csi requiere las credenciales de cephx para comunicarse con el clúster de Ceph.Genere un archivo csi-rbd-secret.yaml similar al ejemplo siguiente, utilizando el IDde usuario de Kubernetes y la clave de cephx recién creados:
kubectl@adm > cat <<EOF > csi-rbd-secret.yaml---apiVersion: v1kind: Secretmetadata: name: csi-rbd-secret namespace: defaultstringData: userID: kubernetes userKey: AQD9o0Fd6hQRChAAt7fMaSZXduT3NWEqylNpmg==EOF
8. Cuando se genere, guarde el nuevo objeto de secreto en Kubernetes:
kubectl@adm > kubectl apply -f csi-rbd-secret.yaml
9. Cree los objetos ServiceAccount y RBAC ClusterRole/ClusterRoleBinding necesarios deKubernetes. No es obligatorio personalizar estos objetos para el entorno de Kubernetesy, por lo tanto, se pueden utilizar directamente desde los archivos YAML de distribuciónde ceph-csi :
kubectl@adm > kubectl apply -f https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-provisioner-rbac.yamlkubectl@adm > kubectl apply -f https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-nodeplugin-rbac.yaml
10. Cree el aprovisionador ceph-csi y los complementos de nodo:
kubectl@adm > wget https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-rbdplugin-provisioner.yamlkubectl@adm > kubectl apply -f csi-rbdplugin-provisioner.yamlkubectl@adm > wget https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-rbdplugin.yamlkubectl@adm > kubectl apply -f csi-rbdplugin.yaml
257 Habilitación de dispositivos de bloques y Kubernetes SES 7
ImportantePor defecto, los archivos YAML del aprovisionador y del complemento de nodoextraerán la versión de desarrollo del contenedor de ceph-csi . Los archivos YAMLdeben actualizarse para utilizar una versión de lanzamiento.
20.10.1 Uso de dispositivos de bloques de Ceph en Kubernetes
Kubernetes StorageClass dene una clase de almacenamiento. Se pueden crear varios objetosStorageClass para asignarlos a diferentes niveles y funciones de calidad de servicio. Por ejemplo,NVMe frente a los repositorios basados en discos duros.
Para crear un objeto StorageClass de ceph-csi que se asigne al repositorio de Kubernetescreado anteriormente, se puede usar el siguiente archivo YAML, después de asegurarse de quela propiedad clusterID coincide con el FSID del clúster de Ceph:
kubectl@adm > cat <<EOF > csi-rbd-sc.yaml---apiVersion: storage.k8s.io/v1kind: StorageClassmetadata: name: csi-rbd-scprovisioner: rbd.csi.ceph.comparameters: clusterID: b9127830-b0cc-4e34-aa47-9d1a2e9949a8 pool: kubernetes csi.storage.k8s.io/provisioner-secret-name: csi-rbd-secret csi.storage.k8s.io/provisioner-secret-namespace: default csi.storage.k8s.io/node-stage-secret-name: csi-rbd-secret csi.storage.k8s.io/node-stage-secret-namespace: defaultreclaimPolicy: DeletemountOptions: - discardEOFkubectl@adm > kubectl apply -f csi-rbd-sc.yaml
Una PersistentVolumeClaim es una petición de recursos de almacenamiento abstractospor parte de un usuario. La PersistentVolumeClaim se asociará a un recurso de pod paraaprovisionar un PersistentVolume , que estaría respaldado por una imagen de bloque deCeph. Se puede incluir un volumeMode opcional para seleccionar entre un sistema de archivosmontado (por defecto) o un volumen basado en dispositivos de bloques en bruto.
258 Uso de dispositivos de bloques de Ceph en Kubernetes SES 7
Con ceph-csi , especicando Filesystem para volumeMode puede admitir peticiones tantoReadWriteOnce como ReadOnlyMany accessMode ; y especicando Block para volumeModepuede admitir peticiones ReadWriteOnce , ReadWriteMany y ReadOnlyMany accessMode .
Por ejemplo, para crear una petición PersistentVolumeClaim basada en bloques que utilice laceph-csi-based StorageClass creada anteriormente, se puede utilizar el siguiente archivoYAML para pedir almacenamiento de bloques en bruto desde csi-rbd-sc StorageClass :
kubectl@adm > cat <<EOF > raw-block-pvc.yaml---apiVersion: v1kind: PersistentVolumeClaimmetadata: name: raw-block-pvcspec: accessModes: - ReadWriteOnce volumeMode: Block resources: requests: storage: 1Gi storageClassName: csi-rbd-scEOFkubectl@adm > kubectl apply -f raw-block-pvc.yaml
A continuación, se muestra un ejemplo de asociación de la PersistentVolumeClaim anteriora un recurso de pod como dispositivo de bloques en bruto:
kubectl@adm > cat <<EOF > raw-block-pod.yaml---apiVersion: v1kind: Podmetadata: name: pod-with-raw-block-volumespec: containers: - name: fc-container image: fedora:26 command: ["/bin/sh", "-c"] args: ["tail -f /dev/null"] volumeDevices: - name: data devicePath: /dev/xvda volumes: - name: data persistentVolumeClaim:
259 Uso de dispositivos de bloques de Ceph en Kubernetes SES 7
claimName: raw-block-pvcEOFkubectl@adm > kubectl apply -f raw-block-pod.yaml
Para crear una PersistentVolumeClaim basad en un sistema de archivos que utilice la clasec ceph-csi-based StorageClass creada anteriormente, se puede utilizar el siguiente archivoYAML para pedir un sistema de archivos montado (respaldado por una imagen RBD) desde laclase csi-rbd-sc StorageClass :
kubectl@adm > cat <<EOF > pvc.yaml---apiVersion: v1kind: PersistentVolumeClaimmetadata: name: rbd-pvcspec: accessModes: - ReadWriteOnce volumeMode: Filesystem resources: requests: storage: 1Gi storageClassName: csi-rbd-scEOFkubectl@adm > kubectl apply -f pvc.yaml
A continuación, se muestra un ejemplo de asociación de la PersistentVolumeClaim anteriora un recurso de pod como sistema de archivos montado:
kubectl@adm > cat <<EOF > pod.yaml---apiVersion: v1kind: Podmetadata: name: csi-rbd-demo-podspec: containers: - name: web-server image: nginx volumeMounts: - name: mypvc mountPath: /var/lib/www/html volumes: - name: mypvc persistentVolumeClaim: claimName: rbd-pvc
260 Uso de dispositivos de bloques de Ceph en Kubernetes SES 7
readOnly: falseEOFkubectl@adm > kubectl apply -f pod.yaml
261 Uso de dispositivos de bloques de Ceph en Kubernetes SES 7
IV Acceso a los datos del clúster
21 Ceph Object Gateway 263
22 Ceph iSCSI Gateway 318
23 Sistema de archivos en clúster 336
24 Exportación de datos de Ceph a través de Samba 347
25 NFS Ganesha 366
21 Ceph Object Gateway
En este capítulo se presentan las tareas de administración relacionadas con Object Gateway,como la comprobación del estado del servicio, la gestión de cuentas, las pasarelas de variossitios o la autenticación LDAP.
21.1 Restricciones y limitaciones de denominación deObject GatewayA continuación encontrará una lista de limitaciones importantes de Object Gateway.
21.1.1 Limitaciones de los depósitos
Cuando se accede a Object Gateway a través de la API de S3, los nombres de depósito debenser nombres compatibles con DNS y solo se permite el carácter de guión "-". Cuando se accede aObject Gateway a través de la API de Swift, puede utilizar cualquier combinación de caracteresUTF-8 compatibles, excepto el carácter de barra "/". La longitud máxima de los nombres dedepósito es de 255 caracteres. Los nombres de depósitos deben ser exclusivos.
Sugerencia: uso de nombres de depósitos compatibles con DNSAunque puede utilizar cualquier nombre de depósito basado en UTF-8 en la API de Swift,se recomienda respetar la limitación existente para los nombre en S3, a n de evitarproblemas al acceder al mismo depósito a través de la API de S3.
21.1.2 Limitaciones de los objetos almacenados
Número máximo de objetos por usuario
No hay restricciones por defecto (limitado a ~2^63).
Número máximo de objetos por depósito
No hay restricciones por defecto (limitado a ~2^63).
Tamaño máximo de un objeto para cargar o almacenar
263 Restricciones y limitaciones de denominación de Object Gateway SES 7
Las cargas sencillas están restringidas a 5 GB. Divida varias partes para objetos másgrandes. El número máximo de porciones de varias partes es 10 000.
21.1.3 Limitaciones de los encabezados HTTP
El encabezado HTTP y la limitación de la petición dependen de la interfaz Web que se utilice.La instancia por defecto de Beast restringe el tamaño del encabezado HTTP a 16 kB.
21.2 Distribución de Object Gateway
La distribución de Ceph Object Gateway sigue el mismo procedimiento que la distribución deotros servicios de Ceph, mediante cephadm. Para obtener más información, consulte el Libro
“Guía de distribución”, Capítulo 5 “Distribución con cephadm”, Sección 5.4.2 “Especificación del servicio y
la colocación”, especícamente el Libro “Guía de distribución”, Capítulo 5 “Distribución con cephadm”,
Sección 5.4.3.4 “Distribución de pasarelas Object Gateways”.
21.3 Funcionamiento del servicio de Object Gateway
Puede utilizar las pasarelas Object Gateway de la misma forma que otros servicios de Ceph:identicando primero el nombre del servicio con el comando ceph orch ps y ejecutando elcomando siguiente para los servicios operativos, por ejemplo:
ceph orch daemon restart OGW_SERVICE_NAME
Consulte el Capítulo 14, Funcionamiento de los servicios de Ceph para obtener información completasobre el funcionamiento de los servicios de Ceph.
21.4 Opciones de configuración
Consulte en la Sección 28.5, “Ceph Object Gateway” una lista de opciones de conguración de ObjectGateway.
264 Limitaciones de los encabezados HTTP SES 7
21.5 Gestión del acceso a Object GatewayEs posible comunicarse con Object Gateway mediante una interfaz compatible con S3 o conSwift. La interfaz de S3 es compatible con un gran subconjunto de la API RESTful de AmazonS3. La interfaz de Swift es compatible con un gran subconjunto de la API de OpenStack Swift.
Ambas interfaces requieren que cree un usuario especíco y que instale el software clienterelevante para comunicarse con la pasarela mediante la clave de secreto del usuario.
21.5.1 Acceso a Object Gateway
21.5.1.1 Acceso a la interfaz de S3
Para acceder a la interfaz de S3, necesita un cliente de REST. S3cmd es un cliente de S3de línea de comandos. Lo encontrará en OpenSUSE Build Service (https://build.opensuse.org/
package/show/Cloud:Tools/s3cmd) . El repositorio contiene versiones tanto para SUSE LinuxEnterprise como para distribuciones basadas en openSUSE.
Si desea probar el acceso a la interfaz de S3, también puede escribir un pequeño guion dePython. El guion se conectará con Object Gateway, creará un depósito nuevo y mostrará todoslos depósitos. Los valores de aws_access_key_id y aws_secret_access_key se toman delos valores de access_key y secret_key devueltos por el comando radosgw_admin de laSección 21.5.2.1, “Adición de usuarios de S3 y Swift”.
1. Instale el paquete python-boto :
root # zypper in python-boto
2. Cree un nuevo guion de Python denominado s3test.py con el siguiente contenido:
import botoimport boto.s3.connectionaccess_key = '11BS02LGFB6AL6H1ADMW'secret_key = 'vzCEkuryfn060dfee4fgQPqFrncKEIkh3ZcdOANY'conn = boto.connect_s3(aws_access_key_id = access_key,aws_secret_access_key = secret_key,host = 'HOSTNAME',is_secure=False,calling_format = boto.s3.connection.OrdinaryCallingFormat(),)
265 Gestión del acceso a Object Gateway SES 7
bucket = conn.create_bucket('my-new-bucket')for bucket in conn.get_all_buckets(): print "NAME\tCREATED".format( name = bucket.name, created = bucket.creation_date, )
Sustituya HOSTNAME por el nombre del host donde haya congurado el servicio de ObjectGateway; por ejemplo gateway_host .
3. Ejecute el guion:
python s3test.py
El guion da como resultado algo parecido a lo siguiente:
my-new-bucket 2015-07-22T15:37:42.000Z
21.5.1.2 Acceso a la interfaz de Swift
Para acceder a Object Gateway a través de una interfaz de Swift, necesita el cliente de líneade comandos swift . La página man 1 swift incluye más información sobre las opciones dela línea de comandos.
El paquete se incluye en el módulo "Nube pública" de SUSE Linux Enterprise 12 de la versión SP3y en SUSE Linux Enterprise 15. Antes de instalar el paquete, debe activar el módulo y actualizarel repositorio de software:
root # SUSEConnect -p sle-module-public-cloud/12/SYSTEM-ARCHsudo zypper refresh
O bien
root # SUSEConnect -p sle-module-public-cloud/15/SYSTEM-ARCHroot # zypper refresh
Para instalar el comando swift , ejecute lo siguiente:
root # zypper in python-swiftclient
El acceso swift utiliza la sintaxis siguiente:
tux > swift -A http://IP_ADDRESS/auth/1.0 \
266 Acceso a Object Gateway SES 7
-U example_user:swift -K 'SWIFT_SECRET_KEY' list
Sustituya IP_ADDRESS por la dirección IP del servidor de pasarela, y SWIFT_SECRET_KEY porel valor de la clave de secreto de Swift que se obtiene al ejecutar el comando radosgw-adminkey create para el usuario de swift en la Sección 21.5.2.1, “Adición de usuarios de S3 y Swift”.
Por ejemplo:
tux > swift -A http://gateway.example.com/auth/1.0 -U example_user:swift \-K 'r5wWIxjOCeEO7DixD1FjTLmNYIViaC6JVhi3013h' list
El resultado es:
my-new-bucket
21.5.2 Gestión de cuentas de S3 y Swift
21.5.2.1 Adición de usuarios de S3 y Swift
Debe crear un usuario, una clave de acceso y un secreto para permitir que los usuarios nalespuedan interactuar con la pasarela. Existen dos tipos de usuarios: usuario y subusuario. Losusuarios se utilizan cuando se interactúa con la interfaz de S3, mientras que los subusuarios sonusuarios de la interfaz de Swift. Cada subusuario está asociado a un usuario.
Para crear un usuario de Swift, siga estos pasos:
1. Para crear un usuario de Swift, que es un subusuario en nuestra terminología, debe crearprimero el usuario asociado.
cephuser@adm > radosgw-admin user create --uid=USERNAME \ --display-name="DISPLAY-NAME" --email=EMAIL
Por ejemplo:
cephuser@adm > radosgw-admin user create \ --uid=example_user \ --display-name="Example User" \ [email protected]
2. Para crear un subusuario (interfaz de Swift) para el usuario, debe especicar el ID deusuario (‑‑uid= USERNAME ), el ID de subusuario y el nivel de acceso para el subusuario.
267 Gestión de cuentas de S3 y Swift SES 7
cephuser@adm > radosgw-admin subuser create --uid=UID \ --subuser=UID \ --access=[ read | write | readwrite | full ]
Por ejemplo:
cephuser@adm > radosgw-admin subuser create --uid=example_user \ --subuser=example_user:swift --access=full
3. Genere una clave de secreto para el usuario.
cephuser@adm > radosgw-admin key create \ --gen-secret \ --subuser=example_user:swift \ --key-type=swift
4. Ambos comandos darán como resultado datos con formato JSON que muestran el estadodel usuario. Fíjese en las siguientes líneas y recuerde el valor de secret_key :
"swift_keys": [ { "user": "example_user:swift", "secret_key": "r5wWIxjOCeEO7DixD1FjTLmNYIViaC6JVhi3013h"}],
Cuando acceda a Object Gateway a través de la interfaz de S3, deberá crear un usuario de S3ejecutando:
cephuser@adm > radosgw-admin user create --uid=USERNAME \ --display-name="DISPLAY-NAME" --email=EMAIL
Por ejemplo:
cephuser@adm > radosgw-admin user create \ --uid=example_user \ --display-name="Example User" \ [email protected]
El comando también crea la clave de acceso y la clave de secreto del usuario. Compruebe elresultado de las palabras clave access_key y secret_key y sus valores correspondientes:
[...] "keys": [ { "user": "example_user", "access_key": "11BS02LGFB6AL6H1ADMW", "secret_key": "vzCEkuryfn060dfee4fgQPqFrncKEIkh3ZcdOANY"}],
268 Gestión de cuentas de S3 y Swift SES 7
[...]
21.5.2.2 Eliminación de usuarios de S3 y Swift
El procedimiento para suprimir usuarios es similar para los usuarios de S3 y de Swift. Pero en elcaso de los usuarios de Swift, puede ser necesario suprimir el usuario incluyendo sus subusuarios.
Para eliminar un usuario de S3 o Swift (incluidos todos sus subusuarios), especique user rmy el ID de usuario en el siguiente comando:
cephuser@adm > radosgw-admin user rm --uid=example_user
Para eliminar un subusuario, especique subuser rm y el ID de subusuario.
cephuser@adm > radosgw-admin subuser rm --uid=example_user:swift
Puede usar las siguientes opciones:
--purge-data
Limpia todos los datos asociados al ID de usuario.
--purge-keys
Limpia todas las claves asociadas al ID de usuario.
Sugerencia: eliminación de un subusuarioCuando se elimina un subusuario, se elimina el acceso a la interfaz de Swift. El usuariopermanecerá en el sistema.
21.5.2.3 Cambio del acceso de usuario y las claves de secreto de S3 y Swift
Los parámetros access_key y secret_key identican al usuario de Object Gateway cuandose accede a la pasarela. Cambiar las claves de usuario existentes es igual a crear otras nuevas,ya que las claves antiguas se sobrescriben.
Para los usuarios de S3, ejecute lo siguiente:
cephuser@adm > radosgw-admin key create --uid=EXAMPLE_USER --key-type=s3 --gen-access-key --gen-secret
269 Gestión de cuentas de S3 y Swift SES 7
Para los usuarios de Swift, ejecute lo siguiente:
cephuser@adm > radosgw-admin key create --subuser=EXAMPLE_USER:swift --key-type=swift --gen-secret
‑‑key-type=TYPE
Especica el tipo de clave. Puede ser swift o s3 .
--gen-access-key
Genera una clave de acceso aleatoria (por defecto, para el usuario de S3).
--gen-secret
Genera una clave de secreto aleatoria.
‑‑secret=KEY
Especica una clave de secreto; por ejemplo, una generada manualmente.
21.5.2.4 Habilitación de la gestión de cuotas de usuario
Ceph Object Gateway permite denir cuotas en usuarios y depósitos que pertenezcan a losusuarios. Las cuotas incluyen el número máximo de objetos de un depósito y el tamaño dealmacenamiento máximo en megabytes.
Antes de habilitar una cuota de usuario, debe denir los parámetros correspondientes:
cephuser@adm > radosgw-admin quota set --quota-scope=user --uid=EXAMPLE_USER \ --max-objects=1024 --max-size=1024
--max-objects
Especica el número máximo de objetos. Un valor negativo inhabilita la comprobación.
--max-size
Especica el número máximo de bytes. Un valor negativo inhabilita la comprobación.
--quota-scope
Dene el ámbito para la cuota. Las opciones son depósito y usuario . Las cuotas dedepósito se aplican a los depósitos que posee un usuario. Las cuotas de usuario se aplicana un usuario.
Una vez denida una cuota de usuario, se puede habilitar:
cephuser@adm > radosgw-admin quota enable --quota-scope=user --uid=EXAMPLE_USER
270 Gestión de cuentas de S3 y Swift SES 7
Para inhabilitar una cuota:
cephuser@adm > radosgw-admin quota disable --quota-scope=user --uid=EXAMPLE_USER
Para mostrar la conguración de la cuota:
cephuser@adm > radosgw-admin user info --uid=EXAMPLE_USER
Para actualizar las estadísticas de la cuota:
cephuser@adm > radosgw-admin user stats --uid=EXAMPLE_USER --sync-stats
21.6 Procesadores frontales HTTPCeph Object Gateway admite dos front-ends HTTP incrustados: Beast y Civetweb.
El front-end Beast utiliza la biblioteca Boost.Beast para el análisis HTTP y la biblioteca Boost.Asiopara la E/S de red asincrónica.
El front-end Civetweb utiliza la biblioteca HTTP Civetweb, que es una derivación de Mongoose.
Puede congurarlos con la opción rgw_frontends . Consulte la Sección 28.5, “Ceph Object
Gateway” para obtener una lista de las opciones de conguración.
21.7 Habilitación de HTTPS/SSL para pasarelas ObjectGatewayPara permitir que Object Gateway se pueda comunicar de forma segura mediante SSL, debetener un certicado emitido por una CA o crear uno autormado.
21.7.1 Creación de certificados autofirmados
SugerenciaOmita esta sección si ya dispone de un certicado válido rmado por una CA.
El siguiente procedimiento describe cómo generar un certicado SSL autormado en el masterde Salt.
271 Procesadores frontales HTTP SES 7
1. Si necesita que identidades de sujeto adicionales conozcan Object Gateway, añádalas a laopción subjectAltName en la sección [v3_req] del archivo /etc/ssl/openssl.cnf :
[...][ v3_req ]subjectAltName = DNS:server1.example.com DNS:server2.example.com[...]
Sugerencia: direcciones IP en subjectAltNamePara utilizar direcciones IP en lugar de nombres de dominio en la opciónsubjectAltName , sustituya la línea de ejemplo por lo siguiente:
subjectAltName = IP:10.0.0.10 IP:10.0.0.11
2. Cree la clave y el certicado con openssl . Introduzca todos los datos que necesite incluiren el certicado. Es recomendable introducir el nombre completo como nombre común.Antes de rmar el certicado, verique que en las extensiones pedidas se incluye "X509v3Subject Alternative Name:" y que el certicado resultante tiene denido "X509v3 SubjectAlternative Name:".
root@master # openssl req -x509 -nodes -days 1095 \ -newkey rsa:4096 -keyout rgw.key -out rgw.pem
3. Añada la clave al nal del archivo de certicado:
root@master # cat rgw.key >> rgw.pem
21.7.2 Configuración de Object Gateway con SSL
Para congurar Object Gateway para que utilice certicados SSL, utilice la opciónrgw_frontends . Por ejemplo:
cephuser@adm > ceph config set WHO rgw_frontends \ beast ssl_port=443 ssl_certificate=config://CERT ssl_key=config://KEY
Si no especica las claves de conguración CERT y KEY , el servicio de Object Gateway buscaráel certicado SSL y la clave en las siguientes claves de conguración:
rgw/cert/RGW_REALM/RGW_ZONE.key
272 Configuración de Object Gateway con SSL SES 7
rgw/cert/RGW_REALM/RGW_ZONE.crt
Si desea anular la clave SSL por defecto y la ubicación del certicado, impórtelos a la base dedatos de conguración mediante el comando siguiente:
ceph config-key set CUSTOM_CONFIG_KEY -i PATH_TO_CERT_FILE
A continuación, utilice las claves de conguración personalizadas mediante la directivaconfig:// .
21.8 Módulos de sincronizaciónObject Gateway se distribuye como un servicio multisitio y puede duplicar datos y metadatosentre las zonas. Los módulos de sincronización se crean sobre la infraestructura de varios sitiosy permiten el envío de datos y metadatos a un nivel externo diferente. Con un módulo desincronización es posible realizar un conjunto de acciones siempre que se produzca un cambio enlos datos (por ejemplo, las operaciones de metadatos como la creación de depósitos o usuarios).Como los cambios en varios sitios de Object Gateway al nal acaban siendo consistentes en lossitios remotos, estos cambios se propagan de forma asíncrona. Esto cubre situaciones de usocomo realizar una copia de seguridad del almacenamiento de objetos en un clúster de nubeexterna o una solución de copia de seguridad personalizada mediante unidades de cinta; otambién indexar metadatos en ElasticSearch,
21.8.1 Configuración de módulos de sincronización
Todos los módulos de sincronización se conguran de forma similar. Debe crear una zonanueva (consulte la Sección 21.13, “Pasarelas Object Gateway de varios sitios” para obtener másdetalles) y dena su opción ‑‑tier_type , por ejemplo ‑‑tier-type-cloud para el módulode sincronización en la nube:
cephuser@adm > radosgw-admin zone create --rgw-zonegroup=ZONE-GROUP-NAME \ --rgw-zone=ZONE-NAME \ --endpoints=http://endpoint1.example.com,http://endpoint2.example.com, [...] \ --tier-type=cloud
Puede congurar el nivel especíco mediante el siguiente comando:
cephuser@adm > radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \ --rgw-zone=ZONE-NAME \
273 Módulos de sincronización SES 7
--tier-config=KEY1=VALUE1,KEY2=VALUE2
El elemento KEY de la conguración especica la variable de conguración que desea actualizary VALUE especica su nuevo valor. Es posible acceder a los valores anidados usando un punto.Por ejemplo:
cephuser@adm > radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \ --rgw-zone=ZONE-NAME \ --tier-config=connection.access_key=KEY,connection.secret=SECRET
Puede acceder a las entradas de matriz añadiendo corchetes "[]" detrás de la entrada a la quese hace referencia. Es posible añadir una entrada de matriz nueva utilizando corchetes "[]". Elvalor de índice de -1 hace referencia a la última entrada de la matriz. No es posible crear unaentrada nueva y volver a hacer referencia a ella en el mismo comando. Por ejemplo, se muestraun comando para crear un perl nuevo para depósitos que empiecen con PREFIX :
cephuser@adm > radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \ --rgw-zone=ZONE-NAME \ --tier-config=profiles[].source_bucket=PREFIX'*'cephuser@adm > radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \ --rgw-zone=ZONE-NAME \ --tier-config=profiles[-1].connection_id=CONNECTION_ID,profiles[-1].acls_id=ACLS_ID
Sugerencia: adición y eliminación de entradas de configuraciónPuede añadir una nueva entrada de conguración de nivel con el parámetro ‑‑tier-config-add=KEY=VALUE .
Para quitar una entrada existente, use ‑‑tier-config-rm=KEY .
21.8.2 Sincronización de zonas
La conguración del módulo de sincronización es local en una zona. El módulo de sincronizacióndetermina si la zona exporta los datos o si solo puede utilizar los datos que se ha modicado enotra zona. A partir de la versión Luminous, los complementos de sincronización compatibles sonElasticSearch , rgw (el complemento por defecto que sincroniza los datos entre las zonas) ylog , un complemento de sincronización trivial que registra la operación de metadatos que seproduce en las zonas remotas. Las secciones siguientes muestran como ejemplo una zona conel módulo de sincronización ElasticSearch . El proceso será similar para congurar cualquierotro complemento de sincronización.
274 Sincronización de zonas SES 7
Nota: complemento de sincronización por defectoEl complemento de sincronización por defecto es rgw y no es necesario congurarlo deforma explícita.
21.8.2.1 Requisitos y supuestos
Supongamos que tenemos una conguración sencilla de varios sitios, descrita en la Sección 21.13,
“Pasarelas Object Gateway de varios sitios”, formada por 2 zonas: us-east y us-west . Se añadeuna tercera zona us-east-es , que es una zona que solo procesa metadatos de los otros sitios.Esta zona puede estar en el mismo clúster de Ceph o en uno distinto a us-east . Esta zona soloconsumirá metadatos de otras zonas y la pasarela Object Gateway de esta zona no atenderádirectamente a ninguna petición del usuario nal.
21.8.2.2 Configuración de zonas
1. Cree una tercera zona similar a la que se describe en la Sección 21.13, “Pasarelas Object
Gateway de varios sitios”, por ejemplo:
cephuser@adm > radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east-es \--access-key=SYSTEM-KEY --secret=SECRET --endpoints=http://rgw-es:80
2. Puede congurar un módulo de sincronización para esta zona así:
cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --tier-type=TIER-TYPE \--tier-config={set of key=value pairs}
3. Por ejemplo, en el módulo de sincronización ElasticSearch :
cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --tier-type=elasticsearch \--tier-config=endpoint=http://localhost:9200,num_shards=10,num_replicas=1
Para las distintas opciones de conguración de niveles admitidas, consulte la Sección 21.8.3,
“Módulo de sincronización ElasticSearch”.
4. Por último, actualice el período:
cephuser@adm > radosgw-admin period update --commit
275 Sincronización de zonas SES 7
5. Inicie ahora Object Gateway en la zona:
cephuser@adm > ceph orch start rgw.REALM-NAME.ZONE-NAME
21.8.3 Módulo de sincronización ElasticSearch
Este módulo de sincronización escribe los metadatos de otras zonas en ElasticSearch. A partirde la versión Luminous, este es el código JSON de campos de datos que se almacenan enElasticSearch.
{ "_index" : "rgw-gold-ee5863d6", "_type" : "object", "_id" : "34137443-8592-48d9-8ca7-160255d52ade.34137.1:object1:null", "_score" : 1.0, "_source" : { "bucket" : "testbucket123", "name" : "object1", "instance" : "null", "versioned_epoch" : 0, "owner" : { "id" : "user1", "display_name" : "user1" }, "permissions" : [ "user1" ], "meta" : { "size" : 712354, "mtime" : "2017-05-04T12:54:16.462Z", "etag" : "7ac66c0f148de9519b8bd264312c4d64" } }}
21.8.3.1 Parámetros de configuración de tipo de nivel de ElasticSearch
endpoint
Especica el puesto nal del servidor de ElasticSearch al que se accede.
num_shards
276 Módulo de sincronización ElasticSearch SES 7
(número entero) El número de particiones con las que se congurará ElasticSearch alinicializar la sincronización de datos. Tenga en cuenta que este valor no se puede cambiardespués de la inicialización. Cualquier cambio que se haga aquí requiere que se vuelva acrear el índice de ElasticSearch y se reinicialice el proceso de sincronización de datos.
num_replicas
(número entero) El número de réplicas con las que se congurará ElasticSearch al inicializarla sincronización de datos.
explicit_custom_meta
(true | false) Especica si se indexarán todos los metadatos personalizados del usuario, osi el usuario deberá congurar (en el nivel de depósitos) las entradas de metadatos delcliente que se deben indexar. La opción por defecto es "false" (falso).
index_buckets_list
(lista de cadenas separadas por comas) Si está vacío, todos los depósitos se indexarán. De locontrario, solo se indexarán los depósitos que se especiquen aquí. Es posible proporcionarprejos de depósito (por ejemplo, "foo*") o sujos de depósito (por ejemplo, "*bar").
approved_owners_list
(lista de cadenas separadas por comas) Si está vacío, se indexarán los depósitos de todos lospropietarios (esto está sujeto a otras restricciones). En caso contrario, se indexarán sololos depósitos de los propietarios especicados. También es posible proporcionar prejosy sujos.
override_index_path
(cadena) Si no está vacío, esta cadena se utilizará como la vía de índice de ElasticSearch.De lo contrario, la vía de índice se determinará y se generará durante la inicialización dela sincronización.
username
Indica un nombre de usuario para ElasticSearch si se requiere autenticación.
password
Indica una contraseña para ElasticSearch si se requiere autenticación.
277 Módulo de sincronización ElasticSearch SES 7
21.8.3.2 Consultas de metadatos
Dado que el clúster de ElasticSearch almacena ahora metadatos de objeto, es importanteque el puesto nal de ElasticSearch no esté expuesto al público y solo puedan acceder losadministradores de clúster. Exponer las consultas de metadatos a los usuarios nales planteaun problema, ya que queremos que los usuarios solo puedan consultar sus propios metadatos yno los de otros usuarios. Esto último requeriría que el clúster de ElasticSearch autenticara a losusuarios de forma similar a como lo hace RGW, lo que supone un problema.
A partir de la versión Luminous, la instancia de RGW de la zona principal de metadatos puedeatender a las peticiones del usuario nal. De este modo, no se expone el puesto nal deElasticSearch al público y también se resuelve el problema de la autenticación y la autorización,ya que RGW realiza estas labores para las peticiones del usuario nal. Por este motivo, RGWpresenta una nueva consulta en las API de depósito que pueden atender las peticiones deElasticSearch. Todas estas peticiones deben enviarse a la zona principal de metadatos.
Cómo obtener una consulta de ElasticSearch
GET /BUCKET?query=QUERY-EXPR
Parámetros de la petición:
max-keys: el número máximo de entradas que se deben devolver.
marker: el marcador de paginación.
expression := [(]<arg> <op> <value> [)][<and|or> ...]
El operador "op" es uno de los siguientes: <, <=, ==, >=, >Por ejemplo:
GET /?query=name==foo
devolverá todas las claves indexadas para las que el usuario tiene permiso de lectura y quetienen como nombre "foo". El resultado será una lista de claves en formato XML similar ala respuesta de lista de depósitos de S3.
Cómo configurar campos de metadatos personalizados
Dena las entradas de metadatos personalizados que se deben indexar (en el depósitoespecicado) y cuáles son los tipos de estas claves. Si se ha congurado el indexadoexplícito de metadatos personalizados, esto es obligatorio para que rgw indexe los valoresde los metadatos personalizados especicados. También es necesario en casos en los quelas claves de metadatos indexadas sean de un tipo distinto a cadena.
278 Módulo de sincronización ElasticSearch SES 7
POST /BUCKET?mdsearchx-amz-meta-search: <key [; type]> [, ...]
Si hay varios campos de metadatos, deben separarse con comas. Es posible aplicar un tipopara un campo con punto y coma ";". Los tipos permitidos actualmente son string (valor pordefecto), integer y date. Por ejemplo, si desea indexar un metadato de objeto personalizadox-amz-meta-year como int, x-amz-meta-date como fecha de tipo y x-amz-meta-title comocadena, debería hacer lo siguiente:
POST /mybooks?mdsearchx-amz-meta-search: x-amz-meta-year;int, x-amz-meta-release-date;date, x-amz-meta-title;string
Cómo suprimir una configuración personalizada de metadatos
Puede suprimir una conguración personalizada de metadatos.
DELETE /BUCKET?mdsearch
Cómo obtener una configuración personalizada de metadatos
Puede recuperar una conguración personalizada de metadatos.
GET /BUCKET?mdsearch
21.8.4 Módulo de sincronización en la nube
En esta sección se presenta un módulo que sincroniza los datos de zona con un servicio remotoen la nube. La sincronización es unidireccional: la fecha no se sincroniza de nuevo desde lazona remota. El objetivo principal de este módulo es habilitar la sincronización de datos convarios proveedores de servicios en la nube. Actualmente es compatible con proveedores de nubecompatibles con AWS (S3).
Para sincronizar los datos con un servicio remoto en la nube, debe congurar las credenciales deusuario. Dado que muchos servicios en la nube incluyen límites en el número de depósitos quepuede crear cada usuario, es posible congurar la asignación de objetos y depósitos de origen,diferentes destinos para a distintos depósitos y prejos de depósito. Tenga en cuenta que laslistas de acceso de origen (ACL) no se conservarán. Es posible asignar permisos de usuarios deorigen especícos a usuarios de destino concretos.
Debido a las limitaciones de la API, no hay manera de conservar la hora de modicación delobjeto original ni la etiqueta de entidad HTTP (ETag). El módulo de sincronización en la nubelos almacena como atributos de metadatos en los objetos de destino.
279 Módulo de sincronización en la nube SES 7
21.8.4.1 Configuración del módulo de sincronización en la nube
A continuación se muestran ejemplos de una conguración trivial y no trivial para el módulode sincronización en la nube. Tenga en cuenta que la conguración trivial puede presentarconictos con la no trivial.
EJEMPLO 21.1: CONFIGURACIÓN TRIVIAL
{ "connection": { "access_key": ACCESS, "secret": SECRET, "endpoint": ENDPOINT, "host_style": path | virtual, }, "acls": [ { "type": id | email | uri, "source_id": SOURCE_ID, "dest_id": DEST_ID } ... ], "target_path": TARGET_PATH,}
EJEMPLO 21.2: CONFIGURACIÓN NO TRIVIAL
{ "default": { "connection": { "access_key": ACCESS, "secret": SECRET, "endpoint": ENDPOINT, "host_style" path | virtual, }, "acls": [ { "type": id | email | uri, # optional, default is id "source_id": ID, "dest_id": ID } ... ] "target_path": PATH # optional }, "connections": [ { "connection_id": ID, "access_key": ACCESS, "secret": SECRET, "endpoint": ENDPOINT, "host_style": path | virtual, # optional
280 Módulo de sincronización en la nube SES 7
} ... ], "acl_profiles": [ { "acls_id": ID, # acl mappings "acls": [ { "type": id | email | uri, "source_id": ID, "dest_id": ID } ... ] } ], "profiles": [ { "source_bucket": SOURCE, "connection_id": CONNECTION_ID, "acls_id": MAPPINGS_ID, "target_path": DEST, # optional } ... ],}
A continuación se explican los términos de conguración utilizados:
connection
Representa una conexión con el servicio remoto en la nube. Contiene "connection_id","access_key", "secret", "endpoint" y "host_style".
access_key
La clave de acceso remoto a la nube que se usará para la conexión especíca.
secret
La clave secreta para el servicio remoto en la nube.
endpoint
Dirección URL del puesto nal del servicio remoto en la nube.
host_style
El tipo de estilo del host ("path" o "virtual") que se usará al acceder de forma remota alpuesto nal en la nube. El valor por defecto es "path".
acls
La matriz de asignaciones de la lista de acceso.
acl_mapping
281 Módulo de sincronización en la nube SES 7
Cada estructura "acl_mapping" contiene "type", "source_id" y "dest_id". Estos elementosdenen la mutación de la ACL para cada objeto. Una mutación de la ACL permite convertirel ID de usuario de origen en un ID de destino.
type
El tipo de ACL: "id" dene el ID de usuario, "email" dene al usuario por correo electrónicoy "uri" dene al usuario por uri (grupo).
source_id
El ID de usuario en la zona de origen.
dest_id
El ID de usuario en el destino.
target_path
Cadena que dene cómo se crea la vía de destino. La vía de destino especica un prejo alque se anexa el nombre del objeto de origen. La vía de destino congurable puede incluircualquiera de las variables siguientes:
SID
Una cadena exclusiva que representa el ID de instancia de sincronización.
ZONEGROUP
El nombre del grupo de zonas.
ZONEGROUP_ID
El ID de grupo de zonas.
ZONE
Nombre de zona.
ZONE_ID
El ID de zona.
BUCKET
El nombre del depósito de origen.
OWNER
El ID de propietario del depósito de origen.Por ejemplo: target_path = rgwx- ZONA - SID / PROPIETARIO / DEPÓSITO
acl_profiles
282 Módulo de sincronización en la nube SES 7
Una matriz de perles de lista de acceso.
acl_profile
Cada perl contiene "acls_id", que representa el perl y una matriz "acls" que contiene unalista "acl_mappings".
profiles
Una lista de perles. Cada perl contiene lo siguiente:
source_bucket
Un nombre de depósito o un prejo de depósito (si termina con *) que dene losdepósitos de origen para este perl.
target_path
Consulte arriba la explicación.
connection_id
El ID de la conexión que se utilizará para este perl.
acls_id
El ID del perl de ACL que se utilizará para este perl.
21.8.4.2 Elementos configurables específicos de S3
El módulo de sincronización en la nube solo funciona con back-ends compatibles con AWS S3.Hay algunos elementos congurables que se pueden utilizar para ajustar su comportamiento alacceder a los servicios en la nube de S3:
{ "multipart_sync_threshold": OBJECT_SIZE, "multipart_min_part_size": PART_SIZE}
multipart_sync_threshold
Los objetos cuyo tamaño sea igual o mayor que este valor se sincronizarán con el servicioen la nube mediante la carga de varias partes.
multipart_min_part_size
El tamaño mínimo de las partes que se debe utilizar al sincronizar objetos mediante lacarga de varias partes.
283 Módulo de sincronización en la nube SES 7
21.8.5 Módulo de sincronización de archivador
El módulo archive sync module usa la característica de control de versiones de objetos S3 enObject Gateway. Puede congurar una zona de archivador que capture las diferentes versiones delos objetos S3 a medida que se producen en otras zonas. El historial de versiones que conservala zona de archivador solo se puede eliminar a través de pasarelas asociadas con la zona dearchivador.
Con esta arquitectura, es posible que varias zonas sin versiones pueden duplicar sus datos ymetadatos a través de sus pasarelas de zona, lo que proporciona alta disponibilidad a los usuariosnales, mientras que la zona de archivador captura todas las actualizaciones de datos paraconsolidarlos como versiones de objetos S3.
Al incluir la zona de archivador en una conguración multizona, se consigue la exibilidad deun historial de objetos dS3 en una zona, al tiempo que se ahorra el espacio que las réplicas delos objetos S3 versionados consumirían en las zonas restantes.
21.8.5.1 Configuración del módulo de sincronización de archivador
Sugerencia: más informaciónConsulte la Sección 21.13, “Pasarelas Object Gateway de varios sitios” para obtener másinformación sobre la conguración de pasarelas de varios sitios.
Consulte la Sección 21.8, “Módulos de sincronización” para obtener información detalladasobre cómo congurar los módulos de sincronización.
Para utilizar el módulo de sincronización de archivador, debe crear una zona nueva cuyo tipode nivel esté denido como archive :
cephuser@adm > radosgw-admin zone create --rgw-zonegroup=ZONE_GROUP_NAME \ --rgw-zone=OGW_ZONE_NAME \ --endpoints=http://OGW_ENDPOINT1_URL[,http://OGW_ENDPOINT2_URL,...] --tier-type=archive
21.9 Autenticación LDAPAparte de la autenticación de usuario local por defecto, Object Gateway también puede utilizarservicios del servidor LDAP para autenticar a los usuarios.
284 Módulo de sincronización de archivador SES 7
21.9.1 Mecanismo de autenticación
Object Gateway extrae las credenciales LDAP del usuario de un testigo. Se construye un ltrode búsqueda a partir del nombre de usuario. Object Gateway utiliza la cuenta del serviciocongurado para buscar una entrada que coincida en el directorio. Si se encuentra una entrada,Object Gateway intenta vincularse al nombre completo encontrado con la contraseña del testigo.Si las credenciales son válidas, la vinculación se realizará correctamente y Object Gatewayotorgará acceso.
Puede limitar los usuarios permitidos estableciendo como base para la búsqueda una unidadorganizativa especíca o especicando un ltro de búsqueda personalizado; por ejemplo, unltro que requiera la pertenencia a un grupo especíco, clases de objetos personalizados oatributos.
21.9.2 Requisitos
LDAP o Active Directory: una instancia de LDAP en ejecución a la que Object Gatewaypueda acceder.
Cuenta de servicio: credenciales LDAP que utilizará Object Gateway con los permisos debúsqueda.
Cuenta de usuario: al menos una cuenta de usuario en el directorio LDAP.
Importante: LDAP y los usuarios locales no se deben solaparNo debe utilizar los mismos nombres de usuario para los usuarios locales y los usuariosque se van a autenticar mediante LDAP. Object Gateway no puede distinguirlos y los tratacomo el mismo usuario.
Sugerencia: comprobaciones de estadoEmplee la utilidad ldapsearch para vericar la cuenta de servicio o la conexión LDAP.Por ejemplo:
tux > ldapsearch -x -D "uid=ceph,ou=system,dc=example,dc=com" -W \-H ldaps://example.com -b "ou=users,dc=example,dc=com" 'uid=*' dn
285 Mecanismo de autenticación SES 7
Asegúrese de utilizar los mismos parámetros LDAP del archivo de conguración de Cephpara eliminar posibles problemas.
21.9.3 Configuración de Object Gateway para utilizar laautenticación LDAP
Los siguientes parámetros están relacionados con la autenticación LDAP:
rgw_ldap_uri
Especica el servidor LDAP que se debe usar. Asegúrese de usar el parámetro ldaps://nombre_completo:puerto para evitar la transmisión de credenciales de forma abierta enformato de texto sin cifrar.
rgw_ldap_binddn
El nombre completo (DN) de la cuenta de servicio que utiliza Object Gateway.
rgw_ldap_secret
La contraseña de la cuenta de servicio.
rgw_ldap_searchdn
Especica la base en el árbol de información del directorio para buscar usuarios. Puedetratarse de la unidad organizativa de los usuarios o alguna unidad organizativa (OU) másespecíca.
rgw_ldap_dnattr
El atributo que se utiliza en el ltro de búsqueda construido para que coincida conun nombre de usuario. Dependiendo de su árbol de información de directorio (DIT),probablemente será uid o cn .
rgw_search_filter
Si no se especica, Object Gateway crea automáticamente el ltro de búsqueda con elvalor rgw_ldap_dnattr . Este parámetro se puede usar para restringir la lista de usuariospermitidos de formas muy exibles. Consulte la Sección 21.9.4, “Uso de un filtro de búsqueda
personalizado para limitar el acceso de usuario” para obtener más información.
286 Configuración de Object Gateway para utilizar la autenticación LDAP SES 7
21.9.4 Uso de un filtro de búsqueda personalizado para limitar elacceso de usuario
Existen dos formas de utilizar el parámetro rgw_search_filter .
21.9.4.1 Filtro parcial para restringir aún más el filtro de búsquedaconstruido
Un ejemplo de un ltro parcial:
"objectclass=inetorgperson"
Object Gateway generará el ltro de búsqueda de la forma habitual con el nombre deusuario tomado del testigo y el valor de rgw_ldap_dnattr . El ltro construido se combina acontinuación con el ltro parcial del atributo rgw_search_filter . Según el nombre de usuarioy la conguración, el ltro de búsqueda nal puede ser:
"(&(uid=hari)(objectclass=inetorgperson))"
En este caso, solo se otorgará acceso al usuario "hari" si se encuentra en el directorio LDAP, tienela clase de objeto "inetorgperson" y ha especicado una contraseña válida.
21.9.4.2 Filtro completo
Un ltro completo debe contener un testigo USERNAME que se sustituirá por el nombre de usuariodurante el intento de autenticación. El parámetro rgw_ldap_dnattr ya no se usa en este caso.Por ejemplo, para limitar los usuarios válidos a un grupo especíco, utilice el ltro siguiente:
"(&(uid=USERNAME)(memberOf=cn=ceph-users,ou=groups,dc=mycompany,dc=com))"
Nota: atributo memberOfPara poder usar el atributo memberOf en las búsquedas LDAP se requiere compatibilidaden el servidor LDAP especíco implementado.
287 Uso de un filtro de búsqueda personalizado para limitar el acceso de usuario SES 7
21.9.5 Generación de un testigo de acceso para la autenticaciónLDAP
La utilidad radosgw-token genera el testigo de acceso en función del nombre de usuario y lacontraseña LDAP. Cree una cadena codicada en base 64 que es el testigo de acceso real. Utilicesu cliente de S3 favorito (consulte la Sección 21.5.1, “Acceso a Object Gateway”) y especique eltestigo como clave de acceso y utilice una clave de secreto vacía.
tux > export RGW_ACCESS_KEY_ID="USERNAME"tux > export RGW_SECRET_ACCESS_KEY="PASSWORD"cephuser@adm > radosgw-token --encode --ttype=ldap
Importante: credenciales en texto no cifradoEl testigo de acceso es una estructura JSON codicada en base 64 y contiene lascredenciales LDAP en texto sin cifrar.
Nota: Active DirectoryPara Active Directory, utilice el parámetro ‑‑type=ad .
21.10 Partición del índice de depósitoObject Gateway almacena los datos del índice de depósito en un repositorio de índice, que usapor defecto .rgw.buckets.index . Si coloca demasiados objetos (cientos de miles) en un únicodepósito y no se dene la cuota del número máximo de objetos por depósito ( rgw bucketdefault quota max objects ), el rendimiento del repositorio de índice se puede degradar.La partición del índice de depósito evita esa disminución del rendimiento y permite un númeroelevado de objetos por depósito.
21.10.1 Nueva partición del índice de depósito
Si un depósito ha crecido mucho y su conguración inicial ya no es suciente, es preciso volvera partir el repositorio de índice del depósito. Se puede usar la partición de índice de depósito enlínea automática (consulte la Sección 21.10.1.1, “Partición dinámica”, o partir el índice de depósitomanualmente sin conexión (consulte la Sección 21.10.1.2, “Partición manual”).
288 Generación de un testigo de acceso para la autenticación LDAP SES 7
21.10.1.1 Partición dinámica
Desde SUSE Enterprise Storage 5, se admite la partición de depósito en línea. Esto detecta si elnúmero de objetos por depósito alcanza un umbral determinado y aumenta automáticamenteel número de particiones utilizado por el índice de depósito. Este proceso reduce el número deentradas de cada partición de índice de depósito.
El proceso de detección se ejecuta en estos casos:
Cuando se añaden nuevos objetos al depósito.
En un proceso en segundo plano que explora periódicamente todos los depósitos. Esto esnecesario para tratar con los depósitos existentes que no se van a actualizar.
Si un depósito requiere partición, se añade a la cola reshard_log y se programa para supartición más tarde. Los hilos de partición se ejecutan en segundo plano y ejecutan la particiónprogramada de una en una.
CONFIGURACIÓN DE LA PARTICIÓN DINÁMICA
rgw_dynamic_resharding
Habilita o inhabilita la partición del índice de depósito dinámica. Los valores válidos son"true" (verdadero) o "false" (falso). Por defecto es "true" (verdadero).
rgw_reshard_num_logs
El número de particiones para el registro. Se usa el valor por defecto de 16.
rgw_reshard_bucket_lock_duration
Duración del bloqueo en el objeto de depósito durante la partición. Se usa el valor pordefecto de 120 segundos.
rgw_max_objs_per_shard
El número máximo de objetos por partición de índice de depósito. Por defecto es 100 000objetos.
rgw_reshard_thread_interval
El tiempo máximo entre las rondas de procesamiento de hilos de partición. Se usa el valorpor defecto de 600 segundos.
COMANDOS PARA ADMINISTRAR EL PROCESO DE PARTICIÓN
Añadir un depósito a la cola de partición:
289 Nueva partición del índice de depósito SES 7
cephuser@adm > radosgw-admin reshard add \ --bucket BUCKET_NAME \ --num-shards NEW_NUMBER_OF_SHARDS
Mostrar la cola de partición:
cephuser@adm > radosgw-admin reshard list
Procesar o programar una partición de depósito:
cephuser@adm > radosgw-admin reshard process
Mostrar el estado de partición del depósito:
cephuser@adm > radosgw-admin reshard status --bucket BUCKET_NAME
Cancelar las particiones de depósito pendientes:
cephuser@adm > radosgw-admin reshard cancel --bucket BUCKET_NAME
21.10.1.2 Partición manual
La partición dinámica mencionada en la Sección 21.10.1.1, “Partición dinámica” solo se admite enconguraciones sencilla de Object Gateway. Para las conguraciones de varios sitios, utilice lapartición manual que se describe en esta sección.
Para particionar manualmente el índice de depósito sin conexión, utilice el comando siguiente:
cephuser@adm > radosgw-admin bucket reshard
El comando bucket reshard realiza las acciones siguientes:
Crea un nuevo conjunto de objetos de índice de depósito para el objeto especicado.
Distribuye todas las entradas de estos objetos de índice.
Crea una nueva instancia del depósito.
Enlaza la nueva instancia del depósito con el depósito para que todas las operaciones deíndice nuevas pasen por los nuevos índices de depósito.
Imprime el ID de depósito antiguo y el nuevo en una salida estándar.
290 Nueva partición del índice de depósito SES 7
SugerenciaCuando elija un número de particiones, tenga en cuenta lo siguiente: no debe haber másde 100.000 entradas por partición. Las particiones del índice de depósito que son númerosprimos tienden a funcionar mejor para distribuir uniformemente las entradas de índice dedepósito entre las particiones. Por ejemplo, tener 503 particiones de índice de depósitoes mejor que tener 500, ya que 503 es un número primo.
PROCEDIMIENTO 21.1: PARTICIÓN DEL ÍNDICE DE DEPÓSITO
1. Asegúrese de que se han detenido todas las operaciones dirigidas al depósito.
2. Realice una copia de seguridad del índice de depósito original:
cephuser@adm > radosgw-admin bi list \ --bucket=BUCKET_NAME \ > BUCKET_NAME.list.backup
3. Vuelva a particionar el índice de depósito:
cephuser@adm > radosgw-admin bucket reshard \ --bucket=BUCKET_NAME \ --num-shards=NEW_SHARDS_NUMBER
Sugerencia: ID de depósito antiguoComo parte del resultado, este comando también imprime los ID nuevo y antiguo.
21.10.2 Partición de índice de depósito para depósitos nuevos
Existen dos opciones que afectan a la partición de índice de depósito:
Utilice la opción rgw_override_bucket_index_max_shards para las conguracionessencillas.
Utilice la opción bucket_index_max_shards para las conguraciones de varios sitios.
Si se dene el valor 0 en las opciones, se inhabilita la partición de índice de depósito. Unvalor mayor que 0 permite la partición de índice de depósito y establece el número máximode particiones.
291 Partición de índice de depósito para depósitos nuevos SES 7
La fórmula siguiente le permitirá calcular el número recomendado de particiones:
number_of_objects_expected_in_a_bucket / 100000
Tenga en cuenta que el número máximo de particiones es de 7877.
21.10.2.1 Configuraciones de varios sitios
Las conguraciones de varios sitios pueden tener un repositorio de índice diferente paragestionar el failover. Para congurar un número de particiones coherente para las zonas de ungrupo de zonas, dena la opción bucket_index_max_shards en la conguración del grupo dezonas:
1. Exporte la conguración del grupo de zonas al archivo zonegroup.json :
cephuser@adm > radosgw-admin zonegroup get > zonegroup.json
2. Edite el archivo zonegroup.json y dena la opción bucket_index_max_shards paracada zona con nombre.
3. Restablezca el grupo de zonas:
cephuser@adm > radosgw-admin zonegroup set < zonegroup.json
4. Actualice el período. Consulte la Sección 21.13.2.6, “Actualice el período”.
21.11 Integración con OpenStack Keystone
OpenStack Keystone es un servicio de identidad para el producto OpenStack. Puede integrarObject Gateway con Keystone a n de congurar una pasarela que acepte un testigo deautenticación de Keystone. Un usuario autorizado por Keystone para acceder a la pasarela severicará en Ceph Object Gateway y, si fuera necesario, se creará automáticamente. ObjectGateway pide periódicamente a Keystone una lista de los testigos revocados.
292 Integración con OpenStack Keystone SES 7
21.11.1 Configuración de OpenStack
Antes de congurar Ceph Object Gateway, debe congurar OpenStack Keystone para habilitarel servicio de Swift y dirigirlo a Ceph Object Gateway:
1. Dena el servicio de Swift.Para utilizar OpenStack a n de validar usuarios de Swift, creeprimero el servicio de Swift:
tux > openstack service create \ --name=swift \ --description="Swift Service" \ object-store
2. Dena los puestos nales.Después de crear el servicio de Swift, diríjalo a Ceph ObjectGateway. Sustituya REGION_NAME por el nombre del grupo de zonas o el nombre de laregión de la pasarela.
tux > openstack endpoint create --region REGION_NAME \ --publicurl "http://radosgw.example.com:8080/swift/v1" \ --adminurl "http://radosgw.example.com:8080/swift/v1" \ --internalurl "http://radosgw.example.com:8080/swift/v1" \ swift
3. Verique los ajustes.Después de crear el servicio de Swift y denir los puestos nales,muestre los puestos nales para vericar que todos los valores son correctos.
tux > openstack endpoint show object-store
21.11.2 Configuración de Ceph Object Gateway
21.11.2.1 Configuración de certificados SSL
Ceph Object Gateway pide periódicamente a Keystone una lista de los testigos revocados.Estas peticiones están codicadas y rmadas. Keystone también puede congurarse para queproporcione testigos autormados, que también están codicados y rmados. Debe congurarla pasarela para que pueda descodicar y vericar estos mensajes rmados. Por lo tanto, loscerticados OpenSSL que Keystone utiliza para crear las peticiones deben convertirse al formato"nss db":
root # mkdir /var/ceph/nss
293 Configuración de OpenStack SES 7
root # openssl x509 -in /etc/keystone/ssl/certs/ca.pem \ -pubkey | certutil -d /var/ceph/nss -A -n ca -t "TCu,Cu,Tuw"rootopenssl x509 -in /etc/keystone/ssl/certs/signing_cert.pem \ -pubkey | certutil -A -d /var/ceph/nss -n signing_cert -t "P,P,P"
Para permitir que Ceph Object Gateway interactúe con OpenStack Keystone, OpenStackKeystone puede utilizar un certicado SSL autormado. Instale el certicado SSL de Keystoneen el nodo donde se ejecuta Ceph Object Gateway o, de forma alternativa, dena el valor de laopción rgw keystone verify ssl como "false" (falso). Si dene rgw keystone verify sslcomo "false", la pasarela no intentará vericar el certicado.
21.11.2.2 Configuración de las opciones de Object Gateway
Puede congurar la integración de Keystone utilizando las siguientes opciones:
rgw keystone api version
Versión de la API de Keystone. Las opciones válidas son 2 o 3. Se usa el valor por defectode 2.
rgw keystone url
La URL y el número de puerto de la API RESTful administrativa en el servidor de Keystone.Sigue el patrón URL_SERVIDOR:NÚMERO_PUERTO .
rgw keystone admin token
El testigo o secreto compartido que se congura internamente en Keystone para laspeticiones administrativas.
rgw keystone accepted roles
Las funciones necesarias para atender las peticiones. Por defecto es "Member, admin".
rgw keystone accepted admin roles
La lista de funciones que permiten a un usuario obtener privilegios administrativos.
rgw keystone token cache size
El número máximo de entradas en el caché de testigo de Keystone.
rgw keystone revocation interval
El número de segundos antes de comprobar los testigos revocados. Por defecto es 15 * 60.
rgw keystone implicit tenants
Crea nuevos usuarios en sus propios inquilinos del mismo nombre. Se usa el valor pordefecto, "false" (falso).
294 Configuración de Ceph Object Gateway SES 7
rgw s3 auth use keystone
Si se establece como "true" (verdadero), Ceph Object Gateway autenticará a los usuariosmediante Keystone. Se usa el valor por defecto, "false" (falso).
nss db path
La vía a la base de datos NSS.
También es posible congurar el inquilino del servicio de Keystone, el usuario y la contraseñapara Keystone (para la versión 2.0 de la API de identidades de OpenStack), de modo similar acómo se suelen congurar los servicios de OpenStack. De este modo, puede evitar establecerel secreto compartido rgw keystone admin token en el archivo de conguración, que sedebe inhabilitar en entornos de producción. Las credenciales del inquilino de servicio debentener privilegios de administrador. Para obtener más información, consulte la documentación
oficial de OpenStack Keystone (https://docs.openstack.org/keystone/latest/#setting-up-projects-
users-and-roles) . A continuación se muestran las opciones de conguración relacionadas:
rgw keystone admin user
El nombre de usuario del administrador de Keystone.
rgw keystone admin password
La contraseña del usuario administrador de Keystone.
rgw keystone admin tenant
El inquilino del usuario administrador de Keystone versión 2.0.
Se asigna un usuario de Ceph Object Gateway a un inquilino de Keystone. Un usuario de Keystonetiene diferentes funciones asignadas, posiblemente en más de un inquilino. Cuando Ceph ObjectGateway obtiene el ticket, busca en las funciones de inquilino y usuario que se han asignado adicho ticket y acepta o rechaza la petición de acuerdo con el valor de la opción rgw keystoneaccepted roles .
Sugerencia: asignación a inquilinos de OpenStackAunque los inquilinos de Swift se asignan por defecto al usuario de Object Gateway,también pueden asignarse a inquilinos de OpenStack mediante la opción rgw keystoneimplicit tenants . Esto hará que los contenedores usen el espacio de nombres delinquilino en lugar del espacio de nombres global de S3, que es la opción por defectode Object Gateway. Se recomienda decidir de antemano el método de asignación en lafase de planicación para evitar confusiones. La razón es que si se cambia la opción más
295 Configuración de Ceph Object Gateway SES 7
tarde, solo se verán afectadas las peticiones nuevas que se asignen bajo un inquilino,mientras que los depósitos antiguos creados anteriormente seguirán en el espacio denombres global.
En la versión 3 de la API de identidades de OpenStack, deber sustituir la opción rgw keystoneadmin tenant por:
rgw keystone admin domain
El dominio de usuario administrador de Keystone.
rgw keystone admin project
El proyecto de usuario administrador de Keystone.
21.12 Colocación de repositorios y clases dealmacenamiento
21.12.1 Visualización de destinos de colocación
Los destinos de colocación controlan qué repositorios están asociados con un depósitodeterminado. El destino de colocación de un depósito se selecciona durante la creación y nose puede modicar. Es posible mostrar su valor de placement_rule ejecutando el siguientecomando:
cephuser@adm > radosgw-admin bucket stats
La conguración del grupo de zonas contiene una lista de destinos de colocación con undestino inicial denominado "default-placement". A continuación, la conguración de zona asignacada nombre de destino de la colocación del grupo de zona a su almacenamiento local. Estainformación de colocación de zona incluye el nombre "index_pool" para el índice del depósito,el nombre "data_extra_pool" para los metadatos sobre cargas de varias incompletas y un nombrede "data_pool" para cada clase de almacenamiento.
296 Colocación de repositorios y clases de almacenamiento SES 7
21.12.2 Clases de almacenamiento
Las clases de almacenamiento ayudan a personalizar la colocación de los datos de objeto. Lasreglas del ciclo de vida del depósito S3 pueden automatizar la transición de objetos entre clasesde almacenamiento.
Las clases de almacenamiento se denen en términos de destinos de colocación. Cada destino decolocación de grupo de zonas muestra sus clases de almacenamiento disponibles con una claseinicial denominada "STANDARD". La conguración de zona es responsable de proporcionar unnombre de repositorio "data_pool" para cada una de las clases de almacenamiento del grupode zonas.
21.12.3 Configuración de grupos de zonas y zonas
Utilice el comando radosgw-admin en los grupos de zona y las zonas para congurar sucolocación. Puede consultar la conguración de la colocación del grupo de zonas con el comandosiguiente:
cephuser@adm > radosgw-admin zonegroup get{ "id": "ab01123f-e0df-4f29-9d71-b44888d67cd5", "name": "default", "api_name": "default", ... "placement_targets": [ { "name": "default-placement", "tags": [], "storage_classes": [ "STANDARD" ] } ], "default_placement": "default-placement", ...}
Para consultar la conguración de colocación de la zona, ejecute:
cephuser@adm > radosgw-admin zone get{ "id": "557cdcee-3aae-4e9e-85c7-2f86f5eddb1f", "name": "default",
297 Clases de almacenamiento SES 7
"domain_root": "default.rgw.meta:root", ... "placement_pools": [ { "key": "default-placement", "val": { "index_pool": "default.rgw.buckets.index", "storage_classes": { "STANDARD": { "data_pool": "default.rgw.buckets.data" } }, "data_extra_pool": "default.rgw.buckets.non-ec", "index_type": 0 } } ], ...}
Nota: sin configuración de varios sitios anteriorSi no ha realizado ninguna conguración de varios sitios anterior, se creanautomáticamente una zona por defecto ("default") y un grupo de zonas. Los cambios en elgrupo de zonas o las zonas no tendrán efecto hasta que reinicie Ceph Object Gateway. Siha creado un reino para varios sitios, los cambios de la zona o el grupo de zonas surtiránefecto después de conrmar los cambios con el comando radosgw-admin period update‑‑commit .
21.12.3.1 Adición de un destino de colocación
Para crear un nuevo destino de colocación denominado "temporary", comience añadiéndolo algrupo de zonas:
cephuser@adm > radosgw-admin zonegroup placement add \ --rgw-zonegroup default \ --placement-id temporary
A continuación, proporcione la información de colocación de zona para ese destino:
cephuser@adm > radosgw-admin zone placement add \ --rgw-zone default \
298 Configuración de grupos de zonas y zonas SES 7
--placement-id temporary \ --data-pool default.rgw.temporary.data \ --index-pool default.rgw.temporary.index \ --data-extra-pool default.rgw.temporary.non-ec
21.12.3.2 Adición de una clase de almacenamiento
Para añadir una nueva clase de almacenamiento denominada "COLD" al destino "default-placement", empiece añadiéndola al grupo de zonas:
cephuser@adm > radosgw-admin zonegroup placement add \ --rgw-zonegroup default \ --placement-id default-placement \ --storage-class COLD
A continuación, proporcione la información de colocación de zona para esa clase dealmacenamiento:
cephuser@adm > radosgw-admin zone placement add \ --rgw-zone default \ --placement-id default-placement \ --storage-class COLD \ --data-pool default.rgw.cold.data \ --compression lz4
21.12.4 Personalización de colocación
21.12.4.1 Edición de la colocación del grupo de zonas por defecto
Por defecto, los nuevos depósitos utilizan el destino default_placement del grupo de zonas.Puede cambiar este valor del grupo de zonas con:
cephuser@adm > radosgw-admin zonegroup placement default \ --rgw-zonegroup default \ --placement-id new-placement
299 Personalización de colocación SES 7
21.12.4.2 Edición de la colocación del usuario por defecto
Un usuario de Ceph Object Gateway puede sustituir el destino de la colocación por defectodel grupo de zonas deniendo un campo default_placement no vacío en la información delusuario. De forma similar, el valor de default_storage_class puede sustituir la clase dealmacenamiento STANDARD aplicada a los objetos por defecto.
cephuser@adm > radosgw-admin user info --uid testid{ ... "default_placement": "", "default_storage_class": "", "placement_tags": [], ...}
Si el destino de colocación de un grupo de zonas contiene etiquetas, los usuarios no podráncrear depósitos con ese destino de colocación a menos que su información de usuario contengaal menos una etiqueta que coincida en su campo "placement_tags". Esto puede ser útil pararestringir el acceso a ciertos tipos de almacenamiento.
El comando radosgw-admin no puede modicar estos campos directamente; por lo tanto, debeeditar el formato JSON manualmente:
cephuser@adm > radosgw-admin metadata get user:USER-ID > user.jsontux > vi user.json # edit the file as requiredcephuser@adm > radosgw-admin metadata put user:USER-ID < user.json
21.12.4.3 Edición de la colocación del depósito por S3 por defecto
Al crear un depósito con el protocolo S3, es posible proporcionar un destino de colocación comoparte de LocationConstraint para sustituir los destinos de colocación por defecto del usuarioy del grupo de zonas.
Normalmente, LocationConstraint debe coincidir con el valor de api_name del grupo dezonas:
<LocationConstraint>default</LocationConstraint>
Puede añadir un destino de colocación personalizado a api_name detrás de un signo de dospuntos:
<LocationConstraint>default:new-placement</LocationConstraint>
300 Personalización de colocación SES 7
21.12.4.4 Edición de la colocación del depósito por Swift
Cuando se crea un depósito con el protocolo Swift, es posible proporcionar un destino decolocación en el parámetro X-Storage-Policy del encabezado HTTP:
X-Storage-Policy: NEW-PLACEMENT
21.12.5 Uso de clases de almacenamiento
Todos los destinos de colocación tienen una clase de almacenamiento STANDARD que se aplicapor defecto a los nuevos objetos. Puede sustituir este valor por defecto con su valor dedefault_storage_class .
Para crear un objeto en una clase de almacenamiento que no sea la clase por defecto, proporcioneese nombre de clase de almacenamiento en un encabezado HTTP con la petición. El protocoloS3 utiliza el encabezado X-Amz-Storage-Class , mientras que el protocolo Swift utiliza elencabezado X-Object-Storage-Class .
Puede utilizar la gestión del ciclo de vida del objeto S3 para mover datos de objetos entre clasesde almacenamiento mediante acciones de transición .
21.13 Pasarelas Object Gateway de varios sitiosCeph admite varias opciones de conguración de varios sitios para Ceph Object Gateway:
Multizona
Una conguración que consta de un grupo de zonas y varias zonas, y cada zona tiene unao más instancias de ceph-radosgw . Cada zona tiene el respaldo de su propio clúster dealmacenamiento de Ceph. Varias zonas de un grupo de zonas proporcionan recuperacióntras fallos para el grupo de zonas en caso de que una de las zonas experimente unfallo importante. Todas las zonas están activas y pueden recibir operaciones de escritura.Además de la recuperación tras fallos, varias zonas activas también pueden servir comobase para las redes de distribución de contenido.
Grupo multizona
Ceph Object Gateway admite varios grupos de zonas, cada grupo de zonas con una omás zonas. Los objetos almacenados en zonas de un grupo de zonas dentro del mismodominio que otro grupo de zonas comparten un espacio de nombres de objeto global, loque garantiza que haya ID de objeto exclusivos en los grupos de zonas y las zonas.
301 Uso de clases de almacenamiento SES 7
NotaEs importante tener en cuenta que los grupos de zonas solo sincronizan metadatosentre sí. Los datos y los metadatos se replican entre las zonas del grupo de zonas.No se comparten datos ni metadatos en un dominio.
Varios dominios
Ceph Object Gateway admite la noción de dominios; un espacio de nombres exclusivoglobal. Se admiten varios dominios que pueden abarcar uno o varios grupos de zonas.
Puede congurar cada instancia de Object Gateway para que funcione con una conguraciónde zona activa-activa, lo que permite la escritura en zonas no principales. La conguraciónde varios sitios se almacena en un contenedor denominado "dominio". El dominio almacenagrupos de zonas, zonas y un período de tiempo con varias épocas para realizar un seguimientode los cambios en la conguración. Los daemons rgw gestionan la sincronización, eliminandola necesidad de un agente de sincronización independiente. Este enfoque de la sincronizaciónpermite que Ceph Object Gateway funcione con una conguración activa-activa, en lugar decon una activa-pasiva.
21.13.1 Requisitos y supuestos
Una conguración de varios sitios requiere al menos dos clústeres de almacenamientode Ceph y al menos dos instancias de Ceph Object Gateway, una para cada clúster dealmacenamiento de Ceph. En la siguiente conguración se presupone que hay al menos dosclústeres de almacenamiento de Ceph en ubicaciones separadas geográcamente. Sin embargo,la conguración puede funcionar en el mismo sitio. Por ejemplo, se pueden llamar rgw1 y rgw2 .
Una conguración de varios sitios requiere un grupo de zonas principal y una zona principal.Una zona principal es la fuente de información con respecto a todas las operaciones de metadatosde un clúster de varios sitios. Además, cada grupo de zonas requiere una zona principal. Losgrupos de zonas pueden tener una o más zonas secundarias o no principales. En esta guía, elhost rgw1 actúa como zona principal del grupo de zonas principal y el host rgw2 actúa comozona secundaria del grupo de zonas principal.
302 Requisitos y supuestos SES 7
21.13.2 Configuración de una zona principal
Todas las pasarelas de una conguración de varios sitios recuperan su conguración de undaemon ceph-radosgw situado en un host dentro del grupo de zonas principal y la zonaprincipal. Para congurar las pasarelas en una conguración de varios sitios, seleccione unainstancia de ceph-radosgw para congurar el grupo de zonas principal y la zona principal.
21.13.2.1 Creación de un dominio
Un dominio representa un espacio de nombres único global que consta de uno o más gruposde zonas, que a su vez contienen una o más zonas. Las zonas contienen depósitos, que a su vezcontienen objetos. Un dominio permite que Ceph Object Gateway admita varios espacios denombres y su conguración en el mismo hardware. Un dominio contiene la noción de períodos.Cada período representa el estado del grupo de zonas y la conguración de la zona en el tiempo.Cada vez que realice un cambio en un grupo de zonas o en una zona, debe actualizar el períodoy asignarlo. Por defecto, Ceph Object Gateway no crea un dominio para la compatibilidadcon versiones anteriores. Como práctica recomendada, se recomienda crear dominios para losclústeres nuevos.
Cree un nuevo dominio denominado gold para la conguración de varios sitios abriendo unainterfaz de línea de comandos en un host identicado para servir en el grupo de zonas principaly la zona. A continuación, ejecute lo siguiente:
cephuser@adm > radosgw-admin realm create --rgw-realm=gold --default
Si el clúster tiene un solo dominio, especique el indicador --default . Si se especica‑‑default , radosgw-admin utiliza este dominio por defecto. Si no se especica --default ,para añadir grupos de zonas y zonas es necesario especicar el indicador --rgw-realm o elindicador --realm-id para identicar el dominio al añadir grupos de zonas y zonas.
Después de crear el dominio, radosgw-admin devuelve la conguración del dominio:
{ "id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "name": "gold", "current_period": "09559832-67a4-4101-8b3f-10dfcd6b2707", "epoch": 1}
303 Configuración de una zona principal SES 7
NotaCeph genera un ID exclusivo para el dominio, que permite renombrar el dominio si esnecesario.
21.13.2.2 Creación de un grupo de zonas principal
Un dominio debe tener al menos un grupo de zonas para servir como grupo de zonas principalpara el dominio. Cree un nuevo grupo de zonas principal para la conguración de varios sitiosabriendo una interfaz de línea de comandos en un host identicado para servir en el grupo dezonas principal y la zona. Cree un grupo de zonas principal llamado us ejecutando lo siguiente:
cephuser@adm > radosgw-admin zonegroup create --rgw-zonegroup=us \--endpoints=http://rgw1:80 --master --default
Si el dominio solo tiene un grupo de zonas, especique el indicador --default . Si se especica--default , radosgw-admin utiliza este grupo de zonas por defecto al añadir nuevas zonas. Sino se especica --default , para añadir zonas se necesitará el indicador --rgw-zonegroup oel indicador --zonegroup-id para identicar el grupo de zonas al añadir o modicar zonas.
Después de crear el grupo de zonas principal, radosgw-admin devuelve la conguración delgrupo de zonas. Por ejemplo:
{ "id": "d4018b8d-8c0d-4072-8919-608726fa369e", "name": "us", "api_name": "us", "is_master": "true", "endpoints": [ "http:\/\/rgw1:80" ], "hostnames": [], "hostnames_s3website": [], "master_zone": "", "zones": [], "placement_targets": [], "default_placement": "", "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"}
304 Configuración de una zona principal SES 7
21.13.2.3 Creación de una zona principal
ImportanteLas zonas deben crearse en un nodo de Ceph Object Gateway que se encuentre dentrode la zona.
Cree una nueva zona principal para la conguración de varios sitios abriendo una interfaz delínea de comandos en un host identicado para servir en el grupo de zonas principal y la zona.Realice lo siguiente:
cephuser@adm > radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east-1 \--endpoints=http://rgw1:80 --access-key=SYSTEM_ACCESS_KEY --secret=SYSTEM_SECRET_KEY
NotaLas opciones --access-key y --secret no se especican en el ejemplo anterior. Estosajustes se añaden a la zona cuando se crea el usuario en la siguiente sección.
Después de crear la zona principal, radosgw-admin devuelve la conguración de la zona. Porejemplo:
{ "id": "56dfabbb-2f4e-4223-925e-de3c72de3866", "name": "us-east-1", "domain_root": "us-east-1.rgw.meta:root", "control_pool": "us-east-1.rgw.control", "gc_pool": "us-east-1.rgw.log:gc", "lc_pool": "us-east-1.rgw.log:lc", "log_pool": "us-east-1.rgw.log", "intent_log_pool": "us-east-1.rgw.log:intent", "usage_log_pool": "us-east-1.rgw.log:usage", "reshard_pool": "us-east-1.rgw.log:reshard", "user_keys_pool": "us-east-1.rgw.meta:users.keys", "user_email_pool": "us-east-1.rgw.meta:users.email", "user_swift_pool": "us-east-1.rgw.meta:users.swift", "user_uid_pool": "us-east-1.rgw.meta:users.uid", "otp_pool": "us-east-1.rgw.otp", "system_key": { "access_key": "1555b35654ad1656d804", "secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r/2EI4ngqJxD7iBdBYLhwluN30JaT3Q==" },
305 Configuración de una zona principal SES 7
"placement_pools": [ { "key": "us-east-1-placement", "val": { "index_pool": "us-east-1.rgw.buckets.index", "storage_classes": { "STANDARD": { "data_pool": "us-east-1.rgw.buckets.data" } }, "data_extra_pool": "us-east-1.rgw.buckets.non-ec", "index_type": 0 } } ], "metadata_heap": "", "realm_id": "" }
21.13.2.4 Supresión de la zona y el grupo de zonas por defecto
ImportanteEn los siguientes pasos se presupone que hay una conguración de varios sitios que utilizasistemas recién instalados en los que aún no se almacenan datos. No suprima la zonapor defecto ni sus repositorios si ya la está utilizando para almacenar datos, o los datosse suprimirán y no se podrán recuperar.
La instalación por defecto de Object Gateway crea el grupo de zonas por defecto denominadodefault . Suprima la zona por defecto si existe. Asegúrese de eliminarla primero del grupo dezonas por defecto.
cephuser@adm > radosgw-admin zonegroup delete --rgw-zonegroup=default
Suprima los repositorios por defecto del clúster de almacenamiento de Ceph, si existen:
ImportanteEn el siguiente paso se presupone que hay una conguración de varios sitios que utilizasistemas recién instalados en los que no se almacenan datos. No suprima el grupo dezonas por defecto si ya lo está utilizando para almacenar datos.
306 Configuración de una zona principal SES 7
cephuser@adm > ceph osd pool rm default.rgw.control default.rgw.control --yes-i-really-really-mean-itcephuser@adm > ceph osd pool rm default.rgw.data.root default.rgw.data.root --yes-i-really-really-mean-itcephuser@adm > ceph osd pool rm default.rgw.gc default.rgw.gc --yes-i-really-really-mean-itcephuser@adm > ceph osd pool rm default.rgw.log default.rgw.log --yes-i-really-really-mean-itcephuser@adm > ceph osd pool rm default.rgw.meta default.rgw.meta --yes-i-really-really-mean-it
AvisoSi suprime el grupo de zonas por defecto, también está suprimiendo el usuario del sistema.Si las claves del usuario administrador no se propagan, la funcionalidad de gestión deObject Gateway de Ceph Dashboard fallará. Continúe en la siguiente sección para volvera crear el usuario del sistema si continúa con este paso.
21.13.2.5 Creación de usuarios del sistema
Los daemons ceph-radosgw deben autenticarse antes de extraer información del dominio yel período. En la zona principal, cree un usuario del sistema para simplicar la autenticaciónentre los daemons:
cephuser@adm > radosgw-admin user create --uid=zone.user \--display-name="Zone User" --access-key=SYSTEM_ACCESS_KEY \--secret=SYSTEM_SECRET_KEY --system
Anote la clave de acceso y la clave secreta , ya que las zonas secundarias debenautenticarse con la zona principal.
Añada el usuario del sistema a la zona principal:
cephuser@adm > radosgw-admin zone modify --rgw-zone=us-east-1 \--access-key=ACCESS-KEY --secret=SECRET
Actualice el período para que los cambios surtan efecto:
cephuser@adm > radosgw-admin period update --commit
307 Configuración de una zona principal SES 7
21.13.2.6 Actualice el período
Después de actualizar la conguración de la zona principal, actualice el período:
cephuser@adm > radosgw-admin period update --commit
Después de actualizar el período, radosgw-admin devuelve la conguración del período. Porejemplo:
{ "id": "09559832-67a4-4101-8b3f-10dfcd6b2707", "epoch": 1, "predecessor_uuid": "", "sync_status": [], "period_map": { "id": "09559832-67a4-4101-8b3f-10dfcd6b2707", "zonegroups": [], "short_zone_ids": [] }, "master_zonegroup": "", "master_zone": "", "period_config": { "bucket_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1 }, "user_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1 } }, "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "realm_name": "gold", "realm_epoch": 1}
NotaLa actualización del período cambia la época y garantiza que otras zonas reciban laconguración actualizada.
21.13.2.7 Inicio de Gateway
En el host de Object Gateway, inicie y habilite el servicio Ceph Object Gateway. Para identicarel FSID exclusivo del clúster, ejecute ceph fsid . Para identicar el nombre del daemon deObject Gateway, ejecute ceph orch ps --hostname NOMBREHOST .
cephuser@ogw > systemctl start ceph-FSID@DAEMON_NAMEcephuser@ogw > systemctl enable ceph-FSID@DAEMON_NAME
308 Configuración de una zona principal SES 7
21.13.3 Configuración de zonas secundarias
Las zonas de un grupo de zonas replican todos los datos para asegurarse de que cada zona tienelos mismos datos. Cuando cree la zona secundaria, ejecute todas las operaciones siguientes enun host identicado para servir a la zona secundaria.
NotaPara añadir una tercera zona, siga los mismos procedimientos que para añadir la zonasecundaria. Utilice un nombre de zona diferente.
ImportanteDebe realizar las operaciones de metadatos, como crear usuarios, en un host de la zonaprincipal. La zona principal y la zona secundaria pueden recibir operaciones de depósito,pero la zona secundaria redirige las operaciones de depósito a la zona principal. Si lazona principal está inactiva, las operaciones de depósito fallarán.
21.13.3.1 Extracción del dominio
Mediante la vía URL, la clave de acceso y el secreto de la zona principal del grupo de zonasprincipal, extraiga la conguración del dominio en el host. Para extraer un dominio que no seael dominio por defecto, especique el dominio mediante las opciones de conguración --rgw-realm o --realm-id .
cephuser@adm > radosgw-admin realm pull --url=url-to-master-zone-gateway --access-key=access-key --secret=secret
NotaAl importar el dominio, también se recupera la conguración del período actual del hostremoto, que se convierte también en el período actual en este host.
Si este dominio es el dominio por defecto, o el único dominio, conviértalo en el dominio pordefecto.
cephuser@adm > radosgw-admin realm default --rgw-realm=REALM-NAME
309 Configuración de zonas secundarias SES 7
21.13.3.2 Creación de una zona secundaria
Cree una zona secundaria para la conguración de varios sitios abriendo una interfaz de línea decomandos en un host identicado para servir a la zona secundaria. Especique el ID del grupode zonas, el nombre de la nueva zona y un puesto nal para la zona. No utilice el indicador‑‑master . Todas las zonas se ejecutan con una conguración activa-activa por defecto. Si lazona secundaria no debe aceptar operaciones de escritura, especique el indicador --read-only para crear una conguración activa-pasiva entre la zona principal y la zona secundaria.Además, proporcione la clave de acceso y la clave secreta del usuario del sistemagenerado almacenado en la zona principal del grupo de zonas principal. Realice lo siguiente:
cephuser@adm > radosgw-admin zone create --rgw-zonegroup=ZONE-GROUP-NAME\ --rgw-zone=ZONE-NAME --endpoints=URL \ --access-key=SYSTEM-KEY --secret=SECRET\ --endpoints=http://FQDN:80 \ [--read-only]
Por ejemplo:
cephuser@adm > radosgw-admin zone create --rgw-zonegroup=us --endpoints=http://rgw2:80 \--rgw-zone=us-east-2 --access-key=SYSTEM_ACCESS_KEY --secret=SYSTEM_SECRET_KEY{ "id": "950c1a43-6836-41a2-a161-64777e07e8b8", "name": "us-east-2", "domain_root": "us-east-2.rgw.data.root", "control_pool": "us-east-2.rgw.control", "gc_pool": "us-east-2.rgw.gc", "log_pool": "us-east-2.rgw.log", "intent_log_pool": "us-east-2.rgw.intent-log", "usage_log_pool": "us-east-2.rgw.usage", "user_keys_pool": "us-east-2.rgw.users.keys", "user_email_pool": "us-east-2.rgw.users.email", "user_swift_pool": "us-east-2.rgw.users.swift", "user_uid_pool": "us-east-2.rgw.users.uid", "system_key": { "access_key": "1555b35654ad1656d804", "secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r\/2EI4ngqJxD7iBdBYLhwluN30JaT3Q==" }, "placement_pools": [ { "key": "default-placement", "val": { "index_pool": "us-east-2.rgw.buckets.index", "data_pool": "us-east-2.rgw.buckets.data", "data_extra_pool": "us-east-2.rgw.buckets.non-ec",
310 Configuración de zonas secundarias SES 7
"index_type": 0 } } ], "metadata_heap": "us-east-2.rgw.meta", "realm_id": "815d74c2-80d6-4e63-8cfc-232037f7ff5c"}
ImportanteEn los pasos siguientes se presupone que hay una conguración de varios sitios en la quese usan sistemas recién instalados en los que aún no se almacenan datos. No suprima lazona por defecto ni sus repositorios si ya la está utilizando para almacenar datos, o losdatos se perderán y no se podrán recuperar.
Suprima la zona por defecto si es necesario:
cephuser@adm > radosgw-admin zone rm --rgw-zone=default
Suprima los repositorios por defecto del clúster de almacenamiento de Ceph si es necesario:
cephuser@adm > ceph osd pool rm default.rgw.control default.rgw.control --yes-i-really-really-mean-itcephuser@adm > ceph osd pool rm default.rgw.data.root default.rgw.data.root --yes-i-really-really-mean-itcephuser@adm > ceph osd pool rm default.rgw.gc default.rgw.gc --yes-i-really-really-mean-itcephuser@adm > ceph osd pool rm default.rgw.log default.rgw.log --yes-i-really-really-mean-itcephuser@adm > ceph osd pool rm default.rgw.users.uid default.rgw.users.uid --yes-i-really-really-mean-it
21.13.3.3 Actualización del archivo de configuración de Ceph
Actualice el archivo de conguración de Ceph en los hosts de la zona secundaria añadiendola opción de conguración rgw_zone y el nombre de la zona secundaria a la entrada de lainstancia.
Para ello, ejecute el comando siguiente:
cephuser@adm > ceph config set SERVICE_NAME rgw_zone us-west
311 Configuración de zonas secundarias SES 7
21.13.3.4 Actualización del período
Después de actualizar la conguración de la zona principal, actualice el período:
cephuser@adm > radosgw-admin period update --commit{ "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1", "epoch": 2, "predecessor_uuid": "09559832-67a4-4101-8b3f-10dfcd6b2707", "sync_status": [ "[...]" ], "period_map": { "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1", "zonegroups": [ { "id": "d4018b8d-8c0d-4072-8919-608726fa369e", "name": "us", "api_name": "us", "is_master": "true", "endpoints": [ "http:\/\/rgw1:80" ], "hostnames": [], "hostnames_s3website": [], "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0", "zones": [ { "id": "83859a9a-9901-4f00-aa6d-285c777e10f0", "name": "us-east-1", "endpoints": [ "http:\/\/rgw1:80" ], "log_meta": "true", "log_data": "false", "bucket_index_max_shards": 0, "read_only": "false" }, { "id": "950c1a43-6836-41a2-a161-64777e07e8b8", "name": "us-east-2", "endpoints": [ "http:\/\/rgw2:80" ], "log_meta": "false", "log_data": "true", "bucket_index_max_shards": 0, "read_only": "false"
312 Configuración de zonas secundarias SES 7
}
], "placement_targets": [ { "name": "default-placement", "tags": [] } ], "default_placement": "default-placement", "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7" } ], "short_zone_ids": [ { "key": "83859a9a-9901-4f00-aa6d-285c777e10f0", "val": 630926044 }, { "key": "950c1a43-6836-41a2-a161-64777e07e8b8", "val": 4276257543 }
] }, "master_zonegroup": "d4018b8d-8c0d-4072-8919-608726fa369e", "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0", "period_config": { "bucket_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1 }, "user_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1 } }, "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "realm_name": "gold", "realm_epoch": 2}
313 Configuración de zonas secundarias SES 7
NotaLa actualización del período cambia la época y garantiza que otras zonas reciban laconguración actualizada.
21.13.3.5 Inicio de Object Gateway
En el host de Object Gateway, inicie y habilite el servicio Ceph Object Gateway:
cephuser@adm > ceph orch start rgw.us-east-2
21.13.3.6 Comprobación del estado de sincronización
Cuando la zona secundaria esté activa y en ejecución, compruebe el estado de sincronización. Lasincronización copia los usuarios y depósitos creados en la zona principal en la zona secundaria.
cephuser@adm > radosgw-admin sync status
La salida proporciona el estado de las operaciones de sincronización. Por ejemplo:
realm f3239bc5-e1a8-4206-a81d-e1576480804d (gold) zonegroup c50dbb7e-d9ce-47cc-a8bb-97d9b399d388 (us) zone 4c453b70-4a16-4ce8-8185-1893b05d346e (us-west)metadata sync syncing full sync: 0/64 shards metadata is caught up with master incremental sync: 64/64 shards data sync source: 1ee9da3e-114d-4ae3-a8a4-056e8a17f532 (us-east) syncing full sync: 0/128 shards incremental sync: 128/128 shards data is caught up with source
NotaLas zonas secundarias aceptan operaciones de depósito; sin embargo, las zonassecundarias redirigen las operaciones de depósito a la zona principal y, a continuación, sesincronizan con la zona principal para recibir el resultado de las operaciones de depósito.Si la zona principal está inactiva, las operaciones de depósito que se ejecuten en la zonasecundaria fallarán, pero las operaciones de objeto deberían realizarse correctamente.
314 Configuración de zonas secundarias SES 7
21.13.4 Mantenimiento general de Object Gateway
21.13.4.1 Comprobación del estado de sincronización
La información sobre el estado de réplica de una zona se puede consultar con:
cephuser@adm > radosgw-admin sync status realm b3bc1c37-9c44-4b89-a03b-04c269bea5da (gold) zonegroup f54f9b22-b4b6-4a0e-9211-fa6ac1693f49 (us) zone adce11c9-b8ed-4a90-8bc5-3fc029ff0816 (us-west) metadata sync syncing full sync: 0/64 shards incremental sync: 64/64 shards metadata is behind on 1 shards oldest incremental change not applied: 2017-03-22 10:20:00.0.881361sdata sync source: 341c2d81-4574-4d08-ab0f-5a2a7b168028 (us-east) syncing full sync: 0/128 shards incremental sync: 128/128 shards data is caught up with source source: 3b5d1a3f-3f27-4e4a-8f34-6072d4bb1275 (us-3) syncing full sync: 0/128 shards incremental sync: 128/128 shards data is caught up with source
21.13.4.2 Cambio de la zona principal de metadatos
ImportanteTenga cuidado cuando cambie qué zona es la principal para los metadatos. Si una zonano ha terminado de sincronizar los metadatos de la zona principal actual, no puede servirlas entradas restantes cuando se asciende a principal, y esos cambios se pierden. Poreste motivo, se recomienda esperar a que el estado de sincronización radosgw-admin deuna zona se ponga al día con la sincronización de los metadatos antes de subirla a zonaprincipal. Del mismo modo, si la zona principal actual está procesando cambios en losmetadatos mientras otra zona se está subiendo a principal, es probable que se pierdandichos cambios. Para evitarlo, se recomienda cerrar todas las instancias de Object en la
315 Mantenimiento general de Object Gateway SES 7
zona principal anterior. Después de subir de nivel otra zona, su nuevo período se puederecuperar con la el comando de extracción de período radosgw-admin y se las pasarelasse pueden reiniciar.
Para subir de nivel una zona (por ejemplo, la zona us-west del grupo de zonas us ) a zonaprincipal de metadatos, ejecute los comandos siguientes en esa zona:
cephuser@ogw > radosgw-admin zone modify --rgw-zone=us-west --mastercephuser@ogw > radosgw-admin zonegroup modify --rgw-zonegroup=us --mastercephuser@ogw > radosgw-admin period update --commit
Esto genera un nuevo período y las instancias de Object Gateway de la zona us-west envíaneste período a otras zonas.
21.13.5 Realización de failover y recuperación tras fallos
Si la zona principal fallara, realice un failover a la zona secundaria para recuperarse tras losfallos.
1. Convierta la zona secundaria en la zona principal y por defecto. Por ejemplo:
cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --master --default
Por defecto, Ceph Object Gateway ejecuta una conguración activa-activa. Si el clústerse ha congurado para ejecutarse en una conguración activa-pasiva, la zona secundariaserá una zona de solo lectura. Elimine el estado --read-only para permitir que la zonareciba operaciones de escritura. Por ejemplo:
cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --master --default \ --read-only=false
2. Actualice el período para que los cambios surtan efecto:
cephuser@adm > radosgw-admin period update --commit
3. Reinicie Ceph Object Gateway:
cephuser@adm > ceph orch restart rgw
Si la zona principal anterior se recupera, revierta la operación.
316 Realización de failover y recuperación tras fallos SES 7
1. Desde la zona recuperada, extraiga la última conguración de dominio de la zona principalactual.
cephuser@adm > radosgw-admin realm pull --url=URL-TO-MASTER-ZONE-GATEWAY \ --access-key=ACCESS-KEY --secret=SECRET
2. Convierta la zona recuperada en la zona principal y por defecto:
cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --master --default
3. Actualice el período para que los cambios surtan efecto:
cephuser@adm > radosgw-admin period update --commit
4. Reinicie Ceph Object Gateway en la zona recuperada:
cephuser@adm > ceph orch restart rgw@rgw
5. Si la zona secundaria debe tener una conguración de solo lectura, actualice la zonasecundaria:
cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --read-only
6. Actualice el período para que los cambios surtan efecto:
cephuser@adm > radosgw-admin period update --commit
7. Reinicie Ceph Object Gateway en la zona secundaria:
cephuser@adm > ceph orch restart@rgw
317 Realización de failover y recuperación tras fallos SES 7
22 Ceph iSCSI Gateway
Este capítulo se centra en las tareas de administración relacionadas con iSCSI Gateway. Paraconsultar el procedimiento de distribución, consulte el Libro “Guía de distribución”, Capítulo 5
“Distribución con cephadm”, Sección 5.4.3.5 “Distribución de pasarelas iSCSI Gateway”.
22.1 Destinos gestionados con ceph-iscsiEn este capítulo se describe cómo conectar destinos gestionados ceph-iscsi desde clientes conVMware, Microsoft Windows o Linux.
22.1.1 Conexión a open-iscsi
La conexión a destinos iSCSI compatibles con ceph-iscsi mediante open-iscsi es un procesode dos pasos. En primer lugar, el iniciador debe descubrir los destinos iSCSI disponibles en elhost de la pasarela y, a continuación, debe entrar y asignar las unidades lógicas disponibles
Ambos pasos requieren que el daemon open-iscsi esté en ejecución. La forma en que inicieel daemon open-iscsi depende de su distribución Linux:
En hosts con SUSE Linux Enterprise Server (SLES) y Red Hat Enterprise Linux (RHEL),ejecute systemctl start iscsid (o service iscsid start si systemctl no estádisponible).
En hosts con Debian y Ubuntu, ejecute systemctl start open-iscsi (o service open-iscsi start ).
Si el sistema operativo del host del iniciador es SUSE Linux Enterprise Server, consulte https://
documentation.suse.com/sles/15-SP1/single-html/SLES-storage/#sec-iscsi-initiator para obtenerinformación sobre cómo conectarse a un destino iSCSI.
Para cualquier otra distribución Linux compatible con open-iscsi , descubra los destinos en lapasarela ceph-iscsi . En este ejemplo se utiliza iscsi1.example.com como dirección del portal.Para el acceso de múltiples rutas, repita los pasos con iscsi2.example.com:
root # iscsiadm -m discovery -t sendtargets -p iscsi1.example.com192.168.124.104:3260,1 iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol
318 Destinos gestionados con ceph-iscsi SES 7
A continuación, entre en el portal. Si la entrada se completa correctamente, las unidades lógicascon RBD del portal estarán disponibles de inmediato en el bus SCSI del sistema:
root # iscsiadm -m node -p iscsi1.example.com --loginLogging in to [iface: default, target: iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol, portal: 192.168.124.104,3260] (multiple)Login to [iface: default, target: iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol, portal: 192.168.124.104,3260] successful.
Repita este proceso con las demás direcciones IP o hosts del portal.
Si su sistema tiene la utilidad lsscsi instalada, se utiliza para mostrar los dispositivos SCSIdisponibles en el sistema:
lsscsi[8:0:0:0] disk SUSE RBD 4.0 /dev/sde[9:0:0:0] disk SUSE RBD 4.0 /dev/sdf
En una conguración de múltiples rutas (donde dos dispositivos iSCSI conectados representanla misma unidad lógica), también puede examinar el estado del dispositivo de múltiples víascon la utilidad multipath :
root # multipath -ll360014050cf9dcfcb2603933ac3298dca dm-9 SUSE,RBDsize=49G features='0' hwhandler='0' wp=rw|-+- policy='service-time 0' prio=1 status=active| `- 8:0:0:0 sde 8:64 active ready running`-+- policy='service-time 0' prio=1 status=enabled`- 9:0:0:0 sdf 8:80 active ready running
Ahora puede utilizar este dispositivo de múltiples rutas igual que cualquier otro dispositivode bloques. Por ejemplo, puede utilizar el dispositivo como volumen físico para la gestión devolúmenes lógicos (LVM) de Linux o, simplemente, puede crear un sistema de archivos en él.El ejemplo siguiente muestra cómo crear un sistema de archivos XFS en el volumen iSCSI demúltiples rutas recién conectado:
root # mkfs -t xfs /dev/mapper/360014050cf9dcfcb2603933ac3298dcalog stripe unit (4194304 bytes) is too large (maximum is 256KiB)log stripe unit adjusted to 32KiBmeta-data=/dev/mapper/360014050cf9dcfcb2603933ac3298dca isize=256 agcount=17, agsize=799744 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 finobt=0data = bsize=4096 blocks=12800000, imaxpct=25
319 Conexión a open-iscsi SES 7
= sunit=1024 swidth=1024 blksnaming =version 2 bsize=4096 ascii-ci=0 ftype=0log =internal log bsize=4096 blocks=6256, version=2 = sectsz=512 sunit=8 blks, lazy-count=1realtime =none extsz=4096 blocks=0, rtextents=0
Tenga en cuenta que puesto que XFS un sistema de archivos no agrupados en clúster, es posibleque solo sea capaz de montar un único nodo de iniciador iSCSI en un momento dado.
Si en cualquier momento desea dejar de utilizar las unidades lógicas iSCSI asociadas con undestino concreto, ejecute el siguiente comando:
root # iscsiadm -m node -p iscsi1.example.com --logoutLogging out of session [sid: 18, iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol, portal: 192.168.124.104,3260]Logout of [sid: 18, target: iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol, portal: 192.168.124.104,3260] successful.
Como ocurre con el descubrimiento y la entrada, debe repetir los pasos de salida para todas lasdirecciones IP y nombres de host del portal.
22.1.1.1 Configuración de múltiples rutas
La conguración de múltiples rutas se conserva en los clientes o los iniciadores y esindependiente de cualquier conguración de ceph-iscsi . Seleccione una estrategia antesde utilizar el almacenamiento de bloques. Después de editar /etc/multipath.conf , reiniciemultipathd con
root # systemctl restart multipathd
Para una conguración activa-pasiva con nombres descriptivos, añada
defaults { user_friendly_names yes}
a /etc/multipath.conf . Después de conectarse correctamente a los destinos, ejecute
root # multipath -llmpathd (36001405dbb561b2b5e439f0aed2f8e1e) dm-0 SUSE,RBDsize=2.0G features='0' hwhandler='0' wp=rw|-+- policy='service-time 0' prio=1 status=active| `- 2:0:0:3 sdl 8:176 active ready running
320 Conexión a open-iscsi SES 7
|-+- policy='service-time 0' prio=1 status=enabled| `- 3:0:0:3 sdj 8:144 active ready running`-+- policy='service-time 0' prio=1 status=enabled `- 4:0:0:3 sdk 8:160 active ready running
Tenga en cuenta el estado de cada enlace. Para una conguración activa-activa, añada
defaults { user_friendly_names yes}
devices { device { vendor "(LIO-ORG|SUSE)" product "RBD" path_grouping_policy "multibus" path_checker "tur" features "0" hardware_handler "1 alua" prio "alua" failback "immediate" rr_weight "uniform" no_path_retry 12 rr_min_io 100 }}
a /etc/multipath.conf . Reinicie multipathd y ejecute
root # multipath -llmpathd (36001405dbb561b2b5e439f0aed2f8e1e) dm-3 SUSE,RBDsize=2.0G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw`-+- policy='service-time 0' prio=50 status=active |- 4:0:0:3 sdj 8:144 active ready running |- 3:0:0:3 sdk 8:160 active ready running `- 2:0:0:3 sdl 8:176 active ready running
321 Conexión a open-iscsi SES 7
22.1.2 Conexión de Microsoft Windows (iniciador de MicrosoftiSCSI)
Para conectarse a un destino iSCSI de SUSE Enterprise Storage desde un servidor Windows 2012,siga estos pasos:
1. Abra Windows Server Manager. En la consola, seleccione Herramientas Iniciador iSCSI.Se abre el recuadro de diálogo Propiedades del iniciador iSCSI. Seleccione la pestañaDescubrimiento:
FIGURA 22.1: PROPIEDADES DEL INICIADOR ISCSI
322 Conexión de Microsoft Windows (iniciador de Microsoft iSCSI) SES 7
2. En el recuadro de diálogo Descubrimiento del portal de destino, introduzca el nombre dehost o la dirección IP del destino en el campo Destino y haga clic en Aceptar:
FIGURA 22.2: DESCUBRIR PORTAL DE DESTINO
323 Conexión de Microsoft Windows (iniciador de Microsoft iSCSI) SES 7
3. Repita este proceso con todas las demás direcciones IP o nombres de host de la pasarela.Cuando haya terminado, revise la lista Portales de destino:
FIGURA 22.3: PORTALES DE DESTINO
4. A continuación, cambie a la pestaña Destinos y revise los destinos que ha descubierto.
324 Conexión de Microsoft Windows (iniciador de Microsoft iSCSI) SES 7
FIGURA 22.4: DESTINOS
5. Haga clic en Conectar en la pestaña Destinos. Se abre el recuadro de diálogo Conectar condestino. Marque la casilla de vericación Habilitar múltiples rutas para habilitar múltiplesrutas de E/S (MPIO) y, a continuación, haga clic en Aceptar:
325 Conexión de Microsoft Windows (iniciador de Microsoft iSCSI) SES 7
6. Cuando se cierre el recuadro de diálogo Conectar con destino, seleccione Propiedades pararevisar las propiedades del destino:
FIGURA 22.5: PROPIEDADES DE DESTINO ISCSI
326 Conexión de Microsoft Windows (iniciador de Microsoft iSCSI) SES 7
7. Seleccione Dispositivos y haga clic en MPIO para revisar la conguración de múltiples rutasde E/S:
FIGURA 22.6: DETALLES DEL DISPOSITIVO
La opción por defecto para Directiva de equilibrio de carga es Carga rotativa con subconjunto.Si preere una conguración de failover, cambie este valor a Solo failover.
Así concluye la conguración del iniciador iSCSI. Los volúmenes iSCSI están ahora disponiblescomo cualquier otro dispositivo SCSI y se pueden iniciar para usarse como volúmenes yunidades. Haga clic en Aceptar para cerrar el recuadro de diálogo Propiedades del iniciador iSCSIy continúe con la función Servicios de archivo y almacenamiento en la consola Gestor del servidor.
Observe el volumen recién conectado. Se identica como SUSE RBD SCSI Multi-Path Drive enel bus iSCSI e inicialmente se marca con el estado Sin conexión y el tipo de tabla de particiónDesconocido. Si el nuevo volumen no aparece de inmediato, seleccione Volver a explorar elalmacenamiento en la lista desplegable Tareas para volver a explorar el bus iSCSI
327 Conexión de Microsoft Windows (iniciador de Microsoft iSCSI) SES 7
1. Haga clic con el botón derecho en el volumen iSCSI y seleccione Nuevo volumen en el menúcontextual. Se abre Asistente de nuevo volumen. Haga clic en Siguiente, resalte el volumeniSCSI recién conectado y haga clic en Siguiente para comenzar.
FIGURA 22.7: NUEVO ASISTENTE DE VOLUMEN
2. Inicialmente, el dispositivo está vacío y no incluye una tabla de particiones. Cuando sele solicite, conrme el recuadro de diálogo que indica que se inicializará el volumen conuna tabla de particiones GPT:
FIGURA 22.8: MENSAJE DE DISCO SIN CONEXIÓN
328 Conexión de Microsoft Windows (iniciador de Microsoft iSCSI) SES 7
3. Seleccione el tamaño del volumen. Por lo general, utilizará toda la capacidad deldispositivo. Después, asigne una letra de unidad o un nombre de directorio donde estarádisponible el volumen recién creado. A continuación, seleccione el sistema de archivosque se va a crear en el volumen nuevo y, por último, conrme la selección con la opciónCrear para terminar de crear el volumen:
FIGURA 22.9: CONFIRMACIÓN DE LAS OPCIONES DEL VOLUMEN
Cuando termine el proceso, revise los resultados y haga clic en Cerrar para concluir lainicialización de la unidad. Después de que nalice la inicialización, el volumen (y susistema de archivos NTFS) estarán disponibles como una unidad local recién inicializada.
22.1.3 Conexión de VMware
1. Para conectarse a volúmenes iSCSI gestionados con ceph-iscsi , necesita un adaptadorde software iSCSI congurado. Si no hay ningún adaptador de ese tipo disponibleen la conguración de vSphere, cree uno seleccionando Conguración Adaptadores dealmacenamiento Añadir Iniciador de software iSCSI.
329 Conexión de VMware SES 7
2. Si está disponible, haga clic con el botón derecho en el adaptador y seleccione Propiedadesen el menú contextual:
FIGURA 22.10: PROPIEDADES DEL INICIADOR ISCSI
3. En el recuadro de diálogo Iniciador de software iSCSI, haga clic en el botón Congurar. Acontinuación, acceda a la pestaña Descubrimiento dinámico y seleccione Añadir.
4. Introduzca la dirección IP o el nombre de host de su pasarela iSCSI ceph-iscsi . Si ejecutavarias pasarelas iSCSI en una conguración de failover, repita este paso para todas laspasarelas con las que trabaje.
330 Conexión de VMware SES 7
FIGURA 22.11: ADICIÓN DE UN SERVIDOR DE DESTINO
Cuando haya introducido todas las pasarelas iSCSI, haga clic en Aceptar en el recuadro dediálogo para iniciar una nueva exploración del adaptador iSCSI.
331 Conexión de VMware SES 7
5. Cuando nalice la nueva exploración, el nuevo dispositivo iSCSI aparece al nal de la listaAdaptadores de almacenamiento en el panel Detalles. Para dispositivos de múltiples rutas,ahora puede hacer clic con el botón derecho en el adaptador y seleccionar Gestionar rutasen el menú contextual:
FIGURA 22.12: GESTIÓN DE DISPOSITIVOS DE MÚLTIPLES RUTAS
Ahora debería ver todas las rutas con una luz verde en Estado. Una de las rutas debe estarmarcada como Activa E/S y todas las demás simplemente como Activa:
FIGURA 22.13: LISTA DE VÍAS PARA MÚLTIPLES RUTAS
6. Ahora puede cambiar de Adaptadores de almacenamiento al elemento etiquetado comoAlmacenamiento. Seleccione Añadir almacenamiento en la esquina superior derecha delpanel para abrir el recuadro de diálogo Añadir almacenamiento. A continuación, seleccione
332 Conexión de VMware SES 7
Disco/Red de unidad lógica y haga clic en Siguiente. El dispositivo iSCSI recién añadidoaparece en la lista Seleccionar disco o red de unidad lógica. Selecciónelo y haga clic enSiguiente para continuar:
FIGURA 22.14: RECUADRO DE DIÁLOGO PARA AÑADIR ALMACENAMIENTO
Haga clic en Siguiente para aceptar el diseño de disco por defecto.
333 Conexión de VMware SES 7
7. En el panel Propiedades, asigne un nombre al nuevo almacén de datos y haga clic enSiguiente. Acepte la conguración por defecto para utilizar todo el espacio del volumenpara el almacén de datos, o bien seleccione Conguración de espacio personalizada paradenir un almacén de datos más pequeño:
FIGURA 22.15: CONFIGURACIÓN DE ESPACIO PERSONALIZADA
Haga clic en Finalizar para completar la creación del almacén de datos.El nuevo almacén de datos aparece ahora en la lista de almacenes de datos y se puedeseleccionar para recuperar la información. Ahora puede usar el volumen iSCSI con ceph-iscsi como cualquier otro almacén de datos de vSphere.
334 Conexión de VMware SES 7
FIGURA 22.16: RESUMEN DEL ALMACÉN DE DATOS ISCSI
22.2 Conclusiónceph-iscsi es un componente clave de SUSE Enterprise Storage 7 que permite acceder alalmacenamiento de bloques distribuido y de alta disponibilidad desde cualquier servidor ocliente capaz de comunicarse con el protocolo iSCSI. Mediante el uso de ceph-iscsi en unoo varios hosts de iSCSI Gateway, las imágenes de Ceph RBD están disponibles como unidadeslógicas asociados con destinos iSCSI, a los que se puede acceder de forma opcional con equilibriode carga y con alta disponibilidad.
Dado que toda la conguración de ceph-iscsi se almacena en el almacén de objetos deCeph RADOS, los hosts de pasarela ceph-iscsi son inherentemente no persistentes y, por lotanto se pueden reemplazar, aumentar o reducir a voluntad. Como resultado, SUSE EnterpriseStorage 7 permite a los clientes de SUSE ejecutar una tecnología de almacenamiento empresarialverdaderamente distribuida, de alta disponibilidad, resistente y autorreparable en hardware noespecializado y en una plataforma completamente de código abierto.
335 Conclusión SES 7
23 Sistema de archivos en clúster
En este capítulo se describen las tareas de administración que normalmente se llevan a cabodespués de congurar el clúster y exportar CephFS. Si necesita más información sobre cómocongurar CephFS, consulte Libro “Guía de distribución”, Capítulo 5 “Distribución con cephadm”,
Sección 5.4.3.3 “Distribución de servidores de metadatos”.
23.1 Montaje de CephFS
Cuando se crea el sistema de archivos y el servidor de metadatos está activo, estará preparadopara montar el sistema de archivos desde un host de cliente.
23.1.1 Preparación del cliente
Si el host del cliente ejecuta SUSE Linux Enterprise 12 SP2 o una versión posterior, el sistemaya está preparado para montar CephFS sin preparativos adicionales.
Si el host de cliente ejecuta SUSE Linux Enterprise 12 SP1, debe aplicar todos los parches másrecientes antes de montar CephFS.
En cualquier caso, todo lo necesario para montar CephFS se incluye en SUSE Linux Enterprise.El producto SUSE Enterprise Storage 7 no es necesario.
Para admitir la sintaxis completa de mount , el paquete ceph-common (que se incluye con SUSELinux Enterprise) debe estar instalado antes de intentar montar CephFS.
ImportanteSin el paquete ceph-common (y, por tanto, sin el ayudante mount.ceph ), será necesarioutilizar las direcciones IP de los monitores en lugar de sus nombres. Esto se debe a queel cliente del kernel no podrá resolver los nombres.
La sintaxis básica de montaje es:
root # mount -t ceph MON1_IP[:PORT],MON2_IP[:PORT],...:CEPHFS_MOUNT_TARGET \MOUNT_POINT -o name=CEPHX_USER_NAME,secret=SECRET_STRING
336 Montaje de CephFS SES 7
23.1.2 Creación de un archivo secreto
El clúster de Ceph se ejecuta con la autenticación activada por defecto. Debe crear un archivodonde se almacene la clave de secreto (no el anillo de claves en sí). Para obtener la clave desecreto para un usuario concreto y, a continuación, crear el archivo, haga lo siguiente:
PROCEDIMIENTO 23.1: CREACIÓN DE UNA CLAVE SECRETA
1. Muestre la clave para el usuario concreto en un archivo de anillo de claves:
cephuser@adm > cat /etc/ceph/ceph.client.admin.keyring
2. Copie la clave del usuario que va a utilizar el sistema de archivos CephFS montado.Normalmente, la clave tiene un aspecto similar al siguiente:
AQCj2YpRiAe6CxAA7/ETt7Hcl9IyxyYciVs47w==
3. Cree un archivo con el nombre de usuario como parte del nombre de archivo; por ejemplo,/etc/ceph/admin.secret para el usuario admin.
4. Pegue el valor de la clave en el archivo creado en el paso anterior.
5. Dena los derechos de acceso adecuados en el archivo. El usuario debe ser el único quepueda leer el archivo: los demás usuarios no deben tener ningún derecho de acceso.
23.1.3 Montaje de CephFS
Puede montar CephFS con el comando mount . Es preciso especicar el nombre de host o ladirección IP del monitor. Dado que la autenticación cephx está habilitada por defecto en SUSEEnterprise Storage, debe especicar también un nombre de usuario y su secreto relacionado:
root # mount -t ceph ceph_mon1:6789:/ /mnt/cephfs \ -o name=admin,secret=AQATSKdNGBnwLhAAnNDKnH65FmVKpXZJVasUeQ==
Como el comando anterior permanece en el historial de shell, un enfoque más seguro es leerel secreto desde un archivo:
root # mount -t ceph ceph_mon1:6789:/ /mnt/cephfs \ -o name=admin,secretfile=/etc/ceph/admin.secret
Tenga en cuenta que el archivo de secreto solo debe contener el secreto del anillo de clavesactual. En nuestro ejemplo, el archivo solo contendrá la línea siguiente:
AQATSKdNGBnwLhAAnNDKnH65FmVKpXZJVasUeQ==
337 Creación de un archivo secreto SES 7
Sugerencia: especificación de varios monitoresResulta recomendable especicar varios monitores separados por comas en la línea delcomando mount por si un monitor se desactiva en algún momento del montaje. Lasdirecciones de los monitores tiene el formato host[:puerto] . Si no se especica elpuerto, se utiliza por defecto el 6789.
Cree el punto de montaje en el host local:
root # mkdir /mnt/cephfs
Monte CephFS:
root # mount -t ceph ceph_mon1:6789:/ /mnt/cephfs \ -o name=admin,secretfile=/etc/ceph/admin.secret
Es posible especicar un subdirectorio subdir si se va a montar un subconjunto del sistemade archivos:
root # mount -t ceph ceph_mon1:6789:/subdir /mnt/cephfs \ -o name=admin,secretfile=/etc/ceph/admin.secret
Puede especicar más de un host de monitor en el comando mount :
root # mount -t ceph ceph_mon1,ceph_mon2,ceph_mon3:6789:/ /mnt/cephfs \ -o name=admin,secretfile=/etc/ceph/admin.secret
Importante: acceso de lectura al directorio raízSi se usan clientes con restricciones de vía, es preciso incluir acceso de lectura al directorioraíz en los permisos del servidor de metadatos. Por ejemplo, un anillo de claves puedetener este aspecto:
client.bar key: supersecretkey caps: [mds] allow rw path=/barjail, allow r path=/ caps: [mon] allow r caps: [osd] allow rwx
La parte allow r path=/ signica que los clientes que tienen vías restringidas podránver el volumen raíz, pero no escribir en él. Esto puede ser un problema para los casos enlos que se requiera aislamiento completo.
338 Montaje de CephFS SES 7
23.2 Desmontaje de CephFS
Para desmontar CephFS, utilice el comando umount :
root # umount /mnt/cephfs
23.3 Montaje de CephFS en /etc/fstabPara montar CephFS automáticamente durante el inicio del cliente, inserte la líneacorrespondiente en la tabla de su sistema de archivos /etc/fstab :
mon1:6790,mon2:/subdir /mnt/cephfs ceph name=admin,secretfile=/etc/ceph/secret.key,noatime,_netdev 0 2
23.4 Varios daemons de servidor de metadatosactivos (MDS activo-activo)
CephFS está congurado por defecto para un solo daemon de servidor de metadatos activo.Para ampliar el rendimiento de los metadatos en sistemas a gran escala, puede habilitar variosdaemons de servidor de metadatos activos: compartirán la carga de trabajo de los metadatosentre sí.
23.4.1 Uso de servidor de metadatos activo-activo
Puede ser útil usar varios daemons de servidor de metadatos activos si el rendimiento de losmetadatos sufre un cuello de botella en el servidor de metadatos único por defecto.
Añadir más daemons no mejora el rendimiento de todos los tipos de cargas de trabajo. Porejemplo, una única aplicación que se ejecute en un único cliente no se beneciará de un númeromayor de daemons de servidor de metadatos; a menos que la aplicación lleve a cabo muchasoperaciones de metadatos en paralelo.
Las cargas de trabajo que suelen beneciarse de que haya un número mayor de daemons deservidor de metadatos activos son las que tienen muchos clientes, quizás funcionando en muchosdirectorios diferentes.
339 Desmontaje de CephFS SES 7
23.4.2 Aumento del tamaño del clúster activo del servidor demetadatos
Cada sistema de archivos CephFS tiene un valor max_mds que controla el número de rangosque se van a crear. El número real de rangos en el sistema de archivos solo aumentará si hayun daemon de repuesto disponible para hacerse cargo del nuevo rango. Por ejemplo, si hay soloun daemon de servidor de metadatos en ejecución y en max_mds se dene el valor 2, no secreará un segundo rango.
En el ejemplo siguiente, la opción max_mds se dene con el valor 2 para crear un nuevo rangoaparte del rango por defecto. Para ver los cambios, ejecute ceph status antes y, después dedenir max_mds , observe la línea que contiene fsmap :
cephuser@adm > ceph status [...] services: [...] mds: cephfs-1/1/1 up {0=node2=up:active}, 1 up:standby [...]cephuser@adm > ceph fs set cephfs max_mds 2cephuser@adm > ceph status [...] services: [...] mds: cephfs-2/2/2 up {0=node2=up:active,1=node1=up:active} [...]
El rango recién creado (1) pasa por el estado de "creación" y entra en su estado "activo".
Importante: daemons de reservaIncluso con varios daemons de servidor de metadatos activos, un sistema de altadisponibilidad sigue necesitando daemons en espera para que entren en acción si fallaalguno de los servidores en los que se ejecuta un daemon activo.
En consecuencia, el número máximo práctico de max_mds para sistemas de altadisponibilidad es uno menos que el número total de servidores de metadatos del sistema.Para seguir estando disponible en caso de que varios servidores fallen, aumente el númerode daemons en espera del sistema para que sea igual al número de servidores que sepueda admitir que fallen.
340 Aumento del tamaño del clúster activo del servidor de metadatos SES 7
23.4.3 Reducción del número de rangos
Todos los rangos, incluidos los que se van a eliminar, deben estar activos en primer lugar. Estosignica que debe tener al menos el número de max_mds de daemons de servidor de metadatosdisponibles.
En primer lugar, dena en max_mds un número inferior. Por ejemplo, vuelva a tener un únicoservidor de metadatos activo:
cephuser@adm > ceph status [...] services: [...] mds: cephfs-2/2/2 up {0=node2=up:active,1=node1=up:active} [...]cephuser@adm > ceph fs set cephfs max_mds 1cephuser@adm > ceph status [...] services: [...] mds: cephfs-1/1/1 up {0=node2=up:active}, 1 up:standby [...]
23.4.4 Fijación manual de árboles de directorio a un rango
En las conguraciones con varios servidores de metadatos activos, se ejecuta un mecanismo deequilibrio que funciona para distribuir la carga de los metadatos de forma uniforme en el clúster.Esto suele ser sucientemente para la mayoría de los usuarios pero, en ocasiones, es aconsejablesustituir el mecanismo de equilibrio dinámico por asignaciones explícitas de metadatos pararangos concreto. De esta forma, se permite que el administrador o los usuarios puedan distribuiruniformemente la carga de la aplicación o limitar el impacto de las peticiones de metadatos delos usuarios en todo el clúster.
El mecanismo proporcionado para este propósito se denomina "jación de exportación". Setrata de un atributo extendido de los directorios. El nombre de este atributo extendido esceph.dir.pin . Los usuarios pueden denir este atributo mediante comandos estándar:
root # setfattr -n ceph.dir.pin -v 2 /path/to/dir
El valor ( - v ) del atributo extendido es el rango al que se debe asignar el subárbol de directorio.Un valor por defecto de -1 indica que el directorio no está jado.
341 Reducción del número de rangos SES 7
La jación de exportación de directorio se hereda de su padre más próximo que cuente con unajación de exportación denido. Por lo tanto, denir la jación de exportación en un directorio,afecta a todos sus hijos. Sin embargo, la jación padre se puede sustituir deniendo jacionesde exportación en el directorio hijo. Por ejemplo:
root # mkdir -p a/b # "a" and "a/b" start with no export pin set.setfattr -n ceph.dir.pin -v 1 a/ # "a" and "b" are now pinned to rank 1.setfattr -n ceph.dir.pin -v 0 a/b # "a/b" is now pinned to rank 0 # and "a/" and the rest of its children # are still pinned to rank 1.
23.5 Gestión del failoverSi un daemon de servidor de metadatos deja de comunicarse con el monitor, este espera elnúmero de segundos denido en mds_beacon_grace (por defecto, 15 segundos) antes de marcarel daemon como retrasado. Es posible congurar uno o varios daemons en espera que se haráncargo del trabajo durante un failover del daemon de servidor de metadatos.
23.5.1 Configuración reserva-respuesta
Cada sistema de archivos CephFS puede congurarse para añadir daemons de reserva-respuesta.Estos daemons de reserva siguen el registro de metadatos del MDS activo para reducir el tiempode failover en caso de que el MDS activo deje de estar disponible. Cada MDS activo puede tenersolo un daemon de reserva-respuesta siguiéndolo.
Para congurar un daemon de reserva-respuesta en un sistema de archivos, ejecute el comandosiguiente:
cephuser@adm > ceph fs set FS-NAME allow_standby_replay BOOL
Cuando se denen los monitores, se asignan daemons de reserva-respuesta disponibles paraseguir los MDS activos en ese sistema de archivos.
Si un MDS ha entrado en estado de reserva-respuesta, solo se utilizará como daemon de reservapara el rango al que sigue. Si otro rango falla, este daemon de reserva-respuesta no se utilizarácomo sustituto, aunque no haya ningún otro daemon de reserva disponible. Por este motivo,se recomienda que si se utiliza este sistema, todos los MDS activos deben tener un daemon dereserva-respuesta.
342 Gestión del failover SES 7
23.6 Configuración de cuotas de CephFS
Puede establecer cuotas en cualquier subdirectorio del sistema de archivos de Ceph. La cuotarestringe el número de bytes o de archivos almacenados debajo del punto especicado en lajerarquía de directorios.
23.6.1 Limitaciones de cuotas de CephFS
El uso de cuotas con CephFS tiene las siguientes limitaciones:
Las cuotas son cooperativas y no compiten.
Las cuotas de Ceph dependen de que el cliente que está montando el sistema de archivosdeje de escribir en él cuando se alcance un límite. La parte del servidor no puede impedirque un cliente malintencionado escriba tantos datos como necesite. No utilice cuotas paraevitar que se rellene el sistema de archivos en entornos en los que los clientes no sean detotal conanza.
Las cuotas son imprecisas.
Los procesos que se escriben en el sistema de archivos se detienen poco después de quese alcance el límite de cuota. Inevitablemente se les permitirá escribir cierta cantidad dedatos por encima del límite congurado. Los escritores del cliente se detendrán décimasde segundos después de superar el límite congurado.
Las cuotas se implementan en el cliente del kernel a partir de la versión 4.17.
Las cuotas son compatibles con el cliente de espacio de usuario (libcephfs, ceph-fuse). Losclientes del kernel de Linux de la versión 4.17 y superiores admiten cuotas de CephFS enclústeres de SUSE Enterprise Storage 7. Los clientes del kernel (incluso de las versionesrecientes) no podrán controlar las cuotas en clústeres más antiguos, incluso si son capacesde establecer los atributos extendidos de las cuotas. Los kernel SLE12-SP3 (y versionesposteriores) ya incluyen las adaptaciones necesarias para gestionar cuotas.
Configure las cuotas cuidadosamente cuando se utilicen con restricciones de montaje basadas
en vías.
El cliente necesita tener acceso al inodo del directorio en el cual se conguran las cuotaspara aplicarlas. Si el cliente tiene acceso restringido a una vía especíca (por ejemplo/home/user ) según la capacidad del MDS y se congura una cuota en un directorio
343 Configuración de cuotas de CephFS SES 7
antecesor al que no tienen acceso ( /home ), el cliente no la aplicará. Si utiliza restriccionesde acceso basadas en vías, asegúrese de congurar la cuota en el directorio al que puedeacceder el cliente (por ejemplo, /home/user o /home/user/quota_dir ).
23.6.2 Configuración de cuotas de CephFS
Puede congurar cuotas de CephFS mediante atributos extendidos virtuales:
ceph.quota.max_files
Congura un límite de archivos.
ceph.quota.max_bytes
Congura un límite debytes.
Si los atributos aparecen en un inodo de directorio, allí se congura una cuota. Si no estánpresentes, no se establece ninguna cuota en ese directorio (aunque se podría congurar una enun directorio padre).
Para establecer una cuota de 100 MB, ejecute:
cephuser@mds > setfattr -n ceph.quota.max_bytes -v 100000000 /SOME/DIRECTORY
Para establecer una cuota de 10.000 archivos, ejecute:
cephuser@mds > setfattr -n ceph.quota.max_files -v 10000 /SOME/DIRECTORY
Para ver la conguración de cuota, ejecute:
cephuser@mds > getfattr -n ceph.quota.max_bytes /SOME/DIRECTORY
cephuser@mds > getfattr -n ceph.quota.max_files /SOME/DIRECTORY
Nota: cuota no configuradaSi el valor del atributo extendido es "0", no se establece la cuota.
Para eliminar una cuota, ejecute:
cephuser@mds > setfattr -n ceph.quota.max_bytes -v 0 /SOME/DIRECTORYcephuser@mds > setfattr -n ceph.quota.max_files -v 0 /SOME/DIRECTORY
344 Configuración de cuotas de CephFS SES 7
23.7 Gestión de instantáneas de CephFSLas instantáneas de CephFS crean una vista de solo lectura del sistema de archivos del momentoen que se toman. Puede crear una instantánea en cualquier directorio. La instantánea cubrirátodos los datos del sistema de archivos del directorio especicado. Después de crear unainstantánea, los datos almacenados en búfer se vacían de forma asincrónica desde varios clientes.Como resultado, crear una instantánea es muy rápido.
Importante: varios sistemas de archivosSi tiene varios sistemas de archivos CephFS que comparten un único repositorio (medianteespacios de nombres), sus instantáneas tendrán un conicto y si se suprime unainstantánea, faltarán datos de archivo en otras instantáneas que compartan el mismorepositorio.
23.7.1 Creación de instantáneas
La función de instantáneas de CephFS está habilitada por defecto en los nuevos sistemas dearchivos. Para habilitarla en sistemas de archivos existentes, ejecute:
cephuser@adm > ceph fs set CEPHFS_NAME allow_new_snaps true
Después de habilitar las instantáneas, todos los directorios de CephFS tendrán un subdirectorio.snap especial.
NotaEste es un subdirectorio virtual. No aparece en la lista de directorios del directorio padre,pero el nombre .snap no se puede utilizar como nombre de archivo ni directorio. Paraacceder al directorio .snap es necesario acceder a él explícitamente, por ejemplo:
tux > ls -la /CEPHFS_MOUNT/.snap/
Importante: limitación de los clientes del kernelLos clientes del kernel de CephFS tienen una limitación: no pueden gestionar másde 400 instantáneas en un sistema de archivos. El número de instantáneas siempredebe mantenerse por debajo de este límite, independientemente del cliente que se esté
345 Gestión de instantáneas de CephFS SES 7
utilizando. Si se utilizan clientes de CephFS más antiguos, como SLE12-SP3, tenga encuenta que tener más 400 instantáneas es perjudicial para las operaciones, ya que elcliente se detendrá por fallo.
Sugerencia: nombre del subdirectorio de instantáneaspersonalizadoPuede congurar un nombre diferente para el subdirectorio de instantáneas deniendoel valor client snapdir .
Para crear una instantánea, cree un subdirectorio en el directorio .snap con un nombrepersonalizado. Por ejemplo, para crear una instantánea del directorio /CEPHFS_MOUNT/2/3/ ,ejecute:
tux > mkdir /CEPHFS_MOUNT/2/3/.snap/CUSTOM_SNAPSHOT_NAME
23.7.2 Supresión de instantáneas
Para suprimir una instantánea, elimine su subdirectorio dentro del directorio .snap :
tux > rmdir /CEPHFS_MOUNT/2/3/.snap/CUSTOM_SNAPSHOT_NAME
346 Supresión de instantáneas SES 7
24 Exportación de datos de Ceph a través de Samba
En este capítulo se describe cómo exportar datos almacenados en un clúster de Ceph a travésde un recurso compartido Samba/CIFS, de forma que se pueda acceder fácilmente a ellosdesde equipos cliente Windows.* También incluye información que le ayudará a conguraruna pasarela Samba de Ceph para unirse a Active Directory en el dominio de Windows* paraautenticar y autorizar a los usuarios.
Nota: rendimiento de pasarela SambaDebido al aumento de la sobrecarga de protocolo y a la latencia adicional causados porsaltos de red adicionales entre el cliente y el almacenamiento, el acceso a CephFS através de una pasarela Samba puede reducir de forma signicativa el rendimiento de laaplicación en comparación con los clientes de Ceph nativos.
24.1 Exportación de CephFS mediante un recursocompartido Samba
Aviso: acceso con varios protocolosLos clientes nativos de CephFS y NFS no están restringidos por los bloqueos de archivosobtenidos a través de Samba, y viceversa. Las aplicaciones que se basan en el bloqueode archivos con varios protocolos pueden sufrir daños en los datos si se accede a las víascompartidas de Samba respaldadas por CephFS a través de otros medios.
24.1.1 Configuración y exportación de paquetes de Samba
Para congurar y exportar un recurso compartido Samba, es necesario instalar los paquetessiguientes: samba-ceph y samba-winbind . Instale estos paquetes si no lo están:
cephuser@smb > zypper install samba-ceph samba-winbind
347 Exportación de CephFS mediante un recurso compartido Samba SES 7
24.1.2 Ejemplo de pasarela única
Para preparar la exportación de un recurso compartido Samba, elija un nodo adecuado para queactúe como pasarela Samba. El nodo debe tener acceso a la red del cliente de Ceph, así comosucientes recursos de CPU, memoria y redes.
Es posible proporcionar funcionalidad de failover con CTDB y SUSE Linux Enterprise HighAvailability Extension. Consulte la Sección 24.1.3, “Configuración de alta disponibilidad” para obtenermás información sobre la conguración de alta disponibilidad.
1. Asegúrese de que ya existe una instancia de CephFS en funcionamiento en el clúster.
2. Cree un anillo de claves especíco para la pasarela Samba en nodo de administración deCeph y cópielo en ambos nodos de pasarela Samba:
cephuser@adm > ceph auth get-or-create client.samba.gw mon 'allow r' \ osd 'allow *' mds 'allow *' -o ceph.client.samba.gw.keyringcephuser@adm > scp ceph.client.samba.gw.keyring SAMBA_NODE:/etc/ceph/
Sustituya SAMBA_NODE con el nombre del nodo de pasarela de Samba.
3. Los pasos siguientes se ejecutan en el nodo de pasarela Samba. Instale Samba junto conel paquete de integración de Ceph:
cephuser@smb > sudo zypper in samba samba-ceph
4. Sustituya el contenido por defecto del archivo /etc/samba/smb.conf por lo siguiente:
[global] netbios name = SAMBA-GW clustering = no idmap config * : backend = tdb2 passdb backend = tdbsam # disable print server load printers = no smbd: backgroundqueue = no
[SHARE_NAME] path = CEPHFS_MOUNT read only = no oplocks = no kernel share modes = no
348 Ejemplo de pasarela única SES 7
La vía CEPHFS_MOUNT anterior debe montarse antes de iniciar Samba con unaconguración de recurso compartido CephFS del kernel. Consulte la Sección 23.3, “Montaje
de CephFS en /etc/fstab”.La conguración de recursos compartidos anterior utiliza el cliente CephFS del kernel deLinux, lo que se recomienda por motivos de rendimiento. Como alternativa, el móduloSamba vfs_ceph también se puede utilizar para comunicarse con el clúster de Ceph. Lasinstrucciones se muestran a continuación para sistemas heredados, pero no se recomiendanpara distribuciones nuevas de Samba:
[SHARE_NAME] path = / vfs objects = ceph ceph: config_file = /etc/ceph/ceph.conf ceph: user_id = samba.gw read only = no oplocks = no kernel share modes = no
Sugerencia: Oplocks y modos compartidosLos oplocks (también conocidos como arrendamientos SMB2+) mejoran elrendimiento gracias al almacenamiento en caché agresivo del cliente, peroactualmente no son seguros si Samba se distribuye junto con otros clientes deCephFS, como el kernel mount.ceph , FUSE o NFS Ganesha.
Si Samba controla en exclusiva todo el acceso a la vía del sistema de archivosCephFS, el parámetro oplocks se puede habilitar de forma segura.
Actualmente, kernel share modes debe estar inhabilitado en un recursocompartido que se ejecute con el módulo CephFS vfs para que la provisión dearchivos funcione correctamente.
349 Ejemplo de pasarela única SES 7
Importante: permitir el accesoSamba asigna usuarios y grupos de SMB a cuentas locales. A los usuarios locales seles puede asignar una contraseña para el acceso compartido de Samba mediante:
root # smbpasswd -a USERNAME
Para que la E/S se realice correctamente, la lista de control de acceso (ACL) de la víacompartida debe permitir el acceso al usuario conectado a través de Samba. Puedemodicar la ACL montándola temporalmente a través del cliente del kernel deCephFS y utilizando las utilidades chmod , chown o setfacl en la vía del recursocompartido. Por ejemplo, para permitir el acceso a todos los usuarios, ejecute:
root # chmod 777 MOUNTED_SHARE_PATH
24.1.2.1 Inicio de los servicios de Samba
Inicie o reinicie los servicios Samba independientes mediante los comandos siguientes:
root # systemctl restart smb.serviceroot # systemctl restart nmb.serviceroot # systemctl restart winbind.service
Para garantizar que los servicios de Samba se inician al arrancar, habilítelos mediante:
root # systemctl enable smb.serviceroot # systemctl enable nmb.serviceroot # systemctl enable winbind.service
Sugerencia: servicios nmb y winbind opcionalesSi no necesita examinar el recurso compartido de red, no es necesario que habilite e inicieel servicio nmb .
El servicio winbind solo es necesario cuando se congura como miembro del dominiode Active Directory. Consulte la Sección 24.2, “Unión de pasarela Samba y Active Directory”.
350 Ejemplo de pasarela única SES 7
24.1.3 Configuración de alta disponibilidad
Importante: no se permite el failover transparenteAunque una distribución de varios nodos de Samba + CTDB tiene mayor disponibilidadesque un nodo único (consulte el Capítulo 24, Exportación de datos de Ceph a través de Samba),no se admite el failover transparente en el cliente. Es probable que las aplicacionesexperimenten una breve interrupción por el error del nodo de pasarela Samba.
En esta sección se proporciona un ejemplo de cómo establecer una conguración de dos nodos dealta disponibilidad de los servidores de Samba. La conguración requiere SUSE Linux EnterpriseHigh 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://documentation.suse.com/sle-ha/15-SP1/ .
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 usapara la administración del clúster con Hawk2 y 192.168.2.1 se usa exclusivamente para lasexportaciones 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://documentation.suse.com/sle-ha/15-SP1/single-html/SLE-HA-install-quick/ .
1. Cree un anillo de claves especíco de la pasarela Samba en el nodo de administración ycópielo en ambos nodos:
cephuser@adm > ceph auth get-or-create client.samba.gw mon 'allow r' \ osd 'allow *' mds 'allow *' -o ceph.client.samba.gw.keyringcephuser@adm > scp ceph.client.samba.gw.keyring earth:/etc/ceph/cephuser@adm > scp ceph.client.samba.gw.keyring mars:/etc/ceph/
2. La conguración de SLE-HA requiere un dispositivo de aislamiento para evitar unasituación de clúster con nodos malinformados cuando los nodos de clúster activos dejen deestar sincronizados. Para ello, puede utilizar una imagen Ceph RBD con un dispositivode bloques Stonith (SBD). Consulte https://documentation.suse.com/sle-ha/15-SP1/single-
html/SLE-HA-guide/#sec-ha-storage-protect-fencing-setup para obtener más información.
351 Configuración de alta disponibilidad SES 7
Si aún no existe, cree un repositorio RBD denominado rbd (consulte la Sección 18.1,
“Creación de un repositorio”) y asócielo con rbd (consulte la Sección 18.5.1, “Asociación de
repositorios a una aplicación”). A continuación, cree una imagen RBD relacionada llamadasbd01 :
cephuser@adm > ceph osd pool create rbdcephuser@adm > ceph osd pool application enable rbd rbdcephuser@adm > rbd -p rbd create sbd01 --size 64M --image-shared
3. 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 .
root # zypper in ctdb tdb-tools samba samba-ceph
b. Asegúrese de que los servicios Samba y CTDB están detenidos e inhabilitados:
root # systemctl disable ctdbroot # systemctl disable smbroot # systemctl disable nmbroot # systemctl disable winbindroot # systemctl stop ctdbroot # systemctl stop smbroot # systemctl stop nmbroot # systemctl stop winbind
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.
4. En earth , cree los archivos de conguración de Samba. Más adelante, se sincronizaránautomáticamente con mars .
a. Inserte una lista de direcciones IP privadas de los nodos de pasarela Samba en elarchivo /etc/ctdb/node . Encontrará más información en la página de manual dectdb ( man 7 ctdb ).
192.168.1.1192.168.1.2
352 Configuración de alta disponibilidad SES 7
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 extenso coneste nombre): Añada también una denición de recurso compartido, como ejemplo,puede usar SHARE_NAME :
[global] netbios name = SAMBA-HA-GW clustering = yes idmap config * : backend = tdb2 passdb backend = tdbsam ctdbd socket = /var/lib/ctdb/ctdb.socket # disable print server load printers = no smbd: backgroundqueue = no
[SHARE_NAME] path = / vfs objects = ceph ceph: config_file = /etc/ceph/ceph.conf ceph: user_id = samba.gw read only = no oplocks = no kernel share modes = no
Tenga en cuenta que los archivos /etc/ctdb/nodes y /etc/samba/smb.confdeben coincidir en todos los nodos de pasarela Samba.
5. Instale y cargue el clúster de SUSE Linux Enterprise High Availability.
a. Registre SUSE Linux Enterprise High Availability Extension en earth y mars :
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
353 Configuración de alta disponibilidad SES 7
c. Asigne la imagen RBD sbd01 en ambas pasarelas Samba medianterbdmap.service .Edite /etc/ceph/rbdmap y añada una entrada para la imagen SBD:
rbd/sbd01 id=samba.gw,keyring=/etc/ceph/ceph.client.samba.gw.keyring
Habilite e inicie rbdmap.service :
root@earth # systemctl enable rbdmap.service && systemctl start rbdmap.serviceroot@mars # systemctl enable rbdmap.service && systemctl start rbdmap.service
El dispositivo /dev/rbd/rbd/sbd01 debe estar disponible en ambas pasarelasSamba.
d. Inicialice el clúster en earth y deje que mars se una a él.
root@earth # ha-cluster-init
root@mars # ha-cluster-join -c earth
ImportanteDurante el proceso de inicialización y unión al clúster, se le preguntaráde forma interactiva si desea utilizar SBD. Conrme con y y, acontinuación, especique /dev/rbd/rbd/sbd01 como vía al dispositivo dealmacenamiento.
6. Compruebe el estado del clúster. Debería observar que se han añadido dos nodos al clúster:
root@earth # crm status2 nodes configured1 resource configured
Online: [ earth mars ]
Full list of resources:
admin-ip (ocf::heartbeat:IPaddr2): Started earth
7. Ejecute los comandos siguientes en earth para congurar el recurso CTDB:
root@earth # crm configure
354 Configuración de alta disponibilidad SES 7
crm(live)configure# primitive ctdb ocf:heartbeat:CTDB params \ ctdb_manages_winbind="false" \ ctdb_manages_samba="false" \ ctdb_recovery_lock="!/usr/lib64/ctdb/ctdb_mutex_ceph_rados_helper ceph client.samba.gw cephfs_metadata ctdb-mutex" ctdb_socket="/var/lib/ctdb/ctdb.socket" \ op monitor interval="10" timeout="20" \ op start interval="0" timeout="200" \ op stop interval="0" timeout="100"crm(live)configure# primitive smb systemd:smb \ op start timeout="100" interval="0" \ op stop timeout="100" interval="0" \ op monitor interval="60" timeout="100"crm(live)configure# primitive nmb systemd:nmb \ op start timeout="100" interval="0" \ op stop timeout="100" interval="0" \ op monitor interval="60" timeout="100"crm(live)configure# primitive winbind systemd:winbind \ op start timeout="100" interval="0" \ op stop timeout="100" interval="0" \ op monitor interval="60" timeout="100"crm(live)configure# group g-ctdb ctdb winbind nmb smbcrm(live)configure# clone cl-ctdb g-ctdb meta interleave="true"crm(live)configure# commit
Sugerencia: primitivas nmb y winbind opcionalesSi no necesita examinar el recurso compartido de red, no es necesario añadir elprimitivo nmb .
El primitivo winbind solo es necesario si se congura como miembro del dominiode Active Directory. Consulte la Sección 24.2, “Unión de pasarela Samba y Active
Directory”.
El archivo binario /usr/lib64/ctdb/ctdb_mutex_ceph_rados_helper de la opción deconguración ctdb_recovery_lock tiene los parámetros CLUSTER_NAME CEPHX_USERRADOS_POOL y RADOS_OBJECT , en este orden.Es posible anexar un parámetro de tiempo de espera de bloqueo adicional para sustituirel valor por defecto utilizado (10 segundos). Un valor más alto aumentará el tiempo defailover del master de recuperación CTDB, mientras que un valor más bajo puede darlugar a que se detecte incorrectamente que el master de recuperación está inactivo, lo quedesencadenaría conmutaciones por error sucesivas.
355 Configuración de alta disponibilidad SES 7
8. 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 especicada, 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://documentation.suse.com/sle-ha/15-SP1/single-html/SLE-HA-guide/#cha-ha-lb .
9. 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
10. 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
356 Configuración de alta disponibilidad SES 7
24.1.3.1 Reinicio de recursos de Samba de alta disponibilidad
Después de cualquier cambio en la conguración de Samba o CTDB, es posible que sea necesarioreiniciar los recursos de alta disponibilidad para que los cambios surtan efecto. Esto puedehacerse así:
root # crm resource restart cl-ctdb
24.2 Unión de pasarela Samba y Active Directory
Puede congurar la pasarela Samba de Ceph para que se convierta en miembro del dominiode Samba compatible con Active Directory (AD). Como miembro del dominio de Samba, puedeusar usuarios y grupos de dominio en listas de acceso local (ACL) en archivos y directorios delsistema CephFS exportado.
24.2.1 Preparación de la instalación de Samba
En esta sección se presenta los pasos preparatorios que debe tener en cuenta antes de congurarSamba. Empezar con un entorno limpio ayuda a evitar confusiones y permite vericar que no semezcla ningún archivo de la instalación anterior de Samba con la nueva instalación del miembrode dominio.
Sugerencia: sincronización de relojesTodos los relojes de los nodos de la pasarela Samba deben sincronizarse con el controladorde dominio de Active Directory. La diferencia de hora puede provocar errores deautenticación.
Compruebe que no se esté ejecutando ningún proceso de Samba ni de almacenamiento en cachéde nombres:
cephuser@smb > ps ax | egrep "samba|smbd|nmbd|winbindd|nscd"
Si en el resultado aparece algún proceso samba , smbd , nmbd , winbindd o nscd , deténgalos.
357 Unión de pasarela Samba y Active Directory SES 7
Si ha ejecutado previamente una instalación de Samba en este host, elimine el archivo /etc/samba/smb.conf . Elimine también todos los archivos de base de datos de Samba, como losarchivos *.tdb y *.ldb . Para mostrar directorios que contienen bases de datos Samba, ejecute:
cephuser@smb > smbd -b | egrep "LOCKDIR|STATEDIR|CACHEDIR|PRIVATE_DIR"
24.2.2 Verificación de DNS
Active Directory (AD) utiliza DNS para localizar otros controladores de dominio (CD) y servicios,como Kerberos. Por lo tanto, los miembros del dominio de AD y los servidores deben poderresolver las zonas DNS de AD.
Verique que DNS esté congurado correctamente y que tanto la búsqueda directa como lainversa den resultados correctamente, por ejemplo:
cephuser@adm > nslookup DC1.domain.example.comServer: 10.99.0.1Address: 10.99.0.1#53
Name: DC1.domain.example.comAddress: 10.99.0.1
cephuser@adm > 10.99.0.1Server: 10.99.0.1Address: 10.99.0.1#53
1.0.99.10.in-addr.arpa name = DC1.domain.example.com.
24.2.3 Resolución de registros SRV
AD utiliza registros SRV para localizar servicios, como Kerberos y LDAP. Para comprobar si losregistros SRV se resuelven correctamente, utilice la shell interactiva nslookup , por ejemplo:
cephuser@adm > nslookupDefault Server: 10.99.0.1Address: 10.99.0.1
> set type=SRV> _ldap._tcp.domain.example.com.Server: UnKnownAddress: 10.99.0.1
358 Verificación de DNS SES 7
_ldap._tcp.domain.example.com SRV service location: priority = 0 weight = 100 port = 389 svr hostname = dc1.domain.example.comdomain.example.com nameserver = dc1.domain.example.comdc1.domain.example.com internet address = 10.99.0.1
24.2.4 Configuración de Kerberos
Samba admite los back-ends Kerberos Heimdal y MIT. Para congurar Kerberos en el miembrode dominio, dena lo siguiente en el archivo /etc/krb5.conf :
[libdefaults] default_realm = DOMAIN.EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = true
En el ejemplo anterior, Kerberos se congura para el reino DOMAIN.EXAMPLE.COM. No serecomienda denir ningún parámetro adicional en el archivo /etc/krb5.conf . Si /etc/krb5.conf contiene una línea include , no funcionará; debe eliminar esta línea.
24.2.5 Resolución del nombre del host local
Cuando se une un host al dominio, Samba intenta registrar el nombre de host en la zona DNSde AD. Para ello, la utilidad net debe ser capaz de resolver el nombre de host mediante DNSo con una entrada correcta en el archivo /etc/hosts .
Para vericar que el nombre de host se resuelve correctamente, utilice el comando getenthosts :
cephuser@adm > getent hosts example-host10.99.0.5 example-host.domain.example.com example-host
El nombre de host y el nombre completo no deben resolverse en la dirección IP 127.0.0.1 ni enninguna dirección IP que no sea la utilizada en la interfaz LAN del miembro de dominio. Si no semuestra ningún resultado o el host se resuelve en la dirección IP incorrecta y no está utilizandoDHCP, dena la entrada correcta en el archivo /etc/hosts :
127.0.0.1 localhost10.99.0.5 example-host.samdom.example.com example-host
359 Configuración de Kerberos SES 7
Sugerencia: DHCP y /etc/hostsSi utiliza DHCP, compruebe que /etc/hosts solo contiene la línea "127.0.0.1". Si sigueteniendo problemas, póngase en contacto con el administrador del servidor DHCP.
Si necesita añadir alias al nombre de host del equipo, añádalos al nal de la línea quecomienza con la dirección IP del equipo, no a la línea "127.0.0.1".
24.2.6 Configuración de Samba
En esta sección se presenta información sobre las opciones de conguración especícas que debeincluir en la conguración de Samba.
La pertenencia al dominio de Active Directory se congura principalmente con el ajustesecurity = ADS junto con los parámetros de asignación de ID y del dominio de Kerberosadecuados en la sección [global] de /etc/samba/smb.conf .
[global] security = ADS workgroup = DOMAIN realm = DOMAIN.EXAMPLE.COM ...
24.2.6.1 Elección del procesador final para la asignación de ID en winbindd
Si necesita que los usuarios tengan diferentes shells de entrada a la sesión o vías de directoriode inicio de Unix, o si desea que tengan el mismo ID en todas partes, deberá usar el back-endwinbind "ad" y añadir atributos RFC2307 a AD.
Importante: atributos RFC2307 y números de IDLos atributos RFC2307 no se añaden automáticamente cuando se crean usuarios o grupos.
Los números de ID presentes en un controlador de dominio (números en el rango3000000) no son atributos RFC2307 y no se utilizarán en los miembros de dominio deUnix. Si necesita tener los mismos números de ID en todas partes, añada los atributosuidNumber y gidNumber a AD y utilice el back-end winbind "ad" en los miembros dedominio de Unix. Si decide añadir los atributos uidNumber y gidNumber a AD, no utilicenúmeros en el rango 3000000.
360 Configuración de Samba SES 7
Si los usuarios solo usarán el controlador de dominio de AD de Samba para la autenticación yno almacenarán datos ni entrarán a la sesión en él, puede usar el back-end winbind "rid". Estocalcula los ID de usuario y grupo del RID de Windows*. Si utiliza la misma sección [global]de smb.conf en cada miembro de dominio de Unix, obtendrá los mismos ID. Si utiliza el back-end "rid", no es necesario añadir nada a AD y los atributos RFC2307 se omitirán. Cuando utiliceel back-end "rid", dena los parámetros template shell y template homedir en smb.conf .Este valor es global y todos los usuarios obtienen la misma shell de entrada a la sesión y lamisma vía del directorio de inicio de Unix (a diferencia de los atributos RFC2307, donde esposible denir shells y vías del directorio de inicio de Unix individuales).
Hay otra forma de congurar Samba: si necesita que los usuarios y grupos tengan el mismoID en todas partes, pero solo necesitan que los usuarios tengan la mismo shell de entrada a lasesión y usen la misma vía de directorio de inicio de Unix. Puede hacerlo utilizando el back-end winbind "ad" y las líneas de plantilla en smb.conf . De esta forma solo necesita añadir losatributos uidNumber y gidNumber a AD.
Sugerencia: más información sobre back-ends para laasignación de IDEncontrará información detallada sobre los back-end de asignación de ID disponiblesen las páginas man relacionadas: man 8 idmap_ad , man 8 idmap_rid y man 8idmap_autorid .
24.2.6.2 Configuración de rangos de ID de usuario y grupo
Después de decidir qué back-end winbind se va a utilizar, debe especicar los rangos que sedeben usar con la opción idmap config en smb.conf . Por defecto, hay varios bloques de IDde usuarios y grupos en un miembro de dominio de Unix:
TABLA 24.1: BLOQUES DE ID DE USUARIOS Y GRUPOS POR DEFECTO
ID Rango
0-999 Usuarios y grupos delsistema local.
A partir de 1000 Usuarios y grupos deUnix local.
361 Configuración de Samba SES 7
ID Rango
A partir de 10000 Usuarios y grupos deldominio
Como puede ver en los rangos anteriores, no debe denir que los rangos "*" ni "DOMAIN"comiencen en 999 o un valor más bajo, ya que interferirían con los usuarios y grupos del sistemalocal. También debe dejar un espacio para cualquier usuario y grupo local de Unix, por lo queuna buena opción podría ser iniciar los rangos de idmap config en 3000.
Debe decidir cuánto podría crecer "DOMAIN" y si tiene previsto tener dominios de conanza. Acontinuación, puede denir los rangos de idmap config de la siguiente manera:
TABLA 24.2: RANGOS DE ID
Dominio Rango
* 3000-7999
DOMINIO 10000-999999
DE CONFIANZA 1000000-9999999
24.2.6.3 Asignación de la cuenta de administrador de dominio al usuarioroot local
Samba permite asignar cuentas de dominio a una cuenta local. Utilice esta función para ejecutaroperaciones de archivo en el sistema de archivos del miembro del dominio como un usuariodiferente que el de la cuenta que pidió la operación en el cliente.
Sugerencia: asignación del administrador de dominio (opcional)La asignación del administrador de dominio a la cuenta raíz local es opcional.Congure solo la asignación si el administrador de dominio necesita ser capaz de ejecutaroperaciones de archivo en el miembro de dominio con permisos de usuario root . Tengaen cuenta que asignar el administrador a la cuenta raíz no permite entrar a la sesión enlos miembros del dominio Unix como "Administrador".
362 Configuración de Samba SES 7
Para asignar el administrador del dominio a la cuenta raíz local, siga estos pasos:
1. Añada el siguiente parámetro a la sección [global] del archivo smb.conf :
username map = /etc/samba/user.map
2. Cree el archivo /etc/samba/user.map con el siguiente contenido:
!root = DOMAIN\Administrator
ImportanteSi utiliza el back-end de asignación de ID "ad", no dena el atributo uidNumber parala cuenta de administrador de dominio. Si la cuenta tiene el atributo denido, el valorsustituye el UID local "0" del usuario root y, por lo tanto, se produce un error en laasignación.
Para obtener más información, consulte el parámetro username map en la página man desmb.conf ( man 5 smb.conf ).
24.2.7 Unión al dominio de Active Directory
Para unir el host a Active Directory, ejecute:
cephuser@smb > net ads join -U administratorEnter administrator's password: PASSWORDUsing short domain name -- DOMAINJoined EXAMPLE-HOST to dns domain 'DOMAIN.example.com'
24.2.8 Configuración del conmutador de servicio de nombres
Para hacer que los usuarios y grupos de dominio estén disponibles en el sistema local, debehabilitar la biblioteca del conmutador de servicio de nombres (NSS). Añada la entrada winbindal nal de las siguientes bases de datos en el archivo /etc/nsswitch.conf :
passwd: files winbindgroup: files winbind
363 Unión al dominio de Active Directory SES 7
Importante: puntos que se deben tener en cuenta
Conserve la entrada files como el primer origen para ambas bases de datos. Estopermite al NSS buscar usuarios y grupos de dominio desde los archivos /etc/passwd y /etc/group antes de consultar el servicio winbind .
No añada la entrada winbind a la base de datos shadow del NSS. Esto puede causarque la utilidad wbinfo falle.
No utilice los mismos nombres de usuario en el archivo /etc/passwd local que enel dominio.
24.2.9 Inicio de los servicios
Tras los cambios de conguración, reinicie los servicios de Samba según se explica en laSección 24.1.2.1, “Inicio de los servicios de Samba” o en la Sección 24.1.3.1, “Reinicio de recursos de
Samba de alta disponibilidad”.
24.2.10 Prueba de la conectividad de winbindd
24.2.10.1 Envío de un ping de winbindd
Para vericar si el servicio winbindd puede conectarse a los controladores de dominio de ADo a un controlador de dominio primario, escriba:
cephuser@smb > wbinfo --ping-dcchecking the NETLOGON for domain[DOMAIN] dc connection to "DC.DOMAIN.EXAMPLE.COM" succeeded
Si se produce un error en el comando anterior, verique que el servicio winbindd se estáejecutando y que el archivo smb.conf está congurado correctamente.
364 Inicio de los servicios SES 7
24.2.10.2 Búsqueda de usuarios y grupos de dominios
La biblioteca libnss_winbind permite buscar usuarios y grupos de dominio. Por ejemplo, parabuscar el usuario de dominio "DOMAIN\demo01":
cephuser@smb > getent passwd DOMAIN\\demo01DOMAIN\demo01:*:10000:10000:demo01:/home/demo01:/bin/bash
Para buscar el grupo de dominio "Domain Users":
cephuser@smb > getent group "DOMAIN\\Domain Users"DOMAIN\domain users:x:10000:
24.2.10.3 Asignación de permisos de archivos a usuarios y grupos dedominio
La biblioteca del conmutador del servicio de nombres (NSS) permite usar cuentas de usuario dedominio y grupos en los comandos. Por ejemplo, para denir como propietario de un archivoal usuario de dominio "demo01" y como grupo de dominio a "Domain Users", escriba:
cephuser@smb > chown "DOMAIN\\demo01:DOMAIN\\domain users" file.txt
365 Prueba de la conectividad de winbindd SES 7
25 NFS Ganesha
NFS Ganesha es un servidor NFS que se ejecuta en un espacio de dirección de usuario, en lugarde hacerlo como parte del kernel del sistema operativo. Con NFS Ganesha, puede poner enmarcha su propio mecanismo de almacenamiento, como Ceph, y acceder a él desde cualquiercliente NFS. Para obtener instrucciones sobre la instalación, consulte Libro “Guía de distribución”,
Capítulo 5 “Distribución con cephadm”, Sección 5.4.3.6 “Distribución de NFS Ganesha”.
Nota: rendimiento de NFS GaneshaDebido al aumento de la sobrecarga de protocolo y a la latencia adicional causados porsaltos de red adicionales entre el cliente y el almacenamiento, el acceso a Ceph a través deuna pasarela de NFS puede reducir de forma signicativa el rendimiento de la aplicaciónen comparación con los clientes nativos de CephFS.
Cada servicio de NFS Ganesha consta de una jerarquía de conguración que contiene:
Un archivo de carga (bootstrap) ganesha.conf
Un objeto de conguración común RADOS por servicio
Un objeto de conguración RADOS por exportación
La conguración de carga es la conguración mínima para iniciar el daemon nfs-ganeshadentro de un contenedor. Cada conguración de carga contendrá una directiva %url queincluya cualquier conguración adicional del objeto de conguración común RADOS. El objetode conguración común puede incluir directivas %url adicionales para cada una de lasexportaciones NFS denidas en los objetos de conguración RADOS de exportación.
366 SES 7
FIGURA 25.1: ESTRUCTURA DE NFS GANESHA
25.1 Creación de un servicio NFSLa forma recomendada de especicar la distribución de los servicios de Ceph es crear un archivocon formato YAML con la especicación de los servicios que desea distribuir. Puede crear unarchivo de especicación independiente para cada tipo de servicio, o bien especicar varios (otodos) los tipos de servicios en un archivo.
Dependiendo de lo que haya decidido hacer, deberá actualizar o crear un archivo con formatoYAML relevante para crear un servicio de NFS Ganesha. Para obtener más información sobre lacreación del archivo, consulte el Libro “Guía de distribución”, Capítulo 5 “Distribución con cephadm”,
Sección 5.4.2 “Especificación del servicio y la colocación”.
Una vez que haya actualizado o creado el archivo, ejecute lo siguiente para crear un servicionfs-ganesha :
cephuser@adm > ceph orch apply -i FILE_NAME
25.2 Inicio o reinicio de NFS GaneshaPara iniciar el servicio de NFS Ganesha, ejecute:
cephuser@adm > ceph orch start nfs.SERVICE_ID
367 Creación de un servicio NFS SES 7
Para reiniciar el servicio de NFS Ganesha, ejecute:
cephuser@adm > ceph orch restart nfs.SERVICE_ID
Si solo desea reiniciar un único daemon de NFS Ganesha, ejecute:
cephuser@adm > ceph orch daemon restart nfs.SERVICE_ID
Cuando se inicia o se reinicia NFS Ganesha, tiene un tiempo límite de gracia de 90 segundospara NFS v4. Durante el período de gracia, las peticiones nuevas de los clientes se rechazande forma activa. Por lo tanto, los clientes pueden observar una ralentización de las peticionescuando NFS se encuentra en período de gracia.
25.3 Listado de objetos en el repositorio derecuperación NFS
Ejecute lo siguiente para mostrar los objetos del repositorio de recuperación de NFS:
cephuser@adm > rados --pool POOL_NAME --namespace NAMESPACE_NAME ls
25.4 Creación de una exportación NFS
Ejecute lo siguiente para crear una exportación NFS.
NotaEl bloque FSAL debe modicarse para incluir el ID de usuario de cephx deseado y la clavede acceso secreta.
cephuser@adm > rados --pool POOL_NAME --namespace NAMESPACE_NAME put export-1 export-1
368 Listado de objetos en el repositorio de recuperación NFS SES 7
25.5 Verificación de la exportación NFSNFS v4 creará una lista de exportaciones en la raíz de un sistema de archivos simulado. Puedevericar que los recursos compartidos NFS se exportan montando la raíz ( / ) del nodo delservidor NFS Ganesha:
root # mount -t nfs nfs_ganesha_server_hostname:/ /path/to/local/mountpointroot # ls /path/to/local/mountpoint cephfs
Nota: NFS Ganesha solo funciona en v4Por defecto, cephadm congura un servidor NFS v4. NFS v4 no interactúa con rpcbind nicon el daemon mountd . Las herramientas del cliente NFS, como showmount , no muestranninguna exportación congurada.
25.6 Montaje de la exportación NFSPara montar el recurso compartido NFS exportado en un host de cliente, ejecute:
root # mount -t nfs nfs_ganesha_server_hostname:/ /path/to/local/mountpoint
25.7 Varios clústeres de NFS GaneshaEs posible denir varios clústeres de NFS Ganesha, lo que permite:
Clústeres de NFS Ganesha separados para acceder a CephFS.
369 Verificación de la exportación NFS SES 7
V Integración con herramientas devirtualización
26 libvirt y Ceph 371
27 Ceph como procesador final para la instancia de QEMU KVM 377
26 libvirt y Ceph
La biblioteca libvirt crea una capa de abstracción de máquina virtual entre las interfacesde hipervisor y las aplicaciones de software que las utilizan. Con libvirt , los desarrolladoresy administradores del sistema pueden centrarse en un marco de gestión común, API comunesy una interfaz de shell también común ( virsh ) para muchos hipervisores distintos, incluidosQEMU/KVM, Xen, LXC y VirtualBox.
Los dispositivos de bloques de Ceph admiten QEMU/KVM. Es posible utilizar dispositivos debloques de Ceph con software que se conecte con libvirt . La solución de nube utiliza libvirtpara interactuar con QEMU/KVM, y QEMU/KVM interactúa con los dispositivos de bloques deCeph a través de librbd .
Para crear máquinas virtuales que utilicen dispositivos de bloques de Ceph, utilice losprocedimientos de las siguientes secciones. En los ejemplos, hemos utilizado libvirt-poolpara el nombre del repositorio, client.libvirt para el nombre de usuario y new-libvirt-image para el nombre de la imagen. Puede utilizar cualquier nombre que desee, pero asegúresede sustituirlos cuando ejecute los comandos en los procedimientos siguientes.
26.1 Configuración de Ceph con libvirtPara congurar Ceph para su uso con libvirt , realice los pasos siguientes:
1. Cree un repositorio. En el ejemplo siguiente se utiliza el nombre de repositorio libvirt-pool con 128 grupos de colocación.
cephuser@adm > ceph osd pool create libvirt-pool 128 128
Compruebe que el repositorio existe.
cephuser@adm > ceph osd lspools
2. Cree un usuario de Ceph. El siguiente ejemplo utiliza el nombre de usuario de Cephclient.libvirt y hace referencia a libvirt-pool .
cephuser@adm > ceph auth get-or-create client.libvirt mon 'profile rbd' osd \ 'profile rbd pool=libvirt-pool'
Verique que el nombre existe.
371 Configuración de Ceph con libvirt SES 7
cephuser@adm > ceph auth list
Nota: nombre de usuario o IDlibvirt accederá a Ceph utilizando el ID libvirt , no el nombre deCeph client.libvirt . Consulte la Sección 30.2.1.1, “Usuario” para obtener unaexplicación detallada de la diferencia entre el ID y el nombre.
3. Utilice QEMU para crear una imagen en el repositorio RBD. El siguiente ejemplo utilizael nombre de imagen new-libvirt-image y hace referencia a libvirt-pool .
Sugerencia: ubicación del archivo de anillo de clavesLa clave de usuario libvirt se almacena en un archivo de claves colocado enel directorio /etc/ceph . El archivo de claves debe tener un nombre adecuadoque incluya el nombre del clúster de Ceph al que pertenece. Para el nombrede clúster por defecto "ceph", el nombre del archivo de claves es /etc/ceph/ceph.client.libvirt.keyring .
Si el anillo de claves no existe, créelo con:
cephuser@adm > ceph auth get client.libvirt > /etc/ceph/ceph.client.libvirt.keyring
root # qemu-img create -f raw rbd:libvirt-pool/new-libvirt-image:id=libvirt 2G
Verique que la imagen existe.
cephuser@adm > rbd -p libvirt-pool ls
26.2 Preparación del gestor de máquina virtual
Puede utilizar libvirt sin un gestor de máquina virtual, pero le resultará más fácil crear elprimer dominio con virt-manager .
1. Instale un gestor de máquina virtual.
372 Preparación del gestor de máquina virtual SES 7
root # zypper in virt-manager
2. Prepare o descargue una imagen de sistema operativo del sistema que desea ejecutar deforma virtualizada.
3. Lance el gestor de máquina virtual.
virt-manager
26.3 Creación de una máquina virtualPara crear una máquina virtual con virt-manager , realice los siguientes pasos:
1. Elija la conexión en la lista, haga clic con el botón derecho en ella y seleccione New(Nuevo).
2. Para importar la imagen de disco existente proporcione la vía al almacenamiento actual.Especique el tipo de sistema operativo, los valores de memoria y el nombre de la máquinavirtual, por ejemplo libvirt-virtual-machine .
3. Finalice la conguración e inicie la máquina virtual.
4. Verique que el dominio recién creado existe con sudo virsh list . Si es necesario,especique la cadena de conexión, como:
virsh -c qemu+ssh://root@vm_host_hostname/system listId Name State-----------------------------------------------[...] 9 libvirt-virtual-machine running
5. Entre en la máquina virtual y deténgala antes de congurarla para su uso con Ceph.
26.4 Configuración de la máquina virtualEn este capítulo nos centramos en la conguración de máquinas virtuales para su integracióncon Ceph mediante virsh . Los comandos de virsh suelen requerir privilegios de usuario root( sudo ) y, si no se tienen esos privilegios, no proporcionan resultados adecuados ni notican deque esos privilegios son necesarios. Para obtener información sobre los comandos de virsh ,consulte man 1 virsh (se requiere el paquete libvirt-client para instalarse).
373 Creación de una máquina virtual SES 7
1. Abra el archivo de conguración con virsh edit vm-domain-name .
root # virsh edit libvirt-virtual-machine
2. En <devices> debe haber una entrada <disk>.
<devices> <emulator>/usr/bin/qemu-system-SYSTEM-ARCH</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/path/to/image/recent-linux.img'/> <target dev='vda' bus='virtio'/> <address type='drive' controller='0' bus='0' unit='0'/> </disk>
Sustituya /path/to/image/recent-linux.img por la vía a la imagen del sistemaoperativo.
ImportanteUse sudo virsh edit en lugar de un editor de textos. Si edita el archivo deconguración en /etc/libvirt/qemu con un editor de textos, libvirt puedeque no reconozca el cambio. Si hay discrepancias entre el contenido del archivoXML de /etc/libvirt/qemu y el resultado de sudo virsh dumpxml vm-domain-name , puede que la máquina virtual no funcione correctamente.
3. Añada la imagen de Ceph RBD que ha creado anteriormente como una entrada <disk>.
<disk type='network' device='disk'> <source protocol='rbd' name='libvirt-pool/new-libvirt-image'> <host name='monitor-host' port='6789'/> </source> <target dev='vda' bus='virtio'/></disk>
Sustituya monitor-host por el nombre de host y sustituya el nombre del repositorio yel nombre de la imagen según sea necesario. Puede añadir varias entradas <host> paralos monitores de Ceph. El atributo dev es el nombre del dispositivo lógico que apareceráen el directorio /dev de la máquina virtual. El atributo de bus opcional indica el tipode dispositivo de disco que se debe emular. Los valores válidos son especícos de cadacontrolador (por ejemplo ide, scsi, virtio, xen, usb o sata).
374 Configuración de la máquina virtual SES 7
4. Guarde el archivo.
5. Si el clúster de Ceph tiene la autenticación habilitada (lo está por defecto), debe generarun secreto. Abra el editor que quiera y cree un archivo denominado secret.xml con elcontenido siguiente:
<secret ephemeral='no' private='no'> <usage type='ceph'> <name>client.libvirt secret</name> </usage></secret>
6. Dena el secreto.
root # virsh secret-define --file secret.xml<uuid of secret is output here>
7. Obtenga la clave client.libvirt y guarde la cadena de clave en un archivo.
cephuser@adm > ceph auth get-key client.libvirt | sudo tee client.libvirt.key
8. Dena el UUID del secreto.
root # virsh secret-set-value --secret uuid of secret \--base64 $(cat client.libvirt.key) && rm client.libvirt.key secret.xml
También debe denir el secreto manualmente añadiendo la siguiente entrada <auth> alelemento <disk> que introdujo antes (sustituya el valor de uuid con el resultado de lalínea de comandos del ejemplo anterior).
root # virsh edit libvirt-virtual-machine
A continuación, añada el elemento <auth></auth> al archivo de conguración dedominio:
...</source><auth username='libvirt'> <secret type='ceph' uuid='9ec59067-fdbc-a6c0-03ff-df165c0587b8'/></auth><target ...
375 Configuración de la máquina virtual SES 7
NotaEl ID del ejemplo es libvirt , no el nombre de Ceph client.libvirt , como segeneró en el paso 2 de la Sección 26.1, “Configuración de Ceph con libvirt”. Asegúresede utilizar el componente ID del nombre de Ceph que ha generado. Si por algúnmotivo necesita volver a generar el secreto, deberá ejecutar sudo virsh secret-undefine uuid antes de ejecutar sudo virsh secret-set-value de nuevo.
26.5 ResumenDespués de congurar la máquina virtual para usarla con Ceph, puede iniciarla. Para vericarque la máquina virtual y Ceph se comunican, puede llevar a cabo los procedimientos siguientes.
1. Compruebe que se está ejecutando Ceph:
cephuser@adm > ceph health
2. Compruebe que se está ejecutando la máquina virtual:
root # virsh list
3. Compruebe que la máquina virtual se comunica con Ceph. Sustituya vm-domain-namepor el nombre de su dominio de máquina virtual:
root # virsh qemu-monitor-command --hmp vm-domain-name 'info block'
4. Compruebe que el dispositivo de &target dev='hdb' bus='ide'/> aparece en /devo en /proc/partitions :
tux > ls /devtux > cat /proc/partitions
376 Resumen SES 7
27 Ceph como procesador final para la instancia deQEMU KVM
El caso de uso más frecuente de Ceph implica proporcionar imágenes de dispositivo de bloquesa máquinas virtuales. Por ejemplo, un usuario puede crear una imagen lista para usar con unsistema operativo y cualquier software relevante en una conguración ideal. A continuación,el usuario toma una instantánea de la imagen. Por último, el usuario clona la instantánea(normalmente muchas veces, consulte la Sección 20.3, “Instantáneas” para más información). Lacapacidad para crear clones de copia de escritura de una instantánea signica que Ceph puedeprovisionar imágenes de dispositivos de bloques a máquinas virtuales rápidamente, ya que elcliente no necesita descargar una imagen completa cada vez que invoca una máquina virtualnueva.
Los dispositivos de bloques de Ceph pueden integrarse con máquinas virtuales QEMU. Paraobtener más información sobre QEMU KVM, consulte https://documentation.suse.com/sles/15-
SP1/single-html/SLES-virtualization/#part-virt-qemu .
27.1 Instalación de qemu-block-rbdPara poder utilizar dispositivos de bloques de Ceph, QEMU debe tener instalado el controladoradecuado. Compruebe si el paquete qemu-block-rbd está instalado e instálelo si fueranecesario:
root # zypper install qemu-block-rbd
27.2 Uso de QEMULa línea de comandos de QEMU espera que se especique el nombre de repositorio y el nombrede imagen. También puede especicar un nombre de instantánea.
qemu-img command options \rbd:pool-name/image-name@snapshot-name:option1=value1:option2=value2...
Por ejemplo, si especica las opciones id y conf , se puede obtener un resultado parecido alsiguiente:
qemu-img command options \rbd:pool_name/image_name:id=glance:conf=/etc/ceph/ceph.conf
377 Instalación de qemu-block-rbd SES 7
27.3 Creación de imágenes con QEMUPuede crear una imagen de dispositivo de bloques en QEMU. Debe especicar el rbd , el nombredel repositorio y el nombre de la imagen que desea crear. También debe especicar el tamañode la imagen.
qemu-img create -f raw rbd:pool-name/image-name size
Por ejemplo:
qemu-img create -f raw rbd:pool1/image1 10GFormatting 'rbd:pool1/image1', fmt=raw size=10737418240 nocow=off cluster_size=0
ImportanteEl formato de datos raw es en realidad la única opción que se puede usar con RBD.Técnicamente, se podrían utilizar otros formatos compatibles con QEMU, como qcow2 ,pero se requiere mucha más supervisión y haría que el volumen no fuera seguro para lamigración en directo de la máquina virtual si el almacenamiento en caché está habilitado.
27.4 Cambio de tamaño de las imágenes con QEMUPuede cambiar el tamaño de una imagen de dispositivo de bloques en QEMU. Debe especicar elrbd , el nombre del repositorio y el nombre de la imagen cuyo tamaño desea cambiar. Tambiéndebe especicar el tamaño de la imagen.
qemu-img resize rbd:pool-name/image-name size
Por ejemplo:
qemu-img resize rbd:pool1/image1 9GImage resized.
27.5 Recuperación de información de la imagen conQEMUPuede recuperar información de la imagen del dispositivo de bloques en QEMU. Debe especicarel rbd , el nombre del repositorio y el nombre de la imagen.
378 Creación de imágenes con QEMU SES 7
qemu-img info rbd:pool-name/image-name
Por ejemplo:
qemu-img info rbd:pool1/image1image: rbd:pool1/image1file format: rawvirtual size: 9.0G (9663676416 bytes)disk size: unavailablecluster_size: 4194304
27.6 Ejecución de QEMU con RBDQEMU puede acceder a una imagen como dispositivo de bloques virtual directamente a travésde librbd . Esto evita una conmutación de contexto adicional y puede aprovechar las ventajasdel almacenamiento en caché de RBD.
Puede utilizar qemu-img para convertir las imágenes de la máquina virtual existentes aimágenes de dispositivos de bloques de Ceph. Por ejemplo, si dispone de una imagen qcow2,ejecute:
qemu-img convert -f qcow2 -O raw sles12.qcow2 rbd:pool1/sles12
Para ejecutar un arranque de la máquina virtual desde esa imagen, ejecute:
root # qemu -m 1024 -drive format=raw,file=rbd:pool1/sles12
El almacenamiento en caché de RBD puede mejorar signicativamente el rendimiento. Lasopciones de caché de QEMU controlan el almacenamiento en caché de librbd :
root # qemu -m 1024 -drive format=rbd,file=rbd:pool1/sles12,cache=writeback
Para obtener más información sobre el almacenamiento en caché de RBD, consulte la Sección 20.5,
“Ajustes de caché”.
27.7 Habilitación de descartes y TRIMLos dispositivos de bloques de Ceph admiten la operación de descarte. Esto signica que uninvitado puede enviar peticiones TRIM para permitir que un dispositivo de bloques de Cephreclame espacio no utilizado. Esto se puede habilitar en el invitado montando XFS con la opciónde descarte.
379 Ejecución de QEMU con RBD SES 7
Para que esto esté disponible para el invitado, se debe habilitar explícitamente para el dispositivode bloques. Para ello, debe especicar una opción discard_granularity asociada a la unidad:
root # qemu -m 1024 -drive format=raw,file=rbd:pool1/sles12,id=drive1,if=none \-device driver=ide-hd,drive=drive1,discard_granularity=512
NotaEn el ejemplo anterior se utiliza el controlador IDE. El controlador virtio no admite eldescarte.
Si utiliza libvirt , edite el archivo de conguración del dominio de libvirt con el comandovirsh edit e incluya el valor xmlns:qemu . A continuación, añada qemu:commandline blockcomo hijo de dicho dominio. El siguiente ejemplo muestra cómo denir dos dispositivos conqemu id= con valores discard_granularity distintos.
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> <qemu:commandline> <qemu:arg value='-set'/> <qemu:arg value='block.scsi0-0-0.discard_granularity=4096'/> <qemu:arg value='-set'/> <qemu:arg value='block.scsi0-0-1.discard_granularity=65536'/> </qemu:commandline></domain>
27.8 Configuración de las opciones de caché deQEMULas opciones de caché de QEMU se corresponden con los siguientes valores de caché de CephRBD.
Writeback (actualización de la memoria a través de datos de caché):
rbd_cache = true
WriteThrough (escritura integral caché-memoria):
rbd_cache = truerbd_cache_max_dirty = 0
380 Configuración de las opciones de caché de QEMU SES 7
None (Ninguna):
rbd_cache = false
Los valores de caché de QEMU sustituyen a los valores por defecto de Ceph (los valores queno se denan explícitamente en el archivo de conguración de Ceph). Si dene explícitamentelos valores de caché de RBD en el archivo de conguración de Ceph (consulte la Sección 20.5,
“Ajustes de caché”), los valores de Ceph sustituirán a los valores de caché de QEMU. Si denelos valores de caché en la línea de comandos de QEMU, los valores de la línea de comandos deQEMU sustituyen a los valores del archivo de conguración de Ceph.
381 Configuración de las opciones de caché de QEMU SES 7
VI Configuración de un clúster
28 Configuración del clúster de Ceph 383
29 Módulos de Ceph Manager 404
30 Autenticación con cephx 409
28 Configuración del clúster de Ceph
En este capítulo se describe cómo congurar el clúster de Ceph mediante las opciones deconguración.
28.1 Configuración del archivo ceph.confcephadm utiliza un archivo ceph.conf básico que solo contiene un conjunto mínimo deopciones para conectarse a los MON, autenticarse y obtener información de conguración. Enla mayoría de los casos, esto se limita a la opción mon_host (aunque se puede evitar medianteel uso de registros SRV de DNS).
ImportanteEl archivo ceph.conf ya no sirve como lugar central para almacenar la conguracióndel clúster. Ahora se usa la base de datos de conguración (consulte la Sección 28.2, “Base
de datos de configuración”).
Si aún necesita cambiar la conguración del clúster mediante el archivo ceph.conf (porejemplo, porque utiliza un cliente que no admite opciones de lectura de la base de datos deconguración), debe ejecutar el comando siguiente y encargarse de mantener y distribuirel archivo ceph.conf en todo el clúster:
cephuser@adm > ceph config set mgr mgr/cephadm/manage_etc_ceph_ceph_conf false
28.1.1 Acceso a ceph.conf dentro de imágenes de contenedor
Aunque los daemons de Ceph se ejecutan en contenedores, aún puede acceder a su archivo deconguración ceph.conf . Se monta mediante asociación como el siguiente archivo en el sistemahost:
/var/lib/ceph/CLUSTER_FSID/DAEMON_NAME/config
383 Configuración del archivo ceph.conf SES 7
Sustituya CLUSTER_FSID por el FSID exclusivo del clúster en ejecución tal y como lo devuelveel comando ceph fsid y DAEMON_NAME por el nombre del daemon especíco que aparece enel comando ceph orch ps . Por ejemplo:
/var/lib/ceph/b4b30c6e-9681-11ea-ac39-525400d7702d/osd.2/config
Para modicar la conguración de un daemon, edite su archivo config y reinícielo:
root # systemctl restart ceph-CLUSTER_FSID-DAEMON_NAME
Por ejemplo:
root # systemctl restart ceph-b4b30c6e-9681-11ea-ac39-525400d7702d-osd.2
ImportanteTodos los ajustes personalizados se perderán después de que cephadm vuelva a distribuirel daemon.
28.2 Base de datos de configuración
Los monitores Ceph Monitor gestionan una base de datos central de opciones de conguraciónque afectan al comportamiento de todo el clúster.
28.2.1 Configuración de secciones y máscaras
Las opciones de conguración almacenadas por MON pueden encontrarse en una sección global,de tipo de daemon o de daemon especíco. Además, las opciones también pueden tener unamáscara asociada para restringir aún más a qué daemons o clientes se aplica la opción. Lasmáscaras tienen dos formas:
TIPO : UBICACIÓN , donde TIPO es una propiedad de CRUSH como rack o host , yUBICACIÓN es un valor para esa propiedad.
384 Base de datos de configuración SES 7
Por ejemplo, host: host_de_ejemplo limitará la opción solo a los daemons o clientesque se ejecutan en ese host concreto.
CLASE : CLASE_DE_DISPOSITiVO , donde CLASE_DE_DISPOSITIVO es el nombre de unaclase de dispositivo CRUSH como hdd o ssd . Por ejemplo, class:ssd limitará la opciónsolo a los OSD respaldados por SSD. Esta máscara no tiene ningún efecto en los daemonso clientes que no sean OSD.
28.2.2 Ajuste y lectura de opciones de configuración
Utilice los comandos siguientes para denir o leer las opciones de conguración del clúster. Elparámetro WHO puede ser un nombre de sección, una máscara o una combinación de ambosseparados por un carácter de barra (/). Por ejemplo, osd/rack:foo representa todos losdaemons OSD del bastidor denominado foo .
ceph config dump
Vuelca toda la base de datos de conguración de un clúster completo.
ceph config get WHO
Vuelca la conguración de un daemon o cliente especícos (por ejemplo, mds.a ), tal comose almacena en la base de datos de conguración.
ceph config set WHO OPTION VALUE
Establece el valor especicado en la opción de conguración de la base de datos deconguración.
ceph config show WHO
Muestra la conguración en ejecución noticada para un daemon en ejecución. Estosajustes pueden diferir de los almacenados por los monitores si también hay en uso archivosde conguración locales o si se han anulado opciones en la línea de comandos o en eltiempo de ejecución. El origen de los valores de la opción se notica como parte delresultado.
ceph config assimilate-conf -i INPUT_FILE -o OUTPUT_FILE
Importa un archivo de conguración especicado como INPUT_FILE y almacena lasopciones válidas en la base de datos de conguración. Cualquier ajuste que no se reconozca,que no sea válido o que el monitor no pueda controlar se devolverá en un archivo abreviadoalmacenado como OUTPUT_FILE . Este comando es útil para realizar la transición dearchivos de conguración legados a una conguración centralizada basada en monitor.
385 Ajuste y lectura de opciones de configuración SES 7
28.2.3 Configuración de daemons en tiempo de ejecución
En la mayoría de los casos, Ceph permite realizar cambios en la conguración de un daemon entiempo de ejecución. Esto es útil, por ejemplo, cuando necesita aumentar o disminuir el volumende salida del registro, o cuando se realiza la optimización del clúster en tiempo de ejecución.
Puede actualizar los valores de las opciones de conguración con el comando siguiente:
cephuser@adm > ceph config set DAEMON OPTION VALUE
Por ejemplo, para ajustar el nivel de registro de depuración en un OSD especíco, ejecute:
cephuser@adm > ceph config set osd.123 debug_ms 20
NotaSi la misma opción también se personaliza en un archivo de conguración local, el ajustedel monitor se ignorará porque tiene menos prioridad que el archivo de conguración.
28.2.3.1 Anulación de valores
Es posible modicar temporalmente el valor de una opción mediante los subcomandos tell odaemon . Dicha modicación solo afecta al proceso en ejecución y se descarta después de queel daemon o el proceso se reinicien.
Existen dos formas de anular valores:
Utilice el subcomando tell para enviar un mensaje a un daemon especíco desdecualquier nodo del clúster:
cephuser@adm > ceph tell DAEMON config set OPTION VALUE
Por ejemplo:
cephuser@adm > ceph tell osd.123 config set debug_osd 20
386 Configuración de daemons en tiempo de ejecución SES 7
SugerenciaEl subcomando tell acepta comodines como identicadores de daemon. Porejemplo, para ajustar el nivel de depuración en todos los daemons de OSD, ejecute:
cephuser@adm > ceph tell osd.* config set debug_osd 20
Utilice el subcomando daemon para conectarse a un proceso de daemon especícomediante un zócalo en /var/run/ceph desde el nodo donde se ejecuta el proceso:
cephuser@adm > ceph daemon DAEMON config set OPTION VALUE
Por ejemplo:
cephuser@adm > ceph daemon osd.4 config set debug_osd 20
SugerenciaAl visualizar los ajustes de tiempo de ejecución con el comando ceph config show(consulte la Sección 28.2.3.2, “Visualización de los ajustes del tiempo de ejecución”), los valoresanulados temporalmente se mostrarán con override en origen.
28.2.3.2 Visualización de los ajustes del tiempo de ejecución
Para ver todas las opciones denidas para un daemon:
cephuser@adm > ceph config show-with-defaults osd.0
Para ver todas las opciones que no están denidas por defecto para un daemon:
cephuser@adm > ceph config show osd.0
Para inspeccionar una opción especíca:
cephuser@adm > ceph config show osd.0 debug_osd
También puede conectarse a un daemon en ejecución desde el nodo donde se está ejecutandosu proceso y observar su conguración:
cephuser@adm > ceph daemon osd.0 config show
387 Configuración de daemons en tiempo de ejecución SES 7
Para ver solo los ajustes que no son los ajustes por defecto:
cephuser@adm > ceph daemon osd.0 config diff
Para inspeccionar una opción especíca:
cephuser@adm > ceph daemon osd.0 config get debug_osd
28.3 Almacén config-keyconfig-key es un servicio de uso general que ofrecen los monitores Ceph Monitor. Simplicala gestión de las claves de conguración al almacenar pares clave-valor de forma permanente.config-key se utiliza principalmente en herramientas y daemons de Ceph.
SugerenciaDespués de añadir una clave nueva o modicar una existente, reinicie el servicio afectadopara que los cambios surtan efecto. Encontrará más información sobre el funcionamientode los servicios de Ceph en el Capítulo 14, Funcionamiento de los servicios de Ceph.
Utilice el comando config-key para hacer funcionar el almacén config-key . El comandoconfig-key utiliza los siguientes subcomandos:
ceph config-key rm KEY
Suprime la clave especicada.
ceph config-key exists KEY
Comprueba si la clave especicada existe.
ceph config-key get KEY
Recupera el valor de la clave especicada.
ceph config-key ls
Muestra todas las claves.
ceph config-key dump
Vuelca todas las claves y sus valores.
ceph config-key set KEY VALUE
Almacena la clave especicada con el valor especicado.
388 Almacén config-key SES 7
28.3.1 iSCSI Gateway
iSCSI Gateway utiliza el almacén config-key para guardar o leer sus opciones de conguración.Todas las claves relacionadas con iSCSI Gateway tienen como prejo la cadena iscsi , porejemplo:
iscsi/trusted_ip_listiscsi/api_portiscsi/api_useriscsi/api_passwordiscsi/api_secure
Si necesita, por ejemplo, dos conjuntos de opciones de conguración, extienda el prejo conotra palabra clave descriptiva; por ejemplo, datacenterA y datacenterB :
iscsi/datacenterA/trusted_ip_listiscsi/datacenterA/api_port[...]iscsi/datacenterB/trusted_ip_listiscsi/datacenterB/api_port[...]
28.4 Ceph OSD y BlueStore
28.4.1 Configuración del tamaño automático del caché
BlueStore se puede congurar para que cambie automáticamente el tamaño de sus cachés sise congura tc_malloc como asignador de memoria y el valor bluestore_cache_autotuneestá habilitado. Esta opción está habilitada por defecto. BlueStore intentará mantener el usode memoria del montón OSD por debajo de un tamaño de destino designado mediante laopción de conguración osd_memory_target . Se trata de un algoritmo de mejor esfuerzoy las memorias caché no se reducirán a un tamaño más pequeño que el indicado por elvalor de osd_memory_cache_min . Las relaciones de caché se elegirán en función de unajerarquía de prioridades. Si la información de prioridad no está disponible, las opcionesbluestore_cache_meta_ratio y bluestore_cache_kv_ratio se utilizan como reserva.
bluestore_cache_autotune
Ajusta automáticamente las relaciones asignadas a diferentes cachés de BlueStorerespetando los valores mínimos. El valor por defecto es True (verdadero).
389 iSCSI Gateway SES 7
osd_memory_target
Si tc_malloc y bluestore_cache_autotune están habilitados, intenta mantener almenos este número de bytes asignados en la memoria.
NotaEsto podría no coincidir exactamente con el uso de memoria de RSS del proceso.Aunque la cantidad total de memoria de montón asignada por el procesogeneralmente debe ser aproximadamente la de este destino, no existe garantíaalguna de que el kernel recupere la memoria cuya asignación se ha anulado.
osd_memory_cache_min
Si tc_malloc y bluestore_cache_autotune están habilitados, dene la cantidadmínima de memoria que se utiliza para las memorias caché.
NotaSi se dene un valor demasiado bajo en esta opción, se podría producir unahiperpaginación signicativa de caché.
28.5 Ceph Object GatewayPuede inuir en el comportamiento de Object Gateway mediante varias opciones. Si no seespecica ninguna opción, se utiliza su valor por defecto. A continuación se muestra una listacompleta de las opciones de Object Gateway:
28.5.1 Valores generales
rgw_frontends
Congura los front-ends HTTP. Puede especicar varios front-ends en una lista delimitadapor comas. Cada conguración de front-end puede incluir una lista de opciones separadaspor espacios, donde cada opción tiene el formato "clave-valor" o "clave". El valor pordefecto es beast port=7480 .
rgw_data
390 Ceph Object Gateway SES 7
Dene la ubicación de los archivos de datos para Object Gateway. El valor por defecto es/var/lib/ceph/radosgw/ID_CLÚSTER .
rgw_enable_apis
Habilita las API especicadas. El valor por defecto es "s3, swift, swift_auth, admin All APIs".
rgw_cache_enabled
Habilita o inhabilita el caché de Object Gateway. El valor por defecto es true (verdadero).
rgw_cache_lru_size
El número de entradas en caché de Object Gateway. El valor por defecto es 10000.
rgw_socket_path
La vía del zócalo de dominio. FastCgiExternalServer utiliza este zócalo. Si no especicauna vía de zócalo, Object Gateway no se ejecutará como servidor externo. La vía queespecique aquí debe ser la misma que la especicada en el archivo rgw.conf .
rgw_fcgi_socket_backlog
El backlog del zócalo para fcgi. El valor por defecto es 1024.
rgw_host
El host de la instancia de Object Gateway. Puede ser una dirección IP o un nombre de host.El valor por defecto es 0.0.0.0 .
rgw_port
El número de puerto en el que la instancia escucha las peticiones. Si no se especica, ObjectGateway ejecuta FastCGI externo.
rgw_dns_name
El nombre DNS del dominio provisto.
rgw_script_uri
El valor alternativo para SCRIPT_URI si no se establece en la petición.
rgw_request_uri
El valor alternativo para REQUEST_URI si no se establece en la petición.
rgw_print_continue
Habilite 100-continue si está operativo. El valor por defecto es true (verdadero).
rgw_remote_addr_param
391 Valores generales SES 7
El parámetro de dirección remota. Por ejemplo, el campo HTTP que contiene la direcciónremota o la dirección X-Forwarded-For si hay un proxy inverso operativo. El valor pordefecto es REMOTE_ADDR .
rgw_op_thread_timeout
El tiempo límite en segundos para los hilos abiertos. El valor por defecto es 600.
rgw_op_thread_suicide_timeout
El tiempo límite en segundos antes de que el proceso de Object Gateway se interrumpa.Este valor está inhabilitado si se establece en 0 (por defecto).
rgw_thread_pool_size
El número de hilos para el servidor de Beast. Se incrementa a un valor superior si necesitaatender más peticiones. Por defecto es 100 hilos.
rgw_num_rados_handles
El número de referencias de clúster de RADOS para Object Gateway. Cada hilo de trabajode Object Gateway elige ahora una referencia de RADOS para toda su vida útil. Esta opciónpuede quedar obsoleta y eliminarse en futuras versiones. El valor por defecto es 1.
rgw_num_control_oids
El número de objetos de noticación utilizados para la sincronización de caché entrediferentes instancias de Object Gateway. El valor por defecto es 8.
rgw_init_timeout
El número de segundos antes de que Object Gateway renuncie a la inicialización. El valorpor defecto es 30.
rgw_mime_types_file
La vía y la ubicación de los tipos MIME. Se utiliza para la detección automática de Swiftde tipos de objetos. El valor por defecto es /etc/mime.types .
rgw_gc_max_objs
El número máximo de objetos que puede controlar la recopilación de elementos noutilizados en un ciclo de procesamiento de recopilación de elementos no utilizados. Elvalor por defecto es 32.
rgw_gc_obj_min_wait
El tiempo de espera mínimo antes de que el objeto se puede eliminar y controlar medianteel procesamiento de recopilación de elementos no utilizados. El valor por defecto es2*3600.
392 Valores generales SES 7
rgw_gc_processor_max_time
El tiempo máximo entre el comienzo de dos ciclos de procesamiento de recopilación deelementos no utilizados consecutivos. El valor por defecto es 3600.
rgw_gc_processor_period
El tiempo de ciclo del procesamiento de recopilación de elementos no utilizados. El valorpor defecto es 3600.
rgw_s3_success_create_obj_status
La respuesta alternativa del estado de éxito para create-obj . El valor por defecto es 0.
rgw_resolve_cname
Indica si Object Gateway debe usar el registro CNAME DNS del campo de nombre de hostde la petición (si el nombre de host no es igual al nombre DNS de Object Gateway). Elvalor por defecto es false (falso).
rgw_obj_stripe_size
El tamaño de una repartición de objetos de Object Gateway. El valor por defecto es 4 <<20 .
rgw_extended_http_attrs
Añade un nuevo conjunto de atributos que se pueden denir en una entidad (por ejemplo,un usuario, un depósito o un objeto). Estos atributos adicionales se pueden denir mediantecampos de encabezado HTTP al colocar la entidad o modicarla mediante el método POST.Si se denen, estos atributos se devolverán como campos HTTP cuando se pida el GET/HEAD de la entidad. El valor por defecto es content_foo, content_bar, x-foo-bar .
rgw_exit_timeout_secs
Número de segundos que se esperará un proceso antes de salir incondicionalmente. Elvalor por defecto es 120.
rgw_get_obj_window_size
El tamaño de la ventana, en bytes, para una petición de un solo objeto. El valor por defectoes 16 << 20 .
rgw_get_obj_max_req_size
El tamaño máximo de petición de una sola operación GET enviada al clúster dealmacenamiento de Ceph. El valor por defecto es 4 << 20 .
rgw_relaxed_s3_bucket_names
393 Valores generales SES 7
Habilita las reglas de nombre de depósito de S3 en expansión para depósitos de la regiónde EE. UU. El valor por defecto es false (falso).
rgw_list_buckets_max_chunk
El número máximo de depósitos que se van a recuperar en una sola operación al mostrarlas depósitos de usuario. El valor por defecto es 1000.
rgw_override_bucket_index_max_shards
Representa el número de fragmentos para el objeto de índice de depósito. El valor 0 (pordefecto) indica que no hay partición. No se recomienda denir un valor demasiado grande(por ejemplo 1000) ya que aumenta el coste de la lista de depósitos. Esta variable sedebe establecer en las secciones del cliente o en las globales, de forma que se apliqueautomáticamente a los comandos radosgw-admin .
rgw_curl_wait_timeout_ms
El tiempo de espera en milisegundos para determinadas llamadas curl . El valor pordefecto es 1000.
rgw_copy_obj_progress
Habilita los resultados del progreso del objeto durante las operaciones de copia largas. Elvalor por defecto es true (verdadero).
rgw_copy_obj_progress_every_bytes
Los bytes mínimos entre los resultados de progreso de las operaciones de copia. El valorpor defecto es 1024*1024.
rgw_admin_entry
El punto de entrada de una dirección URL de petición de administrador. El valor por defectoes admin .
rgw_content_length_compat
Habilita el control de compatibilidad de las peticiones FCGI con CONTENT_LENGTH yHTTP_CONTENT_LENGTH denidos. El valor por defecto es false (falso).
rgw_bucket_quota_ttl
El tiempo en segundos durante el cual la información de cuota almacenada en caché esde conanza. Cuando transcurre este tiempo límite, la información de cuota se vuelve arecuperar del clúster. El valor por defecto es 600.
rgw_user_quota_bucket_sync_interval
394 Valores generales SES 7
El tiempo en segundos durante el cual se acumula la información de cuota del depósitoantes de sincronizarse con el clúster. Durante este tiempo, las demás instancias de ObjectGateway no verán los cambios en las estadísticas de cuota de depósito relacionados conlas operaciones de esta instancia. El valor por defecto es 180.
rgw_user_quota_sync_interval
El tiempo en segundos durante el cual se acumula la información de cuota de usuarioantes de sincronizarla con el clúster. Durante este tiempo, las demás instancias de ObjectGateway no verán los cambios en las estadísticas de cuota de usuario relacionados con lasoperaciones de esta instancia. El valor por defecto es 180.
rgw_bucket_default_quota_max_objects
Número máximo por defecto de objetos por depósito. Se establece en los nuevos usuarios sino se especica ninguna otra cuota y no tiene ningún efecto sobre los usuarios existentes.Esta variable se debe establecer en las secciones del cliente o en las globales, de forma quese aplique automáticamente a los comandos radosgw-admin . El valor por defecto es -1.
rgw_bucket_default_quota_max_size
Capacidad máxima por defecto por depósito en bytes. Se establece en los nuevos usuariossi no se especica ninguna otra cuota y no tiene ningún efecto sobre los usuarios existentes.El valor por defecto es -1.
rgw_user_default_quota_max_objects
Número máximo por defecto de objetos para un usuario. Esto incluye todos los objetosde todos los depósitos propiedad del usuario. Se establece en los nuevos usuarios si nose especica ninguna otra cuota y no tiene ningún efecto sobre los usuarios existentes. Elvalor por defecto es -1.
rgw_user_default_quota_max_size
El valor de la cuota de tamaño máximo de usuario en bytes denido en los nuevos usuariossi no se especica ninguna otra cuota. No tiene ningún efecto sobre los usuarios existentes.El valor por defecto es -1.
rgw_verify_ssl
Verique los certicados SSL mientras realiza las peticiones. El valor por defecto es true(verdadero).
rgw_max_chunk_size
395 Valores generales SES 7
El tamaño máximo de una porción de datos que se leerá en una única operación. Si seaumenta el valor a 4 MB (4194304) se conseguirá un mejor rendimiento al procesar objetosgrandes. El valor por defecto es 128 kB (131072).
CONFIGURACIÓN DE VARIOS SITIOS
rgw_zone
El nombre de la zona de la instancia de pasarela. Si no se dene ninguna zona, es posiblecongurar un valor por defecto para todo el clúster con el comando radosgw-admin zonedefault .
rgw_zonegroup
El nombre del grupo de zonas de la instancia de pasarela. Si no se dene ningún grupode zonas, es posible congurar un valor por defecto para todo el clúster con el comandoradosgw-admin zonegroup default .
rgw_realm
El nombre del reino de la instancia de pasarela. Si no se dene ningún reino, es posiblecongurar un valor por defecto para todo el clúster con el comando radosgw-admin realmdefault .
rgw_run_sync_thread
Si hay otras zonas en el reino desde las que se deba sincronizar, genere hilos para controlarla sincronización de datos y metadatos. El valor por defecto es true (verdadero).
rgw_data_log_window
La ventana de entradas del registro de datos en segundos. El valor por defecto es 30.
rgw_data_log_changes_size
El número de entradas en memoria que se deben conservar para el registro de cambios dedatos. El valor por defecto es 1000.
rgw_data_log_obj_prefix
El prejo del nombre de objeto para el registro de datos. El valor por defecto es "data_log".
rgw_data_log_num_shards
El número de fragmentos (objetos) de los que se debe mantener el registro de cambios dedatos. El valor por defecto es 128.
rgw_md_log_max_shards
El número máximo de fragmentos para el registro de metadatos. El valor por defecto es 64.
396 Valores generales SES 7
CONFIGURACIÓN DE SWIFT
rgw_enforce_swift_acls
Aplica los valores de la lista de control de acceso (ACL) de Swift. El valor por defecto estrue (verdadero).
rgw_swift_token_expiration
El tiempo en segundos que falta para que caduque el testigo de Swift. El valor por defectoes 24*3600.
rgw_swift_url
La URL de la API de Swift de Ceph Object Gateway.
rgw_swift_url_prefix
El prejo de URL para StorageURL de Swift que precede a "/v1". Esto permite ejecutarvarias instancias de pasarela en el mismo host. Por motivos de compatibilidad, si estavariable de conguración se deja vacía, se utilizará el indicador "/swift" por defecto. Utiliceel prejo explícito "/" para iniciar StorageURL en la raíz.
AvisoDenir "/" en esta opción no funcionará si la API de S3 está habilitada. Tenga encuenta que inhabilitar S3 hará que sea imposible distribuir Object Gateway en laconguración de varios sitios.
rgw_swift_auth_url
La URL por defecto para vericar los testigos de autenticación v1 si no se utiliza laautenticación interna de Swift.
rgw_swift_auth_entry
El punto de entrada para una dirección URL de autenticación de Swift. El valor por defectoes auth .
rgw_swift_versioning_enabled
Habilita el control de versiones de objetos de la API de almacenamiento de objetos deOpenStack. Esto permite a los clientes colocar el atributo X-Versions-Location en loscontenedores que se deben versionar. El atributo especica el nombre del contenedordonde se almacenan las versiones archivadas. Por motivos de vericación del control de
397 Valores generales SES 7
acceso, debe ser propiedad del mismo usuario que el contenedor versionado: las ACL nose tienen en cuenta. Esos contenedores no pueden versionarse mediante el mecanismo decontrol de versiones de objetos de S3. El valor por defecto es false (falso).
AJUSTES DE REGISTRO
rgw_log_nonexistent_bucket
Permite que Object Gateway registre una petición para un depósito inexistente. El valorpor defecto es false (falso).
rgw_log_object_name
El formato de registro de un nombre de objeto. Consulte la página man man 1 date paraobtener más información sobre los especicadores de formato. El valor por defecto es %Y-%m-%d-%H-%i-%n .
rgw_log_object_name_utc
Indica si un nombre de objeto registrado incluye una hora UTC. Si se establece en false(valor por defecto), utiliza la hora local.
rgw_usage_max_shards
El número máximo de fragmentos para el registro de uso. El valor por defecto es 32.
rgw_usage_max_user_shards
El número máximo de fragmentos utilizados para el registro de uso de un solo usuario.El valor por defecto es 1.
rgw_enable_ops_log
Habilita el registro de cada operación de Object Gateway correcta. El valor por defectoes false (falso).
rgw_enable_usage_log
Habilita el registro de uso. El valor por defecto es false (falso).
rgw_ops_log_rados
Indica si el registro de operaciones debe escribirse en el back-end del clúster dealmacenamiento de Ceph. El valor por defecto es true (verdadero).
rgw_ops_log_socket_path
El zócalo de dominio Unix para escribir registros de operaciones.
rgw_ops_log_data_backlog
398 Valores generales SES 7
El tamaño máximo de datos de backlog de datos para los registros de operaciones escritosen un zócalo de dominio Unix. El valor por defecto es 5 << 20.
rgw_usage_log_flush_threshold
El número de entradas combinadas sucias en el registro de uso antes de vaciarlas de formasincrónica. El valor por defecto es 1024.
rgw_usage_log_tick_interval
Vacía los datos de registro de uso pendientes cada "n" segundos. El valor por defecto es 30.
rgw_log_http_headers
Lista delimitada por comas de encabezados HTTP que se deben incluir en las entradas deregistro. Los nombres de encabezado no distinguen mayúsculas de minúsculas y usan elnombre de encabezado completo con palabras separadas por guiones bajos. Por ejemplo,"http_x_forwarded_for", "http_x_special_k".
rgw_intent_log_object_name
El formato de registro para el nombre del objeto de registro de intent. Consulte la páginaman man 1 date para obtener más información sobre los especicadores de formato. Elvalor por defecto es "%Y-%m-%d-%i-%n".
rgw_intent_log_object_name_utc
Indica si el nombre del objeto de registro de intent incluye una hora UTC. Si se estableceen false (valor por defecto), utiliza la hora local.
CONFIGURACIÓN DE KEYSTONE
rgw_keystone_url
La URL del servidor de Keystone.
rgw_keystone_api_version
La versión (2 o 3) de la API de identidad de OpenStack que se debe utilizar para lacomunicación con el servidor de Keystone. El valor por defecto es 2.
rgw_keystone_admin_domain
El nombre del dominio de OpenStack con privilegios de administrador al utilizar la versión3 de la API de identidad de OpenStack.
rgw_keystone_admin_project
El nombre del proyecto de OpenStack con privilegios de administrador al utilizar la versión3 de la API de identidad de OpenStack. Si no se dene, se usará en su lugar el valor dergw keystone admin tenant .
399 Valores generales SES 7
rgw_keystone_admin_token
El testigo de administrador de Keystone (secreto compartido). En Object Gateway, laautenticación con el testigo de administrador tiene prioridad sobre la autenticación conlas credenciales de administrador (opciones rgw keystone admin user , rgw keystoneadmin password , rgw keystone admin tenant , rgw keystone admin project yrgw keystone admin domain ). Se considera que la función de testigo de administradorestá obsoleta.
rgw_keystone_admin_tenant
El nombre del inquilino de OpenStack con privilegios de administrador (inquilino deservicio) al utilizar la versión 2 de la API de identidad de OpenStack.
rgw_keystone_admin_user
El nombre del usuario de OpenStack con privilegios de administrador para la autenticaciónde Keystone (usuario de servicio) al utilizar la versión 2 de la API de identidad deOpenStack.
rgw_keystone_admin_password
La contraseña del usuario administrador de OpenStack al utilizar la versión 2 de la APIde identidad de OpenStack.
rgw_keystone_accepted_roles
Las funciones necesarias para atender las peticiones. Por defecto es "Member, admin".
rgw_keystone_token_cache_size
El número máximo de entradas en cada caché del testigo de Keystone. El valor por defectoes 10000.
rgw_keystone_revocation_interval
El número de segundos entre comprobaciones de revocación del testigo. El valor pordefecto es 15*60.
rgw_keystone_verify_ssl
Verica los certicados SSL mientras se realizan peticiones de testigo a Keystone. El valorpor defecto es true (verdadero).
28.5.1.1 Notas adicionales
rgw_dns_name
400 Valores generales SES 7
Permite a los clientes utilizar depósitos de estilo vhost .El acceso al estilo vhost hace referencia al uso bucketname . s3-endpoint / object-path . Esto es en comparación con el acceso de estilo path : s3-
endpoint / bucket / objectSi se dene rgw dns name , verique que el cliente de S3 está congurado para dirigir laspeticiones al puesto nal especicado por rgw dns name .
28.5.2 Configuración de procesadores frontales HTTP
28.5.2.1 Beast
port, ssl_port
Los números de puerto de escucha IPv4 e IPv6. Puede especicar varios números de puerto:
port=80 port=8000 ssl_port=8080
El valor por defecto es 80.
endpoint, ssl_endpoint
Las direcciones de escucha con el formato "dirección[:puerto]", donde "dirección" es unacadena de dirección IPv4 en formato decimal con puntos o una dirección IPv6 en notaciónhexadecimal entre corchetes. Si se especica un puesto nal IPv6, solo se escucharíandirecciones IPv6. El número de puerto opcional es por defecto el 80 para endpoint y el443 para ssl_endpoint . Puede especicar varias direcciones:
endpoint=[::1] endpoint=192.168.0.100:8000 ssl_endpoint=192.168.0.100:8080
ssl_private_key
Vía opcional al archivo de clave privada utilizado para los puestos nales habilitados paraSSL. Si no se especica, se usa el archivo ssl_certificate como clave privada.
tcp_nodelay
Si se especica, la opción de zócalo inhabilitará el algoritmo de Nagle en la conexión.Signica que los paquetes se enviarán tan pronto como sea posible, en lugar de esperar aque se complete el búfer o a que se agote el tiempo límite."1" inhabilita el algoritmo de Nagle para todos los zócalos."0" mantiene habilitado el algoritmo de Nagle (opción por defecto).
401 Configuración de procesadores frontales HTTP SES 7
EJEMPLO 28.1: EJEMPLO DE CONFIGURACIÓN DE BEAST
cephuser@adm > ceph config set rgw.myrealm.myzone.ses-min1.kwwazo \ rgw_frontends beast port=8000 ssl_port=443 \ ssl_certificate=/etc/ssl/ssl.crt \ error_log_file=/var/log/radosgw/beast.error.log
28.5.2.2 Civetweb
port
El número del puerto de escucha. En el caso de los puertos habilitados para SSL, añada unsujo "s" (por ejemplo, "443s"). Para vincular una dirección IPv4 o IPv6 especíca, utiliceel formato "dirección:puerto". Puede especicar varios puestos nales uniéndolos con "+"o proporcionando varias opciones:
port=127.0.0.1:8000+443sport=8000 port=443s
El valor por defecto es 7480.
num_threads
El número de hilos generados por Civetweb para controlar las conexiones HTTP entrantes.Esto limita de manera ecaz el número de conexiones simultáneas que el front-end puedeatender.El valor por defecto es el valor especicado por la opción rgw_thread_pool_size .
request_timeout_ms
El tiempo en milisegundos que Civetweb esperará más datos entrantes antes de darse porvencido.El valor por defecto es 30000 milisegundos.
access_log_file
Vía al archivo de registro de accesos. Puede especicar una vía completa o una relativaal directorio de trabajo actual. Si no se especica (opción por defecto), los accesos no seregistran.
error_log_file
Vía al archivo de registro de errores. Puede especicar una vía completa o una relativaal directorio de trabajo actual. Si no se especica (opción por defecto), los errores no seregistran.
402 Configuración de procesadores frontales HTTP SES 7
EJEMPLO 28.2: EJEMPLO DE CONFIGURACIÓN DE CIVETWEB EN /etc/ceph/ceph.conf
cephuser@adm > ceph config set rgw.myrealm.myzone.ses-min2.ingabw \ rgw_frontends civetweb port=8000+443s request_timeout_ms=30000 \ error_log_file=/var/log/radosgw/civetweb.error.log
28.5.2.3 Opciones comunes
ssl_certificate
Vía al archivo de certicado SSL utilizado para los puestos nales habilitados para SSL.
prefix
Cadena de prejo que se inserta en el URI de todas las peticiones. Por ejemplo, unprocesador frontal solo de Swift podría proporcionar el prejo de URI /swift .
403 Configuración de procesadores frontales HTTP SES 7
29 Módulos de Ceph Manager
La arquitectura de Ceph Manager (consulte Libro “Guía de distribución”, Capítulo 1 “SES y Ceph”,
Sección 1.2.3 “Nodos y daemons de Ceph” para obtener una breve introducción) permite ampliarsu funcionalidad mediante módulos, como la "consola" (consulte la Parte I, “Ceph Dashboard”),"prometheus" (consulte el Capítulo 16, Supervisión y alertas), o el "equilibrador".
Para mostrar todos los módulos disponibles, ejecute:
cephuser@adm > ceph mgr module ls{ "enabled_modules": [ "restful", "status" ], "disabled_modules": [ "dashboard" ]}
Para habilitar o inhabilitar un módulo especíco, ejecute:
cephuser@adm > ceph mgr module enable MODULE-NAME
Por ejemplo:
cephuser@adm > ceph mgr module disable dashboard
Para mostrar los servicios que proporcionan los módulos habilitados, ejecute:
cephuser@adm > ceph mgr services{ "dashboard": "http://myserver.com:7789/", "restful": "https://myserver.com:8789/"}
29.1 EquilibradorEl módulo del equilibrador optimiza la distribución del grupo de colocación (PG) entre los OSDpara conseguir una distribución más equilibrada. Aunque el módulo se activa por defecto, estáinactivo. Admite los dos modos siguientes: crush-compat y upmap .
404 Equilibrador SES 7
Sugerencia: estado y configuración actuales del equilibradorPara ver el estado actual del equilibrador y los datos de conguración, ejecute:
cephuser@adm > ceph balancer status
29.1.1 Modo "crush-compat"
En el modo "crush-compat", el equilibrador ajusta los conjuntos de reequilibrio de peso de losOSD para lograr una mejor distribución de los datos. Mueve los grupos de colocación por losOSD, lo que causa que el clúster tenga temporalmente el estado HEALTH_WARN debido a losgrupos de colocación descolocados.
Sugerencia: activación del modoAunque "crush-compat" es el modo por defecto, se recomienda activarlo explícitamente:
cephuser@adm > ceph balancer mode crush-compat
29.1.2 Planificación y ejecución del equilibrado de datos
Mediante el módulo de equilibrador, puede crear un plan para equilibrar los datos. Acontinuación, puede ejecutar el plan manualmente o dejar que los grupos de colocación seequilibren continuamente de forma automática.
La decisión de ejecutar el equilibrador en modo manual o automático depende de varios factores,como el desequilibrio actual de los datos, el tamaño del clúster, el número de grupos decolocación o la actividad de E/S. Se recomienda crear un plan inicial y ejecutarlo en un momentode baja carga de E/S en el clúster. El motivo es que, probablemente, el desequilibrio inicial seráconsiderable y es una buena práctica para reducir el impacto en los clientes. Después de unaejecución manual inicial, considere la posibilidad de activar el modo automático y de supervisarel tráco de reequilibrio bajo una carga de E/S normal. Deben sopesarse las mejoras en ladistribución del grupo de colocación frente al tráco de reequilibrio causado por el equilibrador.
405 Modo "crush-compat" SES 7
Sugerencia: fracción móvil de grupos de colocación (PG)Durante el proceso de equilibrio, el módulo de equilibrador regula los movimientos delos grupos de colocación para que solo se mueva una fracción congurable de ellos. Elvalor por defecto es el 5 %, y se puede ajustar, por ejemplo al 9 %, ejecutando el comandosiguiente:
cephuser@adm > ceph config set mgr target_max_misplaced_ratio .09
Para crear y ejecutar un plan de equilibrio, siga estos pasos:
1. Compruebe la puntuación actual del clúster:
cephuser@adm > ceph balancer eval
2. Cree un plan. Por ejemplo, "great_plan":
cephuser@adm > ceph balancer optimize great_plan
3. Vea qué cambios implicará el plan "great_plan":
cephuser@adm > ceph balancer show great_plan
4. Compruebe la puntuación potencial del clúster si decide aplicar el plan "great_plan":
cephuser@adm > ceph balancer eval great_plan
5. Ejecute el plan "great_plan" una sola vez:
cephuser@adm > ceph balancer execute great_plan
6. Observe el equilibrio del clúster con el comando ceph -s . Si el resultado es satisfactorio,active el equilibrio automático:
cephuser@adm > ceph balancer on
Si más adelante decide desactivar el equilibrio automático, ejecute:
cephuser@adm > ceph balancer off
406 Planificación y ejecución del equilibrado de datos SES 7
Sugerencia: equilibrio automático sin plan inicialEs posible activar el equilibrio automático sin ejecutar un plan inicial. En tal caso, elreequilibrio de los grupos de colocación puede tardar bastante tiempo.
29.2 Habilitación del módulo de telemetría
El complemento de telemetría envía datos anónimos del proyecto Ceph sobre el clúster en elque se ejecuta el complemento.
Este componente (que hay que aceptar explícitamente) incluye contadores y estadísticas sobrecómo se ha distribuido el clúster, la versión de Ceph, la distribución de los hosts y otrosparámetros que ayudan al proyecto a comprender mejor la forma en que se usa Ceph. Nocontiene datos condenciales como nombres de repositorios, nombres de objetos, contenido deobjetos ni nombres de host.
El propósito del módulo de telemetría es proporcionar comentarios automatizado para quelos desarrolladores puedan cuanticar las tasas de adopción y el seguimiento o detectar loselementos que deben explicarse o validarse mejor durante la conguración para evitar resultadosno deseados.
NotaEl módulo de telemetría requiere que los nodos de Ceph Manager tengan la capacidad deenviar datos a través de HTTPS a los servidores de fases anteriores. Asegúrese de que sucortafuegos corporativos permita esta acción.
1. Para habilitar el módulo de telemetría:
cephuser@adm > ceph mgr module enable telemetry
NotaEste comando solo permite ver los datos localmente. No comparte datos con lacomunidad de Ceph.
407 Habilitación del módulo de telemetría SES 7
2. Para permitir que el módulo de telemetría comience a compartir datos:
cephuser@adm > ceph telemetry on
3. Para inhabilitar el uso compartido de los datos de telemetría:
cephuser@adm > ceph telemetry off
4. Para generar un informe JSON que se pueda imprimir:
cephuser@adm > ceph telemetry show
5. Para añadir un contacto y una descripción al informe:
cephuser@adm > ceph config set mgr mgr/telemetry/contact John Doe [email protected]@adm > ceph config set mgr mgr/telemetry/description 'My first Ceph cluster'
6. El módulo compila y envía un informe nuevo cada 24 horas por defecto. Para ajustar esteintervalo:
cephuser@adm > ceph config set mgr mgr/telemetry/interval HOURS
408 Habilitación del módulo de telemetría SES 7
30 Autenticación con cephx
Para identicar a los clientes y protegerlos frente a ataques de tipo "man-in-the-middle", Cephproporciona su propio sistema de autenticación: cephx . En este contexto, los clientes sonusuarios humanos (por ejemplo, el usuario administrador) o servicios/daemons relacionadoscon Ceph (por ejemplo, los OSD, los monitores o las pasarelas Object Gateway).
NotaEl protocolo cephx no se hace cargo del cifrado de datos durante el transporte, comoSSL/TLS.
30.1 Arquitectura de autenticacióncephx utiliza claves de secreto compartido para la autenticación, lo que signica que tanto elcliente como monitores Ceph Monitor tienen una copia de la clave de secreto del cliente. Elprotocolo de autenticación permite a ambas partes probarse entre sí que disponen de una copiade la clave sin revelarla. Esto proporciona autenticación mutua, lo que signica que el clústerestá seguro de que el usuario posee la clave de secreto, y el usuario está seguro de que el clústertambién tiene una copia.
Una característica fundamental para la capacidad de ampliación de Ceph es que se evita unainterfaz centralizada en el almacén de objetos de Ceph. Esto signica que los clientes de Cephpueden interactuar directamente con los OSD. Para proteger los datos, Ceph proporciona supropio sistema de autenticación, cephx , que autentica a los clientes de Ceph.
Cada monitor puede autenticar a los clientes y distribuir claves, por lo que no hay un puntoúnico de error ni cuellos de botella cuando se utiliza cephx . El monitor devuelve una estructurade datos de autenticación que contiene una clave de sesión que se usará para obtener losservicios de Ceph. Esta clave de sesión está cifrada a su vez con la clave de secreto permanentedel cliente, de forma que solo el cliente puede pedir servicios de los monitores de Ceph. Elcliente utiliza entonces la clave de sesión para pedir los servicios que desea del monitor, y elmonitor proporciona al cliente un ticket que autenticará al cliente en los OSD donde se gestionanrealmente los datos. Los monitores de Ceph y los OSD comparten un secreto, por lo que el clientepuede utilizar el ticket proporcionado por el monitor con cualquier OSD o servidor de metadatosdel clúster. Los tickets de cephx caducan, por lo que un atacante no puede utilizar un ticketcaducado ni una clave de sesión que haya obtenido de forma fraudulenta.
409 Arquitectura de autenticación SES 7
Para utilizar cephx , un administrador debe congurar primero clientes o usuarios. En elsiguiente diagrama, el usuario client.admin invoca ceph auth get-o-create-key en lalínea de comandos para generar un nombre de usuario y una clave de secreto. El subsistemaauth de Ceph genera el nombre de usuario y la clave, almacena una copia con los monitores ytransmite el secreto del usuario de nuevo al usuario client.admin . Esto signica que el clientey el monitor comparten una clave de secreto.
FIGURA 30.1: AUTENTICACIÓN BÁSICA CON cephx
Para autenticarse con el monitor, el cliente pasa el nombre de usuario al monitor. El monitorgenera una clave de sesión, la cifra con la clave de secreto asociada con el nombre de usuarioy transmite el ticket cifrado de vuelta al cliente. El cliente descifra los datos con la clave desecreto compartida para recuperar la clave de sesión. La clave de sesión identica al usuario parala sesión actual. A continuación, el cliente pide un ticket relacionado con el usuario, que estármado por la clave de sesión. El monitor genera un ticket, lo cifra con la clave de secreto delusuario y lo transmite al cliente. El cliente descifra el ticket y lo utiliza para rmar las peticionesa los OSD y los servidores de metadatos en todo el clúster.
410 Arquitectura de autenticación SES 7
FIGURA 30.2: AUTENTICACIÓN CON cephx
El protocolo cephx autentica continuamente las comunicaciones entre el equipo del cliente ylos servidores de Ceph. Cada mensaje que se envía entre un cliente y un servidor después dela autenticación inicial se rma con un ticket que los monitores, los OSD y los servidores demetadatos pueden vericar con su secreto compartido.
411 Arquitectura de autenticación SES 7
FIGURA 30.3: AUTENTICACIÓN CON cephx: SERVIDOR DE METADATOS Y OSD
ImportanteLa protección que ofrece esta autenticación se produce entre el cliente de Ceph y los hostsdel clúster de Ceph. La autenticación no se extiende más allá del cliente de Ceph. Si elusuario accede al cliente de Ceph desde un host remoto, la autenticación de Ceph no seaplica a la conexión entre el host del usuario y el host del cliente.
30.2 Áreas clave de gestiónEn esta sección se describen los usuarios del cliente de Ceph, así como su autenticación yautorización con el clúster de almacenamiento de Ceph. Los usuarios son personas o actores delsistema, como aplicaciones, que utilizan los clientes de Ceph para interactuar con los daemonsdel clúster de almacenamiento de Ceph.
Cuando se ejecuta Ceph con la autenticación y la autorización habilitadas (lo están por defecto),debe especicar un nombre de usuario y un anillo de claves que contenga la clave de secretodel usuario especicado (por lo general, a través de la línea de comandos). Si no especicaun nombre de usuario, Ceph usará client.admin como nombre de usuario por defecto.
412 Áreas clave de gestión SES 7
Si no especica un anillo de claves, Ceph buscará un anillo de claves mediante el valorcorrespondiente del archivo de conguración de Ceph. Por ejemplo, si ejecuta el comando cephhealth sin especicar un nombre de usuario o un anillo de claves, Ceph interpreta el comandoasí:
cephuser@adm > ceph -n client.admin --keyring=/etc/ceph/ceph.client.admin.keyring health
Si lo preere, puede utilizar la variable de entorno CEPH_ARGS para evitar tener que introducirde nuevo el nombre de usuario y el secreto.
30.2.1 Información básica
Independientemente del tipo de cliente de Ceph (por ejemplo, un dispositivo de bloques,almacenamiento de objetos, sistema de archivos o API nativa), Ceph almacena todos los datoscomo objetos en repositorios. Los usuarios de Ceph necesitan tener acceso a los repositoriosa n de poder leer y escribir los datos. Además, los usuarios de Ceph deben tener permisosde ejecución para usar los comandos de administración de Ceph. Los siguientes conceptos leayudarán a comprender mejor la gestión de usuarios de Ceph.
30.2.1.1 Usuario
Un usuario es una persona o un actor del sistema, como una aplicación. Crear usuarios permitecontrolar quién (o qué) puede acceder a su clúster de almacenamiento de Ceph, sus repositoriosy los datos de los repositorios.
Ceph usa tipos de usuarios. Para la gestión de los usuarios, el tipo siempre será client . Cephidentica a los usuarios con un formato delimitado por punto (.), formado por el tipo de usuarioy el ID de usuario. Por ejemplo, TYPE.ID , client.admin o client.user1 . Este formato seusa porque los monitores de Ceph, los OSD y los servidores de metadatos también utilizan elprotocolo cephx, pero no son clientes. Distinguir el tipo de usuario ayuda a diferenciar entrelos usuarios cliente y otros usuarios, además de optimizar el control de acceso, la supervisióndel usuario y el seguimiento.
A veces, el tipo de usuario de Ceph puede parecer confuso, ya que la línea de comandos de Cephpermite especicar un usuario con o sin el tipo, dependiendo del uso que se haga de la líneade comandos. Si especica ‑‑user o ‑‑id , puede omitir el tipo. Por lo tanto, client.user1
413 Información básica SES 7
se puede introducir simplemente como user1 . Si especica ‑‑name o -no , debe especicar eltipo y el nombre, como client.user1 . Se recomienda usar el tipo y el nombre como prácticarecomendada siempre que sea posible.
NotaUn usuario de clúster de almacenamiento de Ceph no es lo mismo que un usuario dealmacenamiento de objetos de Ceph ni un usuario de sistema de archivos de Ceph.Ceph Object Gateway utiliza un usuario de clúster de almacenamiento de Ceph parala comunicación entre el daemon de pasarela y el clúster de almacenamiento, pero lapasarela tiene sus propias funciones de gestión de usuarios para los usuarios nales. Elsistema de archivos de Ceph utiliza la semántica de POSIX. El espacio de usuarios asociadoa ese sistema no es igual que un usuario de clúster de almacenamiento de Ceph.
30.2.1.2 Autorización y permisos
Ceph usa el término permisos (caps, o "capabilities" en inglés) para describir la autorización deun usuario autenticado para que pueda trabajar con los monitores, los OSD y los servidores demetadatos. Los permisos también pueden restringir el acceso a los datos de un repositorio o aun espacio de nombres de repositorio. Un usuario administrativo de Ceph dene los permisosdel usuario cuando lo crea o lo actualiza.
La sintaxis de los permisos sigue este formato:
daemon-type 'allow capability' [...]
A continuación encontrará una lista de permisos para cada tipo de servicio:
Permisos de monitor
Incluye r , w , x y allow profile permiso .
mon 'allow rwx'mon 'allow profile osd'
Permisos de OSD
Incluye r , w , x , class-read , class-write y profile osd . Además, los permisos deOSD también permiten congurar el repositorio y el espacio de nombres.
osd 'allow capability' [pool=poolname] [namespace=namespace-name]
Permiso de servidor de metadatos
414 Información básica SES 7
Solo es allow o se deja vacío.
mds 'allow'
Las siguientes entradas describen cada permiso:
allow
Precede a la conguración de acceso para un daemon. Implica rw solo para el servidorde metadatos.
r
Proporciona al usuario acceso de lectura. Es necesario para que los monitores puedanrecuperar el mapa de CRUSH.
w
Proporciona al usuario acceso de escritura a los objetos.
x
Proporciona al usuario el permiso para llamar a métodos de clase (tanto de lectura comode escritura) y para llevar a cabo operaciones auth en los monitores.
class-read
Proporciona al usuario el permiso para llamar a métodos de lectura de clase. Subconjuntode x .
class-write
Proporciona al usuario el permiso para llamar a métodos de escritura de clase. Subconjuntode x .
*
Proporciona al usuario permisos de lectura, escritura y ejecución para un daemon orepositorio concreto, así como la capacidad de ejecutar comandos de administración.
profile osd
Proporciona a un usuario permiso para conectarse como un OSD a otros OSD o monitores.Se otorga en los OSD para permitirles gestionar el tráco de subejecución de réplica y laelaboración de informes de estado.
profile mds
Proporciona a un usuario permiso para conectarse como un servidor de metadatos a otrosservidores de metadatos o monitores.
profile bootstrap-osd
415 Información básica SES 7
Proporciona a un usuario permisos para cargar un OSD. Se delega a las herramientas dedistribución para que tengan permisos para añadir claves cuando se carga un OSD.
profile bootstrap-mds
Proporciona a un usuario permisos para cargar un servidor de metadatos. Se delega a lasherramientas de distribución para que tengan permisos para añadir claves cuando se cargaun servidor de metadatos.
30.2.1.3 Repositorios
Un repositorio es una partición lógica donde los usuarios almacenan los datos. En distribucionesde Ceph, es común crear un repositorio como una partición lógica para tipos similares de datos.Por ejemplo, al distribuir Ceph como procesador nal para OpenStack, una distribución típicatendría repositorios para los volúmenes, las imágenes, las copias de seguridad, las máquinasvirtuales y los usuarios como client.glance o client.cinder .
30.2.2 Gestión de usuarios
La funcionalidad de gestión de usuarios proporciona a los administradores de clústeres de Cephla capacidad de crear, actualizar y suprimir usuarios directamente en el clúster de Ceph.
Al crear o suprimir usuarios en el clúster de Ceph, puede ser necesario distribuir claves a losclientes para que se puedan añadir a anillos de claves. Para obtener más información, consulte:Sección 30.2.3, “Gestión de anillos de claves”.
30.2.2.1 Listas de usuarios
Para obtener una lista de los usuarios del clúster, ejecute lo siguiente:
cephuser@adm > ceph auth list
Ceph mostrará a todos los usuarios del clúster. Por ejemplo, en un clúster de dos nodos, cephauth list da como resultado algo parecido a esto:
installed auth entries:
osd.0 key: AQCvCbtToC6MDhAATtuT70Sl+DymPCfDSsyV4w== caps: [mon] allow profile osd caps: [osd] allow *
416 Gestión de usuarios SES 7
osd.1 key: AQC4CbtTCFJBChAAVq5spj0ff4eHZICxIOVZeA== caps: [mon] allow profile osd caps: [osd] allow *client.admin key: AQBHCbtT6APDHhAA5W00cBchwkQjh3dkKsyPjw== caps: [mds] allow caps: [mon] allow * caps: [osd] allow *client.bootstrap-mds key: AQBICbtTOK9uGBAAdbe5zcIGHZL3T/u2g6EBww== caps: [mon] allow profile bootstrap-mdsclient.bootstrap-osd key: AQBHCbtT4GxqORAADE5u7RkpCN/oo4e5W0uBtw== caps: [mon] allow profile bootstrap-osd
Nota: notación TYPE.IDTenga en cuenta que se aplica la notación TYPE.ID para los usuarios, de forma queosd.0 especica un usuario de tipo osd cuyo ID es 0 . client.admin es un usuariode tipo client cuyo ID es admin . Tenga en cuenta también que cada entrada tiene unaentrada key: valor y una o más entradas caps: .
Puede utilizar la opción -o nombre de archivo con ceph auth list para guardarel resultado en un archivo.
30.2.2.2 Obtención de información sobre los usuarios
Para recuperar información de un usuario, una clave y permisos concretos, ejecute lo siguiente:
cephuser@adm > ceph auth get TYPE.ID
Por ejemplo:
cephuser@adm > ceph auth get client.adminexported keyring for client.admin[client.admin] key = AQA19uZUqIwkHxAAFuUwvq0eJD4S173oFRxe0g== caps mds = "allow" caps mon = "allow *" caps osd = "allow *"
Los desarrolladores también pueden ejecutar lo siguiente:
cephuser@adm > ceph auth export TYPE.ID
417 Gestión de usuarios SES 7
El comando auth export es idéntico al comando auth get , pero también imprime el ID deautenticación interno.
30.2.2.3 Adición de usuarios
Al añadir un usuario, se crea un nombre de usuario ( TYPE.ID ), una clave de secreto y cualquierpermiso incluido en el comando que se utiliza para crear el usuario.
La clave del usuario permite a este autenticarse con el clúster de almacenamiento de Ceph. Lospermisos del usuario autorizan a este a leer, escribir o ejecutar en los monitores de Ceph (mon),los OSD de Ceph (osd) o los servidores de metadatos de Ceph (mds).
Hay varios comandos disponibles para añadir un usuario:
ceph auth add
Este comando es la manera canónica de añadir un usuario. Crea el usuario, genera unaclave y añade cualquier permiso especicado.
ceph auth get-or-create
Este comando suele ser la forma más cómoda de crear un usuario, ya que devuelve unformato de archivo de clave con el nombre de usuario (entre corchetes) y la clave. Si elusuario ya existe, este comando simplemente devuelve el nombre de usuario y la clavecon formato de archivo de clave. Puede utilizar la opción -o nombre de archivo paraguardar el resultado en un archivo.
ceph auth get-or-create-key
Este comando es un método sencillo de crear un usuario y devolver (solo) la clave delusuario. Resulta útil para clientes que solo necesitan la clave (por ejemplo, libvirt ). Si elusuario ya existe, este comando solo devuelve la clave. Puede utilizar la opción -o nombrede archivo para guardar el resultado en un archivo.
Cuando se crean usuarios de cliente, puede crear un usuario sin permisos. Un usuario sinpermisos puede autenticarse, pero nada más. Un cliente de este tipo no puede recuperar el mapadel clúster del monitor. Sin embargo, puede crear un usuario sin permisos si desea añadir lospermisos más tarde con el comando ceph auth caps .
Un usuario típico tiene al menos el permiso de lectura en el monitor de Ceph y de lectura yescritura en los OSD de Ceph. Además, los permisos de OSD de un usuario a menudo estánrestringidos al acceso a un repositorio concreto.
cephuser@adm > ceph auth add client.john mon 'allow r' osd \
418 Gestión de usuarios SES 7
'allow rw pool=liverpool'cephuser@adm > ceph auth get-or-create client.paul mon 'allow r' osd \ 'allow rw pool=liverpool'cephuser@adm > ceph auth get-or-create client.george mon 'allow r' osd \ 'allow rw pool=liverpool' -o george.keyringcephuser@adm > ceph auth get-or-create-key client.ringo mon 'allow r' osd \ 'allow rw pool=liverpool' -o ringo.key
ImportanteSi proporciona a un usuario permisos para los OSD, pero no restringe el acceso arepositorios concretos, el usuario tendrá acceso a todos los repositorios del clúster.
30.2.2.4 Modificación de los permisos de usuario
El comando ceph auth caps permite especicar un usuario y cambiar sus permisos. Al denirnuevos permisos, se sobrescribirán los existentes. Para ver los permisos actuales, ejecute cephauth get USERTYPE.USERID . Para añadir permisos, también debe especicar los permisosexistentes con el formato siguiente:
cephuser@adm > ceph auth caps USERTYPE.USERID daemon 'allow [r|w|x|*|...] \ [pool=pool-name] [namespace=namespace-name]' [daemon 'allow [r|w|x|*|...] \ [pool=pool-name] [namespace=namespace-name]']
Por ejemplo:
cephuser@adm > ceph auth get client.johncephuser@adm > ceph auth caps client.john mon 'allow r' osd 'allow rw pool=prague'cephuser@adm > ceph auth caps client.paul mon 'allow rw' osd 'allow r pool=prague'cephuser@adm > ceph auth caps client.brian-manager mon 'allow *' osd 'allow *'
Para eliminar un permiso, puede restablecerlo. Si desea que el usuario no tenga acceso a undaemon concreto que se ha denido previamente, especique una cadena vacía:
cephuser@adm > ceph auth caps client.ringo mon ' ' osd ' '
30.2.2.5 Supresión de usuarios
Para suprimir un usuario, utilice ceph auth del :
cephuser@adm > ceph auth del TYPE.ID
419 Gestión de usuarios SES 7
donde TYPE es client , osd , mon o mds , e ID es el nombre del usuario o el ID del daemon.
Si ha creado usuarios con permisos estrictamente para un repositorio que ya no existe, plantéesetambién la posibilidad de suprimir dichos usuarios.
30.2.2.6 Impresión de la clave de un usuario
Para imprimir la clave de autenticación de un usuario con una salida estándar, ejecute losiguiente:
cephuser@adm > ceph auth print-key TYPE.ID
donde TYPE es client , osd , mon o mds , e ID es el nombre del usuario o el ID del daemon.
Imprimir la clave de un usuario resulta útil si necesita completar el software de cliente con laclave de un usuario (por ejemplo, libvirt ), tal y como se muestra en el siguiente ejemplo:
root # mount -t ceph host:/ mount_point \-o name=client.user,secret=`ceph auth print-key client.user`
30.2.2.7 Importación de usuarios
Para importar uno o varios usuarios, utilice ceph auth import y especique un anillo de claves:
cephuser@adm > ceph auth import -i /etc/ceph/ceph.keyring
NotaEl clúster de almacenamiento de Ceph añadirá los nuevos usuarios, sus claves y suspermisos, además de actualizar los usuarios existentes, sus claves y sus permisos.
30.2.3 Gestión de anillos de claves
Si accede a Ceph a través de un cliente de Ceph, el cliente buscará un anillo de claves local. Cephincluye cuatro nombres de anillos de claves por defecto, por lo que no es necesario denirlos enel archivo de conguración de Ceph, a menos que desee sustituir esos valores por defecto:
/etc/ceph/cluster.name.keyring
420 Gestión de anillos de claves SES 7
/etc/ceph/cluster.keyring/etc/ceph/keyring/etc/ceph/keyring.bin
La metavariable cluster es el nombre de su clúster de Ceph denido en el archivo deconguración de Ceph. ceph.conf signica que el nombre del clúster es ceph , como enceph.keyring . La metavariable name es el tipo de usuario y el ID de usuario; por ejemplo,client.admin , como en ceph.client.admin.keyring .
Después de crear un usuario (por ejemplo, client.ringo ), debe obtener la clave y añadirlaa un anillo de claves en un cliente de Ceph para que el usuario pueda acceder el clúster dealmacenamiento de Ceph.
En la Sección 30.2, “Áreas clave de gestión” se detalla cómo mostrar una lista de usuario y obtener,añadir, modicar y suprimir usuarios directamente en el clúster de almacenamiento de Ceph. Sinembargo, Ceph también proporciona la utilidad ceph-authtool , que permite gestionar anillosde claves desde un cliente de Ceph.
30.2.3.1 Creación de un anillo de claves
Cuando se utilizan los procedimientos de la Sección 30.2, “Áreas clave de gestión” para crearusuarios, debe proporcionar las claves de usuario a los clientes de Ceph para que puedanrecuperar la clave para el usuario especicado y autenticarse con el clúster de almacenamientode Ceph. Los clientes de Ceph acceden a los anillos de claves para buscar un nombre de usuarioy recuperar la clave del usuario:
cephuser@adm > ceph-authtool --create-keyring /path/to/keyring
Cuando se crea un anillo de claves con varios usuarios, es recomendable utilizar el nombredel clúster (por ejemplo cluster .keyring) para el nombre de archivo del anillo de claves yguardarlo en el directorio /etc/ceph . De esta forma, la conguración por defecto del anillode claves tomará el nombre de archivo sin que sea necesario especicarlo en la copia local delarchivo de conguración de Ceph. Por ejemplo, para crear ceph.keyring , ejecute lo siguiente:
cephuser@adm > ceph-authtool -C /etc/ceph/ceph.keyring
Cuando se crea un anillo de claves con un solo usuario, se recomienda usar el nombre del clúster,el tipo de usuario y el nombre de usuario y guardarlo en el directorio /etc/ceph . Por ejemplo,ceph.client.admin.keyring para el usuario client.admin .
421 Gestión de anillos de claves SES 7
30.2.3.2 Adición de un usuario a un anillo de claves
Cuando se añade un usuario al clúster de almacenamiento de Ceph (consulte la Sección 30.2.2.3,
“Adición de usuarios”), puede recuperar el usuario, la clave y los permisos, y guardar el usuarioen un anillo de claves.
Si solo desea utilizar un usuario por anillo de claves, el comando ceph auth get con la opción-o guardará el resultado en el formato de archivo del anillo de claves. Por ejemplo, para crearun anillo de claves para el usuario client.admin , ejecute lo siguiente:
cephuser@adm > ceph auth get client.admin -o /etc/ceph/ceph.client.admin.keyring
Si desea importar usuarios en un anillo de claves, puede utilizar ceph-authtool para especicarel anillo de claves de destino y el anillo de claves de origen:
cephuser@adm > ceph-authtool /etc/ceph/ceph.keyring \ --import-keyring /etc/ceph/ceph.client.admin.keyring
ImportanteSi el anillo de claves está en peligro, suprima la clave del directorio /etc/ceph y vuelvaa crear una clave nueva siguiendo las mismas instrucciones de la Sección 30.2.3.1, “Creación
de un anillo de claves”.
30.2.3.3 Creación de un usuario
Ceph proporciona el comando ceph auth add para crear un usuario directamente en elclúster de almacenamiento de Ceph. Sin embargo, también puede crear un usuario, las clavesy los permisos directamente en un anillo de claves del cliente de Ceph. A continuación, puedeimportar el usuario en el clúster de almacenamiento de Ceph:
cephuser@adm > ceph-authtool -n client.ringo --cap osd 'allow rwx' \ --cap mon 'allow rwx' /etc/ceph/ceph.keyring
También puede crear un anillo de claves y añadirle simultáneamente un usuario nuevo:
cephuser@adm > ceph-authtool -C /etc/ceph/ceph.keyring -n client.ringo \ --cap osd 'allow rwx' --cap mon 'allow rwx' --gen-key
422 Gestión de anillos de claves SES 7
En las situaciones anteriores, el nuevo usuario client.ringo está solo en el anillo de claves.Para añadir el nuevo usuario al clúster de almacenamiento de Ceph, sigue siendo necesarioañadir el nuevo usuario al clúster:
cephuser@adm > ceph auth add client.ringo -i /etc/ceph/ceph.keyring
30.2.3.4 Modificación de usuarios
Para modicar los permisos de un registro de usuario en un anillo de claves, especique el anillode claves y el usuario seguidos de los permisos:
cephuser@adm > ceph-authtool /etc/ceph/ceph.keyring -n client.ringo \ --cap osd 'allow rwx' --cap mon 'allow rwx'
Para actualizar el usuario modicado en el entorno de clúster de Ceph, debe importar loscambios desde el anillo de claves en la entrada de usuario del clúster de Ceph:
cephuser@adm > ceph auth import -i /etc/ceph/ceph.keyring
Consulte la Sección 30.2.2.7, “Importación de usuarios” para obtener información sobre cómoactualizar el clúster de almacenamiento de Ceph desde un anillo de claves.
30.2.4 Uso de la línea de comandos
El comando ceph admite las siguientes opciones relacionadas con el nombre de usuario y lamanipulación del secreto:
‑‑id o ‑‑user
Ceph identica a los usuarios con un tipo y un ID ( TYPE . ID ; por ejemplo, client.admino client.user1 ). Las opciones id , name y -n permiten especicar la parte del ID delnombre de usuario (por ejemplo, admin o user1 ). Puede especicar el usuario con laopción ‑‑id y omitir el tipo. Por ejemplo, para especicar el usuario client.foo, escriba losiguiente:
cephuser@adm > ceph --id foo --keyring /path/to/keyring healthcephuser@adm > ceph --user foo --keyring /path/to/keyring health
‑‑name o ‑n
423 Uso de la línea de comandos SES 7
Ceph identica a los usuarios con un tipo y un ID ( TYPE . ID ; por ejemplo, client.admin oclient.user1 ). Las opciones ‑‑name y ‑n permiten especicar el nombre completo delusuario. Debe especicar el tipo de usuario (generalmente, client ) con el ID de usuario:
cephuser@adm > ceph --name client.foo --keyring /path/to/keyring healthcephuser@adm > ceph -n client.foo --keyring /path/to/keyring health
‑‑keyring
La vía al anillo de claves que contiene uno o más nombres de usuario y secretos. La opción‑‑secret ofrece las mismas funciones, pero no funciona con Object Gateway, que utiliza‑‑secret para otro n. Puede recuperar un anillo de claves con auth ceph get-or-create y almacenarlo localmente. Se trata del enfoque preferido, ya que permite cambiarde nombres de usuario sin tener que cambiar la vía del anillo de claves:
cephuser@adm > rbd map --id foo --keyring /path/to/keyring mypool/myimage
424 Uso de la línea de comandos SES 7
A Actualizaciones de mantenimiento de Cephbasadas en versiones secundarias superiores deOctopus
Varios paquetes clave de SUSE Enterprise Storage 7 se basan en las distintas versiones de Octopusde Ceph. Cuando el proyecto Ceph (https://github.com/ceph/ceph ) publica nuevas versionessecundarias de la serie Octopus, SUSE Enterprise Storage 7 se actualiza para garantizar queel producto se benecia de las últimas correcciones de solucionar errores y actualizacionesretroactivas de características de esas versiones.
Este capítulo contiene un resumen de los principales cambios incluidos en cada versiónsecundaria posterior que se ha incluido en el producto, o que se tiene previsto incluir.
Octopus 15.2.5
La versión 15.2.5 de Octopus aporta las siguientes correcciones y otros cambios:
CephFS: las directivas de partición de subárbol estático automáticas ahora se puedencongurar mediante los nuevos atributos extendidos de jación efímera aleatoria ydistribuida en los directorios. Para obtener más datos, consulte la documentación siguiente:https://docs.ceph.com/docs/master/cephfs/multimds/
Los monitores tienen ahora una opción de conguración mon_osd_warn_num_repaired ,que está denida en 10 por defecto. Si algún OSD ha reparado más errores de E/S en losdatos almacenados de los indicados por esta cifra, se genera una advertencia de estadoOSD_TOO_MANY_REPAIRS .
Ahora, si los indicadores no scrub o no deep-scrub se denen globalmente opor repositorio, la depuración programada del tipo inhabilitado se interrumpirán. Lasdepuraciones iniciadas por el usuario NO se interrumpen.
Se ha solucionado un problema por el que osdmaps no se optimizaba en un clúster enbuen estado.
425 Octopus 15.2.5 SES 7
Octopus 15.2.4
La versión 15.2.4 de Octopus aporta las siguientes correcciones y otros cambios:
CVE-2020-10753: rgw: se han saneado las nuevas líneas en el encabezado ExposeHeaderde s3 CORSConguration
Object Gateway: los subcomandos radosgw-admin relacionados con huérfanos ( radosgw-admin orphans find , radosgw-admin orphans finish y radosgw-admin orphanslist-jobs ) han quedado obsoletos. No se han mantenido de forma activa y, dado quealmacenan resultados intermedios en el clúster, podrían llegar a ocupar un clúster casi porcompleto. Se han sustituido por una herramienta, rgw-orphan-list , que actualmente seconsidera experimental.
RBD: el nombre del objeto de repositorio RBD que se utiliza para almacenarla programación de limpieza de la papelera de RBD ha cambiado derbd_trash_trash_purge_schedule a rbd_trash_purge_schedule . Los usuarios queya han comenzado a utilizar la función de programación de limpieza de papelera de RBDy tienen programas por repositorio o por espacio de nombres conguradas deben copiar elobjeto rbd_trash_trash_purge_schedule en rbd_trash_purge_schedule antes de laactualización y eliminar rbd_trash_purge_schedule mediante los comandos siguientesen cada repositorio RBD y espacio de nombres congurado anteriormente:
rados -p pool-name [-N namespace] cp rbd_trash_trash_purge_schedule rbd_trash_purge_schedulerados -p pool-name [-N namespace] rm rbd_trash_trash_purge_schedule
También puede utilizar cualquier otra forma conveniente de restaurar la programacióndespués de la actualización.
Octopus 15.2.3
La versión 15.2.3 de Octopus era una versión Hot Fix para solucionar un problema en elque se detectaban daños en WAL cuando se habilitaban bluefs_preextend_wal_filesy bluefs_bufferen_io al mismo tiempo. La corrección de 15.2.3 es solo unamedida temporal (que cambia el valor por defecto de bluefs_preextend_wal_files
426 Octopus 15.2.4 SES 7
a false ). La solución permanente será eliminar por completo la opciónbluefs_preextend_wal_files : lo más probable es que esta solución llegue en la versión15.2.6.
Octopus 15.2.2La versión 15.2.2 de Octopus solucionó una vulnerabilidad de seguridad:
CVE-2020-10736: se ha corregido una omisión de autorización en MON y MGR.
Octopus 15.2.1La versión 15.2.1 de Octopus solucionó un problema por el cual la actualización rápida deLuminous (SES5.5) a Nautilus (SES6) a Octopus (SES7) provocaba que los OSD se bloquearan.Además, se aplicaron parches a dos vulnerabilidades de seguridad presentes en la versión inicialde Octopus (15.2.0):
CVE-2020-1759: se ha corregido la reutilización de nonce en el modo seguro de msgr V2.
CVE-2020-1760: XSS corregido debido a la división de encabezado GetObject de RGW.
427 Octopus 15.2.2 SES 7
B Actualizaciones de la documentación
En este capítulo se describen los cambios de contenido de este documento que se aplican a laversión actual de SUSE Enterprise Storage.
El capítulo sobre Ceph Dashboard (Parte I, “Ceph Dashboard”) se ha subido un nivel en lajerarquía del libro para que los temas detallados se puedan buscar directamente en la tablade contenido.
La estructura del Libro “Guía de administración y operaciones” se ha actualizado para quecoincida con el rango actual de guías. Algunos capítulos se han trasladado a otras guías(jsc#SES-1397).
428 SES 7
Glosario
General
AlertmanagerUn binario que gestiona las alertas enviadas por el servidor Prometheus y notica al usuarional.
Almacenamiento de objetos de CephEl "producto", el servicio o las capacidades de almacenamiento de objetos, formado por unclúster de almacenamiento de Ceph y Ceph Object Gateway.
Árbol de enrutamientoUn término dado a cualquier diagrama que muestre las diversas rutas que un receptor puedeejecutar.
Ceph DashboardUna aplicación integrada de gestión y supervisión de Ceph basada en Web para administrarvarios aspectos y objetos del clúster. La consola se implementa como un módulo de CephManager.
Ceph ManagerCeph Manager, o MGR, es el software de gestión de Ceph, que recopila todo el estado detodo el clúster en un solo lugar.
Ceph MonitorCeph Monitor, o MON, es el software de supervisión de Ceph.
ceph-salt
Proporciona herramientas para distribuir clústeres de Ceph gestionados por cephadmmediante Salt.
cephadmcephadm distribuye y gestiona un clúster de Ceph conectándose a hosts desde el daemon delgestor a través de SSH para añadir, eliminar o actualizar contenedores de daemon de Ceph.
429 SES 7
CephFSEl sistema de archivos de Ceph.
CephXEl protocolo de autenticación de Ceph. Cephx funciona como Kerberos, pero no tiene unpunto único de fallo.
Cliente de CephColección de componentes de Ceph que pueden acceder a un clúster de almacenamientode Ceph. Entre ellos se incluyen Object Gateway, Ceph Block Device, CephFS y suscorrespondientes bibliotecas, módulos del kernel y clientes FUSE.
Clúster de almacenamiento de CephEl conjunto principal de software de almacenamiento donde se almacenan los datos delusuario' Dicho conjunto está formado por los monitores Ceph Monitor y los OSD.
Conjunto de reglasLas reglas para determinar la ubicación de los datos de un repositorio.
CRUSH, mapa de CRUSHCRUSH: Controlled Replication Under Scalable Hashing (réplica controlada bajo hashescalable) es un algoritmo que determina cómo se deben almacenar y recuperar los datoscalculando las ubicaciones de almacenamiento de los datos. CRUSH requiere un mapa delclúster para almacenar de forma pseudoaleatoria y recuperar los datos de los OSD con unadistribución uniforme de los datos por el clúster.
Daemon Ceph OSDEl daemon ceph-osd es el componente de Ceph responsable de almacenar objetos en unsistema de archivos local y de proporcionar acceso a ellos a través de la red.
DepósitoUn punto que añade otros nodos en una jerarquía de ubicaciones físicas.
Dispositivo de bloques RADOS (RBD)El componente de almacenamiento de bloques de Ceph. También conocido como dispositivode bloques de Ceph.
430 SES 7
DriveGroupsDriveGroups es una declaración de uno o varios diseños de OSD que se pueden asignar aunidades físicas. Un diseño de OSD dene cómo Ceph asigna físicamente el almacenamientode OSD en los medios que coinciden con criterios especicados.
GrafanaSolución de análisis y supervisión de bases de datos.
grupo de zona
Módulo de sincronización de archivosMódulo que permite crear una zona de Object Gateway para mantener el historial deversiones de objetos de S3.
Multizona
NodoCualquier equipo o servidor único de un clúster de Ceph.
Nodo de administraciónEl host desde el que se ejecutan los comandos relacionados con Ceph para administrar loshosts del clúster.
Nodo de OSDUn nodo de clúster donde se almacenan los datos; se gestiona la réplica de los datos, larecuperación, la reposición y el reequilibrio, y que proporciona detalles de supervisión a losmonitores Ceph Monitor mediante la comprobación de otros daemons Ceph OSD.
Object GatewayEl componente de pasarela S3/Swift para el almacén de objetos de Ceph. También conocidocomo pasarela RADOS (RGW).
OSDDispositivo de almacenamiento de objetos: unidad de almacenamiento física o lógica.
PGGrupo de colocación: una subdivisión de un repositorio que se utiliza para ajustar elrendimiento.
PrometheusKit de herramientas de supervisión y alerta de sistemas.
431 SES 7
RADOS (Reliable Autonomic Distributed Object Store, almacén de objetos distribuidoautomático fiable)
El conjunto principal de software de almacenamiento donde se almacenan los datos delusuario (MON+OSD).
Regla de CRUSHLa regla de colocación de datos de CRUSH que se aplica a uno o varios repositorios concretos.
RepositorioLas particiones lógicas para almacenar los objetos, como las imágenes de disco.
SambaSoftware de integración de Windows.
Samba GatewaySamba Gateway se une a Active Directory en el dominio de Windows para autenticar yautorizar a los usuarios.
Servidor de metadatosEl servidor de metadatos, o MDS, es el software de metadatos de Ceph.
Versión secundariaCualquier versión ad hoc que incluye solo correcciones de errores o de seguridad.
432 SES 7
