コンプライアンス プロファイルには、コンプライアンスのモニタに使用できる、一連の Jabber Session Manager（JSM）と Text Conferencing（TC）のイベントの両方またはいずれか一方が含まれます。JSM イベントのみ、TC イベントのみ、または JSM および TC イベントの両方の組み合わせで構成されるコンプライアンス プロファイルを作成できます。

コンプライアンス プロファイルを設定する場合、どの JSM および TC イベントをコンプライアンス サーバにログ記録するかを選択します。コンプライアンス サーバがどのタイプの処理を実行するか、IM and Presence サービスがどのようにコンプライアンス サーバからのエラー応答を処理するか、また IM and Presence サービス ノードがイベントをさらに処理する前にコンプライアンス サーバからの応答を待機するかどうかを決定できます。応答が予期されない場合にイベントがどのように処理されるかも設定できます。

次の表は、JSM イベントおよびパラメータを説明しています。

注意	[BOUNCE]、および [火災と紛失（Fire and Forget）] の組み合わせが選択された場合、これが適用されるイベントがコンプライアンス サーバに渡され、その後破棄されます。これは、IM and Presence サービスによってさらに処理されないことを意味しています。この組み合わせを使用する際は、十分注意してください。

次の表は、TC イベントおよびパラメータを説明しています。

注意	[BOUNCE]、および [火災と紛失（Fire and Forget）] の組み合わせが選択された場合、これが適用されるイベントがコンプライアンス サーバに渡され、その後破棄されます。これは、IM and Presence サービスによってさらに処理されないことを意味しています。この組み合わせを使用する際は、十分注意してください。

同じコンプライアンス プロファイルが複数のコンプライアンス サーバに割り当てられている場合、イベントはそれぞれのコンプライアンス サーバにロード バランスされます。これによって個々のコンプライアンス サーバの負荷が軽減されます。 イベントは、関連するイベントが同じコンプライアンス サーバにルーティングされることを保証するアルゴリズムを使用してルーティングされます。一対一の IM では、イベントはパケットの方向に関係なく to/from アドレスの組み合わせに基づいてルーティングされます。これは、2 人のユーザ間のカンバセーション全体が 1 つのコンプライアンス サーバにルーティングされることを意味しています。グループ チャットでは、特定のチャット ルームに対するイベントがチャット ルーム アドレスを使用してルーティングされ、ルームに対するすべてのイベントが 1 つのコンプライアンス サーバにルーティングされます。

システム デフォルト プロファイルはフレッシュ インストールまたはアップグレード後にシステムで使用可能です。このプロファイルは SystemDefaultComplianceProfile と呼ばれ、削除または変更できません。他と同様にこのプロファイルは割り当ておよび割り当て解除できます。

SystemDefaultComplianceProfile プロファイルには 4 つの JSM と 5 つの TC イベントが設定されています。このプロファイルが割り当てられている場合、そのイベントのいずれかが IM and Presence サービス クラスタで発生する場合、処理のためにコンプライアンス サーバに渡され、応答が予期されます。IM and Presence サービス ノードは、コンプライアンス サーバからの応答に基づいてイベントを処理します。これらのイベントは、SystemDefaultComplianceProfile が利用可能なコンプライアンス プロファイルから選択された場合、読み取り専用形式でプレビューされます。

同じイベントが複数のプロファイルで設定され、これらのプロファイルが異なるサードパーティ コンプライアンス サーバに割り当てられる場合、イベントはルーティング プライオリティで指定される順序で処理されます。デフォルトでは、すべてのプロファイルのルーティング プライオリティはプロファイルがシステムに追加された順序で定義されます。ルーティング プライオリティは再設定できます。

このセクションには、現在コンプライアンスを設定している管理者が IM and Presence サービス 10.0.(1) にアップグレードする前に役立ついくつかのサンプル アップグレード シナリオが含まれています。

注意	この設定を有効にした場合、元に戻すことはできません。

すべてのノードに対してコンプライアンスを有効化した後、IM and Presence サービスによって使用されるコンポーネント名が自動生成された形式に変更されます。機能の使用を継続するには、新しいコンポーネント名でコンプライアンス サーバを更新します。

この章では、コンプライアンス統合時または HA フェールオーバー中に問題が発生した場合に IM and Presence サービス ユーザが体験する動作について説明しています。

