wtorek, 7 lutego 2012

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.

4 komentarze:

  1. Czy VNX moze spowodowac utrate danych?
    Ponizej opis gdzie przez 5 dni nie dalo sie przywrocic dzialania:
    http://www.theregister.co.uk/2012/01/13/tieto_emc_crash/

    W komenatarzach znalazlem taka informacje:
    "when VNX loses a controller, it does not go into write-through mode, which means a second controller failure will cause data loss." CO to wlasciwie znaczy? Co to jest write-through...? I czy to rzeczywiscie takie wazne?

    OdpowiedzUsuń
  2. Poruszyłeś dwie sprawy:

    1. Czy VNX może spowodować utratę danych?
    Dane mogą się "zgubić" na każdej macierzy i w każdej architekturze. Oczywiście urządzenia te mają masę zabezpieczeń i nadmiarowych komponentów aby obniżyć ryzyko takiej utraty ale zawsze może zaistnieć taki zbieg okoliczności i koincydencja różnych awarii, że dane stracimy.
    Dlatego oprócz wszyskich zabezpieczeń typu RAIDy, replikacje itd... ciągle trzeba robić backup i przechowywać go najlepiej w innym miejscu niż same dane produkcyjne.

    2. W komenatarzach znalazlem taka informacje:
    "when VNX loses a controller, it does not go into write-through mode, which means a second controller failure will cause data loss." CO to wlasciwie znaczy? Co to jest write-through...? I czy to rzeczywiscie takie wazne?

    Podczas normalnej pracy VNXa i większości innych macierzy mid-range (mających 2 kontrolery) wszystkie operacje zapisu są najpierw umieszczane w pamięci cache a potem dopiero przenoszone na fizyczne dyski. Zaletą takiego działania jest bardzo szybkie działanie. Serwer dostaje potwierdzenie, że jego dane zostały zapisane od razu gdy trafią do szybkiej pamięci cache i nie musi czekać aż zostaną umieszczone na wolnych dyskach. Minus tego działania jest taki, że pamięć cache jest pamięcią ulotną, w momencie awarii danego kontrolera zawartość cache jest niszczona. Ponieważ dane które w nim się znajdowały według serwerów już zostały zapisane, tak więc mamy do czynienia z tzw: niekonsystencją i w rezultacie utratę danych.
    Aby się przed tym uchronić cache na obydwu kontrolerach w macierzy działa w mirrorze - każdy z nich jest dokładną kopią tego w drugim kontrolerze. Awaria jednego z nich nie doprowadzi do stracenia informacji z cache.
    Gdy jednak taka awaria zajdzie macierz powinna się przełączyć w tryb "write-through" - oznacza to, że cache przestaje być używany i wszystkie zapisy trafiają bezpośrednio na dyski fizycznie. Powoduje to dramatyczny spadek wydajności ale jest konieczne - ponieważ nie ma już dwóch kopii cache (jeden kontroler uszkodzony) to dane w cache drugiego nie są w żaden sposób chronione i dlatego trzeba z niego zrezygnować.
    Praktycznie w 99% przypadków zachowanie spójności danych jest zdecydowanie ważniejsze niż ciągłość działania i dlatego wyłączenie cache i przejście w "write-through" jest standardowym działaniem.

    W Flare30 (czyli oprogramowaniu VNX i Clariionów CX4) jest możliwa zmiana zachowania macierzy po utracie kontrolera i używanie cache nawet bez jego mirroringu. Jest to bardzo niepolecane przez EMC.
    Więc odpowiadając na Twoje pytanie:
    W VNXie można wyłączyć przejście w "write-though" i dalsze używanie cache po utracie kontrolera. W takim przypadku awaria drugiego kontrolera jest równoznaczna z utrata danych. Jednak na moją wiedzę takie ustawienie pracy cache jest nierekomendowane przez dostawcę i musi być celowo uruchomione/wymuszone przez administratora.

    OdpowiedzUsuń
    Odpowiedzi
    1. Dzieki za odpowiedz.

      Jedna tylko uwaga. Z tego co pisza na cytowanej stronce przyczyna bylo "rare combination of component errors". Czy nie jest tak, ze huraoptymistyczne kupowanie "macierzy mid-range (mających 2 kontrolery)" (jak piszesz) w miejsce dotychczasowych high-end jednak sie msci...? Producenci tacy jak EMC VNX albo NetApp kusza nizszymi cenami - a w finale dostaje sie dwa kontrolery... No i de facto filer zamiast macierzy. A w koncu podwojne "component errors" nie sa jednak az tak malo prawdopodobne... W cytowanym artykule Tieto polozylo na filerze VNX a) mnostwo danych wielu klientow b) jak sie okazalo krytycznych...

      Mamy teraz w firmie przetarg i zarowno VNX jak i NetApp sa na tapecie. Ale chyba jednak przydalaby sie mozliwosc zastosowania wielu kontrolerow - czyli chyba jednak VMAX... Za duzo mamy danych krytycznych i duzo userow biznesowych. Nie wierze, ze filery obronia sie podczas awarii. Choc pojemnosci sa juz teraz potworne...

      Usuń
    2. Są macierze mid-range, są macierze enterprise - jasna sprawa. Jeżeli dane są naprawdę krytyczne to oprócz sprzętu z najwyższej półki (czyli np: VMAX albo VSP) powinny jeszcze być replikowane do drugiego DC.
      W sumie to jest to sprawa analizy ryzyka: Ile kosztują macierze, jakie mają dostępności (np: 99,999%), ile kosztuje nas niedostępność danych, jakie ryzyko jesteśmy w stanie zaakceptować, itd...

      Usuń