Кароткая гісторыя пра fio і etcd
Прадукцыйнасць кластара шмат у чым залежыць ад прадукцыйнасці яго сховішчы. etcd экспартуе некаторыя метрыкі ў , Каб прадаставіць патрэбныя звесткі аб прадукцыйнасці сховішчы. Напрыклад, метрыку wal_fsync_duration_seconds. : каб сховішча лічылася дастаткова хуткім, 99-ы працэнтыль гэтай метрыкі павінен быць меншы за 10 мс. Калі вы плануеце запусціць кластар etcd на машынах Linux і жадаеце ацаніць, ці досыць хуткае ў вас сховішча (напрыклад, SSD), можна выкарыстоўваць - Папулярная прылада для тэставання аперацый уводу-высновы. Запусціце наступную каманду, дзе test-data - гэта каталог пад кропкай падлучэння сховішчы:
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestТрэба проста паглядзець вынікі і праверыць, што 99-й процентиль працягласці менш за 10 мс. Калі так, у вас дастаткова хуткае сховішча. Вось прыклад вынікаў:
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-й процентиль амаль дацягнуў да 10 мс, вашаму сховішчы не хопіць хуткасці.
- Бярыце версію не ніжэй за 3.5 (папярэднія не паказваюць працэнты працягласці fdatasync).
- Вышэй паказаны толькі фрагмент вынікаў ад fio.
Доўгая гісторыя пра fio і etcd
Што такое WAL у etcd
Звычайна базы дадзеных выкарыстоўваюць ; etcd таксама яго выкарыстоўвае. Тут мы не будзем падрабязна абмяркоўваць часопіс папераджальнай запісы (write-ahead log, WAL). Нам дастаткова ведаць, што кожны член кластара etcd вядзе яго ў пастаянным сховішчы. etcd запісвае кожную аперацыю з парамі ключ-значэнне (напрыклад, абнаўленне) у WAL, перш чым прымяніць іх у сховішча. Калі паміж здымкамі адзін з чальцоў сховішчы аварыйна завяршаецца і перазапускаецца, ён можа лакальна аднавіць транзакцыі з моманту апошняга здымка па змесціва WAL.
Калі кліент дадае ключ у сховішча пар ключ-значэнне або абнаўляе значэнне існуючага ключа, etcd уносіць запіс аб гэтай аперацыі ў WAL, які ўяўляе сабой звычайны файл у пастаянным сховішчы. Перш чым працягнуць апрацоўку, etcd ПАВІНЕН быць цалкам упэўнены, што запіс у WAL сапраўды адбыўся. У Linux для гэтага недастаткова аднаго сістэмнага выкліку , так як фактычна запіс у фізічнае сховішча можа быць адкладзена. Напрыклад, Linux можа некаторы час захоўваць запіс WAL у кэшы ў памяці ядра (напрыклад, старонкавым кэшы). А для таго, каб дадзеныя сапраўды запісаліся ў сталае сховішча, патрэбен сістэмны выклік fdatasync пасля запісу, і etcd як раз выкарыстоўвае яго (як можна ўбачыць у выніку працы , дзе 8 - гэта дэскрыптар файла WAL):
21:23:09.894875 lseek(8, 0, SEEK_CUR) = 12808 <0.000012>
21:23:09.894911 write(8, ". 20210220361223255266632$10 20103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8) = 0 <0.008314>Нажаль, запіс у сталае сховішча не праходзіць імгненна. Калі выклік fdatasync працуе павольна, прадукцыйнасць сістэмы etcd падае. , Што сховішча лічыцца досыць хуткім, калі ў 99-м працэнты выклікаў fdatasync пры запісе ў файл WAL займаюць менш за 10 мс. Ёсць і іншыя карысныя метрыкі для сховішча, але ў гэтым пасце мы гаворым толькі аб гэтай метрыцы.
Ацэнка сховішчы з дапамогай fio
Калі трэба ацаніць, ці падыходзіць ваша сховішча для etcd, выкарыстайце fio — вельмі папулярная прылада тэставання нагрузкі ўводу-высновы. Варта памятаць, што дыскавыя аперацыі могуць быць самымі рознымі: сінхронныя і асінхронныя, мноства класаў сістэмных выклікаў і т. д. Як следства - fio досыць вельмі складана выкарыстоўваць. У яго маецца мноства параметраў, і розныя камбінацыі іх значэнняў выдаюць зусім непадобныя працоўныя нагрузкі ўводу-высновы. Каб атрымаць адэкватныя лічбы для etcd, варта ўпэўніцца, што тэставая нагрузка запісу ад fio максімальна блізкая да рэальнай нагрузкі ад etcd пры запісе файлаў WAL.
Такім чынам, fio павінен, прынамсі, ствараць нагрузку ў выглядзе шэрагу паслядоўных аперацый запісу ў файл, кожны запіс будзе складацца з сістэмнага выкліку. , за якім ідзе сістэмны выклік fdatasync. Для паслядоўных аперацый запісу fio патрэбен параметр -rw = write. Каб пры запісе fio выкарыстоўваў сістэмны выклік write, а не , варта пазначыць параметр -ioengine=sync. Нарэшце, каб пасля кожнага запісу выклікаўся fdatasync, трэба дадаць параметр -fdatasync=1. Два іншых параметра ў гэтым прыкладзе (-size і -bs) залежаць ад пэўнага сцэнара. У наступным раздзеле мы раскажам, як іх наладзіць.
Чаму менавіта fio і як мы навучыліся яго наладжваць
У гэтым пасце мы апісваем рэальны выпадак. У нас быў кластар v1.13, які мы маніторылі з дапамогай Prometheus. etcd v3.2.24 размяшчаўся на SSD. Метрыкі па etcd паказвалі занадта высокія затрымкі для fdatasync, нават калі кластар нічога не рабіў. Метрыкі былі дзіўнымі, і мы толкам не ведалі, што яны азначаюць. Кластар складаўся з віртуальных машын, трэба было зразумець, у чым праблема: у фізічных SSD ці ў пласце віртуалізацыі. Да таго ж мы часта ўносілі змены ў канфігурацыю абсталявання і ПЗ, і нам патрэбен быў спосаб ацэньваць іх вынік. Мы маглі запускаць etcd у кожнай канфігурацыі і глядзець на метрыкі Prometheus, але гэта занадта клапотна. Мы шукалі дастаткова просты спосаб ацэньваць канкрэтную канфігурацыю. Мы хацелі праверыць, ці правільна мы разумеем метрыкі Prometheus ад etcd.
Але для гэтага трэба было развязаць дзве праблемы. Па-першае, як выглядае нагрузка ўводу-высновы, якую etcd стварае пры запісе ў WAL? Якія сістэмныя выклікі выкарыстоўваюцца? Які памер запісаў? Па-другое, калі мы адкажам на гэтыя пытанні, як прайграць аналагічную працоўную нагрузку з fio? Не забывайце, што fio — вельмі гнуткая прылада са мноствам параметраў. Мы вырашылі абедзве праблемы адным падыходам - з дапамогай каманд и . lsof адлюстроўвае ўсе дэскрыптары файлаў, якія выкарыстоўваюцца працэсам, і звязаныя з імі файлы. А з дапамогай strace можна вывучыць ужо запушчаны працэс ці запусціць працэс і вывучыць яго. strace выводзіць усе сістэмныя выклікі ад які вывучаецца працэсу (і яго даччыных працэсаў). Апошняе вельмі важна, паколькі etcd як раз ужывае падобны падыход.
Перш за ўсё мы выкарыстоўвалі strace для вывучэння сервера etcd для Kubernetes, калі на кластар не было нагрузкі. Мы ўбачылі, што амаль усе запісы WAL былі прыкладна аднаго памеру: 2200-2400 байт. Таму ў камандзе ў пачатку посту мы паказалі параметр -bs=2300 (bs азначае памер у байтах для кожнага запісу fio). Звярніце ўвагу, што памер запісу etcd залежыць ад версіі etcd, пастаўкі, значэнняў параметраў і т. д. і ўплывае на працягласць fdatasync. Калі ў вас падобны сцэнар, вывучыце свае працэсы etcd з дапамогай strace, каб пазнаць дакладныя лічбы.
Затым, каб добра ўявіць сабе дзеянні ў файлавай сістэме etcd, мы запусцілі яе са strace і з параметрамі -ffttT. Так мы спрабавалі вывучыць даччыныя працэсы і запісаць выходныя дадзеныя кожнага з іх у асобным файле, а яшчэ атрымаць падрабязныя справаздачы аб пачатку і працягласці кожнага сістэмнага выкліку. Мы выкарыстоўвалі lsof, каб пацвердзіць свой аналіз выходных дадзеных strace і ўбачыць, які дэскрыптар файла для якіх мэт выкарыстоўваўся. Так з дапамогай strace атрымаліся вынікі, паказаныя вышэй. Статыстыка па часе сінхранізацыі пацвердзіла, што паказчык wal_fsync_duration_seconds з etcd адпавядае выклікам fdatasync з файлавымі дэскрыптарамі WAL.
Мы вывучылі дакументацыю па fio і абралі параметры для нашага сцэнара, каб fio згенераваў нагрузку, аналагічную etcd. Таксама мы праверылі сістэмныя выклікі і іх працягласць, запусціўшы fio са strace, па аналогіі з etcd.
Мы старанна падабралі значэнне параметру -size, якія ўяўляе ўсю нагрузку ўводу-высновы ад fio. У нашым выпадку гэта агульная колькасць байтаў, якія запісваюцца ў сховішча. Яно атрымалася прама прапарцыйнай колькасці сістэмных выклікаў write (і fdatasync). Для вызначанага значэння bs колькасць выклікаў fdatasync = size/bs. Паколькі нас цікавіў процентиль, у нас павінна было быць дастаткова ўзораў для дакладнасці, і мы падлічылі, што нам будзе дастаткова 10 ^ 4 (атрымліваецца 22 мебібайта). Калі -size менш, могуць узнікаць выкіды (напрыклад, некалькі выклікаў fdatasync адпрацоўваюць даўжэй звычайнага і ўплываюць на 99-й процентиль).
паспрабуйце самі
Мы паказалі, як выкарыстоўваць fio і даведацца, ці дастаткова ў сховішчы хуткасці для высокай прадукцыйнасці etcd. Цяпер вы можаце паспрабаваць гэта на практыцы самастойна, выкарыстоўваючы, напрыклад, віртуальныя машыны з сховішчам SSD у .
Крыніца: habr.com