Низкая производительность как iSCSI, так и AoE


9

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

Для тестирования мы используем:

  • Fujitsu Siemens RX200 S4 в качестве цели
  • Fujitsu Siemens RX200 S4 в качестве инициатора
  • NetGear управляемый 1-битный коммутатор
  • встроенные сетевые адаптеры (Broadcom w / TOE), сетевые адаптеры EdiMax, сетевые адаптеры Broadcom w / TOE - все 1 Гбит
  • целевой сервер использует контроллер QLogic с 6 накопителями WD Blue SATA емкостью 2 ТБ.
  • как целевая, так и исходная операционные системы - Ubuntu 16.04 LTS со всеми обновлениями. Переключатель предназначен для хранения. Мы тестируем связи и многолучевость.

Наша проблема - низкая скорость чтения. Для тестирования мы используем ddи файл 40-100GB.

  • локальное чтение и запись на целевом сервере более 300 МБ / с.
  • Запись на сервер по протоколу iSCSI или AoE превышает 200 МБ / с, что нас устраивает.
  • чтение с сервера всегда 95-99 МБ / с.

Мы попробовали ietd, aoetools, LIO. Мы использовали облигации 2 сетевых карт: balance-rr и LACP, многолучевые с rr. Используются нормальные и гигантские кадры. Наконец, мы даже установили прямое сетевое соединение между целью и хостом (без коммутатора).

Все тесты дают более менее одинаковые результаты (конечно, использование обычных сетевых карт без ОО и iSCSI дало на 20-30% худшие результаты).

Тестирование сети с помощью iperf показало скорость передачи около 200 МБ / с (2 ГБ). Наблюдение за использованием сетевых карт на цели с bmon показало равную загрузку обоих устройств (каждое около 50 МБ / с для чтения, около 100 МБ / с для записи).

Поскольку нам не повезло, мы решили использовать третий сетевой адаптер (конечно, обе стороны). Результаты были странными:

  • 2 сетевых карты - 50 МБ / с каждый
  • 3 сетевых карты - 33 МБ / с каждый

Существуют ли ограничения для целевого программного обеспечения, которое отключает вывод более 1 Гбит / с?

Что мы делаем не так?


5
10GbE достаточно дешев в наши дни. Если вам нужна большая полоса пропускания (чего у вас нет), это рекомендуемый путь.
ewwhite

1
10 GbE не поможет с ATAoE, это очень неэффективный протокол Ethernet. Специально для Jumbo кадров!
BaronSamedi1958

1
Я имел в виду iSCSI. ATAoE мертв и не должен использоваться для этого.
ewwhite

Ответы:


11

Чтобы выжать максимальную производительность из подключенного к iSCSI хранилища, вы должны использовать Jumbo Frames и MPIO (не LACP). RDMA / iSER рекомендуется, если вы можете сделать это.

AOE (ATA через Ethernet) стар и дерьмо. Мы уже избавились от Coraid много лет назад. Мы используем StarWind https://www.starwindsoftware.com/ в качестве цели iSCSI уже довольно давно, и StarWind попросил нас перейти с Coraid на любое хранилище, которое мы могли бы сделать.

Так что сейчас мы отлично справляемся с iSCSI, предоставленным StarWind, и используем Windows, ESX и SCST http://scst.sourceforge.net/ в Linux в качестве инициаторов. С RDMA / iSER он работает до 10 Гбит, очень доволен до сих пор.


6

Ваши ожидания относительно того, как работает агрегация Ethernet-соединений, неверны.

Все методы агрегации, кроме balance-rr (т. Е. Все методы с режимом> 0), не дают вам большей пропускной способности для одного соединения; скорее, они увеличивают общую доступную полосу пропускания, когда устанавливается несколько соединений от / к уязвимым хостам. Другими словами, LAG / LACP не даст вам никаких преимуществ для этого сценария с одним соединением.

Единственный метод агрегации, который может дать вам пропускную способность за один сеанс, превышающую то, что вы обычно имеете на одном интерфейсе, это balance-rr , который распределяет пакеты циклически. Вы должны были установить баланс-RR на обоих инициатора и цели. Однако большой улов заключается в том, что это в значительной степени зависит от переключателя.

