TarMK コールドスタンバイによる AEM の実行方法

概要

Tar Micro Kernel のコールドスタンバイ機能では、1 つ以上のスタンバイ AEM インスタンスをプライマリインスタンスに接続することができます。同期プロセスは、プライマリインスタンスからスタンバイインスタンスの方向のみ実行されるという意味で単方向です。

スタンバイインスタンスの目的は、マスターリポジトリのライブデータのコピーを保証して、マスターが何らかの理由で利用できなくなった場合にデータ損失なしにすぐに切り替えられるようにすることです。

コンテンツはプライマリインスタンスとスタンバイインスタンス間で線形的に同期されます。この際、ファイルやリポジトリの破損に関する整合性チェックは実行されません。このような設計であるので、スタンバイインスタンスはプライマリインスタンスの完全なコピーであり、プライマリインスタンスの不整合を軽減するものではありません。

仕組み

プライマリ AEM インスタンスでは、TCP ポートが開かれて、受信メッセージをリスニングしています。現時点で、スレーブがマスターに送信するメッセージには次の 2 つのタイプがあります。

• 現在のヘッドのセグメント ID を要求するメッセージ
• 指定した ID のセグメントデータを要求するメッセージ

スタンバイは、プライマリの現在のヘッドのセグメント ID を定期的に要求します。そのセグメントがローカルに存在しない場合は、セグメントを取得します。既存のセグメントの場合は、セグメントを比較して、必要に応じて参照先のセグメントも要求します。

一般的な TarMK コールドスタンバイデプロイメント：

その他の特徴

堅牢性

接続およびネットワーク関連の問題を自動的に検出して処理するようにデータフローが設計されています。すべてのパケットにチェックサムが付属し、接続の問題やパケットの損失が発生するとただちに再試行メカニズムがトリガーされます。

パフォーマンス

プライマリインスタンスで TarMK コールドスタンバイを有効にしても、パフォーマンスへの影響はほぼありません。CPU 使用率はほとんど増加せず、追加のハードディスクやネットワーク I/O によるパフォーマンスの問題は発生しない見込みです。

スタンバイでは、同期プロセスの実行中に高い CPU 使用率になることが予想されます。この処理はマルチスレッドではないので、複数のコアの利用による高速化は図れません。変更されたデータや送信されるデータがない場合は、測定可能なアクティビティは発生しません。接続速度は、ハードウェアおよびネットワーク環境によって変わりますが、リポジトリのサイズや SSL の利用とは関係ありません。初期の同期に必要になる時間を推測するときや、プライマリノードでしばらく大量のデータが変更されたときには、この点に注意してください。

セキュリティ

すべてのインスタンスが同じイントラネットのセキュリティゾーン内で実行されると想定すると、セキュリティ侵害のリスクは大幅に軽減されます。それでも、スレーブとマスター間での SSL 通信を有効にして、一層のセキュリティレイヤーを追加できます。この構成によって、データが中間者によって侵害される可能性が低下します。

さらに、受信する要求の IP アドレスを制限することで、接続を許可するスタンバイインスタンスを指定できます。この指定によって、イントラネット内でリポジトリをコピーできないことを保証できます。

AEM TarMK コールドスタンバイセットアップの作成

TarMK コールドスタンバイセットアップを作成するには、まずプライマリのインストールフォルダー全体のファイルシステムコピーを実行して新しい場所にコピーし、スタンバイインスタンスを作成する必要があります。その後、各インスタンスを、その役割を示す実行モード（primary または standby）で起動することができます。

以下に、1 つのマスターインスタンスと 1 つのスタンバイインスタンスによるセットアップを作成するために実行する必要のある手順を示します。

1. AEM をインストールします。

2. インスタンスをシャットダウンし、コールドスタンバイインスタンスを実行する場所にインストールフォルダーをコピーします。異なるマシンから実行する場合でも、各フォルダーにわかりやすい名前を付けて（aem-primary や aem-standby など）、各インスタンスを区別するようにしてください。

