Get best of the week

نصائح وحيل العمل مع Ceph في المشاريع المزدحمة



باستخدام Ceph كمخزن للشبكة في مشاريع عبء العمل المختلفة ، قد نواجه مهامًا مختلفة لا تبدو للوهلة الأولى بسيطة أو تافهة. على سبيل المثال:

  • ترحيل البيانات من Ceph القديم إلى الجديد مع الاستخدام الجزئي للخوادم السابقة في المجموعة الجديدة ؛
  • حل مشكلة توزيع مساحة القرص في Ceph.

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

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

مقدمة OSD


نظرًا لأن اثنين من الوصفات الثلاث قيد الدراسة مخصصة لـ OSD ( Object Storage Daemon ) ، قبل الغوص في الجزء العملي - باختصار حول ما هو عليه في Ceph وسبب أهميته.

بادئ ذي بدء ، يجب أن يقال أن مجموعة Ceph بأكملها تتكون من العديد من OSDs. وكلما زاد حجم البيانات المجانية في Ceph. من هنا ، من السهل فهم الوظيفة الرئيسية لـ OSD : فهي تحفظ بيانات كائن Ceph على أنظمة الملفات في جميع عُقد نظام المجموعة وتوفر الوصول إلى الشبكة إليها (للقراءة والكتابة والطلبات الأخرى).

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

القضية رقم 1. استرجع OSD بأمان من مجموعة Ceph دون فقدان البيانات


قد تكون الحاجة إلى إزالة OSD ناتجة عن انسحاب الخادم من المجموعة - على سبيل المثال ، لاستبداله بخادم آخر - وهو ما حدث معنا ، مما أدى إلى كتابة المقالة. وبالتالي ، فإن الهدف النهائي من التلاعب هو استخراج جميع OSDs والأموال على خادم معين بحيث يمكن إيقافها.

من أجل الراحة والقضاء على الموقف ، في عملية تنفيذ الأوامر ، سوف نرتكب خطأ يشير إلى OSD الضرورية ، سنقوم بتعيين متغير منفصل ، ستكون قيمته عدد OSD المطلوب حذفه. سنطلق عليه ${ID}- فيما يلي ، يستبدل هذا المتغير رقم OSD الذي نعمل معه.

دعونا نلقي نظرة على الحالة قبل بدء العمل:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME      STATUS REWEIGHT PRI-AFF
-1       0.46857 root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
 1   ssd 0.15619      osd.1     up     1.00000  1.00000
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2     up     1.00000  1.00000

لبدء إزالة OSD ، ستحتاج إلى التنفيذ بسلاسة reweightإلى الصفر. وبالتالي ، نقوم بتقليل كمية البيانات في قائمة OSD عن طريق الموازنة مع OSDs الأخرى. للقيام بذلك ، يتم تنفيذ الأوامر التالية:

ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78

... وهكذا إلى الصفر.

محدث : أخبرت التعليقات على المقال عن الطريقة مع norebalance+ backfill. الحل صحيح ، ولكن أولاً وقبل كل شيء ، تحتاج إلى إلقاء نظرة على الموقف ، لأننا norebalanceنستخدمه عندما لا نريد أن يتسبب أي OSD في تحميل الشبكة. osd_max_backfillتستخدم في الحالات التي يكون فيها من الضروري الحد من سرعة إعادة التوازن. ونتيجة لذلك ، ستكون إعادة التوازن أبطأ وتسبب حملًا أقل للشبكة.

التوازن السلس ضروري حتى لا تفقد البيانات. هذا صحيح بشكل خاص إذا كان OSD يحتوي على كمية كبيرة من البيانات. للتأكد من نجاح reweightكل شيء بعد تنفيذ الأوامر ، يمكنك ceph -sإما تنفيذه أو تشغيله في نافذة طرفية منفصلةceph -wمن أجل مراقبة التغيرات في الوقت الحقيقي.

عندما تكون OSD "فارغة" ، يمكنك بدء العملية القياسية لإزالتها. للقيام بذلك ، ضع OSD المطلوبة في الحالة down:

ceph osd down osd.${ID}

"سحب" OSD من المجموعة:

ceph osd out osd.${ID}

قم بإيقاف خدمة OSD وإلغاء تحميل قسمها في FS:

systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}

إزالة OSD من خريطة CRUSH :

ceph osd crush remove osd.${ID}

حذف مستخدم OSD:

ceph auth del osd.${ID}

وأخيرًا ، احذف OSD نفسها:

ceph osd rm osd.${ID}

ملاحظة : إذا كنت تستخدم Ceph Luminous أو أعلى ، فيمكن تقليل الخطوات المذكورة أعلاه لإزالة OSD إلى أمرين:

