Adobe Experience Manager(AEM)では、バイナリデータをコンテンツノードとは別に格納できます。バイナリデータはデータストアに格納され、コンテンツノードはノードストアに格納されます。
データストアとノードストアはどちらも OSGi 設定を使用して設定できます。各 OSGi 設定は、永続識別子(PID)を使用して参照されます。
ノードストアとデータストアの両方を設定するには、次の手順を実行します。
AEM クイックスタート JAR ファイルを AEM のインストールディレクトリにコピーします。
フォルダーの作成 crx-quickstart/install
をインストールディレクトリに追加します。
最初に、ノードストアを設定します。そのためには、使用するノードストアオプションの名前を持つ設定ファイルを crx-quickstart/install
ディレクトリに作成します。
例えば、ドキュメントノードストア (AEM MongoMK 実装の基盤 ) では、ファイルを使用します org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config
.
ファイルを編集し、設定オプションを設定します。
使用するデータストアの PID を持つ設定ファイルを作成します。ファイルを編集し、設定オプションを設定します。
AEM を起動します。
新しいバージョンの Oak では、OSGi 設定ファイルについて新しい命名スキームと形式を採用しています。新しい命名スキームでは、設定ファイルの名前に .config を付けることが規定されています。また、新しい形式では、値を型指定することが規定されています。こちらを参照してください。
古いバージョンの Oak からアップグレードする場合は必ず、crx-quickstart/install
フォルダーのバックアップを最初に作成してください。アップグレード後、アップグレードしたインストール環境にフォルダーの内容を復元し、設定ファイルの拡張子を .cfg から .config に変更します。
AEM 5.x のインストール環境からのアップグレードに備えてこの記事をお読みになっている場合は、アップグレードに関するドキュメントを先に参照してください。
セグメントノードストアは、AEM6 におけるアドビの TarMK 実装の基盤です。このストアでは、org.apache.jackrabbit.oak.segment.SegmentNodeStoreService
という PID を設定に使用します。
セグメントノードストアの PID が、 org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService in previous versions
AEM 6 から org.apache.jackrabbit.oak.segment.SegmentNodeStoreService
AEM 6.3 で、この変更を反映するために必要な設定の調整を行ってください。
以下のオプションを設定できます。
repository.home
:リポジトリのホームのパスです。リポジトリ関連のデータが格納されます。デフォルトでは、crx-quickstart/segmentstore
ディレクトリにセグメントファイルが格納されます。
tarmk.size
:セグメントの最大サイズ(MB 単位)です。デフォルトの最大サイズは 256 MB です。
customBlobStore
:カスタムデータストアが使用されることを示すブール値です。デフォルト値は、AEM 6.3 以降のバージョンでは true です。 AEM 6.3 より前のデフォルトは false でした。
以下はサンプルです org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
ファイル:
#Path to repo
repository.home="crx-quickstart/repository"
#Max segment size
tarmk.size=I"256"
#Custom data store
customBlobStore=B"true"
ドキュメントノードストアは、AEM MongoMK 実装の基礎です。 使用する org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService
PID. 以下の設定オプションを使用できます。
mongouri
:Mongo データベースに接続するために必要な MongoURI です。デフォルトは mongodb://localhost:27017
です
db
:Mongo データベースの名前です。デフォルト値は Oak です。ただし、新しい AEM 6 のインストールでは、デフォルトのデータベース名として aem-author が使用されます。
cache
:キャッシュサイズ(MB 単位)です。これは DocumentNodeStore で使用される様々なキャッシュに分散されます。デフォルトは、256
です。
changesSize
:Mongo で差分出力のキャッシュに使用される capped コレクションのサイズ(MB 単位)です。デフォルトは、256
です。
customBlobStore
:カスタムデータストアが使用されることを示すブール値です。デフォルトは、false
です。
以下はサンプルです org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config
ファイル:
#Mongo server details
mongouri="mongodb://localhost:27017"
#Name of Mongo database to use
db="aem-author"
#Store binaries in custom BlobStore
customBlobStore=B"false"
多数のバイナリを処理する場合は、最大限のパフォーマンスを確保するために、デフォルトのノードストアではなく外部のデータストアを使用することをお勧めします。
例えば、プロジェクトで多数のメディアアセットが必要な場合は、それらをファイルデータストアまたは S3 データストアに格納すると、MongoDB 内に直接格納するよりも迅速にアセットにアクセスできます。
ファイルデータストアを使用すると、MongoDB よりもパフォーマンスが向上します。多数のアセットがある場合は、Mongo のバックアップと復元の処理速度も低下します。
各種データストアと設定の詳細については後述します。
カスタムデータストアを有効にするには、それぞれのノードストア設定ファイル(customBlobStore
セグメントノードストアtrue
またはドキュメントノードストア)で が に設定されていることを確認する必要があります。
これは Jackrabbit 2 に含まれる FileDataStore の実装であり、バイナリデータを通常のファイルとしてファイルシステムに格納する手段を提供します。使用する org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore
PID.
以下の設定オプションを使用できます。
repository.home
:リポジトリのホームのパスです。リポジトリ関連の様々なデータが格納されます。デフォルトでは、バイナリファイルは次の場所に保存されます。 crx-quickstart/repository/datastore
ディレクトリ。
path
:ファイルを格納するディレクトリのパスです。指定した場合は、 repository.home
の値です。
minRecordLength
:データストアに格納するファイルの最小サイズ(バイト単位)です。この値よりも小さいバイナリコンテンツはインライン化されます。
NAS を使用して共有ファイルデータストアを格納する場合は、パフォーマンスの問題を回避するために、必ず高性能のデバイスのみを使用してください。
Amazon の Simple Storage Service(S3)にデータを格納するように AEM を設定できます。このストアでは、org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.config
という PID を設定に使用します。
S3 データストア機能を有効にするには、S3 データストアコネクタを含む機能パックをダウンロードしてインストールする必要があります。次に移動: Adobeリポジトリ および機能パックの 1.8.x バージョンから最新バージョンをダウンロードします(例:com.adobe.granite.oak.s3connector-1.8.0.zip)。 さらに、最新のAEMサービスパックをダウンロードしてインストールする必要があります。最新のサービスパックは、 AEM 6.4 Service Pack リリースノート ページ。
TarMK を選択して AEM 6.4 を使用する場合、デフォルトでは、FileDataStore
にバイナリが格納されます。S3 Datastore で TarMK を使用するには、 crx3tar-nofds
実行モード:例:
java -jar aem6.4.jar -r crx3tar-nofds
ダウンロードが完了したら、次の手順に従って S3 コネクタをインストールして設定できます。
機能パック zip ファイルの内容を一時フォルダーに解凍します。
一時フォルダーに移動し、次の場所に移動します。
jcr_root/libs/system/install
上記の場所からにすべてのコンテンツをコピーします。 <aem-install>/crx-quickstart/install.
AEMが既に Tar または MongoDB ストレージと連携するように設定されている場合は、既存の設定ファイルを aem-install/crx-quickstart/install
フォルダーを開いてから先に進みます。 削除する必要があるファイルは次のとおりです。
For MongoMK: org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config
For TarMK: org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
機能パックを展開した一時的な場所に戻り、次のフォルダーの内容をコピーします。
jcr_root/libs/system/config
コピー先:
<aem-install>/crx-quickstart/install
現在の設定に必要な設定ファイルのみをコピーしてください。専用データストアと共有データストアのどちらの設定の場合も、org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.config
ファイルをコピーします。
クラスターセットアップでは、前述の手順をクラスターのすべてのノードで 1 ノードずつ実行してください。また、すべてのノードで必ず同じ S3 設定を使用してください。
ファイルを編集し、設定に必要な設定オプションを追加します。
AEM を起動します。
新しいバージョンの 1.8.x S3 コネクタにアップグレードする必要がある場合は(1.8.0 から 1.8.1 へのアップグレードなど)、次の手順に従います。
AEM インスタンスを停止して
AEM インストールフォルダーの <aem-install>/crx-quickstart/install/15
に移動して、その内容のバックアップを作成します。
バックアップ後、 <aem-install>/crx-quickstart/install/15
フォルダーの例:
上述のファイル名は例として使用しているだけであり、他の名前である場合もあります。
アドビリポジトリから最新バージョンの 1.8.x 機能パックをダウンロードします。
内容を別のフォルダーに解凍し、に移動します。 jcr_root/libs/system/install/15
.
jar ファイルのコピー先 <aem-install>/crx-quickstart/install/15をAEMインストールフォルダーに追加します。
AEM を起動して、コネクタの機能を確認します。
次のオプションを指定して設定ファイルを使用できます。
accessKey:AWSアクセスキー。
secretKey:AWS 秘密アクセスキーです。注意: または、 IAM ロール は認証に使用できます。 IAM ロールを使用している場合、 accessKey
および secretKey
.
s3Bucket:バケット名です。
s3Region:バケットのリージョンです。
path:データストアのパスです。デフォルト値は <AEM install folder>/repository/datastore です。
minRecordLength:データストアに格納するオブジェクトの最小サイズです。最小/デフォルトはです。 16 KB。
maxCachedBinarySize:このサイズ以下のサイズのバイナリは、メモリキャッシュに格納されます。サイズはバイト単位です。デフォルトは17408 (17 KB) です。
cacheSize:キャッシュのサイズ。値はバイト単位で指定します。デフォルトはです。 64GB.
シークレット:共有データストアの設定にバイナリレスレプリケーションを使用する場合にのみ使用します。
stagingSplitPercentage:ステージング非同期アップロードで使用するように設定されたキャッシュサイズの割合。 デフォルト値は 10 です。
uploadThreads:非同期アップロードで使用されるアップロードスレッドの数です。 デフォルト値は 10 です。
stagingPurgeInterval:完了したアップロードをステージングキャッシュからパージする時間間隔(秒)。 デフォルト値は 300 秒(5 分)です。
stagingRetryInterval:失敗したアップロードの再試行間隔(秒)。 デフォルト値は 600 秒(10 分)です。
米国スタンダード | us-standard |
米国西部 | us-west-2 |
米国西部(北カリフォルニア) | us-west-1 |
欧州(アイルランド) |
EU |
アジアパシフィック(シンガポール) |
ap-southeast-1 |
アジアパシフィック(シドニー) |
ap-southeast-2 |
アジアパシフィック(東京) | ap-northeast-1 |
南米(サンパウロ) |
sa-east-1 |
データストアのキャッシュ
のデータストア実装 S3DataStore
, CachingFileDataStore
および AzureDataStore
ローカルファイルシステムのキャッシュをサポートします。 この CachingFileDataStore
DataStore が NFS (Network File System) 上にある場合、実装が役立ちます。
古いキャッシュ実装(Oak 1.6 より前)からアップグレードする場合は、ローカルファイルシステムのキャッシュディレクトリの構造に違いがあります。古いキャッシュ構造では、ダウンロードされたファイルとアップロードされたファイルの両方がキャッシュパスの直下に置かれていました。新しい構造では、ダウンロードとアップロードが分離され、キャッシュパスの下の upload
と download
という名前の 2 つのディレクトリに格納されます。アップグレードプロセスはシームレスにおこなわれ、保留中のアップロードがある場合はアップロードがスケジュールされ、キャッシュ内に以前にダウンロードされたファイルがある場合は初期化時にキャッシュに配置されます。
また、 datastorecacheupgrade
oak-run のコマンド。 このコマンドの実行方法について詳しくは、oak-run モジュールの readme を参照してください。
キャッシュにはサイズ制限があり、cacheSize パラメーターを使用して設定できます。
ダウンロード
データストアからアクセスする前に、要求されたファイル/Blob のレコードがローカルキャッシュでチェックされます。ファイルをキャッシュに追加しているときに、設定された制限(cacheSize
パラメーターを参照)をキャッシュが超えると、領域を再利用できるように、ファイルの一部が消去されます。
非同期アップロード
キャッシュでは、データストアへの非同期アップロードがサポートされています。ファイルは(ファイルシステム上の)キャッシュでローカルにステージングされ、非同期ジョブでファイルのアップロードが開始されます。非同期アップロードの数は、ステージングキャッシュのサイズによって制限されます。ステージングキャッシュのサイズは、stagingSplitPercentage
パラメーターを使用して設定します。このパラメーターでは、ステージングキャッシュに使用するキャッシュサイズの割合(%)を定義します。また、ダウンロードで使用可能なキャッシュの割合は、 (100 - stagingSplitPercentage
)*cacheSize
.
非同期アップロードはマルチスレッドで、スレッド数は uploadThreads
パラメーター。
アップロードが完了すると、ファイルはメインダウンロードキャッシュに移動します。ステージングキャッシュのサイズが制限を超えると、それまでの非同期アップロードが完了して、ステージングキャッシュ内の領域を再び使用できるようになるまで、ファイルは同期的にデータストアにアップロードされます。アップロードされたファイルは、間隔がで設定された定期ジョブによってステージング領域から削除されます。 stagingPurgeInterval
パラメーター。
(ネットワークの障害などが原因で)失敗したアップロードは再試行キューに配置され、定期的に再試行されます。再試行間隔は、 stagingRetryInterval parameter
.
S3 によるバイナリなしのレプリケーションを設定するには、次の手順を実行する必要があります。
オーサーインスタンスとパブリッシュインスタンスをインストールし、それらが正しく開始されたことを確認します。
http://localhost:4502/etc/replication/agents.author/publish.html ページを開いて、レプリケーションエージェントの設定に移動します。
「設定」セクションの「編集」ボタンを押します。
「シリアル化の種類」オプションを「バイナリなし」に変更します。
パラメーター「 binaryless
= true
」と入力します。 変更後、URI は次のようになります。
http://localhost:4503/bin/receive?sling:authRequestLogin=1&binaryless=true
オーサーインスタンスとパブリッシュインスタンスをすべて再起動して、変更を有効にします。
次のコマンドを使用して CQ クイックスタートを展開します。
java -jar cq-quickstart.jar -unpack
AEM を展開したら、crx-quickstart/install フォルダーをインストールディレクトリ内に作成します。
次の 2 つのファイルを crx-quickstart
フォルダー内に作成します。
ファイルを作成したら、必要に応じて設定オプションを追加します。
S3 データストアで必要な、前述の 2 つのバンドルをインストールします。
MongoDB がインストールされていること、および mongod
のインスタンスが実行されていることを確認します。
次のコマンドを使用して AEM を起動します。
java -Xmx1024m -XX:MaxPermSize=256M -jar cq-quickstart.jar -r crx3,crx3mongo
2 つ目の AEM インスタンスについて手順 1 ~ 4 を繰り返します。
2 つ目の AEM インスタンスを起動します。
まず、データストアを共有するために必要なデータストア設定ファイルを各インスタンスで作成します。
FileDataStore
、という名前のファイルを作成します。 org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config
そして、 <aem-install>/crx-quickstart/install
フォルダー。rg.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.config
内 <aem-install>/crx-quickstart/install
フォルダーに保存します。同じデータストアを指すようにデータストア設定ファイルを各インスタンスで変更します。詳しくは、こちらの記事を参照してください。
インスタンスのクローンが既存のサーバーから作成された場合、リポジトリがオフラインになっている間に、最新の oak-run ツールを使用して新しいインスタンスの clusterId
を削除する必要があります。実行する必要があるコマンドは次のとおりです。
java -jar oak-run.jar resetclusterid < repository path | Mongo URI >
セグメントノードストアを設定する場合、リポジトリパスを指定する必要があります。デフォルトでは、パスは <aem-install-folder>/crx-quickstart/repository/segmentstore.
ドキュメントノードストアが設定されている場合、 Mongo 接続文字列 URI.
oak-run ツールは、次の場所からダウンロードできます。
https://mvnrepository.com/artifact/org.apache.jackrabbit/oak-run/
AEM インストールで使用している Oak バージョンに応じて、様々なバージョンのツールを使用する必要があることに注意してください。ツールを使用する前に、以下のバージョン要件を確認してください。
最後に、設定を検証します。そのためには、データストアを共有する各リポジトリによってデータストアに追加された一意のファイルを探す必要があります。ファイルの形式は、 repository-[UUID]
( UUID は、個々のリポジトリの一意の識別子です)。
つまり、正しい設定には、データストアを共有するリポジトリと同じ数の一意のファイルがあります。
ファイルは、データストアに応じて別々に格納されます。
FileDataStore
の場合、データストアフォルダーのルートパスにファイルが作成されます。S3DataStore
ファイルは、設定済みの S3 バケットの、 META
フォルダー。Microsoft の Azure ストレージサービスにデータを格納するように AEM を設定できます。このストアでは、org.apache.jackrabbit.oak.plugins.blob.datastore.AzureDataStore.config
という PID を設定に使用します。
Azure データストア機能を有効にするには、Azure コネクタを含む機能パックをダウンロードしてインストールする必要があります。次に移動: Adobeリポジトリ および機能パックの 1.6.x バージョンから最新バージョンをダウンロードします(例:com.adobe.granite.oak.azureblobconnector-1.6.3.zip)。
TarMK を選択して AEM 6.4 を使用する場合、デフォルトでは、FileDataStore にバイナリが格納されます。Azure DataStore で TarMK を使用するには、 crx3tar-nofds
実行モード:例:
java -jar aem6.4.jar -r crx3tar-nofds
ダウンロードが完了したら、次の手順に従って Azure コネクタをインストールして設定できます。
機能パック zip ファイルの内容を一時フォルダーに解凍します。
一時フォルダーに移動し、の内容をコピーします。 jcr_root/libs/system/install
から <aem-install>crx-quickstart/install
フォルダー。
AEMが既に Tar または MongoDB ストレージと連携するように設定されている場合は、既存の設定ファイルを /crx-quickstart/install
フォルダーを開いてから先に進みます。 削除する必要があるファイルは次のとおりです。
MongoMK の場合:
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config
TarMK の場合:
org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
機能パックが抽出された一時的な場所に戻り、の内容をコピーします。 jcr_root/libs/system/config
から <aem-install>/crx-quickstart/install
フォルダー。
設定ファイルを編集し、設定に必要な設定オプションを追加します。
AEM を起動します。
次のオプションを指定して設定ファイルを使用できます。
azureSas="":コネクタのバージョン 1.6.3 では、Azure Shared Access Signature(SAS) のサポートが追加されました。 SAS とストレージ資格情報の両方が設定ファイルに存在する場合は、SAS が優先されます。 SAS の詳細については、 公式ドキュメント. 「=」文字は必ず「=」のようにエスケープしてください。
azureBlobEndpoint="":Azure Blob エンドポイントです。例: https://<storage-account>.blob.core.windows.net.
accessKey="":ストレージアカウント名です。Microsoft Azure の認証の資格情報について詳しくは、公式ドキュメントを参照してください。
secretKey="":ストレージアクセスキーです。「=」文字は必ず「=」のようにエスケープしてください。
container="":Microsoft Azure の Blob ストレージコンテナ名です。コンテナは、一連の Blob をグループ化したものです。詳しくは、公式ドキュメントを参照してください。
maxConnections="":操作ごとの同時要求の数です。デフォルト値は 1 です。
maxErrorRetry="":リクエストあたりの再試行の数。 デフォルト値は 3 です。
socketTimeout="":要求に使用されるタイムアウト間隔(ミリ秒)。 デフォルト値は 5 分です。
上述の設定に加えて、次の設定も指定できます。
<aem-install>/repository/datastore.
すべての設定は引用符で囲む必要があります。次に例を示します。
accessKey="ASDASDERFAERAER"
secretKey="28932hfjlkwdo8fufsdfas\=\="
データストアのガベージコレクションプロセスは、データストア内の未使用のファイルを削除するために使用します。このプロセスによって、貴重なディスク領域が解放されます。
データストアのガベージコレクションは、次の方法で実行できます。
次の場所にある JMX コンソールに移動します。 https://<serveraddress:port>/system/console/jmx
RepositoryManagement を検索します。見つかった Repository Manager の MBean をクリックして、使用可能なオプションを表示します。
ページの末尾までスクロールして、「startDataStoreGC(boolean markOnly)」リンクをクリックします。
次に示すダイアログの false
パラメーターに markOnly
と入力して、「Invoke」をクリックします。
markOnly
パラメーターは、ガベージコレクションのスイープフェーズを実行するかどうかを示します。
クラスターまたは共有データストア設定(Mongo または Segment Tar を使用)でガベージコレクションを実行すると、特定の Blob ID を削除できないことについての警告がログに表示されることがあります。これは、以前のガベージコレクションで削除された BLOB ID が、ID 削除に関する情報を持たない他のクラスターまたは共有ノードによって誤って再び参照されるためです。 その結果、前回の実行時に既に削除された ID を、ガベージコレクションで再度削除しようとするので、警告がログに記録されます。この動作はパフォーマンスや機能に影響しません。
新しいバージョンの AEM では、複数のリポジトリによって共有されるデータストアでもガベージコレクションを実行できます。共有データストアでデータストアのガベージコレクションを実行できるようにするには、次の手順に従います。
データストアのガベージコレクション用に設定されたメンテナンスタスクが、データストアを共有するすべてのリポジトリインスタンスで無効になっていることを確認します。
次に示す手順を実行します: バイナリガベージコレクション 個別に すべて データストアを共有するリポジトリインスタンス。 ただし、必ず true
の markOnly
パラメーターを使用してから呼び出しボタンをクリックします。
前述の手順がすべてのインスタンスで完了したら、いずれかのインスタンスからデータストアのガベージコレクションを再び実行します。
false
の markOnly
パラメーターを再度設定します。これにより、以前に使用したマークフェーズで見つかったすべてのファイルを照合して、未使用の残りのファイルがデータストアから削除されます。