セールスの浜野です。
今回で3回目の登場です。
1月に投稿した前編ではAzure File Syncの概要と環境構築について紹介させていただきました。
後編では、ファイルの同時編集時の動作、アプリケーションのインストール失敗時の対応など、いろいろと触ってわかったことを載せます。
是非読んでいただけたらと思います。
【目次】
１． 検証環境の構成
２． 検証
(1). アクセス権
(2). ファイルの同時編集
(3). 時計のずれとタイムゾーン
３． おまけ
(1). インストール時の失敗
４． まとめ
１． 検証環境の構成
前回の記事では最も単純な構成を使って構築手順について説明いたしました。
後編では３台のサーバに1つの共有フォルダを同期させる構成にいたします。
- sync-server :ドメインに参加、Cドライブにエンドポイントを作成
- sync-server2:ドメインに参加、追加ディスクをDドライブとしてマウント、エンドポイントを作成
- sync-server3:ドメインには参加せず、追加ディスクをFドライブとしてマウント
2． 検証
① アクセス権
File Syncを使うとオフィスの各拠点のファイルサーバを瞬時に同期させることができます。とても便利ではありますが、前編で記載しましたがファイルサーバはアクセス権を付与しながら運用することが多く、アクセス権を複雑に設定している場合もあり、アクセス権が継承されないと意味がありません。File Syncを使って各拠点のファイルサーバを同期した場合、アクセス権はどのようになるのでしょうか？
sync-serverのファイルのアクセス権を変更してみて動作を見てみます。
text.txtファイルにドメインユーザをフルコントロールのアクセス権を追加してみます。
同じドメインに参加しているsync-server2のtext.txtファイルのプロパティを見ると、アクセス権が同じように変更されていました。
また、ドメインに参加していないsync-server3のtext.txtファイルのプロパティを見ると、ローカルにないユーザ情報なので「不明なアカウント」として表示されています。
ドメインに参加していないサーバではアクセス権を引き継ごうにもユーザ情報がない問う状態になります。アクセス権を設定している環境ではドメイン参加が必須です。
②ファイルの同時編集
ファイルサーバを同期することで注意したい同時編集したときの動作です。
マイクロソフト社のテクニカルドキュメントには以下のように記載されていますのでファイルが作成されるか試してみます。
------------------------------------------------------------------------------------
2 つのサーバーで同じファイルがほぼ同時に変更された場合、どうなりますか。
Azure File Sync では、シンプルな競合解決方法が採用されています。ファイルに対して 2 つのサーバーで同時に変更を加えた場合、その両方の変更が保持されます。 最後に書き込まれた変更では、元のファイル名が維持されます。 古いファイルでは、"ソース" マシンと競合番号が名前に追加されます。 次の命名規則が使用されます。
<拡張子を除くファイル名>-<マシン名>[-#].<拡張子>
たとえば、CompanyReport.docx で競合が生じたとします。古い方の書き込みが CentralServer で行われた場合、最初の競合で生じるファイルの名前は CompanyReport-CentralServer.docx となります。 2 回目の競合では、CompanyReport-CentralServer-1.docx という名前になります。
参照：https://docs.microsoft.com/ja-jp/azure/storage/files/storage-files-faq
------------------------------------------------------------------------------------
では検証してみます。
Sync-serverとsync-server2のtext.txtファイルを同時に開き、それぞれの中身をテスト１、テスト２と編集します。
| Sync-severのファイル | Sync-sever2のファイル |
|
|
|
Sync-serverを保存して閉じた後に、Sync-server2を保存して閉じます。
1分くらい待つと新しいファイルが作成されました。
後から保存したテスト２がtext.txtの内容として残り、先に保存されたファイルは別名で保存されました。
| Sync-severのファイル | Sync-sever2のファイル |
|
|
|
|
text-sync-server.txtという名前で
別ファイルが生成されました
|
後から保存した方が元のファイル を上書き保存しています |
テクニカルドキュメント通りに別名でファイルが生成されることが確認できましたが。
プログラムソースなど複数人がファイルを参照する機会が多い場合はこの方法だと運用は難しいかなと思います。
あくまで競合が起こってしまった際に、編集内容を保護するという役割を持った機能かと思います。
③時計のずれ
いまどきNTPで時刻を合わせていないなどということは無いとは思いますが、Active Directoryに参加していない場合で時刻設定がずれているサーバがあった場合、同期先のタイムスタンプはどうなるのでしょうか。時刻を10分ずらして保存してみます。
sync-server2の時間を10分ずらします。
| sync-server | sync-server2 |
|
|
|
| 21:13 | 21:03(10分遅い) |
Sync-server2のtext.txtファイルを保存して同期されたsync-serverのファイルのタイムスタンプを確認してみます。
Sync-server2のローカルタイムで21:04に保存したファイルは、sync-server側で見ると10分前のタイムスタンプになってます。
Azure側で持っている時間をタイムスタンプにしているわけではないようです。
では、タイムゾーンが異なる場合のタイムスタンプはどうなるのでしょうか。
各支店のファイルサーバを同期できるメリットが発揮されるのは海外拠点とのやり取りかと思いますので、タイムゾーンが異なるサーバ間での同期はあるんじゃないかなと思います。
試してみましょう。
Sync-server2をハノイ時間に設定してみます。
UTC+07:00なので日本時間のSync-Serverとは2時間ほど違います
Sync-server2のファイルを編集して保存します。
エクスプローラーに表示されているタイムスタンプはそれぞれのタイムゾーンで表示されていました。
| sync-server | sync-server2 |
|
|
|
| 21:43 | 19:43 |
３． おまけ
ここからはAzure File Syncの検証をしている時にわかったTIPS的なものを載せていきたいと思います。
①インストールの失敗
前編でAzure File Syncクライアントをのインストール方法について記載しておりますのでそちらもご覧ください。
クライアントには「Windows Management Framework 5.1 」および「PowerShell AzureRM」がインストールされている必要があります。
これらがインストールされている場合は、インストーラーのウィザード終了後にServer Registrationウィンドウが自動的に立ち上がるので問題ありませんが、インストールされていない場合は以下のようなメッセージが表示されます。
問題は、「Windows Management Framework 5.1 」と「PowerShell AzureRM」を正常にインストールした後、この画面にどう戻ったらよいかわからないという点です。
その場合はエクスプローラーで以下の場所から実行ファイルを開くと、Server Registrationウィンドウが開きます。
※C:\Program Files\Azure\StorageSyncAgent\ServerRegistration.exe
4． まとめ
前編・後編とAzure File Syncを触って、いろいろと試してみました私の所感をまとめます。
GOOD
・同期の速度がかなり速い！！
・海外拠点とのやりとりは便利かな。
Not GOOD
・Windows Server2012/2016のみ対応
・ソフトウェア開発であればGithub、ExcelやPowerPointなどの執務で使うファイルであればOffice365やBOXを使った方がオンプレ必要ないので管理がラク。
Azure File Syncは複数拠点のオンプレミスのファイルサーバ(Windows Server2012/2016)のファイルを同期するといった特殊用途で本領発揮するので、なかなか使いどころが難しいかもしれませんね。
私が考える利用シチュエーションとしては、
３DCGを海外拠点でオフショア制作する場合なんかはかなり有効に使えるんじゃないかなと思ってます。
以上です！
