У меня вопрос о моей тестовой лаборатории. Это больше для понимания концепции, чем для ее применения в производстве:
У меня есть ESXi с несколькими настроенными виртуальными машинами linux / windows, и я хотел бы использовать конвертер VMWare для создания резервных копий.
Чтобы ускорить процесс, я решил создать виртуальную машину Windows на том же узле ESXi, на котором я установил Windows 7 и VMWare Converter.
Хост имеет гигабитную карту, но в настоящее время он подключен к порту FD 100 МБ. Windows 7 видит подключенную карту 1gb.
Когда я делаю резервную копию с помощью конвертера VMWare, я указываю IP-адрес хоста в качестве источника и назначения, поэтому я подумал, что копирование может быть быстрее, чем использовать мой ноутбук по сети.
Короче говоря: получаю ужасную производительность (4 Мб / сек). Я запутался в этом, потому что, несмотря на то, что хост использует 100-мегабайтную связь между виртуальными машинами и хостами, вместо этого не должно (исправьте меня, если я ошибаюсь) иметь какие-либо ограничения.
Я настроил Windows 7 для оптимизации производительности сети, но получил лишь небольшое улучшение. Мне все еще нужно 4 часа для резервного копирования (тонкой) виртуальной машины 50 ГБ.
Вдобавок я хотел спросить: поможет ли в этом jumbo frame? Я знаю, что jumbo-кадры должны поддерживаться из конца в конец, а сетевой коммутатор, к которому в настоящее время подключен хост, не поддерживает это, но мне было интересно:
1) Поддерживает ли хост ESXi jumbo-кадры вообще?
2) Можно как-нибудь включить?
3) Если я сделаю это, я думаю, что массовая передача между виртуальными машинами и хостом улучшится, но повлияет ли это на связь, проходящую через настоящий коммутатор, поскольку это не делает jumbo?
Спасибо за прочтение
Jumbo-кадры могут иметь значение, но проблемы с пропускной способностью указывают на гораздо более серьезную проблему. Вы можете включить Jumbo-кадры в ESXi, но для этого требуется использование инструментов командной строки vCLI - вы можете найти конкретные инструкции в этом Документ конфигурации VMware ESXi.
Есть несколько возможных причин.
Ваши данные могут входить и выходить из хоста ESXi - в этом случае Converter будет копировать данные из виртуальной машины на хосте ESXi обратно в интерфейс управления через вашу физическую сеть. Учитывая, что это 100-мегабитный восходящий канал, я все равно ожидаю, что вы получите пару мегабит / сек, а не 4 мегабит / сек, о которых вы сообщаете.
Сетевые адаптеры вашего хоста ESX могут на самом деле неправильно согласовывать настройки 100 Мбит / с / полнодуплексный режим с коммутатором - убедитесь, что параметры коммутатора и pNIC на вашем хосте ESXi установлены правильно.
Конвертер не очень эффективен с точки зрения пропускной способности, но если вы используете блочное копирование диска (а не на уровне файлов), все в порядке (скорость передачи будет> 50% максимальной пропускной способности канала - скажем, 4 мегабайта в секунду на скорости 100 Мбит / с. сеть, 40Meg / sec на GigE). Если ваша копия использует копирование на уровне файлов, то все будет намного медленнее.
Все эти действия создают значительную дополнительную нагрузку на дисковую подсистему, на которой хранятся ваши виртуальные машины. Если вы запускаете все это на довольно медленном хранилище (скажем, несколько дисков SATA в RAID 5), возможно, что диск перегружается, но для правильной настройки хранилища такие вещи не должны быть стрессом.
Я думаю, что проблема в вашей виртуальной сети - предполагая, что это так, вы должны учитывать следующее:
Если ваш порт управления ESXi находится на том же виртуальном коммутаторе, что и группа производственных сетевых портов вашей виртуальной машины, тогда трафик должен возвращаться внутри виртуального коммутатора. Если этого не происходит, я бы начал проверять, настроены ли VLAN для портов \ групп портов, или проверять, заставляет ли ваша IP-адресация думать, что он должен выйти из коммутатора, прежде чем вернуться (например, если у вас есть управление порт в подсети, отличной от сети виртуальных машин, и полагаются на внешний маршрутизатор, позволяющий им общаться). Если вы подозреваете, что ваша сеть выполняет указанные выше действия неправильно, вы можете поместить исходную и целевую виртуальные машины в ту же подсеть, что и порт управления, и подключить их к группе портов виртуальных машин на том же vSwitch, что и порт управления, тогда вы должны получить трафик между различными системами (источником, виртуальной машиной преобразователя и хостом ESX) должен оставаться в пределах vSwitch. Переместите группы портов виртуальной машины, а не возитесь с портом управления - если вы допустили ошибку, вам придется вернуться к физической консоли ESXi, чтобы исправить что-то, и лучше всего не рисковать с этим.
Также выключите как можно больше перед запуском на случай, если что-то вроде процесса резервного копирования забирает всю пропускную способность сети порта управления и т. Д.
Отключение 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 ".