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

FC から IP への移行を停止させる準備をしています

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

FC から IP への移行を停止するための一般的な要件

移行プロセスを開始する前に、構成が要件を満たしていることを確認する必要があります。

既存の MetroCluster FC 構成が次の要件を満たしている必要があります。

MetroCluster サイトから 6 つのすべてのノードのリモートコンソールアクセスが必要です。または、手順で必要に応じてサイト間の移動を計画しておく必要があります。

FC から IP への移行を停止させるために、ドライブシェルフを再利用し、ドライブ要件を満たしておく必要があります

ストレージシェルフに利用可能な十分なスペアドライブとルートアグリゲートスペースがあることを確認する必要があります。

既存のストレージシェルフを再利用する

この手順を使用する場合、既存のストレージシェルフは新しい構成で使用できるように保持されます。node_A_1 - FC と node_B_1 - FC を削除した場合、既存のドライブシェルフは cluster_B の node_A_1 - IP と node_B_2 - IP に接続され、 node_B_1 - IP と node_B_2 の node_B_2 - IP に接続されます

追加のコントローラのストレージ要件

2 つのコントローラ( node_B_2 - IP と node_B_2 - IP )の構成が 2 ノードから 4 ノードに変更されるため、必要に応じてストレージを追加する必要があります。

  • 既存のシェルフで使用可能なスペアドライブに応じて、追加のコントローラに対応するドライブを追加する必要があります。

    この場合、次の図に示すように、追加のストレージシェルフが必要になることがあります。

    シェルフの新しい IP ノードを 2 、 4 つ移行します

    3 台目と 4 台目のコントローラ( node_B_2 - IP および node_B_2 - IP )のそれぞれに 14 ~ 18 本のドライブを追加する必要があります。

    • 3 本のプール 0 ドライブ

    • プール 1 ドライブ × 3

    • 2 本のスペアドライブ

    • システムボリューム用に 6 ~ 10 台のドライブ

  • 新しいノードを含む構成が、ドライブ数、ルートアグリゲートのサイズ容量など、構成のプラットフォーム制限を超えないようにする必要があります

    この情報は、各プラットフォームモデルの NetApp Hardware Universe _ で確認できます。

停止を伴う移行のワークフロー

移行を成功させるには、特定のワークフローに従う必要があります。

移行を準備する際は、サイト間の移動を計画します。リモートノードがラックに設置されてケーブル接続されたら、ノードへのシリアルターミナルアクセスが必要です。ノードが設定されるまでサービスプロセッサへのアクセスは許可されません。

ワークフロー 2n 遷移 bsaic

MetroCluster FC ノードから MetroCluster IP ノードへのポートのマッピング

MetroCluster FC ノードのポートと LIF の設定を、交換する MetroCluster IP ノードと互換性があるように調整する必要があります。

アップグレードプロセスで最初に新しいノードがブートされると、各ノードは交換するノードの最新の設定を使用します。node_A_1 の IP をブートする際、 ONTAP は、 node_A_1 の FC で使用されていたポート上で LIF をホストしようとします。

