etcd માટે પૂરતી કામગીરી માટે fio સાથે ડિસ્ક કેવી રીતે તપાસવી

નૉૅધ. અનુવાદ: આ લેખ એ etcd ડેટાબેઝના સંચાલનને લગતી વાસ્તવિક સમસ્યાના ઉકેલની શોધમાં IBM ક્લાઉડ એન્જિનિયરો દ્વારા હાથ ધરવામાં આવેલા નાના-સંશોધનના પરિણામો છે. સમાન કાર્ય અમારા માટે સુસંગત હતું, પરંતુ લેખકોના વિચારો અને ક્રિયાઓનો અભ્યાસક્રમ વ્યાપક સંદર્ભમાં રસપ્રદ હોઈ શકે છે.

સમગ્ર લેખનો સંક્ષિપ્ત સારાંશ: fio અને etcd

etcd ક્લસ્ટરનું પ્રદર્શન અન્ડરલાઇંગ સ્ટોરેજની ઝડપ પર ખૂબ આધાર રાખે છે. કામગીરીનું નિરીક્ષણ કરવા માટે, વગેરે વિવિધ પ્રોમિથિયસ મેટ્રિક્સની નિકાસ કરે છે. તેમાંથી એક છે wal_fsync_duration_seconds. વગેરે દસ્તાવેજીકરણમાં તે કહે છે, જો આ મેટ્રિકની 99મી પર્સેન્ટાઇલ 10 ms થી વધુ ન હોય તો તે સ્ટોરેજને પર્યાપ્ત ઝડપી ગણી શકાય...

જો તમે Linux મશીનો પર એક etcd ક્લસ્ટર સેટ કરવાનું વિચારી રહ્યાં હોવ અને સ્ટોરેજ ડ્રાઇવ્સ (જેમ કે SSD) પૂરતી ઝડપી છે કે કેમ તે ચકાસવા માંગતા હો, તો અમે લોકપ્રિય I/O ટેસ્ટરનો ઉપયોગ કરવાની ભલામણ કરીએ છીએ. ફિયો. ફક્ત નીચેનો આદેશ ચલાવો (ડિરેક્ટરી test-data પરીક્ષણ કરવામાં આવી રહેલી ડ્રાઇવના માઉન્ટેડ પાર્ટીશનમાં સ્થિત હોવું આવશ્યક છે):

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

જે બાકી છે તે આઉટપુટ જોવાનું છે અને તે 99મી પર્સેન્ટાઈલને બંધબેસે છે કે કેમ તે તપાસવાનું છે fdatasync 10 ms પર જો એમ હોય, તો તમારી ડ્રાઇવ પૂરતી ઝડપી છે. અહીં એક ઉદાહરણ આઉટપુટ છે:

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]

થોડી નોંધો:

1. ઉપરના ઉદાહરણમાં આપણે પરિમાણોને સમાયોજિત કર્યા છે --size и --bs ચોક્કસ કેસ માટે. થી અર્થપૂર્ણ પરિણામો મેળવવા માટે fio, તમારા ઉપયોગના કેસ માટે યોગ્ય હોય તેવા મૂલ્યોનો ઉલ્લેખ કરો. તેમને કેવી રીતે પસંદ કરવું તે નીચે ચર્ચા કરવામાં આવશે.
2. માત્ર પરીક્ષણ દરમિયાન fio ડિસ્ક સબસિસ્ટમ લોડ કરે છે. વાસ્તવિક જીવનમાં, સંભવ છે કે અન્ય પ્રક્રિયાઓ (જેની સાથે સંકળાયેલ છે તે સિવાય wal_fsync_duration_seconds). આવા વધારાના ભારમાં વધારો થઈ શકે છે wal_fsync_duration_seconds. બીજા શબ્દોમાં કહીએ તો, જો 99મી પર્સેન્ટાઇલ સાથે પરીક્ષણમાંથી મેળવેલ હોય fio, માત્ર 10 ms કરતાં સહેજ ઓછું, ત્યાં એક સારી તક છે કે સ્ટોરેજ પ્રદર્શન અપૂરતું છે.
3. પરીક્ષણ માટે તમારે સંસ્કરણની જરૂર પડશે fio 3.5 કરતા ઓછું નથી, કારણ કે જૂની આવૃત્તિઓ એકંદર પરિણામો આપતી નથી fdatasync ટકાવારીના સ્વરૂપમાં.
4. ઉપરોક્ત નિષ્કર્ષ એકંદર નિષ્કર્ષનો માત્ર એક નાનો અંશો છે fio.

