この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、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 サービス リリース 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 サービスがどのようにコンプライアンス サーバからのエラー応答を処理するか、また IM and Presence サービス ノードがイベントをさらに処理する前にコンプライアンス サーバからの応答を待機するかどうかを決定できます。応答が予期されない場合にイベントがどのように処理されるかも設定できます。
次の表は、JSM イベントおよびパラメータを説明しています。
![]() 注意 | [BOUNCE]、および [火災と紛失(Fire and Forget)] の組み合わせが選択された場合、これが適用されるイベントがコンプライアンス サーバに渡され、その後破棄されます。これは、IM and Presence サービスによってさらに処理されないことを意味しています。この組み合わせを使用する際は、十分注意してください。 |
イベント | 説明 |
---|---|
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 |
ユーザが EM からログアウトするときの電話履歴の自動クリア。 |
パラメータ | 説明 |
---|---|
パケット タイプ(Packet Type) |
次の XMPP のパケット タイプからいずれかを選択します。 |
処理(Handling) |
コンプライアンス サーバから返されるエラーが元のパーティまたはコンポーネントにバウンスされるようにする場合は [BOUNCE] を、破棄する場合は [PASS] を選択します。 |
火災と紛失(Fire and Forget) |
イベントの処理を継続する前に IM and Presence サービス ノードがコンプライアンス サーバからの応答を待つ必要がある場合はチェックボックスをオンにします。イベントをさらに継続するために IM and Presence サービス ノードがコンプライアンス サーバからの応答を待つ必要がない場合はチェックボックスをオフにします。 |
次の表は、TC イベントおよびパラメータを説明しています。
![]() 注意 | [BOUNCE]、および [火災と紛失(Fire and Forget)] の組み合わせが選択された場合、これが適用されるイベントがコンプライアンス サーバに渡され、その後破棄されます。これは、IM and Presence サービスによってさらに処理されないことを意味しています。この組み合わせを使用する際は、十分注意してください。 |
イベント | 説明 |
---|---|
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 |
メッセージがルームでブロードキャストされようとしています。 |
パラメータ | 説明 |
---|---|
処理(Handling) |
コンプライアンス サーバから返されるエラーが元のパーティまたはコンポーネントにバウンスされるようにする場合は [BOUNCE] を、破棄する場合は [PASS] を選択します。 |
火災と紛失(Fire and Forget) |
イベントの処理を継続する前に IM and Presence サービス ノードがコンプライアンス サーバからの応答を待つ必要がある場合はチェックボックスをオンにします。イベントをさらに継続するために IM and Presence サービス ノードがコンプライアンス サーバからの応答を待つ必要がない場合はチェックボックスをオフにします。 |
同じコンプライアンス プロファイルが複数のコンプライアンス サーバに割り当てられている場合、イベントはそれぞれのコンプライアンス サーバにロード バランスされます。これによって個々のコンプライアンス サーバの負荷が軽減されます。 イベントは、関連するイベントが同じコンプライアンス サーバにルーティングされることを保証するアルゴリズムを使用してルーティングされます。一対一の IM では、イベントはパケットの方向に関係なく to/from アドレスの組み合わせに基づいてルーティングされます。これは、2 人のユーザ間のカンバセーション全体が 1 つのコンプライアンス サーバにルーティングされることを意味しています。グループ チャットでは、特定のチャット ルームに対するイベントがチャット ルーム アドレスを使用してルーティングされ、ルームに対するすべてのイベントが 1 つのコンプライアンス サーバにルーティングされます。
システム デフォルト プロファイルはフレッシュ インストールまたはアップグレード後にシステムで使用可能です。このプロファイルは SystemDefaultComplianceProfile と呼ばれ、削除または変更できません。他と同様にこのプロファイルは割り当ておよび割り当て解除できます。
SystemDefaultComplianceProfile プロファイルには 4 つの JSM と 5 つの TC イベントが設定されています。このプロファイルが割り当てられている場合、そのイベントのいずれかが IM and Presence サービス クラスタで発生する場合、処理のためにコンプライアンス サーバに渡され、応答が予期されます。IM and Presence サービス ノードは、コンプライアンス サーバからの応答に基づいてイベントを処理します。これらのイベントは、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 サービス イベント処理チェーンの外で処理されるようにします。IM and Presence サービスは、コンプライアンス サーバの処理に関係なくイベントの処理を継続します。
デフォルトで、イベントはイベント処理チェーンの一部として処理され、IM and Presence サービスはコンプライアンス サーバからの応答を待機します。 イベントがイベント処理チェーンの一部として処理され、コンプライアンス サーバが HANDLE で応答する場合、イベントは IM and Presence サービスによってさらに処理されません。コンプライアンス サーバが PASS で応答する場合、IM and Presence サービスはイベントの処理を継続します。 | ||
ステップ 9 | いずれかのタイプのイベントを追加するには、[新規イベントの追加(Add New Event)] を選択します。
トラブルシューティングのヒント サードパーティ製コンプライアンス サーバに割り当てられたプロファイル内のイベントに対する設定を更新した場合、XCP Router サービスを再起動する必要があります。 |
複数のコンプライアンス プロファイルが割り当てられていて、1 つのプロファイルからの一部のイベントまたはすべてのイベントが他のプロファイル内に存在する場合、ルーティング プライオリティを設定できます。
複数のコンプライアンス プロファイルが割り当てられていて、1 つのプロファイルからの一部のまたはすべてのイベントが他のプロファイル内に存在する場合、ルーティング プライオリティを設定できます。各コンプライアンス プロファイルに異なるイベントが設定されている場合、ルーティング プライオリティは適用されません。
システムで設定されたプロファイルのデフォルトのルーティング プライオリティは、設定された順序となります。
以下は、コンプライアンス プロファイル ルーティング プライオリティを使用する場合の例を示しています。
Ethical Wall 精査の対象となるイベントに設定されたコンプライアンス プロファイルと、IM ログ記録の対象となる同じイベントに設定されたコンプライアンス プロファイルがあります。それぞれが異なるコンプライアンス サーバに割り当てられます。Ethical Wall 精査の対象となるイベントを、IM ロギング サーバにログ記録する前に Ethical Wall にルーティングしたい場合、Ethical Wall コンプライアンス プロファイルにより高いプライオリティを割り当てる必要があります。
ルーティング プライオリティを変更したプロファイルが割り当てられた場合、Cisco XCP ルータ サービスを再起動する必要があります。ルータの再起動が必要なときに関して先頭に表示される警告メッセージの指示に従います。
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 ルータ サービスをこれらのコンプライアンスを設定したノードで再起動するだけで十分です。
トラブルシューティングのヒント IM コンプライアンス展開オプションを切り替えた(たとえば、[Message Archiver] オプションから [サードパーティ コンプライアンス サーバ(Third-Party Compliance Server)] オプションに切り替えた)場合、Cisco XCP ルータ サービスを再起動する必要があります。オプション間で切り替えるとサードパーティ コンプライアンス設定が失われることに注意してください。 |
このセクションには、現在コンプライアンスを設定している管理者が IM and Presence サービス 10.0.(1) にアップグレードする前に役立ついくつかのサンプル アップグレード シナリオが含まれています。
第 1 段階 |
クラスタは 2 つのノードと 1 つのコンプライアンス サーバで構成されます。ノード 1 はコンプライアンス サーバに接続され、このノードからのイベントのみがコンプライアンス サーバにルーティングされます。 |
第 2 段階 |
クラスタが IM and Presence サービス バージョン 10.0 にアップグレードされると、ノード 1 はコンプライアンス サーバへの接続を維持し、このノードからのイベントのみがコンプライアンス サーバへルーティングされます。ノード 1 とコンプライアンス サーバの両方が稼動を続行します。設定の変更は必要ありません。 |
第 3 段階 |
をチェックすることでクラスタ全体のコンプライアンスを有効にすると、ノード 1 はコンプライアンス サーバへの接続を維持します。コンプライアンス サーバ上の設定は操作を維持するために更新する必要があります。両方のノードからのイベントはノード 1 を介してコンプライアンス サーバにルーティングされます。 ページ上の [クラスタ内のすべてのノードに対してコンプライアンス ログを有効にする(Enable compliance logging for all nodes in the cluster)] |
第 1 段階 |
クラスタは 2 つのノードと 2 つのサードパーティ製コンプライアンス サーバで構成されます。各ノードは接続され、ノードごとにそれぞれのコンプライアンス サーバにイベントがルーティングされます。 |
第 2 段階 |
クラスタが IM and Presence サービス バージョン 10.0 にアップグレードされた後、各ノードは接続され、ノードごとにそれぞれのコンプライアンス サーバにイベントがルーティングされます。両方のノードとそれぞれのコンプライアンス サーバの両方は稼動を継続し、設定の変更は必要ありません。 |
第 3 段階 |
をチェックすることでクラスタ全体のコンプライアンスを有効にすると、各ノードがそのコンプライアンス サーバに接続されます。コンプライアンス サーバの設定は運用を維持するために更新しなければなりません。ノード 1 およびノード 2 からのイベントが各コンプライアンス サーバにルーティングされます。 ページ上の [クラスタ内のすべてのノードに対してコンプライアンス ログを有効にする(Enable compliance logging for all nodes in the cluster)] |
第 1 段階 |
クラスタは 2 つのノードと 2 つのサードパーティ製コンプライアンス サーバで構成されます。各ノードは接続され、ノードごとにそれぞれのコンプライアンス サーバにイベントがルーティングされます。 |
第 2 段階 |
クラスタが IM and Presence サービス バージョン 10.0 にアップグレードされた後、各ノードは接続され、ノードごとにそれぞれのコンプライアンス サーバにイベントがルーティングされます。両方のノードとそれぞれのコンプライアンス サーバの両方は稼動を継続し、設定の変更は必要ありません。 |
第 3 段階 |
アップグレードされた IM and Presence サービス バージョン 10.0 クラスタで、コンプライアンスを持たない追加のノード、ノード 3 が追加されます。 をチェックすることでクラスタ全体のコンプライアンスを有効にすると、各ノードがそのコンプライアンス サーバに接続されます。コンプライアンス サーバの設定は運用を維持するために更新しなければなりません。ノード 1 およびノード 2 からのイベントが各コンプライアンス サーバにルーティングされます。ノード 3 上のイベントはノード 1 およびノード 2 上の開いたポートを通して両方のコンプライアンス サーバにルーティングされます。 ページ上の [クラスタ内のすべてのノードに対してコンプライアンス ログを有効にする(Enable compliance logging for all nodes in the cluster)] |
![]() 注意 | この設定を有効にした場合、元に戻すことはできません。 |
ステップ 1 | を選択します。 |
ステップ 2 | コンプライアンス サーバの選択項目から [サードパーティ製コンプライアンス サーバ(Third-Party Compliance Server)] を選択します。 |
ステップ 3 | [クラスタ内のすべてのノードに対してコンプライアンス ログを有効にする(Enable compliance logging for all nodes in the cluster)] を選択します。イネーブルにした場合、この設定を元に戻すことはできません。最適な設定チェックボックスに関してはマニュアルを参照し、[保存(Save)] をクリックします。
警告メッセージが表示されます。 |
ステップ 4 | OK をクリックします。 |
ステップ 5 | クラスタ内のすべてのノードで Cisco XCP ルータ サービスを再起動します。 |
すべてのノードに対してコンプライアンスを有効化した後、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 サービス ノードが複数のコンプライアンス サーバに接続するように設定されていて、それぞれ異なるコンプライアンス プロファイルを使用しており、プロファイルに 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 に送信されません。
この場合、ユーザには以下のような影響があります。
IM and Presence サービス ノードの障害発生時のコンプライアンス処理
想定される展開:
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 サービス ノードに接続されたコンプライアンス サーバにルーティングされます。
IM and Presence サービス ノードがサードパーティ製コンプライアンス サーバに統合されている場合、メッセージは、サードパーティ製コンプライアンス サーバに正常にログ記録された後にのみユーザに配信されます。
IM and Presence サービス ノードが、直接接続されているサードパーティ製コンプライアンス サーバとの接続を失った場合、IM and Presence サービスはメッセージを受信者に配信しません。
この接続が失われたときに通知を受けるためには、この状態に関連するアラームが正しく設定されていることを確認する必要があります。
ステップ 1 | IM and Presence サービスにサインインします。 |
ステップ 2 | を選択します。 |
ステップ 3 | [サーバ(Server)] ドロップダウン メニューからアラームを設定するサーバを選択し、[移動(Go)] をクリックします。 |
ステップ 4 | [サービス グループ(Service Group)] ドロップダウン リストから [IM and Presence サービス(IM and Presence Services)] を選択し、[移動(Go)] をクリックします。 |
ステップ 5 | [サービス(Service)] ドロップダウン メニューから [Cisco XCP ルータ(Cisco XCP Router)] を選択し、[移動(Go)] をクリックします。 |
ステップ 6 | 必要に応じてアラーム設定を行います。 |
ステップ 7 | [保存(Save)] をクリックします。 |
コンプライアンス/統合が期待どおりに動作せず、以下のような問題が発生している場合。
この場合、以下のチェックリストを使用してコンプライアンス統合のトラブルシューティングを実行します。
[コンプライアンス サーバの設定(Compliance Server Settings)] ウィンドウの [トラブルシュータ(Troubleshooter)] をチェックします。[トラブルシュータ(Troubleshooter)] が赤の場合はステップ 2 に進みます。[トラブルシュータ(Troubleshooter)] がグリーンの場合はステップ 3 に進みます。
サードパーティ製コンプライアンス サーバ設定ウィンドウで、サードパーティ製コンプライアンス サーバに対する接続設定をチェックします。
Cisco XCP ルータ サービスがサードパーティ製コンプライアンス サーバとの接続を確立したかどうかを検証するには、RTMT を使用して Cisco XCP ルータ サービス ログをチェックしてください。以下のようなエントリに対してログをスキャンします。
正しいパスワードは IM and Presence サービス およびサードパーティ製コンプライアンス サーバで設定されています。
正しいコンポーネント名がサードパーティ製コンプライアンス サーバで設定されています。
Cisco XCP ルータ サービスがサードパーティ製コンプライアンス サーバに接続できない場合、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 サービスでイベントの処理を続行するには、サードパーティ製コンプライアンス サーバが事前に各イベントに応答する必要があります。コンプライアンス サーバが応答していないと考えられる場合は、コンプライアンス サーバのログを確認してください。