移行手順では、クラスタ LIF 、管理 LIF 、およびデータ LIF の構成が正しくなるように、古いノードと新しいノードの両方で手順を実行します。

  1. 既存の MetroCluster FC ポートの用途と新しいノードでの MetroCluster IP インターフェイスのポートの用途が競合していないかを特定します。

    次の表を使用して、新しい MetroCluster IP コントローラの MetroCluster IP ポートを特定する必要があります。次に、 MetroCluster FC ノードのそれらのポートにデータ LIF またはクラスタ LIF が存在するかどうかを確認して記録します。

    これらの競合するデータ LIF または MetroCluster FC ノード上のクラスタ LIF は、移行手順の該当するステップで移動されます。

    注記 AFF A220 および FAS2750 システムでは、 MetroCluster IP 物理ポートもクラスタインターフェイスとして使用されます。新しい MetroCluster IP ノードが AFF A220 または FAS2750 システムの場合、既存のクラスタ LIF を移動する必要はありません。

    次の表に、 MetroCluster IP ポートをプラットフォームモデル別に示します。VLAN ID 列は無視してかまいません。

    プラットフォームモデル MetroCluster の IP ポート VLAN ID

    AFF A800

    e0b

    使用されません

    e1b

    AFF A700 および FAS9000

    e5

    e5b

    AFF A320

    e0g

    E0h

    AFF A300 および FAS8200

    E1A

    e1b

    AFF A220 および FAS2750

    e0a

    10.

    このようなシステムでは、これらの物理ポートがクラスタインターフェイスとしても使用されます。

    e0b

    20

    AFF A250 および FAS500f

    e0c

    10.

    e0d

    20

    次の表に記入して、移行手順で後ほど参照できます。

    ポート 対応する MetroCluster IP インターフェイスポート(上の表を参照) MetroCluster FC ノードのこれらのポートで LIF が競合しています

    node_A_1 の FC 上の最初の MetroCluster IP ポート

    node_A_1 の FC 上の 2 番目の MetroCluster IP ポート

    node_B_1 の最初の MetroCluster IP ポート: FC

    node_B_1 の 2 つ目の MetroCluster IP ポート: FC

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

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

  3. 必要に応じて、 node_A_1 の FC と node_A_1 の IP のポート情報を記録します。

    この表は、移行手順を実行するときに参照します。

    node_A_1 の列で、新しいコントローラモジュールの物理ポートを追加し、新しいノードの IPspace とブロードキャストドメインを計画します。

    node_A_1 - FC node_A_1 の IP

    * LIF *

    * ポート * :

    * IPspace *

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

    * ポート * :

    * IPspace *

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

    クラスタ 1

    クラスタ 2

    クラスタ 3

    クラスタ 4

    ノード管理

    クラスタ管理

    データ 1

    データ 2.

    データ 3

    データ 4.

    SAN

    クラスタ間ポート

  4. 必要に応じて、 node_B_1 FC のすべてのポート情報を記録します。

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

    node_B_1 の IP の列で、新しいコントローラモジュールの物理ポートを追加し、新しいノードの LIF ポートの使用、 IPspace 、およびブロードキャストドメインを計画します。

    node_B_1 - FC node_B_1 - IP

    * LIF *

    * 物理ポート *

    * IPspace *

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

    * 物理ポート *

    * IPspace *

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

    クラスタ 1

    クラスタ 2

    クラスタ 3

    クラスタ 4

    ノード管理

    クラスタ管理

    データ 1

    データ 2.

    データ 3

    データ 4.

    SAN

    クラスタ間ポート

MetroCluster IP コントローラの準備

4 つの新しい MetroCluster IP ノードを準備し、正しいバージョンの ONTAP をインストールする必要があります。

このタスクは新しい各ノードで実行する必要があります。

  • node_A_1 の IP

  • Node_a_2-IP

  • node_B_1 - IP

  • node_B_2 - IP

ノードは新しい * ストレージシェルフに接続する必要があります。既存のストレージシェルフにデータを格納している状態は * 接続しないでください。

ここ手順で説明する手順は、コントローラとシェルフがラックに設置されたときに実行することも、あとで実行することもできます。いずれの場合も、構成をクリアし、ノードを既存のストレージシェルフに接続する前 * および MetroCluster FC ノードの構成を変更する前 * に、ノードを準備する必要があります。

注記 MetroCluster FC コントローラに接続された既存のストレージシェルフに MetroCluster IP コントローラを接続した状態では、この手順を実行しないでください。

