Сборка ядра линукса для собственного сервера (хостинг 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 и отключить ненужные вещи, правда эта попытка была не очень удачной :-) Но планирую разобраться в этом.

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

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

[Boris A Dolgov]

Добрый день!

1) Хочу предупредить, что при использовании "rolling-release" у Вас всегда будет что-то не работать, такова их природа (IMG:style_emoticons/default/sad.gif)
Ну и Gentoo я бы не выбрал для сервера, так как его тяжело развертывать, все административные действия занимают кучу времени и откатываться в случае их неправильности достаточно тяжело. Лучше выберите что-нибудь стабильное, вроде rhel6 - он сейчас достаточно свежий. Есть его бесплатный вариант - Scientific Linux 6. Но следите за багфикс-обновлениями.
2) Все hardened если и имеют смысл, то (на мой взгляд) только на shared-хостинге. Засуньте каждый сайт в отдельного пользователя, правильно проставьте права, часто бекапьтесь - и в 97% случаев у Вас не будет никаких проблем. Если хотите быть уверены на все 99% - то можете изучить SElinux и выставить выполняемым python/php и прочим смотрящим наружу приложениям сильно ограниченный контекст, но там нужно не отрубить лишнего.
3) Особых рекомендаций по ядру нет. Можно отключить статистику, аккаунтинг и аудит (и прочие ненужные слова из General setup), выкинуть ненужные драйверы и подсистемы, HZ поставить 100 и отключить preemption (в Processor Type and Features). Но это - погоня за миллисекундами, сомневаюсь, что даст хотя бы 10% прироста производительности.
4) С btrfs, увы, не работал (IMG:style_emoticons/default/sad.gif)

5) Суровая реальность говорит, что 90% процессорного времени будет тратиться не на ядро, а на пользовательский код. Так что лучше искать узкие места в самом коде и оптимизировать их, тратя время на это. Та же суровая реальность говорит, что в случае нахождения хакером дырки вроде remote code execution в каком-то сайте (а только от этих дырок можно защищаться в ядре всякими hardened), то это всегда заканчивается фатально для сайта, в котором эта дырка была найдена и никогда не заканчивается фатально для остальных сайтов.

[eSupport.org.ua]

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

[Lord Daedra]

Спасибо за ваши ответы!

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

откатываться в случае их неправильности достаточно тяжело

По идее восстановление выглядит так (если ядро, например, не грузится или какие-то большие проблемы): зайти в панельку управления сервером, заставить ребутнуться с rescue-образа по сети. Далее войти туда по ssh и скопипастить пару команд в терминал:

Код

% btrfs device scan && mkdir /broot && mount -o defaults,noatime,discard,ssd /dev/sda3 /broot && mount -o subvol=__active /dev/sda3 /mnt/gentoo && mount -t ext4 /dev/sda2 /mnt/gentoo/boot && mount -o bind /dev /mnt/gentoo/dev && mount -t sysfs none /mnt/gentoo/sys && mount -t proc none /mnt/gentoo/proc && chroot /mnt/gentoo /bin/bash
% env-update && source /etc/profile

ну и всё, мы внутри системы, можно пересобрать ядро как-нибудь иначе, установить или удалить какой-нибудь пакет и после исправления ошибки перезагрузиться в нормальный режим

вообще, примерно такие же действия придётся делать на любой системе, думаю, генту тут не сложнее и не проще той же убунту/дебиана/центоса/сусе

а бэкапы - Btrfs и LVM умеют делать бэкапы прямо разделами, это тоже никак не связано с ОС

все административные действия занимают кучу времени

есть способы сборки обновлений на одном (например, тестовом) сервере и дальнейшего обновления с него, то есть один компилирует, остальные используют это (понятно, что архитектура должна быть такая же и use-флаги такие же), ну, или как вариант вместо Gentoo использовать ArchLinux

