Скорост на съхранение, подходяща за etcd? Да попитаме Фио

Кратка история за fio и etcd

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

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, скоростта на вашето хранилище е на изчерпване.
• Вземете версията Fio не по-малко от 3.5 (предишните не показват процентили за продължителност на fdatasync).
• По-горе е само фрагмент от резултатите от fio.

Дълга история за fio и etcd

Какво е WAL в etcd

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

Когато клиент добави ключ към хранилището на ключ-стойност или актуализира стойността на съществуващ ключ, etcd записва операцията в WAL, който е обикновен файл в постоянно хранилище. etcd ТРЯБВА да бъде напълно сигурен, че записът в WAL действително се е случил, преди да продължи с обработката. В Linux едно системно извикване не е достатъчно за това. пиша, тъй като действителният запис във физическото хранилище може да се забави. Например, 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$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, много популярен I/O инструмент за тестване на натоварване. Трябва да се помни, че дисковите операции могат да бъдат много различни: синхронни и асинхронни, много класове системни повиквания и т.н. В резултат на това fio е доста труден за използване. Той има много параметри и различни комбинации от техните стойности произвеждат много различни I/O работни натоварвания. За да получите адекватни цифри за etcd, трябва да се уверите, че тестовото натоварване на запис от fio е възможно най-близко до действителното натоварване от etcd при запис на WAL файлове.

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

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

В тази публикация описваме истински случай. Имаме клъстер Kubernetes v1.13, който наблюдавахме с Prometheus. etcd v3.2.24 беше хостван на SSD. Метриките на Etcd показаха твърде високи закъснения на fdatasync, дори когато клъстерът не правеше нищо. Показателите бяха странни и всъщност не знаехме какво означават. Клъстерът се състоеше от виртуални машини, беше необходимо да се разбере какъв е проблемът: във физически SSD или в слоя за виртуализация. Освен това често правехме промени в хардуерната и софтуерната конфигурация и се нуждаехме от начин да оценим техните резултати. Можем да стартираме etcd във всяка конфигурация и да разгледаме показателите на Prometheus, но това е твърде много караница. Търсихме доста лесен начин за оценка на конкретна конфигурация. Искахме да проверим дали разбираме правилно показателите на Prometheus от etcd.

Но за това трябваше да се решат два проблема. Първо, как изглежда I/O натоварването, което etcd създава, когато пише на WAL? Какви системни повиквания се използват? Какъв е размерът на записите? Второ, ако отговорим на тези въпроси, как да възпроизведем подобно натоварване с fio? Не забравяйте, че fio е много гъвкав инструмент с много опции. Решихме и двата проблема с един подход - с помощта на командите също и Strace. 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, за да представим цялото I/O натоварване от fio. В нашия случай това е общият брой байтове, записани в хранилището. Оказа се, че е право пропорционално на броя на системните повиквания за запис (и fdatasync). За определена стойност на bs, броят на извикванията на fdatasync = size/bs. Тъй като се интересувахме от процентила, трябваше да имаме достатъчно проби, за да сме сигурни, и изчислихме, че 10^4 ще ни е достатъчно (това са 22 мебибайта). Ако --size е по-малък, може да възникнат извънредни стойности (например няколко извиквания на fdatasync отнемат повече време от обикновено и засягат 99-ия персентил).

Опитайте сами

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

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