Teknologier for å forbedre ytelsen basert på bruk av SSD-er og mye brukt i lagringssystemer har lenge blitt oppfunnet. For det første er det bruken av SSD som lagringsplass, som er 100 % effektivt, men dyrt. Derfor brukes anstrengende og caching-teknologier, der SSD-er kun brukes til de mest populære ("hot") dataene. Tiering er bra for scenarier med langsiktig (dager-uker) bruk av "varme" data. Caching, tvert imot, er for kortvarig (minutter-timer) bruk. Begge disse alternativene er implementert i lagringssystemet . I denne artikkelen vil vi se på implementeringen av den andre algoritmen - .
Essensen av SSD-caching-teknologi er bruken av SSD-er som en mellombuffer mellom harddisker og kontrollerens RAM. Ytelsen til SSD-en er selvfølgelig lavere enn ytelsen til kontrollerens egen cache, men volumet er en størrelsesorden høyere. Derfor får vi et visst kompromiss mellom hastighet og volum.
Indikasjoner for bruk av SSD-cache for lesing:
- Overvekt av leseoperasjoner over skriveoperasjoner (oftest typisk for databaser og webapplikasjoner);
- Tilstedeværelsen av en flaskehals i form av ytelsen til harddisken;
- Mengden nødvendige data er mindre enn størrelsen på SSD-cachen.
Indikasjonene for bruk av en lese+skrive SSD-hurtigbuffer er de samme, bortsett fra arten av operasjonene – blandet type (for eksempel filserver).
De fleste lagringsleverandører bruker skrivebeskyttet SSD-buffer i produktene sine. Den grunnleggende forskjellen De gir muligheten til å bruke hurtigbufferen til å skrive også. For å aktivere SSD-bufringsfunksjonaliteten i QSAN-lagringssystemer, må du kjøpe en separat lisens (leveres elektronisk).
SSD-cachen i XCubeSAN er fysisk implementert i form av separate SSD-cache-pooler. Det kan være opptil fire av dem i systemet. Hvert basseng bruker selvfølgelig sitt eget sett med SSD-er. Og allerede i egenskapene til den virtuelle disken bestemmer vi om den vil bruke en cache-pool og hvilken. Aktivering og deaktivering av cache-bruk for volumer kan gjøres online uten å stoppe I/O. Du kan også legge til SSD-er i bassenget og fjerne dem derfra. Når du oppretter en SSD-bassengbuffer, må du velge hvilken modus den skal fungere i: skrivebeskyttet eller lese+skrive. Dens fysiske organisering avhenger av dette. Siden det kan være flere cache-pooler, kan funksjonaliteten deres være forskjellig (det vil si at systemet kan ha både lese- og lese+skrive-cache-pooler samtidig).
Hvis en skrivebeskyttet cache-pool brukes, kan den bestå av 1-8 SSD-er. Disker trenger ikke å ha samme kapasitet og samme leverandør, da de er kombinert til en NRAID+-struktur. Alle SSD-er i bassenget er delt. Systemet prøver uavhengig å parallellisere innkommende forespørsler mellom alle SSD-er for å oppnå maksimal ytelse. Hvis en av SSD-ene svikter, vil ikke noe vondt skje: cachen inneholder tross alt bare en kopi av dataene som er lagret på utvalget av harddisker. Det er bare at mengden tilgjengelig SSD-cache vil reduseres (eller bli null hvis du bruker den originale SSD-cachen fra én stasjon).
Hvis hurtigbufferen brukes til lese- og skriveoperasjoner, bør antallet SSD-er i bassenget være et multiplum av to, siden innholdet speiles på par med stasjoner (NRAID 1+-strukturen brukes). Duplisering av hurtigbufferen er nødvendig fordi den kan inneholde data som ennå ikke er skrevet til harddiskene. Og i dette tilfellet vil svikt i SSD-en fra cache-poolen føre til tap av informasjon. Når det gjelder NRAID 1+, vil en feil på SSD-en ganske enkelt føre til at hurtigbufferen overføres til en skrivebeskyttet tilstand, med uskrevne data som dumpes på harddisken. Etter å ha erstattet den defekte SSD-en, vil cachen gå tilbake til sin opprinnelige driftsmodus. For større sikkerhet kan du forresten tilordne dedikerte reservedeler til en lese- og skrivebuffer.
Når du bruker SSD-bufringsfunksjonen i XCubeSAN, er det en rekke krav til minnemengden til lagringskontrollere: jo mer systemminne, jo større cache-pool vil være tilgjengelig.
I motsetning til de fleste lagringssystemprodusenter, som bare tilbyr et alternativ for å slå på/av SSD-cachen, gir QSAN flere alternativer. Spesielt kan du velge cache-driftsmodus avhengig av belastningens art. Det er tre forhåndsinnstilte maler som i sin drift er nærmest de tilsvarende tjenestene: database, filsystem, webtjeneste. I tillegg kan administratoren opprette sin egen profil ved å angi de nødvendige parameterverdiene:
- Blokkstørrelse (Cache Block Size) – 1/2/4 MB
- Antall forespørsler om å lese en blokk slik at den kopieres til hurtigbufferen (Populate-on-Read Threshold) – 1..4
- Antall forespørsler om å skrive en blokk slik at den blir kopiert til hurtigbufferen (Populate-on-Write Threshold) – 0..4
Profiler kan endres med en gang, men selvfølgelig med innholdet i cachen tilbakestilt og dens nye "oppvarming".
Med tanke på prinsippet om drift av SSD-cachen, kan vi fremheve hovedoperasjonene når vi jobber med den:
Leser data når de ikke er i hurtigbufferen
- En forespørsel fra verten kommer til kontrolleren;
- Siden de forespurte ikke er i SSD-cachen, leses de fra harddiskene;
- Lesedataene sendes til verten. Samtidig foretas en sjekk for å se om disse blokkene er «varme»;
- Hvis ja, blir de kopiert til SSD-cachen for videre bruk.
Les data når de er til stede i hurtigbufferen
- En forespørsel fra verten kommer til kontrolleren;
- Siden de forespurte dataene er i SSD-cachen, leses de derfra;
- Lesedataene sendes til verten.
Skrive data ved bruk av lesebuffer
- En skriveforespørsel fra verten kommer til kontrolleren;
- Data skrives til harddisker;
- Et svar som indikerer vellykket opptak returneres til verten;
- Samtidig sjekkes det om blokken er "hot" (populate-on-write Threshold-parameteren sammenlignes). Hvis ja, kopieres den til SSD-cachen for senere bruk.
Skrive data ved bruk av en lese+skrivebuffer
- En skriveforespørsel fra verten kommer til kontrolleren;
- Data skrives til SSD-cachen;
- Et svar som indikerer vellykket opptak returneres til verten;
- Data fra SSD-cachen skrives til harddisker i bakgrunnen;
Sjekk i aksjon
Prøvestativ
2 servere (CPU: 2 x Xeon E5-2620v3 2.4Hz / RAM: 32GB) kobles med to porter via Fibre Channel 16G direkte til XCubeSAN XS5224D lagringssystem (16GB RAM/kontroller).
Vi brukte 16 x Seagate Constellation ES, ST500NM0001, 500GB, SAS 6Gb/s, kombinert i RAID5 (15+1), for datamatrisen og 8 x HGST Ultrastar SSD800MH.B, HUSMH8010BSS200, 100GB/SAS som ca.
2 bind ble opprettet: ett for hver server.
Test 1. Skrivebeskyttet SSD-buffer fra 1-8 SSD-er
SSD-hurtigbuffer
- I/O-type: Tilpasning
- Bufferblokkstørrelse: 4MB
- Fyll ut ved lesing-terskel: 1
- Fyll inn-ved-skriv-terskel: 0
I/O-mønster
- Verktøy: IOmeter V1.1.0
- Arbeidere: 1
- Enestående (kødybde): 128
- Tilgangsspesifikasjoner: 4KB, 100 % lest, 100 % tilfeldig
I teorien, jo flere SSD-er i cache-poolen, jo høyere ytelse. I praksis er dette bekreftet. Den eneste betydelige økningen i antall SSD-er med et lite antall volumer fører ikke til en eksplosiv effekt.
Test 2. SSD-cache i lese + skrivemodus med 2-8 SSD-er
SSD-hurtigbuffer
- I/O-type: Tilpasning
- Bufferblokkstørrelse: 4MB
- Fyll ut ved lesing-terskel: 1
- Fyll inn-ved-skriv-terskel: 1
I/O-mønster
- Verktøy: IOmeter V1.1.0
- Arbeidere: 1
- Enestående (kødybde): 128
- Tilgangsspesifikasjoner: 4KB, 100 % skriving, 100 % tilfeldig
Det samme resultatet: eksplosiv ytelsesvekst og skalering etter hvert som antall SSD-er øker.
I begge testene var mengden arbeidsdata mindre enn den totale bufferstørrelsen. Derfor ble alle blokkene over tid kopiert til cachen. Og arbeidet ble faktisk allerede utført med SSD-er, praktisk talt uten å påvirke harddiskene. Hensikten med disse testene var å tydelig demonstrere effektiviteten av å varme opp cachen og skalere ytelsen avhengig av antall SSD-er.
La oss nå komme tilbake til jorden og sjekke en mer realistisk situasjon, når datamengden er større enn cachestørrelsen. For at testen skal bestå i løpet av rimelig tid (cache-oppvarmingsperioden øker kraftig ettersom volumstørrelsen øker), vil vi begrense volumstørrelsen til 120 GB.
Test 3. Databaseemulering
SSD-hurtigbuffer
- I/O-type: Database
- Bufferblokkstørrelse: 1MB
- Fyll ut ved lesing-terskel: 2
- Fyll inn-ved-skriv-terskel: 1
I/O-mønster
- Verktøy: IOmeter V1.1.0
- Arbeidere: 1
- Enestående (kødybde): 128
- Tilgangsspesifikasjoner: 8KB, 67 % lest, 100 % tilfeldig
dommen
Den åpenbare konklusjonen er selvfølgelig den gode effektiviteten ved å bruke en SSD-cache for å forbedre ytelsen til ethvert lagringssystem. Påføres Denne uttalelsen gjelder fullt ut: SSD-bufringsfunksjonen er implementert perfekt. Dette gjelder støtte for lese- og lese-+skrivemoduser, fleksible innstillinger for ethvert bruksscenario, samt den generelle ytelsen til systemet som helhet. Derfor, for en svært rimelig kostnad (lisensprisen er sammenlignbar med prisen på 1-2 SSD-er), kan du øke den totale ytelsen betydelig.
Kilde: www.habr.com