🥇 Как с fio да проверите дисковете за достатъчна производителност за etcd

Прим. прев.: тази статия е резултат от мини-изследване, проведено от инженери на IBM Cloud в търсене на решение на реален проблем, свързан с експлоатацията на базата данни etcd. За нас беше актуална подобна задача, но размишленията и действията на авторите могат да бъдат интересни и в по-широк контекст.

Кратко резюме на цялата статия: fio и etcd

Производителността на etcd кластера зависи силно от скоростта на хранилището, на което се основава. За контрол на производителността etcd експортира различни метрики Prometheus. Една от тях е wal_fsync_duration_seconds. В документацията на etcd се казва, хранилището може да се счита за достатъчно бързо, ако 99-ят процентил на тази метрика не надвишава 10 мс...

Ако обмисляте възможността за създаване на etcd кластер на машини с Linux и искате да проверите дали хранилищата ви са достатъчно бързи (например SSD), препоръчваме да използвате популярния инструмент за I/O тестове, наречен fio. Просто стартирайте следната команда (директорията test-data трябва да се намира в монтирания дял на тестваното хранилище):

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

Остава само да погледнете изхода и да проверите дали 99-ят процентил fdatasync е в 10 мс. Ако е така, значи вашето хранилище работи достатъчно бързо. Ето един пример за изхода:

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]

Няколко бележки:

В примера по-горе настроихме параметрите --size и --bs за конкретния случай. За да получите смислен резултат от fio, посочете стойности, подходящи за вашия сценарий на употреба. За това как да ги изберете, ще бъде обсъдено по-долу.
По време на тестването само fio натоварва дисковата подсистема. В реалния живот е напълно вероятно, че на диска ще пишат и други процеси (освен тези, свързани с wal_fsync_duration_seconds). Такова допълнително натоварване може да доведе до увеличаване на wal_fsync_duration_seconds. С други думи, ако 99-ят процентил, получен от тестването с fio, само леко е под 10 мс, има голяма вероятност производителността на хранилището да не е достатъчна.
За теста ви е необходима версия fio не по-ниска от 3.5, тъй като по-старите версии не агрегатират резултатите fdatasync под формата на процентил.
Представеният по-горе извод е само малка част от общия извод fio.

Подробно за fio и etcd

Няколко думи за WAL-ите на etcd

Обикновено базите данни използват предварителна журнализация (write-ahead logging, WAL). Това важи и за etcd. Обсъждането на WAL надхвърля обхвата на тази статия, но за нашите цели е нужно да знаете следното: всеки член на etcd клъстера съхранява WAL в постоянно хранилище. etcd записва определени операции с хранилището на ключ-стойност (например актуализации) в WAL, преди да ги изпълни. Ако възелът се срине и бъде рестартиран между моментите на snapshot, etcd ще може да възстанови транзакциите, извършени след последния snapshot, базирайки се на съдържанието на WAL.

Така всеки път, когато клиент добави ключ в KV-хранилището или актуализира стойността на съществуващ ключ, etcd добавя описание на операцията в WAL, който представлява обикновен файл в постоянно хранилище. Преди да продължи работата, etcd ТРЯБВА да бъде 100% уверена, че записа в WAL наистина е запазен. За да се постигне това в Linux, не е достатъчно да се ползва системен повик write, тъй като самата операция на запис на физически носител може да бъде отложена. Например, Linux може за известно време да държи WAL-запис в кеша на ядрото в паметта (например, в страницовия кеш). За да се гарантира, че данните са записани на носителя, след запис е нужно да се задейства системен повик fdatasync — точно така постъпва etcd (както е видно от следния извода strace; тук 8 — дескрипторът на файла WAL):

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 
21:23:09.894911 write(8, ".      20210220361223255266632$10 20103026"34"rn3fo"..., 2296) = 2296 
21:23:09.895041 fdatasync(8)            = 0

За съжаление, записът в постоянното хранилище отнема известно време. Продължителността на повикването fdatasync може да окаже влияние на производителността на etcd. В документацията за хранилището се отбелязва, е посочено, че за достатъчна производителност 99-ият процентил на времето за всички повиквания fdatasync при записване на файл WAL трябва да бъде по-малко от 10 ms. Има и други метрики, свързани с хранилището, но в тази статия ще разгледаме именно тази.

Оценка на хранилището с помощта на fio

Можете да оцените дали определено хранилище е подходящо за работа с etcd, с помощта на утилитата fio — популярен тестер I/O. Важно учитывать, что дисковый ввод-вывод может происходить по-разному: синхронно/асинхронно, с использованием различных классов системных вызовов и т.п. Обратная сторона заключается в том, что fio он чрезвычайно сложен в использовании. У утилиты множество параметров, и различные комбинации их значений приводят к совершенно разным результатам. Чтобы получить адекватную оценку для etcd, необходимо убедиться, что генерируемая fio нагрузка на запись максимально близка к нагрузке etcd при записи в WAL-файлы:

