База данных
На первом месте идет организация доступа к базе данных.Нашей задачей является предоставление каждому экземпляру портала (узлу в нашей кластерной архитектуре) доступа к единому пространству данных.
Рассмотрим несколько вариантов решения данной задачи:
Все узлы кластера ссылаются на одну и ту же БД.
В данном случае каждый портал физически обращается одному и тому эе экземпляру БД.Распределение же данных и ресурсов отдается на откуп конкретной СУБД, поддерживающей механизмы кластеризации.
Пожалуй, самый простой вариант с точки зрения настройки портала, но требует знаний и навыков настройки отдельных СУБД.
Альтернатива. Read-Writer database configuration
Данных подход подразумевает, что мы создали две базы данных: одну, оптимизированную под запросы на чтение данных, а другую, оптимизированную под запросы на запись.Далее в свойствах портала мы указываем свойства соединения с обеими базами, а Liferay уже самостоятельно переадресует запросы на чтение в одну БД, а запросы на запсь в другую
Данный подход ничуть не сложнее предыдущего и также требует определенных навыков в настройке репликации данных между базами данных на уровне СУБД.
Альтернатива. Database sharding
Под словосочетанием "Database sharding" подразумевается распределение данных между различными базами данных, так называемое "горизонтальное разделение".Таким образом, каждая БД содержит в себе лишь часть данных, что положительно сказывается на производительности.
Причем Liferay предлагает несколько предустановленных алгоритмов распределения данных:
- RoundRobinShardSelector - позволяет распределять данные между различными эекземплярами портала.
То есть данные каждого экземпляра будут храниться в отдельной базе данных. Если же баз данных меньше чем экземпляров, то данные будут распределяться циклически. - ManualShardSelector - алгоритм аналогичен предыдущему, только позволяет самостоятельно указывать в какой БД должны храниться данные конкретного экземпляра портала.
Если предложенные варианты распределения не устраивают, то можно использовать самостоятельную реализацию.
Данный метод, отличается от предыдущих тем, что не требует опыта настройки репликации и кластеризации отдельных СУБД. И является, пожалуй, самым простым в настройке.
Репозиторий документов
Далее нам необходимо организовать единое пространство документов.С версии 6.1.0 Liferay обладает возможностью работать сразу с несколькими различными репозиториями одновременно.
Причем эти репозитории могут быть как встроенные в Liferay, так и внешние, расположенные на удаленных хостах.
В случае работы с внешними репозиториями, все просто - настройка кластеризации отдается на откуп производителю репозитория.
В случае же, когда Liferay настроен на работу со своим локальным репозиторием, настраивать работу придется самостоятельно.
Рассмотрим различные виды встроенных репозиториев:
File System store
Данный вид репозитория хранит все данные в файловой системе.Данные располагаются в строго определенной структуре подкаталогов относительно коренной директории репозитория.
Эта структура подкаталогов строится по строгому алгоритму, который переводит идентификатор документа, присвоенный ему в БД, в структуру подкаталогов.
Для обеспечения согласованности данных между различными узлами необходимо воспользоваться средствами ОС и смонтировать коренную директорию на все сервера. Таким образом все экземпляры портала будут работать с централизованным репозиторием.
Все возможные конфликты и блокировки одновременного доступа должны предотвращаться файловой системой.
Advanced File System store
Отличается от предыдущего вида репозитория только алгоритмом размещения документов в файловой системе (создает меньшее количество файлов в отдельной поддиректории, что положительно сказывается на времени доступа).Обладает тем же минусом - возможны конфликты и блокировки, если файловая система не имеет средств управления ими.
CMIS (Content Management Interoperability Services) store
Вместо встроенного репозитория можно использовать любой другой, реализующий доступ по протоколу CMIS.Протокол CMIS имеет средства управления одновременным доступом и предотвращает возникновение конфликтов и блокировок.
Таким образом нам необходимо установить внешний репозиторий, а затем настроить наш портал на его использование в качестве встроенного.
JCR (Java Content Repository) store
Liferay обладает встроенным репозиторием Apache Jack Rabbit.По-умолчанию он отключен, но может быть легко подключен через конфигурационный файл.
Сам по себе репозиторий использует один из двух типов хранения данных:
- в файловой системе, что сопряжено все с теми же проблемами синхронизации доступа;
- в БД - данный способ позволяет избавиться от проблем с конфликтами и блокировками, но может стать узким местом и уступает в производительности файловой системе
Amazon Simple Storage Service
В этом случае наш репозиторий располагается в "облаке". Нам достаточно указать авторизацонные данные - далее обо всем будет заботиться Amazon.Documentum store
Для Enterprise версии Liferay портала предоставляется плагин для интеграции с репозиторием Documentum.Задачи кластеризации в этом случае переносятся на сервер установки Documentum.
Поиск
После того как мы разобрались с данными перейдем к вопросу их индексирования и поиска по ним.По-умолчанию Liferay портал использует библиотеку Apache Lucene в качестве своего поискового движка.
Она работает замечательно, но до тех пор пока нам не потребуется кластеризация.
При кластерной организации портала возможны три варианта построения поисковых механизмов:
Подключаемая внешняя поисковая система - Solr
Данный вариант, по праву, считается самым верным решением организации поиска.Во-первых, он подразумевает выделение отдельной машины для нужд полнотекстовой индексации и поиска документов, что несомненно дает прирост производительности.
Во-вторых, он исклячает трудности синхронизации поисковых индексов, так как все узлы обращаются к централизованному серверу.
Принцип же настройки предельно прост:
- Устанавливаем поисковую систему. В данный момент Liferay портал поддерживает интеграцию с системой Apache Solr.
- Конфигурируем Liferay портал, такми образом, что он будет отправлять все запросы в Solr. Под запросами подразумеваются не только поисковые запросы, но и запросы на индексацию созданных или обновленных документов.
- Синхронизация полнотекстовых индексов Lucene между всеми узлами Данный вариант предлагает настроить портал так, чтобы каждое произведенное изменение распространялось сразу на все узлы.
- Общий поисковый индекс Данный подход подразумевает централизованное расположение всего поискового индекса.
При активном редактировании документов, данных подход может порождать большой объем сетевого трафика и сеть может стать узким местом.
Для этого нам придется выбрать между хранением индекса в базе данных и файловой системе.
Плюс файловой системы в скорости доступа, минус в возможных конфликтах одновременного доступа.
И наоборот, плюс базы данных в отсуствии проблем с одновременным доступом, а минус в низкой сокрости доступа.
Кэш
Кэш должен быть реплицирован среди всех узлов кластера.Liferay портал в качестве системы кэширования использует Ehcache.
И более того в стандартную поставку Liferay портала включены механизмы организации репликаци кэша.
Таким образом для включения механизма реплицирования кэша достаточно установить только одно свойство в конфигурации портала.
Далее необходимо протестировать работу приложения под нагрузкой и выявить слабые места.
Если такие места обнаружатся, то придется занятся оптимизацией параметро кэша.
Изменить базовые настройки кэша можно двумя способами:
- При помощи хука - предпочтительный вариант.
- При помощи редактрования настроек задеплоенного портала.
Стоит отметить, что механизм реплицирования организован следующим образом:
при изменении данных кэша на одном из узлов происходит передача изменений на все остальные узлы кластера по протоколу RMI, тем самым при активном редактировании данных сеть может стать слабым звеном цепи.
В Enterprise версии Liferay портал комплектуется альтернативным механизмом репликации, суть его сводится к использованию специальной шины передачи изменений, что приводит к уменьшению передаваемого трафика.
Деплой плагинов
На каждому узле кластера помимо самомго портала должен быть развернут идентичный набор портлетов.Для упрощения процесса деплоймента возможно:
- Настроить ферму на уровне сервера приложений. Таким образом, задеплоив плагины на одном узле, они автоматически будут распространены на все оставшиемся узлы.
- Вручную или скриптом деплоить плагины на каждый узел кластера.
Вот мы и разобрались с основными аспектами устройства кластера Liferay портала. В следующих статьях мы опробуем на практике эти подходы.
