NetApp AFF A800 recension

AFF A800 är den förstklassiga ONTAP all-flash-lagringsuppsättningen från NetApp, som vid lanseringen erbjöd en branschförst, end-to-end NVMe/FC över 32 Gb FC, såväl som 100 GbE-anslutning. Hittills har vi arbetat oss igenom AFF-uppställningen med full fart, med början med den potenta A200 (har sedan dess ersatts av A220) samt A300. Båda enheterna vi tidigare recenserade vann Editor's Choice-priser. Idag kommer vi att titta på det NVMe-baserade kraftpaketet A800 som erbjuder samma ONTAP-fördelar som de tidigare granskade modellerna, såväl som exponentiellt snabbare prestanda och lägre latens. Även om den här första recensionen fokuserar på systemprestanda över Fibre Channel, kommer efterföljande artiklar att dyka in i A800:s end-to-end NVMe over Fabrics (NVMeoF)-stöd.

AFF A800 är den förstklassiga ONTAP all-flash-lagringsuppsättningen från NetApp, som vid lanseringen erbjöd en branschförst, end-to-end NVMe/FC över 32 Gb FC, såväl som 100 GbE-anslutning. Hittills har vi arbetat oss igenom AFF-uppställningen med full fart, med början med den potenta A200 (har sedan dess ersatts av A220) samt A300. Båda enheterna vi tidigare recenserade vann Editor's Choice-priser. Idag kommer vi att titta på det NVMe-baserade kraftpaketet A800 som erbjuder samma ONTAP-fördelar som de tidigare granskade modellerna, såväl som exponentiellt snabbare prestanda och lägre latens. Även om den här första recensionen fokuserar på systemprestanda över Fibre Channel, kommer efterföljande artiklar att dyka in i A800:s end-to-end NVMe over Fabrics (NVMeoF)-stöd.

Till skillnad från A200 och A300 som byggdes för olika segment av mellanregistermarknaden, är A800 designad för de arbetsbelastningar som kräver mest prestanda (som AI och Deep Leaning), samtidigt som den inkluderar den robusta uppsättningen företagsdatatjänster som ONTAP är känd för. För tydlighetens skull har NetApp en serie riktigt snabba lagringar i EF all-flash-familjen, som mellanregistret EF570 vi granskade tidigare. Tillbaka till A800 hävdar NetApp att systemet kan nå 1.3 miljoner IOPS vid under 500 μs latens och genomströmning på upp till 34 GB/s med ett HA-par. I skala betyder detta att ett NAS-kluster kan leverera upp till 11.4M IOPS med 1ms latens och 300 GB/s genomströmning. Ett SAN-kluster kan leverera upp till 7.8 M IOPS vid 500 µs latens och 204 GB/s genomströmning.

Liksom resten av AFF A-seriens system kan NVMe A800 skala till 24 (12 HA-par) 4U dubbelkontrollernoder i ett kluster i NAS-konfiguration. Eftersom detta är ett NVMe-baserat system finns det en liten nyans när det kommer till drivskalning. Mellanregistret A300, till exempel, stöder 4608 enheter där A800 toppar på 2880. Även om det sannolikt inte kommer att vara ett funktionellt problem när det distribueras, lyfter vi detta bara för att indikera att NVMe-baserade system har andra tekniska utmaningar när man överväger JBOD-expansionshyllor än SAS-baserade system, så vi kan inte bara anta att allt blir större när du går uppåt i produktlinjen. I en SAN-konfiguration skalas NVMe A800 till 12 noder (6 HA-par) med stöd för 1,440 15.3 enheter. Som sagt, om användare använder 2.5 TB NVMe SSD:er kan de skala upp till 4 PB i ett 5U-fotavtryck. Med dataeffektivitet aktiverad (förutsatt att 1:800) stöder A315 över 24PB i ett 160-nods NAS-kluster och XNUMXTB i ett SAN-kluster.

