<p>Я думаю на гугл ровняться не стоит ;-)</p><p>В случае, если у человека 3 сервера, вполне возможно, что можно заменить их на 1-N более дорогих (на первое время N=1..2) серверов и это будет даже в перспективе дешевле и надёжнее (стоимость аренды места в датацентре, скорость передачи данных и т.п.). </p><p>В случае с гуглом мы имеем совсем другие масштабы и минимум двойную исбыточность данных, совершенно иные деньги и потенциал трудовых ресурсов. </p><p> </p><p>Автору исходного письма можно посмотреть в сторону DRDB, SAN, iSCSI, возможность разнесения пользователей и их данных по серверам (если данные слабо связаны и можно их разместить в разных местах).</p><p>Относительно аппаратного балнсера... если у вас одна точка входа, то скорее всего ничто не мешает использовать DNS round robin. Возможно, даже, Linux VServer (http://www.linuxvirtualserver.org/).</p><p> </p><p>но всё зависит от объёмов... и возможно на гугл ровняться придётся рано или поздно...</p><p> </p><p>21.08.07, 21:16, Дмитрий Леоненко (dmitry.leonenko@gmail.com):<br /></p><blockquote style="border-left: 1px solid #cccccc; margin: 0pt 0pt 0pt 0.8ex; padding-left: 1em">Гм, мне кажется, или Google все таки хранит много данных и использует обыкновенные ДЕШЕВЫЕ сервера?<br />Может дело в том, как организовать так хранение данных, что бы все было хорошо, а не вкидать во все большое $$ ?<br /><br /><br /><div><span class="gmail_quote">21.08.07, <strong class="gmail_sendername">Alexey Karagodov</strong> <<a href="mailto:karagodov@gmail.com">karagodov@gmail.com</a>> написал(а):</span><blockquote style="border-left: 1px solid #cccccc; margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex"><br />на хранение данных вам придётся потратить n-дцать кбаксов на систему<br />хранения данных (без всяких апачей, давов, нгинх-ов и пр. на ней) и<br />использовать её по сети. <a href="http://www.sun.com">www.sun.com</a> например. (там же и ТТХ различных<br /><br />моделей, кто и чего и сколько может)<br />схема простая: данные - отдельно, их отдача - отдельно, их обработка -<br />отдельно. тогда будет меньше проблем с ростом.<br /><br />21.08.07, Goncharov Yuri<<a href="mailto:neo@kntele.com"><br />neo@kntele.com</a>> написал(а):<br />> Hi all. Простите, если немножко не в тему, возможно просто используя тот же nginx я смогу решить свою задачу.<br />><br />> Есть достаточно большой проэкт.<br />> 5Тб трафика в месяц, 15 миллионов хитов в день.<br /><br />><br />><br />> На данный момент проэкт расположен на 3-х серверах. Далее планируется масштабируемость за счёт наращивания числа бекендов при необходимости.<br />> Во фронтенде всё "встречает" nginx - напрямую отдаёт статику, динамика уходит с ip hash на 2 upstreamа (apache+mod_php)<br /><br />> Для того чтобы обеспечить единый source организовано NFS-connectivity, где весь контент уложен на фронтенд (т.к графические файлы<br />> занимают 90% всего проэкта) - это NFS-server, и два бекенда - NFS-клиенты.<br /><br />> На данный момент проблем нет, но я не уверен в стабильности такого NFS-connectivity ввиду того, что нагрузка постоянно растёт и боюсь, что<br />> в определённый момент начнут происходить затыки именно в NFS-схеме. Как минимум,я не имею понятия об инструменте как такую NFS-схему мониторить.<br /><br />><br />> Какие ещё есть варианты с организацией SAN при условии что:<br />><br />> 1) Над проэктом периодически работают девелоперы и заливать исправленный контент сейчас на 3 сервера, далее на n - слишком накладно.<br /><br />> 2) В проэкте предусмотрена заливка файлов (медиа) через веб, где данные должны быть сохранены в виде файла на диске. Различные варианты в стиле<br />> в блоб и в базу не подходят в виду огромного кол-ва таких файлов. Приблиз порядка миллионов файлов с общим весом в 100Гб.<br /><br />> 3) Сохранить отказоустойчивость в случае выхода одного из серверов из строя. Тут имеет ввиду что несколько позже вместо одного фронта будет два<br />> и перед ними поставится аппаратный балансер, то есть недостатки в данной схеме отказоустойчивости ещё на уровне точки входа просьба не учитывать.<br /><br />> 4) В случае выведения из строя одного из участников SAN-схемы происходит синхронизация после возвращения такого участника в "жизнь".<br />><br />> Допустим варианты с rsync не пробовал, но очень верю в том, что при миллионе файлов такое работать не будет.<br /><br />> Про MogileFS только читал, но есть много и нехороших отзывов на предмет п.4 указанного выше.<br />><br />> Жду любые советы, рекомендации, линки. Спасибо огромное заранее..<br />><br />> --<br />> Best regards<br /><br />><br />> Phone +380 44 426 8812<br />> CTO KNtelecom Ukraine Ltd.<br />> ----------------------------<br />> NEO83-RIPE<br />><br />><br /></blockquote></div><br /><br /></blockquote>