Skip to main content
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

CLIを使用した4ノードまたは8ノードMetroCluster構成の手動による無停止ONTAPアップグレード

共同作成者

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 の新しいバージョンのバージョン番号よりも上位の番号を持つバージョンを指します。

  • このタスクのワークフローは次のとおりです。

    MetroCluster アップグレードの決定フローの図

8ノードまたは4ノードのMetroCluster構成でONTAPソフトウェアを更新する場合の相違点

MetroClusterソフトウェアのアップグレードプロセスは、MetroCluster構成に8ノードと4ノードのどちらが含まれているかによって異なります。

MetroCluster 構成は、 1 つまたは 2 つの DR グループで構成されます。各 DR グループは 2 つの HA ペアで構成され、各 MetroCluster クラスタに HA ペアが 1 つずつ配置されます。8 ノードの MetroCluster には、 2 つの DR グループが含まれています。

8ノードMetroCluster 構成の図。

DRグループは一度に1つずつアップグレードします。

4 ノード MetroCluster 構成の場合:
  1. DRグループ1をアップグレードします。

    1. node_A_1とnode_B_1をアップグレード

    2. node_A_2とnode_B_2をアップグレードします。

8ノードMetroCluster構成の場合は、DRグループのアップグレード手順を2回実行します。
  1. DRグループ1をアップグレードします。

    1. node_A_1とnode_B_1をアップグレード

    2. node_A_2とnode_B_2をアップグレードします。

  2. DRグループ2をアップグレードします。

    1. node_A_3とnode_B_3をアップグレード

    2. node_A_4とnode_B_4をアップグレード

MetroCluster DRグループをアップグレードする準備

ノードのONTAPソフトウェアをアップグレードする前に、ノード間のDR関係を特定し、アップグレードを開始することを示すAutoSupportメッセージを送信し、各ノードで実行されているONTAPのバージョンを確認する必要があります。

が必要です "ダウンロードしました" および "インストール済み" ソフトウェアイメージ。

このタスクは DR グループごとに実行する必要があります。MetroCluster 構成が 8 つのノードで構成されている場合は、 DR グループが 2 つあります。そのため、 DR グループごとにこの手順を繰り返す必要があります。

このタスクの例では、次の図に示すクラスタとノードの名前を使用しています。

