TechnologieĆ«n voor prestatieverbetering, gebaseerd op het gebruik van SSD's en veelvuldig toegepast in opslagsystemen, zijn al geruime tijd uitgevonden. Voorop staat het gebruik van SSD's als opslagruimte, wat 100% effectief maar duur is. Daarom worden technologieĆ«n zoals tiering en caching toegepast, waarbij SSD's alleen worden gebruikt voor de meest gevraagde (āheteā) gegevens. Tiering is nuttig voor scenario's van langdurig (dagen-weken) gebruik van āheteā data. Caching daarentegen is voor kortdurend (minuten-uren) gebruik. Beide opties zijn geĆÆmplementeerd in de opslagoplossing. . In dit artikel zullen we de implementatie van het tweede algoritme bekijken - .
De kern van de technologie van SSD-caching is het gebruik van SSD's als tussenliggende cache tussen harde schijven en het werkgeheugen van de controller. De prestaties van SSD's zijn weliswaar lager dan die van de eigen cache van de controller, maar de capaciteit is daarentegen veel groter. Dit levert een compromis op tussen snelheid en capaciteit.
Indicaties voor het gebruik van SSD-cache voor lezen:
- Het overwegen van leesoperaties boven schrijfoperaties (dit is vooral kenmerkend voor databases en webapplicaties);
- De aanwezigheid van een knelpunt in de prestaties van de array van harde schijven;
- Het volume van de gevraagde gegevens is kleiner dan het volume van de SSD-cache.
Indicaties voor het gebruik van SSD-cache voor lezen en schrijven zijn dezelfde redenen, met uitzondering van de aard van de operaties - een gemengd type (bijvoorbeeld, bestandserver).
De meeste leveranciers van opslagoplossingen gebruiken in hun producten SSD-cache alleen voor leesoperaties. Een wezenlijk verschil ten opzichte van hen is de mogelijkheid om de cache ook voor schrijven te gebruiken. Voor het activeren van de SSD-cachingfunctionaliteit in de QSAN-opslagoplossing is de aankoop van een aparte licentie vereist (wordt in elektronische vorm geleverd).
SSD-cache in XCubeSAN is physically implemented as separate SSD cache pools. The system can have up to four of them. Each pool uses its own set of SSDs. In the properties of the virtual disk, we define whether it will use the cache pool and which one. Enabling and disabling the cache for volumes can be done online without stopping input/output. Additionally, SSDs can be added to or removed from the pool on the fly. When creating an SSD cache pool, it is necessary to choose its operating mode: read-only or read+write. This determines its physical organization. Since there can be multiple cache pools, their functionality can vary (meaning there can be simultaneously reading-only and reading+writing cache pools in the system).
If the cache pool is used only for reading, it can consist of 1-8 SSDs. The disks do not necessarily have to be of the same capacity and vendor, as they are combined in an NRAID+ structure. All SSDs in the pool are used together. The system independently tries to parallelize incoming requests across all SSDs to achieve maximum performance. In the event of one of the SSDs failing, nothing critical will happen: the cache only contains a copy of the data stored on the hard disk array. The available SSD cache volume will simply decrease (or become zero if using an initial SSD cache from a single drive).
If the cache is used for read + write operations, the number of SSDs in the pool must be even, as the contents are mirrored across pairs of drives (using an NRAID 1+ structure). Cache duplication is necessary because it may contain data that has not yet been recorded on the hard disks. In this case, if an SSD from the cache pool fails, it would lead to data loss. However, in the case of NRAID 1+, the failure of an SSD will simply cause the cache to switch to a 'read-only' mode, flushing unsaved data to the hard disk array. After replacing the faulty SSD, the cache will return to its original mode of operation. For added safety, a dedicated hot spare can be assigned to a cache operating in read + write mode.
Bij het gebruik van de SSD-cachefunctie in XCubeSAN zijn er enkele vereisten wat betreft het geheugenvolume van de opslagcontrollers: hoe meer systeemgeheugen, hoe groter de beschikbare cachepool.
In tegenstelling tot de meeste opslagfabrikanten, die alleen de optie bieden om de SSD-cache in of uit te schakelen, biedt QSAN meer mogelijkheden. Zo kunt u de cachemodus kiezen op basis van de aard van de belasting. Er zijn drie vooraf ingestelde sjablonen die het meest overeenkomen met de respectieve diensten: database, bestandssysteem, webservice. Daarnaast kan de beheerder zijn eigen profiel aanmaken door de vereiste parameterwaarden in te stellen:
- Blokgrootte (Cache Block Size) ā 1/2/4 MB
- Aantal leesopvragingen voor een blok om het in de cache te kopiĆ«ren (Populate-on-Read Threshold) ā 1..4
- Aantal schrijfovervragen voor een blok om het in de cache te kopiĆ«ren (Populate-on-Write Threshold) ā 0..4
Profielen kunnen 'on the fly' worden gewijzigd, maar natuurlijk met het wissen van de cache-inhoud en het opnieuw 'opwarmen' ervan.
Bij het overwegen van het principe van de SSD-cache kunnen de belangrijkste bewerkingen worden onderscheiden:
Gegevens lezen wanneer ze niet in de cache aanwezig zijn
- Het verzoek van de host komt binnen bij de controller;
- Aangezien de gevraagde gegevens niet in de SSD-cache zijn, worden ze gelezen van de harde schijven;
- De gelezen gegevens worden naar de host verzonden. Tegelijkertijd wordt gecontroleerd of deze blokken 'heet' zijn;
- Als dat zo is, worden ze naar de SSD-cache gekopieerd voor verder gebruik.
Gegevens lezen wanneer ze in de cache aanwezig zijn
- Het verzoek van de host komt binnen bij de controller;
- Aangezien de gevraagde gegevens in de SSD-cache aanwezig zijn, worden ze daaruit gelezen;
- De gelezen gegevens worden naar de host verzonden.
Gegevens schrijven met behulp van een leescache
- Het schrijfreferentieverzoek van de host komt binnen bij de controller;
- Gegevens worden geschreven naar de harde schijven;
- De host ontvangt een bevestiging van een succesvolle schrijfactie;
- Tegelijkertijd wordt gecontroleerd of het blok 'heet' is (de parameter Populate-on-Write Threshold wordt vergeleken). Als dat zo is, wordt het naar de SSD-cache gekopieerd voor later gebruik.
Gegevens schrijven met behulp van een lees- + schrijfcache
- Het schrijfreferentieverzoek van de host komt binnen bij de controller;
- Gegevens worden naar de SSD-cache geschreven;
- De host ontvangt een bevestiging van een succesvolle schrijfactie;
- Gegevens uit de SSD-cache worden op de achtergrond opgeslagen op harde schijven;
Controle in de zaak
Teststand
2 servers (CPU: 2 x Xeon E5-2620v3 2,4Hz / RAM: 32GB) zijn verbonden met twee poorten via Fibre Channel 16G rechtstreeks aan de SAN XCubeSAN XS5224D (16GB RAM/controller).
Er werden 16 x Seagate Constellation ES, ST500NM0001, 500GB, SAS 6Gb/s gebruikt, samengevoegd in RAID5 (15+1), voor de datavolumes en 8 x HGST Ultrastar SSD800MH.B, HUSMH8010BSS200, 100GB, SAS 12Gb/s als cache.
Er werden 2 volumes aangemaakt: Ć©Ć©n voor elke server.
Test 1. SSD-cache alleen voor lezen met 1-8 SSD's
SSD-cache
- I/O-type: Aanpassing
- Cacheblokgrootte: 4MB
- Populate-on-read-drempel: 1
- Populate-on-write-drempel: 0
I/O-patroon
- Tool: IOmeter V1.1.0
- Werknemers: 1
- Outstanding (wachttiefe): 128
- Toegangspecificaties: 4KB, 100% lezen, 100% willekeurig
In theorie, hoe groter het aantal SSD's in de cachepool, hoe hoger de prestatie. In de praktijk is dit bevestigd. De enige uitzondering is dat een significante toename van het aantal SSD's zonder veel volumes niet leidt tot een explosief effect.
Test 2. SSD-cache in lees + schrijfmode met 2-8 SSD's
SSD-cache
- I/O-type: Aanpassing
- Cacheblokgrootte: 4MB
- Populate-on-read-drempel: 1
- Populate-on-write-drempel: 1
I/O-patroon
- Tool: IOmeter V1.1.0
- Werknemers: 1
- Outstanding (wachttiefe): 128
- Toegangspecificaties: 4KB, 100% schrijven, 100% willekeurig
Hetzelfde resultaat: explosieve prestatiegroei en opschaling bij toenemend aantal SSD's.
In beide tests was het volume van de werkgegevens kleiner dan het totale volume van de cache. Daarom werden na verloop van tijd alle blokken naar de cache gekopieerd. En het werk werd feitelijk uitgevoerd met SSD's, vrijwel zonder de harde schijven te belasten. Het doel van deze tests was om de effectiviteit van het voorverwarmen van de cache en de opschaling van de prestatie naargelang het aantal SSD's duidelijk te demonstreren.
Laten we nu terugkomen op de realiteit en een meer levenssituatie controleren, waarbij het datavolume groter is dan de grootte van de cache. Om de test binnen een redelijke tijd te laten plaatsvinden (de āvoorverwarmingstijdā van de cache neemt sterk toe met de volumegroote), beperken we ons tot een volumegrootte van 120GB.
Test 3. Emulatie van databasewerk
SSD-cache
- I/O-type: Database
- Cacheblokgrootte: 1MB
- Populate-on-read-drempel: 2
- Populate-on-write-drempel: 1
I/O-patroon
- Tool: IOmeter V1.1.0
- Werknemers: 1
- Outstanding (wachttiefe): 128
- Toegangspecificaties: 8KB, 67% lezen, 100% willekeurig
Verdict
Als een voor de hand liggende conclusie komt, blijkt het gebruik van SSD-cache zeker effectief te zijn voor de prestatieverhoging van elke SAN. Dit is van toepassing op Deze verklaring geldt in zijn geheel: de SSD-cachefunctie is uitstekend geĆÆmplementeerd. Dit omvat ondersteuning voor lees- en lees + schrijfmodes, flexibele configuratie voor verschillende gebruiksscenario's, en de algehele systeemperformance. Voor een zeer redelijke prijs (de licentiekosten zijn vergelijkbaar met de kosten van 1-2 SSD's) kan de algehele performance aanzienlijk worden verhoogd.
Bron: habr.com
