sobota, 17 grudnia 2011

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

poniedziałek, 12 grudnia 2011

Magiczny kwadrat Gartnera dla macierzy

Dzisiaj krótki wpis nie związany z wątkiem Clariionów i przygotowania do certyfikacji z tego zakresu.
Gartner, czyli jedna z największych firm doradczych specjalizujących się w nowych technologiach, opublikowała swój tzw: "magiczny kwadrat" za rok 2011 dla macierzy mid-range oraz high-end.

Kwadrat ten jest układem współrzędnych, gdzie na osi poziomej mamy "completness of vision" co można nazwać innowacyjnością i potencjałem jaki tkwi w danej firmie, na osi pionowej natomiast "ability to execute" czyli jaką siłę przebicia i pozycję na rynku ma dany dostawca.
Te dwie linie dzielą cały duży "kwadrat" na cztery mniejsze. Obecność w danym "kwadraciku" pozwala (oczywiście w przybliżeniu) zaklasyfikowac daną firmę i ocenić jej produkty.

Te cztery mniejsze "kwadraciki" to:

  • Leaders (wysoka "completness of vision" i wysoka "ability to execute") - firmy liderzy, dobra pozycja na rynku, duże możliwości i duży potencjał na rozwój
  • Challengers (niska"completness of vision" i wysoka "ability to execute") - firmy o dużych możliwościach marketingowo-sprzedażowych, silnej pozycji ale nieco w stagnacji. Mniej innowacyjne i nowoczesne.
  • Visionares(wysoka "completness of vision" i niska "ability to execute") - zwykle małe firmy z małym udziałem na rynku, ale oferującym bardzo nowatorskie rozwiązania.
  • Niche players(niska "completness of vision" i niska "ability to execute") - gracze "niszowi" zwykle nie liczący się na danym rynku i z gorszymi rozwiązaniami niż konkurencja

Dla macierzy mid i hig-end Gartner widzi obecną sytuację następująco:

Źródło: Gartner (październik 2011)
Można powiedzieć, NetApp na czele ale bardzo blisko EMC a także HP,IBM i DELL.
EMC mimo iż wciąż wśród liderów to jednak pod względem innowacyjności zostało ocenione nieco gorzej.
Najgorsi z najlepszych to Hitachi. Pojawia się tutaj także firma o której szczerze przyznam mało wiem (i chyba trzeba będzie to zmienić) czyli XIO - jedyny z wizjonerów według Gartnera.

Pozostali gracze to w zasadzie albo "niche players", albo na granicy tak jak Fujitsu i Oracle. Muszę przyznać, że wypozycjonowanie tego ostatniego mnie nieco zaskoczyło - myślałem że będzie lepiej. 

Oprócz samego "magicznego kwadratu" Gartner daje także dość dokładne wytyczne według jakich kryteriów był on wyznaczany oraz wskazuje silne i słabe strony każdego z uwzględnionych producentów.
Nie będę się powtarzał i zainteresowanych odsyłam do samego raportu:

wtorek, 15 listopada 2011

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.




Przejście na konto z Google+

Mała zmiana na tym blogu.
Połączyłem swoje konto Bloggerowe z kontem Google+

Bezpośrednie zmiany dla czytających są takie, że teraz z prawego górnego rogu będzie straszyło zdjęcie mojej facjaty, a link zamiast do profilu na Bloggerze poprowadzi do Google+
Niestety wszystkie komentarze jakie zrobiłem do tej pory będą dalej wyświetlały jako autora Akodo (czyli nazwę mojego profilu Bloggerowego). Niezbyt to fajne, ale do przeżycia.

Jeżeli z jakiś powodów takie ustawienie mi się "odwidzi" to wrócę na powrót do odseparowania tych dwóch "tożsamości" ale nie widzę zbytnio powodów czemu miałbym tak robić.

Profile połączyłem bo chciałem. Nie stoi za tym żadna większa przyczyna :D

poniedziałek, 7 listopada 2011

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.


piątek, 21 października 2011

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 3GB4GB8GB16GB


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ół.




wtorek, 11 października 2011

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 AXCX4-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)
64128256256512
Maksymalna liczba LUNów
do stworzenia
5121024204840968192
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 GB6 GB8 GB16 GB32 GB
Max liczba dysków 60120240480960
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

poniedziałek, 26 września 2011

Get proven 2 - Specialist!

 Ponad rok temu (dokładnie 11 lipca) pojawił się na tym blogu wpis o nazwie Get Proven!, w którym opisałem z grubsza ścieżki certyfikacyjne dla produktów i technologii firmy EMC. Na samym opisie się nie skończyło i kilka następnych miesięcy przygotowywałem się (między innymi przez pisanie i omawianie materiału na tym blogu) do podstawowego egzaminu EMC (E20-001) dającego tytuł Information Storage Assosiate.
Egzamin szczęśliwie udało się zdać i od 1 kwietnia 2011 jestem szczęśliwym posiadaczem certyfikatu i tytułu EMCISA.




Co dalej?
Dalsze plany miałem z grubsza określone - chciałem po przerwie rozpocząć przygotowania do kolejnego egzaminu, już z tych bardziej zaawansowanych (poziom Specialist) a konkretnie do E20-522 CLARiiON Solutions Specialist Exam. Niestety w między czasie EMC zrobiło niespodziankę i zakończyło swoją linię macierzy klasy mid-range Clariion i zastępując ją macierzami typu "unified storage" (czyli SAN+NAS) nazwanych VNX. Miałem pewne dylematy związane z inwestowaniem swojego czasu i wysiłku w naukę o technologii, która jest już zastępowana czymś innym ale ostatecznie postanowiłem jednak podszkolić się i może za jakiś czas podejść do tego E20-522.
Powodów jest kilka: 
Po pierwsze, VNXa to widziałem jedynie na prezentacjach, w artykułach i testach publikowanych w  Internecie oraz miałem okazję pobawić się jego symulatorem (w najbliższej przyszłości będę mógł także jednego "pokatować" w EMC Labie). Jeżeli natomiast chodzi o Clariiony, to mam na stanie całą ich gromadkę i swego czasu nawet głównie na mnie spoczywały sprawy związane z ich administracją. Czuję się po prostu dużo bardziej kompetentny w ich temacie.
Po drugie, Clariion-y całkiem dobrze się jeszcze trzymają i na 100% przez następne kilka lat będziemy je spotykać.
Po trzecie, VNX to tak naprawdę Clariion + Celerra włożone do jednego pudełka i lekko zmodyfikowane. Wiedzę o Clariionie oraz działaniu jego systemu operacyjnego (FLARE30) można bezpośrednio przełożyć na wiedzę o działaniu VNXa (a przynajmniej jego części odpowiedzialnej za dostęp blokowy do danych). Nauka o tej "wycofanej linii" nie będzie czasem straconym a informacje w ten sposób zdobyte przydadzą się przy zarządzaniu VNXami.


Następne wpisy
Podobnie jak przy nauce do poprzedniego egzaminu (wszystkie wpisy otagowane jako E20-001 i rozpoczynające się od ISM) kolejne partie materiału, jakie będę sobie powtarzał/przyswajał mam zamiar umieszczać w formie notatek na tym blogu. Nie wiem jeszcze z jakich źródeł będę korzystał przy nauce, najprawdopodobniej będzie sporo z White Paper-ów EMC (jest tego masę na PowerLink-u) ale rozpocznę od  materiałów szkoleniowych z kursu EMC "Clariion Host Integration an Management with Snap View, SAN Copy and MirrorView". Nazwa długa ale trening był całkiem przyjemny i wartościowy - szczególnie jeżeli chodzi o kompleksowe przypomnienie sobie podstaw.


Niestety z racji małej ilości czasu, wpisy pewnie nie będą pojawiały się regularnie, ale postaram się żeby co jakiś czas coś nowego "spłodzić"
Trzymać kciuki ;)

wtorek, 23 sierpnia 2011

Wakacje + zmiana wyglądu

Obecnie szykuje się przerwa w moim pisaniu na blogu z racji sezonu urlopowego. W tej chwili najważniejsze sprawy dla mnie do prognoza pogody oraz znalezienie skutecznego sposobu na komary i przypieczony słońcem kark. Do bloga i spraw związanych ze storage wrócę pewnie gdzieś w wrześniu.

