IM および存在サーバ 高可用性 目次

はじめに前提条件要件使用されているコンポーネントIM および存在 High Availability（HA）冗長性グループ 設定監視された IM および存在サービスユーザ フェールオーバー プロセスJabber クライアント再ログイン タイマーIM および存在フォールバック型手動フォールバック自動フォールバックIM および存在高可用性を解決して下さい

概要

この資料にどのように即刻メッセージおよび存在（IM&P）エンタープライズ IM および存在環境の作業高可用性（別名冗長性の）およびそれを解決する方法を記述されています。

前提条件

要件

次の項目に関する知識が推奨されます。

Cisco Unified IM&P●

Cisco Jabber クライアント●

使用されているコンポーネント

Cisco Unified IM&P 10.0 以上に●

Cisco Jabber クライアント 9.6 以上に●

この 文書に記載されている 情報は特定のラボ 環境のコンポーネントから作成されました。 この資料で使用した初期 （デフォルト） 設定からコンポーネントすべては開始しました。 対象のネットワークが実稼働中である場合には、どのような作業についても、その潜在的な影響について確実に理解しておく必要があります。

IM および存在 High Availability（HA）

CUCM 設定の論理サーバー グループの形の IM および存在オファー ハイ アベイラビリティまた

は冗長性。  IM にこの設定がおよび存在通じ、次に IM の場合に冗長性を可能にするのにおよび存在サービスまたはサーバ障害利用されています。  HA イベントが起こるとき、エンドユーザのセッションは障害のあるサーバからバックアップに移られます。  サーバが NORMAL 状態に復元する、ユーザセッションは管理者によってそれからどちらか自動または手動で戻されます。  

冗長性グループ 設定

冗長性グループは IM にサーバの割り当てをおよび存在 subcluster、また HA のための設定可能にする論理サーバー ペアです。  設定のこの部分にアクセスすることは CUCM サーバ Webページで見つけることができます。

システム > 存在冗長性グループ

管理者が CUCM の System > Server 設定に IM&P パブリッシャを追加し、IM&P サーバが保存されるとき、DefaultCUPSubCluster 冗長性グループはそれに割り当てられるパブリッシャと作成されます。  

作成されたとき、冗長性グループはこのようになります:

この冗長性グループは IM および存在 subcluster に変換します。  CUCM の冗長性グループ 設定の現在のステートでは、これはそれが IM をおよび存在クラスタ トポロジ Webページのように見えるものにです:

IM&P パブリッシャが DefaultCUPSubcluster に割り当てられ、加入者サーバがないことがわかります。  これは IM&P 加入者サーバが CUCM 設定の冗長性グループに割り当てられないという理由によります。

冗長性グループにサブスクライバを割り当てて下さい:

加入者サーバを冗長性グループに割り当てるために、ドロップダウンのから加入者サーバをそれから保存しますコンフィギュレーション変更を単に選択して下さい。

IM&P の後でサブスクライバは冗長性グループに追加されます:

セカンダリ ノード（サブスクライバ）の付加が私達高可用性のオプションを得た後見ます。  高可用性を有効に するために、イネーブル高可用性のチェックボックスを選択し、コンフィギュレーション変更を保存する単に必要があります。

高可用性の後で有効に されます:

ページはオートリフレッシュ断絶状態および原因。  サーバが初期化状態にあるとき、これは 2つのサーバが通信できることを意味します。  サーバは NORMAL 状態に状態遷移の前にそれからサービス ステータスを確認します。  2 つのサーバが互いに接続でき、すべての監視されたサービスが両方に稼働していれば、それから標準標準状態を得ます。 これはすべての監視されたサービスが IM&P サーバでアクティブであることを意味します。

標準標準冗長性グループ状態:

Topology ページ IM&P の標準標準高可用性の状態:

監視された IM および存在サービス

顧客はさまざまな配置 モ デルがある可能性があるので: どのプロセス監視することはダイナミックである IM のみ、IM 耐久性があるチャットだけ、リモート呼び出しコントロール、等と準拠性、IM と SIP/XMPP フェデレーション、IM と、実際のリストの。 デフォルトでこれらの項目はHA が有効に なるとき常に監視されます:

IDS データベース

（アクティブにされた場合）存在エンジン

XCP ルータ

準拠性（メッセージ Archiver がことを）、耐久性があるチャット（テキスト会議 マネージャ）、SIP フェデレーション（SIP フェデレーション Connection Manager）、XMPP フェデレーション（XMPP フェデレーション Connection Manager）設定されたかどうか確認するサーバ リカバリマネージャ チェック（およびアクティブにされる）。  それらが設定され、アクティブになる場合、サーバ リカバリ Manager（SRM）はそれらのサービスを同様に監察します。

