Cisco Unified Communications Manager マネー ジド サービス ガイド リリース 8.5(1)

RTMT の [Summary] ビュー

RTMT の [Summary] ビューには、次のような毎日のモニタが必要なシステムの健全性がすべて表示されます。

• CPU 使用率レベル

• メモリ使用率レベル

• 電話登録ステータス

• 進行中のコール

• ゲートウェイ ステータス

CPU およびメモリ使用率レベルが 70% の限度を超えると、コール処理に関連する Cisco Unified CM パブリッシャおよびサブスクライバが過負荷の状態になります。システムの健全性とパフォーマンスの問題の主なインジケータとして次のものがあります。

• システム時間、ユーザ時間、IOWait、ソフト irq、irq

• CPU Pegging アラート

• 最も CPU を使用するプロセス

• 高 % iowait

• 共通パーティションによる高 % iowait

• ディスク I/O を担当するプロセス

• CodeYellow

ワークステーションまたは PC で RTMT クライアントを常時実行しない場合は、必要な各アラートのしきい値と通知の方法を設定できます。これで、ワークステーションまたは PC 上の RTMT クライアントを終了できます。

Cisco Unified CM サーバが稼動状態になると、RTMT バックエンド、AMC サービスがただちに稼動して、必要なすべての情報を収集、処理し、設定された通知の方法に応じてユーザに通知します。

RTMT の [CPU and Memory] ページには、次の項目について CPU 使用率が表示されます。

• %System：システム レベル（カーネル）での実行の CPU 使用率のパーセンテージ表記

• %User：ユーザ レベル（アプリケーション）での実行の CPU 使用率のパーセンテージ表記

• %IOWait：未処理のディスク I/O 要求を待機して CPU がアイドル状態になっていた時間のパーセンテージ表記

• %SoftIrq：プロセッサが遅延 IRQ 処理（ネットワーク パケットの処理など）を実行する時間のパーセンテージ表記

• %Irq：割り込みのためにデバイスに割り当てられた割り込み要求をプロセッサが実行する時間、または処理の完了時にコンピュータに信号を送信する時間のパーセンテージ表記

CPU 使用率

CPU 使用率が高いと、サービスに遅延または中断が発生し、コール処理に影響を与えることがあります。エンド ユーザのサービスに影響を与えることもあります。場合によっては、高い CPU 使用率がメモリ リークを示していることもあります。RIS DataCollector PerfMonLog を有効にすると CPU 使用率がトラッキングされます。

（注） RIS DataCollector PerfMonLog を有効にすることを推奨します。

表 3-2 に、CPU 使用率のガイドラインを示します。

API を使用して CPU 使用率のモニタもできます。SOAP API を使用すると、次の perfmon カウンタをモニタできます。

• Processor オブジェクト：% CPU Time、System Percentage、User Percentage、IOwait Percentage、Softirq Percentage、Irq Percentage

• Process オブジェクト：% CPU Time

SNMP インターフェイスを使用すると、次の perfmon カウンタをモニタできます。

• Host Resource MIB：hrProcessorLoad、hrSWRunPerfCPU

• CPQHOST-MIB：cpqHoCpuUtilMin、cpqHoCpuUtilFiveMin

CPU 使用率が高い場合は、原因となるプロセスを特定してください。%system と %user、またはそのいずれかが高いために CPUPegging アラートが生成される場合は、アラート メッセージをチェックし、CPU を最も使用しているプロセスを確認してください。RTMT の [Process] ページに移動し、[%CPU] でソートして、高 CPU のプロセスを特定します。

図 3-2 に CPU 使用率を示します。

図 3-2 Cisco Unified Serviceability の CPU 使用率

RIS Data Collector PerfMonLog は、分析用にプロセスの %CPU 使用率をシステム レベルでトラッキングします。

RTMT は CPU 使用率をモニタし、CPU 使用率がしきい値を超えると CallProcessingNodeCPUPegging アラートを生成します。図 3-3 にアラート ステータスの画面を示します。

図 3-3 RTMT の [Alert Central] のアラート ステータス画面

[In Safe Range] 列を頻繁にモニタしてください。[No] と表示される場合は、状況は解決されていません。たとえば、CallProcessingNodeCPUPegging の [In Safe Range] 列に [No] と表示される場合は、そのノードの CPU 使用率がしきい値を超えており、注意が必要であることを示します。

高い CPU 使用率により、CallProcessingNodeCPUPegging に加えて次のアラートがトリガーされることがあります。

• CodeYellow

• CodeRed

• CoreDumpFileFound

• CriticalServiceDown

• LowCallManagerHeartbeatRate

• LowTFTPServerHeartbeatRate

• LowAttendantConsoleHeartRate

サービスがクラッシュする場合は、対応するトレース ファイルが上書されている可能性があります。クラッシュをトラブルシューティングするために、シスコ テクニカル アシスタンス センター（TAC）ではトレース ファイルを必要とします。CoreDumpFileFound、CodeYellow、および CriticalServiceDown の場合は、シスコ TAC を支援するために [Enable Trace Download] オプションを有効にしてください。

% IOwait のモニタリング

%IOwait が高い場合は、ディスク入出力（I/O）アクティビティが頻繁に行われていることを示します。高 IOwait 状況の次の点を考慮してください。

• 頻繁なメモリ スワッピング：スワップ パーティションの %CPU Time をチェックして、高レベルのメモリ スワッピング アクティビティが発生しているかどうかを確認します。頻繁なメモリ スワッピングの原因の 1 つとしてメモリ リークが考えられます。

• DB アクティビティ：データベースがアクティブ パーティションにアクセスします。アクティブ パーティションの %CPU Time が高い場合は、DB アクティビティが頻繁に行われている可能性が高くなります。

• トレースおよびログ ファイルを保存する共通（ログ）パーティション：次の内容を確認します。

– [Trace & Log Central] で、トレース収集アクティビティが実行されているかどうかを確認します。コール処理に影響している場合は（つまり CodeYellow）、トレース収集スケジュールの調整を検討してください。zip オプションを使用している場合は、このオプションをオフにします。

– 詳細レベルでのトレース設定では、Cisco Unified CM により多くのトレースが生成されます。高 %iowait と Cisco Unified CM、またはそのいずれかが CodeYellow の状態にあり、Cisco Unified CM サービス トレースの設定が [Detailed] の場合は、トレース設定を [Error] に変更し、トレースの書き込みを減らします。

RTMT を使用すると、高 %IOwait の原因となるプロセスを特定できます。

• %IOwait が高いために CPUPegging アラートが発生する場合は、アラート メッセージをチェックし、ディスク I/O を待機しているプロセスを確認します。

• RTMT の [Process] ページに移動して、[Status] でソートします。[UNINTERRUPTIBLE DISK SLEEP] の状態にあるプロセスを確認します。

• RIS Data Collector PerfMonLog ファイルをダウンロードし、プロセスのステータスを長期間確認します。

図 3-4 に、[Status] でソートした RTMT の [Process] ウィンドウの例を示します。[UNINTERRUPTIBLE DISK SLEEP] の状態にあるプロセスを確認します。FTP プロセスが、[UNINTERRUPTIBLE DISK SLEEP] の状態になっています。

