etcd සඳහා ප්‍රමාණවත් කාර්ය සාධනයක් සඳහා fio සමඟ තැටි පරීක්ෂා කරන්නේ කෙසේද

සටහන. පරිවර්තනය.: මෙම ලිපිය IBM Cloud ඉංජිනේරුවන් විසින් etcd දත්ත සමුදායේ ක්‍රියාකාරිත්වය සම්බන්ධ සැබෑ ගැටලුවකට විසඳුමක් සෙවීම සඳහා සිදු කරන ලද කුඩා පර්යේෂණයක ප්‍රතිඵලයකි. ඒ හා සමාන කාර්යයක් අපට අදාළ විය, කෙසේ වෙතත්, කතුවරුන්ගේ පරාවර්තන සහ ක්‍රියාවන් පුළුල් සන්දර්භයක් තුළ සිත්ගන්නා සුළු විය හැකිය.

etcd සඳහා ප්‍රමාණවත් කාර්ය සාධනයක් සඳහා fio සමඟ තැටි පරීක්ෂා කරන්නේ කෙසේද

සම්පූර්ණ ලිපියේ කෙටි සාරාංශය: fio සහ etcd

etcd පොකුරක කාර්ය සාධනය යටින් පවතින ගබඩාවේ වේගය මත බෙහෙවින් රඳා පවතී. etcd කාර්ය සාධනය නිරීක්ෂණය කිරීම සඳහා විවිධ Prometheus මෙට්‍රික් අපනයනය කරයි. ඉන් එකක් වන්නේ wal_fsync_duration_seconds. ආදිය සඳහා ලේඛනවල එය පවසයිමෙම මෙට්‍රික් හි 99 වැනි ප්‍රතිශතය 10 ms නොඉක්මවන්නේ නම් ගබඩා කිරීම ප්‍රමාණවත් තරම් වේගවත් ලෙස සැලකිය හැකිය…

ඔබ Linux යන්ත්‍රවල etcd පොකුරක් පිහිටුවීමට සලකා බලන්නේ නම් සහ ධාවක (SSD වැනි) ප්‍රමාණවත් තරම් වේගවත් දැයි පරීක්ෂා කිරීමට අවශ්‍ය නම්, අපි ජනප්‍රිය I/O පරීක්ෂකය භාවිතා කිරීම නිර්දේශ කරමු. fio. පහත විධානය ක්‍රියාත්මක කිරීම ප්‍රමාණවත් වේ (directory test-data පරීක්ෂා කරන ලද ධාවකයේ සවිකර ඇති කොටසෙහි පිහිටා තිබිය යුතුය):

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

එය ඉතිරිව ඇත්තේ ප්‍රතිදානය දෙස බලා 99 වැනි ප්‍රතිශත ගැලපේදැයි පරීක්ෂා කිරීමට පමණි fdatasync ms 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]

සටහන් කිහිපයක්:

  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). etcd ද බලපායි. WAL පිළිබඳ සාකච්ඡාවක් මෙම ලිපියේ විෂය පථයෙන් ඔබ්බට ය, නමුත් අපගේ අරමුණු සඳහා, ඔබ දැනගත යුතු දෙය නම්, සෑම etcd පොකුරු සාමාජිකයෙකුම WAL අඛණ්ඩ ගබඩාවක ගබඩා කරන බවයි. etcd ඒවා ක්‍රියාත්මක කිරීමට පෙර WAL වෙත සමහර ප්‍රධාන අගය ගබඩා මෙහෙයුම් (යාවත්කාලීන කිරීම් වැනි) ලියයි. ස්නැප්ෂොට් අතර නෝඩයක් කඩා වැටී නැවත ආරම්භ වුවහොත්, etcd හට 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 ms ට වඩා අඩු විය. වෙනත් ගබඩා ආශ්‍රිත ප්‍රමිතික ඇත, නමුත් මෙම ලිපිය ඒ ගැන අවධානය යොමු කරනු ඇත.

fio සමඟ ගබඩාව අගය කිරීම

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

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

අපි fio තෝරාගත්තේ ඇයි සහ එය සකසන්නේ කෙසේදැයි අපි ඉගෙන ගත් ආකාරය

මේ සටහන එන්නේ අප මුහුණ දුන් සත්‍ය සිද්ධියකිනි. අපට ප්‍රොමිතියස් හි නිරීක්ෂණ සමඟ Kubernetes v1.13 හි පොකුරක් තිබුණි. etcd v3.2.24 සඳහා SSDs ගබඩාව ලෙස භාවිතා කරන ලදී. Etcd ප්‍රමිතික ඉතා ඉහළ ප්‍රමාදයන් පෙන්වයි fdatasync, පොකුර නිෂ්ක්‍රීයව තිබියදී පවා. අපට, මෙම ප්‍රමිතික ඉතා සැක සහිත බවක් පෙනුණු අතර, ඒවා හරියටම නියෝජනය කරන්නේ කුමක් දැයි අපට විශ්වාස නැත. මීට අමතරව, පොකුර අථත්‍ය යන්ත්‍ර වලින් සමන්විත වූ බැවින් ප්‍රමාදය අථත්‍යකරණය නිසාද නැතහොත් SSD දොස් පැවරිය යුතුද යන්න පැවසිය නොහැක.

