Tekniker för att förbättra prestanda baserade på användningen av SSD:er och som används ofta i lagringssystem har länge uppfunnits. Först och främst är det användningen av SSD som lagringsutrymme, vilket är 100% effektivt, men dyrt. Därför används tröttande och cachingtekniker, där SSD:er endast används för de mest populära ("heta") data. Tiering är bra för scenarier med långvarig (dagar-veckor) användning av "het" data. Caching är tvärtom för kortvarig (minuter-timmar) användning. Båda dessa alternativ är implementerade i lagringssystemet . I den här artikeln kommer vi att titta på implementeringen av den andra algoritmen - .
Kärnan i SSD-cacheteknik är användningen av SSD:er som en mellanliggande cache mellan hårddiskar och kontrollerns RAM. SSD:ns prestanda är förstås lägre än prestandan för kontrollerns egen cache, men volymen är en storleksordning högre. Därför får vi en viss kompromiss mellan hastighet och volym.
Indikationer för att använda SSD-cache för läsning:
- Övervägande läsoperationer framför skrivoperationer (oftast typiskt för databaser och webbapplikationer);
- Närvaron av en flaskhals i form av prestanda för hårddiskarrayen;
- Mängden nödvändig data är mindre än storleken på SSD-cachen.
Indikationerna för att använda en läs+skriv SSD-cache är desamma, förutom operationernas karaktär – blandad typ (till exempel filserver).
De flesta lagringsleverantörer använder skrivskyddad SSD-cache i sina produkter. Den grundläggande skillnaden De ger möjligheten att använda cachen för att skriva också. För att aktivera SSD-cachefunktionen i QSAN-lagringssystem måste du köpa en separat licens (levereras elektroniskt).
SSD-cachen i XCubeSAN är fysiskt implementerad i form av separata SSD-cachepooler. Det kan finnas upp till fyra av dem i systemet. Varje pool använder naturligtvis sin egen uppsättning SSD:er. Och redan i egenskaperna för den virtuella disken bestämmer vi om den kommer att använda en cachepool och vilken. Aktivering och inaktivering av cacheanvändning för volymer kan göras online utan att stoppa I/O. Du kan också lägga till SSD-enheter i poolen och ta bort dem därifrån. När du skapar en SSD-poolcache måste du välja vilket läge den ska fungera i: skrivskyddad eller läs+skriv. Dess fysiska organisation beror på detta. Eftersom det kan finnas flera cachepooler kan deras funktionalitet vara olika (det vill säga att systemet kan ha både läs- och läs+skriv-cachepooler samtidigt).
Om en skrivskyddad cachepool används kan den bestå av 1-8 SSD:er. Diskar behöver inte ha samma kapacitet och samma leverantör, eftersom de är kombinerade till en NRAID+-struktur. Alla SSD:er i poolen är delade. Systemet försöker oberoende parallellisera inkommande förfrågningar mellan alla SSD:er för att uppnå maximal prestanda. Om en av SSD:erna misslyckas kommer inget dåligt att hända: trots allt innehåller cachen bara en kopia av data som lagras på hårddiskar. Det är bara det att mängden tillgänglig SSD-cache kommer att minska (eller bli noll om du använder den ursprungliga SSD-cachen från en enhet).
Om cachen används för läs- och skrivoperationer, bör antalet SSD-enheter i poolen vara en multipel av två, eftersom innehållet speglas på par av enheter (NRAID 1+-strukturen används). Det är nödvändigt att duplicera cachen eftersom den kan innehålla data som ännu inte har skrivits till hårddiskarna. Och i det här fallet skulle fel på SSD:n från cachepoolen leda till förlust av information. I fallet med NRAID 1+ kommer ett fel på SSD helt enkelt att leda till att cachen överförs till ett skrivskyddat läge, med oskrivna data som dumpas på hårddiskarrayen. Efter att ha bytt ut den felaktiga SSD:n återgår cachen till sitt ursprungliga driftsläge. Förresten, för större säkerhet kan du tilldela dedikerade hot reserver till en läs + skrivcache.
När du använder SSD-cachefunktionen i XCubeSAN finns det ett antal krav på mängden minne hos lagringskontroller: ju mer systemminne, desto större cachepool kommer att vara tillgänglig.
Till skillnad från de flesta tillverkare av lagringssystem, som bara erbjuder ett alternativ att slå på/av SSD-cachen, ger QSAN fler alternativ. I synnerhet kan du välja cachedriftläge beroende på belastningens karaktär. Det finns tre förinställda mallar som i sin verksamhet är närmast motsvarande tjänster: databas, filsystem, webbtjänst. Dessutom kan administratören skapa sin egen profil genom att ställa in de nödvändiga parametervärdena:
- Blockstorlek (Cacheblockstorlek) – 1/2/4 MB
- Antal förfrågningar om att läsa ett block så att det kopieras till cachen (Populate-on-Read Threshold) – 1..4
- Antal förfrågningar om att skriva ett block så att det kopieras till cachen (Populate-on-Write Threshold) – 0..4
Profiler kan ändras i farten, men, naturligtvis, med innehållet i cache-återställningen och dess nya "uppvärmning".
Med tanke på principen för driften av SSD-cachen kan vi lyfta fram huvudoperationerna när vi arbetar med den:
Läser data när den inte finns i cachen
- En begäran från värden anländer till styrenheten;
- Eftersom de efterfrågade inte finns i SSD-cachen läses de från hårddiskarna;
- Läsdata skickas till värden. Samtidigt görs en kontroll för att se om dessa block är "heta";
- Om ja, så kopieras de till SSD-cachen för vidare användning.
Läs data när den finns i cachen
- En begäran från värden anländer till styrenheten;
- Eftersom den begärda datan finns i SSD-cachen läses den därifrån;
- Läsdata skickas till värden.
Skriva data när du använder läscache
- En skrivbegäran från värden anländer till styrenheten;
- Data skrivs till hårddiskar;
- Ett svar som indikerar framgångsrik inspelning returneras till värden;
- Samtidigt kontrolleras om blocket är "hot" (parametern Populate-on-Write Threshold jämförs). Om ja, kopieras den till SSD-cachen för senare användning.
Skriva data när du använder en läs+skriv-cache
- En skrivbegäran från värden anländer till styrenheten;
- Data skrivs till SSD-cachen;
- Ett svar som indikerar framgångsrik inspelning returneras till värden;
- Data från SSD-cachen skrivs till hårddiskar i bakgrunden;
Checka in action
Testbänk
2 servrar (CPU: 2 x Xeon E5-2620v3 2.4Hz / RAM: 32GB) är anslutna med två portar via Fibre Channel 16G direkt till XCubeSAN XS5224D lagringssystem (16GB RAM/kontroller).
Vi använde 16 x Seagate Constellation ES, ST500NM0001, 500GB, SAS 6Gb/s, kombinerat i RAID5 (15+1), för datamatrisen och 8 x HGST Ultrastar SSD800MH.B, HUSMH8010BSS200, 100GB/cacheb, SAS som ca.
2 volymer skapades: en för varje server.
Test 1. Skrivskyddad SSD-cache från 1-8 SSD:er
SSD-cache
- I/O-typ: Anpassning
- Cacheblockstorlek: 4MB
- Fylla vid läsning Tröskel: 1
- Fylla-vid-skriv-tröskel: 0
I/O-mönster
- Verktyg: IOmeter V1.1.0
- Arbetare: 1
- Enastående (ködjup): 128
- Åtkomstspecifikationer: 4KB, 100 % läst, 100 % slumpmässigt
I teorin, ju fler SSD:er i cachepoolen, desto högre prestanda. I praktiken har detta bekräftats. Den enda betydande ökningen av antalet SSD-enheter med ett litet antal volymer leder inte till någon explosiv effekt.
Testa 2. SSD-cache i läs + skrivläge med 2-8 SSD:er
SSD-cache
- I/O-typ: Anpassning
- Cacheblockstorlek: 4MB
- Fylla vid läsning Tröskel: 1
- Fylla-vid-skriv-tröskel: 1
I/O-mönster
- Verktyg: IOmeter V1.1.0
- Arbetare: 1
- Enastående (ködjup): 128
- Åtkomstspecifikationer: 4KB, 100 % skriv, 100 % slumpmässigt
Samma resultat: explosiv prestandatillväxt och skalning när antalet SSD-enheter ökar.
I båda testerna var mängden arbetsdata mindre än den totala cachestorleken. Därför kopierades alla block med tiden till cachen. Och arbetet har faktiskt redan utförts med SSD-enheter, praktiskt taget utan att det påverkar hårddiskarna. Syftet med dessa tester var att tydligt demonstrera effektiviteten av att värma upp cachen och skala dess prestanda beroende på antalet SSD:er.
Låt oss nu komma tillbaka till jorden och kolla en mer realistisk situation, när mängden data är större än cachestorleken. För att testet ska klara sig inom en rimlig tid (cachens "uppvärmningsperiod" ökar kraftigt när volymen ökar), kommer vi att begränsa volymstorleken till 120 GB.
Test 3. Databasemulering
SSD-cache
- I/O-typ: Databas
- Cacheblockstorlek: 1MB
- Fylla vid läsning Tröskel: 2
- Fylla-vid-skriv-tröskel: 1
I/O-mönster
- Verktyg: IOmeter V1.1.0
- Arbetare: 1
- Enastående (ködjup): 128
- Åtkomstspecifikationer: 8KB, 67 % läst, 100 % slumpmässigt
dom
Den uppenbara slutsatsen är förstås den goda effektiviteten av att använda en SSD-cache för att förbättra prestandan för alla lagringssystem. Appliceras på Detta uttalande gäller fullt ut: SSD-cachefunktionen är perfekt implementerad. Det handlar om stöd för läs- och läs-+skrivlägen, flexibla inställningar för alla användningsscenarios, såväl som den övergripande prestandan för systemet som helhet. Därför, för en mycket rimlig kostnad (licenspriset är jämförbart med kostnaden för 1-2 SSD-enheter), kan du öka den totala prestandan avsevärt.
Källa: will.com