3. プライマリインスタンスのインストールフォルダーに移動し、次の手順を実行します。

   1. aem-primary/crx-quickstart/install下に存在する可能性のある以前のOSGi設定を確認して削除します
   2. aem-primary/crx-quickstart/installの下にinstall.primaryという名前のフォルダーを作成
   3. aem-primary/crx-quickstart/install/install.primaryの下に、事前に設定したノードストアとデータストアに必要な構成を作成します
   4. org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config というファイルを同じ場所に作成し、適切に設定します。設定オプションについて詳しくは、設定を参照してください。
   5. AEM TarMKインスタンスを外部データストアと共に使用する場合は、aem-primary/crx-quickstart/installの下にcrx3という名前のフォルダーcrx3を作成します
   6. データストア設定ファイルを crx3 フォルダーに配置します。

   例えば、外部ファイルデータストアを使用して AEM TarMK インスタンスを実行している場合は、次の設定ファイルが必要です。

   • aem-primary/crx-quickstart/install/install.primary/org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
   • aem-primary/crx-quickstart/install/install.primary/org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config
   • aem-primary/crx-quickstart/install/crx3/org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config

   以下に、プライマリインスタンスのサンプル設定を示します。

   org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config のサンプル

   org.apache.sling.installer.configuration.persist=B"false"
   customBlobStore=B"true"
   standby=B"false"
   

   org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config のサンプル

   org.apache.sling.installer.configuration.persist=B"false"
   mode="primary"
   port=I"8023"
   

   org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config のサンプル

   org.apache.sling.installer.configuration.persist=B"false"
   path="./crx-quickstart/repository/datastore"
   minRecordLength=I"16384"
   

4. プライマリ実行モードを指定して、プライマリを起動します。

   java -jar quickstart.jar -r primary,crx3,crx3tar
   

5. org.apache.jackrabbit.oak.segment パッケージに対して、新しい Apache Sling Logging Logger を作成します。ログレベルを「デバッグ」に設定し、ログの出力先を個別のログファイル（ /logs/tarmk-coldstandby.log など）に指定します。詳しくは、ログを参照してください。

6. スタンバイ​インスタンスの場所に移動し、jar を実行して起動します。

7. プライマリと同じログ設定を作成します。その後、インスタンスを停止します。

8. 次に、スタンバイインスタンスの準備をおこないます。そのためには、プライマリインスタンスの場合と同様の手順を実行します。

   1. aem-standby/crx-quickstart/install以下にある可能性のあるファイルを削除します。

   2. aem-standby/crx-quickstart/installの下にinstall.standbyという名前の新しいフォルダーを作成します

   3. 次の 2 つの設定ファイルを作成します。

      • org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
      • org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config

   4. aem-standby/crx-quickstart/installの下にcrx3という名前の新しいフォルダーを作成します

   5. データストア設定を作成し、aem-standby/crx-quickstart/install/crx3の下に配置します。 この例では、作成する必要があるファイルは次のとおりです。

      • org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config

   6. ファイルを編集し、必要な設定を作成します。

   以下に、典型的なスタンバイインスタンスのサンプル設定ファイルを示します。

   org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config のサンプル

   org.apache.sling.installer.configuration.persist=B"false"
   name="Oak-Tar"
   service.ranking=I"100"
   standby=B"true"
   customBlobStore=B"true"
   

   org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config のサンプル

   org.apache.sling.installer.configuration.persist=B"false"
   mode="standby"
   primary.host="127.0.0.1"
   port=I"8023"
   secure=B"false"
   interval=I"5"
   standby.autoclean=B"true"
   

   org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config のサンプル

   org.apache.sling.installer.configuration.persist=B"false"
   path="./crx-quickstart/repository/datastore"
   minRecordLength=I"16384"
   

9. スタンバイ実行モードを使用して​スタンバイ​インスタンスを起動します。

   java -jar quickstart.jar -r standby,crx3,crx3tar
   

このサービスは、次の手順により Web コンソール経由で設定することもできます。

1. Webコンソールへのアクセス先：https://serveraddress:serverport/system/console/configMgr
2. Apache Jackrabbit Oak Segment Tar Cold Standby Service​というサービスを探し、重複がそれをクリックして設定を編集します。
3. 設定を保存してインスタンスを再起動し、新しい設定を有効にします。

初回の同期

