Linux soft raid ssd

Linux: Ускоряем софтрейд и RAID6 в домашнем сервере

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

Почему RAID-6?

Почему софтрейд?

Железный рейд нужен только в одном случае – если у него есть батарейка и набортный кеш. Тогда контроллер сразу отвечает ОС что запись на диск завершена на физическом уровне и всякие ACID базы работают очень быстро и безопасно.
В остальных случаях никаких бонусов по сравнению с софт-рейдом нет, одни минусы:
1) Сгорело железо? Новый сервер? Будьте добры купить тот же контроллер, ну или молитесь о совместимости. Софтрейд из тех-же дисков собирается где угодно.
2) Цена 🙂 Собственно, из-за этого нормальных рейдов с батарейкой я в руках так ниразу и не держал 🙂

Ну а те «рейд-контроллеры» которые стоят на обычных материнских платах – вообще никогда не стоит использовать. Они просто дают грузить ОС с рейда за счет набортного биоса (который выполняется центральным процессором, своего процессора нет), на этом их польза заканчивается, и остаются только минусы.

О паре мифов софтрейда

1) Он жрет много драгоценного процессора
Если мы одним глазком глянем в исходники драйвера RAID в ядре Linux, то увидем, что там давно все оптимизированно под SSE2. А с SSE2 процессор может считать XOR от 16 байт за 1 такт на 1 ядре современного процессора и все упирается в скорость обмена с памятью. Можете прикинуть сколько % загрузки одного ядра сгенерирует поток в 1Гб/сек 🙂 А ядер то много 🙂 На практике, с моим Opteron 165 (1.8Ghz 2 ядра) скорость никогда не упиралась в CPU.
2) Он разваливается и потом хрен соберешь.
Если что-то и отваливается – то из-за железа (например обычные винты любят иногда делать всякие фоновые задачи). Добавление вывалившегося веника – простая операция, которая кроме того может проводится автоматически. Впрочем, в среднем это надо делать раз в год.
mdadm /dev/md0 -a /dev/sde1
3) У софтрейда хреновый мониторинг
С мониторингом все отлично и настраиваемо. Достаточно например просто мыло указать в конфиге mdadm и он пришлет вам письмо если что-то случиться с вашим массивом. Очень удобно )

Вот например что приходит если один веник отвалился:

This is an automatically generated mail message from mdadm running on XXXXX

A DegradedArray event had been detected on md device /dev/md0.

Faithfully yours, etc.

P.S. The /proc/mdstat file currently contains the following:

Personalities: [raid6] [raid5] [raid4]
md0: active raid6 sda1[1] sdc1[4] sdd1[3] sde1[2]
2929683456 blocks super 1.2 level 6, 1024k chunk, algorithm 2 [5/4] [_UUUU]

unused devices: none

Рекоменую протестировать перед использованием:
mdadm —monitor -1 -m myname@myisp.com /dev/md0 -t
4) У софтрейда очень низкая скорость перестройки массива
В дефолтной конфигурации – да. А если вы дочитаете до конца статьи – узнаете как сделать так, чтобы все перестраивалось со скоростью самого медленного веника 🙂

О роли bitmap

Linux-овый софтрейд поддерживает замечательную фичу: bitmap. Там отмечаются измененные блоки на диске, и если у вас почему-то отвалился один диск из массива, а потом вы его обратно добавили – полная перестройка массива не нужна. Чертовски полезно. Хранить можно на самом рейде – internal, а можно в отдельном файле – но тут есть ограничения (на тип ФС например). Я сделал internal bitmap. И зря. Internal bitmap тормозит безбожно т.к. постоянно дергается головка веников при записи.

Посмотрим на скорость:

time sh -c «dd if=/dev/zero of=ddfile bs=1M count=5000»
time sh -c «dd if=ddfile of=/dev/null bs=1M count=5000»

