Добрый день, коллеги
Внезапно, хорошее слово :-), возникла необходимость использовать iSCSI в Solaris10 для подключения десятка лунов на серьезном продуктиве. Сервера и массивы Оракл.
iSCSI софтварный, т.е. используются обычные гигабитные карточки Ethernet.

Сталкивался ли кто-то с тюнингом sd_max_throttle если луны подключены по iSCSI в Solaris10?
Параметр тюнится аналогично FC?
Если кто-то реально сталкивался, прошу прокомментировать ваши бест-практиз.
Т.к. одни пишут, что тюнить не надо, другие - что аналогично FC, третьи - что параметр надо тюнить исходя из количества CPU. Хотелось бы понять, кто прав.

Столь острое желание возникло в связи с тем, что меняется конфигурация комплекса.
Там где было три хоста и 20 лунов по FC, теперь будет 1 хост и 20 лунов по iSCSI.
Не хочется поймать проблемы с queue overruns когда все взлелит.
А однозначных рекомендаций пока не нашел.

Из того что удалось пощупать перед стартом процесса переезда были примерные пиковые цифры:
150 МБ/c Write
150 МБ/c Read
3000 IOPS Write
2000 IOPS Read

Теоретически в пике можем попасть на сумму по Read+Write.

Поэтому хочется по максимуму сгладить проблемы заранее.

Scott TigerВендор таргета может иметь свое мнение, и с ним, как правило, нужно считаться..
Вендор таргета пишел о "2048 commands in the queue for an HBA", но нигде не упоминается ситуация, когда iSCSI идет через NIC, а не через HBA.

Scott Tiger Во-вторых, проблемы будут, скорее, на уровне Ethernet-а, в частности - на драйверах сетевых адаптеров. Если вычислительных мощностей достаточно, отключите interrupt moderation/interrupt throttling, повесьте обработку прерываний от этих драйверов на отдельные процессоры. В-третьих, если мы говорим про производительность инициатора, то для него очередь в sd-драйвере - это просто еще один буфер в ядре, через который IO должно протолкнуться, и на это проталкивание нужно некоторое время.

Вычислительных мощностей более чем достаточно, затык в вводе-выводе.
Спасибо за рекомендацию, почитаю, поразмыслю.


Scott TigerЯ бы на Вашем месте поставил эксперимент на имеющемся оборудовании с известной нагрузкой, и уже оттуда строил бы какие-то выводы. Впрочем, я почти уверен, что если будут проблемы, то они будут не в sd, а в транспорте, особенно - на гигабите.
Из того что удалось потестить на новом железе видно, что по iSCSI через NIC сотни мегабайт летят на ура, но как только начинаются большие IOPS-сы - все становится намного грустнее.

Basil A. SidorovВы, эта ... Характеристиками Ethernet-а никогда не интересовались?
Есть пакет и межпакетный интервал фиксированной длительности. У гигабитного Ethernet-а (кроме прочих) две особенности:
1. Любой пакет короче 2048 бит будет дополнен специальной последовательностью до этих самых 2048 бит;
2. Железка может отправлять пакеты пачками (в монопольном режиме).
Первая особенность для iSCSI не особо существенна, но будет ухудшать утилизацию полосы для коротких пакетов.
Вторая особенность может незначительно улучшить утилизацию полосы для коротких пакетов, но, опять-таки, несущественно.
В сухом остатке остаётся предел полосы ~= 110 мегабайт/с и что-то около 100-150 килопакетов в секунду.
Второго, теоретически, вам должно хватить, а вот первое ...
Вы правда думали, что самые волшебные припарки могут заменить "трижды FC" на единственный гигабит?
Спасибо за подробности. Для меня, неспециалиста в Ethernet, они знакомы только отчасти.
Я был категорически против переезда с FC на iSCSI на продуктиве, но .... Партия (и финансовый кризис) сказала надо.
Вот пока ситуация видится в точности наоборот.
Агрегировав три гигабитных линка и отдав их iSCSI удалось получить хорошие МБ/c (порядка 250 МБ/c), но вот получить хорошие IOPS с луна по iSCSI пока не получается.

