Это новая конфигурация ESXi 4.0, на которой виртуальные машины работают вне сети Cybernetics miSAN D iSCSI SAN.
Выполнение теста на чтение с высоким объемом данных на виртуальной машине заняло 8 минут против 1,5 минут на той же виртуальной машине, расположенной на более медленном хосте VMWare Server 1.0 с виртуальными машинами, расположенными на локальном диске. Я слежу за своей скоростью чтения из SAN, и максимальная скорость чтения составляет чуть более 3 МБ / с, а использование диска на виртуальной машине соответствует чуть более 3 МБ / с ... ужасно медленно.
Сервер и SAN подключены к одному коммутатору 1 ГБ. Я следил за этим руководством
virtualgeek.typepad.com/virtual_geek/2009/09/a-multivendor-post-on-using-iscsi-w ith-vmware-vsphere.html
чтобы правильно настроить многопутевый режим, но я все еще не получаю хорошую производительность с моими виртуальными машинами. Я знаю, что SAN и сеть должны иметь возможность обрабатывать более 100 МБ / с, но я просто не понимаю этого. У меня есть две сетевые карты Гбайт на SAN, соединенные с двумя сетевыми картами Гбайт на хосте ESXi. Один сетевой адаптер на каждое ядро VMkernel. Что еще я могу проверить или сделать, чтобы улучшить свою скорость? Заранее благодарим за любые советы.
Эта настройка должна обеспечивать разумную производительность, и, насколько я могу судить, этот массив может выдерживать около 60-70 мегабайт в секунду даже для небольших блоков произвольного ввода-вывода. У меня нет опыта работы с ними, но в спецификации указано, что он должен легко справиться с вашими требованиями, и несколько обзоров, которые ищут, подтверждают это.
В любом случае, на вашем месте я бы сначала отступил. Избавьтесь от использования нескольких путей (на начальном этапе) и убедитесь, что вы можете получить единый путь (на стороне VMware) для поддержания достойной производительности. Предполагая, что у вас есть 8 приводов, полностью заполненных дисками SAS 10k, один горячий резерв и пакет RAID 5 из 7 дисков, он должен легко обеспечивать последовательное чтение или запись> 100 МБ / с через один интерфейс на хорошем выделенном Гбит LAN даже с учетом всех накладных расходов ip \ tcp и iSCSI. Выполните простые массовые тесты больших копий файлов (что-то значительно большее, чем кеш записи в массиве) в или из SAN, чтобы убедиться, что вы это видите. Если вы читаете и записываете на том SAN, производительность будет не более половины от этого показателя. Если нет, то вы захотите взглянуть на всех обычных подозреваемых:
При тестировании убедитесь, что ни хост ESX, ни сеть SAN ничем не заняты.
После того, как вы успешно получаете> 100 МБ / с для последовательного трафика по одному восходящему каналу, вы можете подумать о том, имеет ли значение multipathing. С iSCSI на ESX4 это возможно, но это маловероятно, если массив хранения правильно не поддерживает его в сочетании с ESX 4. Я бы обратился к поставщику массива за советом по этому поводу.
Это оборудование SAN сертифицировано для Vmware, так что обратитесь в службу поддержки, чтобы разобраться в этом. Распространенными причинами плохой производительности является перегрузка интерфейса оборудования SAN, потому что при наличии нескольких подключений к одной и той же SAN не все могут обслуживаться на максимальной скорости.
Кроме того, ваш локальный диск всегда будет быстрее, чем ваш SAN в вашей настройке, потому что даже диск SATA будет иметь максимальную пропускную способность 3 Гбит / с, поэтому ваша SAN никогда не будет соответствовать скорости ваших локальных дисков. Вероятно, вы также используете Ethernet вместо волокна, что также не способствует производительности.
Вы используете SAN не только из-за скорости, но и для того, чтобы иметь централизованное управляемое место, где вы можете разместить все важные данные и убедиться, что применяется подходящий уровень RAID. Есть также определенные функции, такие как репликация, что является одним из преимуществ наличия SAN.
Проблема может быть вызвана несколькими путями. Можете ли вы (и пробовали ли вы) отключить многопутевость и иметь только одно соединение 1 Гб с вашей SAN? VMware может перебивать путь при загрузке из-за плохого соединения или задержки доставки пакетов ...
Кстати, ваша максимальная пропускная способность со ссылкой на 1 ГБ будет ~ 30 МБ / с, если ваш хост SAN и ESXi были единственными двумя устройствами на этой ссылке ...
Какую политику балансировки нагрузки вы используете для своих сетевых адаптеров iSCSI - почти в каждой ситуации одно устройство взаимодействует с другим устройством - каждое из которых использует любую из форм связывания / etherchannel / teaming / любого другого, когда-либо будет использовать только одну из множества доступных ссылок talk - то есть никогда не более 1 Гбит / с, что, кстати, почти никогда не бывает полностью доступно, особенно с iSCSI из-за всей вовлеченной инкапсуляции.
Имейте в виду, что собственный драйвер Multi-Pathing IO (MPIO) в VMware является активным / пассивным, поэтому он будет использовать только один путь для каждого LUN. Таким образом, если весь ваш трафик идет на один LUN, вы будете использовать только один путь, чтобы получить этот трафик туда. Единственный поддерживаемый сторонний драйвер MPIO (о котором я знаю) - это EMC PowerPath, который является драйвером Active / Active MPIO, но для него требуется версия vSphere Enterprise Plus.
Некоторые вещи, на которые стоит посмотреть.
Включили ли вы Jumbo Frames в SAN, коммутаторе и хосте? Показывает ли SAN какие-либо проблемы с производительностью с помощью инструментов мониторинга? Сколько дисков стоит за рассматриваемым LUN? Сколько еще материала попадает на те же диски?