Vmware отключить миграцию виртуальной машины

Обновлено: 04.07.2024

В этой статье приведены общие сведения о параметрах поддержки и ограничениях для миграции виртуальных машин VMware с помощью службы Миграции Azure — средства миграции сервера. Если вы ищете сведения об оценке виртуальных машин VMware для миграции в Azure, ознакомьтесь с таблицей поддержки оценки.

Варианты переноса

Выполнить миграцию виртуальных машин VMware можно несколькими способами:

С использованием миграции без агента. Выполнение миграции виртуальных машин без необходимости установки каких-либо компонентов. Для миграции без агента разверните устройство Миграции Azure.
С использованием миграции на основе агента. Установите на виртуальной машине агент для репликации. Для миграции на основе агента разверните устройство репликации.

Ознакомьтесь с этой статьей, чтобы выяснить, какой метод вам подходит.

Миграция без агента

В этом разделе перечислены требования к миграции виртуальной машины VMware в Azure без агента.

Требования к VMware (без агента)

В таблице перечислены требования гипервизора VMware.

- Datastore.Browse (Хранилище данных -> Обзор хранилища данных). Разрешение на обзор файлов журналов виртуальных машин для устранения неполадок при создании и удалении моментальных снимков.

- Datastore.FileManagement (Хранилище данных -> Низкоуровневые операции с файлами). Разрешение на операции чтения, записи, удаления и переименования в браузере хранилища данных для устранения неполадок при создании и удалении моментальных снимков.

- VirtualMachine.Config.DiskLease (Виртуальная машина -> Аренда диска). Разрешение операций аренды диска для виртуальной машины, чтобы прочитать его с помощью пакета средств разработки виртуального диска VMware vSphere (VDDK).

- VirtualMachine.Provisioning.DiskRandomRead (Виртуальная машина -> Подготовка -> Разрешение доступа к диску только для чтения). Разрешение на открытие диска на виртуальной машине, чтобы прочитать его с помощью VDDK.

- VirtualMachine.Provisioning.DiskRandomAccess (Виртуальная машина -> Подготовка -> Разрешение доступа к диску). Разрешение на открытие диска на виртуальной машине, чтобы прочитать его с помощью VDDK.

- VirtualMachine.Provisioning.GetVmFiles (Виртуальная машина -> Подготовка -> Разрешение загрузки виртуальной машины). Разрешение операций чтения для файлов, связанных с виртуальной машиной, для скачивания журналов и устранения неполадок в случае сбоя.

- VirtualMachine.State.* _ (Виртуальная машина -> Управление снимком). Разрешение создания моментальных снимков виртуальной машины и управления ими для репликации.

Требования к виртуальной машине (без агента)

В таблице приведены требования к миграции без агента для виртуальных машин VMware.

Помимо проверки подключения к Интернету, для виртуальных машин Linux убедитесь, что для успешной установки агента Microsoft Azure Linux (waagent) установлены следующие пакеты:

Python 2.6+
OpenSSL 1.0 и более поздней версии
OpenSSH 5.3 и более поздней версии
Служебные программы файловой системы: sfdisk, fdisk, mkfs, parted
Инструменты работы с паролями: chpasswd, sudo
Инструменты обработки текста: sed, grep
Сетевые инструменты: ip-route

При использовании портала Azure для настройки репликации можно выбрать до 10 виртуальных машин за раз. Для репликации большего количества виртуальных машин можно использовать портал и добавить виртуальные машины для репликации в нескольких пакетах по 10 виртуальных машин или использовать интерфейс PowerShell в службе "Миграция Azure" для настройки репликации. Убедитесь, что не настроена одновременная репликация количества, превышающего максимально поддерживаемое количество виртуальных машин.

Требования к устройству (без агента)

Миграция без агента использует устройство Миграции Azure. Вы можете развернуть устройство как виртуальную машину VMware с помощью шаблона OVA, импортированного в vCenter Server, либо с использованием скрипта PowerShell.

Узнайте больше о требованиях к устройству для VMware.
Узнайте больше о URL-адресах Azure, к которым устройство будет обращаться в общедоступных облаках и облаках для государственных организаций.
В Azure для государственных организаций необходимо развернуть устройство с помощью скрипта.

Требования к портам (без агента)

Миграция на основе агента

В этом разделе описаны требования к миграции на основе агента.

Требования к VMware (на основе агента)

В этой таблице приведены сведения о поддержке и ограничениях для серверов виртуализации VMware.

Требования к VMware	Сведения
VMware vCenter Server	Версия 5.5, 6.0, 6.5 или 6.7.
Узел ESXI VMware vSphere	Версия 5.5, 6.0, 6.5 или 6.7.
Разрешения vCenter Server	Учетная запись только для чтения для vCenter Server.

Требования к виртуальной машине (на основе агента)

В таблице представлены сведения о поддержке виртуальных машин VMware, для которых нужно выполнить миграцию на основе агента.