図 3-4 [UNINTERRUPTIBLE DISK SLEEP] の状態にある FTP プロセス

仮想メモリ

仮想メモリは、物理メモリ（RAM）とスワップ メモリ（ディスク）で構成されています。RTMT の [CPU and Memory] ウィンドウには、次のようなシステム レベルのメモリ使用率情報が表示されます。

• [Total]：物理メモリの合計

• [Free]：空きメモリの量

• [Shared]：使用されている共有メモリの量

• [Buffers]：バッファリングの目的で使用されているメモリの量

• [Cached]：キャッシュに入れられているメモリの量

• [Used]：[Total] - [Free] - [Buffers] - [Cached] + [Shared] の式で計算

• [Total Swap]：スワップ領域の合計

• [Used Swap]：システム上で使用されているスワップ領域の量

• [Free Swap]：システム上で使用可能な空きスワップ領域の量

（注） SOAP API を使用すると、次の perfmon カウンタに関するメモリ情報を照会できます。

• Memory オブジェクト：% Mem Used、% VM Used、Total Kbytes、Total Swap Kbytes、Total VM Kbytes、Used Kbytes、Used Swap Kbytes、Used VM Kbytes

• Process オブジェクト：VmSize、VmData、VmRSS、% Memory Usage

SNMP を使用すると、次の perfmon カウンタを照会できます。

• Host Resource MIB：hrStorageSize、hrStorageUsed、hrStorageAllocationUnits、hrStorageDescr、hrStorageType、hrMemorySize

（注） RTMT の [Trace & Log Central] を使用すると、履歴情報をダウンロードできます。Cisco AMC Service PerfMonLog はデフォルトで有効になります。Cisco AMC Service PerfMonLog は、Cisco Unified CM Release 6.0 では、Cisco RIS Data Collector PerfMonLog が導入されたため非推奨になりました。Cisco RIS Data Collector PerfMonLog は、Cisco Unified CM Release 5.x ではデフォルトで無効になり、Cisco Unified CM Release 6.0 ではデフォルトで有効になります。

（注） perfmon 仮想メモリはメモリの合計（物理 + スワップ）を指し、Host Resource MIB 仮想メモリはスワップ メモリだけを指します。

RTMT の [Process] ウィンドウには、次のようなプロセス レベルのメモリ使用率情報が表示されます。

• [VmSize]：プロセスにより使用される仮想メモリの合計

• [VmRSS]：コード、データ、スタックなど、プロセスにより使用される、現在物理メモリ内にあるレジデント セット

• [VmData]：プロセスによるヒープの仮想メモリ使用率

• [Page Fault Count]：データを物理メモリにロードする必要があった、プロセスで発生した主なページ フォールトの数

図 3-5 に RTMT の [Process] ウィンドウを示します。[VmSize] タブをクリックすると VmSize をソートできます。これで、多くのメモリを消費するプロセスを特定できます。

図 3-5 RTMT プロセスごとにリストされた VmSize

VmSize が増加し続けている場合は、メモリ リークの可能性があります。

プロセスでメモリ リークが発生している場合は、システム管理者は、トレース ファイルを含めてシスコに報告する必要があります。RIS Data Collector PerfMonLog はデータを収集します。ここには、メモリ使用率に関する履歴情報が含まれます。

ディスク使用率

Cisco Unified CM のハード ドライブには、次の 4 つのディスクまたはパーティションがあります。

• 共通パーティション（ログ パーティション）：トレースおよびログ ファイルが格納されます。

• アクティブ パーティション：アクティブな OS および Cisco Unified CM リリースのファイル（バイナリ、ライブラリ、および設定ファイル）が格納されます。

• 非アクティブ パーティション：別の Cisco Unified CM リリースのファイルが格納されます（アップグレード元の古いバージョンやアップグレード先の新しいバージョンなど。ただし、サーバはこのリリースに切り替えられていない）。

• スワップ パーティション：スワップ領域に使用します。

SOAP API を使用すると、次の perfmon カウンタに関するパーティション情報を取得できます。

• Partition オブジェクト：Total Mbytes、Used Mbytes、Queue Length、Write Bytes Per Sec、Read Bytes Per Sec

SNMP MIB を使用すると、次の情報を照会できます。

• Host Resource MIB：hrStorageSize, hrStorageUsed hrStorageAllocationUnits、hrStorageDescr、hrStorageType

RTMT の [Trace & Log Central] を使用すると、次の履歴情報をダウンロードできます。

• Cisco AMC Service PerfMonLog // はデフォルトで有効になります。Cisco Unified CM 6.0 では、Cisco RIS Data Collector PerfMonLog が導入されたため非推奨になりました。

• Cisco RIS Data Collector PerfMonLog // は、Cisco Unified CM Release 5.x ではデフォルトで無効になり、Cisco Unified CM 6.0 ではデフォルトで有効になります。

図 3-6 に、RTMT でのパーティションごとのディスク使用率を示します。

図 3-6 パーティションごとのディスク使用率

ディスク名マッピング

RTMT と SOAP に表示される perfmon インスタンス名は次のとおりです。

• Active

• Inactive

• Common

• Boot

• Swap

• SharedMemory

Host Resource MIB hrStorage の説明に表示される名前は次のとおりです。

• /partB

• /common

• /grub

• 仮想メモリ

• /dev/shm

パーティション アラートは次のとおりです。

• LogPartitionLowWaterMarkExceeded：ログ パーティションの使用済みディスク領域のパーセンテージが設定された下限を下回ると、発生します。このアラートは、管理者がディスク領域をクリーンアップできるように早期に発生する警告と考えてください。RTMT の [Trace & Log Central] を使用してトレースおよびログ ファイルを収集し、これらのトレースおよびログ ファイルをサーバから削除できます。システム管理者は、トレースおよびログファイルを手動でクリーンアップするだけではなく、再び下限に達しないように、保存するトレース ファイルの数も調整する必要があります。

• LogPartitionHighWaterMarkExceeded：ログ パーティションの使用済みディスク領域のパーセンテージが設定された上限を超えると、発生します。このアラートが生成されると、Log Partition Monitoring（LPM）ユーティリティがログ パーティションのファイルの削除を開始し、ディスク領域の不足を防ぐために、ファイルの数が下限に達するまでファイルの削除を続けます。保持しておきたいファイルの一部を LPM が削除することがあるため、LogPartitionLowWaterMarkExceed アラートを受領したらただちに対処する必要があります。

• LowActivePartitionAvailableDiskSpace：アクティブ パーティションの利用可能なディスク領域のパーセンテージが設定された値を下回ると発生します。デフォルトのしきい値を使用することを推奨します。デフォルトのしきい値では、このアラートは生成されません。このアラートが発生した場合、システム管理者は一時的な回避策としてしきい値を調整できます。ただし、シスコ TAC がこの問題を確認する必要があります。リモート アクセスを使用して /tmp を確認します。これまでに、サードパーティ製ソフトウェアによってここに大規模なファイルが残されていたことがあります。

