Комментарии 64
У нас аналогичный контроллер в 2U Supermicro. И время от времени происходит задержка доступа к базе данных PostgreSQL, расположенной на рейд массиве из SSD носителей.
Нет, тут просто полное пропадание контроллера в системе. Кроме того, здесь у клиента 2 RAID-1 на серверных SSD, там тормозить просто не чему.
Вероятно, у вас может быть проблема связанная с тем, что SSD не серверные. Я бы попробовал смоделировать с помощью fio профиль нагрузки в период тормозов, собрав данные с помощью sar.
Если у вас R5, R6, то тормоза вероятны при интенсивной записи даже на SSD. С учетом того, что транзакции вашей БД должна хорошо работать (а это Queue Depth 1), самое вероятное — просто высокая задержка из-за RAID5/6, если он без батарейки.
Для postgresql мы строили mdadm по рекомендации знакомых разработчиков postgresql. По сравнению с 9280 получили ощутимый прирост
Правда у нас raid10
Мы поигралисЬ с планировщиками, аля kyber, blk-mq но у нас 70% записи, что сказывается на выборе, сейчас все больше на кликхаус ушли
Фс xfs, кластера зависят от кол-ва дисков, как понял их должно быть кратно 4м помноженым на 2 с учетом raid10
Нобарьер, ноатайм, отключение ht и всяких энергосбережений, также выбор ssd с низкой задержкой, у нас бюджет был 700-800т.р за 4тб, 512gb
Чем больше канальность памяти и часстота тем лучше
Бекплейн только с 4 дисками на провод, а не один провод на все
Полконфига затюнили
У нас дба в штате нет, только по знакомству поспрашивали, да послушали конференции на английском от разрабов)))
Строго новые версии нужны, с каждой версией все больше паралелизма операций, но тот же старт и рекавери гад все равно в один поток херачит… а частота при многоядерности дорогое удавольствие
Ps ошибки, пишу с телефона
Об этой проблеме SSD дисков, задержки при записи, постоянно говорит amarao и я так же наблюдаю подобные проблемы.
Массивов из ССД достаточное количество есть в эксплуатации и для себя вывел такую рекомендацию «массив предназначен для важной записи (WAL, REDO, BIN-log и т.п.) — только RAID 1 или RAID 10».
Ну и лучше из SATA SSD что я видел — это серия Intel DC S37xx, очень редко подобные провалы там наблюдал. Но их уже нет новых в продаже…
Воздушный поток от основных вентиляторов просто не доходит в необходимом объёме до радиатора RAID-контроллера, эффективности которого далеко до процессорного, а в отсутствии датчиков и встроенных механизмов троттлинга это нехорошо.
Не надёжнее ли установить отдельный слабенький вентилятор на самом радиаторе, чем рассчитывать на нестабильные крохи потока с процессорного? Конечно, неконтролируемый вентилятор может сам стать источником потенциальной проблемы (встречал чипы, сгоревшие от перегрева их заклинившими вентиляторами), но можно либо подключать дополнительный вентилятор с таходатчиком к свободному разъёму на материнской плате (если удастся биосу объяснить его назначение), либо ставить качественные вентиляторы без датчика, как вариант — с сигнализацией о заклинивании, такая опция есть для большинства моделей.
Можно попробовать погонять типовой корпус на стенде, со стеклом вместо верхней крышки.
Не могу сказать порядок цен, но что-то мне кажется крышка для сервера подходящего размера из германия(чтобы тепловизором смотреть через него можно было) будет стоить как крыло от боинга.
Сильно зависит от расположения компонентов в сервере, но нередко проблему можно решить без дополнительных кулеров, просто "отгибая" в нужную сторону часть воздушного потока от кулеров при помощи банального кусочка листового пластика. Как правило дури то в штатных вентиляторах более чем достаточно, просто воздух идёт не совсем туда, куда нужно бы.
Ну и да, всякие контроллеры в 1U серверах частенько страдают по причине того, что расположены там же, где и всяческие колодки интерфейсные, порты для накопителей и прочие источники повышенной плотности проводов. А собирающие сервер сотрудники не сильно задумываются о правильной укладке всех этих шнурков, в итоге перекрывая дорогу воздушным потокам.
Установить вокруг бедного контроллера с так себе радиатором кучу портов, в которых, вероятнее всего, будут торчать шлейфы, даже если не все порты реально используются. И всё это на задворках корпуса, в уголке, куда воздушный поток и так практически не добирается.
Понятно, что скорее всего будет использоваться не набортный, а дополнительный RAID-контроллер, но такой подход к компоновке и охлаждению непонятен.
Я понимаю, что правила здесь применяют только по прихоти, но все же превращать торт в твиттер не стоит?
Что автор «поста» не проверил температуру утилитой для управления собственным RAID-ом, и не убедился, что в сервере хватает вентиляторов для продува всего объема — на его совести. Что кто-то (сборщик) оказался в этом виноват — да, наверное, есть и такой момент, но тут уж «покупайте у брендов», будет дороже, но продуманнее.
Каких открытий нам еще ждать — «я ничего не проверял в своём автомобиле (его же делали умные люди, и продавали за приличные деньги), а оказалось, что масло нужно было менять раз в год или после некоторого пробега, уровень охлаждайки следовало контролировать глазами, а тормозную жидкость тоже требуется менять, хотя я даже не знал, где она залита»?
P.S. «Никто не читает правила», и за их соблюдением особо не следят, часто оставляя на самотек — но каждый харбовчанин соглашался следовать правилам.
P.P.S. Я в курсе, что Supermicro — вполне себе бренд. Сам использую, и контролирую показатели датчиков — не потому, что SM, а потому, что «хочешь сделать хорошо — сделай сам», и мне же будет спокойнее.
Что автор «поста» не проверил температуру утилитой для управления собственным RAID-ом, и не убедился, что в сервере хватает вентиляторов для продува всего объема — на его совести. Что кто-то (сборщик) оказался в этом виноват — да, наверное, есть и такой момент, но тут уж «покупайте у брендов», будет дороже, но продуманнее.
Воздуха хватает, но не в умолчательном режиме при незагрузке CPU в ЦОД-е с очень холодным коридором. Конечно, на столе инженер, который сервер собирал все протестировал.
1) Температура RAID контроллера прекрасно мониторится различными инструментами (storcli, msm). Можно настроить оповещение, чтобы опередить такое неприятное событие.
2) Что мешало сборщику установить шесть вентиляторов? Цена вопроса — копейки.
3) Вполне вероятно, что в ipmi есть профиль Heavy IO. Смысл его понятен из названия профиля.
4) Зачем вам 9361-8i в корпусе, рассчитанном на 4 диска? :)
4) Используем подобные платформы 1U Supermicro c «дедушкой» 9271-4i. Он тоже горячий. Подключены как HDD так и SSD. Условия в дата-центре примерно как у вас. Проблем нет. Mdam-у не доверяем :)
Спасибо!
2. На маме только 5 штатных гнезд. Погоды не делает на самом деле.
3. Есть — не включили, об этом выше писал.
4. Воля клиента — такую карту захотел, не захотел 9265-8i
5. Ну у нас тоже в первый раз — в работе серверов более 10 таких с RAID. Сейчас на всех поменяли профиль вентиляторов.
www.supermicro.com/CDS_Image/uploads/imagecache/600px_wide/intel_motherboard_active/x11scm-f_front_0.jpg
Правый верхний угол.
4) Правильно сделал :)
5) Вообще, можно смело включать профиль Full Speed. В таком режиме вентиляторы гарантированно отработают весь срок жизни сервера. Минус этого — шум. Хотя, кого он волнует в дата-центре? :) Плюсы очевидны, в том числе и для Turbo Boost-a CPU.
store.supermicro.com/supermicro-23cm-4-pin-to-4-pin-fan-extension-cord-cbl-0296l.html
А mdadm не доверяете по обоснованным причинам или у вас "так исторически сложилось"?
Я, честно говоря, с трудом представляю ситуации, в которых под линуксом аппаратный рейд будет предпочтительнее софтового.
Я, честно говоря, с трудом представляю ситуации, в которых под линуксом аппаратный рейд будет предпочтительнее софтового.
если синхронная запись (write+fsync) должна быть быстрой при медленных носителях.
dc ssd, правда, снимают остроту проблемы, но, почему-то, их не всегда используют )
ну и если у нас повышенные требования к надёжности — вероятность, что после отказа диска сервер не загрузится, куда ниже в случае использования аппаратного raid.
Про надежность. Есть какие-то убедительные факты на этот счет?
первое что приходит в голову: может потребоваться изменить boot order в bios.
если мы говорим не про uefi, то модули grub (включая поддержку raid) могут быть загружены только на 4th stage:
https://en.wikipedia.org/wiki/GNU_GRUB#Startup_on_systems_using_BIOS_firmware
любая ошибка до этого момента скорее всего приведёт к невозможности загрузки.
Если у вас медленные устройства, то они медленные и всё тут. Синхронная запись через контроллер у вас будет "быстрая" ровно до тех пор пока есть место в кэше. А оно есть ровно до тех пор, пока вы не пишете в среднем быстрее, чем успевают всасывать накопители. Да, в теории возможен реордеринг записи с целью оптимизации io операций, но это даёт ощутимый эффект только в редких специфичных кейсах.
Ну и по поводу grub и модулей, из другого ответа в ветке:
- На любом, по-моему, не-UEFI железе можно (и нужно) указать порядок и ограничить список накопителей, с которых нужно пытаться запуститься.
- Пихать /boot на raid не 1 — достаточно странно. Если у вас много дисков и хочется запускаться с любого — никто не мешает сделать по разделу хоть на каждом диске и собрать этот raid-1 хоть из дюжины-двух "устройств" разом. Да, будет write amplification, но вы же практически ничего туда всё равно писать не будете.
- Если совсем гложут сомнения в том, что grub сможет /boot на raid-1 увидеть — metadata 1.0 в помощь: служебная информация будет писаться в конец входящих в raid разделов, grub будет видеть любой из таких разделов как обычный, не-raid. А система после запуска спокойно соберёт нужное в зеркало.
- Ну, и при ситуации, что кто-то забыл в mbr воткнуть grub при замене диска проблем тоже достаточно мало — просто запустится со следующего по списку.
В общем, проблема с запуском мне видится весьма надуманной. А вот с надёжностью у mdadm всё даже немного лучше — он, в отличие от аппаратного решения, не перегреется, не может умереть, требуя длительной по времени замены, и пачка накопителей может быть без проблем перекинута и запущена вообще на любом железе, лишь бы портов на нём хватило.
Если у вас медленные устройства, то они медленные и всё тут. Синхронная запись через контроллер у вас будет "быстрая" ровно до тех пор пока есть место в кэше. А оно есть ровно до тех пор, пока вы не пишете в среднем быстрее, чем успевают всасывать накопители. Да, в теории возможен реордеринг записи с целью оптимизации io операций, но это даёт ощутимый эффект только в редких специфичных кейсах.
прямо так специфичных? любая БД с журналом.
запись в журнал БД на hdd по времени равна сику (головки уже ушли с дорожки, да если даже и не ушли — нужно дождаться в среднем полоборота).
запись через wb кэш считай бесплатная — она же линейная и объёмы записи относительно небольшие.
Если совсем гложут сомнения в том, что grub сможет /boot на raid-1 увидеть — metadata 1.0 в помощь: служебная информация будет писаться в конец входящих в raid разделов, grub будет видеть любой из таких разделов как обычный, не-raid.
вот у нас есть диск, с которого bios решил загрузить систему. и на этом диске bad sector как раз на /boot пришёлся.
bios считал бутлоадер с mbr, тот начинает процедуру загрузки самого grub, а диск не читается. и grub пока ещё не умеет raid 1.
А вот с надёжностью у mdadm всё даже немного лучше — он, в отличие от аппаратного решения, не перегреется, не может умереть, требуя длительной по времени замены, и пачка накопителей может быть без проблем перекинута и запущена вообще на любом железе, лишь бы портов на нём хватило.
да кто же спорит. речь про то, что неправильно говорить о том, что mdadm лучше во всём.
прямо так специфичных? любая БД с журналом.
Вы знаете, в нынешнее время, имея требования по производительности базы данных, в частности по latency синхронной записи, достаточно странно не поставить под неё SSD, ну или хотя бы какие-нибудь intel optane отдельно под wal. Кэш контроллера это хорошо, конечно, но появляется необходимость как минимум за батарейкой следить, а то можно и удивиться неприятно.
вот у нас есть диск, с которого bios решил загрузить систему. и на этом диске bad sector как раз на /boot пришёлся
Ну давайте честно, при периодических проверках дисков вероятность отхватить внезапный badblock ну прямо очень мала, я ни разу лично не видел такого. Даже не слышал "из первых рук".
Ну и если уж отхватили, то цепляемся по ipmi, смотрим, отключаем диск, грузимся — едем менять. Фикс проблемы удалённый, диск ехать менять однофигственно, софтовый у вас массив или не софтовый.
Моё личное мнение заключается в том, что аппаратные рейды под линуксом изжили себя после появления ipmi и нормальных ssd, превратившись в лишнюю точку аппаратного отказа.
Как правило в megaraid есть бипер, при перегрев он начинает пищать.
Нужен в первую очередь нормальный мониторинг.
У нас была похожая проблема, только грелся не контроллер, а диски. Сервер стоял временно без нагрузки, но RAID контроллер еженедельную проверку массива выполнял. Плюс, под сервером стоит довольно горячая железка, которая подогревает этот сервер снизу. В итоге, вентиляторы регулируются в зависимости от температуры, нагрузки на который нет, а диски шуруют в полную силу.
Система мониторинга среагировала на чрезмерный нагрев дисков и мы переключили режим работы вентиляторов на более сильный. Никаких отказов не возникло.
Проблема не решена, произведен лишь магический стук в бубен.
Настоящее решение: найти на материнки i2c пины, прилепить пару термодатчико в ответственных местах, поднять мониторинг, посмотреть что действительно происходит
Мне всё ещё больше нравится решение в виде установки небольшого качественного вентилятора прямо на радиатор RAID-контроллера. Хорошо, если удастся пробросить каким-либо образом датчик вентилятора для возможности мониторить его частоту вращения, если нет — лучше позаботиться о том, чтобы вентилятор был со звуковой сигнализацией во избежание потенциальных проблем. Регулировкой частоты вращения можно пренебречь, достаточно 4 см вентилятора на фиксированных низких оборотах.
Для диагностики датчик температуры на плате есть, виден через MEGARAID StorageManager и наверняка, по SNMP.
На днях в очередной раз отвалился радиатор на LSI NMR 8100-4i из-за рассыпавшиегося крепления. Но там похоже виновата конструкция контроллера, где встроенный SSD перекрывает поток от вентиляторов и пластик разрушается за пару лет.
Короткая заметка по инциденту с перегревом RAID-контроллера LSI в сервере в холодном ЦОДе