準備が完了した後のスタンバイの初回起動時には、スタンバイがプライマリにキャッチアップすることから、インスタンス間のネットワークトラフィックが大量に発生します。ログを見ながら、同期のステータスを観察することができます。

スタンバイの tarmk-coldstandby.log では、次のようなエントリを確認できます。

    *DEBUG* [defaultEventExecutorGroup-2-1] org.apache.jackrabbit.oak.segment.standby.store.StandbyStore trying to read segment ec1f739c-0e3c-41b8-be2e-5417efc05266

    *DEBUG* [nioEventLoopGroup-3-1] org.apache.jackrabbit.oak.segment.standby.codec.SegmentDecoder received type 1 with id ec1f739c-0e3c-41b8-be2e-5417efc05266 and size 262144

    *DEBUG* [defaultEventExecutorGroup-2-1] org.apache.jackrabbit.oak.segment.standby.store.StandbyStore got segment ec1f739c-0e3c-41b8-be2e-5417efc05266 with size 262144

    *DEBUG* [defaultEventExecutorGroup-2-1] org.apache.jackrabbit.oak.segment.file.TarWriter Writing segment ec1f739c-0e3c-41b8-be2e-5417efc05266 to /mnt/crx/author/crx-quickstart/repository/segmentstore/data00016a.tar

スタンバイの error.log では、次のようなエントリを確認できます。

*INFO* [FelixStartLevel] org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService started standby sync with 10.20.30.40:8023 at 5 sec.

このログの 10.20.30.40 は、プライマリの IP アドレスです。

プライマリ の tarmk-coldstandby.log では、次のようなエントリを確認できます。

    *DEBUG* [nioEventLoopGroup-3-2] org.apache.jackrabbit.oak.segment.standby.store.CommunicationObserver got message ‘s.d45f53e4-0c33-4d4d-b3d0-7c552c8e3bbd’ from client c7a7ce9b-1e16-488a-976e-627100ddd8cd

    *DEBUG* [nioEventLoopGroup-3-2] org.apache.jackrabbit.oak.segment.standby.server.StandbyServerHandler request segment id d45f53e4-0c33-4d4d-b3d0-7c552c8e3bbd

    *DEBUG* [nioEventLoopGroup-3-2] org.apache.jackrabbit.oak.segment.standby.server.StandbyServerHandler sending segment d45f53e4-0c33-4d4d-b3d0-7c552c8e3bbd to /10.20.30.40:34998

    *DEBUG* [nioEventLoopGroup-3-2] org.apache.jackrabbit.oak.segment.standby.store.CommunicationObserver did send segment with 262144 bytes to client c7a7ce9b-1e16-488a-976e-627100ddd8cd

この場合、ログに示されている「client」は​スタンバイ​インスタンスのことです。

これらのエントリがログに記録されなくなったら、同期プロセスが完了したと見なして問題ありません。

前述のエントリはポーリングメカニズムが正常に機能していることを示しますが、多くの場合、ポーリングが発生している間にデータが同期されているかどうかを把握するために役立ちます。これを行うには、次のようなエントリを探します。

*DEBUG* [defaultEventExecutorGroup-156-1] org.apache.jackrabbit.oak.segment.file.TarWriter Writing segment 3a03fafc-d1f9-4a8f-a67a-d0849d5a36d5 to /<<CQROOTDIRECTORY>>/crx-quickstart/repository/segmentstore/data00014a.tar

また、非共有 FileDataStore での実行時には、バイナリファイルが正しく送信されていることを示す次のようなメッセージが表示されます。

*DEBUG* [nioEventLoopGroup-228-1] org.apache.jackrabbit.oak.segment.standby.codec.ReplyDecoder received blob with id eb26faeaca7f6f5b636f0ececc592f1fd97ea1a9#169102 and size 169102

設定

Cold Standby サービスでは次の OSGi 設定を利用できます。

• Persist Configuration：​有効にした場合、従来の OSGi 設定ファイルではなくリポジトリに設定が保存されます。本番システムでは、プライマリ設定がスタンバイによって取得されないように、この設定を無効にすることを推奨します。

• モード(mode): これは、インスタンスの実行モードを選択します。

