Amazon FSx for NetApp ONTAPへの移行方法を整理してみた

VMware Cloud on AWS／Amazon FSx for NetApp ONTAP 〜俺たちの推しサービスを見て・聞いて・使ってくれ〜
で使用した資料です。

https://dev.classmethod.jp/news/240118-aws-netapp-seminar/

Transcript

1. Amazon FSx for NetApp ONTAPへの
 移行方法を整理してみた
 クラスメソッド株式会社 のんピ
 1
2. 2 自己紹介 { "本名": "山本 涼太 (覚えなくていいです)", "部署": "AWS事業本部 コンサルティング部", "前職": "インフラエンジニア in データセンター", "興味のあること": "面白そうなブログネタ探し", "好きなAWSサービス": [ "Amazon FSx for NetApp ONTAP" "AWS Transit Gateway", "AWS Step Functions" "AWS CDK" ], "称号" : [ "2023 Japan AWS Ambassador", "NetApp Advanced Solution Leading Award 2023", ] }
3. 3 今までのセッションを聞かれて Amazon FSx for NetApp ONTAPに データを移行したい！ と思われたと確信しています
4. 4 気にならないでしょうか Amazon FSx for NetApp ONTAPへの移行方法
5. 5 整理してお届けします Amazon FSx for NetApp ONTAPへの移行方法
6. 6 FSxN へ移行する際の全体プロセス 1. 事前調査, 要求定義 2. 要件定義 3. 移行計画 (必要に応じてPoC) 4. 環境構築 5. 移行リハーサル 6. 本番移行
7. 7 1. 事前調査, 要求定義 2. 要件定義 3. 移行計画 (必要に応じてPoC) 4. 環境構築 5. 移行リハーサル 6. 本番移行 FSxN固有の要素は多くない
8. 8 事前調査や要件を整理する際には以下ブログを参照
9. 9 要件整理後に移行計画を具体化 決めておきたいこと • 移行スケジュール • 作業ごとの役割分担 • 移行先の構成 • 想定移行方法 • 想定移行時間 • 移行対象データサイズの見積 • 発生したリスクに対しての管理方法 • トラブル時の切り戻し判断基準
10. 10 今回お話するのは実際のデータ移行 1. 事前調査, 要求定義 2. 要件定義 3. 移行計画 (必要に応じてPoC) 4. 環境構築 5. 移行リハーサル 6. 本番移行 ここにフォーカス
11. 11 移行方法は大きく2パターン オフライン移行 or オンライン移行
12. 12 オフライン移行の方法 SnowFamilyを使う
13. 13 どんな時にオフライン移行を使用する?
14. 14 オフライン移行の気になるポイント
15. 15 その他にもSnowFamilyを使う際の注意点は複数存在 https://pages.awscloud.com/rs/112-TZM-766/images/202208_AWS_Black_Belt_AWS_Snowball_Edge_Storage_Optimized.pdf
16. 16 完全オフライン移行は現実的ではない 初期転送をオフラインで差分同期をオンラインで
17. 17 オンライン移行の方法 SnapMirrorやDataSync、Robocopyなどの ツールやサービスを使う
18. 18 オンライン移行の中でも2パターン ストレージのレプリケーション機能で移行 or ファイルやブロックレベルでの移行
19. 19 オンライン移行の方法 FSxNにおいては 「SnapMirror」か 「それ以外」か https://aws.amazon.com/jp/blogs/news/migrating-on-premises-file-shares-to-amazon-fsx-for-netapp-ontap/
20. 20 まずは SnapMirrorを検討
21. 21 SnapMirrorで移行することによるメリット • ファイル数/フォルダ階層の影響を受けにくい • 差分転送時の差分計算が速い • メタデータも併せて移行可能 • 帯域制御が可能 • 重複排除や圧縮などのデータ削減効果を維持したまま転 送可能(条件あり) ◦ Transit GatewayやSite-to-Site VPNなどのデータ転送量 に対して課金の抑制 ◦ 転送先のストレージサイズに対する課金の抑制 ◦ 転送時間が短くなる • SnapMirror自体にはデータ転送量に対する課金がない • データ転送用のサーバーが不要
22. 22 要するに 良いことだらけ
23. 23 SnapMirrorが使えないシチュエーション • 移行元がONTAPではない • 移行元と移行先のONTAPのバージョンが6つ以上離れて いる • SnapMirrorのライセンスの用意ができない • SnapMirrorで移行することによって不都合がある ◦ 移行元のボリュームでサロゲートペアに対応していないが移 行先では対応させたい ◦ ボリューム内のデータの構成を分割/統合したい
24. 24 その他の移行ツール、サービスの選定ポイント • 利用時の金銭的コスト • 転送速度 • ツール特有の制約事項 ◦ 帯域制御の有無 ◦ 転送可能なメタデータの種類 ◦ サポートしているプロトコル ◦ 転送時の暗号化 ◦ 移行に失敗したファイルなどのレポート機能の有無 • 使い慣れているか
25. 25 移行するときに重要視したいこと 物理データ使用量の最適化と 階層化によるコスト削減
26. 26 ストレージのサイズによって課金が発生 Primary Storage (SSD): プロビジョニングしたサイズ Capacity Pool Storage: 物理使用量 https://aws.amazon.com/jp/fsx/netapp-ontap/pricing/
27. 27 コスト削減できるなら削減したいですよね? データ使用量の削減(Storage Efficiency)と 階層化の有効活用が重要
28. 28 Tiering Policy Allは諸刃の刃 ポストの重複排除や圧縮がかからずに階層化してしまう => Capacity Pool Storageでの処理は未サポート https://www.netapp.com/media/17239-tr4598.pdf
29. 29 対応方法は大きく2つ 1. Storage Efficiency用のFSxNファイルシステムを追加して転 送 2. Tiering Policyを切り替えながら転送
30. 30 1. SE用のFSxNファイルシステムを追加して転送 移行元がONTAPでカスケードSnapMirrorを使う場合
31. 31 1. SE用のFSxNファイルシステムを追加して転送 SnapMirrorを使わない場合
32. 32 2. Tiering Policyを切り替えながら転送 データ削減後にCapacity Pool Storageに流す を繰り返す ※ SnapMirrorは初期転送時に移行元のデータを全て転送するため採 用しづらい
33. 33 注意点 実際どのぐらい重複排除や圧縮で データ削減されるのかは やってみなければ分からない ↓ 得られたデータ削減量が少ないことも
34. 34 PoCをした上で移行の計画を立てましょう
36. 36 SnapMirrorはStorage Efficiencyを維持した状態で転送 移行元でStorage Efficiencyが効ききっていない状態で SnapMirrorをすると移行先でもその状態のまま