تعارف

کچھ عرصہ پہلے مجھے فیل اوور کلسٹر تیار کرنے کا ٹاسک دیا گیا تھا۔ PostgreSQL کیایک شہر کے اندر آپٹیکل فائبر کے ذریعے منسلک کئی ڈیٹا سینٹرز میں کام کرنا، اور ایک ڈیٹا سینٹر کی ناکامی (مثال کے طور پر، بلیک آؤٹ) کو برداشت کرنے کے قابل۔ سافٹ ویئر کے طور پر جو غلطی رواداری کے لیے ذمہ دار ہے، میں نے انتخاب کیا۔ Pacemakerکیونکہ یہ فیل اوور کلسٹرز بنانے کے لیے RedHat کا آفیشل حل ہے۔ یہ اچھا ہے کیونکہ RedHat اس کے لیے مدد فراہم کرتا ہے، اور اس لیے کہ یہ حل یونیورسل (ماڈیولر) ہے۔ اس کی مدد سے، نہ صرف PostgreSQL بلکہ دیگر خدمات کے لیے بھی، یا تو معیاری ماڈیولز کا استعمال کرتے ہوئے یا انہیں مخصوص ضروریات کے لیے بنانا ممکن ہو سکے گا۔

اس فیصلے نے ایک معقول سوال اٹھایا: فیل اوور کلسٹر کتنا غلطی برداشت کرے گا؟ اس کی چھان بین کرنے کے لیے، میں نے ایک ٹیسٹ بینچ تیار کیا جو کلسٹر نوڈس پر مختلف ناکامیوں کی نقل کرتا ہے، سروس کے بحال ہونے کا انتظار کرتا ہے، ناکام نوڈ کو بازیافت کرتا ہے، اور ایک لوپ میں جانچ جاری رکھتا ہے۔ اس پروجیکٹ کو اصل میں hapgsql کہا جاتا تھا، لیکن وقت کے ساتھ ساتھ میں اس نام سے بور ہو گیا، جس میں صرف ایک حرف تھا۔ لہذا، میں نے غلطی برداشت کرنے والے ڈیٹا بیس کو کال کرنا شروع کیا (اور فلوٹ IP ان کی طرف اشارہ کرتے ہوئے) کروگن (کمپیوٹر گیم کا ایک کردار جس میں تمام اہم اعضاء کو نقل کیا جاتا ہے)، اور نوڈس، کلسٹرز اور پروجیکٹ خود tuchanka (وہ سیارہ جہاں کروگن رہتے ہیں)۔

اب انتظامیہ نے اجازت دے دی ہے۔ پروجیکٹ کو اوپن سورس کمیونٹی کے لیے MIT لائسنس کے تحت کھولیں۔. README کا جلد ہی انگریزی میں ترجمہ کیا جائے گا (کیونکہ یہ توقع کی جاتی ہے کہ مرکزی صارفین Pacemaker اور PostgreSQL ڈویلپر ہوں گے)، اور میں نے README کا پرانا روسی ورژن (جزوی طور پر) اس مضمون کی شکل میں پیش کرنے کا فیصلہ کیا۔

کلسٹرز ورچوئل مشینوں پر تعینات ہیں۔ VirtualBox. کل 12 ورچوئل مشینیں (مجموعی طور پر 36GiB) تعینات کی جائیں گی، جو 4 فالٹ ٹولرنٹ کلسٹرز (مختلف آپشنز) تشکیل دیتی ہیں۔ پہلے دو کلسٹرز دو PostgreSQL سرورز پر مشتمل ہیں، جو مختلف ڈیٹا سینٹرز میں واقع ہیں، اور ایک مشترکہ سرور گواہی c کورم آلہ (تیسرے ڈیٹا سینٹر میں ایک سستی ورچوئل مشین پر میزبانی کی گئی)، جو غیر یقینی صورتحال کو حل کرتی ہے۔ 50٪ / 50٪، اپنا ووٹ کسی ایک پارٹی کو دینا۔ تین ڈیٹا سینٹرز میں تیسرا کلسٹر: ایک آقا، دو غلام، نمبر کورم آلہ. چوتھا کلسٹر چار PostgreSQL سرورز پر مشتمل ہے، دو فی ڈیٹا سینٹر: ایک ماسٹر، باقی نقلیں، اور استعمال بھی گواہی c کورم آلہ. چوتھا دو سرورز یا ایک ڈیٹا سینٹر کی ناکامی کو برداشت کر سکتا ہے۔ اگر ضروری ہو تو اس حل کو نقل کی ایک بڑی تعداد میں پیمانہ کیا جا سکتا ہے۔

