選擇雲端階層處理原則
本文提供 Azure 檔案同步 選取和調整雲端階層處理原則的指引。閱讀本文之前，請確定您了解雲端階層處理的運作方式。 如需雲端階層處理的基本概念，請參閱瞭解 Azure 檔案同步雲端階層處理。 如需雲端階層處理原則與範例的深入說明，請參閱 Azure 檔案同步雲端階層處理原則。
限制
Windows 系統磁碟區不支援雲端階層處理。
如果您使用檔伺服器資源管理員 （FSRM） 來管理伺服器端點上的配額，建議您在資料夾層級套用配額，而不是在磁碟區層級套用配額。 如果您有磁碟區層級的 FSRM 配額，您仍然可以啟用雲端階層處理。 一旦設定 FSRM 配額，所呼叫的可用空間查詢 API 就會根據配額設定，自動報告磁碟區上的可用空間。 不過，當磁碟區根目錄上有硬式配額時，磁碟區上的實際可用空間和磁碟區上的配額限制空間可能不相同。 如果 Azure 檔案同步 認為伺服器端點上沒有足夠的磁碟區可用空間，這可能會導致無休止的階層處理。
階層處理的檔案大小下限
階層處理的檔案大小下限是以檔案系統叢集大小為基礎。 符合雲端階層處理的最小檔案大小是以叢集大小的 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 檔案同步支援對大小上限為 2 Mib 的磁碟區進行雲端階層處理。
Windows 使用的所有文件系統都會根據叢集大小組織硬碟（也稱為配置單位大小）。 叢集大小代表可以用來保存檔案的最小磁碟空間量。 當檔案大小不達到叢集大小的偶數倍時，必須使用額外的空間來保存檔案 - 最多到叢集大小的下一個倍數。
Azure 檔案同步在 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 記錄」中，可能會更有效率。 雲端階層處理重新分析點一律會儲存在磁碟上，並只佔用一個叢集。 將此類小型檔案階層處理可能會導致無法節省空間。 極端的情況下，甚至可能會在啟用雲端階層處理時使用更多空間。 為了防範這一點，雲端階層處理將在 4 KiB 或較小的叢集大小上分層的檔案大小最小為 8 KiB。
選取您的初始原則
一般來說，當您在伺服器端點上啟用雲端階層處理時，您應該針對每個個別的伺服器端點建立一個本機虛擬磁碟機。 隔離伺服器端點可讓您更輕鬆地瞭解雲端階層處理的運作方式，並據以調整您的原則。 但是，即使您在相同的磁碟機上有多個伺服器端點，Azure 檔案同步仍可運作。如需詳細資料，請參閱本機磁碟區上的多個伺服器端點一節。 我們也建議您在第一次啟用雲端階層處理時，讓日期原則保持停用，而磁碟區可用空間原則大約是 10% 到 20%。 對於多數的檔案伺服器磁碟區，20% 的磁碟區可用空間通常是最佳選項。
注意
在某些移轉案例中，如果您在 Windows Server 實例上布建的記憶體比來源少，您可以在移轉至雲端的階層檔案期間暫時將磁碟區可用空間設定為 99%，然後在移轉完成後將其設定為更有用的層級。
為了簡單起見，若要清楚瞭解項目的階層處理方式，我們建議您主要調整您的磁碟區可用空間原則，並維持停用日期原則，除非需要這樣做。 我們建議您這樣做，因為多數客戶發現最有效的方式是盡可能以更多的熱門檔案來填滿本機快取，並在雲端對剩餘檔案進行階層處理。 但是，如果您想要主動釋出本機磁碟空間，而且您知道該伺服器端點中在日期原則中指定的天數之後存取的檔案不需要保留在本機，則日期原則可能相當實用。 設定日期原則會釋出相同磁碟區上其他端點的有價值本機磁碟容量，以快取更多檔案。
設定原則之後，請監視輸出並據以調整這兩個原則。 建議您查看 Azure 監視器中應用程式計量的雲端階層回收大小和雲端階層回收大小。 我們也建議監視伺服器端點的快取命中率，以判斷已在本機快取中開啟的檔案百分比。 若要瞭解如何監視輸出，請參閱監視雲端階層處理。
調整您的原則
如果經常從 Azure 回收的檔案數目大於您想要，您可能會有比在本機伺服器磁碟區上節省空間更多的經常性檔案。 如果可能的話，請增加您的本機磁碟區大小，和/或以微調方式減少磁碟區可用空間原則百分比。 減少太多磁碟區可用空間百分比也可能造成負面影響。 您資料集中較高的流失率需要更多的可用空間 - 針對新檔案和「冷門」檔案的重新叫用。 在最多一小時的延遲內開始進行階層處理，然後需要處理時間，這就是為什麼您的磁碟區上應該永遠有足夠的可用空間。
將更多資料保留在本機代表較低的輸出成本，因為從 Azure 重新叫用的檔案會比較少，但您也需要維護更大量的內部部署儲存體，也就是要負擔其本身的成本。
調整您的磁碟區可用空間原則時，您應該保留在本機的資料量取決於下列因素：頻寬、資料集的存取模式和預算。 使用低頻寬連線時，您可能需要更多的本機資料，以確保使用者的最小延遲。 或者，您可以用指定期間內的流失率為基礎。 例如，如果您知道 1 TiB 數據集的 10% 變更或每個月都主動存取，則您可能想要保留 100 GiB 本機，以免經常重新叫用檔案。 如果您的磁碟區是 2 TiB，則您會想要保留 5% （或 100 GiB） 本機，這表示剩餘的 95% 是您的磁碟區可用空間百分比。 不過，您應該為較高的變換期間新增緩衝區，換句話說，從較大的磁碟區可用空間百分比開始，稍後再調整。
標準作業程序
- 第一次透過 Azure 檔案同步移轉至 Azure 檔案儲存體時，雲端階層處理相依於初始上傳
- 雲端階層處理會每隔 60 分鐘檢查與磁碟區可用空間和日期原則的相容性
- 移轉檔案時在 Robocopy 上使用 /LFSM 切換，可在初始上傳期間進行檔案同步和雲端階層處理以釋出空間
- 如果在熱度圖形成之前進行階層處理，檔案會依上次修改的時間戳記進行階層處理