Cisco Unity Connection の Database Replication のトラブルシューティング

[Shuhei Mentani]

１．概要

本ドキュメントでは、Cisco Unity Connection (CUC) クラスタで、

• 設定変更が正常に反映されない問題
• 受信したはずの Voice Message がユーザのメールボックスに配信されない問題

など様々な問題の要因となり得る、Database Replication の問題に対するトラブルシューティング方法を紹介します。

CUC のクラスタは、Publisher と Subscriber の2台構成ですが、クラスタ内の Database は、以下の2種類の Database Replication によって同期されます。

1. Enterprise Replication (ER)
2. Unity Connection Replication (UCR)

２．2種類の Database Replication について

2-1. Enterprise Replication (ER)

Cisco Unified Communications Manager (CUCM) 6.x 以降と同様の Replication です。

参考URL：
Linux アプライアンス モデルにおける CUCM データベース レプリケーションのトラブルシューティング

CUC の Database の同期は、ER をベースとした UCR によって行われるため、必ず、ER の状態が正常である必要があります。
具体的には、上記リンクで紹介されているとおり、Real Time Monitoring Tool (RTMT) で確認可能な Replication Status が Publisher, Subscriber 共に 2 である必要があります。
RTMT の　Replication Status は
show perf query class "Number of Replicates Created and State of Replication"
でも確認が可能です。

----- コマンド実行例 -----

2-2. Unity Connection Replication (UCR)

ER が正常に動作(Status が 2)している状態で、UCR によって CUC の Publisher と Subscriber 間のデータベースの同期が行われます。
UCR の正常性は、show cuc cluster status コマンドで確認が可能です。

以下のレプリケーションのステータスが Connected であれば正常です。

３．Database Replication の復旧について
3-1. ER の Status が 2 にも関わらず、UCR の Status が Dropped の場合
Subscriber 上で、utils cuc cluster overwritedb を実行することで、Publisher から Subscriber へ Database を上書きコピーすることで復旧できる場合があります。

注意）
データベースの規模が小さいラボ環境では、5分強で上書きコピーは終了しましたが、環境によっては1時間程度要する場合があります。
実行後、Subscriberは自動で再起動します。
Publisherへの影響は無いと考えられますが、営業時間外などに保守作業時間を設けて実施して下さい。

----- コマンド実行例 -----

3-2. ER の Status が 2 にも関わらず、UCR の Status が Disconnected や、3-1 で復旧しない場合
Publisher の Database 上の Subscriber に関する管理情報が壊れている可能性が高く、Subscriber の再インストールが必要となる場合が多いです。
調査次第では、再インストール以外での対処によって復旧できる場合がありますので、必要に応じて Cisco TAC へお問い合わせ下さい。

なお、Subscriber の再インストールは以下の手順で実施して下さい。

1. Subscriber をシャットダウン
2. Cisco Unity Connection Administration にログインして、System Setting > Cluster に移動して、Subscriber の情報を削除
3. Publisher を再起動
4. Cisco Unity Connection Administration にログインして、System Setting > Cluster に移動して、Subscriber を再追加
5. Subscriber を再インストール

3-3. ER の Status が 2 以外の場合
utils dbreplication clusterreset コマンドによって復旧できる可能性があります。

 (*) 営業時間外などに保守作業時間を設けて実施して下さい。

utils dbreplication clusterreset コマンドの手順
(1) Subscriber 上で utils dbreplication stop コマンドを実行し、完了後、次へ

----- コマンド実行例 -----

(2) Publisher 上で utils dbreplication stop コマンドを実行し、完了後、次へ

 (*) コマンド実行例は (1) と同様

(3) Publisher と Subscriber 上で utils dbreplication runtimestate コマンドを実行し "RPC?" が “YES” であることを確認

----- コマンド実行例 -----

 (*) Subscriber も同様

(4) Publisher 上で utils dbreplication dropadmindb コマンドを実行し、完了後、次へ

----- コマンド実行例 -----

(5) Subscriber 上で utils dbreplication dropadmindb コマンドを実行し、完了後、次へ

 (*) コマンド実行例は (4) と同様

(6) Publisher 上で utils dbreplication reset all コマンドを実行

----- コマンド実行例 -----

(7) Publisher と Subscriber 上で定期的に utils dbreplication runtimestate コマンドを実行し、 以下のような出力となれば完了

----- コマンド実行例 -----

(8) 実行後、1時間程度経過した後にも、ER の Status が 2 にならない場合は、以下のログを収集の上、Cisco TAC へお問い合わせ下さい。

•  utils dbreplication runtimestate
•  file get activelog cm/trace/dbl/*.log
•  file get activelog cm/trace/dbl/sdi/dbmon*.txt
•  file get activelog cm/log/informix/dbl_repl*.log
•  file get activelog cm/log/informix/ccm*.log

４．役に立つリンク

• Linux アプライアンス モデルにおける CUCM データベース レプリケーションのトラブルシューティング
• Cisco Unity Connection Clustering（CUCのクラスタの概要を説明）