Всем привет!

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

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

Вообще, я использовал 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 (проверка конфигов, чтение информации об обновлениях и лога обновления) не считая времени компиляции



Мне кажется, стоит использовать всегда последние стабильные версии. То есть если что-то не работает - то следует не заставлять админов делать оверлэи, а заставлять программистов обновлять код чтобы сделать его совместимым с новыми версиями софта. Современные проекты не имеют точки завершения. Если проект жив - он всегда развивается, меняется, всегда дописывается, переписывается. То есть задача не такая уж и сложная, к тому моменту, как Django перейдёт на 3 ветку пайтона, проекты уже по 10 раз перепишутся или просто умрут по тем или иным причинам. При очередном изменении кода добавить поддержку новый версий - не так уж и сложно вообщем-то..

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

eSupport.org.ua,



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

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

...

А какой датацентр используете вы сами или использовали бы (не пионэр)? :-) При условии, что за сервер платить своими деньгами (а не деньгами заказчика, которого консультируете). Разве вы бы не стали стараться сэкономить на том, на чём можно сэкономить и искать места подешевле и получше?

А чем Мерседес отличается от Запорожца? Только красотой?
Не пионэры берут сразу стойки, в которое пихают свое железо.

Ок, если аналогия с машинами - то Toyota. :-) Отличаются своей практичностью, хорошее соотношение цена/качество.

хетзнер не тойота? :-)

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


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


Уже перешел - всё-таки, slackware на десктопе надоела. Заодно развалил fake raid в пользу нормального mdraid и удалил windows Кстати, на fedora есть какой-то "btrfsck is used to check a btrfs filesystem. device is the device file where the filesystem is stored."

Но когда надо было всё пересобирать и подстраивать (специфичный ноут, на 2.6.32-ядрах из коробки не работала графика и иногда клавиатура, не говоря о остальном), как раз спасла возможность превратить систему в контроллируемую помойку, потому что делать rebase всех федоровских/убунтовский патчей, мерджить их с какими-то чужими изменениями и постоянно пересобирать всё это в пакеты у меня не хватило бы сил. Утверждается, что сила slackware - в том, что большинство софта не уходит от vanilla-версий, а все скрипты запуска/конфигурирования предельно просты, понятны и заменяемы.


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


В принципе да, правильно. Есть альтернативные пакетные менеджеры с контролем зависимостей Но уже выше написал, когда такое может пригодиться.

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


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

быстро потеряют работу.

Это теория. А на практике все не так. На практике у вас развивается одна часть кода, а вторая часть несколько лет работает и никто не трогает. А если кому-то придет в голову обновить интерпретатор - она может отвалится. Что повлечет за собой исправления, переписывания и т.д.

И самое главное, сборка их исходников со всякими "О"птимизирующими ключами даст слабый прирост производительности и потенциальные проблемы. Вот когда у вас вроде проверенный годами демон начнет валиться в корки - вот тогда начинаешь понимать, что лучшее - враг хорошего. Конкретно про ядро - никто не мешает вам его компилировать самому, порой это даже нужно. Но опять же - тактика - раз в неделю ставим последнее ядро с kernel.org приведет к увольнению. Ибо случаев, когда в новых ядрах что-то где-то отвалилось - огромное количество, и никогда не знаешь, как оно аукнется.

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


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


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


По любому в 2-серверной конфигурации должно быть или 1/0 или 0.5/0.5, т.е. или один сервер в горячем резерве или работают оба, но под половинной нагрузкой. Второй вариант, конечно, лучше, так как позволяет пики пережить, ну и заметить проблемы по железу, но в принципе и горячий резерв сойдет.

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

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

Boris A Dolgov,


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


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






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

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

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

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

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

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

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

Наверное, как-нибудь так

...

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


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 Гб места для бэкапов на другом сервере

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

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



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

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

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

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

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

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

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

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

MiksIr,

я наткнулся на это сравнение
http://affectioncode.wordpress.com/2008/06...roxy-and-nginx/
и несколько других, nginx не является в данном случае более медленным решением? то есть если оставить его просто для раздачи статики и каких-нибудь других задач, а те вещи, что умеет лучше делать HAProxy, переложить на неё - это будет хуже? если да, то чем? вроде бы это более unix-way - используется пусть много, но лучших программ, каждая в своей области... разве не так?


