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

スイッチオーバーとスイッチバックを使用した MetroCluster IP 構成でのコントローラのアップグレード( ONTAP 9.8 以降)

寄稿者 netapp-thomi netapp-martyh このページの PDF をダウンロード

ONTAP 9.8 以降では、 MetroCluster スイッチオーバー処理を使用して、パートナークラスタのコントローラモジュールをアップグレードする際にクライアントに無停止でサービスを提供できます。この手順の一部として他のコンポーネント(ストレージシェルフやスイッチなど)をアップグレードすることはできません。

このタスクについて
  • プラットフォームで ONTAP 9.8 以降が実行されている必要があります。

  • この手順環境コントローラモジュールは MetroCluster IP 構成です。

  • サポートされるアップグレードパスは、元のプラットフォームモデルによって異なります。

    シェルフ内蔵のプラットフォームモデルはサポートされていません。

    旧プラットフォームモデル

    新しいプラットフォームモデル

    • AFF A320

    • AFF A400

    • FAS8200

    • FAS9000

    • FAS8300

    • FAS8700 の場合

注記 BES-53248 IP スイッチを使用している場合、 AFF A320 プラットフォームモデルはアップグレードに対応していません。
  • 構成内のすべてのコントローラは、同じメンテナンス期間にアップグレードする必要があります。

    このメンテナンス作業以外では、コントローラタイプが異なる MetroCluster 構成を運用することはできません。

  • 新しいプラットフォームは、元のプラットフォームとは別のモデルである必要があります。

  • サポートされているファームウェアバージョンが IP スイッチで実行されている必要があります。

  • 新しいプラットフォームのスロット数が元のシステムのスロット数より少ない場合、またはポートのタイプが異なる場合は、新しいシステムにアダプタを追加しなければならないことがあります。

    詳細については、を参照してください "NetApp Hardware Universe の略"

  • 元のプラットフォームの IP アドレス、ネットマスク、ゲートウェイを新しいプラットフォームで再利用します。

  • この手順では、次の名前が使用されています。

    • site_A

      • アップグレード前:

        • node_A_1 - 古い

        • Node_a_2-old

      • アップグレード後:

        • node_A_1 - 新規

        • Node_a_2 - 新規

    • site_B

      • アップグレード前:

        • node_B_1 - 古い

        • node_B_2 - 古い

      • アップグレード後:

        • node_B_1 - 新規

        • node_B_2 - 新規

MetroCluster IP 構成のコントローラをアップグレードするためのワークフロー

ワークフロー図は、アップグレードタスクを計画する際に役立ちます。

ワークフロー IP アップグレード

アップグレードの準備を行います

既存の MetroCluster 構成に変更を加える前に、構成の健全性を確認し、新しいプラットフォームを準備し、その他のタスクを実行する必要があります。

コントローラをアップグレードする前に MetroCluster スイッチの RCF ファイルを更新しています

古いプラットフォームモデルに応じて、またはスイッチの設定が最小バージョンでない場合、またはバックエンド MetroCluster 接続で使用する VLAN ID を変更する場合は、プラットフォームのアップグレード手順を開始する前にスイッチの RCF ファイルを更新する必要があります。

次のシナリオで RCF ファイルを更新する必要があります。

  • 特定のプラットフォームモデルでは、バックエンド MetroCluster IP 接続でサポートされている VLAN ID をスイッチが使用している必要があります。古いプラットフォームモデルまたは新しいプラットフォームモデルの表に、サポートされる VLAN ID を使用しない * プラットフォームモデルが含まれている場合は、スイッチの RCF ファイルを更新する必要があります。

    注記 ローカルクラスタ接続では任意の VLAN を使用でき、指定した範囲内にある必要はありません。

    プラットフォームモデル(新旧)

    サポートされる VLAN ID

    • AFF A400

    • 10.

    • 20

    • 101 ~ 4096 の範囲の任意の値。

  • サポートされている最小限の RCF バージョンでスイッチ設定が構成されていませんでした:

    スイッチモデル

    必要な RCF ファイルのバージョン

    Cisco 3132Q-V の設定

    1.7 以降

    Cisco 3232C

    1.7 以降

    Broadcom BES-53248 の場合

    1.3 以降

  • VLAN の設定を変更する。

    VLAN ID の範囲は 101 ~ 4096 です。

site_A のコントローラをアップグレードすると、 site_A のスイッチがアップグレードされます。

古いノードから新しいノードへのポートのマッピング

node_A_1 の古い物理ポートが、 node_A_1 の新しい物理ポートに正しくマッピングされ、アップグレード後に node_A_1 の新しいノードがクラスタ内の他のノードおよびネットワークと通信できることを確認する必要があります。

アップグレードプロセスで最初に新しいノードがブートされると、交換前の古いノードの最新の設定が再生されます。node_A_1 を新規にブートすると、 ONTAP は node_A_1 の古いポートで使用されていた LIF をホストしようとします。そのため、アップグレードの一環として、ポートと LIF の設定を古いノードと互換性があるように調整する必要があります。アップグレード手順では、クラスタ LIF 、管理 LIF 、およびデータ LIF の構成が正しくなるように、古いノードと新しいノードの両方で手順を実行します。

次の表に、新しいノードのポート要件に関連する設定変更の例を示します。

クラスタインターコネクトの物理ポート

古いコントローラ

新しいコントローラ

必要なアクション

e0a 、 e0b

e3a 、 e3b

一致するポートがありません。アップグレード後にクラスタポートを再作成する必要があります。

e0c 、 e0d

e0a 、 e0b 、 e0c 、 e0d

e0c と e0d は同じポートです。構成を変更する必要はありませんが、アップグレード後は、使用可能なクラスタポートにクラスタ LIF を分散させることができます。

手順
  1. 新しいコントローラで使用できる物理ポートとポートでホストできる LIF を確認します。

    コントローラのポートの用途は、プラットフォームモジュールおよび MetroCluster IP 構成で使用するスイッチによって異なります。新しいプラットフォームのポート使用量をから収集できます "NetApp Hardware Universe の略"

  2. ポートの使用状況を計画し、次の表に新しいノードごとに参考情報を記入します。

    この表は、アップグレード手順を実行するときに参照します。

    node_A_1 - 古い

    node_A_1 - 新規

    LIF

    ポート

    IPspace

    ブロードキャストドメイン

    ポート

    IPspace

    ブロードキャストドメイン

    クラスタ 1

    クラスタ 2

    クラスタ 3

    クラスタ 4

    ノード管理

    クラスタ管理

    データ 1

    データ 2.

    データ 3

    データ 4.

    SAN

    クラスタ間ポート

