ইত্যাদির জন্য উপযুক্ত স্টোরেজ গতি? এর fio জিজ্ঞাসা করা যাক

fio এবং etcd সম্পর্কে একটি ছোট গল্প

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

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

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

এই পোস্টে, আমরা একটি বাস্তব ঘটনা বর্ণনা. আমরা একটি ক্লাস্টার আছে Kubernetes v1.13 যা আমরা প্রমিথিউসের সাথে পর্যবেক্ষণ করেছি। etcd v3.2.24 একটি SSD তে হোস্ট করা হয়েছিল। Etcd মেট্রিক্স fdatasync লেটেন্সি খুব বেশি দেখিয়েছে, এমনকি যখন ক্লাস্টার কিছুই করছে না। মেট্রিকগুলি অদ্ভুত ছিল এবং আমরা সত্যিই জানতাম না যে তারা কী বোঝায়। ক্লাস্টারে ভার্চুয়াল মেশিন রয়েছে, সমস্যাটি কী তা বোঝার প্রয়োজন ছিল: শারীরিক এসএসডি বা ভার্চুয়ালাইজেশন স্তরে। উপরন্তু, আমরা প্রায়ই হার্ডওয়্যার এবং সফ্টওয়্যার কনফিগারেশন পরিবর্তন করেছি, এবং আমাদের তাদের ফলাফল মূল্যায়ন করার একটি উপায় প্রয়োজন। আমরা প্রতিটি কনফিগারেশনে etcd চালাতে পারি এবং প্রমিথিউস মেট্রিক্সের দিকে তাকাতে পারি, তবে এটি খুব বেশি ঝামেলার। আমরা একটি নির্দিষ্ট কনফিগারেশন মূল্যায়ন করার জন্য একটি মোটামুটি সহজ উপায় খুঁজছিলাম. আমরা etcd থেকে প্রমিথিউস মেট্রিক্স সঠিকভাবে বুঝি কিনা তা পরীক্ষা করতে চেয়েছিলাম।

তবে এর জন্য দুটি সমস্যার সমাধান করতে হয়েছিল। প্রথমত, WAL-তে লেখার সময় etcd যে I/O লোড তৈরি করে তা কেমন দেখায়? কি সিস্টেম কল ব্যবহার করা হয়? রেকর্ডের আকার কত? দ্বিতীয়ত, আমরা যদি এই প্রশ্নের উত্তর দিই, তাহলে আমরা কীভাবে ফিওর সাথে একই ধরনের কাজের চাপ পুনরুত্পাদন করব? ভুলে যাবেন না যে fio অনেক বিকল্প সহ একটি খুব নমনীয় টুল। আমরা উভয় সমস্যা এক পদ্ধতিতে সমাধান করেছি - কমান্ড ব্যবহার করে lsof и স্ট্রেস. lsof প্রক্রিয়া দ্বারা ব্যবহৃত সমস্ত ফাইল বর্ণনাকারী এবং তাদের সম্পর্কিত ফাইলগুলি তালিকাভুক্ত করে। এবং স্ট্রেস দিয়ে, আপনি ইতিমধ্যে চলমান একটি প্রক্রিয়া পরীক্ষা করতে পারেন, বা একটি প্রক্রিয়া শুরু করে এটি পরীক্ষা করতে পারেন। স্ট্রেস পরীক্ষা করা প্রক্রিয়া (এবং এর চাইল্ড প্রসেস) থেকে সমস্ত সিস্টেম কল প্রিন্ট করে। পরেরটি খুবই গুরুত্বপূর্ণ, যেহেতু etcd শুধু একটি অনুরূপ পদ্ধতি গ্রহণ করছে।

যখন ক্লাস্টারে কোন লোড ছিল না তখন আমরা Kubernetes-এর জন্য etcd সার্ভার অন্বেষণ করতে প্রথমে স্ট্রেস ব্যবহার করেছি। আমরা দেখেছি যে প্রায় সমস্ত WAL রেকর্ড প্রায় একই আকারের ছিল: 2200-2400 বাইট। তাই, পোস্টের শুরুতে কমান্ডে, আমরা প্যারামিটারটি নির্দিষ্ট করেছি -bs=2300 (bs মানে প্রতিটি fio এন্ট্রির জন্য বাইটে আকার)। নোট করুন যে etcd এন্ট্রির আকার etcd সংস্করণ, বিতরণ, পরামিতি মান ইত্যাদির উপর নির্ভর করে এবং fdatasync সময়কালকে প্রভাবিত করে। আপনার যদি অনুরূপ দৃশ্য থাকে, সঠিক সংখ্যা খুঁজে বের করতে স্ট্রেস সহ আপনার etcd প্রক্রিয়াগুলি পরীক্ষা করুন।

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

আমরা fio-এর জন্য ডকুমেন্টেশনের মধ্য দিয়ে গিয়েছিলাম এবং আমাদের স্ক্রিপ্টের জন্য বিকল্পগুলি বেছে নিয়েছিলাম যাতে fio etcd-এর মতো লোড তৈরি করে। আমরা etcd-এর মতো strace থেকে fio চালিয়ে সিস্টেম কল এবং তাদের সময়কালও পরীক্ষা করেছি।

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

নিজে চেষ্টা করে দেখুন

আমরা আপনাকে দেখিয়েছি কিভাবে fio ব্যবহার করতে হয় এবং উচ্চ কর্মক্ষমতা ইত্যাদির জন্য স্টোরেজের যথেষ্ট গতি আছে কিনা তা দেখুন। এখন আপনি এটি ব্যবহার করে নিজের জন্য চেষ্টা করতে পারেন, উদাহরণস্বরূপ, SSD স্টোরেজ সহ ভার্চুয়াল মেশিন আইবিএম ক্লাউড.

উত্স: www.habr.com