8ノードMetroCluster 構成の図。

  1. 構成内のDRペアを特定します。

    metrocluster node show -fields dr-partner
     cluster_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::>
  2. 権限レベルをadminからadvancedに設定します。続行するかどうかを尋ねられたら、「* y *」と入力します。

    set -privilege advanced

    advancedプロンプトが表示されます (*>)が表示されます。

  3. cluster_AのONTAPバージョンを確認します。

    system image show
     cluster_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::>
  4. cluster_Bのバージョンを確認します。

    system image show
     cluster_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::>
  5. AutoSupport 通知を送信します。

    autosupport invoke -node * -type all -message "Starting_NDU"

    このAutoSupport通知には、アップグレード前のシステムステータスの記録が含まれます。アップグレードプロセスで問題が発生した場合に役立つトラブルシューティング情報が保存されます。

    AutoSupport メッセージを送信するようにクラスタが設定されていない場合は、通知のコピーがローカルに保存されます。

  6. 最初のセットに含まれる各ノードについて、ターゲットのONTAP ソフトウェアイメージをデフォルトのイメージとして設定します。

    system image modify {-node nodename -iscurrent false} -isdefault true

    このコマンドでは、拡張クエリを使用して、代替イメージとしてインストールされるターゲットのソフトウェアイメージがノードのデフォルトのイメージになるように変更します。

  7. ターゲットの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.
    1. ターゲットの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.
  8. アップグレード対象のノードが各ノードで現在クライアントに対して2回処理を行っているかどうかを確認します。

    system node run -node target-node -command uptime

    uptime コマンドは、ノードの前回のブート以降に 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を更新します。

  1. MetroCluster Tiebreaker ソフトウェアが有効になっている場合は、無効にします。

  2. HAペアの各ノードで、自動ギブバックを無効にします。

    storage failover modify -node target-node -auto-giveback false

    このコマンドは HA ペアのノードごとに実行する必要があります。

  3. 自動ギブバックが無効になったことを確認します。

    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.
  4. 各コントローラのI/Oが50%を超えていないこと、およびCPU利用率がコントローラあたり50%を超えていないことを確認してください。

  5. cluster_A のターゲットノードのテイクオーバーを開始します。

    テイクオーバーされたノードを新しいソフトウェアイメージでブートするには通常のテイクオーバーが必要なため、 -option immediate パラメータは指定しないでください。

    1. cluster_A(node_A_1)のDRパートナーをテイクオーバーします。

      storage failover takeover -ofnode node_A_1

      ノードがブートし、「 Waiting for giveback 」状態になります。

      メモ AutoSupport が有効な場合は、ノードがクラスタクォーラムのメンバーでないことを示す AutoSupport メッセージが送信されます。この通知を無視し、アップグレードを続行してかまいません。
    2. テイクオーバーが正常に完了したことを確認します。

      storage failover show

      次の例は、テイクオーバーが正常に完了したことを示しています。node_A_1 は「 Waiting for giveback 」状態、 node_A_1 は「 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.
  6. cluster_B ( node_B_1 )の DR パートナーをテイクオーバーします。

    テイクオーバーされたノードを新しいソフトウェアイメージでブートするには通常のテイクオーバーが必要なため、 -option immediate パラメータは指定しないでください。

    1. node_B_1をテイクオーバーします。

      storage failover takeover -ofnode node_B_1

      ノードがブートし、「 Waiting for giveback 」状態になります。

      メモ AutoSupport が有効な場合は、ノードがクラスタクォーラムのメンバーでないことを示す AutoSupport メッセージが送信されます。この通知を無視し、アップグレードを続行してかまいません。
    2. テイクオーバーが正常に完了したことを確認します。

      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.
  7. 8 分以上待ってから、次の条件を満たしていることを確認します。

    • クライアントのマルチパス(導入している場合)が安定している。

    • クライアントがテイクオーバー中に発生した I/O の中断から回復している。

      回復までの時間はクライアントによって異なり、クライアントアプリケーションの特性によっては 8 分以上かかることもあります。

  8. アグリゲートをターゲットノードに戻します。

    MetroCluster IP 構成を ONTAP 9.5 以降にアップグレードすると、アグリゲートの状態は短時間 degraded になったあとに再同期されて mirrored に戻ります。

    1. アグリゲートをcluster_AのDRパートナーにギブバックします。

      storage failover giveback –ofnode node_A_1
    2. アグリゲートをcluster_BのDRパートナーにギブバックします。

      storage failover giveback –ofnode node_B_1

      ギブバック処理では、最初にルートアグリゲートがノードに戻され、そのノードのブートが完了するとルート以外のアグリゲートが戻されます。

  9. 両方のクラスタで次のコマンドを実行して、すべてのアグリゲートが戻されたことを確認します。

    storage failover show-giveback

    Giveback Status フィールドにギブバックするアグリゲートがないことが示されている場合は、すべてのアグリゲートが戻されています。ギブバックが拒否された場合は、コマンドによってギブバックの進捗が表示され、ギブバックを拒否したサブシステムも表示されます。

  10. いずれかのアグリゲートが戻されていない場合は、次の手順を実行します。

    1. 拒否された回避策を確認して、「 ve to 」状態に対処するか、拒否を無視するかを決定します。

    2. 必要に応じて、エラーメッセージに記載されている「宛」の状態に対処し、特定された処理が正常に終了するようにします。

    3. storage failover giveback コマンドを再度入力します。

      「 "" ~ "" 」条件をオーバーライドする場合は、 -override-vetoes パラメータを true に設定します。

  11. 8 分以上待ってから、次の条件を満たしていることを確認します。

    • クライアントのマルチパス(導入している場合)が安定している。

    • クライアントがギブバック中に発生した I/O の中断から回復している。

      回復までの時間はクライアントによって異なり、クライアントアプリケーションの特性によっては 8 分以上かかることもあります。

  12. 権限レベルをadminからadvancedに設定します。続行するかどうかを尋ねられたら、「* y *」と入力します。

    set -privilege advanced

    advancedプロンプトが表示されます (*>)が表示されます。

  13. 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::>
  14. 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を更新します。

  1. ノードからすべてのデータLIFを移行します。

    network interface migrate-all -node nodenameA
  2. cluster_A のターゲットノードのテイクオーバーを開始します。

    テイクオーバーされたノードを新しいソフトウェアイメージでブートするには通常のテイクオーバーが必要なため、 -option immediate パラメータは指定しないでください。

    1. 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 メッセージが送信されます。この通知を無視し、アップグレードを続行してかまいません。

    2. テイクオーバーが正常に完了したことを確認します。

      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.
  3. cluster_B のターゲットノードのテイクオーバーを開始します。

    テイクオーバーされたノードを新しいソフトウェアイメージでブートするには通常のテイクオーバーが必要なため、 -option immediate パラメータは指定しないでください。

    1. cluster_B(node_B_2)のDRパートナーをテイクオーバーします。

      アップグレード前のバージョン 入力するコマンド

      ONTAP 9.2 または ONTAP 9.1

      storage failover takeover -ofnode node_B_2

      ONTAP 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メッセージが送信されます。この通知を無視し、アップグレードを続行してかまいません。
    2. テイクオーバーが正常に完了したことを確認します。

      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.
  4. 8 分以上待ってから、次の条件を満たしていることを確認します。

    • クライアントのマルチパス(導入している場合)が安定している。

    • クライアントがテイクオーバー中に発生した I/O の中断から回復している。

      回復までの時間はクライアントによって異なり、クライアントアプリケーションの特性によっては 8 分以上かかることもあります。

  5. アグリゲートをターゲットノードに戻します。

    MetroCluster IP 構成を ONTAP 9.5 にアップグレードすると、アグリゲートの状態は短時間 degraded になったあとに再同期されて mirrored に戻ります。

    1. アグリゲートをcluster_AのDRパートナーにギブバックします。

      storage failover giveback –ofnode node_A_2
    2. アグリゲートをcluster_BのDRパートナーにギブバックします。

      storage failover giveback –ofnode node_B_2

      ギブバック処理では、最初にルートアグリゲートがノードに戻され、そのノードのブートが完了するとルート以外のアグリゲートが戻されます。

  6. 両方のクラスタで次のコマンドを実行して、すべてのアグリゲートが戻されたことを確認します。

    storage failover show-giveback

    Giveback Status フィールドにギブバックするアグリゲートがないことが示されている場合は、すべてのアグリゲートが戻されています。ギブバックが拒否された場合は、コマンドによってギブバックの進捗が表示され、ギブバックを拒否したサブシステムも表示されます。

  7. いずれかのアグリゲートが戻されていない場合は、次の手順を実行します。

    1. 拒否された回避策を確認して、「 ve to 」状態に対処するか、拒否を無視するかを決定します。

    2. 必要に応じて、エラーメッセージに記載されている「宛」の状態に対処し、特定された処理が正常に終了するようにします。

    3. storage failover giveback コマンドを再度入力します。

      「 "" ~ "" 」条件をオーバーライドする場合は、 -override-vetoes パラメータを true に設定します。

  8. 8 分以上待ってから、次の条件を満たしていることを確認します。

    • クライアントのマルチパス(導入している場合)が安定している。

    • クライアントがギブバック中に発生した I/O の中断から回復している。

      回復までの時間はクライアントによって異なり、クライアントアプリケーションの特性によっては 8 分以上かかることもあります。

  9. 権限レベルをadminからadvancedに設定します。続行するかどうかを尋ねられたら、「* y *」と入力します。

    set -privilege advanced

    advancedプロンプトが表示されます (*>)が表示されます。

  10. 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::>
  11. 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::>
  12. HAペアの各ノードで、自動ギブバックを有効にします。

    storage failover modify -node target-node -auto-giveback true

    このコマンドは HA ペアのノードごとに実行する必要があります。

  13. 自動ギブバックが有効になったことを確認します。

    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.