QSAN XCubeSAN XS5226D recension

Förra året granskade vi QSAN XCubeSAN XS1200-serien som vi fann hade bra prestanda, bra kapacitet och ett bra pris för SMB- och ROBO-marknaderna som var målet. För den här recensionen kommer vi att titta på samma apparat med den avancerade XS5226-kontrollern i den. Eftersom design och konstruktion och hantering är identiska (vi använder samma chassi), kan läsarna hänvisa tillbaka till tidigare recension.

Inom XS5200-familjen (ungefär som XS1200-familjen) erbjuder QSAN flera formfaktorer och antingen en enkel eller dubbel styrenhet – återigen med en S för singel eller D för Dual. XS5226D är en dubbelkontroller som är aktiv aktiv och inriktad på högre prestanda för verksamhetskritiska miljöer med de idealiska användningsfallen som HPC, virtualiseringsintegration och M&E. Företaget hävdar prestanda så hög som 12 GB/s sekventiell läsning och 8 GB/s sekventiell skrivning med över 1.5 miljoner IOPS.

Som sagt använder vi samma chassi, vilket innebär att det finns flera områden med överlappning mellan de två recensionerna och kommer därför att hoppas över här. Vi kommer dock att titta på viktiga specifikationsskillnader eftersom de direkt påverkar prestandan.

Specifikationer för QSAN XCubeSAN XS5226D

Raid controller	Dubbel-aktiv
CPU	Intel Xeon D-1500 fyrkärnig
Minne	upp till 128 GB DDR4 ECC
Växeltyp
2.5" SAS, NL-SAS, SED HDD
2.5" SAS, SATA SSD (6Gb MUX-kort behövs för 2.5" SATA-enheter i dubbelt styrsystem)
Expansionsmöjligheter	2U 26-fack, SFF
Max enheter stöds	286

Prestation

Analys av applikationens arbetsbelastning

