次の方法で共有


クラウドの階層化の概要

Azure File Sync のオプション機能であるクラウドを使った階層化により、オンプレミスのファイル サーバーのパフォーマンスを維持しながら、必要なローカル ストレージの量を減らすことができます。

この機能を有効にすると、アクセス頻度の高い (ホット) ファイルのみがローカル サーバーに格納されます。 アクセス頻度の低い (クール) ファイルは、名前空間 (ファイルとフォルダーの構造) とファイル コンテンツに分割されます。 名前空間はローカルに保存され、ファイル コンテンツはクラウド内の Azure ファイル共有に格納されます。

ユーザーが階層化されたファイルを開くと、Azure File Sync によって Azure ファイル共有のファイル データがシームレスに呼び戻されます。

クラウドを使った階層化のしくみ

クラウドを使った階層化のポリシー

クラウドを使った階層化を有効にする場合は、クール ファイルを階層化するタイミングを Azure File Sync に知らせるために設定するポリシーとして、ボリュームの空き領域ポリシーおよび日付ポリシー の 2 つのポリシーがあります。

ボリュームの空き領域ポリシー

ボリュームの空き領域ポリシーは、ローカル ディスク上で一定の容量が使用されている場合に、クール ファイルをクラウドに階層化するように Azure File Sync に指示します。

たとえば、ローカル ディスク容量が 200 GiB であり、少なくとも 40 GiB のローカル ディスク容量を常に空けておきたい場合は、ボリュームの空き領域ポリシーを 20% に設定する必要があります。 ボリュームの空き領域は、個々のディレクトリまたはサーバー エンドポイントのレベルではなく、ボリューム レベルで適用されます。

日付ポリシー

日付ポリシーを使用すると、x 日間アクセスされていない (読み書きされていない) クール ファイルがクラウドに階層化されます。 たとえば、アクセスされずに 15 日以上経過したファイルが通常はアーカイブ ファイルであることがわかった場合は、日付ポリシーを 15 日に設定します。

日付ポリシーとボリュームの空き領域のポリシーを連携させる方法の例については、Azure File Sync のクラウドを使った階層化ポリシーの選択に関するページを参照してください。

Windows Server のデータ重複除去

データ重複除去は、Windows Server 2016 以降でクラウドを使った階層化が有効になっているボリュームでサポートされています。 詳細については、「Azure File Sync のデプロイの計画」を参照してください。

クラウドを使った階層化のヒートマップ

Azure File Sync では、ファイル アクセス (読み書き操作) が一定期間監視され、ファイルのアクセス頻度や最近のアクセス状況に応じて、すべてのファイルにヒート スコアが割り当てられます。 これらのスコアを使用して、各サーバー エンドポイントで、名前空間の "ヒートマップ" が作成されます。 このヒートマップには、クラウドを使った階層化が有効になっている場所にあるすべての同期ファイルがヒート スコア順に一覧表示されています。 最近開いた頻繁にアクセスされるファイルはホットと見なされます。ほとんど開かれず、しばらくアクセスされていないファイルはクールと見なされます。

このヒートマップ内の個々のファイルの相対位置を決めるため、システムでは、最終アクセス時刻、最終変更時刻、作成時刻の順に、これらのタイムスタンプの最大値が使用されます。

通常、最終アクセス時刻が追跡され、使用できます。 ただし、クラウドを使った階層化が有効の状態で新しいサーバー エンドポイントが作成された場合は、ファイル アクセスを監視するのに十分な時間が経過していません。 有効な最終アクセス時刻がない場合は、ヒートマップ内の相対位置を評価するために最終変更時刻が使用されます。

日付ポリシーも同じように動作します。 最終アクセス時刻がない場合、日付ポリシーは最終更新時刻に基づいて動作します。 それを使用できない場合は、ファイルの作成時刻にフォールバックします。 やがて、システムで監視するファイル アクセス要求が増え、自動的に、自己記録している最終アクセス時刻を使用するようになります。

Note

クラウドの階層化では、最終アクセス時刻の追跡は NTFS 機能に依存せずに行われます。 この NTFS 機能は既定でオフになっており、パフォーマンスに関する考慮事項により、この機能を手動で有効にすることはお勧めしません。 クラウドを使った階層化では、最終アクセス時刻が個別に追跡されます。

事前呼び戻し

ファイルが作成または変更される際、指定したサーバーにファイルを事前に呼び戻すことができます。 事前呼び戻しを実装すると、新しいファイルまたは変更したファイルを、指定したサーバーですぐに利用できるようになります。

