CUCM データベース レプリケーションのトラブルシューティング

はじめに

このドキュメントでは、データ レプリケーションの問題を診断する方法と、この問題のトラブルシューティングと解決に必要な手順について説明します。

データベース レプリケーションを診断する手順

このセクションでは、データベースレプリケーションが失敗するシナリオについて説明し、問題を診断して切り分けるためにTACエンジニアが従うトラブルシューティング方法を示します。

ステップ 1：データベースレプリケーションが壊れていることの確認

データベース レプリケーションが壊れたかどうかを判断するには、レプリケーションの Real Time Monitoring Tool（RTMT）のさまざまな状態を知っている必要があります。

データベースの複製を確認するには、次の図に示すように、パブリッシャノードのCLIからutils dbreplication runtimestateコマンドを実行します。 

その出力で、クラスタ レプリケーション状態に古い同期情報が含まれていないことを確認します。同じことを確認し、タイムスタンプを使用します。

ブロードキャスト同期が最近の日付で更新されていない場合は、utils dbreplication status コマンドを実行して、すべてのテーブルとレプリケーションを確認します。エラーと不一致が検出されると、次の図のように、出力に表示され、それに応じて RTMT 状態が変化します。

コマンドを実行すると、すべての表の一貫性が確認され、正確なレプリケーション ステータスが表示されます。

注：すべてのテーブルのチェックを許可してから、トラブルシューティングに進みます。

正確なレプリケーション ステータスが表示されたら、最初の出力に示されているように、レプリケーション セットアップ（RTMT）と詳細を確認します。ノードごとにステータスを確認する必要があります。状態が 2 以外になっているノードがあれば、トラブルシューティングを続けます。

ステップ 2：CUCMのCisco Unified ReportingページからのCMデータベースステータスの収集

1. ステップ1が完了したら、次の図に示すように、Cisco Unified Communications Manager(CUCM)パブリッシャのNavigationドロップダウンリストからCisco Unified Reportingオプションを選択します。

2. [System Reports] に移動し、この図に示すように、[Unified CM Database Status] をクリックします。

3. 「Generate New Report」オプションを使用して新しいレポートを生成するか、次の図に示すように「Generate New Report」アイコンをクリックします。

4.レポートを生成してダウンロードしたら、サービスリクエスト(SR)をオープンする必要が生じた場合にTACエンジニアに提供できるように、レポートを保存します。

ステップ 3：エラーとしてフラグが付けられたコンポーネントのUnified CMデータベースレポートを確認する

コンポーネントにエラーがある場合は、次の図に示すように、エラーに赤いXアイコンのフラグが付きます。

• ローカルデータベースとパブリッシャデータベースにアクセスできることを確認します。

• エラーがある場合は、ノード間のネットワーク接続を確認します。A Cisco DBサービスがノードのCLIから実行され、utils service listコマンドを使用するかどうかを確認します。

• A Cisco DB サービスがダウンしている場合は、utils service start A Cisco DB コマンドを実行して、サービスを開始します。これが失敗した場合は、Cisco TACにお問い合せください。     

• すべてのノードでレプリケーション サーバ リスト（cdr list serv）が入力されていることを確認します。

次の図は、理想的な出力を示しています。

 Cisco Database Replicator（CDR）リストが空になっているノードがある場合は、ステップ 8 を参照してください。

• Unified CM Hosts、Rhosts、および Sqlhost がすべてのノードで同等であることを確認します。

これは重要なステップです。次の図に示すように、Unified CM Hosts、Rhosts、および Sqlhost はすべてのノードで同等です。

Hosts ファイルが一致しない：

サーバで IP アドレスをホスト名に変更または更新する際のアクティビティが正しくない可能性があります。

IP アドレスを CUCM のホスト名に変更するには、次のリンクを参照してください。

IP アドレスおよびホスト名の変更

パブリッシャサーバのCLIからこれらのサービスを再起動し、不一致が解消されているかどうかを確認します。ある場合は、ステップ8に進みます。サポートされていない場合は、Cisco TACにお問い合わせください。GUI/CLI で変更を加えるたびに新しいレポートを生成して、その変更が含まれているかどうかを確認します。

Cluster Manager ( utils service restart Cluster Manager) 
A Cisco DB ( utils service restart A Cisco DB)

Rhosts ファイルが一致しない：

Rhosts ファイルが Hosts ファイルとともに一致しない場合は、「Hosts ファイルが一致しない」で説明した手順に従います。 Rhosts ファイルのみが一致しない場合は、CLI から次のコマンドを実行します。

