ProHoster > بلوق > إدارة > نصائح وحيل للعمل مع Ceph في المشاريع المحملة

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

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

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

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

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

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

مقدمة حول OSD

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

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

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

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

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

للراحة ولتجنب الموقف الذي نرتكب فيه خطأً أثناء تنفيذ الأوامر في الإشارة إلى 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

...وهكذا حتى الصفر.

التوازن السلس مطلوبحتى لا تفقد البيانات. وينطبق هذا بشكل خاص إذا كان 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 من خريطة كراش:

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، فيجب أن يكون واضحًا أنه على الخادم الذي تم تنفيذ العمل فيه، لم تعد هناك OSDs التي تم تنفيذ العمليات المذكورة أعلاه عليها:

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وسنرى أيضًا انخفاضًا في عدد OSDs ومقدار المساحة المتوفرة على القرص.

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

إذا لم يكن هناك أي OSDs متبقية على هذا الخادم، فبعد إزالتها، تحتاج إلى استبعاد الخادم من خريطة 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. الصيغة التي يمكنك من خلالها حساب الكمية المطلوبة من PG موجودة القسم ذي الصلة وثائق سيف. تمت مناقشة هذه المشكلة أيضًا هناك مع أمثلة محددة.

لذلك: إحدى المشكلات الشائعة عند استخدام Ceph هي العدد غير المتوازن لـ OSD وPG بين التجمعات في Ceph.

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

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

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

أولا وقبل كل شيء، تحتاج إلى توزيع البيانات المتاحة بين OSDs المتبقية. لقد أجرينا بالفعل عملية مماثلة في الحالة الأولى، عندما "استنزفنا" العقدة - مع الاختلاف الوحيد الذي سنحتاج الآن إلى تقليله قليلاً reweight. على سبيل المثال، ما يصل إلى 0.95:

ceph osd reweight osd.${ID} 0.95

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

وفي حالتنا الخاصة، جاء كل ذلك إلى:

  • قيمة عالية جدًا replication_count في أحد حمامات السباحة،
  • الكثير من PG في مجموعة واحدة والقليل جدًا في مجموعة أخرى.

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

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

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

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

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 بشكل تسلسلي في كل تجمع وعدم تغيير القيم في التجمعات الأخرى حتى تختفي التحذيرات "تكرار البيانات المتدهورة" и "عدد n من الصفحات المتدهورة".

يمكنك أيضًا التحقق من أن كل شيء سار على ما يرام باستخدام مخرجات الأمر ceph health detail и ceph -s.

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

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

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

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

دعنا ننتقل إلى الجزء العملي. في المثال نستخدم 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، فسنكون سعداء برؤيتها في التعليقات!

PS

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

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

إضافة تعليق