新しいコントローラのネットブート

新しいノードを設置したら、ネットブートを実行して、新しいノードが元のノードと同じバージョンの ONTAP を実行するようにする必要があります。ネットブートという用語は、リモート・サーバに保存された ONTAP イメージからブートすることを意味します。ネットブートの準備を行うときは、システムがアクセスできる Web サーバに、 ONTAP 9 ブート・イメージのコピーを配置する必要があります。

手順
  1. 新しいコントローラをネットブートします。

    1. にアクセスします "ネットアップサポートサイト" システムのネットブートの実行に使用するファイルをダウンロードするには、次の手順を実行します。

    2. ネットアップサポートサイトのソフトウェアダウンロードセクションから適切な ONTAP ソフトウェアをダウンロードし、「 ONTAP-version _image.tgz 」ファイルを Web にアクセスできるディレクトリに保存します。

    3. Web にアクセスできるディレクトリに移動し、必要なファイルが利用可能であることを確認します。

      プラットフォームモデル

      作業

      FAS/AFF8000 シリーズシステム

      __ontap -version ___image.tgz 」ファイルの内容をターゲットディレクトリに展開します。

      「 tar -zxvf_ontap - version _image.tgz 」にあります

      注記 Windows で内容を展開する場合は、 7-Zip または WinRAR を使用してネットブートイメージを展開します。ディレクトリの一覧に、カーネルファイル netboot/ kernel を含むネットブートフォルダが表示される必要があります

      ディレクトリの一覧に、カーネルファイルを含むネットブートフォルダが含まれるようにします。

      netboot/ カーネル

      その他すべてのシステム

      ディレクトリの一覧に、カーネルファイルを含むネットブートフォルダが含まれるようにします。

      `_ontap - version_image.tgz

      「 _ONTAP-version_image.tgz 」ファイルを抽出する必要はありません。

    4. LOADER プロンプトで、管理 LIF のネットブート接続を設定します。

      IP アドレス

      作業

      DHCP

      自動接続を設定します。

      ifconfig e0M -auto

      静的

      手動接続を設定します。

      ifconfig e0M -addr= ip_addr-mask= netmask _ -gw= _gateway`

    5. ネットブートを実行します。

      プラットフォームモデル

      作業

      FAS/AFF8000 シリーズシステム

      ネットブート http://web_server_ip/path_to_web-accessible_directory/netboot/kernel`[]

      その他すべてのシステム

      netboot\http://_web_server_ip/path_to_web-accessible_directory/ontap-version_image.tgz`

    6. ブートメニューからオプション (7) Install new software first を選択して、新しいソフトウェアイメージをダウンロードし、ブートデバイスにインストールします。

      次のメッセージは無視してください。

    「この手順は、 HA ペアでの無停止アップグレードではサポートされていません」というメッセージが表示されます。IT 環境:ソフトウェアの無停止アップグレード。コントローラのアップグレードは対象外。

    1. 手順を続行するかどうかを確認するメッセージが表示されたら 'y' と入力し ' パッケージの入力を求められたら ' イメージ・ファイルの URL を入力します

      http://web_server_ip/path_to_web-accessible_directory/ontap-version_image.tgz`

    2. 必要に応じてユーザ名とパスワードを入力するか、 Enter キーを押して続行します。

    3. 次のようなプロンプトが表示されたら 'n' を入力してバックアップ・リカバリをスキップしてください

      Do you want to restore the backup configuration now? {y|n} **n**
    4. 次のようなプロンプトが表示されたら 'y' を入力して再起動します

      The node must be rebooted to start using the newly installed software. Do you want to reboot now? {y|n}

コントローラモジュールでの設定の消去

MetroCluster 構成で新しいコントローラモジュールを使用する前に、既存の構成をクリアする必要があります。

手順
  1. 必要に応じて、ノードを停止して LOADER プロンプトを表示します。

    「 halt 」

  2. LOADER プロンプトで、環境変数をデフォルト値に設定します。

    「デフォルト設定」

  3. 環境を保存します。

    'aveenv

  4. LOADER プロンプトで、ブートメニューを起動します。

    「 boot_ontap menu

  5. ブートメニューのプロンプトで、設定を消去します。

    wipeconfig

    確認プロンプトに「 yes 」と応答します。

    ノードがリブートし、もう一度ブートメニューが表示されます。

  6. ブートメニューでオプション * 5 * を選択し、システムをメンテナンスモードでブートします。

    確認プロンプトに「 yes 」と応答します。

サイトのアップグレード前の MetroCluster の健全性の確認

アップグレードを実行する前に、 MetroCluster 構成の健全性と接続を確認する必要があります。

手順
  1. ONTAP で MetroCluster 構成の動作を確認します。

    1. ノードがマルチパスであるかどうかを確認します。 +node run -node node_name sysconfig -a

      このコマンドは、 MetroCluster 構成のノードごとに問題で実行する必要があります。

    2. 「 storage disk show -broken 」の構成に破損ディスクがないことを確認してください

      このコマンドは、 MetroCluster 構成の各ノードで問題を実行する必要があります。

    3. ヘルスアラートがないかどうかを確認します。

      「 system health alert show 」というメッセージが表示されます

      このコマンドは、各クラスタで問題を実行する必要があります。

    4. クラスタのライセンスを確認します。

      「 system license show 」を参照してください

      このコマンドは、各クラスタで問題を実行する必要があります。

    5. ノードに接続されているデバイスを確認します。

      「 network device-discovery show 」のように表示されます

      このコマンドは、各クラスタで問題を実行する必要があります。

    6. 両方のサイトでタイムゾーンと時間が正しく設定されていることを確認します。

      cluster date show

    このコマンドは、各クラスタで問題を実行する必要があります。時刻とタイムゾーンを設定するには 'cluster date コマンドを使用します

  2. MetroCluster 構成の運用モードを確認し、 MetroCluster チェックを実行

    1. MetroCluster の構成と動作モードが「 normal 」であることを確認します。 + MetroCluster show

    2. 想定されるすべてのノードが表示されることを確認します。 + MetroCluster node show `

    3. 次のコマンドを問題に設定します。

      「 MetroCluster check run 」のようになります

    4. MetroCluster チェックの結果を表示します。

      MetroCluster チェックショー

  3. Config Advisor ツールを使用して MetroCluster のケーブル接続を確認します。

    1. Config Advisor をダウンロードして実行します。

    2. Config Advisor の実行後、ツールの出力を確認し、推奨される方法で検出された問題に対処します。

アップグレード前に情報を収集

アップグレードの開始前に各ノードについて情報を収集し、必要に応じてネットワークブロードキャストドメインを調整し、 VLAN やインターフェイスグループを削除して、暗号化情報を収集する必要があります。

手順
  1. 各ノードの物理的なケーブル接続をメモし、必要に応じてケーブルにラベルを付けて新しいノードを正しくケーブル接続できるようにします。

  2. 各ノードについて、インターコネクト、ポート、および LIF の情報を収集します。

    ノードごとに次のコマンドの出力を収集する必要があります。

    • MetroCluster interconnect show

    • 「 MetroCluster configurion-settings connection show 」を参照してください

    • 'network interface show -role cluster, node-mgmt

    • network port show -node node_name -type physical

    • 'network port vlan show -node -node-name _`

    • 「 network port ifgrp show -node node_name 」 - instance 」を指定します

    • 「 network port broadcast-domain show 」

    • 「 network port reachability show-detail` 」と表示されます

    • network ipspace show

    • volume show

    • 「 storage aggregate show

    • 「 system node run -node _node-name_sysconfig -a 」のように入力します

    • 「 vserver fcp initiator show 」のように表示されます

    • 「 storage disk show 」を参照してください

    • 「 MetroCluster configurion-settings interface show 」を参照してください

  3. site_B (プラットフォームを現在アップグレード中のサイト)の UUID を収集します。

    MetroCluster node show -fields node-cluster.uuid 、 node-uuid

    アップグレードを正常に実行するには、新しい site_B のコントローラモジュールでこれらの値を正確に設定する必要があります。あとでアップグレードプロセスの適切なコマンドに値をコピーできるように、ファイルに値をコピーします。

    次の例は、 UUID を指定したコマンドの出力を示しています。

    cluster_B::> metrocluster node show -fields node-cluster-uuid, node-uuid
      (metrocluster node show)
    dr-group-id cluster     node   node-uuid                            node-cluster-uuid
    ----------- --------- -------- ------------------------------------ ------------------------------
    1           cluster_A node_A_1 f03cb63c-9a7e-11e7-b68b-00a098908039 ee7db9d5-9a82-11e7-b68b-00a098908039
    1           cluster_A node_A_2 aa9a7a7a-9a81-11e7-a4e9-00a098908c35 ee7db9d5-9a82-11e7-b68b-00a098908039
    1           cluster_B node_B_1 f37b240b-9ac1-11e7-9b42-00a098c9e55d 07958819-9ac6-11e7-9b42-00a098c9e55d
    1           cluster_B node_B_2 bf8e3f8f-9ac4-11e7-bd4e-00a098ca379f 07958819-9ac6-11e7-9b42-00a098c9e55d
    4 entries were displayed.
    cluster_B::*

    UUID を次のようなテーブルに記録することを推奨します。

    クラスタまたはノード

    UUID

    cluster_B

    07958819 - 9ac6-11e7-9b42 - 00a098c9e55d

    node_B_1

    f37b240b-9ac1-11e7-9b42 -00a098c9e55d

    node_B_2

    bf8e3f8f-9ac4-117-bd4e-00a098c379f です

    cluster_A

    ee7db9d5-9a82-11e7-b68b-00a098908039

    node_A_1

    f03cb63c-9a7e-11e7-b68b-00a098908039

    Node_a_2

    aa9a7a7a1-9a81-11e7-a4e9-00a098908c35

  4. MetroCluster ノードが SAN 構成になっている場合は、関連情報を収集します。

    次のコマンドの出力を収集する必要があります。

    • 「 fcp adapter show -instance 」のように表示されます

    • 「 fcp interface show -instance 」の略

    • 「 iscsi interface show 」と表示されます

    • ucadmin show

  5. ルートボリュームが暗号化されている場合は、 key-manager に使用するパスフレーズを収集して保存します。

    「 securitykey-manager backup show 」を参照してください

  6. MetroCluster ノードがボリュームまたはアグリゲートに暗号化を使用している場合は、キーとパスフレーズに関する情報をコピーします。

    追加情報の場合は、を参照してください "オンボードキー管理情報の手動でのバックアップ"

    1. オンボード・キー・マネージャが構成されている場合: +'securitykey-manager onboard show-backup

      パスフレーズは、あとでアップグレード手順で必要になります。

    2. Enterprise Key Management ( KMIP )が設定されている場合は、次のコマンドを問題で実行します。

      「 securitykey manager external show -instance 」 'ecurity key manager key query 」を参照してください

  7. 既存のノードのシステム ID を収集します。

    「 MetroCluster node show -fields node-systemid 、 ha-partner-systemid 、 dr-partner-systemid 、 dr-auxiliary-systemid 」を指定します

    次の出力は、再割り当てされたドライブを示しています。

    ::> metrocluster node show -fields node-systemid,ha-partner-systemid,dr-partner-systemid,dr-auxiliary-systemid
    
    dr-group-id cluster     node     node-systemid ha-partner-systemid dr-partner-systemid dr-auxiliary-systemid
    ----------- ----------- -------- ------------- ------------------- ------------------- ---------------------
    1           cluster_A node_A_1   537403324     537403323           537403321           537403322
    1           cluster_A node_A_2   537403323     537403324           537403322           537403321
    1           cluster_B node_B_1   537403322     537403321           537403323           537403324
    1           cluster_B node_B_2   537403321     537403322           537403324           537403323
    4 entries were displayed.

メディエーターまたは Tiebreaker の監視を削除しています

プラットフォームをアップグレードする前に、 MetroCluster 設定を Tiebreaker またはメディエーターユーティリティで監視している場合は、監視を解除する必要があります。

手順
  1. 次のコマンドの出力を収集します。

    「 storage iscsi-initiator show 」のように表示されます

  2. Tiebreaker 、メディエーター、またはスイッチオーバーを開始できるその他のソフトウェアから既存の MetroCluster 構成を削除します。

    使用するポート

    使用する手順

    Tiebreaker

    "MetroCluster 設定の削除" MetroCluster Tiebreaker インストールおよび設定ガイドのを参照してください

    メディエーター

    ONTAP プロンプトで次のコマンドを問題に設定します。

    MetroCluster 構成設定のメディエーターが削除されました

    サードパーティ製アプリケーション

    製品マニュアルを参照してください。

カスタム AutoSupport メッセージをメンテナンス前に送信する

メンテナンスを実行する前に、 AutoSupport an 問題 message to notify NetApp technical support that maintenance is maintenancing (メンテナンスが進行中であることをネットアップテクニカルサポートに通知する)を実行システム停止が発生したとみなしてテクニカルサポートがケースをオープンしないように、メンテナンスが進行中であることを通知する必要があります。

このタスクは MetroCluster サイトごとに実行する必要があります。

手順
  1. クラスタにログインします。

  2. メンテナンスの開始を通知する AutoSupport メッセージを起動します。

    「 system node AutoSupport invoke -node * -type all -message MAINT= maintenance-window-in-hours 」というメッセージが表示されます

    「 maintenance-window-in-hours 」パラメータには、メンテナンス時間の長さを最大 72 時間指定します。この時間が経過する前にメンテナンスが完了した場合は、メンテナンス期間が終了したことを通知する AutoSupport メッセージを起動できます。

    「 system node AutoSupport invoke -node * -type all -message MAINT= end 」というメッセージが表示されます

  3. 同じ手順をパートナーサイトでも実行します。

MetroCluster 設定をスイッチオーバーしています

site_B のプラットフォームをアップグレードできるように、設定を site_A にスイッチオーバーする必要があります。

このタスクは site_A で実行する必要があります

このタスクを完了すると、 cluster_A はアクティブになり、両方のサイトでデータを提供します。cluster_B が非アクティブで、アップグレードプロセスを開始できる状態です。

MCC アップグレードで、クラスタ A をスイッチオーバーします
手順
  1. site_B のノードをアップグレードできるように、 MetroCluster 構成を site_A にスイッチオーバーします。

    1. cluster_A で次のコマンドを問題します。

      MetroCluster switche-controller-replacement true

      この処理が完了するまでに数分かかることがあります。

    2. スイッチオーバー処理を監視します。

      「 MetroCluster operation show 」を参照してください

    3. 処理が完了したら、ノードがスイッチオーバー状態であることを確認します。

      「 MetroCluster show 」

    4. MetroCluster ノードのステータスを確認します。

      MetroCluster node show

    コントローラのアップグレード中は、ネゴシエートスイッチオーバー後のアグリゲートの自動修復が無効になります。

インターフェイス設定を削除し、古いコントローラをアンインストールします

データ LIF を共通ポートに移動して古いコントローラの VLAN やインターフェイスグループを削除し、コントローラを物理的にアンインストールする必要があります。

このタスクについて
手順
  1. 古いノードをブートして、ノードにログインします。

    「 boot_ontap 」

  2. 古いコントローラのすべてのデータ LIF のホームポートを、新旧両方のコントローラモジュールで同じ共通ポートに割り当てます。

    1. LIF を表示します。

      「 network interface show 」を参照してください

      SAN と NAS を含むすべてのデータ LIF は、スイッチオーバーサイト( cluster_A )で稼働しているため、管理上および運用上のダウン状態になります。

    2. の出力を確認して、クラスタポートとして使用されていない新旧両方のコントローラで同じ共通の物理ネットワークポートを特定します。

      たとえば、 e0d は古いコントローラの物理ポートで、新しいコントローラにも存在します。e0d は、クラスタポート、または新しいコントローラ上で使用されません。

      プラットフォームモデルのポートの用途については、を参照してください "NetApp Hardware Universe の略"

    3. すべてのデータ LIF で共通のポートをホームポートとして使用するように変更します。 +network interface modify -vserver svm -name ___-lif data_-lif LIF_name -home-node port_id

      次の例では、これは「 e0d 」です。

      例:

    network interface modify -vserver vs0 -lif datalif1 -home-port e0d
  3. クラスタポートをメンバーポートとして使用し、 ifgrp をメンバーポートとして使用している VLAN ポートを削除します。

    1. VLAN ポートを削除します。 +network port vlan delete -node_node-name _ vlan-name_portid -vlandid

      例:

      network port vlan delete -node node1 -vlan-name e1c-80
    2. インターフェイスグループから物理ポートを削除します。

      「 network port ifgrp remove-port -node-node_name -ifgrp_interface-group-name _ port_portid 」の形式で指定します

      例:

    network port ifgrp remove-port -node node1 -ifgrp a1a -port e0d
    1. ブロードキャストドメインから VLAN ポートとインターフェイスグループポートを削除します。

      'network port broadcast-domain remove-ports -ipspace_ipspace -broadcast-domain_domain-name_ports_nodename : portname 、 nodename : portname _ 、

    2. 必要に応じて、他の物理ポートをメンバーとして使用するようにインターフェイスグループポートを変更します。

      ifgrp add-port -node node_name -ifgrp interface -group-name_port_port-id`

  4. ノードを停止して LOADER プロンプトを表示します。

    「 halt -inhibit-takeover true 」と入力します

  5. site_B の古いコントローラのシリアルコンソール( node_B_1 古いコントローラと node_B_2 古いコントローラ)に接続し、 LOADER プロンプトが表示されていることを確認します。

  6. bootarg の値を収集します。

    printenv

  7. node_B_1 古いと node_B_2 のストレージ接続とネットワーク接続を切断し、新しいノードに再接続できるようにケーブルにラベルを付けます。

  8. node_B_1 から古いおよび node_B_2 から電源ケーブルを外します。

  9. node_B_1 古いコントローラと node_B_2 の古いコントローラをラックから取り外します。

新しいプラットフォームに対応するためのスイッチ RCF の更新

スイッチは、新しいプラットフォームモデルをサポートする構成に更新する必要があります。

このタスクは、現在アップグレード中のコントローラを含むサイトで実行します。この手順の例では、まず site_B をアップグレードします。

site_A のコントローラをアップグレードすると、 site_A のスイッチがアップグレードされます。

手順
  1. 新しい RCF ファイルを適用するための IP スイッチを準備します。

    使用しているスイッチベンダーに対応する手順については、 MetroCluster IP インストールおよび設定ガイドを参照してください。

  2. RCF ファイルをダウンロードしてインストールします。

    使用しているスイッチベンダーに対応する手順については、を参照してください "MetroCluster IP のインストールと設定"

新しいコントローラを設定します

コントローラをラックに設置して設置し、メンテナンスモードで必要なセットアップを実行してから、コントローラをブートし、コントローラの LIF の設定を確認する必要があります。

新しいコントローラをセットアップする

新しいコントローラをラックに設置してケーブルを接続する必要があります。

手順
  1. 必要に応じて、新しいコントローラモジュールとストレージシェルフの配置を計画します。

    ラックスペースは、コントローラモジュールのプラットフォームモデル、スイッチのタイプ、構成内のストレージシェルフ数によって異なります。

  2. 自身の適切な接地対策を行います

  3. コントローラモジュールをラックまたはキャビネットに設置します。

  4. MetroCluster IP インストールおよび設定ガイドの説明に従って、コントローラを IP スイッチにケーブル接続します。

  5. 新しいノードの電源をオンにして、メンテナンスモードでブートします。

HBA 構成をリストアしています

コントローラモジュールに HBA カードが搭載されているかどうかや設定によっては、サイトで使用するために正しく設定する必要があります。

手順
  1. メンテナンスモードで、システム内の HBA の設定を行います。

    1. ポートの現在の設定を確認します。

      ucadmin show

    2. 必要に応じてポートの設定を更新します。

    HBA のタイプと目的のモード

    使用するコマンド

    CNA FC

    ucadmin modify -m fc -t initiator_adapter-name _ `

    CNA イーサネット

    ucadmin modify -mode cna_adapter-name_`

    FC ターゲット

    fcadmin config -t target_adapter-name_`

    FC イニシエータ

    fcadmin config -t initiator_adapter-name_`

  2. メンテナンスモードを終了します。

    「 halt 」

    コマンドの実行後、ノードが LOADER プロンプトで停止するまで待ちます。

  3. ノードをブートしてメンテナンスモードに戻り、設定の変更が反映されるようにします。

    「 boot_ontap maint 」を使用してください

  4. 変更内容を確認します。

    HBA のタイプ

    使用するコマンド

    CNA

    ucadmin show

    FC

    fcadmin show`

新しいコントローラとシャーシで HA 状態を設定

コントローラとシャーシの HA 状態を確認し、必要に応じてシステム構成に合わせて更新する必要があります。

手順
  1. メンテナンスモードで、コントローラモジュールとシャーシの HA 状態を表示します。

    「 ha-config show 」

    すべてのコンポーネントの HA の状態が「 mccip 」である必要があります。

  2. 表示されたコントローラまたはシャーシのシステム状態が正しくない場合は、 HA 状態を設定します。

    「 ha-config modify controller mccip 」を参照してください

    「 ha-config modify chassis mccip 」を参照してください

MetroCluster の bootarg IP 変数の設定

新しいコントローラモジュールには特定の MetroCluster IP bootarg 値を設定する必要があります。これらの値は、古いコントローラモジュールに設定されている値と一致する必要があります。

このタスクでは、のアップグレード手順で前述した UUID とシステム ID を使用します "アップグレード前に情報を収集"

手順
  1. アップグレード対象のノードが AFF A400 、 FAS8300 、 FAS8700 のいずれかのモデルの場合は、 LOADER プロンプトで次の bootarg を設定します。

    'etenvarge.MCC.port_a_ip_config_local-ip-address/local-ip-mask'0 、 ha-partner-ip-address 、 dr-partner-ip-address 、 dr-aux-partnerip-address 、 vlan-id_`

    「 etenvarge.MCC.port_b_ip_config_local-ip-address/local-ip-mask, 0,ha-partner-ip-address 、 dr-partner-ip-address 、 dr-aux-partnerip-address 、 vlan-id_` 」を指定します

    注記 インターフェイスがデフォルトの VLAN を使用している場合、 vlan-id は不要です。

    次のコマンドは、最初のネットワークに VLAN 120 を、 2 番目のネットワークに VLAN 130 を使用して、 node_B_1 の新しい値を設定します。

    setenv bootarg.mcc.port_a_ip_config 172.17.26.10/23,0,172.17.26.11,172.17.26.13,172.17.26.12,120
    setenv bootarg.mcc.port_b_ip_config 172.17.27.10/23,0,172.17.27.11,172.17.27.13,172.17.27.12,130

    次のコマンドは、最初のネットワークに VLAN 120 を、 2 番目のネットワークに VLAN 130 を使用して、 node_B_2 の値を設定します。

    setenv bootarg.mcc.port_a_ip_config 172.17.26.11/23,0,172.17.26.10,172.17.26.12,172.17.26.13,120
    setenv bootarg.mcc.port_b_ip_config 172.17.27.11/23,0,172.17.27.10,172.17.27.12,172.17.27.13,130

    次の例は、デフォルトの VLAN を使用している場合の node_B_1 に対するコマンドを示しています。

    setenv bootarg.mcc.port_a_ip_config 172.17.26.10/23,0,172.17.26.11,172.17.26.13,172.17.26.12
    setenv bootarg.mcc.port_b_ip_config 172.17.27.10/23,0,172.17.27.11,172.17.27.13,172.17.27.12

    次の例は、デフォルトの VLAN を使用している場合の node_B_2 に対するコマンドを示しています。

    setenv bootarg.mcc.port_a_ip_config 172.17.26.11/23,0,172.17.26.10,172.17.26.12,172.17.26.13
    setenv bootarg.mcc.port_b_ip_config 172.17.27.11/23,0,172.17.27.10,172.17.27.12,172.17.27.13
  2. アップグレード対象のノードが前の手順でリストされていない場合は、各サバイバーノードの LOADER プロンプトで「 local_IP/mask 」で次の bootargs を設定します。

    'etenvarge.MCC.port_a_ip_config_local-ip-address/local-ip-mask'0 、 ha-partner-ip-address 、 dr-partner ip-address 、 dr-aux-partnerip-address 、 dr-aux-aux-partnerip-address

    'etenvarge.MCC.port_b_ip_config_local-ip-address/local-ip-mask'0 、 ha-partner-ip-address 、 dr-partner-ip-address 、 dr-aux-partnerip-address 、 dr-aux-aux-partnerip-address

    次のコマンドは、 node_B_1 について新しい値を設定します。

    setenv bootarg.mcc.port_a_ip_config 172.17.26.10/23,0,172.17.26.11,172.17.26.13,172.17.26.12
    setenv bootarg.mcc.port_b_ip_config 172.17.27.10/23,0,172.17.27.11,172.17.27.13,172.17.27.12

    次のコマンドは、 node_B_2 の値を設定します。

    setenv bootarg.mcc.port_a_ip_config 172.17.26.11/23,0,172.17.26.10,172.17.26.12,172.17.26.13
    setenv bootarg.mcc.port_b_ip_config 172.17.27.11/23,0,172.17.27.10,172.17.27.12,172.17.27.13
  3. 新しいノードの LOADER プロンプトで、 UUID を設定します。

    「 etenv bootarg.mgwd.partner_uuid_partner -cluster-UUID_` 」と入力します

    「 etenv bootarg.mgwd.cluster_ue_local-cluster-UUID_` 」と入力します

    「 etenv bootarge.MCC.pri_partner_uuid_dr-partner -node-UUID_` 」と入力します

    'etenv bootarg.mcc.aux_partner_uuid dr-au-partner -UUID`

    「 etenv bootarg.mcc_iscsi.node_uuid local-node-UUID` 」と入力します

    1. node_B_1 で UUID を設定します。

      次の例は、 node_B_1 で新規の UUID を設定するコマンドを示しています。

      setenv bootarg.mgwd.cluster_uuid ee7db9d5-9a82-11e7-b68b-00a098908039
      setenv bootarg.mgwd.partner_cluster_uuid 07958819-9ac6-11e7-9b42-00a098c9e55d
      setenv bootarg.mcc.pri_partner_uuid f37b240b-9ac1-11e7-9b42-00a098c9e55d
      setenv bootarg.mcc.aux_partner_uuid bf8e3f8f-9ac4-11e7-bd4e-00a098ca379f
      setenv bootarg.mcc_iscsi.node_uuid f03cb63c-9a7e-11e7-b68b-00a098908039
    2. node_B_2 の UUID を設定します。 new :

      次の例は、 node_B_2 の UUID を設定するコマンドを示しています。

    setenv bootarg.mgwd.cluster_uuid ee7db9d5-9a82-11e7-b68b-00a098908039
    setenv bootarg.mgwd.partner_cluster_uuid 07958819-9ac6-11e7-9b42-00a098c9e55d
    setenv bootarg.mcc.pri_partner_uuid bf8e3f8f-9ac4-11e7-bd4e-00a098ca379f
    setenv bootarg.mcc.aux_partner_uuid f37b240b-9ac1-11e7-9b42-00a098c9e55d
    setenv bootarg.mcc_iscsi.node_uuid aa9a7a7a-9a81-11e7-a4e9-00a098908c35
  4. 元のシステムが ADP 用に設定されていた場合は、交換用ノードの LOADER プロンプトで ADP を有効にします。

    'etenv bootarg.me.adp_enabled true

  5. 次の変数を設定します。

    「 etenv bootarg.me.local_config_id_original-sys-sys-id_` 」を返します

    「 etenv bootarge.MCC.DR_PARTNER_DR-partner -sys-id_` 」を選択します

    注記 「 bootarg env.MCC.local_config_id` 」変数は、 * 元の * コントローラモジュール node_B_1 の sys-id に設定する必要があります。
    1. node_B_1 で変数を設定します。

      次の例は、 node_B_1 で新規の値を設定するコマンドを示しています。

      setenv bootarg.mcc.local_config_id 537403322
      setenv bootarg.mcc.dr_partner 537403324
    2. node_B_2 の変数を設定します。

      次の例は、 node_B_2 の値を設定するコマンドを示しています。

    setenv bootarg.mcc.local_config_id 537403321
    setenv bootarg.mcc.dr_partner 537403323
  6. 外部キー管理ツールで暗号化を使用する場合は、必要な bootargs を設定します。

    「 etenv bootarg.kmip.init.ipaddr` 」を参照してください

    「 etenv bootarg.kmip.kmip.init.netmask` 」を参照してください

    「 etenv bootarg.kmip.kmip.init.gateway` 」を参照してください

    「 etenv bootarg.kmip.kmip.init.interface` 」を参照してください

ルートアグリゲートディスクの再割り当て中です

前の手順で確認したシステム ID を使用して、ルートアグリゲートディスクを新しいコントローラモジュールに再割り当てします。

以下の手順はメンテナンスモードで実行します。

手順
  1. システムをメンテナンスモードでブートします。

    「 boot_ontap maint 」を使用してください

  2. メンテナンスモードのプロンプトから node_B_1 で新しいディスクを表示します。

    「ディスクショー - A` 」

    コマンド出力に、新しいコントローラモジュール( 1574774970 )のシステム ID が表示されます。ただし、ルートアグリゲートディスクの所有者は古いシステム ID ( 537403322 )になります。この例で表示されているのは、 MetroCluster 構成の他のノードが所有するドライブではありません。

    *> disk show -a
    Local System ID: 1574774970
    DISK                  OWNER                 POOL   SERIAL NUMBER   HOME                  DR HOME
    ------------          ---------             -----  -------------   -------------         -------------
    prod3-rk18:9.126L44   node_B_1-old(537403322)  Pool1  PZHYN0MD     node_B_1-old(537403322)  node_B_1-old(537403322)
    prod4-rk18:9.126L49   node_B_1-old(537403322)  Pool1  PPG3J5HA     node_B_1-old(537403322)  node_B_1-old(537403322)
    prod4-rk18:8.126L21   node_B_1-old(537403322)  Pool1  PZHTDSZD     node_B_1-old(537403322)  node_B_1-old(537403322)
    prod2-rk18:8.126L2    node_B_1-old(537403322)  Pool0  S0M1J2CF     node_B_1-old(537403322)  node_B_1-old(537403322)
    prod2-rk18:8.126L3    node_B_1-old(537403322)  Pool0  S0M0CQM5     node_B_1-old(537403322)  node_B_1-old(537403322)
    prod1-rk18:9.126L27   node_B_1-old(537403322)  Pool0  S0M1PSDW     node_B_1-old(537403322)  node_B_1-old(537403322)
    .
    .
    .
  3. ドライブシェルフのルートアグリゲートディスクを新しいコントローラに再割り当てします。

    ADP を使用する環境

    使用するコマンド

    はい。

    「ディスクの再割り当て -s old-sysid-d_new-sysid_-r_dr -partner sysid_`

    いいえ

    「ディスクの再割り当て -s old-sysid-d_new-sysid_`

  4. ドライブシェルフのルートアグリゲートディスクを新しいコントローラに再割り当てします。

    「ディスク再割り当て -s old-sysid -d new-sysid 」

    次の例は、 ADP 以外の構成でのドライブの再割り当てを示しています。

    *> disk reassign -s 537403322 -d 1574774970
    Partner node must not be in Takeover mode during disk reassignment from maintenance mode.
    Serious problems could result!!
    Do not proceed with reassignment if the partner is in takeover mode. Abort reassignment (y/n)? n
    
    After the node becomes operational, you must perform a takeover and giveback of the HA partner node to ensure disk reassignment is successful.
    Do you want to continue (y/n)? y
    Disk ownership will be updated on all disks previously belonging to Filer with sysid 537403322.
    Do you want to continue (y/n)? y
  5. ルートアグリゲートのディスクが正しく再割り当てされていることを確認します。 old-remove :

    「ディスクショー」

    「ストレージ・アグリゲートのステータス」

    *> disk show
    Local System ID: 537097247
    
      DISK                    OWNER                    POOL   SERIAL NUMBER   HOME                     DR HOME
    ------------              -------------            -----  -------------   -------------            -------------
    prod03-rk18:8.126L18 node_B_1-new(537097247)  Pool1  PZHYN0MD        node_B_1-new(537097247)   node_B_1-new(537097247)
    prod04-rk18:9.126L49 node_B_1-new(537097247)  Pool1  PPG3J5HA        node_B_1-new(537097247)   node_B_1-new(537097247)
    prod04-rk18:8.126L21 node_B_1-new(537097247)  Pool1  PZHTDSZD        node_B_1-new(537097247)   node_B_1-new(537097247)
    prod02-rk18:8.126L2  node_B_1-new(537097247)  Pool0  S0M1J2CF        node_B_1-new(537097247)   node_B_1-new(537097247)
    prod02-rk18:9.126L29 node_B_1-new(537097247)  Pool0  S0M0CQM5        node_B_1-new(537097247)   node_B_1-new(537097247)
    prod01-rk18:8.126L1  node_B_1-new(537097247)  Pool0  S0M1PSDW        node_B_1-new(537097247)   node_B_1-new(537097247)
    ::>
    ::> aggr status
               Aggr          State           Status                Options
    aggr0_node_B_1           online          raid_dp, aggr         root, nosnap=on,
                                             mirrored              mirror_resync_priority=high(fixed)
                                             fast zeroed
                                             64-bit

新しいコントローラのブート

新しいコントローラをブートする必要があります。 bootarg 変数が正しいことを確認し、必要に応じて暗号化のリカバリ手順を実行するように注意してください。

手順
  1. 新しいノードを停止します。

    「 halt 」

  2. 外部キー管理ツールが設定されている場合は、関連する bootargs を設定します。

    'setenv bootarg.kmip.init.ipaddr ip-address'

    'setenv bootarg.kmip.init.netmask netmask`

    'setenv bootarg.kmip.init.gateway gateway-address

    'setenv bootarg.kmip.init.interface interface-id

  3. partner-sysid が現在のものかどうかを確認します。

    printenv partner-sysid

    partner-sysid が正しくない場合は、次のように設定します。

    'setenv partner-sysid_partner-SysID_`

  4. ONTAP ブートメニューを表示します。

    「 boot_ontap menu

  5. ルート暗号化を使用問題する場合は、キー管理設定の boot menu コマンドを使用します。

    使用するポート

    問題ブートメニュープロンプトでのコマンド

    オンボードキー管理

    「 recover _onboard keymanager 」を参照してください

    外部キー管理

    「 RE_EXTERNAL_KEYmanager 」と入力します

  6. 起動メニューから「 (6) Update flash from backup config 」を選択します。

    注記 オプション 6 を指定すると、完了前にノードが 2 回リブートされます

    システム ID 変更プロンプトに「 y 」と入力します。2 回目のリブートメッセージが表示されるまで待ちます。

    Successfully restored env file from boot media...
    
    Rebooting to load the restored env file...
  7. LOADER で、 bootarg の値を確認し、必要に応じて値を更新します。

    の手順を使用します "MetroCluster の bootarg IP 変数の設定"

  8. partner-sysid が正しいことを確認します。

    printenv partner-sysid

    partner-sysid が正しくない場合は、次のように設定します。

    'setenv partner-sysid_partner-SysID_`

  9. ルート暗号化を使用する場合は、キー管理設定の boot menu コマンドを再度問題に実行します。

    使用するポート

    問題ブートメニュープロンプトでのコマンド

    オンボードキー管理

    「 recover _onboard keymanager 」を参照してください

    外部キー管理

    「 RE_EXTERNAL_KEYmanager 」と入力します

    ノードが完全に起動するまで、ブートメニュープロンプトで「 re cover _xxxxxxxx_keymanager 」コマンドとオプション 6 を何度か問題する必要がある場合があります。

  10. 交換したノードがブートするまで待ちます。

    いずれかのノードがテイクオーバーモードの場合は、「 storage failover giveback 」コマンドを使用してギブバックを実行します。

  11. 暗号化を使用する場合は、キー管理設定に対応したコマンドを使用してキーをリストアします。

    使用するポート

    使用するコマンド

    オンボードキー管理

    「セキュリティキーマネージャオンボード同期」

    詳細については、を参照してください "オンボードキー管理の暗号化キーのリストア"

    外部キー管理

    「 securitykey manager external restore -vserver svm-node __ key -server_host_name

  12. すべてのポートがブロードキャストドメインに属していることを確認します。

    1. ブロードキャストドメインを表示します。

      「 network port broadcast-domain show 」

    2. 必要に応じて、ブロードキャストドメインにポートを追加します。

    3. 必要に応じて、 VLAN とインターフェイスグループを再作成します。

      VLAN およびインターフェイスグループのメンバーシップは、古いノードと異なる場合があります。

