Доброго времени суток.
В ходе более чем горячего обсуждения публикации возникла мысль описать алгоритм построения типового решения от фразы «Нам нужен сайт» до момента, когда этот сайт, уже начавший приносить прибыль, оказывается под атакой и продолжает работать.
Как показывает практика, ошибки или недосмотры на этапе выбора , базового дистрибутива, установки и настройки серверного ПО и, в немалой степени, стиль программирования, могут привести к неработоспособному состоянию практически любой проект, который в ходе демонстрации заказчику работал очень красиво и вроде как быстро.
Как уберечь себя от подобных ошибок?
Ответ прост. Нужно пригласить для проектирования профессионалов. Либо одного универсала, который знает всё и досконально, либо группу хороших специалистов, знающих очень хорошо отдельный аспект и достаточно эрудированых в смежных аспектах.
Целью данной публикации и является попытка собрать такую группу, как для коллегиального обсуждения ТЗ будущей системы, так и для выработки набора рекомендаций для оптимальных настроек всех уровней, начиная от ядра системы, заканчивая, вероятно, php.ini.
Для работы группы, если такая будет собрана, организованна группа habratest
В комментариях к данному сообщению прошу писать только конкретные предложения.
Обсуждения перенесем в группу или организуем конференцию в Jabber.
По результатам, когда и если такие появятся, найдем где опубликовать,
а для обсуждения именно результатов сделаем отдельный пост на Хабре.
Не нужно обсуждать сам процес обсуждения…
Легко сказать «начнем»... А с чего, собственно, мы начнем? А начнем мы с осмысления своих желаний. Что же мы хотим получить в результате? За фразой «сайт в Интерент» кроется весьма развесистое дерево вариантов.
И каждое ответвление скрывает за собой набор технических и технологических решений, на столько отличающихся от соседнего, что всего одна фраза, определяющая выбор того или иного решения может изменить стоимость проекта на порядки (не разы, а порядки!), либо привести к полной неработоспособности проекта, либо к кажущеся работоспособности, следствием которой будет невозможность масштабировать сервис в случае, если ценность проекта окажется, вдруг, положительной и клиент попрет косяками, а сервис загнется.
Фантазии, скажете? Да, фантазии. Но такое случалось уже, хорошо, если не с нами.
Мы предусмотрим возможность масштабирования.
Аналогично мы предусмотрим минимальную (желательно нулевую) стоимость лицензионных отчислений.
Сюда же включим иммунитет к вирусам и максимально высокую защищенность от несанкционированного доступа на уровне операционной системы.
Опытный системный администратор ни когда не попадает в ситуации, из которых хороший системный администратор с легкостью выходит. Мы постараемся обобщить тут знания опытных администраторов и организуем резервное копирование с минимальными усилиями.
А почему, собственно, LAMP?
Вспомним, что LAMP, это Linux, Apache, MySQL, PHP… А действительно ли это правильный набор?
Я не уверен. Может быть, в конце концов мы и остановимся на этом наборе. Может быть…
Но есть альтернативы, и с точки зрения обеспечения максимального быстродействия и максимальной устойчивости на минимальных конфигурациях арендованных (виртуальных) серверов может быть именно эти альтернативы и окажутся оптимальным выбором.
Ответ на справедливый вопрос «А действительно ли это то, что нам нужно» можно получить только в результате тестирования. Грамотного, профессионального тестирования, с прогнозированием результата и анализом соответствия полученного спрогнозированному.
Ну и, как было заявлено, сайт, установленный и настроенный согласно описанным рекомендациям, будет предоставлен для DDoS всеми желающими.
Я хочу подойти к вопросу правильно.
Это подразумевает:
1) Постановку задачи. Описание требований к устойчивости сайта.
2) Агрументированный выбор значений, которые так или иначе изменяются после штатной установки (опции монтирования ФС, sysctl и прочее).
3) Агрументированный выбор ПО, то есть, Nginx, Apache, Lighttpd, etc.
4) Аргументированные настройки этого ПО в разрезе ваксимально возможных нагрузок.
5) Агрументированный алгоритм защиты в разрезе возможных атак.
Не только DDoS, а и атаки на уязвимости с целью получения локального root, например.
6) Методика журналирования поведения системы. Построение графиков, оповещение о проблемах.
Автор: dkr6
