Förra månaden tillkännagav NetApp sin senaste all-flash-array i mellanregister med EF600. Medan EF600 är inriktad på samma marknad som EF570, det är inte en ersättning. Medan EF570 stöder NVMe, är EF600 end-to-end NVMe, vilket ger nya nivåer av flexibilitet och prestanda som inte tidigare setts i mellanregistret. Förutom prestanda och förhållandet mellan pris och prestanda, erbjuder EF600 en nivå av framtidssäkring som kommer att kunna möta morgondagens krav utan att behöva uppgradera gaffeltrucken.
Förra månaden tillkännagav NetApp sin senaste all-flash-array i mellanregister med EF600. Medan EF600 är inriktad på samma marknad som EF570, det är inte en ersättning. Medan EF570 stöder NVMe, är EF600 end-to-end NVMe, vilket ger nya nivåer av flexibilitet och prestanda som inte tidigare setts i mellanregistret. Förutom prestanda och förhållandet mellan pris och prestanda, erbjuder EF600 en nivå av framtidssäkring som kommer att kunna möta morgondagens krav utan att behöva uppgradera gaffeltrucken.
EF600 hoppar direkt till prestanda och hävdar 2 miljoner IOPS, upp till 44 GB/s för bandbredd och latens under 100 μs i vissa arbetsbelastningar. Denna prestandanivå öppnar arrayen för nya prestationskänsliga arbetsbelastningar som Oracle-databaser, realtidsanalys, utöver högpresterande parallell FS som BeeGFS och Spectrum Scale. Prestandaprofilen är till stor del härledd från EF600:s end-to-end NVMe-implementering. Detta tillåter också att arrayen stöder 100 Gb NVMe över InfiniBand, 100 Gb NVMe över RoCE och 32 Gb NVMe över FC, vilket kommer att vara viktigare på vägen. Utöver det kan EF600 packa upp till 367TB kapacitet i sin 2U-formfaktor
EF600 är byggd på fem generationer av NetApp-hårdvara som har visat sig vara tillförlitlig. Ur tillgänglighetssynpunkt erbjuder EF600 sex 9:or och automatisk failover med avancerad övervakning. Arrayen kan upptäcka ett problem innan en enhet misslyckas. I händelse av ett misslyckande kan arrayens Dynamic Disk Pool-teknik göra snabbare ombyggnader av hårddiskar än med RAID5 eller RAID6. Genom SANtricity (som är optimerad för flash) kan EF600 tillhandahålla flera dataskyddsalternativ såsom dynamisk kapacitet, dynamisk segmentstorleksmigrering, dynamisk RAID-nivåmigrering, och den kommer med icke-störande firmwareuppdateringar.
Specifikationer för NetApp AFA EF600
Formfaktor | 2U |
Systemminne | Upp till 128GB |
lagring | |
Maximal råkapacitet | 360TB |
Maximalt antal körningar | 24 |
Drivtyper som stöds | SSD 1.9 TB, 3.8 TB, 7.6 TB 3.8 TB FIPS 1.9 TB, 3.8 TB, 7.6 TB, 15.3 TB FDE |
Värd I/O-portar | Valfria I/O-portar för tillägg: 16 portar 32Gb FC 16 portar 32Gb NVMe över FC 8 portar 100Gb NVMe över InfiniBand 8 portar 100 Gb NVMe över RoCE Ethernet |
Systemhantering | SANtricity System Manager 11.60 (webbaserad, on-box) |
Prestation | |
IOPS | 2 miljoner |
Genomsnittlig latens | <100μs upp till 200,000 4 XNUMXK slumpmässig skriv-IOPS <100μs upp till 150,000 4 XNUMXK slumpmässigt avläst IOPS <250μs upp till 2,000,000 4 XNUMX XNUMXK slumpmässig läs IOPS |
Uthållig genomströmning | Upp till 44 GB/s |
Mått | |
Mått HxBxD | 3.43 x 9.02 x 17.6 i (8.7 x 48.3 x 44.7 cm) |
Vikt | 53.66lb (24.34kg) |
kVA | Typiskt: 0.979 Max: 1.128 |
Watt | Typiskt: 979.09 Max: 1,128 |
BTU | Typiskt: 3348 Max: 3,859.128 |
NetApp AFA EF600 Bygg och design
NetApp AFA EF600 är en 2U-array som kommer med standardutseendet för alla andra NetApp-arrayer: samma eleganta ram med NetApp-varumärke. Under ramen finns de 24 enhetsfack som löper vertikalt över framsidan av arrayen. Som tidigare noterat har NetApp bytt till en klarblå enhetsfack mer i linje med deras varumärke. Strömknappen och LED-indikatorerna finns till vänster på enheten.
När vi rör oss på baksidan av enheten ser vi spegelbilden av kontrollerna, den ena ovanpå den andra. Från vänster till höger finns nätaggregatet, en RJ45-port, USB 3.0-port, en hanteringsport, två nätverksportar, med den övre högra delen upptagen med FC-kontakter för NVMe över FC i detta fall.
NetApp AFA EF600 Management
Den nya EF600 stöder NetApp SANtricity OS 11.XX-programvarupaketen som inkluderar styrenhetens firmware, IOM firmware och SANtricity System Manager som används för att driva lagringsmatriserna i E-serien och EF-serien. SANtricity System Manager ger dig hjälp med att förenkla hanteringsarbetsflödet; det grafiska gränssnittet ser och känns fräscht, med ett enkelt on-box webbgränssnitt och enkel terminologi.
När du loggar in i Systemhanteraren är fliken Hem den första skärmen som visas; här kommer du att se instrumentpanelen i huvuddelen av GUI. Oavsett vilken flik du befinner dig på kommer du alltid att se de allmänna alternativen som finns tillgängliga i det övre högra hörnet av GUI; inklusive Inställningar, Hjälp, Logga ut och även den för närvarande inloggade användaren. Och på den vänstra panelen presenteras de primära systemflikarna, Hem, Lagring, Hårdvara, Inställningar och Support.
I instrumentpanelen kan du ta en titt på kritiska områden som sammanfattar lagringsarrayens tillstånd och tillstånd. På toppen visar meddelandeområdet dig systemstatus och komponenter; prestandaområdet, visar nyckelmått inklusive IOPS, MiB/S och CPU; kapacitetsområdet låter dig se tilldelad systemkapacitet; och lagringshierarkiområdet, ger dig en organiserad vy av de olika hårdvarukomponenterna och lagringsobjekten som hanteras av lagringsarrayen.
När du flyttar ner till fliken Lagring kommer du till de stora systemkategorierna, där konfigurationen av pooler och volymgrupper, volymer, värdar, prestanda och ögonblicksbilder visas. Några av dessa kommer att beskrivas i avsnitten nedan.
Sidan Pooler och volymgrupper visar de pooler och volymgrupper som har skapats i systemet; tillåter redigering av befintliga eller skapa nya från otilldelade enheter. Den här sidan visar också den totala kapaciteten, använd kapacitet, antalet enheter, RAID-konfiguration och annan statistik för dessa pooler eller volymgrupper.
Sidan Volymer visar de volymer som har konfigurerats. För varje volym visar sidan status, tilldelade värdar, pool eller volymgrupp de tillhör, rapporterad kapacitet, allokerad kapacitet och annan information. Detta är också området där du kan skapa eller redigera volymer, eller definiera arbetsbelastningar per applikation.
På sidan Prestanda finns flera sätt att övervaka lagringsarrayens prestanda. Från fliken Logisk vy kan du definiera de komponenter du vill övervaka, inklusive hela systemet, pool, volymgrupp eller enstaka volym. Du kan också övervaka andra nyckelområden i lagringsarrayen med hjälp av vyn Fysisk och Applications & Workloads. Prestandasidan kan också nås från startsidan genom att klicka på Visa prestandadetaljer.
Nästa flik, den hårdvara, är där du kan hantera de fysiska hyllorna, kontrollerna och enheterna som är installerade i lagringsarrayen. Den här sidan visar drivrutinerna som finns var som helst i lagringsarrayen; du kan också ändra denna vy för att visa drivrutiner per pool eller volymgrupp.
Genom att klicka på Controller-ikonen, under Controller Shelf-området, kan du välja och se Controller A- eller Controller B-inställningar. Från det här fönstret kan du flytta över olika flikar, Base, Cache, Host Interfaces, Drive Interfaces, Management Ports och DNS/NTP för att se detaljerad information om styrenheten.
Om du klickar på någon av de andra ikonerna, även under kontrollhyllan, visas fönstret Hyllkomponentinställningar. Det här området är bra för att övervaka status och inställningar relaterade till hyllkomponenterna, inklusive strömförsörjning, fläktar, temperatur, batterier och SFP-information.
På fliken Inställningar kan du konfigurera varningar för att meddela om det finns ett problem med lagringsarrayen. Det här området är också där du kan ändra systeminställningar som lagringsarraynamnet, autentisera användare, importera certifikat och utföra andra systemomfattande funktioner.
Åtkomsthantering är där du kan upprätta användarautentisering i systemet. Från det här området kan du hantera lösenord, lokala användare, konfigurera behörigheter, lägga till katalogserver och andra åtkomsthanteringskonfigurationer. Autentiseringsmetoder inkluderar RBAC (rollbaserad åtkomstkontroll), Directory Services och SAML (Security Assertion Markup Language) 2.0.
Den sista fliken, Support one, låter dig utföra diagnostik och samla in nyckelinformation som kan begäras av teknisk support; om du har problem med lagringsuppsättningen. Här kan du använda händelseloggen för att se historiska register över lagringsarrayen; även utföra systemuppdateringar.
När du rullar nedåt i Support Center-området kan du titta på egenskaperna för de översta lagringsarrayerna, såsom lagringsarrays världsomspännande identifierare chassits serienummer, antal hyllor, antal enheter, enhetstyp, antal kontroller, version av controllerns firmware, systemhanteringsversion och annan systeminformation.
NetApp AFA EF600-konfiguration
NetApp EF600 levererades med 24 NVMe SSD-enheter, som alla är 1.92 TB Samsung-modeller. När det gäller lagring specifikt utnyttjade vi RAID10 som ofta används av kunder som köper denna lagringsuppsättning. Med 24 enheter och en layout med två kontroller delar vi upp dem i två volymgrupper om tolv enheter. Från dessa två volymgrupper tilldelade vi en volym var för varje värd (två volymer per värd balanserade över båda kontrollerna) som var 100 GB stora. Med 12 beräkningsvärdar gav det oss en total arbetsdatauppsättningsstorlek på 24 x 100 GB eller 2.4 TB.
För back-end-anslutning stöder EF600 för närvarande endast NVMeoF, med FCP-stöd kommer. Systemet levererades med all 32Gb FC-optik och för denna recension uppdaterade vi våra 12 värdar till de senaste Emulex 32Gb dual-port HBA:erna. Medan vi traditionellt har testat AFA i VMware, körde vi för att jämföra NVMeoF-prestanda med en renmetallinstallation av SLES 12 SP4 på varje värd. Vi utnyttjade alla 16 32 Gb-portar (åtta per kontrollenhet) kopplade till vårt FC-tyg med dubbla switchar som drivs av Brocade G620-switchar. Sammantaget tillät detta en teoretisk bandbredd på 512 Gb från lagringsarrayen (64 GB/s) där vårt kluster med dubbla portar och 12 värdar stöder 768 Gb eller 96 GB/s topp.
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 % skrivning, 8 trådar, 0-120 % iorate
- Syntetisk databas: SQL och Oracle
- VDI Full Clone och Linked Clone Traces
Våra VDBench-tester sattes sida vid sida med EF600 på NVMeoF och EF570 på FC. Med slumpmässig 4K-läsning startade EF600 vid 206,592 192.7 med en latens på 1 μs och stannade under 2,082,389 ms tills den når cirka 2,082,693 1.4 570 IOPS; den nådde en topp på 103,330 184 570 med en latens på 1 ms. EF929,562 startade på 1,031,613 2.5 med en latens på XNUMXμs. EFXNUMX spikar två gånger, och efter den första toppen stannade den under XNUMX ms tills den når XNUMX XNUMX IOPS, sedan når den maximalt XNUMX XNUMX XNUMX IOPS med en latens på XNUMX ms.
Om man tittar på 4K-skrivprestanda började båda delsystemen igen med ultralåg latens, under 100 μs. EF600 presterade väl under 1 ms till cirka 640,171 570 IOPS, där arrayen också nådde sin topp. Detta var en markant skillnad jämfört med EF222,416:s toppprestanda på 4.7 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 startade EF600 under 500μs vid 128,713 4 IOPS eller 643,152GB/s och toppade på 40.2 458 IOPS eller 570GB/s med 500μs latens; visar en stadig latens över den totala prestandan. EF1 startade också under 202,776 μs och stannade under 12.67 ms tills den träffade 247,692 15.48 IOPS eller 2 GB/s, och sedan nådde den snabbt en topp på XNUMX XNUMX IOPS eller XNUMX GB/s med en latens på XNUMX ms.
I 64K-skrivning startade båda arrayerna med sub-millisekunders latens under 250μs och höll en stadig latens precis innan de nådde sin toppprestanda. EF600 nådde en topp på 141,859 8.87 IOPS eller 1.3 GB/s med en latens på 570 ms. EF80,675-prestandan nådde en topp på 5 3.2 eller XNUMX GB/s vid XNUMX ms latens.
Vår nästa uppsättning tester är våra SQL-arbetsbelastningar: SQL, SQL 90-10 och SQL 80-20. I SQL startade båda arrayerna under 200μs och stannade under 1ms även efter att ha nått toppprestanda. Med EF600 såg vi en topp på 1,880,526 398 570 IOPS vid 1,029,910 μs latens. Och EF818 hade en topp på XNUMX XNUMX XNUMX IOPS med en latens på XNUMXμs.
Med SQL 90-10 såg vi båda arrayerna startade och höll prestanda under 1 ms latens. EF600 nådde en topp på 1,784,866 387 570 IOPS med en latens på 600 μs, medan EF875,340 endast markerade hälften av EF853:s prestanda och nådde en topp på XNUMX XNUMX IOPS vid XNUMX μs latens.
Med SQL 80-20 såg vi återigen liknande utgångspunkt för latens i båda arrayerna, över 200μs. EF600 startade vid 156,264 1,559,733 IOPS och toppade på 406 570 73,990 IOPS med en latens på 739,139 μs. EF1.1 startade på XNUMX XNUMX IOPS och nådde sin topp på XNUMX XNUMX IOPS med en latens på XNUMX ms.
Vår nästa grupp av riktmärken är våra Oracle-arbetsbelastningar: Oracle, Oracle 90-10 och Oracle 80-20. Med Oracle startade EF600 vid 153,376 158 IOPS med 1,531,381 μs latens och höll sig under sub-millisekunders latens, och gick vidare till en topp på 507 570 718,141 IOPS med en latens på 1.2 μs. Detta jämförs med EFXNUMX:s topp på XNUMX XNUMX IOPS vid XNUMXms latens.
I Oracle 90-10 startade EF600 vid 172,788 161 IOPS med en latens på 1 μs och stannade under 1,660,486 ms under hela testet, och den fortsätter att toppa på 286 570 874,181 IOPS med en latens på 650 μs. EFXNUMX, å andra sidan, hade en toppprestanda på XNUMX XNUMX IOPS med en latens på XNUMX μs.
För Oracle 80-20 startade EF600 vid 156,113 158 IOPS med en latens på 600 μs och höll sig under sub-millisekunders latens fram till slutet av testet. EF1,514,221 fortsatte med sin topp på 310 570 735,093 IOPS med en latens på 681 μs. Detta var ungefär två gånger EFXNUMX:s XNUMX XNUMX IOPS med XNUMXμs latens.
Slutsats
NetApp AFA EF600 är en end-to-end NVMe-array riktad mot mellanregistret. Arrayen är bara 2U men kan packa upp till 367TB kapacitet i sin lilla ram och citerar prestanda som skulle konkurrera med mycket större företagsarrayer. Detta inkluderar 2 miljoner IOPS, upp till 44GB/s för bandbredd och latens under 100μs. Arrayen kommer också med viss inbyggd framtidssäkring med stöd för 100 Gb NVMe över InfiniBand, 100 Gb NVMe över RoCE, FCP-stöd och 32 Gb NVMe över FC. Som alla NetApp-arrayer kommer EF600 med hög tillgänglighet och flera inbyggda dataskyddsfunktioner.
När vi tittade på prestanda jämförde vi EF600 som kör NVMe-oF med EF570 över FCP. Detta var inte utformat för att visa vilket som är bättre, utan mer för att illustrera vad man kan förvänta sig av de två enheterna. För slumpmässig läsning i 4K hade EF600 över dubbelt så hög prestanda som EF570 med över 2 miljoner IOPS och nästan hälften av latensen på bara 1.4 ms. För 4K-skrivning hade EF600 nästan tre gånger så hög prestanda (3K IOPS) vid en tredjedel av latensen (cirka 640 ms). Med våra 1.5K sekventiella arbetsbelastningar såg vi en toppprestanda på 64 GB/s läsning och 40.2 GB/s skriver ungefär 8.87 gånger snabbare vid läsning och 2.6 gånger snabbare vid skrivning. För SQL hade EF1.8 toppvärden på 600 miljoner IOPS, 1.88 miljoner IOPS för SQL1.78-90 och 10 miljoner IOPS för SQL 1.56-80, allt med en latens på under millisekunder. Med våra Oracle-tester nådde EF20 600 miljoner IOPS, 1.53 miljoner IOPS på Oracle 1.66-90 och 10 miljoner IOPS i Oracle 1.51-80, återigen allt under 20 ms latens.
AFA EF600 är ännu en imponerande serie från NetApp. EF600 ger mellanregisteranvändare den kapacitet de behöver, samt mycket hög transaktionsprestanda med låg latens. För kunder som inte behöver dataminskningen eller de rika datatjänsterna som ONTAP-sidan av huset erbjuder, passar EF600 rollen att erbjuda högpresterande för riktade applikationer som kan dra nytta av de senaste NVMe SSD- och datatransportteknikerna . I slutändan kommer EF600 inte att vara för alla men det är inte meningen, det är helt klart inte en schweizisk armékniv. NetApps avsikt med EF600 är lite mer taktisk; det vill säga att tillhandahålla en härdad plattform som kan ta applikationer som tenderar att falla utanför de vanliga hotspots för virtualisering, och köra snabbare tid-till-företagsvärde. EF600 kommer att påskynda AI-, ML- och databasarbetsbelastningar, och erbjuda handlingskraftiga insikter till verksamheten snabbare än någonsin tidigare i denna kategori av lagring. För denna prestanda till prisfördel och tillförlitligheten som den här femte generationen EF ger ger EF600 NetApp EF-familjen ytterligare en StorageReview Editor's Choice Award.
Anmäl dig till StorageReviews nyhetsbrev