Как по вашему мнению рациональнее собрать дисковую систему на сервере?
Всем доброго дня!
Смотрите, есть задача перенести некоторые WEB-ресурсы со старого сервера на более новый, но есть конструктивные ограничения.
Много-много лет назад, лет 10 так точно, когда устанавливали ОС на сервер под WEB-портал, собрали всё на весьма неплохом для того времени железе сервера HP, а вот когда собирали RAID, то отдали предпочтение RAID-5. Бог с ним, дело прошлое.
Сейчас нагрузка на WEB-портал сильно выросла, да и к тому же на сервак переехали 2 - 3 сайта с малой нагрузкой, но тем не менее это немного нагрузило сервер. А тут подарочек, освободился более новый и мощный сервер. )))
Решено организовать переезд WEB-сервисов на него. Но есть технологические ограничения в виде только 6 слотов под диски. В распоряжении имеем 6 SSD дисков SAMSUNG EVO. На сервере будет крутиться один из дистрибутивов Linux, какой - сейчас не важно. Основное - это то, что там будет Apache + Nginx, а так же СУБД MYSQL.
Сейчас спорим с коллегами на предмет того, какой RAID собрать и как собрать.
В процессе споров пришли пока к общему знаменателю такому:
- Собираем RAID 50 из 6 SSD дисков, что обеспечит отказоустойчивость и приемлемую производительность.
Среди предложений были ещё варианты:
1. Собрать 2 RAID массива:
- Первый: RAID1 для файловой составляющей (Система, Apache, Nginx)
- Второй: RAID10 для хранения БД.
2. Собрать 3 массива, все RAID1
Первый - ОС.
Второй - /var/www/
Третий - /var/lib/mysql
3.Собрать RAID 10 из 6 дисков.
Диски везде SSD.
А как бы собрали дисковую систему вы и почему?
P.S. Я понимаю, что возможно кто-то сейчас скажет, что надо знать больше, что "Какие цели?" и т.п..
Если коротко, то это WEB-сервер, на котором ещё крутится БД. Требуется сделать всё так, чтобы этот набор сервисов работал если не максимально быстро, то хотя бы не тормозил друг друга. И ясен пень, что железо - это только половина вопроса, важен ещё и код и т.д., и т.п.... Но сейчас мы говорим только про то, как организовать дисковую систему.
У вас на HPE все тоже на SSD крутилось?
RAID контроллер был без кеширования?
Samsung Evo у меня чет прям совсем не прокатили на серверах. Все что были установлены - все сдохли. Так что следить надо за счетчиками на них очень пристально.
Я бы внимательно еще раз посмотрел на RAID5. Потому что у R10 слишком малая утилизация. Для SAS|SATA HDD конечно R5 плохая идея в плане скорости работы, но SSD обычно хватает на веб. Тут нужно вашу нагрузку смотреть, сколько сейчас IOPS и на каких дисках, с каким временем отклика.
raid10 на 6 дисков, конечно, если место не поджимает. Быстро, удобно, нет извращений "ой, системный диск пустой и вообще по нулям i/o, вебовый забит под завязку, а диски под базой загружены в потолок".
raid5 под базой зрелище зело печальное в работе.
я старый разработчик-dba и просто не понимаю этого чисто админского прикола, зачем под ОС занимающую 5-10 гигабайт и дающую примерно 0 IOPS активности выделять отдельные физические диски. Но если нравится - делайте так, кто же запретит.
Dimonchik, так именно потому и один общий массив. С общим объёмом места и общим делением IOPS на все доступные 6 чтения и 3 на запись конкурентных потока.
Ведь если вы заведомо знаете свой workload - то этот вопрос вы бы просто не задавали. А собрали массивы так, как это нужно под задачу.
ну оно дискутабельно, мне кажется базу лучше отделить все же именно чтобы параллельные iops не влияли при поиске проблем, хотя на объемах, конечно. арзитетура другая - отдающие морды и базы на разных будут и т.п.
Melkij, Восстановление данных и восстановление ОС - немного разные вещи. Зачастую крайне удобно иметь возможность быстро восстановить ОС любыми способами. включая просто установку на отдельный винт вне рейда. А потом уже ковырять рейд чтобы восстанавливать данные.
Опять же бывает много разных вариантов из чего сделана файловая система, и если она поломана до уровня, что нельзя загрузить саму ОС, рекавери сильно замедляется.
Saboteur, не, не понимаю весь драматизм. Ни hot standby, ни бекапов нет, зато позаботились как бы так поудобнее восстановить ОС? А не лучше ли было бы позаботиться о данных? Когда файловая система в состоянии невозможно загрузить ОС, то и от самих данных с большой вероятностью лишь бинарный мусор остался. В нормальной ситуации: разобрали сервер, продиагностировали, заменили то что вызывает сомнения, собрали, поставили чистую ОС, накатили ansible, налили реплику hot standby, всё.
Melkij, две причины:
1. если будет тормозить рутовая фс, то будет лагать весь хост. вынос рутовой фс на отдельный том/диск решает этот риск. ведь помимо стораджей под данные есть еще виртфс, которые тоже зависят от состояния рутовой фс.
2. с точки зрения оптимизации производительности полезно разнести на разные тома, логи ведь пишутся как правило на системный том
Melkij,
"поставили чистую ОС, накатили ansible, налили реплику hot standby, всё."
- идеальный расклад.
вопрос: сколько времени будет занимать такое восстановление работоспособности системы в случае небольшого отказа?
Melkij, к сожалению, все запросы к такому большому массиву будут собираться в одну очередь к одной фс (сериализация всех запросов) и это приведет к лагам всей системы как только будет выбрана вся производительность диска. выгоднее разделить нагрузку на разные диски.
Всегда, если есть возможность сделать два меньших массива вместо одного большого - делай два массива.
тип - под ситуацию и деньги, raid1 и 0 имеют наименьшие накладные расходы на процессор но кушают доступное место на диске
raid5 из трех дисков вполне возможен, так как используете десктопные ssd-шники, значит за скоростями не гонитесь и вам хватит софтварного mdadm (настоятельно рекомендую его а не встроенные в zfs и btrfs), поэтому 2 x raid5 по 3 диска - ваш выбор.
p.s. настрой мониторинг бакапы! а при наличии второй машины, master-slave репликацию для базы, как один из инструментов онлайн резервирования (это так приятно запустить базу данных после сбоя в то же мгновение как умрет главный сервер).
я бы сделал зеркало для системы
и там уже 5-й рейд для всего остального.
Или просто зеркало для всего - более чем достаточно, при наличии регулярных бэкапов.
мутить более сложные рейды - обычно нужно только если совсем не хватает денег.
