SDSM ختم ہو گیا ہے، لیکن لکھنے کی بے قابو خواہش باقی ہے۔

کئی سالوں سے، ہمارے بھائی کو معمول کے کام کرنے، ارتکاب کرنے سے پہلے انگلیوں کو عبور کرنے اور راتوں کو رول بیک کی وجہ سے نیند کی کمی کا سامنا کرنا پڑا۔
لیکن تاریک وقت ختم ہونے کو ہے۔

اس مضمون کے ساتھ میں ایک سلسلہ شروع کروں گا کہ کیسے میرے لئے آٹومیشن دیکھا جاتا ہے.
راستے میں، ہم آٹومیشن کے مراحل کو سمجھیں گے، متغیرات کو ذخیرہ کرنے، رسمی ڈیزائن، RestAPI، NETCONF، YANG، YDK اور ہم بہت ساری پروگرامنگ کریں گے۔
میرے لئے اس کا مطلب یہ ہے کہ a) یہ معروضی سچائی نہیں ہے، b) یہ غیر مشروط طور پر بہترین نقطہ نظر نہیں ہے، c) میری رائے، پہلے سے آخری مضمون تک کی تحریک کے دوران بھی، بدل سکتی ہے - سچ پوچھیں تو، مسودے کے مرحلے سے اشاعت، میں نے ہر چیز کو مکمل طور پر دو بار دوبارہ لکھا۔

مواد

1. اہداف
   1. نیٹ ورک ایک واحد حیاتیات کی طرح ہے۔
   2. کنفیگریشن ٹیسٹنگ
   3. ورژننگ
   4. خدمات کی نگرانی اور خود علاج

2. فنڈز
   1. انوینٹری سسٹم
   2. آئی پی اسپیس مینجمنٹ سسٹم
   3. نیٹ ورک سروس کی تفصیل کا نظام
   4. ڈیوائس کی شروعات کا طریقہ کار
   5. وینڈر-ایگنوسٹک کنفیگریشن ماڈل
   6. وینڈر کے لیے مخصوص ڈرائیور انٹرفیس
   7. ڈیوائس کو کنفیگریشن فراہم کرنے کا طریقہ کار
   8. CI / CD
   9. بیک اپ اور انحراف کی تلاش کا طریقہ کار
   10. نگرانی کا نظام

3. حاصل يہ ہوا

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

کتنی مضحکہ خیز بات ہے کہ دوسری بار اسی راستے سے گزرنا پڑے۔

سب سے پہلے مجھے نیٹ ورکس کے بارے میں مضمون لکھنا پڑا کیونکہ وہ RuNet پر نہیں تھے۔

اب مجھے کوئی ایسی جامع دستاویز نہیں مل سکی جو آٹومیشن کے طریقہ کار کو منظم کرے اور سادہ عملی مثالوں کا استعمال کرتے ہوئے مذکورہ بالا ٹیکنالوجیز کا تجزیہ کرے۔

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

ہم ایک درمیانے درجے کا LAN DC ڈیٹا سینٹر لینے کی کوشش کریں گے اور پوری آٹومیشن اسکیم پر کام کریں گے۔
میں آپ کے ساتھ تقریباً پہلی بار کچھ چیزیں کروں گا۔

میں یہاں بیان کردہ نظریات اور آلات میں اصلی نہیں ہوں گا۔ دمتری فگول کے پاس ایک بہترین ہے۔ اس موضوع پر اسٹریمز کے ساتھ چینل.
مضامین ان کے ساتھ کئی پہلوؤں سے اوورلیپ ہوں گے۔

