この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
このソリューションを使用して、IM and Presence サービスはロギングまたは倫理的境界機能のコンプライアンスのために 1 つ以上のサードパーティ コンプライアンス サーバを統合します。 IM and Presence サービス管理者は、どの IM、プレゼンス、またはグループ チャット イベントがコンプライアンス サーバに渡されるか、およびどのイベントがブロックされるかを選択できます。 イベントはポリシーに基づいて選択する必要があります。 たとえば、システムは特定のユーザまたはユーザ グループ間の IM をフィルタするか、IM の作成者および受信者に応じてコンテンツをブロックまたは変更するように設定することができます。
サードパーティ製のコンプライアンス ソリューションを使用するには、クラスタに対してサードパーティ コンプライアンス サーバを設定する必要があります。 IM and Presence サービスは、ユーザ ログイン、ログアウト、プレゼンス共有、IM 交換、またはグループ チャット アクティビティの処理の際に生成されたすべての設定イベントをサード パーティ サーバに渡します。 サードパーティ コンプライアンス サーバは、イベントに関連するポリシーやフィルタを適用し、IM and Presence サービスに対してイベントをさらに処理するかどうかを指示します。 IM and Presence サービスとサードパーティ製のコンプライアンス サーバとの間で受け渡されるイベントの量によっては、ネットワークでパフォーマンスの遅れが発生する可能性があることに注意してください。 IM and Presence サービスがサードパーティ サーバとの接続を失った場合、すべての IM トラフィックが停止します。
サードパーティ コンプライアンスには次のコンポーネントが必要です。
IM and Presence サービス Release 10.0(x):IM and Presence サービスはイベントをサード パーティ コンプライアンス サーバに送信するために Event Broker コンポーネントを使用します。
サードパーティ コンプライアンス サーバ:クラスタ内のすべての IM and Presence サービスノードは、コンプライアンスがすでに設定されたシステムからアップグレードしているのではないかぎり、イベントを設定されたコンプライアンス サーバにリダイレクトします。
IM クライアント:サポートされるクライアントには、Cisco Jabber などの Cisco クライアント、サードパーティ製 XMPP クライアント、および連動ネットワークで使用されるその他のサードパーティ製クライアントがあります。
(注) |
IM and Presence サービスは、IM and Presence サービスとサードパーティ コンプライアンス サーバ間にセキュアな TLS/SSL 接続を提供しません。 |
次の図は、サードパーティ コンプライアンスのコンポーネントとメッセージ フローを示しています。
サードパーティ製コンプライアンス統合を初めて設定する場合、以下のワークフローをお勧めします。
(注) |
次の設定を変更する際には注意が必要です。 変更を保存すると、以前の設定はすべて失われます。 |
コンプライアンス プロファイルには、コンプライアンスのモニタに使用できる、一連の Jabber Session Manager(JSM)と Text Conferencing(TC)のイベントの両方またはいずれか一方が含まれます。 JSM イベントのみ、TC イベントのみ、または JSM および TC イベントの両方の組み合わせで構成されるコンプライアンス プロファイルを作成できます。
コンプライアンス プロファイルを設定する場合、どの JSM および TC イベントをコンプライアンス サーバにログ記録するかを選択します。 コンプライアンス サーバがどのタイプの処理を実行するか、IM and Presence Service がどのようにコンプライアンス サーバからのエラー応答を処理するか、また IM and Presence Service ノードがイベントをさらに処理する前にコンプライアンス サーバからの応答を待機するかどうかを決定できます。 応答が予期されない場合にイベントがどのように処理されるかも設定できます。
次の表は、JSM イベントおよびパラメータを説明しています。
注意 |
[Bounce(バウンス)]、および [Fire and Forget(火災と紛失)] の組み合わせが選択された場合、これが適用されるイベントがコンプライアンス サーバに渡され、その後破棄されます。 これは、IM and Presence Service によってさらに処理されないことを意味しています。 この組み合わせを使用する際は、十分注意してください。 |
イベント | 説明 |
---|---|
e_SESSION |
新しいセッションが作成される、ログイン時に送信されたパケット。 |
e_OFFLINE |
オフラインであるユーザに送信されるパケット。 オフライン ユーザはアクティブ セッションを持たないユーザです。 |
e_SERVER |
内部処理のために直接サーバに送信されるパケット。 |
e_DELIVER |
別のサーバからのパケットに対する最初のイベント。同じサーバ上のユーザからのパケットに対する 2 番目のイベント (同じサーバからのパケットに対する最初のイベントは es_IN です)。 |
e_AUTH |
認証時に送信される IQ パケット。 |
e_REGISTER |
ユーザによる新規アカウントの登録時に生成されるパケット。 |
e_STATS |
定期的に送信されるサーバ統計情報が含まれるパケット。 |
e_DISCOFEAT |
ユーザが disco#info クエリーを送信する場合にトリガーされます。 |
e_PRISESSION |
ユーザが複数のセッションを持つ場合、ユーザのプライマリまたはデフォルト セッションを決定します。 EventBroker コンポーネントによってユーザ プライマリ セッションの選択肢が決まる場合があります。 |
es_IN |
スタンザがユーザ セッションによって受信される直前に生成されます。 |
es_OUT |
スタンザがユーザ セッションから送信されるときに生成されます。 |
es_END |
ユーザがログアウトすると生成されるパケット。 |
パラメータ | 説明 |
---|---|
パケット タイプ |
次の XMPP のパケット タイプからいずれかを選択します。 |
ハンドル |
コンプライアンス サーバから返されるエラーが元のパーティまたはコンポーネントにバウンスされるようにする場合は [bounce(バウンス)] を、破棄する場合は [pass] を選択します。 |
火災と紛失 |
イベントの処理を継続する前に IM and Presence Service ノードがコンプライアンス サーバからの応答を待つ必要がある場合はチェックボックスをオンにします。 イベントをさらに継続するために IM and Presence Service ノードがコンプライアンス サーバからの応答を待つ必要がない場合はチェックボックスをオフにします。 |
次の表は、TC イベントおよびパラメータを説明しています。
注意 |
[Bounce(バウンス)]、および [Fire and Forget(火災と紛失)] の組み合わせが選択された場合、これが適用されるイベントがコンプライアンス サーバに渡され、その後破棄されます。 これは、IM and Presence Service によってさらに処理されないことを意味しています。 この組み合わせを使用する際は、十分注意してください。 |
イベント | 説明 |
---|---|
onServicePacket |
システムは、直接 TC サービスに向けられるかまたはシステム上に存在してしないルームに向けられたルータからのパケットを受信します。 |
onBeforeRoomCreate |
ギアがシステム上にルームを作成しようとしています。 |
onAfterRoomCreate |
部屋はシステム上に正常に作成されました。 唯一の有効な応答は、元のスタンザへの修正がない PASS です。 |
onServiceDiscoInfo |
エンティティが TC サービスに disco#info パケットを送信しました。 有効な応答は PASS のみです。 |
onServiceReconfig |
TC サービスは自身を再構成するシグナルを受信します。 有効な応答は PASS のみです。 これは通知イベントだけです。 XDB パケットのタイプは ="set" になります。 外部コンポーネントは、このパケットに応答することはできません。 |
onDestroy |
ルームのオーナーがルームを閉じます。 有効な応答は PASS のみです。 |
onClose |
ギアがルームを閉じることを要求します。 |
onPacket |
新しい XML スタンザは、ルーム、またはルーム内の参加者に向けられます。 |
onMetaInfoGet |
部屋の設定情報を利用できます。 有効な応答は PASS のみです。 |
onBeforeMetaInfoSet |
ルームの設定をユーザが修正しようとしています。 |
onAfterMetaInfoSet |
ルームの設定がユーザによって修正されました。 有効な応答は、中に何もない PASS のみです。 |
onExamineRoom |
Jabber エンティティは、browse または disco によってルームから情報を要求します。 有効な応答は PASS のみです。 |
onBeforeChangeUser |
ユーザ ロール、ニックネーム、またはプレゼンスの変更が要求されました。 これには、入室、退室、ニックネーム変更、アベイラビリティ変更、または任意のロール変更(音声の許可または無効化、モデレータ特権)などが含まれます。 |
onAfterChangeUser |
ユーザが変更されました。 有効な応答は、中に何もない PASS のみです。 |
onBeforeChangeAffiliation |
ユーザ アフィリエーションが変更されようとしています。 |
onAfterChangeAffiliation |
ユーザ アフィリエーションが変更されました。 有効な応答は、中に何もない PASS のみです。 |
onBeforeRemoveAffiliation |
ユーザ アフィリエーションが削除されようとしています。 |
onAfterRemoveAffiliation |
ユーザ アフィリエーションが削除されました。 唯一の有効な応答は、元のスタンザへの修正がない PASS です。 |
onBeforeJoin |
ユーザがルームを結合しようとしています。 |
onAfterJoin |
ユーザがルームを結合しました。 有効な応答は、中に何もない PASS のみです。 |
onLeave |
ユーザがルームから退室しました。 有効な応答は PASS のみです。 |
onBeforeSubject |
ルームの件名が変更されようとしています。 |
onAfterSubject |
ルームの件名が変更されました。 有効な応答は、中に何もない PASS のみです。 |
onBeforeInvite |
ユーザがルームに招待されようとしています。 |
onAfterInvite |
ユーザがルームに招待されました。 有効な応答は、中に何もない PASS のみです。 |
onHistory |
ルームの履歴が要求されました。 有効な応答は PASS のみです。 |
onBeforeSend |
メッセージがルームで送信されようとしています。 |
onBeforeBroadcast |
メッセージがルームでブロードキャストされようとしています。 |
パラメータ | 説明 |
---|---|
ハンドル |
コンプライアンス サーバから返されるエラーが元のパーティまたはコンポーネントにバウンスされるようにする場合は [bounce(バウンス)] を、破棄する場合は [pass] を選択します。 |
火災と紛失 |
イベントの処理を継続する前に IM and Presence Service ノードがコンプライアンス サーバからの応答を待つ必要がある場合はチェックボックスをオンにします。 イベントをさらに継続するために IM and Presence Service ノードがコンプライアンス サーバからの応答を待つ必要がない場合はチェックボックスをオフにします。 |
同じコンプライアンス プロファイルが複数のコンプライアンス サーバに割り当てられている場合、イベントはそれぞれのコンプライアンス サーバにロード バランスされます。 これによって個々のコンプライアンス サーバの負荷が軽減されます。 イベントは、関連するイベントが同じコンプライアンス サーバにルーティングされることを保証するアルゴリズムを使用してルーティングされます。 一対一の IM では、イベントはパケットの方向に関係なく to/from アドレスの組み合わせに基づいてルーティングされます。 これは、2 人のユーザ間のカンバセーション全体が 1 つのコンプライアンス サーバにルーティングされることを意味しています。 グループ チャットでは、特定のチャット ルームに対するイベントがチャット ルーム アドレスを使用してルーティングされ、ルームに対するすべてのイベントが 1 つのコンプライアンス サーバにルーティングされます。
システム デフォルト プロファイルはフレッシュ インストールまたはアップグレード後にシステムで使用可能です。 このプロファイルは SystemDefaultComplianceProfile と呼ばれ、削除または変更できません。 他と同様にこのプロファイルは割り当ておよび割り当て解除できます。
SystemDefaultComplianceProfile プロファイルには 4 つの JSM と 5 つの TC イベントが設定されています。 このプロファイルが割り当てられている場合、そのイベントのいずれかが IM and Presence Service クラスタで発生する場合、処理のためにコンプライアンス サーバに渡され、応答が予期されます。 IM and Presence Service ノードは、コンプライアンス サーバからの応答に基づいてイベントを処理します。 これらのイベントは、SystemDefaultComplianceProfile が利用可能なコンプライアンス プロファイルから選択された場合、読み取り専用形式でプレビューされます。
JSM イベント | TC イベント |
---|---|
e_SESSION |
onBeforeInvite |
es_END |
onBeforeJoin |
es_IN(メッセージ スタンザのみ) |
onBeforeRoomCreate |
es_OUT(メッセージ スタンザのみ) |
onBeforeSend |
onLeave |
同じイベントが複数のプロファイルで設定され、これらのプロファイルが異なるサードパーティ コンプライアンス サーバに割り当てられる場合、イベントはルーティング プライオリティで指定される順序で処理されます。 デフォルトでは、すべてのプロファイルのルーティング プライオリティはプロファイルがシステムに追加された順序で定義されます。 ルーティング プライオリティは再設定できます。
ステップ 1 | を選択します。 | ||
ステップ 2 | [Add New(新規追加)] を選択します。 | ||
ステップ 3 |
コンプライアンス プロファイルの名前を入力します。 使用できる文字は英数字のみです。 スペースは使用できません。
|
||
ステップ 4 |
コンプライアンス プロファイルの説明を入力します。 このフィールドはオプションで、コンプライアンス プロファイルの目的を示す意味のある説明を含める必要があります。 |
||
ステップ 5 | JSM または TC でイベントを選択します。 | ||
ステップ 6 |
JSM イベントについては、パケット タイプを選択します。 同じパケット タイプを持つ同じイベントを複数回設定することはできません。 [All(すべて)] を選択した場合、別のパケット タイプに対して同じイベントを、またはその逆を設定することはできません。 同じ JSM イベントにすべてのパケット タイプを設定することは、1 つの JSM イベントを All のパケット タイプで設定することと同じです。 |
||
ステップ 7 | 処理タイプを選択します。 | ||
ステップ 8 |
[Fire and Forget(火災と紛失)] チェックボックスを選択して、イベントがコンプライアンス サーバによって IM and Presence Service イベント処理チェーンの外で処理されるようにします。 IM and Presence Service は、コンプライアンス サーバの処理に関係なくイベントの処理を継続します。 デフォルトで、イベントはイベント処理チェーンの一部として処理され、IM and Presence Service はコンプライアンス サーバからの応答を待機します。 イベントがイベント処理チェーンの一部として処理され、コンプライアンス サーバが HANDLE で応答する場合、イベントは IM and Presence Service によってさらに処理されません。 コンプライアンス サーバが PASS で応答する場合、IM and Presence Service はイベントの処理を継続します。 |
||
ステップ 9 |
いずれかのタイプのイベントを追加するには、[Add New Event(新規イベントの追加)] を選択します。 トラブルシューティングのヒント サードパーティ製コンプライアンス サーバに割り当てられたプロファイル内のイベントに対する設定を更新した場合、XCP Router サービスを再起動する必要があります。 |
複数のコンプライアンス プロファイルが割り当てられていて、1 つのプロファイルからの一部のまたはすべてのイベントが他のプロファイル内に存在する場合、ルーティング プライオリティを設定できます。
複数のコンプライアンス プロファイルが割り当てられていて、1 つのプロファイルからの一部のまたはすべてのイベントが他のプロファイル内に存在する場合、ルーティング プライオリティを設定できます。 各コンプライアンス プロファイルに異なるイベントが設定されている場合、ルーティング プライオリティは適用されません。
システムで設定されたプロファイルのデフォルトのルーティング プライオリティは、設定された順序となります。
以下は、コンプライアンス プロファイル ルーティング プライオリティを使用する場合の例を示しています。
Ethical Wall 精査の対象となるイベントに設定されたコンプライアンス プロファイルと、IM ログ記録の対象となる同じイベントに設定されたコンプライアンス プロファイルがあります。 それぞれが異なるコンプライアンス サーバに割り当てられます。 Ethical Wall 精査の対象となるイベントを、IM ロギング サーバにログ記録する前に Ethical Wall にルーティングしたい場合、Ethical Wall コンプライアンス プロファイルにより高いプライオリティを割り当てる必要があります。
ステップ 1 | を選択します。 |
ステップ 2 | [Compliance Profiles listed by routing priority(Top is highest priority)(ルーティング プライオリティ別にコンプライアンス プロファイルをリスト(最上部が最高のプライオリティ))] ウィンドウで、上下矢印を使用してコンプライアンス プロファイルに対するルーティング プライオリティを調整します。 |
ルーティング プライオリティを変更したプロファイルが割り当てられた場合、Cisco XCP Router サービスを再起動する必要があります。 いつルータの再起動が必要になるかは、表示される警告メッセージを参照してください。
IM and Presence サービス 10.0.(1) で、以前にコンプライアンスが設定されていたシステムからアップグレードする場合を除き、クラスタ内のすべてのノードはコンプライアンスの対象となります。 これは、IM and Presence サービス ノードに複数のコンプライアンス サーバを割り当てることはできますが、コンプライアンスの対象とするためにすべての IM and Presence サービス ノードにコンプライアンス サーバを割り当てる必要はないことを意味しています。
クラスタ内の各コンプライアンス サーバは、異なるイベントのセットを処理するように設定できます。 これらのイベントのセットはコンプライアンス プロファイルで設定され、コンプライアンス サーバおよび IM and Presence サービス ノードに割り当てられます。
システム デフォルト プロファイルはフレッシュ インストールまたはアップグレード後にシステムで使用可能です。 このプロファイルは SystemDefaultComplianceProfile と呼ばれ、削除または変更できません。 他と同様にこのプロファイルは割り当ておよび割り当て解除できます。 独自のカスタム コンプライアンス プロファイルを作成するまで、ドロップダウン メニューから使用可能なデフォルトのコンプライアンス プロファイルは 1 つだけです。
10.0(1) 以前からアップグレードする場合、以前の割り当てには SystemDefaultComplianceProfile が割り当てられます。 これはドロップダウン メニューから使用可能な唯一のプロファイルです。 このデフォルト プロファイル内のイベントは、アップグレード前のシステムのものと同じイベントです。
以前のリリースでは、IM Compliance はノード単位で動作しました。 コンプライアンス サーバが割り当てられたノードはすべて、イベントがそのノードで生成された場合にのみ IM イベントをコンプライアンス サーバにログ記録しました。 このリリースでは、IM コンプライアンスはクラスタベースで機能します。 クラスタ内のノードの数またはどのノードにサードパーティ製のコンプライアンス サーバが割り当てられているかに関係なく、クラスタ内のすべてのノードがコンプライアンスの対象となります。 クラスタ内の任意のノードで生成された任意のイベントがコンプライアンス サーバのいずれかにログ記録されます。
10.0(1) 以前からアップグレードする場合、システムはアップグレード後にノードベースで機能しますが、クラスタ内のすべてのノードに対してコンプライアンス ログを有効にできます。 これを選択すると、割り当てを作成、更新、および削除したり、コンプライアンス プロファイルをシステム内に作成したカスタム コンプライアンス プロファイルに変更したりすることが可能になります。
(注) |
以前にコンプライアンスが設定されていたシステム上のすべてのノードに対してコンプライアンス ロギングを有効にすることは必須ではありません。 ノード単位でコンプライアンス ロギングを保持することを選択できます。 この場合、コンプライアンス サーバでは SystemDefaultComplianceProfile だけを使用できます。 |
ステップ 1 | を選択します。 | ||
ステップ 2 | コンプライアンス サーバの選択項目から [Third-Party Compliance Server(サードパーティ コンプライアンス サーバ)] を選択します。 | ||
ステップ 3 |
IM and Presence サービス ノードにサードパーティ製コンプライアンス サーバを割り当てます。
[Open-port Component Name(オープンポート コンポーネント名)] フィールドは、最初の 2 つの列内の値に基づいて自動的に生成されます。 これはオープンポートのコンポーネントを設定する場合に使用されます。 |
||
ステップ 4 |
各コンプライアンス サーバにコンプライアンス プロファイルを割り当てます。 同じコンプライアンス プロファイルを複数回割り当てることができます。
|
||
ステップ 5 | [Save(保存)] をクリックします。 | ||
ステップ 6 |
コンプライアンスがクラスタ内のすべてのノードに適用されている場合、すべてのノードで Cisco XCP ルータ サービスを再起動します。 これを実行しない場合、Cisco XCP Router サービスをこれらのコンプライアンスを設定したノードで再起動するだけで十分です。 トラブルシューティングのヒント IM コンプライアンス展開オプションを切り替えた(たとえば、[Message Archiver] オプションから [Third-Party Compliance Server(サードパーティ コンプライアンス サーバ)] オプションに切り替えた)場合、Cisco XCP Router サービスを再起動する必要があります。 オプション間で切り替えるとサードパーティ コンプライアンス設定が失われることに注意してください。 |
このセクションには、現在コンプライアンスを設定している管理者が IM and Presence サービス 10.0.(1) にアップグレードする前に役立ついくつかのサンプル アップグレード シナリオが含まれています。
第 1 段階 |
クラスタは 2 つのノードと 1 つのコンプライアンス サーバで構成されます。 ノード 1 はコンプライアンス サーバに接続され、このノードからのイベントのみがコンプライアンス サーバにルーティングされます。 |
第 2 段階 |
クラスタが IM and Presence サービス version 10.0 にアップグレードされると、ノード 1 はコンプライアンス サーバへの接続を維持し、このノードからのイベントのみがコンプライアンス サーバへルーティングされます。 ノード 1 とコンプライアンス サーバの両方が稼動を続行します。設定の変更は必要ありません。 |
第 3 段階 |
[Enable compliance logging for all nodes in the cluster(クラスタ内のすべてのノードに対してコンプライアンス ログを有効にする)] をチェックすることでクラスタ全体のコンプライアンスを有効にすると、ノード 1 はコンプライアンス サーバへの接続を維持します。 コンプライアンス サーバ上の設定は操作を維持するために更新する必要があります。 両方のノードからのイベントはノード 1 を介してコンプライアンス サーバにルーティングされます。 ページ上の |
第 1 段階 |
クラスタは 2 つのノードと 2 つのサードパーティ製コンプライアンス サーバで構成されます。 各ノードは接続され、ノードごとにそれぞれのコンプライアンス サーバにイベントがルーティングされます。 |
第 2 段階 |
クラスタが IM and Presence サービス version 10.0 にアップグレードされた後、各ノードは接続され、ノードごとにそれぞれのコンプライアンス サーバにイベントがルーティングされます。 両方のノードとそれぞれのコンプライアンス サーバの両方は稼動を継続し、設定の変更は必要ありません。 |
第 3 段階 |
[Enable compliance logging for all nodes in the cluster(クラスタ内のすべてのノードに対してコンプライアンス ログを有効にする)] をチェックすることでクラスタ全体のコンプライアンスを有効にすると、各ノードがそのコンプライアンス サーバに接続されます。 コンプライアンス サーバ上の設定は操作を維持するために更新する必要があります。 ノード 1 およびノード 2 からのイベントが各コンプライアンス サーバにルーティングされます。 ページ上の |
第 1 段階 |
クラスタは 2 つのノードと 2 つのサードパーティ製コンプライアンス サーバで構成されます。 各ノードは接続され、ノードごとにそれぞれのコンプライアンス サーバにイベントがルーティングされます。 |
第 2 段階 |
クラスタが IM and Presence サービス version 10.0 にアップグレードされた後、各ノードは接続され、ノードごとにそれぞれのコンプライアンス サーバにイベントがルーティングされます。 両方のノードとそれぞれのコンプライアンス サーバの両方は稼動を継続し、設定の変更は必要ありません。 |
第 3 段階 |
アップグレードされた IM and Presence サービス version 10.0 クラスタで、コンプライアンスを持たない追加のノード、ノード 3 が追加されます。 [Enable compliance logging for all nodes in the cluster(クラスタ内のすべてのノードに対してコンプライアンス ログを有効にする)] をチェックすることでクラスタ全体のコンプライアンスを有効にすると、各ノードがそのコンプライアンス サーバに接続されます。 コンプライアンス サーバ上の設定は操作を維持するために更新する必要があります。 ノード 1 およびノード 2 からのイベントが各コンプライアンス サーバにルーティングされます。 ノード 3 上のイベントはノード 1 およびノード 2 上の開いたポートを通して両方のコンプライアンス サーバにルーティングされます。 ページ上の |
注意 |
この設定を有効にした場合、元に戻すことはできません。 |
ステップ 1 | を選択します。 |
ステップ 2 | コンプライアンス サーバの選択項目から [Third-Party Compliance Server(サードパーティ コンプライアンス サーバ)] を選択します。 |
ステップ 3 |
[Enable compliance logging for all nodes in the cluster(クラスタ内のすべてのノードに対してコンプライアンス ログを有効にする)] を選択します。 イネーブルにした場合、この設定を元に戻すことはできません。 最適な設定チェックボックスに関してはマニュアルを参照し、[Save(保存)] をクリックします。 警告メッセージが表示されます。 |
ステップ 4 | [OK] をクリックします。 |
ステップ 5 | クラスタ内のすべてのノードで Cisco XCP Router サービスを再起動します。 |
すべてのノードに対してコンプライアンスを有効化した後、IM and Presence サービスによって使用されるコンポーネント名が自動生成された形式に変更されます。 機能の使用を継続するには、新しいコンポーネント名でコンプライアンス サーバを更新します。
この章では、コンプライアンス統合時または HA フェールオーバー中に問題が発生した場合に IM and Presence サービス ユーザが体験する動作について説明しています。
(注) |
この章のセクションは、(別途記載がある場合を除き)コンプライアンス プロファイルに以下のイベントが含まれることを前提としています。
|
想定される展開:
サブクラスタで展開される 1 つ以上の IM and Presence サービス ノード。
1 つの IM and Presence サービス ノードが単一のサードパーティ コンプライアンス サーバで設定されます。
コンプライアンス サーバまたはサービスがグレースフルにシャットダウンされるとユーザは以下のように影響を受けます。
想定される展開:
サブクラスタで展開される 1 つ以上の IM and Presence サービス ノード。
1 つの IM and Presence サービス ノードが単一のサードパーティ コンプライアンス サーバで設定されます。
最初の 5 分間まで、コンプライアンス サーバまたはサービスがアングレースフルに失敗した場合、または IM and Presence サービス ノードとコンプライアンス サーバ間でネットワークの中断があった場合、ノードはそのコンプライアンス サーバに対してイベントのキューイングを試行します。 個々のイベントは処理またはバウンスされる前に 30 秒間キューに置かれます。
5 分経過してもコンプライアンス サーバまたはネットワークが回復していない場合、サーバへの接続がドロップされ、イベントはキューに置かれなくなります。 この場合、イベントは即時に処理またはバウンスされます。 ユーザには次のような影響があります。
想定される展開:
サブクラスタに展開された 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:
プロファイル 2:
プロファイルの割り当て
通常動作時:
ユーザが IM を送信すると、プロファイル 1 の es_OUT イベントはコンプライアンス サーバ 1 にルーティングされます。 コンプライアンス サーバ 1 がイベントを許可する場合、プロファイル 2 の es_OUT イベントはコンプライアンス サーバ 2 にルーティングされます。
コンプライアンス サーバ 1 にアングレースフルな停止が発生すると、以下のシーケンスが実行されます。
ユーザ A がユーザ B に IM を送信します。
es_OUT イベント(プロファイル 1)がコンプライアンス サーバ 1 のキューに入れられます。
es_OUT イベント(プロファイル 1)が 30 秒後にタイムアウトします。
es_OUT イベント(プロファイル 1)はバウンスされ、IM 送信者はエラー応答を受信します。
es_OUT(プロファイル 2)イベントは処理されず、イベントはコンプライアンス サーバ 2 に送信されません。
この場合、ユーザには以下のような影響があります。
想定される展開:
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 Router サービスの障害またはシャットダウンでない場合は、コンプライアンス イベントは通常どおりコンプライアンス サーバに継続してルーティングされます。 フェールオーバーが発生した 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 サービス ノードに接続されたコンプライアンス サーバにルーティングされます。
IM and Presence サービス ノードがサードパーティ製コンプライアンス サーバに統合されている場合、メッセージは、サードパーティ製コンプライアンス サーバに正常にログ記録された後にのみユーザに配信されます。
IM and Presence サービス ノードが、直接接続されているサードパーティ製コンプライアンス サーバとの接続を失った場合、IM and Presence サービス はメッセージを受信者に配信しません。
この接続が失われたときに通知を受けるためには、この状態に関連するアラームが正しく設定されていることを確認する必要があります。
ステップ 1 | IM and Presence サービス にサインインします。 |
ステップ 2 | を選択します。 |
ステップ 3 | [Server(サーバ)] ドロップダウン メニューからアラームを設定したいサーバを選択し、[Go(移動)] をクリックします。 |
ステップ 4 | [Service Group(サービス グループ)] ドロップダウン リストから [IM and Presence Services(IM and Presence サービス)] を選択し、[Go(移動)] をクリックします。 |
ステップ 5 | [Service(サービス)] ドロップダウン メニューから [Cisco XCP Router(Cisco XCP ルータ)] を選択し、[Go(移動)] をクリックします。 |
ステップ 6 | 必要に応じてアラーム設定を行います。 |
ステップ 7 | [Save(保存)] をクリックします。 |
コンプライアンス/統合が期待どおりに動作せず、以下のような問題が発生している場合。
この場合、以下のチェックリストを使用してコンプライアンス統合のトラブルシューティングを実行します。
[Compliance Server Settings(コンプライアンス サーバの設定)] ウィンドウの [Troubleshooter(トラブルシュータ)] をチェックします。 [Troubleshooter(トラブルシュータ)] が赤の場合はステップ 2 に進みます。 [Troubleshooter(トラブルシュータ)] がグリーンの場合はステップ 3 に進みます。
サードパーティ製コンプライアンス サーバ設定ウィンドウで、サードパーティ製コンプライアンス サーバに対する接続設定をチェックします。
Cisco XCP Router サービスがサードパーティ製コンプライアンス サーバとの接続を確立したかどうかを検証するには、RTMT を使用して Cisco XCP Router サービス ログをチェックしてください。 以下のようなエントリに対してログをスキャンします。
正しいパスワードは IM and Presence サービス およびサードパーティ製コンプライアンス サーバで設定されています。
正しいコンポーネント名がサードパーティ製コンプライアンス サーバで設定されています。
Cisco XCP Router サービスがサードパーティ製コンプライアンス サーバに接続できない場合、Cisco XCP ルータ サービス ログが以下のような出力を表示します。
Connecting on fd 22 to host '10.53.52.205', port 7999 Unable to connect to host '10.53.52.205', port 7999:(111) Connection refused Component op-gwydlvm131.gwydlvm1153-cisco-com is GONE
IM and Presence サービスがコンプライアンス サーバに処理用にイベントを渡す際にログが CONNECTED および ACTIVE を示している場合、IM and Presence サービスでイベントの処理を続行するには、サードパーティ製コンプライアンス サーバが事前に各イベントに応答する必要があります。 コンプライアンス サーバが応答していないと考えられる場合は、コンプライアンス サーバのログを確認してください。
目次
- サードパーティ製コンプライアンス サーバとの統合
- サードパーティ コンプライアンスの概要
- サードパーティ製コンプライアンス サーバの設定ワークフロー
- IM and Presence サービス上のサードパーティ コンプライアンス サーバの設定
- コンプライアンス プロファイル
- コンプライアンス プロファイルの設定
- コンプライアンス プロファイル ルーティング プライオリティ
- コンプライアンス プロファイル ルーティング プライオリティの設定
- コンプライアンス サーバへのコンプライアンス プロファイルの割り当て
- IM and Presence サービス ノードへのサードパーティ製コンプライアンス サーバの割り当て
- アップグレードのシナリオ
- アップグレード シナリオ 1
- アップグレード シナリオ 2
- アップグレード シナリオ 3
- アップグレード後にすべてのノードに対してコンプライアンス ロギングを有効化
- サードパーティ製コンプライアンス サーバ障害イベントの処理
- サードパーティ製コンプライアンス サーバ障害イベントの処理について
- コンプライアンス サーバまたはサービス停止時のイベント処理
- 単一のコンプライアンス サーバまたはサービスのシャットダウン
- 単一のコンプライアンス サーバまたはサービスのアングレースフルな失敗またはネットワークの中断
- 複数のコンプライアンス サーバでのコンプライアンス サーバまたはサービスのグレースフルな停止
- 複数のコンプライアンス サーバでのコンプライアンス サーバまたはサービスのアングレースフルな停止
- 複数のコンプライアンス サーバおよびプロファイルでのコンプライアンス サーバまたはサービスの停止
- IM and Presence サービス ノードの障害発生時のコンプライアンス処理
- 手動のノードのフェールオーバー時のコンプライアンス処理
- 自動化されたノードのフェールオーバー時のコンプライアンス処理
- 複数ノード間のネットワーク障害中のコンプライアンス処理
- Cisco XCP Router サービス障害中のコンプライアンス処理
- IM and Presence サービス ノードおよびサードパーティ製コンプライアンス サーバ アラーム
- サードパーティ製コンプライアンス サーバのトラブルシューティング
サードパーティ コンプライアンスの概要
このソリューションを使用して、IM and Presence サービスはロギングまたは倫理的境界機能のコンプライアンスのために 1 つ以上のサードパーティ コンプライアンス サーバを統合します。 IM and Presence サービス管理者は、どの IM、プレゼンス、またはグループ チャット イベントがコンプライアンス サーバに渡されるか、およびどのイベントがブロックされるかを選択できます。 イベントはポリシーに基づいて選択する必要があります。 たとえば、システムは特定のユーザまたはユーザ グループ間の IM をフィルタするか、IM の作成者および受信者に応じてコンテンツをブロックまたは変更するように設定することができます。
サードパーティ製のコンプライアンス ソリューションを使用するには、クラスタに対してサードパーティ コンプライアンス サーバを設定する必要があります。 IM and Presence サービスは、ユーザ ログイン、ログアウト、プレゼンス共有、IM 交換、またはグループ チャット アクティビティの処理の際に生成されたすべての設定イベントをサード パーティ サーバに渡します。 サードパーティ コンプライアンス サーバは、イベントに関連するポリシーやフィルタを適用し、IM and Presence サービスに対してイベントをさらに処理するかどうかを指示します。 IM and Presence サービスとサードパーティ製のコンプライアンス サーバとの間で受け渡されるイベントの量によっては、ネットワークでパフォーマンスの遅れが発生する可能性があることに注意してください。 IM and Presence サービスがサードパーティ サーバとの接続を失った場合、すべての IM トラフィックが停止します。
サードパーティ コンプライアンスには次のコンポーネントが必要です。
IM and Presence サービス Release 10.0(x):IM and Presence サービスはイベントをサード パーティ コンプライアンス サーバに送信するために Event Broker コンポーネントを使用します。
サードパーティ コンプライアンス サーバ:クラスタ内のすべての IM and Presence サービスノードは、コンプライアンスがすでに設定されたシステムからアップグレードしているのではないかぎり、イベントを設定されたコンプライアンス サーバにリダイレクトします。
IM クライアント:サポートされるクライアントには、Cisco Jabber などの Cisco クライアント、サードパーティ製 XMPP クライアント、および連動ネットワークで使用されるその他のサードパーティ製クライアントがあります。
(注)
IM and Presence サービスは、IM and Presence サービスとサードパーティ コンプライアンス サーバ間にセキュアな TLS/SSL 接続を提供しません。
サードパーティ製コンプライアンス サーバの設定ワークフロー
手順
ステップ 1 対応するコンプライアンス ベンダーのマニュアルにしたがってサードパーティ製コンプライアンス サーバをインストールします。 ステップ 2 サードパーティ製コンプライアンス サーバを IM and Presence サービス ノード上に設定します。 以下の「IM and Presence サービス でのサードパーティ製コンプライアンス サーバの設定」を参照してください。 ステップ 3 対応するコンプライアンス ベンダー要件に基づいてイベントを選択し、コンプライアンス プロファイルを設定します。 以下のコンプライアンス プロファイルを参照してください。 ステップ 4 必要に応じて、コンプライアンス プロファイル ルーティング プライオリティを設定します。 以下のコンプライアンス プロファイル ルーティング プライオリティを参照してください。 ステップ 5 IM and Presence サービス ノードにコンプライアンス サーバおよびコンプライアンス プロファイルを割り当てます。 以下の「コンプライアンス プロファイルのコンプライアンス サーバへの割り当て」および「サードパーティ製コンプライアンス サーバの IM and Presence サービス ノードへの割り当て」を参照してください。 ステップ 6 コンプライアンス サーバ上で、IM and Presence サービスによって生成される対応するオープンポート名を、それぞれのコンプライアンス ベンダーのマニュアルに基づいて設定します。
IM and Presence サービス上のサードパーティ コンプライアンス サーバの設定
はじめる前に手順
- サードパーティ製のコンプライアンス サーバをインストールおよび設定します。
- IM and Presence サービス ノードを、『Installing Cisco Unified Communications Manager(Cisco Unified Communications Manager のインストール)』で説明されるとおりにインストールします。
- IM and Presence サービス ノードを、『Configuration and Administration of IM and Presence Service on Cisco Unified Communications Manager(Cisco Unified Communications Manager での IM and Presence Service の設定および管理)』で説明されるとおりに設定します。
(注)
次の設定を変更する際には注意が必要です。 変更を保存すると、以前の設定はすべて失われます。
ステップ 1 を選択します。 ステップ 2 [Add New(新規追加)] をクリックします。 ステップ 3 コンプライアンス サーバ名、オプションの説明、ホスト名または IP アドレス、ポート、およびパスワードを入力します。 名前は IM and Presence サービスによってローカルでのみ使用されます。 IP アドレス、ポート、およびパスワードはコンプライアンス サーバ自体の設定に一致する必要があります。
(注) [Hostname/IP Address(ホスト名または IP アドレス)] フィールドで使用可能な文字はすべての英数字(a-zA-Z0-9)、ピリオド(.)、バックスラッシュ(\)、ダッシュ(-)、およびアンダースコア(_)です。
ステップ 4 [Save(保存)] をクリックします。
注意 IP アドレス、ポート、またはパスワードに変更を加えた場合、機能が稼動を継続するにはコンプライアンス上で対応する変更を加える必要がある場合があります。
コンプライアンス プロファイル
コンプライアンス プロファイルには、コンプライアンスのモニタに使用できる、一連の Jabber Session Manager(JSM)と Text Conferencing(TC)のイベントの両方またはいずれか一方が含まれます。 JSM イベントのみ、TC イベントのみ、または JSM および TC イベントの両方の組み合わせで構成されるコンプライアンス プロファイルを作成できます。
コンプライアンス プロファイルを設定する場合、どの JSM および TC イベントをコンプライアンス サーバにログ記録するかを選択します。 コンプライアンス サーバがどのタイプの処理を実行するか、IM and Presence Service がどのようにコンプライアンス サーバからのエラー応答を処理するか、また IM and Presence Service ノードがイベントをさらに処理する前にコンプライアンス サーバからの応答を待機するかどうかを決定できます。 応答が予期されない場合にイベントがどのように処理されるかも設定できます。
次の表は、JSM イベントおよびパラメータを説明しています。
注意
[Bounce(バウンス)]、および [Fire and Forget(火災と紛失)] の組み合わせが選択された場合、これが適用されるイベントがコンプライアンス サーバに渡され、その後破棄されます。 これは、IM and Presence Service によってさらに処理されないことを意味しています。 この組み合わせを使用する際は、十分注意してください。
表 1 JSM イベント イベント 説明 e_SESSION
新しいセッションが作成される、ログイン時に送信されたパケット。
e_OFFLINE
オフラインであるユーザに送信されるパケット。 オフライン ユーザはアクティブ セッションを持たないユーザです。
e_SERVER
内部処理のために直接サーバに送信されるパケット。
e_DELIVER
別のサーバからのパケットに対する最初のイベント。同じサーバ上のユーザからのパケットに対する 2 番目のイベント (同じサーバからのパケットに対する最初のイベントは es_IN です)。
e_AUTH
認証時に送信される IQ パケット。
e_REGISTER
ユーザによる新規アカウントの登録時に生成されるパケット。
e_STATS
定期的に送信されるサーバ統計情報が含まれるパケット。
e_DISCOFEAT
ユーザが disco#info クエリーを送信する場合にトリガーされます。
e_PRISESSION
ユーザが複数のセッションを持つ場合、ユーザのプライマリまたはデフォルト セッションを決定します。 EventBroker コンポーネントによってユーザ プライマリ セッションの選択肢が決まる場合があります。
es_IN
スタンザがユーザ セッションによって受信される直前に生成されます。
es_OUT
スタンザがユーザ セッションから送信されるときに生成されます。
es_END
ユーザがログアウトすると生成されるパケット。
表 2 JSM パラメータ パラメータ 説明 パケット タイプ
次の XMPP のパケット タイプからいずれかを選択します。 ハンドル
コンプライアンス サーバから返されるエラーが元のパーティまたはコンポーネントにバウンスされるようにする場合は [bounce(バウンス)] を、破棄する場合は [pass] を選択します。
火災と紛失
イベントの処理を継続する前に IM and Presence Service ノードがコンプライアンス サーバからの応答を待つ必要がある場合はチェックボックスをオンにします。 イベントをさらに継続するために IM and Presence Service ノードがコンプライアンス サーバからの応答を待つ必要がない場合はチェックボックスをオフにします。
次の表は、TC イベントおよびパラメータを説明しています。
注意
[Bounce(バウンス)]、および [Fire and Forget(火災と紛失)] の組み合わせが選択された場合、これが適用されるイベントがコンプライアンス サーバに渡され、その後破棄されます。 これは、IM and Presence Service によってさらに処理されないことを意味しています。 この組み合わせを使用する際は、十分注意してください。
表 3 TC イベント イベント 説明 onServicePacket
システムは、直接 TC サービスに向けられるかまたはシステム上に存在してしないルームに向けられたルータからのパケットを受信します。
onBeforeRoomCreate
ギアがシステム上にルームを作成しようとしています。
onAfterRoomCreate
部屋はシステム上に正常に作成されました。 唯一の有効な応答は、元のスタンザへの修正がない PASS です。
onServiceDiscoInfo
エンティティが TC サービスに disco#info パケットを送信しました。 有効な応答は PASS のみです。
onServiceReconfig
TC サービスは自身を再構成するシグナルを受信します。 有効な応答は PASS のみです。
これは通知イベントだけです。 XDB パケットのタイプは ="set" になります。 外部コンポーネントは、このパケットに応答することはできません。
onDestroy
ルームのオーナーがルームを閉じます。 有効な応答は PASS のみです。
onClose
ギアがルームを閉じることを要求します。
onPacket
新しい XML スタンザは、ルーム、またはルーム内の参加者に向けられます。
onMetaInfoGet
部屋の設定情報を利用できます。 有効な応答は PASS のみです。
onBeforeMetaInfoSet
ルームの設定をユーザが修正しようとしています。
onAfterMetaInfoSet
ルームの設定がユーザによって修正されました。 有効な応答は、中に何もない PASS のみです。
onExamineRoom
Jabber エンティティは、browse または disco によってルームから情報を要求します。 有効な応答は PASS のみです。
onBeforeChangeUser
ユーザ ロール、ニックネーム、またはプレゼンスの変更が要求されました。 これには、入室、退室、ニックネーム変更、アベイラビリティ変更、または任意のロール変更(音声の許可または無効化、モデレータ特権)などが含まれます。
onAfterChangeUser
ユーザが変更されました。 有効な応答は、中に何もない PASS のみです。
onBeforeChangeAffiliation
ユーザ アフィリエーションが変更されようとしています。
onAfterChangeAffiliation
ユーザ アフィリエーションが変更されました。 有効な応答は、中に何もない PASS のみです。
onBeforeRemoveAffiliation
ユーザ アフィリエーションが削除されようとしています。
onAfterRemoveAffiliation
ユーザ アフィリエーションが削除されました。 唯一の有効な応答は、元のスタンザへの修正がない PASS です。
onBeforeJoin
ユーザがルームを結合しようとしています。
onAfterJoin
ユーザがルームを結合しました。 有効な応答は、中に何もない PASS のみです。
onLeave
ユーザがルームから退室しました。 有効な応答は PASS のみです。
onBeforeSubject
ルームの件名が変更されようとしています。
onAfterSubject
ルームの件名が変更されました。 有効な応答は、中に何もない PASS のみです。
onBeforeInvite
ユーザがルームに招待されようとしています。
onAfterInvite
ユーザがルームに招待されました。 有効な応答は、中に何もない PASS のみです。
onHistory
ルームの履歴が要求されました。 有効な応答は PASS のみです。
onBeforeSend
メッセージがルームで送信されようとしています。
onBeforeBroadcast
メッセージがルームでブロードキャストされようとしています。
表 4 TC パラメータ パラメータ 説明 ハンドル
コンプライアンス サーバから返されるエラーが元のパーティまたはコンポーネントにバウンスされるようにする場合は [bounce(バウンス)] を、破棄する場合は [pass] を選択します。
火災と紛失
イベントの処理を継続する前に IM and Presence Service ノードがコンプライアンス サーバからの応答を待つ必要がある場合はチェックボックスをオンにします。 イベントをさらに継続するために IM and Presence Service ノードがコンプライアンス サーバからの応答を待つ必要がない場合はチェックボックスをオフにします。
同じコンプライアンス プロファイルが複数のコンプライアンス サーバに割り当てられている場合、イベントはそれぞれのコンプライアンス サーバにロード バランスされます。 これによって個々のコンプライアンス サーバの負荷が軽減されます。 イベントは、関連するイベントが同じコンプライアンス サーバにルーティングされることを保証するアルゴリズムを使用してルーティングされます。 一対一の IM では、イベントはパケットの方向に関係なく to/from アドレスの組み合わせに基づいてルーティングされます。 これは、2 人のユーザ間のカンバセーション全体が 1 つのコンプライアンス サーバにルーティングされることを意味しています。 グループ チャットでは、特定のチャット ルームに対するイベントがチャット ルーム アドレスを使用してルーティングされ、ルームに対するすべてのイベントが 1 つのコンプライアンス サーバにルーティングされます。
システム デフォルト プロファイルはフレッシュ インストールまたはアップグレード後にシステムで使用可能です。 このプロファイルは SystemDefaultComplianceProfile と呼ばれ、削除または変更できません。 他と同様にこのプロファイルは割り当ておよび割り当て解除できます。
SystemDefaultComplianceProfile プロファイルには 4 つの JSM と 5 つの TC イベントが設定されています。 このプロファイルが割り当てられている場合、そのイベントのいずれかが IM and Presence Service クラスタで発生する場合、処理のためにコンプライアンス サーバに渡され、応答が予期されます。 IM and Presence Service ノードは、コンプライアンス サーバからの応答に基づいてイベントを処理します。 これらのイベントは、SystemDefaultComplianceProfile が利用可能なコンプライアンス プロファイルから選択された場合、読み取り専用形式でプレビューされます。
表 5 SystemDefaultComplianceProfile Pre-Configured イベント JSM イベント TC イベント e_SESSION
onBeforeInvite
es_END
onBeforeJoin
es_IN(メッセージ スタンザのみ)
onBeforeRoomCreate
es_OUT(メッセージ スタンザのみ)
onBeforeSend
onLeave
同じイベントが複数のプロファイルで設定され、これらのプロファイルが異なるサードパーティ コンプライアンス サーバに割り当てられる場合、イベントはルーティング プライオリティで指定される順序で処理されます。 デフォルトでは、すべてのプロファイルのルーティング プライオリティはプロファイルがシステムに追加された順序で定義されます。 ルーティング プライオリティは再設定できます。
コンプライアンス プロファイルの設定
手順
ステップ 1 を選択します。 ステップ 2 [Add New(新規追加)] を選択します。 ステップ 3 コンプライアンス プロファイルの名前を入力します。 使用できる文字は英数字のみです。 スペースは使用できません。
(注) コンプライアンスのプロファイル名は、コンプライアンス プロファイルがコンプライアンス サーバに割り当てられている場合は変更できません。
ステップ 4 コンプライアンス プロファイルの説明を入力します。 このフィールドはオプションで、コンプライアンス プロファイルの目的を示す意味のある説明を含める必要があります。
ステップ 5 JSM または TC でイベントを選択します。 ステップ 6 JSM イベントについては、パケット タイプを選択します。 同じパケット タイプを持つ同じイベントを複数回設定することはできません。
[All(すべて)] を選択した場合、別のパケット タイプに対して同じイベントを、またはその逆を設定することはできません。
同じ JSM イベントにすべてのパケット タイプを設定することは、1 つの JSM イベントを All のパケット タイプで設定することと同じです。
ステップ 7 処理タイプを選択します。 ステップ 8 [Fire and Forget(火災と紛失)] チェックボックスを選択して、イベントがコンプライアンス サーバによって IM and Presence Service イベント処理チェーンの外で処理されるようにします。 IM and Presence Service は、コンプライアンス サーバの処理に関係なくイベントの処理を継続します。 デフォルトで、イベントはイベント処理チェーンの一部として処理され、IM and Presence Service はコンプライアンス サーバからの応答を待機します。
イベントがイベント処理チェーンの一部として処理され、コンプライアンス サーバが HANDLE で応答する場合、イベントは IM and Presence Service によってさらに処理されません。 コンプライアンス サーバが PASS で応答する場合、IM and Presence Service はイベントの処理を継続します。
ステップ 9 いずれかのタイプのイベントを追加するには、[Add New Event(新規イベントの追加)] を選択します。 トラブルシューティングのヒント
サードパーティ製コンプライアンス サーバに割り当てられたプロファイル内のイベントに対する設定を更新した場合、XCP Router サービスを再起動する必要があります。
次の作業
複数のコンプライアンス プロファイルが割り当てられていて、1 つのプロファイルからの一部のまたはすべてのイベントが他のプロファイル内に存在する場合、ルーティング プライオリティを設定できます。
コンプライアンス プロファイル ルーティング プライオリティ
複数のコンプライアンス プロファイルが割り当てられていて、1 つのプロファイルからの一部のまたはすべてのイベントが他のプロファイル内に存在する場合、ルーティング プライオリティを設定できます。 各コンプライアンス プロファイルに異なるイベントが設定されている場合、ルーティング プライオリティは適用されません。
システムで設定されたプロファイルのデフォルトのルーティング プライオリティは、設定された順序となります。
Ethical Wall 精査の対象となるイベントに設定されたコンプライアンス プロファイルと、IM ログ記録の対象となる同じイベントに設定されたコンプライアンス プロファイルがあります。 それぞれが異なるコンプライアンス サーバに割り当てられます。 Ethical Wall 精査の対象となるイベントを、IM ロギング サーバにログ記録する前に Ethical Wall にルーティングしたい場合、Ethical Wall コンプライアンス プロファイルにより高いプライオリティを割り当てる必要があります。
コンプライアンス プロファイル ルーティング プライオリティの設定
手順
ステップ 1 を選択します。 ステップ 2 [Compliance Profiles listed by routing priority(Top is highest priority)(ルーティング プライオリティ別にコンプライアンス プロファイルをリスト(最上部が最高のプライオリティ))] ウィンドウで、上下矢印を使用してコンプライアンス プロファイルに対するルーティング プライオリティを調整します。
次の作業
ルーティング プライオリティを変更したプロファイルが割り当てられた場合、Cisco XCP Router サービスを再起動する必要があります。 いつルータの再起動が必要になるかは、表示される警告メッセージを参照してください。
コンプライアンス サーバへのコンプライアンス プロファイルの割り当て
IM and Presence サービス 10.0.(1) で、以前にコンプライアンスが設定されていたシステムからアップグレードする場合を除き、クラスタ内のすべてのノードはコンプライアンスの対象となります。 これは、IM and Presence サービス ノードに複数のコンプライアンス サーバを割り当てることはできますが、コンプライアンスの対象とするためにすべての IM and Presence サービス ノードにコンプライアンス サーバを割り当てる必要はないことを意味しています。
クラスタ内の各コンプライアンス サーバは、異なるイベントのセットを処理するように設定できます。 これらのイベントのセットはコンプライアンス プロファイルで設定され、コンプライアンス サーバおよび IM and Presence サービス ノードに割り当てられます。
システム デフォルト プロファイルはフレッシュ インストールまたはアップグレード後にシステムで使用可能です。 このプロファイルは SystemDefaultComplianceProfile と呼ばれ、削除または変更できません。 他と同様にこのプロファイルは割り当ておよび割り当て解除できます。 独自のカスタム コンプライアンス プロファイルを作成するまで、ドロップダウン メニューから使用可能なデフォルトのコンプライアンス プロファイルは 1 つだけです。
10.0(1) 以前からアップグレードする場合、以前の割り当てには SystemDefaultComplianceProfile が割り当てられます。 これはドロップダウン メニューから使用可能な唯一のプロファイルです。 このデフォルト プロファイル内のイベントは、アップグレード前のシステムのものと同じイベントです。
以前のリリースでは、IM Compliance はノード単位で動作しました。 コンプライアンス サーバが割り当てられたノードはすべて、イベントがそのノードで生成された場合にのみ IM イベントをコンプライアンス サーバにログ記録しました。 このリリースでは、IM コンプライアンスはクラスタベースで機能します。 クラスタ内のノードの数またはどのノードにサードパーティ製のコンプライアンス サーバが割り当てられているかに関係なく、クラスタ内のすべてのノードがコンプライアンスの対象となります。 クラスタ内の任意のノードで生成された任意のイベントがコンプライアンス サーバのいずれかにログ記録されます。
10.0(1) 以前からアップグレードする場合、システムはアップグレード後にノードベースで機能しますが、クラスタ内のすべてのノードに対してコンプライアンス ログを有効にできます。 これを選択すると、割り当てを作成、更新、および削除したり、コンプライアンス プロファイルをシステム内に作成したカスタム コンプライアンス プロファイルに変更したりすることが可能になります。
(注)
以前にコンプライアンスが設定されていたシステム上のすべてのノードに対してコンプライアンス ロギングを有効にすることは必須ではありません。 ノード単位でコンプライアンス ロギングを保持することを選択できます。 この場合、コンプライアンス サーバでは SystemDefaultComplianceProfile だけを使用できます。
IM and Presence サービス ノードへのサードパーティ製コンプライアンス サーバの割り当て
手順
ステップ 1 を選択します。 ステップ 2 コンプライアンス サーバの選択項目から [Third-Party Compliance Server(サードパーティ コンプライアンス サーバ)] を選択します。 ステップ 3 IM and Presence サービス ノードにサードパーティ製コンプライアンス サーバを割り当てます。
(注) アップグレード前にコンプライアンスが設定されていたシステムからアップグレードした場合、同じノードを複数のコンプライアンス サーバに割り当てることはできません。 この場合、同じノードを複数のコンプライアンス サーバに割り当てたい場合、クラスタ全体に対するコンプライアンスを有効にする必要があります。
[Open-port Component Name(オープンポート コンポーネント名)] フィールドは、最初の 2 つの列内の値に基づいて自動的に生成されます。 これはオープンポートのコンポーネントを設定する場合に使用されます。
ステップ 4 各コンプライアンス サーバにコンプライアンス プロファイルを割り当てます。 同じコンプライアンス プロファイルを複数回割り当てることができます。
(注) 10.0(1) より前のバージョンからシステムをアップグレードして、コンプライアンスをアップグレード前に設定した場合、システムのデフォルト プロファイルのみをドロップ ダウン メニューから利用できます。 カスタム プロファイルを使用するには、クラスタ全体のコンプライアンスを有効にします。
ステップ 5 [Save(保存)] をクリックします。 ステップ 6 コンプライアンスがクラスタ内のすべてのノードに適用されている場合、すべてのノードで Cisco XCP ルータ サービスを再起動します。 これを実行しない場合、Cisco XCP Router サービスをこれらのコンプライアンスを設定したノードで再起動するだけで十分です。 トラブルシューティングのヒント
IM コンプライアンス展開オプションを切り替えた(たとえば、[Message Archiver] オプションから [Third-Party Compliance Server(サードパーティ コンプライアンス サーバ)] オプションに切り替えた)場合、Cisco XCP Router サービスを再起動する必要があります。 オプション間で切り替えるとサードパーティ コンプライアンス設定が失われることに注意してください。
アップグレードのシナリオ
このセクションには、現在コンプライアンスを設定している管理者が IM and Presence サービス 10.0.(1) にアップグレードする前に役立ついくつかのサンプル アップグレード シナリオが含まれています。
アップグレード シナリオ 1
第 1 段階
クラスタは 2 つのノードと 1 つのコンプライアンス サーバで構成されます。 ノード 1 はコンプライアンス サーバに接続され、このノードからのイベントのみがコンプライアンス サーバにルーティングされます。
第 2 段階
クラスタが IM and Presence サービス version 10.0 にアップグレードされると、ノード 1 はコンプライアンス サーバへの接続を維持し、このノードからのイベントのみがコンプライアンス サーバへルーティングされます。 ノード 1 とコンプライアンス サーバの両方が稼動を続行します。設定の変更は必要ありません。
第 3 段階
[Enable compliance logging for all nodes in the cluster(クラスタ内のすべてのノードに対してコンプライアンス ログを有効にする)] をチェックすることでクラスタ全体のコンプライアンスを有効にすると、ノード 1 はコンプライアンス サーバへの接続を維持します。 コンプライアンス サーバ上の設定は操作を維持するために更新する必要があります。 両方のノードからのイベントはノード 1 を介してコンプライアンス サーバにルーティングされます。
ページ上のアップグレード シナリオ 2
第 1 段階
クラスタは 2 つのノードと 2 つのサードパーティ製コンプライアンス サーバで構成されます。 各ノードは接続され、ノードごとにそれぞれのコンプライアンス サーバにイベントがルーティングされます。
第 2 段階
クラスタが IM and Presence サービス version 10.0 にアップグレードされた後、各ノードは接続され、ノードごとにそれぞれのコンプライアンス サーバにイベントがルーティングされます。 両方のノードとそれぞれのコンプライアンス サーバの両方は稼動を継続し、設定の変更は必要ありません。
第 3 段階
[Enable compliance logging for all nodes in the cluster(クラスタ内のすべてのノードに対してコンプライアンス ログを有効にする)] をチェックすることでクラスタ全体のコンプライアンスを有効にすると、各ノードがそのコンプライアンス サーバに接続されます。 コンプライアンス サーバ上の設定は操作を維持するために更新する必要があります。 ノード 1 およびノード 2 からのイベントが各コンプライアンス サーバにルーティングされます。
ページ上のアップグレード シナリオ 3
第 1 段階
クラスタは 2 つのノードと 2 つのサードパーティ製コンプライアンス サーバで構成されます。 各ノードは接続され、ノードごとにそれぞれのコンプライアンス サーバにイベントがルーティングされます。
第 2 段階
クラスタが IM and Presence サービス version 10.0 にアップグレードされた後、各ノードは接続され、ノードごとにそれぞれのコンプライアンス サーバにイベントがルーティングされます。 両方のノードとそれぞれのコンプライアンス サーバの両方は稼動を継続し、設定の変更は必要ありません。
第 3 段階
アップグレードされた IM and Presence サービス version 10.0 クラスタで、コンプライアンスを持たない追加のノード、ノード 3 が追加されます。
[Enable compliance logging for all nodes in the cluster(クラスタ内のすべてのノードに対してコンプライアンス ログを有効にする)] をチェックすることでクラスタ全体のコンプライアンスを有効にすると、各ノードがそのコンプライアンス サーバに接続されます。 コンプライアンス サーバ上の設定は操作を維持するために更新する必要があります。 ノード 1 およびノード 2 からのイベントが各コンプライアンス サーバにルーティングされます。 ノード 3 上のイベントはノード 1 およびノード 2 上の開いたポートを通して両方のコンプライアンス サーバにルーティングされます。
ページ上のアップグレード後にすべてのノードに対してコンプライアンス ロギングを有効化
手順
ステップ 1 を選択します。 ステップ 2 コンプライアンス サーバの選択項目から [Third-Party Compliance Server(サードパーティ コンプライアンス サーバ)] を選択します。 ステップ 3 [Enable compliance logging for all nodes in the cluster(クラスタ内のすべてのノードに対してコンプライアンス ログを有効にする)] を選択します。 イネーブルにした場合、この設定を元に戻すことはできません。 最適な設定チェックボックスに関してはマニュアルを参照し、[Save(保存)] をクリックします。 警告メッセージが表示されます。
ステップ 4 [OK] をクリックします。 ステップ 5 クラスタ内のすべてのノードで Cisco XCP Router サービスを再起動します。
次の作業
すべてのノードに対してコンプライアンスを有効化した後、IM and Presence サービスによって使用されるコンポーネント名が自動生成された形式に変更されます。 機能の使用を継続するには、新しいコンポーネント名でコンプライアンス サーバを更新します。
単一のコンプライアンス サーバまたはサービスのシャットダウン
単一のコンプライアンス サーバまたはサービスのアングレースフルな失敗またはネットワークの中断
想定される展開:
サブクラスタで展開される 1 つ以上の IM and Presence サービス ノード。
1 つの IM and Presence サービス ノードが単一のサードパーティ コンプライアンス サーバで設定されます。
最初の 5 分間まで、コンプライアンス サーバまたはサービスがアングレースフルに失敗した場合、または IM and Presence サービス ノードとコンプライアンス サーバ間でネットワークの中断があった場合、ノードはそのコンプライアンス サーバに対してイベントのキューイングを試行します。 個々のイベントは処理またはバウンスされる前に 30 秒間キューに置かれます。
5 分経過してもコンプライアンス サーバまたはネットワークが回復していない場合、サーバへの接続がドロップされ、イベントはキューに置かれなくなります。 この場合、イベントは即時に処理またはバウンスされます。 ユーザには次のような影響があります。
複数のコンプライアンス サーバでのコンプライアンス サーバまたはサービスのグレースフルな停止
想定される展開:
サブクラスタに展開された 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:
プロファイル 2:
プロファイルの割り当て
通常動作時:
ユーザが IM を送信すると、プロファイル 1 の es_OUT イベントはコンプライアンス サーバ 1 にルーティングされます。 コンプライアンス サーバ 1 がイベントを許可する場合、プロファイル 2 の es_OUT イベントはコンプライアンス サーバ 2 にルーティングされます。
コンプライアンス サーバ 1 にアングレースフルな停止が発生すると、以下のシーケンスが実行されます。
ユーザ A がユーザ B に IM を送信します。
es_OUT イベント(プロファイル 1)がコンプライアンス サーバ 1 のキューに入れられます。
es_OUT イベント(プロファイル 1)が 30 秒後にタイムアウトします。
es_OUT イベント(プロファイル 1)はバウンスされ、IM 送信者はエラー応答を受信します。
es_OUT(プロファイル 2)イベントは処理されず、イベントはコンプライアンス サーバ 2 に送信されません。
この場合、ユーザには以下のような影響があります。
手動のノードのフェールオーバー時のコンプライアンス処理
想定される展開:
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 Router サービスの障害またはシャットダウンでない場合は、コンプライアンス イベントは通常どおりコンプライアンス サーバに継続してルーティングされます。 フェールオーバーが発生した 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 分以上継続する場合、イベントは展開内の別のコンプライアンス サーバによって処理され、スタンザは通常どおり配信されます。
Cisco XCP Router サービス障害中のコンプライアンス処理
想定される展開:
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 サービス ノードに接続されたコンプライアンス サーバにルーティングされます。
IM and Presence サービス ノードおよびサードパーティ製コンプライアンス サーバ アラーム
手順IM and Presence サービス ノードがサードパーティ製コンプライアンス サーバに統合されている場合、メッセージは、サードパーティ製コンプライアンス サーバに正常にログ記録された後にのみユーザに配信されます。
IM and Presence サービス ノードが、直接接続されているサードパーティ製コンプライアンス サーバとの接続を失った場合、IM and Presence サービス はメッセージを受信者に配信しません。
この接続が失われたときに通知を受けるためには、この状態に関連するアラームが正しく設定されていることを確認する必要があります。
ステップ 1 IM and Presence サービス にサインインします。 ステップ 2 を選択します。 ステップ 3 [Server(サーバ)] ドロップダウン メニューからアラームを設定したいサーバを選択し、[Go(移動)] をクリックします。 ステップ 4 [Service Group(サービス グループ)] ドロップダウン リストから [IM and Presence Services(IM and Presence サービス)] を選択し、[Go(移動)] をクリックします。 ステップ 5 [Service(サービス)] ドロップダウン メニューから [Cisco XCP Router(Cisco XCP ルータ)] を選択し、[Go(移動)] をクリックします。 ステップ 6 必要に応じてアラーム設定を行います。 ステップ 7 [Save(保存)] をクリックします。
サードパーティ製コンプライアンス サーバのトラブルシューティング
コンプライアンス/統合が期待どおりに動作せず、以下のような問題が発生している場合。
この場合、以下のチェックリストを使用してコンプライアンス統合のトラブルシューティングを実行します。
[Compliance Server Settings(コンプライアンス サーバの設定)] ウィンドウの [Troubleshooter(トラブルシュータ)] をチェックします。 [Troubleshooter(トラブルシュータ)] が赤の場合はステップ 2 に進みます。 [Troubleshooter(トラブルシュータ)] がグリーンの場合はステップ 3 に進みます。
サードパーティ製コンプライアンス サーバ設定ウィンドウで、サードパーティ製コンプライアンス サーバに対する接続設定をチェックします。
Cisco XCP Router サービスがサードパーティ製コンプライアンス サーバとの接続を確立したかどうかを検証するには、RTMT を使用して Cisco XCP Router サービス ログをチェックしてください。 以下のようなエントリに対してログをスキャンします。
- ログが CONNECTED を表示するが ACTIVE を表示しない場合は以下を検証してください。
正しいパスワードは IM and Presence サービス およびサードパーティ製コンプライアンス サーバで設定されています。
正しいコンポーネント名がサードパーティ製コンプライアンス サーバで設定されています。
Cisco XCP Router サービスがサードパーティ製コンプライアンス サーバに接続できない場合、Cisco XCP ルータ サービス ログが以下のような出力を表示します。
Connecting on fd 22 to host '10.53.52.205', port 7999 Unable to connect to host '10.53.52.205', port 7999:(111) Connection refused Component op-gwydlvm131.gwydlvm1153-cisco-com is GONE- Cisco XCP Router サービスがサードパーティ製コンプライアンス サーバと接続を確立できない場合、以下を確認してください。
IM and Presence サービスがコンプライアンス サーバに処理用にイベントを渡す際にログが CONNECTED および ACTIVE を示している場合、IM and Presence サービスでイベントの処理を続行するには、サードパーティ製コンプライアンス サーバが事前に各イベントに応答する必要があります。 コンプライアンス サーバが応答していないと考えられる場合は、コンプライアンス サーバのログを確認してください。