Продолжу пересказ интересных статей про изменения в новой редакции vSphere. Сегодня выбор пал на статью про изменения механизма Storage vMotion. Кроме этого, очень советую почитать серьёзный документ “The Design and Evolution of Live Storage Migration in VMware ESX”, описывающий эволюцию и результаты тестов различных реализаций миграции, а также ещё одну замечательную статью – vSphere 5.0: Storage vMotion and the Mirror Driver.
Storage vMotion позволяет мигрировать запущенный ВМ между хранилищами без остановки. Впервые данный механизм был реализован для перехода с VMFS-2 на VMFS-3, тогда он еще так не назывался и чаще упоминался как Upgrade vMotion.
Быстро стало очевидно, что многие функции могут быть реализованы с помощью Storage vMotion, такие как тиринг, перемещение ВМ при потребности в обслуживании, удалении/выводе из эксплуатации хранилищ.
Лежащие в основе технологии претерпели множественные изменения со времен первой версии, и снова в версии vSphere 5.0 представлен новый эффективный механизм миграции, который улучшил производительность и надежность операции.
В ESX 3.5 миграция основывалась на традиционном механизме снимков ВМ. Создавался снимок ВМ с исходного диска и операции ввода/ввода ложились на него с этого момента. Изменения базового диска прекращались и его можно было перемещать на целевое хранилище. Когда базовый диск был перемещен, фиксировались все изменения, отраженные в снимке, на диск в целевом хранилище. Однако, если ВМ была очень нагружена, дельта-снимок мог стать большого размера и окончание процесса фиксации изменений могло занять много времени.
В версии 4.х механизм снова был усовершенствован с помощью функции Changed Block Tracking (слежения за измененными блоками) – CBT. Это означало, что Storage vMotion больше не требуется использовать снимки, которые могут сильно вырасти при интенсивных операция ввода/вывода, и заняло бы много времени на завершение перемещения. CBT отслеживает какие блоки изменились с момента получения первой копии. Затем рекурсивно проивзодится один или несколько проходов копирования, пока количество измененных блоков не станет настолько мало, что позволит переключить ВМ на новое хранилище через операцию Fast Suspend/Resume. Данный механизм очень похож на обычный vMotion. Опять же, если ВМ сильно нагружена, то миграция может занять много времени на выполнение большого количества проходов.
В версии 5.0 проблема большого количества проходов была решена, теперь операция Storage vMotion делается в один проход. Для этого используется новый механизм Mirror Driver (драйвер зеркалирования) чтобы обеспечить синхронизацию блоков на целевом хранилище при любых изменениях относительно первоначальной копии. Миграция выполняется в один проход, все блоки копируются на целевое хранилище. Если блоки были изменены после начала копированя, то они синхронизируются из исходного диска на целевой посредством драйвера зеркалирования. Рекурсивные проходы больше не требуются. Это означает, что операция миграции занимает меньше времени.
Дополнительные возможности Storage vMotion в vSphere 5.0:
- Миграция ВМ со снимками/связанными клонами.
- Storage vMotion позволил реализовать новую технику балансировки дисковой нагрузки – Storage DRS .
Иногда возникает вопрос – почему в логе наблюдаются ссылки на предварительное копирование памяти во время Storage vMotion? Так вот, данного копирования нет. Это просто артефакт инфраструктуры используемой для миграции в vmkernel, которая также используется и обычным vMotion. Память атомарно передается целевой ВМ во время операции Fast suspend/Resume (stun), которая эффективно переключает ВМ на диски целевого хранилища.
Еще одно замечание, касающееся путаницы сетевых коммуникаций и Storage vMotion. Операции Storage vMotion выполняются внутри одиночного хоста ESXi либо на хранилище при использовании VAAI. Каких-либо операций на сетевом уровне через управляющую сеть или Storage vMotion не возникает. Часть управляющих операций могут иметь место между vpxa/hostd/vpxd/nfc (network file copy), но все основные операции передачи данных являются внутренними для ESXi через функцию VMkernel Data Mover (либо внутренними для системы хранения при использовании VAAI). В ранних версия ESX для передачи части файлов ВМ, например, логов, использовался механизм nfc (network file copy), который больше не используется.
Спасибо, интересная серия статей. Читаю с удовольствием.
Хотел бы дополнить статью описанием процеса Storage vMotion, чтобы было полное понимание того, как он работает.
1. Директория виртуальной машины копируется посредством VPXA на целевое виртуальное хранилище
2. На целевом хранилище запускается “теневая” виртуальная машина, использующая скопированные файлы. “Теневая” ВМ после этого приостанавливается и ожидает завершения копирования vmdk файлов.
3. Storage vMotion указывает Storage vMotion Mirror драйверу зеркалировать операции записи уже скопированных, но изменённых на исходном хранилище, блоков на целевое хранилище.
4. Копирование файлов виртуальной машины производится в один проход, в процессе зеркалирования операций I/O.
5. Storage vMotion вызывает Fast Suspend и далее Resume виртуальной машины (как при vMotion), для того чтобы переместить работающую ВМ на “теневую” ВМ.
6. После завершения Fast Suspend и Resume старая директория и файлы ВМ удаляются с исходного хранилища.