Ponieważ jednak nie jestem całkowicie odcięty od sieci to co jakiś czas loguję się i udzielam w różnych ciekawych miejscach, ogólnie związanych z IT. Na jednym z tego typu portali dostałem bardzo cenną opinię, że MetaStorage nie jest zbyt przyjazny "wizualnie" i przydała by się zmiana kolorystyki - co też uczyniłem.

I to na tyle...


Do poczytania:
Tylko ten jeden link

niedziela, 7 sierpnia 2011

VMAXe - duże maleństwo

Ostatni miesiąc był dość bogaty w ogłoszenia i premiery nowych wersji znanych produktów. Najpierw IBM ogłosił powstanie trzeciej generacji macierzy XIV, kilka dni po tym pojawiła się nowa wersja vSphere, a jeszcze później EMC zaanonsowało powstanie nowego modelu swojej flagowej macierzy enterprise, który został  nazwany VMAXe.

EMC Symmetrix


W EMC linia macierzy klasy "enterprise", czyli tych przeznaczonych dla największych przedsiębiorstw o bardzo dużych potrzebach dotyczących przestrzeni, bezpieczeństwa i ciągłego działania, nosi nazwę EMC Symmetrix.
Aktualne modele z tej linii to VMAXy, które kilka lat temu zastąpiły macierze DMX.

VMAX to macierz bardzo potężna, skalowalna do ponad 2000 dysków. Sercem macierzy są jednostki zwane VMAX Engine ( może ich być od 1 do 8), z których każda jest jakby podwójnym (redundantnym) kontrolerem.
Oczywiście VMAX gwarantuje najwyższą możliwą dostępność, współpracę z mainfraimem i masę dodatkowych funkcjonalności takich jak replikacje synchroniczne, wsparcie dla VMware, thin provisioning, automatyczny tiering itd... , jak się można domyślać cena VMAXa także jest odpowiednio duża.

VMAXe

Nie wiem czy ojcem VMAXe jest dział marketingu, techniczny czy "rozpoznania potrzeb klienta" w każdym razie
EMC stwierdziło, że pomiędzy macierzami klasy midrange (VNX) a enterprise (VMAX) można "upchnąć" coś jeszcze. Tym czymś został właśnie VMAXe.

Pozycjonowanie na tle innych produktów jest następujące:



Czym różni się VMXe od "normalnej" macierzy "VMAX"?


  • Mniejsza skalowalność "pojemnościowa" - VMAXe max 960 dysków, (VMAX = 2400)
  • Mniejsza skalowalość "wydajnościowa" - VMAXe - do 4 Directorów (VMAX do 8) - director to jednostka zarządzająca, każdy z nich jest zbudowany z dwóch redundannych konrolerów.
  • Mniejsza ilość portów na front-endzie - VMAXe do 64, dla VMAX-a jest to 128
  • Brak SRDFa , jego rolę przejmuje oprogramowanie RecoveryPoint
  • Brak wsparcia dla inerfacu FICON
Bardzo dużą zaletą macierzy VMAXe ma być możliwość jej błyskawicznej instalacji i skonfigurowania. Według EMC - w 4godziny od dostarczenia macierz może być uruchomione i w 4 minuty po uruchomieniu można wystawiać pierwsze zasoby.



Podsumowując - VMAXe to standardowy produkt powstały przez wycięcie części funkcjonalności i możliwości rozbudowy wersji oryginalnej i z fanfarami zaprezentowany jako coś nowego i rewolucyjnego.
Czy jest na niego miejsce na rynku, ciężko ocenić - nie wiem ile firm ma zapotrzebowanie na "malutkiego enterprise-a". - szczególnie, że te "standordowe rozwiązania" także mogą być wyskalowane dla relatywnie niewielkich zasobów (np: VMAX SE) 

Do poczytania:



wtorek, 12 lipca 2011

XIV Gen3 - nowa generacja pozytywnego "szajsu"

Kiedy 15 miesięcy temu, na tym blogu pojawił się pierwszy "merytoryczny" wpis (po dwóch organizacyjno-osobistych) dotyczył on IBM-owskiej macierzy XIV i nosił tytuł "Pozytywny szajs"
"Szajs" to coś byle jakiego - w tym przypadku chodziło o dyski SATA, duże i tanie ale niezbyt szybkie i mało "prestiżowe", pozytywny - bo archiektura XIVa była na tyle ciekawa, że niwelowała wady dysków SATA, przez co dostawaliśmy relatywnie tanią macierz, którą można było zaklasyfikować (nie bez pewnych oporów) do sektora mid-range. Więcej informacji i rozwinięcie tematu w poście sprzed ponad roku  ( XIV - Pozytywny szajs ).

XIV Gen3

Wracam do tej "zamierzchłej" historii ponieważ IBM właśnie ogłosił powstanie trzeciej generacji macierzy XIV.
Gwoli informacji: Generacja I to macierze produkowane przez firmę XIV (sic!) i noszące nazwę Nextra. Druga generacja powstała już po wykupieniu XIVa przez IBMa i zmianie nazwy tej rodziny macierzy na XIV właśnie - to ona została opisana na tym blogu i określona mianem "Pozytywnego szajsu".

Trzecia generacja to dalej ta sama architektura, ale odświeżeniu uległy wszystkie jej komponenty.
Po pierwsze dyski SATA, zostały zastąpione napędami NL-SAS (Near Line SAS) - nazwa może trochę myląca (ale oczywiście jest to zamierzone) - chodzi o dyski z mechaniką SATA ale do komunikacji używające interfejsu SASowego. Dostajemy lepszą obsługę kolejkowania poleceń, sprawniejszą obsługę/korekcję błędów i nieco lepszą wydajność. Druga z dużych zmian to wprowadzenie połączenia Infiniband pomiędzy modułami.
Z innych mniej znaczących zmian można wymienić:
  • Obsługę 8Gbit/sec na front-endzie
  • Szybsze procesory na kontrolerach
  • Nowy rack (wow)
  • Nowe lepsze GUI ( wow^2)
Jeżeli mówimy o wydajności to Gen3 jest od Gen2 od 2 do 3 razy szybszy (oczywiście według danych i testów samego IBMa)


Jeżeli ktoś miałby ochotę na mocno marketingowy filmik o XIVie i jego nowej generacji to zapraszam:



Do poczytania:

Xiv Gen3 - Both hands clapping
A brief history of xiv
XIV - Product Page

sobota, 9 lipca 2011

Bunkier w serwerowni - Axxana Phoenix System RP

Jednym ze sposobów zabezpieczania danych na macierzy jest ich replikacja do analogicznego urządzenia w lokalizacji zdalnej. Macierz źródłowa używana jest jako maszyna produkcyjna, a wszystkie zmiany przesyłane są do lokalizacji zapasowej. Dzięki temu uszkodzenie/zniszczenie macierzy, a nawet katastrofa (ogień,powódź, zawalenie się budynku) całego centrum komputerowego nie doprowadzi do utracenia przez nas danych.


Replikacja w skrócie:

Replikację można podzielić, z grubsza ,na dwa typy:

Synchroniczna - zapewnia, że w każdej chwili  na macierzy zdalnej, jest dokładny obraz danych produkcyjnych.  Każdy zapis/zmiana przez serwer podpięty do macierzy jest wysyłany do zdalnej lokalizacji i dopiero po przyjściu jego potwierdzenia zapisu, host jest informowany o udanej zmianie.
Zaletą tej replikacji jest zerowa wartość RPO czyli, w przypadku awarii, nasza kopia jest identyczna jak dane na uszkodzonej maszynie. Wady to, przede wszystkim, zwiększony czas oczekiwania i ograniczona odległość na którą można stosować to rozwiązanie (ok 100km).

Asynchroniczna - Potwierdzenie zapisu wraca do hosta od razu po jego wykonaniu na macierz źródłowej. Wszyskie bloki danych które się zmieniły są zapisywane w odrębnym miejscu i cyklicznie wysyłane "w paczce" na drugą macierz. Długość tego cyklu wysyłania danych określa nam jakie RPO uzyskujemy, Np: wysyłając zmiany co 15 minut, w najgorszym przypadku po awarii mamy możliwość pracownia na danych sprzed kwadransu. To jest oczywiście wada tej replikacji, w porównaniu do synchornicznej. Zalety to mniejsze wymagania co do parametrów łącza, szybsze działanie i brak ograniczeń związanych z maksymalną odległością między dwoma serwerowniami.


