Clariion - zarządzanie SP,Modułami I/O i Portami

Kolejny wpis z serii przygotowujących do egzaminu na Clariion specjalistę. Poprzednio opisywałem zarządzanie dyskami, teraz skupimy się na pozostałych komponentach.


Zarządzanie Service Procesorem:

Jeżeli przejdziemy do menu System-->Hardware na danej macierzy po lewej stronie ekranu będziemy widzieli panel z grupą opcji związanych z zarządzaniem SP A i SP B:

Mamy tutaj kilka opcji związanych z zarządzaniem Service Procesorami. Z tego poziomu możemy przeładować kontroler, zebrać pliki Diagnostyczne (tzw: SPCollects), a także przeprowadzić kongfigurację właściwości sieciowych danego SP i zrobić bardzo podstawowy troubleshooting problemów związanych z siecią, za pomocą narzędzi ping i traceroute.

Po wybraniu opcji Properties otworzy się okno zawierajace osiem zakładek:

W zakłace General mamy podstawowe informacje o stanie kontrolera, firmware, nr seryjnym itd...
Pozostałe także zawierają pewne ogólne dane i statystyki - nic co wymagało by większego tłumaczenia. Jedynym miejscem gdzie warto zajrzeć jest zakładka Network

Możemy w tym okienku ustawić kilka spraw związanych z siecią:

• Management Port Settings - opcje związane z działaniem portu zarządzania SP
• Requested settings - z jaką prędkością i w jakim trybie chcemy żeby pracował (domyślnie: Auto)
• Link Status - a w jakim naprawdę pracuje
• SNMP Settings - ustawienia SNMP
• Enable/Disable processing of SNMP MIB read requests - włączenie wyłączenie obsługi SNMP dla tego kontrolera
• SNMP Community - tutaj można ustawić tzw: " SNMP Community String" czyli pewien rodzaj klucza, którym autentyfikować się muszą urządzenia, wymieniające się danymi poprzez SNMP.
• Virtual Port Properties - IP adres oraz tzw: VLAN ID naszego kontrolera. 

Po wybraniu przycisku "Properties" możemy przejść do kolejnego okienka z ustawieniami dotyczącymi sieci:

Tutaj dokonujemy wyboru podstawowych ustawień sieci: IP,Maska,Brama, dodatkowo możemy skonfigurować konroler do pracy w sieci IPv6. Te wielkości które tutaj ustawimy będą adresem sieciowym naszego SP (a tak bardziej szczegółowo portu sieciowego, do którego się będziemy podłączali, gdy trzeba będzie wykonać jakieś akcje na macierzy).
Clariion (od FLARE29) wspiera także wykorzystanie VLANów i tzw: VLAN Tagging.
Czym są VLANy nie będę tutaj opisywał, gdyż jest to jest dość podstawowe pojęcie z dziedziny sieci komputerowych - w razie potrzeby google bez problemu "pomoże" się dokształcić.
W każdym razie porty ethernetowe Clariiona (bądź te używane do zarządzania, jak właśnie opisywany, a takżę połączenia 1GbE i 10GbE do komunikacji iSCSI) mogą być wykorzystywane w sieci VLANowej. Fizyczne Porty iSCSI mogą także być podzielone na kilka portów wirtualnych, co pozwala na dobrą segregację ruchu do nich przychodzącego. Port zarządzający na SP nie może być w ten sposób podzielony, zresztą i tak nie było by powodu aby to robić.

Zarządzanie modułami I/O i portami:

Moduły I/O w najnowszych Clariionach noszą nazwe UltraFlex I/O.
Tak jak i wszystkie pozostałe komponenty sprzętowe Clariiona można je obejrzeć w sekcji System-->Hardware, gdzie w lewej części ekranu pokazane jest "drzewko", z pokazanymi zależnościami między poszczególnymi częściami macierzy. Środkowa część ekranu to schematycznie pokazana macierz, razem z zaznaczoną wybraną częścią. Ponieważ opisujemy moduły IO i wchodzące w ich skład porty tak więc na poniższym zrzucie ekranowym mamy zaznaczony właśnie ten komponent:

Aby dostać się do właściwości danego komponentu należy go zaznaczyć po czym wybrać przycisk "Properties".

Właściwości Front-End portu:

W zależności czy wybrany port jest portem FC czy iSCSI inne będą jego właściwości.

Port FC:

Podstawowe dane to WWN portu, Szybkość jego pracy (obecna, wybrana, maksymalna).
Oraz garść informacji o inicjatorach znanych temu portowi (czyli takich które się z nim już komunikowały).

Port iSCSI:

Jeżeli chodzi o informacje i opcje przedstawione na tym okienku, to mamy tutja możliwość definiowania adresu IQN dla portu iSCSI oraz jego aliasu. Możemy także sprawdzić MAC adres oraz ustawioną i obecną prędkość z jaką pracuje port. Opcja MTU(bytes) określa maksymalny rozmiar ramki iSCSI, jaka zostaje wysłana - jeżeli nasza sieć obsługuje tzw: jumbo frames to warto z tego skorzystać i ustawić MTU na większe niż 1500.
Dolna część okienka to wypis wszystkich wirtualnych portów zdefiniowanych dla tego fizycznego portu iSCSI. Clariion od FLARE29 (jak wspomniałem opisując właściwości sieciowe kontrolera) wspiera VLANy i VLAN tagging, można więc jeden port fizyczny zaprezentować jako kilka portów wirtualnych (każy w innym VLANie). Dodawanie i konfigurowanie tych portów odbywa się w okienkach które otwierają się po wciśnięciu przycisków Add i Properties. Nie różnią się one niczym od analogicznego okienka dotyczącego ustwień sieciowych kontrolera - podobnie wybieramy IP,maskę,bramę oraz ustawiamy VLAN ID.

Clariion umożliwia także wyświetlenie wszystkich portów i ich podstawowych konfiguracji poza "drzewkiem" sprzętu. Opcja Manage Data Ports jest dostępna po kliknięciu prawym przyciskiem myszy na daną macierz na liście (w okienku Dashboard-u) i wybranie opcji Port Management. Otrzymamy listę wszystkich portów na macierzy, razem z ich opisem, prędkością działania oraz adresami IP lub IQN

---

