Меня часто спрашивают о производительности работы технологии Instant VM Recovery.
Напомню, в таком варианте скорость восстановления целой виртуальной машины фактически равна скорости загрузки этой ВМ, так как никакие данные не копируются, а машина просто запускается непосредственно из архивных файлов (дедуплицированных и сжатых).
Достигая высокого значения RTO, приходится платить производительностью дисковой подсистемы ВМ, пока она не будет перенесена обратно на высокопроизводительную систему хранения. Для переноса необходимо выбрать наиболее подходящий способ миграции, например:
- Storage vMotion - миграция дисков ВМ, без остановки ВМ.
- Клонирование работающей ВМ (hot-cloning).
- Репликация ВМ (например, с помощью Veeam Backup & Replication).
- Перенос файлов выключенной ВМ в запланированном окне.
Но все же стоит вопрос, а насколько мы теряем в производительности? Сколько по времени будет происходить полное восстановление ВМ - не только доступность сервисов, но и восстановление производительности?
На сайте Veeam есть очень интересный документ от компании openBench Labs. В нем описаны проведенные тесты производительности резервного копирования, и в частности производительность IVMR.
Ниже цифры тестирования работы ВМ с Exchange Server 2010 (500 почтовых ящиков, общий объем данных порядка 220 ГБ), работающего под нагрузкой (Jetstress benchmark), дающие ответы на вышеозначенные вопросы.
Производительность
При восстановлении ВМ через Instant VM Recovery существуют два варианта работы с дисковой подсистемой восстанавливаемой машины: оставить изменяемую в процессе работы ВМ дельту на vPower NFS, при этом доступен Storage vMotion для миграции; или записывать дельту на более производительную СХД, доступную хосту ESXi, но в данном случае vMotion для переноса диска не доступен.
Кроме того, сам процесс переноса файлов ВМ на другую систему, тоже сказывается на производительности.
Вот данные, полученные в результате тестов:
- При записи изменений на vPower NFS - 140 писем / 38 транзакций в секунду
- При переносе (Storage vMotion) - 60 писем / 25 транзакций в секунду
- При записи изменений на внешней СХД - 290 писем /105 транзакций в секунду
- При клонировании (hot-cloning) - 150 писем / 50 транзакций в секунду
При этом стоит учитывать, что при Strorage vMotion ВМ не останавливается в своей работе, а самое главное - сохраняет все данные; в то время, как в случае с горячим клонированием, необходимо выключить ВМ, и затем включить ее копию. При этом, в при клонировании, данные сохранятся только до момента старта процесса клонирования, т.е. такой вариант чаще всего неприемлем для ВМ, содержащие данные (почтовые серверы, СУБД и т.п.), но можно использовать для ВМ с сервисами (напр., веб-приложения, использующие БД на выделенном сервере).
В качестве альтернативы клонированию, при невозможности использования SvMotion, лучше использовать функцию репликации в Veeam Backup & Replication - чтобы получить точную копию работающей ВМ с актуальными данными. Но в этом случае также необходимо выключить ВМ, и включить ее копию (запланировать краткосрочную остановку сервиса на переключение).
Немного о самих цифрах. Даже в самом наихудшем варианте (во время миграции vMotion) уровень нагрузки практически такой же, как в типичных нагруженных критически важных машинах.
В любом случае, процесс переноса лучше отложить на время наименьшей загрузки ВМ и сети (после рабочего дня).
Время восстановления
Очень важно знать, сколько времени понадобиться на полное восстановление ВМ, с учетом процесса миграции файлов ВМ в основную систему хранения данных.
Тесты показали:
- Публикация ВМ в vSphere - 22 секунды
- Загрузка ВМ - 67 секунд
- Время на полное восстановление (перенос SvMotion) - 2 часа 50 минут
- Время на полное восстановление (перенос клонированием) - 3 часа 10 минут
Итого получаем менее 2х минут на восстановление доступности сервиса, и порядка трех часов на полное восстановление ВМ с более 200 ГБ данных.
Выводы и рекомендации
Вот вы и получили цифры для подготовки SLA и ответы на вопросы о производительности.
Жаль, что не тестировался вариант репликации восстанавливаемой ВМ с помощью VBR. Но зная технологию можно предположить, что влияние на производительность будет таким же, как и hot-clonning, но время переноса вероятней всего увеличится за счет дополнительных реплик.
Наилучшие сценарии восстановления я вижу такие:
- Самый простой и без остановок в работе сервиса:
- Запустить Instant VM Recovery без перенаправления данных на внешнее хранилище.
- В период спада нагрузки на сервис (ночь) запустить Storage vMotion для переноса ВМ в основное хранилище.
- При необходимости увеличения производительности ВМ:
- Запустить Instant VM Recovery с перенаправления данных на внешнюю СХД.
- В период спада нагрузки на сервис (ночь) запустить репликацию ВМ (VBR) для переноса ВМ в основное хранилище.
- Выключить ВМ (не отключая Instant VM Recovery!)
- Сделать еще одну реплику, чтобы получить точную копию ВМ.
- Включить реплику.
- Выключить Instant VM Recovery.
При больших объемах изменяемых данных, можно провести несколько репликаций (перед выключением ВМ - пункт c), чтобы уменьшить дельту и сократить время “финализирующей” реплики (в пункте d).
Постоянный адрес статьи
Комментариев нет:
Отправить комментарий