• LowInactivePartitionAvailableDiskSpace：非アクティブ パーティションの利用可能なディスク領域のパーセンテージが設定された値を下回ると発生します。デフォルトのしきい値を使用することを推奨します。デフォルトのしきい値では、このアラートは生成されません。このアラートが発生した場合、システム管理者は一時的な回避策としてしきい値を調整できます。ただし、シスコ TAC がこの問題を確認する必要があります。

表 3-3 に、Cisco Unified CM Release 4.x と Cisco Unified CM Release 5.x のディスクに関連する perfmon カウンタの比較を示します。

データベース複製と Cisco Unified Communication Manager ノード

RTMT の [Database Summary] を使用すると、図 3-7 に示すようにデータベース アクティビティをモニタできます。たとえば、[CallManager] > [Service] > [Database Summary] の順にクリックします。

図 3-7 RTMT の [Database Summary]

Cisco Unified CM プロセスと CPU 使用率

Cisco Unified CM プロセスは「ccm」と表されます。

表 3-4 に、Cisco Unified CM プロセスと CPU 使用率についての一般的なガイドラインを示します。

ccm プロセスはマルチスレッド アプリケーションであるため、MCS-7845 サーバの方がプロセッサ数が多く、CPU 使用率のしきい値が低くなっています。ただし、メイン ルータ スレッドがコール処理の大部分を実行します。複数のプロセッサを使用できる場合でも、1 つのスレッドを複数のプロセッサで同時に実行できません。したがって、アイドル状態のプロセッサがある場合でも、ccm メイン ルータ スレッドで CPU リソースが不足することがあります。

ハイパー スレッディングを使用した MCS-7845 サーバには 4 つの仮想プロセッサが搭載されています。したがって、コール処理のためにメイン ルータ スレッドが最大速度で実行されているサーバで、他の 3 つのプロセッサがほぼアイドル状態になっていることがあります。この場合、CPU 使用率の合計が 25 ～ 30% の場合でも、UC Manager の状態が Code Yellow になることがあります。同様に、2 つの仮想プロセッサを備えた MCS-7835 サーバでは、CPU 使用率が約 50 ～ 60% の場合に UC Manager の状態が Code Yellow になることがあります。

次を使用して perfmon カウンタを照会します。

• SOAP API

– perfmon カウンタ

– デバイス情報

– DB アクセス

– CDR アクセス

• SNMP

– CISCO-CCM-MIB：ccmPhoneTable、ccmGatewayTable など。

– RTMT の [Trace & Log Central] を使用して履歴情報をダウンロードします。

– Cisco AMC Service PerfMonLog はデフォルトで有効になります。これは Cisco Unified CM Release 6.0 では、Cisco RIS Data Collector PerfMonLog が導入されたため非推奨になりました。

– Cisco RIS Data Collector PerfMonLog は、Cisco Unified CM Release 5.x ではデフォルトで無効になり、Cisco Unified CM Release 6.0 ではデフォルトで有効になります。

CodeYellow

CodeYellow の状態は、ccm プロセスが過負荷の状態にあるため、それ以上着信コールを処理できない場合に発生します。この場合、Cisco Unified CM がコール スロットリングを開始します。これは、RTMT で 1 つのプロセッサの CPU 使用率が 100 % になり、残りのプロセッサが 0 % で動作しているわけではありません。

メイン スレッドはプロセッサ A で 1/10 秒間、プロセッサ B で次の 2/10 秒間、その他のプロセッサでも同様に実行できるため、RTMT に表示される CPU 使用率はよりバランスが取れたものになります。デフォルトでは、RTMT には 30 秒間の平均 CPU 使用率が表示されます。

CodeYellow アラートは、発生時にトラブルシューティングの目的でトレース ファイルをダウンロードするように設定できます。

AverageExpectedDelay カウンタは、着信メッセージを処理する現在の平均予測遅延を表します。この値が、「Code Yellow Entry Latency」サービス パラメータで指定された値を超えると、CodeYellow アラームが生成されます。このカウンタは、コール処理のパフォーマンス問題に関する主なインジケータの 1 つです。

CodeYellow が表示されているにもかかわらず、CPU 使用率の合計がわずか 25% の場合、これは、Cisco Unified CM がコール処理に必要とするプロセッサが 1 つであるためです。使用可能なプロセッサ リソースがない場合は、4 台の仮想プロセッサ サーバで CPU 使用率の合計がわずか 25 ～ 30% の場合でも、CodeYellow が表示されることがあります。同様に、2 台のプロセッサ サーバでは、CPU 使用率の合計が約 50% の場合に CodeYellow が表示されることがあります。

モニタする必要があるその他の perfmon カウンタには次のようなものがあります。

• Cisco CallManager\CallsActive、CallsAttempted、EncryptedCallsActive、AuthenticatedCallsActive、VideoCallsActive

• Cisco CallManager\RegisteredHardwarePhones、RegisteredMGCPGateway

• Cisco CallManager\T1ChannelsActive、FXOPortsActive、MTPResourceActive、MOHMulticastResourceActive

• Cisco Locations\BandwidthAvailable

• Cisco CallManager System Performance\AverageExpectedDelay

• CodeYellow

• DBReplicationFailure

• LowCallManagerHeartbeat

• ExcessiveVoiceQualityReports

• MaliciousCallTrace

• CDRFileDeliveryFailure/CDRAgentSendFileFailed

• Critical Service Down

• CoreDumpFileFound

図 3-8 に、RTMT の [Performance] ウィンドウを示します。

図 3-8 スタンド アロン クラスタの RTMT の [Performance]

（注） 一般に、Cisco Unified CM Release 4.x の perfmon カウンタは、同じ名前を使用し、同じ値を表すように保持されてきました。

RIS Data Collector PerfMonLog

Cisco Unified CM Release 5.x では、RIS Data Collector PerfMonLog ファイルはデフォルトで有効になりません。トラブルシューティングに役立つように、RIS Data Collector PerfMonLog を有効にしておくことを推奨します。RIS Data Collector PerfMonLog は、CPU、メモリ、ディスク、ネットワークをトラッキングします。RIS Data Collector PerfMonLog を有効にすると、AMC PerfMonLog を無効にできます。Cisco Unified CM Release 6.x では、AMC PerfMonLog が RIS Data Collector PerfMonLog に置き換えられました。

（注） RIS Data Collector PerfMonLog を有効にすると、CPU に与える影響が、約 1% と小さくなります。

RTMT の [Trace & Log Central] を使用して、対象となる期間の RIS Data Collector PerfMonLog ファイルをダウンロードします。Windows Perfmon Viewer（または RTMT の Perfmon ビューア）を開き、必要なパフォーマンス カウンタを次のように追加します。

• [CPU 使用率（CPU usage）] > [プロセッサまたはプロセス % CPU（Processor or Process % CPU）]

• [メモリ使用率（Memory usage）] > [メモリ %VM 使用済み（Memory %VM Used）]

• [ディスク使用率（Disk usage）] > [パーティション % 使用済み（Partition % Used）]

