У меня есть вопрос по моей тестовой лаборатории. Это больше для понимания концепции, чем для применения ее в производстве:
У меня есть ESXi с несколькими настроенными виртуальными машинами Linux/Windows, и я хотел бы использовать конвертер VMWare для создания резервных копий.
Чтобы ускорить процесс, я решил создать виртуальную машину Windows на том же хосте ESXi, где установлены Windows 7 и VMWare Converter.
У хоста гигабитная карта, но в данный момент она подключена к порту FD 100Mb. Windows 7 видит подключенную карту 1gb.
Когда я делаю резервную копию с помощью конвертера VMWare, я указываю IP-адрес хоста в качестве источника и назначения, поэтому я подумал, что копирование может быть быстрее, чем при использовании моего ноутбука по сети.
Ну, если коротко: я получаю ужасную производительность (4 Мбит/сек). Я немного запутался в этом, потому что, несмотря на то, что хост использует 100 Мбит/с, связь между виртуальными машинами и хостами не должна (поправьте меня, если я ошибаюсь) иметь какие-либо ограничения.
Я настроил Windows 7, чтобы оптимизировать производительность сети, но добился лишь небольшого улучшения. Мне все еще нужно 4 часа, чтобы создать резервную копию 50-гигабайтной (тонкой) виртуальной машины.
Дополнительно хотел спросить: Поможет ли в этом jumbo frame? Я знаю, что jumbo frame должны поддерживаться сквозным образом, а сетевой коммутатор, к которому в данный момент подключен хост, этого не поддерживает, но мне было интересно:
1) Поддерживает ли хост ESXi вообще кадры большого размера?
2) Можно ли это как-то включить?
3) Если я это сделаю, то, полагаю, массовая передача данных между виртуальными машинами и хостом улучшится, но повлияет ли это на связь, проходящую через реальный коммутатор, поскольку он не делает больших объемов данных?
Спасибо за прочтение
решение1
Jumbo-кадры могут иметь некоторое значение, но ваши проблемы с пропускной способностью указывают на гораздо более серьезную проблему. Вы можете включить Jumbo-кадры в ESXi, но для этого требуется использование инструментов командной строки vCLI — вы можете найти конкретные инструкции в этомДокумент конфигурации VMware ESXi.
Вот несколько возможных причин.
У вас могут быть данные, входящие и исходящие из хоста ESXi - в этом случае Converter будет копировать данные из виртуальной машины в хосте ESXi обратно в интерфейс управления через вашу физическую сеть. Учитывая, что это 100-мегабитный восходящий канал, я все равно ожидаю, что вы получите пару мегабайт/сек, а не 4 мегабит/сек, о которых вы сообщаете.
Возможно, сетевые карты вашего хоста ESX некорректно согласовывают настройки 100 Мбит/с/полный дуплекс с коммутатором — убедитесь, что настройки коммутатора и pNIC на вашем хосте ESXi установлены правильно.
Converter не очень эффективен с точки зрения пропускной способности, но если вы используете блочное копирование дисков (а не на уровне файлов), то все в порядке (скорость передачи данных будет >50% от максимальной пропускной способности канала связи — скажем, 4 Мбит/с в сети 100 Мбит/с, 40 Мбит/с на GigE). Если ваша копия использует копирование на уровне файлов, то все будет намного медленнее.
Вся эта деятельность создает значительную дополнительную нагрузку на дисковую подсистему, на которой хранятся ваши виртуальные машины. Если вы запускаете все это на довольно медленном хранилище (скажем, несколько дисков SATA в RAID 5), то, возможно, диск перегружен, но для здоровой конфигурации хранилища такого рода вещи не должны быть стрессом.
Я думаю, что проблема в вашей виртуальной сети. Если предположить, что это так, то вам следует учесть следующее:
Если ваш порт управления ESXi находится на том же виртуальном коммутаторе, что и группа портов производственной сети вашей виртуальной машины, то трафик должен возвращаться обратно внутри виртуального коммутатора. Если этого не происходит, то я бы начал проверять, настроены ли VLAN на портах\группах портов, или проверил бы, не заставляет ли ваша IP-адресация трафик думать, что он должен выйти из коммутатора, прежде чем вернуться обратно (например, если у вас есть порт управления в другой подсети по отношению к сети виртуальной машины, и вы полагаетесь на внешний маршрутизатор, чтобы разрешить им общаться). Если вы подозреваете, что ваша сеть не делает вышеизложенное правильно, то вы можете поместить исходную и целевую виртуальные машины в ту же подсеть, что и порт управления, и подключить их к группе портов виртуальной машины на том же vSwitch, что и порт управления, тогда вы должны заставить трафик между различными системами (источником, конвертером виртуальной машины и хостом ESX) оставаться в пределах vSwitch. Перемещайте группы портов виртуальных машин, а не возитесь с портом управления. Если вы допустите ошибку, вам придется вернуться к физической консоли ESXi, чтобы исправить ситуацию, и лучше не рисковать.
Также перед началом работы отключите как можно больше ресурсов на случай, если что-то вроде процесса резервного копирования поглотит всю пропускную способность порта управления и т. д.
решение2
Отключение шифрования SSL — способ обойти эту проблему. Вот как это делается:
Open the converter-worker.xml configuration file. It is located in
"%ALLUSERSPROFILE%\VMware\VMware vCenter Converter Standalone"
folder for Windows Vista or newer or in
"%ALLUSERSPROFILE%\Application Data\VMware\VMware vCenter Converter Standalone"
for older Windows versions.
Set the key Config/nfc/useSsl to false and save the configuration file.
Restart "VMware vCenter Converter Standalone Worker" service.
Т.е. это должно выглядеть так:
...
<nfc>
<readTimeoutMs>120000</readTimeoutMs>
<useSsl>false</useSsl>
...
«Перезапустите службу «VMware vCenter Converter Standalone Worker».