Axxana Phoenix System RP

Jak widać obydwa typy replikacji mają swoje wady i zalety.
Pytanie , czy istnieje rozwiązanie łączące te drugie i eliminujące pierwsze.
Oczywiście nie, ale istnieje dość dobry zastępnik, który marketingowo nazywany jest "Replikacją synchroniczną po asynchronicznej infrastrukturze"
Produkt posiadający te rozwiązanie to Axxana Phoenix System RP.
Zasada działania niczym nie różni się od zwykłej macierzy z włączoną asynchroniczną replikacją ( wykorzystywany jest Recovery Point od EMC) - zmienione dane są zapisywane i cyklicznie wysyłane do lokalizacji zdalnej. Cały trik polega jednak na miejscu, gdzie te zmiany,są przechowywane przed wysłaniem. Jest to EDR (Enterprise Data Recording) black box.


EDR black box

Pojemnik, w którym znajdują się nie wysłane jeszcze lokalizacji zdalnej dane, jest oparty na technologi używanej do budowy "czarnych skrzynek" w samolotach. Oznacza to, że może wytrzymać ogień o temperaturze ponad 1000 stopni, zalanie wodą, uderzenia, wstrząsy oraz najróżniejsze siłowe próby zniszczenia/uszkodzenia, a także ochronić przed tymi czynnikami swoją zawartość.
Zabezpieczenia te gwarantują, że nawet w przypadku np: zawalenia budynku z serwerownią, dane nie przesłane do lokalizacji zapasowej są bezpieczne. Problematyczne może być wysłanie paczki zmian po takiej katastrofie do drugiej macierzy ale i na to jest rozwiązanie: Phoenix System potrafi w przypadku zniszczenia infrastruktury sieciowej, komunikować się i zainicjować transfer za pomocą sieci komórkowej. Nadajnik oczywiście także jest zabezpieczony i znajduje się wewnątrz EDRa.

Dla zainteresowanych polecam następujący film na serwisie YouTube na którym naocznie można przekonać się jakie "tortury" jest w stanie wytrzymać "black box" ( w menu: palenie, dziurawienie, przygniatanie, potrząsanie i inne):





Reasumując:


Rozwiązanie jest ciekawe i dość "efektowne" (przynajmniej przy oglądaniu "testów"). Oczywiście nie zastąpi prawdziwej replikacji synchronicznej i w niektórych przypadkach może być dość problematyczne (wysyłanie dużej ilości danych poprzez sieć komórkową) ale w przypadku gdy odległość między naszymi centrami komputerowymi jest znacznie większa niż 100km może być dobrym zastępnikiem rozwiązania gwarantującego zerową utratę danych (RPO=0) przy awarii/katastrofie.

Do poczytania:

Opis EDRa
Axxana Phoenix System RP
THE PHOENIX SYSTEM RP

czwartek, 30 czerwca 2011

RAID5, RAID6 - czy można im ufać?

Wybór używanej struktury RAIDowe to jeden z pierwszych kroków przy konfigurowaniu nowych przestrzeni dyskowych, a same RAIDy to całkowity elementarz wiedzy storage.
Czy jednak na pewno działanie i benefity związane z tym tematem są dobrze znane?
Czy istnieją ryzyka, nie widoczne na pierwszy rzut oka, a istotnie wpływające na bezpieczeństwo danych na dyskach skonfigurowanych w RAIDy?

Wygląda na to, że tak. A skrótem, który może niejednemu adminowi spędzać sen z powiek jest: URE


URE (Unrecoverable Read Error)

URE(Unreceoverable Read Error) jest to sytuacja, kiedy nie da się odczytać bloku danych z dysku, mimo iż on sam pracuje sprawnie. Dla używanych obecnie dysków SATA URE średnio zdarza się raz na od 10^14 do 10^16 razy. Przeliczając to na wielkości, to dla najgorszego scenariusza (10^14) - błędny sektor znajduje się co  12TB przestrzeni.

Co to oznacza w teorii?

RAID5 jest odporny na uszkodzenie jednego dysku. W takim przypadku najczęściej następuje rozpoczęcie jego odbudowy( wykorzystując dysk "hot spare"), a do tego czasu sama struktura pracuje z ograniczoną wydajnością, wyliczając, "w locie", dane z uszkodzonego nośnika, za pomocą mechanizmów parzystości.
Jeżeli podczas odbudowy, która nie jest niczym innym jak tylko odczytywaniem/rekonsturkcją danych sektor po sektorze i zapisywaniu na "hot spare", wystąpi błąd URE, to odbudowa RAID5 się nie uda, a ponieważ dane nie są dłużej konsystentne (nie uda sie odczyt z bloku z URE) możemy mówić o utracie danych.

Największe obecnie dostępne dla macierzy dyski SATA to 2TB (ale już 3TB "maluchy" się zbliżają).
Przyjmując wystąpienie URE co 12TB, to jeden na sześć dysków (16,6%) SATA 2TB jest jego "szczęśliwym nosicielem". Teraz pomyślmy o strukturze RAID5 działającej na grupie 4+1. Po awarii jednego dysku do rekonstrukcji danych potrzebny jest odczyt z wszyskich pozostałych.
Czyli mamy 4 dyski, dla każdego 16,6% na wystąpienie URE. Wykorzystując odrobinę matematyki wychodzi jakieś 50% szans na utratę danych.
Nieźle...

A co to oznacza w praktyce?

W praktyce nie jest tak źle.
Po pierwsze to dyski SATA używane w macierzach zwykle mają współczynnik URE w granicach 10^15 czyli dziesięciokrotnie mniej niż wartość przyjęta do obliczeń powyżej.
Po drugie SATA nie są (lub przynajmniej nie powinny) być używane dla krytycznych informacji - tutaj jak na chwilę obecną najpopularniejsze są dyski FC i SAS. Niestety nie udało mi się znaleźć informacji na temat częstości występowania błędów URE na tym typie nośników - możliwie, że jest ona pomijanie mała.
Po trzecie - macierze , szczególnie te z obszarów mid-range i enterprise przeprowadzają cały czas w tle sprawdzanie umieszczonych w nich dysków. Zdecydowana większość zgłaszanych przez te urządzenia dysków do wymiany działa sprawnie a jedynie przekroczyło pewne progi dotyczące ilości pojawiających się błędów - dzięki takiemu podejściu bardzo rzadko dochodzi do sytuacji gdy jeden z napędów jest całkowicie niesprawny a sam RAID5  działa bez redundancji i nie potrafi poradzić sobie z pojedynczym URE.

A co z RAID6?

RAID6 zapewnia działanie i dostęp do danych po utracie dwóch dysków. Oznacza to, że możemy mieć awarię napędu i wystąpienie URE podczas odbudowy a dane ciągle będą bezpieczne. Wystąpienie 2 URE na  tym samym sektorze w dwóch dyskach jest praktycznie niemożliwe więc wydaje się, że nic nam nie grozi.
Są jednak opinie, że bezpieczeństwo zapewniane przez RAID6 będzie coraz mniejsze i w końcu stanie się niewystarczające. Obawy te wynikają z faktu, iż pojemności dysków twardych rosną o wiele szybciej niż ich wydajność. W konsekwencji odbudowy dysków po awarii trwają o wiele dłużej (czasem nawet mówimy o dniach), a dodatkowo wewnętrzne mechanizmy sprawdzania napędów przez macierze (scrubbing) także będą o wiele rzadziej sprawdzać poszczególne sektory. Biorąc to pod uwagę, coraz realniejsza staje się sytuacja, kiedy mamy awarię dysku, podczas odbudowy występuje awaria drugiego, a następnie na dokładkę mamy jeszcze URE. Wszystko razem skutkuje utratą danych w RAID6
Specjaliści, którzy ostrzegają przed takim scenariuszem, aproksymują, że ochrona zapewniana przez RAID6 dla dysków SATA będzie wystarczająca do około 2019r. Potem czasy odbudowy będą tak długie, że RAID6 będzie zapewniał ochronę taką jak RIAD5 obecnie czyli teoretycznie żadną (pamiętacie 50% "teoretycznej" szansy na utratę danych po awarii jednego dysku).
Co będzie nas ratowało?
Pewnie RAID7 z potrójną parzystością. ;)