LAN DC میں 4 DCs، تقریباً 250 سوئچز، نصف درجن راؤٹرز اور دو فائر والز ہیں۔
فیس بک نہیں، لیکن آپ کو آٹومیشن کے بارے میں گہرائی سے سوچنے کے لیے کافی ہے۔
تاہم، ایک رائے یہ ہے کہ اگر آپ کے پاس 1 سے زیادہ ڈیوائس ہے، تو آٹومیشن کی پہلے ہی ضرورت ہے۔
درحقیقت، یہ تصور کرنا مشکل ہے کہ اب کوئی بھی گھٹنے کے اسکرپٹ کے کم از کم ایک پیکٹ کے بغیر رہ سکتا ہے۔
اگرچہ میں نے سنا ہے کہ ایسے دفاتر ہیں جہاں ایکسل میں آئی پی ایڈریسز رکھے جاتے ہیں، اور نیٹ ورک کے ہزاروں آلات میں سے ہر ایک کو دستی طور پر ترتیب دیا جاتا ہے اور اس کی اپنی منفرد ترتیب ہوتی ہے۔ بلاشبہ یہ جدید آرٹ کے طور پر منظور کیا جا سکتا ہے، لیکن انجینئر کے جذبات کو ضرور مجروح کیا جائے گا۔

اہداف

اب ہم سب سے تجریدی اہداف طے کریں گے:

• نیٹ ورک ایک واحد حیاتیات کی طرح ہے۔
• کنفیگریشن ٹیسٹنگ
• نیٹ ورک اسٹیٹ ورژننگ
• خدمات کی نگرانی اور خود علاج

اس مضمون میں بعد میں ہم دیکھیں گے کہ ہم کن ذرائع کو استعمال کریں گے، اور ذیل میں، ہم اہداف اور ذرائع کو تفصیل سے دیکھیں گے۔

نیٹ ورک ایک واحد حیاتیات کی طرح ہے۔

سیریز کا وضاحتی جملہ، اگرچہ پہلی نظر میں یہ اتنا اہم نہیں لگتا ہے: ہم نیٹ ورک کو ترتیب دیں گے، انفرادی آلات کو نہیں۔.
حالیہ برسوں میں، ہم نے نیٹ ورک کو ایک واحد وجود کے طور پر برتاؤ کرنے کی طرف زور میں تبدیلی دیکھی ہے، اس لیے سافٹ ویئر ڈیفائنڈ نیٹ ورکنگ۔, ارادے سے چلنے والے نیٹ ورکس и خود مختار نیٹ ورکس.
آخر کار، نیٹ ورک سے ایپلی کیشنز کو عالمی سطح پر کیا ضرورت ہے: پوائنٹس A اور B (اچھی طرح سے، کبھی کبھی +B-Z) کے درمیان رابطہ اور دیگر ایپلی کیشنز اور صارفین سے الگ تھلگ۔

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

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

1. سب سے پہلے ہم سسٹم میں تبدیلیوں کو دستاویز کرتے ہیں۔
2. تمام نیٹ ورک ڈیوائسز کی ٹارگٹ کنفیگریشن تیار کرنا
3. ہم نیٹ ورک کنفیگریشن اپ ڈیٹ پروگرام شروع کرتے ہیں، جو اس بات کا حساب لگاتا ہے کہ ہر نوڈ پر کیا ہٹانا ہے، کیا شامل کرنا ہے، اور نوڈس کو مطلوبہ حالت میں لاتا ہے۔

ایک ہی وقت میں، ہم صرف پہلے مرحلے میں دستی طور پر تبدیلیاں کرتے ہیں۔

کنفیگریشن ٹیسٹنگ

جانا جاتا ہےکہ 80% مسائل کنفیگریشن تبدیلیوں کے دوران پیش آتے ہیں - اس کا بالواسطہ ثبوت یہ ہے کہ نئے سال کی تعطیلات کے دوران سب کچھ عام طور پر پرسکون ہوتا ہے۔
میں نے ذاتی طور پر انسانی غلطی کی وجہ سے درجنوں عالمی ڈاؤن ٹائمز کا مشاہدہ کیا ہے: غلط کمانڈ، کنفیگریشن غلط برانچ میں عمل میں لائی گئی، کمیونٹی بھول گئی، MPLS کو عالمی سطح پر راؤٹر پر مسمار کر دیا گیا، ہارڈ ویئر کے پانچ ٹکڑوں کو ترتیب دیا گیا، لیکن غلطی نہیں ہوئی۔ چھٹے پر دیکھا گیا، پرانی تبدیلیاں کسی اور شخص نے کیں۔ ایک ٹن منظرنامے ہیں۔