Medan NetApp har aktiverat front-end NVMe-stöd i andra AFF-system, erbjuder A800 vad som kallas end-to-end NVMe-stöd. Som nämnts kommer vi inte att dyka hela vägen in i vad detta betyder i den här recensionen. Det räcker med att säga att A800 är den första all-flash NVMe-arrayen för att åstadkomma detta. Vad detta innebär i praktiken är att organisationer kan dra fördel av den framväxande vågen av NVMeoF-funktioner idag, samtidigt som de servar sina mer traditionella arbetsbelastningar över FC. Tidigare var organisationer som ville dra fördel av NVMeoF i allmänhet förvisade till "vetenskapsprojekt" typer av distributioner som även om de var snabba, hade begränsningar när det gällde skalning och datatjänster. NetApps implementering här åtgärdar dessa brister, samtidigt som det ger stöd för standardanslutningsalternativen i både FC och Ethernet.

Naturligtvis kan vi inte prata A800 utan att lyfta fram molnanslutningen och NetApp Data Fabric. ONTAP inneboende är en djup uppsättning av anslutningar till ledande molnleverantörer, vilket gör det möjligt för kunder att placera sin data där det är mest meningsfullt, vare sig det är lokalt på A800 eller någon annanstans. NetApp stöder moln- och multimolnanslutningar med Amazon Web Services, Microsoft Azure, Google Cloud Platform och andra. Brett molnstöd låter NetApp-kunder ha den flexibilitet de behöver när de hanterar sitt dataavtryck och smidigheten att flytta runt data efter behov för att dra fördel av molnekonomi, nya funktioner eller formtyper och så vidare.

Vår speciella konstruktion består av en A800 med 24 x 1.92TB NVMe SSD-enheter med två fyraportars 32Gb FC-portar anslutna per kontrollenhet (totalt 8 portar) med ONTAP 9.5RC1 installerad.

Specifikationer för NetApp A800

Design och bygga

NetApp AFF A800 är en 4U-array som har ett mycket liknande utseende som resten i AFF-serien. Under den snygga ramen som innehåller ventilation och NetApp-märke finns två rader med blå 2.5-tumsenhetsfack för SSD:erna.

Om man tittar på själva NVMe-enheterna stöder NetApp ett brett utbud av kapacitetsalternativ inklusive 1.9 TB, 3.8 TB, 7.6 TB och 15.3 TB SSD-enheter. När detta skrivs skickar NetApp alla dessa enheter som självkryptering (SED) med AES-256-kryptering. Dessutom, för system som initierats med ONTAP 9.4, är snabb nollställning av enheten aktiverad.

Det finns två kontroller som vänds runt på baksidan av enheten: en staplad ovanpå den andra som en spegelbild. Vår konfiguration inkluderar fyra olika stilar av gränssnitt för anslutning. Dessa fyra kort finns längst till höger och på mitten av PCIe-kortplatserna. De inkluderar ett fyrports 32 Gb FC-kort (överst till vänster), ett nätverkskort med dubbla portar 25 GbE (nedre till vänster), ett nätverkskort med dubbla portar 100 GbE (överst till höger) och ett nätverkskort med fyrportar 10 GbE (nedre till höger).

Genom att ta bort en av kontrollerna kan vi se anslutningarna till resten av enheten, såväl som fläktarna som kantar framsidan av kontrollenheten.

Vänd runt till den bakre styrenheten, den vänstra sidan har dubbla redundanta PSU:er för varje styrenhet såväl som HA-interconnect-portarna och kluster-interconnect-portarna. Den högra botten av varje styrenhet har också 1HA och klusterportar. Huvuddelen av resten tas upp med PCIe-platser (fem) som kan fyllas med nätverksportar 100GbE, 10GbE eller 32Gb Fiberkanal eller någon kombination av ovanstående som i vår konfiguration. I mitten nedtill finns hanteringsportarna och två USB 3.0-portar.

Regulatorn är otroligt lätt att öppna, vilket gör den mycket användbar.

Vi kan se de två processorerna, 20 DIMM-platser (fyllda med 20 x 32 GB DIMM-minne) och de två NVDIMM-platserna. PCIe-nätverkets AIC:er är också lättillgängliga härifrån.

Verksamhetsledningen

