ProHoster > بلوق > إدارة > كيفية التحقق من الأقراص باستخدام fio للحصول على أداء كافٍ لـ etcd

كيفية التحقق من الأقراص باستخدام fio للحصول على أداء كافٍ لـ etcd

ملحوظة. ترجمة.: هذه المقالة هي نتيجة بحث صغير أجراه مهندسو IBM Cloud بحثًا عن حل لمشكلة حقيقية تتعلق بتشغيل قاعدة البيانات إلخ. كانت مهمة مماثلة مهمة بالنسبة لنا ، ومع ذلك ، فإن مسار تأملات وأفعال المؤلفين قد يكون مثيرًا للاهتمام في سياق أوسع.

كيفية التحقق من الأقراص باستخدام fio للحصول على أداء كافٍ لـ etcd

ملخص موجز للمقالة بأكملها: fio و etcd

يعتمد أداء مجموعة إلخ إلى حد كبير على سرعة التخزين الأساسي. إلخ ، يصدر العديد من مقاييس بروميثيوس لمراقبة الأداء. واحد منهم هو wal_fsync_duration_seconds. في وثائق الخ انها تقوليمكن اعتبار هذا التخزين سريعًا بدرجة كافية إذا كانت النسبة المئوية 99 من هذا المقياس لا تتجاوز 10 مللي ثانية ...

إذا كنت تفكر في إنشاء مجموعة إلخ على أجهزة Linux وترغب في اختبار ما إذا كانت محركات الأقراص (مثل محركات أقراص الحالة الثابتة) سريعة بدرجة كافية ، فإننا نوصي باستخدام أداة اختبار الإدخال / الإخراج الشهيرة المسمى خيط. يكفي تشغيل الأمر التالي (الدليل 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]

بعض الملاحظات:

  1. في المثال أعلاه ، قمنا بتعديل المعلمات --size и --bs لحالة معينة. للحصول على نتيجة ذات مغزى من fio، حدد القيم المناسبة لحالة الاستخدام الخاصة بك. سيتم مناقشة كيفية اختيارهم أدناه.
  2. أثناء الاختبار فقط fio يقوم بتحميل النظام الفرعي للقرص. في الحياة الواقعية ، من المحتمل أن تكتب العمليات الأخرى على القرص (إلى جانب تلك المتعلقة بـ wal_fsync_duration_seconds). هذا الحمل الإضافي يمكن أن يزيد wal_fsync_duration_seconds. بمعنى آخر ، إذا كانت النسبة المئوية 99 من الاختبار باستخدام fio، فقط أقل بقليل من 10 مللي ثانية ، هناك فرصة جيدة ألا يكون أداء التخزين كافيًا.
  3. للاختبار سوف تحتاج إلى الإصدار fio لا أقل من 3.5، لأن الإصدارات القديمة لا تجمع النتائج fdatasync في شكل نسب مئوية.
  4. الاستنتاج أعلاه هو مقتطف صغير من الاستنتاج العام fio.

المزيد عن fio و etcd

بضع كلمات حول WALs وما إلى ذلك

بشكل عام ، تستخدم قواعد البيانات التسجيل الاستباقي (تسجيل الكتابة المسبقة ، WAL). إلخ يتأثر أيضًا. إن مناقشة WAL خارج نطاق هذه المقالة ، ولكن لأغراضنا ، ما تحتاج إلى معرفته هو أن كل عضو في الكتلة وما إلى ذلك يخزن WAL في تخزين دائم. يكتب etcd بعض عمليات تخزين قيمة المفتاح (مثل التحديثات) إلى WAL قبل تنفيذها. إذا تعطلت العقدة وأعيد تشغيلها بين اللقطات ، فيمكن لـ etcd استرداد المعاملات منذ اللقطة السابقة بناءً على محتويات WAL.

