そうか、そうか

~とあるSIerの、哀と涙の軌跡~

FSx for NetApp ONTAPへデータ移行をやってます~その1~

どうも何者でもない私です。

 

今回は「オンプレミスのファイルサーバ」をFSxへ移行をする機会がありましたので、その内容を皆さんにお伝えしようと思います。

 

結構長くなるので、何回かに分けてのご紹介です!

その1では、「前準備」ということで、注意点などについてご紹介しようと思います。

※内容としては、FSx側というより、オンプレミス側の視点が中心です。

 

 

VMware Cloud on AWSなんかでも使えるようになったFSx

FSxは、AWSが提供するストレージサービスです。

 

最近だと、vSANストレージしか使えなかったVMware Cloud on AWSで、データストアとしてFSx for NetApp ONTAPが使えるようになったというのが、私の中で話題になっていました。

docs.vmware.com

 

今日、ファイルサーバーがない企業さんは中々ないと思いますが、増え続けるファイルやフォルダのデータの保管先として、クラウド環境が選択肢に入るケースもあるのではないでしょうか。

 

ただ、規模の大きい企業さんだと、それこそTBを超えてPBに近いデータを保持される場合もあり、1Gbps程度のネットワーク帯域ではデータの移行をやるのも一苦労です。

 

もしも、あなたの企業がNetAppのストレージを使っていたら…

もしも、あなたの企業がAWSを使っていたら…

 

FSx for NetApp ONTAPへの移行が、ちょっと楽になるかもしれません。

 

実はやったことがない。NetApp

3月まで30TB近いファイルサーバの移行案件(しかもRobocopy)をやっていた私は、

心境的に「ファイルサーバの移行?死んでも嫌だねー!

な、状態だったのですが、4月に入るとSEというのは比較的になる職業でして…

手が空いてしまった私は、泣く泣くファイルサーバの移行をやらされやりました。

しかも、NetAppの移行。

え、私NetAppとかやったことないけど?

 

このNetApp。

実に単語がややこしく、専門の用語が多いこと多いこと…

・LIF

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

・Snapshot

・SnapMirror

・SnapVault

・アグリゲート

・SVM

・ルートボリューム

などなど…

 

30歳を越えて、頭がボケ始めている私には中々キツい。

 

しかも、これらの単語はすべて密接に関係しているため、どれか一つでも理解できていないと、連鎖的に他の物がわからなくなるという、おまけつき。

 

昔の職場にNetAppができる、というだけで重宝されてるSEさんがいたけど、理由がよくわかります。

 

 

移行の構成

今回取り扱った環境は中々面白く、すでにオンプレミスでSnapMirrorが構成されている2台のNetAppがありました。

 

この環境のデータをFSxに持っていくことになります。

RobocopyでFSxへデータを持って行ってもいいのですが、せっかくNetAppを使っているのです。

 

SnapMirrorを使って移行してみましょう!

 

SnapMirrorってなんだべさ?

SnapMirrorとは、

 

SnapMirrorは、NetAppのストレージシステムで使用されるデータ転送技術の一つで、データのレプリケーションを実現するためのソフトウェアです。

SnapMirrorは、プライマリストレージシステムからセカンダリストレージシステムへのデータの自動的かつ高速な転送を可能にします。この技術により、データのバックアップ、災害復旧、データのテストや開発用途などに利用されます。

SnapMirrorは、差分転送機能を備えており、変更されたブロックのみを転送することができるため、効率的にデータを転送することができます。また、高速なネットワーク接続を利用することで、遅延を最小限に抑えることができます。

 

by ChatGPTさん

 

つまり、ストレージ間のレプリケーション技術のことですね。(投げやり)

 

↓以下、NetAppさんのページから抜粋した図です。

SnapMirrorレプリケーションのためのストレージ システムの準備

 

ここでいう「デスティネーション」がFSxになるわけです。

 

Robocopyだと、ファイル単位の転送になるので、非常に多くの時間を要しますが、SnapMirrorの転送はNetAppというストレージに最適化された転送方式です。

 

結論から言うと注意すべき点は、

  1. FSx for NetApp ONTAP(移行先)と、オンプレミス側のNetApp(移行元)のバージョン互換性
  2. SnapMirrorのレプリケーション形式が何か?
  3. クラスタ間LIFの構成状態はどうなっているか?
  4. SnapMirrorライセンスは持っているか?

主に、この4点でした。

 

細かい話をすると、もっとあるのだとは思いますが、私がやったケースではこの4点が要注意のポイントでした。

※他だと、「ボリュームの暗号化は使っているか」などもあると思います。

 

