Именно так оно и обстоит. С удаленным администрированием оно так: Либо когда ты сам администришь — то гуд, или «тебя администрят» а ты об этом даже не знаешь.
Кстати, из дурацких «дыр администрирования». У меня лично в одном из проектов был случай, когда в процессе «ввода в эксплуатацию» просто сделали дамп девелоперской базы и развернули на боевом сервере… со всеми несекурными паролями. И так проработала почти год.
Плюсы двух серверов:
+ Разделение БД и PHP однозначно хорошо сказывается на производительности, поскольку БД и скрипты принципиально по-разному работают как с оперативной памятью, с процессорной мощностью, с вводом-выводом. Ты можешь их по-разному конфигурировать (т.е. на одной машине сделать упор на память+проц, а на второй на быстрый ввод-вывод).
+ Апгрейд тоже проходит независимо. Что это означает? Отпадает надобность выделять большие суммы на «апгрейд всего и сразу». Достаточно апгрейдить только то что нужно.
+ Изначально заложены возможности для дальнейшего функционального масштабирования.
Минусы:
— Больше юнитов в стойке
— Вместо одного сервера тебе придется следить за двумя
— Если тебе уже сразу известны требования к системе, которую ты проектируешь, и заранее известны потенциально «узкие места», то выбор должны диктовать именно эти требования, а не то, кто тебе что из своего личного опыта насоветует.
P.S.: Кстати, может вам интересны именно какие бывают узкие места именно в веб-приложениях подобных вашему (если опишете вкратце что проектируете). Возможно если вы сформулируете вопрос так, то получите информацию, которая будет иметь для вас намного больше практической ценности: — личный опыт людей как они с ними пытаются бороться с помощью одного или нескольких серверов.
), то возможно тебе может стоит сформулировать вопрос иначе.
Между методологией «Гугля» и рядовым высоконагруженным вебприложением лежит огромная пропасть.
Поясню в чем разница методологии. Если рубануть из розетки половину Гугловых map-reduce нод никто ничего не заметит (разве что нагрузка на остальную половину возрастет в два раза, и искать все будет медленее). Т.е. Гугль-архитектура изначатьно заточна на резервирование с запасом.
Подход типичного высоконагруженного веб-приложения (которому не хватает одного сервера): сервер под БД, сервер под отдачу статики, сервер под PHP, сервер под memcache, сервер под полнотекст, сервер под отдачу потокового контента, сервера по внешнее xmlrpc-взаимодействие и т.д… и отказ/тормоза/ступор/DDoS/технические работы любого из этих серверов приводит к неработоспособности всего сервиса (ну или существенной части его функционала). Да, мы распределили нагрузку, но вмето этого получили 4-5 точек отказа вместо одной.
Почему бы сразу не сделать «как Гугль»? Ответ прост: Метод, используемый Гуглом начинает работать от нескольких сотен серверов, и в основном попытки создать map-reduce-кластер из десятки серверов по сути экспериментаторство-баловство (с переменным успехом и эпическими результатами), где накладные расходы (а они в любой кластерной технологии очень остро существуют) не окупаются.
Эльфов, а особенно эльфиек, можно не только «одевать», но и «раздевать». Достаточно реальзовать такую фичу с каждым правильным ответом викторины «доспех» «эльфийки» становиться все прозрачнее и прозрачнее меньше в размере — успех это будет иметь, по крайней мере у определенной части аудитории. Причем, часть этой аудитории обязательно кинет ссылку своим друзьям — типа «слышь, баклан зацени фишку», а это для вас означает раскрутку (причем что ценно, по сценарию «проект сам работает на свою раскрутку»).
А вообще, если ты поподробнее опишешь задачу как ты ее представляешь в голове, возможно получишь более конкретные советы. Потому как, не бывает универсальных решений. И то что у кого-то хорошо работало легко может херово работать у тебя.
Погугли побольше инфы по кличевикам «Xen», «OpenVZ», «linux containers».
Параграфы с «откровенно-рекламными хвальбами» смело пропускай, а вот там где описываются ограничения и трудности читай внимательно и с пристрастием, думая при этом о своей системе.
Думаю прочитанной инфы (обращай внимание на плюсы и минусы) должно хватить для того, чтобы принять взвешанное решение о том как устроить архитектуру.
На что обращать внимание: Да, не забывай, что помимо того, что какое-то решение распрекрасно, как ты конкретно будешь администрировать полученную систему предлагаемыми средствами.
Также (если ты не хочешь заморачиваться с виртуализацией, хотя контейнеры это почти не виртуализация) погугли еще «cpu affinity»,«ionice»,«ulimit».
В сетевых приложениях этот чанковый аллокатор у меня как раз и показал себя с лучшей стороны «во всей красе».
Хотя, изначально, когда я его писал, это было как раз решение эффективного освобождения памяти занятого хитрыми графами с ссылающимися друг на друга элементами. А определять что граф «не нужен» очень просто — у нас не один в два указателя один на «граф» (обычно если он древовидно-образный, то это указатель на корневой элемент), а второй указатель на чанк-пул из которого выделяются элементы. Когда мы перестали работать с графом — просто говорим освободить и все!
Проблему с кодировкой mysqldump-а в 99% можно решить одним из трех способов:
* Заставить заменить все SET NAMES cp1251 на SET NAMES utf8 (или наоборот): sed -e 's#SET NAMES yyy#SET NAMES xxx#' dump.sql
* Сконвертивовать сам дамп (если вы не используете в базе blob-ов то проблем возникнуть не должно): iconv -f xxx -t yyy
* комбинация sed и iconv
После этого на выходе мы получаем то что можно лить в другую базу. Кстати, sed поможет если надо, например, произвести переименование таблиц называющихся по другому в целевой базе.
Насчет использования англицизмов, особенно технических, КАТЕГОРИЧЕСКИ НЕ СОГЛАСЕН!
«Прекрасные русские аналоги» — прекрасны лишь на первый взгляд. Не всегда очевидно, какой все-таки технический термин скрывается за этим «аналогом». Все-таки, при прочтении статьи (а мы не забываем, что Хабрахабр все-таки не сервер литературной прозы, а имеет выраженную IT тематику), у читателя, встретившего в тексте некий термин, возникает разумное желание — найти в Интернете побольше информации по данной тематите. А вот тут-то и возникает большой облом, поскольку у большинства ИТ-терминов не существует устоявшихся и четко определенных русскоязычных «аналогов».
Переводы многих теминов спорны, а некоторые вводят в заблуждение. Например, тот ужас царящий в русской терминологии связанной, например, с многопоточным (Multithreading) программированием нормальному человеку вообще нельзя читать без валидола.
Я уже не говорю про бестолковые машинние переводы (частенько пролетают на Хабре). Или, что еще хуже, потытки «высокоходожественного перевода» технических терминов. Тут даже человек хорошо знакомый с данной тематикой может просто не понять что же на самом деле имел ввиду автор.
Если я давал бы рекомендации (не требования, а рекомендации) насчет языка изложения статей, то пунктом #1 поставил бы настоятельную рекомендацию — употребил термин — написал рядом в скобочках оригинал.
Согласитесь, качество передачи информации оно намного важнее чем «тся/ться».