ONTAP GUI har kommit långt under åren, från ett Java-aktiverat GUI i 8.2 och äldre dagar till den moderna och väldesignade webdrivna ONTAP 9.5. NetApp har gjort betydande förbättringar av GUI, vilket gör det mer och mer användbart för mer än bara dagliga administrationsfunktioner.

Instrumentbräda:

Efter att ha loggat in möts du av instrumentpanelen som ger dig en snabb genomgång av vad som händer med systemet. Instrumentpanelen är ganska enkel vad du kan se. Var och en av widgetarna möjliggör snabba blickar på varningar, prestanda, kapacitet, effektivitet och skydd. För mer detaljerad visning och långsiktig trend rekommenderar vi att du använder NetApps (gratis) OnCommand Unified Manager för ONTAP-mätvärden.

Molnnivå:

Med tillägget av NetApp Cloud-alternativet Fabric Pool gör GUI det enkelt att ansluta till publika moln, inklusive NDAS, såväl som lokalt StorageGRID.

SVM:er:

Från den här fliken kan du skapa, redigera, ta bort och starta/stoppa alla dataprotokoll SVM på ONTAP-klustret samt redigera olika inställningar.

Aggregat och lagringspooler:

Med flikarna Aggregate och Storage Pool kan du enkelt skapa och hantera Aggregates och Storage Pools.

Volymer och LUN:

Volym- och LUN-administratörssidan ger dig ett brett utbud av att skapa och administrera FlexVols, FlexGroups och LUNs, och även igroups och mappningar för var och en av SVM:erna.

QoS:

QoS har kommit långt på ONTAP genom åren, eftersom du nu kan konfigurera ett tak och golv för varje arbetsbelastning, samt ha dem konfigurerade för att anpassa sig till dina förändrade arbetsbelastningar. QoS kan appliceras på olika objekt inuti ONTAP som volymer, filer och LUN samt några andra objekt.

Nätverkskonfiguration:

All grundläggande nätverkskonfiguration och administration finns i GUI: IP Spaces, Broadcast Domains, Ports, LIFs, FC och nu NVMe.

Peering:

Fram till de senaste versionerna av ONTAP behövde du skapa peering-relationer enbart via CLI; men nu kan du skapa Cluster-peers och även SVM-peers i GUI också. När du väl har konfigurerat peering kan du till och med skapa en SnapMirror-relation direkt i guiden för att skapa volym.

Klusteruppdateringar:

ONTAP-uppgraderingar blir enklare och lättare att gå igenom. En liten men mycket användbar funktion som lagts till i 9.4 gör det ännu enklare att göra ONTAP-uppdateringar. Vi älskar verkligen kommandoraden, men detta gör det väldigt enkelt att arbeta med kunder för att uppgradera sina filer. Inga fler http/ftp-servrar att bråka med; ladda bara upp .tgz-filen direkt och kör den automatiska klusteruppdateringen.

Prestation

För prestanda kommer vi att jämföra A800 med A300. Detta används för att visa hur väl prestanda hos NetApp AFF-modellerna skalar när du flyttar upp i familjen. I alla våra tester har vi datareduktionstjänster aktiverade, vilket innebär att inline dedupe och komprimering är aktiverade. Som vi har noterat i tidigare recensioner ger NetApp ONTAP fantastiska DR-funktioner med minimal overhead eller prestandapåverkan.

Konfigurationen av vår NetApp AFF A800 inkluderade 8 32Gb FC-portar med 24 1.92TB NVMe SSD installerade. Av de 24 1.92 TB SSD:er som distribueras i vår A800, delade vi upp dem i två RAID-DP-aggregat, med 11 SSD:er i bruk och en som hot-spare. Arrayen var ansluten via 32 Gb genom två Brocade G620-switchar, som sedan hade 16 16 Gb-länkar till våra Dell PowerEdge R740xd-servrar.

För våra syntetiska riktmärken som använder VDbench såväl som Sysbench, tillhandahåller vi 32 600 GB-volymer jämnt fördelade över både kontroller och diskgrupper. För SQL Server använde vi ytterligare fyra 1.1 TB volymer, två per kontroller för att hålla de virtuella datorerna som används för benchmarking. Efter att datareduktionen redovisats uppgick det totala fotavtrycket som användes under våra tester till knappt 50 % utnyttjande för varje aggregat.

