Я думаю, что ответ на ваши вопросы сильно зависит от поведения этого приложения, использования базы данных и т. Д. ... и ничего нельзя сказать, не глядя на текущие показатели производительности (как уже упоминалось в других ответах). Я отправляю некоторые из своих мыслей в качестве рекомендаций.
База данных
Большинство организаций запустить СУБД в разных узлах, и некоторые инженеры выбрали бы никогда не виртуализировать их, в зависимости от того, что говорят, что их DB поставщика передовой практики в их случае (то есть, я обычно считают виртуальные машины чтобы быть эквивалентным физическим хостам, и я использую их по возможности).
С точки зрения производительности, для РСУБД часто требуется настройка ядра или нетрадиционные стратегии файловой системы, и их использование в отдельных хостах может помочь. Если БД когда-либо нужно настраивать в режиме высокой доступности или в кластере, отделяя его от серверов приложений, это также упростит работу. Обратите внимание, что настройка базы данных, если вам когда-либо понадобится это сделать, может быть сложной темой, если серьезно относиться к ней, и она часто включает в себя такие вещи, как выравнивание разделов на диске, попытка уменьшить движение головки диска, умело распределяя сегменты/файлы данных базы данных, учитывая Размеры и стратегии кэширования СУБД и ОС ... Все это может повлиять на работу других приложений, работающих на одном и том же хосте, поэтому я предпочел бы оставить только DB.
Кроме того, RDBMS часто обслуживают несколько приложений (для этого есть веские причины: иногда для некоторых интеграций требуется доступ к нескольким базам данных приложений). Помочь им отделить их от серверов приложений.
Кроме того, системы БД имеют свои собственные процедуры обновления, резервного копирования, распределения/кластеризации и администрирования и часто поддерживаются разными лицами, чем серверы приложений. Таким образом, для всей темы администрирования базы данных легче справиться, если вы считаете ее отдельно. И если база данных станет узким местом, вы можете работать только с базой данных, не учитывая, влияют ли другие уровни на производительность.
Я рекомендую хранить только РСУБД в одном хосте для разумных производственных условий. Но, конечно, если у вас нет требований к производительности, администрированию или доступности, вы можете использовать общий сервер для всего.
Glassfish
В общих чертах, если вы хотите, чтобы развернуть приложение Java EE для нескольких серверов (для балансировки нагрузки и высокой доступности) установить один и тот же сервер приложений и артефакты для всех серверов приложений в кластер.Затем вы можете выбрать, какие артефакты включить на каждом узле кластера. Некоторые серверы приложений могут включать или отключать компоненты в зависимости от нагрузки на сервер. В этом случае ваш сервер приложений - это «единица», которую необходимо распространять.
Теперь могут быть случаи, когда вы или ваша организация предпочитаете иметь полностью разделенные сетевые уровни для веб-уровня и бизнес-уровня (т. Е. Проблемы безопасности). В этом случае для этого вы будете использовать отдельные хосты. Если ваш веб-уровень действительно тяжелый, и вы обнаружите, что вам нужно масштабировать его отдельно от бизнес-уровня (то есть вы обнаружите, что вам нужно 6 веб-серверов, но вы можете сделать это с 1 или 2 контейнерами EJB), я бы отделил эти два уровня слишком.
В примечании: есть небольшие преимущества при запуске веб-сайтов и уровней EJB в том же экземпляре Glassfish: поскольку они совместно используют JVM, вызовы между веб-уровнем и бизнес-уровнем могут использовать семантику вызова по ссылке. В зависимости от вашей рабочей нагрузки и размера и сериализации стоимости ответов это может привести к заметному увеличению производительности.
В большинстве случаев для многих корпоративных приложений я бы использовал только один или два сервера (в зависимости от того, нужна ли вам высокая доступность), содержащий оба уровня, потому что, даже если загрузка возрастает, вы все равно можете расти вертикально (увеличить мощность сервера или виртуальную машину ресурсов) или горизонтально (добавьте еще один запрос на сервер и запрос баланса нагрузки).
Приложения, доступные в мире и имеющие высокую пропускную способность, должны учитывать многие другие аспекты, чтобы они могли быть масштабируемыми (простое добавление узлов к узлу кластера Java EE не будет сокращать его), поэтому я не думаю, что какой-либо из это решение лучше или хуже для развертывания в «Облаке», но в общих чертах, если вы планируете развертывать службы гибкой виртуализации, и ваши требования оправдывают это, я рекомендую отделить веб-и бизнес-уровни.
безопасности
На мой взгляд, обсуждаемые темы не оказывают непосредственное влияние на безопасность.
Наконец, я уверен, что многое другое можно сказать об этой теме, и мой опыт ограничен, поэтому, пожалуйста, получите больше мнений;).
http://glassfish.java.net/public/clustering31.html – Flexo
У вас может быть JVM, которая также является вашей РСУБД. –