времени на установку Gentoo требуется больше (так как вручную делается), да, но, например, обновлять конфиги гораздо удобнее, чем на Ubuntu, а обычное обновление пакетов ничем не сложнее того же убунтушного

вообщем, на все серверы, на которые мне не очень хочется тратить время, я ставлю Ubuntu Server LTS и оно отлично работает, но на каких-то собственных серверах всегда хочется что-то настроить получше под себя, наверное, это самое правильное - выбирать систему, которая больше всего нравится админу (в данном случае этот сервер буду админить сам)

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

3) Большое спасибо! Кстати, про Ubuntu, мне показалось достаточно интересным:

В чём разница между серверной и десктопной версиями Ubuntu? Ответ дан здесь:
https://help.ubuntu.com/11.04/serverguide/C...ro-kernel-diffs

• The Server Edition uses the Deadline I/O scheduler instead of the CFQ scheduler used by the Desktop Edition.
• Preemption is turned off in the Server Edition.
• The timer interrupt is 100 Hz in the Server Edition and 250 Hz in the Desktop Edition.

When running a 64-bit version of Ubuntu on 64-bit processors you are not limited by memory addressing space.

To see all kernel configuration options you can look through /boot/config-2.6.35-server. Also, Linux Kernel in a Nutshell is a great resource on the options available.

надо будет детальнее сравнить конфиги и посмотреть, что они там настраивали в ядре ещё...

4) всё впереди, я думаю, она станет вариантом по умолчанию через несколько лет на большинстве дистрибутивов (первой, возможно, будет 16 федора)

5) самое узкое место если оценивать проекты - это как правило база, поэтому сейчас изучаю CouchDB, для некоторых задач весьма неплохое решение, ну и думаю, что на полупустом (кажется, это важно) SSD с Btrfs (и включёными оптимизациями под SSD) оно должно работать получше, чем на обычных дисках, единственное, уточню, какие именно SSD там используются (старые вроде плохие и не очень-то быстрые, конечно было бы интересно заюзать новые интеловские SSD под SATA 6 Gbit/s...)



eSupport.org.ua,

Ничего они не тормозят, если железо нормальное

Железо обычное (планирую взять в хетзнере с SSD-дисками), я обычно выбираю по соотношению цена/производительность, у хетзнера, вроде, это соотношение лучшее (или одно из лучших) на данный момент. (Или я не прав?)

Вообщем, железо типа такого i7-980X Hexa-Core, 24Gb RAM, 2x120Gb SSD, но если вы вдруг знаете более выгодный вариант (по соотношению цена/производительность при примерно таких же (не хуже) показателях стабильности и качества саппорта), то подскажите, плиз. Всё что я видел - или хуже или дороже или хуже и дороже. :-)

Опыта использования всех этих патчей безопасности у меня (пока) нет, но я нашёл статью http://www.webhostingtalk.com/showthread.php?t=387527 , здесь автор тоже ставит под сомнение необходимость обязательного использования подобных патчей, это заставило меня немного задуматься об этом... с другой стороны, статья опубликована несколько лет назад

А за Генту на хостинге я бы дал пенделя

Вот сразу чувствуется, у Gentoo с вами были какие-то особые отношения (IMG:style_emoticons/default/rolleyes.gif) (IMG:style_emoticons/default/tongue.gif)

Gentoo достаточно простая и популярная система (я убунтушник разобрался в ней не спеша недели за 2), достаточно популярный дистрибутив если посмотреть на сайт http://www.dudalibre.com/gnulinuxcounter?lang=en
Там есть профили, можно использовать серверный. Многие так и делают.

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


Но мне бы не хотелось превращать эту тему в выбор лучшей ОС для сервера, это такой достаточно религиозный вопрос... В конце концов линукс - это ядро, а всё остальное - это не так важно и служит лишь для удобства. Хотелось бы просто постараться собрать оптимальный конфиг для ядра, тем более сборка ядра genkernel'ом (если знать, что включать) - это очень простая процедура и в принципе почему бы не отключить пару ненужных опций и включить пару оптимизаций - это ведь действительно просто, почему не потратить на это пару часов раз в полгода чтобы сделать оптимальное ядро для своих серверов.

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

