Clariion - Watermarki i write cache hit ratio

W poprzednim wpisie wspomniałem o watermarkach oraz parametrze write cache hit ratio, oraz zadeklarowałem że wrócę do ich dokładniejszego opisu następnym razem.

Watermarki i działanie write cache:

Aby wyjaśnić pojęcie watermarków muszę przybliżyć działanie cache dla Clariiona.
Jeżeli do macierzy dochodzi polecenie zapisu jakiś danych to praktycznie można przyjąć że zawsze (z pewnymi wyjątkami na których nie będę się rozpisywał) te dane trafiają do części pamięci cache odpowiedzialnej za zapisy (write cache).
Po umieszczeniu danych w cache do serwera, który dane zapisywał, wysłane zostaje potwierdzenie wykonania tej operacji. Następuje ono bardzo szybko, głównie dlatego, że sam cache oparty na modułach flash jest dużo szybszy niż dyski fizyczne. Oczywiście dane zapisane na pamięć flash muszą być docelowo zapisane na dyski (pamięć cache ma ograniczoną wielkość i dodatkowo nie jest odporna na utratę zasilania) - proces "zrzucania" danych z cache na dyski nosi nazwę "flushing", a te dane które jeszcze nie zostały zrzucone to tzw: "dirty pages".

Podstawowym kryterium mówiącym o tym jak intensywnie kontroler zrzuca "dirty pages" na dyski fizyczne jest wypełnienie write cache. Można wyróżnić trzy rodzaje "flushingu":

• idle
• watermark (nazywane też "high water flushing")
• force

Najlepiej pokazać to na wykresie (z góry przepraszam, za moje "arcydzieło" paintowe):

Oś pionowa przedstawia tutaj zapełnienie cache do zapisu. Są tam zaznaczone trzy progi:

1. Low watermark - standardowo ustawiony na 60% - może być zmieniony przez administratora
2. High watermark - standardowo ustawiony na 80% - może być zmieniony przez administratora
3. Pełne wypełnienie cache - 100% 

Żeby była jasność - wykres powyższy pokazuje pewne uproszczenie. To jak działa cache i kiedy zachodzą jego poszczególne rodzaje nie jest całkowicie zgodne z tym wykresem. Zaraz będzie to wyjaśnione w szczegółach.

Jak działa flushing:

Na początku pracy macierzy cache oczywiście jest wypełniony w 0%. Do macierzy zaczynają spływać żądania zapisu, trafiają one do cache i powoli go zapełniają. Cache początkowo działa w trybie "idle flushing" - oznacza to, że Clariion grupuje w cache poszczególne zapisy i zrzuca je na dyski dopiero wtedy, gdy do LUNa do którego dane przynależą nie ma odwołań przez 2 sek (taki LUN jest wtedy uznawany jako nieużywany - idle). Tego typu flushing w bardzo małym stopniu obciąża kontrolery, nie ma także wpływu na szybkość pracy zasobów, ponieważ generuje ruch na LUNie jedynie wtedy gdy jest on nieużywany.

Pierwsza zamiana w pracy flushingu zachodzi kiedy przekroczona zostaje granica określone "High Watermarkiem" (czyli większą z tych dwóch wartości). Wtedy z trybu "idle" przełączamy się na "watermark". W tym trybie Clariion zaczyna dużo bardziej intensywnie zrzucać "dirty pages" na dyski, nawet dla LUNów które są właśnie używane. Ten sposób "czyszczenia" cache trwa do momentu, kiedy jego zajętość spadanie poniżej wartości określonej "Low Watermarkiem", kiedy na powrót trafiamy  w"Idle flushing".

Jeżeli mimo włączenia trybu "watermark flushing" zajętość cache ciągle rośnie (tzn: macierz dostaje bardzo duże ilości zapisów i nie nadążą ze zrzucaniem tego na dyski), dochodzimy do fizycznej granicy ile może zmieścić się w cache czyli do 100% jego zapełnienia. W tym momencie macierz nie ma innego wyjścia - cache zostaje wyłączony i zaczyna się tzw: "force flushing" czyli szybkie zrzucanie zawartości cache na dyski. Ponieważ w tym trybie wszystkie nowe zapisy idą bezpośdenio na dysk, a dodatkowo same dyski są przyjmują to co "zapchało" cache, tak więc wydajność macierzy może być mocno obniżona. "Force flushing" trwa do momentu aż wypełnienie cache spadnie poniżej wartości low watermarka.

Jaki jest sens tych trzech trybów?

Macierz stara się utrzymać zajętość cache pomiędzy low a high watermarkiem. Od góry nie chcemy dobijać "do sufitu" - standardowo zostawiamy 20% cache (od 80 do 100 procent wypełnienia) jako bufor, który może przyjąć nagłe obciążenie ze strony serwerów, jednak z drugiej strony nie chcemy aby nasz cache był cały czas w połowie lub większej ilości pusty - oznaczało by to, że się marnuje i nie jest używany. Dlatego też macierz stara się utrzymywać utylizację cache na poziomie 60-80%, z jednej strony trzymając bufor chroniący przed pikami obciążeniowymi z drugiej dbając aby pamięć podręczna nie była nieużywana.

Write cache hit ratio:

Obiecałem wspomnieć jeszcze o jednym aspekcie a mianowicie o wartości określanej jako "Write cache hit ratio". Cały problem polega na zrozumieniu co tak naprawdę EMC pod tym pojęciem rozumie - skoro z definicji praktycznie wszystkie zapisy mają trafiać do cache tak więc wartość powinna oscylować lub być równa 100% - jeżeli tak się nie dzieje to albo mamy opisany trochę wyżej "force flushing" albo tzw: "write aside" czyli zapis blokiem o dużej wielkości (standardowo 2048 bloków) który automatycznie od razu jest wysyłany na dyski fizyczne.

Spróbowałem znaleźć w dokumentacji EMC jak definiować należy ten parametr i okazało się że nie ma tutaj żadnej wielkiej filozofii. Definicja jest analogiczna do Read Cache Hit Ratio czyli przedstawia ile % ze wszystkich żądań zapisu trafiło najpierw do pamięci cache.

Sam nie wiem dlaczego spodziewałem się tutaj czegoś innego.