• [コール処理（Call Processing）] > [Cisco CallManager CallsActive]

図 3-9 に、Windows Perfmon Viewer の出力を示します。

図 3-9 Windows Perfmon Viewer

重要なサービスのステータス

RTMT の [Critical Service] ウィンドウには、図 3-10 に示すように、すべての重要なサービスの現在のステータスが表示されます。

図 3-10 RTMT の [Critical Service] ウィンドウ

CriticalServiceDown アラートは、サービスがダウンすると生成されます。デフォルトでは、RTMT バックエンド サービスが 30 秒ごとにステータスを確認します。その間にサービスがダウンし、再開された場合は、CriticalServiceDown アラートが生成されないこともあります。

CriticalServiceDown アラートは、RTMT の [Critical Service] ページに含まれるサービスだけをモニタします。Core ファイルの生成なしにサービスが再起動されたことが疑われる場合は、RTMT の [Critical Service] ページで時間が経過していることを確認し、RIS Troubleshooting perfmon ログ ファイルをチェックし、サービス（プロセス）の PID が変更されていないかどうかを確認します。

次の CLI を使用すると、Service Manager のログをチェックできます。

• file get activelog platform/servm_startup.log

• file get activelog platform/log/servm*.log

次の CLI を使用すると、特定の RTMT 機能を複製できます。

• admin:utils service

• show perf

• show risdb

CoreDumpFileFound アラートは、RTMT バックエンド サービスが新しいコア ダンプ ファイルを検出すると生成されます。CriticalServiceDown と CoreDumpFileFound の両方のアラートは、トラブルシューティングの目的で対応するトレース ファイルをダウンロードするように設定できます。これは、クラッシュしたときにトレース ファイルを維持するために役立ちます。

syslog メッセージ

syslog メッセージは、図 3-11 に示すように RTMT の syslog ビューアで表示できます。

図 3-11 syslog ビューア

syslog トラップを CISCO-SYSLOG-MIB のリモート サーバに送信するには、次の手順に従います。

ステップ 1 Cisco Unified Serviceability SNMP ウィンドウでトラップ（通知）の宛先を設定します。

ステップ 2 CISCO-SYSLOG-MIB でトラップの生成を有効にします。

ステップ 3 CISCO-SYSLOG-MIB で適切な SysLog レベルを設定します。

一部の Cisco Unified CM サービス アラームについて syslog トラップが生成されていない場合は、RTMT の syslog ビューアをチェックし、アラームが表示されていないかどうかを確認します。表示されていない場合は、アラーム設定を調整し、ローカル syslog にアラームを送信します。

ハードウェア障害により生成される syslog のイベント重大度は 4 以上であり、次のいずれかのパターンが含まれます。

• *cma*[???]:*

• *cma*[????]:*

• *cma*[?????]:*

• *hp*[???]:*

• *hp*[????]:*

• *hp*[?????]:*

これらのパターンを検索して、syslog でハードウェア障害イベントを検出できます。

アラーム設定については、次の URL にある『Cisco Unified Serviceability Administration Guide』の「Alarm Configuration」の項を参照してください。

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/service/5_1_3/ccmsrva/saalarm.html

syslog メッセージおよびトラップとしての RTMT アラート

RTMT アラートは、リモート syslog サーバに送信できます。ローカルおよびリモート syslog サーバに送信するには、Cisco Unified Serviceability で AMC アラームを設定します。図 3-12 にウィンドウを示します。

図 3-12 ローカルおよびリモート syslog の設定

バックアップ/復元

シスコは次のバックアップ/復元ユーティリティを提供しています。

• Cisco Unified CM Release 4.x では Backup and Restore System（BARS）アプリケーションを使用します。

• Cisco Unified CM Release 5.x では Disaster Recovery Framework（DRF; 障害回復フレームワーク）を使用します。

• Cisco Unified CM Release 6.x では Disaster Recovery System（DRS; 障害復旧システム）を使用します。これは、基本的には前述の DRF から名称が変更されたものです。

これらのツールは、ローカルのテープ ドライブや、ネットワーク上のファイルへのバックアップ ファイルの書き込み（またはそこからの復元ファイルの読み取り）をサポートしています。BARS は Windows の共有を、DRF および DRS は SFTP を使用してネットワーク ロケーションにアクセスします。サードパーティのバックアップ ソリューションを使用する場合は、サードパーティのバックアップ ソリューションがピックアップできるように、BARS、DRF、およびDRS はネットワーク ロケーションに書き込むことができます。

DRF および DRS はクラスタ全体のバックアップを実行します。つまり、すべてのノードのデータがバックアップされます。ただし、復元は必要なノードだけに対して行われます。

バックアップの対象として設定するものや、作成するファイルなどの詳細については、リリースに応じて次のマニュアルを参照してください。

• 『Disaster Recovery Administration Guide』

• 『Cisco IP Telephony Disaster Recovery Administration Guide』

• 『Cisco IP Telephony Backup and Restore System (BARS) Administration Guide』

アプライアンスでインストール、アップグレード、またはオプションのインストールを実行した場合は、設定データが変更されているかどうかにかかわらず、新たにバックアップすることを推奨します。

致命的なハードウェア障害が発生し、ハードウェアを交換する必要がある場合は、新しいハードウェアに Cisco Unified CM を再インストールし、バックアップから復元してください。

（注） アプライアンスの迅速な復元ソリューションとしてドライブのプルおよびスワップはサポートされていません。

使用しているリリースに対応する『Cisco Unified Communications Manager Install and Upgrade Guide』の「 Replacing a Single Server or Cluster for Cisco Unified Communications Manager 」の章を参照してください。次の URL からアクセスできます。

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_installation_guides_list.html

SNMP MIB の使用

Cisco Unified CM ハードウェア サーバは SNMP MIB を使用してモニタします。次の MIB がサポートされています。

• Vendor-Specific MIB（「ベンダー固有の管理情報ベース」）

– IBM-SYSTEM-LMSENSOR

– IBM-SYSTEM-POWER

– IBM-SYSTEM-RAID

– IBM-SYSTEM-xxx-MIB

– CPQ-xxx-MIB（HP）

– CPQHEALTH（HP）

– INTEL-SERVER-BASEBOARD6（Cisco Unified CM Release 7.1[2] で導入）

MIB にリストされた SNMP トラップ、通知、およびインフォームを受け取るように、ネットワーク管理アプリケーションで SNMP を設定します。特定の MIB がサポートされるかどうかは、Cisco Unified CM のリリースとハードウェア ベンダーによって異なります。

MIB と MCS のタイプ

MCS のタイプを直接指定する特定の Object IDentifier（OID; オブジェクト ID）はありません。Linux アプライアンスの場合は、sysObjectID の値をサーバ タイプにマッピングできます。たとえば、HP-7825 サーバでは、sysobjectID は 1.3.6.1.4.1.9.1.583 を返します。

Windows の場合は、OID がサーバを Windows サーバとして識別することを除いて、サーバ タイプについてそのような特定の値が返されることはありません。さまざまなハードウェアに割り当てられた sysObjectID のリストについては、 http://www.oidview.com/mibs/9/CISCO-PRODUCTS-MIB.html を参照してください。