LIF の設定を確認およびリストアする

アップグレード手順の開始時にマッピングされた適切なノードとポートで LIF がホストされていることを確認します。

この tsak について
手順
  1. スイッチバックの前に、 LIF が適切なノードとポートにホストされていることを確認します。

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

      「 advanced 」の権限が必要です

    2. ポート設定を無視して LIF が適切に配置されるようにします。

      「 vserver config override command 」 network interface modify -vserver vserver_name __ -home-node _active_port_after_upgrade _ -lif LIF_name -home-node _new_node_name _

    vserver config override コマンドで network interface modify コマンドを入力した場合は、 tab autoccomplete 機能を使用することはできません。autoccomplete を使用してネットワーク 'interface modify' を作成してから 'vserver config override' コマンドで囲むことができます

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

      「特権管理者」

  2. インターフェイスをホームノードにリバートします。

    「 network interface revert * -vserver_vserver-name に指定します

    必要に応じて、すべての SVM でこの手順を実行します。

MetroCluster 設定を元に戻します

このタスクでは、スイッチバック処理を実行し、 MetroCluster 構成が通常運用時の状態に戻ります。site_A のノードはまだアップグレード待ちです。

MCC アップグレードクラスタ A のスイッチバック
手順
  1. site_B の MetroCluster node show コマンドを問題し ' 出力を確認します

    1. 新しいノードが正しく表示されることを確認します。

    2. 新しいノードの状態が「 Waiting for switchback 」であることを確認します。

  2. アクティブなクラスタ(アップグレードを実行していないクラスタ)の任意のノードから必要なコマンドを実行して、修復とスイッチバックを実行します。

    1. データアグリゲートを修復します。 + MetroCluster heal aggregates `

    2. ルートアグリゲートを修復します。

      MetroCluster はルートを修復します

    3. クラスタをスイッチバックします。

      MetroCluster スイッチバック

  3. スイッチバック処理の進捗を確認します。

    「 MetroCluster show 」

    出力に「 waiting-for-switchback 」と表示されたら、スイッチバック処理はまだ進行中です。

    cluster_B::> metrocluster show
    Cluster                   Entry Name          State
    ------------------------- ------------------- -----------
     Local: cluster_B         Configuration state configured
                              Mode                switchover
                              AUSO Failure Domain -
    Remote: cluster_A         Configuration state configured
                              Mode                waiting-for-switchback
                              AUSO Failure Domain -

    出力に normal と表示された場合、スイッチバック処理は完了しています。

    cluster_B::> metrocluster show
    Cluster                   Entry Name          State
    ------------------------- ------------------- -----------
     Local: cluster_B         Configuration state configured
                              Mode                normal
                              AUSO Failure Domain -
    Remote: cluster_A         Configuration state configured
                              Mode                normal
                              AUSO Failure Domain -

    スイッチバックが完了するまでに時間がかかる場合は、「 MetroCluster config-replication resync-status show 」コマンドを使用することで、進行中のベースラインのステータスを確認できます。このコマンドは、 advanced 権限レベルで実行します。

MetroCluster 構成の健常性を確認しています

コントローラモジュールをアップグレードしたら、 MetroCluster 構成の健全性を確認する必要があります。

このタスクは、 MetroCluster 構成の任意のノードで実行できます。

手順
  1. MetroCluster 構成の動作を確認します。

    1. MetroCluster 構成と動作モードが正常であることを確認します。 + MetroCluster show `

    2. MetroCluster チェックを実行します + MetroCluster チェックを実行します

    3. MetroCluster チェックの結果を表示します。

      MetroCluster チェックショー

  2. MetroCluster の接続およびステータスを確認します。

    1. MetroCluster IP 接続を確認します。

      「 storage iscsi-initiator show 」のように表示されます

    2. ノードが動作していることを確認します。

      MetroCluster node show

    3. MetroCluster IP インターフェイスが動作していることを確認します。

      「 MetroCluster configurion-settings interface show 」を参照してください

    4. ローカルフェイルオーバーが有効になっていることを確認します。

      「 storage failover show 」をクリックします