ceph osd out osd.${ID}
ceph osd purge osd.${ID}

إذا تم تنفيذ الأمر ، بعد تنفيذ الخطوات المذكورة أعلاه ، ceph osd treeفيجب ملاحظة أن الخادم حيث تم تنفيذ العمل لم يعد لديه OSD التي تم تنفيذ العمليات المذكورة أعلاه لها:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
-1       0.46857      root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2    up     1.00000  1.00000

على طول الطريق ، نلاحظ أن حالة مجموعة Ceph ستدخل HEALTH_WARN، وسنرى أيضًا انخفاضًا في عدد OSD ومقدار مساحة القرص المتوفرة.

بعد ذلك ، سيتم وصف الخطوات المطلوبة إذا كنت ترغب في إيقاف الخادم تمامًا ، وبالتالي ، إزالته من Ceph. في هذه الحالة ، من المهم أن تتذكر أنه قبل إغلاق الخادم ، يجب عليك استخراج جميع OSDs على هذا الخادم.

إذا لم يعد هناك المزيد من OSD على هذا الخادم ، فبعد إزالته ، تحتاج إلى استبعاد الخادم من بطاقة OSD عن طريق hv-2تشغيل الأمر التالي:

ceph osd crush rm hv-2

نحذفه monمن الخادم hv-2عن طريق تشغيل الأمر أدناه على خادم آخر (أي في هذه الحالة ، في hv-1):

ceph-deploy mon destroy hv-2

بعد ذلك ، يمكنك إيقاف الخادم ومتابعة الإجراءات اللاحقة (إعادة نشره ، وما إلى ذلك).

القضية رقم 2. تخصيص مساحة القرص في مجموعة Ceph التي تم إنشاؤها بالفعل


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

لذلك: إحدى المشاكل الشائعة أثناء عملية Ceph هي كمية غير متوازنة من OSD و PG بين التجمعات في Ceph. بشكل عام ، القيمة المحددة بشكل صحيح لـ PG هي مفتاح التشغيل الموثوق للكتلة ، وبعد ذلك سننظر في ما يمكن أن يحدث في الحالة المعاكسة.

تكمن الصعوبة في اختيار الكمية المناسبة من PG في شيئين:

  1. PG, , , chunk'.
  2. , , PG, .

من الناحية العملية ، يتم الحصول على مشكلة أكثر خطورة: تجاوز البيانات في أحد OSDs. والسبب في ذلك هو أن Ceph ، عند حساب كمية البيانات المتاحة (يمكنك العثور عليها MAX AVAILفي إخراج الأمر ceph dfلكل تجمع على حدة) ، يعتمد على كمية البيانات المتاحة في OSD. إذا لم تكن هناك مساحة كافية في OSD واحد على الأقل ، فلن تعمل كتابة المزيد من البيانات حتى يتم توزيع البيانات بشكل صحيح بين جميع OSDs.

تجدر الإشارة إلى أن هذه المشكلات يتم حلها إلى حد كبير في مرحلة تكوين مجموعة Ceph . إحدى الأدوات التي يمكنك استخدامها هي Ceph PGCalc . بمساعدتها ، يتم حساب الكمية اللازمة من PG بصريًا. ومع ذلك ، يمكنك اللجوء إليها في حالة تكون فيها مجموعة Ceph بالفعللم يتم تكوينه بشكل صحيح. هنا يجدر التوضيح أنه كجزء من عمل التصحيح ، ستحتاج على الأرجح إلى تقليل عدد PGs ، وهذه الميزة غير متاحة في الإصدارات القديمة من Ceph (ظهرت فقط من إصدار Nautilus ).

لذا ، دعونا نتخيل الصورة التالية: للكتلة حالة HEALTH_WARNبسبب نهاية مكان في أحد OSDs. خطأ سيشهد على ذلك HEALTH_WARN: 1 near full osd. فيما يلي خوارزمية للتغلب على هذا الموقف.

بادئ ذي بدء ، تحتاج إلى توزيع البيانات المتاحة بين بقية OSD. لقد قمنا بالفعل بعملية مماثلة في الحالة الأولى ، عندما "قمنا بتجفيف" العقدة - مع الفارق الوحيد الذي سيحتاج الآن إلى تقليل طفيف reweight. على سبيل المثال ، قبل 0.95:

ceph osd reweight osd.${ID} 0.95

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

في حالتنا الخاصة ، استند كل شيء على:

  • مهم للغاية replication_countفي أحد حمامات السباحة ،
  • الكثير من PGs في تجمع واحد وصغير جدًا في تجمع آخر.

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

