کلاؤڈ کمپیوٹنگ ہماری زندگیوں میں گہرائی سے داخل ہو رہی ہے اور شاید کوئی بھی ایسا شخص نہیں ہے جس نے کم از کم ایک بار بھی کلاؤڈ سروسز کا استعمال نہ کیا ہو۔ تاہم، بادل بالکل کیا ہے اور یہ کیسے کام کرتا ہے، بہت کم لوگ جانتے ہیں، یہاں تک کہ ایک خیال کی سطح پر بھی۔ 5G پہلے سے ہی ایک حقیقت بن رہا ہے اور ٹیلی کام کا بنیادی ڈھانچہ قطب کے حل سے کلاؤڈ حل کی طرف بڑھنا شروع کر رہا ہے، بالکل اسی طرح جب یہ مکمل طور پر ہارڈ ویئر کے حل سے ورچوئلائزڈ "ستون" کی طرف منتقل ہوا تھا۔
آج ہم کلاؤڈ انفراسٹرکچر کی اندرونی دنیا کے بارے میں بات کریں گے، خاص طور پر ہم نیٹ ورک کے حصے کی بنیادی باتوں کو دیکھیں گے۔
بادل کیا ہے؟ وہی ورچوئلائزیشن - پروفائل ویو؟
ایک منطقی سوال سے زیادہ۔ نہیں - یہ ورچوئلائزیشن نہیں ہے، حالانکہ یہ اس کے بغیر نہیں ہو سکتا۔ آئیے دو تعریفیں دیکھیں:
کلاؤڈ کمپیوٹنگ (اس کے بعد کلاؤڈ کہا جاتا ہے) تقسیم شدہ کمپیوٹنگ وسائل تک صارف کے لیے دوستانہ رسائی فراہم کرنے کا ایک ماڈل ہے جسے سروس فراہم کرنے والے کے لیے سب سے کم ممکنہ تاخیر اور کم سے کم لاگت کے ساتھ ڈیمانڈ پر تعینات اور لانچ کیا جانا چاہیے۔
ورچوئلائزیشن - یہ ایک فزیکل ہستی (مثال کے طور پر ایک سرور) کو کئی ورچوئل میں تقسیم کرنے کی صلاحیت ہے، اس طرح وسائل کے استعمال میں اضافہ ہوتا ہے (مثال کے طور پر، آپ کے پاس 3 سرورز 25-30 فیصد لوڈ ہوئے تھے، ورچوئلائزیشن کے بعد آپ کو 1 سرور لوڈ ہو جاتا ہے۔ 80-90 فیصد تک)۔ قدرتی طور پر، ورچوئلائزیشن کچھ وسائل کو کھا جاتی ہے - آپ کو ہائپرائزر کو کھانا کھلانے کی ضرورت ہے، تاہم، جیسا کہ پریکٹس نے دکھایا ہے، گیم موم بتی کے قابل ہے۔ ورچوئلائزیشن کی ایک مثالی مثال VMWare ہے، جو مکمل طور پر ورچوئل مشینیں تیار کرتی ہے، یا مثال کے طور پر KVM، جسے میں ترجیح دیتا ہوں، لیکن یہ ذائقہ کا معاملہ ہے۔
ہم اسے سمجھے بغیر ورچوئلائزیشن کا استعمال کرتے ہیں، اور یہاں تک کہ آئرن راؤٹرز بھی پہلے سے ہی ورچوئلائزیشن کا استعمال کرتے ہیں - مثال کے طور پر، JunOS کے تازہ ترین ورژن میں، آپریٹنگ سسٹم ریئل ٹائم لینکس ڈسٹری بیوشن (ونڈ ریور 9) کے اوپر ایک ورچوئل مشین کے طور پر انسٹال ہوتا ہے۔ لیکن ورچوئلائزیشن کلاؤڈ نہیں ہے، لیکن کلاؤڈ ورچوئلائزیشن کے بغیر موجود نہیں ہوسکتا۔
ورچوئلائزیشن عمارت کے بلاکس میں سے ایک ہے جس پر کلاؤڈ بنایا گیا ہے۔
صرف ایک L2 ڈومین میں کئی ہائپر وائزرز کو اکٹھا کرکے کلاؤڈ بنانا، کسی قسم کے جوابدہ کے ذریعے vlans کو خود بخود رجسٹر کرنے کے لیے یامل پلے بکس کے ایک جوڑے کو شامل کرنا اور خود کار طریقے سے ورچوئل مشینیں بنانے کے لیے اس پر آرکیسٹریشن سسٹم جیسی چیز کو جام کرنا کام نہیں کرے گا۔ یہ زیادہ درست ہوگا، لیکن نتیجے میں فرینکنسٹین وہ بادل نہیں ہے جس کی ہمیں ضرورت ہے، حالانکہ یہ دوسروں کے لیے حتمی خواب ہوسکتا ہے۔ مزید یہ کہ، اگر آپ وہی Openstack لیتے ہیں، تو یہ بنیادی طور پر اب بھی Frankenstein ہے، لیکن اوہ ٹھیک ہے، آئیے ابھی اس کے بارے میں بات نہیں کرتے ہیں۔
لیکن میں سمجھتا ہوں کہ اوپر پیش کی گئی تعریف سے یہ بالکل واضح نہیں ہے کہ اصل میں بادل کسے کہا جا سکتا ہے۔
لہذا، NIST (National Institute of Standards and Technology) کی ایک دستاویز 5 اہم خصوصیات فراہم کرتی ہے جو کلاؤڈ انفراسٹرکچر میں ہونی چاہیے:
درخواست پر سروس فراہم کرنا۔ صارف کو اس کے لیے مختص کمپیوٹر وسائل (جیسے نیٹ ورکس، ورچوئل ڈسک، میموری، پروسیسر کور وغیرہ) تک مفت رسائی دی جانی چاہیے، اور یہ وسائل خود بخود فراہم کیے جانے چاہئیں - یعنی سروس فراہم کرنے والے کی مداخلت کے بغیر۔
سروس کی وسیع دستیابی. معیاری پی سی اور پتلے کلائنٹس اور موبائل آلات دونوں کے استعمال کی اجازت دینے کے لیے وسائل تک رسائی معیاری میکانزم کے ذریعے فراہم کی جانی چاہیے۔
وسائل کو تالابوں میں ملانا۔ ریسورس پولز کو ایک ہی وقت میں متعدد کلائنٹس کو وسائل فراہم کرنے کے قابل ہونا چاہیے، اس بات کو یقینی بناتے ہوئے کہ کلائنٹس الگ تھلگ اور باہمی اثر و رسوخ اور وسائل کے لیے مسابقت سے پاک ہوں۔ تالابوں میں نیٹ ورکس بھی شامل ہیں، جو اوورلیپنگ ایڈریسنگ کے استعمال کے امکان کی نشاندہی کرتے ہیں۔ پولز کو طلب کے مطابق پیمانہ کرنے کے قابل ہونا چاہیے۔ پولز کا استعمال وسائل کی خرابی کی رواداری اور جسمانی اور ورچوئل وسائل کی تجرید کی ضروری سطح فراہم کرنا ممکن بناتا ہے - سروس کے وصول کنندہ کو صرف وسائل کا سیٹ فراہم کیا جاتا ہے جس کی اس نے درخواست کی تھی (جہاں یہ وسائل جسمانی طور پر واقع ہیں، کتنے پر سرورز اور سوئچز - اس سے کلائنٹ کو کوئی فرق نہیں پڑتا)۔ تاہم، ہمیں اس حقیقت کو مدنظر رکھنا چاہیے کہ فراہم کنندہ کو ان وسائل کی شفاف ریزرویشن کو یقینی بنانا چاہیے۔
مختلف حالات میں فوری موافقت۔ خدمات کو لچکدار ہونا چاہیے - وسائل کی تیزی سے فراہمی، ان کی دوبارہ تقسیم، کلائنٹ کی درخواست پر وسائل کو شامل کرنا یا کم کرنا، اور کلائنٹ کی طرف سے یہ احساس ہونا چاہیے کہ کلاؤڈ وسائل لامتناہی ہیں۔ سمجھنے میں آسانی کے لیے، مثال کے طور پر، آپ کو کوئی انتباہ نظر نہیں آتا ہے کہ Apple iCloud میں آپ کی ڈسک کی جگہ کا کچھ حصہ غائب ہو گیا ہے کیونکہ سرور پر ہارڈ ڈرائیو ٹوٹ گئی ہے، اور ڈرائیوز ٹوٹ جاتی ہیں۔ اس کے علاوہ، آپ کی طرف سے، اس سروس کے امکانات تقریباً لامحدود ہیں - آپ کو 2 ٹی بی کی ضرورت ہے - کوئی مسئلہ نہیں، آپ نے اسے ادا کیا اور وصول کیا۔ اسی طرح کی مثال Google.Drive یا Yandex.Disk کے ساتھ دی جا سکتی ہے۔
فراہم کردہ سروس کی پیمائش کا امکان۔ کلاؤڈ سسٹمز کو خود بخود استعمال شدہ وسائل کو کنٹرول اور بہتر بنانا چاہیے، اور یہ طریقہ کار صارف اور سروس فراہم کرنے والے دونوں کے لیے شفاف ہونا چاہیے۔ یعنی، آپ ہمیشہ چیک کر سکتے ہیں کہ آپ اور آپ کے کلائنٹس کتنے وسائل استعمال کر رہے ہیں۔
یہ اس حقیقت پر غور کرنے کے قابل ہے کہ یہ ضروریات زیادہ تر عوامی کلاؤڈ کی ضروریات ہیں، لہذا ایک نجی کلاؤڈ (یعنی کمپنی کی اندرونی ضروریات کے لیے شروع کردہ کلاؤڈ) کے لیے، ان ضروریات کو قدرے ایڈجسٹ کیا جا سکتا ہے۔ تاہم، انہیں ابھی کرنا باقی ہے، ورنہ ہم کلاؤڈ کمپیوٹنگ کے تمام فوائد حاصل نہیں کر پائیں گے۔
ہمیں بادل کی ضرورت کیوں ہے؟
تاہم، کوئی بھی نئی یا موجودہ ٹیکنالوجی، کوئی بھی نیا پروٹوکول کسی چیز کے لیے بنایا گیا ہے (اچھی طرح سے، سوائے RIP-ng کے، یقیناً)۔ کسی کو پروٹوکول کی خاطر پروٹوکول کی ضرورت نہیں ہے (اچھی طرح سے، RIP-ng کے علاوہ، یقینا)۔ یہ منطقی ہے کہ کلاؤڈ کو صارف/کلائنٹ کو کسی قسم کی خدمت فراہم کرنے کے لیے بنایا گیا ہے۔ ہم سب کم از کم کلاؤڈ سروسز کے ایک جوڑے سے واقف ہیں، مثال کے طور پر Dropbox یا Google.Docs، اور مجھے یقین ہے کہ زیادہ تر لوگ انہیں کامیابی سے استعمال کرتے ہیں - مثال کے طور پر، یہ مضمون Google.Docs کلاؤڈ سروس کا استعمال کرتے ہوئے لکھا گیا تھا۔ لیکن جن کلاؤڈ سروسز کو ہم جانتے ہیں وہ صرف کلاؤڈ کی صلاحیتوں کا حصہ ہیں — زیادہ واضح طور پر، وہ صرف SaaS قسم کی سروس ہیں۔ ہم کلاؤڈ سروس تین طریقوں سے فراہم کر سکتے ہیں: SaaS، PaaS یا IaaS کی شکل میں۔ آپ کو کس خدمت کی ضرورت ہے اس کا انحصار آپ کی خواہشات اور صلاحیتوں پر ہے۔
آئیے ہر ایک کو ترتیب سے دیکھیں:
سروس کے طور پر سافٹ ویئر (ساؤ) کلائنٹ کو مکمل سروس فراہم کرنے کا ایک ماڈل ہے، مثال کے طور پر، Yandex.Mail یا Gmail جیسی ای میل سروس۔ اس سروس ڈیلیوری ماڈل میں، آپ، ایک کلائنٹ کے طور پر، خدمات کو استعمال کرنے کے علاوہ کچھ نہیں کرتے ہیں - یعنی، آپ کو سروس کو ترتیب دینے، اس کی غلطی کو برداشت کرنے یا بے کار ہونے کے بارے میں سوچنے کی ضرورت نہیں ہے۔ اہم بات یہ ہے کہ آپ اپنے پاس ورڈ سے سمجھوتہ نہ کریں؛ اس سروس کا فراہم کنندہ آپ کے لیے باقی کام کرے گا۔ سروس فراہم کرنے والے کے نقطہ نظر سے، وہ پوری سروس کے لیے مکمل طور پر ذمہ دار ہے - سرور ہارڈویئر اور میزبان آپریٹنگ سسٹم سے لے کر ڈیٹا بیس اور سافٹ ویئر کی ترتیبات تک۔
ایک خدمت کے طور پر پلیٹ فارم (PaaS) - اس ماڈل کو استعمال کرتے وقت، سروس فراہم کرنے والا کلائنٹ کو سروس کے لیے ورک پیس فراہم کرتا ہے، مثال کے طور پر، آئیے ایک ویب سرور لیں۔ سروس فراہم کرنے والے نے کلائنٹ کو ایک ورچوئل سرور فراہم کیا (حقیقت میں، وسائل کا ایک سیٹ، جیسے کہ RAM/CPU/Storage/Nets وغیرہ)، اور یہاں تک کہ اس سرور پر OS اور ضروری سافٹ ویئر انسٹال کیا، تاہم، کنفیگریشن یہ سب کچھ کلائنٹ خود کرتا ہے اور سروس کی کارکردگی کے لیے کلائنٹ جواب دیتا ہے۔ سروس فراہم کرنے والا، جیسا کہ پچھلے معاملے میں، جسمانی آلات، ہائپر وائزرز، خود ورچوئل مشین، اس کے نیٹ ورک کی دستیابی، وغیرہ کی کارکردگی کا ذمہ دار ہے، لیکن خود سروس اب اپنی ذمہ داری کے دائرے میں نہیں ہے۔
انفراسٹرکچر بطور سروس (IAAS) - یہ نقطہ نظر پہلے سے زیادہ دلچسپ ہے، درحقیقت، سروس فراہم کرنے والا کلائنٹ کو ایک مکمل ورچوئلائزڈ انفراسٹرکچر فراہم کرتا ہے - یعنی وسائل کا کچھ سیٹ (پول)، جیسے CPU Cores، RAM، نیٹ ورکس وغیرہ۔ باقی سب کچھ اس پر منحصر ہے۔ کلائنٹ - کلائنٹ مختص پول (کوٹہ) کے اندر ان وسائل کے ساتھ کیا کرنا چاہتا ہے - یہ سپلائر کے لیے خاص طور پر اہم نہیں ہے۔ چاہے کلائنٹ اپنا وی ای پی سی بنانا چاہے یا ایک منی آپریٹر بنا کر کمیونیکیشن سروسز فراہم کرنا چاہے - کوئی سوال نہیں - ایسا کریں۔ ایسے حالات میں، سروس فراہم کنندہ وسائل کی فراہمی، ان کی غلطی کی برداشت اور دستیابی کے ساتھ ساتھ OS کے لیے ذمہ دار ہے جو انہیں ان وسائل کو جمع کرنے اور کسی بھی وقت وسائل کو بڑھانے یا کم کرنے کی اہلیت کے ساتھ کلائنٹ کو دستیاب کرنے کی اجازت دیتا ہے۔ کلائنٹ کی درخواست پر. کلائنٹ تمام ورچوئل مشینوں اور دیگر ٹنسل کو سیلف سروس پورٹل اور کنسول کے ذریعے خود ترتیب دیتا ہے، بشمول نیٹ ورکس (سوائے بیرونی نیٹ ورکس کے)۔
OpenStack کیا ہے؟
تینوں اختیارات میں، سروس فراہم کرنے والے کو ایک OS کی ضرورت ہے جو کلاؤڈ انفراسٹرکچر کی تخلیق کو قابل بنائے۔ درحقیقت، SaaS کے ساتھ، ایک سے زیادہ ڈویژنز ٹیکنالوجیز کے پورے اسٹیک کے لیے ذمہ دار ہیں - ایک ڈویژن ہے جو انفراسٹرکچر کے لیے ذمہ دار ہے - یعنی یہ کسی دوسرے ڈویژن کو IaaS فراہم کرتا ہے، یہ ڈویژن کلائنٹ کو SaaS فراہم کرتا ہے۔ اوپن اسٹیک ان کلاؤڈ آپریٹنگ سسٹمز میں سے ایک ہے جو آپ کو سوئچز، سرورز اور اسٹوریج سسٹمز کو ایک واحد ریسورس پول میں جمع کرنے، اس عام پول کو ذیلی پولز (کرایہ داروں) میں تقسیم کرنے اور نیٹ ورک پر کلائنٹس کو یہ وسائل فراہم کرنے کی اجازت دیتا ہے۔
OpenStack ایک کلاؤڈ آپریٹنگ سسٹم ہے جو آپ کو کمپیوٹنگ وسائل، ڈیٹا اسٹوریج اور نیٹ ورک کے وسائل کے بڑے تالابوں کو کنٹرول کرنے کی اجازت دیتا ہے، معیاری تصدیقی میکانزم کا استعمال کرتے ہوئے API کے ذریعے انتظام اور انتظام کیا جاتا ہے۔
دوسرے لفظوں میں، یہ مفت سافٹ ویئر پروجیکٹس کا ایک سیٹ ہے جو کلاؤڈ سروسز (سرکاری اور نجی دونوں) بنانے کے لیے ڈیزائن کیا گیا ہے - یعنی ٹولز کا ایک سیٹ جو آپ کو سرور اور سوئچنگ آلات کو وسائل کے ایک تالاب میں جوڑنے کی اجازت دیتا ہے۔ یہ وسائل، غلطی رواداری کی ضروری سطح فراہم کرتے ہیں۔
اس مواد کو لکھنے کے وقت، OpenStack کا ڈھانچہ اس طرح لگتا ہے:
سے لی گئی تصویر
OpenStack میں شامل ہر ایک اجزاء ایک مخصوص فنکشن انجام دیتا ہے۔ یہ تقسیم شدہ فن تعمیر آپ کو حل میں فعال اجزاء کے سیٹ کو شامل کرنے کی اجازت دیتا ہے جس کی آپ کو ضرورت ہے۔ تاہم، کچھ اجزاء جڑ کے اجزاء ہیں اور ان کے ہٹانے سے مجموعی طور پر حل کی مکمل یا جزوی ناکارہائی ہوگی۔ یہ اجزاء عام طور پر درجہ بندی کر رہے ہیں:
- ڈیش بورڈ - OpenStack خدمات کے انتظام کے لیے ویب پر مبنی GUI
- Keystone ایک مرکزی شناختی خدمت ہے جو دیگر خدمات کے لیے توثیق اور اجازت کی فعالیت فراہم کرتی ہے، نیز صارف کی اسناد اور ان کے کرداروں کا انتظام کرتی ہے۔
- نیوٹران - ایک نیٹ ورک سروس جو مختلف OpenStack سروسز کے انٹرفیس کے درمیان کنیکٹوٹی فراہم کرتی ہے (بشمول VMs کے درمیان کنیکٹوٹی اور بیرونی دنیا تک ان کی رسائی)
- کنڈر - ورچوئل مشینوں کے لیے بلاک اسٹوریج تک رسائی فراہم کرتا ہے۔
- نئی - ورچوئل مشینوں کا لائف سائیکل مینجمنٹ
- نظر — ورچوئل مشین امیجز اور سنیپ شاٹس کا ذخیرہ
- سوئفٹ - اسٹوریج آبجیکٹ تک رسائی فراہم کرتا ہے۔
- سیلومیٹر - ایک خدمت جو ٹیلی میٹری جمع کرنے اور دستیاب اور استعمال شدہ وسائل کی پیمائش کرنے کی صلاحیت فراہم کرتی ہے۔
- حرارت - خودکار تخلیق اور وسائل کی فراہمی کے لیے ٹیمپلیٹس پر مبنی آرکیسٹریشن
تمام منصوبوں اور ان کے مقاصد کی مکمل فہرست دیکھی جا سکتی ہے۔ .
ہر OpenStack جزو ایک ایسی خدمت ہے جو ایک مخصوص فنکشن انجام دیتی ہے اور اس فنکشن کو منظم کرنے اور ایک متحد انفراسٹرکچر بنانے کے لیے دیگر کلاؤڈ آپریٹنگ سسٹم سروسز کے ساتھ تعامل کرنے کے لیے ایک API فراہم کرتی ہے۔ مثال کے طور پر، نووا کمپیوٹنگ ریسورس مینجمنٹ اور ان وسائل کو کنفیگر کرنے کے لیے ایک API فراہم کرتا ہے، Glance ان کے انتظام کے لیے امیج مینجمنٹ اور ایک API فراہم کرتا ہے، Cinder بلاک اسٹوریج اور اس کے انتظام کے لیے API فراہم کرتا ہے، وغیرہ۔ تمام افعال ایک دوسرے سے بہت قریب سے جڑے ہوئے ہیں۔
تاہم، اگر آپ اسے دیکھیں تو، OpenStack میں چلنے والی تمام سروسز بالآخر نیٹ ورک سے منسلک کسی نہ کسی قسم کی ورچوئل مشین (یا کنٹینر) ہوتی ہیں۔ سوال یہ پیدا ہوتا ہے کہ ہمیں اتنے عناصر کی ضرورت کیوں ہے؟
آئیے ایک ورچوئل مشین بنانے اور اسے نیٹ ورک سے منسلک کرنے اور اوپن اسٹیک میں مستقل اسٹوریج کے الگورتھم کو دیکھیں۔
- جب آپ مشین بنانے کی درخواست کرتے ہیں، ہورائزن (ڈیش بورڈ) کے ذریعے درخواست ہو یا CLI کے ذریعے درخواست، سب سے پہلے جو ہوتا ہے وہ Keystone پر آپ کی درخواست کی اجازت ہے - کیا آپ مشین بنا سکتے ہیں، کیا اس میں اس نیٹ ورک کو استعمال کرنے کا حق، کیا آپ کا ڈرافٹ کوٹہ وغیرہ۔
- کی اسٹون آپ کی درخواست کی توثیق کرتا ہے اور جوابی پیغام میں ایک توثیق ٹوکن تیار کرتا ہے، جسے مزید استعمال کیا جائے گا۔ Keystone سے جواب موصول ہونے کے بعد، درخواست نووا (nova api) کی طرف بھیجی جاتی ہے۔
- Nova-api پہلے سے تیار کردہ auth ٹوکن کا استعمال کرتے ہوئے Keystone سے رابطہ کرکے آپ کی درخواست کی درستگی کی جانچ کرتا ہے۔
- Keystone توثیق کرتا ہے اور اس توثیق ٹوکن کی بنیاد پر اجازتوں اور پابندیوں کے بارے میں معلومات فراہم کرتا ہے۔
- Nova-api nova-database میں نئے VM کے لیے ایک اندراج تخلیق کرتا ہے اور مشین بنانے کی درخواست نووا-شیڈیولر کو بھیج دیتا ہے۔
- نووا-شیڈیولر میزبان (کمپیوٹر نوڈ) کا انتخاب کرتا ہے جس پر مخصوص پیرامیٹرز، وزن اور زون کی بنیاد پر VM کو تعینات کیا جائے گا۔ اس کا ریکارڈ اور VM ID نووا ڈیٹا بیس پر لکھے گئے ہیں۔
- اگلا، نووا-شیڈیولر ایک مثال کو تعینات کرنے کی درخواست کے ساتھ نووا-کمپیوٹ سے رابطہ کرتا ہے۔ نووا-کمپیوٹ مشین کے پیرامیٹرز کے بارے میں معلومات حاصل کرنے کے لیے نووا کنڈکٹر سے رابطہ کرتا ہے (نووا-کنڈکٹر ایک نووا عنصر ہے جو نووا-ڈیٹا بیس اور نووا-کمپیوٹ کے درمیان ایک پراکسی سرور کے طور پر کام کرتا ہے، ڈیٹا بیس کے مسائل سے بچنے کے لیے نووا-ڈیٹا بیس تک درخواستوں کی تعداد کو محدود کرتا ہے۔ مستقل بوجھ میں کمی)۔
- نووا کنڈکٹر نووا ڈیٹا بیس سے مطلوبہ معلومات حاصل کرتا ہے اور اسے نووا کمپیوٹ میں منتقل کرتا ہے۔
- اس کے بعد، تصویری ID حاصل کرنے کے لیے نووا کمپیوٹ کالز پر نظر ڈالتا ہے۔ Glace Keystone میں درخواست کی توثیق کرتا ہے اور درخواست کردہ معلومات واپس کرتا ہے۔
- نیٹ ورک پیرامیٹرز کے بارے میں معلومات حاصل کرنے کے لیے نووا کمپیوٹ رابطے نیوٹران۔ نظر کی طرح، نیوٹران Keystone میں درخواست کی توثیق کرتا ہے، جس کے بعد یہ ڈیٹا بیس میں ایک اندراج (پورٹ شناخت کنندہ، وغیرہ) بناتا ہے، پورٹ بنانے کی درخواست کرتا ہے، اور درخواست کردہ معلومات کو نووا کمپیوٹ میں واپس کرتا ہے۔
- ورچوئل مشین کو حجم مختص کرنے کی درخواست کے ساتھ نووا کمپیوٹ کانٹیکٹس سنڈر۔ نظر کی طرح، سائڈر Keystone میں درخواست کی توثیق کرتا ہے، حجم بنانے کی درخواست بناتا ہے، اور درخواست کردہ معلومات واپس کرتا ہے۔
- Nova-compute contacts libvirt مخصوص پیرامیٹرز کے ساتھ ورچوئل مشین کو تعینات کرنے کی درخواست کے ساتھ۔
درحقیقت، ایک سادہ ورچوئل مشین بنانے کا بظاہر آسان آپریشن کلاؤڈ پلیٹ فارم کے عناصر کے درمیان API کالوں کے ایسے بھنور میں بدل جاتا ہے۔ مزید برآں، جیسا کہ آپ دیکھ سکتے ہیں، یہاں تک کہ پہلے نامزد کردہ خدمات بھی چھوٹے اجزاء پر مشتمل ہوتی ہیں جن کے درمیان تعامل ہوتا ہے۔ ایک مشین بنانا اس کا صرف ایک چھوٹا حصہ ہے جو آپ کو کلاؤڈ پلیٹ فارم کرنے کی اجازت دیتا ہے - ٹریفک کو متوازن کرنے کے لیے ایک سروس ذمہ دار ہے، ایک سروس بلاک اسٹوریج کے لیے ذمہ دار ہے، ایک سروس DNS کے لیے ذمہ دار ہے، ایک خدمت ہے جو ننگے میٹل سرورز کی فراہمی کے لیے ذمہ دار ہے، وغیرہ۔ بادل آپ کو اجازت دیتا ہے کہ آپ اپنی ورچوئل مشینوں کو بھیڑوں کے ریوڑ کی طرح برتاؤ کریں (ورچوئلائزیشن کے برخلاف)۔ اگر آپ کی مشین کو ورچوئل ماحول میں کچھ ہوتا ہے - آپ اسے بیک اپ وغیرہ سے بحال کرتے ہیں، لیکن کلاؤڈ ایپلی کیشنز اس طرح سے بنتی ہیں کہ ورچوئل مشین اتنا اہم کردار ادا نہیں کرتی ہے - ورچوئل مشین "مر گئی" - کوئی مسئلہ نہیں - ایک نئی گاڑی ابھی بنائی گئی ہے جو ٹیمپلیٹ پر مبنی ہے اور جیسا کہ وہ کہتے ہیں، اسکواڈ نے لڑاکا کے نقصان کا نوٹس نہیں لیا۔ قدرتی طور پر، یہ آرکیسٹریشن میکانزم کی موجودگی فراہم کرتا ہے - ہیٹ ٹیمپلیٹس کا استعمال کرتے ہوئے، آپ آسانی سے درجنوں نیٹ ورکس اور ورچوئل مشینوں پر مشتمل ایک پیچیدہ فنکشن لگا سکتے ہیں۔
یہ ہمیشہ ذہن میں رکھنے کے قابل ہے کہ نیٹ ورک کے بغیر کوئی کلاؤڈ انفراسٹرکچر نہیں ہے - ہر عنصر کسی نہ کسی طریقے سے نیٹ ورک کے ذریعے دوسرے عناصر کے ساتھ تعامل کرتا ہے۔ اس کے علاوہ، کلاؤڈ میں بالکل غیر جامد نیٹ ورک ہے۔ قدرتی طور پر، انڈرلے نیٹ ورک بھی کم و بیش جامد ہے - نئے نوڈس اور سوئچز ہر روز شامل نہیں کیے جاتے ہیں، لیکن اوورلے کا جزو لامحالہ بدل سکتا ہے اور ہوتا رہے گا - نئے نیٹ ورکس کو شامل یا حذف کیا جائے گا، نئی ورچوئل مشینیں نمودار ہوں گی اور پرانی ہوں گی۔ مرنا اور جیسا کہ آپ کو مضمون کے بالکل شروع میں دی گئی کلاؤڈ کی تعریف سے یاد ہے، وسائل صارف کو خود بخود اور سروس فراہم کنندہ کی مداخلت کے ساتھ کم سے کم (یا بہتر ابھی تک) کے ساتھ مختص کیے جانے چاہئیں۔ یعنی نیٹ ورک کے وسائل کی فراہمی کی وہ قسم جو اب آپ کے ذاتی اکاؤنٹ کی شکل میں فرنٹ اینڈ کی شکل میں موجود ہے جو http/https کے ذریعے قابل رسائی ہے اور آن ڈیوٹی نیٹ ورک انجینئر واسیلی بطور بیک اینڈ کلاؤڈ نہیں ہے، یہاں تک کہ اگر واسلی کے آٹھ ہاتھ ہیں۔
نیوٹران، ایک نیٹ ورک سروس کے طور پر، کلاؤڈ انفراسٹرکچر کے نیٹ ورک حصے کے انتظام کے لیے ایک API فراہم کرتا ہے۔ سروس نیٹ ورک-ایس-اے-سروس (NaaS) نامی تجریدی پرت فراہم کرکے اوپن اسٹیک کے نیٹ ورکنگ حصے کو طاقت اور انتظام کرتی ہے۔ یعنی، نیٹ ورک وہی مجازی پیمائشی اکائی ہے، مثال کے طور پر، ورچوئل CPU کور یا RAM کی مقدار۔
لیکن OpenStack کے نیٹ ورک کے حصے کے فن تعمیر پر جانے سے پہلے، آئیے غور کریں کہ یہ نیٹ ورک اوپن اسٹیک میں کیسے کام کرتا ہے اور نیٹ ورک کلاؤڈ کا ایک اہم اور لازمی حصہ کیوں ہے۔
لہذا ہمارے پاس دو RED کلائنٹ VMs اور دو GREEN کلائنٹ VMs ہیں۔ آئیے فرض کریں کہ یہ مشینیں دو ہائپر وائزرز پر اس طرح واقع ہیں:
اس وقت، یہ صرف 4 سرورز کی ورچوئلائزیشن ہے اور اس سے زیادہ کچھ نہیں، کیونکہ اب تک ہم نے صرف 4 سرورز کو دو فزیکل سرورز پر رکھ کر ورچوئلائز کیا ہے۔ اور اب تک وہ نیٹ ورک سے منسلک بھی نہیں ہیں۔
بادل بنانے کے لیے، ہمیں کئی اجزاء شامل کرنے کی ضرورت ہے۔ سب سے پہلے، ہم نیٹ ورک کے حصے کو ورچوئلائز کرتے ہیں - ہمیں ان 4 مشینوں کو جوڑوں میں جوڑنے کی ضرورت ہے، اور کلائنٹ ایک L2 کنکشن چاہتے ہیں۔ آپ ایک سوئچ کا استعمال کر سکتے ہیں اور اس کی سمت میں ایک ٹرنک کو ترتیب دے سکتے ہیں اور لینکس برج کا استعمال کرتے ہوئے ہر چیز کو حل کر سکتے ہیں یا، زیادہ جدید صارفین کے لیے، openvswitch (ہم اس پر بعد میں واپس جائیں گے)۔ لیکن بہت سارے نیٹ ورکس ہو سکتے ہیں، اور L2 کو سوئچ کے ذریعے مسلسل دھکیلنا بہترین خیال نہیں ہے - یہاں مختلف محکمے ہیں، ایک سروس ڈیسک، درخواست کے مکمل ہونے کے مہینوں انتظار، مسائل کا حل کرنے کے ہفتوں - جدید دنیا میں یہ نقطہ نظر اب کام نہیں کرتا. اور جتنی جلدی کوئی کمپنی اس کو سمجھ جائے گی، اس کے لیے آگے بڑھنا اتنا ہی آسان ہوگا۔ لہذا، ہائپر وائزرز کے درمیان ہم ایک L3 نیٹ ورک کا انتخاب کریں گے جس کے ذریعے ہماری ورچوئل مشینیں بات چیت کریں گی، اور اس L3 نیٹ ورک کے اوپر ہم ورچوئل L2 اوورلے نیٹ ورکس بنائیں گے جہاں ہماری ورچوئل مشینوں کی ٹریفک چلے گی۔ آپ GRE، Geneve یا VxLAN کو encapsulation کے طور پر استعمال کر سکتے ہیں۔ آئیے فی الحال مؤخر الذکر پر توجہ مرکوز کرتے ہیں، حالانکہ یہ خاص طور پر اہم نہیں ہے۔
ہمیں کہیں VTEP تلاش کرنے کی ضرورت ہے (مجھے امید ہے کہ ہر کوئی VxLAN اصطلاحات سے واقف ہے)۔ چونکہ ہمارے پاس سرورز سے سیدھا ایک L3 نیٹ ورک آرہا ہے، اس لیے ہمیں سرورز پر VTEP لگانے سے کوئی چیز نہیں روکتی، اور OVS (OpenvSwitch) ایسا کرنے میں بہترین ہے۔ نتیجے کے طور پر، ہمیں یہ ڈیزائن ملا:
چونکہ VMs کے درمیان ٹریفک کو تقسیم کرنا ضروری ہے، اس لیے ورچوئل مشینوں کی طرف بندرگاہوں کے vlan نمبر مختلف ہوں گے۔ ٹیگ نمبر صرف ایک ورچوئل سوئچ کے اندر کردار ادا کرتا ہے، کیونکہ جب VxLAN میں شامل ہوتا ہے تو ہم اسے آسانی سے ہٹا سکتے ہیں، کیونکہ ہمارے پاس VNI ہوگا۔
اب ہم ان کے لیے بغیر کسی پریشانی کے اپنی مشینیں اور ورچوئل نیٹ ورک بنا سکتے ہیں۔
تاہم، اگر کلائنٹ کے پاس دوسری مشین ہے، لیکن وہ مختلف نیٹ ورک پر ہے؟ ہمیں نیٹ ورکس کے درمیان روٹ کرنے کی ضرورت ہے۔ جب سنٹرلائزڈ روٹنگ کا استعمال کیا جائے گا تو ہم ایک آسان آپشن دیکھیں گے - یعنی ٹریفک کو خصوصی سرشار نیٹ ورک نوڈس کے ذریعے روٹ کیا جاتا ہے (اچھی طرح سے، ایک اصول کے طور پر، وہ کنٹرول نوڈس کے ساتھ مل جاتے ہیں، لہذا ہمارے پاس ایک ہی چیز ہوگی)۔
ایسا لگتا ہے کہ کچھ بھی پیچیدہ نہیں ہے - ہم کنٹرول نوڈ پر ایک پل انٹرفیس بناتے ہیں، اس کی طرف ٹریفک چلاتے ہیں اور وہاں سے جہاں ہمیں ضرورت ہوتی ہے اسے روٹ کرتے ہیں۔ لیکن مسئلہ یہ ہے کہ RED کلائنٹ 10.0.0.0/24 نیٹ ورک استعمال کرنا چاہتا ہے، اور GREEN کلائنٹ 10.0.0.0/24 نیٹ ورک استعمال کرنا چاہتا ہے۔ یعنی، ہم ایڈریس اسپیس کو آپس میں جوڑنا شروع کر دیتے ہیں۔ مزید برآں، کلائنٹس نہیں چاہتے ہیں کہ دوسرے کلائنٹس ان کے اندرونی نیٹ ورکس میں جانے کے قابل ہوں، جو سمجھ میں آتا ہے۔ نیٹ ورکس اور کلائنٹ ڈیٹا ٹریفک کو الگ کرنے کے لیے، ہم ان میں سے ہر ایک کے لیے الگ نام کی جگہ مختص کریں گے۔ نیم اسپیس درحقیقت لینکس نیٹ ورک اسٹیک کی ایک کاپی ہے، یعنی نام کی جگہ RED میں کلائنٹس نیم اسپیس GREEN کے کلائنٹس سے مکمل طور پر الگ تھلگ ہیں (اچھی طرح سے، ان کلائنٹ نیٹ ورکس کے درمیان روٹنگ کی اجازت ڈیفالٹ نیم اسپیس کے ذریعے ہے یا اپ اسٹریم ٹرانسپورٹ آلات پر)۔
یعنی، ہمیں مندرجہ ذیل خاکہ ملتا ہے:
L2 سرنگیں تمام کمپیوٹنگ نوڈس سے کنٹرول نوڈ تک جاتی ہیں۔ نوڈ جہاں ان نیٹ ورکس کے لیے L3 انٹرفیس واقع ہے، ہر ایک کو الگ تھلگ کرنے کے لیے مخصوص نام کی جگہ میں۔
تاہم، ہم سب سے اہم بات بھول گئے. ورچوئل مشین کو کلائنٹ کو ایک سروس فراہم کرنی چاہیے، یعنی اس کے پاس کم از کم ایک بیرونی انٹرفیس ہونا چاہیے جس کے ذریعے اس تک پہنچا جا سکے۔ یعنی ہمیں باہر کی دنیا میں جانے کی ضرورت ہے۔ یہاں مختلف اختیارات ہیں۔ آئیے سب سے آسان آپشن کرتے ہیں۔ ہم ہر کلائنٹ میں ایک نیٹ ورک شامل کریں گے، جو فراہم کنندہ کے نیٹ ورک میں درست ہوگا اور دوسرے نیٹ ورکس کے ساتھ اوورلیپ نہیں ہوگا۔ نیٹ ورکس فراہم کرنے والے نیٹ ورک کے اطراف میں مختلف VRFs کو بھی ایک دوسرے کو کاٹ سکتے ہیں اور دیکھ سکتے ہیں۔ نیٹ ورک کا ڈیٹا ہر کلائنٹ کے نام کی جگہ میں بھی رہے گا۔ تاہم، وہ اب بھی ایک جسمانی (یا بانڈ، جو زیادہ منطقی ہے) انٹرفیس کے ذریعے باہر کی دنیا میں جائیں گے۔ کلائنٹ ٹریفک کو الگ کرنے کے لیے، باہر جانے والی ٹریفک کو کلائنٹ کے لیے مختص VLAN ٹیگ کے ساتھ ٹیگ کیا جائے گا۔
نتیجے کے طور پر، ہمیں یہ خاکہ ملا:
ایک معقول سوال یہ ہے کہ کمپیوٹ نوڈس پر خود گیٹ وے کیوں نہیں بناتے؟ یہ کوئی بڑا مسئلہ نہیں ہے، مزید یہ کہ اگر آپ ڈسٹری بیوٹڈ راؤٹر (DVR) کو آن کرتے ہیں تو یہ کام کرے گا۔ اس منظر نامے میں، ہم مرکزی گیٹ وے کے ساتھ سب سے آسان آپشن پر غور کر رہے ہیں، جو Openstack میں بطور ڈیفالٹ استعمال ہوتا ہے۔ زیادہ بوجھ والے افعال کے لیے، وہ تقسیم شدہ روٹر اور ایکسلریشن ٹیکنالوجیز جیسے کہ SR-IOV اور پاس تھرو دونوں استعمال کریں گے، لیکن جیسا کہ وہ کہتے ہیں، یہ بالکل مختلف کہانی ہے۔ پہلے، آئیے بنیادی حصے سے نمٹتے ہیں، اور پھر ہم تفصیلات میں جائیں گے۔
دراصل، ہماری اسکیم پہلے ہی قابل عمل ہے، لیکن اس میں چند باریکیاں ہیں:
- ہمیں کسی نہ کسی طرح اپنی مشینوں کی حفاظت کرنے کی ضرورت ہے، یعنی کلائنٹ کی طرف سوئچ انٹرفیس پر فلٹر لگانا ہے۔
- ورچوئل مشین کے لیے خود بخود IP ایڈریس حاصل کرنا ممکن بنائیں، تاکہ آپ کو ہر بار کنسول کے ذریعے اس میں لاگ ان ہونے اور ایڈریس کو رجسٹر کرنے کی ضرورت نہ ہو۔
آئیے مشین کے تحفظ کے ساتھ شروع کریں۔ اس کے لیے آپ banal iptables استعمال کر سکتے ہیں، کیوں نہیں۔
یعنی، اب ہماری ٹوپولوجی قدرے پیچیدہ ہو گئی ہے:
آئیے آگے بڑھیں۔ ہمیں DHCP سرور شامل کرنے کی ضرورت ہے۔ ہر کلائنٹ کے لیے DHCP سرورز کو تلاش کرنے کے لیے سب سے بہترین جگہ وہ کنٹرول نوڈ ہو گا جو پہلے ہی اوپر بیان کیا گیا ہے، جہاں نام کی جگہیں واقع ہیں:
تاہم، ایک چھوٹا سا مسئلہ ہے. کیا ہوگا اگر سب کچھ دوبارہ شروع ہو جائے اور DHCP پر کرائے پر لینے کے بارے میں تمام معلومات غائب ہو جائیں۔ یہ منطقی ہے کہ مشینوں کو نئے پتے دیے جائیں گے، جو زیادہ آسان نہیں ہے۔ یہاں دو طریقے ہیں - یا تو ڈومین نام استعمال کریں اور ہر کلائنٹ کے لیے DNS سرور شامل کریں، پھر پتہ ہمارے لیے خاص طور پر اہم نہیں ہوگا (k8s میں نیٹ ورک کے حصے کی طرح) - لیکن بیرونی نیٹ ورکس کے ساتھ ایک مسئلہ ہے، کیونکہ ان میں ایڈریس بھی DHCP کے ذریعے جاری کیے جا سکتے ہیں - آپ کو کلاؤڈ پلیٹ فارم میں DNS سرورز اور ایک بیرونی DNS سرور کے ساتھ ہم آہنگی کی ضرورت ہے، جو میری رائے میں بہت لچکدار نہیں ہے، لیکن کافی ممکن ہے۔ یا دوسرا آپشن میٹا ڈیٹا کا استعمال کرنا ہے - یعنی مشین کو جاری کردہ ایڈریس کے بارے میں معلومات کو محفوظ کریں تاکہ DHCP سرور کو معلوم ہو کہ اگر مشین کو پہلے ہی ایڈریس موصول ہو چکا ہے تو مشین کو کون سا ایڈریس جاری کرنا ہے۔ دوسرا آپشن آسان اور زیادہ لچکدار ہے، کیونکہ یہ آپ کو کار کے بارے میں اضافی معلومات محفوظ کرنے کی اجازت دیتا ہے۔ اب آئیے ایجنٹ میٹا ڈیٹا کو خاکہ میں شامل کریں:
ایک اور مسئلہ جس پر بحث کرنے کے قابل بھی ہے وہ ہے تمام کلائنٹس کی طرف سے ایک بیرونی نیٹ ورک استعمال کرنے کی اہلیت، کیونکہ بیرونی نیٹ ورکس، اگر وہ پورے نیٹ ورک میں درست ہونے چاہئیں، مشکل ہو جائیں گے - آپ کو ان نیٹ ورکس کے مختص کو مستقل طور پر مختص اور کنٹرول کرنے کی ضرورت ہے۔ عوامی کلاؤڈ بناتے وقت تمام کلائنٹس کے لیے ایک ہی بیرونی پری کنفیگرڈ نیٹ ورک کو استعمال کرنے کی صلاحیت بہت مفید ہوگی۔ اس سے مشینوں کو تعینات کرنا آسان ہو جائے گا کیونکہ ہمیں ایڈریس ڈیٹا بیس سے مشورہ کرنے اور ہر کلائنٹ کے بیرونی نیٹ ورک کے لیے ایک منفرد ایڈریس اسپیس منتخب کرنے کی ضرورت نہیں ہے۔ اس کے علاوہ، ہم ایک بیرونی نیٹ ورک کو پہلے سے رجسٹر کر سکتے ہیں اور تعیناتی کے وقت ہمیں صرف کلائنٹ مشینوں کے ساتھ بیرونی پتوں کو منسلک کرنے کی ضرورت ہوگی۔
اور یہاں NAT ہماری مدد کے لیے آتا ہے - ہم صرف NAT ترجمہ کا استعمال کرتے ہوئے ڈیفالٹ نام کی جگہ کے ذریعے کلائنٹس کے لیے بیرونی دنیا تک رسائی ممکن بنائیں گے۔ ٹھیک ہے، یہاں ایک چھوٹا سا مسئلہ ہے. یہ اچھا ہے اگر کلائنٹ کا سرور کلائنٹ کے طور پر کام کرتا ہے نہ کہ سرور کے طور پر - یعنی یہ کنکشن قبول کرنے کے بجائے شروع کرتا ہے۔ لیکن ہمارے لیے اس کے برعکس ہوگا۔ اس صورت میں، ہمیں ڈیسٹینیشن NAT کرنے کی ضرورت ہے تاکہ ٹریفک موصول ہونے پر، کنٹرول نوڈ سمجھے کہ یہ ٹریفک کلائنٹ A کی ورچوئل مشین A کے لیے ہے، جس کا مطلب ہے کہ ہمیں کسی بیرونی ایڈریس سے NAT کا ترجمہ کرنے کی ضرورت ہے، مثال کے طور پر 100.1.1.1۔ .10.0.0.1، اندرونی پتہ 100 پر۔ اس صورت میں، اگرچہ تمام کلائنٹس ایک ہی نیٹ ورک کا استعمال کریں گے، لیکن اندرونی تنہائی مکمل طور پر محفوظ ہے۔ یعنی، ہمیں کنٹرول نوڈ پر dNAT اور sNAT کرنے کی ضرورت ہے۔ آیا فلوٹنگ ایڈریسز کے ساتھ ایک نیٹ ورک استعمال کرنا ہے یا بیرونی نیٹ ورکس، یا دونوں ایک ساتھ، اس بات پر منحصر ہے کہ آپ کلاؤڈ میں کیا لانا چاہتے ہیں۔ ہم ڈائیگرام میں تیرتے پتے شامل نہیں کریں گے، لیکن پہلے سے شامل کیے گئے بیرونی نیٹ ورکس کو چھوڑ دیں گے - ہر کلائنٹ کا اپنا ایک بیرونی نیٹ ورک ہوتا ہے (ڈائیگرام میں انہیں بیرونی انٹرفیس پر vlan 200 اور XNUMX کے طور پر دکھایا گیا ہے)۔
نتیجے کے طور پر، ہمیں ایک دلچسپ اور اسی وقت سوچا سمجھا حل ملا، جس میں ایک خاص لچک ہے لیکن اس میں ابھی تک غلطی برداشت کرنے کا طریقہ کار نہیں ہے۔
سب سے پہلے، ہمارے پاس صرف ایک کنٹرول نوڈ ہے - اس کی ناکامی تمام نظاموں کے خاتمے کا باعث بنے گی۔ اس مسئلے کو حل کرنے کے لیے، آپ کو کم از کم 3 نوڈس کا کورم بنانا ہوگا۔ آئیے اسے خاکہ میں شامل کریں:
قدرتی طور پر، تمام نوڈس ہم آہنگ ہوتے ہیں اور جب ایک فعال نوڈ نکل جاتا ہے، تو دوسرا نوڈ اپنی ذمہ داریاں سنبھال لے گا۔
اگلا مسئلہ ورچوئل مشین ڈسک کا ہے۔ اس وقت، وہ خود ہائپر وائزر پر محفوظ ہیں، اور ہائپر وائزر کے ساتھ مسائل کی صورت میں، ہم تمام ڈیٹا کھو دیتے ہیں - اور اگر ہم ڈسک کو نہیں بلکہ پورا سرور کھو دیتے ہیں تو چھاپے کی موجودگی یہاں مدد نہیں کرے گی۔ ایسا کرنے کے لیے، ہمیں ایک ایسی سروس بنانے کی ضرورت ہے جو کسی قسم کے سٹوریج کے لیے فرنٹ اینڈ کے طور پر کام کرے۔ یہ کس قسم کا ذخیرہ ہوگا ہمارے لیے خاص طور پر اہم نہیں ہے، لیکن اسے ہمارے ڈیٹا کو ڈسک اور نوڈ، اور ممکنہ طور پر پوری کابینہ دونوں کی ناکامی سے بچانا چاہیے۔ یہاں کئی آپشنز ہیں - یقیناً فائبر چینل کے ساتھ SAN نیٹ ورکس موجود ہیں، لیکن آئیے ایماندار بنیں - FC پہلے سے ہی ماضی کی یادگار ہے - ٹرانسپورٹ میں E1 کا ایک اینالاگ - ہاں، میں متفق ہوں، یہ اب بھی استعمال ہوتا ہے، لیکن صرف جہاں یہ اس کے بغیر بالکل ناممکن ہے۔ لہذا، میں 2020 میں رضاکارانہ طور پر ایف سی نیٹ ورک تعینات نہیں کروں گا، یہ جانتے ہوئے کہ اس کے علاوہ اور بھی دلچسپ متبادل ہیں۔ اگرچہ ہر ایک کا اپنا، وہاں وہ لوگ ہو سکتے ہیں جو یہ مانتے ہیں کہ FC اپنی تمام حدود کے ساتھ صرف ہمیں ضرورت ہے - میں بحث نہیں کروں گا، ہر ایک کی اپنی رائے ہے۔ تاہم، میری رائے میں سب سے دلچسپ حل ایس ڈی ایس کا استعمال کرنا ہے، جیسے سیف۔
Ceph آپ کو بیک اپ کے ممکنہ اختیارات کے ایک گروپ کے ساتھ ایک انتہائی دستیاب ڈیٹا سٹوریج سلوشن بنانے کی اجازت دیتا ہے، جس کا آغاز برابری کی جانچ کے ساتھ کوڈز سے ہوتا ہے (5 یا 6 کے مطابق) مختلف ڈسکوں پر مکمل ڈیٹا ریپلیکشن کے ساتھ ختم ہوتا ہے سرورز، اور الماریوں میں سرورز وغیرہ۔
Ceph بنانے کے لیے آپ کو مزید 3 نوڈس کی ضرورت ہے۔ سٹوریج کے ساتھ تعامل بھی نیٹ ورک کے ذریعے بلاک، آبجیکٹ اور فائل سٹوریج سروسز کے ذریعے کیا جائے گا۔ آئیے اسکیما میں اسٹوریج شامل کریں:
نوٹ: آپ ہائپر کنورجڈ کمپیوٹ نوڈس بھی بنا سکتے ہیں - یہ ایک نوڈ پر کئی فنکشنز کو یکجا کرنے کا تصور ہے - مثال کے طور پر، اسٹوریج + کمپیوٹ - سیف اسٹوریج کے لیے خصوصی نوڈس وقف کیے بغیر۔ ہمیں وہی غلطی برداشت کرنے والی اسکیم ملے گی - چونکہ SDS ہمارے بیان کردہ ریزرویشن لیول کے ساتھ ڈیٹا محفوظ کرے گا۔ تاہم، ہائپر کنورجڈ نوڈس ہمیشہ ایک سمجھوتہ ہوتے ہیں - چونکہ اسٹوریج نوڈ صرف ہوا کو گرم نہیں کرتا جیسا کہ پہلی نظر میں لگتا ہے (چونکہ اس پر کوئی ورچوئل مشینیں نہیں ہیں) - یہ SDS کی سروسنگ پر CPU کے وسائل خرچ کرتا ہے (حقیقت میں، یہ سب کچھ کرتا ہے۔ نوڈس، ڈسک وغیرہ کی ناکامی کے بعد نقل اور بحالی)۔ یعنی، اگر آپ اسے اسٹوریج کے ساتھ جوڑتے ہیں تو آپ کمپیوٹ نوڈ کی کچھ طاقت کھو دیں گے۔
ان تمام چیزوں کو کسی نہ کسی طرح منظم کرنے کی ضرورت ہے - ہمیں کسی ایسی چیز کی ضرورت ہے جس کے ذریعے ہم ایک مشین، ایک نیٹ ورک، ایک ورچوئل راؤٹر وغیرہ بنا سکیں۔ ایسا کرنے کے لیے، ہم کنٹرول نوڈ میں ایک سروس شامل کریں گے جو ڈیش بورڈ کے طور پر کام کرے گی۔ کلائنٹ http/ https کے ذریعے اس پورٹل سے جڑنے کے قابل ہو گا اور اپنی ضرورت کی ہر چیز کر سکے گا (اچھی طرح سے، تقریباً)۔
نتیجے کے طور پر، اب ہمارے پاس غلطی برداشت کرنے والا نظام ہے۔ اس بنیادی ڈھانچے کے تمام عناصر کو کسی نہ کسی طرح منظم کیا جانا چاہیے۔ یہ پہلے بیان کیا گیا تھا کہ Openstack منصوبوں کا ایک مجموعہ ہے، جن میں سے ہر ایک مخصوص فنکشن فراہم کرتا ہے۔ جیسا کہ ہم دیکھتے ہیں، کافی سے زیادہ عناصر ہیں جن کو ترتیب دینے اور کنٹرول کرنے کی ضرورت ہے۔ آج ہم نیٹ ورک کے حصے کے بارے میں بات کریں گے۔
نیوٹران فن تعمیر
OpenStack میں، یہ نیوٹران ہے جو ورچوئل مشین پورٹس کو ایک مشترکہ L2 نیٹ ورک سے منسلک کرنے، مختلف L2 نیٹ ورکس پر واقع VMs کے درمیان ٹریفک روٹنگ کو یقینی بنانے کے ساتھ ساتھ آؤٹورڈ روٹنگ، NAT، Floating IP، DHCP وغیرہ جیسی خدمات فراہم کرنے کا ذمہ دار ہے۔
اعلی سطح پر، نیٹ ورک سروس (بنیادی حصہ) کے آپریشن کو مندرجہ ذیل بیان کیا جا سکتا ہے۔
VM شروع کرتے وقت، نیٹ ورک سروس:
- دیئے گئے VM (یا بندرگاہوں) کے لیے ایک پورٹ بناتا ہے اور DHCP سروس کو اس کے بارے میں مطلع کرتا ہے۔
- ایک نیا ورچوئل نیٹ ورک ڈیوائس بنایا گیا ہے (بذریعہ libvirt)؛
- VM مرحلہ 1 میں بنائے گئے بندرگاہوں سے جڑتا ہے۔
عجیب بات یہ ہے کہ نیوٹران کا کام معیاری میکانزم پر مبنی ہے جو ہر اس شخص سے واقف ہے جس نے کبھی لینکس میں غوطہ لگایا ہے - نام کی جگہیں، iptables، linux bridges، openvswitch، conntrack، وغیرہ۔
یہ فوری طور پر واضح کیا جانا چاہئے کہ نیوٹران SDN کنٹرولر نہیں ہے۔
نیوٹران کئی ایک دوسرے سے جڑے ہوئے اجزاء پر مشتمل ہے:
اوپن اسٹیک نیوٹران سرور ایک ڈیمون ہے جو API کے ذریعے صارف کی درخواستوں کے ساتھ کام کرتا ہے۔ یہ شیطان کسی بھی نیٹ ورک کنکشن کو رجسٹر کرنے میں ملوث نہیں ہے، لیکن اس کے لیے ضروری معلومات اپنے پلگ ان کو فراہم کرتا ہے، جو پھر مطلوبہ نیٹ ورک عنصر کو ترتیب دیتا ہے۔ OpenStack نوڈس پر نیوٹران ایجنٹ نیوٹران سرور کے ساتھ رجسٹر ہوتے ہیں۔
نیوٹران سرور دراصل python میں لکھی گئی ایک ایپلی کیشن ہے جو دو حصوں پر مشتمل ہے:
- آرام کی خدمت
- نیوٹران پلگ ان (کور/سروس)
REST سروس کو دوسرے اجزاء سے API کالز وصول کرنے کے لیے ڈیزائن کیا گیا ہے (مثال کے طور پر، کچھ معلومات فراہم کرنے کی درخواست وغیرہ)
پلگ انز پلگ ان سافٹ ویئر کے اجزاء/ماڈیولز ہیں جنہیں API کی درخواستوں کے دوران بلایا جاتا ہے - یعنی کسی سروس کا انتساب ان کے ذریعے ہوتا ہے۔ پلگ ان کو دو اقسام میں تقسیم کیا گیا ہے - سروس اور روٹ۔ ایک اصول کے طور پر، ہارس پلگ ان بنیادی طور پر ایڈریس اسپیس اور VMs کے درمیان L2 کنکشن کے انتظام کے لیے ذمہ دار ہے، اور سروس پلگ ان پہلے سے ہی اضافی فعالیت فراہم کرتے ہیں جیسے VPN یا FW۔
مثال کے طور پر آج دستیاب پلگ ان کی فہرست دیکھی جا سکتی ہے۔
کئی سروس پلگ ان ہو سکتے ہیں، لیکن صرف ایک ہارس پلگ ان ہو سکتا ہے۔
openstack-neutron-ml2 معیاری اوپن اسٹیک روٹ پلگ ان ہے۔ اس پلگ ان میں ایک ماڈیولر فن تعمیر ہے (اپنے پیشرو کے برعکس) اور اس سے منسلک ڈرائیوروں کے ذریعے نیٹ ورک سروس کو ترتیب دیتا ہے۔ ہم تھوڑی دیر بعد خود پلگ ان کو دیکھیں گے، کیونکہ حقیقت میں یہ وہ لچک دیتا ہے جو OpenStack کے نیٹ ورک کے حصے میں ہے۔ روٹ پلگ ان کو تبدیل کیا جا سکتا ہے (مثال کے طور پر، Contrail Networking ایسی تبدیلی کرتی ہے)۔
RPC سروس (rabbitmq-server) — ایک ایسی خدمت جو قطار کا انتظام اور دیگر OpenStack سروسز کے ساتھ تعامل فراہم کرتی ہے، نیز نیٹ ورک سروس ایجنٹس کے درمیان تعامل۔
نیٹ ورک ایجنٹس — ایجنٹس جو ہر نوڈ میں واقع ہوتے ہیں، جس کے ذریعے نیٹ ورک کی خدمات ترتیب دی جاتی ہیں۔
ایجنٹوں کی کئی قسمیں ہیں۔
اہم ایجنٹ ہے L2 ایجنٹ. یہ ایجنٹ ہر ایک ہائپر وائزر پر چلتے ہیں، بشمول کنٹرول نوڈس (زیادہ واضح طور پر، تمام نوڈس پر جو کرایہ داروں کے لیے کوئی بھی سروس فراہم کرتے ہیں) اور ان کا بنیادی کام ورچوئل مشینوں کو ایک عام L2 نیٹ ورک سے جوڑنا ہے، اور جب کوئی واقعہ پیش آتا ہے تو الرٹ بھی پیدا کرتے ہیں ( مثال کے طور پر بندرگاہ کو غیر فعال/ فعال کریں)۔
اگلا، کوئی کم اہم ایجنٹ نہیں ہے L3 ایجنٹ. پہلے سے طے شدہ طور پر، یہ ایجنٹ خصوصی طور پر نیٹ ورک نوڈ پر چلتا ہے (اکثر نیٹ ورک نوڈ کو کنٹرول نوڈ کے ساتھ ملایا جاتا ہے) اور کرایہ داروں کے نیٹ ورکس کے درمیان روٹنگ فراہم کرتا ہے (دونوں اس کے نیٹ ورکس اور دوسرے کرایہ داروں کے نیٹ ورکس کے درمیان، اور بیرونی دنیا کے لیے قابل رسائی ہے، فراہم کرتا ہے۔ NAT، نیز DHCP سروس)۔ تاہم، DVR (تقسیم شدہ راؤٹر) استعمال کرتے وقت، کمپیوٹ نوڈس پر L3 پلگ ان کی ضرورت بھی ظاہر ہوتی ہے۔
L3 ایجنٹ ہر کرایہ دار کو اس کے اپنے الگ تھلگ نیٹ ورکس اور ورچوئل راؤٹرز کی فعالیت فراہم کرنے کے لیے لینکس نام کی جگہوں کا استعمال کرتا ہے جو ٹریفک کو روٹ کرتے ہیں اور لیئر 2 نیٹ ورکس کے لیے گیٹ وے خدمات فراہم کرتے ہیں۔
ڈیٹا بیس - نیٹ ورکس، سب نیٹس، پورٹس، پولز وغیرہ کے شناخت کنندگان کا ڈیٹا بیس۔
درحقیقت، نیوٹران کسی بھی نیٹ ورک کے اداروں کی تخلیق سے API کی درخواستوں کو قبول کرتا ہے، درخواست کی تصدیق کرتا ہے، اور RPC (اگر یہ کسی پلگ ان یا ایجنٹ تک رسائی حاصل کرتا ہے) یا REST API (اگر یہ SDN میں بات چیت کرتا ہے) ایجنٹوں کو منتقل کرتا ہے (پلگ ان کے ذریعے) درخواست کردہ سروس کو منظم کرنے کے لیے ضروری ہدایات۔
اب آئیے ٹیسٹ انسٹالیشن کی طرف آتے ہیں (اسے کیسے لگایا جاتا ہے اور اس میں کیا شامل ہے، ہم بعد میں عملی حصے میں دیکھیں گے) اور دیکھیں گے کہ ہر جزو کہاں واقع ہے:
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$
دراصل، یہ نیوٹران کی پوری ساخت ہے۔ اب یہ ML2 پلگ ان پر کچھ وقت گزارنے کے قابل ہے۔
ماڈیولر پرت 2
جیسا کہ اوپر ذکر کیا گیا ہے، پلگ ان ایک معیاری OpenStack روٹ پلگ ان ہے اور اس کا ایک ماڈیولر فن تعمیر ہے۔
ML2 پلگ ان کے پیشرو میں یک سنگی ڈھانچہ تھا، جس کی اجازت نہیں تھی، مثال کے طور پر، ایک تنصیب میں کئی ٹیکنالوجیز کا مرکب استعمال کرنا۔ مثال کے طور پر، آپ ایک ہی وقت میں openvswitch اور linuxbridge دونوں استعمال نہیں کر سکتے ہیں - یا تو پہلا یا دوسرا۔ اس وجہ سے، اس کے فن تعمیر کے ساتھ ML2 پلگ ان بنایا گیا تھا۔
ML2 کے دو اجزاء ہیں - دو قسم کے ڈرائیور: ٹائپ ڈرائیور اور میکانزم ڈرائیور۔
ڈرائیوروں کو ٹائپ کریں۔ ان ٹیکنالوجیز کا تعین کریں جو نیٹ ورک کنکشن کو منظم کرنے کے لیے استعمال ہوں گی، مثال کے طور پر VxLAN, VLAN, GRE۔ ایک ہی وقت میں، ڈرائیور مختلف ٹیکنالوجی کے استعمال کی اجازت دیتا ہے. معیاری ٹیکنالوجی اوورلے نیٹ ورکس اور vlan بیرونی نیٹ ورکس کے لیے VxLAN encapsulation ہے۔
قسم کے ڈرائیوروں میں مندرجہ ذیل نیٹ ورک کی اقسام شامل ہیں:
فلیٹ - ٹیگنگ کے بغیر نیٹ ورک
وی ایل این۔ - ٹیگ شدہ نیٹ ورک
مقامی - آل ان ون تنصیبات کے لیے ایک خاص قسم کا نیٹ ورک (ایسی تنصیبات یا تو ڈویلپرز یا تربیت کے لیے درکار ہیں)
GRE - GRE سرنگوں کا استعمال کرتے ہوئے نیٹ ورک کو اوورلے کریں۔
VxLAN - VxLAN سرنگوں کا استعمال کرتے ہوئے نیٹ ورک کو اوورلے کریں۔
میکانزم ڈرائیورز ٹولز کی وضاحت کریں جو ٹائپ ڈرائیور میں بیان کردہ ٹیکنالوجیز کی تنظیم کو یقینی بناتے ہیں - مثال کے طور پر، openvswitch، sr-iov، opendaylight، OVN، وغیرہ۔
اس ڈرائیور کے نفاذ پر منحصر ہے، یا تو نیوٹران کے ذریعے کنٹرول شدہ ایجنٹ استعمال کیے جائیں گے، یا کسی بیرونی SDN کنٹرولر سے کنکشن استعمال کیے جائیں گے، جو L2 نیٹ ورکس کو منظم کرنے، روٹنگ وغیرہ سے متعلق تمام مسائل کا خیال رکھتا ہے۔
مثال: اگر ہم ML2 کو OVS کے ساتھ استعمال کرتے ہیں، تو ہر کمپیوٹنگ نوڈ پر ایک L2 ایجنٹ انسٹال ہوتا ہے جو OVS کا انتظام کرتا ہے۔ تاہم، اگر ہم، مثال کے طور پر، OVN یا OpenDayLight استعمال کرتے ہیں، تو OVS کا کنٹرول ان کے دائرہ اختیار میں آتا ہے - نیوٹران، روٹ پلگ ان کے ذریعے، کنٹرولر کو کمانڈ دیتا ہے، اور یہ پہلے سے وہی کرتا ہے جو اسے بتایا گیا تھا۔
آئیے اوپن vSwitch پر برش کریں۔
اس وقت، OpenStack کے اہم اجزاء میں سے ایک Open vSwitch ہے۔
جب OpenStack کو بغیر کسی اضافی وینڈر SDN جیسے Juniper Contrail یا Nokia Nuage کے انسٹال کرتے ہیں، OVS کلاؤڈ نیٹ ورک کا بنیادی نیٹ ورک جزو ہے اور iptables، conntrack، namespaces کے ساتھ مل کر، آپ کو مکمل کثیر کرایہ داری اوورلے نیٹ ورکس کو منظم کرنے کی اجازت دیتا ہے۔ قدرتی طور پر، اس جزو کو تبدیل کیا جا سکتا ہے، مثال کے طور پر، تیسرے فریق کے ملکیتی (وینڈر) SDN حل استعمال کرتے وقت۔
OVS ایک اوپن سورس سافٹ ویئر سوئچ ہے جو ورچوئلائزڈ ماحول میں بطور ورچوئل ٹریفک فارورڈر استعمال کرنے کے لیے ڈیزائن کیا گیا ہے۔
اس وقت، OVS میں بہت اچھی فعالیت ہے، جس میں ٹیکنالوجیز جیسے QoS، LACP، VLAN، VxLAN، GENEVE، OpenFlow، DPDK، وغیرہ شامل ہیں۔
نوٹ: OVS کو ابتدائی طور پر بہت زیادہ بھری ہوئی ٹیلی کام فنکشنز کے لیے ایک نرم سوئچ کے طور پر تصور نہیں کیا گیا تھا اور اسے کم بینڈوتھ کی ڈیمانڈ کرنے والے IT فنکشنز جیسے WEB سرور یا میل سرور کے لیے زیادہ ڈیزائن کیا گیا تھا۔ تاہم، OVS کو مزید تیار کیا جا رہا ہے اور OVS کے موجودہ نفاذ نے اس کی کارکردگی اور صلاحیتوں کو بہت بہتر کیا ہے، جو اسے ٹیلی کام آپریٹرز کے لیے انتہائی بھری ہوئی فنکشنز کے ساتھ استعمال کرنے کی اجازت دیتا ہے، مثال کے طور پر، DPDK ایکسلریشن کے لیے تعاون کے ساتھ OVS کا نفاذ ہے۔
OVS کے تین اہم اجزاء ہیں جن سے آپ کو آگاہ ہونا ضروری ہے:
- دانا ماڈیول - دانا کی جگہ میں واقع ایک جزو جو کنٹرول عنصر سے موصول ہونے والے قواعد کی بنیاد پر ٹریفک پر کارروائی کرتا ہے۔
- وی سوئچ ڈیمون (ovs-vswitchd) صارف کی جگہ پر شروع کیا جانے والا ایک عمل ہے جو کرنل ماڈیول کی پروگرامنگ کے لیے ذمہ دار ہے - یعنی یہ سوئچ کے آپریشن کی منطق کو براہ راست ظاہر کرتا ہے۔
- ڈیٹا بیس سرور - ایک مقامی ڈیٹا بیس جو OVS چلانے والے ہر میزبان پر واقع ہے، جس میں کنفیگریشن محفوظ ہے۔ SDN کنٹرولرز OVSDB پروٹوکول کا استعمال کرتے ہوئے اس ماڈیول کے ذریعے بات چیت کر سکتے ہیں۔
یہ سب تشخیصی اور انتظامی افادیت کے ایک سیٹ کے ساتھ ہے، جیسے ovs-vsctl، ovs-appctl، ovs-ofctl، وغیرہ۔
فی الحال، اوپن اسٹیک بڑے پیمانے پر ٹیلی کام آپریٹرز کے ذریعے نیٹ ورک کے فنکشنز کو اس میں منتقل کرنے کے لیے استعمال کیا جاتا ہے، جیسے ای پی سی، ایس بی سی، ایچ ایل آر، وغیرہ۔ کچھ فنکشنز OVS کے ساتھ مسائل کے بغیر رہ سکتے ہیں جیسا کہ ہے، لیکن مثال کے طور پر، ای پی سی سبسکرائبر ٹریفک کو پروسیس کرتا ہے - پھر یہ گزر جاتا ہے۔ ٹریفک کی ایک بڑی مقدار (اب ٹریفک کا حجم کئی سو گیگا بٹ فی سیکنڈ تک پہنچ جاتا ہے)۔ قدرتی طور پر، کرنل اسپیس کے ذریعے اس طرح کے ٹریفک کو چلانا (چونکہ فارورڈر پہلے سے طے شدہ طور پر وہاں موجود ہے) بہترین خیال نہیں ہے۔ لہذا، OVS کو اکثر یوزر اسپیس میں ڈی پی ڈی کے ایکسلریشن ٹکنالوجی کا استعمال کرتے ہوئے مکمل طور پر تعینات کیا جاتا ہے تاکہ کرنل کو نظرانداز کرتے ہوئے NIC سے یوزر اسپیس تک ٹریفک کو آگے بڑھایا جاسکے۔
نوٹ: ٹیلی کام فنکشنز کے لیے تعینات کلاؤڈ کے لیے، یہ ممکن ہے کہ ایک کمپیوٹ نوڈ سے OVS کو بائی پاس کرتے ہوئے براہ راست سوئچنگ آلات تک ٹریفک کو آؤٹ پٹ کیا جائے۔ اس مقصد کے لیے SR-IOV اور پاس تھرو میکانزم استعمال کیے جاتے ہیں۔
یہ ایک حقیقی ترتیب پر کیسے کام کرتا ہے؟
ٹھیک ہے، اب عملی حصے کی طرف چلتے ہیں اور دیکھتے ہیں کہ یہ سب عملی طور پر کیسے کام کرتا ہے۔
سب سے پہلے، آئیے ایک سادہ Openstack کی تنصیب کو متعین کرتے ہیں۔ چونکہ میرے پاس تجربات کے لیے سرورز کا سیٹ نہیں ہے، اس لیے ہم پروٹوٹائپ کو ورچوئل مشینوں سے ایک فزیکل سرور پر جمع کریں گے۔ ہاں، قدرتی طور پر، ایسا حل تجارتی مقاصد کے لیے موزوں نہیں ہے، لیکن اوپن اسٹیک میں نیٹ ورک کیسے کام کرتا ہے، اس کی مثال دیکھنے کے لیے آنکھوں کے لیے ایسی تنصیب کافی ہے۔ مزید یہ کہ، اس طرح کی تنصیب تربیتی مقاصد کے لیے اور بھی زیادہ دلچسپ ہے - کیونکہ آپ ٹریفک وغیرہ کو پکڑ سکتے ہیں۔
چونکہ ہمیں صرف بنیادی حصہ دیکھنے کی ضرورت ہے، اس لیے ہم کئی نیٹ ورک استعمال نہیں کر سکتے لیکن صرف دو نیٹ ورکس کا استعمال کرتے ہوئے ہر چیز کو بڑھا سکتے ہیں، اور اس لے آؤٹ میں دوسرا نیٹ ورک انڈر کلاؤڈ اور ڈی این ایس سرور تک رسائی کے لیے خصوصی طور پر استعمال کیا جائے گا۔ ہم فی الحال بیرونی نیٹ ورکس پر بات نہیں کریں گے - یہ ایک الگ بڑے مضمون کا موضوع ہے۔
تو، ترتیب میں شروع کرتے ہیں. سب سے پہلے، ایک چھوٹا سا نظریہ. ہم TripleO (اوپن اسٹیک پر اوپن اسٹیک) کا استعمال کرتے ہوئے اوپن اسٹیک انسٹال کریں گے۔ ٹرپل او کا خلاصہ یہ ہے کہ ہم اوپن اسٹیک آل ان ون (یعنی ایک نوڈ پر) انسٹال کرتے ہیں، جسے انڈر کلاؤڈ کہتے ہیں، اور پھر آپریشن کے لیے اوپن اسٹیک کو انسٹال کرنے کے لیے تعینات اوپن اسٹیک کی صلاحیتوں کا استعمال کرتے ہیں، جسے اوور کلاؤڈ کہتے ہیں۔ انڈر کلاؤڈ فزیکل سرورز (ننگی دھات) کو منظم کرنے کے لیے اپنی فطری صلاحیت کا استعمال کرے گا - Ironic پروجیکٹ - ہائپر وائزرز کی فراہمی کے لیے جو کمپیوٹ، کنٹرول، اسٹوریج نوڈس کے کردار کو انجام دیں گے۔ یعنی، ہم Openstack کو تعینات کرنے کے لیے کسی بھی فریق ثالث کا ٹول استعمال نہیں کرتے ہیں - ہم Openstack کا استعمال کرتے ہوئے Openstack کو تعینات کرتے ہیں۔ جیسے جیسے انسٹالیشن آگے بڑھے گی یہ زیادہ واضح ہو جائے گا، اس لیے ہم وہاں نہیں رکیں گے اور آگے بڑھیں گے۔
نوٹ: اس مضمون میں، سادگی کی خاطر، میں نے اندرونی اوپن اسٹیک نیٹ ورکس کے لیے نیٹ ورک آئسولیشن کا استعمال نہیں کیا، لیکن سب کچھ صرف ایک نیٹ ورک کا استعمال کرتے ہوئے لگایا گیا ہے۔ تاہم، نیٹ ورک آئسولیشن کی موجودگی یا غیر موجودگی حل کی بنیادی فعالیت کو متاثر نہیں کرتی ہے - سب کچھ بالکل ویسا ہی کام کرے گا جیسا کہ تنہائی کا استعمال کرتے وقت، لیکن ٹریفک اسی نیٹ ورک پر رواں دواں رہے گی۔ تجارتی تنصیب کے لیے، قدرتی طور پر مختلف vlans اور انٹرفیس کا استعمال کرتے ہوئے تنہائی کا استعمال کرنا ضروری ہے۔ مثال کے طور پر، سیف سٹوریج مینجمنٹ ٹریفک اور خود ڈیٹا ٹریفک (ڈسک تک مشین تک رسائی وغیرہ) جب الگ تھلگ ہو تو مختلف ذیلی نیٹس (اسٹوریج مینجمنٹ اور اسٹوریج) کا استعمال کرتے ہیں اور یہ آپ کو اس ٹریفک کو تقسیم کرکے حل کو زیادہ غلطی برداشت کرنے کی اجازت دیتا ہے، مثال کے طور پر مختلف بندرگاہوں پر، یا مختلف ٹریفک کے لیے مختلف QoS پروفائلز کا استعمال کرنا تاکہ ڈیٹا ٹریفک سگنلنگ ٹریفک کو نچوڑ نہ سکے۔ ہمارے معاملے میں، وہ ایک ہی نیٹ ورک پر جائیں گے اور حقیقت میں یہ ہمیں کسی بھی طرح سے محدود نہیں کرتا ہے۔
نوٹ: چونکہ ہم ورچوئل مشینوں پر مبنی ورچوئل ماحول میں ورچوئل مشینیں چلانے جا رہے ہیں، ہمیں پہلے نیسٹڈ ورچوئلائزیشن کو فعال کرنے کی ضرورت ہے۔
آپ چیک کر سکتے ہیں کہ نیسٹڈ ورچوئلائزیشن فعال ہے یا نہیں اس طرح:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#اگر آپ کو حرف N نظر آتا ہے، تو ہم نیٹ ورک پر ملنے والی کسی بھی گائیڈ کے مطابق نیسٹڈ ورچوئلائزیشن کے لیے سپورٹ کو فعال کرتے ہیں، مثال کے طور پر .
ہمیں ورچوئل مشینوں سے درج ذیل سرکٹ کو جمع کرنے کی ضرورت ہے:
میرے معاملے میں، ان ورچوئل مشینوں کو جوڑنے کے لیے جو مستقبل کی انسٹالیشن کا حصہ ہیں (اور مجھے ان میں سے 7 ملیں، لیکن اگر آپ کے پاس بہت زیادہ وسائل نہیں ہیں تو آپ 4 کے ذریعے حاصل کر سکتے ہیں)، میں نے OpenvSwitch کا استعمال کیا۔ میں نے ایک ovs برج بنایا اور ورچوئل مشینوں کو اس سے پورٹ گروپس کے ذریعے منسلک کیا۔ ایسا کرنے کے لیے، میں نے اس طرح ایک xML فائل بنائی:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
<network>
<name>ovs-network-1</name>
<uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
<forward mode='bridge'/>
<bridge name='ovs-br1'/>
<virtualport type='openvswitch'/>
<portgroup name='trunk-1'>
<vlan trunk='yes'>
<tag id='100'/>
<tag id='101'/>
<tag id='102'/>
</vlan>
</portgroup>
<portgroup name='access-100'>
<vlan>
<tag id='100'/>
</vlan>
</portgroup>
<portgroup name='access-101'>
<vlan>
<tag id='101'/>
</vlan>
</portgroup>
</network>یہاں تین پورٹ گروپس کا اعلان کیا گیا ہے - دو رسائی اور ایک ٹرنک (بعد میں DNS سرور کے لیے ضروری تھا، لیکن آپ اس کے بغیر کر سکتے ہیں، یا اسے میزبان مشین پر انسٹال کر سکتے ہیں - جو بھی آپ کے لیے زیادہ آسان ہو)۔ اس کے بعد، اس ٹیمپلیٹ کو استعمال کرتے ہوئے، ہم virsh net-define کے ذریعے اپنا اعلان کرتے ہیں:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 اب ہم ہائپر وائزر پورٹ کنفیگریشنز میں ترمیم کرتے ہیں:
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# نوٹ: اس منظر نامے میں، پورٹ ovs-br1 پر ایڈریس قابل رسائی نہیں ہوگا کیونکہ اس میں vlan ٹیگ نہیں ہے۔ اسے ٹھیک کرنے کے لیے، آپ کو sudo ovs-vsctl set port ovs-br1 tag=100 کمانڈ جاری کرنے کی ضرورت ہے۔ تاہم، دوبارہ شروع کرنے کے بعد، یہ ٹیگ غائب ہو جائے گا (اگر کوئی جانتا ہے کہ اسے اپنی جگہ پر کیسے رکھنا ہے، تو میں بہت مشکور ہوں گا)۔ لیکن یہ اتنا اہم نہیں ہے، کیونکہ ہمیں صرف انسٹالیشن کے دوران اس ایڈریس کی ضرورت ہوگی اور جب Openstack مکمل طور پر تعینات ہو جائے گا تو اس کی ضرورت نہیں ہوگی۔
اگلا، ہم ایک انڈر کلاؤڈ مشین بناتے ہیں:
virt-install -n undercloud --description "undercloud" --os-type=Linux --os-variant=centos7.0 --ram=8192 --vcpus=8 --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0انسٹالیشن کے دوران، آپ تمام ضروری پیرامیٹرز سیٹ کرتے ہیں، جیسے کہ مشین کا نام، پاس ورڈ، صارفین، این ٹی پی سرورز وغیرہ، آپ فوری طور پر پورٹس کو کنفیگر کر سکتے ہیں، لیکن میرے لیے ذاتی طور پر، انسٹالیشن کے بعد، مشین کے ذریعے لاگ ان کرنا آسان ہے۔ کنسول اور ضروری فائلوں کو درست کریں۔ اگر آپ کے پاس پہلے سے ہی تیار شدہ تصویر ہے، تو آپ اسے استعمال کر سکتے ہیں، یا میں نے کیا کیا ہے - کم سے کم Centos 7 امیج ڈاؤن لوڈ کریں اور اسے VM انسٹال کرنے کے لیے استعمال کریں۔
کامیاب انسٹالیشن کے بعد، آپ کے پاس ایک ورچوئل مشین ہونی چاہیے جس پر آپ انڈر کلاؤڈ انسٹال کر سکتے ہیں۔
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningسب سے پہلے، انسٹالیشن کے عمل کے لیے ضروری ٹولز انسٹال کریں:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
انڈر کلاؤڈ انسٹالیشن
ہم ایک اسٹیک صارف بناتے ہیں، پاس ورڈ مرتب کرتے ہیں، اسے sudoer میں شامل کرتے ہیں اور اسے پاس ورڈ درج کیے بغیر sudo کے ذریعے روٹ کمانڈز پر عمل درآمد کرنے کی صلاحیت دیتے ہیں۔
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackاب ہم میزبان فائل میں مکمل انڈر کلاؤڈ نام بتاتے ہیں:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6اگلا، ہم ریپوزٹریز شامل کرتے ہیں اور سافٹ ویئر انسٹال کرتے ہیں جس کی ہمیں ضرورت ہے:
sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansibleنوٹ: اگر آپ ceph کو انسٹال کرنے کا ارادہ نہیں رکھتے ہیں، تو آپ کو ceph سے متعلق کمانڈز داخل کرنے کی ضرورت نہیں ہے۔ میں نے کوئینز کی ریلیز کا استعمال کیا، لیکن آپ اپنی پسند کا کوئی دوسرا استعمال کر سکتے ہیں۔
اگلا، انڈر کلاؤڈ کنفیگریشن فائل کو صارف کی ہوم ڈائریکٹری اسٹیک پر کاپی کریں:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confاب ہمیں اس فائل کو درست کرنے کی ضرورت ہے، اسے اپنی انسٹالیشن میں ایڈجسٹ کرنا ہے۔
آپ کو فائل کے آغاز میں ان لائنوں کو شامل کرنے کی ضرورت ہے:
vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10تو، آئیے ترتیبات کے ذریعے چلتے ہیں:
undercloud_hostname - انڈر کلاؤڈ سرور کا پورا نام، DNS سرور کے اندراج سے مماثل ہونا چاہیے۔
local_ip - نیٹ ورک کی فراہمی کی طرف مقامی انڈر کلاؤڈ ایڈریس
نیٹ ورک_گیٹ وے - وہی مقامی پتہ، جو اوور کلاؤڈ نوڈس کی تنصیب کے دوران بیرونی دنیا تک رسائی کے لیے گیٹ وے کا کام کرے گا، مقامی آئی پی کے ساتھ بھی موافق ہے۔
undercloud_public_host - بیرونی API ایڈریس، پروویژننگ نیٹ ورک سے کوئی بھی مفت ایڈریس تفویض کیا جاتا ہے۔
undercloud_admin_host اندرونی API ایڈریس، پروویژننگ نیٹ ورک سے کوئی بھی مفت ایڈریس تفویض کیا جاتا ہے۔
undercloud_nameservers - DNS سرور
generate_service_certificate - موجودہ مثال میں یہ لائن بہت اہم ہے، کیونکہ اگر آپ اسے غلط پر سیٹ نہیں کرتے ہیں تو آپ کو انسٹالیشن کے دوران ایک خرابی موصول ہوگی، مسئلہ Red Hat بگ ٹریکر پر بیان کیا گیا ہے۔
local_interface نیٹ ورک کی فراہمی میں انٹرفیس۔ اس انٹرفیس کو انڈر کلاؤڈ تعیناتی کے دوران دوبارہ ترتیب دیا جائے گا، لہذا آپ کو انڈر کلاؤڈ پر دو انٹرفیسز رکھنے کی ضرورت ہے - ایک اس تک رسائی کے لیے، دوسرا پروویژننگ کے لیے۔
local_mtu - ایم ٹی یو۔ چونکہ ہمارے پاس ایک ٹیسٹ لیبارٹری ہے اور میرے پاس OVS سوئچ پورٹس پر 1500 کا MTU ہے، اس لیے اسے 1450 پر سیٹ کرنا ضروری ہے تاکہ VxLAN میں موجود پیکٹ وہاں سے گزر سکیں۔
network_cidr - فراہمی کا نیٹ ورک
بہانا - بیرونی نیٹ ورک تک رسائی کے لیے NAT کا استعمال
masquerade_network - نیٹ ورک جس کو NATE کیا جائے گا۔
dhcp_start - ایڈریس پول کا ابتدائی پتہ جہاں سے اوور کلاؤڈ تعیناتی کے دوران پتے نوڈس کو تفویض کیے جائیں گے۔
dhcp_end - ایڈریس پول کا حتمی پتہ جہاں سے اوور کلاؤڈ تعیناتی کے دوران پتے نوڈس کو تفویض کیے جائیں گے۔
معائنہ_iprange - خود شناسی کے لیے ضروری پتوں کا ایک تالاب (مذکورہ بالا تالاب کے ساتھ اوورلیپ نہیں ہونا چاہیے)
شیڈولر_میکس_کوششیں - اوور کلاؤڈ کو انسٹال کرنے کی کوششوں کی زیادہ سے زیادہ تعداد (نوڈس کی تعداد سے زیادہ یا اس کے برابر ہونا چاہیے)
فائل کے بیان ہونے کے بعد، آپ انڈر کلاؤڈ کو تعینات کرنے کا حکم دے سکتے ہیں:
openstack undercloud install
آپ کے آئرن پر منحصر طریقہ کار 10 سے 30 منٹ تک لیتا ہے۔ آخر کار آپ کو اس طرح آؤٹ پٹ دیکھنا چاہئے:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Undercloud install complete.
The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.
There is also a stackrc file at /home/stack/stackrc.
These files are needed to interact with the OpenStack services, and should be
secured.
#############################################################################یہ آؤٹ پٹ کہتا ہے کہ آپ نے کامیابی کے ساتھ انڈر کلاؤڈ انسٹال کر لیا ہے اور اب آپ انڈر کلاؤڈ کی حیثیت کو چیک کر سکتے ہیں اور اوور کلاؤڈ کو انسٹال کرنے کے لیے آگے بڑھ سکتے ہیں۔
اگر آپ ifconfig آؤٹ پٹ کو دیکھیں گے تو آپ دیکھیں گے کہ ایک نیا پل انٹرفیس نمودار ہوا ہے۔
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0اوور کلاؤڈ تعیناتی اب اس انٹرفیس کے ذریعے کی جائے گی۔
نیچے دیے گئے آؤٹ پٹ سے آپ دیکھ سکتے ہیں کہ ہمارے پاس تمام خدمات ایک نوڈ پر ہیں:
(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name | Service | Zone |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute | nova |
+--------------------------+-----------+----------+ذیل میں انڈر کلاؤڈ نیٹ ورک کے حصے کی ترتیب ہے:
(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json
{
"network_config": [
{
"addresses": [
{
"ip_netmask": "192.168.255.1/24"
}
],
"members": [
{
"dns_servers": [
"192.168.255.253"
],
"mtu": 1450,
"name": "eth0",
"primary": "true",
"type": "interface"
}
],
"mtu": 1450,
"name": "br-ctlplane",
"ovs_extra": [
"br-set-external-id br-ctlplane bridge-id br-ctlplane"
],
"routes": [],
"type": "ovs_bridge"
}
]
}
(undercloud) [stack@undercloud ~]$اوور کلاؤڈ انسٹالیشن
اس وقت ہمارے پاس صرف انڈر کلاؤڈ ہے، اور ہمارے پاس اتنے نوڈس نہیں ہیں جن سے اوور کلاؤڈ کو اکٹھا کیا جائے۔ لہذا، سب سے پہلے، آئیے ان ورچوئل مشینوں کو تعینات کریں جن کی ہمیں ضرورت ہے۔ تعیناتی کے دوران، انڈر کلاؤڈ خود اوور کلاؤڈ مشین پر OS اور ضروری سافٹ ویئر انسٹال کرے گا - یعنی ہمیں مشین کو مکمل طور پر تعینات کرنے کی ضرورت نہیں ہے، بلکہ اس کے لیے صرف ایک ڈسک (یا ڈسک) بنائیں گے اور اس کے پیرامیٹرز کا تعین کریں گے - یعنی درحقیقت، ہمیں ایک ننگا سرور ملتا ہے جس پر OS انسٹال نہیں ہوتا ہے۔
آئیے اپنی ورچوئل مشینوں کی ڈسکوں کے ساتھ فولڈر میں جائیں اور مطلوبہ سائز کی ڈسکیں بنائیں:
cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160Gچونکہ ہم روٹ کے طور پر کام کر رہے ہیں، ہمیں ان ڈسکوں کے مالک کو تبدیل کرنے کی ضرورت ہے تاکہ حقوق کے ساتھ کوئی مسئلہ نہ ہو:
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]#
[root@hp-gen9 images]#
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# نوٹ: اگر آپ اس کا مطالعہ کرنے کے لیے سیف کو انسٹال کرنے کا ارادہ نہیں رکھتے ہیں، تو کمانڈز کم از کم دو ڈسکوں کے ساتھ کم از کم 3 نوڈس نہیں بناتے ہیں، لیکن ٹیمپلیٹ میں اس بات کی نشاندہی ہوتی ہے کہ ورچوئل ڈسکیں vda, vdb وغیرہ استعمال کی جائیں گی۔
بہت اچھا، اب ہمیں ان تمام مشینوں کی وضاحت کرنے کی ضرورت ہے:
virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > /tmp/control-1.xml
virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-1.xml
virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-2.xml
virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-1.xml
virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-2.xml آخر میں ایک کمانڈ ہے -print-xml > /tmp/storage-1.xml، جو /tmp/ فولڈر میں ہر مشین کی تفصیل کے ساتھ ایک ایکس ایم ایل فائل بناتی ہے؛ اگر آپ اسے شامل نہیں کرتے ہیں، تو آپ نہیں ہوں گے۔ ورچوئل مشینوں کی شناخت کرنے کے قابل۔
اب ہمیں ان تمام مشینوں کو ورش میں بیان کرنے کی ضرورت ہے:
virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#اب ایک چھوٹی سی بات - ٹرپل او انسٹالیشن اور خود شناسی کے دوران سرورز کو منظم کرنے کے لیے IPMI کا استعمال کرتا ہے۔
انٹراسپیکشن ہارڈ ویئر کا معائنہ کرنے کا عمل ہے تاکہ نوڈس کی مزید فراہمی کے لیے ضروری پیرامیٹرز حاصل کیے جا سکیں۔ خود شناسی ستم ظریفی کا استعمال کرتے ہوئے کی جاتی ہے، ایک خدمت جو ننگی دھاتی سرورز کے ساتھ کام کرنے کے لیے بنائی گئی ہے۔
لیکن یہاں مسئلہ ہے - جب کہ ہارڈویئر IPMI سرورز کے پاس ایک الگ پورٹ ہے (یا مشترکہ بندرگاہ ہے، لیکن یہ اہم نہیں ہے)، پھر ورچوئل مشینوں میں ایسی بندرگاہیں نہیں ہوتیں۔ یہاں vbmc نامی ایک بیساکھی ہماری مدد کے لیے آتی ہے - ایک ایسی افادیت جو آپ کو IPMI پورٹ کی تقلید کرنے کی اجازت دیتی ہے۔ یہ نزاکت خاص طور پر ان لوگوں کے لیے توجہ دینے کے قابل ہے جو ESXI ہائپر وائزر پر ایسی لیبارٹری قائم کرنا چاہتے ہیں - سچ پوچھیں تو، مجھے نہیں معلوم کہ اس میں vbmc کا کوئی اینالاگ ہے یا نہیں، اس لیے ہر چیز کو تعینات کرنے سے پہلے اس مسئلے کے بارے میں سوچنا ضروری ہے۔ .
vbmc انسٹال کریں:
yum install yum install python2-virtualbmcاگر آپ کا OS پیکیج نہیں ڈھونڈ سکتا ہے، تو ذخیرہ شامل کریں:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmاب ہم افادیت قائم کرتے ہیں۔ یہاں ہر چیز بے عزتی کی حد تک ہے۔ اب یہ منطقی ہے کہ vbmc فہرست میں کوئی سرور نہیں ہیں۔
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# ان کے ظاہر ہونے کے لیے، ان کا دستی طور پر اس طرح اعلان کیا جانا چاہیے:
[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1 | down | :: | 7004 |
| compute-2 | down | :: | 7005 |
| control-1 | down | :: | 7001 |
| storage-1 | down | :: | 7002 |
| storage-2 | down | :: | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#میرے خیال میں کمانڈ کا نحو بغیر کسی وضاحت کے واضح ہے۔ تاہم، فی الحال ہمارے تمام سیشنز نیچے کی حالت میں ہیں۔ ان کے UP کی حیثیت میں جانے کے لیے، آپ کو ان کو فعال کرنے کی ضرورت ہے:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status | Address | Port |
+-------------+---------+---------+------+
| compute-1 | running | :: | 7004 |
| compute-2 | running | :: | 7005 |
| control-1 | running | :: | 7001 |
| storage-1 | running | :: | 7002 |
| storage-2 | running | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#اور فائنل ٹچ - آپ کو فائر وال کے قواعد کو درست کرنے کی ضرورت ہے (یا اسے مکمل طور پر غیر فعال کریں):
firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload
اب انڈر کلاؤڈ پر جائیں اور چیک کریں کہ سب کچھ کام کر رہا ہے۔ میزبان مشین کا پتہ 192.168.255.200 ہے، انڈر کلاؤڈ پر ہم نے تعیناتی کی تیاری کے دوران ضروری ipmitool پیکیج شامل کیا:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
65 control-1 runningجیسا کہ آپ دیکھ سکتے ہیں، ہم نے vbmc کے ذریعے کنٹرول نوڈ کو کامیابی کے ساتھ لانچ کیا ہے۔ اب آئیے اسے آف کریں اور آگے بڑھیں:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#اگلا مرحلہ ان نوڈس کا خود معائنہ ہے جس پر اوور کلاؤڈ انسٹال ہوگا۔ ایسا کرنے کے لیے، ہمیں اپنے نوڈس کی تفصیل کے ساتھ ایک json فائل تیار کرنی ہوگی۔ براہ کرم نوٹ کریں کہ، ننگے سرورز پر انسٹالیشن کے برعکس، فائل اس پورٹ کی نشاندہی کرتی ہے جس پر ہر مشین کے لیے vbmc چل رہا ہے۔
[root@hp-gen9 ~]# virsh domiflist --domain control-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:20:a2:2f
- network ovs-network-1 virtio 52:54:00:3f:87:9f
[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:98:e9:d6
[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:6a:ea:be
[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:79:0b:cb
[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:a7:fe:27نوٹ: کنٹرول نوڈ کے دو انٹرفیس ہیں، لیکن اس معاملے میں یہ اہم نہیں ہے، اس انسٹالیشن میں ہمارے لیے ایک ہی کافی ہوگا۔
اب ہم json فائل تیار کرتے ہیں۔ ہمیں بندرگاہ کے پوست کے پتے کی نشاندہی کرنے کی ضرورت ہے جس کے ذریعے پروویژننگ کی جائے گی، نوڈس کے پیرامیٹرز، ان کے نام بتائیں اور ipmi تک جانے کا طریقہ بتائیں:
{
"nodes":[
{
"mac":[
"52:54:00:20:a2:2f"
],
"cpu":"8",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"control-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7001"
},
{
"mac":[
"52:54:00:79:0b:cb"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7002"
},
{
"mac":[
"52:54:00:a7:fe:27"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7003"
},
{
"mac":[
"52:54:00:98:e9:d6"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7004"
},
{
"mac":[
"52:54:00:6a:ea:be"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7005"
}
]
}اب ہمیں ستم ظریفی کے لیے تصاویر تیار کرنے کی ضرورت ہے۔ ایسا کرنے کے لیے، انہیں wget کے ذریعے ڈاؤن لوڈ کریں اور انسٹال کریں:
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack 916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack 15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack 53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$انڈر کلاؤڈ پر تصاویر اپ لوڈ کرنا:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$چیک کر رہا ہے کہ تمام تصاویر لوڈ ہو گئی ہیں۔
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Name | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$ایک اور چیز - آپ کو DNS سرور شامل کرنے کی ضرورت ہے:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$اب ہم خود شناسی کا حکم دے سکتے ہیں:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$جیسا کہ آپ آؤٹ پٹ سے دیکھ سکتے ہیں، ہر چیز بغیر کسی غلطی کے مکمل ہوئی۔ آئیے چیک کریں کہ تمام نوڈس دستیاب حالت میں ہیں:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | power off | available | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | power off | available | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | power off | available | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | power off | available | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | power off | available | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ اگر نوڈس ایک مختلف حالت میں ہیں، عام طور پر قابل انتظام، پھر کچھ غلط ہو گیا اور آپ کو لاگ کو دیکھنے کی ضرورت ہے اور یہ معلوم کرنا ہوگا کہ ایسا کیوں ہوا۔ ذہن میں رکھیں کہ اس منظر نامے میں ہم ورچوئلائزیشن کا استعمال کر رہے ہیں اور ورچوئل مشینوں یا vbmc کے استعمال سے وابستہ کیڑے ہو سکتے ہیں۔
اگلا، ہمیں یہ بتانے کی ضرورت ہے کہ کون سا نوڈ کون سا فنکشن انجام دے گا - یعنی اس پروفائل کی نشاندہی کریں جس کے ساتھ نوڈ تعینات کرے گا:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | None | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | None | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | None | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | None | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | None | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 | 40 | 0 | 1 | True |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal | 4096 | 40 | 0 | 1 | True |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control | 4096 | 40 | 0 | 1 | True |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 | 40 | 0 | 1 | True |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute | 4096 | 40 | 0 | 1 | True |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage | 4096 | 40 | 0 | 1 | True |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$ہر نوڈ کے لیے پروفائل کی وضاحت کریں:
openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167آئیے چیک کریں کہ ہم نے سب کچھ صحیح طریقے سے کیا:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | control | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | ceph-storage | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | ceph-storage | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | compute | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | compute | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$اگر سب کچھ درست ہے تو، ہم اوور کلاؤڈ کو تعینات کرنے کا حکم دیتے ہیں:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemuایک حقیقی تنصیب میں، اپنی مرضی کے مطابق سانچوں کو قدرتی طور پر استعمال کیا جائے گا، ہمارے معاملے میں یہ عمل کو بہت پیچیدہ بنا دے گا، کیونکہ ٹیمپلیٹ میں ہر ترمیم کی وضاحت کرنی ہوگی۔ جیسا کہ پہلے لکھا گیا تھا، یہاں تک کہ ایک سادہ تنصیب ہمارے لیے یہ دیکھنے کے لیے کافی ہوگی کہ یہ کیسے کام کرتا ہے۔
نوٹ: اس معاملے میں --libvirt-type qemu متغیر ضروری ہے، کیونکہ ہم نیسٹڈ ورچوئلائزیشن استعمال کریں گے۔ بصورت دیگر، آپ ورچوئل مشینیں نہیں چلا سکیں گے۔
اب آپ کے پاس تقریباً ایک گھنٹہ ہے، یا شاید اس سے زیادہ (ہارڈ ویئر کی صلاحیتوں پر منحصر ہے) اور آپ صرف امید کر سکتے ہیں کہ اس وقت کے بعد آپ کو درج ذیل پیغام نظر آئے گا:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stack CREATE completed successfully
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$اب آپ کے پاس اوپن اسٹیک کا تقریباً مکمل ورژن ہے، جس پر آپ مطالعہ، تجربہ، وغیرہ کر سکتے ہیں۔
آئیے چیک کریں کہ سب کچھ ٹھیک سے کام کر رہا ہے۔ صارف کی ہوم ڈائرکٹری اسٹیک میں دو فائلیں ہیں - ایک اسٹیک آر سی (انڈر کلاؤڈ کے انتظام کے لیے) اور دوسری اوور کلاؤڈ آر سی (اوور کلاؤڈ کے انتظام کے لیے)۔ ان فائلوں کو بطور ذریعہ بیان کیا جانا چاہیے، کیونکہ ان میں تصدیق کے لیے ضروری معلومات ہوتی ہیں۔
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0 | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ source overcloudrc
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$میری انسٹالیشن کے لیے ابھی بھی ایک چھوٹا سا ٹچ درکار ہے - کنٹرولر پر روٹ شامل کرنا، کیونکہ جس مشین کے ساتھ میں کام کر رہا ہوں وہ مختلف نیٹ ورک پر ہے۔ اس کے لیے ہیٹ ایڈمن اکاؤنٹ کے تحت کنٹرول-1 پر جائیں اور روٹ کو رجسٹر کریں۔
(undercloud) [stack@undercloud ~]$ ssh [email protected]
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254ٹھیک ہے، اب آپ افق میں جا سکتے ہیں۔ تمام معلومات - پتے، لاگ ان اور پاس ورڈ - فائل /home/stack/overcloudrc میں ہیں۔ حتمی خاکہ اس طرح لگتا ہے:
ویسے، ہماری تنصیب میں، مشین کے پتے DHCP کے ذریعے جاری کیے گئے تھے اور جیسا کہ آپ دیکھ سکتے ہیں، وہ "بے ترتیب" جاری کیے جاتے ہیں۔ آپ ٹیمپلیٹ میں سختی سے وضاحت کر سکتے ہیں کہ اگر آپ کو ضرورت ہو تو تعیناتی کے دوران کس مشین کے ساتھ کون سا پتہ منسلک ہونا چاہیے۔
ورچوئل مشینوں کے درمیان ٹریفک کیسے چلتا ہے؟
اس مضمون میں ہم ٹریفک کو گزرنے کے لیے تین آپشنز دیکھیں گے۔
- ایک L2 نیٹ ورک پر ایک ہائپر وائزر پر دو مشینیں۔
- ایک ہی L2 نیٹ ورک پر مختلف ہائپر وائزرز پر دو مشینیں۔
- مختلف نیٹ ورکس پر دو مشینیں (کراس نیٹ ورک روٹنگ)
بیرونی نیٹ ورک کے ذریعے بیرونی دنیا تک رسائی کے معاملات، تیرتے پتوں کے ساتھ ساتھ تقسیم شدہ روٹنگ کا استعمال کرتے ہوئے، ہم اگلی بار غور کریں گے، فی الحال ہم اندرونی ٹریفک پر توجہ مرکوز کریں گے۔
چیک کرنے کے لیے، آئیے درج ذیل خاکہ کو اکٹھا کرتے ہیں:
ہم نے 4 ورچوئل مشینیں بنائی ہیں - 3 ایک L2 نیٹ ورک پر - نیٹ-1، اور 1 مزید نیٹ-2 نیٹ ورک پر
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Name | Tenant ID | Status | Task State | Power State | Networks |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ آئیے دیکھتے ہیں کہ تیار کردہ مشینیں کن ہائپر وائزرز پر واقع ہیں:
(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-3 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-4 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000004 |
(اوور کلاؤڈ) [stack@undercloud ~]$
مشینیں vm-1 اور vm-3 کمپیوٹ-0 پر واقع ہیں، مشینیں vm-2 اور vm-4 نوڈ کمپیوٹ-1 پر واقع ہیں۔
اس کے علاوہ، مخصوص نیٹ ورکس کے درمیان روٹنگ کو فعال کرنے کے لیے ایک ورچوئل راؤٹر بنایا گیا ہے۔
(overcloud) [stack@undercloud ~]$ openstack router list --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID | Name | Status | State | Distributed | HA | Project |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP | False | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ روٹر میں دو ورچوئل پورٹس ہیں، جو نیٹ ورکس کے لیے گیٹ وے کے طور پر کام کرتے ہیں۔
(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$ لیکن اس سے پہلے کہ ہم دیکھیں کہ ٹریفک کیسے چلتی ہے، آئیے دیکھتے ہیں کہ ہمارے پاس اس وقت کنٹرول نوڈ (جو کہ نیٹ ورک نوڈ بھی ہے) اور کمپیوٹ نوڈ پر کیا ہے۔ آئیے کمپیوٹ نوڈ کے ساتھ شروع کریں۔
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$اس وقت، نوڈ میں تین ovs پل ہیں - br-int، br-tun، br-ex۔ ان کے درمیان، جیسا کہ ہم دیکھتے ہیں، انٹرفیس کا ایک سیٹ ہے۔ سمجھنے میں آسانی کے لیے، آئیے ان تمام انٹرفیس کو خاکہ پر پلاٹ کرتے ہیں اور دیکھتے ہیں کہ کیا ہوتا ہے۔
ان پتوں کو دیکھتے ہوئے جن پر VxLAN سرنگیں بلند کی گئی ہیں، یہ دیکھا جا سکتا ہے کہ ایک سرنگ کو کمپیوٹ-1 (192.168.255.26) تک بڑھایا گیا ہے، دوسری سرنگ کنٹرول-1 (192.168.255.15) کی طرف دکھائی دیتی ہے۔ لیکن سب سے دلچسپ بات یہ ہے کہ br-ex میں فزیکل انٹرفیس نہیں ہے، اور اگر آپ دیکھیں کہ فلوز کنفیگر کیے گئے ہیں، تو آپ دیکھ سکتے ہیں کہ یہ پل اس وقت صرف ٹریفک کو چھوڑ سکتا ہے۔
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20<link>
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ جیسا کہ آپ آؤٹ پٹ سے دیکھ سکتے ہیں، ایڈریس کو براہ راست فزیکل پورٹ پر خراب کیا جاتا ہے، ورچوئل برج انٹرفیس پر نہیں۔
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-ex
cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$
پہلے قاعدے کے مطابق، ہر وہ چیز جو phy-br-ex پورٹ سے آئی تھی اسے ضائع کر دینا چاہیے۔
درحقیقت، اس پل پر ٹریفک کے آنے کے لیے فی الحال کوئی اور جگہ نہیں ہے سوائے اس انٹرفیس (br-int کے ساتھ انٹرفیس) کے، اور قطروں کو دیکھتے ہوئے، BUM ٹریفک پہلے ہی پل میں جا چکی ہے۔
یعنی ٹریفک اس نوڈ کو صرف VxLAN ٹنل کے ذریعے چھوڑ سکتی ہے اور کچھ نہیں۔ تاہم، اگر آپ DVR آن کرتے ہیں، تو صورتحال بدل جائے گی، لیکن ہم اس سے کسی اور وقت نمٹیں گے۔ نیٹ ورک آئسولیشن کا استعمال کرتے وقت، مثال کے طور پر vlans کا استعمال کرتے ہوئے، آپ کے پاس vlan 3 میں ایک L0 انٹرفیس نہیں، بلکہ کئی انٹرفیس ہوں گے۔ تاہم، VxLAN ٹریفک نوڈ کو اسی طرح چھوڑ دے گا، بلکہ کسی قسم کے وقف شدہ vlan میں بھی شامل ہو جائے گا۔
ہم نے کمپیوٹ نوڈ کو ترتیب دیا ہے، آئیے کنٹرول نوڈ پر چلتے ہیں۔
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
br-ex:
br-ex 65534/1: (internal)
eth0 1/2: (system)
phy-br-ex 2/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/3: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/4: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$درحقیقت، ہم کہہ سکتے ہیں کہ سب کچھ ایک جیسا ہے، لیکن آئی پی ایڈریس اب فزیکل انٹرفیس پر نہیں بلکہ ورچوئل برج پر ہے۔ ایسا اس لیے کیا گیا ہے کہ یہ بندرگاہ وہ بندرگاہ ہے جس کے ذریعے ٹریفک باہر کی دنیا تک جائے گی۔
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20<link>
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ یہ بندرگاہ br-ex برج سے منسلک ہے اور چونکہ اس پر vlan کے ٹیگ نہیں ہیں، یہ بندرگاہ ایک ٹرنک پورٹ ہے جس پر تمام vlans کی اجازت ہے، اب ٹریفک بغیر ٹیگ کے باہر جاتی ہے، جیسا کہ vlan-id 0 سے اشارہ کیا گیا ہے۔ اوپر کی پیداوار.
اس وقت باقی سب کچھ کمپیوٹ نوڈ سے ملتا جلتا ہے - وہی پل، وہی سرنگیں جو دو کمپیوٹ نوڈس تک جاتی ہیں۔
ہم اس مضمون میں سٹوریج نوڈس پر غور نہیں کریں گے، لیکن سمجھنے کے لیے یہ کہنا ضروری ہے کہ ان نوڈس کا نیٹ ورک حصہ بے عزتی کی حد تک ہے۔ ہمارے معاملے میں، صرف ایک فزیکل پورٹ (eth0) ہے جس میں IP ایڈریس تفویض کیا گیا ہے اور بس۔ یہاں کوئی VxLAN سرنگیں، سرنگوں کے پل وغیرہ نہیں ہیں - کوئی ovs بالکل نہیں ہے، کیونکہ اس میں کوئی فائدہ نہیں ہے۔ نیٹ ورک آئسولیشن کا استعمال کرتے وقت، اس نوڈ میں دو انٹرفیس ہوں گے (فزیکل پورٹس، باڈی، یا صرف دو ویلان - اس سے کوئی فرق نہیں پڑتا - یہ اس پر منحصر ہے کہ آپ کیا چاہتے ہیں) - ایک مینجمنٹ کے لیے، دوسرا ٹریفک کے لیے (VM ڈسک پر لکھنا) ، ڈسک سے پڑھنا وغیرہ)
ہم نے معلوم کیا کہ ہمارے پاس کسی بھی خدمات کی عدم موجودگی میں نوڈس پر کیا ہے۔ اب آئیے 4 ورچوئل مشینیں لانچ کرتے ہیں اور دیکھتے ہیں کہ اوپر بیان کردہ اسکیم کیسے بدلتی ہے - ہمارے پاس پورٹس، ورچوئل راؤٹرز وغیرہ ہونے چاہئیں۔
اب تک ہمارا نیٹ ورک اس طرح نظر آتا ہے:
ہمارے پاس ہر کمپیوٹر نوڈ پر دو ورچوئل مشینیں ہیں۔ compute-0 کو بطور مثال استعمال کرتے ہوئے، آئیے دیکھتے ہیں کہ سب کچھ کیسے شامل ہے۔
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ مشین میں صرف ایک ورچوئل انٹرفیس ہے - tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
یہ انٹرفیس لینکس پل میں نظر آتا ہے:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.0242904c92a8 no
qbr5bd37136-47 8000.5e4e05841423 no qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 no qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ جیسا کہ آپ آؤٹ پٹ سے دیکھ سکتے ہیں، پل میں صرف دو انٹرفیس ہیں - tap95d96a75-a0 اور qvb95d96a75-a0۔
یہاں یہ OpenStack میں ورچوئل نیٹ ورک ڈیوائسز کی اقسام پر تھوڑا سا غور کرنے کے قابل ہے:
vtap - ایک مثال سے منسلک ورچوئل انٹرفیس (VM)
کیو بی آر - لینکس پل
qvb اور qvo - vEth جوڑی لینکس برج اور اوپن vSwitch برج سے منسلک ہے
br-int, br-tun, br-vlan — کھلے vSwitch پل
patch-, int-br-, phy-br- - پلوں کو جوڑنے والے vSwitch پیچ انٹرفیس کھولیں
qg, qr, ha, fg, sg - OVS سے جڑنے کے لیے ورچوئل ڈیوائسز کے ذریعے استعمال ہونے والی vSwitch پورٹس کھولیں
جیسا کہ آپ سمجھتے ہیں، اگر ہمارے پاس پل میں ایک qvb95d96a75-a0 پورٹ ہے، جو کہ vEth جوڑا ہے، تو کہیں کہیں اس کا ہم منصب ہے، جسے منطقی طور پر qvo95d96a75-a0 کہا جانا چاہیے۔ آئیے دیکھتے ہیں کہ OVS پر کون سی بندرگاہیں ہیں۔
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
qvo5bd37136-47 6/6: (system)
qvo95d96a75-a0 3/5: (system)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ جیسا کہ ہم دیکھ سکتے ہیں، بندرگاہ br-int میں ہے۔ Br-int ایک سوئچ کے طور پر کام کرتا ہے جو ورچوئل مشین پورٹس کو ختم کرتا ہے۔ qvo95d96a75-a0 کے علاوہ، پورٹ qvo5bd37136-47 آؤٹ پٹ میں نظر آتا ہے۔ یہ دوسری ورچوئل مشین کی بندرگاہ ہے۔ نتیجے کے طور پر، ہمارا خاکہ اب اس طرح نظر آتا ہے:
ایک سوال جو فوری طور پر توجہ دینے والے قاری کی دلچسپی کا باعث بنتا ہے - ورچوئل مشین پورٹ اور OVS پورٹ کے درمیان لینکس پل کیا ہے؟ حقیقت یہ ہے کہ مشین کی حفاظت کے لیے حفاظتی گروپ استعمال کیے جاتے ہیں، جو iptables سے زیادہ کچھ نہیں ہیں۔ OVS iptables کے ساتھ کام نہیں کرتا، اس لیے یہ "Crutch" ایجاد ہوئی۔ تاہم، یہ متروک ہوتا جا رہا ہے - اسے نئی ریلیز میں کنٹراک سے تبدیل کیا جا رہا ہے۔
یعنی، بالآخر اسکیم اس طرح نظر آتی ہے:
ایک L2 نیٹ ورک پر ایک ہائپر وائزر پر دو مشینیں۔
چونکہ یہ دونوں VMs ایک ہی L2 نیٹ ورک اور ایک ہی ہائپر وائزر پر واقع ہیں، اس لیے ان کے درمیان ٹریفک منطقی طور پر مقامی طور پر br-int کے ذریعے بہے گا، کیونکہ دونوں مشینیں ایک ہی VLAN پر ہوں گی۔
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface Type Source Model MAC
-------------------------------------------------------
tap5bd37136-47 bridge qbr5bd37136-47 virtio fa:16:3e:83:ad:a4
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int
port VLAN MAC Age
6 1 fa:16:3e:83:ad:a4 0
3 1 fa:16:3e:44:98:20 0
[heat-admin@overcloud-novacompute-0 ~]$ ایک ہی L2 نیٹ ورک پر مختلف ہائپر وائزرز پر دو مشینیں۔
اب دیکھتے ہیں کہ ٹریفک ایک ہی L2 نیٹ ورک پر دو مشینوں کے درمیان کیسے جائے گی، لیکن مختلف ہائپر وائزرز پر واقع ہے۔ سچ پوچھیں تو کچھ زیادہ نہیں بدلے گا، بس ہائپر وائزرز کے درمیان ٹریفک vxlan سرنگ سے گزرے گی۔ آئیے ایک مثال دیکھتے ہیں۔
ورچوئل مشینوں کے پتے جن کے درمیان ہم ٹریفک دیکھیں گے:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface Type Source Model MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ ہم compute-0 پر br-int میں فارورڈنگ ٹیبل کو دیکھتے ہیں:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
2 1 fa:16:3e:72:ad:53 1
[heat-admin@overcloud-novacompute-0 ~]ٹریفک کو پورٹ 2 پر جانا چاہیے - آئیے دیکھتے ہیں کہ یہ کس قسم کی بندرگاہ ہے:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$یہ patch-tun ہے - یعنی br-tun میں انٹرفیس۔ آئیے دیکھتے ہیں کہ br-tun پر پیکج کا کیا ہوتا ہے:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ پیکٹ VxLAN میں پیک کیا جاتا ہے اور پورٹ 2 پر بھیجا جاتا ہے۔ آئیے دیکھتے ہیں کہ پورٹ 2 کہاں جاتا ہے:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:b2:d1:f8:21:96:66
2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$یہ compute-1 پر ایک vxlan سرنگ ہے:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$آئیے compute-1 پر جائیں اور دیکھتے ہیں کہ پیکیج کے ساتھ آگے کیا ہوتا ہے:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
2 1 fa:16:3e:44:98:20 1
[heat-admin@overcloud-novacompute-1 ~]$ Mac compute-1 پر br-int فارورڈنگ ٹیبل میں ہے، اور جیسا کہ اوپر کے آؤٹ پٹ سے دیکھا جا سکتا ہے، یہ پورٹ 2 کے ذریعے نظر آتا ہے، جو کہ br-tun کی طرف پورٹ ہے:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46ٹھیک ہے، پھر ہم دیکھتے ہیں کہ کمپیوٹ-1 پر br-int میں ایک منزل پوست ہے:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
3 1 fa:16:3e:72:ad:53 0
[heat-admin@overcloud-novacompute-1 ~]$ یعنی، موصول ہونے والا پیکٹ پورٹ 3 پر جائے گا، جس کے پیچھے پہلے سے ہی ایک ورچوئل مشین مثال-00000003 موجود ہے۔
ورچوئل انفراسٹرکچر پر سیکھنے کے لیے اوپن اسٹیک کو تعینات کرنے کی خوبصورتی یہ ہے کہ ہم آسانی سے ہائپر وائزرز کے درمیان ٹریفک کو پکڑ سکتے ہیں اور دیکھ سکتے ہیں کہ اس کے ساتھ کیا ہو رہا ہے۔ اب ہم یہی کریں گے، tcpdump کو vnet پورٹ پر compute-0 کی طرف چلائیں:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************پہلی سطر ظاہر کرتی ہے کہ ایڈریس 10.0.1.85 سے Patek ایڈریس 10.0.1.88 (ICMP ٹریفک) پر جاتا ہے، اور اسے vni 22 والے VxLAN پیکٹ میں لپیٹا جاتا ہے اور پیکٹ میزبان 192.168.255.19 (compute-0) سے ہوسٹ 192.168.255.26 پر جاتا ہے۔ .1 ( کمپیوٹ-XNUMX)۔ ہم چیک کر سکتے ہیں کہ VNI ovs میں بیان کردہ سے میل کھاتا ہے۔
آئیے اس لائن پر واپس آتے ہیں actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2۔ ہیکساڈیسیمل نمبر سسٹم میں 0x16 vni ہے۔ آئیے اس نمبر کو 16ویں سسٹم میں تبدیل کریں:
16 = 6*16^0+1*16^1 = 6+16 = 22یعنی vni حقیقت سے مطابقت رکھتا ہے۔
دوسری لائن واپسی کی ٹریفک کو ظاہر کرتی ہے، ٹھیک ہے، اس کی وضاحت کرنے کا کوئی فائدہ نہیں، وہاں سب کچھ واضح ہے۔
مختلف نیٹ ورکس پر دو مشینیں (انٹر نیٹ ورک روٹنگ)
آج کا آخری معاملہ ورچوئل روٹر کا استعمال کرتے ہوئے ایک پروجیکٹ کے اندر نیٹ ورکس کے درمیان روٹنگ ہے۔ ہم DVR کے بغیر کیس پر غور کر رہے ہیں (ہم اسے کسی اور مضمون میں دیکھیں گے)، لہذا نیٹ ورک نوڈ پر روٹنگ ہوتی ہے۔ ہمارے معاملے میں، نیٹ ورک نوڈ کو ایک الگ ادارے میں نہیں رکھا گیا ہے اور یہ کنٹرول نوڈ پر واقع ہے۔
سب سے پہلے، دیکھتے ہیں کہ روٹنگ کام کرتی ہے:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 msچونکہ اس معاملے میں پیکٹ کو گیٹ وے پر جانا چاہیے اور وہاں روٹ کیا جانا چاہیے، اس لیے ہمیں گیٹ وے کا پوست کا پتہ معلوم کرنا ہوگا، جس کے لیے ہم مثال کے طور پر اے آر پی ٹیبل کو دیکھتے ہیں:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether] on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether] on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether] on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether] on eth0اب دیکھتے ہیں کہ منزل کے ساتھ ٹریفک (10.0.1.254) fa:16:3e:c4:64:70 کہاں بھیجی جائے:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
2 1 fa:16:3e:c4:64:70 0
[heat-admin@overcloud-novacompute-0 ~]$ آئیے دیکھتے ہیں کہ پورٹ 2 کہاں جاتا ہے:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ سب کچھ منطقی ہے، ٹریفک br-tun پر جاتی ہے۔ آئیے دیکھتے ہیں کہ اسے کس vxlan سرنگ میں لپیٹا جائے گا:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ تیسری بندرگاہ vxlan سرنگ ہے:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ جو کنٹرول نوڈ کو دیکھتا ہے:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ ٹریفک کنٹرول نوڈ تک پہنچ گئی ہے، اس لیے ہمیں اس پر جانے کی ضرورت ہے اور دیکھنا ہوگا کہ روٹنگ کیسے ہوگی۔
جیسا کہ آپ کو یاد ہے، اندر کا کنٹرول نوڈ بالکل کمپیوٹ نوڈ جیسا ہی نظر آتا تھا - وہی تین پل، صرف br-ex میں ایک فزیکل پورٹ تھا جس کے ذریعے نوڈ باہر ٹریفک بھیج سکتا تھا۔ مثالوں کی تخلیق نے کمپیوٹ نوڈس پر کنفیگریشن کو تبدیل کر دیا - لینکس برج، iptables اور انٹرفیس کو نوڈس میں شامل کیا گیا۔ نیٹ ورکس اور ورچوئل روٹر کی تخلیق نے بھی کنٹرول نوڈ کی ترتیب پر اپنا نشان چھوڑا۔
لہذا، یہ واضح ہے کہ گیٹ وے میک ایڈریس کنٹرول نوڈ پر br-int فارورڈنگ ٹیبل میں ہونا چاہئے۔ آئیے چیک کریں کہ یہ وہاں ہے اور کہاں نظر آرہا ہے:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
5 1 fa:16:3e:c4:64:70 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ میک پورٹ qr-0c52b15f-8f سے نظر آتا ہے۔ اگر ہم Openstack میں ورچوئل پورٹس کی فہرست پر واپس جائیں تو اس قسم کی پورٹ مختلف ورچوئل ڈیوائسز کو OVS سے جوڑنے کے لیے استعمال ہوتی ہے۔ زیادہ درست ہونے کے لیے، qr ورچوئل راؤٹر کا ایک پورٹ ہے، جسے نام کی جگہ کے طور پر دکھایا جاتا ہے۔
آئیے دیکھتے ہیں کہ سرور پر کیا نام کی جگہیں ہیں:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ زیادہ سے زیادہ تین کاپیاں۔ لیکن ناموں کو دیکھتے ہوئے، آپ ان میں سے ہر ایک کے مقصد کا اندازہ لگا سکتے ہیں۔ ہم بعد میں ID 0 اور 1 کے ساتھ مثالوں پر واپس جائیں گے، اب ہمیں namespace qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe میں دلچسپی ہے:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254
[heat-admin@overcloud-controller-0 ~]$ اس نام کی جگہ میں دو اندرونی ہیں جو ہم نے پہلے بنائے تھے۔ دونوں ورچوئل پورٹس کو br-int میں شامل کر دیا گیا ہے۔ آئیے پورٹ qr-0c52b15f-8f کا میک ایڈریس چیک کرتے ہیں، کیونکہ ٹریفک، منزل کے میک ایڈریس کے مطابق، اس انٹرفیس پر جاتی ہے۔
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ یعنی اس معاملے میں سب کچھ معیاری روٹنگ کے قوانین کے مطابق کام کرتا ہے۔ چونکہ ٹریفک میزبان 10.0.2.8 کے لیے مقصود ہے، اس لیے اسے دوسرے انٹرفیس qr-92fa49b5-54 سے باہر نکلنا چاہیے اور vxlan سرنگ سے ہو کر کمپیوٹ نوڈ تک جانا چاہیے۔
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address HWtype HWaddress Flags Mask Iface
10.0.1.88 ether fa:16:3e:72:ad:53 C qr-0c52b15f-8f
10.0.1.90 ether fa:16:3e:83:ad:a4 C qr-0c52b15f-8f
10.0.2.8 ether fa:16:3e:6c:ad:9c C qr-92fa49b5-54
10.0.2.42 ether fa:16:3e:f5:0b:29 C qr-92fa49b5-54
10.0.1.85 ether fa:16:3e:44:98:20 C qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ سب کچھ منطقی ہے، کوئی تعجب نہیں۔ آئیے دیکھتے ہیں کہ میزبان 10.0.2.8 کا پوست کا پتہ br-int میں کہاں نظر آتا ہے:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
2 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ جیسا کہ توقع کی جاتی ہے، ٹریفک br-tun تک جاتی ہے، آئیے دیکھتے ہیں کہ ٹریفک اگلی کس سرنگ پر جاتی ہے:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ ٹریفک سرنگ میں کمپیوٹ-1 تک جاتی ہے۔ ٹھیک ہے، compute-1 پر سب کچھ آسان ہے - br-tun سے پیکیج br-int اور وہاں سے ورچوئل مشین انٹرفیس پر جاتا ہے:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
4 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$ آئیے چیک کریں کہ یہ واقعی درست انٹرفیس ہے:
[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.02429c001e1c no
qbr3210e8ec-c0 8000.ea27f45358be no qvb3210e8ec-c0
tap3210e8ec-c0
qbre7e23f1b-07 8000.b26ac0eded8a no qvbe7e23f1b-07
tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface Type Source Model MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge qbr3210e8ec-c0 virtio fa:16:3e:6c:ad:9c
[heat-admin@overcloud-novacompute-1 ~]$
دراصل، ہم پیکج کے ذریعے پورے راستے پر چلے گئے۔ میرے خیال میں آپ نے دیکھا ہے کہ ٹریفک مختلف vxlan سرنگوں سے گزری اور مختلف VNIs کے ساتھ باہر نکلی۔ آئیے دیکھتے ہیں کہ یہ کس قسم کے VNI ہیں، جس کے بعد ہم نوڈ کے کنٹرول پورٹ پر ایک ڈمپ جمع کریں گے اور اس بات کو یقینی بنائیں گے کہ ٹریفک بالکل اسی طرح چلتی ہے جیسا کہ اوپر بیان کیا گیا ہے۔
لہذا، سرنگ ٹو کمپیوٹ-0 میں درج ذیل ایکشنز ہیں=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[]، آؤٹ پٹ:3۔ آئیے 0x16 کو ڈیسیمل نمبر سسٹم میں تبدیل کریں:
0x16 = 6*16^0+1*16^1 = 6+16 = 22کمپیوٹ-1 کے لیے سرنگ میں درج ذیل VNI ہے: actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[]، آؤٹ پٹ:2۔ آئیے 0x63 کو ڈیسیمل نمبر سسٹم میں تبدیل کریں:
0x63 = 3*16^0+6*16^1 = 3+96 = 99ٹھیک ہے، اب ڈمپ کو دیکھتے ہیں:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
*****************omitted*******************پہلا پیکٹ میزبان 192.168.255.19 (compute-0) سے vni 192.168.255.15 کے ساتھ 1 (کنٹرول-22) کی میزبانی کرنے والا vxlan پیکٹ ہے، جس کے اندر ایک ICMP پیکٹ میزبان 10.0.1.85 سے.10.0.2.8 ہوسٹ تک پیک کیا جاتا ہے۔ جیسا کہ ہم نے اوپر حساب کیا، vni اس سے میل کھاتا ہے جو ہم نے آؤٹ پٹ میں دیکھا۔
دوسرا پیکٹ میزبان 192.168.255.15 (کنٹرول-1) سے vni 192.168.255.26 کے ساتھ 1 (کمپیوٹ-99) کی میزبانی کرنے والا vxlan پیکٹ ہے، جس کے اندر ایک ICMP پیکٹ کو میزبان 10.0.1.85 سے.10.0.2.8 میزبان تک پیک کیا گیا ہے۔ جیسا کہ ہم نے اوپر حساب کیا، vni اس سے میل کھاتا ہے جو ہم نے آؤٹ پٹ میں دیکھا۔
اگلے دو پیکٹ 10.0.2.8 سے 10.0.1.85 سے واپسی کی ٹریفک ہیں۔
یعنی، آخر میں ہمیں مندرجہ ذیل کنٹرول نوڈ سکیم ملی:
ایسا ہی لگتا ہے؟ ہم دو نام کی جگہوں کے بارے میں بھول گئے:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ جیسا کہ ہم نے کلاؤڈ پلیٹ فارم کے فن تعمیر کے بارے میں بات کی، یہ اچھا ہوگا اگر مشینیں خود بخود ڈی ایچ سی پی سرور سے پتے وصول کریں۔ یہ ہمارے دو نیٹ ورکس 10.0.1.0/24 اور 10.0.2.0/24 کے لیے دو DHCP سرور ہیں۔
آئیے چیک کریں کہ یہ سچ ہے۔ اس نام کی جگہ میں صرف ایک پتہ ہے - 10.0.1.1 - خود DHCP سرور کا پتہ، اور یہ br-int میں بھی شامل ہے:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0آئیے دیکھتے ہیں کہ کیا qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 پر مشتمل عمل ان کے نام پر کنٹرول نوڈ پر ہیں:
[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
root 640420 0.0 0.0 4220 348 ? Ss 11:31 0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+ 951620 0.0 0.0 112944 980 pts/0 S+ 18:50 0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ اس طرح کا ایک عمل ہے اور اوپر آؤٹ پٹ میں پیش کردہ معلومات کی بنیاد پر، ہم، مثال کے طور پر، دیکھ سکتے ہیں کہ ہمارے پاس فی الحال کرائے کے لیے کیا ہے:
[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$نتیجے کے طور پر، ہمیں کنٹرول نوڈ پر خدمات کا درج ذیل سیٹ ملتا ہے:
ٹھیک ہے، ذہن میں رکھیں - یہ صرف 4 مشینیں، 2 اندرونی نیٹ ورکس اور ایک ورچوئل روٹر ہے... ہمارے پاس اب یہاں بیرونی نیٹ ورکس نہیں ہیں، مختلف پروجیکٹس کا ایک گروپ، ہر ایک اپنے اپنے نیٹ ورکس (اوور لیپنگ) کے ساتھ، اور ہمارے پاس ہے ایک تقسیم شدہ راؤٹر بند ہو گیا، اور آخر میں، ٹیسٹ بینچ میں صرف ایک کنٹرول نوڈ تھا (غلطی کو برداشت کرنے کے لیے تین نوڈس کا کورم ہونا چاہیے)۔ یہ منطقی ہے کہ تجارت میں ہر چیز "تھوڑا" زیادہ پیچیدہ ہے، لیکن اس سادہ سی مثال میں ہم سمجھتے ہیں کہ اسے کیسے کام کرنا چاہیے - چاہے آپ کے پاس 3 یا 300 نام کی جگہیں ہوں، یقیناً اہم ہے، لیکن کام کے نقطہ نظر سے مکمل ڈھانچہ، کچھ بھی زیادہ نہیں بدلے گا... حالانکہ آپ کچھ وینڈر ایس ڈی این میں پلگ ان نہیں کریں گے۔ لیکن یہ بالکل مختلف کہانی ہے۔
مجھے امید ہے کہ یہ دلچسپ تھا۔ اگر آپ کے پاس کوئی تبصرے/اضافے ہیں، یا کہیں میں نے بالکل جھوٹ بولا ہے (میں انسان ہوں اور میری رائے ہمیشہ موضوعی رہے گی) - وہ لکھیں جو درست کرنے/شامل کرنے کی ضرورت ہے - ہم سب کچھ درست/شامل کریں گے۔
آخر میں، میں اوپن اسٹیک (ونیلا اور وینڈر دونوں) کا VMWare کے کلاؤڈ حل کے ساتھ موازنہ کرنے کے بارے میں کچھ الفاظ کہنا چاہوں گا - پچھلے دو سالوں میں مجھ سے یہ سوال اکثر پوچھا جاتا رہا ہے اور، صاف لفظوں میں، میں پہلے ہی اس سے تھک چکے ہیں، لیکن پھر بھی۔ میری رائے میں، ان دو حلوں کا موازنہ کرنا بہت مشکل ہے، لیکن ہم یہ ضرور کہہ سکتے ہیں کہ دونوں حلوں میں نقصانات ہیں اور ایک حل کا انتخاب کرتے وقت آپ کو نفع و نقصان کا وزن کرنا ہوگا۔
اگر OpenStack ایک کمیونٹی سے چلنے والا حل ہے، تو VMWare کو صرف وہی کرنے کا حق ہے جو وہ چاہتا ہے (پڑھیں - اس کے لیے کیا فائدہ مند ہے) اور یہ منطقی ہے - کیونکہ یہ ایک تجارتی کمپنی ہے جو اپنے کلائنٹس سے پیسہ کمانے کی عادی ہے۔ لیکن ایک بڑا اور موٹا لیکن ہے - آپ OpenStack سے اتر سکتے ہیں، مثال کے طور پر Nokia سے، اور بہت کم خرچ کے ساتھ، مثال کے طور پر، Juniper (Contrail Cloud) سے حل پر سوئچ کر سکتے ہیں، لیکن آپ کے VMWare سے باہر نکلنے کا امکان نہیں ہے۔ . میرے نزدیک یہ دو حل اس طرح نظر آتے ہیں - اوپن اسٹیک (فروش) ایک سادہ پنجرا ہے جس میں آپ کو رکھا جاتا ہے، لیکن آپ کے پاس ایک چابی ہے اور آپ کسی بھی وقت چھوڑ سکتے ہیں۔ VMWare ایک سنہری پنجرا ہے، اس پنجرے کی چابی مالک کے پاس ہے اور اس پر آپ کو بہت زیادہ خرچہ آئے گا۔
میں یا تو پہلے پروڈکٹ یا دوسرے کو فروغ نہیں دے رہا ہوں - آپ اپنی ضرورت کا انتخاب کریں۔ لیکن اگر میرے پاس ایسا انتخاب ہوتا، تو میں دونوں حلوں کا انتخاب کروں گا - IT کلاؤڈ کے لیے VMWare (کم بوجھ، آسان انتظام)، کچھ وینڈر سے OpenStack (Nokia اور Juniper بہت اچھے ٹرنکی حل فراہم کرتے ہیں) - ٹیلی کام کلاؤڈ کے لیے۔ میں خالص آئی ٹی کے لیے اوپن اسٹیک استعمال نہیں کروں گا - یہ ایک توپ سے چڑیوں کو گولی مارنے جیسا ہے، لیکن مجھے فالتو پن کے علاوہ اسے استعمال کرنے میں کوئی تضاد نظر نہیں آتا۔ تاہم، ٹیلی کام میں VMWare کا استعمال فورڈ ریپٹر میں پسے ہوئے پتھر کو لے جانے کے مترادف ہے - یہ باہر سے خوبصورت ہے، لیکن ڈرائیور کو ایک کے بجائے 10 ٹرپ کرنے پڑتے ہیں۔
میری رائے میں، VMWare کا سب سے بڑا نقصان اس کا مکمل بند ہونا ہے - کمپنی آپ کو اس بارے میں کوئی معلومات نہیں دے گی کہ یہ کیسے کام کرتا ہے، مثال کے طور پر، vSAN یا ہائپر وائزر کرنل میں کیا ہے - یہ صرف اس کے لیے منافع بخش نہیں ہے - یعنی آپ کبھی بھی VMWare میں ماہر نہ بنیں - وینڈر سپورٹ کے بغیر، آپ برباد ہو جاتے ہیں (اکثر میں VMWare ماہرین سے ملتا ہوں جو معمولی سوالات سے حیران ہوتے ہیں)۔ میرے لیے، VMWare ایک کار خرید رہا ہے جس میں ہڈ بند ہے - ہاں، آپ کے پاس ماہرین ہوسکتے ہیں جو ٹائمنگ بیلٹ کو تبدیل کرسکتے ہیں، لیکن صرف وہی شخص جس نے آپ کو یہ حل بیچا ہے وہ ہڈ کھول سکتا ہے۔ ذاتی طور پر، مجھے ایسے حل پسند نہیں ہیں جن میں میں فٹ نہیں ہو سکتا۔ آپ کہیں گے کہ شاید آپ کو ہڈ کے نیچے جانے کی ضرورت نہیں ہے۔ ہاں، یہ ممکن ہے، لیکن میں آپ کو اس وقت دیکھوں گا جب آپ کو کلاؤڈ میں 20-30 ورچوئل مشینوں، 40-50 نیٹ ورکس سے ایک بڑے فنکشن کو جمع کرنے کی ضرورت ہو گی، جن میں سے آدھے باہر جانا چاہتے ہیں، اور دوسرا آدھا حصہ مانگے گا۔ SR-IOV ایکسلریشن، بصورت دیگر آپ کو ان کاروں میں سے ایک دو درجن مزید درکار ہوں گے - بصورت دیگر کارکردگی کافی نہیں ہوگی۔
دوسرے نقطہ نظر بھی ہیں، اس لیے صرف آپ ہی فیصلہ کر سکتے ہیں کہ کس چیز کا انتخاب کرنا ہے اور سب سے اہم بات، پھر آپ اپنی پسند کے ذمہ دار ہوں گے۔ یہ صرف میری رائے ہے - ایک ایسا شخص جس نے کم از کم 4 پروڈکٹس کو دیکھا اور چھو لیا ہے - Nokia، Juniper، Red Hat اور VMWare۔ یعنی، میرے پاس موازنہ کرنے کے لیے کچھ ہے۔
ماخذ: www.habr.com