Podsumowując

Dla mnie sprawa jest w miarę prosta.
RAID5 dla FC i SAS
RAID6 dla SATA
I nie ma się co martwić (przynajmniej przez najbliższe 10lat), że staniemy się ofiarą zmasowanego ataku URE podczas jednoczesnego uszkodzenia wielu dysków w jedym RAIDzie.
Ale całkiem możliwe, że się mylę i siedzę na tykającej bombie zegarowej.

I tym optymistycznym akcentem, zakończę wpis.

DO POCZYTANIA:

Why raid5 stops working in 2009
Why raid6 stops working in 2019
Triple-parity RAID and Beyond

sobota, 11 czerwca 2011

VNX - symulator dla każdego!

EMC udostępniło "symulator" macierzy VNXe3100.
Szkoda, że nie można się "pobawić" którymś z bardziej zaawansowanych modeli z tej linii ale dla kogoś kto nie ma dostępu do prawdziwej macierzy, takie demo może dostarczyć dużo radości :D Zobaczyć możemy nie tylko samego VNXa ale i interfejs Unisphere , który może nie jest już taką nowością (obecny już w CLARiiONach z FLARE30) ale nie każdy miał okazję na nim pracować.

Plik do ściągnięcia w tym miejscu:
VNX Demo

PS.
Widzę że demo jest bardzo "realistyczne". Spróbowałem usunąć jedną z predefiniowanych storage pool i czekam już drugi kwadrans na wynik :D

sobota, 28 maja 2011

VNX - macierze wszystkich typów łaczcie się!

W sumie post jest takim trochę odgrzewanym kotletem , ponieważ seria macierzy VNX ma już prawie pół roku, ale z nadmiaru innych tematów blogowych oraz chronicznego braku czasu pojawia się on dopiero teraz.


Breaking Record:

W styczniu 2011 odbył się event EMC pod nazwą"Breaking Record".
Było dość zabawowo, czego przykładem może być próba (udana) bicia rekordu Guinessa w ilości osób jakie zmieszczą się w Mini Copperze:



Podczas konferencji, oprócz marketingowych wygłupów, EMC zaanonsowało także kilkadziesiąt produktów, jakie pojawiają się w jej ofercie, przy czym jednym z najistotniejszych była nowa rodzina macierzy mid-range nazwanych VNX.
Zmiana ta jest bardzo istotna i dość mocno przebudowała macierzowe portfolio EMC. Znikają z ich oferty dwie rodziny urządzeń , a mianowicie Celerry (macierze NASowe) oraz Clariiony (macierzy SANowe), a zamiast nich pojawia się nowy "twór" będący połączeniem tych modeli. Tym samym EMC wzbogaciło swoje portfolio o "unified storage" - czyli macierz potrafiącą wystawiać zasoby zarówno w sposób blokowy po SANie (FC, iSCSI) jaki i plikowy (NFS,CIFS). 


Architektura VNX:

Obsługiwane protokoły:

Architektura VNXa to połączenie CLARiiONa i Celerry - do obsługi blokowego dostępu do zasobów wykorzystywane są Storage Procesory działające pod kontrolą firmware FLARE 30, który jest dobrze znany posiadaczom CLARiiONów. W zależonści od modelu VNX obsługuje połączenia blokowe za pomocą protokołu iSCSI, FC, FCOE.  
Modułami zarządzającymi ruchem plikowym są X-Blades. W maksymalnej konfiguracji VNX ma ich aż osiem, a każdy z nich może działać jako zupełnie niezależny serwer plików. Obsługiwany jest NFS/pNFS , CIFS oraz FTP.
Dodatkowo oprócz protokołów blokowych i plikowych VNX zapewnia także wsparcie dla obiektowego dostępu do danych - zarówno z wykorzystaniem protokołu SOAP jak i REST.

Dyski:

W zależności od modelu, maksymalna liczba dysków waha się od 48 (VNXe3100) do 1000 (VNX7500), isnieją również VNXy Gateway-e, które nie zawierają dysków, a stanowią jedynie "bramy" umożliwiające dostęp plikowy, do zasobów umieszczony w istniejącej już infrastrukturze SAN.
Typy dysków to SSD, lub według nomenklatury EMC - EFD(Enterprise Flash Disk), a także SAS i SATA (Nearline SAS). Oprócz standardowych dysków 3,5 cala VNX obsługuje także dyski 2,5 calowe.

Możliwości:

Seria VNX posiada całą gamę funkcjonalności związanych z zarządzaniem i udostępnianiem danych. Duża część z nich jest licencjonowana i wchodzi w skład tzw: Priced Packs and Suits, które można dokupić/zaaktywować na danej macierzy.
Funkcjonalność dostępna standardowo to między innymi virtual/thin provisioning oraz deduplikacja na poziomie pliku. Automatyczny tiering (FAST) lub wykorzystanie dysków SSD jako dodatkowej pamięci cache (FAST CACHE) jest już opcją płatną i wchodzi (razem z np: QoSem i narzędziemi do analizy wydajnościowej) w skład FAST Suit. Dość przydatne są także paczki z licencjami na replikację: Local/Remote Protection Suit, które umożliwią nam wykonywanie kopii lokalnych (snapshoty i klony) oraz zdalnych (replikacja synchroniczna i asynchorniczna), a także uruchomienie CDP (Constant Data Protection) za pomocą oprogramowania Recovery Point. Kolejną paczką z nowymi funkcjonalnościami jest Security and Compliance Suit, gdzie znajdują się moduły zapewniające szyfrowanie, kontrolę antywirusową oraz zakładanie tzw: retention locków na dane, czyli uniemożliwiające ich skasowanie i zmianę przed upływem ustalonego okresu czasu.


Rodzina VNXów:

Składa się z dwóch linii macierzowych.
Pierwsza z nich to seria VNXe (Neo) przeznaczona dla małych-średnich przedsiębiorstw. Macierze te są niewielkie i nie obsługują protokołu FC, dostęp blokowy zapewniony jest jedynie za pomocą iSCSI.
VNXe jest skierowana do przedsiębiorstw w których, ze względu na wielkość działów IT,  nie ma dedykowanych administratorów pamięci masowych - priorytetem jest łatwość i intuicyjność w obsłudze.
Druga seria to macierze VNX (Culham), z przeznaczeniem na przedsiębiorstwa średnie i duże - te maszyny są dużo większe, dużo bardziej skalowalne oraz dysponują większymi możliwościami.

Porównanie macierzy VNX (źródło:EMC)

Podsumowanie:

Trochę ciężko rozstać się z dobrze znanymi markami takimi jak CLARiiON i Celerra, ale trzeba iść do przodu, a VNXy wyglądają naprawdę interesująco. Dodatkowo w maszynie jest jeszcze potencjał (np: retention lock i obsługa protokołów objektowych), który może sprawić, że np ten model zastąpi także macierz archiwizacyjną Centera. Unifikacja jest w końcu jednym z trendów w dzisiejszym świecie storage.





Taśma kontratakuje!

W erze deduplikacji i  backupów do chmury wydawało by się, że składowania na taśmy magnetyczne powoli będą odchodziły w zapomnienie. Plotki mówią nawet , że w ośrodkach R&D EMC hasło "Tape is dead" zostało zastąpione ostatnio przez "VTL is dead" - czyli już nawet nie same taśmy i biblioteki ale nawet urządzenia je udające są w niełasce i odwrocie.

