ආදිය සඳහා ගබඩා වේගය සුදුසුද? අපි ෆියෝගෙන් අහමු

fio සහ etcd ගැන කෙටි කතාවක්

පොකුරු කාර්ය සාධනය ආදිය බොහෝ දුරට එහි ගබඩාවේ කාර්ය සාධනය මත රඳා පවතී. etcd සමහර ප්‍රමිතික අපනයනය කරයි Prometheusඅපේක්ෂිත ගබඩා කාර්ය සාධන තොරතුරු සැපයීමට. උදාහරණයක් ලෙස, wal_fsync_duration_seconds මෙට්‍රික්. etcd සඳහා ලියකියවිලි පවසයි: ගබඩා කිරීම ප්‍රමාණවත් තරම් වේගවත් යැයි සැලකීමට නම්, මෙම මිතිකයේ 99 වැනි ප්‍රතිශතය 10ms ට වඩා අඩු විය යුතුය. ඔබ ලිනක්ස් යන්ත්‍රවල etcd පොකුරක් ධාවනය කිරීමට අදහස් කරන්නේ නම් සහ ඔබේ ගබඩාව ප්‍රමාණවත් තරම් වේගවත් දැයි තක්සේරු කිරීමට අවශ්‍ය නම් (උදා: SSD), ඔබට භාවිතා කළ හැක fio I/O මෙහෙයුම් පරීක්ෂා කිරීම සඳහා ජනප්‍රිය මෙවලමකි. පහත විධානය ක්‍රියාත්මක කරන්න, එහිදී test-data යනු ගබඩා සවි කිරීමේ ස්ථානය යටතේ ඇති බහලුම වේ:

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

ඔබට අවශ්‍ය වන්නේ ප්‍රතිඵල දෙස බලා කාලසීමාවේ 99 වැනි ප්‍රතිශතය දැයි පරීක්ෂා කිරීමයි fdatasync 10 ms ට අඩු එසේ නම්, ඔබට සාධාරණ වේගවත් ගබඩාවක් ඇත. මෙන්න ප්රතිඵල සඳහා උදාහරණයක්:

  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 වින්‍යාස කිරීමට ඉගෙන ගත් ආකාරය.
• පරීක්ෂා කිරීමේදී, සියලුම I/O load පැමිණෙන්නේ fio වෙතින්. සැබෑ ජීවිතයකදී, wal_fsync_duration_seconds වලට අදාළ ඒවාට අමතරව වෙනත් ලිවීමේ ඉල්ලීම් ගබඩාවට පැමිණීමට ඉඩ ඇත. අමතර පැටවීම wal_fsync_duration_seconds වල අගය වැඩි කරයි. එබැවින් 99 වැනි ප්‍රතිශතය 10ms ට ආසන්න නම්, ඔබේ ගබඩාවේ වේගය අවසන් වේ.
• අනුවාදය ගන්න fio 3.5 ට වඩා අඩු නොවේ (පෙර ඒවා fdatasync කාල ප්‍රතිශත පෙන්වන්නේ නැත).
• ඉහත දක්වා ඇත්තේ fio වෙතින් ලැබෙන ප්‍රතිඵලවල කොටසක් පමණි.

fio සහ etcd ගැන දිග කතාවක්

ආදියෙහි WAL යනු කුමක්ද?

සාමාන්යයෙන් දත්ත සමුදායන් භාවිතා කරයි ඉදිරියට ලියන්න; etcd එය ද භාවිතා කරයි. අපි මෙහි ලිවීමට පෙර ලොගය (WAL) විස්තරාත්මකව සාකච්ඡා නොකරමු. etcd පොකුරේ සෑම සාමාජිකයෙක්ම එය නොනැසී පවතින ගබඩාවක පවත්වාගෙන යන බව දැනගැනීම අපට ප්‍රමාණවත්ය. etcd ගබඩාවට යෙදීමට පෙර එක් එක් යතුරු අගය ක්‍රියාවන් (යාවත්කාලීන කිරීමක් වැනි) WAL වෙත ලියයි. ගබඩා සාමාජිකයින්ගෙන් එක් අයෙකු බිඳවැටීම සහ ස්නැප්ෂොට් අතර නැවත ආරම්භ කළහොත්, එයට WAL අන්තර්ගතය අනුව අවසන් ස්නැප්ෂොට් සිට ගනුදෙනු දේශීයව ප්‍රතිසාධනය කළ හැක.

