Неймовірно повільне видалення знімка


13

У мене є вікно ESXi з пам'яттю HP LeftHand, відкрите через iSCSI.

У мене віртуальна машина з 1 ТБ диска, з яких витрачається 800 ГБ. Диск товстий, передбачений на сховищі LeftHand.

Знімок був відкритий на VM (щоб Veeam Backup and Recovery міг зробити свою справу) і був відкритий близько 6 годин. За цей час був створений дельта-диск приблизно 5 Гб.

Видалення знімка зайняло більше 5 годин і досі не завершено. Масив зберігання повідомляє практично про відсутність IOPS на цьому масиві (близько 600, що є фоновим шумом), відсутність пропускної здатності (близько 8 Мб / сек, що знову - фоновий шум), середня глибина черги 9.

Іншими словами, процес консолідації знімків, здається, не пов'язаний з IO, я не бачу нічого, що спричиняє видалення знімка, настільки чортово повільним. Це буде працювати, якщо судити, спостерігаючи файли дельта.

Все, на що я повинен звернути увагу, чому цей (порівняно невеликий) знімок так повільно видаляється?


Відповідно до документації VMWare , я переглядаю ls -lh | grep -E "delta|flat|sesparse"зараз і бачу два дельта файли, які змінюються:

-rw-------    1 root     root      194.0M Jun 15 01:28 EXAMPLE-000001-delta.vmdk
-rw-------    1 root     root      274.0M Jun 15 01:27 EXAMPLE-000002-delta.vmdk

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

Розміри файлів будуть падати з кожної ітерації (ну, більшість ітерацій), тому я вважаю , що в кінцевому рахунку ця процедура консолідації буде завершена (можливо , мені доведеться взяти віртуальну машину від мережі в протягом 30 хвилин , щоб це закінчити , не створюючи будь - яких змін) .

Для консолідації потрібно близько 2 хвилин на сто мег дельти. Це, звичайно, ніколи раніше не бувало. Видалення знімків у звичайному режимі резервного копіювання Veeam займає близько 40 хвилин (так, звичайно, не швидко, але не так повільно).


Через 6 годин і 2 хвилини знімок остаточно видаляється. Однак я все-таки хотів би знати, чи є у вас спосіб вирішити цю проблему (за межами продуктивності пам’яті).


Я не можу не помітити, що 8Mbit / секунда досить близька до мережі 10Mbit / sec мінус деяка накладні витрати. Чи є ймовірність, що це проблема, пов’язана з мережею, на посиланні iSCSI - ухильний виправлений патч тільки починає виходити з ладу? Це одиночне посилання, єдиний хост, чи хост інакше виконує ОК для постійного читання / запису? Чи можете ви перевірити порт комутатора на наявність помилок?
TesselilingHeckler

@TessellatingHeckler Я просто зробив кілька тестів, і я все ще можу отримати близько 1,5 Гбіт / сек послідовний з масиву, що я б очікував отримати від нього за звичайних обставин. Минулої ночі зняття знімка зайняло три хвилини, що на сьогоднішній день є найшвидшим, який я коли- небудь бачив (як правило, це приблизно в 10 разів, але минулої ночі тут була велика футбольна гра, тому я підозрюю, що ніхто не використовував системи через години коли резервні копії виконуються, отже, крихітна дельта та малий час здійснення). Тож це можна зробити швидко, тільки колись цього не зробили.
Марк Хендерсон

Хм. У вас працює VMware Storage IO Control і чи зберігається сховище даних з іншими ВМ? Будь-який шанс, що це вдарив про якийсь обмежувальний / м'який ліміт там, не підкреслюючи обладнання хоста чи SAN?
TessellatingHeckler

Версія ESXi та vCenter?
Нілс

@Nils 5,5 для обох
Марк Хендерсон

Відповіді:


2

Наскільки я розумію, що видалення знімків ESXI може (і зазвичай це потрібно) тривати тривалий час. Перед тим, як знімок можна буде зняти, зміни зі старого знімка потрібно записати до наступного знімка для того, щоб. Мене навчали завжди видаляти знімки від найдавніших до останніх, щоб допомогти цьому процесу протікати якнайшвидше та ефективніше.

Природно, чим більше змін між знімками, тим довше буде тривати злиття.


1
Правильно, окрім 6 годин, щоб зняти знімок 5 Гб, це абсурд. Як я вже згадував, для зняття знімка зазвичай потрібно 40 хвилин, і я навіть відчуваю, що 40 хвилин занадто проклято повільно. Це був єдиний знімок із цієї VM, а також видалення знімків змінилось у пізніших версіях ESXi, оскільки порядок, у який вони видаляються, не має великого значення.
Марк Хендерсон

2
Раніше я бачив повільну поведінку знімків із невеликим введенням-виведенням у пам’яті, але ніколи не відстежував це до причини. Я завжди просто припускав, що гіпервізор жує дельта в пам’яті. (Машини, про які йдеться, використовували накопичувачі, що безпосередньо підключаються, або я, можливо, також переглядав проблеми SAN, але я завжди додав їх до великих дельт або неоптимізованого коду в підсистемі знімків VMWare).
voretaq7
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.