لا يحتاجك

فيما يتعلق بشعبية Rook المتزايدة ، أريد أن أتحدث عن مطباتها والمشاكل التي تنتظرك في الطريق.

عني: تجربة إدارة Ceph مع إصدار المطرقة ، مؤسس مجتمع t.me/ceph_ru في البرقيات.

لكي لا تكون بلا أساس ، سأشير إلى المشاركات التي قبلها Habr (حسب التصنيف) حول مشاكل ceph. لقد واجهت معظم المشاكل في هذه الوظائف أيضا. روابط إلى المواد المستخدمة في نهاية المنشور.

في منشور عن Rook ، نذكر ceph لسبب ما - Rook بشكل أساسي ceph ملفوفة في kubernetes ، مما يعني أنها ترث كل مشاكلها. سنبدأ مع مشاكل ceph.

تبسيط إدارة الكتلة

واحدة من مزايا Rook هي راحة إدارة ceph من خلال kuberentes.

ومع ذلك ، يحتوي ceph على أكثر من 1000 معلمة للتوليف ، في الوقت نفسه من خلال الغراب ، يمكننا تحرير جزء صغير منها فقط.

مثال مضيئة
> ceph daemon mon.a config show | مرحاض
1401

تم وضع Rook كوسيلة ملائمة لتثبيت وتحديث ceph
لا توجد مشاكل في تثبيت ceph دون Rook - تتم كتابة كتاب اللعب ansible في 30 دقيقة ، ولكن هناك الكثير من المشاكل في تحديث المشاكل.

اقتباس من مشاركة Krok

على سبيل المثال: التشغيل غير الصحيح للسناجب بعد الترقية من هامر إلى جوهرة

> ceph osd سحق عرض tunables
{
...
"Straw_calc_version": 1 ،
"Allow_bucket_algs": 22 ،
"الملف الشخصي": "غير معروف" ،
Optimal_tunables: 0 ،
...
}

ولكن حتى في الإصدارات الثانوية هناك مشاكل.

مثال: تحديث 12.2.6 جلب الكتلة إلى الصحة يخطئ و PG كسر مشروط
ceph.com/releases/v12-2-8-released

لا التحديث ، الانتظار والاختبار؟ لكننا نوع من استخدام الغراب لراحة التحديثات كذلك.

تعقيد كتلة التعافي من الكوارث في الغراب

مثال: تعطل OSD الأخطاء العاجلة تحت قدميه. أنت تشك في أن المشكلة تكمن في أحد المعلمات في التكوين ، وتريد تغيير التهيئة لخفي محدد ، لكن لا يمكنك ذلك ، لأن لديك kubernetes و DaemonSet.

لا يوجد بديل. ceph tell osd.Num injectargs لا يعمل - أكاذيب OSD.

تصحيح التعقيد

بالنسبة لبعض الإعدادات واختبارات الأداء ، يجب عليك الاتصال مباشرة بمقبس الخفي osd. في حالة Rook ، فأنت بحاجة أولاً إلى العثور على الحاوية المناسبة ، ثم الدخول إليها ، والعثور على المفقودين لضبط التصحيح وتصحيحها.

صعوبة رفع OSD بالتتابع

مثال: تقع OSD على OOM ، تبدأ إعادة التوازن ، ثم السقوط التالي.

الحل: ارفع OSD واحداً تلو الآخر ، وانتظر حتى يتم تضمينه بالكامل في المجموعة ، وارفع التالي. (المزيد في تقرير تشيف تشريح الكارثة.)

في حالة التثبيت baremetal ، يتم ذلك يدويًا ، في حالة Rook و OSD واحد على العقدة لا توجد مشاكل معينة ، ستحدث مشكلات في الرفع المتتابع إذا كان OSD> 1 على العقدة.

بالطبع ، يمكن حلها ، لكننا نحمل Rook من أجل التبسيط ، لكننا نحصل على تعقيدات.

صعوبة اختيار حدود للشياطين ceph

بالنسبة لتركيبات cem البارميتالية ، من السهل حساب الموارد اللازمة لكل مجموعة - هناك صيغ وهناك دراسات. عند استخدام وحدات المعالجة المركزية الضعيفة ، لا يزال يتعين عليك إجراء سلسلة من اختبارات الأداء لمعرفة ماهية Numa ، ولكنها لا تزال أبسط من Rook.

