🥇Jak sprawdzić dyski za pomocą fio pod kątem wystarczającej wydajności dla etcd

Notatka. przeł.: Ten artykuł jest wynikiem mini-badania przeprowadzonego przez inżynierów IBM Cloud w poszukiwaniu rozwiązania realnego problemu związanego z działaniem bazy danych etcd. Podobne zadanie było dla nas istotne, jednak przebieg rozważań i działań autorów może być ciekawy w szerszym kontekście.

Krótkie podsumowanie całego artykułu: fio i etcd

Wydajność klastra etcd w dużym stopniu zależy od szybkości podstawowej pamięci masowej. etcd eksportuje różne metryki Prometheusa w celu monitorowania wydajności. Jeden z nich jest wal_fsync_duration_seconds. W dokumentacji dla etcd to mówiże pamięć można uznać za wystarczająco szybką, jeśli 99. percentyl tej metryki nie przekracza 10 ms…

Jeśli rozważasz utworzenie klastra etcd na maszynach z systemem Linux i chcesz sprawdzić, czy dyski (takie jak dyski SSD) są wystarczająco szybkie, zalecamy skorzystanie z popularnego testera wejść/wyjść o nazwie fio. Wystarczy uruchomić następującą komendę (directory test-data musi znajdować się w zamontowanej partycji testowanego dysku):

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

Pozostaje tylko spojrzeć na wynik i sprawdzić, czy pasuje 99. percentyl fdatasync za 10 ms. Jeśli tak, oznacza to, że dysk działa wystarczająco szybko. Oto przykładowe wyjście:

fsync/fdatasync/sync_file_range:
  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]

Kilka uwag:

W powyższym przykładzie dostosowaliśmy parametry --size и --bs dla konkretnego przypadku. Aby uzyskać znaczący wynik z fio, określ wartości odpowiednie dla Twojego przypadku użycia. Jak je wybrać, zostanie omówione poniżej.
Tylko podczas testowania fio ładuje podsystem dyskowy. W prawdziwym życiu jest prawdopodobne, że inne procesy będą zapisywać na dysku (oprócz tych związanych z wal_fsync_duration_seconds). To dodatkowe obciążenie może wzrosnąć wal_fsync_duration_seconds. Innymi słowy, jeśli 99. percentyl z testu z fio, tylko nieco mniej niż 10 ms, istnieje duże prawdopodobieństwo, że wydajność pamięci masowej nie jest wystarczająca.
Do testu potrzebna będzie wersja fio nie mniej niż 3.5, ponieważ starsze wersje nie agregują wyników fdatasync w postaci percentyli.
Powyższa konkluzja jest tylko małym fragmentem ogólnej konkluzji fio.

Więcej o fio i etcd

Kilka słów o WAL itp

Zasadniczo używają baz danych proaktywne logowanie (rejestrowanie z wyprzedzeniem, WAL). etcd również jest dotknięty. Omówienie WAL wykracza poza zakres tego artykułu, ale dla naszych celów musisz wiedzieć, że każdy członek klastra etcd przechowuje WAL w pamięci trwałej. etcd zapisuje niektóre operacje przechowywania klucz-wartość (takie jak aktualizacje) do WAL przed ich wykonaniem. Jeśli węzeł ulegnie awarii i uruchomi się ponownie między migawkami, etcd może odzyskać transakcje od poprzedniej migawki na podstawie zawartości WAL.

Tak więc za każdym razem, gdy klient dodaje klucz do magazynu KV lub aktualizuje wartość istniejącego klucza, etcd dodaje opis operacji do WAL, który jest zwykłym plikiem w magazynie trwałym. etcd MUSI mieć 100% pewność, że wpis WAL został faktycznie zapisany przed kontynuowaniem. Aby to osiągnąć w systemie Linux, nie wystarczy użyć wywołania systemowego write, ponieważ sama operacja zapisu na nośniku fizycznym może być opóźniona. Na przykład Linux może przez pewien czas przechowywać wpis WAL w pamięci podręcznej jądra (takiej jak pamięć podręczna stron). Aby mieć pewność, że dane zostaną zapisane na nośniku, po zapisie należy wywołać wywołanie systemowe fdatasync - to jest dokładnie to, co robi etcd (jak widać na poniższym wyjściu strace; Tutaj 8 - deskryptor pliku WAL):

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ".20210220361223255266632$1020103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

