Saltar a contenidoSaltar a navegación de páginas: página anterior [tecla acceso p]/página siguiente [tecla acceso n]
ContenidoContenido
Guía de administración
  1. Acerca de esta guía
  2. I Gestión en clúster
    1. 1 Privilegios de usuario y comandos de símbolos del sistema
    2. 2 Administración de un clúster de Salt
    3. 3 Copia de seguridad de la configuración y los datos del clúster
  3. II Funcionamiento de un clúster
    1. 4 Introducción
    2. 5 Gestión de los servicios de Ceph
    3. 6 Determinación del estado del clúster
    4. 7 Supervisión y alertas
    5. 8 Autenticación con cephx
    6. 9 Gestión de datos almacenados
    7. 10 Módulos de Ceph Manager
    8. 11 Gestión de repositorios de almacenamiento
    9. 12 Dispositivo de bloques RADOS
    10. 13 Repositorios codificados de borrado
    11. 14 Niveles de caché
    12. 15 Mejora del rendimiento con el caché de LVM
    13. 16 Configuración del clúster de Ceph
  4. III Acceso a los datos del clúster
    1. 17 Ceph Object Gateway
    2. 18 Ceph iSCSI Gateway
    3. 19 Sistema de archivos con agrupación en clúster
    4. 20 Exportación de datos de Ceph a través de Samba
    5. 21 NFS Ganesha: exportación de datos de Ceph a través de NFS
  5. IV Gestión del clúster con herramientas de interfaz gráfica de usuario
    1. 22 Ceph Dashboard
  6. V Integración con herramientas de virtualización
    1. 23 Uso de libvirt con Ceph
    2. 24 Ceph como procesador final para la instancia de QEMU KVM
  7. VI Preguntas frecuentes, consejos y solución de problemas
    1. 25 Consejos y sugerencias
    2. 26 Preguntas más frecuentes
    3. 27 Solución de problemas
  8. A Ejemplo personalizado de la fase 1 de DeepSea
  9. B Alertas por defecto para SUSE Enterprise Storage 6
  10. C Actualizaciones de mantenimiento de Ceph basadas en versiones secundarias superiores de Nautilus
  11. Glosario
  12. D Actualizaciones de la documentación
Navegación
Se aplica a SUSE Enterprise Storage 6

14 Niveles de caché Edit source

Un nivel de caché es una capa de almacenamiento adicional implementada entre el cliente y el almacenamiento estándar. Está diseñado para agilizar el acceso a los repositorios almacenados en discos duros lentos y los repositorios codificados de borrado.

Por lo general, la existencia de niveles de caché implica la creación de un repositorio de dispositivos de almacenamiento relativamente rápidos (por ejemplo, unidades SSD), configurados para actuar como un nivel de caché, así como un repositorio de copia de seguridad con dispositivos más lentos y menos costosos, configurados como nivel de almacenamiento. El tamaño del repositorio de caché suele ser del 10-20 % del repositorio de almacenamiento.

14.1 Terminología de almacenamiento por niveles Edit source

Los niveles de caché reconocen dos tipos de repositorios: un repositorio de caché y un repositorio de almacenamiento.

Sugerencia
Sugerencia

Para obtener información general sobre los repositorios, consulte el Capítulo 11, Gestión de repositorios de almacenamiento.

repositorio de almacenamiento

Puede ser un repositorio estándar replicado que almacena varias copias de un objeto en el clúster de almacenamiento Ceph o un repositorio codificado de borrado (consulte el Capítulo 13, Repositorios codificados de borrado).

El repositorio de almacenamiento se conoce a veces como almacenamiento de "copia de seguridad" o "en frío".

repositorio de caché

Un repositorio estándar replicado, almacenado en un dispositivo de almacenamiento relativamente pequeño pero rápido, con su propio conjunto de reglas, en una asignación CRUSH.

El repositorio de caché también se conoce como almacenamiento "en caliente".

14.2 Puntos que se deben tener en cuenta Edit source

