X

News, tips, partners, and perspectives for the Oracle Solaris operating system

Улучшение доступности сервера приложений Sun Java System Application Server с помощью кластера Solaris

Guest Author

Введение

Сервер приложений Sun Java System Application Server является одним из ведущих продуктов ПО промежуточного слоя и обладает надежной архитектурой и стабильностью, а также прост в использовании. В структуре самого сервера приложений имеется несколько функций высокой доступности в виде агентов узла, распространяемых по множеству узлов для предотвращения появления единственной точки отказа.  Вот простой пример структуры:



Тем не менее, как видно из приведенной выше блок-схемы, сервер администрирования домена (DAS) не является высоко доступным. В случае отказа DAS невозможно выполнять административные задачи. Несмотря на то, что клиентские подключения перенаправляются в другие экземпляры кластера в случае сбоя или недоступности экземпляра или агентов узла, хотелось бы иметь функцию автоматического восстановления для сокращения нагрузки на оставшиеся экземпляры кластера. Кроме того, возникают ситуации сбоя оборудования, ОС или сети, которые необходимо учитывать для важных развертываний, где время работы без отказов является одным из основных требований.  

Почему требуется высокодоступное решение?

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

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

Как выбрать наилучшее решение?

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

Является ли решение надежным и проработанным?

Предоставляет ли поставщик агент, специально разработанный для сервера приложений Sun Java System Application Server?

Является ли решение простым в развертывании и использовании?

Является ли решение экономичным?

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

И, что важно, можно ли получить поддержку в виде документации, обслуживания клиентов и единого консультационного центра?

Почему именно кластер Solaris?


Кластер Solaris – это лучшее решение высокой доступности для платформы Solaris изо всех существующих на настоящий момент. Это решение обеспечивает превосходную интеграцию с операционной системой Solaris и помогает клиентам использовать ее новые функции, не внося изменений в существующие развертывания. Кластер Solaris поддерживает приложения, запущенные в контейнерах, предлагает очень широкий выбор файловых систем, которые можно использовать, широкий выбор архитектур процессоров и т. д.  В число преимуществ решения входят следующие.

Интеграция уровня ядра, что позволяет использовать такие функции Solaris, как контейнеры, ZFS, FMA и т. д.

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

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

Определение сбоев в сети, основанное на IPMP, и баланс нагрузки.

Один и тот же агент можно использовать для Sun Java Application Server и Glassfish.

Мастера настройки служб данных для наиболее распространенных задач кластера Solaris.

Сложный защитный механизм, помогающий избежать повреждения данных.

Определение потери доступа к хранилищу путем наблюдения за путями к дискам.

Как кластер Solaris обеспечивает высокую доступность?

Кластер Solaris обеспечивает высокую доступность с помощью избыточных компонентов.  Хранилище, сервер и сеть являются избыточными. На приведенном ниже рисунке показан простой двухузловой кластер, где существуют рекомендованные избыточные межсоединения, хранилище доступно для обоих узлов, а каждый из них доступен в общей сети. Важно отметить, что это рекомендуемая комплектация, и что в минимальной комплектации может присутствовать всего лишь одно общее хранилище, межсоединение и интерфейс общедоступной сети. Гибкость кластера Solaris обеспечивает даже возможность иметь одноузловой кластер при индивидуальной необходимости.

ЛИУ =  логическое имя узла, тип виртуального IP-адреса, используемый для перемещения IP-адресов между сетевыми контроллерами.

RAID =  любое подходящее ПО или оборудование на основе механизма RAID, обеспечивающее как избыточность, так и производительность.

Можно выбрать, обеспечивать ли доступность только для DAS или для агента узла тоже. Выбор зависит от среды. Масштабируемость агентов узла не является проблемой при наличии развертываний высокой доступности, поскольку многочисленные агенты узла могут быть развернуты на одной установке кластера Solaris. Эти агенты узла настраиваются в многочисленных группах ресурсов, каждая из которых имеет один логический узел, HAStoragePlus и ресурс узла агента. Поскольку агенты узла в обычном развертывании распространены по многочисленным узлам, нет необходимости в дополнительном оборудовании просто потому, что используется архитектура высокой доступности. Хранилище можно сделать избыточным при помощи как программного, так и аппаратного RAID.

Действия кластера Solaris по переходу на другой узел в случае сбоя

