هل سرعة التخزين مناسبة للغير؟ اسأل قوة المراقبة الدولية

قصة قصيرة عن قوة المراقبة الدولية وغيرها

أداء الكتلة etcd يعتمد إلى حد كبير على أداء تخزينه. etcd تصدر بعض المقاييس إلى Prometheus لتوفير المعلومات اللازمة حول أداء التخزين. على سبيل المثال ، metric wal_fsync_duration_seconds. تقول وثائق etcd : لكي يتم اعتبار التخزين بالسرعة الكافية ، يجب أن تكون النسبة المئوية التاسعة والتسعين لهذا القياس أقل من 10 مللي ثانية. إذا كنت تخطط لتشغيل مجموعة etcd على أجهزة Linux وترغب في تقييم ما إذا كانت سعة التخزين لديك سريعة بما فيه الكفاية (مثل محركات أقراص الحالة الصلبة) ، يمكنك استخدام fio ، وهي أداة شائعة لاختبار عمليات الإدخال / الإخراج. قم بتشغيل الأمر التالي ، حيث يكون 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 و - bbs لسيناريونا المحدد. للحصول على نتيجة مفيدة من fio ، أدخل قيمك. أين يمكن الحصول عليها؟ اقرأ كيف تعلمنا كيفية تكوين fio .
• أثناء الاختبار ، يأتي تحميل I / O بالكامل من fio. في سيناريو حقيقي ، من المحتمل أن تصل طلبات الكتابة الأخرى إلى المستودع ، باستثناء الطلبات المتعلقة بـ wal_fsync_duration_seconds. سيزيد التحميل الإضافي قيمة wal_fsync_duration_seconds. لذلك إذا وصلت النسبة المئوية التاسعة والتسعين إلى 10 مللي ثانية تقريبًا ، فلن تكون سعة التخزين لديك كافية.
• خذ نسخة fio لا تقل عن 3.5 (لا تُظهر الإصدارات السابقة نسبًا مئوية من مدة fdatasync).
• أعلاه ليست سوى مقتطف من النتائج من fio.

قصة طويلة عن قوة المراقبة الدولية وغيرها

ما هو WAL في الخ

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

عندما يضيف العميل مفتاحًا إلى متجر للأزواج ذات القيمة الأساسية أو يقوم بتحديث قيمة مفتاح موجود ، إلخ يسجل هذه العملية في WAL ، وهو ملف منتظم في التخزين الدائم. قبل المتابعة ، يجب أن تكون متأكدًا تمامًا من أن الكتابة إلى WAL حدثت بالفعل. على نظام Linux ، لا تكفي مكالمة نظام الكتابة الواحدة لهذا ، لأن الكتابة الفعلية إلى التخزين الفعلي قد تتأخر. على سبيل المثال ، قد يقوم Linux بتخزين سجل WAL في ذاكرة تخزين مؤقت في ذاكرة kernel لبعض الوقت (على سبيل المثال ، ذاكرة تخزين مؤقت للصفحة). ولكي تتم كتابة البيانات بدقة على وحدة التخزين الثابتة ، فأنت بحاجة إلى استدعاء نظام fdatasync بعد الكتابة ، وما إلى ذلك ، فما عليك سوى استخدامه (كما ترون من strace ، حيث 8 هو واصف ملف WAL):

 21:23:09.894875 lseek(8, 0, SEEK_CUR) = 12808 <0.000012> 21:23:09.894911 write(8, ".\0\0\0\0\0\0\202\10\2\20\361\223\255\266\6\32$\10\0\20\10\30\26\"\34\"\r\n\3fo"..., 2296) = 2296 <0.000130> 21:23:09.895041 fdatasync(8) = 0 <0.008314> 

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

تقييم التخزين مع قوة المراقبة الدولية

إذا كنت بحاجة إلى تقييم ما إذا كان المستودع الخاص بك مناسبًا للغير ، فاستخدم fio ، وهي أداة اختبار تحميل I / O شائعة جدًا. يجب أن نتذكر أن عمليات القرص يمكن أن تكون مختلفة للغاية: متزامن وغير متزامن ، العديد من فئات مكالمات النظام ، وما إلى ذلك. يحتوي على العديد من المعلمات ، وتنتج توليفات مختلفة من قيمها أحمال عمل I / O مختلفة تمامًا. للحصول على أرقام كافية لـ etcd ، يجب عليك التأكد من أن تحميل تسجيل الاختبار من fio أقرب ما يمكن من التحميل الحقيقي من etcd عند كتابة ملفات WAL.

وبالتالي ، يجب على fio إنشاء حمل على الأقل في شكل سلسلة من عمليات الكتابة المتسلسلة إلى الملف ، وسوف يتألف كل سجل من مكالمة نظام الكتابة متبوعة باستدعاء نظام fdatasync. لعمليات الكتابة المتسلسلة ، يحتاج fio إلى --rw = خيار الكتابة. لكي يستخدم fio استدعاء نظام الكتابة بدلاً من pwrite عند التسجيل ، يجدر تحديد المعلمة --ioengine = sync. أخيرًا ، لكي يتم استدعاء fdatasync بعد كل إدخال ، تحتاج إلى إضافة --fdatasync = 1 معلمة. الخياران الآخران في هذا المثال (- الحجم و - bbs) خاصان بالسيناريو. في القسم التالي ، سنعرض لك كيفية تكوينها.

لماذا قوة المراقبة الدولية وكيف تعلمنا كيفية تكوينه

في هذا المنشور نصف الحالة الحقيقية. كان لدينا كتلة Kubernetes v1.13 ، والتي قمنا بمراقبتها باستخدام بروميثيوس. etcd v3.2.24 تم استضافته على SSD. أظهرت مقاييس Etcd اختارات عالية جدًا لـ fdatasync ، حتى عندما كانت المجموعة لا تفعل شيئًا. كانت المقاييس غريبة ، ولم نكن نعرف حقًا ما المقصود بها. تتكون المجموعة من أجهزة افتراضية ، وكان عليك أن تفهم المشكلة التي كانت: في محركات أقراص الحالة المادية الفعلية أو في طبقة المحاكاة الافتراضية. بالإضافة إلى ذلك ، قمنا في كثير من الأحيان بإجراء تغييرات على تكوين الأجهزة والبرامج ، وكنا بحاجة إلى طريقة لتقييم نتائجها. يمكننا تشغيل الخ في كل تكوين وإلقاء نظرة على مقاييس بروميثيوس ، ولكن هذا أمر مزعج للغاية. كنا نبحث عن وسيلة بسيطة إلى حد ما لتقييم تكوين معين. أردنا التحقق مما إذا فهمنا مقاييس Prometheus من etcd بشكل صحيح.

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

بادئ ذي بدء ، استخدمنا strace لمعرفة خادم etcd لـ Kubernetes عندما لم يكن هناك تحميل على نظام المجموعة. رأينا أن جميع سجلات WAL تقريبًا كانت بنفس الحجم تقريبا: 2200-2400 بايت. لذلك ، في الأمر في بداية المنشور ، حددنا المعلمة --bs = 2300 (bs تعني الحجم بالبايت لكل إدخال fio). لاحظ أن حجم الإدخال etcd يعتمد على إصدار etc ، والتسليم ، وقيم المعلمة ، وما إلى ذلك ، ويؤثر على مدة fdatasync. إذا كان لديك سيناريو مشابه ، فافحص عملياتك الخاطفة بشيء لمعرفة الأرقام الدقيقة.

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

درسنا وثائق fio وحددنا خيارات برنامجنا النصي بحيث يولد fio حملاً مشابهاً لـ etcd. لقد فحصنا أيضًا مكالمات النظام ومدتها من خلال تشغيل fio من strace ، على غرار etcd.

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

جربه بنفسك

لقد أظهرنا كيفية استخدام fio ومعرفة ما إذا كان التخزين به سرعة كافية لأداء عالٍ وما إلى ذلك. يمكنك الآن تجربة ذلك على أرض الواقع ، باستخدام ، على سبيل المثال ، أجهزة افتراضية مع تخزين SSD في IBM Cloud .