Los niveles de caché pueden degradar el rendimiento del clúster para cargas de trabajo específicas. A continuación, describiremos algunos de los aspectos que debe tener en cuenta:

  • Dependencia de la carga de trabajo: las posibles mejoras de rendimiento del caché dependen de la carga de trabajo. Dado que existe un coste asociado a introducir objetos en el caché o sacarlos de él, puede ser más eficaz cuando la mayoría de las peticiones afectan a un pequeño número de objetos. El repositorio de caché debe ser lo suficientemente grande como para capturar el espacio de trabajo, de modo que la carga de trabajo evite la hiperpaginación.

  • Dificultad para establecer una comparativa: la mayoría de las comparativas de rendimiento pueden mostrar un bajo rendimiento con niveles de caché. El motivo es que piden un conjunto extenso de objetos y el caché tarda mucho en "entrar en calor".

  • Probabilidad de bajo rendimiento: en las cargas de trabajo inadecuadas para los niveles de caché, el rendimiento suele ser más lento que el de un repositorio normal replicado sin niveles de caché.

  • Enumeración de objetos de librados: si la aplicación usa librados directamente y se basa en la enumeración de objetos, los niveles de caché podrían no funcionar del modo previsto. (Esto no es un problema para Object Gateway, RBD o CephFS).

14.3 Cuándo usar los niveles de caché Edit source

Plantéese usar los niveles de caché en los siguientes casos:

  • Los repositorios codificados de borrado se almacenan en FileStore y debe acceder a ellos mediante dispositivos de bloques RADOS (RBD). Si desea más información sobre RBD, consulte el Capítulo 12, Dispositivo de bloques RADOS.

  • Los repositorios codificados de borrado se almacenan en FileStore y debe acceder a ellos a través de iSCSI. Para obtener más información acerca de iSCSI, consulte el Capítulo 18, Ceph iSCSI Gateway.

  • Tiene un número limitado de dispositivos de almacenamiento de alto rendimiento y un gran conjunto de dispositivos de bajo rendimiento y necesita acceder a los datos almacenados con mayor rapidez.

14.4 Modos de caché Edit source

El agente de niveles de caché gestiona la migración de datos entre el nivel de caché y el de almacenamiento. Los administradores pueden configurar el modo en que se produce esta migración. Existen dos escenarios principales:

modo write-back

En el modo write-back, los clientes Ceph escriben datos en el nivel de caché y reciben una señal ACK de este. Posteriormente, los datos escritos en el nivel de caché pasan al nivel de almacenamiento y se eliminan del caché. Conceptualmente, el nivel de caché se superpone "delante" del nivel de almacenamiento. Cuando un cliente de Ceph necesita datos que se encuentran en el nivel de almacenamiento, el agente de niveles de caché mueve los datos al espacio de lectura del nivel de caché, que pasa a enviarlos al cliente de Ceph. A partir de ahí, el cliente de Ceph puede llevar a cabo operaciones de E/S con el nivel de caché hasta que los datos se vuelven inactivos. Esto resulta idóneo para datos modificables, como edición de fotografías y vídeos o datos transaccionales.

modo de solo lectura

En el modo de solo lectura, los clientes Ceph escriben los datos directamente en el nivel de almacenamiento. Al leer, Ceph copia los objetos solicitados del nivel de copia de seguridad al de caché. Los objetos obsoletos se eliminan del nivel de caché según la directiva definida. Este enfoque es idóneo para obtener datos inmutables, como la presentación de fotos o vídeos en una red social, datos de ADN o radiografías, ya que leer datos desde un repositorio de caché que podría incluir datos obsoletos ofrecería menos fiabilidad. No utilice el modo de solo lectura para datos modificables.

14.5 Repositorio codificado de borrado y niveles de caché Edit source

Los repositorios codificados de borrado requieren más recursos que los repositorios replicados. Para superar dichas limitaciones, se recomienda definir un nivel de caché antes de definir el repositorio codificado de borrado. Este es un requisito si se usa FileStore.

Por ejemplo, si el repositorio hot-storage está formado por almacenamiento rápido, el valor ecpool creado en la Sección 13.3, “Perfiles de código de borrado” se puede acelerar con:

cephadm@adm > ceph osd tier add ecpool hot-storage
cephadm@adm > ceph osd tier cache-mode hot-storage writeback
cephadm@adm > ceph osd tier set-overlay ecpool hot-storage

Esto colocará el repositorio hot-storage como nivel de ecpool en modo write-back para que cada operación de escritura y lectura en ecpool utilice en realidad almacenamiento en caliente y se beneficie de su flexibilidad y velocidad.

cephadm@adm > rbd --pool ecpool create --size 10 myvolume

Para obtener más información sobre los niveles de caché, consulte el Capítulo 14, Niveles de caché.

14.6 Configuración de un ejemplo de niveles de almacenamiento Edit source

En esta sección se muestra la configuración de un nivel de caché SSD rápido (almacenamiento en caliente) frente a un disco duro estándar (almacenamiento en frío).

Sugerencia
Sugerencia

El ejemplo siguiente solo tiene fines ilustrativos e incluye una configuración con una raíz y una regla para la parte del SSD en un único nodo Ceph.

