Распределение Уровней По Виртуальным Машинам

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

В 3-уровневых архитектурах обычно имеется 3 уровня:

  • Aклиент/презентация уровень, на котором живет клиентский код; и
  • Aпромежуточное по уровень, где живет бизнес-логика; и
  • Adata/eis уровень, на котором живут СУБД и другие системы с большим объемом данных

В Java land для веб-приложения это может выглядеть следующим образом например:

  • сервер приложений, например GlassFish, выполняющий как "веб-уровень" (войны, включающие клиентский уровень в веб-приложении), так и "бизнес-уровень" (EJBs, middleware и т. д.); и
  • сервер СУБД, реализующий уровень данных

В виртуализированной/кластеризованной среде эти приложения (GlassFish, RBMBS, такие как Oracle или PostgreSQL и т. д.) будет работать на виртуальных машинах.

Мой вопрос: каковы стандартные способы выделения / распределения этого 3-го уровня архитектура этих виртуальных машин? Это означает, что любая из следующих "стратегий" может быть жизнеспособной , но не предпочтительной :

  1. одна виртуальная машина (допустим, все виртуальные машины являются серверами Ubuntu, поэтому стоимость/цена не учитывается в уравнении), работающая как на GlassFish, так и на RDBMS (все 3 уровня)
  2. Две ВМ: ВМ работает сервер приложений GlassFish и ВМ, сервер базы данных, сказать, что PostgreSQL
  3. три виртуальные машины: две виртуальные машины сервера приложений, обе работающие под управлением GlassFish, однако 1 Экземпляр GlassFish работает только на WARs (web tier), в то время как 2-й экземпляр FlassFish работает на логике middleware / biz; затем 3-й сервер БД

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

Будут плюсы/минусы каждого. Меня интересует, какие стратегии лучше всего подходят для достижения следующих целей: (1) максимизирует пропускную способность/скорость, (2) Лучше всего подходит для кластерной/облачной среды и (3) максимизирует безопасность.

Заранее спасибо!

2 3
architecture virtual-machine multi-tier

2 ответа:

(1) максимизирует пропускную способность / скорость,

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

(2) Лучше всего подходит для кластерной / облачной среды

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

И (3) максимизирует безопасность.

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

2

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

база данных

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

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

Кроме того, СУБД часто обслуживают несколько приложений (для этого есть веские причины: Иногда некоторые интеграции требуют доступа к нескольким базам данных приложений). Имея их отделение от серверов приложений помогает.

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

Рекомендую сохранение одной СУБД на одном хосте для производственных сред разумного размера. Но, конечно, если у вас нет требований к производительности, администрированию или доступности, Вы можете рассмотреть возможность использования общего сервера для всего.

Glassfish

В общих чертах, если вы хотите развернуть приложение Java EE на нескольких серверах (для балансировки нагрузки или высокой доступности), Вы устанавливаете один и тот же сервер приложений и артефакты на все серверы приложений в кластере. Затем вы можете выбрать, какие артефакты включить на каждом узле кластера. Некоторые серверы приложений могут включать или отключать компоненты в зависимости от нагрузки на сервер. В этом случае сервер приложений является "единицей", которую необходимо распространить.

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

Как Примечание: есть небольшие преимущества в запуске уровней web и EJB в одном экземпляре Glassfish: поскольку они совместно используют JVM, вызовы между веб-уровнем и бизнес-уровнем могут использовать семантику call-by-reference. В зависимости от вашей рабочей нагрузки и размера и сериализации стоимость ответов, это может привести к заметному увеличению производительности.

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

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

безопасность

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

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

1