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


127

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

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

Ответы:


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

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


27
Но с двумя машинами вероятность отказа оборудования
увеличивается вдвое

4
@ TWith2Sugars - в отличие от чего?
Кев

3
Ссылка пункт 1. Если веб-уровень принадлежит владельцу, то что еще вам нужно или нужно, кроме интерфейса API приложения / базы данных? В любом случае, на этом игра окончена? Тогда все становится очень интересным с точки зрения услуг, необходимых для поддержки инфраструктуры DMZ, например, любых действующих служб AD или Microsoft?
Ноэли Данн,

4
@Noelie - у вашего веб-уровня не будет доступа, например, для резервного копирования базы данных в файл и ftp этого файла на ftp.hackers.com с помощью xp_cmdshell. Или отбросьте базу данных. Или измените значения конфигурации. и т. д.
Марк Брэкетт,

6
@kirgy - поскольку две машины работают параллельно и каждая является одной точкой отказа, общая надежность ниже; технически он не двойной (на самом деле 1 - (r1 * r2)), но достаточно близок для большой надежности и малых узлов .... В случае 0,01% это будет 0,0199%. Но для 100 узлов это будет 36,6% вместо 100%, подразумеваемых оператором удвоения.
Марк Брэкетт,

45

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

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

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


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

4
Я пришел и собирался прокомментировать то же самое. Переключить сервер БД так же просто, как изменить строку подключения (в большинстве случаев).
CitizenBane 05

Уу, мне это нравится. Кто-то думает о контексте, прежде чем предложить решение!
demisx

22

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


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

@MattK - а что, если у вас большой объем памяти? У нас есть приложение, в котором каждый клиент имеет свою собственную базу данных, поэтому и базу данных, и веб-серверы можно очень легко масштабировать по горизонтали. Учитывая, что у нас больше памяти, чем используемого диска (64 ГБ против ~ 40 ГБ), не лучше ли для повышения производительности хранить все это на одном компьютере?
Beep beep

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

15

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


12
Что делать, если у вас небольшая база данных, но с тоннами памяти? Разве стоимость прохождения по сети для каждого обращения к базе данных, особенно если их много, не перевешивает преимущества?
Beep beep

1
@Tom Ritter Хотя производительность вызывает беспокойство (согласно этому ответу и пункту 3 в ответе Марка Брэкетта), я знаю, что некоторые люди (включая меня), вероятно, сэкономят деньги, НЕ получая отдельный сервер БД в БОЛЬШЕ ЦП / ОЗУ / и т.п. на одном-единственном сервере, который его заменил. Так что это нужно учитывать. Что касается разделенной памяти, IIS и SQL можно настроить с учетом их конкуренции за ресурсы. Лично для меня "ударом" был балл №1 Марка ... безопасность. Мне нравится мысль об ограниченном доступе скомпрометированного веб-сервера к отдельному серверу БД.
Дилан - INNO Software

@Tom, Вы всегда можете разделить пространство памяти на два отдельных блока. Половина для сервера и половина для базы данных.
Pacerier

15

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

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

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

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


2
Если вы используете что-либо, кроме SP, то ваш веб-сервер, вероятно, в любом случае имеет полный доступ к данным в вашей базе данных
Джордж Мауэр

Почему это не рентабельно? Пожалуйста уточни.
Роберт Джеппесен,

Роберт I расширил это и добавил несколько комментариев по масштабируемости и обслуживанию.
Dana the Sane

9

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

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


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

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

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

@Earwicker - как насчет всех остальных баз данных, находящихся на сервере БД? Все, что вы потеряли, - это одна база данных.
Кев

8
Помимо Даниэля, вы упускаете ОГРОМНОЕ очко. Речь идет не о резервной копии базы данных, а о скомпрометированных данных. Согласны ли ваши клиенты, что «Хакер украл все ваши данные о клиентах и ​​продажах, но не волнуйтесь, у меня есть резервная копия». :)
Дилан - INNO Software

9

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


6

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


6

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

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


5

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

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

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

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

Точно так же на вопрос, заданный Кевом, а как насчет всех других баз данных, находящихся на сервере БД? Все, что вы потеряли, - это одна база данных ».

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

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


4

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


2

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

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

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


1
Джордж, я думаю, вам следует обратиться к ответу Марка Брэкетта. Безопасность вашего веб-сервера для базы данных НЕ будет такой же, как если бы сервер был отдельным. В частности, «локальный диск» не будет доступен. Кроме того, если бы был взломан только один веб-сайт (из многих), они, скорее всего, только скомпрометировали доступ к базе данных ЭТОГО САЙТА (если вы не используете слишком сильного пользователя для этой строки подключения). Есть бесчисленное множество других сценариев, я просто не думаю, что здесь место для комментариев.
Дилан - INNO Software

2

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


Не правда. У вас есть доступ к любым данным или привилегиям, которые были у Box A для Box B. В безопасной настройке это означало бы, что у вас самый высокий уровень доступа к БД, который имеет приложение в Box A. Однако у вас нет прав доступа к базе данных или root в ОС Box B.
Марк Брэкетт,

2
«У вас есть доступ к любым данным или привилегиям, которые были у Box A для Box B» - это то, что я имел в виду под «вы мгновенно получаете доступ к данным на сервере B». Если бы СУБД была в блоке A, а блока B не было, какая разница? NB. в любом случае мы предполагаем, что вы уже взломали ящик A.
Дэниел Эрвикер,

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

1
А в конфигурации с одним ящиком, если этот ящик будет скомпрометирован, вы потеряете тот ящик, который включает в себя БД. Какая разница?
Дэниел Эрвикер,

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

2

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

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


Объясните, пожалуйста, как это дает экономию.
Джон Сондерс,

1
Джон - он говорит, что для получения производительности, эквивалентной 2 машинам, вам нужно удвоить количество ядер, что удвоит затраты на лицензирование SQL Server. Зачем платить дополнительно 10-20 тысяч долларов за SQL Server, если все, что вы получаете, - это та же производительность, что и при использовании двух машин.
гудок

Истина только в том случае, если производительность / использование ресурсов (например, ЦП) определяется серверами приложений, а не сервером базы данных. если db нужно 8 процессоров, это не сработает.
Андреас Дитрих

1

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


-1

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

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

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

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

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


1
Первоначальный вопрос задавался о серверах приложений, не обязательно общедоступных веб-серверах с выходом в Интернет.
João Bragança

-2

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


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

Извините, память была предназначена в качестве примера причины необходимости развертывания для разделения ОС. Другие причины включают: производительность, безопасность, корпоративные стандарты / лицензирование, поддержку поставщиков и т. Д.
Крис Ноу,

-6

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


3
почему это безопаснее?
Брайан Чен
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.