Низкая произв-ноcть дисковой подсистемы на IBM BladeCenter S

[nimus]

Раз уж с этим термином есть непонятки, буду писать "заявленные характеристики". Так вот, заявленные характеристики:
- 4 шины по 3 Гб от каждой корзины на каждый САС контроллер (у нас корзина одна, т.е. 12 Гбит от неё на первый САС контроллер и 12 на второй);
- от каждого САС контроллера до каждого лезвия по 3 Гбита;
- 4 Гбита между контроллерами;
- чип в каждом контроллере LSI 1064E обрабатывает до 4 ГБайт в секунду;
- 6 HDD со средней линейной скоростью чтения и записи около 170Мб/сек;
- если контроллера два, то пулы распределяются между контроллерами, т.е. максимум от RAID подсистемы до лезвий можно выжать до 6 Гбит, но на один пул не более 3 Гбит;
- дополнительная управляющая шина САС контроллеров по Гбит.

Надеюсь вы не подумали, что производительность рейд контроллера на линейных операция равна суммарной пропускной способности всех шин от него к дискам? А то если вдруг подумали, то это вы зря

)) Идея хорошая, надо будет так подумать )) Ну а если серьезно, то я написал выше, что рассчитываю на минимум, т.е. самую узкую шину, т.е. 3Гбита. При этом учитываю, что винты точно читают быстрее, а контроллер точно обрабатывает больше.

[nimus]

Так вот, заявленные характеристики:
...
Откуда Вы их в таком виде взяли, если не секрет?

Конечно не секрет. Детально изучил документацию на шасси и отдельные конструктивные элементы. Большинство из характеристик указано в целом ряде документов и найти их оказалось очень просто. Вот основные источники:
IBM SAS RAID Controller Module Installation and user guide v2:

Код: Выделить всё

Hardware features and specifications
This section provides a summary of the features and specifications for the IBM
BladeCenter S SAS RAID Controller Module.
The SAS RAID Modules support the following features:
v 6 internal 1X SAS 3.0 Gb host connectivity to 6 blade slots
v 2 internal 4X SAS 3.0Gb to 2 disk storage module (DSM ) systems
Chapter 1. Introduction 7
v 1.0 Gb Ethernet for RAID management
v 10/100 Ethernet for Switch management
v Serial SAS Protocol
v Serial Management Protocol (SMP) as defined in the SAS specification
v Fourteen internal x1 links to Blade servers

IBM BladeCenterSAS Expansion Card (CFFv) Installation and User's Guide:

Код: Выделить всё

SAS is a high-speed data transport technology used for mass storage attachments. The SAS expansion card allows you to attach a blade server or expansion unit to external storage. The expansion card provides up to 6 Gb of full-duplex bandwidth per port.
SAS specifications v Bandwidth: 3 Gb per second maximum at half-duplex and 6 Gb per second maximum at full-duplex per port.
SAS device Single-chip design with two completely independen.

Дополнительно доступно в просмотре детальной информации по контроллерам:

Код: Выделить всё

<CLI> detail controller –ctlr [0|1]
…
Target port speed : 3Gbps
…
для контроллера 0:
Associated Volumes currently serviced by this controller    :
|     0|                Pool_Sys:v1|    139GB|          0|                     VBL INI|
|     1|                Pool_Sys:v2|    139GB|          0|                     VBL INI|
для контроллера 1:
Associated Volumes currently serviced by this controller    :
|     0|                  Pool_1:d1|   1395GB|          0|                     VBL INI|

Если читать это внимательно, то видно, что в оригинале у IBM данные характеристики озаглавлены как «specifications». Именно поэтому в первых постах я писал о характеристиках как спецификации.

[nimus]

При всем уважении, картина из HDTUNE не может никоим образом характеризовать ограничения шины или контроллера.

Всё верно, но картинка забавная. Такой же тест на прочих серверах дает изогнутую линию с падающей к концу дисков скоростью с показаниями, примерно равными физическим возможностям жестких дисков в массиве (если для RAID 0, то суммарной, для RAID 0+1 равной скорости половины устройств). Ну и максимум совсем другой. Те же 4 Seagate 250Гб SATA в RAID 0+1 дают больше скорость чем этот массив, а корзина из 4-х SAS винтов на 67Гб показывает скорость от 160 в начале до 120 в конце. Повторюсь, железо там несоизмеримо более слабое.
И хотя это не есть главный показатель, но понять откуда ограничение в 90МБ/сек очень интересно и полезно. Как минимум это поможет наиболее эффективно использовать имеющееся оборудование.

Предлагаю указать настройки иометра, на которых были получены такие результаты:
DB pattern: чтение/запись в случайном порядке (60% чтение / 40% запись), размер блока 4Кбайт - 110-120 IOPS; 0.4-0.5 МБ/сек.
В частности, outstanding ios.

