リリース2.2.xソフトウェアを実行するOptical Network System(ONS)15454では、ユーザがリリース2.2.2または3.0へのソフトウェアアップグレードを実行できるようになりました。この最初の問題では、これらのソフトウェアアップグレードを完了するために必要なすべての手順を説明します。
この一番上の問題のアップグレードの前提条件、アップグレード前、およびアップグレード後のセクションは、リリース2.2.2と3.0の両方のソフトウェアアップグレードに共通です。アップグレードセクションでは、リリース2.2.2と3.0の両方のアップグレード手順について説明します。
注意:新しいシステムをインストールする場合は、リリース3.0.0を推奨します。一般的にGreenfieldアプリケーションと呼ばれるものだけを使用してください。ONS 15454リリース2.2.xから3.0.0にアップグレードすると、ノードでプロビジョニングの変更が実行された後、アップグレードプロセスの後にノードがリセットされる可能性のある状態が発生する可能性があります。テスト中に、アップグレードされたシステムの2 %未満でこの状態が発生しました。ノードがこの状態になると、トラフィックがプロビジョニングされた回線に影響を与える可能性があります。ノードをリリース3.0.0にアップグレードする場合は、メンテナンスウィンドウ内でアップグレードを実行し、「新しいソフトウェアレベルのアクティブ化」セクションのステップ9の後の注意点に従います。
次の項では、アップグレードに必要なハードウェアおよびソフトウェアの設定前提条件について詳しく説明します。各セクションで作業を進め、すべての基準を満たしていることを確認します。
次のフローチャートを使用して、アップグレードの前提条件の手順を確認してください。
ソフトウェアのアップグレードには、次のハードウェアおよびソフトウェアコンポーネントが最低限必要です。
486以上のプロセッサを搭載したIBM互換PCを使用するWindowsワークステーション。
CD ROMドライブ、およびWindows 95、Windows 98、Windows 2000、またはWindows NTを実行する128 MBランダムアクセスメモリ(RAM)
10baseTイーサネットネットワークインターフェイスカード(NIC)およびイーサネットケーブル(TCC+に接続するにはCAT 5 10baseTパッチケーブルを使用)を使用して、ONS 15454に直接接続します。 PCを15454に直接接続する方法の詳細については、「Cisco ONS 15454 TCCカードへのPC直接接続のトラブルシューティング」の一番上の問題を参照してください。
Netscape Navigator 4.08以降、Netscape Communicator 4.61以降、Internet Explorer 4.0 Service Pack 2以降を使用するブラウザソフトウェア。Netscape Navigatorは、ノードに同梱されているONS 15454ソフトウェアCDに含まれています。
Java ™ Policy File and Java Runtime Environment(JRE)ファイル(ONS 15454ソフトウェアCDに収録)。 CDをお持ちでない場合は、Java ™ WebサイトからJREソフトウェアをダウンロードできます。リリース3.0 Java Runtime Environment(JRE)ファイルでは、リリース1.2.2_005以降が必要です。
CTCリリース2.2.xを実行するワークステーションのTransmission Control Protocol/Internet Protocol(TCP/IP)ネットワークプロパティを設定する場合は、ドメインネームサービス(DNS)およびWindows Internet Naming Service(WINS)が無効になっていることを確認します。WINS解決はほとんど使用されませんが、DNSは一般的に企業ネットワークで使用されます。DNSが有効な場合、CTCがハングし、すべてのネットワークノードでロックアップを修正するためにTiming Communications A dn Control(TCC+)側スイッチが必要になります。
DNSとWINSの設定を無効にする方法の詳細については、『ONS 15454ユーザーマニュアル』の「PCをONS 15454に接続する方法」のステップ4を参照してください。
CTCを実行しているワークステーション上の他のすべてのイーサネットデバイス(ダイヤルアップアダプタなど)を無効にします。ワークステーションに複数のIPアドレスがある場合は、それらを削除する必要があります。複数のIPアドレスが実行されている場合、CTCリリース2.2.2をインストールすることはできません。
同じIPサブネットに複数のONS 15454ノードが設定されている場合、1つのルータに接続できるのは1つだけです。そうしないと、残りのノードが到達不能になる可能性があります。IP接続に関する推奨事項については、『15454でのIPアドレッシングとスタティックルートに関する一般的な問題』の「15454での一般的なIPアドレッシングのシナリオ」セクションを参照してください。
フロントパネルのイーサネットインターフェイスは、リリース2.2.xで変更されています。バックプレーン上の永続的ワイヤラップLAN接続は、TCC(AまたはB)がアクティブか、前面パネルのTCC接続が使用されている場合に、ノードと通信します。リリース2.2.0以降を使用している場合、アクティブなポートに関係なく、TCC+ RJ-45ポートのいずれかを介して接続できます。
PCを15454に直接接続する方法の詳細については、「Cisco ONS 15454 TCCカードへのPC直接接続のトラブルシューティング」の一番上の問題を参照してください。
Optical Carrier-48(OC-48)Long Reach(LR)1550カードの特定のハードウェアリビジョンでは、リリース2.x.xソフトウェアはサポートされていません。OC-48リングがある場合は、次の手順に示すように、続行する前にOC-48ラインカードのハードウェアリビジョンを確認する必要があります。
CTCノードビューで、[Inventory]タブをクリックします。
次に示すように、ハードウェア情報を含む適切なスロットをクリックします。
008CハードウェアリビジョンのOC-48 LRラインカード(OC48 LR 1550)がある場合は、ソフトウェアアップグレードを続行する前に、それらを交換する必要があります。
次の手順に示すように、CTCを使用してデュプレックスの共通モジュールを確認する必要があります。
ノードにログインします。
スロット7、8、10、および11に、TCC+カードとクロスコネクト(XC)カードまたはクロスコネクト(XC-VT)カードが重複して装着されていることを確認します。リリース2.2.xでは、シンプレックス動作はサポートされていません。
ネットワーク内の各ノードで手順1と2を繰り返します。
ネットワーク内の任意のノードへのアクティブなTelnetセッションがすべて閉じられていることを確認します。
追加のスーパーユーザ
新しいスーパーユーザCISCO15がリリース2.2.0に追加されました。現在はcerent454スーパーユーザ名を使用できますが、このユーザ名は今後のリリースで廃止される予定です。
ONS 15454ノードの背面を見て、右側にATM Interface Processor(AIP)が刻印された緑色のボードを見つけます(ボードに面すると書き込みは横向きになります)。
部品番号のステッカーを探します。番号の前には、ステッカーのP/Nが付いている必要があります。
注:部品番号のステッカーがない場合は、番号がボード自体にスタンプされることがあります。
部品番号が67-11-00015の場合は、AIPボードを交換する必要があります。そうでない場合、AIPボードはソフトウェアアップグレードをサポートします。
ネットワーク内のすべてのノードに対して、手順1 ~ 3を繰り返します。
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
次の項では、アップグレードに必要なハードウェアおよびソフトウェアの設定前提条件について詳しく説明します。各セクションで作業を進め、すべての基準を満たしていることを確認します。
アップグレード前の手順を支援するには、次のフローチャートを使用します。
リリース2.2.xからリリース2.2.2または3.0ソフトウェアにアップグレードする前に、ネットワーク内の各ノードの現在のデータベースをバックアップする必要があります。
CTC にログインします。
[ノード]ビューで、次に示すように、[メンテナンス] > [データベース]タブをクリックします。
[バックアップ]をクリックします。
ワークステーションのハードドライブまたはネットワークストレージにデータベースを保存します。ファイル拡張子に.dbを持つ適切なファイル名を使用します(たとえば、myDatabase.db)。
[Save] をクリックします。[File Received]ダイアログボックスが表示されます(次を参照)。
[OK] をクリックします。
ネットワーク内の各ノードの重要な情報は、書き込みまたは必要に応じて画面を印刷して、手動でログに記録することをお勧めします。この手順は、データベースをバックアップした後のオプションです。次の表を使用して、ログを記録する必要のある情報を決定します。ネットワーク内の各ノードの表(または自分のバージョン)を完成させます。
項目 | ここにデータを記録(該当する場合) |
---|---|
ノードのIPアドレス | |
ノード名 | |
タイミング設定 | |
データ通信チャネル(DCC)接続DCCがアクティブになっているすべての光ポートをリストする | |
ユーザID(少なくとも1人のスーパーユーザを含め、すべてリスト) | |
インベントリ;インベントリウィンドウから印刷画面を実行する | |
アクティブTCC+ | スロット7またはスロット11(円1) |
アクティブXC | スロット8またはスロット10(円1) |
ネットワーク情報ネットワークビューの[プロビジョニング(Provisioning)]タブからすべての情報を記録します | |
Current configuration :BLSR、リニアなど | |
システム内のすべての保護グループをリストします。[保護グループ]ウィンドウから印刷画面を実行する | |
アラームの一覧表示アラームウィンドウから印刷画面を実行する | |
回線のリスト回路ウィンドウから印刷画面を行う |
各ノードのデータベースをバックアップし、各ノードに必要な情報を記録したら、ソフトウェアのアップグレードを開始する準備が整います。
注意:アップグレード中に一時的なトラフィック中断が発生する可能性があります。新しいソフトウェアレベルのアクティベーション中に、各回線で60ミリ秒未満のトラフィック中断が可能です。イーサネットの場合、スパニングツリープロトコル(STP)の再計算により、各回線でトラフィックの中断が数分に及ぶ可能性があります。
注意:アップグレード中にメンテナンスやプロビジョニングを行わないでください。
注:ワークステーションに最も直接接続されているノードから開始すると、最適なダウンロードパフォーマンスを実現できます。ただし、ほとんどのネットワークでは、最も遠いノードでアクティベーションを開始し、最も直接接続されているノードに進むほうが安全です。これにより、予期しない状況でアップグレードが失敗した場合に、ノードが停止するリスクがなくなります。この問題は、ネットワーク管理ポリシーの問題です。
リリース2.2.0からアップグレードする場合は、最初にptfix.exeスクリプト(PC)を実行する必要があります。 リリース2.2.1からアップグレードする場合は、このドキュメントの「新しいソフトウェアレベルのアップロード」セクションに直接移動してください。
TCC+カードには2つのフラッシュランダムアクセスメモリ(RAM)があります。 アップグレードにより、バックアップとアクティブTCC+カードの両方のバックアップRAMにソフトウェアがアップロードされます。アクティブなソフトウェアはプライマリRAMの場所で実行されるため、トラフィックには影響しません。したがって、ソフトウェアはいつでもアップロードできます。
ソフトウェアリリースレベル2.2.2のアップグレード手順をテストしたところ、ごく少数のケースで、Bidirectional Line Switched Rings(BLSR)トランクカードがハングする可能性があることが判明しました。回避策は、BLSRトランクカードをリセットすることです。したがって、ソフトウェアリリースレベル2.2.2にアップグレードする場合は、新しいソフトウェアレベルをアクティブにする前に、各ノードのBLSRトランクカードをリセットする必要があります。
次のフローチャートを使用して、アップグレード手順を支援してください。
スクリプトptfix.exeは、リリース2.2.0より上のソフトウェアレベルにアップグレードする際に初めて実行する必要があります。このスクリプトは、リリース2.2.1スタンバイ/保護ソフトウェア以降の新しいTCC+カードでメモリのパーティションを実行します。クラスタサイズを16384から65536バイトに変更します。リリース2.2.1からアップグレードする場合は、この手順を省略して、このドキュメントの「アップロード」セクションに進むことができます。
注意:複数のノードと1つのワークステーションで同時にスクリプトを実行しないでください。
スクリプトの実行には、約2 ~ 3分かかります。必要に応じて、IPアドレスの前に – uオペランドを指定して、メモリパーティションを元に戻すことができます。
CTCリリース2.2.0を使用して、ワークステーションに接続されているノードから最も遠いノードにログインします。
ONS 15454で既存のアラームを確認します。続行する前に、未処理のアラームをすべて解決します。
ノードビューで、次に示すように[Maintenance] > [Software]タブをクリックします。
アクティブロードが2.2.0(02.20-001A-00.38)であることを確認します。 このスクリプトは、リリース2.2.0(02.20-001A-00.38)のロードでのみ動作します。
ONS 15454へのアクティブなTelnet接続をすべて閉じます。
コマンドウィンドウで、CDソフトウェアのCisco15454ディレクトリから、次に示すように、スクリプトを実行しているノードのIPアドレスを使用してptfix.exeを実行します。
このステップには約2 ~ 3分かかります。スクリプトが正常に完了すると、[Upgrade Preparation Complete]メッセージが表示されます。
CTC接続を閉じ、以前に接続していたノード(スクリプトを実行したノードから最も遠い)に再接続します。
[Network]ビューから、スクリプトを実行したノードにログインします。
[メンテナンス] > [ソフトウェア]タブをクリックします。
次に示すように、保護ソフトウェアがnoneになっていることを確認します。
注:リリース2.2.2ロードがアクティブになる前にアクティブ/スタンバイTCC+がリブートする場合は、スクリプトを再実行してください。
次のステップを実行します。
リング内のすべてのノードで既存のアラームをチェックします。続行する前に、未処理のアラームまたは異常な状態を解決します。
同期ファシリティに対して未処理のアラームが宣言されていないことを確認します。続行する前に、同期機能のマイナー、メジャー、またはクリティカルアラームをすべてクリアします。
注:情報アラームは青色で表示されます。これらは無視できます。
すべてのノードでアラームを確認して解決した後、新しいソフトウェアレベルを最初のノードだけにアップロードします。リリース2.2.0のアップグレードでは、このノードがスクリプトを最近実行したノードになります。
注:ソフトウェアのアップグレードプロセス中に、アラームが発生すると、動作しているTCC+カードと保護しているTCC+カードのソフトウェアアップグレードが行われていることが示されます。これは正常であり、次に示すように、アップグレードが完了するとアラームがホワイトアウトします。
アップグレードするノードに戻ります。[ノード]ビューで、次に示すように、[メンテナンス] > [ソフトウェア]タブをクリックします。
[Upgrade] をクリックします。[Software Upgrade]ダイアログボックスが開きます。
新しいソフトウェアレベルが含まれているCD-ROMドライブを参照し、Cisco15454フォルダを開くか、新しいソフトウェアをダウンロードしたディレクトリに移動します。次のスクリーンショットでは、/Upgradeというディレクトリからアップロードしています。
.pkg拡張子を持つファイルを選択し、[開く]をクリックします。次に示すように、CTCにはステータスウィンドウが表示されるので、アップグレードプロセスをモニタできます。
新しいソフトウェアレベルがアクティブTCC+カードとスタンバイTCC+カードの両方にコピーされると、ファイルが正常に転送されたことを示すメッセージが次のように表示されます。
注:アップグレードプロセスには30分以上かかる場合があります。
ノードがBLSR設定の場合は、新しいソフトウェアレベルをアクティブにする前にリングロックアウトを実行する必要があります。リングロックアウトは、アップグレード中にシェルフ内のカードのブートによって発生するビットエラーによるスイッチング(保護Synchronous Transport Signal(STS;同期転送信号)のルーティングトラフィック)を防止します。BLSRリングのすべてのノードに対してリングロックアウトを実行する必要があります。リングロックアウトについては、次の手順を実行します。
注:ロックアウト中は、BLSRスパンは保護されません。リング内のすべてのノードをアクティブにした後、ロックアウトを必ず取り外してください。
注:リングまたはスパンの切り替えを防止するには、各ノードのイーストスパンとウェストスパンの両方でロックアウトを実行します。
次の手順に従って、アップグレード中にスイッチが発生するのを防ぐために、リングロックアウトを実行します。
[メンテナンス] > [リング]タブをクリックします。
次に示すように、WestとEastの両方の操作のプルダウンメニューからLockout Spanを選択します。
[適用]をクリックして、コマンドをアクティブにします。プロンプトに[はい]と答えます。新しいソフトウェアレベルがロードされるまで、ノードをこの状態のままにします。
注:WestおよびEastスパンをロックアウトすると、次に示すロックアウト要求アラームが表示されます。次のスクリーンショットでは、ノードAがプライマリタイミング基準としてスロット6のOC-48カードを使用しています。このため、ロックアウト・スパンが適用されると、ロックアウト・スパンによってプライマリ・タイミング基準が失われたことを示す追加のアラームが表示されます。
保護STSタイムスロットのデフォルトKアラームまたはアラームは、このロックアウト期間中に発生する可能性があります。アラームが発生した場合は、これらのアラームを無視します。
BLSRのすべてのノードでステップ1を繰り返します。
ソフトウェアリリースレベル2.2.2にアップグレードする場合は、BLSRトランクカードをリセットする必要があります。ソフトウェアリリースレベル3.0にアップグレードする場合、この手順は必要ありません。ノードビューで、15454シャーシ内のすべてのBLSRトランクカードを個別に右クリックし、リセットします。これは、新しいソフトウェアレベルのロード中にBLSRカードがロックアップするリスクを防ぐために必要です。
次のようにプロンプトに[Yes]と答えます。
注:BLSRカードが正しくリセットされない場合は、新しいソフトウェアバージョンのロードを続行する前に、BLSRカードの問題を解決してください。必要に応じて、カードを物理的に取り付け直します。カードを装着し直す必要がある場合は、保護スイッチのすべてのロックアウトを最初にリリースしてください。カードがリブートしてアクティブになったら、ロックアウトを再度発行します。
BLSRリングのすべてのノードでステップ3を繰り返します。
保護グループ(1:1および1:N)に属するすべてのカードが、その保護グループの現用カードでアクティブであり、保護スイッチが発生していないことを確認します。つまり、先に進む前に、保護カードがスタンバイになっていることを確認します。
ネットワーク内の最も遠いノードから始まり、ワークステーションのノードで終わる各ノードにログインしてアクティブにします。
注:リリース3.0ソフトウェアレベルをアクティブにすると、一連のJava例外エラーが発生する場合があります。これらのメッセージは、リリース3.0のJavaコードベースで2.2.xが解釈できない変更が原因であるため、無視してください。Javaの例外には悪影響はありません。
スクリプトを実行したノードにログインします。
そのノードのIPアドレスを記録します。
ノードにアクティブアラームがないことを確認します。
ノードビューで、[メンテナンス(Maintenance)] > [ソフトウェア(Software)]タブをクリックします。
次に示すように、アップグレードに選択したソフトウェアレベルに応じて、保護ソフトウェアにリリース2.2.2または3.0が表示されることを確認します。
[Activate] をクリックします。[アクティブ化]ダイアログボックスが表示され、次のように警告メッセージが表示されます。
[はい]をクリックして、アクティベーションを続行します。アクティベーションの最初の部分は2 ~ 3分で完了し、次に示すメッセージを発行します。
次に、アクティブ化が完了し、ノードがリブートすることを確認するメッセージが表示されます。
[OK] をクリックします。
ソフトウェアアップグレードがノードで完了するまで待ってから、続行します。
アクティブ化は、スタンバイTCC+から開始して、インストールされている各カードを介してノードから実行されます。スタンバイTCC+が完全にアクティブになり、完全にリブートされると、アクティブTCC+になり、他のTCC+がリブートします。その後、XCまたはXCVTとアラームインターフェイスカード(AIC)がリブートします。次に、ラインカードが左から右に1つずつブートします。プロセス全体で約30分かかります。このプロセスはトラフィックに影響を与えるため、シスコでは、メンテナンス時間帯に新しいロードをアクティブにすることを推奨しています。Time Division Muliplexing(TDM)トラフィックは50ミリ秒以上のヒットに耐え、STPの再計算により、イーサネットトラフィックは約3 ~ 4分のヒットになります。すべてのカードが起動した後、アクティブなXCVTが再び起動し、すべての回線が正しく更新されていることを確認します。アクティブなXCVTがこの最後のリブートを終了し、すべてのアラームがクリアされたら、次のステップに安全に進むことができます。
注意:ONS 15454リリース2.2.xから3.0にアップグレードする場合、アクティブ化中に状態が発生する可能性があります。この場合、ノードでプロビジョニングの変更が実行されると、アップグレードプロセス後にノードがリセットされます。カードが新しいソフトウェアを正常にロードできない場合、アクティブ化が完了した後も通信障害(CONTBUS)状態が続き、ノードがこの状態になったことを示す可能性があります。ノードがこの状態になると、プロビジョニングの変更によってノードがシステム全体のリセットに移行し、すべてのカード(元々リセットに失敗したカードを除く)がソフトリブートを実行して、新しいソフトウェアイメージをリロードします。ノードがこの状態になると、トラフィックがプロビジョニングされた回線に影響を与える可能性があります。
アップグレード完了後にクリアされないCONTBUSアラームが表示された場合は、アラームを生成したカードを手動で取り付け直します。
アップグレードアクティベーションが正常に完了したことを確認するために、次の手順に示すように、ノードに対してプロビジョニング変更を実行することを推奨します。
[ノード]ビューで、次に示すように、[プロビジョニング] > [タイミング]タブをクリックします。
[参照リスト]ペインで、NE参照のいずれかを変更し、[適用]をクリックします。
1分待ってから、同じNEリファレンスをもう一度変更し、[適用]をクリックします。
問題が発生した場合は、30分のタイマーが動作するように設定され、ノードのリセットがメンテナンス時間帯またはスタッフがオンサイトにいる間に発生します。ノードのアラームパネルでSYSBOOTアラームを探します。プロビジョニングの変更後30分ノードがリセットされず、ノードのCTCアラームパネルにSYSBOOTアラームが表示されない場合、ソフトウェアのアクティベーションは成功しました。
リリース2.2.2のアップグレードでは、NetscapeまたはInternet Explorerブラウザをシャットダウンして再起動します。CTCからリリース3.0をアップグレードする場合は、次のスクリーンショットに示すように、[File] > [Exit]を選択します。
ステップ2のIPアドレスを使用してCTCに再接続します(IPアドレスがまだブラウザのロケーションバーにある場合は、Shiftキーを押しながらブラウザの[Reload/Refresh]ボタンをクリックするだけで構いません)。
リリース3.0 TCCソフトウェアは、次に示すように、3.0の新しいCTCソフトウェアレベルをダウンロードします。
次に示す[Delete CTC Cache]画面が表示されます。[CTCキャッシュの削除]ボタンをクリックして続行します。
次に示すように、新しいCTCアプレットがアップロードされます。
新しいリリース3.0のソフトウェアレベルに再接続しようとするとブラウザがハングする場合は、cms*.jarファイルをパソコンから削除してから、再接続してみてください。
新しいCTCアプレットはCTCリリース2.2.xと下位互換性があるため、アップグレード中にネットワークの可視性が得られます。
アップグレードする残りの各ノードに個別にログインし、次の手順を繰り返します。これらの各手順は、TCC+カードを搭載し、ソフトウェアリリース2.2.xを実行しているすべてのノードで実行する必要があります。各ノードが終了したら、NetscapeのCTCセッションからログアウトして、ONS 15454ノードから新しいJavaプラグインをダウンロードする必要があります。次のノードをアップグレードする前に、各ノードが完了することを許可します(すべてのアラームが10分間クリアされます)。詳細については、次のセクションを参照してください。
Ptfixスクリプト(リリース2.2.0のみ)
最後のノード(ワークステーションに接続されているノード)をアクティブ化した後、システムがリブートするまで待ちます。
注:お待ちください。システムのリブートには数分かかることがあります。
すべてのノードで新しいソフトウェアロードがアクティブになった後、すべてのBLSRノードでspanロックアウトを解放します。
CTCノードビューで、[Maintenance] > [Ring]タブをクリックします。
ロックアウトがアクティブな西と東の方向を個別に選択します。
次に示すように[クリア]を選択します。
[適用]をクリックして、コマンドをアクティブにします。次に示すように、リングロックアウトアラームがホワイトアウトになります。
次のパネルでは、リングマップテーブルを呼び出して、デフォルトKバイトまたはノードIDミスマッチのアラームをクリアするためにそれを受け入れるように求めるメッセージが表示されます。
または、[Provisioning] > [Ring]タブに移動し、[Ring Map]ボタンをクリックする必要がある場合があります。次に示すように、リングマップを受け入れます。
ソフトウェアのアップグレードに問題がある場合は、必要なオプションの手順を次に示します。現在のバージョンのソフトウェアでは、アップグレードが完了したことを確認するために、アップグレード前にログに記録された回線とプロビジョニング情報を再確認する必要があります。ノートと比較して、すべてのプロビジョニングが同じであり、ネットワークがすべてのトラフィックを伝送していることを確認します。アラームが報告されていないか、アップグレード前に報告されたアラームが少なくとも同じであることを確認します。
次のフローチャートを使用して、アップグレード後の手順を支援します。
アップグレード手順により、日付の設定が変更されることがあります。
CTCノードビューで、[Provisioning] > [General]タブをクリックします。
正しい日付を設定し、次に示すように[Apply]をクリックします。
残りのノードごとに手順1と2を繰り返します。
スペアのTCC+ユニットはすべて、新しいソフトウェアリリースレベルにアップグレードする必要があります。
スペアのTCC+をアップグレードするには、アップグレードしたリリースレベルを実行しているノードのスタンバイスロットに配置します。カードはアクティブなTCC+から自動的にアップグレードされます。
ソフトウェアのアップグレードが正常に完了した場合、次の手順は必要ありません。ただし、ソフトウェアのアップグレードで問題が発生した場合は、データベースを元に戻すか、手動で復元する必要があります。必要に応じて、次の手順を使用します。
次のフローチャートを使用して、アップグレード回復手順を支援します。
特定の状況では、バックアップデータベースに戻す必要がある場合があります。リリース2.2.xからリリース2.2.2または3.0ソフトウェアにアップグレードする前に、ネットワーク内のすべてのノードで現在のデータベースをバックアップする必要があります(ソフトウェアをアップグレードします)。 重要なすべての情報をハードドライブに記録またはエクスポートすることを強く推奨します。バックアップデータベースに戻す必要がある場合は、次の手順に従います。
BLSRがプロビジョニングされている場合は、復元を開始する前に、各ノードでスパンロックアウトを実行する必要があります。BLSRリングのロックアウト手順に従って、BLSRリングのスパンロックアウトを実行します。
注:サポートされている(サービスに影響しない)リリース3.0からの復元を実行するには、復元するリリースが、そのノードのリリース3.0にアクティブ化した時点で動作している必要があります。また、サポートされている復帰は、以前のアクティベーション時にノード設定を自動的に状態に復元します。したがって、ソフトウェアを元に戻すと、アクティベーション後に行った設定変更はすべて失われます。
注:次の手順では、データベースは復元の一部として自動的に復元されます。これはリリース2.2.1以降でのみ行われます。アクティブ化の前にリリース2.2.0を実行していた場合は、元に戻す手順を実行した後で、データベースを手動で復元する必要があります。データベースの手動復元はトラフィックに影響を与えるため、サービス時間帯に実行する必要があります。
ノードのIPアドレスを記録します。
[Node]ビューでスタンバイTCC+を右クリックし、次に示すように[Reset Card]オプションを選択します。
はいと答えてよろしいですか?ダイアログボックスが表示され、次のように選択内容を確認します。
カードをリセットすると、次に示すように、システムリセットとTCC+通信障害アラームが発生することに注意してください。
TCC+のリブートが完了するまで待ちます(約4分かかります)。 TCC+のリブートが完了すると、上記のシステムリセットとTCC+通信障害アラームがホワイトアウトします。
ノードビューで、[メンテナンス(Maintenance)] > [ソフトウェア(Software)]タブをクリックします。
次に示すように、保護ソフトウェアに2.2.x(アップグレード元のリリース)が表示されることを確認します。
[Revert]をクリックします。Revertは、保護ソフトウェアをアクティブにし、以前のロードからデータベースをリストアします。次に示すように、選択を確認するダイアログボックスが表示されます。
[OK] をクリックします。これにより、ノードへの接続がドロップされ、復元が開始されます。復帰時に、次のパネルが表示されます。
ノードを元に戻すと、次に示すrevert successfulパネルが表示され、ノードが再起動することを示します。
[Yes]を選択し、システムの再起動がノードで完了するまで待ってから続行します。次のパネルが表示され、リブート中にノードへのCTC接続が失われたことを示します。
注:お待ちください。システムのリブートが完了するまでに最大30分かかることがあります。
システムのリブートを実行すると、次に示すように、個々のカードがリブートされると、システムのリブートのアラームと、ノード上のその他の複数のアラームが発生します。
リブートが完了すると、すべてのアラームがホワイトアウトします。
NetscapeまたはInternet Explorerブラウザをシャットダウンします。
別のノードを復元する前に1分間待ちます。
ネットワーク内のすべてのノードを元に戻した後、ブラウザを再起動し、ステップ1で記録したIPアドレスで元に戻された最後のノードにログインします。これにより、リリース2.2.xの適切なCTCアプレットがワークステーションにアップロードされます。
BLSRをプロビジョニングし、復帰手順の前にリングロックアウトを実行した場合は、各ノードでリングロックアウトを解除する必要があります。BLSRリングのロックアウト解除手順に従って、BLSRリングのロックアウトを解除します。
注:JRE 1.3.0にアップグレードした場合、リリース2.2.1以前(またはリリース1.0.0を実行しているONS 15454)にログインできません。 以前のバージョンのJREが必要なリリースに戻す場合は、ネットワーク内のすべてのノードを元に戻した後、Javaを再起動し、ワークステーションのシステム一時ディレクトリからjarファイルを削除する必要があります。JRE 1.3も使用するリリースに戻す場合、またはアップグレード中に古いバージョンのJREを保持している場合は、これは問題になりません。
リリース2.2.0からアップグレードする場合、またはその他の場合は、アップグレード前のデータベースを手動で復元する必要がある場合があります。
注意:リリース2.2.0を復元する場合や、以降のリリースでソフトウェアの復元が失敗する場合を除き、これらの手順は実行しないでください。
注意:このプロセスはトラフィックに影響を与えるため、サービス時間帯に実行する必要があります。
CTCノードビューで、次に示すように[Maintenance] > [Database]タブをクリックします。
[復元]をクリックします。[開く]ダイアログボックスが表示されます。
以前に保存したファイルを選択し、次に示すようにOpenを選択します。
次の警告パネルが表示され、復元によってトラフィックが失われる可能性があることが示されます。次に示すように、[Yes]をクリックして続行します。
データベースが復元され、TCC+sがリブートします。復元の最後に、下のパネルが表示されます。次に示すように、[OK]をクリックして続行します。
システムをリブートすると、ノードへのCTC接続が失われることに注意してください。次にパネルを示します。
TCC+sがリブートしたら、CTCに再度ログインし、回線の設定が以前のデータベースバージョンと一致していることを物理的にチェックして、データベースが復元されたことを確認します。次のノードを復元する前に1分間待ちます。