środa, 28 marca 2012

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.

środa, 21 marca 2012

Clariion - Storage System Properties


W poprzednim wpisie związanym z Clariionami zrobiliśmy szybki "rajd" po podstawowych menu i okienkach Unisphere.
Dzisiaj chciałbym przyjrzeć się niektórym miejscom nieco bardziej.
Na pierwszy ogień idą ustawienia związane z kontrolerami (storage procesorami)


Własności i konfiguracja Storage Procesorów (kontrolerów)

Właściwości, które opisuję, są dostępne w menu Properties dla kontrolerów macierzowych (SPA/SPB Tasks-->Properties). Okno które się otworzy po wybraniu tej opcji ma 4 zakładki: General,SP Cache, SP Memory, Software.
Postaram się opisać każdą z nich.

Zakładka General:


Są tutaj podstawowe informacje na temat kontrolera.
Mamy tutaj dane o numerze seryjnym, "adresach" w sieci FC (czyli WWN) oraz iSCSI, można również przypisać danemu SP nazwę (pole Name) - nie ma to wpływu na działania kontorlera, a jedynie jest ułatwieniem dla administratora przy jego identyfikacji.
Jeżeli używamy Unix TRU64 to w tym miejscu możemy także ustawić UUID  (Unique Unit Indentifier) - w życiu nie pracowałem na tym systemie, więc niestety nie wiem nic więcej o roli i konfiguracji tego parametru.

Na karcie mamy także trzy opcje pod postacią pól wyboru, przy czym jedna (Mixed Mode) jest nieaktywna. Działanie tych opcji jest następujące:
  • Statistics Logging - włączenie zbierania danych wydajnościowych, które możemy potem analizować jeżeli mamy wykupioną licencje na Navisphere/Unisphere Analyzera. Uruchomienie tej opcji może spowodować niewielką (około 1%) utratę wydajności
  • Mixed Mode - aktualnie nieaktywne pole. Za pomocą tego przełącznika w starszych wersjach FLARE można było przełączyć działanie pamięci cache między tzw: "mixed mode" a "bandwidth mode", przy czym ten drugi używany był wyłącznie w przypadku konfiguracji wszyskich dysków w macierzy w struktury RAID3. Bandwidth mode charakteryzował się między innymi brakiem mirroringu dla write cache pomiędzy kontrolerami. Obecnie Clariiony działają cały czas w trybie "mixed" i nie da się tego wyłączyć.
  • Storage Groups - jeżeli ten checkbox nie jest zaznaczony to każdy host podłączony do Clariiona będzie widział i miał dostęp do każdego LUNa stworzonego na macierzy. W 99.9% przypadków nie chcemy takiego scenariusza i wolimy sami konfigurować które zasoby mają być widoczne dla jakich serwerów,

Zakładka SP Cache:


W tym miejscu mamy dość sporo informacji o tym jak ustawiony i jak pracuje cache w naszej macierzy.
Zakładka podzielona jest na dwa obszary: Konfigurację i Statystyke.

