URUS کمپنی نے Kubernetes کو مختلف شکلوں میں آزمایا: Google Cloud میں، ننگی دھات پر آزاد تعیناتی، اور پھر اپنے پلیٹ فارم کو Mail.ru Cloud Solutions (MCS) کلاؤڈ پر منتقل کر دیا۔ Igor Shishkin بتاتا ہے کہ انہوں نے ایک نئے کلاؤڈ فراہم کنندہ کا انتخاب کیسے کیا اور ریکارڈ دو گھنٹے میں وہ اس پر منتقل ہونے میں کیسے کامیاب ہوئے ()، URUS میں سینئر سسٹم ایڈمنسٹریٹر۔
URUS کیا کرتا ہے؟
شہری ماحول کے معیار کو بہتر بنانے کے بہت سے طریقے ہیں، اور ان میں سے ایک اسے ماحول دوست بنانا ہے۔ یہ بالکل وہی ہے جس پر URUS - Smart Digital Services کمپنی کام کر رہی ہے۔ یہاں وہ ایسے حل نافذ کرتے ہیں جو کاروباری اداروں کو اہم ماحولیاتی اشاریوں کی نگرانی کرنے اور ماحول پر ان کے منفی اثرات کو کم کرنے میں مدد کرتے ہیں۔ سینسر ہوا کی ساخت، شور کی سطح اور دیگر پیرامیٹرز پر ڈیٹا اکٹھا کرتے ہیں، اور پھر انہیں تجزیہ اور سفارشات کے لیے متحد URUS-Ekomon پلیٹ فارم پر بھیجتے ہیں۔
URUS اندر سے کیسے کام کرتا ہے۔
URUS کا ایک عام کلائنٹ ایک کمپنی ہے جو رہائشی علاقے میں یا اس کے قریب واقع ہے۔ یہ فیکٹری، بندرگاہ، ریلوے ڈپو یا کوئی اور سہولت ہو سکتی ہے۔ اگر ہمارے کلائنٹ کو پہلے ہی کوئی وارننگ مل چکی ہے، اسے ماحولیاتی آلودگی کے لیے جرمانہ کیا گیا ہے، یا وہ کم شور کرنا چاہتا ہے، نقصان دہ اخراج کی مقدار کو کم کرنا چاہتا ہے، تو وہ ہمارے پاس آتا ہے، اور ہم اسے پہلے سے ہی ماحولیاتی نگرانی کے لیے ایک تیار حل پیش کرتے ہیں۔
H2S حراستی نگرانی کا گراف قریبی پلانٹ سے رات کے وقت باقاعدگی سے اخراج کو ظاہر کرتا ہے۔
جو آلات ہم URUS میں استعمال کرتے ہیں ان میں کئی سینسر ہوتے ہیں جو ماحولیاتی صورتحال کا اندازہ لگانے کے لیے بعض گیسوں، شور کی سطح اور دیگر ڈیٹا کے مواد کے بارے میں معلومات اکٹھا کرتے ہیں۔ سینسر کی صحیح تعداد کا تعین ہمیشہ مخصوص کام سے ہوتا ہے۔
پیمائش کی تفصیلات پر منحصر ہے، سینسر والے آلات عمارتوں، کھمبوں اور دیگر من مانی جگہوں کی دیواروں پر واقع ہو سکتے ہیں۔ اس طرح کا ہر آلہ معلومات جمع کرتا ہے، اسے جمع کرتا ہے اور ڈیٹا وصول کرنے والے گیٹ وے کو بھیجتا ہے۔ وہاں ہم ڈیٹا کو طویل مدتی اسٹوریج کے لیے محفوظ کرتے ہیں اور بعد کے تجزیے کے لیے اسے پہلے سے پروسیس کرتے ہیں۔ تجزیہ کے نتیجے میں ہمیں جو کچھ ملتا ہے اس کی سب سے آسان مثال ایئر کوالٹی انڈیکس ہے، جسے AQI بھی کہا جاتا ہے۔
متوازی طور پر، ہمارے پلیٹ فارم پر بہت سی دوسری خدمات کام کرتی ہیں، لیکن وہ بنیادی طور پر سروس کی نوعیت کی ہیں۔ مثال کے طور پر، نوٹیفکیشن سروس کلائنٹس کو اطلاع بھیجتی ہے اگر مانیٹر کیے گئے پیرامیٹرز میں سے کوئی بھی (مثال کے طور پر CO2 مواد) قابل اجازت قیمت سے زیادہ ہے۔
ہم ڈیٹا کو کیسے اسٹور کرتے ہیں۔ ننگی دھات پر کبرنیٹس کی کہانی
URUS ماحولیاتی نگرانی کے منصوبے میں کئی ڈیٹا گودام ہیں۔ ایک میں ہم "خام" ڈیٹا رکھتے ہیں - جو ہمیں براہ راست آلات سے موصول ہوتا ہے۔ یہ ذخیرہ ایک "مقناطیسی" ٹیپ ہے، جیسے پرانے کیسٹ ٹیپس پر، تمام اشارے کی تاریخ کے ساتھ۔ دوسری قسم کی سٹوریج پہلے سے تیار شدہ ڈیٹا کے لیے استعمال کی جاتی ہے - ڈیوائسز کا ڈیٹا، سینسرز کے درمیان کنکشن کے بارے میں میٹا ڈیٹا اور خود ڈیوائسز کی ریڈنگ، تنظیموں کے ساتھ وابستگی، مقامات وغیرہ۔ یہ معلومات آپ کو متحرک طور پر اس بات کا اندازہ لگانے کی اجازت دیتی ہے کہ کسی خاص اشارے کے پاس کیسے ہے۔ وقت کی ایک خاص مدت میں تبدیل اگر ایسی ضرورت پیش آتی ہے تو ہم "خام" ڈیٹا اسٹوریج کو، دوسری چیزوں کے ساتھ، بیک اپ کے طور پر اور پہلے سے پروسیس شدہ ڈیٹا کو بحال کرنے کے لیے استعمال کرتے ہیں۔
جب ہم کئی سال پہلے اپنے سٹوریج کے مسئلے کو حل کرنے کی کوشش کر رہے تھے، تو ہمارے پاس پلیٹ فارم کے دو انتخاب تھے: Kubernetes اور OpenStack۔ لیکن چونکہ مؤخر الذکر کافی شیطانی نظر آتا ہے (صرف اس کے فن تعمیر کو دیکھیں تاکہ اس بات کا یقین ہو جائے)، ہم نے کوبرنیٹس پر ہی بس کیا۔ اس کے حق میں ایک اور دلیل نسبتاً آسان سافٹ ویئر کنٹرول تھی، وسائل کے مطابق ہارڈ ویئر نوڈس کو بھی زیادہ لچکدار طریقے سے کاٹنے کی صلاحیت۔
Kubernetes میں مہارت حاصل کرنے کے متوازی طور پر، ہم نے ڈیٹا کو ذخیرہ کرنے کے طریقوں کا بھی مطالعہ کیا، جب کہ ہم نے اپنے تمام اسٹوریج کو اپنے ہارڈ ویئر پر Kubernetes میں رکھا، ہمیں بہترین مہارت حاصل ہوئی۔ ہر وہ چیز جو ہم نے کبرنیٹس پر گزاری تھی: سٹیٹ فل اسٹوریج، مانیٹرنگ سسٹم، CI/CD۔ Kubernetes ہمارے لیے ایک ہمہ جہت پلیٹ فارم بن گیا ہے۔
لیکن ہم Kubernetes کے ساتھ بطور خدمت کام کرنا چاہتے تھے، اور اس کی حمایت اور ترقی میں مشغول نہیں تھے۔ اس کے علاوہ، ہمیں یہ پسند نہیں آیا کہ اسے ننگی دھات پر برقرار رکھنے میں ہمیں کتنا خرچ آتا ہے، اور ہمیں مسلسل ترقی کی ضرورت ہے! مثال کے طور پر، پہلے کاموں میں سے ایک Kubernetes Ingress کنٹرولرز کو ہماری تنظیم کے نیٹ ورک انفراسٹرکچر میں ضم کرنا تھا۔ یہ ایک بوجھل کام ہے، خاص طور پر اس بات پر غور کرتے ہوئے کہ اس وقت پروگرامی وسائل کے انتظام کے لیے کچھ بھی تیار نہیں تھا جیسے DNS ریکارڈز یا IP پتوں کی تقسیم۔ بعد میں ہم نے بیرونی ڈیٹا اسٹوریج کے ساتھ تجربہ کرنا شروع کیا۔ ہم PVC کنٹرولر کو لاگو کرنے کے لیے کبھی نہیں پہنچے، لیکن پھر بھی یہ واضح ہو گیا کہ یہ کام کا ایک بڑا علاقہ تھا جس کے لیے سرشار ماہرین کی ضرورت تھی۔
گوگل کلاؤڈ پلیٹ فارم پر سوئچ کرنا ایک عارضی حل ہے۔
ہم نے محسوس کیا کہ یہ جاری نہیں رہ سکتا، اور اپنے ڈیٹا کو ننگی دھات سے گوگل کلاؤڈ پلیٹ فارم پر منتقل کر دیا۔ درحقیقت، اس وقت روسی کمپنی کے لیے بہت زیادہ دلچسپ آپشنز نہیں تھے: گوگل کلاؤڈ پلیٹ فارم کے علاوہ، صرف ایمیزون نے اسی طرح کی سروس پیش کی، لیکن ہم پھر بھی گوگل کے حل پر ہی بس گئے۔ پھر یہ ہمیں اقتصادی طور پر زیادہ منافع بخش معلوم ہوا، اپ اسٹریم کے قریب، اس حقیقت کا تذکرہ نہ کرنا کہ گوگل خود پروڈکشن میں PoC Kubernetes کی ایک قسم ہے۔
پہلا بڑا مسئلہ افق پر نمودار ہوا کیونکہ ہمارے کسٹمر بیس میں اضافہ ہوا۔ جب ہمیں ذاتی ڈیٹا کو ذخیرہ کرنے کی ضرورت تھی، تو ہمیں ایک انتخاب کا سامنا کرنا پڑا: یا تو ہم گوگل کے ساتھ کام کرتے ہیں اور روسی قوانین کی خلاف ورزی کرتے ہیں، یا ہم روسی فیڈریشن میں کسی متبادل کی تلاش میں ہیں۔ انتخاب، مجموعی طور پر، پیش قیاسی تھا۔ 🙂
ہم نے مثالی کلاؤڈ سروس کو کیسے دیکھا
تلاش کے آغاز تک، ہم پہلے ہی جان چکے تھے کہ ہم مستقبل کے کلاؤڈ فراہم کنندہ سے کیا حاصل کرنا چاہتے ہیں۔ ہم کس خدمت کی تلاش کر رہے تھے:
- تیز اور لچکدار. اس طرح کہ ہم فوری طور پر ایک نیا نوڈ شامل کر سکتے ہیں یا کسی بھی وقت کچھ تعینات کر سکتے ہیں۔
- سستا. ہم مالیاتی مسئلے کے بارے میں بہت فکر مند تھے، کیونکہ ہمارے پاس وسائل محدود تھے۔ ہم پہلے ہی جانتے تھے کہ ہم Kubernetes کے ساتھ کام کرنا چاہتے ہیں، اور اب کام اس حل کو استعمال کرنے کی کارکردگی کو بڑھانے یا کم از کم برقرار رکھنے کے لیے اس کی لاگت کو کم کرنا تھا۔
- خودکار. ہم نے مینیجرز اور فون کالز یا ایسے حالات کے بغیر API کے ذریعے سروس کے ساتھ کام کرنے کا منصوبہ بنایا جہاں ہمیں ہنگامی حالت میں کئی درجن نوڈس کو دستی طور پر بڑھانے کی ضرورت ہے۔ چونکہ ہمارے زیادہ تر عمل خودکار ہیں، اس لیے ہم نے کلاؤڈ سروس سے بھی یہی توقع کی تھی۔
- روسی فیڈریشن میں سرورز کے ساتھ. یقینا، ہم نے روسی قانون سازی اور اسی 152-FZ کی تعمیل کرنے کا منصوبہ بنایا ہے۔
اس وقت، روس میں Kubernetes aaS فراہم کرنے والے چند تھے، اور فراہم کنندہ کا انتخاب کرتے وقت، ہمارے لیے یہ ضروری تھا کہ ہم اپنی ترجیحات پر سمجھوتہ نہ کریں۔ Mail.ru کلاؤڈ سولیوشنز ٹیم، جس کے ساتھ ہم نے کام کرنا شروع کیا اور اب بھی تعاون کر رہے ہیں، نے ہمیں API سپورٹ اور ایک آسان کنٹرول پینل کے ساتھ ایک مکمل خودکار سروس فراہم کی جس میں Horizon شامل ہے - اس کے ساتھ ہم تیزی سے نوڈس کی ایک من مانی تعداد کو بڑھا سکتے ہیں۔
ہم دو گھنٹوں میں ایم سی ایس میں منتقل ہونے میں کیسے کامیاب ہوئے۔
اس طرح کے اقدامات میں، بہت سی کمپنیوں کو مشکلات اور دھچکے کا سامنا کرنا پڑتا ہے، لیکن ہمارے معاملے میں ایسا کوئی نہیں تھا۔ ہم خوش قسمت تھے: چونکہ ہم منتقلی شروع ہونے سے پہلے ہی Kubernetes پر کام کر رہے تھے، اس لیے ہم نے صرف تین فائلوں کو درست کیا اور نئے کلاؤڈ پلیٹ فارم، MCS پر اپنی خدمات کا آغاز کیا۔ میں آپ کو یاد دلاتا ہوں کہ اس وقت تک ہم نے بالآخر ننگی دھات چھوڑ دی تھی اور گوگل کلاؤڈ پلیٹ فارم پر رہتے تھے۔ لہذا، اس اقدام میں خود دو گھنٹے سے زیادہ کا وقت نہیں لگا، اس کے علاوہ ہمارے آلات سے ڈیٹا کاپی کرنے میں تھوڑا زیادہ وقت (تقریباً ایک گھنٹہ) صرف ہوا۔ اس وقت ہم پہلے ہی Spinnaker (مسلسل ڈیلیوری فراہم کرنے کے لیے ایک ملٹی کلاؤڈ سی ڈی سروس) استعمال کر رہے تھے۔ ہم نے اسے تیزی سے نئے کلسٹر میں بھی شامل کیا اور معمول کے مطابق کام جاری رکھا۔
ترقی کے عمل اور CI/CD کے آٹومیشن کی بدولت، URUS میں Kubernetes کو ایک ماہر (اور وہ میں ہوں) سنبھالتا ہے۔ کسی مرحلے پر، ایک اور سسٹم ایڈمنسٹریٹر نے میرے ساتھ کام کیا، لیکن پھر پتہ چلا کہ ہم نے پہلے سے ہی تمام اہم معمولات کو خودکار کر دیا ہے اور ہمارے مرکزی پروڈکٹ کے حصے میں زیادہ سے زیادہ کام تھے اور اس سے وسائل کو اس کی طرف لے جانے کا احساس ہوا۔
ہم نے کلاؤڈ فراہم کنندہ سے وہی حاصل کیا جس کی ہمیں توقع تھی، کیونکہ ہم نے بغیر کسی فریب کے تعاون شروع کیا۔ اگر کوئی واقعات تھے، تو وہ زیادہ تر تکنیکی تھے اور وہ جن کی آسانی سے سروس کی نسبتاً تازگی سے وضاحت کی جا سکتی تھی۔ اہم بات یہ ہے کہ ایم سی ایس ٹیم جلد سے جلد کوتاہیوں کو دور کرتی ہے اور میسنجر میں سوالات کے فوری جواب دیتی ہے۔
اگر میں گوگل کلاؤڈ پلیٹ فارم کے ساتھ اپنے تجربے کا موازنہ کرتا ہوں، تو ان کے معاملے میں مجھے یہ بھی معلوم نہیں تھا کہ فیڈ بیک بٹن کہاں ہے، کیونکہ اس کی ضرورت ہی نہیں تھی۔ اور اگر کوئی مسئلہ پیش آیا تو گوگل نے خود یکطرفہ طور پر نوٹیفیکیشن بھیجے۔ لیکن MCS کے معاملے میں، میرے خیال میں بڑا فائدہ یہ ہے کہ وہ روسی کلائنٹس کے زیادہ سے زیادہ قریب ہیں - جغرافیائی اور ذہنی دونوں لحاظ سے۔
ہم مستقبل میں بادلوں کے ساتھ کام کرتے ہوئے کیسے دیکھتے ہیں۔
اب ہمارا کام Kubernetes سے بہت قریب سے جڑا ہوا ہے، اور یہ بنیادی ڈھانچے کے کاموں کے نقطہ نظر سے ہمارے لیے پوری طرح موزوں ہے۔ اس لیے، ہم اس سے کہیں بھی ہجرت کرنے کا ارادہ نہیں رکھتے، حالانکہ ہم معمول کے کاموں کو آسان بنانے اور نئے کو خودکار بنانے، خدمات کے استحکام اور بھروسے کو بڑھانے کے لیے مسلسل نئے طریقے اور خدمات متعارف کروا رہے ہیں... اب ہم Chaos Monkey سروس شروع کر رہے ہیں (خاص طور پر ، ہم chaoskube استعمال کرتے ہیں، لیکن اس سے یہ تصور تبدیل نہیں ہوتا ہے: )، جسے اصل میں Netflix نے بنایا تھا۔ Chaos Monkey ایک آسان کام کرتا ہے: یہ بے ترتیب کبرنیٹس پوڈ کو بے ترتیب وقت پر حذف کر دیتا ہے۔ یہ ہماری سروس کے لیے ضروری ہے کہ وہ n–1 کی تعداد کے ساتھ معمول کے مطابق زندگی گزاریں، اس لیے ہم خود کو کسی بھی پریشانی کے لیے تیار رہنے کی تربیت دیتے ہیں۔
اب میں تیسری پارٹی کے حل کا استعمال دیکھ رہا ہوں - وہی کلاؤڈ پلیٹ فارم - نوجوان کمپنیوں کے لیے صرف صحیح چیز کے طور پر۔ عام طور پر، اپنے سفر کے آغاز میں، وہ انسانی اور مالی دونوں طرح کے وسائل میں محدود ہوتے ہیں، اور اپنے کلاؤڈ یا ڈیٹا سینٹر کو بنانا اور برقرار رکھنا بہت مہنگا اور محنت طلب ہوتا ہے۔ کلاؤڈ فراہم کرنے والے آپ کو ان اخراجات کو کم کرنے کی اجازت دیتے ہیں؛ آپ ان سے فوری طور پر یہاں اور ابھی خدمات کے آپریشن کے لیے ضروری وسائل حاصل کر سکتے ہیں، اور حقیقت کے بعد ان وسائل کی ادائیگی کر سکتے ہیں۔ جہاں تک URUS کمپنی کا تعلق ہے، ہم فی الحال بادل میں Kubernetes کے ساتھ وفادار رہیں گے۔ لیکن کون جانتا ہے، ہمیں جغرافیائی طور پر توسیع کرنا پڑ سکتی ہے، یا کچھ مخصوص آلات کی بنیاد پر حل کو نافذ کرنا پڑ سکتا ہے۔ یا ہوسکتا ہے کہ استعمال ہونے والے وسائل کی مقدار اپنے کوبرنیٹس کو ننگی دھات پر جواز فراہم کرے گی، جیسے اچھے پرانے دنوں میں۔ 🙂
کلاؤڈ سروسز کے ساتھ کام کرنے سے ہم نے کیا سیکھا۔
ہم نے ننگی دھات پر کبرنیٹس کا استعمال شروع کیا، اور وہاں بھی یہ اپنے طریقے سے اچھا تھا۔ لیکن اس کی طاقتیں کلاؤڈ میں ایک AAS جزو کے طور پر واضح طور پر ظاہر ہوئیں۔ اگر آپ ایک مقصد طے کرتے ہیں اور ہر چیز کو ہر ممکن حد تک خودکار بناتے ہیں، تو آپ وینڈر لاک ان سے بچ سکیں گے اور کلاؤڈ فراہم کرنے والوں کے درمیان منتقل ہونے میں چند گھنٹے لگیں گے، اور اعصابی خلیے ہمارے ساتھ رہیں گے۔ ہم دوسری کمپنیوں کو مشورہ دے سکتے ہیں: اگر آپ محدود وسائل اور ترقی کے لیے زیادہ سے زیادہ رفتار رکھتے ہوئے، اپنی (کلاؤڈ) سروس شروع کرنا چاہتے ہیں، تو کلاؤڈ ریسورسز کرائے پر لے کر ابھی شروع کریں، اور فوربس کے لکھنے کے بعد اپنا ڈیٹا سینٹر بنائیں۔
ماخذ: www.habr.com