سرعت ذخیره سازی مناسب برای etcd؟ بیا از فیو بپرسیم

داستان کوتاهی در مورد fio و etc

عملکرد خوشه etcd تا حد زیادی به عملکرد ذخیره سازی آن بستگی دارد. etcd برخی از معیارها را صادر می کند تیتان فرزند پاپتوسبرای ارائه اطلاعات عملکرد ذخیره سازی مورد نظر. به عنوان مثال، متریک wal_fsync_duration_seconds. مستندات برای etcd می گوید: برای اینکه ذخیره سازی به اندازه کافی سریع در نظر گرفته شود، صدک 99 این متریک باید کمتر از 10 میلی ثانیه باشد. اگر قصد دارید یک کلاستر etcd را روی ماشین های لینوکس اجرا کنید و می خواهید ارزیابی کنید که آیا فضای ذخیره سازی شما به اندازه کافی سریع است (مثلا SSD)، می توانید از آن استفاده کنید. نخ یک ابزار محبوب برای آزمایش عملیات I/O است. دستور زیر را اجرا کنید، جایی که test-data دایرکتوری زیر نقطه نصب حافظه است:

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

شما فقط باید به نتایج نگاه کنید و بررسی کنید که صدک 99 مدت زمان است fdatasync کمتر از 10 میلی ثانیه اگر چنین است، ذخیره سازی نسبتاً سریعی دارید. در اینجا یک نمونه از نتایج است:

  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 را یاد گرفتیم.
• در طول آزمایش، تمام بار ورودی/خروجی از fio می آید. در یک سناریوی واقعی، احتمالاً درخواست‌های نوشتن دیگری به جز موارد مربوط به wal_fsync_duration_seconds وارد فضای ذخیره‌سازی می‌شوند. بار اضافی مقدار wal_fsync_duration_seconds را افزایش می دهد. بنابراین اگر صدک 99 نزدیک به 10 میلی‌ثانیه باشد، سرعت ذخیره‌سازی شما تمام می‌شود.
• نسخه را بگیرید نخ کمتر از 3.5 نیست (قبلی ها صدک مدت fdatasync را نشان نمی دهند).
• در بالا فقط یک تکه از نتایج fio است.

داستان طولانی در مورد fio و etcd

WAL در etcd چیست؟

معمولا از پایگاه های داده استفاده می شود ثبت پیش‌نویس; 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 کمتر از 10 میلی‌ثانیه برای نوشتن در فایل WAL طول بکشد، ذخیره‌سازی به اندازه کافی سریع در نظر گرفته می‌شود. معیارهای مفید دیگری برای ذخیره سازی وجود دارد، اما در این پست ما فقط در مورد این معیار صحبت می کنیم.

تخمین ذخیره سازی با fio

اگر باید ارزیابی کنید که آیا فضای ذخیره‌سازی شما برای etcd مناسب است، از fio، یک ابزار بسیار محبوب تست بار ورودی/خروجی استفاده کنید. لازم به یادآوری است که عملیات دیسک می تواند بسیار متفاوت باشد: همزمان و ناهمزمان، بسیاری از کلاس های فراخوانی سیستم، و غیره. در نتیجه، استفاده از fio بسیار دشوار است. پارامترهای زیادی دارد و ترکیب های مختلف مقادیر آن ها بار کاری ورودی/خروجی بسیار متفاوتی را تولید می کند. برای بدست آوردن ارقام کافی برای etcd، باید مطمئن شوید که بار نوشتن آزمایشی از fio تا حد امکان به بار واقعی etcd در هنگام نوشتن فایل های WAL نزدیک است.

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

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