[Boris A Dolgov]

По идее восстановление выглядит так (если ядро, например, не грузится или какие-то большие проблемы): зайти в панельку управления сервером, заставить ребутнуться с rescue-образа по сети. Далее войти туда по ssh и скопипастить пару команд в терминал:

Код

% btrfs device scan && mkdir /broot && mount -o defaults,noatime,discard,ssd /dev/sda3 /broot && mount -o subvol=__active /dev/sda3 /mnt/gentoo && mount -t ext4 /dev/sda2 /mnt/gentoo/boot && mount -o bind /dev /mnt/gentoo/dev && mount -t sysfs none /mnt/gentoo/sys && mount -t proc none /mnt/gentoo/proc && chroot /mnt/gentoo /bin/bash
% env-update && source /etc/profile

ну и всё, мы внутри системы, можно пересобрать ядро как-нибудь иначе, установить или удалить какой-нибудь пакет и после исправления ошибки перезагрузиться в нормальный режим

И всё это время Ваш сайт будет простаивать (IMG:style_emoticons/default/smile.gif)

В данном случае я имел ввиду менее серьезный баг. Например, если на Gentoo отвалится python, его будет достаточно трудно быстро вернуть, а в большинстве дистрибутивов хватит чего-нибудь вроде rpm/dpkg/yast reinstall python, ну или заливки поверх корня готового архива, подготовленного с другой машины.

а бэкапы - Btrfs и LVM умеют делать бэкапы прямо разделами, это тоже никак не связано с ОС

Будьте осторожны - например, если это попробовать использовать на LVM, то получается такой perfomace regression, что хочется вернуться к традиционным бекапам. Хотя, в btrfs это может быть лучше, ведь она оперирует не блоками, а файлами.

4) всё впереди, я думаю, она станет вариантом по умолчанию через несколько лет на большинстве дистрибутивов (первой, возможно, будет 16 федора)

Мне даже захотелось попробовать (IMG:style_emoticons/default/smile.gif) Сейчас у меня на ноуте (с двумя ssd) slackware64 на ext3, возможно, имеет смысл перевестись на fedora15 + btrfs.

5) самое узкое место если оценивать проекты - это как правило база, поэтому сейчас изучаю CouchDB, для некоторых задач весьма неплохое решение, ну и думаю, что на полупустом (кажется, это важно) SSD с Btrfs (и включёными оптимизациями под SSD) оно должно работать получше, чем на обычных дисках, единственное, уточню, какие именно SSD там используются (старые вроде плохие и не очень-то быстрые, конечно было бы интересно заюзать новые интеловские SSD под SATA 6 Gbit/s...)

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

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

Ради холивара - а что плохого в слаке? Я с fedora на неё очень легко слез (когда понадобилось пересобирать ядро и иксы 10 раз в день с большой кучкой сторонних патчей). А ArchLinux, вроде бы, та же слака, только сделанная с нуля.

[MiksIr]

Нельзя генту на сервере. Как и большинство дистрибутивов. Реально подходят только энтерпрайз версии ну или centos.
Попробую объяснить почему. Нормальные сервера живут годами. Это сейчас вам кажется год - огромной величиной, а потом окажется, что уже 4-й год пошел. Сервера не обновляются глобально. Т.е. меняются пакеты с известными секьюрити дырами ну и пакеты, которые нужно поменять ибо потребовалась новая функциональность. Администраторы, которые постоянно обновляют систему аргументируя "новое - значит лучше" - долго не работают на своем месте.
Так вот, для серверного дистрибутива важно, что бы вы смогли поставить обновленный или новый (но стабильный) пакет не обновляя весь дистрибутив по связям. Ну, и что бы эти новые пакеты появлялись.

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

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