Слушая интервью Скотта Хансельмана с командой Stack Overflow ( части 1 и 2 ), он был непреклонен в том, что сервер SQL и сервер приложений должны находиться на разных машинах. Это просто для того, чтобы в случае взлома одного сервера обе системы были недоступны? Перевешивают ли проблемы безопасности сложность двух серверов (дополнительные расходы, выделенное сетевое соединение между ними, дополнительное обслуживание и т. Д.), Особенно для небольшого приложения, где ни одна из частей не использует слишком много ЦП или памяти? Даже с двумя серверами, когда один из них скомпрометирован, злоумышленник может нанести серьезный ущерб, либо удалив базу данных, либо изменив код приложения.
Почему это так важно, если производительность не является проблемой?
источник
Это не совсем деле значения (вы вполне можете запускать свой сайт с сетью / базой данных на одном компьютере), это просто самый простой шаг в масштабировании ..
Это именно то, что сделал StackOverflow - начиная с одной машины, на которой запущен IIS / SQL Server, затем, когда он начал сильно загружаться, был куплен второй сервер, и на него был перемещен SQL-сервер.
Если производительность не является проблемой, не тратьте деньги на покупку / обслуживание двух серверов.
источник
С другой стороны, ссылаясь на другого блоггера Скотта (Watermasyck, из Telligent), они обнаружили, что большинство пользователей могут ускорить работу веб-сайтов (с помощью сервера сообщества Telligent), разместив базу данных на том же компьютере, что и веб-сайт. Однако в случае их клиентов обычно db и веб-сервер являются единственными приложениями на этой машине, и веб-сайт не сильно нагружает машину. Кроме того, эффективность отсутствия необходимости пересылки данных по сети компенсировала возросшую нагрузку.
источник
Я думаю, что большим фактором будет производительность. И код веб-сервера / приложения, и SQL Server будут кэшировать часто запрашиваемые данные в памяти, и вы убиваете производительность своего кеша, выполняя их в одном и том же пространстве памяти.
источник
Том прав в этом. Некоторые другие причины заключаются в том, что это нерентабельно и есть дополнительные риски безопасности.
Требования к оборудованию веб-серверов отличаются от требований к серверам баз данных. Серверы баз данных работают лучше с большим объемом памяти и действительно быстрым дисковым массивом, в то время как веб-серверам требуется достаточно памяти только для кеширования файлов и частых запросов к БД (в зависимости от вашей настройки). Что касается экономической эффективности, два сервера не обязательно будут дешевле, однако соотношение производительность / стоимость должно быть выше, поскольку вам не придется конкурировать между разными приложениями за ресурсы. По этой причине вам, вероятно, придется потратить намного больше на один сервер, который обслуживает оба и предлагает производительность, эквивалентную двум специализированным.
Проблема безопасности заключается в том, что если одна машина скомпрометирована, уязвимы и веб-сервер, и база данных. С двумя серверами у вас есть передышка, поскольку второй сервер все еще будет в безопасности (по крайней мере, на время).
Кроме того, есть некоторые преимущества масштабируемости, поскольку вам, возможно, придется поддерживать только несколько серверов баз данных, которые используются множеством различных веб-приложений. Таким образом, у вас будет меньше работы по установке обновлений или исправлений и настройке производительности. Я считаю, что существуют инструменты управления сервером, облегчающие эти задачи (в случае одной машины).
источник
Безопасность - главная проблема. В идеале ваш сервер базы данных должен находиться за брандмауэром с открытыми только портами, необходимыми для доступа к данным. Ваше веб-приложение должно подключаться к серверу базы данных с учетной записью SQL, у которой достаточно прав для работы приложения, и не более того. Например, вам следует удалить права, разрешающие удаление объектов, и, безусловно, вы не должны подключаться с использованием таких учетных записей, как «sa».
В случае, если вы потеряете веб-сервер из-за взлома (т.е. при полномасштабном повышении привилегий до прав администратора), в худшем случае может быть скомпрометирована база данных вашего приложения, но не весь сервер базы данных (как это было бы в случае, если бы сервер базы данных и веб-сервер были одной машиной). Если вы зашифровали строки подключения к базе данных, а хакер недостаточно сообразителен, чтобы их расшифровать, то все, что вы потеряли, - это веб-сервер.
источник
Один фактор, о котором еще не упоминалось, - это балансировка нагрузки. Если вы начинаете думать о веб-сервере и базе данных как о разных машинах, вы оптимизируете для меньшего количества сетевых циклов, а также становится проще добавить второй веб-сервер или второе ядро базы данных по мере роста потребностей.
источник
Я могу сказать по собственному опыту, что часто бывает хорошей идеей разместить веб-сервер и базу данных на разных машинах. Если у вас есть приложение, требующее значительных ресурсов, оно может легко вызвать пиковые циклы ЦП на машине, что по существу приведет к остановке машины. Однако, если ваше приложение имеет ограниченное использование базы данных, вероятно, не будет большой проблемой, если они будут использовать общий сервер.
источник
Вау, никто не упоминает о том, что, если вы действительно покупаете SQL-сервер за 5 тысяч долларов, вы можете использовать его не только для своего веб-приложения. Если вы используете экспресс, возможно, вам все равно. Я вижу, что серверы SQL запускают базы данных для 20–30 приложений, поэтому размещение его на веб-сервере было бы неразумным.
Во-вторых, зависит от того, для кого предназначен сервер. Я работаю в финансовых компаниях и правительстве. Поэтому мы используем безумный подход к использованию только sprocs и ограничения портов с веб-сервера на SQL. Так что, если веб-приложение взломали. Единственное, что может сделать хакер, - это вызвать sprocs, поскольку учетная запись пользователя на веб-сервере заблокирована, чтобы видеть / вызывать sprocs в БД. Итак, теперь хакеру нужно выяснить, как попасть в БД. Если он находится на веб-сервере, до него легко добраться.
источник
Я согласен с Дэниелом Эрвикером - секретный вопрос в значительной степени ошибочен.
Если у вас есть единая установка с веб-сервером и только база данных для этого веб-сервера на нем, если этот веб-сервер скомпрометирован, вы потеряете и веб-сервер, и только базу данных для этого конкретного приложения.
Это точно так же, как если бы вы потеряли веб-сервер при установке с двумя серверами. Вы теряете веб-сервер и только базу данных для этого конкретного приложения.
Аргумент, что `` остальная часть целостности сервера БД сохраняется '', когда у вас есть установка с двумя серверами, не имеет значения, потому что в первом сценарии все остальные серверы базы данных, относящиеся к любому другому приложению (если таковые имеются), также остаются неизменными. - будучи, как они есть, размещены в другом месте.
Точно так же на вопрос, заданный Кевом, а как насчет всех других баз данных, находящихся на сервере БД? Все, что вы потеряли, - это одна база данных ».
Напротив, в конфигурации с двумя серверами, когда злоумышленник имел доступ к веб-серверу и через прокси-сервер, ограниченные права (в лучшем случае) на сервер базы данных, они могли подвергнуть опасности базы данных любого другого приложения, перенеся выполнять медленные запросы с интенсивным использованием памяти или максимально увеличивать доступное пространство для хранения на сервере базы данных. Разделив приложения на их собственные задачи, очень похоже на виртуализацию, вы также положительно изолируете их в целях безопасности.
источник
Это зависит от приложения и цели. Когда высокая доступность и производительность не критичны, неплохо не разделять БД и веб-сервер. Особенно с учетом прироста производительности - если приложение выполняет большое количество запросов к базе данных, можно снять значительную нагрузку на сеть, сохранив все это в одной системе, сохраняя при этом низкое время отклика.
источник
Я думаю, это потому, что эти две машины обычно нужно оптимизировать по-разному. Кроме того, я понятия не имею, мы запускаем все наши приложения с серверной базой данных на одном компьютере - если мы не видим публичных - но у нас не было проблем.
Я не могу представить, что слишком много людей заботятся о том, чтобы одна машина была скомпрометирована на обоих, поскольку веб-приложение обычно имеет почти неограниченный доступ, по крайней мере, к данным, если не к схеме внутри базы данных.
Интересно, что могут сказать другие.
источник
Я слушал этот подкаст, и это было забавно, но аргумент безопасности не имел для меня никакого смысла. Если вы скомпрометировали сервер A, и этот сервер может получить доступ к данным на сервере B, вы сразу же получите доступ к данным на сервере B.
источник
Лицензии на базы данных недешевы и часто взимаются за процессор, поэтому, разделив свои веб-серверы, вы можете снизить стоимость лицензий на базы данных.
Например, если у вас есть 1 сервер, выполняющий одновременно и веб, и базу данных, содержащую 8 ЦП, вам придется заплатить за лицензию на 8 ЦП. Однако, если у вас есть два сервера с 4 процессорами каждый и база данных работает на одном сервере, вам нужно будет заплатить только за 4 лицензии на ЦП.
источник
Дополнительную озабоченность вызывает то, что базы данных любят занимать всю доступную память и держать ее в резерве на тот случай, когда они захотят ее использовать. Вы можете принудительно ограничить объем памяти, но это может значительно замедлить доступ к данным.
источник
Утверждать, что запуск сервера базы данных на веб-сервере дает реальный выигрыш в производительности, является ошибочным аргументом.
Поскольку серверы баз данных принимают строки запроса и возвращают наборы результатов, данные, фактически передаваемые с сервера данных на веб-сервер, относительно малы, но мощность, необходимая для обработки запроса и создания набора результатов, относительно велика. Таким образом, оптимизация производительности в отношении времени передачи данных означает оптимизацию в неправильном направлении.
Что касается безопасности, то наличие сервера данных в другом компьютере, чем веб-сервер, дает преимущества. Такая установка - это еще не все, что нужно для обеспечения безопасности, но это шаг в правильном направлении.
Что касается масштабируемости, то легко и относительно дешево добавить веб-серверы и поместить их в кластер для обработки увеличенного трафика. Добавить серверы данных и кластеризовать их не так-то просто и дешево. Кроме того, веб-серверы и серверы данных имеют разные потребности в оборудовании, поэтому несколько устройств помогают с масштабируемостью.
Если вы начинаете с малого и имеете только одну коробку, то хорошим вариантом будет использование виртуальных машин. Запуск веб-сервера и сервера данных на разных виртуальных машинах на одном хосте дает вам все преимущества отдельных устройств по цене одной большой коробки.
источник
Операционная система - еще одно соображение. Хотя вашей базе данных может потребоваться больший объем памяти и, следовательно, UNIX, ваш веб-сервер - или, более конкретно, ваш сервер приложений, поскольку вы упомянули только два уровня - может быть на основе .Net и, следовательно, требовать Windows.
источник
Хорошо! Дело в том, что безопаснее установить сервер БД на другом компьютере, а приложение - на веб-сервер. Затем вы подключаете свое приложение к базе данных с помощью веб-ссылки. Спасибо.
источник