次の方法で共有


クラウドの階層化の概要

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

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

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

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

クラウドの階層化は、ファイル アクセス パターンを監視し、定義されたポリシーに基づいてファイルを階層化することで機能します。

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

クラウドの階層化を有効にすると、クール ファイルをいつ階層化するかをAzure File Syncに通知するように設定できる 2 つのポリシーがあります。ボリュームの空き領域ポリシーdate ポリシー

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

ボリュームの空き領域ポリシーはAzure File Syncに対して、ローカル ディスクで一定の領域が占有されたときにクール ファイルをクラウドに階層化するように指示します。

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

日付ポリシー

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

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

Windows Server データ重複排除

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

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

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

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

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

日付ポリシーも同じように動作します。 最終アクセス時刻がない場合、日付ポリシーは最終変更時刻に対して機能します。 使用できない場合は、ファイルの作成時刻にフォールバックします。 時間の経過と同時に、システムはより多くのファイル アクセス要求を監視し、自己追跡された最終アクセス時間の使用を自動的に開始します。

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

クラウド階層化ポリシーの選択に関する考慮事項

データの再呼び出しにはクラウドからダウンロードする必要があるので、アクセス頻度の低いコールド ファイルは階層化されたファイルに最適です。 Azure File Syncは、ディスクへの呼び戻しを保持するために合計メモリの% を 10 個予約します。 この予約済みメモリの 60% が使用されている場合、取り消しはディスクに保持されません。 システムに多数の階層化されたファイルが存在し、大量のアクセスが行われると、システムがメモリのしきい値に達する可能性があります。 この状況により、予期しない余分なエグレス、I/O パフォーマンスの低下、システムの低速化、ハングが発生する可能性があります。

プロアクティブなリコール

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

たとえば、世界各地に分散しているある企業が、米国とインドにブランチ オフィスを構えているとします。 米国の朝、インフォメーション ワーカーが新しいプロジェクトのために、新しいフォルダーとファイルを作成して、1 日中それに取り組みます。 Azure File Syncは、フォルダーとファイルを Azure ファイル共有 (クラウド エンドポイント) と同期します。これは、登録されているすべてのサーバー間の中央ハブとして機能します。 インドにいるインフォメーション ワーカーは、インドのタイムゾーンでプロジェクトの作業を続行します。 朝に到着すると、インドのローカル Azure File Sync対応サーバーは、インドチームがローカル キャッシュを効率的に処理できるように、これらの新しいファイルをローカルで使用できるようにする必要があります。 プロアクティブな呼び出しを有効にすると、ユーザーがファイルを開こうとするまで待つのではなく、Azureファイル共有でファイルが変更または作成されたらすぐにダウンロードするようにサーバーに指示されます。

サーバーに呼び戻されたファイルがローカルで必要ない場合、不要な呼び戻しによってエグレス トラフィックとコストが増加する可能性があります。 そのため、クラウドからの最近の変更でサーバーのキャッシュを事前に更新することが、そのサーバーのファイルを使用するユーザーやアプリケーションにプラスの影響を与えると分かっている場合に限り、プロアクティブキャッシュリコールを有効にしてください。

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

事前呼び出しの詳細については、「Deploy Azure File Syncを参照してください。

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

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

階層化されたファイル

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

階層化されたファイルのプロパティのスクリーンショット (名前空間のみ)。

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

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

階層化されていないファイルのプロパティのスクリーンショット (名前空間とファイル コンテンツ)。

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

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

ディスク領域不足モード

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

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

ディスク領域が不足すると、Azure File Syncが正しく機能せず、使用できなくなる可能性もあります。 Azure File Syncではこのような状況を完全に防ぐことはできませんが、ディスク領域の不足モード (15.1 以降のAzure File Sync エージェント バージョンで使用可能) は、サーバー エンドポイントがこの状況に到達するのを防ぐのに役立ち、サーバーが高速に抜け出すのに役立ちます。

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

ディスク領域の不足モードでは、Azure File Sync エージェントは次の 2 つの処理を行います。

  • プロアクティブ階層化: ファイル同期エージェントは、クラウドに対してより積極的にファイルを階層化します。 同期エージェントは、通常の1時間ごとの頻度ではなく、毎分ファイルをティアリングするためのチェックを行います。 ボリュームの空き容量ポリシーに基づく階層化は、通常、アップロードの同期が開始されてからアップロードが完全に完了するまでは行われません。 ただし、ディスク領域の不足モードでは、初期アップロード同期中に階層化が有効になり、個々のファイルがAzureファイル共有にアップロードされると、ファイルは階層化と見なされます。

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

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

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

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

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

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

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

ボリューム サイズ ボリューム サイズの 10% ボリュームの空き領域ポリシー しきい値 = 最小 (ボリューム サイズの 10%、ボリューム空き領域ポリシー、20 GiB) ボリュームの現在の空き領域 ディスク領域不足モードか? 理由
100 GiB 10 GiB 7% (7 ギビバイト) 7 GiB = Min(10 GiB, 7 GiB, 20 GiB) 9% (9 ギビバイト) いいえ 現在のボリュームの空き領域 (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ギビバイト) いいえ 現在のボリュームの空き領域 (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)

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

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

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

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

ディスク領域の不足モードから抜け出す方法

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

サーバーのディスク領域が不足しているかどうかを確認するにはどうすればよいですか?

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

こちらも参照ください