Однажды я слушал Hanselminutes и возник этот вопрос. При каких обстоятельствах нужно отделять данные от кода? Например, в одной из систем, над которыми я работал, БД находится в том же ящике, что и сервер веб-контента. По другому сценарию мы их разделили. Что лучше, почему ты так себя чувствуешь?
Лично я считаю, что разлука - это хорошо, если ты можешь себе это позволить.
Данные лучше защищены от взлома. Разделение позволяет лучше контролировать отказоустойчивость. Разделение позволяет лучше управлять трафиком и балансировать его нагрузку.
Когда это действительно становится проблемой, так это со временем доступа к данным. Задержка на коробке, когда они оба вместе, значительно уменьшена по сравнению с сетью.
Что ты думаешь?
Первая мысль, которая пришла мне в голову, заключалась в том, чтобы не перерабатывать решение.
Все в одной коробке - это нормально. Всемогущий Stack Overflow тоже начался.
Когда у вас есть достаточный спрос (и ресурсы), чтобы оправдать несколько коробок, сделайте это. Создание идеальной настройки произойдет не с первого раза.
Храните отличные резервные копии независимо от того, что и как вы настроили для быстрого восстановления и восстановления. Реплицируйте свою базу данных за пределами площадки, чтобы вы могли перестроить и восстановить ее где угодно (в облаке, на других хостах и т. Д.)
Удачи!
По крайней мере, очень плохая идея. Раньше у меня была установка, в которой на одном сервере были Apache + MySQL, и средняя загрузка регулярно превышала 10, и страницы загружались бесконечно. Мы разделили обе службы и поместили MySQL на меньший сервер. Оба сервера никогда не превысят 0,35 средней нагрузки.
Подсчитайте ... Размещение веб-сервера + сервера БД на одном сервере - большая потеря.
У Эвана тоже есть хорошая точка зрения. Объединение вещей в машину, как правило, приводит к множеству сокращений, которые значительно затрудняют масштабирование. Одна служба = одна ОС - хорошее практическое правило (можно было бы сказать, что одна служба = одна машина, но теперь есть виртуализация).
Есть несколько причин, по которым вам следует рассмотреть возможность разделения базы данных и веб-сервера, и некоторые из них повторяют то, что уже упоминалось.
Во-первых, это потенциальная проблема с производительностью. Обычно сервер базы данных любит память. Чем больше памяти он может выделить для кэширования данных, тем меньше доступа требуется для чтения с диска. Так что в наличии памяти есть преимущество. В результате может возникнуть проблема нехватки памяти между веб-сервером и сервером базы данных. С учетом сказанного, существует множество случаев, когда серверы баз данных работают на одном компьютере с веб-сервером, например, с MySQL или SQL Server Express или даже с полнофункциональным SQL Server с SQL Server 2005 Reporting Services.
Во-вторых, есть случай, когда ваше приложение может использовать некоторые, но не все данные. Это особенно верно, если внутренние системы тоже касаются базы данных. Это маловероятный сценарий в среде веб-хостинга, и я предполагаю, что вы смотрите на свои теги. Но в этом случае вы можете ограничить доступ веб-сервера к базе данных только тем, что необходимо. Да, если веб-сервер скомпрометирован, они могут получить этот доступ, но если это ограниченный набор разрешений, они не могут получить все. Разместите его на одном веб-сервере, и это совсем другая история.
В-третьих, вы можете понять, скомпрометирован ли ваш веб-сервер, просмотрев сетевой трафик между веб-сервером и сервером базы данных с помощью IDS / IPS. Например, если мы говорим о SQL Server и xp_cmdshell отправляется на сервер базы данных, или sp_configure, это должно сообщить IDS / IPS, что что-то не так. И это дает вам немедленное предупреждение о взломе веб-сервера.
В-четвертых, разделение обязанностей. Если у вас есть люди, ответственные за развертывание веб-приложения, им, вероятно, для этого потребуются расширенные права на веб-сервер. Какие права зависят от того, что вы делаете, от какой ОС, от какого веб-сервера и т. Д., Но вы поняли. Если у этих людей не должно быть доступа ко всему, что находится на сервере базы данных, а обновления на сервере базы данных обрабатываются другим набором людей (например, администраторами баз данных), они могут лучше защитить компанию, используя другие серверы.
С точки зрения безопасности это должно быть на отдельных коробках. Однако в зависимости от бюджета это должно быть бизнес-решением, принимать риск или нет.
Это почему? Во-первых, лучшие практики рекомендуют:
Если ваша база данных находится на отдельной машине, для ее атаки потребуется дополнительный шаг. Если вы будете тщательно следить за защитой, веб-сервер не сможет получить доступ к чему-либо еще в поле db, кроме db (то есть без оболочки, без запущенных сценариев и т. Д.). Вот почему брандмауэр хорош и для внутреннего контроля.
Если вы действительно хорошо делаете безопасность, ваш пользователь web-2-db будет иметь минимальные привилегии на базе данных, имея возможность доступа / изменения только того, что ему действительно нужно (то есть без таблицы отбрасывания и т. Д.). Забавно, как часто мы видим GRANT * в базе данных для пользователя, которому нужно всего лишь выбрать и обновить из нескольких таблиц.
Таким образом, то, что многие люди запускают db + веб-сервер + почтовый сервер + DNS в одном компьютере, не означает, что это лучшее решение безопасности, это просто приемлемый риск, основанный на системе $$.
Следует иметь в виду одну важную вещь: когда вы переходите с одной машины на две, ваши шансы простоя удваиваются - то есть, если ваш сайт зависит от работы БД. Если для вас важно время безотказной работы, возможно, вы смотрите на 4 (или более) сервера - и тогда вы золотой.
Я не думаю, что вам нужно беспокоиться о скорости связи БД с веб-сервером. Мощность процессора, которую вы получаете, добавляя машину, ускорит сами запросы к БД, а передача между серверами даже при 100 МБ должна быть незначительной по сравнению со скоростью, с которой вы можете серверить веб-страницы в реальном времени.
Я не думаю, что безопасность значительно лучше с отдельным ящиком. Если злоумышленник скомпрометирует ящик, который выполняет веб-обслуживание, это, вероятно, приведет к компрометации базы данных в любом случае. Аргументы аварийного переключения и балансировки нагрузки / масштабируемости намного лучше.
Но если у вас есть только один веб-ящик, я определенно предпочел бы хранить данные в одном и том же поле.
Если у них есть доступ к вашей веб-машине, они могут вытащить детали базы данных из ваших файлов конфигурации, загрузить оболочку php и выгрузить данные оттуда. Одним из преимуществ безопасности является наличие более одной БД на одном компьютере.
Однако он позволяет распределить нагрузку, и, если вам нужно сделать это для повышения производительности, это хорошо, если у вас быстрое соединение, как указано.
Если вас беспокоит избыточность, то было бы хорошо разместить все данные на одном устройстве, а резервную копию - на другом.
Я согласен, разлука лучше, если ее можно себе позволить.
Если устройство может справиться с нагрузкой на ЦП / ОЗУ, то их размещение в одном устройстве может быть лучше по соображениям производительности, поскольку не будет сетевой задержки между веб-сервером и сервером базы данных.
У меня нет однозначного мнения относительно другого. Тем не менее, если вы планируете «масштабировать», вы можете подумать о том, чтобы сделать веб-сервер (-ы) как можно более не имеющими состояния, чтобы обеспечить масштабирование без изменения архитектуры проекта.
Если у вас небольшая, относительно статическая база данных, к которой часто обращаются, то ее хранение на том же сервере, что и веб-сервер, может быть полезным (поскольку вы воспользуетесь преимуществами кэширования данных в памяти). Однако для любых других сценариев лучше всего разделить две роли, если вы можете позволить себе дополнительно 1-2 тысячи долларов за другой сервер.
Я думаю, что разделение базы данных и веб-сервера на разные машины может добавить злоумышленнику еще один слой, но очень тонкий.
Если вы хотите «заманить» злоумышленников таким образом, вы можете использовать обратный прокси или веб-кеш на отдельной машине. Злоумышленник пойдет на эту машину и не найдет ни данных, ни подробностей о том, как добраться до машины с базой данных. На обратном прокси-сервере будет определен только веб-сервер, который может быть заблокирован, кроме порта, на котором он обслуживает веб-страницы.
Безопасность: прокси-сервер может обеспечить дополнительный уровень защиты, отделяя или маскируя тип сервера, который находится за обратным прокси. Эта конфигурация может защитить серверы дальше по цепочке - в основном за счет обфускации.