Концептуально, как делает выравнивание нагрузки на работе уровня EJB в контейнере Glassfish/any ejb
Я задаюсь вопросом концептуально, как выравнивание нагрузки работает на EJB-уровне (не веб-репликация сессии) с Java контейнеры EE как Glassfish. Из того, что я подобрал Ваш удаленный интерфейс, прокси, который делегирует Ваш вызов к одному из многих серверов, которые Вы можете иметь в среде.
Если вещи перестали работать, они, как предполагается, могут "закончить" на другом сервере? Я хочу понять основную теорию позади этого выравнивания нагрузки, почему это - лучше, чем набор серверов все выполнение простого веб-приложения с привязкой сессии на подсистеме балансировки нагрузки?
2 ответа
Мне интересно концептуально, как балансировка нагрузки работает на уровне EJB (не репликации веб-сеанса) с помощью { {1}} Контейнеры Java EE, такие как Glassfish. Насколько я понял, ваш удаленный интерфейс представляет собой прокси-сервер, который делегирует ваш вызов одному из многих серверов, которые вы {{1} } может быть в среде.
Вы правы. В Glassfish при первоначальном поиске будет предпринята попытка связаться с одним из серверов, перечисленных в файле jndi.properties . Затем серверу известны все остальные узлы кластера, которые будут использоваться для циклического перебора.Удаленная ссылка (прокси) сделает это за вас прозрачно. Теоретически узлы можно добавлять / удалять из кластера динамически. См. Балансировка нагрузки и переключение при отказе Glassfish RMI-IIOP .
Если что-то не так, должны ли они "завершить" работу на другом сервере? Я хочу понять основную теорию , лежащую в основе этой балансировки нагрузки, почему она лучше, чем несколько серверов, на которых выполняется простое веб-приложение с {{ 1}} сходство сеанса на балансировщике нагрузки?
Если компонент не имеет состояния, вам даже не требуется какое-либо сходство, и запрос может быть обработан на любом узле. Каждая удаленная ссылка сама по себе действует как балансировщик нагрузки.
Если фасоль с полным состоянием, он более волосат. Кластер будет пытаться поддерживать 2 реплики компонента. И запрос отправляется против этих двух реплик. Если один из узлов выйдет из строя, кластер будет воссоздавать другую реплику, пока узел не вернется - это действительно похоже на репликацию сеанса HTTP с привязкой сеанса.
Но, в отличие от веб-сервера, bean-компонент - это транзакционные компоненты. Таким образом, если возникает исключение, транзакция откатывается, и компонент с отслеживанием состояния становится недействительным, поскольку его состояние может больше не быть согласованным.
Как указал Паскаль, существует своего рода переключение при отказе определенного типа. Если узел недоступен, запрос может быть перенаправлен на другой узел. Но если узел выходит из строя , пока запрос обрабатывается, я не знаю, сможет ли он повторно отправить его в другое место.
Если вы хотите узнать больше, я предлагаю вам прочитать Руководство по высокой доступности GlassFish и Поддержка кластеров в Glassfish .
Если что-то выйдет из строя, должны ли они «завершить» работу на другом сервере?
Отработка отказа (здесь вы имеете в виду отработку отказа, не балансировка нагрузки) не является частью спецификации , насколько мне известно. Однако большинство поставщиков поддерживают аварийное переключение, и для обеспечения этой функции можно объединить несколько контейнеров EJB в кластер. По сути, ход каждой открытой транзакции передается на резервный сервер (-ы), и, если основной контейнер выходит из строя, пока транзакция все еще открыта, резервный сервер может взять на себя управление и, при некоторых обстоятельствах, может продолжить транзакцию. (например, WebLogic требует, чтобы методы были объявлены как идемпотентные ). Чаще всего резервный контейнер откатывает транзакцию и сигнализирует клиенту, что нужно повторить исходный запрос.
Я хочу понять основную теорию, лежащую в основе этой балансировки нагрузки, почему она лучше, чем несколько серверов, на которых выполняется простое веб-приложение с привязкой сеанса к балансировщику нагрузки?
Слишком много концепций смешано здесь, чтобы предоставить Ответ. Отказоустойчивость! = Балансировка нагрузки, сходство сеанса на самом деле не связано с отработкой отказа (это просто означает, что запрос будет отправлен на сервер, на котором находится сеанс). Отказоустойчивость может быть достигнута на веб-уровне с помощью репликации состояния сеанса HTTP (репликация в памяти, в базе данных и т. Д.). Вам нужно прояснить вопрос.