Implementering av SSD-cache i QSAN XCubeSAN

Prestandaförbättringstekniker som är baserade på användningen av SSD och som ofta tillämpas i lagringssystem har funnits länge. Framför allt handlar det om att använda SSD som lagringsutrymme, vilket är 100% effektivt men dyrt. Därför används teknologi för tiering och caching, där SSD enbart används för de mest efterfrågade ('heta') data. Tiering är bra för långvarigt (dagar-veckor) användande av 'heta' data. Caching å sin sida är för kortvarigt (minuter-timmar) användande. Båda dessa alternativ implementeras i lagringssystem. QSAN XCubeSAN. I denna artikel kommer vi att granska implementeringen av den andra algoritmen – SSD caching.

Essensen av teknologin för SSD caching är att använda SSD som en mellanliggande cache mellan hårddiskarna och kontrollerarens RAM. Prestandan hos SSD är naturligtvis lägre än prestandan hos kontrollerarens egen cache, men å sin del är volymen mycket större. Så vi får en slags kompromiss mellan hastighet och volym.

Indikationer för att använda SSD-cache för läsning:

• En övervägande mängd läsoperationer jämfört med skrivoperationer (vanligtvis kännetecknande för databaser och webbapplikationer);
• När det finns ett flaskhals som innebär prestandan hos hårddiskarrayen;
• När volymen av efterfrågade data är mindre än SSD-cache-volymen.

Indikationerna för att använda SSD-cache för läsning + skrivning är desamma, förutom typen av operationer – en blandad typ (t.ex. filserver).

De flesta leverantörerna av lagringssystem använder SSD-cache i sina produkter endast för läsoperationer. Den principiella skillnaden QSAN från dem är möjligheten att använda cachen även för skrivning. För att aktivera funktionen för SSD caching i QSAN-lagringssystemet krävs ett separat licensköp (levereras elektroniskt).

SSD-cachen i XCubeSAN implementeras fysiskt som separata SSD-cachepooler. Systemet kan ha upp till fyra sådana pooler. Varje pool använder förstås sin egen uppsättning av SSD. I inställningarna för den virtuella disken bestämmer vi om den ska använda cachepoolen och vilken specifik pool som ska användas. Aktivering och avaktivering av cacheanvändning för volymer kan göras online utan stopp av in-/utmatning. SSD kan även läggas till och tas bort från poolen utan nedstängning. När man skapar en SSD-cachepool måste man välja vilket läge den ska verka i: endast läsning eller läsning + skrivning. Detta påverkar dess fysiska struktur. Eftersom det kan finnas flera cachepooler kan deras funktionalitet variera (det vill säga systemet kan ha cachepooler för både läsning och läsning + skrivning samtidigt).

Om cachepoolen används endast för läsning kan den bestå av 1-8 SSD. Diskarna behöver inte nödvändigtvis ha samma kapacitet eller vara från samma tillverkare, eftersom de kombineras i en NRAID+-struktur. Alla SSD i poolen används gemensamt. Systemet försöker automatiskt parallellisera inkommande förfrågningar mellan alla SSD för att uppnå maximal prestanda. Om en av SSD-enheterna går sönder händer ingenting allvarligt: cacheminnet innehåller endast en kopia av data som lagras på massan av hårddiskar. Endast den tillgängliga SSD-cachekapaciteten minskar (eller blir noll om den ursprungliga SSD-cachen var baserad på en enda enhet).

Om cachen används för både läsningar och skrivningar måste antalet SSD i poolen vara jämnt, eftersom innehållet speglas på par av lagringsenheter (NRAID 1+-struktur används). Duplicering av cachen är nödvändig eftersom den kan innehålla data som inte har skrivits till hårddiskarna ännu. I så fall skulle en SSD-fel i cachepoolen orsaka förlust av information. I fallet med NRAID 1+ skulle ett fel på en SSD helt enkelt leda till att cachen går in i ett "endast läsning"-läge med utplåtning av oskrivna data till massan av hårddiskar. Efter att den defekta SSD-enheten har bytts ut, återgår cachen till sitt ursprungliga driftläge. För ökad säkerhet kan en dedikerad hot spare tilldelas cachen som arbetar i läsning + skrivning.

Vid användning av SSD-cachefunktionaliteten i XCubeSAN finns det en rad krav på minnesvolymen för lagringskontrollerna: ju mer systemminne, desto större cachen kommer att vara tillgänglig.

Till skillnad från de flesta lagringsproducenter, som enbart erbjuder alternativ för att aktivera/inaktivera SSD-cachen, ger QSAN större möjligheter. Speciellt kan man välja cache-arbetsläge beroende på belastningstypen. Det finns tre förinställda mallar som ligger närmast de motsvarande tjänsterna: databas, filsystem, webbtjänst. Dessutom kan administratören skapa sin egen profil genom att ställa in nödvändiga parameterarvärden:

