CUCMサーバでの障害が発生した場合、サーバをリブートする前にお試しいただきたい
手順（初期対応方法）について説明させていただきます。ここで主に想定されている
障害としてはサービスが全断しておりハードウェア障害が疑われるような状況とします。
（弊社社内ITでの運用手順に近いイメージとなります。もし、より良い手順のご提案等が
ありましたら、是非コメントをお寄せください）
０．準備
障害発生時に備え、通常運用では以下の準備を行っておきます。
定期的なバックアップ -- スケジュールドバックアップをご活用いただき、最低でも
週一回程度のバックアップを取るようにしておきます。
設定情報・変更履歴の管理 -- CUCM設定内容についてドキュメント化を行います
特にGW/電話機数、各サーバで起動しているサービス、外線番号についての記録。
ベースライン管理 -- RTMTを利用して、平常時のCPU、メモリ、HDD使用量
を記録。さらに、RegisterされているGW数、電話機台数を把握しておく。
アラーム発報設定 -- RTMTでCritical serviceダウンなどについてはメールによる
アラーム発報などを設定することもできます。
メンテナンス時パッチの適応 -- サーバの定期メンテナンス計画を立て、計画
ダウン時には最新のサービスパック、ESパッチ、FWUCDによるファームウェア
アップデートなどを行うように事前に計画しておく。
トレースレベルの設定 -- Cisco Callmanagerサービスについてはトレースの取得
レベルをDetailedにしておくことで、障害発生時の解析をスムーズにする。
緊急時連絡先の貼付 -- 緊急時にすぐ連絡できるよう、わかりやすい位置に
管理者名、モデル型番、シリアル番号、サポート契約番号、TAC連絡先等の
必要情報をまとめておく
リカバリ用Discの準備 -- CUCMの障害発生時に利用する該当バージョンに
応じたリカバリディスクの準備。リカバリディスクについてはサポートコミュニティ内
別ドキュメントをご参照ください。
https://supportforums.cisco.com/docs/DOC-12782
１．障害発生、状況把握
障害が発生したとの一報があった場合、まず障害状況について正確に把握する。
・利用できなくなっている機能は何か、電話全断なのか、一部のサービスだけなのか
・内線どおしの通話はできるのか、外線への発信は可能か、着信は可能か
・影響が出ている電話機は特定の部署のものか、それとも全てか
・電話機LCD画面の表示はどのようになっているのか、CMサービスダウンかDHCPを
再取得しようとしているのか
・障害はいつごろから発生しているのか、発生した時刻は
・障害発生の前に何か関連するアクションがあったのか、突然発生したのか
・誰が最初に障害を発見したのか
・どの番号の電話機に問題が発生しているのか、電話機のモデル・MACアドレスは何か
・障害は間欠的に発生しているのか、それとも常に発生しているのか
２．サーバステータス確認
サーバのステータスを各種管理ツールから確認します。
・RTMTでの接続を行い、接続できればAlert 画面から、どのような障害が発生しているかを確認
同時にCPU,メモリ、HDDのパフォーマンス等も確認。取得できるようであれば、以下のログを取得
- Eventlog-System
- Cisco CallManager
- Cisco AMC Service
- Cisco AMC Service DeviceLog
- Cisco RIS Data Collector PerfMonLog
- その他障害に応じて必要なログ
・Cisco Unified CM Administration、Cisco Unified Serviceability 画面へ
アクセスできるかを確認
・クラスタ内に複数ノード（サーバ）がある場合、Cisco Unified Reporting画面から
DBのレプリケーションが動作しているかを確認します。
・SSHで管理者用のCLIへログインできるかを確認します。ログインできた場合
以下のコマンドを発行して情報を取得します。
- show hardware
- show status
- show tech all
- utils service list
- utils create report hardware
・サーバへのPingができるかどうかを確認
サーバのステータスを目視にて確認
・サーバLED、HDD LED等で異常を示す警告が出ていないかを確認
・サーバコンソールにエラーメッセージが表示されていないかを確認。エラーメッセージが
表示されている場合は、それをできるだけ正確に記録する。
携帯のカメラ・デジカメ等で写真を撮ることもおすすめです。
３．サーバ復旧作業開始
サービスが全断しているような状況の場合、以下の手順でインパクトの少ない順に
復旧を試します。
A.Cisco Unified Serviceability 画面へアクセスできる場合
Tools ＞ Cotrol Centerからサービスの状況を把握します。本来動作しているべき
サービスが停止している場合は、再起動・リスタートを試します。
サービス全断のような場合は、基本的に以下の手順で
Control Center - Network Services Cisco Database Layer Monitor
（データベースの変更動作を監視しているDBモニターの再起動）
Control Center - Feature Services Cisco CallManager
（呼処理の中核となるコールマネージャーサービスの再起動）
それぞれ、サービスを選択してリスタートボタンをクリック
他にも動作しているべきだが停止しているサービスがあれば、再起動を試します。
サービスを再起動できれば、電話システムの動作が復旧したかを確認してください。
B.Cisco Unified Serviceabilityへのアクセスができない、または
Serviceabilityの画面からではサービスの再起動ができない場合
SSH接続によるCLIからのコマンド発行により状況把握、サービス復旧をはかります。
ログイン後、 utils service list コマンドで現在動作しているサービスを把握します。
各サービス毎に[STARTED]が動作中、[STOPPED]が停止中となります。ただし、
[STOPPED] Service not Activated の表示はもともとサービスを管理者側で有効に
設定していないものですから、問題ありません。
[STARTING...] 起動中、[STOPPING]停止中のようなサービスに注目します。
本当にサービス起動もしくは停止の途中である可能性もありますが、起動・停止中に
サービスがハングしてしまっているというような場合もあります。
次の手順でサービスの再起動を行ってみてください。
utils service restart Cisco Tomcat
(Webサーバ・サーブレットエンジンTomcatの再起動）
このサービスが再起動できれば、Webサーバ機能が復旧する場合がありますので
A.の手順に戻ってサービスの再起動を試します。
utils service restart Cisco Database Layer Monitor
（データベースの変更動作を監視しているDBモニターの再起動）
ここまでの手順でもサービスが再開しない場合、CUCM内のサービス全てをリスタート
する以下コマンドを発行してみます。
utils service restart Service Manager
全てのサービスをリスタートしますので１０分程度の時間がかかる場合があります。
プロンプト admin: が戻ってくればリスタート完了です。
utils service list コマンドで再びサービス起動状況を確認してください。
上記のサービス再起動（リスタート）でも電話サービスが復旧しない場合、コマンドから
サーバリスタートを試みます。
utils system restart 発行後、 yes エンター でリスタート実行
サーバ再起動後、電話サービスが復旧したかを確認してください。
C.SSH経由のCLIへのアクセスができない場合
SSH経由のCLIアクセスができない場合は、物理的にサーバコンソールにアクセスする
必要があります。サーバコンソールからCLIにアクセスできる場合は
utils service restart System SSH
でまずはSSHサービスを再起動できないかを確認してください。
このリスタートでSSH経由でアクセスできるようになった場合は、B.の手順に戻って
サービスの再起動を試します。ダメなようであれば、そのままサーバのコンソールから
B.の手順と同様にサービスの再起動を試します。
D.コンソールのCLIにもアクセスできない場合
残念ながら、サーバへのアクセスがA.B.C.の手順すべてうまくいかない場合、
強制的にサーバをリスタートする必要があります。ただし、サーバの強制リスタートは
OSのファイルシステムを破壊してしまう可能性もありますので、以下の手順で行ってください。
・項目１にあるように目視による状況把握・コンソールに表示されているエラーの記録
・もし、HDDのオレンジLED点灯等によりハードウェア障害が確認できる場合は
障害品交換の手配
・CUCMリカバリディスクの準備
・サーバのリセットボタンによる強制リスタート
・リスタート後、DVDドライブにリカバリディスクをセット
・リカバリディスクが立ち上がれば、ファイルシステムチェックの実行（FSCK)
・FSCK終了後、ディスクを抜きサーバをリスタート
・HP製サーバであればHP Smart Start、IBM製であればDSAによるログ収集、
ダイアグノスティックテストを行う
・最新のFWUCDの適応を行う
・サーバリスタート
４．サーバ起動後、電話サービスが再開していることを確認
・utils service listでサービス状態を確認
・Cisco Unified Serviceablityからサービス状態を確認
・RTMTからRegisterされたGW/電話機台数を確認
・内線どおしの基本コールを確認
・外線への発信・着信を確認（各GWの回線番号ごと）
・各種サービス等の確認
５．必要があればログを取得して、TACへの解析依頼をする
・取得すべきログは項目２で説明したもの、およびHP Smart Startもしくは
IBM DSAのログ
・発生時の詳細状況
以上です。
（追記）サービスリスタートへの影響
(1)DB管理用サービスをリスタート：数分
この間はDBへの変更が出来ませんが、呼処理は継続し影響はありません。
(2)Cisco CallManagerのリスタート：数分
この間の呼処理（新規の発信・着信・転送）ができなくなります。現在、通話中の
呼に関しては維持されます。
(3)Cisco Tomcatのリスタート：数分
Webサービス（Cisco Unified CM Administrator, Cisco Unified Serviceability,
Csico Unified User, Extension Mobility, Web Dialer, Click to Call)へのアクセスが
できなくなります。呼処理は継続し影響はありません。
(4)System SSHのリスタート：数分
新しいSSHセッションが張れなくなります。既存のSSHセッションは影響を受けません。
呼処理は継続し影響はありません。
(5)Service Manager、全サービスをリスタート：約10分から15分
全てのサービスをリスタートするため、呼処理にも影響が出ます。
呼処理をつかさどっているCisco CallManager Serviceも含まれるためです。
ただし、現在通話中の呼に関しては維持されます。
サーバリスタートの場合に比較して、OS起動時間分のみ短縮できます。