ملاحظة : إذا قمت بتكوين مجموعة Ceph من البداية ، فستكون الوظيفة المفيدة الأخرى للآلة الحاسبة هي إنشاء الأوامر التي ستنشئ تجمعات من البداية مع المعلمات المدرجة في الجدول.

يساعدك العمود الأخير ، عدد الصفحات المقترحة ، في التنقل . في حالتنا ، الحالة الثانية مفيدة أيضًا ، حيث يشار إلى معلمة النسخ المتماثل ، لأننا قررنا تغيير عامل النسخ المتماثل.

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

ceph osd pool $pool_name set $replication_size

وبعد الانتهاء منه - نغير قيم المعلمات pg_numو pgp_numعلى النحو التالي:

ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_number

هام : يجب أن نغير عدد PGs في كل تجمع بشكل تسلسلي ولا نغير القيم الموجودة في مجموعات أخرى حتى تختفي التحذيرات "تكرار البيانات المتدهورة" و "عدد الصفحات المتحللة" .

يمكنك أيضا التحقق من أن كل شيء كان ناجحا، وفقا لاستنتاجات ceph health detailو الأوامر ceph -s.

القضية رقم 3. ترحيل الآلة الافتراضية من LVM إلى Ceph RBD


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

يمكن حل المشكلة بطرق مختلفة - على سبيل المثال ، من خلال الترحيل إلى خادم آخر (إن وجد) أو إضافة أقراص جديدة إلى الخادم. ولكن ليس من الممكن دائمًا القيام بذلك ، لذلك يمكن أن يكون الانتقال من LVM إلى Ceph حلاً ممتازًا لهذه المشكلة. من خلال تحديد هذا الخيار ، نقوم أيضًا بتبسيط عملية الترحيل الإضافية بين الخوادم ، حيث لن تكون هناك حاجة لنقل التخزين المحلي من برنامج مراقبة افتراضي إلى آخر. الصيد الوحيد هو أنه سيتعين عليك إيقاف VM طوال فترة العمل.

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

دعونا ننزل إلى الجزء العملي. في المثال ، نستخدم virsh ، وبالتالي libvirt. أولاً ، تأكد من أن تجمع Ceph الذي سيتم ترحيل البيانات إليه متصل بـ libvirt:

virsh pool-dumpxml $ceph_pool

يجب أن يحتوي وصف التجمع على بيانات اتصال Ceph مع بيانات التفويض.

الخطوة التالية هي تحويل صورة LVM إلى Ceph RBD. يعتمد وقت التشغيل بشكل أساسي على حجم الصورة:

qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_name

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

virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml

... وتحرير الأصل ( vm_name.xml). ابحث عن كتلة تحتوي على وصف للقرص (يبدأ بخط <disk type='file' device='disk'>وينتهي </disk>) وأحضره إلى النموذج التالي:

<disk type='network' device='disk'>
<driver name='qemu'/>
<auth username='libvirt'>
  <secret type='ceph' uuid='sec-ret-uu-id'/>
 </auth>
<source protocol='rbd' name='$ceph_pool/$vm_image_name>
  <host name='10.0.0.1' port='6789'/>
  <host name='10.0.0.2' port='6789'/>
</source>
<target dev='vda' bus='virtio'/> 
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>

دعنا نلقي نظرة على بعض التفاصيل:

  1. sourceيشير البروتوكول إلى عنوان التخزين في Ceph RBD (هذا هو العنوان الذي يشير إلى اسم تجمع Ceph وصورة RBD ، والتي تم تحديدها في المرحلة الأولى).
  2. secretتشير الكتلة إلى النوع ceph، بالإضافة إلى UUID للسر للاتصال به. يمكن العثور على uuid الخاص به مع الأمر virsh secret-list.
  3. hostيشار في عناوين كتلة لشاشات Ceph.

بعد تحرير ملف التكوين واستكمال تحويل LVM إلى RBD ، يمكنك تطبيق ملف التكوين المعدل وبدء تشغيل الجهاز الظاهري:

virsh define $vm_name.xml
virsh start $vm_name

حان الوقت للتحقق من أن الجهاز الظاهري بدأ بشكل صحيح: يمكنك معرفة ذلك ، على سبيل المثال ، عن طريق الاتصال به عبر SSH أو من خلال virsh.

إذا كان الجهاز الظاهري يعمل بشكل صحيح ولم تجد مشاكل أخرى ، فيمكنك حذف صورة LVM التي لم تعد مستخدمة:

lvremove main/$vm_image_name

استنتاج


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

ملاحظة


اقرأ أيضا في مدونتنا:

More articles:


All Articles