Cisco Unified Communications Manager および Cisco PGW のバックアップ
ここでは、プラットフォームをアップグレードする前に、認識されていて信頼できる構成を保存するプロセスの概要について、次のトピックに分けて説明します。
• 「Cisco Unified Communications Manager のバックアップ」
• 「Cisco Unified Communications Manager および Cisco PGW における構成の復元」
• 「Cisco PGW の構成の復元」
• 「Cisco PGW のクリーン ステータスへの復元」
バックアップを実行した後、必要に応じて保存した構成を Hosted UCS プラットフォーム コンポーネントに復元することができます。たとえば、Cisco Unified CM または Cisco PGW の初期の静的構成を復元しておけば、時間のかかる再構成のプロセスを省略できます。
Cisco Unified Communications Manager のバックアップ
Disaster Recovery System(DRS; ディザスタ リカバリ システム)を使用して、構成のバックアップと復元を実行するには、次の手順を実行します。
手順
ステップ 1 Cisco Unified CM の OS 管理者資格情報を使用して、[Disaster Recovery System] にアクセスします (CCM7.x) 。
ステップ 2 Cisco Unified CM でバックアップ デバイスを作成し、アクセス資格情報を含むネットワーク ベースのバックアップ デバイスを追加します。
ステップ 3 [Manual Backup] > [Select the Device Name] を選択します。
ステップ 4 [CCM] チェックボックスをオンにします。
ステップ 5 [Start Backup] をクリックします。
約 5 ~ 10 分経過すると、Backup Device フォルダに TAR ファイルが作成されます。
Cisco PGW のバックアップ
(注) 使用中の Cisco PGW 2200 ソフトスイッチが、連続サービス システム(アクティブ/スタンバイ)の場合は、両方の Cisco PGW 2200 ソフトスイッチでバックアップを実行する必要があります。
(注) 次のセクションに示すさまざまなバックアップの方法は、システムに mgcusr としてログインしている場合のみ実行できます。ルートとして実行している場合は、いずれのバックアップ操作も実行できません。
手動のバックアップ操作を実行するには、Cisco MGC で次の UNIX コマンドを入力します。
mgcbackup -d path [-r retries -t retry_time]
表示の意味は次のとおりです。
• path -- バックアップ ファイルを保存するディレクトリのフル パスです。たとえば、システムにマウントしたリモート サーバ上のディレクトリや、ローカルのテープ ドライブなどを指定します。
(注) バックアップ ファイルは、ローカルの Cisco MGC ホストには保存しないことを推奨します。これは、ローカル ホストにバックアップ ファイルを保存すると、データの呼び出しに使用できるディスク領域が減り、自然災害が発生した場合にデータの安全を確保できなくなる可能性があるためです。
• retries -- バックアップ操作を中断する前に、Cisco MGC でアクティブなプロビジョニング セッションを確認する試行回数です。デフォルト値は 0、最大値は 100 です。
(注) Cisco MGC 上に、アクティブなプロビジョニング セッションが存在する間は、バックアップ操作を開始できません。
• retry_time -- Cisco MGC において、アクティブなプロビジョニング セッションの確認を実行するまでに、待機する時間(秒数)です。デフォルト値は 30 秒、最大値は 3600 秒です。
たとえば、/dev/rmt/h0 というディレクトリ パスに、試行回数は最大 3 回、各操作間の待機時間は 60 秒で手動のバックアップ操作を実行する場合は、次の UNIX コマンドを入力します。
mgcbackup -d /dev/rmt/h0 -r 3 -t 60
バックアップ ファイルは指定したディレクトリに、次の形式で保存されます。
mgc_hostname_yyyymmdd_hhmmss_backup
表示の意味は次のとおりです。
• hostname -- Cisco MGC ホストの名前です(例:MGC-01)。
• yyyymmdd -- バックアップ ファイルの作成日を、年-月-日の形式で表します(例:20011130)。
• hhmmss -- バックアップ ファイルの作成時刻を、時間-分-秒の形式で表します(例:115923)。
バックアップ操作の詳細については、『Cisco PGW 2200 Softswitch Release 9.8 Operations, Maintenance, and Troubleshooting Guide』の第 3 章「Backing Up System Software」を参照してください。このマニュアルは次の URL から入手できます。
http://www.ciscosystems.cg/en/US/docs/voice_ip_comm/pgw/9.8/Maintenance/Guide/r9chap3.html#wp1229244
Cisco Unified Communications Manager および Cisco PGW における構成の復元
ここでは、Cisco Unified CM および Cisco PGW の構成を復元する方法を説明します。内容は次のとおりです。
• 「Cisco Unified Communications Manager の構成の復元」
• 「Cisco PGW の構成の復元」
• 「Cisco PGW バックアップ ファイルのリスト表示」
• 「Cisco PGW バックアップ ファイルの復元」
• 「Cisco PGW のクリーン ステータスへの復元」
Cisco Unified Communications Manager の構成の復元
Cisco Unified CM を復元するには、Disaster Recovery System(DRS; ディザスタ リカバリ システム)の復元プロセスを実行してから、パブリッシャとサブスクライバを再起動します。
Cisco PGW の構成の復元
この復元方式では、Cisco MGC ソフトウェアの構成データを復元するスクリプト、UNIX 管理ファイル、および Main Memory Database(MMDB; メイン メモリ データベース)を使用します。
(注) この手順は、定期的にシステム構成データのバックアップを実施していることを前提としています。この手順をシステム構成のバックアップに適用する手順については、「Cisco PGW のバックアップ」 を参照してください。
Cisco PGW バックアップ ファイルのリスト表示
特定のディレクトリ パスのバックアップ ファイルをリスト表示するには、Cisco MGC で、次の UNIX コマンドを入力します。
ここで path は、バックアップ ファイルを保存したディレクトリのパス(リモート サーバ上のディレクトリや、ローカルのテープ ドライブなど)です。
システムにより、次のような応答が返されます。
Backup files in /var/cisco
--------------------------------------------------
mgc_venus_20011010_153003_backup
mgc_venus_20011011_153003_backup
mgc_venus_20011012_153003_backup
Cisco PGW バックアップ ファイルの復元
バックアップ ファイルを復元する前に、PGW の CiscoMGC サービスを停止する必要があります。
PGW にルート ユーザとしてログインし、次のコマンドを実行して mgc サービスを停止します。
PGW-ENT2M% /etc/init.d/CiscoMGC stop
特定のバックアップ ファイルに保存されている構成データを復元するには、影響を受ける Cisco MGC で次の UNIX コマンドを実行して、復元スクリプトを実行します。
mgcrestore -d path -f filename
表示の意味は次のとおりです。
• path -- バックアップ ファイルが保存されている場所へのディレクトリ パスです。
• filename -- 保存するバックアップ ファイルのファイル名です。
たとえば、/var/cisco というディレクトリに保存されている mgc_venus_20011012_153003_backup という名前のバックアップ ファイルを復元する場合は、次のコマンドを入力します。
mgcrestore -d /var/cisco -f mgc_venus_20011012_153003_backup
バックアップ ファイルを復元した後、ルート ユーザとして PGW 上で mgc サービスを起動します。
PGW-ENT2M% /etc/init.d/CiscoMGC start
バックアップ操作の詳細については、『Cisco PGW 2200 Softswitch Release 9.8 Operations, Maintenance, and Troubleshooting Guide』の第 5 章「Restoring Procedures for Cisco MGC Software Release 9.1(5) and up」を参照してください。このマニュアルは次の URL から入手できます。 http://www.ciscosystems.cg/en/US/docs/voice_ip_comm/pgw/9.8/Maintenance/Guide/r9chap6.html#wp1722661
Cisco PGW のクリーン ステータスへの復元
Cisco PGW をクリアし、元の静的構成を復元するには、次の手順を実行します。
手順
ステップ 1 Reflexion Host - UNIX を使用して Cisco PGW にログインします。
テスト システムに、ユーザ名:mgcusr、パスワード:cisco を使用してログインします。
ステップ 2 太字で示すテキストを入力します。
GL-D-PGW mml> prov-sta::srcver="pure-static",dstver="iBVSconfig",confirm
MGC-01 - Media Gateway Controller 2005-06-30 14:09:55.352 BST
(注) 上記に示す MML コマンド内の pure-static は、PGW における静的構成 MML セッションの名前の例です。PGW に保存されている静的 MML 構成セッションがある場合は、そのセッションを使用して PGW 静的構成を復元します。
MGC-01 - Media Gateway Controller 2005-06-30 14:10:02.164 BST
M COMPLD
"PROV-CPY"
;
この例の iBVSconfig というエントリは仮の名前です。正確な名前を入力しなくてもかまいません。
USM のバックアップと復元
USM は、クラスタ内および、アクティブ/スタンバイサーバ間のデータベースを自動的にバックアップします。USM により、各ヘッドエンドに常に 2 個ずつ、合計 4 個のデータベースのコピーを保持しています。データベースのコピーをオフサイトに保存する必要がある場合は、データベースのエクスポート コピーを作成できます。
これまで、ほとんどの場合、オフサイト バックアップは 24 時間に 1 回実行されてきました。これは、早朝などのプロビジョニング トラフィックが少ない時間帯に実行する必要があります。
ディザスタ リカバリ プランの一部としてバックアップを有益なものにするため、USM のバックアップは、Hosted UCS プラットフォームに Cisco PGW、Cisco Unified CM、IP Unity も搭載されている場合、それらとの一貫した状態を保つ必要があります。一貫した状態を確保するため、プラットフォームのバックアップを作成している間は、USM のトランザクションをフリーズさせる必要があります。
すべてのバックアップを同時に作成することができれば、USM と、これにより制御されるサーバ間に不整合が生じることなく、プラットフォーム全体を時間的に移動させ、最新のバックアップの状態に戻すことが可能になります。
(注) CLI を使用する場合は、クライアントが SSH を使用できる必要があります。最も一般的な SSH クライアントには Putty(Windows プラットフォーム)または端末上の SSH クライアント(UNIX / Linux および Mac OS X プラットフォーム)などがあります。
(注) デフォルトのログイン ユーザ名は usmcli、デフォルトのパスワードは voss です。デフォルトのログイン情報を使用してログインできない場合は、サポート担当者にお問い合わせいただき、デフォルト パスワードのリセットと、この機能が使用中のシステムで有効にされていることの確認を依頼してください。
次に示すコマンドは、アクティブ VoSS サーバで実行することが重要です。これらのコマンドをアクティブではない VoSS ディレクタで実行しないでください。
CLI を使用する場合は、次の手順を実行します。
ステップ 1 SSH を使用してクラスタ/スタンドアロン システムに、ユーザ usmcli としてログインします。次のようなプロンプトが表示されます。
Welcome to the VOSS-USM Standalone Console
ステップ 2 イネーブル モードを開始するには(他のネットワーク ハードウェアと同様に)、次に示すように enable と入力します。
プロンプトが「=>>」から「=>#」に変わり、変更が反映されるようになります。
ステップ 3 次に示すように CLI で「dbbackup」コマンドを入力します。
(注) バックアップされるのはデータベースのみです。DNS 構成、Syslog、手動による変更(たとえば、ファイル内容に加えた変更)、およびバルク ローダーのシートなどの他の構成情報は、現在のところ、ファイルをコピーして手動でバックアップする必要があります。
(注) ただし、システムを再構築する場合は、プラットフォームとソフトウェアの再インストール時にこれらのファイルも再作成されます。
USM データベースが実行される手順を図 5-1 に示します。
図 5-1 CLI を使用した USM データベースのバックアップ
USM の復元
USM データベースのバックアップを実行する前に、USM システム上の関連するサービスを停止する必要があります。
手順
ステップ 1 USM にルート ユーザとしてログインします。
ステップ 2 すべてのサービスを停止し、Postgress を再起動します(クラスタ環境でスタンドアロンの場合は、Postgress を再起動する必要があります)。スタンドアロン USM システムで、次に示すコマンドを実行してすべてのサービスを停止します。
for svc in usm-autoregister loader_scheduler extdhcp apache2 usm_batch selfcare memcached estraier iptparent iptqueue iptdevmn voss-monit voss-imq postgresql-standalone postgresql; do /etc/init.d/${svc} stop; done
USM がクラスタとして導入されている場合は、次に示すコマンドを使用してすべてのサービスを停止します。
/etc/init.d/heartbeat-wrapper stop
Restart postgresql services:
/etc/init.d/postgresql-stanalone restart
/etc/init.d/postgresql restart
ステップ 3 次の例を参照し、復元を実行します。
/opt/VOSS/usm/scripts/deployment/db-backup-restore.py --restore /root/db-backup-ipt-2010-02-11.sql
ステップ 4 バックアップ ファイルを復元したら、すべての USM サービスを起動します。スタンドアロン USM システムでは、次に示すコマンドを実行してすべてのサービスを起動します。
for svc in voss-monit iptdevmn iptqueue iptparent estraier memcached usm_batch selfcare apache2 extdhcp loader_scheduler usm-autoregister; do /etc/init.d/${svc} start; done
USM がクラスタとして導入されている場合は、次に示すコマンドを使用してすべてのサービスを起動します。
/etc/init.d/heartbeat-wrapper start
Cisco Unified Communications Manager クラスタのクリア
このセクションでは、Hosted UCS プラットフォームを再構築する準備段階として、Cisco Unified CM クラスタをクリアするプロセスについて説明します。
クリアの手順の順番は重要ではありません。一部の Hosted UCS プラットフォームでは、これ以上のクリアの手順が必要になる場合があります。たとえば、Movius サーバの Sysconfig GUI を使用して Movius サーバ内の組織を消去する必要がある場合もあります。
再構築プロセスを開始したら、すべての段階を完了させる必要があります。アーキテクチャから 1 つのコンポーネントを削除すると、元に戻すことはできません。
USM と Cisco Unified CM の間でデータの重複や不整合が生じないようにするため、再構築を実行する前に Cisco Unified CM をクリアする必要があります。
CUCM バックアップ ファイルを復元すると、Cisco Unified CM パブリッシャをすぐに初期の状態に戻すことができます。
DRS バックアップ ファイルを使用できない場合に Cisco Unified CM をクリアにし、相互依存性の問題を回避するには、次の手順を実行します。
手順
ステップ 1 電話機を削除します。
検索リストで 50 台の電話機を選択すると、一度に 50 台の電話機を削除できます。
ステップ 2 [Call Routing] > [Translation Patterns] メニューから、一度に 50 個のトランスレーション パターンを削除します。
ステップ 3 [Device] > [CTI Route Points] メニューから、使用された CTI ルート ポイントをすべて削除します。
ステップ 4 [Call Routing] > [Route/Hunt] > [Route Pattern] メニューから、すべてのルート パターンを削除します。
ステップ 5 [Call Routing] > [Route/Hunt] > [Route List] メニューから、すべてのルート リストを削除します。
ステップ 6 [RoutePlan] > [Route/Hunt] > [Route Group] メニューから、すべてのルート グループを削除します。
ステップ 7 [Device] > [Trunks] メニューから、すべてのトランクを削除します。
ステップ 8 [Device] > [Gatekeepers] メニューから、すべてのゲートキーパーを削除します。
ステップ 9 [Device] > [Gateways] メニューから、すべてのゲートウェイを削除します。
ステップ 10 [Media Resources] > [MediaResourceGroupList] メニューから、すべてのメディア リソース グループ リストを削除します。
ステップ 11 [Media Resources] > [MediaResourceGroup] メニューから、すべてのメディア リソース グループを削除します。
ステップ 12 [System] > [Locations] メニューから、すべての場所を(一度に 50 個表示して)削除します。
(注) Cisco Unified CM では、デフォルトの場所、デバイス プールおよび地域は削除できません。デフォルトの設定は削除しないでください。
ステップ 13 [Media Resource] > [Conference Bridge] メニューから、不要なコンファレンス ブリッジをすべて削除します。
USM が必要とするコンファレンス ブリッジは削除しません。
ステップ 14 [Application] > [CiscoCM Attendant Console] > [Pilot Points] メニューから、使用されたパイロット ポイントがあれば削除します。
ステップ 15 [System] > [Device Pool] メニューから、デフォルト以外のデバイス プールをすべて削除します。
ステップ 16 [System] > [Region] メニューから、デフォルト以外の地域をすべて削除します。
ステップ 17 [Call Routing] > [Route/Hunt] > [Hunt Pilot] メニューから、使用されたハント パイロットをすべて削除します。
ステップ 18 [Call Routing] > [Route/Hunt] > [Hunt List] メニューから、使用されたハント リストをすべて削除します。
ステップ 19 [Call Routing] > [Route/Hunt] > [Line Group] メニューから、使用されたライン グループをすべて削除します。
ステップ 20 すべてのユーザを、CCMAdmin グループから 1 人ずつ、または BAT Tool の機能を使用して一括で削除します。
ステップ 21 [Call Routing] > [Directory Numbers] メニューから、使用されたディレクトリ番号をすべて削除します。
ステップ 22 [Call Routing] > [Call Pickup Group] から、使用されたコール ピックアップ番号をすべて削除します。
ステップ 23 [Call Routing] > [Call Park] メニューから、使用されたコール パーク番号をすべて削除します。
ステップ 24 [System] > [Cisco Unified CM Groups] メニューから、デフォルト以外の Cisco Unified CM グループをすべて削除します。
ステップ 25 [Device] > [Device Settings] > [Device Profile] メニューから、「Logout」サービスを含むプロファイルをすべて削除します。
ステップ 26 [Call Routing] > [Route Plan Report] メニューから、割り当てられていない DN を探し、検索ページの最下部にある [Delete All Found Items] を選択します。
これにより、150 個の割り当てられていない DN を一度に削除できます。
ステップ 27 voice-mail プロファイル、voice-mail パイロット番号、および MWI 番号についても、これらを維持する必要がない限り同様に処理します。
ステップ 28 [Call Routing] > [Class of Control] > [Calling Search Space] メニューから、 IncomingToCluster 以外のすべての CSS を削除します。
ステップ 29 [Call Routing] > [Class of Control] > [Partitions] メニューから、すべてのパーティションを削除します。
ステップ 30 [Call Routing] > [Route Plan Report] メニューから、割り当てられている DN を検索し、一度に削除します。
(注) 問題が発生した場合は、依存関係レコード機能を使用して、レコードの消去を妨げている可能性があるコンポーネントを検索します。
Cisco PGW の初期化
このセクションでは、Hosted UCS プラットフォームを再構築する前に、USM が作成したファイルを削除して、Cisco PGW をクリアするプロセスについて説明します。
Cisco PGW のクリアは、Hosted UCS プラットフォームをリロードする前に実行する必要があります。Cisco PGW のクリアとは、USM のデータは消去し、USM に関係なく Cisco PGW サーバ上に作成された他の構成情報は消去しないことを意味します。
Cisco PGW を初期化するには、次の手順を実行します。
手順
ステップ 1 アクティブな Cisco PGW にログインします。
PuTTY などの端末コンソール プログラムを使用し、Telnet または SSH を使用してログインします。
テスト システムに、ユーザ アカウント:mgcusr、パスワード:cisco を使用してログインします。
前の行に戻って値を追加できるよう、上向きの矢印の操作を設定するには、次を使用します。
ステップ 2 アクティブな Cisco PGW にログインしていることを確認するには、次のコマンドを入力します。
ステップ 3 必要に応じてロールバックを可能にするには、バイナリ バックアップを作成します。ファイル名は自由に決定できます。
たとえば、270710-01bin などです。
mml> prov-sta::srcver=”active”,dstver=”270710-01bin”
ステップ 4 必要に応じて、診断用のテキスト バックアップを作成します。ファイル名は自由に決定できます。
たとえば、270710 -01text などです。
mml>prov-exp:all:dirname=”270710-01text”
ステップ 5 ロールバックが必要な場合はプロセスを元に戻します。
mml> prov-sta::srcver=”270710-01bin ”,dstver=”270710-03bin ”
mml> prov-dply (Dual server PGW platform)
or
mml> prov-cpy (Single server PGW platform)
ステップ 6 Cisco PGW のリセット プロセス(ダイヤル プランのみ)を実行するには、次のコマンドを入力します。
% cd /opt/CiscoMGC/etc/cust_specific
これにより、テキスト ファイルを含めた保存されているファイルのリストを取得できます。
% cd /opt/CiscoMGC/etc/cust_specific/270710-01text
ステップ 7 USM によりロードされた、4 文字の mml ファイルをすべてメモに記録します。
たとえば、メモ帳に ICCM.mml、P974.mml、XXXX.mml、XXXX.mml をコピーします。
mml> prov-sta::srcver=”active”,dstver=”270710-02bin”
mml> numan-dlt:dialplan:custgrpid=“XXXX“
ここで、 XXXX は 4 文字の各 mml ファイルの名前を指します。
ステップ 8 すべての XXXX.mml ファイルが削除されるまで、このプロセスを繰り返します。依存関係を持つファイルが見つかった場合は、次のファイルからこの動作を始め、すべてのファイルが削除されるまで手順を繰り返します。
(注) ダイヤル プラン間の相互関係のため、手動では削除できないダイヤル プランもあります。PGW の静的構成のバックアップを作成し、PGW をクリーン アップする必要がある場合に、PGW の静的構成を復元することを推奨します。
ステップ 9 ICCM ダイヤル プランを空のファイルとしてリロードします。
mml> numan-add:dialplan:custgrpid=“ICCM“,overdec=”YES”
mml> prov-dply (Dual server PGW platform)
or
mml> prov-cpy (Single server PGW platform)
ステップ 10 手順が終了したら、再度 Cisco PGW のバックアップを実行します。
たとえば、Cisco PGW の静的設定を削除して Cisco PGW をクリアする必要がある場合などは、これが Cisco PGW の静的構成になります。
ステップ 11 必要に応じてロールバックを可能にするには、バイナリ バックアップを作成します。ファイル名は自由に決定できます。
たとえば、 VSR2-151007Static-HB-01bin などです。
mml> prov-sta::srcver=”active”,dstver=”2710001-01bin”
USM の初期化
このセクションでは、すでにダイヤル プランとデータがロードされている既存の USM プラットフォームをクリアする方法について説明します。
Hosted UCS プラットフォームの再構築を計画している場合に、USM データベースをクリアします。クリアのプロセスは、USM GUI を使用して手動ですべてのデータを削除したり、バルク データやオペレーション ツールを削除するよりも速く完了します。これは、USM に多くのカスタマーと場所がロードされている場合に顕著です。
USM クラスタを削除するには、次の手順を実行します。
注意 破棄の手順を元に直す方法がないため、正しいサーバで作業していることを確認してください。
(注) このコマンドによる影響は重大です。このコマンドを使用する前に、このコマンドを実行した場合の影響を十分に理解するようにしてください。
手順
ステップ 1 SSH を使用してクラスタ/スタンドアロン システムに、ユーザ usmcli としてログインします。
次のようなプロンプトが表示されます。
Welcome to the VOSS-USM Standalone Console
ステップ 2 イネーブル モードを開始するには(他のネットワーク ハードウェアと同様に)、次に示すように enable と入力します。
プロンプトが「=>>」から「=>#」に変わり、変更が反映されるようになります。
ステップ 3 次に示すように CLI で「reset app」コマンドを入力します。
Really reset the application? ? [y/N] : y
Application reset complete.
ステップ 4 USM システムを再起動します。
(注) USM は他のサーバに自動的にレプリケートするため、破棄する必要があるのは、スタンドアロン VOSS システム、または VOSSDir1 のみです。