本ページの製品は2024年4月1日より、エフサステクノロジーズ株式会社に統合となり、順次、切り替えを実施してまいります。一部、富士通表記が混在することがありますので、ご了承ください。

MetroCluster マニュアル

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

この手順を使用して、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グループを更新する場合は、DRグループを1つずつ更新する必要があります。
「古いノード」とは、交換対象のノードを意味します。

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

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

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

手順

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

デフォルトのブロードキャストドメインがない既存のクラスタに新しいノードを追加すると、想定される名前ではなくUniversal Unique Identifier（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
2. パートナークラスタで同じコマンドを実行します。

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

対象	使用する手順
Tiebreaker	Tiebreaker CLIの`monitor remove`コマンドを使用して、MetroCluster構成を削除します。次の例では、ソフトウェアから「`cluster_A`」を削除しています。 MetroCluster Tiebreaker :> monitor remove -monitor-name cluster_A Successfully removed monitor from MetroCluster Tiebreaker software. Tiebreaker CLIの`monitor show -status`コマンドを使用して、MetroCluster構成が正しく削除されたことを確認します。 MetroCluster Tiebreaker :> monitor show -status
メディエーター	ONTAPプロンプトで次のコマンドを入力します。 `metrocluster configuration-settings mediator remove`
他社製アプリケーション	製品ドキュメントを参照してください。

対象

使用する手順

Tiebreaker

Tiebreaker CLIのmonitor removeコマンドを使用して、MetroCluster構成を削除します。

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

メディエーター

ONTAPプロンプトで次のコマンドを入力します。

metrocluster configuration-settings mediator remove

他社製アプリケーション

製品ドキュメントを参照してください。

「MetroCluster IP構成の拡張」のすべての手順を実行して、新しいノードとストレージを構成に追加します。

拡張手順が完了すると、次の図のような一時的な構成になります。

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

Figure 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ボリュームを移動します。

アグリゲートは作成時または作成後にミラーリングすることもできます。
1. 「SAN以外のデータ管理LIFとクラスタ管理LIFを新しいノードに移動する」のすべての手順を実行します。

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

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

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 peer showコマンドを使用して、cluster_Bのピアを特定します。

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アドレスが更新されていることを確認します。

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

次の例の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グループを削除すると、次の図のような構成になります。

Figure 3. 4ノード構成

Figure 4. 8ノード構成
MetroCluster構成の運用モードを確認し、MetroClusterチェックを実行します。
1. MetroCluster構成と運用モードが正常な状態であることを確認します。
  
  metrocluster show
2. 想定されるノードがすべて表示されることを確認します。
  
  metrocluster node show
3. 次のコマンドを実行します。
  
  metrocluster check run
4. MetroClusterチェックの結果を表示します。
  
  metrocluster check show

必要に応じて、構成に応じた手順を使用して監視を再開します。

対象	使用する手順
Tiebreaker	「MetroCluster Tiebreakerソフトウェアのインストールおよび設定」の「MetroCluster構成の追加」
メディエーター	「MetroCluster IPのインストールおよび設定」の「MetroCluster IP構成でのONTAP Mediatorサービスの設定」
他社製アプリケーション	製品ドキュメントを参照してください。

対象

使用する手順

Tiebreaker

「MetroCluster Tiebreakerソフトウェアのインストールおよび設定」の「MetroCluster構成の追加」

メディエーター

「MetroCluster IPのインストールおよび設定」の「MetroCluster IP構成でのONTAP Mediatorサービスの設定」

他社製アプリケーション

製品ドキュメントを参照してください。

サポートケースの自動生成を再開するには、メンテナンスが完了したことを通知するAutoSupportメッセージを送信します。
1. 次のコマンドを実行します。
  
  system node autosupport invoke -node * -type all -message MAINT=end
2. パートナークラスタで同じコマンドを実行します。