SQL Server prestanda

StorageReviews Microsoft SQL Server OLTP-testprotokoll använder det aktuella utkastet till Transaction Processing Performance Councils Benchmark C (TPC-C), ett riktmärke för onlinetransaktionsbearbetning som simulerar de aktiviteter som finns i komplexa applikationsmiljöer. TPC-C-riktmärket kommer närmare än syntetiska prestandariktmärken att mäta prestandastyrkorna och flaskhalsarna hos lagringsinfrastruktur i databasmiljöer.

Varje SQL Server VM är konfigurerad med två vDisks: 100 GB volym för uppstart och en 500 GB volym för databasen och loggfiler. Ur ett systemresursperspektiv konfigurerade vi varje virtuell dator med 16 vCPU:er, 64 GB DRAM och utnyttjade LSI Logic SAS SCSI-kontrollern. Medan våra Sysbench-arbetsbelastningar som tidigare testats mättade plattformen i både lagrings-I/O och kapacitet, letar SQL-testet efter latensprestanda.

Det här testet använder SQL Server 2014 som körs på Windows Server 2012 R2 gäst-VM, och betonas av Dells Benchmark Factory for Databases. Medan vår traditionella användning av detta riktmärke har varit att testa stora 3,000 1,500-skaliga databaser på lokal eller delad lagring, fokuserar vi i denna iteration på att sprida ut fyra XNUMX XNUMX-skaliga databaser jämnt över våra servrar.

SQL Server-testkonfiguration (per virtuell dator)

• Windows Server 2012 R2
• Lagringsutrymme: 600 GB tilldelat, 500 GB använt
• SQL Server 2014
  • Databasstorlek: 1,500 XNUMX skala
  • Virtuell klientbelastning: 15,000 XNUMX
  • RAM-buffert: 48GB
• Testlängd: 3 timmar
  • 2.5 timmars förkonditionering
  • 30 minuters provperiod

För vår SQL Server-transaktionsprestanda hade A800 en sammanlagd poäng på 12,635.5 3,158.6 TPS med individuella virtuella datorer som kördes från 3,159.3 300 TPS till 12,628.7 200 TPS (en trevlig liten ökning jämfört med A12,583.8:s XNUMX XNUMX TPS och AXNUMX:s XNUMX XNUMX TPS och AXNUMX:s XNUMX TPS).

Om vi ​​tittar på SQL Servers genomsnittliga latens ser vi en större förbättring i A800 eftersom den sjönk till 5 ms sammanlagt och 5 ms på alla virtuella datorer (mycket bättre än A300:s 8 ms och A200:s 25 ms).

Sysbench MySQL Performance

Vårt första benchmark för lokala lagringsapplikationer består av en Percona MySQL OLTP-databas mätt via SysBench. Detta test mäter också genomsnittlig TPS (Transactions Per Second), genomsnittlig latens och genomsnittlig 99:e percentil latens.

Varje Sysbench VM är konfigurerad med tre vDisks: en för uppstart (~92GB), en med den förbyggda databasen (~447GB) och den tredje för databasen som testas (270GB). Ur ett systemresursperspektiv konfigurerade vi varje virtuell dator med 16 vCPU:er, 60 GB DRAM och utnyttjade LSI Logic SAS SCSI-kontrollern.

Sysbench-testkonfiguration (per virtuell dator)

• CentOS 6.3 64-bitars
• Percona XtraDB 5.5.30-rel30.1
  • Databastabeller: 100
  • Databasstorlek: 10,000,000 XNUMX XNUMX
  • Databastrådar: 32
  • RAM-buffert: 24GB
• Testlängd: 3 timmar
  • 2 timmar förkonditionering 32 trådar
  • 1 timme 32 trådar

För Sysbench testade vi flera uppsättningar virtuella datorer inklusive 8, 16 och 32, och vi körde Sysbench med både datareduktionen "På". A800 kunde nå 15,750.8 8 TPS för 22,170.9VM, 16 44,149.8 TPS för 32VM och 300 32 TPS för 22,313VM. Dessa är mycket högre än den tidigare, nästan en fördubbling av vad AXNUMX gjorde med XNUMXVM, XNUMX XNUMX TPS.

