こんにちは、キクです。
システム障害や自然災害など、企業としての活動の継続に支障が出る状況を想定して、システムの復旧における方法を検討しておくことは非常に重要です。
いわゆる｢DR対策｣というやつですね。
ストレージシステムであるNetAppにおいても、代表的な技術の1つである｢SnapMirror｣を活用することでDR対策が可能になります。
というわけで、今回は『SnapMirrorの基本的な設定方法』をテーマに書いていきたいと思います！
本記事の内容
それでは、よろしくお願いします。
SnapMirrorについて
まずはじめに「SnapMirrorとはなんぞや？」という部分について簡単に触れていこうと思います。
SnapMirrorは「同一クラスタ内」または「異なるクラスタ間」でデータを複製（Replicate）する機能になります。
詳しい設定方法については後述しますが、転送元（ソース）と転送先（ターゲット）の関係にあるボリュームを「手動」または「スケジュール」によってデータ転送するのがSnapMirrorとなります。
なお、本記事では｢異なるクラスタ間｣でのSnapMirror設定を例に進めていきたいと思います。
SnapMirrorの特徴の1つとして「Snapshot技術を利用している」ということが挙げられます。
毎回ソース側のすべてのデータを転送していては時間がかかってしまいます。
しかしSnapshot技術を活用することで、前回の転送からの差分を把握し、その差分データのみを転送対象とすることで効率的に転送を行うことが可能になります。
ちなみに冒頭でも触れたように、SnapMirrorはDR対策として活用するケースがメインとなりますので、データをリストアすることも可能です。
通常「ソース → ターゲット」へと転送している関係性を「ソース ← ターゲット」として転送（逆再同期）することでターゲット側のデータをソース側に復旧（リストア）することできるという挙動になります。
SnapMirror設定に必要な事前作業
SnapMirrorを設定するためにはいくつか事前準備が必要になります。
ここでは大きく4つのステップに分けて作業を実施します。
ステップ1〜3はソース/ターゲットの両クラスタで作業が必要になります。
ステップ4も両クラスタで作業が必要ですが、こちらは「申請/受入」という形での作業となります。
ステップ1：SnapMirror用設定
①ブロードキャストドメイン作成
まずは、SnapMirror通信で利用されるブロードキャストドメインを作成していきます。
ここでは、ブロードキャストドメイン名を「InterCluster」という名前で設定します。
::> broadcast-domain create -broadcast-domain InterCluster -mtu 1500 -ipspace Default②ブロードキャストドメインへのポート追加
次に、作成したブロードキャストドメインにポートを追加します。
1ノードあたり最低2つ以上のポートを追加することで冗長性を高めることができます。
少し脱線しますが、SnapMirror通信で利用するLIFに割り当てるロール「intercluster」のフェイルオーバーポリシーは、デフォルトで「local-only」が設定されます。
これは後続作業で作成するLIFのフェイルオーバー先が自ノードのみであることを意味します。
そのため、1ノードあたり1ポートで構成してしまうとLIFはパートナーノードにフェイルオーバできないので「非冗長構成」になってしまうという点には注意が必要です。
::> broadcast-domain add-ports -broadcast-domain InterCluster -ports ノード名1:ポート名1,ノード名1:ポート名2,･･･,ノード名2:ポート名1,ノード名2:ポート名2,･･･上記はいくつかの物理ポートをそのままブロードキャストドメインに追加した例になりますが、物理ポートをインターフェイスグループでまとめてから追加するのでも問題ありません。
::> broadcast-domain add-ports -broadcast-domain InterCluster -ports ノード名1:インターフェイスグループ名1,ノード名2:インターフェイスグループ名1個人的には後者の方が単一のポート障害時であればLIFの移動がそもそも発生しないので好きですね。
③LIFの作成
続いて、SnapMirror通信で利用するLIFを作成します。
ここでは、例としてコントローラ1側LIFを「intercluster1（またはintercluster3）」、コントローラ2側LIFを「intercluster2（またはintercluster4）」として設定します。
なお、ホームポートには②でブロードキャストドメインに追加したインターフェイスグループ(またはポート)を指定します。
::> network interface create -vserver クラスタ名 -lif intercluster1 -role intercluster -home-node コントローラ名1 -home-port インターフェイスグループ名1 -address xx.xx.xx.xx -netmask xx.xx.xx.xx -broadcast-domain InterCluster -firewall-policy intercluster -auto-revert false
::> network interface create -vserver クラスタ名 -lif intercluster2 -role intercluster -home-node コントローラ名2 -home-port インターフェイスグループ名1 -address xx.xx.xx.xx -netmask xx.xx.xx.xx -broadcast-domain InterCluster -firewall-policy intercluster -auto-revert falseステップ2：物理接続
続いて物理作業。
ステップ1でブロードキャストドメイン「InterCluster」に追加した物理ポートを接続します。
ソース/ターゲットの双方で接続が完了したら、疎通確認をしておきましょう。
::> network ping -vserver クラスタ名 -lif InterCluster1 -destination xx.xx.xx.xxステップ3：クラスタピア関係の確立
冒頭でも触れましたが、本記事では異なるクラスタ間でのSnapMirrorを扱います。
ここではSnapMirror先（ターゲット）となるクラスタとピア関係を設定していきます。
①事前確認
設定前のクラスタピア設定状態を確認します。
::> cluster peer show -instance②クラスタピア関係の設定
対向側クラスタのSnapMirror用LIFに設定されたIPアドレスを指定してクラスタピア関係を確立します。
::> cluster peer create -peer-addrs IPアドレス1,IPアドレス2なお、上記で指定している各IPアドレスには以下を指定します。
③事後確認
クラスタピア関係が設定されたことを確認します。
::> cluster peer show -instanceステップ4：SVMピア関係の確立
クラスタのピア設定が完了したら、次はSnapMirrorで利用するボリュームを管理するSVM同士でピア関係を設定していきます。
本作業は、一方のクラスタから「申請」を実施し、もう一方のクラスタで「受け入れ」という形で作業を進めていきます。
本記事ではターゲット側でSVMピア関係確立の申請を実施し、ソース側で受け入れるという流れとします。
①事前確認
クラスタピア関係と同様に、設定前のSVMピア設定状態を確認します。
::> vserver peer show②SVMピア申請（ターゲットクラスタ作業）
ターゲットクラスタからSVMピア設定の申請を実施します。
::> vserver peer create -vserver ターゲットSVM名 -peer-cluster ターゲットクラスタ名 -peer-vserver ソースSVM名 -applications snapmirror -local-name ソースSVMエイリアス名オプション「-local-name」はターゲット側で管理する上でのみ利用するソースSVMの別名になります。
ソースクラスタが複数存在し、同じSVM名のSVMピア関係を作成するような場合にはどのクラスタのSVMなのか判別できなくなってしまいます。
そうした場合にターゲット側で別名をつけておくことで判別できるようにしておきます。
実際のSVM名が変更されてしまうなどの影響はないので、判別しやすい名前をつけておきましょう。
以下は実際に入力した例になります。
::> vserver peer create -vserver dstSVM -peer-cluster dstcluster -peer-vserver srcSVM -applications snapmirror -local-name srcSVM_aliasSVMピア関係が追加されたことを確認します。
この時点ではPeer Stateという項目が「initiated」と表示されていれば問題ありません。
::> vserver peer show③SVMピア申請の受け入れ（ソースクラスタ作業）
ソースクラスタでターゲット側から実施したSVMピア申請を受け入れていきます。
::> vserver peer accept -vserver ソースSVM名 -peer-vserver ターゲットSVM名以下は実際に入力した例になります。
::> vserver peer accept -vserver srcSVM -peer-vserver dstSVMSVMピア関係一覧を確認します。
::> vserver peer show受け入れたSVMピア情報が表示され、Peer Stateが「peered」となっていれば無事SVMピア関係が成立しました。
ターゲット側でも同じ状態になっていることを確認しておきましょう。
SnapMirror設定
いよいよSnapMirrorを設定していきます。
本記事では、ターゲットクラスタで作業を実施していきます。
また、ソースボリュームおよびターゲットボリュームは既に存在するものとして進めていきます。
ステップ1：SnapMirror関係の作成
まずは、ソースボリュームとターゲットボリュームとでSnapMirror関係を作成します。
::> snapmirror create -source-path ソースパス -destination-path ターゲットパス -policy SnapMirrorポリシー名 -schedule SnappMirrorスケジュール名各パスは次のような形式で入力します
以下は実際に入力した例になります。
::> snapmirror create -source-path srcSVM_alias:srcVOL -destination-path dstSVM:dstVOL -policy MirrorAllSnapshots -schedule dailySnapMirror関係が作成されたことを確認します。
::> snapmirror showステップ2：SnapMirror関係の初期化
最後にSnapMirror関係の初期化を実施します。
これによりSnapMirrorで必要なベーススナップショットが作成され、データ転送も可能な状態が整います。
::> snapmirror initialize -source-path ソースパス -destination-path ターゲットパス以下は実際に入力した例になります。
::> snapmirror initialize -source-path srcSVM_alias:srcVOL -destination-path dstSVM:dstVOL改めてSnapMirror関係を確認します。
::> snapmirror show先程まで「Uninitialized」だったMirror Stateが「Snapmirrored」になっているかと思います。
これにて基本的なSnapMirror関係の設定は完了です。
お疲れさまでした。
本項で登場した「ベーススナップショット」について触れた記事を以前書いているので、興味のある方は読んでみてください。
関連記事：【NetApp】SnapMirrorが突如転送できなくなった原因と対応
おわりに
いかがだったでしょうか。
今回はストレージのDR対策として活用される｢SnapMirrorの基本的な設定方法」についての内容でした。
設定パターンとしては本記事でご紹介したもの以外にも様々あるかとは思いますが、｢クラスタやSVMのピア設定も必要なのかー｣などSnapMirror設定の全体像に対する理解が少しでも深まっていたら嬉しいです。
本記事を最後までお読みいただきありがとうございました。
ではでは！