Получите ответ на эти ранее заданные вопросы
Как получить свободное место на смонтированном диске 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 имеет тонкое выделение, а виртуальные машины - Eager Thick.
По словам моего специалиста по хранению данных, в 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 просматривает каждый блок, чтобы увидеть, есть ли там данные, и если они нужны, если они не нужны, обнулит блок, тогда как sdelete записывает огромный файл, а затем удаляет его. Вот почему я ищу вариант fstrim для всей части SSD 3PAR.
[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) свои тома.
Если внутреннее хранилище работает с тонкой подготовкой, вам также необходимо использовать ленивый обнулить файлы VMDK, чтобы уменьшить объем хранилища и сделать возможным кэширование / дедупликацию горячих данных серверной частью.