Amazon Web Services ブログ
オンプレミスから Amazon FSx for NetApp ONTAP へのファイル共有の移行
このブログは Sujata Abichandani ( Sr. Storage Infrastructure Architect ) と Madhu Vinod Diwaka ( Cloud Infrastructure Architect ) によって執筆された内容を日本語化したものです。原文はこちらを参照して下さい。
あらゆる規模の企業が、オンプレミス上で稼働しているアプリケーションを Amazon Web Services ( AWS ) に移行することで、俊敏性の向上、イノベーションの加速、セキュリティの改善、コストの削減を実現したいと考えています。これらのアプリケーションの多くは、NetApp ONTAP を搭載した NAS ( Network Attached Storage ) アプライアンスにデータを格納しており、ストレージとデータの管理機能により、アプリケーションとワークロードを簡単に管理することができます。従来はオンプレミスの NetApp ONTAP をクラウドに移行する際、NetApp ONTAP の機能をすべて備えたクラウドソリューションがないことが、クラウド移行に伴うオーバーヘッドを生じさせる大きな課題となっていました。
AWS Storage Day 2021で、AWS は新サービスである Amazon FSx for NetApp ONTAP ( 以降 FSx for ONTAPと表記 ) を発表しました。FSx for ONTAP を利用することで、わずか数クリックで AWS 上にフルマネージド型の NetApp ONTAP ファイルストレージを起動、実行、拡張できるようになりました。これにより、アプリケーションのコードやデータ管理方法を変更することなく、NetApp やその他の NAS デバイスに依存するオンプレミスアプリケーションを AWS に移行することができます。
このブログでは、オンプレミスの NAS から FSx for ONTAP にデータを移行する方法の概要を説明します。特に NetApp SnapMirror を使用して、オンプレミスの NetApp ONTAP ファイルシステムを FSx for ONTAP にオンライン移行することに焦点を当てます。
オンライン移行とオフライン移行の比較
オンプレミスのデータを FSx for ONTAP に移行するには、オンライン移行とオフライン移行の 2 つの方法があります。移行に使用するツールは選択する移行方法によって異なります。
オンライン移行では AWS Direct Connect または VPN 経由で FSx for ONTAP にデータを転送することができます。最も広く利用されているツールとして、NetApp SnapMirror、NetApp Cloud Sync、NetApp XCP、Robocopy / rsync、AWS DataSync などがあります ( DataSync については原文公開後に対応された為、本記事では部分的な情報追加に止めます )。利用可能な帯域幅と移行するデータの総量は、総移行時間に直接影響します。
オフライン移行は、外部へのネットワーク接続が不安定または利用できない場合や、移行するデータ量が大きすぎて利用可能なネットワーク経由での移行にかかる時間が妥当でない場合に推奨されます。これらのシナリオでデータを転送するために推奨される方法は、AWS Snow ファミリーサービス ( Snowcone、Snowball Edge、Snowmobile ) を使用することです。
移行方法の選定
以下のフローチャートは FSx for ONTAP にデータを移行するための最適な方法を選定するのに役立ちます。追加の検討事項については、本ブログの「オンライン移行」と「 AWS Snow ファミリーを使用したオフライン移行」のセクションを参照してください。
図 1: 適切な移行方法を選定するためのフローチャート
オンライン移行
オンライン移行の機能比較を以下の表に示します。
| 機能 | NetApp SnapMirror | NetApp Cloud Sync | NetApp XCP, Robocopy/rsync | AWS DataSync |
| インストール方法 | NetApp ONTAP のネイティブ機能* | BlueXP ( 旧 Cloud Manager ) から利用 | XCP はNetAppが無償で提供するクライアントソフトウェアです Robocopy / rsync は OS ネイティブです |
AWS マネジメントコンソールや AWS CLI から利用 |
| 移行元 | NetApp ONTAP | 特に制限なし | 特に制限なし | 特に制限なし |
| ストレージプロトコル | NFS, SMB, iSCSI | NFS, SMB | NFS, SMB | NFS, SMB, HDFS ほか |
| 転送中の暗号化 | NetApp ONTAP バージョン 9.6 以降は対応 | NFS とオブジェクトデータの転送は暗号化に対応、 SMB は非対応 | 移行元と移行先で暗号化が有効な場合サポート | 移行元と移行先で暗号化が有効な場合サポート |
| 利用料金 | クラスタ毎のライセンスが必要 | ご利用に応じた料金 | 無料 | 料金ページを参照 |
| 独自の機能 | ブロックレベルレプリケーションで、最速の転送速度 | 1. エンド・ツー・エンドのフルマネージド型移行 2. オブジェクトベースの移行をサポートする唯一のサービス |
XCP File Analytics で、ファイルシステムに関するインサイトを提供 | SMB、 NFS をはじめ、HDFS クライアントとして Hadoop クラスターに接続するなど多くの形式に対応 |
| 最適な使用例 | 1. 移行元と移行先でデータが頻繁に変更される場合 2. ファイル構造が複雑で、サイズの小さいファイルが百万単位で存在する場合 |
GUIベースのマネージド型の移行により、SnapMirror に次いでシンプルな移行を実現 | Robocopy はWindows、 rsync は Linux / macOS にそれぞれ組み込まれており、追加のソフトウェアなしで移行が可能 | FSx for ONTAP と NetApp ONTAP の間でファイルを転送する場合は SnapMirror を使用することを推奨 |
*オンプレミスの NetApp ONTAP ファイルシステムには SnapMirror ライセンスが必要です。
*オンプレミスの NetApp ONTAP ファイルシステムと FSx for ONTAP の SnapMirror の互換性に関してはこちらのページでご確認ください。
*DataSync については原文公開後に対応された為、本記事では部分的な情報追加に止めます
図 2: FSx for ONTAP オンライン移行アーキテクチャ
NetApp SnapMirror
SnapMirror は NetApp ONTAP のネイティブ機能であり、FSx for ONTAP で完全にサポートされています。SnapMirror は、オンプレミスの NetApp ONTAP ファイルシステムから FSx for ONTAP への移行アプローチとして推奨されています。
SnapMirror は、2 つの NetApp ONTAP ファイルシステム間でブロックレベルのレプリケーションを採用しており、 指定されたソースボリュームからデスティネーションボリュームへデータを複製します。SnapMirror のブロックレベルレプリケーションは、ディレクトリ構造が複雑、ファイル数が 5,000万個以上 、ファイルサイズが非常に小さい ( キロバイト単位 ) などの場合に他のツールよりも効率的に実行されます。データは暗号化され、転送中も重複排除され圧縮されたままです。ソースボリュームのスナップショットはデスティネーションボリュームにも保存されます。
SnapMirror 移行ガイド
このガイドでは、FSx for ONTAP ファイルシステムとストレージ仮想マシン ( SVM ) を作成済みで、移行データを格納する移行先のボリュームはまだ作成していない状況を想定しています。ここではインタークラスタロジカルインタフェース ( LIF ) を使用して、移行元と移行先の NetApp ONTAP クラスタとそれぞれの SVM の間にピア関係を確立するプロセスを紹介します。ピア関係を設定したら、SnapMirror 関係を確立して、移行元から移行先にデータを複製します。最初の転送後、移行の準備が整うまではオプションでインクリメンタルアップデートを実行することができます。最後に FSx for ONTAP ボリュームからSnapMirror関係を解除して、マウントして使用できるようにします。
CLI でどこに値を差し込めばよいかを簡単に理解できるように、クラスタ、SVM、ボリュームのエイリアス を次のように設定しています。
FSx-Destは、デスティネーションクラスタの識別子 (FsxIdxxxxxxxxxxxxx) ですOnPrem-Sourceは、ソースクラスタの識別子ですDestSVMは、デスティネーション SVM 名ですSourceSVMは、ソース SVM の名前です- ソースとデスティネーションのボリューム名はどちらも
vol1です
1. デスティネーションクラスタにログインし、デスティネーションボリュームを作成する
FSx for ONTAP のファイルシステム ( デスティネーションクラスタ ) に Secure Shell ( SSH ) でアクセスします。AWS マネジメントコンソールから <ManagementIP> を取得します。
$ ssh fsxadmin@<ManagementIP>
SnapMirror 関係を作成する前に、デスティネーションクラスタに移行元から複製するするボリュー ムと同等以上の容量を持つボリュームを用意する必要があります。また、SnapMirror 関係の移行先として機能する様、 -type DP を付けてボリュームを作成する必要があります。
FSx-Dest::>vol create -volume vol1 -aggregate aggr1 -size 1g -type DP
2.移行元と移行先のインタークラスタ LIF を確認する
SnapMirror では、インタークラスタ LIF を使用して、ソースクラスタとデスティネーションクラスタ間のデータ転送を行います。これらのインタークラスタ LIF は IP アドレスにマッピングされ、クラスタ間のピア関係を確立するときに使用されます。
FSx for ONTAP システムの場合、AWS マネジメントコンソールでファイルシステムに移動し Network & Security のタブを選択して IP アドレスを取得します。Endpoints のセクションに Inter-cluster endpoint – IP address が表示されます。
図 3: AWS マネジメントコンソールでインタークラスタ LIF の IP アドレスを確認する
また、以下のコマンドを使用して ONTAP CLI からインタークラスタ LIF の IP アドレスを取得することもできます。
OnPrem-Source::> network interface show -role intercluster
Logical Network
Vserver Interface Status Address/Mask
----------- ---------- ------- ------------
FSx-Dest
inter_1 up/up 10.0.0.36/24
inter_2 up/up 10.0.1.69/24
inter_1 と inter_2 の IP アドレスを保存します。FSx-Dest ( 移行先 ) では dest_inter_1 と dest_inter_2 、OnPrem-Source ( 移行元 ) では source_inter_1 と source_inter_2 と呼ぶことにします。
3.移行元と移行先の間にクラスタピア関係を確立する
デスティネーションクラスタ側からソースクラスタのインタークラスタ LIF の IP アドレス ( source_inter_1 および source_inter_2 ) を指定して、クラスタピア関係を確立します。このコマンドでは、ソースクラスタ上でクラスタピア関係を確立する際に入力するパスフレーズを作成するよう要求されます。
FSx-Dest::> cluster peer create -address-family ipv4 -peer-addrs <source_inter_1>,<source_inter_2>
次に、ソースクラスタ側からデスティネーションクラスタのインタークラスタ LIF の IP アドレス ( dest_inter_1 および dest_inter_2 ) を指定して、クラスタピア関係を確立します。認証にはデスティネーションクラスタ側で作成したパスフレーズを入力する必要があります。
OnPrem-Source::> cluster peer create -address-family ipv4 -peer-addrs <dest_inter_1>,<dest_inter_2>
ソースクラスタ上で以下のコマンドを使用して、ピアリングが成功したことを確認します。Availability は Available と表示されているはずです。
OnPrem-Source::> cluster peer show
Peer Cluster Name Availability Authentication ----------------- -------------- -------------- FSx-Dest Available ok
4. SVM のピア関係を作成する
クラスタピア関係が確立されたので、次は SVM のピアリングを行います。以下のコマンドでデスティネーションクラスタ ( FSx-Dest ) 上に SVM のピア関係を作成し、冒頭で挙げたものに加えて以下のエイリアスを使用します。
- ソースクラスタ上でデスティネーション SVM を指定する
<DestLocalName>はdestsvm01とします - デスティネーションクラスタ上でソース SVM を指定する
<SourceLocalName>はsourcesvm01とします
FSx-Dest::> vserver peer create -vserver <DestSVM> -peer-vserver <SourceSVM> -peer-cluster <OnPrem-Source> -applications snapmirror -local-name <SourceLocalName>
Info: [Job 207] 'vserver peer create' job queued
次に、ソースクラスタ ( OnPrem-Source ) 上でピア関係を受け入れます。
OnPrem-Source::> vserver peer accept -vserver <SourceSVM> -peer-vserver <DestSVM> -local-name <DestLocalName>
Info: [Job 211] 'vserver peer accept' job queued
以下のコマンドを使用して SVM のピアリング状態を確認します。Peer State は peered と表示されるはずです。
OnPrem-Source::> vserver peer show
Peer Peer Peer Peering Remote vserver Vserver State Cluster Applications Vserver ------- -------- ------ -------- ------------- --------- svm01 destsvm1 peered FSx-Dest snapmirror svm01
5. SnapMirror 関係の作成と初期化
SVM のピアリングが完了したら、次の手順としてデスティネーションクラスタで SnapMirror 関係を作成し初期化します。オプションで -throttle フラグを使用し、SnapMirror 関係が使用できる最大帯域幅 ( キロバイト / 秒 ) を設定できます。
FSx-Dest::> snapmirror create -source-path <SourceLocalName>:vol1 -destination-path <DestSVM>:vol1 -vserver <DestSVM> -throttle unlimited
Operation succeeded: snapmirror create for the relationship with destination "DestSVM:vol1".
SnapMirror 関係が作成されたら、次のコマンドを使用してデスティネーションクラスタ上で SnapMirror 関係を初期化します。これによりソースボリュームからデスティネーションボリュームへデータのスナップショットの転送が開始されます。
FSx-Dest::> snapmirror initialize -destination-path <DestSVM>:vol1 -source-path <SourceLocalName>:vol1
6.更新されたデスティネーションクラスタを維持する
頻繁に使用されているデータを移行する場合、移行先のクラスタが移行元のクラスタの最新の状態で保たれていることを確認する必要があります。また、データを損失することなく移行を完了するために、メンテナンスウィンドウをスケジュールする必要があります。これらのアクションは自動的に行われるわけではありません。デスティネーションクラスタにワンタイムアップデートを実行するには、次のコマンドを実行します。
FSx-Dest::> snapmirror update -destination-path <DestSVM>:vol1
クライアントを FSx for ONTAP に移行する前に、時間単位または日単位で更新をスケジュールすることができます。SnapMirror のスケジュールは、次のコマンドを使用して設定できます。
FSx-Dest::> snapmirror modify -destination-path <DestSVM>:vol1 -schedule hourly
7. SnapMirror 関係を解消する
FSx for ONTAP でソースクラスタからデスティネーションクラスタに一度だけ転送する場合、 転送後に FSx for ONTAP を読み取り / 書き込みボリュームとして使用するには、SnapMirror 関係を解除する必要があります ( 関係を解除するまで SnapMirror デスティネーションボリュームは読み取り専用になります )。
次のコマンドを実行して転送が完了したことを確認します。Mirror State が Snapmirrored で、Relationship Status が Idle であることを確認します。また、デスティネーションボリュームに最新のデータが反映されているか、Last Transfer End Timestamp が最新であることも確認する必要があり ます。
FSx-Dest::> snapmirror show -fields state,status,last-transfer-end-timestamp
Source Destination Mirror Relationship Last Transfer End Path Path State Status Timestamp ---------- ----------- ---------- ------- --------------- Svm01:vol1 svm02:DestVol Snapmirrored Idle 09/02 09:02:21
次に quiesce コマンドを使用して、今後の SnapMirror 転送を無効にする必要があります。
FSx-Dest::> snapmirror quiesce -destination-path <DestSVM>:vol1
snapmirror show コマンドを使用して、Relationship Status が Quiesced に変更されたことを確認します。
FSx-Dest::> snapmirror show
Source Destination Mirror Relationship Path Path State Status ----------- ------------ ------------- -------- sourcesvm1:vol1 svm01:DestVol Snapmirrored Quiesced
これが確認できたら、次のコマンドで SnapMirror 関係を解除できます。
FSx-Dest::> snapmirror break -destination-path <DestSVM>:vol1
Operation succeeded: snapmirror break for destination "DestSVM:vol1".
これでソースボリュームのデータがデスティネーションボリュームに完全にミラーリングされ、読み書き可能なボリュームとして利用できるようになります。このデータをクライアントやアプリケーションからアクセスできるようにする為には、NAS 共有 (SMB / NFS ) または iSCSI LUN をマウントする必要があります。
NetApp Cloud Sync
NetApp Cloud Sync は、NetApp Data Broker を使用してソースからターゲットにデータを同期します ( これをシンク関係と呼びます )。Data Broker はソースとターゲットの間のシンク関係を制御します。シンク関係を設定すると、Cloud Sync はソースデータを分析し、複数のレプリケーションストリームに分割し、高度に並列化された方法でターゲットにプッシュして帯域幅の利用率を最適化します。最初のコピー後、変更されたデータは設定されたスケジュールに基づいて同期されます。Cloud Sync は、NetApp BlueXP ( 旧 Cloud Manager ) に含まれます。
NetApp XCP
NetApp XCP は、NFS と SMB ( CIFS ) プロトコルに対応した NetApp の無償サービスです。これを使用して、オンプレミスのストレージ ( NetApp ONTAP など ) から FSx for ONTAP にデータを移行することができます。XCP はライブデータ移行、同期関係の構築をサポートし、さらに XCP File Analytics を使用してファイルのインサイトを表示するダッシュボードを提供します。XCP は、移行元と移行先のボリュームをマウントした Linux または Windows のホストにインストールするクライアントソフトウェアで、ホスト上でコマンドを実行することでデータの移行を容易にします。
ネイティブのツール: Robocopy / rsync
Robocopy と rsync は、それぞれ Windows と Linux / macOS で利用できるネイティブの CLI ツールです。どちらのソリューションも、移行元と移行先のボリュームがマウントされたホストが必要で、Windows または Linux / macOS のホストがそれぞれ Robocopy または rsync のコマンドを実行します。
AWS Snow ファミリーを使用したオフライン移行
帯域幅が限られていたり、インターネット接続が不安定または利用できない場合、AWS Snow ファミリーはインターネットよりも速いスピードでオフラインの移行をサポートします。
インターネットを介した大容量データの移行は、高速回線であっても数ヶ月かかることがあります。例えば、信頼性の高い 100 Mbps の接続で 100 TB を転送すると、他の用途に使用できる帯域幅を制限しながら 100 日以上かかることがあります。しかし AWS Snowball Edge を 2 台使用すれば、同じ転送を 1 日以内 ( 輸送時間を含む ) で完了することができます。
データ転送時間の短縮は AWS Snow ファミリーの唯一の用途ではありません。WAN 接続が不安定または利用できない場所、メータリングが有効な場合、またはレガシー環境が原因でオンライン転送にオーバヘッドが生じる場合の転送方法として推奨されます。
AWS Snow ファミリーは、AWS Snowcone、AWS Snowball Edge、および AWS Snowmobile で構成されています。各製品には、用途に応じ様々な容量やビルトインのコンピューティング機能が搭載されています。AWS Snow ファミリーのデバイスは AWS によって所有、管理され、AWS のセキュリティ、監視、ストレージ管理、コンピューティング機能と統合されています。
AWS Snow ファミリーを使用した FSx for ONTAP への移行に関するベストプラクティスについては別のブログで紹介する予定です。それまでの間、Snowball Edge を使った移行に関するブログ記事、”Snowball Edge を使用したデータ移行のベストプラクティス“、”Best practices for accelerating data migration with AWS Snowball Edge“をご覧下さい。
まとめ
このブログでは、 FSx for ONTAP へのデータ移行に使用できるオンラインとオフラインの移行オプションの概要と、SnapMirror を使用したオンプレミスの NetApp ONTAP 移行に関する手順を紹介しています。
オンライン移行は、データ量が少なく信頼性の高い広帯域の接続が必要な場合に最適です。オフライン移行は、データ量が非常に多い場合や接続に制限のある場所からの移行に最適です。さまざまな移行テクノロジーとそのトレードオフを理解することで、 FSx for ONTAP への移行をシンプルかつ容易に計画し、成功させることができます。
詳細については、 FSx for ONTAP のドキュメントを参照してください。もし移行に最適なオプションがわからない場合は、AWS アカウントチームにご相談ください。
このブログ記事をお読みいただき、ありがとうございました。コメントや質問があれば、遠慮なくコメント欄に記入してください。
翻訳はネットアップ合同会社の岩井様、監修はソリューションアーキテクトの長田が担当しました。