В кластере Solaris имеется набор сложных алгоритмов, которые применяются для определения того, следует ли перезапустить приложение при сбое или перейти на избыточный узелл. Как правило, IP-адрес, файловая система, где находятся двоичные файлы и данные приложения, а также сам ресурс приложения группируются в логический объект, называемый группой ресурса. Как видно из названия, файловая система, IP-адрес и само приложение рассматриваются как ресурсы, и каждый из них идентифицируется типом ресурса, который часто называется агентом. Механизм восстановления, например перезапуск или переход на другой узел, определяется в зависимости от времени ожидания, количества перезапусков и предыдущих переходов на другие узлы. Агент, как правило, имеет методы запуска, остановки и проверки, используемые для запуска, остановки и проверки предварительных условий каждый раз, когда состояние приложения изменяется. В его составе также имеется тест, который выполняется через предварительно определенный период времени для определения доступности приложения.

Кластер Solaris имеет два типа ресурса, или агента, для сервера приложений Sun Java System Application Server.  Тип ресурса SUNW.jsas используется для DAS, и SUNW.jsas_na для агента узла. В механизм проверки входят исполнение команд ?asadmin list-domain? и ?asadmin list-node-agents? и интерпретация выходных данных для определения, находятся ли DAS и агенты узла в нужном состоянии.  ПО сервера приложений, файловая система и IP-адрес переносятся на избыточный узел в случае необходимости перехода на другой ресурс. Ознакомьтесь с руководством по службе данных кластера Sun (http://docs.sun.com/app/docs/doc/819-2988) для получения дополнительных сведений.

Ниже приведена иллюстрация перехода на другой узел в случая отказа сервера.
 

В установке, о которой рассказывалось выше, сервер приложений не переносится на второй узел, если
происходит сбой только одного из сетевых контроллеров. Избыточный сетевой контроллер, который является частью той же группы IPMP, размещает логический узел, используемый DAS и агентами узла. Далее будет отслеживаться временная сетевая задержка до тех пор, пока логический узел не перемещен с nic1 на nic2.

Для развертывания сервера приложений рекомендуется глобальная файловая система (GFS), поскольку в файловой системе, где установлены файлы настроек и (в конкретных развертываниях) двоичные файлы, выполняется очень мало записей, отличных от записи в журналы. Поскольку глобальная файловая система установлена на всех узлах, результатом является более быстрый переход на другие узлы и более быстрый запуск сервера приложений в случае отказа узла или подобных проблем.

Обслуживание и обновления

Те же свойства, что помогают кластеру Solaris обеспечивать восстановление при сбоях, можно использовать для обеспечения непрерывности работы в случае обслуживания или обновления. 

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

Обслуживание сервера приложений или обновление зависит от способа хранения двоичных файлов, данных и файлов настроек. 

1.)Хранение двоичных файлов на внутреннем жестком диске узла и хранение агента домена и узла и связанных с ними файлов в общем хранилище.  Этот способ рекомендуется для сред, где необходимы частые обновления. Недостатком этого способа является возможная несогласованность двоичных файлов приложения из-за различий в исправлениях или обновлениях.

2.)Хранение двоичных файлов и данных в общем хранилище.   Этот способ обеспечивает постоянную согласованность данных, но усложняет обслуживание и обновления без сбоев.

Необходимо делать выбор, принимая во внимание процедуры и процессы, выполняемые в организации.

Другие функции

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

Кластер Solaris оснащен простым в использовании, интуитивно понятным средством управления с графическим интерфейсом пользователя, который называется Sun Cluster Manager и может использоваться для выполнения большинства задач, связанных с обслуживанием.

Кластер Solaris имеет встроенную функцию телеметрии, которую можно использовать для контроля использования ресурсов, таких как ЦП, память и т. д.


Сервер приложения Sun Java Application не требует внесения каких-либо изменений в кластер Solaris, поскольку агент разработан с учетом такой ситуации.

Этот же агент можно использовать и для Glassfish.

Можно сделать высоко доступным брокер очереди сообщений при помощи высокой доступности для агента очереди сообщений Sun Java.

Исходные коды этого продукта, в соответствии с философией компании Sun, постепенно делаются открытыми, и агенты уже доступны по лицензии CDDL.

Продукт с открытым исходным кодом, основанный на той же базе кода, можно получить в выпусках для OpenSolaris под названием Open High Availability Cluster.  Дополнительные сведения о продукте и сообществе приведены по адресу: http://www.opensolaris.org/os/communities/ohac .

Для этого продукта с открытым исходным кодом также имеется полный набор тестов, который помогает пользователям успешно тестировать развертывание.  Дополнительные сведения можно получить в документе http://opensolaris.org/os/community/ha-clusters/ohac/Documentation/Tests/.


Заключение

Для сред, которые исключительно важны для выполнения задач, доступность решения при любых типах сбоев является очень серьезным критерием.  Кластер Solaris разработан наилучшим образом для обеспечения самой высокой доступности для сервера приложений путем его интеграции с ОС Solaris благодаря стабильности и наличию агента, специально разработанного для сервера приложений Sun Java System Application Server.
 

Мадхан Кумар
Solaris Cluster Engineering

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha