TeknologjitĂ« pĂ«r rritjen e performancĂ«s, tĂ« bazuara nĂ« pĂ«rdorimin e SSD dhe tĂ« aplikuara gjerĂ«sisht nĂ« sistemet e ruajtjes, janĂ« shpikur prej kohĂ«sh. Para sĂ« gjithash, kjo Ă«shtĂ« pĂ«rdorimi i SSD si hapĂ«sirĂ« pĂ«r ruajtje, e cila Ă«shtĂ« 100% efektive, por e shtrenjtĂ«. Prandaj, pĂ«rdoren teknologjitĂ« e tierimit dhe caching, ku SSD pĂ«rdoren vetĂ«m pĂ«r tĂ« dhĂ«nat mĂ« tĂ« kĂ«rkuara (âtĂ« nxehtaâ). Tierimi Ă«shtĂ« i mirĂ« pĂ«r skenarĂ« afatgjatĂ« (ditĂ«-javĂ«) tĂ« pĂ«rdorimit tĂ« tĂ« dhĂ«nave âtĂ« nxehtaâ. Caching, nga ana tjetĂ«r, pĂ«r pĂ«rdorim afatshkurtĂ«r (minuta-orĂ«). TĂ« dy kĂ«ta opsione realizohen nĂ« sistemet e ruajtjes. . NĂ« kĂ«tĂ« artikull do tĂ« shqyrtojmĂ« realizimin e algoritmit tĂ« dytĂ« â .
Thelbi i teknologjisë së SSD caching është përdorimi i SSD si një ndërlidhës midis disqeve të forta dhe memories operative të kontrollorit. Performanca e SSD, sigurisht, është më e ulët se performanca e caches së vet kontrollorit, por volumi është shumë më i madh. Prandaj, ne kemi një kompromis ndërmjet shpejtësisë dhe kapacitetit.
Shqyrtimi për përdorimin e SSD cache për lexim:
- Përparësia e operacioneve të leximit krahas operacioneve të shkruar (më së shumti karakteristike për bazat e të dhënave dhe aplikacionet web);
- Prania e një ngushtice në formë të performancës së grupit të disqeve të forta;
- Vëllimi i të dhënave të kërkuara është më i vogël se vëllimi i SSD cache.
Shqyrtimi pĂ«r pĂ«rdorimin e SSD cache pĂ«r lexim + shkruar janĂ« tĂ« njĂ«jtat arsye, pĂ«rveç natyrĂ«s sĂ« operacioneve â tip tĂ« pĂ«rzier (p.sh., serveri i skedarĂ«ve).
Shumica e ofruesve të sistemit të ruajtjes përdorin në produktet e tyre SSD cache vetëm për operacione të leximit. Dallimi thelbësor nga ata është mundësia e përdorimit të cache edhe për shkruar. Për aktivizimin e funksionalitetit të SSD caching në sistemin e ruajtjes QSAN, kërkohet blerja e një licence të veçantë (ofrohet në format elektronik).
SSD cache in XCubeSAN is physically implemented as separate SSD cache pools. The system can have up to four of them. Each pool, of course, uses its own set of SSDs. In the properties of the virtual disk, we specify whether it will use the cache pool and which one exactly. Enabling and disabling cache usage for volumes can be done online without interrupting input/output operations. Additionally, SSDs can be added to and removed from the pool on-the-fly. When creating an SSD cache pool, it is necessary to choose the mode in which it will operate: read-only or read+write. This determines its physical organization. Since there can be multiple cache pools, their functionality can be different (meaning the system can simultaneously have cache pools for reading and for reading+writing).
In the case of using a cache pool for reading only, it can consist of 1-8 SSDs. The drives do not necessarily have to be of the same capacity and vendor, as they are combined into an NRAID+ structure. All SSDs in the pool are used collectively. The system independently tries to parallelize incoming requests between all SSDs to achieve maximum performance. If one of the SSDs fails, nothing serious will happen: the cache only contains a copy of the data stored on the hard disk array. The available SSD cache capacity will simply be reduced (or become zero if the original SSD cache consists of a single drive).
If the cache is used for read + write operations, then the number of SSDs in the pool must be an even number, as the content is mirrored across pairs of drives (an NRAID 1+ structure is used). The duplication of the cache is necessary because it may contain data that has not yet been written to the hard disks. In this case, the failure of an SSD from the cache pool would lead to information loss. However, with an NRAID 1+ configuration, the failure of an SSD would simply switch the cache to 'read-only' mode while flushing unsaved data to the hard disk array. After replacing the faulty SSD, the cache will return to its original operating mode. For greater security, a dedicated hot spare can be assigned to a cache operating in read + write mode.
Kur përdoret funksioni i keqimin SSD në XCubeSAN, ka një sërë kërkesash për kapacitetin e memorjes së kontrollorëve të SCK: sa më shumë memorie sistemike, aq më shumë hapësirë do të jetë e disponueshme në pool-in e keqimit.
Përveç kësaj, ndryshe nga shumica e prodhuesve të SCK, të cilët ofrojnë vetëm një opsion për të aktivizuar / çaktivizuar keqimin SSD, QSAN ofron mundësi më të mëdha. Konkretisht, mund të zgjidhni modalitetin e funksionimit të keqimit në varësi të natyrës së ngarkesës. Ka tre modele të paracaktuara, më të afërta me shërbimet përkatëse: baza e të dhënave, sistemi i skedarëve, shërbimi web. Përveç kësaj, administratori mund të krijojë një profil të tij, duke vendosur vlerat përkatëse të parametrave:
- MadhĂ«sia e bllokut (Cache Block Size) â 1/2/4 MB
- Numri i kĂ«rkesave pĂ«r tĂ« lexuar njĂ« bllok, qĂ« ai tĂ« kopjohet nĂ« keqim (Populate-on-Read Threshold) â 1..4
- Numri i kĂ«rkesave pĂ«r tĂ« shkruar njĂ« bllok, qĂ« ai tĂ« kopjohet nĂ« keqim (Populate-on-Write Threshold) â 0..4
Profilit mund të ndryshohet "në flakë", por, natyrisht, me ri-nullimin e përmbajtjes së keqimit dhe me "ngrohjen" e re të tij.
Duke shqyrtuar parimin e funksionimit të keqimit SSD, mund të dallohen operacionet kryesore gjatë punës me të:
Leximi i të dhënave kur ato nuk janë në keqim.
- Kërkesa nga hosti arrin në kontrollor;
- Pasi të dhënat e kërkuara nuk janë në keqim SSD, ato lexohen nga disqet e ngurtë;
- Të dhënat e lexuara dërgohen te hosti. Njëkohësisht bëhet një kontroll nëse këto blloqe janë "të nxehta";
- Nëse po, ato kopjohen në keqim SSD për përdorim të mëtejshëm.
Leximi i të dhënave kur ato janë në keqim.
- Kërkesa nga hosti arrin në kontrollor;
- Pasi të dhënat e kërkuara janë në keqim SSD, ato lexohen prej andej;
- Të dhënat e lexuara dërgohen te hosti.
Shkrimi i të dhënave kur përdoret keqimi për lexim.
- Kërkesa për shkrim nga hosti arrin në kontrollor;
- Të dhënat shkruhen në disqet e ngurtë;
- Hostit i kthehet një përgjigje për shkrimin e suksesshëm;
- Njëkohësisht kontrollohet nëse blloku është "i nxehtë" (krahason parametër Populate-on-Write Threshold). Nëse po, ai kopjohet në keqim SSD për përdorim të mëtejshëm.
Shkrimi i të dhënave kur përdoret keqimi për lexim + shkrim.
- Kërkesa për shkrim nga hosti arrin në kontrollor;
- Të dhënat shkruhen në keqim SSD;
- Hostit i kthehet një përgjigje për shkrimin e suksesshëm;
- Të dhënat nga SSD cache regjistrohen pasivisht në hard disqet.
Kontrolli në veprim
Standi i testimit
2 servera (CPU: 2 x Xeon E5-2620v3 2.4Hz / RAM: 32GB) janë lidhur me dy porta përmes Fibre Channel 16G direkt në Storage XCubeSAN XS5224D (16GB RAM / kontrollues).
U përdorën 16 x Seagate Constellation ES, ST500NM0001, 500GB, SAS 6Gb/s, të kombinuar në RAID5 (15+1) për masivin e të dhënave dhe 8 x HGST Ultrastar SSD800MH.B, HUSMH8010BSS200, 100GB, SAS 12Gb/s si cache.
U krijuan 2 vëllime: një për çdo server.
Testi 1. SSD cache vetëm për lexim me 1-8 SSD
SSD Cache
- Lloji I/O: Personalizim
- Madhësia e Bllokut të Cache: 4MB
- Popullimi në prag për lexim: 1
- Popullimi në prag për shkruar: 0
Pattern I/O
- Mjeti: IOmeter V1.1.0
- Punëtorët: 1
- Derdhja e jashtme (Thellësia e Radhës): 128
- Specifikimet e Qasjes: 4KB, 100% Lexim, 100% Rastësor
Teorikisht, sa më shumë SSD në grupin e caches, aq më shumë performancë. Në praktikë, kjo u konfirmua gjithashtu. E vetmja, rritja e konsiderueshme e numrit të SSD-ve me një numër të vogël vëllimesh nuk çon në një efekt eksploziv.
Testi 2. SSD cache në modus leximi + shkrimi me 2-8 SSD
SSD Cache
- Lloji I/O: Personalizim
- Madhësia e Bllokut të Cache: 4MB
- Popullimi në prag për lexim: 1
- Popullimi në prag për shkruar: 1
Pattern I/O
- Mjeti: IOmeter V1.1.0
- Punëtorët: 1
- Derdhja e jashtme (Thellësia e Radhës): 128
- Specifikimet e Qasjes: 4KB, 100% Shkrim, 100% Rastësor
I njëjti rezultat: rritje eksplozive e performancës dhe shkallëzim me rritjen e numrit të SSD-ve.
Në të dy testet, volumi i të dhënave të punës ishte më i vogël se volumi total i caches. Prandaj, me kalimin e kohës të gjitha blloqet u kopjuan në cache. Dhe puna në thelb u krye me SSD, duke prekur praktikisht hard disqet. Qëllimi i këtyre testeve ishte të tregohej qartë efektiviteti i ngrohjes së caches dhe shkallëzimi i performancës së tij në varësi të numrit të SSD-ve.
Tani, le tĂ« kthehemi nga qiejt nĂ« tokĂ« dhe tĂ« kontrollojmĂ« njĂ« situatĂ« mĂ« realiste, kur volumi i tĂ« dhĂ«nave Ă«shtĂ« mĂ« i madh se madhĂ«sia e caches. NĂ« mĂ«nyrĂ« qĂ« testi tĂ« kalojĂ« brenda njĂ« kohe tĂ« arsyeshme (koha e ângrohjesâ sĂ« caches rritet ndjeshĂ«m me rritjen e madhĂ«sisĂ« sĂ« vĂ«llimit), do tĂ« kufizohemi nĂ« madhĂ«sinĂ« e vĂ«llimit prej 120GB.
Testi 3. Emulimi i punës së bazës së të dhënave
SSD Cache
- Lloji I/O: Baza e të dhënave
- Madhësia e Bllokut të Cache: 1MB
- Popullimi në prag për lexim: 2
- Popullimi në prag për shkruar: 1
Pattern I/O
- Mjeti: IOmeter V1.1.0
- Punëtorët: 1
- Derdhja e jashtme (Thellësia e Radhës): 128
- Specifikimet e Qasjes: 8KB, 67% Lexim, 100% Rastësor
Verdikti
Si një përfundim të dukshëm, padyshim se del një efikasitet i mirë në përdorimin e SSD cache për të rritur performancën e çdo sistemi ruajtjeje. Ky kjo deklaratë i përket plotësisht: funksioni i keqazhitjes SSD është realizuar shkëlqyeshëm. Kjo përfshin mbështetje për modulet e leximit dhe leximit + shkrimit, konfigurimin fleksibël të operimit për çdo skenar përdorimi, si dhe performancën përfundimtare të sistemit në tërësi. Prandaj, për një çmim shumë të arsyeshëm (çmimi i licencës është i krahasueshëm me çmimin e 1-2 SSD), është e mundur të rritet ndjeshëm performanca e përgjithshme.
Burimi: habr.com
