Microsoft Azure Stack HCI Review (DataON HCI-224 med Intel Optane NVMe)

Hittills har vi gjort det dök djupt in i Microsoft Azure Stack HCI, den lokala implementeringen av Microsofts Azure-molntjänst. Azure Stack HCI kan ses som en typ av plattform som är bäst av båda världarna. Den har alla hanteringsverktyg från Azure som Azure Monitor, Azure Security Center, Azure Update Management, Azure Network Adapter och Azure Site Recovery, samtidigt som den innehåller data på plats och uppfyller vissa regler. Azure Stack HCI är uppdelad i tre delar: mjukvarudefinierad arkitektur, Azure-tjänster och hårdvara.

Hittills har vi gjort det dök djupt in i Microsoft Azure Stack HCI, den lokala implementeringen av Microsofts Azure-molntjänst. Azure Stack HCI kan ses som en typ av plattform som är bäst av båda världarna. Den har alla hanteringsverktyg från Azure som Azure Monitor, Azure Security Center, Azure Update Management, Azure Network Adapter och Azure Site Recovery, samtidigt som den innehåller data på plats och uppfyller vissa regler. Azure Stack HCI är uppdelad i tre delar: mjukvarudefinierad arkitektur, Azure-tjänster och hårdvara.

Att välja rätt hårdvara är viktigt som vi beskrev i vår artikel, "Vikten av hårdvara i Microsoft Azure Stack HCI.” Det första steget för att distribuera Azure Stack HCI skulle vara att hitta en certifierad hårdvaruleverantör, i det här fallet DataON. DataON har haft ett starkt partnerskap med både Microsoft och Intel i flera år och förverkligar detta partnerskap fullt ut i hårdvarulayouten för Azure Stack HCI i en Intel Select-konfiguration. En intressant aspekt av partnerskapet med Intel är möjligheten att utnyttja företagets PMEM (och naturligtvis dess senaste processorer) med Azure Stack HCI.

I många fall konfigureras och levereras DataON HCI Intel Select-lösningarna i sitt eget rack, redo att distribueras omedelbart. Denna leveransmetod är särskilt användbar vid kanten, där befintlig IT-infrastruktur är begränsad eller obefintlig. I StorageReview-labbet distribuerade vi de fyra lagrings- och beräkningsnoderna, domänkontrollanten och switcharna enligt diagrammet nedan.

Bygg och design

Microsoft Azure Stack HCI-klustret vi granskade är byggt på DataON HCI-224 All Flash NVMe-plattformen. Dessa servrar är 2U i storlek med 24-NVMe-fack framtill, och erbjuder gott om expansion på baksidan för PCIe-baserade komponenter. Märkningen är hög i motsats till de mattsvarta drivcaddyerna, vilket gör det enkelt att upptäcka specifika enheter om det är dags att byta ut. Allt är märkt, vilket inte är så ovanligt, men omfattningen av märkningen är det. Vår implementering har varje nod märkt (1 till 4), samt ett antal andra objekt som gör det enkelt att distribuera och hantera i datacentret.

Vår konfiguration kom utrustad med 48 NVMe SSD, eller 12 per nod. Dessa inkluderade fyra 375 GB Intel Optane P4800X SSD:er och åtta Intel P4510 2TB SSD:er.

På baksidan har vi två dubbla portar 100G Mellanox Connect-X 5 NIC, som ger en helt redundant anslutning genom två Mellanox 100G-switchar (SN2100) för klusternätverkstrafik. I vår studiofotografering visas inte alla anslutningar med fullständig märkning på vardera änden av lämplig nätverkskabel för att möjliggöra felfri kablage vid installationsstadiet.

Dessförinnan har vi aldrig fått en lösning med denna nivå av dokumentation på etiketten. Microsoft och DataON gör implementeringen av Azure Stack till en smärtfri process så att kunderna kan komma igång direkt. Varje kabel är färgkodad för den specifika användningen och märkt för var varje ände går. I kombination med det skräddarsydda blad som DataON tillhandahåller kunderna, garanterar det nästan en felfri driftsättning. I vår implementering var systemet förkonfigurerat med IP-adresser före leverans, med IP-adresser för hantering och IPMI märkta.

Hantering och användbarhet

För köpare som driver en Hyper-V-butik på Windows Server kommer Microsoft Azure Stack HCI att vara en enkel övergång. Många av samma hanteringsverktyg finns på plats, med många som erbjuder ett mer integrerat och enkelt arbetsflöde. I vår granskningsprocess använde vi både Windows Failover Cluster Manager för att hantera DataOn HCI Cluster, såväl som Windows Admin Center för att övervaka arbetsbelastningar och se hur de presterade.

