Всем привет!

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

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

Вообще, я использовал 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 статей на эту тему про генту, значит, ставят же её на сервер зачем-то :-) http://wiki.hetzner.de/index.php/Kategorie:Gentoo + сборка ядра (интересная ссылка для тех, кто ещё помнит название этой темы) http://wiki.hetzner.de/index.php/Kernel_Konfiguration .



Ясно. Вообщем, да, всё логично... А вы сами какое решение для бэкапа предпочитаете?


eSupport.org.ua,



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

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


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

Иногда есть необходимость в обработке больших объёмов данных, тут важна производительность сервера, а пользователь всего один. Трафик - это тот самый итоговый отчёт. Почему для таких задач не подойдёт hetzner?

Если я правильно понял, то NLB нужна в случае большого трафика, когда один сервер с ним не справляется... А если трафик обычный, но каждый запрос занимает значительные ресурсы сервера? Ну, вообщем, вот нельзя так давать общие советы в стиле "hetzner плохой"... Всё относительно...






Кроме NLB какие ещё критерии являются на ваш взляд важными при выборе правильного дц? Было бы интересно прочитать статью на хабре, но не знаю ника...

Выбор только по критерию качества - это осетрина первой свежести. Только так и надо поступать, причем всегда.
В России бизнес построен на нефти и откатах. В нефти уже все внедрено, а откатам SAP не нужен.
Специфика задач - создать очередной скулхостинг? Тогда не имеет значения, что за ОС там будет. Все равно через год пропадет.

А мои статьи удалила администрация Хабра, так что пиши ей - может тебе скинут на email.

Тесты - очень специфичная весч. В частности под разные задачи вы получите разные результаты. Например, haproxy умеет keep-alive на бекенд, а nginx нет. Насколько это принципиально? Если огромное число запросов в бекенд, которые выдаются очень быстро - принципиально. Если бекенд думает несколько сотен мс - не принципиально. С другой стороны, в nginx - это в первую очередь веб-сервер, и там много ручек по эффективномой отдаче статики с дисков. Стоит городить два решения вместе? Где-то да, где-то нет. Проектируйте, пробуйте... потом поделетесь своим опытом.


Да, делаете несколько записей А. Как результат, при отказе одного сервера половина клиентов отдыхает. RR(round-robin) DNS не не обеспечивает переключение клиентов. Для того, что бы забрать сервисы с мертвой машины (а IP адрес - один из таких сервисов) - нужны системы типа linux ha. Минимально передавать IP между машинами можно и с помощью carp - вроде есть порт под linux хотя изначально оно freebsd-шное. Linux HA - это такоеуниверсальное, которое позволяет описывать сервисы и управдять их запуском/остановкой в зависимости от состояния всех нод кластера.


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

MiksIr,



Если в общих чертах - как я понял из ваших слов, для деплоймента игр для социальных сетей лучше избегать haproxy, там как раз много запросов и быстрые ответы. Для обычных контент-ориентированных комьюнити сайтов (а-ля соцсети/хабр/лукэтми) и контент-ориентированных приложений для соцсетей (всякие журнальчики) - стоит рассмотреть как вариант, верно?
Вообщем, мне бы самому как раз и хотелось бы почитать подобные решения, вообще, люблю подход к обучению case study. То есть была такая-то проблема, тестировали это и это, в итоге сделали так-то.


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

ну, в целом понятно, на каждый сервер в датацентре покупаются специальные failover ip'ы по одному на сервер, которые в случае необходимости с помощью Linux HA передаются на другие серверы...

но тут возникает тогда другой вопрос - допустим, есть какой-нибудь кластер из 3 серверов с примерной нагрузкой в 60-70%. если один из серверов зависнет и система передаст его ип другому серверу - то зависнет и он... то есть нельзя просто перебросить фэиловер ип с одного сервера на другой... единственное решение - равномерно распределить нагрузку по всем оставшимся серверам...

возможно, решение было бы в покупке нескольких failover ip'ов на 1 сервер, и в случае падения сервера один ип передавать одному серверу, второй ип другому... но если в кластере не 3 а 100 или 1000 серверов, то на каждый сервер ведь не получится же купить 99 или 999 failover ip'ов чтобы равномерно снять нагрузку :-)

вот эта задача, интересно, как-нибудь решается (без какого-либо отдельного специального оборудования)?



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

Про Генту на сервере: эта тема обсуждалась и тут есть разные мнения. Кто-то согласен с вами и таких людей много. Кто-то писал, что раз в неделю делает emerge -uNDvta @world, обновление у него занимает 15 минут без учёта компиляции и никаких сбоев не было. И таких людей тоже много, многие гентушники используют генту и на сервере.

Вообщем, это нормально, если по каким-то вопросам нет единого мнения :-)



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

eSupport.org.ua,



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

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




P.S. какой же я зануда, соорри




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

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


