Red Hat Training

A Red Hat training course is available for RHEL 8

Deduplicar y comprimir el almacenamiento

Red Hat Enterprise Linux 8

Uso de VDO para optimizar la capacidad de almacenamiento en RHEL 8

Resumen

Esta colección de documentación proporciona instrucciones sobre cómo utilizar el Optimizador de Datos Virtuales (VDO) para gestionar grupos de almacenamiento deduplicados y comprimidos en Red Hat Enterprise Linux 8.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a sustituir el lenguaje problemático en nuestro código, documentación y propiedades web. Estamos empezando con estos cuatro términos: maestro, esclavo, lista negra y lista blanca. Debido a la enormidad de este esfuerzo, estos cambios se implementarán gradualmente a lo largo de varias versiones próximas. Para más detalles, consulte el mensaje de nuestro CTO Chris Wright.

Proporcionar comentarios sobre la documentación de Red Hat

Agradecemos su opinión sobre nuestra documentación. Por favor, díganos cómo podemos mejorarla. Para ello:

  • Para comentarios sencillos sobre pasajes concretos:

    1. Asegúrese de que está viendo la documentación en el formato Multi-page HTML. Además, asegúrese de ver el botón Feedback en la esquina superior derecha del documento.
    2. Utilice el cursor del ratón para resaltar la parte del texto que desea comentar.
    3. Haga clic en la ventana emergente Add Feedback que aparece debajo del texto resaltado.
    4. Siga las instrucciones mostradas.
  • Para enviar comentarios más complejos, cree un ticket de Bugzilla:

    1. Vaya al sitio web de Bugzilla.
    2. Como componente, utilice Documentation.
    3. Rellene el campo Description con su sugerencia de mejora. Incluya un enlace a la(s) parte(s) pertinente(s) de la documentación.
    4. Haga clic en Submit Bug.

Capítulo 1. Despliegue de VDO

Como administrador del sistema, puede utilizar VDO para crear pools de almacenamiento deduplicados y comprimidos.

1.1. Introducción a VDO

Virtual Data Optimizer (VDO) proporciona una reducción de datos en línea para Linux en forma de deduplicación, compresión y thin provisioning. Cuando se configura un volumen VDO, se especifica un dispositivo de bloques en el que construir el volumen VDO y la cantidad de almacenamiento lógico que se pretende presentar.

  • Al alojar máquinas virtuales o contenedores activos, Red Hat recomienda aprovisionar el almacenamiento en una proporción de 10:1 lógica a física: es decir, si está utilizando 1 TB de almacenamiento físico, lo presentaría como 10 TB de almacenamiento lógico.
  • Para el almacenamiento de objetos, como el tipo proporcionado por Ceph, Red Hat recomienda utilizar una proporción de 3:1 lógica a física: es decir, 1 TB de almacenamiento físico se presentaría como 3 TB de almacenamiento lógico.

En cualquiera de los dos casos, puede simplemente poner un sistema de archivos sobre el dispositivo lógico presentado por VDO y luego utilizarlo directamente o como parte de una arquitectura de almacenamiento distribuido en la nube.

Debido a que VDO tiene un aprovisionamiento ligero, el sistema de archivos y las aplicaciones sólo ven el espacio lógico en uso y no son conscientes del espacio físico real disponible. Utilice scripts para supervisar el espacio real disponible y generar una alerta si el uso supera un umbral: por ejemplo, cuando el volumen de VDO está a 80 de su capacidad.

Recursos adicionales

1.2. Escenarios de implantación de VDO

Puede desplegar VDO de varias maneras para proporcionar almacenamiento deduplicado para:

  • tanto el acceso a los bloques como a los archivos
  • almacenamiento local y remoto

Dado que VDO expone su almacenamiento deduplicado como un dispositivo de bloques estándar de Linux, puede utilizarlo con sistemas de archivos estándar, controladores de destino iSCSI y FC, o como almacenamiento unificado.

Nota

El despliegue de VDO con Ceph Storage no está soportado actualmente.

KVM

Puede desplegar VDO en un servidor KVM configurado con Direct Attached Storage.

VDO Deployment with KVM

Sistemas de archivos

Puede crear sistemas de archivos sobre VDO y exponerlos a usuarios NFS o CIFS con el servidor NFS o Samba.

Deduplicated NAS

objetivo iSCSI

Puede exportar la totalidad del objetivo de almacenamiento VDO como objetivo iSCSI a iniciadores iSCSI remotos.

Deduplicated block storage target

LVM

En los sistemas con más funciones, puede utilizar LVM para proporcionar varios números de unidades lógicas (LUN) que estén respaldados por el mismo grupo de almacenamiento deduplicado.

En el siguiente diagrama, el objetivo VDO se registra como un volumen físico para que pueda ser gestionado por LVM. Se crean múltiples volúmenes lógicos (LV1 a LV4) a partir del pool de almacenamiento deduplicado. De esta manera, VDO puede soportar el acceso a bloques o archivos unificados multiprotocolo al pool de almacenamiento deduplicado subyacente.

Deduplicated unified storage

El diseño de almacenamiento unificado deduplicado permite que varios sistemas de archivos utilicen colectivamente el mismo dominio de deduplicación a través de las herramientas LVM. Además, los sistemas de archivos pueden aprovechar las funciones de instantáneas LVM, copia en escritura y contracción o crecimiento, todo ello sobre VDO.

Codificación

Los mecanismos de Device Mapper (DM) como DM Crypt son compatibles con VDO. El cifrado de los volúmenes de VDO ayuda a garantizar la seguridad de los datos, y cualquier sistema de archivos por encima de VDO se sigue deduplicando.

Using VDO with encryption
Importante

La aplicación de la capa de encriptación por encima de VDO da lugar a poca o ninguna deduplicación de datos. El cifrado hace que los bloques duplicados sean diferentes antes de que VDO pueda deduplicarlos.

Coloque siempre la capa de encriptación por debajo de VDO.

1.3. Componentes de un volumen VDO

VDO utiliza un dispositivo de bloque como almacén de respaldo, que puede incluir una agregación de almacenamiento físico consistente en uno o más discos, particiones o incluso archivos planos. Cuando una herramienta de gestión de almacenamiento crea un volumen VDO, VDO reserva espacio de volumen para el índice UDS y el volumen VDO. El índice UDS y el volumen VDO interactúan juntos para proporcionar almacenamiento de bloques deduplicado.

Figura 1.1. Organización del disco VDO

VDO disk organization

La solución de VDO consta de los siguientes componentes:

kvdo

Un módulo del kernel que se carga en la capa de Linux Device Mapper proporciona un volumen de almacenamiento en bloque deduplicado, comprimido y con aprovisionamiento ligero.

El módulo kvdo expone un dispositivo de bloque. Puede acceder a este dispositivo de bloque directamente para el almacenamiento en bloque o presentarlo a través de un sistema de archivos Linux, como XFS o ext4.

Cuando kvdo recibe una solicitud para leer un bloque lógico de datos de un volumen VDO, mapea el bloque lógico solicitado al bloque físico subyacente y luego lee y devuelve los datos solicitados.

Cuando kvdo recibe una solicitud para escribir un bloque de datos en un volumen VDO, primero comprueba si la solicitud es una petición de DISCARD o TRIM o si los datos son uniformemente cero. Si cualquiera de estas condiciones es verdadera, kvdo actualiza su mapa de bloques y reconoce la solicitud. En caso contrario, VDO procesa y optimiza los datos.

uds

Un módulo del núcleo que se comunica con el índice del Servicio Universal de Deduplicación (UDS) en el volumen y analiza los datos en busca de duplicados. Para cada nueva pieza de datos, UDS determina rápidamente si esa pieza es idéntica a cualquier pieza de datos almacenada previamente. Si el índice encuentra una coincidencia, el sistema de almacenamiento puede entonces referenciar internamente el elemento existente para evitar almacenar la misma información más de una vez.

El índice UDS se ejecuta dentro del núcleo como el módulo del núcleo uds.

Herramientas de línea de comandos
Para configurar y gestionar el almacenamiento optimizado.

1.4. El tamaño físico y lógico de un volumen VDO

Esta sección describe el tamaño físico, el tamaño físico disponible y el tamaño lógico que puede utilizar VDO:

Tamaño físico

Este es el mismo tamaño que el dispositivo de bloque subyacente. VDO utiliza este almacenamiento para:

  • Los datos de los usuarios, que pueden estar deduplicados y comprimidos
  • Metadatos VDO, como el índice UDS
Tamaño físico disponible

Es la parte del tamaño físico que VDO puede utilizar para los datos del usuario

Equivale al tamaño físico menos el tamaño de los metadatos, menos el resto tras dividir el volumen en losas por el tamaño de losa dado.

Tamaño lógico

Es el tamaño provisionado que el volumen VDO presenta a las aplicaciones. Normalmente es mayor que el tamaño físico disponible. Si no se especifica la opción --vdoLogicalSize, entonces el aprovisionamiento del volumen lógico se aprovisiona en una proporción de 1:1. Por ejemplo, si se coloca un volumen VDO sobre un dispositivo de bloques de 20 GB, entonces se reservan 2,5 GB para el índice UDS (si se utiliza el tamaño de índice por defecto). Los 17,5 GB restantes se destinan a los metadatos de VDO y a los datos del usuario. Como resultado, el almacenamiento disponible para consumir no es más de 17,5 GB, y puede ser menos debido a los metadatos que componen el volumen VDO real.

Actualmente, VDO admite cualquier tamaño lógico hasta 254 veces el tamaño del volumen físico, con un tamaño lógico máximo absoluto de 4PB.

Figura 1.2. Organización del disco VDO

VDO disk organization

En esta figura, el objetivo de almacenamiento deduplicado VDO se sitúa completamente sobre el dispositivo de bloque, lo que significa que el tamaño físico del volumen VDO es del mismo tamaño que el dispositivo de bloque subyacente.

Recursos adicionales

1.5. Tamaño de la losa en VDO

El almacenamiento físico del volumen VDO se divide en un número de losas. Cada tabla es una región contigua del espacio físico. Todos los bloques de un volumen determinado tienen el mismo tamaño, que puede ser cualquier potencia de 2 múltiplos de 128 MB hasta 32 GB.

El tamaño por defecto de los slabs es de 2 GB para facilitar la evaluación de VDO en sistemas de prueba más pequeños. Un solo volumen VDO puede tener hasta 8192 bloques. Por lo tanto, en la configuración por defecto con losas de 2 GB, el almacenamiento físico máximo permitido es de 16 TB. Cuando se utilizan placas de 32 GB, el máximo de almacenamiento físico permitido es de 256 TB. VDO siempre reserva al menos un slab entero para metadatos, y por lo tanto, el slab reservado no puede ser utilizado para almacenar datos de usuario.

El tamaño de la losa no influye en el rendimiento del volumen VDO.

Tabla 1.1. Tamaños de losa VDO recomendados por tamaño de volumen físico

Tamaño del volumen físicoTamaño de losa recomendado

10-99 GB

1 GB

100 GB - 1 TB

2 GB

2-256 TB

32 GB

Puede controlar el tamaño de la losa proporcionando la opción --vdoSlabSize=megabytes al comando vdo create.

1.6. Requisitos de VDO

VDO tiene ciertos requisitos en cuanto a su colocación y a los recursos de su sistema.

1.6.1. Requisitos de memoria de VDO

Cada volumen VDO tiene dos requisitos de memoria distintos:

El módulo VDO

VDO requiere una cantidad fija de 38 MB de RAM y varias cantidades variables:

  • 1.15 MB de RAM por cada 1 MB de tamaño de caché de mapa de bloques configurado. La caché del mapa de bloques requiere un mínimo de 150 MB de RAM.
  • 1.6 MB de RAM por cada 1 TB de espacio lógico.
  • 268 MB de RAM por cada 1 TB de almacenamiento físico gestionado por el volumen.

El índice UDS

El Servicio de Deduplicación Universal (UDS) requiere un mínimo de 250 MB de RAM, que es también la cantidad por defecto que utiliza la deduplicación. Puede configurar el valor al formatear un volumen VDO, ya que el valor también afecta a la cantidad de almacenamiento que necesita el índice.

La memoria necesaria para el índice UDS viene determinada por el tipo de índice y el tamaño requerido de la ventana de deduplicación:

Tipo de índiceVentana de deduplicaciónNota

Denso

1 TB por cada 1 GB de RAM

Un índice denso de 1 GB suele ser suficiente para hasta 4 TB de almacenamiento físico.

Sparse

10 TB por 1 GB de RAM

Un índice disperso de 1 GB suele ser suficiente para hasta 40 TB de almacenamiento físico.

La función UDS Sparse Indexing es el modo recomendado para VDO. Se basa en la localidad temporal de los datos e intenta retener en memoria sólo las entradas de índice más relevantes. Con el índice disperso, UDS puede mantener una ventana de deduplicación diez veces mayor que con el denso, utilizando la misma cantidad de memoria.

Aunque el índice disperso proporciona la mayor cobertura, el índice denso ofrece más consejos de deduplicación. Para la mayoría de las cargas de trabajo, dada la misma cantidad de memoria, la diferencia en las tasas de deduplicación entre los índices densos y dispersos es insignificante.

Recursos adicionales

1.6.2. Requisitos de espacio de almacenamiento de VDO

Puede configurar un volumen VDO para utilizar hasta 256 TB de almacenamiento físico. Sólo una parte del almacenamiento físico es utilizable para almacenar datos. Esta sección proporciona los cálculos para determinar el tamaño utilizable de un volumen gestionado por VDO.

VDO requiere almacenamiento para dos tipos de metadatos VDO y para el índice UDS:

  • El primer tipo de metadatos VDO utiliza aproximadamente 1 MB por cada 4 GB de physical storage más 1 MB adicional por cada losa.
  • El segundo tipo de metadatos VDO consume aproximadamente 1,25 MB por cada 1 GB de logical storage, redondeado a la losa más cercana.
  • La cantidad de almacenamiento necesaria para el índice UDS depende del tipo de índice y de la cantidad de RAM asignada al índice. Por cada 1 GB de RAM, un índice UDS denso utiliza 17 GB de almacenamiento, y un índice UDS disperso utilizará 170 GB de almacenamiento.

Recursos adicionales

1.6.3. Colocación de VDO en la pila de almacenamiento

Debe colocar ciertas capas de almacenamiento debajo de VDO y otras por encima de VDO.

Un volumen VDO es un dispositivo de bloque poco aprovisionado. Para evitar quedarse sin espacio físico, coloque el volumen encima de un almacenamiento que pueda ampliar más adelante. Ejemplos de este tipo de almacenamiento ampliable son los volúmenes LVM o las matrices RAID MD.

Puede colocar capas de aprovisionamiento grueso encima de VDO, pero no puede confiar en las garantías del aprovisionamiento grueso en ese caso. Dado que la capa VDO es de aprovisionamiento fino, los efectos del aprovisionamiento fino se aplican a todas las capas por encima de ella. Si no supervisa el dispositivo VDO, podría quedarse sin espacio físico en los volúmenes de aprovisionamiento grueso por encima de VDO.

Configuraciones compatibles

  • Capas que sólo se pueden colocar bajo VDO:

    • DM Multipath
    • Cripta DM
    • RAID por software (LVM o MD RAID)
  • Capas que sólo se pueden colocar encima de VDO:

    • Caché LVM
    • Instantáneas LVM
    • Aprovisionamiento ligero LVM

Configuraciones no admitidas

  • VDO sobre otros volúmenes VDO
  • VDO sobre las instantáneas LVM
  • VDO sobre la caché LVM
  • VDO sobre un dispositivo de bucle de retorno
  • VDO sobre el aprovisionamiento ligero de LVM
  • Volúmenes encriptados sobre VDO
  • Particiones en un volumen VDO
  • RAID, como LVM RAID, MD RAID, o cualquier otro tipo, sobre un volumen VDO

Recursos adicionales

  • Para más información sobre el apilamiento de VDO con capas LVM, consulte el artículo Apilar volúmenes LVM.

1.6.4. Ejemplos de requisitos VDO por tamaño físico

Las siguientes tablas proporcionan los requisitos aproximados del sistema de VDO basados en el tamaño físico del volumen subyacente. Cada tabla enumera los requisitos apropiados para el despliegue previsto, como el almacenamiento primario o el almacenamiento de copia de seguridad.

Los números exactos dependen de su configuración del volumen VDO.

Despliegue del almacenamiento primario

En el caso del almacenamiento primario, el índice UDS está entre el 0,01% y el 25% del tamaño físico.

Tabla 1.2. Requisitos de almacenamiento y memoria para el almacenamiento primario

Tamaño físicoUso de la RAM: UDSUso de la RAM: VDOUso del discoTipo de índice

10GB-1TB

250MB

472MB

2.5GB

Denso

2-10TB

1GB

3GB

10 GB

Denso

250MB

22 GB

Sparse

11-50TB

2GB

14 GB

170 GB

Sparse

51-100TB

3GB

27 GB

255 GB

Sparse

101-256TB

12 GB

69 GB

1020 GB

Sparse

Despliegue del almacenamiento de seguridad

En el caso del almacenamiento de copias de seguridad, el índice UDS cubre el tamaño del conjunto de copias de seguridad pero no es mayor que el tamaño físico. Si espera que el conjunto de copias de seguridad o el tamaño físico crezcan en el futuro, téngalo en cuenta en el tamaño del índice.

Tabla 1.3. Requisitos de almacenamiento y memoria para el almacenamiento de copias de seguridad

Tamaño físicoUso de la RAM: UDSUso de la RAM: VDOUso del discoTipo de índice

10GB-1TB

250MB

472MB

2.5 GB

Denso

2-10TB

2GB

3GB

170 GB

Sparse

11-50TB

10 GB

14 GB

850 GB

Sparse

51-100TB

20 GB

27 GB

1700GB

Sparse

101-256TB

26 GB

69 GB

3400GB

Sparse

1.7. Instalación de VDO

Este procedimiento instala el software necesario para crear, montar y gestionar volúmenes VDO.

Procedimiento

  • Instale los paquetes vdo y kmod-kvdo:

    # yum install vdo kmod-kvdo

1.8. Creación de un volumen VDO

Este procedimiento crea un volumen VDO en un dispositivo de bloque.

Requisitos previos

Procedimiento

