Разрешить сбрасывать HP 3PAR StoreServ 7400

Спин от этих ранее заданных вопросов

Как получить свободное место от смонтированного диска Redhat 7

Обновление crypttab запрашивает пароль для fstrim

У нас есть HP 3PAR StoreServ 7400 со 170 ВМ, распределенными по 38 хостам.

Вот проблема, как я ее понимаю: (Кроме того, мне сказали, что я не уверен, правда это или нет, я перечитал технический документ HP 3PAR StoreServ 7400 и действительно не могу найти ничего, что могло бы сделать резервную копию того, чем занимается мой хранитель говорит мне. Так что на протяжении всего ниже, если кто-то замечает что-то не так, пожалуйста, дайте мне знать.)

3 PAR разбит на 3 секции,

Уровень 1: SSD используется для кэширования и быстрого доступа к часто используемым файлам.

Слой 2: и Слой 3: Какой-то вращающийся диск, что и почему есть дополнительные 2 слоя, в которых я не уверен, но я предполагаю, что Слой 2 используется для данных, к которым обычно не обращаются, но к битам доступа, а Слой 3 используется для хранение остатка.

Внутри части SSD, как я читал во многих статьях, когда данные записываются в блок SSD, а затем удаляются, этот блок не обнуляется, пока в него не будут записаны новые данные, поэтому, когда данные внутри блока удаляются, таблица, в которой хранится отображение Информация обновляется, затем, когда новые данные записываются в этот же блок, сначала необходимо обнулить блок, а затем записать в него. Этот процесс в SSD, если привод не отключен, периодичность может привести к снижению скорости вращения.

3PAR LUN имеет тонкую настройку, виртуальные машины настроены на полную мощность.

По словам моего хранителя, в 3PAR встроена специальная функция, которая позволяет не использовать хранилище SSD для других ВМ по мере необходимости, что не имеет смысла.

Проверка фактов:

Виртуальная машина с толстой подготовкой - это файлы VMDK. Когда создается виртуальная машина, вы указываете размер виртуальной машины, и это создает файл VMDK. По-моему, это говорит мне о том, что при регулярном доступе к ВМ весь файл VMDK затем перемещается на SDD, и они говорят мне, что даже если VMDK настроен на использование 40 ГБ, некоторые из этих 40 ГБ могут использоваться на другие виртуальные машины? Для меня это больше похоже на тонкую подготовленную виртуальную машину, а не на толстую.

Хорошо, добираемся до проблемы.

В наших системах Windows мы используем sdelete для поиска и обнуления неиспользуемых блоков.

В нашей системе Linux Fedora я пытался понять, как заставить работать fstrim.

Я попробовал команду dd = write-big-file delete-big-file, и она отправила дисковый ввод-вывод через крышу, что было замечено, и мне сказали, что больше этого не нужно делать.

Проведя небольшое исследование, мне кажется, что sdelete делает то же самое, что и dd = write-big-file delete-big-file, так почему дисковый ввод-вывод не проходит через систему Windows?

Так что я думаю, что сократил это до двух решений. Ни чего я не знаю как сделать.

1. Каким-то образом, не перемещая виртуальные машины в другой массив хранения, можно запускать fstrim-подобную функцию во всей части SSD SAN.

Примечание: если я понимаю все, что прочитал, fstrim просматривает каждый блок, чтобы увидеть, есть ли данные, и если они нужны, если не нужно, обнулит блок, где sdelete пишет огромный файл, а затем удаляет его. Вот почему я ищу опцию fstrim во всей части SSD 3PAR.

2. Longshot, но ошибка, которую я получаю с fstrim:

[root @ rhtest ~] # fstrim -v / fstrim: /: операция удаления не поддерживается

Я читал, что опция сброса должна быть установлена ​​как в ОС, так и в хранилище данных, но я не могу понять, где и как установить опцию сброса в 3PAR. У меня есть доступ по SSH и GUI к 3PAR.

Я прошел через бесчисленное множество пошаговых инструкций по настройке сбросов в ОС, и неважно, сколько разных способов его раскручивать, я всегда получаю одну и ту же ошибку.

Да, я также рассмотрел другие варианты, 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 это было бы невозможно.

Вы должны иметь возможность разрешать сброс как на виртуальной машине, так и на устройстве хранения.

Попытка уменьшить размер раздела или логического тома с помощью файловой системы 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, однако это может вызвать скачок дискового ввода-вывода, а также запустить его.

Что-то, чтобы попробовать в одночасье

Любой из этих вариантов не лучший, но переформатирование каждой виртуальной машины для получения ext3 или ext4 не представляется возможным.

То, что вы можете сделать, это настроить правило сродства для всех виртуальных машин Linux и использовать опцию 1 сверху.

Вы используете готовый VMDK с толстой подготовкой, что означает, что вам нечего восстанавливать, когда вы пытаетесь урезать (технически говоря, SCSI UNMAP) ваши тома.

Если хранение бэкенд работает Thin Provisioning , то вы также должны использовать ленивые обнуляется файлы VMDK для того , чтобы уменьшить объем и сделать возможным для внутреннего интерфейса в кэш / DeDup данные теплые.