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

4ノードまたは8ノードのMetroCluster IP構成を更新（ONTAP 9.8以降）

08/23/2024 共同作成者

PDF

この手順を使用して、4ノードまたは8ノード構成のコントローラとストレージをアップグレードできます。

ONTAP 9.13.1以降では、8ノードMetroCluster IP構成のコントローラとストレージをアップグレードできます。そのためには、構成を拡張して一時的に12ノード構成にし、古いディザスタリカバリ（DR）グループを削除します。

ONTAP 9.8以降では、4ノードMetroCluster IP構成のコントローラとストレージをアップグレードできます。そのためには、構成を拡張して一時的な8ノード構成にしてから、古いDRグループを削除します。

このタスクについて

8ノード構成の場合は、システムでONTAP 9.13.1以降が実行されている必要があります。
4ノード構成の場合は、システムでONTAP 9.8以降が実行されている必要があります。
IPスイッチもアップグレードする場合は、このリフレッシュ手順を実行する前にスイッチをアップグレードする必要があります。
この手順では、1つの4ノードDRグループを更新するために必要な手順について説明します。8ノード構成（DRグループが2つ）の場合は、一方または両方のDRグループを更新できます。

両方のDRグループを更新する場合は、一度に1つのDRグループを更新する必要があります。
「古いノード」とは、置き換えるノードを意味します。

8ノード構成では、ソースとターゲットの8ノードMetroCluster プラットフォームの組み合わせがサポートされている必要があります。

両方のDRグループを更新する場合、最初のDRグループを更新したあとにプラットフォームの組み合わせがサポートされないことがあります。サポートされる8ノード構成にするには、両方のDRグループを更新する必要があります。

MetroCluster IP構成では、この手順を使用して特定のプラットフォームモデルのみを更新できます。
- サポートされるプラットフォームのアップグレードの組み合わせについては、のMetroCluster IP更新テーブルを参照してください "システムの更新方法を選択する"。
ソースプラットフォームとターゲットプラットフォームの下限が適用されます。上位のプラットフォームに移行する場合は、すべてのDRグループの機器更改が完了するまで新しいプラットフォームの制限が適用されません。
ソースプラットフォームよりも制限が低いプラットフォームに対して機器更改を実行する場合は、この手順を実行する前に、ターゲットプラットフォームの制限に合わせて制限を調整し、制限をターゲットプラットフォームの制限以下にする必要があります。

コンソールログを有効にする

NetAppでは、使用しているデバイスでコンソールロギングをイネーブルにし、この手順を実行する際に次のアクションを実行することを強く推奨します。

メンテナンス中はAutoSupportを有効のままにします。
メンテナンスの前後にメンテナンスAutoSupportメッセージをトリガーして、メンテナンスアクティビティ中にケースの作成を無効にします。

ナレッジベースの記事を参照してください "スケジュールされたメンテナンス時間中にケースの自動作成を停止する方法"。
任意のCLIセッションのセッションロギングをイネーブルにします。セッションログを有効にする方法については、ナレッジベースの記事の「セッション出力のログ」セクションを参照してください "ONTAPシステムへの接続を最適化するためのPuTTYの設定方法"。

更新手順の実行

MetroCluster IP設定を更新するには、次の手順を実行します。

手順

古いノードにデフォルトのブロードキャストドメインが作成されていることを確認します。

デフォルトのブロードキャストドメインがない既存のクラスタに新しいノードを追加すると、想定される名前ではなくUniversal Unique Identifier（UUID）を使用して新しいノード用のノード管理LIFが作成されます。詳細については、技術情報アーティクルを参照してください "UUID名で生成された新しく追加されたノードのノード管理LIF"。
古いノードから情報を収集します。

この段階では、次の図に示すように 4 ノード構成が表示されます。

