Kiedyś zajmowali szczyt łańcucha pokarmowego. Przez tysiące lat. I wtedy stało się coś nie do pomyślenia: niebo pokryło się chmurami i przestały istnieć. Po drugiej stronie świata miały miejsce wydarzenia, które zmieniły klimat: wzrosło zachmurzenie. Dinozaury stały się zbyt duże i zbyt wolne: ich próby przetrwania były skazane na niepowodzenie. Drapieżniki wierzchołkowe rządziły Ziemią przez 100 milionów lat, stając się większe i silniejsze. Ewoluowały w coś, co wydawało się idealną istotą na szczycie łańcucha pokarmowego, ale wszechświat nagle zmienił oblicze naszej planety.
Jak na ironię, to chmury zniszczyły dinozaury 66 milionów lat temu. W ten sam sposób dzisiejsze chmury niszczą klasyczne systemy przechowywania danych na szczycie łańcucha pokarmowego. W obu przypadkach problemem nie były same chmury, ale umiejętność przystosowania się do zmieniającego się świata. W przypadku dinozaurów wszystko wydarzyło się szybko: niszczycielski efekt chmur nastąpił w ciągu kilku dni lub tygodni od upadku meteorytu (lub erupcji wulkanu – wybór teorii należy do Ciebie). W przypadku klasycznych hurtowni danych proces ten trwa latami, ale jest oczywiście nieodwracalny.
Okres triasu: wiek wielkiego żelaza i pojawienie się zastosowań migracyjnych
Więc co się stało? Istniejący ekosystem obejmował systemy pamięci masowej klasy podstawowej i średniej, systemy klasy korporacyjnej oraz pamięć masową podłączaną bezpośrednio (DAS). Kategorie te zostały określone przez analityków i miały własne wielkości rynkowe, wskaźniki kosztów, niezawodności, wydajności i skalowalności. I wtedy wydarzyło się coś dziwnego.
Pojawienie się maszyn wirtualnych oznaczało, że na jednym serwerze można było jednocześnie uruchamiać wiele aplikacji, prawdopodobnie u wielu właścicieli – zmiana, która natychmiast postawiła pod znakiem zapytania przyszłość bezpośrednio podłączanej pamięci masowej. Następnie właściciele największych infrastruktur hiperskalowych (hiperskalerów): Facebook, Google, eBay itp., zmęczeni płaceniem ogromnych sum pieniędzy za systemy pamięci masowej, opracowali własne aplikacje, które zamiast dużych „sprzętowych” pamięci masowej zapewniały dostępność danych na zwykłych serwerach systemy. Następnie Amazon wprowadził na rynek coś dziwnego o nazwie Simple Storage Service, czyli S3. Nie blok, nie plik, ale coś zasadniczo nowego: zakup systemu stał się niemożliwy, można było kupić jedynie usługę. Zaczekaj chwilę, co to za jasne światło widoczne na niebie? Kolejna asteroida?
Jura: era „wystarczająco dobrych saurów”
W fazę rozwoju pamięci masowej weszliśmy z ideologią „wystarczająco dobre”. Klienci pamięci masowych, zauważając, co zrobili hiperskalownicy, zaczęli kwestionować słuszność dziesięcio-, a nawet stukrotności dodatkowych kosztów w stosunku do sprzętu, jakie płacili za swoje korporacyjne systemy pamięci masowej. Macierze średniego poziomu zaczęły zdobywać udział w rynku w porównaniu z systemami najwyższej klasy. Produkty takie jak wykazał szybki wzrost. EMC Symmetrix, niegdyś dominująca macierz klasy korporacyjnej, nadal zajmowała pewne terytorium, ale szybko się zmniejszało. Wielu użytkowników rozpoczęło migrację swoich danych do AWS.
Z drugiej strony innowatorzy pamięci masowej zaczęli zapożyczać pomysły od hiperskalerów, wykorzystując technologie rozproszonych systemów skalowalnych poziomo – ideologia przeciwna skalowaniu wertykalnemu. Oczekuje się, że nowe oprogramowanie do przechowywania danych będzie mogło działać na zwykłych serwerach, podobnie jak hiperskalery. Nigdy więcej 10-100-krotności kosztu samego sprzętu. Teoretycznie możesz skorzystać z dowolnego serwera - wybór zależy od Twoich preferencji. Rozpoczęła się era przechowywania definiowanego programowo (SDS): chmury zasłoniły niebo, temperatura spadła, a populacja drapieżników wierzchołkowych zaczęła spadać.
Okres kredowy: początek ewolucji systemów przechowywania definiowanych programowo
Początki pamięci masowej definiowanej programowo były burzliwe. Obiecano wiele, ale niewiele zrealizowano. Jednocześnie nastąpił ważny zwrot technologiczny: pamięć flash stała się nowoczesną alternatywą dla wirującej rdzy (HDD). Był to okres wielu start-upów w dziedzinie pamięci masowej i łatwych w obsłudze środków kapitału wysokiego ryzyka. Wszystko byłoby wspaniale, gdyby nie jeden problem: przechowywanie danych wymaga poważnego przemyślenia. Okazuje się, że klienci lubią swoje dane. Jeśli stracą do nich dostęp lub w terabajtach danych zostanie znalezionych kilka uszkodzonych fragmentów, bardzo się martwią. Większość startupów nie przetrwała. Klienci otrzymali fajną funkcjonalność, ale nie wszystko było dobrze z podstawowymi narzędziami. Zły przepis.
Okres kenozoiczny: dominują masywy magazynowe
Niewiele osób mówi o tym, co stało się później, bo nie jest to zbyt interesujące – klienci nadal kupują te same, klasyczne macierze pamięci masowej. Oczywiście ci, którzy przenieśli swoje aplikacje do chmur, przenieśli tam także swoje dane. Jednak dla zdecydowanej większości klientów, którzy nie chcą całkowicie przejść na chmurę, lub w ogóle nie chcą się na nią przełączać, ten sam Hewlett Packard Enterprise w dalszym ciągu oferował klasyczne macierze.
Mamy rok 2019, więc dlaczego nadal istnieje wielomiliardowy biznes pamięci masowej oparty na technologii Y2K? Ponieważ działają! Mówiąc najprościej, wymagania aplikacji o znaczeniu krytycznym nie były realizowane przez produkty tworzone na fali szumu. Produkty takie jak HPE 3PAR pozostały najlepszymi opcjami dla klientów korporacyjnych, a nowa ewolucja architektury HPE 3PAR – to tylko potwierdza.
Z kolei możliwości systemów pamięci masowej definiowanych programowo były doskonałe: skalowalność pozioma, wykorzystanie standardowych serwerów... Ale ceną za to była: niestabilna dostępność, nieprzewidywalna wydajność i specyficzne zasady skalowalności.
Złożoność wymagań klientów polega na tym, że nigdy nie są one prostsze. Nikt nie powie, że utrata integralności danych lub wydłużone przestoje są akceptowalne. Dlatego tak ważna dla systemów pamięci masowej jest architektura, która jednocześnie spełnia wymagania nowoczesnych, szybko rozwijających się centrów danych, a w poszukiwaniu kompromisu nie jest pozbawiona kluczowych cech systemów pamięci masowej klasy Enterprise.
Okres trzeciorzędowy: pojawienie się nowych form życia
Spróbujmy dowiedzieć się, jak jedna z nowicjuszek na rynku pamięci masowej – Datera – poradziła sobie z tak trudną mieszanką historycznie ustalonych i nowych wymagań wobec systemów przechowywania. Przede wszystkim poprzez wdrożenie architektury skupionej na rozwiązaniu opisanego powyżej dylematu. Nie da się zmodyfikować dotychczasowej architektury, aby sprostać wyzwaniom nowoczesnego centrum danych, tak jak nie da się zmodyfikować przeciętnej architektury pamięci masowej definiowanej programowo, aby spełniała wymagania systemów klasy korporacyjnej: dinozaury nie stały się ssakami ze względu na temperaturę upuszczony.
Stworzenie rozwiązania spełniającego wymagania dotyczące pamięci masowej klasy korporacyjnej, przy jednoczesnym pełnym wykorzystaniu elastyczności nowoczesnego centrum danych, nie jest łatwym zadaniem, ale właśnie to postanowiła zrobić firma Datera. Specjaliści firmy Datera pracowali nad tym od pięciu lat i znaleźli przepis na „ugotowanie” pamięci masowej klasy korporacyjnej definiowanej programowo.
Główną trudnością, jaką napotkała Datera, było to, że musiała użyć operatora logicznego „AND” zamiast znacznie prostszego „OR”. Stała dostępność ORAZ przewidywalna wydajność ORAZ skalowalność architektury ORAZ orkiestracja w formie kodu ORAZ ustandaryzowany sprzęt ORAZ egzekwowanie zasad ORAZ elastyczność ORAZ zarządzanie oparte na analizach, bezpieczeństwo „ORAZ”, integracja „ORAZ” z otwartymi ekosystemami. Operator logiczny „AND” jest o jeden znak dłuższy niż „OR” - to jest główna różnica.
Okres czwartorzędowy: nowoczesne centra danych i nagła zmiana klimatu determinują rozwój systemów pamięci masowej definiowanych programowo
Jak więc Datera stworzyła architekturę, która spełnia wymagania tradycyjnej pamięci masowej dla przedsiębiorstw, a jednocześnie spełnia wymagania nowoczesnego centrum danych? Wszystko znowu sprowadza się do tego nieznośnego operatora „AND”.
Nie było sensu zajmować się indywidualnymi wymaganiami jeden po drugim. Suma takich elementów nie stanie się jedną całością. Jak w każdym złożonym systemie, ważne było dokładne rozważenie całego kompleksu wyważonych kompromisów. Podczas opracowywania specjaliści Datera kierowali się trzema głównymi zasadami:
- zarządzanie specyficzne dla aplikacji;
- ujednolicony mechanizm zapewniający elastyczność danych;
- wysoka wydajność dzięki zmniejszonym kosztom ogólnym.
Cechą wspólną tych zasad jest prostota. Z łatwością zarządzaj swoim systemem, zarządzaj danymi za pomocą jednego, eleganckiego silnika i zapewniaj przewidywalną (i wysoką) wydajność przy jednoczesnej redukcji kosztów. Dlaczego prostota jest tak ważna? Doświadczeni profesjonaliści w świecie pamięci masowej wiedzą, że spełnienia wymagań współczesnych dynamicznych centrów danych dotyczących pamięci masowej nie da się osiągnąć jedynie poprzez szczegółowe zarządzanie, wiele narzędzi do zarządzania danymi i hiperoptymalizację w celu zwiększenia wydajności. Kompleks takich technik jest nam już znany jako system przechowywania dinozaurów.
Znajomość tych zasad dobrze się przydała Daterze. Opracowana przez nich architektura charakteryzuje się z jednej strony dostępnością, wydajnością i skalowalnością nowoczesnego systemu pamięci masowej klasy korporacyjnej, a z drugiej strony elastycznością i szybkością niezbędną w nowoczesnym centrum danych definiowanym programowo.
Dostępność Datery w Rosji
Datera jest globalnym partnerem technologicznym firmy Hewlett Packard Enterprise. Produkty Datera są testowane pod kątem kompatybilności i wydajności z różnymi modelami serwerów .
Więcej informacji na temat architektury Datera można znaleźć na stronie 31 Październik.
Źródło: www.habr.com