CLI を使用したSAN ボリューム・コントローラー ソフトウェア・アップグレード

コマンド行インターフェース (CLI) を使用して、ソフトウェア・アップグレードをインストールできます。

1. SAN ボリューム・コントローラーのコードを、 次の SAN ボリューム・コントローラー (2145) のサポートの Web サイトからダウンロードします。

   www.ibm.com/storage/support/2145

   • SAN ボリューム・コントローラー・コードを CD に書き込む場合は、CD イメージをダウンロードする必要があります。
   • SAN ボリューム・コントローラー・コードを CD に書き込まない場合は、インストール・イメージをダウンロードする必要があります。
2. PuTTY scp (pscp) を使用して、ソフトウェア・アップグレード・ファイルをノードにコピーします。
3. ソフトウェア・アップグレード・ファイルが正常にコピーされたことを確認します。
   ソフトウェアのアップグレードを始める前に、以下のことを理解しておいてください。

   • 以下の状態ではインストール・プロセスが失敗します。
     • リモート・クラスターにインストールされているソフトウェアが新規ソフトウェアと互換性がない場合、またはクラスター間通信エラーがあり、ソフトウェアに互換性があることをソフトウェアが確認できない場合。
     • クラスターに、新規ソフトウェアでサポートされていないハードウェア・タイプのノードがある場合。
     • SAN ボリューム・コントローラー・ソフトウェアが、アップグレード・プロセスの一部としてノードをリブートすることにより、クラスター内の 1 つ以上の仮想ディスク (VDisk) がオフラインにされることを判別した場合。どの VDisk が影響を受けるかについての詳細は、svcinfo lsnodedependentvdisks コマンドを使用するか、「ノードの表示」パネルから「依存 VDisk の表示」アクションを使用して見つけることができます。アップグレード中にデータへのアクセスが失われても対応可能な場合は、force フラグを使用して、この制限をオーバーライドすることができます。
   • ソフトウェア・アップグレードは、ノード間のファイバー・チャネル接続を使用してクラスター内のすべてのノードに配布されます。
   • ノードは 1 つずつ更新されます。
   • ノードは、通常のクラスター・アクティビティーと並行して、新しいソフトウェアの実行を始めます。
   • ノードは、更新中、入出力グループの入出力アクティビティーには参加しません。その結果、入出力グループ内の VDisk のすべての入出力アクティビティーは、ホスト・マルチパス・ソフトウェアによって、入出力グループ内のほかのノードに送られます。
   • ノードの更新から次の更新まで、30 分の遅延が設けられています。 この遅れによって、ホスト・マルチパス・ソフトウェアは、アップグレードされたノードへのパスを再発見することができるため、入出力グループの別のノードが更新されるときにアクセスが失われることはありません。
   • ソフトウェアの更新は、クラスター内のすべてのノードが新しいソフトウェア・レベルに正常に更新されるまでコミットされません。すべてのノードが新しいソフトウェア・レベルで正常に再始動されると、新しいレベルがコミットされます。新しいレベルがコミットされると、クラスターの重要製品データ (VPD) は更新されて、新しいソフトウェア・レベルを反映します。
   • アップグレードされたソフトウェアの新規機能は、すべてのメンバー・ノードがアップグレードされ、更新がコミットされるまで起動できません。
   • ソフトウェアのアップグレード・プロセスは若干時間がかかるため、インストール・コマンドは、ソフトウェア・レベルがクラスターによって検査されるとただちに完了します。 アップグレードの完了時点を判別するには、クラスターの VPD のソフトウェア・レベルを表示するか、あるいはエラー・イベント・ログのソフトウェア・アップグレード完了イベントを探す必要があります。 ノードが新規ソフトウェア・レベルで再始動できない場合、あるいはプロセスの他の時点に障害を起こした場合、ソフトウェア・レベルは元に戻されます。
   • ソフトウェアのアップグレード中、各ノードのバージョン番号は、ソフトウェアがインストールされ、そのノードが再始動された時点で更新されます。クラスターのソフトウェア・バージョン番号は、新規ソフトウェア・レベルがコミットされると更新されます。
   • ソフトウェアのアップグレードが開始すると、エラー・ログまたはイベント・ログに項目が作成され、アップグレードが完了または失敗したときも項目が作成されます。
4. 以下の CLI コマンドを発行して、ソフトウェア・アップグレード・プロセスを開始します。
   • SAN ボリューム・コントローラーのバージョン 4.3.1 から バージョン 5.1 にアップグレードする場合は、次のコマンドを入力してください。

     svcservicetask applysoftware -file software_upgrade_file

   • SAN ボリューム・コントローラーのバージョン 5.1 からアップグレードする場合は、 次のコマンドを入力してください。

     svctask applysoftware -file software_upgrade_file

   ここで、software_upgrade_file はソフトウェア・アップグレード・ファイルの名前です。

   クラスターのアップグレードの一部としてノードをリブートする結果、いずれかの VDisk がオフラインになることをクラスターが識別している場合、ソフトウェアのアップグレードは開始されません。 問題が識別されているにもかかわらずアップグレードを続行する必要があることを指示するには、オプションの force パラメーターを使用できます。アップグレードが失敗した原因を特定するには、svcinfo lsnodedependentvdisks コマンドを使用します。このパラメーターを使用すると、続行することを確認するためのプロンプトが出されます。force パラメーターの動作が変更され、エラー・ログにエラーがあるクラスターに対してアップグレードを適用する際には不要になりました。
5. CLI で次のコマンドを発行して、ソフトウェア・アップグレード・プロセスの状況を検査します。

   svcinfo lssoftwareupgradestatus

   注: stalled_non_redundant という状況が表示された場合、 残りのノードのセットのアップグレードを続行すると、VDisk がオフラインになる場合があります。IBM® サービス担当員に連絡を取って、アップグレードを完了させてください。
6. 以下のステップを実行して、ソフトウェア・アップグレードが正常に完了したか調べます。
   1. svctask dumperrlog CLI コマンドを発行して、エラー・ログの内容をテキスト・ファイルに送ります。
      ソフトウェアが正常にアップグレードされた場合は、以下の出力がテキスト・ファイルに表示されます。

      Upgrade completed successfully

   2. クラスター内のノードごとに svcinfo lsnodevpd CLI コマンドを発行します。 「ソフトウェア・バージョン (software version)」フィールドに、新しいソフトウェア・レベルが表示されます。