🥇 ترانتول کارتوس: لوا بیک اینڈ کو تین لائنوں میں شارڈنگ کرنا

Mail.ru گروپ میں ہمارے پاس Tarantool ہے - یہ Lua میں ایک ایپلیکیشن سرور ہے، جو ڈیٹا بیس کے طور پر بھی دوگنا ہو جاتا ہے (یا اس کے برعکس؟) یہ تیز اور ٹھنڈا ہے، لیکن ایک سرور کی صلاحیتیں اب بھی لامحدود نہیں ہیں۔ عمودی اسکیلنگ بھی کوئی علاج نہیں ہے، اس لیے ٹرانٹول کے پاس افقی اسکیلنگ کے لیے ٹولز ہیں - vshard ماڈیول ہے [1]. یہ آپ کو متعدد سرورز پر ڈیٹا کو تیز کرنے کی اجازت دیتا ہے، لیکن آپ کو اسے ترتیب دینے اور کاروباری منطق کو منسلک کرنے کے لیے اس کے ساتھ ٹنکر کرنا پڑتا ہے۔

اچھی خبر: ہم نے کچھ بڑے شاٹس جمع کیے ہیں (جیسے ہے [2], ہے [3]) اور ایک اور فریم ورک بنایا جو اس مسئلے کے حل کو نمایاں طور پر آسان بنائے گا۔

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

اصل مسئلہ کیا ہے؟

ہمارے پاس ٹیرانٹولا ہے، ہمارے پاس ویشارڈ ہے - آپ مزید کیا چاہتے ہیں؟

سب سے پہلے، یہ سہولت کا معاملہ ہے. vshard کنفیگریشن Lua ٹیبلز کے ذریعے ترتیب دی گئی ہے۔ متعدد ٹرانٹول پراسیسز کے تقسیم شدہ نظام کے درست طریقے سے کام کرنے کے لیے، ترتیب ہر جگہ ایک جیسی ہونی چاہیے۔ کوئی بھی یہ دستی طور پر نہیں کرنا چاہتا۔ لہذا، تمام قسم کے اسکرپٹ، جوابی، اور تعیناتی کے نظام استعمال کیے جاتے ہیں.

کارٹریج خود vshard کنفیگریشن کا انتظام کرتا ہے، یہ اس کی بنیاد پر کرتا ہے۔ اپنی تقسیم شدہ ترتیب. یہ بنیادی طور پر ایک سادہ YAML فائل ہے، جس کی ایک کاپی ہر Tarantool مثال میں محفوظ کی جاتی ہے۔ آسانیاں یہ ہے کہ فریم ورک خود اس کی ترتیب کی نگرانی کرتا ہے اور اس بات کو یقینی بناتا ہے کہ یہ ہر جگہ یکساں ہے۔

دوم، یہ پھر سہولت کی بات ہے۔ ویشارڈ کنفیگریشن کا کاروباری منطق کی ترقی سے کوئی تعلق نہیں ہے اور صرف پروگرامر کو اس کے کام سے ہٹاتا ہے۔ جب ہم کسی پروجیکٹ کے فن تعمیر پر بات کرتے ہیں، تو ہم اکثر انفرادی اجزاء اور ان کے تعامل کے بارے میں بات کرتے ہیں۔ کلسٹر کو 3 ڈیٹا سینٹرز میں شامل کرنے کے بارے میں سوچنا بہت جلد ہے۔

ہم نے ان مسائل کو بار بار حل کیا، اور کسی موقع پر ہم ایک ایسا نقطہ نظر تیار کرنے میں کامیاب ہو گئے جس نے ایپلیکیشن کے ساتھ اس کی پوری زندگی کے دوران کام کرنا آسان بنا دیا: تخلیق، ترقی، جانچ، CI/CD، دیکھ بھال۔

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

ٹرانٹول کارتوس کی اہم خصوصیات:

خودکار کلسٹر آرکیسٹریشن؛
نئے کرداروں کا استعمال کرتے ہوئے ایپلی کیشن کی فعالیت کو بڑھانا؛
ترقی اور تعیناتی کے لیے ایپلیکیشن ٹیمپلیٹ؛
بلٹ میں خودکار شارڈنگ؛
Luatest ٹیسٹنگ فریم ورک کے ساتھ انضمام؛
WebUI اور API کا استعمال کرتے ہوئے کلسٹر مینجمنٹ؛
پیکیجنگ اور تعیناتی کے اوزار.