درست وقت کی خدمت این ٹی پی ڈی غلطی رواداری کے لیے بھی دوبارہ تشکیل دیا گیا، لیکن یہ طریقہ خود استعمال کرتا ہے۔ ntpd (یتیم موڈ)۔ مشترکہ سرور گواہی ایک مرکزی NTP سرور کے طور پر کام کرتا ہے، اپنے وقت کو تمام کلسٹرز میں تقسیم کرتا ہے، اس طرح تمام سرورز کو ایک دوسرے کے ساتھ ہم آہنگ کرتا ہے۔ اگر گواہی ناکام ہوجاتا ہے یا الگ تھلگ ہوجاتا ہے، پھر کلسٹر سرورز میں سے ایک (کلسٹر کے اندر) اپنا وقت تقسیم کرنا شروع کردے گا۔ معاون کیشنگ HTTP پراکسی تک بھی اٹھایا گواہیاس کی مدد سے، دیگر ورچوئل مشینوں کو یم ریپوزٹریز تک رسائی حاصل ہے۔ درحقیقت، درست وقت اور پراکسی جیسی خدمات زیادہ تر ممکنہ طور پر سرشار سرورز پر ہوسٹ کی جائیں گی، لیکن بوتھ میں ان کی میزبانی کی جاتی ہے۔ گواہی صرف ورچوئل مشینوں کی تعداد اور جگہ کو بچانے کے لیے۔

ورژن

v0۔ VirtualBox 7 پر CentOS 11 اور PostgreSQL 6.1 کے ساتھ کام کرتا ہے۔

کلسٹر ڈھانچہ

تمام کلسٹرز کو ایک سے زیادہ ڈیٹا سینٹرز میں واقع ہونے کے لیے ڈیزائن کیا گیا ہے، ایک فلیٹ نیٹ ورک میں مل کر اور ایک ڈیٹا سینٹر کی ناکامی یا نیٹ ورک کی تنہائی کو برداشت کرنا چاہیے۔ اس لیے ناممکن ہے کے خلاف تحفظ کے لئے استعمال کریں منقسم دماغ معیاری پیس میکر ٹیکنالوجی کہلاتی ہے۔ اسٹونتھ (سر میں دوسرے نوڈ کو گولی مارو) یا باڑ. اس کا خلاصہ: اگر کلسٹر میں موجود نوڈس کو شک ہونے لگتا ہے کہ کسی نوڈ میں کچھ غلط ہے، وہ جواب نہیں دے رہا ہے یا غلط برتاؤ کر رہا ہے، تو وہ اسے "بیرونی" آلات کے ذریعے زبردستی بند کر دیتے ہیں، مثال کے طور پر، IPMI یا UPS کنٹرول کارڈ۔ . لیکن یہ صرف ان صورتوں میں کام کرے گا جہاں، ایک ہی ناکامی کی صورت میں، IPMI یا UPS سرور کام کرنا جاری رکھے۔ یہاں ہم ایک بہت زیادہ تباہ کن ناکامی سے بچانے کا ارادہ رکھتے ہیں، جب پورا ڈیٹا سینٹر ناکام ہو جاتا ہے (مثال کے طور پر، طاقت کھو دیتا ہے)۔ اور اس طرح کے انکار کے ساتھ، سب کچھ سٹونتھ-آلات (IPMI، UPS، وغیرہ) بھی کام نہیں کریں گے۔

اس کے بجائے، نظام کورم کے خیال پر مبنی ہے. تمام نوڈس کی آواز ہوتی ہے، اور صرف وہی کام کر سکتے ہیں جو تمام نوڈس کے نصف سے زیادہ دیکھ سکتے ہیں۔ "نصف + 1" کی اس مقدار کو کہا جاتا ہے۔ کورم. اگر کورم پورا نہیں ہوتا ہے، تو نوڈ فیصلہ کرتا ہے کہ یہ نیٹ ورک آئسولیشن میں ہے اور اسے اپنے وسائل کو بند کرنا چاہیے، یعنی یہ وہی ہے جو ہے تقسیم دماغ کی حفاظت. اگر اس رویے کا ذمہ دار سافٹ ویئر کام نہیں کرتا ہے، تو ایک واچ ڈاگ، مثال کے طور پر، IPMI پر مبنی، کام کرنا پڑے گا۔