たとえば、世界各地に分散しているある企業が、米国とインドにブランチ オフィスを構えているとします。 米国の朝、インフォメーション ワーカーが新しいプロジェクトのために、新しいフォルダーとファイルを作成して、1 日中それに取り組みます。 Azure File Sync によって、フォルダーとファイルが Azure ファイル共有 (クラウド エンドポイント) に同期されます。 インドにいるインフォメーション ワーカーは、インドのタイムゾーンでプロジェクトの作業を続行します。 彼らが朝に作業に取り掛かる際、インドにあるローカルの Azure File Sync 対応サーバーでは、インド チームが効率的にローカル キャッシュで作業できるように、これらの新しいファイルがローカルで利用できるようになっている必要があります。 このモードを有効にすると、Azure ファイル共有でファイルが変更または作成されるとすぐに事前にファイルを呼び戻すように、サーバーに伝えられます。

ファイルをローカルのサーバーに呼び戻す必要がない場合に不要な呼び戻しを行うと、エグレス トラフィックとコストが増える場合があります。 そのため、事前呼び戻しの有効化は、クラウドの最近の変更をサーバー上のキャッシュに事前に保存しておくことが、そのサーバー上のファイルを使用しているユーザーやアプリケーションに有益であることがわかっている場合に行ってください。

事前呼び戻しを有効にすると、サーバーの帯域幅の使用量が増加し、ローカル サーバー上の他の比較的新しいコンテンツが、呼び戻されるファイルの増加によって大幅に階層化される可能性もあります。 そうして、急速な階層化が実行されると、階層化処理を実行しているファイルがホットであるとサーバーで判断されて、さらなる呼び戻しが行われる場合があります。

事前呼び戻しの詳しい説明は、Azure File Sync のデプロイに関する記事をご覧ください。

階層化されたファイルおよびローカルにキャッシュされたファイルの動作

クラウドを使った階層化とは、名前空間 (ファイルとフォルダーの階層、およびファイルのプロパティ) とファイル コンテンツを分離することです。

階層化されたファイル

階層化されたファイルでは、ファイルのコンテンツ自体がローカルに保存されていないため、ディスク上のサイズはゼロになります。 ファイルが階層化されると、Azure File Sync ファイル システム フィルター (StorageSync.sys) によって、ローカルでファイルが再解析ポイントと呼ばれるポインターと置き換えられます。 再解析ポイントは Azure ファイル共有内のファイルへの URL を表します。 サード パーティ アプリケーションで階層化されたファイルを安全に識別できるように、階層化されたファイルには offline 属性と FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS 属性の両方が NTFS 内で設定されます。

A screenshot of a file's properties when it is tiered - namespace only.

ローカルにキャッシュされたファイル

オンプレミスのファイル サーバーに格納されているファイルの場合、ファイル全体 (ファイル属性とファイル コンテンツ) はローカルに保存されるため、ディスク上のサイズはファイルの論理サイズとほぼ同じになります。

A screenshot of a file's properties when it is not tiered - namespace + file content.

また、ファイルが部分的に階層化されるか、または部分的に呼び戻される場合もあります。 部分的に階層化されたファイルは、一部分だけをディスクに保存します。 ファイルへのストリーミング アクセスをサポートしているアプリケーションでファイルの部分的な読み取りを行っている場合は、ファイルの一部分だけをボリュームに呼び戻すことができます。 マルチメディア プレイヤーと zip ツールはその例です。 Azure File Sync は効率的なサービスであり、要求された情報だけを、接続している Azure ファイル共有から呼び戻します。

Note

サイズは、ファイルの論理サイズを表します。 ディスク上のサイズは、ディスクに格納されているファイル ストリームの物理サイズを表します。

ディスク領域不足モード

サーバー エンドポイントを持つディスクは、クラウドを使った階層化が有効になっている場合でも、さまざまな理由により領域が不足する可能性があります。 これらの理由には以下のものが含まれます。

  • サーバー エンドポイント パスの外部のディスクにデータが手動でコピーされる
  • 低速な同期または同期の遅延のため、ファイルが階層化されない
  • 階層化されたファイルの過剰な呼び戻し

ディスク領域が不足すると、Azure File Sync が正しく機能せず、使用できなくなる可能性もあります。 Azure File Sync ではこれらの発生を完全に防ぐことはできませんが、(15.1 以降のバージョンの Azure File Sync エージェントで使用可能な) ディスク領域不足モードは、サーバー エンドポイントがこの状況にならないように、またサーバーがすばやく抜け出せるよう設計されています。

クラウド階層化が有効になっているサーバー エンドポイントの場合、ボリュームの空き領域が計算されたしきい値を下回った場合、ボリュームはディスク領域不足モードになります。

