SDSM تمام شده است، اما میل غیرقابل کنترل برای نوشتن باقی مانده است.

برادرمان سال‌ها از انجام کارهای معمولی، ضربدری انگشتان قبل از ارتکاب و کمبود خواب به دلیل عقب‌نشینی‌های شبانه رنج می‌برد.
اما دوران تاریک رو به پایان است.

با این مقاله من یک سری در مورد چگونگی شروع خواهم کرد به من اتوماسیون دیده می شود.
در طول مسیر، ما مراحل اتوماسیون، ذخیره متغیرها، رسمی کردن طراحی، RestAPI، NETCONF، YANG، YDK را درک خواهیم کرد و برنامه نویسی زیادی انجام خواهیم داد.
به من به این معنی است که الف) حقیقتی عینی نیست، ب) بدون قید و شرط بهترین رویکرد نیست، ج) نظر من، حتی در طول حرکت از مقاله اول تا آخرین مقاله، می تواند تغییر کند - صادقانه بگویم، از مرحله پیش نویس به انتشار، من همه چیز را به طور کامل دو بار بازنویسی کردم.

مقدار

1. اهداف
   1. شبکه مانند یک موجود زنده است
   2. تست پیکربندی
   3. نسخه سازی
   4. نظارت و خوددرمانی خدمات

2. وجوه
   1. سیستم موجودی
   2. سیستم مدیریت فضای IP
   3. سیستم شرح خدمات شبکه
   4. مکانیزم اولیه سازی دستگاه
   5. مدل پیکربندی فروشنده-اگنوستیک
   6. رابط راننده مخصوص فروشنده
   7. مکانیزم برای تحویل پیکربندی به دستگاه
   8. CI / CD
   9. مکانیزم برای پشتیبان گیری و جستجوی انحرافات
   10. سیستم نظارت

3. نتیجه

من سعی خواهم کرد ADSM را در قالبی متفاوت از SDSM انجام دهم. مقالات بزرگ، دقیق و شماره گذاری شده همچنان ظاهر می شوند، و در بین آنها یادداشت های کوچکی از تجربیات روزمره منتشر خواهم کرد. من سعی می کنم اینجا با کمال گرایی مبارزه کنم و تک تک آنها را لیس ندهم.

چقدر خنده دار است که بار دوم باید همان مسیر را طی کنی.

در ابتدا مجبور شدم خودم مقاله هایی در مورد شبکه ها بنویسم به دلیل اینکه آنها در RuNet نبودند.

اکنون نتوانستم سند جامعی پیدا کنم که رویکردهای اتوماسیون را نظام‌مند کند و فناوری‌های فوق را با استفاده از مثال‌های عملی ساده تحلیل کند.

من ممکن است اشتباه کنم، پس لطفا لینک منابع مفید را ارائه دهید. با این حال، این تصمیم من برای نوشتن را تغییر نمی دهد، زیرا هدف اصلی این است که خودم چیزی یاد بگیرم و آسان کردن زندگی برای دیگران یک امتیاز خوشایند است که ژن به اشتراک گذاری تجربه را نوازش می دهد.

ما سعی خواهیم کرد یک مرکز داده LAN DC با اندازه متوسط ​​بگیریم و کل طرح اتوماسیون را انجام دهیم.
من تقریباً برای اولین بار با شما برخی کارها را انجام خواهم داد.

من در ایده ها و ابزارهایی که در اینجا توضیح داده شده است اصیل نخواهم بود. دیمیتری فیگول یک عملکرد عالی دارد کانال با جریان در این موضوع.
مقالات از بسیاری جهات با آنها همپوشانی دارند.

LAN DC دارای 4 DC، حدود 250 سوئیچ، نیم دوجین روتر و چند فایروال است.
فیس بوک نیست، اما به اندازه ای است که شما را وادار کند عمیقاً در مورد اتوماسیون فکر کنید.
با این حال، این نظر وجود دارد که اگر بیش از 1 دستگاه دارید، از قبل به اتوماسیون نیاز است.
در واقع، تصور اینکه اکنون هر کسی بتواند بدون حداقل یک بسته اسکریپت زانویی زندگی کند، سخت است.
اگرچه شنیدم دفاتری وجود دارند که آدرس های IP در اکسل نگهداری می شوند و هر یک از هزاران دستگاه شبکه به صورت دستی پیکربندی شده اند و پیکربندی منحصر به فرد خود را دارند. البته این را می توان به عنوان هنر مدرن رد کرد ، اما احساسات مهندس قطعاً توهین می شود.