آٹومیشن ہمیں کم غلطیاں کرنے کی اجازت دے گا، لیکن بڑے پیمانے پر۔ اس طرح آپ نہ صرف ایک ڈیوائس بلکہ پورے نیٹ ورک کو ایک ساتھ اینٹ کر سکتے ہیں۔

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

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

کے بارے میں خیالات کا ایک نامیاتی تسلسل نظام نیٹ ورک مینجمنٹ اور CI/CD کنفیگریشن کا مکمل ورژن بن جاتا ہے۔

ورژننگ

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

ہم کہتے ہیں کہ موجودہ ورژن 1.0.0 ہے۔
کیا کسی ایک ٹی او آر پر لوپ بیک انٹرفیس کا آئی پی ایڈریس بدل گیا ہے؟ یہ ایک معمولی ورژن ہے اور اس کا نمبر 1.0.1 ہوگا۔
ہم نے BGP میں راستوں کو درآمد کرنے کی پالیسیوں پر نظر ثانی کی ہے - تھوڑی زیادہ سنجیدگی سے - پہلے ہی 1.1.0
ہم نے آئی جی پی سے چھٹکارا حاصل کرنے اور صرف بی جی پی پر جانے کا فیصلہ کیا - یہ پہلے سے ہی ایک بنیادی ڈیزائن میں تبدیلی ہے - 2.0.0۔

ایک ہی وقت میں، مختلف ڈی سی کے مختلف ورژن ہو سکتے ہیں - نیٹ ورک ترقی کر رہا ہے، نئے آلات نصب کیے جا رہے ہیں، ریڑھ کی ہڈی کی نئی سطحیں کہیں شامل کی جا رہی ہیں، دوسروں میں نہیں، وغیرہ۔

کے بارے میں سیمنٹک ورژننگ ہم ایک الگ مضمون میں بات کریں گے۔

میں دہراتا ہوں - کوئی بھی تبدیلی (سوائے ڈیبگنگ کمانڈز کے) ایک ورژن اپ ڈیٹ ہے۔ موجودہ ورژن سے کسی بھی انحراف کے بارے میں منتظمین کو مطلع کیا جانا چاہیے۔

تبدیلیوں کو رول بیک کرنے پر بھی یہی لاگو ہوتا ہے - یہ آخری کمانڈز کو منسوخ نہیں کر رہا ہے، یہ ڈیوائس کے آپریٹنگ سسٹم کا استعمال کرتے ہوئے رول بیک نہیں ہے - یہ پورے نیٹ ورک کو ایک نئے (پرانے) ورژن پر لا رہا ہے۔

خدمات کی نگرانی اور خود علاج

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

اور یہاں ہم نہ صرف انفرادی آلات بلکہ پورے نیٹ ورک کی صحت کی بھی نگرانی کرتے ہیں، دونوں وائٹ باکس، جو نسبتاً قابل فہم ہے، اور بلیک باکس، جو زیادہ پیچیدہ ہے۔

ہمیں ایسے مہتواکانکشی منصوبوں کو عملی جامہ پہنانے کی کیا ضرورت ہوگی؟

• نیٹ ورک پر موجود تمام آلات، ان کے مقام، کردار، ماڈلز، سافٹ ویئر ورژنز کی فہرست رکھیں۔
  kazan-leaf-1.lmu.net, Kazan, leaf, Juniper QFX 5120, R18.3.
• نیٹ ورک سروسز کو بیان کرنے کے لیے ایک نظام رکھیں۔
  آئی جی پی، بی جی پی، ایل 2/3 وی پی این، پالیسی، اے سی ایل، این ٹی پی، ایس ایس ایچ۔
