Flexible Data Placement w NVMe: jak SSD pozwala hostowi grupować zapisy, żeby ograniczyć write amplification i pracę garbage collectora?

Problem z SSD nie zaczyna się wtedy, gdy host zapisuje dużo danych. Zaczyna się wtedy, gdy kontroler musi przenosić dane, których host w ogóle nie kazał mu przenosić. Przy mieszance plików o różnym czasie życia — logów, cache’u, SSTables, danych tymczasowych i długo żyjących rekordów — strony NAND szybko układają się w bloki zawierające jednocześnie dane aktualne i nieważne. Żeby taki blok skasować, kontroler musi najpierw skopiować pozostałe poprawne strony gdzie indziej. Jeden zapis hosta potrafi więc wygenerować więcej niż jeden zapis do NAND.

To właśnie write amplification. Jeśli host zapisze 1 TB, a SSD fizycznie zapisze 2 TB do pamięci flash, WAF wynosi 2. Koszt nie jest abstrakcyjny: rośnie zużycie NAND, kontroler wykonuje więcej pracy, zwiększa się zapotrzebowanie na przepustowość wewnętrzną, a przy mocnym obciążeniu pojawiają się skoki opóźnień związane z garbage collection.

Flexible Data Placement, czyli FDP, zmienia podział odpowiedzialności. Host nie przejmuje pełnego zarządzania pamięcią flash, ale przekazuje SSD informację, które zapisy powinny trafiać razem. Kontroler nadal zarządza NAND, mapowaniem LBA i odzyskiwaniem przestrzeni, lecz dostaje znacznie lepszą wskazówkę niż w klasycznym modelu blokowego SSD.

FDP nie mówi SSD „gdzie zapisać sektor”. Mówi, które dane powinny starzeć się razem

Najłatwiej źle zrozumieć FDP jako mechanizm ręcznego wybierania fizycznego miejsca w NAND. Tak nie działa.

Host nadal zapisuje na zwykłe adresy LBA. Aplikacja może nadpisywać dane, wykonywać losowe I/O i korzystać z urządzenia w sposób znacznie bardziej zbliżony do klasycznego NVMe niż w przypadku Zoned Namespaces. FDP dodaje natomiast do zapisu informację o Data Placement.

Najważniejsze pojęcia są cztery:

• Reclaim Unit, RU – jednostka danych, którą kontroler może odzyskiwać jako całość; praktycznie jest to obszar istotny z punktu widzenia garbage collection;

• Reclaim Unit Handle, RUH – uchwyt pozwalający kierować dane do określonego strumienia jednostek odzyskiwania;

• Reclaim Group, RG – grupa zawierająca odpowiadające sobie Reclaim Units;

• Placement Identifier, PID – identyfikator używany przez host przy zapisie. Łączy wskazanie Reclaim Group Identifier z Placement Handle.

Jest tu istotny szczegół. Host operuje Placement Handle, natomiast namespace ma zdefiniowane powiązanie Placement Handle → Reclaim Unit Handle. To mapowanie może zostać określone podczas tworzenia namespace’u. Dopiero kontroler, korzystając z tego mapowania i wskazanego Reclaim Group, ustala konkretny Reclaim Unit dla zapisu.

W praktyce logika po stronie aplikacji nie powinna więc brzmieć: „ten rekord zapisz do fizycznego bloku 742”. Powinna brzmieć raczej:

„Dane z tej klasy mają podobny czas życia, więc oznaczaj je tym samym Placement Identifierem”.

Przykład dobrze pokazuje różnicę. Serwer przechowuje jednocześnie:

• cache ważny średnio przez kilka minut,

• logi rotowane co godzinę,

• pliki SST z bazy LSM wymieniane podczas compaction,

• dane użytkownika pozostające na dysku miesiącami.

Na zwykłym SSD firmware może wymieszać te zapisy w tych samych jednostkach odzyskiwania. Po usunięciu godzinnych logów nadal pozostają tam strony należące do wielomiesięcznych danych. Garbage collector nie może po prostu wymazać całej jednostki. Musi skopiować ocalałe strony.

Przy FDP host może rozdzielić te klasy. Krótko żyjące dane trafiają razem, długo żyjące razem, a intensywnie nadpisywany cache nie zanieczyszcza jednostek zawierających chłodne dane.

