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

CLIを使用したONTAPの手動無停止アップグレード(標準構成)

共同作成者 netapp-aherbin netapp-aaron-holt netapp-dbagwell netapp-ahibbard netapp-forry

System Managerを使用した自動アップグレードが推奨されるアップグレード方法です。System Managerがお使いの構成をサポートしていない場合は、ONTAPコマンドラインインターフェイス(CLI)を使用して、手動で無停止アップグレードを実行できます。2ノード以上のクラスタを手動無停止アップグレードでアップグレードするには、HAペアの各ノードでフェイルオーバー操作を開始し、「障害」ノードを更新し、ギブバックを開始してから、クラスタ内の各HAペアでこのプロセスを繰り返す必要があります。

開始する前に

アップグレード"準備"の要件を満たしている必要があります。

HAペアの最初のノードの更新

ノードのパートナーによるテイクオーバーを開始することで、HAペアの最初のノードを更新できます。最初のノードをアップグレードしている間、ノードのデータはパートナーから提供されます。

メジャー アップグレードを実行する場合は、外部接続用にデータLIFを設定し、最初のONTAPイメージをインストールしたノードをアップグレード対象の最初のノードにする必要があります。

最初のノードをアップグレードした後は、できるだけ早くパートナーノードをアップグレードする必要があります。2つのノードの"異なるバージョンの混在"状態を必要以上に長く維持しないでください。