En todos los pasos siguientes, sustituya vdo-name por el identificador que desee utilizar para su volumen VDO; por ejemplo, vdo1. Debe utilizar un nombre y un dispositivo diferentes para cada instancia de VDO en el sistema.

  1. Busque un nombre persistente para el dispositivo de bloque donde desea crear el volumen VDO. Para más información sobre los nombres persistentes, consulte Capítulo 6, Visión general de los atributos de nomenclatura persistente.

    Si utiliza un nombre de dispositivo no persistente, entonces VDO podría no iniciarse correctamente en el futuro si el nombre del dispositivo cambia.

  2. Crea el volumen VDO:

    # vdo create \
          --name=vdo-name \
          --device=block-device \
          --vdoLogicalSize=logical-size
    • Sustituya block-device por el nombre persistente del dispositivo de bloque en el que desea crear el volumen VDO. Por ejemplo, /dev/disk/by-id/scsi-3600508b1001c264ad2af21e903ad031f.
    • Sustituya logical-size con la cantidad de almacenamiento lógico que debe presentar el volumen VDO:

      • Para las máquinas virtuales activas o el almacenamiento en contenedores, utilice un tamaño lógico que sea ten veces el tamaño físico de su dispositivo de bloque. Por ejemplo, si su dispositivo de bloque tiene un tamaño de 1TB, utilice aquí 10T.
      • Para el almacenamiento de objetos, utilice el tamaño lógico que es three veces el tamaño físico de su dispositivo de bloque. Por ejemplo, si su dispositivo de bloque tiene un tamaño de 1TB, utilice aquí 3T.
    • Si el dispositivo de bloque físico es mayor de 16TiB, añada la opción --vdoSlabSize=32G para aumentar el tamaño de la losa en el volumen a 32GiB.

      Si se utiliza el tamaño de bloque por defecto de 2GiB en dispositivos de bloque de más de 16TiB, el comando vdo create falla con el siguiente error:

      vdo: ERROR - vdoformat: formatVDO failed on '/dev/device': Estado de VDO: Excede el número máximo de placas soportadas

    Ejemplo 1.1. Creación de VDO para el almacenamiento de contenedores

    Por ejemplo, para crear un volumen VDO para el almacenamiento de contenedores en un dispositivo de bloque de 1TB, podría utilizar:

    # vdo create \
          --name=vdo1 \
          --device=/dev/disk/by-id/scsi-3600508b1001c264ad2af21e903ad031f \
          --vdoLogicalSize=10T
    Importante

    Si se produce un fallo al crear el volumen VDO, elimine el volumen para limpiarlo. Consulte Sección 2.10.2, “Eliminación de un volumen VDO creado sin éxito” para obtener más detalles.

  3. Cree un sistema de archivos sobre el volumen VDO:

    • Para el sistema de archivos XFS:

      # mkfs.xfs -K /dev/mapper/vdo-name
    • Para el sistema de archivos ext4:

      # mkfs.ext4 -E nodiscard /dev/mapper/vdo-name
  4. Utilice el siguiente comando para esperar a que el sistema registre el nuevo nodo de dispositivo:

    # udevadm settle

Próximos pasos

  1. Montar el sistema de archivos. Consulte Sección 1.9, “Montaje de un volumen VDO” para obtener más detalles.
  2. Habilite la función discard para el sistema de archivos de su dispositivo VDO. Consulte Sección 1.10, “Activación del descarte periódico de bloques” para obtener más detalles.

Recursos adicionales

  • La página de manual vdo(8)

1.9. Montaje de un volumen VDO

Este procedimiento monta un sistema de archivos en un volumen VDO, de forma manual o persistente.

Requisitos previos

Procedimiento

  • Para montar el sistema de archivos en el volumen VDO manualmente, utilice:

    # montar /dev/mapper/vdo-name mount-point
  • Para configurar el sistema de archivos para que se monte automáticamente en el arranque, añada una línea al archivo /etc/fstab:

    • Para el sistema de archivos XFS:

      /dev/mapper/vdo-name mount-point xfs defaults,_netdev,x-systemd.device-timeout=0,x-systemd.requires=vdo.service 0 0
    • Para el sistema de archivos ext4:

      /dev/mapper/vdo-name mount-point ext4 defaults,_netdev,x-systemd.device-timeout=0,x-systemd.requires=vdo.service 0 0

Recursos adicionales

  • La página de manual vdo(8)

1.10. Activación del descarte periódico de bloques

Este procedimiento habilita un temporizador systemd que descarta regularmente los bloques no utilizados en todos los sistemas de archivos compatibles.

Procedimiento

  • Activar e iniciar el temporizador systemd:

    # systemctl enable --now fstrim.timer

1.11. Control de VDO

Este procedimiento describe cómo obtener información de uso y eficiencia de un volumen VDO.

Requisitos previos

Procedimiento

  • Utilice la utilidad vdostats para obtener información sobre un volumen VDO:

    # vdostats --human-readable
    
    Device                   1K-blocks    Used     Available    Use%    Space saving%
    /dev/mapper/node1osd1    926.5G       21.0G    905.5G       2%      73%
    /dev/mapper/node1osd2    926.5G       28.2G    898.3G       3%      64%

Recursos adicionales

  • La página de manual vdostats(8).

Capítulo 2. Mantenimiento de VDO

Después de desplegar un volumen VDO, puede realizar ciertas tareas para mantenerlo u optimizarlo. Algunas de las siguientes tareas son necesarias para el correcto funcionamiento de los volúmenes VDO.

Requisitos previos

2.1. Gestión del espacio libre en los volúmenes VDO

VDO es un objetivo de almacenamiento en bloque poco aprovisionado. Por ello, debe supervisar y gestionar activamente el uso del espacio en los volúmenes de VDO.

2.1.1. El tamaño físico y lógico de un volumen VDO

Esta sección describe el tamaño físico, el tamaño físico disponible y el tamaño lógico que puede utilizar VDO:

Tamaño físico

Este es el mismo tamaño que el dispositivo de bloque subyacente. VDO utiliza este almacenamiento para:

  • Los datos de los usuarios, que pueden estar deduplicados y comprimidos
  • Metadatos VDO, como el índice UDS
Tamaño físico disponible

Es la parte del tamaño físico que VDO puede utilizar para los datos del usuario

Equivale al tamaño físico menos el tamaño de los metadatos, menos el resto tras dividir el volumen en losas por el tamaño de losa dado.

Tamaño lógico

Es el tamaño provisionado que el volumen VDO presenta a las aplicaciones. Normalmente es mayor que el tamaño físico disponible. Si no se especifica la opción --vdoLogicalSize, entonces el aprovisionamiento del volumen lógico se aprovisiona en una proporción de 1:1. Por ejemplo, si se coloca un volumen VDO sobre un dispositivo de bloques de 20 GB, entonces se reservan 2,5 GB para el índice UDS (si se utiliza el tamaño de índice por defecto). Los 17,5 GB restantes se destinan a los metadatos de VDO y a los datos del usuario. Como resultado, el almacenamiento disponible para consumir no es más de 17,5 GB, y puede ser menos debido a los metadatos que componen el volumen VDO real.

Actualmente, VDO admite cualquier tamaño lógico hasta 254 veces el tamaño del volumen físico, con un tamaño lógico máximo absoluto de 4PB.

Figura 2.1. Organización del disco VDO

VDO disk organization

En esta figura, el objetivo de almacenamiento deduplicado VDO se sitúa completamente sobre el dispositivo de bloque, lo que significa que el tamaño físico del volumen VDO es del mismo tamaño que el dispositivo de bloque subyacente.

Recursos adicionales

2.1.2. Aprovisionamiento ligero en VDO

VDO es un objetivo de almacenamiento en bloque con aprovisionamiento ligero. La cantidad de espacio físico que utiliza un volumen VDO puede diferir del tamaño del volumen que se presenta a los usuarios del almacenamiento. Puede aprovechar esta disparidad para ahorrar en costes de almacenamiento.

Condiciones fuera del espacio

Tenga cuidado para evitar quedarse sin espacio de almacenamiento de forma inesperada, si los datos escritos no alcanzan la tasa de optimización esperada.

Cuando el número de bloques lógicos (almacenamiento virtual) supera el número de bloques físicos (almacenamiento real), es posible que los sistemas de archivos y las aplicaciones se queden inesperadamente sin espacio. Por esta razón, los sistemas de almacenamiento que utilizan VDO deben proporcionarle una forma de controlar el tamaño del pool libre en el volumen VDO.

Puede determinar el tamaño de este pool libre utilizando la utilidad vdostats. La salida por defecto de esta utilidad lista la información de todos los volúmenes VDO en ejecución en un formato similar al de la utilidad de Linux df. Por ejemplo:

Device                1K-blocks   Used        Available   Use%
/dev/mapper/vdo-name  211812352   105906176   105906176   50%

Cuando la capacidad de almacenamiento físico de un volumen VDO está casi llena, VDO informa de una advertencia en el registro del sistema, similar a la siguiente:

Oct  2 17:13:39 system lvm[13863]: Monitoring VDO pool vdo-name.
Oct  2 17:27:39 system lvm[13863]: WARNING: VDO pool vdo-name is now 80.69% full.
Oct  2 17:28:19 system lvm[13863]: WARNING: VDO pool vdo-name is now 85.25% full.
Oct  2 17:29:39 system lvm[13863]: WARNING: VDO pool vdo-name is now 90.64% full.
Oct  2 17:30:29 system lvm[13863]: WARNING: VDO pool vdo-name is now 96.07% full.
Nota

Estos mensajes de advertencia sólo aparecen cuando el servicio lvm2-monitor está en funcionamiento. Está activado por defecto.

Cómo prevenir las condiciones de fuera del espacio

Si el tamaño de la piscina libre desciende por debajo de un determinado nivel, puedes actuar:

  • Eliminación de datos. Esto recupera espacio siempre que los datos borrados no se dupliquen. El borrado de datos libera el espacio sólo después de los descartes.
  • Añadir almacenamiento físico
Importante

Supervise el espacio físico en sus volúmenes VDO para evitar situaciones de falta de espacio. Quedarse sin bloques físicos podría resultar en la pérdida de datos recientemente escritos y no reconocidos en el volumen VDO.

Aprovisionamiento delgado y los comandos TRIM y DISCARD

Para beneficiarse del ahorro de almacenamiento que supone el thin provisioning, la capa de almacenamiento físico necesita saber cuándo se eliminan los datos. Los sistemas de archivos que trabajan con el almacenamiento thinly provisioned envían comandos TRIM o DISCARD para informar al sistema de almacenamiento cuando un bloque lógico ya no es necesario.

Existen varios métodos para enviar los comandos TRIM o DISCARD:

  • Con la opción de montaje discard, los sistemas de archivos pueden enviar estos comandos cada vez que se elimina un bloque.
  • Puede enviar los comandos de forma controlada utilizando utilidades como fstrim. Estas utilidades le dicen al sistema de archivos que detecte los bloques lógicos que no se utilizan y que envíe la información al sistema de almacenamiento en forma de comando TRIM o DISCARD.

La necesidad de utilizar TRIM o DISCARD en los bloques no utilizados no es exclusiva de VDO. Cualquier sistema de almacenamiento con aprovisionamiento ligero tiene el mismo reto.

2.1.3. Control de VDO

Este procedimiento describe cómo obtener información de uso y eficiencia de un volumen VDO.

Requisitos previos

Procedimiento

  • Utilice la utilidad vdostats para obtener información sobre un volumen VDO:

    # vdostats --human-readable
    
    Device                   1K-blocks    Used     Available    Use%    Space saving%
    /dev/mapper/node1osd1    926.5G       21.0G    905.5G       2%      73%
    /dev/mapper/node1osd2    926.5G       28.2G    898.3G       3%      64%

Recursos adicionales

  • La página de manual vdostats(8).

2.1.4. Recuperación de espacio para VDO en los sistemas de archivos

Este procedimiento recupera el espacio de almacenamiento en un volumen VDO que alberga un sistema de archivos.

VDO no puede recuperar espacio a menos que los sistemas de archivos comuniquen que los bloques están libres utilizando los comandos DISCARD, TRIM, o UNMAP.

Procedimiento

  • Si el sistema de archivos de su volumen VDO admite operaciones de descarte, habilítelas. Consulte Capítulo 5, Descartar los bloques no utilizados.
  • Para los sistemas de archivos que no utilizan DISCARD, TRIM, o UNMAP, puede recuperar manualmente el espacio libre. Almacene un archivo compuesto por ceros binarios para llenar el espacio libre y luego elimine ese archivo.

2.1.5. Recuperación de espacio para VDO sin sistema de archivos

Este procedimiento recupera el espacio de almacenamiento en un volumen VDO que se utiliza como destino de almacenamiento en bloque sin un sistema de archivos.

Procedimiento

  • Utilice la utilidad blkdiscard.

    Por ejemplo, un único volumen VDO puede dividirse en múltiples subvolúmenes desplegando LVM sobre él. Antes de desaprovisionar un volumen lógico, utilice la utilidad blkdiscard para liberar el espacio utilizado previamente por ese volumen lógico.

    LVM soporta el comando REQ_DISCARD y reenvía las peticiones a VDO en las direcciones lógicas de bloque apropiadas para liberar el espacio. Si se utilizan otros gestores de volumen, también deben soportar REQ_DISCARD, o, de forma equivalente, UNMAP para dispositivos SCSI o TRIM para dispositivos ATA.

Recursos adicionales

  • La página de manual blkdiscard(8)

2.1.6. Recuperación de espacio para VDO en la red Fibre Channel o Ethernet

Este procedimiento reclama el espacio de almacenamiento en volúmenes VDO (o partes de volúmenes) que se aprovisionan a los hosts en una estructura de almacenamiento de canal de fibra o una red Ethernet utilizando marcos de destino SCSI como LIO o SCST.

Procedimiento

  • Los iniciadores SCSI pueden utilizar el comando UNMAP para liberar espacio en los objetivos de almacenamiento con aprovisionamiento ligero, pero el marco del objetivo SCSI necesita ser configurado para anunciar el soporte de este comando. Esto se hace normalmente habilitando el aprovisionamiento ligero en estos volúmenes.

    Verifique la compatibilidad con UNMAP en los iniciadores SCSI basados en Linux ejecutando el siguiente comando:

    # sg_vpd --page=0xb0 /dev/device

    En la salida, verifique que el valor de Maximum unmap LBA count es mayor que cero.

2.2. Iniciar o detener los volúmenes de VDO

Puede iniciar o detener un volumen VDO determinado, o todos los volúmenes VDO, y sus índices UDS asociados.

2.2.1. Inició y activó los volúmenes de VDO

Durante el arranque del sistema, la unidad vdo systemd automáticamente starts todos los dispositivos VDO que estén configurados como activated.

La unidad vdo systemd se instala y habilita por defecto cuando se instala el paquete vdo. Esta unidad ejecuta automáticamente el comando vdo start --all al iniciar el sistema para que aparezcan todos los volúmenes VDO activados.

También puede crear un volumen VDO que no se inicie automáticamente añadiendo la opción --activate=disabled al comando vdo create.

El orden de salida

Algunos sistemas pueden colocar los volúmenes LVM tanto por encima de los volúmenes VDO como por debajo de ellos. En estos sistemas, es necesario iniciar los servicios en el orden correcto:

  1. La capa inferior de LVM debe iniciarse primero. En la mayoría de los sistemas, el inicio de esta capa se configura automáticamente cuando se instala el paquete LVM.
  2. La unidad vdo systemd debe arrancar entonces.
  3. Por último, deben ejecutarse scripts adicionales para iniciar volúmenes LVM u otros servicios sobre los volúmenes VDO en ejecución.

El tiempo que tarda en detenerse un volumen

Detener un volumen VDO lleva un tiempo basado en la velocidad de su dispositivo de almacenamiento y la cantidad de datos que el volumen necesita escribir:

  • El volumen siempre escribe alrededor de 1GiB por cada 1GiB del índice UDS.
  • El volumen escribe adicionalmente la cantidad de datos equivalente al tamaño de la caché del mapa de bloques más hasta 8MiB por losa.
  • El volumen debe terminar de procesar todas las solicitudes de E/S pendientes.

2.2.2. Iniciar un volumen VDO

Este procedimiento inicia un volumen VDO determinado o todos los volúmenes VDO de su sistema.

Procedimiento

  • Para iniciar un determinado volumen VDO, utilice:

    # vdo start --name=my-vdo
  • Para iniciar todos los volúmenes VDO, utilice:

    # vdo start --all

Recursos adicionales

  • La página de manual vdo(8)

2.2.3. Detener un volumen VDO

Este procedimiento detiene un volumen VDO determinado o todos los volúmenes VDO de su sistema.

Procedimiento

  1. Detener el volumen.

    • Para detener un determinado volumen VDO, utilice:

      # vdo stop --name=my-vdo
    • Para detener todos los volúmenes VDO, utilice:

      # vdo stop --all
  2. Espere a que el volumen termine de escribir datos en el disco.

Recursos adicionales

  • La página de manual vdo(8)

2.3. Inicio automático de los volúmenes VDO en el arranque del sistema

Puede configurar los volúmenes VDO para que se inicien automáticamente al arrancar el sistema. También puede desactivar el inicio automático.

2.3.1. Inició y activó los volúmenes de VDO

Durante el arranque del sistema, la unidad vdo systemd automáticamente starts todos los dispositivos VDO que estén configurados como activated.

La unidad vdo systemd se instala y habilita por defecto cuando se instala el paquete vdo. Esta unidad ejecuta automáticamente el comando vdo start --all al iniciar el sistema para que aparezcan todos los volúmenes VDO activados.

También puede crear un volumen VDO que no se inicie automáticamente añadiendo la opción --activate=disabled al comando vdo create.

El orden de salida

Algunos sistemas pueden colocar los volúmenes LVM tanto por encima de los volúmenes VDO como por debajo de ellos. En estos sistemas, es necesario iniciar los servicios en el orden correcto:

  1. La capa inferior de LVM debe iniciarse primero. En la mayoría de los sistemas, el inicio de esta capa se configura automáticamente cuando se instala el paquete LVM.
  2. La unidad vdo systemd debe arrancar entonces.
  3. Por último, deben ejecutarse scripts adicionales para iniciar volúmenes LVM u otros servicios sobre los volúmenes VDO en ejecución.

El tiempo que tarda en detenerse un volumen

Detener un volumen VDO lleva un tiempo basado en la velocidad de su dispositivo de almacenamiento y la cantidad de datos que el volumen necesita escribir:

  • El volumen siempre escribe alrededor de 1GiB por cada 1GiB del índice UDS.
  • El volumen escribe adicionalmente la cantidad de datos equivalente al tamaño de la caché del mapa de bloques más hasta 8MiB por losa.
  • El volumen debe terminar de procesar todas las solicitudes de E/S pendientes.

2.3.2. Activación de un volumen VDO

Este procedimiento activa un volumen VDO para que se ponga en marcha automáticamente.

Procedimiento

  • Para activar un volumen específico:

    # vdo activate --name=my-vdo
  • Para activar todos los volúmenes:

    # vdo activate --all

Recursos adicionales

  • La página de manual vdo(8)

2.3.3. Desactivación de un volumen VDO

Este procedimiento desactiva un volumen VDO para evitar que se inicie automáticamente.

Procedimiento

  • Para desactivar un volumen específico:

    # vdo deactivate --name=my-vdo
  • Para desactivar todos los volúmenes:

    # vdo deactivate --all

