Najmniejszy film swiata

Oto co IBM zrobil przy okazji prac nad pamieciami masowymi.

Trzy warstwy macierzy dyskowej

Kilka miesięcy temu uczestniczyłem w spotkaniu organizowanym przez IDC. Miało ono śniadaniową formule, a tematem przewodnim miały być oszczędności w IT. Okazało się, że mowa była tylko o rozwiązaniach cloud'owych sponsora tego posiłku  Słowo "oszczędności" padło raz i to w złym kontekście. Nie ukrywam, że bylem rozczarowany, czemu nawet dałem wyraz w końcowej dyskusji (od tej pory zaproszenia  na kolejne spotkania przestały przychodzić :)). Okazało się jednak, że ten czas nie był do końca stracony. A to za sprawa Grzegorza, managera z T-mobil. W swojej prezentacji przedstawił on koncepcję 3 warstw technologii:

- standaryzacja
- wirtualizacja
- automatyzacja

Za pomocą tej koncepcji zgrabnie wyjaśnił czym dla niego jest chmura prywatna. Z czasem dotarło do mnie, że ten sam schemat sprawdza się tez w odniesieniu do innych technologi IT, w tym do macierzy dyskowych.

Standaryzacja dotyczy tu sprzętu.  Macierz zbudowana jest z fizycznych elementów tj. szafy, kontrolery, interfejsy, półki dyskowe, dyski. Aktualnie producenci stosują standardowe komponenty.  Hardware macierzy można skompletować bez problemu w sklepie typu Komputronik. W roli kontrolerów występują tu bowiem zwykle serwery, wyposażone w powszechnie używane podzespoły. Dyski dostarcza jeden z 2 producentów -  Seagate albo Hitachi, a protokół łączący wszystko to dobrze znane SCSI w wersji serial - SAS. Sprawia to, że w zasadzie hardware w rozwiązaniach rożnych producentów jest bardzo podobny. Różnice wynikają ze sposobu wykorzystywania tego żelastwa  Odpowiada za to system operacyjny macierzy. To tutaj zaszyte są te wszystkie wspaniale możliwości obiecywane przez vendorów.

standardowy sprzęt

Już od dawna jedna z podstawowych funkcji jaka realizuje oprogramowanie macierzy dyskowej jest wirtualizacja. Dzięki niej zasoby logiczne udostępniane przez macierz nie są na sztywno związane ze sprzętem  W połączeniu z redundancja  wirtualizacja daje wysoką dostępność  Awaria dysku, portu czy nawet całego kontrolera nie oznacza utraty danych ani dostępu do nich. Aktualnie nawet najprostsze rozwiązania posiadają tą funkcjonalność  Kolejnym dobrodziejstwem wirtualizacji jest możliwość reorganizacji logicznych zasobów macierzy "w locie", bez odłączania ich od serwera.  Możemy zmieniać zasobom poziom RAID, przenosić je na inne warstwy dysków (7k, 10k, 15k, SSD). Pozwala to na dopasowywanie możliwości zasobu do zmieniających się wymagań aplikacji.

wirtualizacja

Sama wirtualizacja pozwala na wykonywanie takich operacji w sposób ręczny, na podstawie decyzji administratora. Od kilku lat powstają mechanizmy, które przekazują to zadanie macierzy dyskowej. To jest własnie  trzecia warstwa pamięci masowej -  automatyzacja. Nowoczesna macierz alokuje fizyczne zasoby na podstawie rzeczywistych potrzeb wynikających z charakteru operacji generowanych przez aplikacje. Co więcej  jeżeli zmieni się charakter tych operacji to macierz sama potrafi się do tego zaadoptować  Automatyzacja sprawia, że znikają w macierzy podziały na warstwy i grupy RAID. Staje się ona jedna przestrzenią na dane. Tworząc zasób logiczny nie musimy zastanawiać się, na których dyskach powinien on leżeć  Tworzymy go po prostu na macierzy. Zajmuje on dokładnie tyle miejsca ile rzeczywiście potrzebuje. Jego bloki lezą na dyskach zgodnie z realnym zapotrzebowaniem. Jest łatwiej, wydajniej i bardzo efektywnie.

