NetApp EF570 All-Flash Array Review

Vid den här tiden förra året introducerade NetApp flera nya erbjudanden i sin Big Data-analysportfölj. Bland de erbjudanden som tillkännagavs var företagets senaste all-flash array (AFA), NetApp EF570. EF570 är en mellanklass AFA som är designad för hög prestanda, hög tillgänglighet, enkelhet och ett starkt pris/prestanda-förhållande för ett 2U-system. 

Vid den här tiden förra året introducerade NetApp flera nya erbjudanden i sin Big Data-analysportfölj. Bland de erbjudanden som tillkännagavs var företagets senaste all-flash array (AFA), NetApp EF570. EF570 är en mellanklass AFA som är designad för hög prestanda, hög tillgänglighet, enkelhet och ett starkt pris/prestanda-förhållande för ett 2U-system. 

NetApp säger att EF570 har "extrem" prestanda, och även om vi inte är de för överdrift, citerar företaget några mycket imponerande siffror. NetApp uppger att arrayen kan träffa uppåt en miljon IOPS och en sekventiell bandbredd på 21 GB/s, allt med en latens på under 100 mikrosekunder. All denna prestanda är speciellt anpassad för miljöer med blandad arbetsbelastning, inklusive Big Data-analys. Utöver den utlovade prestandan stöder arrayen flera höghastighetsvärdgränssnitt inklusive 32 Gb Fibre Channel, 25 Gb iSCSI, 100 Gb InfiniBand, 12 Gb SAS och 100 Gb NVMe över InfiniBand. Detta kommer inte bara att hjälpa till att nå de angivna hastigheterna, det kommer också att hjälpa till att skydda investeringar i lagringsnätverk framåt.

Precis som flera andra NetApp-system är hög tillgänglighet en inbyggd aspekt; här är EF570 inte annorlunda. Arrayen har ingen enda felpunkt och kommer med helt redundanta I/O-vägar och automatiserad failover. Den kommer också med en rapporterad sex 9:or av tillgänglighet. Med dessa funktioner erbjuder EF570 också de vanliga misstänkta för datahantering inklusive ögonblicksbilder, volymkopiering och spegling. Samtidigt säkerställer SANtricity OS dataintegritet samtidigt som det skyddar från tyst datakorruption. Arrayen kan upptäcka och lösa de flesta problem genom bakgrundsövervakning och omfattande diagnostisk data och analys.

NetApp EF570 kommer i en modulär design och är lätt att skala. Ett 2U-system kan stödja upp till 367 TB kapacitet och att lägga till de fyra expansionshyllorna kan ge en total kapacitet på upp till 1.8 PB. Genom SANtricity GUI kan användare skala utan extra hanteringskomplexitet och få tillgång till sina data på mindre än 10 minuter. Denna enkla skala och höga kapacitet ger EF570 ett starkt förhållande mellan pris och prestanda. Möjligheten att skala till 1.8 PB gör också arrayen till ett attraktivt val som kan hjälpa till att undvika uppgraderingar av gaffeltruckar i framtiden.

Specifikationer för NetApp EF570

Design och bygga

Som sagt är EF570 en 2U AFA. Liksom de allra flesta NetApp-produkter (åtminstone de nyare), ser ramarna likadana ut med ett snyggt metallskydd och ventilation och NetApp-märke på vänster sida. Under ramen finns de tjugofyra 2.5-tumsenhetsfack som löper vertikalt över framsidan av arrayen. Den högra sidan av arrayen har NetApp-märke och den vänstra har knapparna och lysdioderna Power, Attention och Locate.

När man vänder sig till baksidan av enheten kan man tydligt se den höga tillgängligheten/redundanta designen. Arrayen är en spegelbild från vänster till höger. Botten är fylld med nätaggregat. Den övre halvan har de två kontrollerna. Regulatorerna konfigurerades med 32 Gb HICs med fyra portar (värdgränssnittskort), som utnyttjade två ASIC:er per kontroller. De inbyggda FC-portarna användes inte, vilket skulle ge en extra ASIC-väg per styrenhet. För våra tester använde vi en layout med bästa praxis för dubbla 32Gb-switchar.

Verksamhetsledningen

I våra tidigare NetApp-recensioner tittade vi på företagets ONTAP-operativsystem. Även om ONTAP är det mer populära och välkända operativsystemet, drivs EF-serien faktiskt av SANtricity OS. 

SANtricitys startskärm ger administratörer en layout av hela systemet. Man kan enkelt se prestanda (som kan delas upp till IOPS, MB/s och CPU eller ses efter olika tidsramar), kapacitet, såväl som lagringshierarki. Längs den vänstra sidan av skärmen finns flikar: Hem, Lagring, Hårdvara, Inställningar och Support. 

