Настройка Jackrabbit в кластерной среде

Question

Я хочу настроить Jackrabbit в кластере (я настраиваю его с помощью Liferay).

Я прочитал этот документ - http://wiki.apache.org/jackrabbit/Clustering, к сожалению, он очень короткий, поэтому я непонять некоторые концепции и лучшие практики.Позвольте мне сначала объяснить, какие у меня настройки:

у нас есть 2 веблогических сервера, которые используют одну и ту же файловую систему, и мы развернем одну и ту же войну для обеих веблогик.Я использую Oracle в качестве базы данных (у меня есть пул соединений, настроенный в WL, и я хочу подключиться с использованием JNDI)

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

Оба узла совместно используют PersistranceManager, файловую систему хранилища и хранилище данных (если у меня есть и)

Вот вопросы:

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

2. Я хочу, чтобы производительность была лучшей, я выигралМне не нужно много контента и пользователей (10 пользователей одновременно), поэтому я хочу оптимизировать время загрузки страницы для более быстрого рендеринга страниц.Какова была бы лучшая практика - я должен настроить PersistanceManager для перехода на БД?

3. где должна указывать файловая система репозитория на каждом узле?

4. где должны указывать рабочие пространства на каждом узле?

5. где должна указывать файловая система рабочего пространства?

Я пытался указать все из них на мою базу данных, но у меня, кажется, есть тупики (или база данных работает слишком медленно).

И я включил ведение журнала и вижумного ненужных чтений, похоже, что при каждой загрузке файла jackrabbit открывает соединение, предварительно кэширует все файлы, закрывает и делает это несколько раз (занимает около минуты), чтобы загрузить очень маленький файл, скорее всего, что-то не так с моимconfig.

Вот мой конфигурационный файл:

<?xml version="1.0"?>
<Repository>
<FileSystem class="org.apache.jackrabbit.core.fs.db.OracleFileSystem">
        <param name="driver" value="javax.naming.InitialContext"/>
        <param name="url" value="ISG" />

    <param name="schema" value="oracle"/>
    <param name="schemaObjectPrefix" value="J_R_FS_"/>
</FileSystem>
<Security appName="Jackrabbit">
    <AccessManager class="org.apache.jackrabbit.core.security.SimpleAccessManager" />
    <LoginModule class="org.apache.jackrabbit.core.security.SimpleLoginModule">
        <param name="anonymousId" value="anonymous" />
    </LoginModule>
</Security>
<Workspaces rootPath="${rep.home}/workspaces" defaultWorkspace="liferay" />
<Workspace name="${wsp.name}">
    <PersistenceManager class="org.apache.jackrabbit.core.persistence.db.OraclePersistenceManager">
            <param name="driver" value="javax.naming.InitialContext"/>
            <param name="url" value="ISG" />
        <param name="tableSpace" value="" />

        <param name="schema" value="oracle" />
        <param name="schemaObjectPrefix" value="J_PM_${wsp.name}_" />
        <param name="externalBLOBs" value="false" />
    </PersistenceManager>

    <FileSystem class="org.apache.jackrabbit.core.fs.db.OracleFileSystem">
            <param name="driver" value="javax.naming.InitialContext"/>
            <param name="url" value="ISG" />
        <param name="tableSpace" value="" />

        <param name="schema" value="oracle"/>
        <param name="schemaObjectPrefix" value="J_FS_${wsp.name}_"/>
    </FileSystem>
</Workspace>
<Versioning rootPath="${rep.home}/version">
    <FileSystem class="org.apache.jackrabbit.core.fs.db.OracleFileSystem">
            <param name="driver" value="javax.naming.InitialContext"/>
            <param name="url" value="ISG" />

        <param name="schema" value="oracle"/>
        <param name="schemaObjectPrefix" value="J_V_FS_"/>
    </FileSystem>
    <PersistenceManager class="org.apache.jackrabbit.core.persistence.db.OraclePersistenceManager">
            <param name="driver" value="javax.naming.InitialContext"/>
            <param name="url" value="ISG" />
        <param name="tableSpace" value="" />

        <param name="schema" value="oracle" />
        <param name="schemaObjectPrefix" value="J_V_PM_" />
        <param name="externalBLOBs" value="false" />
    </PersistenceManager>
</Versioning>

<Cluster id="node_1" syncDelay="2000">
  <Journal class="org.apache.jackrabbit.core.journal.OracleDatabaseJournal">
        <param name="revision" value="${rep.home}/revision.log"/>
            <param name="driver" value="javax.naming.InitialContext"/>
            <param name="url" value="ISG" />
        <param name="tableSpace" value="" />

        <param name="schema" value="oracle"/>
        <param name="schemaObjectPrefix" value="J_C_"/>
    </Journal>
</Cluster>
</Repository>

Answer 1

Официальная документация Liferay рекомендует делиться данными Jackrabbit с использованием базы данных в кластерном сценарии, а не файловой системы.

Допустим, вы используете файловую систему на каждом из ваших узлов Liferay (это стандартная конфигурация Liferay). Узел A не сможет получить доступ к данным Jackrabbit на узле B и наоборот. Со временем узлы становятся все более несинхронными. Чтобы обойти это, вы можете создать сетевой ресурс и настроить каждый узел так, чтобы он указывал на общий ресурс. Проблема в том, что это может привести к повреждению файла, если каждый из узлов Liferay пишет одновременно.

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

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

Редактировать - дополнение: в какой-то момент в версии 5.2 был добавлен AdvancedFileSystemHook, который устраняет проблемы с повреждением файлов и проблемы с блокировкой при использовании общей сетевой файловой системы. Чтобы реализовать это, измените файл portal-ext.properties на использование AdvancedFileSystemHook, перенесите данные в общую папку, укажите горизонтальные узлы в общей папке.

Answer 2

Обязателен ли кролик? Liferay использует механизм хранения для хранения «просто» двоичных данных, все метаданные находятся в базе данных Liferay, поэтому вы не получите многого от репозитория JCR. Это прискорбно, но работает текущая реализация.

Next: Вы настраиваете кластер Jackrabbit или Liferay? Для кластера Jackrabbit (в среде с одним узлом Liferay) я не могу помочь. Если вы кластеризуете Liferay, вы найдете некоторую информацию в руководстве администратора (перейдите по ссылке pdf - к сожалению, прямая ссылка на главу кластеризация в html не работает, но вы найдите главу в pdf - там это работает.)

Некоторые подробности о кластеризации Liferay:

Liferay ожидает, что библиотека документов будет «атомарной», то есть документ, написанный на одном из узлов Liferay, должен быть немедленно читаемым на любом другом узле в кластере Liferay. Решение jackrabbit, которое вы найдете в руководстве по администрированию, заставляет jackrabbit использовать базу данных для обмена. Но вы увидите, что рекомендуемым решением является не использование Jackrabbit, а AdvancedFilesystemHook - кроме стандартного FileSystemHook, он хранит документы в нескольких подкаталогах (работает на общих сетевых ресурсах, рекомендуется SAN). FileSystemHook по умолчанию ограничен количеством файлов, разрешенных (для ОС) в одном каталоге, AdvancedFileSystemHook обойдет это путем создания нескольких подкаталогов (например, каталога unix mailspool). Если это только для «нескольких» документов - без достижения предела ОС - я ожидаю, что FileSystemHook также будет работать с общим каталогом, но я не совсем уверен в проблемах блокировки файлов там.

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

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