CLI を使用したソフトウェアの自動更新

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

1. 最新バージョンのテスト・ユーティリティーをダウンロードし、インストールし、実行して、現行のシステムに問題がないことを確認する必要があります。
   重要: 管理 GUI または CLI を使用してテスト・ユーティリティーをインストールおよび実行した後、このページのステップ 2 に戻る必要があります。

   このツールの最新バージョンは、次の Web サイトでダウンロードおよびインストールできます。このリンクは、管理 GUI または CLI を使用してテスト・ユーティリティーをインストールおよび実行するための手順を提供します。

   http://www.ibm.com/support/docview.wss?uid=ssg1S4000585

2. 最新のコードを www.ibm.com/support サイトからダウンロードします。
   • コードを CD に書き込む場合は、CD イメージをダウンロードする必要があります。
   • コードを CD に書き込まない場合は、インストール・イメージをダウンロードする必要があります。
3. PuTTY scp (pscp) を使用して、アップデート・ファイルをノードにコピーします。
4. アップデート・ファイルが正常にコピーされたことを確認します。
   更新を始める前に、以下の状況を理解しておいてください。

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

   applysoftware -file software_update_file

   ここで、software_update_file は、ステップ 3 でファイルをコピーした先のディレクトリー内のコード・アップデート・ファイルの名前です。

   システムのアップデートの一部としてノードをリブートした結果、いずれかのボリュームがオフラインになることがシステムで識別される場合、コードのアップデートは開始されません。識別された問題に関係なく更新を続行するよう指示するために、オプションの force パラメーターを使用できます。 force パラメーターを使用すると、続行することを確認するためのプロンプトが出されます。
6. 次の CLI コマンドを発行して、コード更新プロセスの状況を確認します。

   lsupdate

   このコマンドは、アップデートの完了時に success と表示します。 システム上でホット・スペア・ノードが構成されている場合、ホット・スペア・ノードは、更新が完了した時点で各ノードからの入出力操作を受け入れます。
   注: stalled_non_redundant という状況が表示された場合、 残りのノードのセットの更新を続行すると、ボリュームがオフラインになる場合があります。サービス担当員に連絡して、更新を完了してください。
7. アップデートが正常に完了したことを確認するには、システム内のノードごとに lsnodevpd CLI コマンドを発行します。

   「コード・バージョン (code version)」フィールドに、新しいコード・レベルが表示されます。

   重要: 既に 64 GB を超える RAM を取り付け済みのシステム上で、システム・ソフトウェアを 8.1.0 より前のバージョンからバージョン 8.1.1 以降に更新すると、すべてのノードがエラー・コード 841 で更新から戻ります。バージョン 8.1.0 以降では、以前のバージョンと異なる方法でメモリーを割り振るため、RAM を再度「受け入れる」必要があります。 エラーを解決するには、以下のステップを実行します。

   1. 単一ノード上で、svctask chnodehw コマンドを実行します。複数のノード上で同時にコマンドを実行しないでください。
   2. ノードが再始動してエラーなしで戻るまで待ちます。
   3. マルチパス・ドライブがホスト上で回復するまで、さらに 30 分待ちます。
   4. すべてのノード上でエラーがクリアされるまで、このプロセスを各ノードに対して個別に繰り返します。