ہیلو ، دنیا!

میں خود فریم ورک دکھانے کا انتظار نہیں کر سکتا، اس لیے ہم فن تعمیر کے بارے میں کہانی کو بعد میں چھوڑ دیں گے اور کچھ آسان سے شروع کریں گے۔ اگر ہم فرض کر لیں کہ ترن ٹول خود پہلے سے نصب ہے، تو جو کچھ باقی ہے وہ کرنا ہے۔

$ tarantoolctl rocks install cartridge-cli
$ export PATH=$PWD/.rocks/bin/:$PATH

یہ دونوں کمانڈز کمانڈ لائن یوٹیلیٹیز کو انسٹال کریں گی اور آپ کو ٹیمپلیٹ سے اپنی پہلی ایپلیکیشن بنانے کی اجازت دیں گی۔

$ cartridge create --name myapp

اور یہ وہی ہے جو ہمیں ملتا ہے:

myapp/
├── .git/
├── .gitignore
├── app/roles/custom.lua
├── deps.sh
├── init.lua
├── myapp-scm-1.rockspec
├── test
│   ├── helper
│   │   ├── integration.lua
│   │   └── unit.lua
│   ├── helper.lua
│   ├── integration/api_test.lua
│   └── unit/sample_test.lua
└── tmp/

یہ ایک تیار شدہ "ہیلو، ورلڈ!" کے ساتھ ایک گٹ ذخیرہ ہے! درخواست آئیے اسے فوراً چلانے کی کوشش کرتے ہیں، پہلے سے انحصار انسٹال کر چکے ہیں (بشمول خود فریم ورک):

$ tarantoolctl rocks make
$ ./init.lua --http-port 8080

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

ایپلی کیشن ڈویلپمنٹ

ذرا تصور کریں، ہم ایک ایسا پروجیکٹ ڈیزائن کر رہے ہیں جس میں ڈیٹا حاصل کرنا، اسے محفوظ کرنا اور دن میں ایک بار رپورٹ بنانا ضروری ہے۔

ہم ایک خاکہ بنانا شروع کرتے ہیں اور اس پر تین اجزاء رکھتے ہیں: گیٹ وے، اسٹوریج اور شیڈولر۔ ہم مزید فن تعمیر پر کام کر رہے ہیں۔ چونکہ ہم vshard کو اسٹوریج کے طور پر استعمال کرتے ہیں، اس لیے ہم vshard-router اور vshard-storage کو اسکیم میں شامل کرتے ہیں۔ نہ تو گیٹ وے اور نہ ہی شیڈیولر براہ راست اسٹوریج تک رسائی حاصل کرے گا؛ راؤٹر اسی کے لیے ہے، اسی لیے اسے بنایا گیا تھا۔

یہ خاکہ اب بھی قطعی طور پر اس بات کی نمائندگی نہیں کرتا ہے کہ ہم اس منصوبے میں کیا تعمیر کریں گے کیونکہ اجزاء تجریدی نظر آتے ہیں۔ ہمیں ابھی بھی یہ دیکھنے کی ضرورت ہے کہ یہ حقیقی ٹرانٹول پر کیسے پیش کیا جائے گا - آئیے عمل کے لحاظ سے اپنے اجزاء کو گروپ بنائیں۔

vshard-router اور گیٹ وے کو الگ الگ مثالوں پر رکھنے کا کوئی فائدہ نہیں ہے۔ اگر یہ پہلے سے ہی روٹر کی ذمہ داری ہے تو ہمیں ایک بار پھر نیٹ ورک کو سرف کرنے کی ضرورت کیوں ہے؟ انہیں اسی عمل کے اندر چلایا جانا چاہیے۔ یعنی گیٹ وے اور vshard.router.cfg دونوں ایک ہی عمل میں شروع کیے گئے ہیں، اور انہیں مقامی طور پر بات چیت کرنے دیں۔

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

اور جب سٹیجنگ یا پروڈکشن میں تعیناتی کی بات آتی ہے، تو ہم ہارڈ ویئر کی صلاحیتوں کے لحاظ سے ہر ٹرانٹول پروسیس کو اس کے اپنے کرداروں کا سیٹ تفویض کریں گے:

ٹوپولوجی مینجمنٹ