Результаты для моего RAID-6 из 5xWD 1Тб получились следующие: чтение 268МБ/сек, запись 37МБ/сек. Все разводят руками и говорят: ну а чего же вы хотели? RAID-6 тормозит при записи, ведь ему надо прочитать то что было записано раньше, чтобы посчитать обновленные контрольные суммы для всех дисков. А еще и этот bitmap…
Скорость перестройки массива – около 25МБ/сек – полная перестройка массива до 15 часов. Вот он, ваш ночной кошмар.

Решаются проблемы просто:

У драйвера рейда в Linux есть такой полезный параметр: stripe_cache_size
значение по умолчанию которого равно 256. Слишком низкое значение – резко снижает скорость записи (как оказалось). Оптимальное значение для многих – 8192. Это — кол-во блоков памяти на 1 диск. 1 блок это обычно 4kb (зависит от платформы), для 5-и дискового массива кеш займет 8192*4кб*5 = 160МБ.
echo 8192 > /sys/block/md0/md/stripe_cache_size

Действовать начинает моментально. Теперь в большинстве случаев драйверу не приходится читать диск перед записью (особенно при линейной записи), и производительность резко вырастает. После перезагрузки пропадает, чтобы не пропало — добавляем в какой-нибуть /etc/rc.local например.

Скорость перестройки массива теперь – 66МБ/сек (это сразу по всем дискам, около 5 часов на весь массив), скорость чтения осталась той-же, а вот скорость записи – выросла до 130МБ/сек (с 37).

Переносим bitmap на отдельный диск (в моём случае — системный). Если системный веник сдохнет — ничего страшного, массив восстановится и без bitmap-а.
Головка больше не дергается при записи лишний раз, и скорость записи вырастает до 165МБ/сек.
mdadm -G /dev/md0 -b /var/md0_intent

Итак, за 10 секунд мы подняли скорость записи с удручающих 37 МБ/сек до вполне приличных 165 МБ/сек (более чем в 4 раза!!). Теперь через Samba по сети файлы и пишутся и читаются 95-100 МБ/сек, и планировавшийся из-за низкой скорости рейда апгрейд сервера придется отложить на неопределенное время – производительности дохленького Opteron 165 теперь с лихвой хватает для всех поставленных задач 🙂
С новым годом 🙂

PS. Внимание! Под рутом ходить только на трезвую голову!
PS. В непростой схватке, первый пост на хабре в 2011 году опубликовал все-таки я
PS. infi

Источник

Самый актуальный гайд по установке Linux на SSD-накопители в 2021 году

Привет, Хабр! Долгие годы по сети гуляют байки о тайных умениях спецподготовки твердотельных накопителей к установке Linux-дистрибутивов. Пользователей-новичков это отпугивает — перейти на OpenSource типа Ubuntu. А давно не следящих за новинками железа — оттягивает прокачать скорость работы. В этом посте мы отбросим все мифы и неактуальные советы, прочно засевшие в топе поисковых запросов. А заодно подскажем ряд простых и эффективных советов по установке Linux на SSD-накопители. Поехали!

Недавно мы уже рассказывали о типичных ошибках использования твердотельных накопителей любителями лайфхаков и прочих улучшений. Тема ошибок при эксплуатации SSD вызвала неподдельный интерес в комментариях, где была затронута популярная байка о тонкостях и секретах настройки Linux при установке на SSD-накопители. Та самая, что активно обсуждалась в холиварах на форумах и породила множество подробных гайдов на просторах Хабра. Если вдруг кто не в курсе, можете загуглить “установку Linux на SSD”.

С большой долей вероятности, поисковая выдача отправит вас прямиком во времена доллара по 30 рублей и новейших процессоров Intel Core под Socket H2. Эх, ностальгия!

Тогда вопросы надежности и долговечности первых твердотельных дисков всерьез волновали сторонников Linux-систем. Особенно тех, кто не обращал внимание на журналирование файловых систем поколения Ext3. К примеру, важная для NAND-памяти процедура TRIM выполнялась по умолчанию лишь раз в неделю, нанося серьезный урон ячейкам в масштабах нескольких лет эксплуатации. Но главное, на что мы рекомендуем сейчас обращать внимание при чтении подобных гайдов и секретов: дата публикации. Ладно когда гайду 5-6 лет, но у большинства и вовсе скоро юбилей.