automatyzacja

Na rynku są dostępne rożne rozwiązania. Cześć przeszła wszystkie etapy rozwoju pamięci masowej. Nowe funkcjonalności są w nich wdrażane zgodnie z wymaganiami stawianymi przez zmieniającą się rzeczywistość i są opcjonalne. Na drugim biegunie stoją macierze dyskowe tworzone przez nowe start-upy takie jak Pure Storage, czy Nimbus Data. Tutaj automatyzacja jest naturalnym trybem pracy.

Standaryzacja, wirtualizacja, automatyzacja - co dalej?

SCSI vs. NFS

Protokół SCSI nie został stworzony do transmisji w sieci. Jego właściwe miejsce to magistrala na sztywno połączona z komputerem. SCSI w wersji sieciowej to emulacja tej pierwotnej koncepcji. Emulacja czyli kłamstwo. Oszukanym w tej intrydze jest system operacyjny. Wydaje mu się, że ma dyski lokalne, a tymczasem są to wolumeny, gdzieś daleko w macierzy, na dyskach, z których korzystają też inne systemy. Nienaturalność tego układu podkreślają problemy z nomenklatura. W OS konfigurujemy WOLUMEN na DYSKU, który na macierzy jest WOLUMENEM utworzonym na wielu DYSKACH fizycznych.  Często używając tych samych słów mówimy o różnych rzeczach co prowadzi do nieuchronnych nieporozumień.

Oczywiście założenia były bardzo szczytne i do pewnego momentu odzwierciedlały potrzeby. Zaczęło się od kabli. Magistrala SCSI potrzebuje dużo miedzi. Kable były przez to grube i krótkie, a złącza awaryjne. Idealnym rozwiązaniem na ten problem okazało się zastąpienie miedzi lekkim i cienkim światłowodem. Na potrzeby tego szybkiego, szeregowego medium został stworzony protokół Fiber Channel. Zapakowano w jego ramki pakiety SCSI i powoli zaczęły nam rosnąć w serwerowniach sieci SAN. Dzięki temu mamy dziś scentralizowany storage.

Blokowy dostęp do danych, jaki realizuje protokół SCSI jest bardzo wydajny. Efektywnie wykorzystuje dostępne pasmo. Gorzej jest z zarządzaniem po stronie systemu operacyjnego. Niby wszystko da się zrobić, ale wymaga to czasu, wiedzy, doświadczenia i szczególnej ostrożności. Na przykład powiększanie filesystemu:

- powiększam wolumen na macierzy

- powiadamiam o tym OS - rescan scsi

- powiadamiam o tym volume manager
- powiększam wolumen logiczny w OS
- powiększam filesystem

Nie w każdym systemie jest to możliwe, nie zawsze można zrobić to 'w locie', a dodatkowo warto byłoby mieć na wszelki wypadek backup.

Przykład drugi - wykonanie i udostępnienie kopii danych z użyciem kopii migawkowej. Ta operacja to w sumie 11 czynności. Sporo pracy. A jak mamy to zrobić dla aplikacji, która jest na wielu systemach plików, wielu grupach dyskowych, które składają się z wielu dysków? A co jeśli takich kopii mamy kilkadziesiąt i codziennie musimy je tworzyć/odświeżać/przywracać do zapamiętanego stanu? To jest rzeczywistość wielu administratorów storage. Z jednej strony mają nowoczesne macierze dyskowe oferujące ogromne możliwości, a z drugiej systemy operacyjne używające protokołu, który ogranicza i komplikuje dostęp do danych.

