Вопрос адресован к профессионалам, поэтому людям не имеющим реального опыта просьба не офтопить.
Итак суть проблемы. Создаю рекламную систему: банеры, объявления. Предполагаются очень большие нагрузки на БД, т.к. будет индексация площадок, вывод материалов и подсчёт статистики. Реализую всё на связке php5 + MySQL5. Вопрос такой, как сбалансировать систему, может есть конкретные примеры как сделать связку из нескольких выделенных серверов, что не было потери данных при пиковых нагрузках. Ориентировочно предполагается до 100000000 обращение к БД в сутки. Очень нужны конкретные примеры физического разделения back-end и front-end, создание кластеров БД с возможностью безболезненного наращивания ресурсов. Буду признателен за любую информацию по теме.

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

Да, насчет связи между ур.2 и ур.3 - вроде одна контора, для которой мы делали софт, линковала это на пачке firewire шлангов, но я, честно говоря, так и не понял, почему именно так. Возможно, чего-то не знаю.

MuToGeN, я правильно понял? на первый уровень можно поставить nginx в качестве прокси и определённый статический контент хранить в кеше на нём. Далее, если можете, проясните вопрос, потому что пока я как-то плаваю в нём. К примеру на 2 уровне у нас 3 сервера для back-end(следовательно на три машины ставится один и тот-же скрипт), а на 3 уровне 5 машин образуют кластер БД. Поправте меня, если я что-то понимаю не правильно. 

akazed, извиняюсь, был пьян, посему мысль изложил непонятно. По пунктам:
1 уровень - легковесный веб-сервер. Что делает - раздает статический контент, запросы на динамику передает на 2й уровень, иногда проверяя, кто на 2м уровне сильно загружен, а кто отдыхает.
2 уровень - берет данные с 3го уровня, обрабатывает их, передает на 1й.
3 уровень - источник данных. Тут надо иметь в виду то, что он не должен быть чем-то большим, чем просто источником данных, т.е. не перекладывать на него задачи 2го уровня.
При таком подходе есть огромный плюс - можно без всяких хитрых средств следить за нагрузкой и наращивать аппаратные ресурсы в случае необходимости. Наращивать обычно приходится только 2й уровень.

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

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

akazed, все что накопаешь выкладывай сюда. Очень полезный материал.

Вот нашёл наглядный пример реализации 3-х уровневой системы
Пример построения высоконагруженной системы на основе открытого решения

Появился новый вопрос, на который я пока не могу найти ответа.
Сетевой админ предложил использовать MySQL NDBcluster. Может у кого есть пример реализации php скрипта с MySQL сluster. Я с такой задачей сталкиваюсь впервые. И ещё, а стоит ли вообще применять MySQL NDBcluster для создания отказоустойчивой и масштабируемой системы, может лучше использовать репликацию и InnoDB?

Проведя вечер за исследованием вопроса и материалов конференции highload++ 2008 пришол к выводу, что для построения хорошей системы с лёгкой горизонтальной масштабируемостью, репликация не подходит абсолютно. 
ИМХО, хабре прогеры сильно прогадали, сделав распределение нагрузок между серверами БД на php.

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

А насчет InnoDB vs NDBCluster - это подбирается эмперически. Все зависит от конечной задачи. Вот Аструм Интертеинмент, к примеру, который держит ТаймЗиро и многие другие проекты, связанные с критичными нагрузками, пользуют в основном NDBCluster.

Сравнивая InnoDB vs NDBCluster, пришол к выводу, что NDBCluster работает быстрее и более устойчив к нагрузкам. Но часть задачи при работе с запросами приходится перекладывать на php. Однако это не создаёт проблем, если изначально использовать оптимально сконфигурированный физ. сервер. Хочу сразу уточнить, что для работы связки php + MySQL cluster нужно как минимум 3 машины. Хотя сейчас хочу поизвращаться и попробовать всё поставить на одну под FreeBSD 7.0