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

прослушивание интервью Скотта Хансельмана с командой переполнения стека (часть 1 и 2), Он был непреклонен в том, что SQL server и сервер приложений должны быть на разных машинах. Это просто чтобы убедиться, что если один сервер скомпрометирован, обе системы недоступны? Проблемы безопасности перевешивают сложность двух серверов (дополнительная стоимость, выделенное сетевое соединение между ними, большее обслуживание и т. д.), особенно для небольшого применения, где ни одна часть не использует слишком много процессора или памяти? Даже с двумя серверами, когда один сервер скомпрометирован, злоумышленник может нанести серьезный ущерб, либо удалив базу данных, либо испортив код приложения.

Почему это так важно, если производительность не является проблемой?

18 ответов


  1. безопасность. Ваш веб-сервер живет в DMZ, доступен для общедоступного интернета и принимает ненадежные данные от анонимных пользователей. Если ваш веб-сервер скомпрометирован, и вы следовали правилам наименьших привилегий при подключении к вашей БД, максимальная экспозиция-это то, что ваше приложение может сделать через API базы данных. Если у вас есть бизнес-уровень между ними, у вас есть еще один шаг между вашим злоумышленником и вашими данными. Если, с другой стороны, ваша база данных находится на том же сервере, злоумышленник сейчас имеет корневой доступ к вашим данным и сервера.
  2. масштабируемость. Сохранение состояния веб-сервера позволяет масштабировать веб-серверы по горизонтали довольно легко. Это очень трудно горизонтально масштабировать сервер базы данных.
  3. производительность. 2 коробки = 2 раза CPU, 2 раза ОЗУ и 2 раза шпиндели для доступа к диску.

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


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

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

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


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


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


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

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

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

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


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

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


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


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


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

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

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

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

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

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

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


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

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


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


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

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

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


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


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

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


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


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

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

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

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

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


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


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