Med Sysbenchs genomsnittliga latens nådde A800 16.3ms för 8VM, 23.1ms för 16VM, och 23.2ms vid 32VM. Detta är mycket bättre än de mindre AFF-modellerna.

I vårt värsta scenario (99:e percentilen) latens, träffade A800 31.3 ms för 8VM, 48.5 ms för 16VM, 48.1ms för 32VM.

VDBench arbetsbelastningsanalys

När det gäller benchmarking av lagringsmatriser är applikationstestning bäst, och syntetiska tester kommer på andra plats. Även om det inte är en perfekt representation av faktiska arbetsbelastningar, hjälper syntetiska tester till baslagringsenheter med en repeterbarhetsfaktor som gör det enkelt att göra jämförelser mellan äpplen och äpplen mellan konkurrerande lösningar. Dessa arbetsbelastningar erbjuder en rad olika testprofiler som sträcker sig från "fyra hörn"-tester, vanliga tester av databasöverföringsstorlek, såväl som spårfångst från olika VDI-miljöer. Alla dessa tester utnyttjar den vanliga vdBench-arbetsbelastningsgeneratorn, med en skriptmotor för att automatisera och fånga resultat över ett stort beräkningstestkluster. Detta gör att vi kan upprepa samma arbetsbelastningar över ett brett utbud av lagringsenheter, inklusive flash-arrayer och individuella lagringsenheter.

profiler:

• 4K slumpmässig läsning: 100 % läsning, 128 trådar, 0-120 % iorat
• 4K Random Write: 100% Write, 64 trådar, 0-120% iorate
• 64K sekventiell läsning: 100 % läsning, 16 trådar, 0-120 % iorat
• 64K sekventiell skrivning: 100% skriv, 8 trådar, 0-120% iorate
• Syntetisk databas: SQL och Oracle
• VDI Full Clone och Linked Clone Traces

Från och med topp slumpmässig 4K-läsprestanda startade A800 vid 118,511 217.5 IOPS med en latens på 800 μs. A1 höll sig under 1.07 ms tills den nådde cirka 1,219.829 miljoner IOPS och nådde en topp på 3.3 300 635,342 IOPS med en latens på 6.4 ms. Detta var en markant skillnad jämfört med AXNUMX:s toppprestanda på XNUMX XNUMX IOPS med en latens på XNUMX ms.

Om man tittar på 4K-skrivprestanda, började A800 på 45,676 213.1 IOPS med en latens på 800μs. A410 hade en fördröjningsprestanda på under millisekunder fram till cirka 439 4.4 IOPS och nådde en topp på cirka 300 208,820 IOPS med 9.72 ms latens innan den tappade några. Däremot hade AXNUMX en toppprestanda på XNUMX XNUMX IOPS med en latens på XNUMX ms.

När vi byter till sekventiella arbetsbelastningar tittar vi på topp 64K läsprestanda, och här började A800 på 29,589 1.85 IOPS eller 166.1 GB/s med en latens på 300μs. A300 hade en fördröjning på under millisekunder till cirka 18.5K IOPS eller 302,668 GB/s, och nådde en topp på 18.9 1.7 IOPS eller 300 GB/s vid 84,766 ms latens. A5.71 nådde en topp på cirka 3.64 XNUMX XNUMX IOPS eller XNUMX GB/s med XNUMX ms latens innan den tappade lite.

För 64K sekventiell skrivprestanda startade A800 vid 8,103 506.4 IOPS eller 304.8 MB/s med en latens på 1 μs. Arrayen stannade under 80 ms till slutet av körningen eller omkring 5K IOPS eller 80,536GB/s, och fortsatte med att nå en topp på 5.03 3.1 IOPS eller 300GB/s med en latens på 48,883ms. För toppprestanda såg vi A3.1 nå 4.8 XNUMX IOPS eller XNUMX GB/s med en latens på XNUMX ms.

