Здравствуйте, есть 2 сервера, оба средние 2core x 7gb, есть два варианта. Просто развернуть пару сайтов на одном сервере, nginx+php+mysql или второй вариант - это вынести mysql на другой сервер.
Не знаю стоит ли так делать, возможно это только сделает хуже, задержки между серверами нет, они в одном ДЦ, но всё равно я не знаю как быстро будет работать БД, которая стоит не на локалхосте.
Если вынесу БД на другой сервер работать будет, скорее всего, даже удобнее. И это очень сильно повысит безопасность, как мне кажется.
Безопасность о которой вы упомянули должна быть соблюдена в любом случае, даже если у вас всё на одном сервере крутится. Я бы реализовал следующим образом.
1-й сервер оставил с базами сайтов, а 2-й реализовал под бэкапы (или под репликацию ваших баз данных: master/slave). Так будет надёжнее. Поймите, пока у вас на сайте нет 100К посетителей в сутки это будет только тормозить загрузку сайтов (отдачу контента).
Отличный способ эффективно утилизировать оба сервера.
Если совсем заморочиться и позволяют свободные ресурсы, можно на обоих сделать сайт отказоустойчивым.
+разделяемые ресурсы
+ставим мунин например, и если чтото глючит-это видно сразу
-возрастают затраты (колокейшн, аренда айпи адреса и тд)
-коннект в БД по tcp. коннект через сокеты работает таки быстрее, хотя если у Вас не хайлоад, то разницы особой Вы не прочуствуете
landergate: в том, что база данных находится на отдельном сервере и дыра в nginx+php не позволит слить всю БД, тем более что сайта два и доступ к БД у них будет разграничен.
Александр Черных:
На малых проектах приложение не отнимает RAM у базы данных.
Мониторить можно любой сервер, любую службу, любой процесс, и не только Munin-ом, поэтому приобретать отдельный сервер под БД ради более простого мониторинга (при том, что на самом деле мониторить нужно приложение, а не ОС вокруг) расточительно.
automatik:
nginx запускается от имени www-data, поэтому всё, что сможет сделать взломщик веб-приложения (если допустить, что в нём есть дыра) - это погулять по папкам в пределах доступа www-data.
БД сливают не от её присутствия локально на сервере, а от имеющихся прав к данным.
Если БД-учётка сайта имеет чтение данных, не имеет значения, где размещён сервер - локально или на отдельном оборудовании. Чтение до этих данных всё равно есть, и взломщик их всё-равно прочитает.
Чтобы не допускать сливания данных вообще всех сайтов через один единственный, надо не физически разделять сервер БД, а логически отделять права доступа между учётками для сайтов, чтобы каждый сайт мог читать только свои таблицы.
Александр Черных: Даже средние проекты отлично живут с приложением+БД на борту, если правильно подобрать ресурсы в зависимости от потребления, чтобы оба умещались.
landergate: угу, Вы спросили - я сказал. Мои опыт и беглый просмотр ответов на Ваш вопрос говорил о том, что разделять нужно, когда придет время. Просто оно для Вас еще не настало. Удачи!
Человеку в ходе эксплуатации придется заниматься к примеру такими задачами как накат обновлений и не дай БОГ восстановлением БД из backup. Поверьте это удобнее, когда они на разных серверах. Ну и фактор управления безопасностью.
Николай Бараненко: Не имеет значения, где обновляется БД - и там и там будет временной простой, пока инфраструктура не предполагает высокую доступность.
Не имеет значения, куда восстанавливать БД из бэкапа - на тот же сервер, или на выделенный.
> Ну и фактор управления безопасностью.
В чём разница с размещением на том же сервере?
Уязвимостей безопасности приклада + БД на двоих будет больше чем у каждого в отдельности. НО если конечно это для тестовой лаборатории на вырост, то пойдет и один.
Николай Бараненко:
> Уязвимостей безопасности приклада
Уязвимость в приложении уже предполагает, что злоумышленник имеет те же права, что и приложение. Если приложение может читать свои данные в БД, то сделать это сможет и зломумышленник.
> Уязвимостей БД
Вам известны случаи в истории, когда данные сливались через уязвимости в БД, а не легитимным чтением данных с имеющейся учётки приложения?
В обоих случаях не имеет значения, где размещена БД. Если злоумышленник попал на сервер через приложение, то у него будет доступ к данным этого приложения независимо от того, где размещена БД - локально или отдельно.
безопасность это никак не повысит это раз
выносить бд надо если основной сервер не справляется и вы решили масштабироваться и это самый простой первый шаг
все ваши мысли не верны.
Средний