Recursos adicionales

  • La página de manual vdo(8)

2.4. Selección de un modo de escritura VDO

Puede configurar el modo de escritura para un volumen VDO, basándose en lo que requiere el dispositivo de bloque subyacente. Por defecto, VDO selecciona el modo de escritura automáticamente.

2.4.1. Modos de escritura VDO

VDO admite los siguientes modos de escritura:

sync

Cuando VDO está en modo sync, las capas por encima de él asumen que un comando de escritura escribe datos en el almacenamiento persistente. Como resultado, no es necesario que el sistema de archivos o la aplicación, por ejemplo, emitan solicitudes FLUSH o de acceso forzado a la unidad (FUA) para hacer que los datos se vuelvan persistentes en los puntos críticos.

VDO debe estar en modo sync sólo cuando el almacenamiento subyacente garantiza que los datos se escriben en el almacenamiento persistente cuando el comando de escritura se completa. Es decir, el almacenamiento no debe tener una caché de escritura volátil, o debe tener una caché de escritura.

async

Cuando VDO está en modo async, VDO no garantiza que los datos se escriban en el almacenamiento persistente cuando se reconoce un comando de escritura. El sistema de archivos o la aplicación deben emitir peticiones FLUSH o FUA para asegurar la persistencia de los datos en los puntos críticos de cada transacción.

VDO debe estar configurado en el modo async si el almacenamiento subyacente no garantiza que los datos se escriban en el almacenamiento persistente cuando el comando de escritura se completa; es decir, cuando el almacenamiento tiene una caché de escritura volátil.

async-unsafe

Este modo tiene las mismas propiedades que async pero no cumple con Atomicidad, Consistencia, Aislamiento, Durabilidad (ACID). En comparación con async, async-unsafe tiene un mejor rendimiento.

Aviso

Cuando una aplicación o un sistema de archivos que asume el cumplimiento de ACID opera sobre el volumen VDO, el modo async-unsafe podría causar una pérdida de datos inesperada.

auto
El modo auto selecciona automáticamente sync o async en función de las características de cada dispositivo. Esta es la opción por defecto.

2.4.2. El procesamiento interno de los modos de escritura VDO

Esta sección proporciona detalles sobre el funcionamiento de los modos de escritura sync y async VDO.

Si el módulo kvdo funciona en modo síncrono:

  1. Escribe temporalmente los datos de la solicitud en el bloque asignado y luego acusa recibo de la solicitud.
  2. Una vez completado el acuse de recibo, se intenta desduplicar el bloque calculando una firma MurmurHash-3 de los datos del bloque, que se envía al índice VDO.
  3. Si el índice VDO contiene una entrada para un bloque con la misma firma, kvdo lee el bloque indicado y hace una comparación byte a byte de los dos bloques para verificar que son idénticos.
  4. Si efectivamente son idénticos, entonces kvdo actualiza su mapa de bloques para que el bloque lógico apunte al bloque físico correspondiente y libera el bloque físico asignado.
  5. Si el índice VDO no contiene una entrada para la firma del bloque que se está escribiendo, o el bloque indicado no contiene realmente los mismos datos, kvdo actualiza su mapa de bloques para hacer permanente el bloque físico temporal.

Si kvdo funciona en modo asíncrono:

  1. En lugar de escribir los datos, acusará inmediatamente recibo de la solicitud.
  2. A continuación, intentará desduplicar el bloque de la misma manera que se ha descrito anteriormente.
  3. Si el bloque resulta ser un duplicado, kvdo actualiza su mapa de bloques y libera el bloque asignado. En caso contrario, escribe los datos de la solicitud en el bloque asignado y actualiza el mapa de bloques para que el bloque físico sea permanente.

2.4.3. Comprobación del modo de escritura en un volumen VDO

Este procedimiento muestra el modo de escritura activo en un volumen VDO seleccionado.

Procedimiento

  • Utilice el siguiente comando para ver el modo de escritura utilizado por un volumen VDO:

    # vdo status --name=my-vdo

    La lista de salida:

    • El configured write policy, que es la opción seleccionada entre sync, async, o auto
    • El write policy, que es el modo de escritura particular que VDO aplicó, es decir sync o async

2.4.4. Comprobación de un caché volátil

Este procedimiento determina si un dispositivo de bloque tiene una caché volátil o no. Puede utilizar la información para elegir entre los modos de escritura sync y async VDO.

Procedimiento

  1. Utilice cualquiera de los siguientes métodos para determinar si un dispositivo tiene una caché de escritura:

    • Lea el /sys/block/block-device/device/scsi_disk/identifier/cache_type sysfs archivo. Por ejemplo:

      $ cat '/sys/block/sda/device/scsi_disk/7:0:0:0/cache_type'
      
      write back
      $ cat '/sys/block/sdb/device/scsi_disk/1:2:0:0/cache_type'
      
      None
    • Alternativamente, puede encontrar si los dispositivos mencionados anteriormente tienen una caché de escritura o no en el registro de arranque del kernel:

      sd 7:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
      sd 1:2:0:0: [sdb] Write cache: disabled, read cache: disabled, supports DPO and FUA
  2. En los ejemplos anteriores:

    • El dispositivo sda indica que has es una caché de escritura. Utilice el modo async para ello.
    • El dispositivo sdb indica que does not have es una caché de escritura. Utilice el modo sync para ello.

    Debe configurar VDO para utilizar el modo de escritura sync si el valor de cache_type es None o write through.

2.4.5. Configurar un modo de escritura VDO

Este procedimiento establece un modo de escritura para un volumen VDO, ya sea para uno existente o al crear un nuevo volumen.

Importante

El uso de un modo de escritura incorrecto puede provocar la pérdida de datos después de un fallo de alimentación, una caída del sistema o cualquier pérdida inesperada de contacto con el disco.

Requisitos previos

Procedimiento

  • Puedes establecer un modo de escritura tanto en un volumen VDO existente como al crear un nuevo volumen:

    • Para modificar un volumen VDO existente, utilice:

      # vdo changeWritePolicy --writePolicy=sync|async|async-unsafe|auto \
                              --name=vdo-name
    • Para especificar un modo de escritura al crear un volumen VDO, añada la opción --writePolicy=sync|async|async-unsafe|auto al comando vdo create.

2.5. Recuperación de un volumen VDO después de un cierre sucio

Puede recuperar un volumen VDO después de un apagado no limpio para que pueda seguir funcionando. La tarea es en su mayoría automatizada. Además, puede limpiar después de que un volumen VDO se haya creado sin éxito debido a un fallo en el proceso.

2.5.1. Modos de escritura VDO

VDO admite los siguientes modos de escritura:

sync

Cuando VDO está en modo sync, las capas por encima de él asumen que un comando de escritura escribe datos en el almacenamiento persistente. Como resultado, no es necesario que el sistema de archivos o la aplicación, por ejemplo, emitan solicitudes FLUSH o de acceso forzado a la unidad (FUA) para hacer que los datos se vuelvan persistentes en los puntos críticos.

VDO debe estar en modo sync sólo cuando el almacenamiento subyacente garantiza que los datos se escriben en el almacenamiento persistente cuando el comando de escritura se completa. Es decir, el almacenamiento no debe tener una caché de escritura volátil, o debe tener una caché de escritura.

async

Cuando VDO está en modo async, VDO no garantiza que los datos se escriban en el almacenamiento persistente cuando se reconoce un comando de escritura. El sistema de archivos o la aplicación deben emitir peticiones FLUSH o FUA para asegurar la persistencia de los datos en los puntos críticos de cada transacción.

VDO debe estar configurado en el modo async si el almacenamiento subyacente no garantiza que los datos se escriban en el almacenamiento persistente cuando el comando de escritura se completa; es decir, cuando el almacenamiento tiene una caché de escritura volátil.

async-unsafe

Este modo tiene las mismas propiedades que async pero no cumple con Atomicidad, Consistencia, Aislamiento, Durabilidad (ACID). En comparación con async, async-unsafe tiene un mejor rendimiento.

Aviso

Cuando una aplicación o un sistema de archivos que asume el cumplimiento de ACID opera sobre el volumen VDO, el modo async-unsafe podría causar una pérdida de datos inesperada.

auto
El modo auto selecciona automáticamente sync o async en función de las características de cada dispositivo. Esta es la opción por defecto.

2.5.2. Recuperación de volumen VDO

Cuando un volumen VDO se reinicia después de un apagado no limpio, VDO realiza las siguientes acciones:

  • Verifica la consistencia de los metadatos en el volumen.
  • Reconstruye una parte de los metadatos para repararlos si es necesario.

Las reconstrucciones son automáticas y no requieren la intervención del usuario.

VDO puede reconstruir diferentes escrituras dependiendo del modo de escritura activo:

sync
Si VDO se ejecutaba en un almacenamiento síncrono y la política de escritura estaba establecida en sync, todos los datos escritos en el volumen se recuperan completamente.
async
Si la política de escritura era async, algunas escrituras podrían no ser recuperadas si no se hicieron duraderas. Esto se hace enviando a VDO un comando FLUSH o una E/S de escritura etiquetada con la bandera FUA (forzar acceso a la unidad). Puede lograr esto desde el modo de usuario invocando una operación de integridad de datos como fsync, fdatasync, sync, o umount.

En cualquiera de los dos modos, algunas escrituras que no fueron reconocidas o que no fueron seguidas de una descarga también podrían ser reconstruidas.

Recuperación automática y manual

Cuando un volumen VDO entra en el modo de funcionamiento recovering, VDO reconstruye automáticamente el volumen VDO sucio cuando vuelve a estar en línea. Esto se llama online recovery.

Si VDO no puede recuperar un volumen VDO con éxito, coloca el volumen en el modo de funcionamiento read-only que persiste a través de los reinicios del volumen. Es necesario arreglar el problema manualmente forzando una reconstrucción.

Recursos adicionales

2.5.3. Modos de funcionamiento de VDO

Esta sección describe los modos que indican si un volumen VDO está funcionando normalmente o se está recuperando de un error.

Puede mostrar el modo de funcionamiento actual de un volumen VDO mediante el comando vdostats --verbose device comando. Consulte el atributo Operating mode en la salida.

normal
Este es el modo de funcionamiento por defecto. Los volúmenes VDO están siempre en modo normal, a menos que alguno de los siguientes estados fuerce un modo diferente. Un volumen VDO recién creado se inicia en modo normal.
recovering

Cuando un volumen VDO no guarda todos sus metadatos antes de apagarse, entra automáticamente en el modo recovering la próxima vez que se inicie. Las razones típicas para entrar en este modo son la pérdida repentina de energía o un problema del dispositivo de almacenamiento subyacente.

En el modo recovering, VDO está fijando los recuentos de referencias para cada bloque físico de datos en el dispositivo. La recuperación no suele llevar mucho tiempo. El tiempo depende de lo grande que sea el volumen VDO, de lo rápido que sea el dispositivo de almacenamiento subyacente y de cuántas otras peticiones esté gestionando VDO simultáneamente. El volumen VDO funciona normalmente con las siguientes excepciones:

  • Al principio, la cantidad de espacio disponible para las solicitudes de escritura en el volumen puede ser limitada. A medida que se recuperan más metadatos, se dispone de más espacio libre.
  • Los datos escritos mientras el volumen VDO se está recuperando pueden fallar en la deduplicación contra los datos escritos antes de la caída si esos datos están en una porción del volumen que aún no se ha recuperado. VDO puede comprimir los datos mientras se recupera el volumen. Todavía puede leer o sobrescribir bloques comprimidos.
  • Durante una recuperación en línea, algunas estadísticas no están disponibles: por ejemplo, blocks in use y blocks free. Estas estadísticas estarán disponibles cuando se complete la reconstrucción.
  • Los tiempos de respuesta para las lecturas y escrituras podrían ser más lentos de lo habitual debido a los trabajos de recuperación en curso

Puede apagar el volumen VDO de forma segura en el modo recovering. Si la recuperación no finaliza antes del apagado, el dispositivo vuelve a entrar en el modo recovering la próxima vez que se inicie.

El volumen VDO sale automáticamente del modo recovering y pasa al modo normal cuando ha fijado todos los recuentos de referencia. No es necesaria ninguna acción del administrador. Para más detalles, consulte Sección 2.5.4, “Recuperación de un volumen VDO en línea”.

read-only

Cuando un volumen VDO encuentra un error interno fatal, entra en modo read-only. Los eventos que pueden causar el modo read-only incluyen la corrupción de metadatos o que el dispositivo de almacenamiento de respaldo se vuelva de sólo lectura. Este modo es un estado de error.

En el modo read-only, las lecturas de datos funcionan normalmente pero las escrituras de datos siempre fallan. El volumen VDO permanece en modo read-only hasta que un administrador solucione el problema.

Puede apagar con seguridad un volumen VDO en modo read-only. El modo normalmente persiste después de reiniciar el volumen VDO. En raros casos, el volumen VDO no es capaz de grabar el estado read-only en el dispositivo de almacenamiento de respaldo. En estos casos, VDO intenta hacer una recuperación en su lugar.

Una vez que un volumen está en modo de sólo lectura, no hay garantía de que los datos del volumen no se hayan perdido o corrompido. En estos casos, Red Hat recomienda copiar los datos fuera del volumen de sólo lectura y posiblemente restaurar el volumen desde una copia de seguridad.

Si el riesgo de corrupción de datos es aceptable, es posible forzar una reconstrucción fuera de línea de los metadatos del volumen VDO para que el volumen pueda volver a estar en línea y disponible. No se puede garantizar la integridad de los datos reconstruidos. Para más detalles, consulte Sección 2.5.5, “Forzar una reconstrucción fuera de línea de los metadatos de un volumen VDO”.

2.5.4. Recuperación de un volumen VDO en línea

Este procedimiento realiza una recuperación en línea en un volumen VDO para recuperar los metadatos después de un cierre sucio.

Procedimiento

  1. Si el volumen VDO no está ya iniciado, inícielo:

    # vdo start --name=my-vdo

    No son necesarios pasos adicionales. La recuperación se ejecuta en segundo plano.

  2. Si confía en estadísticas de volumen como blocks in use y blocks free, espere a que estén disponibles.

2.5.5. Forzar una reconstrucción fuera de línea de los metadatos de un volumen VDO

Este procedimiento realiza una reconstrucción forzada fuera de línea de los metadatos de un volumen VDO para recuperarse después de un cierre sucio.

Aviso

Este procedimiento podría causar la pérdida de datos en el volumen.

Requisitos previos

  • Se inicia el volumen VDO.

Procedimiento

  1. Comprueba si el volumen está en modo de sólo lectura. Consulte el atributo operating mode en la salida del comando:

    # vdo status --name=my-vdo

    Si el volumen no está en modo de sólo lectura, no es necesario forzar una reconstrucción fuera de línea. Realice una recuperación en línea como se describe en Sección 2.5.4, “Recuperación de un volumen VDO en línea”.

  2. Detenga el volumen si está en funcionamiento:

    # vdo stop --name=my-vdo
  3. Reinicie el volumen con la opción --forceRebuild:

    # vdo start --name=my-vdo --forceRebuild

2.5.6. Eliminación de un volumen VDO creado sin éxito

Este procedimiento limpia un volumen VDO en un estado intermedio. Un volumen queda en un estado intermedio si se produce un fallo al crear el volumen. Esto puede ocurrir cuando, por ejemplo:

  • El sistema se bloquea
  • El poder falla
  • El administrador interrumpe un comando vdo create en ejecución

Procedimiento

  • Para limpiar, elimine el volumen creado sin éxito con la opción --force:

    # vdo remove --force --name=my-vdo

    La opción --force es necesaria porque el administrador podría haber causado un conflicto al cambiar la configuración del sistema desde que se creó el volumen sin éxito.

    Sin la opción --force, el comando vdo remove falla con el siguiente mensaje:

    [...]
    A previous operation failed.
    Recovery from the failure either failed or was interrupted.
    Add '--force' to 'remove' to perform the following cleanup.
    Steps to clean up VDO my-vdo:
    umount -f /dev/mapper/my-vdo
    udevadm settle
    dmsetup remove my-vdo
    vdo: ERROR - VDO volume my-vdo previous operation (create) is incomplete

2.6. Optimización del índice UDS

Puede configurar ciertos ajustes del índice UDS para optimizarlo en su sistema.

Importante

No se pueden cambiar las propiedades del índice UDS after creando el volumen VDO.

2.6.1. Componentes de un volumen VDO

VDO utiliza un dispositivo de bloque como almacén de respaldo, que puede incluir una agregación de almacenamiento físico consistente en uno o más discos, particiones o incluso archivos planos. Cuando una herramienta de gestión de almacenamiento crea un volumen VDO, VDO reserva espacio de volumen para el índice UDS y el volumen VDO. El índice UDS y el volumen VDO interactúan juntos para proporcionar almacenamiento de bloques deduplicado.

Figura 2.2. Organización del disco VDO

VDO disk organization

La solución de VDO consta de los siguientes componentes:

kvdo

Un módulo del kernel que se carga en la capa de Linux Device Mapper proporciona un volumen de almacenamiento en bloque deduplicado, comprimido y con aprovisionamiento ligero.

El módulo kvdo expone un dispositivo de bloque. Puede acceder a este dispositivo de bloque directamente para el almacenamiento en bloque o presentarlo a través de un sistema de archivos Linux, como XFS o ext4.

Cuando kvdo recibe una solicitud para leer un bloque lógico de datos de un volumen VDO, mapea el bloque lógico solicitado al bloque físico subyacente y luego lee y devuelve los datos solicitados.

Cuando kvdo recibe una solicitud para escribir un bloque de datos en un volumen VDO, primero comprueba si la solicitud es una petición de DISCARD o TRIM o si los datos son uniformemente cero. Si cualquiera de estas condiciones es verdadera, kvdo actualiza su mapa de bloques y reconoce la solicitud. En caso contrario, VDO procesa y optimiza los datos.

uds

Un módulo del núcleo que se comunica con el índice del Servicio Universal de Deduplicación (UDS) en el volumen y analiza los datos en busca de duplicados. Para cada nueva pieza de datos, UDS determina rápidamente si esa pieza es idéntica a cualquier pieza de datos almacenada previamente. Si el índice encuentra una coincidencia, el sistema de almacenamiento puede entonces referenciar internamente el elemento existente para evitar almacenar la misma información más de una vez.

El índice UDS se ejecuta dentro del núcleo como el módulo del núcleo uds.

Herramientas de línea de comandos
Para configurar y gestionar el almacenamiento optimizado.

2.6.2. El índice UDS

VDO utiliza un índice de deduplicación de alto rendimiento llamado UDS para detectar bloques de datos duplicados mientras se almacenan.

El índice UDS constituye la base del producto VDO. Para cada nuevo dato, determina rápidamente si ese dato es idéntico a cualquier dato almacenado anteriormente. Si el índice encuentra una coincidencia, el sistema de almacenamiento puede entonces referenciar internamente el elemento existente para evitar almacenar la misma información más de una vez.