Basil A. SidorovОграничивает именно сеть или, всё-таки, возможности дисков хоста?
Пока не уверен. iostat иногда показывает какую-то ересь со стороны Solaris10.
Циферок больше чем 250 wIOPS на лун я пока не видел.

С большей вероятностью затык на стороне массива.

Немного разобрался.
По циферкам в iostat - циферки правильные. Клиент немного дезинформировал о запущенной загрузке, по факту оказалось основная нагрузка только будет впереди. Также на некоторых лунах был отключен кэш на запись.

С включенным кэшем на запись и сгенерированной мной нагрузкой на iSCSI LUN циферки показывает такие:

r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device
4.0 5034.3 32.0 165504.0 115.4 233.5 22.9 46.3 75 99 c0tXXXXXXXXXXXXXXXXd0
...
0.0 7648.0 0.0 82602.0 183.2 256.0 24.0 33.5 100 100 c0tXXXXXXXXXXXXXXXXd0

Нормально, должно хватить.

Scott TigerЕсли вычислительных мощностей достаточно, отключите interrupt moderation/interrupt throttling, повесьте обработку прерываний от этих драйверов на отдельные процессоры.
Сервер имеет интерфейсы e1000gX.

Не нашел на MOS-e суппортной возможности отключить "interrupt moderation/interrupt throttling".
Interrupt Coalescence (also called Interrupt Moderation, Interrupt Blanking, or Interrupt Throttling).


Jumbo для агрерированных интерфейсов отданных под iSCSI прикрутил.

Вешать прерывания на отдельные CPU похоже смысла нет. Посмотрел, загрузка на CPU ответственных за нужные NIC небольшая.

Всем спасибо, немного сориентировался, хотя связка iSCSI через NIC и величина sd_max_throttle так и не понято до конца.

Scott Tigerasvc_t у Вас не очень
Это я запустил на один лун максимальную нагрузку через ряд потоков DD чтобы понять какие максимальные IOPS-сы примет лун. Соответственно, на пиковой нагрузке вылез и asvc_t. На продуктиве нагрузка должна быть меньше на один лун.

Scott Tiger https://docs.oracle.com/cd/E23824_01/html/821-1458/gkind.html
За ссылку спасибо.
Но на Solaris10 не едет. Нет таких параметров.

# dladm show-linkprop -p _intr_throttling_rate e1000g0
dladm: cannot get link property '_intr_throttling_rate': object not found
# dladm show-linkprop -p _intr_throttling_rate aggr1
dladm: cannot get link property '_intr_throttling_rate': object not found

# dladm show-linkprop -p _intr_adaptive e1000g0
dladm: cannot get link property '_intr_adaptive': object not found
# dladm show-linkprop -p _intr_adaptive aggr1
dladm: cannot get link property '_intr_adaptive': object not found

# ndd /dev/e1000g0 \?
? (read only)
autoneg_cap (read only)
pause_cap (read only)
asym_pause_cap (read only)
1000fdx_cap (read only)
1000hdx_cap (read only)
100T4_cap (read only)
100fdx_cap (read only)
100hdx_cap (read only)
10fdx_cap (read only)
10hdx_cap (read only)
adv_autoneg_cap (read and write)
adv_pause_cap (read only)
adv_asym_pause_cap (read only)
adv_1000fdx_cap (read and write)
adv_1000hdx_cap (read only)
adv_100T4_cap (read only)
adv_100fdx_cap (read and write)
adv_100hdx_cap (read and write)
adv_10fdx_cap (read and write)
adv_10hdx_cap (read and write)
lp_autoneg_cap (read only)
lp_pause_cap (read only)
lp_asym_pause_cap (read only)
lp_1000fdx_cap (read only)
lp_1000hdx_cap (read only)
lp_100T4_cap (read only)
lp_100fdx_cap (read only)
lp_100hdx_cap (read only)
lp_10fdx_cap (read only)
lp_10hdx_cap (read only)
force_speed_duplex (read and write)
link_status (read only)
link_speed (read only)
link_duplex (read only)
link_autoneg (read only)
tx_bcopy_threshold (read and write)
tx_interrupt_enable (read and write)
tx_intr_delay (read and write)
tx_intr_abs_delay (read and write)
rx_bcopy_threshold (read and write)
max_num_rcv_packets (read and write)
rx_intr_delay (read and write)
rx_intr_abs_delay (read and write)