En un entorno de producción, las configuraciones de clúster suelen incluir más raíces y reglas para el almacenamiento en caliente, así como nodos mixtos, con discos SSD y SATA.

  1. Cree dos reglas de CRUSH adicionales: "replicated_ssd" para la clase de dispositivo de almacenamiento en caché SSD rápida y "replicated_hdd" para la clase de dispositivo HDD más lenta:

    cephadm@adm > ceph osd crush rule create-replicated replicated_ssd default host ssd
    cephadm@adm > ceph osd crush rule create-replicated replicated_hdd default host hdd
  2. Cambie todos los repositorios existentes a la regla "replicated_hdd". Esto evita que Ceph almacene datos en los dispositivos SSD recién añadidos:

    cephadm@adm > ceph osd pool set POOL_NAME crush_rule replicated_hdd
  3. Convierta el equipo en un nodo Ceph mediante DeepSea. Instale el software y configure el equipo host como se describe en la Sección 2.1, “Adición de nuevos nodos de clúster”. Supongamos que su nombre es node-4. Este nodo debe tener 4 discos OSD.

    [...]
    host node-4 {
       id -5  # do not change unnecessarily
       # weight 0.012
       alg straw
       hash 0  # rjenkins1
       item osd.6 weight 0.003
       item osd.7 weight 0.003
       item osd.8 weight 0.003
       item osd.9 weight 0.003
    }
    [...]
  4. Edite la asignación CRUSH para el repositorio de almacenamiento en caliente asignado a los OSD con el respaldo de las unidades SSD rápidas. Defina una segunda jerarquía con un nodo raíz para los SSD (como "root ssd"). También puede cambiar el valor de peso (weight) y añadir una regla de CRUSH para los SSD. Para obtener más información sobre el mapa de CRUSH, consulte la Sección 9.5, “Manipulación del mapa de CRUSH”.

    Edite el mapa de CRUSH directamente con herramientas de línea de comandos, como getcrushmap y crushtool:

    cephadm@adm > ceph osd crush rm-device-class osd.6 osd.7 osd.8 osd.9
    cephadm@adm > ceph osd crush set-device-class ssd osd.6 osd.7 osd.8 osd.9
  5. Cree el repositorio de almacenamiento en caliente que se utilizará para los niveles de caché. Utilice la nueva regla "ssd":

    cephadm@adm > ceph osd pool create hot-storage 100 100 replicated ssd
  6. Cree el repositorio de almacenamiento en frío con la regla "replicated_ruleset" por defecto:

    cephadm@adm > ceph osd pool create cold-storage 100 100 replicated replicated_ruleset
  7. A continuación, la configuración de un nivel de caché implica asociar un repositorio de almacenamiento con un repositorio de caché, en este caso, almacenamiento en frío (copia de seguridad) con almacenamiento en caliente (caché):

    cephadm@adm > ceph osd tier add cold-storage hot-storage
  8. Para definir el modo de caché como "writeback" (escritura diferida), realice lo siguiente:

    cephadm@adm > ceph osd tier cache-mode hot-storage writeback

    Para obtener más información acerca de los modos de caché, consulte la Sección 14.4, “Modos de caché”.

    Los niveles de caché de la escritura diferida cubren el nivel de almacenamiento, por lo que requieren un paso adicional: debe dirigir todo el tráfico de los clientes del repositorio de almacenamiento al repositorio de caché. Para dirigir el tráfico de los clientes directamente al repositorio de caché, ejecute lo siguiente, por ejemplo:

    cephadm@adm > ceph osd tier set-overlay cold-storage hot-storage

14.7 Configuración de un nivel de caché Edit source

Existen varias opciones que puede utilizar para configurar niveles de caché. Utilice la siguiente sintaxis:

cephadm@adm > ceph osd pool set cachepool key value

14.7.1 Conjunto de resultados Edit source

Los parámetros de Hit set (Conjunto de resultados) permiten ajustar los repositorios de caché. Los conjuntos de resultados de Ceph suelen ser filtros de Bloom y proporcionan un modo eficaz de asignar memoria al seguimiento de los objetos que se encuentran en el repositorio de caché.

El conjunto de resultados es una matriz de bits que se utiliza para almacenar el resultado de un conjunto de funciones de hash aplicadas a nombres de objetos. Inicialmente, todos los bits se establecen como 0. Cuando un objeto se añade al conjunto de resultados, su nombre se almacena en un valor hash y el resultado se asigna a diferentes posiciones del conjunto de resultados, donde el valor de bit se establece como 1.

