Debian based SSD software RAID

[FreeLSD]

Вопрос, конечно, на границе софта и харда. Пусть здесь будет?

Планирую подъем сервака под СУБД. Выбранная ОС - Debian Jessie (во-первых, с дебианом больше прочего знаком, во-вторых, спецы под данную задачу рекомендуют именно его. Или бубунту :) ). Железо не тру сервачное, но добротное. Главный вопрос - дисковая подсистема. Сейчас это два SSD, которые хочется зарядить в "избыточный массив недорогих дисков", зеркало, разумеется. И только я собрался пускать это хозяйство в дело, как начитался всякого :unsure:

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

Про косяк последнего дебиана, не позволяющего запуститься с деградировавшим зеркалом и метод устранения - тоже прочитал.

Хочу спросить у гуру: что из вышеперечисленного правда, а что - домыслы? На что еще обратить внимание и есть ли какие best practices в этой области для ознакомления?

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

[Пэтро]

А почему SSD ?

[NnN]

Сталкивался с комбинированными накопителями в одном дисковом массиве только в 3PAR, но и там нагрузкой на дисковую подсистему занималась специально обученная "голова", вплоть до разделения таблиц баз данных - оперативные и частозапрашиваемые данные были на быстрых SSD, обычные на iSCSI, архивные на SAS. Всё это было в одном большом дисковом массиве и данные распределялись и перемещались по нужным "мощностям" автоматически.

 

Возможно ли корректно реализовать подобное на уровне софта под Дебианом - очень интересный вопрос. Подпишусь-ка на тему.

[FreeLSD]

А почему SSD ?

Скорость чтения.

[FreeLSD]

там нагрузкой на дисковую подсистему занималась специально обученная "голова", вплоть до разделения таблиц баз данных - оперативные и частозапрашиваемые данные были на быстрых SSD, обычные на iSCSI, архивные на SAS. Всё это было в одном большом дисковом массиве и данные распределялись и перемещались по нужным "мощностям" автоматически.

Это очень круто, из пушки по воробьям бить не вижу смысла :)

Для ясности, БД будет порядка единиц гигабайт, ну, может, до десятка дойдет. 50 - 100 пользователей (это с учетом перспективы).

При этом есть опыт использования Debian + 1C server + Postgresql с самописной конфой, сидело до десятка польззователей одновременно, и все это хозяйство крутилось пару лет на смешной коробочке с ... Intel Atom (Атом, Карл! :blink: ), 2G RAM ( ) с приемлемой производительностью. Так что речь идет не о тонкой настройке, а чтобы не допустить явных косяков.

[Andreios]

Я так и не понял.

Есть два ссд сейчас, но хочется добавить дешевых хдд до быстрого и избыточного? :)

Ну можно например btier какой-нибудь заюзать, для создания гибрида, на рейд10.

Типа 2 ссд в рейд1 + 4 хдд в рейд 10.

 

На ссд будут лежать горячие данные, для быстрого чтения, и запись туда же, после чего постепенно переезд в хдд.

Изменено 8 апреля, 2016 пользователем Andreios

[FreeLSD]

Нет, все проще :) Есть пустая машина с двумя ссд, хочется их зазеркалить и

не допустить явных косяков.

[Andreios]

FreeLSD, да тогда jbod + качественные бекапы.

[FreeLSD]

Andreios, не пойдёт - избыточность обязательна. Если в варианте с Атомом и десятком юзеров задержка в пару часов (с потерей одного дня работы в базе) на восстановление была допустима, то в данном случае - смерти подобна. Подумываю даже над организацией непрерывного резервирования с помощью репликации.

[a0xff]

если важна надёжность, то ssd декстоп класса- плохой выбор

кроме того у двух новых ssd в raid 1 будет одно забавное свойство- они умрут одновременно.

что-то вроде двух винтов и одного ssd для enhanceio в качестве кешера чтения- более правильный путь

[Пэтро]

Если база гиг то она почти вся в кеше

 

Больше памяти)

[FreeLSD]

Если база гиг то она почти вся в кеше

 

Больше памяти)

Именно, постгре любит кэшировать всё и вся. Памяти хватает :)

[FreeLSD]

a0xff, каким образом настраивается такая конструкция? Что про это можно почитать? Или ось/субд это сами способны решить?

[a0xff]

FreeLSD, примерно так:

https://habrahabr.ru/post/169845/

работает вполне стабильно. Если решишься ставить- можешь писать в личку- помогу поставить, хотя там относительно просто. Нужно только относительно свежее ядро(от 3.8, если правильно помню)

использовал как кеширование записи несколько лет.

Как кешер чтения будет для базы безопаснее.

Но в целом согласен с Петро- если объём небольшой- можно наращиванием памяти решить вопрос скорости- система сама будет держать данные в файловом кеше

[FreeLSD]

Из комментов к приведенной статье:

Штуки требующие реально много IOPS предпочитаю размещать на RAID1 из пары SSD + полные и инкрементные бекапы на другой машине.

Возможно просто инерционность мышления.

Вот и я склоняюсь к похожему решению.