Cisco BTS 10200 Softswitch オペレーション/メンテナンス ガイド Release 5.0
BTS の監視とバックアップ
BTS の監視とバックアップ
発行日;2012/02/06 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 887KB) | フィードバック

目次

BTS の監視とバックアップ

BTS 輻輳の検出と防止

BTS ハードウェアの監視

BTS システム状態のチェック

BTS システム状態レポートの使用

BTS システム時刻のチェック

各ホスト マシンの OS ログのチェック

各ホスト マシン上のディスク ミラーリングのチェック

CA/FS サイド A

CA/FS サイド B

EMS サイド A

EMS サイド B

データベースおよびテーブルの監査

Numbering Resource Utilization/Forecast(NRUF)レポートの作成

地方以外の第一次通信事業者および中間通信事業者のレポートの作成

地方の第一次通信事業者および中間通信事業者のレポートの作成

ソフトウェア イメージのバックアップ

全面的なデータベース監査

共有メモリのチェック

CA/FS サイド A での作業

CA/FS サイド B での作業

BTS 全体のバックアップ

CA/FS のバックアップ

EMS/BDMS のバックアップ

EMS データベースのバックアップ

データベースのアーカイブ

ヒープ使用量の確認

DNS サーバのチェック

BTS の監視とバックアップ

この章では、BTS の全体的なメンテナンス方法について説明します。

BTS 輻輳の検出と防止

輻輳が発生すると、BTS は自動的に次の処理を実行します。

トラフィック過負荷またはその他の異常なイベントによって発生した、内部メッセージングの輻輳を検出する

システム障害を回避するための予防アクションを実行する(トラフィックの制限を含む)

内部メッセージングを検出したら、アラームを生成する

輻輳が緩和したら、アラームをクリアする

BTS 内部コール処理エンジンに輻輳が発生したとき、SS7 ネットワークに送信される解放メッセージに、輻輳を示す Access Control List(ACL; アクセス コントロール リスト)パラメータを含める

緊急メッセージをルーティングする。緊急コールの正確な番号は異なります。10 桁までの番号を指定してください(911 および 9911 はデフォルトで含まれています)。詳細については、Cisco TAC にお問い合せください。CA の再起動が必要になります。

課金用に SS7 切断原因コード 42 を生成する

原因コード「resource unavailable」で、課金用のケーブル シグナリング停止イベントを生成する

輻輳アラームについては、『Cisco BTS 10200 Softswitch Troubleshooting Guide』を参照してください。

BTS ハードウェアの監視

Hardware Monitor(HMN; ハードウェア モニタ)サブシステムは、次の情報を追跡します。

CPU がアイドル状態になっている割合

CPU がシステム モードになっている割合

CPU がユーザ モードになっている割合

CPU が I/O をブロックしている割合

「実際の」メモリ合計

使用可能な空きメモリ

スワップ領域の合計

使用可能な空きスワップ領域

物理ディスクのディスク使用状況とディスク制御使用状況、および制御レベル(SCSI コントローラに対するベンダーからのドライバ サポートによって異なります)

ディスク デバイス(sd0 や sd1 など)の使用状況

転送速度、Transactions Per Second(TPS; トランザクション数/秒)、ハード エラーまたはソフト エラー

上位 10 個のシステム プロセス(個々のプロセスによる CPU 使用量の一時的な急上昇は報告しません)

HMN は、設定を超過したデバイスおよび機能についてアラーム レポートを生成します。これらの設定が独自の要件に適合するように調整してください。HMN は、次の場合にアラームを生成します。

1 個のプロセスが CPU の 70% を超過した。

Call Agent の CPU の混雑が 90%(アイドル状態が 10%)を超えた。

少なくとも 5 分間隔で、負荷平均が 5 を超えた。

メモリの 95% が消費され、スワップの 50% を超える割合が消費された。これは、システムが仮想メモリのページングに過度の時間を費やしていることを示しています。

