🥇Як з 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 запісвае некаторыя аперацыі з key-value-сховішчам (напрыклад, абнаўлення) у 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 <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>

Нажаль, запіс у сталае сховішча займае некаторы час. Якое зацягнулася выкананне выкліку fdatasync можа адбіцца на прадукцыйнасці etcd. У дакументацыі да сховішча паказваецца, Што для дастатковай прадукцыйнасці неабходна, каб 99-й процентиль працягласці ўсіх выклікаў fdatasync пры запісе ў файл WAL была менш за 10 мс. Ёсць і іншыя метрыкі, звязаныя са сховішчам, але ў гэтым артыкуле пойдзе гаворка менавіта аб гэтым.

Ацэньваем сховішча з дапамогай fio

Ацаніць, ці падыходзіць нейкае сховішча для выкарыстання з etcd, можна з дапамогай утыліты FIO - Папулярнага тэстара I / O. Улічвайце, што дыскавы ўвод-вывад можа адбывацца па-рознаму: sync/async, мноства розных класаў сістэмных выклікаў і да т.п. Адваротны бок медаля заключаецца ў тым, што 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 (bs - Памер у байтах кожнага блока запісу ў fio).

Звярніце ўвагу, што памер блокаў запісу etcd можа вар'іравацца ў залежнасці ад версіі, deployment'а, значэнняў параметраў і г.д. - гэта ўплывае на працягласць 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). Для пэўнага bs колькасць выклікаў fdatasync роўна size / bs.

Паколькі нас цікавіў працэнтыль, мы імкнуліся да таго, каб колькасць спроб была дастаткова вялікай для статыстычнай значнасці. І вырашылі, што 10^4 (што адпавядае памеру ў 22 Мб) будзе дастаткова. Меншыя значэнні параметру --size давалі больш выяўлены шум (напрыклад, выклікі fdatasync, якія займаюць значна больш часу, чым звычайна, і ўплываюць на 99-й процентиль).

Справа за вамі

У артыкуле паказана, як з дапамогай fio можна ацаніць, ці зяўляецца дастаткова хуткім носьбіт, прызначаны для выкарыстання з etcd. Цяпер справа за вамі! Даследаваць віртуальныя машыны са сховішчам на базе SSD можна ў сэрвісе IBM Cloud.

PS ад перакладчыка

З гатовымі прыкладамі выкарыстання fio для рашэння іншых задач можна азнаёміцца ў дакументацыі або напрамую ў рэпазітары праекта (Там іх прадстаўлена нашмат больш, чым згадваецца ў дакументацыі).

PPS з перакладчыка

Чытайце таксама ў нашым блогу:

Крыніца: habr.com

Як з fio праверыць дыскі на дастатковую прадукцыйнасць для etcd