Безопасность транзакций между доменами Oracle WebLogic Server

Управляя распределенной (XA) транзакцией, менеджер транзакций должен иметь возможность связываться со всеми участниками транзакции. Т.е. со всеми серверами и ресурсами в ней участвующими. Коммуникационные каналы настраиваются в зависимости от того, куда направляется транзакция:

• Inter-domain - коммуникация между серверами, участвующими в транзакции и расположенными не в одном и том же домене
  
  
• Intra-domain - коммуникация между серверами, участвующими в транзакции и расположенными в одном и том же домене.
  

Каналы коммуникации для транзакций должны быть защищенными, чтобы предотвращать от атак вида человек посредине. Сервер приложений Oracle WebLogic предоставляет следующие опции для защиты коммуникационных каналов:

• Cross Domain Security - используется отображение учетных данных пользователей для настройки совместимого коммуникационного канала между серверами в транзакциях между доменами. Хотя это требует более сложной конфигурации, Cross Domain Security позволяет настроить доверие между отдельными доменами.
  
  
• Security Interoperability Mode - устанавливает доверие между всеми доменами, которые участвуют в транзакции, путем
  установки для учетных данных всех доменов (domain credentials) совпадающих значений, т.е. principal из одного домена разрешен и в других. Этот режим проще для настройки чем Cross Domain Security, однако некоторые настройки Security Interoperability Mode полагаются на доверие домена и менее безопасны.
  

Рассмотрим преимущества и недостатки данных режимов.

А почему бы мне и не заплатить за мой Spring Framework?

Вопрос, вынесенный в заголовок темы, может показаться странным. Действительно, все знают, что Spring Framework стоит ровно столько же, сколько, например, посмотреть на знаменитого брюссельского Писающего мальчика, т.е. ровно ноль. Однако, если задуматься об эксплуатации приложения, разработанного на основе этого замечательного фреймворка, то может оказаться, что у нас не все так однозначно.

В данной статье Суровый расскажет о плюсах эксплуатации приложения, разработанного на основе Spring Framework, на "взрослом" сервере приложений, например на, поскольку уж так получилось, что я работаю в IBM, - WebSphere Application Server. Целью данного изложения является донести до вас, уважаемые читатели, мысль о том, что инфраструктура имеет значение.

Кластер серверов приложений Oracle WebLogic Server забивает сеть при возникновении проблем

Не все администраторы знают, что по-умолчанию экземпляры сервера приложений Oracle WebLogic Server ведут логи не только в своих каталогах DOMAIN_HOME/server/SERVER/logs, но и пересылают их по сети на сервер администрирования домена. Это сделано для облегчения работы людей: если у вас домен из нескольких десятков экземпляров сервера приложений, то очевидно, что иметь все логи доступными в одном месте очень удобно. Но за данное удобство приходится платить.

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

На небольших доменах (4 - 8 экземпляров) я отключал/отключаю пересылку логов на сервер администрирования. В консоли администратора необходимо в настройках каждого управляемого сервера выставить свойство Domain log broadcaster:, Severity level на странице Environment -> Servers -> SERVER -> Logging -> General, Advanced в значение Critical или даже более жесткое.

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

Для включения фильтрации необходимо создать один или несколько фильтров логов. Фильтры создаются для всего домена на странице DOMAIN -> Configuration -> Log Filters.

При создании нового фильтра достаточно задать его имя.

Если затем перейти в новый созданный фильтр, то с помощью кнопок на панели Expression можно сформировать условие фильтрации.

После редактирования условия нужно не забыть нажать кнопку Save. Отредактированный фильтр вместе с условием станет доступен на таблице Log Filters.

Теперь его можно назначить для свойства Domain log broadcaster:, Filter на странице Environment -> Servers -> SERVER -> Logging -> General, Advanced.

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

Понравилось сообщение - подпишитесь на блог

Коммуникация в кластере серверов приложений Oracle WebLogic

