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

はじめに

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

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

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

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

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

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

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

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

o

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

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

正確なレプリケーション ステータスが表示されたら、最初の出力に示されているように、レプリケーション セットアップ（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アイコンをクリックします。

4. 新しいレポートが正常に生成されるまで待機します。

5. レポートが生成されたら、アイコンをクリックしてレポートをダウンロードし、サービスリクエスト(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配信データ保護とプライバシー