Концептуально, как балансировка нагрузки на уровне EJB работает в Glassfish / любом контейнере ejb

Question

Мне интересно, как работает балансировка нагрузки на уровне EJB (не репликация веб-сеанса) с контейнерами Java EE, такими как Glassfish.Из того, что я обнаружил, ваш удаленный интерфейс - это прокси, который делегирует ваш вызов одному из многих серверов, которые вы можете иметь в среде.

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

Answer 1

Мне интересно, концептуально, как балансировка нагрузки работает на уровне EJB (не репликация веб-сессии) с Контейнеры Java EE, такие как Glassfish. Из того, что я почерпнул твой пульт Интерфейс является прокси, который делегирует Ваш звонок на один из многих серверов вы может иметь в окружающей среде.

Вы правы. В Glassfish начальный поиск попытается связаться с одним из серверов, перечисленных в файле jndi.properties. Затем сервер знает все другие узлы в кластере, которые будут использоваться для циклического перебора. Удаленная ссылка (прокси) сделает это за вас прозрачно. Теоретически узлы могут быть добавлены / удалены из кластера динамически. См. Балансировка нагрузки и аварийное переключение нагрузки Glassfish RMI-IIOP .

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

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

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

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

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

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

Answer 2

Если что-то не так, предполагается, что они смогут "завершить" на другом сервере?

Failover (здесь вы имеете в виду аварийное переключение, а не load-балансировка) не является частью спецификации , насколько я знаю.Однако большинство поставщиков поддерживают аварийное переключение, и несколько контейнеров EJB могут быть сгруппированы для обеспечения этой функции.По сути, ход каждой открытой транзакции передается на сервер (ы) резервного копирования, и, если основной контейнер завершает работу с ошибкой, когда транзакция все еще открыта, сервер резервного копирования может вступить во владение и, при некоторых обстоятельствах, он может продолжить транзакцию.(например, WebLogic требует, чтобы методы были объявлены как идемпотент ).Чаще всего резервный контейнер выполняет откат транзакции и сигнализирует клиенту о необходимости повторить исходный запрос.

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

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