To tyle na temat zarządzania kontrolerem i portami.
W kolejnych wpisach zostajemy w temacie zarządzania poszczególnymi urządzaniami/bytami zdefiniowanymi na macierzy lub w jej "otoczeniu". Zaczniemy od tego w jaki sposób macierz widzi i zarządza korzystającymi z niej hostami.

Clariion - zarządzanie hardware (dyski)

Po naprawdę długiej przerwie wracam do tematu przygotowania do egzaminu na Clariion specjalistę. Szczerze powiedziawszy mam dość mieszane uczucia co do kontynuowania tego wątku, po pierwsze Clariiony to już zamknięta linia (choć ich następca VNX jest całkiem do nich podobny i podobnie się nim zarządza - przynajmniej jeżeli chodzi o storage blokowy), po drugie ostatnio całkowicie nie mam czasu, żeby porządnie skupić się na przygotowaniach.
Dość narzekania pora wziąć się do nauki, a co dalej będzie z tą serią wpisów to się zobaczy:

Zarządzanie dyskami w Clariionie:

Jednym z najważniejszych elementów w macierzy dyskowej jest oczywiście dysk. W zależności od wielkości danego urządzenia może ich być od kilkunastu do około tysiąca (i więcej).
W Clariionach informacje o tym komponencie można znaleźć w menu Storage-->Disks.  Wybór tej opcji otwiera okno gdzie mamy wylistowane wszystkie dyski jakie znajdują się w danej macierzy:
Dla każdego dysku wyświetlone jest kilka podstawowych informacji:

• Name (nazwa) ---> dany dysk jest identyfikowany za pomocą trzech liczb oznaczających po kolei: Pętlę (bus) na której znajduje się napęd, Półkę (enclosure) gdzie jest umieszczony i jego pozycję (Disk) na tej półce. 
• State (stan) ---> obecny  stan dysku
• Raw Capacity (Pojemność surowa) - ilość przestrzeni dostepna do wystawiania 
• User Capacity (Pojemność zużyta) - ilość przestrzeni wystawiona do LUNów
• LUN ID - nr LUNów które mają przestrzeń wystawioną z danego dysku
• LUN Type - Typ RAIDu w jakim jest dany dysk
• Hot Spare Replacing - Status dysku Hot Spare

Po wybraniu opcji "Properties" możemy zobaczyć szczegółowe informacje o wybranym napędzie. Dostępne są następujące dane:

Zakładka "General":

Tutaj mamy dużo więcej informacji o wybranym napędzie. Między innymi producenta, model, numer seryjny, wesja firmare itd...

Zakładka Errors:

Ilość błędów na dysku, z podziałem na te przy odczycie/zapisie oraz "miękkie" (soft) i "twarde" (hard).
Soft zwykle znaczy, że nie ma żadnego problemu z samym dyskiem, a jedynie coś się nie udało przy próbie zapisu lub odczytu. Błędy twarde zazwyczaj sygnalizują uszkodzenia samego dysku (np: bad sectory).

Zakładka Statisctics:

Pewne bardzo podstawowe dane wydajnościowe dotyczące pracy dysku. Ilość IOPSów oraz przepustowość, a także utylizacja dysku. Danych raczej mało i dostępny jest tylko "zrzut" stanu obecnego bez możliwości sprawdzenia histroii co raczej ograniczna efektywne wykorzystanie tych informacji.

Zakładka Power Settings:

Na tej zakładce mamy informację, czy dany dysk wspiera zarządzanie oszczędzaniem energii oraz czy jest ono włączone. Zarządzanie polega na zatrzymaniu ruchu obrotowego dysku, kiedy nie jest on używany, dzięki czemu nie zużywa prądu. Minusem jest to, że po odwołaniu się do danych na nim znajdujących najpierw musi wykonać "rozruch" i rozkręcić się do swojej prędkości pracy.

Oszczędzanie energii (Power Saving) dla dysków:
Opcję zarządzania energią dla dysków ustawia się na poziomie RAID grupy. Wszystkie napędy w danej grupie muszą wspierać tą funkcjonalność, aby można ją było uruchomić. Jeżeli jest włączona, mechanizm zatrzyma dyski jeżeli przez czas 30 minut nie będzie do żadnego z nich skierowane żądanie I/O. Po zatrzymaniu dyski potrzebują ok 15sekund na ponowne uruchomienie.
Dodatkowymi warunkami (oprócz pół godzinnej nieaktywności) aby można było uruchomić tryb oszczędzania enterii jest aby, na żadnym LUNie z RAID grupy, nie była uruchomiona replikacja oraz żeby grupa nie zawierała metaLUNów.


Zarządzanie dyskami Hot Spare:
Dyski Hot Spare są to napędy skonfigurowane nie do przechowywania danych ale do zastępowania dysków uszkodzonych. Jeżeli w macierzy jeden z dysków ulegnie uszkodzeniu, to automatycznie na jego miejsce wskakuje rezerwowy "hot spare.
Zgodnie z "dobrymi praktykami" EMC w Clariionach na każde 30 dysków powinien być jeden "hot spare" przy czym rolę tą może pełnić każdy napęd, wyjątkiem są dyski EFD(SSD) które mogą być hot spare tylko dla innego dysku EFD. Pozostałe "dobre praktyki" przy konfigurowaniu dysków HS, to rozmieszczanie ich na tych samych pętlach (Bus) co dyski, które będą one chroniły, a także stworzenie co najmniej jednego HS dla każdego typu (rodzaj, prędkość, pojemność) dysku jaki mamy w macierzy.

Dyski HS w Clariionach są globalne, tzn: nie da się ich przypisać do takiego napędu grupy RAID, LUNa czy pojedynczego dysku która będą chroniły. Każdy HS chroni całą macierz i wszystkie napędy (oczywiście jeżeli jest w stanie - czyli ma odpowiednią wielkość i nie jest dyskiem SSD).

Sytuacje w których dysk HS zastępuje zwykły można podzielić na trzy kategorie:

• Uszkodzenie dysku
• Zainicjowanie proaktywnej wymiany automatycznie przez macierz (FLARE)
• Zainicjowanie proaktywnej wymiany manualnie przez administratora (poprzez GUI lub naviseccli)