A Cisco DB ( utils service restart A Cisco DB )
Cluster Manager ( utils service restart Cluster Manager)

新しいレポートを生成し、Rhost ファイルがすべてのサーバで同等であるかどうかを確認します。ある場合は、ステップ8に進みます。サポートされていない場合は、Cisco TACにお問い合わせください。

Sqlhosts が一致しない：

Sqlhosts ファイルが Hosts ファイルとともに一致しない場合は、「Hosts ファイルが一致しない」で説明した手順に従います。Sqlhosts ファイルのみが一致しない場合は、CLI から次のコマンドを実行します。

utils service restart A Cisco DB

新しいレポートを生成し、Sqlhosts ファイルがすべてのサーバで同等であるかどうかを確認します。ある場合は、ステップ8に進みます。サポートされていない場合は、Cisco TACにお問い合わせください

• 次の図のように、データベース層リモート プロシージャ コール（DBL RPC）hello が正常に完了していることを確認します。

  RPC hello が特定のノードに対して機能しない場合：

• その特定のノードとパブリッシャ間のネットワーク接続を確認します。
• ポート番号 1515 がネットワークに割り当てられていることを確認します。

TCP/UDP ポートの使用に関する詳細は、次のリンクを参照してください。

Cisco Unified Communications Manager の TCP および UDP ポートの使用

• 次の図のように、ネットワーク接続がノード間で正常に機能していることを確認します。

ノードのネットワーク接続が失敗した場合：

• ノード間にネットワーク到達可能性があることを確認します。
• 適切な TCP/UDP ポート番号がネットワークに割り当てられていることを確認します。

新しいレポートを生成し、接続が正常に機能していることを確認します。接続が正常に機能していない場合は、ステップ 8 に進みます。

ステップ 4：Utils Diagnose Testコマンドを使用する個々のコンポーネントの確認

utils diagnose test コマンドは、すべてのコンポーネントをチェックし、合格/不合格の値を返します。データベース レプリケーションが適切に機能するために必要なコンポーネントは、次のとおりです。

• ネットワーク接続:

validate_network コマンドは、クラスタ内のすべてのノードでネットワーク接続のあらゆる側面をチェックします。接続の問題があれば、多くの場合、エラーがドメイン ネーム サーバ/逆引きドメイン ネーム サーバ（DNS/RDNS）に表示されます。validate_network コマンドは、300 秒でこの操作を完了します。ネットワーク接続性テストでよく見られるエラー メッセージは、次のとおりです。

1.エラー「Intra-cluster communication is broken」が発生しました（次の図を参照）。

• 原因

このエラーは、クラスタ内の 1 つ以上のノードにネットワーク接続の問題があると発生します。すべてのノードに ping の到達可能性があることを確認します。

• 作用

クラスタ内通信が壊れていると、データベース レプリケーションの問題が発生します。

2. Reverse DNS lookup failed。

• 原因

このエラーは、ノードで逆引き DNS ルックアップが失敗すると発生します。ただし、次のコマンドを使用すると、DNSが設定され、正しく機能するかどうかを確認できます。

utils network eth0 all - Shows the DNS configuration (if present)
utils network host <ip address/Hostname> - Checks for resolution of ip address/Hostname

• 作用

DNSが正しく機能しないと、サーバが定義されてホスト名を使用する際に、データベースレプリケーションの問題が発生する可能性があります。

• Network Time Protocol（NTP）の到達可能性：

NTPは、サーバの時刻と基準クロックの同期を維持する役割を担います。パブリッシャはNTPサーバとしてリストされているIPを持つデバイスと常に時刻を同期しますが、サブスクライバはパブリッシャと時刻を同期します。

データベース レプリケーションの問題を回避するためには、NTP が完全に機能することが非常に重要です。

NTPストラタム（親参照クロックまでのホップ数）は5未満である必要があり、そうでない場合は信頼性が低いと見なされます。

NTP ステータスをチェックするには、次の手順を実行します。

1. 次の図のように、utils diagnose test コマンドを使用して、出力をチェックします。

  2.さらに、次のコマンドを実行できます。

utils ntp status

ステップ 5：すべてのノードからの接続ステータスをチェックし、認証されていることを確認します

1. ステップ 4 の完了後、報告された問題がなければ、次の図のように、すべてのノードで utils network connectivity コマンドを実行して、データベースへの接続が正常に機能していることを確認します。