Niestety zapisywanie w pamięci trwałej zajmuje trochę czasu. Długotrwałe wykonywanie wywołań fdatasync może wpłynąć na wydajność etcd. W dokumentacji repozytorium wskazany, że dla wystarczającej wydajności konieczne jest, aby 99. percentyl czasu trwania wszystkich połączeń fdatasync podczas zapisu do pliku WAL był mniejszy niż 10 ms. Istnieją inne metryki związane z pamięcią masową, ale ten artykuł skupi się na tym.

Wycena przechowywania z fio

Za pomocą narzędzia możesz ocenić, czy określona pamięć jest odpowiednia do użycia z etcd fio — popularny tester wejść/wyjść. Należy pamiętać, że dyskowe operacje we/wy mogą odbywać się na wiele różnych sposobów: synchronizacja/asynchronizacja, wiele różnych klas wywołań systemowych i tak dalej. Druga strona medalu jest taka fio niezwykle trudny w użyciu. Narzędzie ma wiele parametrów, a różne kombinacje ich wartości prowadzą do zupełnie innych wyników. Aby uzyskać rozsądne oszacowanie dla etcd, musisz upewnić się, że obciążenie zapisu generowane przez fio jest jak najbardziej zbliżone do obciążenia zapisu WAL pliku etcd:

Oznacza to, że wygenerowany fio ładowanie powinno być co najmniej serią kolejnych zapisów do pliku, gdzie każdy zapis składa się z wywołania systemowego writeśledzony przez fdatasync.
Aby włączyć zapis sekwencyjny, należy określić flagę --rw=write.
Że fio napisał za pomocą połączeń write (zamiast innych wywołań systemowych — np. pwrite), użyj flagi --ioengine=sync.
Na koniec flaga --fdatasync=1 zapewnia, że każdy write musi być fdatasync.
Pozostałe dwa parametry w naszym przykładzie to: --size и --bs - mogą się różnić w zależności od konkretnego przypadku użycia. W następnej sekcji opisano ich konfigurację.

Dlaczego wybraliśmy Fio i jak nauczyliśmy się go konfigurować

Ta notatka pochodzi z prawdziwego przypadku, z którym się zetknęliśmy. Mieliśmy klaster na Kubernetes v1.13 z monitoringiem na Prometheus. Dyski SSD były używane jako pamięć dla etcd v3.2.24. Metryki Etcd wykazały zbyt duże opóźnienia fdatasync, nawet gdy klaster był bezczynny. Dla nas te wskaźniki wydawały się bardzo wątpliwe i nie byliśmy pewni, co dokładnie reprezentują. Ponadto klaster składał się z maszyn wirtualnych, więc nie można było stwierdzić, czy opóźnienie wynikało z wirtualizacji, czy też winny był dysk SSD.

Ponadto rozważaliśmy różne zmiany w konfiguracji sprzętu i oprogramowania, więc potrzebowaliśmy sposobu na ich ocenę. Oczywiście byłoby możliwe uruchomienie etcd w każdej konfiguracji i przyjrzenie się odpowiednim metrykom Prometheusa, ale wymagałoby to znacznego wysiłku. Potrzebowaliśmy prostego sposobu oceny konkretnej konfiguracji. Chcieliśmy przetestować nasze zrozumienie metryk Prometheusa pochodzących z etcd.

Wymagało to rozwiązania dwóch problemów:

Po pierwsze, jak wygląda obciążenie we/wy generowane przez etcd podczas zapisywania do plików WAL? Jakie wywołania systemowe są używane? Jaki jest rozmiar bloków rekordów?
Po drugie, powiedzmy, że mamy odpowiedzi na powyższe pytania. Jak odtworzyć odpowiednie obciążenie za pomocą fio? Mimo wszystko fio — niezwykle elastyczne narzędzie z dużą ilością parametrów (łatwo to sprawdzić, np. tutaj - około. tłumacz.).

