Архитектура проекта. Правильно так?

php скриптом

Больше никто так не делает?

Ватсон, всё элементарно. Так как картинки лежат только на VDS, то и 'оттуда' - это с VDS!

На vds лежит только mysql как я понял

Я думаю правильнее будет взять два вдса у одного хостера, на одном положить mysql с файлами, на другом движки для приложений.

нет, первая фраза - "БД и картинки сайта лежат на вдс сервере." Mysql на отдельном сервере это может быть как раз и нормально, хотя shared + VDS это как-то чудно.

Pilat добавил 06.08.2009 в 15:23

Обычная архитектура -

клиент <--> nginx <--> apache <--> mysql

а что получится, если картинки на другом сервере? Как их передать клиенту? Писать для сайта один адрес (домен), для картинок другой - ну так делают и криминала в этом нет для не-SSL сайтов (SSL браузер будет возмущаться), mysql на отдельном сервере многие хостеры делают - тоже не криминал. Но какой смысл запускать скрипты на shared, если у Вас есть выделенный сервер? Если в том же датацентре, то прокатит, всё зависит от связи между серверами, если в другом, то работать не будет, - то обрывы, то скорость низкая, то латентность, - что-то обязательно настигнет.

и картинки тоже

Без понятия о задачи думать о ее реализации - глупо

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

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

Так всеже стоит перенести и сайт на вдс? Какие плюсы от этого?

Мои 5 копеек.

Насколько я понимаю, сейчас проще обеспечить работу канала и сервера, чем делать распределенную архитектуру, нацеленную на надежность, поэтому, ВСЕ складывают на один сервер (для начала можно VDS). Разделять начинают только после того, как производительности одной физической железки начинает не хватать (например, выносят базу на отдельную машину). Для того, чтобы в случае краха машины все можно было быстро починить (часа 1.5-3) делают бакап содержимого сервера и держат квалифицированного админа на расстоянии телефонного звонка (не ICQ, а телефона). И плюс берут VDS у провайдера, который его починит в течение часа при крахе физической машины или арендуют физический сервер, который провайдер тоже быстро заменит (далее накатываем бакап) (т.е. в случае колокейшина нужно держать две своих машины, поэтому, проще аренда).

Когда у меня провайдеры ребутнули машину по питанию и сетевуха не встала, я тупо развернул на второй машине в chroot архив рабочей системы вместе с IP адресами первой машины. Владельцы сайта, который активно раскручивается успели отзвониться, остальные даже не заметили. Потом починили рабочую машину и я все вернул обратно. Это чрезвычайная ситуация, к которой нужно быть готовым, но не надо на этом заморачиваться. Такое бывает раз в несколько лет.

Т.е. никакой распределенки для обеспечения надежности (стоимость приложения явно выйдет из размера бюджета). Хотя, если потеря данных за пол дня п простой в пару часов дороже аренды второй машины - можно реализовать полугорячее резервирование через хитбит и DRDB, но при этом нужно очень сильно задуматься, т.к. глюки в системе определения работоспособности машины могут привести к уменшению надежности (например мониторинг работоспособности системы определит недоступность рабочей машины и положит ее, переведя запросы на резервную, а на самом деле между ними на короткое время пропал линк).

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

Итого, мои рекомендации - запихать все на одну машину или VDS. Хоститься у вменяемого провайдера, который сумеет заменить железо достаточно быстро. Иметь бакап и нормального сисадмина (не обязательно постоянного, т.к. достаточно настроить бакап и следить, что он работает). Следить за нагрузкой на сервере и когда это необходимо заниматься оптимизацией критических скриптов. При таком раскладе программирование системы - самое обычное, при катастрофе теряются данные с последнего бакапа (обычно делается ночью, чаще не стоит, т.к. диск будет сильно грузиться в течение бакапа).

Короче - стандартный вариант.

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

И еще добавлю - при выносе mysql на отдельный сервер очень часто забивается канал, по этому лучше всего соеденить кроссом гигабитные интерфейсы и сделать бондинг