🥇نحوه بررسی دیسک ها با fio برای کارایی کافی برای etcd

توجه داشته باشید. ترجمه: این مقاله نتیجه یک تحقیق کوچک است که توسط مهندسان IBM Cloud در جستجوی راه حلی برای مشکل واقعی مربوط به عملکرد پایگاه داده etcd انجام شده است. کار مشابهی برای ما مرتبط بود، با این حال، سیر تأملات و اقدامات نویسندگان ممکن است در یک زمینه گسترده تر جالب باشد.

خلاصه ای از کل مقاله: fio و etc

عملکرد یک خوشه etcd به شدت به سرعت ذخیره سازی زیرین بستگی دارد. etcd معیارهای مختلف Prometheus را برای نظارت بر عملکرد صادر می کند. یکی از آنها است wal_fsync_duration_seconds. در مستندات برای etcd می گویداگر صدک 99 این متریک از 10 میلی ثانیه تجاوز نکند، می توان ذخیره سازی را به اندازه کافی سریع در نظر گرفت.

اگر قصد راه‌اندازی یک خوشه etcd در ماشین‌های لینوکس را دارید و می‌خواهید آزمایش کنید که آیا درایوها (مانند SSD) به اندازه کافی سریع هستند، توصیه می‌کنیم از تستر معروف ورودی/خروجی به نام استفاده کنید. نخ. کافی است دستور زیر را اجرا کنید (دایرکتوری test-data باید در پارتیشن نصب شده درایو تست شده قرار گیرد:

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

فقط باید به خروجی نگاه کرد و بررسی کرد که آیا صدک 99 مطابقت دارد یا خیر fdatasync در 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]

چند نکته:

در مثال بالا، پارامترها را تنظیم کرده ایم --size и --bs برای یک مورد خاص تا نتیجه ای معنادار از fio، مقادیر مناسب برای مورد استفاده خود را مشخص کنید. نحوه انتخاب آنها در زیر مورد بحث قرار خواهد گرفت.
فقط در حین تست fio زیر سیستم دیسک را بارگذاری می کند. در زندگی واقعی، این احتمال وجود دارد که فرآیندهای دیگری نیز روی دیسک بنویسند (به جز موارد مربوط به wal_fsync_duration_seconds). این بار اضافی می تواند افزایش یابد wal_fsync_duration_seconds. به عبارت دیگر، اگر صدک 99 از تست با fio، فقط کمی کمتر از 10 میلی ثانیه، احتمال خوبی وجود دارد که عملکرد ذخیره سازی کافی نباشد.
برای تست به نسخه نیاز دارید fio کمتر از 3.5 نیست، زیرا نسخه های قدیمی تر نتایج را جمع نمی کنند fdatasync به صورت صدک.
نتیجه گیری فوق تنها گزیده ای کوچک از نتیجه گیری کلی است fio.

بیشتر در مورد fio و etcd

چند کلمه در مورد WALs 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 میلی ثانیه بود. معیارهای دیگر مربوط به ذخیره سازی وجود دارد، اما این مقاله بر روی آن یکی تمرکز خواهد کرد.

ارزش گذاری ذخیره سازی با fio

شما می توانید ارزیابی کنید که آیا یک حافظه خاص برای استفاده با etcd با استفاده از ابزار مناسب است یا خیر نخ - یک تستر I/O محبوب. به خاطر داشته باشید که ورودی/خروجی دیسک می‌تواند به روش‌های مختلفی اتفاق بیفتد: همگام‌سازی/همگام‌سازی، بسیاری از کلاس‌های syscall مختلف و غیره. روی دیگر سکه این است fio استفاده بسیار دشوار است این ابزار دارای پارامترهای زیادی است و ترکیبات مختلف مقادیر آنها به نتایج کاملاً متفاوتی منجر می شود. برای به دست آوردن یک تخمین معقول برای etcd، باید مطمئن شوید که بار نوشتن تولید شده توسط fio تا حد امکان به بار نوشتن فایل WAL etcd نزدیک است:

این بدان معنی است که تولید شده است fio بارگذاری حداقل باید یک سری از نوشتن های متوالی در فایل باشد، جایی که هر نوشتن شامل یک فراخوانی سیستمی است. writeبه دنبال fdatasync.
برای فعال کردن نوشتن متوالی، باید پرچم را مشخص کنید --rw=write.
که fio با استفاده از تماس نوشت write (به جای دیگر فراخوانی های سیستم - برای مثال، pwrite) از پرچم استفاده کنید --ioengine=sync.
بالاخره پرچم --fdatasync=1 تضمین می کند که هر write باید fdatasync.
دو پارامتر دیگر در مثال ما عبارتند از: --size и --bs - ممکن است بسته به مورد استفاده خاص متفاوت باشد. در بخش بعدی تنظیمات آنها توضیح داده خواهد شد.