Vår nästa grupp av riktmärken är våra SQL-tester. I SQL startade A800 vid 138,007 255.2 IOPS med 650 μs latens och hade submillisekunders latens till cirka 697,603 1.5 IOPS, och fortsatte med att nå en topp på 300 488,488 IOPS med en latens på 2.1 ms. Detta jämförs med AXNUMX:s topp på XNUMX XNUMX IOPS med en latens på XNUMX ms.

I SQL 90-10 startade A800 vid 70,867 277.3 IOPS med en latens på 1 μs och stannade under 640 ms till cirka 730,567 1.4 IOPS, och nådde en topp på 300 416,370 IOPS med en latens på 2.46 ms. AXNUMX, å andra sidan, hade en toppprestanda på XNUMX XNUMX IOPS med en latens på XNUMX ms

För SQL 80-20 startade A800 vid 56,391 256.6 IOPS med en latens på 480 μs med en fördröjning på under millisekunder upp till cirka 800 623,557 IOPS. A1.6 nådde sin topp på 300 360,642 IOPS med en latens på 2.82 ms. Detta var ungefär dubbelt så mycket som AXNUMX:s XNUMX XNUMX IOPS med XNUMXms latens.

När vi gick vidare till våra Oracle-arbetsbelastningar såg vi A800 starta på 64,020 254.7 IOPS med 1 μs latens, och stannade under 470 ms till cirka 800 656,438 IOPS. A1.9 nådde en topp på 800 300 IOPS med en latens på 340,391 ms. Återigen hade A3.6 nästan dubbelt så hög prestanda som AXNUMX:s poäng på XNUMX XNUMX IOPS med en latens på XNUMX ms.

Med Oracle 90-10 startade A800 vid 75,710 242.5 IOPS och 759,117 μs latens. Arrayen hanterade fördröjningsprestanda under millisekunder, och nådde en topp på 839.2 300 IOPS vid 417,869 μs latens – ett stort steg upp från A1.53:s topp på XNUMX XNUMX IOPS med en latens på XNUMX ms.

Med Oracle 80-20 bibehöll A800 submillisekunders latensprestanda från 65,505 254.5 IOPS vid 666,556 μs latens och toppade på 943.1 300 IOPS vid 362,499 μs. A1.62 nådde en topp på XNUMX XNUMX IOPS och en latens på XNUMX ms.

Därefter bytte vi till vårt VDI Clone Test, Full och Linked. För VDI Full Clone Boot hade A800 sub-millisekunders latens fram till cirka 535K IOPS och toppade på 579,786 1.8 IOPS med en latens på 300ms. A300,128 nådde en topp på 3.46 XNUMX IOPS med en latens på XNUMX ms.

Med VDI Full Clone Initial Login stannade A800 under 1 ms till cirka 200 254,888 IOPS och nådde en topp på 3.5 300 IOPS med 123,984 ms latens. Detta kontrasteras med A7.26 som toppar på XNUMX XNUMX IOPS med en latens på XNUMX ms.

VDI FC Monday Login visade A800 med sub-millisekunders latensprestanda fram till cirka 180K IOPS och en topp på 228,346 2.2 IOPS med en latens på 300ms. Detta var ett stort hopp över A131,628:s 3.89 XNUMX IOPS med en latens på XNUMX ms.

Vid byte till VDI Linked Clone (LC), i starttestet, hade A800 latens under 1ms nästan hela tiden, bröt 1ms-barriären vid cirka 440K IOPS och toppade på 460,366 1.1 IOPS med en latens på 300ms. A215,621 nådde en topp på 2.28 XNUMX IOPS med en latens på XNUMX ms.

I VDI LC Initial Login hade A800 återigen en lång serie under millisekunders latens fram till cirka 158K IOPS, med en topp på 166,224 1.5 IOPS vid en latens på 300 ms. Detta jämförs med A95,296:s topp på 2.68 XNUMX IOPS med en latens på XNUMXms.

