Швидкість сховища підходить для etcd? Запитаємо fio

Коротка історія про fio та etcd

Продуктивність кластера тощо багато в чому залежить від продуктивності його сховища. etcd експортує деякі метрики в Прометей, щоб надати необхідні відомості про продуктивність сховища. Наприклад, метрику wal_fsync_duration_seconds. У документації до etcd сказано: щоб сховище вважалося досить швидким, 99-й процентиль цієї метрики має бути меншим за 10 мс. Якщо ви плануєте запустити кластер etcd на машинах Linux і хочете оцінити, чи достатньо швидке у вас сховище (наприклад, SSD), можна використовувати нитка - Популярний інструмент для тестування операцій введення-виведення. Запустіть наступну команду, де test-data - це каталог під точкою підключення сховища:

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

Потрібно просто переглянути результати та перевірити, що 99-й процентиль тривалості fdatasync менше 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.
• Під час тестування все навантаження введення-виводу надходить від 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 після запису, і якраз використовує його (як можна побачити в результаті роботи) страйк, де 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 при записі у файл WAL займають менше 10 мс. Є й інші корисні метрики для сховища, але в цьому пості ми говоримо лише про цю метрику.

Оцінка сховища за допомогою fio

Якщо потрібно оцінити, чи підходить ваше сховище для etcd, використовуйте fio - дуже популярний інструмент тестування навантаження вводу-виводу. Слід пам'ятати, що дискові операції можуть бути різними: синхронні та асинхронні, безліч класів системних викликів і т. д. Як наслідок — fio досить дуже складно використовувати. Він має безліч параметрів, і різні комбінації їх значень видають зовсім несхожі робочі навантаження вводу-виводу. Щоб отримати адекватні цифри для etcd, слід переконатися, що тестове навантаження запису від fio є максимально близьким до реального навантаження від etcd при записі файлів WAL.

Отже, fio повинен, як мінімум, створювати навантаження у вигляді ряду послідовних операцій запису у файл, кожен запис буде складатися із системного виклику запис, За яким слідує системний виклик fdatasync. Для послідовних операцій запису fio потрібен параметр -rw = write. Щоб під час запису fio використав системний виклик write, а не pwriteварто вказати параметр —ioengine=sync. Нарешті, щоб після кожного запису викликався fdatasync, потрібно додати параметр fdatasync=1. Два інших параметри у цьому прикладі (-size та -bs) залежать від конкретного сценарію. У наступному розділі ми розповімо, як їх налаштувати.

Чому саме fio і як ми навчилися його налаштовувати

У цьому пості описуємо реальний випадок. У нас був кластер Кубернетес v1.13, який ми моніторили за допомогою Prometheus. etcd v3.2.24 розміщувався на SSD. Метрики на etcd показували надто високі затримки для fdatasync, навіть коли кластер нічого не робив. Метрики були дивними, і ми до ладу не знали, що вони означають. Кластер складався з віртуальних машин, потрібно було зрозуміти, в чому проблема: у фізичних SSD або у шарі віртуалізації. До того ж ми часто вносили зміни до конфігурації обладнання та програмного забезпечення, і нам потрібен був спосіб оцінювати їх результат. Ми могли запускати etcd у кожній конфігурації та дивитися на метрики Prometheus, але це надто клопітно. Ми шукали досить простий спосіб оцінювати конкретну конфігурацію. Ми хотіли перевірити, чи правильно ми розуміємо Prometheus метрики від 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 IBM Cloud.

Джерело: habr.com