Ostatnio miałem okazję porozmawiać trochę z jednym z inżynierów IBMa, specjalizującym się w technologii storage ( dokładniej to macierzami z serii DS8000 ). W pewnym momencie padło pytanie o kierunek rozwoju macierzy i dowiedziałem się, że od pewnego czasu wszystko zmierza w kierunku coraz większego szajsu. A zaraz potem, że szajsu w pozytywnym tego słowa znaczeniu i jako przykład podamy został XIV.
XIV - Storage Reinvented:
XIV działa na dyskach SATA, czyli dużych, wolnych i tanich. Można powiedzieć taki low-end wydajnościowy na dodatek w przeciwieństwie do "elitarnych" dysków FC używany także w normalnych desktopach przez co staje się jakiś taki pospolity :D
To już wiemy czemu XIV to "szajs", bo używa w dysków SATA.
Czemu jednak pozytywny?
Ponieważ ma całkiem ciekawą architekturę i mechanizm działania, która w dużym stopniu kompensuje niedostatki wynikające z zastosowania napędów SATA. XIV jest siecią (gridem) zbudowanym z węzłów - w minimalnej konfiguracji 6, maksymalnej 15. Każdy węzeł to 12 dysków + kontroler + cache.
Idźmy dalej: Wszystkie dane są automatycznie dzielone i rozrzucane po całej macierzy. Tutaj administrator ma niewiele do powiedzenia, macierz wie lepiej i robi tzw: "wide stripping" - czyli dzieli dane na małe kawałeczki i rozrzuca po wszystkich dostępnych dyskach. Oczywiście dane są mirrorowane i chronione dyskami "hot spare" ale ten poziom zabezpieczeń także narzucany jest automatycznie.
Co zyskujemy dzięki takiemu "rozczłonkowaniu" danych?
1. wydajność:
Przy odczycie/zapisie danych pracuje cała macierz więc wydajność poszczególnych dysków się sumuje.
2. szybszy rebuild po awarii:
Nie ma synchronizowania całego wielkiego (1TB) dysku hot spare , tutaj każdy dysk w macierzy wykonuje swój "kawałek" rebuildu przez co znowu ich wydajność się sumuje i cały proces trwa ok 30minut
3. Mniejsze ryzyko występienia DDF ( Double Disk Failure ) :
Szansa na to że dwa dyski padną jednocześnie w macierzy jest minimalna jeżeli weźmie się pod uwagę jedynie wyliczenia związane z MTBF danych dysków. Niestety sytuacja w rzeczywistości nie jest tak różowa. Uprośćmy sytuację i rozważmy strukturę RAID1 + hot spare. Jeżeli jeden dysk przestaje pracować, dane są bezpieczne na drugim dysku - chwilę po występieniu awarii uaktywnia się hot-spare i zaczyna proces odbudowy czyli przekopiowania wszystkich danych z pozostałego w mirrorze napędu na dysk "hot spare". Dla dużych dysków odbudowa może trwać i kilkanaście godzin a polega na odczytywaniu danych sektor po sektorze i zapisywaniu ich na drugiej stronie. Operacja ta jest naprawdę bardzo intensywnym i długotrwałym procesem i szansa że podczas tego "wysiłku" drugi z dysków padnie rośnie wielokrotnie.
W XIVie ten problem nie występuje ponieważ nie ma "hot sparów" w tradycyjnym tego słowa znaczeniu. Nasz mirror danych też jest porozrzucany po całej macierzy a i miejsce "hot spare" jest zarezerwowane po małym kawałeczku na wszystkich dyskach. Podczas awarii dane z prędkością wszystkich pozostałych napędów są "rebuildowane" na wolne miejsca tworzące "hot spare". Proces jest o wiele szybszy ( do 30 min ) i o wiele mniej obciąża same dyski. W efekcie niwelujemy zagrożenie drugą awarią związaną z intensywnym I/O na dysku.
Tyle w skrócie o pozytywnych aspektach "szajsu" :D
Coś z życia:
Jeżeli chodzi o moje osobiste doświadczenia z pracą z XIVem to jak narazie są bardzo malutkie. Śmieszne jest GUI które wygląda bardziej jak interfejs z Mac OSa niż program do zarządzania macierzą. Wszytko bardzo ładnie świeci na zielono choć jak słyszałem nie znaczy to jeszcze, że wszystko pracuje sprawnie. Możliwe że któryś z dysków jest do wymiany ale macierz nie chce mnie stresować komunikatami o błędach.
W porównaniu do ECC konsoli czy NaviSphere od EMC , czy choćby Sunowskiego CAMa , to zarządzanie XIVem wygląda bardzo cukierkowo i dziecinnie.
A sama macierz? Jak to macierz - buczy, grzeje, mruga lampkami ;)
Do poczytania:
7-reasons-why-ibms-xiv-isnt-perfect
ddf-debunked-xiv-two-years-later
xiv-drive-management
calculating-the-output-of-wide-striping.
I to będzie tyle jak na pierwszy post techniczny w tym blogu.
Brak komentarzy:
Prześlij komentarz