🥇Fio бар дискілерді etcd | үшін жеткілікті өнімділікке қалай тексеруге болады ProHoster

Ескерту. аударма: Бұл мақала etcd дерекқорының жұмысына қатысты нақты мәселенің шешімін іздеу үшін IBM Cloud инженерлері жүргізген шағын зерттеулердің нәтижесі болып табылады. Осыған ұқсас тапсырма біз үшін өзекті болды, дегенмен авторлардың ой-пікірлері мен әрекеттері кеңірек контексте қызықты болуы мүмкін.

Бүкіл мақаланың қысқаша мазмұны: fio және т.б

etcd кластерінің өнімділігі негізгі жад жылдамдығына өте тәуелді. etcd өнімділікті бақылау үшін әртүрлі Prometheus көрсеткіштерін экспорттайды. Солардың бірі wal_fsync_duration_seconds. т.б. құжаттамада дейді олегер бұл көрсеткіштің 99-процентильі 10 мс аспаса, бұл жад жеткілікті жылдам деп санауға болады...

Егер сіз Linux машиналарында etcd кластерін орнатуды қарастырсаңыз және дискілердің (мысалы, SSD дискілері) жеткілікті жылдам екенін тексергіңіз келсе, танымал енгізу/шығару сынақ құралын пайдалануды ұсынамыз. 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 мс-ден сәл аз болса, сақтау өнімділігі жеткіліксіз болу ықтималдығы жоғары.
Сынақ үшін сізге нұсқа қажет fio 3.5-ден кем емес, өйткені ескі нұсқалар нәтижелерді біріктірмейді fdatasync процентиль түрінде.
Жоғарыда айтылған тұжырым жалпы қорытындыдан шағын үзінді ғана fio.

fio және т.б. туралы көбірек

WALs және т.б. туралы бірнеше сөз

Әдетте, мәліметтер базасы қолданылады проактивті тіркеу (алдын ала жазу, WAL). т.б. да әсер етеді. WAL туралы талқылау осы мақаланың ауқымынан тыс, бірақ біздің мақсаттарымыз үшін білуіңіз керек нәрсе - әрбір etcd кластер мүшесі WAL-ды тұрақты сақтауда сақтайды. etcd кейбір кілт-мәнді сақтау операцияларын (жаңартулар сияқты) оларды орындамас бұрын WAL жүйесіне жазады. Түйін бұзылса және суреттер арасында қайта іске қосылса, т.б. WAL мазмұнына негізделген алдыңғы суреттен кейінгі транзакцияларды қалпына келтіре алады.

Осылайша, клиент KV дүкеніне кілт қосқан сайын немесе бар кілттің мәнін жаңартқанда, etcd операцияның сипаттамасын тұрақты қоймадағы кәдімгі файл болып табылатын WAL-ға қосады. etcd жалғастырмас бұрын WAL жазбасының шынымен сақталғанына 100% сенімді болуы керек. 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 шақыруларының ұзақ орындалуы т.б. өнімділігіне әсер етуі мүмкін. Репозиторий құжаттамасында көрсетілген, жеткілікті өнімділік үшін барлық қоңыраулар ұзақтығының 99-процентильі қажет fdatasync WAL файлына жазу 10 мс-ден аз болды. Сақтауға қатысты басқа көрсеткіштер бар, бірақ бұл мақала осыған назар аударады.

Fio көмегімен сақтауды бағалау

Белгілі бір жадтың etcd бағдарламасымен пайдалануға жарамдылығын утилитаны пайдаланып бағалай аласыз fio — танымал енгізу/шығару тестері. Дискіні енгізу/шығару әр түрлі жолдармен жүзеге асуы мүмкін екенін есте сақтаңыз: синхрондау/асинхрондау, көптеген әртүрлі жүйелік қоңырау сыныптары және т.б. Монетаның екінші жағы - бұл fio пайдалану өте қиын. Утилитаның көптеген параметрлері бар және олардың мәндерінің әртүрлі комбинациясы мүлдем басқа нәтижелерге әкеледі. etcd үшін ақылға қонымды баға алу үшін fio арқылы жасалған жазу жүктемесі etcd WAL файлының жазу жүктемесіне мүмкіндігінше жақын екеніне көз жеткізу керек:

Бұл құрылған дегенді білдіреді fio жүктеме кем дегенде файлға жүйелі жазбалар қатары болуы керек, мұнда әрбір жазу жүйелік шақырудан тұрады. writeілесуші fdatasync.
Тізбектелген жазуды қосу үшін жалаушаны көрсету керек --rw=write.
сол fio қоңыраулар арқылы жазды write (басқа жүйелік қоңырауларға қарағанда, мысалы, pwrite), жалаушаны пайдаланыңыз --ioengine=sync.
Соңында ту --fdatasync=1 сайын болуын қамтамасыз етеді write болуы тиіс fdatasync.
Біздің мысалдағы басқа екі параметр: --size и --bs - нақты пайдалану жағдайына байланысты өзгеруі мүмкін. Келесі бөлімде олардың конфигурациясы сипатталады.

