規劃 Azure 檔案同步部署

採訪和示範 Azure 檔案同步簡介 - 按一下即可播放!

Azure 檔案同步是一項服務,可讓您在內部部署 Windows Server 或雲端虛擬機器上快取數岳 Azure 檔案共用。

本文將向您介紹 Azure 檔案同步概念和功能。 一旦您熟悉 Azure 檔案同步,就請考慮遵循 Azure 檔案同步部署指南來試用這項服務。

這些檔案將儲存在雲端的 Azure 檔案共用中。 Azure 檔案共用的使用方式有兩種:直接裝載這些無伺服器 Azure 檔案共用 (SMB),或使用 Azure 檔案同步快取內部部署的 Azure 檔案共用。您所選擇的部署選項會變更規劃部署時所需考慮的層面。

  • 直接裝戴 Azure 檔案共用:由於 Azure 檔案儲存體會提供 SMB 存取,因此您可以使用 Windows、macOS 和 Linux 中提供的標準 SMB 用戶端,在內部部署或雲端中裝載 Azure 檔案共用。 由於 Azure 檔案共用是無伺服器的,因此針對生產案例進行部署並不需要管理檔案伺服器或 NAS 裝置。 這表示您不需要套用軟體修補程式或交換實體磁碟。

  • 使用 Azure 檔案同步快取內部部署的 Azure 檔案共用:Azure 檔案同步可讓您將組織的檔案共用集中在 Azure 檔案服務中,同時保有內部部署檔案伺服器的靈活度、效能及相容性。 Azure 檔案同步會將內部部署 (或雲端) Windows Server 轉換成 Azure 檔案共用的快速快取。

管理概念

Azure 檔案同步部署有三個基礎管理物件:

  • Azure 檔案共用:Azure 檔案共用是無伺服器的雲端檔案共用,可提供「Azure 檔案同步」同步關係的 雲端端點。 雖然 Azure 檔案共用中的檔案可以直接使用 SMB 或 FileREST 通訊協定進行存取,但是建議您在搭配 Azure 檔案同步使用 Azure 檔案共用時,主要透過 Windows Server 快取存取檔案。這是因為 Azure 檔案儲存體現今缺少有效率的變更偵測機制 (如 Windows Server 所具有的),因此直接對 Azure 檔案共用進行變更將需要一段時間才能傳播回伺服器端點。
  • 伺服器端點:Windows Server上正在同步至 Azure 檔案共用的路徑。 這可以是磁碟區上的特定資料夾或磁碟區的根目錄。 如果伺服器端點的命名空間沒有重疊,則相同磁碟區中可以存在多個伺服器端點。
  • 同步群組:此為物件,可定義 雲端端點 或 Azure 檔案共用與伺服器端點之間的同步關係。 同步群組內的端點會與彼此保持同步。 例如,如果您有兩組不同的檔案需要透過 Azure 檔案同步管理,您會建立兩個同步群組,並將不同的端點個別新增至這兩個同步群組。

Azure 檔案共用管理概念

Azure 檔案共用已部署到 儲存體帳戶,這是代表共用儲存體集區的最上層物件。 此儲存體集區可用來部署多個檔案共用,以及其他儲存體資源 (例如 Blob 容器、佇列或資料表)。 部署到儲存體帳戶的所有儲存體資源,都共用適用於該儲存體帳戶的限制。 如需目前的儲存體帳戶限制,請參閱 Azure 檔案儲存體的擴充 性和效能目標

要用於 Azure 檔案儲存體部署的儲存體帳戶有兩種主要類型:

  • 一般用途第 2 版 (GPv2) 儲存體帳戶:GPv2 儲存體帳戶可讓您在標準/硬碟型 (HDD 型) 的硬體上部署 Azure 檔案共用。 除了儲存 Azure 檔案共用,GPv2 儲存體帳戶還可以儲存其他儲存體資源,例如 Blob 容器、佇列或資料表。
  • FileStorage 儲存體帳戶:FileStorage 儲存體帳戶可讓您在進階/固態磁碟型 (SSD 型) 硬體上部署 Azure 檔案共用。 FileStorage 帳戶只能用來儲存 Azure 檔案共用;不能在 FileStorage 帳戶中部署其他儲存體資源 (Blob 容器、佇列、資料表等等)。 只有 FileStorage 帳戶可以部署 SMB 和 NFS 檔案共用。

在 Azure 入口網站、PowerShell 或 CLI 中,可能會遇到數個其他儲存體帳戶類型。 BlockBlobStorage 和 BlobStorage 這兩個儲存體帳戶類型,不能包含 Azure 檔案共用。 您可能會看到其他兩個儲存體帳戶類型為一般用途第 1 版 (GPv1) 和傳統儲存體帳戶,這兩者都可以包含 Azure 檔案共用。 雖然 GPv1 和傳統儲存體帳戶可能包含 Azure 檔案共用,但 Azure 檔案儲存體的大部分新功能僅適用於 GPv2 和 FileStorage 儲存體帳戶。 因此,我們建議僅將 GPv2 和 FileStorage 儲存體帳戶用於新的部署,若環境中已存在 GPv1 和傳統儲存體帳戶時,則建議對其進行升級。

Azure 檔案同步管理概念

同步群組會部署到 儲存體同步服務,這些服務是最上層物件,用來註冊與 Azure 檔案同步搭配使用的伺服器,並包含同步群組關聯性。 儲存體同步服務資源是儲存體帳戶資源的對等,同樣可以部署到 Azure 資源群組中。 儲存體同步服務可以建立同步群組,跨多個儲存體帳戶和多個已註冊 Windows Server 包含 Azure 檔案共用。

您必須先向儲存體同步服務註冊 Windows Server,才能在儲存體同步服務中建立同步群組。 這會建立 已註冊的伺服器物件,代表您的伺服器或叢集與儲存體同步服務之間的信任關係。 若要註冊儲存體同步服務,您必須先在伺服器上安裝 Azure 檔案同步代理程式。 一次只能向單一儲存體同步服務註冊個別伺服器或叢集。

同步群組包含一個雲端端點或 Azure 檔案共用,以及至少一個伺服器端點。 伺服器端點物件所包含的設定,可設定 雲端階層處理 功能,以提供 Azure 檔案同步的快取功能。為了與 Azure 檔案共用同步,包含 Azure 檔案共用的儲存體帳戶必須與儲存體同步服務位於相同的 Azure 區域中。

重要

您可以變更同步群組中任何雲端端點或伺服器端點的命名空間,並讓您的檔案同步至同步群組中的其他端點。 如果直接對雲端端點 (Azure 檔案共用) 進行變更,則必須先由 Azure 檔案同步變更偵測作業探索到該變更。 針對雲端端點的變更偵測作業,每隔 24 小時才會起始一次。 如需詳細資訊,請參閱 Azure 檔案服務常見問題集

考慮所需儲存體同步服務的計數

上一節討論設定 Azure 檔案同步的核心資源:儲存體同步處理服務。 Windows 的伺服器只能註冊至一個儲存體同步處理服務。 因此,通常最好只部署單一儲存體同步服務,並註冊所有的伺服器。