А вы не выкладывали на дедик ру или куда-либо ещё эту статью, она у вас не осталось? С администрацией Хабра у меня тоже не самые лучшие отношения - я не люблю начинать предложения с заглавной буквы в комментариях к статьям, и они без каких-либо предупреждений сделали на мой аккаунт режим read-only с указанием причины за что при попытке отправить новый коммент, режим времененный... на пару месяцев (а по техническим причинам и на личные сообщения, какие же там у них опытные программисты работают )

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

вообщем, если у вас это осталось - скиньте лучше вы, ну, а нет так нет...

В/На Украине есть хорошая пословица, перевод которой будет звучать примерно так:
- Коля, почему ты бедный?
- Потому что дурной.
- А чего ты дурной?
- Потому что бедный.

А у немцев есть другие:
1. Я не так богат, чтоб покупать дешевые вещи.
2. Не бойся больших расходов, бойся маленьких доходов.

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

Нет, наоборот. Но зависит от бекенда и средств кеширования.

Отдельным балансировщиком решается, можно догадаться.

Покажите пальцем - у кого тут он есть?

Success история про генту на кластере из, хотя бы, полусотни серверов была бы хорошим основанием поверить.

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

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

я не считаю, что покупка серверов выгоднее аренды (если нет отдельного админа), но если бы я стал покупать сервер - купил бы супермикро, в не Dell... а вот если в офис - какой-нибудь Apple :-)

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

кроме того, целый ряд факторов:
- цена лишь условно определяет качество (а 100% надёжности всё равно не будет с любыми серверами)
- чтобы улучшить доходы иногда приходится ухудшить (sic!) сайт (с точки зрения разработчика/дизайнера), т.е. качество реализации не означает успешность, а иногда даже означает обратное
- в случае ДДОСа возможно было бы дешевле просто выключить серверы на какое-то время

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

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

специфика проектов играет большую роль, где-то нужно качество, где-то нет... общие советы "качество на первом месте" тут не работают

Ясно.

Про балансировщик-то я догадался, я думал, может быть без балансировщика есть какие-нибудь хитрости...
кстати, тут всё так запутанно вначале показалось...
сначала нашёл http://www.linux-ha.org/wiki/Main_Page
Потом эти две ссылки:
http://www.karlkatzke.com/heartbeat-vs-pac...-clvmd-vs-evms/
http://theclusterguy.clusterlabs.org/post/...at-corosync-wtf
(это для начального ознакомления)
в итоге наткнулся на http://www.clusterlabs.org/wiki/Main_Page

Профита нет, интерес может быть. Люди же :-)

Про Success story - да, очень бы хотелось прочитать что-то подобное, но судя по результатам голосования, 92% пользователей этой системы используют не более 8 серверов, по дистрибутивам выигрывают центос и дебиан (впрочем, не так много людей проголосовало там, это раз, и два, в тех голосовалках нет защиты от накруток) ... надо там Gentoo в топ вывести что ли... народ посмотрит на результаты голосования и начнут её ставить, вот и изменим мир немного :-) зато пакеты будут более протестированными
http://www.clusterlabs.org/wiki/UsagePoll
а если серьёзно - то да, в случае, если эти пакеты на данный момент работают кривовато - это достаточно серьёзный аргумент для меня чтобы отказаться от идей использовать Gentoo

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

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

А какой смысл заниматься тем, что не имеет огромных шансов на успех?

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

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

гарантий что что-либо получится никаких нет, в интернете на стартаперских форумах есть мнение что только 1 из 10 проектов получается, на мой взгляд - это ещё меньший показатель...

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

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

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



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

Проекты, для которых важна стабильность (и которые приносят деньги их владельцам, а через них и мне) хостятся на Ubuntu, ни разу никаких глюков по вине системы с ними не случалось. :-) Не знаю, почему многие выбирают Debian и тем более CentOS, с Ubuntu Server у меня всегда всё отлично было. Не только с LTS, но и с обычной с обновлениями раз в полгода.

Выгодно или нет, а так же шансы на успех - это все описывается в бизнес-плане.
Ну и пример с игростроем - детский. Посмотри как это решила Сони со своим плейстейшеном.

А все эти MongoDB можно понять на любом VPS, которые сейчас дешевле чем ящик хорошего пива. Туда и Gentoo пихнуть можно.

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

было бы интересно почитать бизнес-план вконтакте

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

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

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

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


а что именно решила Сони? идея с играми для соцсетей кстати неплохая, знаю некоторых разработчиков игр для вконтакте, хорошо живут, рад за них




большинство разработчиков не хотят становиться ещё и админами, они не хотят разбираться с линуксом в том или ином виде, им хватает своего php/python/ruby , на котором они пишут ... тем более с Gentoo :-))

Не хотят - пусть платят тем, кто хочет
Булки разработчики не пекут и сапогов не шьют
Так и тут

Ну, да, я вообщем-то согласен, это просто пример про не очень занятую хостерами нишу. Чтобы использовать MySQL разработчику надо просто купить любой хостинг, чтобы использовать CouchDB/MongoDB разработчику надо становиться админом или нанимать админа, это в любом случае выйдет дороже, да и без админа VPS как правило дороже обычного shared-хостинга.