Брзина на складирање погодна за etcd? Да го прашаме Фио

Кратка приказна за фио и др

Изведба на кластерот итн во голема мера зависи од перформансите на неговото складирање. etcd извезува некои метрики во Прометејза да се обезбедат саканите информации за перформансите на складирањето. На пример, метриката wal_fsync_duration_seconds. Во документацијата за etcd пишува: За складирањето да се смета за доволно брзо, 99-от перцентил на оваа метрика мора да биде помал од 10 ms. Ако планирате да извршите итн. кластер на машини со Linux и сакате да оцените дали вашето складирање е доволно брзо (на пр. SSD), можете да користите Фио е популарна алатка за тестирање на I/O операции. Извршете ја следнава команда, каде тест-податоци е директориумот под точката за монтирање за складирање:

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

Треба само да ги погледнете резултатите и да проверите дали е 99-тиот перцентил од времетраењето fdatasync помалку од 10 ms. Ако е така, имате разумно брзо складирање. Еве пример за резултатите:

  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.
• За време на тестирањето, целото оптоварување на I/O доаѓа од fio. Во реално сценарио, веројатно ќе има и други барања за пишување кои доаѓаат во складиштето, освен оние поврзани со wal_fsync_duration_seconds. Дополнителниот товар ќе ја зголеми вредноста на wal_fsync_duration_seconds. Значи, ако 99-от перцентил е блиску до 10 ms, вашата меморија е без брзина.
• Земете ја верзијата Фио не помалку од 3.5 (претходните не покажуваат перцентили за времетраење на fdatasync).
• Погоре е само дел од резултатите од fio.

Долга приказна за Fio и etcd

Што е WAL во итн

Обично користат бази на податоци дневник за однапред запишување; го користи и etcd. Овде нема детално да разговараме за дневникот за однапред запишување (WAL). Доволно е да знаеме дека секој член на кластерот etcd го одржува во постојано складирање. etcd ја запишува секоја операција со вредност на клучот (како што е ажурирање) во WAL пред да ја примени во продавницата. Ако некој од членовите на складиштето падне и се рестартира помеѓу снимките, може локално да ги обнови трансакциите од последната снимка според содржината на 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 ќе страдаат. Во документацијата за etcd пишувадека складирањето се смета за доволно брзо ако, во 99-от перцентил, на повиците на fdatasync им требаат помалку од 10 ms за да се запишат во датотеката WAL. Постојат и други корисни метрики за складирање, но во овој пост зборуваме само за оваа метрика.

Проценка на складирање со fio

Ако треба да оцените дали вашето складирање е погодно за etcd, користете fio, многу популарна алатка за тестирање на вчитување В/И. Треба да се запомни дека операциите на дискот можат да бидат многу различни: синхрони и асинхрони, многу класи на системски повици итн. Како резултат на тоа, fio е доста тешко да се користи. Има многу параметри, а различните комбинации на нивните вредности создаваат многу различни В/И оптоварувања. За да добиете соодветни бројки за итн.

Затоа, fio треба, минимум, да создаде оптоварување во форма на серија последователни запишувања на датотеката, секое запишување ќе се состои од системски повик пишувампроследено со системскиот повик fdatasync. Секвенцијалните запишувања во fio бараат опција --rw=write. За fio да го користи системот за пишување, повик при пишување, наместо пишуваат, треба да го наведете параметарот --ioengine=sync. Конечно, за да повикате fdatasync после секое запишување, треба да го додадете параметарот --fdatasync=1. Другите две опции во овој пример (--size и -bs) се специфични за скриптата. Во следниот дел, ќе ви покажеме како да ги поставите.

Зошто токму фио и како научивме да го поставиме