SnapMirrorは無制限にできるわけじゃない

ポイント1:互換性を確認せよ!

なんでもそうなのですが、機器と機器、システムとシステム、機器とシステム。

それぞれに、「互換性」というものがあります。

 

まずは、SnapMirrorが使えるかFSxと移行元のNetAppのバージョン互換性を確認してみましょう。

 


2023年6月現在、FSxのバージョンは9.11 P16 でした。

例えば、今のバージョンが9.3だと、9.11のFSxとは互換性がありません。

とすると、FSxとSnapMirrorをするために、ONTAPのバージョンアップが必要になるかもしれませんね。

 

今回だと、この絵の通り、ONTAPのバージョンが少し古く、FSxとの互換性がありませんでした。

 

よって、SnapMirrorのためにONTAPのバージョンアップを余儀なくされました。

 

こいつが曲者。レプリケーション方式

ポイント2:DP形式なら、XDP形式へ変更せよ!

SnapMirrorには、DPとXDPという2種類のレプリケーション形式があります。

 

ものすごくざっくり言うと、

  1. DPは、バージョン互換性が厳しいレプリケーション方式
  2. XDPは、バージョン互換性にあまり縛られないレプリケーション方式

です。

 

ONTAP 9.5以降(?)は、XDP形式が主流になっていますが、それ以前のバージョンでは特に指定しない限り、DP形式になります。

 

もし、私と同じように、ポイント1の問題にひっかかり、ONTAPのバージョンアップを検討しないといけない場合DP形式を使用していると、ONTAPのバージョンアップ後に従来のSnapMirrorが使えなくってしまう可能性があります。

 

 

なので、DP形式は使わずXDP形式へ変換すること検討しましょう。

↓snapmirror show とか叩くと「Type」列に記載が出てくる。

 

どうしても、変換が嫌なら、2台のNetAppを両方ともバージョンアップすればいいのですが、そもそもバージョンアップ作業自体、ハードルが中々高い作業だと思うので、バージョンアップを1台で済ませたいなら、やはりこの変換はやっておくべきでしょう。

 

種類多すぎぃ!クラスタ間LIF

ポイント3:クラスタ間LIFがFSxと通信可能かを確認せよ!

 

LIFって、単語がですよね。。。

大人しく、ネットワークインターフェースだけでいいのに…

 

さて、LIFとはLogical InterFaceの略称です。

単語に踊らされる必要はなく、要はNetAppにおける仮想ネットワークだと思ってもらえればよいと思います。

 

このネットワークは、色々と種類がありまして。

など、様々な種類(役割)があります。

 

SnapMirrorを使う上で重要なのは

クラスタ

データ提供(大体はSVM管理と兼ねてるかな?)

この2つです。

 

クラスタ間LIFとは、

クラスタクラスタを接続するためのネットワークです。

NetAppでインターフェースを作成するときなんかにも選択肢の一つとして登場します。

クラスタは、ノード間で構成されます。(単一ノードでも構成可能)

ノードとは、ざっくりいうとNetApp筐体における「コントローラー」のことです。

 

SnapMirrorのデータは、クラスタ間LIFを通じて行われますので、

今回だと、オンプレミスのクラスタ間LIFとFSxのクラスタ間LIFの疎通が取れていることが重要です。

 

FSxをデプロイすると、最初からこの「クラスタ間LIF」が定義されて出来上がります。

↓ inter_1とinter_2と書いてるのが、「クラスタ間LIF」です。

 

 

これがなきゃ詰む。ライセンス

ポイント4:SnapMirrorのライセンスは双方向で必要なんだよ!

SnapMirrorは、ソース側 / デスティネーション側 両方でSnapMirrorライセンスが必要です。

デスティネーション側、つまりFSxにはSnapMirrorをするためのライセンスがあります。

問題は、ソース側。

ソース側にライセンスないとそもそもSnapMirrorができません。

ポイント4で書きましたが、これ、真っ先に確認すべき内容ですね。

 

移行のトポロジー

今回、私が関与したプロジェクトでは、SnapMirror構成を「カスケード接続」して、FSxへデータ移行することを決めました。

オンプレミス側で行っているSnapMirrorをさらにもう一段階、SnapMirrorを行ってFSxに持っていきます。

そのために、クリアしないといけないのは…ポイント1の「ONTAPの互換性」ですね。

ONTAPのバージョンを上げて、FSxとの互換性が取れるようにする必要があります。

 

最後に

SnapMirrorを使ってFSxへ移行するための「前段階」で注意すべき点をご紹介しました。

次回以降は、ポイント1と2について、もう少し技術的な部位をご紹介しようと思います。

 

ではでは。