اس بارے میں معلومات کہ کون سے کردار کہاں چل رہے ہیں کہیں نہ کہیں ذخیرہ ہونا ضروری ہے۔ اور یہ "کہیں" تقسیم شدہ ترتیب ہے، جس کا میں نے اوپر ذکر کیا ہے۔ اس کے بارے میں سب سے اہم چیز کلسٹر ٹوپولوجی ہے۔ یہاں 3 ترانٹول عملوں کے 5 نقل کرنے والے گروپ ہیں:

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

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

کرداروں کی زندگی

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

function init()
function validate_config()
function apply_config()
function stop()

ہر کردار کا ایک فنکشن ہوتا ہے۔ init. اسے ایک بار کہا جاتا ہے جب یا تو رول فعال ہوتا ہے یا جب Tarantool دوبارہ شروع ہوتا ہے۔ وہاں یہ آسان ہے، مثال کے طور پر، box.space.create کو شروع کرنا، یا شیڈیولر کچھ بیک گراؤنڈ فائبر لانچ کر سکتا ہے جو مخصوص وقت کے وقفوں پر کام کرے گا۔

ایک فنکشن init کافی نہیں ہو سکتا. کارٹریج رولز کو تقسیم شدہ کنفیگریشن سے فائدہ اٹھانے کی اجازت دیتا ہے جسے یہ ٹوپولوجی کو ذخیرہ کرنے کے لیے استعمال کرتا ہے۔ ہم اسی کنفیگریشن میں ایک نئے سیکشن کا اعلان کر سکتے ہیں اور اس میں بزنس کنفیگریشن کا ایک ٹکڑا محفوظ کر سکتے ہیں۔ میری مثال میں، یہ شیڈیولر رول کے لیے ڈیٹا سکیما یا شیڈول سیٹنگ ہو سکتا ہے۔

کلسٹر کالز validate_config и apply_config ہر بار جب تقسیم شدہ ترتیب تبدیل ہوتی ہے۔ جب ایک کنفیگریشن کو دو فیز کمٹ کے ذریعے لاگو کیا جاتا ہے، تو کلسٹر چیک کرتا ہے کہ ہر کردار اس نئی کنفیگریشن کو قبول کرنے کے لیے تیار ہے اور اگر ضروری ہو تو صارف کو غلطی کی اطلاع دیتا ہے۔ جب ہر کوئی اس بات سے اتفاق کرتا ہے کہ ترتیب عام ہے، پھر apply_config.

کرداروں کا بھی ایک طریقہ ہوتا ہے۔ stop، جو کردار کے آؤٹ پٹ کو صاف کرنے کے لئے درکار ہے۔ اگر ہم یہ کہتے ہیں کہ اس سرور پر شیڈیولر کی مزید ضرورت نہیں ہے، تو یہ ان ریشوں کو روک سکتا ہے جن کے ساتھ یہ شروع ہوا تھا۔ init.

کردار ایک دوسرے کے ساتھ تعامل کر سکتے ہیں۔ ہم Lua میں فنکشن کالز لکھنے کے عادی ہیں، لیکن یہ ہو سکتا ہے کہ ایک دیئے گئے عمل میں وہ کردار نہ ہو جس کی ہمیں ضرورت ہے۔ نیٹ ورک پر کالوں کی سہولت کے لیے، ہم rpc (ریموٹ پروسیجر کال) کا معاون ماڈیول استعمال کرتے ہیں، جو Tarantool میں بنائے گئے معیاری نیٹ باکس کی بنیاد پر بنایا گیا ہے۔ یہ مفید ہو سکتا ہے اگر، مثال کے طور پر، آپ کا گیٹ وے ایک دن انتظار کرنے کے بجائے، شیڈیولر سے ابھی کام کرنے کے لیے براہ راست کہنا چاہتا ہے۔

ایک اور اہم نکتہ غلطی برداشت کو یقینی بنانا ہے۔ کارٹریج صحت کی نگرانی کے لیے SWIM پروٹوکول کا استعمال کرتا ہے۔ ہے [4]. مختصراً، UDP پر عمل ایک دوسرے کے ساتھ "افواہوں" کا تبادلہ کرتے ہیں—ہر عمل اپنے پڑوسیوں کو تازہ ترین خبریں بتاتا ہے، اور وہ جواب دیتے ہیں۔ اچانک جواب نہ آنے پر ترنتول کو شک ہونے لگتا ہے کہ کچھ گڑبڑ ہے اور کچھ دیر بعد موت کا ورد کرتا ہے اور آس پاس کے سب کو یہ خبر بتانے لگتا ہے۔