• Blockstorlek (Cache Block Size) – 1/2/4 MB
• Antal läsfrågor som behövs för att blocket ska kopieras till cachen (Populate-on-Read Threshold) – 1..4
• Antal skrivfrågor som behövs för att blocket ska kopieras till cachen (Populate-on-Write Threshold) – 0..4

Profiler kan ändras "under körning", men självklart med att cachen nollställs och värms upp på nytt.

När man överväger principerna för hur SSD-cachen fungerar kan man identifiera de huvudsakliga operationerna vid arbete med den:

• Läsa data när de inte finns i cachen;
• Läsa data när de finns i cachen;
• Skriva data vid bruk av cache för läsning;
• Skriva data vid bruk av cache för läsning + skrivning.

Läsa data när de inte finns i cachen

1. Begäran från värden kommer till kontrollern;
2. Eftersom de begärda data inte finns i SSD-cachen, läses de från hårddiskarna;
3. De lästa data skickas till värden. Samtidigt kontrolleras det om dessa block är "heta";
4. Om så är fallet kopieras de till SSD-cachen för framtida användning.

Läsa data när de finns i cachen

1. Begäran från värden kommer till kontrollern;
2. Eftersom de begärda uppgifterna finns i SSD-cachen, läses de därifrån;
3. De lästa data skickas till värden.

Skriva data vid bruk av cache för läsning

1. Skrivbegäran från värden kommer till kontrollern;
2. Data skrivs på hårddiskarna;
3. Ett svar om lyckad inskrivning returneras till värden;
4. Samtidigt kontrolleras det om blocket är "hett" (jämförs med parametern Populate-on-Write Threshold). Om så är fallet kopieras det till SSD-cachen för senare användning.

Skriva data vid bruk av cache för läsning + skrivning

1. Skrivbegäran från värden kommer till kontrollern;
2. Data skrivs till SSD-cachen;
3. Ett svar om lyckad inskrivning returneras till värden;
4. Data from the SSD cache is written to hard drives in the background;

Check in action

Testbänk

2 servers (CPU: 2 x Xeon E5-2620v3 2.4Hz / RAM: 32GB) are connected by two ports directly to the XCubeSAN XS5224D (16GB RAM/controller) via Fibre Channel 16G.

16 x Seagate Constellation ES, ST500NM0001, 500GB, SAS 6Gb/s were used, combined in RAID5 (15+1), for the data array and 8 x HGST Ultrastar SSD800MH.B, HUSMH8010BSS200, 100GB, SAS 12Gb/s as cache

2 volumes were created: one for each server.

Test 1. SSD cache read-only with 1-8 SSDs

SSD Cache

• I/O Type: Customization
• Cache Block Size: 4MB
• Populate-on-read Threshold: 1
• Populate-on-write Threshold: 0

I/O Pattern

• Tool: IOmeter V1.1.0
• Workers: 1
• Outstanding (Queue Depth): 128
• Access Specifications: 4KB, 100% Read, 100% Random

In theory, the more SSDs in the cache pool, the higher the performance. This was confirmed in practice. The only significant increase in the number of SSDs with a low number of volumes does not lead to an explosive effect.

Test 2. SSD cache in read + write mode with 2-8 SSDs

SSD Cache

• I/O Type: Customization
• Cache Block Size: 4MB
• Populate-on-read Threshold: 1
• Populate-on-write Threshold: 1

I/O Pattern

• Tool: IOmeter V1.1.0
• Workers: 1
• Outstanding (Queue Depth): 128
• Access Specifications: 4KB, 100% Write, 100% Random

The same result: explosive growth in performance and scaling with an increase in the number of SSDs.

In both tests, the volume of the working data was less than the total cache size. Therefore, over time, all blocks were copied to the cache. The work was essentially done with SSDs, practically not touching the hard drives. The purpose of these tests was to visually demonstrate the effectiveness of cache warming and scaling its performance depending on the number of SSDs.

Now let's return to reality and check a more realistic situation where the volume of data exceeds the size of the cache. To ensure the test is completed in a reasonable time (the 'warming' time of the cache increases significantly with the volume size), we will limit the volume size to 120GB.

Test 3. Emulation of database operation

SSD Cache

• I/O Type: Database
• Cache Block Size: 1MB
• Populate-on-read Threshold: 2
• Populate-on-write Threshold: 1

I/O Pattern

• Tool: IOmeter V1.1.0
• Workers: 1
• Outstanding (Queue Depth): 128
• Access Specifications: 8KB, 67% Read, 100% Random

Utvärdering

A reasonable conclusion suggests a good efficiency of SSD cache use to enhance the performance of any storage system. Specifically for QSAN XCubeSAN Detta uttalande gäller helt och hållet: funktionen för SSD-cache är utmärkt implementerad. Detta gäller stöd för läs- och läs + skrivlägen, flexibel anpassning av arbete för alla användarscenarier samt den övergripande prestandan i systemet. Därför kan man, till ett mycket rimligt pris (licensavgiften motsvarar kostnaden för 1-2 SSD:er), avsevärt öka den totala prestandan.

Källa: habr.com