etcd-এর জন্য পর্যাপ্ত পারফরম্যান্সের জন্য fio দিয়ে ডিস্কগুলি কীভাবে পরীক্ষা করবেন

বিঃদ্রঃ. অনুবাদ: এই নিবন্ধটি etcd ডাটাবেসের অপারেশন সম্পর্কিত একটি বাস্তব সমস্যার সমাধানের সন্ধানে IBM ক্লাউড ইঞ্জিনিয়ারদের দ্বারা পরিচালিত একটি ছোট-গবেষণার ফলাফল। একটি অনুরূপ কাজ আমাদের জন্য প্রাসঙ্গিক ছিল, তবে, লেখকদের প্রতিফলন এবং কর্মের কোর্স একটি বিস্তৃত প্রসঙ্গে আকর্ষণীয় হতে পারে।

সম্পূর্ণ নিবন্ধের সংক্ষিপ্ত সারাংশ: fio এবং etcd

একটি etcd ক্লাস্টারের কর্মক্ষমতা অন্তর্নিহিত স্টোরেজের গতির উপর অত্যন্ত নির্ভরশীল। etcd কর্মক্ষমতা নিরীক্ষণের জন্য বিভিন্ন প্রমিথিউস মেট্রিক্স রপ্তানি করে। তাদের মধ্যে একজন wal_fsync_duration_seconds. ইত্যাদি জন্য ডকুমেন্টেশন এটা বলেএই মেট্রিকের 99 তম পার্সেন্টাইল 10 ms এর বেশি না হলে সেই স্টোরেজটিকে যথেষ্ট দ্রুত বিবেচনা করা যেতে পারে...

