LAMP. От постановки задачи до старта отказоустойчивого сервера

Доброго времени суток.

В ходе более чем горячего обсуждения публикации ^[1] возникла мысль описать алгоритм построения типового решения от фразы «Нам нужен сайт» до момента, когда этот сайт, уже начавший приносить прибыль, оказывается под атакой и продолжает работать.

Как показывает практика, ошибки или недосмотры на этапе выбора хостинга ^[2], базового дистрибутива, установки и настройки серерного ПО и, в немалой степени, стиль программирования, могут привести к неработоспособному состоянию практически любой проект, который в ходе демонстрации заказчику работал очень красиво и вроде как быстро.
Как уберечь себя от подобных ошибок?
Ответ прост. Нужно пригласить для проектирования профессионалов. Либо одного универсала, который знает всё и досконально, либо группу хороших специалистов, знающих очень хорошо отдельный аспект и достаточно эрудированых в смежных аспектах.

Целью данной публикации и является попытка собрать такую группу, как для коллегиального обсуждения ТЗ будущей системы, так и для выработки набора рекомендаций для оптимальных настроек всех уровней, начиная от ядра системы, заканчивая, вероятно, php.ini.

Для работы группы, если такая будет собрана, организованна группа habratest ^[3]
В комментариях к данному сообщению прошу писать только конкретные предложения.
Обсуждения перенесем в группу или организуем конференцию в Jabber.
По результатам, когда и если такие появятся, найдем где опубликовать,
а для обсуждения именно результатов сделаем отдельный пост на Хабре.
Не нужно обсуждать сам процес обсуждения…

Легко сказать «начнем»... А с чего, собственно, мы начнем? А начнем мы с осмысления своих желаний. Что же мы хотим получить в результате? За фразой «сайт в Интерент» кроется весьма развесистое дерево вариантов.
И каждое ответвление скрывает за собой набор технических и технологических решений, на столько отличающицся от соседнего, что всего одна фраза, определяющая выбор того или иного решения может изменить стоимость проекта на порядки (не разы, а порядки!), либо привести к полной неработоспособности проекта, либо к кажущеся работоспособности, следствием которой будет невозможность масштабировать сервис в случае, если ценность проекта окажется, вдруг, положительной и клиент попрет косяками, а сервис загнется.
Фантазии, скажете? Да, фантазии. Но такое случалось уже, хорошо, если не с нами.
Мы предусмотрим возможность масштабирования.
Аналогично мы предусмотрим минимальную (желательно нулевую) стоимость лицензионных отчислений.
Сюда же включим иммунитет к вирусам и максимально высокую защищенность от несанкционированного доступа на уровне операционной системы.

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

А почему, собственно, LAMP?
Вспомним, что LAMP, это Linux, Apache, MySQL, PHP… А действительно ли это правильный набор?
Я не уверен. Может быть, в конце концов мы и остановимся на этом наборе. Может быть…
Но есть альтернативы, и с точки зрения обеспечения максимального быстродействия и максимальной устойчивости на минимальных конфигурациях арендованных (виртуальных) серверов может быть именно эти альтернативы и окажутся оптимальным выбором.

Ответ на справедливый вопрос «А действительно ли это то, что нам нужно» можно получить только в результате тестирования. Грамотного, профессионального тестирования, с прогнозированием результата и анализом соответствия полученного спрогнозированному.
Ну и, как было заявлено, сайт, установленный и настроенных согласно описанным рекомендациям, будет предоставлен для DDoS всеми желающими.

Автор: dkr6