Pierwsza sytuacja tłumaczy się sama przez się. W drugiej dysk który zostaje zastąpiony HSem działa sprawnie, jednak na podstawie pewnych przesłanek - przekroczenia pewnych progów alarmowych - macierz uznaje go za napęd zagrożony i przeprowadza proaktywną wymianę. Trzeci wariant to oczywiście decyzja administratora. 

Między uszkodzeniem a proaktywnymi wymianami jest jedna podstawowa różnica. Po awarii dane na dysku są niedostępne, dlatego aby HS mógł go zastąpić musi nastąpić proces odbudowy (rebuild) - zachodzi to automatycznie i wykorzystuje nadmiarowość zapewnianą przez struktury RAID. W przypadku najpopularniejszych RAID5 i 6 odbudowa to rekalkulacja danych wykorzystując kody parzystości. Jest to proces obciążający macierz i dość czasochłonny (szczególnie w przypadku dużych dysków SATA).
Prędkość odbudowy zależy od następujących czynników:

• Wielkość dysku
• Rodzaj dysku (SATA,SAS,FC, itd...)
• Ilości przestrzeni zajętej (przypisanej do LUNów)
• Priorytetu odbudowy (od ASAP do Low)
• Obciążenia macierzy (ilości IOPSów)
• Typu RAID w którym jest uszkodzony dysk
• Wielkości grupy RAIDowej (dotyczy R5 i R6)
• Rozłożenia dysków na pętlach FC w macierzy

W odróżnieniu do uszkodzenia, proaktywna wymiana nie wymaga odbudowy, a jedynie przekopiowania zawartości (dysk zastępowany przez "Hot spare" ciągle działa). Generuje to zdecydowanie mniejsze obciążenie macierzy.

Aby zainicjować zastąpienie dysku przez Hot Sprare należy kliknąć w dany dysk na liście i wybrać opcję: "Copy to Hot Spare"

---

Kolejnymi tematy z cyklu "clariionowych" będą o zarządzaniu pozostałymi komponentami sprzętowymi.

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.

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.

Clariion - Rzut oka na Unisphere + menu do zarządzania macierzą

Trochę czasu upłynęło od ostatniego wpisu związanego z Clariionami i przygotowaniami do egzaminu. Niestety nadmiar zajęć bardziej priorytetowych spowodował, że nieco "odpuściłem" pisanie na blogu.

Ten wpis skupi się na Unisphere i pokaże pewne podstawowe informacje jaki można sprawdzić za pomocą tego interfejsu. Dość dużo będzie zrzutów ekranu, bo nie ma większego sensu opisywanie słowami tego co ładnie można po prostu pokazać.

Start: Dashboard + okolice

Unisphere pojawił się razem z FLARE30 i zastąpił poprzedni interface nazywany NaviSphere.
Zaraz po zalogowaniu się (poprzez wpisanie adresu IP naszego Clariiona do przeglądarki), widzimy tzw: dashboard czyli stonę startową z najróżniejszymi charakterystykami.

Standardowy dashboard bez modyfikacji wygląda następująco:

Poszczególne panele można zmieniać wykorzystując obecny w okolicach prawego górnego rogu przycisk Customize.
Standardowo dostajemy informację o urządzeniach (Clariionach, Centerach i VNXach) w naszej domenie, alarmach i ostrzeżeniach oraz pewne podstawowe dane dotyczące zarządzania pojemnością - zarówno Clariionów jak i macierzy Celerra.

W górnej części mamy poziome menu z kilkoma głównymi opcjami.

• Dashboard - wyświetlenie dashboardu
• System List - Lista naszych urządzeń w domenie
• Domains - Informacje o domenach
• Alerts - Czyli log z wszyskimi alarmami
• Support - Opcje związane z serwisowaniem macierzy

Część z tych pozycji jest rozwijalna i udostępnia kolejne "pod-menu":

W tym wpisie chciałbym skupić się na najbardziej rozbudowanej części tego menu czyli pozycji System List
Po przejściu na zakładkę System Lists otrzymamy wykaz naszych macierzy w domenie:

Na tym zrzucie raczej ubogo, jeden samotny Clariion CX-240 :D
Poprzez "prawo-klik" na danym urządzeniu dostajemy się do menu kontekstowego z wieloma opcjami dotyczącycmi zarządzania konkretnym urządzeniem:

Jak widać cała pula opcji do wyboru. Nie będę się rozwodził na temat każdej z nich (większość będzie bardziej lub mniej opisana w kolejnych wpisach).


Menu dla pojedynczego systemu (macierzy)


Po wybraniu jednego z systemów (macierzy), dostajemy kolejne menu i opcje pozwalające nam monitorować/zarządzać nim:

Menu ma następującą strukturę (zaznaczyłem jedynie "pod-menu" w tych ważniejszych pozycjach):

• System
• System Information
• Hardware
• Hot Spares
• Storage
• Summary
• Disks
• Pools/RAID Groups
• LUNs
• Storage Groups
• Folders
• Hosts
• Summary
• Host List
• Virtualization
• Replicas
• Monitoring
• Reports
• SP Event Logs
• Event Notification
• Analyzer
• Quality of Service Manager
• Settings
• Support

I przechodząc po kolei:

Menu System:

Zakładka System Information wygląda następująco:

Główną część okna zajmują podstawowe informacje o danej macierzy takie jak status, nr seryjny adresy IP kontrolerów itd... Na lewo znajduje się panel sterujący podzielony na kilka sekcji, związanych z poszczególnymi typami zadań.


Kolejną opcją w menu system jest Hardware:

Środkową część okna zajmuje lista komponentów macierzy pod postacią "drzewka"
Po prawej stronie możemy zobaczyć szczegółowe własności wybranego komponentu oraz w niektórych przypadkach jego graficzny obraz z zaznaczonym położeniem.

Zakładka Hot Spares jest "nudna" więc nie będziemy jej tutaj prezentowali. Nazwa dość jednoznacznie tłumaczy jej zawartość.

Menu Storage:


Główna zakładka menu storage zawierająca podsumowanie to Summary:

Menu z opcjami po lewej stronie (identyczne dla wszystkich zakładek z grupy Storage) pozwala nam na przeproawdzenie podstawowych operacji na LUNach i Storage grupach, przy czym za najważniejszą należy oczywiście uznać stworzenie nowego LUNa. Dominującą część okna zajmuje coś w stylu "dashboard"-a z ogólnymi informacjami na temat statusu LUNów oraz pojemności i wykorzystania macierzy.

