Разрешить отбрасывать 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, если диск не тримедирован периодичностью, может привести к более низким скоростям w / r.
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?
Итак, я думаю, что сократил это до двух решений. Ни чего делать не умею.
- Каким-то образом, не перемещая виртуальные машины в другой массив хранения, можно запустить функцию, подобную fstrim, на всей SSD-части SAN.
Дополнительное примечание: если я понимаю все, что я прочитал, fstrim просматривает каждый блок, чтобы увидеть, есть ли там данные, и если они нужны, если они не нужны, обнулит блок, тогда как sdelete записывает огромный файл, а затем удаляет его. . Вот почему я ищу вариант fstrim для всей части SSD 3PAR.
- Я получаю ошибку при использовании fstrim:
[root @ rhtest ~] # fstrim -v / {{ 1}} fstrim: /: операция сброса не поддерживается
Я читал, что параметр сброса должен быть установлен как в ОС, так и в хранилище данных, но я не могу понять, где и как установить параметр сброса в 3PAR У меня есть доступ к 3PAR как через SSH, так и через графический интерфейс.
Я прошел через бесчисленное количество пошаговых руководств по настройке сброса в ОС, и независимо от того, сколько разных способов я его раскручиваю, я всегда получаю одну и ту же ошибку.
Да, я также изучал другие варианты, один из которых был 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 с отложенным обнулением, чтобы уменьшить объем хранилища и сделать возможным backend для кэширования / дедупликации «теплых» данных.
Два возможных варианта:
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) ваши тома.
Если серверная часть хранилище работает с тонким выделением ресурсов, тогда вам также необходимо использовать ленивые обнуленные файлы VMDK, чтобы уменьшить объем хранилища и сделать возможным кэширование / дедупликацию горячих данных серверной частью.