Насколько готовы современные дистрибутивы Linux к установке на SSD?

Не пытайтесь изобрести колесо. Современные дистрибутивы Linux хорошо оптимизированы под установку на твердотельные накопители и автоматически выставляют оптимальные параметры журналирования и ежедневного обновления TRIM, а также деликатно относятся к записи кэша на диск. Начиная с Ubuntu версии 14.04 твердотельные диски корректно определялись еще на этапе установки, оставляя пользователю лишь иллюзию выбора неправильной файловой системы вместо рекомендуемой Ext4. Все остальное вторично, а 99% проверяющих через консоль активность TRIM на SATA-дисках, неизменно обнаруживали корректные значения вместо нулей.

Повторимся — наш совет простой: прежде чем тратить время на чтение гайдов и лайфхаков по установке Linux-систем на SSD-диск, взгляните на дату публикации. На одном из Ubuntu-сообществ от некогда грандиозного Wiki-склада полезных команд остался лишь пяток абзацев, типа проверки активности утилиты TRIM. Все современные версии той же Ubuntu динамически отслеживают параметры работы дисковой подсистемы и по умолчанию стараются минимизировать число паразитных операций с кэшем вне оперативной памяти.

Как подготовить SSD-накопитель к установке Linux-системы?

На сегодняшний день можно смело урезать советы по подготовке твердотельного диска для Linux до советов по выбору подходящего носителя по типу и емкости. Вместо поиска альтернатив файловой системе Ext4 (стандарт де-факто) лучше потратить время на изучение отличий между NAND-чипами с QLC, TLC и другими видами компоновки ячеек. Подробнее о выборе накопителей по признаку QLC и их теоретических недостатках мы подробно рассказывали в этом посте. Если вкратце, SSD-накопители с QLC-ячейками дешевле, а TLC применяются во флагманских решениях, обеспечивая лучшую наработку на отказ и более высокую скорость передачи данных. Продукция Kingston построена на базе передовых 3D TLC и 3D NAND ячеек памяти, лишенных недостатков 4-битных QLC.

Но раскрыть потенциал памяти на ячейках 3D TLC и 3D NAND можно лишь с применением SSD-накопителей формата M.2, подключаемых напрямую к шине PCI-E x4. В линейке накопителей Kingston вы можете выбрать наиболее производительные M.2-накопители линейки KC2500 с предельной скоростью чтения/записи 3500/2500 МБ/с уже для моделей c емкостью от 500 ГБ. Ячейки выполнены по 96-слойной технологии 3D TLC, а производительность контроллера Silicon Motion 2262EN давно стала неким стандартом.

В сегменте M.2-накопителей с ячейками 3D NAND одним из самых популярных решений Kingston являются SSD из линейки A2000. Модели на 500 и 1000 ГБ демонстрируют скорость чтения/записи на отметке 2200/2000 МБ в секунду, а младшая — 2000/1100 МБ/с.

Если же планируете подключать диск по SATA, гнаться за скоростями выше 560 МБайт/с не имеет смысла — упретесь в лимит по шине. Выгоду следует искать в емкости доступного пространства. В линейках Kingston A400 и KC600 доступны твердотельные SATA-диски вместимостью до 2 ТБ. Отличия бюджетной линейки A400 от старшей кроется в использовании ячеек памяти TLC вместо 3D TLC, что напрямую влияет на цену и показатель наработки по числу записываемых байтов информации.

Рекомендовать младшие SATA-диски под систему можно с рядом оговорок, но под отдельные разделы системы и данные эти решения могут оказаться не сильно дороже компактного жесткого диска, превосходя по скорости даже RAID-массивы из винчестеров бытового сегмента.

