Может ли сервер баз данных и web сервер размещаться на одном компьютере
Слушая интервью Скотта Хансельмана с командой Stack Overflow ( части 1 и 2 ), он был непреклонен в том, что сервер SQL и сервер приложений должны находиться на разных машинах. Это просто для того, чтобы в случае взлома одного сервера обе системы были недоступны? Перевешивают ли проблемы безопасности сложность двух серверов (дополнительные расходы, выделенное сетевое соединение между ними, дополнительное обслуживание и т. Д.), Особенно для небольшого приложения, где ни одна из частей не использует слишком много ЦП или памяти? Даже с двумя серверами, когда один из них скомпрометирован, злоумышленник может нанести серьезный ущерб, удалив базу данных или изменив код приложения.
Почему это так важно, если производительность не является проблемой?
Я считаю, что есть одна проблема, которая полностью опущена во всей этой ветке, и вопрос, который в значительной степени отменяет эту рекомендацию. Что делать, если вы получаете доступ к учетным данным базы данных, но не к серверу. Если база данных и приложение размещены на одном компьютере, вы можете запретить любой внешний доступ к базе данных, и поэтому только учетные данные базы данных не предоставляют вам никакого доступа, для этого вам понадобится доступ к серверу. И это на одну проблему безопасности меньше, если вы спросите меня.
- Безопасность. Ваш веб-сервер находится в демилитаризованной зоне, доступной для общего доступа в Интернет и принимающей ненадежные данные от анонимных пользователей. Если ваш веб-сервер скомпрометирован, и вы следовали правилам минимальных привилегий при подключении к своей БД, максимальное воздействие - это то, что ваше приложение может делать через API базы данных. Если у вас есть бизнес-уровень между ними, у вас есть еще один шаг между злоумышленником и вашими данными. Если, с другой стороны, ваша база данных находится на том же сервере, злоумышленник теперь имеет root-доступ к вашим данным и серверу.
- Масштабируемость. Сохранение состояния вашего веб-сервера без учета состояния позволяет вам легко масштабировать веб-серверы по горизонтали. Это очень трудно горизонтально масштабировать сервер базы данных.
- Представление. 2 коробки = в 2 раза больше ЦП, в 2 раза больше ОЗУ и в 2 раза больше шпинделей для доступа к диску.
При всем вышесказанном я, безусловно, вижу разумные случаи, когда ни один из этих пунктов не имеет значения.
Ref. Пункт 1. Если веб-уровень принадлежит владельцу, то что еще вам нужно или нужно, кроме интерфейса API приложения / базы данных? Конечно, на этом игра все равно окончена? Тогда все становится очень интересным с точки зрения услуг, необходимых для поддержки инфраструктуры DMZ, например, любых действующих служб AD или Microsoft?
@kirgy - поскольку две машины работают параллельно и каждая является одной точкой отказа, общая надежность ниже; технически он не двойной (на самом деле 1 - (r1 * r2)), но достаточно близок для большой надежности и малых узлов . В случае 0,01% это будет 0,0199%. Но для 100 узлов это будет 36,6% вместо 100%, подразумеваемых оператором удвоения.
На самом деле это не имеет значения (вы вполне можете запустить свой сайт с сетью / базой данных на том же компьютере), это просто самый простой шаг в масштабировании ..
Это именно то, что сделал StackOverflow - начиная с одной машины, на которой был запущен IIS / SQL Server, затем, когда он начал сильно загружаться, был куплен второй сервер, и на него был перемещен SQL-сервер.
Если производительность не является проблемой, не тратьте деньги на покупку / обслуживание двух серверов.
Я согласен, это можно сделать при низкой нагрузке . по мере увеличения нагрузки их легко разделить на 2 или более машины.
Я пришел и собирался прокомментировать то же самое. Переключить сервер БД так же просто, как изменить строку подключения (в большинстве случаев).
С другой стороны, обращаясь к другому блоггеру Скотту (Watermasyck, из Telligent), они обнаружили, что большинство пользователей могут ускорить работу веб-сайтов (с помощью сервера сообщества Telligent), разместив базу данных на том же компьютере, что и веб-сайт. Однако в случае их клиента обычно db и веб-сервер являются единственными приложениями на этой машине, и веб-сайт не так сильно нагружает машину. Затем эффективность отсутствия необходимости отправлять данные по сети больше компенсировала возросшую нагрузку.
. до тех пор, пока одновременное использование не увеличится и серверу db не потребуется больше памяти для эффективного использования буферов и кешей. Как только серверам веб-приложений и баз данных требуется больше памяти, чем они могут совместно использовать в одном устройстве, подкачка и дисковый ввод-вывод увеличиваются, а производительность снижается.
@MattK - а что, если у вас большой объем памяти? У нас есть приложение, в котором каждый клиент имеет свою собственную базу данных, поэтому и базу данных, и веб-серверы можно очень легко масштабировать по горизонтали. Учитывая, что у нас больше памяти, чем используемого диска (64 ГБ против ~ 40 ГБ), не лучше ли для повышения производительности хранить все это на одном компьютере?
Если ваш рабочий набор умещается в памяти, вы можете не увидеть ни одной из упомянутых мною проблем с производительностью. Чаще на серверах больше диска, чем ОЗУ, но похоже, что в вашем случае у вас есть базы данных, которые полностью умещаются в ОЗУ - при условии, что приложения на общем сервере не потребляют ее слишком много.
Том прав в этом. Некоторые другие причины заключаются в том, что это нерентабельно и что есть дополнительные риски безопасности.
Требования к оборудованию веб-серверов отличаются от требований к серверам баз данных. Серверы баз данных работают лучше с большим объемом памяти и действительно быстрым дисковым массивом, в то время как веб-серверам требуется достаточно памяти только для кеширования файлов и частых запросов к БД (в зависимости от вашей настройки). Что касается экономической эффективности, два сервера не обязательно будут дешевле, однако соотношение производительность / стоимость должно быть выше, поскольку вам не придется конкурировать между разными приложениями за ресурсы. По этой причине вам, вероятно, придется потратить намного больше на один сервер, который обслуживает оба и предлагает производительность, эквивалентную двум специализированным.
Проблема безопасности заключается в том, что если одна машина скомпрометирована, уязвимы и веб-сервер, и база данных. С двумя серверами у вас есть передышка, так как второй сервер все еще будет в безопасности (по крайней мере, на некоторое время).
Кроме того, есть некоторые преимущества масштабируемости, поскольку вам, возможно, придется поддерживать только несколько серверов баз данных, которые используются множеством различных веб-приложений. Таким образом, у вас будет меньше работы по установке обновлений или исправлений и настройке производительности. Я считаю, что существуют инструменты управления сервером, облегчающие эти задачи (в случае одной машины).
прослушивание интервью Скотта Хансельмана с командой переполнения стека (часть 1 и 2), Он был непреклонен в том, что SQL server и сервер приложений должны быть на разных машинах. Это просто чтобы убедиться, что если один сервер скомпрометирован, обе системы недоступны? Проблемы безопасности перевешивают сложность двух серверов (дополнительная стоимость, выделенное сетевое соединение между ними, большее обслуживание и т. д.), особенно для небольшого применения, где ни одна часть не использует слишком много процессора или памяти? Даже с двумя серверами, когда один сервер скомпрометирован, злоумышленник может нанести серьезный ущерб, либо удалив базу данных, либо испортив код приложения.
Почему это так важно, если производительность не является проблемой?
- безопасность. Ваш веб-сервер живет в DMZ, доступен для общедоступного интернета и принимает ненадежные данные от анонимных пользователей. Если ваш веб-сервер скомпрометирован, и вы следовали правилам наименьших привилегий при подключении к вашей БД, максимальная экспозиция-это то, что ваше приложение может сделать через API базы данных. Если у вас есть бизнес-уровень между ними, у вас есть еще один шаг между вашим злоумышленником и вашими данными. Если, с другой стороны, ваша база данных находится на том же сервере, злоумышленник сейчас имеет корневой доступ к вашим данным и сервера.
- масштабируемость. Сохранение состояния веб-сервера позволяет масштабировать веб-серверы по горизонтали довольно легко. Это очень трудно горизонтально масштабировать сервер базы данных.
- производительность. 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 на одном хосте дает вам все преимущества отдельных ящиков за счет одной большой цены коробки.
ОК! Дело в том, что более безопасно иметь сервер БД, установленный на другой машине, и Ваше приложение на веб-сервере. Затем вы подключаете приложение к БД с помощью веб-ссылки. Спасибо.
Я где-то читал, что веб-приложение состоит из веб-сервера, сервера приложений и сервера баз данных. В чем разница между этими тремя ?
Веб-Сервер -
сервер, на котором размещен ваш сайт. На этом сервере будут установлены веб-серверы, такие как IIS, apache и т. д.
Сервер Приложений -
сервер, на котором созданы приложения, использующие вашу базу данных, веб-службу и т. д. На этом сервере приложений будет размещен бизнес-уровень (обернутый веб-службами), запланированные задания, службы windows и т. д.
Сервер Баз Данных -
на сервере баз данных будет размещена одна или несколько баз данных, таких как Oracle, Sql Server, MySql и т. д.
Если вы имеете в виду htdocs тогда это веб-сервер. Базы данных, которую вы используете должна быть установлена на другом сервере, который является сервер базы данных. Сервер приложений также может быть установлен на том же компьютере веб-сервера.
Это часто сбивает с толку.
во-первых - "сервер" может относиться к физической вещи (компьютер) или логической вещи (часть программного обеспечения).
программное обеспечение Web, application и database server может работать на одном физическом сервере или распространяться на нескольких физических компьютерах. Большинство крупных веб-сайтов имеют несколько компьютеров; большинство" потребительских " хостинговых пакетов работают на одном ящике.
логическое разделение выглядит следующим образом.
программное обеспечение сервера баз данных, где приложение хранит свою структурированную информацию. Как правило, это означает пользовательское программное обеспечение, которое позволяет сервер приложений, чтобы задать такие вопросы, как "сколько элементов пользователь x имеет в своей корзине?", используя язык программирования. Примерами являются MySQL, SQL Server, Oracle (все "реляционные базы данных") и MongoDB, Redis и CouchDB (решения"NoSQL").
программное обеспечение базы данных может работать на той же физической машине, что и веб-сервер, но обычно это первое, что размещается на отдельном физическом оборудовании, когда сайт должен масштабироваться.
Я только что узнал, что могу написать действительно простой веб-сервер использование Python. У меня уже есть веб-сервер Apache, я хотел бы попробовать веб-сервер на основе Python на этой машине. Но я боюсь, что могу получить какой-то конфликт, если я попытаюсь. Я имею в виду, как два веб-сервера будут "решать", кому нужен сервер запроса от клиента?
заставьте их слушать разные порты, и все будет в порядке.
веб-порт по умолчанию-80. При открытии url-адреса в браузере без указания порта по умолчанию используется 80.
вы можете настроить свой веб-сервер для прослушивания другого порта, но тогда вам также нужно будет явно указать его в url:
при выборе порта обратите внимание, что этот конкретный номер порта не используется программное обеспечение, которое вы установили и бегу по твоей коробке. В противном случае, как вы правильно догадались, возникнет конфликт.
P.S. всего несколько дней назад, делая переустановку, я не смог запустить IIS (по-видимому, без причины). Оказалось, что новая версия Skype заняла этот порт по умолчанию! Пришлось удалить его параметр "использовать порт 80 и 443 в качестве альтернативы для входящих соединений".
веб-сервер привязан к определенному порту. Обычно это порт 80. Если порт не указан явно,это порт, который браузер будет пытаться ударить.
вы можете заставить ваш альтернативный сервер работать на другом порту (8080 или 8081, похоже, популярны для веб-серверов, но выбор за вами ).
Это остановит конфликт. Все, что идет на порт 80, попадает на ваш старый сервер. Все идет к 8080 (или любому порту, который вы решите запустить свой сервер) поразит ваш простой сервер python.
чтобы попасть на другой сервер, используйте URL-адрес: -
Если вы действительно хотите запустить отдельные серверы для тестирования серверного программного обеспечения, см. другие ответы, но.
Это звучит так (потому что вы разработчик, а не сисадмин, верно?) ты действительно просто хочу запустить сайты Python и PHP на одном компьютере. Итак, простите меня, если я читаю ваш вопрос, но эта настройка позволяет мне запускать оба типа сайтов на одном компьютере с одним портом (порт 80) на одном сервере Apache.
Я делаю новые записи в моем файле/etc / hosts (или C:\Windows\System32\drivers\etc\hosts в Windows) и укажите их на 127.0.0.1:
затем в Apache добавляю VirtualHosts для каждого сайта:
Итак, сайты PHP работают в DocumentRoot как они всегда делают. И сайты Python работают в WSGI. И они оба работают в Apache. Затем, чтобы проверить, я просто добавляю ".local " в любом браузере, который я использую для работы с моей локальной копией.
вы не можете открыть два веб-сервера в одном порту (по умолчанию 80), если вы хотите сделать два или более веб-серверов, вы должны использовать разные порты.
Если вы используете DNS, Вы можете легко настроить свой веб-сервер для ответа с разными веб-сайтами на разные запросы, что может быть полезно, если вам нужно иметь разные веб-сайты для поддоменов или разных доменов.
веб-серверы не будут иметь права голоса в том, кто обслуживает запрос на подключение (эта задача все еще находится на уровне операционной системы). Кроме того, без специальных опций сокета сокет должен быть привязан к уникальному сочетанию интерфейса, интернет-адреса и порта.
Кажется, что запустить сервер базы данных на той же машине, что и веб-сервер, было бы просто, но не рискуем ли мы при этом безопасностью?
Среда будет представлять собой Windows server, Postgresql (последняя версия, возможно , 9.0) и Apache 2.
Ответ 2
Ваша служба, находящаяся на первом слое системы, должна иметь как можно меньшую поверхность атаки. Это основная причина для использования обратных прокси-серверов и брандмауэров, а также для того, чтобы держать ненужные службы и программы подальше от серверов, которым они не нужны для работы. Именно поэтому веб-серверы являются наиболее распространенной целью для усиления безопасности.
Ваш веб-сервер не должен иметь полного доступа к системе баз данных , п оэтому компрометация веб-сервера не приведет к компрометации и сервера базы данных. Во-первых, у четная запись, которую веб-сервер использует для доступа к базе данных, не должна иметь локальных административных прав на блок SQL, ее права должны быть ограничены только разрешениями базы данных. Во-вторых, в рамках этих разрешений SQL он должен работать по принципу наименьших привилегий. Например, ваш веб-блок не должен иметь возможности создавать новые базы данных внутри экземпляра. В идеал е в аш веб-блок не должен иметь возможности сбрасывать таблицы или удалять строки из таблиц без крайней необходимости , п оэтому в случае компрометации правильно настроенной двухуровневой системы влияние злоумышленника, использующего учетные данные SQL, ограничено.
Ответ 3
Это действительно зависит от модели безопасности вашего Web-сервера и сервера БД (то есть от программного обеспечения), а также от степени брандмауэринга/контроля доступа/IDP, которые вы бы применяли на этих двух серверах, если бы они находились на разных серверах.
При прочих равных условиях, вероятно, лучше разделить эти два сервера. Практически, однако, по крайней мере, в среде LAMP, пока вы используете privsep Apache (если вы не уверены, не волнуйтесь, это так) и не используете root login для MySQL в вашем webapp, а также у вас нет tcp/3306 для внешнего мира, вы не получите большого выигрыша в безопасности, если перенесете один или другой сервер на другой «кусок кремния». Однако вы получаете преимущества в производительности и отлаживаемости.
Ваш вопрос задан в стиле, который требует абсолютного ответа, но без дополнительной информации (как минимум, о каких ОС и вкусах web/DB-серверов идет речь ) т рудно дать информативный ответ.
Ответ 4
Ответ 5
Я бы не стал , но это я.
Это зависит от того, что находится в вашей системе (т. е . брандмауэры, балансировщики нагрузки и т. д .) и насколько они грамотно настроены, каковы фактические данные (т. е . публично доступные данные с одним концом, национальные секреты с другим), есть ли какое-либо влияние на производительность при их объединении, конфиг ура ция сети между ними (т. е . межуровневые брандмауэры) и качество защиты ОС/приложений, которые будут применяться.
Если вы не ожидаете, что эта система будет испытывать слишком большую нагрузку, можно рассмотреть вариант виртуализации системы в двух отдельных виртуальных машинах, по одной на каждую функцию — возможно, с третьей виртуальной машиной с программным брандмауэром между ними. Это будет означать, что , даже если кто-то взломает ваш веб-сервер, ему придется взломать сервер базы данных и, если он включен, промежуточную ВМ брандмауэра. Конечно, это снизит общую производительность системы, но будет, по крайней мере, в некоторой степени более безопасным, а также поможет, если ваша нагрузка когда-нибудь возрастет и потребует двухсерверной конструкции, поскольку вы сможете просто перенести одну ВМ на вторую машину. Бесплатный продукт ESXi от VMWare может сделать все это довольно легко, и уже есть бесплатные виртуальные машины брандмауэра, готовые к внедрению, если вы захотите их использовать.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Ответ 1
Если ваш веб-сервер будет взломан, злоумышленник все равно получит полномочия для доступа к тем же базам данных, независимо от того, на каком сервере они работают. В конце концов, сервер базы данных должен быть настроен так, чтобы разрешить легитимный запрос с веб-сервера (п редполагая разумные меры безопасности, такие как mysqld , не принимает логин root без пароля с localhost).
Учитывая это, вы, возможно, захотите запустить отдельный сервер базы данных. Причина этого связана с производительностью, масштабируемостью и т. д .
Читайте также: