etcd үчүн ылайыктуу сактоо ылдамдыгы? Сурайлы

fio жана башкалар жөнүндө кыскача окуя

Кластердин аткаруусу ж.б. анын сакталышынын натыйжалуулугуна көз каранды. 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 мс кем. Ооба болсо, сизде жетиштүү тез сактагыч бар. Бул жерде натыйжалардын бир мисалы болуп саналат:

  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 аны жөн гана колдонот (иштин жыйынтыгында көрүнүп тургандай) 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 документтеринде айтылатfdatasync чалууларынын 99-проценттили WAL файлына жазуу үчүн 10 мсден аз убакытты талап кылса, сактагыч жетиштүү тез деп эсептелет. Башка пайдалуу сактагыч көрсөткүчтөрү бар, бирок бул постто биз айтып жаткан жалгыз көрсөткүч.

Fio аркылуу сактоону баалоо

Эгер сиздин сактагычыңыз etcd үчүн ылайыктуу экенине баа беришиңиз керек болсо, fio, абдан популярдуу I/O жүгүн текшерүү куралын колдонуңуз. Дисктеги операциялар өтө ар түрдүү болушу мүмкүн экенин эстен чыгарбоо керек: синхрондуу жана асинхрондуу, системалык чалуулардын көп класстары ж.б. Натыйжада, fioну колдонуу абдан кыйын. Анын көптөгөн параметрлери бар жана алардын баалуулуктарынын ар кандай айкалыштары такыр башка I/O жумуш жүктөрүн жаратат. etcd үчүн адекваттуу сандарды алуу үчүн, WAL файлдарын жазууда fioдан тесттик жазуу жүгү etcdден иш жүзүндөгү жүктөмгө мүмкүн болушунча жакын болушун камсыздоо керек.

Демек, fio, жок дегенде, файлга бир катар ырааттуу жазуулардын жүгүн жаратышы керек, ар бир жазуу системалык чакыруудан турган жазууандан кийин fdatasync тутумунун чалуусу. Fio ырааттуу жазуулар үчүн --rw=write параметри талап кылынат. Ошентип, fio жазуу учурунда эмес, жазуу тутумунун чакыруусун колдонот pwrite, ал –ioengine=sync параметрин көрсөтүү зарыл. Акырында, ар бир жазуудан кийин fdatasync чалуу үчүн, --fdatasync=1 опциясын кошушуңуз керек. Бул мисалдагы башка эки вариант (--size жана -bs) сценарийге тиешелүү. Кийинки бөлүмдө биз аларды кантип орнотууну көрсөтөбүз.

Эмне үчүн fio жана биз аны конфигурациялоону кантип үйрөндүк

Бул постто биз чыныгы окуяны сүрөттөп беребиз. Бизде кластер бар болчу Kubernetes v1.13, биз Prometheus аркылуу көзөмөлдөгөн. etcd v3.2.24 SSDде жайгаштырылган. Etcd метрикалары, кластер эч нерсе кылбай турганда да, fdatasync үчүн өтө жогорку кечиктирүүнү көрсөттү. Көрсөткүчтөр кызыктай болгон жана биз алардын эмнени билдирерин чындыгында билген эмеспиз. Кластер виртуалдык машиналардан турган, көйгөй эмнеде экенин түшүнүү керек болчу: физикалык SSDлерде же виртуалдаштыруу катмарында. Мындан тышкары, биз аппараттык жана программалык камсыздоо конфигурацияларына тез-тез өзгөртүүлөрдү киргизчүбүз жана алардын натыйжаларын баалоо ыкмасы керек болчу. Биз ар бир конфигурацияда etcd иштетип, Prometheus метрикасын карап көрсөк болот, бирок бул өтө эле көп түйшүк. Биз белгилүү бир конфигурацияны баалоо үчүн абдан жөнөкөй жол издеп жаткан. Биз etcd'дин Prometheus көрсөткүчтөрүн туура түшүнгөнүбүздү текшергибиз келди.