Para averiguar si un objeto existe en el caché, se vuelve a convertir su nombre en un valor hash. Si algún bit es 0, el objeto no está en el caché y hay que recuperarlo del almacenamiento en frío.

Es posible que los resultados de diferentes objetos estén almacenados en la misma posición del conjunto de resultados. El azar puede provocar que todos los bits sean 1 sin que el objeto esté en el caché. Por lo tanto, los conjuntos de resultados que funcionan con un filtro de Bloom solo pueden distinguir con total seguridad que un objeto no está en el caché y es necesario recuperarlo del almacenamiento en frío.

Un repositorio de caché puede tener más de un conjunto de resultados para realizar un seguimiento del acceso a los archivos a lo largo del tiempo. El ajuste hit_set_count define el número de conjuntos de resultados que se están utilizando y hit_set_period define durante cuánto tiempo se ha utilizado cada conjunto. Cuando vence el periodo, se utiliza el siguiente conjunto de resultados. Si se agota el número de conjuntos de resultados, se libera la memoria del conjunto de resultados más antiguo y se crea un nuevo conjunto. Los valores de hit_set_count y hit_set_period multiplicados entre sí definen el marco de tiempo general durante el que se ha realizado el seguimiento del acceso a los objetos.

Filtro de Bloom con 3 objetos almacenados
Figura 14.1: Filtro de Bloom con 3 objetos almacenados

En comparación con el número de objetos con hash, un conjunto de resultados a partir de un filtro de Bloom implica un uso muy eficaz de la memoria. Se necesitan menos de 10 bits para reducir la probabilidad de falsos positivos por debajo del 1 %. La probabilidad de falsos positivos se puede definir con hit_set_fpp. En función del número de objetos en un grupo de posiciones y la probabilidad de falsos positivos, Ceph calcula automáticamente el tamaño del conjunto de resultados.

El almacenamiento requerido en el repositorio de caché se puede limitar con min_write_recency_for_promote y min_read_recency_for_promote. Si el valor se define como 0, todos los objetos se almacenan en el repositorio de caché en cuanto se leen o se escriben y persisten hasta que son expulsados. Cualquier valor mayor que 0 define el número de conjuntos de resultados ordenados por antigüedad en los que se busca el objeto. Si el objeto se encuentra en un conjunto de resultados, se almacenará en el repositorio de caché. Tenga en cuenta que al crear una copia de seguridad de los objetos, estos podrían subirse a la memoria caché. Una copia de seguridad completa con el valor "0" puede hacer que todos los datos se suban al nivel de caché mientras los datos activos se eliminan del nivel de caché. Por lo tanto, puede resultar útil cambiar este valor en función de la estrategia de copia de seguridad.

Nota
Nota

Cuanto más prolongado sea el periodo y más altos los valores de min_read_recency_for_promote y min_write_recency_for_promote, más memoria RAM consumirá el daemon ceph-osd. En concreto, cuando el agente se activa para limpiar o expulsar objetos del caché, todos los conjuntos de resultados de hit_set_count se cargan en la memoria RAM.

14.7.1.1 Utilice GMT para el conjunto de resultados Edit source

Las configuraciones de nivel de caché tienen un filtro de Bloom llamado conjunto de resultados. El filtro comprueba si un objeto pertenece a un conjunto de objetos de almacenamiento en frío o en caliente. Los objetos se incorporan al conjunto de resultados con marcas horarias añadidas a su nombre.

Si los equipos del clúster se encuentran en distintas zonas horarias y las marcas horarias se corresponden con la hora local, los objetos de un conjunto de resultados pueden tener nombres equívocos, con marcas horarias futuras o pasadas. En el peor de los casos, los objetos podrían no existir en el conjunto de resultados.

Para evitar esto, el parámetro use_gmt_hitset tiene un valor por defecto de "1" en las configuraciones de nivel de caché recién creadas. De este modo, se fuerza el uso de marcas horarias GMT (hora del meridiano de Greenwich) por parte de los OSD al crear los nombres de objetos para los conjuntos de resultados.

Aviso
Aviso: deje el valor por defecto

No modifique el valor por defecto de "1" en use_gmt_hitset. Si los errores relacionados con esta opción no se deben a la configuración del clúster, no lo cambie nunca manualmente. De lo contrario, el comportamiento del clúster podría ser impredecible.

14.7.2 Tamaño de caché Edit source

El agente de niveles de caché realiza dos funciones principales:

Limpieza

El agente identifica objetos modificados (sucios) y los envía al repositorio de almacenamiento para el almacenamiento a largo plazo.

Expulsión

