AWS DataSyncとAzure File Sync 比較 ～Azure File Sync動作確認編～

AWS DataSync(以下、DataSync)と Azure File Sync(以下、File Sync)シリーズの7本目の記事です。
1本目は記事はこちら
AWS DataSyncとAzure File Sync 比較 ～共通点と相違点～
2本目は記事はこちら
AWS DataSyncとAzure File Sync 比較 ～前提条件定義編～
3本目は記事はこちら
AWS DataSyncとAzure File Sync 比較 ～AWS DataSync構築事前準備編～
4本目の記事はこちら
AWS DataSyncとAzure File Sync 比較 ～AWS DataSync構築編～
5本目の記事はこちら
AWS DataSyncとAzure File Sync 比較 ～AWS DataSync動作確認編～
6本目の記事はこちら
AWS DataSyncとAzure File Sync 比較 ～Azure File Sync構築編～

本記事ではFile Syncの動作確認を行います。

動作確認

動作確認を行いますが、その前に念のためDataSyncとFile Syncの動作確認環境の違いを構成図にします。
後程DataSyncの動作確認の記事にも構成図を掲載します。

構成図

以下の構成で動作確認を行いました。

青線で同期を行い、権限確認に必要な新ファイルサーバーへの同期処理は赤線で行っています。
Azure Filesを既存のファイルサーバーにストレージアカウントのアクセスキーでマウントすることもできるのですが、アクセスキーでのマウントはNTFSアクセス権が効かなくなってしまいますのでもう1台ファイルサーバーを立ててそこにAzure File Syncで接続して確認します。
今回は検証なのでオンプレのKVM上にVMを立てて検証していますが、AzureとVPNを張っていればAzure上にVMを立ててもいいです。
というかAzure上にVM立ててるとAzureへのファイルサーバーのLift＆Shiftが完全な形で検証できますね。
この動作確認の構成を応用すると、オンプレミスのファイルサーバーのリプレースや、多拠点間でのデータ同期とアクセス速度向上を行うキャッシュサーバーの構成が構築できます。

同期実行

File SyncはDataSyncと違って同期グループ設定後に即時同期かつ常時同期なので、わざわざ同期を実行するという操作は不要です。

同期データ確認

同期実行の操作が不要なのでデータ確認からです。
前回の記事の通りに同期グループにサーバエンドポイントとして新しいファイルサーバーを追加します。

何もないディレクトリに対して

無事データ同期が行われます。

NTFSアクセス権確認

A事業部に所属するdomain.user01でアクセスすると無事データを開けます。

B事業部に所属するdomain.user11でアクセスすると、事業部フォルダすら開けません。

Microsoftさん、完璧ですね！
NTFSアクセス権とかActive DirectoryとかはMicrosoftさんのお家芸なんで当たり前と言えば当たり前かもしれませんが、それでも思い通りに動作すると嬉しいですね。

今回はここまで。