اهداف

اکنون انتزاعی ترین اهداف را تعیین می کنیم:

• شبکه مانند یک موجود زنده است
• تست پیکربندی
• نسخه سازی وضعیت شبکه
• نظارت و خوددرمانی خدمات

در ادامه این مقاله به این خواهیم پرداخت که از چه وسایلی استفاده خواهیم کرد و در ادامه اهداف و وسایل را به تفصیل بررسی خواهیم کرد.

شبکه مانند یک موجود زنده است

عبارت تعیین کننده سریال، اگرچه در نگاه اول ممکن است چندان مهم به نظر نرسد: ما شبکه را پیکربندی خواهیم کرد، نه دستگاه های جداگانه.
در سال‌های اخیر، ما شاهد تغییری در تاکید به سمت تلقی شبکه به عنوان یک موجودیت واحد بوده‌ایم، از این رو شبکه تعریف شده توسط نرم افزار, شبکه های هدف محور и شبکه های خودمختار.
به هر حال، برنامه‌ها در سطح جهانی به چه چیزی از شبکه نیاز دارند: اتصال بین نقاط A و B (خوب، گاهی اوقات + B-Z) و جداسازی از سایر برنامه‌ها و کاربران.

و بنابراین وظیفه ما در این سریال این است یک سیستم بسازید، حفظ پیکربندی فعلی کل شبکه، که قبلاً به پیکربندی واقعی هر دستگاه مطابق با نقش و مکان آن تجزیه شده است.
سیستم مدیریت شبکه به این معنی است که برای ایجاد تغییرات با آن تماس می گیریم و آن نیز به نوبه خود وضعیت مورد نظر را برای هر دستگاه محاسبه کرده و آن را پیکربندی می کند.
به این ترتیب، دسترسی دستی به CLI را تقریباً به صفر می‌رسانیم - هر گونه تغییر در تنظیمات دستگاه یا طراحی شبکه باید رسمی و مستند شود - و تنها پس از آن به عناصر ضروری شبکه منتقل می‌شود.

به عنوان مثال، اگر ما تصمیم گرفتیم که از این پس سوئیچ های رک در کازان به جای یک شبکه، دو شبکه را اعلام کنند، ما

1. ابتدا تغییرات سیستم ها را مستند می کنیم
2. ایجاد پیکربندی هدف تمام دستگاه های شبکه
3. ما برنامه به‌روزرسانی پیکربندی شبکه را راه‌اندازی می‌کنیم، که محاسبه می‌کند چه چیزی باید از هر گره حذف شود، چه چیزی اضافه شود، و گره‌ها را به حالت دلخواه می‌رساند.

در عین حال تغییرات را فقط در مرحله اول به صورت دستی انجام می دهیم.

تست پیکربندی

شناخته شده استکه 80٪ از مشکلات در هنگام تغییر پیکربندی رخ می دهد - شواهد غیرمستقیم این است که در تعطیلات سال نو همه چیز معمولاً آرام است.
من شخصا شاهد ده‌ها خرابی جهانی به دلیل خطای انسانی بوده‌ام: دستور اشتباه، پیکربندی در شعبه اشتباهی اجرا شد، انجمن فراموش کرد، MPLS به صورت جهانی روی روتر حذف شد، پنج قطعه سخت‌افزار پیکربندی شد، اما خطا نبود. در ششم مشاهده شد، تغییرات قدیمی ایجاد شده توسط شخص دیگری انجام شد. انبوهی از سناریوها وجود دارد.

اتوماسیون به ما این امکان را می دهد که اشتباهات کمتری داشته باشیم، اما در مقیاس بزرگتر. به این ترتیب می توانید نه تنها یک دستگاه، بلکه کل شبکه را به طور همزمان آجر کنید.

از زمان های بسیار قدیم، پدربزرگ های ما صحت تغییرات ایجاد شده را با نگاه دقیق، توپ های فولادی و عملکرد شبکه پس از راه اندازی بررسی می کردند.
آن پدربزرگ‌هایی که کارشان منجر به از کار افتادگی و تلفات فاجعه‌بار شد، فرزندان کمتری بر جای گذاشتند و باید به مرور زمان از بین بروند، اما تکامل فرآیندی کند است و بنابراین همه هنوز در ابتدا تغییرات را در آزمایشگاه آزمایش نمی‌کنند.
با این حال، در خط مقدم پیشرفت کسانی هستند که فرآیند آزمایش پیکربندی و کاربرد بیشتر آن در شبکه را خودکار کرده اند. به عبارت دیگر، من روش CI/CD را قرض گرفتم (یکپارچه سازی مداوم، استقرار مداوم) از توسعه دهندگان.
در یکی از قسمت ها به نحوه پیاده سازی این با استفاده از یک سیستم کنترل نسخه، احتمالاً Github، خواهیم پرداخت.