cluster_A のノードをアップグレードします

cluster_A についてもアップグレード手順を繰り返す必要があります

手順
  1. 同じ手順を繰り返して、 cluster_A のノードをアップグレードします "アップグレードの準備を行います"

    タスクを実行すると、これらの例ではクラスタとノードをすべて逆に参照しています。たとえば、この例で cluster_A からスイッチオーバーすると、 cluster_B からスイッチオーバーされます

Tiebreaker またはメディエーターの監視をリストアしています

MetroCluster 構成のアップグレードが完了したら、 Tiebreaker またはメディエーターユーティリティを使用して監視を再開できます。

手順
  1. 必要に応じて、構成に応じて手順を使用してリストアを監視します。

    使用するポート この手順を使用します

    Tiebreaker

    "MetroCluster 構成を追加しています" MetroCluster Tiebreaker インストールおよび設定ガイドのを参照してください

    メディエーター

    "MetroCluster IP 構成での ONTAP メディエーターサービスの設定" MetroCluster IP インストールおよび設定ガイドのを参照してください

    サードパーティ製アプリケーション

    製品マニュアルを参照してください。

メンテナンス後にカスタム AutoSupport メッセージを送信する

アップグレードの完了後、ケースの自動作成を再開できるように、メンテナンスの終了を通知する AutoSupport メッセージを送信する必要があります。

手順
  1. サポートケースの自動生成を再開するには、メンテナンスが完了したことを示す AutoSupport メッセージを送信します。

    1. 次のコマンドを問題で実行します。 + 「 system node AutoSupport invoke -node * -type all -message MAINT= end 」

    2. パートナークラスタに対してこのコマンドを繰り返します。