اگر نوڈس کی تعداد برابر ہے (دو ڈیٹا سینٹرز میں ایک کلسٹر)، تو نام نہاد غیر یقینی صورتحال پیدا ہو سکتی ہے۔ 50٪ / 50٪ (آدھا آدھا) جب نیٹ ورک کی تنہائی کلسٹر کو بالکل نصف میں تقسیم کرتی ہے۔ لہذا، نوڈس کی ایک برابر تعداد کے لئے، ہم شامل کرتے ہیں کورم آلہ ایک غیر ضروری ڈیمون ہے جسے تیسرے ڈیٹا سینٹر میں سب سے سستی ورچوئل مشین پر لانچ کیا جا سکتا ہے۔ وہ اپنا ووٹ کسی ایک طبقے کو دیتا ہے (جسے وہ دیکھتا ہے) اور اس طرح 50%/50% غیر یقینی صورتحال کو حل کرتا ہے۔ میں نے اس سرور کا نام دیا جس پر کورم ڈیوائس لانچ کی جائے گی۔ گواہی (repmgr سے اصطلاحات، مجھے یہ پسند آیا)۔

وسائل کو ایک جگہ سے دوسری جگہ منتقل کیا جا سکتا ہے، مثال کے طور پر، ناقص سرورز سے صحت مند سرورز تک، یا سسٹم ایڈمنسٹریٹرز کے حکم پر۔ تاکہ کلائنٹس کو معلوم ہو کہ ان کے مطلوبہ وسائل کہاں واقع ہیں (کہاں جڑنا ہے؟) تیرتا IP (فلوٹ IP)۔ یہ آئی پیز ہیں جو پیس میکر نوڈس کے گرد گھوم سکتے ہیں (ہر چیز فلیٹ نیٹ ورک پر ہے)۔ ان میں سے ہر ایک وسیلہ (سروس) کی علامت ہے اور وہ جگہ ہوگی جہاں آپ کو اس سروس تک رسائی حاصل کرنے کے لیے جڑنے کی ضرورت ہے (ہمارے معاملے میں، ڈیٹا بیس)۔

ٹوچنکا 1 (کمپیکشن کے ساتھ سرکٹ)

ساخت

خیال یہ تھا کہ ہمارے پاس کم بوجھ کے ساتھ بہت سے چھوٹے ڈیٹا بیس ہیں، جن کے لیے صرف پڑھنے کے لین دین کے لیے گرم اسٹینڈ بائی موڈ میں ایک وقف شدہ غلام سرور کو برقرار رکھنا غیر منافع بخش ہے (اس طرح کے وسائل کے ضیاع کی کوئی ضرورت نہیں ہے)۔

ہر ڈیٹا سینٹر میں ایک سرور ہوتا ہے۔ ہر سرور کی دو پوسٹگری ایس کیو ایل مثالیں ہوتی ہیں (پوسٹگری ایس کیو ایل کی اصطلاح میں انہیں کلسٹرز کہا جاتا ہے، لیکن الجھن سے بچنے کے لیے میں ان کو مثالیں کہوں گا (دوسرے ڈیٹا بیس کے ساتھ مشابہت کے ساتھ)، اور میں صرف پیس میکر کلسٹر کلسٹر کہوں گا)۔ ایک مثال ماسٹر موڈ میں کام کرتی ہے، اور صرف یہ خدمات فراہم کرتی ہے (صرف فلوٹ IP اس کی طرف جاتا ہے)۔ دوسری مثال دوسرے ڈیٹا سینٹر کے لیے غلام کے طور پر کام کرتی ہے، اور خدمات صرف اس صورت میں فراہم کرے گی جب اس کا مالک ناکام ہو جائے۔ چونکہ زیادہ تر وقت میں دو میں سے صرف ایک مثال (ماسٹر) خدمات فراہم کرے گی (درخواستیں انجام دیں)، تمام سرور وسائل ماسٹر کے لیے بہتر بنائے گئے ہیں (میموری مشترکہ_بفرز کیشے وغیرہ کے لیے مختص کی گئی ہے)، لیکن اس لیے کہ دوسری مثال ڈیٹا سینٹرز میں سے کسی ایک کی ناکامی کی صورت میں (فائل سسٹم کیشے کے ذریعے سب سے زیادہ آپریشن کے باوجود) کافی وسائل بھی ہیں۔ غلام کلسٹر کے عام آپریشن کے دوران خدمات فراہم نہیں کرتا ہے (صرف پڑھنے کی درخواستیں انجام نہیں دیتا ہے)، تاکہ ایک ہی مشین پر مالک کے ساتھ وسائل کی جنگ نہ ہو۔

دو نوڈس کی صورت میں، غلطی کی برداشت صرف غیر مطابقت پذیر نقل کے ساتھ ہی ممکن ہے، کیونکہ ہم وقت ساز نقل کے ساتھ، غلام کی ناکامی آقا کے رکنے کا باعث بنے گی۔

گواہی دینے میں ناکامی۔