Pozostałe opcje (poza Summary) w menu Storage pokazują nam po kolei kolejne "struktury" jakie tworzymy na macierzy aby finalnie:
Zakładka Disks pokazuje nam jakie dyski mamy w macierzy - czyli zaczynamy od podstawowy fizycznych "cegiełek" dostarczających przestrzeń.
Same dyski nie umożliwią nam jeszcze wystawiania przestrzeni do serwerów, należy je odpowiednio skonfigurować - utworzyć z nich grupy ( w przypadku wystawiania tradycyjnego) lub pule (w przypadku użycia "thin provisioningu"). Każda grupa/pula dysków ma przypisany do siebie rodzaj protekcji RAID (0/1/5/6 itd...). Informacje na temat obecnych na macierzy grup/pul są dostępne w zakładce Pools/RAID Groups:

Mając stworzone struktury RAID można na nich tworzyć LUNy. Czyli te objekty, które będziemy prezentowali dla hostów.
Jak się nietrudno zorientować zakładka na której są informacje o LUNach nazywa się LUNs:

Oprócz obecnych w każdej zakładce menu Storage opcji "zadokowanych" po lewej stronie okna, pozostałą jego część zajmuje lista wszystkich LUNów zdefiniowanych na macierzy razem z pewnymi podstawowymi informacjami o nich (Nazwa, Numer, Status, Pojemność, Do jakiego hosta został wystawiony)

Po stworzeniu LUNów została nam jeszcze tylko jedna rzecz do skonfigurowania na macierzy, tak aby z przestrzeni danego LUNa mógł korzystać host.
Należy wykonać tzw: mapowanie czyli zezwolić macierzy na skomunikowanie się ze sobą wybranego hosta z wybranym LUNem. Wykorzystuje się do tego strukturę nazwaną Storage Group, która składa się z dwóch części. W jednej z nich mamy listę LUNów, a w drugiej listę Hostów. To co robi macierz to pozwala aby wszystkie hosty z grupy, miały dostęp do wszystkich LUNów z tej samej grupy.
Oczywiście przy tworzeniu takich grup mamy do dyspozycji różne warianty i opcje, ale w tym wpisie nie chodzi nam o wyjaśnienie tego procesu ale tylko pokazanie miejsca gdzie w Unisphere są okienka i menu związane z takimi objektami.
Znajduje się to w zakładce Storage Gropus:

W górnej części widzimy listę zdefiniowanych grup a na dole w zakładkach można sprawdzić jakie LUNy i hosty zostały do niej przypisane.

Ostatnia pozycja to Folders , w przeciwieństiwe do pozostałych opcji nie jest to kolejny "krok" przy tworzeniu i wystawianiu zasobów. W tym oknie możemy zobaczyć sobie LUNy podzielone na różne kategorie (foldery) - między innymi: LUNy nie wystawione do hostów, LUNy przypisane do poszczególnych SP, MetaLUNy (czyli kilka LUNów połączonych w jeden). Można także w tym miejscu zdefiniować swoje katalogi i poprzypisywać do nie zasoby.

Menu Hosts:


Tak jak i w pozostałych przypadkach menu host posiada swoją zakładkę Summary:

I tak jak się można domyślić znajduje się na niej kilka okienek z podstawowymi informacjami na temat widzianych przez macierz hostów.

Pozostałe dwie opcje w menu "Hosts" odpowiadają za liste wszystkich serwerów podpiętych do macierzy (Host List) oraz za integrację z VMware (Virtualization).

Dość lakonicznie to opisuję, ale więcej nie trzeba :D


Pozostałe Menu z grupy System List:

Zostały jeszcze 4 nieomówione menu z całej grupy opcji związanych z poszczególnymi macierzami.
Są to mianowicie: Replicas, Monitoring, Settings, Support
Nie będę poświęcał im tyle czasu i uwagi w tym wpisie co pozostałym. Jeżeli chodzi o menu Replicas to oczywiście zawiera ono opcje to tworzenia i konfigurowania najróżniejszych tworów związanych z replikami lokalnymi oraz zdalnymi - same mechanizmy będą opisane w innym miejscu i późniejszym czasie.
Jeżeli chodzi o Monitoring, to każda z jego opcji jest jakby osobnym narzędziem, przy czym niektóre z nich są osobno licencjonowane (np Analyzer czy Quality of Service Manager). One także powinny doczekać się swoich własnych wpisów.
Menu Settings oraz Support są średnio ciekawe i nie ma tam fajerwerków - nazwa mówi wszysko.


Podsumowując:


Wpis dość długi i dodatkowo pełen zrzutów ekranowych.  W zasadzie mam co do niego ambiwalentne uczucia, gdyż to wszysko co jest tutaj opisane poznaje się w ciągu kilkunastu minut "przeklikiwania" się przez macierz. Przygotowanie tego wpisu zajęło mi dużo więcej czasu, szczególnie w zakresie przygotowywania zrzutów i zaciemniania wszelkiego rodzaju numerów seryjnych oraz nazw.
Na pewno pojawi się jeszcze jeden (lub nawet więcej) wpisów związanych z Unisphere, ale będą bardziej treściwe i pokażą jak wykonywać pewne (podstawowe) czynności na macierzy lub gdzie szukać bardziej precyzyjnych ustawień - obiecuję nie będzie już takiej treści ogólnej z zdjęciami dashbordów i listw z menu :D

Choć najprawdopodobniej kolejny post na blogu nie będzie dotyczył Clariionów i przygotowań do nieszczęsnego egzaminu.

Clariion - FAST Cache

Po wpisie dotyczącym autentyfikacji użytkowników i innych spraw średnio przydatnych przy codziennym administrowaniu macierzami, wracamy do zagadnień  "ciekawszych".
Dzisiejszym tematem jest nowa funkcjonalność zaimplementowana we FLARE30 i dostępna w macierzach Clariion CX4 oraz VNX, chodzi mianowicie o FAST Cache. Nazwa może być trochę myląca, ponieważ jest to co innego niż FAST (nazwa na automatyczny tiering w macierzach EMC). Gdyby opisać jednym zdaniem działanie FAST Cache, to jest to wykorzystanie dysków SSD do rozszerzenia pamięci cache.

Podstawy