（注）	この章のセクションは、（別途記載がある場合を除き）コンプライアンス プロファイルに以下のイベントが含まれることを前提としています。 e_SESSION（ユーザ ログインの記録） es_END（ユーザ ログアウトの記録） メッセージに対する es_OUT/es_IN（IM カンバセーションの記録） 1 つ以上の TC イベント（チャット ルーム内のやりとりの記録）

想定される展開：

• サブクラスタで展開される 1 つ以上の IM and Presence サービス ノード。

• 1 つの IM and Presence サービス ノードが単一のサードパーティ コンプライアンス サーバで設定されます。

コンプライアンス サーバまたはサービスがグレースフルにシャットダウンされるとユーザは以下のように影響を受けます。

• ユーザは通常どおり XMPP クライアントを使用して IM and Presence サービスへのログインとログアウトを続行しますが、ログインとログアウトのイベントはコンプライアンス サーバにログ記録されません。

• ユーザは IM の送信またはチャット ルームの利用がブロックされ、それぞれの場合にサーバ エラー応答を受信します。

想定される展開：

• サブクラスタで展開される 1 つ以上の IM and Presence サービス ノード。

• 1 つの IM and Presence サービス ノードが単一のサードパーティ コンプライアンス サーバで設定されます。

最初の 5 分間まで、コンプライアンス サーバまたはサービスがアングレースフルに失敗した場合、または IM and Presence サービス ノードとコンプライアンス サーバ間でネットワークの中断があった場合、ノードはそのコンプライアンス サーバに対してイベントのキューイングを試行します。個々のイベントは処理またはバウンスされる前に 30 秒間キューに置かれます。

5 分経過してもコンプライアンス サーバまたはネットワークが回復していない場合、サーバへの接続がドロップされ、イベントはキューに置かれなくなります。この場合、イベントは即時に処理またはバウンスされます。ユーザには次のような影響があります。

• ユーザには IM and Presence サービスへのログイン時に最大 30 秒の遅延が発生しますが、ログアウト時には遅延はありません。ログインおよびログアウト イベントはコンプライアンス サーバにログ記録されません。

• ユーザは IM の送信またはチャット ルームの利用がブロックされます。それぞれの場合、ユーザはサーバ エラー応答を受信しますが、エラーが受信されるまでに最大 30 秒の遅延が発生する場合があります。

• プレゼンス ステータスの更新が処理されている間、ユーザには最大 30 秒の遅延が発生する場合があります。

想定される展開：

• サブクラスタに展開された 1 つの IM and Presence サービス ノード。

• 1 つの IM and Presence サービス ノードが複数のサードパーティ コンプライアンス サーバで設定されます。

IM and Presence サービス ノードが複数のコンプライアンス サーバに接続されている場合、通常は、JID ベースのアルゴリズムを使用して、イベントにコンプライアンス サーバに渡るロードバランスが適用されます。異なるユーザに対するイベントは異なるコンプライアンス サーバにルーティングできます。

コンプライアンス サーバまたはサービスのいずれかがグレースフルにシャットダウンした場合、このサーバにルーティングされるはずだったイベントは残りのコンプライアンス サーバにルーティングされます。

想定される展開：

• サブクラスタに展開された 1 つの IM and Presence サービス ノード。

• 1 つの IM and Presence サービス ノードが複数のサードパーティ コンプライアンス サーバで設定されます。

IM and Presence サービス ノードが複数のコンプライアンス サーバに接続されている場合、通常は、JID ベースのアルゴリズムを使用して、イベントにコンプライアンス サーバに渡るロードバランスが適用されます。異なるユーザに対するイベントは異なるコンプライアンス サーバにルーティングできます。

コンプライアンス サーバまたはサービスのいずれかがアングレースフルに失敗した場合、または IM and Presence サービス ノードとそのサーバの間のネットワークに障害が発生した場合、ユーザは以下のように影響を受けます。

• 一部ユーザには IM and Presence サービスへのログイン時に最大 30 秒の遅延が発生しますが、ログアウト時には遅延はありません。ログインおよびログアウト イベントはコンプライアンス サーバにログ記録されません。

• 一部のユーザは IM の送信またはチャット ルームの利用を最大 5 分間ブロックされます。この期間が経過した後、ユーザは IM の送信またはチャット ルームの利用を継続することができ、イベントは残りのコンプライアンス サーバのいずれかにルーティングされます。

