"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
Brak komentarzy:
Prześlij komentarz