В данной заметке мы рассмотрим довольно важный для понимания настройки и поддержки серверов приложений Oracle WebLogic вопрос - вопрос коммуникации в кластере.

Общие положения

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

• IP-сокеты - для коммуникации вида точка-точка между участниками кластера;
  
  
• IP unicast и multicast для распространения информации о доступности серверов и их состоянии, а так же для построения кластерного JNDI-дерева.
  

При создании кластера с помощью Configuration Wizard по умолчанию устанавливается режим обмена unicast, а при создании кластера с помощью WLST - multicast. Если есть проблемы с распространением JNDI-дерева на кластер с помощью unicast, то может помочь использование нового свойства - ClusterMBean.MessageOrderingEnabled. По умолчанию данное свойство не включено. Чтобы его включить нужно добавить следующую строчку в config.xml:

<message-ordering-enabled>true</message-ordering-enabled>.

Если данная настройка не решает проблему, то нужно перейти на использование multicast режима.

Интересное про сервер администрирования домена WebLogic

Как ведет себя домен сервера приложений WebLogic, если сервер администрирования аварийно завершает свою работу или по каким-то другим причинам становится недоступным?

Если сервер администрирования становится недоступным, то управляемые сервера корректно продолжают свою работу. При этом, если данные сервера объединены в кластер, то так же продолжает работать балансировка нагрузки и восстановление после сбоев. Управляемые сервера так же можно запустить, не имея запущенного сервера администрирования, они будут периодически пытаться с ним связаться и после того, как это удастся - произведут синхронизацию конфигурации. До синхронизации будут использоваться настройки, сохраненные на управляемых серверах. Однако при работе управляемых серверов без доступного сервера администрирования не допускается изменение их настроек.

Соображения по использованию WorkManager'ов на сервере приложений Oracle WebLogic

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

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

Прежде всего следует помнить, что использование стандартного WorkManager'а (default) как правило является вполне допустимым решением: на каждое развернутое на сервере приложение будет создан свой WorkManager, имеющий настройки по-умолчанию. Дополнительные менеджеры потоков нужно определять лишь в следующих случаях:

• Приоритеты потоков по-умолчанию - все потоки имеют равный приоритет - нас не устраивают (Fair Share).
  
  
• Необходимо задать время ответа, к которому сервер приложений должен стремиться (Response Time).
  
  
• Возможны взаимоблокировки при взаимодействии сервер-сервер, в данном случае необходимо настроить WorkManager с явно заданным ограничением числа потоков снизу (Minimum Threads Constraint).
  
  
• При работе приложения используется общий для нескольких потоков пул соединений JDBC, тогда необходимо ограничить число этих потоков сверху (Maximum Threads Constraint).
  

Отдельно стоит заметить, что если на сервере приложений Oracle WebLogic развернута Oracle Service Bus, то для избежания взаимоблокировок при использовании Service Callout'ов необходимо, чтобы вызываемые таким образом сервисы имели отдельные WorkManager'ы. Подробнее про модель потоков OSB можно прочитать в одноименной статье.

Включение административного канала на сервере приложений WebLogic

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

Перед включением административного канала необходимо настроить SSL для всех серверов домена. Рассмотрим настройку SSL с использованием сгенерированного самоподписанного сертификата.

Правильное тестирование и обновление приложения на сервере приложений WebLogic

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

Очистка постоянных хранилищ (Persistent Store) сервера приложений WebLogic с помощью WLST

Для сохранения в долговременной памяти различных объектов, таких как сервисы диагностики, JMS-сообщения, логи транзакций, таймеры и т.д., сервер приложений Oracle WebLogic использует механизм постоянных хранилищ (Persistent Store). Постоянные хранилища могут работать как с диском (File Stores), так и с СУБД (JDBC Stores). При этом сервер приложений никогда не очищает файловое хранилище, т.е. не уменьшает его размер даже если в нем не осталось объектов.

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

