Technologie zwiększające wydajność, oparte na wykorzystaniu SSD i powszechnie stosowane w systemach pamięci masowej, zostały wynalezione już jakiś czas temu. Przede wszystkim chodzi o zastosowanie SSD jako przestrzeni magazynowej, co jest w 100% efektywne, ale kosztowne. Dlatego wprowadzane są technologie tieringu i caching, gdzie SSD są używane tylko dla najczęściej używanych ("gorących") danych. Tiering jest dobry do scenariuszy długoterminowego (dni-tygodnie) użycia "gorących" danych. Natomiast caching jest przeznaczony do krótkoterminowego (minuty-godziny) wykorzystania. Oba te warianty są realizowane w systemach pamięci masowej. . W tym artykule omówimy realizację drugiego algorytmu – .
Istota technologii cachingu SSD polega na wykorzystaniu SSD jako pośredniej pamięci podręcznej pomiędzy dyskami twardymi a pamięcią RAM kontrolera. Wydajność SSD jest oczywiście niższa niż wydajność wbudowanej pamięci podręcznej kontrolera, ale pojemność jest znacznie wyższa. Dlatego uzyskujemy pewien kompromis między szybkością a pojemnością.
Wskazania do użycia SSD jako pamięci podręcznej do odczytu:
- Przewaga operacji odczytu nad operacjami zapisu (najczęściej charakterystyczna dla baz danych i aplikacji internetowych);
- Obecność wąskiego gardła w postaci wydajności macierzy dysków twardych;
- Objętość wymaganych danych jest mniejsza niż objętość pamięci podręcznej SSD.
Wskazania do użycia SSD jako pamięci podręcznej do odczytu i zapisu są te same, z wyjątkiem charakteru operacji – typ mieszany (na przykład serwer plików).
Większość dostawców systemów pamięci masowej wykorzystuje w swoich produktach caching SSD tylko do operacji odczytu. Kluczową różnicą jest możliwość użycia pamięci podręcznej również do zapisu. Aby aktywować funkcjonalność cachingu SSD w systemach pamięci masowej QSAN, należy zakupić oddzielną licencję (dostarczaną w formie elektronicznej).
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 a cache pool and which one. You can enable and disable cache usage for volumes in online mode without stopping input/output. Additionally, SSDs can be added to or removed from the pool while it is active. When creating an SSD cache pool, it is necessary to choose its operating mode: read-only or read+write. This affects its physical organization. Since there can be multiple cache pools, their functionality can vary (meaning that the system can have both read and read+write cache pools simultaneously).
If the cache pool is used only for reading, it can consist of 1-8 SSDs. The drives do not have to be of the same capacity or vendor, as they are combined into an NRAID+ structure. All SSDs in the pool are used collectively. The system 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 in the case of an initial SSD cache from a single drive).
However, if the cache is used for read + write operations, the number of SSDs in the pool must be even, as the content is mirrored on pairs of drives (using an NRAID 1+ structure). Cache duplication is necessary because it may contain data that has not yet been written to the hard drives. In this case, the failure of an SSD from the cache pool would lead to data loss. With NRAID 1+, the failure of an SSD simply results in the cache switching to 'read-only' mode, resetting any unwritten data to the hard disk array. After replacing the faulty SSD, the cache will return to its original operational mode. For added safety, a dedicated hot spare can be assigned to caches operating on read + write.
Podczas korzystania z funkcji pamięci podręcznej SSD w XCubeSAN istnieje szereg wymagań dotyczących pamięci kontrolerów macierzy dyskowych: im więcej pamięci systemowej, tym większa pojemność puli pamięci podręcznej będzie dostępna.
W przeciwieństwie do większości producentów macierzy dyskowych, którzy oferują tylko opcję włączenia/wyłączenia pamięci podręcznej SSD, QSAN zapewnia znacznie większe możliwości. W szczególności można wybrać tryb pracy pamięci podręcznej w zależności od charakterystyki obciążenia. Istnieją trzy wstępnie skonfigurowane szablony, które najbardziej odpowiadają odpowiednim usługom: baza danych, system plików, usługa internetowa. Dodatkowo administrator może stworzyć własny profil, określając wymagane wartości parametrów:
- Rozmiar bloku (Cache Block Size) – 1/2/4 MB
- Liczba żądań odczytu bloku, aby został skopiowany do pamięci podręcznej (Populate-on-Read Threshold) – 1..4
- Liczba żądań zapisu bloku, aby został skopiowany do pamięci podręcznej (Populate-on-Write Threshold) – 0..4
Profile można zmieniać 'w locie', ale oczywiście z zerowaniem zawartości pamięci podręcznej i jej nowym 'ogrzewaniem'.
Rozważając zasady działania pamięci podręcznej SSD, można wyróżnić podstawowe operacje podczas pracy z nią:
Odczyt danych, gdy nie są dostępne w pamięci podręcznej
- Żądanie od hosta trafia do kontrolera;
- Ponieważ żądane dane nie znajdują się w pamięci podręcznej SSD, są odczytywane z dysków twardych;
- Odczytane dane są wysyłane do hosta. Równocześnie sprawdzane jest, czy te bloki są 'gorące';
- Jeśli tak, są kopiowane do pamięci podręcznej SSD do dalszego wykorzystania.
Odczyt danych, gdy są obecne w pamięci podręcznej
- Żądanie od hosta trafia do kontrolera;
- Ponieważ żądane dane są w pamięci podręcznej SSD, są odczytywane stamtąd;
- Odczytane dane są wysyłane do hosta.
Zapis danych przy użyciu pamięci podręcznej do odczytu
- Żądanie zapisu od hosta trafia do kontrolera;
- Dane są zapisywane na dyskach twardych;
- Host otrzymuje odpowiedź o pomyślnym zapisie;
- Równocześnie sprawdzane jest, czy blok jest 'gorący' (porównanie z parametrem Populate-on-Write Threshold). Jeśli tak, to jest kopiowany do pamięci podręcznej SSD do późniejszego użycia.
Zapis danych przy użyciu pamięci podręcznej do odczytu + zapisu
- Żądanie zapisu od hosta trafia do kontrolera;
- Dane są zapisywane w pamięci podręcznej SSD;
- Host otrzymuje odpowiedź o pomyślnym zapisie;
- Dane z pamięci podręcznej SSD są w tle zapisywane na dyski twarde;
Przykład w działaniu
Stojak testowy
2 serwery (CPU: 2 x Xeon E5-2620v3 2.4Hz / RAM: 32GB) są podłączone dwoma portami przez Fibre Channel 16G bezpośrednio do macierzy XCubeSAN XS5224D (16GB RAM/kontroler).
Użyto 16 x Seagate Constellation ES, ST500NM0001, 500GB, SAS 6Gb/s, połączonych w RAID5 (15+1) do macierzy danych oraz 8 x HGST Ultrastar SSD800MH.B, HUSMH8010BSS200, 100GB, SAS 12Gb/s jako pamięci podręcznej.
Stworzono 2 wolumeny: po jednym dla każdego serwera.
Test 1. Pamięć podręczna SSD tylko do odczytu z 1-8 SSD
SSD Cache
- Typ I/O: Dostosowanie
- Rozmiar bloku pamięci podręcznej: 4MB
- Próg uzupełnienia przy odczycie: 1
- Próg uzupełnienia przy zapisie: 0
Wzór I/O
- Narzędzie: IOmeter V1.1.0
- Liczba pracowników: 1
- Liczba oczekujących (głębokość kolejki): 128
- Specyfikacje dostępu: 4KB, 100% Odczyt, 100% Losowy
Teoretycznie, im więcej SSD w puli pamięci podręcznej, tym wyższa wydajność. W praktyce się to potwierdziło. Jedynym wyjątkiem jest znaczne zwiększenie liczby SSD przy małej liczbie wolumenów, co nie prowadzi do efektu eksplozji.
Test 2. Pamięć podręczna SSD w trybie odczyt + zapis z 2-8 SSD
SSD Cache
- Typ I/O: Dostosowanie
- Rozmiar bloku pamięci podręcznej: 4MB
- Próg uzupełnienia przy odczycie: 1
- Próg uzupełnienia przy zapisie: 1
Wzór I/O
- Narzędzie: IOmeter V1.1.0
- Liczba pracowników: 1
- Liczba oczekujących (głębokość kolejki): 128
- Specyfikacje dostępu: 4KB, 100% Zapis, 100% Losowy
Taki sam wynik: eksplozja wydajności i skalowalność przy zwiększeniu liczby SSD.
W obu testach objętość danych roboczych była mniejsza od całkowitej objętości pamięci podręcznej. Dlatego z biegiem czasu wszystkie bloki zostały skopiowane do pamięci podręcznej. Praca toczyła się w zasadzie na SSD, praktycznie nie angażując dysków twardych. Celem tych testów było jednoznaczne pokazanie skuteczności podgrzewania pamięci podręcznej i skalowania jej wydajności w zależności od liczby SSD.
Teraz wracamy na ziemię i sprawdzamy bardziej realistyczną sytuację, gdy objętość danych jest większa od rozmiaru pamięci podręcznej. Aby test przeszedł w rozsądnym czasie (czas „podgrzewania” pamięci podręcznej znacznie rośnie przy zwiększeniu rozmiaru wolumenu), ograniczymy się do rozmiaru wolumenu 120GB.
Test 3. Emulacja działania bazy danych
SSD Cache
- Typ I/O: Baza danych
- Rozmiar bloku pamięci podręcznej: 1MB
- Próg uzupełnienia przy odczycie: 2
- Próg uzupełnienia przy zapisie: 1
Wzór I/O
- Narzędzie: IOmeter V1.1.0
- Liczba pracowników: 1
- Liczba oczekujących (głębokość kolejki): 128
- Specyfikacje dostępu: 8KB, 67% Odczyt, 100% Losowy
Werdykt
Oczywistym wnioskiem jest, że efektywność użycia pamięci podręcznej SSD do zwiększenia wydajności każdej SŁD jest na pewno dobra. W odniesieniu do To twierdzenie dotyczy w pełni: funkcja pamięci podręcznej SSD została wdrożona doskonale. Dotyczy to wsparcia dla trybów odczytu oraz odczytu + zapisu, elastycznego dostosowania do różnych scenariuszy użycia, a także ogólnej wydajności systemu. Dlatego za całkiem rozsądną cenę (koszt licencji porównywalny z ceną 1-2 SSD) można znacząco zwiększyć ogólną wydajność.
Źródło: habr.com