ディスク領域不足モードでは、Azure File Sync エージェントの 2 つの機能の動作が変わります。

  • 予防的な階層化: このモードでは、File Sync エージェントによってファイルがより積極的にクラウドに階層化されます。 同期エージェントでは、通常の 1 時間ごとの頻度ではなく 1 分ごとに、階層化されるファイルがチェックされます。 ボリュームの空き領域ポリシーの階層化は通常、初期アップロード同期中に、完全アップロードが完了するまでは行われませんが、ディスク領域不足モードでは、初期アップロード同期中に階層化が有効になり、個々のファイルが Azure ファイル共有にアップロードされるとファイルの階層化が検討されます。

  • 非保持型呼び戻し: 階層化されたファイルをユーザーが開くとき、Azure ファイル共有から直接呼び戻されたファイルはディスクに保持されません。 Invoke-StorageSyncFileRecall コマンドレットによって開始された呼び戻しはこの規則の例外であり、ディスクに保持されます。

ボリュームの空き領域がしきい値を上回ると、Azure File Sync は自動的に通常の状態に戻ります。 ディスク領域不足モードは、クラウド階層化が有効になっているサーバーにのみ適用され、ボリュームの空き領域ポリシーが常に優先されます。

ボリュームに 2 つのサーバー エンドポイント (1 つは階層化が有効で、1 つは階層化なし) がある場合、ディスク領域不足モードは、階層化が有効になっているサーバー エンドポイントにのみ適用されます。

ディスク領域不足モードのしきい値はどのように計算されますか?

しきい値は、次の 3 つの数値のうち最小値を使用して計算します。

  • ボリューム サイズの 10% (GiB 単位)
  • ボリュームの空き領域ポリシー (GiB)
  • 20 GiB

次の表に、しきい値の計算方法と、ボリュームがディスク領域不足モードになる状況の例をいくつか示します。

ボリューム サイズ ボリューム サイズの 10% ボリュームの空き領域ポリシー しきい値 = Min(ボリューム サイズの 10%, ボリュームの空き領域ポリシー, 20 GB) ボリュームの現在の空き領域 ディスク領域不足モードか? 理由
100 GiB 10 GiB 7% (7 GiB) 7 GiB = Min(10 GiB, 7 GiB, 20 GiB) 9% (9 GiB) いいえ 現在のボリュームの空き領域 (9 GiB) > しきい値 (7 GiB)
100 GiB 10 GiB 7% (7 GiB) 7 GiB = Min(10 GiB, 7 GiB, 20 GiB) 5% (5 GiB) はい 現在のボリュームの空き領域 (5 GiB) < しきい値 (7 GiB)
300 GiB 30 GiB 8% (24 GiB) 20 GiB = Min(30 GiB, 24 GiB, 20 GiB) 7% (21 GiB) いいえ 現在のボリュームの空き領域 (21 GiB) > しきい値 (20 GiB)
300 GiB 30 GiB 8% (24 GiB) 20 GiB = Min(30 GiB, 24 GiB, 20 GiB) 6% (18 GiB) はい 現在のボリュームの空き領域 (18 GiB) < しきい値 (20 GiB)

ディスク領域不足モードとボリュームの空き領域ポリシーの関係はどうなっていますか?

ディスク領域不足モードは、ボリュームの空き領域ポリシーを常に優先します。 しきい値の計算は、ユーザーが設定したボリュームの空き領域ポリシーが優先するように設計されています。

サーバー エンドポイントがディスク領域不足モードになっている最も一般的な原因は何ですか?

ディスク領域不足モードの主な原因は、階層化が有効なサーバー エンドポイントがあるディスクに大量のデータをコピーまたは移動することです。

ディスク領域不足モードを終了する方法は?

サーバー エンドポイントでディスク領域不足モードを終了するには、次の 2 つの方法があります。

  1. ディスク領域不足モードでは、呼び戻しを繰り返さず、ファイルの階層化を頻繁に行わないようにすると、介入を必要とせずに、通常の動作に自動的に切り替わります。
  2. ボリューム サイズを増やすか、サーバー エンドポイントの外部の領域を解放することで、プロセスを手動で高速化できます。

サーバーがディスク領域不足モードかどうかを確認する方法は?

  • サーバー エンドポイントがディスク領域不足モードの場合は、Azure portal のサーバー エンドポイントの [エラーとトラブルシューティング] タブのクラウドを使った階層化の正常性セクションに表示されます。
  • 各サーバー エンドポイントで、1 分ごとにイベント ID 19000 がテレメトリ イベント ログに記録されます。 このイベントを使用して、サーバー エンドポイントがディスク領域不足モードである (IsLowDiskMode = true) かどうかを判断します。 テレメトリ イベント ログは、イベント ビューアーの Applications and Services\Microsoft\FileSync\Agent にあります。

次のステップ