fio અને etcd વિશે વિગતો

WALs વગેરે વિશે થોડાક શબ્દો

સામાન્ય રીતે, ડેટાબેઝ ઉપયોગ કરે છે સક્રિય લોગીંગ (રાઇટ-હેડ લોગીંગ, WAL). વગેરે આ પણ લાગુ પડે છે. WAL ની ચર્ચા આ લેખના અવકાશની બહાર છે, પરંતુ અમારા હેતુઓ માટે તમારે જે જાણવાની જરૂર છે તે અહીં છે: દરેક etcd ક્લસ્ટર સભ્ય WALને સતત સ્ટોરેજમાં સ્ટોર કરે છે. etcd કેટલાક કી-વેલ્યુ સ્ટોર ઓપરેશન્સ (જેમ કે અપડેટ્સ) WAL ને એક્ઝેક્યુટ કરતા પહેલા લખે છે. જો નોડ ક્રેશ થાય છે અને સ્નેપશોટ વચ્ચે પુનઃપ્રારંભ થાય છે, તો etcd WAL ની સામગ્રીના આધારે અગાઉના સ્નેપશોટથી કરવામાં આવેલ વ્યવહારોને પુનઃસ્થાપિત કરી શકે છે.

આમ, દર વખતે જ્યારે ક્લાયન્ટ KV સ્ટોરમાં કી ઉમેરે છે અથવા હાલની કીની કિંમત અપડેટ કરે છે, etcd એ WAL માં ઓપરેશનનું વર્ણન ઉમેરે છે, જે સતત સ્ટોરેજમાં નિયમિત ફાઇલ છે. etcd એ 100% ખાતરી હોવી જોઈએ કે આગળ વધતા પહેલા WAL એન્ટ્રી ખરેખર સાચવવામાં આવી છે. 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 ms કરતા ઓછું હતું. સ્ટોરેજ સંબંધિત અન્ય મેટ્રિક્સ છે, પરંતુ આ લેખ તેના પર ધ્યાન કેન્દ્રિત કરશે.

fio નો ઉપયોગ કરીને સ્ટોરેજનું મૂલ્યાંકન કરી રહ્યું છે

તમે મૂલ્યાંકન કરી શકો છો કે શું ચોક્કસ સ્ટોરેજ ઉપયોગિતાનો ઉપયોગ કરીને etcd સાથે ઉપયોગ માટે યોગ્ય છે ફિયો - એક લોકપ્રિય I/O ટેસ્ટર. ધ્યાનમાં રાખો કે ડિસ્ક I/O અલગ અલગ રીતે થઈ શકે છે: સિંક/અસિંક, સિસ્ટમ કૉલ્સના ઘણા વિવિધ વર્ગો, વગેરે. સિક્કાની બીજી બાજુ એ છે fio વાપરવા માટે અત્યંત મુશ્કેલ. ઉપયોગિતામાં ઘણા પરિમાણો છે, અને તેમના મૂલ્યોના વિવિધ સંયોજનો સંપૂર્ણપણે અલગ પરિણામો તરફ દોરી જાય છે. etcd માટે વાજબી અંદાજ મેળવવા માટે, તમારે એ સુનિશ્ચિત કરવું જોઈએ કે fio દ્વારા જનરેટ થયેલ રાઈટ લોડ WAL ફાઈલો પર etcd ના લખાણ લોડ જેટલો શક્ય હોય તેટલો સમાન છે:

• આનો અર્થ એ થાય કે પેદા થાય છે fio વર્કલોડ ઓછામાં ઓછું ફાઇલમાં ક્રમિક લખાણોની શ્રેણી હોવી જોઈએ, જ્યાં દરેક લેખન કામગીરીમાં સિસ્ટમ કૉલનો સમાવેશ થાય છે writeત્યારબાદ fdatasync.
• ક્રમિક રેકોર્ડિંગને સક્ષમ કરવા માટે, તમારે ધ્વજનો ઉલ્લેખ કરવો આવશ્યક છે --rw=write.
• પ્રતિ fio કૉલ્સનો ઉપયોગ કરીને લખ્યું write (અને અન્ય સિસ્ટમ કૉલ્સ નહીં - ઉદાહરણ તરીકે, pwrite), ધ્વજ વાપરો --ioengine=sync.
• છેલ્લે, ધ્વજ --fdatasync=1 ખાતરી આપે છે કે દરેક પાછળ write હોવું જ જોઈએ fdatasync.
• અમારા ઉદાહરણમાં બે અન્ય પરિમાણો: --size и --bs - ચોક્કસ ઉપયોગ કેસના આધારે બદલાઈ શકે છે. આગળનો વિભાગ તેમને કેવી રીતે ગોઠવવું તેનું વર્ણન કરશે.

અમે શા માટે fio પસંદ કર્યું અને અમે તેને કેવી રીતે સેટ કરવું તે શીખ્યા

આ નોંધ એક વાસ્તવિક કેસમાંથી આવે છે જેનો અમે સામનો કર્યો હતો. અમારી પાસે પ્રોમિથિયસ પર દેખરેખ સાથે કુબરનેટ્સ v1.13 પર ક્લસ્ટર હતું. સોલિડ સ્ટેટ ડ્રાઇવનો ઉપયોગ etcd v3.2.24 માટે સંગ્રહ તરીકે થતો હતો. etcd મેટ્રિક્સ ખૂબ ઊંચી વિલંબ દર્શાવે છે fdatasyncજ્યારે ક્લસ્ટર નિષ્ક્રિય હતું ત્યારે પણ. અમને આ મેટ્રિક્સ ખૂબ જ શંકાસ્પદ જણાયા અને અમને ખાતરી ન હતી કે તેઓ બરાબર શું રજૂ કરે છે. વધુમાં, ક્લસ્ટરમાં વર્ચ્યુઅલ મશીનોનો સમાવેશ થતો હતો, તેથી તે કહેવું અશક્ય હતું કે વિલંબ વર્ચ્યુઅલાઈઝેશનને કારણે હતો કે SSDs દોષિત હતા.

વધુમાં, અમે હાર્ડવેર અને સૉફ્ટવેર ગોઠવણીમાં વિવિધ ફેરફારો જોઈ રહ્યા હતા, તેથી અમને તેનું મૂલ્યાંકન કરવાની રીતની જરૂર હતી. અલબત્ત, દરેક રૂપરેખાંકનમાં etcd ચલાવવું અને અનુરૂપ પ્રોમિથિયસ મેટ્રિક્સને જોવું શક્ય બનશે, પરંતુ આ માટે નોંધપાત્ર પ્રયત્નોની જરૂર પડશે. ચોક્કસ રૂપરેખાંકનનું મૂલ્યાંકન કરવા માટે અમને એક સરળ રીતની જરૂર છે. અમે etcd માંથી આવતા પ્રોમિથિયસ મેટ્રિક્સની અમારી સમજને ચકાસવા માગીએ છીએ.

આ કરવા માટે, બે સમસ્યાઓ હલ કરવાની જરૂર હતી:

• પ્રથમ, WAL ફાઇલો પર લખતી વખતે etcd જે I/O લોડ જનરેટ કરે છે તે કેવો દેખાય છે? કયા સિસ્ટમ કૉલ્સનો ઉપયોગ થાય છે? લખવાના બ્લોકનું કદ શું છે?
• બીજું, ચાલો કહીએ કે અમારી પાસે ઉપરોક્ત પ્રશ્નોના જવાબો છે. સાથે અનુરૂપ લોડનું પુનઃઉત્પાદન કેવી રીતે કરવું fio? અંતમાં fio - પુષ્કળ પરિમાણો સાથે અત્યંત લવચીક ઉપયોગિતા (આ ચકાસવું સરળ છે, ઉદાહરણ તરીકે, અહીં - આશરે અનુવાદ.).

