クラウドを使った階層化ポリシーの選択
この記事では、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 ボリュームを作成するときの既定のクラスター サイズを示しています。
| Volume size | 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% です。
Note
一部の移行シナリオでは、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 スイッチを使用すると、ファイルを同期し、初回アップロード中にクラウドを使った階層化によって領域を確保することができます
- ヒートマップが形成される前に階層化が開始された場合、ファイルは最終変更時刻のタイムスタンプに応じて階層化されます。