Rozwiązaliśmy oba problemy za pomocą tego samego podejścia opartego na poleceniach lsof и strace:

Z lsof możesz wyświetlić wszystkie deskryptory plików używane przez proces, a także pliki, do których się odnoszą.
Z strace możesz przeanalizować już uruchomiony proces lub uruchomić proces i obserwować go. Polecenie wyświetla wszystkie wywołania systemowe wykonane przez ten proces i, jeśli to konieczne, jego potomków. To ostatnie jest ważne dla procesów rozwidlających się, a etcd jest jednym z takich procesów.

Pierwszą rzeczą, którą zrobiliśmy, było użycie strace do zbadania serwera etcd w klastrze Kubernetes, gdy był bezczynny.

Stwierdzono więc, że bloki rekordów WAL są bardzo gęsto pogrupowane, rozmiar większości mieścił się w przedziale 2200-2400 bajtów. Dlatego polecenie na początku tego artykułu używa flagi --bs=2300 (bs to rozmiar w bajtach każdego bloku zapisu fio).

Należy pamiętać, że rozmiar bloków zapisu etcd może się różnić w zależności od wersji, wdrożenia, wartości parametrów itp. - wpływa na czas trwania fdatasync. Jeśli masz podobny przypadek użycia, przeanalizuj za pomocą strace procesy etcd, aby uzyskać aktualne wartości.

Następnie, aby uzyskać jasny i kompleksowy obraz tego, jak działa etcd z systemem plików, zaczęliśmy go od spodu strace z flagami -ffttT. Umożliwiło to przechwytywanie procesów potomnych i zapisywanie danych wyjściowych każdego z nich w osobnym pliku. Ponadto uzyskano szczegółowe informacje o czasie rozpoczęcia i czasie trwania każdego wywołania systemowego.

Użyliśmy również polecenia lsofaby potwierdzić zrozumienie wyjścia strace pod względem tego, który deskryptor pliku został użyty w jakim celu. Doszedłem do wniosku strace, podobny do powyższego. Statystyczne manipulacje czasami synchronizacji potwierdziły, że metryka wal_fsync_duration_seconds from etcd pasuje do wywołań fdatasync z deskryptorami plików WAL.

Aby wygenerować z fio obciążenie podobne do tego z etcd, przestudiowano dokumentację narzędzia i wybrano parametry odpowiednie dla naszego zadania. Sprawdziliśmy, czy trwają prawidłowe wywołania systemowe i potwierdziliśmy ich czas trwania, uruchamiając fio z strace (tak jak to zrobiono w przypadku etcd).

Szczególną uwagę zwrócono na określenie wartości parametru --size. Reprezentuje całkowite obciążenie we/wy generowane przez narzędzie fio. W naszym przypadku jest to całkowita liczba bajtów zapisanych na nośniku. Jest wprost proporcjonalna do liczby połączeń write (i fdatasync). Dla konkretnego bs liczba połączeń fdatasync równa się size / bs.

Ponieważ interesował nas percentyl, chcieliśmy, aby liczba próbek była wystarczająco duża, aby była istotna statystycznie. I zdecydował, że 10^4 (co odpowiada rozmiarowi 22 MB). Mniejsze wartości parametrów --size dawał wyraźniejszy hałas (na przykład połączenia fdatasync, które trwają znacznie dłużej niż zwykle i wpływają na 99. percentyl).

To zależy od Ciebie

Artykuł pokazuje, jak używać fio można ocenić, czy nośnik przeznaczony do użytku z etcd jest wystarczająco szybki. Teraz to zależy od Ciebie! W usłudze można eksplorować maszyny wirtualne z pamięcią masową opartą na dyskach SSD IBM Cloud.

PS od tłumacza

Z gotowymi przypadkami użycia fio W przypadku innych zadań zob dokumentacja lub bezpośrednio do repozytoria projektów (jest ich znacznie więcej niż podano w dokumentacji).

PPS od tłumacza

Przeczytaj także na naszym blogu:

Źródło: www.habr.com

Jak sprawdzić dyski za pomocą fio pod kątem wystarczającej wydajności dla etcd