システム・ソフトウェア更新

システム更新プロセスには、システム環境全体の更新が含まれます。

重要: 更新処理中に、いずれかのノードに対するメモリー DIMM 障害が検出された場合は、即時に停止してください。更新を確実に成功させるには、以下の手順を実行します。
  1. 障害のあるノード上の DIMM を、ハードウェア・メーカーの指示にしたがって交換します。
  2. DIMM 障害のあるノードをシステムから取り外します。
    svctask rmnode object_id | object_name
  3. システム内の残りのノードの状況と更新状況を確認します。
    svcinfo lssoftwareupgradestatus
  4. パートナー・ノードが稼働しており、システム更新の状況が updating である場合は、保守モードでノードを更新し、それをシステムに戻します。
    svctask addnode
    可能なフラグについては、addnode コマンドの情報を参照してください。更新を続行します。
  5. パートナー・ノードがアップで、システムの更新状況が stalled の場合、更新を完了するか (ロールフォワード)、取り消すか (ロールバック) を判断します。判断の一部は、障害が発生したときに更新がどこまで進んでいたかに基づきます。サービス更新ストラテジーまたはノードの取り外し (rmnode コマンド) のいずれかを使用してロールフォワードできます。
    • ロールフォワード (サービス更新): 手動で更新を完了するには、保守モードの更新処理を使用して、残りのダウン・レベルのノードを更新します。すべてのノードが同じレベルで稼働するようになったら、更新をコミットします。
    • ロールフォワード (rmnode コマンド): rmnode コマンド・プロシージャーは、更新が 50% 以上完了している場合にのみ使用します。
    • ロールバック (更新を取り消す):
       svctask applysoftware -abort -force
      1 つ以上のノードがオフラインの場合は、-force パラメーターが必要です。
      重要: -force パラメーターを使用すると、アクセスが失われる可能性があります。 このオプションは、(オフライン・ノードの) パートナー・ノードが元のコード・レベルである場合にのみ選択してください。
      更新ノードが、一度に 1 つのノードずつ、元のソフトウェア・レベルにロールバックされます。
  6. すべてのノードがロールバックされ、同じファームウェアを実行していることを確認します。
  7. 次のコマンドを入力します。
    svcconfig backup
  8. システムの正常性を確認します。

更新の前の制約事項に関する最新情報は、以下のサイトを参照してください。

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

作業の計画には最大 1 週間の範囲で時間をとり、更新の準備作業を行い、 システム環境の更新を完了させます。更新手順は、表 1 に示すように、一般的なプロセスに分割できます。
表 1. 更新タスク
シーケンス 更新task
1 更新の前に、関連する前提条件および作業について、よく理解しておいてください。自動更新手順では、クラスター化システムが各ノードを体系的に更新します。自動的に更新するか手動で更新するかを決めます。自動更新手順では、クラスター化システムが各ノードを体系的に更新します。自動方式は、ノード上のソフトウェア 更新の場合の推奨手順です。ただし、各ノードを手動で更新することもできます。
2 CIM オブジェクト・マネージャー (CIMOM) クライアントが正常に機能していることを確認します。 必要な場合は、これらのクライアントを更新して、新規バージョンの システム・コードをサポートできるようにします。
3 環境内のマルチパス・ドライバーが完全に冗長な状態であることを確認します。
4 システムを更新します。
5 システム環境内の他の装置を更新します。例として、ホストおよびスイッチを正しいレベルに更新する場合があります。
注: 時間は、必要な準備作業の量と環境のサイズによって異なります。
重要: マルチパス・ドライバー・サポートでフェイルオーバーの問題が起きた場合は、これらの問題を解決してから通常の操作を開始してください。

システムのソフトウェア は、単一のパッケージとしてテストされ、リリースされます。 パッケージ番号は、新しいリリースが作成されるたびに大きくなります。

コード・レベルには、前の特定のレベルからの更新だけをサポートするものもあります。あるいは、特定のハードウェア・タイプにのみインストールできるコードがあります。現在のレベルから複数レベル上に更新するときは、その中間にあるレベルのインストールが必要になる場合があります。例えば、レベル 1 からレベル 3 に更新する場合、レベル 3 をインストールする前にレベル 2 のインストールが必要になることがあります。それぞれのコード・レベルの前提条件について詳しくは、次の Web サイトを参照してください。

