Тема номера: Системы высокой готовности

Сергей Комаров,
ведущий специалист РДТЕХ
по интернет-технологиям

Построение систем высокой готовности
на основе сервера приложений Oracle Application Server 10g
(OracleAS 10g)

Источник: обзор представлен компанией РДТЕХ (http://www.rdtex.ru )

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

• Сбой приложения. Возникает в процессе работы пользователей с приложением. Может быть вызван как ошибками в самом приложении, так и сбоями в работе среды выполнения приложения. Чтобы минимизировать риск подобных сбоев, сервер приложений должен уметь определять подобные состояния и принимать адекватные меры (например, автоматический перезапуск приложения).
• Аппаратный сбой. Возникает по причине отказа в оборудовании. Риск подобного сбоя может быть минимизирован путем подключения дополнительных серверов и объединения их в кластер, с автоматическим определением отказавшего узла.
• Плановое и внеплановое обслуживание. Подобные операции также можно отнести к сбоям, поскольку в этот момент сервисы, предоставляемые сервером приложений, также могут быть частично, либо полностью, недоступны. Как и в предыдущем случае, выйти из такой ситуации можно создав кластер.

OracleAS 10g предоставляет масштабируемую инфраструктуру для обеспечения бесперебойной работы приложений J2EE. При этом возможна как вертикальная, так и горизонтальная масштабируемость. Ниже поясним эти два вида масштабируемости, и какие свойства сервера приложений OracleAS 10g за ними стоят.

Вертикальная масштабируемость средствами компонентов OC4J

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

Несколько экземпляров OC4J на одном хосте

Сервер приложений OracleAS 10g позволяет создать несколько экземпляров OC4J (Oracle Containers for Java). Экземпляр OC4J по сути дела является некой логической сущностью, состоящей из набора конфигурационных файлов контейнера OC4J, сопутствующих библиотек и развернутых приложений J2EE, запускаемых в контексте этого контейнера. Подобная организация позволяет развертывать и запускать приложения J2EE в независимых контейнерах OC4J (каждому из которых соответствуют одна или несколько виртуальных Java-машин (JVM)). Тем самым обеспечивается изоляция приложений друг от друга и как следствие повышается надежность работы системы в целом: сбой одного из контейнеров не приведет к остановке остальных приложений в других контейнерах на сервере.

Несколько процессов JVM на экземпляр OC4J

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

Еще одним свойством процессов экземпляра OC4J является автоматическая репликация состояния приложений: Web-модулей и EJB. Чтобы контроллировать процесс репликации состояния между процессами (как локальными, так и на разных хостах), их можно объединять в так называемые острова. При этом состояние приложения будет реплицироваться между процессами, образующими один остров. Последнее утверждение справедливо пока только для Web-модулей.

Горизонтальная масштабируемость средствами сервера OracleAS 10g

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

Балансировка нагрузки

Балансировку нагрузки между узлами кластера можно организовать либо через соответствующую аппаратуру, либо программным способом. В последнем случае в качестве балансировщика нагрузки можно использовать Oracle Web Cache.

Oracle Web Cache в качестве балансировщика нагрузки

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

Oracle HTTP Server в качестве балансировщика нагрузки

Запросы к Web-приложениям J2EE, выполняемым в экземплярах OC4J, поступают через Oracle HTTP Server. Здесь за передачу запросов от сервера HTTP в экземпляр OC4J отвечает модуль mod_oc4j. В случае использования кластера mod_oc4j начинает выступать в качестве балансировщика нагрузки между процессами OC4J, раположенными на всех узлах кластера. Для выбора очередного процесса для обработки запроса mod_oc4j использует один из трех алгоритмов: последовательный выбор, случайный выбор и выбор на основе текущей загрузки процессов OC4J.

Высокая готовность инфраструктуры сервера приложений OracleAS 10g

При поиске и устранении всех возможных точек отказа необходимо рассматривать не только серверы промежуточного звена, но и саму инфраструктуру, т.е. сервер, на котором находятся репозиторий метаданных и службы идентификации пользователей. На текущий момент возможны два варианта: кластер с аварийным переходом на холодный резервный ресурс (Cold Failover Cluster, CFC) и кластер с аварийным переходом на активный резервный ресурс (Active Failover Cluster, AFC). Оба варианта кластеров инфраструктуры основаны на использовании аппаратного кластера. В кластере CFC “рабочим” является только один узел, в то время как другой находится в состоянии ожидания. В случае возникновения сбоя происходит переключение на запасной узел. В кластере AFC оба узла инфраструктуры находятся в рабочем состоянии, распределяя нагрузку между собой. В этом случае для обеспечения высокой готовности репозитория метаданных используется технология RAC.