CLIを使用した4ノードまたは8ノードMetroCluster構成の手動による無停止ONTAPアップグレード
変更を提案
PDF
4ノードまたは8ノードMetroCluster構成の手動アップグレードでは、更新の準備を行い、1つまたは2つのDRグループのそれぞれのDRペアを同時に更新し、アップグレード後の手順を実行します。
-
この作業は、次の構成に適用されます。
-
ONTAP 9.2 以前を実行している 4 ノード MetroCluster FC 構成または IP 構成
-
ONTAP のバージョンに関係なく、 8 ノードの MetroCluster FC 構成
-
-
2ノードMetroCluster構成の場合は、この手順を使用しないでください。
-
次のタスクでは、ONTAPの古いバージョンと新しいバージョンを参照しています。
-
アップグレードの場合、古いバージョンは ONTAP の以前のバージョンで、 ONTAP の新しいバージョンよりも下位のバージョン番号が割り当てられます。
-
ダウングレード手順での古いバージョンとは、 ONTAP の新しいバージョン、つまり ONTAP の新しいバージョンのバージョン番号よりも上位の番号を持つバージョンを指します。
-
-
このタスクのワークフローの概要は次のとおりです。
8ノードまたは4ノードのMetroCluster構成でONTAPソフトウェアを更新する場合の相違点
MetroClusterソフトウェアのアップグレードプロセスは、MetroCluster構成に8ノードと4ノードのどちらが含まれているかによって異なります。
MetroCluster構成は、1つまたは2つのDRグループで構成されます。各DRグループは、2つのHAペアで構成されます（各MetroClusterクラスタに1つのHAペア）。8ノードMetroClusterには、次の2つのDRグループが含まれます。
DRグループは一度に1つずつアップグレードします。
-
DRグループ1をアップグレードします。
-
node_A_1とnode_B_1をアップグレードします。
-
node_A_2とnode_B_2をアップグレードします。
-
-
DRグループ1をアップグレードします。
-
node_A_1とnode_B_1をアップグレードします。
-
node_A_2とnode_B_2をアップグレードします。
-
-
DRグループ2をアップグレードします。
-
node_A_3とnode_B_3をアップグレードします。
-
node_A_4とnode_B_4をアップグレードします。
-
MetroCluster DRグループのアップグレード準備
ノード上のONTAPソフトウェアをアップグレードする前に、ノード間のDR関係を特定して、アップグレードを開始することを知らせるAutoSupportメッセージを送信します。また、各ノードで実行中のONTAPのバージョンを確認します。
ソフトウェアイメージと"インストール済み"ソフトウェアイメージが必要"ダウンロードしました"です。
このタスクは、DRグループごとに実行する必要があります。MetroCluster構成が8つのノードで構成されている場合は、DRグループが2つあります。そのため、このタスクをDRグループごとに繰り返す必要があります。
このタスクの例では、次の図に示す名前を使用してクラスタとノードを識別しています。
-
構成内のDRペアを特定します。
metrocluster node show -fields dr-partnercluster_A::> metrocluster node show -fields dr-partner (metrocluster node show) dr-group-id cluster node dr-partner ----------- ------- -------- ---------- 1 cluster_A node_A_1 node_B_1 1 cluster_A node_A_2 node_B_2 1 cluster_B node_B_1 node_A_1 1 cluster_B node_B_2 node_A_2 4 entries were displayed. cluster_A::>
-
権限レベルをadminからadvancedに設定します。続行するかどうかを尋ねられたら、「* y *」と入力します。
set -privilege advancedadvancedプロンプト(`*>`が表示されます）。
-
cluster_AのONTAPバージョンを確認します。
system image showcluster_A::*> system image show Is Is Install Node Image Default Current Version Date -------- ------- ------- ------- ------- ------------------- node_A_1 image1 true true X.X.X MM/DD/YYYY TIME image2 false false Y.Y.Y MM/DD/YYYY TIME node_A_2 image1 true true X.X.X MM/DD/YYYY TIME image2 false false Y.Y.Y MM/DD/YYYY TIME 4 entries were displayed. cluster_A::> -
cluster_Bのバージョンを確認します。
system image showcluster_B::*> system image show Is Is Install Node Image Default Current Version Date -------- ------- ------- ------- ------- ------------------- node_B_1 image1 true true X.X.X MM/DD/YYYY TIME image2 false false Y.Y.Y MM/DD/YYYY TIME node_B_2 image1 true true X.X.X MM/DD/YYYY TIME image2 false false Y.Y.Y MM/DD/YYYY TIME 4 entries were displayed. cluster_B::> -
AutoSupport通知を送信します。
autosupport invoke -node * -type all -message "Starting_NDU"このAutoSupport通知には、アップグレード前のシステムステータスの記録が含まれます。アップグレードプロセスで問題が発生した場合に役立つトラブルシューティング情報が保存されます。
AutoSupportメッセージを送信するようにクラスタが設定されていない場合は、通知のコピーがローカルに保存されます。
-
最初のセットに含まれる各ノードについて、ターゲットのONTAPソフトウェアイメージをデフォルトのイメージとして設定します。
system image modify {-node nodename -iscurrent false} -isdefault trueこのコマンドは、拡張クエリを使用して、代替イメージとしてインストールされるターゲットのソフトウェアイメージがノードのデフォルトのイメージになるように変更します。
-
ターゲットのONTAPソフトウェアイメージがcluster_Aでデフォルトのイメージとして設定されたことを確認します。
system image show次の例では、image2が新しいONTAPバージョンで、最初のセットに含まれる各ノードでデフォルトのイメージとして設定されています。
cluster_A::*> system image show Is Is Install Node Image Default Current Version Date -------- ------- ------- ------- ------- ------------------- node_A_1 image1 false true X.X.X MM/DD/YYYY TIME image2 true false Y.Y.Y MM/DD/YYYY TIME node_A_2 image1 false true X.X.X MM/DD/YYYY TIME image2 true false Y.Y.Y MM/DD/YYYY TIME 2 entries were displayed.-
ターゲットのONTAPソフトウェアイメージがcluster_Bでデフォルトのイメージとして設定されたことを確認します。
system image show次の例では、最初のセットに含まれる各ノードで、ターゲットのバージョンがデフォルトのイメージとして設定されています。
cluster_B::*> system image show Is Is Install Node Image Default Current Version Date -------- ------- ------- ------- ------- ------------------- node_A_1 image1 false true X.X.X MM/DD/YYYY TIME image2 true false Y.Y.Y MM/YY/YYYY TIME node_A_2 image1 false true X.X.X MM/DD/YYYY TIME image2 true false Y.Y.Y MM/DD/YYYY TIME 2 entries were displayed. -
-
各ノードに対して次のコマンドを2回実行して、アップグレード対象のノードが現在クライアントに対して処理を行っているかどうかを確認します。
system node run -node target-node -command uptimeuptimeコマンドでは、ノードの前回のブート以降にNFS、CIFS、FC、iSCSIの各クライアントに対してノードが実行した処理の総数が表示されます。各プロトコルについてコマンドを2回実行して、処理数が増加しているかどうかを確認する必要があります。増加している場合は、そのプロトコルのクライアントに対してノードが現在処理を行っています。増加していない場合は、そのプロトコルのクライアントに対してノードは現在処理を行っていません。
ノードのアップグレード後にクライアント トラフィックが再開したことを確認できるように、クライアントの処理数が増加している各プロトコルを書き留めておいてください。 次の例は、NFS、CIFS、FC、およびiSCSIの処理が含まれるノードを示しています。ただし、ノードは現在NFSクライアントとiSCSIクライアントに対してのみ処理を行っています。
cluster_x::> system node run -node node0 -command uptime 2:58pm up 7 days, 19:16 800000260 NFS ops, 1017333 CIFS ops, 0 HTTP ops, 40395 FCP ops, 32810 iSCSI ops cluster_x::> system node run -node node0 -command uptime 2:58pm up 7 days, 19:17 800001573 NFS ops, 1017333 CIFS ops, 0 HTTP ops, 40395 FCP ops, 32815 iSCSI ops
MetroCluster DRグループ内の最初のDRペアの更新
ONTAPの新しいバージョンをノードの現在のバージョンにするには、ノードのテイクオーバーとギブバックを適切な順序で行う必要があります。
すべてのノードで古いバージョンのONTAPを実行する必要があります。
この手順では、node_A_1とnode_B_1をアップグレードします。
最初のDRグループのONTAPソフトウェアをアップグレード済みで、8ノードMetroCluster構成内の2つ目のDRグループをアップグレードする場合は、この手順でnode_A_3とnode_B_3を更新します。
-
MetroCluster Tiebreakerソフトウェアが有効になっている場合は、無効にします。
-
HAペアの各ノードで自動ギブバックを無効にします。
storage failover modify -node target-node -auto-giveback falseこのコマンドはHAペアのノードごとに実行する必要があります。
-
自動ギブバックが無効になっていることを確認します。
storage failover show -fields auto-giveback次の例は、両方のノードで自動ギブバックが無効になっていることを示しています。
cluster_x::> storage failover show -fields auto-giveback node auto-giveback -------- ------------- node_x_1 false node_x_2 false 2 entries were displayed.
-
各コントローラのI/Oが50%を超えていないこと、およびCPU利用率がコントローラあたり50%を超えていないことを確認してください。
-
cluster_Aのターゲットノードのテイクオーバーを開始します。
テイクオーバーされたノードを新しいソフトウェアイメージでブートするには通常のテイクオーバーが必要なため、-option immediateパラメータは指定しないでください。
-
cluster_A（node_A_1）のDRパートナーをテイクオーバーします。
storage failover takeover -ofnode node_A_1ノードがブートし、「Waiting for giveback」状態になります。
AutoSupportが有効な場合は、ノードがクラスタ クォーラムのメンバーでないことを示すAutoSupportメッセージが送信されます。この通知を無視し、アップグレードを続行してかまいません。 -
テイクオーバーが正常に完了したことを確認します。
storage failover show次の例は、テイクオーバーが正常に完了したことを示しています。node_A_1の状態は「Waiting for giveback」、node_A_2の状態は「In takeover」になっています。
cluster1::> storage failover show Takeover Node Partner Possible State Description -------------- -------------- -------- ------------------------------------- node_A_1 node_A_2 - Waiting for giveback (HA mailboxes) node_A_2 node_A_1 false In takeover 2 entries were displayed. -
-
cluster_B（node_B_1）のDRパートナーをテイクオーバーします。
テイクオーバーされたノードを新しいソフトウェアイメージでブートするには通常のテイクオーバーが必要なため、-option immediateパラメータは指定しないでください。
-
node_B_1をテイクオーバーします。
storage failover takeover -ofnode node_B_1ノードがブートし、「Waiting for giveback」状態になります。
AutoSupportが有効な場合は、ノードがクラスタ クォーラムのメンバーでないことを示すAutoSupportメッセージが送信されます。この通知を無視し、アップグレードを続行してかまいません。 -
テイクオーバーが正常に完了したことを確認します。
storage failover show次の例は、テイクオーバーが正常に完了したことを示しています。node_B_1の状態は「Waiting for giveback」、node_B_2の状態は「In takeover」になっています。
cluster1::> storage failover show Takeover Node Partner Possible State Description -------------- -------------- -------- ------------------------------------- node_B_1 node_B_2 - Waiting for giveback (HA mailboxes) node_B_2 node_B_1 false In takeover 2 entries were displayed. -
-
8分以上待ってから、次の条件を満たしていることを確認します。
-
クライアントのマルチパス（導入している場合）が安定している。
-
クライアントがテイクオーバー中に発生したI/Oの中断から回復している。
回復までの時間はクライアントによって異なり、クライアント アプリケーションの特性によっては8分以上かかることもあります。
-
-
アグリゲートをターゲット ノードに戻します。
MetroCluster IP構成をONTAP 9.5以降にアップグレードすると、アグリゲートの状態は短時間degradedになったあとに再同期されてmirroredに戻ります。
-
アグリゲートをcluster_AのDRパートナーにギブバックします。
storage failover giveback -ofnode node_A_1 -
アグリゲートをcluster_BのDRパートナーにギブバックします。
storage failover giveback -ofnode node_B_1ギブバック処理では、最初にルート アグリゲートがノードに戻され、そのノードのブートが完了するとルート以外のアグリゲートが戻されます。
-
-
両方のクラスタで次のコマンドを実行して、すべてのアグリゲートが戻されたことを確認します。
storage failover show-givebackGiveback Statusフィールドにギブバックするアグリゲートがないことが示されている場合は、すべてのアグリゲートが戻されています。ギブバックが拒否された場合は、コマンドによってギブバックの進捗が表示され、拒否したサブシステムも表示されます。
-
戻されていないアグリゲートがある場合は、次の操作を実行します。
-
拒否された回避策を確認して、「 ve to 」状態に対処するか、拒否を無視するかを決定します。
-
必要に応じて、エラーメッセージに記載されている「宛」の状態に対処し、特定された処理が正常に終了するようにします。
-
storage failover givebackコマンドを再度入力します。
「 "" ～ "" 」条件をオーバーライドする場合は、 -override-vetoes パラメータを true に設定します。
-
-
8分以上待ってから、次の条件を満たしていることを確認します。
-
クライアントのマルチパス（導入している場合）が安定している。
-
クライアントがギブバック中に発生したI/Oの中断から回復している。
回復までの時間はクライアントによって異なり、クライアント アプリケーションの特性によっては8分以上かかることもあります。
-
-
権限レベルをadminからadvancedに設定します。続行するかどうかを尋ねられたら、「* y *」と入力します。
set -privilege advancedadvancedプロンプト(`*>`が表示されます）。
-
cluster_Aのバージョンを確認します。
system image show次の例は、System image2がnode_A_1のデフォルトおよび現在のバージョンであることを示しています。
cluster_A::*> system image show Is Is Install Node Image Default Current Version Date -------- ------- ------- ------- -------- ------------------- node_A_1 image1 false false X.X.X MM/DD/YYYY TIME image2 true true Y.Y.Y MM/DD/YYYY TIME node_A_2 image1 false true X.X.X MM/DD/YYYY TIME image2 true false Y.Y.Y MM/DD/YYYY TIME 4 entries were displayed. cluster_A::> -
cluster_Bのバージョンを確認します。
system image show次の例は、System image2（ONTAP 9 .0.0）がnode_A_1のデフォルトおよび現在のバージョンであることを示しています。
cluster_A::*> system image show Is Is Install Node Image Default Current Version Date -------- ------- ------- ------- -------- ------------------- node_B_1 image1 false false X.X.X MM/DD/YYYY TIME image2 true true Y.Y.Y MM/DD/YYYY TIME node_B_2 image1 false true X.X.X MM/DD/YYYY TIME image2 true false Y.Y.Y MM/DD/YYYY TIME 4 entries were displayed. cluster_A::>
MetroCluster DRグループ内の2つ目のDRペアの更新
ONTAPの新しいバージョンをノードの現在のバージョンにするには、ノードのテイクオーバーとギブバックを正しい順序で実行する必要があります。
最初のDRペア（node_A_1とnode_B_1）をアップグレードしておく必要があります。
このタスクでは、node_A_2とnode_B_2をアップグレードします。
最初のDRグループのONTAPソフトウェアをアップグレードし、8ノードMetroCluster構成の2つ目のDRグループを更新する場合は、この手順でnode_A_4とnode_B_4を更新します。
-
ノードからすべてのデータLIFを移行します。
network interface migrate-all -node nodenameA -
cluster_Aのターゲットノードのテイクオーバーを開始します。
テイクオーバーされたノードを新しいソフトウェアイメージでブートするには通常のテイクオーバーが必要なため、-option immediateパラメータは指定しないでください。
-
cluster_AのDRパートナーをテイクオーバーします。
storage failover takeover -ofnode node_A_2 -option allow-version-mismatch
この `allow-version-mismatch`オプションは、ONTAP 9 .0からONTAP 9 .1へのアップグレードやパッチのアップグレードには必要ありません。 ノードがブートし、「Waiting for giveback」状態になります。
AutoSupportが有効な場合は、ノードがクラスタ クォーラムのメンバーでないことを示すAutoSupportメッセージが送信されます。この通知を無視し、アップグレードを続行してかまいません。
-
テイクオーバーが正常に完了したことを確認します。
storage failover show次の例は、テイクオーバーが正常に完了したことを示しています。node_A_2の状態は「Waiting for giveback」、node_A_1の状態は「In takeover」になっています。
cluster1::> storage failover show Takeover Node Partner Possible State Description -------------- -------------- -------- ------------------------------------- node_A_1 node_A_2 false In takeover node_A_2 node_A_1 - Waiting for giveback (HA mailboxes) 2 entries were displayed. -
-
cluster_Bのターゲット ノードのテイクオーバーを開始します。
テイクオーバーされたノードを新しいソフトウェアイメージでブートするには通常のテイクオーバーが必要なため、-option immediateパラメータは指定しないでください。
-
cluster_B（node_B_2）のDRパートナーをテイクオーバーします。
アップグレード前のバージョン 入力するコマンド ONTAP 9.2またはONTAP 9.1
storage failover takeover -ofnode node_B_2ONTAP 9.0またはData ONTAP 8.3.x
storage failover takeover -ofnode node_B_2 -option allow-version-mismatch
この `allow-version-mismatch`オプションは、ONTAP 9 .0からONTAP 9 .1へのアップグレードやパッチのアップグレードには必要ありません。 ノードがブートし、「Waiting for giveback」状態になります。
AutoSupportが有効な場合は、ノードがクラスタクォーラムのメンバーでないことを示すAutoSupportメッセージが送信されます。この通知を無視し、アップグレードを続行してかまいません。 -
テイクオーバーが正常に完了したことを確認します。
storage failover show次の例は、テイクオーバーが正常に完了したことを示しています。node_B_2の状態は「Waiting for giveback」、node_B_1の状態は「In takeover」になっています。
cluster1::> storage failover show Takeover Node Partner Possible State Description -------------- -------------- -------- ------------------------------------- node_B_1 node_B_2 false In takeover node_B_2 node_B_1 - Waiting for giveback (HA mailboxes) 2 entries were displayed. -
-
8分以上待ってから、次の条件を満たしていることを確認します。
-
クライアントのマルチパス（導入している場合）が安定している。
-
クライアントがテイクオーバー中に発生したI/Oの中断から回復している。
回復までの時間はクライアントによって異なり、クライアント アプリケーションの特性によっては8分以上かかることもあります。
-
-
アグリゲートをターゲット ノードに戻します。
MetroCluster IP構成をONTAP 9 5にアップグレードすると、アグリゲートは短時間degraded状態になり、その後再同期されてmirrored状態に戻ります。
-
アグリゲートをcluster_AのDRパートナーにギブバックします。
storage failover giveback -ofnode node_A_2 -
アグリゲートをcluster_BのDRパートナーにギブバックします。
storage failover giveback -ofnode node_B_2ギブバック処理では、最初にルート アグリゲートがノードに戻され、そのノードのブートが完了するとルート以外のアグリゲートが戻されます。
-
-
両方のクラスタで次のコマンドを実行して、すべてのアグリゲートが戻されたことを確認します。
storage failover show-givebackGiveback Statusフィールドにギブバックするアグリゲートがないことが示されている場合は、すべてのアグリゲートが戻されています。ギブバックが拒否された場合は、コマンドによってギブバックの進捗が表示され、拒否したサブシステムも表示されます。
-
戻されていないアグリゲートがある場合は、次の操作を実行します。
-
拒否された回避策を確認して、「 ve to 」状態に対処するか、拒否を無視するかを決定します。
-
必要に応じて、エラーメッセージに記載されている「宛」の状態に対処し、特定された処理が正常に終了するようにします。
-
storage failover givebackコマンドを再度入力します。
「 "" ～ "" 」条件をオーバーライドする場合は、 -override-vetoes パラメータを true に設定します。
-
-
8分以上待ってから、次の条件を満たしていることを確認します。
-
クライアントのマルチパス（導入している場合）が安定している。
-
クライアントがギブバック中に発生したI/Oの中断から回復している。
回復までの時間はクライアントによって異なり、クライアント アプリケーションの特性によっては8分以上かかることもあります。
-
-
権限レベルをadminからadvancedに設定します。続行するかどうかを尋ねられたら、「* y *」と入力します。
set -privilege advancedadvancedプロンプト(`*>`が表示されます）。
-
cluster_Aのバージョンを確認します。
system image show次の例は、System image2（ターゲットのONTAPイメージ）がnode_A_2のデフォルトおよび現在のバージョンであることを示しています。
cluster_B::*> system image show Is Is Install Node Image Default Current Version Date -------- ------- ------- ------- ---------- ------------------- node_A_1 image1 false false X.X.X MM/DD/YYYY TIME image2 true true Y.Y.Y MM/DD/YYYY TIME node_A_2 image1 false false X.X.X MM/DD/YYYY TIME image2 true true Y.Y.Y MM/DD/YYYY TIME 4 entries were displayed. cluster_A::> -
cluster_Bのバージョンを確認します。
system image show次の例は、System image2（ターゲットのONTAPイメージ）がnode_B_2のデフォルトかつ現在のバージョンであることを示しています。
cluster_B::*> system image show Is Is Install Node Image Default Current Version Date -------- ------- ------- ------- ---------- ------------------- node_B_1 image1 false false X.X.X MM/DD/YYYY TIME image2 true true Y.Y.Y MM/DD/YYYY TIME node_B_2 image1 false false X.X.X MM/DD/YYYY TIME image2 true true Y.Y.Y MM/DD/YYYY TIME 4 entries were displayed. cluster_A::> -
HAペアの各ノードで、自動ギブバックを有効にします。
storage failover modify -node target-node -auto-giveback trueこのコマンドはHAペアのノードごとに実行する必要があります。
-
自動ギブバックが有効になったことを確認します。
storage failover show -fields auto-giveback次の例では、両方のノードで自動ギブバックが有効になっています。
cluster_x::> storage failover show -fields auto-giveback node auto-giveback -------- ------------- node_x_1 true node_x_2 true 2 entries were displayed.