• Port (port)：​通信に使用するポート。デフォルトは、8023 です。

• プライマリホスト(primary.host): — プライマリインスタンスのホスト。この設定は、スタンバイにのみ適用されます。

• 同期間隔(interval): — この設定は、同期要求間隔を決定し、スタンバイインスタンスにのみ適用されます。

• Allowed IP-Ranges (primary.allowed-client-ip-ranges): — プライマリが接続を許可するIP範囲。

• セキュア(secure):SSL暗号化を 有効にします。この設定を利用するには、すべてのインスタンスで有効にする必要があります。

• スタンバイ読み取りタイムアウト(standby.readtimeout)：スタンバイインスタンスから発行された要求の タイムアウト（ミリ秒）。推奨されるタイムアウト設定は 43200000 です。通常、タイムアウトは 12 時間以上の値に設定することをお勧めします。

• スタンバイ自動クリーンアップ(standby.autoclean)：同期サイクルでストアのサイズが増加した場合に、クリーンアップメソッドを 呼び出します。

フェイルオーバー手順

何らかの理由でプライマリインスタンスに障害が発生した場合、以下の方法で起動時の実行モードを変更して、プライマリの役割を引き継ぐようにスタンバイインスタンスのいずれかを設定することができます。

1. スタンバイインスタンスがインストールされている場所に移動して、そのインスタンスを停止します。

2. このセットアップでロードバランサーを設定している場合は、この時点でロードバランサーの設定からプライマリを削除できます。

3. スタンバイのインストールフォルダーから crx-quickstart フォルダーをバックアップします。このフォルダーは、新しいスタンバイのセットアップ時に開始点として使用できます。

4. primary 実行モードを使用してインスタンスを再起動します。

   java -jar quickstart.jar -r primary,crx3,crx3tar
   

5. ロードバランサーに新しいプライマリを追加します。

6. 新しいスタンバイインスタンスを作成して起動します。詳しくは、前述の AEM TarMK コールドスタンバイセットアップの作成を参照してください。

コールドスタンバイセットアップへのホットフィックスの適用

コールドスタンバイセットアップにホットフィックスを適用する推奨方法は、ホットフィックスをプライマリインスタンスにインストールし、ホットフィックスがインストールされた新しいコールドスタンバイインスタンスにクローニングすることです。

これをおこなうには、次に示す手順に従います。

1. JMXコンソールに移動し、org.apache.jackrabbit.oakを使用して、コールドスタンバイインスタンスで同期プロセスを停止します。ステータス（「スタンバイ」） Bean。 この方法の詳細については、監視の節を参照してください。
2. コールドスタンバイインスタンスを停止します。
3. プライマリインスタンスにホットフィックスをインストールします。修正プログラムのインストール方法について詳しくは、パッケージの使用方法を参照してください。
4. インストール後の問題についてインスタンスをテストします。
5. コールドスタンバイインスタンスのインストールフォルダーを削除して、コールドスタンバイインスタンスを削除します。
6. プライマリインスタンスを停止し、インストールフォルダー全体をコールドスタンバイの場所にファイルシステムコピーして、クローンを作成します。
7. 新しく作成したクローンをコールドスタンバイインスタンスとして機能するように再設定します。詳しくは、AEM TarMK コールドスタンバイセットアップの作成を参照してください。
8. プライマリインスタンスとコールドスタンバイインスタンスの両方を起動します。

監視

この機能は、JMXまたはMBeanを使用して情報を公開します。これを行うには、JMXコンソールを使用して、スタンバイとマスターの現在の状態を調べます。 この情報は、type org.apache.jackrabbit.oak:type="Standby" StatusというMBeanで確認できます。

スタンバイ

スタンバイインスタンスを観察する際には、1 つのノードを公開します。その ID は通常、汎用 UUID です。

このノードには次の 5 つの読み取り専用属性があります。

• Running: 同期プロセスが実行中かどうかを示すboolean値。
• Mode: クライアント：インスタンスの識別に使用されるUUIDが続きます。この UUID は、設定が更新されるたびに変更されます。
• Status: 現在の状態をテキスト形式で表したもの( running やなど stopped)。
• FailedRequests:連続したエラーの数。
• SecondsSinceLastSuccess: サーバーとの最後の通信が成功してからの秒数。通信が成功しない場合は-1と表示されます。