• آلہ شروع کرنے کے قابل ہو.
  میزبان نام، Mgmt IP، Mgmt روٹ، صارفین، RSA-Keys، LLDP، NETCONF
• ڈیوائس کو کنفیگر کریں اور کنفیگریشن کو مطلوبہ (بشمول پرانے) ورژن پر لائیں۔
• ٹیسٹ کنفیگریشن
• وقتاً فوقتاً موجودہ آلات سے انحراف کے لیے تمام آلات کی حیثیت چیک کریں اور رپورٹ کریں کہ یہ کسے ہونا چاہیے۔
  راتوں رات، کسی نے خاموشی سے ACL میں ایک اصول شامل کر دیا۔.
• کارکردگی کی نگرانی کریں۔

فنڈز

پراجیکٹ کو اجزاء میں گلنا شروع کرنا کافی پیچیدہ لگتا ہے۔

اور ان میں سے دس ہوں گے:

1. انوینٹری سسٹم
2. آئی پی اسپیس مینجمنٹ سسٹم
3. نیٹ ورک سروس کی تفصیل کا نظام
4. ڈیوائس کی شروعات کا طریقہ کار
5. وینڈر-ایگنوسٹک کنفیگریشن ماڈل
6. وینڈر کے لیے مخصوص ڈرائیور انٹرفیس
7. ڈیوائس کو کنفیگریشن فراہم کرنے کا طریقہ کار
8. CI / CD
9. بیک اپ اور انحراف کی تلاش کا طریقہ کار
10. نگرانی کا نظام

یہ، ویسے، اس بات کی ایک مثال ہے کہ کس طرح سائیکل کے اہداف پر نظریہ تبدیل ہوا - مسودے میں 4 اجزاء تھے۔

مثال میں میں نے تمام اجزاء اور آلہ خود دکھایا۔
ایک دوسرے کو کاٹتے ہوئے اجزاء ایک دوسرے کے ساتھ تعامل کرتے ہیں۔
بلاک جتنا بڑا ہوگا، اس جزو پر اتنی ہی زیادہ توجہ دینے کی ضرورت ہے۔

جزو 1: انوینٹری سسٹم

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

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

• انوینٹری نمبر
• عنوان/تفصیل
• ماڈل (Huawei CE12800، Juniper QFX5120، وغیرہ۔)
• خصوصیت کے پیرامیٹرز (بورڈز، انٹرفیس، وغیرہ)
• کردار (پتی، ریڑھ کی ہڈی، بارڈر راؤٹر، وغیرہ)
• مقام (علاقہ، شہر، ڈیٹا سینٹر، ریک، یونٹ)
• آلات کے درمیان باہمی رابطے
• نیٹ ورک ٹوپولوجی

یہ بالکل واضح ہے کہ ہم خود یہ سب جاننا چاہتے ہیں۔
لیکن کیا اس سے آٹومیشن کے مقاصد میں مدد ملے گی؟
یقینا
مثال کے طور پر، ہم جانتے ہیں کہ لیف سوئچز پر دیئے گئے ڈیٹا سینٹر میں، اگر یہ Huawei ہے، تو مخصوص ٹریفک کو فلٹر کرنے کے لیے ACLs کو VLAN پر لاگو کیا جانا چاہیے، اور اگر یہ Juniper ہے، تو فزیکل انٹرفیس کے یونٹ 0 پر۔
یا آپ کو خطے کی تمام سرحدوں پر ایک نیا Syslog سرور رول آؤٹ کرنے کی ضرورت ہے۔

اس میں ہم ورچوئل نیٹ ورک ڈیوائسز کو اسٹور کریں گے، مثال کے طور پر ورچوئل روٹرز یا روٹ ریفلیکٹرز۔ ہم DNS سرورز، NTP، Syslog اور عام طور پر ہر وہ چیز شامل کر سکتے ہیں جو کسی نہ کسی طرح نیٹ ورک سے متعلق ہو۔

جزو 2: آئی پی اسپیس مینجمنٹ سسٹم