گواہی دینے میں ناکامی (کورم آلہ) میں صرف Tuchanka1 کلسٹر پر غور کروں گا، باقی سب کے ساتھ یہ ایک ہی کہانی ہوگی۔ اگر گواہ ناکام ہوجاتا ہے، تو کلسٹر ڈھانچے میں کچھ بھی نہیں بدلے گا، سب کچھ اسی طرح کام کرتا رہے گا جس طرح اس نے کیا تھا۔ لیکن کورم 2 میں سے 3 ہو جائے گا، اور اس وجہ سے کوئی بھی ناکامی کلسٹر کے لیے مہلک ہو گی۔ اسے اب بھی فوری طور پر ٹھیک کرنا پڑے گا۔

Tuchanka1 انکار

Tuchanka1 کے ڈیٹا سینٹرز میں سے ایک کی ناکامی۔ اس معاملے میں گواہی دوسرے ڈیٹا سینٹر میں دوسرے نوڈ پر ووٹ ڈالتا ہے۔ وہاں، سابق غلام ایک ماسٹر میں بدل جاتا ہے، نتیجے کے طور پر، دونوں آقاؤں ایک ہی سرور پر کام کرتے ہیں اور ان کے دونوں فلوٹ آئی پی ان کی طرف اشارہ کرتے ہیں۔

Tuchanka2 (کلاسیکی)

ساخت

دو نوڈس کی کلاسک اسکیم۔ ایک پر آقا کام کرتا ہے، دوسرے پر غلام۔ دونوں درخواستوں پر عمل کر سکتے ہیں (غلام صرف پڑھا جاتا ہے)، لہذا دونوں کو فلوٹ IP کے ذریعے اشارہ کیا جاتا ہے: krogan2 ماسٹر ہے، krogan2s1 غلام ہے۔ آقا اور غلام دونوں میں عیب برداشت ہوگا۔

دو نوڈس کی صورت میں، غلطی کی برداشت صرف غیر مطابقت پذیر نقل کے ساتھ ہی ممکن ہے، کیونکہ مطابقت پذیر نقل کے ساتھ، غلام کی ناکامی آقا کے رکنے کا باعث بنے گی۔

Tuchanka2 انکار

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

Tuchanka4 (بہت سے غلام)

ساخت

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

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

Tuchanka4 انکار

اگر ایک ڈیٹا سینٹر (یعنی دو سرورز) ناکام ہوجاتا ہے، تو دوسرے کے لیے گواہی ووٹ دیں۔ نتیجے کے طور پر، دوسرے ڈیٹا سینٹر میں دو سرور چل رہے ہیں: ایک ماسٹر چلا رہا ہے، اور ماسٹر فلوٹ IP اس کی طرف اشارہ کرتا ہے (پڑھنے کے لیے لکھنے کی درخواستیں وصول کرنے کے لیے)؛ اور دوسرے سرور پر ایک غلام ہے جو ہم وقت ساز نقل کے ساتھ چل رہا ہے، اور غلام فلوٹ IPs میں سے ایک اس کی طرف اشارہ کرتا ہے (صرف پڑھنے کی درخواستوں کے لیے)۔

نوٹ کرنے والی پہلی بات یہ ہے کہ تمام غلام فلوٹ IPs کارکن نہیں ہوں گے، لیکن صرف ایک۔ اور اس کے ساتھ صحیح طریقے سے کام کرنے کے لیے یہ ضروری ہوگا۔ ایس کیو ایل پراکسی تمام درخواستوں کو صرف باقی فلوٹ IP پر بھیج دیا گیا؛ اور اگر ایس کیو ایل پراکسی نہیں، پھر آپ کنکشن یو آر ایل میں کوما سے الگ کیے گئے تمام فلوٹ IP غلاموں کی فہرست بنا سکتے ہیں۔ اس صورت میں، کے ساتھ libpq کنکشن پہلے کام کرنے والے IP سے ہوگا، یہ خودکار ٹیسٹنگ سسٹم میں کیا جاتا ہے۔ شاید دوسری لائبریریوں میں، مثال کے طور پر، JDBC، یہ کام نہیں کرے گا اور ضروری ہے۔ ایس کیو ایل پراکسی. ایسا اس لیے کیا جاتا ہے کیونکہ غلاموں کے لیے فلوٹ آئی پیز کو ایک سرور پر بیک وقت اٹھانے سے منع کیا جاتا ہے، تاکہ اگر ان میں سے کئی چل رہے ہوں تو انہیں غلام سرورز میں یکساں طور پر تقسیم کیا جائے۔

دوسرا: ڈیٹا سینٹر کی ناکامی کی صورت میں بھی، ہم وقت ساز نقل کو برقرار رکھا جائے گا۔ اور یہاں تک کہ اگر ثانوی ناکامی واقع ہوتی ہے، یعنی، باقی ڈیٹا سینٹر کے دو سرورز میں سے ایک ناکام ہوجاتا ہے، کلسٹر، اگرچہ یہ خدمات فراہم کرنا بند کردے گا، پھر بھی ان تمام پرعزم لین دین کے بارے میں معلومات کو برقرار رکھے گا جن کے لیے اس نے کمٹمنٹ کی تصدیق کی ہے۔ (ثانوی ناکامی کی صورت میں نقصان کی کوئی معلومات نہیں ہوگی)۔

