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

2025-05-07

この記事では、Azure File Sync のクラウド階層化ポリシーの選択と調整に関するガイダンスを提供します。この記事を読む前に、クラウドの階層化のしくみを理解していることを確認してください。クラウド階層化の基礎については、「 Azure File Sync のクラウド階層化について」を参照してください。例を含むクラウド階層化ポリシーの詳細については、「 Azure File Sync クラウドの階層化ポリシー」を参照してください。

制限事項

Windows システムボリュームでは、クラウドを使った階層化はサポートされていません。
サーバーエンドポイントのクォータ管理にファイルサーバーリソースマネージャー (FSRM) を使用している場合は、ボリュームレベルではなくフォルダーレベルでクォータを適用することをお勧めします。ボリュームレベルの FSRM クォータがある場合でも、クラウドの階層化を有効にすることができます。 FSRM クォータが設定されると、呼び出される空き領域クエリ API は、クォータ設定に従ってボリュームの空き領域を自動的に報告します。ただし、ハードクォータがボリュームルートに存在する場合、ボリューム上の実際の空き領域とボリューム上のクォータ制限付き領域は同じでない可能性があります。その結果、サーバーエンドポイント上に十分なボリュームの空き領域がないと Azure File Sync が判断すると、無限の階層化が発生する可能性があります。

ファイルを階層化するための最小サイズ

階層化するファイルの最小ファイルサイズは、ファイルシステムクラスターのサイズに基づきます。クラウドの階層化の対象となる最小ファイルサイズは、クラスターサイズの 2 倍、少なくとも 8 KiB で計算されます。次の表は、ボリュームクラスターのサイズに基づいて階層化できる最小ファイルサイズを示しています。

ボリュームクラスターサイズ	このサイズ以上のファイルは階層化できます
4 KiB 以下 (4,096 バイト)	8 KiB
8 KiB (8,192 バイト)	16 KiB
16 KiB (16,384 バイト)	32 KiB
32 KiB (32,768 バイト)	64 KiB
64 KiB (65,536 バイト)	128 KiB
128 KiB (131,072 バイト)	256 KiB
256 KiB (262,144 バイト)	512 KiB
512 KiB (524,288 バイト)	1 メビバイト (MiB)
1 MiB (1,048,576 バイト)	2 MiB
2 MiB (2,097,152 バイト)	4 MiB

Azure File Sync では、クラスターサイズが最大 2 MiB のボリュームでのクラウド階層化がサポートされています。

Windows で使用されるすべてのファイルシステムは、クラスターサイズ (アロケーションユニットサイズとも呼ばれます) に基づいてハードディスクを整理します。クラスターサイズは、ファイルを保持するために使用できる最小のディスク領域を表します。ファイルサイズがクラスターサイズの偶数の倍数に出ない場合は、ファイルを保持するために追加の領域 (クラスターサイズの次の倍数まで) を使用する必要があります。

Azure File Sync は、Windows Server 2012 R2 以降の NTFS ボリュームでサポートされています。次の表では、Windows Server で新しい NTFS ボリュームを作成するときの既定のクラスターサイズについて説明します。

ボリュームサイズ	Windows Server
7 MiB – 16 TiB	4 KiB
16 TiB – 32 TiB	8 KiB
32 TiB – 64 TiB	16 KiB

ボリュームの作成時に、別のクラスターサイズでボリュームを手動でフォーマットした可能性があります。ボリュームが古いバージョンの Windows に由来する場合、既定のクラスターサイズも異なる場合があります。 4 KiB より小さいクラスターサイズを選択した場合でも、階層化できる最小のファイルサイズとして 8 KiB の制限が適用されます。 (技術的に 2 倍のクラスターサイズが 8 KiB 未満の場合でも)。

絶対最小値の理由は、NTFSが非常に小さなファイルを格納する方法によるものです - 1 KiBから4 KiBサイズのファイル。ボリュームの他のパラメーターによっては、小さなファイルがディスク上のクラスターにまったく格納されない可能性があります。このようなファイルをボリュームのマスターファイルテーブルまたは "MFT レコード" に直接格納する方が効率的な場合があります。クラウド階層化再解析ポイントは常にディスクに格納され、1 つのクラスターを占有します。このような小さなファイルを階層化すると、最終的にスペースが節約されない可能性があります。極端なケースでは、クラウドの階層化を有効にして、より多くの領域を使用する可能性があります。それを防ぐために、クラウドの階層化で階層化されるファイルの最小サイズは、4 KiB 以下のクラスターサイズで 8 KiB です。

初期ポリシーの選択

