システムの更新

システムの更新プロセスには、SAN ボリューム・コントローラー環境全体の更新が含まれます。

バージョン 7.4 以降からバージョン 7.5 以降への更新は、ここから開始します。

バージョン 7.4.0 より前のリリースから更新する場合は、前のリリースの説明に従います。ただし、更新の確認を行う必要があります。これは、現行リリースの説明には含まれていません。ご使用のリリースの説明に従った後、このバージョンの対応する最終の説明に戻ります。状況メッセージの受信および更新の確認に関するステップを実行します。

制約事項: システムをバージョン 7.1.0 以前からバージョン 7.2.0 以降に更新する場合、更新されるシステム上に 2 次ボリュームを持つグローバル・ミラー関係を停止する必要があります。更新プロセスが完了した後、これらの関係を再始動することができます。

重要: 更新処理中に、いずれかのノードに対するメモリー DIMM 障害が検出された場合は、即時に停止してください。更新を確実に成功させるには、以下の手順を実行します。

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

更新の前の制約事項に関する最新情報は、次のサポート・サイトで flashes, alerts, and bulletins を検索してください。

www.ibm.com/storage/support/2145

作業の計画には最大 1 週間の範囲で時間をとり、更新の準備作業を行い、SAN ボリューム・コントローラー環境の更新を完了させます。更新手順は、表 1 に示すように、一般的なプロセスに分割できます。

表 1. 更新タスク
シーケンス	更新task
1	更新の前に、関連する前提条件および作業について、よく理解しておいてください。自動的に更新するか手動で更新するかを決めます。自動更新手順では、クラスター化システムが各ノードを体系的に更新します。自動方式は、ノード上のソフトウェアの更新の場合の推奨手順です。ただし、各ノードを手動で更新することもできます。
2	CIM オブジェクト・マネージャー (CIMOM) クライアントが正常に機能していることを確認します。必要な場合は、これらのクライアントを更新して、新バージョンの SAN ボリューム・コントローラー・コードをサポートできるようにします。
3	環境内のマルチパス・ドライバーが完全に冗長な状態であることを確認します。
4	システムを更新します。システム更新には、コンポーネントのファームウェア更新が含まれます。ドライブのファームウェア更新は別個のプロセスです。
5	SAN ボリューム・コントローラー環境内のその他の装置を更新します。例として、ホストおよびスイッチを正しいレベルに更新する場合があります。
注: 時間は、必要な準備作業の量と環境のサイズによって異なります。自動更新の場合、各ノードにつき約 20 分と、それに加えて各システムにつき 30 分かかります。マルチパス・ソフトウェアのリカバリーには、30 分かかります。

重要: マルチパス・ドライバー・サポートでフェイルオーバーの問題が起きた場合は、これらの問題を解決してから通常の操作を開始してください。

システムとその接続アダプターのファームウェアおよびソフトウェアは、単一パッケージとしてテストされ、リリースされます。パッケージ番号は新規リリースが作成されるたびに増えていきます。

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

www.ibm.com/storage/support/2145

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

注: システム・ソフトウェアの更新が完了した後、管理 GUI を使用して、これらのイベントに対する修正手順を実行することで、各ノード上で Fibre Channel over Ethernet (FCoE) 機能を有効にすることができます。 FCoE のアクティベーション手順には、ノードのリブートが含まれます。同じ入出力グループ内の別のノードをアクティベーションする間にホスト・マルチパスがリカバリーする時間を考慮に入れてください。

更新プロセス

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

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

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

すべての情報コマンド
rmnode コマンド

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

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

マルチパス・ドライバー

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

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

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

内部フラッシュ・ドライブを含む SAN ボリューム・コントローラー 2145-CG8 または 2145-CF8 システムの更新

SAN ボリューム・コントローラーの更新処理は、システム内の各ノードを順次リブートします。更新が開始されて各ノードが更新される前に、更新処理は従属ボリュームが存在するかどうかを検査します。lsdependentvdisks コマンド・ライン・インターフェース (CLI) コマンドに node パラメーターを指定して使用することで、従属ボリュームが存在するかどうかを確認できます。

RAID 0 を使用する内部フラッシュ・ドライブを含むシステムの更新

更新・プロセスでは、更新を処理するために、各ノードが一時的にオフラインになります。内部フラッシュ・ドライブ (flash drive) を含むノードがオフラインになっている間に、そのオフラインのノード上にミラーリングされたコピーを配置しているボリュームにデータが書き込まれると、そのデータは他方のオンライン・コピーにのみ書き込まれます。更新したノードがシステムに再結合した後、オンラインで保持されていたコピーからデータの再同期が行われます。更新・プロセスでは、パートナー・ノード上で更新が開始されるまでに約 30 分の遅延があります。この時間内に同期を完了させなければ、更新が停止し、手操作による介入が必要になります。ミラーリングされたボリュームが、そのボリューム・コピーの片方または両方を格納するために、SAN ボリューム・コントローラー・ノード上にあるフラッシュ・ドライブ (flash drive) のディスク・エクステントを使用している場合は、再同期が時間内に確実に完了するように、そのボリュームの同期率を 80 以上に設定してください。

注: ボリューム・コピーを含む 2 つのノード間の時間間隔を増やして、更新処理中にノードがオフラインになるのを防ぐには、コードの手動更新を検討してください。

表 2 は、同期率を定義しています。

表 2. ボリューム・コピーの再同期率
同期速度	コピーされるデータ/秒
1-10	128 KB
11-20	256 KB
21-30	512 KB
31-40	1 MB
41-50	2 MB
51-60	4 MB
61-70	8 MB
71-80	16 MB
81-90	32 MB
91-100	64 MB