Поддержка	Сведения
Рабочая нагрузка компьютера	Служба "Миграция Azure" поддерживает репликацию любой рабочей нагрузки (например, Active Directory, SQL Server и т. д.), выполняемой на поддерживаемом компьютере.
Операционные системы	Для получения последних сведений ознакомьтесь с поддержкой операционной системы для Site Recovery. Служба "Миграция Azure" обеспечивает такую же поддержку операционной системы виртуальной машины.
Файловая система Linux и гостевое хранилище	Для получения последних сведений ознакомьтесь с поддержкой файловой операционной системы Linux для Site Recovery. Служба "Миграция Azure" обеспечивает такую же поддержку файловой системы Linux.
Сеть и хранилище	Для получения последних сведений ознакомьтесь с требованиями к сети и хранилищу для Site Recovery. Служба "Миграция Azure" предоставляет идентичные требования к сети или хранилищу.
Требования Azure	Для получения последних сведений ознакомьтесь с требованиями к сети Azure, хранилищу, и вычислениям для Site Recovery. Служба "Миграция Azure" предусматривает такие же требования к миграции VMware.
Служба Mobility Service	Агент службы "Мобильность" необходимо установить на каждой виртуальной машине, которую вы хотите переместить.
Загрузка UEFI	Поддерживается. Виртуальные машины на основе UEFI будут перенесены на виртуальные машины Azure 2-го поколения.
Безопасная загрузка UEFI.	Не поддерживается для миграции.
Целевой диск	Виртуальные машины можно перенести только на управляемые диски (HDD (цен. категория "Стандартный"), SSD (цен. категория "Стандартный" и "Премиум")) в Azure.
Размер диска	Диск ОС размером до 2 ТБ для виртуальной машины поколения 1; диск ОС размером до 4 ТБ для виртуальных машин поколения 2; 32 ТБ для дисков данных.
Ограничения для дисков	До 63 дисков на одну виртуальную машину.
Зашифрованные диски и тома	Виртуальные машины с зашифрованными дисками или томами не поддерживаются для миграции.
Кластер общих дисков	Не поддерживается.
Независимые диски	Поддерживается.
Сквозные диски	Поддерживается.
NFS	Тома NFS, подключенные как тома на виртуальных машинах, не реплицируются.
Цели iSCSI	Поддерживается.
Многопутевой ввод-вывод	Не поддерживается.
Хранилище vMotion	Поддерживается
Объединенные сетевые карты	Не поддерживается.
IPv6	Не поддерживается.

Требования к устройству (на основе агента)

При настройке устройства репликации с помощью шаблона OVA, предоставленного в центре миграции Azure, устройство запускается с помощью Windows Server 2016 и соответствует требованиям поддержки. Если вы настраиваете устройство репликации на физическом сервере вручную, убедитесь, что оно соответствует требованиям.

Узнайте больше о требованиях к устройству репликации для VMware.
На устройстве должна быть установлена MySQL. Сведения о вариантах установки.
Узнайте больше о URL-адресах, к которым устройству необходимо иметь доступ в общедоступных облаках и облаках для государственных организаций.
Изучите сведения о портах, к которым необходимо получить доступ.

Требования к портам (на основе агента)

Требования для виртуальных машин Azure

Все локальные виртуальные машины, реплицируемые в Azure (перенесенные без или на основе агента), должны соответствовать требованиям к виртуальным машинам Azure, перечисленным в этой таблице.

при этом допустимы только буквы, цифры и дефисы

Перед миграцией необходимо включить RDP на локальной виртуальной машине.

Убедитесь в том, что правила для протоколов TCP и UDP для общедоступного профиля добавлены, а протокол RDP разрешен в разделе Брандмауэр Windows > Разрешенные программы для всех профилей.

Для VPN типа "сеть — сеть"разрешите RDP в разделе Брандмауэр Windows -> Разрешенные приложения и компоненты для Доменных и Частных сетей.

Перед миграцией на локальном компьютере убедитесь, что служба Secure Shell настроена на Запуск, а правила брандмауэра разрешают SSH-подключение.

Правила группы безопасности сети на виртуальной машине Azure, для которой выполнена отработка отказа, и подсети Azure, к которой она подключена, должны разрешать входящие подключения к порту SSH.

14.02.2020

VMWare, Виртуализация

комментариев 10

Технология vMotion позволяет перенести запущенную виртуальную машины VMWare с одного физического хоста ESXi на другой без прерывания ее работы и остановки сервисов. В этой статье мы рассмотрим особенности технологии VMWare vMotion: как работает vMotion, какие виды vMotion бывают, как настроить vMotion в VMWare vSphere и как вручную смигрировать виртуальную машину между хостами ESXi или хранилищами с помощью vMotion. Рассмотрим основные способы оптимизации vMotion и решения проблем.

Аналогичная технология Microsoft для миграции ВМ между хостами Hyper-V называется Hyper-V Live Migration

Как работает VMWare vMotion?

Сервер управления VMWare vCenter;
Наличие общего хранилища (подключенного через Fibre Channel, iSCSI или NAS), на котором хранятся файлы виртуальной машины. Благодаря общему хранилищу в SAN сети несколько физических ESXi серверов могут получать доступ к файлам одной ВМ;
Наличие общей быстрой сети ( не менее 1 Гб Ethernet) между исходным и целевым хостом ESXi. При миграции у ВМ сохраняется ее оригинальный MAC адрес, а vMotion оповещает маршрутизатор о том, что местоположение данного MAC адреса изменилось. В результате активные сетевые соединения не теряются;
Совместимость процессоров на хостах, или включённая опция Enhanced vMotion Compatibility (EVC)

Как происходит vMotion? Сначала на целевом хосте создается теневой клон исходной ВМ с такой-же конфигурацией из vmx файла. Эта ВМ-клон видит все файлы ВМ на общем хранилище. Содержимое оперативной памяти и состояние запущенной ВМ передается по сети между исходным и целевым хостом ESXi. vMotion делает снапшот состояния памяти ВМ, копирует его на целевой сервер по сети. vMotion при этом отслеживает изменения в страницах памяти, а затем до-копирует модифицированные сегменты памяти (это может происходить в несколько этапов, каждый раз копируется все меньший объем данных и за меньшее время).

В какой-то момент состояние исходной ВМ замораживается, выполняется копированию изменённых сегментов памяти и команд процессора, и ВМ запускается на целевом ESXi. Весь процесс для 1/10 Гб Ethernet сети для средних размеров ВМ занимает несколько секунд.

Виды VMware vMotion

VMWare под названием vMotion понимает целый стек различных технологий, позволяющих переместить на лету запущенные ВМ между серверами, дисковыми массивами, городами или между наземной и облачной инфраструктурой.