Funkcjonalność FAST Cache została wprowadzona przez FLARE30 i polega ona na wykorzystaniu dysków SSD, nie jako przestrzeni do wystawiania danych, ale jako rozszerzenie pamięci cache. Można (w zależności od konfiguracji i ilości dysków SSD) "rozbudować" cache macierzy o wielkości od 73GB do 2TB.
Celem takiego ruchu jest oczywiście zapewnienie większej wydajności jaką zapewnia zwiększona "pamięć podręczna". Dyski SSD mają dużo lepsze parametry niż ich "tradycyjni", mechaniczni koledzy i dlatego operacje IO są na nich wykonywane dużo szybciej.
Uruchomienie funkcjonalności FAST Cache może być wykonane podczas działania macierzy i nie wymaga jej wyłączenia, to samo dotyczy zmian (zwiększenia/zmniejszenia/usunięcia) ilości przestrzeni o jaką chcemy "rozbudować" nasz cache.
Do FAST Cache możemy dołączać całe dyski SSD, nie jest możliwe podzielenie dysku na części i wykorzystanie np: kawałka na wystawianie przestrzeni, a reszty dla FAST Cache.
Po uruchomienia FAST Cache wszyskie nowo tworzone LUNy mają domyślnie aktywną opcję korzystania z tej funkcjonalności, jeżeli chcemy uruchomić ją także dla już istniejących zasobów, należy to zrobić ręcznie( włączenie/wyłączenie FAST Cache można robić per LUN lub per storage pula). Zasoby znajdujące się na dyskach SSD mają FAST Cache wyłączony.


Porównanie pamięci cache i FAST cache.

Mimo iż dyski SSD są dużo szybsze niż mechniczne to jednak nie zapewnieją tych samych parametrów i czasów odpowiedzi co "natywny" cache macierzy oparty na kościach DRAM.

W tabelce jest porównanie tych dwóch rodzajów "cache":

Parametr	DRAM	Fast Cache
Wielkość	do 32GB (zależy od modelu macierzy)	do 2TB
Czas odpowiedzi	nanosekundy do milisekund	milisekundy do mikrosekund
Podział	Osobne obszary dla odczytu i zapisu	Współny obszar używany do "cachowanie" danych na odczyt i zapis
Ziarnistość (min rozmiar danych jakie można zapisać w cache)	Rozmiar pojedyńczej strony jest możliwy do zdefiniowania prze użytkownika. Możliwy zakres: od 2Kb do 16Kb	Operuje na kawałkach (extends) o wielkości 64Kb
Odporność na awarie	Nie jest odporny na utratę zasilania (musi być podtrzymany bateryjnie do czasu zrzutu na dysk). Po uszkodzeniu wymagana interwencja serwisanta.	Odporny na zanik zasilania. Uszkodzony dysk SSD w Fast Cache może być zastąpiony hot spare i wymieniony ręcznie.

Działanie FAST Cache:

Czas na opisanie budowy i działania FAST Cache na nieco większym poziomie szczegółowości.
Na FAST Cache składają się dwa komponenty:

• Policy engine - odpowiada za zarządzanie i odpowiednie kierowanie przepływem żądań IO przez FAST Cache. Ten moduł decyduje który fragmet danych ma być umieszczony w pamięci FAST Cache, dba również o to aby nieużywane fragmenty były z niej usuwane.
• Memory map - mapa pokazująca jakie dane są w FAST Cache, przechowuje informację o zawartości każdego z 64KB fragmentów na jaki podzielony jest FAST Cache.

Przepływ danych przy włączonym FAST Cache:

Żądania IO przychodzące do macierzy są sprawdzane czy dotyczą zapisu/odczytu z LUNu (lub z puli) która ma włączoną funkcjonalność FAST Cache. Jeżeli tak to sprawdzane jest (w memory map) czy dane te są już w FAST Cache czy nie. Jeżeli ich nie ma, to dalsza "droga" danego IO jest taka sama jak w przypadku nie używania FAST Cache. 

Jeżeli dane są w fast cache to policy engine przekierowuje IO do Fast Cache. Jeżeli IO jest żądaniem odczytu, a dane znajdują się w pamieci DRAM (czyli natywnym cache) to są stamtąd odczytywane, jeżeli ich tam nie ma, do odczyt ma miejsce z dysku SSD,  a dodatkowo dane te są także zapisywane w DRAMie.
Jeżeli od strony hosta przychodzi żądanie zapisu, to jest ono obsługiwane w ten sam sposób, co normalnie (czyli z wyłączonym FAST Cache) - dane trafiają do DRAMu. Różnica polega na tym, że tzw "de-stagingig" czyli zrzucanie danych z pamięci cache na dyski, odbywa się dwuetapowo, najpierw dane są przegrywane z wewnętrznego cache (DRAM) na dyski SSD (Flash Cache), a dopiero potem na dyski mechaniczne. Pozwala to na dużo szybsze czyszczenie pamięci cache na DRAM z tzw "dirty pages", czyli danych które już zostały zaraportowane hostowi jako zapisane, ale ciągle są obecne jedynie w natywnej pamięci cache (DRAM), która nie jest odporna na zanik zasilania.

O tym, które dane są obecne w FLASH Cache, decyduje policy engine. Algorytm który jest wykorzystywany opiera się częstości w jakie hosty wykonują operacje IO na konkretnych blokach danych.
Proces przenoszenia często używanych danych z dysków mechanicznych na SSD nazywany jest Promotion. Przeniesienie danych do których częstość odwołań spadła z FLASH Cacha spowrotem na dyski mechaniczne nazywana jest Write Back.
Co do Write Back to nie mam pełnej jasnosci jak on dokładnie działa: W dokumentacji EMC (h8046-fast-cache-wp) pisze wyraźnie, że dane są kopiowane z SSD na HDD. Nieścisłość według mnie polega na tym, że podczas promocji do FAST Cache dane nie są przenoszone, ale kopiowane, czyli cały czas rezydują w swoim orginalnym miejscu, w cache - czy to zwykłym, czy FAST - znajduje się tylko ich kopia. Operacja odwrotna czyli Write Back nie powinien nic kopiować tylko zaznaczać na memory map, że dany blok nie jest już w tej pamięci obecny.


Jak uruchomić FAST Cache:

Z poziomu Unisphere Fast Cache uaktywnia się po wyborze opcji Storage System Properties na zakładce FAST Cache. Po uruchomieniu funkcjonalność ta jest domyślnie włączona dla wszyskich nowych zasobów.
Przy tworzeniu LUNa można włączyć/wyłączyć używanie przez niego FAST Cache w zakładce Create LUN-->Advanced poprzez zaznaczenie/odznaczenie odpowiedniego pola wyboru.
Dla istniejących LUNów zmiana tego parametru jest możliwa miejscu Properties-->Cache, w przypadku thin pool-i ustawienia FAST Cache są w Properties-->Advance.


Uruchamiać i konfigurować  FAST Cache można również z poziomu CLI:

Uruchamianie FAST Cache:

cache -fast -create -disks -rtype -mode

gdzie:

-disks <-- dyski z których chcemy stworzyć FAST Cache.
-rtype <-- rodzaj protekcji (powinien być RAID1)
-mode <-- tryb ro (read only) lub rw (read write)

Usunięcie FAST Cache:

cache -fast -destroy

Clariion - Unisphere Security Features

Tytuł po angielsku (brakło weny do stworzenia jakiegoś w miarę dobrego tłumaczenia) ale sama treść już w języku ojczystym ;)
Tym razem będzie o czymś na co w praktyce (przynajmniej mojej osobistej) raczej nie zwracałem uwagi. Temat przewodni to bezpieczeństwo a konkretnie sposoby na jakie Clariion (a w zasadzie Unisphere) pilnuje, aby dostępu do niego miały tylko uprawnione osoby i tylko w tym zakresie jaki został im udostępniony.
Ponieważ operacje zakładania i dawania dostępu nowym użytkownikom do macierzy to nie jest coś, co się przeprowadza regularnie i często, tak więc zwykle nie pamięta się wszyskich możliwości i niuansów jakie są z tym związane.
Podejrzewam jednak, że udane podejście do egzaminu na Clariion Specialist wymaga odświeżenia i uporządkowania sobie wiedzy w tym zakresie.

Do rzeczy.

Macierzą można zarządzać przez dwa główne interfejsy. Unisphere - czyli GUI dostępne poprzez przeglądarkę sieciową lub za pomocą linii komend.

Unisphere:

Aby dostać się do Unisphere należy w przeglądarce wpisać adres http://<clariion_ip> - powoduje to uruchomienie apletu Javy. Aplet ten zestawia bezpieczne, szyfrowane połączenie ( SSL/TLS na porcie 443) z storage management serwerem na macierzy. Dzięki temu, mimo iż nie jest bezpośrednio używany https, połączenie jest zabezpieczone.
Szyfrowana jest także cała komunikacja pomiędzy storage management serwerami na różnych macierzach.

Podczas logowania się do macierzy za pomocą Unisphere użytkownik autentyfikuje się podając login, hasło oraz tzw zakres (scope)

SecureCLI:

Podczas używania linii poleceń komunikacja z macierzą jest zabezpieczona w ten sam sposób, co przy łączeniu poprzez Unisphere (szyfrowanie połączenia).
Jeżeli chodzi o autoryzację, to administrator przy wpisywaniu komend, każdorazowo powinien podać login,hasło oraz zakres. Ponieważ takie rozwiązanie nie jest zbyt wygodne mamy możliwość stworzenia tzw "Security File". "Security File" jest przypisany do danego użytkownika na systemie operacyjnym, z którego wydaje się polecenia do clariiona i zawiera w sobie zaszyfrowany login,hasło i scope. Dzięki temu dany użytkownik nie musi ich podawać razem z każdą wysłaną komendą.
Komenda tworząca "Security File" to addusersecurity i ma następującą składnię:
naviseccli -addusersecurity -user <username> -password <pw> -scope<0|1|2>


Sam "Security file" to tak naprawdę dwa pliki które umiejscawiają się na home folderze użytkownika:
SecuredCLISecurityFile.xml i SecuredCLIXMLEncrypted.key

Usunięcie "Security Pliku" wykonuje się poleceniem:
naviseccli -removeusersecurity

Zakres (scope):

Każde konto do zarządzania Clariionami ma jeden z trzech zakresów:

• Local - konto zdefiniowane na jednej macierzy
• Global - konto umożliwiające administrowanie każdą z macierzy w domenie
• LDAP - konto zdefiniowane na serwerze LDAP (np: w domenie AD) i umożliwiające zalogowanie się do każdej macierzy używającej LDAPu do autentyfikacji

Autentyfikacja przez serwer LDAP:

Metoda wykorzystania do zarządzania Clariionami konta z domeny jest najbardziej wygodna. Dzięki temu nie musimy wyodrębniać zarządzania użytkownikami macierzą do innego miejsca i możemy utrzymać centralny punkt (domena np: AD) do zarządzania uprawnieniami.
Macierz musi być najpierw odpowiednio skonfigurowana aby móc na niej korzystać z użytkowników domenowych. Z poziomu Unisphere ustawienia dotyczące LDAPa można znaleźć w menu:

All Systems > Domains > Configure LDAP for CLARiiON Systems

W tym miejscu można przede wszystkim dodać(i zmienić) adresy naszych kontrolerów domeny.
Tutaj także ustawia się interwał synchronizacji. Storage server przechowuje (cache-uje) informacje o kontach i ich uprawnieniach pobrane z domeny tak, żeby każde wydane polecenie nie musiało być autentyfikowane z kontrolerem. Standardowo ten cache jest czyszczony co 24h, ale jeżeli chcemy aby czas ten uległ skróceniu i macierz częściej odświeżała/synchronizowała informacje z domeny możemy zmienić.


Role użytkowników:


Ostatni temat jaki zostanie omówiony w tym wpisie, to role czyli rodzaje kont jakie można założyć na macierzy. Różnią się one, oczywiście, rodzajem uprawnień, a przez to działaniami jakie dany użytkownik może wykonywać.
Dostępne są następujące role:

• Monitor - użytkownik z uprawnieniami read-only
• Manager - użytkownik mogący zarządzać macierzą ale nie mający uprawnień do tworzenia i zarządzania kontami użytkowników na niej.
• Administratror - użytkownik posiadający maksymalne uprawnienia zarówno jeżeli chodzi o zarządzanie macierzą (tworzenie, wystawianie LUNów, definiowanie RAID grup itd..) jak i o zarządzanie użytkownikami
• Security Administrator - użytkownik mogący tworzyć i zarządzać innymi użytkownikami, ale nie mogący konfigurować macierzy.