هنگامی که به ایده شبکه CI/CD عادت کردید، یک شبه روش بررسی یک پیکربندی با اعمال آن در یک شبکه تولید مانند ناآگاهی اولیه قرون وسطی به نظر می رسد. مثل ضربه زدن به کلاهک با چکش.

ادامه ارگانیک ایده ها در مورد سیستم مدیریت شبکه و CI/CD تبدیل به یک نسخه کامل از پیکربندی می شود.

نسخه سازی

ما فرض می کنیم که با هر تغییری، حتی جزئی ترین آنها، حتی در یک دستگاه غیرقابل توجه، کل شبکه از یک حالت به حالت دیگر حرکت می کند.
و همیشه دستوری را روی دستگاه اجرا نمی کنیم، وضعیت شبکه را تغییر می دهیم.
پس بیایید این حالت ها را نسخه ها بنامیم؟

فرض کنید نسخه فعلی 1.0.0 است.
آیا آدرس IP رابط Loopback در یکی از ToR ها تغییر کرده است؟ این یک نسخه کوچک است و شماره آن 1.0.1 خواهد بود.
ما سیاست‌های وارد کردن مسیرها به BGP را - کمی جدی‌تر - قبلاً 1.1.0 اصلاح کردیم.
ما تصمیم گرفتیم از شر IGP خلاص شویم و فقط به BGP برویم - این یک تغییر اساسی در طراحی است - 2.0.0.

در همان زمان، DC های مختلف ممکن است نسخه های مختلفی داشته باشند - شبکه در حال توسعه است، تجهیزات جدید در حال نصب هستند، سطوح جدیدی از ستون ها در جایی اضافه می شوند، نه در دیگران و غیره.

بر نسخه سازی معنایی در مقاله ای جداگانه صحبت خواهیم کرد.

تکرار می کنم - هر تغییری (به جز دستورات اشکال زدایی) به روز رسانی نسخه است. مدیران باید از هرگونه انحراف از نسخه فعلی مطلع شوند.

همین امر در مورد بازگرداندن تغییرات نیز صدق می کند - این به معنای لغو آخرین دستورات نیست، این یک بازگشت با استفاده از سیستم عامل دستگاه نیست - این کار کل شبکه را به نسخه جدید (قدیمی) می آورد.

نظارت و خوددرمانی خدمات

این وظیفه بدیهی در شبکه های مدرن به سطح جدیدی رسیده است.
اغلب، ارائه دهندگان خدمات بزرگ به جای اینکه بفهمند چه اتفاقی افتاده است، این رویکرد را اتخاذ می کنند که یک سرویس ناموفق باید خیلی سریع تعمیر شود و سرویس جدیدی مطرح شود.
"بسیار" به این معنی است که شما باید سخاوتمندانه از همه طرف با نظارت پوشانده شوید، که در عرض چند ثانیه کوچکترین انحراف از هنجار را تشخیص می دهد.
و در اینجا معیارهای معمول، مانند بارگیری رابط یا در دسترس بودن گره، دیگر کافی نیستند. نظارت دستی آنها توسط افسر وظیفه نیز کافی نیست.
برای خیلی چیزها باید وجود داشته باشد خود درمانی - چراغ‌های مانیتورینگ قرمز شدند و ما رفتیم و چنار را در جایی که درد داشت، گذاشتیم.

و در اینجا ما نه تنها دستگاه‌های جداگانه، بلکه سلامت کل شبکه را نیز رصد می‌کنیم، هم whitebox که نسبتاً قابل درک است و هم blackbox که پیچیده‌تر است.

برای اجرای چنین طرح های بلندپروازانه ای به چه چیزهایی نیاز خواهیم داشت؟

• فهرستی از تمام دستگاه‌های موجود در شبکه، موقعیت مکانی، نقش‌ها، مدل‌ها، نسخه‌های نرم‌افزار را داشته باشید.
  kazan-leaf-1.lmu.net, Kazan, leaf, Juniper QFX 5120, R18.3.
• سیستمی برای توصیف خدمات شبکه داشته باشید.
  IGP، BGP، L2/3VPN، خط مشی، ACL، NTP، SSH.
