Организация дисковой системы для веб-сервера
На данный момент имеется веб-сервер (nginx+apache+mysql+php) с трафиком где-то 200.000 запросов в сутки (с учётом статики: 4.000.000 запросов в сутки)... Планируем купить выделенный сервер, поэтому возник вопрос по тому, как его правильно настроить (в плане высокой производительности и высокой отказоустойчивости/безопасности). Основное ограничение (пока не уверен на 100% что оно нужно, но скорее всего в целях экономии нужно) - уместить сервер в 1 юнит.
И пока очень неоднозначным выглядит вопрос, какую дисковую систему выбрать и как её организовать, чтобы обеспечить максимальную производительность и отказоустойчивость при не очень высоких ценах (т. е. SSD скорее всего не рассматриваем). Под дисковой системой понимается контроллер + жесткие диски + backup-сервер.
Если есть кто-то опытный, подскажите по конфигурации - как правильнее настроить?
Пока что присмотрел такую конфигурацию:
1. Контроллер Intel RAID RS2BL040
2. Пара основных жестких дисков HDD 300 Gb SAS Seagate Cheetah 15K.6
3. Пара дополнительных жестких дисков HDD 1 Tb SATA-II 300 Seagate Constellation ES
4. В качестве backup-сервера - рабочая станция.
И пока что мне кажется, что настроить лучше всего таким образом:
1. В контроллере весь кэш (512 мб) использовать для кэширования записи, т.к. все эти read-ahead отлично умеет делать InnoDB, да и у сервера оперативки будет на порядок больше чем кэш контроллера. Размер блока наверное нужно сделать 16 kb.
2. Основные жесткие диски объединить в RAID1, дополнительные тоже в RAID1.
3. На основных жестких выделить 2 раздела: boot (64 mb), main. Последний разбить через LVM:
3.1. linux (где будет сам linux) - 50 Gb, reiserfs
3.2. mysql (база данных) - 100 gb, ext4
3.3. www (веб-файлы) - 120 gb, reiserfs
3.4. tmp - 20 gb, ext4
4. На дополнительных жестких дисках сделать такие разделы:
4.1. lv_linux_snapshot - 50 gb - сюда будут записываться copy-on-write данные при создании бэкапа системы через lvcreate --snapshot --name lv_snapshot /dev/vg/linux
4.2. lv_mysql_snapshot - 100 gb - аналогично для резервной копии mysql
4.3. lv_www_snapshot - 120 gb - аналогично для создания копии папки www.
4.4. backups - 700 gb - для хранения бэкапов
Соответственно раз в месяц будет сниматься полный бэкап с раздела linux. Только вот есть вопрос - если потом восстановиться из бэкапа сделанного через lvm-snapshot, то запустится-ли система? :)
Раз в неделю полный raw-бэкап с базы. А за неделю для базы будут собираться бинарные логи и складываться в backups. Также наверное стоит делать sql-бэкап через mysqldump хотя бы раз в месяц на экстренный случай, если raw-бэкап сделался криво и не запустился.
С www-раздела лучше конечно делать 1 полный бэкап + инкрементальные например в течение месяца. Какой тулзой лучше всего это организуется?
Ну и backup-сервер будет заходить в раздел backups каждый день и скачивать через scp бэкапы.
Ещё не очень понятно какие настройки выставлять при создании файловых систем...
- Для комментирования войдите или зарегистрируйтесь
Сервер лучше бы взять в 2.5
Сервер лучше бы взять с 2.5 дисками, их больше влезет и выбор вариантов raid сразу увеличится.
Всю дисковую систему тестить с разными вариантами конфигов с максимально приближенным шаблоном нагрузки. Сначала raw диски , потом с файловой системой. Менять-крутить разные параметры и смотреть на результаты. Много чего всплывет интересного. В этом месте и с настройками ФС определитесь, с самими ФС и настройкой VM.
Reiser рекомендую затестить на предмет 100% заполнения ФС. Однажды словил дикое снижение перфоманса при заполнении райзера на ~95%. Причем, освободив место почти в половину, грабли с перфомансом не улучшились.
alexanderyt
Насчёт 2.5 дисков - согласен, вроде как помимо того, что они меньше по размеру, ещё и среднее время доступа должно быть меньше из-за меньших расстояний, которые приходится проходить считывающей головке.
По поводу масштабных тестов - это конечно хорошая идея, но уж больно трудоёмкая... Хотелось бы иметь систему, в которой при появлении перегрузки дисков можно менять конфигурацию (добавлять новые диски в RAID-массив), менять разделы, переносить базу/контент с массива/раздела на раздел... LVM в этом плане очень гибкий.
-
Да там не особо и трудоемко.
Да там не особо и трудоемко. Размер страйпа в рейде выбирать методом тыка уж точно плохая идея.
по вашей схеме у вас 2 винта
по вашей схеме у вас 2 винта гуляют под бекапами.. а можно было бы на них расместить раздел mysql или www по вашему усмотрению.. при нагрузке на 4х винтах вертется будет шустрее..
а еще лучше взять 4 одинаковых и сделать 0+1 .. а бекапы сливать rsyncom на бекапсервер
Под бэкапы нужно много место
Под бэкапы нужно много место - особенно много может понадобиться под бинарные логи MySQL.
Возможно стоит просто взять сервер с 6-ю отсеками для дисков и если будут проблемы с перегрузкой ввода-вывода, то будет 2 пути решения:
1. Перенести на большие SATA-диски например www-раздел. Это будет легко сделать при использовании LVM
2. Добавить ещё пару SAS-дисков в RAID 0+1... Вот только умеет-ли контроллер в горячем режиме принять новые пару дисков и перестроить RAID1 из 2-х дисков в RAID 1+0 из 4-х дисков?
Ещё кстати у контроллера на который дал ссылку заявлено: Число поддерживаемых устройств До 4 с прямым подключением ко внутренним портам или до 32 устройств с помощью SAS-экспандеров. Что за SAS-экспандер, как он подключается и как влияет на производительность?
-
Лучше поменяйте контроллер
Лучше поменяйте контроллер ;)
Кстати, рассмотрите возможность программного РАЙДа. Если у вас памяти немеряно, как вы пишите, то РАЙД-10 и ЛВМ с большим кэшем даст больший эффект, чем дешевые контроллеры.
на текущем сервере у вас есть
на текущем сервере у вас есть проблемы с iowait?
50gb на систему это слишком - даже для desktop хватает 10 с избытком. Подумайте действительно ли вам нужен LVM, если хотите высокой производительности?
yaleks написал(а): на текущем
Проблем с вводом/выводом на данный момент нет.
LVM нужен в первую очередь чтобы снимать бэкапы с БД, не останавливая её через lvm-snapshot. Т. е. в принципе LVM-раздел можно выделить только под mysql.
Также я считаю, что нужно снимать образы с корневой ФС, чтобы в случае каких-то сбоев или взлома (при условии, что использованная уязвимость известна) можно было приехать в серверную с образом системы до взлома, накатить её, пофиксить уязвимость и запустить в нормальном режиме. Какие есть способы снять образ с корневой системы, который можно будет потом загрузить на сервер? lvm-snapshot решает эту задачу?
Насчёт 50 gb - да, возможно и переборщил. Для серверной системы вполне хватит 10-20 Gb.
-