Почему не рекомендуется иметь базу данных и веб-сервер на одной машине?

Ответ 1

• Безопасность. Ваш веб-сервер живет в DMZ, доступный для общедоступного Интернета и получая недоверенные данные от анонимных пользователей. Если ваш веб-сервер подвергается риску, и вы соблюдали минимальные правила привилегий при подключении к вашей базе данных, максимальная степень воздействия - это то, что ваше приложение может выполнять через API баз данных. Если у вас есть деловой уровень между ними, у вас есть еще один шаг между вашим злоумышленником и вашими данными. Если, с другой стороны, ваша база данных находится на том же сервере, злоумышленник теперь имеет root-доступ к вашим данным и серверам.
• Масштабируемость. Сохранение вашего веб-сервера без гражданства позволяет масштабировать ваши веб-серверы горизонтально довольно легко. Очень трудно горизонтально масштабировать сервер базы данных.
• Производительность. 2 блока = 2 раза процессор, 2 раза оперативной памяти и 2 раза шпиндели для доступа к диску.

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

Ответ 2

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

Это то, что сделал StackOverflow - начиная с одиночной машины, на которой запущен IIS/SQL Server, а затем, когда она начала загружаться, второй сервер был куплен и SQL Server был перемещен на него.

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

Ответ 3

С другой стороны, ссылаясь на другой блог Scott (Watermasyck, Telligent), они обнаружили, что большинство пользователей могут ускорить работу сайтов (используя Telligent Community Server), поставив базу данных на том же компьютере, что и веб-сайт, Тем не менее, в своем случае клиента обычно db и веб-сервер являются единственными приложениями на этой машине, и веб-сайт не сильно напрягает машину. Тогда эффективность отсутствия необходимости отправлять данные по сети больше, что компенсирует повышенную нагрузку.

Ответ 4

Я бы подумал, что большой фактор будет производительностью. Оба кода веб-сервера/приложения и SQL Server будут кэшировать часто запрашиваемые данные в памяти, и вы убиваете свою производительность кэша, запустив их в одном и том же пространстве памяти.

Ответ 5

Том прав на это. Некоторые другие причины заключаются в том, что они не являются экономически эффективными и что существуют дополнительные риски для безопасности.

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

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

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

Ответ 6

Безопасность - серьезная проблема. В идеале сервер базы данных должен сидеть за брандмауэром только с портами, необходимыми для открытия доступа к данным. Ваше веб-приложение должно быть подключено к серверу базы данных с учетной записью SQL, которая имеет достаточно прав для работы приложения и не более того. Например, вы должны удалить права, разрешающие удаление объектов, и, конечно же, вы не должны подключаться к учетным записям, таким как "sa".

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

Ответ 7

Одним из факторов, который еще не упоминался, является балансировка нагрузки. Если вы начинаете думать о том, что веб-сервер и база данных являются отдельными машинами, вы оптимизируете меньшее количество поездок в сети, а также становится проще добавлять второй веб-сервер или второй движок базы данных по мере увеличения потребностей.

Ответ 8

Я из первых рук могу говорить, что часто рекомендуется размещать веб-сервер и базу данных на разных машинах. Если у вас есть приложение с интенсивным ресурсом, это может привести к тому, что циклы ЦП на машине достигнут пика, что приведет к остановке машины. Однако, если ваше приложение имеет ограниченное использование базы данных, вероятно, не будет большой проблемой, чтобы они совместно использовали сервер.

Ответ 9

Я согласен с Дэниелом Эрвикером - секретный вопрос в значительной степени испорчен.

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

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

Аргумент о том, что "остальная целостность сервера БД поддерживается", где у вас есть настройка с двумя серверами, не имеет значения, поскольку в первом сценарии каждый другой сервер базы данных, относящийся ко всем другим приложениям (если они есть), остается не затронутые, как и они, размещены в других местах.