El índice UDS se ejecuta dentro del núcleo como el módulo del núcleo uds.

El deduplication window es el número de bloques escritos previamente que el índice recuerda. El tamaño de la ventana de deduplicación es configurable. Para un tamaño de ventana determinado, el índice requiere una cantidad específica de memoria RAM y una cantidad específica de espacio en disco. El tamaño de la ventana suele determinarse especificando el tamaño de la memoria del índice mediante la opción --indexMem=size. VDO determina entonces la cantidad de espacio en disco a utilizar automáticamente.

El índice UDS consta de dos partes:

  • En la memoria se utiliza una representación compacta que contiene como máximo una entrada por bloque único.
  • Un componente en el disco que registra los nombres de los bloques asociados presentados al índice a medida que se producen, en orden.

UDS utiliza una media de 4 bytes por entrada en memoria, incluyendo la caché.

El componente on-disk mantiene un historial acotado de los datos pasados a UDS. UDS proporciona consejos de deduplicación para los datos que caen dentro de esta ventana de deduplicación, conteniendo los nombres de los bloques vistos más recientemente. La ventana de deduplicación permite a UDS indexar los datos de la forma más eficiente posible, limitando al mismo tiempo la cantidad de memoria necesaria para indexar grandes depósitos de datos. A pesar de la naturaleza limitada de la ventana de deduplicación, la mayoría de los conjuntos de datos que tienen altos niveles de deduplicación también muestran un alto grado de localidad temporal - en otras palabras, la mayor parte de la deduplicación ocurre entre conjuntos de bloques que fueron escritos aproximadamente al mismo tiempo. Además, en general, es más probable que los datos que se escriben dupliquen los que se escribieron recientemente que los que se escribieron hace mucho tiempo. Por lo tanto, para una carga de trabajo determinada en un intervalo de tiempo determinado, los índices de deduplicación serán a menudo los mismos si UDS indexa sólo los datos más recientes o todos los datos.

Dado que los datos duplicados tienden a mostrar una localización temporal, rara vez es necesario indexar cada bloque en el sistema de almacenamiento. Si no fuera así, el coste de la memoria de los índices superaría el ahorro de los costes de almacenamiento derivados de la deduplicación. Los requisitos de tamaño de los índices están más relacionados con la tasa de ingestión de datos. Por ejemplo, consideremos un sistema de almacenamiento con 100 TB de capacidad total pero con una tasa de ingestión de 1 TB por semana. Con una ventana de deduplicación de 4 TB, UDS puede detectar la mayor parte de la redundancia entre los datos escritos en el último mes.

2.7. Activar o desactivar la deduplicación en VDO

En algunos casos, es posible que desee desactivar temporalmente la deduplicación de los datos que se están escribiendo en un volumen VDO mientras se mantiene la capacidad de leer y escribir en el volumen. Desactivar la deduplicación impide que las escrituras posteriores se dedupliquen, pero los datos que ya estaban deduplicados siguen estándolo.

2.7.1. Deduplicación en VDO

La deduplicación es una técnica para reducir el consumo de recursos de almacenamiento mediante la eliminación de múltiples copias de bloques duplicados.

En lugar de escribir los mismos datos más de una vez, VDO detecta cada bloque duplicado y lo registra como una referencia al bloque original. VDO mantiene un mapeo de las direcciones lógicas de bloque, que son utilizadas por la capa de almacenamiento por encima de VDO, a las direcciones físicas de bloque, que son utilizadas por la capa de almacenamiento por debajo de VDO.

Después de la deduplicación, se pueden asignar múltiples direcciones de bloques lógicos a la misma dirección de bloque físico. Estos se denominan bloques compartidos. La compartición de bloques es invisible para los usuarios del almacenamiento, que leen y escriben bloques como lo harían si VDO no estuviera presente.

Cuando se sobrescribe un bloque compartido, VDO asigna un nuevo bloque físico para almacenar los datos del nuevo bloque, para garantizar que no se modifiquen otras direcciones de bloques lógicos que están asignadas al bloque físico compartido.

2.7.2. Activación de la deduplicación en un volumen VDO

Este procedimiento reinicia el índice UDS asociado e informa al volumen VDO de que la deduplicación vuelve a estar activa.

Nota

La deduplicación está activada por defecto.

Procedimiento

  • Para reiniciar la deduplicación en un volumen VDO, utilice el siguiente comando:

    # vdo enableDeduplication --name=my-vdo

2.7.3. Desactivación de la deduplicación en un volumen VDO

Este procedimiento detiene el índice UDS asociado e informa al volumen VDO de que la deduplicación ya no está activa.

Procedimiento

  • Para detener la deduplicación en un volumen VDO, utilice el siguiente comando:

    # vdo disableDeduplication --name=my-vdo
  • También puede desactivar la deduplicación al crear un nuevo volumen VDO añadiendo la opción --deduplication=disabled al comando vdo create.

2.8. Activar o desactivar la compresión en VDO

VDO proporciona compresión de datos. Puede desactivarla para maximizar el rendimiento o para acelerar el procesamiento de datos que probablemente no se compriman, o volver a activarla para aumentar el ahorro de espacio.

2.8.1. Compresión en VDO

Además de la deduplicación a nivel de bloque, VDO también proporciona compresión en línea a nivel de bloque utilizando la tecnología HIOPS Compression™.

La compresión de volumen VDO está activada por defecto.

Mientras que la deduplicación es la solución óptima para entornos de máquinas virtuales y aplicaciones de copia de seguridad, la compresión funciona muy bien con formatos de archivo estructurados y no estructurados que no suelen presentar redundancia a nivel de bloque, como los archivos de registro y las bases de datos.

La compresión opera sobre bloques que no han sido identificados como duplicados. Cuando VDO ve datos únicos por primera vez, los comprime. Las copias posteriores de los datos que ya han sido almacenados se deduplican sin requerir un paso adicional de compresión.

La función de compresión se basa en un algoritmo de empaquetamiento paralelizado que permite manejar muchas operaciones de compresión a la vez. Después de almacenar primero el bloque y responder al solicitante, un algoritmo de empaquetamiento de mejor ajuste encuentra múltiples bloques que, cuando se comprimen, pueden caber en un solo bloque físico. Cuando se determina que es improbable que un bloque físico concreto contenga más bloques comprimidos, se escribe en el almacenamiento y los bloques no comprimidos se liberan y se reutilizan.

Al realizar las operaciones de compresión y empaquetado después de haber respondido al solicitante, el uso de la compresión impone una penalización de latencia mínima.

2.8.2. Activación de la compresión en un volumen VDO

Este procedimiento permite la compresión en un volumen VDO para aumentar el ahorro de espacio.

Nota

La compresión está activada por defecto.

Procedimiento

  • Para iniciarlo de nuevo, utilice el siguiente comando:

    # vdo enableCompression --name=my-vdo

2.8.3. Desactivación de la compresión en un volumen VDO

Este procedimiento detiene la compresión en un volumen VDO para maximizar el rendimiento o para acelerar el procesamiento de datos que probablemente no se compriman.

Procedimiento

  • Para detener la compresión en un volumen VDO existente, utilice el siguiente comando:

    # vdo disableCompression --name=my-vdo
  • Como alternativa, puede desactivar la compresión añadiendo la opción --compression=disabled al comando vdo create cuando cree un nuevo volumen.

2.9. Aumentar el tamaño de un volumen VDO

Puede aumentar el tamaño físico de un volumen VDO para utilizar más capacidad de almacenamiento subyacente, o el tamaño lógico para proporcionar más capacidad en el volumen.

2.9.1. El tamaño físico y lógico de un volumen VDO

Esta sección describe el tamaño físico, el tamaño físico disponible y el tamaño lógico que puede utilizar VDO:

Tamaño físico

Este es el mismo tamaño que el dispositivo de bloque subyacente. VDO utiliza este almacenamiento para:

  • Los datos de los usuarios, que pueden estar deduplicados y comprimidos
  • Metadatos VDO, como el índice UDS
Tamaño físico disponible

Es la parte del tamaño físico que VDO puede utilizar para los datos del usuario

Equivale al tamaño físico menos el tamaño de los metadatos, menos el resto tras dividir el volumen en losas por el tamaño de losa dado.

Tamaño lógico

Es el tamaño provisionado que el volumen VDO presenta a las aplicaciones. Normalmente es mayor que el tamaño físico disponible. Si no se especifica la opción --vdoLogicalSize, entonces el aprovisionamiento del volumen lógico se aprovisiona en una proporción de 1:1. Por ejemplo, si se coloca un volumen VDO sobre un dispositivo de bloques de 20 GB, entonces se reservan 2,5 GB para el índice UDS (si se utiliza el tamaño de índice por defecto). Los 17,5 GB restantes se destinan a los metadatos de VDO y a los datos del usuario. Como resultado, el almacenamiento disponible para consumir no es más de 17,5 GB, y puede ser menos debido a los metadatos que componen el volumen VDO real.

Actualmente, VDO admite cualquier tamaño lógico hasta 254 veces el tamaño del volumen físico, con un tamaño lógico máximo absoluto de 4PB.

Figura 2.3. Organización del disco VDO

VDO disk organization

En esta figura, el objetivo de almacenamiento deduplicado VDO se sitúa completamente sobre el dispositivo de bloque, lo que significa que el tamaño físico del volumen VDO es del mismo tamaño que el dispositivo de bloque subyacente.

Recursos adicionales

2.9.2. Aprovisionamiento ligero en VDO

VDO es un objetivo de almacenamiento en bloque con aprovisionamiento ligero. La cantidad de espacio físico que utiliza un volumen VDO puede diferir del tamaño del volumen que se presenta a los usuarios del almacenamiento. Puede aprovechar esta disparidad para ahorrar en costes de almacenamiento.

Condiciones fuera del espacio

Tenga cuidado para evitar quedarse sin espacio de almacenamiento de forma inesperada, si los datos escritos no alcanzan la tasa de optimización esperada.

Cuando el número de bloques lógicos (almacenamiento virtual) supera el número de bloques físicos (almacenamiento real), es posible que los sistemas de archivos y las aplicaciones se queden inesperadamente sin espacio. Por esta razón, los sistemas de almacenamiento que utilizan VDO deben proporcionarle una forma de controlar el tamaño del pool libre en el volumen VDO.

Puede determinar el tamaño de este pool libre utilizando la utilidad vdostats. La salida por defecto de esta utilidad lista la información de todos los volúmenes VDO en ejecución en un formato similar al de la utilidad de Linux df. Por ejemplo:

Device                1K-blocks   Used        Available   Use%
/dev/mapper/vdo-name  211812352   105906176   105906176   50%

Cuando la capacidad de almacenamiento físico de un volumen VDO está casi llena, VDO informa de una advertencia en el registro del sistema, similar a la siguiente:

Oct  2 17:13:39 system lvm[13863]: Monitoring VDO pool vdo-name.
Oct  2 17:27:39 system lvm[13863]: WARNING: VDO pool vdo-name is now 80.69% full.
Oct  2 17:28:19 system lvm[13863]: WARNING: VDO pool vdo-name is now 85.25% full.
Oct  2 17:29:39 system lvm[13863]: WARNING: VDO pool vdo-name is now 90.64% full.
Oct  2 17:30:29 system lvm[13863]: WARNING: VDO pool vdo-name is now 96.07% full.
Nota

Estos mensajes de advertencia sólo aparecen cuando el servicio lvm2-monitor está en funcionamiento. Está activado por defecto.

Cómo prevenir las condiciones de fuera del espacio

Si el tamaño de la piscina libre desciende por debajo de un determinado nivel, puedes actuar:

  • Eliminación de datos. Esto recupera espacio siempre que los datos borrados no se dupliquen. El borrado de datos libera el espacio sólo después de los descartes.
  • Añadir almacenamiento físico
Importante

Supervise el espacio físico en sus volúmenes VDO para evitar situaciones de falta de espacio. Quedarse sin bloques físicos podría resultar en la pérdida de datos recientemente escritos y no reconocidos en el volumen VDO.

Aprovisionamiento delgado y los comandos TRIM y DISCARD

Para beneficiarse del ahorro de almacenamiento que supone el thin provisioning, la capa de almacenamiento físico necesita saber cuándo se eliminan los datos. Los sistemas de archivos que trabajan con el almacenamiento thinly provisioned envían comandos TRIM o DISCARD para informar al sistema de almacenamiento cuando un bloque lógico ya no es necesario.

Existen varios métodos para enviar los comandos TRIM o DISCARD:

  • Con la opción de montaje discard, los sistemas de archivos pueden enviar estos comandos cada vez que se elimina un bloque.
  • Puede enviar los comandos de forma controlada utilizando utilidades como fstrim. Estas utilidades le dicen al sistema de archivos que detecte los bloques lógicos que no se utilizan y que envíe la información al sistema de almacenamiento en forma de comando TRIM o DISCARD.

La necesidad de utilizar TRIM o DISCARD en los bloques no utilizados no es exclusiva de VDO. Cualquier sistema de almacenamiento con aprovisionamiento ligero tiene el mismo reto.

2.9.3. Aumentar el tamaño lógico de un volumen VDO

Este procedimiento aumenta el tamaño lógico de un determinado volumen VDO. Le permite crear inicialmente volúmenes VDO que tienen un tamaño lógico lo suficientemente pequeño como para estar a salvo de quedarse sin espacio. Después de algún tiempo, puede evaluar la tasa real de reducción de datos, y si es suficiente, puede aumentar el tamaño lógico del volumen VDO para aprovechar el ahorro de espacio.

No es posible disminuir el tamaño lógico de un volumen VDO.

Procedimiento

  • Para aumentar el tamaño lógico, utilice:

    # vdo growLogical --name=my-vdo \
                      --vdoLogicalSize=new-logical-size

    Cuando el tamaño lógico aumenta, VDO informa a cualquier dispositivo o sistema de archivos que se encuentre sobre el volumen del nuevo tamaño.

2.9.4. Aumentar el tamaño físico de un volumen VDO

Este procedimiento aumenta la cantidad de almacenamiento físico disponible para un volumen VDO.

No es posible reducir un volumen VDO de esta manera.

Requisitos previos

  • El dispositivo de bloque subyacente tiene una capacidad mayor que el tamaño físico actual del volumen VDO.

    Si no lo hace, puede intentar aumentar el tamaño del dispositivo. El procedimiento exacto depende del tipo de dispositivo. Por ejemplo, para redimensionar una partición MBR o GPT, consulte la sección Redimensionar una partición en la guía Managing storage devices.

Procedimiento

  • Añade el nuevo espacio de almacenamiento físico al volumen VDO:

    # vdo growPhysical --name=my-vdo

2.10. Eliminación de volúmenes VDO

Puede eliminar un volumen VDO existente en su sistema.

2.10.1. Eliminación de un volumen VDO en funcionamiento

Este procedimiento elimina un volumen VDO y su índice UDS asociado.

Procedimiento

  1. Desmonte los sistemas de archivos y detenga las aplicaciones que están utilizando el almacenamiento en el volumen VDO.
  2. Para eliminar el volumen VDO de su sistema, utilice:

    # vdo remove --name=my-vdo

2.10.2. Eliminación de un volumen VDO creado sin éxito

Este procedimiento limpia un volumen VDO en un estado intermedio. Un volumen queda en un estado intermedio si se produce un fallo al crear el volumen. Esto puede ocurrir cuando, por ejemplo:

  • El sistema se bloquea
  • El poder falla
  • El administrador interrumpe un comando vdo create en ejecución

Procedimiento

  • Para limpiar, elimine el volumen creado sin éxito con la opción --force:

    # vdo remove --force --name=my-vdo

    La opción --force es necesaria porque el administrador podría haber causado un conflicto al cambiar la configuración del sistema desde que se creó el volumen sin éxito.

    Sin la opción --force, el comando vdo remove falla con el siguiente mensaje:

    [...]
    A previous operation failed.
    Recovery from the failure either failed or was interrupted.
    Add '--force' to 'remove' to perform the following cleanup.
    Steps to clean up VDO my-vdo:
    umount -f /dev/mapper/my-vdo
    udevadm settle
    dmsetup remove my-vdo
    vdo: ERROR - VDO volume my-vdo previous operation (create) is incomplete

Capítulo 3. Prueba de ahorro de espacio VDO

Puede realizar una serie de pruebas para determinar cuánto espacio de almacenamiento puede ahorrar utilizando VDO.

Requisitos previos

  • Se dispone de uno o más dispositivos físicos de bloque.
  • El dispositivo de bloque de destino es mayor que 512 GiB.
  • VDO está instalado.

3.1. El objetivo y los resultados de las pruebas VDO

Las pruebas de VDO proporcionadas por Red Hat ayudan a producir una evaluación de la integración de VDO en los dispositivos de almacenamiento existentes. Están destinadas a aumentar, no a sustituir, sus esfuerzos de evaluación interna.

Los resultados de las pruebas ayudan a los ingenieros de Red Hat a comprender el comportamiento de VDO en entornos de almacenamiento específicos. Los fabricantes de equipos originales (OEM) pueden aprender cómo diseñar sus dispositivos con capacidad de deduplicación y compresión, y cómo sus clientes pueden ajustar sus aplicaciones para esos dispositivos.

Objetivos

  • Identificar los ajustes de configuración que provocan respuestas óptimas del dispositivo de prueba.
  • Explicar los parámetros básicos de ajuste para ayudar a evitar configuraciones erróneas del producto.
  • Crear una referencia de resultados de rendimiento para comparar con casos de uso reales.
  • Identificar cómo las diferentes cargas de trabajo afectan al rendimiento y a la eficiencia de los datos.
  • Acorte el tiempo de comercialización con las implantaciones de VDO.

El plan y las condiciones de la prueba

Las pruebas de VDO proporcionan las condiciones en las que el VDO puede ser evaluado de forma más realista. La alteración de los procedimientos o parámetros de prueba puede invalidar los resultados. Los ingenieros de ventas de Red Hat pueden guiarle a la hora de modificar los planes de prueba.

Para realizar un plan de pruebas eficaz, debe estudiar la arquitectura de VDO y explorar estos elementos:

  • El rendimiento en entornos de alta carga
  • Las propiedades configurables de VDO para el ajuste del rendimiento de las aplicaciones de los usuarios finales
  • El impacto de que VDO sea un dispositivo de bloque nativo de 4 KiB
  • La respuesta a los patrones de acceso y las distribuciones de deduplicación y compresión
  • El valor del coste frente a la capacidad frente al rendimiento para una aplicación determinada

3.2. Aprovisionamiento ligero en VDO

VDO es un objetivo de almacenamiento en bloque con aprovisionamiento ligero. La cantidad de espacio físico que utiliza un volumen VDO puede diferir del tamaño del volumen que se presenta a los usuarios del almacenamiento. Puede aprovechar esta disparidad para ahorrar en costes de almacenamiento.