وبالتالي ، في كل مرة يضيف فيها العميل مفتاحًا إلى متجر KV أو يحدّث قيمة مفتاح موجود ، يضيف الخ د وصف العملية إلى WAL ، وهو ملف عادي في المخزن الدائم. يجب أن يكون etcd متأكدًا بنسبة 100٪ أن إدخال WAL قد تم حفظه بالفعل قبل المتابعة. لتحقيق ذلك على Linux ، لا يكفي استخدام استدعاء النظام write، لأن عملية الكتابة نفسها إلى الوسائط الفعلية قد تتأخر. على سبيل المثال ، قد يحتفظ Linux بإدخال WAL في ذاكرة التخزين المؤقت للنواة في الذاكرة (على سبيل المثال ، في ذاكرة التخزين المؤقت للصفحة) لبعض الوقت. للتأكد من كتابة البيانات إلى الوسائط ، يجب استدعاء استدعاء النظام بعد الكتابة fdatasync - هذا هو بالضبط ما يفعله الخ (كما ترى في الإخراج التالي 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 على أداء إلخ. في وثائق المستودع مبين، من أجل الحصول على أداء كافٍ ، من الضروري أن تكون النسبة المئوية 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 v1.13 مع مراقبة بروميثيوس. تم استخدام محركات الأقراص ذات الحالة الثابتة كمخزن لـ etcd v3.2.24. أظهرت مقاييس Etcd زمن انتقال مرتفع جدًا fdatasync، حتى عندما كانت الكتلة خامدة. بالنسبة لنا ، بدت هذه المقاييس مشكوكًا فيها للغاية ، ولم نكن متأكدين مما تمثله بالضبط. بالإضافة إلى ذلك ، كانت المجموعة تتكون من أجهزة افتراضية ، لذلك لم يكن من الممكن تحديد ما إذا كان التأخير بسبب المحاكاة الافتراضية أم أن SSD هو المسؤول.

بالإضافة إلى ذلك ، أخذنا في الاعتبار التغييرات المختلفة في تكوين الأجهزة والبرامج ، لذلك كنا بحاجة إلى طريقة لتقييمها. بالطبع ، سيكون من الممكن تشغيل etcd في كل تكوين وإلقاء نظرة على مقاييس Prometheus المقابلة ، لكن هذا يتطلب جهدًا كبيرًا. ما كنا بحاجة إليه هو طريقة بسيطة لتقييم تكوين معين. أردنا اختبار فهمنا لمقاييس بروميثيوس القادمة من الخ.

هذا يتطلب حل مشكلتين:

  • أولاً ، كيف يبدو تحميل الإدخال / الإخراج الذي تم إنشاؤه بواسطة etcd عند الكتابة إلى ملفات WAL؟ ما هي مكالمات النظام المستخدمة؟ ما هو حجم كتل التسجيل؟
  • ثانيًا ، لنفترض أن لدينا إجابات على الأسئلة أعلاه. كيفية إعادة إنتاج الحمل المقابل باستخدام fio؟ بعد كل شيء fio - فائدة مرنة للغاية مع وفرة من المعلمات (من السهل التحقق من ذلك ، على سبيل المثال ، هنا - تقريبا. ترجمة.).

لقد حللنا كلتا المشكلتين بنفس النهج القائم على الأوامر lsof и strace:

  • استخدام lsof يمكنك عرض جميع واصفات الملفات التي تستخدمها العملية ، بالإضافة إلى الملفات التي تشير إليها.
  • استخدام strace يمكنك تحليل عملية قيد التشغيل بالفعل أو تشغيل عملية ومشاهدتها. يعرض الأمر جميع استدعاءات النظام التي تم إجراؤها بواسطة هذه العملية ، وإذا لزم الأمر ، نسلها. هذا الأخير مهم للعمليات التي تكون متفرعة ، وما إلى ذلك هو أحد هذه العمليات.

أول شيء فعلناه هو استخدام strace لفحص خادم etcd في مجموعة Kubernetes عندما كان خاملاً.

لذلك وجد أن كتل تسجيل WAL مجمعة بكثافة كبيرة ، وكان حجم الأغلبية في حدود 2200-2400 بايت. هذا هو السبب في أن الأمر في بداية هذه المقالة يستخدم العلم --bs=2300 (bs هو الحجم بالبايت لكل كتلة كتابة fio).

يرجى ملاحظة أن حجم كتل الكتابة وما إلى ذلك قد يختلف اعتمادًا على الإصدار والنشر وقيم المعلمات وما إلى ذلك. - يؤثر على المدة fdatasync. إذا كانت لديك حالة استخدام مماثلة ، فقم بتحليلها باستخدام strace عمليات الخرد الخاصة بك للحصول على قيم محدثة.

بعد ذلك ، من أجل الحصول على فكرة واضحة وشاملة عن كيفية عمل etcd مع نظام الملفات ، بدأنا ذلك من الأسفل strace مع الأعلام -ffttT. هذا جعل من الممكن التقاط العمليات الفرعية وكتابة إخراج كل منها في ملف منفصل. بالإضافة إلى ذلك ، تم الحصول على معلومات مفصلة حول وقت بدء ومدة كل مكالمة نظام.

كما استخدمنا الأمر lsofلتأكيد فهمك للمخرجات strace من حيث واصف الملف الذي تم استخدامه لهذا الغرض. لقد وصلت إلى الاستنتاج strace، على غرار ما ورد أعلاه. أكدت التلاعبات الإحصائية مع أوقات المزامنة أن المقياس wal_fsync_duration_seconds من etcd يطابق المكالمات fdatasync مع واصفات ملف WAL.

لتوليد مع fio عبء عمل مشابه لذلك من الخ ، تمت دراسة توثيق الأداة وتم اختيار المعلمات المناسبة لمهمتنا. لقد تحققنا من أن مكالمات النظام الصحيحة قيد التقدم وأكدنا مدتها بالتشغيل fio من strace (كما حدث في حالة الخ).

تم إيلاء اهتمام خاص لتحديد قيمة المعلمة --size. يمثل إجمالي حمل الإدخال / الإخراج الناتج عن الأداة المساعدة fio. في حالتنا ، هذا هو العدد الإجمالي للبايتات المكتوبة في الوسائط. يتناسب طرديا مع عدد المكالمات write (و fdatasync). لمحدد bs عدد المكالمات fdatasync غير size / bs.

نظرًا لأننا كنا مهتمين بالنسب المئوية ، أردنا أن يكون عدد العينات كبيرًا بما يكفي ليكون ذا دلالة إحصائية. وقررت ذلك 10^4 (الذي يتوافق مع حجم 22 ميغا بايت) سيكون كافياً. قيم معلمات أصغر --size أعطى ضوضاء أكثر وضوحًا (على سبيل المثال ، المكالمات fdatasync، والتي تستغرق وقتًا أطول بكثير من المعتاد وتؤثر على 99 بالمائة).

الأمر متروك لك

يوضح المقال كيفية الاستخدام fio يمكن للمرء أن يحكم على ما إذا كانت الوسائط المخصصة للاستخدام مع etcd سريعة بدرجة كافية. الوضع الآن يترتب عليك! يمكنك استكشاف الأجهزة الافتراضية مع التخزين المستند إلى SSD في الخدمة آي بي إم الغيمة.

PS من المترجم

مع حالات الاستخدام الجاهزة fio للمهام الأخرى ، انظر توثيق أو مباشرة إلى مستودعات المشروع (هناك الكثير منهم أكثر مما هو مذكور في الوثائق).

PPS من المترجم

اقرأ أيضًا على مدونتنا:

المصدر: www.habr.com

إضافة تعليق