Классический vMotion – миграция запущенной ВМ между серверами ESXi;
Storage vMotion – онлайн перенос файлов виртуальной машины между хранилищами (дисковыми массивами);
Shared-Nothing vMotion – миграция ВМ между серверами ESXi по сети без использования общего хранилища (требуется L2 сеть);
Long Distance vMotion – перенос ВМ между удаленными сайтами (максимальная задержка Round Trip Time до 150 мс, в том числе в L3-сетях). Появился в версии vSphere 6.0;
Encrypted vSphere vMotion – возможность шифрования ВМ при передачи по сети (доступно в vSphere 6.5);
Cross-Cloud Cold и Hot Migration – онлайн и офлайн миграция между наземной и облачной инфраструктурой;

Особенности VMware Storage vMotion

Как мы уже сказали, технология Storage VMotion позволяет переместить файлы запущенной виртуальной машины (виртуальные диски и файлы конфигурации) на другое VMFS/NFS хранилище (LUN, дисковый массива) без остановки ВМ.

Требования для успешного выполнения Storage VMotion:

Диски VM должны иметь тип persistent или RDM;
Не поддерживается миграция ВМ, во время установки VMware Tools;
При миграции нужно учитывать версию VMFS на хранилище. Например, нельзя перенести диск размером более 2 Тб с VMFS5 на VMFS3;
Наличие лицензии на хосте ESXi;
Хост, на котором запущена ВМ должен иметь доступ к исходному и целевому хранилищу;
При копировании для диска виртуальной машины используется технология Changed Block Tracking, которая позволяет отслеживать измененные блоки данных и до-копировать их.

Enhanced vMotion Compatibility (EVC) в VMWare

Режим Enhanced vMotion Compatibility (EVC) для кластеров VMware HA/DRS используется, если кластер построен на хостах с процессорами разных поколений (но не разных производителей!!). При включении EVC для кластера, гипервизор начинает маскировать инструкции CPU, которые поддерживаются не на всех хостах. При включении EVC все функции процессоров хостов ESXi в кластере начинают соответствовать некому базовому минимальному набору инструкций CPU, который задал администратора vSphere в настройках.

Таким образом благодаря EVC вы можете мигрировать ВМ между хостами с разными наборами инструкций процессора.

Нельзя смешивать в одном кластере vSphere хосты с разными вендорами процессоров, например, Intel и AMD. EVC позволяет добиться совместимости между процессорами только одного вендора.

Вы можете включить VMWare EVC на уровне кластера. Перейдите в раздел Configure -> Configuration -> VMWare EVC и нажмите кнопку Edit.

При включении EVC для кластера вам нужно выбрать режим EVC (для AMD или Intel) и выбрать в выпадающем списке минимальное поколение процессоров вендора, которые имеются в вашем кластере.

VMWare рекомендует всегда включать EVC, независимо от того какие хосты у вас в кластере. Так вам будет проще при расширении кластера. Есть даже отдельный документ, где доказывается, что даже если ваши ВМ не будут использовать весть набор инструкций, на производительность это не скажется.

В VMware vSphere 6.7 появились технологии миграции между облаком и on-prem (Cross-Cloud Cold и Hot Migration). Для реализации ВМ в облако теперь можно включать в настройках ВМ Per-VM EVC (доступно в vSphere 6.7 с Hardware Version 14).

Можно получить базовые уровни EVC выставлены для ВМ в кластере из PowerCLI:

Чтобы получить максимально поддерживаемый режим EVC на:
Get-VMHost | Select-Object Name,ProcessorType,MaxEVCMode

Как включить vMotion в VMWare vSphere?

Рассмотрим, как включить vMotion на примере VMWare vSphere 6.7. Для использования vMotion достаточно лицензии Essentials Plus .

vMotion включается на уровне VMkernel виртуального коммутатора хоста ESXi. Выберите хост, перейдите на вкладку Configure -> Networking -> VMkernel adapters.

Выберите ваш VMkernel интерфейс и откройте его свойства (Edit).

В свойствах vmk порта в секции Enabled Service включите опцию vMotion.

В моем примере HA кластер VMWare уже создан и используется vSphere Distributed Switch (VDS).

vMotion: как мигрировать ВМ между серверами

Чтобы с помощью vMotion перенести запущенную ВМ между двумя ESXi хостами, запустите vSphere Client, щелкните по ВМ и выберите Migrate.

Выберите тип миграции, который вы хотите использовать:

Я выбрал первый вариант.

Мастер миграции предложит выбрать хост, кластер, resourse pool или vApp, в который нужно перенести данную виртуальную машину. Выберите хост. Если vMotion настроен правильно, и не обнаружено конфликтов, в секции Compatibility будет указано: Compatibility checks succeeded.

Мастер миграции ВМ предложит выбрать в какую сети нужно поместить vNIC сетевой ВМ при миграции. Если вы хотите, чтобы ВМ была доступна после миграции, она должна быть помещена в тот же самый сегмент (VLAN), как и на исходном хосте. Если у вас используется стандартный vSphere Switch, нужно создать одинаковые группы портов (Port Group) на всех ESXi хостах. При использовании VDS, группы портов на всех хостах кластера одинаковые.

На последнем этапе нужно выбрать приоритет задачи миграции vMotion. По-умолчанию используется наивысший приоритете (Schedule vMotion with high priority). Я всегда использую именно его.

Осталось нажать Next -> Finish и запустится процедура миграции ВМ на другой хост. За статусом миграции можно следить в панели Recent Tasks (задание Relocate virtual machine). В моем случае процесс миграции ВМ с помощью vMotion по 10 Гб Ethernet занял около 3 секунд.

Убедитесь, что ваша ВМ теперь запущена на другом хосте ESXi.

Можно переместить запущенную ВМ на другой хост с помощью PowerShell командлета Move-VM из PowerCLI. Например, мы хотим перенести все ВМ с хоста esxi-1 на esxi-2:

Get-VMHost esxi-1|Get-Vm| Move-VM –Destination (Get-VMHost esxi-2)

Почему не работает vMotion?

Перечислим основные причины, из-за которых vMotion может завершаться с ошибкой или миграция ВМ выполняться очень медленно:

При ошибках миграции ваша ВМ не выключается, не прекращает работу и по прежнему запущена на исходном хосте.

