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

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

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

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

Ако обмисляте да настроите 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 ms, има голям шанс производителността на съхранението да не е достатъчна.
За теста ще ви трябва версията fio не по-малко от 3.5, тъй като по-старите версии не обобщават резултатите fdatasync под формата на процентили.
Горното заключение е само малък откъс от общото заключение fio.

Повече за fio и etcd

Няколко думи за WAL и т.н

Като цяло базите данни използват проактивно регистриране (регистриране с предварително записване, WAL). etcd също е засегнат. Обсъждането на WAL е извън обхвата на тази статия, но за нашите цели това, което трябва да знаете е, че всеки член на клъстер etcd съхранява WAL в постоянно хранилище. etcd записва някои операции за съхранение на ключ-стойност (като актуализации) в WAL, преди да ги изпълни. Ако възел се срине и се рестартира между моментните снимки, etcd може да възстанови транзакции от предишната моментна снимка въз основа на съдържанието на 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 ms. Има и други показатели, свързани със съхранението, но тази статия ще се съсредоточи върху тях.

Оценяване на съхранението с fio

Можете да прецените дали определено хранилище е подходящо за използване с etcd с помощта на помощната програма Fio — популярен I/O тестер. Имайте предвид, че I/O на диска може да се случи по много различни начини: синхронизиране/асинхронизиране, много различни класове на syscall и т.н. Другата страна на монетата е това fio изключително трудно за използване. Помощната програма има много параметри и различни комбинации от техните стойности водят до напълно различни резултати. За да получите разумна оценка за etcd, трябва да се уверите, че натоварването при запис, генерирано от fio, е възможно най-близо до натоварването при запис на WAL файл на etcd:

Това означава, че генерираното fio натоварването трябва да бъде поне поредица от последователни записи във файла, където всеки запис се състои от системно извикване writeследван от fdatasync.
За да разрешите последователно писане, трябва да посочите флага --rw=write.
Че fio писа с помощта на разговори write (вместо други системни повиквания - напр. pwrite), използвайте флага --ioengine=sync.
И накрая, знамето --fdatasync=1 гарантира, че всеки write трябва да бъде fdatasync.
Другите два параметъра в нашия пример са: --size и --bs - може да варира в зависимост от конкретния случай на употреба. Следващият раздел ще опише тяхната конфигурация.

Защо избрахме fio и как се научихме как да го настроим

Тази бележка идва от истински случай, на който се натъкнахме. Имахме клъстер на Kubernetes v1.13 с мониторинг на Prometheus. SSD бяха използвани като хранилище за 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 може да варира в зависимост от версията, внедряването, стойностите на параметрите и т.н. - влияе върху продължителността 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 MB) ще е достатъчно. По-малки стойности на параметрите --size издаде по-изразен шум (например обаждания fdatasync, което отнема много повече време от обикновено и засяга 99-ия персентил).

От теб зависи

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

PS от преводача

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

PPS от преводача

Прочетете също в нашия блог:

Източник: www.habr.com

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