Alternatywą dla blokowego SCSI są protokoły plikowe, takie jak NFS. Od początku zaprojektowany do pracy w sieci. Zapewnia naturalny dla OS dostęp do danych. System ma “świadomość”, że korzysta z zasobu sieciowego. Nie wymaga dedykowanej sieci SAN. Zapewnia spójność danych przy dostępie z wielu systemów. Jest łatwy w implementacji i zarządzaniu. Dla przykładu opisywana wcześniej operacja zwiększenia zasobu wykonywana jest w jednym prostym kroku na macierzy. Po stronie systemu operacyjnego nie są potrzebne żadne dodatkowe akcje - dba o to sam protokół.

Mimo tylu niewątpliwych zalet NFS nie jest chętnie wykorzystywany w dużych środowiskach np. na potrzeby baz danych. Wynika to z niskiej przepustowości sieci Ethernet, która jest głównym medium dla tego protokołu. Tak było przynajmniej do niedawna. Sieci klasy Data Centre, oparte na technologii 10,40,100 Gb Ethernet są coraz częściej budowane w naszych serwerowniach. Powoduje to, że główny argument na korzyść sieciowego SCSI, tj. szybkość nie jest już aktualny.

W takiej sytuacji NFS staje się coraz bardziej atrakcyjny. Ma on też swoje wady, ale w odróżnieniu od SCSI ciągle się zmienia i dostosowuje. Najnowsza wersja - parallel NFS - rozwiązuje większość problemów, które hamowały jego szerszą ekspansję. Zapowiadane do przyszły rok aktualizacje różnych systemów i macierzy NAS mają na liście zmian wsparcie dla pNFS'a. Może się okazać, że będzie to przełomowy czas dla adaptacji tego protokołu jako głównej metody dostępu do danych.

Implementacja SCSI w protokole sieciowym było najprostszym i najszybszym rozwiązaniem na problemy tamtych czasów. Wydaje się jednak, że ten pomysł nie przetrwa próby czasu. Jest to coraz większe ograniczenie dla rozwoju nowoczesnej infrastruktury IT, a przy okazji dużo kosztuje. Czy to oznacza koniec SAN?

SSD w array estimator

Estymator macierzy dyskowej to narzędzie, którego używam przy szacowaniu wielkości macierzy dyskowej.   Na podstawie wpisanych danych (oczekiwana ilość IOPS, pojemność, rodzaj napędów i charakterystyka operacji IO) wylicza wielkość macierzy. Tak naprawdę to podaje tylko ilość napędów, które są potrzebne do spełnienia podanych wymagań. Biorąc pod uwagę, że dysk jest najsłabszym elementem macierzy, to taka  informacja jest całkiem cenna. W praktyce dodaję jeszcze jakieś 10% więcej i staram się włożyć do środka jak najwięcej pamięci cache. Tak przygotowana konfiguracja powinna spełnić wymagania.

Skoro kilka dni temu dodałem SSD do kalkulatora IOPS to naturalne było, że w końcu "solidne napędy" pojawią się też w estymatorze. Całkiem szybko się z tym uporałem - no nie :)

http://wmarow.com/storage/goals.html

Zapraszam do testowania.

SSD w IOPS calculator

Co jakiś czas przypomni mi się mój kalkulator IOPS. Sprawdzę statystyki strony i listę rzeczy do poprawienia. Tak też zrobiłem dzisiaj rano. Okazuje się, że cały czas jest używany! Postanowiłem więc zrobić coś o czym myślałem już dawno - dodać SSD.

W przypadku HDD wydajność liczy się na podstawie fizycznych ograniczeń ruchomych elementów tych urządzeń. W SSD nic się nie rusza. Nie ma formuły do liczenia wydajności napędu SSD. Musimy zdać się na dane producenta (liczby z czapy!), wyniki rzetelnych testów (brak takowych), własne testy lub opinie zaufanych osób.

Jak już mamy te liczby to wpisujemy je w kalkulator i możemy liczyć wydajność macierzy SSD.