• プレゼンス ステータスの更新が処理されている間、一部のユーザには最大 30 秒の遅延が発生する場合があります。

IM and Presence サービス ノードが複数のコンプライアンス サーバに接続するように設定されていて、それぞれ異なるコンプライアンス プロファイルを使用しており、プロファイルに 1 つまたは複数の同一のイベントが含まれる場合、これらのイベントに対する通常の動作は、各プロファイルのプライオリティに基づいて各コンプライアンス プロファイルに関連付けられるコンプライアンス サーバに順番にルーティングされることです。

この動作の詳細は次の例で説明されています。

想定される展開：

• 1 つまたは複数の同一のイベントを含む複数のプロファイルを持つサブクラスタ内に展開された 1 つの IM and Presence サービス ノード。

• IM and Presence サービス ノードは複数のサードパーティ コンプライアンス サーバおよびプロファイルで設定されます。

各コンプライアンス プロファイルには設定された以下のイベントがあります。

プロファイル 1：

• e_SESSION（ユーザ ログインの記録）

• メッセージに対する es_OUT/es_IN（IM カンバセーションの記録）

• es_END（ユーザ ログアウトの記録）

プロファイル 2：

• メッセージに対する es_OUT/es_IN（IM カンバセーションの記録）

プロファイルの割り当て：

• プロファイル 1 はコンプライアンス サーバ 1 に割り当てられます。

• プロファイル 2 はコンプライアンス サーバ 2 に割り当てられます。

• プロファイル 1 が最高のプライオリティです。

通常動作時：

ユーザが IM を送信すると、プロファイル 1 の es_OUT イベントはコンプライアンス サーバ 1 にルーティングされます。コンプライアンス サーバ 1 がイベントを許可する場合、プロファイル 2 の es_OUT イベントはコンプライアンス サーバ 2 にルーティングされます。

コンプライアンス サーバ 1 にアングレースフルな停止が発生すると、以下のシーケンスが実行されます。

1. ユーザ A がユーザ B.に IM を送信します。

2. es_OUT イベント（プロファイル 1）がコンプライアンス サーバ 1 のキューに入れられます。

3. es_OUT イベント（プロファイル 1）が 30 秒後にタイムアウトします。

4. es_OUT イベント（プロファイル 1）はバウンスされ、IM 送信者はエラー応答を受信します。

5. es_OUT（プロファイル 2）イベントは処理されず、イベントはコンプライアンス サーバ 2 に送信されません。

この場合、ユーザには以下のような影響があります。

• ユーザは、IM の送信をブロックされます。それぞれの場合に、ユーザはサーバ エラー応答を受信しますが、エラーが受信されるまでに最大 30 秒の遅延が発生する場合があります。IM のカンバセーションに関連付けられたイベントは残りのコンプライアンス サーバにルーティングされます。

• プレゼンス ステータスの更新が処理されている間、ユーザには最大 30 秒の遅延が発生する場合があります。

想定される展開：

• HA が有効化されたサブクラスタで展開される 2 つの IM and Presence サービス ノード。

• それぞれの IM and Presence サービス ノードは、同じコンプライアンス プロファイルを使用して異なるサードパーティ製コンプライアンス サーバで設定されています。

通常動作時：

• イベントは JID ベースのアルゴリズムを使用してコンプライアンス サーバにわたってロードバランスされています。

• 異なるユーザに対するイベントは異なるコンプライアンス サーバにルーティングできます。

• コンプライアンス サーバにルーティングされているイベントは、接続先の IM and Presence サービス ノードを使用してルーティングされます。

IM and Presence サービス ノードの手動のフェールオーバーが発生した場合、通常関連するコンプライアンス サーバにルーティングされるイベントは以下のように処理されます。

• ログインおよびログアウト イベントはコンプライアンス サーバにログ記録されません。一部のユーザには IM and Presence サービスへのログイン時に最大 30 秒の遅延が発生しますが、ログアウト時には遅延はありません。

• フェールオーバー中、ユーザは IM の送信またはチャット ルームの利用をブロックされます。この場合、各ケースについて、ユーザはサーバ エラー応答を受信しますが、エラーが受信されるまでに最大 30 秒の遅延が発生する場合があります。ブロックされるイベントはコンプライアンス サーバにログ記録されません。

• フェールオーバーが完了すると、IM またはグループ チャット イベントが別の IM and Presence サービス ノードに接続されるコンプライアンス サーバによって処理され、スタンザは通常どおり配信されます。

