ADG Оставить заявку
Блог Инфраструктура 4 мин чтения

10GbE в серверной: iSCSI наконец перестал задыхаться

Поставили первые 10 Gigabit Ethernet адаптеры на хосты виртуализации - iSCSI-трафик к SAN перестал быть узким местом. Рекомендуем выделенный VLAN для storage.

Контекст момента

10 Gigabit Ethernet адаптеры становятся доступными по цене для среднего бизнеса в 2008 году

Несколько месяцев мы смотрели на 10 Gigabit Ethernet как на технологию для очень больших дядей с очень большими бюджетами. Карточки стоили так, что о них можно было только мечтать, и мы исправно тянули iSCSI по гигабитным линкам, считая, что 1 Гбит/с - это нормально.

Ненормально. Просто долго не было хорошей альтернативы по цене.

Этим летом что-то начало меняться: 10GbE-адаптеры от Intel и Chelsio появились у российских дистрибьюторов по ценам, которые уже не вызывают физической боли. Не дёшево, но аргументируемо. Мы взяли пару карт и поставили на два хоста виртуализации, которые активнее всего работают с iSCSI-хранилищем.

Что не устраивало раньше

На нашем объекте с виртуализацией - несколько хостов VMware ESX, общее iSCSI-хранилище - симптомы накапливались постепенно. По мере того как виртуальных машин становилось больше, а среди них появились базы данных и 1С, стало заметно: дисковый I/O у виртуалок проседает именно в часы пик. Сами хосты загружены умеренно, процессор не при делах, на хранилище полки живые - а запросы к диску тормозят.

Стандартный диагноз - iSCSI-трафик делит гигабитный линк с обычным ethernet-трафиком виртуалок. При активной нагрузке на хранилище сеть становится бутылочным горлышком. Мы разносили трафик по разным физическим портам, прокладывали отдельные кабели - помогало, но не радикально. Гигабит остаётся гигабитом.

Thin provisioning мы разбирали отдельно - там была другая история. Но именно тот разбор показал, что нужно смотреть на всю цепочку от хоста до полки системно, а не только на заполнение пулов.

Как ставили

Карты встали без особых хлопот - физически. Серверные платформы у нас с PCIe x8, слоты нашлись. Драйверы под ESX 3.5 пришлось немного поискать, но ничего экзотического: Chelsio кладёт их на сайт, а для Intel e10g* всё оказалось в стандартном наборе для нужной версии.

Интереснее была история с сетью. Сначала мы просто подключили 10GbE-порты в тот же коммутатор и оставили storage-трафик на том же VLAN. Работает. Быстрее. Но через несколько дней мониторинга стало ясно: картина нечистая - broadcast-домен один, в нём крутится всё подряд, и при определённых условиях latency на iSCSI начинает гулять.

Решение, которое оказалось правильным - выделенный VLAN под storage-трафик. Отдельная подсеть, отдельный VLAN, iSCSI-трафик в нём не пересекается с виртуальными машинами и управляющим трафиком. На коммутаторе trunk-порт к хосту несёт оба VLAN, но VMware ESX умеет их разруливать через vSwitch - один виртуальный коммутатор под VM-трафик, другой под iSCSI VMkernel-порт.

Разница почувствовалась сразу. Не в попугаях синтетических бенчмарков - в реальной картине: база данных перестала жаловаться на I/O wait в часы пик, 1С-сессии стали шустрее, и мониторинг перестал подсвечивать узкое место на сетевом уровне.

Что получилось в итоге

Конкретные наблюдения после пары недель эксплуатации:

Выделенный VLAN - не паранойя, а необходимость. Смешивать storage-трафик с остальным на одном broadcast-домене - значит создавать непредсказуемые задержки, которые сложно диагностировать. Отдельный VLAN снимает эту проблему структурно.

Jumbo frames стоит включить. MTU 9000 на storage VLAN снижает накладные расходы при больших блоках - это заметно на последовательных операциях. Но нужно согласовать на всех узлах цепочки: хост, коммутатор, хранилище. Если где-то MTU меньше - сюрпризы гарантированы.

10GbE не заменяет Fibre Channel, но для iSCSI по делу. Когда мы строили iSCSI-хранилище, аргумент был именно в доступности: FC-инфраструктура дорогая, iSCSI по ethernet - нет. С 10GbE этот аргумент стал ещё весомее: скорость сопоставимая, цена входа - несравнимо меньше.

Два порта лучше одного. На одном из хостов мы оставили одну 10GbE-карту - и обнаружили, что при отказе апстрима весь storage недоступен. На втором хосте поставили две карты, настроили multipath iSCSI - там всё аккуратнее. Первый хост стоит в плане на доработку.

Что дальше смотрим

Пока непонятно, как поведёт себя связка при росте числа виртуалок - у нас сейчас около двадцати машин на двух хостах, и запас по полосе есть. Интересно, где появится следующее узкое место: на самом хранилище, на контроллере дисков или где-то ещё. Мониторинг настроен, смотрим.

В managed-сопровождении мы теперь явно закладываем выделенный storage VLAN и 10GbE в рекомендации для объектов с виртуализацией и SAN. Если клиент думает «куда потратить следующий ИТ-бюджет» и у него есть iSCSI - этот вопрос перестал быть сложным.

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.