Tuchanka3 (3 ڈیٹا سینٹرز)

ساخت

یہ ایسی صورت حال کے لیے ایک کلسٹر ہے جہاں تین مکمل طور پر کام کرنے والے ڈیٹا سینٹرز ہیں، جن میں سے ہر ایک میں مکمل طور پر کام کرنے والا ڈیٹا بیس سرور ہے۔ اس معاملے میں کورم آلہ ضروری نہیں. ایک ڈیٹا سینٹر میں ایک آقا کا عملہ ہوتا ہے، باقی دو غلاموں کے ذریعے ہوتے ہیں۔ نقل مطابقت پذیر ہے، ANY ٹائپ کریں (slave1, slave2)، یعنی کلائنٹ کو ایک کمٹ کی تصدیق اس وقت ملے گی جب غلاموں میں سے کوئی بھی پہلا جواب دے گا کہ اس نے کمٹمنٹ کو قبول کر لیا ہے۔ وسائل کی نشاندہی آقا کے لیے ایک فلوٹ IP اور دو غلاموں کے لیے ہوتی ہے۔ Tuchanka4 کے برعکس، تینوں فلوٹ IPs غلطی کو برداشت کرنے والے ہیں۔ صرف پڑھنے کے لیے SQL سوالات کو متوازن کرنے کے لیے آپ استعمال کر سکتے ہیں۔ ایس کیو ایل پراکسی (علحدہ غلطی رواداری کے ساتھ)، یا ایک غلام فلوٹ آئی پی کو آدھے کلائنٹس کو تفویض کریں، اور دوسرا آدھا دوسرے کو۔

Tuchanka3 انکار

اگر ڈیٹا سینٹرز میں سے ایک ناکام ہوجاتا ہے، تو دو باقی رہتے ہیں۔ ایک میں، ماسٹر سے ماسٹر اور فلوٹ IP اٹھائے جاتے ہیں، دوسرے میں - غلام اور دونوں غلام فلوٹ IP (مثال کے طور پر دونوں غلام فلوٹ IPs سے تمام کنکشن قبول کرنے کے لیے وسائل کا دوگنا ذخیرہ ہونا ضروری ہے)۔ آقاؤں اور غلاموں کے درمیان ہم وقت ساز نقل۔ اس کے علاوہ، کلسٹر دو ڈیٹا سینٹرز کی تباہی کی صورت میں پرعزم اور تصدیق شدہ لین دین کے بارے میں معلومات کو محفوظ کرے گا (معلومات کا کوئی نقصان نہیں ہوگا) (اگر وہ بیک وقت تباہ نہیں ہوتے ہیں)۔

میں نے فائل کی ساخت اور تعیناتی کی تفصیلی وضاحت شامل نہ کرنے کا فیصلہ کیا۔ جو کوئی بھی کھیلنا چاہتا ہے وہ README میں یہ سب پڑھ سکتا ہے۔ میں صرف خودکار جانچ کی تفصیل فراہم کر رہا ہوں۔

خودکار جانچ کا نظام

مختلف فالٹس کی تقلید کرکے کلسٹرز کی فالٹ ٹولرنس کو جانچنے کے لیے، ایک خودکار ٹیسٹنگ سسٹم بنایا گیا ہے۔ اسکرپٹ کے ذریعے لانچ کیا گیا۔ test/failure. اسکرپٹ کلسٹرز کی تعداد کو پیرامیٹرز کے طور پر لے سکتا ہے جن کی آپ جانچ کرنا چاہتے ہیں۔ مثال کے طور پر یہ حکم:

test/failure 2 3

صرف دوسرے اور تیسرے کلسٹر کی جانچ کرے گا۔ اگر پیرامیٹرز کی وضاحت نہیں کی گئی ہے، تو تمام کلسٹرز کی جانچ کی جائے گی۔ تمام کلسٹرز کو متوازی طور پر جانچا جاتا ہے، اور نتیجہ tmux پینل میں ظاہر ہوتا ہے۔ Tmux ایک وقف شدہ tmux سرور استعمال کرتا ہے، لہذا اسکرپٹ کو پہلے سے طے شدہ tmux کے تحت چلایا جاسکتا ہے، جس کے نتیجے میں ایک نیسٹڈ tmux ہوتا ہے۔ میں ٹرمینل کو ایک بڑی ونڈو میں اور چھوٹے فونٹ کے ساتھ استعمال کرنے کی تجویز کرتا ہوں۔ جانچ شروع ہونے سے پہلے، تمام ورچوئل مشینیں اسکرپٹ کے مکمل ہونے کے وقت اسنیپ شاٹ پر واپس لوٹ جاتی ہیں۔ setup.