Z drugiej strony jeżeli już mówiło się o taśmach to zwykle o standardzie LTO i jego nowej odsłonie LTO5 oraz rozszerzeniu roadmapy aż do 8 wersji tej technologii. Inne rozwiązania gdzieś były z boku i wykorzystywane raczej niszowo.
Nie znaczy to jednak, że nic się poza LTO w świecie taśm nie dzieje - wręcz przeciwnie.
Od kliku (kilkunastu) lat między dwoma firmami toczy się prawdziwy wyścig zbrojeń i walka na posiadanie jak najszybszego napędu i jak najbardziej pojemnej taśmy magnetycznej. Mówimy tutaj o napędach kiedyś dedykowanych pod mainfraimy (obsługa interfejsów FICON i ESCON) a teraz obecnych także w rozwiązaniach enterprise - z jednej strony mam IBMa i jego serię napędów 3592 (Jaguar) a po drugiej Sun Microsystems (teraz część Oracle) i linia T10000.
Swego czasu obydwie firmy starały się wyprzedzić konkurenta i jako pierwsza wypuścić taśmę o pojemności 1TB. Wyścig wygrał Sun wypuszczając w czerwcu 2008 roku napęd T10000B obsługujący nośniki o natywnej(nieskompresowanej) pojemności 1TB, IBM "spóźnił" się jedynie o 3 miesiące i we wrześniu 2008 pokazał trzecią generację Jaguara czyli napęd T1130 o takiej samej jedno-terabajtowej pojemności.
Ostatnie miesiące pokazały, że ani IBM ani Sun/Oracle nie powiedziały jeszcze ostatniego słowa, a szybkość rozwoju technologicznego sektora napędów hi-end może zawstydzić LTO, z jego skromniutkim planem podwajania pojemności co mniej-więcej dwa lata.
Z początkiem tego roku Oracle zaanonsował T10000C, który pięciokrotnie (!) zwiększa dotychczasową pojemność. Natywnie 5TB, prędkość max 240MB/s i 2GB bufor robią wrażenie, IBM musiał jakoś na to zareagować. Przedwczoraj (9 maja) ogłosił nowy napęd z serii 3592 o nazwie TS1140 - ponieważ jest on w stanie nagrać mniej danych niż konkurent (4TB), to spece od reklamy zachwalają  go nie jako największy ale  najszybszy z dostępnych na świecie przewijaków (250MB/s - całe 10 szybciej niż T10000C - niech żyje marketing).

Ciekawe jak dalej potoczy się sprawa, abstrahując już od konkrurencji w tym sektorze napędów, nośnik zawierający 12TB danych (po kompresji), nie wydzielający ciepła i nie pobierający energii po nagraniu, który może być przechowywany w dużych ilościach na relatywnie małej powierzchni (np szafa HD do biblioteki TS3500) stanowi całkiem realne zagrożenie dla innych rozwiązań backupowych, dla których już "odrtąbiono" zwycięstwo i "zabicie" taśmy.
Promotorzy rozwiązań deduplikacyjnych będą mieli całkiem ciężkie zadanie aby udowodnić opłacalność swoich rozwiązań.

Jedna sprawa może tylko zastanowić - wykorzystując 8Gb/s łącze fc i wysycając zupełnie napęd, zapisanie pełnego nośnika zajmie prawie 6 godzin.  W wielu przypadkach nie będziemy mieli do dyspozycji takiego okna backupowego - no ale od czego bufory na VTLu ;)

Do poczytania:

sobota, 30 kwietnia 2011

Duże biblioteki

Serwerownie, szczególnie te największe, to miejsca gdzie znajduje się wiele różnego rodzaju urządzeń, z których większość jest dość sporawych rozmiarów. Są jednak pewne elementy  wyróżniające się gabarytami nawet wśród szaf pełnych serwerów czy macierzy załadowanych dyskami. Najwięcej miejsca i największe wrażenie swoimi gabarytami robią biblioteki taśmowe z segmentu hi-end, długie czasem na kilkanaście szaf , z robotami poruszającymi się w środku i z oknami umożliwiającymi obserwację ich pracy, stanowią dość intrygujące elementy infrastruktury datacenter.

Czym jest biblioteka taśmowa?

Jest to jedno z urządzeń wchodzących w skład środowiska backupowego wykorzystującego taśmy magnetyczne. Taśma magnetyczna, jako nośnik danych przeżywa ostatnio duży kryzys . Co prawda jest jeszcze bardzo popularna, a sama technologia ciągle rozwijana ( np: w 2010r został wprowadzony standard LTO5 pozwalający na przechowanie 3TB danych na 1 taśmie), ale coraz więcej firm uznaje ją za rozwiązanie przestarzałe i wybiera metody backupu wykorzystujące dyski twarde i deduplikację lub najnowsze rozwiązania wykorzystujące składowanie do tzw. chmury.
Sama filozofia wykonywania składowania na taśmę jest bardzo prosta. Serwer backupu wysyła strumień danych, który następnie jest przesyłany (bezpośrednio lub np: z wykorzystaniem sieci SAN) do napędu taśmowego, a ten z kolei zapisuje te dane na taśmę magnetyczną. Na tym w sumie koniec filozofii z backupem na taśmy, gdyby nie fakt, iż samo ładowanie i rozładowywanie napędu z taśmy musi być wykonywane ręcznie. Przy małym wolumenie i pojedynczym napędzie nie stanowi to problemu, ale gdy ilość taśm osiągnie wielkość setek (lub tysięcy), a napędów kilkunastu to wymagane jest zautomatyzowanie sposobu dostarczania i przechowywania nośników. Rozwiązaniem tego problemu jest właśnie biblioteka taśmowa. Składa się ona zwykle z jednostki sterującej, kieszeni( slotów) w których umieszczane są nieużywane w danym momencie taśmy, jednego lub więcej napędu taśmowego oraz robota ( zwanego także accessorem lub pickerem), którego rolą jest podawanie taśm do napędów i odkładanie ich do slotów po zakończonym odczycie/zapisie. Jeżeli chodzi o rozmiary bibliotek, to są one najróżniejsze - od malutkich "pudełeczek" o wielkości 4U i pojemności kilkunastu taśm, do prawdziwych gigantów mających po kilkadziesiąt metrów i dziesiątki tysięcy slotów na nośniki.

Jak jest zbudowana biblioteka taśmowa?

Zdecydowana większość bibliotek posiada te same elementy składowe. Przede wszystkim są to tzw.: sloty , czyli „półeczki „ na których leżą tasiemki , kolejną częścią, która jest integralną składową każdej biblioteki jest robot, zwany także czasem picekrem lub accessorem , a którego zadaniem jest transport kasetek między slotem a napędami. Ostatnia część znajdująca się w każdej bibliotece to napęd taśmowy, którego ilość waha się od jednego w najmniejszych modelach do kilkudziesięciu w tych największych.
Oprócz tych trzech podstawowych elementów, które znajdują się w każdej bibliotece taśmowej, zdecydowana większość modeli posiada także inne urządzenia, zapewniające dodatkowe funkcjonalności. Najczęściej spotykane to:
  • Podajnik na kasety (Mail slot , CAP , I/O Station) - jest to miejsce, dzięki któremu można dokładać i usuwać taśmy z biblioteki, bez potrzeby jej zatrzymywania. W mniejszych modelach może to być coś w stylu szufladki ze slotami , większe posiadają duże podajniki wbudowane w drzwi i mieszczące po kilkadziesiąt kaset naraz.
  • Konsola - umożliwiająca bezpośrednią diagnostykę i sterowanie biblioteką. Czasem jest to tylko mały ekranik LCD i dwa przyciski, w większych modelach mogą to być osobne dedykowane serwery ze specjalnie przygotowanym oprogramowaniem.
  • Zatoka serwisowa - tą funkcjonalność mają tylko największe z bibliotek. Zwykle ich krańcowe części mogą być fizycznie odizolowane od reszty i służyć do serwisowania robotów bez potrzeby wyłączania całej maszyny.

Duże biblioteki?

Najpierw słowem wyjaśnienia, co uznajemy za "dużą" bibliotekę. Jednym z głównych kryteriów jakimi się kierowałem była sama wielkość biblioteki - musi być skalowalna poza jedną szafę. Dodatkowo najlepiej, aby oferowała funkcjonalności dostępne dla rozwiązań HA (High Availability) czyli np: redundantnego robota, ale nie był to dla mnie wymóg twardy.
Ogólnie opisane zostaną następujące modele:

IBM:
  • 3494
  • TS3500
Oracle/Sun:
  • SL8500
  • SL3000
  • 9310
Spectra Logic:
  • T-Finity

IBM:

Hi-endowe biblioteki IBMa ( czyli model 3494 i jego następca TS3500) mają typową architekturę jaka jest stosowana dla tego typu rozwiązań. Jest to liniowy układ z szafą serwisową na początku i szafami ze slotami i napędami sukcesywnie dołączanymi jeden obok drugiego podczas rozbudowy bibliotek. Ciekawie załatwiona jest sprawa zapewnienia wysokiej dostępności. Sam robot w tych modelach może być zaopatrzony w podwójny chwytak (gripper) - wykorzystanie tego mechanizmu wiąże się z wadami i zaletami. Wadą jest ograniczenie pojemności biblioteki, gdyż użycie dwóch gripperów w jednym robocie powoduje, że najwyższe dwa rzędy na kasetki w każdej szafie są niedostępne i muszą być zaślepione. Co do zalet to oczywiście poprawiona jest dostępność danej biblioteki, nawet w przypadku uszkodzenia jednego z chwytaków, robot pozostaje sprawny; dodatkowo nieco zwiększa się szybkość montowania kasetek - jeżeli w napędzie już załadowana była taśma, to robot zamiast rozładować przewijak, a następnie pobrać i załadować nową taśmę, robi to w jednym ruchu wykorzystując obydwa chwytaki. Dodatkowo, oprócz zapewnienia sobie redundancji w obrębie pojedynczego robota, można dokupić "pełną" funkcjonalność HA pod postacią dodatkowego pełnego robota i drugiej zatoczki serwisowej. W takim przypadku dodatkowy „service bay” instalowany jest na drugim końcu biblioteki. Rozwiązanie takie ma kilka zalet zwiększających dostępność i niezawodność biblioteki poprzez zwiększenie jej "odporności" na błędy. Po pierwsze mamy dwa roboty, w razie awarii jednego z nich, drugi delikatnie "dopchnie" go do zatoczki  serwisowej i sam zacznie obsługiwać całą bibliotekę. Drugi bonus, który jednak występuje jedynie w starszej bibliotece czyli 3494 to zdublowanie jednostek sterujących biblioteką (tzw: Library Managerów), które wbudowane są w tył szaf serwisowych ( gwoli ciekawostki: system operacyjny na którym działają Library Mangery to OS/2). Po takim zdublowaniu obydwie jednostki łączą się w klaster i w razie awarii jednej z nich system automatycznie (w teorii) przełączy się na pozostałą.
Obydwie biblioteki (3494 i TS3500) obsługują wywodzące się z mainframów napędy IBMa - Jaguary, które w najnowszej generacji 3 potrafią zapisać do 1TB (nieskompresowanych) danych. Nowszy model TS3500 (zwany także Anaconda) obsługuje również napędy LTO, aż do najnowszej wersji 5. Całkiem nowatorskim rozwiązaniem (i to na skalę globalną) wykorzystanym w TS3500 są szafy o podwyższonej gęstości (HD - High Density) - taśmy znajdują się w takiej szafie w kilku warstwach jedna za drugą. Dla taśm LTO ilość warstw jest równa 5, dla taśm z Jaguarów 4. Co prawda szybkość dostępu do kasetek z takiej szafy zmniejsza się, ponieważ robot musi wyciągnąć wszystkie taśmy z warstw wcześniejszych w danym slocie, ale utrudnienie to zniwelowane o wiele większą pojemnością danej szafy, w której mieści się grubo ponad 1000 taśm ( dokładnie 1320 dla LTO).
Jeżeli chodzi o porównanie bibliotek 3494 i TS3500, to oprócz dodatkowych funkcji takich jak wsparcie dla LTO, czy szafy HD , nowa biblioteka jest znacznie lepiej diagnozowalna i udziela większej ilości informacji o swoim działaniu i potencjalnych uszkodzeniach. 3494 - uczy pod tym względem człowieka cierpliwości, sygnalizując wystąpienie błędu, ale nie informując w wielu wypadkach, na jakim komponencie.

Oracle/Sun

W zasadzie biblioteki opisane w tym akapicie nie są ani firmy Oracle ani Sun, ale StorageTek ( z wyjątkiem 9310). Dwie z nich cały czas są w sprzedaży,  natomiast trzecia 9310 jest już rozwiązaniem niewspieranym, natomiast na tyle oryginalnym, że wartym chociażby krótkiej wzmianki. 
Zacznijmy od najstarszej konstrukcji, czyli biblioteki 9310 Powderhorn - jest to konstrukcja o tyle inna od pozostałych, że ma kształt oktagonu, którego boki są ścianami ze slotami i napędami. Całość obsługiwana jest przez jednego robota poruszającego się ruchem obrotowym. Kolejnym rozwiązaniem wyróżniającym 9310 od innych bibliotek jest moduł LMU (Library Management Unit), który odpowiada za komunikację między hostem a robotem (polecenia montowania/odmontowania kasetek do napędów) - moduł ten jest w 9310 oddzielną jednostką i nie musi być w tym samym miejscu, co reszta biblioteki.
Po chwili spędzonej w "muzeum" możemy zająć się bardziej aktualnymi okazami ze stajni Oracle, czyli modelami SL3000 i SL8500. Najpierw ten pierwszy, jako znacznie mniej ciekawszy.
SL3000 -  w zasadzie o tej bibliotece nie da się powiedzieć nic specjalnego. Standardowy liniowy układ i prosty tor, po jakim poruszają się roboty. Sama biblioteka jest skalowana aż do 12 modułów – szaf i ma możliwość zastosowania do 2 robotów ( zwanychtutaj tallbot lub t-bot). Z powodu swoich gabarytów i pojemności, oraz rozwiązań HA (High Avilabilty) można zaliczyć ją do bibliotek dużych , ale nie ma w niej nic ponadto co wyróżniało by ją od typowych modeli tego segmentu.
SL8500 - dość ciekawe rozwiązanie o nietypowej konstrukcji. Sama biblioteka jak i pozostałe ( z wyjątkiem 9310) ma budowę modułową. SL8500 posiada jednak tylko jeden moduł będący odpowiednikiem racka serwisowego. Nazywany on jest w tym modelu CIM (Customer Interface Module) i jest znacznie szerszy (jak i cała biblioteka) od typowej szafy bibliotecznej - Spowodowane jest to tym, iż znajdują się w nim obydwa końce toru, po którym poruszają się roboty, a dodatkowo jeszcze pomiędzy nimi znajduje się konsola do sterowania i monitorowania pracy biblioteki. Oczywiście obecność obydwu zakończeń toru ruchu robotów w jednym module wskazuje, że kształt tego toru nie jest standardowy- w przypadku SL8500 jest on podobny do litery U z początkiem i końcem właśnie w części CIM. Na drugim końcu biblioteki mamy moduły DEM (Drive & Electornics Module) i RIM (Robot Interface Module) - w DEM możemy umieścić do 64 napędow, a RIM jest miejscem gdzie tor ruchu robotów zakręca i zawraca. Pomiędzy CIMa a RIMa dokłada się szafy ze slotami( SEM - Storage Expansion Module).
Sam kształt toru po jakim jeżdżą roboty nie jest jedynym wyróżnikiem SL8500 , sama ich ilość także jest nietypowa. W tej bibliotece standardowo znajdują się 4 roboty (zwane h-botami), a jeżeli interesuje nas wersja HA (High avaliability) to liczba ta rośnie do 8. Wynika to z architektury samej biblioteki gdzie tor ruchu nie jest "pojedyńczy" ale składa się z czterech równoległych "szyn", rozłożonych równomiernie jedna nad drugą na całej wysokości biblioteki. Każda z takich "szyn" jest torem dla jednego robota (lub dwóch w wersji HA) i każdy z takich robotów ma dostęp jedynie do 1/4 slotów znajdujących się w bibliotece oraz tylko to tych napędów, które znajdują się na odpowiedniej dla niego wysokości. Same roboty są oczywiście dużo mniejsze niż te występujące w innych bibliotekach klasy "hi-end". Takie poziome podzielenie jednej jednostki na cztery niezależne części ma oczywiście swoje zalety, z których kluczową jest przyśpieszenie czasu podmontowania/zdemonotania taśm wynikające z faktu, że naraz pracuje 4 lub nawet 8 robotów. Minusem jest duża komplikacja i wydłużony czas obsługi żądania,  gdzie kasetka znajduje się w "domenie" innego robota niż tego który obsługuje jej miejsce docelowe (np: wolny napęd). W takim przypadku kasetka musi zostać zawieziona do tzw.: windy (które znajdują się niedaleko modułów CIM), następnie tą windą poruszającą się jedynie w kierunku góra-dół zwieziona na odpowiednią warstwę i stamtąd pobrana przez drugiego h-bota który zawiezie ją do celu.
Sama biblioteka po maksymalnym rozbudowaniu ( do 5 modułów SEM) mieści w sobie do około 10.000 taśm i może mieć do 64 napędów.  To jednak nie wyczerpuje możliwości. Biblioteki SL8500 można łączyć ze sobą tworząc tzw.: kompleks. Poszczególne SL8500 stawia się równolegle do siebie i łączy ze sobą za pomocą specjalnych przejściówek PTP - "pass-thru" port. Maksymalny wspierany przez Oracle kompleks składa się z 10 SL8500, co daje sumarycznie możliwość stworzenia jednej gigantycznej biblioteki zawierającej 100.000 taśm, ponad 600 napędów i do 80 robotów. Wykorzystując standard LTO5 w takim "kolosie" możemy przechować do 150PB danych (300PB licząc standardową kompresję 2:1). Problematyczny, w przypadku tak dużego tworu, staje się czas , jaki jest potrzebny na podmontowanie taśmy - w najgorszym przypadku droga taśmy do napędu wiedzie przez kilka bibliotek, portów PTP (które mają ograniczoną pojemność) i windy. 

