次の方法で共有


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

この記事では、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 スイッチを使用すると、ファイルの同期とクラウドの階層化が可能になり、初期アップロード時に領域が作成されます
  • ヒートマップが形成される前に階層化が行われる場合、ファイルは最後に変更されたタイムスタンプによって階層化されます

次のステップ