ONTAP での MetroCluster ソフトウェアの設定
変更を提案
PDF
MetroCluster 構成の各ノードは、ノードレベルの設定や 2 つのサイトへのノードの設定を含めて、 ONTAP で設定する必要があります。また、 2 つのサイト間に MetroCluster 関係を実装する必要があります。
-
設定プロセスを開始する前に、コントローラモジュールに必要な IP アドレスを収集します。
-
サイト A の IP ネットワーク情報ワークシートに記入
サイト A の IP ネットワーク情報ワークシート
システムを設定する前に、最初の MetroCluster サイト（サイト A ）の IP アドレスその他のネットワーク情報を、ネットワーク管理者から入手する必要があります。
クラスタ作成情報：サイト A
クラスタを初めて作成するときは、次の情報が必要です。
情報のタイプ |
値を入力します |
クラスタ名。この情報で使用している例： site_A |
|
DNS ドメイン |
|
DNS ネームサーバ |
|
場所 |
|
管理者パスワード |
ノード情報：サイト A
クラスタ内のノードごとに、管理 IP アドレス、ネットワークマスク、およびデフォルトゲートウェイが必要です。
ノード |
ポート |
IP アドレス |
ネットワークマスク |
デフォルトゲートウェイ |
ノード 1 ：この情報で使用している例： controller_A_1 |
||||
ノード 2 ：2 ノード MetroCluster 構成（サイトごとに 1 つのノード）を使用している場合は不要 この情報で使用している例： controller_A_2 |
クラスタピアリング用の LIF およびポート：サイト A
クラスタ内のノードごとに、 2 つのクラスタ間 LIF の IP アドレス、ネットワークマスク、およびデフォルトゲートウェイが必要です。クラスタ間 LIF は、クラスタのピアリングに使用されます。
ノード |
ポート |
クラスタ間 LIF の IP アドレス |
ネットワークマスク |
デフォルトゲートウェイ |
ノード 1 IC LIF 1 |
||||
ノード 1 IC LIF 2 |
タイムサーバ情報：サイト A
時間を同期する必要があります。これには 1 台以上の NTP タイムサーバが必要です。
ノード |
ホスト名 |
IP アドレス |
ネットワークマスク |
デフォルトゲートウェイ |
NTP サーバ 1 |
||||
NTP サーバ 2 |
サイトA nbsp；AutoSupport 情報
各ノードで AutoSupport を設定する必要があります。これには次の情報が必要です。
情報のタイプ |
値を入力します |
|
送信元 E メールアドレス |
メールホスト |
|
IP アドレスまたは名前 |
転送プロトコル |
|
HTTP 、 HTTPS 、または SMTP |
プロキシサーバ |
|
受信者の E メールアドレスまたは配信リスト |
メッセージ全文 |
|
簡潔なメッセージ |
||
SP 情報：サイト A
トラブルシューティングとメンテナンスのために、各ノードのサービスプロセッサ（ SP ）へのアクセスを有効にする必要があります。そのためには、各ノードについて次のネットワーク情報が必要です。
ノード |
IP アドレス |
ネットワークマスク |
デフォルトゲートウェイ |
ノード 1 |
サイト B の IP ネットワーク情報ワークシート
システムを設定する前に、 2 つ目の MetroCluster サイト（サイト B ）の IP アドレスその他のネットワーク情報を、ネットワーク管理者から入手する必要があります。
クラスタ作成情報：サイト B
クラスタを初めて作成するときは、次の情報が必要です。
情報のタイプ |
値を入力します |
クラスタ名。この情報で使用している例： site_B |
|
DNS ドメイン |
|
DNS ネームサーバ |
|
場所 |
|
管理者パスワード |
ノード情報：サイト B
クラスタ内のノードごとに、管理 IP アドレス、ネットワークマスク、およびデフォルトゲートウェイが必要です。
ノード |
ポート |
IP アドレス |
ネットワークマスク |
デフォルトゲートウェイ |
ノード 1 ：この情報で使用している例： controller_B_1 |
||||
ノード 2 ：2 ノード MetroCluster 構成（サイトごとに 1 つのノード）の場合は不要 この情報で使用している例： controller_B_2 |
クラスタピアリング用の LIF およびポート：サイト B
クラスタ内のノードごとに、 2 つのクラスタ間 LIF の IP アドレス、ネットワークマスク、およびデフォルトゲートウェイが必要です。クラスタ間 LIF は、クラスタのピアリングに使用されます。
ノード |
ポート |
クラスタ間 LIF の IP アドレス |
ネットワークマスク |
デフォルトゲートウェイ |
ノード 1 IC LIF 1 |
||||
ノード 1 IC LIF 2 |
タイムサーバ情報：サイト B
時間を同期する必要があります。これには 1 台以上の NTP タイムサーバが必要です。
ノード |
ホスト名 |
IP アドレス |
ネットワークマスク |
デフォルトゲートウェイ |
NTP サーバ 1 |
||||
NTP サーバ 2 |
サイトB nbsp；AutoSupport 情報
各ノードで AutoSupport を設定する必要があります。これには次の情報が必要です。
情報のタイプ |
値を入力します |
|
送信元 E メールアドレス |
メールホスト |
|
IP アドレスまたは名前 |
転送プロトコル |
|
HTTP 、 HTTPS 、または SMTP |
プロキシサーバ |
|
受信者の E メールアドレスまたは配信リスト |
メッセージ全文 |
|
簡潔なメッセージ |
||
サイトB nbsp；SP情報
トラブルシューティングとメンテナンスのために、各ノードのサービスプロセッサ（ SP ）へのアクセスを有効にする必要があります。これには、ノードごとに次のネットワーク情報が必要です。
ノード |
IP アドレス |
ネットワークマスク |
デフォルトゲートウェイ |
ノード 1 （ controller_B_1 ） |
標準クラスタ構成と MetroCluster 構成の類似点 / 相違点
MetroCluster 構成の各クラスタのノードの構成は、標準クラスタのノードと似ています。
MetroCluster 構成は、 2 つの標準クラスタを基盤としています。構成は物理的に対称な構成である必要があり、各ノードのハードウェア構成が同じで、すべての MetroCluster コンポーネントがケーブル接続され、設定されている必要があります。ただし、 MetroCluster 構成のノードの基本的なソフトウェア設定は、標準クラスタのノードと同じです。
設定手順 |
標準クラスタ構成 |
MetroCluster の設定 |
各ノードで管理 LIF 、クラスタ LIF 、データ LIF を設定。 |
両方のクラスタタイプで同じです |
ルートアグリゲートを設定 |
両方のクラスタタイプで同じです |
クラスタ内の一方のノードでクラスタを設定。 |
両方のクラスタタイプで同じです |
もう一方のノードをクラスタに追加。 |
両方のクラスタタイプで同じです |
ミラーされたルートアグリゲートを作成 |
任意。 |
必須 |
クラスタをピアリング。 |
任意。 |
必須 |
MetroCluster 設定を有効にします。 |
システムのデフォルト設定をリストアし、コントローラモジュールで HBA タイプを設定しています
MetroCluster を正しくインストールするには、コントローラモジュールのデフォルトをリセットしてリストアします。
このタスクを実行する必要があるのは、 FC-to-SAS ブリッジを使用するストレッチ構成のみです。
-
LOADER プロンプトで環境変数をデフォルト設定に戻します。
「デフォルト設定」
-
ノードをメンテナンスモードでブートし、システム内の HBA の設定を行います。
-
メンテナンスモードでブートします。
「 boot_ontap maint 」を使用してください
-
ポートの現在の設定を確認します。
ucadmin show
-
必要に応じてポートの設定を更新します。
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_`
-
-
メンテナンスモードを終了します。
「 halt 」
コマンドの実行後、ノードが LOADER プロンプトで停止するまで待ちます。
-
ノードをブートしてメンテナンスモードに戻り、設定の変更が反映されるようにします。
「 boot_ontap maint 」を使用してください
-
変更内容を確認します。
HBA のタイプ
使用するコマンド
CNA
ucadmin show
FC
fcadmin show`
-
メンテナンスモードを終了します。
「 halt 」
コマンドの実行後、ノードが LOADER プロンプトで停止するまで待ちます。
-
ノードをブートメニューでブートします。
「 boot_ontap menu
コマンドの実行後、ブートメニューが表示されるまで待ちます。
-
ブートメニュープロンプトで「 wipeconfig 」と入力してノード設定をクリアし、 Enter キーを押します。
次の画面はブートメニューのプロンプトを示しています。
Please choose one of the following: (1) Normal Boot. (2) Boot without /etc/rc. (3) Change password. (4) Clean configuration and initialize all disks. (5) Maintenance mode boot. (6) Update flash from backup config. (7) Install new software first. (8) Reboot node. (9) Configure Advanced Drive Partitioning. Selection (1-9)? wipeconfig This option deletes critical system configuration, including cluster membership. Warning: do not run this option on a HA node that has been taken over. Are you sure you want to continue?: yes Rebooting to finish wipeconfig request.
FAS8020 システムでの X1132A-R6 クアッドポートカードの FC-VI ポートの設定
FAS8020 システムで X1132A-R6 クアッドポートカードを使用している場合は、メンテナンスモードに切り替えて、ポート 1a / 1b を FC-VI およびイニシエータ用に使用するように設定できます。工場出荷状態の MetroCluster システムでは、構成に応じて適切にポートが設定されているため、この設定は必要ありません。
このタスクはメンテナンスモードで実行する必要があります。
|
ucadmin コマンドを使用した FC ポートの FC-VI ポートへの変換は、 FAS8020 および AFF 8020 システムでのみサポートされます。他のプラットフォームでは、 FC ポートを FCVI ポートに変換することはできません。 |
-
ポートを無効にします。
「ストレージ無効化アダプタ 1a 」
「ストレージ無効化アダプタ 1b'
*> storage disable adapter 1a Jun 03 02:17:57 [controller_B_1:fci.adapter.offlining:info]: Offlining Fibre Channel adapter 1a. Host adapter 1a disable succeeded Jun 03 02:17:57 [controller_B_1:fci.adapter.offline:info]: Fibre Channel adapter 1a is now offline. *> storage disable adapter 1b Jun 03 02:18:43 [controller_B_1:fci.adapter.offlining:info]: Offlining Fibre Channel adapter 1b. Host adapter 1b disable succeeded Jun 03 02:18:43 [controller_B_1:fci.adapter.offline:info]: Fibre Channel adapter 1b is now offline. *>
-
ポートが無効になっていることを確認します。
ucadmin show
*> ucadmin show Current Current Pending Pending Admin Adapter Mode Type Mode Type Status ------- ------- --------- ------- --------- ------- ... 1a fc initiator - - offline 1b fc initiator - - offline 1c fc initiator - - online 1d fc initiator - - online -
ポート a とポート b を FC-VI モードに設定します。
ucadmin modify -adapter 1a -type FCVI`
このコマンドでは、 1a だけを指定した場合でも、ポートペアの両方のポート 1a と 1b のモードが設定されます。
*> ucadmin modify -t fcvi 1a Jun 03 02:19:13 [controller_B_1:ucm.type.changed:info]: FC-4 type has changed to fcvi on adapter 1a. Reboot the controller for the changes to take effect. Jun 03 02:19:13 [controller_B_1:ucm.type.changed:info]: FC-4 type has changed to fcvi on adapter 1b. Reboot the controller for the changes to take effect.
-
変更が保留中であることを確認します。
ucadmin show
*> ucadmin show Current Current Pending Pending Admin Adapter Mode Type Mode Type Status ------- ------- --------- ------- --------- ------- ... 1a fc initiator - fcvi offline 1b fc initiator - fcvi offline 1c fc initiator - - online 1d fc initiator - - online -
コントローラをシャットダウンし、メンテナンスモードでリブートします。
-
設定の変更を確認します。
ucadmin show local
Node Adapter Mode Type Mode Type Status ------------ ------- ------- --------- ------- --------- ----------- ... controller_B_1 1a fc fcvi - - online controller_B_1 1b fc fcvi - - online controller_B_1 1c fc initiator - - online controller_B_1 1d fc initiator - - online 6 entries were displayed.
保守モードでの 2 ノード構成のディスク割り当ての検証
システムを ONTAP で完全にブートする前に、システムをメンテナンスモードでブートして、ノードのディスク割り当てを確認することもできます。ディスクは、両方のサイトが独自のディスクシェルフを所有してデータを提供し、各ノードおよび各プールのミラーディスク数が等しい、完全に対称な構成を形成するように割り当てられている必要があります。
システムをメンテナンスモードにする必要があります。
新しい MetroCluster システムの場合、出荷前にディスク割り当てが完了しています。
次の表に、 MetroCluster 構成のプール割り当ての例を示します。ディスクはシェルフ単位でプールに割り当てられます。
ディスクシェルフ（ _ 例名 _ ） … |
サイト |
所属ノード |
割り当てプール |
ディスクシェルフ 1 （ shelf_A_1_1 ） |
サイト A |
ノード A1 |
プール 0 |
ディスクシェルフ 2 （ shelf_A_1_3 ） |
ディスクシェルフ 3 （ shelf_B_1_1 ） |
ノード B1 |
プール 1. |
ディスクシェルフ 4 （ shelf_B_1_3 ） |
ディスクシェルフ 9 （ shelf_B_1_2 ） |
サイト B |
ノード B1 |
プール 0 |
ディスクシェルフ 10 （ shelf_B_1_4 ） |
ディスクシェルフ 11 （ shelf_A_1_2 ） |
ノード A1 |
構成に DS460C ディスクシェルフが含まれている場合は、それぞれの 12 ディスクドロワーについて、次のガイドラインに従ってディスクを手動で割り当てる必要があります。
ドロワーのディスク |
ノードとプール |
1 ~ 6 |
ローカルノードのプール 0 |
7-12 |
DR パートナーのプール 1 |
このディスク割り当てパターンに従うことで、ドロワーがオフラインになった場合のアグリゲートへの影響を最小限に抑えることができます。
-
工場出荷状態のシステムの場合は、シェルフの割り当てを確認します。
「 Disk show – v 」のように表示されます
-
必要に応じて、接続されているディスクシェルフ上のディスクを適切なプールに明示的に割り当てることができます
「ディスク割り当て」
ノードと同じサイトにあるディスクシェルフはプール 0 に割り当て、パートナーサイトにあるディスクシェルフはプール 1 に割り当てます。各プールに同じ数のシェルフを割り当てる必要があります。
-
システムをブートしていない場合は、メンテナンスモードでブートします。
-
サイト A のノードで、ローカルディスクシェルフをプール 0 に、リモートディスクシェルフをプール 1 に割り当てます。 +
disk assign -shelf_disk_shelf_name_-p_pool_ストレージコントローラ node_A_1 にシェルフが 4 台ある場合は、次のコマンドを問題できます。
*> disk assign -shelf shelf_A_1_1 -p 0 *> disk assign -shelf shelf_A_1_3 -p 0 *> disk assign -shelf shelf_A_1_2 -p 1 *> disk assign -shelf shelf_A_1_4 -p 1
-
リモートサイト（サイト B ）のノードで、ローカルディスクシェルフをプール 0 に、リモートディスクシェルフをプール 1 に割り当てます。 +
disk assign -shelf_disk_shelf_name_-p_pool_ストレージコントローラ node_B_1 にシェルフが 4 台ある場合は、次のコマンドを問題に設定します。
*> disk assign -shelf shelf_B_1_2 -p 0 *> disk assign -shelf shelf_B_1_4 -p 0 *> disk assign -shelf shelf_B_1_1 -p 1 *> disk assign -shelf shelf_B_1_3 -p 1
-
各ディスクのディスク・シェルフ ID とベイを表示します +
disk show – v
-
コンポーネントの HA 状態の確認
工場出荷時に事前設定されていないストレッチ MetroCluster 構成では、コントローラおよびシャーシのコンポーネントの HA の状態が「 mcc-2n 」に設定されていることを確認し、適切にブートする必要があります。工場出荷状態のシステムでは事前に設定されているため、検証は不要です。
システムをメンテナンスモードにする必要があります。
-
メンテナンスモードで、コントローラモジュールとシャーシの HA 状態を表示します。
「 ha-config show 」
コントローラモジュールとシャーシには「 mcc-2n 」という値が表示されます。
-
表示されたコントローラのシステム状態が「 mcc-2n 」でない場合は、コントローラの HA 状態を設定します。
「 ha-config modify controller mcc-2n 」という形式で指定します
-
表示されたシャーシのシステム状態が「 mcc-2n 」でない場合は、シャーシの HA 状態を設定します。
「 ha-config modify chassis mcc-2n 」というようになりました
ノードを停止します。
ノードが LOADER プロンプトに戻るまで待ちます。
-
MetroCluster 構成の各ノードで、上記の手順を繰り返します。
2 ノード MetroCluster 構成での ONTAP のセットアップ
2 ノード MetroCluster 構成では、各クラスタでノードをブートし、クラスタセットアップウィザードを終了し、「 cluster setup 」コマンドを使用してノードをシングルノードクラスタに構成する必要があります。
サービスプロセッサが設定されていないことを確認してください。
このタスクは、ネットアップの標準のストレージを使用した 2 ノード MetroCluster 構成が対象です。
このタスクは、 MetroCluster 構成の両方のクラスタで実行する必要があります。
ONTAP のセットアップに関するその他の一般的な情報については、を参照してください "ONTAP をセットアップします"
-
最初のノードの電源をオンにします。
この手順はディザスタリカバリ（ DR ）サイトのノードでも実行する必要があります。 ノードがブートし、 AutoSupport が自動的に有効になることを示すクラスタセットアップウィザードがコンソールで起動されます。
::> Welcome to the cluster setup wizard. You can enter the following commands at any time: "help" or "?" - if you want to have a question clarified, "back" - if you want to change previously answered questions, and "exit" or "quit" - if you want to quit the cluster setup wizard. Any changes you made before quitting will be saved. You can return to cluster setup at any time by typing "cluster setup". To accept a default or omit a question, do not enter a value. This system will send event messages and periodic reports to NetApp Technical Support. To disable this feature, enter autosupport modify -support disable within 24 hours. Enabling AutoSupport can significantly speed problem determination and resolution, should a problem occur on your system. For further information on AutoSupport, see: http://support.netapp.com/autosupport/ Type yes to confirm and continue {yes}: yes Enter the node management interface port [e0M]: Enter the node management interface IP address [10.101.01.01]: Enter the node management interface netmask [101.010.101.0]: Enter the node management interface default gateway [10.101.01.0]: Do you want to create a new cluster or join an existing cluster? {create, join}: -
新しいクラスタを作成します。
「 create 」
-
ノードをシングルノードクラスタとして使用するかどうかを選択します。
Do you intend for this node to be used as a single node cluster? {yes, no} [yes]: -
Enter キーを押してシステムのデフォルトの "yes" をそのまま使用するか ' または "no`" と入力してから Enter キーを押して独自の値を入力します
-
プロンプトに従って * Cluster Setup * ウィザードを完了し、 Enter キーを押してデフォルト値をそのまま使用するか、独自の値を入力して Enter キーを押します。
デフォルト値は、プラットフォームとネットワークの構成に基づいて自動的に決定されます。
-
クラスタセットアップ * ウィザードが完了したら、次のコマンドを入力して、クラスタがアクティブで、第 1 ノードが正常に機能していることを確認します。
「 cluster show 」を参照してください
次の例は、第 1 ノードが含まれるクラスタ（ cluster1-01 ）が正常に機能しており、クラスタへの参加条件を満たしていることを示しています。
cluster1::> cluster show Node Health Eligibility --------------------- ------- ------------ cluster1-01 true true
管理 SVM またはノード SVM に対して入力した設定のいずれかを変更する必要がある場合は 'cluster setup コマンドを使用してクラスタセットアップ * ウィザードにアクセスできます
クラスタを MetroCluster 構成に設定
クラスタをピアリングし、ルートアグリゲートをミラーリングし、ミラーリングされたデータアグリゲートを作成し、コマンドを問題して MetroCluster の処理を実装する必要があります。
クラスタをピアリング
MetroCluster 構成内のクラスタが相互に通信し、 MetroCluster ディザスタリカバリに不可欠なデータミラーリングを実行できるようにするために、クラスタ間にはピア関係が必要です。
クラスタ間 LIF を設定しています
MetroCluster パートナークラスタ間の通信に使用するポートにクラスタ間 LIF を作成する必要があります。専用のポートを使用することも、データトラフィック用を兼ねたポートを使用することもできます。
専用ポートでのクラスタ間 LIF の設定
専用ポートにクラスタ間 LIF を設定できます。通常は、レプリケーショントラフィックに使用できる帯域幅が増加します。
-
クラスタ内のポートの一覧を表示します。
「 network port show 」のように表示されます
コマンド構文全体については、マニュアルページを参照してください。
次の例は 'cluster0' 内のネットワーク・ポートを示しています
cluster01::> network port show Speed (Mbps) Node Port IPspace Broadcast Domain Link MTU Admin/Oper ------ --------- ------------ ---------------- ----- ------- ------------ cluster01-01 e0a Cluster Cluster up 1500 auto/1000 e0b Cluster Cluster up 1500 auto/1000 e0c Default Default up 1500 auto/1000 e0d Default Default up 1500 auto/1000 e0e Default Default up 1500 auto/1000 e0f Default Default up 1500 auto/1000 cluster01-02 e0a Cluster Cluster up 1500 auto/1000 e0b Cluster Cluster up 1500 auto/1000 e0c Default Default up 1500 auto/1000 e0d Default Default up 1500 auto/1000 e0e Default Default up 1500 auto/1000 e0f Default Default up 1500 auto/1000 -
クラスタ間通信専用に使用可能なポートを特定します。
network interface show -fields home-port 、 curr -port
コマンド構文全体については、マニュアルページを参照してください。
次の例は、ポート「 e0e 」および「 e0f 」に LIF が割り当てられていないことを示しています。
cluster01::> network interface show -fields home-port,curr-port vserver lif home-port curr-port Cluster cluster01-01_clus1 e0a e0a Cluster cluster01-01_clus2 e0b e0b Cluster cluster01-02_clus1 e0a e0a Cluster cluster01-02_clus2 e0b e0b cluster01 cluster_mgmt e0c e0c cluster01 cluster01-01_mgmt1 e0c e0c cluster01 cluster01-02_mgmt1 e0c e0c -
専用ポートのフェイルオーバーグループを作成します。
「 network interface failover-groups create -vserver_system_svm 」 -failover-group_failover_group_ -targets_physical_or_logical_ports_`
次の例では、ポート「 e0e 」および「 e0f 」を、システム SVM 「 cluster01 」上のフェイルオーバーグループ「 intercluster01 」に割り当てます。
cluster01::> network interface failover-groups create -vserver cluster01 -failover-group intercluster01 -targets cluster01-01:e0e,cluster01-01:e0f,cluster01-02:e0e,cluster01-02:e0f
-
フェイルオーバーグループが作成されたことを確認します。
「 network interface failover-groups show 」と表示されます
コマンド構文全体については、マニュアルページを参照してください。
cluster01::> network interface failover-groups show Failover Vserver Group Targets ---------------- ---------------- -------------------------------------------- Cluster Cluster cluster01-01:e0a, cluster01-01:e0b, cluster01-02:e0a, cluster01-02:e0b cluster01 Default cluster01-01:e0c, cluster01-01:e0d, cluster01-02:e0c, cluster01-02:e0d, cluster01-01:e0e, cluster01-01:e0f cluster01-02:e0e, cluster01-02:e0f intercluster01 cluster01-01:e0e, cluster01-01:e0f cluster01-02:e0e, cluster01-02:e0f -
システム SVM にクラスタ間 LIF を作成して、フェイルオーバーグループに割り当てます。
ONTAP バージョン
コマンドを実行します
ONTAP 9.6 以降
「 network interface create -vserver system_svm -lif lif_name -policy default -intercluster -home-node node -home-port port -address port_ip -netmask netmask-failover-group failover_group 」という名前のポートを作成します
ONTAP 9.5 以前
network interface create -vserver system_svm -lif lif_name -role intercluster -home-node node -home-port port -address port_ip -netmask netmask-failover-group failover_group を作成します
コマンド構文全体については、マニュアルページを参照してください。
次の例は、フェイルオーバーグループ「 intercluster0` 」内にクラスタ間 LIF 「 cluster01_icl01 」と「 cluster01_icl02 」を作成します。
cluster01::> network interface create -vserver cluster01 -lif cluster01_icl01 -service- policy default-intercluster -home-node cluster01-01 -home-port e0e -address 192.168.1.201 -netmask 255.255.255.0 -failover-group intercluster01 cluster01::> network interface create -vserver cluster01 -lif cluster01_icl02 -service- policy default-intercluster -home-node cluster01-02 -home-port e0e -address 192.168.1.202 -netmask 255.255.255.0 -failover-group intercluster01
-
クラスタ間 LIF が作成されたことを確認します。
ONTAP バージョン
コマンドを実行します
ONTAP 9.6 以降
「 network interface show -service -policy default -intercluster 」のように表示されます
ONTAP 9.5 以前
「 network interface show -role intercluster 」の略
コマンド構文全体については、マニュアルページを参照してください。
cluster01::> network interface show -service-policy default-intercluster Logical Status Network Current Current Is Vserver Interface Admin/Oper Address/Mask Node Port Home ----------- ---------- ---------- ------------------ ------------- ------- ---- cluster01 cluster01_icl01 up/up 192.168.1.201/24 cluster01-01 e0e true cluster01_icl02 up/up 192.168.1.202/24 cluster01-02 e0f true -
クラスタ間 LIF が冗長構成になっていることを確認します。
ONTAP バージョン
コマンドを実行します
ONTAP 9.6 以降
「 network interface show -service -policy default -intercluster-failover 」のように入力します
ONTAP 9.5 以前
「 network interface show -role intercluster-failover 」の略
コマンド構文全体については、マニュアルページを参照してください。
次の例は、 SVM ポート「 e0e 」上のクラスタ間 LIF 「 cluster01_icl01 」と「 cluster01_icl02 」がポート「 e0f 」にフェイルオーバーされることを示しています。
cluster01::> network interface show -service-policy default-intercluster –failover Logical Home Failover Failover Vserver Interface Node:Port Policy Group -------- --------------- --------------------- --------------- -------- cluster01 cluster01_icl01 cluster01-01:e0e local-only intercluster01 Failover Targets: cluster01-01:e0e, cluster01-01:e0f cluster01_icl02 cluster01-02:e0e local-only intercluster01 Failover Targets: cluster01-02:e0e, cluster01-02:e0f
共有データポートでのクラスタ間 LIF の設定
データネットワークと共有するポートにクラスタ間 LIF を設定できます。これにより、クラスタ間ネットワークに必要なポート数を減らすことができます。
-
クラスタ内のポートの一覧を表示します。
「 network port show 」のように表示されます
コマンド構文全体については、マニュアルページを参照してください。
次の例は 'cluster0' 内のネットワーク・ポートを示しています
cluster01::> network port show Speed (Mbps) Node Port IPspace Broadcast Domain Link MTU Admin/Oper ------ --------- ------------ ---------------- ----- ------- ------------ cluster01-01 e0a Cluster Cluster up 1500 auto/1000 e0b Cluster Cluster up 1500 auto/1000 e0c Default Default up 1500 auto/1000 e0d Default Default up 1500 auto/1000 cluster01-02 e0a Cluster Cluster up 1500 auto/1000 e0b Cluster Cluster up 1500 auto/1000 e0c Default Default up 1500 auto/1000 e0d Default Default up 1500 auto/1000 -
システム SVM にクラスタ間 LIF を作成します。
ONTAP バージョン
コマンドを実行します
ONTAP 9.6 以降
「 network interface create -vserver system_svm _ -lif_lif_name_service-policy default -intercluster -home-node node -home-port port _-address _port_ip-netmask netmask _ 」のようになります
ONTAP 9.5 以前
「 network interface create -vserver system_svm _ -lif LIF_name -role intercluster -home-node _node _-home-port _ -address_port_ip-netmask netmask _ 」のようになります
コマンド構文全体については、マニュアルページを参照してください。
次の例は、クラスタ間 LIF 「 cluster01_icl01 」と「 cluster01_icl02 」を作成します。
cluster01::> network interface create -vserver cluster01 -lif cluster01_icl01 -service- policy default-intercluster -home-node cluster01-01 -home-port e0c -address 192.168.1.201 -netmask 255.255.255.0 cluster01::> network interface create -vserver cluster01 -lif cluster01_icl02 -service- policy default-intercluster -home-node cluster01-02 -home-port e0c -address 192.168.1.202 -netmask 255.255.255.0
-
クラスタ間 LIF が作成されたことを確認します。
ONTAP バージョン
コマンドを実行します
ONTAP 9.6 以降
「 network interface show -service -policy default -intercluster 」のように表示されます
ONTAP 9.5 以前
「 network interface show -role intercluster 」の略
コマンド構文全体については、マニュアルページを参照してください。
cluster01::> network interface show -service-policy default-intercluster Logical Status Network Current Current Is Vserver Interface Admin/Oper Address/Mask Node Port Home ----------- ---------- ---------- ------------------ ------------- ------- ---- cluster01 cluster01_icl01 up/up 192.168.1.201/24 cluster01-01 e0c true cluster01_icl02 up/up 192.168.1.202/24 cluster01-02 e0c true -
クラスタ間 LIF が冗長構成になっていることを確認します。
ONTAP バージョン
コマンドを実行します
ONTAP 9.6 以降
「 network interface show – service-policy default-intercluster-failover 」と表示されます
ONTAP 9.5 以前
「 network interface show -role intercluster-failover 」の略
コマンド構文全体については、マニュアルページを参照してください。
次の例は、ポート「 e0c 」上のクラスタ間 LIF 「 cluster01_icl01 」と「 cluster01_icl02 」がポート「 e0d 」にフェイルオーバーされることを示しています。
cluster01::> network interface show -service-policy default-intercluster –failover Logical Home Failover Failover Vserver Interface Node:Port Policy Group -------- --------------- --------------------- --------------- -------- cluster01 cluster01_icl01 cluster01-01:e0c local-only 192.168.1.201/24 Failover Targets: cluster01-01:e0c, cluster01-01:e0d cluster01_icl02 cluster01-02:e0c local-only 192.168.1.201/24 Failover Targets: cluster01-02:e0c, cluster01-02:e0d
クラスタピア関係を作成
MetroCluster クラスタ間にクラスタピア関係を作成する必要があります。
クラスタピア関係を作成
cluster peer create コマンドを使用すると、ローカルクラスタとリモートクラスタ間にピア関係を作成できます。ピア関係が作成されたら ' リモート・クラスタ上で cluster peer create を実行して ' ローカル・クラスタに対してピア関係を認証できます
-
ピア関係にあるクラスタ内の各ノードでクラスタ間 LIF を作成しておく必要があります。
-
クラスタで ONTAP 9.3 以降が実行されている必要があります。
-
デスティネーションクラスタで、ソースクラスタとのピア関係を作成します。
cluster peer create -generate-passphrase -offer-expiration_mm/dd/YYYY HH ： MM ： SS_|1…7days | 1…168 時間 -peer-addrs_peer_lif_ips_-ipspace_ips_`
「 -generate-passphrase 」と「 -peer-addrs 」の両方を指定した場合、生成されたパスワードを使用できるのは、「 -peer-addrs 」にクラスタ間 LIF が指定されているクラスタだけです。
カスタム IPspace を使用しない場合は、 -ipspace オプションを無視してかまいません。コマンド構文全体については、マニュアルページを参照してください。
次の例は、リモートクラスタを指定せずにクラスタピア関係を作成します。
cluster02::> cluster peer create -generate-passphrase -offer-expiration 2days Passphrase: UCa+6lRVICXeL/gq1WrK7ShR Expiration Time: 6/7/2017 08:16:10 EST Initial Allowed Vserver Peers: - Intercluster LIF IP: 192.140.112.101 Peer Cluster Name: Clus_7ShR (temporary generated) Warning: make a note of the passphrase - it cannot be displayed again. -
ソースクラスタで、ソースクラスタをデスティネーションクラスタに対して認証します。
'cluster peer create -peer-addrs_peer_lif_ips_-ipspace_`
コマンド構文全体については、マニュアルページを参照してください。
次の例は、クラスタ間 LIF の IP アドレス 192.140.112.101 および 192.140.112.102 でローカルクラスタをリモートクラスタに対して認証します。
cluster01::> cluster peer create -peer-addrs 192.140.112.101,192.140.112.102 Notice: Use a generated passphrase or choose a passphrase of 8 or more characters. To ensure the authenticity of the peering relationship, use a phrase or sequence of characters that would be hard to guess. Enter the passphrase: Confirm the passphrase: Clusters cluster02 and cluster01 are peered.プロンプトが表示されたら、ピア関係のパスフレーズを入力します。
-
クラスタピア関係が作成されたことを確認します。
「 cluster peer show -instance 」のように表示されます
cluster01::> cluster peer show -instance Peer Cluster Name: cluster02 Remote Intercluster Addresses: 192.140.112.101, 192.140.112.102 Availability of the Remote Cluster: Available Remote Cluster Name: cluster2 Active IP Addresses: 192.140.112.101, 192.140.112.102 Cluster Serial Number: 1-80-123456 Address Family of Relationship: ipv4 Authentication Status Administrative: no-authentication Authentication Status Operational: absent Last Update Time: 02/05 21:05:41 IPspace for the Relationship: Default -
ピア関係にあるノードの接続状態とステータスを確認します。
cluster peer health show
cluster01::> cluster peer health show Node cluster-Name Node-Name Ping-Status RDB-Health Cluster-Health Avail… ---------- --------------------------- --------- --------------- -------- cluster01-01 cluster02 cluster02-01 Data: interface_reachable ICMP: interface_reachable true true true cluster02-02 Data: interface_reachable ICMP: interface_reachable true true true cluster01-02 cluster02 cluster02-01 Data: interface_reachable ICMP: interface_reachable true true true cluster02-02 Data: interface_reachable ICMP: interface_reachable true true true
クラスタピア関係の作成（ ONTAP 9.2 以前）
「 cluster peer create 」コマンドを使用して、ローカルクラスタとリモートクラスタ間のピア関係の要求を開始できます。ピア関係がローカルクラスタによって要求された後 ' リモートクラスタ上で cluster peer create を実行して ' 関係を受け入れることができます
-
ピア関係にあるクラスタ内の各ノードでクラスタ間 LIF を作成しておく必要があります。
-
クラスタ管理者は、各クラスタが他のクラスタに対して自身を認証する際に使用するパスフレーズに同意しておく必要があります。
-
データ保護のデスティネーションクラスタで、データ保護のソースクラスタとのピア関係を作成します。
'cluster peer create -peer-addrs_peer_lif_ips_-ipspace_`
カスタム IPspace を使用しない場合は、 -ipspace オプションを無視してかまいません。コマンド構文全体については、マニュアルページを参照してください。
次の例は、クラスタ間 LIF の IP アドレス 192.168.2.201 および 192.168.2.202 で、リモートクラスタとのクラスタピア関係を作成します。
cluster02::> cluster peer create -peer-addrs 192.168.2.201,192.168.2.202 Enter the passphrase: Please enter the passphrase again:
プロンプトが表示されたら、ピア関係のパスフレーズを入力します。
-
データ保護のソースクラスタで、ソースクラスタをデスティネーションクラスタに対して認証します。
'cluster peer create -peer-addrs_peer_lif_ips_-ipspace_`
コマンド構文全体については、マニュアルページを参照してください。
次の例は、クラスタ間 LIF の IP アドレス 192.140.112.203 および 192.140.112.204 でローカルクラスタをリモートクラスタに対して認証します。
cluster01::> cluster peer create -peer-addrs 192.168.2.203,192.168.2.204 Please confirm the passphrase: Please confirm the passphrase again:
プロンプトが表示されたら、ピア関係のパスフレーズを入力します。
-
クラスタピア関係が作成されたことを確認します。
cluster peer show – instance
コマンド構文全体については、マニュアルページを参照してください。
cluster01::> cluster peer show –instance Peer Cluster Name: cluster01 Remote Intercluster Addresses: 192.168.2.201,192.168.2.202 Availability: Available Remote Cluster Name: cluster02 Active IP Addresses: 192.168.2.201,192.168.2.202 Cluster Serial Number: 1-80-000013
-
ピア関係にあるノードの接続状態とステータスを確認します。
cluster peer health show
コマンド構文全体については、マニュアルページを参照してください。
cluster01::> cluster peer health show Node cluster-Name Node-Name Ping-Status RDB-Health Cluster-Health Avail… ---------- --------------------------- --------- --------------- -------- cluster01-01 cluster02 cluster02-01 Data: interface_reachable ICMP: interface_reachable true true true cluster02-02 Data: interface_reachable ICMP: interface_reachable true true true cluster01-02 cluster02 cluster02-01 Data: interface_reachable ICMP: interface_reachable true true true cluster02-02 Data: interface_reachable ICMP: interface_reachable true true true
ルートアグリゲートをミラーリング
データ保護を提供するには、ルートアグリゲートをミラーする必要があります。
デフォルトでは、ルートアグリゲートは RAID-DP タイプのアグリゲートとして作成されます。ルートアグリゲートのタイプは RAID-DP から RAID4 に変更することができます。次のコマンドは、ルートアグリゲートを RAID4 タイプのアグリゲートに変更します。
「 storage aggregate modify – aggregate_name _raidtype raid4 」と表示されます
|
|
ADP 以外のシステムでは、ミラーリングの実行前後に、アグリゲートの RAID タイプをデフォルトの RAID-DP から RAID4 に変更できます。 |
-
ルートアグリゲートをミラーします。
「 storage aggregate mirror _aggr_name _ 」のようになります
次のコマンドでは 'controller_A_1 のルートアグリゲートがミラーされます
controller_A_1::> storage aggregate mirror aggr0_controller_A_1
これによりアグリゲートがミラーされるため、ローカルのプレックスとリモートのプレックスがリモートの MetroCluster サイトに配置されたアグリゲートが作成されます。
-
MetroCluster 構成の各ノードについて、同じ手順を繰り返します。
各ノードでミラーされたデータアグリゲートを作成します
DR グループの各ノードに、ミラーされたデータアグリゲートを 1 つ作成する必要があります。
-
新しいアグリゲートで使用するドライブまたはアレイ LUN を把握しておきます。
-
複数のドライブタイプを含むシステム（異機種混在ストレージ）の場合は、正しいドライブタイプが選択されるようにする方法を確認しておく必要があります。
-
ドライブとアレイ LUN は特定のノードによって所有されます。アグリゲートを作成する場合、アグリゲート内のすべてのドライブは同じノードによって所有される必要があります。そのノードが、作成するアグリゲートのホームノードになります。
-
アグリゲート名は、 MetroCluster 構成を計画する際に決定した命名規則に従う必要があります。
-
使用可能なスペアのリストを表示します。
「 storage disk show -spare -owner_node_name _ 」というように入力します
-
アグリゲートを作成します。
「 storage aggregate create -mirror true 」のようになります
クラスタ管理インターフェイスでクラスタにログインした場合、クラスタ内の任意のノードにアグリゲートを作成できます。アグリゲートを特定のノード上に作成するには、「 -node 」パラメータを使用するか、そのノードが所有するドライブを指定します。
次のオプションを指定できます。
-
アグリゲートのホームノード（通常運用時にアグリゲートを所有するノード）
-
アグリゲートに追加するドライブまたはアレイ LUN のリスト
-
追加するドライブ数
使用できるドライブ数が限られている最小サポート構成では、 force-small-aggregate オプションを使用して、 3 ディスクの RAID-DP アグリゲートを作成できるように設定する必要があります。 -
アグリゲートに使用するチェックサム形式
-
使用するドライブのタイプ
-
使用するドライブのサイズ
-
使用するドライブの速度
-
アグリゲート上の RAID グループの RAID タイプ
-
RAID グループに含めることができるドライブまたはアレイ LUN の最大数
-
これらのオプションの詳細については 'storage aggregate create のマニュアル・ページを参照してください RPM の異なるドライブでも使用できます
次のコマンドでは、 10 本のディスクを含むミラーアグリゲートが作成されます。
cluster_A::> storage aggregate create aggr1_node_A_1 -diskcount 10 -node node_A_1 -mirror true [Job 15] Job is queued: Create aggr1_node_A_1. [Job 15] The job is starting. [Job 15] Job succeeded: DONE
-
-
新しいアグリゲートの RAID グループとドライブを確認します。
「 storage aggregate show-status -aggregate _aggregate-name _ 」を参照してください
ミラーされていないデータアグリゲートの作成
MetroCluster 構成が提供する冗長なミラーリングを必要としないデータについては、必要に応じてミラーされていないデータアグリゲートを作成できます。
-
新しいアグリゲートで使用するドライブまたはアレイ LUN を把握しておきます。
-
複数のドライブタイプを含むシステム（異機種混在ストレージ）の場合は、正しいドライブタイプが選択されていることを確認する方法を理解しておく必要があります。
-
注意 * ： MetroCluster FC 構成では、ミラーされていないアグリゲートがスイッチオーバー後にオンラインになるのは、アグリゲート内のリモートディスクにアクセスできる場合のみです。ISL で障害が発生すると、ミラーされていないリモートディスク内のデータにローカルノードがアクセスできなくなる可能性があります。アグリゲートに障害が発生すると、ローカルノードがリブートされる場合があります。
|
|
ミラーされていないアグリゲートは、そのアグリゲートを所有するノードに対してローカルでなければなりません。 |
-
ドライブとアレイ LUN は特定のノードによって所有されます。アグリゲートを作成する場合、アグリゲート内のすべてのドライブは同じノードによって所有される必要があります。そのノードが、作成するアグリゲートのホームノードになります。
-
アグリゲート名は、 MetroCluster 構成を計画する際に決定した命名規則に従う必要があります。
-
。 "ディスクとアグリゲートの管理" アグリゲートのミラーリングの詳細については、を参照してください
-
使用可能なスペアのリストを表示します。
「 storage disk show -spare -owner_node_name _ 」というように入力します
-
アグリゲートを作成します。
「 storage aggregate create 」
クラスタ管理インターフェイスでクラスタにログインした場合、クラスタ内の任意のノードにアグリゲートを作成できます。アグリゲートが特定のノード上に作成されていることを確認するには、「 -node 」パラメータを使用するか、そのノードが所有するドライブを指定します。
次のオプションを指定できます。
-
アグリゲートのホームノード（通常運用時にアグリゲートを所有するノード）
-
アグリゲートに追加するドライブまたはアレイ LUN のリスト
-
追加するドライブ数
-
アグリゲートに使用するチェックサム形式
-
使用するドライブのタイプ
-
使用するドライブのサイズ
-
使用するドライブの速度
-
アグリゲート上の RAID グループの RAID タイプ
-
RAID グループに含めることができるドライブまたはアレイ LUN の最大数
-
これらのオプションの詳細については 'storage aggregate create のマニュアル・ページを参照してください RPM の異なるドライブでも使用できます
次のコマンドでは、 10 本のディスクを含むミラーされていないアグリゲートが作成さ
controller_A_1::> storage aggregate create aggr1_controller_A_1 -diskcount 10 -node controller_A_1 [Job 15] Job is queued: Create aggr1_controller_A_1. [Job 15] The job is starting. [Job 15] Job succeeded: DONE
-
-
新しいアグリゲートの RAID グループとドライブを確認します。
「 storage aggregate show-status -aggregate _aggregate-name _ 」を参照してください
MetroCluster 構成の実装
MetroCluster 構成でデータ保護を開始するに MetroCluster は 'data configure コマンドを実行する必要があります
-
ルート以外のミラーされたデータアグリゲートが各クラスタに少なくとも 2 つ必要です。
その他のデータアグリゲートはミラーされていてもいなくてもかまいません。
アグリゲートのタイプを確認します。
「 storage aggregate show
ミラーされた単一のデータアグリゲートを使用する場合は、を参照してください "ONTAP で MCC ソフトウェアを設定" 手順については、を参照し -
コントローラおよびシャーシの ha-config の状態が「 mcc-2n 」である必要があります。
MetroCluster 構成をイネーブルにするには、任意のノード上で、 MetroCluster configure コマンドを 1 回実行し問題ます。サイトごとまたはノードごとにコマンドを問題で実行する必要はありません。また、問題するノードまたはサイトはどれでもかまいません。
-
次の形式で MetroCluster を設定します。
MetroCluster 構成の内容
操作
複数のデータアグリゲート
いずれかのノードのプロンプトで、 MetroCluster を設定します。
MetroCluster configure_node-name_` です
ミラーされた 1 つのデータアグリゲート
-
いずれかのノードのプロンプトで、 advanced 権限レベルに切り替えます。
「 advanced 」の権限が必要です
advanced モードで続けるかどうかを尋ねられたら、「 y 」と入力して応答する必要があります。 advanced モードのプロンプト（ * > ）が表示されます。
-
MetroCluster に -allow-with-one-aggregate true パラメータを設定します。
「 MetroCluster configure -allow-with-one-aggregate true_node-name_` 」
-
admin 権限レベルに戻ります。 +
set -privilege admin
複数のデータアグリゲートを使用することを推奨します。最初の DR グループにアグリゲートが 1 つしかなく、 1 つのアグリゲートを含む DR グループを追加する場合は、メタデータボリュームを単一のデータアグリゲートから移動する必要があります。この手順の詳細については、を参照してください "MetroCluster 構成でのメタデータボリュームの移動"。 次のコマンドは 'controller_A_1 を含む DR グループ内のすべてのノードで MetroCluster 構成を有効にします
cluster_A::*> metrocluster configure -node-name controller_A_1 [Job 121] Job succeeded: Configure is successful.
-
-
サイト A のネットワークステータスを確認します。
「 network port show 」のように表示されます
次の例は、ネットワークポートの用途を示しています。
cluster_A::> network port show Speed (Mbps) Node Port IPspace Broadcast Domain Link MTU Admin/Oper ------ --------- --------- ---------------- ----- ------- ------------ controller_A_1 e0a Cluster Cluster up 9000 auto/1000 e0b Cluster Cluster up 9000 auto/1000 e0c Default Default up 1500 auto/1000 e0d Default Default up 1500 auto/1000 e0e Default Default up 1500 auto/1000 e0f Default Default up 1500 auto/1000 e0g Default Default up 1500 auto/1000 7 entries were displayed. -
MetroCluster 構成の両方のサイトから MetroCluster 構成を確認します。
-
サイト A から構成を確認します :+
MetroCluster showcluster_A::> metrocluster show Cluster Entry Name State ------------------------- ------------------- ----------- Local: cluster_A Configuration state configured Mode normal AUSO Failure Domain auso-on-cluster-disaster Remote: cluster_B Configuration state configured Mode normal AUSO Failure Domain auso-on-cluster-disaster -
サイト B から構成を確認します + MetroCluster show
cluster_B::> metrocluster show Cluster Entry Name State ------------------------- ------------------- ----------- Local: cluster_B Configuration state configured Mode normal AUSO Failure Domain auso-on-cluster-disaster Remote: cluster_A Configuration state configured Mode normal AUSO Failure Domain auso-on-cluster-disaster
-
健常性監視用の FC-to-SAS ブリッジの設定
9.8 より前のバージョンの ONTAP を実行しているシステムで FC-to-SAS ブリッジを使用している場合は、 MetroCluster 構成の FC-to-SAS ブリッジを監視するための特別な設定手順を実行する必要があります。
-
FibreBridge ブリッジでは、サードパーティ製の SNMP 監視ツールはサポートされません。
-
ONTAP 9.8 以降では、デフォルトで FC-to-SAS ブリッジがインバンド接続で監視されるため、追加の設定は必要ありません。
|
|
ONTAP 9.8 以降では 'storage bridge コマンドは 'system bridge コマンドに置き換えられました次の手順は「 storage bridge 」コマンドを示していますが、 ONTAP 9.8 以降を実行している場合は「 system bridge 」コマンドが優先されます。 |
-
ONTAP クラスタのプロンプトで、ブリッジをヘルスモニタの対象に追加します。
-
使用している ONTAP のバージョンに対応したコマンドを使用して、ブリッジを追加します。
ONTAP バージョン
コマンドを実行します
ONTAP 9.5 以降
「 storage bridge add -address 0.0.0.0 -managed-by in-band-name_bridge-name_`
ONTAP 9.4 以前
「 storage bridge add -address_bridge-ip-address_-name_bridge-name_` 」
-
ブリッジが追加され、正しく設定されていることを確認します。
「 storage bridge show 」
ポーリング間隔に応じて、すべてのデータが反映されるまで 15 分程度かかる場合があります。ONTAP ヘルスモニタは、「 Status 」列の値が「 ok 」で、ワールドワイド名（ WWN ）などのその他の情報が表示されていれば、ブリッジに接続して監視できます。
次の例は、 FC-to-SAS ブリッジが設定されていることを示しています。
controller_A_1::> storage bridge show Bridge Symbolic Name Is Monitored Monitor Status Vendor Model Bridge WWN ------------------ ------------- ------------ -------------- ------ ----------------- ---------- ATTO_10.10.20.10 atto01 true ok Atto FibreBridge 7500N 20000010867038c0 ATTO_10.10.20.11 atto02 true ok Atto FibreBridge 7500N 20000010867033c0 ATTO_10.10.20.12 atto03 true ok Atto FibreBridge 7500N 20000010867030c0 ATTO_10.10.20.13 atto04 true ok Atto FibreBridge 7500N 2000001086703b80 4 entries were displayed controller_A_1::>
-
MetroCluster の設定を確認しています
MetroCluster 構成内のコンポーネントおよび関係が正しく機能していることを確認できます。チェックは、初期設定後と、 MetroCluster 設定に変更を加えたあとに実施する必要があります。また、ネゴシエート（計画的）スイッチオーバーやスイッチバックの処理の前にも実施します。
いずれかまたは両方のクラスタに対して短時間に MetroCluster check run コマンドを 2 回発行すると ' 競合が発生し ' コマンドがすべてのデータを収集しない場合がありますそれ以降の「 MetroCluster check show 」コマンドでは、期待される出力が表示されません。
-
構成を確認します。
「 MetroCluster check run 」のようになります
このコマンドはバックグラウンドジョブとして実行され、すぐに完了しない場合があります。
cluster_A::> metrocluster check run The operation has been started and is running in the background. Wait for it to complete and run "metrocluster check show" to view the results. To check the status of the running metrocluster check operation, use the command, "metrocluster operation history show -job-id 2245"
cluster_A::> metrocluster check show Component Result ------------------- --------- nodes ok lifs ok config-replication ok aggregates ok clusters ok connections ok volumes ok 7 entries were displayed.
-
より詳細な結果を表示します。
「 MetroCluster check run 」のようになります
MetroCluster check aggregate show
MetroCluster check cluster show
MetroCluster check config-replication show
MetroCluster check lif show
MetroCluster check node show
「 MetroCluster check show 」コマンドは、最新の「 MetroCluster check run 」コマンドの結果を表示します。MetroCluster check show コマンドを使用する前に ' 必ず MetroCluster check run コマンドを実行して ' 表示されている情報が最新であることを確認してください
次に、正常な 4 ノード MetroCluster 構成の MetroCluster check aggregate show コマンドの出力例を示します。
cluster_A::> metrocluster check aggregate show Last Checked On: 8/5/2014 00:42:58 Node Aggregate Check Result --------------- -------------------- --------------------- --------- controller_A_1 controller_A_1_aggr0 mirroring-status ok disk-pool-allocation ok ownership-state ok controller_A_1_aggr1 mirroring-status ok disk-pool-allocation ok ownership-state ok controller_A_1_aggr2 mirroring-status ok disk-pool-allocation ok ownership-state ok controller_A_2 controller_A_2_aggr0 mirroring-status ok disk-pool-allocation ok ownership-state ok controller_A_2_aggr1 mirroring-status ok disk-pool-allocation ok ownership-state ok controller_A_2_aggr2 mirroring-status ok disk-pool-allocation ok ownership-state ok 18 entries were displayed.次に、正常な 4 ノード MetroCluster 構成の MetroCluster check cluster show コマンドの出力例を示します。この出力は、必要に応じてネゴシエートスイッチオーバーを実行できる状態であることを示しています。
Last Checked On: 9/13/2017 20:47:04 Cluster Check Result --------------------- ------------------------------- --------- mccint-fas9000-0102 negotiated-switchover-ready not-applicable switchback-ready not-applicable job-schedules ok licenses ok periodic-check-enabled ok mccint-fas9000-0304 negotiated-switchover-ready not-applicable switchback-ready not-applicable job-schedules ok licenses ok periodic-check-enabled ok 10 entries were displayed.
Config Advisor での MetroCluster 構成エラーの確認
一般的な構成エラーの有無を確認する Config Advisor ツールをネットアップサポートサイトからダウンロードできます。
Config Advisor は、構成の検証や健常性のチェックに使用できるツールです。データ収集とシステム分析のために、セキュアなサイトにもセキュアでないサイトにも導入できます。
|
|
Config Advisor のサポートには制限があり、オンラインでしか使用できません。 |
-
Config Advisor のダウンロードページにアクセスし、ツールをダウンロードします。
-
Config Advisor を実行し、ツールの出力を確認して、問題が検出された場合は出力に表示される推奨事項に従って対処します。
スイッチオーバー、修復、スイッチバックを検証しています
MetroCluster 構成のスイッチオーバー、修復、スイッチバックの処理を検証する必要があります。
-
に記載されているネゴシエートスイッチオーバー、修復、スイッチバックの手順を使用し "スイッチオーバー、修復、スイッチバックを実行"ます。
構成バックアップファイルを保護しています
ローカルクラスタ内のデフォルトの場所に加えて、クラスタ構成バックアップファイルをアップロードするリモート URL （ HTTP または FTP ）を指定することで、クラスタ構成バックアップファイルの保護を強化できます。
-
構成バックアップファイルのリモートデスティネーションの URL を設定します。
「システム構成のバックアップ設定は URL-of-destination 」を変更します
。 "CLI を使用したクラスタ管理" 追加情報が含まれています。