NVMe. Czy to już pora?
Pamiętam, jak jeszcze całkiem niedawno, większość z nas dość sceptycznie podchodziła do koncepcji centrum przetwarzania danych z macierzami typu All Flash (AFA)? Ceny tych macierzy były wtedy na tyle wysokie, że tylko nielicznym innowatorom [o dyfuzji innowacji czytaj tutaj] udawało się uzasadnić ich zakup.
Technologia flash rozwinęła się i ustabilizowała, a ceny dysków SSD spadły. I wtedy do swoich portfeli sięgnęły grupy wczesnych naśladowców (early adopters) oraz wczesnej większości (early majority).
Gartner prognozuje, że do 2020 roku aż 77% macierzy na rynku, to będą macierze hybrydowe (HFA) oraz macierze All Flash (AFA).
Jeżeli skorelujemy krzywą dyfuzji innowacji (zaznaczoną kolorem pomarańczowym) z krzywą udziału w rynku tej innowacji (zaznaczoną kolorem zielonym) oraz założymy trafność prognoz Gartnera, to na tej podstawie można przyjąć, że aktualnie znajdujemy się gdzieś na środku tego wykresu.
W przypadku macierzy flash kilka znaczących czynników „popycha” powyższy proces dyfuzji innowacji do przodu. Oczywiście wspomniany już wcześniej spadek cen dysków flash jest jednym z nich. Ale oprócz niego ważne są również:
- możliwość obniżenia kosztów rozwiązania dzięki technologiom de-duplikacji i kompresji danych.
Znasz współczynnik redukcji danych w swoim środowisku? Wykorzystaj kompresję i/lub de-duplikację i po prostu kup mniejszą ilość dysków. Oczywiście ważne, aby przy tym nie ucierpiała wydajność Twoich aplikacji.
Co ciekawe, „efektem ubocznym” stosowania w macierzach dysków flash i mechanizmów redukcji danych, jest stopniowe wycofywanie dysków mechanicznych 15 tys. RPM z ofert producentów macierzy. Okazuje się bowiem, że konfiguracja macierzy z takimi dyskami często jest droższa od odpowiadającej jej konfiguracji HFA (z uwzględnieniem kompresji i de-duplikacji oraz biorąc pod uwagę pobór prądu i zajmowane miejsce w serwerowni). Dodatkowo konfiguracja z dyskami 15 tys. RPM nie jest w stanie dostarczyć takich parametrów SLO dla aplikacji (w tym przede wszystkim czasów odpowiedzi), jak jej odpowiednik z dyskami flash. W rezultacie przedsiębiorstwa coraz rzadziej decydują się na zakup macierzy z dyskami 15 tys. RPM.
- wydajność aplikacji.
Wspomniane już wcześniej czasy odpowiedzi gwarantowane na dyskach flash są nieporównywalnie niższe od tych, jakie można osiągnąć dla dysków mechanicznych. Lepsza wydajność to również możliwość większej konsolidacji środowisk oraz lepszej jakości obsługi mieszanych obciążeń w środowiskach wirtualnych.
Pojawienie się dysków flash zmieniło nieco perspektywę wymiarowania i estymowania wydajności w systemie IT. Najczęściej to właśnie dysk twardy był pierwszym wąskim gardłem takiego systemu. Wydajność procesorów, pamięci RAM i magistral rosła nieporównywalnie szybciej od wydajności dysków twardych, które jakby zatrzymały się pod tym względem „w średniowieczu”. Aż do pojawienia się dysku SSD. Wraz z rozpowszechnianiem się tych dysków natknęliśmy się jednak na kolejną przeszkodę. Otóż mamy bardzo szybki dysk SSD, ale jest on podłączony do już „wysłużonej” magistrali SCSI (aktualnie najczęściej – Serial Attached SCSI).
I tutaj nareszcie pojawia się w tej mojej historii nasz tytułowy standard NVMe.
Standard, który pozwala na dalszy rozwój i ewolucję macierzy AFA. Zaprojektowany i zbudowany specjalnie dla dysków flash. Następca poczciwego SCSI.
NVMe dzisiaj.
NVMe aktualnie najczęściej jest stosowane wewnątrz serwerów, jako przestrzeń typu Direct Attached Storage (DAS). W oparciu o tę przestrzeń budowane są rozwiązania hiperkonwergentne, na przykład te dla środowisk Software Defined Storage (SDS). Dyski NVMe są tam wykorzystywane między innymi jako przestrzeń cache takiego rozwiązania.
No dobrze. Wszystko fajnie, jeżeli mam aplikację, która skaluje się horyzontalnie i takie rozwiązanie hiperkonwergentne jest dla niej idealnym rozwiązaniem. Ale co w przypadku, gdy chcę zainstalować swoją aplikację w bardziej tradycyjnej infrastrukturze typu: serwer + sieć LAN i/lub SAN + macierz.
Już dzisiaj znajdziesz na rynku macierze w konfiguracjach z dyskami NVMe. Warto się jednak na chwilę zatrzymać i zastanowić nad fundamentem takiego rozwiązania. A fundamentem tutaj wcale nie jest macierz dyskowa, ale sieć, za pomocą której podłączymy tę macierz do naszych serwerów.
Trochę przypomina mi to sytuację jaką miałem jeszcze kilka dni temu u siebie w domu. Dlatego pozwolę sobie na krótką dygresję, aby lepiej zobrazować co mam na myśli, pisząc o fundamencie rozwiązania.
Od niedawna korzystam ze światłowodu, który dostarcza rewelacyjnych przepustowości (około 200-300 Mbps) oraz nieporównywalnie niskich opóźnień (2-4 ms pingi). Niestety dwa komputery stacjonarne moich synów znajdują się w takich pokojach, do których dociera bardzo słaby sygnał WiFi (a budując dom nie pomyślałem o rozprowadzeniu „skrętki”; wiem, aż wstyd się przyznać ). Bez modernizacji swojej wewnętrznej sieci jakość połączenia na tych dwóch komputerach była dramatycznie niska w porównaniu z możliwościami światłowodu (około 3 Mbps i nawet 20 ms pingi).
Przetestowałem transmitery sieciowe (dane transmitowane poprzez instalację elektryczną) – wzrost wydajności do około 7 Mbps. Sprawdziłem extendery WiFi – wzrost wydajności do około 15 Mbps. I w końcu zdecydowałem się „poprowadzić skrętkę” do tych dwóch pokoi.
Kilka godzin pracy i trochę wiercenia w ścianach w sobotę po południu. Rezultat?
- 50 metrów kabla Ethernet kategorii 5e i zarobienie końcówek – 100 zł.
- Silikony, szpachle, listwy do kabli – 80 zł.
- Miny chłopaków na widok wyniku jaki na koniec „wypluł” z siebie Speedtest – bezcenne .
Podobnie może wyglądać sytuacja z wdrożeniem NVMe jeżeli wybierzesz niewłaściwą sieć pomiędzy serwerem a macierzą.
Krótko o NVMe (Non Volatile Memory Express).
Powiedzieliśmy już sobie, że NVMe jest standardem zbudowanym dla dysków flash i ma zastąpić aktualnie wykorzystywany protokół transmisji danych do/z dysków. Co go w takim razie wyróżnia?
Po pierwsze, zrównoleglenie zadań, które w przypadku NVMe są wykonywane w 64 tys. kolejek (zamiast w jednej). A każda z tych kolejek może zawierać 64 tys. poleceń (zamiast 32), podzielonych na dwie grupy: administracyjne i IO. Każda kolejka może mieć zdefiniowany swój własny priorytet i jest albo kolejką typu submission albo kolejką typu completion. W tych pierwszych przekazywane są wiadomości od serwera do kontrolera, a w tych drugich - od kontrolera do serwera. Zrównoleglenie pracy pozwala na znaczne obniżenie opóźnień i zwiększenie wydajności aplikacji, które mogą zacząć korzystać jednocześnie z 64 tysięcy równoległych strumieni.
Po drugie, skoro o opóźnieniach mowa, już sam protokół NVMe charakteryzuje się o połowę niższymi ich wartościami (2,7 us) w porównaniu do swojego poprzednika.
Po trzecie, wykorzystanie wielordzeniowości w taki sposób, że kolejki i przerwania (których również jest więcej) można przydzielać do różnych rdzeni procesorów. Ponadto, ponieważ każdy rdzeń procesora może mieć przydzieloną na własność swoją kolejkę, dlatego nie ma potrzeby synchronizacji komend (w pojedynczej kolejce wymagane jest blokowanie i synchronizacja komend).
Aby jednak móc w pełni wykorzystać zalety protokołu NVMe, konieczne jest użycie zupełnie innej magistrali niż do tej pory. Dlatego dyski SSD NVMe podłączane są bezpośrednio do szyny PCIe. Protokołem komunikacyjnym na tej magistrali jest natomiast protokół NVMe.
Więcej informacji na temat samego standardu znajdziesz na przykład tutaj. My natomiast skupmy się na wspomnianej już wcześniej sieci.
Budujemy fundament (NVMe over Fabric).
Wykorzystywanie dysków NVMe wewnątrz serwerów, jako przestrzeń DAS (Direct Attached Storage), ogranicza skalowalność rozwiązania oraz często obniża jego niezawodność. Szczególnie na tle technologii replikacyjnych, do których przyzwyczaiły nas macierze dyskowe. Aby jednak w efektywny sposób korzystać z NVMe w macierzach dyskowych, musimy podłączyć je do serwerów za pomocą sieci, która pozwoli na odpowiednią jakość obsługi tego protokołu. I tu pojawia się na horyzoncie i pędzi nam z pomocą NVMe over Fabric (NVMe-oF). Ponieważ sieć ta będzie stanowiła fundament komunikacji serwera z dyskami, dlatego nie może to być „jakakolwiek” sieć. Musi być skalowalna. Musi zapewniać odpowiednią dostępność i pozwalać na centralne zarządzanie. A dodatkowo, aby nie być wąskim gardłem całego sytemu, musi również dostarczać odpowiednio niskich opóźnień.
To może wykorzystać istniejącą i powszechnie używaną sieć SAN, która ma opinię wydajnej, zawsze dostępnej i bezpiecznej oraz bardzo skalowalnej. Dzisiaj aż 70% macierzy AFA jest podłączonych właśnie do tej sieci. No i mamy w niej jeden i ten sam standard Fibre Channel spójny i implementowany już od kilku dekad zarówno w ekosystemie serwerów jak i macierzy dyskowych. Ale… Mimo, że NVMe nie jest zupełnie nowym standardem (jego pierwsza implementacja pojawiła się w 2011 roku), to w dalszym ciągu wprowadza sporo zamieszania wokół siebie, szczególnie w dyskusji na temat: „która sieć będzie dla niego najodpowiedniejsza”.
Z jednej strony stoi wcześniej wspomniany Fibre Channel w sieciach SAN. Z drugiej strony mamy cały świat Ethernetu ze standardami takimi jak RoCEv3, iWARP i Infiniband. Do tego pojawia nam się ciągle jeszcze żywy FCoE, który w przypadku wykorzystania pod NVMe wymaga jednak specjalistycznych sieci DCB (Data Center Bridging). I na koniec zostaje jeszcze wersja programowa, proponowana m.in. przez Facebooka, która sprowadza się do transportowania NVMe over TCP (iNVMe) z wszelkimi zaletami, ale również limitami, jakie ma TCP wraz z całym swoim stosem.
To teraz masz już mniej więcej pełen obraz protokołów, które walczą pomiędzy sobą o miano najlepszego dla NVMe-oF. Do wyboru, do koloru .
Powiedzieliśmy, że sieć NVMe over Fabric powinna być skalowalna i powinna charakteryzować się niskimi opóźnieniami. Dobrze byłoby również, aby stała za nią jakaś historia (doświadczenie i stabilność działania). Porównajmy w takim razie wszystkie wyżej wymienione protokoły w takich właśnie kategoriach.
Protokół | Opóźnienie | Skalowalność | Zasięg na rynku klasy enterprise |
RoCEv2 | Niskie | Duża | Pomijalny |
iWARP | Średnie | Duża | Pomijalny |
FCoE | Niskie | Średnia | Ograniczony |
iNVMe | Wysokie | Ograniczona | Żaden |
Fibre Channel | Niższe | Duża | Dominujący |
Infiniband | Najniższe | Ograniczona | Prawie żaden |
W tabeli wyróżniłem, wydaje się naturalnego i najlepszego kandydata.
Dlaczego Fibre Channel (FC)?
Jest to sieć zbudowana na potrzeby podłączania macierzy dyskowych i jest duże prawdopodobieństwo, że już teraz jest ona wykorzystywana w Twoim centrum przetwarzania. Charakteryzuje się niskimi opóźnieniami, a w przypadku zastosowania w niej protokołu NVMe opóźnienia te są jeszcze niższe (o ponad 50%). Jej skalowalność jest optymalizowana w taki sposób, aby udźwignąć bardzo duże obciążenia, a aktualne generacje FC pozwalają już dzisiaj na osiąganie przepustowości rzędu 32Gbps i 128Gbps (vs. 10Gbps, 25Gbps, 40Gbps i 100Gbps w przypadku sieci Ethernet). No i chyba najważniejsze. Nadal wykorzystujesz istniejącą sieć SAN oraz równolegle, stopniowo i w swoim tempie wdrażasz w tej samej sieci macierze NVMe.
To oczywiście ma sens i jest możliwe w przypadku, gdy Twoja istniejąca sieć SAN jest relatywnie nowa (i zapewnia odpowiednią przepustowość). Jeżeli tak nie jest, to możesz ją modernizować sukcesywnie, dodając do niej przełączniki najnowszych generacji do obsługi pamięci masowych NVMe, bez konieczności wymiany całej sieci. NVMe oraz SCSI mogą bowiem współistnieć w ramach tego samego serwera (a nawet tej samej karty HBA) oraz tym bardziej w tej samej sieci SAN. W ten sposób dynamicznie, w swoim tempie i również na żądanie, migrujesz aplikacje ze SCSI do NVMe.
A może jednak Ethernet?
Tylko po co implementować nowy rodzaj sieci dla macierzy dyskowych i nowe protokoły, które nie zostały sprawdzone w boju, skoro możesz wykorzystać istniejącą, pewną i stabilną sieć? W dzisiejszych centrach przetwarzania rzadko można spotkać sieci Ethernet szybsze niż 10Gbps i aby wykorzystać to medium transmisyjne dla NVMe musielibyśmy dokonać bardzo dużych zmian z wymianą sieci włącznie. Co więcej, w wielu centrach przetwarzania nie ma dedykowanej sieci Ethernet dla ruchu przeznaczonego dla pamięci masowych. A jeżeli będziesz się decydował na jej zbudowanie dla NVMe, musisz już na początku wiedzieć z jakiego protokołu skorzystać (na przykład dla FCoE musi to być sieć zbudowana w oparciu o specjalizowane przełączniki DCB).
Czego można się spodziewać po NVMe?
Zbudowałeś sieć, która pozwala na zagwarantowanie i dotrzymanie wymaganych dla aplikacji SLO. Masz macierze z dyskami NVMe, które replikują dane pomiędzy ośrodkami i gwarantują przy tym bardzo niskie czasy odpowiedzi (również z uwzględnieniem tej replikacji!!!).
Na co w takim przypadku mogą liczyć odbiorcy Twoich usług:
- szybsze transakcje i niskie opóźnienia w tradycyjnych, relacyjnych bazach danych i lepsze doświadczenie użytkownika aplikacji,
- większa ilość zapytań w bazach danych,
- większa gęstość VM w serwerach,
- lepsza obsługa mieszanych obciążeń w zwirtualizowanych środowiskach (konsolidacja),
- szybsze czasy przetwarzania w hurtowniach danych,
- szybsza eksploracja danych,
- szybsza analiza danych w dużych zbiorach danych w czasie rzeczywistym (analiza strumieni danych, IoT),
- szybsze przetwarzania w systemach plików takich jak HDFS oraz szybsze transakcje w bazach NoSQL.
A co, jeżeli zwykłe dyski flash okazują się być dla mnie w zupełności wystarczające?
Pozwól, że opowiem Ci o banku, który korzysta z macierzy AFA klasy midrange.
Bank ten używa technologii partycjonowania pamięci cache, aby oddzielić w tej pamięci zapytania IO o różnym charakterze, pochodzące z różnych serwerów (produkcja vs. development vs. test). Wszystkie dane są „pod spodem” przechowywane na wspólnej puli dyskowej z wbudowanym mechanizmem wide-striping (dane „rozrzucane” na wszystkie 32 dyski flash w macierzy). Na tej samej puli zabezpieczane są również repliki danych z drugiego ośrodka.
Macierz jest w stanie obsłużyć różnorodne obciążenia IO z prawdziwego środowiska bankowego, utrzymując przy tym bardzo stabilne i niskie czasy odpowiedzi na poziomie 1,8 ms (wliczając w to jedno-milisekundowe opóźnienie związane z replikacją danych pomiędzy ośrodkami).
Obszar danych produkcyjnych generuje 63 tys. IOPS. Obszar danych testowych i developerskich generuje 35 tys. IOPS.
Dla takiego obciążenia wspomniana macierz pracuje na poziomie:
- 30% obciążenia procesorów,
- 40% obciążenia dysków,
- 40% obciążenia portów wykorzystywanych do replikacji,
- 20% obciążenia portów wykorzystywanych dla hostów.
Jeżeli właściciele aplikacji, korzystających z powyższych macierzy są zadowoleni z pracy ich środowiska, to wdrażanie dla nich już teraz NVMe niekoniecznie musi być uzasadnione. A w takim przypadku mogę te aplikacje przesunąć w swojej roadmapie migracji do NVMe na późniejszy okres. Na przykład, gdy ceny technologii będą niższe i gdy te aplikacje rzeczywiście będą potrzebować jeszcze niższych czasów odpowiedzi.
Pamiętaj, za wdrożeniem NVMe powinny stać przede wszystkim koszty i ekonomika rozwiązania. Obniżanie opóźnień w aplikacji jest bardzo kuszącym argumentem. Warto go jednak skonfrontować z ceną jaka za tym stoi. Tym bardziej, jeżeli opóźnienia w okolicy 1 ms i poniżej, osiągane na standardowych dyskach flash są dla tej aplikacji w zupełności akceptowalne.
Dodaj komentarz