আপনি যদি লিনাক্স মেশিনে একটি etcd ক্লাস্টার সেট আপ করার বিষয়ে বিবেচনা করছেন এবং ড্রাইভগুলি (যেমন SSD) যথেষ্ট দ্রুত কিনা তা পরীক্ষা করতে চান, আমরা জনপ্রিয় I/O টেস্টার ব্যবহার করার পরামর্শ দিই fio. নিম্নলিখিত কমান্ডটি চালানোর জন্য এটি যথেষ্ট (ডিরেক্টরি 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 সম্পর্কে আরও

ওয়াল ইত্যাদি সম্পর্কে কয়েকটি শব্দ

সাধারণত, ডাটাবেস ব্যবহার করে সক্রিয় লগিং (লেখা-আগামী লগিং, WAL)। etcd এছাড়াও প্রভাবিত হয়। WAL এর একটি আলোচনা এই নিবন্ধের সুযোগের বাইরে, কিন্তু আমাদের উদ্দেশ্যে, আপনাকে যা জানা দরকার তা হল প্রতিটি etcd ক্লাস্টার সদস্য WAL কে স্থায়ী সঞ্চয় করে রাখে। etcd কিছু কী-ভ্যালু স্টোরেজ অপারেশন (যেমন আপডেট) WAL-এ সেগুলি চালানোর আগে লেখে। যদি একটি নোড ক্র্যাশ হয় এবং স্ন্যাপশটের মধ্যে পুনরায় চালু হয়, etcd WAL এর বিষয়বস্তুর উপর ভিত্তি করে আগের স্ন্যাপশট থেকে লেনদেন পুনরুদ্ধার করতে পারে।

এইভাবে, প্রতিবার একজন ক্লায়েন্ট KV স্টোরে একটি কী যোগ করে বা বিদ্যমান কী-এর মান আপডেট করে, etcd WAL-তে অপারেশনের বিবরণ যোগ করে, যা স্থায়ী স্টোরে একটি নিয়মিত ফাইল। etcd অবশ্যই 100% নিশ্চিত হতে হবে যে WAL এন্ট্রি আসলেই এগিয়ে যাওয়ার আগে সংরক্ষিত হয়েছে। লিনাক্সে এটি অর্জন করতে, সিস্টেম কল ব্যবহার করা যথেষ্ট নয় write, যেহেতু ফিজিক্যাল মিডিয়াতে লেখার অপারেশনে দেরি হতে পারে। উদাহরণস্বরূপ, লিনাক্স কিছু সময়ের জন্য একটি ইন-মেমরি কার্নেল ক্যাশে (যেমন, পৃষ্ঠা ক্যাশে) একটি 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 বিভিন্ন উপায়ে ঘটতে পারে: সিঙ্ক/অসিঙ্ক, অনেকগুলি বিভিন্ন সিস্কাল ক্লাস, এবং আরও অনেক কিছু। মুদ্রার অপর পিঠটা হল সেটা fio ব্যবহার করা অত্যন্ত কঠিন। ইউটিলিটির অনেকগুলি পরামিতি রয়েছে এবং তাদের মানগুলির বিভিন্ন সমন্বয় সম্পূর্ণ ভিন্ন ফলাফলের দিকে নিয়ে যায়। etcd এর জন্য একটি যুক্তিসঙ্গত অনুমান পেতে, আপনাকে নিশ্চিত করতে হবে যে fio দ্বারা উত্পন্ন লেখার লোডটি etcd এর WAL ফাইল লেখার লোডের যতটা সম্ভব কাছাকাছি:

• এর মানে উৎপন্ন হয়েছে fio লোডটি কমপক্ষে ফাইলটিতে ধারাবাহিক লেখার একটি সিরিজ হওয়া উচিত, যেখানে প্রতিটি লেখায় একটি সিস্টেম কল থাকে writeঅনুসরণ করে fdatasync.
• ক্রমিক লেখা সক্রিয় করতে, আপনাকে অবশ্যই পতাকা নির্দিষ্ট করতে হবে --rw=write.
• যে fio কল ব্যবহার করে লিখেছেন write (অন্যান্য সিস্টেম কলের পরিবর্তে - উদাহরণস্বরূপ, pwrite), পতাকা ব্যবহার করুন --ioengine=sync.
• অবশেষে, পতাকা --fdatasync=1 প্রত্যেকের জন্য গ্যারান্টি দেয় write হতে হবে fdatasync.
• আমাদের উদাহরণে অন্য দুটি পরামিতি হল: --size и --bs - নির্দিষ্ট ব্যবহারের ক্ষেত্রে নির্ভর করে পরিবর্তিত হতে পারে। পরবর্তী বিভাগে তাদের কনফিগারেশন বর্ণনা করা হবে.

আমরা কেন fio বেছে নিয়েছি এবং কীভাবে এটি সেট আপ করতে হয় তা শিখেছি

এই নোটটি আমরা সম্মুখীন একটি বাস্তব কেস থেকে আসে. প্রমিথিউসের উপর নজরদারি সহ আমাদের কুবারনেটস v1.13-এ একটি ক্লাস্টার ছিল। SSD গুলি etcd v3.2.24 এর স্টোরেজ হিসাবে ব্যবহৃত হত। Etcd মেট্রিক্স খুব বেশি বিলম্ব দেখিয়েছে fdatasync, এমনকি যখন ক্লাস্টার নিষ্ক্রিয় ছিল। আমাদের কাছে, এই মেট্রিক্সগুলি খুব সন্দেহজনক বলে মনে হয়েছিল, এবং আমরা নিশ্চিত নই যে তারা ঠিক কী প্রতিনিধিত্ব করে। উপরন্তু, ক্লাস্টারে ভার্চুয়াল মেশিন রয়েছে, তাই ভার্চুয়ালাইজেশনের কারণে বিলম্ব হয়েছে নাকি SSD এর জন্য দায়ী ছিল তা বলা সম্ভব হয়নি।

উপরন্তু, আমরা হার্ডওয়্যার এবং সফ্টওয়্যার কনফিগারেশনের বিভিন্ন পরিবর্তন বিবেচনা করেছি, তাই আমাদের তাদের মূল্যায়ন করার একটি উপায় প্রয়োজন। অবশ্যই, প্রতিটি কনফিগারেশনে 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 etcd ম্যাচ কল থেকে fdatasync WAL ফাইল বর্ণনাকারী সহ।

দিয়ে তৈরি করতে fio etcd থেকে অনুরূপ একটি কাজের চাপ, ইউটিলিটির ডকুমেন্টেশন অধ্যয়ন করা হয়েছিল এবং আমাদের কাজের জন্য উপযুক্ত পরামিতিগুলি নির্বাচন করা হয়েছিল। আমরা যাচাই করেছি যে সঠিক সিস্টেম কলগুলি চলছে এবং চলমান দ্বারা তাদের সময়কাল নিশ্চিত করেছি৷ fio থেকে strace (যেমন এটি ইত্যাদির ক্ষেত্রে করা হয়েছিল)।

প্যারামিটারের মান নির্ধারণে বিশেষ মনোযোগ দেওয়া হয়েছিল --size. এটি fio ইউটিলিটি দ্বারা উত্পন্ন মোট I/O লোড উপস্থাপন করে। আমাদের ক্ষেত্রে, এটি মিডিয়াতে লেখা মোট বাইট সংখ্যা। এটি কলের সংখ্যার সাথে সরাসরি সমানুপাতিক write (এবং fdatasync) একটি নির্দিষ্ট জন্য bs কল সংখ্যা fdatasync হয় size / bs.

যেহেতু আমরা শতাংশে আগ্রহী ছিলাম, তাই আমরা চেয়েছিলাম নমুনার সংখ্যা পরিসংখ্যানগতভাবে তাৎপর্যপূর্ণ হওয়ার জন্য যথেষ্ট বড় হোক। এবং এটি সিদ্ধান্ত নিয়েছে 10^4 (যা 22 MB এর আকারের সাথে মিলে যায়) যথেষ্ট হবে। ছোট প্যারামিটার মান --size আরও স্পষ্ট শব্দ দিয়েছে (উদাহরণস্বরূপ, কল fdatasync, যা স্বাভাবিকের চেয়ে অনেক বেশি সময় নেয় এবং 99 তম শতাংশকে প্রভাবিত করে)।

এটা আপনার উপর নির্ভর করছে

নিবন্ধটি কীভাবে ব্যবহার করবেন তা দেখায় fio etcd-এর সাথে ব্যবহারের উদ্দেশ্যে মিডিয়া যথেষ্ট দ্রুত কিনা তা বিচার করতে পারে। এখন এটা আপনার উপর নির্ভর করে! আপনি পরিষেবাতে SSD-ভিত্তিক স্টোরেজ সহ ভার্চুয়াল মেশিনগুলি অন্বেষণ করতে পারেন আইবিএম ক্লাউড.

অনুবাদক থেকে PS

রেডিমেড ব্যবহারের ক্ষেত্রে সঙ্গে fio অন্যান্য কাজের জন্য, দেখুন ডকুমেন্টেশন অথবা সরাসরি প্রকল্প সংগ্রহস্থল (ডকুমেন্টেশনে উল্লিখিত তুলনায় তাদের অনেক বেশি আছে)।

অনুবাদক থেকে PPS

আমাদের ব্লগেও পড়ুন:

• «etcd 3.4.3: স্টোরেজ নির্ভরযোগ্যতা এবং নিরাপত্তা অধ্যয়ন";
• «সরাসরি etcd Kubernetes ক্লাস্টারে ডেটা নিয়ে আমাদের অভিজ্ঞতা (K8s API ছাড়া)";
• «কুবারনেটসের অপারেশনে 6টি বিনোদনমূলক সিস্টেম বাগ [এবং তাদের সমাধান]».

উত্স: www.habr.com