次の図のような8ノード構成が表示されます。
サポートケースが自動で生成されないようにするには、アップグレードが進行中であることを示す AutoSupport メッセージを送信します。
1. 次のコマンドを問題で実行します。 + 「 system node AutoSupport invoke -node * -type all -message 」 MAINT=10h Upgrading _old-model_To _new-model 」 _`
  
  次の例は、 10 時間のメンテナンス時間を指定します。プランによっては、さらに時間をかけたい場合もあります。
  
  この時間が経過する前にメンテナンスが完了した場合は、メンテナンス期間が終了したことを通知する AutoSupport メッセージを起動できます。
「 system node AutoSupport invoke -node * -type all -message MAINT= end 」というメッセージが表示されます
1. パートナークラスタに対してこのコマンドを繰り返します。
エンドツーエンドの暗号化が有効になっている場合は、次の手順を実行します。 "エンドツーエンドの暗号化を無効にする"。

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

使用するポート

使用する手順

Tiebreaker

MetroCluster 構成を削除するには 'Tiebreaker CLI の monitor remove コマンドを使用します

次の例では ' "cluster_a" がソフトウェアから削除されています
```
NetApp MetroCluster Tiebreaker :> monitor remove -monitor-name cluster_A
Successfully removed monitor from NetApp MetroCluster Tiebreaker
software.
```
Tiebreaker CLIを使用して、MetroCluster の設定が正しく削除されたことを確認します monitor show -status コマンドを実行します
```
NetApp MetroCluster Tiebreaker :> monitor show -status
```

メディエーター

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

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

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

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

のすべての手順を実行します "MetroCluster IP構成の拡張" をクリックして新しいノードとストレージを構成に追加してください。

拡張手順が完了すると、一時的な設定が次の図のように表示されます。

図 1. 8ノードの一時的な構成

図 2. 一時的な12ノード構成

両方のクラスタで次のコマンドを実行して、テイクオーバーが可能で、ノードが接続されていることを確認します。

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

cluster_A::> storage failover show
                                    Takeover
Node           Partner              Possible    State Description
-------------- -------------------- ---------   ------------------
Node_FC_1      Node_FC_2              true      Connected to Node_FC_2
Node_FC_2      Node_FC_1              true      Connected to Node_FC_1
Node_IP_1      Node_IP_2              true      Connected to Node_IP_2
Node_IP_2      Node_IP_1              true      Connected to Node_IP_1

CRS ボリュームを移動します。

の手順を実行します "MetroCluster 構成でのメタデータボリュームの移動"。
次の手順を使用して、古いノードから新しいノードにデータを移動します。
1. のすべての手順を実行します "アグリゲートを作成してボリュームを新しいノードに移動"。
  
  アグリゲートのミラーリングは、作成時または作成後に実行できます。
2. のすべての手順を実行します "SAN以外のデータLIFとクラスタ管理LIFを新しいノードに移動する"。

各クラスタについて、移行したノードのクラスタピアのIPアドレスを変更します。

を使用して、cluster_Aピアを特定します cluster peer show コマンドを実行します

cluster_A::> cluster peer show
Peer Cluster Name         Cluster Serial Number Availability   Authentication
------------------------- --------------------- -------------- --------------
cluster_B         1-80-000011           Unavailable    absent

cluster_AピアのIPアドレスを変更します。

cluster peer modify -cluster cluster_A -peer-addrs node_A_3_IP -address-family ipv4

を使用して、cluster_Bピアを特定します cluster peer show コマンドを実行します

cluster_B::> cluster peer show
Peer Cluster Name         Cluster Serial Number Availability   Authentication
------------------------- --------------------- -------------- --------------
cluster_A         1-80-000011           Unavailable    absent

cluster_BピアのIPアドレスを変更します。

cluster peer modify -cluster cluster_B -peer-addrs node_B_3_IP -address-family ipv4

各クラスタのクラスタピアIPアドレスが更新されていることを確認します。

を使用して、各クラスタのIPアドレスが更新されていることを確認します cluster peer show -instance コマンドを実行します

。 Remote Intercluster Addresses 次の例のフィールドには、更新されたIPアドレスが表示されます。

cluster_Aの例：

cluster_A::> cluster peer show -instance

Peer Cluster Name: cluster_B
           Remote Intercluster Addresses: 172.21.178.204, 172.21.178.212
      Availability of the Remote Cluster: Available
                     Remote Cluster Name: cluster_B
                     Active IP Addresses: 172.21.178.212, 172.21.178.204
                   Cluster Serial Number: 1-80-000011
                    Remote Cluster Nodes: node_B_3-IP,
                                          node_B_4-IP
                   Remote Cluster Health: true
                 Unreachable Local Nodes: -
          Address Family of Relationship: ipv4
    Authentication Status Administrative: use-authentication
       Authentication Status Operational: ok
                        Last Update Time: 4/20/2023 18:23:53
            IPspace for the Relationship: Default
Proposed Setting for Encryption of Inter-Cluster Communication: -
Encryption Protocol For Inter-Cluster Communication: tls-psk
  Algorithm By Which the PSK Was Derived: jpake

cluster_A::>

+ たとえば、cluster_Bです

cluster_B::> cluster peer show -instance

                       Peer Cluster Name: cluster_A
           Remote Intercluster Addresses: 172.21.178.188, 172.21.178.196 <<<<<<<< Should reflect the modified address
      Availability of the Remote Cluster: Available
                     Remote Cluster Name: cluster_A
                     Active IP Addresses: 172.21.178.196, 172.21.178.188
                   Cluster Serial Number: 1-80-000011
                    Remote Cluster Nodes: node_A_3-IP,
                                          node_A_4-IP
                   Remote Cluster Health: true
                 Unreachable Local Nodes: -
          Address Family of Relationship: ipv4
    Authentication Status Administrative: use-authentication
       Authentication Status Operational: ok
                        Last Update Time: 4/20/2023 18:23:53
            IPspace for the Relationship: Default
Proposed Setting for Encryption of Inter-Cluster Communication: -
Encryption Protocol For Inter-Cluster Communication: tls-psk
  Algorithm By Which the PSK Was Derived: jpake

cluster_B::>

の手順に従います "ディザスタリカバリグループを削除しています" をクリックして、古いDRグループを削除します。
8ノード構成で両方のDRグループを更新する場合は、各DRグループに対して手順全体を繰り返す必要があります。

古いDRグループを削除すると、次の図のような設定が表示されます。

図 3. 4 ノード構成

図 4. 8ノード構成
MetroCluster 構成の運用モードを確認し、 MetroCluster チェックを実行
1. MetroCluster 構成と運用モードが正常な状態であることを確認します。
  
  「 MetroCluster show 」
2. 想定されるすべてのノードが表示されることを確認します。
  
  MetroCluster node show
3. 次のコマンドを問題に設定します。
  
  「 MetroCluster check run 」のようになります
4. MetroCluster チェックの結果を表示します。
  
  MetroCluster チェックショー
新しいノードを追加する前にエンドツーエンドの暗号化を無効にした場合は、の手順に従って再度有効にできます。 "エンドツーエンドの暗号化を実現"。

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

使用するポート

この手順を使用します