Condiciones fuera del espacio

Tenga cuidado para evitar quedarse sin espacio de almacenamiento de forma inesperada, si los datos escritos no alcanzan la tasa de optimización esperada.

Cuando el número de bloques lógicos (almacenamiento virtual) supera el número de bloques físicos (almacenamiento real), es posible que los sistemas de archivos y las aplicaciones se queden inesperadamente sin espacio. Por esta razón, los sistemas de almacenamiento que utilizan VDO deben proporcionarle una forma de controlar el tamaño del pool libre en el volumen VDO.

Puede determinar el tamaño de este pool libre utilizando la utilidad vdostats. La salida por defecto de esta utilidad lista la información de todos los volúmenes VDO en ejecución en un formato similar al de la utilidad de Linux df. Por ejemplo:

Device                1K-blocks   Used        Available   Use%
/dev/mapper/vdo-name  211812352   105906176   105906176   50%

Cuando la capacidad de almacenamiento físico de un volumen VDO está casi llena, VDO informa de una advertencia en el registro del sistema, similar a la siguiente:

Oct  2 17:13:39 system lvm[13863]: Monitoring VDO pool vdo-name.
Oct  2 17:27:39 system lvm[13863]: WARNING: VDO pool vdo-name is now 80.69% full.
Oct  2 17:28:19 system lvm[13863]: WARNING: VDO pool vdo-name is now 85.25% full.
Oct  2 17:29:39 system lvm[13863]: WARNING: VDO pool vdo-name is now 90.64% full.
Oct  2 17:30:29 system lvm[13863]: WARNING: VDO pool vdo-name is now 96.07% full.
Nota

Estos mensajes de advertencia sólo aparecen cuando el servicio lvm2-monitor está en funcionamiento. Está activado por defecto.

Cómo prevenir las condiciones de fuera del espacio

Si el tamaño de la piscina libre desciende por debajo de un determinado nivel, puedes actuar:

  • Eliminación de datos. Esto recupera espacio siempre que los datos borrados no se dupliquen. El borrado de datos libera el espacio sólo después de los descartes.
  • Añadir almacenamiento físico
Importante

Supervise el espacio físico en sus volúmenes VDO para evitar situaciones de falta de espacio. Quedarse sin bloques físicos podría resultar en la pérdida de datos recientemente escritos y no reconocidos en el volumen VDO.

Aprovisionamiento delgado y los comandos TRIM y DISCARD

Para beneficiarse del ahorro de almacenamiento que supone el thin provisioning, la capa de almacenamiento físico necesita saber cuándo se eliminan los datos. Los sistemas de archivos que trabajan con el almacenamiento thinly provisioned envían comandos TRIM o DISCARD para informar al sistema de almacenamiento cuando un bloque lógico ya no es necesario.

Existen varios métodos para enviar los comandos TRIM o DISCARD:

  • Con la opción de montaje discard, los sistemas de archivos pueden enviar estos comandos cada vez que se elimina un bloque.
  • Puede enviar los comandos de forma controlada utilizando utilidades como fstrim. Estas utilidades le dicen al sistema de archivos que detecte los bloques lógicos que no se utilizan y que envíe la información al sistema de almacenamiento en forma de comando TRIM o DISCARD.

La necesidad de utilizar TRIM o DISCARD en los bloques no utilizados no es exclusiva de VDO. Cualquier sistema de almacenamiento con aprovisionamiento ligero tiene el mismo reto.

3.3. Información a registrar antes de cada prueba VDO

Debe registrar la siguiente información al comienzo de cada prueba para asegurarse de que el entorno de la prueba se entiende completamente. Puede capturar gran parte de la información necesaria utilizando la utilidad sosreport.

Información necesaria

  • La compilación de Linux utilizada, incluyendo el número de compilación del kernel
  • La lista completa de paquetes instalados, tal y como se obtiene del comando rpm -qa
  • Especificaciones completas del sistema

    • Tipo y cantidad de CPU; disponible en el archivo /proc/cpuinfo
    • La memoria instalada y la cantidad disponible después de la ejecución del sistema operativo rase; disponible en el archivo /proc/meminfo
    • Tipos de controladores de accionamiento usados
    • Tipos y cantidad de discos usados
  • Una lista completa de los procesos en ejecución; disponible desde el comando ps aux o un listado similar
  • Nombre del volumen físico y del grupo de volúmenes creado para su uso con VDO; disponible en los comandos pvs y vgs
  • Sistema de archivos utilizado al formatear el volumen VDO, si lo hay
  • Permisos en el directorio montado
  • Contenido del archivo /etc/vdoconf.yaml
  • Ubicación de los archivos VDO

3.4. Creación de un volumen de prueba VDO

Este procedimiento crea un volumen VDO con un tamaño lógico de 1 TiB en un volumen físico de 512 GiB para fines de prueba.

Procedimiento

  1. Crear un volumen VDO:

    # vdo create --name=vdo-test \
                 --device=/dev/sdb \
                 --vdoLogicalSize=1T \
                 --writePolicy=policy \
                 --verbose
    • Sustituya /dev/sdb por la ruta de acceso a un dispositivo de bloque.
    • Para probar el modo VDO async sobre el almacenamiento asíncrono, cree un volumen asíncrono utilizando la opción --writePolicy=async.
    • Para probar el modo VDO sync sobre el almacenamiento síncrono, cree un volumen síncrono utilizando la opción --writePolicy=sync.
  2. Formatea el nuevo volumen con un sistema de archivos XFS o ext4.

    • Para XFS:

      # mkfs.xfs -K /dev/mapper/vdo-test
    • Para ext4:

      # mkfs.ext4 -E nodiscard /dev/mapper/vdo-test
  3. Monte el volumen formateado:

    # mkdir /mnt/vdo-test
    
    # mount /dev/mapper/vdo-test /mnt/vdo-test && \
      chmod a+rwx /mnt/vdo-test

3.5. Comprobación del volumen de prueba VDO

Este procedimiento comprueba si la lectura y escritura en el volumen de prueba VDO funciona.

Requisitos previos

Procedimiento

  1. Escribe 32 GiB de datos aleatorios en el volumen VDO:

    $ dd if=/dev/urandom of=/mnt/vdo-test/testfile bs=4096 count=8388608
  2. Leer los datos del volumen VDO y escribirlos en otro volumen:

    $ dd if=/mnt/vdo-test/testfile of=another-location/archivo de prueba bs=4096
    • Sustituya another-location con cualquier directorio donde tenga acceso de escritura que no esté en el volumen de prueba de VDO. Por ejemplo, puede utilizar su directorio personal.
  3. Compara los dos archivos:

    $ diff --report-identical-files /mnt/vdo-test/testfile another-location/archivo-de-prueba

    El comando debería informar que los archivos son los mismos.

  4. Copie el archivo en una nueva ubicación en el volumen VDO:

    $ dd if=another-location/archivo de prueba of=/mnt/vdo-test/archivo de prueba2 bs=4096
  5. Compara el tercer archivo con el segundo:

    $ diff --report-identical-files /mnt/vdo-test/testfile2 another-location/archivo-de-prueba

    El comando debería informar que los archivos son los mismos.

Pasos de limpieza

3.6. Limpieza del volumen de prueba de VDO

Este procedimiento elimina del sistema el volumen de VDO utilizado para comprobar la eficiencia de VDO.

Requisitos previos

  • Se monta un volumen de prueba VDO.

Procedimiento

  1. Desmontar el sistema de archivos creado en el volumen VDO:

    # umount /mnt/vdo-test
  2. Retire el volumen de prueba VDO del sistema:

    # vdo remove --name=vdo-test

Pasos de verificación

  • Compruebe que el volumen ha sido eliminado:

    # vdo list --all | grep vdo-test

    El comando no debería listar la partición de prueba VDO.

3.7. Medición de la deduplicación VDO

Este procedimiento comprueba la eficacia de la deduplicación de datos VDO en un volumen de prueba VDO.

Requisitos previos

Procedimiento

  1. Prepara una tabla en la que puedas registrar los resultados de las pruebas:

    EstadísticaSistema de archivos sin soporteDespués de la semillaDespués de 10 copias

    Tamaño del sistema de archivos utilizado

       

    Datos VDO utilizados

       

    VDO lógico utilizado

       
  2. Cree 10 directorios en el volumen VDO para contener 10 copias del conjunto de datos de prueba:

    $ mkdir /mnt/vdo-test/vdo{01..10}
  3. Examine el uso del disco informado por el sistema de archivos:

    $ df --human-readable /mnt/vdo-test

    Ejemplo 3.1. Uso del disco

    Filesystem            Size  Used Avail Use% Mounted on
    /dev/mapper/vdo-test  1.5T  198M  1.4T   1% /mnt/vdo-test
  4. Registra los siguientes valores:

    # vdostats --verbose | grep "blocks used"

    Ejemplo 3.2. Bloques usados

    data blocks used                : 1090
    overhead blocks used            : 538846
    logical blocks used             : 6059434
    • El valor data blocks used es el número de bloques utilizados por los datos del usuario después de la optimización en el dispositivo físico que se ejecuta bajo VDO.
    • El valor logical blocks used es el número de bloques utilizados antes de la optimización. Se utilizará como punto de partida para las mediciones.
  5. Cree un archivo de origen de datos en el volumen VDO:

    $ dd if=/dev/urandom of=/mnt/vdo-test/sourcefile bs=4096 count=1048576
    
    4294967296 bytes (4.3 GB) copied, 540.538 s, 7.9 MB/s
  6. Vuelva a examinar la cantidad de espacio de disco físico utilizado:

    $ df --human-readable /mnt/vdo-test

    Ejemplo 3.3. Uso del disco con el archivo fuente de datos

    Filesystem            Size  Used Avail Use% Mounted on
    /dev/mapper/vdo-test  1.5T  4.2G  1.4T   1% /mnt/vdo-test
    # vdostats --verbose | grep "blocks used"

    Ejemplo 3.4. Bloques utilizados con el archivo de origen de datos

    data blocks used                : 1050093  # Increased by 4GiB
    overhead blocks used            : 538846   # Did not significantly change
    logical blocks used             : 7108036  # Increased by 4GiB

    Este comando debería mostrar un aumento en el número de bloques utilizados, correspondiente al tamaño del archivo escrito.

  7. Copie el archivo en cada uno de los 10 subdirectorios:

    $ for i in {01..10}; do
      cp /mnt/vdo-test/sourcefile /mnt/vdo-test/vdo$i
      done
  8. Vuelva a examinar la cantidad de espacio de disco físico utilizado:

    $ df -h /mnt/vdo-test

    Ejemplo 3.5. Uso del disco después de copiar el archivo

    Filesystem            Size  Used Avail Use% Mounted on
    /dev/mapper/vdo-test  1.5T   45G  1.3T   4% /mnt/vdo-test
    # vdostats --verbose | grep "blocks used"

    Ejemplo 3.6. Bloques utilizados después de copiar el archivo

    data blocks used                : 1050836   # Increased by 3 MiB
    overhead blocks used            : 538846
    logical blocks used             : 17594127  # Increased by 41 GiB

    El valor de data blocks used debería ser similar al resultado del listado anterior, con sólo un ligero aumento debido al registro en el diario del sistema de archivos y los metadatos.

  9. Reste este nuevo valor del espacio utilizado por el sistema de archivos del valor encontrado antes de escribir los datos de la prueba. Esta es la cantidad de espacio consumido por esta prueba desde la perspectiva del sistema de archivos.
  10. Observe el ahorro de espacio en sus estadísticas registradas:

    Ejemplo 3.7. Valores registrados

    EstadísticaSistema de archivos sin soporteDespués de la semillaDespués de 10 copias

    Tamaño del sistema de archivos utilizado

    198 MiB

    4.2 GiB

    45 GiB

    Datos VDO utilizados

    4 MiB

    4.1 GiB

    4.1 GiB

    VDO lógico utilizado

    23.6 GiB (file system overhead for 1.6 TiB formatted drive)

    27.8 GiB

    68.7 GiB

    Nota

    En la tabla, los valores se han convertido a MiB o GiB. Los bloques en la salida de vdostats tienen un tamaño de 4.096 B.

Pasos de limpieza

3.8. Medición de la compresión VDO

Este procedimiento comprueba la eficacia de la compresión de datos VDO en un volumen de prueba VDO.

Requisitos previos

Procedimiento

  1. Desactive la deduplicación y active la compresión en el volumen de prueba VDO:

    # vdo disableDeduplication --name=vdo-test
    # vdo enableCompression --name=vdo-test
  2. Sincroniza el volumen VDO para completar cualquier compresión inacabada:

    # sync && dmsetup message vdo-test 0 sync-dedupe
  3. Inspeccione las estadísticas de VDO antes de la transferencia:

    # vdostats --verbose | grep "blocks used"

    Anote los valores data blocks used y logical blocks used.

  4. VDO optimiza la sobrecarga del sistema de archivos, así como los datos reales del usuario. Calcule el número de bloques de 4 KiB ahorrados por la compresión para el sistema de archivos vacío como logical blocks used menos data blocks used.
  5. Copie el contenido del directorio /lib en el volumen VDO:

    # cp --verbose --recursive /lib /mnt/vdo-test
    
    ...
    sent 152508960 bytes  received 60448 bytes  61027763.20 bytes/sec
    total size is 152293104  speedup is 1.00

    Registra el tamaño total de los datos copiados.

  6. Sincronizar las cachés de Linux y el volumen VDO:

    # sync && dmsetup message vdo-test 0 sync-dedupe
  7. Inspeccione las estadísticas de VDO de nuevo:

    # vdostats --verbose | grep "blocks used"

    Observe los valores de logical blocks used y data blocks used.

  8. Calcule la cantidad de bytes ahorrados por la compresión utilizando la siguiente fórmula:

    saved_bytes = (logical_blocks_used - data_blocks_used) * 4096

Pasos de limpieza

3.9. Medición del ahorro total de espacio de VDO

Este procedimiento comprueba la eficacia combinada de la deduplicación y la compresión de datos VDO en un volumen de prueba VDO.

Procedimiento

  1. Cree y monte un volumen VDO como se describe en Sección 3.4, “Creación de un volumen de prueba VDO”.
  2. Realice las pruebas descritas en Medición de la deduplicación VDO y Medición de la compresión VDO en el mismo volumen sin eliminarlo. Observe los cambios en el ahorro de espacio en la salida de vdostats.
  3. Experimente con sus propios conjuntos de datos.

3.10. Probando el efecto de TRIM y DISCARD en VDO

Este procedimiento comprueba si los comandos TRIM y DISCARD liberan correctamente los bloques de los archivos eliminados en un volumen de prueba de VDO. Demuestra que los descartes informan a VDO de que el espacio ya no se utiliza.

Requisitos previos

Procedimiento

  1. Prepara una tabla en la que puedas registrar los resultados de las pruebas:

    PasoEspacio de archivo utilizado (MB)Bloques de datos utilizadosBloques lógicos utilizados

    Inicialmente

       

    Añadir un archivo de 1 GiB

       

    Ejecutar fstrim

       

    Borrar un archivo de 1 GiB

       

    Ejecutar fstrim

       
  2. Recorta el sistema de archivos para eliminar los bloques innecesarios:

    # fstrim /mnt/vdo-test

    El comando puede tardar mucho tiempo.

  3. Registra el uso de espacio inicial en el sistema de archivos:

    $ df -m /mnt/vdo-test
  4. Vea cuántos bloques de datos físicos y lógicos utiliza el volumen VDO:

    # vdostats --verbose | grep "blocks used"
  5. Crear un archivo de 1 GiB con datos no duplicados en el volumen VDO:

    $ dd if=/dev/urandom of=/mnt/vdo-test/file bs=1M count=1K
  6. Vuelve a registrar el uso del espacio:

    $ df -m /mnt/vdo-test
    
    # vdostats --verbose | grep "blocks used"

    El sistema de archivos debería utilizar 1 GiB adicional. Los valores data blocks used y logical blocks used deberían aumentar de forma similar.

  7. Vuelve a recortar el sistema de archivos:

    # fstrim /mnt/vdo-test
  8. Vuelve a inspeccionar el uso del espacio para confirmar que el recorte no ha tenido impacto en el uso del volumen físico:

    $ df -m /mnt/vdo-test
    
    # vdostats --verbose | grep "blocks used"
  9. Borra el archivo de 1 GiB:

    $ rm /mnt/vdo-test/file
  10. Comprueba y registra de nuevo el uso del espacio:

    $ df -m /mnt/vdo-test
    
    # vdostats --verbose | grep "blocks used"

    El sistema de archivos es consciente de que se ha eliminado un archivo, pero no hay ningún cambio en el número de bloques físicos o lógicos porque la eliminación del archivo no se ha comunicado al almacenamiento subyacente.

  11. Vuelve a recortar el sistema de archivos:

    # fstrim /mnt/vdo-test
  12. Comprueba y registra de nuevo el uso del espacio:

    $ df -m /mnt/vdo-test
    
    # vdostats --verbose | grep "blocks used"

    La utilidad fstrim busca bloques libres en el sistema de archivos y envía un comando TRIM al volumen VDO para las direcciones no utilizadas, que libera los bloques lógicos asociados. VDO procesa el comando TRIM para liberar los bloques físicos subyacentes.

Recursos adicionales

Capítulo 4. Comprobación del rendimiento de VDO

Puede realizar una serie de pruebas para medir el rendimiento de VDO, obtener un perfil de rendimiento de su sistema con VDO y determinar qué aplicaciones funcionan bien con VDO.

Requisitos previos

  • Hay uno o más dispositivos de bloque físico Linux disponibles.
  • El dispositivo de bloque de destino (por ejemplo, /dev/sdb) es mayor que 512 GiB.
  • El probador de E/S flexible (fio) está instalado.
  • VDO está instalado.

4.1. Preparación de un entorno para las pruebas de rendimiento de VDO

Antes de probar el rendimiento del VDO, debe considerar la configuración del sistema anfitrión, la configuración del VDO y las cargas de trabajo que se utilizarán durante las pruebas. Estas elecciones afectan a la evaluación comparativa de la eficiencia del espacio, el ancho de banda y la latencia.

Para evitar que una prueba afecte a los resultados de otra, debe crear un nuevo volumen VDO para cada iteración de cada prueba.

4.1.1. Consideraciones antes de probar el rendimiento de VDO

Las siguientes condiciones y configuraciones afectan a los resultados de la prueba VDO:

Configuración del sistema

  • Número y tipo de núcleos de CPU disponibles. Puedes listar esta información utilizando la utilidad taskset.
  • Memoria disponible y memoria total instalada
  • Configuración de los dispositivos de almacenamiento
  • Programador de disco activo
  • Versión del núcleo de Linux
  • Paquetes instalados