Cisco Unified CM リリースによってサポートされている Media Convergence Server（MCS）の MIB については、 http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/compat/cmmibcmp.xls を参照してください。

コマンドライン インターフェイスの使用

システム BIOS は、サーバのブート中に表示されます。次のコマンドは、ハードウェア、BIOS、RAID、およびファームウェアの詳細を表示する場合に有効です。これらの項目は Cisco Unified CM イメージの一部として含まれており、Cisco Unified CM Release 4.x と同様に個別に管理する必要はありませんが、診断アクティビティで確認が必要な場合があります。

admin:utils fior status CLI を使用し、高 IOwait を発生させているプロセスを特定することもできます。admin:utils fior コマンドに使用可能なその他のオプションには、enable、disable、start、stop、list、top があります。たとえば、コマンド プロンプトに admin:utils fior list と入力します。次のように表示されます。

admin:utils for top CLI for output sorted by top disk users を使用します。次のように表示されます。

その他にも次のコマンドを使用できます。

• admin:utils diagnose list

• admin:utils diagnose test

• admin:utils diagnose module <moduleName>

• admin:utilsdiagnose fix

• admin:utils create report hardware

• admin:utils iostat

admin:utils diagnose list CLI

次のように、使用可能なすべての診断テストが表示されます。

admin:utils diagnose test CLI

各診断テストを実行します。このテストでは修復は試みません。次のように表示されます。

admin:utils diagnose module <moduleName> CLI

1 つの診断テストを実行し、問題の解決を試みます。admin:utils diagnose fix CLI を使用して、すべての診断テストを一度に実行することもできます。たとえば、admin:utils diagnose module tomcat と入力すると、次のように表示されます。

admin:utils diagnose fix CLI

すべての診断テストを実行し、可能であれば、システムの修復を試みます。次のように表示されます。

admin:utils create report hardware CLI

ディスク アレイ、リモート コンソール、診断、および環境データが含まれるシステム レポートを作成します。パラメータは必要ありません。次のように表示されます。

admin:utils iostat CLI

特定の回数の繰り返しと間隔について iostat 出力が提供されます。2 回の iostat の読み取りの間隔（秒）と、実行する iostat の繰り返しの回数が表示されます。次のように表示されます。

次の CLI を使用して、クラスタ内接続をモニタし、管理できます。

• admin:utils dbreplication status

• admin:utils dbreplication repair all/nodename

• admin:utils dbreplication reset all/nodename

• admin:utils dbreplication stop

• admin:utils dbreplication dropadmindb

• admin:utils dbreplication setrepltimeout

• show tech dbstateinfo

• show tech dbinuse

• show tech notify

• run sql <query>

ハードウェアの移行

古いハードウェアをサポートしない新しい Cisco Unified CM リリースにアップグレードするための準備として、またはキャパシティとパフォーマンスの向上や RAID など、より強力なハードウェアだけで利用可能な機能を単に活用するために、使用中の Cisco Unified CM をより強力なハードウェアに移行することをお客様が希望する場合があります。このためには、古いハードウェアからバックアップし、新しいハードウェアに同じ Cisco Unified CM リリースをインストールし、次に新しいハードウェアで復元するという手順になります。

より強力なハードウェアに移行する場合は、サードパーティに対するシスコのロイヤリティをカバーするために SKU の移行が必要になる場合があります。移行を検討中の場合は、アカウント チームが『Cisco Unified CM Ordering Guide』に付属の『Guide to Cisco Unified CM Upgrades and Server Migrations』を確認する必要があります。

プラットフォームのセキュリティ

この項では次の内容について説明しています

• 「ロックダウンされたシステム」

• 「Cisco Security Agent のサポート」

• 「セキュリティ パッチおよび更新」

• 「Role-Based アクセス コントロール」

ロックダウンされたシステム

セキュリティのために、組み込みのファイアウォールともに Cisco Security Agent が含まれており、すべてのクラスタ ノードの接続を、アプリケーションにより定義された IP テーブルとセンシティブ ポートを通じて制御しています。アプライアンスには AntiVirus アプリケーションはインストールされていません。アプライアンスにより使用されているネイティブ OS も、攻撃対象領域や脆弱性を最小限に抑えるように強化されています。未使用のソフトウェアとそれに伴う脆弱性を排除するために、数千もの使用可能なパッケージのうち、使用しているものは 200 未満です。

「オンボックス」式の電子メール クライアントや Web ブラウザはサポートされていません。不要なすべてのログインは削除されているか、無効にされています。また、すべてのソフトウェアはシスコが提供しており、シスコの承認を確認するためのデジタル署名がされています。シスコが提供する GUI、CLI、および API インターフェイスが、システムを管理するための唯一の手段であり、これらのインターフェイスとやり取りするためには認証が必要です。この種のアプライアンスが、Microsoft Windows や、ネイティブ OS に対するオープンシステム アクセスが可能なその他のシステムよりもマルウェアの対象となりにくい点にも注意してください。このため、基本 OS に適用する必要があるパッチの数が大幅に少なくなっています。

Cisco Unified CM は、その TCP/UDP ポートの使用を規制しています。詳細なリストについては、各 Cisco Unified CM リリースのマニュアル、『Cisco Unified Communications Manager TCP and UDP Port Usage』を参照してください。

Cisco Security Agent のサポート

アプライアンスは「ヘッドレス」またはマネージドではない Cisco Security Agent をサポートしています。将来のリリースで Cisco Security Agent Management Center のイベント モニタリング機能のサポートを追加する予定ですが、ポリシーの編集や配布はサポートしません。

セキュリティ パッチおよび更新

アプライアンスのソフトウェア イメージには、ファームウェア、ドライバ、ネイティブ OS、データベース、および Cisco Unified CM アプリケーション コンポーネントに対して適用されたすべてのセキュリティ アップデートとパッチが含まれます。シスコ メンテナンス リリースを最新の状態に維持しているお客様の場合、セキュリティ アップデートは自動的に提供されています。詳細については、シスコのアカウント チームから入手可能なアプリケーション ノート『Appliance Security Update Process for Cisco Unified Communications Manager』（C27-412838-00）を参照してください。

Role-Based アクセス コントロール

Cisco Unified CM では、Cisco Unified CM 設定の認証に関するロールベース アクセス コントロールに Multi-Layer Admin（MLA; マルチレイヤ管理）を使用しています。

一般的なインストール/アップグレード手順

初めての無人インストールは、Cisco Unified Communications Answer File Generator（ http://www.cisco.com/web/cuc_afg/index.html で入手可能）を使用して実行できます。詳細については、オンライン ヘルプとマニュアル『Installing Cisco Unified Communications Manager』を参照してください。

アップグレードについては、次の Web サイトのリストからアップグレードの適切なリリースを検索してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_installation_guides_list.html

インストールされているリリースとパッケージの検出

インストールされているリリースとパッケージを表示するには、次のような方法があります。

• show version [ active | inactive ] および show packages active の各コマンド