När vi tittade på mer av nodnivån först genom en Microsoft Remote Desktop (RDP)-session inloggad på en av noderna, tittade vi på Windows Failover Cluster Manager. Detta ger både hanteringsmöjligheter på nodnivå och synlighet på klusternivå. Denna typ av åtkomst skulle vara mer inriktad på initial driftsättning, där daglig övervakning skulle ske från Windows Admin Center.

Först klickar vi på vårt specifika kluster och får allmän information om det, möjligheten att konfigurera det och en titt på resurser. Detta ger en sammanfattning av det valda klustret, så att du kan se var problemen finns och börja borra i specifika områden.

Nästa upp är failover-roller. Här kan vi se alla Hyper-V virtuella datorer som körs på klustret. Här visas de många virtuella vmfleet-maskiner som vi använde för att stresstesta klustret.

Nätverk låter oss se vilka klusternätverk som är tillgängliga och status för varje. Genom att välja ett klusternätverk kan du se det underliggande nätverkskortet som är associerat med det, såväl som dess IP-adress.

Under lagringsalternativet finns Diskar, Pooler och Enclosures. För diskar kan man klicka på virtuella diskar och få information som status, var den är tilldelad, ägarnod, disknummer, partitionsstil och kapacitet. Användare kan också borra ner lite djupare med ännu mer information som presenteras som pool-ID, namn och beskrivning – såväl som virtuellt disk-ID, namn och beskrivning, hälso- och driftsstatus och motståndskraft.

Pooler liknar varandra, med information om vissa lagringspooler som status, hälsa, ägarnod, drifttillstånd och total kapacitet, samt ledigt och använt utrymme.

Under Noder kan man enkelt se alla noder i klustret och deras status.

Till höger kan man byta till failover-diskar och se den enskilda disken för en given nod längst ner.

Från samma sidofält kan man också titta på nätverket för en given nod.

Medan Windows Failover Cluster Manager är en mer "ned till detaljerna" hanteringsapparat, kräver den att användare ansluter via Windows Remote Desktop till en server själv (eller en annan server som är ansluten till det klustret) för att arbeta med den. Även om denna hanteringsstil är bra för många användningsområden, gjorde Microsoft det enklare med en ny plattform som heter Windows Admin Center. Till skillnad från Failover Cluster Manager är Windows Admin Center helt webbläsarbaserat, vilket gör det lättare att ansluta till från vilken dator eller surfplatta som helst på arbetsplatsen. Den erbjuder också ett moderniserat och estetiskt tilltalande utseende och känsla, vilket gör den dagliga övervakningen till en roligare uppgift. Den erbjuder en titt på mycket av samma information, med ett starkare fokus på aktivitetsövervakning som Failover Cluster Manager inte erbjuder i samma utsträckning.

När Windows Admin Center är associerat med ett kluster kan du gå igenom specifika områden för att visa och hantera operationer. Här ser vi övergripande klusterberäkningsprestandainformation, som håller reda på de övergripande resurserna som de virtuella datorerna använder.

Även om Windows Admin Center är utmärkt för att visa aktivitet, kan du fortfarande interagera med virtuella datorer i ditt kluster. Nedan startar vi ett antal virtuella vmfleet-maskiner.

Användare kan också borra i information om specifika virtuella datorer.

Under roller får vi en lite annorlunda uppfattning om roller men det mesta av samma nyckelinformation.

Under inställningar kan användare ladda ner, installera och uppdatera tillägg för Azure.

Genom Windows Admin Center kan vi också gå in i Hyper-Converged Cluster Manager för att titta närmare på beräkning och lagring. Vi öppnar upp till Dashboard som har allmän information som antalet servrar, enheter, virtuella datorer, volymer, samt användningen av CPU, minne och lagring. Längs botten av instrumentpanelen finns klustrets prestanda som är uppdelad i en specifik tidsram och IOPS och latens.

Under beräkning kan administratörer borra i själva servrarna för hantering inklusive borttagning av servern från klustret. Här finns allmän information om servern som används såsom drifttid, plats, domän, tillverkare, modell, serienummer, OS-namn, version och byggnummer. Användare kan också titta på prestanda som är specifik för servern.

Genom att klicka på fliken Volymer kommer användarna till en sammanfattning av alla volymer i klustret. Volymernas hälsa är färgkodade: grönt för friskt, rött för kritiskt och gult för varning. Prestanda spåras också för alla volymer, uppdelade efter tidsram och i IOPS, latens och genomströmning.

Att borra ner i en enskild volym ger specifika egenskaper för volymen inklusive status, filsystem, sökväg, feldomänkännedom, total storlek, använd storlek, elasticitet och fotavtryck. Det finns valfria funktioner (deduplicering och komprimering samt integritetskontrollsummor) som kan slås av eller på här. Kapaciteten visas grafiskt och visar använd kontra tillgänglig. Och återigen ser vi prestanda.