Spectra Logic - T-Finity

I na zakończenie najbardziej egzotyczna, przynajmniej dla mnie, konstrukcja. Niestety w przeciwieństwie do innych opisanych tutaj modeli nie miałem z nią styczności bezpośrednio, dlatego bazuję na materiałach dostępnych w Internecie, ale wydaje mi się ona na tyle interesująca, a ponadto mało znana, że chciałbym o niej wspomnieć.
Biblioteka T-Finity jest biblioteką o architekturze liniowej. Pierwszym wyróżnikiem jest ilość modułów, o jakie możemy ją rozbudowywać aż 25. Powoduje to, iż jest to największa z dostępnych na rynku bibliotek. Kolejną cechą i rozwiązaniem według mnie rewolucyjnym jest technologia, w jakiej przechowywane są taśmy - coś podobnego występuje w IBMowskich szafach HD (opisanych przy okazji modelu TS3500) ale w T-Finity jest to po pierwsze standardem, a po drugie występuje pod inną(efektywniejszą) postacią. W czym rzecz, otóż w innych bibliotekach taśmy spoczywają w slotach (szufladkach) znajdujących się w szafach/modułach i tworzących na nich coś w stylu "siatki" z kolumnami i wierszami. IBMowska szafa HD, w jednym slocie potrafi umieścić jedna za drugą  4 lub 5 kasetek (w zależności od ich typu),co kilkukrotnie zwiększa to pojemność takiej szafy, ale jednocześnie sprawia, że przed użyciem taśmy "z głębi" robot musi wyciągnąć i tymczasowo "poupychać" i innych slotach wszystkie taśmy jakie znajdują się przed nią. Rozwiązanie zastosowane w T-Finity opiera się na innym mechanizmie, w slotach nie umieszczane są tutaj kasetki, ale specjalne koszyki. 
Koszyk jest to zwykły plastikowy pojemnik, do którego mieści się 10 taśm. Robot posiada dwa rodzaje chwytaków, pierwszym z nich wyciąga cały koszyk ze slotu , drugi z wyciągniętego i trzymanego koszyka wybiera odpowiednią taśmę. Rozwiązanie tego typu ma kilka zalet. Po pierwsze w nawet w porównaniu do szafy HD, gęstość upakowania taśm jest znacznie większa. Po drugie, nie ma opóźnień związanych z wyładowywaniem wszystkich taśm z warstw wyższych, cały kosz wyciągany jest od razu i trzymany przez robota podczas całej operacji. Po trzecie - robot jest zdolny do przenoszenia 10 taśm za jednym razem, co znacznie przyśpiesza operacje wykonywane na grupie kaset.
 Z innych cech T-Finity, to podobnie jak dla SL8500 istnieje możliwość łączenia ich w kompleks - w tej chwili wspierane jest połączenie do 4 jednostek, co sumarycznie daje wielkość 130.000 taśm i pod względem wielkości deklasuje każde inne rozwiązanie. 
T-Finity posiada także wiele innychfunkcjonalności, których na próżno szukać u konkurencji . Wbudowana kontrola zużycia fizycznego taśm (MLM - Media Lifecycle Management) ostrzega nas gdy któraś z kasetek jest nadmiernie zużywana (zbyt dużo razy montowana lub np: nie używana od bardzo dawna) , podobny mechanizm kontroluje napędy (DLM - Drive Lifecycle Management).
Podsumowując T-Finity firmy Spectra Logic wygląda naprawdę imponująco, szkoda, że firma nie jest szerzej znana, przynajmniej w Polsce.

Podsumowanie:

Mimo uznawania przez wielu taśm magnetycznych za nośnik przestarzały i nieefektywny, cały czas mamy jeszcze do czynienia z dużymi środowiskami backupowymi ,opartymi właśnie na tej technologii. Taśmy są szczególnie popularne w organizacjach, które mają potrzeby czy wymogi składowania dużych ilości danych przez długie okresy czasu ( banki , firmy telekomunikacyjne itd...).
Dla tego rodzaju profilu przechowywanych danych, co do których dodatkowo jest bardzo mała szansa, że będziemy ich kiedykolwiek potrzbować( tzw: dane WORN - Write Once , Read Never) , taśma jest wciąż najbardziej ekonomicznym rozwiązanie. Dodatkowo, jeżeli wolumen danych jest naprawdę bardzo duży (dziesiątki petabajtów), nie ma innego spójnego rozwiązania, które mogłoby taką ilość informacji obsłużyć. 
Oczywiście technologia taśmowa i same biblioteki mają także wady. Po pierwsze są awarie, które powodują zatrzymanie pracy każdej biblioteki i to niezależnie od ilości redundantnych i wzajemnie dublujących się części - upuszczona przez robota taśma, stanowiąca przeszkodę na torze ruchu, powoduje unieruchomienie całego urządzenia, aż do czasu ręcznego usunięcia jej przez operatora. Uszkodzony czujnik w drzwiach błędnie sygnalizujący ich otwarcie, także uniemożliwia pracę biblioteki, która nie pozwoli na ruch robotom w takiej sytuacji. Duża liczba części mechanicznych, od których z jednej strony wymaga się wielkiej precyzji, a z drugiej pracy z dużymi prędkościami i przyśpieszeniami (np.: roboty, chwytaki itd...) także może stanowić potencjalne źródło awarii gdyż zużywają się one podczas eksploatacji.
Mimo tych ograniczeń backup na taśmy magnetyczne jeszcze długo będzie wykorzystywany w dużych organizacjach, a potężne biblioteki taśmowe dominowały w serwerowniach największych firm.