1 つのパーティションの 70 % が消費されると、マイナー アラーム(MAINTENANCE #90)を生成する。

1 つのパーティションの 80 % が消費されると、メジャー アラーム(MAINTENANCE #66)を生成する。

1 つのパーティションの 90 % が消費されると、クリティカル アラーム(MAINTENANCE #65)を生成する。

 

表3-1 ハードウェアの管理

作業
サンプル コマンド

ノード レポートの実行

report node node=prica42;

ノードの表示

status node node=prica42;

ホスト マシンのリブート

control node node=prica42; action=REBOOT;

注意 このコマンドは、注意して使用してください。

メンテナンスのためのホスト マシンの設定

control node node=prica42; action=HALT;

注意 ノードを再起動するには、ローカル コンソール アクセスまたは電源の再投入を行ってください。

BTS システム状態のチェック

次の作業を、示されている頻度で実行するか、システム管理者が推奨する場合は、それ以上の頻度で実行します。

 

表3-2 BTS システム状態のチェックリスト

作業
頻度


 

BTS システム状態レポートの使用

毎日


 

BTS システム時刻のチェック

毎日


 

トラフィック測定のチェック

「測定値の使用」を参照してください。

毎日


 

イベント レポートおよびアラーム レポートのチェック

『Cisco BTS 10200 Softswitch Troubleshooting Guide』を参照してください。

毎日


 

各ホスト マシンの OS ログのチェック

毎日


 

EMS データベースのバックアップ

毎日


 

各ホスト マシン上のディスク ミラーリングのチェック

毎週


 

データベースおよびテーブルの監査

毎月


 

フィルタのクリーニング

機器製造業者のマニュアルを参照してください。

毎月


 

データベースのアーカイブ

システム管理者にお問い合せください。


 

ソフトウェア イメージのバックアップ

毎月


 

ヒープ使用量の確認

3 か月ごと


 

トランク グループに対する診断プロシージャの実行

「外部リソースの管理」を参照してください。

3 か月ごと


 

加入者の終端装置に対する診断プロシージャの実行

「外部リソースの管理」を参照してください。

3 か月ごと


 

NCS/MGCP エンドポイントのネットワーク ループバック テストの実行

機器製造業者のマニュアルを参照してください。

3 か月ごと


 

Numbering Resource Utilization/Forecast(NRUF) レポートの作成

6 か月ごと

BTS システム状態レポートの使用

BTS では、全体の状態についてデータを収集し、レポートを作成できます。このデータを使用して、ハードウェア障害やトラフィック輻輳などの問題を検出します。

 

表3-3 BTS システム状態レポートの使用

作業
サンプル コマンド

スケジュールしたレポートの表示

show scheduled-command verb=report; noun=system_health

ID 番号別のレポートの表示

show scheduled-command ID=1

レポートのスケジュール

add scheduled-command verb=report; noun=system_health; start-time=2003-10-01 12:22:22; recurrence=DAILY; keys=period; key-values=<1 ... 720>;
 

ここで、

start-time :BTS がレポートを作成する時刻(yyyy-mm-dd hh:mm:ssss)。

recurrence: レポートを実行する頻度(none(1 回限り)、daily、weekly、monthly)。

keys=period; key-values=<1 ...720>;: さかのぼってデータを収集する時間数。指定しない場合、BTS ではデフォルトの 24(過去 24 時間分のデータ)が使用されます。

レポートの変更

change scheduled-command id=881958666704177006; start-time=2003-10-01 14:14:14; recurrence=DAILY; keys=period; key-values=24;

レポートの削除

delete scheduled-command id=881958666704177006;

完了したレポートの表示

Web ブラウザで次のように入力します。

https://<アクティブな EMS のIP アドレスまたは FQDN>:/report/system_health

レポートの即時生成

report system-health period=<1 ... 720>;

BTS システム時刻のチェック

各クロックの時刻のずれは 2 秒以内である必要があります。


注意 CA、FS、EMS、および BDMS の実行中は、BTS ホスト マシンの日付または時刻を変更しないでください。その代わりに、Solaris OS が NTP サービスから自動的に時刻を取得できるようにしてください。


ステップ 1 プライマリ EMS とセカンダリ EMS の両方に、root としてログインします。

ステップ 2 <hostname># date と入力します。

ステップ 3 各 EMS で、次のことを確認します。

a. 時刻のずれが +/-2 秒以内である。

b. 日、月、年、時間帯が正しい。

ステップ 4 プライマリ CA とセカンダリ CA の両方に、root としてログインします。

ステップ 5 <hostname># date と入力します。

ステップ 6 各 CA で、次のことを確認します。

a. 時刻のずれが +/-2 秒以内である。

b. 日、月、年、時間帯が正しい。


 

各ホスト マシンの OS ログのチェック

4 つのすべてのホスト マシン(プライマリ EMS、セカンダリ EMS、プライマリ CA、セカンダリ CA)の OS ログを調べて、エラーや警告がないかを確認します。このレポートには、メモリ ヒット、ディスク エラー、頻繁なプロセス再起動など、最新のメッセージが示されます。


ステップ 1 root としてログインします。

ステップ 2 dmesg と入力します。

ステップ 3 より詳細な履歴を得るには、/var/adm/messages ファイルを編集します。


 

各ホスト マシン上のディスク ミラーリングのチェック

CA/FS サイド A

この手順を実行する前に、BTS プラットフォームがコントローラ 1 に接続されているか、コントローラ 0 に接続されているかを確認してください。


ステップ 1 Telnet を使用して、root として CA/FS サイド A にログインします。

ステップ 2 次のいずれかを入力します。

<hostname># metastat | grep c0
 

または

<hostname># metastat | grep c1
 

ステップ 3 返された結果が次の内容と一致することを確認します。

c1t0d0s1 0 No Okay Yes
c1t1d0s1 0 No Okay Yes
c1t0d0s5 0 No Okay Yes
c1t1d0s5 0 No Okay Yes
c1t0d0s6 0 No Okay Yes
c1t1d0s6 0 No Okay Yes
c1t0d0s0 0 No Okay Yes
c1t1d0s0 0 No Okay Yes
c1t0d0s3 0 No Okay Yes
c1t1d0s3 0 No Okay Yes
c1t1d0 Yes id1,sd@SSEAGATE_ST373307LSUN72G_3HZ9JG7800007518H8WV
c1t0d0 Yes id1,sd@SSEAGATE_ST373307LSUN72G_3HZ9JC9N00007518Y15K

結果が異なる場合は、次のコマンドでディスク ミラーリングを同期させます。

<hostname># cd /opt/setup
<hostname># sync_mirror

) これには約 30 分かかります。


ステップ 1 ~ ステップ 3 に従って結果を確認します。


注意 不一致が生じた場合は、一度同期化を行います。不一致が解消されない場合は、Cisco TAC にお問い合せください。


 

CA/FS サイド B


ステップ 1 Telnet を使用して、root として CA/FS サイド B にログインします。

ステップ 2 <hostname># metastat | grep c0 と入力します。

ステップ 3 返された結果が次の内容と一致することを確認します。

c0t0d0s6 0 No Okay
c0t1d0s6 0 No Okay
c0t0d0s1 0 No Okay
c0t1d0s1 0 No Okay
c0t0d0s5 0 No Okay
c0t1d0s5 0 No Okay
c0t0d0s7 0 No Okay
c0t1d0s7 0 No Okay
c0t0d0s0 0 No Okay
c0t1d0s0 0 No Okay
c0t0d0s3 0 No Okay
c0t1d0s3 0 No Okay
 

結果が異なる場合は、次のコマンドでディスク ミラーリングを同期させます。

<hostname># cd /opt/setup
<hostname># sync_mirror

) これには約 30 分かかります。


ステップ 1 ~ ステップ 3 に従って結果を確認します。


注意 不一致が生じた場合は、一度同期化を行います。不一致が解消されない場合は、Cisco TAC にお問い合せください。


 

EMS サイド A


ステップ 1 Telnet を使用して、root として EMS サイド A にログインします。

ステップ 2 <hostname># metastat | grep c0 と入力します。

ステップ 3 返された結果が次の内容と一致することを確認します。

c0t0d0s6 0 No Okay
c0t1d0s6 0 No Okay
c0t0d0s1 0 No Okay
c0t1d0s1 0 No Okay
c0t0d0s5 0 No Okay
c0t1d0s5 0 No Okay
c0t0d0s7 0 No Okay
c0t1d0s7 0 No Okay
c0t0d0s0 0 No Okay
c0t1d0s0 0 No Okay
c0t0d0s3 0 No Okay
c0t1d0s3 0 No Okay
 

結果が異なる場合は、次のコマンドでディスク ミラーリングを同期させます。

<hostname># cd /opt/setup
<hostname># sync_mirror
 

) これには約 30 分かかります。