Как ускорить/оптимизировать vMotion для быстрой миграции ВМ?

Вы можете ускорить миграцию ваших виртуальных машин несколькими способами.

В первую очередь желательно использовать максимально производительную сеть между ESXi хостами. Нужно использовать как минимум 10 Gb, а лучше 25Gb сеть (сетевой адаптер вашего ESXi сервера и физический коммутатор должны поддерживать этот режим).
Использовать разные физические интерфейсы для трафика vMotion;
При миграции vMotion используются потоки. Для одного интерфейса VMkernel, для которого включен vMotion, создается один поток. При этом этот поток может использовать только одно ядро процессора.

Чтобы предоставить для процессов vMotion более одного ядра CPU, нужно создать несколько VMkernel интерфейсов с включенной опцией vMotion и привязать их к одному NIC интерфейсу. Один поток vMotion имеет среднюю пропускную способность около 15 GbE, соответственно, чтобы загрузить сеть 100 GbE вам нужно 6 потоков.

Прошел уже почти год с момента как я опубликовал последнюю запись на тему документа по Best Practices в VMware 7.0. Изначально я не планировал разбирать его дальше раздела, посвященного виртуальным машинам, однако результаты посещаемости сайта говорят о том, что данный цикл интересен читателю и было бы неплохо его закончить.

В течение следующих частей мы посмотрим на рекомендации VMware по управлению виртуальной инфраструктурой. Сегодня на очереди vCenter Server, vMotion, DRS, DPM.

Еще раз напоминаю, что это вольное изложение и часть информации из документа будет опущена, а что-то может быть сформулировано не совсем корректно. Не забудьте ознакомиться с оригинальным документом.

Для тех, кто здесь впервые, рекомендую предварительно ознакомиться с другими частями:

General Resource Management

Гипервизор ESXi предоставляет пользователю несколько механизмов для конфигурации и распределения ресурсов между виртуальными машинами. При этом ручное распределение вычислительных ресурсов может оказать значительное влияние на производительность виртуальных машин. Отсюда следует ряд рекомендаций:

Следует использовать Reservation, Shares и Limits только в случае необходимости;
Если ожидаются частые изменения в инфраструктуре, которые могут влиять на общее количество доступных ресурсов, стоит использовать Shares, а не Reservation для честного распределения ресурсов между виртуальными машинами;
При использовании Reservation, рекомендуется указывать минимально необходимое количество CPU или RAM, а не резервировать все ресурсы для виртуальной машины. После того, как резерв будет удовлетворен, оставшиеся ресурсы будут распределены на основании показателя Shares. Не стоит выставлять большие значения Reservations, это может помещать запуску других виртуальных машин, которым не остается свободных ресурсов в пуле;
При использовании резервов, всегда необходимо оставлять свободные ресурсы для работы гипервизора и прочих служб, например, DRS и миграции;
Чтобы полностью изолировать пул ресурсов, необходимо использовать тип Fixed, а также включить для него Reservation и Limit;
Если сервис состоит из нескольких виртуальных машин (multi-tier service), стоит группировать данные виртуальные машины в рамках одного пула ресурсов для управления потребностями на уровне сервиса целиком.

VMware vCenter

vCenter Server должен получать достаточное количество вычислительных и дисковых ресурсов для функционирования;
Количество потребляемых ресурсов и производительность напрямую зависит от размера инфраструктуры (количество хостов, виртуальных машин и т.п.), а также от количества подключенных клиентов. Превышение допустимых максимумов однозначно скажется на производительности в худшую сторону, и к тому же не поддерживается;
Для получения минимальных задержек при работе vCenter с базой данных, следует минимизировать количество сетевых узлов между ними;
Сетевые задержки между vCenter Server и хостами ESXi могут влиять на производительность операций, в которые вовлечены данные хосты.

VMware vCenter Database Considerations

Работа vCenter напрямую зависит от работоспособности и производительности базы данных, в которой он хранит конфигурационную информацию о всем окружении, статистику, задачи, события и т.д.

VMware vCenter Database Network and Storage Considerations

Если vCenter Appliance использует thin или lazy-zeroed диски, процесс загрузки может быть дольше, чем в случае использования дисков в формате eager-zeroed;
В крупных инсталляциях могут генерироваться большие объемы данных и хорошей практикой будет наблюдение за утилизацией дискового пространства. Как настроить оповещения сказано в соответствующей KB.

VMware vCenter Database Configuration and Maintenance

Следует использовать statistic level в соответствии с текущими требованиями. Данное значение может варьироваться от 1 до 4, но 1 достаточно в большинстве случаев. Более высокие значения могут замедлить работу vCenter, а также увеличится потребление дискового пространства. В случае, если необходим более высокий уровень статистики, например, при отладке, по окончанию данного процесса его следует снизить;
При запуске vCenter формирует пул из 50 потоков для подключения к БД. Размер данного пула меняется динамически в зависимости от работы vCenter и не требует модификации. Однако, при необходимости, размер данного пула может быть изменен до 128 потоков, при этом следует учитывать, что это увеличит потребление ОЗУ и может снизить скорость загрузки VC;
При необходимости подключения к БД VCSA следует воспользоваться материалом из данной KB;
В случае, если наблюдается медленное выполнение запросов, производительность может быть увеличена с помощью выполнения процедуры Vacuum and Analyze на базе данных VCDB.

PostgreSQL (vPostgres) Database Recommendations

В качестве базы данных vCenter использует PostgreSQL (vPosgress). Несмотря на то, что на этапе инсталляции, оптимизация работы базы данных выполняется автоматически, есть некоторые моменты на которые стоит обратить внимание:

vCenter Server Appliance создает несколько виртуальных дисков в момент инсталляции. Для улучшения производительности в больших окружениях следует убедиться, что виртуальные диски с партициями /storage/db, /storage/dblog и /storage/seat располагаются на разных физических дисках;
На виртуальном диске /storage/dblog хранятся транзакционные логи базы данных. vCenter особенно чувствителен к производительности данной партиции, в связи с чем виртуальный диск с данным разделом рекомендуется располагать на высокопроизводительном хранилище с наименьшим временем отклика;
Несмотря на то, что у PostgreSQL имеется свой собственный кэш, данные так же кэшируются на уровне операционной системы. Таким образом, производительность может быть улучшена за счет увеличения кэша ОС. Сделать это можно увеличив объем ОЗУ, выделенный виртуальной машине с vCenter Server, после чего, часть выделенной оперативной памяти будет задействована под кэш;
При достижении размера партиции /storage/dblog примерно до 90%, происходит сброс транзакционных логов. Чем быстрее заполняется этот раздел – тем чаще происходит операция сброса, увеличивая при этом количество дисковых операций. Увеличение размеров данной партиции снижает частоту сброса логов и уменьшает общий ввод-вывод. Это может помочь в больших инфраструктурах, однако, здесь есть и минусы – в случае необходимости восстановления после сбоя, данная процедура может занять большее время;
Для мониторинга дискового пространства можно использовать параметры vpxd.vdb.space.errorPercent и vpxd.vdb.space.warningPercent в расширенных настройках vCenter Server;
Так же для мониторинга можно использовать плагин pgtop для vCenter Server Appliance.

VMware vMotion and Storage vMotion

VMware vMotion Recommendations

Виртуальные машины, создаваемые в vSphere 7.0, имеют версию vHardware 17 (а в более свежих апдейтах – 18). Поскольку виртуальные машины с vHardware версии 17 могут запускаться только на хостах ESXi 7.0 и выше, vMotion для данных VM будет функционировать только в рамках хостов, поддерживающих данную версию;
Начиная с версии 6.5 vSphere поддерживает шифрование при выполнении операций миграции vMotion. Шифрование выполняется как на источнике, так и на приемнике, поэтому в случае миграции виртуальной машины на хост, версия которого ниже, чем 6.5, шифрования траффика при операциях vMotion производиться не будет;
Производительность vMotion со включенным шифрованием будет значительно выше, в случае если хост поддерживает инструкции AES_NI (Intel’s Advanced Encryption Standard New Instruction Set). Без поддержки данных инструкций, производительность vMotion может быть неприемлемой;
Зашифрованные виртуальные машины всегда используют Encrypted vMotion при миграции. Для нешифрованных виртуальных машин, шифрование может быть отключено (Disabled), обязательно (Required) и «по возможности» (Opportunistic);
Производительность vMotion напрямую зависит от скорости сети, поэтому рекомендуется иметь сетевое подключение 10GB/s и выше для сети, которая задействована под миграцию;
Все vmknic для vMotion следует располагать на одном и том же виртуальном свитче, при этом каждая из подгрупп, к которым они подключены, должна использовать разные физические интерфейсы в качестве активного аплинка;
В случае использования сети 40GB/s, рекомендуется сконфигурировать минимум 3 vMotion vmknics. Использование нескольких vmknic позволяет создавать множество потоков vMotion, утилизируя при этом большее количество процессорных ядер и увеличивая общую производительность;
При выполнении операций vMotion, ESXi старается зарезервировать процессорные ресурсы на источнике и приемнике, с целью максимальной утилизации пропускной способности сети. Количество резервируемого CPU зависит от количества vMotion NICs и их скорости, и составляет 10% производительности процессорного ядра за каждый 1Gb/s сетевого интерфейса, или же 100% процессорного ядра за каждый 10GB/s сетевой интерфейс, c минимальным резервом в 30%. Из этого вытекает то, что всегда следует держать незарезервированные процессорные ресурсы, чтобы процессы vMotion могли полностью утилизировать доступный сетевой канал и выполнять миграции быстрее;
Производительность vMotion может быть снижена, если swap уровня хоста размещен на локальных дисках (SSD или HDD).

VMware Storage vMotion Recommendations

Производительность Storage vMotion напрямую зависит от инфраструктуры хранения данных, от скорости подключения ESXi к хранилищам, от скорости работы хранилища-источника и хранилища-приемника. В момент операции миграции происходит чтение данных виртуальной машины из источника и запись в приемник, при этом виртуальная машина продолжает функционировать;
Storage vMotion будет иметь максимальную производительность в моменты низкой активности в сети хранения и если перемещаемые виртуальные машины при этом не создают большого дискового ввода-вывода;
Одна операция миграции позволяет перемещать до 4-х дисков виртуальной машины одновременно, но при этом на один Datastore будет копироваться не более одного диска одновременно. Например, перемещение 4-х дисков VMDK с хранилища A в хранилище B будет выполняться последовательно диск за диском, в то время, как перемещение четырех дисков VMDK с хранилищ A, B, C, D в хранилища E, F, G, H будут идти параллельно;
Как вариант, можно использовать anti-affinity правила для дисков виртуальных машин, тем самым выполнять операции svMotion на разные Datastore параллельно;
При выполнении операции Storage vMotion на более быстрое хранилище, эффект будет заметен только по окончанию процедуры миграции. В то же время эффект от перемещения на более медленное хранилище будет проявляться постепенно с операцией копирования;
Storage vMotion работает значительно лучше на массивах, поддерживающих VAAI.

VMware Cross-Host Storage vMotion Recommendations

Cross-host Storage vMotion позволяет перемещать виртуальные машины одновременно между хостами и хранилищами.

Cross-host Storage vMotion оптимизирован для работы с блоками размером 1MB, который уже достаточно давно является размером блока, выбираемым по умолчанию для VMFS. Однако, при создании хранилищ VM на VMFS3 размер блока мог быть выбран другой и при апгрейде хранилища до VMFS5 он не изменялся. В таком случае, самым верным вариантом будет пересоздать хранилище;
При использовании 40GB/s интерфейсов, применяются те же правила, что и для обычного vMotion, и рекомендуется использовать 3 vMotion vmknics;
Аналогичным образом одновременно копируется 4 диска и применяются те же правила, что и при Storage vMotion;
В большинстве своем, Cross-host Storage vMotion для миграции виртуальных дисков использует сеть vMotion. Однако, если оба хоста, между которыми выполняется миграция, подключены к одному и тому же массиву, поддерживающему VAAI, и хост-источник имеет доступы к Datastore, на который будет мигрирована виртуальная машина, в таком случае будет задействован VAAI функционал массива. Если же VAAI не поддерживается, будет задействована сеть хранения данных для копирования дисков, а не сеть vMotion;