اس پروٹوکول کی بنیاد پر، کارٹریج خودکار ناکامی کی پروسیسنگ کو منظم کرتا ہے۔ ہر عمل اپنے ماحول کی نگرانی کرتا ہے، اور اگر لیڈر اچانک جواب دینا بند کر دیتا ہے، تو نقل اپنا کردار سنبھال سکتی ہے، اور کارٹریج اس کے مطابق چلنے والے کرداروں کو ترتیب دیتا ہے۔

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

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

ڈوکر کے برعکس، ہم صرف ایک رول "امیج" نہیں لے سکتے، اسے دوسری مشین پر لے جا کر وہاں چلا سکتے ہیں۔ ہمارے کردار ڈوکر کنٹینرز کی طرح الگ تھلگ نہیں ہیں۔ نیز، ہم ایک مثال پر دو ایک جیسے کردار نہیں چلا سکتے۔ ایک کردار یا تو موجود ہے یا نہیں ہے؛ ایک لحاظ سے، یہ سنگلٹن ہے۔ اور تیسرا، رولز پورے ریپلیکیشن گروپ میں ایک جیسے ہونے چاہئیں، کیونکہ بصورت دیگر یہ مضحکہ خیز ہوگا - ڈیٹا ایک جیسا ہے، لیکن ترتیب مختلف ہے۔

تعیناتی کے اوزار

میں نے یہ دکھانے کا وعدہ کیا کہ کارٹریج ایپلی کیشنز کو تعینات کرنے میں کس طرح مدد کرتا ہے۔ دوسروں کے لیے زندگی آسان بنانے کے لیے، فریم ورک پیکجز RPM پیکجز:

$ cartridge pack rpm myapp -- упакует для нас ./myapp-0.1.0-1.rpm
$ sudo yum install ./myapp-0.1.0-1.rpm

انسٹال کردہ پیکیج میں آپ کی ضرورت کی تقریباً ہر چیز شامل ہے: ایپلیکیشن اور انسٹال کردہ انحصار۔ Tarantool بھی RPM پیکج کے انحصار کے طور پر سرور پر آئے گا، اور ہماری سروس شروع کرنے کے لیے تیار ہے۔ یہ systemd کے ذریعے کیا جاتا ہے، لیکن پہلے آپ کو تھوڑی سی ترتیب لکھنی ہوگی۔ کم از کم، ہر عمل کے URI کی وضاحت کریں۔ مثال کے طور پر تین کافی ہیں۔

$ sudo tee /etc/tarantool/conf.d/demo.yml <<CONFIG
myapp.router: {"advertise_uri": "localhost:3301", "http_port": 8080}
myapp.storage_A: {"advertise_uri": "localhost:3302", "http_enabled": False}
myapp.storage_B: {"advertise_uri": "localhost:3303", "http_enabled": False}
CONFIG

یہاں ایک دلچسپ nuance ہے. صرف بائنری پروٹوکول پورٹ کی وضاحت کرنے کے بجائے، ہم میزبان نام سمیت عمل کا پورا عوامی پتہ بتاتے ہیں۔ یہ ضروری ہے تاکہ کلسٹر نوڈس کو معلوم ہو کہ کس طرح ایک دوسرے سے جڑنا ہے۔ advertise_uri ایڈریس کے طور پر 0.0.0.0 استعمال کرنا برا خیال ہے؛ یہ ایک بیرونی IP ایڈریس ہونا چاہیے، ساکٹ بائنڈ نہیں۔ اس کے بغیر، کچھ بھی کام نہیں کرے گا، لہذا کارٹریج آپ کو غلط اشتہار_uri کے ساتھ نوڈ لانچ کرنے نہیں دے گا۔

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

$ sudo systemctl start myapp@router
$ sudo systemctl start myapp@storage_A
$ sudo systemctl start myapp@storage_B

کنفیگریشن میں، ہم نے HTTP پورٹ کی وضاحت کی جس پر کارٹریج ویب انٹرفیس - 8080 پیش کرتا ہے۔ آئیے اس پر جائیں اور ایک نظر ڈالیں:

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

آئیے آپ کے پسندیدہ مشروب کا ایک گلاس ڈالیں اور ایک طویل کام کے ہفتے کے بعد آرام کریں۔ درخواست استعمال کی جا سکتی ہے۔