NetAppのデータをFSx for NetApp ONTAPへデータ移行してみた①

どうも、GOKUSANです。

先日、とあるお客様でNetAppをカスケード接続して、最終的にデータをFSx for NetApp ONTAPへ持っていくという作業をやりました。
NetApp全くの未経験の私には中々にきつかったので、注意点などをメモとして残したいと思います。


## NetAppには独自の用語が多い
ファイルベースストレージの代表格ともいえるNetAppは、ファイルサーバとしての利用はもちろん、仮想化基盤の共有ストレージとしても多く用いられます。

私もVMware vSphereの共有ストレージとしてNetAppを触る機会は多かったのですが、どうもNetAppは専門用語が多く、どうも苦手意識が強くありました。

例えば…
アグリゲート
SVM
LIF
などがそうですね。

そんな中で、ファイルサーバとして利用されているNetAppのデータをFSx for NetApp ONTAP(以降、FSxN)へ移行し、オンプレミスのNetAppを廃止するという作業をご依頼いただきました。


## FSxNへデータを持っていくために
「SnapMirror」を使えばいいかなぁ、という点はNetAppを扱ったことがある方なら、考えるのではないでしょうか。
実際、私もそう考えていたのですが、これが中々にハードルが高かったです。

:::note warn
**ライセンスについて**
SnapMirrorによる移行には、**移行元と移行先両方**に「SnapMirror」のライセンスが必要です。
FSxNには、最初からSnapMirrorのライセンスが含まれています。
:::

### 今回の構成
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3552050/ca9ec171-be98-efe3-213b-0bc055c3464c.png)

オンプレミスではすでに2台のNetAppが稼働しており、SnapMirrorが運用されています。
オンプレミスのNetAppに格納されているデータFSxNにもっていかないといけません。

まず基本的な移行方針として<font color="Blue">**カスケード接続**</font>でFSxNへSnapMirrorをすることを思いつきました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3552050/8b845455-02d6-19ad-cf66-fd3b9c852fdb.png)

理由としては、絵で言うと**真ん中にあるNetApp機器は現行SnapMirrorの複製先…言うなれば「バックアップストレージ」**だったからです。
なので、バックアップストレージとFSxNの間で細々とSnapMirrorを流しておけばお客様の業務に影響がでないかなーと考えました。

さて、FSxNのONTAPバージョンは2023年9月現在 **9.12.1**です。(絵は、2023年6月時点のものなので9.11です)
対して、今回の移行対象は **9.3**。

幸いなことにメジャーバージョンは一緒でしたが、マイナーバージョンに結構な乖離があります。
この状態でSnapMirrorはできるのでしょうか？

結論から言うと<font color="Red">**できません**</font>。

### バージョンアップが必要なんだよ
NetAppのマニュアルにも載っていますが、SnapMirrorをやるにはONTAPの互換性が取れてなきゃダメです。

https://docs.netapp.com/ja-jp/ontap/data-protection/compatible-ontap-versions-snapmirror-concept.html#%E3%83%A6%E3%83%8B%E3%83%95%E3%82%A1%E3%82%A4%E3%83%89%E3%83%AC%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E9%96%A2%E4%BF%82

マニュアルによると9.3と互換性があるのは「9.8」ぐらいまでですね。
しかしながら、FSxNは、AWSが提供するサービスですから**バージョンなんて選べません**。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3552050/37e27d88-f1ee-3ce2-f14e-1990937db0b0.png)


よって、**オンプレミス側のNetAppをバージョンアップ**しないといけません。

:::note warn
ここで注意すべきは、
①　オンプレミス側の機器がどこまでONTAPバージョンを上げられるか？
②　すでにオンプレミスでSnapMirrorが構成されているが、両方の機器をバージョンアップしないといけないか？

の2点です。
:::

## バージョンアップによる影響
ONTAPはマイナーバージョン内でも色々と手が加えられており、元々使えていたものが後のバージョンで使えなくなっていることもあります。

今回のバージョンアップいうと、「SnapMirror」の形式がそれにあたります。
上記、①については「9.7」まで上げられるようでした。
では、②についてはどうでしょうか？

### DP形式とXDP形式
SnapMirrorの形式として存在するこれですが、結論から言うと今のONTAPバージョンでは**DP形式**は使えません。
これはレガシーなレプリケーション形式でして、現在では**XDP形式**と呼ばれるものに置き換わっています。

ONTAPのバージョンによっては、SnapMirrorをコマンドで作成する際のデフォルトの形式が「DP形式」のものと「XDP形式」があります。

今回のオンプレミス側ONTAPのバージョン9.3は過渡期でして、運悪く「DP形式」でSnapMirrorが構成されていました。

さて、「DP形式」だと何が運が悪いのかというと、
**DP形式は、SnapMirror構成時の互換性が超狭い**のです。

今回のオンプレミスの機器は、HWの制限上「9.7」までしONTAPバージョンを上げられません。
FSxNとSnapMirrorをするために、9.7までバージョンアップを行う・・・これ自体はOKですが、
仮に、2台のNetAppの内、片側だけをバージョンアップすると何が起きるのでしょうか？

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3552050/315e2c14-545d-41c4-16f3-5772b8d7f735.png)

はい。
この絵のように、DP形式のままではオンプレミス機器間でのSnapMirrorが構成できなくなってしまいます。
これは、DP形式利用時におけるSnapMirror互換性が超狭く、9.3だと9.5までしかSnapMirrorが出来ません。

こ、こいつは由々しき事態だぜっ・・・！

じゃぁ、2台ともバージョンアップしないといけないのか？
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3552050/9ea9b38a-0e91-9f96-6ba4-09a7f14d0bd7.png)

結論からいうと、そんなことはありません。
要は、**DP形式が悪いならDP形式なんて辞めちまえばいい**のです。

なお、構成済みのSnapMirrorが何の形式を使っているかは、
```
snapmirror show
```
をONTAP上から実行すれば一発でわかります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3552050/a0c29704-4711-ab5e-6f1d-269558553aac.png)
↑Tyep列の記載がそれですね。

少し流れをまとめますと
FSxNへSnapMirrorをするために、ONTAPのバージョン互換性が取れていない
↓
互換性があるバージョンに上げるとオンプレミスのONTAP2台ともバージョンアップしないといけない！？
↓
バージョンアップ2台はきついので、片側だけがいいけど片側だけ上げるとオンプレミスのSnapMirrorがDP形式なのでできなくなる
↓
それならDP形式をやめてXDP形式に変えよう！

という感じですね。

XDP形式への変換については、次回にまた書こうと思います。

:::note info
**今日のまとめ**
・FSxNへのデータ移行には、ONTAP同士ならSnapMirrorを検討しよう！
・SnapMirrorに移行元と移行先両方にライセンスがいるよ！
・SnapMirrorには互換性がある！ONTAPバージョンに注意だ！
・SnapMirrorには形式がある！バージョンアップによる影響は要確認！

:::

ではでは。