Бирок бул үчүн эки маселени чечүү керек болчу. Биринчиден, WALга жазганда etcd түзгөн киргизүү/чыгаруу жүгү эмне? Кандай системалык чалуулар колдонулат? Посттордун өлчөмү кандай? Экинчиден, бул суроолорго жооп берсек, фио менен окшош жүктү кантип кайра чыгара алабыз? fio көптөгөн варианттары бар абдан ийкемдүү курал экенин унутпаңыз. Биз эки маселени бир ыкма менен чечтик - буйруктарды колдонуу lsof и strace. lsof процесс тарабынан колдонулган бардык файл дескрипторлорун жана аларга байланыштуу файлдарды көрсөтөт. Ал эми strace менен сиз иштеп жаткан процессти изилдей аласыз же процессти баштап, аны изилдей аласыз. strace изилденип жаткан процесстен (жана анын бала процесстеринен) бардык системалык чалууларды басып чыгарат. Акыркысы абдан маанилүү, анткени etcd окшош мамилени колдонот.

Кластерде жүк жок болгондо, биз биринчи кылган нерсе, Kubernetes үчүн etcd серверин изилдөө үчүн strace колдондук. Биз дээрлик бардык WAL жазуулары болжол менен бирдей өлчөмдө болгонун көрдүк: 2200–2400 байт. Ошондуктан, посттун башындагы буйрукта биз -bs=2300 параметрин көрсөттүк (bs ар бир fio жазуусу үчүн байт өлчөмүн билдирет). Көңүл буруңуз, etcd жазуусунун өлчөмү etcd версиясына, жеткирүүгө, параметр маанилерине, ж.б. көз каранды жана fdatasync узактыгына таасир этет. Эгер сизде окшош сценарий болсо, так сандарды билүү үчүн strace аркылуу etcd процесстериңизди карап көрүңүз.

Андан кийин, etcd файл системасы эмне кыларын жакшы түшүнүү үчүн, биз аны strace жана -ffttT параметрлери менен иштеттик. Ошентип, биз бала процесстерин изилдөөгө жана алардын ар биринин чыгышын өзүнчө файлга жазууга, ошондой эле ар бир тутум чалуусунун башталышы жана узактыгы жөнүндө толук отчетторду алууга аракет кылдык. Биз strace чыгарууну талдообузду ырастоо жана кайсы файл дескриптору кандай максаттарда колдонулганын көрүү үчүн колдондук. Ошентип, strace колдонуп, биз жогоруда көрсөтүлгөн натыйжаларды алдык. Синхрондоштуруу убакытынын статистикасы etcd'ден wal_fsync_duration_seconds метрикасы WAL файл дескрипторлору менен fdatasync чалууларына туура келерин тастыктады.

Fio документтерин карап чыктык жана скриптибиздин параметрлерин тандап алдык, ошентип fio etcd окшош жүктү жаратат. Ошондой эле, etcd.

Биз кылдаттык менен --size параметринин маанисин тандап алдык, ал fioнун бардык I/O жүгүн билдирет. Биздин учурда, бул сактагычка жазылган байттардын жалпы саны. Бул жазуу (жана fdatasync) тутумунун чалууларынын санына түз пропорционалдуу болуп чыкты. bs белгилүү бир мааниси үчүн fdatasync чалуулардын саны = size/bs. Биз пайыздык көрсөткүчкө кызыккандыктан, ишенимдүү болушу үчүн үлгүлөр жетиштүү болушу керек болчу жана биз үчүн 10^4 жетиштүү болорун эсептедик (бул 22 мебибайт). Эгер --size кичине болсо, четтөөлөр пайда болушу мүмкүн (мисалы, бир нече fdatasync чалуулары адаттагыдан көбүрөөк убакытты талап кылат жана 99-проценттилге таасир этет).

Өзүңүз аракет кылып көрүңүз

Биз fioну кантип колдонууну көрсөттүк жана etcd жакшы иштеши үчүн сактагычтын ылдамдыгын билдик. Эми сиз муну, мисалы, SSD сактагычы бар виртуалдык машиналарды колдонуп, өзүңүз да сынап көрө аласыз IBM Cloud.

Source: www.habr.com