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

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

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

[Lord Daedra]

Boris A Dolgov,

А мне кажется неправильным сразу при проектировании системы закладывать в неё некоторый обязательный даунтайм.

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

Опять же не могу сказать по поводу btrfs, но в LVM это устроено так: снапшот делается мгновенно, затем все изменения сбрасываются в специальном формате на отдельный раздел, и этот раздел можно примонтировать в какое-то другое место, как будто это отдельный раздел. При этом из-за записи всех изменений (которые идут блоками размером в PE) всё жутко тормозит - фактически, вместо одной (возможно небольшой) записи, нужно копировать большой кусок данных, и исправить это никак нельзя. Так как это работает на блочном уровне, то желательно перед созданием бекапа завершить все записывающие процессы, перевести ФС в ro, сделать sync, и только после этого создавать бекапный раздел. Это дорого, но при должной автоматизации уложится секунд в 10.

Ясно. Спасибо за объяснение основных принципов работы!

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

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

/* это пока просто теория/планы на будущее, в наличии на это всё на начальном этапе 1-3 сервера, не более */

Да, конечно, хотелось бы нагрузить их поровну.

Мои знания в этой области весьма ограничены, но почему бы и не поучиться. Я прочитал информацию с сайта http://www.loadbalancing.org/ и несколько статей в блогах, понял, что один из самых оптимальных и недорогих вариантов - это использование HAproxy. (Так же это можно сделать средствами nginx (в случае вебсервера), но это решение похуже).

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

Пока я не до конца понимаю, как это будет работать с uWSGI. Я думаю, что запрос должен обрабатываться на том же сервере, куда он пришёл, а не делать кластер для uWSGI как-то отдельно.. И с базой аналогично. А то получится, что статику с 1 сервера берем, базу с другого, а обрабатывается всё на третьем, это как-то странно выглядит с учётом того, что на каждом установлены те же самые компоненты.

Минус разделения всё на отдельные серверы - архитектура сложнее становится. Гораздо проще если всё состоит из однотипных серверов. При увеличении нагрузки - просто покупается ещё 1 сервер и туда клонируется какой-нибудь из существующих.

Кроме HAproxy, видимо, ещё Gluster потребуется установить/настроить/изучить.

Наверное, как-нибудь так (IMG:style_emoticons/default/unsure.gif)

...

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


MiksIr,

Спасибо, что поделились своей точкой зрения, не до конца согласен с ней, но да, что-то в этом есть... Пока я просто пробую Gentoo на VM дома со всякими оптимизациями и прочее.

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

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

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

Мне очень бы хотелось воспринимать Gentoo как FreeBSD (которая считается стабильной серверной системой), я собственно так и стараюсь делать. С FreeBSD не работал (не считая домашней MacOS с MacPorts). Судя по записям в блогах, отличие в том, что в FreeBSD есть определенный набор пакетов, важных для стабильности системы, которые обновляются только при переходе с ветки на ветку, в Gentoo же абсолютно всё можно обновлять в любое время с появлением новых версий.

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

FreeBSD не нравится как раз тем (и только тем), что FreeBSD это не GNU/Linux. Я не смогу там запустить какие-то вещи типа Jedox Palo (OLAP) или что-то подобное. Не хотелось бы ограничивать себя в выборе программ.

Как минимум - наработкой на отказ.

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

ЗЫ: базу бакапить нужно средствами для бакапа базы, а не делать снимки файловой системы.

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

eSupport.org.ua,
ок, ещё одна попытка:

i7-980X Hexacore, 24Gb RAM, 2 SSD (не считая платы за установку) стоит 139 евро, из этого вычитается 19% VAT, получается около 112 евро или 4500 рублей, что очень и очень недорого за такую конфигурацию. Пинг к этому серверу из Москвы будет около 60. В случае любого сбоя есть возможность
а) перезагрузить через панельку (без звонков куда-то там в дц)
б) загрузиться с rescue системы по сети чтобы восстановить что-нибудь (а не просить сотрудников дц)
в) за 10 минут с помощью скрипта с rescue-системы установить чистый debian/suse/centos/ubuntu/freebsd, при этом системы ставятся с оптимизированными ядрами под эти серверы (не проверял лично, но читал про это), есть зеркала для скачки обновлений, понятно, что оно быстрее скачает и трафик наверное не учитывается...
г) 100 Гб места для бэкапов на другом сервере

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

если вы не считаете этот датацентр хорошим по соотношению цена/качество, назовите другие, какие вы считаете хорошими? то есть такое возможно если а) за те же деньги давали бы больше или б) тоже самое за меньшие деньги

Кому и кобыла невеста.

то есть приведите какие-то конкретные примеры того, что является более оптимальным выбором, а то сейчас вы просто как-то неаргументированно "наезжаете" или на датацентр или на мою систему оценки (IMG:style_emoticons/default/rolleyes.gif) (IMG:style_emoticons/default/smile.gif)

Сообщение отредактировал Lord Daedra - 04.05.2011, 22:47

[eSupport.org.ua]

Твоя ошибка в том, что на первое место ты ставишь цену за аренду оборудования, а не качество. По поводу хороших ДЦ и оборудования я в свое время писал статью на Хабре, где приводил расчет по ценам на стойку.

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

Если бы хетцзнер хоть давал возможность NLB, то тогда можно было бы его рассматривать как вариант для файловера, что дает более-менее нормальную надежность.