Вопрос или проблема
У меня есть сервер ESXi с хранилищем HP LeftHand, подключенным через iSCSI.
У меня есть виртуальная машина с диском на 1TB, из которых используется 800GB. Диск выделен на хранилище LeftHand с полным резервированием.
Снимок был открыт на VM (чтобы Veeam Backup and Recovery мог выполнять свои функции) и был открыт примерно 6 часов. За это время был создан дельта-диск объемом около 5GB.
Удаление снимка занимает уже более 5 часов и все еще не завершено. Система хранения практически не сообщает о IOPS (около 600, что является фоновым шумом), не показывает пропускной способности (около 8MB/сек, что снова является фоновым шумом), средняя глубина очереди составляет 9.
Другими словами, процесс консолидации снимка, похоже, не зависит от ввода-вывода, я не вижу ничего, что могло бы вызвать такую ужасную медлительность удаления снимка. Он работает, судя по наблюдениям за дельта-файлами.
Есть ли что-то еще, на что мне следует обратить внимание, чтобы понять, почему этот (относительно небольшой) снимок так медленно удаляется?
Согласно документации 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
Я полагаю, что один файл снимка консолидация во время, когда другой собирает дельта во время процесса консолидации. Затем новый файл консолидации, и другой дельта создается в процессе.
Размеры файлов уменьшаются с каждой итерацией (ну, с большей частью итераций), поэтому я предполагаю, что в конечном итоге эта процедура консолидации завершится (возможно, мне придется отключить VM от сети на 30 минут, чтобы это закончилось без изменения).
Это занимает около 2 минут на каждые сто мегабайт дельта для консолидации. Это определенно никогда не происходило раньше. Удаление снимка при нормальном резервном копировании Veeam занимает около 40 минут (так что, конечно, это не быстро, но и не так медленно).
После 6 часов и 2 минут снимок наконец удален. Тем не менее, мне все еще хотелось бы знать, есть ли какой-либо способ, которым вы обычно устраняете проблемы с подобными вопросами (за пределами производительности хранения).
Я понимаю, что удаление снимков ESXI может (и обычно занимает) много времени. Перед тем, как снимок может быть удален, изменения из старого снимка должны быть записаны в следующий снимок по очереди. Меня учили всегда удалять снимки от старого к новому, чтобы помочь этому процессу проходить как можно быстрее и эффективнее.
Естественно, чем больше изменений между снимками, тем дольше будет объединение.
К сожалению, нет решения для удаления снимков из ESXi или Vcenter. Вам придется ждать, пока он не будет удален, и не останавливать его никаким образом в процессе удаления.
Ответ или решение
При работе с виртуализированными машинами в среде VMware ESXi часто возникает необходимость удалять снимки (snapshot), однако процесс удаления может занять гораздо больше времени, чем предполагалось. В описанном вами случае, несмотря на то что снятый снимок имел объем данных в 5 ГБ и был активен всего 6 часов, его удаление заняло более 6 часов. Давайте рассмотрим возможные причины этой проблемы и методы их диагностики.
Факторы, влияющие на скорость удаления снимка
-
Объем изменений и структура снимков:
При любой операции по сооружению (консолидации) снимка все изменения, произошедшие с момента создания снимка, должны быть включены в основной виртуальный диск. Если между снимками произошло множество изменений (и в вашем случае это около 800 ГБ), то это требует значительных ресурсов. Даже если сами данные снимка небольшие, алгоритм соединения может столкнуться с большим количеством данных. -
Параметры окружения и инфраструктура:
Важно учитывать параметры сети и хранилища. Поскольку ваша система использует HP LeftHand с подключением по iSCSI, проанализируйте следующие аспекты:- Загрузка сети: Если другие виртуальные машины активно используют сеть, это может значительно замедлить процесс.
- Нагрузка на хранилище: Хотя вы отмечаете, что IOPS на уровне 600 кажется низким, надо также проверять другие метрики хранилища, такие как задержка, планирование запросов и использование контроллера.
-
Конфигурация Veeam Backup:
Veeam использует свои методы для создания снимков, что может повлиять на производительность при их удалении. Например, если во время удаления происходит бэкап, это может создать дополнительные накладные расходы на ресурсы.
Диагностика производительности
Для диагностики и улучшения ситуации можно использовать следующие подходы:
-
Мониторинг сети и хранилища: Используйте инструменты мониторинга (такие как VMware vRealize Operations или встроенные инструменты мониторинга хранилища) для отслеживания загрузки сети и IOPS во время удаления снимка.
-
Анализ конфигурации: Проверьте параметры конфигурации вашей виртуальной машины и хранилища. Убедитесь, что настройки iSCSI оптимальны для вашей нагрузки.
-
Обновление ПО: Убедитесь, что версии VMware ESXi и Veeam актуальны. Иногда обновления ПО могут исправить ошибки и улучшить производительность.
Рекомендации по выполнению операций
-
Удаление снимков по порядку: Удаляйте снимки в порядке их создания — от старых к новым. Это уменьшит объем данных, которые нужно обрабатывать, и работа консолидации будет быстрее.
-
Изолирование нагрузки: По возможности желательно временно отключить сетевые функции виртуальной машины, чтобы минимизировать изменения операций во время удаления снимка.
-
Планирование операций: Если у вас есть возможность, выполняйте операции удаление или создание снимков в периоды низкой нагрузки, чтобы минимизировать влияние на производительность.
Заключение
Удаление снимков в среде VMware может быть медленным процессом, особенно если не учитывать определенные факторы, такие как объем изменений и нагрузки на инфраструктуру. Важно проводить постоянный мониторинг и диагностику, чтобы выявлять потенциальные узкие места и улучшать производительность операции. Следуя вышеуказанным рекомендациям, вы сможете оптимизировать свои процессы работы с виртуальными машинами, делая их более эффективными и управляемыми.