Назад | Перейти на главную страницу

SAN с ужасающей целевой производительностью iSCSI

У нас есть установка SAN для бедняков на сервере Ubuntu 1U с iSCSI-Target с двумя дисками по 300 ГБ в RAID-0. Затем мы используем его для блочного хранилища виртуальных машин. Гипервизор подключается к SAN через гигабит через выделенную VLAN и интерфейсы.

У нас есть только одна настройка виртуальной машины и мы делаем несколько тестов. Если мы бежим hdparm -t /dev/sda1 от виртуальной машины мы получаем «нормальную» производительность 75 МБ / с от виртуальной машины к сети SAN. Затем мы в основном компилируем пакет с ./configure и make. Все начинается нормально, но затем внезапно средняя нагрузка на SAN вырастает до 7+, и все замедляется до ползания. Когда мы подключаемся по SSH к SAN и запускаемся сверху, убедитесь, что нагрузка составляет 7+, но использование ЦП практически ничего, кроме того, у сервера есть 1,5 ГБ доступной памяти. Когда мы завершаем компиляцию на виртуальной машине, НАГРУЗКА в SAN медленно возвращается к цифрам меньше единицы.

Что в мире вызывает это? Как мы можем диагностировать это дальше?

Вот два скриншота из SAN при высокой нагрузке.

1> Output of iotop on the SAN:


2> Output of top on the SAN:

Это очень похоже на типичный случай недостаточной скорости хранения. Гипервизоры (особенно ESXi / vSphere) будут выполнять синхронную запись значительно чаще, чем вы могли бы увидеть при установке ОС с нуля, такой как Linux, - где подавляющее большинство запросов записи будут асинхронными (если вы не испортили настройки файловой системы) ). Для синхронной записи снова потребуется хранилище, чтобы подтвердить, что операция завершена и была зафиксирована в постоянном хранилище. Если у вас всего 2 диска, это будет тяжелая игра - вы видите результаты.

Ваши варианты:

  1. использовать RAID-контроллер с собственным кешем с резервным питанием от батареи или флэш-памяти, чтобы он мог сообщать о завершении, как только данные были записаны в кеш
  2. лгите своему гипервизору, что данные были переданы в постоянное хранилище, хотя на самом деле это не так, включив IOMode=wb для вашего определения LUN в ietd.conf

Обратите внимание, что последнее не рекомендуется, так как это может привести к повреждению хранилища данных вашего гипервизора, файловых систем гостей и транзакционных баз данных при отключении электроэнергии или сбое вашего сервера хранения (и IET действительно может иногда давать сбой), но это действительно так. вполне подходит в качестве быстрой проверки, является ли синхронизация записи причиной вашей нагрузки и ужасных показателей производительности при компиляции.

узкое место. может быть на стороне инициатора, сети с обеих сторон, целевого программного обеспечения или целевой дисковой подсистемы. по описанию, я бы начал с сети, убедившись, что разгрузка отключена (ethtool -K {tso, gso, lro} off)

hdparm - очень плохой инструмент для тестирования производительности ввода-вывода. Вам следует подумать об использовании bonnie++, или один из дополнительных инструментов для конкретных приложений.

При выполнении вашего ./configure; make процесса, вы в конечном итоге выполните ряд операций чтения и записи с переменным размером, которые, скорее всего, будут распределены по всему диску, а не в смежной области.

Как только вы лучше поймете производительность вашей системы ввода-вывода, вы сможете определить основную причину.

Нормальная ли производительность на цели iSCSI при записи напрямую на диск, но не нормальная, когда вы говорите по iSCSI? Если это так, возможно, это связано с сетью (разгрузка, mtu, несоответствие дуплекса / скорости и т. Д.). Если нет, возможно, связано с контроллером / диском (кеш записи и т. Д.)