Spis treści:
Wydajne bazy danych, systemy analityczne czy platformy Big Data potrafią dojść do granicy możliwości nie dlatego, że brakuje im procesora albo pamięci RAM w wykorzystywanym sprzęcie IT. Często problem pojawia się znacznie niżej, w warstwie wejścia-wyjścia. Nawet bardzo szybka własna lub zewnętrzna serwerownia niewiele pomoże, jeśli dane znajdują się na zbyt wolnej pamięci masowej albo komunikacja z nią odbywa się przez źle zaprojektowaną sieć. NVMe-oF, czyli NVMe over Fabrics pozwala oddzielić warstwę obliczeniową od pamięci masowej i udostępniać zasoby na szybkich dyskach wielu serwerom za pośrednictwem sieci. Wykorzystywany do tego protokół może działać nie tylko przez lokalne PCIe, ale również z wykorzystaniem różnych mechanizmów transportowych – m.in. RDMA, TCP czy Fibre Channel.
Z artykułu dowiesz się, jak zaprojektować środowisko NVMe-oF dla baz danych i Big Data, dobrać sieć oraz pamięć masową, zapewnić wysoką dostępność i sprawdzić, gdzie w rzeczywistości znajduje się wąskie gardło.
NVMe-oF – charakterystyka technologii i podstawy jej działania
W klasycznym serwerze dysk NVMe jest urządzeniem lokalnym. System komunikuje się z nim przez PCIe, dzięki czemu aplikacja ma bezpośredni dostęp do bardzo szybkiej pamięci masowej. NVMe-oF przenosi podobny model działania poza pojedynczą maszynę. Host wysyła polecenia NVMe do kontrolera znajdującego się w systemie pamięci masowej, a pomiędzy nimi znajduje się sieć transportowa. Dzięki temu można rozdzielić serwery wykonujące obliczenia od tych przechowujących dane.
W praktyce daje to dwie ważne możliwości. Po pierwsze, można zwiększać moc obliczeniową bez przebudowy pamięci masowej. Po drugie, gdy potrzebna jest większa pojemność lub wydajność I/O, da się rozbudować warstwę dyskową bez ingerencji w każdy serwer.
Do wyboru są różne sposoby transportu. Jednym z nich jest NVMe/TCP – wykorzystuje standardową sieć IP i jest stosunkowo łatwe do wdrożenia. Drugi to NVMe/RDMA, który pozwala ograniczyć narzut związany z obsługą transmisji, dlatego lepiej pasuje do środowisk, w których liczą się bardzo małe opóźnienia.
Dlaczego NVMe-oF dobrze sprawdza się w bazach danych i Big Data?
Bazy danych potrafią generować ogromną liczbę operacji wejścia-wyjścia. Ich charakter jest przy tym bardzo różny. Jedna aplikacja wykonuje mnóstwo niewielkich, losowych operacji, inna przede wszystkim odczytuje duże bloki danych w sposób sekwencyjny. NVMe-oF pozwala zbudować warstwę pamięci masowej dopasowaną do takich różnych obciążeń i udostępnić ją wielu serwerom.
W środowiskach Big Data dochodzi jeszcze jeden czynnik – równoległość. Dane są często przetwarzane jednocześnie przez wiele hostów, więc pamięć masowa musi obsłużyć nie tylko dużą przepustowość, ale również znaczną liczbę operacji wykonywanych w jednym czasie. Należy jednak podkreślić, że samo NVMe-oF nie zapewni wysokiej wydajności – zależy ona także od innych czynników. Jeśli bowiem sieć będzie miała zbyt małą przepustowość, duże opóźnienia albo przeciążone przełączniki, szybkie nośniki danych nie będą w stanie w pełni wykorzystać swoich możliwości.
Dlatego taką infrastrukturę IT trzeba projektować kompleksowo, a więc od aplikacji aż do fizycznego nośnika. Znaczenie ma każdy tworzący ją element.
Najważniejsze elementy architektury NVMe-oF – serwery, pamięć masowa i sieć
Projekt takiej infrastruktury najlepiej podzielić na trzy warstwy:
- obliczeniową;
- pamięci masowej;
- sieciową.
Warstwę obliczeniową tworzą serwery dedykowane uruchamiające bazy danych, silniki analityczne czy zadania przetwarzania danych. Ich procesory i RAM trzeba dobrać do charakteru obciążenia. W przypadku baz danych odpowiednio duża pamięć operacyjna może zresztą ograniczyć liczbę odwołań do pamięci masowej, więc nie zawsze całe obciążenie trzeba przenosić na dyski.
Warstwa pamięci masowej to macierz NVMe-oF. Tutaj sama jej pojemność jest tylko jednym z istotnych parametrów. Równie ważne są liczba operacji I/O, przepustowość, opóźnienia oraz sposób rozłożenia obciążenia pomiędzy kontrolery, porty i nośniki.
W przypadku ostatniej warstwy, czyli sieci, najłatwiej jest popełnić kosztowny błąd. Nie wystarczy bowiem jedynie sprawdzić przepustowości pojedynczego portu i upewnić się, że spełnia oczekiwania. Trzeba policzyć, jaki ruch może wygenerować cała grupa serwerów i czy przełączniki oraz połączenia między nimi są w stanie go obsłużyć.
Sieć pod niskie opóźnienia – o czym trzeba pamiętać?
W NVMe-oF sieć jest częścią systemu pamięci masowej. Nie można więc potraktować jej jako zwykłego połączenia pomiędzy serwerem a macierzą. W środowisku nastawionym na niskie opóźnienia należy ograniczyć liczbę niepotrzebnych przeskoków pomiędzy urządzeniami, zapewnić odpowiednią przepustowość i unikać współdzielenia infrastruktury IT z ruchem, którego natężenia nie da się przewidzieć.
NVMe/TCP jest dobrym wyborem, gdy ważna jest prostota i wykorzystanie standardowej infrastruktury Ethernet. NVMe/RDMA ma więcej sensu tam, gdzie liczy się możliwie mały narzut komunikacyjny i bardzo niskie opóźnienia. Dobrym rozwiązaniem jest również rozdzielenie ruchu pamięci masowej od kopii zapasowych, zarządzania serwerami czy komunikacji aplikacyjnej. Dzięki temu chwilowy wzrost ruchu w jednym obszarze nie powinien od razu negatywnie odbijać się na operacjach I/O.
Dobór dysków NVMe i ochrona danych
Szybkość pojedynczego nośnika danych to dopiero jeden z wielu innych parametrów. W przypadku bazy danych znaczenie mają między innymi opóźnienia przy losowym odczycie i zapisie, liczba operacji I/O, trwałość zapisu oraz zachowanie dysku podczas długotrwałego obciążenia.
Do środowisk produkcyjnych warto wybierać nośniki przeznaczone do pracy serwerowej i dopasowane pod względem wytrzymałości zapisu do rzeczywistego obciążenia. Nie można też zapominać o temperaturze. Wysokowydajne NVMe potrafią generować sporo ciepła, a ich przegrzewanie może prowadzić do ograniczania wydajności.
Ochrona danych to osobna kwestia. Takie technologie, jak RAID, replikacja i kopie zapasowe rozwiązują różne związane z tym problemy. Z tego powodu nie powinny być traktowane jako wzajemne zamienniki. Odporność macierzy na awarię jednego dysku nie zabezpiecza bowiem przed przypadkowym usunięciem danych, błędem aplikacji czy ich zaszyfrowaniem w wyniku incydentu bezpieczeństwa.
Macierz NVMe-oF czy pamięć masowa definiowana programowo – co wybrać?
NVMe-oF może być zbudowane na gotowej, wyspecjalizowanej macierzy albo na rozwiązaniu programowym, w którym kilka serwerów wyposażonych w dyski NVMe tworzy rozproszoną warstwę pamięci masowej. Pierwsze z tych rozwiązań zwykle upraszcza wdrożenie i późniejsze zarządzanie całym systemem. Drugie daje większą elastyczność i pozwala wykorzystać standardowe serwery, ale wymaga dokładnego doboru oprogramowania, replikacji, rozwiązań z zakresu ochrony danych i procedur odtwarzania po awarii.
Jeśli najważniejsze są przewidywalne opóźnienia dla kilku bardzo wymagających baz danych, dedykowana macierz może być łatwiejsza do zoptymalizowania. Przy dużym środowisku analitycznym, które ma rosnąć poziomo, rozwiązanie programowe powinno z kolei dać więcej swobody. Dlatego najlepiej najpierw określić profil przewidywanego obciążenia systemu, a dopiero potem wybierać technologię, która zapewni największą możliwą wydajność.
Konfiguracja hostów, kontrolerów i przestrzeni nazw
W środowisku NVMe-oF host nawiązuje połączenie z kontrolerem pamięci masowej. Po stronie systemu operacyjnego pojawiają się przestrzenie nazw, czyli udostępniane zasoby blokowe. Najlepiej zacząć konfigurację od niewielkiego środowiska testowego. Najpierw trzeba sprawdzić pojedynczą ścieżkę i poprawność wykrywania przestrzeni nazw. Dopiero później warto włączać wiele ścieżek i automatyczne przełączanie.
W systemie Linux obsługę wielościeżkową zapewnia natywny mechanizm NVMe multipath. Pozwala on połączyć wiele ścieżek prowadzących do tej samej przestrzeni nazw w jedno urządzenie blokowe. Dostępne są różne sposoby wyboru ścieżki, między innymi zależne od NUMA, kolejności cyklicznej czy głębokości kolejki. Przed wdrożeniem trzeba sprawdzić zgodność wersji jądra, sterowników, oprogramowania kontrolera i narzędzi zarządzających.
Wysoka dostępność systemu i test przełączania po awarii
Wysoka dostępność powinna obejmować cały tor I/O. Awaria dysku to tylko jeden ze scenariuszy. Równie dobrze problem może pojawić się w porcie kontrolera, karcie sieciowej, przełączniku albo na całej ścieżce transmisyjnej. Z tego powodu host powinien mieć więcej niż jedną niezależną drogę do pamięci masowej. Po utracie jednej z nich ruch powinien zostać przełączony na pozostałą bez zatrzymania aplikacji.
I właśnie ten mechanizm trzeba sprawdzić w praktyce. Najlepiej w warunkach kontrolowanych wyłączać kolejne ścieżki i obserwować, czy operacje I/O nadal są wykonywane. Po przywróceniu połączenia należy natomiast sprawdzić, czy system wraca do prawidłowego stanu.
Strojenie wydajności całego środowiska IT
Na wydajność działania NVMe-oF wpływ mają m.in. takie elementy, jak:
- wykorzystywane aplikacje;
- rodzaj systemu operacyjnego;
- parametry procesora i pamięci RAM;
- możliwości sterownika, karty sieciowej, przełączników, kontrolerów i samych nośników danych.
W serwerach dedykowanych należy zwrócić uwagę między innymi na przypisanie procesów i przerwań do odpowiednich rdzeni CPU oraz relację pomiędzy kartą sieciową a pamięcią i procesorem w architekturze NUMA. Źle rozłożone obciążenie może zwiększać opóźnienia nawet wtedy, gdy sama sieć i pamięć masowa mają duży zapas wydajności.
Znaczenie mają też kolejki I/O, konfiguracja systemu plików i parametry aplikacji. Najrozsądniej ustalić wartości bazowe, zmienić jeden parametr i ponownie wykonać pomiar. Wtedy wiadomo, co faktycznie przyniosło poprawę.
W bazach danych warto również rozważyć oddzielenie plików danych, dzienników transakcyjnych i obszarów tymczasowych. Każdy z tych elementów może generować zupełnie inny rodzaj ruchu.
Testy I/O – jak znaleźć rzeczywiste wąskie gardło?
Testy wydajności powinny w możliwie największym stopniu odwzorowywać rzeczywiste obciążenie systemu. Wynik kilku milionów IOPS może wyglądać świetnie na wykresie, ale niewiele mówi, jeśli aplikacja wykonuje głównie duże, sekwencyjne odczyty. W drugą stronę również to działa – wysoka przepustowość nie gwarantuje dobrych wyników bazy danych wykonującej mnóstwo niewielkich operacji losowych.
Dlatego należy mierzyć co najmniej liczbę operacji I/O na sekundę, opóźnienie i przepustowość. Dobrze jest analizować także rozkład opóźnień. Bazowanie tylko na uśrednionych wartościach to duży błąd. Takie dane często maskują pojedyncze, ale bardzo wolne operacje, które z punktu widzenia wydajności działania aplikacji mogą mieć duże znaczenie.
Pomiary najlepiej wykonywać warstwowo. Najpierw sama pamięć masowa, potem połączenie NVMe-oF, system plików, a na końcu rzeczywista aplikacja. Jednocześnie trzeba obserwować CPU, kolejki I/O, interfejsy sieciowe, błędy transmisji i obciążenie kontrolerów.
Monitoring i telemetria NVMe-oF
Monitoring NVMe-oF nie powinien ograniczać się jedynie do sprawdzania, czy urządzenie jest dostępne. Warto obserwować również stan ścieżek NVMe, opóźnienia I/O, głębokość kolejek, błędy urządzeń i wykorzystanie interfejsów sieciowych. Po stronie macierzy istotne będą między innymi obciążenie kontrolerów, stan nośników, temperatury i opóźnienia.
Szczególnie przydatne jest zestawianie danych z kilku warstw. Jeśli jednocześnie rośnie opóźnienie I/O, wykorzystanie portu sieciowego i kolejka na kontrolerze, problem prawdopodobnie nie leży wyłącznie po stronie dysku. Taka korelacja pozwala szybciej znaleźć przyczynę pogorszenia wydajności. Pamiętaj, że w środowiskach bazodanowych czas potrzebny na znalezienie przyczyny problemu potrafi być równie ważny, jak sama wydajność sprzętu.
Własna serwerownia, kolokacja czy usługa zarządzana – które rozwiązanie wybrać?
Budowa własnego środowiska NVMe-oF wymaga odpowiedniej serwerowni, zasilania, chłodzenia, sieci oraz zespołu kompetentnych informatyków. Daje pełną kontrolę nad infrastrukturą IT, ale wiąże się z dużymi kosztami – zarówno na etapie wdrożenia, jak i późniejszego utrzymania. Własna serwerownia sprawdzi się przede wszystkim w organizacjach, które potrzebują pełnej kontroli nad infrastrukturą, mają duży budżet oraz własny zespół techniczny i mogą uzasadnić wysokie koszty utrzymania obiektu (np. w branży finansowej jest to ochrona bardzo wrażliwych danych).
Kolokacja pozwala zachować własne serwery i pamięć masową, a jednocześnie przenieść odpowiedzialność za przygotowanie i utrzymanie infrastruktury na zewnętrznego operatora. Ma to szczególne znaczenie wtedy, gdy środowisko wymaga dużej mocy, redundantnego zasilania i wydajnego chłodzenia, a budowa własnej serwerowni byłaby nieuzasadniona ekonomicznie. To rozwiązanie dobrze sprawdzi się wtedy, gdy firma chce samodzielnie kontrolować serwery i środowisko NVMe-oF, ale nie chce inwestować we własny obiekt, zasilanie, chłodzenie i zabezpieczenia.
Trzecią opcją jest model zarządzany, w którym część lub całość infrastruktury i administracji przejmuje dostawca. Upraszcza to obsługę, ale jednocześnie ogranicza możliwości samodzielnego konfigurowania środowiska. Usługa zarządzana będzie dobrym wyborem dla organizacji, które chcą korzystać z wydajnego środowiska NVMe-oF, ale nie mają własnych kompetencji lub zasobów potrzebnych do jego codziennej administracji i optymalizacji.
W przypadku NVMe-oF szczególnie ważna jest możliwość dobrania odpowiedniej infrastruktury serwerowej i sieciowej. Serwery dedykowane mogą stanowić warstwę obliczeniową, a konfiguracje wyposażone w NVMe są dobrym punktem wyjścia dla systemów wymagających szybkiego dostępu do danych. Sprint Data Center oferuje taki sprzęt przeznaczony do wymagających zastosowań, w tym pracy z bazami danych i analizą danych. Jako doświadczone datacenter zajmujemy się również kolokacją, oferując kompleksowy pakiet usług związanych z obsługą infrastruktury IT – zapraszamy do kontaktu i zapoznania się z ofertą.
FAQ – odpowiedzi na często zadawane pytania
Czy NVMe-oF zastępuje RAID?
Nie. NVMe-oF odpowiada za sposób udostępniania pamięci masowej przez sieć, natomiast RAID jest jednym z mechanizmów ochrony przed awarią nośników. Obie warstwy mogą oczywiście działać równocześnie.
Czy NVMe-oF ma sens przy jednym serwerze?
Technicznie tak, ale w praktyce największe korzyści pojawiają się przy rozdzieleniu serwerów obliczeniowych i pamięci masowej oraz przy korzystaniu z wielu hostów. Przy jednym serwerze lokalne NVMe może być po prostu prostszym rozwiązaniem.
Czy można uruchomić bazę danych bezpośrednio na przestrzeni NVMe-oF?
Tak. Udostępniona przestrzeń może być widoczna jako urządzenie blokowe, ale trzeba sprawdzić wymagania konkretnego silnika bazy danych, systemu plików i mechanizmów wysokiej dostępności.
Czy NVMe-oF nadaje się do kopii zapasowych?
Tak, ale sama wydajność nie powinna być tutaj głównym kryterium. Równie ważne są pojemność, retencja, koszt przechowywania, odseparowanie kopii od środowiska produkcyjnego i czas potrzebny na odtworzenie danych.