Увімкнути відкидання HP 3PAR StoreServ 7400

Відкрутіться від цих раніше заданих питань

Як отримати вільний простір з змонтованого накопичувача Redhat 7

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

У нас є HP 3PAR StoreServ 7400 із потужністю 170 ВМ на 38 хостів.

Ось така проблема, як я її розумію: (Також мені сказали деяку інформацію, яка не впевнена, правда це чи ні, я прочитав посібник HP 3PAR StoreServ 7400 і справді не можу знайти нічого, що б створило резервну копію того, що є моїм зберігачем скажіть мені. Тож у нижченаведеному, якщо хтось помітить щось неправдиве, будь ласка, дайте мені знати.)

3 ПАР розділено на 3 секції,

Шар 1: SSD, що використовується для кешування та швидкого доступу до файлів, що часто отримують доступ.

Шар 2: і 3 рівень: якийсь диск, що обертається, що і чому є додаткові 2 шари, не впевнені, але моє припущення, що рівень 2 використовується для даних, які не є найчастіше доступними, але для доступу є біт, а рівень 3 використовується для зберігання решти.

У розділі SSD, як я читав у багатьох статтях, коли дані записуються до блоку SSD, а потім видаляються, цей блок не занулюється до тих пір, поки до нього не будуть записані нові дані. Отже, коли дані всередині блоку видаляються, таблиця, в якій зберігається відображення інформація оновлюється, тоді, коли нові дані записуються в той самий блок, спочатку блок повинен бути нульовим, а потім його можна записати. Цей процес всередині SSD, якщо привід не оброблений періодичністю, може призвести до зниження швидкості ш / р.

3PAR LUN тонкий за умови, що VM - це Eager Thick.

За словами мого хлопця з пам’яті, 3PAR має вбудовану особливість, яка дозволяє використовувати SSD-накопичувач у разі необхідності, щоб бути доступним для інших ВМ, що не має сенсу.

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

Товстий розміщений VM - це файли VMDK, при створенні VM ви вказуєте розмір VM, і це створює файл VMDK. На мій погляд, це говорить мені про те, що якщо доступ до VM регулярно отримується, весь файл VMDK потім переміщується в SDD, і те, що вони мені говорять, це те, що навіть якщо VMDK налаштований на використання 40 ГБ, то деякі з цих 40 ГБ можуть бути використані на інші ВМ? Це звучить більше для мене, як тонкий представлений VM не товстий.

Добре дістатися до проблеми.

У наших системах Windows ми використовуємо sdelete для пошуку та зняття нуля невикористаних блоків.

У нашій системі Fedora Linux я постійно намагався зрозуміти, як змусити fstrim працювати.

Я спробував команду dd = write-big-file delete-big-file, і він надіслав диск вводу / виводу через дах, про що було помічено, і мені сказали не робити цього знову.

Здійснюючи невелике дослідження, мені здається, що sdelete в значній мірі робить те ж саме, що і dd = write-big-file delete-big-file, тому чому диск вводу / виводу не проходить крізь дах на системах Windows?

Тож я думаю, що я знищив це до двох рішень. Жоден з яких я не знаю, як це зробити.

1. Якимось чином без пересування VM на інший масив пам'яті зможе запустити функцію, подібну до 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 це було б неможливо.

Потрібно мати можливість увімкнути скидки як на VM, так і на запам'ятовуючий пристрій.

Спроба зменшити розмір розділу чи логічного обсягу з файловою системою xfs неможливо, це відома помилка з Fedora. Якщо вас зацікавила ця функція, зверніться до служби технічної підтримки Red Hat та довідкової програми Red Hat bugzilla 1062667 та надайте свій приклад використання для зменшення / скорочення XFS.

Як можлива обробка в деяких середовищах, тонкі передбачені обсяги LVM можуть розглядатися як додатковий шар нижче файлової системи XFS.

Якщо VM не хочуть отримати товстий 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, однак це може спричинити сплеск дискового вводу / виводу, а також зайняти деякий час.

Щось спробувати протягом ночі

Будь-який варіант не найкращий, але переформатування кожного VM для отримання ext3 або ext4 не здається можливим.

Що ви можете зробити, це налаштувати правило афінності для всіх віртуальних машин Linux та використовувати варіант 1 зверху.

Ви використовуєте нетерплячі товсті VMDK, а це означає, що немає чого відшкодувати, коли ви намагаєтеся обрізати (технічно кажучи; SCSI UNMAP) свої обсяги.

Якщо резервне сховище працює з тонким резервуванням, вам також потрібно використовувати ліниві нульові файли VMDK, щоб зменшити обсяг пам’яті та зробити можливим для бекенда кешувати / виводити теплі дані.