ہیلو، میرا نام Kostya Kramlikh ہے، میں Yandex.Cloud میں ورچوئل پرائیویٹ کلاؤڈ ڈویژن کا لیڈ ڈویلپر ہوں۔ میں ایک ورچوئل نیٹ ورکر ہوں، اور جیسا کہ آپ اندازہ لگا سکتے ہیں، میں اس مضمون میں عمومی طور پر ورچوئل پرائیویٹ کلاؤڈ (VPC) ڈیوائس اور خاص طور پر ورچوئل نیٹ ورک کے بارے میں بات کروں گا۔ اور آپ یہ بھی جان لیں گے کہ ہم، سروس کے ڈویلپرز، اپنے صارفین کے تاثرات کو اہمیت کیوں دیتے ہیں۔ لیکن سب سے پہلے چیزیں.
VPC کیا ہے؟
آج کل، خدمات کی تعیناتی کے لیے بہت سے اختیارات موجود ہیں۔ مجھے یقین ہے کہ کوئی اب بھی سرور کو ایڈمنسٹریٹر کی میز کے نیچے رکھتا ہے، حالانکہ مجھے امید ہے کہ ایسی کہانیاں کم ہوں گی۔
اب خدمات عوامی بادلوں پر جانے کی کوشش کر رہی ہیں، اور یہیں سے وہ VPCs سے ٹکراتی ہیں۔ VPC ایک عوامی کلاؤڈ کا ایک حصہ ہے جو صارف، انفراسٹرکچر، پلیٹ فارم اور دیگر صلاحیتوں کو آپس میں جوڑتا ہے، وہ جہاں بھی ہوں، ہمارے کلاؤڈ میں یا اس سے باہر۔ اسی وقت، VPC آپ کو اجازت دیتا ہے کہ آپ ان صلاحیتوں کو انٹرنیٹ پر غیر ضروری طور پر ظاہر نہ کریں، وہ آپ کے الگ تھلگ نیٹ ورک میں ہی رہیں۔
ورچوئل نیٹ ورک باہر سے کیسا لگتا ہے؟
VPC کے ذریعہ، ہمارا بنیادی طور پر ایک اوورلے نیٹ ورک اور نیٹ ورک کی خدمات، جیسے VPNaaS، NATaas، LBaas، وغیرہ سے مراد ہے۔ اور یہ سب کچھ غلطی برداشت کرنے والے نیٹ ورک انفراسٹرکچر کے اوپر کام کرتا ہے، جو پہلے ہی ہو چکا ہے۔ یہاں، Habré پر.
آئیے ورچوئل نیٹ ورک اور اس کے آلے کو قریب سے دیکھتے ہیں۔
دو دستیابی زونز پر غور کریں۔ ہم ایک ورچوئل نیٹ ورک فراہم کرتے ہیں - جسے ہم VPC کہتے ہیں۔ درحقیقت، یہ آپ کے "گرے" پتوں کی انفرادیت کی جگہ کی وضاحت کرتا ہے۔ ہر ورچوئل نیٹ ورک کے اندر، آپ کے پاس پتے کی جگہ پر مکمل کنٹرول ہوتا ہے جسے آپ وسائل کی گنتی کے لیے تفویض کر سکتے ہیں۔
نیٹ ورک عالمی ہے۔ ایک ہی وقت میں، یہ سب نیٹ نامی ایک ہستی کی شکل میں دستیابی کے ہر زون پر پیش کیا جاتا ہے۔ ہر سب نیٹ کے لیے، آپ 16 یا اس سے کم سائز کا CIDR تفویض کرتے ہیں۔ ہر دستیابی زون میں ایسی ایک سے زیادہ ہستی ہو سکتی ہے، اور ان کے درمیان ہمیشہ شفاف روٹنگ ہوتی ہے۔ اس کا مطلب یہ ہے کہ ایک ہی VPC کے اندر آپ کے تمام وسائل ایک دوسرے سے "بات" کر سکتے ہیں، چاہے وہ مختلف دستیابی زون میں ہوں۔ انٹرنیٹ تک رسائی کے بغیر "مواصلات" کریں، ہمارے اندرونی چینلز کے ذریعے، یہ سوچ کر کہ وہ ایک ہی نجی نیٹ ورک کے اندر ہیں۔
اوپر دیا گیا خاکہ ایک عام صورت حال کو ظاہر کرتا ہے: دو VPCs جو پتوں میں کہیں ایک دوسرے کو آپس میں جوڑتے ہیں۔ دونوں آپ کے ہو سکتے ہیں۔ مثال کے طور پر، ایک ترقی کے لیے، دوسرا جانچ کے لیے۔ صرف مختلف صارفین ہوسکتے ہیں - اس معاملے میں کوئی فرق نہیں پڑتا ہے۔ اور ایک ورچوئل مشین ہر VPC میں لگائی جاتی ہے۔
آئیے اسکیم کو مزید خراب کرتے ہیں۔ آپ اسے اس طرح بنا سکتے ہیں کہ ایک ورچوئل مشین ایک ساتھ کئی سب نیٹس میں پھنس جائے۔ اور نہ صرف اس طرح، بلکہ مختلف ورچوئل نیٹ ورکس میں۔
ایک ہی وقت میں، اگر آپ کو مشینوں کو انٹرنیٹ پر ظاہر کرنے کی ضرورت ہے، تو یہ API یا UI کے ذریعے کیا جا سکتا ہے۔ ایسا کرنے کے لیے، آپ کو اپنے "گرے"، اندرونی پتے کے NAT ترجمہ کو "سفید" - عوامی میں ترتیب دینا ہوگا۔ آپ "سفید" پتہ کا انتخاب نہیں کر سکتے، یہ ہمارے پتوں کے پول سے تصادفی طور پر تفویض کیا جاتا ہے۔ جیسے ہی آپ بیرونی آئی پی کا استعمال بند کرتے ہیں، یہ پول میں واپس آ جاتا ہے۔ آپ صرف "سفید" پتہ استعمال کرنے کے وقت کے لیے ادائیگی کرتے ہیں۔
NAT مثال کے ذریعے مشین کو انٹرنیٹ تک رسائی دینا بھی ممکن ہے۔ آپ جامد روٹنگ ٹیبل کے ذریعے ٹریفک کو کسی مثال پر روٹ کر سکتے ہیں۔ ہم نے ایسا معاملہ فراہم کیا ہے، کیونکہ صارفین کو بعض اوقات اس کی ضرورت ہوتی ہے، اور ہم اس کے بارے میں جانتے ہیں۔ اسی مناسبت سے، ہمارے تصویری کیٹلاگ میں خاص طور پر ترتیب شدہ NAT امیج شامل ہے۔
لیکن یہاں تک کہ جب تیار NAT امیج موجود ہو، سیٹ اپ مشکل ہو سکتا ہے۔ ہم سمجھ گئے کہ کچھ صارفین کے لیے یہ سب سے آسان آپشن نہیں ہے، اس لیے آخر میں ہم نے ایک کلک میں مطلوبہ سب نیٹ کے لیے NAT کو فعال کرنا ممکن بنایا۔ یہ فیچر ابھی تک بند پیش نظارہ رسائی میں ہے، جہاں کمیونٹی ممبران کی مدد سے اس کا تجربہ کیا جاتا ہے۔
ورچوئل نیٹ ورک کو اندر سے کیسے ترتیب دیا جاتا ہے۔
صارف ورچوئل نیٹ ورک کے ساتھ کیسے تعامل کرتا ہے؟ ویب اپنے API کے ساتھ باہر کی طرف نظر آتا ہے۔ صارف API پر آتا ہے اور ہدف کی حالت کے ساتھ کام کرتا ہے۔ API کے ذریعے صارف دیکھتا ہے کہ ہر چیز کو کس طرح ترتیب اور ترتیب دیا جانا چاہیے، جب کہ وہ اسٹیٹس کو دیکھتا ہے کہ اصل حالت مطلوبہ سے کتنا مختلف ہے۔ یہ صارف کی تصویر ہے۔ اندر کیا ہو رہا ہے؟
ہم Yandex ڈیٹا بیس پر مطلوبہ حالت لکھتے ہیں اور اپنے VPC کے مختلف حصوں کو ترتیب دینے کے لیے جاتے ہیں۔ Yandex.Cloud میں اوورلے نیٹ ورک OpenContrail کے منتخب اجزاء پر مبنی ہے، جسے حال ہی میں Tungsten Fabric کہا گیا ہے۔ نیٹ ورک سروسز کو ایک واحد CloudGate پلیٹ فارم پر لاگو کیا جاتا ہے۔ CloudGate میں، ہم نے متعدد اوپن سورس اجزاء کا بھی استعمال کیا: GoBGP - کنٹرول کی معلومات تک رسائی کے ساتھ ساتھ VPP - ایک سافٹ ویئر راؤٹر کو لاگو کرنے کے لیے جو ڈیٹا پاتھ کے لیے DPDK کے اوپر چلتا ہے۔
ٹنگسٹن فیبرک CloudGate کے ساتھ GoBGP کے ذریعے بات چیت کرتا ہے۔ بتاتا ہے کہ اوورلے نیٹ ورک میں کیا ہو رہا ہے۔ CloudGate، بدلے میں، اوورلے نیٹ ورکس کو ایک دوسرے اور انٹرنیٹ کے ساتھ جوڑتا ہے۔
اب دیکھتے ہیں کہ ایک ورچوئل نیٹ ورک اسکیلنگ اور دستیابی کے مسائل کو کیسے حل کرتا ہے۔ آئیے ایک سادہ کیس پر غور کریں۔ ایک دستیابی زون ہے اور اس میں دو VPCs بنائے گئے ہیں۔ ہم نے ٹنگسٹن فیبرک کا ایک مثال تعینات کیا، اور یہ کئی دسیوں ہزار نیٹ ورکس کو کھینچتا ہے۔ نیٹ ورکس CloudGate کے ساتھ بات چیت کرتے ہیں۔ CloudGate، جیسا کہ ہم پہلے ہی کہہ چکے ہیں، ایک دوسرے اور انٹرنیٹ کے ساتھ ان کے رابطے کو یقینی بناتا ہے۔
ہم کہتے ہیں کہ دوسرا دستیابی زون شامل کیا گیا ہے۔ اسے پہلے سے مکمل طور پر آزادانہ طور پر ناکام ہونا چاہئے۔ لہذا، دوسرے دستیابی زون میں، ہمیں ایک علیحدہ ٹنگسٹن فیبرک مثال انسٹال کرنا چاہیے۔ یہ ایک الگ سسٹم ہوگا جو اوورلے سے متعلق ہے اور پہلے سسٹم کے بارے میں بہت کم جانتا ہے۔ اور یہ مرئیت کہ ہمارا ورچوئل نیٹ ورک عالمی ہے، درحقیقت، ہمارا VPC API بناتا ہے۔ یہ اس کا کام ہے۔
VPC1 کو Availability Zone B میں میپ کیا جاتا ہے اگر Availability Zone B میں وسائل موجود ہیں جنہیں VPC1 پر دھکیل دیا جاتا ہے۔ اگر دستیابی زون B میں VPC2 سے کوئی وسائل نہیں ہیں، تو ہم اس زون میں VPC2 کو عملی شکل نہیں دیں گے۔ بدلے میں، چونکہ VPC3 کے وسائل صرف زون B میں موجود ہیں، VPC3 زون A میں موجود نہیں ہے۔ سب کچھ سادہ اور منطقی ہے۔
آئیے تھوڑا گہرائی میں جائیں اور دیکھتے ہیں کہ Y.Cloud میں ایک خاص میزبان کیسے کام کرتا ہے۔ اہم چیز جو میں نوٹ کرنا چاہتا ہوں وہ یہ ہے کہ تمام میزبان اسی طرح ترتیب دیئے گئے ہیں۔ ہم اسے اس طرح بناتے ہیں کہ صرف ضروری کم از کم خدمات ہارڈ ویئر پر چلتی ہیں، باقی تمام ورچوئل مشینوں پر چلتی ہیں۔ ہم بنیادی ڈھانچے کی خدمات کی بنیاد پر اعلیٰ درجے کی خدمات تیار کرتے ہیں، اور کچھ انجینئرنگ مسائل کو حل کرنے کے لیے کلاؤڈ کا استعمال بھی کرتے ہیں، مثال کے طور پر، مسلسل انضمام کے فریم ورک کے اندر۔
اگر ہم کسی مخصوص میزبان کو دیکھیں تو ہم دیکھ سکتے ہیں کہ میزبان OS پر تین اجزاء چل رہے ہیں:
- کمپیوٹ - میزبان پر کمپیوٹنگ وسائل کی تقسیم کا ذمہ دار حصہ۔
- VRouter Tungsten Fabric کا ایک حصہ ہے جو ایک اوورلے کو منظم کرتا ہے، یعنی یہ پیکٹوں کو انڈرلے کے ذریعے سرنگ کرتا ہے۔
- VDisks اسٹوریج ورچوئلائزیشن کے حصے ہیں۔
اس کے علاوہ، خدمات ورچوئل مشینوں میں شروع کی جاتی ہیں: کلاؤڈ انفراسٹرکچر سروسز، پلیٹ فارم سروسز اور کسٹمر کی صلاحیتیں۔ کسٹمر کی صلاحیتیں اور پلیٹ فارم کی خدمات ہمیشہ VRouter کے ذریعے اوورلے پر جاتی ہیں۔
بنیادی ڈھانچے کی خدمات اوورلے میں چپک سکتی ہیں، لیکن بنیادی طور پر وہ انڈرلے میں کام کرنا چاہتی ہیں۔ وہ SR-IOV کی مدد سے انڈرلے میں پھنس گئے ہیں۔ درحقیقت، ہم کارڈ کو ورچوئل نیٹ ورک کارڈز (ورچوئل فنکشنز) میں کاٹتے ہیں اور انہیں انفراسٹرکچر ورچوئل مشینوں میں ڈال دیتے ہیں تاکہ کارکردگی ضائع نہ ہو۔ مثال کے طور پر، وہی کلاؤڈ گیٹ ان انفراسٹرکچر ورچوئل مشینوں میں سے ایک کے طور پر لانچ کیا گیا ہے۔
اب جب کہ ہم نے ورچوئل نیٹ ورک کے عالمی کاموں اور کلاؤڈ کے بنیادی اجزاء کی ساخت کو بیان کیا ہے، آئیے دیکھتے ہیں کہ ورچوئل نیٹ ورک کے مختلف حصے ایک دوسرے کے ساتھ کس طرح تعامل کرتے ہیں۔
ہم اپنے سسٹم میں تین پرتوں کو الگ کرتے ہیں:
- Config Plane - نظام کی ہدف حالت کا تعین کرتا ہے۔ یہ وہی ہے جسے صارف API کے ذریعے تشکیل دیتا ہے۔
- کنٹرول پلین - صارف کی وضاحت کردہ سیمنٹکس فراہم کرتا ہے، یعنی ڈیٹا پلین کی حالت کو وہی لاتا ہے جسے صارف نے کنفیگ پلین میں بیان کیا تھا۔
- ڈیٹا پلین - صارف کے پیکٹوں پر براہ راست کارروائی کرتا ہے۔
جیسا کہ میں نے اوپر کہا، یہ سب اس حقیقت سے شروع ہوتا ہے کہ صارف یا اندرونی پلیٹ فارم سروس API میں آتی ہے اور ایک مخصوص ہدف کی حالت کو بیان کرتی ہے۔
یہ حالت فوری طور پر Yandex ڈیٹا بیس پر لکھی جاتی ہے، API کے ذریعے غیر مطابقت پذیر آپریشن ID واپس کرتی ہے، اور صارف کی مطلوبہ حالت کو واپس کرنے کے لیے ہماری اندرونی مشینری شروع کرتی ہے۔ کنفیگریشن کے کام SDN کنٹرولر کے پاس جاتے ہیں اور Tungsten Fabric کو بتاتے ہیں کہ اوورلے میں کیا کرنا ہے۔ مثال کے طور پر، وہ بندرگاہیں، ورچوئل نیٹ ورکس، اور اس طرح کی چیزیں محفوظ کرتے ہیں۔
ٹنگسٹن فیبرک میں کنفیگ پلین مطلوبہ حالت کو کنٹرول پلین کو بھیجتا ہے۔ اس کے ذریعے، Config Plane میزبانوں کے ساتھ بات چیت کرتا ہے، یہ بتاتا ہے کہ ان پر جلد ہی کیا گھومنے والا ہے۔
اب دیکھتے ہیں کہ میزبانوں پر سسٹم کیسا لگتا ہے۔ ورچوئل مشین میں نیٹ ورک اڈاپٹر VRouter میں لگا ہوا ہے۔ VRouter ایک بنیادی ٹنگسٹن فیبرک ماڈیول ہے جو پیکٹوں کو دیکھتا ہے۔ اگر کسی پیکیج کے لیے پہلے سے ہی کوئی بہاؤ موجود ہے تو ماڈیول اس پر کارروائی کرتا ہے۔ اگر کوئی بہاؤ نہیں ہے تو، ماڈیول نام نہاد پنٹنگ کرتا ہے، یعنی یہ یوزر موڈ کے عمل کو ایک پیکٹ بھیجتا ہے۔ یہ عمل پیکٹ کو پارس کرتا ہے اور یا تو خود اس کا جواب دیتا ہے، جیسے DHCP اور DNS، یا VRouter کو بتاتا ہے کہ اس کے ساتھ کیا کرنا ہے۔ اس کے بعد، VRouter پیکٹ پر کارروائی کر سکتا ہے۔
مزید، ایک ہی ورچوئل نیٹ ورک کے اندر ورچوئل مشینوں کے درمیان ٹریفک شفاف طریقے سے جاتا ہے، اسے کلاؤڈ گیٹ کی طرف نہیں بھیج دیا جاتا ہے۔ وہ میزبان جن پر ورچوئل مشینیں تعینات ہیں ایک دوسرے سے براہ راست بات چیت کرتے ہیں۔ وہ ٹریفک کو سرنگ کرتے ہیں اور انڈرلے کے ذریعے ایک دوسرے کے لیے آگے بڑھاتے ہیں۔
کنٹرول طیارے BGP کے ذریعے دستیابی زون کے درمیان ایک دوسرے کے ساتھ بات چیت کرتے ہیں، جیسا کہ دوسرے روٹر کے ساتھ ہوتا ہے۔ وہ بتاتے ہیں کہ کون سی مشینیں کہاں ہیں تاکہ ایک زون میں VMs دوسرے VM کے ساتھ براہ راست بات چیت کر سکیں۔
اور کنٹرول طیارہ کلاؤڈ گیٹ کے ساتھ بات چیت کرتا ہے۔ اسی طرح، یہ رپورٹ کرتا ہے کہ کہاں اور کون سی ورچوئل مشینیں اٹھائی گئی ہیں، ان کے پاس کون سے پتے ہیں۔ یہ آپ کو بیلنسرز سے بیرونی ٹریفک اور ٹریفک کو ان تک بھیجنے کی اجازت دیتا ہے۔
VPC سے نکلنے والی ٹریفک کلاؤڈ گیٹ پر، ڈیٹا پاتھ پر آتی ہے، جہاں ہمارے پلگ ان کے ساتھ VPP کو جلدی سے چبایا جاتا ہے۔ پھر ٹریفک کو یا تو دوسرے VPCs یا باہر، بارڈر روٹرز پر بھیج دیا جاتا ہے جو خود CloudGate کے کنٹرول پلین کے ذریعے کنفیگر ہوتے ہیں۔
مستقبل قریب کے منصوبے
اگر ہم اوپر کہی گئی ہر چیز کا چند جملوں میں خلاصہ کرتے ہیں، تو ہم کہہ سکتے ہیں کہ Yandex.Cloud میں VPC دو اہم کاموں کو حل کرتا ہے:
- مختلف گاہکوں کے درمیان تنہائی فراہم کرتا ہے۔
- وسائل، انفراسٹرکچر، پلیٹ فارم کی خدمات، دوسرے کلاؤڈز اور آن پریمیس کو ایک نیٹ ورک میں یکجا کرتا ہے۔
اور ان مسائل کو اچھی طرح سے حل کرنے کے لیے، آپ کو اندرونی فن تعمیر کی سطح پر اسکیل ایبلٹی اور غلطی برداشت کرنے کی ضرورت ہے، جو VPC کرتا ہے۔
آہستہ آہستہ VPC افعال حاصل کرتا ہے، ہم نئی خصوصیات کو نافذ کرتے ہیں، ہم صارف کی سہولت کے لحاظ سے کچھ بہتر کرنے کی کوشش کرتے ہیں۔ کچھ خیالات کا اظہار کیا جاتا ہے اور ہماری کمیونٹی کے اراکین کی بدولت ترجیحی فہرست میں شامل ہوتے ہیں۔
ہمارے پاس فی الحال مستقبل قریب کے منصوبوں کی درج ذیل فہرست ہے:
- VPN بطور سروس
- پرائیویٹ DNS مثالیں پہلے سے تشکیل شدہ DNS سرور کے ساتھ ورچوئل مشینوں کو تیزی سے ترتیب دینے کی تصاویر ہیں۔
- DNS بطور سروس۔
- اندرونی بوجھ بیلنسر۔
- ورچوئل مشین کو دوبارہ بنائے بغیر ایک "سفید" IP ایڈریس شامل کرنا۔
بیلنسر اور پہلے سے بنائی گئی ورچوئل مشین کے لیے آئی پی ایڈریس کو تبدیل کرنے کی صلاحیت صارفین کی درخواست پر اس فہرست میں شامل تھی۔ سچ پوچھیں تو، واضح تاثرات کے بغیر، ہم ان افعال کو تھوڑی دیر بعد لے لیتے۔ اور اس لیے ہم پتے کے بارے میں پہلے ہی مسئلے پر کام کر رہے ہیں۔
ابتدائی طور پر، ایک "سفید" IP ایڈریس صرف مشین بناتے وقت شامل کیا جا سکتا تھا۔ اگر صارف یہ کرنا بھول گیا تو ورچوئل مشین کو دوبارہ بنانا ہوگا۔ وہی اور، اگر ضروری ہو تو، بیرونی IP کو ہٹا دیں۔ مشین کو دوبارہ بنائے بغیر عوامی IP کو آن اور آف کرنا جلد ہی ممکن ہو جائے گا۔
بلا جھجھک اظہار خیال کریں۔ دوسرے صارفین. آپ کلاؤڈ کو بہتر بنانے اور اہم اور مفید خصوصیات کو تیزی سے حاصل کرنے میں ہماری مدد کرتے ہیں!
ماخذ: www.habr.com