При миграции выключенных виртуальных машин, Cross-host Storage vMotion будет использовать технологию Network File Copy (NFC). Однако, как и в случае со включенными виртуальными машинами, NFC будет задействовать VAAI, если это возможно, или же сеть хранения данных (нужно помнить, что это будет возможно только в случае, если хост-источник имеет доступ к хранилищу, куда перемещается машина).

Примечание: до vSphere 6.0 NFC использовал только management сеть. Начиная с vSphere 6.0, NFC траффик все так же использует сеть управления по умолчанию, однако, теперь для нужд NFC можно выделить отдельный интерфейс (vmknic Storage Replication).

VMware Distributed Resource Scheduler (DRS)

DRS in General

Следует следить за рекомендациями DRS, особенно в случае использования ручных ограничений и правил. В некоторых случаях невыполнение текущих рекомендаций может помешать генерации новых;
В случае использования affinity rules, следует наблюдать за DRS Faults и ошибками в работе DRS, которые могут возникать из-за препятствия существующих правил балансировке. Устранение текущих ошибок может значительно помочь с балансировкой существующей нагрузки;
Начиная с vSphere 7.0 привычная метрика cluster-level balance была заменена на новую – Cluster DRS Score, которая является индикатором состояния кластера и виртуальных машин в данном кластере.

DRS Cluster Configuration Setting

DRS affinity rules позволяют обеспечивать нахождение группы виртуальных машин в рамках одного хоста (VM/VM affinity), в то время как anti-affinity rules, препятствуют этому (VM/VM anti-affinity). Правила DRS так же позволяют явно указать хосты, на которых будут запускаться виртуальные машины (VM/Host affinity), или наоборот не будут (VM/Host anti-affinity).

В большинстве случаев, отказ от использования affinity rules позволит получить наилучший эффект от работы DRS, однако в некоторых случаях, данные правила могут улучшить производительность и обеспечить высокую доступность для сервисов.

Доступны следующие правила:

Keep Virtual Machines Together – позволяет достичь повышения производительности за счет уменьшения задержек при взаимодействии между виртуальными машинами в группе;
Separate Virtual Machines – Использование данного правила для группы VM, предоставляющих один и тот же сервис, позволит повысить доступность сервиса, за счет исключения ситуации, при которой все виртуальные машины, обеспечивающие один и тот же сервис оказались на одном хосте, с которым возникли неполадки;
Virtual Machines to Hosts – Включает в себя правила Must run on, Should run on, Must not run on и Should not run on, которые могут применяться, например, в случае с лицензированием, поскольку ограничивают круг хостов, на которых могут запускаться VM.

DRS Cluster Sizing and Resource Settings

Превышение допустимых максимумов по количеству хостов, виртуальных машин, пулов ресурсов не поддерживается. Несмотря на то, что система с превышенными максимумами может оставаться работоспособной, это может повлиять на производительность vCenter Server и DRS;
С осторожностью следует подходить к установке reservations, shares и limits. Слишком большой резерв может оставить мало незарезервированных ресурсов в кластере, что повлияет на DRS. В то же время слишком низкие лимиты могут препятствовать виртуальной машине в использовании свободных ресурсов, что скажется на ее производительности;
DRS учитывает NetIOC (NIOC) при расчетах рекомендаций;
Как уже упоминалось выше, для операций vMotion следует оставлять свободные ресурсы CPU на хостах.

DRS Performance Tuning

Начиная с vSphere 7.0 реакция механизма DRS зависит от типа нагрузок и настраивается соответственно нагрузкам в кластере. Всего таких уровней 5:

Level 1 – Только необходимая миграция, например, при вводе хоста в режим Maintenance. На текущем уровне DRS не предлагает миграцию с целью улучшения производительности;

Level 2 – Используется для стабильных рабочих нагрузок. DRS рекомендует миграцию виртуальных машин, только в моменты нехватки ресурсов;

Level 3 – Уровень по умолчанию. Подходит для большинства стабильных нагрузок;

Level 4 – Для систем, которым свойственны всплески при потреблении ресурсов и требуется реакция DRS;

Level 5 – Данный уровень следует использовать для динамичных нагрузок, потребление ресурсов которых постоянно изменяется.

В vSphere имеется ряд функций, которые могут упростить управление кластером:

VM Distribution – DRS старается равномерно распределять виртуальные машины в кластере, тем самым косвенно повышая доступность систем;
Начиная с vSphere 7.0 в дополнении к процессорным ресурсам и оперативной памяти, DRS учитывает так же и пропускную способность сети, когда формирует рекомендации по перемещению VM.

Обще вышеуказанных опции доступны в разделе Additional Options настроек DRS.

Для получения высоких показателей DRS Score, возможно, следует ослабить действующие в кластере правила, изменить уровень реагирования DRS, либо снизить потребление ресурсов в кластере.

Есть несколько причин, по которым DRS Score может быть занижен:

Миграции препятствуют affinity и anti-affinity правила;
Миграции препятствуют несовместимые хосты в кластере;
Затраты ресурсов на миграцию могут быть выше, чем ожидаемые преимущества после ее выполнения;
На всех хостах в кластере повышенная загрузка сетевых интерфейсов;
В кластере нет свободных ресурсов, чтобы удовлетворить потребности виртуальных машин.

VMware Distributed Power Management (DPM)