Od FLARE29 dostępne są także 3 role do działań związanych z replikacją:

• Local Replication - użytkownik może wykonywać operacje związane z replikacją lokalną SnapView
• Replication  - użytkownik może wykonać operacje związane z replikcją zdalną - MirrorView, oraz lokalną.
• Replication/Recovery - rola podobna jak Replication ale dodatkowo użytkownik może wykonywać operacje "odzyskania" np: roll-back z kopii migawkowej.

Co istotne żadna z tych 3 ról "replikacyjnych" nie zezwala na tworzenie nowych bytów związanych z replikacją (jak klony, kopie migawkowe itd...). Możliwe jest jedynie zarządzanie już istniejącymi obiektami.

Clariion - software (przegląd)

Dzisiaj na tapetę bierzemy software na jakim działa Clariion.
Całe oprogramowanie związane z tą macierzą można podzielić na dwie kategorie:

1. Software na macierzy
• Management Server & User Interface server
• Unisphere Agent
• FLARE


2. Software zainstalowany na serwerze podpiętym do macierzy
• Unisphere
• Unisphere agent (opcjonalnie)
• Navisphere Secure CLI
• Unisphere Server Utility
• Unisphere Storage System Initialization Utility
• Unisphere Service Manager
• Management Server & User Interface server (opcjonalnie)

Nieco więcej szczegółów opisujących działanie najważniejszych z tych pozycji oraz wzajemne interakcje między nimi:

Unisphere
Jest to interejs, który pozwala nam poprzez przeglądarke i aplet JAVA podłączyć się do macierzy. Unisphere łączy się z Management Serverem zainstalowanym na Service Procesorze macierzy i dostarcza wygodnego interfejsu do zarządzania jej zasobami.
Unisphere pojawił się razem z FLARE30, w poprzednich wersjach firmwaru powłoka i GUI nazywało się NaviSphere.

Unisphere ( a konkretnie jeden z jego ekranów pokazujący stan komponentów hardware) wygląda następująco:

źródło: Screenshot z własnego ekranu ;) Uruchomione EMC VNXe Demo

Co prawda ten zrzut nie jest z Unisphere działającego na Clariionie ale na jego "następcy" VNXie ale wygląd jest identyczny.
W materiałach EMC Unisphere jest zakwalifikowany jako oprogramowanie "host based" (zainstalowany na serwerze podpiętym do macierzy) ale ja jakoś bardziej bym go umiejscawiał w samym SP - jako część FLARE.

FLARE
Flare (Fibre Logic Array Runtime Environment) jest głównym oprogramowaniem działającym na Clariionie i zapewnia macierzy jej podstawową funkcjonalność (tworzenie RAIDów, obsługa cache etc...).  FLARE jest umieszczony w tzw: vaulcie (5 pierwszych dysków na pierwszej półce dyskowej) i podczas ładowania/startu Service Procesorów jest na nie wgrywany. FLARE tak naprawdę jest to Windows XP z "nakładką" przygotowaną przez EMC.

(Storage) Management Server 
Oprogramowanie działające albo na samym SP w Clariionie albo (opcjonalnie) na wydzielonym serwerze Windowsa. Polecenia jakie użytkownik(administrator) wysyła do macierzy poprzez przeglądarkę sieciową(Unisphere) lub z linii poleceń trafiają do Management Servera. Management Server kieruje następnie dane polecenia do odpowiedniego modułu nimi zarządzającego (np: Performance, Security, Raporty itd...). Wszyskie komendy wymagające zmiany na samej macierzy idą do FLARE.
Management server zajmuje się także zarządzanie tzw: domeną.
Domena jest to grupa Clariionów zarządzana z jednego miejsca. Posiadając więcej macierzy tego typu niezbyt wygodne było by zarządzanie każdą z nich poprzez bezpośrednie logowanie - dlatego tworzy się domenę - pojedynczy punkt zarządzania - i możemy administrować nimi logując się tylko do jednej, wybranej macierzy, która staje się wtedy kontrolerem domeny (nie ma to oczywiście nic wspólnego z kontrolerem domeny Acitve Directory znanego z produktów Microsoft-u).
Jeżeli posiadamy naprawdę dużą liczbę Clariionów (kilkaset) i chcemy je umieścić w jednej domenie, można  rozważyć instalację Management Servera na dedykowanym serwerze z Windowsem i w ten sposób odciążymy Service Procesor macierzy od kontrolowania tak dużej domeny. Ma to jednak sens jedynie w naprawdę dużych środowiskach.

NaviSphere Secure CLI
Jest to interfejs tekstowy (Command Line Interface) za pomocą którego można administrować Clariionami. Jest to metoda alternatywna do graficznego interfejsu dostępnego poprzez przeglądarkę sieciową i Unisphere. Wykorzystując tą metodę zarządzania wydajemy polecenia bezpośrednio do macierzy (do Management Servera) - nie ma tutaj użycia domeny i pojedynczego punktu do zarządzania i monitorowania.

Clariion - architektura (Storage Processor)

Kontynujemy opis architektury Clariiona - tym razem skupimy się na głównym jego komponencie czyli storage procesorze:

Storage Processor (SP) to "mózg" kierujący macierzą (duża część Clariionów ma takich "mózgów" dwie sztuki). On obsługuje żądania I/O jakie trafiają i pilnuje bezpieczeństwa danych i zapewnia żeby odpowiednie hosty miały dostęp do odpowiednich LUNów.

Każdy SP posiada jeden lub dwa (w zależonści od modelu) processory Intel Xeon oraz od 3 do 16GB RAMu.

MODEL	CX4-120	CX4-240	CX4-480	CX4-960
Procesor	1 dual core 1,2GHz	1 dual core 1,6GHz	1 dual core 2,2GHz	2 dual core 2,33GHz
Ilość RAMu	3GB	4GB	8GB	16GB