Kiedy większość danych w Reclaim Unit unieważnia się w podobnym czasie, kontroler może odzyskać przestrzeń przy znacznie mniejszej liczbie relokacji. To jest faktyczna przewaga FDP. Nie chodzi o szybsze wykonanie pojedynczego polecenia Write, tylko o zmniejszenie ilości przyszłej pracy wykonywanej wewnątrz SSD.

Z tego powodu podstawowym kryterium grupowania nie powinien być format pliku, katalog czy nazwa aplikacji. Najlepiej działa podobny cykl życia danych.

Dobra klasyfikacja może wyglądać tak:

• PID A – bardzo krótki TTL i cache;

• PID B – logi oraz dane tymczasowe;

• PID C – aktywnie modyfikowane dane robocze;

• PID D – dane chłodne lub praktycznie niezmienne.

Z kolei utworzenie osobnego PID dla każdego typu obiektu tylko dlatego, że jest dostępny, zwykle nie daje przewagi. FDP nie nagradza liczby klas. Nagradza trafne rozdzielenie danych o różnym profilu unieważniania.

Mniejszy garbage collection nie jest automatyczny: zła klasyfikacja potrafi zmarnować cały efekt FDP

Idealnym punktem odniesienia jest WAF równy 1: SSD zapisuje do flash mniej więcej tyle danych, ile otrzymał od hosta. FDP został zaprojektowany tak, aby umożliwiać zbliżenie się do takiego scenariusza dla odpowiednich workloadów, ale nie należy wpisywać „WAF=1” do projektu jako gwarantowanego parametru.

Kontroler wciąż ma własny firmware, własne zasady zarządzania pamięcią, over-provisioning i ograniczenia wynikające z geometrii NAND. FDP pozostaje interfejsem współpracy hosta z kontrolerem, a nie przejęciem FTL przez aplikację.

To ważne, ponieważ obecność obsługi FDP na etykiecie SSD nie oznacza jeszcze niskiego write amplification.

Najczęstszy błąd wygląda banalnie: aplikacja ma trzy klasy danych, ale klasyfikacja odpowiada ich funkcji biznesowej, a nie czasowi życia.

Załóżmy, że do jednego PID trafiają:

• rekordy usuwane po 10 minutach,

• rekordy przechowywane przez 30 dni,

• dane permanentne.

Dla garbage collectora nadal jest to fatalna mieszanka. Gdy pierwsza grupa zniknie, w Reclaim Unit zostaną dwie pozostałe. Kontroler nadal będzie musiał relokować poprawne strony przed kasowaniem.

Drugi problem to nierównomierne obciążenie RUH. Samo utworzenie kilku uchwytów nie zapewnia izolacji zachowania firmware’u. Badania wykonywane na komercyjnych SSD pokazały również przypadki „noisy RUH”, w których intensywne unieważnianie danych przypisanych do jednego uchwytu wpływało na write amplification obserwowany dla innych. FDP daje hostowi więcej kontroli, ale nie odsłania całej polityki FTL.

Dlatego wdrożenie powinno być mierzone, nie oceniane po samym włączeniu funkcji.

W NVMe dostępny jest FDP Statistics Log Page. Zawiera między innymi liczniki:

• Host Bytes with Metadata Written – HBMW,

• Media Bytes with Metadata Written – MBMW,

• Media Bytes Erased – MBE.

Relacja ilości danych zapisanych do medium do danych zapisanych przez hosta pozwala obserwować faktyczny write amplification. Dodatkowo ilość kasowanych danych pokazuje, jak intensywnie pracuje mechanizm odzyskiwania przestrzeni.

W praktycznym teście najpierw wykonuję workload kontrolny bez świadomego rozdzielania danych, a potem dokładnie ten sam workload z FDP. Trzeba zachować ten sam rozmiar datasetu, poziom zapełnienia SSD, proporcję odczytów do zapisów oraz czas testu. Porównywanie świeżo wyczyszczonego nośnika z dyskiem pracującym przy 85–90% zapełnienia jest bezwartościowe — garbage collector działa w zupełnie innych warunkach.

Szczególnie interesują trzy wartości:

1. WAF.
Jeżeli po włączeniu FDP spada wyraźnie, klasyfikacja rzeczywiście pomaga kontrolerowi.

2. Opóźnienia ogona, np. p99 i p99.9.
Średnia latencja może prawie się nie zmienić, podczas gdy ograniczenie pracy GC usuwa najgorsze skoki opóźnień. Dla baz danych i cache’u właśnie ten efekt może być ważniejszy niż średni IOPS.