• بتوانید دستگاه را مقداردهی اولیه کنید.
  نام میزبان، Mgmt IP، Mgmt Route، کاربران، RSA-Keys، LLDP، NETCONF
• دستگاه را پیکربندی کنید و پیکربندی را به نسخه دلخواه (از جمله قدیمی) بیاورید.
• پیکربندی تست
• به طور دوره ای وضعیت همه دستگاه ها را برای انحراف از دستگاه های فعلی بررسی کنید و به چه کسی باید گزارش دهید.
  یک شبه، شخصی بی سر و صدا یک قانون را به ACL اضافه کرد.
• نظارت بر عملکرد

وجوه

به نظر می رسد آنقدر پیچیده به نظر می رسد که شروع به تجزیه پروژه به اجزاء کند.

و ده نفر از آنها خواهد بود:

1. سیستم موجودی
2. سیستم مدیریت فضای IP
3. سیستم شرح خدمات شبکه
4. مکانیزم اولیه سازی دستگاه
5. مدل پیکربندی فروشنده-اگنوستیک
6. رابط راننده مخصوص فروشنده
7. مکانیزم برای تحویل پیکربندی به دستگاه
8. CI / CD
9. مکانیزم برای پشتیبان گیری و جستجوی انحرافات
10. سیستم نظارت

به هر حال، این نمونه ای از نحوه تغییر دیدگاه در مورد اهداف چرخه است - 4 جزء در پیش نویس وجود داشت.

در تصویر تمام اجزا و خود دستگاه را به تصویر کشیدم.
اجزای متقاطع با یکدیگر تعامل دارند.
هر چه بلوک بزرگتر باشد، باید به این جزء توجه بیشتری شود.

جزء 1: سیستم موجودی

بدیهی است که ما می خواهیم بدانیم چه تجهیزاتی در کجا قرار دارند، به چه چیزی متصل هستند.
سیستم موجودی جزء لاینفک هر شرکتی است.
اغلب، یک شرکت دارای یک سیستم موجودی جداگانه برای دستگاه های شبکه است که مشکلات خاص تری را حل می کند.
به عنوان بخشی از این سری مقالات، آن را DCIM - مدیریت زیرساخت مرکز داده می نامیم. اگرچه خود اصطلاح DCIM، به طور دقیق، موارد بیشتری را شامل می شود.

برای اهداف خود، ما اطلاعات زیر را در مورد دستگاه در آن ذخیره می کنیم:

• شماره موجودی
• عنوان/توضیحات
• مدل (Huawei CE12800، Juniper QFX5120 و غیره.)
• پارامترهای مشخصه (بردها، رابط ها و غیره)
• نقش (برگ، ستون فقرات، روتر مرزی و غیره)
• محل (منطقه، شهر، مرکز داده، رک، واحد)
• اتصالات بین دستگاه ها
• توپولوژی شبکه

کاملاً واضح است که ما خودمان می خواهیم همه اینها را بدانیم.
اما آیا این به اهداف اتوماسیون کمک می کند؟
بدیهی.
به عنوان مثال، ما می دانیم که در یک مرکز داده معین روی سوئیچ های Leaf، اگر هواوی باشد، ACL برای فیلتر کردن ترافیک خاص باید روی VLAN اعمال شود و اگر Juniper است، سپس روی واحد 0 رابط فیزیکی اعمال شود.
یا باید یک سرور Syslog جدید در تمام مرزهای منطقه راه اندازی کنید.

در آن ما دستگاه های شبکه مجازی، به عنوان مثال روترهای مجازی یا بازتابنده های ریشه را ذخیره خواهیم کرد. ما می‌توانیم سرورهای DNS، NTP، Syslog و به‌طور کلی هر چیزی را که به هر طریقی به شبکه مربوط می‌شود، اضافه کنیم.

جزء 2: سیستم مدیریت فضای IP

بله، و امروزه تیم هایی از افراد وجود دارند که پیشوندها و آدرس های IP را در یک فایل اکسل پیگیری می کنند. اما رویکرد مدرن هنوز یک پایگاه داده است، با یک front-end در nginx/apache، API و توابع گسترده برای ضبط آدرس های IP و شبکه های تقسیم شده به VRF.
IPAM - مدیریت آدرس IP.

برای اهداف خود، ما اطلاعات زیر را در آن ذخیره می کنیم:

• VLAN ها
• VRF
• شبکه ها/زیر شبکه ها
• آدرس های IP
• اتصال آدرس ها به دستگاه ها، شبکه ها به مکان ها و شماره های VLAN

