پرو ہوسٹر > بلاگ > انتظامیہ > مصروف پروجیکٹس میں سیف کے ساتھ کام کرنے کے لیے نکات اور چالیں۔

مصروف پروجیکٹس میں سیف کے ساتھ کام کرنے کے لیے نکات اور چالیں۔

مصروف پروجیکٹس میں سیف کے ساتھ کام کرنے کے لیے نکات اور چالیں۔

مختلف بوجھ والے پروجیکٹس میں نیٹ ورک اسٹوریج کے طور پر Ceph کا استعمال کرتے ہوئے، ہمیں مختلف کاموں کا سامنا کرنا پڑ سکتا ہے جو پہلی نظر میں آسان یا معمولی نہیں لگتے ہیں۔ مثال کے طور پر:

  • نئے کلسٹر میں پچھلے سرورز کے جزوی استعمال کے ساتھ پرانے Ceph سے نئے میں ڈیٹا کی منتقلی؛
  • Ceph میں ڈسک کی جگہ مختص کرنے کے مسئلے کا حل۔

اس طرح کے مسائل سے نمٹنے کے لیے، ہمیں ڈیٹا کو کھونے کے بغیر OSD کو درست طریقے سے ہٹانے کی ضرورت کا سامنا کرنا پڑتا ہے، جو کہ خاص طور پر اہم ہے جب بڑی مقدار میں ڈیٹا سے نمٹنے کے لیے۔ اس مضمون میں بحث کی جائے گی.

ذیل میں بیان کردہ طریقے Ceph کے کسی بھی ورژن کے لیے متعلقہ ہیں۔ اس کے علاوہ، اس حقیقت کو بھی مدنظر رکھا جائے گا کہ Ceph ڈیٹا کی ایک بڑی مقدار کو ذخیرہ کر سکتا ہے: ڈیٹا کے نقصان اور دیگر مسائل کو روکنے کے لیے، کچھ اقدامات کو کئی دیگر میں "تقسیم" کر دیا جائے گا۔

OSD کے بارے میں پیش لفظ

چونکہ زیر بحث تین میں سے دو ترکیبیں OSD کے لیے وقف ہیں (آبجیکٹ اسٹوریج ڈیمون)، عملی حصے میں غوطہ لگانے سے پہلے - مختصراً اس کے بارے میں کہ یہ سیف میں کیا ہے اور یہ اتنا اہم کیوں ہے۔

سب سے پہلے تو یہ کہنا چاہیے کہ پورا Ceph کلسٹر بہت سے OSDs پر مشتمل ہے۔ جتنے زیادہ ہیں، Ceph میں مفت ڈیٹا کا حجم اتنا ہی زیادہ ہوگا۔ یہاں سے سمجھنا آسان ہے۔ مرکزی OSD فنکشن: یہ تمام کلسٹر نوڈس کے فائل سسٹمز پر Ceph آبجیکٹ ڈیٹا کو اسٹور کرتا ہے اور اسے نیٹ ورک تک رسائی فراہم کرتا ہے (پڑھنے، لکھنے اور دیگر درخواستوں کے لیے)۔

اسی سطح پر، نقل کے پیرامیٹرز مختلف OSDs کے درمیان اشیاء کو کاپی کرکے سیٹ کیے جاتے ہیں۔ اور یہاں آپ کو مختلف مسائل کا سامنا کرنا پڑ سکتا ہے، جن کے حل ذیل میں زیر بحث آئیں گے۔

مقدمہ نمبر 1۔ ڈیٹا کو کھونے کے بغیر Ceph کلسٹر سے OSD کو محفوظ طریقے سے ہٹا دیں۔

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 اس پر صفر۔ اس طرح ہم او ایس ڈی میں ڈیٹا کی مقدار کو دوسرے او ایس ڈیز سے متوازن کرکے اسے کم کرتے ہیں۔ ایسا کرنے کے لیے، درج ذیل کمانڈز چلائیں:

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 "خالی" ہو جاتا ہے، تو آپ اسے ہٹانے کے لیے معیاری آپریشن کے ساتھ آگے بڑھ سکتے ہیں۔ ایسا کرنے کے لیے، مطلوبہ او ایس ڈی کو ریاست میں منتقل کریں۔ 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، پھر یہ واضح ہونا چاہئے کہ سرور پر جہاں کام انجام دیا گیا تھا وہاں اب کوئی او ایس ڈی نہیں ہیں جن کے لئے اوپر کی کارروائیاں انجام دی گئی ہیں:

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 کے دیباچے سے کروں گا (پلیسمنٹ گروپس)۔ Ceph میں PG کا بنیادی کردار بنیادی طور پر Ceph اشیاء کو جمع کرنا اور انہیں OSD میں مزید نقل کرنا ہے۔ وہ فارمولہ جس کے ساتھ آپ PG کی مطلوبہ مقدار کا حساب لگا سکتے ہیں۔ متعلقہ سیکشن Ceph دستاویزات۔ یہ مسئلہ وہاں بھی مخصوص مثالوں کے ساتھ زیر بحث آیا ہے۔