Configuración de VDO

  • Esquema de partición
  • Sistemas de archivos utilizados en volúmenes VDO
  • Tamaño del almacenamiento físico asignado a un volumen VDO
  • Tamaño del volumen lógico VDO creado
  • Indexación UDS dispersa o densa
  • Índice UDS en el tamaño de la memoria
  • Configuración del hilo VDO

Cargas de trabajo

  • Tipos de herramientas utilizadas para generar datos de prueba
  • Número de clientes simultáneos
  • La cantidad de bloques duplicados de 4 KiB en los datos escritos
  • Patrones de lectura y escritura
  • El tamaño del conjunto de trabajo

4.1.2. Consideraciones especiales para comprobar el rendimiento de lectura de VDO

Debe tener en cuenta estos factores adicionales antes de probar el rendimiento de lectura de VDO:

  • Si un bloque de 4 KiB no se ha escrito nunca, VDO no lee del almacenamiento y responde inmediatamente con un bloque cero.
  • Si se ha escrito un bloque de 4 KiB pero contiene todos ceros, VDO no lee del almacenamiento y responde inmediatamente con un bloque cero.

Este comportamiento da lugar a un rendimiento de lectura muy rápido cuando no hay datos que leer. Por ello, las pruebas de lectura deben rellenar previamente el volumen con datos reales.

4.1.3. Preparación del sistema para probar el rendimiento de VDO

Este procedimiento configura los ajustes del sistema para lograr un rendimiento óptimo de VDO durante las pruebas.

Importante

La realización de pruebas más allá de los límites indicados en cualquier prueba concreta podría dar lugar a la pérdida de tiempo de prueba debido a resultados anormales.

Por ejemplo, las pruebas de VDO describen una prueba que realiza lecturas aleatorias sobre un rango de direcciones de 100 GiB. Para probar un conjunto de trabajo de 500 GiB, debe aumentar la cantidad de RAM asignada para la caché del mapa de bloques de VDO en consecuencia.

Procedimiento

  1. Asegúrese de que su CPU está funcionando en su configuración de mayor rendimiento.
  2. Si es posible, desactive el escalado de frecuencia de la CPU mediante la configuración de la BIOS o la utilidad de Linux cpupower.
  3. Si es posible, active el ajuste dinámico de la frecuencia del procesador (Turbo Boost o Turbo Core) para la CPU. Esta función introduce cierta variabilidad en los resultados de las pruebas, pero mejora el rendimiento general.
  4. Los sistemas de archivos pueden tener un impacto único en el rendimiento. Suelen sesgar las mediciones de rendimiento, lo que hace más difícil aislar el impacto de VDO en los resultados.

    Si es razonable, mida el rendimiento en el dispositivo de bloques sin procesar. Si no es posible, formatee el dispositivo utilizando el sistema de archivos que VDO utilizará en la implementación de destino.

4.2. Creación de un volumen VDO para pruebas de rendimiento

Este procedimiento crea un volumen VDO con un tamaño lógico de 1 TiB en un volumen físico de 512 GiB para probar el rendimiento de VDO.

Procedimiento

  • Crear un volumen VDO:

    # vdo create --name=vdo-test \
                 --device=/dev/sdb \
                 --vdoLogicalSize=1T \
                 --writePolicy=policy \
                 --verbose
    • Sustituya /dev/sdb por la ruta de acceso a un dispositivo de bloque.
    • Para probar el modo VDO async sobre el almacenamiento asíncrono, cree un volumen asíncrono utilizando la opción --writePolicy=async.
    • Para probar el modo VDO sync sobre el almacenamiento síncrono, cree un volumen síncrono utilizando la opción --writePolicy=sync.

4.3. Limpieza del volumen de pruebas de rendimiento de VDO

Este procedimiento elimina del sistema el volumen VDO utilizado para probar el rendimiento de VDO.

Requisitos previos

  • Existe un volumen de prueba VDO en el sistema.

Procedimiento

  • Retire el volumen de prueba VDO del sistema:

    # vdo remove --name=vdo-test

Pasos de verificación

  • Compruebe que el volumen ha sido eliminado:

    # vdo list --all | grep vdo-test

    El comando no debería listar la partición de prueba VDO.

4.4. Prueba de los efectos de la profundidad de E/S en el rendimiento de VDO

Estas pruebas determinan la profundidad de E/S que produce el rendimiento óptimo y la menor latencia para su configuración de VDO. La profundidad de E/S representa el número de solicitudes de E/S que la herramienta fio envía a la vez.

Dado que VDO utiliza un tamaño de sector de 4 KiB, las pruebas realizan cuatro esquinas con operaciones de E/S de 4 KiB y una profundidad de E/S de 1, 8, 16, 32, 64, 128, 256, 512 y 1024.

4.4.1. Comprobación del efecto de la profundidad de E/S en las lecturas secuenciales del 100% en VDO

Esta prueba determina el rendimiento de las operaciones de lectura secuencial al 100% en un volumen VDO con diferentes valores de profundidad de E/S.

Procedimiento

  1. Crea un nuevo volumen VDO.

    Para más detalles, consulte Sección 4.2, “Creación de un volumen VDO para pruebas de rendimiento”.

  2. Rellene previamente las áreas a las que la prueba podría acceder realizando un trabajo de escritura fio en el volumen de prueba:

    # fio --rw=write \
          --bs=8M \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --thread \
          --direct=1 \
          --scramble_buffers=1
  3. Registre el rendimiento y la latencia reportados para lecturas secuenciales del 100%:

    # for depth in 1 2 4 8 16 32 64 128 256 512 1024 2048; do
      fio --rw=read \
          --bs=4096 \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --numjobs=1 \
          --thread \
          --norandommap \
          --runtime=300 \
          --direct=1 \
          --iodepth=$depth \
          --scramble_buffers=1 \
          --offset=0 \
          --size=100g
      done
  4. Retire el volumen de prueba VDO.

    Para más detalles, consulte Sección 4.3, “Limpieza del volumen de pruebas de rendimiento de VDO”.

4.4.2. Probando el efecto de la profundidad de E/S en las escrituras secuenciales al 100% en VDO

Esta prueba determina el rendimiento de las operaciones de escritura secuencial al 100% en un volumen VDO con diferentes valores de profundidad de E/S.

Procedimiento

  1. Cree un nuevo volumen de prueba VDO.

    Para más detalles, consulte Sección 4.2, “Creación de un volumen VDO para pruebas de rendimiento”.

  2. Rellene previamente las áreas a las que la prueba podría acceder realizando un trabajo de escritura fio:

    # fio --rw=write \
          --bs=8M \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --thread \
          --direct=1 \
          --scramble_buffers=1
  3. Registra el rendimiento y la latencia reportados para escrituras secuenciales del 100%:

    # for depth in 1 2 4 8 16 32 64 128 256 512 1024 2048; do
      fio --rw=write \
          --bs=4096 \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --numjobs=1 \
          --thread \
          --norandommap \
          --runtime=300 \
          --direct=1 \
          --iodepth=$depth \
          --scramble_buffers=1 \
          --offset=0 \
          --size=100g
      done
  4. Retire el volumen de prueba VDO.

    Para más detalles, consulte Sección 4.3, “Limpieza del volumen de pruebas de rendimiento de VDO”.

4.4.3. Probando el efecto de la profundidad de E/S en las lecturas aleatorias del 100% en VDO

Esta prueba determina el rendimiento de las operaciones de lectura aleatoria al 100% en un volumen VDO con diferentes valores de profundidad de E/S.

Procedimiento

  1. Cree un nuevo volumen de prueba VDO.

    Para más detalles, consulte Sección 4.2, “Creación de un volumen VDO para pruebas de rendimiento”.

  2. Rellene previamente las áreas a las que la prueba podría acceder realizando un trabajo de escritura fio:

    # fio --rw=write \
          --bs=8M \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --thread \
          --direct=1 \
          --scramble_buffers=1
  3. Registra el rendimiento y la latencia reportados para lecturas aleatorias del 100%:

    # for depth in 1 2 4 8 16 32 64 128 256 512 1024 2048; do
      fio --rw=randread \
          --bs=4096 \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --numjobs=1 \
          --thread \
          --norandommap \
          --runtime=300 \
          --direct=1 \
          --iodepth=$depth \
          --scramble_buffers=1 \
          --offset=0 \
          --size=100g
      done
  4. Retire el volumen de prueba VDO.

    Para más detalles, consulte Sección 4.3, “Limpieza del volumen de pruebas de rendimiento de VDO”.

4.4.4. Probando el efecto de la profundidad de E/S en las escrituras aleatorias al 100% en VDO

Esta prueba determina el rendimiento de las operaciones de escritura aleatorias al 100% en un volumen VDO con diferentes valores de profundidad de E/S.

Importante

Debe volver a crear el volumen VDO entre cada prueba de profundidad de E/S.

Procedimiento

Realice la siguiente serie de pasos por separado para los valores de profundidad de E/S de 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024 y 2048:

  1. Cree un nuevo volumen de prueba VDO.

    Para más detalles, consulte Sección 4.2, “Creación de un volumen VDO para pruebas de rendimiento”.

  2. Rellene previamente las áreas a las que la prueba podría acceder realizando un trabajo de escritura fio:

    # fio --rw=write \
          --bs=8M \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --thread \
          --direct=1 \
          --scramble_buffers=1
  3. Registra el rendimiento y la latencia reportados para escrituras aleatorias del 100%:

    # fio --rw=randwrite \
          --bs=4096 \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --numjobs=1 \
          --thread \
          --norandommap \
          --runtime=300 \
          --direct=1 \
          --iodepth=depth-value
          --scramble_buffers=1 \
          --offset=0 \
          --size=100g
      done
  4. Retire el volumen de prueba VDO.

    Para más detalles, consulte Sección 4.3, “Limpieza del volumen de pruebas de rendimiento de VDO”.

4.4.5. Análisis del rendimiento de VDO con diferentes profundidades de E/S

El siguiente ejemplo analiza el rendimiento y la latencia de VDO registrados con diferentes valores de profundidad de E/S.

Observe el comportamiento en toda la gama y los puntos de inflexión en los que el aumento de la profundidad de E/S proporciona ganancias de rendimiento decrecientes. El acceso secuencial y el acceso aleatorio probablemente alcancen un pico en valores diferentes, pero los picos podrían ser diferentes para todos los tipos de configuraciones de almacenamiento.

Ejemplo 4.1. Análisis de profundidad de E/S

Figura 4.1. Análisis del rendimiento de VDO

VDO throughput analysis

Fíjate en la "rodilla" de cada curva de rendimiento:

  • El marcador 1 identifica el pico de rendimiento secuencial en el punto X. Esta configuración particular no se beneficia de la profundidad de E/S secuencial de 4 KiB mayor que X.
  • El marcador 2 identifica el pico de rendimiento aleatorio de 4 KiB en el punto Z. Esta configuración concreta no se beneficia de una profundidad de E/S aleatoria de 4 KiB mayor que Z.

Más allá de la profundidad de E/S en los puntos X y Z, las ganancias de ancho de banda disminuyen, y la latencia media de las peticiones aumenta 1:1 por cada petición de E/S adicional.

La siguiente imagen muestra un ejemplo de la latencia de escritura aleatoria después de la "rodilla" de la curva en el gráfico anterior. Debe probar en estos puntos para obtener el máximo rendimiento que incurra en la menor penalización del tiempo de respuesta.

Figura 4.2. Análisis de latencia VDO

VDO latency analysis

Profundidad óptima de E/S

El punto Z marca la profundidad de E/S óptima. El plan de pruebas recoge datos adicionales con una profundidad de E/S igual a Z.

4.5. Comprobación de los efectos del tamaño de la solicitud de E/S en el rendimiento de VDO

Utilizando estas pruebas, se puede identificar el tamaño de bloque que produce el mejor rendimiento de VDO en la profundidad óptima de E/S.

Las pruebas realizan cuatro esquinas con una profundidad de E/S fija, con tamaños de bloque variados en el rango de 8 KiB a 1 MiB.

Requisitos previos

4.5.1. Prueba del efecto del tamaño de la solicitud de E/S en las escrituras secuenciales en VDO

Esta prueba determina el rendimiento de las operaciones de escritura secuencial en un volumen VDO con diferentes tamaños de solicitud de E/S.

Procedimiento

  1. Crea un nuevo volumen VDO.

    Para más detalles, consulte Sección 4.2, “Creación de un volumen VDO para pruebas de rendimiento”.

  2. Rellene previamente las áreas a las que la prueba podría acceder realizando un trabajo de escritura fio en el volumen de prueba:

    # fio --rw=write \
          --bs=8M \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --thread \
          --direct=1 \
          --scramble_buffers=1
  3. Registre el rendimiento y la latencia reportados para la prueba de escritura secuencial:

    # for iosize in 4 8 16 32 64 128 256 512 1024; do
      fio --rw=write \
          --bs=${iosize}k \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --numjobs=1 \
          --thread \
          --norandommap \
          --runtime=300 \
          --direct=1 \
          --iodepth=optimal-depth \
          --scramble_buffers=1 \
          --offset=0 \
          --size=100g
      done
  4. Retire el volumen de prueba VDO.

    Para más detalles, consulte Sección 4.3, “Limpieza del volumen de pruebas de rendimiento de VDO”.

4.5.2. Probando el efecto del tamaño de la solicitud de E/S en las escrituras aleatorias en VDO

Esta prueba determina el rendimiento de las operaciones de escritura aleatoria en un volumen VDO con diferentes tamaños de solicitud de E/S.

Importante

Debe volver a crear el volumen VDO entre cada prueba de tamaño de solicitud de E/S.

Procedimiento

Realice los siguientes pasos en serie por separado para los tamaños de solicitud de E/S de 4k, 8k, 16k, 32k, 64k, 128k, 256k, 512k, y 1024k:

  1. Crea un nuevo volumen VDO.

    Para más detalles, consulte Sección 4.2, “Creación de un volumen VDO para pruebas de rendimiento”.

  2. Rellene previamente las áreas a las que la prueba podría acceder realizando un trabajo de escritura fio en el volumen de prueba:

    # fio --rw=write \
          --bs=8M \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --thread \
          --direct=1 \
          --scramble_buffers=1
  3. Registra el rendimiento y la latencia de la prueba de escritura aleatoria:

    # fio --rw=randwrite \
          --bs=request-size \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --numjobs=1 \
          --thread \
          --norandommap \
          --runtime=300 \
          --direct=1 \
          --iodepth=optimal-depth \
          --scramble_buffers=1 \
          --offset=0 \
          --size=100g
      done
  4. Retire el volumen de prueba VDO.

    Para más detalles, consulte Sección 4.3, “Limpieza del volumen de pruebas de rendimiento de VDO”.

4.5.3. Prueba del efecto del tamaño de la solicitud de E/S en la lectura secuencial en VDO

Esta prueba determina el rendimiento de las operaciones de lectura secuencial en un volumen VDO con diferentes tamaños de solicitud de E/S.

Procedimiento

  1. Crea un nuevo volumen VDO.

    Para más detalles, consulte Sección 4.2, “Creación de un volumen VDO para pruebas de rendimiento”.

  2. Rellene previamente las áreas a las que la prueba podría acceder realizando un trabajo de escritura fio en el volumen de prueba:

    # fio --rw=write \
          --bs=8M \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --thread \
          --direct=1 \
          --scramble_buffers=1
  3. Registre el rendimiento y la latencia reportados para la prueba de lectura secuencial:

    # for iosize in 4 8 16 32 64 128 256 512 1024; do
      fio --rw=read \
          --bs=${iosize}k \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --numjobs=1 \
          --thread \
          --norandommap \
          --runtime=300 \
          --direct=1 \
          --iodepth=optimal-depth \
          --scramble_buffers=1 \
          --offset=0 \
          --size=100g
      done
  4. Retire el volumen de prueba VDO.

    Para más detalles, consulte Sección 4.3, “Limpieza del volumen de pruebas de rendimiento de VDO”.

4.5.4. Probando el efecto del tamaño de la solicitud de E/S en la lectura aleatoria en VDO

Esta prueba determina el rendimiento de las operaciones de lectura aleatoria en un volumen VDO con diferentes tamaños de solicitud de E/S.

Procedimiento

  1. Crea un nuevo volumen VDO.

    Para más detalles, consulte Sección 4.2, “Creación de un volumen VDO para pruebas de rendimiento”.

  2. Rellene previamente las áreas a las que la prueba podría acceder realizando un trabajo de escritura fio en el volumen de prueba:

    # fio --rw=write \
          --bs=8M \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --thread \
          --direct=1 \
          --scramble_buffers=1
  3. Registre el rendimiento y la latencia reportados para la prueba de lectura aleatoria:

    # for iosize in 4 8 16 32 64 128 256 512 1024; do
      fio --rw=read \
          --bs=${iosize}k \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --numjobs=1 \
          --thread \
          --norandommap \
          --runtime=300 \
          --direct=1 \
          --iodepth=optimal-depth \
          --scramble_buffers=1 \
          --offset=0 \
          --size=100g
      done
  4. Retire el volumen de prueba VDO.

    Para más detalles, consulte Sección 4.3, “Limpieza del volumen de pruebas de rendimiento de VDO”.

4.5.5. Análisis del rendimiento de VDO con diferentes tamaños de solicitud de E/S

El siguiente ejemplo analiza el rendimiento y la latencia de VDO registrados en diferentes tamaños de solicitud de E/S.

Ejemplo 4.2. Análisis del tamaño de las solicitudes de E/S

Figura 4.3. Análisis del tamaño de la solicitud frente al rendimiento y puntos de inflexión clave

Request size versus throughput analysis and key inflection points

Analizar los resultados del ejemplo:

  • Las escrituras secuenciales alcanzan un rendimiento máximo con el tamaño de la solicitud Y.

    Esta curva demuestra cómo las aplicaciones que son configurables o naturalmente dominadas por ciertos tamaños de solicitud pueden percibir el rendimiento. Los tamaños de solicitud más grandes suelen proporcionar más rendimiento porque las operaciones de E/S de 4 KiB podrían beneficiarse de la fusión.

  • Las lecturas secuenciales alcanzan un pico de rendimiento similar en el punto Z.

    Después de estos picos, la latencia general antes de que la operación de E/S se complete aumenta sin rendimiento adicional. Debes ajustar el dispositivo para que no acepte operaciones de E/S mayores a este tamaño.

  • Las lecturas aleatorias alcanzan su máximo rendimiento en el punto X.

    Algunos dispositivos pueden alcanzar tasas de rendimiento casi secuenciales en accesos aleatorios de gran tamaño de solicitud, pero otros sufren más penalizaciones cuando varían de un acceso puramente secuencial.

  • Las escrituras aleatorias alcanzan su máximo rendimiento en el punto Y.

    Las escrituras aleatorias implican la mayor interacción de un dispositivo de deduplicación, y VDO logra un alto rendimiento especialmente cuando los tamaños de las solicitudes o las profundidades de E/S son grandes.