دوباره، واضح است که ما می‌خواهیم مطمئن شویم که وقتی یک آدرس IP جدید را برای Loopback ToR اختصاص می‌دهیم، از این واقعیت که قبلاً به شخصی اختصاص داده شده است، دچار مشکل نشویم. یا اینکه از یک پیشوند دو بار در انتهای مختلف شبکه استفاده کردیم.
اما این چگونه به اتوماسیون کمک می کند؟
آسان است
ما یک پیشوند در سیستم با نقش Loopbacks درخواست می‌کنیم که حاوی آدرس‌های IP موجود برای تخصیص است - اگر پیدا شد، آدرس را اختصاص می‌دهیم، اگر نه، درخواست ایجاد یک پیشوند جدید می‌کنیم.
یا هنگام ایجاد یک پیکربندی دستگاه، می توانیم از همان سیستم بفهمیم که رابط VRF باید در آن قرار گیرد.
و هنگام راه اندازی یک سرور جدید، اسکریپت وارد سیستم می شود، متوجه می شود که سرور در کدام سوئیچ است، کدام پورت و کدام زیرشبکه به رابط اختصاص داده شده است - و آدرس سرور را از آن اختصاص می دهد.

این نشان دهنده تمایل به ترکیب DCIM و IPAM در یک سیستم است تا توابع تکراری و سرویس دهی به دو نهاد مشابه نباشد.
این کاری است که ما انجام خواهیم داد.

جزء 3. سیستم برای توصیف خدمات شبکه

اگر دو سیستم اول متغیرهایی را ذخیره می کنند که هنوز باید به نحوی مورد استفاده قرار گیرند، سیستم سوم برای هر نقش دستگاه توضیح می دهد که چگونه باید پیکربندی شود.
ارزش تمایز دو نوع مختلف خدمات شبکه را دارد:

• زیر ساخت
• مشتری.

اولی برای ارائه اتصال اولیه و کنترل دستگاه طراحی شده است. اینها عبارتند از VTY، SNMP، NTP، Syslog، AAA، پروتکل های مسیریابی، CoPP و غیره.
دومی خدمات را برای مشتری سازماندهی می کند: MPLS L2/L3VPN، GRE، VXLAN، VLAN، L2TP و غیره.
البته، موارد مرزی نیز وجود دارد - MPLS LDP، BGP کجا را شامل شود؟ بله، و پروتکل های مسیریابی را می توان برای کلاینت ها استفاده کرد. اما این مهم نیست.

هر دو نوع سرویس به تنظیمات اولیه تجزیه می شوند:

• رابط های فیزیکی و منطقی (برچسب/انتگ، mtu)
• آدرس های IP و VRF ها (IP، IPv6، VRF)
• ACL ها و سیاست های پردازش ترافیک
• پروتکل ها (IGP، BGP، MPLS)
• خط مشی های مسیریابی (لیست های پیشوند، جوامع، فیلترهای ASN).
• خدمات ابزار (SSH، NTP، LLDP، Syslog...)
• و غیره.

دقیقاً چگونه این کار را انجام خواهیم داد، من هنوز هیچ ایده ای ندارم. در مقاله ای جداگانه به بررسی آن خواهیم پرداخت.

اگر کمی به زندگی نزدیک‌تر باشیم، می‌توانیم آن را توصیف کنیم
سوئیچ Leaf باید جلسات BGP را با تمام سوئیچ‌های Spine متصل داشته باشد، شبکه‌های متصل را به فرآیند وارد کند و فقط شبکه‌هایی را از یک پیشوند خاص از سوئیچ‌های Spine بپذیرد. CoPP IPv6 ND را به 10 pps و غیره محدود کنید.
به نوبه خود، خارها جلساتی را با تمام سرنخ های متصل برگزار می کنند و به عنوان بازتاب دهنده ریشه عمل می کنند و از آنها فقط مسیرهایی با طول معین و با یک جامعه خاص را می پذیرند.

جزء 4: مکانیسم راه‌اندازی دستگاه

تحت این عنوان، من بسیاری از اقداماتی را که باید رخ دهد تا یک دستگاه در رادار ظاهر شود و از راه دور به آن دسترسی پیدا کند، ترکیب می کنم.

1. دستگاه را در سیستم موجودی وارد کنید.
2. یک آدرس IP مدیریت انتخاب کنید.
3. دسترسی اولیه به آن را تنظیم کنید:
   نام میزبان، آدرس IP مدیریت، مسیر به شبکه مدیریت، کاربران، کلیدهای SSH، پروتکل ها - telnet/SSH/NETCONF