ステップ 1 ~ ステップ 3 に従って結果を確認します。


注意 不一致が生じた場合は、一度同期化を行います。不一致が解消されない場合は、Cisco TAC にお問い合せください。


 

EMS サイド B


ステップ 1 Telnet を使用して、root として EMS サイド B にログインします。

ステップ 2 <hostname># metastat | grep c0 と入力します。

ステップ 3 返された結果が次の内容と一致することを確認します。

c0t0d0s6 0 No Okay
c0t1d0s6 0 No Okay
c0t0d0s1 0 No Okay
c0t1d0s1 0 No Okay
c0t0d0s5 0 No Okay
c0t1d0s5 0 No Okay
c0t0d0s7 0 No Okay
c0t1d0s7 0 No Okay
c0t0d0s0 0 No Okay
c0t1d0s0 0 No Okay
c0t0d0s3 0 No Okay
c0t1d0s3 0 No Okay
 

結果が異なる場合は、次のコマンドでディスク ミラーリングを同期させます。

<hostname># cd /opt/setup
<hostname># sync_mirror
 

) これには約 30 分かかります。


ステップ 1 ~ ステップ 3 に従って結果を確認します。


注意 不一致が生じた場合は、一度同期化を行います。不一致が解消されない場合は、Cisco TAC にお問い合せください。


 

データベースおよびテーブルの監査

データベース全体、または Oracle データベースと共有メモリ内のプロビジョニング可能なすべてのテーブルのエントリを監査します。『Cisco BTS 10200 Softswitch Troubleshooting Guide』を参照してください。


注意 監査には時間がかかります。メンテナンス ウィンドウ以外では行わないでください。完了時間は、データベースまたはテーブルのエントリの数によって異なります。

 

表3-4 データベースおよびテーブルの監査

作業
サンプル コマンド

個々のテーブルの監査

audit trunk type=row-count;

プロビジョニング可能な各テーブルのすべてのエントリ の監査

audit database;
 

タイプ に基づいた、プロビジョニング可能なテーブルの監査

audit database type=row-count;

) type のデフォルトは full です。


プラットフォームの状態 に基づいた、プロビジョニング可能なテーブルの監査

audit database platform-state=active;

) platform-state のデフォルトは active です。


ネットワーク要素間の不一致の監査

1. root としてログインします。

2. 次のように入力します。

bts_audit -ems priems01 -ca prica01 -platforms CA146,FSAIN205 -tables SUBSCRIBER,MGW_PROFILE
 

) bts_audit は、終端レコードが無効な MGW を指している場合など、特定のシナリオでは機能しません。


ネットワーク要素間の不一致の解消

テーブルが、存在しない行を参照している場合、不一致は解消されません。アクティブなネットワーク要素間のデータ不一致だけを同期させます。

1. bts_audit を使用して、不一致を監査します。

2. 次のように入力します。

bts_sync /opt/ems/report/Audit_CA146_root.sql
bts_sync applies updates directly to the databases.

Numbering Resource Utilization/Forecast(NRUF) レポートの作成

North American Numbering Plan Association(NANPA)は、19 か国における電話番号の使用に関する情報を収集、保存、保守しています。電話番号を保持している通信事業者などの企業は、NRUF レポートという形で NANPA に年 2 回報告を行う必要があります。レポートの提出に関する詳細とサポートについては、http://www.nanpa.com を参照してください。

BTS は、Number Block テーブルを使用して NRUF レポートを作成します。このテーブルの特徴は、次のとおりです。

NANPA 監査の唯一の参考資料となる単一のテーブルです。

カスタマイズ可能です。

他のテーブルからインポートしたデータによる更新、オフィスコードの更新による変更に基づく更新、または手動での更新が可能です。

次のフィールドがあります。

Number Block: NPA to NPA-NXX-XXXX:FCC による NANPA 監査要件に準拠するため、レポートの入力は NPANXX になります。NANPA の管轄外の市場では、National Destination Code(NDC; 国内宛先コード)と Exchange Code(EC; 交換局コード)を連結したものに基づくか、EC だけに基づいて入力を行うことができます。

Code Holder = Y/N

Block Holder = Y/N

Native = Y/N

Non-Native = Y/N

次の各種レポートを生成するには、report dn-summary を使用します。

NDC および EC 内のすべての DN

NDC および EC 内の 1000 番単位のグループ

Operating Company Number(OCN; 通信事業者番号)

スイッチ Common Language Location Identifier(CLLI)コード

OCN + CLLI コード:エントリは LERG データと一致する必要があります。

地方以外の第一次通信事業者および中間通信事業者のレポートの作成

