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

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

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


load-balancing glassfish ejb jakarta-ee
person benstpierre    schedule 12.03.2010    source источник

Ответы (2)


arrow_upward
8
arrow_downward

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

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

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

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

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

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

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

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

person ewernli    schedule 13.03.2010

arrow_upward
7
arrow_downward

Если что-то пойдет не так, они должны быть в состоянии «закончить» на другом сервере?

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

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

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

person Pascal Thivent    schedule 13.03.2010