MegaRaid 92x/93xx оптимальный размер drive group

[ramirez]

Добрый день.

Есть-ли какие-то рекомендации по планированию drive groups на контроллерах megaraid 92xx/93xx?
В доках LSI я встречал только фразы типа "12 дисков и больше для максимальной производительности"
Сейчас у меня собрана группа RAID6 из 32 SATA дисков по 4TB. Плюс два hot spare. И отдельным томом отдана Windows Server 2016. Итого 108TB непрерывным куском. Красота. Но беспокоит пара вопросов:

Насколько это целесообразно с точки зрения производительности контроллера/времени ребилда?
С точки зрения винды, возможны ли проблемы с VSS на таком томе или деградация производительности ntfs?

Спасибо!

[Umlyaut]

Добрый день.

Есть-ли какие-то рекомендации по планированию drive groups на контроллерах megaraid 92xx/93xx?
В доках LSI я встречал только фразы типа "12 дисков и больше для максимальной производительности"

Полагаю, шпиндели (hdd) можно множить, пока не упрёмся либо в лимиты по их к-ву у контроллера, либо в наличные места (корзины, экспандеры, "вот это вот всё(тм)").
Не говоря о 12Gb-ном семействе 93хх, дури и у нынешних 92хх (нынешних - в смысле на двуядерных ROC 2208 (9265, 9270, etc.) в отличие от ранешних одноядерных 9260/61) хватит прокачать несколько десятков даже и 15k SAS.
Понятно, что при набивании рейд-групп ssd-хами Великий Насыщуха придёт к контроллеру сильно раньше, хотя в этом случае умножение числа ssd будет работать не на "бесконечное" ускорение I/O, а на увеличение размеров LUN`а (из-за меньших размеров ssd по ср-ю с hdd). Тут, безусловно, 93хх заруливают 92хх-ых.

Сейчас у меня собрана группа RAID6 из 32 SATA дисков по 4TB. Плюс два hot spare. И отдельным томом отдана Windows Server 2016. Итого 108TB непрерывным куском. Красота. Но беспокоит пара вопросов:

Насколько это целесообразно с точки зрения производительности контроллера/времени ребилда?

Я уже не раз отмечал, что на современных контроллерах, не страдающих нехваткой бортовой процессорной мощности для работы с КС (одной или двумя), время ребилда есть функция двух пар-ров - собственно скорости записи на одиночный диск (да-да, тот самый, на который мы ребилдим) и режима работы массива - при интенсивном I/O время ребилда увеличивается в разы.

Причём смещение баланса (%) между I/O и ребилдом в настройках контроллера ситуацию радикально не исправляет: ребилд в "окне" (ночь, выходные) происходит за расчётное время (объём диска
/ ~скорость записи на диск), а вот в течении рабочего дня даже с балансом в 95% в пользу ребилда таковой идёт в два-три раза медленнее (правда, при балансе от 50% и меньше эти "два-три" легко превращаются в "пять-шесть").
Собственно, ровно поэтому я давным давно забросил мысль строить рейд-группы R5, а с некоторых пор и R10 - как только смог позволить себе многошпиндельные конфигурации (чтобы превозмочь WP=6 ), так сразу и перелез на R6/60.

Понятно, что с ssd ситуация полегше, особенно если не жадничать и оставлять приличные "хвосты" неразмеченными (я оставляю до 25% объёма ssd) - тогда при ребилде падение скорости записи на Hot Spare ssd не такое драматичное (и вот тут уже можно даже пороскошествовать в плане скорости группы, скроив её в R10 )

Всё вышесказанное не теоретизирование, а голимая практика (личная).

С точки зрения винды, возможны ли проблемы с VSS на таком томе или деградация производительности ntfs?
!

Чегой-то?
Не вижу связи - и VSS, и ntfs работают сильно выше уровнем и их работоспособность никак не завязана на скорость нижележащей дисковой системы.
Какого рода "проблем VSS" и "деградации ntfs" Вы опасаетесь - можете обрисовать детальнее?

[Stranger03]

Насколько это целесообразно с точки зрения производительности контроллера/времени ребилда?

С Р6 при вылете одного диска на время ребилда просадки быть не должно.

[Umlyaut]

Насколько это целесообразно с точки зрения производительности контроллера/времени ребилда?

С Р6 при вылете одного диска на время ребилда просадки быть не должно.

Если "просадка" - это про производительность, то зависит от баланса ребилда в настройках контроллера.
Хотя оцениваю просадку производительности обычного ежедневного I/O при своём любимом 90-95% балансе в пользу ребилда как умеренную (видимо, многоуровневое кеширование даёт вздохнуть ) - время ребилда "просаживается" значительнее всё же.

[Stranger03]

время ребилда "просаживается" значительнее всё же.

Время понятно, при таком массиве даже без нагрузки это может затянутся ой как надолго, . У меня на 6-ти дисках САТА по 6ТБ в Р5 без нагрузки время ребилда около 3-х часов,

[ramirez]

Ребилд без нагрузки занимает чуть меньше суток ( Есть мысль все таки разбить пополам: создать две drive group по 18 дисков. ребилд должен быть быстрее.
Касательно VSS: по моим наблюдениям он чувствителен к логическим ошибкам в ntfs, а прочекать такой том думаю будет довольно сложно за адекватное время.
Размер кластера ntfs на таком томе будет максимальным, что не всегда желательно.
плюс, большой том -> много файлов -> большая mft, склонная к фрагментации.

[Stranger03]

ramirez
Есть куда такое огромное кол-во данных сбекапить? Значит вы счастливчик,

[Umlyaut]

время ребилда "просаживается" значительнее всё же.

Время понятно, при таком массиве даже без нагрузки это может затянутся ой как надолго, . У меня на 6-ти дисках САТА по 6ТБ в Р5 без нагрузки время ребилда около 3-х часов,

Что-то уж как-то больно быстро ребилдится, уж не сочтите за недоверие.

Это что ж, в течение 3-х часов (т.е. в сустейнед мод) Ваш Hot Spare SATA-диск (7k2rpm?) в 6ТБ полностью заполняется со скоростью записи в ~500MByte/sec.??? Да ну нафиг!

Вот ща глянул старые логи подсобной (умеренно нагруженной) хранилки: у меня ночной (то есть с минимальным I/O) ребилд 1TB SATA 7k2 (Констеллейшн) в R6 на стареньком 3WARE 9650SE шёл 2ч10мин - т.е. ~128MB/s (это меньше номинально-формальных 175MB/s для sustained по паспорту, но тут уж старичок-3ware может просто тормозить на двух КС).

Что интересно: ровно на той же хранилке, но после замены однотерабайтников на двух- (тоже Констеллейшены), ребилд, начавшийся в час дня с минутами (т.е. под обычной рабочей нагрузкой по I/O, с балансом 5/5 - Fastest Rebuild) шёл 7ч20мин - т.е. со средней скоростью ~75MB/s.

Даже если у Вас новейший 12Gbit-ный контроллер, то это всего-навсего не даст ему тормозить на КС (в Вашем случае - одной), так что упереться мы должны именно в сустейнед на харде - а я плохо представляю себе хард, льющий на себя три часа со скоростью в пол-гигабайта в секунду.
Что-то тут не так (может, Вы просто время ребилда "на глазок" припомнили, или с размером харда запамятовали? )

Без обид, ОК - просто понять хочу.

[ramirez]

у меня вообще печально получается: диск 3.7TB за 20 часов = 50-55MB/s....
Диски 7K HGST HUS726040, контроллер 9361-4i.

в качестве бекапа - еще один такой ящик на 108TB XD

[Umlyaut]

Ребилд без нагрузки занимает чуть меньше суток

у меня вообще печально получается: диск 3.7TB за 20 часов = 50-55MB/s....
Диски 7K HGST HUS726040, контроллер 9361-4i.

Соболезную...
Перед сном как-то с идеями сложно - по заветам Скарлетт О`Хара "я подумаю об этом завтра(с)".

