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さんのお家芸なんで当たり前と言えば当たり前かもしれませんが、それでも思い通りに動作すると嬉しいですね。
今回はここまで。