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.
- 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.
- 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