• Cisco Unified Operations Manager

• Unified OS の管理

• Cisco Unified Communications Manager

• SNMP

サードパーティの NMS では、次の SNMP OID を使用して Cisco Unified CM のリリースを照会できます。

• .iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoCcmMIB.ciscoCcmMIBObjects.ccmGeneralInfo.ccm Table.ccmEntry.ccmVersion

Cisco Unified CM のライセンス Web ページには、アップロードされたライセンス ファイルのリリースが表示されます。これは、システムにインストールされているものと厳密には一致しないことがあります。

RTMT レポート

RTMT には、要約、コール アクティビティ、デバイス ステータス、サーバ ステータス、サービス ステータス、アラート ステータスなどの情報を表示する設定済み画面が多数あります。RTMT の [Summary] 設定済み画面には、Cisco Unified CM システムの健全性の要約ビューが表示されます。この画面には、CPU、メモリ、登録済みの電話機、CallsInProgress、ActiveGateway ポートおよびチャネルが表示されます。この画面は、CPU やメモリの使用率がクラスタの正常な範囲内に入っていること、またすべての電話が正しく登録されていることを確認するために、毎日チェックする必要がある最初の場所です。

電話の要約（Phone Summary）およびデバイスの要約（Device Summary）の各設定済み画面には、電話やゲートウェイ ステータスのより詳しい情報が表示されます。登録に失敗したデバイスがいくつかある場合は、[Admin Find/List] ページまたは RTMT デバイス検索を使用して、問題のデバイスに関する詳細を取得できます。[Critical Services] 設定済み画面には、主要なサービスの現在の実行およびアクティベーション ステータスが表示されます。左側の対応するアイコンをクリックすることで、これらのすべての設定済み画面にアクセスできます。

Serviceability レポート

Cisco Serviceability Reporter サービスは、Cisco Unified CallManager Serviceability Web ページで日報を生成します。各レポートには、特定のレポートの統計を示すさまざまなチャートを構成する要約が表示されます。Reporter は、ロギングされた情報に基づいて 1 日に 1 回、次のようなレポートを生成します。

• デバイス統計レポート

• サーバ統計レポート

• サービス統計レポート

• コール アクティビティ レポート

• アラート要約レポート

• パフォーマンス保護レポート

各レポートの詳細については、次の Web サイトを参照してください。 http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/service/5_0_2/ccmsrvs/sssrvrep.html#wp1033420

Cisco Unified Reporting

Cisco Unified Reporting には Cisco Unified CM の管理コンソールからアクセスし、クラスタ データのトラブルシューティングまたは確認のためのレポートを生成します。このレポートにクラスタ データが表示されます。データを検索するために複数の手順を実行する必要はありません。このツール設計により、既存のソースからのデータの収集、データの比較、変則的なデータの報告が容易になります。図 3-13 に、使用可能なレポートを示します。詳細については、『Cisco Unified CM Administration Guide』を参照してください。

図 3-13 システム レポート

オンボード エージェントの使用

オンボード エージェントは、次のようなオンボックスのサードパーティ ソフトウェア クライアント、エージェント、またはデーモンです。

• アンチウイルス クライアント

• 無停電電源装置モニタリング エージェント

• 管理エージェント

Cisco Unified CM Release 4.x では、特定のタイプのオンボード エージェントがサポートされています。Cisco Unified CM Release 5.0 以降のリリースで使用されているアプライアンスはオンボード エージェントのインストールはサポートしておらず、サードパーティの統合用に API を提供しています。

詳細については、次の URL にある、サードパーティ プラットフォーム エージェントに関する 2007 年 11 月の製品情報を参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_bulletins_list.html

コール詳細レコードとコール メンテナンス レコード

CDR および CMR は、課金、チャージバック、管理のための監視および診断など、さまざまな用途に使用されます。CDR および CMR を管理するための付属アプリケーションに加えて、Cisco Unified CM Release 4.x では、外部システムが CDR および CMR データにアクセスするための、さまざまな方法による直接のデータベース アクセスをサポートしていました。Cisco Unified CM Release 5.0 以降のリリースでは、SFTP を使用して、フォーマット済みファイルを Cisco Unified CM から要求元のアプリケーションにプッシュしています。

CDR をアクティブにしている場合は、CPU 使用率の 2% の増加が、CDR および CMR の両方をアクティブにしている場合は 4% の増加が一般的です。

perfmon カウンタ

表 3-5 に、Cisco Unified CM Release 4.x と Release 5.x 以降の対応する perfom カウンタをいくつか示します。

無停電電源装置（UPS）との統合

Cisco Unified CM Release 6.0(1a) 以降では、サーバは特定の MCS 7800 モデルについて、APC の Uninterruptible Power Supplies（UPS; 無停電電源装置）の特定のモデルとの統合をサポートしています。以前のサーバ リリースでは、外部スクリプトを使用して UPS をモニタし、グレースフル シャットダウンのために Cisco CLI を発行しています。詳細については、次の Web サイトで入手可能な Cisco Unified CM 6.0(1b) のリリース ノートを参照してください。 http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/rel_notes/6_0_1/cucm-rel_note-601b.html

（注） HP iLO または IBM RSA II などのネイティブ ハードウェアのアウトオブバンド管理は、Cisco Unified CM のグレースフル シャットダウンには使用できません。

ネイティブ ハードウェア アウトオブバンド管理（OOB）

HP iLO および IBM RSA II のサポートされる機能は、次の領域で有効になります。

• CPU ステータスと CPU 使用率

• メモリ ステータスとメモリ使用率

• システム コンポーネント温度

• ファン ステータス

• 電源ステータス

• RAID およびディスク ステータス

• Network Interface Card（NIC; ネットワーク インターフェイス カード）を含むネットワーク ステータス

• オペレーショナル ステータス（動作の問題の性質およびタイプ、重大度のレベルを示す、重大なシステム問題発生後のシステムおよびカーネル ステータス、データ ダンプの確認を含む）

サーバでのこれらのインターフェイスのサポートには次の機能が含まれます（明確な機能の名称はハードウェア ベンダーによって異なる）。

• リモート コンソール（ブート画面と Cisco CLI にアクセスする）

• リモート電源管理

電話登録ステータス

突然の変化を認識できるように、電源登録ステータスをモニタする必要があります。登録ステータスがわずかに変化し、短時間にすばやく再調整された場合は、電話機の移動、追加、または変更を示すことがあります。電話登録カウンタの急な小さい低下は、アクセス スイッチや WAN 回線の停止や誤作動など、限られた範囲内での停止を示すことがあります。登録済み電話のレベルが大きく低下した場合は、管理者がただちに注意しなければなりません。このカウンタは、システムがすべて復元されたことを確認するために、特にアップグレードの前後にモニタする必要があります。

履歴情報のダウンロード

RTMT の [Trace & Log Central] または SOAP API を使用して、次のような履歴情報をダウンロードすることもできます。

• Cisco AMC Service PerfMonLog はデフォルトで有効になりますが、Cisco Unified CM Release 6.0 では、Cisco RIS Data Collector PerfMonLog が導入されたため非推奨になりました。