Данные значени для outstanding ios = 1. Для outstanding ios = 64 показания такие: 300 IOPS; 1.2 МБ/сек. Это фактический достигнутый максимум на длинной очереди. Больше ИОПСы уже не растут при прочих настройках.
Например, при таком кол-ве outstanding ios тезультаты теста далее меняются, хоть в 1, хоть в 8 потоков гонять. Т.е. даже если outstanding ios = 8*64.

[ITER]

)) Идея хорошая, надо будет так подумать )) Ну а если серьезно, то я написал выше, что рассчитываю на минимум, т.е. самую узкую шину, т.е. 3Гбита. При этом учитываю, что винты точно читают быстрее, а контроллер точно обрабатывает больше.

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

[Black-Dragon]

Производительность рейда определяется производительностью процессора в этом рейде и "особенностями" (кривостью) прошивки, ПСП кеш памяти рейда, шиной синхронизации кеша м-ду контроллерами (если их два) и т.д. и т.п. Но никак не какими либо характеристиками внешних интерфейсов.

Тут по-любому что-то не так. Надо разбираться.

[nimus]

Производительность рейда определяется производительностью процессора в этом рейде и "особенностями" (кривостью) прошивки, ПСП кеш памяти рейда, шиной синхронизации кеша м-ду контроллерами (если их два) и т.д. и т.п. Но никак не какими либо характеристиками внешних интерфейсов.

Производительность процессора в этом рейде позволяет обрабатывать до 4ГБайта в секунду.
ПСП кеш памяти рейда тут вроде не важна, т.к. тормозит не на операциях с кешем.
Шина синхронизации м-ду контроллерами 4Гбита, но и она не должна играть роль, т.к. один пул обслуживает один контроллер.
Шины внешних интерфейсов - тут никакой взаимосвязи, это бесспорно.

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

Но я всё же надеюсь, что как-то можно добиться нормальной производительности.

[ITER]

Производительность процессора в этом рейде позволяет обрабатывать до 4ГБайта в секунду.

Это маркетинговое заявление, не имеющее никакого отношение к реальным возможностям контроллера.

ПСП кеш памяти рейда тут вроде не важна, т.к. тормозит не на операциях с кешем.

Любые операции с данными на рейд контроллере проходят через кеш. Любые! Даже если отключен write back кеш.

Остается кривость прошивки. И если это так для нового оборудоания, плюс данная проблема не лечится, то какие должны быть действия?
Но я всё же надеюсь, что как-то можно добиться нормальной производительности.

Тут есть два варианта любо это действительно какой то глюк и он как то лечится, либо этот контроллер так хреново и работает. Тут надо спросить других "счастливых" обладателей такой же железки, как у них дела с производительностью.

[diz]