4.6. Prueba de los efectos de las cargas mixtas de E/S en el rendimiento de VDO

Esta prueba determina cómo se comporta su configuración de VDO con cargas de E/S mixtas de lectura y escritura, y analiza los efectos de las lecturas y escrituras mixtas en la profundidad de cola aleatoria óptima y los tamaños de solicitud de 4 KB a 1 MB.

Este procedimiento realiza una prueba de cuatro esquinas con una profundidad de E/S fija, un tamaño de bloque variado en el rango de 8 KB a 256 KB y un porcentaje de lectura establecido en incrementos del 10%, comenzando por el 0%.

Requisitos previos

Procedimiento

  1. Crea un nuevo volumen VDO.

    Para más detalles, consulte Sección 4.2, “Creación de un volumen VDO para pruebas de rendimiento”.

  2. Rellene previamente las áreas a las que la prueba podría acceder realizando un trabajo de escritura fio en el volumen de prueba:

    # fio --rw=write \
          --bs=8M \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --thread \
          --direct=1 \
          --scramble_buffers=1
  3. Registre el rendimiento y la latencia reportados para el estímulo de entrada de lectura y escritura:

    # for readmix in 0 10 20 30 40 50 60 70 80 90 100; do
        for iosize in 4 8 16 32 64 128 256 512 1024; do
          fio --rw=rw \
              --rwmixread=$readmix \
              --bs=${iosize}k \
              --name=vdo \
              --filename=/dev/mapper/vdo-test \
              --ioengine=libaio \
              --numjobs=1 \
              --thread \
              --norandommap \
              --runtime=300 \
              --direct=0 \
              --iodepth=optimal-depth \
              --scramble_buffers=1 \
              --offset=0 \
              --size=100g
        done
      done
  4. Retire el volumen de prueba VDO.

    Para más detalles, consulte Sección 4.3, “Limpieza del volumen de pruebas de rendimiento de VDO”.

  5. Grafique los resultados de la prueba.

    Ejemplo 4.3. Análisis de cargas mixtas de E/S

    La siguiente imagen muestra un ejemplo de cómo VDO podría responder a cargas de E/S mixtas:

    Figura 4.4. El rendimiento es consistente en diferentes combinaciones de lectura y escritura

    Performance is consistent across varying read and write mixes

    El rendimiento y la latencia agregados son relativamente consistentes en toda la gama de mezcla de lecturas y escrituras, con una tendencia desde el rendimiento máximo de escritura más bajo hasta el rendimiento máximo de lectura más alto.

    Este comportamiento puede variar con diferentes almacenamientos, pero la observación importante es que el rendimiento es consistente bajo cargas variables o que se puede entender la expectativa de rendimiento para aplicaciones que demuestran mezclas específicas de lectura y escritura.

    Nota

    Si su sistema no muestra una consistencia de respuesta similar, podría ser un signo de una configuración subóptima. Póngase en contacto con su ingeniero de ventas de Red Hat si esto ocurre.

4.7. Prueba de los efectos de los entornos de aplicación en el rendimiento de VDO

Estas pruebas determinan cómo se comporta su configuración de VDO cuando se despliega en un entorno mixto de aplicación real. Si conoce más detalles sobre el entorno previsto, pruébelos también.

Requisitos previos

  • Considere la posibilidad de limitar la profundidad de la cola permitida en su configuración.
  • Si es posible, ajuste la aplicación para que emita peticiones con los tamaños de bloque que sean más beneficiosos para el rendimiento de VDO.

Procedimiento

  1. Crea un nuevo volumen VDO.

    Para más detalles, consulte Sección 4.2, “Creación de un volumen VDO para pruebas de rendimiento”.

  2. Rellene previamente las áreas a las que la prueba podría acceder realizando un trabajo de escritura fio en el volumen de prueba:

    # fio --rw=write \
          --bs=8M \
          --name=vdo \
          --filename=/dev/mapper/vdo-test \
          --ioengine=libaio \
          --thread \
          --direct=1 \
          --scramble_buffers=1
  3. Registre el rendimiento y la latencia reportados para el estímulo de entrada de lectura y escritura:

    # for readmix in 20 50 80; do
        for iosize in 4 8 16 32 64 128 256 512 1024; do
          fio --rw=rw \
              --rwmixread=$readmix \
              --bsrange=4k-256k \
              --name=vdo \
              --filename=/dev/mapper/vdo-name \
              --ioengine=libaio \
              --numjobs=1 \
              --thread \
              --norandommap \
              --runtime=300 \
              --direct=0 \
              --iodepth=$iosize \
              --scramble_buffers=1 \
              --offset=0 \
              --size=100g
        done
      done
  4. Retire el volumen de prueba VDO.

    Para más detalles, consulte Sección 4.3, “Limpieza del volumen de pruebas de rendimiento de VDO”.

  5. Grafique los resultados de la prueba.

    Ejemplo 4.4. Análisis del entorno de la aplicación

    La siguiente imagen muestra un ejemplo de cómo VDO podría responder a cargas de E/S mixtas:

    Figura 4.5. Rendimiento en entornos mixtos

    Mixed environment performance

4.8. Opciones utilizadas para probar el rendimiento de VDO con fio

Las pruebas VDO utilizan la utilidad fio para generar sintéticamente datos con características repetibles. Las siguientes opciones de fio son necesarias para simular las cargas de trabajo del mundo real en las pruebas:

Tabla 4.1. Usado fio opciones

ArgumentoDescripciónValor utilizado en las pruebas

--size

La cantidad de datos que fio envía al objetivo por trabajo.

Véase también la opción --numjobs.

100 GiB

--bs

El tamaño del bloque de cada solicitud de lectura y escritura producida por fio.

Red Hat recomienda un tamaño de bloque de 4 KiB para que coincida con los 4 KiB por defecto de VDO.

4k

--numjobs

El número de puestos de trabajo que crea fio para el punto de referencia.

Cada trabajo envía la cantidad de datos especificada por la opción --size. El primer trabajo envía los datos al dispositivo en el desplazamiento especificado por la opción --offset. Los trabajos subsiguientes sobrescriben la misma región del disco a menos que proporcione la opción --offset_increment, que desplaza cada trabajo desde el lugar donde comenzó el trabajo anterior por ese valor.

Para alcanzar el máximo rendimiento en los discos flash (SSD), Red Hat recomienda al menos dos trabajos. Un trabajo suele ser suficiente para saturar el rendimiento de los discos rotativos (HDD).

1 para HDD, 2 para SSD

--thread

Indica a los trabajos de fio que se ejecuten en hilos en lugar de bifurcarse, lo que podría proporcionar un mejor rendimiento al limitar el cambio de contexto.

none

--ioengine

El motor de E/S que fio utiliza para el benchmark.

Las pruebas de Red Hat utilizan el motor asíncrono sin búfer llamado libaio para probar las cargas de trabajo en las que uno o más procesos realizan peticiones aleatorias simultáneas. El motor libaio permite que un solo hilo realice múltiples peticiones de forma asíncrona antes de recuperar cualquier dato. Esto limita el número de cambios de contexto que requeriría un motor síncrono si proporcionara las peticiones de muchos hilos.

libaio

--direct

Esta opción permite que las peticiones enviadas al dispositivo se salten la caché de páginas del kernel.

Debe utilizar el motor libaio con la opción --direct. De lo contrario, el núcleo utiliza la API de sincronización para todas las solicitudes de E/S.

1 (libaio)

--iodepth

El número de buffers de E/S en vuelo en cualquier momento.

Un valor alto suele aumentar el rendimiento, sobre todo en las lecturas o escrituras aleatorias. Los valores altos garantizan que el controlador siempre tenga solicitudes para procesar. Sin embargo, un valor demasiado alto (normalmente superior a 1K) puede provocar una latencia no deseada.

Red Hat recomienda un valor entre 128 y 512. El valor final es un compromiso y depende de cómo tolere su aplicación la latencia.

128 como mínimo

--iodepth_batch_submit

El número de peticiones de E/S a crear cuando la reserva de búferes de profundidad de E/S comienza a vaciarse.

Esta opción limita el cambio de tareas de las operaciones de E/S a la creación de buffers durante la prueba.

16

--iodepth_batch_complete

El número de operaciones de E/S a completar antes de enviar un lote.

Esta opción limita el cambio de tareas de las operaciones de E/S a la creación de buffers durante la prueba.

16

--gtod_reduce

Desactiva las llamadas a la hora del día para calcular la latencia.

Este ajuste reduce el rendimiento si está activado. Habilite la opción a menos que necesite medir la latencia.

1

Capítulo 5. Descartar los bloques no utilizados

Puede realizar o programar operaciones de descarte en los dispositivos de bloque que las admitan.

5.1. Operaciones de descarte de bloques

Las operaciones de descarte de bloques descartan los bloques que ya no están en uso por un sistema de archivos montado. Son útiles en:

  • Unidades de estado sólido (SSD)
  • Almacenamiento con aprovisionamiento ligero

Requisitos

El dispositivo de bloque subyacente al sistema de archivos debe soportar operaciones de descarte físico.

Las operaciones de descarte físico se admiten si el valor del /sys/block/device/queue/discard_max_bytes es distinto de cero.

5.2. Tipos de operaciones de descarte de bloques

Se pueden ejecutar operaciones de descarte utilizando diferentes métodos:

Descarte de lotes
Son ejecutados explícitamente por el usuario. Descartan todos los bloques no utilizados en los sistemas de archivos seleccionados.
Descarte en línea
Se especifican en el momento del montaje. Se ejecutan en tiempo real sin intervención del usuario. Las operaciones de descarte en línea sólo descartan los bloques que están pasando de usados a libres.
Descarte periódico
Son operaciones por lotes que se ejecutan regularmente por un servicio de systemd.

Todos los tipos son compatibles con los sistemas de archivos XFS y ext4 y con VDO.

Recomendaciones

Red Hat recomienda utilizar el descarte por lotes o periódico.

Utilice el descarte en línea sólo si:

  • la carga de trabajo del sistema es tal que el descarte por lotes no es factible, o
  • las operaciones de descarte en línea son necesarias para mantener el rendimiento.

5.3. Realizar el descarte de bloques por lotes

Este procedimiento realiza una operación de descarte de bloques por lotes para descartar los bloques no utilizados en un sistema de archivos montado.

Requisitos previos

  • El sistema de archivos está montado.
  • El dispositivo de bloques subyacente al sistema de archivos admite operaciones de descarte físico.

Procedimiento

  • Utilice la utilidad fstrim:

    • Para realizar el descarte sólo en un sistema de archivos seleccionado, utilice:

      # fstrim mount-point
    • Para realizar el descarte en todos los sistemas de archivos montados, utilice:

      # fstrim --all

Si ejecuta el comando fstrim en:

  • un dispositivo que no admite operaciones de descarte, o
  • un dispositivo lógico (LVM o MD) compuesto por múltiples dispositivos, donde cualquiera de ellos no soporta operaciones de descarte,

aparece el siguiente mensaje:

# fstrim /mnt/non_discard

fstrim: /mnt/non_discard: the discard operation is not supported

Recursos adicionales

  • La página de manual fstrim(8)

5.4. Activación del descarte de bloques en línea

Este procedimiento permite realizar operaciones de descarte de bloques en línea que descartan automáticamente los bloques no utilizados en todos los sistemas de archivos compatibles.

Procedimiento

  • Activar el descarte en línea en el momento del montaje:

    • Al montar un sistema de archivos manualmente, añada la opción de montaje -o discard:

      # mount -o discard device mount-point
    • Al montar un sistema de archivos de forma persistente, añada la opción discard a la entrada de montaje en el archivo /etc/fstab.

Recursos adicionales

  • La página de manual mount(8)
  • La página de manual fstab(5)

5.5. Habilitación del descarte de bloques en línea mediante RHEL System Roles

Esta sección describe cómo habilitar el descarte de bloques en línea utilizando el rol storage.

Requisitos previos

  • Existe un playbook de Ansible que incluye el rol storage.

Para obtener información sobre cómo aplicar un libro de jugadas de este tipo, consulte Aplicar un rol.

5.5.1. Ejemplo de libro de jugadas de Ansible para activar el descarte de bloques en línea

Esta sección proporciona un ejemplo de libro de jugadas de Ansible. Este libro de jugadas aplica el rol storage para montar un sistema de archivos XFS con el descarte de bloques en línea activado.

Ejemplo 5.1. Un libro de jugadas que permite descartar bloques en línea en /mnt/data/

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: xfs
        mount_point: /mnt/data
        mount_options: discard
  roles:
    - rhel-system-roles.storage

Recursos adicionales

  • Para más detalles sobre los parámetros utilizados en el rol de sistema storage, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.

5.5.2. Recursos adicionales

5.6. Activación del descarte periódico de bloques

Este procedimiento habilita un temporizador systemd que descarta regularmente los bloques no utilizados en todos los sistemas de archivos compatibles.

Procedimiento

  • Activar e iniciar el temporizador systemd:

    # systemctl enable --now fstrim.timer

Capítulo 6. Visión general de los atributos de nomenclatura persistente

Como administrador del sistema, usted necesita referirse a los volúmenes de almacenamiento utilizando atributos de nomenclatura persistentes para construir configuraciones de almacenamiento que sean confiables a través de múltiples arranques del sistema.

6.1. Desventajas de los atributos de denominación no persistentes

Red Hat Enterprise Linux proporciona varias formas de identificar los dispositivos de almacenamiento. Es importante utilizar la opción correcta para identificar cada dispositivo cuando se utiliza para evitar acceder inadvertidamente al dispositivo equivocado, particularmente cuando se instalan o reformatean unidades.

Tradicionalmente, los nombres no persistentes en forma de /dev/sd(major number)(minor number) se utilizan en Linux para referirse a los dispositivos de almacenamiento. El rango de números mayores y menores y los nombres sd asociados se asignan a cada dispositivo cuando se detecta. Esto significa que la asociación entre el rango de números mayores y menores y los nombres sd asociados puede cambiar si el orden de detección del dispositivo cambia.

Este cambio en el ordenamiento podría ocurrir en las siguientes situaciones:

  • La paralelización del proceso de arranque del sistema detecta los dispositivos de almacenamiento en un orden diferente con cada arranque del sistema.
  • Un disco no se enciende o no responde a la controladora SCSI. Esto hace que no sea detectado por la sonda normal de dispositivos. El disco no es accesible para el sistema y los dispositivos subsiguientes tendrán su rango de números mayores y menores, incluyendo los nombres asociados sd desplazados hacia abajo. Por ejemplo, si un disco normalmente referido como sdb no es detectado, un disco normalmente referido como sdc aparecerá como sdb.
  • Un controlador SCSI (adaptador de bus de host, o HBA) no se inicializa, lo que provoca que no se detecten todos los discos conectados a ese HBA. A todos los discos conectados a los HBA comprobados posteriormente se les asignan diferentes rangos de números mayores y menores, y diferentes nombres asociados sd.
  • El orden de inicialización del controlador cambia si hay diferentes tipos de HBA en el sistema. Esto hace que los discos conectados a esos HBAs sean detectados en un orden diferente. Esto también puede ocurrir si los HBA se mueven a diferentes ranuras PCI en el sistema.
  • Los discos conectados al sistema con adaptadores de canal de fibra, iSCSI o FCoE pueden ser inaccesibles en el momento en que se comprueban los dispositivos de almacenamiento, debido a que una matriz de almacenamiento o un interruptor intermedio están apagados, por ejemplo. Esto puede ocurrir cuando un sistema se reinicia después de un fallo de alimentación, si la matriz de almacenamiento tarda más en ponerse en línea que el sistema en arrancar. Aunque algunos controladores de Canal de Fibra soportan un mecanismo para especificar un mapeo persistente de SCSI target ID a WWPN, esto no hace que se reserven los rangos de números mayores y menores, y los nombres asociados sd; sólo proporciona números SCSI target ID consistentes.

Estas razones hacen que no sea deseable utilizar el rango de números mayores y menores o los nombres asociados de sd al referirse a los dispositivos, como en el archivo /etc/fstab. Existe la posibilidad de que se monte el dispositivo incorrecto y se produzca una corrupción de datos.

Ocasionalmente, sin embargo, sigue siendo necesario referirse a los nombres de sd incluso cuando se utiliza otro mecanismo, como cuando se informan errores de un dispositivo. Esto se debe a que el núcleo de Linux utiliza los nombres de sd (y también las tuplas SCSI host/channel/target/LUN) en los mensajes del núcleo relativos al dispositivo.

6.2. Sistema de archivos e identificadores de dispositivos

Esta sección explica la diferencia entre los atributos persistentes que identifican los sistemas de archivos y los dispositivos de bloque.

Identificadores del sistema de archivos

Los identificadores del sistema de archivos están vinculados a un sistema de archivos concreto creado en un dispositivo de bloques. El identificador también se almacena como parte del sistema de archivos. Si copias el sistema de archivos a un dispositivo diferente, sigue llevando el mismo identificador del sistema de archivos. Por otro lado, si reescribes el dispositivo, por ejemplo, formateándolo con la utilidad mkfs, el dispositivo pierde el atributo.

Los identificadores del sistema de archivos son:

  • Identificador único (UUID)
  • Etiqueta

Identificadores de dispositivos

Los identificadores de dispositivo están vinculados a un dispositivo de bloque: por ejemplo, un disco o una partición. Si se reescribe el dispositivo, por ejemplo, formateándolo con la utilidad mkfs, el dispositivo mantiene el atributo, porque no se almacena en el sistema de archivos.

Los identificadores de los dispositivos son:

  • Identificador mundial (WWID)
  • UUID de la partición
  • Número de serie

Recomendaciones

  • Algunos sistemas de archivos, como los volúmenes lógicos, abarcan varios dispositivos. Red Hat recomienda acceder a estos sistemas de archivos utilizando identificadores de sistemas de archivos en lugar de identificadores de dispositivos.

6.3. Nombres de dispositivos gestionados por el mecanismo udev en /dev/disk/

Esta sección enumera los diferentes tipos de atributos de nomenclatura persistente que el servicio udev proporciona en el directorio /dev/disk/.

El mecanismo udev se utiliza para todo tipo de dispositivos en Linux, no sólo para los dispositivos de almacenamiento. En el caso de los dispositivos de almacenamiento, Red Hat Enterprise Linux contiene reglas udev que crean enlaces simbólicos en el directorio /dev/disk/. Esto le permite referirse a los dispositivos de almacenamiento por:

  • Su contenido
  • Un identificador único
  • Su número de serie.

Aunque los atributos de nomenclatura de udev son persistentes, en el sentido de que no cambian por sí solos en los reinicios del sistema, algunos también son configurables.

6.3.1. Identificadores del sistema de archivos

El atributo UUID en /dev/disk/by-uuid/

Las entradas de este directorio proporcionan un nombre simbólico que hace referencia al dispositivo de almacenamiento mediante un unique identifier (UUID) en el contenido (es decir, los datos) almacenado en el dispositivo. Por ejemplo:

/dev/disco/por-uuid/3e6be9de-8139-11d1-9106-a43f08d823a6

Puede utilizar el UUID para referirse al dispositivo en el archivo /etc/fstab utilizando la siguiente sintaxis:

UUID=3e6be9de-8139-11d1-9106-a43f08d823a6

Puedes configurar el atributo UUID al crear un sistema de archivos, y también puedes cambiarlo posteriormente.

El atributo Label en /dev/disk/by-label/

Las entradas de este directorio proporcionan un nombre simbólico que hace referencia al dispositivo de almacenamiento mediante un label en el contenido (es decir, los datos) almacenado en el dispositivo.

Por ejemplo:

/dev/disco/por-etiqueta/Boot

Puede utilizar la etiqueta para referirse al dispositivo en el archivo /etc/fstab utilizando la siguiente sintaxis:

ETIQUETA=Boot

Puede configurar el atributo Etiqueta al crear un sistema de archivos, y también puede modificarlo posteriormente.

6.3.2. Identificadores de dispositivos

El atributo WWID en /dev/disk/by-id/

El World Wide Identifier (WWID) es un identificador persistente, system-independent identifier, que el estándar SCSI exige a todos los dispositivos SCSI. Se garantiza que el identificador WWID es único para cada dispositivo de almacenamiento, e independiente de la ruta que se utilice para acceder al dispositivo. El identificador es una propiedad del dispositivo, pero no se almacena en el contenido (es decir, los datos) de los dispositivos.

Este identificador puede obtenerse emitiendo una consulta SCSI para recuperar los datos vitales del producto de identificación del dispositivo (página 0x83) o el número de serie de la unidad (página 0x80).

Red Hat Enterprise Linux mantiene automáticamente el mapeo apropiado del nombre del dispositivo basado en WWID a un nombre actual de /dev/sd en ese sistema. Las aplicaciones pueden usar el nombre /dev/disk/by-id/ para referenciar los datos en el disco, incluso si la ruta al dispositivo cambia, e incluso cuando se accede al dispositivo desde diferentes sistemas.

Ejemplo 6.1. Asignaciones WWID

Enlace simbólico WWIDDispositivo no persistenteNota

/dev/disk/by-id/scsi-3600508b400105e210000900000490000

/dev/sda

Un dispositivo con un identificador de página 0x83

/dev/disk/by-id/scsi-SSEAGATE_ST373453LW_3HW1RHM6

/dev/sdb

Un dispositivo con un identificador de página 0x80

/dev/disk/by-id/ata-SAMSUNG_MZNLN256HMHQ-000L7_S2WDNX0J336519-part3

/dev/sdc3

Una partición de disco

Además de estos nombres persistentes proporcionados por el sistema, también puede utilizar las reglas de udev para implementar nombres persistentes propios, asignados al WWID del almacenamiento.

El atributo UUID de la partición en /dev/disk/by-partuuid

El atributo UUID de la partición (PARTUUID) identifica las particiones tal y como se definen en la tabla de particiones GPT.

Ejemplo 6.2. Asignaciones de UUID de partición

PARTUUID symlinkDispositivo no persistente

/dev/disk/by-partuuid/4cd1448a-01

/dev/sda1

/dev/disk/by-partuuid/4cd1448a-02

/dev/sda2

/dev/disk/by-partuuid/4cd1448a-03

/dev/sda3

El atributo Path en /dev/disk/by-path/

Este atributo proporciona un nombre simbólico que hace referencia al dispositivo de almacenamiento mediante la dirección hardware path utilizada para acceder al dispositivo.

El atributo Path falla si cualquier parte de la ruta de hardware (por ejemplo, el ID PCI, el puerto de destino o el número LUN) cambia. Por lo tanto, el atributo Path no es fiable. Sin embargo, el atributo Path puede ser útil en uno de los siguientes escenarios:

  • Es necesario identificar un disco que se piensa sustituir más adelante.
  • Usted planea instalar un servicio de almacenamiento en un disco en una ubicación específica.

6.4. El identificador mundial con DM Multipath

Esta sección describe el mapeo entre el World Wide Identifier (WWID) y los nombres de dispositivos no persistentes en una configuración de Device Mapper Multipath.

Si hay varias rutas desde un sistema a un dispositivo, DM Multipath utiliza el WWID para detectarlo. DM Multipath presenta entonces un único "pseudo-dispositivo" en el directorio /dev/mapper/wwid, como /dev/mapper/3600508b400105df70000e00000ac0000.

El comando multipath -l muestra la asignación a los identificadores no persistentes:

  • Host:Channel:Target:LUN
  • /dev/sd nombre
  • major:minor número

Ejemplo 6.3. Asignaciones WWID en una configuración multirruta

Un ejemplo de salida del comando multipath -l:

3600508b400105df70000e00000ac0000 dm-2 vendor,product
[size=20G][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=0][active]
 \_ 5:0:1:1 sdc 8:32  [active][undef]
 \_ 6:0:1:1 sdg 8:96  [active][undef]
\_ round-robin 0 [prio=0][enabled]
 \_ 5:0:0:1 sdb 8:16  [active][undef]
 \_ 6:0:0:1 sdf 8:80  [active][undef]

DM Multipath mantiene automáticamente la asignación adecuada de cada nombre de dispositivo basado en WWID a su correspondiente nombre /dev/sd en el sistema. Estos nombres son persistentes a través de los cambios de ruta, y son consistentes cuando se accede al dispositivo desde diferentes sistemas.

Cuando se utiliza la función user_friendly_names de DM Multipath, el WWID se asigna a un nombre de la forma /dev/mapper/mpathN. Por defecto, esta asignación se mantiene en el archivo /etc/multipath/bindings. Estos nombres de mpathN nombres son persistentes mientras se mantenga ese archivo.

Importante

Si se utiliza user_friendly_names, se requieren pasos adicionales para obtener nombres consistentes en un clúster.

6.5. Limitaciones de la convención de nombres de dispositivos udev

Las siguientes son algunas limitaciones de la convención de nombres udev:

  • Es posible que el dispositivo no esté accesible en el momento en que se realiza la consulta porque el mecanismo de udev puede depender de la capacidad de consultar el dispositivo de almacenamiento cuando se procesan las reglas de udev para un evento de udev. Esto es más probable que ocurra con los dispositivos de almacenamiento Fibre Channel, iSCSI o FCoE cuando el dispositivo no se encuentra en el chasis del servidor.
  • El kernel puede enviar eventos udev en cualquier momento, haciendo que las reglas sean procesadas y posiblemente haciendo que los enlaces /dev/disk/by-*/ sean eliminados si el dispositivo no es accesible.
  • Puede haber un retraso entre el momento en que se genera el evento udev y el momento en que se procesa, como cuando se detecta un gran número de dispositivos y el servicio udevd del espacio de usuario tarda cierto tiempo en procesar las reglas de cada uno. Esto puede causar un retraso entre el momento en que el kernel detecta el dispositivo y cuando los nombres de /dev/disk/by-*/ están disponibles.
  • Los programas externos como blkid invocados por las reglas podrían abrir el dispositivo durante un breve período de tiempo, haciendo que el dispositivo sea inaccesible para otros usos.
  • Los nombres de los dispositivos gestionados por el mecanismo udev en /dev/disk/ pueden cambiar entre las principales versiones, lo que obliga a actualizar los enlaces.

6.6. Listado de atributos de nomenclatura persistente

Este procedimiento describe cómo averiguar los atributos de nomenclatura persistente de los dispositivos de almacenamiento no persistentes.

Procedimiento

  • Para listar los atributos UUID y Label, utilice la utilidad lsblk:

    $ lsblk --fs storage-device

    Por ejemplo:

    Ejemplo 6.4. Ver el UUID y la etiqueta de un sistema de archivos

    $ lsblk --fs /dev/sda1
    
    NAME FSTYPE LABEL UUID                                 MOUNTPOINT
    sda1 xfs    Boot  afa5d5e3-9050-48c3-acc1-bb30095f3dc4 /boot
  • Para listar el atributo PARTUUID, utilice la utilidad lsblk con la opción --output PARTUUID:

    $ lsblk --output PARTUUID

    Por ejemplo:

    Ejemplo 6.5. Ver el atributo PARTUUID de una partición

    $ lsblk --output +PARTUUID /dev/sda1
    
    NAME MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT PARTUUID
    sda1   8:1    0  512M  0 part /boot      4cd1448a-01
  • Para listar el atributo WWID, examine los objetivos de los enlaces simbólicos en el directorio /dev/disk/by-id/. Por ejemplo:

    Ejemplo 6.6. Ver el WWID de todos los dispositivos de almacenamiento del sistema

    $ file /dev/disk/by-id/*
    
    /dev/disk/by-id/ata-QEMU_HARDDISK_QM00001
    symbolic link to ../../sda
    /dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part1
    symbolic link to ../../sda1
    /dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part2
    symbolic link to ../../sda2
    /dev/disk/by-id/dm-name-rhel_rhel8-root
    symbolic link to ../../dm-0
    /dev/disk/by-id/dm-name-rhel_rhel8-swap
    symbolic link to ../../dm-1
    /dev/disk/by-id/dm-uuid-LVM-QIWtEHtXGobe5bewlIUDivKOz5ofkgFhP0RMFsNyySVihqEl2cWWbR7MjXJolD6g
    symbolic link to ../../dm-1
    /dev/disk/by-id/dm-uuid-LVM-QIWtEHtXGobe5bewlIUDivKOz5ofkgFhXqH2M45hD2H9nAf2qfWSrlRLhzfMyOKd
    symbolic link to ../../dm-0
    /dev/disk/by-id/lvm-pv-uuid-atlr2Y-vuMo-ueoH-CpMG-4JuH-AhEF-wu4QQm
    symbolic link to ../../sda2

6.7. Modificación de los atributos de nomenclatura persistente

Este procedimiento describe cómo cambiar el atributo de nomenclatura persistente UUID o Label de un sistema de archivos.

Nota

El cambio de los atributos de udev se produce en segundo plano y puede llevar mucho tiempo. El comando udevadm settle espera hasta que el cambio esté completamente registrado, lo que garantiza que su siguiente comando podrá utilizar el nuevo atributo correctamente.

En los siguientes comandos:

  • Sustituya new-uuid por el UUID que quieras establecer; por ejemplo, 1cdfbc07-1c90-4984-b5ec-f61943f5ea50. Puedes generar un UUID utilizando el comando uuidgen.
  • Sustituya new-label por una etiqueta; por ejemplo, backup_data.

Requisitos previos

  • Si va a modificar los atributos de un sistema de archivos XFS, desmóntelo primero.

Procedimiento

  • Para cambiar los atributos UUID o Label de un sistema de archivos XFS, utilice la utilidad xfs_admin:

    # xfs_admin -U new-uuid -L new-label storage-device
    # udevadm settle
  • Para cambiar los atributos UUID o Label de un sistema de archivos ext4, ext3, o ext2, utilice la utilidad tune2fs:

    # tune2fs -U new-uuid -L new-label storage-device
    # udevadm settle
  • Para cambiar el UUID o los atributos de la etiqueta de un volumen de intercambio, utilice la utilidad swaplabel:

    # swaplabel --uuid new-uuid --label new-label swap-device
    # udevadm settle

Capítulo 7. Uso de la consola web para gestionar los volúmenes del Optimizador de Datos Virtual

Configure el optimizador de datos virtual (VDO) mediante la consola web de RHEL 8.

Aprenderás a:

  • Crear volúmenes VDO
  • Formato de volúmenes VDO
  • Ampliar los volúmenes de VDO

Requisitos previos

  • La consola web de RHEL 8 está instalada y accesible.

    Para más detalles, véase Instalación de la consola web.

  • El paquete cockpit-storaged está instalado en su sistema.

7.1. Volúmenes VDO en la consola web

Red Hat Enterprise Linux 8 soporta Virtual Data Optimizer (VDO).

VDO es una tecnología de virtualización de bloques que combina:

Compresión
Para más detalles, consulte Activar o desactivar la compresión en VDO.
Deduplicación
Para más detalles, consulte Activar o desactivar la deduplicación en VDO.
Aprovisionamiento ligero
Para más detalles, consulte Volúmenes lógicos de aprovisionamiento fino (volúmenes finos).

Gracias a estas tecnologías, VDO:

  • Ahorra espacio de almacenamiento en línea
  • Comprime los archivos
  • Elimina las duplicaciones
  • Permite asignar más espacio virtual que el que proporciona el almacenamiento físico o lógico
  • Permite ampliar el almacenamiento virtual mediante el crecimiento

VDO puede crearse sobre muchos tipos de almacenamiento. En la consola web de RHEL 8, puede configurar VDO sobre:

  • LVM

    Nota

    No es posible configurar VDO sobre volúmenes de aprovisionamiento ligero.

  • Volumen físico
  • RAID por software

Para más detalles sobre la colocación de VDO en la pila de almacenamiento, véase Requisitos del sistema.

Recursos adicionales

7.2. Creación de volúmenes VDO en la consola web

Cree un volumen VDO en la consola web de RHEL.

Requisitos previos

  • Unidades físicas, LVMs, o RAID de las que se quiere crear VDO.

Procedimiento

  1. Inicie sesión en la consola web de RHEL 8.

    Para más detalles, consulte Iniciar sesión en la consola web.

  2. Haga clic en Storage.
  3. Haga clic en el icono en el cuadro VDO Devices.

    cabina de mando añadiendo vdo

  4. En el campo Name, introduzca el nombre de un volumen VDO sin espacios.
  5. Seleccione la unidad que desea utilizar.
  6. En la barra Logical Size, configure el tamaño del volumen VDO. Puede ampliarlo más de diez veces, pero tenga en cuenta con qué fin está creando el volumen VDO:

    • Para las máquinas virtuales activas o el almacenamiento en contenedores, utilice un tamaño lógico diez veces superior al tamaño físico del volumen.
    • Para el almacenamiento de objetos, utilice un tamaño lógico que sea tres veces el tamaño físico del volumen.

    Para más detalles, véase Despliegue de VDO.

  7. En la barra Index Memory, asigne memoria para el volumen VDO.

    Para más detalles sobre los requisitos del sistema VDO, consulte Requisitos del sistema.

  8. Seleccione la opción Compression. Esta opción puede reducir eficazmente varios formatos de archivo.

    Para más detalles, consulte Activar o desactivar la compresión en VDO.

  9. Seleccione la opción Deduplication.

    Esta opción reduce el consumo de recursos de almacenamiento al eliminar múltiples copias de bloques duplicados. Para más detalles, consulte Activar o desactivar la deduplicación en VDO.

  10. Opcional] Si desea utilizar el volumen VDO con aplicaciones que necesitan un tamaño de bloque de 512 bytes, seleccione Use 512 Byte emulation. Esto reduce el rendimiento del volumen VDO, pero debería ser necesario muy raramente. En caso de duda, déjelo desactivado.
  11. Haga clic en Create.

    cockpit crear diálogo vdo

Si el proceso de creación del volumen VDO tiene éxito, puede ver el nuevo volumen VDO en la sección Storage y formatearlo con un sistema de archivos.

cabina vdo creada

7.3. Formateo de volúmenes VDO en la consola web

Los volúmenes VDO actúan como unidades físicas. Para utilizarlos, es necesario formatearlos con un sistema de archivos.

Aviso

El formateo de VDO borrará todos los datos del volumen.

Los siguientes pasos describen el procedimiento para formatear volúmenes VDO.

Requisitos previos

Procedimiento

  1. Inicie sesión en la consola web de RHEL 8.

    Para más detalles, consulte Iniciar sesión en la consola web.

  2. Haga clic en Storage.
  3. Haz clic en el volumen VDO.
  4. Haga clic en la pestaña Unrecognized Data.
  5. Haga clic en Format.

    formato vdo de la cabina

  6. En el menú desplegable Erase, seleccione:

    Don’t overwrite existing data
    La consola web de RHEL sólo reescribe la cabecera del disco. La ventaja de esta opción es la velocidad de formateo.
    Overwrite existing data with zeros
    La consola web de RHEL reescribe todo el disco con ceros. Esta opción es más lenta porque el programa tiene que recorrer todo el disco. Utilice esta opción si el disco incluye algún dato y necesita reescribirlo.
  7. En el menú desplegable Type, seleccione un sistema de archivos:

    • El sistema de archivos XFS soporta grandes volúmenes lógicos, el cambio de unidades físicas en línea sin interrupción, y el crecimiento. Deje este sistema de archivos seleccionado si no tiene una preferencia fuerte diferente.

      XFS no admite la reducción de volúmenes. Por lo tanto, no podrá reducir el volumen formateado con XFS.

    • El sistema de archivos ext4 admite volúmenes lógicos, el cambio de unidades físicas en línea sin interrupción, el crecimiento y la reducción.

    También puede seleccionar una versión con el cifrado LUKS (Linux Unified Key Setup), que le permite cifrar el volumen con una frase de contraseña.

  8. En el campo Name, introduzca el nombre del volumen lógico.
  9. En el menú desplegable Mounting, seleccione Custom.

    La opción Default no asegura que el sistema de archivos se monte en el siguiente arranque.

  10. En el campo Mount Point, añada la ruta de montaje.
  11. Seleccione Mount at boot.

    formato lv de la cabina

  12. Haga clic en Format.

    El formateo puede tardar varios minutos dependiendo de las opciones de formateo utilizadas y del tamaño del volumen.

    Después de terminar con éxito, puede ver los detalles del volumen VDO formateado en la pestaña Filesystem.

    cabina vdo formateada

  13. Para utilizar el volumen VDO, haga clic en Mount.

En este punto, el sistema utiliza el volumen VDO montado y formateado.

7.4. Ampliación de volúmenes VDO en la consola web

Ampliar los volúmenes VDO en la consola web de RHEL 8.

Requisitos previos

  • El paquete cockpit-storaged está instalado en su sistema.
  • El volumen VDO creado.

Procedimiento

  1. Inicie sesión en la consola web de RHEL 8.

    Para más detalles, consulte Iniciar sesión en la consola web.

  2. Haga clic en Storage.
  3. Haga clic en su volumen VDO en el cuadro VDO Devices.

    cabina vdo creada

  4. En los detalles del volumen VDO, haga clic en el botón Grow.
  5. En el cuadro de diálogo Grow logical size of VDO, amplíe el tamaño lógico del volumen VDO.

    cabina vdo crecer hecho

    El tamaño original del volumen lógico de la captura de pantalla era de 6 GB. Como puede ver, la consola web de RHEL le permite hacer crecer el volumen a más de diez veces el tamaño y funciona correctamente debido a la compresión y deduplicación.

  6. Haga clic en Grow.

Si el proceso de crecimiento de VDO tiene éxito, puede ver el nuevo tamaño en los detalles del volumen VDO.

detalles del cockpit vdo grow