VMware Distributed Power Management позволяет экономить электроэнергию, в моменты, когда хосты в кластере не утилизированы и не находятся под нагрузкой. Данный функционал позволяет консолидировать виртуальные машины на группе хостов, после чего переводит высвободившиеся гипервизоры в Standby режим. DPM поддерживает достаточную вычислительную емкость в кластере, чтобы удовлетворить нужды всех виртуальных машин. В моменты, когда потребность в ресурсах увеличивается, DPM включает дополнительные хосты и переносит на них виртуальные машины, приводя кластер к сбалансированному состоянию.

Начиная с vSphere 7.0, DPM учитывает всю выделенную оперативную память для виртуальных машин и поскольку эти значения достаточно стабильны, в большинстве случаев работа DPM зависит от процессорной утилизации.

DPM использует DRS, а значит большинство практик, применяемых к DRS, применяются и к DPM.

Что такое Storage VMotion?

Одна из замечательных технологий, которая стала доступна из GUI в VMware vSphere, Storage VMotion позволяет перемещать хранилище виртуальной машины (ее виртуальные диски) на другой том VMFS / LUN без остановки работы служб и приложений. На диаграмме ниже показано, какие именно фазы проходят в ESX/ESXi при перемещении виртуальной машины между хранилищами.

Как включить VMotion В vmware Sphere 5.x и мигрировать vm-05

Во-первых, при инициировании миграции, VMware vSphere копирует все файлы виртуальной машины, за исключением виртуальных дисков, на новое целевое виртуальное хранилище.
Во-вторых, в VMware vSphere включается технология Changed Block Tracking для диска виртуальной машины. VMware vSphere отслеживает изменяющиеся блоки и записывает эти данные в битовый массив. Обычно этот битовый массив хранится в памяти VMware ESX / ESXi.
Далее VMware vSphere «пре-копирует» диск виртуальной машины и swap-файл с целевого устройства на хранилище назначения (первая итерация). В это время виртуальная машина может продолжать запись в виртуальный диск. В это время некоторые блоки диска меняются и отслеживаются технологией Changed Block Tracking. Далее изменившиеся данные посылаются vSphere на целевой диск и применяются там (вторая итерация). При этом во время такого копирования данные на исходном диске также изменятся и также эти изменения отследятся Changed Block Tracking. Таким образом, итерации будут продолжаться до тех пор, пока объем изменений не будет настолько мал, что они будут переданы мгновенно на целевой виртуальный диск.
Теперь ESXI вызывает (fast suspend/resume) виртуальной машины. Виртуальная машина «приостанавливается» (suspend) на хосте ESX и процесс, реализующий виртуальную машину, запускает ее уже с целевого хранилища (resume). Именно в этот момент происходит последняя итерация копирования изменившихся данных исходного диска на целевой vmdk. Таким образом, виртуальные диски исходного и целевого виртуального хранилищ оказываются идентичны, после чего происходит resume виртуальной машины.
После того, как виртуальная машина запустилась с целевого хранилища, ее виртуальные диски и другие файлы на исходном хранилище уничтожаются.

Каковы варианты использования Storage vMotion?

Миграция со старого хранилища на новые системы хранения или миграция на хранилище другого поставщика без простоев на виртуальные машины.
Выполнение запланированных действий, таких как обновление хранилища на исходном Lun. виртуальной машины из толстого в тонкий и из тонкого в толстый.
Перенос критически важных виртуальных машин в высокопроизводительные массивы хранения для повышения производительности виртуальной машины.
Миграция рабочей нагрузки между различными физическими LUN
Балансировка нагрузки IOPS (с кластерами sDRS Datastore)
svMotion не зависит от хранилища, что означает, что он может работать со всем, что может предоставить хранилище данных VMware. (iSCSI, FCoE, vSAN, NFS, NAS и т. д.)

Требования и ограничения Storage vMotion

Виртуальная машина и ее хост должны соответствовать требованиям к ресурсам и конфигурации для дисков виртуальной машины, которые необходимо перенести с помощью Storage vMotion. Storage vMotion подчиняется следующим требованиям и ограничениям:

Диски виртуальных машин должны находиться в постоянном режиме (persistent mode) или быть необработанными сопоставлениями устройств (RDM). Для RDM в режиме виртуальной совместимости вы можете перенести файл сопоставления или преобразовать его в диски с толстым (thick-provisioned) или тонким (thin-provisioned) предоставлением во время миграции, если местом назначения не является хранилище данных NFS. Если вы преобразовываете файл сопоставления, создается новый виртуальный диск, и содержимое сопоставленного LUN копируется на этот диск. Для RDM в режиме физической совместимости (physical compatibility) вы можете перенести только файл сопоставления.
Миграция виртуальных машин во время установки VMware Tools не поддерживается.
Поскольку хранилища данных VMFS3 не поддерживают виртуальные диски большой емкости, вы не можете перемещать виртуальные диски размером более 2 ТБ из хранилища данных VMFS5 в хранилище данных VMFS3.
Хост, на котором работает виртуальная машина, должен иметь лицензию, включающую Storage vMotion.
Хостам ESXi 4.0 и более поздних версий не требуется конфигурация vMotion для выполнения миграции с помощью Storage vMotion.
Хост, на котором работает виртуальная машина, должен иметь доступ как к исходному, так и к целевому хранилищу данных.
Виртуальная машина должна быть выключена, если вы хотите одновременно перенести виртуальную машину на другой хост и другое хранилище
svMotion может вызвать проблемы в приложениях с интенсивным вводом-выводом, таких как базы данных. Имейте это в виду
Максимальное количество одновременных миграций svMotion - 16, тем не менее, это может привести к снижению производительности массива хранения.
В то время как vMotion требует выделенного стека vmkernel TCP / IP для трафика. Storage vMotion переносит данные двумя способами: через коммутаторы FC, если вы используете Fibre Channel, или с помощью интерфейсов управления или обеспечения.
Виртуальные машины со снимками, не могут быть перемещены с помощью Storage VMotion
Хост, на котором виртуальная машина запущена, должен иметь доступ к исходному и целевому хранилищам данных

Практическая часть в vCenter 5.5

теперь немного практики. При общем storage есть два вида миграции

- Change host
- Change datastore