Oprócz tego SP zawiera pamięć cache, która jest podzielona na trzy obszary. W pierwszym znajduje się systemu operacyjny/firmware kontrolera. Nazywa się on FLARE  (Fibre Logic Array Runtime Environment) i tajemnicą poliszynela jest, że tak naprawdę to Windows XP z "nakładką" do obsługi macierzy. Obecnie najnowsza wersja flare w macierzach Clariion to FLARE30.
Pozostałe dwa obszary cache to cache zapisów(write) i cache odczytów(read). Wielkość części zajętej przez system jest stała, natomast możemy zmieniać ilość pamięci przydzielonej na read i write.
Ponieważ pamięć cache jest bardzo szybka w porównaniu do dysków mechanicznych (czy nawet SSD) tak więc jej oczywistym zastosowaniem jest przyśpieszenie obsługi i/o jakie trafiają do macierzy.
Pamięć cache odczytu jest zapełniana danymi, co do których kontroler podejrzewa, że będą potrzebne w najbliższej przyszłości, natomiast do pamięci cache zapisu trafiają wszyskie (z kilkoma wyjątkami) dane wysyłane do macierzy. Po zapisaniu danych do cache macierz wysyła do hosta potwierdzenie udanego zapisu (duży uzysk na czasie niż gdyby host miał czekać aż dane zostaną zapisane na dyskach) a następnie w "czasie wolnym" przerzuca dane z cache na dyski. Więcej o działaniu pamięci cache będzie w jednym z następnych wpisów.

Oprócz CPU,RAMu i pamięci cache , SP zawiera także karty I/O służące do podłaczania do kontrolera serwerów i napędów. Karty mogą być trojakiego typu: FC (z portami o prędkościach do 8Gb/s) lub iSCSI (porty 10Gb/s). Razem z najnowszym release-m firmwaru (FLARE 30,5) Clariion zaczął wspierać także FCOE (Fibre Channel over Ethernet) i jest możliwość dołączenia do niego kart obsługujących ten protokół.

Clariion - wprowadzenie oraz architektura

Clariion jest to nazwa rodziny (linii) macierzy SANowych pozycjonowanych przez EMC jako "mid-range".
Jest (a w zasadzie był) to jeden z najdłużej rozwijanych produktów, jego początki sięgają wczesnych lat 90 a zaprojektowany i  produkowany był przez firmę Data General (przejętą w 1999r przez EMC).
Linia Clariionów została zamknięta w tym roku i zastąpiona modelem VNX, który łączy w sobie funkcjonalność macierzy SAN i macierzy NAS (tzw: "unifed storage").

Ostatnia generacja macierzy Clariion obejmuje sobą następujące modele: AX, CX4-120 , CX4-240 , CX4-480, CX4-960

Porównanie modeli:

MODEL	AX	CX4-120	CX4-240	CX4-480	CX4-960
Maksymalna pojemność	120 TB	235 TB	459 TB	939 TB	1899 TB
Maksymalna liczba podłączonych systemów (hostów)	64	128	256	256	512
Maksymalna liczba LUNów do stworzenia	512	1024	2048	4096	8192
Maksymalna liczba portów Front End (podłączenie z hostami)	4 FC lub 4 IP	4 FC i 4 iSCSI	4 FC i 4 iSCSI	8 FC i 4 iSCSI	8 FC i 4 iSCSI
Cache	2 GB	6 GB	8 GB	16 GB	32 GB
Max liczba dysków	60	120	240	480	960
Wspierane typy dysków	SATAII i SAS	FC, SATA II, EFD (SSD)	FC, SATA II, EFD (SSD)	FC, SATA II, EFD (SSD)	FC, SATA II, EFD (SSD)

Architektura CLARiiONa:

Ponieważ nie znalazłem żadnego schematu architektury Clariiona, który mógłbym spokojnie tutaj przedstawić, nie naruszając praw autorskich, postanowiłem stworzyć takowy samodzielnie.

Biorąc pod uwagę mój całkowity brak zdolności i wyczucia plastycznego, z góry przepraszam za pewną "toporność" poniższej grafiki ;)

I kilka zdań komentarza:

Clariion jest macierzą z redundantną jednostka centralną (kontrolerem) zwanym w przypadku tej linii: Storage Processor-em (SP). Redundancja jest tutaj użyta nieco na wyrost, gdyż pojedynczy storage procesor moze nie dostarczyć wymaganej wydajności, do obsłużenia intensywnie używanej maciezy. Można powiedzieć, że przy obciążeniu SP do 50% zapewnione jest nadmiarowość tego komponentu, jeżeli jednak macierz pracuje, a każdy z jej SP jest obciążony mocniej niż na 50%, to awaria jednej z tych jednostek może spowodować zatrzymanie całej macierzy.

SP komunikują się między sobą za pomocą magistrali zwanej CMI (Clariion Messaging Interface), magistrala ta jest używana między innymi do przesyłania informacji o zawartości i zmianach w cache, tak żeby obydwa SP zawsze miały dokładnie ten sam jego obraz (mirrored cache) - jest to oczywiście związane z poprawą bezpieczeństwa i redukcją ryzyka utraty danych w przypadku uszkodzenia jedego z kontrolerów.

Back End, czyli połączenie pomiędzy SP (cache) a fizycznymi dyskami, to 4 tzw "pętle" FC (mogą mieć 2 lub 4 GB/s przepustowości). Na pętlach podłącza się półki dyskowe (na powyższym schemacie na każdej pętli podpięta jest jedna półka, w rzeczywistości może ich być kilka), dokonuje się tego za pomocą układu zwanego Link Control Card (LCC). LCC kontroluje stan komponentów w obrębie podłączonej do niej półki.

Na jednej półce dyskowej w Clariionie znajduje się do 15 dysków 3,5cala (istnieją także półki dyskowe "wysokiej gęstości" ale nie będę tu o nich pisał).

Dodatkowe komponenty wchodzące w skład macierzy to oczywiście zasilacze (redundantne), dodatkowo podłączone do baterii SPS, pozwalajacych w wypadku utraty zasilania na potrzymanie zawartości pamięci cache, do czasu jej "zrzucenia" na dyski fizyczne oraz kontrolowane wyłączenie macierzy. Clariion ma także cały zestaw wiatraków używanych (a jakże) do zapewnienia właściwego chłodzenia.

---

W kolejnym wpisie kontynujemy zagadnienia związane z budową Clariiona.

Trochę bliżej sprawdzimy między innymi działanie i budowę pamięci cache oraz modułów I/O