Konfigurować możemy następujące parametry:

  • Page Size - parametr ten określa wielkość pojedyńczej strony w cache (czyli granulację pamięci cache). Możliwe jest ustawienie czterech wartości: 2,4,8,16KB , przy czym 8 jest wartością standardową. Zmiana rozmiaru strony jest zalecana jeżeli nasz Clariion jest dedykowany dla jednej aplikacji (lub grupy podobnych aplikacji) o których wiemy jakiej wielkości blokiem się posługują przy komunikacji z dyskami - dla Exchange będzie to np: 4KB, a Oracle pisze blokami po 16KB.
  • Low Watermark(%) - definiuje poziom na jakim ustawiony jest tzw: "watermark". Wielkośc % oznacza procentowe wypełnienie cache, a przy przekroczeniu tej wartości macierz zmienia swój sposób działania. Więcej szczegółów o watermarkach i ich wpływie na pracę cache w dalszej części wpisu (będzie w osobnym)
  • High Watermark(%) - drugi z poziomów przy którym cache zaczyna zachowywać się inaczej. Również będzie opisany dokładniej w dalszej części wpisu
  • Enable Watermarks - odznaczenie tego pola sprawia, że ustawienia watermarków nie będą miały wpływu na działanie pamięci cache.
  • Mirrored Write Cache - pole nieaktywne, nie da się (przynajmniej z poziomu Unisphere) wyłączyć mirrorowania write cache na drugi kontroler. Jest to wymuszone przez względy bezpieczeństwa - gdyby mirror cache nie był włączony to w przypadku awarii jednego kontrolera tracilibyśmy dane zawarte w jego pamięci cache, które nie zostały jeszcze zrzucone na dyski fizyczne.
  • SP A Read Cache - włącza/wyłącza pamięć cache dla odczytów na SP A
  • SP B Read Cache -  włącza/wyłącza pamięć cache dla odczytów na SP B
  • Write Cache(Enabled) -  włącza/wyłącza pamięć cache dla zapisów (lepiej tego nie ruszać, chyba że naprawdę zależy nam na posiadaniu bardzo wolnej macierzy)
  • HA Cache Vault - opcja nieaktywna, nie da się wyłączyć HA Cache Vaulta. Co tak naprawdę to oznacza i dlaczego jest tak skonfigurowane? Vault to 5 pierwszych dysków w Clariionie (mają takie miłe etykietki z napisem - "Nie ruszaj mnie!"), na nich przechowywane są pewne witalne dla działania macierzy informacje. Znajduje się tam także miejsce dla zrobienia zrzutu pamięci cache w przypadku całkowitej utraty zasilania. W momencie kiedy do macierzy przestaje dopływać prąd, prawie wszystko się wyłącza. Gdyby wyłączyło się zupełnie wszystko utracilibyśmy dane z cache do zapisu, które jeszcze nie zostały zapisane na dyski. Aby tego uniknąć w momencie utraty zasilania, uruchamia się podtrzymywanie bateryjne pamięci cache, a macierz wykonuje zrzut tej pamięci na dyski w vault. Dyski w vault są chronione za pomocą RAID5, a HA Cache Vault oznacza, że cache do zapisów zostaje wyłączony, jeżeli jeden z tych dysków zostanie uszkodzony i nie zdąży się jeszcze odbudować z Hot Spare - ma to nas zabezpieczyć przed utratą danych w sytuacji utrat zasilania z jednoczesną podwójną awarią dysków w Vault - no cóż, ostrożonści nigdy za wiele :D

Druga część zakładki to statystyki, są tutaj prezentowane informacje o:

  • Read Cache Hit Ratio - czyli ile procent żądań odczytu, zostało obsłużonych przez cache bez potrzeby sięgania do dysków fizycznych.
  • Write Cache Hit Ratio - podobnie jak dla powyższego współczynnika tylko dotyczy do żądań zapisu nie odczytu. Wskaźnik ten jest trochę "kontrowersyjny" i wrócę jeszcze do niego w tym wpisie (będzie w osobnym).
  • Percent Dirty Pages - ilość (procentowa) stron w write cache zajętych przez dane nie zapisane jeszcze na dyskach fizycznych
  • Percent Unassigned Pages - ilość (procentowa) stron w cache które nie są przypisane ani do SPA ni do SPB

Zakładka SP Memory:






Na tej zakładce cudów nie ma, tylko jeszcze trochę informacji na temat pamięci cache.
Najważniejsza funkcjonalność tutaj to możliwość ustalenia wielkości pamięci cache dla odczytów (osobno na SPA i SPB) oraz zapisów (z racji tego że write cache jest mirrorowany, więc nie ma możliwości ustawienia różnych wartości na kontrolerach)

Zakładka Software:



Zakładka pokazuje jakie licencje ( i w jakich wersjach) są zainstalowane na macierzy. Na załączonym obrazku jest tylko podstawowy system na Clariionach (FLARE) w wersji 30 i jego dwa komponenty czyli Unisphere i AccessLogix. Z innych rzeczy które mogą się tutaj znaleźć to licencje na replikacje, moduł do QoSa, moduł do zarządzania wydajnością itd...



I to w sumie było by na tyle jeżeli chodzi o okno z właściwościami kontrolera.
Zostało mi jeszcze opisanie watermarków oraz write cache hit ratio co stanie się w następnym wpisie i będzie można przejść do kolejnego etapu.