Under huvudfliken Storage finns det flera alternativ att välja mellan för att gå ner i vad ens lagring gör, inklusive: Pooler och volymgrupper, Volymer, Värdar, Prestanda, Snapshots, Asynkron spegling och Synchronous Mirroring. 

Genom att klicka på Pooler och volymgrupper kan vi titta på antingen all kapacitet eller reserverad kapacitet. Därifrån kan användare skapa nya pooler eller volymgrupper, lägga till kapacitet till dem eller redigera dem. 

Under Volym kan användare skapa eller redigera volymer samt få information om aktuella volymer såsom namn, status, om tunn provisionering är aktiverad, var de är tilldelade, hur många LUN, vilken pool eller volymgrupp de tillhör, och kapaciteten.

Prestanda är något som alltid är intressant för oss, och för administratörer som vill veta hur bra deras lagring presterar kan de kolla igenom prestandasektionen under lagring. Här ges användare några olika prestandavyer baserat på vissa mätvärden och det kan ses som en logisk vy, fysisk vy eller applikations- och arbetsbelastningsvy. Det finns också ett alternativ att borra ner från hela AFA till pooler och volymgrupper eller bara volymer. 

När du borrar ner i fysisk prestanda finns det ett alternativ att se prestandan på kontroller, kanaler eller enheter. 

Fliken Maskinvara visar, som förväntat, hårdvara och hur den körs. På framsidan kan användare kolla på enheterna för att se om allt fungerar normalt och om något behöver bytas ut (indikeras med färg, blått är normalt). 

Den bakre delen av hårdvaran är liknande, bara denna gång är kontroller och PSU:er färgkodade för att säkerställa att de fungerar korrekt eller behöver åtgärdas. 

Fliken Inställningar visar allmän information om systemet och iSCSI-inställningar eller andra inställningar som användare vill lägga till. Det finns också olika konfigurationsalternativ under den här fliken också. 

Prestation

Analys av applikationens arbetsbelastning

Benchmarks för applikationsarbetsbelastningen för NetApp EF570 består av MySQL OLTP-prestanda via SysBench och Microsoft SQL Server OLTP-prestanda med en simulerad TPC-C-arbetsbelastning. I varje scenario hade vi arrayen konfigurerad med 26 Toshiba PX04SV SAS 3.0 SSD:er och konfigurerad i två 12-enheters RAID10-diskgrupper, en fäst vid varje styrenhet. Detta lämnade 2 SSD:er som reservdelar. Två 5TB-volymer skapades sedan, en per diskgrupp. I vår testmiljö skapade detta en balanserad belastning för våra SQL- och Sysbench-arbetsbelastningar.

SQL Server prestanda

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 Quests 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 fyra 570 XNUMX-skaliga databaser jämnt över NetApp EFXNUMX (två virtuella datorer per kontroller).

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

SQL Server OLTP Benchmark Factory LoadGen Utrustning

• Dell EMC PowerEdge R740xd Virtualiserat SQL 4-nodskluster
  • 8 Intel Xeon Gold 6130 CPU för 269GHz i kluster (två per nod, 2.1GHz, 16-kärnor, 22MB cache)
  • 1 TB RAM (256 GB per nod, 16 GB x 16 DDR4, 128 GB per CPU)
  • 4 x Emulex 16GB dual-port FC HBA
  • 4 x Mellanox ConnectX-4 rNDC 25GbE NIC med dubbla portar
  • VMware ESXi vSphere 6.5 / Enterprise Plus 8-CPU

För SQL Server presterade NetApp EF570 på ett snabbt och konsekvent sätt, och mätte 3,160 12,642.245 TPS och förändringar över alla fyra virtuella datorer, vilket gav oss ett sammanlagt XNUMX XNUMX XNUMX TPS.

Om man tittar på latens, presterade alla virtuella datorer med en konsekvent 3ms svarstid.

Sysbench Performance

