sobota, 15 maja 2010

"Automated tiering" - czyli być na odpowiednim poziomie ( cześć 2)

W poprzednim wpisie dowiedzieliśmy się czym jest "Automated Tiering", teraz czas na przybliżenie konkretnych implementacji tej technologii.

Oczywiście nie da się nawet ogólnie opisach wszystkich obecnych lub planowanych rozwiązań w tym zakresie dlatego postanowiłem skupić się na czterech najbardziej znanych ( choć oczywiście wybór ten był bardzo subiektywny):

EMC(FAST)
FAST czyli Fully Automated Storage Tiering to propozycja EMC która ma zostać wprowadzona jako opcja do maszyn z serii Symmetrix, Clariion oraz Cellera.
Administrator będzie miał możliwość definiowania różnego rodzaju "policy" z określonymi poziomami a nastęnie przypisywania konkretnych LUNów do tych "policy".
Czyli tworzymy policy np: "bazy danych OLTP" i w nim definiujemy Tier1 z dyskami SSD , Tier2 z dyskami FC 15k i Tier3 z dyskami FC 10k , ustawiamy że Tier1 ma mieć 10% , Tier2 30% a Tier 3 60% i gotowe. Teraz do danej polityki przydzielamy LUNy wystawione do systemów bazodanowych i macierz zajmie się optymalizacją wydajnościową. Oczywiście podobnych polityk możemy stworzyć więcej i poprzydzieleń do nich zasoby wedle naszych potrzeb.Poziomy (Tier-y) mogą nie tylo różnić się rodzajem dysków ale także ich ilością czy też strukturami RAID jakie na nich tworzymy. Można więć stworzyć górny poziom z RAIDem 10 i dolny na tych samych dyskach ale w RAIDzie 5 lub 6.
Ograniczeniem FASTa przynajmniej w wersji v1 jest to że przenoszenie danych odbywa się na poziomie LUNa.W świecie rzeczywistym nie ma sytuacji że wszystkie dane z obrębu file systemu czy LUNa są tak samo często używane, nawet na LUNie który "uśredniony" wydaje się bardzo zajęty znajdują się dane które odczytywane/zapisywane są relatywnie żadka. Niestety FAST nie potrafi (jeszcze) operować na poziomie bloku i dlatego wszystkie przesunięcia pomiędzy warstwami odbywają się całym LUNem.
Zapowiedziana jest już kolejna wersja systemu FAST ( v2 ) która będzie umożliwiała przenoszenie na poziomie bloku - jeżeli EMC nie będzie miało poślizgu to powinniśmy tą funkcjonalność zobaczyć w trzecim kwartale tego roku.


IBM(Easy Tier)
Rozwiązanie IBMa w zakresie "Automated Tieringu" nazywa się Easy Tier i zostało ostatnio zaimplementowane w najbardziej zaawansowanej macierzy tego producenta czyli DS8700.
Funkcjonalność ta nie wymaga wykupienia na nią licencji i jest dostępna dla wszystkich posiadających daną macierz i wersję mikrokodu R5.1. Oprócz tego IBM oferuje dodatek o nazwie "Storage Tier Advisor" który automatycznie przeanalizuje aktywność danych na naszej macierzy i pomoże optymalnie dobrać ich rozłożenie na warstwach ( tyle oficjalnie - nieoficjalnie mówi się że główną rolą "Doradcy" jest naciągnięcie nas na kupno dysków SSD , które w większości przypadków są według niego niezbędne dla zapewnienia naszej macierzy prawidłowego działania ).
"Easy Tier" bada dane podzielone na 1GB partie i wyznacza dla nich tzw "heat map" , czyli mapę miejsc aktywnych. Użytkownik następnie może takie "gorące" dane poprzemieszczać na wyższe TIERy lub też zostawić ta pracę samej macierzy. Oprócz przenoszenia danych pakietami po 1GB, można również dokonywać tieringu na poziomie całych LUNów.


Compellent(Data Progression)
Compellent ma rozwiązanie czysto softwarowe z dziedziny "Data Tieringu", na dodatek działające na poziomie bloków danych, co sprawia że oferta EMC i IBMa pod tym względem pozostaje nieco w tyle. Program nazywa się "Data Progression" i ( przynajmniej według samego Comellenta ) jest jedyną aplikacją która potrafi dokonywac inteligentnego przenoszenia danych na tak niskim poziomie.