地方以外の第一次通信事業者および中間通信事業者の NRUF レポートの特徴は、次のとおりです。

1000 番単位のブロック レベル(NPA-NXX-X)で実行される。

NANP のみに適用される。

レポートは、DN2SUBSCRIBER テーブルの STATUS トークンに基づいて次のデータを返します。

 

表3-5 地方以外の通信事業者の NRUF レポート データ

データ グループ
DN2SUBSCRIBER テーブルからの一致データ

割り当てられた DN

個々の DN:

ndc=<npa>; ec=<nxx>; DN=[0-9][0-9][0-9]; (status=assigned) AND ADMIN-DN=N
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9][0-9]; (status=ported-out) AND ADMIN-DN=N

DID DN:

ndc=<npa>; ec=<nxx>; DN=xxxx; (status=assigned) AND ADMIN-DN=N; X 10000
ndc=<npa>; ec=<nxx>; DN=xxxx; (status=ported-out) AND ADMIN-DN=N; X 10000
 
ndc=<npa>; ec=<nxx>; DN=[0-9]xxx; (status=assigned) AND ADMIN-DN=N; X 1000
ndc=<npa>; ec=<nxx>; DN=[0-9]xxx; (status=ported-out) AND ADMIN-DN=N; X 1000
 
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9]xx; (status=assigned) AND ADMIN-DN=N; X 100
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9]xx; (status=ported-out) AND ADMIN-DN=N; X 100
 
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9][0-9]x; (status=assigned) AND ADMIN-DN=N; X 10
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9][0-9]x; (status=ported-out) AND ADMIN-DN=N; X 10
 

PORTED-OUT DN

中間の電話番号

0

予約されている DN

0

エージング DN

DISC DN:

ndc=<npa>; ec=<nxx>; DN=[0-9][0-9][0-9][0-9]; (status=DISC)
 

変更番号 DN:

ndc=<npa>; ec=<nxx>; DN=[0-9][0-9][0-9][0-9]; (status=CN)
 

DISC DID DN:

ndc=<npa>; ec=<nxx>; DN=xxxx; (status=DISC) X 10000
ndc=<npa>; ec=<nxx>; DN=[0-9]xxx; (status=DISC) X 1000
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9]xx; (status=DISC) X 100
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9][0-9]x; (status=DISC) X 10
 

変更番号 DID DN:

ndc=<npa>; ec=<nxx>; DN=xxxx; (status=CN) X 10000
ndc=<npa>; ec=<nxx>; DN=[0-9]xxx; (status=CN) X 1000
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9]xx; (status=CN) X 100
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9][0-9]x; (status=CN) X 10

管理 DN

管理 DN:

ndc=<npa>; ec=<nxx>; status=LRN;
ndc=<npa>; ec=<nxx>; status=CLRN
ndc=<npa>; ec=<nxx>; status=RACF-DN;
ndc=<npa>; ec=<nxx>; status=ANNC;
ndc=<npa>; ec=<nxx>; status=TEST-LINE;
 
ndc=<npa>; ec=<nxx>; (ADMIN-DN=Y AND (status=ASSIGNED))
ndc=<npa>; ec=<nxx>; (ADMIN-DN=Y AND (status=PORTED-OUT))
 

管理 DID DN:

ndc=<npa>; ec=<nxx>; DN=xxxx; (ADMIN-DN=Y AND (status=ASSIGNED)) X 10000
ndc=<npa>; ec=<nxx>; DN=xxxx; (ADMIN-DN=Y AND (status=PORTED-OUT)) X 10000
ndc=<npa>; ec=<nxx>; DN=[0-9]xxx (ADMIN-DN=Y AND (status=ASSIGNED)) X 1000
ndc=<npa>; ec=<nxx>; DN=[0-9]xxx (ADMIN-DN=Y AND (status=PORTED-OUT)) X 1000
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9]xx; (ADMIN-DN=Y AND (status=ASSIGNED)) X 100
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9]xx; (ADMIN-DN=Y AND (status=PORTED-OUT)) X 100
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9][0-9]x; (ADMIN-DN=Y AND (status=ASSIGNED)) X 10
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9][0-9]x; (ADMIN-DN=Y AND (status=PORTED-OUT)) X 10

変更番号管理 DN

地方の第一次通信事業者および中間通信事業者のレポートの作成

この項では、サービス プロバイダーがコード保有者である場合に、NPA-NXX レベルで報告する DN 情報について説明します。「ndc, ec」レベルの NRUF レポートには、さまざまな長さの dn-group が含まれます。国によっては、長さが 1、2、3、または 4 の dn-group がサポートされています。

Rural Primary Carrier(U2 様式)NPA-NXX レポートには、次の内容が含まれます。

NPA-NXX(ndc, ec として入力)

レート センター(LERG から読み取り)

州(LERG から読み取り)

割り当てられた DN の数

中継 DN の数

予約されている DN の数

エージング DN の数

管理 DN の数

プールに割り当て(常に 0)

Rural Intermediate Carrier(U4 様式)レポートには、次の内容が含まれます。

NPA-NXX(ndc, ec として入力)

レート センター(LERG から読み取り)

州(LERG から読み取り)

割り当てられた DN の数

中継 DN の数

予約されている DN の数

エージング DN の数

管理 DN の数

受け取った番号(常に 0)

レポートは、DN2SUBSCRIBER テーブルの STATUS トークンに基づいて次のデータを返します。

 

表3-6 地方の通信事業者の NRUF レポート データ

データ グループ
DN2SUBSCRIBER テーブルからの一致データ

割り当てられた DN

個々の DN:

ndc=<npa>; ec=<nxx>; DN=[0-9][0-9][0-9]; (status=assigned) AND ADMIN-DN=N
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9][0-9]; (status=ported-out) AND ADMIN-DN=N
 

DID DN:

ndc=<npa>; ec=<nxx>; DN=xxxx; (status=assigned) AND ADMIN-DN=N; X 10000
ndc=<npa>; ec=<nxx>; DN=xxxx; (status=ported-out) AND ADMIN-DN=N; X 10000
 
ndc=<npa>; ec=<nxx>; DN=[0-9]xxx; (status=assigned) AND ADMIN-DN=N; X 1000
ndc=<npa>; ec=<nxx>; DN=[0-9]xxx; (status=ported-out) AND ADMIN-DN=N; X 1000
 
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9]xx; (status=assigned) AND ADMIN-DN=N; X 100
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9]xx; (status=ported-out) AND ADMIN-DN=N; X 100
 
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9][0-9]x; (status=assigned) AND ADMIN-DN=N; X 10
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9][0-9]x; (status=ported-out) AND ADMIN-DN=N; X 10

中間の電話番号

0

予約されている DN

0

エージング DN

DISC DN:

ndc=<npa>; ec=<nxx>; DN=[0-9][0-9][0-9][0-9]; (status=DISC)
 

変更番号 DN:

ndc=<npa>; ec=<nxx>; DN=[0-9][0-9][0-9][0-9]; (status=CN)

DISC DID DN:

ndc=<npa>; ec=<nxx>; DN=xxxx; (status=DISC) X 10000
ndc=<npa>; ec=<nxx>; DN=[0-9]xxx; (status=DISC) X 1000
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9]xx; (status=DISC) X 100
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9][0-9]x; (status=DISC) X 10
 

変更番号 DID DN:

ndc=<npa>; ec=<nxx>; DN=xxxx; (status=CN) X 10000
ndc=<npa>; ec=<nxx>; DN=[0-9]xxx; (status=CN) X 1000
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9]xx; (status=CN) X 100
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9][0-9]x; (status=CN) X 10

管理 DN

管理 DN:

ndc=<npa>; ec=<nxx>; status=LRN;
ndc=<npa>; ec=<nxx>; status=CLRN
ndc=<npa>; ec=<nxx>; status=RACF-DN;
ndc=<npa>; ec=<nxx>; status=ANNC;
ndc=<npa>; ec=<nxx>; status=TEST-LINE;
 
ndc=<npa>; ec=<nxx>; (ADMIN-DN=Y AND (status=ASSIGNED))
ndc=<npa>; ec=<nxx>; (ADMIN-DN=Y AND (status=PORTED-OUT))
 

管理 DID DN:

ndc=<npa>; ec=<nxx>; DN=xxxx; (ADMIN-DN=Y AND (status=ASSIGNED)) X 10000
ndc=<npa>; ec=<nxx>; DN=xxxx; (ADMIN-DN=Y AND (status=PORTED-OUT)) X 10000
ndc=<npa>; ec=<nxx>; DN=[0-9]xxx (ADMIN-DN=Y AND (status=ASSIGNED)) X 1000
ndc=<npa>; ec=<nxx>; DN=[0-9]xxx (ADMIN-DN=Y AND (status=PORTED-OUT)) X 1000
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9]xx; (ADMIN-DN=Y AND (status=ASSIGNED)) X 100
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9]xx; (ADMIN-DN=Y AND (status=PORTED-OUT)) X 100
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9][0-9]x; (ADMIN-DN=Y AND (status=ASSIGNED)) X 10
ndc=<npa>; ec=<nxx>; DN=[0-9][0-9][0-9]x; (ADMIN-DN=Y AND (status=PORTED-OUT)) X 10

ソフトウェア イメージのバックアップ

この手順には、次の作業が含まれます。

「全面的なデータベース監査」

「共有メモリのチェック」

「BTS 全体のバックアップ」

全面的なデータベース監査


ステップ 1 CLI ユーザとして EMS サイド A にログインします。

ステップ 2 audit database type=full; と入力します。

ステップ 3 監査レポートを調べて、不一致やエラーがないことを確認します。エラーがあった場合は、エラーの修正を試行してください。修正できない場合は、Cisco TAC にお問い合せください。


 

共有メモリのチェック

この作業では、共有メモリをチェックして潜在的なデータ問題を検出します。

CA/FS サイド A での作業


ステップ 1 root としてログインします。

ステップ 2 次のように入力します。

<hostname># cd /opt/OptiCall/CAxxx/bin
<hostname># ca_tiat data
 

Enter キーを押します。

結果は次の内容と一致する必要があります。

All tables are OK.
For details, see ca_tiat.out
 

注意 結果に「All tables are OK」と示されていない場合は、作業をやめてただちに Cisco TAC にお問い合せください。結果に「All tables are OK」と示された場合は、ステップ 3 に進みます。

ステップ 3 次のように入力します。

<hostname># cd /opt/OptiCall/FSPTCzzz/bin <Return>
<hostname># potsctx_tiat data <Return>
 

Enter キーを押します。

結果は次の内容と一致する必要があります。

All tables are OK.
For detail, see potsctx_tiat.out
 

注意 結果に「All tables are OK」と示されていない場合は、作業をやめてただちに Cisco TAC にお問い合せください。結果に「All tables are OK」と示された場合は、ステップ 4 に進みます。

ステップ 4 次のように入力します。

<hostname>#cd /opt/OptiCall/FSAINyyy/bin
<hostname>#ain_tiat data
 

ステップ 5 Enter キーを押します。

結果は次の内容と一致する必要があります。

All tables are OK.
For detail, see ain_tiat.out
 

注意 結果に「All tables are OK」と示されていない場合は、作業をやめてただちに Cisco TAC にお問い合せください。


 

CA/FS サイド B での作業


ステップ 1 root としてログインします。

ステップ 2 次のように入力します。

<hostname>#cd /opt/OptiCall/CAxxx/bin
<hostname>#ca_tiat data
 

ステップ 3 Enter キーを押します。

結果は次の内容と一致する必要があります。

All tables are OK.
For detail, see ca_tiat.out
 

注意 結果に「All tables are OK」と示されていない場合は、作業をやめてただちに Cisco TAC にお問い合せください。結果に「All tables are OK」と示された場合は、ステップ 3 に進みます。

ステップ 4 次のように入力します。

<hostname>#cd /opt/OptiCall/FSPTCzzz/bin
<hostname>#potsctx_tiat data

ステップ 5 Enter キーを押します。

結果は次の内容と一致する必要があります。

All tables are OK.
For detail, see potsctx_tiat.out
 

注意 結果に「All tables are OK」と示されていない場合は、作業をやめてただちに Cisco TAC にお問い合せください。結果に「All tables are OK」と示された場合は、ステップ 6 に進みます。

ステップ 6 次のように入力します。

<hostname>#cd /opt/OptiCall/FSAINyyy/bin
<hostname>#ain_tiat data

ステップ 7 Enter キーを押します。

結果は次の内容と一致する必要があります。

All tables are OK.
For detail, see ain_tiat.out
 

注意 結果に「All tables are OK」と示されていない場合は、作業をやめてただちに Cisco TAC にお問い合せください。


 

BTS 全体のバックアップ

この作業は、ソフトウェアのアップグレード前後または日常的に、必ずメンテナンス ウィンドウ内で行います。プロビジョニング プロセスを開始する前に、次のものが用意されていることを確認します。

 

プロビジョニング前のチェックリスト。


 

NFS サーバのホスト名または IP アドレス。


 

NFS サーバからの共有ディレクトリ。


 

ルートユーザのアクセス


 

ブロックされているプロビジョニング

CA/FS のバックアップ

次の手順を実行して、セカンダリ CA/FS をバックアップします。その後、この手順をプライマリ CA/FS に対して繰り返します。


ステップ 1 セカンダリ CA/FS にroot としてログインします。

ステップ 2 すべてのプラットフォームが STANDBY モードであることを確認します。<hostname>#nodestat と入力します。

ステップ 3 /opt/Build やアプリケーション tar ファイルなど、不要なファイルやディレクトリを削除します。

ステップ 4 NFS サーバを /mnt ディレクトリにマウントします。<hostname>#mount <nfs server ip or hostname>:/<share dire> /mnt と入力します。

ステップ 5 すべてのプラットフォームを停止します。<hostname>#platform stop all と入力します。

ステップ 6 すべてのプラットフォームのデータ ディレクトリ(共有メモリ)を NFS サーバに保存します。

<hostname>#tar -cf - /opt/OptiCall/CAxxx/bin/data |gzip -fast - > /mnt/data.<hostname>.CA
<hostname>#tar -cf - /opt/OptiCall/FSAINxxx/bin/data |gzip -fast - > /mnt/data.<hostname>.FSAIN
<hostname>#tar -cf /opt/OptiCall/FSPTCxxx/bin/data |gzip -fast - > /mnt/data.<hostname>.FSPTC

ここで、xxx はインスタンス番号です。

ステップ 7 すべてのプラットフォームを起動します。<hostname>#platform start と入力します。

ステップ 8 すべてのプラットフォームが STANDBY モードであることを確認します。<hostname>#nodestat と入力します。

ステップ 9 フラッシュ アーカイブ用の除外ディレクトリ ファイルを作成します。次のように入力します。

<hostname>#vi /tmp/excluded_dir
/opt/OptiCall/CAxxx/bin/data
/opt/OptiCall/CAxxx/bin/logs
/opt/OptiCall/FSAINxxx/bin/data
/opt/OptiCall/FSAINxxx/bin/logs
/opt/OptiCall/FSPTCxxx/bin/data
/opt/OptiCall/FSPTCxxxx/bin/logs
 

ここで、xxx はインスタンス番号です。

ステップ 10 システムをバックアップします。次のように入力します。

<hostname>#mv /bin/date /bin/date.archive
<hostname>#mv /bin/.date /bin/date
<hostname>#flarcreate -n <hostname> -X /tmp/excluded_dir -c /mnt/<hostname>.archive
<hostname>#mv /bin/date /bin/.date
<hostname>#mv /bin/date.archive /bin/date
 

ステップ 11 NFS サーバをアンマウントします。次のように入力します。

<hostname>#umount /mnt
 

ステップ 12 アクティブな EMS から、すべてのプラットフォームをスイッチオーバーします。次のように入力します。

<hostname>#ssh optiuser@<hostname>
cli>control feature-server id=FSAINxxx;target-state=standby-active;
cli>control feature-server id=FSPTCxxx;target-state=standby-active;
cli>control call-agent id=CAxxx;target-state=standby-active;
 

ここで、xxx は各プラットフォームのインスタンス番号です。

ステップ 13 この手順を、プライマリ CA/FS に対して繰り返します。


 

EMS/BDMS のバックアップ

次の手順を実行して STANDBY EMS/BDMS システムをバックアップします。


ステップ 1 root としてログインします。

ステップ 2 すべてのプラットフォームが STANDBY モードであることを確認します。<hostname>#nodestat と入力します。

ステップ 3 /opt/Build やアプリケーション tar ファイルなど、不要なファイルやディレクトリを削除します。

ステップ 4 NFS サーバを /mnt ディレクトリにマウントします。<hostname>#mount <nfs server ip or hostname>:/<share dire> /mnt と入力します。

ステップ 5 すべてのプラットフォームを停止します。<hostname>#platform stop all と入力します。

ステップ 6 Oracle データベースと MySQL ディレクトリを保存します。次のように入力します。

<hostname>#tar -cf - /data1/oradata |gzip -fast - >/mnt/oradata.<hostname>
<hostname>#tar -cf - /opt/ems/db |gzip -fast - >/mnt/db.<hostname>
 

ステップ 7 フラッシュ アーカイブ用の除外ディレクトリ ファイルを作成します。次のように入力します。

<hostname>#vi /tmp/excluded_dir
/data1/oradata
 

ステップ 8 すべてのプラットフォームを起動します。<hostname>#platform start と入力します。

ステップ 9 すべてのプラットフォームが STANDBY モードであることを確認します。<hostname>#nodestat と入力します。

ステップ 10 システムをバックアップします。次のように入力します。

<hostname>#mv /bin/date /bin/date.archive
<hostname>#mv /bin/.date /bin/date
<hostname>#flarcreate -n <hostname> -X /tmp/excluded_dir -c /mnt/<hostname>.archive
<hostname>#mv /bin/date /bin/.date
<hostname>#mv /bin/date.archive /bin/date
 

ステップ 11 NFS サーバをアンマウントします。<hostname>#umount /mnt と入力します。

ステップ 12 アクティブな EMS から、すべてのプラットフォームをスイッチオーバーします。次のように入力します。

<hostname>#ssh optiuser@<hostname>
cli>control bdms id=BDMS01;target-state=standby-active;
cli>control element-manager id=EM01;target-state=standby-active;

ステップ 13 ステップ 3 以降を繰り返して、PRIMARY EMS/BDMS をバックアップします。


 

EMS データベースのバックアップ

この手順は、上級の UNIX ユーザを対象としています。この手順では、EMS のプロビジョニング データベースをリモート サーバに保存する方法を説明します。リモート サーバは次の条件を満たしている必要があります。

企業 LAN に接続されている。

バックアップが毎日行われている: インストール時のデフォルトでは、毎日のホット バックアップはオンになっていません。

バックアップ プロセスは次のとおりです。

ora_hot_backup.ks:データベース データ ファイル、制御ファイル、およびアーカイブ ログをバックアップします。

ora_arch_backup.ksh:アーカイブ ログをバックアップします。

プライマリ EMS システム上およびセカンダリ EMS システム上のターゲット バックアップ ディレクトリは、どちらも /opt/oraback です。/opt/oraback ディレクトリ内のバックアップ ファイルは、リモート FTP サイトの /opt/backup ディレクトリに後で転送されます。リモート FTP サイトへの転送後、ファイルは /opt/oraback から除去されます。


ステップ 1 バックアップの前に、プライマリ EMS とセカンダリ EMS のデータベースを二重に確認します。


注意 ora_hot_backup.ksh および ora_arch_backup.ksh をスケジュールする前に、二重確認を行ってください。これにより、データベースとアーカイブされたログ ファイルが RMAN プロセスに適していることが検証されます。

a. oracle または su - oracle としてログインします。

b. dbadm -E backup_crosscheck と入力します。

c. ログ ファイルにエラーがないことを確認します。ただし、「validation failed for archived log」というメッセージはあってもかまいません。/data1/arch/opticalx_yyy.arc ファイルのこれらのメッセージは無視してください。検証によって、RMAN は *.arc ファイルを検索しないよう誘導されます。ora_purge_archlog.ksh で、 *.arc ファイルは除去されます。

RMAN-06157: validation failed for archived log
RMAN-08514: archivelog filename=/data1/arch/optical1_25.arc recid=1 stamp=461878656
 

ステップ 2 アーカイブ ログの除去プロセスを削除し、バックアップ プロセスをスケジュールします。


) この操作を、プライマリ EMS とセカンダリ EMS の両方で実行します。


a. ora_purge_archlog.ksh プロセスをディセーブルにします。

b. ora_hot_backup.ksh プロセスをイネーブルにします。

c. オプション:ora_arch_backup.ksh プロセスをイネーブルにします。

d. oracle または su - oracle としてログインします。

e. crontab -e と入力します。

f. crontab ファイルを次のように変更します。これは、プライマリ EMS サイトで行います。データベース名は optical1 です。

 
# Daily Oracle Hot backup - this also include archive log backup
# Note: Set hot backup process to run at 2:00am every day.
#
0 2 * * * /opt/oracle/admin/scripts/ora_hot_backup.ksh optical1 > /opt/oracle/t
mp/ora_hot_backup.log 2>&1
#
# Oracle archive log backups, in addition to daily hot backup.
# Note: Set one additional archive log backup to run at 6:00pm every day.
#
0 18 * * * /opt/oracle/admin/scripts/ora_arch_backup.ksh optical1 > /opt/
oracle/tmp/ora_arch_backup.log 2>&1
#
# Purge archive log files
# Note: Delete or uncomment this line to stop purging archive log files.
#
#0 1,3,...,23 * * * /opt/oracle/admin/scripts/ora_purge_archlog.ksh optical1 > /opt/oracle/tmp/ora_purge_archlog.log 2>&1
 

g. optical1 optical2 に置き換え、セカンダリ EMS サイトでcrontab ファイルを次のように変更します。これは、プライマリ EMS サイトで行います。データベース名は optical1 です。 を繰り返します。

ステップ 3 リモート FTP サイトを設定します。

a. oracle ユーザ アクセスを確認し、FTP サーバ サイト上にバックアップ ディレクトリを作成します。

Primary EMS hostname: priems
Secondary EMS hostname: secems
FTP server hostname: ftpserver
FTP server Oracle password: ora00
FTP server backup directory: /opt/backup
 

最初に、oracle ユーザ アクセスを使用して、リモート FTP サーバへの接続をテストします。oracle のパスワードが「ora00」でない場合は、/opt/oracle/admin/etc/dba.env ファイル内の ORA_PW 変数を更新します。

b. 次のコマンドをプライマリ EMS とセカンダリ EMS の両方で実行します。

telnet ftpserver
 

c. oracle としてログインし、パスワード(この場合 ora00)を入力します。

d. /opt/backup ディレクトリを作成します。このディレクトリに対する書き込み権限が oracle ユーザに与えられていることを確認します。

mkdir /opt/backup
 

) FTP サーバの /opt/backup ディレクトリからテープ デバイスまたは企業向けテープ ライブラリにバックアップ ファイルをアーカイブすることは、ユーザの責任で行う必要があります。


ステップ 4 FTP プロセスをスケジュールします。

a. 次のコマンドをプライマリ EMS とセカンダリ EMS の両方で実行します。

oracle または su - oracle としてログインし、 crontab -e コマンドを入力します。

b. 次の行をプライマリ EMS の Oracle crontab に追加します。

#
# FTP backup files from primary (optical1) to /opt/backup directory of ftpserver.
#
0 6 * * * /opt/oracle/admin/scripts/ora_ftp_backup.ksh optical1 ftpserver /opt/backup > /opt/oracle/tmp/ora_ftp_backup.log 2>&1
 

c. ftpserver を、リモート FTP サーバの正しいホスト名に置き換えます。/opt/backup が正しくない場合は、正しいディレクトリ名に置き換えます。


0 6 *** /opt/oracle/admin/scripts/ora_ftp_backup.ksh ......... ora_ftp_backup.log 2>&1 は、1 行に入力する必要があります。


d. セカンダリ EMS の oracle crontab を編集し、 optical1 optical2 に置き換えます。

ステップ 5 バックアップ ファイルを確認します。次のように入力します。

cd /opt/oraback  EMS systems
cd /opt/backup  Remote FTP system


 

データベースのアーカイブ


ステップ 1 root としてログインします。

ステップ 2 すべてのプラットフォームを停止します。これがプライマリ ノードである場合は、CLI コマンドを使用して STANDBY-FORCED-ACTIVE に制御します。

ステップ 3 /var/yp が存在することを確認します。ls -l /var/yp と入力します。

上記のようなファイルまたはディレクトリは存在しないという結果が出力された場合は、mkdir -p /var/yp と入力します。

ステップ 4 NFS サーバをマウントします。mount <nfsserver hostname/ip>:/<share directory> /mnt と入力します。例:

mount 10.89.183.253:/opt/archive /mnt
 

ステップ 5 すべてのインターフェイスをバックアップします。tar -cvf /mnt/<local_hostname>.tar host* と入力します。例:

<hostname>#tar -cvf bts-prica.tar host.*
 

ステップ 6 Solaris の「date」コマンドを復元して、システムのフラッシュ アーカイブを作成します。次のように入力します。

mv /bin/date /bin/date.orig
mv /bin/.date /bin/date
 

ステップ 7 アーカイブを作成します。<hostname>#flarcreate -n <archive name> -x /opt -S -c /mnt/<file name> と入力します。


) アーカイブ名の例:flarcreate -n CCPU-EMS -x /opt -S -c /mnt/secems04.archive


ステップ 8 /opt ディレクトリをバックアップします。
tar -cvf - /opt/* |gzip -c >/opt/<hostname_release>.tar.gz と入力します。

ステップ 9 元の設定を復元します。次のように入力します。

mv /bin/date /bin/.date
mv /bin/date.orig /bin/date
 

ステップ 10 NFS サーバをアンマウントします。umount /mnt と入力します。


 

ヒープ使用量の確認

ヒープとは、アプリケーションの実行時に生成するデータ用に BTS が確保しているメモリのことです。BTS は、CA、AIN、POTS、EMS、および BDMS の各プラットフォームによって開始されたすべてのプロセスのヒープ使用量を監査します。ヒープの監査は、ADP プロセスに追加されます。

1 つのプロセスのヒープ使用量が特定のしきい値レベルを上回ると、BTS はアラームを生成します。ヒープ使用量がしきい値レベルを下回ると、アラームはクリアされます。

ヒープの監査では、次のことを実行します。

プロセスごとに、最新 4 期のヒープ使用量のトレースを監視します。

プラットフォームによって開始された各プロセスのヒープ使用量を、1 日 1 回午後 4 時に測定します。

1 つのプロセスのヒープ使用量が最大ヒープ サイズ制限の 70% を上回った場合、マイナー アラームを発行します。

1 つのプロセスのヒープ使用量が最大ヒープ サイズ制限の 68% を下回った場合、マイナー アラームをクリアします。

1 つのプロセスのヒープ使用量が最大ヒープ サイズ制限の 80% を上回った場合、メジャー アラームを発行します。

1 つのプロセスのヒープ使用量が最大ヒープ サイズ制限の 78% を下回った場合、メジャー アラームをクリアします。

1 つのプロセスのヒープ使用量が最大ヒープ サイズ制限の 90% を上回った場合、クリティカル アラームを発行します。

1 つのプロセスのヒープ使用量が最大ヒープ サイズ制限の 88% を下回った場合、クリティカル アラームをクリアします。

トレース ログで、最新 20 個のヒープ測定値を報告します。これには、時刻と各プロセスの値が含まれます。

プロセスの再起動時に、ヒープ使用量アラームをクリアします。

DNS サーバのチェック

すべてのノードに対して次の手順を実行します。


ステップ 1 アクティブ CA に root としてログインします。

ステップ 2 more /etc/resolv.conf と入力します。

nameserver <ip address> をメモに記録します。

ステップ 3 nslookup と入力します。

このデフォルトは、最初の DNS サーバです。

ステップ 4 有効なゲートウェイ名を入力し、Enter キーを押します。

ゲートウェイに関連付けられている IP アドレスが表示されます。

ステップ 5 server <second dns server ip> と入力します。

ステップ 6 有効なゲートウェイ名を入力し、Enter キーを押します。

ゲートウェイに関連付けられている IP アドレスが表示されます。

ステップ 7 exit と入力して終了します。