Во овој пост, опишуваме вистински случај. Имаме кластер Кубернети v1.13 што го следевме со Прометеј. etcd v3.2.24 беше хостиран на SSD. Etcd метриката покажала превисока латентност на fdatasync, дури и кога кластерот не правел ништо. Метриката беше чудна и навистина не знаевме што значат. Кластерот се состоеше од виртуелни машини, беше неопходно да се разбере што е проблемот: во физички SSD-дискови или во слојот за виртуелизација. Дополнително, често правевме промени во конфигурацијата на хардверот и софтверот и ни требаше начин да ги оцениме нивните резултати. Можеме да работиме etcd во секоја конфигурација и да ги погледнеме метриките на Prometheus, но тоа е преголема мака. Баравме прилично едноставен начин да оцениме одредена конфигурација. Сакавме да провериме дали правилно ја разбираме метриката на Прометеј од etcd.

Но, за ова требаше да се решат два проблема. Прво, како изгледа В/И оптоварувањето што го создава etcd при пишувањето во WAL? Кои системски повици се користат? Која е големината на записите? Второ, ако одговориме на овие прашања, како да репродуцираме сличен обем на работа со fio? Не заборавајте дека fio е многу флексибилна алатка со многу опции. Ги решивме двата проблема во еден пристап - користејќи ги командите лсоф и трага. lsof ги наведува сите дескриптори на датотеки што се користат во процесот и нивните поврзани датотеки. И со штрајс, можете да испитате веќе извршен процес, или да започнете процес и да го испитате. strace ги печати сите системски повици од процесот што се испитува (и неговите втори процеси). Последново е многу важно, бидејќи etcd само зазема сличен пристап.

Прво користевме strace за да го истражиме серверот etcd за Kubernetes кога немаше оптоварување на кластерот. Видовме дека скоро сите записи на WAL беа приближно со иста големина: 2200–2400 бајти. Затоа, во командата на почетокот на постот, го наведовме параметарот -bs=2300 (bs значи големина во бајти за секој фио запис). Имајте предвид дека големината на записот etcd зависи од верзијата etcd, дистрибуцијата, вредностите на параметрите итн., и влијае на времетраењето на fdatasync. Ако имате слично сценарио, испитајте ги вашите процеси итн.д.

Потоа, за да добиеме добра идеја за тоа што прави датотечниот систем etcd, го започнавме со strace и опциите -ffttT. Затоа, се обидовме да ги испитаме детските процеси и да го снимиме излезот од секој од нив во посебна датотека, а исто така да добиеме детални извештаи за почетокот и времетраењето на секој системски повик. Го користевме lsof за да ја потврдиме нашата анализа на излезот на трасата и да видиме кој дескриптор на датотека се користи за која цел. Така, со помош на трајс се добиени резултатите прикажани погоре. Статистиката за време на синхронизација потврди дека wal_fsync_duration_seconds од etcd е конзистентна со повиците fdatasync со дескриптори на датотеки WAL.

Поминавме низ документацијата за fio и избравме опции за нашата скрипта, така што fio ќе генерира оптоварување слично на etcd. Ги проверивме и системските повици и нивното времетраење со извршување на fio од strace, слично на etcd.

Внимателно ја избравме вредноста на параметарот --size за да го претстави целото I/O оптоварување од fio. Во нашиот случај, ова е вкупниот број на бајти запишани во складиштето. Се покажа дека е директно пропорционално на бројот на системски повици за пишување (и fdatasync). За одредена вредност на bs, бројот на fdatasync повици = големина/бс. Бидејќи бевме заинтересирани за перцентилот, моравме да имаме доволно примероци за да бидеме сигурни, и пресметавме дека ќе ни бидат доволни 10^4 (тоа се 22 мебибајти). Ако --size е помала, може да се појават оддалечени (на пример, неколку fdatasync повици траат подолго од вообичаеното и влијаат на 99-от перцентил).

Обидете се сами

Ви покажавме како да користите fio и да видите дали складирањето е доволно брзо за etcd да работи добро. Сега можете сами да го испробате користејќи, на пример, виртуелни машини со складирање на SSD IBM Cloud.

Извор: www.habr.com