В любом случае, если вы установите для target и initiator баланс-rr, прямое соединение двух машин должно повысить производительность. Если нет, можете ли вы опубликовать iperfс BalanceRR и обе машины напрямую подключены (без коммутатора)? Также, пожалуйста, напишите точную ddкоманду, которую вы использовали для бенчмаркинга.


2

Примечание: я говорю только об iSCSI здесь. У меня нет опыта работы с AoE, кроме того, что я о нем читал, и я бы не стал реализовывать его в какой-либо новой инфраструктуре (это в значительной степени не работает).

Не используйте balance-rr для чего-либо, кроме некоторых очень специфических протоколов точка-точка. Он имеет ужасную производительность в условиях практически любой нагрузки в реальном мире и вызывает множество проблем в сети (таких как МНОГО дрожания). Определенно не используйте это с выключателем.

Используйте MPIO без какого-либо соединения на стороне инициатора для достижения балансировки нагрузки и отказоустойчивости. Чтобы гарантировать, что ваши пути не будут «перепутаны» при отправке всего вашего трафика по одному пути, поместите отдельные пути (гигабитные сетевые адаптеры между целью и инициатором, в вашем случае) в отдельные подсети.

Не стесняйтесь связать целевую сторону с LACP для каждого пути (как в двух связях для двух путей для всего четырех сетевых адаптеров, как пример конфигурации целевого порта). Это прекрасно работает и может сбалансировать несколько подключений инициатора, которые используют одни и те же пути. Также используйте jumbo frames и iSER, если это возможно. Использование LACP на цели уравновесит соединения к каждому пути между несколькими сетевыми картами.

Использование LACP на инициаторе будет эффективным только в том случае, если он устанавливает много целевых подключений к порталу с одновременным использованием (не характерно практически для любой рабочей нагрузки). Даже если бы вы эффективно внедрили LACP для каждого пути на инициаторе, это быстро превратилось бы в кошмарный кабель, чтобы использовать (например) четыре дополнительных матрицы для каждой коробки. Если вам требуется пропускная способность более 2 Гбит / с для одного инициатора, рассмотрите 10 Гбит / с Ethernet.


1

Большинство ответов по AoE совершенно неверны, противоречивы и показывают отсутствие знаний и опыта AoE. Во-первых, это не перестал существовать. CORAID является поставщиком AoE, и они перезапустились как «SouthSuite», сохранив при этом товарный знак CORAID. Они тоже разработчики. Они делают новые продукты и поддерживают большинство старых. Они также продвигают развитие AoE, как ясно показывают их открытые технические списки рассылки. Проверьте веб-сайт, он все в курсе и рассказывает всю историю на своей странице истории.

Кто-то сказал, что AoE не получит выгоду от гигантских фреймов, и это тоже было неправильно. Он был поддержан после выхода 13-й версии vbladed. Вам нужно настроить MTU для поддержки нового размера кадра, но в остальном он прекрасно работает.

iSCSI работает на уровне 5 модели OSI. Обычный транспорт это TCP. Это дает вам некоторое исправление ошибок (из-за контрольных сумм в TCP) и позволяет вам маршрутизировать трафик по IP на уровне 3. На этом преимущества iSCSI заканчиваются. Производительность в реальном мире просто ужасна, если сравнивать ее с чем-то вроде FCP, AoE или FCoE. Я бы пригласил вас в Google «Сравнение производительности iscsi» для шоу ужасов.

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

Агрегация 802.3ad не сильно увеличит пропускную способность вашего единого потока даже в циклическом сценарии. Это также усложнит конфигурацию вашей сети и предоставит вам пару новых возможностей для того, чтобы застрелиться в ноге, не согласовав интервалы между PDU или неверно сконфигурировав канал Cisco VPC для поддержки активного состояния. Не используйте LACP с AoE, пусть он обрабатывает свою собственную многопутевую передачу и мультиплексирование. Более поздние версии AoE справляются с этим красиво, и в большинстве случаев более изящно, чем даже FCP, поскольку все это происходит автоматически. Дополнительные порты Ethernet обеспечивают большую пропускную способность и повышенную отказоустойчивость. Если вы распределите порты Ethernet хоста и инициатора по нескольким коммутаторам, это может обеспечить еще большую избыточность. Нет необходимости настраивать режим склеивания. Кроме того, не запускайте IP на тех же интерфейсах, которые вы используете для AoE.

