Архитектура на вырост.

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

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

Поддержу предыдущего оратора. Не нужно переусложнять работающую систему просто "чтобы было".

А вот ваше работающее приложение можно и нужно писать (или подбирать, если речь о CMS), держа в уме дальнейшую возможность адаптации творения под что-то подобное.

Вы пишете второй вконтакте или яндекс?

Какого рода и посещаемости сайт вы делаете?

По моей оценке сайт с посещаемостью до 5-10 миллионов кликов к страницам в сутки будет нормально работать на стандартной системе на мощном сервере без каких то особых заморочек.

У меня один сервер держит около 5 миллионов запросов в сутки к тяжелым страницам PHP.

Load average 0.5

Если будут тормоза, то можно будет mysql или апаче на отдельный сервер поставить.

Вопрос архитектуры большого сайта – весьма сложный и сходу на него не ответить.

Нужно, пробовать, тестировать, много думать.

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

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

Ну скажем есть потенциал до 10 млн. просмотров точно есть, больше как вложимся.

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

Ну я не сказал что пишу вконтакт же? :), а назвал адекватное число, оцененное по счетчикам конкурентов.

UnnamedUA, ну, допустим, есть еще одна разумная переходная ступень между одним сервером и кластером : одна задача - один диск (или массив).

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

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

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

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

1) Вынести отдачу статики на отдельные сервера

2) Вынести mysql на отдельные сервера. С помощью репликации mysql распределить БД на несколько серверов.

3) Вынести апач на отдельный сервер.

4) Сделать несколько фронтендов nginx которые будут проксировать на один бэкенд. Между фронтендами сделать балансировку нагрузки с помощью ДНС.

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

Вам уже всё расписали, в принципе.

Простейшие схемы на будущее:

1) Отдельный сервер баз данных, отдельный сервер с проектом. Вообще никаких проблем в реализации.

2) nginx + apache на одном сервере. На нём же прописан в nginx второй сервер как бэкенд (балансировка).

Файлы дублируются на втором сервере. Вариантов здесь несколько:

а) DRBD

б) rsync (самый простой в реализации вариант)

в) NFS и т.п.

Так же 3-й сервер используется под базы данных.