جی ہاں، اور آج کل ایسے لوگوں کی ٹیمیں ہیں جو ایکسل فائل میں سابقہ ​​جات اور آئی پی ایڈریس کو ٹریک کرتی ہیں۔ لیکن جدید نقطہ نظر اب بھی ایک ڈیٹا بیس ہے، جس میں nginx/apache، API اور VRFs میں تقسیم IP ایڈریس اور نیٹ ورکس کو ریکارڈ کرنے کے لیے وسیع فنکشنز پر فرنٹ اینڈ ہے۔
آئی پی اے ایم - آئی پی ایڈریس مینجمنٹ۔

اپنے مقاصد کے لیے، ہم اس میں درج ذیل معلومات محفوظ کریں گے:

• وی ایل این۔
• وی آر ایف
• نیٹ ورکس/سب نیٹس
• IP پتے
• پتوں کو آلات، نیٹ ورکس کو مقامات اور VLAN نمبروں سے بائنڈنگ کرنا

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

یہ DCIM اور IPAM کو ایک نظام میں جوڑنے کی خواہش کا اشارہ کرتا ہے تاکہ فنکشنز کو ڈپلیکیٹ نہ کیا جائے اور دو ملتے جلتے اداروں کی خدمت نہ کی جائے۔
ہم یہی کریں گے۔

جزو 3. نیٹ ورک کی خدمات کی وضاحت کے لیے نظام

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

• انفراسٹرکچر
• کلائنٹ

سابقہ ​​کو بنیادی کنیکٹیویٹی اور ڈیوائس کنٹرول فراہم کرنے کے لیے ڈیزائن کیا گیا ہے۔ ان میں VTY، SNMP، NTP، Syslog، AAA، روٹنگ پروٹوکول، CoPP، وغیرہ شامل ہیں۔
مؤخر الذکر کلائنٹ کے لیے سروس کو منظم کرتا ہے: MPLS L2/L3VPN، GRE، VXLAN، VLAN، L2TP، وغیرہ۔
یقیناً، بارڈر لائن کیسز بھی ہیں - MPLS LDP، BGP کو کہاں شامل کیا جائے؟ ہاں، اور روٹنگ پروٹوکول کلائنٹس کے لیے استعمال کیے جا سکتے ہیں۔ لیکن یہ اہم نہیں ہے۔

دونوں قسم کی خدمات کنفیگریشن پرائمیٹوز میں تحلیل ہو جاتی ہیں:

• جسمانی اور منطقی انٹرفیس (ٹیگ/اینٹگ، ایم ٹی یو)
• IP پتے اور VRFs (IP, IPv6, VRF)
• ACLs اور ٹریفک پروسیسنگ کی پالیسیاں
• پروٹوکول (آئی جی پی، بی جی پی، ایم پی ایل ایس)
• روٹنگ پالیسیاں (سابقہ ​​فہرستیں، کمیونٹیز، ASN فلٹرز)۔
• یوٹیلیٹی سروسز (SSH، NTP، LLDP، Syslog...)
• وغیرہ

ہم یہ کیسے کریں گے، مجھے ابھی تک کوئی اندازہ نہیں ہے۔ ہم ایک علیحدہ مضمون میں اس کا جائزہ لیں گے۔

زندگی سے ذرا قریب ہو جائیں تو ہم اس کو بیان کر سکتے ہیں۔
لیف سوئچ میں تمام منسلک اسپائن سوئچز کے ساتھ BGP سیشنز ہونے چاہئیں، اس عمل میں جڑے ہوئے نیٹ ورکس کو درآمد کریں، اور اسپائن سوئچز سے صرف ایک مخصوص سابقہ ​​سے نیٹ ورک قبول کریں۔ CoPP IPv6 ND کو 10 pps تک محدود کریں، وغیرہ۔
بدلے میں، ریڑھ کی ہڈی تمام منسلک لیڈز کے ساتھ سیشن منعقد کرتی ہے، جڑ کے عکاس کے طور پر کام کرتی ہے، اور ان سے صرف ایک مخصوص لمبائی کے راستے اور ایک مخصوص کمیونٹی کے ساتھ قبول کرتی ہیں۔