Scott TigerЧто касается вынесения обработки прерываний на отдельные процессоры - это просто возможность чуть снизить время отклика забесплатно (при достатке или избытке вычислительной мощности, при работе на пределе или за ним нужно думать, что важнее - отсутствие конкуренции за процессор от прикладных задач или "зеленый свет" вводу-выводу). 3 гигабитных адаптера при полностью отключенном interrupt throttling-е современные процессоры, конечно, не сильно пригрузят, но зачем впустую терять производильность? intrstat в помощь.
Вник в конкретику. Оказывается в Solaris 10 нет суппортноо метода привязать конкретное прерывание к выделенному CPU.





Scott TigerTxInterruptDelay и MaxNumReceivePackets в e1000g.conf в чём-то поможет. man e1000g. А вообще - обновляйтесь :)
Таки да, на Solaris11 многое решилось бы меньшей кровью.
На параметры TxInterruptDelay и MaxNumReceivePackets я также смотрел, но пока не смог достонально понять их суть, а документации по ним и бест-практиз как-то не густо.

В любом случае, спасибо.

Так как процов на сервере очень много, а со стороны массива тюнить такую привязку к CPU не могу, то просто помониторил загурзку CPU с обеих сторон в момент активной нагрузки.
Активная нагрузка по iSCSI. iSCSI работает по трем агрегированным гигабитным линкам с Jumbo.

Со стороны массива
Стоит восемь virtual processor i386 processor operates at 2300 MHz.
Худшие значения были такие:
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 0 0 118 9298 201 3344 52 1290 4113 0 465 33 64 0 3
1 0 0 183 13228 4041 4536 72 1780 5732 0 487 7 87 0 6
2 0 0 7416 12170 4231 4312 119 1697 5524 9 405 2 92 0 5
3 0 0 14436 18278 11507 3291 166 1430 4989 13 1149 2 93 0 5
4 0 0 8262 20118 12480 3350 111 1429 5254 7 402 0 95 0 4
5 0 0 14986 14956 8236 3507 152 1372 5350 16 599 0 95 0 5
6 0 0 71 9295 227 3208 31 1168 3860 0 1115 38 56 0 6
7 0 0 1612 9156 122 4578 33 1707 5720 0 1145 10 86 0 4
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 0 0 35 9248 201 3088 55 1140 3655 0 212 35 62 0 3
1 0 0 327 13372 4237 4577 73 1699 5637 0 55 4 91 0 5
2 0 0 7360 12021 4152 4187 122 1616 5503 6 527 1 93 0 6
3 0 0 13858 18448 11583 3443 164 1429 4906 13 38 0 94 0 5
4 0 0 8540 20579 12930 3614 110 1377 4969 9 140 1 93 0 6
5 0 0 15066 14833 8104 3679 150 1363 5187 16 1004 0 94 0 6
6 0 0 259 9502 227 4359 41 1432 5038 0 1255 13 80 0 6
7 0 0 1538 8764 108 2830 29 962 3223 0 1033 42 54 0 4
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 0 0 195 9085 202 3365 51 1089 4116 0 109 34 65 0 1
1 0 0 581 14242 5395 4277 77 1579 5618 0 76 5 90 0 5
2 0 0 7035 12059 4341 4151 130 1535 5514 8 1054 1 94 0 4
3 0 0 13385 19421 12718 3302 176 1346 4918 12 362 0 95 0 4
4 0 0 8037 22546 15086 3417 119 1294 4917 10 992 2 94 0 4
5 0 0 14415 15123 8503 3642 163 1266 5212 18 55 0 95 0 4
6 0 0 492 9139 228 4090 36 1375 4978 0 1180 20 76 0 4
7 0 0 1441 8769 114 3644 26 1236 4241 0 1463 32 63 0 5

