Выбор ПО
Anatoly Molchanov
На мой взгляд, выбор ПО отражает сугубо личные предпочтения и возможности. Поэтому предлагается выделить необходимое количество веток LAMP, LnAPP ... и пусть каждая группа развивает свою ветку самостоятельно. Профит в том, что основные вопросы (каналы связи между узлами кластера, средства авторизации) могут решаться практически независимо от ПО.. А человек, который знает лучше всего Mango будет не так полезен в обсуждении MySQL, да и ему скучно будет..
Пример решения: несколько(N) равноправных узлов в VPN, открыты необходимые порты для предоставления сервиса, доступ по ssh только из VPN, shh порт может аварийно открываться наружу через port knocking, используется tahoe-lafs N для хранения файлов, триггерная репликация на Postgres'е для распространения обновленной информации БД, встречает запрос nginx, за ним Apache, PHP. При выходе из строя любого количества узлов <(N-1), сервис обслуживает клиента.
* видно, что пример не может конкурировать с LAMP, которые для некоторых задач гораздо предпочтительнее ввиду простоты настройки и обслуживания
Dmitriy Kruglikov
<ykd...@gmail.com> написал:
> Приветствую!
Аналогично.
> На мой взгляд, выбор ПО отражает сугубо личные предпочтения и возможности.
фантазии именно этим.
Пока на Хабре озвучили только "бложек на WP"...
Вот под него и будем проектировать...
> Поэтому предлагается выделить необходимое количество веток LAMP, LnAPP ... и
> пусть каждая группа развивает свою ветку самостоятельно.
У нас пока и одна группа не определена. Куда уж о "каждой" говорить ;(
> Профит в том, что
> основные вопросы (каналы связи между узлами кластера, средства авторизации)
> могут решаться практически независимо от ПО.. А человек, который знает лучше
> всего Mango будет не так полезен в обсуждении MySQL, да и ему скучно будет..
Давай не будем замахиваться на кластер и его узлы...
Это за пределами предложенного бюджета.
> Пример решения:
[скип]
Я не готов замахнуться на монографию по общей теории всего.
Хотя, да, много из перечисленного приходилось строить и в той или иной
мере в курсе дела.
Но !
Вижу текущую задачу в:
- подготовке пакета рекомендаций по настройке отдельно стоящего, единичного,
сервера (виртуального или выделенного), арендуемого на каком-либо
хостинге, типа Hetzner.
- настройке сервера (обещали предоставить) согласно наших рекомендаций
- обеспечении сбора статистики в ходе возможной DDoS.
- анализа успешного или провального результата и отчета перед хабрасообщством.
И не более того.
Справедливости ради, иногда появляется желание обобщить и
зафиксировать на носителях свой опыт...
Но к завтраку это проходит (с)
;)
--
Best regards,
Dmitriy Kruglikov.
Anatoly Molchanov
2. Степень отказоустойчивости (сколько произвольных машин из группы могут покинуть нас): конкурирующий (N-1), т.е. (N-1) машина может выйти из строя без потери сервиса, но должна быть возможность снизить overhead за счет снижения степени отказоустойчивости. Это позволит всей системе в случае "чего" переходить в более тормознутый, но надежный режим работы.
3. Оборудование. Важно, чтобы выбранные VPS'ы не были уникальным предложением на рынке. Более того, есть смысл сразу арендовать в нескольких разных компаниях (это обезопасит от "директор уехал", "нас продали").
4. Часто пропускают проблемы отказоустойчивости VPN (любой реализации). Это нужно учесть, не должно быть централизованных серверов.
5. и т.д.
Dmitriy Kruglikov
Мне, как и многим, не нравится тенденция к применению каких-либо рекомендаций по настройкам
без достаточного понимания как цели, так и путей достижения.
Исходя их этого, но в рамках целевой аудитории "владельцев недорогих VPS/VDS" я и хочу
пройтись по граблям и подготовить рекомендации.
С пояснением цели и путей достижения. Кратко, но без пропусков.
Особый упор сделать на экономию ресурсов и оптимальные настройки на всех уровнях.
Потому как "недорогой хостинг" подразумевает весьма скудные аппаратные ресурсы.
Кроме того, следует учитывать что для обеспечения поддержки такого сервиса
админ будет так же весьма бюджетный.
Anatoly Molchanov
ТЗ составляет заказчик. Оно обычно равноценно фразе "сделайте так, чтобы всегда все нормально работало". Выбор ПО - это часть реализации проекта. Каждый всегда будет выбирать по-своему и это правильно. Ставить нужно то, что знаешь лучше всего.. (это не мешает "узнавать" новые решения)
Если есть желание поставить банальный веб-сервер в обвесе, смысл народ собирать? есть уже тысячи рекомендаций от гуру с картинками
* Некоторые требования набросал.
** Цель определяет не исполнитель, а заказчик. Вы сами не знаете чего хотите, поэтому пока ничего не сдвинется с места.
*** вот это "бюджетный", "скудные ресурсы".. я сейчас работаю на четырех нодах https://hosting.reg.ru/vps/vps_details?plan=VPS-1-1011 (со скидкой, 158 рублей в месяц за каждую). p2p сервис, не надо про "не доступно"
вторник, 14 августа 2012 г., 13:29:21 UTC+4 пользователь Dmitriy Kruglikov написал:
Антон Пацев
Пример решения: несколько(N) равноправных узлов в VPN, открыты необходимые порты для предоставления сервиса, доступ по ssh только из VPN, shh порт может аварийно открываться наружу через port knocking, используется tahoe-lafs N для хранения файлов, триггерная репликация на Postgres'е для распространения обновленной информации БД, встречает запрос nginx, за ним Apache, PHP. При выходе из строя любого количества узлов <(N-1), сервис обслуживает клиента.