El agente identifica los objetos que no han sido modificados (limpios) y expulsa del caché a los que no se han utilizado recientemente.

14.7.2.1 Tamaño absoluto Edit source

El agente de niveles de caché puede limpiar o expulsar objetos basándose en el número total de bytes o en el número total de objetos. Para especificar un número máximo de bytes, ejecute lo siguiente:

cephadm@adm > ceph osd pool set cachepool target_max_bytes num_of_bytes

Para especificar el número máximo de objetos, ejecute lo siguiente:

cephadm@adm > ceph osd pool set cachepool target_max_objects num_of_objects
Nota
Nota

Ceph no puede determinar el tamaño de un repositorio de caché de forma automática, por lo que se precisa la configuración del tamaño absoluto. De lo contrario, las tareas de limpieza y expulsión no funcionarán. Si especifica ambos límites, el agente de niveles de caché empezará a limpiar o a expulsar cuando se active cualquiera de los dos umbrales.

Nota
Nota

Solo se bloquearán todas las peticiones de los clientes cuando se alcancen los valores de target_max_bytes o target_max_objects.

14.7.2.2 Tamaño relativo Edit source

El agente de niveles de caché puede limpiar o expulsar objetos en relación al tamaño del repositorio de caché (especificado por target_max_bytes o target_max_objects en la Sección 14.7.2.1, “Tamaño absoluto”). Cuando el repositorio de caché conste de determinado porcentaje de objetos modificados (sucios), el agente de niveles de caché los limpiará vaciándolos en el repositorio de almacenamiento. Para definir el valor de cache_target_dirty_ratio, ejecute lo siguiente:

cephadm@adm > ceph osd pool set cachepool cache_target_dirty_ratio 0.0...1.0

Por ejemplo, si define el valor como 0,4, la limpieza de los objetos modificados (sucios) comenzará cuando se alcance el 40 % de la capacidad del repositorio de caché:

cephadm@adm > ceph osd pool set hot-storage cache_target_dirty_ratio 0.4

Cuando los objetos sucios alcancen un porcentaje determinado de la capacidad, se limpiarán a una velocidad superior. Use cache_target_dirty_high_ratio:

cephadm@adm > ceph osd pool set cachepool cache_target_dirty_high_ratio 0.0..1.0

Cuando el repositorio de caché alcance un porcentaje determinado de su capacidad, el agente de niveles de caché expulsará objetos para mantener la capacidad disponible. Para definir el valor de cache_target_full_ratio, ejecute lo siguiente:

cephadm@adm > ceph osd pool set cachepool cache_target_full_ratio 0.0..1.0

14.7.3 Antigüedad del caché Edit source

Puede especificar la antigüedad mínima que debe tener un objeto (sucio) modificado recientemente para que el agente de niveles de caché lo vacíe en el repositorio de almacenamiento. Tenga en cuenta que esto solo se aplicará si la memoria caché realmente necesita vaciar/expulsar objetos:

cephadm@adm > ceph osd pool set cachepool cache_min_flush_age num_of_seconds

Puede especificar la antigüedad mínima que debe tener un objeto para que se expulse del nivel de caché:

cephadm@adm > ceph osd pool set cachepool cache_min_evict_age num_of_seconds

14.7.4 Ejemplos Edit source

14.7.4.1 Repositorio de caché extenso y poca memoria Edit source

Si hay mucho espacio de almacenamiento y poca cantidad de RAM disponible, se pueden almacenar todos los objetos en el repositorio de caché en cuanto se accede a ellos. El conjunto de resultados seguirá teniendo un tamaño pequeño. A continuación encontrará un conjunto de valores de configuración de ejemplo:

hit_set_count = 1
hit_set_period = 3600
hit_set_fpp = 0.05
min_write_recency_for_promote = 0
min_read_recency_for_promote = 0

14.7.4.2 Repositorio de caché pequeño y mucha memoria Edit source

Si hay poco espacio de almacenamiento, pero una capacidad de memoria disponible relativamente grande, el nivel de caché puede configurarse para que almacene un número limitado de objetos en el repositorio de caché. Doce conjuntos de resultados, de los cuales cada uno se usa durante un periodo de 14.400 segundos, proporcionan un seguimiento durante 48 horas en total. Si se ha accedido a un objeto durante las últimas 8 horas, se almacena en el repositorio de caché. El conjunto de valores de configuración de ejemplo es el siguiente:

hit_set_count = 12
hit_set_period = 14400
hit_set_fpp = 0.01
min_write_recency_for_promote = 2
min_read_recency_for_promote = 2
Imprimir esta página