Неліктен біз fio-ны таңдадық және оны қалай орнату керектігін білдік

Бұл жазба біз кездестірген нақты жағдайдан алынған. Бізде Prometheus-те мониторингі бар Kubernetes v1.13 жүйесінде кластер болды. SSD дискілері etcd v3.2.24 үшін сақтау ретінде пайдаланылды. Etcd көрсеткіштері тым жоғары кідірістерді көрсетті fdatasync, тіпті кластер жұмыс істемей тұрған кезде де. Біз үшін бұл көрсеткіштер өте күмәнді болып көрінді және біз олардың нақты нені білдіретінін білмедік. Сонымен қатар, кластер виртуалды машиналардан тұрды, сондықтан кідіріс виртуализацияға байланысты ма, әлде SSD кінәлі ме деп айту мүмкін болмады.

Сонымен қатар, біз аппараттық және бағдарламалық қамтамасыз ету конфигурациясындағы әртүрлі өзгерістерді қарастырдық, сондықтан бізге оларды бағалау әдісі қажет болды. Әрине, әрбір конфигурацияда etcd іске қосып, сәйкес Prometheus көрсеткіштерін қарауға болады, бірақ бұл айтарлықтай күш салуды қажет етеді. Бізге нақты конфигурацияны бағалаудың қарапайым жолы қажет болды. Біз т.б. келген Prometheus метрикасын түсінетіндігімізді тексергіміз келді.

Бұл екі мәселені шешуді талап етті:

Біріншіден, WAL файлдарына жазу кезінде etcd арқылы жасалған енгізу/шығару жүктемесі қандай болады? Қандай жүйелік қоңыраулар қолданылады? Жазба блоктарының көлемі қандай?
Екіншіден, жоғарыдағы сұрақтарға жауаптарымыз бар делік. Сәйкес жүктемені қалай шығаруға болады fio? Қалай болғанда да fio — көптеген параметрлері бар өте икемді утилита (мұны тексеру оңай, мысалы, осында - шамамен. аудар.).

Біз екі мәселені бірдей командалық тәсілмен шештік lsof и strace:

Көмегімен lsof процесс пайдаланатын барлық файл дескрипторларын, сондай-ақ оларға сілтеме жасайтын файлдарды көруге болады.
Көмегімен strace сіз әлдеқашан жұмыс істеп тұрған процесті талдай аласыз немесе процесті іске қосып, оны көре аласыз. Пәрмен осы процесс арқылы жасалған барлық жүйелік қоңырауларды және қажет болса, оның ұрпақтарын көрсетеді. Соңғысы ашылатын процестер үшін маңызды, және т.б. осындай процестердің бірі.

Біз жасаған бірінші нәрсе пайдалану болды strace Kubernetes кластеріндегі etcd серверін жұмыс істемей тұрған кезде тексеру үшін.

Осылайша, 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 (бұл т.б. жағдайда жасалғандай).

Параметрдің мәнін анықтауға ерекше назар аударылды --size. Ол fio утилитасы арқылы жасалған жалпы енгізу/шығару жүктемесін білдіреді. Біздің жағдайда бұл бұқаралық ақпарат құралдарына жазылған байттардың жалпы саны. Ол қоңыраулар санына тура пропорционал write (және fdatasync). Нақты үшін bs қоңыраулар саны fdatasync тең size / bs.

Бізді пайыздық көрсеткіш қызықтырғандықтан, біз үлгілер санының статистикалық маңызды болуы үшін жеткілікті үлкен болуын қаладық. Және солай шешті 10^4 (22 МБ өлшеміне сәйкес келеді) жеткілікті болады. Кішірақ параметр мәндері --size айқынырақ шу шығарды (мысалы, қоңыраулар fdatasync, бұл әдеттегіден әлдеқайда ұзағырақ уақыт алады және 99-процентильге әсер етеді).

Барлығы өзіннің қолында

Мақалада қалай пайдалану керектігі көрсетілген fio etcd-мен пайдалануға арналған медиа жеткілікті жылдам екенін анықтауға болады. Енді бұл сізге байланысты! Қызметте SSD негізіндегі жады бар виртуалды машиналарды зерттеуге болады IBM Cloud.

Аудармашыдан PS

Дайын пайдалану жағдайларымен fio Басқа тапсырмалар үшін қараңыз құжаттама немесе тікелей жоба репозиторийлері (олардың саны құжаттамада көрсетілгеннен әлдеқайда көп).

Аудармашыдан PPS

Біздің блогта да оқыңыз:

Ақпарат көзі: www.habr.com

etcd үшін жеткілікті өнімділік үшін fio бар дискілерді қалай тексеруге болады