جزو 4: ڈیوائس شروع کرنے کا طریقہ کار

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

1. انوینٹری سسٹم میں ڈیوائس درج کریں۔
2. انتظامی IP پتہ منتخب کریں۔
3. اس تک بنیادی رسائی مرتب کریں:
   میزبان نام، مینجمنٹ IP ایڈریس، مینجمنٹ نیٹ ورک کا راستہ، صارفین، SSH کیز، پروٹوکول - telnet/SSH/NETCONF

تین طریقے ہیں:

• سب کچھ مکمل طور پر دستی ہے۔ ڈیوائس کو اسٹینڈ پر لایا گیا ہے، جہاں ایک عام نامیاتی شخص اسے سسٹم میں داخل کرے گا، کنسول سے جڑے گا اور اسے ترتیب دے گا۔ چھوٹے جامد نیٹ ورکس پر کام کر سکتے ہیں۔
• ZTP - زیرو ٹچ پروویژننگ۔ ہارڈ ویئر پہنچا، کھڑا ہوا، DHCP کے ذریعے ایڈریس موصول ہوا، ایک خاص سرور پر گیا، اور خود کو ترتیب دیا۔
• کنسول سرورز کا بنیادی ڈھانچہ، جہاں ابتدائی کنفیگریشن خودکار موڈ میں کنسول پورٹ کے ذریعے ہوتی ہے۔

ہم تینوں کے بارے میں ایک الگ مضمون میں بات کریں گے۔

جزو 5: وینڈر-ایگنوسٹک کنفیگریشن ماڈل

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

1. آلہ کے ساتھ تعامل کے لیے مخصوص انٹرفیس کے مطابق نہ بنیں۔ CLI، NETCONF، RESTCONF، SNMP ہو - ماڈل ایک جیسا ہوگا۔
2. نیٹ ورک پر دکانداروں کی تعداد کے مطابق ٹیمپلیٹس/اسکرپٹس کی تعداد نہ رکھیں، اور اگر ڈیزائن بدل جائے تو ایک ہی چیز کو کئی جگہوں پر تبدیل کریں۔
3. ڈیوائس (بیک اپ) سے کنفیگریشن لوڈ کریں، اسے بالکل اسی ماڈل میں ڈالیں اور ڈیلٹا کا حساب لگانے کے لیے ٹارگٹ کنفیگریشن کا موجودہ کنفیگریشن سے براہ راست موازنہ کریں اور ایک کنفیگریشن پیچ تیار کریں جو صرف ان حصوں کو تبدیل کرے گا جو ضروری ہیں یا انحراف کی نشاندہی کرنے کے لیے۔

اس مرحلے کے نتیجے میں، ہم وینڈر سے آزاد کنفیگریشن حاصل کرتے ہیں۔

اجزاء 6. وینڈر کے لیے مخصوص ڈرائیور انٹرفیس

آپ کو اپنے آپ کو اس امید کے ساتھ خوشامد نہیں کرنا چاہئے کہ ایک دن یہ ممکن ہو جائے گا کہ سسکا کو بالکل اسی طرح ترتیب دیا جائے جس طرح ایک جونیپر، صرف ان کو بالکل وہی کال بھیج کر۔ وائٹ باکسز کی بڑھتی ہوئی مقبولیت اور NETCONF، RESTCONF، OpenConfig کے لیے تعاون کے ابھرنے کے باوجود، یہ پروٹوکول جو مخصوص مواد فراہم کرتا ہے وہ وینڈر سے وینڈر میں مختلف ہوتا ہے، اور یہ ان کے مسابقتی اختلافات میں سے ایک ہے جسے وہ اتنی آسانی سے ترک نہیں کریں گے۔
یہ تقریباً OpenContrail اور OpenStack جیسا ہی ہے، جن کے پاس نارتھ باؤنڈ انٹرفیس کے طور پر RestAPI ہے، بالکل مختلف کالوں کی توقع کرتے ہیں۔