3PAR(Adaptive Optimalization)
Firma 3PAR pozostaje tak jakby trochę poza głównymi liderami rynku storage (EMC, Netapp , IBM ), nie oznacza to jednak, że jej produkty są niewarte zainteresowania.
Jezeli chodzi o tematykę "Automated tiering" to produkt 3PARa nazywa się "Adaptive Optimalization" i został zaimplementowany w firmwarze macierzy z serii "InServ Storage Server".
Oprogramowanie te szczególnie dobrze współpracuje z dyskami SSD i według danych z testów ( przeprowadzanych przez 3PARa więc trzeba je traktowac z dużą dozą ostrożności ) pozwalają zaoszczędzić do 30% kosztów niż przy użyciu środowiska opartego na dyskach FC. Własnością odróżniająca rozwiązanie 3PARa od innych jest sposób pomiaru, które dane są najbardziej aktywne i powinny być przeniesione. U innych producentów zwykle zajmuje się tym osobny program/proces działający na macierzy, którego normalnym zadaniem jest pomiar i monitorowanie wydajności. W macierzach 3 PARa dane w LUNie podzielone są na jeszcze pewne mniejsze jednostki (Tzw: "regions") i do każdego regionu dodane są pewne metadane zawierające między innymi liczniki z ilością odwołań. Bazując na tym "Adaptive Optimalization" potrafi zidentyfikować i przenieść dane na odpowiednie dla nich miejsce.



Oprócz czterech wspomnianych rozwiązań istnieje także wiele innych. Wśród nich można np wspomnieć o firmie StoreSimple i jej kombajnie do deduplikacji, auto-tieringu i pracy w "chmurze" dla środowisk Windowsowych o nazwie: Hybrid Storage Appliance ( obecnie w fazie beta testów).
Googlując hasło "Automated tiering" czy przeglądając blogi i portale związane z tematyką storage znaleźć można jesze masę informacji o innych nie wspomnianych tutaj rozwiązaniach.


Do poczytania:
EMC - FAST - Take Action
EMC - Fast and the continuing virtualization of storage p1
EMC - Fast and the continuing virtualization of storage p2
EMC - Fast and the continuing virtualization of storage p3
IBM - Easy Tier
IBM - "Easy Tier" in DS8700
Compellent - Intelligent Tiered Storage
3PAR - Adaptive Optimization
3PAR - New operational efficiences
StoreSimple

niedziela, 2 maja 2010

"Automated tiering" - czyli być na odpowiednim poziomie ( cześć 1)

"Do more with less" - ta sentencja pojawia się ostatnio bardzo często gdy mówi się o oczekiwaniach względem działów IT. Łatwo powiedzieć, trudniej zrobić. Biznes nie tylko oczekuje więcej i lepiej ale jeszcze chcą to uzyskać mniejszymi kosztami.
Jeżeli ograniczymy się tylko do zagadnień związanych z pamięciami masowymi to jedną z technologii które ostatnio się pojawiły ( lub są zapowiedziane ), a która może pomóc w spełnieniu "żądań" biznesu jest tzw "Automated Tiering"

Na czym to polega?

Dwoma Współczynnikami które są najbardziej widoczne ze strony użytkownika końcowego to wydajność i stabilność. Aplikacja która chodzi szybko jest lepsza od tej która co chwile pokazuje nam "klepsydrę" czy komunikat "proszę czekać". Sprawa oczywista i nie potrzeba rozwodzić się nad nią długo. Podobnie jest ze stabilnością. Jeżeli program jest wciąż niedostępny z powodu awarii to wiadomo, że nie jest to stan normalny czy pożądany.
Teraz przełóżmy to na grunt storage. Zapewnienie stabilności to oczywiście z jednej strony odpowiednia konfiguracja macierzy na której znajdują się dane - grupy RAID z redundancją, dyski "hot spare" , z drugiej usuwanie SPOFów zarówno w samej macierzy jak i jej otoczeniu ( multipathing , podłaczenie do osobnych fabriców itd.). Temat bardzo szeroki , ale nie związany z motywem przewodnim tego wpisu czyli "Automatic tieringiem"