При первом у вас уже должен быть общий storage. Перед тем как я познакомился с vMotion конфигурация была следующей. Два хоста не в кластере. Независимые storage. Необходимо было перезагрузить один из хостов а машинки на нем не трогать. В итоге создал общий storage для них. Затем смигрировал с первого хоста на другой storage машинку, для этого кликнул по ней выбрал migration и выбрал

Как включить VMotion В vmware Sphere 5.x и мигрировать vm-06

Выбрал общий storage и дождался когда операция закончится, затем выбрал в миграции первый пункт Change host и выбираем нужный host.

Как работает "Shared-Nothing" vMotion (Enhanced vMotion) в VMware vSphere 5.1.

Как знают многие пользователи, среди новых возможностей VMware vSphere 5.1 есть так называемая Enhanced vMotion или "Shared-Nothing" vMotion - функция, позволяющая переместить работающую виртуальную машину на локальном хранилище ESXi на другой хост и хранилище с помощью комбинации техник vMoton и Storage vMotion в одной операции. Это означает, что для такого типа горячей миграции не требуется общее хранилище (Shared Storage), а значит и затрат на его приобретение. Напомним также, что функция Enhanced vMotion включена во все коммерческие издания VMware vSphere, кроме vSphere Essentials.

Давайте посмотрим поближе, как это все работает:

Как включить VMotion В vmware Sphere 5.x и мигрировать vm-07

Сначала приведем требования и особенности работы vMotion при отсутствии общего хранилища:

Хосты ESXi должны находиться под управлением одного сервера vCenter.
Хосты должны находиться в одном контейнере Datacenter.
Хосты должны быть в одной Layer 2 подсети (и, если используется распределенный коммутатор, на одном VDS).Enhanced vMotion - это исключительно ручной процесс, то есть функции DRS и Storage DRS не будут использовать миграцию машин без общего хранилища. Это же касается и режима обслуживания хоста (Maintenance Mode).
Для одного хоста ESXi может быть проведено не более 2-х Enhanced vMotion единовременно. Таким образом, на хост ESXi может одновременно приходиться максимум 2 штуки Enhanced vMotion и 6 обычных vMotion (всего 8 миграций на хост) + 2 операции Storage vMotion, либо 2 Enhanced vMotion (так как это также задействует Storage vMotion).
Enhanced vMotion может проводить горячую миграцию одновременно по нескольким сетевым адаптерам хоста ESXi, если они имеются и настроены корректно.

Миграция Enhanced vMotion может быть проведена только через тонкий клиент vSphere Web Client (в обычном клиенте эта функция недоступна - см. комментарии):

Как включить VMotion В vmware Sphere 5.x и мигрировать vm-08

Миграция Enhanced vMotion идет по обычной сети vMotion (а не по Storage Network), по ней передаются и диск ВМ, и ее память с регистрами процессора для обеспечения непрерывной работоспособности виртуальной машины во время миграции:

Как включить VMotion В vmware Sphere 5.x и мигрировать vm-09

Теперь как это все работает последовательно. Сначала механизм Enhanced vMotion вызывает подсистему Storage vMotion, которая производит копирование данных по сети vMotion. Здесь важны 2 ключевых компонента - bulk copy и mirror mode driver.

Как включить VMotion В vmware Sphere 5.x и мигрировать vm-10

Сначала механизм bulk copy начинает копирование блоков данных с максимально возможной скоростью. Во время этого часть блоков на исходном хранилище хоста может измениться - тут и вступает в дело mirror mode driver, который начинает поддерживать данные блоки на исходном и целевом хранилище в синхронном состоянии.

Mirror mode driver во время своей работы игнорирует те блоки исходного хранилища, которые меняются, но еще не были скопированы на целевое хранилище. Чтобы поддерживать максимальную скорость копирования, Mirror mode driver использует специальный буфер, чтобы не использовать отложенную запись блоков.

Как включить VMotion В vmware Sphere 5.x и мигрировать vm-11

Когда диски на исходном и целевом хранилище и их изменяющиеся блоки приходят в синхронное состояние, начинается передача данных оперативной памяти и регистров процессора (операция vMotion). Это делается после Storage vMotion, так как страницы памяти меняются с более высокой интенсивностью. После проведения vMotion идет операция мгновенного переключения на целевой хост и хранилище (Switch over). Это делается традиционным способом - когда различия в памяти и регистрах процессора весьма малы, виртуальная машина на мгновение подмораживается, различия до передаются на целевой хост (плюс переброс сетевых соединений), машина размораживается на целевом хосте и продолжает исполнять операции и использовать хранилище с виртуальным диском уже целевого хоста.

Ну а если вы перемещаете виртуальную машину не между локальными дисками хост-серверов, а между общими хранилищами, к которым имеют доступ оба хоста, то миграция дисков ВМ идет уже по Storage Network, как и в случае с обычным Storage vMotion, чтобы ускорить процесс и не создавать нагрузку на процессоры хостов и сеть vMotion. В этом случае (если возможно) будет использоваться и механизм VAAI для передачи нагрузки по копированию блоков на сторону дискового массива.

У меня настроен стенд, как я его настраивал, описано тут. Теперь слайды демонстрации.

У меня два сервера ESXi, не в кластере, но под управлением vCenter сервер. Работает только виртуальная машина и, судя по ошибке, памяти на 106-ом хосте не хватает. Здесь, как раз и пригодится vMotion. Мне нужно не останавливая работу перенисти ВМ на другой сервер, выключить 106-ой хост, добавить в него оперативной памяти и вернуть ВМ обратно.

Убеждаюсь, что файлы виртуальной машины расположены на обжем LUN, который в свою очередь находится на FreeNAS. Это главное условие для миграции, о котором многие забывают.

И вот первая проблема, на хосте с которого я хочу осуществить миграцию, она не включена и поэтому работать не будет. Теперь либо ВМ нужно выключить и запустить миграцию, либо включить vMotion на обоих хостах ESXi. Выбираем, конечно, второй вариант.