• Cisco RIS Data Collector PerfMonLog は、Cisco Unified CM Release 5.x ではデフォルトで無効になり、Cisco Unified CM Release 6.0 ではデフォルトで有効になります。

応答しない Cisco CallManager サービス

Cisco CallManager サービスが応答しなくなった場合は、次のメッセージがシステム イベント ログに表示されます。

この場合では、その他にも次のメッセージが表示されることがあります。

Cisco Communications Manager が、次のエラーにより起動しませんでした。

このとき、Cisco Unified IP Phone やゲートウェイなどのデバイスが Cisco Unified Communications Manager から登録解除されると、ユーザはダイヤル トーンの遅延を受信し、高い CPU 使用率のために Cisco Unified Communications Manager サーバがフリーズします。または、そのいずれかの状況が発生します。ここに含まれないイベント ログ メッセージについては、Cisco Unified Communications Manager のイベント ログを参照してください。

考えられる原因

サービスが機能するために十分なリソース（CPU やメモリなど）がない場合には、Cisco CallManager サービスは応答を停止できます。一般に、その時点でサーバの CPU 使用率は 100% になります。

推奨処置

発生している中断のタイプに応じて、その中断の根本原因の確認に役立つさまざまなデータを収集する必要があります。

リソースの不足による中断が発生した場合は、次の手順を使用します。

手順

ステップ 1 中断の前後 15 分間の Cisco CallManager トレースを収集します。

ステップ 2 中断の前後 15 分間の Specification and Description Language（SDL）トレースを収集します。

ステップ 3 ある場合は、perfmon トレースを収集します。

ステップ 4 トレースがない場合は、perfmon トレースの収集を開始し、サーバ上で実行されている各プロセスのメモリと CPU の使用率をトラッキングします。これらは、リソースの不足による中断が再度発生した場合に役立ちます。

パブリッシャとサブスクライバの間でデータベースの複製が失敗する

データベースの複製は、Cisco Unified Communications Manager クラスタのコア機能です。データベースのマスター コピーを備えたサーバはパブリッシャ（最初のノード）として機能し、データベースを複製するサーバはサブスクライバ（以降のノード）を構成します。

ヒント サブスクライバ サーバに Cisco Unified Communications Manager をインストールする前に、パブリッシャ データベース サーバ上のデータベースをサブスクライバが確実に複製できるように、Cisco Unified CM の管理の [サーバの設定（Server Configuration）] ウィンドウにサブスクライバを追加する必要があります。サブスクライバ サーバを [サーバの設定（Server Configuration）] ウィンドウに追加し、Cisco Unified Communications Manager をサブスクライバにインストールしたら、サブスクライバはパブリッシャ サーバ上のデータベースのコピーを受け取ります。

パブリッシャ サーバに対する変更が、サブスクライバ サーバに登録されている電話に反映されません。

考えられる原因

パブリッシャ サーバとサブスクライバ サーバの間の複製に失敗する。

推奨処置

データベースの複製を確認し、必要に応じて、次の手順に従って修正します。

手順

ステップ 1 データベースの複製を確認します。データベースの複製は、CLI、Cisco Unified Reporting、または RTMT を使用して確認できます。

• CLI を使用して確認するには、ステップ 2 を参照してください。

• Cisco Unified Reporting を使用して確認するには、ステップ 3 を参照してください。

• RTMT を使用して確認するには、ステップ 4 を参照してください。

ステップ 2 CLI を使用してデータベースの複製を確認するには、CLI にアクセスし、次のコマンドを発行して各ノードでの複製を確認します。各ノードでこの CLI コマンドを実行し、その複製のステータスを確認する必要があります。また、サブスクライバをインストールした後、サブスクライバの数によっては、2 のステータスに達するまでに長い時間がかかることがあります。

この場合に Replicate_State オブジェクトが 2 の値を示すことに注意してください。次に、Replicate_State がとることのできる値を示します。

• 0：この値は、複製が開始されていないことを示します。後続のノード（サブスクライバ）がありません。または、Cisco Database Layer Monitor サービスが、サブスクライバのインストール後から実行されていません。

• 1：この値は、複製が作成されているにもかかわらず、カウントが間違っていることを示します。

• 2：この値は、複製の状態が良好であることを示します。

• 3：この値は、クラスタで複製に問題があることを示します。

• 4：この値は、複製の設定に失敗したことを示します。

ステップ 3 Cisco Unified Reporting を使用してデータベースの複製を確認するには、次のタスクを実行します。

a. Cisco Unified CM の管理の右上に表示される [ナビゲーション（Navigation）] ドロップダウン リスト ボックスから Cisco Unified Reporting を選択します。

b. Cisco Unified Reporting が表示されたら、[システム レポート（System Reports）] をクリックします。

c. データベースの複製に関するデバッグ情報を提供する [Cisco Unified CM Database Status] レポートを生成し、表示します。

このレポートを生成したら、レポートを開き、[Cisco Unified CM Database Status] を確認します。ここには、クラスタ内の全サーバの RTMT レプリケーション カウンタが含まれます。すべてのサーバの複製状態は 2 になっていなければならず、すべてのサーバで同じ数の複製が作成されている必要があります。

前述のステータスの確認で複製の状態が 2 になっていない場合は、このレポートの「Replication Server List」を参照してください。ここには、接続され、各ノードとやり取りしているサーバが表示されます。各サーバは（それ自体のリストで）「local」（ローカル）と示され、他のサーバは「active connected」（アクティブに接続）と示されるはずです。「dropped」（切断）と表示されるサーバがある場合は、通常は、ノード間に通信の問題が発生していることを示します。

d. 必要に応じて [Cisco Unified CM Database Status] レポートを生成し、表示します。このレポートには、Cisco Unified Communications Manager データベースの健全性のスナップショットが表示されます。

ステップ 4 RTMT を使用してデータベースの複製を確認するには、次のタスクを実行します。

a. Cisco Unified Real-Time Monitoring Tool（RTMT）を開きます。

b. [CallManager] タブをクリックします。

c. [Database Summary] をクリックします。[Replication Status] ペインが表示されます。

[Replication Status] ペインに表示される値を次に示します。

• 0：この値は、複製が開始されていないことを示します。後続のノード（サブスクライバ）がありません。または、Cisco Database Layer Monitor サービスが、サブスクライバのインストール後から実行されていません。

• 1：この値は、複製が作成されているにもかかわらず、カウントが間違っていることを示します。

• 2：この値は、複製の状態が良好であることを示します。

• 3：この値は、クラスタで複製に問題があることを示します。

• 4：この値は、複製の設定に失敗したことを示します。

d. Replicate_State パフォーマンス モニタリング カウンタを表示するには、[System] > [Performance] > [Open Performance Monitoring] を選択します。パブリッシャ データベース サーバ（最初のノード）をダブルクリックし、パフォーマンス モニタを拡張します。[Number of Replicates Created and State of Replication] をクリックします。[Replicate_State] をダブルクリックします。[Object Instances] ウィンドウの [ReplicateCount] をクリックし、[Add] をクリックします。