Under fliken Drives får vi en sammanfattning av alla enheter i systemet. Här ser vi det totala antalet enheter och om det finns några varningar med samma färgkodning som volymer eller inte. Vi kan också se kapaciteten: använd, tillgänglig och reserverad.

Klinkande på inventering får vi en lista över alla enheter och flera detaljer. Detaljerna inkluderar status för enheten, dess modell, kapacitetsstorleken, typen, vad den används till och mängden lagringsutrymme som används.

Vi kan borra ner i en enda enhet och se egenskaper som status, plats, storlek, typ, används för, tillverkare, modell, serienummer, firmwareversion och lagringspoolen den finns i. Vi kan se hur mycket kapacitet som används. mot tillgänglig för den individuella enheten och dess prestanda i IOPS, latens och genomströmning.

Nedanför prestandan kan vi även se statistik för körfördröjning och fel.

Prestation

Prestanda inuti Microsoft Azure Stack-ekosystemet har alltid varit bra, en stark färg som har tagit sig igenom från Storage Spaces-dagarna. Med det i åtanke tittade vi på några vanliga benchmarking-arbetsbelastningar i den här recensionen för att låta användare se hur väl den här plattformen kan jämföras med andra HCI-lösningar på marknaden. Med det i åtanke använde vi arbetsbelastningar för att betona slumpmässiga små blockstorlekar såväl som stora blocköverföringar för att visa vilken potential denna Microsoft-lösning kan erbjuda. I vår Azure Stack HCI-recension utnyttjade vi vmfleet för prestandabenchmarks, medan vi på VMware eller bare-metal Linux använde vdbench.

För prestandan här testade vi systemet med både 2-vägsspegel och 3-vägsspegel. Spegeln hänvisar till metoden för dataskydd (antingen två kopior eller tre kopior). Uppenbarligen kommer användarna att förlora en del kapacitet med fler kopior. Ur ett prestandaperspektiv borde 3-vägs leda till bättre läsningar genom ökningen av parallellitet och 2-vägs är bättre för skrivprestanda med en tredjedel mindre nätverkstrafik.

För vårt slumpmässiga test i 4K såg 2-vägsspegeln en genomströmning på 2,204,296 247 564,601 IOPS avlästa med en genomsnittlig latens på 3.69 µs och en skrivgenomströmning på 3 2,302,610 IOPS vid en genomsnittlig latens på 170 ms. 338,538-vägs såg en läsgenomströmning på 9.12 521 4 IOPS läst med en genomsnittlig latens på 202 µs och för skrivning var det en genomströmning på XNUMX XNUMX IOPS vid en genomsnittlig latens på XNUMX ms. För att sätta en del av detta i perspektiv mätte VMwares vSAN-erbjudande med två Optane SSD:er och fyra NVMe Capacity SSD:er per nod XNUMXK IOPS XNUMXK läsning vid sin topp och XNUMXK IOPS skrivning.

Därefter tittar vi på vårt 32K sekventiellt riktmärke. För läsning såg vi 2-vägsträffen 42.59 GB/s och 3-vägsträffen 39.48GB/s. För skrivningar gav HCI oss 13.8 GB/s för 2-vägs och 7.19 GB/s för 3-vägs.

Vi fortsätter med vårt sekventiella arbete och går vidare till våra 64K-tester. Här 2-vägsträffen 39.5 GB/s läsning och 15.24 GB/s skriv och 3-vägsträffen 46.47 GB/s läs och 7.72 GB/s skriv. Jämfört med vSAN kommer läsbandbreddsskillnaderna inte ens i närheten, där bandbredden i sina tester toppade på drygt 5.3 GB/s med en 64K blockstorlek. Skrivbandbredden hade en liknande skillnad, där vSAN toppade på 2.55 GB/s.

Vårt nästa riktmärke är SQL med blandad läs/skrivprestanda. Här hade 2-vägs en genomströmning på 1,959,921 324 3 IOPS vid en genomsnittlig latens på 1,929,030 µs. 185-vägsträffen 2 321 XNUMX IOPS med en genomsnittlig latens på XNUMX µs. SQL-arbetsbelastningen är ett annat område där Azure Stack HCI kan visa sin styrka, som mäter strax under XNUMX miljoner IOPS, medan VMwares vSAN i samma arbetsbelastningsprofil mätte XNUMXk IOPS.

Med SQL 90-10 träffade 2-vägs 1,745,560 411 3 IOPS med en genomsnittlig latens på 1,547,388 µs och 285-vägs hade XNUMX XNUMX XNUMX IOPS och XNUMX µs för latens.

