AFF A800 是 NetApp 的頂級 ONTAP 全閃存存儲陣列，推出時提供了行業首創的端到端 NVMe/FC over 32Gb FC，以及 100GbE 連接。 迄今為止，我們一直在研究全閃存 AFF 產品線，首先是強大的 A200 （此後被 A220 取代）以及 A300. 我們之前評論過的兩個單元都獲得了編輯選擇獎。 今天，我們將關注基於 NVMe 的 A800 powerhouse，它提供與之前審查過的模型相同的 ONTAP 優勢，以及成倍增長的性能和更低的延遲。 雖然這篇初步評論側重於光纖通道上的系統性能，但後續文章將深入探討 A800 的端到端 NVMe over Fabrics (NVMeoF) 支持。
AFF A800 是 NetApp 的頂級 ONTAP 全閃存存儲陣列，推出時提供了行業首創的端到端 NVMe/FC over 32Gb FC，以及 100GbE 連接。 迄今為止，我們一直在研究全閃存 AFF 產品線，首先是強大的 A200 （此後被 A220 取代）以及 A300. 我們之前評論過的兩個單元都獲得了編輯選擇獎。 今天，我們將關注基於 NVMe 的 A800 powerhouse，它提供與之前審查過的模型相同的 ONTAP 優勢，以及成倍增長的性能和更低的延遲。 雖然這篇初步評論側重於光纖通道上的系統性能，但後續文章將深入探討 A800 的端到端 NVMe over Fabrics (NVMeoF) 支持。
與專為中端市場的不同細分市場打造的 A200 和 A300 不同，A800 專為需要最高性能的工作負載（例如 AI 和深度學習）而設計，同時還包括 ONTAP 所提供的一組強大的企業數據服務聞名。 明確一點，NetApp 在 EF 全閃存系列中擁有一系列真正快速的存儲，例如中端 EF570 我們之前回顧過。 回到 A800，NetApp 聲稱該系統可以在低於 1.3 微秒的延遲和高達 500GB/s 的吞吐量下達到 34 萬次 IOPS，使用 HA 對。 在規模上，這意味著 NAS 集群可以在 11.4 毫秒的延遲和 1 GB/s 的吞吐量下提供高達 300M 的 IOPS。 SAN 集群可以在 7.8µs 延遲和 500GB/s 吞吐量下提供高達 204M IOPS。
與其他 AFF A 系列系統一樣，NVMe A800 可以在 NAS 配置的集群中擴展到 24 個（12 個 HA 對）4U 雙控制器節點。 因為這是一個基於 NVMe 的系統，所以在驅動器縮放方面存在一些細微差別。 例如，中端 A300 支持 4608 個驅動器，而 A800 最高為 2880 個。雖然在部署時不太可能成為功能問題，但我們強調這一點只是為了表明基於 NVMe 的系統在考慮 JBOD 擴展架時面臨不同的工程挑戰基於 SAS 的系統，因此我們不能假設隨著產品線的升級一切都會變得更大。 在 SAN 配置中，NVMe A800 可擴展到 12 個節點（6 個 HA 對），支持 1,440 個驅動器。 也就是說，如果用戶使用 15.3TB NVMe SSD，他們可以在 2.5U 佔用空間中擴展到 4PB。 啟用數據效率（假設 5:1）後，A800 在 315 節點 NAS 集群中支持超過 24PB，在 SAN 集群中支持超過 160TB。
雖然 NetApp 已經在其他 AFF 系統中啟用了前端 NVMe 支持，但 A800 提供了所謂的端到端 NVMe 支持。 如前所述，我們不會在這篇評論中深入探討這意味著什麼。 可以說 A800 是第一個實現這一目標的全閃存 NVMe 陣列就足夠了。 實際上，這意味著組織可以利用當今新興的 NVMeoF 功能浪潮，同時仍然通過 FC 為其更傳統的工作負載提供服務。 以前，想要利用 NVMeoF 的組織通常被降級為“科學項目”類型的部署，這些部署雖然速度很快，但在規模和數據服務方面存在局限性。 NetApp 的實施解決了這些缺點，同時還支持 FC 和以太網中的標準連接選項。
當然，我們不能不強調雲連接性和 A800 NetApp 數據結構. ONTAP 固有的是與領先的雲提供商的深度連接，使客戶能夠將數據放在最有意義的地方，無論是在 A800 本地還是其他地方。 NetApp 支持與 Amazon Web Services、Microsoft Azure、Google Cloud Platform 等的雲和多雲連接。 廣泛的雲支持讓 NetApp 客戶在管理數據足跡時擁有所需的靈活性，並根據需要靈活地移動數據以利用雲經濟、新功能或形狀類型等。
我們的特定構建包括一個 A800，帶有 24 個 1.92TB NVMe SSD，每個控制器連接兩個四端口 32Gb FC 端口（總共 8 個端口），並安裝了 ONTAP 9.5RC1。
NetApp A800 規格
| 最大橫向擴展 | 2-24 個節點（12 個 HA 對） |
| 最大SSD | 2880 |
| 最大有效容量 | 316.3PB |
| 每系統雙活雙控制器 | |
| 控制器外形 | 4U |
| PCIe 擴展槽 | 8 |
| FC 目標端口（32Gb 自動量程） | 32 |
| FC 目標端口（16Gb 自動量程） | 32 |
| 100GbE 端口（40GbE 自動量程） | 20 |
| 10GbE 端口 | 32 |
| 支持存儲網絡 | NVMe/光纖通道 FC iSCSI的 NFS的 磷酸化NFS CIFS/中小企業 |
| 作業系統版本 | ONTAP 9.4 RC1 或更高版本 |
| 貨架和媒體 | NVMe 驅動器包 |
| 支持主機/客戶端操作系統 | 窗戶2000 在Windows Server 2003 在Windows Server 2008 在Windows Server 2012 在Windows Server 2016 Linux 甲骨文 AIX HP-UX Mac OS VMware的 ESX |
設計和建造
NetApp AFF A800 是一個 4U 陣列，外觀與 AFF 系列中的其他陣列非常相似。 在包含通風和 NetApp 品牌的時尚邊框下方，是兩排用於 SSD 的藍色 2.5 英寸驅動器托架。
看看 NVMe 驅動器本身，NetApp 支持多種容量選項，包括 1.9TB、3.8TB、7.6TB 和 15.3TB SSD。 在撰寫本文時，NetApp 將所有這些驅動器作為採用 AES-256 加密的自加密 (SED) 進行交付。 此外，對於使用 ONTAP 9.4 初始化的系統，啟用了快速驅動器歸零。
翻轉到設備的後部，有兩個控制器：一個像鏡像一樣堆疊在另一個之上。 我們的配置包括四種不同風格的連接接口。 這四張卡位於最右側和中間的 PCIe 插槽中。 它們包括四端口 32Gb FC 卡（左上）、雙端口 25GbE 網卡（左下）、雙端口 100GbE 網卡（右上）和四端口 10GbE 網卡（右下）。
卸下其中一個控制器，我們可以看到與設備其餘部分的連接，以及排列在控制器前部的風扇。
翻到後控制器，左側有用於每個控制器的雙冗餘 PSU 以及 HA 互連端口和集群互連端口。 每個控制器的右下角還有 1HA 和集群互連端口。 其餘大部分被 PCIe 插槽（五個）佔用，這些插槽可以填充網絡端口 100GbE、10GbE 或 32Gb 光纖通道或上述配置的某種組合。 中間底部是管理端口和兩個 USB 3.0 端口。
控制器非常容易打開，非常易於維修。
我們可以看到兩個 CPU、20 個 DIMM 插槽（裝有 20 個 32GB DIMM 內存）和兩個 NVDIMM 插槽。 從這裡也可以輕鬆訪問 PCIe 網絡 AIC。
管理
多年來，ONTAP GUI 已經取得了長足的進步，從 8.2 及更早版本的支持 Java 的 GUI 到現代且設計良好的 Web 驅動的 ONTAP 9.5。 NetApp 對 GUI 進行了重大改進，使其越來越多地用於日常管理功能之外的用途。
儀表板：
登錄後，您會看到儀表板，它將讓您快速了解系統正在發生的事情。 就您能夠看到的內容而言，儀表板非常簡單。 每個小部件都允許快速瀏覽警報、性能、容量、效率和保護。 如需更詳細的查看和長期趨勢，建議使用 NetApp（免費）的 OnCommand Unified Manager for ONTAP 指標。
雲層：
通過添加 NetApp Cloud 選項 Fabric Pool，GUI 可以輕鬆連接到公有云，包括 NDAS 以及本地 StorageGRID。
支持向量機：
在此選項卡中，您可以創建、編輯、刪除和啟動/停止 ONTAP 集群上的所有數據協議 SVM，以及編輯各種設置。
聚合和存儲池：
聚合和存儲池選項卡允許直接創建和管理聚合和存儲池。
捲和 LUN：
捲和 LUN 管理頁面為您提供了多種創建和管理 FlexVol、FlexGroup 和 LUN，甚至每個 SVM 的 igroup 和映射的方法。
服務質量：
多年來，QoS 在 ONTAP 上取得了長足的進步，因為您現在可以為每個工作負載配置上限和下限，並將它們配置為適應不斷變化的工作負載。 QoS 可以應用於 ONTAP 內部的各種對象，例如卷、文件和 LUN 以及一些其他對象。
網絡配置：
所有基本網絡配置和管理都在 GUI 中：IP 空間、廣播域、端口、LIF、FC 和現在的 NVMe。
對等：
在 ONTAP 的最後幾個版本之前，您需要僅通過 CLI 創建對等關係； 但是，現在您也可以在 GUI 中創建集群節點，甚至 SVM 節點。 配置對等互連後，您甚至可以直接在卷創建嚮導中創建 SnapMirror 關係。
集群更新：
ONTAP 升級變得越來越容易。 9.4 中添加的一個小但非常有用的功能使進行 ONTAP 更新變得更加容易。 我們當然都喜歡命令行，但這使得與客戶合作升級他們的文件變得非常容易。 沒有更多的 http/ftp 服務器可以搞砸了； 只需直接上傳 .tgz 文件並運行自動集群更新。
性能
對於性能，我們將比較 A800 和 A300。 這用於顯示 NetApp AFF 模型的性能隨著您在系列中的升級而擴展的程度。 在我們所有的測試中，我們都啟用了數據縮減服務，這意味著啟用了內聯重複數據刪除和壓縮。 正如我們在過去的評論中指出的那樣，NetApp ONTAP 提供了強大的災難恢復功能，同時將開銷或性能影響降至最低。
我們的 NetApp AFF A800 配置包括 8 個 32Gb FC 端口，安裝了 24 個 1.92TB NVMe SSD。 在我們的 A24 中部署的 1.92 個 800TB SSD 中，我們將它們分成兩個 RAID-DP 聚合，使用 11 個 SSD，一個作為熱備用。 該陣列通過兩個 Brocade G32 交換機通過 620Gb 連接，然後有 16 個 16Gb 鏈接到我們的 Dell PowerEdge R740xd 服務器。
對於使用 VDbench 和 Sysbench 的綜合基準測試，我們配置了 32 個 600GB 卷，均勻分佈在控制器和磁盤組中。 對於 SQL Server，我們使用了額外的四個 1.1TB 卷，每個控制器兩個卷來保存用於基準測試的 VM。 考慮到數據縮減後，我們測試期間使用的總佔用空間相當於每個聚合的利用率略低於 50%。
SQL Server 性能
StorageReview 的 Microsoft SQL Server OLTP 測試協議採用事務處理性能委員會的基準 C (TPC-C) 的最新草案，這是一種模擬複雜應用程序環境中活動的在線事務處理基準。 TPC-C 基準比綜合性能基準更接近於衡量數據庫環境中存儲基礎設施的性能優勢和瓶頸。
每個 SQL Server VM 都配置有兩個虛擬磁盤：100GB 卷用於啟動，500GB 卷用於數據庫和日誌文件。 從系統資源的角度來看，我們為每個虛擬機配置了 16 個 vCPU、64GB DRAM 並利用了 LSI Logic SAS SCSI 控制器。 雖然我們之前測試的 Sysbench 工作負載在存儲 I/O 和容量方面使平台飽和，但 SQL 測試尋找延遲性能。
此測試使用在 Windows Server 2014 R2012 來賓虛擬機上運行的 SQL Server 2，並由戴爾的數據庫基準工廠進行壓力測試。 雖然我們對該基準的傳統用法是在本地或共享存儲上測試 3,000 規模的大型數據庫，但在本次迭代中，我們專注於在我們的服務器上均勻分佈四個 1,500 規模的數據庫。
SQL Server 測試配置（每個虛擬機）
- 在Windows Server 2012 R2
- 存儲空間：分配 600GB，使用 500GB
- SQL Server 2014的
- 數據庫大小：1,500 規模
- 虛擬客戶端負載：15,000
- 內存緩衝區：48GB
- 測試時長：3 小時
- 2.5 小時預處理
- 30分鐘採樣期
對於我們的 SQL Server 事務性能，A800 的總得分為 12,635.5 TPS，單個 VM 的運行速度從 3,158.6 TPS 到 3,159.3 TPS（比 A300 的 12,628.7 TPS 和 A200 的 12,583.8 TPS 小幅提升）。
查看 SQL Server 平均延遲，我們發現 A800 的改進更大，因為它下降到 5 毫秒聚合和所有 VM 上的 5 毫秒（比 A300 的 8 毫秒和 A200 的 25 毫秒好得多）。
Sysbench MySQL 性能
我們的第一個本地存儲應用程序基準測試包括通過 SysBench 測量的 Percona MySQL OLTP 數據庫。 該測試測量平均 TPS（每秒事務數）、平均延遲和平均 99% 延遲。
每個 Sysbench VM 配置了三個虛擬磁盤：一個用於啟動 (~92GB)，一個用於預構建數據庫 (~447GB)，第三個用於測試中的數據庫 (270GB)。 從系統資源的角度來看，我們為每個虛擬機配置了 16 個 vCPU、60GB DRAM 並利用了 LSI Logic SAS SCSI 控制器。
Sysbench 測試配置（每個虛擬機）
- 中央操作系統 6.3 64 位
- Percona XtraDB 5.5.30-rel30.1
- 數據庫表：100
- 數據庫大小：10,000,000
- 數據庫線程：32
- 內存緩衝區：24GB
- 測試時長：3 小時
- 2 小時預處理 32 個線程
- 1 小時 32 個線程
對於 Sysbench，我們測試了幾組 VM，包括 8、16 和 32，並且我們運行 Sysbench，同時數據縮減都處於“開啟”狀態。 A800 能夠達到 15,750.8VM 的 8TPS、22,170.9VM 的 16TPS 和 44,149.8VM 的 32TPS。 這些比之前的要高得多，幾乎是 A300 在 32VM、22,313 TPS 上的兩倍。
對於 Sysbench 平均延遲，A800 在 16.3VM 時達到 8ms，在 23.1VM 時達到 16ms，在 23.2VM 時達到 32ms。 這比較小的 AFF 模型要好得多。
在我們的最壞情況（第 99 個百分位數）延遲中，A800 31.3VM 達到 8ms，48.5VM 達到 16ms，48.1VM 達到 32ms。
VDBench 工作負載分析
在對存儲陣列進行基準測試時，應用程序測試是最好的，綜合測試排在第二位。 雖然不能完美代表實際工作負載，但綜合測試確實有助於為具有可重複性因素的存儲設備建立基線，從而可以輕鬆地在競爭解決方案之間進行同類比較。 這些工作負載提供了一系列不同的測試配置文件，包括“四個角”測試、常見的數據庫傳輸大小測試，以及來自不同 VDI 環境的跟踪捕獲。 所有這些測試都利用通用的 vdBench 工作負載生成器，以及一個腳本引擎來自動化和捕獲大型計算測試集群的結果。 這使我們能夠在各種存儲設備上重複相同的工作負載，包括閃存陣列和單個存儲設備。
簡介：
- 4K 隨機讀取：100% 讀取，128 個線程，0-120% 重複率
- 4K 隨機寫入：100% 寫入，64 線程，0-120% iorate
- 64K 順序讀取：100% 讀取，16 個線程，0-120% 迭代
- 64K 順序寫入：100% 寫入，8 個線程，0-120% 迭代
- 綜合數據庫：SQL 和 Oracle
- VDI 完整克隆和鏈接克隆跟踪
從峰值隨機 4K 讀取性能開始，A800 以 118,511 IOPS 開始，延遲為 217.5μs。 A800 保持在 1 毫秒以下，直到它達到約 1.07 萬次 IOPS，然後以 1,219.829 毫秒的延遲達到 3.3 IOPS 的峰值。 與延遲為 300 毫秒的 A635,342 的 6.4 IOPS 峰值性能相比，這是一個顯著差異。
看看 4K 寫入性能，A800 以 45,676 IOPS 開始，延遲為 213.1μs。 A800 在達到約 410K IOPS 之前一直具有亞毫秒級延遲性能，然後以約 439K IOPS 的峰值達到峰值，延遲為 4.4ms，然後下降了一些。 相比之下，A300 的峰值性能為 208,820 IOPS，延遲為 9.72 毫秒。
切換到順序工作負載，我們查看峰值 64K 讀取性能，此處 A800 以 29,589 IOPS 或 1.85GB/s 開始，延遲為 166.1μs。 A300 具有亞毫秒延遲，直到大約 300K IOPS 或 18.5GB/s，在 302,668ms 延遲時達到 18.9 IOPS 或 1.7GB/s 的峰值。 A300 的峰值約為 84,766K IOPS 或 5.71GB/s，延遲為 3.64ms，然後略有下降。
對於 64K 順序寫入性能，A800 以 8,103 IOPS 或 506.4MB/s 開始，延遲為 304.8μs。 該陣列在運行結束之前一直保持在 1 毫秒以下，或者大約 80K IOPS 或 5GB/s，然後以 80,536 IOPS 或 5.03GB/s 的峰值達到峰值，延遲為 3.1ms。 對於峰值性能，我們看到 A300 在 48,883 毫秒的延遲下達到 3.1 IOPS 或 4.8GB/s。
我們的下一批基準是我們的 SQL 測試。 在 SQL 中，A800 以 138,007 IOPS 開始，延遲為 255.2 微秒，延遲為亞毫秒，直到大約 650K IOPS，在延遲為 697,603 毫秒時達到 1.5 IOPS 的峰值。 相比之下，A300 的峰值為 488,488 IOPS，延遲為 2.1 毫秒。
在 SQL 90-10 中，A800 以 70,867 IOPS 開始，延遲為 277.3 微秒，並保持在 1 毫秒以下，直到大約 640K IOPS，然後以 730,567 IOPS 和 1.4 毫秒的延遲達到峰值。 另一方面，A300 的峰值性能為 416,370 IOPS，延遲為 2.46 毫秒
對於 SQL 80-20，A800 以 56,391 IOPS 開始，延遲為 256.6 微秒，延遲為亞毫秒，直到約 480K IOPS。 A800 的峰值為 623,557 IOPS，延遲為 1.6 毫秒。 這大約是 A300 的 360,642 IOPS 的兩倍，延遲為 2.82 毫秒。
繼續我們的 Oracle 工作負載，我們看到 A800 從 64,020 IOPS 開始，延遲為 254.7 微秒，一直保持在 1 毫秒以下，直到大約 470K IOPS。 A800 在 656,438 毫秒的延遲時達到 1.9 IOPS 的峰值。 同樣，A800 的性能幾乎是 A300 得分 340,391 IOPS 的兩倍，延遲為 3.6 毫秒。
對於 Oracle 90-10，A800 以 75,710 IOPS 和 242.5μs 延遲啟動。 該陣列始終管理亞毫秒級延遲性能，在 759,117 微秒延遲時達到 839.2 IOPS 的峰值——比 A300 的峰值 417,869 IOPS 和 1.53 毫秒的延遲高出一大步。
借助 Oracle 80-20，A800 保持了亞毫秒級延遲性能，從 65,505 IOPS 和 254.5μs 延遲到 666,556 IOPS，943.1μs 峰值。 A300 的峰值為 362,499 IOPS，延遲為 1.62 毫秒。
接下來我們切換到我們的 VDI 克隆測試，完整和鏈接。 對於 VDI 完整克隆啟動，A800 在達到約 535K IOPS 之前具有亞毫秒級延遲，並以 579,786 毫秒的延遲達到 1.8 IOPS 的峰值。 A300 的峰值為 300,128 IOPS，延遲為 3.46 毫秒。
使用 VDI 完整克隆初始登錄時，A800 保持在 1 毫秒以下，直到大約 200K IOPS，並以 254,888 毫秒的延遲達到 3.5 IOPS 的峰值。 這與 A300 形成鮮明對比，峰值為 123,984 IOPS，延遲為 7.26 毫秒。
VDI FC Monday Login 顯示 A800 具有亞毫秒延遲性能，直到大約 180K IOPS 和 228,346 IOPS 的峰值，延遲為 2.2 毫秒。 與延遲為 300 毫秒的 A131,628 的 3.89 IOPS 相比，這是一個巨大的飛躍。
切換到 VDI 鏈接克隆 (LC)，在啟動測試中，A800 的延遲幾乎始終低於 1 毫秒，在大約 1K IOPS 時突破了 440 毫秒的障礙，並以 460,366 毫秒的延遲達到 1.1 IOPS 的峰值。 A300 的峰值為 215,621 IOPS，延遲為 2.28 毫秒。
在 VDI LC 初始登錄中，A800 再次出現長時間的亞毫秒延遲，直到大約 158K IOPS，峰值為 166,224 IOPS，延遲為 1.5 毫秒。 相比之下，A300 的峰值為 95,296 IOPS，延遲為 2.68 毫秒。
最後，我們查看 VDI LC Monday Login，其中 A800 以 15,287 IOPS 開始，延遲為 299.3μs。 該陣列保持在 1 毫秒以下，直到大約 130K IOPS，並以 164,684 毫秒的延遲達到 3.1 IOPS 的峰值。 A300 峰值為 94,722 IOPS，延遲為 5.4 毫秒
結論
NetApp AFF A800 是一款 4U 的全閃存存儲陣列，具有頂級性能。 A800 配備所有 NVMe 閃存，旨在滿足最苛刻的工作負載。 除了支持所有 NVMe（以及每個容量高達 15.3TB 的 NVMe SSD）外，AFF A800 還具有可選的 100GbE 連接，可在性能絕對必要時使用。 根據 NetApp 的說法，AFF A800 應該能夠以低於 1.4 微秒的延遲達到 500 萬次 IOPS。 與 A 系列中的其他 NetApp 陣列一樣，A800 由 ONTAP 提供支持。
為了提高性能，我們運行了由 SQL Server 和 Sysbench 組成的應用程序分析工作負載，以及 VDBench 工作負載。 對於我們的應用程序工作負載分析，A800 的事務性 SQL Server 得分總計為 12,835.5 TPS，平均延遲為 5 毫秒。 與 A300 的 12,628.7 TPS 和 8 毫秒的平均延遲相比，這是性能的一大進步。 使用 Sysbench，A800 為我們提供了 15,750.8VM 8TPS，22,170.9VM 16 TPS，44,149.8VM 32 TPS，16.3VM 的平均延遲為 8ms，23.1VM 為 16ms，23.2VM 為 32ms，最壞情況下的延遲為31.3VM 為 8ms，48.5VM 為 16ms，48.1VM 為 32ms。 在某些情況下，A800 能夠將 TPS 提高一倍，同時將延遲大約減半。
對於我們的 VDBench 工作負載，NetApp AFF A800 繼續表現出色。 亮點包括 1.2K 讀取 4 萬 IOPS、439K 寫入 4K IOPS、順序 18.9K 讀取 64GB/s 和 5.03K 寫入 64GB/s。 所有這些數字都是在 5 毫秒的延遲下達到的。 在我們的 SQL 測試中，該陣列在 SQL 698-731 中達到 90K IOPS，在 SQL 10-624 中達到 80K IOPS，在 SQL 20-800 中達到 656K IOPS。 在 Oracle 中，A90 達到 10K IOPS，而在 Oracle 80-20 和 Oracle 759-667 中，陣列始終具有亞毫秒級延遲，峰值分別為 800K IOPS 和 580K IOPS。 在我們的 VDI 克隆測試中，A460 能夠達到完整克隆 4.4K IOPS 和鏈接克隆 XNUMXK IOPS 的啟動分數。 我們所有測試中的最高峰值延遲僅為 XNUMX 毫秒。
與我們之前評測過的中端市場 ONTAP 系統一樣，NetApp 再次憑藉以企業為中心的 A800 脫穎而出。 性能配置文件非常強大，在 ONTAP 系列中處於領先地位。 如前所述，此測試是典型的光纖通道工作； 我們還沒有剝離 NVMeoF 配置中可用的內容，這應該很好玩。 在審查硬件時，有時會有一個瑣碎的擔憂，即較老的存儲供應商不像初創公司那樣快速和靈活，而且“遺留代碼”無法跟上步伐。 我們在 NetApp 產品組合的任何地方都沒有看到這些問題的跡象，而且，A800 以對企業實用的方式採用 NVMe 和 NVMeoF，而不會犧牲多年來 ONTAP 固有的數據保護和可用性功能。 NetApp 在 A800 中對 NVMe 有很好的處理，我們很高興看到這些學習如何在其他陣列中找到它們的方式。
