ProHoster > وبلاگ > اداره > نکات و ترفندهایی برای کار با Ceph در پروژه های شلوغ

نکات و ترفندهایی برای کار با Ceph در پروژه های شلوغ

نکات و ترفندهایی برای کار با Ceph در پروژه های شلوغ

با استفاده از Ceph به عنوان ذخیره سازی شبکه در پروژه هایی با بارهای مختلف، ممکن است با کارهای مختلفی روبرو شویم که در نگاه اول ساده و پیش پا افتاده به نظر نمی رسند. مثلا:

  • انتقال داده ها از Ceph قدیمی به جدید با استفاده جزئی از سرورهای قبلی در خوشه جدید.
  • راه حل برای مشکل تخصیص فضای دیسک در Ceph.

در مواجهه با چنین مشکلاتی، ما با نیاز به حذف صحیح OSD بدون از دست دادن داده ها روبرو هستیم، که به ویژه در هنگام مواجهه با حجم زیاد داده مهم است. این در مقاله مورد بحث قرار خواهد گرفت.

روش های شرح داده شده در زیر برای هر نسخه از Ceph مرتبط هستند. علاوه بر این، این واقعیت که Ceph می تواند حجم زیادی از داده ها را ذخیره کند در نظر گرفته می شود: برای جلوگیری از از دست دادن داده ها و سایر مشکلات، برخی اقدامات به چندین مورد دیگر تقسیم می شوند.

پیشگفتار در مورد OSD

از آنجایی که دو مورد از سه دستور العمل مورد بحث به OSD اختصاص داده شده است (دیمون ذخیره سازی اشیاقبل از فرو رفتن در بخش عملی - به طور خلاصه در مورد اینکه در Ceph چیست و چرا اینقدر مهم است.

اول از همه باید گفت که کل خوشه Ceph از OSD های زیادی تشکیل شده است. هر چه تعداد بیشتر باشد، حجم داده رایگان در Ceph بیشتر می شود. از اینجا به راحتی قابل درک است عملکرد اصلی OSD: داده های شی Ceph را در سیستم های فایل تمام گره های خوشه ای ذخیره می کند و دسترسی شبکه را به آن (برای خواندن، نوشتن و سایر درخواست ها) فراهم می کند.

در همان سطح، پارامترهای تکرار با کپی کردن اشیا بین OSD های مختلف تنظیم می شوند. و در اینجا می توانید با مشکلات مختلفی روبرو شوید که راه حل های آنها در زیر مورد بحث قرار خواهد گرفت.

پرونده شماره 1. OSD را با خیال راحت از خوشه Ceph بدون از دست دادن داده حذف کنید

نیاز به حذف OSD ممکن است با حذف سرور از خوشه ایجاد شود - به عنوان مثال، جایگزین کردن آن با سرور دیگری - که برای ما اتفاق افتاد و باعث نوشتن این مقاله شد. بنابراین، هدف نهایی دستکاری استخراج همه OSD ها و 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 با متعادل کردن آن با سایر OSD ها کاهش می دهیم. برای این کار دستورات زیر را اجرا کنید:

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 را از نقشه 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 حذف کنید، مراحل زیر شرح داده می شود. در این مورد، مهم است که به یاد داشته باشید قبل از خاموش کردن سرور، باید همه OSD ها را حذف کنید در این سرور

اگر 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 است. فرمولی که با آن می توانید مقدار PG مورد نیاز را محاسبه کنید در آن وجود دارد بخش مربوطه اسناد Ceph. این موضوع نیز در آنجا با مثال های مشخص مطرح می شود.

بنابراین: یکی از مشکلات رایج هنگام استفاده از Ceph، نامتعادل بودن تعداد OSD و PG بین استخرها در Ceph است.

اولاً، به همین دلیل، ممکن است موقعیتی ایجاد شود که تعداد زیادی PG در یک استخر کوچک مشخص شود، که اساساً استفاده غیرمنطقی از فضای دیسک در خوشه است. در مرحله دوم، در عمل یک مشکل جدی تر وجود دارد: سرریز داده ها در یکی از OSD. این مستلزم انتقال خوشه به حالت اول است HEALTH_WARN، و سپس HEALTH_ERR. دلیل این امر این است که Ceph هنگام محاسبه مقدار داده های موجود (می توانید آن را توسط MAX AVAIL در خروجی فرمان ceph df برای هر استخر به طور جداگانه) بر اساس میزان داده های موجود در OSD است. اگر حداقل در یک OSD فضای کافی وجود نداشته باشد، تا زمانی که داده ها به درستی بین همه OSD ها توزیع نشود، نمی توان اطلاعات بیشتری نوشت.

شایان ذکر است که این مشکلات تا حد زیادی در مرحله پیکربندی خوشه Ceph تصمیم گیری می شود. یکی از ابزارهایی که می توانید استفاده کنید این است Ceph PGCalc. با کمک آن، مقدار مورد نیاز PG به وضوح محاسبه می شود. با این حال، شما همچنین می توانید در شرایطی که خوشه Ceph وجود دارد به آن متوسل شوید قبلا به اشتباه پیکربندی شده است در اینجا شایان ذکر است که به عنوان بخشی از کار تعمیر به احتمال زیاد نیاز به کاهش تعداد PG ها خواهید داشت و این ویژگی در نسخه های قدیمی Ceph (فقط در نسخه ظاهر شد) موجود نیست. حلزونهای گرمسیری مارپیچی جنوب اقیانوس ساکن و اقیانوس هند).

بنابراین، بیایید تصویر زیر را تصور کنیم: خوشه یک وضعیت دارد HEALTH_WARN به دلیل خالی شدن فضای یکی از OSD. این با یک خطا نشان داده خواهد شد HEALTH_WARN: 1 near full osd. در زیر الگوریتمی برای خروج از این وضعیت آمده است.

اول از همه، شما باید داده های موجود را بین OSD های باقی مانده توزیع کنید. ما قبلاً عملیات مشابهی را در مورد اول انجام دادیم ، زمانی که گره را "تخلیه" کردیم - با تنها تفاوتی که اکنون باید کمی کاهش دهیم 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

این مهم است: باید تعداد PG ها را به صورت متوالی در هر Pool تغییر دهیم و تا زمانی که اخطارها ناپدید نشوند، مقادیر را در استخرهای دیگر تغییر ندهیم. "افزایش داده های تخریب شده" и "n-تعداد صفحات کاهش یافته".

همچنین می توانید با استفاده از خروجی های فرمان بررسی کنید که همه چیز به خوبی پیش رفته است 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 باقی می‌ماند، که در صورتی که انتقال ماشین مجازی به 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

اضافه کردن نظر