Technologieën voor het verbeteren van de prestaties op basis van het gebruik van SSD's en die veel worden gebruikt in opslagsystemen, zijn al lang uitgevonden. Allereerst is het het gebruik van SSD als opslagruimte, dat 100% effectief is, maar duur. Daarom worden vermoeiende en caching-technologieën gebruikt, waarbij SSD's alleen worden gebruikt voor de meest populaire ("hot") gegevens. Tiering is goed voor scenario's van langdurig (dagen-weken) gebruik van ‘hot’ data. Caching daarentegen is bedoeld voor gebruik op korte termijn (minuten-uren). Beide opties zijn geïmplementeerd in het opslagsysteem . In dit artikel zullen we kijken naar de implementatie van het tweede algoritme - .
De essentie van SSD-cachingtechnologie is het gebruik van SSD's als tussencache tussen harde schijven en het RAM van de controller. De prestaties van de SSD zijn uiteraard lager dan de prestaties van de eigen cache van de controller, maar het volume is een orde van grootte hoger. Daarom krijgen we een bepaald compromis tussen snelheid en volume.
Indicaties voor het gebruik van SSD-cache voor lezen:
- Het overwicht van leesbewerkingen op schrijfbewerkingen (meestal typisch voor databases en webapplicaties);
- De aanwezigheid van een knelpunt in de vorm van prestaties van de harde schijfarray;
- De hoeveelheid benodigde gegevens is kleiner dan de grootte van de SSD-cache.
De indicaties voor het gebruik van een lees- en schrijf-SSD-cache zijn hetzelfde, behalve de aard van de bewerkingen: gemengd type (bijvoorbeeld bestandsserver).
De meeste opslagleveranciers gebruiken alleen-lezen SSD-cache in hun producten. Het fundamentele verschil Ze bieden de mogelijkheid om de cache ook voor schrijven te gebruiken. Om de SSD-cachingfunctionaliteit in QSAN-opslagsystemen te activeren, moet u een afzonderlijke licentie aanschaffen (elektronisch geleverd).
De SSD-cache in XCubeSAN is fysiek geïmplementeerd in de vorm van afzonderlijke SSD-cachepools. Er kunnen er maximaal vier in het systeem zijn. Elke pool gebruikt uiteraard zijn eigen set SSD's. En al in de eigenschappen van de virtuele schijf bepalen we of deze een cachepool zal gebruiken en welke. Het in- en uitschakelen van het cachegebruik voor volumes kan online worden gedaan zonder de I/O te stoppen. Je kunt ook SSD's aan de pool toevoegen en ze daar verwijderen. Wanneer u een SSD-poolcache maakt, moet u kiezen in welke modus deze zal werken: alleen-lezen of lezen+schrijven. De fysieke organisatie ervan hangt hiervan af. Omdat er meerdere cachepools kunnen zijn, kan hun functionaliteit verschillend zijn (dat wil zeggen dat het systeem tegelijkertijd zowel lees- als lees+schrijf-cachepools kan hebben).
Als er een alleen-lezen cachepool wordt gebruikt, kan deze uit 1-8 SSD's bestaan. Schijven hoeven niet dezelfde capaciteit en dezelfde leverancier te hebben, aangezien ze gecombineerd zijn in een NRAID+-structuur. Alle SSD's in de pool worden gedeeld. Het systeem probeert onafhankelijk binnenkomende verzoeken tussen alle SSD's te parallelliseren om maximale prestaties te bereiken. Als een van de SSD's uitvalt, gebeurt er niets ergs: de cache bevat immers alleen een kopie van de gegevens die op de array met harde schijven zijn opgeslagen. Het is alleen zo dat de hoeveelheid beschikbare SSD-cache zal afnemen (of nul zal worden als u de originele SSD-cache van één schijf gebruikt).
Als de cache wordt gebruikt voor lees- en schrijfbewerkingen, moet het aantal SSD's in de pool een veelvoud van twee zijn, omdat de inhoud wordt gespiegeld op schijfparen (de NRAID 1+-structuur wordt gebruikt). Het dupliceren van de cache is noodzakelijk omdat deze gegevens kan bevatten die nog niet naar de harde schijven zijn geschreven. En in dit geval zou het falen van de SSD uit de cachepool leiden tot verlies van informatie. In het geval van NRAID 1+ zal een storing van de SSD er simpelweg toe leiden dat de cache wordt overgebracht naar een alleen-lezen-status, waarbij ongeschreven gegevens op de harde schijf worden gedumpt. Na het vervangen van de defecte SSD keert de cache terug naar de oorspronkelijke bedrijfsmodus. Voor meer veiligheid kunt u trouwens speciale hot spares toewijzen aan een lees- en schrijfcache.
Bij gebruik van de SSD-cachingfunctie in XCubeSAN zijn er een aantal vereisten voor de hoeveelheid geheugen van opslagcontrollers: hoe meer systeemgeheugen, hoe groter de cachepool beschikbaar zal zijn.
In tegenstelling tot de meeste fabrikanten van opslagsystemen, die alleen een optie bieden om de SSD-cache in of uit te schakelen, biedt QSAN meer opties. In het bijzonder kunt u de cache-werkmodus selecteren, afhankelijk van de aard van de belasting. Er zijn drie vooraf ingestelde sjablonen die qua werking het dichtst in de buurt komen van de overeenkomstige services: database, bestandssysteem, webservice. Bovendien kan de beheerder zijn eigen profiel aanmaken door de vereiste parameterwaarden in te stellen:
- Blokgrootte (cacheblokgrootte) – 1/2/4 MB
- Aantal verzoeken om een blok te lezen zodat het naar de cache wordt gekopieerd (Populate-on-Read Threshold) – 1..4
- Aantal verzoeken om een blok te schrijven zodat het naar de cache wordt gekopieerd (Populate-on-Write Threshold) – 0..4
Profielen kunnen direct worden gewijzigd, maar uiteraard met de inhoud van de cache-reset en de nieuwe “opwarming”.
Gezien het werkingsprincipe van de SSD-cache, kunnen we de belangrijkste bewerkingen benadrukken wanneer we ermee werken:
Gegevens lezen wanneer deze zich niet in de cache bevinden
- Een verzoek van de host arriveert bij de controller;
- Omdat de gevraagde bestanden niet in de SSD-cache staan, worden ze vanaf de harde schijven gelezen;
- De gelezen gegevens worden naar de host verzonden. Tegelijkertijd wordt gecontroleerd of deze blokken “hot” zijn;
- Zo ja, dan worden ze voor verder gebruik naar de SSD-cache gekopieerd.
Gegevens lezen wanneer deze aanwezig zijn in de cache
- Een verzoek van de host arriveert bij de controller;
- Omdat de opgevraagde gegevens zich in de SSD-cache bevinden, worden deze van daaruit gelezen;
- De gelezen gegevens worden naar de host verzonden.
Gegevens schrijven bij gebruik van leescache
- Een schrijfverzoek van de host arriveert bij de controller;
- Gegevens worden naar harde schijven geschreven;
- Een antwoord dat een succesvolle opname aangeeft, wordt teruggestuurd naar de host;
- Tegelijkertijd wordt gecontroleerd of het blok “hot” is (de parameter Populate-on-Write Threshold wordt vergeleken). Zo ja, dan wordt het naar de SSD-cache gekopieerd voor later gebruik.
Gegevens schrijven bij gebruik van een lees- en schrijfcache
- Een schrijfverzoek van de host arriveert bij de controller;
- Gegevens worden naar de SSD-cache geschreven;
- Een antwoord dat een succesvolle opname aangeeft, wordt teruggestuurd naar de host;
- Gegevens uit de SSD-cache worden op de achtergrond naar harde schijven geschreven;
Inchecken in actie
Testbank
2 servers (CPU: 2 x Xeon E5-2620v3 2.4 Hz / RAM: 32 GB) zijn via twee poorten via Fibre Channel 16G rechtstreeks verbonden met het XCubeSAN XS5224D opslagsysteem (16 GB RAM/controller).
We gebruikten 16 x Seagate Constellation ES, ST500NM0001, 500GB, SAS 6Gb/s, gecombineerd in RAID5 (15+1), voor de data-array en 8 x HGST Ultrastar SSD800MH.B, HUSMH8010BSS200, 100GB, SAS 12Gb/s als cache
Er zijn 2 volumes gemaakt: één voor elke server.
Test 1. Alleen-lezen SSD-cache van 1-8 SSD's
SSD-cache
- I/O-type: maatwerk
- Cacheblokgrootte: 4 MB
- Drempelwaarde voor vullen bij lezen: 1
- Drempelwaarde voor invullen bij schrijven: 0
I/O-patroon
- Gereedschap: IOmeter V1.1.0
- Arbeiders: 1
- Uitstekend (wachtrijdiepte): 128
- Toegangsspecificaties: 4 KB, 100% lezen, 100% willekeurig
In theorie geldt: hoe meer SSD's in de cachepool, hoe hoger de prestaties. In de praktijk wordt dit bevestigd. De enige significante toename van het aantal SSD's met een klein aantal volumes leidt niet tot een explosief effect.
Test 2. SSD-cache in lees- en schrijfmodus met 2-8 SSD's
SSD-cache
- I/O-type: maatwerk
- Cacheblokgrootte: 4 MB
- Drempelwaarde voor vullen bij lezen: 1
- Drempelwaarde voor invullen bij schrijven: 1
I/O-patroon
- Gereedschap: IOmeter V1.1.0
- Arbeiders: 1
- Uitstekend (wachtrijdiepte): 128
- Toegangsspecificaties: 4 KB, 100% schrijven, 100% willekeurig
Hetzelfde resultaat: explosieve prestatiegroei en schaalvergroting naarmate het aantal SSD's toeneemt.
In beide tests was de hoeveelheid werkgegevens kleiner dan de totale cachegrootte. Daarom werden na verloop van tijd alle blokken naar de cache gekopieerd. En het werk werd feitelijk al uitgevoerd met SSD's, vrijwel zonder dat dit gevolgen had voor de harde schijven. Het doel van deze tests was om duidelijk de effectiviteit aan te tonen van het opwarmen van de cache en het schalen van de prestaties, afhankelijk van het aantal SSD's.
Laten we nu terug naar de aarde komen en een meer realistische situatie bekijken, waarin de hoeveelheid gegevens groter is dan de cachegrootte. Om ervoor te zorgen dat de test binnen een redelijke tijd slaagt (de opwarmperiode van de cache neemt enorm toe naarmate de volumegrootte toeneemt), beperken we de volumegrootte tot 120 GB.
Test 3. Database-emulatie
SSD-cache
- I/O-type: Database
- Cacheblokgrootte: 1 MB
- Drempelwaarde voor vullen bij lezen: 2
- Drempelwaarde voor invullen bij schrijven: 1
I/O-patroon
- Gereedschap: IOmeter V1.1.0
- Arbeiders: 1
- Uitstekend (wachtrijdiepte): 128
- Toegangsspecificaties: 8 KB, 67% lezen, 100% willekeurig
vonnis
De voor de hand liggende conclusie is natuurlijk de goede efficiëntie van het gebruik van een SSD-cache om de prestaties van elk opslagsysteem te verbeteren. Toegepast op Deze uitspraak is volledig van toepassing: de SSD-cachingfunctie is perfect geïmplementeerd. Dit betreft ondersteuning voor lees- en lees-+schrijfmodi, flexibele instellingen voor elk gebruiksscenario, evenals de algehele prestaties van het systeem als geheel. Daarom kunt u tegen een zeer redelijke prijs (de licentieprijs vergelijkbaar met de kosten van 1-2 SSD's) de algehele prestaties aanzienlijk verbeteren.
Bron: www.habr.com