ヒント カウンタの定義を表示するには、カウンタ名を右クリックし、[Counter Description] を選択します。

ステップ 5 すべてのサーバで RTMT のステータスが良好であるにもかかわらず、データベースが同期していないことが疑われる場合は、CLI コマンド utils dbreplication status を実行します（いずれかのサーバで RTMT のステータスが 4 と表示される場合は、ステップ 6 に進みます）。

このステータス コマンドは、 utils dbreplication status all を使用してすべてのサーバで、または utils dbreplication status <hostname> を使用して 1 つのサブスクライバで実行できます。

ステータス レポートは、疑わしいテーブルがあるかどうかを示します。疑わしいテーブルがある場合は、複製修正 CLI コマンドを使用し、パブリッシャ サーバからサブスクライバ サーバにデータを同期します。

複製の修正は、utils dbreplication repair usage:utils dbreplication repair [nodename]|all コマンドを使用して、すべてのサブスクライバ サーバで実行することも（ all パラメータを使用）、1 つのサブスクライバ サーバだけで実行することもできます。

複製の修正を実行した後（数分間かかることがある）、別のステータス コマンドを実行して、すべてのテーブルが同期されたことを確認できます。修正後にテーブルが同期されていれば、複製の修正は成功です。

（注） サーバの 1 つで RTMT のステータスが 4 の場合、またはステータス 0 の状態が 4 時間を超えた場合に限り、ステップ 6 を実行します。

ステップ 6 [Cisco Unified CM Database Status] レポートを生成し、表示します。このレポートには、データベースの複製に関するデバッグ情報が出力されます。RTMT のステータスが不良と表示される各サブスクライバで、hosts、rhosts、sqlhosts、およびサービス ファイルに適切な情報が含まれることを確認します。

[Cisco Unified CM Cluster Overview] レポートを生成し、表示します。サブスクライバ サーバのバージョンが同一であること、接続が正常であること、時間遅延が許容値内であることを確認します。

前述の条件が許容できるものである場合、次の手順を実行して、そのサブスクライバ サーバ上でレプリケーションをリセットします。

a. サブスクライバ サーバで、CLI コマンド utils dbreplication stop
を実行します。これを、RTMT の値が 4 のすべてのサブスクライバ サーバで実行します。

b. パブリッシャ サーバで、CLI コマンド utils dbreplication stop を実行します。

c. パブリッシャ サーバで、CLI コマンド utils dbreplication reset <hostname> を実行します。ここで、 <hostname> は、リセットする必要があるサブスクライバ サーバのホスト名です。すべてのサブスクライバ サーバをリセットする必要がある場合は、コマンド utils dbreplication reset all を使用します。

失われたノードでデータベースの複製が実行されない

失われたノードの回復時に接続が復元されても、データベースの複製が行われません。トピック「パブリッシャとサブスクライバの間でデータベースの複製が失敗する」で説明する方法を使用して、複製の状態を確認できます。ノードですでに複製のリセットを試み、その操作に失敗している場合に限り、次の手順を使用します。

考えられる原因

デバイス テーブルでの削除により、CDR チェックがループに入っている。

推奨処置

ステップ 1 影響を受けているサブスクライバで utils dbreplication stop を実行します。これはすべて同時に実行できます。

ステップ 2 ステップ 1 が完了するまで待ち、次に、影響を受けているパブリッシャ サーバで utils dbreplication stop を実行します。

影響を受けているパブリッシャ サーバから utils dbreplication clusterreset を実行します。このコマンドを実行すると、ログ名がログ ファイルにリストされます。このファイルを確認し、プロセスのステータスをモニタします。パスは次のとおりです。
/var/log/active/cm/trace/dbl/sdi

ステップ 3 影響を受けているパブリッシャから utils dbreplication reset all を実行します。

ステップ 4 クラスタ内のすべてのサブスクライバ サーバですべてのサービスを停止し、再起動して（または、すべてのシステム（サブスクライバ サーバ）を再起動/リブートして）、サービスを変更します。この操作は必ず、 utils dbreplication status で 2 のステータスが表示されてから実行します。

データベース テーブルで同期が外れてもアラートがトリガーされない

同期外れとは、クラスタ内の 2 つのサーバの特定のデータベース テーブルに同じ情報が含まれていないという意味です。

Cisco Unified Communications Manager バージョン 6.x 以降では、この症状には予期しないコール処理の動作が含まれます。コールのルーティングと処理が予想どおりに実行されません。この症状は、パブリッシャ サーバとサブスクライバ サーバのいずれかで発生することがあります。

Cisco Unified Communications Manager バージョン 5.x では、この症状には予期しないコール処理の動作が含まれます。コールのルーティングと処理は予想どおりに実行されませんが、これは、パブリッシャ サーバがオフラインになっているときに限ります。これらの症状が見られる場合は、 utils dbreplication status コマンドを実行します。「Out of sync」と表示されます。「Out of sync」と表示されない場合は、問題はありません。

考えられる原因

ノード間でデータベース テーブルの同期が外れたままになっています。複製アラートは、複製プロセスの障害だけを示し、データベース テーブルの同期が外れた時期は示しません。通常、複製が正しく行われている場合は、テーブルの同期は維持されているはずです。場合によっては、複製が正しく行われているように見えるにもかかわらず、データベース テーブルが「同期外れ」になる状況が発生することがあります。

推奨処置

ステップ 1 CLI コマンドを使用してクラスタの複製をリセットします。この処置を実行するためには、クラスタ内のサーバがオンラインで、IP 接続が完全に確立されていることが必要です。プラットフォーム CLI と Cisco Unified Reporting を使用して、クラスタのすべてのサーバがオンラインになっていることを確認します。

ステップ 2 サーバの複製の状態が 2 の場合は、パブリッシャ サーバで utils dbreplication repair server name コマンドを使用します。

サーバの複製の状態が 2 でない場合は、すべてのサブスクライバ サーバで utils dbreplication stop コマンドを使用します。

次に、パブリッシャ サーバで utils dbreplication stop コマンドを、その後に utils dbreplication reset all コマンドを使用します。

以前のリリースに戻す場合のデータベース レプリケーションのリセット

古い製品リリースを実行できるようにクラスタ内のサーバを元に戻す場合は、クラスタ内部でデータベースの複製を手動でリセットする必要があります。すべてのクラスタ サーバを古い製品リリースに戻した後にデータベースの複製をリセットするには、すべてのパブリッシャ サーバで utils dbreplication reset コマンドを使用します。

Cisco Unified Communications Operating System Administration または CLI を使用してバージョンを切り替えると、古い製品バージョンに戻すときに、データベース複製のリセット要件に関するメッセージが表示されます。

有効なコマンドとユーティリティ

この項では、ルート アクセスが無効にされた Cisco Unified Communications Manager サーバのトラブルシューティングに役立つコマンドやユーティリティのクイック リファレンスを提供します。

表 3-6 に、システムのさまざまな問題をトラブルシューティングするための情報収集に使用できる CLI コマンドと GUI をまとめます。