සේවාලාභියෙකු යතුරු-අගය ගබඩාවට යතුරක් එක් කරන විට හෝ පවතින යතුරක අගය යාවත්කාලීන කරන විට, etcd විසින් අඛණ්ඩ ගබඩාවේ ඇති සාමාන්‍ය ගොනුවක් වන WAL හි ක්‍රියාකාරිත්වය වාර්තා කරයි. etcd සැකසීම දිගටම කරගෙන යාමට පෙර WAL ප්‍රවේශය ඇත්ත වශයෙන්ම සිදු වූ බවට සම්පූර්ණයෙන්ම සහතික විය යුතුය. Linux වලදී, මේ සඳහා එක් පද්ධති ඇමතුමක් ප්රමාණවත් නොවේ. ලියන්න, භෞතික ගබඩාවට සත්‍ය ලිවීම ප්‍රමාද විය හැකි බැවින්. උදාහරණයක් ලෙස, Linux විසින් යම් කාලයක් සඳහා කර්නල් මතකයේ (පිටු හැඹිලියක් වැනි) හැඹිලියක WAL ප්‍රවේශයක් ගබඩා කළ හැක. ස්ථිර ගබඩාවට දත්ත නිවැරදිව ලිවීම සඳහා, ලිවීමෙන් පසු fdatasync පද්ධති ඇමතුම අවශ්‍ය වන අතර etcd එය භාවිතා කරයි (ඔබට කාර්යයේ ප්‍රති result ලය අනුව දැකිය හැකිය. තීරය, 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 ගොනුවට ලිවීමට 10ms ට වඩා අඩු කාලයක් ගත වුවහොත් ගබඩාව ප්‍රමාණවත් තරම් වේගවත් යැයි සැලකේ. ගබඩා කිරීම සඳහා වෙනත් ප්‍රයෝජනවත් ප්‍රමිතික ඇත, නමුත් මෙම ලිපියෙන් අපි කතා කරන්නේ මෙම මෙට්‍රික් ගැන පමණි.

fio සමඟ ගබඩාව ඇස්තමේන්තු කිරීම

ඔබේ ගබඩාව etcd සඳහා සුදුසු දැයි ඔබට ඇගයීමට අවශ්‍ය නම්, ඉතා ජනප්‍රිය I/O load testing මෙවලමක් වන fio භාවිතා කරන්න. තැටි මෙහෙයුම් බෙහෙවින් වෙනස් විය හැකි බව මතක තබා ගත යුතුය: සමමුහුර්ත සහ අසමමුහුර්ත, පද්ධති ඇමතුම් බොහෝ පන්ති, ආදිය. ප්රතිඵලයක් ලෙස, fio භාවිතා කිරීම තරමක් අපහසු වේ. එයට බොහෝ පරාමිති ඇති අතර ඒවායේ අගයන්හි විවිධ සංයෝජන ඉතා වෙනස් I/O වැඩ බරක් නිපදවයි. etcd සඳහා ප්‍රමාණවත් සංඛ්‍යා ලබා ගැනීම සඳහා, WAL ගොනු ලිවීමේදී fio වෙතින් වන පරීක්ෂණ ලිවීමේ භාරය etcd වෙතින් වන සත්‍ය භාරයට හැකි තරම් ආසන්න බව ඔබ සහතික කර ගත යුතුය.

එබැවින්, fio, අවම වශයෙන්, ගොනුවට අඛණ්ඩව ලිවීම් මාලාවක් ආකාරයෙන් බරක් සෑදිය යුතුය, සෑම ලිවීමක්ම පද්ධති ඇමතුමකින් සමන්විත වේ. ලියන්නfdatasync පද්ධති ඇමතුම අනුගමනය කරයි. fio වෙත අනුක්‍රමික ලිවීම් සඳහා --rw=write විකල්පය අවශ්‍ය වේ. fio සඳහා ලිවීමේදී ලිවීමේ පද්ධති ඇමතුම භාවිතා කිරීමට, ඒ වෙනුවට ලියන්න, ඔබ --ioengine=සමමුහුර්ත පරාමිතිය සඳහන් කළ යුතුය. අවසාන වශයෙන්, එක් එක් ලිවීමෙන් පසුව fdatasync ඇමතීමට, ඔබ --fdatasync=1 පරාමිතිය එකතු කළ යුතුය. මෙම උදාහරණයේ ඇති අනෙකුත් විකල්ප දෙක (--size සහ -bs) ස්ක්‍රිප්ට්-විශේෂිත වේ. ඊළඟ කොටසේදී, අපි ඔබට ඒවා සකසන්නේ කෙසේදැයි පෙන්වන්නෙමු.

ඇයි හරියටම fio සහ අපි එය පිහිටුවීමට ඉගෙන ගත්තේ කෙසේද

මෙම ලිපියෙන් අපි සැබෑ නඩුවක් විස්තර කරමු. අපිට පොකුරක් තියෙනවා කුබර්නෙට්ස් v1.13 අපි Prometheus සමඟ නිරීක්ෂණය කළෙමු. etcd v3.2.24 SSD එකක සත්කාරකත්වය ලබා දී ඇත. Etcd මෙට්‍රික්ස් පොකුර කිසිවක් නොකරන විට පවා fdatasync ප්‍රමාදයන් ඉතා ඉහළ අගයක් පෙන්නුම් කළේය. ප්‍රමිතික අමුතු වූ අතර ඒවායින් අදහස් කරන්නේ කුමක්දැයි අපි ඇත්ත වශයෙන්ම දැන සිටියේ නැත. පොකුර අථත්‍ය යන්ත්‍ර වලින් සමන්විත විය, ගැටලුව කුමක්දැයි තේරුම් ගැනීමට අවශ්‍ය විය: භෞතික SSD වල හෝ අථත්‍යකරණ ස්ථරයේ. මීට අමතරව, අපි බොහෝ විට දෘඪාංග සහ මෘදුකාංග වින්යාසය සඳහා වෙනස්කම් සිදු කළ අතර, ඒවායේ ප්රතිඵල ඇගයීමට ක්රමයක් අවශ්ය විය. අපට සෑම වින්‍යාසයකම etcd ධාවනය කර Prometheus metrics දෙස බැලිය හැක, නමුත් එය කරදර වැඩියි. අපි නිශ්චිත වින්‍යාසයක් ඇගයීමට තරමක් සරල ක්‍රමයක් සොයමින් සිටියෙමු. අපට etcd වලින් Prometheus metrics නිවැරදිව තේරුම් ගත හැකිදැයි පරීක්ෂා කිරීමට අවශ්‍ය විය.

නමුත් මේ සඳහා ගැටළු දෙකක් විසඳිය යුතු විය. පළමුව, WAL වෙත ලිවීමේදී etcd නිර්මාණය කරන I/O load එක මොන වගේද? භාවිතා කරන පද්ධති ඇමතුම් මොනවාද? වාර්තාවල ප්රමාණය කොපමණද? දෙවනුව, අපි මෙම ප්‍රශ්නවලට පිළිතුරු දෙන්නේ නම්, අපි fio සමඟ සමාන වැඩ ප්‍රමාණයක් ප්‍රතිනිෂ්පාදනය කරන්නේ කෙසේද? fio යනු බොහෝ විකල්ප සහිත ඉතා නම්‍යශීලී මෙවලමක් බව අමතක නොකරන්න. අපි ගැටළු දෙකම එක ප්රවේශයකින් විසඳා ඇත - විධාන භාවිතා කිරීම lsof и තීරය. lsof ක්‍රියාවලිය විසින් භාවිතා කරන සියලුම ගොනු විස්තර සහ ඒවාට සම්බන්ධ ගොනු ලැයිස්තුගත කරයි. සහ සරලව, ඔබට දැනටමත් ක්‍රියාත්මක වන ක්‍රියාවලියක් පරීක්ෂා කළ හැකිය, නැතහොත් ක්‍රියාවලියක් ආරම්භ කර එය පරීක්ෂා කළ හැකිය. strace පරීක්ෂා කරන ක්‍රියාවලියෙන් සියලුම පද්ධති ඇමතුම් මුද්‍රණය කරයි (සහ එහි ළමා ක්‍රියාවලි). etcd එකම ප්‍රවේශයක් ගන්නා බැවින් දෙවැන්න ඉතා වැදගත් වේ.

පොකුරේ බරක් නොමැති විට Kubernetes සඳහා etcd සේවාදායකය ගවේෂණය කිරීමට අපි මුලින්ම strace භාවිතා කළෙමු. සියලුම WAL වාර්තා පාහේ එකම ප්‍රමාණයේ බව අපි දුටුවෙමු: බයිට් 2200–2400. එබැවින්, පෝස්ට් ආරම්භයේ ඇති විධානය තුළ, අපි -bs=2300 පරාමිතිය සඳහන් කළෙමු (bs යනු එක් එක් fio ප්රවේශය සඳහා බයිට් වල ප්රමාණය). etcd ප්‍රවේශයේ ප්‍රමාණය etcd අනුවාදය, බෙදා හැරීම, පරාමිති අගයන් යනාදිය මත රඳා පවතින අතර fdatasync කාලසීමාවට බලපාන බව සලකන්න. ඔබට සමාන අවස්ථාවක් තිබේ නම්, නිශ්චිත සංඛ්‍යා සොයා ගැනීමට ඔබේ etcd ක්‍රියාවලි ස්ට්‍රේස් සමඟින් පරීක්ෂා කරන්න.

ඉන්පසු, etcd ගොනු පද්ධතිය කරන්නේ කුමක්ද යන්න පිළිබඳ හොඳ අදහසක් ලබා ගැනීම සඳහා, අපි එය strace සහ -ffttT විකල්ප සමඟ ආරම්භ කළෙමු. එබැවින් අපි ළමා ක්‍රියාවලීන් පරීක්ෂා කර ඒ සෑම එකකම ප්‍රතිදානය වෙනම ගොනුවක සටහන් කිරීමටත්, එක් එක් පද්ධති ඇමතුම් ආරම්භය සහ කාලසීමාව පිළිබඳ සවිස්තරාත්මක වාර්තා ලබා ගැනීමටත් උත්සාහ කළෙමු. ස්ට්‍රේස් ප්‍රතිදානය පිළිබඳ අපගේ විශ්ලේෂණය තහවුරු කිරීමට සහ කුමන කාර්යය සඳහා කුමන ගොනු විස්තරය භාවිතා කරන්නේ දැයි බැලීමට අපි lsof භාවිතා කළෙමු. එබැවින් ස්ට්රේස් ආධාරයෙන්, ඉහත පෙන්වා ඇති ප්රතිඵල ලබා ගන්නා ලදී. wal_fsync_duration_seconds from etcd WAL ගොනු විස්තර සහිත fdatasync ඇමතුම් සමඟ අනුකූල වන බව සමමුහුර්ත කාල සංඛ්‍යාලේඛන තහවුරු කළේය.

අපි fio සඳහා ප්‍රලේඛනය හරහා ගොස් අපගේ ස්ක්‍රිප්ට් සඳහා විකල්ප තෝරා ගත්තෙමු, එවිට fio etcd වලට සමාන බරක් ජනනය කරයි. අපි etcd වලට සමාන strace සිට fio ධාවනය කිරීමෙන් පද්ධති ඇමතුම් සහ ඒවායේ කාලසීමාව ද පරීක්ෂා කළෙමු.

අපි fio වෙතින් සම්පූර්ණ I/O භාරය නියෝජනය කිරීමට --size පරාමිතියෙහි අගය ප්‍රවේශමෙන් තෝරාගෙන ඇත. අපගේ නඩුවේදී, ගබඩාවට ලියා ඇති මුළු බයිට් ගණන මෙයයි. එය ලිවීමේ (සහ fdatasync) පද්ධති ඇමතුම් ගණනට සෘජුව සමානුපාතික විය. bs හි නිශ්චිත අගයක් සඳහා, fdatasync ඇමතුම් ගණන = විශාලත්වය/bs. අපි ප්‍රතිශතය ගැන උනන්දු වූ නිසා, අපට සහතික වීමට ප්‍රමාණවත් සාම්පල තිබිය යුතු අතර, අපට 10^4 ප්‍රමාණවත් වනු ඇතැයි අපි ගණනය කළෙමු (එය මෙබිබයිට් 22කි). --size කුඩා නම්, පිටස්තර ඇති විය හැක (උදාහරණයක් ලෙස, fdatasync ඇමතුම් කිහිපයක් වෙනදාට වඩා වැඩි කාලයක් ගත වන අතර 99 වැනි ප්‍රතිශතයට බලපායි).

ඔබම උත්සාහ කරන්න

අපි ඔබට fio භාවිතා කරන්නේ කෙසේද සහ etcd හොඳින් ක්‍රියා කිරීමට තරම් ආචයනය වේගවත් දැයි බලන්න ආකාරය පෙන්වා දුන්නෙමු. දැන් ඔබට SSD ආචයනය සහිත අතථ්‍ය යන්ත්‍ර භාවිතා කර ඔබටම එය අත්හදා බැලිය හැක IBM වළාකුල.

මූලාශ්රය: www.habr.com