Zapraszam do testowania:

http://wmarow.com/storage/strcalc.html

Ile kosztuje zmarnowana przestrzeń dyskowa?

Dobre, współczesne macierze dyskowe pomagają zaoszczędzić sporo miejsca i co za tym idzie pieniędzy. Jest to możliwe głównie dzięki trzem technologiom: thin provisioning, wide striping i automated tiering. Bez nich musieliśmy z trudem i z miernymi rezultatami ręcznie alokować przestrzeń. Teraz macierz wykonuje to automatycznie. Manualne przydzialanie zasobów jest nadal możliwe, ale jest dosyć kosztowne. Trzeba bowiem zapłacić za terabajty, które nigdy nie zostaną użyte. Ukrywają się one w niezapełnionych filesystemach i datafilach. W klasycznym modelu zarządzania pamięcią masową tracimy też pojemność na rzecz szybkości - na potrzeby stosunkowo małych, ale mocno obciążających LUNów dedykowane są całe grupy RAID. Dodatkowo, aby uniknąć problemów z wydajnością macierz budujemy z szybkich, ale drogich i małych dysków co podnosi koszt rozwiązania. Jak to się przekłada na pieniądze? Przykład:


koszt 1TB w macierzy "klasycznej" - 20 000 PLN
koszt 1TB w macierzy "nowoczesnej" - 15 000 PLN

cena macierzy "klasycznej" 100 TB - 2 000 000 PLN
cana macierzy "nowoczesnej" 100 TB - 1 500 000 PLN

oszczędność - 500 000 PLN

niewykorzystana przestrzeń w macierzy "klasycznej" - 30% - 30 TB - 600 000 PLN
niewykorzystana przestrzeń w macierzy "nowoczesnej" - 10% - 10 TB - 150 000 PLN

oszczędność - 450 000 PLN

całkowina oszczędność 950 000 PLN


Ten przykład nie jest doskonały. Kwota będzie różna zależnie od wielu czynników. Warto ją sobie policzyć dla własnego środowiska.  Często oszczędności na "nowoczesnym" podejściu do zarządzania pamięcią masową to miliony złotych.

Ekonomia macierzy dyskowej cz. 2

"Jeżeli naszym celem jest budowa ekonomicznego środowiska storage to musimy efektywnie zarządzać przestrzenią macierzy dyskowej przez cały okres jej eksploatacji. Należy również mieć świadomość, że każde z rozwiązań trzeba prędzej czy później wymienić na nowe."

Tym razem kilka zdań o funkcjonalnościach.

http://storagefocus.pl/raporty/dyski-macierze-dyskowe/ekonomia-macierzy-dyskowej-cz2

(video) Pure Storage

Ekonomia macierzy dyskowej

Może się starzeję ..., albo za dużo myslę ? :) W każdym razie doszedłem ostatnio do wniosku, że moja największa wartość dla pracodawcy to umiejętność oszczędzania pieniędzy. Napisałem nawet o tym artykuł:

http://storagefocus.pl/raporty/dyski-macierze-dyskowe/ekonomia-macierzy-dyskowej-cz1

Pamiątkowa dyskietka

Podczas porządków w piwnicy znalazłem karton z przedmiotami, które zebrałem z biurka odchodząc z mojej pierwszej pracy. Między starymi dokumentami, wizytówkami, cartyfikatami i materiałami ze szkoleń z produktów, które już nie istnieją znalazłem dyskietkę.

Nie pamiętam jakie były motywy przywłaszczenie tego przedmiotu. Przyznaję, że to nie ładnie z mojej strony. Chcę jednak zachować tę pamiątkę z trzech powodów:

1. jest z roku, w którym zacząłem pracę w IT - 1997

2. Digital UNIX to mój pierwszy Unix

3. zawiera oprogramowanie do zarządzania kontrolerem RAID - czyli Storage!