Сақтау жылдамдығы т.б. үшін қолайлы ма? Фиодан сұрайық

Fio және т.б. туралы қысқаша әңгіме

Кластердің өнімділігі және т.б. көп жағдайда оны сақтау өнімділігіне байланысты. etcd кейбір көрсеткіштерді экспорттайды Прометейқажетті сақтау өнімділігі туралы ақпаратты қамтамасыз ету. Мысалы, wal_fsync_duration_seconds көрсеткіші. etcd құжаттамасында айтылған: Жад жеткілікті жылдам деп есептелуі үшін, осы көрсеткіштің 99-процентильі 10 мс кем болуы керек. Егер сіз Linux машиналарында etcd кластерін іске қосуды жоспарласаңыз және жадыңыз жеткілікті жылдам (мысалы, SSD) екенін бағалағыңыз келсе, оны пайдалана аласыз. fio енгізу/шығару операцияларын тексеруге арналған танымал құрал болып табылады. Келесі пәрменді іске қосыңыз, мұнда сынақ деректері сақтауды орнату нүктесінің астындағы каталог болып табылады:

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

Fio және т.б. туралы ұзақ әңгіме

WAL деген не т.б

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

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

fio көмегімен жадты бағалау

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

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

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

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

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

Біз алдымен кластерде жүктеме болмаған кезде Kubernetes үшін etcd серверін зерттеу үшін strace қолдандық. Біз WAL жазбаларының барлығы дерлік бірдей көлемде екенін көрдік: 2200–2400 байт. Сондықтан посттың басындағы пәрменде -bs=2300 параметрін көрсеттік (bs әрбір fio жазбасы үшін байттағы өлшемді білдіреді). etcd жазбасының өлшемі etcd нұсқасына, таратуға, параметр мәндеріне және т.б. байланысты екенін және fdatasync ұзақтығына әсер ететінін ескеріңіз. Егер сізде ұқсас сценарий болса, нақты сандарды білу үшін etcd процестеріңізді strace арқылы тексеріңіз.

Содан кейін etcd файлдық жүйесі не істеп жатқаны туралы жақсы түсінік алу үшін біз оны strace және -ffttT опцияларынан бастадық. Сондықтан біз еншілес процестерді тексеруге және олардың әрқайсысының шығысын бөлек файлға жазуға, сондай-ақ әрбір жүйелік қоңыраудың басталуы мен ұзақтығы туралы егжей-тегжейлі есептерді алуға тырыстық. Біз strace шығысының талдауын растау және қандай файл дескрипторы қандай мақсатта қолданылғанын көру үшін lsof қолдандық. Осылайша, strace көмегімен жоғарыда көрсетілген нәтижелер алынды. Синхрондау уақыты статистикасы etcd ішінен wal_fsync_duration_seconds WAL файл дескрипторларымен fdatasync шақыруларына сәйкес келетінін растады.

Біз fio құжаттамасын қарап шықтық және fio etcd файлына ұқсас жүктемені тудыратын етіп сценарийіміздің опцияларын таңдадық. Біз сондай-ақ etcd сияқты strace-тен fio іске қосу арқылы жүйелік қоңырауларды және олардың ұзақтығын тексердік.

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

Өзіңіз көріңіз

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

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