Habilitar descartes HP 3PAR StoreServ 7400

13

Spin off de estas preguntas anteriores

Cómo obtener espacio libre de la unidad montada Redhat 7

Actualizar crypttab solicita la frase de contraseña para fstrim

Tenemos un HP 3PAR StoreServ 7400 con 170 máquinas virtuales distribuidas en 38 hosts.

Aquí está el problema tal como lo entiendo: (También me han dicho alguna información que no estoy seguro de si es verdad o no, he leído el documento técnico HP 3PAR StoreServ 7400 y realmente no puedo encontrar nada que respalde lo que es mi tipo de almacenamiento diciéndome, así que a lo largo de lo siguiente, si alguien nota algo que no es cierto, hágamelo saber

El 3 PAR se divide en 3 secciones,

Capa 1: SSD utilizado para almacenar en caché y acceder rápidamente a los archivos de acceso común.

Capa 2: y Capa 3: algún tipo de disco giratorio, qué y por qué hay 2 capas adicionales de las que no estoy seguro, pero supongo que la Capa 2 se usa para datos a los que no se accede con mayor frecuencia pero que se accede un poco y la Capa 3 se usa para almacenamiento del resto.

Dentro de la porción SSD, como he leído en muchos artículos, cuando los datos se escriben en un bloque SSD y luego se eliminan, ese bloque no se pone a cero hasta que se escriben nuevos datos, por lo tanto, cuando los datos dentro del bloque se eliminan, la tabla que almacena la asignación la información se actualiza, luego, cuando se escriben nuevos datos en ese mismo bloque, primero se debe poner a cero el bloque y luego se puede escribir en él. Este proceso dentro de SSD si la unidad no está programada periódicamente puede conducir a velocidades más bajas de w / r.

El 3PAR LUN tiene un aprovisionamiento ligero y las máquinas virtuales están aprovisionadas con Eager Thick.

Según mi chico de almacenamiento, el 3PAR tiene una característica especial incorporada que permite que el almacenamiento SSD no esté disponible para que esté disponible para las otras máquinas virtuales, según sea necesario, lo que no tiene sentido.

Revisión de hechos:

Una máquina virtual de aprovisionamiento grueso es un archivo VMDK, cuando se crea la máquina virtual, usted especifica el tamaño de la máquina virtual y esto crea un archivo VMDK. En mi opinión, eso me dice que si se accede regularmente a la VM, todo el archivo VMDK se mueve a SDD, y lo que me dicen es que incluso si el VMDK está configurado para usar 40 GB, algunos de esos 40 GB se pueden usar en otras máquinas virtuales? Eso me parece más como una máquina virtual aprovisionada delgada, no una gruesa.

Ok llegando al problema.

En nuestros sistemas Windows utilizamos sdelete para encontrar y poner a cero los bloques no utilizados.

En nuestro sistema Linux Fedora, he estado tratando de descubrir cómo hacer que fstrim funcione.

Intenté el comando dd = write-big-file delete-big-file y eso envió la E / S del disco a través del techo, lo cual se notó y me dijeron que no volviera a hacer eso.

Investigando un poco, me parece que sdelete hace más o menos lo mismo que dd = write-big-file delete-big-file, entonces, ¿por qué la E / S de disco no pasa por alto en los sistemas Windows?

Así que creo que lo he reducido a dos soluciones. Ninguno de los cuales sé hacer.

  1. De alguna manera, sin mover las máquinas virtuales a una matriz de almacenamiento diferente, puede ejecutar una función similar a fstrim en toda la porción SSD de la SAN.

Nota al margen: si entiendo todo lo que he leído, fstrim examina cada bloque para ver si hay datos y si es necesario, si no es necesario, el bloque se pondrá a cero, donde como sdelete escribe un archivo enorme y luego lo elimina. Es por eso que estoy buscando una opción fstrim en toda la parte SSD del 3PAR.

  1. Longshot pero el error que obtengo con fstrim es:

[root @ rhtest ~] # fstrim -v / fstrim: /: la operación de descarte no es compatible

He leído que la opción de descarte debe establecerse tanto en el sistema operativo como en el almacén de datos, pero no puedo averiguar dónde o cómo establecer una opción de descarte en el 3PAR. Tengo acceso tanto SSH como GUI al 3PAR.

He pasado por innumerables recorridos para configurar los descartes dentro del sistema operativo y no importa cuántas formas diferentes lo gire, siempre obtengo el mismo error.

Sí, también he examinado otras opciones zerofree era una, y un par de otras que no me vienen a la mente, sin embargo, funcionaron como zdelete, o leí que eran muy peligrosas, busqué en el hdparam, etc.

A continuación pondré algunos resultados sobre el sistema operativo en cuestión, todos son iguales.

[root@rhtest ~]# hostnamectl
    Static hostname: rhtest.domain.com
    Icon name: computer-vm
    Chassis: vm
    Machine ID: f52e8e75ae704c579e2fbdf8e7a1d5ac
    Boot ID: 98ba6a02443d41cba9cf457acf5ed194
    Virtualization: vmware
    Operating System: Red Hat Enterprise Linux Server 7.2 (Maipo)
    CPE OS Name: cpe:/o:redhat:enterprise_linux:7.2:GA:server
    Kernel: Linux 3.10.0-327.el7.x86_64
    Architecture: x86-64

[root@rhtest ~]# blkid
    /dev/block/8:2: UUID="2OHGU8-ir1w-LLGB-6v72-zZqN-CIaX-FjGImJ" TYPE="LVM2_member"
    /dev/block/253:1: UUID="ad872f09-5147-4252-af56-aa6244219515" TYPE="xfs"
    /dev/block/8:1: UUID="83aac355-a443-4ff9-90fa-9f6da8e31cc2" TYPE="xfs"
    /dev/block/253:0: UUID="dbe56f6a-2a4a-42da-82e2-bef9a73caafb" TYPE="swap"

[root@rhtest ~]# lsblk
    NAME                           MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
    fd0                              2:0    1    4K  0 disk
    sda                              8:0    0   50G  0 disk
    ââsda1                           8:1    0  500M  0 part /boot
    ââsda2                           8:2    0 49.5G  0 part
        âârhel_-rhtest-swap 253:0    0    2G  0 lvm  [SWAP]
        âârhel_-rhtest-root 253:1    0 47.5G  0 lvm  /
    sdb                              8:16   0   50G  0 disk
    sr0                             11:0    1 1024M  0 rom


[root@rhtest ~]# df -h
    Filesystem                              Size  Used Avail Use% Mounted on
    /dev/mapper/rhel_-rhtest-root   48G  883M   47G   2% /
    devtmpfs                                991M     0  991M   0% /dev
    tmpfs                                  1001M     0 1001M   0% /dev/shm
    tmpfs                                  1001M  8.5M  993M   1% /run
    tmpfs                                  1001M     0 1001M   0% /sys/fs/cgroup
    /dev/sda1                               497M  124M  374M  25% /boot
    tmpfs                                   201M     0  201M   0% /run/user/0
Anthony Fornito
fuente

Respuestas:

10

Ser capaz de ejecutar fstrim en las particiones / sería la mejor solución, sin embargo, con la forma en que está configurado su ESXi, no sería posible.

Debe poder habilitar los descartes tanto en la VM como en el dispositivo de almacenamiento.

Intentar reducir el tamaño de una partición o volumen lógico con el sistema de archivos xfs no se puede hacer, este es un error conocido con fedora. Si está interesado en esta funcionalidad, póngase en contacto con el soporte de Red Hat y haga referencia al bugzilla 1062667 de Red Hat, y proporcione su caso de uso para necesitar la reducción / reducción de XFS.

Como posible solución en algunos entornos, los volúmenes LVM aprovisionados delgados se pueden considerar como una capa adicional debajo del sistema de archivos XFS.

Si las máquinas virtuales están ansiosas por el VMDK aprovisionado, lo que significa que no hay nada que reclamar cuando intenta recortar (técnicamente hablando; SCSI UNMAP) sus volúmenes.

Si el almacenamiento de back-end está ejecutando un aprovisionamiento delgado, entonces también debe usar archivos VMDK a cero diferidos para reducir el almacenamiento y hacer posible que el backend guarde en caché / dedupta los datos cálidos.

Dos posibles opciones:

1. When storage is provided by a remote server across a SAN, you can only discard blocks if the storage is thin provisioned.

    1. VMotion all the VM's to a different data store and use the built-in VMWare tools
    2. Connect to the ESXi Host with SSH
    3. Navigate to the Virtual Machine Folder
    4. Verify disk usage with du
    5. Run vmkfstools -K [disk]
    6. Verify disk usage with du

2.  dd if=/dev/zero of=BIGFILE bs=1024000
    rm -f BIGFILE

Por lo que puedo decir, esto hace lo mismo que sdelete, sin embargo, puede causar un pico en la E / S del disco y también demorar un tiempo en ejecutarse.

Algo para probar durante la noche

Cualquiera de las opciones no es la mejor, pero reformatear cada VM para obtener ext3 o ext4 no parece factible.

Lo que puede hacer es configurar una regla de afinidad para todas las máquinas virtuales de Linux y usar la opción 1 de arriba.

Brian Curless
fuente
3

Está utilizando VMDK aprovisionado grueso y ansioso, lo que significa que no hay nada que reclamar cuando intenta recortar (técnicamente hablando; SCSI UNMAP) sus volúmenes.

Si el almacenamiento de back-end está acabando el aprovisionamiento, entonces también es necesario utilizar perezosos archivos VMDK puestos a cero con el fin de reducir el almacenamiento y hacer posible que el backend para cache / dedup los datos cálidos.

pauska
fuente
Gracias por responder, sin embargo, no estoy seguro de entender completamente su respuesta, si todas mis suposiciones de la pregunta son correctas, sería necesario reclamar los bloques distintos de cero de la SAN, especialmente si el archivo VMDK se mueve de SSD a disco giratorio. ¿Correcto?
Anthony Fornito
3
@AnthonyFornito No puedes reclamar nada con discos gruesos ansiosos. El grosor entusiasta significa que VMWare obliga al almacenamiento de back-end a escribir la asignación completa de cada archivo, incluidos los ceros.
pauska
@pauska es totalmente correcto. 3PAR y muchas soluciones similares están diseñadas para compresión / deduplicación / niveles. Su modelo híbrido 3PAR tiene más que ver con la eficiencia de la capacidad y no con la configuración orientada al rendimiento. Es por eso que es mejor usar discos diferidos a cero en lugar de ansiosos a cero en su caso.
Strepsils