К сожалению, не получилось сразу разобраться, а что представляет из себя Linux HA (heartbeat+pacemaker), вы не могли бы немного поподробнее пояснить этот момент? То есть я нашёл официальную wiki, но не до конца понял, а зачем нужна эта вещь, одного nginx (или nginx+HAProxy) не хватит?

Как-то так:
Если сервер, на который пришёл запрос (кстати, как обычно делается (в простом дешёвом случае), просто добавляются в зону несколько А и АААА записей разных серверов у регистратора или на каком-нибудь dyndns.com ?) сильно загружен, то должен выбраться какой-либо другой незагруженный сервер (выбирает или HAProxy или nginx), туда пересылают запрос пользователя на nginx, если это статика - он её раздаёт, иначе отправляет это своему локальному php-fpm (если php-скрипт) или локальному uWSGI (если приложение на Django/Pyramid) (т.е. всё на том же сервере), которые также при необходимости могут производить какие-то действия со статикой (включая контент пользователя) или локальной базой CouchDB (которая из коробки умеет мастер-мастер репликацию и так же есть на всех серверах).

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

(И есть вопрос относительно того, как сделать так, чтобы пользователь, закачав картинку на какой-то сервер закачал её (совершенно прозрачно для всех скриптов и себя) на все серверы сразу, без каких-либо блокировок его дальнейшей работы и ожиданий завершения операции, чтобы это было асинхронно и само по себе. Я думаю, тут нужна какая-то сетевая файловая система (каждый сервер выделяет отдельный ssd диск на это), которая бы сделал а-ля raid1 на этих разделах между разными серверами и позволяла приложениям (скриптам) не заботиться о таких вещах, как синхронизация. То есть приложение (скрипт) копирует файл пользователя на локальный диск, а дальше этот файл уже сам как-то асинхронно расходится по другим серверам. Когда файл запрашивается - сначала проверяется текущий, если ешё не успело синхронизироваться (только закачали) - ищетсяна других серверах. Как-то так. Так как мне нравится Btrfs, то, наверное, Ceph был бы идеальным решением (работает над Btrfs-разделами и задействует преимущества этой системы), но он пока в разработке, поэтому я и сказал про Gluster) Ну, вообщем, наверное, про Gluster я всё же прав...

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

P.S. а MySQL хватит и на одном сервере, там ничего такого нет и не будет...


Тут да - полностю согласен.

Может быть стоит написать об этих проблемах на гентушном багтрекере и предложить какие-либо концептуальные подходы к решению проблемы?
Я бы предложил такую реализацию:
Для ебилдов предложить сделать официальный сервер с архивами всех старых неподдерживаемых ебилдов, чтобы он прозрачно для всех собирал и хранил вообще все ебилды всех времён. Ограничить там скорость до минимума, чтобы никто не использовал его в качестве основного (и тем самым не нагружали постоянно сервер), а если вам потребуется старый ебилд - можно будет утянуть оттуда.
Кстати, я не знаю, может быть, уже кто-то придумал это до меня - слишком просто...

Ну, то есть, идеальных систем нет, для меня идеал нечно среднее между ubuntu и gentoo. Но из gentoo идеал сделать проще. По крайней мере пока так кажется. А возможные проблемы с аптаймом закрыть таким вот дешевым кластером из 2-3 серверов, даже если я случайно завалю один сервер и буду разбирааться с этим пару дней, никто из посетителей и не заметит. :-) Единственное что немного пугает - нестабильная работа, ситуации, когда непонятно, в чём именно ошибка.

Но такого у меня пока не было (на убунте с обновлениями раз в полгода) Точнее было 1 раз за всю историю "админства", когда почему-то php-cgi стал падать раз в неделю и его никто не поднимал автоматически, я тогда перешёл на php-fpm и проблем нет. Но это скорее всего, были какие-то проблемы с настройками (мне тогда было лень в этом разбираться).

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

На том же хетзнере в вики есть как минимум 5 ст