Varje sysbench VM är konfigurerad med tre vDisks, en för start (~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. Lastgenerationssystem är Dell R740xd-servrar.

Dell PowerEdge R740xd Virtualiserat MySQL 4-nodkluster

• 8 Intel Xeon Gold 6130 CPU för 269GHz i kluster (två per nod, 2.1GHz, 16-kärnor, 22MB cache)
• 1 TB RAM (256 GB per nod, 16 GB x 16 DDR4, 128 GB per CPU)
• 4 x Emulex 16GB dual-port FC HBA
• 4 x Mellanox ConnectX-4 rNDC 25GbE NIC med dubbla portar
• VMware ESXi vSphere 6.5 / Enterprise Plus 8-CPU

Sysbench-testkonfiguration (per virtuell dator)

• CentOS 6.3 64-bitars
• Lagringsutrymme: 1 TB, 800 GB använt
• 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 virtuella datorer. Syftet med dessa tester är att visa hur väl en given array presterar under en arbetsbelastning med måttlig till full mättnad. Inte alla recensioner slår våra strumpor av när det kommer till prestandaresultat, men NetApp EF570 gjorde just det. Vid en 8VM belastning mätte EF570 22,951 16 TPS, vilket överträffade de flesta arrayer på sin topp. EF570 plockade upp till 39,635VM och visade inga tecken på att sakta ner, och ökade till otroliga 32 570 TPS. På 57,347VM var dock EF8 bara ett monster, som nådde en topp på 570 XNUMX TPS och slutade inte på grund av brist på I/O, utan fullkomligt mättade CPU:erna över våra XNUMX värdar. Att säga att EFXNUMX är snabb är milt uttryckt; det är ett monster.

Om vi ​​tittar på genomsnittlig latens över våra 8, 16 och 32VM arbetsbelastningar, fortsatte NetApp EF570 att imponera på oss. Vid 8 VMs mätte den låga 11.15 ms, vilket ökade när belastningen ökade till 16 VMs till bara 12.98 ms. Vid 32vms, där de flesta arrayer börjar tappa kraft, tog EF570 upp till bara 17.98ms.

När man tittar på 99:e percentilens latens började NetApp EF570:s verkliga färger lysa. Inte bara kunde den upprätthålla stark genomströmning, den gjorde det med mycket låg topplatens. Detta visar dig att även när denna array krossar I/O så gör den det på ett förutsägbart och konsekvent sätt.

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. På arraysidan använder vi vårt kluster av Dell PowerEdge R740xd-servrar:

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 % skrivning, 8 trådar, 0-120 % iorate
• Syntetisk databas: SQL och Oracle
• VDI Full Clone och Linked Clone Traces

I 4K topp läsprestanda startade EF570 med sub-millisekunders latens och hoppade kort över 1ms runt 510K IOPS och sjönk tillbaka under 1ms till nästan 1 miljon IOPS. Arrayen nådde en topp på cirka 1.03 miljoner IOPS och en latens på 2ms innan några fall av.

För slumpmässig skrivprestanda i 4K nådde EF570 drygt 200K IOPS innan den bröt 1ms. EF570 fortsatte att nå sin topp på cirka 223K IOPS med en latens på 4ms innan den sjönk något.

När EF64 bytte till 570 190 sekventiell arbetsbelastning, hade EF12 sub-millisekunders latensprestanda till cirka 247,692 15.5 IOPS eller 2.1 GB/s innan den nådde en topp på XNUMX XNUMX IOPS eller XNUMX GB/s med en latens på XNUMX ms.

För 64K-skrivning hade AFA sub-millisekunders latens till nära slutet eller 80K IOPS (5GB/s). Arrayen nådde en topp på 80,675 5.04 IOPS eller 3.2 GB/s med en latens på XNUMX ms.

När vi går vidare till våra SQL-arbetsbelastningar kunde EF570 nå en topp på 1,029,910 818 XNUMX IOPS med en latens på XNUMX μs.

För SQL90-10 nådde arrayen en topp på 876,833 957 IOPS med en latens på XNUMX μs.

SQL 80-20 var det första SQL-testet som gick över 1 ms nära topp, med en toppprestanda på 740,691 1.2 IOPS och en latens på XNUMX ms.

Nästa steg var våra Oracle-arbetsbelastningar. Återigen gick EF570 över 1 ms nära toppen med en toppprestanda på 721,615 1.35 IOPS och en latens på XNUMX ms. 

Oracle 90-10 hade under millisekunders latensprestanda genomgående, med en topppoäng på 875,567 675 IOPS och en latens på XNUMX μs.

Oracle 80-20 fortsatte med latensprestanda på under millisekunder med en topppoäng på 738,238 808 IOPS och en latens på XNUMXμs.

Därefter bytte vi till vårt VDI-klontest, Full och Linked. För VDI Full Clone Boot nådde EF570 ungefär 835K IOPS under 1 ms och nådde en topp på 841,945 1.2 IOPS med en latens på XNUMX ms. 

Med VDI FC Initial Login tog EF570 sig till 250K IOPS innan den bröt 1ms. Den nådde sin topp på 262,141 3.3 IOPS med en latens på XNUMX ms.

För VDI FC Monday Login hade EF570 sub-millisekunders latens fram till cirka 300K IOPS, som fortsatte att nå en topp på 331,146 1.5 IOPS med en latens på XNUMXms.

För VDI LC Boot hade EF570 sub-millisekunders latens genomgående med en topppoäng på 519,975 980 IOPS och en latens på XNUMXμs.

VDI LC Initial Login, återigen, såg latensen förbli under 1ms med en topppoäng på 269,995 944 IOPS med en latens på XNUMXμs.

För VDI LC Monday Login kunde EF570 upprätthålla en latens under 1 ms till ungefär 270 299,663 IOPS och nådde en topp på 1.7 XNUMX IOPS med en latens på XNUMX ms. 

Slutsats

NetApp EF570 är en 2U all-blixt array riktad mot mellanregistret. EF570 kommer med en modulär design som gör den mycket tillgänglig och gör den lätt att skala. En mycket intressant aspekt av arrayen är dess prestanda. NetApp uppger att EF570 kan nå upp till en miljon IOPS och upp till 21 GB/s sekventiell bandbredd. Företaget fortsätter med att säga att allt detta kan göras på mindre än 100μs. Denna höga prestanda, i kombination med dess höga tillgänglighet och enkelhet i både hantering och skalning, gör den till ett attraktivt alternativ när det ses genom pris-till-prestanda-objektivet.

När man tittar på applikationsprestanda sträcker sig NetApp EF570 från utmärkt prestanda till att sätta nya rekord för vårt labb. SQL Server-prestanda visade att EF570 var kapabel till mycket snäva och konsekventa prestanda, och mätte 3 ms över våra fyra virtuella SQL-datorer, mätt av Benchmark Factory. I vårt skalade Sysbench-riktmärke fick EF570 så höga poäng att vi mättade vårt beräkningskluster innan arrayen fick slut på tillgänglig I/O. Vid 8VM mätte vi 22.9K TPS, eller ungefär där de flesta flash-arrayer vi har testat börjar ta slut. Vid 16VM:er tryckte EF570 till 39.6K TPS, vilket toppade det tidigare höga rekordet i vårt Sysbench-test mätt på RAID0 NVMe-oF-blixtarrayen. Vid 32VM nådde vi toppen av vårt testkluster med ett rekordstort resultat på 57.3K TPS. För alla dessa var den genomsnittliga latensen och 99:e percentilens latens låg och smörig. Det behöver inte sägas att vi var imponerade.

I våra VDBench-resultat visade EF570 en stark visning och slog 1 miljon IOPS på några få riktmärken inklusive 4K-läsning (1.03 miljoner med endast 2ms latens) och SQL (1,029,910 818 570 IOPS med endast 15.5μs). På den sekventiella sidan av saken kunde EF5.04 nå 2.1 GB/s läsning och 3.2 GB/s skrivtid med 90 ms respektive 10 ms latens. Arrayen hade några andra nummer med hög prestanda/låg latens som var värda att anropa. I SQL 877-957 träffade den 80K IOPS (20μs), på SQL 741-1.2 träffade den 722K IOPS (1.35ms), i Oracle såg vi 90K IOPS (10ms), på Oracle 876-675 registrerade vi 80K IOPS (20μs), för Oracle 738-808 noterade vi 842K IOPS (1.2μs), för VDI FC Boot spelade vi in ​​520K IOPS (980ms), och för VDI LC Boot såg vi XNUMXK IOPS (XNUMXμs).

NetApp riktar EF570 till mellanmarknaden, men det är till stor del på grund av skalbarhet. Vanligtvis när vi tänker mellanmarknaden frammanar termen visioner om prisvärde och prestanda som är "tillräckligt bra" för att få jobbet gjort. Låt oss vara tydliga här; EF570 kan ha ett mellanpris, men den erbjuder en prestandaprofil av företagsklass som blåser bort allt vi har sett i labbet. Vidare, i några av testerna (32VM Sysbench), toppade vi vårt datorkluster, vilket betyder att det förmodligen finns ännu mer prestanda att hämta. När det gäller krävande blocklagringsarbetsbelastningar som analys och framväxande användningsfall i AI-stil där latens och tillgänglighet betyder dollar, är det viktigt att ha ett lagringsverktyg som är designat för jobbet. NetApp EF570 är en perfekt lösning för dessa arbetsbelastningar, som gör att de krävande databaserna blir underkastade för att leverera intelligens på det snabbaste sättet vi har sett hittills.

NetApp Flash Arrays

Diskutera denna recension

Anmäl dig till StorageReviews nyhetsbrev