Со стороны сервера
Обработкой трех гигабинтых линков задействованых в ISCSI занимаются
три virtual processor sparcv9 processor operates at 2998 MHz.
Худшие значения были такие:
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
17 0 0 4057 11671 4778 13742 2 0 24 0 1 0 15 0 85
21 0 0 1779 2450 2439 19 0 0 29 0 10 0 4 0 96
25 0 0 1731 2479 2468 20 0 0 24 0 10 0 4 0 96
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
17 0 0 4475 13537 5696 15640 2 0 21 0 0 0 17 0 83
21 0 0 1666 2743 2732 19 0 0 29 0 10 0 4 0 96
25 0 0 1617 2760 2749 18 0 0 24 0 9 0 4 0 96
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
17 0 0 3193 11137 3374 15471 2 0 24 0 0 0 13 0 87
21 0 0 1417 1741 1729 21 0 0 12 0 12 0 3 0 97
25 0 0 1350 1700 1691 15 0 0 14 0 11 0 2 0 98


Наглядно видна разница между загрузкой sparcv9 и i386.
Похоже если и будет затык, то это будет затык по CPU при обработке iSCSI на стороне массива.

Scott TigerА "массив" - это что-то из Amber Road-ов (7х10)?
Да.

Scott TigerЗагрузка приличная на нём, я бы попрофилировал ядро просто ради интереса. См. hotkernel.d (может потребоваться доработка напильником) и lockstat -CcwP.
Профилировать из шелла не суппортно, пока будет лететь так как есть.
А за нагрузкой я понаблюдал немного. Все сервисы на массиве отключил, кроме обязательных и iSCSI.
Как только заходишь на массив через http на просмотр графиков нагрузки - сразу одно ядро нагружается д 100%.
Поступает сильная нагрузка на запись - остальные ядра начинают нагружаться достаточно быстро.
Т.к. трафик идет по трем линкам iSCSI и все диски в RAID6, то рост нагрузки на CPU понятен :-)

МутагенGASTROPODA Агрегировав три гигабитных линка

Это точно неверное решение. Во-первых, LACP агрегаты не дадут соединению между двумя устройствами скорость более чем одного линка, ...
Правильное решение для iSCSI - индивидуальные сетевые соединения и мультипасинг на сервере (точно как с FibreChannel)
Оппонирую.
Вид со стороны массива (nge1+nge2+nge3=aggr1) - см. картинку

Вид со стороны сервера - (e1000g1+e1000g10+e1000g20=aggr1)
# dladm show-aggr -s -i 1 -p
key:1 ipackets rbytes opackets obytes %ipkts %opkts
Total 11059 859552 20683 164552530
e1000g1 2849 216258 5328 42685858 25.8 25.8
e1000g10 5483 435034 10259 81046864 49.6 49.6
e1000g20 2727 208260 5096 40819808 24.7 24.6

key:1 ipackets rbytes opackets obytes %ipkts %opkts
Total 10446 826476 19576 155880132
e1000g1 2671 196380 5014 39901672 25.6 25.6
e1000g10 5299 430442 9942 79095086 50.7 50.8
e1000g20 2476 199654 4620 36883374 23.7 23.6

key:1 ipackets rbytes opackets obytes %ipkts %opkts
Total 11570 901268 21691 170872798
e1000g1 2866 233772 5344 41914606 24.8 24.6
e1000g10 5549 438838 10419 82006864 48.0 48.0
e1000g20 3155 228658 5928 46951328 27.3 27.3

key:1 ipackets rbytes opackets obytes %ipkts %opkts
Total 13810 1036498 25929 205850010
e1000g1 3627 276804 6818 54680588 26.3 26.3
e1000g10 6959 517546 13068 103002036 50.4 50.4
e1000g20 3224 242148 6043 48167386 23.3 23.3

key:1 ipackets rbytes opackets obytes %ipkts %opkts
Total 10912 792738 20419 162520344
e1000g1 2578 198368 4824 38634486 23.6 23.6
e1000g10 5587 393042 10450 82948254 51.2 51.2
e1000g20 2747 201328 5145 40937604 25.2 25.2

[quote Мутаген]GASTROPODA ... во-вторых балансировка там работает по числу линков в степени 2 (ie должно быть 2,4 или 8 линков).
Про это я когда-то читал, но не уверен, что сейчас ситуация не изменилась. Да и больше чем три линка отдать все равно не могу.