در این پست یک مورد واقعی را شرح می دهیم. ما یک خوشه داریم کوبرنیتس نسخه 1.13 که ما با پرومتئوس نظارت کردیم. etcd v3.2.24 بر روی یک SSD میزبانی شد. معیارهای Etcd نشان داد که تاخیرهای fdatasync بسیار زیاد است، حتی زمانی که خوشه هیچ کاری انجام نمی داد. معیارها عجیب بودند و ما واقعاً معنی آنها را نمی دانستیم. این خوشه از ماشین های مجازی تشکیل شده بود، لازم بود بفهمیم مشکل چیست: در SSD های فیزیکی یا در لایه مجازی سازی. علاوه بر این، ما اغلب تغییراتی در پیکربندی سخت افزار و نرم افزار ایجاد می کردیم و به روشی برای ارزیابی نتایج آنها نیاز داشتیم. ما می‌توانیم etcd را در هر پیکربندی اجرا کنیم و به معیارهای Prometheus نگاه کنیم، اما این خیلی دردسر است. ما به دنبال یک راه نسبتا ساده برای ارزیابی یک پیکربندی خاص بودیم. می‌خواستیم بررسی کنیم که آیا معیارهای Prometheus را از etcd به درستی درک می‌کنیم.

اما برای این کار دو مشکل باید حل می شد. ابتدا، بارگذاری ورودی/خروجی که etcd هنگام نوشتن در WAL ایجاد می‌کند، چگونه به نظر می‌رسد؟ از چه فراخوانی های سیستمی استفاده می شود؟ اندازه رکوردها چقدر است؟ دوم، اگر به این سؤالات پاسخ دهیم، چگونه یک حجم کاری مشابه را با fio بازتولید کنیم؟ فراموش نکنید که fio یک ابزار بسیار انعطاف پذیر با گزینه های زیادی است. ما هر دو مشکل را با یک رویکرد حل کردیم - با استفاده از دستورات lsof и تسمه. lsof تمام توصیفگرهای فایل استفاده شده توسط فرآیند و فایل های مرتبط با آنها را فهرست می کند. و با strace می توانید یک فرآیند از قبل در حال اجرا را بررسی کنید یا یک فرآیند را شروع کنید و آن را بررسی کنید. strace همه فراخوانی های سیستم را از فرآیند مورد بررسی (و پردازش های فرزند آن) چاپ می کند. مورد دوم بسیار مهم است، زیرا etcd رویکرد مشابهی دارد.

ما برای اولین بار از strace برای کاوش سرور etcd برای Kubernetes زمانی که هیچ باری روی خوشه وجود نداشت استفاده کردیم. ما دیدیم که تقریباً تمام رکوردهای WAL تقریباً یک اندازه بودند: 2200-2400 بایت. بنابراین در دستور ابتدای پست، پارامتر -bs=2300 را مشخص کردیم (bs به معنای اندازه بر حسب بایت برای هر ورودی fio است). توجه داشته باشید که اندازه ورودی etcd به نسخه etcd، توزیع، مقادیر پارامتر و غیره بستگی دارد و بر مدت زمان fdatasync تأثیر می گذارد. اگر سناریوی مشابهی دارید، فرآیندهای etcd خود را با strace بررسی کنید تا اعداد دقیق را بیابید.

سپس برای اینکه بفهمیم فایل سیستم etcd چه می کند، آن را با strace و گزینه های -ffttT شروع کردیم. بنابراین سعی کردیم پردازش های فرزند را بررسی کرده و خروجی هر یک از آنها را در یک فایل جداگانه ثبت کنیم و همچنین گزارش های دقیقی از شروع و مدت زمان هر تماس سیستمی دریافت کنیم. ما از lsof برای تأیید تجزیه و تحلیل خود از خروجی strace استفاده کردیم و ببینیم کدام توصیفگر فایل برای چه هدفی استفاده شده است. بنابراین با کمک strace نتایج نشان داده شده در بالا به دست آمد. آمار زمان همگام‌سازی تأیید کرد که wal_fsync_duration_seconds از etcd با تماس‌های fdatasync با توصیف‌گرهای فایل WAL سازگار است.

ما مستندات fio را مرور کردیم و گزینه‌هایی را برای اسکریپت خود انتخاب کردیم تا fio باری مشابه etcd ایجاد کند. ما همچنین تماس های سیستمی و مدت زمان آنها را با اجرای fio از strace، مشابه etcd بررسی کردیم.

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

خودتان آن را امتحان کنید

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

منبع: www.habr.com