只有在您有下列情況時,才需要建立多個儲存體同步服務:

  • 永遠不能彼此交換資料的相異伺服器集合。 在此情況下,您會想要將系統設定為排除特定的伺服器集,使其與在不同儲存體同步服務的同步群組中已做為雲端端點的 Azure 檔案共用進行同步處理。 另一種方式是,向不同的儲存體同步服務註冊的 Windows 伺服器無法與相同的 Azure 檔案共用進行同步處理。
  • 需要擁有比單一儲存體同步服務可支援更多的已註冊伺服器或同步群組。 如需詳細資訊,請參閱 Azure 檔案同步調整目標

規劃平衡的同步拓撲

在您部署任何資源之前,請務必先規劃要在本機伺服器上同步處理的內容,以及 Azure 檔案共用。 制訂方案可協助您判斷您需要多少儲存體帳戶、Azure 檔案共用和同步資源。 即使您的資料目前不在 Windows 伺服器或您想要長期使用的伺服器上,這些考慮仍相關。 [遷移] 區段 有助於判斷您的情況的適當遷移路徑。

在此步驟中,您將決定您需要多少個 Azure 檔案共用。 單一 Windows Server 實例 (或叢集) 可同步最多30個 Azure 檔案共用。

您的磁片區上可能會有更多您目前在本機共用的資料夾,以做為使用者和應用程式的 SMB 共用。 此案例最簡單的方式是想像將1:1 對應到 Azure 檔案共用的內部部署共用。 如果您有足夠的共用數目,在30以下的單一 Windows Server 實例中,我們建議使用1:1 對應。

如果您有30個以上的共用,通常不需要將內部部署共用1:1 對應到 Azure 檔案共用。 請考慮下列選項。

共用群組

例如,如果人力資源 (HR) 部門有15個共用,您可能會考慮將所有 HR 資料儲存在單一 Azure 檔案共用中。 將多個內部部署共用儲存在一個 Azure 檔案共用中,並無法讓您在本機 Windows Server 實例上建立一般的15個 SMB 共用。 這只表示您會將這些15個共用的根資料夾組織成共同資料夾下的子資料夾。 然後,您會將此通用資料夾同步處理至 Azure 檔案共用。 如此一來,這個內部部署共用群組就只需要一個雲端中的 Azure 檔案共用。

磁片區同步

Azure 檔案同步支援將磁片區的根目錄同步至 Azure 檔案共用。 如果您同步處理磁片區根目錄,則所有子資料夾和檔案都會移至相同的 Azure 檔案共用。

同步處理磁片區的根目錄不一定是最佳選項。 同步多個位置有其優點。 例如,這麼做有助於讓每個同步範圍的專案數目保持在較低的範圍。 我們會使用100000000個專案來測試 Azure 檔案共用和 Azure 檔案同步 (檔案和資料夾) 每個共用。 但最佳做法是嘗試將低於20000000或30000000的數位保留在單一共用中。 使用較少的專案來設定 Azure 檔案同步,對於檔案同步處理沒有任何好處。較少的專案也會受益于下列案例:

  • 雲端內容的初始掃描可能會更快完成,進而減少在啟用 Azure 檔案同步的伺服器上顯示命名空間的等候。
  • 從 Azure 檔案共用快照集進行雲端端還原的速度將會比較快。
  • 內部部署伺服器的災難復原可以大幅提高速度。
  • 直接在 Azure 檔案共用中對 Azure 檔案共用 (所做) 的變更,可以更快地偵測和同步。

提示

如果您不知道有多少個檔案和資料夾,請參閱 TreeSize tool 中的「卡住軟體 GmbH。

部署對應的結構化方法

在稍後的步驟中部署雲端儲存體之前,請務必在內部部署資料夾與 Azure 檔案共用之間建立對應。 此對應會通知您將布建的 Azure 檔案同步 同步群組 資源數量。 同步處理群組會將您伺服器上的 Azure 檔案共用和資料夾結合在一起,並建立同步連接。

若要決定您需要多少個 Azure 檔案共用,請參閱下列限制和最佳作法。 這麼做可協助您將地圖優化。

  • 安裝 Azure 檔案同步代理程式的伺服器可與最多30個 Azure 檔案共用同步。

  • Azure 檔案共用會部署在儲存體帳戶中。 這種安排可讓儲存體帳戶成為效能數位的調整目標,例如 IOPS 和輸送量。

    理論上,有一個標準 Azure 檔案共用會讓儲存體帳戶可傳遞的效能達到最大效能。 如果您將多個共用放在單一儲存體帳戶中,則會為這些共用建立 IOPS 和輸送量的共用集區。 如果您打算只將 Azure 檔案同步附加至這些檔案共用,將數個 Azure 檔案共用群組至相同的儲存體帳戶將不會造成問題。 請檢查 Azure 檔案共用的效能目標,以深入瞭解相關的計量。 這些限制不適用於 premium 儲存體,其效能會明確地布建並保證每個共用。

    如果您打算將應用程式隨即轉移至 Azure,而該應用程式會以原生方式使用 Azure 檔案共用,您可能需要 Azure 檔案共用的更多效能。 如果這種使用方式是一種可能性,即使在未來,最好還是在自己的儲存體帳戶中建立單一標準 Azure 檔案共用。

  • 每個 Azure 區域的每個訂用帳戶都有250個儲存體帳戶的限制。

提示

有了這項資訊,通常必須將磁片區上的多個最上層資料夾組成新的通用根目錄。 然後,您可以將這個新的根目錄和您群組的所有資料夾,同步處理至單一 Azure 檔案共用。 這項技術可讓您在每個伺服器的30個 Azure 檔案共用同步的限制內保持不變。

在常見的根目錄下,這種群組不會影響對您資料的存取。 您的 Acl 保持不變。 您只需要調整任何共用路徑 (例如 SMB 或 NFS 共用) 您可能會在現在變更為通用根目錄的本機伺服器資料夾上。 沒有其他變更。

重要

Azure 檔案同步最重要的縮放向量是需要同步的 (檔案和) 資料夾的專案數。 如需詳細資訊,請參閱 Azure 檔案同步調整目標

最佳做法是讓每個同步處理範圍的專案數目保持低。 這是您將資料夾對應至 Azure 檔案共用時要考慮的重要因素。 Azure 檔案同步會使用100000000個專案進行測試, (檔案和資料夾) 每個共用。 但通常最好是將低於20000000或30000000的專案數目保留在單一共用中。 如果您開始超過這些數位,請將您的命名空間分割成多個共用。 如果您大致低於這些數位,您可以繼續將多個內部部署共用群組至相同的 Azure 檔案共用。 這種作法可提供您成長的空間。