لہذا، پانچویں مرحلے میں، وینڈر سے آزاد ماڈل کو وہ فارم لینا چاہیے جس میں یہ ہارڈ ویئر پر جائے گا۔
اور یہاں تمام ذرائع اچھے ہیں (نہیں): CLI، NETCONF، RESTCONF، SNMP بس۔

لہذا، ہمیں ایک ڈرائیور کی ضرورت ہوگی جو پچھلے مرحلے کے نتیجے کو کسی مخصوص وینڈر کے مطلوبہ فارمیٹ میں منتقل کرے گا: CLI کمانڈز کا ایک سیٹ، ایک XML ڈھانچہ۔

اجزاء 7. ڈیوائس کو کنفیگریشن فراہم کرنے کا طریقہ کار

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

• CLI (ٹیل نیٹ، ایس ایس ایچ)
• SNMP
• NETCONF
• RESTCONF
• باقی API
• اوپن فلو (حالانکہ یہ ایک آؤٹ لیئر ہے کیونکہ یہ ایف آئی بی ڈیلیور کرنے کا ایک طریقہ ہے، سیٹنگز نہیں)

آئیے یہاں ٹی کو ڈاٹ کرتے ہیں۔ CLI میراث ہے۔ SNMP... کھانسی کھانسی۔
RESTCONF ابھی تک ایک نامعلوم جانور ہے؛ REST API کو تقریباً کوئی بھی سپورٹ نہیں کرتا ہے۔ لہذا، ہم سیریز میں NETCONF پر توجہ مرکوز کریں گے۔

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

دوم، اور ہم یہ کن ٹولز کے ساتھ کریں گے؟
یہاں ایک بڑا انتخاب بھی ہے:

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

یہاں پسندیدہ ابھی تک منتخب نہیں کیا گیا ہے - ہم تلاش کریں گے.

یہاں اور کیا اہم ہے؟ ترتیب کو لاگو کرنے کے نتائج۔
کامیاب ہوا یا نہیں۔ کیا اب بھی ہارڈ ویئر تک رسائی ہے یا نہیں؟
ایسا لگتا ہے کہ کمٹ یہاں اس بات کی تصدیق اور توثیق میں مدد کرے گا کہ ڈیوائس پر کیا ڈاؤن لوڈ کیا گیا تھا۔
یہ، NETCONF کے درست نفاذ کے ساتھ مل کر، مناسب آلات کی حد کو نمایاں طور پر تنگ کرتا ہے - بہت سے مینوفیکچررز عام وعدوں کی حمایت نہیں کرتے ہیں۔ لیکن یہ صرف ایک شرط ہے۔ آر ایف پی. آخر میں، کوئی بھی پریشان نہیں ہے کہ ایک بھی روسی وینڈر 32*100GE انٹرفیس کی شرط کی تعمیل نہیں کرے گا۔ یا وہ پریشان ہے؟

جزو 8۔ CI/CD

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

لیکن، جیسا کہ اوپر کہا جا چکا ہے، ہم کچھ ایسے وحشی نہیں ہیں جو ہر چیز کو سیدھا پروڈکشن میں ڈالنا چاہتے ہیں۔
تیار کردہ کنفیگریشن کو پہلے پائپ لائن CI/CD سے گزرنا چاہیے۔

CI/CD کا مطلب ہے مسلسل انضمام، مسلسل تعیناتی۔ یہ ایک ایسا نقطہ نظر ہے جس میں ٹیم نہ صرف ہر چھ ماہ بعد ایک نئی بڑی ریلیز کرتی ہے، پرانی کو مکمل طور پر تبدیل کرتی ہے، بلکہ چھوٹے حصوں میں باقاعدگی سے بتدریج (تعیناتی) نئی فعالیت کو نافذ کرتی ہے، جن میں سے ہر ایک کو مطابقت، حفاظت اور مکمل طور پر جانچا جاتا ہے۔ کارکردگی (انٹیگریشن)۔

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