ユーザ フェールオーバー プロセス

フェールオーバーが（自動か手動）起こるとき、覚えるべき主要なポイントはユーザアカウントが 1 サーバから他に移られないが、存在エンジンのユーザセッションだけ移動されますことです。  IM の pre-10 バージョンおよび存在では、ユーザー割り当ては 1 サーバから他に移られました。  サーバにあったこのユーザ移動はサーバ リソースに非常に高く、ロードに追加されました。 10.X およびそれ以降では、ユーザはそれらがに割り当てられる、存在エンジンのバックエンド

ユーザセッションは壊れたノードから機能ノードに移られますことサーバでホームにい。  ユーザは変更がサーバ リカバリ Manager（SRM）と起こるとき Jabber および再ログをの終了する必要がありません。

Jabber クライアント再ログイン タイマー

フェールオーバー イベントの後でセカンダリ IM&P ノードで完全にアクティブになるユーザセッションのためにユーザは石鹸（クライアント プロファイル エージェント）でそのサーバにログインに試みる必要があります。  これは IMDB データベースから渡されるワンタイムパスワードで自動的に起こります。 ログ ins が IM のリソースおよび存在サーバに大きな費用がかかるので、フェールオーバー イベントが発生するときログ ins を絞る方法がある必要があります。  このスロットルかバッファはセカンダリ ノードのユーザ向けのサービス中断なしでセカンダリ ノードにログインにすべてのユーザを割り当てます。  ユーザログ ins を絞るのに使用するメカニズムはクライアント再ログイン低限およびクライアント再ログイン 上限 サーバ リカバリManager（SRM）サービスパラメータです。  

クライアント再ログイン低限-クライアントが HA イベントの場合にセカンダリサーバにログインに試みる前に Jabber クライアントが待っている時間の最低要量を定義するパラメータ（秒で）。

クライアント再ログイン 上限-クライアントが HA イベントの場合にセカンダリサーバにログインに試みる前に Jabber クライアントが待っている時間の最大量を定義するパラメータ（秒で）。

Jabber クライアントはサーバにログインでこれらのパラメータを受け取り、値を今後使用できるようにキャッシュします。  IM&P サーバから HA イベントを受け取る場合、クライアントは上部および低限間の秒の乱数を選択し、Jabber クライアントの前の時間数がセカンダリにログインに試みること待っています。  タイマーが切れれば、クライアントはセカンダリ ノードに石鹸ログインを試みます。

IM および存在フォールバック型

ユーザ フェールオーバーがある場合、サービスが問題となるサーバで復元するときユーザ フォールバックがある必要があります。  サーバ フォールバックには 2 つの型があります:

手動フォールバック

手動フォールバック（サーバ リカバリ マネージャのためのデフォルト 設定）はサービスが復元する 冗長性グループ許可しますフォールバック ボタンを起こり。 このボタンが選択される場合、セカンダリ ノードに移動されたユーザセッションはホーム ノードに戻って、移動されます。Jabber クライアントはフォールバックのための上部および低限の再ログを適用します。

自動フォールバック

自動フォールバックはサーバがサービスを監察し、サーバ リカバリ Manager（SRM）サービスがホーム ノードにフォールバック ユーザ自動的にと起こります。  この設定のキーは自動フォールバックが始められる前に壊れるサービス/サーバがアクティブのままになることができるようにサーバ リカバリ Manager（SRM）サービスが 30 分を待っていることです。  この 30 分アップタイムが確立されれば、ユーザセッションはホーム ノードに戻って移動されます。  Jabber クライアントはフォールバックのための上部および低限の再ログを適用します。 

自動フォールバックはデフォルト 設定ではないです、しかし有効に することができます。  自動フォールバックを有効に するために、本当を評価するためにサーバ リカバリ マネージャ サービスパラメータのイネーブル自動フォールバック パラメータを変更して下さい。

IM および存在高可用性を解決して下さい

問題を IM の HA および存在で解決するために情報を収集して下さい:

サーバはフェールオーバー イベント（デバッグ レベルもし可能なら）の前後にからの回復します Manager（SRM）ログを

●

IM&P コマンド ライン インターフェースによるコマンドの出力は enterprisesubcluster からSQL を『*』 を選択 します実行します IM&P の enterprisesubcluster 表は冗長性グループ 設定を収容します

●

IM&P コマンド ライン インターフェースによるコマンドの出力は enterprisenode から SQLを『*』 を選択 します実行します enterprisenode 表はノードのノード 情報および subcluster割り当てを表示するものです

●