2. 「Cannot send TCP/UDP packets」というエラーメッセージが表示された場合は、ネットワークに再送信がないかどうかを確認するか、TCP/UDPポートをブロックしてください。show network cluster コマンドは、すべてのノードが認証されているかどうかをチェックします。

3.ノードのステータスが認証されていない場合は、次の図に示すように、ネットワーク接続とセキュリティパスワードがすべてのノードで同じであることを確認します。

セキュリティ パスワードを変更/回復するには、次のリンクを参照してください。

CUCM でパスワードをリセットする方法

CUCM オペレーティング システム管理者パスワードの回復

手順 6：Utils Dbreplication Runtimestateコマンドで「out of sync」または「not Requested」ステータスが表示される

データベース レプリケーションは、クラスタ内のすべてのノードに実際のテーブルをプッシュするため、ネットワークの使用率が非常に高いタスクであることを理解することが重要です。次の内容を確認してください。

•  ノードが同じデータセンター/サイト内にある：ラウンドトリップ時間(RTT)が短いすべてのノードに到達できます。RTTが異常に高い場合は、ネットワークのパフォーマンスをチェックします。

•  ノードがワイドエリアネットワーク(WAN)上に分散している：ノードのネットワーク接続が80ミリ秒未満であることを確認します。レプリケーション プロセスに参加できないノードがある場合は、次に示すように、パラメータの値を大きくします。

utils dbreplication setprocess <1-40>

注：このパラメータを変更すると、レプリケーション設定のパフォーマンスは向上しますが、システムリソースがさらに消費されます。

• レプリケーションタイムアウトは、クラスター内のノード数に基づきます。レプリケーションタイムアウト（既定： 300秒）は、すべてのサブスクライバーが定義されたメッセージを送信するのをパブリッシャーが待機する時間です。クラスタ内のノードの数に基づいて、レプリケーションのタイムアウトを計算してください。

Server 1-5 = 1 Minute Per Server Servers 6-10  = 2 Minutes Per Server Servers >10 = 3 Minutes Per Server.

Example: 12 Servers in Cluster : Server 1-5 * 1 min = 5 min, + 6-10 * 2 min = 10 min, + 11-12 * 3 min = 6 min,  
Repltimeout should be set to 21 Minutes.

レプリケーションのタイムアウトを確認/設定するコマンド：

show tech repltimeout ( To check the current replication timeout value )
utils dbreplication setrepltimeout ( To set the replication timeout )

手順7と8は、チェックリストを満たした後に実行する必要があります。

チェックリスト：

• すべてのノードが互いに接続されている。ステップ 5 を参照してください。

• RPC に到達可能である。ステップ 3 を参照してください。

• ノードが8より大きい場合は、ステップ7および8に進む前にCisco TACに問い合せてください。

• 営業時間外に手順を実行する。

手順 7：データベースレプリケーション用の全テーブルまたは選択テーブルの修復

utils dbreplication runtimestate コマンドにより、エラー/不一致のテーブルがあると示された場合は、次のコマンドを実行します。

Utils dbreplication repair all

utils dbreplication runtimestate コマンドを実行して、ステータスをもう一度確認します。

ステータスが変更されていない限り、ステップ 8 に進みます。

ステップ 8：データベースレプリケーションを最初からリセットする

データベースレプリケーションをリセットしてプロセスを最初から開始する手順を参照してください。

utils dbreplication stop all  (Only on the publisher)
utils dbreplication dropadmindb (First on all the subscribers one by one then the publisher)
utils dbreplication reset all ( Only on the publisher )

このプロセスを監視するには、RTMT/utils dbreplication runtimestate コマンドを実行します。

次の一連のコマンドを参照して、特定のノードのデータベース レプリケーションをリセットします。

utils dbreplication stop <sub name/IP> (Only on the publisher)
utils dbreplcation dropadmindb (Only on the affected subscriber)
utils dbreplication reset <sub name/IP> (Only on the publisher )

Cisco TACに連絡してさらにサポートを受ける場合は、次の出力とレポートが提供されていることを確認してください。

utils dbreplication runtimestate
utils diagnose test
utils network connectivity

レポート:

• Cisco Unified Reporting CMデータベースレポート（ステップ2を参照）。

• CLIからutils create report databaseコマンドを実行し、.tarファイルをダウンロードしてSFTPサーバを使用します。

関連情報

• CUCMのutils dbreplication runtimestateの出力について
• CUCM データベース レプリケーション Linux アプライアンス モデルのトラブルシューティング
• CXデリバリデータ保護およびプライバシー