( Есть мысль все таки разбить пополам: создать две drive group по 18 дисков. ребилд должен быть быстрее.

Чисто теоретически.

Что происходит при ребилде?

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

Соответственно, скорость записи стрипа на HSD ограничивается двумя основными пар-рами - как быстро может писать одиночный диск (HSD) и как быстро контроллер способен подавать ему данные для записи.
Второе, в свою очередь, зависит от скорости вычисления недостающего стрипа и от скорости, с которой данные подаются с дисков на "вычислитель" (RoC).

Современные RoC давно уже не являются bottleneck в плане вычисления КС (что в R5, что в R6), отсюда следует, что по-настоящему в этом месте нас может затормозить с ребилдом лишь интенсивное шевеление головками дисками при большом I/O. Но поскольку головы всей рейд-группы гуляют по одним и тем же цилиндрам синхронно, то I/O будет мешать позиционированию головок на считывание ребилдящегося в настоящий момент набора стрипов абсолютно одинаково для любого кол-ва хардов в рейд-группе.
Типа так: для ребилда очередного стрипа нам надо прочитать, скажем, условные 10-11-й цилиндры одновременно с N дисков - и тут бац! запрос на I/O вынуждает нас дёрнуть головами на 20-21-й (и тоже на всех N дисках). При таком раскладе даже если дисков будет N/2, то на скорости работы механики каждого отдельного диска это никак не скажется.

Конечно, если Вы сделаете две независимые рейд-группы - 2 х R6 - и у них будет разное наполнение (на одной медленные "хомяки" (home directories), а на другой БД (SQL или mail server), то тогда первая группа будет ребилдиться быстрее второй (когда обе под нагрузкой). Но тем самым - уменьшением числа шпинделей - Вы буквально "ограбите" "быстрые" (по требованиям к I/O) приложения (заметьте - не выиграв в скорости ребилда "быстрой" рейд-группы).

Казалось бы, можно сделать две "независимые" рейд-группы R6, объединив их в страйп R0 - т.е. соорудить R60: тогда мы, типа, поимеем скорость всех шпинделей.
Угу, вот только скорость ребилда по-прежнему будет функцией нагрузки по I/O, а не кол-ва дисков в сабъюните (см.парой абзацев выше).
Т.е. R60 имеет смысл только с т.з. повышения "статистической" надёжности (уповаем, что вылет третьего диска до ребилда по крайней мере одного из двух вылетевших ранее может прийтись на другой сабъюнит (R6) 60-го),но никак не для сокращения времени ребилда.

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

Касательно VSS: по моим наблюдениям он чувствителен к логическим ошибкам в ntfs, а прочекать такой том думаю будет довольно сложно за адекватное время.

Если Вы под "прочекать" имеете в виду стандартный СС контроллера, то мой опыт показывает, что том R6 в 14,5ТБ на уже упоминавшемся мною старичке-3ware и SATA-хардах 7k2rpm чекается контроллером за 10-11 часов. Не знаю, можно ли линейно экстраполировать временнЫе потребности на Ваш 108ТБ-шный массив, бо контроллер у Вас пошустрее всё же будет и по идее должен укладываться в стандартный уикенд. Жаль я не храню логи своих LSI`ев (мониторинг идёт через CLI с грепаньем и реакцией на ай-яй-яй в отцеженном), а то глянул бы разницу.

Был у меня не так давно кейз с СС: там вначале контроллер после CC ругался на один диск, мол, SMART threshold exceeded, а потом после следующих СС полезли сообщения, мол "Sector repair completed" на этом же драйве. Никаких проблем с базирующимися на данном LUN`е VMFS-разделами, набитыми vmdk-шными дисками с самыми разными ФС внутри (виртуалки виндовые, линуховые) не было вплоть до замены "дезертира" на HSD (директивной - просто "вынес" негодяя из рейд-руппы нафиг, не дожидаясь ).

Кстати, "логические ошибки ntfs" ею прекрасно купируются в силу самого её устройства (две MFT).
Не говорю уж о внутреннем reallocate бэд-блоков силами самого винта.

Плюс на современных контроллерах - у LSI начиная с двуядерных RoC 2208 (9265,66,70,etc.) - для SAS-дисков доступна функция PI (по стандарту T10 DIF - избыточность на уровне физического сектора), когда диски предформатируются не под, например, 512b, а под 520 или 528 (4096 vs. 4112), после чего включенный на контроллере функционал PI обеспечивает верификацию при записи каждого записанного физ.сектора - а это ещё одна "линия обороны".

В общем, я б на Вашем месте сильно бы не напрягался, а то голова разболится.

Размер кластера ntfs на таком томе будет максимальным, что не всегда желательно.
плюс, большой том -> много файлов -> большая mft, склонная к фрагментации.

Этот момент вообще к специфике раздела имеет опосредованное отношение - могу лишь сказать, что если Вас это анноит, то дробите LUN`ы и всё такое, выкручивайтесь, короче.

Ещё раз извините за возможные трюизмы,если что.

[Stranger03]

Что-то уж как-то больно быстро ребилдится, уж не сочтите за недоверие.

Ну может и бОльше, давненько там не вылетали диски, уже не помню. Но то, что долго, факт,

[Umlyaut]

у меня вообще печально получается: диск 3.7TB за 20 часов = 50-55MB/s....
Диски 7K HGST HUS726040, контроллер 9361-4i.

Соболезную...
Перед сном как-то с идеями сложно - по заветам Скарлетт О`Хара "я подумаю об этом завтра(с)".

Ну вот оно и наступило - "завтра".

На свежую голову надумалось вот что:

Ваши 50-55MB/s при 20-часовом ребилде 4TB-шника - это примерно треть от его, диска, паспортной скорости записи. А я так припоминаю, что у LSI-контроллеров всю дорогу изначально, по дефолту "искаропки" (и что важнее - мало кем изменяется при сооружении рейд-группы и её настройке!), баланс на ребилд стоИт "70 I/O - 30 rebuild". Что совершенно неприлично коррелирует с Вашим случаем.

Т.е. в таком разе ребилд, типа, производится в 1/3 часть "мощности" контроллера даже без нагрузки - что даёт пищу для интересных размышлений на тему "подкапотного" устройства всей этой хурмы.

Такое могло бы быть в том случае, если этот rate жёстко забит в алгорим: типа, не некий плавающий "диспетчер/вочдог", распределяющий загрузку RoC между I/O и ребилдом в заданном соотношении (в смысле - при рабочей нагрузке обязан выделять на ребилд не менее заданного threshold, но при отсутствии I/O может дать на ребилд и больше), а тупой "тикер-кликер", выделяющий каждый третий (в дефолтном случае) "тик" бортового процессора на ребилд - причём вне зависимости, заняты ли два других "тика" нагрузкой по I/O, или в её, нагрузки, отсутствие, "молотят" вхолостую.

Тогда всё бьётся - даже в отсутствие у Вас нагрузки на дисковую при дефолтном балансе в 1/3 на ребилд таковой будет совершаться примерно втрое медленнее, как если б у Вас было 95% в пользу ребилда.

Попробуйте поменять рейт - например, на 66% для ребилда - и посмотрите, за сколько без нагрузки отребилдится Ваш том (вангую, если я правильно догадываюсь, в районе 10 часов против 20 исходных; ну а при 90-95% в пользу ребилда должно бы быть часов 6-7).