在您的情況下,您可能會使用稍早) 所述的新通用根資料夾方法,以邏輯方式將一組資料夾同步處理至相同的 Azure 檔案共用 (。 但是重新組合資料夾可能還是比較好,因為它們會同步至兩個 Azure 檔案共用,而不是一個 Azure 檔案共用。 您可以使用這種方法,在伺服器之間保持每個檔案共用的檔案和資料夾數目。 您也可以分割內部部署共用,並在多部內部部署伺服器之間進行同步處理,以增加每台額外的伺服器與30個以上的 Azure 檔案共用同步的功能。

建立對應表

顯示對應表範例的圖表。下載下列檔案,以體驗和使用此映射的內容。

使用先前的資訊來判斷您需要多少 Azure 檔案共用,以及現有資料的哪些部分最後會在哪個 Azure 檔案共用中。

建立記錄您想法的資料表,以便您可以在需要時參考它。 保持組織很重要,因為當您一次布建許多 Azure 資源時,可能會很容易遺失對應計畫的詳細資料。 下載下列 Excel 檔案作為範本,以協助建立您的對應。


Excel icon that sets the context for the download. 下載命名空間對應範本。

Windows 檔案伺服器考量

若要在 Windows Server 上啟用同步功能,您必須安裝 Azure 檔案同步的可下載代理程式。 Azure 檔案同步代理程式提供兩個主要元件:FileSyncSvc.exe,這是負責監視伺服器端點上變更並起始同步工作階段的背景 Windows 服務,以及 StorageSync.sys,這是可啟用雲端階層處理和快速災害復原的檔案系統篩選器。

作業系統需求

支援 Azure 檔案同步搭配下列 Windows Server 版本:

版本 支援的 SKU 支援的部署選項
Windows Server 2019 Datacenter、Standard 和 IoT Full 和 Core
Windows Server 2016 Datacenter、Standard 和 Storage Server Full 和 Core
Windows Server 2012 R2 Datacenter、Standard 和 Storage Server Full 和 Core

Windows Server 的未來版本將會於發佈時加入支援清單。

重要

建議您透過 Windows Update 的最新更新,將搭配 Azure 檔案同步使用的所有伺服器保持在最新狀態。

最低系統資源

Azure 檔案同步需要一部伺服器 (實體或虛擬),其中至少有一個 CPU 和最少 2 GiB 的記憶體。

重要

如果伺服器在啟用動態記憶體的虛擬機器中執行,則 VM 的記憶體應最少設定為 2048 MiB。

對於大部分的生產工作負載,不建議您設定僅具有最低需求的「Azure 檔案同步」同步伺服器。 如需詳細資訊,請參閱建議的系統資源

就像任何伺服器功能或應用程式一樣,Azure 檔案同步的系統資源需求取決於部署的規模;伺服器上較大型的部署需要更多的系統資源。 對於 Azure 檔案同步,規模取決於伺服器端點間的物件數目和資料集上的變換。 單一伺服器可在多個同步群組中具有伺服器端點,而在下表中列出的物件數目則說明伺服器所附加的完整命名空間。

例如,具有 1 千萬個物件的伺服器端點 A + 具有 1 千萬個物件的伺服器端點 B = 2 千萬個物件。 對於該範例部署,我們會建議 8 個 CPU、16 GiB 的記憶體以提供穩定的狀態,以及 (如果可能) 48 GiB 的記憶體以進行初始遷移。

基於效能考量,命名空間資料會儲存在記憶體中。 因此,較大的命名空間需要更多記憶體來維持良好的效能,而更多變換則需要更多的 CPU 才能處理。

在下表中,我們提供了命名空間的大小,以及典型一般用途檔案共用的容量轉換,其中平均檔案大小為 512 KiB。 如果您的檔案大小較小,請考慮為相同容量新增額外的記憶體。 將您的記憶體組態以命名空間的大小為基礎。

命名空間大小 - 檔案與目錄 (數百萬) 一般總容量 (TiB) CPU 核心 建議的記憶體 (GiB)
3 1.4 2 8 (初始同步)/2 (一般變換)
5 2.3 2 16 (初始同步)/4 (一般變換)
10 4.7 4 32 (初始同步)/8 (一般變換)
30 14.0 8 48 (初始同步)/16 (一般變換)
50 23.3 16 64 (初始同步)/32 (一般變換)
100* 46.6 32 128 (初始同步)/32 (一般變換)

*目前不建議同步處理超過 1 千萬個檔案和目錄。 這是以測試閾值為基礎的軟性限制。 如需詳細資訊,請參閱 Azure 檔案同步擴展目標 (機器翻譯)。

提示

命名空間的初始同步是一項使用大量記憶體的作業,我們建議您直到完成初始同步前,配置更多的記憶體。 這不是必要的,但可能會加速初始同步。

一般變換是每天命名空間變更的 0.5%。 對於更高等級的變換,請考慮新增更多 CPU。

  • 本機連結的磁碟區會以 NTFS 檔案系統進行格式化。

評估 Cmdlet

在部署 Azure 檔案同步之前,您應該使用 Azure 檔案同步評估 Cmdlet 來評估其是否與您的系統相容。 此 Cmdlet 會檢查檔案系統和資料集的潛在問題,例如不支援的字元或作業系統版本。 也會檢查下列提到的大部分功能 (但不是全部);我們建議您仔細閱讀本節的其餘部分,以確保您的部署可順利進行。

您可以藉由安裝 Az PowerShell 模組來安裝評估 Cmdlet,此模組可依照此處的指示進行安裝:安裝和設定 Azure PowerShell

使用量

您可以使用幾個不同的方式來叫用評估工具:您可以執行系統檢查、資料集檢查,或兩者都執行。 若要執行系統和資料集的檢查:

Invoke-AzStorageSyncCompatibilityCheck -Path <path>

若要只要測試資料集:

Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks

若只要測試系統需求:

Invoke-AzStorageSyncCompatibilityCheck -ComputerName <computer name> -SkipNamespaceChecks

若要以 CSV 格式顯示結果:

$validation = Invoke-AzStorageSyncCompatibilityCheck C:\DATA
$validation.Results | Select-Object -Property Type, Path, Level, Description, Result | Export-Csv -Path C:\results.csv -Encoding utf8

檔案系統相容性

只在直接連接的 NTFS 磁碟區上支援 Azure 檔案同步。 Windows Server 上直接連接的儲存體或 DAS 表示 Windows Server 作業系統擁有檔案系統。 您可以透過將磁碟實際連接到檔案伺服器、將虛擬磁碟連接至檔案伺服器 VM (例如 Hyper-v 所裝載的 VM),或甚至透過 ISCSI 來提供 DAS。

只支援 NTFS 磁碟區;不支援 ReFS、FAT、FAT32 及其他檔案系統。

下表顯示 NTFS 檔案系統功能的 Interop 狀態:

功能 支援狀態 注意
存取控制清單 (ACL) 完全支援 Azure 檔案同步會保留 Windows 樣式 Discretionary 存取控制清單,並由伺服器端點上的 Windows Server 強制執行。 當直接裝載 Azure 檔案共用時,也可以強制執行 ACL,不過這需要額外的設定。 如需詳細資訊,請參閱身分識別一節
永久連結 已略過
符號連結 已略過
掛接點 部分支援 掛接點可能是伺服器端點的根目錄,但如果伺服器端點的命名空間中包含它們,系統會予以略過。
接合 已略過 例如,分散式檔案系統 DfrsrPrivate 和 DFSRoots 資料夾。
重新分析點 已略過
NTFS 壓縮 完全支援
疏鬆檔案 完全支援 疏鬆檔案會同步 (不會封鎖),但它們會以完整檔案的形式同步至雲端。 如果檔案內容在雲端中 (或另一部伺服器上) 有所變更,該檔案在變更下載之後就不再是疏鬆檔案。
替代資料流 (ADS) 已保留,但未同步 例如,不會同步「檔案分類基礎結構」所建立的分類標籤。 每個伺服器端點上檔案的現有分類標籤會原封不動。

Azure 檔案同步也會略過特定的暫存檔案和系統資料夾:

檔案/資料夾 附註
pagefile.sys 系統專用檔案
Desktop.ini 系統專用檔案
thumbs.db 暫存檔案的縮圖
ehthumbs.db 媒體暫存檔案的縮圖
~$*.* Office 暫存檔
*.tmp 暫存檔
*.laccdb Access DB 鎖定檔
635D02A9D91C401B97884B82B3BCDAEA.* 內部同步檔案
\系統磁碟區資訊 特定磁碟區的資料夾
$RECYCLE.BIN 資料夾
\SyncShareState 同步處理的資料夾

考慮本機磁片上需要多少可用空間

規劃使用 Azure 檔案同步時,請考慮您要在本機磁片上安裝伺服器端點所需的可用空間量。

使用 Azure 檔案同步時,您必須考慮下列各項在本機磁片上佔用的空間:

  • 啟用雲端階層處理之後:

    • 分層式檔案的重新分析點
    • Azure 檔案同步中繼資料資料庫
    • Azure 檔案同步 heatstore
    • 在您的熱快取中完整下載檔案 (如果有任何)
    • 磁片區可用空間原則需求
  • 已停用雲端階層處理:

    • 完整下載檔案
    • Azure 檔案同步 heatstore
    • Azure 檔案同步中繼資料資料庫

我們將使用範例來說明如何估計本機磁片上所需的可用空間量。 假設您已在 Azure Windows VM 上安裝 Azure 檔案同步代理程式,並規劃在磁片 F 上建立伺服器端點。您有1000000檔案,而且想要將所有這些檔案、100000目錄和磁片叢集大小分層為 4 KiB。 磁片大小為 1000 GiB。 您想要啟用雲端階層處理,並將磁片區可用空間原則設定為20%。

  1. NTFS 會配置每個階層式檔案的叢集大小。 1000000 files * 4 KiB cluster size = 4000000 KiB (4 GiB)

注意

階層式檔案所佔用的空間是由 NTFS 所配置。 因此,它不會顯示在任何 UI 中。 3. 同步中繼資料會佔用每個專案的叢集大小。 (1000000 檔案 + 100000 目錄) * 4 KiB 叢集大小 = 4400000 KiB (4.4 GiB) 4. Azure 檔案同步 heatstore 占每個檔案 1.1 KiB。 1000000 files * 1.1 KiB = 1100000 KiB (1.1 GiB) 5. 磁片區可用空間原則為20%。 1000 GiB * 0.2 = 200 GiB

在此情況下,Azure 檔案同步需要大約 209500000 KiB (209.5 GiB) 此命名空間的空間。 將此數量新增至所需的任何額外可用空間,以找出此磁片所需的可用空間量。

容錯移轉叢集

Azure 檔案同步的 [一般用途的檔案伺服器] 部署選項支援 Windows Server 容錯移轉叢集。 「適用於應用程式資料的向外延展檔案伺服器」(SOFS) 或叢集共用磁碟區 (CSV) 上並不支援容錯移轉叢集。

注意

必須在容錯移轉叢集中的每個節點上安裝 Azure 檔案同步代理程式,同步才能正確運作。

重複資料刪除

Windows Server 2016 與 Windows Server 2019
無論是否已在磁片區上的一或多個伺服器端點上啟用或停用雲端階層處理,Windows Server 2016 和 Windows server 2019,都支援重復資料刪除。 在已啟用雲端階層處理的磁碟區上啟用重複資料刪除,可讓您在內部部署中快取更多檔案,而不需佈建更多儲存空間。

在啟用雲端階層處理的磁碟區上啟用重復資料刪除時,伺服器端點位置內的重復資料刪除最佳化檔案將會根據雲端階層處理原則設定進行階層處理,與一般檔案類似。 當重復資料刪除最佳化檔案已進行階層處理,重復資料刪除垃圾收集工作將會自動執行,藉由移除磁碟區上其他檔案不再需要參考的區塊來回收磁碟空間。

請注意,磁碟區節省空間僅適用於伺服器;您在 Azure 檔案共用中的資料將不會進行重復資料刪除。

注意

若要支援 Windows Server 2019 上已啟用雲端階層處理的磁片區上的重復資料刪除,必須安裝 Windows update KB4520062-2019 年10月或更新版本的每月匯總套件更新,並且需要 Azure 檔案同步代理程式版本12.0.0.0 或更新版本。

Windows Server 2012 R2
Azure 檔案同步不支援在 Windows Server 2012 R2 的相同磁碟區上進行重復資料刪除和雲端階層處理。 如果已在磁碟區上啟用重復資料刪除,則必須停用雲端階層處理。

注意事項

  • 如果在安裝 Azure 檔案同步代理程式之前安裝重復資料刪除,則需要重新啟動,才能支援在相同磁碟區上進行重復資料刪除和雲端階層處理。

  • 在啟用雲端階層處理之後,如果在磁碟區上啟用重復資料刪除,則初始重復資料刪除最佳化工作將會最佳化磁碟區上尚未進行階層處理的檔案,而且會對雲端階層處理產生下列影響:

    • 可用空間原則會根據磁碟區上的可用空間,使用熱度圖繼續對檔案進行階層處理。
    • 日期原則會略過檔案的階層處理,而這些檔案可能由於存取檔案的重復資料刪除最佳化作業而有資格進行階層處理。
  • 針對進行中的重復資料刪除最佳化作業,如果檔案尚未進行階層處理,則重復資料刪除 MinimumFileAgeDays 設定會延遲以日期原則進行雲端階層處理。

    • 範例:如果 MinimumFileAgeDays 設定為 7 天,而雲端階層處理日期原則為 30 天,則日期原則會在 37 天後對檔案進行階層處理。
    • 注意:一旦 Azure 檔案同步對檔案進行階層處理,重復資料刪除最佳化工作就會略過該檔案。
  • 如果執行 Windows Server 2012 R2 並已安裝 Azure 檔案同步代理程式的伺服器已升級至 Windows Server 2016 或 Windows Server 2019,則必須執行下列步驟,才能支援在相同磁碟區上進行重復資料刪除和雲端階層處理:

    • 解除安裝適用於 Windows Server 2012 R2 的 Azure 檔案同步代理程式,然後重新啟動伺服器。
    • 下載適用於新伺服器作業系統版本 (Windows Server 2016 或 Windows Server 2019) 的 Azure 檔案同步代理程式。
    • 安裝 Azure 檔案同步代理程式,並重新啟動伺服器。

    注意:解除安裝並重新安裝代理程式時,會保留伺服器上的 Azure 檔案同步組態設定。

分散式檔案系統 (DFS)

Azure 檔案同步支援與 DFS 命名空間 (DFS-N) 和 DFS 複寫 (DFS-R) 互通。

DFS 命名空間 (DFS-N) :DFS-N 伺服器上完全支援 Azure 檔案同步。 您可以將 Azure 檔案同步代理程式安裝在一或多個 DFS-N 成員上,同步伺服器端點與雲端端點之間的資料。 如需詳細資訊,請參閱 DFS 命名空間概觀

DFS 複寫 (DFS-R) :因為 DFS-R 與 Azure 檔案同步都是複寫解決方案,所以建議您在大部分情況下,以 Azure 檔案同步取代 DFS-R。不過有幾個案例,您會想要一起使用 DFS-R 和 Azure 檔案同步:

  • 您正要從 DFS-R 部署移轉至 Azure 檔案同步部署。 如需詳細資訊,請參閱將 DFS 複寫 (DFS-R) 部署移轉至 Azure 檔案同步
  • 並非需要檔案資料複本的每部內部部署伺服器都能直接連線到網際網路。
  • 分支伺服器將資料合併到您要使用 Azure 檔案同步的單一中樞伺服器。

Azure 檔案同步和 DFS-R 如需並存使用:

  1. 務必在具有 DFS-R 複寫資料夾的磁碟區上停用 Azure 檔案同步雲端階層。
  2. 不應在 DFS-R 唯讀複寫資料夾上設定伺服器端點。

如需詳細資訊,請參閱 DFS 複寫概觀

Sysprep

不支援在已安裝 Azure 檔案同步代理程式的伺服器上使用 sysprep,而且此舉可能會導致非預期的結果。 請在部署伺服器映像和完成 sysprep 迷你設定之後,再進行代理程式安裝與伺服器註冊。

如果在伺服器端點上啟用雲端階層處理,則系統會略過階層式檔案,且 Windows 搜尋不會將這些檔案編製索引。 非階層式檔案則會正確編製索引。

其他階層式存放裝置管理 (HSM) 解決方案

不應該搭配 Azure 檔案同步使用其他 HSM 解決方案。

效能和延展性

由於 Azure 檔案同步代理程式會在連線至 Azure 檔案共用的 Windows Server 機器上執行,因此有效的同步效能將取決於基礎結構中的許多因素:Windows Server 和基礎磁碟組態、伺服器與 Azure 儲存體之間的網路頻寬、檔案大小、資料集大小總計,以及資料集的活動。 由於 Azure 檔案同步會在檔案層級上運作,因此 Azure 檔案同步解決方案的效能特性應以每秒處理的物件 (檔案和目錄) 數來測量,以獲得較精準的結果。

不會立即偵測及複寫使用 Azure 入口網站或 SMB 對 Azure 檔案共用所做的變更,和伺服器端點的變更不一樣。 Azure 檔案還沒有變更通知或日誌功能,因此無法在檔案變更時自動啟動同步工作階段。 在 Windows 伺服器上,Azure 檔案同步使用Windows USN 日誌,在檔案變更時自動起始同步會話

若要偵測 Azure 檔案共用的變更,Azure 檔案同步有個已排程的作業,稱為「變更偵測作業」。 變更偵測作業會列舉檔案共用的每個檔案,然後比較該檔案的同步版本。 當變更偵測作業判斷檔案已有變更時,Azure 檔案同步就會起始同步工作階段。 變更偵測作業會每隔 24 小時起始。 由於變更偵測作業的運作方式是列舉 Azure 檔案共用的每個檔案,大命名空間會比小命名空間耗費更長的時間。 大命名空間判斷哪些檔案已變更所耗費的時間,可能會超過 24 小時 (每隔 24 小時執行一次偵測作業)。

如需詳細資訊,請參閱 Azure 檔案同步效能度量Azure 檔案同步調整目標

身分識別

Azure 檔案同步會使用您的標準 AD 型身分識別,不需要設定同步以外的任何特殊設定。當您使用 Azure 檔案同步時,一般預期是大部分的存取都會透過 Azure 檔案同步快取伺服器進行,而不是透過 Azure 檔案共用進行。 由於伺服器端點位於 Windows Server 上,而且 Windows Server 已有很長時間支援 AD 和 Windows 樣式 ACL,因此除了確保向儲存體同步服務註冊的 Windows 檔案伺服器已加入網域之外,不需要採取任何動作。 Azure 檔案同步會將 ACL 儲存在 Azure 檔案共用中的檔案,並將其複寫至所有伺服器端點。

即使直接對 Azure 檔案共用所做的變更需要更長時間才能同步至同步群組中的伺服器端點,您可能仍想要確保您也可以在雲端直接對您的檔案共用強制執行 AD 權限。 若要這樣做,您必須使用網域將儲存體帳戶加入至您的內部部署 AD,就像 Windows 檔案伺服器加入網域的方式一樣。 若要深入了解如何使用網域將您的儲存體帳戶加入至客戶所擁有的 Active Directory,請參閱 Azure 檔案儲存體 Active Directory 概觀

重要

不需要使用網域將您的儲存體帳戶加入至 Active Directory,即可成功部署 Azure 檔案同步。這是一個嚴格的選擇性步驟,可讓 Azure 檔案共用在使用者直接裝載 Azure 檔案共用時,強制執行內部部署 ACL。

網路功能

Azure 檔案同步代理程式會使用 Azure 檔案同步 REST 通訊協定和 FileREST 通訊協定,與您的儲存體同步服務和 Azure 檔案共用進行通訊,而這兩個通訊協定一律使用經由連接埠 443 的 HTTPS。 SMB 永遠不會用來在您的 Windows Server 與 Azure 檔案共用之間上傳或下載資料。 由於大部分的組織允許經由連接埠 443 的 HTTPS 流量,因此若要造訪大部分的網站,通常不需要特殊的網路組態,就能部署 Azure 檔案同步。

根據組織的原則或獨特的法規需求,您與 Azure 的通訊可能需要受到更多約束,因此 Azure 檔案共用提供了數種機制,供您設定網路功能。 根據您的需求,您可以:

  • 透過 ExpressRoute 或 Azure VPN 進行通道同步和檔案上傳/下載流量。
  • 利用 Azure 檔案儲存體和 Azure 網路功能,例如服務端點和私人端點。
  • 設定 Azure 檔案同步,以在您的環境中支援您的 Proxy。
  • 節流來自 Azure 檔案同步的網路活動。

重要

Azure 檔案同步不支援網際網路路由。 Azure 檔案同步支援預設的網路路由選項 [Microsoft 路由]。

若要深入瞭解 Azure 檔案同步和網路功能,請參閱 Azure 檔案同步網路功能考慮

加密

使用 Azure 檔案同步時,需要考慮三個不同層級的加密:在 Windows Server 的待用儲存體加密、在 Azure 檔案同步代理程式與 Azure 之間的傳輸中加密,以及在 Azure 檔案共用中資料的待用加密。

Windows Server 待用加密

有兩種策略通常會使用 Azure 檔案同步,在 Windows Server 上加密資料:檔案系統底下的加密,讓檔案系統及寫入其中的所有資料都會進行加密,以及檔案格式本身內的加密。 這些方法並不互斥;如有需要,您可以將它們搭配使用,因為加密的目的不同。

為了在檔案系統底下提供加密,Windows Server 提供 BitLocker 收件匣。 BitLocker 對於 Azure 檔案同步而言完全透明。使用 BitLocker 這類加密機制的主要原因,是為了防止有人竊取磁碟,實際洩漏內部部署資料中心的資料,以及防止側載未授權的作業系統來執行未授權的讀取/寫入。 若要深入了解 BitLocker,請參閱 BitLocker 概觀

與 BitLocker 作用類似的第三方產品,由於位於 NTFS 磁碟區下方,應該也能以完全透明的方式使用 Azure 檔案同步。

另一個用於加密資料的主要方法,就是在應用程式儲存檔案時,加密檔案的資料流。 某些應用程式可能會以原生方式執行此動作,但通常不會發生這種情況。 加密檔案資料流的方法範例是 Azure 資訊保護 (AIP)/Azure Rights Management Services (Azure RMS)/Active Directory RMS。 使用加密機制 (例如 AIP/RMS) 的主要原因,是要防止有人將資料從檔案共用複製到其他位置 (例如快閃磁碟機),或透過電子郵件傳送給未授權人員,而將資料洩漏出去。 當檔案的資料流已加密為檔案格式的一部分時,此檔案會繼續在 Azure 檔案共用上加密。

Azure 檔案同步無法與 NTFS 加密檔案系統 (NTFS EFS) 或位於檔案系統上但在檔案資料流下的第三方加密解決方案交互操作。

傳輸中加密

注意

Azure 檔案同步服務將於 2020 年 8 月 1 日移除 TLS 1.0 和 1.1 的支援。 根據預設,所有支援的 Azure 檔案同步代理程式版本都已使用 TLS 1.2。 如果您的伺服器上已停用 TLS 1.2 或使用 Proxy,則可能會發生使用舊版 TLS 的情況。 如果您使用 Proxy,建議您檢查 Proxy 組態。 5/1/2020 之後新增的 Azure 檔案同步服務區域僅會支援 TLS 1.2,而且將會在 2020 年 8 月 1 日從現有區域中移除 TLS 1.0 和 1.1 的支援。 如需詳細資訊,請參閱疑難排解指南

Azure 檔案同步代理程式會使用 Azure 檔案同步 REST 通訊協定和 FileREST 通訊協定,與您的儲存體同步服務和 Azure 檔案共用進行通訊,而這兩個通訊協定一律使用經由連接埠 443 的 HTTPS。 Azure 檔案同步不會透過 HTTP 傳送未加密的要求。

Azure 儲存體帳戶包含一個需要傳輸中加密 (預設為啟用) 的切換。 即使已停用儲存體帳戶層級的切換,這表示有可能以未加密的方式連線至 Azure 檔案共用,但 Azure 檔案同步仍然只會使用加密通道來存取您的檔案共用。

停用儲存體帳戶傳輸中加密的主要原因,是為了支援必須在舊版作業系統上執行的繼承應用程式,例如 Windows Server 2008 R2 或舊版 Linux 散發套件,直接與 Azure 檔案共用交談。 如果繼承應用程式與檔案共用的 Windows Server 快取交談,切換此設定將不會有任何作用。

我們強烈建議您確保傳輸中資料加密已啟用。

如需傳輸中加密的詳細資訊,請參閱在 Azure 儲存體中需要安全傳輸

Azure 檔案共用的待用加密

使用 Azure 儲存體服務加密 (SSE) 將儲存在 Azure 檔案儲存體中的所有資料進行待用加密。 儲存體服務加密的運作方式與 Windows 上的 BitLocker 相似:資料會在檔案系統層級下加密。 由於資料是在 Azure 檔案共用的檔案系統下加密,因此當其編碼為磁碟時,不需要存取用戶端上的基礎金鑰,即可讀取或寫入 Azure 檔案共用。 待用加密同時適用於 SMB 和 NFS 通訊協定。

根據預設,儲存於 Azure 檔案儲存體中的資料是以使用 Microsoft 管理的金鑰加密。 使用 Microsoft 管理的金鑰時,Microsoft 會保存金鑰來加密/解密資料,並負責定期輪替。 您也可以選擇管理自己的金鑰,這可讓您控制輪替的程序。 如果您選擇使用客戶管理的金鑰來對檔案共用進行加密,則 Azure 檔案儲存體會獲授權存取您的金鑰,以滿足用戶端的讀取和寫入要求。 使用客戶管理的金鑰時,可以隨時撤銷此授權,但這表示您的 Azure 檔案共用將無法再透過 SMB 或 FileREST API 來進行存取。

Azure 檔案儲存體使用與其他 Azure 儲存體服務 (例如 Azure Blob 儲存體) 相同的加密配置。 如需深入了解 Azure 儲存體服務加密 (SSE) 的詳細資訊,請參閱待用資料的 Azure 儲存體加密

儲存層

Azure 檔案儲存體提供了四種不同的儲存體,分別是進階、交易最佳化、經常性存取和非經常性存取,使您可以根據案例的效能和價格需求來量身打造檔案共用:

  • 進階:進階檔案共用是由固態硬碟 (SSD) 支援,並提供持續高效能和低延遲,能在毫秒內處理多數的 IO 作業,適用於 IO 密集型工作負載。 進階檔案共用適合各種不同的工作負載,例如資料庫、網站託管以及開發環境等等。 進階檔案共用可以同時與伺服器訊息 (SMB) 和網路檔案系統 (NFS) 通訊協定搭配使用。
  • 交易最佳化:交易最佳化檔案共用可讓交易繁重的工作負載不需要進階檔案共用所提供的延遲功能。 在硬碟 (HDD) 支援的標準儲存體硬體上提供交易最佳化的檔案共用。 交易最佳化原本稱為「標準」層,不過這是指儲存體媒體類型,而不是存取層本身 (經常性存取和非經常性存取也是「標準」層,因其位於標準儲存硬體上)。
  • 經常性:經常性檔案共用可針對一般用途的檔案共用案例 (例如小組共用) 提供儲存體最佳化。 在 HDD 支援的標準儲存體硬體上提供經常性存取檔案共用。
  • 非經常性:非經常性檔案共用可針對線上封存儲存案例提供符合成本效益的儲存體最佳化。 在 HDD 支援的標準儲存體硬體上提供非經常性存取檔案共用。

進階檔案共用以 FileStorage 儲存體帳戶 類型進行部署,而且僅適用於已佈建的計費模型。 如需進階檔案共用佈建計費模型的詳細資訊,請參閱了解如何佈建進階檔案共用。 標準檔案共用 (包括交易最佳化、經常性存取和非經常性存取檔案共用) 以 一般用途版本 2 (GPv2) 儲存體帳戶 類型進行部署,並可透過「隨用隨付」計費來取得。

為您的工作負載選取儲存層時,請考慮效能和使用需求。 如果您的工作負載需要個位數的延遲,或者您正在使用 SSD 儲存體媒體內部部署,則進階層可能是最適合的。 如果低延遲不是最重要的考慮 (例如,從 Azure 裝載了內部部署的小組共用,或使用 Azure 檔案同步在內部部署環境中進行快取),則以成本的觀點來看,標準儲存體可能更適合。

在儲存體帳戶中建立檔案共用之後,就無法將其移至不同儲存體帳戶類型的專屬層中。 例如,若要將交易最佳化的檔案共用移至進階層,則必須在 FileStorage 儲存體帳戶中建立新的檔案共用,並將資料從原始共用複製到 FileStorage 帳戶中的新檔案共用。 我們建議使用 AzCopy 在 Azure 檔案共用之間複製資料,但是也可以使用 Windows 上的 robocopy 或 macOS 和 Linux 的 rsync 等工具進行複製。

部署在 GPv2 儲存體帳戶內的檔案共用可以在標準層 (交易最佳化、經常性存取和非經常性存取) 之間移動,而不需要建立新的儲存體帳戶和遷移資料,但是當變更層級時,將會產生交易成本。 將共用從較常存取層移至較少存取層時,會針對共用中的每個檔案產生較少存取層的寫入交易費用。 將共用從較少存取層移至較常存取層時,會針對共用中的每個檔案產生較少存取層的讀取交易費用。

如需詳細資訊,請參閱了解 Azure 檔案儲存體計費

區域可用性

具有 100 TiB 容量的標準檔案共用有特定限制。

  • 目前只支援本機備援儲存體 (LRS) 和區域備援儲存體 (GRS) 帳戶。
  • 一旦啟用大型檔案共用後,您就無法將儲存體帳戶轉換成異地備援儲存體 (GRS) 或異地區域備援儲存體 (GZRS) 帳戶。
  • 一旦啟用大型檔案共用,您就無法予以停用。

Azure 檔案共用的區域可用性

如需瞭解區域的可用性,請參閱 依區域提供的產品

下欄區域會要求您先要求 Azure 儲存體存取權,才能搭配使用 Azure 檔案同步:

  • 法國南部
  • 南非西部
  • 阿拉伯聯合大公國中部

若要要求這些區域的存取權,請依照 本檔中的程式操作。

備援性

為了保護 Azure 檔案共用中的資料,避免資料遺失或損毀,所有 Azure 檔案共用都會在寫入時儲存每個檔案的多個複本。 視工作負載的需求而定,您可以選取額外的備援程度。 Azure 檔案儲存體目前支援下列資料備援選項:

  • 本機冗余儲存體 (LRS):使用 LRS,每個檔案都會在 Azure 儲存體叢集中儲存三次。 這可防止因為硬體錯誤 (例如磁碟機損壞) 而遺失資料。 但是,若在資料中心內發生火災或洪水之類的災害,則所有使用 LRS 的儲存體帳戶複本可能都會遺失或無法復原。
  • 區域冗余儲存體 (ZRS):使用 ZRS,每個儲存的檔案都會有三個複本,不過這些複本實際上是隔離在不同 Azure 可用性區域 中的三個不同儲存體叢集中。 可用性區域是 Azure 地區內獨特的實體位置。 每個區域都是由一或多個資料中心組成,配備了獨立的電源、冷卻和網路功能。 直到寫入所有三個可用性區域中的儲存體叢集後,才會接受對儲存體的寫入。
  • 異地複寫儲存體 (GRS):有了 GRS,您有兩個區域,也就是主要和次要區域。 檔案會在主要區域的 Azure 儲存體叢集中儲存三次。 寫入會以非同步方式複寫到 Microsoft 定義的次要區域。 GRS 可在兩個 Azure 區域之間提供六個數據複本。 如果發生嚴重損壞,例如因為自然災害或其他類似事件而導致 Azure 區域永久遺失,Microsoft 將會執行容錯移轉,而次要複本會變成主要,以提供所有作業。 由於主要與次要區域之間的複寫是非同步的,在嚴重損壞的情況下,尚未複寫到次要區域的資料將會遺失。 您也可以執行異地備援儲存體帳戶的手動容錯移轉。
  • 異地區域-多餘儲存體 (GZRS):您可以將 GZRS 視為像是 ZRS,但使用異地冗余。 使用 GZRS 時,檔案會在主要區域中的三個不同儲存體叢集之間儲存三次。 接著,所有寫入都會以非同步方式複寫到 Microsoft 定義的次要區域。 GZRS 的容錯移轉程式運作方式與 GRS 相同。

標準 Azure 檔案共用最多可支援四個冗余類型,最多5個 TiB。 大於 5 TiB 的標準檔案共用僅支援 LRS 和 ZRS。 進階版Azure 檔案共用只支援 LRS 和 ZRS。

一般用途版本 2 (GPv2) 儲存體帳戶提供 Azure 檔案儲存體不支援的兩個額外備援選項:可讀取的異地備援儲存體 (通常稱為 RA-GRS),以及可讀取的異地區域備援儲存體 (通常稱為 RA-GZRS)。 您可以在已設定這些選項的儲存體帳戶中佈建 Azure 檔案共用,不過 Azure 檔案儲存體不支援從次要區域讀取。 部署到可讀取異地或異地區域備援儲存體帳戶中的 Azure 檔案共用,將會分別以異地備援或異地區域備援儲存體的形式計費。

重要

異地備援和異地區域備援儲存體可讓您將儲存體手動容錯移轉至次要區域。 當您使用 Azure 檔案同步時,我們建議您不要在災害外部執行此動作,因為這會提高資料遺失的可能性。 如果您想要在發生災害時起始儲存體的手動容錯移轉,您必須向 Microsoft 開啟支援案例,讓 Azure 檔案同步繼續與次要端點同步。

遷移

如果您有現有的 Windows 檔案伺服器2012R2 或更新版本,可以直接安裝 Azure 檔案同步,而不需要將資料移到新的伺服器。 如果您打算在採用 Azure 檔案同步的過程中遷移至新的 Windows 檔案伺服器,或您的資料目前位於連接的網路上儲存體 (NAS) 有幾種可能的遷移方法可搭配此資料使用 Azure 檔案同步。 您應該選擇哪一個遷移方法,取決於您的資料目前所在的位置。

查看 Azure 檔案同步和 Azure 檔案共用的遷移總覽 文章,您可以在其中找到案例的詳細指導方針。

防毒

由於防毒軟體的運作方式是掃描檔案中的已知惡意程式碼,因此,防毒軟體可能會導致重新叫用階層式檔案,因而產生高輸出費用。 在 4.0 版和更新版本的 Azure 檔案同步代理程式中,階層式檔案已設定安全的 Windows 屬性 FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS。 建議您洽詢您的軟體廠商,以了解如何設定其解決方案來略過讀取已設定此屬性的檔案 (很多軟體會自動這麼做)。

作為 Microsoft 內部防毒解決方案的 Windows Defender 和 System Center Endpoint Protection (SCEP),皆會自動略過讀取已設定此屬性的檔案。 我們已經測試這兩個解決方案並找到一個小問題:當您將伺服器新增至現有同步群組時,會在新的伺服器上重新叫用 (下載) 小於 800 個位元組的檔案。 這些檔案會保留在新的伺服器上,而且不會分層,因為這些檔案不符合階層處理大小需求 (> 64 kb)。

注意

防毒軟體廠商可以使用 Azure 檔案同步防毒相容性測試套件 (可從 Microsoft 下載中心下載),檢查其產品與 Azure 檔案同步之間的相容性。

Backup

如果已啟用雲端階層處理,則不應使用直接備份伺服器端點的解決方案,或不應使用伺服器端點所在的 VM。 雲端階層處理只會在伺服器端點上儲存您的資料子集,並將完整資料集放在您的 Azure 檔案共用中。 視所使用的備份解決方案而定,階層式檔案將會略過,而且不會備份 (因為它們已設定 FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS 屬性) ,或會將它們重新叫用到磁片,因而產生高輸出費用。 我們建議使用雲端備份解決方案來直接備份 Azure 檔案共用。 如需詳細資訊,請參閱 關於 azure 檔案共用備份 ,或洽詢您的備份提供者,查看是否支援備份 Azure 檔案共用。

如果您想要使用內部部署備份解決方案,應該在已停用雲端階層處理的同步處理群組中的伺服器上執行備份。 執行還原時,請使用磁碟區層級或檔案層級的還原選項。 使用檔案層級還原選項進行還原的檔案會同步至同步群組中的所有端點,並使用從備份還原過來的版本取代現有檔案。 磁碟區層級還原將不會取代 Azure 檔案共用或其他伺服器端點中的較新檔案版本。

警告

如果您需要使用 Robocopy/B 搭配在來源或目標伺服器上執行的 Azure 檔案同步代理程式,請升級為 Azure 檔案同步代理程式版本12.0 版或更新版本。 使用 Robocopy/B 搭配小於12.0 的代理程式版本,會導致複製期間的分層檔案損毀。

注意

裸機 (BMR) 還原可能會導致非預期的結果,且目前不受支援。

注意

搭配第 9 版的 Azure 檔案同步代理程式,已啟用雲端階層處理的磁碟區現在支援 VSS 快照集 (包括 [舊版] 索引標籤)。 不過,您必須透過 PowerShell 啟用舊版相容性。 了解作法

資料分類

如果您已安裝資料分類軟體,啟用雲端階層處理可能會因為下列兩個原因而導致增加成本:

  1. 在啟用雲端階層處理的情況下,您最熱門的檔案會在本機快取,而最酷檔案則會分層到雲端中的 Azure 檔案共用。 如果您的資料分類會定期掃描檔案共用中的所有檔案,則必須在每次掃描時重新叫用分層到雲端的檔案。

  2. 如果資料分類軟體使用檔案資料流程中的中繼資料,則必須完全重新叫用檔案,軟體才能看到分類。

這會增加重新叫用數目和回收的資料量,進而增加成本。

Azure 檔案同步代理程式更新原則

Azure 檔案同步代理程式會定期更新,以新增功能和解決問題。 建議您設定 Microsoft Update,以取得 Azure 檔案同步代理程式的最新更新。

主要與次要代理程式版本

  • 主要代理程式版本通常會包含新功能,且會使用遞增的數字作為版本號碼的第一個部分。 例如:*2.*.**
  • 次要代理程式版本也稱為「修補」,且會比主要版本更常發行。 它們通常包含錯誤修正和小幅改善,但是沒有任何新功能。 例如:**.3.**

升級路徑

有四個經核准及測試的方式可用來安裝 Azure 檔案同步代理程式更新。

  1. (慣用) 設定 Microsoft Update,以自動下載並安裝代理程式更新。
    建議一律採用每個 Azure 檔案同步更新,以確保您可存取伺服器代理程式的最新修正程式。 Microsoft Update 會為您自動下載和安裝更新,讓這個程序順暢進行。
  2. 使用 AfsUpdater.exe 下載並安裝代理程式更新。
    AfsUpdater.exe 位於代理程式安裝目錄中。 按兩下可執行檔,即可下載並安裝代理程式的更新。
  3. 使用 Microsoft Update 修補檔或 .msp 可執行檔,修補現有的 Azure 檔案同步代理程式。您可以從 Microsoft Update 類別目錄下載最新的 Azure 檔案同步更新套件。
    執行 .msp 可執行檔將會使用與 Microsoft Update 在先前升級路徑中自動使用的相同方法,來升級 Azure 檔案同步安裝。 套用 Microsoft Update 修補程式將會執行 Azure 檔案同步安裝的就地升級。
  4. 請從 Microsoft 下載中心下載最新的 Azure 檔案同步代理程式安裝程式。
    若要升級現有的 Azure 檔案同步代理程式安裝,請將舊版解除安裝,然後從所下載的安裝程式安裝最新版本。 Azure 檔案同步安裝程式會維護伺服器註冊、同步群組和任何其他設定。

自動代理程式生命週期管理

在代理程式第6版中,檔案同步小組引進了代理程式自動升級功能。 您可以選取兩種模式的其中一種,並指定要在伺服器上嘗試升級的維護視窗。 這項功能的設計目的是為了協助您進行代理程式生命週期管理,方法是提供 guardrail,讓您的代理程式無法過期或不需要保持最新的設定。

  1. 預設設定 會嘗試防止代理程式到期。 在代理程式張貼到期日的21天內,代理程式會嘗試自我升級。 它會在到期前的21天內,以及在選取的維護時段開始嘗試升級一次。 此選項不會消除定期 Microsoft Update 修補程式的需求。
  2. (選擇性)您可以選擇在新的代理程式版本可用 (目前不適用於) 的叢集伺服器時,代理程式會自動升級本身。 這項更新會在選取的維護期間發生,並可讓您的伺服器在新功能正式推出後立即受益于這些新功能和增強功能。 這是建議的無煩惱設定,可提供主要的代理程式版本,以及伺服器的定期更新修補程式。 每個發行的代理程式都是 GA 品質。 如果您選取此選項,Microsoft 會將最新的代理程式版本傳送給您。 排除叢集伺服器。 試驗完成後,代理程式也將可在 Microsoft 下載中心 aka.ms/AFS/agent 取得。
變更自動升級設定

下列指示說明如何在您完成安裝程式之後變更設定(如果您需要進行變更)。

開啟 PowerShell 主控台並流覽至您安裝同步代理程式的目錄,然後匯入伺服器 Cmdlet。 根據預設,這會看起來像這樣:

cd 'C:\Program Files\Azure\StorageSyncAgent'
Import-Module -Name .\StorageSync.Management.ServerCmdlets.dll

您可以執行 Get-StorageSyncAgentAutoUpdatePolicy 以檢查目前的原則設定,並判斷是否要變更它。

若要將目前的原則設定變更為延遲的更新追蹤,您可以使用:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration

若要將目前的原則設定變更為立即更新追蹤,您可以使用:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest

代理程式生命週期和變更管理保證

Azure 檔案同步是一項雲端服務,持續推出新功能和增強功能。 這表示特定的 Azure 檔案同步代理程式版本只會支援一段有限的時間。 為了加速您的部署,下列規則保證您有足夠的時間和通知,可在您的變更管理程式中容納代理程式更新/升級:

  • 主要代理程式版本從初始發行日期算起會獲得至少六個月的支援。
  • 我們保證主要代理程式版本之間的支援至少有三個月的重疊。
  • 系統會在到期至少三個月之前,使用即將到期代理程式向已註冊的伺服器發出警告。 您可以在儲存體同步服務的已註冊伺服器區段之下,檢查已註冊的伺服器是否使用舊版的代理程式。
  • 次要代理程式版本的存留期會繫結至相關聯的主要版本。 例如,當代理程式 3.0 版發行時,代理程式 2.* 版全都會設定為一起過期。

注意

安裝具有到期警告的代理程式版本時會顯示警告,但仍會成功。 不支援嘗試安裝或與已過期的代理程式版本連線,而且會加以封鎖。

後續步驟