ඊට අමතරව, දෘඪාංග සහ මෘදුකාංග වින්‍යාසයේ විවිධ වෙනස්කම් අපි සලකා බැලුවෙමු, එබැවින් අපට ඒවා ඇගයීමට ක්‍රමයක් අවශ්‍ය විය. ඇත්ත වශයෙන්ම, එක් එක් වින්‍යාසය තුළ etcd ධාවනය කිරීමට සහ අනුරූප Prometheus මෙට්‍රික්ස් බැලීමට හැකි වනු ඇත, නමුත් ඒ සඳහා සැලකිය යුතු උත්සාහයක් අවශ්‍ය වේ. අපට අවශ්‍ය වූයේ නිශ්චිත වින්‍යාසයක් ඇගයීමට සරල ක්‍රමයක් විය. අපිට etcd වලින් එන Prometheus metrics ගැන අපේ අවබෝධය පරීක්ෂා කරන්න ඕන.

මෙය ගැටළු දෙකක් විසඳීමට අවශ්ය විය:

  • පළමුව, WAL ගොනු වලට ලිවීමේදී etcd මගින් ජනනය වන I/O භාරය පෙනෙන්නේ කෙසේද? භාවිතා කරන පද්ධති ඇමතුම් මොනවාද? වාර්තා කුට්ටි ප්රමාණය කොපමණද?
  • දෙවනුව ඉහත ප්‍රශ්න වලට පිළිතුරු අප සතුව ඇතැයි සිතමු. සමඟ අනුරූප බර ප්‍රතිනිෂ්පාදනය කරන්නේ කෙසේද fio? සියල්ලට පසු fio - පරාමිති බහුල සමග අතිශයින්ම නම්යශීලී උපයෝගීතාව (මෙය සත්‍යාපනය කිරීම පහසුය, උදාහරණයක් ලෙස, මෙහි - ආසන්න වශයෙන්. පරිවර්තනය.).

අපි ගැටළු දෙකම එකම විධාන මත පදනම් වූ ප්‍රවේශයකින් විසඳා ගත්තෙමු lsof и strace:

  • සහාය ඇතිව lsof ඔබට ක්‍රියාවලිය මගින් භාවිතා කරන සියලුම ගොනු විස්තර මෙන්ම ඔවුන් යොමු කරන ගොනුද නැරඹිය හැක.
  • සහාය ඇතිව strace ඔබට දැනටමත් ක්‍රියාත්මක වන ක්‍රියාවලියක් විශ්ලේෂණය කිරීමට හෝ ක්‍රියාවලියක් ක්‍රියාත්මක කර එය නැරඹීමට හැකිය. විධානය මඟින් මෙම ක්‍රියාවලිය මගින් සිදු කරන ලද සියලුම පද්ධති ඇමතුම් සහ අවශ්‍ය නම්, එහි පැවත එන්නන් පෙන්වයි. දෙවැන්න දෙබල වන ක්‍රියාවලීන් සඳහා වැදගත් වන අතර etcd යනු එවැනි ක්‍රියාවලියකි.

අපි මුලින්ම කළේ භාවිතා කිරීමයි 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 (එය etcd වලදී සිදු කළ පරිදි).

පරාමිතියේ අගය තීරණය කිරීම සඳහා විශේෂ අවධානය යොමු කරන ලදී --size. එය fio උපයෝගීතාව මගින් ජනනය කරන ලද සම්පූර්ණ I/O භාරය නියෝජනය කරයි. අපගේ නඩුවේදී, මෙය මාධ්යයට ලියන ලද මුළු බයිට් ගණනයි. එය ඇමතුම් ගණනට සෘජුවම සමානුපාතික වේ write (හා fdatasync) නිශ්චිත දෙයක් සඳහා bs ඇමතුම් සංඛ්යාව fdatasync සමානයි size / bs.

අපි ප්‍රතිශතය ගැන උනන්දු වූ නිසා, අපට අවශ්‍ය වූයේ සංඛ්‍යානමය වශයෙන් සැලකිය යුතු තරම් විශාල සාම්පල සංඛ්‍යාවක් තිබීමයි. ඒ වගේම තීරණය කළා 10^4 (22 MB ප්රමාණයට අනුරූප වන) ප්රමාණවත් වනු ඇත. කුඩා පරාමිති අගයන් --size වඩා උච්චාරණ ශබ්දයක් ලබා දුන්නේය (උදාහරණයක් ලෙස, ඇමතුම් fdatasync, එය වෙනදාට වඩා බොහෝ කාලයක් ගත වන අතර 99 වැනි ප්‍රතිශතයට බලපායි).

එය ඔයාට බාරයි

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

පරිවර්තකගෙන් PS

සූදානම් කළ භාවිත අවස්ථා සමඟ fio වෙනත් කාර්යයන් සඳහා, බලන්න ලියකියවිලි හෝ සෘජුවම ව්යාපෘති ගබඩා (ලේඛනවල සඳහන් කර ඇති ඒවාට වඩා බොහෝ ඒවා තිබේ).

පරිවර්තක වෙතින් PPS

අපගේ බ්ලොග් අඩවියේ ද කියවන්න:

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

අදහස් එක් කරන්න