અમે સમાન આદેશ-આધારિત અભિગમનો ઉપયોગ કરીને બંને સમસ્યાઓ હલ કરી lsof и strace:

• ની મદદ સાથે lsof તમે પ્રક્રિયા દ્વારા ઉપયોગમાં લેવાતા તમામ ફાઇલ વર્ણનકર્તાઓ તેમજ તેઓ જે ફાઇલોનો સંદર્ભ આપે છે તે જોઈ શકો છો.
• ની મદદ સાથે strace તમે પહેલેથી ચાલી રહેલી પ્રક્રિયાનું વિશ્લેષણ કરી શકો છો અથવા પ્રક્રિયા ચલાવી શકો છો અને તેનું અવલોકન કરી શકો છો. આદેશ આ પ્રક્રિયા દ્વારા કરવામાં આવેલ તમામ સિસ્ટમ કોલ્સ અને વૈકલ્પિક રીતે, તેના વંશજો દર્શાવે છે. બાદમાં ફોર્કિંગ પ્રક્રિયાઓ માટે મહત્વપૂર્ણ છે, અને etcd આવી પ્રક્રિયાઓમાંની એક છે.

અમે જે પ્રથમ વસ્તુનો ઉપયોગ કર્યો તે હતો strace જ્યારે તે નિષ્ક્રિય હોય ત્યારે કુબરનેટ્સ ક્લસ્ટરમાં etcd સર્વરનો અભ્યાસ કરવા માટે.

આમ, એવું જાણવા મળ્યું કે WAL માં રાઇટ બ્લોક્સ ખૂબ જ ગીચ જૂથમાં છે, તેમાંના મોટા ભાગના 2200-2400 બાઇટ્સની રેન્જમાં છે. તેથી જ આ લેખની શરૂઆતમાં આદેશ ધ્વજનો ઉપયોગ કરે છે --bs=2300 (bs — દરેક રેકોર્ડિંગ બ્લોકના બાઈટમાં કદ fio).

મહેરબાની કરીને નોંધ કરો કે આવૃત્તિ, જમાવટ, પરિમાણ મૂલ્યો વગેરેના આધારે etcd રાઈટ બ્લોક માપો બદલાઈ શકે છે. - આ સમયગાળાને અસર કરે છે fdatasync. જો તમારી પાસે સમાન ઉપયોગનો કેસ છે, તો તેની સાથે વિશ્લેષણ કરો strace નવીનતમ મૂલ્યો મેળવવા માટે તમારી etcd પ્રક્રિયાઓ.

પછી, ફાઇલ સિસ્ટમ સાથે etcd કેવી રીતે કામ કરે છે તેની સ્પષ્ટ અને વ્યાપક સમજ મેળવવા માટે, અમે તેને નીચેથી ચલાવ્યું. strace ધ્વજ સાથે -ffttT. આનાથી બાળ પ્રક્રિયાઓ કેપ્ચર કરવાનું અને દરેકનું આઉટપુટ અલગ ફાઇલમાં લખવાનું શક્ય બન્યું. વધુમાં, દરેક સિસ્ટમ કૉલની શરૂઆતની ક્ષણ અને અવધિ વિશે વિગતવાર માહિતી મેળવવામાં આવી હતી.

અમે આદેશનો ઉપયોગ પણ કર્યો lsofઆઉટપુટ વિશે તમારી સમજની પુષ્ટિ કરવા માટે strace કયા હેતુ માટે ફાઇલ વર્ણનકર્તાનો ઉપયોગ કરવામાં આવ્યો હતો તે સંદર્ભમાં. પરિણામ આવ્યું strace, ઉપરના જેવું જ. સિંક્રનાઇઝેશન સમય સાથે આંકડાકીય મેનીપ્યુલેશન્સ પુષ્ટિ કરે છે કે મેટ્રિક wal_fsync_duration_seconds વગેરેથી મેળ ખાતા કૉલ્સ fdatasync WAL ફાઇલ વર્ણનકર્તાઓ સાથે.