"Automatic tiering" dotyczy sprawy drugiej czyli wydajności. Wydajność możemy mierzyć w ilośći I/O na sekundę ( czyli ile operacji odczytu/zapisu danych może macierz przyjąć w ciągu jednej sekundy ). Host, a konkretniej aplikacje/bazy na nim działające zgłaszają ileś zapytań o dane lub wysyłają coś do zeskładowania na dyskach i cały problem polega na tym żeby ta ilość nie przekroczyła możliwości jakie ma nasza macierz.
Wydajność można "tuningować" na dwa sposoby, pierwszy to dobranie odpowiedniego typu grupy RAIDowej. Przykładowo RAID 1+0 jest szybszy niż RAID5, rozrzucenie danych po wielu dyskach również może przyśpieszyć samą macierz. Minus - im lepsze wydajność tym mniej pojemności. Przy 1+0 tracimy 50% przy RAID5 ( 2+1 ) - 33% , RAID5 ( 4 + 1 ) to 20% mniej miejsca do dyspozycji itd. NIc nie jest za darmo.
Druga sprawa to umieszczenie danych na szybszych dyskach. Obecnie najtańsze i największe są dyski SATA , klasy wyższa to dyski FC ( Fiber Channel ) o prędkościach obrotowych 10.000 i 15.000 RPM, a na samym szczycie mamy dyski SSD - bardzo szybkie i niestety bardzo drogie ( średnio cena 1GB jest 7 - 8 razy wyższa niż dla dysku FC).
Tradycyjne podejście polega na ocenie zapotrzebowania aplikacji na I/O ( najlepiej poprzez obserwację jej działania ) a potem przygotowanie dla niej miejsca na dyskach o odpowiedniej prędkości i w odpowiednio dobranej grupie RAIDowej. Takie działanie , jeżeli podparte jest solidną wcześniejszą analizą , może być całkiem zadowalające ale wciąż jest jeszcze dużo możliwości na poprawę tego procesu. Szczególnie jeżeli biznes chce od nas więcej, za mniej.

Automated Tiering

Idea Automatic Tieringu jest bardzo prosta. Macierz sama dokonuje pomiaru które dane są najczęściej używane i automatycznie przenosi je na odpowiednio szybkie dyski, analogicznie nieużywane fragmenty przenoszone są na nośnik wolniejszy. Dzięki temu możliwe jest bardziej optymalne rozmieszczenie aplikacji i poprawienie ogólnej wydajności ( czyli dostajemy więcej ) a jednocześnie dane mało używane rezydują na najtańszych dyskach ( wydajemy mniej ). Administrator zwykle ogranicza się do samego zdefiniowania warstw i ich procentowego udziału - reszta jest już na głowie samej macierzy i jej oprogramowania. Warstwy różnią się nie tylko typem dysków na jakich są zdefiniowane ( SSD , FC, SATA ) , administrator może także różnicować je wybierająć różne typy RAIDu dla niech ( np: Tier1 - RAID10 , Tier2 - RAID5 ).

Wyróżnia się dwie metody/typy używania automatycznego "tieringu". Pierwsza z nich to traktowanie go jako pamięci cache. Oczywiście współczesne systemy macierzowe mają swój własny bardzo szybki cache ale wykorzystanie górnego poziomu jako dodatkowej puli cache pozwoli na znaczne jej powiększenie. W metodzie tej dane są nie tyle przenoszone co kopiowane na najwyższą warstwę. Dodatkowo warstwa ta służy wyłącznie do odczytu, wszystkie zapisy i tak omijają dodatkowo stworzony "cache" i trafiają od razu na dyski wolniejsze ( robi się tak aby w wypadku uszkodzenia dysku najwyższej warstwy nie utradzić danych ). Oczywiście przy tak wykorzystanym "automatic tieringu" traci się cześć jego zalet. Po pierwsze pewne partie danych są zduplikowane na 2 warstswach czyli zajmują 2 razy więcej miejsca, niezbyt dobrze sprzyja to założeniu "do more for less", zamieniamy je raczej na "do more for more". Drugą wadą jest zachowanie przy systemach z dużą ilością zapisów, ponieważ idą one do warst niższych automatycznie tracimy cały zysk wydajnościowy zapewniany przez "automatic tiering".

