Cisco CallManager クラスタのアップグレード
目次
概要
このドキュメントは、Cisco CallManager クラスタをアップグレードする方法に関する概要レベルの推奨事項を説明することを目的としています。 Cisco CallManager ソフトウェアに付属のインストレーション ノートに、インストール手順に関する詳細情報がすべて記載されています。 ただし、このドキュメントでは、クラスタのアップグレードで発生するその他の問題の一部について説明します。
前提条件
要件
アップグレードを開始する前に、次の点を確認してください。
-
最新の OS/BIOS パッチを実行していること。
Cisco IP Telephony サーバを最新に保つ方法については、「Cisco IP Telephony の BIOS およびオペレーティング システムのバージョン ロードマップ」を参照してください。
-
MSSQL サービスが実行されていることを確認します。 そうでなければ、SQLSvc のパスワードを確認します。
「SQLSvc アカウントのパスワードの回復」を参照してください。
-
IP テレフォニー ソリューションの互換性に関する情報は、「Cisco Unified Communications Manager ソフトウェア互換性マトリクス」を参照してください。
-
クラスタのすべてのサーバが同じ DB を使用していることを、[START] > [RUN] > [REGEDIT] > HKEY_LOCAL_MACHINE\Software\Cisco systems, inc\DBL で確認します。
DBConnection 0（SERVER=Publisher 名および DATABASE=CCM030X 内）がパブリッシャ サーバ上で最新のものであることを確認します。DBConnection 1 は加入者の名前および最新の Cisco CallManager データベースを指します。
-
Microsoft SQL Enterprise Manager を使用するすべてのサーバで複製が OK であることを確認します。 これは、[Start] > [Programs] > [Microsoft SQL Server 7.0] > [Enterprise Manager] にあります。
-
すべてのシスコ認定アンチ ウイルスおよび侵入検知サービスを無効にします。
-
空き領域が 1 GB 以上あること。 この設定が推奨されます。
注: CallManager トレースを無効にして、トレース ファイルなどの未使用のファイルを削除して空き領域を確保してください。
-
ターミナル サービスはサポートされていないため、使用しないでください。 その代わりに、サポートされる仮想ネットワーク コンピューティング（VNC）を使用します。
注: RAID コントローラがある場合、アップグレード前に 1 つのディスクを取り出し、最新バージョンのバックアップがあることを確認します。 これにより、アップグレードが失敗しても以前の設定に戻ることができます。
使用するコンポーネント
このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
表記法
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
パブリッシャのアップグレード
Cisco CallManager クラスタはパブリッシャ/サブスクライバ データベース関係の基礎であるため、パブリッシャを最初にアップグレードすることが重要です。 アップグレードを行うと、新しいデータベースがパブリッシャで作成され、古いデータベースのデータがそこに移行します。 これにより、データベース スキーマへの新しい変更を簡単に処理できます。 サブスクライバが追加されると、パブリッシャの新しいデータベースに登録されます。 このため、パブリッシャを最初にアップグレードする必要があるのです。 まだ存在していないデータベースにサブスクライバを登録することはできません。 下の図は、パブリッシャ/サブスクライバ関係のほか、コール シグナリング関係を示します。
注: CTI ID = 1 の CallManager サーバをパブリッシャ サーバと見なすことができます。 CTI ID を検索するには、[CCM Admin Webpage] > [System] > [Cisco CallManager] に移動して、検索結果からサーバをクリックして CTI ID を確認します。
アップグレードでは Cisco CallManager のすべてをダウンロードする必要があるか
いいえ。 大きなキャンパスでは、Dynamic Host Configuration Protocol（DHCP）サーバが数時間で数千台の電話機から IP アドレスの要求を受信する負担は大きくなります。 拡張アップグレードの時間にすべての電話サービスがダウンすることが望ましくない場合もあります。 アップグレードは放課後に実行する必要がありますが、多くの場合アップグレード中にクラスタの一部を実行し続けることができます。 これは Cisco CallManager の冗長グループを活用することで実現できます。 基本的に、1 つのサーバをアップグレードする間はバックアップがすべての電話をサポートします。 このドキュメントでは、3つの標準的な導入モデルについて説明します。
推奨されるクラスタ設定
2,500台の電話 - 3 つのサーバ合わせて
最大 2500 人のユーザに対応する Cisco CallManager クラスタ：
-
サーバ A は専用データベース パブリッシャと Trivial File Transfer Protocol（TFTP）サーバです。
-
サーバ B は登録されている全デバイスに対するプライマリ Cisco CallManager です。
-
サーバ C は登録されている全デバイスに対するバックアップ Cisco CallManager です。
この設定では、サーバ B および C には Cisco CallManager 冗長グループが 1 つだけ必要です。
-
パブリッシャを最初にアップグレードする必要があるので、ここでプロセスを開始します。 パブリッシャ A は単なるデータベース サーバなので、アップグレードして再起動できます。
-
Cisco CallManager C でアップグレードを開始できます。 Cisco CallManager C はバックアップであり、そこに登録されたデバイスがないため、コール処理は中断されません。 また、プライマリ Cisco CallManager の前にバックアップ Cisco CallManager をアップグレードすると、デバイスがそのファームウェアを 1 度だけアップグレードすればよくなります。
-
プライマリ Cisco CallManager B をアップグレードできます。 アップグレードを開始すると、Cisco CallManager サービスが停止して、デバイスはバックアップ Cisco CallManager C にフェールオーバーします。 デバイスが登録され、ファームウェアの更新を受信している間、サービスにわずかな中断があります。
-
アップグレード プロセスの最後のステップは、クラスタ内のすべてのサーバをリブートすることです。 パブリッシャ A のリブートから始めます。 リブートが完了したら、Cisco CallManager B をリブートします。 サーバがオンラインに戻ったら、フェールバック プロセスが始まるまで 5 ~ 10 分待ちます。 最後に、Cisco CallManager C をリブートします。 以上でクラスタのアップグレードは完了です。
5,000台の電話 - 4 つのサーバ合わせて
最大 5000 人のユーザに対応する Cisco CallManager クラスタ：
-
サーバ A は専用データベース パブリッシャと TFTP サーバです。
-
サーバ B は IP Phone 1 から 2500 までに対するプライマリ Cisco CallManager です。
-
サーバ C は IP Phone 2501 から 5000 までに対するプライマリ Cisco CallManager です。
-
サーバ D は登録されている全デバイスに対するバックアップ Cisco CallManager です。
この設定では、2 つの Cisco CallManager 冗長グループが必要です。 1 つはサーバ B および D 用で、もう 1 つはサーバ C および D 用です。
このシナリオでは、2 つのプライマリ Cisco CallManager が 1 つのバックアップを持つことになります。 各プライマリで 2,500 台の電話機がある場合、アップグレードのために両方のプライマリ サーバを停止することはできません。 バックアップは 5,000 台のデバイスで終了しますので、2,500 台の制限に違反します。
-
パブリッシャ A を最初にアップグレードします。 次に、Cisco CallManager D をアップグレードします。 この時点まで、コール処理は中断されません。
-
Cisco CallManager D を再起動したら、Cisco CallManager B のアップグレードを開始します。 アップグレードを開始すると、デバイスは Cisco CallManager D にフェールオーバーします。 デバイスが登録され、ファームウェアの更新を受信している間、サービスがわずかに中断します。 Cisco CallManager B がオンラインに戻ったら、デバイスがフェールバックするまで 5 ~ 10 分待ちます。
-
Cisco CallManager C をアップグレードします。 デバイスが Cisco CallManager D を登録し、ファームウェアの更新を受信している間、サービスがわずかに中断します。
-
アップグレード プロセスを完了するには、クラスタ内のすべてのサーバをリブートする必要があります。 まず Publisher A をリブートします。 リブートが完了したら、Cisco CallManager B をリブートします。 Cisco CallManager B がオンラインに戻ったら、デバイスがフェールバックするまで 5 ~ 10 分待ちます。 次に、Cisco CallManager C をリブートしてサーバがオンラインに戻るまで待ちます。 最後に、Cisco CallManager D をリブートします。 以上でクラスタのアップグレードは完了です。 この状況では、2 回目のプライマリ アップグレード中に電話機の半数がダウンします。 これは理想的ではないものの、電話機がダウンする台数とその時間を最小化することになります。
10,000台の電話 - 8 つのサーバ合わせて
最大 10,000 人のユーザに対応する Cisco CallManager クラスタ：
-
サーバ A は専用データベース パブリッシャです。
-
サーバ B は専用の TFTP サーバです。
-
サーバ C は IP Phone 1 から 2500 までに対するプライマリ Cisco CallManager です。
-
サーバ D は IP Phone 2501 から 5000 までに対するプライマリ Cisco CallManager です。
-
サーバ E は IP Phone 1 から 5000 までに対するバックアップ Cisco CallManager です。
-
サーバ F は IP Phone 5001 から 7500 までに対するプライマリ Cisco CallManager です。
-
サーバ G は IP Phone 7501 から 10,000 までに対するプライマリ Cisco CallManager です。
-
サーバ H は IP Phone 5001 から 10,000 までに対するバックアップ Cisco CallManager です。
この設定では、サーバ CE、DE、FH および GH には Cisco CallManager 冗長グループが 4 つ必要です。 次の図に、この設定を示します。
-
パブリッシャをアップグレードします。
-
TFTP サーバをアップグレードします。
この時点で 6 つすべての Cisco CallManager サーバは稼働し続けているため、アップグレードによる影響を受けません。 このシナリオは、5,000 台の電話機のシナリオで説明したものと似ています。 唯一の違いは、1 つのバックアップを持つ 2 つのプライマリが 2 組あることです。 プライマリ Cisco CallManager は C、D、F、G です。 バックアップは E および H で、プライマリ C および D は E がバックアップし、プライマリ F および G は H がバックアップします。
-
バックアップ Cisco CallManager E および H はこの次にアップグレードする必要があります。 アップグレードが完了したら、サーバがリブートしてオンラインに戻るのを待ちます。
-
これで、Cisco CallManager C および F をアップグレードする準備ができました。 アップグレードを開始すると、これらの Cisco CallManager に登録されたデバイスがバックアップにフェールオーバーします。 デバイスが登録し、ファームウェアの更新を受信している間、サービスがわずかに中断します。 デバイスがフェールバックするまで 5 ~ 10 分待ちます。
-
次に、Cisco CallManager D および G をアップグレードします。 手順 4 と同様に、サービスにわずかな中断があります。 アップグレードが完了したら、サーバがリブートしてオンラインに戻るのを待ちます。
-
アップグレードを完了するには、クラスタ内のすべてのサーバをリブートする必要があります。 次のグループのアップグレードを開始する前に、それぞれのリブート プロセスが完了していることを確認します。 パブリッシャ A のリブートから始めます。 次に、TFTP B をリブートします。 B がオンラインに戻ったら、Cisco CallManager C および F をリブートします。 デバイスがフェールバックするまで 5 ~ 10 分待ち、Cisco CallManagers D および G をリブートします。 最後に、Cisco CallManager E および H をリブートします。 以上でクラスタのアップグレードは完了です。
レビュー： Cisco CallManager アップグレードのルール
Cisco CallManager をアップグレードするときは、次のルールに従ってください。
-
パブリッシャおよびスタンドアロン TFTP サーバ（あれば）を常に最初にアップグレードします。
-
バックアップ Cisco CallManager は2 番目にアップグレードします。
-
最後にプライマリ Cisco CallManager をアップグレードします。
-
すべての Cisco CallManager をアップグレードしたら、すべてのサーバをリブートする必要があります。
-
SA および管理者パスワードを設定する際は、クラスタ内のすべてのサーバで同じパスワードを設定してください。
取り付け/アップグレードが失敗する場合の対処法
Cisco CallManager 3.1 および 3.2
次のログを収集します。
-
C:\*.log
-
C:\*.txt
-
C:\Winnt\sti*.*
-
C:\dcdsrvr\log\*.*（DCD に関する問題の場合）
-
C:\Install\DBInstall\*.*
StiSetup.log はインストール/アップグレード中のさまざまな段階の概要を示します。 Dbinstall000.log はデータベース レベルでどのような変更が行われたかについての概要を示します。
Cisco CallManager 3.3
次のログを収集します。
-
ルート ディレクトリ C:\ にあるすべての *.txt と *.log ファイル
-
次の場所にあるすべてのファイル：C: \Program Files\Common Files\Cisco\Logs ディレクトリ
-
STI_DATA パーティションにあるすべてのファイル
-
C:\DCDSrvr\log ディレクトリにあるすべてのファイル（DCD に関する問題の場合）
CCMInst<date><time>.log はインストール/アップグレード中のさまざまな段階の概要を示します。 CCMDBSetup<date><time>.log はデータベース レベルでどのような変更が行われたかについての概要を示します。
Cisco CallManager 4.x
次のディレクトリにあるすべてのログ ファイル（*.log と *.txt）を取得して確認します。
-
C:\Program Files\Common Files\Cisco\Logs にあるすべてのファイル
-
C:\Program Files\Common Files\Cisco\Directory にあるすべてのファイル
-
C:\Install\DBInstall にあるすべてのファイル
-
C:\Dcdsrvr\log にあるすべてのファイル
ログ ファイルに表示されるすべてのエラー メッセージが重大であるとは限りません。 MSI はさまざまな理由でログ ファイルにエラー メッセージを生成します。 たとえば、Cisco CallManager で使用されていないサービスにアクセスしようとした場合にも、メッセージが表示されます。
詳細については、「Cisco CallManager 4.x のアップグレード」を参照してください。
注: パスワードの同期問題を解決するには、パブリッシャのみで Admin Utility を使用します。
イベント ビューア： .evt 形式で記録されるアプリケーションおよびシステム ログ
注: すべてのエラーが実際の問題に関連しているとは限りません。 シスコ テクニカル サポートでケースをオープンする前に、必ず確認してください。
詳細については、「CallManager のイベント ログ」を参照してください。 このドキュメントは頻繁に更新されます。
収集したログは、TAC エンジニアが問題を詳しく調査するために活用されます。 そのため、TAC ケースを常にこれらのログで更新しておくと、解決プロセスがスムーズに運びます。
フィードバック