手順
  1. AutoSupportメッセージを呼び出して、クラスタ内の最初のノードを更新します。

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

    このAutoSupport通知には、更新直前のシステム ステータスの記録が含まれています。これにより、更新処理で問題が発生した場合に役立つトラブルシューティング情報が保存されます。

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

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

    set -privilege advanced

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

  3. 新しいONTAPソフトウェア イメージをデフォルトのイメージとして設定します。

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

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

  4. 更新の進行状況を監視します。

    system node upgrade-revert show
  5. 新しいONTAPソフトウェア イメージがデフォルトのイメージとして設定されたことを確認します。

    system image show

    次の例では、image2が新しいONTAPバージョンで、node0のデフォルトのバージョンとして設定されています。

    cluster1::*> system image show
                     Is      Is                Install
    Node     Image   Default Current Version    Date
    -------- ------- ------- ------- --------- -------------------
    node0
             image1  false   true    X.X.X     MM/DD/YYYY TIME
             image2  true    false   Y.Y.Y     MM/DD/YYYY TIME
    node1
             image1  true    true    X.X.X     MM/DD/YYYY TIME
             image2  false   false   Y.Y.Y     MM/DD/YYYY TIME
    4 entries were displayed.
  6. パートナー ノードで自動ギブバックが有効になっている場合は、無効にします。

    storage failover modify -node nodenameB -auto-giveback false

    クラスタが2ノードクラスタの場合、自動ギブバックを無効にすると、交互障害シナリオ発生時に管理クラスタサービスがオンラインにならないことを警告するメッセージが表示されます。 `y`を入力して続行します。

  7. ノードのパートナーの自動ギブバックが無効になっていることを確認します。

    storage failover show -node nodenameB -fields auto-giveback
    cluster1::> storage failover show -node node1 -fields auto-giveback
    node     auto-giveback
    -------- -------------
    node1    false
    1 entry was displayed.
  8. 次のコマンドを2回実行して、更新対象のノードが現在クライアントに対して処理を行っているかどうかを確認します。

    system node run -node nodenameA -command uptime

    uptimeコマンドでは、ノードの前回のブート以降にNFS、SMB、FC、iSCSIの各クライアントに対してノードが実行した処理の総数が表示されます。プロトコルごとにコマンドを2回実行して、処理数が増加しているかどうかを確認する必要があります。増加している場合は、そのプロトコルのクライアントに対してノードが現在処理を行っています。増加していない場合は、そのプロトコルのクライアントに対してノードは現在処理を行っていません。

    メモ ノードの更新後にクライアント トラフィックが再開したことを確認できるように、クライアントの処理数が増加しているプロトコルをすべて書き留めてください。

    次の例は、NFS、SMB、FC、およびiSCSIの処理が検出されたノードを示しています。ただし、ノードは現在NFSクライアントとiSCSIクライアントに対してのみ処理を行っています。

    cluster1::> 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
    
    cluster1::> 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
  9. ノードからすべてのデータLIFを移行します。

    network interface migrate-all -node nodenameA
  10. 移行したLIFを確認します。

    network interface show
    `network interface show`および LIF ステータスを確認するために使用できるパラメータの詳細については、link:https://docs.netapp.com/us-en/ontap-cli/network-interface-show.html["ONTAPコマンド リファレンス"^]を参照してください。

    次の例は、node0のデータLIFが正常に移行されたことを示しています。それぞれのLIFについて、この例に含まれるフィールドを使用して、LIFのホーム ノードとポート、LIFの移行先である現在のノードとポート、およびLIFの動作ステータスと管理ステータスを確認できます。

    cluster1::> network interface show -data-protocol nfs|cifs -role data -home-node node0 -fields home-node,curr-node,curr-port,home-port,status-admin,status-oper
    vserver lif     home-node home-port curr-node curr-port status-oper status-admin
    ------- ------- --------- --------- --------- --------- ----------- ------------
    vs0     data001 node0     e0a       node1     e0a       up          up
    vs0     data002 node0     e0b       node1     e0b       up          up
    vs0     data003 node0     e0b       node1     e0b       up          up
    vs0     data004 node0     e0a       node1     e0a       up          up
    4 entries were displayed.
  11. テイクオーバーを開始します。

    storage failover takeover -ofnode nodenameA

    テイクオーバーするノードを新しいソフトウェア イメージでブートするには通常のテイクオーバーが必要なため、-option immediateパラメータは指定しないでください。ノードからLIFを手動で移行しなかった場合は、LIFがノードのHAパートナーに自動的に移行されるので、サービスが停止することはありません。

    最初のノードがブートし、Waiting for giveback状態になります。

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

    storage failover show

    バージョン不一致およびメールボックス形式の問題を示すエラー メッセージが表示される可能性があります。これは想定どおりの動作です。無停止メジャー アップグレードにおける一時的な状態を表しており、悪影響はありません。

    次の例は、テイクオーバーが正常に完了したことを示しています。ノードnode0の状態はWaiting for giveback、パートナーの状態はIn takeoverになっています。

    cluster1::> storage failover show
                                  Takeover
    Node           Partner        Possible State Description
    -------------- -------------- -------- -------------------------------------
    node0          node1          -        Waiting for giveback (HA mailboxes)
    node1          node0          false    In takeover
    2 entries were displayed.
  13. 次の状態になるまで最低8分待ちます。

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

    • クライアントは、テイクオーバー中に発生する I/O 操作の一時停止から回復されます。

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

  14. アグリゲートを最初のノードに戻します。

    storage failover giveback -ofnode nodenameA

    ギブバックでは、最初にルート アグリゲートをパートナー ノードに戻し、そのノードのブートが完了すると、ルート以外のアグリゲートと自動的にリバートするように設定されたすべてのLIFを戻します。新しくブートしたノードで、戻されたアグリゲートから順番にクライアントへのデータ提供が開始されます。

  15. すべてのアグリゲートが戻されたことを確認します。

    storage failover show-giveback

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

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

    1. 拒否回避策を確認して、「veto」条件に対処するか、拒否をオーバーライドするかを決定します。

    2. 必要に応じて、エラーメッセージに記載されている「veto」条件に対処し、特定された処理が正常に終了することを確認します。

    3. `storage failover giveback`コマンドを再実行します。

      veto」条件を上書きする場合は、-override-vetoes パラメータを true に設定します。

  17. 次の状態になるまで最低8分待ちます。

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

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

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

  18. ノードの更新が正常に完了したことを確認します。

    1. advanced権限レベルに切り替えます。

      set -privilege advanced
    2. ノードの更新ステータスが完了になっていることを確認します。

      system node upgrade-revert show -node nodenameA

      ステータスがcompleteと表示される必要があります。

    ステータスがcompleteと表示されない場合は、テクニカル サポートにお問い合わせください。

    1. admin権限レベルに戻ります。

      set -privilege admin
  19. ノードのポートが動作していることを確認します。

    network port show -node nodenameA

    このコマンドは、ONTAP 9の上位バージョンにアップグレードされたノードで実行する必要があります。

    次の例は、ノードのすべてのポートが動作していることを示しています。

    cluster1::> network port show -node node0
                                                                 Speed (Mbps)
    Node   Port      IPspace      Broadcast Domain Link   MTU    Admin/Oper
    ------ --------- ------------ ---------------- ----- ------- ------------
    node0
           e0M       Default      -                up       1500  auto/100
           e0a       Default      -                up       1500  auto/1000
           e0b       Default      -                up       1500  auto/1000
           e1a       Cluster      Cluster          up       9000  auto/10000
           e1b       Cluster      Cluster          up       9000  auto/10000
    5 entries were displayed.
  20. LIFをノードにリバートします。

    network interface revert *

    このコマンドを実行すると、移行したLIFが元のノードに戻されます。

    cluster1::> network interface revert *
    8 entries were acted on.
  21. ノードのデータLIFが正常にノードにリバートされ、動作していることを確認します。

    network interface show

    次の例は、ノードがホストするすべてのデータLIFが正常にノードにリバートされ、動作ステータスが「up」になっていることを示しています。

    cluster1::> network interface show
                Logical    Status     Network            Current       Current Is
    Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
    ----------- ---------- ---------- ------------------ ------------- ------- ----
    vs0
                data001      up/up    192.0.2.120/24     node0         e0a     true
                data002      up/up    192.0.2.121/24     node0         e0b     true
                data003      up/up    192.0.2.122/24     node0         e0b     true
                data004      up/up    192.0.2.123/24     node0         e0a     true
    4 entries were displayed.
  22. 前の手順でこのノードがクライアントに対して処理を行っていることを確認した場合は、その時点で処理を行っていたプロトコルごとに、ノードがサービスを提供していることを確認します。

    system node run -node nodenameA -command uptime

    更新中に、処理数はゼロにリセットされます。

    次の例は、更新したノードがNFSクライアントとiSCSIクライアントに対する処理を再開していることを示しています。

    cluster1::> system node run -node node0 -command uptime
      3:15pm up  0 days, 0:16 129 NFS ops, 0 CIFS ops, 0 HTTP ops, 0 FCP ops, 2 iSCSI ops
  23. 前の手順でパートナー ノードの自動ギブバックを無効にした場合は、再度有効にします。

    storage failover modify -node nodenameB -auto-giveback true