ٹرمینل کو جانچے جانے والے کلسٹرز کی تعداد کے مطابق کالموں میں تقسیم کیا گیا ہے؛ بطور ڈیفالٹ (اسکرین شاٹ میں) چار ہیں۔ میں Tuchanka2 کی مثال استعمال کرتے ہوئے کالم کے مندرجات کو بیان کروں گا۔ اسکرین شاٹ میں پینل نمبر دیے گئے ہیں:

1. ٹیسٹ کے اعدادوشمار یہاں دکھائے گئے ہیں۔ کالم:
   • ناکامی - ٹیسٹ کا نام (اسکرپٹ میں فنکشن) جو غلطی کی تقلید کرتا ہے۔
   • رد عمل - سیکنڈ میں ریاضی کا اوسط وقت جس کے دوران کلسٹر نے اپنی فعالیت کو بحال کیا۔ اس کی پیمائش اسکرپٹ کے آغاز سے لے کر اس وقت تک کی جاتی ہے جب تک کہ کلسٹر اپنی فعالیت کو بحال کرتا ہے اور خدمات کی فراہمی جاری رکھنے کے قابل ہوتا ہے۔ اگر وقت بہت کم ہے، مثال کے طور پر، چھ سیکنڈ (یہ کئی بندوں کے ساتھ کلسٹرز میں ہوتا ہے (Tuchanka3 اور Tuchanka4))، اس کا مطلب ہے کہ غلطی غیر مطابقت پذیر غلام پر تھی اور اس نے کارکردگی کو کسی بھی طرح متاثر نہیں کیا۔ کلسٹر اسٹیٹ سوئچز۔
   • انحراف - قدر کے پھیلاؤ (درستگی) کو ظاہر کرتا ہے۔ رد عمل معیاری انحراف کا طریقہ استعمال کرتے ہوئے
   • شمار - یہ ٹیسٹ کتنی بار کیا گیا۔
2. ایک مختصر لاگ آپ کو اندازہ کرنے کی اجازت دیتا ہے کہ کلسٹر اس وقت کیا کر رہا ہے۔ تکرار (ٹیسٹ) نمبر، ٹائم اسٹیمپ اور آپریشن کا نام ظاہر ہوتا ہے۔ بہت لمبا دوڑنا (> 5 منٹ) کسی مسئلے کی نشاندہی کرتا ہے۔
3. دل (دل) - موجودہ وقت۔ کارکردگی کے بصری تشخیص کے لیے ماسٹرز۔ موجودہ وقت فلوٹ آئی پی ماسٹر کا استعمال کرتے ہوئے اس کے ٹیبل پر مسلسل لکھا جاتا ہے۔ کامیاب ہونے کی صورت میں نتیجہ اس پینل میں ظاہر ہوتا ہے۔
4. شکست دے دی (پلس) - "موجودہ وقت"، جو پہلے اسکرپٹ کے ذریعہ ریکارڈ کیا گیا تھا۔ دل ماسٹر کرنے کے لئے، اب سے پڑھیں غلام اس کے فلوٹ IP کے ذریعے۔ آپ کو غلام اور نقل کی کارکردگی کا بصری طور پر جائزہ لینے کی اجازت دیتا ہے۔ Tuchanka1 میں فلوٹ آئی پی کے ساتھ کوئی غلام نہیں ہے (خدمات فراہم کرنے والا کوئی غلام نہیں)، لیکن دو مثالیں (DBs) ہیں، اس لیے اسے یہاں نہیں دکھایا جائے گا۔ شکست دے دیاور دل دوسری مثال.
5. افادیت کا استعمال کرتے ہوئے کلسٹر صحت کی نگرانی کرنا pcs mon. ساخت، نوڈس میں وسائل کی تقسیم اور دیگر مفید معلومات دکھاتا ہے۔
6. کلسٹر میں موجود ہر ورچوئل مشین سے سسٹم کی نگرانی یہاں دکھائی جاتی ہے۔ کلسٹر میں کتنی ورچوئل مشینیں ہیں اس پر انحصار کرتے ہوئے اس طرح کے مزید پینل ہو سکتے ہیں۔ دو گراف سی پی یو لوڈ (ورچوئل مشینوں میں دو پروسیسر ہوتے ہیں)، ورچوئل مشین کا نام، سسٹم لوڈ۔ (جس کا نام لوڈ ایوریج ہے کیونکہ اس کا اوسط 5، 10 اور 15 منٹ سے زیادہ ہے)، ڈیٹا اور میموری ایلوکیشن پر کارروائی کریں۔
7. اسکرپٹ کا ٹریس ٹیسٹنگ انجام دے رہا ہے۔ خرابی کی صورت میں - آپریشن میں اچانک رکاوٹ یا انتظار کا نہ ختم ہونے والا چکر - یہاں آپ اس رویے کی وجہ دیکھ سکتے ہیں۔

ٹیسٹنگ دو مراحل میں کی جاتی ہے۔ سب سے پہلے، اسکرپٹ تمام قسم کے ٹیسٹوں سے گزرتا ہے، تصادفی طور پر ایک ورچوئل مشین کا انتخاب کرتا ہے جس پر اس ٹیسٹ کو لاگو کیا جائے۔ پھر جانچ کا ایک نہ ختم ہونے والا چکر چلایا جاتا ہے، ورچوئل مشینیں اور فالٹ کو ہر بار بے ترتیب طور پر منتخب کیا جاتا ہے۔ ٹیسٹنگ اسکرپٹ (نیچے پینل) کا اچانک ختم ہو جانا یا کسی چیز کے انتظار کا نہ ختم ہونے والا لوپ (> ایک آپریشن کے لیے 5 منٹ تک عمل درآمد کا وقت، یہ ٹریس میں دیکھا جا سکتا ہے) اس بات کی نشاندہی کرتا ہے کہ اس کلسٹر پر کچھ ٹیسٹ ناکام ہو گئے ہیں۔

ہر ٹیسٹ مندرجہ ذیل آپریشنز پر مشتمل ہوتا ہے۔

1. ایک فنکشن شروع کریں جو غلطی کی تقلید کرتا ہے۔
2. تیار؟ - کلسٹر کے بحال ہونے کا انتظار (جب تمام خدمات فراہم کی جاتی ہیں)۔
3. کلسٹر ریکوری ٹائم آؤٹ دکھاتا ہے (رد عمل).
4. درست کریں - کلسٹر کی "مرمت" کی جا رہی ہے۔ جس کے بعد اسے مکمل طور پر آپریشنل حالت میں واپس آنا چاہیے اور اگلی خرابی کے لیے تیار رہنا چاہیے۔

یہاں ٹیسٹوں کی ایک فہرست ہے جس کی تفصیل کے ساتھ وہ کیا کرتے ہیں:

• فورک بم: فورک بم کا استعمال کرتے ہوئے "آؤٹ آف میموری" بناتا ہے۔
• جگہ سے باہر: ہارڈ ڈرائیو بھری ہوئی ہے۔ لیکن ٹیسٹ بجائے علامتی ہے؛ معمولی بوجھ کے ساتھ جو ٹیسٹنگ کے دوران پیدا ہوتا ہے، PostgreSQL عام طور پر اس وقت ناکام نہیں ہوتا جب ہارڈ ڈرائیو بھر جاتی ہے۔
• Postgres-KILL: کمانڈ کے ساتھ PostgreSQL کو مار ڈالتا ہے۔ killall -KILL postgres.
• پوسٹگریس-اسٹاپ: PostgreSQL کمانڈ ہینگ کرتا ہے۔ killall -STOP postgres.
• بجلی بند: کمانڈ کے ساتھ ورچوئل مشین کو "ڈی اینرجائز" کرتا ہے۔ VBoxManage controlvm "виртуалка" poweroff.
• پھر سیٹ کریں: کمانڈ کے ساتھ ورچوئل مشین کو اوورلوڈ کرتا ہے۔ VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: کمانڈ کے ساتھ SBD شیطان کو معطل کرتا ہے۔ killall -STOP sbd.
• شٹ ڈاؤن: SSH کے ذریعے ورچوئل مشین کو کمانڈ بھیجتا ہے۔ systemctl poweroff، نظام احسن طریقے سے بند ہو جاتا ہے۔
• لنک ختم کریں۔: نیٹ ورک تنہائی، کمانڈ VBoxManage controlvm "виртуалка" setlinkstate1 off.

معیاری tmux کمانڈ "kill-window" کا استعمال کرتے ہوئے جانچ مکمل کرنا Ctrl-b اور، یا "detach-client" کمانڈ Ctrl-b d: اس مقام پر ٹیسٹنگ ختم ہوجاتی ہے، tmux بند ہوجاتا ہے، ورچوئل مشینیں بند ہوجاتی ہیں۔

جانچ کے دوران مسائل کی نشاندہی کی گئی۔

