GIGABYTE, en välrenommerad tillverkare av datorrelaterade hårdvarukomponenter och system, har hoppat in på datalagringsmarknaden genom att samarbeta med Bigtera för att erbjuda en unik högpresterande, mjukvarudefinierad lagringslösning. GIGABYTE levererar hårdvaran, ihopkopplad med Bigteras VirtualStor mjukvaruplattform för att erbjuda en rad lagringsenheter för att möta olika kapacitets- och prestandakrav. Även om de flesta kommer att känna till GIGABYTE (som har funnits i över 30 år), kan Bigtera vara ett nytt namn för vissa. Bigtera, som grundades 2012, har två utvecklingscenter och över hundra kunder som driver VirtualStor i produktionsmiljöer.
Bigtera VirtualStor-familjen består av tre olika produktlinjer – Scaler, Converger och Extreme – som var och en är en mjukvarudefinierad lagringslösning som distribueras på standard x86-arkitektur. Scaler är datalagring för hybridutskalningslösningar; Converger är en lagringslösning som kan användas för att skapa en hyperkonvergerad infrastruktur genom att para den med VMware, Hyper-V eller KVM; och Extreme är en all-flash-utskalad lagringslösning designad för att leverera I/O till applikationer som kräver konsekvent låg latens och förbrukar en stor mängd bandbredd. I denna djupdykning kommer vi att undersöka VirtualStor Scaler-lösningen.
VirtualStor Scaler är en utskalad lagringslösning snarare än en uppskalnings- eller HCI-lösning (hyperconverged infrastructure), vilket innebär att fler diskar eller noder kan läggas till i ett VirtualStor Scaler-lagringskluster när mer lagringskapacitet behövs. Du får med andra ord rätt mängd lagringsutrymme för ditt datacenter som kan modifieras beroende på aktuella omständigheter. Denna flexibilitet eliminerar effektivt både överprovisionering av hårdvara (ett krav på uppskalningslösningar) och behovet av att lägga till mer datorkraft (oavsett om det behövs eller inte) när du använder en HCI-lösning.
GIGABYTE erbjuder sex olika plattformar för VirtualStor Scaler-systemet. I ena änden av spektrumet, optimerat för sina mindre användare, finns ett system med 48 TB användbar lagringskapacitet som består av tre 1U-noder. I den andra änden, för kunder som behöver hantera en enorm mängd data, finns ett system som kan lagra 4 PB data och består av åtta 4U-noder. För att säkerställa kvaliteten på dessa system använder GIGABYTE sina egna toppmoderna servrar som är utrustade med dubbla Intel Second Generation Xeon Scalable-processorer för att tillgodose beräkningsbehovet för dessa lagringsnoder. För datalagring använder VirtualStor-lagringsenheter en kombination av hårddiskar och NVMe- eller SATA SSD-cacheenheter. För att garantera att data fortsätter att flöda från enheten använder noderna Intel SFP+ och nätverkskort, och offline-nodhantering sker med Aspeed-fjärrstyrenheter.
VirtualStor Scaler Storage Protocols
Dagens datacenter måste leverera lagring för att möta behoven hos en krävande och mångsidig grupp användare så snabbt och kostnadseffektivt som möjligt. För att möta de olika lagringsbehoven i ett datacenter, stöder VirtualStor alla vanligt använda lagringsprotokoll (NAS, SAN och objektlagring) från en enda enhetlig lagringspool. För att säkerställa att prestandakraven uppfylls kan lagringen ha kvalitetsattribut (QoS) applicerade på filer, mappar eller volymer. Kvoter, som förhindrar en användare eller applikation från att överkonsumera lagringsutrymme, kan tillämpas på mapp- eller volymbasis.
VirtualStor är designad för att på ett tillförlitligt och konsekvent sätt tillhandahålla prestandabehov för de mest krävande applikationerna. Ett av sätten att de har åstadkommit detta är hur VirtualStors back-end-lagringsmotor, BigteraStore, hanterar placeringen av data. BigteraStore använder flash-enheter för datacachning och för att konsolidera och slå samman små datablock till större sekventiella block. Detta har inte bara en enorm inverkan på prestandan hos ett VirtualStor-system vid hantering av slumpmässiga data, det ökar också enhetens livslängd med färre skrivningar som görs till en flashenhet. BigteraStore förbättrar också prestandan för sina lagringssystem genom att identifiera sekventiell data (som levereras i större datablock) och kommer att läsa och skriva dessa data direkt på sina hårddiskar. Eftersom streaming av sekventiell data direkt till en hårddisk inte drabbas av samma prestandastraff som att läsa och skriva slumpmässiga data till en hårddisk, bevarar detta också kapaciteten hos dyra flashenheter för användning med slumpmässig data där det har störst inverkan.
Använd VirtualStor Scaler Flash
Dataeffektivitet, skydd och resiliens är tre faktorer som måste hanteras av dagens moderna lagringslösningar, och VirtualStor använder de senaste teknikerna och verktygen för att tillhandahålla en robust, effektiv lösning för att hantera dessa faktorer.
Den viktigaste egenskapen hos alla lagringssystem är förmågan att skydda integriteten hos data som lagras på den. För att göra detta stöder VirtualStor datareplikering, raderingskodning, RAID, feldetektering och självreparation av korrupta data. Eftersom data replikeras och balanseras över många olika lagringsnoder, i den osannolika händelsen att en hårdvarukomponent eller server misslyckas, kommer en annan lagringsnod sömlöst att ta över, och i de flesta fall kommer användaren eller applikationen inte ens vara medveten om att ett fel har inträffat . När den felaktiga komponenten har identifierats och ersatts kommer den automatiskt att integreras tillbaka i systemet. Du kan säkra känslig data som behöver det yttersta skyddet på en VirtualStor genom att använda Intel AES-NI-krypteringsteknik, men naturligtvis kan andra mindre säkra data lämnas i okrypterat tillstånd på VirtualStor-lagringsenheten.
VirtualStor Scaler Arkitektonisk översikt
En faktor som ofta förbises av de flesta användare när de bestämmer sig för vilken lagringslösning de ska gå med är svårigheten att ta fram den underliggande lagringen för användning. Det faktum att all VirtualStor-lagring, oavsett typ eller protokoll, kommer från en enda pool som kan överprovisioneras eliminerar effektivt både den tidskrävande uppgiften att omprovisionera den underliggande lagringen för att göra den tillgänglig, såväl som öar eller silos, lagringsutrymme som har tillhandahållits men som inte används.
VirtualStor Scaler Dashboard
Värdet av en lagringslösning kan minimeras om dess hanterbarhet är antingen svår eller undermålig, men som tur är har VirtualStor gjort det enkelt att hantera sin lagring genom att erbjuda en intuitiv, modern, webbaserad hanteringskonsol. Tidigare har vi sett några äldre enhetliga lagringssystem annonseras för att ha en enda hanteringskonsol, men vid närmare granskning hade hanteringskonsolen bestått av bara hanteringskomponenterna från olika system placerade som funktioner på en hanteringskonsol. Tyvärr leder denna situation till förvirring eftersom olika termer används för lagringskomponenterna och olika arbetsflöden krävs beroende på vilken lagringstyp som hanteras – ett minst sagt invecklat och förbryllande sätt att hantera lagring.
Vi har också sett lagringssystem som kräver kommandoradsinteraktion för att slutföra vanliga uppgifter där en felaktig inmatning kan orsaka katastrofala resultat. Tvärtom, med VirtualStor-enheter är alla arbetsflöden när man hanterar den dagliga systemhanteringen GUI-baserade och kräver ingen kommandoradsinteraktion. Dessutom, eftersom de designades med stöd för flera protokoll från början – inte som en eftertanke – är de inte belastade med äldre bolt-on-funktionalitet, vilket gör hanteringen av VirtualStor intuitiv och felfri.
VirtualStor Scaler Performance
Förutom att sätta ihop lösningen och göra den enkel att använda, måste klustret fortfarande erbjuda prestanda som passar de målinriktade kundernas användningsfall. Vidare erbjuder Bigtera stöd för flera protokoll, något som ger den här lösningen mer flexibilitet. Under en period på flera veckor testade vi lösningen med följande hårdvarukonfiguration:
- Klientnoder
- 1 x GIGABYTE H261-3C0 – 2U 4 noder, 3 noder användes för 3 klientservrar
- Per nod:
- 2 x Xeon Gold 6140-processorer (18 kärnor, 2.3 GHz)
- 8 x 16GB 2666MHz DDR4 RDIMM-minnesmoduler
- 1 x GIGABYTE CLNOQ42 Dual Port 25 GB SFP+ OCP LAN-kort (QLogic FastLinQ QL41202-A2G)
- 1 x 960 GB 2.5” Seagate SATA SSD
- Lagringsnoder
- 3 x GIGABYTE S451-3R0 lagringsservrar
- Per nod:
- 2 x Intel Xeon Silver 4114-processorer (10 kärnor, 2.2 GHz)
- 8 x 16GB 2666MHz DDR4 RDIMM-minnesmoduler
- 36 x 8TB 3.5” Seagate Exos SATA HDD
- 2 x 3.84 TB Adata SR2000CP AIC SSD
- 1 x 960 GB 2.5” Seagate SATA SSD
- 1 x GIGABYTE CLN4C44 4 x 25 GbE SFP28 LAN-portar (Mellanox ConnectX-4 Lx)
- 1 x GIGABYTE HW RAID-KORT CRA4648, GIGABYTE MR 3108 BBU
Som nämnts använder lösningen både hårddiskar och flashminne. Varje nod använder en 960 GB Seagate SSD för uppstart. För kapacitetsnivån använder GIGABYTE Seagate Exos 8 TB Enterprise-hårddiskar , med 36 enheter per lagringsnod. För att få bästa möjliga prestandaprofil ur denna konfiguration använder GIGABYTE ett par Adata SR2000CP 3D eTLC SSD-enheter per lagringsnod. Tilläggskorten på 3.84 TB hanterar journalföring samt tillhandahåller cacheelementet för klustret. SR2000CP-familjen finns i kapaciteter upp till 11 TB, men korten på 3.84 TB uppfyller prestandamålen (R/W-hastigheter på upp till 6000/3800 MB per sekund) och kostnadsmålen för denna enhet.
När man tittar på prestanda är det viktigt att förstå hur företag ser på storskaliga SDS-plattformar. De är generellt bra för objektprotokollprestanda, men när du vill utnyttja ett mer traditionellt protokoll som iSCSI, ses det mer som ett "kompatibilitets"-användningsfall. För att uttrycka det på ett annat sätt, de fungerar, men är mycket långsammare än de primära protokoll som lagringsarrayen byggdes kring. Det är dock inte fallet med alla plattformar, vilket är en del av det som gör VirtualStor Scaler så unik. För att bevisa denna punkt körde vi back-to-back-tester, ett med RBD-protokollet och ett med iSCSI. Det är värt att notera att testning av alla protokoll som VirtualScaler stöder låg utanför ramen för denna artikel, eftersom listan är bred (NFS, CIFS/SMB och S3 API).
För testspecifikationerna använde vi FIO för att mäta prestandan för 30 10 GB RBD-andelar mot 30 10 GB iSCSI LUN. Vi delade upp det så av våra tre klientsystem fick var och en åtkomst till 10 delningar eller LUN:er. Vi tillämpade sedan en arbetsbelastning på 1 tråd per lagringsenhet och ett ködjup på 16 (sammanlagt till klustret blev detta 30 trådar vardera med en belastning på 16Q). Vi jämförde sedan prestanda för stora sekventiella överföringar samt mindre slumpmässig 4K-trafik.
I vår första arbetsbelastning som mätte en 1024K sekventiell överföring såg vi i genomsnitt drygt 1600MB/s läsning och 960MB/s skrivning från var och en av våra tre klienter som utnyttjade iSCSI. Sammantaget gick detta ut till 4.9 GB/s läsning och 2.9 GB/s skriv. Genom att utnyttja RBD såg vi liknande skrivtrafik på över 960 MB/s per klient, men läsprestanda var högre med över 2700 MB/s per klient. Sammanlagt mätte RBD-summorna 8.1 GB/s läsning och 2.9 GB/s skrivning.
Genom att sänka vår arbetsbelastningsstorlek till en 128k sekventiell överföring såg vi återigen en liknande balans mellan iSCSI- och RBD-prestanda. Med iSCSI såg varje klient ungefär 440 MB/s skrivning och 1600 1.3 MB/s läst, vilket räknade till sammanlagt 4.9 GB/s skrivning och 410 GB/s läsning. Med fokus på RBD såg vi något lägre skrivprestanda på över 2500MB/s per klient och högre läsprestanda på över 1.2MB/s per klient. Detta fungerade till ett aggregat på 7.8 GB/s skrivning och XNUMX GB/s läs över RBD.
Genom att byta fokus till mindre prestanda för slumpmässig överföring fokuserar vi på vårt 4K-test. Om man tittar på båda protokollen i 4K slumpmässig skrivning, erbjöd iSCSI och RBD båda liknande prestanda på över 23K IOPS per klient eller ungefär 71K IOPS sammanlagt, med en kant mot RBD. När vi tittade på läsprestanda såg vi iSCSI med cirka 64K IOPS per klient eller 193K IOPS sammanlagt, och RBD som mätte 97K IOPS per klient eller 291K IOPS totalt.
Med fokus på genomsnittlig latens i våra 4K slumpmässiga överföringstester, med en sammanlagd klusterbelastning på 30 trådar och 16 köer per tråd, mätte vi drygt 6.7 ms skrivning för både iSCSI- och RBD-överföringar, med RBD som har en liten kant. Vid läsöverföringar hade RBD-prestanda en större fördel, då den mätte 1.647 ms sammanlagt, jämfört med 2.489 ms sammanlagt från iSCSI.
Bottom Line
VirtualStor Scaler är en flexibel och skalbar mjukvarudefinierad lösning som körs på industristandard x86-servrar och levererar fil-, block- eller objektlagring. I det här fallet har vi kombinerat klient- och lagringsnoder från GIGABYTE för att lyfta fram den konvergerade lösningens enkla hantering och stöd för flera protokoll. Det är också viktigt att lyfta fram motståndskraft som finns i plattformen. Det kommer till stor del tack vare Ceph-underbyggen av VirutalStor. Bigtera föredrar att inte leda med det meddelandet, eftersom det ofta antas att Ceph tillhandahåller fantastiska dataskyddsfunktioner, men saknar förmågan att berätta en prestanda- och flexibilitetshistoria – som båda är avgörande i de flesta företagslagringsapplikationer. Under vår tid med VirtualStor Scaler blev vi ständigt imponerade av förmågan att leverera mycket stark iSCSI-prestanda tillsammans med RADOS-blockgränssnittet. Släng in det faktum att det finns ett snyggt GUI ovanpå, vilket är praktiskt för dem som föredrar att inte pyssla med CLI—Bigtera har gjort det bra här. VirtualStor-lösningen kan helt klart vara mycket mer än ett datalager för typiska analys-, HPC- och AI/ML-implementeringar. Företaget skulle göra klokt i att betrakta detta som en direkt ersättning för en mängd olika användningsfall från on-prem moln, till lagringskonsolidering och mer typiska virtualiserade arbetsbelastningar, tack vare lösningens flexibilitet.
Amazon