Ориентироваться на разницу значений по наработке до отказа у твердотельных SATA-накопителей не столь важно. Как минимум, важнее заложить в бюджет обновления дискового массива качественное питание компьютера, начиная с блока питания и заканчивая сетевым фильтром и бесперебойником. Твердотельные накопители в целом довольно слаботочные решения по сравнению с жесткими дисками, и некачественное питание может свести к нулю всю выгоду от показателя в 1 миллион часов по MTBF.

О журналировании и бэкапе при выборе файловой системы

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

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

С резервным копированием в бытовых условиях лучшим выходом может оказаться сетевое хранилище, чье влияние на производительность операционной системы на твердотельном диске будет сведено к минимуму. С кэшем и минимизацией числа мелких обращений к ячейкам памяти, три четверти которых не превышают по размеру саму ячейку в 4 Кб, лучше всего бороться достаточным запасом свободной оперативной памяти. Современные дистрибутивы Ubuntu по умолчанию хорошо отлажены для использования оперативки под кэш, сводя выгрузку в виртуальную память до нескольких обращений за день.

Как настроить разделы и сколько оставить неразмеченной?

В вопросах эффективности разделения SSD-накопителей на массив логических разделов мы не рекомендуем пытаться искать связи с продлением срока службы носителя. Заложив изначально 25-30% хранилища свободными от данных, вы внесете максимальный вклад в срок безотказной и верной службы диска, а потому вольны свободно размечать до 4-х разделов в рамках Ext4. Другой вопрос, что современные высокоскоростные носители данных можно подключить как USB-C флешку и перекинуть туда некоторые разделы системы.

Создавать несколько логических разделов имеет смысл лишь для разнесения каталогов системы с различным характером применения. Например, системные и бинарные каталоги имеет смысл разделить от логов, как и резервные базы. А вот потребности /run лучше покрыть запасом по доступной оперативной памяти. Это наилучшим образом скажется на снижении IOPS на диск в течении длительного периода эксплуатации.

Как следует настраивать актуальные сборки на базе Linux под SSD?

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

Даже широко обсуждаемое включение ежедневного запуска TRIM уже несколько лет как потеряло свою актуальность. Данная процедура автоматически запускается всеми современными Linux-дистрибутивами. В этом абзаце речь идет о большей части советов, где упоминается Fstab, пользовательские наработки по которому давно стали базовой частью системы.

Выходит, что никаких отличий по настройке, при установке Linux системы на SSD и жесткий диск, нет вовсе. Можете смело доверить заботу о твердотельном накопителе системе, позаботившись запасом доступной оперативной памяти под нагрузкой. 32 ГБ гарантированно покроют этот вопрос у 99% пользователей, а проверить текущие значения потребления можно простой командой free.

Как измерить скорость работы SSD в Linux?

Если десять лет назад еще можно было встретить упоминания Phoronix test suite, на сегодняшний день стандартом бенчмарков в бытовых, рабочих и серверных машинах является утилита Fio. В умелых руках с ее помощью можно оперативно измерить окупаемость масштабирования СХД по стоимости IOPS, но в бытовых целях вас наверняка интересуют те же значения, что выдает на Windows утилита CrystalDiskMark, не так ли?

Ее аналог доступен на просторах Github под именем KDiskMark. У программы есть графический интерфейс, сводящий проверку скорости накопителей и любых дисков до пары кликов мышкой. За оболочкой скрывается вышеупомянутая Fio, итоговые значения которой наиболее точны в сравнении измерений диска на других ОС.

Вердикт: смело монтируйте Linux на SSD без заморочек

Более подробный анализ значений работы SSD-дисков требует более обстоятельного подхода и широко освещен Хабровчанами. Базовую информацию, разметку и проверку дисковых разделов можно выполнить с помощью утилиты Disks, предустановленной в Ubuntu и многих других Linux-дистрибутивах. А 99% всех рекомендаций и твиков давно утратили свою актуальность. Сегодня вы можете наслаждаться быстрой работой Linux-систем на твердотельных накопителях Kingston без дополнительных танцев с бубнами, просто выбрав установку по умолчанию.

Для получения дополнительной информации о продуктах Kingston Technology обращайтесь на официальный сайт компании.

Источник