Slutligen tittar vi på VDI LC Monday Login där A800 startade vid 15,287 299.3 IOPS med en latens på 1μs. Arrayen stannade under 130 ms till cirka 164,684 3.1 IOPS och nådde en topp på 300 94,722 IOPS med en latens på 5.4 ms. AXNUMX nådde en topp på XNUMX XNUMX IOPS med en latens på XNUMX ms

Slutsats 

NetApp AFF A800 är en 4U, all-flash-lagringsuppsättning som handlar om högsta prestanda. A800 kommer med all NVMe-blixt och är inriktad på de mest krävande arbetsbelastningarna. Förutom att stödja alla NVMe (och NVMe SSD-enheter upp till 15.3 TB i kapacitet vardera), har AFF A800 även valfri 100GbE-anslutning för när prestanda är ett absolut måste. Enligt NetApp ska AFF A800 kunna nå 1.4 miljoner IOPS med en latens under 500 μs. Som med andra NetApp-arrayer i A-serien, drivs A800 av ONTAP.

För prestanda körde vi både våra Application Analysis Workloads, bestående av SQL Server och Sysbench, samt våra VDBench-arbetsbelastningar. För vår analys av applikationsarbetsbelastningen hade A800 transaktionsbaserade SQL Server-poäng på 12,835.5 5 TPS sammanlagt och en genomsnittlig latens på 300 ms. Detta var ett stort steg upp i prestanda jämfört med A12,628.7:s 8 800 TPS och genomsnittliga latens på 15,750.8ms. Med Sysbench gav A8 oss 22,170.9 16 TPS för 44,149.8VM, 32 16.3 TPS för 8VM och 23.1 16 TPS för 23.2VM, med genomsnittliga latenser på 32 ms för 31.3VM, 8 ms för 48.5 ms för 16 ms fördröjningar och 48.1 ms för 32 ms fördröjningar och 800 ms för XNUMX ms fördröjning. XNUMXms för XNUMXVM, XNUMXms för XNUMXVM och XNUMXms för XNUMXVM. I vissa fall kunde AXNUMX fördubbla TPS samtidigt som latensen halverades ungefär.

För våra VDBench-arbetsbelastningar fortsatte NetApp AFF A800 att glänsa. Höjdpunkter inkluderar 1.2 miljoner IOPS i 4K-läsning, 439K IOPS i 4K-skrivning, 18.9GB/s i sekventiell 64K-läsning och 5.03GB/s i 64K-skrivning. Alla dessa siffror träffades med under 5ms latens. I vår SQL-testning träffade arrayen 698K IOPS, 731K IOPS i SQL 90-10 och 624K IOPS i SQL 80-20. I Oracle träffade A800 656K IOPS och i både Oracle 90-10 och Oracle 80-20 hade arrayen sub-millisekunders latens genomgående med topppoäng på 759K IOPS respektive 667K IOPS. I våra VDI Clone-tester kunde A800 uppnå startpoäng på 580K IOPS för Full Clone och 460K IOPS för Linked Clone. Den högsta topplatensen under alla våra tester var bara 4.4 ms.

Liksom ONTAP-systemen på mellanmarknaden som vi har granskat tidigare, slår NetApp återigen ut parken med den företagsinriktade A800. Prestandaprofilen är mycket stark och tar sin position i toppen av ONTAP-familjen. Som nämnts är denna testning trädgårdsvarianten Fibre Channel work; vi har ännu inte skalat tillbaka vad som är tillgängligt i NVMeoF-konfigurationen, vilket borde vara kul. När man tittar på hårdvara för granskning, finns det ibland en liten oro över att äldre lagringsleverantörer inte är lika snabba och flexibla eftersom startups och "äldre kod" inte kan hålla jämna steg. Vi ser inga tecken på dessa problem någonstans i NetApp-portföljen, och vidare omfattar A800 NVMe och NVMeoF på sätt som är praktiska för företaget utan att offra dataskydds- och tillgänglighetsfunktionerna som är inneboende i ONTAP i flera år. NetApp har ett bra grepp om NVMe i A800, vi är entusiastiska över att se hur dessa lärande hittar sin väg genom sina andra arrayer.

NetApp AFF-serien

Diskutera denna recension

Anmäl dig till StorageReviews nyhetsbrev