できるだけ早くノードのHAパートナーの更新に進んでください。何らかの理由で更新プロセスを中断する必要がある場合は、HAペアの両方のノードで同じバージョンのONTAPを実行する必要があります。

HAペアのパートナー ノードの更新

HAペアの最初のノードを更新したあとは、そのノードでテイクオーバーを開始してパートナーを更新します。パートナーをアップグレードしている間、パートナーのデータは最初のノードから提供されます。

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

    set -privilege advanced

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

  2. 新しいONTAPソフトウェア イメージをデフォルトのイメージとして設定します。

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

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

  3. 更新の進行状況を監視します。

    system node upgrade-revert show
  4. 新しいONTAPソフトウェア イメージがデフォルトのイメージとして設定されたことを確認します。

    system image show

    次の例では、 `image2`はONTAPの新しいバージョンであり、ノード上のデフォルトイメージとして設定されています:

    cluster1::*> system image show
                     Is      Is                Install
    Node     Image   Default Current Version    Date
    -------- ------- ------- ------- --------- -------------------
    node0
             image1  false   false   X.X.X     MM/DD/YYYY TIME
             image2  true    true    Y.Y.Y     MM/DD/YYYY TIME
    node1
             image1  false   true    X.X.X     MM/DD/YYYY TIME
             image2  true    false   Y.Y.Y     MM/DD/YYYY TIME
    4 entries were displayed.
  5. パートナー ノードで自動ギブバックが有効になっている場合は、無効にします。

    storage failover modify -node nodenameA -auto-giveback false

    クラスタが2ノードクラスタの場合、自動ギブバックを無効にすると、交互障害シナリオ発生時に管理クラスタサービスがオンラインにならないことを警告するメッセージが表示されます。 `y`を入力して続行します。

  6. パートナー ノードの自動ギブバックが無効になっていることを確認します。

    storage failover show -node nodenameA -fields auto-giveback
    cluster1::> storage failover show -node node0 -fields auto-giveback
    node     auto-giveback
    -------- -------------
    node0    false
    1 entry was displayed.
  7. 次のコマンドを2回実行して、更新対象のノードが現在クライアントに対して処理を行っているかどうかを確認します。

    system node run -node nodenameB -command uptime

    uptimeコマンドでは、ノードの前回のブート以降にNFS、SMB、FC、iSCSIの各クライアントに対してノードが実行した処理の総数が表示されます。プロトコルごとにコマンドを2回実行して、処理数が増加しているかどうかを確認する必要があります。増加している場合は、そのプロトコルのクライアントに対してノードが現在処理を行っています。増加していない場合は、そのプロトコルのクライアントに対してノードは現在処理を行っていません。

    メモ ノードの更新後にクライアント トラフィックが再開したことを確認できるように、クライアントの処理数が増加しているプロトコルをすべて書き留めてください。

    次の例は、NFS、SMB、FC、およびiSCSIの処理が検出されたノードを示しています。ただし、ノードは現在NFSクライアントとiSCSIクライアントに対してのみ処理を行っています。

    cluster1::> system node run -node node1 -command uptime
      2:58pm up  7 days, 19:16 800000260 NFS ops, 1017333 CIFS ops, 0 HTTP ops, 40395 FCP ops, 32810 iSCSI ops
    
    cluster1::> system node run -node node1 -command uptime
      2:58pm up  7 days, 19:17 800001573 NFS ops, 1017333 CIFS ops, 0 HTTP ops, 40395 FCP ops, 32815 iSCSI ops
  8. ノードからすべてのデータLIFを移行します。

    network interface migrate-all -node nodenameB
  9. 移行したLIFのステータスを確認します。

    network interface show
    `network interface show`および LIF ステータスを確認するために使用できるパラメータの詳細については、link:https://docs.netapp.com/us-en/ontap-cli/network-interface-show.html["ONTAPコマンド リファレンス"^]を参照してください。

    次の例は、node1のデータLIFが正常に移行されたことを示しています。それぞれのLIFについて、この例に含まれるフィールドを使用して、LIFのホーム ノードとポート、LIFの移行先である現在のノードとポート、およびLIFの動作ステータスと管理ステータスを確認できます。

    cluster1::> network interface show -data-protocol nfs|cifs -role data -home-node node1 -fields home-node,curr-node,curr-port,home-port,status-admin,status-oper
    vserver lif     home-node home-port curr-node curr-port status-oper status-admin
    ------- ------- --------- --------- --------- --------- ----------- ------------
    vs0     data001 node1     e0a       node0     e0a       up          up
    vs0     data002 node1     e0b       node0     e0b       up          up
    vs0     data003 node1     e0b       node0     e0b       up          up
    vs0     data004 node1     e0a       node0     e0a       up          up
    4 entries were displayed.
  10. テイクオーバーを開始します。

    storage failover takeover -ofnode nodenameB -option allow-version-mismatch

    テイクオーバーするノードを新しいソフトウェア イメージでブートするには通常のテイクオーバーが必要なため、-option immediateパラメータは指定しないでください。ノードからLIFを手動で移行しなかった場合は、LIFがノードのHAパートナーに自動的に移行されるので、サービスが停止することはありません。

    警告が表示されます。続行するには `y`を入力する必要があります。

    テイクオーバーされたノードがブートし、Waiting for giveback状態になります。

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

    storage failover show

    次の例は、テイクオーバーが正常に完了したことを示しています。ノードnode1の状態はWaiting for giveback、パートナーの状態はIn takeoverになっています。

    cluster1::> storage failover show
                                  Takeover
    Node           Partner        Possible State Description
    -------------- -------------- -------- -------------------------------------
    node0          node1          -        In takeover
    node1          node0          false    Waiting for giveback (HA mailboxes)
    2 entries were displayed.
  12. 以下の条件が有効になるまで少なくとも8分間お待ちください:+

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

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

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

  13. アグリゲートをパートナー ノードに戻します。

    storage failover giveback -ofnode nodenameB

    ギブバック処理では、最初にルート アグリゲートがノードに戻され、そのノードのブートが完了すると、ルート以外のアグリゲートと自動的にリバートするように設定されたすべてのLIFが戻されます。新しくブートしたノードで、戻されたアグリゲートから順番にクライアントへのデータ提供が開始されます。

  14. すべてのアグリゲートが戻されたことを確認します。

    storage failover show-giveback

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

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

    1. 拒否回避策を確認して、「veto」条件に対処するか、拒否をオーバーライドするかを決定します。

    2. 必要に応じて、エラーメッセージに記載されている「veto」条件に対処し、特定された処理が正常に終了することを確認します。

    3. `storage failover giveback`コマンドを再実行します。

      veto」条件を上書きする場合は、-override-vetoes パラメータを true に設定します。

  16. 次の状態になるまで最低8分待ちます。

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

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

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

  17. ノードの更新が正常に完了したことを確認します。

    1. advanced権限レベルに切り替えます。

      set -privilege advanced
    2. ノードの更新ステータスが完了になっていることを確認します。

      system node upgrade-revert show -node nodenameB

      ステータスがcompleteと表示される必要があります。

    ステータスが「完了」でない場合は、ノードから `system node upgrade-revert upgrade`コマンドを実行してください。コマンドを実行しても更新が完了しない場合は、テクニカルサポートにお問い合わせください。

    1. admin権限レベルに戻ります。

      set -privilege admin
  18. ノードのポートが動作していることを確認します。

    network port show -node nodenameB

    このコマンドはONTAP 9.4にアップグレードされたノードで実行する必要があります。

    次の例は、ノードのすべてのデータ ポートが動作していることを示しています。

    cluster1::> network port show -node node1
                                                                 Speed (Mbps)
    Node   Port      IPspace      Broadcast Domain Link   MTU    Admin/Oper
    ------ --------- ------------ ---------------- ----- ------- ------------
    node1
           e0M       Default      -                up       1500  auto/100
           e0a       Default      -                up       1500  auto/1000
           e0b       Default      -                up       1500  auto/1000
           e1a       Cluster      Cluster          up       9000  auto/10000
           e1b       Cluster      Cluster          up       9000  auto/10000
    5 entries were displayed.
    `network port show`の詳細については、link:https://docs.netapp.com/us-en/ontap-cli/network-port-show.html["ONTAPコマンド リファレンス"^]を参照してください。
  19. LIFをノードにリバートします。

    network interface revert *

    このコマンドを実行すると、移行したLIFが元のノードに戻されます。

    cluster1::> network interface revert *
    8 entries were acted on.
  20. ノードのデータLIFが正常にノードにリバートされ、動作していることを確認します。

    network interface show

    次の例は、ノードがホストするすべてのデータLIFが正常にノードにリバートされ、動作ステータスが「up」になっていることを示しています。

    cluster1::> network interface show
                Logical    Status     Network            Current       Current Is
    Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
    ----------- ---------- ---------- ------------------ ------------- ------- ----
    vs0
                data001      up/up    192.0.2.120/24     node1         e0a     true
                data002      up/up    192.0.2.121/24     node1         e0b     true
                data003      up/up    192.0.2.122/24     node1         e0b     true
                data004      up/up    192.0.2.123/24     node1         e0a     true
    4 entries were displayed.
  21. 前の手順でこのノードがクライアントに対して処理を行っていることを確認した場合は、その時点で処理を行っていたプロトコルごとに、ノードがサービスを提供していることを確認します。

    system node run -node nodenameB -command uptime

    更新中に、処理数はゼロにリセットされます。

    次の例は、更新したノードがNFSクライアントとiSCSIクライアントに対する処理を再開していることを示しています。

    cluster1::> system node run -node node1 -command uptime
      3:15pm up  0 days, 0:16 129 NFS ops, 0 CIFS ops, 0 HTTP ops, 0 FCP ops, 2 iSCSI ops
  22. これがクラスタ内で更新する最後のノードであった場合は、AutoSupport通知を発行します。

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

    このAutoSupport通知には、更新直前のシステム ステータスの記録が含まれています。これにより、更新処理で問題が発生した場合に役立つトラブルシューティング情報が保存されます。

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

  23. HAペアの両方のノードで新しいONTAPソフトウェアが実行されていることを確認します。

    set -privilege advanced
    system node image show

    次の例では、image2がONTAPの更新されたバージョンで、両方のノードのデフォルトのバージョンになっています。

    cluster1::*> system node image show
                     Is      Is                Install
    Node     Image   Default Current Version    Date
    -------- ------- ------- ------- --------- -------------------
    node0
             image1  false   false   X.X.X     MM/DD/YYYY TIME
             image2  true    true    Y.Y.Y     MM/DD/YYYY TIME
    node1
             image1  false   false   X.X.X     MM/DD/YYYY TIME
             image2  true    true    Y.Y.Y     MM/DD/YYYY TIME
    4 entries were displayed.
  24. 前の手順でパートナー ノードの自動ギブバックを無効にした場合は、再度有効にします。

    storage failover modify -node nodenameA -auto-giveback true
  25. cluster show`および `cluster ring show(高度な権限レベル)コマンドを使用して、クラスタがクォーラム状態にあり、サービスが実行されていることを確認します。

    追加のHAペアをアップグレードする前にこの操作を行ってください。

    `cluster show`および `cluster ring show`の詳細については、link:https://docs.netapp.com/us-en/ontap-cli/search.html?q=cluster+show["ONTAPコマンド リファレンス"^]を参照してください。
  26. admin権限レベルに戻ります。

    set -privilege admin
  27. 追加のHAペアがある場合はアップグレードします。