I del 1 av vår X-IO Technologies ISE 860 G3 Review lade vi en översikt över vad ISE 860 G3 är och vi tittade på tillämpningar och syntetiska riktmärken. I en kort sammanfattning presterade plattformen utomordentligt bra över allt vi kastade på den, inklusive MySQL, SQL Server och syntetiska arbetsbelastningar. För den andra delen av vår recension kommer vi att utöka vår VMware-virtualiseringstestning av ISE 860 G3 med VMmark-tester, misslyckas med en styrenhet under belastning och stressar QoS-motorn på ISE 860 G3 under MySQL-arbetsbelastningar.
I del 1 av vår X-IO Technologies ISE 860 G3 Review lade vi en översikt över vad ISE 860 G3 är och vi tittade på tillämpningar och syntetiska riktmärken. I en kort sammanfattning presterade plattformen utomordentligt bra över allt vi kastade på den, inklusive MySQL, SQL Server och syntetiska arbetsbelastningar. För den andra delen av vår recension kommer vi att utöka vår VMware-virtualiseringstestning av ISE 860 G3 med VMmark-tester, misslyckas med en styrenhet under belastning och stressar QoS-motorn på ISE 860 G3 under MySQL-arbetsbelastningar.
VMmarks prestandaanalys
Som med alla våra Application Performance Analyser försöker vi visa hur produkter presterar i en liveproduktionsmiljö jämfört med företagets anspråk på prestanda. Vi förstår vikten av att utvärdera lagring som en komponent i större system, framför allt hur responsiv lagring är när man interagerar med viktiga företagsapplikationer. I detta test använder vi VMmark virtualisering benchmark av VMware i en miljö med flera servrar.
VMmark är genom sin design ett mycket resursintensivt riktmärke, med en bred blandning av VM-baserade applikationsarbetsbelastningar som stressar lagring, nätverk och datoraktivitet. När det kommer till att testa virtualiseringsprestanda finns det nästan inget bättre riktmärke för det, eftersom VMmark tittar på så många aspekter som täcker lagrings-I/O, CPU och till och med nätverksprestanda i VMware-miljöer.
Dell PowerEdge R730 VMware VMmark 4-nods klusterspecifikationer
- Dell PowerEdge R730-servrar (x4)
- CPU:er: Åtta Intel Xeon E5-2690 v3 2.6 GHz (12C/24T)
- Minne: 64 x 16 GB DDR4 RDIMM
- Emulex LightPulse LPe16002B 16 Gb FC Dual-Port HBA
- Emulex OneConnect OCe14102-NX 10 Gb Ethernet Dual-Port NIC
- VMware ESXi 6.0
ISE 860 G3 (20×1.6TB SSD per DataPac)
- Innan RAID: 51.2TB
- RAID 10 Kapacitet: 22.9TB
- RAID 5 Kapacitet: 36.6TB
- Listpris: $ 575,000
I vår första titt på VMware VMmarks prestanda med XIO ISE 860 använder vi Dell PowerEdge R730 13G 4-nodskluster som drivkraft bakom arbetsbördan. Med åtta Intel E5-2690 v3 Haswell-processorer erbjuder detta kluster 249.6 GHz CPU-resurser för de applikationer som körs som en del av varje VMmark-bricka. Generellt sett har vi sett ett krav på cirka 10GHz per bricka, vilket innebär att detta kluster under optimala förhållanden bör kunna köra mellan 24-26 brickor. Utöver det skulle det vara nödvändigt att lägga till ytterligare servrar i klustret eller byta till en högre nivå processor som E5-2697 v3 eller E5-2699 v3. Det är ett annat sätt att säga att när det här klustret fylls på kommer lagringen med största sannolikhet fortfarande att ha lite utrymme tillgängligt för att gå högre.
Genom att skala VMmark-arbetsbelastningen på XIO ISE 860 såg vi en stark linjär förbättring från 1 till 22 brickor. Efter 22 brickor började prestandan avta något när vårt datorkluster fäste dess CPU-användning. Med ett större kluster kunde XIO ISE 860 enkelt hantera ytterligare belastning. Att dyka in i prestandaövervakningen bakom kulisserna backar upp det, med latens som mäter under 1 ms under våra 26 tile runs, med en handfull ensiffriga toppar under svmotion/deploy-åtgärder. Eftersom prestanda med låg latens är ett absolut måste för en all-flash-array, gör X-IO ISE 860 ingen besviken alls.
Test av styrenhetsfel
Det finns olika SAN-designer på marknaden samt konfigurationsskillnader som aktiv/passiv och aktiv/aktiv. När det gäller att hantera fel tillåter båda designerna en reserv- eller sekundärkontroller att ta över lagringsuppgifter om den primära kontrollenheten går offline. Vi har haft ett växande intresse för att visa hur olika plattformar klarar av att styrenheter misslyckas, eftersom alla plattformar inte är lika. Scenariot vi utformade är ganska grundläggande i sin kärna; distribuera en betydande arbetsbelastning på lagringsarrayen, vänta tills arbetsbelastningen når stabilt tillstånd och dra sedan en kontroller. Under denna process tittar vi på hur prestandaegenskaperna förändras, övervakar för avbruten I/O-aktivitet och viktigast av allt hur snabbt plattformen återupptar arbetsbelastningen som testas. För X-IO ISE 860 använde vi vår Sysbench-arbetsbelastning, med 4 instanser fördelade på två volymer.
Med 4 virtuella Sysbench-datorer körda på ISE 860, väntade vi i ungefär 15 minuter på att arbetsbelastningen skulle jämnas ut på lagringsarrayen. Vid denna tidpunkt mätte arbetsbelastningen cirka 1,100 3 TPS per virtuell dator. Med en handkontroll utdragen såg vi prestandan minska i 4-10 sekunder över alla virtuella datorer, pausa i cirka 6.0 sekunder och sedan snabbt återuppta prestandanivån som uppmättes före felet. Våra VMware ESXi XNUMX-värdar klarade enkelt detta lagrings-I/O-avbrott och fortsatte att arbeta som om ingenting hade hänt.
Från X-IO ISE Manager Suite kunde vi se felet efter cirka 5 minuter (manuell uppdatering kan ha visat det tidigare). 10-15 minuter efter att ha dragit kontrollen fick vi också ett automatiskt e-postmeddelande från X-IO-supporten som varnade oss för kontrollfelet.
För att föra tillbaka den gamla kontrollern i vecket (eller lägga till ersättningskontrollern i arrayen) sätter du helt enkelt in regulatorn på baksidan av arrayen, låter arrayen detektera/analysera kontrollern och indikerar att den kan slås samman med arrayen. . Denna process tog några minuter och presenterade en "Lägg till"-knapp i ISE Manager-kontrollervyn. När vi väl klickade såg vi en liknande nedgång i prestanda, följt av några sekunders I/O-paus innan arrayen återgick till det normala. Precis som det ursprungliga felet hade VMware ESXi 6.0 inga problem att hantera detta avbrott och vi såg inga fel på gästoperativsystemets nivå. Alla lagringsmatriser är inte skapade lika i detta avseende, och det är trevligt att se att ISE 860 lätt skulle kunna hantera ett katastrofalt misslyckande.
X-IO Technologies ISE 860 G3 QoS
Vi berörde kort QoS i den första delen av vår recension, här ska vi ta en mer djupgående titt. X-IO erbjuder QoS-funktionalitet på deras ISE-lagringsmatriser. QoS-inställningar tillämpas på volymnivån, där användaren kan specificera IOPS Max, IOPS Min och IOPS Burst. Även om syntetiska resultat kan vara användbara för att visa hur väl QoS-profiler fungerar på en viss enhet, är det mycket mer värdefullt att se hur applikationer svarar på dem. Vi använde vår Sysbench MySQL TPC-C arbetsbelastning igen i det här avsnittet eftersom det erbjuder en utmärkt prestandaövervakningskapacitet i realtid. Vårt scenario utnyttjade en 4 virtuella datorer, med två virtuella datorer på en volym och de andra två på en annan volym. En volym designades för att vara ett "produktions"-användningsfall, där vi inte ville ha någon begränsning i prestanda jämfört med ett oreglerat riktmärke, medan den andra volymen skulle vara ett "utvecklings"-användningsfall. Detta skulle återspegla en företagsinställning där du behöver flera databasinstanser som körs på primär lagring, men utvecklingsinstanser skulle inte tillåtas påverka produktions-VM.
Att aktivera QoS och konfigurera det på en volymnivå är mycket enkelt på X-IO ISE 860. Inställningarna nås via samma menyer vid provisionering av volymer, där standard är "lagringsreglerad" eller full prestanda. För att aktivera QoS anger du bara ett IOPS-värde, och genom vissa försök och fel ser du hur det påverkar din arbetsbelastning. Det är värt att övervaka IOPS-nivån för din arbetsbelastning utan begränsningar genom prestandavyn på ISE Manager först för att få en baslinje. I det här fallet förbrukade 2 virtuella Sysbench-datorer över 20,000 30 IOPS, så vi satte en 40k IOPS Max, 20k IOPS Burst och XNUMXk IOPs Min på volymen som kör vår produktionsbelastning. För vår utvecklingsvolym gick vi igenom några iterationer för att se hur begränsningen av I/O-profilen påverkade vår live Sysbench-körning.
Det första exemplet visar Sysbench som körs på vår produktionsvolym, med QoS aktiverat. Vi såg ingen prestandaförändring jämfört med lagring reglerad eller helt obegränsad.
På vår utvecklingsarbete Sysbench kunde vi enkelt kontrollera prestandaprofilen vilket översattes till stabila, om än lägre prestandanivåer. I exemplet nedan ändrade vi från en profil inställd till hälften av vår produktionsvolym, till en som sänkte IOPS-nivån till 25 % av originalet. Som du kan se skedde prestandaförändringen omedelbart, utan I/O-avbrott eller I/O-instabilitet. För köpare som är oroliga för bullriga grannar som kan påverka högprioriterade arbetsbelastningar, erbjuder X-IO en mycket kapabel QoS-funktioner som fungerar mycket bra under verkliga förhållanden.
Del 2 Sista tankar
Det andra segmentet i denna recensionsserie tar en bred titt på både prestanda och servicefrågor. På prestandafronten tog ISE 860 ner 26 brickor i VMmark, vilket maximerade förmågan hos 4-nodsklustret. Gå längre, med sin 26-bricka belastning var skrivlatensen otroligt låg, mätte under 1 ms, med toppar på mindre än 10 ms. ISE har helt klart mer takhöjd här, vilket är något vi kommer att utforska ytterligare. Att ta allt de fyra servrarna kunde kasta sin väg är ingen liten bedrift men förväntades ändå eftersom ISE fortsätter att visa fantastisk prestanda över en mängd olika arbetsbelastningar.
Om man ser bortom prestanda är ett av X-IO:s anspråk på att vara känt med ISE-serien bristen på behov av underhåll. Om en enhet misslyckas i det här fallet kommer det inte att fungera, X-IO aggregerar lagringen för att avsiktligt fördunkla de individuella enheterna själva, även om du fysiskt skulle kunna komma åt dem medan de är i drift. I det här fallet drog vi mindre än graciöst en kontroller för att se vad som händer med aktiva arbetsbelastningar. Med ett litet slag när den andra kontrollern absorberade belastningen fortsatte allt utan problem i vCenter eller gästoperativsystem. Vi gick också in på QoS-funktionerna i ISE, som möjliggör snäva kontroller per volym. Mogna QoS-funktioner finns inte så ofta på primära lagringsmatriser, så denna nivå av granulär åtkomst är bra att ha, särskilt för dem som kör icke-kritiska dev-arbetsbelastningar på primär lagring, eller har bullriga grannar som ofta kan äta upp ordentligt mer än sin beskärda del av resurserna.
Vi kommer att fortsätta att arbeta med ISE 860 när vi vidareutvecklar våra teststrategier för denna nya sort av högpresterande lagring. Nästa steg inkluderar testning mot en Cisco UCS Mini med åtta blad och några ytterligare arbetsbelastningar som flash-arrayer kan utmärka sig med.
X-IO Technologies ISE 860 G3 recension: del 1
Anmäl dig till StorageReviews nyhetsbrev