في حالة Rook ، بالإضافة إلى حدود الذاكرة التي يمكن حسابها ، فإن السؤال الذي يطرح نفسه هو تعيين حد وحدة المعالجة المركزية.

ثم عليك أن تتعرق مع اختبارات الأداء. في حالة الاستخفاف بالحدود ، ستحصل على كتلة بطيئة ، وفي حالة تحديد الحالة غير الصحيحة ، ستحصل على استخدام نشط لوحدة المعالجة المركزية مع إعادة التوازن ، مما سيؤثر بشكل سيئ على تطبيقاتك في kubernetes.

مشاكل الشبكات v1

بالنسبة لـ ceph ، يوصى باستخدام شبكة 2x10gb. واحد لحركة مرور العميل ، والآخر للمكتب استخدام ceph (إعادة التوازن). إذا كنت تعيش باستخدام ceph on baremetal ، فمن السهل تهيئة هذا الفصل ، وإذا كنت تعيش مع Rook ، فإن الفصل مع الشبكات سيؤدي إلى مشاكل بالنسبة لك ، لأنه بعيدًا عن كل تكوين كتلة يسمح لك بتغذية شبكتين مختلفتين لتعبئة البيانات.

قضايا الشبكات v2

إذا رفضت مشاركة الشبكات ، فسوف تسد حركة المرور عبر ceph القناة بأكملها مع إعادة التوازن ، وستتباطأ تطبيقاتك في kubernetes أو تتعطل. يمكنك تقليل معدل إعادة التوازن ceph ، ولكن بعد ذلك بسبب إعادة التوازن الطويلة ، تحصل على زيادة خطر سقوط العقدة الثانية من الكتلة على الأقراص أو OOM ، وهناك بالفعل مضمون للقراءة فقط على الكتلة.

إعادة التوازن الطويل - الفرامل تطبيق طويل

اقتبس من وظيفة Ceph. تشريح الكوارث.

اختبار أداء الكتلة:

تستغرق عملية الكتابة 4 كيلوبايت 1 مللي ثانية ، والأداء 1000 عمليات / ثانية في 1 دفق.

تستغرق العملية التي يبلغ حجمها 4 ميغابايت (حجم الكائن) 22 مللي ثانية ، والأداء 45 عملية / ثانية.

لذلك ، عندما يفشل أحد المجالات الثلاثة ، تكون الكتلة في حالة متدهورة لبعض الوقت ، وينتشر نصف الكائنات الساخنة وفقًا لإصدارات مختلفة ، ثم يبدأ نصف عمليات الكتابة باسترداد قسري.

يتم احتساب وقت الاسترداد القسري تقريبًا - عمليات الكتابة في كائن منخفض.

أولاً ، نقرأ 4 ميغابايت في 22 مللي ثانية ، والكتابة 22 مللي ثانية ، ثم 1 مللي ثانية نكتب 4 كيلوبايت من البيانات نفسها. في المجموع ، 45 مللي ثانية لعملية الكتابة واحدة لكائن تدهور على SSD ، عندما كان الأداء القياسي 1 مللي ثانية - انخفاض الأداء 45 مرة.

كلما زادت النسبة المئوية للكائنات المتدهورة ، زاد الأمر سوءًا.

اتضح أن معدل إعادة التوازن أمر بالغ الأهمية للتشغيل الصحيح للمجموعة.

خادم إعدادات محددة ل ceph

قد يحتاج ceph إلى ضبط مضيف محدد.

مثال: إعدادات sysctl ونفس JumboFrame ، يمكن أن تؤثر بعض هذه الإعدادات سلبًا على حمولتك.

لا تزال هناك حاجة حقيقية للرخ

إذا كنت في السحابة ، فلديك تخزين من مزود السحابة الخاص بك ، والذي هو أكثر ملاءمة.

إذا كنت على الخوادم الخاصة بك ، فستكون إدارة ceph أكثر ملاءمة بدون kubernetes.

هل استئجار خادم في بعض استضافة منخفضة التكلفة؟ بعد ذلك ستجد الكثير من المرح مع الشبكة والتأخير والنطاق الترددي ، مما يؤثر سلبًا بشكل واضح على ceph.

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

قائمة الأدبيات المستخدمة:

بعد # 1 لكنك تقول Ceph ... ولكن هل هو جيد؟
بعد رقم 2 تشريح الكوارث