App Server Clustering vs Terracotta

Question

Я слышал термин «кластеризация», используемый для серверов приложений, таких как GlassFish, а также Terracotta; и я пытаюсь понять, что означает кластер при использовании в сочетании с серверами приложений и при использовании в сочетании с Terracotta.

Мой понимание является:

Если GlassFish сервер кластерный, то это означает, что мы имеем несколько физических/виртуальных машин, каждая со своим собственным JRE/JVM работает отдельные экземпляры GlassFish. Однако, поскольку они сгруппированы, все они будут обмениваться данными через свой сервер администратора («DAS») и будут иметь те же приложения, которые будут развернуты для всех из них. Они будут эффективно действовать (конечному пользователю), как если бы они были единственным сервером приложений, но теперь с балансировкой нагрузки, отказоустойчивостью/резервированием и масштабируемостью добавлены в микс.

Terracotta - это, по сути, продукт, который делает несколько JVM, работающих на разных физических/виртуальных машинах, действует так, как если бы они были одним JVM.

Таким образом, если я правильно понимаю, следующий подразумевается:

• сервера кластера приложение, которое вы, когда вы хотите балансировки нагрузки и устойчивость отказоустойчивого
• используется Terracotta, когда какая-либо конкретная виртуальная машина Java слишком мала, чтобы содержать ваше приложение и вам нужно больше «лошадиных сил»
• Таким образом, технически, если у вас есть стек GlassFish, скажем, 5 экземпляров сервера; каждый из этих 5 экземпляров действительно может быть массивом/кластером экземпляров Terracotta; что каждый экземпляр сервера GlassFish на самом деле является экземпляром GlassFish, живущим через JVM нескольких машин.

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

Answer 1

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

Если ваше приложение не имеет гражданства, и вам просто нужно выполнить балансировку нагрузки и выйти из строя, вы можете использовать такое решение, как JGroups. В этом случае каждый узел обрабатывает запросы и не имеет представления о других узлах. Объекты в памяти не разделяются между узлами, и каждая JVM работает сама по себе и не имеет представления о других JVM. Это часто хорошо работает для приложений типа запроса/ответа. Веб-сервер, обслуживающий контент (без сеансов), делает это, например.

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

GlassFish немного находится в середине вышеупомянутых концепций. Объекты в памяти GlassFish видны всем узлам. Однако интерфейс (HTTP-коннекторы) работают без гражданства.

Так, чтобы ответить на ваши вопросы:

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

2) Да. Хотя технически говоря, Terracotta решает только часть разделяемой памяти, а не часть процессора. Однако, решая часть памяти, он автоматически решает процессорную часть, так как теперь вы можете просто добавить JVM в пространство общей памяти.

3) Я не знаю, возможно ли это, но как мысленный эксперимент; Да.

Answer 2

кластеризация может означать одно из следующих действий:

1. Несколько экземпляров можно управлять как единое целое. Разверните приложение в кластере, оно развернуто во всех экземплярах кластера. Внесите изменения в конфигурацию, и это изменение будет перенесено на все узлы кластера. GlassFish поддерживает это из коробки.
2. Доступность услуг. Если какой-либо один экземпляр не работает, приложение доступно в другом экземпляре. Без высокой доступности включение любого сбоя экземпляра также приводит к потере сеанса для любого сеанса, управляемого этим экземпляром. GlassFish поддерживает это из коробки.
3. Высокая доступность. Если какой-либо один экземпляр не работает, приложение доступно в другом экземпляре, и нет потери сеанса, поскольку реплика сеанса также поддерживается в другом экземпляре. GlassFish поддерживает это. Вам нужно будет выбрать # 2 или # 3 в любом кластере.

Что вы спрашиваете о IMHO - это действительно №3, потому что это единственный реальный случай, когда Terracotta - в контексте кластеризации с высокой степенью готовности - предложит значение w/GlassFish. GlassFish уже предлагает встроенную высокую доступность, поэтому лучше было бы предложить прекрасную возможность использовать Terracotta для решения проблемы, поскольку это усложнит архитектуру развертывания.

Основная причина, по которой я могу думать о добавлении Terracotta, заключается в том, что вы можете отключить управление сеансом до сетки данных и освободить GlassFish для запуска бизнес-логики. Это может быть связано с более частым сбором мусора или желанием управлять большим количеством пользователей на экземпляр GlassFish. Тем не менее, я не уверен, что Terracotta может сделать это без проблем. Благодаря встроенной кластеризации HA GlassFish реплицирующие сеансы являются бесшовными (без модификаций логики приложения). Возможно, вам придется написать код для ввода/получения данных из Terracotta cache. Я дам вам исследование :-) Oracle GlassFish Server также интегрирует (легко) с Coherence для решения этой проблемы. Вы можете разделить управление сеансом на сетку данных Coherence без изменения кода приложения.

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

Надеюсь, это поможет.