Benchmarks för applikationsarbetsbelastningen för QSAN XCubeSAN XS5226D 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, konfigurerade 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 ut fyra 5200 XNUMX-skaliga databaser jämnt över QSAN XSXNUMX (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 vår testning kommer vi att jämföra den nya styrenheten med den tidigare testade. Detta är mindre en "vilken är bättre" och mer av en "titt på prestandan man får beroende på ens behov."

Med SQL Server gjorde skillnaden i kontroller verkligen ingen stor skillnad i prestanda. XS1226 med 4VM fick 12,634.3 5226 TPS och XS4 med 12,634.7VM fick XNUMX XNUMX TPS.

Med SQL genomsnittlig latens såg vi mer av samma. XS1226 hade en latens på 5.8 ms och XS5226 hade en latens på 5.0 ms.

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

I vårt Sysbench-riktmärke testade vi flera uppsättningar av 4VM, 8VM, 16VM och 32VM. När det gäller transaktionsprestanda visade XS5226D en stark prestanda med 6,889 4 TPS för 13,023VMs, 8 21,645 TPS vid 16VMs, 26,810 32 TPS vid XNUMXVMs och XNUMX XNUMX TPS vid XNUMXVMs.

Med genomsnittlig latens presterade 4VM XS1226 något bättre än XS5226D, 18.1 ms till 18.6 ms, men XS5226D utkantade den tidigare kontrollern i de andra VM-konfigurationerna med 19.7 ms för 8 VM, 23.9 ms för 16 VM och 41 V ms för 32 VM.

I vårt benchmark för latens i värsta fall ser vi samma sak som med genomsnittlig latens: bättre i 4VM för XS1200-serien och bättre i resten med XS5200-serien. För XS5226D såg vi en latens på 32.7 ms för 4VM, 34.8 ms för 8VM, 47 ms för 16VM och 76.9 ms 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. 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-toppläsprestanda hade XS5226D sub-millisekunders latensprestanda upp till bara 400K IOPS, med en toppprestanda på 442,075 8.03 IOPS med en latens på 1200ms. Detta blåste långt förbi XS284 som nådde en topp på 13.82K IOPS och XNUMXms latens.

Med 4K-toppskrivprestanda hade den nya styrenheten sub-millisekunders latensprestanda upp till cirka 270K IOPS med en topp på 294,255 6.27 IOPS med en latens på 246ms. Som jämförelse hade den gamla kontrollern en toppprestanda på cirka 7.9K med XNUMX ms latens.

Byte över till sekventiell prestanda, i 64K-läsaren red XS5226D precis under 1ms tills cirka 38K IOPS eller 2.3GB/s och nådde en topp på 95,762 5.99 IOPS eller 5.34GB/s med en latens på 1200ms. XSXNUMX hade inte ens prestanda under millisekunder.

För 64K sekventiell toppskrivning hade XS5226D prestanda under 1ms till cirka 63K IOPS eller 3.9GB/s. Den nådde en topp på cirka 80K IOPS eller 4.95 GB/s med en latens på 2.68ms.

I vår SQL-arbetsbelastning överträffade den nya styrenheten enkelt sin motsvarighet. XS5226D hade en fördröjningsprestanda på under millisekunder fram till cirka 380 425,327 IOPS och nådde en topp på 2.27 5226 IOPS med en latens på 200 ms. Så XS1D-kontrollern hade cirka XNUMXK mer IOPS med XNUMXms lägre latens.

I SQL 90-10 stannade XS5226D under 1 ms till cirka 350 407,661 IOPS och nådde en topp på 2.36 1 IOPS med en latens på XNUMX ms. Återigen överglänste den den andra kontrollern som hade all sin prestanda över XNUMX ms.

SQL 80-20 visade XS5226D med submillisekunders latensprestanda fram till cirka 340K IOPS och en toppprestanda på 387,085 2.4 IOPS med en latens på 1200ms. Återigen, det var ganska prestandahoppet på XS247 som hade en toppprestanda på cirka 3.26K IOPS vid XNUMXms latens.

Med Oracle Workload klarade XS5226D nästan 310K IOPS innan den bröt 1ms och nådde en topp på 381,444 3.1 IOPS med 1200ms. XS246,186 nådde en topp på 4.2 XNUMX IOPS med en latens på XNUMX ms.

Med Oracle 90-10 höll sig XS5226D under 1 ms till cirka 360 407,763 IOPS och nådde en topp på 1.56 1200 IOPS med en latens på 248,759 ms. Som jämförelse toppade XS2.2 på 1 XNUMX IOPS med XNUMX ms latens och sjönk aldrig under XNUMX ms under hela körningen.

För Oracle 80-20-körningen klarade XS5226D bara 350K IOPS innan den bröt 1ms och nådde en topp på 386,844 1.66 IOPS med en latens på 1200ms. XS1 var över 242,000 ms genomgående med en topp på 4.16 XNUMX IOPS och en latens på XNUMX ms.

Därefter bytte vi till vårt VDI-klontest, Full och Linked. För VDI Full Clone Boot gick XS5226D över linjen på 1 ms ett tag innan den föll omkull vid ungefär 225 367,665 IOPS och nådde en topp på 2.78 1200 IOPS med en latens på 218 ms. Ett imponerande hopp i prestanda jämfört med XS4.26:s XNUMXK IOPS och XNUMXms latens.

För VCI FC Initial Login hade XS5226D sub-millisekunders latensprestanda fram till cirka 200K IOPS och toppade på cirka 260K IOPS med 3ms latens. XS1200 nådde en topp på 185,787 3.91 IOPS med XNUMXms latens i samma test.

VDI Full Clone Monday Login såg att XS5226D nådde cirka 163K IOPS under 1 ms och nådde en topp på 269,724 1.86 IOPS med en latens på 182,376 ms. Den tidigare kontrollern kunde nå en topp på 2.55 XNUMX IOPS med XNUMX ms latens.

Byte över till VDI Linked Clone, starttestet visade att XS5226D klarade sig till ungefär 110K med sub-millisekunders latensprestanda och toppade på 216,579 2.36 IOPS med en latens på 1200ms. XS149,488 nådde en topp på 3.39 XNUMX IOPS med en latens på XNUMX ms.

VDI Linked Clone initiala inloggning såg också att XS5226D klarade sig till ungefär 110K med sub-millisekunders latensprestanda och sedan toppade den på 182,425 1.39 IOPS med en latens på 1200ms. Jämför detta med XS147,423 som hade en toppprestanda på 1.71 XNUMX IOPS vid XNUMX ms latens.

Slutligen fick VDI Linked Clone Monday Login XS5226D återigen göra det till ungefär 110K med sub-millisekunder latensprestanda och sedan toppade den på cirka 220K IOPS med en latens på 2.3ms. XS1200 nådde en topp på 148,738 3.2 IOPS med en latens på XNUMX ms.

Slutsats

QSAN XCubeSAN XS5226D är ett dubbelt aktivt-aktivt SAN som lovar mer prestanda än XS1226D som riktade sig till små och medelstora företag. För den här recensionen utnyttjade vi samma chassi med en uppgraderad kontroller. Med det sagt, design och konstruktion och förvaltning var desamma och finns i vår ursprungliga recension. XS5226D är inriktad på mer verksamhetskritiska arbetsbelastningar och har målanvändningsfall högre uppströms än XS1226D som HPC, M&E och virtualisering. Att använda samma chassi innebär att alla fördelar med anslutning och hög tillgänglighet är desamma.

När vi tittar på prestanda, i vår analys av applikationsarbetsbelastning, översattes skillnaden i kontroller inte till någon större skillnad i prestanda för våra SQL Server-riktmärken, även om vi på andra områden såg enorma vinster. TPS för XS1226 var 12,634.3 5226 och för XS0.4 var poängen bara 12,634.7 TPS högre på 5.8 5.0. Vi såg en liknande åtgärd med genomsnittlig latens med den mindre kontrollern som slog 1226 ms och den större 4 ms. Med Sysbench såg vi mycket bättre prestanda av XS5226 i 32VM-konfigurationer, men XS26,810.4 hade bättre prestanda med fler virtuella datorer med 41VM-prestanda på 76.9 XNUMX TPS, XNUMX ms genomsnittlig latens och XNUMX ms i värsta fall.

Med våra VDBench-arbetsbelastningar var det en enorm skillnad i nästan alla våra tester med XS5226D som klart ger mycket mer prestanda. I vår 4K såg vi XS5226D-kontrollerna få poäng över 442K IOPS-läsning och 294K IOPS-skrivning med latens så låg som 8.03ms respektive 6.27ms. 64K-prestanda visade att kontrollern slog nästan 6 GB/s läsning och nästan 5 GB/s skriv. Med vår SQL-arbetsbelastning hade kontrollern toppprestanda över 425K IOPS, 407K IOPS för 90-10 och 387K IOPS för 80-20. Oracle-arbetsbelastningen visade också några riktigt bra siffror med toppprestanda över 381K IOPS, 407K IOPS för 90-10 och 386K IOPS för 80-20 med latenser mellan 1.56 ms till 3.1 ms. För vår VDI Full Clone och Linked Clone tittade vi på Boot, Initial Login och Monday Login. För Boot-prestanda slog XS5226D över 367K IOPS i FC och över 216K IOPS i LC. Initial inloggning visade cirka 260K IOPS toppprestanda FC och över 182K IOPS för LC. Och Monday Login hade XS5226D-kontrollern med över 269K IOPS FC och 220K IOPS LC.

Sammantaget klarade sig XS5200 ganska bra och drar full nytta av Toshiba PX04 SAS3 SSD:erna vi installerade. Prestanda totalt sett är mycket imponerande, eftersom 6GB/s läsning och 5GB/s skrivning (64K sekventiell) från ett SMB SAN är mycket bra. Naturligtvis finns det något av en kompromiss; funktionsuppsättningen, gränssnittet och mjukvaruintegreringarna med populära paket som VMware lämnar lite övrigt att önska när du ser mer exklusivt på företagsbehov. Hur som helst, XS5200 erbjuder en fantastisk prestanda/kostnadsprofil som kommer att få jobbet gjort bra för en stor del av målgruppen.