નો ઉપયોગ કરીને જનરેટ કરવા માટે fio વગેરેના લોડની જેમ વર્કલોડ, ઉપયોગિતા દસ્તાવેજોનો અભ્યાસ કરવામાં આવ્યો હતો અને અમારા કાર્ય માટે યોગ્ય પરિમાણો પસંદ કરવામાં આવ્યા હતા. અમે સુનિશ્ચિત કર્યું કે યોગ્ય સિસ્ટમ કૉલ્સ સામેલ હતા અને ચાલીને તેમની અવધિની પુષ્ટિ કરી fio થી strace (જેમ કે વગેરેના કિસ્સામાં કરવામાં આવ્યું હતું).

પેરામીટરનું મૂલ્ય નક્કી કરવા માટે ખાસ ધ્યાન આપવામાં આવ્યું હતું --size. તે fio ઉપયોગિતા દ્વારા જનરેટ થયેલ કુલ I/O લોડનું પ્રતિનિધિત્વ કરે છે. અમારા કિસ્સામાં, આ મીડિયાને લખવામાં આવેલી બાઇટ્સની કુલ સંખ્યા છે. તે કૉલ્સની સંખ્યાના સીધા પ્રમાણસર છે write (અને fdatasync). ચોક્કસ માટે bs કૉલ્સની સંખ્યા fdatasync બરાબર size / bs.

કારણ કે અમને પર્સેન્ટાઈલમાં રસ હતો, અમે એ સુનિશ્ચિત કરવાનો પ્રયાસ કર્યો કે નમૂનાઓની સંખ્યા આંકડાકીય મહત્વ માટે પૂરતી મોટી છે. અને તેઓએ તે નક્કી કર્યું 10^4 (જે 22 MB ના કદને અનુરૂપ છે) પર્યાપ્ત હશે. નાના પેરામીટર મૂલ્યો --size વધુ સ્પષ્ટ અવાજ ઉત્પન્ન કરે છે (ઉદાહરણ તરીકે, કૉલ્સ fdatasync, જે સામાન્ય કરતાં ઘણો સમય લે છે અને 99મી પર્સેન્ટાઇલને અસર કરે છે).

તે તમારા ઉપર છે

લેખ બતાવે છે કે કેવી રીતે ઉપયોગ કરવો fio તમે મૂલ્યાંકન કરી શકો છો કે શું etcd સાથે ઉપયોગ કરવા માટે બનાવાયેલ મીડિયા પર્યાપ્ત ઝડપી છે. હવે તે તમારા પર છે! તમે સેવામાં SSD-આધારિત સ્ટોરેજ સાથે વર્ચ્યુઅલ મશીનોનું અન્વેષણ કરી શકો છો આઇબીએમ ક્લાઉડ.

અનુવાદક તરફથી પીએસ

ઉપયોગના તૈયાર ઉદાહરણો સાથે fio અન્ય સમસ્યાઓ ઉકેલવા માટે માં શોધી શકાય છે દસ્તાવેજીકરણ અથવા સીધા જ પ્રોજેક્ટ રીપોઝીટરીઝ (દસ્તાવેજમાં ઉલ્લેખિત કરતાં તેમાંના ઘણા વધુ છે).

અનુવાદક તરફથી PPS

અમારા બ્લોગ પર પણ વાંચો:

• «etcd 3.4.3: સંગ્રહની વિશ્વસનીયતા અને સુરક્ષાનો અભ્યાસ»;
• «સીધો etcd કુબરનેટ્સ ક્લસ્ટરમાં ડેટા સાથે કામ કરવાનો અમારો અનુભવ (K8s API વિના)»;
• «કુબરનેટ્સના સંચાલનમાં 6 મનોરંજક સિસ્ટમ બગ્સ [અને તેમના ઉકેલ]».

સોર્સ: www.habr.com