🥇Fio менен дисктерди etcd | үчүн жетиштүү иштешин кантип текшерүү керек ProHoster

Эскертүү. котормо.: Бул макала etcd маалымат базасынын иштешине байланыштуу чыныгы көйгөйдү чечүү жолун издөөдө IBM Cloud инженерлери тарабынан жүргүзүлгөн мини-изилдөөнүн натыйжалары. Ушундай эле тапшырма биз үчүн актуалдуу болгон, бирок авторлордун ой-пикири жана иш-аракеттери кененирээк контекстте кызыктуу болушу мүмкүн.

Бүт макаланын кыскача баяндамасы: fio жана башкалар

etcd кластеринин иштеши негизги сактагычтын ылдамдыгынан көз каранды. Иштин натыйжалуулугун көзөмөлдөө үчүн, etcd ар кандай Prometheus көрсөткүчтөрүн экспорттойт. Алардын бири wal_fsync_duration_seconds. etcd документтеринде мамлекеттер, эгерде бул метриканын 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). etcd бул да тиешелүү. 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 чалуусун аяктоо үчүн көп убакыт талап кылынса, etcd иштешине таасир этиши мүмкүн. Репозиторий үчүн документацияда көрсөтүлгөнжетишээрлик аткаруу үчүн бардык чалуулардын узактыгынын 99-проценттиль болушу керек fdatasync файлга жазып жатканда, WAL 10 мс кем болгон. Сактоо менен байланышкан башка көрсөткүчтөр бар, бирок бул макалада ушул нерсеге көңүл бурулат.

Fio аркылуу сактагычты баалоо

Сиз белгилүү бир сактагычтын vb 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 боюнча кластер бар болчу. Катуу абалдагы дисктер 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 утилитасы тарабынан түзүлгөн жалпы I/O жүгүн билдирет. Биздин учурда бул маалымат каражаттарына жазылган байттардын жалпы саны. Бул чалуулардын санына түз пропорционалдуу write (жана fdatasync). Белгилүү болгондой bs чалуулардын саны fdatasync болуп саналат size / bs.

Биз пайыздык көрсөткүчкө кызыккандыктан, биз үлгүлөрдүн саны статистикалык мааниге ээ болуу үчүн жетиштүү болушун камсыз кылууга аракет кылдык. Ошондо алар чечишти 10^4 (22 МБ өлчөмүнө туура келет) жетиштүү болот. Кичинекей параметр маанилери --size көбүрөөк ызы-чуу чыгарган (мисалы, чалуулар fdatasync, бул адаттагыдан бир топ узагыраак убакытты талап кылат жана 99-проценттилге таасир этет).

Бул сага жараша

Макалада кантип колдонуу керектиги көрсөтүлгөн fio etcd менен колдонууга арналган медианын ылдамдыгын баалай аласыз. Эми бул сизге көз каранды! Кызматта SSD негизиндеги сактагычы бар виртуалдык машиналарды изилдей аласыз IBM Cloud.

Котормочудан PS

колдонуунун даяр мисалдары менен fio башка маселелерди чечүү үчүн табууга болот документтер же түздөн-түз долбоордун репозиторийлери (алардын саны документтерде айтылгандан да көп).

Котормочудан PPS

Биздин блогдон дагы окуңуз:

Source: www.habr.com

Fio менен дисктерди etcd үчүн жетиштүү иштеши үчүн кантип текшерүү керек