3. Zachowanie po długim okresie zapisu.
Krótki benchmark na pustym SSD często pokazuje świetne liczby również bez FDP. Sensowny test musi doprowadzić urządzenie do stanu ustalonego, w którym nadpisywanie i reclaim faktycznie występują.

Są też sytuacje, w których wdrażanie FDP ma niski priorytet. Jeśli workload jest prawie wyłącznie odczytowy, zbiór danych mieści się z dużym zapasem na urządzeniu i występuje niewiele nadpisań, potencjalny zysk będzie ograniczony. Podobnie przy małym WAF już na starcie komplikowanie ścieżki zapisu może nie mieć uzasadnienia.

Inaczej wygląda serwer cache, baza LSM, system logowania, object storage albo platforma regularnie nadpisująca duże ilości danych. Tam różnica między logicznymi zapisami hosta a fizycznymi zapisami NAND potrafi być jednym z ważniejszych czynników wpływających na koszt i żywotność floty SSD.

Jak uruchamiać FDP w Linuksie, żeby nie pomylić „włączone” z „działa”

Pierwszy krok nie odbywa się w aplikacji. Najpierw trzeba sprawdzić sam kontroler NVMe i konfigurację FDP.

W aktualnym ekosystemie linuksowym obsługę FDP znajdziemy między innymi w nvme-cli, libnvme, fio, SPDK oraz w oprogramowaniu korzystającym bezpośrednio z NVMe przez io_uring_cmd. Sam fakt, że serwer ma dysk NVMe PCIe 5.0, niczego jednak nie gwarantuje. Generacja PCIe i obsługa FDP to dwie różne cechy. Szczególnie w sprzęcie konsumenckim nie należy zakładać obecności FDP bez sprawdzenia capability kontrolera.

nvme-cli potrafi odczytać m.in. strony logów:

• fdp-configs – konfiguracje FDP,

• fdp-ruh-usage – wykorzystanie Reclaim Unit Handles,

• fdp-stats – statystyki FDP,

• fdp-events – zdarzenia FDP.

Do tego dochodzi odczyt stanu RUH. Dostępne informacje obejmują między innymi Placement Identifier, identyfikator RUH, pozostałą dostępną liczbę zapisów do jednostki oraz szacowany pozostały czas aktywności Reclaim Unit, jeżeli kontroler dostarcza te dane.

To powinien być pierwszy test przed zmianą aplikacji: ustalić, czy konkretny model SSD rzeczywiście udostępnia FDP, ile oferuje konfiguracji, jakie ma Reclaim Groups i RUH oraz czy funkcja została włączona dla właściwego Endurance Group.

Kolejny krok to namespace. Przy jego tworzeniu host może określić listę Placement Handles i przypisać do nich odpowiednie identyfikatory Reclaim Unit Handles. nvme-cli obsługuje w tym celu listę uchwytów przy tworzeniu namespace’u. To już operacja administracyjna, więc nie należy eksperymentować na urządzeniu z produkcyjnymi danymi. Zmiana układu namespace’ów może oznaczać konieczność ich ponownego utworzenia i utratę znajdujących się w nich danych.

Dopiero później dochodzi aplikacja lub generator obciążenia.

fio pozwala testować Data Placement typu FDP i wybierać konkretne Placement IDs. Można ograniczić pulę używanych identyfikatorów, a także przygotować schemat przypisujący zakresy offsetów LBA do określonych PID. Dzięki temu da się zbudować powtarzalny benchmark bez przepisywania własnego silnika storage.

To rozsądniejsza kolejność niż natychmiastowa integracja z bazą danych:

1. sprawdzić capability SSD;

2. odczytać konfigurację FDP i RUH;

3. zebrać bazowy WAF bez FDP;

4. przygotować dwie–cztery klasy danych o naprawdę różnym czasie życia;

5. odtworzyć workload w fio lub innym kontrolowanym narzędziu;

6. porównać FDP Statistics, throughput oraz p99/p99.9;

7. dopiero po potwierdzeniu efektu przenieść klasyfikację do aplikacji.

Jest jeszcze jeden detal, który dobrze nadaje się do wykrywania błędów implementacji. Zapis z nieprawidłowym Placement Identifierem nie musi zostać odrzucony. Specyfikacja przewiduje, że kontroler może sam wybrać dostępny Reclaim Group i RUH dla takiego zapisu, a następnie wygenerować zdarzenie Invalid Placement Identifier, jeśli odpowiedni typ FDP Event został włączony.

