启用丢弃HP 3PAR StoreServ 7400

从这些先前提出的问题中分解出来

如何从挂载的驱动器Redhat 7中获得可用空间

更新crypttab要求输入fstrim的密码

我们有一台HP 3PAR StoreServ 7400，可在38台主机上提供170个VM。

据我所知，这是一个问题：（还告诉我一些信息，我不确定它是否正确，我已经阅读了HP 3PAR StoreServ 7400白皮书，但实际上找不到任何备份我的存储人员的东西告诉我。因此，在下面的内容中，如果有人发现不正确的内容，请告诉我。）

3个PAR分为3个部分，

第1层：SSD用于缓存和快速访问常用文件。

第2层和第3层：某种类型的旋转磁盘，尚不确定什么以及为什么还有另外2层，但是我的假设是，第2层用于不是最常访问的数据，但是访问一点，第3层用于其余的存储。

正如我在许多文章中读到的，在SSD部分中，当将数据写入SSD块，然后删除该块时，直到将新数据写入该块时，该块才归零。因此，当删除该块中的数据时，存储映射的表info得到更新，然后将新数据写入同一块时，首先需要将该块清零，然后再将其写入。如果未调整驱动器的周期性，则SSD内的此过程可能导致较低的w / r速度。

3PAR LUN是精简配置的，而VM则是精简配置的。

据我的存储人员说，HP 3PAR内置了一项特殊功能，该功能允许根据需要将SSD存储不用于其他VM。

事实检查：

厚置备的VM是VMDK文件，在创建VM时，您指定VM的大小，这将创建VMDK文件。在我看来，如果定期访问VM，则整个VMDK文件将移至SDD，他们告诉我的是，即使VMDK设置为使用40GB，也可以在其中使用40GB的一部分。其他VM？在我看来，这听起来像是精简配置的VM，而不是厚实的VM。

确定问题了。

在我们的Windows系统上，我们使用sdelete查找并归零未使用的块。

在我们的Linux Fedora系统上，我一直在试图弄清楚如何使fstrim正常工作。

我确实尝试了dd = write-big-file delete-big-file命令，该命令通过屋顶发送了磁盘I / O，这被注意到了，并被告知不要再这样做。

经过一些研究，我发现sdelete与dd = write-big-file delete-big-file几乎具有相同的作用，因此为什么磁盘I / O不能通过Windows系统的屋顶？

所以我认为我已将其缩减为两种解决方案。我都不知道该怎么办。

1. 某种程度上，无需将VM垂直​​移动到其他存储阵列，就能够在SAN的整个SSD部分上运行类似fstrim的功能。

旁注：如果我了解我所读的所有内容，fstrim会查看每个块以查看是否有数据，是否需要，如果不需要，则会将该块清零，因为sdelete会在其中写入一个大文件，然后将其删除。这就是为什么我要在3PAR的整个SSD部分中寻找fstrim选项。

2. 长镜头，但我得到的fstrim错误是：

[root @ rhtest〜]＃fstrim -v / fstrim：/：不支持丢弃操作

我已经读过，需要在OS和数据存储区上同时设置丢弃选项，但是我无法弄清楚在3PAR上何处或如何设置丢弃选项，因为我同时具有对3PAR的SSH和GUI访问权限。

我已经经历了无数的关于在OS中设置丢弃的演练，无论旋转的方式有多少，我总是会遇到相同的错误。

是的，我也研究过其他选项，zerofree是其中一种，还有其他一些我不介意的东西，但是它们要么像zdelete一样工作，要么我读到它们非常危险，我研究了hdparam等。

下面，我将介绍一些有关操作系统的输出，它们都是相同的。

[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

能够在/分区上运行fstrim是最好的解决方案，但是用它们配置ESXi的方式将是不可能的。

您需要能够在VM和存储设备上都启用丢弃功能。

尝试使用xfs文件系统减小分区或逻辑卷的大小是无法做到的，这是fedora的已知错误。如果您对此功能感兴趣，请联系Red Hat支持并参考Red Hat bugzilla 1062667，并提供您需要减少/缩小XFS的用例。

作为在某些环境中的一种可能的解决方法，可以将精简配置的LVM卷视为XFS文件系统下方的附加层。

如果虚拟机急需厚置备的VMDK，则意味着在尝试修剪（从技术上来说； SCSI UNMAP）卷时，没有什么可回收的。

如果后端存储正在运行精简资源调配，那么您还需要使用延迟归零的VMDK文件，以减少存储量，并使后端可以缓存/删除热数据。

两种可能的选择：

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

从我可以看出，它的作用与sdelete相同，但是它可能导致磁盘I / O激增，并且需要一段时间才能运行。

一夜之间可以尝试的东西

这两种方法都不是最佳选择，但是重新格式化每个VM以获取ext3或ext4听起来并不可行。

您可能能够做的是为所有linux VM设置关联规则，并使用上面的选项1。

您正在使用急切的厚置备VMDK，这意味着在尝试修剪（从技术上来说； SCSI UNMAP）卷时，没有什么可以回收的。

如果后端存储正在运行精简资源调配，那么您还需要使用延迟归零的VMDK文件，以减少存储量，并使后端可以缓存/删除热数据。