Для очистки хранилища администратору сервера приложений доступна утилита командной строки weblogic.store.Admin и утилита WebLogic Scripting Tool (WLST). При использовании WLST необходимо выполнить команду compactstore, принимающую в качестве аргументов путь к каталогу, в котором содержатся файлы хранилища, и путь к каталогу временных файлов - в данном каталоге будет создана резервная копия хранилища. Последний аргумент является необязательным, однако если вы его указываете, то необходимо учитывать, что каталог для резервной копии не может находиться внутри каталога хранилища. Команду compactstore можно выполнять только при выключенном экземпляре сервера приложений WebLogic, использующем хранилище.

Пример:

wls:/offline> compactstore('/home/weblogic/user_projects/domains/esb_domain/store/RTKDSVStore_1')

Подробнее про использование постоянных хранилищ можно прочитать в разделе Using the WebLogic Persistent Store документа Configuring Server Environments for Oracle WebLogic Server 11g Release 1 (10.3.6).

Понравилось сообщение - подпишитесь на блог и Twitter

Варианты запуска WebLogic Server'а с использованием WLST

Существует несколько способов запуска серверов участников домена сервера приложений WebLogic. Один из них - это использовать скрипты DOMAIN_HOME/bin/startWebLogic.sh для AdminServer'а и DOMAIN_HOME/bin/startManagedWebLogic.sh для управляемых серверов. Другой - использовать утилиту WebLogic Scripting Tool (WLST). В данной заметке мы подробно рассмотрим второй способ.

Пример использования Spring Framework совместно с SCA-контейнером Oracle WebLogic

В одной из предыдущих заметок я привел теоретическое описание компонентной архитектуры сервисов (SCA). Однако любая теория требует практического подкрепления, поэтому в данной заметке мы рассмотрим использование SCA-контейнера сервера приложений Oracle WebLogic и Spring Framework для реализации некоторых из довольно часто используемых паттернов интеграции корпоративных приложений (EIP) - Обогатитель данных (Data Enricher) и основанный на нем паттерн Квитанция (Claim Check).

Паттерн Обогатитель данных

Если есть две интегрируемые системы, одна из которых возвращает меньше данных, нежели нужно другой, то такие данные требуется обогащать - добавлять недостающие, получая их из некоторого хранилища. Например, по почтовому индексу, передаваемому системой-источником, можно получить во внешнем хранилище, например в БД КЛАДР, населенный пункт абонента и передать его в систему-приемник. В данном случае Обогатитель данных выступает специальным трансформатором преобразующим сообщение с неполным набором данных в итоговое сообщение. Важным компонентом данного паттерна является внешнее хранилище данных, которое может представлять собой СУБД, некоторое предустановленное корпоративное приложение или публичную службу.

Паттерн Квитанция

Данный паттерн решает следующую проблему: передаваемое через интеграционный слой, например через очередь, сообщение слишком большое, а его обработка осуществляется в несколько шагов. Чтобы не передавать большое сообщение на каждый шаг обработки, что может повлечь снижение производительности системы, можно поступить следующим образом: сохранить сообщение во внешнем хранилище, например в СУБД, а передавать некоторую квитанцию - сообщение, содержащее лишь указатель на сохраненные данные. При этом в том узле, в котором необходимо получить доступ к содержимому сообщения, оно извлекается из хранилища с помощью паттерна Обогатитель данных.

Интеграция Spring Framework и консоли администрирования сервера приложений WebLogic

При эксплуатации программ, разработанных с использованием Spring Framework, под управлением сервера приложений WebLogic, их сопровождение можно облегчить с помощью предоставляемых компанией Oracle расширений для консоли администрирования. В данной заметке мы рассмотрим как включить данные расширения и обеспечить их использование для управления приложениями.

Создание кластера серверов приложений WebLogic с помощью WLST и утилит pack/unpack

