Activer les suppressions HP 3PAR StoreServ 7400

Retombée de ces questions posées précédemment

Comment obtenir de l'espace libre à partir du lecteur monté Redhat 7

La mise à jour de crypttab demande une phrase secrète pour fstrim

Nous avons un HP 3PAR StoreServ 7400 avec 170 machines virtuelles réparties sur 38 hôtes.

Voici le problème tel que je le comprends: (De plus, on m'a dit que je ne sais pas si c'est vrai ou non, j'ai lu le livre blanc HP 3PAR StoreServ 7400 et je ne trouve vraiment rien qui sauvegarde ce qu'est mon type de stockage alors, si vous remarquez quelque chose de faux, faites-le moi savoir.)

Le 3 PAR est divisé en 3 sections,

Couche 1: SSD utilisé pour mettre en cache et accéder rapidement aux fichiers couramment utilisés.

Couche 2: et couche 3: une sorte de disque en rotation, quoi et pourquoi il y a 2 couches supplémentaires dont je ne suis pas sûr, mais mon hypothèse est que la couche 2 est utilisée pour les données qui ne sont pas le plus souvent accessibles mais accèdent un peu et la couche 3 est utilisée pour stockage du reste.

Dans la partie SSD, comme j'ai lu dans de nombreux articles lorsque les données sont écrites dans un bloc SSD, puis supprimé, ce bloc n'est pas mis à zéro jusqu'à ce que de nouvelles données y soient écrites.Ainsi, lorsque les données dans le bloc sont supprimées, la table qui stocke le mappage les informations sont mises à jour, puis lorsque de nouvelles données sont écrites dans ce même bloc, le bloc doit d'abord être mis à zéro, puis il peut être écrit. Ce processus au sein du SSD si le lecteur n'est pas coupé périodiquement peut conduire à des vitesses w / r plus faibles.

Le 3PAR LUN est alloué de manière fine, les machines virtuelles sont allouées de manière épaisse.

Selon mon spécialiste du stockage, le 3PAR a une fonctionnalité spéciale intégrée qui permet au stockage SSD non utilisé d'être disponible pour les autres machines virtuelles selon les besoins, ce qui n'a aucun sens.

Vérification des faits:

Une VM provisionnée épaisse est un fichier VMDK, lorsque la VM est créée, vous spécifiez la taille de la VM et cela crée un fichier VMDK. Dans mon esprit, cela me dit que si la VM est régulièrement consultée, l'intégralité du fichier VMDK est ensuite déplacé vers SDD, et ce qu'ils me disent, c'est que même si le VMDK est configuré pour utiliser 40 Go, une partie de ces 40 Go peut être utilisée sur d'autres VM? Cela me semble plus comme une machine virtuelle allouée mince pas un épais.

Ok, j'arrive au problème.

Sur nos systèmes Windows, nous utilisons sdelete pour trouver et supprimer les blocs inutilisés.

Sur notre système Linux Fedora, j'ai essayé de comprendre comment faire fonctionner fstrim.

J'ai essayé la commande dd = write-big-file delete-big-file et cela a envoyé les E / S disque à travers le toit, ce qui a été remarqué, et on m'a dit de ne pas recommencer.

En faisant un peu de recherche, il me semble que sdelete fait à peu près la même chose que dd = write-big-file delete-big-file alors pourquoi les E / S de disque ne passent-elles pas par le toit sur les systèmes Windows?

Je pense donc que je l'ai réduit à deux solutions. Je ne sais ni comment faire.

1. D'une manière ou d'une autre, sans v-motion, les machines virtuelles vers une autre matrice de stockage peuvent exécuter une fonction de type fstrim sur toute la partie SSD du SAN.

Note latérale: Si je comprends tout ce que j'ai lu, fstrim regarde chaque bloc pour voir si des données sont là et si elles sont nécessaires, si elles ne sont pas nécessaires, le bloc sera mis à zéro, où sdelete écrit un énorme fichier puis le supprime. C'est pourquoi je recherche une option fstrim sur toute la partie SSD du 3PAR.

2. Longshot mais l'erreur que j'obtiens avec fstrim est:

[root @ rhtest ~] # fstrim -v / fstrim: /: l'opération de suppression n'est pas prise en charge

J'ai lu que l'option de suppression doit être définie à la fois sur le système d'exploitation et la banque de données, mais je ne peux pas savoir où ni comment définir une option de suppression sur le 3PAR.J'ai à la fois un accès SSH et GUI au 3PAR.

J'ai parcouru d'innombrables procédures pas à pas pour configurer les rejets dans le système d'exploitation et peu importe le nombre de façons différentes dont je le fais, j'obtiens toujours la même erreur.

Oui, j'ai également examiné d'autres options, zerofree en était une, et quelques autres qui ne me viennent pas à l'esprit, mais elles fonctionnaient comme zdelete, ou j'ai lu qu'elles étaient très dangereuses, j'ai examiné le hdparam, etc.

Ci-dessous, je mettrai une sortie sur le système d'exploitation en question, ils sont tous les mêmes.

[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

Être capable d'exécuter fstrim sur les partitions / serait la meilleure solution mais avec la façon dont votre ESXi est configuré, ce ne serait pas possible.

Vous devez être en mesure d'activer les rejets sur la machine virtuelle et le périphérique de stockage.

Essayer de réduire la taille d'une partition ou d'un volume logique avec le système de fichiers xfs ne peut pas être fait. C'est un bogue connu avec fedora. Si vous êtes intéressé par cette fonctionnalité, veuillez contacter le support Red Hat et faire référence à Red Hat bugzilla 1062667, et fournir votre cas d'utilisation pour avoir besoin d'une réduction / réduction XFS.

Comme contournement possible dans certains environnements, les volumes LVM à allocation dynamique peuvent être considérés comme une couche supplémentaire sous le système de fichiers XFS.

Si les VM sont des VMDK provisionnés avec impatience, cela signifie qu'il n'y a rien à récupérer lorsque vous essayez de couper (techniquement parlant; SCSI UNMAP) vos volumes.

Si le stockage back-end exécute un provisionnement fin, vous devez également utiliser des fichiers VMDK à mise à zéro différée afin de réduire le stockage et permettre au backend de mettre en cache / dédoubler les données chaudes.

Deux options possibles:

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

D'après ce que je peux dire, cela fait la même chose que sdelete, mais cela peut provoquer un pic dans les E / S du disque et prendre un certain temps à s'exécuter.

Quelque chose à essayer du jour au lendemain

Les deux options ne sont pas les meilleures, mais le reformatage de chaque machine virtuelle pour obtenir ext3 ou ext4 ne semble pas faisable.

Ce que vous pourriez faire est de configurer une règle d'affinité pour toutes les machines virtuelles Linux et d'utiliser l'option 1 ci-dessus.

Vous utilisez un VMDK provisionné épais, ce qui signifie qu'il n'y a rien à récupérer lorsque vous tentez de couper (techniquement parlant; SCSI UNMAP) vos volumes.

Si le stockage back - end est en marche thin provisioning alors vous devez également utiliser paresseux fichiers VMDK mises à zéro afin de réduire le stockage et le rendre possible pour le back - end de cache / dedup les données chaudes.