AFX 概述 9191 草稿
建議變更
PDF
創新演進： NetApp ONTAP
NetApp ONTAP 誕生於 1992 年，旨在為多個客戶端提供 NFS 工作負載服務，同時革新效能、資料彈性、時間點複本等諸多面向。它最初僅支援 NFSv2，但隨著對更新的 NFS 版本、其他資料協定以及更多資料保護功能的需求不斷增長，NetApp ONTAP 必須隨之發展。
以下是 ONTAP 在過去 30 多年中發生的一些重大演變的簡要時間線。
| 十年 | 功能 |
|---|---|
1990s |
NFSv2、NFSv3、CIFS、Snapshot、WAFL 檔案系統、AutoSupport、SnapMirror |
2000s |
SnapVault、SnapLock、NFSv4、區塊協議、FlexVols、FlexClone、GX/ 橫向擴展、重複資料刪除、檔案複本 |
2010s |
叢集式 ONTAP、內嵌儲存效率、NFSv4.1/pNFS、NVMe、RAID-TEC、FlexGroup Volume、Volume 加密、AFF、Cloud Volumes ONTAP、QoS、FabricPool、Azure NetApp Files（ANF）、Google Cloud NetApp Volumes（GCNV）、All SAN Array（ASA） |
2020s |
SnapMirror 業務連續性、FlexCache、ONTAP S3、IPsec、自主勒索軟體防護、SnapMirror 進出 ANF 和 GCNV、Amazon FSxN、ASAr2、NetApp AFX 您在這裡 |
NetApp ONTAP 特性
多年來， ONTAP 一直作為一個統一的平台運行，將檔案、區塊和物件整合到一個系統中。這使得 ONTAP 成為資料中心的瑞士軍刀——一個可以完成您要求的任何任務的平台。
然而，隨著應用程式的演進和資料中心需求的變化，以及 IT 產業的一系列變革，對能夠執行特定任務的平台的需求日益增長。因此，現在有幾種不同的方式可以使用 ONTAP。
| ONTAP 特性 | 說明 |
|---|---|
統一 ONTAP |
還是您一直熟悉的 ONTAP，並且仍在積極開發和改進中。 |
所有 SAN 陣列 |
ONTAP 僅支援 iSCSI、FCP 和 NVMe over FC/TCP，並提供主動 / 主動控制器功能，以及 ASAr2 中的解耦概念。 |
雲端常駐 ONTAP |
在雲端運作的 ONTAP；可以是位於雲端資料中心的裸機系統，也可以是虛擬化的 ONTAP 執行個體。 |
分散式 ONTAP/AFX |
ONTAP 採用分解式架構，適用於高效能 NAS 和物件工作負載。 |
統一 ONTAP 架構概述
下圖展示了統一 ONTAP 的整體架構，並在其下方描述了各個部分是如何組合在一起的。
ONTAP 架構的一些關鍵面向：
-
檔案、物件和區塊支援
-
傳輸協定透過前端用戶端資料網路提供服務
-
多個獨立節點可以叢集在一起
-
每個節點都可以為資料和管理使用案例提供獨立的浮動 IP 位址
-
叢集節點透過叢集 VLAN 連接到 NetApp 提供的後端交換器。
-
節點以 HA 配對的形式呈現，以便在硬體或電源故障時提供恢復能力
-
HA 配對具有直接連接的 NVRAM 卡，可進行複寫以保護寫入作業
-
每個節點至少被分配一個 Aggregate，並擁有磁碟總數的一部分。
-
在故障轉移過程中，節點的磁碟會被重新指派給 HA 合作夥伴（且僅指派給 HA 合作夥伴）
-
磁碟櫃通常透過多路徑佈線直接連接到節點，但高階系統引入了在同一後端叢集交換器上建置儲存網路的概念
-
磁碟區（FlexVols 和 FlexGroup 磁碟區）為資料存取提供儲存的入口點
什麼是 NetApp AFX？
這裡要記住的一點是， NetApp AFX 仍然是 ONTAP 。
這只是利用 ONTAP 優勢的另一種方式。您為 Unified ONTAP 或 All SAN Array 系統安裝的映像與 NetApp AFX 使用的映像相同。程式碼庫完全一致，但系統的啟動方式決定了執行的程式碼路徑、後端儲存的呈現方式以及支援的功能和協定。
NetApp AFX 為 NAS 和物件工作負載提供解耦架構，同時保留了您熟悉且喜愛的豐富功能的 ONTAP 軟體。解耦 ONTAP 指的是一種儲存架構，其中每個 NetApp 控制器節點透過冗餘網路交換器和高速低延遲網路存取相同的容量。這種方法允許控制器節點和儲存容量彼此獨立擴展，從而更精準地滿足各種高效能工作負載的需求。換句話說，當您需要更高的效能時，只需添加控制器節點。如果您需要更多容量，請添加機櫃機箱。這使儲存管理員能夠靈活地為最終使用者提供更具成本效益的儲存解決方案。
由於沒有哪個控制器節點獨立擁有磁碟，因此也不存在具有自身容量和效能限制的實體 Aggregate 。相反，容量以共享模式呈現，所有節點都可以與之互動，而 ONTAP 可以自動管理。
關鍵術語和概念
以下術語與 AFX 直接相關。有關 ONTAP 的特定術語，請參閱產品文件。
分散式 ONTAP
指的是基於 ONTAP 的全新架構，該架構能夠獨立擴展運算能力和容量。「解耦式 ONTAP」並非產品名稱，而是用來區分統一 ONTAP 和 NetApp AFX 架構的一種方式。
NetApp AFX
NetApp AFX 是分離式 ONTAP 架構的正式產品名稱，並已於 NetApp Insight 2025 發布。
運算節點
在 NetApp AFX 中，運算節點指的是儲存控制器節點（在文件中經常可以互換使用）。這些節點沒有板載磁碟，並且採用完全模組化設計，以實現 ONTAP 解耦架構所提供的獨立擴展能力。
儲存可用區
儲存可用區 (SAZ) 是 NetApp AFX 叢集中的單一容量池，其中所有磁碟都在所有節點之間共用。SAZ 支援共享容量、增強效能、全域重複資料刪除等功能。
NetApp AFX 架構與統一 ONTAP 有何不同
上文概述了統一 ONTAP 架構如何透過直接連接的高可用性（HA）對提供檔案、物件和區塊資料儲存，這些 HA 對各自擁有獨立的磁碟組，並透過磁碟聚合來呈現實體容量。本節將更詳細地討論統一 ONTAP 和 NetApp AFX 架構之間的一些主要差異。
如何判斷系統是否運作 NetApp AFX
查看系統是否運行 NetApp AFX 的主要方法是執行以下命令：
AFX::> node show -fields personality node personality ---------------- ----------- afx-01 AFX afx-02 AFX
另一個線索是新的 Storage Availability Zone，但 NetApp All-SAN Arrays (ASA) 也支援這個概念。您可以透過該命令查看容量。
AFX::> storage availability-zone show
Availability Zone Name: storage_availability_zone_0
Availability Zone UUID: 545cb59f-32e9-11f1-a2f5-d039eabdd925
Total Size: 69.59TB
Physical Used: 837.1GB
Physical Used Percent: 1%
Available: 68.77TB
Metadata Used: 837.1GB
Log and Recovery Metadata: 834.6GB
Delayed Frees: 2.50GB
Physical User Data Without Snapshot Copies: 17.24MB
Logical User Data Without Snapshot Copies: 17.24MB
Efficiency Ratio Without Snapshot Copies: 1.00:1
Space Full Threshold Percent: 98%
Space Nearly Full Threshold Percent: 95%
節點到磁碟的關係
在統一的 ONTAP 架構中，讀寫操作會被導向到特定的磁碟子集。因此，即使在 24 節點叢集中擁有 24 個磁碟架（每個節點一個磁碟架），在任何給定時間，每個節點也只能直接存取一個磁碟架，這限制了叢集的容量和效能。
此外，由於 NVRAM 在 HA 配對之間直接連接，節點必須實際位於彼此相鄰的位置，並且作為容錯移轉目標時耦合性更強。例如，當一個節點容錯移轉到其合作夥伴節點時，它實際能夠存取的唯一磁碟就是 HA 配對網域中的磁碟。
在 NetApp AFX 中，磁碟呈現給運算節點的方式發生了一些重大變化。
所有儲存節點均可看到所有磁碟 — 不存在磁碟所有權歸屬問題。
在 NetApp AFX 中，節點和機架都連接到同一個後端交換器，這使得 ONTAP 可以將磁碟的整體可見性網域擴展到整個堆疊。因此，沒有節點擁有任何特定的磁碟。相反地，所有磁碟都參與單一容量資源池，稱為 Storage Availability Zone （儲存可用性區域），可提供更簡單的容量管理和更高的效能潛力（更多可用磁碟意味著更多可用效能）。
不再有實體 Aggregate
Unified ONTAP 將磁碟分組到 RAID 群組中，然後將它們組合成一個稱為 Aggregate 的容量結構。此 Aggregate 用於向儲存系統呈現實體容量，並決定了可用於建立磁碟區以服務最終使用者資料的空間邊界。每個節點必須至少分配一個 Aggregate，這些 Aggregate 的當前容量上限為 800TB。一旦達到此上限，將沒有更多空間用於寫入操作。
實體 Aggregate 也可能帶來一些容量管理方面的挑戰，因為儲存管理員有時需要手動調整 Volume 的位置，以保持叢集節點間的容量平衡。當採用橫向擴展 Volume 架構（例如 FlexGroup Volume）時，這些挑戰會更加突出。Aggregate 的大小、磁碟數量、磁碟類型等也可能存在差異，這會導致在存取不同節點時出現效能差異。
NetApp AFX 將實體 Aggregate 的概念虛擬化，使其由 ONTAP 管理，然後透過新的 Storage Availability Zone 將實體容量管理從每個節點的方法轉變為每個叢集的方法。這種單一的容量池為空間管理提供了「所見即所得」的方法。
NVRAM 從直接連線遷移到交換複寫
ONTAP 使用 NVRAM 作為暫存區，以保護傳入叢集的寫入作業。ONTAP 叢集中的每個節點都配備一塊帶電池備援的 NVRAM 卡。當客戶端向磁碟區發送寫入作業時，資料會先儲存在 NVRAM 中。當 NVRAM 被填滿或 10 秒定時器逾時（以先到者為準）時，NVRAM 的內容會被刷新到磁碟。這被稱為一致性點。
NVRAM 內容也會在 HA 對之間不斷複製，這進一步有助於保護資料一致性，因為如果節點發生故障，NVRAM 內容將保留在倖存的節點上並提交到磁碟。
在統一的 ONTAP 叢集中，HA 配對之間的 NVRAM 卡直接相互連接。NetApp AFX 將 NVRAM 複寫移至後端叢集網路。因此，HA 合作夥伴節點對於節點沒有如此嚴格的距離要求。相反地，HA 配對可以分隔到乙太網路的最大距離。
寫入可用區域中任何 ( 和所有 ) 磁碟的資料
NetApp AFX 移除了磁碟擁有權的概念，並將實體集合體的架構轉變為由 ONTAP 管理的虛擬化方式，讓為叢集購買的所有容量都可供連接至該叢集的節點使用。使用 AFX 時，所有節點都能寫入儲存可用性區域中的任何磁碟，無論節點：磁碟區擁有權為何。節點仍然有磁碟區擁有權的概念，因為寫入仍需經過 NVRAM，但該資料可以儲存在任何可用容量中。這表示可以有更多磁碟參與單一工作負載，進而帶來效能上的優勢。
獨立擴充容量和運算節點
在 NetApp AFX 架構中，硬體資源實作了解耦，節點不再需要同時新增關聯的磁碟。當叢集的效能相關資源（例如 RAM、CPU 或網路吞吐量）不足時，只需在叢集中新增儲存節點，即可利用現有的儲存可用區。反之，如果需要的是容量，則只需添加儲存架即可。這種靈活性確保您只購買所需的資源，從而避免過度配置。
節點效能的線性擴充
隨著節點加入 AFF 叢集，工作負載將獲得更多的 CPU、RAM 和網路資源。隨著這些資源納入環境中，效能提升呈線性成長。下圖顯示隨著節點增加，效能如何提升。
更大的 RAID 群組、更少的同位磁碟機
ONTAP 透過 RAID 群組（特別是 RAID-TEC）為磁碟提供資料保護和效能的雙重保障。RAID-TEC 可在磁碟發生故障時提供三重同位元檢查保護。即使 RAID 群組中同時發生三個磁碟機故障，RAID-TEC 也能確保資料安全。在統一的 ONTAP 中，RAID 群組最多可容納 28 個磁碟，其中 3 個磁碟機用於同位元檢查，1 個磁碟機用作備用磁碟機。因此，28 個磁碟機中有 24 個用於資料操作 / RAID 條帶化。
NetApp AFX 仍然採用 RAID-TEC 技術，但將 RAID 群組的大小增加到 96 個硬碟，而只需要 3 個奇偶校驗盤和 1 個備用碟。更大的 RAID 群組可帶來更高的整體效能，同時，由於 SSD 的低故障率、在更大數量的硬碟上更均勻地分配操作，以及 NetApp AFX 中從奇偶校驗盤重建資料碟的改進，硬碟故障帶來的風險也降至最低。
下表近似表示統一 ONTAP 和 NetApp AFX 系統中 84 個磁碟在不同磁碟機容量下可用的原始容量。
| 磁碟機大小 | 近似原始容量（統一） | 近似原始容量（AFX） |
|---|---|---|
7.6 TB |
約 547.2TB |
約 608TB（+60.8TB） |
15.3 TB |
~1101.6TB |
約 1224TB (+122.4TB) |
30.6 TB |
約 2203.2TB |
約 2448TB（+244.7TB） |
60.1 TB |
約 4327.2TB |
約 4808TB（+480.8TB） |
更快的磁碟故障重建時間
在統一的 ONTAP 中，每個節點擁有儲存堆疊中的一部分磁碟。這意味著該節點只能寫入這些磁碟，而且在磁碟發生故障時，磁碟重建也僅由單一節點處理。
NetApp AFX 無需磁碟所有權。因此，如有需要，所有磁碟機都可以從單一節點寫入資料。這也意味著，當需要根據同位元檢查資訊重建磁碟機時，叢集中的所有節點都會參與，因此磁碟機重建速度比單一節點單獨執行要快得多。
重複資料刪除網域
重複資料刪除允許儲存系統在其檔案系統中尋找重複區塊，然後建立指向單一區塊的指標，以減少已使用容量的總量。在統一的 ONTAP 中，重複資料刪除遵循特定的邊界來決定哪些區塊可以被刪減。這些邊界取決於所使用的重複資料刪除類型。一般來說：
-
基於 Volume 的重複資料刪除 → Volume 邊界
-
跨磁碟區重複資料刪除 → Aggregate 邊界
下表顯示了統一 ONTAP 中不同場景下重複資料的容量變化。由於檔案副本跨越節點和 aggregate（從而跨越重複資料刪除網域），因此節省的空間會減少。
| 情境 | 已使用空間 |
|---|---|
同一磁碟區中四個相同的 10GB 檔案副本（磁碟區重複資料刪除） |
10 GB |
同一個 10GB 檔案的四個副本、不同的磁碟區、相同的 Aggregate（已啟用跨磁碟區重複資料刪除） |
10 GB |
同一個 10GB 檔案的四個副本，分別位於 4 個不同的磁碟區、4 個不同的 Aggregate（已啟用跨磁碟區重複資料刪除） |
40 GB |
由於 NetApp AFX 移除了實體聚合並將容量管理遷移到新的儲存可用區，重複資料刪除域的邊界也隨之改變。在 AFX 中，重複資料刪除域位於磁碟區層級（類似於統一 ONTAP）和節點層級（而非聚合層級），這是在 9.19.1 版本之前的情況。
從 ONTAP 9.19.1 開始，AFX 支援儲存可用區層級的全域重複資料刪除網域，因此叢集儲存資源池中的所有重複區塊都以相同的方式處理。
下表顯示 NetApp AFX 中不同案例下重複資料的容量行為。
| 情境 | 已使用空間 |
|---|---|
同一磁碟區中四個相同的 10GB 檔案副本（磁碟區重複資料刪除） |
10GB（9.18.1）10GB（9.19.1） |
同一 10GB 檔案的四個副本，位於不同的磁碟區，同一節點（已啟用跨磁碟區重複資料刪除） |
10GB（9.18.1）10GB（9.19.1） |
同一個 10GB 檔案的四個副本，分別位於 4 個不同的磁碟區、4 個不同的節點上（已啟用跨磁碟區重複資料刪除） |
40GB（9.18.1）10GB（9.19.1） |
已移除/不再支援的功能
NetApp AFX 專為高效能 NAS 和物件工作負載而設計，特別適用於（但不限於）人工智慧訓練和推理領域。在 NetApp AFX 的設計過程中，我們決定停用 ONTAP 中的一些功能。
-
由於專注於高效能 NAS 和物件儲存，NetApp AFX 解決方案已移除區塊儲存工作負載。它不支援 FCP、iSCSI 或 NVMe 資料協定，並且沒有計劃添加區塊儲存協定。
-
Disaggregated 與 de-aggregated 同義,這表示 aggregate（至少在實體儲存管理概念上）已被移除。移除實體 aggregate 不僅簡化了 ONTAP 中的容量管理,也提供了實現單一容量池的機制。
-
移除 Aggregate 意味著 Aggregate 特定功能也會被移除。例如，MetroCluster 利用 Aggregate 層級的鏡射來實現站台容錯移轉功能。因此，MetroCluster 也已從 NetApp AFX 移除。站台容錯移轉功能將由 ONTAP 9.19.1GA 中提供的新 SnapMirror Active-Sync for NAS 功能提供。
-
名為 FabricPool 的冷資料分層功能目前也無法用於 NetApp AFX，因為它也是特定於 Aggregate 的。
-
由於採用了新的容量架構，NetApp AFX 中也不再需要基於複本的磁碟區移動。如需更多資訊，請參閱「零複本磁碟區移動」。
-
功能移除也意味著一些 CLI/GUI/REST API 的變更，因此任何不再支援的功能的命令或 API 呼叫也將被移除。
-
目前 NetApp AFX 無法使用 ZAPI。
-
用於虛擬化的 NFS 複製卸載（僅限具有精細資料分佈的 FlexGroup 磁碟區）
ONTAP 管理變更
整體而言，NetApp AFX 管理不會改變叢集的管理機制。管理員仍然可以利用 CLI、GUI 和 REST API 登入並配置叢集。但 NetApp AFX 確實提供了一個改善儲存管理操作方式的機會。
更簡化的容量管理
NetApp AFX 儲存可用區將管理端點從基於節點和 Aggregate 的方式簡化為整個叢集可用的單一容量資源池。隨著磁碟區的增長和收縮，ONTAP 會自動從儲存可用區借用和釋放容量。
因此，儲存管理員不再需要費心在多達 24 個節點和數百個 Aggregate 中尋找和管理可用空間。現在，只需在一個地方即可管理和檢視容量。
例如，在統一 ONTAP 的 CLI 中，如果您想查看叢集的總實體容量資訊，可以使用 “aggregate show-space，該命令會列印所有 Aggregate 項目。而在 NetApp AFX 中，您可以使用 “cluster space show，該指令只會顯示單一儲存可用區。
在 Unified ONTAP System Manager GUI 中，使用層級來顯示容量。實際上，GUI 會嘗試透過加總總數來顯示叢集的整體容量，但仍會以每個 Aggregate 為基礎顯示整體使用情況。
在 NetApp AFX System Manager 中，叢集空間的檢視幾乎相同，但由於沒有 Aggregate，因此無需進行額外的計算。您看到的容量就是您獲得的容量。
FlexGroup Volume 管理改進
FlexGroup 磁碟區由多個底層 FlexVol 組成磁碟區構成，這些底層組成磁碟區分佈在叢集中的多個節點和聚合中，並以單一大型命名空間的形式呈現給 NAS 用戶端。FlexGroup 磁碟區為高效能工作負載提供效能、擴充性、負載平衡和檔案數量的優勢。然而，由於磁碟區需要在節點和聚合之間進行協調，因此當容量開始飽和時，它們有時會遇到一些物理限制，因為聚合提供的獨立檔案系統也具有獨立的容量使用和限制。例如，如果包含 FlexGroup 磁碟區組成磁碟區的某個聚合在叢集中的其他聚合之前開始飽和，則整個 FlexGroup 本身可能會出現容量或效能問題。
因此，儲存管理員可能會過度擔心底層 FlexGroup 基礎架構，而忽略了維護環境的其他方面。
NetApp AFX 將容量集中在一個儲存可用區中，這更貼近 FlexGroup 磁碟區的預期運作方式。所有磁碟區都位於同一個容量池中，而不是分佈在多個大小可能不同的獨立 Aggregate 中的多個組成磁碟區，這大大簡化了使用 FlexGroup 磁碟區的整體管理開銷。
此外，AFX 預設會為 FlexGroup 磁碟區啟用進階容量平衡功能，有助於更妥善地在磁碟區中分配較大的檔案。現在，FlexGroup 磁碟區組成要素較不需要管理概念，而是在背景中靜靜地執行其工作。
自動化儲存管理任務
在 NetApp AFX 中使用 Storage Availability Zone 時，所有容量都會在所有節點之間共享。雖然節點仍擁有磁碟區，但 ONTAP 會根據每個節點在任何特定時間的需求，透過借用和釋放容量來自動管理每個節點的容量使用量。這意味著儲存管理員不再需要擔心如何以最佳方式平衡可用空間。
此外，ONTAP 可自動管理 RAID 群組，無需管理員幹預，即可將新新增的磁碟新增至現有或新建的 RAID 群組。ONTAP 還可跨節點管理磁碟區遷移，而無需複製資料。
零複本磁碟區移動
Unified ONTAP 提供了一種在節點或 Aggregate 之間無中斷地移動 Volume 的方法，以此來管理整個叢集的效能和容量使用情況。
當磁碟區移動開始時，會發生以下情況：
-
在指定的目標 Aggregate 上建立新的空磁碟區
-
Volume 中繼資料（例如儲存效率資訊、檔案控點等）會複寫到新的目的地 Volume
-
磁碟區資料透過 SnapMirror 技術經由後端叢集網路複製到目的地磁碟區，目的地 Aggregate 需要有可用的可用空間才能進行移動，否則移動工作將會失敗
-
磁碟區複寫會再次執行，以確保兩個磁碟區與任何資料變更保持一致
-
啟動切換流程，將來源磁碟區離線，並將目的地磁碟區升級為新的來源磁碟區供用戶端使用
-
用戶端 IO 在切換過程中會短暫暫停，但無需重新掛載
在 NetApp AFX 中，儲存可用區會將所有容量提供給所有節點，所有節點都可以寫入該儲存池中的任何磁碟。一旦資料放置完成，即使磁碟區被移動，資料也會保持在原位。這意味著無需複製資料。磁碟區移動程序與統一 ONTAP 相同，只是無需透過 SnapMirror 複製資料。不需要額外的容量。
輕量級的磁碟區遷移功能使 AFX 能夠自動執行許多管理任務，而不會受到效能或容量的限制。這些磁碟區遷移功能在 NetApp AFX 提供的一些新功能中已應用，如下文所述。
HA 故障轉移行為
在統一的 ONTAP 架構中，節點擁有磁碟和 Aggregate，資料透過 Volume 進行服務。寫入作業使用本機節點的 NVRAM 刷新到該節點擁有的磁碟。當節點重新啟動或發生故障時，ONTAP 將觸發故障節點資源的接管，將磁碟和 Aggregate 的所有權轉移給合作夥伴節點。網路介面也會故障轉移到 IP 位址空間中的連接埠。由於 NVRAM 內容在 HA 配對之間持續複寫，因此節點會刷新 NVRAM 內容，以提交故障節點寫入磁碟的資料。之後，倖存節點將擁有故障節點的 Aggregate 和 Volume，直到故障節點恢復正常。這意味著，所有流向這些 Volume（以及倖存節點已擁有的 Volume）的流量都將在單一節點上處理，直到故障轉移問題解決為止。
作為初始統一 ONTAP 叢集部署的一部分，建議事先規劃容錯移轉，以避免單一節點使其合作夥伴過載。這本身就是一個挑戰，因為很難預測哪些磁碟區可能會成為效能霸凌者，但諸如不中斷營運的磁碟區移動和磁碟區服務品質原則等功能可以協助緩解。
下圖顯示統一的 ONTAP 叢集如何在節點間造成效能不均衡，以及故障轉移在某些情況下如何導致效能下降。
當 HA 配對的節點在磁碟區數量和效能使用率方面變得不平衡時、節點容錯移轉會影響整體效能、因為存續的節點現在將擁有所有故障節點的磁碟區。同時、叢集中的其他節點可能有空間承擔額外的工作。
如上所示，當 HA 合作夥伴需要承擔額外任務時，可能會出現過載，並影響該節點上所有磁碟區的效能。磁碟區遷移可以緩解這種情況，但這需要在節點之間進行複製（需要可用空間），而且所需時間可能超過節點故障復原所需的時間。此外，如果您遷移磁碟區，它不會故障復原到原始節點。而是會保留在您遷移到的節點上。
使用 NetApp AFX 時，節點容錯移轉會表現出一些不同的行為。
-
由於節點不擁有磁碟，也沒有實體 Aggregate，因此節點容錯移轉不需要轉移這些資源。相反地，只有網路介面和 Volume 所有權會轉移到其他節點。
-
NVRAM 提交仍然會發生，但透過 HA 網路而不是直接連線進行。
-
磁碟區完成向夥伴節點的初始容錯移轉後，AFX 會將磁碟區重新分佈到叢集中的其他倖存節點上。這得歸功於零複製磁碟區移動技術。
-
當節點恢復後，磁碟區將移回原始節點。
NetApp AFX 已經維持叢集中各個節點的效能平衡，以保持相對均勻的使用率，因此當發生容錯移轉並重新平衡磁碟區時，叢集中的節點使用率應該大致相同。
節點新增和移除
統一的 ONTAP 和 NetApp AFX 都允許向叢集中新增和移除節點。但是，由於架構上的一些差異，節點新增和移除的過程略有不同。
在統一化 ONTAP 中新增/移除節點
我們已經了解到，統一的 ONTAP 具有直接的節點到磁碟所有權關係，並且所有節點都必須擁有一些磁碟，並且至少附加一個 aggregate。基於此，以下規則適用於節點的新增和刪除操作。
-
在統一的 ONTAP 中新增節點無需任何額外步驟，但為了確保所有節點（包括新節點）的效能平衡，需要將磁碟區遷移到新節點。這需要預先分析現有磁碟區及其工作負載，決定要遷移哪些磁碟區，然後執行實際的磁碟區遷移，而實際的磁碟區遷移又需要將資料複製到後端叢集網路。
-
在統一 ONTAP 中移除節點需要手動遷移節點上的現有磁碟區，這意味著您必須確定哪些節點可以託管哪些磁碟區以保持效能穩定，並且您必須有足夠的可用容量來為這些磁碟區提供遷移空間。如果可用容量不足，可能還需要進行額外的磁碟區遷移，以便在叢集中重新分配工作負載。移除節點也會移除 HA 配對，因此工作量會加倍。由於節點擁有磁碟，因此還需要對這些節點進行完整的磁碟重新初始化。所有這些都會增加原本相對簡單的任務所需的時間和精力。
NetApp AFX 中的節點新增 / 刪除
我們也了解到，NetApp AFX 並沒有利用標準的節點到磁碟所有權機制，也不使用實體聚合來向叢集提供容量。因此，節點的新增和移除行為略有不同。
-
在 NetApp AFX 中新增節點無需進行預先的磁碟區分析，也無需管理員介入來確保每個節點的磁碟區數量均衡。相反地，ONTAP 會自動平衡新加入節點之間的磁碟區數量，以維持相對均衡的效能設定檔。ONTAP 會自動在節點之間移動磁碟區，而無需複製任何內容，從而減少了向叢集新增節點所需的時間、容量和工作量。
-
在 NetApp AFX 中移除節點也不需要太多（如果有的話）人工介入。當節點標記為移除時、ONTAP 會自動將磁碟區移至各節點（同樣不需複製）、以清空要移除的節點。而且由於節點不擁有磁碟、因此移除節點後不需要重新初始化磁碟。這使得 AFX 中的節點本質上具有模組化、易於擴充或縮減。
效能導向的磁碟區移動
NetApp AFX 的零複製磁碟區移動功能，表示它可以在不複製資料的情況下根據需要重新平衡磁碟區，這使其能夠快速執行，且無需額外容量。這表示磁碟區移動可以成為 ONTAP 叢集自動負載平衡中更重要的一環。現在移動磁碟區幾乎不產生任何成本，ONTAP 可以利用這個有價值的工具，納入如以效能為導向的磁碟區負載平衡等功能。
在執行 ONTAP 9.18.1 及更新版本的 NetApp AFX 中，節點、HA 配對和磁碟區使用率會持續受到監控，同時也會收集和分析效能資料。如果節點的使用率超出定義的臨界值，ONTAP 會自動選取要移至使用率較低節點的磁碟區，以維持整個叢集的平衡效能。
叢集規模和擴充
統一 ONTAP 叢集最多支援 24 個節點，每個新增節點都必須配備磁碟（用於系統功能和資料服務）。磁碟櫃可以新增到叢集中，但即使叢集規模達到 24 個節點，它們也始終連接到單一 HA 配對，並且僅由單一節點擁有。這意味著即使只需要提升效能，叢集也會增加容量，而效能提升主要集中在新節點擁有的特定磁碟集。因此，您最終可能會獲得一些不需要的額外容量。
NetApp AFX 支援更大規模的叢集。從 9.19.1 版本開始，AFX 叢集的單一叢集最多可包含 32 個節點。由於所有節點都能看到並存取所有磁碟，因此它們可以共用這些磁碟機的效能和容量（截至 ONTAP 9.19.1 版本，最高可達 32PB），從而避免資源閒置。磁碟區移動無需複製，因此 ONTAP 能夠自動將磁碟區移動到新增的節點，以確保節點利用率均衡分佈，而容量則透過儲存可用區進行均衡分配。
根磁碟區變更
在 NetApp ONTAP 中，每個節點都被指派一個根磁碟區，用於存放系統特定的檔案和功能，例如日誌檔案、開機映像、核心檔案、叢集資料庫等等。
在統一的 ONTAP 中，這些根磁碟區位於實體根 Aggregate 上。為了減少根 Aggregate 使用的容量，它們是透過進階磁碟分割（ADP）在資料磁碟機分割區上建立的。
NetApp AFX 架構移除了實體聚合，因此也不再需要根聚合和 ADP。根磁碟區的概念仍然存在，但它們現在位於容量池的虛擬化區域中，無需額外配置。此外，根磁碟區的功能也發生了變化。開機映像和複寫的叢集資料庫從儲存堆疊移至每個 AFX 節點上的板載開機媒體。現在，即使儲存堆疊存取中斷，節點仍然可以開機並保持叢集資格，從而簡化了疑難排解的複雜性。
機載開機媒體
NetApp AFX 節點利用內建的開機媒體，這是一個 NVMe 連接的 M.2 裝置，容量約為 3.8TB。這些開機裝置包含開機映像檔和複寫的資料庫，這些都與儲存機櫃分離，當發生磁碟存取問題時可提供額外的備援。如果開機媒體故障，該節點將由其 HA 夥伴接管，並可更換開機媒體。更換後，儲存管理員會將新的 ONTAP 映像載入該裝置，ONTAP 會自動重建叢集資料庫以恢復完整功能。
效能
NetApp AFX 的設計以效能和擴充性為核心，專門針對需要高讀寫處理量的工作負載，並可提供簡單、線性的擴充。
每個節點的效能
每個 NetApp AFX 儲存節點都提供特定的讀取和寫入吞吐量。隨著節點加入叢集中，效能會線性成長，如本文件「節點效能的線性擴展」部分所述。
目前，節點類型為 "AFX 1K"，讀寫吞吐量大致如下所示。隨著 NetApp AFX 可用硬體的更新，這些限制可能會改變。注意：如下面的「基準測試結果」部分所示，使用多個用戶端讀取和寫入多個檔案時達到了最高效能。
| 節點類型 | 讀取效能上限 | 最大寫入效能 |
|---|---|---|
AFX 1K |
約 35GB/s |
約 10GB/s |
|
如需最新的效能預估，請洽詢您的 NetApp 銷售團隊。 |
每個磁碟櫃效能
每個儲存架包含高效能儲存模組，配備 16 個 100GB 乙太網路連接埠，利用 RoCEv2 通訊協定與叢集中的運算節點進行高頻寬儲存互動。與任何實體資源一樣，這些儲存架的效能也有其極限——尤其因為 NetApp AFX 可以呈現多個節點指向同一組磁碟。下表顯示了單一儲存架對 TLC 和 QLC 硬碟的估計最大讀取和寫入效能。有關 TLC 和 QLC 差異的更多資訊，請參閱「TLC 與 QLC」。
| 機櫃模組類型 | 讀取效能上限 | 最大寫入效能 |
|---|---|---|
NSM 140 |
140GB/s（TLC 和 QLC） |
70GB/s TLC 35GB/s QLC |
|
|
如需最新的效能預估，請洽詢您的 NetApp 銷售團隊。 |
效能密度
在分散式 ONTAP 架構中，將儲存節點與磁碟櫃分離，可讓更多節點將流量推送到較少的磁碟櫃，這有助於減少資料中心的整體佔用空間，只需使用所需的容量即可獲得最大效能。
「效能密度」的概念使儲存管理員能夠最大限度地利用現有硬體，而無需過度配置儲存環境。
例如，在統一的 ONTAP 叢集中，由於每個節點都有自己的一組磁碟，因此效能僅限於該節點擁有的磁碟；由於只有一個節點可以存取一組磁碟，因此它不一定能充分利用可用磁碟並達到其最大效能。
NetApp AFX 將所有磁碟匯集到單一儲存可用區域中，因此所有節點都可以運用所有磁碟。而且由於磁碟和節點是分離的，因此您不需要那麼多機櫃就能獲得相同的效能。這樣可以壓縮效能並最大化機櫃的最大效能潛力。
節點與機櫃比率
Unified ONTAP 節點每個節點至少需要一組磁碟，且單一節點可以連接多個磁碟櫃。因此，單一節點可能會出現效能瓶頸，可能無法充分利用其自身的磁碟。
NetApp AFX 將所有磁碟櫃提供給所有節點。每個磁碟櫃包含具有 16 x 100GB RoCE 功能介面的模組，以增加每個磁碟櫃允許的總效能量。因此，您可以使用多個節點飽和單一磁碟櫃，這些節點將對同一組磁碟進行讀取和寫入。
截至 ONTAP 9.19.1，節點：機櫃飽和度比率約為 4:1。
基準測試結果
以下部分介紹使用具有下列組態參數的 NetApp AFX 叢集進行基準測試的結果。
-
4 個節點、4 個資料介面
-
2 個磁碟櫃（7.6TB 磁碟機）
-
ONTAP 9.19.1
-
NFSv4.2（pNFS、工作階段主幹連線）
-
FlexGroup Volume
-
"ElBencho" 基準測試
-
寫入：elbencho --hosts=x.x.x.[y-z] -d -w -b 1M -t 80 --iodepth 1 --direct -s 600g /fio_vol1/
-
讀取：elbencho --hosts=x.x.x.[y-z] -r -b 256k -t 80 --lat --iodepth 2 --direct -s 600g --infloop /fio_vol1/
-
4 台 Cisco C240 M8 伺服器、2 個連接埠 * 200GbE CX-7 卡、80 個執行緒
-
NFS 掛載選項：rw,vers=4.2,rsize=1048576,wsize=1048576,trunkdiscovery,proto=tcp
上述組態達到了 4 節點叢集可用的最大讀取速度（~134GB/s），並且正好達到每個節點允許的最大寫入速度（40GB/s）。
積極的預先讀取
在媒體串流工作負載中，一部 4K 電影通常會分割成數萬個檔案，每個檔案的大小通常在 50 MB 到 250 MB 之間。每個檔案代表一個影格，應用程式會在單一要求中讀取整個影格。為了維持流暢、不間斷且無可見緩衝的串流，這些影格讀取必須完成且不能中斷。
ONTAP 提供磁碟區層級選項(`-aggressive-readahead-mode`來最佳化這些工作負載。從 ONTAP 9.19.1 開始，AFX 上引入了新的 `cross_file_sequential_read`模式，可加速具有可預測 I/O 模式的類似檔案類型工作負載（例如媒體轉譯和串流）。
cross_file_sequential_read 會根據檔案名稱預測下一個要讀取的檔案，並在用戶端發出讀取呼叫之前開始對這些檔案進行預先讀取。預測邏輯假設目錄中的所有檔案都遵循一個命名模式，其數字後綴單調遞增（例如 file1、file2、file3）。目錄中的所有檔案必須遵循此模式，可以使用十進位或十六進位編號。檔案名稱長度最多為 255 個字元。該邏輯與副檔名無關，並且僅基於目前檔案名稱在目前目錄中產生下一組檔案名稱。如果先前使用十進位編號產生的檔案名稱在目錄中不存在，則會使用十六進位編號重新產生檔案名稱。如果產生的檔案名稱都不存在，則不會對該組發出預先擷取。預先擷取會在發出下一個用戶端讀取時恢復。
啟用這些選項後，"frametest" 效能基準測試能夠以每秒 30 幀的速度讀取 30,000 個 4K 幀，同時支援 30 個用戶端（NFSv3 和 SMB3）和 34 個用戶端（NFSv4.1），沒有丟幀。
雖然跨檔案循序讀取主要針對媒體工作負載而設計，但其他具有可預測存取模式和檔案名稱的讀取密集型工作負載（例如 AI 訓練和推理）也可以從中受益。
考量事項與注意事項
-
共享緩衝區快取 – 主動預讀使用與節點上其他磁碟區相同的緩衝區快取。啟用此功能可能會影響該節點上其他磁碟區的讀取效能。
-
底層儲存效能 – 如果檔案讀取速度不夠快（例如，在基於 HDD 的 FAS 系統上），則快取資料可能會在用戶端讀取之前被清除，從而抵消預讀的優勢。
-
存取模式要求 – 如果工作負載的讀取模式不是循序的，或者目錄中的檔案名稱不是按遞增循序順序命名的，則 cross_file_sequential_read 積極預先讀取模式不會帶來有意義的效益。
NFSv4.x 效能增強功能
幾十年來，NFS 版本 3 一直是 NFS 應用程式的黃金標準——早在 1995 年正式發佈時就已如此。它兼具高效能和高可靠性，因此人們很難考慮升級到更新的 NFS 版本，這也不難理解。
然而、NFSv3 並非沒有限制。協定的無狀態特性雖然有利於效能、並可將儲存容錯移轉的中斷降至最低、但對於資料一致性和鎖定管理而言並不理想。NFS 伺服器並不會真正追蹤鎖定狀態、因此如果發生故障、NFS 伺服器可能會或可能不會釋放鎖定、而 NFS 用戶端可能不知道檔案是否已鎖定。
NFSv3 的安全性也存在一些不足之處。該協定需要開放多個防火牆連接埠才能正常運作，且數位 ID 以明文形式透過網路傳輸。此外，NFS 缺乏強大的 ACL 支援，也不包含原生檔案和資料夾稽核功能。由於這些限制，NFSv4 於 2003 年透過 "RFC-3530" 建立（已於 2015 年被 "RFC-7530"淘汰）。
雖然 NFSv4.x 已經存在了 20 多年，但由於一些原因，它仍然沒有被廣泛採用。
-
身分識別管理的複雜性：許多環境沒有名稱服務基礎架構來正確利用 NFSv4.x 中的名稱字串和 Kerberos 安全性需求。
-
新版 NFS 用戶端的需求：隨著 NFSv4 發佈時間的推移，如今的 NFS 環境對新版 NFS 用戶端的需求已不再那麼迫切。幾乎所有目前使用的作業系統都包含完全支援 NFSv4 的 NFS 用戶端，但仍有一些舊系統可能缺少必要的 NFSv4.x 套件。事實上，某些應用程式仍然需要使用較舊的 NFS 版本。
-
「如果沒壞，就別修」的心態：企業 IT 組織在採用新技術方面出了名的保守——即使是那些已經存在 20 多年的技術。如果目前的 NFS 版本運作良好，為什麼要改變呢？
-
效能問題:在過去 20 年的大部分時間裡,有狀態協定(例如 NFSv4.x)的效能一直落後於無狀態協定 NFSv3。過去,效能上的影響往往超過了 NFSv4.x 帶來的優勢。
使用 AFX 在 ONTAP 9.18.1 中對 NFSv4.x 進行改進
ONTAP 的一些架構變更為 NFS 提供了急需的效能提升，並顯著提高了 NFSv4.x 的整體效能。
以下是其中一些變更的高階摘要。
順序讀取效能提升：NFSv4.1 比 NFSv3 提升 30%
ONTAP 9.18.1 引進了對 NFSv4.1 多路徑 I/O 的支援。MPIO 不再處理來自 WAFL 檔案系統的讀取操作，而是將讀取操作轉移到網路域，以多路徑安全的方式提供服務。這種方法減少了上下文切換，提高了順序讀取流量的整體並行性，並透過繞過 WAFL 降低了緩衝區管理的開銷。
FlexGroup Volume 隨機讀取增強：NFSv4.1 與 NFSv3 的差異在 7% 以內
FlexGroup Volume 是將多個底層組成 Volume 整合為一個統一命名空間的 Volume 。在 AFX 中、FlexGroup Volume 預設啟用進階容量平衡、這表示大於 10GB 的檔案會以多部分檔案的形式寫入多個組成 Volume 。由於這些檔案部分位於遠端位置、 NFSv4.x 的隨機讀取效能通常略有下降（比 NFSv3 低約 18% ）。ONTAP 9.18.1 引入了對 NFSv4.x 多部分讀取的快取 IO 支援、以解決此問題。附註：此變更不適用於 FlexVol Volume 。
循序寫入：比先前版本提升 10%
改進了 HA 故障轉移功能的 NVLOG 資料複製方式,提高了 NetApp AFX 系統的整體順序寫入效能。
中繼資料作業：在 EDA 基準測試中，效能在 NFSv3 的 15% 範圍內
NFSv4.1 傳統上會將所有 OPEN 和 CLOSE 操作串行化，叢集節點會逐一處理這些操作，然後才能將其從網路傳送到 WAFL。ONTAP 9.18.1 引入了並發開啟 / 關閉（COC）機制，它透過改變競爭條件的解決方式來消除網路串列化，從而解決了先前版本中出現的 OPEN/CLOSE 瓶頸問題。
所有這些變更，以及 AFX 帶來的架構變更，都使得 ONTAP 9.18.1 中 NFSv4.1 的整體效能得以提升。
連續 IO 結果
效能提升較為顯著的領域之一是順序 IO（即可預測且依序執行的 IO 操作）。在使用 fio 進行的標準效能測試中，執行 ONTAP 9.18.1 的 AFX 的順序讀取效能提升了近 30%，順序寫入效能提升了 10%。
中繼資料密集型工作負載結果
更令人印象深刻的是，NFSv4.x 在效能瓶頸之一——元資料方面也取得了顯著改進。這些是隨機 I/O 操作，通常在 4K 範圍內，用於管理檔案擁有者和屬性、建立和列出檔案等等。由於 NFSv4.x 的狀態性，這類操作往往會消耗更多 CPU 資源並增加延遲，從而降低整體效能。
隨著 AFX ONTAP 9.18.1 的變更，NFSv4.x 在這些類型工作負載下的效能已大幅改善，並已縮小與 NFSv3 效能的差距（在 15% 以內）。
我們的效能工程團隊對標準 AI 影像、EDA 和軟體建置基準的效能進行了比較，發現與先前的 ONTAP 版本相比有了巨大的提升。
其他相似之處和差異
儘管 NetApp AFX 在儲存架構的呈現方式上存在一些相當大的差異，但 ONTAP 的功能集和管理方式幾乎保持不變。這完全是出於設計考量。ONTAP 就是 ONTAP，應盡可能降低學習難度。在這種情況下，NetApp AFX 仍然運行著 ONTAP。
管理 – CLI
在 NetApp AFX 中，CLI 與統一 ONTAP 的 CLI 幾乎完全相同。大多數命令仍然在叢集層級運行，但也允許執行節點層級的命令。仍然保留了頂級命令目錄和子命令，以及命令自動補全功能。此外，所有相同的 CLI 快捷鍵也都有效（例如，使用 `-fields`過濾內容）。
NetApp AFX CLI 的唯一真正區別在於新增和移除的功能（如本文檔「」部分所述）。如果某個功能（例如 aggregate 或 Metrocluster）被移除，則對應的 CLI 指令將不再可用。
此外，在 NetApp AFX 新增特性和功能的同時，也會提供新的指令。例如，新的 "NetApp AI Data Engine（AIDE）" 附加元件透過後端叢集網路直接與 NetApp AFX 叢集互動。因此， dcn 和 data-engine 指令目錄會新增至 NetApp AFX CLI 中。
以下顯示了 NetApp AFX 叢集中管理員權限可用的頂級命令目錄。新增指令以粗體顯示。
AFX::>
cluster data-engine dcn event exit
history job man metrocluster network
qos redo rows run security
set snaplock snapmirror statistics statistics-v1
storage system top up volume
vserver
管理 – GUI
System Manager 仍然是與 NetApp AFX 叢集互動以管理資源的 GUI 介面，當您第一次登入它時，您可能不會一眼看出您實際上並沒有登入統一的 ONTAP 系統。
統一 ONTAP System Manager 儀表板 |
NetApp AFX System Manager 儀表板 |
如上所示，統一 ONTAP 和 NetApp AFX 的 System Manager 之間並沒有太多明顯的差異。不過，還是有一些差別的。
深入查看選單和儀表板後，你會發現大部分內容都保持不變。磁碟區仍然顯示已使用容量和總容量。網路介面仍然顯示連接埠和 IP 位址。你仍然可以為 SnapMirror 配置保護原則。硬體檢視仍然可用。但 NetApp AFX 也透過提供新的佈線檢視對這些檢視進行了一些增強，你可以在其中深入查看整個儲存堆疊中所有線纜的連接位置。
REST API
NetApp AFX 也致力於保留大部分 ONTAP REST API 調用，這意味著如果您已建立了一套基於 REST API 的自動化工具，它們在大多數情況下仍然可以使用。主要例外情況包括聚合、Metrocluster、SAN 和一些效能計數器。完整的 REST API 文件可在 NetApp AFX 叢集的 System Manager 中找到，瀏覽至 https://clus_mgmt_ip/docs/api。
外部 ONTAP 管理工具
NetApp AFX 為一些外部 ONTAP 管理工具提供支援，例如：
-
NetApp System Manager
-
NetApp Console
-
Grafana Harvest（25.11.0 及更新版本）
-
NetApp Trident （25.10 及更高版本）
NetApp AFX 目前不支援：
-
NetApp ActiveIQ Unified Manager
網路
NetApp AFX 中的網路堆疊與統一 ONTAP 相同。
-
資料 LIF 仍用於向內部和外部服務提供網路位址。
-
每個節點都有自己的一組實體連接埠和虛擬連接埠。
-
VLAN、ifgroup 和 BGP 仍受支援。
-
LIF 仍然可以在叢集中的實體節點和連接埠之間進行容錯移轉。
-
IPspace / 廣播網域的設定仍然相同。
-
每個 SVM 都可以擁有自己專用的資料網路。
-
管理網路可以與資料網路分開。
-
除了新增 400GB 網路支援外，用戶端資料網路沒有其他變更。
-
後端叢集交換器仍然透過 NetApp 提供的「黃金設定檔案」進行設定。
一些主要的網路差異包括：
-
後端叢集網路連接埠現在僅支援與叢集交換器的 100 GB 連線。
-
由於叢集交換器支援 400GB 頻寬，後端節點連線使用 4 x 100GB 分線纜線，以減少交換器上使用的連接埠數量。
-
現在，透過交換器上的新 HA VLAN 組態，NVRAM 會在後端叢集網路的 HA 配對之間進行鏡射。
-
AI Data Engine 預設會新增一個新的 DCN 網路。這些 IP 位址會自動生成,並可根據需要進行變更。
安全性
NetApp AFX 執行 ONTAP，這表示它使用與 ONTAP 相同的安全性。所有加密模組都相同，這表示一旦認證程序完成，安全認證將會相同。NetApp AFX 也運用與統一 ONTAP 相同的安全加密支援。
此外， NetApp AFX 支援統一 ONTAP 提供的許多安全功能，包括（但不限於）：
-
自主勒索軟體保護
-
安全的多租戶
-
靜態加密（Volume 加密）和傳輸中加密（TLS 1.3）
-
自加密硬碟（SED）
-
NFS 和 SMB Kerberos 驗證與加密
-
多管理員驗證
-
SnapLock
有關統一 ONTAP 已獲得的認證（以及其他安全強化資訊）、請參閱：
快照和資料保護
NetApp AFX 採用與統一 ONTAP 相同的快照和複寫技術，這些功能的工作方式沒有重大變化。實際上，AFX 可以使用您熟悉的 "規則和組態" 與統一 ONTAP 系統進行雙向複寫。
AFX 中複製的唯一例外情況是 FlexGroup 磁碟區複製到統一 ONTAP 系統。在這種情況下,目標統一 ONTAP 系統必須運作 ONTAP 9.16.1 或更高版本才能提供高階容量平衡支援。
不中斷營運
ONTAP 提供不中斷營運作業，例如磁碟區移動、升級、叢集維護、儲存設備容錯移轉等。NetApp AFX 提供相同的不中斷營運作業，但有一些調整。
-
Volume 移動仍然不會造成中斷，但不再需要複本。
-
儲存容錯移轉仍然不會造成中斷，但在初始容錯移轉之後，磁碟區會在叢集中所有存續的節點之間重新平衡。
-
LIF 遷移是相同的。
-
硬體維護和升級方式相同。
磁碟區類型
Unified ONTAP 支援多種不同的磁碟區類型，例如：
-
FlexVols
-
資料量FlexGroup
-
FlexCache
-
FlexClone
-
物件儲存貯體
NetApp AFX 為每種磁碟區類型提供全面支援，並且 FlexCache 磁碟區與統一的 ONTAP 系統完全互通。
有關 FlexGroup 磁碟區如何從 AFX 架構中受益的更多資訊，請參閱「FlexGroup 磁碟區管理改進」。
硬體詳細資料
以下章節涵蓋有關 NetApp AFX 叢集硬體的詳細資訊。如需 NetApp AFX 硬體的最新資訊，請參閱"https://hwu.netapp.com"。
支援的硬體
有關 NetApp AFX 支援的硬體的最新資訊，請查看 "https://hwu.netapp.com"。
節點
NetApp AFX 節點是基於為統一 ONTAP 叢集提供的 AFF A1K 型節點。這些節點沒有板載磁碟用於儲存，採用模組化設計，可根據效能需求輕鬆新增和移除節點。每個節點佔用 2U 的機架空間，並且隨著新增到 AFX 叢集中的節點數量增加，效能呈線性增長。
硬體插槽
NetApp AFX 1K 節點使用下列插槽分配。
-
插槽 1 專用於 HA 複寫
-
插槽 7 專用於叢集複寫
-
插槽 10 和 11 專用於儲存櫃通訊
書架
NetApp AFX 機架採用與 AFF 系統相同的機殼。AFX 機架的主要差異在於所使用的模組。NSM140 模組可提供更強大的效能，並有助於實現解耦式 ONTAP。以下是一些關鍵注意事項：
-
僅支援完全填滿的磁碟櫃。
-
當插入電源後，NetApp AFX 會自動偵測到磁碟櫃。
-
目前不支援移除機櫃。
交換器
NetApp AFX 仍然使用後端叢集交換器進行叢集內通訊，例如叢集資料庫複寫、遠端資料作業、儲存作業和 NVRAM 鏡射。從功能上看，統一 ONTAP 和 NetApp AFX 叢集交換器之間的唯一區別在於：
-
400GbE 支援
-
新的 HA VLAN
-
如需更多資訊、請參閱 "Cisco 交換器資料表" 。
叢集交換器連線能力
NetApp AFX 的許多主要架構概念都大量使用了後端叢集交換器。例如，叢集介面、儲存適配器、儲存機櫃和 NVRAM 卡都連接到叢集交換器。目前，所有這些介面僅支援 100GB 通訊，而交換器支援 400GB。因此，100GB 介面透過 4 x 100GB 分線電纜連接到交換器上的 400GB 介面。這種方法減少了交換器上使用的連接埠數量。例如，16 x 100GB 儲存機櫃模組連接埠僅使用交換器上的 4 個連接埠，而節點上總共 8 個連接埠使用 2 個交換器連接埠。
磁碟類型和大小
NetApp AFX 目前僅支援以下尺寸的 NVMe 附加 SSD ：
-
7.6 TB
-
15.3 TB
-
30.1 TB
-
60.6 TB
TLC 與 QLC
NetApp AFX 可同時支援 TLC 和 QLC 兩種快閃記憶體類型。7.6TB 和 15.3TB 的硬碟採用 TLC 閃存，而容量大於 30.1TB 的硬碟則採用 QLC 快閃記憶體。無論採用何種快閃記憶體類型，均可符合 NVIDIA SuperPod 認證的效能標準。
所有與 NetApp AFX 系統搭配使用的硬碟均為高效能硬碟，QLC 和 TLC 的讀取效能幾乎相同。QLC 的寫入效能略遜於 TLC，並且在寫入密集型工作負載下可能會出現更明顯的損耗平衡現象。
如需效能數據、請參閱表 7）每個磁碟櫃的效能預估值。
在選擇使用的磁碟機類型時，請考慮儲存設備將承載哪些工作負載，以及涉及的效能 / 容量密度權衡。
最大值和最小值
以下部分將介紹 NetApp AFX 叢集與統一 ONTAP 相比的最大值和最小值。
如需最新限制，請參閱 "Hardware Universe"。
| 限制 | 統一 ONTAP | NetApp AFX |
|---|---|---|
Volume 數量（叢集） |
|
|
Aggregate 大小 |
|
|
節點計數 |
|
|
總容量 |
|
|
支援的磁碟櫃數量 |
|
|
支援的磁碟機總數 |
|
|
Volume 大小 |
|
|
每個磁碟區的檔案數量上限 |
|
|
每個目錄的最大檔案數（預設 320MB maxdirsize 值） |
|
|
SnapMirror 同時傳輸 |
|
|
qtree 數量 |
|
|
每個節點的最大 TCP 連線數 |
|
|
每個節點的鎖定數量上限 |
|
|
最大資料介面數（叢集） |
|
|
最大成分數 – FlexGroup |
|
|
叢集間 LIF 數量上限 |
|
|
IP 空間的最大數量 |
|
|
每個來源的 FlexCache 最大數量 |
|
|
FlexCache 的最大數量（節點） |
|
|
NetApp ONTAP for AFX 最新版本有哪些新功能？
本部分涵蓋 NetApp AFX 的最新更新，並將隨每個新版本更新。請定期查看此處以獲取新資訊，同時也請查看版本發布說明。
最新版本：
ONTAP 9.19.1RC1（截至 2026 年 5 月）
NetApp AFX 的新增功能：
-
全域重複資料刪除
-
動態儲存效率
-
進階預先讀取
-
支援 32 個節點
-
32PB 支援
-
每個 FlexGroup Volume 512 個組成磁碟區
何處可找到其他資訊
如需深入瞭解本文件所述資訊，請參閱下列文件和 / 或網站：
-
Hardware Universe "https://hwu.netapp.com/"
-
NetApp AFX 產品頁面https://www.netapp.com/afx/[]
-
NetApp AFX：可擴充、安全的 AI 資料基礎架構"https://www.netapp.com/blog/afx-scalable-secure-ai-data-infrastructure/"
-
在 NFSv3 或 NFSv4.x 之間做決定？選擇越來越清楚了… "https://community.netapp.com/t5/Tech-ONTAP-Blogs/Deciding-between-NFSv3-or-NFSv4-x-The-choice-is-getting-clearer"
-
NetApp AFX 資料表 "https://www.netapp.com/media/142853-ds-3466-netapp-afx-datasheet.pdf"
版本歷史記錄
| 版本 | 日期 | 文件版本歷史記錄 |
|---|---|---|
版本 1.0 |
2026 年 6 月 |
初始版本 |
請參閱 NetApp 支援網站上的 "互通性對照表工具（IMT）"，以確認本文件中所述的產品和功能版本是否受您的特定環境支援。NetApp IMT 定義了可用於建立受 NetApp 支援的組態的產品元件和版本。具體結果取決於每位客戶根據已發布的規範進行的安裝。
版權資訊
版權所有 © 2026 NetApp, Inc. 保留所有權利。美國印刷。未經版權所有者事先書面許可，不得以任何形式或任何方式（包括圖形、電子或機械方式，例如影印、錄音、錄製或儲存在電子檢索系統中）複製本文件中受版權保護的任何部分。
由 NetApp 版權資料衍伸之軟體必須遵守下列授權和免責聲明：
本軟體由 NetApp 提供，以「現況」提供，不提供任何明示或暗示的保證，包括但不限於適銷性和特定用途適用性的暗示保證，特此聲明免除所有此類保證。在任何情況下，NetApp 均不對任何直接、間接、附帶、特殊、懲罰性或後果性損害（包括但不限於替代商品或服務的採購、使用、資料或利潤的損失或業務中斷）承擔責任，無論此類損害是如何造成的，也無論基於何種責任理論，無論是合約、嚴格責任還是侵權（包括過失責任或其他），即使已被告知可能發生此類損害。
NetApp 保留隨時變更本文所述之任何產品的權利，恕不另行通知。NetApp 不承擔因使用本文所述之產品而產生的責任或義務，除非明確經過 NetApp 書面同意。使用或購買此產品並不會在依據任何專利權、商標權或任何其他 NetApp 智慧財產權的情況下轉讓授權。
本手冊中所述的產品可能受一項或多項美國專利、外國專利或正在申請的專利保護。
有限權利聲明：政府的使用、複製或揭露均受 DFARS 252.227-7013（2014 年 2 月）和 FAR 52.227-19（2007 年 12 月）技術資料權利—非商業項目第 (b)(3) 款所規定的限制約束。
本文所含資料涉及商業產品及/或商業服務（定義見 FAR 2.101），且為 NetApp, Inc. 所有。本協議項下提供的所有 NetApp 技術資料和電腦軟體均為商業性質，且完全由私人出資開發。美國政府擁有非獨佔、不可轉讓、不可再許可的全球性、有限且不可撤銷的許可，僅可將資料用於與交付該資料的美國政府合約相關的用途，並支持該合約的履行。除本文另有規定外，未經 NetApp, Inc. 事先書面批准，不得使用、揭露、複製、修改、執行或展示該資料。美國國防部的授權權利僅限於 DFARS 條款 252.227-7015(b)（FEB 2014）中規定的權利。
商標資訊
NETAPP、NETAPP 標誌以及列於 "http://www.netapp.com/TM" 的標記均為 NetApp, Inc. 的商標。其他公司與產品名稱可能為其各自所有者的商標。