Аналогично, к вопросу, заданному Kev ', как насчет всех других баз данных, находящихся на сервере БД? Все, что вы потеряли, это одна база данных.

• Если вы размещаете приложение и базу данных на одном сервере, вы будете размещать только базы данных на этом сервере, связанные с этим приложением. Таким образом, вы не потеряете никаких дополнительных баз данных в настройках одного сервера по сравнению с настройкой нескольких серверов.

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

Ответ 10

Это зависит от приложения и цели. Когда высокая доступность и производительность не являются критическими, неплохо не отделять БД и веб-сервер. Особенно учитывая прирост производительности - если приложение делает большой объем запросов к базе данных, значительную нагрузку на сеть можно удалить, сохранив все это в одной и той же системе, сохраняя минимальное время ответа.

Ответ 11

Ничего себе, никто не объясняет, что если вы действительно покупаете SQL-сервер на 5 тысяч долларов, вы можете использовать его больше, чем ваше веб-приложение. Если вы используете экспресс, возможно, вам все равно. Я вижу, что SQL-серверы запускают базы данных для 20-30 приложений, поэтому их размещение на веб-сервере не будет разумным.

Во-вторых, зависит от того, для кого предназначен сервер. Я работаю для финансовых компаний и правительства. Поэтому мы используем сумасшедшую боль в подходе к использованию только sprocs и ограничивающих порты от веб-сервера до SQL. Поэтому, если веб-приложение взломано. Единственное, что может сделать хакер, это вызвать sprocs, поскольку учетная запись пользователя на веб-сервере заблокирована, чтобы видеть или вызывать sprocs на БД. Итак, теперь хакер должен выяснить, как попасть в БД. Если его на веб-сервере хорошо его легко найти.

Ответ 12

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

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

Заинтересованы в том, что могут сказать другие.

Ответ 13

Я слушал этот подкаст, и это было забавно, но аргумент безопасности не имел для меня никакого смысла. Если вы поставили под угрозу сервер A, и этот сервер может получить доступ к данным на сервере B, то вы мгновенно получите доступ к данным на сервере B.

Ответ 14

Лицензии на базу данных не являются чипами и часто начисляются за каждый процессор, поэтому, разделяя ваши веб-серверы, вы можете снизить стоимость лицензий на базу данных.

Например, если у вас есть 1 сервер, который выполняет как интернет, так и базу данных, содержащую 8 процессоров, вам придется заплатить за лицензию на 8 процессоров. Однако, если у вас есть два сервера, каждый из которых имеет 4 процессора и запускает базу данных на одном сервере, вам нужно будет заплатить только за 4 процессора.

Ответ 15

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

Ответ 16

Утверждение о том, что реальное увеличение производительности, получаемое при запуске сервера базы данных на веб-сервере, является ошибочным аргументом.

Поскольку серверы баз данных берут строки запросов и возвращают наборы результатов, данные, фактически текущие от сервера данных к веб-серверу, относительно малы, но лошадиная сила, необходимая для обработки запроса и создания набора результатов, относительно велика. Оптимизация производительности в течение времени передачи данных, таким образом, оптимизируется вокруг неправильной вещи.

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

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

Если вы начинаете с малого и имеете только одну коробку, тогда хорошим способом будет использование виртуальных машин. Запуск веб-сервера и сервера данных в разных виртуальных машинах на одном хосте дает вам все преимущества отдельных ящиков за счет одной большой стоимости коробки.

Ответ 17

Операционная система - еще одно соображение. Хотя вашей базе данных могут потребоваться большие пространства памяти и, следовательно, UNIX, ваш веб-сервер, или, более конкретно, ваш сервер приложений, поскольку вы указываете только два уровня, может быть основано на .NET и поэтому требует Windows.

Ответ 18

Ok! Вот в чем дело, более безопасно устанавливать ваш сервер БД на другой компьютер и ваше приложение на веб-сервере. Затем вы подключаете свое приложение к БД с помощью веб-ссылки. Спасибо.