Vi har pratat om det och tipsat er om det , och nu levererar vi äntligen VMware vSAN med Intel Optane Review. Detta blir den tredje stora recensionen av vSAN, som börjar med en flerdelad recension av en hybrid vSAN 6.0, följt av en all-flash-recension av vSAN 6.2 . Istället för att utnyttja vårt Dell PowerEdge R730xd-kluster använder vi den här gången Supermicros 2029U-TN24R4T+ 2U, 24-facks server som kör vSAN 6.7. För lagring använder vi en ren NVMe-konfiguration med Intel Optane P4800X (375 GB) SSD-diskar för skrivnivån samt Intel P4500 (2 TB) SSD-diskar för kapacitetsnivån.
För de som inte är bekanta med vSAN är det VMwares hyperkonvergerade infrastruktur optimerad för vSphere som lutar mot lagring. Med andra ord är vSAN ett steg på de mjukvarudefinierade datacenterbyggstenarna som syftar till att göra lagring och lagringshantering enkel och samtidigt leverera bättre prestanda. vSAN säljs vanligtvis genom ett certifieringsprogram som kallas VMware vSAN ReadyNodes som är en kombination av certifierad hårdvara kombinerad med VMware-programvara. De flesta av de stora serverleverantörerna erbjuder ReadyNode-konfigurationer och vissa erbjuder även vSAN som en apparat.
Intels Select Solutions liknar ReadyNode-idén. Intel Select Solutions är verifierade hård- och mjukvarustackar som följer kraven som ställts upp av Intel. Lösningarna som levereras till marknaden av stora serverleverantörer måste antingen kunna replikera eller överträffa benchmarkprestanda som skisserats av Intel och de måste ha detaljerade installationsguider för kunderna. Inställningen vi använder för den här recensionen faller inom denna kategori, närmare bestämt är det en Intel Select-lösning för VMware vSAN. Som namnet antyder är lösningen speciellt designad för VMware-miljöer.
Intel Select Solution för VMware vSAN finns i två konfigurationer: en "Bas" och en "Plus". Vår konfiguration sitter någonstans i mitten av dessa konfigurationer; det är i grunden en baskonfiguration med uppgraderade processorer. Med Optane SSD:er för skrivnivån är våra system utformade för att möta latenskraven från affärskritiska applikationer.
Specifikationer för Supermicro 2029U-TN24R4T+:
- Supermicro 2029U-TN24R4T+-servrar (x4)
- CPU: 2 x Intel Xeon Gold 6152-processor, 2.10 GHz, 22 kärnor
- Minne: 384 GB RAM (12 x 32 GB 2,666 4 MHz DDRXNUMX DIMM)
- vSAN-diskgrupper, 2x per nod:
- vSAN Cache-nivå: 2 x 375 GB Intel Optane SSD DC P4800X Series NVMe SSD:er
- vSAN Kapacitetsnivå: 4 x 2TB Intel DC P4500 Series NVMe SSD:er
- Nätverk:
- Intel Ethernet Converged Network Adapter X710 10/40 GbE (dedikerad länk för vSAN, vMotion/VM-trafik/Management uppdelad på sitt eget VLAN).
- Prestanda
- 4KB slumpmässigt, ködjup 16, R/W: upp till 550/500K IOPS
- 4KB slumpmässigt, ködjup 16, blandat 70/30 R/W: upp till 500K IOPS
- DWPD: 30
- Prestanda
- Sekventiell läsning: 3200MB/s
- Sekventiell skrivning: 1050MB/s
- Slumpmässig 4K-läsning: 490,000 XNUMX IOPS
- Slumpmässig 4K-skrivning: 38,000 XNUMX IOPS
- DWPD 0.75 slumpmässigt; 4.62 sekventiell
Analys av applikationens arbetsbelastning
De första riktmärkena består av MySQL OLTP-prestanda via SysBench och Microsoft SQL Server OLTP-prestanda med en simulerad TPC-C-arbetsbelastning.
Varje SQL Server VM är konfigurerad med två vDisks, en 100 GB för uppstart och en 500 GB för databasen och loggfilerna. Ur ett systemresursperspektiv konfigurerade vi varje virtuell dator med 16 vCPU:er, 64 GB DRAM och utnyttjade LSI Logic SAS SCSI-kontrollern. Dessa tester är utformade för att övervaka hur en latenskänslig applikation presterar på klustret med en måttlig, men inte överväldigande, beräknings- och lagringsbelastning.
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
I SQL Server TPC-C-testet på hyperkonvergerade plattformar tittar vi på arbetsbelastningsbalansen över klustret i hybridläge, all-flash-läge (AF) och all-flash-datareduktion (AF DR). AF-läget för Optane, föga överraskande, presterade bara något bättre med en sammanlagd poäng på 12,605 3,148.56 TPS med individuella virtuella datorer på mellan 3,152.66 12,472 TPS och 12,604 3,148.7 TPS. Detta är totalt sett något bättre än den icke-Optane-versionen av vSAN som hade en sammanlagd poäng på 3,153.5 11,969 TPS. Med DR på såg vi att Optane fick en sammanlagd poäng på XNUMX XNUMX TPS (bara en TPS lägre än med DR avstängd) med individuella virtuella datorer som sträckte sig mellan XNUMX XNUMX TPS till XNUMX XNUMX TPS. Detta var ett ganska stort hopp över icke-Optane-versionen med DR:s sammanlagda poäng på XNUMX XNUMX TPS. Det är värt att notera här att Gold-CPU:erna sannolikt är en begränsande faktor och med Platinum-CPU:er finns det mer uppsida att hämta.
För SQL Server TPC-C-testet är den variabel vi ägnar mest uppmärksamhet åt genomsnittlig latens. Små luckor i transaktionsresultat visar inte hela historien. I vårt genomsnittliga latenstest hade AF Optane en sammanlagd poäng på bara 16.5 ms med individuella virtuella datorer från 14 ms till 21 ms. Med DR på Optane-versionen hoppade bara till 17 ms för aggregat med 13 ms till 21 ms latens för enskilda virtuella datorer. Detta är en stor förbättring jämfört med icke-Optane vSAN med en sammanlagd poäng på 52.5 ms utan DR och 261 ms med DR på.
Sysbench Performance
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 (400GB). Ur ett systemresursperspektiv konfigurerade vi varje virtuell dator med 16 vCPU:er, 64 GB DRAM och utnyttjade LSI Logic SAS SCSI-kontrollern.
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: 12 timmar
- 6 timmar förkonditionering 32 trådar
- 1 timme 32 trådar
- 1 timme 16 trådar
- 1 timme 8 trådar
- 1 timme 4 trådar
- 1 timme 2 trådar
Med Sysbench OLTP tittar vi på 8VM-konfigurationen för var och en. Optane AF hade en sammanlagd poäng på 10,699 4,273 TPS, över två gånger den icke-Optane-versionens 8,668 3,625 TPS. Med DR på slog Optane XNUMX XNUMX TPS jämfört med icke-Optane med DR:s XNUMX XNUMX TPS.
För Sysbenchs genomsnittliga latens kunde det Optane-baserade vSAN verkligen lysa med sammanlagda poäng på 23.95 ms och 29.62 ms med DR på. Detta jämförs med icke-Optanes 60.05ms och 71.05ms med DR på. I båda fallen hade Optane mindre än halva latensen.
Genomsnittlig 99:e percentil latens visade återigen att det Optane-baserade vSAN var dramatiskt snabbare med sammanlagda poäng på 42.9 ms och 55.63 ms med DR på jämfört med icke-Optanes 126.02 ms och med DR på, 212.42 ms.
VDBench arbetsbelastningsanalys
När det gäller benchmarking av lagringsmatriser är applikationstestning bäst och syntetisk testning 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
För VDBench-testet kommer vi bara att titta på Optane Supermicro-versionen av vSAN och vi kommer att titta på att ha DR antingen på (kallas DR från och med här) eller av (refererat till som Raw från och med här). I vårt första test för topp 4K slumpmässig läsning hade Raw sub-millisekunder latens till ungefär 440K IOPS och toppade på 521,599 4.65 IOPS med en latens på 1ms. DR startade strax under 406,322 ms innan den gick över och nådde en topp på 7.32 XNUMX IOPS med en latens på XNUMX ms.
Med 4K slumpmässig skrivning körde Raw 1ms-linjen men stannade under den till cirka 150K IOPS och nådde en topp på 202,081 8.4 IOPS med en latens på 114ms. DR tog sig till cirka 183,947K IOPS med latens på under millisekunder och nådde en topp på 1.43 XNUMX IOPS med XNUMXms latens innan den sjönk kraftigt i prestanda och ökade i latens.
Därefter tittar vi på 64K sekventiella arbetsbelastningar. För att läsa hade Raw en fördröjningsprestanda på under millisekunder fram till cirka 54K IOPS eller 3.5 GB/s och nådde en topp på 85,319 5.33 IOPS eller 4.69 GB/s med en latens på 1 ms. DR startade över 73,583 ms och nådde en topp på 4.6 4.23 IOPS eller XNUMX GB/s med en latens på XNUMX ms.
För 64K-skrivning nådde Raw bara cirka 12K IOPS innan den bröt 1ms, och fortsatte med att nå en topp på 40,869 2.55 IOPS eller 5.58GB/s med en latens på 7,303ms. DR hade en fördröjningsprestanda på under millisekunder men nådde en topp på bara 456 623 IOPS eller XNUMX MB/s med en latens på XNUMX μs.
När vi går vidare till våra SQL-arbetsbelastningar, hade Raw en fördröjning på under millisekunder till cirka 330 385,159 IOPS och nådde en topp på 2.34 1 IOPS med en latens på 321,504 ms. DR stannade över 3.02 ms i stort sett hela tiden med en toppvisning på XNUMX XNUMX IOPS med en latens på XNUMX ms.
För SQL 90-10 nådde Raw cirka 300K IOPS innan den bröt 1ms och nådde en topp på 363,550 2.52 IOPS med en latens på 299,132. DR nådde en topp på 3.26 XNUMX IOPS med en latens på XNUMX ms.
Vårt SQL 80-20-test såg att Raw körde över 277K IOPS på under 1ms och toppade på 332,949 2.79 IOPS med en latens på 285,010ms. DR nådde en topp på 3.42 XNUMX IOPS med en latens på XNUMXms.
Nästa upp är våra Oracle-arbetsbelastningar. Raw hade submillisekunders latens fram till cirka 262K IOPS och toppade på 323,706 3.27 IOPS med en latens på 211,993ms. DR nådde en topp på 2.07 XNUMX IOPS med en latens på XNUMXms innan den återigen sjönk i prestanda och ökade i latens.
För Oracle 90-10 hade Raw en fördröjningsprestanda på under millisekunder fram till cirka 315 354,590 IOPS och nådde en topp på 1.67 279,356 IOPS med en latens på 2.24 ms. DR nådde en topp på XNUMX XNUMX IOPS med en latens på XNUMXms.
Oracle 80-20-testet såg att Raw kördes under 1 ms till ungefär 273K IOPS och toppade på 322,616 1.85 IOPS med en latens på 263,425 ms. DR kunde nå en topp på 2.36 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 hade Raw sub-millisekunders latensprestanda fram till cirka 240K IOPS, som fortsatte med en topp på 293,335 3.3 IOPS och en latens på 181,527ms. DR nådde en topp på 5.31 XNUMX IOPS och en latens på XNUMX ms innan den tappade.
VDI FC Initial Login hade den råa starten nära 1 ms och passerade den snabbt och fortsatte att nå en topp på 153,513 5.6 IOPS med 68 ms latens innan ett litet fall. DR nådde en topp tidigare på ungefär 5.3K IOPS och XNUMX ms latens innan den sjunkit i prestanda och ökade i latens.
Med VDI FC Monday Login hade Raw en fördröjning på under millisekunder till cirka 58K IOPS och toppade på 152,660 3.14 IOPS med en latens på 1.64ms. DR hade en bättre topplatens (64,201ms), men toppade bara med en prestanda på XNUMX XNUMX IOPS.
För VDI LC Boot hade Raw en fördröjning på under millisekunder till cirka 170K IOPS och nådde en topp på 209,676 2.21 IOPS med en latens på 119,036ms. Med DR nådde den en topp på 3.99 XNUMX IOPS och en latens på XNUMX ms.
När vi gick vidare till VDI LC Initial Login stannade Raw under 1 ms till 29K IOPS och nådde en topp på 92,951 2.62 IOPS med en latens på 64 ms. För DR nådde den en topp på strax under 2.3K IOPS med en latens på ungefär XNUMX ms innan den tappade.
Slutligen, med en titt på VDI LC Monday Login, klarade sig Raw till cirka 35K IOPS innan den bröt 1ms och nådde en topp på 101,997 4.65 IOPS med en latens på 47ms. Med DR var toppen cirka 1.82K IOPS vid XNUMXms latens innan prestandan sjönk.
Slutsats
VMwares hyperkonvergerade lagringslösning finns i många former och former; denna speciella iteration använder fyra Supermicro 2029U-TN24R4T+-servrar för beräkning. För lagring utnyttjar denna version av vSAN både Intel Optane i form av Intel Optane P4800X SSD och NVME-lagring i form av Intel P4500 SSD. Denna speciella konstruktion är en del av Intels nya Select Solutions, särskilt Intel Select Solutions för VMware vSAN. Det kan ses som en vSAN ReadyNode som är certifierad av både VMware och Intel för att nå de nödvändiga prestandamåtten.
När vi tittar på prestanda, i vår Application Workload Analysis ställde vi Optane-versionen av vSAN mot vår tidigare testade all-flash-version av vSAN på Dell/Toshiba-utrustning. För SQL Server hade Optane-konfigurationen nästan identiska poäng med datareduktion (DR) på och av, en sammanlagd poäng på 12,605 12,604 TPS utan DR och 11,969 16.5 TPS med DR. Detta markerar ett ganska stort hopp över all-flash, icke-Optane-versionen med DR på (17 6.2 TPS). När man tittar på latens, visade Optane-versionen en drastisk förbättring med sammanlagda poäng på bara 10,699 ms utan DR och bara 8,668 ms med DR på, mindre än hälften av latensen för SAS all-flash-versionen på vSAN 24. Med Sysbench hade Optane-versionen av vSAN över dubbelt så mycket TPS som all-flash-versionen med sammanlagda poäng på 30 60 TPS Raw och 71 XNUMX TPS med DR på. Denna trend fortsätter med latens och värsta tänkbara latens, i båda fallen mindre än hälften med sammanlagda poäng på XNUMX ms och XNUMX ms med DR i genomsnitt och XNUMX ms och XNUMX ms med DR i värsta fall.
För vår VDBench hade Optane vSAN flera höjdpunkter för Raw-prestanda inklusive 4K-läsning av 522K IOPS, 4K-skrivning av 202K IOPS, 64K-läsning av 5.33GB/s och 64K-läsning av 2.55GB/s. Med DR på såg vi vSAN-träffen 406K IOPS 4K läsa, 184K IOPS-skrivning (följt av ett kraftigt fall), 4.6GB/s läsas på 64K och endast 456MB/s skriva på 64K men med latens under 1ms. vSAN fortsatte med stark prestanda i SQL som slog 385K IOPS, 364K IOPS i 90-10 och 333K IOPS i 80-20 och DR träffade 322K IOPS, 299K IOPS i 90-10 och 285K-80 i 20K IOPS. I Oracle hade Raw ganska stark prestanda med 324K IOPS, 355K IOPS i 90-10 och 323K IOPS i 80-20. DR var också stark i Oracle med toppar på 212K IOPS (innan avhopp), 279K IOPS i 90-10 och 263K IOPS i 80-20.
Införandet av Optane SSD:er har helt klart en stor inverkan på skrivprestandan för vSAN. Detta med tanke på att enheterna bara är 375 GB och vSAN stöder 600 GB kapacitet för skrivnivåenheterna. Så det är möjligt att vi kan få lite mer skrivprestanda där genom att ha större enheter. Det finns också en hel del uppåtriktad potential för dessa Intel-konfigurationer, eftersom snabbare sammankopplingar är kvalificerade och mer aggressiva RAM- och CPU-konfigurationer används som i Plus-alternativen. Intel har också snabbare/bättre enheter tillgängliga nu för läsnivån; P4510 var en avsevärd förbättring jämfört med P4500. Poängen är att snarare än att ta dessa data som det bästa Optane kan göra, handlar dessa data mer om att ställa in baslinjen för mellanregisterserverkonfigurationer som har mycket mer att ge, om tillfället skulle behöva det. Det är också viktigt att tänka på att vSAN är väl positionerat för att fortsätta dra nytta av ny lagrings- och serverteknik när det kommer till marknaden – något som är mycket svårare för traditionella leverantörer av apparater att åstadkomma.
Takeaway är dock helt klart att i takt med att vSAN har mognat har VMware varit smarta för att komma i framkant av framväxande teknik som Intel Optane SSD:er. Detta ger vSAN en betydande fördel när det gäller hur prestanda kan se ut på HCI-marknaden. Även om många HCI-lösningar gärna möter behoven hos ROBO-användningsfall som har måttliga prestandaprofiler, fortsätter vSAN att söka efter de bästa partnerna för att skapa lösningar som är lika nöjda i kanten som de lägger grunden för nästa generations datacenter ser ut som i SDDC-världen. Optane-baserade vSAN-kluster är extremt väl lämpade för det senare, och erbjuder bästa möjliga skrivfördröjning för alla applikationsarbetsbelastningar.
Amazon