Drugą metodą wykorzystania "Automated tieringu" jest traktowanie wyższych warstw jako normalną przestrzeń użytkową. Pewne dane, które są często używane zostają przez system umieszczone na wyższych warstwach i rezydują sobie tam do czasu aż macierz stwierdzi, że aktywność z nimi związana zmalała lub też pojawią się inne LUNy które wykorzystywane są jeszcze bardziej/częściej. Rozwiąznie takie niweluje obydwie wady jakie ma stosowanie wyższych warst jako pamięci cache. Retencja między warstwami trwa także dużo dłużej, dane na danym tierze mogą przebywać i tygodnie zanim zostaną przerzucone na inne miejsce, w pierwszej metodzie ten czas można liczyć w minutach czy godzinach ( inna sprawa czy da się tak szybko przerzucać duże ilości danych między warstwami i jaki to ma wpływ na pracę macierzy).

Kolejnym czynnikiem który pozwala nam podzielić "automated tiering" na różne podkategorie jest poziom na jakim on zachodzi. Ogólnie można wyróżnić trzy warianty: Na poziomie pojedyńczego LUNa, na poziomie pliku, na poziomie bloku danych. Najoptymalniejsza, ale też najtrudniejsza do zaimplementowania jest metoda optymalizowania na poziomie bloku danych, wtedy kontorla i sprawdzenie które fragmenty są najczęściej używane jest najefektywniejsza. Przenoszenie na poziomie LUNa musi opierać się na danych uśrednionych dla tego LUNa, które nie zawsze są reprezentatywne, pewne jego części ( nawet stanowiące większość) mogą być mało aktywne, a śrdenia jest podnoszona przez małe bloki danych które używane są ekstremalnie często. W wyniku takiego zachowania cały LUN, wraz z masą nieużywanych danych ląduje na najwyższych warstwach. Podobnie sytuacja wygląda przy "tieringu" na poziomie plików - ciężko w ten sposób oszacować aktywność poszczególnych części przy bazach danch.

Pytania i kontrowersje

"Automated tiering" to bardzo dobre i przyszłościowe rozwiązanie , jednak jest kilka kwesti i pytań na które ciężko jest w tej chwili udzielić wyczerpującej odpowiedzi.
Najważniejsze dwa według mnie, które mogą wskazywać na potencjalne problemy z jakimi wiąże się "tiering" to:

1. W jaki sposób "Automated Tiering" wpływa na replikcaję?
2. W jaki sposób "Automated Tiering" wpływa na odzysk danych z taśm?

Ad 1:
Przy replikacji musimy zarówno macierz źródłową jak i docelową utrzymać w synchronizacji, tak żeby dane wysłane z LUNów na macierzy A trafiły do odpowiadających im LUNów na macierzy B. Jeżeli konfiguracje macierzy A będzie się stale i nieprzewidywalnie zmieniała to w jaki sposób zostanie zapewnione że macierz B nadąży za tymi zmianami oczywiście cały czas przyjmując zreplikowane dane. Jak na razie nie znalazłem jeszcze odpowiedzi na to pytanie i pewnie pierwsze implementacje "Automated tieringu" nie będą wspierały replikacji.

Ad 2:
Co jeżeli backup danego file systemu/bazy został wykonany przy zupełnie innym rozłożeniu danych na warstwach? Co jeżeli macierz stosuje "Automated tiering" na poziomie bloków i dane są teraz porozrzucane w najróżnieszy sposób po wszystkich warstwach i dyskach? czy sekwencyjny zapis stanu poprzedniego obecny na taśmie pozwoli na skuteczny odzysk tych danych gdy struktura na która trzba ten zapis "zrzucić" jest zupełnie inna?

Na razie "Automated Tiering" jest w fazie bardzo wczesnego rozwoju i pewnie na pytania te nie ma jeszcze prostej i skutecznej odpowiedzi. Czas pokaże jak zostanie to rozwiązane.

To tyle na część 1, w części 2 omówimy obecne (lub zapowiedziane) rozwiązania "Automated Tieringu" - między innymi "FAST" od EMC i IBMowski "Easy Tier".


Do poczytania:

How hot is automated tiering
Issues with automated tiering
Making sense of Automated Tiering
Why automated tiering matters
Automated Tiering Methods
The importance of data migration in storage tiering
Introduction to Automated Tiering