کسی نہ کسی طرح، تاریخی طور پر، آئی ٹی انڈسٹری کو کسی بھی وجہ سے دو مشروط کیمپوں میں تقسیم کیا گیا ہے: وہ جو "کے لیے" ہیں اور وہ جو "خلاف" ہیں۔ مزید یہ کہ تنازعات کا موضوع مکمل طور پر من مانی ہو سکتا ہے۔ کون سا OS بہتر ہے: جیت یا لینکس؟ اینڈرائیڈ یا آئی او ایس اسمارٹ فون پر؟ کیا آپ کو ہر چیز کو بادلوں میں ذخیرہ کرنا چاہئے یا اسے کولڈ RAID اسٹوریج پر رکھنا چاہئے اور پیچ کو محفوظ میں رکھنا چاہئے؟ کیا پی ایچ پی والوں کو پروگرامر کہلانے کا حق ہے؟ یہ تنازعات، بعض اوقات، فطرت میں خصوصی طور پر موجود ہوتے ہیں اور کھیلوں کی دلچسپی کے علاوہ ان کی کوئی بنیاد نہیں ہوتی۔
ایسا ہی ہوا کہ کنٹینرز کی آمد اور ڈوکر اور مشروط k8s کے ساتھ اس تمام پیارے کھانے کے ساتھ، پس منظر کے مختلف شعبوں میں نئی صلاحیتوں کے استعمال کے لیے "کے لیے" اور "خلاف" بحثیں شروع ہو گئیں۔ (آئیے پہلے سے ایک ریزرویشن کر لیں کہ اگرچہ اکثر اس بحث میں کبرنیٹس کو ایک آرکیسٹریٹر کے طور پر اشارہ کیا جائے گا، لیکن اس مخصوص ٹول کا انتخاب بنیادی اہمیت کا حامل نہیں ہے۔ اس کے بجائے، آپ کسی دوسرے کو تبدیل کر سکتے ہیں جو آپ کے لیے سب سے زیادہ آسان اور مانوس معلوم ہو۔ .)
اور، ایسا لگتا ہے، یہ ایک ہی سکے کے دو رُخوں کے درمیان ایک سادہ سا جھگڑا ہوگا۔ ون بمقابلہ لینکس کے درمیان ابدی تصادم کی طرح بے حس اور بے رحم، جس میں کافی لوگ بیچ میں کہیں موجود ہیں۔ لیکن کنٹینرائزیشن کے معاملے میں، سب کچھ اتنا آسان نہیں ہے۔ عام طور پر اس طرح کے تنازعات میں کوئی دائیں طرف نہیں ہوتا، لیکن ڈیٹا بیس کو ذخیرہ کرنے کے لیے کنٹینرز کے "استعمال" یا "استعمال نہ کرنے" کی صورت میں، سب کچھ الٹا ہو جاتا ہے۔ کیونکہ ایک معنوں میں اس نقطہ نظر کے حامی اور مخالف دونوں ہی حق پر ہیں۔
روشن پہلو
لائٹ سائیڈ کی دلیل کو مختصراً ایک فقرے میں بیان کیا جا سکتا ہے: "ہیلو، 2k19 کھڑکی کے باہر ہے!" یہ یقیناً پاپولزم کی طرح لگتا ہے، لیکن اگر آپ صورتحال کو تفصیل سے دیکھیں تو اس کے فوائد ہیں۔ آئیے اب ان کو حل کرتے ہیں۔
ہم کہتے ہیں کہ آپ کے پاس ایک بڑا ویب پروجیکٹ ہے۔ یہ ابتدائی طور پر مائیکرو سروس اپروچ کی بنیاد پر بنایا جا سکتا تھا، یا کسی وقت یہ ارتقائی راستے کے ذریعے اس تک پہنچا تھا - حقیقت میں یہ بہت اہم نہیں ہے۔ آپ نے ہمارے پروجیکٹ کو الگ الگ مائیکرو سروسز میں بکھیر دیا، آرکیسٹریشن سیٹ اپ، لوڈ بیلنسنگ اور اسکیلنگ کی۔ اور اب، صاف ضمیر کے ساتھ، آپ حبرا اثرات کے دوران گرے ہوئے سرورز کو اٹھانے کے بجائے ایک موجیٹو کو جھولا میں گھونٹ دیتے ہیں۔ لیکن تمام اعمال میں آپ کو مستقل مزاج ہونا چاہیے۔ اکثر، صرف ایپلیکیشن کوڈ کو کنٹینرائز کیا جاتا ہے۔ ہمارے پاس کوڈ کے علاوہ اور کیا ہے؟
یہ ٹھیک ہے، ڈیٹا. کسی بھی پروجیکٹ کا دل اس کا ڈیٹا ہوتا ہے: یہ یا تو ایک عام DBMS - MySQL، Postgre، MongoDB، یا تلاش (ElasticSearch) کے لیے استعمال ہونے والا ذخیرہ، کیشنگ کے لیے کلیدی قدر کا ذخیرہ - مثال کے طور پر، redis وغیرہ۔ فی الحال ہم نہیں ہیں۔ ہم ٹیڑھے بیک اینڈ پر عمل درآمد کے اختیارات کے بارے میں بات کریں گے جب ڈیٹا بیس ناقص تحریری سوالات کی وجہ سے کریش ہو جاتا ہے، اور اس کے بجائے ہم کلائنٹ کے بوجھ کے تحت اس ڈیٹا بیس کی غلطی برداشت کو یقینی بنانے کے بارے میں بات کریں گے۔ بہر حال، جب ہم اپنی درخواست کو کنٹینرائز کرتے ہیں اور آنے والی درخواستوں کی کسی بھی تعداد پر کارروائی کرنے کے لیے اسے آزادانہ طور پر اسکیل کرنے کی اجازت دیتے ہیں، تو یہ قدرتی طور پر ڈیٹا بیس پر بوجھ بڑھاتا ہے۔
درحقیقت ڈیٹابیس تک رسائی حاصل کرنے والا چینل اور جس سرور پر یہ چلتا ہے وہ ہمارے خوبصورت کنٹینرائزڈ بیک اینڈ میں سوئی کی آنکھ بن جاتا ہے۔ ایک ہی وقت میں، کنٹینر ورچوئلائزیشن کا بنیادی مقصد ڈھانچے کی نقل و حرکت اور لچک ہے، جو ہمیں پورے انفراسٹرکچر میں زیادہ سے زیادہ بوجھ کی تقسیم کو زیادہ سے زیادہ مؤثر طریقے سے ترتیب دینے کی اجازت دیتا ہے۔ یعنی، اگر ہم کلسٹر میں سسٹم کے تمام موجودہ عناصر کو کنٹینرائز اور رول آؤٹ نہیں کرتے ہیں، تو ہم بہت سنگین غلطی کر رہے ہیں۔
نہ صرف خود ایپلیکیشن، بلکہ ڈیٹا کو ذخیرہ کرنے کے لیے ذمہ دار خدمات کو بھی کلسٹر کرنا زیادہ منطقی ہے۔ آزادانہ طور پر کام کرنے والے اور آپس میں بوجھ کو k8s میں تقسیم کرنے والے ویب سرورز کو کلسٹرنگ اور تعینات کرکے، ہم پہلے ہی ڈیٹا کی ہم آہنگی کا مسئلہ حل کر رہے ہیں - پوسٹس پر وہی تبصرے، اگر ہم کسی میڈیا یا بلاگ پلیٹ فارم کو بطور مثال لیں۔ کسی بھی صورت میں، ہمارے پاس ایک انٹرا کلسٹر ہے، یہاں تک کہ ورچوئل، ڈیٹا بیس کی بطور ExternalService کی نمائندگی۔ سوال یہ ہے کہ ڈیٹا بیس خود ابھی تک کلسٹرڈ نہیں ہے - کیوب میں تعینات ویب سرور ہمارے جامد جنگی ڈیٹا بیس سے تبدیلیوں کے بارے میں معلومات لیتے ہیں، جو الگ سے گھومتا ہے۔
کیا آپ کو کیچ محسوس ہوتا ہے؟ ہم لوڈ کو تقسیم کرنے اور مین ویب سرور کے کریش ہونے سے بچنے کے لیے k8s یا Swarm استعمال کرتے ہیں، لیکن ہم ڈیٹا بیس کے لیے ایسا نہیں کرتے ہیں۔ لیکن اگر ڈیٹا بیس کریش ہو جاتا ہے، تو ہمارا پورا کلسٹرڈ انفراسٹرکچر کوئی معنی نہیں رکھتا - خالی ویب پیجز کیا فائدہ مند ہیں جو ڈیٹا بیس تک رسائی کی غلطی کو لوٹاتے ہیں؟
اس لیے نہ صرف ویب سرورز کو کلسٹر کرنا ضروری ہے، جیسا کہ عام طور پر کیا جاتا ہے، بلکہ ڈیٹا بیس کے بنیادی ڈھانچے کو بھی۔ صرف اس طرح سے ہم ایک ایسے ڈھانچے کو یقینی بنا سکتے ہیں جو ایک ٹیم میں مکمل طور پر کام کرے، لیکن ایک ہی وقت میں ایک دوسرے سے آزاد ہو۔ مزید برآں، یہاں تک کہ اگر ہمارا آدھا بیک اینڈ بوجھ کے نیچے "گر جاتا ہے"، باقی بچ جائے گا، اور کلسٹر کے اندر ڈیٹا بیس کو ایک دوسرے کے ساتھ ہم آہنگ کرنے کا نظام اور نئے کلسٹرز کو لامتناہی پیمانے اور تعینات کرنے کی صلاحیت سے مطلوبہ صلاحیت تک تیزی سے پہنچنے میں مدد ملے گی۔ اگر صرف ڈیٹا سینٹر میں ریک ہوتے۔
اس کے علاوہ، کلسٹرز میں تقسیم کردہ ڈیٹا بیس ماڈل آپ کو اس ڈیٹا بیس کو جہاں ضرورت ہو وہاں لے جانے کی اجازت دیتا ہے۔ اگر ہم ایک عالمی سروس کے بارے میں بات کر رہے ہیں، تو یہ بالکل غیر منطقی ہے کہ سان فرانسسکو کے علاقے میں کہیں ویب کلسٹر کو گھمایا جائے اور ساتھ ہی ماسکو کے علاقے اور پیچھے ڈیٹا بیس تک رسائی کے دوران پیکٹ بھیجیں۔
نیز، ڈیٹا بیس کی کنٹینرائزیشن آپ کو نظام کے تمام عناصر کو تجرید کی ایک ہی سطح پر بنانے کی اجازت دیتی ہے۔ جو، بدلے میں، منتظمین کی فعال شمولیت کے بغیر، ڈویلپرز کے ذریعے، کوڈ سے براہ راست اس نظام کا انتظام کرنا ممکن بناتا ہے۔ ڈویلپرز کا خیال تھا کہ نئے سب پروجیکٹ کے لیے ایک علیحدہ DBMS کی ضرورت ہے - آسان! ایک yaml فائل لکھی، اسے کلسٹر پر اپ لوڈ کیا اور آپ کا کام ہو گیا۔
اور ظاہر ہے، اندرونی آپریشن بہت آسان ہے. مجھے بتائیں، جب ٹیم کے کسی نئے رکن نے کام کے لیے جنگی ڈیٹا بیس میں ہاتھ ڈالے تو آپ نے کتنی بار آنکھیں بند کیں؟ کون سا، درحقیقت، صرف وہی ہے جو آپ کے پاس ہے اور ابھی گھوم رہا ہے؟ بلاشبہ، ہم سب یہاں بالغ ہیں، اور کہیں ہمارے پاس ایک تازہ بیک اپ ہے، اور اس سے بھی دور - دادی کے کھیرے اور پرانی سکیوں کے ساتھ شیلف کے پیچھے - ایک اور بیک اپ، شاید کولڈ اسٹوریج میں بھی، کیونکہ آپ کے دفتر میں پہلے ہی ایک بار آگ لگ چکی تھی۔ لیکن اسی طرح، لڑاکا انفراسٹرکچر تک رسائی کے ساتھ ٹیم کے ایک نئے رکن کا ہر تعارف اور یقیناً، جنگی ڈیٹا بیس تک ہر ایک کے لیے درستگی کی ایک بالٹی ہے۔ ٹھیک ہے، اسے کون جانتا ہے، ایک نوزائیدہ، ہو سکتا ہے کہ وہ ہاتھ پاؤں مارے؟ یہ خوفناک ہے، آپ اتفاق کریں گے.
کنٹینرائزیشن اور درحقیقت، آپ کے پروجیکٹ کے ڈیٹا بیس کی تقسیم شدہ فزیکل ٹوپولوجی ایسے درست لمحات سے بچنے میں مدد کرتی ہے۔ ایک نوزائیدہ پر بھروسہ نہیں کرتے؟ ٹھیک ہے! آئیے اسے اپنے کلسٹر کے ساتھ کام کرنے اور ڈیٹا بیس کو دوسرے کلسٹرز سے منقطع کرنے کے لیے دیں - صرف دستی دھکا اور دو کلیدوں کی ہم وقت ساز گردش (ایک ٹیم لیڈ کے لیے، دوسری ایڈمن کے لیے) کے ذریعے ہم آہنگی۔ اور سب خوش ہیں۔
اور اب وقت آگیا ہے کہ ڈیٹا بیس کلسٹرنگ کے مخالفین میں تبدیل ہوجائیں۔
تاریک پہلو
یہ بحث کرتے ہوئے کہ ڈیٹا بیس کو کنٹینرائز کرنا اور اسے ایک مرکزی سرور پر چلانا کیوں قابل نہیں ہے، ہم قدامت پسندوں کے بیانات اور بیانات جیسے "دادا نے ہارڈ ویئر پر ڈیٹا بیس چلاتے ہیں، اور ہم بھی ایسا ہی کریں گے!" اس کے بجائے، آئیے ایک ایسی صورتحال کے ساتھ آنے کی کوشش کریں جس میں کنٹینرائزیشن حقیقت میں ٹھوس منافع ادا کرے گی۔
متفق ہوں، جن پروجیکٹس کو واقعی کنٹینر میں بیس کی ضرورت ہوتی ہے وہ بہترین ملنگ مشین آپریٹر کی طرف سے ایک ہاتھ کی انگلیوں پر گنے جا سکتے ہیں۔ زیادہ تر حصے کے لیے، یہاں تک کہ k8s یا Docker Swarm کا استعمال بھی بے کار ہے - اکثر یہ ٹولز ٹیکنالوجیز کی عمومی تشہیر اور جنسوں کے فرد میں "اللہ تعالیٰ" کے رویوں کی وجہ سے استعمال کیے جاتے ہیں۔ بادل اور کنٹینرز. ٹھیک ہے، کیونکہ اب یہ فیشن ہے اور ہر کوئی کرتا ہے۔
کم از کم آدھے معاملات میں، کسی پروجیکٹ پر Kubernetis یا صرف Docker کا استعمال بے کار ہے۔ مسئلہ یہ ہے کہ کلائنٹ کے انفراسٹرکچر کو برقرار رکھنے کے لیے رکھی گئی تمام ٹیمیں یا آؤٹ سورسنگ کمپنیاں اس سے واقف نہیں ہیں۔ جب کنٹینرز لگائے جاتے ہیں تو یہ بدتر ہوتا ہے، کیونکہ اس سے کلائنٹ پر سکے کی ایک خاص رقم خرچ ہوتی ہے۔
عام طور پر، ایک رائے ہے کہ ڈاکر/کیوب مافیا احمقانہ طور پر ان کلائنٹس کو کچل رہا ہے جو ان بنیادی ڈھانچے کے مسائل کو آؤٹ سورس کرتے ہیں۔ سب کے بعد، کلسٹرز کے ساتھ کام کرنے کے لیے، ہمیں ایسے انجینئرز کی ضرورت ہے جو اس کے قابل ہوں اور عام طور پر نافذ کردہ حل کے فن تعمیر کو سمجھتے ہوں۔ ہم نے پہلے ہی ایک بار جمہوریہ کی اشاعت کے ساتھ اپنا معاملہ بیان کیا تھا - وہاں ہم نے کلائنٹ کی ٹیم کو Kubernetis کی حقیقتوں میں کام کرنے کی تربیت دی، اور ہر کوئی مطمئن تھا۔ اور یہ مہذب تھا۔ اکثر، k8s "عمل درآمد کرنے والے" کلائنٹ کے بنیادی ڈھانچے کو یرغمال بنا لیتے ہیں - کیونکہ اب صرف وہی سمجھتے ہیں کہ وہاں سب کچھ کیسے کام کرتا ہے؛ کلائنٹ کی طرف کوئی ماہر نہیں ہے۔
اب تصور کریں کہ اس طرح ہم نہ صرف ویب سرور کے حصے کو آؤٹ سورس کرتے ہیں بلکہ ڈیٹا بیس کی دیکھ بھال بھی کرتے ہیں۔ ہم نے کہا کہ بی ڈی دل ہے، اور دل کا نقصان کسی بھی جاندار کے لیے مہلک ہے۔ مختصر میں، امکانات بہترین نہیں ہیں. لہذا، ہائپ Kubernetis کے بجائے، بہت سے پروجیکٹس کو AWS کے لیے عام ٹیرف سے پریشان نہیں ہونا چاہیے، جو ان کی سائٹ/پروجیکٹ پر بوجھ کے تمام مسائل کو حل کر دے گا۔ لیکن AWS اب فیشن ایبل نہیں ہے، اور شو آف کی قیمت پیسے سے زیادہ ہے - بدقسمتی سے، IT ماحول میں بھی۔
ٹھیک ہے. شاید پروجیکٹ کو واقعی کلسٹرنگ کی ضرورت ہے، لیکن اگر اسٹیٹ لیس ایپلی کیشنز کے ساتھ سب کچھ واضح ہے، تو پھر ہم کلسٹرڈ ڈیٹا بیس کے لیے نیٹ ورک کنیکٹیویٹی کو کیسے منظم کر سکتے ہیں؟
اگر ہم بغیر کسی رکاوٹ کے انجینئرنگ کے حل کے بارے میں بات کر رہے ہیں، جو k8s میں منتقلی ہے، تو ہمارا بنیادی سردرد کلسٹرڈ ڈیٹا بیس میں ڈیٹا کی نقل ہے۔ کچھ ڈی بی ایم ایس ابتدائی طور پر اپنی انفرادی مثالوں کے درمیان ڈیٹا کی تقسیم کے لیے کافی وفادار ہوتے ہیں۔ بہت سے دوسرے اتنے خوش آمدید نہیں ہیں۔ اور اکثر ہمارے پروجیکٹ کے لیے ڈی بی ایم ایس کو منتخب کرنے کی بنیادی دلیل کم سے کم وسائل اور انجینئرنگ کے اخراجات کے ساتھ نقل کرنے کی صلاحیت نہیں ہے۔ خاص طور پر اگر اس منصوبے کو ابتدائی طور پر ایک مائیکرو سروس کے طور پر نہیں بنایا گیا تھا، لیکن اس سمت میں صرف تیار کیا گیا تھا۔
ہمارے خیال میں نیٹ ورک ڈرائیوز کی رفتار کے بارے میں بات کرنے کی ضرورت نہیں ہے - وہ سست ہیں۔ وہ. ہمارے پاس اب بھی کوئی حقیقی موقع نہیں ہے، اگر کچھ ہوتا ہے، کسی DBMS مثال کو دوبارہ شروع کرنے کا کہیں جہاں زیادہ ہے، مثال کے طور پر، پروسیسر پاور یا مفت RAM۔ ہم بہت تیزی سے ورچوئلائزڈ ڈسک سب سسٹم کی کارکردگی کا جائزہ لیں گے۔ اس کے مطابق، ڈی بی ایم ایس کو قریب میں واقع مشینوں کے اپنے ذاتی سیٹ پر کیل لگانا چاہیے۔ یا یہ ضروری ہے کہ کسی نہ کسی طرح الگ الگ ٹھنڈا ہو جائے کہ قیاس کے ذخائر کے لیے کافی تیزی سے ڈیٹا سنکرونائزیشن ہو۔
ورچوئل فائل سسٹم کے موضوع کو جاری رکھنا: ڈوکر والیومز، بدقسمتی سے، مسئلہ سے پاک نہیں ہیں۔ عام طور پر، طویل مدتی قابل اعتماد ڈیٹا اسٹوریج جیسے معاملے میں، میں تکنیکی طور پر سب سے آسان اسکیموں کے ساتھ کرنا چاہوں گا۔ اور کنٹینر کے FS سے والدین کے میزبان کے FS میں ایک نئی تجریدی پرت شامل کرنا اپنے آپ میں ایک خطرہ ہے۔ لیکن جب کنٹینرائزیشن سپورٹ سسٹم کے آپریشن کو بھی ان تہوں کے درمیان ڈیٹا منتقل کرنے میں مشکلات کا سامنا کرنا پڑتا ہے، تو یہ واقعی ایک تباہی ہے۔ اس وقت ترقی پسند انسانیت کو معلوم اکثر مسائل کا خاتمہ ہو چکا ہے۔ لیکن آپ سمجھتے ہیں، میکانزم جتنا پیچیدہ ہوگا، اتنا ہی آسان ٹوٹ جائے گا۔
ان تمام "ایڈونچرز" کی روشنی میں، ڈیٹا بیس کو ایک جگہ رکھنا زیادہ منافع بخش اور آسان ہے، اور یہاں تک کہ اگر آپ کو ایپلیکیشن کو کنٹینرائز کرنے کی ضرورت ہو، تو اسے خود چلنے دیں اور ڈسٹری بیوشن گیٹ وے کے ذریعے بیک وقت مواصلت حاصل کریں۔ ڈیٹا بیس، جو صرف ایک بار اور ایک جگہ پڑھا اور لکھا جائے گا۔ یہ نقطہ نظر غلطیوں اور غیر مطابقت پذیری کے امکانات کو کم سے کم کر دیتا ہے۔
ہم کس طرف لے جا رہے ہیں؟ مزید یہ کہ، ڈیٹا بیس کنٹینرائزیشن مناسب ہے جہاں اس کی حقیقی ضرورت ہو۔ آپ ایک مکمل ایپ ڈیٹا بیس نہیں بنا سکتے اور اسے اس طرح گھما سکتے ہیں جیسے آپ کے پاس دو درجن مائیکرو سروسز ہیں - یہ اس طرح کام نہیں کرتا ہے۔ اور یہ واضح طور پر سمجھنا ضروری ہے.
پیداوار کے بجائے
اگر آپ کسی واضح نتیجے کا انتظار کر رہے ہیں "ڈیٹا بیس کو ورچوئلائز کرنا ہے یا نہیں،" تو ہم آپ کو مایوس کریں گے: یہ یہاں نہیں ہوگا۔ کیونکہ کوئی بھی بنیادی ڈھانچہ حل بناتے وقت، کسی کی رہنمائی فیشن اور ترقی سے نہیں، بلکہ سب سے پہلے عقل سے ہونی چاہیے۔
ایسے منصوبے ہیں جن کے لیے اصول اور اوزار جو Kubernetis کے ساتھ آتے ہیں بالکل فٹ بیٹھتے ہیں، اور ایسے منصوبوں میں کم از کم بیک اینڈ ایریا میں امن ہوتا ہے۔ اور ایسے منصوبے ہیں جن کو کنٹینرائزیشن کی ضرورت نہیں ہے، بلکہ ایک عام سرور کے بنیادی ڈھانچے کی ضرورت ہے، کیونکہ وہ بنیادی طور پر مائیکرو سروس کلسٹر ماڈل پر دوبارہ نہیں بڑھ سکتے، کیونکہ وہ گر جائیں گے۔
ماخذ: www.habr.com