clustered Data ONTAP 8.2 アップグレードおよびリバート

clustered Data ONTAP® 8.2
アップグレードおよびリバート / ダウングレード ガイド
ネットアップ株式会社
www.netapp.com/jp
部品番号: 215-09045_A0
作成日: 2013年5月
目次 | 3
目次
Data ONTAPクラスタのアップグレード ........................................................ 7
Upgrade Advisorを使用したアップグレードの計画 ................................................... 8
アップグレードの計画 ................................................................................................. 9
クラスタのアップグレードの種類 .................................................................. 10
クラスタのアップグレードのチェックリスト .................................................... 10
クラスタのアップグレードに関する要件と制限 ............................................ 16
バッチ アップグレードのアップグレード順序 ............................................... 18
アップグレード プロセス期間の見積もりに関するガイドライン ................... 20
アップグレード時のInfinite Volumeに関する注意事項 .............................. 20
SnapMirrorのアップグレード要件 ................................................................ 21
潜在的なアップグレードの問題の特定 ....................................................... 22
Data ONTAPクラスタのアップグレードの準備 ........................................................ 25
Perfstat Convergedを使用したパフォーマンスのベースラインの作成 ........ 25
クラスタがクォーラムにあることの検証 ....................................................... 26
クラスタとSVMの健全性の確認 .................................................................. 27
LIFの有効化とホーム ポートへのリバート .................................................. 28
LIFフェイルオーバーの設定の確認 ............................................................ 30
LIFの自動リバランシングの無効化 ............................................................ 31
システム時間の検証 .................................................................................... 32
各ノードで実行しているソフトウェア バージョンの確認 .............................. 34
Data ONTAPソフトウェア イメージの取得 ................................................... 34
クラスタでのData ONTAP 8.xソフトウェア イメージのインストール ........... 35
クラスタでのData ONTAPソフトウェア イメージの格納と切り替えの仕
組み ......................................................................................................... 36
無停止アップグレードまたは無停止ダウングレードを行うための
SnapMirror関係の準備 .......................................................................... 38
実行中のジョブがないことの確認 ................................................................ 39
ソフトウェアのアップグレードの実行 ........................................................................ 40
クラスタをアップグレードする準備が完了していることの確認 ................... 40
ローリング アップグレード方式によるData ONTAPクラスタの無停止ア
ップグレード ............................................................................................. 42
4 | アップグレードおよびリバート / ダウングレード ガイド
バッチ方式によるData ONTAPクラスタの無停止アップグレード ............... 50
停止を伴うData ONTAPクラスタのアップグレード ...................................... 59
クラスタが正常にアップグレードされたことの確認 ..................................... 60
クラスタのアップグレード後の手順の実行 .............................................................. 61
クラスタとSVMの健全性の確認 .................................................................. 61
LIFの有効化とホーム ポートへのリバート .................................................. 62
アップグレード後のInfinite Volume用のネームスペース ミラー コンス
ティチュエントの作成 .............................................................................. 64
Remote Support Agent用のクラスタ管理LIFの設定 ................................... 66
SnapMirror処理の再開 ................................................................................ 66
古い形式のSnapMirror関係のアップグレード ............................................. 67
LIFの自動リバランシングの有効化 ............................................................ 68
ファームウェアの更新 .................................................................................. 70
システム ファームウェアの更新 ............................................................................... 70
ディスク ファームウェアの更新 ................................................................................ 70
ディスク ファームウェアの更新方法 ............................................................ 70
Disk Qualification Packageの更新が必要なタイミング ............................... 71
ディスク シェルフ ファームウェア更新中のサービスの可用性 ................... 72
ディスク シェルフ ファームウェアの更新 ................................................................. 73
ディスク シェルフ ファームウェアの更新方法 ............................................. 73
古いディスク シェルフ ファームウェアの検出 .............................................. 74
ACPファームウェアの更新方法 ................................................................... 75
サービス プロセッサ ファームウェアの更新 ............................................................ 75
RLMファームウェアの更新 ...................................................................................... 76
Flash Cacheファームウェアの更新方法 ................................................................... 76
以前のData ONTAPリリース ファミリーへのクラスタのリバート .............. 77
リバートのタイミングおよびテクニカル サポート連絡のタイミング ......................... 77
リバートの計画 ......................................................................................................... 78
クラスタ リバートのチェックリスト ................................................................. 78
リバート プロセスの注意事項 ...................................................................... 81
潜在的なリバートの問題の特定 .................................................................. 82
Data ONTAPクラスタをリバートする準備 ................................................................ 83
本番用システムをリバートする準備 ............................................................ 83
クラスタとSVMの健全性の確認 .................................................................. 93
目次 | 5
リバートまたはダウングレード前のクラスタがクォーラムにあることの
確認 ......................................................................................................... 94
システム時間の検証 .................................................................................... 95
リバート前のiSNSの準備 ............................................................................. 96
リバート前のSnapshotコピーの準備 ............................................................ 97
Data ONTAPソフトウェア イメージの取得 ................................................... 98
クラスタでのData ONTAP 8.xソフトウェア イメージのインストール ........... 99
Data ONTAPクラスタのリバート ............................................................................ 100
リバート後の手順の完了 ....................................................................................... 103
クラスタとSVMの健全性の確認 ................................................................ 103
LIFの有効化とホーム ポートへのリバート ................................................ 104
リバート後のSnapshotコピーの準備 .......................................................... 106
クライアント アクセスの確認（CIFSおよびNFS） ........................................ 106
SPファームウェアのダウングレードに関する注意事項 ............................ 107
リバートまたはダウングレード後の必要なVシリーズライセンスの再イ
ンストール .............................................................................................. 107
vsadminロールが割り当てられたSVM管理者向けの機能の有効化 ...... 108
同じ リリース ファミリーの以前のリリースにクラスタをダウングレードす
る ............................................................................................................ 109
ダウングレードのタイミングおよびテクニカル サポートへの連絡のタイミング .... 109
ダウングレードの計画 ............................................................................................ 109
クラスタ ダウングレードのチェックリスト .................................................... 110
Vシリーズ システムをダウングレードする場合の確認事項 ..................... 112
ダウングレード プロセスの注意事項 ......................................................... 112
Data ONTAPのダウングレード プロセスの準備 ................................................... 113
クラスタとSVMの健全性の確認 ................................................................ 113
LIFの有効化とホーム ポートへのリバート ................................................ 114
リバートまたはダウングレード前のクラスタがクォーラムにあることの
確認 ....................................................................................................... 116
システム時間の検証 .................................................................................. 117
バックエンド構成のエラーの確認 .............................................................. 118
ダウングレード前の各ノードで実行しているソフトウェア バージョンの
確認 ....................................................................................................... 119
Data ONTAPソフトウェア イメージの取得 ................................................. 119
6 | アップグレードおよびリバート / ダウングレード ガイド
クラスタでのData ONTAP 8.xソフトウェア イメージのインストール ......... 120
無停止アップグレードまたは無停止ダウングレードを行うための
SnapMirror関係の準備 ........................................................................ 121
Data ONTAPのダウングレード プロセスの実行 ................................................... 123
実行中のジョブがないことの確認 .............................................................. 123
以前のバージョンのData ONTAP 8.xへのデフォルト ブート イメージの
変更 ....................................................................................................... 124
ダウングレード後の手順の実行 ............................................................................ 128
クラスタとSVMの健全性の確認 ................................................................ 128
LIFの有効化とホーム ポートへのリバート ................................................ 129
クライアント アクセスの確認（CIFSおよびNFS） ........................................ 130
SnapMirror処理の再開 .............................................................................. 131
SPファームウェアのダウングレードに関する注意事項 ............................ 131
リバートまたはダウングレード後の必要なVシリーズライセンスの再イ
ンストール .............................................................................................. 132
アップグレード実行中のサービスの可用性の最適化 ............................. 133
アップグレードがサービスの可用性に与える影響 ............................................... 133
サービスおよびプロトコルの注意事項 .................................................................. 134
ステートレス プロトコルの考慮事項 .......................................................... 134
セッション指向プロトコルの考慮事項 ........................................................ 135
ディスク ファームウェアのバックグラウンド更新について .................................... 135
著作権に関する情報 ................................................................................. 137
商標に関する情報 ..................................................................................... 138
ご意見をお寄せください ............................................................................ 139
索引 ............................................................................................................ 140
7
Data ONTAPクラスタのアップグレード
クラスタを最新のData ONTAPリリースにアップグレードするときは、まず準備を整え、クラスタをア
ップグレードし、最後にアップグレード後の手順をいくつか実行する必要があります。
注: アップグレードの計画にUpgrade Advisorを使用することを推奨します。 ただし、このガイドの
有用な詳細関連情報を参照して、Upgrade Advisorの計画に役立てることができます。
Upgrade Advisorを使用できない場合は、このガイドに示されているガイドラインを使用して、手
動で独自のアップグレード プランを作成する必要があります。
アップグレード プロセスは次のフェーズからなります。
•
•
•
アップグレードの準備
アップグレードの実行
アップグレード後の手順の実行
計画では、次のことを実行します。
•
•
ターゲットのData ONTAPリリースの『リリース ノート』の内容を確認します。
ネットアップ サポート サイトのInteroperability Matrixを調べて、構成に含まれるすべてのコンポ
ーネントがアップグレード後のData ONTAPリリースと互換性があることを確認します。
特に明記されていないかぎり、このガイドの要件および手順はサポートされる以下のすべてに適
用されます。
•
•
Data ONTAP 8.2.xプラットフォーム
サポート対象のプラットフォームの詳細については、ターゲットのData ONTAPリリースの『リリ
ース ノート』を参照してください。
Data ONTAP 8.2リリース ファミリーへのアップグレード パスと リリース ファミリー内でのアップ
グレード パス
サポートされるアップグレード パスには、Data ONTAP 8.2リリース ファミリーのリリースへの任
意の8.1.xリリースからのアップグレード（メジャー アップグレード）と8.2.xから8.2.zへのアップグ
レード（マイナー アップグレード）があります。
関連情報
NetApp Interoperability Matrix：support.netapp.com/NOW/products/interoperability
8 | アップグレードおよびリバート / ダウングレード ガイド
Upgrade Advisorを使用したアップグレードの計画
Upgrade Advisorツールを使用して（ご使用の環境で利用できる場合）、現行リリースへのアップグ
レード要件を満たしているか確認し、アップグレード計画を作成する必要があります。
開始する前に
Upgrade Advisorツールを使用するには、ご使用のシステムが次の要件を満たしている必要があり
ます。
•
•
有効なサポート契約がある。
NetAppへのAutoSupportメッセージ送信が有効になっている。
注意: システムが上記の要件を満たしていない場合は、このData ONTAPリリースの『リリース ノ
ート』や『アップグレード ガイド』を参照して、詳細なアップグレード プランを作成してください。
タスク概要
Upgrade Advisorはネットアップ サポート サイトから入手できるオンライン ツールであり、Data
ONTAPのアップグレードの計画プロセスを簡素化します。 システムの識別情報およびターゲット
リリースをUpgrade Advisorに送信すると、システムに関するAutoSupportデータが、ターゲット リリ
ースに関する既知の要件および制限事項に対して照合されます。 その後Upgrade Advisorにより、
アップグレード プラン（およびオプションでバックアウト プラン）が作成され、推奨される準備手順お
よび実行手順が提示されます。
アップグレード プランを生成するには、システムのホスト名、システムID、シリアル番号のいずれ
かを確認しておく必要があり、ターゲットとなるアップグレード リリースを選択しておく必要がありま
す。 また、次のようなその他のオプションも選択できます。
•
•
•
クラスタのプラン作成
バックアウト プランの作成
アップグレード シナリオの比較
Upgrade Advisorの詳細については、Upgrade Advisorのヘルプ画面を参照してください。
手順
1. システムのホスト名、システムID、シリアル番号のいずれかを確認し、記録します。これには、
clustershellで次のコマンドを入力します。
system node run -node nodename sysconfig
システムIDの情報は、ディスプレイの上部付近に表示されます。
2. Webブラウザから、ネットアップ サポート サイトのMy AutoSupportホームページ（URL：
support.netapp.com/NOW/asuphome）にログインします。
3. [Launch My AutoSupport]リンクをクリックします。
Data ONTAPクラスタのアップグレード | 9
4. メッセージに従い、システムのホスト名、システムID、シリアル番号のいずれかを入力します。
5. アップグレードするシステムをリストされた中から選択します。
6. ASUP行から最新のAutoSupportレコードを選択します。
7. [Upgrade Advisor]タブをクリックします。
8. [Target Versions]メニューからアップグレードするData ONTAPリリースを選択します。
9. アップグレード プランに含めるアップグレード方式および詳細レベルを選択します。
10. [Continue]をクリックして、アップグレード プランを生成します。
終了後の操作
Upgrade Advisorを使用してアップグレード プランを生成、実行したら、この『アップグレード ガイド』
の手順に従う必要はありません。 ただし、詳細や背景について確認したい場合にこのガイドを利
用できます。
関連情報
Upgrade Advisor：support.netapp.com/NOW/asuphome
アップグレードの計画
Data ONTAPではリリースの更新のたびに新機能が追加されるため、新機能および関連するアッ
プグレード要件について理解し、アップグレードが現在の構成にどのような影響を与えるかを評価
する必要があります。 Data ONTAPの2つ以上前のリリースからアップグレードする場合は問題が
発生する可能性が高くなります。
注: アップグレードの計画にUpgrade Advisorを使用することを推奨します。ただし、このガイドの
有用な詳細関連情報を参照して、Upgrade Advisorの計画に役立てることができます。
Upgrade Advisorを使用できない場合は、このガイドに示されているガイドラインを使用して、手
動で独自のアップグレード プランを作成する必要があります。
アップグレードを開始する前に、次の作業を計画する必要があります。
•
•
•
•
•
Data ONTAPのアップグレード ターゲット リリースの『リリース ノート』の内容を確認します。
既存のソフトウェアからターゲット リリースにアップグレードするための要件を把握します。
アップグレード実行後のシステムの潜在的な動作変更を把握します。
アップグレード チェックリストの全項目に対処する準備をします。
万一問題が発生して、以前の（アップグレード前にシステムで実行されていた）Data ONTAPリ
リースにリバートまたはダウングレードする必要が生じたときのために、バックアウト プランを作
成します。
10 | アップグレードおよびリバート / ダウングレード ガイド
特に示されていないかぎり、このガイドの要件および手順はサポート対象のすべてのData ONTAP
8.2.xプラットフォームに適用されます。 サポート対象のプラットフォームの詳細については、この
Data ONTAPリリースの『リリース ノート』を参照してください。
関連コンセプト
以前のData ONTAPリリース ファミリーへのクラスタのリバート（77ページ）
同じ リリース ファミリーの以前のリリースにクラスタをダウングレードする（109ページ）
クラスタのアップグレードの種類
クラスタを新しいData ONTAPリリースにアップグレードするときは、要件に応じて、無停止アップグ
レードまたは停止を伴うアップグレードのいずれかを実行できます。
無停止アップグレード（NDU）では、クラスタをオンラインにしたままアップグレードが実行され、アッ
プグレード中もデータの提供が継続されます。 NDUの実行方法は2種類あります。
•
•
ローリング アップグレード
この方法では、ノードを1つずつオフラインにしてアップグレードし、その間そのノードのストレー
ジをパートナーにフェイルオーバーします。 一方のノードのアップグレードが完了したら、パート
ナーから元のノードに制御を戻し、今度はパートナーで同じ処理を行います。 HAペアのそれぞ
れについて、すべてのペアがターゲット リリースに切り替わるまで順番にアップグレードを行い
ます。
この方法はクラスタのサイズに関係なく使用できます。ただし、2～6ノードのクラスタでは、必ず
この方法を使用する必要があります。
バッチ アップグレード
この方法では、クラスタをそれぞれ複数のHAペアを含む2つのバッチに分けます。 最初のバッ
チで、各HAペアの一方のノードをオフラインにしてアップグレードし、その間それぞれのノード
のストレージをパートナーにフェイルオーバーします。 すべてのHAペアの一方のノードのアッ
プグレードが完了したら、それぞれのパートナーから対応するノードに制御を戻し、今度はパー
トナーで同じ処理を行います。 その後、2つ目のバッチでも同じ処理を行います。
この方法は8ノード以上のクラスタでのみ使用できます。
停止を伴うアップグレードでは、クラスタをオフラインにしてアップグレードを実行します。 このアッ
プグレードでは、各HAペアのストレージ フェイルオーバーを無効にしてから各ノードをリブートしま
す。
停止を伴うアップグレードはクラスタのサイズに関係なく実行できます。
クラスタのアップグレードのチェックリスト
このチェックリストを使用して、アップグレードの準備から、アップグレードの実行、アップグレード後
の手順の実行まで、進捗を記録しながら進めることができます。
アップグレードの準備手順
準備手順は、次の条件がすべて当てはまると完了します。
Data ONTAPクラスタのアップグレード | 11
状態
ターゲット リリースのソフトウェアおよびハードウェアのサポート
を確認した。
ハードウェアのサポートを確認するには、『Hardware Universe』
（旧称は『システム構成ガイド』）support.netapp.com/knowledge/
docs/hardware/NetApp/syscfg/index.shtmlを参照してください。
クラスタ ネットワーク スイッチと管理ネットワーク スイッチがサ
ポートされている。
クラスタおよび管理イーサネット スイッチで使用するソフトウェ
ア、ファームウェア、およびリファレンス構成ファイルには、Data
ONTAPとの互換性が必要です。 Data ONTAPの導入またはア
ップグレードを計画する際に、Cluster and Management Ethernet
Switch Matrixを参照して、スイッチ構成の更新も必要かどうか
を確認する必要があります。
SAN構成が完全にサポートされている。
ターゲットのData ONTAPソフトウェア バージョン、ホストOSおよ
びパッチ、必須のHost Utilitiesソフトウェア、アダプタ ドライバお
よびファームウェアなど、すべてのSANコンポーネントは、ネット
アップ サポート サイトのInteroperability Matrixにリストされてい
ます。
リリース固有のアップグレードの問題がすべて解決されている。
クラスタシェルのアクセス権限がある。
パフォーマンスのベースラインを作成した。
パフォーマンスのベースラインは、Perfstat Convergedを使用して
作成します。
各ノードについてリモート管理デバイスが設定されている。
サービス プロセッサ（SP）またはRemote LAN Module（RLM）を
設定しておく必要があります。 詳細については、『clustered Data
ONTAP システム アドミニストレーション ガイド（クラスタ管理）』
を参照してください。
クラスタがクォーラムにある。
すべてのノードがクォーラムに参加しており、すべてのリングが
クォーラム内にあることを確認します。 また、リングごとのクォー
ラム マスターがすべてのノードで同一であることを確認します。
完了
12 | アップグレードおよびリバート / ダウングレード ガイド
状態
クラスタとSVMが正常に実行されている。
アップグレードの処理を進める前に、すべてのアグリゲートとボ
リュームがオンラインで正常に動作していることを確認する必要
があります。 ノードのステータスは、cluster showコマンドを
使用して確認できます。
LIFがオンラインで、それぞれの正しいホーム ポートにある。
LIFの設定は、network interfaceコマンドを使用して表示お
よび変更できます。
LIFフェイルオーバーの設定を確認した。
各データLIFに正しいフェイルオーバー ポリシー、フェイルオー
バー グループ、およびフェイルオーバー ターゲットが適用され
ている必要があります。
LIFの自動リバランシングが無効になっている（バッチ アップグ
レードのみ）。
システム時間がクラスタ全体で同期されている。
各ノードでData ONTAP 8.1以降を実行している。
system node image showコマンドを実行して、実行している
ソフトウェアのバージョンがアップグレードに対応したバージョン
以上であることを確認します。
ターゲットのData ONTAPソフトウェア イメージがHTTPサーバ
にある。
ターゲットのData ONTAPリリースのソフトウェア イメージをネッ
トアップ サポート サイト：support.netapp.comからダウンロード
し、各ノードからアクセスできるHTTPサーバに格納します。
ターゲットのData ONTAPソフトウェア イメージが各ノードにイン
ストールされ、代替ブート デバイス イメージとして設定されてい
る。
ソフトウェア イメージは、 system node image updateコマン
ドを使用してインストールできます。 ソフトウェア イメージが各ノ
ードに代替ブート イメージとしてインストールされているかどう
かは、system node image showコマンドを使用して確認でき
ます。
SnapMirror処理が一時中止されている。
完了
Data ONTAPクラスタのアップグレード | 13
状態
完了
実行中のジョブがない。
アグリゲート、ボリューム、ミラー、NDMP（ダンプまたはリスト
ア）、またはSnapshotに関する実行中のジョブ（作成、削除、移
動、変更、複製、マウントなど）やキューに格納されているジョブ
がある場合は、ジョブが完了するまで待つか、キューのエントリ
を中止します。
ローリング アップグレードの実行手順
ローリング アップグレード方式で無停止アップグレードを実行する場合、アップグレードは次の手
順をすべて実行すると完了になります。
状態
完了
クラスタの無停止アップグレードを実行する準備が完了していることを確認し
た。
最初のHAペアのアップグレードが完
了している。
HAペアの最初のノードのアップグレ
ードが完了している。
ノードのパートナーのアップグレード
が完了している。
HAペアが正常にアップグレードされ
たことを確認した。
2つ目のHAペアのアップグレードが
完了している（必要な場合）。
HAペアの最初のノードのアップグレ
ードが完了している。
ノードのパートナーのアップグレード
が完了している。
HAペアが正常にアップグレードされ
たことを確認した。
3番目のHAペアのアップグレードが
完了している（必要な場合）。
HAペアの最初のノードのアップグレ
ードが完了している。
ノードのパートナーのアップグレード
が完了している。
HAペアが正常にアップグレードされ
たことを確認した。
クラスタのアップグレードが正常に完了したことを確認した。
14 | アップグレードおよびリバート / ダウングレード ガイド
バッチ アップグレードの実行手順
バッチ アップグレード方式で無停止アップグレードを実行する場合、アップグレードは次の手順を
すべて実行すると完了になります。
状態
完了
クラスタの無停止アップグレードを実行する準備が完了していることを確認し
た。
クラスタを2つのバッチに分けてある。
クラスタに含まれるHAペアの数が偶数の場合は、各バッチにHAペアを半分
ずつ含めます。 クラスタに含まれるHAペアの数が奇数の場合は、最初のバ
ッチに2つ目のバッチよりも1つ多くHAペアを含めます。
最初のバッチのアップグレードが完
了している。
それぞれのHAペアの最初のノードの
アップグレードが完了している。
ノードのパートナーのアップグレード
が完了している。
HAペアが正常にアップグレードされ
たことを確認した。
2つ目のバッチのアップグレードが完
了している。
それぞれのHAペアの最初のノードの
アップグレードが完了している。
ノードのパートナーのアップグレード
が完了している。
HAペアが正常にアップグレードされ
たことを確認した。
クラスタのアップグレードが正常に完了したことを確認した。
停止を伴うアップグレードの実行手順
停止を伴うアップグレードを実行する場合、アップグレードは次の手順をすべて実行すると完了に
なります。
状態
クラスタの停止を伴うアップグレードを実行する準備が完了していることを確
認した。
ストレージ フェイルオーバーを無効にして各ノードがリブートされている。
クラスタのアップグレードが正常に完了したことを確認した。
アップグレード後の手順
アップグレード後の手順は、次の条件がすべて当てはまると完了します。
完了
Data ONTAPクラスタのアップグレード | 15
状態
クラスタとSVMが正常に実行されている。
アップグレードの処理を進める前に、すべてのアグリゲートとボリュームがオ
ンラインで正常に動作していることを確認する必要があります。 ノードのステ
ータスは、cluster showコマンドを使用して確認できます。
LIFがオンラインで、それぞれの正しいホーム ポートにある。
LIFの設定は、network interfaceコマンドを使用して表示および変更でき
ます。
Infinite Volumeのネームスペース ミラー コンスティチュエントがある。
複数のノードにまたがるInfinite Volumeがクラスタに含まれている場合、ネー
ムスペース コンスティチュエントのデータを保護するためにネームスペース
ミラー コンスティチュエントを作成する必要があります。
クラスタ管理LIFがRemote Support Agent用に正しく設定されている。
クラスタ管理LIFは、SPデバイスまたはRLMデバイスごとにrsa setupコマ
ンドを使用して設定できます。
SnapMirror処理が再開されている。
無停止アップグレードを実行する前にSnapMirror処理を一時停止した場合
は、アップグレードの完了後に再開する必要があります。
古い形式のSnapMirror関係が更新されている。
Data ONTAP 8.2へのアップグレード前に使用していたSnapMirror関係で、
Data ONTAP 8.2の新しい機能や強化された機能を利用する場合は、Data
ONTAP 8.2の構文の形式を使用するようにSnapMirror関係を更新する必要
があります。
LIFの自動リバランシングが再有効化されている。
関連コンセプト
潜在的なアップグレードの問題の特定（22ページ）
ソフトウェアのアップグレードの実行（40ページ）
関連タスク
Data ONTAPクラスタのアップグレードの準備（25ページ）
クラスタのアップグレード後の手順の実行（61ページ）
完了
16 | アップグレードおよびリバート / ダウングレード ガイド
関連情報
Cluster and Management Ethernet Switch Support Matrix：support.netapp.com/NOW/download/
software/cm_switches
NetApp Interoperability Matrix：support.netapp.com/NOW/products/interoperability
クラスタのアップグレードに関する要件と制限
クラスタのアップグレードを実行する前に、クラスタのリリース、構成、および最大値の要件を確認
しておく必要があります。 また、アップグレードを実行する際は、異なるバージョンを混在させる場
合の要件についても注意してください。
リリースに関する要件
クラスタは、Data ONTAP 8.1.xのすべてのリリースからData ONTAP 8.2リリース ファミリーにアップ
グレードできます。
注: Data ONTAP GX 10.xを実行している場合は、クラスタをData ONTAP 8.2リリース ファミリー
に自分でアップグレードしないでください。この処理はサポートされていません。 必ずNetAppの
担当者にご連絡ください。
8.1よりも前のリリースからData ONTAP 8.2リリースにアップグレードする場合、Data ONTAP 8.2リ
リースにアップグレードする前に、最新のData ONTAP 8.1リリースへの中間アップグレード（複数ホ
ップ アップグレード）を実行する必要があります。
構成に関する要件
クラスタをアップグレードする際の構成に関する要件を次に示します。
•
•
障害ディスク ドライブはギブバック処理の妨げとなるばかりか、ループ状態からクラスタ全体の
不安定動作を招く可能性があるため、アップグレード プロセスを開始する前にすべて取り外す
か交換しておく。
障害ディスクの特定と取り外しの詳細については、『clustered Data ONTAP 物理ストレージ管
理ガイド』を参照してください。
NFSクライアントに対応しないクラスタにはハード マウントを使用する。
NFSタイムアウトが頻繁に発生する可能性がある場合、アップグレード プロセス中にシステム
がダウンしてデータが破損する可能性があるため、ソフト マウントは使用しないでください。
次の条件に1つでも当てはまる場合、アップグレードに支障をきたすおそれがあります。
•
•
ストレージ システムがクライアントに対して頻繁にCIFSサービスを提供している場合。
CIFSはセッション指向なので、データ損失を防ぐには、アップグレードの実行前にセッションを
終了する必要があります。
ストレージ システムが、処理を中断できないNetwork Data Management Protocol（NDMP）クラ
イアントに頻繁にサービスを提供している場合。
このプロトコルはセッション指向なので、無停止アップグレードを実行するには、実行中のセッ
ションを終了し、このサービスを無効にする必要があります。
Data ONTAPクラスタのアップグレード | 17
制限
それぞれのプラットフォームのシステム制限を超えないようにしてください。 SAN環境のシステム
制限については、『Clustered Data ONTAP SAN Configuration Guide』を参照してください。 また、
次のシステム要素に関しては、プラットフォームに関係なく、最大値を超えないように注意してくだ
さい。
項目
値（ノードあたり）
確認コマンド
FlexVol
500
volume show -node node_name
重複排除が有効化されて 500
いるFlexVol
Snapshotコピー
20,000
volume snapshot show
CPU利用率 *
50%以下
ディスク利用率 *
50%以下
node run -node node_name command sysstat -c 10 -x 3
* Data ONTAPをアップグレードする前に、CPUおよびディスク利用率を30秒間監視する必要があ
ります。 CPU列およびDisk Util列の値が、レポートされる10個すべての計測値で50パーセントを
超えないようにします。 アップグレードが完了するまで、ストレージ システムに新たな負荷がかか
らないようにする必要があります。
注: Performance and Statistics Collector（Perfstat Converged）ツールを使用して、アップグレード
後のパフォーマンスと比較するためのパフォーマンスのベースラインを把握する必要がありま
す。
異なるバージョンの混在に関する要件
Data ONTAPクラスタは、ごく一時的に異なるバージョンが混在した状態、つまり、クラスタのノード
ごとに異なるリリース ファミリーのData ONTAPが実行される状態にすることができます。 ただし、
すべてのノードで新しいターゲット リリースが実行されるまでは、アップグレードは完了していませ
ん。
クラスタに異なるバージョンが混在している間は、アップグレードに必要なコマンドを除き、クラスタ
の処理や構成を変更するコマンドは実行しないでください（監視処理は可能です）。
関連タスク
Perfstat Convergedを使用したパフォーマンスのベースラインの作成（25ページ）
18 | アップグレードおよびリバート / ダウングレード ガイド
バッチ アップグレードのアップグレード順序
バッチ アップグレードを実行するときは、ノードの各セットを特定の順序でアップグレードする必要
があります。 この順序に従うことで、NDUの実行中もクラスタを停止させることなくデータの提供を
継続できます。
次の図に、12ノード クラスタの場合のバッチ アップグレードの順序を示します。
注: この図のノード名は例であり、 適切なアップグレード順序を示すために番号を付けてありま
す。
このクラスタは、同数のHAペアを含む2つのバッチに分けられ、 次の順序でノードがアップグレー
ドされます。
Data ONTAPクラスタのアップグレード | 19
1. バッチ1：
a. node1、node3、node5を同時にアップグレードする。
b. node2、node4、node6を同時にアップグレードする。
2. バッチ2：
a. node7、node9、node11を同時にアップグレードする。
b. node8、node10、node12を同時にアップグレードする。
クラスタに含まれるHAペアの数が奇数の場合は、最初のバッチの方のHAペアの数を多くします。
たとえば、次の図は、14ノード クラスタの場合のバッチ アップグレードの順序を示したものです。こ
の図では、最初のバッチに4組のHAペアが含まれ、2つ目のバッチに3組のHAペアが含まれてい
ます。
この14ノード クラスタでは、次の順序でノードをアップグレードします。
20 | アップグレードおよびリバート / ダウングレード ガイド
1. バッチ1：
a. node1、node3、node5、node7を同時にアップグレードする。
b. node2、node4、node6、node8を同時にアップグレードする。
2. バッチ2：
a. node9、node11、node13を同時にアップグレードする。
b. node10、node12、node14を同時にアップグレードする。
アップグレード プロセス期間の見積もりに関するガイドライン
各HAペアごとに、準備手順の完了に約30分、アップグレードの実行に約60分、アップグレード後
の手順の完了に約30分かかるように計画する必要があります。
バッチ方式の無停止アップグレードでは、すべてのHAペアを同時にまとめてアップグレードできま
す。 したがって、バッチ アップグレードを使用したクラスタ アップグレードに要する時間は、クラスタ
の規模に関係なく、2つのHAペアをアップグレードする場合とほぼ同じです。
アップグレード期間のガイドラインは、代表的な構成とワークロードに基づいたものです。 これらの
ガイドラインを使用して、ご使用の環境の無停止アップグレードの実行に必要な時間を見積もるこ
とができます。
アップグレード時のInfinite Volumeに関する注意事項
クラスタをData ONTAP 8.1.1以降にアップグレードする際、クラスタにInfinite Volumeが含まれてい
る場合は、実行できるアップグレードの種類とアップグレード後に実行する必要がある手順につい
て理解しておく必要があります。
Infinite Volumeを含むクラスタをアップグレードするときは、次の種類のアップグレードを使用でき
ます。
•
•
無停止アップグレード（NDU）
Infinite Volumeを含むクラスタのNDUを実行する場合は、ローリング方式を使用します。
Infinite Volumeを含むクラスタのNDUをバッチ方式で実行することはできません。
停止を伴うアップグレード
Infinite Volumeを含むクラスタの停止を伴うアップグレードを実行する場合は、クラスタ内のノ
ードを一度に1つずつリブートし、前のノードのリブートが完了してから次のノードのリブートを実
行する必要があります。
注: テクニカル サポートが、Data ONTAP 8.1.xを実行しているInfinite Volumeに ネームスペース
コンスティチュエントのデータ保護ミラー コピーを作成している場合は、 ネームスペース コンス
ティチュエントのデータ保護ミラー コピーを含むノードを最初にアップグレードしてください。 ネー
ムスペース コンスティチュエントのデータ保護ミラー コピーをテクニカル サポートが作成してい
ない場合は、どのノードからアップグレードを開始してもかまいません。
アップグレード後、複数のノードにまたがるInfinite Volumeには、そのInfinite Volumeのネームス
ペース コンスティチュエントのデータを保護するために、ネームスペース ミラー コンスティチュエン
Data ONTAPクラスタのアップグレード | 21
トが必要となります。 ネームスペース ミラー コンスティチュエントは、アップグレード プロセスでは
自動的に作成されません。 Infinite Volumeに関するアップグレード後の手順を確認して、アップグ
レード後にネームスペース ミラー コンスティチュエントを作成する方法を検討してください。
アップグレードの完了後、Data ONTAP 8.2.xのデータ保護機能を有効にするためには、データ保
護ミラー関係に含まれるInfinite Volumeが、ソース クラスタとデスティネーション クラスタのInfinite
Volumeを備えたSVM間のピアリングを使用する必要があります。 SVMピアリングまたは新しい関
係機能は、アップグレード プロセスでは自動的に設定されません。 アップグレード後にSVMピアリ
ングまたは新しい関係機能を使用できるように、アップグレード後の手順を確認して、データ保護ミ
ラー関係をアップグレードする方法を検討してください。
関連コンセプト
クラスタのアップグレードの種類（10ページ）
関連タスク
アップグレード後のInfinite Volume用のネームスペース ミラー コンスティチュエントの作成（64
ページ）
古い形式のSnapMirror関係のアップグレード（67ページ）
SnapMirrorのアップグレード要件
SnapMirrorを実行しているクラスタをアップグレードする場合、デスティネーション ボリュームを含
む各ノードのSnapMirror処理を一時停止する必要があります。
SnapMirrorボリュームのレプリケーションでは、デスティネーション システムで、SnapMirrorソース
システムと同等以上のData ONTAPバージョンを使用する必要があります。 SnapMirror転送が失
敗しないようにするには、SnapMirror処理を一時停止する必要があります。また、ソース システム
よりも先にデスティネーション ボリュームをアップグレードしなければならない場合もあります。
NDUの実行時にSnapMirror処理を一時停止する
SnapMirror環境でアップグレードを行うときは、すべてのSnapMirror処理を一時停止してアップグ
レードを実行し、完了後にSnapMirror処理を再開する方法が一番簡単です。 ただし、この方法で
は、NDUを実行している間はSnapMirror転送が行われません。 バッチ アップグレードを実行する
場合や相互にボリュームをミラーリングしているノードがクラスタにある場合は、この方法を使用す
る必要があります。
一度に1つのデスティネーション ボリュームでSnapMirror処理を一時停止する
別の方法として、特定のデスティネーション ボリュームのSnapMirror転送を一時停止し、デスティ
ネーション ボリュームを含むノード（またはHAペア）、ソース ボリュームを含むノード（またはHAペ
ア）の順にアップグレードして、完了後にデスティネーション ボリュームのSnapMirror転送を再開す
ることもできます。 この方法を使用すると、デスティネーション ボリュームを含むノードとソース ボリ
22 | アップグレードおよびリバート / ダウングレード ガイド
ュームを含むノードをアップグレードしている間、他のすべてのデスティネーション ボリュームの
SnapMirror転送を継続できます。
この方法でアップグレードするときは、ローリング アップグレードを使用する必要があります。バッ
チ アップグレードは使用できません。
ネットワーク接続型ストレージ（NAS）用に構成されたストレージ システムでのSnapMirrorの実行の
詳細については、『clustered Data ONTAP データ保護ガイド』を参照してください。
潜在的なアップグレードの問題の特定
Data ONTAPのすべてのリリース ファミリーには、それぞれ固有のアップグレード要件があります。
アップグレードする際はあらかじめそれらの要件を把握しておく必要があります。
アップグレードする前に、次の内容を把握する必要があります。
•
•
新しいリリースにアップグレードする前に解決を要する問題
新しいリリースへのアップグレード後の新しいシステム動作
各Data ONTAPリリース ファミリーごとに多数の新機能が導入されるため、新しいリリース ファミリ
ーにアップグレードする際には問題が生じることがあります。
アップグレードの問題の詳細なリストについては、『リリース ノート』を確認してください。
Data ONTAP 8.2リリース ファミリーに関するアップグレードの問題
クラスタをData ONTAP 8.2以降のリリースにアップグレードする場合は、既知の技術的問題を確
認し、事前に解決しておく必要があります。
本ドキュメントの発行時点で判明している重要な問題について、概要を以下に示します。 ターゲッ
トのData ONTAPリリースの最新の『リリース ノート』にある「重要な注意事項」セクションで、アップ
グレードに影響を与える可能性がある問題の一覧を確認してください。
•
•
•
•
Data ONTAP 8.2にアップグレードしたあとは、license-list-info ZAPIはサポートされません。
そのため、Data ONTAP 8.2でサポートされているバージョンの管理ソフトウェアをインストール
する必要があります。
Data ONTAP 8.2以降、すべてのライセンス キーは28文字です。
Data ONTAP 8.2より前にインストールしたライセンスは、Data ONTAP 8.2にアップグレードした
あとのリリースでも有効です。 ただし、Data ONTAP 8.2にライセンスを再インストールする場
合、古いキーは受け付けられません。
Data ONTAP 8.2以降、ベースラインSPファームウェア イメージは、Data ONTAPイメージに同梱
されています。
SP自動更新機能がデフォルトで有効になっています。 SP更新は手動で開始することもできま
す。
Data ONTAPのアップグレードを実行中に、LUNに新しいリビジョン番号が割り当てられます。
Windows Server 2008およびWindows Server 2012は、新しいリビジョン番号を持つLUNを新し
いディスクと解釈し、ホストの再起動後にそれらのディスクをオフラインにします。このステータ
Data ONTAPクラスタのアップグレード | 23
•
•
•
•
•
•
•
•
•
•
スは、アップグレード後にWindowsの管理インターフェイスに表示されます。 Windows Server
2003はLUNのリビジョン番号を無視します。
Data ONTAP 8.1.2以降、ソフトウェアのインストールまたはアップグレードには、ディスク エラー
の検出および予測機能が強化されているDS14mk2 ATおよびDS4243ディスク シェルフの新し
いバージョンのディスク シェルフ ファームウェアが含まれています。
そのため、このバージョンのData ONTAPにアップグレードしたあとは、一部のディスク シェルフ
およびディスク モデルに関して、ディスク障害数が増加することがあります。
Flash Cacheモジュールを搭載した3210または3140システムは、clustered Data ONTAP 8.1以降
の8.2.xリリースにアップグレードしないでください。
Flash Cacheモジュールは、clustered Data ONTAP 8.1以降の8.2.xリリースを実行する3210また
は3140システムではサポートされません。
Data ONTAP 8.2以降では、NFSv2のサポートが廃止され、NFSv2のすべての機能がData
ONTAPから削除されています。
NFSv2プロトコルを使用する必要がある環境では、NFSv2の使用を中止するまでは、Data
ONTAP 8.2以降にアップグレードしないでください。
クラスタをData ONTAP 8.1.3以降にアップグレードすると、既存のすべてのSVMについて、enable-ejukeboxパラメータの設定がtrueに変更されます。
SVMを新規に作成するときの-enable-ejukeboxパラメータのデフォルト値もtrueに変更され
ています。
Data ONTAP 8.2以降では、ストライピングされたボリュームはサポートされなくなりました。
ストライピングされたボリュームがある環境では、Data ONTAP 8.2にアップグレードしないでくだ
さい。
flex_cloneライセンスがある場合、Data ONTAP 8.2へのアップグレード後に
licensed_feature.flex_cloneオプションをオンにする必要があります。
Data ONTAP 8.1.3以降では、オンボード ウィルス対策のサポートが廃止されています。
そのため、Data ONTAP 8.1.3以降にアップグレードする前に、オンボード ウィルス対策を無効
にし、すべてのオンデマンド ウィルス対策（AVOD）ジョブのスケジュールを解除する必要があ
ります。
SMB 3.0をサポートしていないバージョンからサポートしているバージョンにData ONTAPをアッ
プグレードした場合、マッピングされているSMB共有に対するWindows 8またはWindows 2012
Serverからの再接続が失敗し、「署名が無効です」というエラーが表示されることがあります。
Data ONTAP 8.2以降のリリースでは、SMB 3.0がサポートされます。
NFSクライアントのあるストレージ システムでNFSv4.1またはpNFSを使用する場合は、一定の
注意事項に従って環境内に適切に導入する必要があります。
ノードを対象としたNDMPモードでは、テープによるバックアップとリストア処理を実行するため
に、NDMP固有のクレデンシャルを使用してストレージ システムにアクセスする必要がありま
す。
24 | アップグレードおよびリバート / ダウングレード ガイド
Data ONTAP 8.2リリース ファミリーの動作の変更点
ここでは、クラスタをData ONTAP 8.2以降にアップグレードする場合に注意が必要なData ONTAP
の動作の変更点を示します。
本ドキュメントの発行時点で判明している重要な変更点について、概要を以下に示します。 Data
ONTAPのターゲット リリースの『リリース ノート』で「既知の問題および制限」セクションを確認し、
ターゲット リリースにアップグレード後の動作の変更点の詳細リストを参照してください。
•
•
•
•
•
•
•
•
•
•
•
Data ONTAP 8.2以降では、Network Time Protocol（NTP;ネットワーク タイム プロトコル）がクラ
スタ上で常に有効になります。
手動で時間を設定すると、その設定はクラスタ上のすべてのノードで有効になります。
Data ONTAP 8.2以降、Element Manager（ClusterViewを含む）は使用できません。
Data ONTAPコマンドライン インターフェイスまたはOnCommand System Manager（Webベース
のグラフィカルな管理インターフェイス）を使用して、クラスタを管理できます。
Data ONTAP 8.2以降では、アグリゲートSnapshotコピーの自動削除は常に有効で、無効にする
ことはできません。
以前のバージョンのData ONTAPでは、FlexVolのフラクショナル リザーブ設定を、0～100の任
意の値に設定できました。
Data ONTAP 8.2以降、フラクショナル リザーブ設定は0または100にのみ設定できます。
Data ONTAP 8.2以降では、WWNではなくSNに基づいてエイリアスが生成されます。
ノードを対象としたNDMPモードでは、テープによるバックアップとリストア処理を実行するため
に、NDMP固有のクレデンシャルを使用してストレージ システムにアクセスする必要がありま
す。
NFSクライアントのあるストレージ システムでNFSv4.1またはpNFSを使用する場合は、一定の
注意事項に従って環境内に適切に導入する必要があります。
Data ONTAP 8.2以降、すべてのライセンス キーは28文字です。
Data ONTAP 8.2より前にインストールしたライセンスは、Data ONTAP 8.2にアップグレードした
あとのリリースでも有効です。 ただし、Data ONTAP 8.2でライセンスを再インストールする場
合、古いキーは受け付けられません。
Data ONTAP 8.2以降、ベースラインSPファームウェア イメージは、Data ONTAPイメージに同梱
されています。
SP自動更新機能がデフォルトで有効になっています。 SP更新は手動で開始することもできま
す。
Data ONTAP 8.2にアップグレードする際、ノードごとにそれぞれリリース8.2とリリース8.1を実行
するように、クラスタを複数のバージョンが混在する構成にすることができます。
この状態にすると、クラスタ スイッチ ヘルスモニタでヘルス アラートが生成されることがありま
す。 これらのアラートによってトリガーされるAutoSupportメッセージには誤った件名が表示され
ます。
Data ONTAP 8.1で提供されているデフォルトのLDAPクライアント スキーマAD-SFUは、UNIX
（SFU）またはIdentity Management for UNIX（IDMU）では機能しません。
この問題は、Data ONTAP 8.2へのアップグレード中に修正されます。
Data ONTAPクラスタのアップグレード | 25
•
•
•
•
•
•
•
Data ONTAP 8.2へのアップグレード前に使用していたSnapMirror関係で、Data ONTAP 8.2の
新しい機能や強化された機能を利用する場合は、Data ONTAP 8.2の構文の形式を使用するよ
うにSnapMirror関係を更新する必要があります。
保留状態のクラスタ間SVMピア関係について、ローカル クラスタのクラスタ管理者がSVMピア
関係を削除し、同時にピア クラスタのクラスタ管理者がSVMピア関係を受け入れた場合、両ク
ラスタのSVMピア関係の整合性が失われることがあります。
192.168.1/24および192.168.2/24サブネット内のアドレスでLIFを設定しないでください。
それらのアドレスでLIFを設定すると、プライベートiWARPインターフェイスとの競合が生じ、ノ
ードのリブートまたはLIFの移行後にLIFをオンラインにできなくなることがあります。
ファスト パスは、クラスタのすべてのノードにおいてデフォルトで有効になります。
ただし、特定のシナリオでは、パフォーマンスの低下やソフトウェア アップグレードの失敗など
の問題を回避するため、ファスト パスを無効にする必要があります。
ボリュームのフラクショナル リザーブを0に設定している場合、使用するテクノロジまたはData
ONTAPの機能によっては、スペース不足エラーを回避するためにいくつかの予防措置を講じ
る必要があります。
FAS2240システムのe0P（デフォルト）以外のポートを使用するようにACPを構成すると、内蔵
ACPPモジュールのIOM6Eが応答しなくなり、ローカルのSASエクスパンダでACPが無効になり
ます。
ポートe0Pにハードウェアの問題がある場合を除き、FAS2240システムのACPには常にデフォ
ルトのポートを使用するようにしてください。
FlexCacheボリュームは、clustered Data ONTAP 8.2を実行する次のFASシステムでサポートさ
れていません：3140、3160、3210、および3240。
Data ONTAPクラスタのアップグレードの準備
クラスタに最新のData ONTAPリリースをインストールするときは、クラスタの健全性について事前
にいくつか確認する必要があります。たとえば、クラスタが正常に実行されていること、クラスタが
クォーラムにあること、SVMの健全性などを確認します。
Perfstat Convergedを使用したパフォーマンスのベースラインの作成
Performance and Statistics Collector（Perfstat Converged）はクラスタ診断データ収集ツールで、ネッ
トアップ サポート サイトで入手でき、アップグレード後に比較するためのパフォーマンスのベースラ
インを設定できます。 アップグレード前にPerfstatレポートを作成する必要があります。
タスク概要
一般的な使用時間帯にPerfstatレポートを作成してください。約30分かかります。
26 | アップグレードおよびリバート / ダウングレード ガイド
手順
1. ネットアップ サポート サイト（support.netapp.com/NOW/download/tools/perfstat）からPerfstat
Convergedをダウンロードします。
2. 一般的な使用時間帯に次のコマンドを入力します。
perfstat8 -m c -t 4 -i 5 node_management_IP_address
クラスタのノードにノード管理IPアドレスを使用できます。
終了後の操作
出力ファイルは、Data ONTAPのアップグレードの完了後も数週間保持してください。
クラスタがクォーラムにあることの検証
アップグレードを行う前に、すべてのノードがレプリケートされたデータベース（RDB）クォーラムに
参加していることと、すべてのリングがクォーラムにあることを検証する必要があります。 また、リ
ングごとのクォーラム マスターがすべてのノードで同じであることも確認する必要があります。
タスク概要
クラスタ レプリケーション リングとRDBクォーラムの詳細については、『clustered Data ONTAP シス
テム アドミニストレーション ガイド（クラスタ管理）』を参照してください。
手順
1. 権限レベルをadvancedに設定します。
set -privilege advanced
「y」を入力して、作業を続行します。
2. 各RDBプロセスを表示します。
表示するRDBプロセス
コマンド
管理アプリケーション
cluster ring show -unitname mgmt
ボリューム ロケーション データベース
cluster ring show -unitname vldb
仮想インターフェイス マネージャ
cluster ring show -unitname vifmgr
SAN管理デーモン
cluster ring show -unitname bcomd
例
cluster1::*> cluster ring show -unitname vldb
Node
UnitName Epoch DB Epoch DB Trnxs Master
------ -------- ----- -------- -------- ---------
Data ONTAPクラスタのアップグレード | 27
node0 vldb
154
154
node1 vldb
154
154
node2 vldb
154
154
node3 vldb
154
154
4 entries were displayed.
14847
14847
14847
14847
node0
node0
node0
node0
それぞれのプロセスで、次の構成の詳細を確認します。
リレーショナル データベースのエポックとデータベースのエポックが各ノードで一致するこ
と。
リングごとのクォーラム マスターがすべてのノードで同一であること。
各リングのクォーラム マスターが異なる場合がある点に注意してください。
•
•
3. admin権限レベルに戻ります。
set -privilege admin
4. SAN環境を使用している場合は、クラスタがSANクォーラムにあることを確認します。
event log show -messagename scsiblade.*
scsibladeイベント メッセージに、SCSIブレードがクォーラムにあることが示されます。
例
cluster::> event log show -messagename scsiblade.*
Time
Node
Severity
------------------- ---------------- ------------8/13/2012 14:03:51 node0
INFORMATIONAL
8/13/2012 14:03:51 node1
INFORMATIONAL
Event
--------------------------scsiblade.in.quorum: The scsi-blade ...
scsiblade.in.quorum: The scsi-blade ...
クラスタとSVMの健全性の確認
クラスタのアップグレード、リバート、またはダウングレードを行う際は、実行前と実行後に、ノード
が正常に機能していてクラスタに追加するための条件を満たしていること、およびアグリゲートとボ
リュームがオンラインであることを確認する必要があります。
手順
1. クラスタ内のノードがオンラインで、クラスタに追加するための条件を満たしていることを確認し
ます。
cluster show
例
cluster1::> cluster show
Node
Health
--------------------- ------node0
true
node1
true
Eligibility
-----------true
true
正常に機能していないノードや条件を満たしていないノードがある場合は、EMSログでエラーを
確認して適切に修正します。 EMSメッセージの詳細については、『clustered Data ONTAP シス
テム アドミニストレーション ガイド（クラスタ管理）』を参照してください。
28 | アップグレードおよびリバート / ダウングレード ガイド
クラスタの健全性に関する問題のトラブルシューティング方法については、ネットアップ サポー
ト サイトの技術情報アーティクル「Troubleshooting Workflow: RDB app out of quorum」を参照
してください。
2. すべてのアグリゲートがオンラインであることを確認するために、物理ストレージと論理ストレー
ジ（ストレージのアグリゲートも含む）の状態を表示します。
storage aggregate show -state !online
このコマンドを実行すると、オンラインでないアグリゲートが表示されます。
例
cluster1::> storage aggregate show -state !online
There are no entries matching your query.
アグリゲートの管理の詳細については、『clustered Data ONTAP 物理ストレージ管理ガイド』を
参照してください。
3. すべてのボリュームがオンラインであることを確認するために、オンラインでないボリュームを
表示します。
volume show -state !online
例
cluster1::> volume show -state !online
There are no entries matching your query.
ボリュームの管理の詳細については、『clustered Data ONTAP論理ストレージ管理ガイド』を参
照してください。
LIFの有効化とホーム ポートへのリバート
リブートを行うと、一部のLIFが関連付けられているフェイルオーバー ポートに移行されることがあ
ります。 クラスタのアップグレード、リバート、またはダウングレードを行う際は、実行前と実行後
に、ホーム ポートにないLIFを有効にしてリバートする必要があります。
タスク概要
network interface revertコマンドを実行すると、対応するホーム ポートにないLIFがホーム
ポートにリバートされます（ホーム ポートが稼働している場合）。 LIFのホーム ポートはLIFの作成
時に指定します。指定されているホーム ポートは、 network interface showコマンドを使用し
て確認できます。
手順
1. すべてのLIFのステータスを表示します。
network interface show
Data ONTAPクラスタのアップグレード | 29
例
SVMのすべてのLIFのステータスを表示する例を次に示します。
cluster1::> network interface show -vserver vs0
Logical
Status
Network
Vserver
Interface Admin/Oper Address/Mask
----------- ---------- ---------- -----------------vs0
data001
down/down 192.0.2.120/24
data002
down/down 192.0.2.121/24
data003
down/down 192.0.2.122/24
data004
down/down 192.0.2.123/24
data005
down/down 192.0.2.124/24
data006
down/down 192.0.2.125/24
data007
down/down 192.0.2.126/24
data008
down/down 192.0.2.127/24
8 entries were displayed.
Current
Current Is
Node
Port
Home
------------- ------- ---node0
node0
node0
node0
node0
node0
node0
node0
e0e
e0f
e2a
e2b
e0e
e0f
e2a
e2b
true
true
true
true
false
false
false
false
Status AdminステータスがdownになっているLIFやIs homeステータスがfalseになっている
LIFがある場合は次の手順に進みます。
2. データLIFを有効にします。
network interface modify {-role data} -status-admin up
例
cluster1::> network interface modify {-role data} -status-admin up
8 entries were modified.
3. LIFをそれぞれのホーム ポートにリバートします。
network interface revert *
このコマンドを実行すると、すべてのLIFがそれぞれのホーム ポートにリバートされ、すべての
LIFのホーム ステータスがtrueに変わります。
例
cluster1::> network interface revert *
8 entries were acted on.
4. すべてのLIFがそれぞれのホーム ポートにあることを確認します。
network interface show
例
次の例では、SVM vs0のすべてのLIFがそれぞれのホーム ポートにあります。
cluster1::> network interface show -vserver vs0
Logical
Status
Network
Vserver
Interface Admin/Oper Address/Mask
----------- ---------- ---------- -----------------vs0
data001
up/up
192.0.2.120/24
Current
Current Is
Node
Port
Home
------------- ------- ---node0
e0e
true
30 | アップグレードおよびリバート / ダウングレード ガイド
data002
up/up
data003
up/up
data004
up/up
data005
up/up
data006
up/up
data007
up/up
data008
up/up
8 entries were displayed.
192.0.2.121/24
192.0.2.122/24
192.0.2.123/24
192.0.2.124/24
192.0.2.125/24
192.0.2.126/24
192.0.2.127/24
node0
node0
node0
node1
node1
node1
node1
e0f
e2a
e2b
e0e
e0f
e2a
e2b
true
true
true
true
true
true
true
LIFフェイルオーバーの設定の確認
アップグレードを実行する前に、network interface showコマンドを使用してLIFフェイルオー
バーの設定を確認する必要があります。
タスク概要
LIFフェイルオーバーの設定と有効化の詳細については、『clustered Data ONTAP ネットワーク管
理ガイド』を参照してください。
手順
1. 各データ ポートのフェイルオーバー ポリシーを表示します。
network interface show -role data -failover
例
2つのデータLIFを含む2ノード クラスタでData ONTAP 8.1.xを実行している場合のデフォルトの
フェイルオーバーの設定の例を次に示します。
cluster1::> network interface show -role data -failover
Logical
Home
Failover
Failover
Vserver Interface
Node:Port
Group Usage
Group
-------- --------------- --------------------- --------------- --------------vs0
lif0
node0:e0b
system-defined
Failover Targets: node0:e0b, node0:e0c,
node0:e0d, node0:e0e,
node0:e0f, node1:e0b,
node1:e0c, node1:e0d,
node1:e0e, node1:e0f
vs1
lif1
node1:e0b
system-defined
Failover Targets: node1:e0b, node1:e0c,
node1:e0d, node1:e0e,
node1:e0f, node0:e0b,
node0:e0c, node0:e0d,
node0:e0e, node0:e0f
2つのデータLIFを含む2ノード クラスタでData ONTAP 8.2.xを実行している場合のデフォルトの
フェイルオーバーの設定の例を次に示します。
cluster1::> network interface show -role data -failover
Logical
Home
Failover
Failover
Vserver Interface
Node:Port
Policy
Group
-------- --------------- --------------------- --------------- ---------------
Data ONTAPクラスタのアップグレード | 31
vs0
lif0
node0:e0b
nextavail
system-defined
Failover Targets: node0:e0b, node0:e0c,
node0:e0d, node0:e0e,
node0:e0f, node1:e0b,
node1:e0c, node1:e0d,
node1:e0e, node1:e0f
lif1
node1:e0b
nextavail
system-defined
Failover Targets: node1:e0b, node1:e0c,
node1:e0d, node1:e0e,
node1:e0f, node0:e0b,
node0:e0c, node0:e0d,
node0:e0e, node0:e0f
vs1
Failover Targetsフィールドには、各LIFのフェイルオーバー ターゲットが優先順位の高いも
のから順番に表示されます。 たとえば、lif0のホーム ポート（node0のe0b）からのフェイルオー
バーでは、node0のポートe0cへのフェイルオーバーが最初に試行されます。 そのあと、e0cにフ
ェイルオーバーできない場合はnode0のポートe0dというように、順番にフェイルオーバーが試行
されます。
2. データ ポートが異なるVLANまたはサブネットにある場合は、それぞれのLIFに対してユーザ
定義のフェイルオーバー ポリシーが設定されていることを確認します。
VLANまたはサブネットごとに、network interface failover-groups createコマンドを
使用して、ユーザ定義のフェイルオーバー グループをそれぞれ作成する必要があります。 こ
れにより、LIFがネットワーク トポロジに基づいて正しくフェイルオーバーされるようになります。
3. フェイルオーバー ポリシーがdisabledに設定されているLIFがある場合は、network
interface modifyコマンドを使用してフェイルオーバーを有効にします。
4. それぞれのLIFについて、LIFのホーム ノードのアップグレード時に稼働したままにする別のノ
ードのデータ ポートがFailover Targetsフィールドに含まれていることを確認します。
フェイルオーバー グループにフェイルオーバー ターゲットを追加するには、network
interface failover-groups createコマンドを使用します。
LIFの自動リバランシングの無効化
バッチ アップグレードの実行前にLIFの自動リバランシングを無効にしておくことで、アップグレード
手順の実行中もLIFをオンラインのまま維持することができます。
タスク概要
LIFの自動リバランシングを有効にすると、LIFのフェイルオーバー ルールに基づいて、別のノード
の利用率が低いポートにLIFを移行できます。 ただし、バッチ アップグレードでは複数のノードを同
時にアップグレードできるため、LIFの自動リバランシングを有効にしているとリブート中のノードに
LIFが移行される可能性があります。
手順
1. 権限レベルをadvancedに設定します。
32 | アップグレードおよびリバート / ダウングレード ガイド
set -privilege advanced
2. LIFの自動リバランシングが有効になっているLIFを確認して記録します。
network interface show -allow-lb-migrate true
例
cluster1::*> network interface show -allow-lb-migrate true
Logical
Status
Network
Current
Current Is
Vserver
Interface Admin/Oper Address/Mask
Node
Port
Home
----------- ---------- ---------- ------------------ ------------------- ---vs0
data1
up/up
192.0.2.120/24
node0
e0e
true
data2
up/up
192.0.2.121/24
node0
e0f
true
data3
up/up
192.0.2.122/24
node1
e0e
true
data4
up/up
192.0.2.123/24
node1
e0f
true
data5
up/up
192.0.2.124/24
node2
e0e
true
data6
up/up
192.0.2.125/24
node2
e0f
true
data7
up/up
192.0.2.126/24
node3
e0e
true
data8
up/up
192.0.2.127/24
node3
e0f
true
8 entries were displayed.
自動リバランシングが有効になっているLIFを記録しておくのは、バッチ アップグレードの完了
後に再度有効にするためです。
3. 特定したそれぞれのLIFについて、LIFの自動リバランシングを無効にします。
network interface modify * -allow-lb-migrate false
4. admin権限レベルに戻ります。
set -privilege admin
システム時間の検証
NTPが構成され、クラスタ全体で時間が同期されていることを検証する必要があります。
タスク概要
システム時間の管理の詳細については、『clustered Data ONTAP システム アドミニストレーション
ガイド（クラスタ管理）』を参照してください。
Data ONTAPクラスタのアップグレード | 33
手順
1. system services ntp server showコマンドを使用して、それぞれのノードがNTPサーバに
関連付けられていることを確認します。
例
cluster1::> system services
Node
Server
------ -------------------node0
ntp1.example.com
ntp2.example.com
node1
ntp1.example.com
ntp2.example.com
node2
ntp1.example.com
ntp2.example.com
node3
ntp1.example.com
ntp2.example.com
ntp server show
Version
----------max
max
max
max
max
max
max
max
2. 各ノードの日付と時刻が同じであることを確認します。
実行しているData ONTAPのリリース
入力するコマンド
8.1.x
system node date show
8.2.x
cluster date show
例
cluster1::> cluster date show
Node
Date
--------- ------------------node0
4/6/2013 20:54:38
node1
4/6/2013 20:54:38
node2
4/6/2013 20:54:38
node3
4/6/2013 20:54:38
4 entries were displayed.
Timezone
------------------------GMT
GMT
GMT
GMT
34 | アップグレードおよびリバート / ダウングレード ガイド
各ノードで実行しているソフトウェア バージョンの確認
アップグレードを行うには、各ノードで実行しているソフトウェアのバージョンがアップグレードに対
応したバージョン以上でなければなりません。 ソフトウェアのバージョンは、 system node image
showコマンドを使用して確認できます。
タスク概要
Data ONTAP 8.2.xに直接アップグレードできるのは、Data ONTAP 8.1以降を実行しているクラスタ
だけです。
手順
1. 現在のソフトウェアのバージョンを確認します。
system node image show
例
cluster1::> system node image show
Is
Is
Node
Image
Default Current Version
-------- ------- ------- ------- --------node0
image1 true
true
8.1.2
image2 false
false
8.1.0
node1
image1 true
true
8.1.2
image2 false
false
8.1.0
4 entries were displayed.
Install
Date
------------------10/25/2012 12:36:46
11/27/2011 12:58:24
10/25/2012 12:34:22
11/27/2011 12:58:26
Data ONTAPソフトウェア イメージの取得
各ノードからsystem node image updateコマンドを使用してアクセスできるように、ネットアップ
サポート サイトからネットワーク上のHTTPサーバにソフトウェア イメージをコピーする必要があり
ます。
タスク概要
クラスタをData ONTAPの目的のリリースにアップグレード、リバート、またはダウングレードするに
は、ソフトウェア イメージが必要です。 ソフトウェア イメージ、ファームウェアのバージョン情報、ス
トレージ システム モデルの最新のファームウェアは、ネットアップ サポート サイトで入手できます。
次の重要情報に注意してください。
•
•
ソフトウェア イメージはストレージ システム モデルに固有です。
ご使用のシステムに適したイメージを取得してください。
ソフトウェア イメージには、Data ONTAPの特定のバージョンのリリース時点でのシステム ファ
ームウェアの最新バージョンが含まれています。
Data ONTAPクラスタのアップグレード | 35
手順
1. ネットアップ サポート サイトの[Software Downloads]領域で目的のData ONTAPソフトウェアを
見つけます。
2. ネットアップ サポート サイトから、イメージを提供するHTTPサーバ上のディレクトリにソフトウェ
ア イメージ（82_setup_i.tgzなど）をコピーします。
関連情報
ソフトウェアのダウンロード：support.netapp.com/NOW/cgi-bin/software
クラスタでのData ONTAP 8.xソフトウェア イメージのインストール
必要に応じて、デフォルトの設定はData ONTAP 8.xの現在のバージョンのまま、Data ONTAP 8.x
イメージのソフトウェア パッケージをインストールすることができます。
開始する前に
Data ONTAPソフトウェア イメージを入手しておく必要があります。
手順
1. 要件に応じて、次のいずれかの処理を行います。
状況
コマンド
ソフトウェア イメージ system node image get -node * -package location replace-package true -background true
をダウンロードする
（インストールは行わ
このコマンドを実行すると、ソフトウェア イメージがすべてのノードに同時にダウ
ない）
ンロードされます。 一度に1つずつ各ノードにイメージをダウンロードする場合
は、-backgroundパラメータを指定せずに実行します。
すでにダウンロードし system node image update -node * -packagefile:///
てあるソフトウェア イ mroot/etc/software/image_name -background true
メージをインストール
このコマンドを実行すると、ソフトウェア イメージがすべてのノードに同時にインス
する
トールされます。 一度に1つずつ各ノードにイメージをインストールする場合は、backgroundパラメータを指定せずに実行します。
ソフトウェア イメージ system node image update -node * -package location のダウンロードとイン replace-package true -background true
ストールを1回の操作
このコマンドを実行すると、ソフトウェア イメージがすべてのノードに同時にダウ
で行う
ンロードされてインストールされます。 一度に1つずつ各ノードにイメージをダウン
ロードしてインストールする場合は、-backgroundパラメータを指定せずに実
行します。
2. ソフトウェア イメージが各ノードにダウンロードおよびインストールされたことを確認します。
36 | アップグレードおよびリバート / ダウングレード ガイド
system node image show-update-progress -node *
このコマンドを実行すると、ソフトウェア イメージのダウンロードとインストールについての現在
の状態が表示されます。 すべてのノードのRun StatusがExitedになり、Exit Statusが
Successになるまで、このコマンドを繰り返し実行します。
例
次の例では、2ノード クラスタの両方のノードでソフトウェア イメージのダウンロードとインストー
ルが正常に完了しています。
cluster1::> system node image show-update-progress -node *
There is no update/install in progress
Status of most recent operation:
Run Status:
Exited
Exit Status:
Success
Phase:
Run Script
Exit Message:
Installation complete. image2 updated on node node0.
There is no update/install in progress
Status of most recent operation:
Run Status:
Exited
Exit Status:
Success
Phase:
Run Script
Exit Message:
Installation complete. image2 updated on node node1.
2 entries were acted on.
クラスタでのData ONTAPソフトウェア イメージの格納と切り替えの仕組み
クラスタ内の各ノードは、現在実行しているイメージとブート可能な代替イメージの2つのData
ONTAPソフトウェア イメージを保持することができます。
クラスタ内の各ノードのソフトウェア イメージは、system node image showコマンドを使用して確
認できます。 新しいソフトウェア イメージをダウンロードしてそのイメージにアップグレードしたとき
にイメージがどのように切り替わるかを次の例で説明します。
Data ONTAPイメージが切り替わる仕組み
ここでは、2ノード クラスタの例を示します。 各ノードにimage1（バージョン8.0.2）とimage2（バ
ージョン8.0.1）という2つのイメージがあります。 現在はどちらのノードでもimage1が実行され
ています（Is Current列で確認）。 ノードをリブートした場合は、どちらのノードも、デフォルトの
イメージとして設定（Is Default列で確認）されているimage1からブートします。 代替イメージ
は、どちらのノードもimage2です。
cluster1::> system node image show
Is
Is
Node
Image
Default Current Version
-------- ------- ------- ------- --------node0
image1 true
true
8.0.2
image2 false
false
8.0.1
node1
image1 true
true
8.0.2
Install
Date
------------------3/25/2011 12:36:46
10/15/2010 12:58:24
3/25/2011 12:34:22
Data ONTAPクラスタのアップグレード | 37
image2 false
false
4 entries were displayed.
8.0.1
10/15/2010 12:58:26
新しいソフトウェア イメージをダウンロードすると、代替イメージ（image2）のパッケージが新
しいパッケージで置き換えられますが、どちらのノードでも現在のイメージ（image1）が引き続
き実行されます。
cluster1::> system node image update -node * -package http://
10.28.99.99/8.1.1_q_image.tgz -replace-package true
ダウンロードが完了すると、バージョン8.1.1が代替イメージ（image2）として格納され、どちら
のノードでもバージョン8.0.2（image1）が引き続き実行されます。
cluster1::> system node image show
Is
Is
Node
Image
Default Current Version
-------- ------- ------- ------- --------node0
image1 true
true
8.0.2
image2 false
false
8.1.1
node1
image1 true
true
8.0.2
image2 false
false
8.1.1
4 entries were displayed.
Install
Date
------------------3/25/2011 12:36:46
6/15/2012 10:23:18
3/25/2011 12:34:22
6/15/2012 10:23:18
system node image modifyコマンドを使用してimage2をノードのデフォルトのイメージと
して設定すると、ノードのリブート後にimage2からブートするようになります。 image2をデフォ
ルトのイメージとして設定してノードをリブートした場合の例を次に示します。 イメージが切り
替わり、image1が代替イメージ、image2が現在のイメージになっています。
cluster1::> system node image show
Is
Is
Install
Node
Image
Default Current Version
Date
-------- ------- ------- ------- --------- ------------------node0
image1 false
false
8.0.2
3/25/2011 12:36:46
image2 true
true
8.1.1
6/15/2012 10:23:18
node1
image1 false
false
8.0.2
3/25/2011 12:34:22
image2 true
true
8.1.1
6/15/2012 10:23:18
4 entries were displayed.
38 | アップグレードおよびリバート / ダウングレード ガイド
無停止アップグレードまたは無停止ダウングレードを行うためのSnapMirror関係の準
備
Data ONTAPの無停止アップグレードまたは無停止ダウングレードを実行する前に、SnapMirrorの
動作を一時停止する必要があります。
タスク概要
SnapMirror処理の詳細については、snapmirrorのマニュアル ページおよび『clustered Data ONTAP
データ保護ガイド』を参照してください。
手順
1. snapmirror showコマンドを使用して、各SnapMirror関係のデスティネーション パスを確認し
ます。
2. それぞれのデスティネーション ボリュームについて、以降のSnapMirror転送を一時中止しま
す。
snapmirror quiesce -destination-path destination
例
Data ONTAP 8.1からアップグレードする場合の例を次に示します。この例では、SVM vs0およ
びクラスタcluster1からデスティネーション ボリュームvol1への転送を休止します。
cluster1::> snapmirror quiesce -destination-path cluster1://vs0/vol1
例
Data ONTAP 8.2リリース ファミリーの別のリリースにダウングレードする場合の例を次に示しま
す。この例では、SVM vs0からデスティネーション ボリュームvol1への転送を休止します。
cluster1::> snapmirror quiesce -destination-path vs0:vol1
3. 現在転送中のSnapMirror関係があるかどうかを確認します。
snapmirror show -status Transferring
現在転送中のSnapMirror関係がある場合は、転送が完了してからData ONTAPのアップグレ
ードを実行する必要があります。
4. データを転送中のSnapMirror関係がある場合は、転送を中止します。
snapmirror abort -destination-path destination -h
-hパラメータを指定すると、再開チェックポイントが破棄され、転送が完了した最後のSnapshot
コピーの状態にデスティネーション ボリュームがリストアされます。
Data ONTAPクラスタのアップグレード | 39
負荷共有ミラーの転送を中止する場合は、-foreground trueパラメータを使用する必要が
あります。
実行中のジョブがないことの確認
別のData ONTAPリリースにアップグレードまたはダウングレードする前に、クラスタ ジョブのステ
ータスを確認する必要があります。 アグリゲート、ボリューム、NDMP（ダンプまたはリストア）、ま
たはSnapshotに関する実行中のジョブ（作成、削除、移動、変更、複製、マウントなど）やキューに
格納されているジョブがある場合は、ジョブが完了するまで待つか、キューのエントリを中止しま
す。
手順
1. アグリゲート、ボリューム、またはSnapshotに関する実行中のジョブとキューに格納されている
ジョブのリストを確認します。
job show
例
cluster1::> job show
Owning
Job ID Name
Vserver
Node
------ ---------------- --------- -----------308114 mirror-daily-3587206
node-vserver
node1
Descr:Auto-replicate to 1 mirror(s)
308115 mirror-daily-3618985
node-vserver
node1
Descr:Auto-replicate to 1 mirror(s)
308116 mirror-daily-3619010
node-vserver
node1
Descr:Auto-replicate to 1 mirror(s)
308117 mirror-daily-3749547
node-vserver
node1
Descr:Auto-replicate to 1 mirror(s)
4 entries were displayed.
State
---------Running
Running
Queued
Queued
2. アグリゲート、ボリューム、またはSnapshotに関する実行中のジョブとキューに格納されている
ジョブを削除します。
job delete *
例
cluster1::> job delete *
4 entries were displayed.
状態がQueuedまたはDormantと表示されたジョブは、job showコマンドの出力に表示されるジ
ョブIDを使用して個別に削除しなければならない場合があります。
job delete -id job_id
40 | アップグレードおよびリバート / ダウングレード ガイド
3. 実行中またはキューに格納されているジョブがないことを確認します。
job show
例
cluster1::> job show
This table is currently empty.
ソフトウェアのアップグレードの実行
Data ONTAPソフトウェアをアップグレードするには、いくつかの作業を行う必要があります。最初
に実行中のジョブがないことを確認し、アップグレード方式を決め、そのアップグレード方式に応じ
た手順を実行します。
次のいずれかのアップグレード方式を選択できます。
•
•
•
ローリング アップグレード（無停止）
バッチ アップグレード（無停止）
停止を伴うアップグレード
また、SnapMirror環境でアップグレードを実行する場合は、次の指示に従う必要があります。
•
•
ノードを正しい順序でアップグレードします。
無停止アップグレードを実行する前にSnapMirror処理を一時停止します。
関連コンセプト
クラスタのアップグレードの種類（10ページ）
クラスタをアップグレードする準備が完了していることの確認
ターゲットのData ONTAPソフトウェアがインストールされていること、ストレージ フェイルオーバー
が有効になっていること、およびクラスタHAが有効になっていること（必要な場合）を確認する必要
があります。
手順
1. Data ONTAP 8.2ソフトウェアがインストールされていることを確認します。
system node image show
例
次の例では、両方のノードに代替イメージとしてバージョン8.2.0がインストールされています。
cluster1::> system node image show
Is
Is
Node
Image
Default Current Version
Install
Date
Data ONTAPクラスタのアップグレード | 41
-------- ------- ------- ------node0
image1 true
true
image2 false
false
node1
image1 true
true
image2 false
false
4 entries were displayed.
--------
-------------------
8.1.2
8.2.0
10/25/2012 12:37:36
4/22/2013 13:52:22
8.1.2
8.2.0
10/25/2012 12:41:16
4/22/2013 13:55:22
ターゲットのData ONTAPソフトウェア イメージのインストールの詳細については、「クラスタで
のData ONTAP 8.xソフトウェア イメージのインストール」を参照してください。
2. Data ONTAP 8.2ソフトウェア イメージをデフォルトのイメージとして設定します。
system image modify {-node * -iscurrent false} -isdefault true
3. Data ONTAP 8.2ソフトウェア イメージがデフォルトのイメージとして設定されていることを確認し
ます。
system node image show
例
次の例では、両方のノードでデフォルトのイメージとしてバージョン8.2.0が設定されています。
cluster1::> system node image show
Is
Is
Node
Image
Default Current Version
-------- ------- ------- ------- -------node0
image1 false
true
8.1.2
image2 true
false 8.2.0
node1
image1 false
true
8.1.2
image2 true
false
8.2.0
4 entries were displayed.
Install
Date
------------------10/25/2012 12:37:36
4/22/2013 13:52:22
10/25/2012 12:41:16
4/22/2013 13:55:22
4. 無停止アップグレードを実行する場合は、ハイアベイラビリティ構成を確認します。
a. ストレージ フェイルオーバーが有効になっていて実行可能であることを確認します。
storage failover show
例
次の例では、node0とnode1でストレージ フェイルオーバーが有効かつ実行可能な状態にな
っています。
cluster1::> storage failover show
Takeover
Node
Partner
Possible
-------------- -------------- -------node0
node1
true
node1
node0
true
2 entries were displayed.
State
------------------------------------Connected to node1
Connected to node0
ストレージ フェイルオーバーは、storage failover modifyコマンドを使用して有効にで
きます。
42 | アップグレードおよびリバート / ダウングレード ガイド
b. クラスタが2つのノードだけで構成されている（単一のHAペア）場合は、クラスタHAが構成さ
れていることを確認します。
cluster ha show
例
cluster1::> cluster ha show
High Availability Configured: true
クラスタHAは、cluster ha modifyコマンドを使用して有効にできます。
ローリング アップグレード方式によるData ONTAPクラスタの無停止アップグレード
無停止アップグレード（NDU）方式では、HAペアの各ノードでフェイルオーバー処理を開始し、フェ
イルオーバー元の（「障害」）システムを更新してからギブバックを開始します。この処理をクラスタ
内のそれぞれのHAペアに対して繰り返します。
開始する前に
アップグレード前の必要な準備作業を行い、クラスタをアップグレードする準備が完了したことを確
認する必要があります。
手順
1. HAペアの最初のノードのアップグレード（43ページ）
ノードのパートナーによるテイクオーバーを開始して、HAペアの最初のノードをアップグレード
します。 最初のノードをアップグレードしている間、ノードのデータはパートナーから提供されま
す。
2. HAペアの2つ目のノードのアップグレード（46ページ）
HAペアの最初のノードをアップグレードしたあと、そのノードでテイクオーバーを開始してパート
ナーをアップグレードします。 パートナーをアップグレードしている間、パートナーのデータは最
初のノードから提供されます。
3. HAペアが正常にアップグレードされたことの確認（49ページ）
HAペアの両方のノードをアップグレードしたあと、それらの両方のノードでターゲット リリースが
実行されていることを確認する必要があります。
4. 残りのHAペアについて、手順1から3を繰り返します。
終了後の操作
クラスタが正常にアップグレードされたことを確認します。
Data ONTAPクラスタのアップグレード | 43
関連参照情報
クラスタのアップグレードのチェックリスト（10ページ）
HAペアの最初のノードのアップグレード
ノードのパートナーによるテイクオーバーを開始して、HAペアの最初のノードをアップグレードしま
す。 最初のノードをアップグレードしている間、ノードのデータはパートナーから提供されます。
手順
1. 自動ギブバックが有効になっている場合は、HAペアの各ノードについて次のコマンドを入力し
て、両方のノードで無効にします。
storage failover modify -node nodename -auto-giveback false
2. 両方のノードで自動ギブバックが無効になっていることを確認します。
storage failover show -auto-giveback false
例
cluster1::> storage failover show -auto-giveback false
Takeover
Node
Partner
Possible State
-------------- -------------- -------- ------------------------------------node0
node1
true
Connected to node1
node1
node0
true
Connected to node0
2 entries were displayed.
3. ノードからLIFを移行します。
network interface migrate-all -node nodenameA
SANプロトコルのデータLIFは移行されません。 クラスタ内の各ノードにこれらのLIFがあれば、
アップグレード プロセスの実行時に代替パスからデータを提供できます。
クラスタへの接続にクラスタ管理LIFを使用しており、クラスタ管理LIFを現在このノードでホスト
している場合は、LIFの移行中にSSHセッションが一時的に切断されます。 LIFの移行が完了
すると、クラスタ管理LIFを通じてクラスタにログインできるようになります。
4. LIFが対応するフェイルオーバー ターゲットに移行されたことを確認します。
network interface show -data-protocol nfs -role data -curr-node
nodenameB
例
次の例では、node0のデータLIFがパートナー（node1）のポートe0bに移行されています。
cluster1::> network interface show -data-protocol nfs -role data -curr-node node1
Logical
Status
Network
Current
Current Is
Vserver
Interface Admin/Oper Address/Mask
Node
Port
Home
----------- ---------- ---------- ------------------ ------------- ------- ---vs0
lif1
up/up
192.0.2.130/24
node1
e0b
true
44 | アップグレードおよびリバート / ダウングレード ガイド
lif2
lif3
up/up
up/up
192.0.2.131/24
192.0.2.132/24
node1
node1
e0b
e0b
false
true
lif1
up/up
lif2
up/up
5 entries were displayed.
192.0.2.133/24
192.0.2.134/24
node1
node1
e0b
e0b
false
true
vs1
必要に応じて、network interface migrateコマンドを使用して、LIFをパートナー ノードの
別のポートに移行することもできます。
5. AutoSupport通知をトリガーします。
system node autosupport invoke -node nodenameA -type all -message
"starting_NDU"
このAutoSupport通知には、アップグレード直前のシステム ステータスの記録が含まれます。
これにより、アップグレード処理で問題が発生した場合に役立つトラブルシューティング情報が
保存されます。
AutoSupportメッセージを送信するように設定していない場合は、通知のコピーがローカルに保
存されます。
6. テイクオーバーを開始します。
storage failover takeover -ofnode nodenameA
テイクオーバーされたノードを新しいソフトウェア イメージでブートするには通常のテイクオーバ
ーが必要なため、-option immediateパラメータは指定しないでください。
最初のノードがブートし、Waiting for giveback状態になります。
7. テイクオーバーが正常に完了したことを確認します。
storage failover show
テイクオーバーが正常に完了した例を次に示します。 ノードnode0の状態はWaiting for
giveback、パートナーの状態はIn takeoverになっています。
例
cluster1::> storage failover show
Takeover
Node
Partner
Possible
-------------- -------------- -------node0
node1
node1
node0
false
2 entries were displayed.
State Description
------------------------------------Waiting for giveback (HA mailboxes)
In takeover
8. 8分待ってから、次の条件を満たしていることを確認します。
•
•
クライアントのマルチパス（導入している場合）が安定している。
クライアントがテイクオーバー中に発生するI/Oの中断から回復した。
回復までの時間はクライアントによって異なり、クライアント アプリケーションの特性によっ
ては8分以上かかることもあります。
9. アグリゲートを最初のノードに戻します。
Data ONTAPクラスタのアップグレード | 45
storage failover giveback –ofnode nodenameA
注意: 次のような状況が検出された場合、ギブバックは開始されず、エラー メッセージが表示
されてイベントが生成されます。
•
•
•
実行時間の長い処理（ASUPの生成など）
再開できない処理（アグリゲートの作成など）
エラー状態（ノード間のディスク接続不一致など）
ギブバックが開始されない場合は、次の手順を実行します。
a. エラー メッセージに示された「拒否」状態に対処して、特定された処理が正常に終了する
ようにします。
b. ギブバック コマンドを再度入力します。
storage failover giveback -ofnode nodenameA
または、メッセージおよびイベントが自分の環境にどのように影響するかを分析します。 拒
否状態でもそれほど影響がない場合は、次のコマンドを入力してギブバックの拒否を無視し
てもかまいません。
storage failover giveback –ofnode nodenameA -override-vetoes true
拒否を無視しても問題がないかどうかの判断に関する詳細については、『clustered Data
ONTAP ハイアベイラビリティ構成ガイド』を参照してください。
最初にルート アグリゲートがパートナー ノードに戻され、そのノードのブートが完了するとルー
ト以外のアグリゲートが戻されます。
10. すべてのアグリゲートが戻されたことを確認します。
storage failover show-giveback
テイクオーバーされたノードの状態がGiveback Statusフィールドに部分的なギブバック状態
として表示される場合は、作業を進める前に次の手順を実行します。
a. 戻されたアグリゲートを特定します。
storage aggregate show -node nodenameA
b. EMSログでエラーを確認して適切に修正します。
EMSメッセージの詳細については、『clustered Data ONTAP システム アドミニストレーション
ガイド（クラスタ管理）』を参照してください。
c. 手順10.aをもう一度実行して修正内容を確認します。
新しくブートしたシステムで、戻されたアグリゲートから順番にクライアントへのデータ提供が開
始されます。
11. LIFをノードにリバートします。
network interface revert *
このコマンドを実行すると、移行したLIFが元のノードに戻されます。
46 | アップグレードおよびリバート / ダウングレード ガイド
例
cluster1::> network interface revert *
8 entries were acted on.
12. クライアントにデータが提供されていることを確認します。
network interface show
network port show
13. AutoSupport通知をトリガーします。
system node autosupport invoke -node nodenameA -type all -message
"finishing_NDU"
HAペアのパートナー ノードのアップグレード
HAペアの最初のノードをアップグレードしたあと、そのノードでテイクオーバーを開始してパートナ
ーをアップグレードします。 パートナーをアップグレードしている間、パートナーのデータは最初の
ノードから提供されます。
手順
1. ノードからLIFを移行します。
network interface migrate-all -node nodenameB
SANプロトコルのデータLIFは移行されません。 クラスタ内の各ノードにこれらのLIFがあれば、
アップグレード プロセスの実行時に代替パスからデータを提供できます。
クラスタへの接続にクラスタ管理LIFを使用しており、クラスタ管理LIFを現在このノードでホスト
している場合は、LIFの移行中にSSHセッションが一時的に切断されます。 LIFの移行が完了
すると、クラスタ管理LIFを通じてクラスタにログインできるようになります。
2. LIFが対応するフェイルオーバー ターゲットに移行されたことを確認します。
network interface show -data-protocol nfs -role data -curr-nodenodenameA
例
次の例では、node1のデータLIFがパートナー（node0）のポートe0bに移行されています。
cluster1::> network interface show -data-protocol nfs -role data -curr-node node1
Logical
Status
Network
Current
Current Is
Vserver
Interface Admin/Oper Address/Mask
Node
Port
Home
----------- ---------- ---------- ------------------ ------------- ------- ---vs0
lif1
up/up
192.0.2.130/24
node0
e0b
true
lif2
up/up
192.0.2.131/24
node0
e0b
false
lif3
up/up
192.0.2.132/24
node0
e0b
true
vs1
lif1
up/up
192.0.2.133/24
node0
e0b
false
lif2
up/up
192.0.2.134/24
node0
e0b
true
5 entries were displayed.
Data ONTAPクラスタのアップグレード | 47
必要に応じて、network interface migrateコマンドを使用して、LIFをパートナー ノードの
別のポートに移行することもできます。
3. AutoSupport通知をトリガーします。
system node autosupport invoke -node nodenameB -type all -message
"starting_NDU"
このAutoSupport通知には、アップグレード直前のシステム ステータスの記録が含まれます。
これにより、アップグレード処理で問題が発生した場合に役立つトラブルシューティング情報が
保存されます。
AutoSupportメッセージを送信するように設定していない場合は、通知のコピーがローカルに保
存されます。
4. 次のいずれかのコマンドを使用してテイクオーバーを開始します。
アップグレード前のバージ
ョン
コマンド
Data ONTAP 8.2.xリリース
storage failover takeover -ofnode nodenameB
Data ONTAP 8.1.xリリース
storage failover takeover -ofnode nodenameB -option
allow-version-mismatch
allow-version-mismatchオプションを指定すると、メジャー リリース
アップグレードの実行時にHAペアでData ONTAPリリース ファミリーの異
なるバージョンの使用が可能になります。
テイクオーバーされたノードを新しいソフトウェア イメージでブートするには通常のテイクオーバ
ーが必要なため、-option immediateパラメータは指定しないでください。
テイクオーバーされたノードがブートし、Waiting for giveback状態になります。
5. テイクオーバーが正常に完了したことを確認します。
storage failover show
例
テイクオーバーが正常に完了した例を次に示します。 ノードnode1の状態はWaiting for
giveback、パートナーの状態はIn takeoverになっています。
cluster1::> storage failover show
Takeover
Node
Partner
Possible
-------------- -------------- -------node0
node1
node1
node0
false
2 entries were displayed.
State Description
------------------------------------In takeover
Waiting for giveback (HA mailboxes)
6. 8分待ってから、次の条件を満たしていることを確認します。
•
クライアントのマルチパス（導入している場合）が安定している。
48 | アップグレードおよびリバート / ダウングレード ガイド
クライアントがテイクオーバー中に発生するI/Oの中断から回復した。
回復までの時間はクライアントによって異なり、クライアント アプリケーションの特性によっ
ては8分以上かかることもあります。
•
7. アグリゲートをパートナー ノードに戻します。
storage failover giveback -ofnode nodenameB
注意: 次のような状況が検出された場合、ギブバックは開始されず、エラー メッセージが表示
されてイベントが生成されます。
•
•
•
実行時間の長い処理（ASUPの生成など）
再開できない処理（アグリゲートの作成など）
エラー状態（ノード間のディスク接続不一致など）
ギブバックが開始されない場合は、次の手順を実行します。
a. エラー メッセージに示された「拒否」状態に対処して、特定された処理が正常に終了する
ようにします。
b. ギブバック コマンドを再度入力します。
storage failover giveback -ofnode nodenameB
または、メッセージおよびイベントが自分の環境にどのように影響するかを分析します。 拒
否状態がそれほど深刻でない場合は、次のコマンドを入力してギブバックの拒否を無視する
ことができます。
storage failover giveback -ofnode nodenameB -override-vetoes true
拒否を無視しても問題がないかどうかの判断に関する詳細については、『clustered Data
ONTAP ハイアベイラビリティ構成ガイド』を参照してください。
最初にルート アグリゲートがパートナー ノードに戻され、そのノードのブートが完了するとルー
ト以外のアグリゲートが戻されます。
8. すべてのアグリゲートが戻されたことを確認します。
storage failover show-giveback
テイクオーバーされたノードの状態がGiveback Statusフィールドに部分的なギブバック状態
として表示される場合は、作業を進める前に次の手順を実行します。
a. 戻されたアグリゲートを特定します。
storage aggregate show -node nodenameB
b. EMSログでエラーを確認して適切に修正します。
EMSメッセージの詳細については、『clustered Data ONTAP システム アドミニストレーション
ガイド（クラスタ管理）』を参照してください。
c. 手順8.aをもう一度実行して修正内容を確認します。
新しくブートしたシステムで、戻されたアグリゲートから順番にクライアントへのデータ提供が開
始されます。
Data ONTAPクラスタのアップグレード | 49
9. LIFをノードにリバートします。
network interface revert *
このコマンドを実行すると、移行したLIFが元のノードに戻されます。
例
cluster1::> network interface revert *
8 entries were acted on.
10. クライアントにデータが提供されていることを確認します。
network interface show
network port show
11. AutoSupport通知をトリガーします。
system node autosupport invoke -node nodenameB -type all -message
"finishing_NDU"
HAペアが正常にアップグレードされたことの確認
HAペアの両方のノードをアップグレードしたあと、それらの両方のノードでターゲット リリースが実
行されていることを確認する必要があります。
手順
1. HAペアの両方のノードで 新しいData ONTAP 8.2ソフトウェアが実行されていることを確認しま
す。
system node image show
次の例では、両方のノードの現在のバージョンがバージョン8.2.0になっています。
cluster1::> system node image show
Is
Is
Node
Image
Default Current Version
-------- ------- ------- ------- -------node0
image1 true
true
8.2.0
image2 false
false
8.1.2
node1
image1 true
true
8.2.0
image2 false
false
8.1.2
4 entries were displayed.
Install
Date
------------------4/22/2013 13:52:22
10/25/2012 12:37:36
4/22/2013 13:55:22
10/25/2012 12:41:16
2. 自動ギブバックを無効にしていた場合は、両方のノードで再度有効にします。
storage failover modify -node nodename -auto-giveback true
3. 次のノードのペアをアップグレードする前に、クラスタがクォーラムにあること、およびサービス
が実行されていることを確認します。
50 | アップグレードおよびリバート / ダウングレード ガイド
クラスタがクォーラムにあるかどうかは、cluster showコマンドおよびcluster ring showコ
マンドを使用して確認できます。
終了後の操作
他のすべてのHAペアをアップグレードします。 すべてのHAペアをアップグレードしたら、クラスタ
が正常にアップグレードされたことを確認します。
バッチ方式によるData ONTAPクラスタの無停止アップグレード
クラスタにノードが8つ以上含まれている場合は、クラスタを2つのバッチに分けてData ONTAPをア
ップグレードできます。この方法では、最初のバッチに含まれるノードのセットをアップグレードし、
それらのハイアベイラビリティパートナーをアップグレードしてから、2つ目のバッチについても同じ
処理を実行します。
開始する前に
•
•
アップグレード前の必要な準備作業を行い、クラスタをアップグレードする準備が完了したこと
を確認する必要があります。
バッチ アップグレードでアップグレードする順序を決めておく必要があります。
タスク概要
Data ONTAP 8.1.xからアップグレードする際、クラスタにInfinite Volumeが含まれている場合は、
バッチ アップグレード方式は使用しないでください。 代わりに、ローリング アップグレード方式で無
停止アップグレードを実行するか、停止を伴うアップグレードを実行します。
手順
1. HAペアのバッチ単位での最初のノード セットのアップグレード（51ページ）
パートナーによるテイクオーバーを開始して、HAペアのバッチに含まれる最初のノード セットを
アップグレードします。 最初のノード セットを アップグレードしている間、ノードのデータはパー
トナーから提供されます。
2. HAペアのバッチ単位での2つ目のノード セットのアップグレード（54ページ）
ノードでテイクオーバーを開始して、HAペアのバッチに含まれるパートナー ノードをアップグレ
ードします。 パートナーをアップグレードしている間、ノードのデータは最初のノード セットから
提供されます。
3. バッチが正常にアップグレードされたことの確認（58ページ）
バッチに含まれるすべてのノードをアップグレードしたあと、それらのノードでターゲット リリース
が実行されていることを確認する必要があります。
4. 手順1から3を繰り返して、2つ目のバッチをアップグレードします。
Data ONTAPクラスタのアップグレード | 51
終了後の操作
クラスタが正常にアップグレードされたことを確認します。
関連コンセプト
バッチ アップグレードのアップグレード順序（18ページ）
関連参照情報
クラスタのアップグレードのチェックリスト（10ページ）
HAペアのバッチ単位での最初のノード セットのアップグレード
パートナーによるテイクオーバーを開始して、HAペアのバッチに含まれる最初のノード セットをア
ップグレードします。 最初のノード セットをアップグレードしている間、ノードのデータはパートナー
から提供されます。
手順
1. 各ノードについて次のコマンドを入力して、最初のバッチに含まれるHAペアの自動ギブバック
を無効にします。
storage failover modify -node nodename -auto-giveback false
2. バッチに含まれるノードで自動ギブバックが無効になっていることを確認します。
storage failover show -auto-giveback false
例
次の例では、バッチに含まれるすべてのノードで自動ギブバックが無効になっています。
cluster1::> storage failover show -auto-giveback false
Takeover
Node
Partner
Possible State
-------------- -------------- -------- ------------------------------------node0
node1
true
Connected to node1
node1
node0
true
Connected to node0
node2
node3
true
Connected to node3
node3
node2
true
Connected to node2
node4
node5
true
Connected to node5
node5
node4
true
Connected to node4
6 entries were displayed.
3. 最初のセットに含まれる各ノードについて次のコマンドを入力して、テイクオーバーするノードか
らLIFを移行します。
network interface migrate {-data-protocol nfs -role data -curr-node
source_node} -dest-node partner_node
SANプロトコルのデータLIFは移行されません。 クラスタ内の各ノードにこれらのLIFがあれば、
アップグレード プロセスの実行時に代替パスからデータを提供できます。
52 | アップグレードおよびリバート / ダウングレード ガイド
4. ノードの各パートナーについて次のコマンドを入力して、パートナーの適切なポートにLIFが移
行されたことを確認します。
network interface show -data-protocol nfs -role data -curr-node
partner_node
例
次の例では、node0のデータLIFがパートナー（node1）のポートe0bに移行されています。
cluster1::> network interface show -data-protocol nfs -role data -curr-node node1
Logical
Status
Network
Current
Current Is
Vserver
Interface Admin/Oper Address/Mask
Node
Port
Home
----------- ---------- ---------- ------------------ ------------- ------- ---vs0
lif1
up/up
192.0.2.130/24
node1
e0b
true
lif2
up/up
192.0.2.131/24
node1
e0b
false
lif3
up/up
192.0.2.132/24
node1
e0b
true
vs1
lif1
up/up
192.0.2.133/24
node1
e0b
false
lif2
up/up
192.0.2.134/24
node1
e0b
true
5 entries were displayed.
必要に応じて、network interface migrateコマンドを使用して、LIFをパートナー ノードの
別のポートに移行することもできます。
5. セットに含まれる各ノードについて次のコマンドを入力して、AutoSupport通知をトリガーします。
system node autosupport invoke -node nodename -type all -message
"starting_NDU"
このAutoSupport通知には、アップグレード直前のシステム ステータスの記録が含まれます。
これにより、アップグレード処理で問題が発生した場合に役立つトラブルシューティング情報が
保存されます。
AutoSupportメッセージを送信するように設定していない場合は、通知のコピーがローカルに保
存されます。
6. 最初のセットに含まれる各ノードについて次のコマンドを入力して、テイクオーバーを開始しま
す。
storage failover takeover -ofnode nodename
テイクオーバーされたノードを新しいソフトウェア イメージでブートするには通常のテイクオーバ
ーが必要なため、-option immediateパラメータは指定しないでください。
ノードがブートし、Waiting for giveback状態になります。
7. テイクオーバーが正常に完了したことを確認します。
storage failover show
例
テイクオーバーが正常に完了した例を次に示します。 最初のセットのノード（node0、node2、お
よびnode4）の状態はWaiting for giveback、パートナーの状態はIn takeoverになってい
ます。
Data ONTAPクラスタのアップグレード | 53
cluster1::> storage failover show
Takeover
Node
Partner
Possible
-------------- -------------- -------node0
node1
node1
node0
false
node2
node3
node3
node2
false
node4
node5
node5
node4
false
node6
node7
true
node7
node6
true
node8
node9
true
node9
node8
true
node10
node11
true
node11
node10
true
12 entries were displayed.
State Description
------------------------------------Waiting for giveback (HA mailboxes)
In takeover
Waiting for giveback (HA mailboxes)
In takeover
Waiting for giveback (HA mailboxes)
In takeover
Connected to node7
Connected to node6
Connected to node9
Connected to node8
Connected to node11
Connected to node10
8. 8分待ってから、次の条件を満たしていることを確認します。
クライアントのマルチパス（導入している場合）が安定している。
クライアントがテイクオーバー中に発生するI/Oの中断から回復した。
回復までの時間はクライアントによって異なり、クライアント アプリケーションの特性によっ
ては8分以上かかることもあります。
•
•
9. ノードの各パートナーについて次のコマンドを入力して、アグリゲートを元のノードに戻します。
storage failover giveback –ofnode nodename
注意: 次のような状況が検出された場合、ギブバックは開始されず、エラー メッセージが表示
されてイベントが生成されます。
•
•
•
実行時間の長い処理（ASUPの生成など）
再開できない処理（アグリゲートの作成など）
エラー状態（ノード間のディスク接続不一致など）
ギブバックが開始されない場合は、次の手順を実行します。
a. エラー メッセージに示された「拒否」状態に対処して、特定された処理が正常に終了する
ようにします。
b. ギブバック コマンドを再度入力します。
storage failover giveback -ofnode nodename
または、メッセージおよびイベントが自分の環境にどのように影響するかを分析します。 拒
否状態でもそれほど影響がない場合は、次のコマンドを入力してギブバックの拒否を無視し
てもかまいません。
storage failover giveback –ofnode nodename -override-vetoes true
拒否を無視しても問題がないかどうかの判断に関する詳細については、『clustered Data
ONTAP ハイアベイラビリティ構成ガイド』を参照してください。
最初にルート アグリゲートがパートナー ノードに戻され、それらのノードのブートが完了すると
ルート以外のアグリゲートが戻されます。
54 | アップグレードおよびリバート / ダウングレード ガイド
10. すべてのアグリゲートが戻されたことを確認します。
storage failover show-giveback
テイクオーバーされたノードの状態がGiveback Statusフィールドに部分的なギブバック状態
として表示される場合は、作業を進める前に次の手順を実行します。
a. 戻されたアグリゲートを特定します。
storage aggregate show -node nodename
b. EMSログでエラーを確認して適切に修正します。
EMSメッセージの詳細については、『clustered Data ONTAP システム アドミニストレーション
ガイド（クラスタ管理）』を参照してください。
c. 手順10.aをもう一度実行して修正内容を確認します。
新しくブートしたシステムで、戻されたアグリゲートから順番にクライアントへのデータ提供が開
始されます。
11. LIFを最初のセットのノードにリバートします。
network interface revert *
このコマンドを実行すると、移行したLIFが元のノードに戻されます。
例
cluster1::> network interface revert *
12 entries were acted on.
12. クライアントにデータが提供されていることを確認します。
network interface show
network port show
13. 最初のセットに含まれる各ノードについて次のコマンドを入力して、AutoSupport通知をトリガー
します。
system node autosupport invoke -node nodename -type all -message
"finishing_NDU"
HAペアのバッチ単位でのパートナー ノードのアップグレード
ノードでテイクオーバーを開始して、HAペアのバッチに含まれるパートナー ノードをアップグレード
します。 パートナーをアップグレードしている間、ノードのデータは最初のノード セットから提供され
ます。
手順
1. 2つ目のセットに含まれる各ノードについて次のコマンドを入力して、テイクオーバーするノード
からLIFを移行します。
Data ONTAPクラスタのアップグレード | 55
network interface migrate {-data-protocol nfs -role data -curr-node
source_node}-dest-node partner_node
SANプロトコルのデータLIFは移行されません。 クラスタ内の各ノードにこれらのLIFがあれば、
アップグレード プロセスの実行時に代替パスからデータを提供できます。
2. ノードの各パートナーについて次のコマンドを入力して、パートナーの適切なポートにLIFが移
行されたことを確認します。
network interface show -data-protocol nfs -role data -currnodepartner_node
例
次の例では、node1のデータLIFがパートナー（node0）のポートe0bに移行されています。
cluster1::> network interface show -data-protocol nfs -role data -curr-node node0
Logical
Status
Network
Current
Current Is
Vserver
Interface Admin/Oper Address/Mask
Node
Port
Home
----------- ---------- ---------- ------------------ ------------- ------- ---vs0
lif1
up/up
192.0.2.130/24
node0
e0b
false
lif2
up/up
192.0.2.131/24
node0
e0b
true
lif3
up/up
192.0.2.132/24
node0
e0b
false
vs1
lif1
up/up
192.0.2.133/24
node0
e0b
true
lif2
up/up
192.0.2.134/24
node0
e0b
false
5 entries were displayed.
必要に応じて、network interface migrateコマンドを使用して、LIFをパートナー ノードの
別のポートに移行することもできます。
3. 2つ目のセットに含まれる各ノードについて次のコマンドを入力して、AutoSupport通知をトリガ
ーします。
system node autosupport invoke -node nodename -type all -message
"starting_NDU"
このAutoSupport通知には、アップグレード直前のシステム ステータスの記録が含まれます。
これにより、アップグレード処理で問題が発生した場合に役立つトラブルシューティング情報が
保存されます。
AutoSupportメッセージを送信するように設定していない場合は、通知のコピーがローカルに保
存されます。
4. 2つ目のセットに含まれる各ノードについて次のいずれかのコマンドを入力して、テイクオーバ
ーを開始します。
アップグレード前のバージョ コマンド
ン
Data ONTAP 8.2.xリリース
storage failover takeover -ofnode nodename
56 | アップグレードおよびリバート / ダウングレード ガイド
アップグレード前のバージョ コマンド
ン
Data ONTAP 8.1.xリリース
storage failover takeover -ofnode nodename -option
allow-version-mismatch
allow-version-mismatchオプションを指定すると、メジャー リリース
アップグレードの実行時にHAペアでData ONTAPリリース ファミリーの異
なるバージョンの使用が可能になります。
テイクオーバーされたノードを新しいソフトウェア イメージでブートするには通常のテイクオーバ
ーが必要なため、-option immediateパラメータは指定しないでください。
テイクオーバーされたノードがブートし、Waiting for giveback状態になります。
5. テイクオーバーが正常に完了したことを確認します。
storage failover show
例
テイクオーバーが正常に完了した例を次に示します。 2つ目のセットのノード（node1、node3、お
よびnode5）の状態はWaiting for giveback、パートナーの状態はIn takeoverになってい
ます。
cluster1::> storage failover show
Takeover
Node
Partner
Possible
-------------- -------------- -------node0
node1
false
node1
node0
node2
node3
false
node3
node2
node4
node5
false
node5
node4
node6
node7
true
node7
node6
true
node8
node9
true
node9
node8
true
node10
node11
true
node11
node10
true
12 entries were displayed.
State Description
------------------------------------In takeover
Waiting for giveback (HA mailboxes)
In takeover
Waiting for giveback (HA mailboxes)
In takeover
Waiting for giveback (HA mailboxes)
Connected to node7
Connected to node6
Connected to node9
Connected to node8
Connected to node11
Connected to node10
6. 8分待ってから、次の条件を満たしていることを確認します。
•
•
クライアントのマルチパス（導入している場合）が安定している。
クライアントがテイクオーバー中に発生するI/Oの中断から回復した。
回復までの時間はクライアントによって異なり、クライアント アプリケーションの特性によっ
ては8分以上かかることもあります。
7. ノードの各パートナーについて次のコマンドを入力して、アグリゲートを元のノードに戻します。
storage failover giveback –ofnode nodename
注意: 次のような状況が検出された場合、ギブバックは開始されず、エラー メッセージが表示
されてイベントが生成されます。
Data ONTAPクラスタのアップグレード | 57
•
•
•
実行時間の長い処理（ASUPの生成など）
再開できない処理（アグリゲートの作成など）
エラー状態（ノード間のディスク接続不一致など）
ギブバックが開始されない場合は、次の手順を実行します。
a. エラー メッセージに示された「拒否」状態に対処して、特定された処理が正常に終了する
ようにします。
b. ギブバック コマンドを再度入力します。
storage failover giveback -ofnode nodename
または、メッセージおよびイベントが自分の環境にどのように影響するかを分析します。 拒
否状態でもそれほど影響がない場合は、次のコマンドを入力してギブバックの拒否を無視し
てもかまいません。
storage failover giveback –ofnode nodename -override-vetoes true
拒否を無視しても問題がないかどうかの判断に関する詳細については、『clustered Data
ONTAP ハイアベイラビリティ構成ガイド』を参照してください。
最初にルート アグリゲートがパートナー ノードに戻され、それらのノードのブートが完了すると
ルート以外のアグリゲートが戻されます。
8. すべてのアグリゲートが戻されたことを確認します。
storage failover show-giveback
テイクオーバーされたノードの状態がGiveback Statusフィールドに部分的なギブバック状態
として表示される場合は、作業を進める前に次の手順を実行します。
a. 戻されたアグリゲートを特定します。
storage aggregate show -node nodename
b. EMSログでエラーを確認して適切に修正します。
EMSメッセージの詳細については、『clustered Data ONTAP システム アドミニストレーション
ガイド（クラスタ管理）』を参照してください。
c. 手順8.aをもう一度実行して修正内容を確認します。
新しくブートしたシステムで、戻されたアグリゲートから順番にクライアントへのデータ提供が開
始されます。
9. LIFを2つ目のセットのノードにリバートします。
network interface revert *
このコマンドを実行すると、移行したLIFが元のノードに戻されます。
例
cluster1::> network interface revert *
12 entries were acted on.
58 | アップグレードおよびリバート / ダウングレード ガイド
10. クライアントにデータが提供されていることを確認します。
network interface show
network port show
11. 2つ目のセットに含まれる各ノードについて次のコマンドを入力して、AutoSupport通知をトリガ
ーします。
system node autosupport invoke -node nodename -type all -message
"finishing_NDU"
バッチが正常にアップグレードされたことの確認
バッチに含まれるすべてのノードをアップグレードしたあと、それらのノードでターゲット リリースが
実行されていることを確認する必要があります。
手順
1. 最初のバッチに含まれるすべてのノードで新しいData ONTAP 8.2ソフトウェアが実行されてい
ることを確認します。
system node image show
次の12ノードのクラスタの例では、最初のバッチのノード（node0～node5）の現在のバージョン
がバージョン8.2.0になっています。
cluster1::> system node image show
Is
Is
Node
Image
Default Current Version
-------- ------- ------- ------- -------node0
image1 true
true
8.2.0
image2 false
false
8.1.2
node1
image1 true
true
8.2.0
image2 false
false
8.1.2
node2
image1 true
true
8.2.0
image2 false
false
8.1.2
node3
image1 true
true
8.2.0
image2 false
false
8.1.2
node4
image1 true
true
8.2.0
image2 false
false
8.1.2
node5
image1 true
true
8.2.0
image2 false
false
8.1.2
node6
image1 true
false
8.2.0
image2 false
true
8.1.2
node7
image1 true
false
8.2.0
image2 false
true
8.1.2
node8
image1 true
false
8.2.0
image2 false
true
8.1.2
node9
image1 true
false
8.2.0
image2 false
true
8.1.2
node10
image1 true
false
8.2.0
Install
Date
------------------4/22/2013 13:52:22
10/25/2012 12:37:36
4/22/2013 13:55:22
10/25/2012 12:41:16
4/22/2013 13:52:22
10/25/2012 12:37:36
4/22/2013 13:55:22
10/25/2012 12:41:16
4/22/2013 13:52:22
10/25/2012 12:37:36
4/22/2013 13:55:22
10/25/2012 12:41:16
4/22/2013 13:52:22
10/25/2012 12:37:36
4/22/2013 13:55:22
10/25/2012 12:41:16
4/22/2013 13:52:22
10/25/2012 12:37:36
4/22/2013 13:55:22
10/25/2012 12:41:16
4/22/2013 13:52:22
Data ONTAPクラスタのアップグレード | 59
image2
false
true
8.1.2
10/25/2012 12:37:36
8.2.0
8.1.2
4/22/2013 13:55:22
10/25/2012 12:41:16
node11
image1 true
false
image2 false
true
12 entries were displayed.
2. 自動ギブバックを無効にしていた場合は、次のコマンドを入力して、最初のバッチに含まれる各
ノードで再度有効にします。
storage failover modify -node nodename -auto-giveback true
3. 次のノードのバッチをアップグレードする前に、クラスタがクォーラムにあること、およびサービ
スが実行されていることを確認します。
クラスタがクォーラムにあるかどうかは、cluster showコマンドおよびcluster ring showコ
マンドを使用して確認できます。
終了後の操作
最初のバッチと同じ手順で2つ目のバッチをアップグレードします。 両方のバッチをアップグレード
したら、クラスタが正常にアップグレードされたことを確認します。
停止を伴うData ONTAPクラスタのアップグレード
新しいData ONTAPリリースにアップグレードする際にクラスタをオフラインにしてもかまわない場
合は、停止を伴うアップグレードを使用できます。 この方法では、各HAペアのストレージ フィルオ
ーバーを無効にして、クラスタ内の各ノードのソフトウェアを更新し、完了したらストレージ フェイル
オーバーを再度有効にします。
開始する前に
アップグレード前の必要な準備作業を行い、クラスタをアップグレードする準備が完了したことを確
認する必要があります。
タスク概要
停止に伴うアップグレードの実行中は、各ノードがシングルノード システムとして機能します。 ノー
ドで障害が発生するとデータを利用できなくなります。
手順
1. 1組のHAペアで構成されたクラスタ（2ノード クラスタ）の場合は、クラスタのハイアベイラビリテ
ィを無効にします。
cluster ha modify -configured false
2. クラスタ内の各HAペアのストレージ フェイルオーバーを無効にします。
storage failover modify -node * -enabled false
3. クラスタ内の各ノードをリブートします。
system node reboot -node nodename
60 | アップグレードおよびリバート / ダウングレード ガイド
クラスタにInfinite Volumeが含まれていなければ、すべてのノードを同時にリブートしてもかま
いません。 ここでは、各ノードを1つずつリブートし、 前のノードのリブートが完了してから次のノ
ードのリブートを開始する必要があります。
各ノードが新しいData ONTAPイメージでブートします。 Data ONTAPログイン プロンプトが表示
され、リブート プロセスが完了したことが示されます。
4. 各ノードが新しいData ONTAPイメージでリブートされたら、新しい Data ONTAP 8.2ソフトウェア
が実行されていることを確認します。
system node image show
次の例では、両方のノードの現在のバージョンがバージョン8.2.0になっています。
cluster1::> system node image show
Is
Is
Node
Image
Default Current Version
-------- ------- ------- ------- -------node0
image1 true
true
8.2.0
image2 false
false
8.1.2
node1
image1 true
true
8.2.0
image2 false
false
8.1.2
4 entries were displayed.
Install
Date
------------------4/22/2013 13:52:22
10/25/2012 12:37:36
4/22/2013 13:55:22
10/25/2012 12:41:16
5. クラスタ内のそれぞれのHAペアのストレージ フェイルオーバーを有効にします。
storage failover modify -node * -enabled true
6. 1組のHAペアで構成されたクラスタ（2ノード クラスタ）の場合は、クラスタのハイアベイラビリテ
ィを有効にします。
cluster ha modify -configured true
クラスタが正常にアップグレードされたことの確認
すべてのHAペアをアップグレードしたあと、versionコマンドとsystem node upgrade-revert
showコマンドを使用して、アップグレードが正常に完了したこと、およびすべてのノードでターゲット
リリースが実行されていることを確認する必要があります。
手順
1. 権限レベルをadvancedに設定します。
set -privilege advanced
2. 次のコマンドを実行して、各ノードのアップグレードが完了していることを確認します。
system node upgrade-revert show
各ノードのステータスがcompleteになっている必要があります。
いずれかのノードについて失敗したことを示すステータスが表示された場合は、system node
upgrade-revert upgradeコマンドを実行します。 このコマンドを実行してもノードのアップグ
レードが完了しない場合は、すぐにテクニカル サポートに連絡してください。
Data ONTAPクラスタのアップグレード | 61
3. admin権限レベルに戻ります。
set -privilege admin
4. クラスタのバージョンがターゲットのData ONTAPリリースになっていることを確認します。
version
クラスタのバージョンがターゲットのData ONTAPリリースになっていない場合は、system
node upgrade-revert upgradeコマンドを実行してクラスタのバージョンを更新します。
クラスタのアップグレード後の手順の実行
クラスタをData ONTAPソフトウェアを最新のバージョンにアップグレードした場合は、アップグレー
ド後に追加の手順を実行する必要があります。
クラスタとSVMの健全性の確認
クラスタのアップグレード、リバート、またはダウングレードを行う際は、実行前と実行後に、ノード
が正常に機能していてクラスタに追加するための条件を満たしていること、およびアグリゲートとボ
リュームがオンラインであることを確認する必要があります。
手順
1. クラスタ内のノードがオンラインで、クラスタに追加するための条件を満たしていることを確認し
ます。
cluster show
例
cluster1::> cluster show
Node
Health
--------------------- ------node0
true
node1
true
Eligibility
-----------true
true
正常に機能していないノードや条件を満たしていないノードがある場合は、EMSログでエラーを
確認して適切に修正します。 EMSメッセージの詳細については、『clustered Data ONTAP シス
テム アドミニストレーション ガイド（クラスタ管理）』を参照してください。
クラスタの健全性に関する問題のトラブルシューティング方法については、ネットアップ サポー
ト サイトの技術情報アーティクル「Troubleshooting Workflow: RDB app out of quorum」を参照
してください。
2. すべてのアグリゲートがオンラインであることを確認するために、物理ストレージと論理ストレー
ジ（ストレージのアグリゲートも含む）の状態を表示します。
storage aggregate show -state !online
このコマンドを実行すると、オンラインでないアグリゲートが表示されます。
62 | アップグレードおよびリバート / ダウングレード ガイド
例
cluster1::> storage aggregate show -state !online
There are no entries matching your query.
アグリゲートの管理の詳細については、『clustered Data ONTAP 物理ストレージ管理ガイド』を
参照してください。
3. すべてのボリュームがオンラインであることを確認するために、オンラインでないボリュームを
表示します。
volume show -state !online
例
cluster1::> volume show -state !online
There are no entries matching your query.
ボリュームの管理の詳細については、『clustered Data ONTAP論理ストレージ管理ガイド』を参
照してください。
LIFの有効化とホーム ポートへのリバート
リブートを行うと、一部のLIFが関連付けられているフェイルオーバー ポートに移行されることがあ
ります。 クラスタのアップグレード、リバート、またはダウングレードを行う際は、実行前と実行後
に、ホーム ポートにないLIFを有効にしてリバートする必要があります。
タスク概要
network interface revertコマンドを実行すると、対応するホーム ポートにないLIFがホーム
ポートにリバートされます（ホーム ポートが稼働している場合）。 LIFのホーム ポートはLIFの作成
時に指定します。指定されているホーム ポートは、 network interface showコマンドを使用し
て確認できます。
手順
1. すべてのLIFのステータスを表示します。
network interface show
例
SVMのすべてのLIFのステータスを表示する例を次に示します。
cluster1::> network interface show -vserver vs0
Logical
Status
Network
Vserver
Interface Admin/Oper Address/Mask
----------- ---------- ---------- -----------------vs0
data001
down/down 192.0.2.120/24
data002
down/down 192.0.2.121/24
data003
down/down 192.0.2.122/24
Current
Current Is
Node
Port
Home
------------- ------- ---node0
node0
node0
e0e
e0f
e2a
true
true
true
Data ONTAPクラスタのアップグレード | 63
data004
down/down
data005
down/down
data006
down/down
data007
down/down
data008
down/down
8 entries were displayed.
192.0.2.123/24
192.0.2.124/24
192.0.2.125/24
192.0.2.126/24
192.0.2.127/24
node0
node0
node0
node0
node0
e2b
e0e
e0f
e2a
e2b
true
false
false
false
false
Status AdminステータスがdownになっているLIFやIs homeステータスがfalseになっている
LIFがある場合は次の手順に進みます。
2. データLIFを有効にします。
network interface modify {-role data} -status-admin up
例
cluster1::> network interface modify {-role data} -status-admin up
8 entries were modified.
3. LIFをそれぞれのホーム ポートにリバートします。
network interface revert *
このコマンドを実行すると、すべてのLIFがそれぞれのホーム ポートにリバートされ、すべての
LIFのホーム ステータスがtrueに変わります。
例
cluster1::> network interface revert *
8 entries were acted on.
4. すべてのLIFがそれぞれのホーム ポートにあることを確認します。
network interface show
例
次の例では、SVM vs0のすべてのLIFがそれぞれのホーム ポートにあります。
cluster1::> network interface show -vserver vs0
Logical
Status
Network
Vserver
Interface Admin/Oper Address/Mask
----------- ---------- ---------- -----------------vs0
data001
up/up
192.0.2.120/24
data002
up/up
192.0.2.121/24
data003
up/up
192.0.2.122/24
data004
up/up
192.0.2.123/24
data005
up/up
192.0.2.124/24
data006
up/up
192.0.2.125/24
data007
up/up
192.0.2.126/24
data008
up/up
192.0.2.127/24
8 entries were displayed.
Current
Current Is
Node
Port
Home
------------- ------- ---node0
node0
node0
node0
node1
node1
node1
node1
e0e
e0f
e2a
e2b
e0e
e0f
e2a
e2b
true
true
true
true
true
true
true
true
64 | アップグレードおよびリバート / ダウングレード ガイド
アップグレード後のInfinite Volume用のネームスペース ミラー コンスティチュエントの
作成
Infinite Volumeを含むクラスタをアップグレードしたあと、複数のノードにまたがるすべてのInfinite
Volumeで、ネームスペース コンスティチュエントのデータを保護するためにネームスペース ミラー
コンスティチュエントを作成する必要があります。
開始する前に
•
•
ネームスペース ミラー コンスティチュエントを作成するには、アップグレード後のInfinite
Volumeが複数のノードにまたがっている必要があります。
この手順を実行するかテクニカル サポートに連絡するかを判断します。
◦
◦
Data ONTAP 8.1.xを実行しているInfinite Volumeのネームスペース コンスティチュエントに
対するデータ保護ミラー コピーをテクニカル サポートを通じてアップグレード前に作成した
場合は、アップグレード後にテクニカル サポートに連絡して、ネームスペース コンスティチュ
エントのデータ保護ミラー コピーをネームスペース ミラー コンスティチュエントに変換する必
要があります。
Data ONTAP 8.1.xを実行しているInfinite Volumeのネームスペース コンスティチュエントに
対するデータ保護ミラー コピーをテクニカル サポートを通じてアップグレード前に作成して
いない場合は、アップグレード後にこの手順に従ってネームスペース ミラー コンスティチュ
エントを作成できます。
タスク概要
Data ONTAP 8.2以降を実行するクラスタのInfinite Volumeにはネームスペース ミラー コンスティ
チュエントが必要ですが、 Data ONTAP 8.1.xからアップグレードしたInfinite Volumeにはネームス
ペース ミラー コンスティチュエントがありません。
注: データ保護ミラー関係が確立されたInfinite Volumeの場合、ネームスペース コンスティチュ
エントのデータを保護するためにネームスペース ミラー コンスティチュエントが必要になるの
は、ソースの読み書き可能なInfinite Volumeだけです。 デスティネーションの読み取り専用の
Infinite Volumeは、Infinite Volumeのデータ保護ミラー関係によってデータが保護されるため、
ネームスペース ミラー コンスティチュエントは必要ありません。
手順
1. アップグレードしたInfinite Volumeにネームスペース ミラー コンスティチュエントを格納できるだ
けの十分なスペースがあることを確認します。
a. volume showコマンドで -is-constituent trueパラメータを指定して、Infinite Volume
のネームスペース コンスティチュエントのサイズと、そのネームスペース コンスティチュエン
トが格納されているアグリゲートの名前を確認します。
ネームスペース コンスティチュエントのサイズを確認するのは、ネームスペース ミラー コン
スティチュエントのサイズはネームスペース コンスティチュエントと同じになるためです。 ア
Data ONTAPクラスタのアップグレード | 65
グリゲートの名前を確認するのは、このアグリゲートを評価から除外する必要があるためで
す。 ネームスペース ミラー コンスティチュエントはネームスペース コンスティチュエントと異
なるアグリゲートに格納する必要があるため、ネームスペース コンスティチュエントとは別
のノードに作成します。
例
次の例では、repo_vol_nsという名前のネームスペース コンスティチュエントのサイズが
10TBになっています。 このネームスペース コンスティチュエントが格納されているアグリゲ
ートの名前はaggr_nsです。
cluster1::> volume show -is-constituent true
Vserver Volume
Aggregate State Type Size Available Used%
------- -------------------- ------ ---- ----- --------- ----vs0
repo_vol_default_data0001 aggr1
online RW
50TB
35.0TB
30%
vs0
repo_vol_default_data0002 aggr2
online RW
50TB
34.0TB
32%
vs0
repo_vol_default_data0003 aggr3
online RW
50TB
35.5TB
29%
vs0
repo_vol_default_data0004 aggr4
online RW
50TB
36.5TB
27%
vs0
repo_vol_ns
aggr_ns online RW
10TB
8.4TB
16%
5 entries were displayed.
b. aggregate showコマンドで-fields nodeパラメータを指定して、Infinite Volumeを含むク
ラスタの中から、ネームスペース コンスティチュエントが格納されたアグリゲートとは別のノ
ードにあるアグリゲートを探します。
例
次の例では、aggr_nsという名前のアグリゲートにネームスペース コンスティチュエントが格
納されており、そのアグリゲートのノードはnode-02です。 そのため、node-02のアグリゲート
であるaggr1やaggr_nsではなく、 node-01にあるaggr2、aggr3、またはaggr4のいずれかのア
グリゲートを使用します。
cluster1::> aggregate show -fields node
aggregate node
--------- -----------aggr1
node-02
aggr2
node-01
aggr3
node-01
aggr4
node-01
aggr_ns
node-02
c. いずれかのアグリゲートにネームスペース ミラー コンスティチュエントを格納できるだけの
十分なスペースがあることを確認します。
d. 必要に応じて、アグリゲートのスペースを拡張します。
Infinite Volumeにネームスペース ミラー コンスティチュエントのための十分なスペースが確保
されます。
2. volume modifyコマンドを使用して、ネームスペース コンスティチュエントのサイズの分だけ
Infinite Volumeのサイズを拡張します。
66 | アップグレードおよびリバート / ダウングレード ガイド
例
次の例では、repo_volという名前のボリュームをネームスペース コンスティチュエントのサイズ
（10TB）の分だけ拡張しています。
cluster1::> volume modify -vserver vs0 -volume repo_vol -size +10TB
ネームスペース ミラー コンスティチュエントが自動的に作成されます。
Remote Support Agent用のクラスタ管理LIFの設定
Data ONTAPのメジャー アップグレードやマイナー アップグレードを実行したあと、Remote Support
Agent（RSA）を使用する場合は、各リモート デバイスに対してrsa setupコマンドを使用して、
RSAソフトウェア用のクラスタ管理LIFを設定する必要があります。
タスク概要
RSAの設定とクラスタ管理LIFの設定の詳細については、『Remote Support Agent Configuration
Guide for Clustered Data ONTAP』を参照してください。
SnapMirror処理の再開
無停止アップグレードまたは無停止ダウングレードを行った場合は、一時中止していたSnapMirror
関係を完了後に再開する必要があります。
開始する前に
snapmirror quiesceコマンドを使用して既存のSnapMirror関係を一時中止し、クラスタの無停
止アップグレードまたは無停止ダウングレードを完了しておく必要があります。
手順
1. それぞれのデスティネーション ボリュームについて、既存のSnapMirror転送を再開します。
snapmirror resume -destination-path destination
例
Relationship CapabilityがPre 8.2のSnapMirror関係の転送を再開する例を次に示します。デス
ティネーション パスはcluster1://vs0/vol1です。
cluster1::> snapmirror resume -destination-path cluster1://vs0/vol1
2. snapmirror showコマンドを使用して、SnapMirror処理が再開されたことを確認します。
3. 再開されないSnapMirror処理がある場合は、転送を中止します。
snapmirror abort -destination-path destination -h
Data ONTAPクラスタのアップグレード | 67
-hパラメータを指定すると、再開チェックポイントが破棄され、転送が完了した最後のSnapshot
コピーの状態にデスティネーション ボリュームがリストアされます。
転送を中止したあとも再開されないSnapMirror処理がある場合は、snapmirror resyncコマ
ンドを使用してミラー関係を再確立する必要があります。
古い形式のSnapMirror関係のアップグレード
Data ONTAP 8.2へのアップグレード前に使用していたSnapMirror関係で、Data ONTAP 8.2の新し
い機能や強化された機能を利用する場合は、Data ONTAP 8.2の構文の形式を使用するように
SnapMirror関係を更新する必要があります。
タスク概要
クラスタのアップグレード後、クラスタは既存のサービスを中断することなく完全に動作します。 た
だし、アップグレードを実行しても、SnapMirror関係の構文の変更は反映されないため、
SnapMirror関係で新しいリリースの機能を利用することはできません。 新しい機能を利用するに
は、ネットアップが提供しているツールを使用するか、それぞれのSnapMirror関係に対する更新を
独自に行って、SnapMirror関係を更新する必要があります。
手順
1. SVMピア関係を作成します。
a. クラスタ ピア関係の一方のクラスタで、vserver peer createコマンドを使用してSVMピ
ア関係を作成します。
同じ2つのSVMを使用するSnapMirror関係が複数ある場合、SVMピア関係は1つだけでか
まいません。
b. クラスタ ピア関係のもう一方のクラスタで、vserver peer acceptコマンドを使用して
SVM作成要求を受け入れます。
c. 名前が競合する場合は、vserver renameコマンドを使用して一方のSVMの名前を変更し
ます。
2. snapmirror showコマンドを使用して、「Relationship Capability」フィールドが「Pre 8.2」に設定
されているすべてのSnapMirror関係がhealthyと表示されることを確認します。
3. 既存のそれぞれのSnapMirror関係について、Data ONTAP 8.2のSnapMirror関係の構文を使
用するようにアップグレードします。
a. snapmirror quiesceコマンドを使用して、アップグレードする関係で以降の転送が開始さ
れないようにします。
b. SnapMirror関係をアップグレードする前に、snapmirror abort -hコマンドを使用してアク
ティブな転送を中止するか、アクティブな転送が完了するまで待ちます。
c. snapmirror show -instanceコマンドを使用して、SnapMirror関係の設定パラメータを確
認して記録します。
これらのパラメータは、SnapMirrorポリシーを確認するときに使用します。
68 | アップグレードおよびリバート / ダウングレード ガイド
d. snapmirror show -instanceコマンドで生成された出力の「Relationship Capability」フィ
ールドで、アップグレードできる関係を確認します。
このフィールドのエントリが「Pre 8.2」の場合、その関係はアップグレードできます。 このフィ
ールドのエントリが「8.2 and above」の場合、その関係はすでにアップグレードされている
か、Data ONTAPのアップグレード後に作成されています。
e. 古い形式の構文を使用してSnapMirror関係を削除します。
例
vs1-dest::> snapmirror delete -source-path cluster1://vs1/vol1 destination-path cluster2://vs1-dest/vol1-dest
f. 前の手順でsnapmirror policy showコマンドを使用して記録しておいた設定パラメータ
に一致するSnapMirrorポリシーがあるかどうかを確認します。
g. 設定パラメータに一致するSnapMirrorポリシーがない場合は、snapmirror policy
createコマンドを使用して新しいSnapMirrorポリシーを作成します。
例
vs1-dest::> snapmirror policy create -policy marketpolicy -vserver
vs1
h. snapmirror createコマンドで新しい形式の構文を使用し、目的のポリシーを指定して
SnapMirror関係を作成します。
例
vs1-dest::> snapmirror create -source-path vs1:vol1 -destinationpath vs1-dest:vol1-dest -type DP -policy marketpolicy
4. snapmirror resyncコマンドを使用して、それぞれのSnapMirror関係を再同期します。
LIFの自動リバランシングの有効化
バッチ アップグレードを実行するためにLIFの自動リバランシングを無効にした場合は、アップグレ
ードの完了後に再度有効にします。
手順
1. 権限レベルをadvancedに設定します。
set -privilege advanced
2. 必要に応じて、それぞれのLIFでLIFの自動リバランシングを有効にします。
network interface modify -vserver Vserver_name -lif LIF_name -allow-lbmigrate true
Data ONTAPクラスタのアップグレード | 69
3. admin権限レベルに戻ります。
set -privilege admin
70 | アップグレードおよびリバート / ダウングレード ガイド
ファームウェアの更新
Data ONTAPをアップグレードするとご使用のファームウェアがアップグレードされるため、システ
ム、ディスク、ディスク シェルフ ファームウェアのほか、システムにインストールされているその他
のコンポーネントのファームウェアのアップグレード要件を考慮する必要があります。 Data ONTAP
アップグレード間のファームウェアの更新も必要になる可能性があります。
システム ファームウェアの更新
Data ONTAPソフトウェアのアップグレードを実行すると、Data ONTAPのアップグレード パッケージ
に含まれているファームウェア サービス イメージがストレージ システムのブート デバイスにコピー
され、新しいファームウェアが自動的にインストールされます。
Data ONTAPアップグレード中にシステム ファームウェアをアップグレードする場合、ネットアップ
サポート サイトから、システム ファームウェアを取得して、インストール方法についての詳細を参
照できます。
関連情報
システム ファームウェアおよび診断ダウンロード：support.netapp.com/NOW/cgi-bin/fw
ディスク ファームウェアの更新
ディスク ファームウェアはData ONTAPシステム ファイルにバンドルされ、Data ONTAPのアップグ
レード中に自動的に更新されます。 ネットアップ サポート サイトからディスク ファームウェアを入手
して手動で更新することもできます。
関連情報
Disk Drive and Firmware Matrix：support.netapp.com/NOW/download/tools/diskfw
ディスク ファームウェアの更新方法
Data ONTAPをアップグレードするとき、ディスク ファームウェアは、Data ONTAPシステム ファイル
にバンドルされているファームウェアより古い場合には自動的に更新されます。 最新のファームウ
ェア パッケージをネットアップ サポート サイトからダウンロードし、ファイルをインストールして、ディ
スク ファームウェアを更新することもできます。
すべてのストレージ システムには、最新のファームウェア リビジョンが備わっています。 次のいず
れかの場合、ディスク ファームウェアは自動的に更新されます。
•
新しいディスクまたはディスク シェルフを追加した場合
ファームウェアの更新 | 71
ディスク ファームウェアの更新版は、システムに常駐するファームウェア バンドルから適用され
ます。
注: SASシェルフを活性増設する場合、ファームウェアは自動的には更新されません。 古いド
ライブ、シェルフ、ACPファームウェアを手動で確認して更新する必要があります。
•
Data ONTAPは、ディスク ファームウェアの更新版を検出します。
Data ONTAPは、2分おきに新しいファームウェアをスキャンします。
システムにディスク ファームウェアの更新版を追加できるのは、次の場合です。
•
•
•
Data ONTAPのアップグレード実行中
新しいリリース ファミリーへのアップグレードには、たいていディスク ファームウェアの更新が含
まれています。 ディスク ファームウェアの更新は、リリース ファミリー内でのData ONTAPのア
ップグレードに含まれる場合もあります。
ディスク ファームウェアの更新パッケージの取得後
一部のディスク タイプで問題が発生したり、NetAppから通知があった場合、ネットアップ サポ
ート サイトからディスク ファームウェアの更新をダウンロードするように指示されることがありま
す。
Data ONTAPのアップグレード前に最新のディスク ファームウェアをダウンロードしてインストー
ルする必要があります。
SASシェルフの活性増設のタイミング
ディスクドライブのメーカーはそれぞれ独自のディスクドライブ ファームウェアを提供しています。
したがって、ディスク ファームウェアの更新版には、1つ以上のディスクドライブ タイプ用のファーム
ウェアの更新版が含まれている可能性があります。 ご使用のストレージ システムでは複数のドラ
イブ メーカーのドライブが使用されている場合もあり、ディスク ファームウェアの更新によって影響
が生じるかどうかは、ご使用のシステムのドライブの種類および数によって異なります。
Disk Qualification Packageの更新が必要なタイミング
Disk Qualification Package（DQP）は、新しく認定されたディスクドライブに対する完全なサポートを
追加するためのパッケージです。 ディスク ファームウェアを更新したり、新しいタイプやサイズのデ
ィスクをストレージ システムに追加するたびに、DQPも更新する必要があります。
DQPはネットアップ サポート サイトから入手できます。 DQPは、次の場合にダウンロードしてイン
ストールする必要があります。
•
•
•
新しいタイプやサイズのディスクをノードに追加したとき
たとえば、1TBのディスクを使用している環境で2TBのディスクを追加した場合、DQPの最新版
がないかどうかを確認する必要があります。
ディスク ファームウェアを更新したとき
新しいディスク ファームウェアやDQPファイルが利用可能になったとき
関連情報
Disk Qualification Package Instructions：support.netapp.com/NOW/download/tools/diskqual/
72 | アップグレードおよびリバート / ダウングレード ガイド
Disk Drive & Firmware Matrix：support.netapp.com/NOW/download/tools/diskfw/
ディスク シェルフ ファームウェア更新中のサービスの可用性
デフォルトでは、ディスク ファームウェアの更新はバックグラウンドで自動的に行われるため、スト
レージ システム サービスの継続は保証されます。
ディスク ファームウェア パッケージはご使用のシステムにいつでもダウンロードでき、ファームウェ
アはバックグラウンドで無停止で更新されます。 ただし、ディスク ファームウェアの更新が終了す
るまで待ってから無停止アップグレードを開始する必要があります。
ディスク ファームウェアのバックグラウンド更新では一度に1つのディスクが処理され、ディスクごと
に約2.5分必要です。 システムに接続されるすべてのディスクで同時にファームウェア更新が必要
になる可能性は低いですが、Data ONTAP NDUを開始する前にノードに接続されたディスクごとに
2.5分以上待機することを推奨します。
たとえば、ノードに192個のディスクが接続されている場合、480分（8時間）以上待機する必要があ
ります。 クラスタ内のすべてのノードがファームウェア更新を完了するまで待ってからNDUを開始
する必要があります。 ディスク ファームウェアはクラスタ内のすべてのノードで並行して更新できま
す。
AutoSupportを使用した古いディスク ファームウェアの検出
AutoSupportのメッセージには、ストレージ システムにインストールされたディスク ファームウェアの
情報が含まれています。 「Installed Systems」ページは、これらのメッセージを使用してシステム上
のファームウェア バージョンを監視し、システム上のインストール済みディスク ファームウェアのバ
ージョンが古くなると、通知を表示します。
開始する前に
Installed Systemsサービスを使用してディスク ファームウェアのバージョンを監視するには、ストレ
ージ システムが次の要件を満たす必要があります。
•
•
システム上でAutoSupportが有効化されていること。
AutoSupportの詳細については、『clustered Data ONTAP システム アドミニストレーション ガイド
（クラスタ管理）』を参照してください。
ご使用のNetApp製品の登録
手順
1. Webブラウザを使用して、ネットアップ サポート サイト：support.netapp.comにアクセスします。
2. [My Support] > [View Installed Systems]を選択します。
3. 特定システムの検索条件を入力するか、自社のシステムのリストを表示して、アップグレードす
るストレージ システム製品の詳細を表示します。
4. [AutoSupport Status]カテゴリで、[Health Check Details]をクリックします。
ファームウェアの更新 | 73
タスクの結果
ご使用のストレージ システムでファームウェアの更新を使用できる場合、「Firmware Analysis」ペ
ージへのリンクを含むメッセージが表示されます。 「Firmware Analysis」ページにストレージ システ
ムに新しいディスク ファームウェアを使用できるというメッセージが表示されている場合、次のData
ONTAPアップグレード時に、ディスク ファームウェアの更新が実行されます。 ディスク ファームウ
ェアのメッセージが含まれていなければ、システム上のディスク ファームウェアは最新バージョンで
す。
関連情報
システム：support.netapp.com/eservice/Systems.jsp
ディスク シェルフ ファームウェアの更新
ディスク シェルフ ファームウェア（ディスク シェルフのモジュールのファームウェア）はData ONTAP
システム ファイルにバンドルされ、Data ONTAPアップグレード中に自動的に更新されます。 また、
ネットアップ サポート サイトから入手して手動で更新することもできます。
ディスク シェルフを活性増設した場合には、ディスク シェルフ ファームウェアの更新は必須となり
ます。 詳細については、ディスク シェルフのマニュアルを参照してください。
関連情報
ディスク シェルフ ファームウェア：support.netapp.com/NOW/download/tools/diskshelf
ディスク シェルフ ファームウェアの更新方法
Data ONTAPをアップグレードするとき、ディスク シェルフ ファームウェアは、Data ONTAPシステム
ファイルにバンドルされているファームウェアより古い場合は自動的に更新されます。 シェルフ モ
ジュールに対応する最新のファームウェアをネットアップ サポート サイトからダウンロードしてイン
ストールすることにより、ディスク シェルフ ファームウェアを更新することもできます。
ディスク シェルフのATシリーズ、ESHシリーズ、SASシェルフI/Oモジュール（IOM）シリーズは、ディ
スク スワップ時の信号整合性など、ホスト バス アダプタ インターフェイスへのディスクのインターコ
ネクトを提供します。 ディスク シェルフの背面中央には、モジュールが2つ（チャネルAおよびチャネ
ルBに1つずつ）搭載されています。 SASモジュールは、特定のシステムの内部コンポーネントの場
合もあります。 これらのモジュールに対する更新ファームウェアは、定期的に提供されます。
各ストレージ システムは、最新のディスク シェルフ ファームウェア バージョンを備えています。
システムにディスク シェルフ ファームウェアの更新版をロードできるのは、次の場合です。
•
Data ONTAPのアップグレード実行後
Data ONTAPアップグレード パッケージには、たいていディスク シェルフ ファームウェアの更新
版が含まれています。 アップグレード パッケージの新しいバージョンが、インストールされてい
74 | アップグレードおよびリバート / ダウングレード ガイド
•
•
るバージョンよりも新しい場合、新バージョンがダウンロードされ、Data ONTAPアップグレード
プロセスの一環として、givebackフェーズ中にインストールされます。
ファームウェアの手動更新中
Data ONTAPソフトウェアの無停止アップグレードを実行する場合、またはNetAppから通知が
あった場合には、ネットアップ サポート サイトからディスク シェルフ ファームウェアの更新版を
ダウンロードする必要があります。
SASシェルフの活性増設のタイミング
また、システムに新たなファームウェアが存在する場合は、次のイベントによってディスク シェルフ
ファームウェアの自動更新がトリガーされます。
•
•
•
•
system rebootコマンドの実行
storage failover givebackコマンドの実行
新たなディスクドライブの挿入
新たなシェルフ モジュールの挿入
ディスク シェルフおよびディスク シェルフ モジュールの詳細については、『clustered Data ONTAP
ハイアベイラビリティ構成ガイド』およびご使用のシェルフの『Installation and Service Guide』を参照
してください。
古いディスク シェルフ ファームウェアの検出
Data ONTAPソフトウェアの無停止アップグレードを実行する場合、または、ディスク シェルフ ファ
ームウェアを更新するように指示された場合には、まず、システムに接続されているディスク シェ
ルフにインストールされているファームウェアのバージョンを確認する必要があります。
手順
1. ネットアップ サポート サイトのディスク シェルフ ファームウェア情報を調べ、使用するシェルフ
に対応する最新ファームウェアのバージョンを確認します。
2. ストレージ システムのコマンドラインで、次のコマンドを入力します。
system node run nodename sysconfig -v
3. sysconfig -vの出力結果から、シェルフ情報を確認します。
例
Shelf 1: AT-FCX Firmware rev. AT-FCX A: 36 AT-FCX B: 36
Shelf 2: AT-FCX Firmware rev. AT-FCX A: 36 AT-FCX B: 36
コマンド出力されたディスク シェルフ ファームウェアのバージョンがネットアップ サポート サイト
の最新バージョンより古い場合、ディスク シェルフ ファームウェアを手動で更新する必要があり
ます。
ファームウェアの更新 | 75
関連情報
ディスク シェルフ ファームウェア：support.netapp.com/NOW/download/tools/diskshelf
ACPファームウェアの更新方法
ACP機能を備えたディスク シェルフの場合、Data ONTAPのアップグレード時にACPファームウェ
アが自動的に更新されます。 このファームウェアは、ネットアップ サポート サイトから入手して手
動で更新することもできます。
Data ONTAPをアップグレードする際、ACPファームウェア（ディスク シェルフ上のACPプロセッサの
ファームウェア）がData ONTAPシステム ファイルにバンドルされているものよりも古い場合は、こ
のファームウェアが自動的に更新されます。
関連情報
ディスク シェルフ ファームウェア：support.netapp.com/NOW/download/tools/diskshelf
clustered Data ONTAPへのディスク シェルフ ファームウェアのダウンロードおよびインストール
の手順：support.netapp.com/NOW/download/tools/diskshelf/shelffw_cm.html
サービス プロセッサ ファームウェアの更新
サービス プロセッサ（SP）は、一部のシステムに含まれるリモート管理デバイスです。 Data ONTAP
8.2以降、ベースラインSPファームウェア イメージはData ONTAPイメージに含まれているため、SP
はデフォルトで自動的に更新されます。
SPへの既存の接続は、SPファームウェアを更新するときに切断されます。 これは、SPファームウェ
ア更新が自動的にまたは手動で開始される場合に該当します。
注: Data ONTAPは、失敗したSP自動更新を検出し、修正アクションをトリガーして、SP自動更新
を最大3回試行します。 3回の試行がすべて失敗した場合は、テクニカル サポートにお問い合わ
せください。
Data ONTAPアップグレード中にSPファームウェアをアップグレードする場合、ネットアップ サポート
サイトから、SPファームウェアを取得して、インストール方法についての詳細を参照できます。 SPフ
ァームウェアをダウンロードして更新するには、Data ONTAPのCLIまたはSP CLIを使用します。
SPの詳細および動作については、『clustered Data ONTAP システム アドミニストレーション ガイド
（クラスタ管理）』を参照してください。
76 | アップグレードおよびリバート / ダウングレード ガイド
RLMファームウェアの更新
Remote LAN Module（RLM）ファームウェアをアップグレードするには、Data ONTAP CLIまたは
RLM CLIを使用してRLMファームウェアのダウンロードと更新を行います。
ネットアップ サポート サイトからRLMファームウェアを取得して、インストール方法についての詳細
を参照できます。
RLMの詳細および動作については、 『clustered Data ONTAP システム アドミニストレーション ガイ
ド（クラスタ管理）』を参照してください。
Flash Cacheファームウェアの更新方法
Flash Cacheデバイスのファームウェアは、 Data ONTAPアップグレードの配布ファイルに付属して
います。 実行中のファームウェアがData ONTAPシステム ファイルにバンドルされているファーム
ウェアより古い場合、自動的に更新されます。
ファームウェア更新は、元の16GB PAMデバイスには利用できません。 自動更新は、Flash Cache
デバイスにのみ実行され、PAMデバイスには実行されません。
Data ONTAPを無停止でアップグレードする場合（NDU）、Flash Cacheファームウェアは無停止で
更新されます。 これは、Flash Cacheファームウェアのアップグレードに必要なリブートが、
storage failover givebackプロセスの最終リブート前に行われるためです。 この結果、シス
テムにFlash Cacheデバイスが含まれる場合、Data ONTAP NDUの実行中にリブートが複数回行
われる可能性がありますが、これは想定内の動作です。
Flash CacheとPAMの説明および機能の詳細については、 『clustered Data ONTAP システム アドミ
ニストレーション ガイド（クラスタ管理）』を参照してください。
77
以前のData ONTAPリリース ファミリーへのクラスタのリ
バート
クラスタを以前のData ONTAPファミリーのリリースに移行することをリバートと呼びます。 リバート
を行うときは、まず準備を整え、クラスタシェルでsystem node revert-toコマンドを使用し、ノー
ドシェルでrevert_toコマンドを使用して、最後にリバート後の手順を実行する必要があります。
revert_toコマンドは、Data ONTAPのディスク上の構造をターゲットである以前のリリースと互換
性を持つように変更して、システムのリバートの準備を完了させます。
注意: 以前のリリース ファミリーのリリースを単純にダウンロードおよびブート（ネットブート）して
Data ONTAPをリバートしようとしないでください。 その場合、ターゲットである以前のリリースは
ブートできません。 リバート プロセスには、クラスタシェルのsystem node revert-toコマンド
とノードシェルのrevert_toコマンドを使用する必要があります。
詳細については、system node revert-toのマニュアル ページを参照してください。
リバートのタイミングおよびテクニカル サポート連絡のタイミング
新しいシステムまたはテスト用システムは支援なしでリバートできますが、アップグレードの実行中
や実行後に問題が発生した場合や、本番環境システムをリバートする場合はテクニカル サポート
に連絡してください。
次の場合のみ、テクニカル サポートの支援なしで以前のリリース ファミリーにリバートできます。
•
•
テスト用システムで新しいリリースにアップグレードしたあと、テストが完了したので元のリリー
スに戻す。
Data ONTAPの以前のリリースで標準化している環境に、まだ本番環境に使用していないData
ONTAPの以降のリリースを実行する新しいストレージ システムを構成する。
本番環境のData ONTAPは、テクニカル サポートの支援なしでリバートしないでください。 次のよう
な場合は、すぐにテクニカル サポートに連絡してください。
•
•
•
•
アップグレード プロセスが失敗して終了できない。
アップグレード プロセスが終了したが、本番環境でクラスタが使用できない。
アップグレード プロセスが終了してクラスタが本番環境に移行したが、正しく動作しない。
アップグレード プロセスが終了しないノードがあるので、プロセスが終了したノードをリバートし
たい。
78 | アップグレードおよびリバート / ダウングレード ガイド
リバートの計画
Data ONTAPではリリースの更新ごとに新機能が追加されるため、リバート要件について理解し、
リバートが現在の構成にどのような影響を与えるかを評価する必要があります。
リバートを開始する前に、次の作業を計画する必要があります。
•
•
•
•
Data ONTAPのリバート ソース リリースの『リリース ノート』の内容の確認。
既存のソフトウェアからターゲット リリースにリバートするための要件の把握。
リバート実行後のシステムの潜在的な機能変更の把握。
リバート チェックリストの全項目に対処するための準備。
クラスタ リバートのチェックリスト
このチェックリストを使用して、リバートの準備から、リバートの実行、リバート後の手順の実行ま
で、進捗を記録しながら進めることができます。
リバートの準備手順
準備手順は、次の条件がすべて当てはまると完了します。
状態
ターゲット リリースのソフトウェアおよびハードウェアのサポート
を確認した。
ハードウェアのサポートを確認するには、『Hardware Universe』
（旧称は『システム構成ガイド』）support.netapp.com/knowledge/
docs/hardware/NetApp/syscfg/index.shtmlを参照してください。
ターゲット リリースでサポートされないプラットフォームのノード
がある場合、そのノードについては、クラスタをリバートする前に
クラスタから分離する必要があります。 クラスタからのノードの
削除の詳細については、『clustered Data ONTAP システム アド
ミニストレーション ガイド（クラスタ管理）』を参照してください。
SAN構成が完全にサポートされている。
SAN構成がターゲットのData ONTAPリリースの制限を超えな
いことを確認する必要があります。 SAN構成の制限の詳細に
ついては、『Clustered Data ONTAP SAN Configuration Guide』
を参照してください。
リリース固有のリバートの問題がすべて解決されている。
advanced権限レベルでクラスタシェルにアクセスできる。
完了
以前のData ONTAPリリース ファミリーへのクラスタのリバート | 79
状態
クラスタとSVMが正常に実行されている。
リバートの処理を進める前に、すべてのアグリゲートとボリュー
ムがオンラインで正常に動作していることを確認する必要があ
ります。 ノードのステータスは、cluster showコマンドを使用し
て確認できます。
クラスタがクォーラムにある。
すべてのノードがクォーラムに参加しており、すべてのリングが
クォーラム内にある必要があります。 また、リングごとのクォー
ラム マスターがすべてのノードで同一でなければなりません。
すべてのコア ダンプ ファイルが保存または削除されている。
コア ダンプの管理の詳細については、『clustered Data ONTAP
システム アドミニストレーション ガイド（クラスタ管理）』を参照し
てください。
システム時間がクラスタ全体で同期されている。
iSNSサーバとそれに関連付けられているSVM管理LIFのIPv4
アドレスが設定されている。
新しいData ONTAPリリースで作成されたSnapshotコピーが削除
され、ノードのルート ボリュームおよびルート アグリゲートから
すべてのSnapshotコピーが削除されている。
現在のリリースへのアップグレード後に作成されたSnapshotコピ
ーをすべて削除する必要があります。また、ルート アグリゲート
とルート ボリュームのSnapshotコピーを削除し、それらの
Snapshotスケジュールも無効にする必要があります。
IPv6オブジェクトがすべて削除されている。
IPv6アドレスを使用しているLIF、ルーティング グループ、およ
びファイアウォール ポリシーをすべて削除する必要がありま
す。 これらのオブジェクトの削除の詳細については、『clustered
Data ONTAP ネットワーク管理ガイド』を参照してください。
ターゲットのData ONTAPソフトウェア イメージがHTTPサーバ
にある。
ターゲットのData ONTAPリリースのソフトウェア イメージをネッ
トアップ サポート サイト：support.netapp.comからダウンロード
し、各ノードからアクセスできるHTTPサーバに格納します。
完了
80 | アップグレードおよびリバート / ダウングレード ガイド
状態
完了
ターゲットのData ONTAPソフトウェア イメージが各ノードにイン
ストールされ、代替ブート デバイス イメージとして設定されてい
る。
ソフトウェア イメージは、 system node image updateコマン
ドを使用してインストールできます。 ソフトウェア イメージが各ノ
ードに代替ブート イメージとしてインストールされているかどう
かは、system node image showコマンドを使用して確認でき
ます。
リバートの実行手順
リバートは、次の手順をすべて実行すると完了になります。
状態
完了
実行中のジョブがない。
アグリゲート、ボリューム、ミラー、NDMP（ダンプまたはリスト
ア）、またはSnapshotに関する実行中のジョブ（作成、削除、移
動、変更、複製、マウントなど）やキューに格納されているジョブ
がある場合は、ジョブが完了するまで待つか、キューのエントリ
を中止します。
ターゲットのData ONTAPソフトウェアがインストールされ、デフ
ォルトのブート イメージとして設定されている。
各ノードでターゲット リリースをブートした。
リバート後の手順
リバート後の手順は、次の条件がすべて当てはまると完了します。
状態
クラスタとSVMが正常に実行されている。
リバートの実行後に、すべてのアグリゲートとボリュームがオン
ラインで正常に動作していることを確認する必要があります。 ノ
ードのステータスは、cluster showコマンドを使用して確認で
きます。
LIFがオンラインで、それぞれの正しいホーム ポートにある。
LIFの設定は、network interfaceコマンドを使用して表示お
よび変更できます。
完了
以前のData ONTAPリリース ファミリーへのクラスタのリバート | 81
状態
完了
各ノードのルート ボリュームとルート アグリゲートのSnapshotス
ケジュールが有効になっている。
Snapshotコピーの作成を再開するために、ルート ボリュームと
ルート アグリゲートのSnapshotスケジュールを再度有効にする
必要があります。
クライアントからアクセスできることを確認した。
設定されているそれぞれのプロトコルについて、クライアントか
らクラスタにアクセスできることを確認する必要があります。
サービス プロセッサ ファームウェアのバージョンを確認した。
現在使用しているSPファームウェアのバージョンをサポートして
いないData ONTAPリリースにリバートする場合、そのData
ONTAPでサポートされるSPファームウェアのバージョンをインス
トールする必要があります。
SVM管理者のvsadminロールに対してevent generateautosupport-log機能が有効になっている。
リバート プロセスの注意事項
Data ONTAPをリバートするときは、開始前にリバートの問題と制限事項について理解しておく必
要があります。
次の点に注意してください。
•
•
•
•
•
複数のノードで構成されるクラスタはData ONTAP 8.2から8.1.xにリバートできますが、
シングル ノード クラスタはData ONTAP 8.1にリバートできません。
Infinite Volumeを備えたSVMを含むクラスタは、Data ONTAP 8.1にリバートしないでください。
Data ONTAP 8.1.xのData ONTAP 8.1.1以降のリリースにリバートする場合は、テクニカル サポ
ートにお問い合わせください。 Data ONTAP 8.1.0にリバートする場合は、Infinite Volumeを備え
たSVMをすべて削除する必要があります。
リバートの実行時はシステムが停止します。
リバートの実行中はクライアントからアクセスできなくなります。 本番環境システムをリバートす
る場合は、この停止時間を考慮して計画してください。
リバートを行う際は、クラスタ内のすべてのノードが対象になります。
リバートはクラスタ内のすべてのノードで実行する必要があります。ただし、一部の手順につい
ては、HAペアごとにそれぞれのノードのセットに対して実行し、それが完了してから次のペア
のリバートに進む必要があります。
リバートは、すべてのノードで新しいターゲット リリースが実行されるようになった時点で完了で
す。
82 | アップグレードおよびリバート / ダウングレード ガイド
•
•
•
クラスタに異なるバージョンが混在した状態のときは、リバートの要件を満たすために必要なも
のを除き、クラスタの処理や構成を変更するコマンドは実行しないでください（監視処理は可能
です）。
何らかの理由でリバートを完了できない場合は、すぐにテクニカル サポートに連絡してくださ
い。 一部のノードのみをリバートした状態で、クラスタを元のリリースにアップグレードしないでく
ださい。
ノードをリバートすると、Flash Cacheモジュール内のキャッシュ データはクリアされます。
Flash Cacheモジュール内にキャッシュ データがないため、初回の読み取り要求に対してはディ
スクからデータを取り出すことになり、この期間の読み取りパフォーマンスが低下します。 読み
取り要求に対応するたびに、再びキャッシュにデータが蓄えられます。
FlexCacheボリュームを含むボリュームをData ONTAP 8.2からData ONTAP 8.1.xにリバートし
ても、FlexCacheボリュームは削除されません。
これらのFlexCacheボリュームは休止状態になり、クライアントからの読み取り要求のキャッシュ
には使用できません。
system node revert-toコマンドを入力してクラスタのリバートを開始したあと、リバートが完
了するまでは、versionコマンドを使用できなくなり、出力が表示されない状態になります。
潜在的なリバートの問題の特定
Data ONTAPのすべてのリリース ファミリーには、それぞれ固有のリバート要件があります。リバー
ト前にそれらの要件をきちんと把握し、解決しておく必要があります。
詳細情報および本書の発行後に見つかったリバートの問題を確認するには、『clustered Data
ONTAP リリース　ノート』を参照してください。 このガイドの公開時点で判明しているリバートの問
題は次のとおりです。
•
•
•
•
•
•
Data ONTAP 8.2では、NFSv4 ACLで最大1,024個のACEが新たにサポートされるようになりま
した。
400個を超えるACEを含む環境でNFSv4 ACLを使用している場合、以前のリリース ファミリー
にリバートするには特定の処理が必要です。
Data ONTAP 8.2以降へのアップグレードによってライセンスが適用された機能または使用許諾
された機能を入手し、Data ONTAP 8.2よりも前のバージョンではその機能にライセンスが必要
だった場合、リバートのあとにライセンスのインストールが必要になることがあります。
これは、リバートするリリース用のライセンスがインストールされていなかった場合に発生しま
す。
現在使用しているSPファームウェアのバージョンをサポートしていないData ONTAPリリースに
ダウングレードまたはリバートする場合、そのData ONTAPでサポートされるSPファームウェア
のバージョンをインストールする必要があります。
Data ONTAP 8.2よりも前のリリースにリバートする場合は、サーバ タイプ以外のデジタル証明
書と認証方式がcertのユーザ ログインを削除しておく必要があります。
Data ONTAP 8.1.2以前にリバートする場合、securitylogin role config resetコマンド
を実行して、一部のRole-Based Access Controlの設定をデフォルト値にリセットするように求め
るプロンプトが表示されます。
Data ONTAP 8.2以降では、NTPは常に有効です。
以前のData ONTAPリリース ファミリーへのクラスタのリバート | 83
•
•
•
以前のリリースにリバートした場合、以前のリリースを実行していたときの設定に関係なく、
NTPは有効なままになります。
RSHおよびIPv6接続は、Data ONTAP 8.2以降のリリースでのみサポートされます。
以前のリリースにリバートする場合は、クリアテキスト プロトコル（RSHおよびTelnet）を有効に
するために追加したRSHユーザ アカウントやIPv6ファイアウォール ポリシーを手動で削除して
おく必要があります。
Data ONTAP 8.2を搭載して出荷されたノードにData ONTAP 8.1リリース ファミリーのリリースを
再インストールする場合、ライセンスについて考慮する必要があります。
Data ONTAP 8.2が搭載されて出荷されたノードにData ONTAP 8.1リリース ファミリーのリリー
スを再インストールする場合、Data ONTAP 8.1リリース ファミリーでサポートされているキー形
式のクラスタベースのライセンスを再インストールする必要があります。
ADドメイン ユーザのクラスタ アクセス（管理SVM）は、Data ONTAP 8.1.1以降のリリースでの
みサポートされます。
以前のリリースにリバートする場合、ADドメイン ユーザのクラスタ アクセスの認証に使用され
る既存の認証トンネルの削除を求めるプロンプトがData ONTAPによって表示されます。
Data ONTAPクラスタをリバートする準備
以前のData ONTAPリリース ファミリーにリバートする前に、リバート要件を確認し、リバートの問
題をすべて解決して、ターゲット リリースのData ONTAPソフトウェア イメージを入手する必要があ
ります。
リバートの注意事項および手順の最新情報については、このData ONTAPソース リリースの 『リリ
ース ノート』を確認してください。
本番用システムをリバートする準備
ご使用の環境でクライアントにデータを提供するように設定しているシステムをリバートする場合、
リバートのための特定の設定が準備されていることを確認する必要があります。
リバート前の負荷共有ミラー関係とデータ保護ミラー関係の削除
Data ONTAP 8.1.xにリバートする場合は、Data ONTAP 8.2で作成した負荷共有ミラー関係とデー
タ保護ミラー関係を事前にすべて削除しておく必要があります。
手順
1. snapmirror showコマンドとvolume showコマンドを使用して、すべてのミラー関係に関する
情報と各関係のデスティネーション ボリュームに関する情報をそれぞれ確認して記録します。
削除する必要があるミラー関係は次のとおりです。
•
•
すべての負荷共有ミラー関係
Data ONTAP 8.2で作成したすべてのデータ保護ミラー関係
84 | アップグレードおよびリバート / ダウングレード ガイド
この関係は、snapmirror showコマンドを使用してミラー関係を表示したときに、
relationship capabilityが8.2 and aboveと表示されます。
すべてのデータ保護関係（Data ONTAP 8.2でクラスタを作成し直した場合）
Data ONTAP 8.2でsystem configuration recovery cluster recreateコマンドを使
用してクラスタを作成し直した場合は、すべてのデータ保護関係を削除する必要がありま
す。
•
例
次の例では、クラスタの関係がミラー関係になっています。
cluster1::>
source-path
----------vs1:vol1
snapmirror show -fields relationship-capability
destination-path relationship-capability
---------------- ----------------------vs1:vol3
"8.2 and above"
2. snapmirror breakコマンドを使用して、特定したそれぞれのデータ保護関係を解除します。
例
cluster1::> snapmirror break -destination-path vs1:vol3
3. snapmirror deleteコマンドを使用して、特定したそれぞれのデータ保護ミラー関係と負荷共
有ミラー関係を削除します。
例
cluster1::> snapmirror delete -destination-path vs1:vol3
削除されるのはミラー関係だけで、デスティネーション ボリュームは削除されません。
4. 削除したそれぞれのデータ保護ミラー関係について、ソース ノードでsnapmirror releaseコ
マンドを使用して、設定情報とSnapshotコピーをソース ボリュームから削除します。
例
cluster1::> snapmirror release -relationship-info-only -source-path vs1:vol1 -destinationpath vs1:vol3
5. volume offlineコマンドを使用して、負荷共有のそれぞれのデスティネーション ボリュームを
オフラインにします。
6. volume deleteコマンドを使用して、負荷共有と初期化されていないデータ保護のそれぞれの
デスティネーション ボリュームをオフラインにします。
終了後の操作
必要に応じて、リバート ターゲット リリースでミラー関係を再作成します。
以前のData ONTAPリリース ファミリーへのクラスタのリバート | 85
リバート前のバックアップ ヴォールト関係の削除
Data ONTAP 8.1.xにリバートする場合は、Data ONTAP 8.2で作成したバックアップ ヴォールト関
係を事前にすべて削除しておく必要があります。
手順
1. snapmirror showコマンドとvolume showコマンドを使用して、すべてのバックアップ ヴォー
ルト関係に関する情報と各関係のデスティネーション ボリュームに関する情報をそれぞれ確認
して記録します。
Data ONTAP 8.2よりも前のリリースにはバックアップ ヴォールトにバックアップする機能がない
ため、すべてのバックアップ ヴォールト関係を削除する必要があります。
例
次の例では、クラスタの関係がバックアップ ヴォールト関係になっています。
cluster1::>
source-path
----------vs1:vol2
snapmirror show -fields relationship-capability
destination-path relationship-capability
---------------- ----------------------vs1:vol2_backup "8.2 and above"
2. setコマンドで-privilege advancedパラメータを指定して、コマンド セッションの権限レベル
をadvancedに切り替えます。
3. snapmirror breakコマンドで-delete-snapshotsパラメータを指定して、特定したそれぞれ
のバックアップ ヴォールト関係を解除します。
-delete-snapshotsパラメータを使用すると、ボリュームにあるすべてのSnapshotコピーが削
除されます。バックアップ ヴォールト関係がある場合は、リバートする前に必ずこの処理を行う
必要があります。
例
cluster1::*> snapmirror break -destination-path vs1:vol2_backup
-delete-snapshots
4. snapmirror deleteコマンドを使用して、特定したそれぞれのバックアップ ヴォールト関係を
削除します。
例
cluster1::*> snapmirror delete -destination-path vs1:vol2_backup
削除されるのはバックアップ ヴォールト関係だけで、デスティネーション ボリュームは削除され
ません。
86 | アップグレードおよびリバート / ダウングレード ガイド
5. 削除したそれぞれのバックアップ ヴォールト関係について、ソース ノードでsnapmirror
releaseコマンドを使用して、設定情報とSnapshotコピーをソース ボリュームから削除します。
例
cluster1::*> snapmirror release -source-path vs1:vol2 -destination-path vs1:vol2_backup
6. volume offlineコマンドを使用して、それぞれのデスティネーション ボリュームをオフライン
にします。
7. volume deleteコマンドを使用して、それぞれのデスティネーション ボリュームを削除します。
Data ONTAP 8.2よりも前のリリースにリバートする場合のSMB 3.0の無効化
Data ONTAP 8.2以降のリリースでは、SMB 3.0がサポートされます。 Data ONTAP 8.2よりも前の
リリースにリバートする場合は、クラスタ内のすべてのSVMでSMB 3.0を無効にしておく必要があり
ます。
•
次のadvancedレベルのコマンドを実行すると、すべてのSVMでこの機能が無効になります。
vserver cifs options modify -vserver * -smb3-enabled false
•
Data ONTAP 8.2以降のリリースで利用できる新しい機能の中に、SMB 3.0に依存する機能が
いくつかあることに注意してください。これには、次の機能が含まれます。
◦
◦
◦
◦
◦
◦
共有の継続的な可用性
永続的ハンドル
SMB共有に対するリモートVSS
監視
ODXコピー オフロード
BranchCacheバージョン2
注: Hyper-V over SMBソリューションは、共有の継続的な可用性、永続的ハンドル、SMB共
有に対するリモートVSS、および監視プロトコルに依存します。 クラスタでHyper-V over SMB
ソリューションについて適切な処置を行うまでは、SMB 3.0を無効にしないでください。 また、
SMB 3.0を無効にする前に、リモートVSSで進行中のシャドウ コピー処理がないことを確認し
てください。
詳細については、『clustered Data ONTAP ファイル アクセスおよびプロトコル管理ガイド』を参照し
てください。
リバート前のCIFSのIPv6設定の再設定
Data ONTAP 8.2以降のリリースでは、CIFSでのIPv6の使用がサポートされます。 Data ONTAP
8.2よりも前のリリースにリバートする場合は、IPv6アドレスしか設定されていない項目について、す
べてIPv4アドレスで再設定しておく必要があります。
再設定が必要な項目の例としては次のものがあります。
•
CIFSサーバをホストするSVMのデータLIF、ルーティング グループ、静的ルート
以前のData ONTAPリリース ファミリーへのクラスタのリバート | 87
•
優先ドメイン コントローラ
注: ドメイン コントローラやCIFSサーバにサービスを提供するその他のサーバで、CIFSでのIPv6
の使用がサポートされないバージョンのData IPv4アドレスを設定しておく必要があります。
CIFSサーバ設定の管理の詳細については、『clustered Data ONTAP ファイル アクセスおよびプロ
トコル管理ガイド』を参照してください。 IPv4およびIPv6の設定の詳細については、『clustered Data
ONTAP ネットワーク管理ガイド』を参照してください。
Data ONTAP 8.2よりも前のリリースにリバートする場合に実行しておく必要があるFPolicyの設定に関
する処理
Data ONTAP 8.2以降のリリースでは、FPolicy機能がサポートされます。 Data ONTAP 8.2よりも前
のリリースにリバートする場合は、リバートに関する重要な考慮事項を理解しておく必要がありま
す。
FPolicyをサポートしないData ONTAPリリースにリバートする前に、以下の条件を満たす必要があ
ります。
•
FPolicyサーバがオフライン ビットをセットしているファイルがある場合は、それらを削除する
か、元のファイルに置き換えてから、FPolicyを無効にして、FPolicyをサポートしないData
ONTAPのリリースにリバートする必要があります。
注: リバートする前にオフライン ビットがセットされているファイルを元のファイルに置き換え
ない場合、クライアントは、スタブが参照するファイルではなく、スタブ ファイルにアクセスしま
す。
•
クラスタのFPolicy機能を無効にする場合は、クラスタ上のすべてのFPolicyポリシーを無効する
必要があります。
FPolicyの設定の管理の詳細については、『clustered Data ONTAP ファイル アクセスおよびプロト
コル管理ガイド』を参照してください。
Data ONTAP 8.2よりも前のリリースにリバートする場合に実行しておく必要があるHyper-V over SMB
ソリューションに関する処理
Data ONTAP 8.2以降のリリースでは、Hyper-V over SMBソリューションがサポートされます。 Data
ONTAP 8.2よりも前のリリースにリバートする場合は、リバートに関する重要な考慮事項を理解し
ておく必要があります。
以下の点について検討し、必要に応じて措置を講じる必要があります。
•
リバート時、仮想マシン ファイルへのHyper-Vサーバによるファイル アクセスがあってはなりま
せん。
◦
◦
Hyper-Vアプリケーションを使用して、仮想マシン ファイルを別のストレージ デバイスまたは
ローカル ストレージに移行することができます。
すべての仮想マシンを停止し、データLIFへのHyper-Vサーバの接続を手動で終了すること
ができます。
88 | アップグレードおよびリバート / ダウングレード ガイド
•
•
•
Data ONTAPでは、リバートの前にSMB 3.0が無効化されます。したがって、SMB接続を手
動で終了していない場合は、リバート時にData ONTAPによって切断されます。
Hyper-V over SMBソリューションは、このソリューションをサポートしていないData ONTAPのバ
ージョンにリバートする場合には使用できません。
仮想マシン ファイルをSVMのボリュームに格納する場合は、接続されたLUNを使用して仮想
マシン ファイルの格納およびアクセスを行うようにHyper-Vサーバを設定する必要があります。
そのあと、SMB共有から、接続されたLUNに、仮想マシン ファイルをコピーする必要がありま
す。
リバートするには、リモートVSSで進行中のシャドウ コピー処理がないことを確認する必要があ
ります。
進行中の処理がある場合は、処理が終了するまで待機するか、リバートを開始する前に手動
で中止する必要があります。 シャドウ コピー処理を中止する必要がある場合は、テクニカル サ
ポートにお問い合わせください。 リバート時、Data ONTAPでは、既存のSnapshotコピーは削除
されません。
リバートする前に、すべてのSVMでシャドウ コピー機能を無効にする必要があります。
次のadvanced権限のコマンドを実行すると、すべてのSVMでこの機能が無効になります。
vserver cifs options modify -vserver * -shadowcopy-enabled false
•
リバートする前に、すべてのSVMでSMB 3.0を無効にする必要があります。
次のadvanced権限のコマンドを実行すると、すべてのSVMでこの機能が無効になります。
vserver cifs options modify -vserver * -smb3-enabled false
注: Data ONTAP 8.2以降で利用できるCIFS機能の中には、ほかにもSMB 3.0に依存する機
能があります。 SMB 3.0に依存する他の機能について適切な処置を行うまでは、SMB 3.0を
無効にしないでください。 該当する機能としては、共有の継続的な可用性、永続的ハンド
ル、SMB共有に対するリモートVSS、監視プロトコル、ODXコピー オフロード、CIFSリパース
ポイント、BranchCache 2などがあります。
Hyper-V over SMBソリューションの管理の詳細については、『clustered Data ONTAP ファイル アク
セスおよびプロトコル管理ガイド』を参照してください。
Data ONTAP 8.2よりも前のリリースにリバートする場合に実行しておく必要があるローカル ユーザとロ
ーカル グループの設定に関する処理
Data ONTAP 8.2以降のリリースでは、CIFSサーバのローカル ユーザとローカル グループがサポ
ートされます。 Data ONTAP 8.2よりも前のリリースにリバートする場合は、リバートに関する重要な
考慮事項を理解しておく必要があります。
CIFSサーバのローカル ユーザとローカル グループがサポートされないバージョンにData ONTAP
をリバートする場合は、次の点について事前に確認し、該当する処理を実行しておく必要がありま
す。
•
Data ONTAPの以前のメジャー バージョンにリバートする際、認証とアクセス トークンの作成時
にローカル ユーザとローカル グループは使用されません。
以前のData ONTAPリリース ファミリーへのクラスタのリバート | 89
•
•
認証にローカル ユーザ アカウントを使用しているユーザがリバート後も引き続きアクセスでき
るようにするには、そのユーザが認証に使用できるドメイン アカウントを設定する必要がありま
す。
ローカル ユーザとローカル グループは、ファイルおよびフォルダのACLからは削除されませ
ん。
ファイル アクセス要求が、ローカル ユーザまたはローカル グループに付与されたアクセス権に
基づいて許可されるアクセスに依存する場合、その要求は拒否されます。 アクセスを許可する
には、ローカル ユーザとローカル グループではなく、ドメイン ユーザとドメイン グループに基づ
いてアクセスを許可するようにファイル アクセス権を再設定する必要があります。
リバートする前に、すべてのSVMでローカル ユーザおよびグループ機能を無効にする必要が
あります。
次のadvanced権限のコマンドを実行すると、すべてのSVMでこの機能が無効になります。
vserver cifs options modify -vserver * -is-local-users-and-groupsenabled false
ローカル ユーザとローカル グループの管理およびSMBアクセスの管理の詳細については、
『clustered Data ONTAP ファイル アクセスおよびプロトコル管理ガイド』を参照してください。
リバート前のSMBアクセスのエクスポート ポリシーの設定
Data ONTAP 8.2よりも前のリリースにリバートするときは、SMB共有を介してデータにアクセスす
るSVMでSMBアクセスのエクスポート ポリシーを事前に設定しておく必要があります。
Data ONTAP 8.2よりも前のリリースでは、SMBアクセスのエクスポート ポリシーは必須です。 Data
ONTAP 8.2以降、SMBアクセスのエクスポート ポリシーは省略可能になり、デフォルトで無効にな
っています。 エクスポート ポリシーが必須であるData ONTAPのバージョンにリバートすると、エク
スポート ポリシーが有効になり、SMBアクセスに必要となります。 SMBアクセスを許可するエクス
ポート ポリシーがリバート前に設定されていないと、SMB共有を介したSMBクライアントからのデ
ータ アクセスが拒否されます。
推奨される方法は、SMBクライアント アクセスに関する解決しにくい問題がリバートの完了後に発
生しないように、リバートする前に、SMB共有を使用するすべてのSVMでSMBのエクスポート ポリ
シーを設定することです。
SMBアクセスのエクスポート ポリシーの設定の詳細については、『clustered Data ONTAP ファイル
アクセスおよびプロトコル管理ガイド』を参照してください。
Data ONTAP 8.2よりも前のリリースにリバートする場合のBranchCacheの無効化
Data ONTAP 8.2以降のリリースでは、BranchCacheがサポートされます。 Data ONTAP 8.2よりも
前のリリースにリバートする場合は、クラスタ内のすべてのSVMでBranchCacheを無効にしておく
必要があります。
•
次のコマンドを実行すると、すべてのSVMでこの機能が無効になります。
vserver cifs branchcache delete -vserver * -flush-hashes true
このコマンドは、すべてのSVMのBranchCacheの設定とハッシュを削除します。 リバートの完了
後、必要に応じて、ハッシュ ストアが格納されていたディレクトリを手動で削除できます。
90 | アップグレードおよびリバート / ダウングレード ガイド
•
Data ONTAPをBranchCacheがサポートされないバージョンにリバートすると、BranchCache対応
クライアントに対してSMB共有でBranchCacheの機能がアドバタイズされなくなります。そのた
め、クライアントからハッシュ情報が要求されることはありません。
クライアントでは、代わりに、通常のSMB読み取り要求を使用して実際のコンテンツを要求しま
す。
BranchCache設定の管理の詳細については、『clustered Data ONTAP ファイル アクセスおよびプロ
トコル管理ガイド』を参照してください。
ボリュームが重複排除されたシステムのリバート
Data ONTAP 8.2リリース ファミリーからリバートする前に、リバート処理に使用する十分な空きス
ペースがボリュームにあることを確認してください。
タスク概要
重複排除が有効になっているシステムのData ONTAP 8.2リリース ファミリーからのリバートでは、
advancedモードのコマンドも使用します。 テクニカル サポートにお問い合わせください。
リバートするボリュームで重複排除とデータ圧縮の両方を有効にしている場合は、先にデータ圧縮
をリバートしてから重複排除をリバートする必要があります。
手順
1. volume efficiency showコマンドに-fieldsオプションを指定して、ボリュームで実行され
ている効率化処理の進捗状況を表示します。
例
次のコマンドは、効率化処理の進捗状況を表示します。
volume efficiency show -fields vserver,volume,progress
2. volume efficiency stopコマンドに-allオプションを指定して、アクティブな重複排除処理
とキューに登録されている重複排除処理をすべて中止します。
例
次のコマンドは、ボリュームVolAのアクティブな重複排除処理とキューに登録されている重複
排除処理をすべて中止します。
volume efficiency stop -vserver vs1 -volume VolA -all
3. volume efficiency offコマンドを使用して、重複排除処理を無効にします。
例
次のコマンドは、ボリュームVolAの重複排除処理を無効にします。
volume efficiency off -vserver vs1 -volume VolA
4. set -privilege advancedコマンドを使用して、advanced権限レベルでログインします。
以前のData ONTAPリリース ファミリーへのクラスタのリバート | 91
5. volume efficiency revert-toコマンドに-versionオプションを指定して、ボリュームの効
率化メタデータをData ONTAPの特定のバージョンにリバートします。
例
次のコマンドは、ボリュームVolAの効率化メタデータをバージョン8.1にリバートします。
volume efficiency revert-to -vserver vs1 -volume VolA -version 8.1
6. リバート処理の完了後、次のコマンドを入力して、admin権限レベルに戻ります。
set -privilege admin
重複排除の詳細については、『clustered Data ONTAP論理ストレージ管理ガイド』を参照してく
ださい。
ボリュームが圧縮されたシステムのリバート
Data ONTAP 8.2リリース ファミリーからリバートする前に、リバート処理に使用する十分な空きス
ペースがボリュームにあることを確認してください。
開始する前に
Data ONTAP 8.2リリース ファミリーからリバートする場合は、データが圧縮されているすべての
Snapshotコピーを削除して、ボリュームのデータを解凍しておく必要があります。
タスク概要
データ圧縮が有効になっているシステムのData ONTAP 8.2リリースからのリバートでは、advanced
モードのコマンドも使用します。 テクニカル サポートにお問い合わせください。
手順
1. volume efficiency showコマンドに-fieldsオプションを指定して、ボリュームで実行され
ている効率化処理の進捗状況を表示します。
例
次のコマンドは、効率化処理の進捗状況を表示します。
volume efficiency show -fields vserver,volume,progress
2. volume efficiency stopコマンドに-allオプションを指定して、ボリューム上のアクティブな
データおよびキューに入れられているデータの圧縮処理をすべて停止します。
例
次のコマンドは、ボリュームVolAのアクティブなデータおよびキューに入れられているデータ両
方の圧縮処理を中止します。
volume efficiency stop -vserver vs1 -volume VolA -all
92 | アップグレードおよびリバート / ダウングレード ガイド
3. volume efficiency modifyコマンドを使用して、ボリューム上のデータ圧縮を無効にしま
す。
例
次のコマンドは、ボリュームVolAのデータ圧縮を無効にします。
volume efficiency modify -vserver vs1 -volume VolA -compression false inline-compression false
4. volume efficiency offコマンドを使用して、ボリューム上の重複排除を無効にします。
例
次のコマンドは、ボリュームVolAの重複排除を無効にします。
volume efficiency off -vserver vs1 -volume VolA
5. set -privilege advancedコマンドを使用して、advanced権限レベルでログインします。
6. volume efficiency revert-toコマンドに-versionオプションを指定して、ボリュームの効
率化メタデータをData ONTAP 8.1リリース ファミリーにダウングレードします。
例
Data ONTAP 8.1リリースにリバートする場合の例を次に示します。このコマンドでは、ボリュー
ムVolAの効率化メタデータをバージョン8.1にダウングレードしています。
volume efficiency revert-to -vserver vs1 -volume VolA -version 8.1
7. リバート処理の完了後、set -privilege adminコマンドを使用して、admin権限に戻ります。
データ圧縮の詳細については、『clustered Data ONTAP論理ストレージ管理ガイド』を参照してく
ださい。
Infinite Volumeを備えたSVMの削除
Infinite Volumeを含むクラスタをData ONTAP 8.1ファミリーのData ONTAP 8.1.1以降のリリースか
らData ONTAP 8.1ファミリーの最初のリリースにリバートまたはダウングレードする場合は、
Infinite Volumeとそれを含むSVMを事前に削除しておく必要があります。
開始する前に
•
•
Infinite Volumeをアンマウントしておく必要があります。
Infinite Volumeとの間に確立されたSnapMirror関係をすべて削除しておく必要があります。
手順
1. Infinite Volumeがオンラインの場合は、volume offlineコマンドを使用してオフラインにしま
す。
2. volume deleteコマンドを使用してInfinite Volumeを削除します。
以前のData ONTAPリリース ファミリーへのクラスタのリバート | 93
3. volume deleteコマンドを使用して、データ保護やリカバリのために作成していたFlexVolをす
べて削除します。
4. SVMに関連付けられている、カスタマイズされたユーザ アカウントとロールをすべて削除しま
す。
ユーザについては、『clustered Data ONTAP ファイル アクセスおよびプロトコル管理ガイド』を
参照してください。
5. vserver stopコマンドを使用してSVMを停止します。
6. vserver deleteコマンドを使用してSVMを削除します。
7. クラスタ内のすべてのノードをリブートします。
クラスタとSVMの健全性の確認
クラスタのアップグレード、リバート、またはダウングレードを行う際は、実行前と実行後に、ノード
が正常に機能していてクラスタに追加するための条件を満たしていること、およびアグリゲートとボ
リュームがオンラインであることを確認する必要があります。
手順
1. クラスタ内のノードがオンラインで、クラスタに追加するための条件を満たしていることを確認し
ます。
cluster show
例
cluster1::> cluster show
Node
Health
--------------------- ------node0
true
node1
true
Eligibility
-----------true
true
正常に機能していないノードや条件を満たしていないノードがある場合は、EMSログでエラーを
確認して適切に修正します。 EMSメッセージの詳細については、『clustered Data ONTAP シス
テム アドミニストレーション ガイド（クラスタ管理）』を参照してください。
クラスタの健全性に関する問題のトラブルシューティング方法については、ネットアップ サポー
ト サイトの技術情報アーティクル「Troubleshooting Workflow: RDB app out of quorum」を参照
してください。
2. すべてのアグリゲートがオンラインであることを確認するために、物理ストレージと論理ストレー
ジ（ストレージのアグリゲートも含む）の状態を表示します。
storage aggregate show -state !online
このコマンドを実行すると、オンラインでないアグリゲートが表示されます。
94 | アップグレードおよびリバート / ダウングレード ガイド
例
cluster1::> storage aggregate show -state !online
There are no entries matching your query.
アグリゲートの管理の詳細については、『clustered Data ONTAP 物理ストレージ管理ガイド』を
参照してください。
3. すべてのボリュームがオンラインであることを確認するために、オンラインでないボリュームを
表示します。
volume show -state !online
例
cluster1::> volume show -state !online
There are no entries matching your query.
ボリュームの管理の詳細については、『clustered Data ONTAP論理ストレージ管理ガイド』を参
照してください。
リバートまたはダウングレード前のクラスタがクォーラムにあることの確認
すべてのノードがレプリケートされたデータベース（RDB）クォーラムに参加していることと、すべて
のリングがクォーラムにあることを確認する必要があります。 また、リングごとのクォーラム マスタ
ーがすべてのノードで同じであることも確認する必要があります。
タスク概要
クラスタ レプリケーション リングとRDBクォーラムの詳細については、『clustered Data ONTAP シス
テム アドミニストレーション ガイド（クラスタ管理）』を参照してください。
手順
1. 権限レベルをadvancedに設定します。
set -privilege advanced
2. 各RDBプロセスを表示します。
表示するRDBプロセス
コマンド
管理アプリケーション
cluster ring show -unitname mgmt
ボリューム ロケーション データベース
cluster ring show -unitname vldb
仮想インターフェイス マネージャ
cluster ring show -unitname vifmgr
SAN管理デーモン
cluster ring show -unitname bcomd
以前のData ONTAPリリース ファミリーへのクラスタのリバート | 95
例
cluster1::*> cluster ring show -unitname vldb
Node
UnitName Epoch DB Epoch
------ -------- ----- -------node0 vldb
154
154
node1 vldb
154
154
node2 vldb
154
154
node3 vldb
154
154
4 entries were displayed.
DB Trnxs
-------14847
14847
14847
14847
Master
--------node1
node1
node1
node1
Online
--------Secondary
Master
Secondary
Secondary
それぞれのプロセスについて、次の設定を確認します。
リレーショナル データベースのエポックとデータベースのエポックが各ノードで一致するこ
と。
リングごとのクォーラム マスターがすべてのノードで同一であること。
各リングのクォーラム マスターが異なる場合がある点に注意してください。
•
•
3. admin権限レベルに戻ります。
set -privilege admin
4. SAN環境を使用している場合は、クラスタがSANクォーラムにあることを確認します。
event log show -messagename scsiblade.*
scsibladeイベント メッセージに、SCSIブレードがクォーラムにあることが示されます。
例
cluster::> event log show -messagename scsiblade.*
Time
Node
Severity
------------------- ---------------- ------------8/13/2012 14:03:51 node0
INFORMATIONAL
8/13/2012 14:03:51 node1
INFORMATIONAL
Event
--------------------------scsiblade.in.quorum: The scsi-blade ...
scsiblade.in.quorum: The scsi-blade ...
システム時間の検証
NTPが構成され、クラスタ全体で時間が同期されていることを検証する必要があります。
タスク概要
システム時間の管理の詳細については、『clustered Data ONTAP システム アドミニストレーション
ガイド（クラスタ管理）』を参照してください。
手順
1. system services ntp server showコマンドを使用して、それぞれのノードがNTPサーバに
関連付けられていることを確認します。
例
cluster1::> system services ntp server show
Node
Server
Version
96 | アップグレードおよびリバート / ダウングレード ガイド
------ -------------------node0
ntp1.example.com
ntp2.example.com
node1
ntp1.example.com
ntp2.example.com
node2
ntp1.example.com
ntp2.example.com
node3
ntp1.example.com
ntp2.example.com
----------max
max
max
max
max
max
max
max
2. 各ノードの日付と時刻が同じであることを確認します。
実行しているData ONTAPのリリース
入力するコマンド
8.1.x
system node date show
8.2.x
cluster date show
例
cluster1::> cluster date show
Node
Date
--------- ------------------node0
4/6/2013 20:54:38
node1
4/6/2013 20:54:38
node2
4/6/2013 20:54:38
node3
4/6/2013 20:54:38
4 entries were displayed.
Timezone
------------------------GMT
GMT
GMT
GMT
リバート前のiSNSの準備
IPv6アドレスを使用しているiSNSサーバがある場合は、Data ONTAP 8.1にリバートする前に、
iSNSサーバとそれに関連付けられているSVM管理LIFをIPv4アドレスで再設定しておく必要があ
ります。
手順
1. クラスタで使用するように設定しているそれぞれのiSNSサーバについて、IPv4アドレスがあるこ
とを確認します。
iSNSサーバにIPv4アドレスがあるかどうかを確認するには、iSNSサーバのベンダーが提供す
るサーバ管理ツールまたはサーバ管理インターフェイスを使用します。 iSNSサーバにIPv4アド
レスがない場合は、次の手順に進む前に作成する必要があります。
2. iSNSが設定されているそれぞれのSVMについて、iSNSサーバのIPアドレスをIPv4アドレスに
変更します。
vserver iscsi isns modify -vserver Vserver_name -address IPv4_address
以前のData ONTAPリリース ファミリーへのクラスタのリバート | 97
3. iSNSが設定されているそれぞれのSVMについて、iSNSサーバに関連付けられているSVM管
理LIFをIPv4アドレスに変更します。
network interface modify -vserver Vserver_name -lif LIF_name -address
IPv4_address
リバート前のSnapshotコピーの準備
以前のData ONTAPリリースにリバートする場合は、現在のリリースへのアップグレード後に作成さ
れたSnapshotコピーを事前にすべて削除する必要があります。また、ルート アグリゲートとルート
ボリュームのSnapshotコピーを削除し、それらのSnapshotスケジュールも無効にする必要がありま
す。
開始する前に
SnapMirror環境でリバートを実行する場合は、次のミラー関係を事前に削除しておく必要がありま
す。
•
•
•
すべての負荷共有ミラー関係
Data ONTAP 8.2で作成したすべてのデータ保護ミラー関係
すべてのデータ保護ミラー関係（Data ONTAP 8.2でクラスタを作成し直した場合）
タスク概要
ルート アグリゲートとルート ボリュームのSnapshotコピーはクラスタシェルでは表示できず、
snapshot deleteコマンドを実行しても削除されません。そのため、それらのSnapshotコピーにつ
いては手動で削除する必要があります。
手順
1. 現在のリリースへのアップグレード後に作成されたSnapshotコピーを特定します。
volume snapshot show -fs-version 8.2
2. 特定したSnapshotコピーを削除します。
volume snapshot delete {-fs-version 8.2 -node nodename}
3. run -node nodename aggr statusコマンドを使用して、クラスタ内の各ノードのルート アグ
リゲートを特定します。
ルート アグリゲートは、aggr statusコマンドの出力でOptions列にrootとして表記されます。
cluster1::> run -node node1 aggr status
Aggr State
aggr0 online
Status
raid_dp, aggr
64-bit
4. ルート アグリゲートのSnapshotスケジュールを無効にします。
Options
root
98 | アップグレードおよびリバート / ダウングレード ガイド
run -node nodename aggr options root_aggr_name nosnap on
5. ルート アグリゲートのSnapshotコピーを削除します。
run -node nodename snap delete -A -a -f aggr_name
6. run -node nodename vol statusコマンドを使用して、クラスタ内の各ノードのルート ボリュー
ムを特定します。
ルート ボリュームは、vol statusコマンドの出力でOptions列にrootとして表記されます。
vs1::>
run -node node1 vol status
Volume State
vol0 online
Status
raid_dp, flex
64-bit
Options
root, nvfail=on
7. ルート ボリュームのSnapshotスケジュールを無効にします。
run -node nodename vol options root_volume_name nosnap on
8. ルート ボリュームのSnapshotコピーを削除します。
run -node nodename snap delete -a -f volume_name
例
cluster1::> run -node node1 snap delete -a -f vol0
Data ONTAPソフトウェア イメージの取得
各ノードからsystem node image updateコマンドを使用してアクセスできるように、ネットアップ
サポート サイトからネットワーク上のHTTPサーバにソフトウェア イメージをコピーする必要があり
ます。
タスク概要
クラスタをData ONTAPの目的のリリースにアップグレード、リバート、またはダウングレードするに
は、ソフトウェア イメージが必要です。 ソフトウェア イメージ、ファームウェアのバージョン情報、ス
トレージ システム モデルの最新のファームウェアは、ネットアップ サポート サイトで入手できます。
次の重要情報に注意してください。
•
•
ソフトウェア イメージはストレージ システム モデルに固有です。
ご使用のシステムに適したイメージを取得してください。
ソフトウェア イメージには、Data ONTAPの特定のバージョンのリリース時点でのシステム ファ
ームウェアの最新バージョンが含まれています。
以前のData ONTAPリリース ファミリーへのクラスタのリバート | 99
手順
1. ネットアップ サポート サイトの[Software Downloads]領域で目的のData ONTAPソフトウェアを
見つけます。
2. ネットアップ サポート サイトから、イメージを提供するHTTPサーバ上のディレクトリにソフトウェ
ア イメージ（82_setup_i.tgzなど）をコピーします。
関連情報
ソフトウェアのダウンロード：support.netapp.com/NOW/cgi-bin/software
クラスタでのData ONTAP 8.xソフトウェア イメージのインストール
必要に応じて、デフォルトの設定はData ONTAP 8.xの現在のバージョンのまま、Data ONTAP 8.x
イメージのソフトウェア パッケージをインストールすることができます。
開始する前に
Data ONTAPソフトウェア イメージを入手しておく必要があります。
手順
1. 要件に応じて、次のいずれかの処理を行います。
状況
コマンド
ソフトウェア イメージ system node image get -node * -package location replace-package true -background true
をダウンロードする
（インストールは行わ
このコマンドを実行すると、ソフトウェア イメージがすべてのノードに同時にダウ
ない）
ンロードされます。 一度に1つずつ各ノードにイメージをダウンロードする場合
は、-backgroundパラメータを指定せずに実行します。
すでにダウンロードし system node image update -node * -packagefile:///
てあるソフトウェア イ mroot/etc/software/image_name -background true
メージをインストール
このコマンドを実行すると、ソフトウェア イメージがすべてのノードに同時にインス
する
トールされます。 一度に1つずつ各ノードにイメージをインストールする場合は、backgroundパラメータを指定せずに実行します。
ソフトウェア イメージ system node image update -node * -package location のダウンロードとイン replace-package true -background true
ストールを1回の操作
このコマンドを実行すると、ソフトウェア イメージがすべてのノードに同時にダウ
で行う
ンロードされてインストールされます。 一度に1つずつ各ノードにイメージをダウン
ロードしてインストールする場合は、-backgroundパラメータを指定せずに実
行します。
2. ソフトウェア イメージが各ノードにダウンロードおよびインストールされたことを確認します。
100 | アップグレードおよびリバート / ダウングレード ガイド
system node image show-update-progress -node *
このコマンドを実行すると、ソフトウェア イメージのダウンロードとインストールについての現在
の状態が表示されます。 すべてのノードのRun StatusがExitedになり、Exit Statusが
Successになるまで、このコマンドを繰り返し実行します。
例
次の例では、2ノード クラスタの両方のノードでソフトウェア イメージのダウンロードとインストー
ルが正常に完了しています。
cluster1::> system node image show-update-progress -node *
There is no update/install in progress
Status of most recent operation:
Run Status:
Exited
Exit Status:
Success
Phase:
Run Script
Exit Message:
Installation complete. image2 updated on node node0.
There is no update/install in progress
Status of most recent operation:
Run Status:
Exited
Exit Status:
Success
Phase:
Run Script
Exit Message:
Installation complete. image2 updated on node node1.
2 entries were acted on.
Data ONTAPクラスタのリバート
クラスタをオフラインにして以前のData ONTAPリリースにリバートするには、ストレージ フェイルオ
ーバーとデータLIFを無効にし、リバートの前提条件を満たしていることを確認してから、ノードのク
ラスタ設定とファイルシステム設定をリバートします。この処理をクラスタの他の各ノードに対して
繰り返す必要があります。
開始する前に
リバート前の必要な準備作業を完了しておく必要があります。
タスク概要
クラスタをI/Oなしでリバートするには、クラスタをオフラインにした状態でリバートを行う必要があり
ます。
手順
1. ターゲットのData ONTAPソフトウェアがインストールされていることを確認します。
system node image show
例
次の例では、両方のノードに代替イメージとしてバージョン8.1.2がインストールされています。
以前のData ONTAPリリース ファミリーへのクラスタのリバート | 101
cluster1::> system node image show
Is
Is
Node
Image
Default Current Version
-------- ------- ------- ------- -------node0
image1 true
true
8.2.0
image2 false
false
8.1.2
node1
image1 true
true
8.2.0
image2 false
false
8.1.2
4 entries were displayed.
Install
Date
------------------10/25/2012 12:37:36
4/22/2013 13:52:22
10/25/2012 12:41:16
4/22/2013 13:55:22
ターゲットのData ONTAPソフトウェア イメージのインストールの詳細については、「クラスタで
のData ONTAP 8.xソフトウェア イメージのインストール」を参照してください。
2. ターゲットのData ONTAPソフトウェア イメージをデフォルトのイメージとして設定します。
system image modify {-node * -iscurrent false} -isdefault true
3. ターゲットのData ONTAPソフトウェア イメージがデフォルトのイメージとして設定されたことを確
認します。
system node image show
例
次の例では、両方のノードでデフォルトのイメージとしてバージョン8.1.2が設定されています。
cluster1::> system node image show
Is
Is
Node
Image
Default Current Version
-------- ------- ------- ------- -------node0
image1 false
true
8.2.0
image2 true
false 8.1.2
node1
image1 false
true
8.2.0
image2 true
false
8.1.2
4 entries were displayed.
Install
Date
------------------10/25/2012 12:37:36
4/22/2013 13:52:22
10/25/2012 12:41:16
4/22/2013 13:55:22
4. クラスタ内のすべてのデータLIFを無効にします。
network interface modify {-role data} -status-admin down
5. クラスタが2つのノードだけで構成されている場合は、クラスタのHAを無効にします。
cluster ha modify -configured false
6. HAペアのいずれかのノードについて次のコマンドを入力して、ノードのストレージ フェイルオー
バーを無効にします。
storage failover modify -node nodename -enabled false
ストレージ フェイルオーバーを無効にするのは、HAペアに対して1度だけです。 一方のノード
でストレージ フェイルオーバーを無効にすると、そのノードのパートナーでもストレージ フェイル
オーバーが無効になります。
7. 権限レベルをadvancedに設定します。
set -privilege advanced
102 | アップグレードおよびリバート / ダウングレード ガイド
8. クラスタが2つのノードだけで構成されている場合は、次の手順に従って、ノードにイプシロンが
設定されていないことを確認します。
a. ノードにイプシロンが現在設定されているかどうかを確認します。
cluster show -node nodename
例
次の例では、ノードにイプシロンが設定されています。
cluster1::*> cluster show -node node1
Node:
UUID:
Epsilon:
Eligibility:
Health:
node1
026efc12-ac1a-11e0-80ed-0f7eba8fc313
true
true
true
b. ノードにイプシロンが設定されている場合は、イプシロンをパートナーに移動できるように、
イプシロンをfalseに設定します。
cluster modify -node nodenameA -epsilon false
c. パートナー ノードでイプシロンをtrueに設定して、イプシロンをパートナーに移動します。
cluster modify -node nodenameB -epsilon true
9. ノードをリバートする準備が完了していることを確認します。
system node revert-to -node nodename -check-only true -version 8.1
check-onlyパラメータを指定すると、リバートを行う前に対処する必要がある前提条件が特定
されます。これには、たとえば次のような処理が含まれます。
•
•
•
ストレージ フェイルオーバーを無効にする。
Snapshotポリシーを無効にする。
新しいリリース ファミリーへのアップグレード後に作成されたSnapshotコピーを削除する。
特定された前提条件をすべて満たしたら、次の手順に進みます。
10. すべての前提条件を満たしていることを確認します。
system node revert-to -node nodename -check-only true -version 8.1
11. ノードのクラスタ設定をリバートします。
system node revert-to -node nodename -version 8.1
-versionオプションは、ターゲットのリリース ファミリーを表します。 たとえば、手順2で確認し
たインストール済みのソフトウェアがData ONTAP 8.1.2であれば、-versionオプションの値は
8.1になります。
クラスタ設定がリバートされ、クラスタシェルからログアウトされます。
12. もう一度クラスタシェルにログインし、ノードシェルに切り替えます。
system node run -node nodename
以前のData ONTAPリリース ファミリーへのクラスタのリバート | 103
13. ノードのファイルシステム構成をリバートします。
revert_to 8.1c
このコマンドを実行すると、ノードのファイルシステム設定をリバートする準備が完了しているこ
とが検証され、そのあとにリバートが実行されます。 前提条件が示された場合は、それに対処
してからrevert_toをもう一度入力する必要があります。
コマンドの処理が完了すると、LOADERプロンプトが表示されます。
14. LOADERプロンプトで、次のコマンドを入力してターゲット リリースでブートします。
boot_ontap
15. HAペアのもう一方のノードで、手順8（102ページ）から14（103ページ）を繰り返します。
16. クラスタが2つのノードだけで構成されている場合は、クラスタのHAを再度有効にします。
cluster ha modify -configured true
17. ストレージ フェイルオーバーを無効にしていた場合は、両方のノードで再度有効にします。
storage failover modify -node nodename -enabled true
18. クラスタの他のHAペアのそれぞれについて、手順6（101ページ）から17（103ページ）を繰り返し
ます。
リバート後の手順の完了
Data ONTAPの以前のリリース ファミリーにリバートしたあと、クラスタの健全性およびストレージの
可用性を確認する手順を実行する必要が生じることがあります。
また、手動で停止したサービスがすべて、リバート後に再起動したことを確認する必要がありま
す。 再起動していない場合はそれらのサービスを手動で再起動して、クライアントにストレージ シ
ステム サービスへの適切なアクセス権があることを確認する必要があります。
クラスタとSVMの健全性の確認
クラスタのアップグレード、リバート、またはダウングレードを行う際は、実行前と実行後に、ノード
が正常に機能していてクラスタに追加するための条件を満たしていること、およびアグリゲートとボ
リュームがオンラインであることを確認する必要があります。
手順
1. クラスタ内のノードがオンラインで、クラスタに追加するための条件を満たしていることを確認し
ます。
cluster show
例
cluster1::> cluster show
Node
Health
Eligibility
104 | アップグレードおよびリバート / ダウングレード ガイド
--------------------- ------- -----------node0
true
true
node1
true
true
正常に機能していないノードや条件を満たしていないノードがある場合は、EMSログでエラーを
確認して適切に修正します。 EMSメッセージの詳細については、『clustered Data ONTAP シス
テム アドミニストレーション ガイド（クラスタ管理）』を参照してください。
クラスタの健全性に関する問題のトラブルシューティング方法については、ネットアップ サポー
ト サイトの技術情報アーティクル「Troubleshooting Workflow: RDB app out of quorum」を参照
してください。
2. すべてのアグリゲートがオンラインであることを確認するために、物理ストレージと論理ストレー
ジ（ストレージのアグリゲートも含む）の状態を表示します。
storage aggregate show -state !online
このコマンドを実行すると、オンラインでないアグリゲートが表示されます。
例
cluster1::> storage aggregate show -state !online
There are no entries matching your query.
アグリゲートの管理の詳細については、『clustered Data ONTAP 物理ストレージ管理ガイド』を
参照してください。
3. すべてのボリュームがオンラインであることを確認するために、オンラインでないボリュームを
表示します。
volume show -state !online
例
cluster1::> volume show -state !online
There are no entries matching your query.
ボリュームの管理の詳細については、『clustered Data ONTAP論理ストレージ管理ガイド』を参
照してください。
LIFの有効化とホーム ポートへのリバート
リブートを行うと、一部のLIFが関連付けられているフェイルオーバー ポートに移行されることがあ
ります。 クラスタのアップグレード、リバート、またはダウングレードを行う際は、実行前と実行後
に、ホーム ポートにないLIFを有効にしてリバートする必要があります。
タスク概要
network interface revertコマンドを実行すると、対応するホーム ポートにないLIFがホーム
ポートにリバートされます（ホーム ポートが稼働している場合）。 LIFのホーム ポートはLIFの作成
以前のData ONTAPリリース ファミリーへのクラスタのリバート | 105
時に指定します。指定されているホーム ポートは、 network interface showコマンドを使用し
て確認できます。
手順
1. すべてのLIFのステータスを表示します。
network interface show
例
SVMのすべてのLIFのステータスを表示する例を次に示します。
cluster1::> network interface show -vserver vs0
Logical
Status
Network
Vserver
Interface Admin/Oper Address/Mask
----------- ---------- ---------- -----------------vs0
data001
down/down 192.0.2.120/24
data002
down/down 192.0.2.121/24
data003
down/down 192.0.2.122/24
data004
down/down 192.0.2.123/24
data005
down/down 192.0.2.124/24
data006
down/down 192.0.2.125/24
data007
down/down 192.0.2.126/24
data008
down/down 192.0.2.127/24
8 entries were displayed.
Current
Current Is
Node
Port
Home
------------- ------- ---node0
node0
node0
node0
node0
node0
node0
node0
e0e
e0f
e2a
e2b
e0e
e0f
e2a
e2b
true
true
true
true
false
false
false
false
Status AdminステータスがdownになっているLIFやIs homeステータスがfalseになっている
LIFがある場合は次の手順に進みます。
2. データLIFを有効にします。
network interface modify {-role data} -status-admin up
例
cluster1::> network interface modify {-role data} -status-admin up
8 entries were modified.
3. LIFをそれぞれのホーム ポートにリバートします。
network interface revert *
このコマンドを実行すると、すべてのLIFがそれぞれのホーム ポートにリバートされ、すべての
LIFのホーム ステータスがtrueに変わります。
例
cluster1::> network interface revert *
8 entries were acted on.
4. すべてのLIFがそれぞれのホーム ポートにあることを確認します。
network interface show
106 | アップグレードおよびリバート / ダウングレード ガイド
例
次の例では、SVM vs0のすべてのLIFがそれぞれのホーム ポートにあります。
cluster1::> network interface show -vserver vs0
Logical
Status
Network
Vserver
Interface Admin/Oper Address/Mask
----------- ---------- ---------- -----------------vs0
data001
up/up
192.0.2.120/24
data002
up/up
192.0.2.121/24
data003
up/up
192.0.2.122/24
data004
up/up
192.0.2.123/24
data005
up/up
192.0.2.124/24
data006
up/up
192.0.2.125/24
data007
up/up
192.0.2.126/24
data008
up/up
192.0.2.127/24
8 entries were displayed.
Current
Current Is
Node
Port
Home
------------- ------- ---node0
node0
node0
node0
node1
node1
node1
node1
e0e
e0f
e2a
e2b
e0e
e0f
e2a
e2b
true
true
true
true
true
true
true
true
リバート後のSnapshotコピーの準備
以前のバージョンのData ONTAPにリバートした場合は、Snapshotコピーの作成を再開するため
に、ルート ボリュームとルート アグリゲートのSnapshotスケジュールを再度有効にする必要があり
ます。
タスク概要
以前のバージョンのData ONTAPにリバートする前に無効にしたルート ボリュームとルート アグリ
ゲートのSnapshotスケジュールを再度有効にします。
手順
1. run -node nodename vol options root_vol_name nosnap offコマンドを使用して、ルー
ト ボリュームのSnapshotスケジュールを有効にします。
例
cluster1::> run -node node1 vol options vol0 nosnap off
2. run -node nodename aggr options root_aggr_name nosnap offコマンドを使用して、ル
ート アグリゲートのSnapshotスケジュールを有効にします。
例
cluster1::> run -node node1 aggr options aggr0 nosnap off
クライアント アクセスの確認（CIFSおよびNFS）
設定されているプロトコルについて、NFSクライアントおよびCIFSクライアントからのアクセスをテス
トして、クラスタにアクセスできることを確認します。
以前のData ONTAPリリース ファミリーへのクラスタのリバート | 107
SPファームウェアのダウングレードに関する注意事項
現在使用しているSPファームウェアのバージョンをサポートしていないData ONTAPリリースにダウ
ングレードまたはリバートする場合、そのData ONTAPでサポートされるSPファームウェアのバージ
ョンをインストールする必要があります。
Data ONTAPのリバートまたはダウングレードのプロセスが完了したら、リバートまたはダウングレ
ードしたバージョンのData ONTAPでサポートされるSPファームウェアのバージョンをインストール
する必要があります。 Data ONTAPの各リリースでサポートされるSPファームウェアのバージョンに
ついては、ネットアップ サポート サイトでBIOSサービス プロセッサのサポート マトリックスを参照し
てください。 SPファームウェアをダウンロードしてインストールする方法については、ネットアップ サ
ポート サイトでシステム ファームウェアおよび診断ダウンロードのページを参照してください。
リバートまたはダウングレード後の必要なVシリーズライセンスの再インストール
Data ONTAP 8.2からVシリーズ システムのライセンス方式が変わりました。 Data ONTAP 8.2以降
では、Vシリーズ システムでストレージ アレイのLUNにアクセスするためにV_StorageAttachライセ
ンス パッケージが必要になります。 実行するリバートの内容によっては、前のリリース用のVシリ
ーズ ライセンス キーのインストールが必要になる場合があります。
ライセンス キーは、リバートまたはダウングレードするVシリーズ システムごとに必要です。 ライセ
ンスがインストールされていないと、72時間後にVシリーズ システムがリブートされます。
状況または条件
Vシリーズのライセンス要件
Data ONTAP 8.1.xリリース ファミリーから8.2に
アップグレードしたVシリーズ システムを、8.1.x
リリース ファミリーのリリースにリバートする場
合
リバートするリリース用のVシリーズのライセン
スをインストールする必要はありません。 Data
ONTAPを8.1.xから8.2にアップグレードしたとき
のVシリーズライセンスが保存されており、Data
ONTAPを8.1.xにダウングレードする際はそれ
らのライセンスが再インストールされます。
Data ONTAP 8.2を新規にインストールしたシス リバートするリリース用のVシリーズ システム
テムを8.1.xリリース ファミリーのリリースにリバ のライセンス キーを手動でインストールする必
ートする場合
要があります。 営業担当者に問い合わせて、
システムおよびリリースに応じた適切なライセ
ンス キーを入手してください。
Data ONTAP 8.2.xから8.2リリース ファミリーの V_StorageAttachライセンス パッケージをインス
それよりも前のリリースにダウングレードする場 トールする必要はありません。リリース ファミリ
合
ーに対応した適切なライセンスが保存されてい
ます。
ライセンスのインストール方法については、『clustered Data ONTAP システム アドミニストレーショ
ン ガイド（SVM管理）』を参照してください。
108 | アップグレードおよびリバート / ダウングレード ガイド
vsadminロールが割り当てられたSVM管理者向けの機能の有効化
以前のバージョンのclustered Data ONTAPにリバートした場合、定義済みのvsadminロールでは
event generate-autosupport-log機能を使用できなくなります。 そのため、event generate
autosupport logというコマンド ディレクトリ名でカスタム ロールを作成し、そのロールのユーザ
を作成する必要があります。
タスク概要
新しいカスタム ロールが割り当てられたSVM管理者は、event generate-autosupport-logコ
マンドやそれに対応するZAPIのコマンドを実行できます。
手順
1. security login role createコマンドを使用して、SVM管理者の新しいロールを作成しま
す。
例
testという新しいロールを作成する例を次に示します。
cluster1::>security login role create -role test -cmddirname "event
generate-autosupport-log" -access all -query "" -vserver vs1
2. security login create -usernameコマンドを使用して、新しいユーザを作成して新しいロ
ールを割り当てます。
例
新しいユーザを作成して新しいロールを割り当てる例を次に示します。
cluster1::>security login create -username user_test1 -application
ontapi -authmethod password -role test -vserver vs1
109
同じ リリース ファミリーの以前のリリースにクラスタをダウ
ングレードする
クラスタを同じData ONTAPリリース ファミリーの以前のリリースに移行することを ダウングレードと
呼びます。 ダウングレードを実行するには、準備、以前のリリースのダウンロードおよびブート、ダ
ウングレード後の手順の完了が必要です。
ダウングレードでは、Data ONTAPのディスク上の構造を変更する必要はありません。要件および
互換性を確認したら、必要な作業はターゲット リリースを入手してブートするだけです。
ダウングレードのタイミングおよびテクニカル サポートへの連絡のタ
イミング
新しいシステムまたはテスト用システムは支援なしでダウングレードできますが、アップグレードの
実行中や実行後に問題が発生した場合や、本番環境システムをダウングレードする場合はテクニ
カル サポートに連絡してください。
次の場合のみ、テクニカル サポートの支援なしで以前のリリース ファミリーにダウングレードでき
ます。
•
•
テスト用システムで新しいリリースにアップグレードしたあと、テストが完了したので元のリリー
スに戻す。
Data ONTAPの以前のリリースで標準化している環境に、まだ本番環境に使用していないData
ONTAPの以降のリリースを実行する新しいストレージ システムを構成する。
本番環境のData ONTAPは、テクニカル サポートの支援なしでダウングレードしないでください。
次のような場合は、すぐにテクニカル サポートに連絡してください。
•
•
•
•
アップグレード プロセスが失敗して終了できない。
アップグレード プロセスが終了したが、本番環境でクラスタが使用できない。
アップグレード プロセスが終了してクラスタが本番環境に移行したが、正しく動作しない。
アップグレード プロセスが終了しないノードがあるので、プロセスが終了したノードをダウングレ
ードしたい。
ダウングレードの計画
Data ONTAPではリリースの更新ごとに新機能が追加されるため、ダウングレード要件について理
解し、ダウングレードが現在の構成にどのような影響を与えるかを評価する必要があります。
ダウングレードを開始する前に、次の作業を計画する必要があります。
•
Data ONTAPのダウングレード ソース リリースの『リリース ノート』の内容の確認。
110 | アップグレードおよびリバート / ダウングレード ガイド
•
•
•
既存のソフトウェアからターゲット リリースにダウンロードするための要件の理解。
ダウングレード実行後のシステムの潜在的な機能変更の把握。
ダウングレード チェックリストの全項目に対処するための準備。
クラスタ ダウングレードのチェックリスト
このチェックリストを使用して、ダウングレードの準備から、ダウングレードの実行、ダウングレード
後の手順の実行まで、進捗を記録しながら進めることができます。
ダウングレードの準備手順
準備手順は、次の条件がすべて当てはまると完了します。
状態
ターゲット リリースのソフトウェアおよびハードウェアのサポート
を確認した。
ハードウェアのサポートを確認するには、『Hardware Universe』
（旧称は『システム構成ガイド』）support.netapp.com/knowledge/
docs/hardware/NetApp/syscfg/index.shtmlを参照してください。
リリース固有のダウングレードの問題がすべて解決されてい
る。
クラスタシェルのアクセス権限がある。
クラスタとSVMが正常に実行されている。
リバートの処理を進める前に、すべてのアグリゲートとボリュー
ムがオンラインで正常に動作していることを確認する必要があ
ります。 ノードのステータスは、cluster showコマンドを使用し
て確認できます。
クラスタがクォーラムにある。
すべてのノードがクォーラムに参加しており、すべてのリングが
クォーラム内にある必要があります。 また、リングごとのクォー
ラム マスターがすべてのノードで同一でなければなりません。
LIFがオンラインで、それぞれの正しいホーム ポートにある。
LIFの設定は、network interfaceコマンドを使用して表示お
よび変更できます。
システム時間がクラスタ全体で同期されている。
バックエンド構成にエラーがない（Vシリーズ システムをダウン
グレードする場合）
バックエンド構成にエラーがないかどうかは、storage array
config showコマンドを使用して確認できます。
完了
同じ リリース ファミリーの以前のリリースにクラスタをダウングレードする | 111
状態
完了
各ノードでData ONTAP 8.1以降を実行している。
system node image showコマンドを実行して、実行している
ソフトウェアのバージョンがダウングレードに対応したバージョン
以上であることを確認します。
ターゲットのData ONTAPソフトウェア イメージがHTTPサーバ
にある。
ターゲットのData ONTAPリリースのソフトウェア イメージをネッ
トアップ サポート サイト：support.netapp.comからダウンロード
し、各ノードからアクセスできるHTTPサーバに格納します。
ターゲットのData ONTAPソフトウェア イメージが各ノードにイン
ストールされ、代替ブート デバイス イメージとして設定されてい
る。
ソフトウェア イメージは、 system node image updateコマン
ドを使用してインストールできます。 ソフトウェア イメージが各ノ
ードに代替ブート イメージとしてインストールされているかどう
かは、system node image showコマンドを使用して確認でき
ます。
SnapMirror処理が一時中止されている。
ダウングレードの実行手順
ダウングレードは、次の手順をすべて実行すると完了になります。
状態
完了
実行中のジョブがない。
アグリゲート、ボリューム、NDMP（ダンプまたはリストア）、またはSnapshotに
関する実行中のジョブやキューに格納されているジョブがある場合は、ジョブ
が完了するまで待つか、キューのエントリを中止します。
ターゲットのData ONTAPソフトウェアがインストールされ、デフォルトの ブー
ト イメージとして設定されている。
それぞれのHAペアのダウングレード HAペアの最初のノードのダウングレ
が完了している。
ードが完了している。
ノードのパートナーのダウングレード
が完了している。
ダウングレード後の手順
ダウングレード後の手順は、次の条件がすべて当てはまると完了します。
112 | アップグレードおよびリバート / ダウングレード ガイド
状態
完了
クラスタとSVMが正常に実行されている。
リバートの実行後に、すべてのアグリゲートとボリュームがオン
ラインで正常に動作していることを確認する必要があります。 ノ
ードのステータスは、cluster showコマンドを使用して確認で
きます。
LIFがオンラインで、それぞれの正しいホーム ポートにある。
LIFの設定は、network interfaceコマンドを使用して表示お
よび変更できます。
クライアントからアクセスできることを確認した。
設定されているそれぞれのプロトコルについて、クライアントか
らクラスタにアクセスできることを確認する必要があります。
SnapMirror処理が再開されている。
サービス プロセッサ ファームウェアのバージョンを確認した。
現在使用しているSPファームウェアのバージョンをサポートして
いないData ONTAPリリースにリバートする場合、そのData
ONTAPでサポートされるSPファームウェアのバージョンをインス
トールする必要があります。
Vシリーズ システムをダウングレードする場合の確認事項
ネイティブ ディスクが付属したシステムのダウングレード プロセスは、Vシリーズ システムとFASシ
ステムで同じです。 Vシリーズ システムでアレイLUNを使用している場合は、Data ONTAPを実行
するすべてのシステムで行う確認のほかに、いくつかの確認が追加で必要になります。
アレイLUNを使用するData ONTAP 8.2システムをダウングレードする場合は、事前に次の点につ
いて確認してください。
•
•
ダウングレードするリリースではサポートされないData ONTAP 8.2の機能を使用しているかど
うか
バックエンド ストレージ関連の構成にエラーがないかどうか
ダウングレード プロセスの注意事項
クラスタを以前のバージョンのData ONTAPにダウングレードするときは、ダウングレードの問題と
制限事項について理解しておく必要があります。
次の点に注意してください。
•
クラスタをData ONTAP 8.2にアップグレードした場合、Data ONTAP 8.2リリース ファミリーのそ
れよりも前のリリースへのダウングレードが可能です。
たとえば、Data ONTAP 8.2.1からは8.2.0にダウングレードできます。
同じ リリース ファミリーの以前のリリースにクラスタをダウングレードする | 113
•
•
•
クライアントに対するサービスが2分以上停止する可能性があります。
ダウングレードの実行中にクライアント トラフィックが120秒以上停止する可能性があります。
長時間のシステム停止が許容されないアプリケーションがある場合は、ダウングレードの計画
段階でこの点を考慮するようにしてください。
ダウングレードを行う際は、クラスタ内のすべてのノードが対象になります。
ダウングレードはクラスタ内のすべてのノードで実行する必要があります。ただし、一部の手順
については、HAペアごとにそれぞれのノードのセットに対して実行し、それが完了してから次
のペアのダウングレードに進む必要があります。
Data ONTAPクラスタは、ごく一時的に異なるバージョンが混在した状態、つまり、クラスタのノ
ードごとに異なるリリース ファミリーのData ONTAPが実行される状態にすることができます。
ただし、すべてのノードで新しいターゲット リリースが実行されるまでは、アップグレードは完了
していません。
クラスタに異なるバージョンが混在している間は、アップグレードに必要なコマンドを除き、クラ
スタの処理や構成を変更するコマンドは実行しないでください（監視処理は可能です）。
Data ONTAPのダウングレード プロセスの準備
ダウングレードを実行する前に、クラスタの健全性を確認し、アグリゲートとボリュームの健全性を
確認し、 ターゲットのData ONTAPイメージをインストールしておく必要があります。
クラスタとSVMの健全性の確認
クラスタのアップグレード、リバート、またはダウングレードを行う際は、実行前と実行後に、ノード
が正常に機能していてクラスタに追加するための条件を満たしていること、およびアグリゲートとボ
リュームがオンラインであることを確認する必要があります。
手順
1. クラスタ内のノードがオンラインで、クラスタに追加するための条件を満たしていることを確認し
ます。
cluster show
例
cluster1::> cluster show
Node
Health
--------------------- ------node0
true
node1
true
Eligibility
-----------true
true
正常に機能していないノードや条件を満たしていないノードがある場合は、EMSログでエラーを
確認して適切に修正します。 EMSメッセージの詳細については、『clustered Data ONTAP シス
テム アドミニストレーション ガイド（クラスタ管理）』を参照してください。
114 | アップグレードおよびリバート / ダウングレード ガイド
クラスタの健全性に関する問題のトラブルシューティング方法については、ネットアップ サポー
ト サイトの技術情報アーティクル「Troubleshooting Workflow: RDB app out of quorum」を参照
してください。
2. すべてのアグリゲートがオンラインであることを確認するために、物理ストレージと論理ストレー
ジ（ストレージのアグリゲートも含む）の状態を表示します。
storage aggregate show -state !online
このコマンドを実行すると、オンラインでないアグリゲートが表示されます。
例
cluster1::> storage aggregate show -state !online
There are no entries matching your query.
アグリゲートの管理の詳細については、『clustered Data ONTAP 物理ストレージ管理ガイド』を
参照してください。
3. すべてのボリュームがオンラインであることを確認するために、オンラインでないボリュームを
表示します。
volume show -state !online
例
cluster1::> volume show -state !online
There are no entries matching your query.
ボリュームの管理の詳細については、『clustered Data ONTAP論理ストレージ管理ガイド』を参
照してください。
LIFの有効化とホーム ポートへのリバート
リブートを行うと、一部のLIFが関連付けられているフェイルオーバー ポートに移行されることがあ
ります。 クラスタのアップグレード、リバート、またはダウングレードを行う際は、実行前と実行後
に、ホーム ポートにないLIFを有効にしてリバートする必要があります。
タスク概要
network interface revertコマンドを実行すると、対応するホーム ポートにないLIFがホーム
ポートにリバートされます（ホーム ポートが稼働している場合）。 LIFのホーム ポートはLIFの作成
時に指定します。指定されているホーム ポートは、 network interface showコマンドを使用し
て確認できます。
手順
1. すべてのLIFのステータスを表示します。
network interface show
同じ リリース ファミリーの以前のリリースにクラスタをダウングレードする | 115
例
SVMのすべてのLIFのステータスを表示する例を次に示します。
cluster1::> network interface show -vserver vs0
Logical
Status
Network
Vserver
Interface Admin/Oper Address/Mask
----------- ---------- ---------- -----------------vs0
data001
down/down 192.0.2.120/24
data002
down/down 192.0.2.121/24
data003
down/down 192.0.2.122/24
data004
down/down 192.0.2.123/24
data005
down/down 192.0.2.124/24
data006
down/down 192.0.2.125/24
data007
down/down 192.0.2.126/24
data008
down/down 192.0.2.127/24
8 entries were displayed.
Current
Current Is
Node
Port
Home
------------- ------- ---node0
node0
node0
node0
node0
node0
node0
node0
e0e
e0f
e2a
e2b
e0e
e0f
e2a
e2b
true
true
true
true
false
false
false
false
Status AdminステータスがdownになっているLIFやIs homeステータスがfalseになっている
LIFがある場合は次の手順に進みます。
2. データLIFを有効にします。
network interface modify {-role data} -status-admin up
例
cluster1::> network interface modify {-role data} -status-admin up
8 entries were modified.
3. LIFをそれぞれのホーム ポートにリバートします。
network interface revert *
このコマンドを実行すると、すべてのLIFがそれぞれのホーム ポートにリバートされ、すべての
LIFのホーム ステータスがtrueに変わります。
例
cluster1::> network interface revert *
8 entries were acted on.
4. すべてのLIFがそれぞれのホーム ポートにあることを確認します。
network interface show
例
次の例では、SVM vs0のすべてのLIFがそれぞれのホーム ポートにあります。
cluster1::> network interface show -vserver vs0
Logical
Status
Network
Vserver
Interface Admin/Oper Address/Mask
----------- ---------- ---------- -----------------vs0
data001
up/up
192.0.2.120/24
Current
Current Is
Node
Port
Home
------------- ------- ---node0
e0e
true
116 | アップグレードおよびリバート / ダウングレード ガイド
data002
up/up
data003
up/up
data004
up/up
data005
up/up
data006
up/up
data007
up/up
data008
up/up
8 entries were displayed.
192.0.2.121/24
192.0.2.122/24
192.0.2.123/24
192.0.2.124/24
192.0.2.125/24
192.0.2.126/24
192.0.2.127/24
node0
node0
node0
node1
node1
node1
node1
e0f
e2a
e2b
e0e
e0f
e2a
e2b
true
true
true
true
true
true
true
リバートまたはダウングレード前のクラスタがクォーラムにあることの確認
すべてのノードがレプリケートされたデータベース（RDB）クォーラムに参加していることと、すべて
のリングがクォーラムにあることを確認する必要があります。 また、リングごとのクォーラム マスタ
ーがすべてのノードで同じであることも確認する必要があります。
タスク概要
クラスタ レプリケーション リングとRDBクォーラムの詳細については、『clustered Data ONTAP シス
テム アドミニストレーション ガイド（クラスタ管理）』を参照してください。
手順
1. 権限レベルをadvancedに設定します。
set -privilege advanced
2. 各RDBプロセスを表示します。
表示するRDBプロセス
コマンド
管理アプリケーション
cluster ring show -unitname mgmt
ボリューム ロケーション データベース
cluster ring show -unitname vldb
仮想インターフェイス マネージャ
cluster ring show -unitname vifmgr
SAN管理デーモン
cluster ring show -unitname bcomd
例
cluster1::*> cluster ring show -unitname vldb
Node
UnitName Epoch DB Epoch
------ -------- ----- -------node0 vldb
154
154
node1 vldb
154
154
node2 vldb
154
154
node3 vldb
154
154
4 entries were displayed.
DB Trnxs
-------14847
14847
14847
14847
Master
--------node1
node1
node1
node1
Online
--------Secondary
Master
Secondary
Secondary
それぞれのプロセスについて、次の設定を確認します。
•
•
リレーショナル データベースのエポックとデータベースのエポックが各ノードで一致するこ
と。
リングごとのクォーラム マスターがすべてのノードで同一であること。
同じ リリース ファミリーの以前のリリースにクラスタをダウングレードする | 117
各リングのクォーラム マスターが異なる場合がある点に注意してください。
3. admin権限レベルに戻ります。
set -privilege admin
4. SAN環境を使用している場合は、クラスタがSANクォーラムにあることを確認します。
event log show -messagename scsiblade.*
scsibladeイベント メッセージに、SCSIブレードがクォーラムにあることが示されます。
例
cluster::> event log show -messagename scsiblade.*
Time
Node
Severity
------------------- ---------------- ------------8/13/2012 14:03:51 node0
INFORMATIONAL
8/13/2012 14:03:51 node1
INFORMATIONAL
Event
--------------------------scsiblade.in.quorum: The scsi-blade ...
scsiblade.in.quorum: The scsi-blade ...
システム時間の検証
NTPが構成され、クラスタ全体で時間が同期されていることを検証する必要があります。
タスク概要
システム時間の管理の詳細については、『clustered Data ONTAP システム アドミニストレーション
ガイド（クラスタ管理）』を参照してください。
手順
1. system services ntp server showコマンドを使用して、それぞれのノードがNTPサーバに
関連付けられていることを確認します。
例
cluster1::> system services
Node
Server
------ -------------------node0
ntp1.example.com
ntp2.example.com
node1
ntp1.example.com
ntp2.example.com
node2
ntp1.example.com
ntp2.example.com
node3
ntp1.example.com
ntp2.example.com
ntp server show
Version
----------max
max
max
max
max
max
max
max
2. 各ノードの日付と時刻が同じであることを確認します。
118 | アップグレードおよびリバート / ダウングレード ガイド
実行しているData ONTAPのリリース
入力するコマンド
8.1.x
system node date show
8.2.x
cluster date show
例
cluster1::> cluster date show
Node
Date
--------- ------------------node0
4/6/2013 20:54:38
node1
4/6/2013 20:54:38
node2
4/6/2013 20:54:38
node3
4/6/2013 20:54:38
4 entries were displayed.
Timezone
------------------------GMT
GMT
GMT
GMT
バックエンド構成のエラーの確認
Vシリーズ システムを以前のリリースにダウングレードする場合は、事前にstorage errors
showを実行して、バックエンド構成にエラーがないかどうかを確認する必要があります。
手順
1. 次のコマンドを入力します。
storage array config show
2. 手順1の結果に基づいて、次のいずれかを行います。
状況または条件
操作
storage array config showの出力にstorage errors
showを実行するように表示されない場合
ダウングレードを実行します。
storage array config showの出力にstorage errors
showを実行するように表示される場合
次の手順に進みます。
Data ONTAPとバックエンドのストレージ アレイの適切な連携に支障を及ぼす問題がバックエ
ンド構成で検出されなかった場合、storage errors showコマンドを実行するように指示され
ます。
3. 次のコマンドを入力します。
storage errors show
storage errors showコマンドを実行すると、次の例に示すように、アレイLUNレベルの詳細
が表示されます。
同じ リリース ファミリーの以前のリリースにクラスタをダウングレードする | 119
例
IBM_1742_1
---------NAME (Serial #): This Array LUN is only available on one path.
Proper configuration requires two paths.
4. storage errors showで表示された問題を解決し、システムをダウングレードします。
storage errors showの出力に表示されるエラーとその解決方法については、『V-Series
Installation Requirements and Reference Guide』で説明しています。
ダウングレード前の各ノードで実行しているソフトウェア バージョンの確認
system node image showコマンドを実行して、実行しているソフトウェアのバージョンがダウング
レード プロセスに対応したバージョン以上であることを確認します。
手順
1. 現在のソフトウェアのバージョンを確認します。
system node image show
例
cluster1::> system node image show
Is
Is
Node
Image
Default Current Version
-------- ------- ------- ------- -------node0
image1 true
true
8.2.1
image2 false
false
8.2.0
node1
image1 true
true
8.2.1
image2 false
false
8.2.0
4 entries were displayed.
Install
Date
------------------8/27/2013 13:52:22
3/25/2013 12:37:36
8/27/2013 13:55:22
3/25/2013 12:41:16
Data ONTAPソフトウェア イメージの取得
各ノードからsystem node image updateコマンドを使用してアクセスできるように、ネットアップ
サポート サイトからネットワーク上のHTTPサーバにソフトウェア イメージをコピーする必要があり
ます。
タスク概要
クラスタをData ONTAPの目的のリリースにアップグレード、リバート、またはダウングレードするに
は、ソフトウェア イメージが必要です。 ソフトウェア イメージ、ファームウェアのバージョン情報、ス
トレージ システム モデルの最新のファームウェアは、ネットアップ サポート サイトで入手できます。
次の重要情報に注意してください。
•
ソフトウェア イメージはストレージ システム モデルに固有です。
120 | アップグレードおよびリバート / ダウングレード ガイド
•
ご使用のシステムに適したイメージを取得してください。
ソフトウェア イメージには、Data ONTAPの特定のバージョンのリリース時点でのシステム ファ
ームウェアの最新バージョンが含まれています。
手順
1. ネットアップ サポート サイトの[Software Downloads]領域で目的のData ONTAPソフトウェアを
見つけます。
2. ネットアップ サポート サイトから、イメージを提供するHTTPサーバ上のディレクトリにソフトウェ
ア イメージ（82_setup_i.tgzなど）をコピーします。
関連情報
ソフトウェアのダウンロード：support.netapp.com/NOW/cgi-bin/software
クラスタでのData ONTAP 8.xソフトウェア イメージのインストール
必要に応じて、デフォルトの設定はData ONTAP 8.xの現在のバージョンのまま、Data ONTAP 8.x
イメージのソフトウェア パッケージをインストールすることができます。
開始する前に
Data ONTAPソフトウェア イメージを入手しておく必要があります。
手順
1. 要件に応じて、次のいずれかの処理を行います。
状況
コマンド
ソフトウェア イメージ system node image get -node * -package location replace-package true -background true
をダウンロードする
（インストールは行わ
このコマンドを実行すると、ソフトウェア イメージがすべてのノードに同時にダウ
ない）
ンロードされます。 一度に1つずつ各ノードにイメージをダウンロードする場合
は、-backgroundパラメータを指定せずに実行します。
すでにダウンロードし system node image update -node * -packagefile:///
てあるソフトウェア イ mroot/etc/software/image_name -background true
メージをインストール
このコマンドを実行すると、ソフトウェア イメージがすべてのノードに同時にインス
する
トールされます。 一度に1つずつ各ノードにイメージをインストールする場合は、backgroundパラメータを指定せずに実行します。
同じ リリース ファミリーの以前のリリースにクラスタをダウングレードする | 121
状況
コマンド
ソフトウェア イメージ system node image update -node * -package location のダウンロードとイン replace-package true -background true
ストールを1回の操作
このコマンドを実行すると、ソフトウェア イメージがすべてのノードに同時にダウ
で行う
ンロードされてインストールされます。 一度に1つずつ各ノードにイメージをダウン
ロードしてインストールする場合は、-backgroundパラメータを指定せずに実
行します。
2. ソフトウェア イメージが各ノードにダウンロードおよびインストールされたことを確認します。
system node image show-update-progress -node *
このコマンドを実行すると、ソフトウェア イメージのダウンロードとインストールについての現在
の状態が表示されます。 すべてのノードのRun StatusがExitedになり、Exit Statusが
Successになるまで、このコマンドを繰り返し実行します。
例
次の例では、2ノード クラスタの両方のノードでソフトウェア イメージのダウンロードとインストー
ルが正常に完了しています。
cluster1::> system node image show-update-progress -node *
There is no update/install in progress
Status of most recent operation:
Run Status:
Exited
Exit Status:
Success
Phase:
Run Script
Exit Message:
Installation complete. image2 updated on node node0.
There is no update/install in progress
Status of most recent operation:
Run Status:
Exited
Exit Status:
Success
Phase:
Run Script
Exit Message:
Installation complete. image2 updated on node node1.
2 entries were acted on.
無停止アップグレードまたは無停止ダウングレードを行うためのSnapMirror関係の準
備
Data ONTAPの無停止アップグレードまたは無停止ダウングレードを実行する前に、SnapMirrorの
動作を一時停止する必要があります。
タスク概要
SnapMirror処理の詳細については、snapmirrorのマニュアル ページおよび『clustered Data ONTAP
データ保護ガイド』を参照してください。
122 | アップグレードおよびリバート / ダウングレード ガイド
手順
1. snapmirror showコマンドを使用して、各SnapMirror関係のデスティネーション パスを確認し
ます。
2. それぞれのデスティネーション ボリュームについて、以降のSnapMirror転送を一時中止しま
す。
snapmirror quiesce -destination-path destination
例
Data ONTAP 8.1からアップグレードする場合の例を次に示します。この例では、SVM vs0およ
びクラスタcluster1からデスティネーション ボリュームvol1への転送を休止します。
cluster1::> snapmirror quiesce -destination-path cluster1://vs0/vol1
例
Data ONTAP 8.2リリース ファミリーの別のリリースにダウングレードする場合の例を次に示しま
す。この例では、SVM vs0からデスティネーション ボリュームvol1への転送を休止します。
cluster1::> snapmirror quiesce -destination-path vs0:vol1
3. 現在転送中のSnapMirror関係があるかどうかを確認します。
snapmirror show -status Transferring
現在転送中のSnapMirror関係がある場合は、転送が完了してからData ONTAPのアップグレ
ードを実行する必要があります。
4. データを転送中のSnapMirror関係がある場合は、転送を中止します。
snapmirror abort -destination-path destination -h
-hパラメータを指定すると、再開チェックポイントが破棄され、転送が完了した最後のSnapshot
コピーの状態にデスティネーション ボリュームがリストアされます。
負荷共有ミラーの転送を中止する場合は、-foreground trueパラメータを使用する必要が
あります。
同じ リリース ファミリーの以前のリリースにクラスタをダウングレードする | 123
Data ONTAPのダウングレード プロセスの実行
クラスタを同じData ONTAPリリース ファミリーの以前のリリースにダウングレードするには、ターゲ
ット イメージをインストールし、ダウングレードの問題に対処して、デフォルトのブート イメージを変
更する必要があります。
開始する前に
ダウングレードの手順を実行する前に、ダウングレードの準備を完了しておく必要があります。
実行中のジョブがないことの確認
別のData ONTAPリリースにアップグレードまたはダウングレードする前に、クラスタ ジョブのステ
ータスを確認する必要があります。 アグリゲート、ボリューム、NDMP（ダンプまたはリストア）、ま
たはSnapshotに関する実行中のジョブ（作成、削除、移動、変更、複製、マウントなど）やキューに
格納されているジョブがある場合は、ジョブが完了するまで待つか、キューのエントリを中止しま
す。
手順
1. アグリゲート、ボリューム、またはSnapshotに関する実行中のジョブとキューに格納されている
ジョブのリストを確認します。
job show
例
cluster1::> job show
Owning
Job ID Name
Vserver
Node
------ ---------------- --------- -----------308114 mirror-daily-3587206
node-vserver
node1
Descr:Auto-replicate to 1 mirror(s)
308115 mirror-daily-3618985
node-vserver
node1
Descr:Auto-replicate to 1 mirror(s)
308116 mirror-daily-3619010
node-vserver
node1
Descr:Auto-replicate to 1 mirror(s)
308117 mirror-daily-3749547
node-vserver
node1
Descr:Auto-replicate to 1 mirror(s)
4 entries were displayed.
State
---------Running
Running
Queued
Queued
2. アグリゲート、ボリューム、またはSnapshotに関する実行中のジョブとキューに格納されている
ジョブを削除します。
job delete *
124 | アップグレードおよびリバート / ダウングレード ガイド
例
cluster1::> job delete *
4 entries were displayed.
状態がQueuedまたはDormantと表示されたジョブは、job showコマンドの出力に表示されるジ
ョブIDを使用して個別に削除しなければならない場合があります。
job delete -id job_id
3. 実行中またはキューに格納されているジョブがないことを確認します。
job show
例
cluster1::> job show
This table is currently empty.
以前のバージョンのData ONTAP 8.xへのデフォルト ブート イメージの変更
デフォルト ブート イメージを変更するには、クラスタの各ノードでデフォルト ブート イメージを設定し
たあと、HAペアの各ノードでフェイルオーバー処理を開始し、「障害」システムを更新してからギブ
バックを開始します。この処理をクラスタの各ペアに対して繰り返す必要があります。
手順
1. ターゲットのData ONTAP 8.2ソフトウェアがインストールされていることを確認します。
system node image show
例
次の例では、両方のノードに代替イメージとしてバージョン8.2.0がインストールされています。
cluster1::> system node image show
Is
Is
Node
Image
Default Current Version
-------- ------- ------- ------- -------node0
image1 true
true
8.2.1
image2 false
false
8.2.0
node1
image1 true
true
8.2.1
image2 false
false
8.2.0
4 entries were displayed.
Install
Date
------------------10/25/2012 12:37:36
4/22/2013 13:52:22
10/25/2012 12:41:16
4/22/2013 13:55:22
ターゲットのData ONTAPソフトウェア イメージのインストールの詳細については、「クラスタで
のData ONTAP 8.xソフトウェア イメージのインストール」を参照してください。
2. 現在のデフォルト ブート イメージを8.2.xに変更します。
system node image modify {-iscurrent true} -isdefault false
同じ リリース ファミリーの以前のリリースにクラスタをダウングレードする | 125
このコマンドを実行すると、以前のリリースではサポートされない現在のリリースの機能が特定
されます。 そのような機能が見つかった場合は、次に進む前に、コマンドの出力に表示された
指示に従って対処する必要があります。
例
デフォルト ブート イメージを8.2.0に変更する例を次に示します。
cluster1::> system node image modify {-iscurrent true} -isdefault false
2 entries were modified.
3. デフォルト ブート イメージをもう一度表示します。
system node image show
例
次の例では、両方のノードでデフォルト イメージがバージョン8.2.0になっています。
cluster1::> system node image show
Is
Is
Node
Image
Default Current Version
-------- ------- ------- ------- -------node0
image1 false
true
8.2.1
image2 true
false
8.2.0
node1
image1 false
true
8.2.1
image2 true
false
8.2.0
4 entries were displayed.
Install
Date
------------------10/25/2012 12:37:36
4/22/2013 13:52:22
10/25/2012 12:41:16
4/22/2013 13:55:22
4. ストレージ フェイルオーバーが有効になっていて実行可能であることを確認します。
storage failover show
例
次の例では、node0とnode1の各ノードでストレージ フェイルオーバーが有効かつ実行可能な状
態になっています。
cluster1::> storage failover show
Node
-------------node0
node1
2 entries were
Partner
-------------node1
node0
displayed.
Enabled
------true
true
Takeover
Possible
-------true
true
InterConn
Up
--------true
true
State
----------connected
connected
5. クラスタが2つのノードだけで構成されている（単一のHAペア）場合は、クラスタHAが構成され
ていることを確認します。
cluster ha show
126 | アップグレードおよびリバート / ダウングレード ガイド
例
cluster1::> cluster ha show
High Availability Configured: true
6. 自動ギブバックが有効になっている場合は、HAペアの両方のノードで無効にします。
storage failover modify -node nodename -auto-giveback false
7. ダウングレード時にテイクオーバーされるノードからLIFを移行します。
network interface migrate-all -node nodename
SANプロトコルのデータLIFは移行されません。 クラスタ内の各ノードにこれらのLIFがあれば、
アップグレード プロセスの実行時に代替パスからデータを提供できます。
8. テイクオーバーを開始します。
storage failover takeover -ofnode nodename
テイクオーバーされたノードを代替ソフトウェア イメージでブートするには通常のテイクオーバ
ーが必要なため、-option immediateパラメータは指定しないでください。
テイクオーバーされたノードがブートし、waiting for giveback状態になります。
9. テイクオーバーが正常に完了したことを確認します。
storage failover show
テイクオーバーが正常に完了した例を次に示します。 ノードnode0の状態はWaiting for
giveback、パートナーの状態はIn takeoverになっています。
例
cluster1::> storage failover show
Takeover
Node
Partner
Possible
-------------- -------------- -------node0
node1
node1
node0
false
2 entries were displayed.
State Description
------------------------------------Waiting for giveback (HA mailboxes)
In takeover
10. 8分待ってから、次の条件を満たしていることを確認します。
•
•
クライアントのマルチパス（導入している場合）が安定している。
クライアントがテイクオーバー中に発生するI/Oの中断から回復した。
回復までの時間はクライアントによって異なり、クライアント アプリケーションの特性によっ
ては8分以上かかることもあります。
11. ルート アグリゲートをパートナー ノードに戻します。
storage failover giveback –ofnode nodename
注意: 次のような状況が検出された場合、ギブバックは開始されず、エラー メッセージが表示
されてイベントが生成されます。
同じ リリース ファミリーの以前のリリースにクラスタをダウングレードする | 127
•
•
•
実行時間の長い処理（ASUPの生成など）
再開できない処理（アグリゲートの作成など）
エラー状態（ノード間のディスク接続不一致など）
ギブバックが開始されない場合は、次の手順を実行します。
a. エラー メッセージに示された「拒否」状態に対処して、特定された処理が正常に終了する
ようにします。
b. ギブバック コマンドを再度入力します。
storage failover giveback -ofnode nodename
または、メッセージおよびイベントが自分の環境にどのように影響するかを分析します。 拒
否状態でもそれほど影響がない場合は、次のコマンドを入力してギブバックの拒否を無視し
てもかまいません。
storage failover giveback –ofnode nodename -override-vetoes true
拒否を無視しても問題がないかどうかの判断に関する詳細については、『clustered Data
ONTAP ハイアベイラビリティ構成ガイド』を参照してください。
最初にルート アグリゲートがパートナー ノードに戻され、そのノードのブートが完了するとルー
ト以外のアグリゲートが戻されます。
次の手順に進む前に、すべてのアグリゲートがノードBに戻されている必要があります。 この処
理には10分ほどかかります。
12. すべてのアグリゲートが戻されたことを確認します。
storage failover show-giveback
すべてのアグリゲートが戻されると、新しくブートされたシステムでクライアントへのデータ提供
が開始されます。
13. HAペアのもう一方のノードで、手順7（126ページ）から12（127ページ）を繰り返します。
14. 自動ギブバックを有効にしていた場合は、両方のノードで再度有効にします。
storage failover modify -node nodename -auto-giveback true
15. ダウングレードするクラスタにHAペアが複数含まれている場合は、次のノードのペアをダウン
グレードする前に、クラスタがクォーラムにあること、およびサービスが実行されていることを確
認します。
128 | アップグレードおよびリバート / ダウングレード ガイド
ダウングレード後の手順の実行
クラスタを Data ONTAP 8.xよりも前のバージョンにダウングレードした場合は、クラスタが正常に
動作することを確認してください。
クラスタとSVMの健全性の確認
クラスタのアップグレード、リバート、またはダウングレードを行う際は、実行前と実行後に、ノード
が正常に機能していてクラスタに追加するための条件を満たしていること、およびアグリゲートとボ
リュームがオンラインであることを確認する必要があります。
手順
1. クラスタ内のノードがオンラインで、クラスタに追加するための条件を満たしていることを確認し
ます。
cluster show
例
cluster1::> cluster show
Node
Health
--------------------- ------node0
true
node1
true
Eligibility
-----------true
true
正常に機能していないノードや条件を満たしていないノードがある場合は、EMSログでエラーを
確認して適切に修正します。 EMSメッセージの詳細については、『clustered Data ONTAP シス
テム アドミニストレーション ガイド（クラスタ管理）』を参照してください。
クラスタの健全性に関する問題のトラブルシューティング方法については、ネットアップ サポー
ト サイトの技術情報アーティクル「Troubleshooting Workflow: RDB app out of quorum」を参照
してください。
2. すべてのアグリゲートがオンラインであることを確認するために、物理ストレージと論理ストレー
ジ（ストレージのアグリゲートも含む）の状態を表示します。
storage aggregate show -state !online
このコマンドを実行すると、オンラインでないアグリゲートが表示されます。
例
cluster1::> storage aggregate show -state !online
There are no entries matching your query.
アグリゲートの管理の詳細については、『clustered Data ONTAP 物理ストレージ管理ガイド』を
参照してください。
同じ リリース ファミリーの以前のリリースにクラスタをダウングレードする | 129
3. すべてのボリュームがオンラインであることを確認するために、オンラインでないボリュームを
表示します。
volume show -state !online
例
cluster1::> volume show -state !online
There are no entries matching your query.
ボリュームの管理の詳細については、『clustered Data ONTAP論理ストレージ管理ガイド』を参
照してください。
LIFの有効化とホーム ポートへのリバート
リブートを行うと、一部のLIFが関連付けられているフェイルオーバー ポートに移行されることがあ
ります。 クラスタのアップグレード、リバート、またはダウングレードを行う際は、実行前と実行後
に、ホーム ポートにないLIFを有効にしてリバートする必要があります。
タスク概要
network interface revertコマンドを実行すると、対応するホーム ポートにないLIFがホーム
ポートにリバートされます（ホーム ポートが稼働している場合）。 LIFのホーム ポートはLIFの作成
時に指定します。指定されているホーム ポートは、 network interface showコマンドを使用し
て確認できます。
手順
1. すべてのLIFのステータスを表示します。
network interface show
例
SVMのすべてのLIFのステータスを表示する例を次に示します。
cluster1::> network interface show -vserver vs0
Logical
Status
Network
Vserver
Interface Admin/Oper Address/Mask
----------- ---------- ---------- -----------------vs0
data001
down/down 192.0.2.120/24
data002
down/down 192.0.2.121/24
data003
down/down 192.0.2.122/24
data004
down/down 192.0.2.123/24
data005
down/down 192.0.2.124/24
data006
down/down 192.0.2.125/24
data007
down/down 192.0.2.126/24
data008
down/down 192.0.2.127/24
8 entries were displayed.
Current
Current Is
Node
Port
Home
------------- ------- ---node0
node0
node0
node0
node0
node0
node0
node0
e0e
e0f
e2a
e2b
e0e
e0f
e2a
e2b
true
true
true
true
false
false
false
false
Status AdminステータスがdownになっているLIFやIs homeステータスがfalseになっている
LIFがある場合は次の手順に進みます。
130 | アップグレードおよびリバート / ダウングレード ガイド
2. データLIFを有効にします。
network interface modify {-role data} -status-admin up
例
cluster1::> network interface modify {-role data} -status-admin up
8 entries were modified.
3. LIFをそれぞれのホーム ポートにリバートします。
network interface revert *
このコマンドを実行すると、すべてのLIFがそれぞれのホーム ポートにリバートされ、すべての
LIFのホーム ステータスがtrueに変わります。
例
cluster1::> network interface revert *
8 entries were acted on.
4. すべてのLIFがそれぞれのホーム ポートにあることを確認します。
network interface show
例
次の例では、SVM vs0のすべてのLIFがそれぞれのホーム ポートにあります。
cluster1::> network interface show -vserver vs0
Logical
Status
Network
Vserver
Interface Admin/Oper Address/Mask
----------- ---------- ---------- -----------------vs0
data001
up/up
192.0.2.120/24
data002
up/up
192.0.2.121/24
data003
up/up
192.0.2.122/24
data004
up/up
192.0.2.123/24
data005
up/up
192.0.2.124/24
data006
up/up
192.0.2.125/24
data007
up/up
192.0.2.126/24
data008
up/up
192.0.2.127/24
8 entries were displayed.
Current
Current Is
Node
Port
Home
------------- ------- ---node0
node0
node0
node0
node1
node1
node1
node1
e0e
e0f
e2a
e2b
e0e
e0f
e2a
e2b
true
true
true
true
true
true
true
true
クライアント アクセスの確認（CIFSおよびNFS）
設定されているプロトコルについて、NFSクライアントおよびCIFSクライアントからのアクセスをテス
トして、クラスタにアクセスできることを確認します。
同じ リリース ファミリーの以前のリリースにクラスタをダウングレードする | 131
SnapMirror処理の再開
無停止アップグレードまたは無停止ダウングレードを行った場合は、一時中止していたSnapMirror
関係を完了後に再開する必要があります。
開始する前に
snapmirror quiesceコマンドを使用して既存のSnapMirror関係を一時中止し、クラスタの無停
止アップグレードまたは無停止ダウングレードを完了しておく必要があります。
手順
1. それぞれのデスティネーション ボリュームについて、既存のSnapMirror転送を再開します。
snapmirror resume -destination-path destination
例
Relationship CapabilityがPre 8.2のSnapMirror関係の転送を再開する例を次に示します。デス
ティネーション パスはcluster1://vs0/vol1です。
cluster1::> snapmirror resume -destination-path cluster1://vs0/vol1
2. snapmirror showコマンドを使用して、SnapMirror処理が再開されたことを確認します。
3. 再開されないSnapMirror処理がある場合は、転送を中止します。
snapmirror abort -destination-path destination -h
-hパラメータを指定すると、再開チェックポイントが破棄され、転送が完了した最後のSnapshot
コピーの状態にデスティネーション ボリュームがリストアされます。
転送を中止したあとも再開されないSnapMirror処理がある場合は、snapmirror resyncコマ
ンドを使用してミラー関係を再確立する必要があります。
SPファームウェアのダウングレードに関する注意事項
現在使用しているSPファームウェアのバージョンをサポートしていないData ONTAPリリースにダウ
ングレードまたはリバートする場合、そのData ONTAPでサポートされるSPファームウェアのバージ
ョンをインストールする必要があります。
Data ONTAPのリバートまたはダウングレードのプロセスが完了したら、リバートまたはダウングレ
ードしたバージョンのData ONTAPでサポートされるSPファームウェアのバージョンをインストール
する必要があります。 Data ONTAPの各リリースでサポートされるSPファームウェアのバージョンに
ついては、ネットアップ サポート サイトでBIOSサービス プロセッサのサポート マトリックスを参照し
てください。 SPファームウェアをダウンロードしてインストールする方法については、ネットアップ サ
ポート サイトでシステム ファームウェアおよび診断ダウンロードのページを参照してください。
132 | アップグレードおよびリバート / ダウングレード ガイド
リバートまたはダウングレード後の必要なVシリーズライセンスの再インストール
Data ONTAP 8.2からVシリーズ システムのライセンス方式が変わりました。 Data ONTAP 8.2以降
では、Vシリーズ システムでストレージ アレイのLUNにアクセスするためにV_StorageAttachライセ
ンス パッケージが必要になります。 実行するリバートの内容によっては、前のリリース用のVシリ
ーズ ライセンス キーのインストールが必要になる場合があります。
ライセンス キーは、リバートまたはダウングレードするVシリーズ システムごとに必要です。 ライセ
ンスがインストールされていないと、72時間後にVシリーズ システムがリブートされます。
状況または条件
Vシリーズのライセンス要件
Data ONTAP 8.1.xリリース ファミリーから8.2に
アップグレードしたVシリーズ システムを、8.1.x
リリース ファミリーのリリースにリバートする場
合
リバートするリリース用のVシリーズのライセン
スをインストールする必要はありません。 Data
ONTAPを8.1.xから8.2にアップグレードしたとき
のVシリーズライセンスが保存されており、Data
ONTAPを8.1.xにダウングレードする際はそれ
らのライセンスが再インストールされます。
Data ONTAP 8.2を新規にインストールしたシス リバートするリリース用のVシリーズ システム
テムを8.1.xリリース ファミリーのリリースにリバ のライセンス キーを手動でインストールする必
ートする場合
要があります。 営業担当者に問い合わせて、
システムおよびリリースに応じた適切なライセ
ンス キーを入手してください。
Data ONTAP 8.2.xから8.2リリース ファミリーの V_StorageAttachライセンス パッケージをインス
それよりも前のリリースにダウングレードする場 トールする必要はありません。リリース ファミリ
合
ーに対応した適切なライセンスが保存されてい
ます。
ライセンスのインストール方法については、『clustered Data ONTAP システム アドミニストレーショ
ン ガイド（SVM管理）』を参照してください。
133
アップグレード実行中のサービスの可用性の最適化
Data ONTAPのアップグレード実行中のサービス可用性は、計画および構成によって最適化でき
ます。 状況によっては、クライアント上のサービスをまったく中断せずにアップグレードを実行でき
ます。
アップグレードがサービスの可用性に与える影響
アップグレード開始前にストレージ システム サービスの可用性に影響を与える可能性がある要因
を確認できます。
サービスの可用性に影響を与える要因は次のとおりです。
•
•
•
•
•
使用されているプロトコル、ライセンスされているサービスの種類、タイムアウト エラーによる影
響
Data ONTAPの問題および新機能に関する判断を異なるリリース ファミリー間で行うか、同一リ
リース ファミリー内で行うか
Data ONTAPリリース ファミリー間のアップグレードの方が、リリース ファミリー内のアップグレ
ードより手順が多く、停止回数が多くなる可能性があります。
システム ファームウェアの更新の必要性
システム ファームウェアの更新によっては、システムの停止およびリブートが必要です。 ダウ
ンタイムが予定されているアップグレードではサービスが中断される可能性がありますが、無
停止アップグレードではサービスに影響しません。
ディスク シェルフ ファームウェアの更新の必要性
ファームウェアの無停止アップグレードは、ディスク シェルフおよびモジュールの多くの構成で
利用できます。
使用中のアプリケーションの種類およびタイムアウト エラーによる影響
アップグレード実行中のクライアント アプリケーションの可用性は、機能、プロトコル、構成によ
って異なります。 詳細については、アプリケーションのマニュアルを参照してください。
注: ストレージ ソリューションでのハードウェアおよびソフトウェアのアップグレードにはすべて、
潜在的にストレージ システムのサービスを中断する何らかの要因が含まれています。 サービス
の可用性を最大限に保つには、アップグレードのオプションを慎重に検討し、最適な方法を判別
するようにしてください。
関連コンセプト
潜在的なアップグレードの問題の特定（22ページ）
ファームウェアの更新（70ページ）
ディスク シェルフ ファームウェアの更新（73ページ）
ディスク ファームウェアの更新（70ページ）
134 | アップグレードおよびリバート / ダウングレード ガイド
サービスおよびプロトコルの注意事項
一般に、NFS、FC、iSCSIなどのステートレス プロトコルに基づくサービスは、CIFSやNDMPなどの
セッション指向プロトコルに比べ、アップグレード実行中のサービス中断の影響を受けません。
アップグレードの実行中、新しいソフトウェアをロードするには、（HA構成のテイクオーバーおよび
ギブバックを開始して）クラスタ内の各ノードをリブートする必要があります。 通常、ステートレス プ
ロトコルに基づくサービスは、無停止アップグレード中も継続的に使用できます。
ステートレス プロトコルには通常、タイムアウト処理が含まれています。 たとえば、タイムアウト時
間内に、送信したメッセージに対する確認応答が得られない場合、転送エラーとみなされます。 ク
ラスタでは、クライアントのタイムアウト時間がクラスタの中断時間（リブートまたはHA構成のギブ
バックの所要時間など）より長い場合、クライアントはストレージ システムのサービスの中断を認識
しません。
セッション指向プロトコルには、サービスを中断から保護するタイムアウトの概念がありません。 セ
ッション指向のストレージ システムのサービスが中断されると、進行中の処理に関する状態情報
が失われるので、ユーザは処理を再起動する必要があります。
ステートレス プロトコルの考慮事項
クライアントが推奨ガイドラインに従って設定されている場合は、ステートレス プロトコルを使用す
るクライアント接続が設定に含まれていても、アップグレード中に悪影響を与えることは通常ありま
せん。
ステートレス プロトコルを使用する場合は、次のことを考慮してください。
•
NFSハード マウント
アップグレード中にクライアントへの悪影響はありません。 ストレージ システムがリブートする
まで、クライアントは次のようなメッセージを受け取る場合があります。
NFS server not responding, retrying
•
•
通常、読み取り / 書き込みディレクトリはハード マウントする必要があります。 ハード マウント
は、デフォルトのマウント タイプです。
NFSソフト マウント
ソフト マウントは使用しないでください（NFSタイムアウトが頻繁に発生する場合）。 タイムアウト
によって競合状態が発生し、データが破損する可能性があります。 さらに、アプリケーションに
よっては、ソフト マウントを使用してNFS処理がタイムアウトに達した場合に発生するエラーを
適切に処理できません。
HA構成における無停止アップグレード、テイクオーバー、ギブバックの発生時に頻繁にタイム
アウトが発生する可能性があります。
通常、ソフト マウントは、ディスクからの読み込みにのみ使用してください。使用する場合は、マ
ウントの信頼性が低いことに留意してください。
SANプロトコル
アップグレード実行中のサービスの可用性の最適化 | 135
推奨ガイドラインに従って設定されている場合、FCまたはiSCSIクライアントへの悪影響はあり
ません。
詳細については、ネットアップ サポート サイトのInteroperability Matrixを参照してください。
関連情報
互換性マトリックス：http://support.netapp.com/NOW/products/interoperability
セッション指向プロトコルの考慮事項
ストレージ システムおよびセッション指向プロトコルは、アップグレードの実行中、特定領域のクラ
イアントおよびアプリケーションに悪影響を及ぼす可能性があります。
セッション指向プロトコルを使用する場合は、次のことを考慮してください。
•
•
•
CIFS
クライアントのセッションを終了します。 アップグレードの開始前に、ユーザにセッションを終了
するように通知してください。
NDMP
状態が失われるので、クライアント ユーザは操作を再試行する必要があります。
バックアップおよびリストア
状態が失われるので、クライアント ユーザは操作を再試行する必要があります。
注意: アップグレードの実行中および開始直前は、バックアップまたはリストアの操作を開始
しないでください。 開始すると、データが失われることがあります。
•
アプリケーション（OracleまたはExchangeなど）
影響はアプリケーションによって異なります。 タイムアウト ベースのアプリケーションでは、タイ
ムアウトの値を変更し、Data ONTAPのリブート時間よりも長く設定することで、悪影響を最小限
に抑えることができます。
ディスク ファームウェアのバックグラウンド更新について
ストレージ システムがリブートし、新しいディスク ファームウェアがある場合には、該当ドライブが
自動的に順番にオフラインになるので、ストレージ システムは読み取りや書き込みの要求に正常
に対応できます。
オフライン状態のドライブに関連する要求があった場合、読み取り要求はRAIDグループ内の他の
ディスクからデータを再構築する方法で処理され、書き込み要求はログに書き込まれます。 ディス
ク ファームウェアの更新が完了すると、そのドライブはオフライン状態の間に発生した書き込み処
理の再同期化後、オンライン状態に戻ります。
ディスク ファームウェアのバックグラウンド更新中、ストレージ システムは正常に機能します。 ファ
ームウェア更新のためにディスクがオフライン状態になるとき、およびファームウェア更新が完了し
てディスクがオンライン状態に戻るときに、ステータス メッセージが表示されます。 ディスク ファー
ムウェアのバックグラウンド更新は、アクティブなデータ ディスクおよびスペア ディスクに対して連
136 | アップグレードおよびリバート / ダウングレード ガイド
続的に進行します。 ディスク ファームウェアの更新が連続して順番に実行されるので、二重ディス
ク障害時にもデータ損失は生じません。
オフライン状態のドライブは、ノードシェルのvol status -rコマンドの出力にofflineと表示され
ます。 オフライン状態のスペア ディスクは、ボリュームに追加、または再構築処理用の交換ドライ
ブとして選択はできません。 ただし、通常はディスクがオフライン状態になるのはごく短時間（長く
ても数分）なので、正常なシステム処理が中断されることはありません。
ディスク ファームウェアのバックグラウンド更新が完了しないのは、次の状況が発生した場合だけ
です。
•
•
ストレージ システム上にデグレード アグリゲートがある。
ファームウェア更新を必要とするディスクがオフライン状態のアグリゲートまたはプレックス内に
ある。
これらの状況が解決されると、ディスク ファームウェアの自動バックグラウンド更新が再開します。
アグリゲートのステータスおよび状態の判別に関する詳細は、『clustered Data ONTAP 物理ストレ
ージ管理ガイド』を参照してください。
137
著作権に関する情報
Copyright © 1994–2013 NetApp, Inc. All rights reserved. Printed in the U.S.
このドキュメントは著作権によって保護されています。著作権所有者の書面による事前承諾がある
場合を除き、画像媒体、電子媒体、および写真複写、記録媒体、テープ媒体、電子検索システム
への組み込みを含む機械媒体など、いかなる形式および方法による複製も禁止します。
ネットアップの著作物から派生したソフトウェアは、次に示す使用許諾条項および免責条項の対象
となります。
このソフトウェアは、ネットアップによって「現状のまま」提供されています。明示的な保証、または
商品性および特定目的に対する適合性の暗示的保証を含み、かつこれに限定されないいかなる
暗示的な保証も行ないません。 ネットアップは、代替品または代替サービスの調達、使用不能、デ
ータ損失、利益損失、業務中断を含み、かつこれに限定されない、このソフトウェアの使用により
生じたすべての直接的損害、間接的損害、偶発的損害、特別損害、懲罰的損害、必然的損害の
発生に対して、損失の発生の可能性が通知されていたとしても、その発生理由、根拠とする責任
論、契約の有無、厳格責任、不法行為（過失またはそうでない場合を含む）にかかわらず、一切の
責任を負いません。
ネットアップは、ここに記載されているすべての製品に対する変更を随時、予告なく行う権利を保
有します。 ネットアップによる明示的な書面による合意がある場合を除き、ここに記載されている
製品の使用により生じる責任および義務に対して、ネットアップは責任を負いません。 この製品の
使用または購入は、ネットアップの特許権、商標権、または他の知的所有権に基づくライセンスの
供与とはみなされません。
このマニュアルに記載されている製品は、1つ以上の米国特許、その他の国の特許、および出願
中の特許によって保護されている場合があります。
権利の制限について：政府による使用、複製、開示は、DFARS 252.227-7103（1988年10月）およ
びFAR 52-227-19（1987年6月）のRights in Technical Data and Computer Software（技術データおよ
びコンピュータソフトウェアに関する諸権利）条項の(c) (1) (ii)項に規定された制限が適宜適用され
ます。
138 | アップグレードおよびリバート / ダウングレード ガイド
商標に関する情報
NetApp、NetAppのロゴ、Network Appliance、Network Applianceのロゴ、Akorri、
ApplianceWatch、ASUP、AutoSupport、BalancePoint、BalancePoint Predictor、Bycast、Campaign
Express、ComplianceClock、Cryptainer、CryptoShred、CyberSnap、Data Center Fitness、Data
ONTAP、DataFabric、DataFort、Decru、Decru DataFort、DenseStak、Engenio、Engenioのロゴ、EStack、ExpressPod、FAServer、FastStak、FilerView、Flash Accel、Flash Cache、Flash Pool、
FlashRay、FlexCache、FlexClone、FlexPod、FlexScale、FlexShare、FlexSuite、FlexVol、FPolicy、
GetSuccessful、gFiler、Go further, faster、Imagine Virtually Anything、Lifetime Key Management、
LockVault、Mars、Manage ONTAP、MetroCluster、MultiStore、NearStore、NetCache、NOW
（NetApp on the Web）、Onaro、OnCommand、ONTAPI、OpenKey、PerformanceStak、RAID-DP、
ReplicatorX、SANscreen、SANshare、SANtricity、SecureAdmin、SecureShare、Select、Service
Builder、Shadow Tape、Simplicity、Simulate ONTAP、SnapCopy、Snap Creator、SnapDirector、
SnapDrive、SnapFilter、SnapIntegrator、SnapLock、SnapManager、SnapMigrator、SnapMirror、
SnapMover、SnapProtect、SnapRestore、Snapshot、SnapSuite、SnapValidator、SnapVault、
StorageGRID、StoreVault、StoreVaultのロゴ、SyncMirror、Tech OnTap、The evolution of storage、
Topio、VelocityStak、vFiler、VFM、Virtual File Manager、VPolicy、WAFL、Web Filer、および
XBBは、米国、その他の国、またはその両方におけるNetApp, Inc.の商標または登録商標です。
IBM、IBMロゴ、およびibm.comは、米国、その他の国、またはその両方におけるInternational
Business Machines Corporationの登録商標です。 IBMの商標の完全および最新のリストは、Web
サイトwww.ibm.com/legal/copytrade.shtmlでご覧いただけます。
Appleは、米国、その他の国、またはその両方におけるApple Computer, Inc.の登録商標です。
QuickTimeは、米国、その他の国、またはその両方におけるApple Computer, Inc.の商標です。
Microsoftは、米国、その他の国、またはその両方におけるMicrosoft Corporationの登録商標で
す。Windows Mediaは、米国、その他の国、またはその両方におけるMicrosoft Corporationの商標
です。 RealAudio、RealNetworks、RealPlayer、RealSystem、RealText、RealVideoは、米国、その他
の国、またはその両方におけるRealNetworks, Inc.の登録商標です。RealMedia、RealProxy、
SureStreamは、米国、その他の国、またはその両方におけるRealNetworks, Inc.の商標です。
その他のすべてのブランドおよび製品は、それを所有する各社の商標または登録商標であり、相
応の取り扱いが必要です。
Network Applianceは、CompactFlashおよびCFロゴの両商標に対する使用許諾を有しています。
NetApp, Inc. NetCacheは、RealSystemの認定互換製品です。
139
ご意見をお寄せください
弊社では、マニュアルの品質を向上していくため、皆様からのフィードバックをお待ちしています。
いただいたフィードバックは、今後のマニュアル作成に役立てさせていただきます。 ご意見やご要
望は、[email protected] までお寄せください。 その際、担当部署で適切に対応
させていただくため、製品名、バージョン、オペレーティング システムなどの基本情報を必ず入れ
てください。
郵送の場合の宛先は、次のとおりです。
•
•
•
•
〒105-0001　東京都港区虎ノ門4丁目1番8号　虎ノ門4丁目MTビル
ネットアップ株式会社
注：弊社営業担当者名を記載してください
140 | アップグレードおよびリバート / ダウングレード ガイド
索引
A
I
ACPファームウェア
更新 75
Alternate Control Path
次を参照 : ACP
AutoSupport
使用している古いディスク ファームウェアの検出 72
Infinite Volume
アップグレード後のネームスペース ミラー コンステ
ィチュエントの作成 64
アップグレード時の注意事項 20
削除 92
iSNS
リバートの準備 96
C
CIFS
アップグレード中の中断の回避 135
クライアント アクセスの確認 106, 130
CPU利用率
アップグレード要件 16
L
LIF
Remote Support Agentのセットアップ 66
自動リバランシングの無効化 31
自動リバランシングの有効化 68
フェイルオーバーの設定の確認 30
有効かとホーム ポートへのリバート 28, 62, 104,
114, 129
D
Data ONTAP
8.2の潜在的なアップグレードの問題 22
SnapMirror環境での無停止アップグレード 38, 121
アップグレード プロセスの概要 7
以前のリリース ファミリーへのリバート, 概要 77
Data ONTAP 8.2リリース ファミリー
動作の変更 24
Data ONTAPシステム ファイル
HTTPサーバへのソフトウェア イメージのコピー 34,
98, 119
Data ONTAPソフトウェア イメージ
イメージの格納と切り替えの仕組み 36
取得 34, 98, 119
リバートする場合に必要な準備作業 83
Disk Qualification Package
更新が必要なタイミング 71
DQP
次を参照 : Disk Qualification Package
F
Flash Cache
ファームウェアの更新について 76
FlexVol
アップグレード要件 16
N
NDMP
アップグレード中の中断の回避 135
NDU
次を参照 : 無停止アップグレード
NFS
アップグレードのプロトコル考慮事項 134
クライアント アクセスの確認 106, 130
P
PAM
ファームウェアの更新について 76
Performance Acceleration Module
次を参照 : PAM
Perfstat
パフォーマンスのベースラインの作成, アップグレー
ド前 25
R
RDBクォーラム
索引 | 141
リバートまたはダウングレード前のクラスタのステ
ータスの確認 94, 116
Remote LAN Module
次を参照 : RLM
Remote Support Agent
アップグレード後のクラスタ管理LIFの設定 66
RLM
ファームウェアの更新について 76
RSA
次を参照 : Remote Support Agent
RSAのセットアップ コマンド
Remote Support Agentのセットアップ 66
S
SAN
アップグレードのプロトコル考慮事項 134
Simple Network Management Protocol
次を参照 : SNMP
SnapMirror環境
NDU実行後の処理の再開 66, 131
アップグレードの要件 21
無停止アップグレード 38, 121
Snapshotコピー
アップグレード要件 16
リバート後の準備 106
リバート前の準備 97
リバート前のデータが圧縮されたコピーの削除 91
SPファームウェア
更新について 75
ダウングレードに関する注意事項 107, 131
SVM
Infinite Volumeの削除 92
健全性の確認 27, 61, 93, 103, 113, 128
SVMの健全性
検証 27, 61, 93, 103, 113, 128
system node image modifyコマンド
デフォルト ブート イメージの変更 124
system node image showコマンド
ソフトウェアのバージョンの確認 34, 119
デフォルト ブート イメージの表示 124
system node revert-toコマンド
Data ONTAPのリバート 77
U
Upgrade Advisorツール
アップグレードの計画 8
V
vsadminロール
リバート処理後の有効化
有効化
リバート処理後のvsadminロール 108
Vシリーズ システム
ダウングレードする際の前提条件 112
ダウングレード前のエラーの確認 118
あ
アグリゲート
ステータスの確認 27, 61, 93, 103, 113, 128
圧縮されたボリューム
リバート要件 91
アップグレード
Data ONTAP 8.2の動作の変更点 24
Data ONTAP 8.2リリース ファミリーの潜在的な問
題 22
Data ONTAPソフトウェア イメージの取得 34, 98,
119
Infinite Volumeのネームスペース ミラー コンスティ
チュエントの作成 64
LIFの有効化とホーム ポートへのリバート, 実行前
と実行後 28, 62, 104, 114, 129
SnapMirror環境, 無停止手順 38, 121
SnapMirrorの要件 21
Upgrade Advisorを使用した計画 8
期間の見積もり 20
クラスタがRDBクォーラムにあることの事前の検証
26
クラスタの準備が完了していることの確認 40
計画 9
サービス中断の回避 134
サービスの可用性に与える影響 133
サービスの可用性の維持について 133
システム ファームウェア, 概要 70
実行プロセス 40
実行前のパフォーマンスのベースラインの作成 25
種類 10
ステートレス プロトコルの考慮事項 134
セッション指向プロトコルの考慮事項 135
潜在的な問題の評価 22
ソフトウェアのバージョンの確認 34
チェックリスト 10
停止を伴う手順 59
ディスク シェルフ ファームウェアの更新方法 73
142 | アップグレードおよびリバート / ダウングレード ガイド
ディスク ファームウェアの更新方法 70
ノードのアップグレード順序 18
プロセスの概要 7
アップグレード後の手順
チェックリスト 10
アップグレードの実行
チェックリスト 10
プロセス 40
アップグレードの準備手順
チェックリスト 10
い
以前のリリースにリバートする
要件の概要 78
以前のリリースへのダウングレード
Vシリーズのライセンス要件 107, 132
以前のリリースへのリバート
Infinite Volumeの削除 92
Vシリーズのライセンス要件 107, 132
圧縮されたボリューム 91
サポートするシナリオ 77
実行後のSnapshotコピーの準備 106
実行前のiSNSの準備 96
実行前のSnapshotコピーの準備 97
実行前のクラスタがRDBクォーラムにあることの確
認 94, 116
チェックリスト 78
重複排除されたボリューム 90
テクニカル サポートへの連絡のタイミング 77
バックアップ ヴォールト関係の削除 85
必要な準備作業 83
本番用システムの場合の準備 83
ミラー関係の削除 83
問題の特定 81, 82
リバート後の手順 103
イメージ
次を参照 : ソフトウェア イメージ
え
エラー
ダウングレード前の確認 118
か
概要
アップグレード プロセス 7
同じリリース ファミリーの以前のリリースへのダウ
ングレード 109
仮想サーバ
次を参照 : SVM
関係
バックアップ ヴォールトの削除, リバート前 85
ミラーの削除, リバート前 83
き
ギブバック
ダウングレード時に開始 124
基本入出力
次を参照 : BIOS
共通インターネット ファイルシステム
次を参照 : CIFS
く
クォーラム
クラスタの状態の検証 26
リバートまたはダウングレード前のクラスタのステ
ータスの確認 94, 116
クラスタ
CIFSおよびNFSのクライアント アクセスの確認 106,
130
I/Oなしでリバート 100
アップグレード
計画 9
チェックリスト 10
プロセス 40
プロセスの概要 7
要件 16
アップグレードまたはダウングレード前の実行中の
ジョブがないことの確認 39, 123
以前のリリースへのリバート
必要な準備作業 83
イメージの格納と切り替えの仕組み 36
クラスタがRDBクォーラムにあることの検証 26
健全性の確認 27, 61, 93, 103, 113, 128
システム時間が同期されていることの検証 32, 95,
117
ステータスの確認 10
ソフトウェア イメージのインストール 35, 99, 120
ダウングレード
同じリリース ファミリーの以前のリリース, 概要
109
ダウングレード後の手順の実行 128
索引 | 143
チェックリスト 110
問題 112
ダウングレード時にデフォルト ブート イメージを変
更 124
停止を伴うアップグレード 59
リバート
以前のリリース ファミリーへのリバート, 概要
77
チェックリスト 78
問題および制限事項 81
リバート後の手順の完了 103
リバートまたはダウングレード前のステータスの確
認 94, 116
クラスタ管理LIF
RSAの設定 66
クラスタの健全性
検証 27, 61, 93, 103, 113, 128
クラスタ レプリケーション リング
クラスタがRDBクォーラムにあることの検証 26
け
計画
Upgrade Advisorを使用したアップグレード 8
アップグレード 9
ダウングレードの要件 109
リバート 78
異なるバージョンの混在
アップグレード要件 16
コマンド
RSAのセットアップ 66
system node image modify 124
system node image show
アップグレード前のソフトウェアのバージョンの
確認 34
ダウングレード前のソフトウェアのバージョン
の確認 119
system node revert-to 77
さ
サービスの可用性
アップグレード中の最適化について 133
アップグレード中の中断の回避 134
アップグレードの影響 133
ディスク ファームウェア更新中 72
サービス プロセッサ
次を参照 : SPファームウェア
削除
Infinite Volumeを備えたSVM 92
サポート
ダウングレード時の連絡のタイミング 109
リバート時の連絡のタイミング 77
し
検証
RDBクォーラムにあるクラスタ 26
リバートまたはダウングレード前のクラスタがクォー
ラムにあることの確認 94, 116
こ
更新
Flash Cacheファームウェア, 概要 76
RLMファームウェアの概要 76
SPファームウェア, 概要 75
システム ファームウェア, 概要 70
ディスク シェルフ ファームウェア, 概要 73
ディスク ファームウェア, 概要 70
ディスク ファームウェアの更新方法 70
ディスク ファームウェア更新中のサービスの可用
性 72
バックグラウンド ディスク ファームウェアの概要
135
構成
バックエンドのエラー 118
シェルフ
ファームウェアの更新方法 73
古いファームウェアの検出 74
システム サービス
リバート後の確認 103
システム時間
検証 32, 95, 117
システム ファームウェア
自動インストール, 概要 70
システム ファイル, Data ONTAP
ソフトウェア イメージのコピー 34, 98, 119
取得
Data ONTAPソフトウェア イメージ 34, 98, 119
準備
リバートする場合に必要な作業 83
ジョブ
アップグレードまたはダウングレード前のステータ
スの確認 39, 123
144 | アップグレードおよびリバート / ダウングレード ガイド
す
ステートレス プロトコル
アップグレード中のサービス中断の回避 134
ストレージ エリア ネットワーク
次を参照 : SAN
ストレージ システム
ミラー環境の無停止アップグレード 38, 121
せ
制限事項
ダウングレードする 112
リバート 81
セッション指向プロトコル
アップグレード中のサービス中断の回避 135
そ
ソフトウェア イメージ
イメージの格納と切り替えの仕組み 36
インストール 35, 99, 120
コピー 34, 98, 119
リバートする場合に必要な準備作業 83
ソフトウェアのバージョン
アップグレード前の確認 34
ダウングレード前の確認 119
た
代替イメージ
ブート可能 36
ダウングレード
Infinite Volumeの削除 92
LIFの有効化とホーム ポートへのリバート, 実行前
と実行後 28, 62, 104, 114, 129
Vシリーズ システムの場合の前提条件 112
概要, 同じリリース ファミリーの以前のリリース 109
計画の要件 109
実行前のクラスタがRDBクォーラムにあることの確
認 94, 116
ソフトウェアのバージョンの確認 119
ダウングレード後の手順の実行 128
ダウングレードの問題 112
ダウングレード前のバックエンド構成のエラーの確
認 118
チェックリスト 110
テクニカル サポートへの連絡のタイミング 109
デフォルト ブート イメージの変更 124
ダウングレード後の手順
完了 128
チェックリスト 110
ダウングレードの準備手順
チェックリスト 110
ダンプ処理
アップグレードまたはダウングレード前のジョブのス
テータスの確認 39, 123
ち
チェックリスト
アップグレード 10
ダウングレードする 110
リバート 78
注意事項
SPファームウェアのダウングレード 107, 131
重複排除されたボリューム
システムのリバート 90
て
停止を伴うアップグレード
Infinite Volume, 注意事項 20
クラスタの準備が完了していることの確認 40
定義 10
手順 59
ディスク
Disk Qualification Packageの更新が必要なタイミン
グ 71
アップグレード中のファームウェアの更新方法 70
ファームウェア更新中のサービスの可用性 72
ファームウェアの更新について 70
ファームウェアのバックグラウンド更新の概要 135
古いファームウェアの検出 72
ディスク シェルフ
ACPの更新 75
ファームウェアの更新, 概要 73
ファームウェアの更新について 70
ファームウェアの更新方法 73
古いファームウェアの検出 74
ディスク シェルフ ファームウェアの更新
概要 73
ディスク ファームウェア
更新中のサービスの可用性 72
更新について 70
バックグラウンド更新の概要 135
索引 | 145
古いかどうかを検出, AutoSupportの使用 72
ディスク利用率
アップグレード要件 16
データ保護ミラー関係
アップグレード後の更新に関する注意事項 20
リバート前の削除 83
テクニカル サポート
ダウングレード時の連絡のタイミング 109
リバート時の連絡のタイミング 77
デフォルト ブート イメージ
アップグレード前の確認 10
ダウングレード時に変更 124
と
トラブルシューティング
ホーム ポートへのLIFのリバート 28, 62, 104, 114,
129
ね
ネームスペース ミラー コンスティチュエント
アップグレード後にInfinite Volume用に作成 64
アップグレード後の作成に関する注意事項 20
ネットアップ サポート サイト
Data ONTAPソフトウェア イメージの取得 34, 98,
119
ネットワークデータ管理プロトコル
次を参照 : NDMP
ネットワーク ファイルシステム
次を参照 : NFS
の
ノード
RDBクォーラムへの参加の検証 26
アップグレード順序 18
ソフトウェアのバージョンの確認 34, 119
リバートまたはダウングレード前のステータスの確
認 94, 116
は
バージョン
現在のソフトウェアについての確認 119
ノードの現在のソフトウェアについての確認 34
古いディスク シェルフ ファームウェアの検出 74
古いディスク ファームウェアの検出 72
バックアップ ヴォールト関係
リバート前の削除 85
バックエンド構成
ダウングレード前のエラーの確認 118
バックグラウンド ディスク
ファームウェア更新の概要 135
バッチ アップグレード
2つ目のノード セットのアップグレード 54
アップグレード
バッチ方式での2つ目のノード セットのアップ
グレード 54
バッチ方式での最初のノード セットのアップグ
レード 51
バッチ方式を使用した場合のバッチについて
の確認 58
完了の確認 58
クラスタの準備が完了していることの確認 40
最初のノード セットのアップグレード 51
実行後のLIFの自動リバランシングの有効化 68
実行前のLIFの自動リバランシングの無効化 31
定義 10
プロセス 50
パフォーマンスのベースライン
アップグレード前のPerfstatを使用した設定 25
ふ
ファームウェア
Flash Cacheの更新について 76
PAMの更新について 76
RLM, 更新 76
SPのダウングレードに関する注意事項 107, 131
システムの更新, 概要 70
ディスク, 更新方法 70
ディスク, シェルフ, およびシステムの更新について
70
ディスク シェルフ, 更新プロセスの概要 73
ディスクの更新について 70
古いかどうかを検出, ディスク シェルフ 74
古いディスクの検出, AutoSupportの使用 72
ファームウェアの更新
ACP 75
SPについて 75
ディスク更新中のサービスの可用性 72
ディスク シェルフ, 概要 73
バックグラウンド ディスクの概要 135
ファイル転送プロトコル
次を参照 : FTP
146 | アップグレードおよびリバート / ダウングレード ガイド
ブート イメージ
アップグレード前の確認 10
ダウングレード時に変更 124
フェイルオーバー
ダウングレード時に開始 124
負荷共有ミラー関係
リバート前の削除 83
古いファームウェア
検出, ディスク 72
検出, ディスク シェルフ 74
プロトコル
アップグレード中の中断の回避 134
ステートレスのアップグレード考慮事項 134
セッション指向の考慮事項 135
ディスク シェルフ ファームウェア, 概要 73
ノードのアップグレード順序 18
バッチ方式 50
方法 10
ローリング アップグレード方式 42
無停止メジャー アップグレード
ディスク シェルフ ファームウェアの更新要件 73
も
ベースボード管理コントローラ
次を参照 : BMC
モジュール ファームウェア
SPの更新, 概要 75
ディスク シェルフ, 更新プロセスの概要 73
問題
Data ONTAP 8.2リリース ファミリーの潜在的なアッ
プグレードの問題 22
潜在的なアップグレードの評価 22
ダウングレード 112
リバート 81, 82
ほ
よ
ボリューム
アップグレードまたはダウングレード前のボリュー
ムのステータスの確認 39, 123
ステータスの確認 27, 61, 93, 103, 113, 128
本番用システム
リバートの準備 83
要件
へ
CPUとディスクの利用率 16
SnapMirrorのアップグレード 21
Snapshotコピー 16
アップグレードまたはダウングレード前のジョブのス
テータスの確認 39, 123
ダウングレードの計画 109
み
ミラー関係
リバート前の削除 83
ミラーリング
次を参照 : SnapMirror環境
ら
ライセンス
Vシリーズに関するダウングレード時の要件 107,
132
Vシリーズに関するリバート時の要件 107, 132
む
無停止アップグレード
Flash Cacheファームウェア更新の仕組み 76
Infinite Volume, 注意事項 20
SnapMirror環境, 手順 38, 121
期間の見積もり 20
クラスタの準備が完了していることの確認 40
サービス中断の回避 134
サービスの可用性の最適化について 133
実行後のSnapMirror処理の再開 66, 131
定義 10
り
リストア処理
アップグレードまたはダウングレード前のジョブのス
テータスの確認 39, 123
リバート
I/Oなし, 手順 100
LIFの有効化とホーム ポートへのリバート, 実行後
28, 62, 104, 114, 129
リバート後の手順
完了 103
索引 | 147
チェックリスト 78
リバートの準備手順
チェックリスト 78
リバートの問題
注意事項 81
特定 82
バックアップ ヴォールト関係の削除 85
負荷共有ミラー関係とデータ保護ミラー関係の削除
83
リリース ファミリー
Data ONTAP 8.2の動作の変更点 24
アップグレードがサービスの可用性に与える影響
133
潜在的なアップグレードの問題の評価 22
れ
レプリケーション リング
クラスタがRDBクォーラムにあることの検証 26
レプリケートされたデータベース クォーラム
次を参照 : RDBクォーラム
ろ
ローリング アップグレード
2つ目のノードのアップグレード 46
HAペアについての確認 49
アップグレード
ローリング方式での2つ目のノードのアップグ
レード 46
ローリング方式での最初のノードのアップグレ
ード 43
ローリング方式の場合の完了の確認 60
ローリング方式を使用した場合のHAペアにつ
いての確認 49
完了の確認 60
クラスタの準備が完了していることの確認 40
最初のノードのアップグレード 43
定義 10
プロセス 42
論理インターフェイス
次を参照 : LIF