Artykuł ten inicjalnie pokazał się w czasopiśmie DataCenter Manager ( http://datacentermanager.pl/duze-biblioteki/ )


sobota, 16 kwietnia 2011

Deduplikacja - kopie idą precz! (Część 7 - reszta)

Po wpisach poświęconych w całości każdemu z "dużych" graczy w obszarze deduplikacji, chciałbym wspomnieć o innych produktach posiadających taką funkcjonalność.

FalconStore:

FalconStore to duży gracz w segmencie wirtualnych bibliotek taśmowych i oczywiste jest że ma w swojej ofercie także rozwiązania deduplikacyjne. FalconStore SIR (Single Instance Repository) jest "główką" deduplikacyną, którą dołącza się do FalconStoreVTLa, a która przeprowadza usuwanie kopii danych. Sam FS SIR nie posiada swojej przestrzeni dyskowej i wymogiem jest aby na jego back-endzie umieścić macierz zewnętrzną do przechowywania zdeduplikowanych danych. Jest to rozwiązanie łatwo skalowalne pod względem wydajności ponieważ poszczególne elementy SIRa łączą się, tworząc w maksymalnej konfiguracji 4 nodowy klaster (z redundancją N+1).
Oprócz SIRa, który jest "dodatkiem" do wirtualnej biblioteki, FalconStore oferuje także rozwiązania nie wymagające środowiska VTLowego. FalconStore FDS (File Deduplication System) jest linią produktów zarówno całkowicie softwarowych (SAK - Software Application Kit) jak i dedykowanych jednostek zintegrowanych z zasobami dyskowymi (Series 100/300/600). Urządzenia te mogą wymieniać dane z serwerami za pomocą protokołów NFS/CIFS a także wykorzystując OST firmy Symantec.

Symantec:

Dwa produkty firmy Symantec umożliwiają deduplikację danych -Backup Exec i NetBackup. Obydwie aplikacje mają bardzo podobną funkcjonalność, a ich głównym zadaniem jest wykonywanie i zarządzanie backupami. Identyczna jest również technologia deduplikacji jaką stosują i nosi ona nazwę: Veritas PureDisk.
Jeżeli chodzi o różnice między tym dwoma produktami, to są one inaczej pozycjonowane: Exec jest przeznaczony do małych i średnich przedsiębiorstw, natomiast NetBackup to produkt dla największych klientów klasy enterprise. Sama deduplikacja może zachodzić w różnych miejscach - preferowane jest jej wykonanie na kliencie, zysujemy wtedy oszczędość nie tylko miejsca ale i wykorzystania łącza, ale jeżeli powoduje to zbyt duże obciążenie CPU klienta, to zarówno Exec jak i NetBackup umożliwia przeniesienie tego procesu na serwer.
Symantec ma w swojej ofercie także dedykowany sprzęt (tzw: appliance) deduplikacyjny. Jest to serwer z działającym na nim oprogramowaniem do deduplikacji. Są to dwa produkty oznaczone jako NetBackup 5000 i 5200

Oracle:

Mówiąc o deduplikacji w rozwiązaniach Oracle najlepiej jest skupić się na możliwościach jakie w tym zakresie oferuje ZFS. Co prawda Oracle ma także swojego "czysto sprzętowego" deduplikatora nazwanego StorageTek VTL Prime, ale tak naprawdę jest to "rebrandowany" FalconStore VTL + SIR.
Co do ZFSa to jest to system bardzo ciekawy i pełen bardzo interesujących rozwiązań tak że w zasadzie tylko jemu można by było poświęcić cały duży wpis, ale w tym momencie skupimy się wyłącznie na funkcjonalności deduplikacji.
Deduplikacja w ZFSie odbywa się na poziomie bloku danych i jako skróty wykorzystuje generowane przez filesystem 256bitowe sumy kontrolne. Jest to mechanizm bardzo podobny do tego znanego z Netapp-owego WAFLa, gdzie również jako skróty zastosowano, już istniejące dla celów kontroli, checksumy.
Tym co odróżnia deduplikację ZFSową od Netapp-owej jest fakt, iż odbywa się ona w czasie rzeczywistym.
Dodatkowo dla ZFSa można uruchomić specjalny tryb "Weryfikacji", który podczas deduplikowania dodatkowo sprawdza czy nie występuje kolizja skrótów. Z kolejnych "fajnych" możliwości  ZFSa jest "szacowanie" ilości miejsca, jakie zostanie zaoszczędzone w wyniku włączenia deduplikacji - niestety nie miałem możliwości sprawdzić, jak takie szacowanie działa, ale gdyby ktoś był chętny niech zainteresuje się manualem do komendy zdb a szczególnie jej przełącznikiem -S.


CommVault:

CommVault to firma specjalizująca się w oprogramowaniu do backupu i archiwizacji. Jej flagowy produkt wykorzystujący deduplikację to Simpana (obecnie w wersji 9).
CommVault wykorzystuje specyficzną metodę wykonywania deduplikacji, którą można nazwać hybrydową - klient serwera backupowego dzieli dane na paczki oraz liczy z nich skróty, nie wykonuje jednak sprawdzania czy dane się powtarzają, są one jedynie kompresowane i wszystkie wysyłane do serwera. Dopiero na serwerze przeprowadzane jest samo deduplikowanie.
Kolejną dość nietypową własnością jaką ma Simpana to możliwość deduplikownia danych na taśmach magnetycznych. Dość ciężko znaleźć zastosowanie dla takiej funkcjonalności, ale jeżeli ktoś widzi taką potrzebę, to produkt CommVaultu mu ją zapewni.


NEC:

Firma NEC ma w swojej ofercie urządzenie HydraStore, które jest macierzą zbudowaną w technice RAIN ( Redundand Array of Independent Nodes) i posiada architekturę klastrową (skalowalną do 55 osobnych węzłów). Macierz ta posiada także mechanizmy deduplikacji wykonywanej "w locie" (inline)


ExaGrid:

ExaGrid jest firmą mocno nastawioną na produkty wykorzystujące deduplikację. Jej celem są głównie przedsiębiorstwa małej i średniej wielkości, choć widać, że chciała by także mocniej zaznaczyć swoją obecność w sektorze firm obsługujących korporacje klasy enterprise. Dedykowana seria urządzeń do dedplikacji firmy ExaGrid nosi nazwę EX. Mają one budowę klastrową (do 10 węzłów) i raczej niczym się nie wyróżnia od innych rozwiązań oferujących deduplikację na celu.


Quantum:

Seria deduplikatorów firmy Quantum to modele oznaczone jako DXi i obejmują sobą zarówno sektor małych (DXi4500), średnich (DXi6700) jak i dużych (DXi7500) przedsiębiorstw. Deduplikacja odbywa się na celu a deduplikator posiada funkcję "udawania" biblioteki taśmowej. Usuwanie kopii jest wykonane na poziomie bloku danych o zmiennej długości. Z przyjemnych dodatków można wspomnieć o module Advanced Reporting, który jest obecny w każdym modelu DXi (i bez dodatkowej licencji), a pozwala na monitorowanie stanu obecnego, historycznego oraz wyznaczania trendu bardzo wielu parametrów z zakresu capacity i wydajności.


Sepaton:

Mniej znana firma, która jednak ma dość ciekawe rozwiązania deduplikacyjne. Urządzenie które ma je zaimplementowane nosi nazwę S2100-ES2 i jest biblioteką taśmową, mogącą działać w klastrze i posiadającą możliwość deduplikowania danych. Interesujący jest sam poziom na którym deduplikacja się odbywa, ponieważ można go uznać za poziom bajtów - silnik deduplikacyjny obserwuje przychodzący do niego strumień danych (nie dzieli go na porcje) i w tym ciągłym strumieniu wyszukuje fragmenty, której już ma zeskładowane. Dodatkowo wykorzystywana jest tzw: content-aware deduplikacja, czyli samo urządzenie potrafi wykryć jakiego rodzaju dane są na niego przesyłane (jaka aplikacja backupowa jest używana) i odpowiednio do tego zmodyfikować swoje parametry pracy, tak aby zapewnić jak najlepszą i najwydajniejszą deduplikację. Sam mechanizm/silnik deduplikacji nosi nazwę DeltaStor.


CA:

Firma, o niezwykle długiej nazwie CA, zaznaczyła swoją obecność w obszarze deduplikacji, dołączając taką możliwość do swojego oprogramowania backupowego: CA ArcServe Backup. Deduplikacja odbywa się na serwerze (na celu) oraz jest wykonywana "w locie" (inline)


Asigra:

Na koniec rozwiązanie trochę egzotyczne: Asigra Cloud Backup. Jest to aplikacja backupowa, która po pierwsze składuje dane w chmurze (to nie jest jakiś ewenement, podobną funkcjonalność mają np: nowe wersje NetBackupa), a po drugie jest bezagentowa - dane z klientów są ściągne po wykonaniu pewnego skanowania poprzez sieć a następnie podłączenia się do danego zasobu i zeskładowania go. Dodatkowo dane są jeszcze deduplikowane przed zaciągnięciem tak, że obciążenie sieci mocno spada.





Na tym zakończy się cykl "deduplikacyjny". Początkowo planowałem 3 albo 4 wpisy, ale temat jest tak obszerny, że mimo 7 postów dalej nie jest wyczerpany.
Ufff. Dość o dyskach, kolejny wpis będzie o bibliotekach.