ڈیبگنگ کمانڈز کے استثناء کے ساتھ، نیٹ ورک پر بالکل تمام تبدیلیاں CI/CD پائپ لائن کے ذریعے ہونی چاہئیں - یہ ہماری پرسکون زندگی اور طویل، خوشگوار کیریئر کی ضمانت ہے۔

اجزاء 9. بیک اپ اور بے ضابطگی کا پتہ لگانے کا نظام

ٹھیک ہے، بیک اپ کے بارے میں دوبارہ بات کرنے کی ضرورت نہیں ہے۔
ہم انہیں صرف گٹ میں کراؤن کے مطابق یا کنفیگریشن تبدیلی کی حقیقت پر ڈالیں گے۔

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

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

مثال کے طور پر، کسی مسئلے کو مقامی بنانے کے لیے فی مخصوص IP پیکٹوں کی تعداد کو گننے کے لیے فائر وال کا اصول ایک مکمل طور پر عام عارضی ترتیب ہے۔

جزو 10. نگرانی کا نظام

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

ارتقائی سوچ CI/CD عمل کا ایک نامیاتی حصہ ہے۔ نیٹ ورک پر کنفیگریشن کو رول آؤٹ کرنے کے بعد، ہمیں اس بات کا تعین کرنے کے قابل ہونے کی ضرورت ہے کہ اب اس کے ساتھ سب کچھ ٹھیک ہے یا نہیں۔
اور ہم نہ صرف بات کر رہے ہیں اور نہ صرف انٹرفیس کے استعمال کے نظام الاوقات یا نوڈ کی دستیابی کے بارے میں، بلکہ مزید باریک چیزوں کے بارے میں - ضروری راستوں کی موجودگی، ان پر خصوصیات، BGP سیشنز کی تعداد، OSPF پڑوسی، اختتام سے آخر تک کی کارکردگی۔ حد سے زیادہ خدمات کی.
کیا بیرونی سرور پر syslogs کا اضافہ ہونا بند ہو گیا، یا SFlow ایجنٹ ٹوٹ گیا، یا کیا قطاروں میں قطرے بڑھنے لگے، یا کیا کچھ جوڑے کے سابقوں کے درمیان رابطہ ٹوٹ گیا؟

اس پر ہم ایک الگ مضمون میں غور کریں گے۔

حاصل يہ ہوا

بنیاد کے طور پر، میں نے جدید ڈیٹا سینٹر نیٹ ورک ڈیزائنز میں سے ایک کا انتخاب کیا - BGP کے ساتھ L3 Clos Fabric روٹنگ پروٹوکول کے طور پر۔
اس بار ہم جونیپر پر نیٹ ورک بنائیں گے، کیونکہ اب JunOs انٹرفیس ایک وین لو ہے۔

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

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

اور ہاں، میں تیار حل کے ساتھ اس چکر کو خوبصورتی سے ختم کرنے کا وعدہ نہیں کرتا۔ 🙂

کارآمد ویب سائٹس

• سیریز میں جانے سے پہلے، نتاشا سموئلینکو کی کتاب پڑھنے کے قابل ہے۔ نیٹ ورک انجینئرز کے لیے ازگر. اور شاید گزر جائے۔ کورس.
• پڑھنا بھی مفید رہے گا۔ RFC پیٹر لاپوخوف کے ذریعے فیس بک سے ڈیٹا سینٹر فیکٹریوں کے ڈیزائن کے بارے میں۔
• فن تعمیر کی دستاویزات آپ کو اندازہ دے گی کہ اوورلے SDN کیسے کام کرتا ہے۔ ٹنگسٹن فیبرک (پہلے اوپن کنٹریل)۔

شکریہ

رومن گورج۔ تبصرے اور ترمیم کے لیے۔
آرٹیوم چرنوبے۔ KDPV کے لیے۔

ماخذ: www.habr.com