RAID 1 または 10 を使用する内部フラッシュ・ドライブを含むシステムの更新: 更新プロセスでは、更新を処理するために、各ノードが一時的にオフラインになります。この処理中は、オフライン・ノード上のミラーリングされたアレイに対する書き込み操作は、オンライン・ノード内のドライブにのみ書き込まれます。ノードがオンラインに戻ると、オフラインだったドライブは、ミラーリングされたオンラインのアレイから再同期されます。ただし、パートナー・ノードの更新が必要になる前にこの同期プロセスが完了しない場合、従属ボリューム・プロセスが失敗し、更新が停止します。
重要: 更新処理中にオフラインになってしまう 2 つのノード間の時間間隔を増やすには、コードの手動更新を検討してください。

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

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

SAN ボリューム・コントローラーのバージョン 6.4.0 以降では、4 つのファイバー・チャネル・ポートおよび 2 つの Fibre Channel over Ethernet (FCoE) ポートのサポートが使用可能になっています。システムにこれらのソフトウェアのバージョンが含まれる場合、6.4.0 より前のバージョンのソフトウェアが稼働している別のシステムとリモート・コピー協力関係を確立することはできません。 6.4.0 以降で稼働するシステムに、これより前のソフトウェア・バージョンで稼働している別のシステムとの既存のリモート・コピー協力関係がある場合、合計 5 つ以上のファイバー・チャネル・ポートおよび FCoE ポートを持つノードを追加することはできません。また、システム内の既存のノード上で、(FCoE を使用可能にするか、新規ハードウェアを取り付けることにより) 追加のポートをアクティブにすることもできません。これらの問題を解決するには、次の 2 つのオプションがあります。

リモート・システムのソフトウェアを 6.4.0 以降に更新する
chnodehw -legacy CLI コマンドを使用して、6.4.0 以降のソフトウェア・バージョンがインストールされたシステム内のノードで、追加のハードウェアを使用不可にする

chnodehw CLI の -legacy パラメーターは、FCoE ポートのアクティブ化および非アクティブ化を制御します。

追加のハードウェアをアクティブにするには、以下の CLI コマンドを実行します。

chnodehw node id

ここで node_name | node_id (必須) は、変更するノードを指定します。パラメーターの後に指定する変数は、次のいずれかです。

そのノードをシステムに追加したときに割り当てたノード名。
ノードに割り当てられた ID (ワールド・ワイド・ノード名ではない)。

追加のハードウェアを使用不可にするには、以下のコマンドを実行します。

chnodehw -legacy software_level node id

ここで software_level は、ノードと同時に使用する必要があるソフトウェアのレベルを示しています。この値が 6.4.0 より小さい場合、最大 4 つのファイバー・チャネルまたは FCoE ポートをサポートするためだけに、ノードは自身のハードウェアを構成します。また、node_name | node_id (必須) は、変更するノードを指定します。パラメーターの後に指定する変数は、次のいずれかです。

そのノードをシステムに追加したときに割り当てたノード名。
ノードに割り当てられた ID (ワールド・ワイド・ノード名ではない)。

6.4.0 コードの各ノード上で 6 つのポート (ファイバー・チャネル・ポートが 4 つ、FCoE ポートが 2 つ) がサポートされる場合、6.4.0 より前のシステムとの協力関係をセットアップする方法は規則によって管理されます。

6.4.0 のシステムは、5 つ以上の FC/FCoE 入出力ポートが使用可能にされている 6.4.0 より前のシステムと協力関係を形成することはできません。
例えば、A、B、C という 3 つのシステム間でのマルチシステム協力関係の構成があるとします。
A <-> B<-> C
システム A には 6.4.0 よりも前のソフトウェアがインストールされており、システム B および C には 6.4.0 がインストールされています。
システム B に、使用可能な FCoE ポートがない場合にのみ、この構成でリモート・コピー・サービスが可能です。
システム A と B の間の協力関係は、システム C のノード上の FCoE ポートがアクティブになっているため、影響を受けません。
6.4.0 システムで、6.4.0 より前のシステムとの間に協力関係が既に確立されている場合、および協力関係が停止している間に追加のハードウェア (ファイバー・チャネル・ポートが 4 つ、FCoE ポートが 2 つ) が使用可能にされた場合、リモート・システムを更新するまで、または chnodehw -legacy コマンドを使用して追加のハードウェアを使用不可にするまでは、協力関係を再開することはできません。
古いハードウェア構成のノード (10 Gb イーサネット・アダプターを備え、6.3.0 から 6.4.0 に更新されたシステムを含む) は、イベント・ログを生成することがあります。このログは、新規ハードウェア (FCoE 機能) が使用可能であり、 chnodehw コマンドを使用して有効にする必要があることを示します。古いレベルのソフトウェアを実行しているシステムとのリモート・コピー協力関係を継続操作する場合は、このイベント・ログを修正しないでおいてください。

追加のハードウェアがアクティブ化され、6.4 より前のソフトウェアを実行するシステムとの協力関係を確立する必要がある場合は、最初に chnodehw –legacy software version (pre 6.4 node id コマンドを使用して、追加ハードウェアを無効にする必要があります。

システムにノードが追加されると、システムは (開始された) 協力関係をチェックし、協力関係にあるシステムで最も低いレベルのソフトウェアを判別します。このソフトウェア・レベルは、システムに追加されるノードに渡されます。ノードは、システムに結合するときに、chnodehw -legacy software level コマンドと同等の処理を行います。

システム更新後

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