سه رویکرد وجود دارد:

• همه چیز کاملا دستی است. دستگاه به جایگاه آورده می شود، جایی که یک فرد معمولی ارگانیک آن را وارد سیستم می کند، به کنسول متصل می شود و آن را پیکربندی می کند. می تواند روی شبکه های استاتیک کوچک کار کند.
• ZTP - Zero Touch Provisioning. سخت افزار رسید، ایستاد، یک آدرس از طریق DHCP دریافت کرد، به یک سرور ویژه رفت و خودش را پیکربندی کرد.
• زیرساخت سرورهای کنسول، که در آن پیکربندی اولیه از طریق پورت کنسول در حالت خودکار انجام می شود.

در مقاله ای جداگانه در مورد هر سه صحبت خواهیم کرد.

جزء 5: مدل پیکربندی فروشنده-اگنوستیک

تا به حال، همه سیستم‌ها وصله‌های ناهمگونی بوده‌اند که متغیرها و توصیفی اعلامی از آنچه می‌خواهیم در شبکه ببینیم ارائه می‌دهند. اما دیر یا زود، شما باید با موارد خاص کنار بیایید.
در این مرحله، برای هر دستگاه خاص، اولیه‌ها، سرویس‌ها و متغیرها در یک مدل پیکربندی ترکیب می‌شوند که در واقع پیکربندی کامل یک دستگاه خاص را فقط به شیوه‌ای خنثی از فروشنده توصیف می‌کند.
این مرحله چه کاری انجام می دهد؟ چرا بلافاصله یک پیکربندی دستگاه ایجاد نمی کنید که بتوانید به سادگی آن را آپلود کنید؟
در واقع این سه مشکل را حل می کند:

1. برای تعامل با دستگاه خود را با یک رابط خاص سازگار نکنید. CLI، NETCONF، RESTCONF، SNMP - مدل یکسان خواهد بود.
2. تعداد قالب ها/اسکریپت ها را با توجه به تعداد فروشنده های موجود در شبکه نگه ندارید و در صورت تغییر طراحی، همان چیزی را در چندین مکان تغییر دهید.
3. پیکربندی را از دستگاه بارگیری کنید (پشتیبان گیری)، آن را دقیقاً در همان مدل قرار دهید و مستقیماً پیکربندی هدف را با پیکربندی موجود مقایسه کنید تا دلتا را محاسبه کنید و یک پچ پیکربندی تهیه کنید که فقط آن قسمت هایی را که لازم است یا برای شناسایی انحرافات تغییر می دهد.

در نتیجه این مرحله، یک پیکربندی مستقل از فروشنده به دست می آوریم.

جزء 6. رابط راننده خاص فروشنده

شما نباید با این امید که روزی می‌توانید یک ciska را دقیقاً به همان روش Juniper پیکربندی کنید، به سادگی با ارسال دقیقاً همان تماس‌ها به آنها، خود را متملق کنید. با وجود محبوبیت روزافزون وایت باکس ها و ظهور پشتیبانی از NETCONF، RESTCONF، OpenConfig، محتوای خاصی که این پروتکل ها ارائه می دهند از فروشنده ای به فروشنده دیگر متفاوت است و این یکی از تفاوت های رقابتی آنهاست که به این راحتی از آن دست نخواهند داد.
این تقریباً مشابه OpenContrail و OpenStack است که RestAPI را به عنوان رابط NorthBound خود دارند و انتظار تماس‌های کاملاً متفاوتی دارند.

بنابراین، در مرحله پنجم، مدل مستقل از فروشنده باید به شکلی باشد که به سمت سخت افزار می رود.
و در اینجا همه ابزارها خوب هستند (نه): CLI، NETCONF، RESTCONF، SNMP به سادگی.

بنابراین، ما به درایوری نیاز داریم که نتیجه مرحله قبل را به فرمت مورد نیاز یک فروشنده خاص منتقل کند: مجموعه ای از دستورات CLI، یک ساختار XML.

جزء 7. مکانیزم برای تحویل پیکربندی به دستگاه

ما پیکربندی را ایجاد کرده‌ایم، اما هنوز باید به دستگاه‌ها تحویل داده شود - و بدیهی است که نه با دست.
اولا، با این سوال مواجه هستیم که از چه حمل و نقلی استفاده خواهیم کرد؟ و امروز انتخاب دیگر کوچک نیست:

• CLI (تلنت، ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (اگرچه یک دور از ذهن است زیرا راهی برای ارائه FIB است نه تنظیمات)

بیایید t را در اینجا نقطه گذاری کنیم. CLI میراث است. SNMP ... سرفه سرفه.
RESTCONF هنوز یک حیوان ناشناخته است؛ REST API تقریباً توسط هیچکس پشتیبانی نمی شود. بنابراین، ما در این سری بر روی NETCONF تمرکز خواهیم کرد.

در واقع، همانطور که خواننده قبلاً فهمیده است، در این مرحله ما قبلاً در مورد رابط تصمیم گرفته ایم - نتیجه مرحله قبلی قبلاً در قالب رابط انتخاب شده ارائه شده است.

دومین بارو با چه ابزاری این کار را انجام خواهیم داد؟
همچنین یک انتخاب بزرگ در اینجا وجود دارد:

• فیلمنامه یا پلتفرم خودنویس. بیایید خود را با ncclient و asyncIO مسلح کنیم و همه کارها را خودمان انجام دهیم. ساختن یک سیستم استقرار از ابتدا برای ما چه هزینه ای دارد؟
• Ansible با کتابخانه غنی ماژول های شبکه.
• نمک با کار ناچیزش با شبکه و ارتباط با ناپالم.
• در واقع ناپالم، که چند فروشنده را می شناسد و بس، خداحافظ.
• نورنیر حیوان دیگری است که در آینده آن را تشریح خواهیم کرد.

در اینجا مورد علاقه هنوز انتخاب نشده است - ما جستجو خواهیم کرد.

چه چیز دیگری در اینجا مهم است؟ پیامدهای اعمال پیکربندی.
موفق بوده یا نه. آیا هنوز دسترسی به سخت افزار وجود دارد یا خیر؟
به نظر می رسد که commit در اینجا به تأیید و تأیید آنچه در دستگاه دانلود شده است کمک می کند.
این، همراه با اجرای صحیح NETCONF، به طور قابل توجهی محدوده دستگاه های مناسب را محدود می کند - تولیدکنندگان زیادی از تعهدات عادی پشتیبانی نمی کنند. اما این تنها یکی از پیش نیازهاست RFP. در پایان، هیچ کس نگران این نیست که حتی یک فروشنده روسی شرایط رابط 32*100GE را رعایت نکند. یا او نگران است؟

جزء 8. CI/CD

در این مرحله، ما از قبل پیکربندی را برای تمام دستگاه های شبکه آماده کرده ایم.
من "برای همه چیز" می نویسم زیرا ما در مورد نسخه سازی وضعیت شبکه صحبت می کنیم. و حتی اگر نیاز به تغییر تنظیمات فقط یک سوئیچ داشته باشید، تغییرات برای کل شبکه محاسبه می شود. بدیهی است که آنها می توانند برای اکثر گره ها صفر باشند.

اما، همانطور که قبلاً در بالا گفته شد، ما نوعی بربر نیستیم که بخواهیم همه چیز را مستقیماً وارد تولید کنیم.
پیکربندی ایجاد شده باید ابتدا از طریق Pipeline CI/CD انجام شود.

CI/CD مخفف Continuous Integration، Continuous Deployment است. این رویکردی است که در آن تیم نه تنها یک نسخه اصلی جدید را هر شش ماه یکبار منتشر می‌کند و به طور کامل جایگزین نسخه قبلی می‌شود، بلکه به طور منظم عملکردهای جدید (استقرار) را در بخش‌های کوچک پیاده‌سازی می‌کند، که هر کدام به طور جامع از نظر سازگاری، امنیت و تست شده است. عملکرد (ادغام).

برای انجام این کار، ما یک سیستم کنترل نسخه داریم که تغییرات پیکربندی را نظارت می کند، یک آزمایشگاه که بررسی می کند آیا سرویس مشتری خراب است، یک سیستم نظارتی که این واقعیت را بررسی می کند، و آخرین مرحله ایجاد تغییرات در شبکه تولید است.

به استثنای دستورات اشکال زدایی، مطلقاً همه تغییرات در شبکه باید از طریق خط لوله CI/CD انجام شود - این تضمین ما برای یک زندگی آرام و یک حرفه طولانی و شاد است.

جزء 9. پشتیبان گیری و سیستم تشخیص ناهنجاری

خب، دیگر نیازی به صحبت در مورد پشتیبان گیری نیست.
ما به سادگی آنها را با توجه به تاج یا با توجه به تغییر پیکربندی در git قرار می دهیم.

اما بخش دوم جالب تر است - کسی باید مراقب این نسخه های پشتیبان باشد. و در برخی موارد، این شخص باید برود و همه چیز را همانطور که بوده بچرخاند، و در موارد دیگر، به کسی میو کند که چیزی اشتباه است.
به عنوان مثال، اگر کاربر جدیدی ظاهر شده است که در متغیرها ثبت نشده است، باید او را از هک حذف کنید. و اگر بهتر است یک قانون جدید فایروال را لمس نکنید، ممکن است شخصی به تازگی اشکال زدایی را روشن کرده باشد یا شاید سرویس جدید، یک بانگلر، طبق مقررات ثبت نشده باشد، اما افراد قبلاً به آن ملحق شده اند.

علیرغم هرگونه سیستم اتوماسیون و دست پولادین مدیریت، ما هنوز از دلتای کوچکی در مقیاس کل شبکه فرار نخواهیم کرد. برای رفع اشکال، هیچ کس پیکربندی را به سیستم اضافه نمی کند. علاوه بر این، آنها حتی ممکن است در مدل پیکربندی گنجانده نشوند.

به عنوان مثال، یک قانون فایروال برای شمارش تعداد بسته ها در هر IP خاص برای بومی سازی یک مشکل، یک پیکربندی موقت کاملا معمولی است.

جزء 10. سیستم نظارت

در ابتدا قصد نداشتم موضوع نظارت را پوشش دهم - این هنوز یک موضوع حجیم، بحث برانگیز و پیچیده است. اما با پیشرفت کار، مشخص شد که این بخش جدایی ناپذیر اتوماسیون است. و دور زدن آن حتی بدون تمرین غیرممکن است.

تفکر در حال تکامل بخشی ارگانیک از فرآیند CI/CD است. پس از ارائه پیکربندی به شبکه، باید بتوانیم تشخیص دهیم که آیا اکنون همه چیز با آن درست است یا خیر.
و ما نه تنها در مورد برنامه های استفاده از رابط یا در دسترس بودن گره صحبت می کنیم، بلکه در مورد چیزهای ظریف تر - وجود مسیرهای لازم، ویژگی های روی آنها، تعداد جلسات BGP، همسایگان OSPF، عملکرد End-to-End صحبت می کنیم. خدمات فراگیر
آیا syslogs به سرور خارجی اضافه نمی‌شود، یا عامل SFlow خراب می‌شود، یا افت صف‌ها شروع به رشد می‌کند، یا اتصال بین برخی از جفت پیشوندها خراب می‌شود؟

در مقاله ای جداگانه به این موضوع خواهیم پرداخت.

نتیجه

به عنوان پایه، یکی از طراحی های مدرن شبکه مرکز داده - L3 Clos Fabric با BGP را به عنوان پروتکل مسیریابی انتخاب کردم.
این بار ما شبکه را بر روی Juniper خواهیم ساخت، زیرا اکنون رابط JunOs یک vanlove است.

بیایید زندگی خود را با استفاده از ابزارهای منبع باز و شبکه چند فروشنده دشوارتر کنیم - بنابراین علاوه بر Juniper، یک فرد خوش شانس دیگر را نیز در این راه انتخاب خواهم کرد.

برنامه برای انتشارات آینده چیزی شبیه به این است:
ابتدا در مورد شبکه های مجازی صحبت می کنم. اولاً به این دلیل که من می خواهم و دوم اینکه بدون این، طراحی شبکه زیرساخت چندان واضح نخواهد بود.
سپس در مورد خود طراحی شبکه: توپولوژی، مسیریابی، سیاست ها.
بیایید یک پایه آزمایشگاهی جمع کنیم.
بیایید در مورد آن فکر کنیم و شاید مقداردهی اولیه دستگاه را در شبکه تمرین کنیم.
و سپس در مورد هر جزء با جزئیات دقیق.

و بله، من قول نمی دهم که این چرخه را با یک راه حل آماده پایان دهم. 🙂

لینک های مفید

• قبل از پرداختن به سریال، ارزش خواندن کتاب ناتاشا سامویلنکو را دارد پایتون برای مهندسان شبکه. و شاید بگذرد دوره.
• خواندن آن نیز مفید خواهد بود RFC درباره طراحی کارخانه های مرکز داده از فیس بوک توسط پیتر لاپوخوف.
• مستندات معماری به شما ایده ای از نحوه عملکرد Overlay SDN می دهد. پارچه تنگستن (قبلاً Open Contrail).

متشکرم

تنگه رومی. برای نظرات و ویرایش ها
آرتیوم چرنوبای. برای KDPV.

منبع: www.habr.com