Сборка ядра линукса для собственного сервера (хостинг php- python-проектов, включая приложения для соцсетей, планируется высокая нагрузка) Опции

[Lord Daedra]

Всем привет!

Не нашёл подходящего раздела, поэтому напишу тут.

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

Вообще, я использовал Ubuntu Server и был счастлив, но сейчас захотелось собрать что-то более оптимизированное под мои задачи, к тому же Ubuntu, увы, не rolling release.

Использовать на сервере я планирую Gentoo (но возможно передумаю в сторону ArchLinux), так как она отличается достаточной гибкостью и при этом является rolling-release'ом (то есть пакеты свежие, что мне очень нравится).

Потестировав немного Gentoo на домашней впске я обнаружил такие технологии как grsecurity (http://grsecurity.net/), pax (http://pax.grsecurity.net/) ( для использования этой технологии используется патченый gcc (туда добавляется поддержка SSP и(или) PIE)), rbac, selinux...

Вообщем, это классные фишки, но они тормозят. Так как я не админ, то хотелось бы спросить более опытных в этом плане людей - что из этого имеет смысл использовать на сервере при условии, что на этом сервере нет пользователей кроме администратора (и каких-либо скриптов, про которые администратор не знает) и вход на ssh только по ключам, нет ftp, нет почты, нет днс, нет апача (есть nginx), есть mysql, есть couchdb, есть python и всё что с ним связано (деплоймент через uWSGI), есть php-fpm с suhosin? То есть взлом возможен лишь через какие-то кривые скрипты (php, python)...

Имеет ли вообще смысл в hardened-ядре или лучше не стоит это всё ставить (hardened ядро со всеми этими патчами) и использовать vanilla ядро? То есть насколько большая плата производительностью за безопасность, не слишком ли она большая?

Кроме того, что точно следует отключать в ядре или как-то настраивать? (ну, помимо неиспользуемого оборудования и файловых систем)

Было бы интересно собрать в этой теме примерные рекомендации по настройке ядра.

Забыл добавить, что пока я поэкспериментировал только с Btrfs-raid1 (как замена software raid1+LVM) на / и systemd, и то и другое у меня ок заработало. Btrfs имеет оптимизации для SSD-дисков, поэтому интересная вещь на мой взляд, а systemd - просто потому что после убунтушного upstart'a мне показалось как-то неправильным возвращаться на обычный gentoo-шный sysvinit...

Потом попробовал подключить grsecurity и отключить ненужные вещи, правда эта попытка была не очень удачной :-) Но планирую разобраться в этом.

Не стал делать тему в закрытых разделах, думаю, это будет интересно многим владельцам обычных серверов...

Возможно, кто-то сможет посоветовать интересные статьи по теме или расскажет о своём опыте... Спасибо!

[MiksIr]

а какие решения вы использовали бы на моём месте.. вот то, что я писал выше (HAproxy, Gluster) - стоит ли в это разбираться или есть что-то более подходящее?

Нет, ничего из этого двух не использовал. Как правило, Linux HA (heartbeat+pacemaker) для переключения сервисов по нодам, nginx как фронт-енд балансировка (т.е. совсем не видел причины вводить дополнительный уровень в виде haproxy, так как nginx хорошо балансирует http с возможностью кеширования и отдачи статики напрямую). С распределенными фс работал мало, ибо либо были простые системы, где хватало програмной синхронизации данных по нодам, либо были внешние FC дисковые полки.

Но собственно, что мешает выделить какие-то значимые пакеты и не обновлять их часто? А при обновлении предпочитать бинарники, а не собирать на сервере из исходников со всякими оптимизациями. Такая стратегия невозможна или чем-то затруднительна?

Тем, что это не поддерживается комьюнити генту. И вы никогда не узнаете - мантейнер нужного вам пакета влепил зависимость от новой версии системного пакета потому-что со старым не работает, или потому-что у него стоит новый и он класть хотел на тестирование со старыми. Ну и тем, что когда вы захотите пересобрать по каким-то причинам пакет старой версии - его уже не окажется в репозитории. Ну, как пример, ставишь новую версию nginx - а там баг. Пытаешься откатиться на старую версию - а ебилды почистили, оставили три последних... а баг появился четыре минора назад. Вот это самый простой косяк, с которым я сталкивался... про остальные просто долго писать.
Не, пробуйте, конечно. Потом сами поймете, что для сервера важна стабильность окружения, и лишь единицы пакетов требуют новых версий. И очень круто, года эти пакеты новые нормально разворачиваются на старом окружении. Генту вам это не даст.

Основные причины поломок - это жёсткие диски и блоки питания. Как я понимаю, они одинаковые везде.
Но в любом случае 2 сервера (любых) лучше 1 брэндового так как даже если они и сломаются раньше -то скорее всего, не одновременно.

Если вы берете в аренду - то пофиг. Когда создаешь свой серверный парк - там другие правила. В том числе и штука аналогичная той, что я про дистрибутивы говорил - т.е. если у вас вылетает что-то через три года - вы сможете купить запчасти, а не выкидывать сервер =)

а если стоит блокировка, то в чем разница, в чём заключаются риски? конечно средствами для бэкапа базы правильнее, но ведь и так работает...

В том, что не нужны никакие блокировки. Есть много решений по бакапу, включая быстрый инкрементальный. И не нужно думать, как поведет себя база и самое главное - какое состояние базы записано на диске, не окажется ли оно нерабочее, если пытаться с него запуститься. Т.е. нужно неплохо знать как именно эта база работает с диском. В общем, никому не нужное веселье.