Всем привет!

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

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

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

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

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

Добрый день!

1) Хочу предупредить, что при использовании "rolling-release" у Вас всегда будет что-то не работать, такова их природа
Ну и 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, увы, не работал

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

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

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

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


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


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

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

а бэкапы - 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


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

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 с вами были какие-то особые отношения

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

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


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

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

И всё это время Ваш сайт будет простаивать

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


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


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


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


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

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

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

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

Конечно неправ. В хетцнере дешевое десктопное гуано, которое берут пионэры.

Мне кажется как-то так:

- если сервер используется для оказания услуг хостинга (то есть сотня - пара сотен обычных клиентов, куча каких-нибудь неведомых администратору сайтов), то да, лучше использовать или CentOS или Debian/Ubuntu, т.е. те системы, для которых есть поддержка со стороны бизнеса, иначе могут быть проблемы с установкой всяких там панелек и прочего софта (они попросту могут не поддерживать инсталляцию на такие системы), а быстрое обновление, например, php будет требовать обновления cms-ок (действий, которые будет осуществлять не админ сервера, а админ/владелец сайта)... понятно, что в таком случае хочется иметь стабильную систему с длительной поддержкой и не трогать...


- (это мой вариант) если сервер используется для хостинга 1-5 проектов небольшой команды стартаперов из трёх-пяти человек или по принципу "1 сервер - 1 проект" - то почему бы и нет - ведь разработчики побыстрее хотят получить доступ к новым версиям (это открывает новые возможности и часто ускоряет работу)? А хорошо оптимизированный сервер поможет оттянуть момент покупки новых серверов и тем самым позволит немного сэкономить на этом (может быть, именно те самых дополнительных 10% и хватит) и чем больше оптимизированных серверов - тем больше экономия, тем более оправданными кажутся бОльшие временные затраты на администрирование.

Например, насколько я слышал, вконтакте используют (или использовали) Debian + Apache с mod_php. Интересно, сколько бы миллионов они сэкономили на железе (учитывая их объёмы в тысячи серверов), если бы просто наняли пару нормальных профессиональных админов, которые бы установили и настроили везде оптимизированную генту. Но вообщем-то, они не парились об этом, потому что начальные инвестиции позволяли не париться.



Boris A Dolgov,



Лучше обновления делать ночью, ночной аптайм не является чем-то очень критичным для проекта как правило (если проект ориентирован только на Москву-Питер, а не на весь мир сразу, а так и есть в большинстве случаев). (и опять же - если проект свой - то число 99,99% аптайм не играет никакой роли, важнее ответ на вопрос "а сколько денег потеряешь (не получишь), если выключишь сервер на три часа ночью?" как правило ответ "ни сколько", в случае с хостингом - да, тут хостер обязан гарантировать аптайм по договору вне зависимости от того, что, к примеру, проект на сервере с 88% аптаймом (3 часа оффлайна на технические работы каждый день с 3 до 6 ночи по Москве), всегда работающий в нужное время принесёт больше денег, чем сервер с 99% аптаймом, отключающийся в неподходящее время)
Выдавать 503 код состояния - на это нормально реагируют поисковики, это подходит для SEO. А в большинстве случаев даже выключать не придётся. Тот же хабр, например, часто в оффлайне по ночам, это не мешает проекту прилично зарабатывать...

Если аптайм важен и нужно именно 99,99% - можно использовать два сервера, сделать кластер, не обновлять одновременно, вот и получится 99,99% аптайм. Кстати, интересно, как это технически бы выглядело (в недорогом исполнении)...

Если что-то очень плохое случилось (с пайтоном, например) в генту - можно переустановить из stage3 или снэпшота Btrfs.



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


Да, я думаю, что это можно использовать. Единственная проблема - https://btrfs.wiki.kernel.org/index.php/FAQ..._fsck_like_tool
Именно из-за этого как я понимаю, на Btrfs стоит экспериментальный флаг в ядре



Возможно, вы сможете обойтись и без федоры:

http://slackware.mega.kg/files/slackware64.../a/btrfs-progs/
https://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3
ядро надо минимум 2.6.31 вроде бы (причём и в 2.6.38 были добавлены какие-то вещи, поэтому я с 2.6.38 тестирую всё сейчас на всякий случай)

Но забэкапьтесь сначала, конечно же...


А это как-то зависит от того, какая именно база? Если большая часть всего в CouchDB - её тоже стоит отдельно или без разницы?
Вообщем, nginx (статика), uwsgi (джанга/пирамид), CouchDB (nosql - базы данных) - это основа, а также немного mysql и php-fpm - это для типовых wordpress/drupal/modx... вообще, имеет ли смысл выносить couchdb, uwsgi и nginx на отдельные серверы или может быть лучше из нескольких серверов попробовать сделать кластер (вот и об аптайме можно будет не волноваться)

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


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



MiksIr,

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

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

Почему бы не делать по ночам (ночной аптайм всё равно не критичен) раз в пару недель обновление? на это уйдет максимум минут 20 (проверка конфигов, чтение информации об обновлениях и лога обновления) не считая времени компиляции



Мне кажется, стоит использовать всегда последние стабильные версии. То есть если что-то не работает - то следует н