Это означает, что генерируемая fio нагрузка, по крайней мере, должна представлять собой серию последовательных записей в файл, где каждая операция записи состоит из системного вызова write, за которым следует fdatasync.
Чтобы включить последовательную запись, необходимо указать флаг --rw=write.
За да fio письма с использованием вызовов write (а не других системных вызовов — например, pwrite), используйте флаг --ioengine=sync.
Наконец, флаг --fdatasync=1 гарантирует, что за каждым write следва fdatasync.
Два других параметра в нашем примере: --size и --bs — могут меняться в зависимости от конкретного сценария использования. В следующем разделе будет представлена настройка этих параметров.

Почему мы выбрали fio и как мы узнали, как его настраивать

Эта заметка появилась из реального кейса, с которым мы столкнулись. У нас был кластер на Kubernetes v1.13 с мониторингом на Prometheus. В качестве хранилища для etcd v3.2.24 использовались твердотельные накопители. Метрики etcd показывали слишком высокие задержки fdatasync, даже когда кластер простаивал. Мы считали эти метрики сомнительными и не были уверены в том, что именно они представляют. Дополнительно, кластер состоял из виртуальных машин, так что неясно было, связана ли задержка с виртуализацией или в этом виноваты SSD.

Кроме того, мы исследовали различные изменения в конфигурации аппаратного и программного обеспечения, поэтому нужен был способ их оценки. Конечно, можно было бы запустить etcd в каждой конфигурации и наблюдать за соответствующими метриками Prometheus, но это потребовало бы значительных усилий. Нам же был нужен простой способ для оценки конкретной конфигурации. Мы хотели проверить понимание метрик Prometheus, поступающих от etcd.

Для этого требовалось решить две проблемы:

Първо, как изглежда I/O натоварването, генерирано от etcd при записване във WAL файлове? Какви системни повици се използват? Какъв е размерът на записите?
На второ място, приемаме, че имаме отговори на горепосочените въпроси. Как можем да възпроизведем съответното натоварване с fio? Ведь fio — изключително гъвкав инструмент с множество параметри (това лесно може да се провери, например, тук — бел. ред.).

Решихме и двата проблема по един и същ начин, основавайки се на команди lsof и strace:

С помощта на lsof можете да прегледате всички файлови дескриптори, използвани от процеса, както и файловете, с които са свързани.
С помощта на strace можете да анализирате вече стартиран процес или да стартирате нов и да го наблюдавате. Командата извежда всички системни повици, извършени от този процес и, ако е необходимо, от неговите наследници. Последното е важно за процесите, които се форкват, а etcd е един от тези процеси.

Първото, което направихме, е да използваме strace за изучаване на сървъра на etcd в кластера на Kubernetes, докато той е в покой.

Така беше установено, че блоковете на записа в WAL са много плътно групирани, размерът на повечето беше в диапазона 2200-2400 байта. Поради това командата в началото на тази статия използва флага --bs=2300 (бс — размерът в байтове на всеки блок на записа в fio).

Обърнете внимание, че размерът на блоковете на записа в etcd може да варира в зависимост от версията, деплоймента, стойностите на параметрите и др. — това влияе на продължителността. fdatasyncАко имате подобен сценарий на използване, анализирайте чрез strace вашите etcd процеси, за да получите актуални стойности.

След това, за да получим ясна и обхватна представа за работата на etcd с файловата система, стартирахме я с strace с флаговете -ffttT. Това позволи обхващането на наследствените процеси и записването на изхода на всеки в отделен файл. Освен това бяха получени подробни данни за момента на стартиране и продължителността на всеки системен повик.

Също така използвахме командата lsof, за да потвърдим разбирането си за изхода strace в контекста на това, кой файлов дескриптор за каква цел е използван. Полученият изход strace, наподобява този, който е предоставен по-горе. Статистическите манипулации с времето на синхронизация потвърдиха, че метриката wal_fsync_duration_seconds от etcd отговаря на повиците fdatasync с файловите дескриптори на WAL.

За да се генерира с помощта на fio Рабочото натоварване, подобно на натоварването от etcd, беше проучена документацията на утилитата и подбрани параметри, подходящи за нашата задача. Убедихме се, че са активирани необходимите системни извиквания и потвърдихме тяхната продължителност, стартирайки fio от strace (както беше направено в случая с etcd).

Особено внимание беше обърнато на опредлянето на стойността на параметъра --size. Той представлява общото I/O натоварване, генерирано от утилитата fio. В нашия случай това е общият брой байтове, записани на носителя. Той е право пропорционален на броя на извикванията write (и fdatasync). За определено бс броя на извикванията fdatasync е равно на size / bs.

Тъй като ни интересуваше процентилът, ние се стремяхме към достатъчно голям брой проби за статистическа значимост. И решихме, че 10^4 (което отговаря на размер от 22 MB) ще бъде достатъчно. По-малките стойности на параметъра --size даваха по-изразен шум (например, извиквания fdatasync, които отнемат много повече време от обикновено и влияят на 99-ия процентил).

Сега е във вашите ръце

В статията е показано как с помощта на fio може да се оцени дали носителят е достатъчно бърз за използване с etcd. Сега е във вашите ръце! Изследвайте виртуални машини с SSD базирано хранилище в услугата IBM Cloud.

P.S. от преводача

С готови примери за използване fio за решаване на други задачи можете да се запознаете с документацията или директно в репозитория на проекта (там са представени много повече примери, отколкото се споменава в документацията).