To niewygodne podczas testów, bo aplikacja może pozornie działać poprawnie, mimo że wysyła złe identyfikatory. Dane zostają zapisane, test nie kończy się błędem, ale oczekiwane rozmieszczenie nie występuje.

Dlatego podczas wdrożenia trzeba monitorować FDP Events, a nie tylko sprawdzać kod zakończenia operacji Write. Szczególnie użyteczne są zdarzenia sygnalizujące między innymi:

• Invalid Placement Identifier,

• Reclaim Unit Not Fully Written,

• Reclaim Unit Active Time Limit Exceeded,

• Media Reallocated,

• Implicitly Modified Reclaim Unit Handle.

Ten mechanizm diagnostyczny jest ważniejszy, niż wygląda. Najgorsza awaria FDP to nie zawsze niedziałający zapis. Znacznie gorszy jest zapis działający bez błędów, ale trafiający do domyślnego placementu i dający administratorowi fałszywe przekonanie, że produkcja korzysta z zaplanowanej segregacji.

FDP ma też praktyczną przewagę nad Zoned Namespaces. ZNS daje hostowi jeszcze większą kontrolę nad rozmieszczeniem danych, ale wymusza znacznie bardziej rygorystyczny model pracy ze strefami i zapisami sekwencyjnymi. FDP zachowuje klasyczny, losowo adresowany interfejs blokowy. Dla istniejącej bazy danych albo cache’u oznacza to zwykle mniejszą ingerencję w architekturę.

Cena za tę wygodę jest jasna: host nie kontroluje całego garbage collectora. Ostateczne decyzje nadal podejmuje firmware SSD. Dwa modele obsługujące tę samą wersję NVMe i FDP mogą więc reagować na identyczny workload inaczej.

FAQ

Czy FDP automatycznie obniża WAF do 1?
Nie. WAF zbliżony do 1 jest możliwy dla dobrze dopasowanych workloadów, ale FDP nie gwarantuje takiego wyniku. Efekt zależy od sposobu grupowania danych, poziomu zapełnienia urządzenia, charakterystyki zapisów oraz polityki firmware’u konkretnego SSD.

Czym FDP różni się od NVMe Streams?
Oba mechanizmy pozwalają przekazywać kontrolerowi informacje pomocne w separowaniu zapisów, ale FDP został zaprojektowany wokół Reclaim Groups, Reclaim Units, RUH i Placement Identifiers oraz daje hostowi dokładniejszy model współpracy z procesem odzyskiwania przestrzeni.

Czy FDP wymaga zapisu sekwencyjnego jak ZNS?
Nie. To jedna z jego największych zalet. Host zachowuje typowy interfejs blokowy i może wykonywać losowe zapisy LBA, podczas gdy Placement Identifier przekazuje dodatkową informację dotyczącą rozmieszczenia.

Czy każdy nowy SSD NVMe PCIe 5.0 obsługuje FDP?
Nie. Wersja PCIe określa interfejs transportowy, a FDP jest osobną funkcją NVMe. Obsługę trzeba potwierdzić na konkretnym kontrolerze i firmware, najlepiej przez narzędzia NVMe, a nie na podstawie samej nazwy handlowej dysku.

Jak dobrać Placement IDs?
Najpierw według czasu życia i wzorca unieważniania danych, a dopiero później według typu aplikacji. Dwa zbiory należące do różnych usług mogą korzystać z tej samej klasy placementu, jeśli ich dane powstają i wygasają w podobnym rytmie.

Czy większa liczba Placement IDs oznacza lepszy wynik?
Nie. Zbyt drobny podział komplikuje klasyfikację i nie daje automatycznej redukcji WAF. Zacząłbym od dwóch–czterech wyraźnie różnych klas i dodawał następne wyłącznie wtedy, gdy pomiary pokazują, że istniejąca grupa łączy dane o wyraźnie różnych cyklach życia.

Co sprawdzić jako pierwsze przed wdrożeniem FDP na produkcji?
Najpierw zmierz bazowy WAF na rzeczywistym workloadzie i odczytaj capabilities oraz konfigurację FDP konkretnego SSD. Jeżeli już bez FDP WAF jest bliski 1, optymalizacja ma niski priorytet. Jeśli jest wysoki, następnym krokiem jest znalezienie dwóch klas danych o najbardziej różnym czasie życia. To właśnie ich mieszanie należy usunąć w pierwszej kolejności — nie zaczynaj od tworzenia kilkunastu PID-ów ani od przebudowy aplikacji.

Więcej informacji na: https://it-buzz.pl