لہذا: Ceph استعمال کرتے وقت ایک عام مسئلہ Ceph میں پولوں کے درمیان OSD اور PG کی غیر متوازن تعداد ہے۔

سب سے پہلے، اس کی وجہ سے، ایسی صورت حال پیدا ہو سکتی ہے جب ایک چھوٹے سے پول میں بہت زیادہ PGs کی وضاحت کی گئی ہو، جو کہ بنیادی طور پر کلسٹر میں ڈسک کی جگہ کا غیر معقول استعمال ہے۔ دوم، عملی طور پر ایک زیادہ سنگین مسئلہ ہے: OSDs میں سے ایک میں ڈیٹا اوور فلو۔ اس میں کلسٹر کی پہلی ریاست میں منتقلی شامل ہے۔ HEALTH_WARN، اور پھر HEALTH_ERR. اس کی وجہ یہ ہے کہ Ceph، ڈیٹا کی دستیاب مقدار کا حساب لگاتے وقت (آپ اسے اس کے ذریعے تلاش کر سکتے ہیں۔ MAX AVAIL کمانڈ آؤٹ پٹ میں ceph df ہر پول کے لیے الگ سے) OSD میں دستیاب ڈیٹا کی مقدار پر مبنی ہے۔ اگر کم از کم ایک OSD میں کافی جگہ نہیں ہے، تو اس وقت تک مزید ڈیٹا نہیں لکھا جا سکتا جب تک کہ ڈیٹا کو تمام OSDs میں صحیح طریقے سے تقسیم نہ کر دیا جائے۔

یہ ان مسائل کو واضح کرنے کے قابل ہے سیف کلسٹر کنفیگریشن مرحلے پر بڑے پیمانے پر فیصلہ کیا جاتا ہے۔. ٹولز میں سے ایک جو آپ استعمال کر سکتے ہیں۔ سیف پی جی کیلک. اس کی مدد سے، پی جی کی مطلوبہ رقم واضح طور پر شمار کی جاتی ہے۔ تاہم، آپ اس صورت حال میں بھی اس کا سہارا لے سکتے ہیں جہاں Ceph کلسٹر پہلے ہی غلط طریقے سے ترتیب دیا گیا ہے۔ یہاں یہ واضح کرنا ضروری ہے کہ فکس ورک کے حصے کے طور پر آپ کو زیادہ تر ممکنہ طور پر PGs کی تعداد کو کم کرنے کی ضرورت ہوگی، اور یہ خصوصیت Ceph کے پرانے ورژن میں دستیاب نہیں ہے (یہ صرف ورژن میں ظاہر ہوا ہے۔ Nautilus).

تو، آئیے درج ذیل تصویر کا تصور کریں: کلسٹر کی ایک حیثیت ہے۔ HEALTH_WARN OSD میں سے ایک کی جگہ ختم ہونے کی وجہ سے۔ یہ ایک غلطی کی طرف اشارہ کیا جائے گا HEALTH_WARN: 1 near full osd. اس صورتحال سے نکلنے کے لیے ذیل میں ایک الگورتھم ہے۔

سب سے پہلے، آپ کو باقی OSDs کے درمیان دستیاب ڈیٹا تقسیم کرنے کی ضرورت ہے۔ ہم نے پہلے ہی کیس میں اسی طرح کا آپریشن کیا تھا، جب ہم نے نوڈ کو "خراب" کیا تھا - صرف فرق کے ساتھ کہ اب ہمیں قدرے کم کرنے کی ضرورت ہوگی۔ reweight. مثال کے طور پر، 0.95 تک:

ceph osd reweight osd.${ID} 0.95

اس سے OSD میں ڈسک کی جگہ خالی ہو جاتی ہے اور سیف ہیلتھ میں خرابی ٹھیک ہو جاتی ہے۔ تاہم، جیسا کہ پہلے ہی ذکر کیا جا چکا ہے، یہ مسئلہ بنیادی طور پر ابتدائی مراحل میں 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 کی تعداد کو ترتیب وار تبدیل کرنا چاہیے اور دوسرے پولز میں اقدار کو تبدیل نہیں کرنا چاہیے جب تک کہ انتباہات غائب نہ ہو جائیں "ڈیگریڈڈ ڈیٹا فالتو پن" и "پی جیز کی تعداد میں کمی".

آپ یہ بھی چیک کر سکتے ہیں کہ کمانڈ آؤٹ پٹس کا استعمال کرتے ہوئے سب کچھ ٹھیک ہو گیا۔ 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 استعمال کرنے کے اپنے تجربے سے تبصرے یا اسی طرح کی دوسری کہانیاں ہیں، تو ہمیں انہیں تبصروں میں دیکھ کر خوشی ہوگی!

PS

ہمارے بلاگ پر بھی پڑھیں:

ماخذ: www.habr.com

نیا تبصرہ شامل کریں