Teknologier til forbedring af ydeevnen baseret på brugen af SSD'er og udbredt i lagersystemer er længe blevet opfundet. Først og fremmest er det brugen af SSD som lagerplads, hvilket er 100% effektivt, men dyrt. Derfor bruges trættende og caching-teknologier, hvor SSD'er kun bruges til de mest populære ("hotte") data. Tiering er godt for scenarier med langsigtet (dage-uger) brug af "varme" data. Caching er derimod til kortvarig (minutter-timer) brug. Begge disse muligheder er implementeret i lagersystemet . I denne artikel vil vi se på implementeringen af den anden algoritme - .
Essensen af SSD-cacheteknologi er brugen af SSD'er som en mellemliggende cache mellem harddiske og controllerens RAM. Ydeevnen på SSD'en er selvfølgelig lavere end ydelsen på controllerens egen cache, men lydstyrken er en størrelsesorden højere. Derfor får vi et vist kompromis mellem hastighed og volumen.
Indikationer for brug af SSD-cache til læsning:
- Overvægten af læseoperationer over skriveoperationer (oftest typisk for databaser og webapplikationer);
- Tilstedeværelsen af en flaskehals i form af ydeevne af harddisken array;
- Mængden af nødvendige data er mindre end størrelsen af SSD-cachen.
Indikationerne for brug af en read+write SSD-cache er de samme, bortset fra arten af operationerne – blandet type (for eksempel filserver).
De fleste lagerleverandører bruger skrivebeskyttet SSD-cache i deres produkter. Den grundlæggende forskel De giver også mulighed for at bruge cachen til skrivning. For at aktivere SSD-caching-funktionen i QSAN-lagringssystemer skal du købe en separat licens (leveres elektronisk).
SSD-cachen i XCubeSAN er fysisk implementeret i form af separate SSD-cache-puljer. Der kan være op til fire af dem i systemet. Hver pool bruger selvfølgelig sit eget sæt SSD'er. Og allerede i egenskaberne for den virtuelle disk bestemmer vi, om den vil bruge en cache-pulje og hvilken. Aktivering og deaktivering af cachebrug for volumener kan udføres online uden at stoppe I/O. Du kan også varmt tilføje SSD'er til poolen og fjerne dem derfra. Når du opretter en SSD-pool-cache, skal du vælge, hvilken tilstand den skal fungere i: skrivebeskyttet eller læse+skrive. Dens fysiske organisation afhænger af dette. Da der kan være flere cache-puljer, kan deres funktionalitet være forskellig (det vil sige, at systemet kan have både læse- og læse+skrive-cache-puljer på samme tid).
Hvis der bruges en skrivebeskyttet cache-pulje, kan den bestå af 1-8 SSD'er. Diske behøver ikke at have samme kapacitet og samme leverandør, da de er kombineret til en NRAID+ struktur. Alle SSD'er i poolen er delt. Systemet forsøger uafhængigt at parallelisere indgående anmodninger mellem alle SSD'er for at opnå maksimal ydeevne. Hvis en af SSD'erne fejler, vil der ikke ske noget dårligt: Cachen indeholder trods alt kun en kopi af de data, der er gemt på rækken af harddiske. Det er bare, at mængden af tilgængelig SSD-cache vil falde (eller blive nul, hvis du bruger den originale SSD-cache fra ét drev).
Hvis cachen bruges til læse- og skriveoperationer, bør antallet af SSD'er i puljen være et multiplum af to, da indholdet spejles på par af drev (NRAID 1+-strukturen bruges). Det er nødvendigt at kopiere cachen, fordi den kan indeholde data, der endnu ikke er skrevet til harddiskene. Og i dette tilfælde ville svigt af SSD'en fra cachepuljen føre til tab af information. I tilfælde af NRAID 1+ vil en fejl på SSD'en blot føre til, at cachen overføres til en skrivebeskyttet tilstand, hvor uskrevne data bliver dumpet på harddisken. Efter udskiftning af den defekte SSD vender cachen tilbage til sin oprindelige driftstilstand. Af den måde, for større sikkerhed, kan du tildele dedikerede hot spares til en læse + skrive cache.
Når du bruger SSD-cachefunktionen i XCubeSAN, er der en række krav til mængden af hukommelse på lagercontrollere: Jo mere systemhukommelse, desto større cachepulje vil være tilgængelig.
I modsætning til de fleste lagersystemproducenter, som kun tilbyder en mulighed for at slå SSD-cachen til/fra, giver QSAN flere muligheder. Du kan især vælge cachedriftstilstand afhængigt af belastningens art. Der er tre forudindstillede skabeloner, der i deres drift er tættest på de tilsvarende tjenester: database, filsystem, webservice. Derudover kan administratoren oprette sin egen profil ved at indstille de nødvendige parameterværdier:
- Blokstørrelse (Cacheblokstørrelse) – 1/2/4 MB
- Antal anmodninger om at læse en blok, så den kopieres til cachen (Populate-on-Read Threshold) – 1..4
- Antal anmodninger om at skrive en blok, så den kopieres til cachen (Populate-on-Write Threshold) – 0..4
Profiler kan ændres med det samme, men selvfølgelig med indholdet af cachen nulstillet og dens nye "opvarmning".
I betragtning af princippet om drift af SSD-cachen kan vi fremhæve de vigtigste operationer, når vi arbejder med det:
Læser data, når de ikke er i cachen
- En anmodning fra værten ankommer til controlleren;
- Da de anmodede ikke er i SSD-cachen, læses de fra harddiskene;
- De læste data sendes til værten. Samtidig bliver der tjekket, om disse blokke er “hot”;
- Hvis ja, så kopieres de til SSD-cachen til videre brug.
Læs data, når de er til stede i cachen
- En anmodning fra værten ankommer til controlleren;
- Da de anmodede data er i SSD-cachen, læses de derfra;
- De læste data sendes til værten.
Skrivning af data ved brug af læsecache
- En skriveanmodning fra værten ankommer til controlleren;
- Data skrives til harddiske;
- Et svar, der indikerer vellykket optagelse, returneres til værten;
- Samtidig kontrolleres det, om blokken er "hot" (parameteren Populate-on-Write Threshold sammenlignes). Hvis ja, så kopieres den til SSD-cachen til senere brug.
Skrivning af data ved brug af en read+write cache
- En skriveanmodning fra værten ankommer til controlleren;
- Data skrives til SSD-cachen;
- Et svar, der indikerer vellykket optagelse, returneres til værten;
- Data fra SSD-cachen skrives til harddiske i baggrunden;
Tjek i aktion
Prøvestativ
2 servere (CPU: 2 x Xeon E5-2620v3 2.4Hz / RAM: 32GB) er forbundet med to porte via Fibre Channel 16G direkte til XCubeSAN XS5224D lagersystemet (16GB RAM/controller).
Vi brugte 16 x Seagate Constellation ES, ST500NM0001, 500GB, SAS 6Gb/s, kombineret i RAID5 (15+1), til dataarrayet og 8 x HGST Ultrastar SSD800MH.B, HUSMH8010BSS200, 100GB/SAS'er som ca.
2 bind blev oprettet: en for hver server.
Test 1. Skrivebeskyttet SSD-cache fra 1-8 SSD'er
SSD-cache
- I/O-type: Tilpasning
- Cacheblokstørrelse: 4MB
- Udfyld-ved-læs-tærskel: 1
- Udfyld-ved-skriv-tærskel: 0
I/O mønster
- Værktøj: IOmeter V1.1.0
- Arbejdere: 1
- Udestående (kødybde): 128
- Adgangsspecifikationer: 4KB, 100 % læst, 100 % tilfældigt
I teorien, jo flere SSD'er i cache-puljen, jo højere ydeevne. I praksis er dette blevet bekræftet. Den eneste væsentlige stigning i antallet af SSD'er med et lille antal volumener fører ikke til en eksplosiv effekt.
Test 2. SSD-cache i læse-+skrivetilstand med 2-8 SSD'er
SSD-cache
- I/O-type: Tilpasning
- Cacheblokstørrelse: 4MB
- Udfyld-ved-læs-tærskel: 1
- Udfyld-ved-skriv-tærskel: 1
I/O mønster
- Værktøj: IOmeter V1.1.0
- Arbejdere: 1
- Udestående (kødybde): 128
- Adgangsspecifikationer: 4KB, 100 % skrivning, 100 % tilfældig
Det samme resultat: eksplosiv vækst i ydeevnen og skalering i takt med, at antallet af SSD'er stiger.
I begge test var mængden af arbejdsdata mindre end den samlede cachestørrelse. Derfor blev alle blokke med tiden kopieret til cachen. Og arbejdet blev faktisk allerede udført med SSD'er, praktisk talt uden at påvirke harddiske. Formålet med disse tests var tydeligt at demonstrere effektiviteten af at varme cachen op og skalere dens ydeevne afhængigt af antallet af SSD'er.
Lad os nu vende tilbage til jorden og se en mere realistisk situation, når mængden af data er større end cachestørrelsen. For at testen skal bestå inden for rimelig tid (cache-opvarmningsperioden øges meget, når lydstyrken øges), vil vi begrænse volumenstørrelsen til 120 GB.
Test 3. Database-emulering
SSD-cache
- I/O-type: Database
- Cacheblokstørrelse: 1MB
- Udfyld-ved-læs-tærskel: 2
- Udfyld-ved-skriv-tærskel: 1
I/O mønster
- Værktøj: IOmeter V1.1.0
- Arbejdere: 1
- Udestående (kødybde): 128
- Adgangsspecifikationer: 8KB, 67 % læst, 100 % tilfældigt
dom
Den åbenlyse konklusion er selvfølgelig den gode effektivitet ved at bruge en SSD-cache til at forbedre ydeevnen af ethvert lagersystem. Anvendt til Denne erklæring gælder fuldt ud: SSD-cachefunktionen er implementeret perfekt. Det drejer sig om understøttelse af læse- og læse-+skrivetilstande, fleksible indstillinger til ethvert brugsscenarie, samt den overordnede ydeevne af systemet som helhed. Derfor kan du for en meget rimelig pris (licensprisen kan sammenlignes med prisen på 1-2 SSD'er) øge den samlede ydeevne betydeligt.
Kilde: www.habr.com