一般に、サーバーエンドポイントでクラウドの階層化を有効にする場合は、個々のサーバーエンドポイントごとに 1 つのローカル仮想ドライブを作成する必要があります。サーバーエンドポイントを分離すると、クラウドの階層化のしくみを理解し、それに応じてポリシーを調整しやすくなります。ただし、同じドライブに複数のサーバーエンドポイントがある場合でも、Azure File Sync は機能します。詳細については、「ローカルボリューム上の複数のサーバーエンドポイント」セクションを参照してください。また、クラウドの階層化を初めて有効にする場合は、日付ポリシーを無効にし、ボリュームの空き領域ポリシーを約 10% ~ 20%に維持することをお勧めします。ほとんどのファイルサーバーボリュームでは、通常、20% ボリュームの空き領域が最適なオプションです。

注

一部の移行シナリオでは、ソースよりも少ない記憶域を Windows Server インスタンスにプロビジョニングした場合、クラウドへの階層化ファイルへの移行中にボリュームの空き領域を一時的に 99% に設定し、移行が完了した後でより便利なレベルに設定できます。

わかりやすくするために、また、項目の階層化方法を明確に理解するために、ボリュームの空き領域ポリシーを主に調整し、必要な場合を除き、日付ポリシーを無効にしておくことをお勧めします。ほとんどのお客様は、ローカルキャッシュにできるだけ多くのホットファイルを格納し、残りをクラウドに階層化することが重要だと考えるので、これをお勧めします。ただし、日付ポリシーは、ローカルディスク領域を事前に解放する必要があり、日付ポリシーで指定された日数後にアクセスされたサーバーエンドポイント内のファイルをローカルに保持する必要がないことがわかっている場合に役立つ場合があります。日付ポリシーを設定すると、同じボリューム上の他のエンドポイントの貴重なローカルディスク容量が解放され、より多くのファイルがキャッシュされます。

ポリシーを設定したら、エグレスを監視し、それに応じて両方のポリシーを調整します。 Azure Monitor のアプリケーションメトリック別に、 クラウド階層化リコールサイズ と クラウド階層化リコールサイズ を確認することをお勧めします。また、サーバーエンドポイントのキャッシュヒット率を監視して、ローカルキャッシュに既に存在する開いているファイルの割合を判断することもお勧めします。エグレスを監視する方法については、「クラウドの階層化の監視」を参照してください。

ポリシーの調整

Azure から繰り返し呼び出されるファイルの数が必要以上に多い場合は、ローカルサーバーボリュームに保存する領域よりもホットなファイルが多い可能性があります。可能であればローカルボリュームサイズを増やすか、ボリュームの空き領域ポリシーの割合を少しずつ減らします。ボリュームの空き領域の割合を減らすと、悪影響を及ぼす可能性もあります。データセット内の変更頻度が高いほど、新しいファイルと "コールド" ファイルの呼び戻しのために、より多くの空き領域が必要になります。階層化は最大 1 時間の遅延で開始され、その後は処理時間が必要になります。そのため、ボリュームには常に十分な空き領域を確保しておく必要があります。

データをローカルに保持すると、Azure から呼び出されるファイルの数が少ないほどエグレスコストが低くなりますが、必要なオンプレミスストレージの量も増え、独自のコストがかかります。

ボリュームの空き領域ポリシーを調整する場合、ローカルに保持する必要があるデータの量は、帯域幅、データセットのアクセスパターン、および予算の要因によって決まります。低帯域幅接続では、ユーザーの遅延を最小限に抑えるために、より多くのローカルデータが必要になる場合があります。それ以外の場合は、特定の期間中のチャーンレートに基づいて設定できます。たとえば、1 TiB データセットの 10% が毎月変更されたり、アクティブにアクセスされたりすることがわかっている場合は、ファイルを頻繁に呼び出さないように、100 GiB をローカルに保持することをお勧めします。ボリュームが 2 TiB の場合は、5% (または 100 GiB) をローカルのままにします。つまり、残りの 95% はボリュームの空き領域の割合です。ただし、変更頻度が高い期間はバッファーを追加する必要があります。つまり、ボリュームの空き領域の割合を大きくして開始し、後で必要に応じて調整する必要があります。

標準的な操作手順

Azure File Sync を使用して初めて Azure Files に移行する場合、クラウドの階層化は初期アップロードに依存します
クラウドを使った階層化では、60 分ごとにボリュームの空き領域と日付のポリシーに準拠していることが確認されます
ファイルの移行時に Robocopy で /LFSM スイッチを使用すると、ファイルの同期とクラウドの階層化が可能になり、初期アップロード時に領域が作成されます
ヒートマップが形成される前に階層化が行われる場合、ファイルは最後に変更されたタイムスタンプによって階層化されます

次のステップ

Azure File Sync のデプロイの計画