次のような 3 つの呼び出し可能なメソッドもあります。

• start(): 同期プロセスの開始。
• stop(): 同期処理を停止します。
• cleanup(): スタンバイでクリーンアップ操作を実行します。

プライマリ

プライマリを観察することで、MBean 経由で一般的な情報を取得できます。この MBean の ID 値は、TarMK スタンバイサービスが使用しているポート番号（デフォルトは 8023）です。メソッドと属性の大部分はスタンバイと同じですが、次の点で一部異なります。

• Mode: は常に値を表示し primaryます。

さらに、マスターに接続する最大 10 のクライアント（スタンバイインスタンス）の情報を取得できます。MBean ID はインスタンスの UUID です。これらの MBean には呼び出し可能なメソッドはありませんが、次のように非常に便利な読み取り専用属性が存在します。

• Name: クライアントのID。
• LastSeenTimestamp: テキスト表現での最後の要求のタイムスタンプ。
• LastRequest: クライアントの最後のリクエスト。
• RemoteAddress: クライアントのIPアドレス。
• RemotePort: クライアントが最後の要求に使用したポート。
• TransferredSegments: このクライアントに転送されたセグメントの合計数。
• TransferredSegmentBytes:このクライアントに転送された合計バイト数。

コールドスタンバイリポジトリのメンテナンス

リビジョンクリーンアップ

Adobeでは、時間の経過とともに過剰なリポジトリの増大を防ぐため、定期的にメンテナンスを実行することを推奨しています。 コールドスタンバイリポジトリのメンテナンスを手動で実行するには、次の手順に従います。

1. JMX コンソールに移動し、org.apache.jackrabbit.oak: Status（"Standby"） bean を使用して、スタンバイインスタンスでスタンバイプロセスを停止します。この方法について詳しくは、監視に関する前述の節を参照してください。

2. プライマリ AEM インスタンスを停止します。

3. プライマリインスタンスで oak コンパクションツールを実行します。詳しくは、リポジトリの管理を参照してください。

4. プライマリインスタンスを起動します。

5. 最初の手順で説明したものと同じ JMX bean を使用して、スタンバイインスタンスでスタンバイプロセスを開始します。

6. ログを監視し、同期が完了するまで待ちます。この時点で、スタンバイリポジトリの大幅な増加が見られる可能性があります。

7. 最初の手順で説明したとおりに、同じJMX Beanを使用して、スタンバイインスタンスでcleanup()操作を実行します。

オフラインコンパクションではリポジトリ履歴が実質的には書き直されるので、リポジトリでの変更の計算により多くの時間がかかり、スタンバイインスタンスとプライマリとの同期が完了するまで通常より時間がかかる場合があります。また、このプロセスが完了した後は、スタンバイ側のリポジトリのサイズは、プライマリ側のリポジトリとほぼ同じサイズになることに注意してください。

別の方法として、プライマリでコンパクションを実行した後にプライマリリポジトリをスタンバイに手動でコピーすることもできます。つまり、コンパクションを実行するたびにスタンバイを再構築します。

データストアのガベージコレクション

ファイルデータストアインスタンスに対してガベージコレクションをときどき実行することが重要です。そうしないと、削除されたバイナリがファイルシステムに残り、最終的にドライブがいっぱいになります。ガベージコレクションを実行するには、次の手順に従います。

1. の<a0/>セクションの説明に従って、コールドスタンバイリポジトリメンテナンスを実行します。

2. メンテナンスプロセスが完了し、インスタンスが再起動したら、次の手順を実行します。

   • 主に、この記事で説明されているように、関連するJMX Beanを介してデータストアのガベージコレクションを実行します。
   • スタンバイ時には、データストアのガベージコレクションは、BlobGarbageCollection MBean - startBlobGC()経由でのみ利用できます。 RepositoryManagement MBeanはスタンバイでは使用できません。
   メモ

   共有データストアを使用していない場合は、ガベージコレクションを最初にプライマリで実行してから、スタンバイで実行する必要があります。