www.ibm.com/support
重要: ログに未修正エラーが入っていないこと、また、システムの日時が正しく設定されていることを確認します。 修正手順を開始し、必ず未解決のエラーを修正してから、コードの並行更新を試みてください。

更新プロセス

自動更新処理の際は、システム内の各ノードが 1 つずつ更新され、ノードへの新規コードのステージングが行われます。各ノードが再始動している間は、システムが維持できる最大入出力速度がいくらか低下する場合があります。 システム内のすべてのノードが新しいコード・レベルで正常に再始動された後に、新規レベルは自動的にコミットされます。

自動コード更新時には、作業ペアの各ノードが順次更新されます。 更新中のノードは一時的に使用できなくなり、そのノードに対するすべて入出力操作は失敗します。その結果、入出力エラー件数は増加し、失敗入出力操作は、作業ペアのパートナー・ノードに送られます。 アプリケーションが入出力の失敗を認識することはありません。新規ノードがシステムに追加されると、更新パッケージが自動的にシステムから新規ノードにダウンロードされます。

更新は、一般に、通常のユーザーの入出力操作と並行して実行できます。ただし、パフォーマンスに影響が生じる可能性があります。更新中に実行できる操作に適用される制限がある場合、これらの制限は、更新パッケージのダウンロードに使用した製品 Web サイトに記載されています。更新手順の間、構成コマンドの大半は使用できません。更新処理の開始以後は、新規コード・レベルがコミットされるまで、またはプロセスがバックアウトされるまで、以下のコマンドのみが操作可能です。

  • すべての情報コマンド

更新処理が完了したかどうかを判断するには、管理 GUI からの通知を確認します。コマンド・ライン・インターフェースを使用している場合は、lsupdate コマンドを発行して、更新の状況を表示します。

更新処理時に発生する操作上の制限があるため、コード更新はユーザーの作業になります。ただし、更新に関連した問題が生じた場合は、サポート・センターに連絡してください。技術支援を受けずに更新問題のトラブルシューティングを試みないでください。詳しい説明は、『資料、ヘルプ、および技術支援の入手方法』のトピックを参照してください。

マルチパス・ドライバー

更新を行う前に、マルチパス・ドライバーが完全に冗長な状態であり、すべてのパスが使用可能でオンラインになっていることを確認してください。パスの消滅 (フェイルオーバー) に関連したエラーが発生し、更新中にエラー件数が増加する場合があります。ノードへのパスが回復すると、ノードはフォールバックして完全冗長システムになります。 30 分の遅延の後に、他方のノードへのパスがダウンします。

ホスト上で IBM® Subsystem Device Driver (SDD) または IBM Subsystem Device Driver Device Specific Module (SDDDSM) をマルチパス・ソフトウェアとして使用している場合は、datapath query device または datapath query adapter コマンドを発行すると、増加した入出力エラー件数が表示され、マルチパス・ソフトウェアの状態をモニターすることができます。詳しくは、「IBM マルチパス・サブシステム・デバイス・ドライバー ユーザーズ・ガイド」を参照して、datapath query コマンドの詳細情報を確認してください。

ホスト上で IBM Subsystem Device Driver Path Control Module (SDDPCM) をマルチパス・ソフトウェアとして使用している場合は、pcmpath query device または pcmpath query adapter コマンドを発行すると、増加した入出力エラー件数が表示され、マルチパス・ソフトウェアの状態をモニターすることができます。

メトロ・ミラー関係およびグローバル・ミラー 関係

実行中のメトロ・ミラー関係またはグローバル・ミラー関係の 2 次ボリュームを持つシステム上でソフトウェアを更新する場合、1 次ボリューム上の書き込みパフォーマンスが低下する可能性があります。また、グローバル・ミラー関係は、エラー・コード 1920 を示す 1 つ以上のエラーで自動的に停止する場合があります。書き込みパフォーマンスの低下を回避するために、ソフトウェアを更新する前に、そのような関係を事前に停止し、更新が完了した後で関係を再始動することもできます。

システム更新後

ご使用のシステムに更新前にあった監査ログの内容は、構成ノードの /dumps/audit ディレクトリー内のファイルへ送信されます。これで、システムの更新が正常に完了した後に実行されるコマンドから発生する内容が、監査ログに含まれるようになります。