Попробуйте создать тему на IBM`овском форуме, желательно не на нашем языке

[nimus]

Тут надо спросить других "счастливых" обладателей такой же железки, как у них дела с производительностью.

Вот это и пробую. Пока найти не могу таковых в рускоязычном сообществе.

[nimus]

Производительность процессора в этом рейде позволяет обрабатывать до 4ГБайта в секунду.

Это маркетинговое заявление, не имеющее никакого отношение к реальным возможностям контроллера.

В режиме RAID-0 быстрого или умного контроллера не надо. Любой десктопный умудряется пропускать 400 МБ/сек, а больше мне и не надо, т.к. шина пропустит только 350-380 МБ/сек. Поэтому я уверен, что скорости контроллера должно быть достаточно. К тому же контроллер за $3500 наврядли искуственно замедлен ниже уровня встроенных в чипсеты простеньких контроллеров.

[exLH]

Конечно не секрет. Детально изучил документацию на шасси и отдельные конструктивные элементы.

Меня больше всего интересовало другое, где у IBM написано вот так:

- 6 HDD со средней линейной скоростью чтения и записи около 170Мб/сек;

Поэтому я уверен, что скорости контроллера должно быть достаточно.

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

P.S. Я не отрицаю что скорее всего именно в Вашем конкретном случае есть какая-то проблема. Но разобраться с ней удаленно мне лично (к примеру) было бы сложновато. А путь решения, который избрали Вы (через претензию к спецификации/гарантии), мне видится бесперспективным. Максимум, чего Вы добьетесь, это полгода разбирательств на самых разных уровнях (начиная от младшего персонала у поставщика, заканчивая судом, результат которого скорее всего будет явно не в вашу пользу). Ищите вменяемого партнера рядом, который приедет и настроит. За деньги.

[nimus]

- 6 HDD со средней линейной скоростью чтения и записи около 170Мб/сек;

Это характристики на Seagate Cheetah 15K.7, которые стоят в корзине. Характеристики опубликованны на сайте Seagate и подтверждены кучей тестов на просторах интернета, например, на toms hardware guide. В начале диска скорость чтения и записи для данного девайса примерно равна 220 МБ/сек.

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

К сожалению, тут доверились поставщику, чего не стоило делать. Во многом свою роль сыграло имя ИБМ. Как вариант предлагалось альтернативное решение Интел (попроще, подешевле), его другой поставщик дал протестировать. Там таких проблем не было. Ожидать их на данной машине и в голову не пришло, особенно учитывая заверения поставщика. К сожалению, главное разочарование уже имеет место. Далее ожиданий уже не много )

Ищите вменяемого партнера рядом, который приедет и настроит. За деньги.

Проблема в том, что специалисты вменяемые есть и у себя в штате. Всё, что можно настроить - общупали. Есть один открытый вопрос: если такое же оборудование у кого-то работает иначе, то это проблема сборки или какого-то отдельного девайса. То, что проблема в настройке - маловероятно. Поэтому я и начал с поиска знакомых с характеристиками таких машин. Видно BladeCenter S не сильно распространен.

Было одно гадкое предположение, которое сегодня подтвердилось в результатах тестов. Об этом в отдельном посте.

[nimus]

Есть первые сдвиги.

На глаза попался тест одного контроллера (http://www.fcenter.ru/online.shtml?arti ... /hdd/27722), который вел себя при тестировании крайне забавно.
При определенной последовательности запуска тестов результат тестов на линейной записи оказывался крайне низким. Падал в 4-10 раз и оказывался меньше скорости одного отдельного устройства. Причем показания были крайне стабильные, но низкие.

147585.png (3.4 КБ) 5507 просмотров

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

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

А теперь самое интересное.
После данного происшествия результаты тестов разительно стали отличаться.
Контроллер забрал себе на обслуживание большой пул и стал летать!!!
Так, на эмуляции работы с БД через IOmeter, кол-во иопсов выросло в 10(!!!) раз до 1200-1400. Линейная скорость записи в один поток осталась на уровне 90МБ/сек, но при параллельном тестировании в несколько потоков выросла с 90 до 240МБ/сек.

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

Увы, через часа 3 контроллер снова решил, что надо «подстроить» производительность на лету, и результат теста на dbpatter через iometer упал почти в 3 раза (до 500 IOPS). Скорость линейного чтения в 8 потоков пока держится на уровне 240 МБ/сек, но, как верно подметил gs, не для этого машина бралась.

В итоге, подтвердилось подозрение в повышенной самостоятельности и шибком уме контроллеров, а также о том, что текущие настройки находятся в состоянии, способном пропускать 1500 IOPS на dbpattern тесте вместо 120-150.
После того, как контроллер зашуршал быстро, настройки не менялись, а скорость снова упала. Следовательно, дело не в настройках.

Теперь главная проблема придумать последовательность действий, которые без временной недоступности контроллера заставят его перейти в нужный режим и, главное, ОСТАВАТЬСЯ В НЕМ. На все выходные поставлю iometer эмулировать работу с БД. Надеюсь к понедельнику свыкнется с мыслью, что это его судьба, и снова будет нормально работать...

[exLH]

Это характристики на Seagate Cheetah 15K.7, которые стоят в корзине. Характеристики опубликованны на сайте Seagate

Вы же не рассчитываете всерьез, что это ссылка на "кучу тестов" будет воспринята как "спецификация IBM"? Я все еще клоню к тому, что претензии к спецификации пока беспочвенны и не имеют перспективы в деле.

[nimus]

Это характристики на Seagate Cheetah 15K.7, которые стоят в корзине. Характеристики опубликованны на сайте Seagate

Вы же не рассчитываете всерьез, что это ссылка на "кучу тестов" будет воспринята как "спецификация IBM"? Я все еще клоню к тому, что претензии к спецификации пока беспочвенны и не имеют перспективы в деле.

Да я и не собираюсь доводить до разборок с поставщиком. Мне надо добиться работоспособности сервера и скорейшего ввода его в эксплуатацию, а не траты время на попытки доказать, кто прав. Ну а спецификация производителя с сайта Seagate - это всё же аргумент. И я для себя их уж точно могу держать в уме, прикидывая что я жду от сервера Особенно учитывая, что мои теоретические познания при расчете производительности прочих 6-ти серверов в организации дают верный результат.

Если уж говорить о винтах, то по примеру данного теста на примере восьми Fujitsu MBA3073RC видно чего я жду.

147584.png (5.4 КБ) 5509 просмотров

Фуджики явно помедленее новых cheetah'ов, но и они легко дают на 4 устройства чуть меньше 500 МБайт в секунду (зеленая линия на графике, RAID 0+1 на 8 дисков даст скорость RAID 0 на 4). Т.е. сомнений, что 6 более быстрых читахов не могут дать 350 МБ/сек быть не может.

А снизу графика видно то, что есть у меня ))