Короче говоря, не слушайте скептиков AoE, они думают, что у них нет большого опыта и они просто бегают по модным мозговым волнам. Избегайте стадо. Сконфигурируйте резервное хранилище с предварительно настроенной ручной загрузкой, и вы, вероятно, увидите, что ваша пропускная способность чтения возрастет. Откажитесь от использования протоколов агрегации и запускайте крики из iSCSI. И наконец, прекратите использовать 'dd', это не очень хороший тест, и он подвержен плохим эффектам кэширования. Используйте настоящий инструмент для тестирования, такой как 'fio', 'iozone' или 'dbench'. Те дают гораздо более надежные результаты.


1

Я знаю, что LACP для нескольких соединений. Тестирование это был акт отчаяния :)

Все тесты были проведены с балансом -rr и двумя сетевыми картами.

Запись в цель iSCSI:
dd if = / dev / zero of = / mnt / zero.bin bs = 1M count = 2000
2000 + 0 przeczytanych recordww
2000 + 0 zapisanych recordów
2097152000 байт (2,1 ГБ, 2,0 ГиБ) скопировано , 10,1093 с, 207 МБ / с

Чтение из целевого объекта iSCSI:
dd if = / mnt / zero.bin of = / dev / null bs = 1M
2000 + 0 записей przeczytanych -
2000 + 0 записей zazisanych -
2097152000 байт (2,1 ГБ , 2,0 ГиБ) скопировано, 16 164 с, 130 МБ / с

Скорость сети:
iperf -c 172.16.10.80
------------------------ ------------------------------------
Клиент подключается к 172.16.10.80, TCP-порт 5001
Размер окна TCP: 325 Кбайт (по умолчанию)
--------------------------------------------- ---------------
[3] локальный 172.16.10.70 порт 37024, связанный с 172.16.10.80 портом 5001
[ID] Пропускная способность интервала передачи
[3] 0,0-10,0 с 2,30 ГБайт 1,98 Гбит / с

Тестирование с использованием кадров iperf и jumbo дало одинаковые результаты.

Я набрал некоторую скорость чтения, запустив инициатор:
hdparm -a 2048 / dev / dm-1
Ранее это было 256, а скорость чтения была 96 МБ / с.
Моя цель - достичь скорости чтения около 200 МБ / с.

РЕДАКТИРОВАТЬ:
1. Мы не используем LACP - это был один раз тест.
2. Тестирование с балансом -rr и MPIO дает точно такие же результаты. Multipathing был протестирован с сетевыми картами в разных подсетях.
3. Добавление большего количества сетевых карт не увеличивает скорость чтения, а только уменьшает использование каждого сетевого адаптера.
4. Мы думаем, что проблема в некотором ограничении (драйвер, модуль?), Которое не позволяет читать быстрее. Но я не уверен, является ли это целью или инициатором.


РЕДАКТИРОВАТЬ 2: Только что сделал дополнительный тест: настроил тот же хост в качестве цели и инициатора, чтобы избавиться от проблем сетевого оборудования. Я был в шоке: точно такая же скорость чтения! 130 МБ / с! Запись составляет 227 МБ / с.


Чтобы использовать LACP при использовании iSCSI, необходимо иметь несколько подключений на сеанс. Нет mc / s = нет прироста производительности. scst.sourceforge.net/mc_s.html и starwindsoftware.com/blog/… могут помочь.
BaronSamedi1958

-2

как вы настроили свой ник, правильно ли настроены все буферы, достаточно ли оперативной памяти для сетевых буферов. здесь также не используется связывание, вы можете использовать 2 канала iscsi и использовать их для многопутевого канала на инициаторе, так же, как и в ATAoE, многопутевые каналы инициатора по полкам и лунным ID на любом пути.


Есть ли какие-либо проверки и / или изменения конфигурации, которые вы могли бы предложить сделать? Даже если у вас нет полного ответа, он поможет вашему ответу и другим, если вы можете дать некоторые подсказки, чтобы направить спрашивающего в правильном направлении
iwaseatenbyagrue
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.