För SQL 80-20 hade 2-vägs en genomströmning på 1,530,319 581 3 IOPS vid 1,175,469 µs för latens. Trevägsträffen 681 XNUMX XNUMX IOPS och XNUMX µs för latens.

SPECsfs

Nästa upp är vårt SPECsfs 2014 SP2 benchmark – ett nytt test för oss här. SPECsfs är en benchmark-svit som mäter filserverns genomströmning och svarstid. Riktmärket ger oss en standardiserad metod för att jämföra prestanda mellan olika leverantörsplattformar. Riktmärket fungerar genom att sätta en skala och öka upp tills punktfördröjningen är för stor för riktmärkets specifikationer. Här tittar vi på skalan som kan göras tills 11ms är bruten, samt bandbredden som servern träffar när den misslyckas med latensnumret.

Vi kommer att titta på latens först här eftersom det kommer att kasta mer ljus över varför bandbredden stannade där den gjorde i den andra delen. Skalan och deras latenser för både 2-vägs och 3-vägs finns i tabellen nedan:

Som man kan se började båda konfigurationerna nära 250µs, 2-vägs något under och förblev så hela tiden. På en skala av 1500 misslyckades 3-vägs och gick till 11.285 ms, vilket gav den ett intervall på 262 µs till 10.45 ms. 2-vägs misslyckades på en skala av 1800 och träffade 11.7 ms, vilket ger den ett intervall på 243 µs till 11.07 ms.

Nästa tabell visar bandbredden för varje konfiguration vid varje build, med felet som anges ovan i latens.

För bandbredd körde båda konfigurationerna hals i hals med 300 MB/s intervaller fram tills 3-vägs misslyckades med latensen med sin slutliga passerande bandbredd på 4.02 GB/s, och 2-vägs med en slutlig passerande bandbredd på 4.62 GB/ s.

Slutsats

Det var ett tag sedan vi var så djupa med något i Microsofts lagringscentrerade stacken; och pojke, är vi glada över att vara tillbaka. Med den omdöpta Microsoft Azure Stack HCI-lösningen har Microsoft gjort något som är så grundläggande och grundläggande att det är lätt att underskatta. Microsoft har gjort sin HCI-lösning dödlig att använda utan att lägga över något för att dämpa prestandan. Som framgår av våra siffror har DataON-klustret vi har testat en enorm siffra, det snabbaste vi har sett i ett mellanmarknads 4-nods HCI-kluster. För att vara rättvis så testar vi inte ens den senaste och bästa hårdvaran från DataON heller. Även om den här konfigurationen helt klart inte är slarvig, komplett med Intel Optane DC SSD:er, erbjuder DataON snabbare lösningar som drar fördel av Intel Xeon 2nd Generation CPUs, beständigt minne och snabbare nätverk. Det faktum att det finns ännu mer prestanda tillgängligt i en Azure Stack HCI-lösning är spännande, men det är också viktigt att komma ihåg att lösningen kan skalas ner så väl till så små implementeringar som två noder HCI som kan konfigureras switchless för en lågkostnads ​​edge- eller SMB-lösning.

Genom att gå igenom prestandasiffrorna kunde Microsoft Azure Stack HCI-klustret erbjuda en otrolig mängd I/O och bandbredd. I sfären med fyra hörn mätte vi mer än 2.3M IOPS 4K slumpmässig läsning med en 3-vägs spegelkonfiguration och 338k IOPS 4K slumpmässig skrivning. Om du behöver bättre skrivprestanda kunde en 2-vägs spegelkonfiguration öka 4K slumpmässiga skrivhastigheter till 564k IOPs. När man tittar på bandbredd är det dock där Microsoft Azure Stack verkligen lyser. I vår 64K block sekventiell överföring arbetsbelastning, 2-vägs spegel mätte 39.5 GB/s läsning och 15.24 GB/s skriv, medan 3-vägs spegel mätte 46.47 GB/s läsning och 7.72 GB/s skriv. Detta överstiger vida vad vi har mätt från tidigare HCI-kluster.

Sammantaget visade sig Microsofts Azure Stack HCI-lösning vara både enkel att distribuera, lätt att hantera och exceptionellt presterande, allt du vill ha. DataON, som en lösningspartner, utmärkte sig i att tillhandahålla en nyckelfärdig konstruktion som erbjuder inbyggd hårdvara med tydliga instruktioner som slutligen säljs i en konfiguration som kan vara igång på nolltid. Kunder kan till och med hoppa över kabeldragningen i många fall, så det beror verkligen på det specifika behovet. På båda sätten visade sig Azure Stack HCI i kombination med Intel Optane, Intel NVMe SSD och Mellanox 100G-nätverk vara en kraft att räkna med.

DataON HCI Solutions

Diskutera denna recension

Anmäl dig till StorageReviews nyhetsbrev