Name：小原 誠（Makoto Kobara）
October, 2020
はじめに
ファイルサーバーからのデータ移行を取り上げる「瞬間移動」ブログシリーズ、今回は、データのアクセス権限やタイムスタンプといったデータに付随する情報、いわゆる「メタデータ」の移行について、前回の「XCP」Windows 版に続いて、「Cloud Sync」を利用したWindowsファイルの移行を取り上げてみます。
- ネットアップ純正のデータ同期サービス「Cloud Sync」とは
- 「Cloud Sync」を利用したWindowsファイル移行
（移行元/先ファイルサーバーにNetApp ONTAP 9を利用している場合）
以下の内容については、前回の記事を御覧ください。
- そもそもなぜメタデータ移行に気をつける必要があるのか
- Windows環境でのメタデータの種類と移行にあたっての一般的な確認ポイント
- ネットアップ純正の移行ツール「XCP」Windows版を利用した場合の動き
（移行元/先ファイルサーバーにNetApp ONTAP 9を利用している場合）
データ同期サービス「Cloud Sync」とは
「Cloud Sync」とは、ネットアップが提供しているデータ同期サービス（SaaS）で、次のような特徴があります。
- データの同期元・同期先に、NFS / CIFS / Amazon S3 プロトコルを選択可能
（例えば NFSプロトコルからCIFSプロトコルへなど、異なる組み合わせも選択可能、通信さえできれば、オンプレ-クラウド間や、クラウド間での同期も可能） - 同期の設定や実行は、GUI上の簡単操作で、アプリ開発者や業務担当者自らが操作でき、一度きりのデータ同期も、スケジュールに従った定期実行も可能
- 同期設定数（セッション数）に応じた従量課金で提供
図 1 Cloud Syncの画面
このように、Cloud Sync は、インフラの有識者でなくとも、アプリ開発者や業務担当者自らが手軽にデータ同期を実行できることを最大の特徴とするサービスです。
実行にあたっては最初に、Data Broker（データブローカー）と呼ぶ役割をLinuxサーバー上にインストールし、Cloud Syncの管理画面（SaaS）からデータブローカーを制御、データブローカーが同期元/先へのデータ同期を実行します。データブローカーのインストール要件等はこちらをご確認ください。
「Cloud Sync」でのメタデータ移行（Windowsファイル共有編）
今回は、前述のCloud Syncを利用して、移行元/移行先ファイルサーバーに弊社の ONTAP 9 を利用したファイルサーバーを用意、この環境でのWindowsファイル共有でのメタデータ移行を検証しました。検証項目は前回のXCPと同様です。
- 移行元ファイルサーバー：NetApp ONTAP 9.6P3（ONTAP Selectを利用）
- 移行先ファイルサーバー：同上
- 移行ツール：NetApp Cloud Sync 6 Sept 2020 リリース版
（Data Broker は CentOS Linux release 8.0.1905 （Core）上にインストール） - 移行元/先ファイルサーバーでの共有フォルダ設定
- プロトコル設定：CIFS
- ボリューム設定：
- security=ntfs（NTFS-ACL利用）
- language=utf8mb4（サロゲートペア有効）
- 全て同じADドメインに所属
図2 CloudSyncでのWindows環境のメタデータの移行評価環境概要
また、Cloud Syncは、『ACL同期あり』のオプションで実行しています。
この環境での評価結果について表2に記します。
この結果からわかるように、細かなメタデータ移行への対応は、前回ご紹介したXCPと比較すると、限定的と言えるでしょう。
表2 CloudSyncでのWindows環境でのメタデータの移行
|
# |
メタデータの種類 |
一般的な確認ポイント |
可否 |
|---|---|---|---|
|
1 |
ファイル名 /フォルダ名 |
|
可 |
|
一部制限有（※1） |
||
|
N/A（※2） |
||
|
2 |
アクセス権 |
|
一部制限有（※3） |
|
3 |
所有者（オーナー） |
|
不可（※4） |
|
4 |
拡張属性 |
|
一部制限有（※5） |
|
5 |
タイムスタンプ |
|
一部制限有（※6） |
|
6 |
代替データストリーム |
|
不可 |
|
7 |
スパース属性 |
|
不可（※7） |
※1：1038文字までは対応可能です。
※2：Windowsファイル共有で使われるSMB/CIFSプロトコルの仕様から、Windowsクライアント側では大文字/小文字を判別できないため、評価の対象外（N/A）としています。
※3：移行先では所有者（オーナー）が BUILTIN\Administrators に置き換わることから、移行元で『所有者だがアクセス権はない』ファイル/フォルダについては、移行できません。
※4：移行先では所有者（オーナー）がBUILTIN\Administrators に置き換わります。
※5：移行元で拡張属性が全く設定されていないファイル/フォルダは、移行先ではARCHIVE属性のみ自動的に設定されます。また、HIDDEN、SYSTEM、OFFLINE属性は移行できません。
※6：CreationTimeはファイル、フォルダともに、移行した時間に置き換えられます。LastWriteTimeはファイルの場合ミリ秒以下が0に置き換えられ、フォルダの場合は移行した時間に置き換えられます。
LastAccessTimeは、ファイルの場合は移行後のLastWriteTimeと同じになります。
※7：ファイルのコピーは成功しますが、スパース属性は引き継がれません（移行元ではブロック未割り当てだった範囲に、移行先ではブロックが割り当たります）。
まとめと次回予告
今回のブログでは、CloudSyncを利用したWindows環境でのメタデータ移行の評価結果についてご紹介しました。
CloudSyncはユーザー自身が手軽に、データファイルの同期を行うことを目的としたツールのため、ファイルサーバー移行ツールに求められるメタデータ移行の機能は、現時点では限定的です。
しかし、その設定や実行操作の手軽さから、前回ご紹介したXCPとの間で適材適所で使い分けるものと思います。
次回は、Windowsに標準で付属しているツール「robocopy」について簡単に取り上げ、Windows環境でのメタデータ移行のまとめを行います。
次回の投稿もお楽しみに!
Name：小原 誠（Makoto Kobara）
Title：ネットアップ合同会社 システム技術本部 ソリューション アーキテクト部 シニアソリューションアーキテクト
Bio：ストレージプロダクトの要素技術研究開発に始まり、ITインフラ分野におけるコンサルティング（IT戦略立案）からトランスフォーメーション（要件定義、設計構築、運用改善、PMO）まで官公庁・自治体、製造業、サービス業、通信・ハイテク業など業種を問わず、計20年以上従事。ネットアップにおいてはソリューションアーキテクトとして、クラウドソリューション領域を中心に、マーケティング活動や、パートナー企業との共同ソリューション開発や、ユーザー企業での導入支援を実施。