想定される展開：

• HA が有効化されたサブクラスタで展開される 2 つの IM and Presence サービス ノード。

• それぞれの IM and Presence サービス ノードは、同じコンプライアンス プロファイルを使用して異なるコンプライアンス サーバで設定されています。

通常動作時：

• イベントは JID ベースのアルゴリズムを使用してコンプライアンス サーバにわたってロードバランスされています。

• 異なるユーザに対するイベントは異なるコンプライアンス サーバにルーティングできます。

• 各コンプライアンス サーバにルーティングされているイベントは、接続先の IM and Presence サービス ノードを使用してルーティングされます。

（注）	フェールオーバーの要因が Cisco XCP ルータ サービスの障害またはシャットダウンでない場合は、コンプライアンス イベントは通常どおりコンプライアンス サーバに継続してルーティングされます。フェールオーバーが発生した IM and Presence サービス ノードに接続されているコンプライアンス サーバにルーティングされるイベントは、コンプライアンス サーバに継続してルーティングされます。

想定される展開：

• HA が有効化されたサブクラスタで展開される 2 つの IM and Presence サービス ノード。

• それぞれの IM and Presence サービス ノードは、同じコンプライアンス プロファイルを使用して異なるコンプライアンス サーバで設定されています。

通常動作時：

• イベントは JID ベースのアルゴリズムを使用してコンプライアンス サーバにわたってロードバランスされています。

• 異なるユーザに対するイベントは異なるコンプライアンス サーバにルーティングできます。

• 各コンプライアンス サーバにルーティングされているイベントは、接続先の IM and Presence サービス ノードを使用してルーティングされます。

IM and Presence サービス ノード間でネットワーク障害が発生した場合、通常は別の IM and Presence サービス ノードに関連付けられるコンプライアンス サーバにルーティングされるユーザのイベントは以下のように処理されます。

• 一部のユーザには IM and Presence サービスへのログイン時に最大 30 秒の遅延が発生しますが、ログアウト時には遅延はありません。ログインおよびログアウト イベントはコンプライアンス サーバにログ記録されません。

• 障害時に、一部のユーザは IM の送信やチャット ルームの利用をブロックされます。それぞれの場合に、ユーザはサーバ エラー応答を受信しますが、エラーが受信されるまでに最大 30 秒の遅延が発生する場合があります。ブロックされるイベントはコンプライアンス サーバにログ記録されません。

• 障害が 2 分以上継続する場合、イベントは展開内の別のコンプライアンス　サーバによって処理され、スタンザは通常どおり配信されます。

想定される展開：

• HA が有効化されていないサブクラスタで展開される 2 つの IM and Presence サービス ノード。

• それぞれの IM and Presence サービス ノードは、同じコンプライアンス プロファイルを使用して異なるコンプライアンス サーバで設定されています。

  （注）	このセクションでは、HA が有効な場合の結果についても強調されます。

通常動作時：

• イベントは JID ベースのアルゴリズムを使用してコンプライアンス サーバにわたってロードバランスされています。

• 異なるユーザに対するイベントは異なるコンプライアンス サーバにルーティングできます。

• 各コンプライアンス サーバにルーティングされているイベントは、接続先の IM and Presence サービス ノードを使用してルーティングされます。

HA が有効になっているかどうかによってユーザが体験する結果の相違は以下のとおりです。

• HA が有効になっている場合、ユーザはログインしたままになっており、残りのノードに移動されます。

• HA が有効になっていない場合、障害の発生したノード上のユーザはログアウトされ、サービスを利用できません。

より一般的な影響は以下のとおりです。

• 障害の発生した IM and Presence サービス ノードに接続されているコンプライアンス サーバに通常ルーティングされているイベントは、他の IM and Presence サービス ノードに接続されているコンプライアンス サーバにルーティングされます。

• 障害が一時的なものである場合、一部のユーザは IM の送信やチャットルームの使用をブロックされます。それぞれの場合に、ユーザはサーバ エラー応答を受信しますが、エラーが受信されるまでに最大 30 秒の遅延が発生する場合があります。ブロックされるイベントはコンプライアンス サーバにログ記録されません。

• 障害が長期間継続する場合、IM は通常どおり処理され、他の IM and Presence サービス ノードに接続されたコンプライアンス サーバにルーティングされます。