چرا fio را انتخاب کردیم و چگونه یاد گرفتیم که چگونه آن را راه اندازی کنیم

این یادداشت برگرفته از یک مورد واقعی است که ما با آن مواجه شدیم. ما یک خوشه در Kubernetes نسخه 1.13 با نظارت بر Prometheus داشتیم. SSD به عنوان ذخیره سازی برای etcd نسخه 3.2.24 استفاده شد. معیارهای ETCD تأخیر بسیار بالایی را نشان دادند fdatasync، حتی زمانی که خوشه بیکار بود. برای ما، این معیارها بسیار مشکوک به نظر می رسید و ما مطمئن نبودیم که دقیقاً چه چیزی را نشان می دهند. علاوه بر این، این خوشه متشکل از ماشین های مجازی بود، بنابراین نمی توان گفت که تاخیر به دلیل مجازی سازی است یا SSD مقصر است.

علاوه بر این، ما تغییرات مختلفی را در پیکربندی سخت افزار و نرم افزار در نظر گرفتیم، بنابراین به روشی برای ارزیابی آنها نیاز داشتیم. البته، می‌توان etcd را در هر پیکربندی اجرا کرد و به معیارهای Prometheus مربوطه نگاه کرد، اما این به تلاش قابل توجهی نیاز دارد. آنچه ما نیاز داشتیم یک راه ساده برای ارزیابی یک پیکربندی خاص بود. ما می‌خواستیم درک خود را از معیارهای Prometheus که از etcd بدست می‌آید آزمایش کنیم.

این نیاز به حل دو مشکل داشت:

ابتدا، بار ورودی/خروجی ایجاد شده توسط etcd هنگام نوشتن روی فایل های WAL چگونه است؟ از چه فراخوانی های سیستمی استفاده می شود؟ اندازه بلوک های رکورد چقدر است؟
ثانیاً، فرض کنید برای سؤالات بالا پاسخ داریم. نحوه بازتولید بار مربوطه با fio? گذشته از همه اینها fio - ابزار بسیار انعطاف پذیر با پارامترهای فراوان (به عنوان مثال، این به راحتی قابل تأیید است، اینجا - تقریبا ترجمه.).

ما هر دو مشکل را با یک رویکرد مبتنی بر دستور حل کردیم lsof и strace:

با lsof شما می توانید تمام توصیفگرهای فایل مورد استفاده در فرآیند و همچنین فایل هایی را که به آنها ارجاع می دهند مشاهده کنید.
با strace شما می توانید یک فرآیند در حال اجرا را تجزیه و تحلیل کنید یا یک فرآیند را اجرا کنید و آن را تماشا کنید. این دستور تمام فراخوانی های سیستمی که توسط این فرآیند و در صورت لزوم فرزندان آن انجام می شود را نمایش می دهد. مورد دوم برای فرآیندهایی که در حال فورک هستند مهم است و etcd یکی از این فرآیندها است.

اولین کاری که انجام دادیم استفاده بود strace برای بررسی سرور etcd در خوشه Kubernetes در حالی که بیکار بود.

بنابراین مشخص شد که بلوک های رکورد 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 است. در مورد ما، این تعداد کل بایت های نوشته شده به رسانه است. با تعداد تماس ها نسبت مستقیم دارد write (و fdatasync). برای یک خاص bs تعداد تماس ها fdatasync برابر است size / bs.

از آنجایی که ما به صدک علاقه مند بودیم، می خواستیم تعداد نمونه ها به اندازه کافی بزرگ باشد که از نظر آماری معنی دار باشد. و تصمیم گرفت که 10^4 (که مربوط به حجم 22 مگابایت است) کافی است. مقادیر پارامتر کوچکتر --size صدای واضح تری داد (مثلاً تماس ها fdatasync، که بسیار بیشتر از حد معمول طول می کشد و صدک 99 را تحت تأثیر قرار می دهد).

این به شما بستگی دارد

مقاله نحوه استفاده را نشان می دهد fio می توان قضاوت کرد که آیا رسانه در نظر گرفته شده برای استفاده با etcd به اندازه کافی سریع است. حالا به شما بستگی دارد! می‌توانید ماشین‌های مجازی را با فضای ذخیره‌سازی مبتنی بر SSD در این سرویس کاوش کنید IBM Cloud.

PS از مترجم

با موارد مصرف آماده fio برای کارهای دیگر، نگاه کنید مستندات یا مستقیم به مخازن پروژه (تعداد آنها بسیار بیشتر از آنچه در مستندات ذکر شده است) وجود دارد.

PPS از مترجم

در وبلاگ ما نیز بخوانید:

منبع: www.habr.com

نحوه بررسی دیسک ها با fio برای عملکرد کافی برای etcd