• اس وقت واچ ڈاگ ڈیمن ایس بی ڈی مشاہدہ شدہ ڈیمنز کو روکنے پر کام کرتا ہے، لیکن انہیں منجمد نہیں کرتا۔ اور، نتیجے کے طور پر، خرابیاں جو صرف منجمد کرنے کا باعث بنتی ہیں Corosync и Pacemaker، لیکن پھانسی نہیں ایس بی ڈی. چیک کے لیے Corosync پہلے سے ہی ہے PR#83 (GitHub پر at ایس بی ڈی)، دھاگے میں قبول کر لیا گیا۔ ماسٹر. انہوں نے وعدہ کیا (PR#83 میں) کہ Pacemaker کے لیے بھی کچھ ایسا ہی ہوگا، مجھے امید ہے کہ اس کے بعد ریڈھاٹ 8 کروں گا. لیکن اس طرح کی "خرابیاں" قیاس آرائی پر مبنی ہیں اور آسانی سے مصنوعی طور پر استعمال کی جا سکتی ہیں، مثال کے طور پر، killall -STOP corosyncلیکن حقیقی زندگی میں کبھی نہیں ملتے۔

• У Pacemaker کے لئے ورژن میں CentOS 7 غلط طریقے سے مقرر sync_timeout у کورم آلہ، اس کے نتیجے میں اگر ایک نوڈ ناکام ہو گیا تو، کچھ امکان کے ساتھ دوسرا نوڈ بھی دوبارہ شروع ہو گیا۔، جس کی طرف ماسٹر کو منتقل ہونا تھا۔ افزائش سے افاقہ sync_timeout у کورم آلہ تعیناتی کے دوران (اسکرپٹ میں setup/setup1)۔ اس ترمیم کو ڈویلپرز نے قبول نہیں کیا۔ Pacemaker، اس کے بجائے انہوں نے بنیادی ڈھانچے کو اس طرح سے دوبارہ ڈیزائن کرنے کا وعدہ کیا (کچھ غیر متعین مستقبل میں) کہ اس ٹائم آؤٹ کا خود بخود حساب لگایا جائے گا۔

• اگر ڈیٹا بیس کی ترتیب اس کی وضاحت کرتی ہے۔ LC_MESSAGES (متنی پیغامات) یونی کوڈ استعمال کیا جا سکتا ہے، جیسے ru_RU.UTF-8، پھر آغاز پر پوسٹ گریڈ ایسے ماحول میں جہاں لوکیل UTF-8 نہیں ہے، خالی ماحول میں کہیں (یہاں پیس میکر+pgsqlms(paf) چلتا ہے۔ پوسٹ گریڈ)، پھر لاگ میں UTF-8 حروف کی بجائے سوالیہ نشانات ہوں گے۔. PostgreSQL ڈویلپرز اس بات پر متفق نہیں ہوئے ہیں کہ اس معاملے میں کیا کرنا ہے۔ اس کی لاگت آتی ہے، آپ کو انسٹال کرنے کی ضرورت ہے۔ LC_MESSAGES=en_US.UTF-8 ڈیٹا بیس کی مثال کو تشکیل دیتے وقت۔

• اگر wal_receiver_timeout سیٹ ہے (پہلے سے طے شدہ طور پر یہ 60s ہے)، تو tuchanka3 اور tuchanka4 کلسٹرز میں ماسٹر پر PostgreSQL-STOP ٹیسٹ کے دوران نقل نئے ماسٹر سے دوبارہ منسلک نہیں ہوتی ہے۔. نقل وہاں مطابقت پذیر ہے، اس لیے نہ صرف غلام رک جاتا ہے، بلکہ نیا آقا بھی۔ PostgreSQL کو ترتیب دیتے وقت wal_receiver_timeout=0 ترتیب دے کر کام کرتا ہے۔

• کبھی کبھار میں نے فورک بومب ٹیسٹ (میموری اوور فلو) میں پوسٹگری ایس کیو ایل میں نقل جمنے کا مشاہدہ کیا۔ ForkBomb کے بعد، بعض اوقات غلام نئے آقا سے دوبارہ رابطہ نہیں کر سکتے. میں نے اس کا سامنا صرف tuchanka3 اور tuchanka4 کلسٹرز میں کیا ہے، جہاں مطابقت پذیر نقل کی وجہ سے ماسٹر منجمد ہو گیا ہے۔ مسئلہ کافی دیر (تقریباً دو گھنٹے) کے بعد خود ہی چلا گیا۔ اس کو درست کرنے کے لیے مزید تحقیق کی ضرورت ہے۔ علامات پچھلے بگ سے ملتے جلتے ہیں، جو ایک مختلف وجہ سے ہوتا ہے، لیکن اسی کے نتائج کے ساتھ۔

کروگن کی تصویر لی گئی ہے۔ منحرف فن مصنف کی اجازت سے:

ماخذ: www.habr.com