Это новая конфигурация ESXi 4.0, на которой работают виртуальные машины на базе SAN-сети Cybernetics miSAN D iSCSI.
Выполнение теста на чтение больших объемов данных на виртуальной машине заняло 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-with-vmware-vsphere.html
для правильной настройки multipathing, но я все еще не получаю хорошей производительности с моими виртуальными машинами. Я знаю, что SAN и сеть должны быть в состоянии обрабатывать более 100 МБ/с, но я просто не получаю этого. У меня есть два GB NIC на SAN multipathing на два GB NIC на хосте ESXi. Один NIC на VMkernel. Есть ли что-то еще, что я могу проверить или сделать, чтобы улучшить свою скорость? Заранее спасибо за любые советы.
решение1
Это оборудование SAN сертифицировано для Vmware, поэтому обратитесь в службу поддержки, чтобы разобраться с этим. Распространенными причинами плохой производительности являются перегрузка интерфейса оборудования SAN, поскольку если у вас есть несколько подключений к одному и тому же SAN, не все они могут обслуживаться на максимальной скорости.
Также ваш локальный диск всегда будет быстрее, чем ваш SAN в вашей настройке, потому что даже диск SATA будет иметь максимальную пропускную способность 3 Гбит/с, поэтому ваш SAN никогда не сравняется со скоростью ваших локальных дисков. Вы, вероятно, также используете ethernet вместо оптоволокна, что также не способствует производительности.
Вы используете SAN не только из-за скорости, но и для того, чтобы иметь центральное управляемое место, где вы можете разместить все важные данные и убедиться, что применяется подходящий уровень RAID. Также есть определенные функции, такие как репликация, что является одним из преимуществ наличия SAN.
решение2
Эта настройка должна обеспечивать разумную производительность, и, насколько я могу судить, этот массив может поддерживать около 60-70 мегабайт в секунду даже для небольших блоков случайного ввода-вывода. У меня нет опыта работы с ними, но спецификация указывает, что он должен легко справиться с вашими требованиями, и несколько обзоров, которые выдает поиск, подтверждают это.
В любом случае, если бы я был вами, я бы сначала немного отступил. Избавьтесь от многопутевого режима (вначале) и убедитесь, что вы можете получить один путь (на стороне VMware) для поддержания приличной производительности. Предполагая, что у вас есть 8-дисковый блок, полностью заполненный дисками SAS 10k, один горячий резерв и пакет RAID 5 из 7 дисков, он должен быть в состоянии легко обеспечить >100 МБ/с последовательного чтения или записи через один интерфейс в хорошей выделенной локальной сети Gbit, даже с учетом всех накладных расходов ip\tcp и iSCSI. Проведите простые массовые тесты больших копий файлов (что-то значительно большее, чем кэш записи на массиве) в или из SAN, чтобы убедиться, что вы видите это. Если вы читаете и пишете в том SAN, то производительность будет не более чем в два раза ниже, кстати. Если нет, то вам нужно будет посмотреть на всех обычных подозреваемых:
- Для начала убедитесь, что кэш SAN настроен правильно.
- Убедитесь, что все диски исправны, т.е. вы не боретесь с перестроением RAID.
- Убедитесь, что коммутатор исправен и не занят другими задачами. В идеале вам следует изолировать трафик SAN на его собственном коммутаторе. Если это невозможно, поместите его в отдельную VLAN.
- Определенно не стоит подключать его к дешевому коммутатору, который слишком занят другими функциями.
- Проверьте настройки дуплекса и скорости на всех портах (ESX, Switch и SAN)
- Не вмешивайтесь в работу Jumbo Frames и ESX, пока не убедитесь, что все остальное работает.
- Обязательно включите аппаратное управление потоком на коммутаторе
При тестировании убедитесь, что ни хост ESX, ни SAN не заняты чем-либо другим.
Как только вы успешно получите >100Meg/sec для последовательного трафика на одном восходящем канале, вы можете рассмотреть возможность проверки того, имеет ли значение многопутевой режим. С iSCSI на ESX4 это возможно, но маловероятно, если только массив хранения не поддерживает его правильно в сочетании с ESX 4. Я бы обратился к поставщику массива за рекомендациями по этому вопросу.
решение3
Multipathing может быть причиной вашей проблемы. Можете ли вы отключить multipathing и иметь только одно 1Gb соединение с вашей SAN? VMware может перегружать путь при нагрузке из-за плохого соединения или задержки в доставке пакетов...
Кстати, ваша максимальная пропускная способность при соединении на 1 Гбит/с составит ~30 Мбайт/с, если ваши SAN и хост ESXi будут единственными двумя устройствами на этом соединении...
решение4
Имейте в виду, что собственный драйвер Multi-Pathing IO (MPIO) в VMware является только Active/Passive, поэтому он будет использовать только один путь на LUN. Поэтому, если весь ваш трафик идет на один LUN, вы будете использовать только один путь, чтобы доставить этот трафик туда. Единственный поддерживаемый сторонний драйвер MPIO (насколько мне известно) — это PowerPath от EMC, который является драйвером MPIO Active/Active, но для него требуется версия Enterprise Plus vSphere.
Есть на что обратить внимание.
Включили ли вы Jumbo Frames на SAN, коммутаторе и хосте? Показывает ли SAN какие-либо проблемы с производительностью с помощью своих инструментов мониторинга? Сколько дисков находится за рассматриваемым LUN? Сколько других вещей попадает на те же диски?