В заметке полуторагодичной давности Создаем кластер серверов приложений WebLogic: балансировка нагрузки, обнаружение ошибок, репликация сессий Суровый расказывал о том, как создать домен с помощью Configuration Wizard. Однако у данного способа есть недостаток - он трудоемок для администратора. Посудите сами: администратор, каждый раз создавая домен, вынужден проходить по двум десяткам окон мастера, внося одни и те же изменения. А т.к. классический процесс разработки и внедрения предполагает наличие как минимум трех сред: разработки, интеграционного тестирования и промышленной эксплуатации, то придется создать как минимум три домена. При этом грамотно настроеная среда промышленной эксплуатации подразумевает кластеризацию и соответствующее увеличение экземпляров домена. К счастью, процесс создания домена можно автоматизировать с помощью утилиты WebLogic Scripting Tool (WLST).

Потоки в управляемой среде. WorkManager

Вся мощь серверов приложений проявляется в том, что они обеспечивают управляемую среду исполнения программ. С одной стороны это обозначает, что сервер приложений предоставляет некий набор API, например JSR-316 - Java EE 6, а с другой - сервер приложений предоставляет средства, обеспечивающие управление жизненным циклом программы, транзакциями, доступом к ресурсам и другим системам, а так же потоками.

Пул потоков

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

Администратор сервера приложений может настроить следующие параметры пула:

• Приоритет потоков - параметр позволяет ранжировать потоки, создаваемые разными пулами, по приоритету. Таким образом можно настроить поведение при котором запрос пользователя к критичному для бизнеса приложению приостанавливает другие потоки в системе.
  
  
• Количество потоков в пуле - параметр позволяет задать минимальное и максимальное количество потоков, находящихся в пуле. При этом современные сервера приложений, например Oracle WebLogic, позволяют не ограничивать максимальное значение потоков в пуле константой, а указать источник данных (пул соединений с базой данных), на основе которого данное значение будет вычисляться. Таким образом обеспечивается полное однозначное соответствие - одно соединение с базой данных на один поток.
  
  

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

Установка и использование WebLogic Server 12c в версии для разработчиков

На прошлой неделе Oracle сделала доступным для скачивания набор дистрибутивов сервера приложений нового поколения, основы линейки продуктов Oracle Fusion Middleware, - WebLogic Server 12c. Данный продукт доступен как в виде инсталляторов под Windows, Linux и Mac OS X, так и в виде двух ZIP-архивов, предназначенных исключительно для разработчиков. В данной заметке мы рассмотрим как установить WebLogic Server из данных архивов и создать демонстрационный домен, а так же написать и развернуть в данном домене небольшое Java EE 6 приложение, используя Oracle Enterprise Pack for Eclipse 12.1.1.

Анонсирован WebLogic Server 12c

C - обозначает Cloud.

Посмотрел две презентации, приуроченные к выходу Oracle Fusion Middleware WebLogic Server 12c. Обещают, что данный продукт будет доступен для скачивания с OTN на следующей неделе. Технический номер версии будет - 12.1.1. Вероятно, Oracle отказывается от принятой сейчас запутанной системы нумерации версий, при которой WebLogic Server 10.3.X называется WebLogic Server 11g, что не может не радовать. В 2012-м году обещали так же выход остальных компонентов Fusion Middleware, например - Oracle SOA Suite.

UPD 10.12.2011: WebLogic Server 12c доступен для скачивания на OTN.

Создаем кластер серверов приложений WebLogic: балансировка нагрузки, обнаружение ошибок, репликация сессий

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

В данной статье мы рассмотрим следующие вопросы:

1. Структура домена WebLogic.
2. Создание домена и объединение серверов в кластер.
3. Балансировка нагрузки с помощью HttpClusterServlet.
4. Репликация сессий между серверами кластера.
5. Балансировка нагрузки с помощью Apache 2.
6. Выводы.
7. Ресурсы.