この手順では、ノードの設定をクリアし、新しいドライブのメールボックスのリージョンをクリアします。

  1. コントローラモジュールを新しいストレージシェルフに接続します。

  2. 保守モードで、コントローラモジュールとシャーシの HA 状態を表示します。「 ha-config show 」

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

  3. 表示されたコントローラまたはシャーシのシステム状態が正しくない場合は、 HA の状態を設定します。「 ha-config modify controller mccip 」「 ha-config modify chassis ip

  4. 保守モードを終了します :halt

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

  5. 4 つのすべてのノードで次の手順を繰り返して、設定をクリアします。

    1. 環境変数をデフォルト値の「 set-defaults 」に設定します

    2. 環境を保存します : 'aveenv`bye

  6. ブートメニューの 9a オプションを使用して、次の手順を繰り返して 4 つのノードをすべてブートします。

    1. LOADER プロンプトで、ブートメニュー「 boot_ontap menu 」を起動します

    2. ブートメニューでオプション * 9a * を選択してコントローラをリブートします。

  7. ブートメニューのオプション * 5 を使用して、 4 つのノードのそれぞれをメンテナンスモードでブートします。

  8. システム ID と 4 つのノードそれぞれの「 sysconfig 」を記録します

  9. node_A_1 の IP と node_B_1 の IP について、次の手順を繰り返します。

    1. 各サイトにローカルなすべてのディスクの所有権を割り当てます。「ディスク割り当て adapter.xx.*」

    2. node_A_1 の IP と node_B_1 の IP でドライブシェルフが接続されている HBA ごとに、上記の手順を繰り返します。

  10. node_A_1 の IP と node_B_1 の IP で次の手順を繰り返し、各ローカルディスクのメールボックス領域をクリアします。

    1. 各ディスクのメールボックス領域を破棄します : 「メールボックスを破棄する」ローカルの「メールボックスを破棄するパートナー」

  11. 4 台すべてのコントローラを停止します

  12. 各コントローラで、ブートメニュー「 boot_ontap menu 」を表示します

  13. 4 つのコントローラのそれぞれで、設定「 wipeconfig 」をクリアします

    wipeconfig 処理が完了すると、ノードは自動的にブートメニューに戻ります。

  14. ブートメニューの 9a オプションを使用して、次の手順を繰り返して 4 つのノードをすべてブートします。

    1. LOADER プロンプトで、ブートメニュー「 boot_ontap menu 」を起動します

    2. ブートメニューでオプション * 9a * を選択してコントローラをリブートします。

    3. コントローラモジュールのブートが完了してから次のコントローラモジュールに移動します。

    9a が完了すると、ノードは自動的にブートメニューに戻ります。

  15. コントローラの電源をオフにします。

MetroCluster FC 構成の健全性の確認

移行を実行する前に、 MetroCluster FC 構成の健全性と接続を確認する必要があります

このタスクは、 MetroCluster FC 構成上で実行します。

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

    1. システムがマルチパスであるかどうかを確認します。「 node run -node node-name sysconfig -a ` 」

    2. 両方のクラスタにヘルスアラートがないかどうかを確認します。 'system health alert show'

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

    4. MetroCluster チェック「 MetroCluster check run 」を実行します

    5. MetroCluster チェックの結果を表示します。「 MetroCluster check show 」

    6. スイッチにヘルスアラートがないかどうかを確認します(ある場合):「 storage switch show 」

    7. Config Advisor を実行します。

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

  2. ノードが非 HA モードであることを確認します。「 storage failover show 」

Tiebreaker またはその他の監視ソフトウェアから既存の設定を削除します

スイッチオーバーを開始できる MetroCluster Tiebreaker 構成や他社製アプリケーション( ClusterLion など)で既存の構成を監視している場合は、移行の前に Tiebreaker またはその他のソフトウェアから MetroCluster 構成を削除する必要があります。

  1. Tiebreaker ソフトウェアから既存の MetroCluster 設定を削除します。

  2. スイッチオーバーを開始できるサードパーティ製アプリケーションから既存の MetroCluster 構成を削除します。

    アプリケーションのマニュアルを参照してください。