Вы, безусловно, можете использовать одно и то же ведро S3 между экземплярами — на самом деле, это обычно используется вместе с репликацией без двоичных файлов от автора -> издателя (ов) и является проверенной и надежной конфигурацией.
Можно даже совместно использовать одно и то же ведро между совершенно разными средами (например, DEV/STAGE или BLUE/GREEN в вашем случае). Основная проблема, о которой следует помнить, связана со сборкой мусора DataStore (DSGC), потому что вполне возможно, что будут большие двоичные объекты, на которые ссылаются только некоторые экземпляры, совместно использующие ведро, и поэтому при очистке неиспользуемых больших двоичных объектов это необходимо принято во внимание.
Однако все это является частью дизайна, и есть флаг, разработанный специально для этой цели, который указывает DSGC выполнять только первую фазу (фазу «пометки») GC и пропускать 2-ю фазу «развертки», пока не будут выполнены все экземпляры. отметили, какие большие двоичные объекты они хотят сохранить/отбросить. После того, как все экземпляры сделали это, можно запустить фазу очистки, чтобы очистить большие двоичные объекты, которые не нужны никаким экземплярам, использующим ведро.
Более подробное объяснение см. в документации Oak: https://jackrabbit.apache.org/oak/docs/plugins/blobstore.html#Shared_DataStore_Blob_Garbage_Collection_Since_1.2.0
Я считаю, что полезно понять, что почти все реализации хранилища данных сделаны таким образом, что большие двоичные объекты хранятся в соответствии с их контрольной суммой, поэтому один и тот же файл, добавленный дважды, будет иметь только одну копию, хранящуюся в хранилище данных, и будет два хранилища сегментов. записи, ссылающиеся на тот же большой двоичный объект. Точно так же несколько экземпляров AEM, совместно использующих одно и то же ведро, смогут найти данный большой двоичный объект независимо от того, какой экземпляр поместил его туда в первую очередь.
Вы можете легко увидеть это в действии с помощью FileDataStore, найдя BLOB-объект и sha256 его - например. (этот пример для OS X, команда контрольной суммы в Linux/Windows будет немного отличаться):
$ shasum -a256 crx-quickstart/repository/datastore/0c/9e/40/0c9e405fc8d0f0405930cd0044611cfbf014938a1837ae0cfaa266d7732d1002
0c9e405fc8d0f0405930cd0044611cfbf014938a1837ae0cfaa266d7732d1002 crx-quickstart/repository/datastore/0c/9e/40/0c9e405fc8d0f0405930cd0044611cfbf014938a1837ae0cfaa266d7732d1002
Там вы можете видеть, что а) имя файла является контрольной суммой и б) оно вложено с использованием первых 3 пар символов из этой контрольной суммы, поэтому вы можете найти файл, просто зная хэш, и если вы сохраните тот же двоичный файл, даже если имя или метаданные JCR отличаются, ссылка на большой двоичный объект будет одним и тем же буквальным файлом на диске.
Из памяти S3 datastore использует префиксы, а не вложенность каталогов, потому что производительность выше, но принцип тот же.
Наконец, несколько вещей, которые следует учитывать:
1) Хранилище S3 относительно дешевое (и практически неограниченное), поэтому можно привести аргумент, что выполнять обычный DSGC не так уж необходимо, если вы действительно не пытаетесь сэкономить копейки.
2) Если вы используете DSGC, вам нужно подумать о том, как это будет работать с любой стратегией резервного копирования, которую вы используете для экземпляров AEM. Например, если вы откатываете хранилище сегментов вскоре после запуска DSGC, вам, вероятно, придется восстановить некоторые из этих очищенных BLOB-объектов. Вы можете использовать правила управления версиями и/или жизненного цикла, чтобы помочь в этом, но это может значительно увеличить сложность и время процесса восстановления.
Если вы решите просто пропустить DSGC и оставить большие двоичные объекты там на неопределенный срок, рекомендуется убедиться, что ключ доступа или роли IAM, которые использует AEM, не имеют разрешения DeleteObject для корзины, просто чтобы убедиться, что мошеннический процесс GC может ничего не удалять.
Надеюсь это поможет.
Редактировать Во всем этом я забыл ответить на ваш вопрос - да, в большинстве случаев это сэкономит время при клонировании. Вам по-прежнему необходимо синхронизировать хранилище сегментов (очевидно), и для этого существуют различные подходы. crx2oak, безусловно, один из них — вы увидите в документации, что есть специальные варианты его использования с S3, где вы предоставляете файл конфигурации (в основном сериализованный файл .config, который вы использовали бы с Felix/OSGi).
Вы также можете использовать что-то вроде rsync, чтобы просто скопировать файлы TAR (по крайней мере, целевой AEM остановлен. Дуб, как правило, атомарный, поэтому горячая копия из источника может работать теоретически, но YMMV).
Наконец, вы, очевидно, можете использовать Mongo и кластеризовать хранилище сегментов таким образом, но при этом применяются все обычные проблемы стоимости/сложности/производительности).
Еще одна интересная разработка для сине-зеленого шрифта на горизонте — это CompositeNodeStore — об этом говорится в хорошем выступлении на конференции adaptTo() 2017 года:
https://adapt.to/2017/en/schedule/zero-downtime-deployments-for-the-sling-based-apps-using-docker.html
person
David J
schedule
19.06.2018
