クラウドを使った階層化ポリシー
クラウドを使った階層化には、どのファイルをクラウドに階層化させるかを判断するための 2 つのポリシー、ボリュームの空き領域ポリシーと日付ポリシーがあります。
ボリュームの空き領域のポリシーを使用すると、サーバー エンドポイントが配置されているローカル ボリュームの指定した割合が常に解放されるようになります。
日付ポリシーを使用すると、最終アクセス日が x 日以降のファイルが階層化されます。 ボリュームの空き領域ポリシーは、常に優先されます。 日付ポリシーに示された日数分のファイルを保管しておく十分な空き領域がない場合、ボリュームの空き領域の割合が適切になるまで、Azure File Sync によって日付ポリシーが上書きされ、最もアクセスの少ないファイルの階層化が継続します。
両方のポリシーが連携するしくみ
ここでは、次の例を使用して、これらのポリシーの動作を説明します。あなたは、500 GiB のローカル ボリュームで Azure File Sync を構成し、クラウドを使った階層化は有効にしていないとします。 ファイル共有には、以下のファイルが保管されています。
| ファイル名 | 最終アクセス時刻 | ファイル サイズ | 格納先 |
|---|---|---|---|
| ファイル 1 | 2 日前 | 10 GiB | サーバーと Azure ファイル共有 |
| ファイル 2 | 10 日前 | 30 GiB | サーバーと Azure ファイル共有 |
| ファイル 3 | 1 年前 | 200 GiB | サーバーと Azure ファイル共有 |
| ファイル 4 | 1 年、2 日前 | 120 GiB | サーバーと Azure ファイル共有 |
| ファイル 5 | 2 年、1 日前 | 140 GiB | サーバーと Azure ファイル共有 |
変更 1: クラウドを使った階層化を有効にし、ボリュームの空き領域ポリシーを 20% に設定し、日付ポリシーは無効のままにしたとします。 この構成の場合、クラウドを使った階層化によって、ローカル コンピューターの領域の 20% (この場合は 100 GiB) が常に解放され、使用できるようになります。 つまり、ローカル キャッシュの合計容量は 400 GiB になります。 この 400 GiB には、ローカル ボリュームで最も最近かつ頻繁にアクセスされるファイルが格納されます。
この構成の場合、ファイル 1 から 4 のみがローカル キャッシュに格納され、ファイル 5 は階層化されます。 これは、使用可能な 400 GiB のうちの 360 GiB にすぎません。 ファイル 5 は 140 GiB で、ローカルにキャッシュされると、400 GiB の制限を超えてしまいます。
変更 2: たとえば、ユーザーがファイル 5 にアクセスしたとします。 これにより、ファイル 5 は共有内で最も最近アクセスされたファイルになります。 その結果、ファイル 5 はローカル キャッシュに格納され、400 GiB の制限に収まるよう、ファイル 4 が階層化されます。 次の表は、この更新を踏まえた、ファイルの格納場所を示したものです。
| ファイル名 | 最終アクセス時刻 | ファイル サイズ | 格納先 |
|---|---|---|---|
| ファイル 5 | 2 時間前 | 140 GiB | サーバーと Azure ファイル共有 |
| ファイル 1 | 2 日前 | 10 GiB | サーバーと Azure ファイル共有 |
| ファイル 2 | 10 日前 | 30 GiB | サーバーと Azure ファイル共有 |
| ファイル 3 | 1 年前 | 200 GiB | サーバーと Azure ファイル共有 |
| ファイル 4 | 1 年、2 日前 | 120 GiB | Azure ファイル共有、ローカルで階層化 |
変更 3: 日付ベースの階層化ポリシーが 60 日、ボリュームの空き領域ポリシーが 70% になるようにポリシーを更新したとします。 この場合、ローカル キャッシュに格納できるのは最大でわずか 150 GiB になります。 ファイル 2 の最終アクセス日は 60 日前以内ですが、ボリュームの空き領域ポリシーは日付ポリシーを上書きするため、70% のローカル空き領域を維持するためにファイル 2 は階層化されます。
変更 4: ボリュームの空き領域ポリシーを 20% に変更した後、Invoke-StorageSyncFileRecall を使用してクラウドを使った階層化ポリシーの範囲内でローカル ドライブに収まるすべてのファイルを再現した場合、表は次のようになります。
| ファイル名 | 最終アクセス時刻 | ファイル サイズ | 格納先 |
|---|---|---|---|
| ファイル 5 | 1 時間前 | 140 GiB | サーバーと Azure ファイル共有 |
| ファイル 1 | 2 日前 | 10 GiB | サーバーと Azure ファイル共有 |
| ファイル 2 | 10 日前 | 30 GiB | サーバーと Azure ファイル共有 |
| ファイル 3 | 1 年前 | 200 GiB | Azure ファイル共有、ローカルで階層化 |
| ファイル 4 | 1 年、2 日前 | 120 GiB | Azure ファイル共有、ローカルで階層化 |
この場合、ファイル 1、2、5 はローカルにキャッシュされ、ファイル 3 と 4 が階層化されます。 日付ポリシーは 60 日に設定されているため、ボリュームの空き領域ポリシーではローカルに最大 400 GiB 保管できるにもかかわらず、ファイル 3 と 4 は階層化されます。
Note
ユーザーがボリュームの空き領域ポリシーをより小さい値に変更 (たとえば、20% から 10% へ) したり、日付ポリシーをより大きな値に変更 (たとえば、20 日から 50日へ) しても、ファイルは自動的に再現されません。
ローカル ボリューム上の複数のサーバー エンドポイント
クラウドを使った階層化は、1 つのローカル ボリューム上の複数のサーバー エンドポイントに対して有効にすることができます。 この構成では、同じボリューム上のすべてのサーバー エンドポイントに対して、ボリュームの空き領域を同じ値に設定する必要があります。 同じボリューム上の複数のサーバー エンドポイントに異なるボリューム空き領域ポリシーを設定すると、設定されているボリューム空き領域の割合の内、最大値が優先されます。 これは、有効なボリューム空き領域ポリシーと呼ばれます。 たとえば、同じローカル ボリュームに 3 つのサーバー エンドポイントがあり、1 つを 15% に、もう 1 つを 20% に、そして 3 つ目を 30% に設定した場合、空き容量が 30% を下回った段階で、それらすべてのうち最もアクセスの少ないファイルの階層化が開始します。