كيف نفعل أتمتة شبكة قديمة كبيرة

مرحبا. لدينا 15،260+ كائن و 38000 جهاز شبكة تحتاج إلى التهيئة والتحديث والتحقق من التشغيل. خدمة أسطول المعدات هذا أمر صعب للغاية ويتطلب الكثير من الوقت والجهد والناس. لذلك ، كنا بحاجة لأتمتة العمل باستخدام معدات الشبكات ، وقررنا تكييف مفهوم الشبكة كقانون لإدارة الشبكة في شركتنا. تحت الخفض ، اقرأ سجل الأتمتة ، والأخطاء التي ارتكبت وخطة أخرى لأنظمة البناء.

قصة قصيرة طويلة ، ونحن نريد لأتمتة الشبكة

تحية! اسمي Alexander Prokhorov ، ومع فريق مهندسي الشبكات في قسمنا ، نعمل على شبكة في #IT X5 . يقوم قسمنا بتطوير البنية التحتية للشبكة والمراقبة وأتمتة الشبكات والاتجاه العصري للشبكة كقانون.

في البداية ، لم أكن أؤمن حقًا بأي آلية تلقائية في شبكتنا من حيث المبدأ. كان هناك الكثير من الأخطاء القديمة والتكوينية - ليس في كل مكان كان هناك تفويض مركزي ، وليس كل الأجهزة تدعم SSH ، وليس في كل مكان تم تكوين SNMP . كل هذا قوض إلى حد كبير الاعتقاد في الأتمتة. لذلك ، بادئ ذي بدء ، قمنا بترتيب ما هو ضروري لبدء التشغيل الآلي ، وهي: توحيد اتصال SSH ، والترخيص الفردي ( AAA ) وملامح SNMP. كل هذا الأساس يسمح لك بكتابة أداة للتوصيل الشامل للتكوينات على جهاز ، لكن السؤال الذي يطرح نفسه: هل يمكنني الحصول على المزيد؟ لذلك توصلنا إلى ضرورة وضع خطة لتطوير الأتمتة ومفهوم الشبكة كقانون ، على وجه الخصوص.

مفهوم الشبكة ككود ، وفقًا لسيسكو ، يعني المبادئ التالية:

• تخزين التكوينات الهدف في مستودع ، التحكم المصدر
• تغييرات التكوين تذهب من خلال مستودع ، المصدر الوحيد للحقيقة
• تضمين التكوينات من خلال API

تسمح لك النقطتان الأوليان بتطبيق نهج DevOps أو NetDevOps لإدارة البنية الأساسية للشبكة. مع الفقرة الثالثة هناك صعوبات ، على سبيل المثال ، ماذا تفعل إذا لم يكن هناك API؟ بالطبع ، SSH و CLI ، نحن الشبكيين!


بالإضافة إلى محاولة تطبيق مناهج جديدة لإدارة الشبكة ، أردنا حل بعض المشكلات الأكثر حدة في البنية التحتية للشبكة ، مثل تكامل البيانات والتحديث والأتمتة بالطبع. من خلال الأتمتة ، لا نعني فقط التسليم الشامل للتكوينات للمعدات ، بل يعني أيضًا التكوين التلقائي ، والجمع التلقائي لبيانات مخزون معدات الشبكة ، والتكامل مع أنظمة المراقبة. لكن أول الأشياء أولا.

الوظيفة التي نهدف إليها هي:

• قاعدة بيانات معدات الشبكة (+ الاكتشاف ، + التحديث التلقائي)
• عناوين الشبكة الأساسية (التحقق من صحة IPAM +)
• تكامل أنظمة المراقبة مع بيانات المخزون
• تخزين معايير التكوين في نظام التحكم في الإصدار
• التكوين التلقائي للتكوينات الهدف لكائن
• تسليم بالجملة من التكوينات إلى معدات الشبكة
• قم بتنفيذ عملية CI / CD لإدارة تغييرات تكوين الشبكة
• اختبار تكوينات الشبكة باستخدام CI / CD
• ZTP (Zero Touch Provisioning) - الإعداد التلقائي للمعدات لكائن ما

الأنظمة التي نحتاجها واتصالاتهم

استنتاج موجز من المفسد - من الأفضل تنظيم ومراقبة عملية التسليم الشامل للتكوينات حتى لا يتم التوصل إلى التسليم الشامل للأخطاء في التكوينات.

 - DevOps:    50ms     4    -     : ", !@#$%" 

يتكون المخطط الذي توصلنا إليه من كتل البيانات التجارية "التجارية" ، وكتل البيانات الرئيسية "للشبكة" ، وأنظمة مراقبة البنية التحتية للشبكات ، وأنظمة تسليم التهيئة ، وأنظمة التحكم في الإصدار مع وحدة اختبار.

كل ما نحتاجه هو البيانات

أولاً نحتاج إلى معرفة الأشياء الموجودة في الشركة.

نظام شركة SAP - ERP . توجد بيانات حول جميع المنشآت تقريبًا ، وبشكل أكثر دقة على جميع المتاجر ومراكز التوزيع. وكذلك هناك بيانات عن المعدات التي مرت عبر مستودع تكنولوجيا المعلومات مع أرقام المخزون ، والتي ستكون مفيدة لنا في المستقبل. المكاتب فقط مفقودة ، لا يتم تشغيلها في النظام. نحن نحاول حل هذه المشكلة في عملية منفصلة ، بدءًا من لحظة الفتح ، نحتاج إلى اتصال على كل كائن ، ونختار إعدادات الاتصال ، لذلك في مكان ما في هذه اللحظة نحتاج إلى إنشاء بيانات رئيسية. لكن قصور البيانات هو موضوع منفصل ، فمن الأفضل وضع هذا الوصف في مقالة منفصلة إذا كان هناك اهتمام بهذا.

HPSM - نظام يحتوي على CMDB مشترك لتكنولوجيا المعلومات ، وإدارة الحوادث ، وإدارة التغيير. نظرًا لأن النظام شائع في جميع تكنولوجيا المعلومات ، يجب أن يحتوي على جميع معدات تكنولوجيا المعلومات ، بما في ذلك معدات الشبكات. هذا هو المكان الذي سنضيف فيه جميع البيانات النهائية عبر الشبكة. مع إدارة الحوادث والتغيير ، نخطط للتفاعل من أنظمة المراقبة في المستقبل.

نحن نعرف الأشياء التي لدينا ، وإثرائها بالبيانات عبر الشبكة. لهذا الغرض ، لدينا نظامان - IPAM من SolarWinds ونظام CMDB.noc الخاص بنا.

IPAM هو مستودع لشبكات IP ، وينبغي أن تكون البيانات الصحيحة والأكثر دقة حول ملكية عناوين IP في الشركة هنا.

CMDB.noc هي قاعدة بيانات مع واجهة WEB حيث يتم تخزين البيانات الثابتة على معدات الشبكة - أجهزة التوجيه ، والمفاتيح ، ونقاط الوصول ، وكذلك مقدمي الخدمات وخصائصها. تحت ثابت يعني أن التغيير يتم فقط بمشاركة الرجل. بمعنى آخر ، لا يقوم الاكتشاف التلقائي بإجراء تغييرات على قاعدة البيانات هذه ؛ فنحن في حاجة إليها لفهم ما "يجب" تثبيته على الكائن. قاعدتها ضرورية كمنطقة عازلة بين الأنظمة الإنتاجية التي تعمل بها الشركة بأكملها وأدوات الشبكة الداخلية. يسرع عملية التطوير ، ويضيف الحقول اللازمة ، والعلاقات الجديدة ، وضبط المعلمات ، إلخ. بالإضافة إلى ذلك ، لا يكمن هذا الحل في سرعة التطوير فحسب ، بل أيضًا في وجود تلك العلاقات بين البيانات التي نحتاجها ، دون المساومة. كمثال صغير ، نستخدم العديد من exid في قاعدة البيانات للاتصال بين IPAM و SAP و HPSM.

نتيجة لذلك ، تلقينا بيانات كاملة عن جميع الكائنات ، مع معدات الشبكة المرفقة وعناوين IP. نحتاج الآن إلى قوالب التكوين أو خدمات الشبكة التي نقدمها في هذه المواقع.

مصدر واحد للحقيقة

هنا ، توصلنا للتو إلى تطبيق مبدأ NaaC الأول - تخزين التكوينات الهدف في المستودع. في حالتنا ، هذا هو Gitlab. كان الخيار بالنسبة لنا بسيطًا:

• أولاً ، لدينا هذه الأداة بالفعل في شركتنا ، ولم نكن بحاجة إلى نشرها من البداية
• ثانياً ، إنها مناسبة تمامًا لجميع مهامنا الحالية والمستقبلية على البنية التحتية للشبكة

سيحدث الجزء المثير للاهتمام من الأتمتة في Gitlab - عملية تغيير معيار التكوين أو ببساطة القالب.

مثال على عملية التغيير القياسية

أحد أنواع الكائنات التي لدينا هو متجر Pyaterochka. هناك ، يتكون طوبولوجيا نموذجية من جهاز توجيه واحد ومفاتيح واحد / اثنين. يتم تخزين ملف تكوين القالب في Gitlab ، في هذا الجزء كل شيء بسيط. ولكن هذا ليس تماما NaaC.

الآن دعنا نقول مشروع جديد يأتي إلينا. تتمثل مهام مشروع تكنولوجيا المعلومات الجديد في إجراء تجربة في حجم معين من المتاجر. وفقا لنتائج الطيار - إذا نجحت ، إجراء نسخة متماثلة لجميع الكائنات من هذا النوع ؛ خلاف ذلك طي الطيار دون إجراء النسخ المتماثل.

تناسب هذه العملية جيدًا منطق Git:

1. لمشروع جديد ، نقوم بإنشاء فرع ، حيث نقوم بإجراء تغييرات على التكوينات.
2. في الفرع ، نحتفظ أيضًا بقائمة من الكائنات التي يتم اختبار هذا المشروع عليها.
3. إذا نجحت ، فنحن نقدم طلب دمج في الفرع الرئيسي ، والذي سيحتاج إلى نسخ متماثل إلى شبكة prod
4. في حالة الفشل ، إما ترك فرع للتاريخ ، أو ببساطة حذف

في التقريب الأول - حتى بدون التشغيل الآلي ، إنها أداة ملائمة جدًا للعمل معًا على تكوين شبكة. خاصة إذا كنت تتخيل أن ثلاثة مشاريع أو أكثر جاءت في نفس الوقت. عندما يحين الوقت لإطلاق المشاريع في prod ، ستحتاج إلى حل جميع تعارضات التكوين في طلبات الدمج والتحقق من أن التغييرات في الإعدادات ليست حصرية بشكل متبادل. وهذا مريحة للغاية للقيام به.

بالإضافة إلى ذلك ، يضيف لنا هذا النهج المرونة في استخدام أدوات Gitlab CI / CD لاختبار التكوينات تقريبًا ، لأتمتة تسليم التكوينات إلى طاولة اختبار أو مجموعة تجريبية من الكائنات. // وحتى على همز إذا كنت تريد.

نشر التكوين إلى أي بيئة

في البداية ، كان الهدف الرئيسي بالتحديد هو التسليم الشامل للتكوينات ، كأداة تتيح لك بوضوح كبير توفير وقت المهندسين وتسريع تنفيذ مهام التكوين. للقيام بذلك ، حتى قبل بدء النشاط الكبير "Network as a Code" ، قمنا بكتابة حل بيثون للاتصال بالمعدات إما لجمع تكوينات المعدات أو لتكوينها. هذا هو netmiko ، وهذا هو pysnmp ، وهذا هو jinja2 ، الخ

ولكن حان الوقت لتقسيم التكوين المجمع إلى عدة أنواع فرعية:

1. تسليم التكوينات لاختبار والمناطق التجريبية

   يعتمد هذا العنصر على Gitlab CI ، والذي يسمح لك بتمكين تسليم التكوين إلى مناطق الاختبار والاختبار في خط الأنابيب.
   
2. ازدواجية التكوينات في همز

   • عنصر منفصل ، غالبًا ما يحدث النسخ المتماثل لأجهزة 38 كيلو في عدة موجات - زيادة حجم - لمراقبة الوضع في همز. بالإضافة إلى ذلك ، يتطلب العمل بهذا الحجم تنسيق العمل ، لذلك من الأفضل أن تبدأ هذه العملية يدويًا. لهذا ، من المريح استخدام Ansible + -AWX وربط التجميع الديناميكي للمخزون من أنظمة البيانات الرئيسية الخاصة بنا إليه.
   • كإضافة إلى ذلك ، يعد هذا حلًا مناسبًا عندما تحتاج إلى إعطاء السطر الثاني إطلاق كتب التشغيل التي تم تكوينها مسبقًا والتي تؤدي عمليات معقدة وهامة ، مثل تبديل حركة المرور بين المواقع.
3. جمع البيانات

   • أجهزة شبكة الكشف التلقائي
   • تكوينات النسخ الاحتياطي
   • تحقق الاتصال

   
   لقد قمنا بتخصيص هذه المهمة في كتلة منفصلة ، حيث توجد أوقات قام فيها شخص بتفكيك أحد المحولات فجأة أو تثبيت جهاز جديد ، لكننا لم نعلم بذلك مسبقًا. وفقًا لذلك ، لن يكون هذا الجهاز في بياناتنا الرئيسية وسيخسر عملية تسليم التكوين والمراقبة والعمل التشغيلي بشكل عام. يحدث أن تم تثبيت الجهاز بشكل شرعي ، ولكن "تم سكب" التكوين بشكل غير صحيح هناك ، ولسبب ما ، لا تعمل كلمات المرور ssh أو snmp أو aaa أو غير القياسية للوصول إلى هناك. للقيام بذلك ، لدينا بيثون لتجربة جميع أساليب الاتصال القديمة الممكنة التي يمكن أن تكون لدينا في الشركة ، وجعل القوة الغاشمة لجميع كلمات المرور القديمة ، وجميع من أجل الوصول إلى قطعة من الحديد وإعداده للعمل مع ansible والمراقبة .
   
   هناك طريقة بسيطة - لجعل العديد من ملفات المخزون غير مرغوب فيها ، حيث يمكن وصف جميع البيانات الممكنة للاتصالات (جميع أنواع البائعين بكل أزواج اسم المستخدم / كلمة المرور الممكنة) وتشغيل دليل تشغيل لكل متغير في المخزون . كنا نأمل في حل أفضل ، ولكن في مؤتمر RedHat ، نصح Ansible architect بنفس الطريقة. من المفترض عمومًا أنك تعرف مسبقًا ما الذي تتصل به.
   أردنا حلاً عالميًا - عند إزالة نسخة احتياطية ، ابحث عن معدات جديدة ، وإذا وجدت ، فأضفها إلى جميع الأنظمة الضرورية. لذلك ، نختار حلاً في بيثون - معرفة ما يمكن أن يكون أكثر جمالا من البرنامج الذي يمكنه في حد ذاته اكتشاف قطعة شبكة من الأجهزة للاتصال بها ، بغض النظر عن ما تم تكوينها عليه (ضمن حدود معقولة ، بالطبع) ، التكوين حسب الحاجة ، وإزالة التكوين ، وفي نفس الوقت ، إضافة بيانات API إلى الأنظمة المطلوبة.
   

التحقق مثل الرصد

واحدة من مهام الأتمتة هي ، بالطبع ، معرفة ما الذي حدث خارج هذه الأتمتة. لم يتم تكوين جميع الأجهزة 38k بشكل مثالي في المرة الأولى ، بل إنه يحدث أن يقوم شخص ما بإعداد المعدات بأيديهم. ومن الضروري تتبع هذه التغييرات واستعادة العدالة إلى التكوين الهدف.

هناك ثلاث طرق للتحقق من توافق التكوين مع المعيار:

• قم بالتحقق مرة واحدة كل فترة - قم بإلغاء تحميل الحالة الحالية ، والتحقق من الهدف وقم بتصحيح أوجه القصور المحددة.
• دون التحقق من أي شيء ، مرة واحدة كل فترة - طرح التكوينات الهدف. صحيح ، هناك خطر من كسر شيء ما - ربما لم يكن هناك كل شيء في التكوين الهدف.
• النهج المريح هو عندما يتم اعتبار الاختلافات من التكوين الهدف في Single Source of Truth تنبيهات ويتم مراقبتها بواسطة نظام المراقبة. يتضمن ذلك: عدم تطابق مع معيار التكوين الحالي ، وفرق بين الجهاز وتلك المحددة في البيانات الرئيسية ، وعدم تطابق مع البيانات في IPAM .

في الحالة الثالثة ، يظهر خيار لنقل هذا العمل إلى إدارة الحوادث (OS) ، بحيث يتم القضاء على التناقضات في أجزاء صغيرة طوال الوقت بأكمله عن طريق الطوارئ.

Zabbix ، الذي كتبت عنه سابقًا في مقال "كيف راقبنا 14000 كائن" ، هو نظامنا لمراقبة الكائنات الموزعة حيث يمكننا عمل أي محفزات وتنبيهات يمكننا التفكير فيها. منذ كتابة المقال الأخير ، قمنا بالترقية إلى Zabbix 4.0 LTS .

استنادًا إلى Web Zabbix ، أجرينا تحديثًا لبوابة دعم الشبكة الخاصة بنا ، حيث يمكنك الآن العثور على جميع المعلومات الموجودة على كائن من جميع أنظمتنا على شاشة واحدة ، بالإضافة إلى تشغيل البرامج النصية للتحقق من وجود مشكلات متكررة.



قدمنا ​​أيضًا ميزة جديدة - بالنسبة لنا ، أصبحت Zabbix ، بطريقة ما ، CRON لإطلاق البرامج النصية المجدولة ، مثل البرامج النصية لتكامل النظام ، والبرامج النصية للاكتشاف التلقائي. يعد هذا مناسبًا جدًا عندما تحتاج إلى إلقاء نظرة على البرامج النصية الحالية ومتى وأين يتم تشغيلها دون التحقق من كافة الخوادم. صحيح ، بالنسبة للبرامج النصية التي تعمل لأكثر من 30 ثانية ، ستحتاج إلى قاذفة تطلقها دون انتظار النهاية. لحسن الحظ ، الأمر بسيط:




يعد Splunk حلاً يتيح لك جمع سجلات الأحداث من معدات الشبكة ، كما يمكن استخدامه لمراقبة التشغيل الآلي. على سبيل المثال ، عند جمع نسخة احتياطية للتكوين ، يقوم البرنامج النصي python بإنشاء رسالة LOG CFG-5-BACKUP ، يرسل جهاز التوجيه أو المحول رسالة إلى Splunk ، حيث نحسب عدد الرسائل من هذا النوع من معدات الشبكة. يتيح لنا ذلك تتبع كمية المعدات التي اكتشفها البرنامج النصي. ونرى عدد قطع الحديد التي كانت قادرة على الإبلاغ عن ذلك إلى Splunk والتحقق من وصول الرسائل من جميع قطع الحديد.
يعد Spectrum نظامًا شاملاً نستخدمه لمراقبة الكائنات الحرجة ، وهي أداة قوية تساعدنا كثيرًا في حل حوادث الشبكة الخطيرة. في الأتمتة ، نستخدمها فقط لسحب البيانات منها ، فهي ليست مفتوحة المصدر ، وبالتالي فإن الاحتمالات محدودة إلى حد ما.

الكرز على الكعكة

باستخدام الأنظمة التي تحتوي على بيانات رئيسية حول المعدات ، يمكننا التفكير في إنشاء ZTP أو Zero Touch Provisioning. مثل زر "الضبط التلقائي" ، ولكن فقط بدون زر.

لدينا جميع البيانات اللازمة من الكتل السابقة - نحن نعرف الكائن ونوعه وما هي المعدات الموجودة (البائع والموديل) وما عناوين (IPAM) وما معيار التكوين الحالي (Git). من خلال تجميعها جميعًا ، يمكننا على الأقل إعداد قالب تهيئة للتحميل على الجهاز ، سيكون أقرب إلى One Touch Provisioning ، ولكن في بعض الأحيان لا يكون هناك حاجة إلى المزيد.

تحتاج True Zero Touch إلى وسيلة لتوصيل التهيئة تلقائيًا إلى الأجهزة غير المُجهزة. وعلاوة على ذلك ، فمن المستحسن بغض النظر عن البائع. هناك العديد من خيارات العمل - خادم وحدة التحكم ، إذا كانت جميع المعدات تمر عبر المستودع المركزي ، وحلول وحدة التحكم المحمولة ، إذا وصلت المعدات على الفور. نحن نعمل فقط على هذه الحلول ، ولكن بمجرد توفر خيار العمل ، يمكننا مشاركتها.

استنتاج

في المجموع ، في مفهومنا للشبكة كقانون ، كان هناك 5 معالم رئيسية:

• البيانات الرئيسية (اتصالات الأنظمة والبيانات مع بعضها البعض ، واجهة برمجة التطبيقات للأنظمة ، كفاية البيانات للدعم والتشغيل)
• مراقبة البيانات والتكوينات (الاكتشاف التلقائي لأجهزة الشبكة ، والتحقق من أهمية التكوين في المنشأة)
• تكوينات التحكم في الإصدار والاختبار والتجريب (Gitlab CI / CD كما هو مطبق على الشبكة ، وأدوات اختبار تهيئة الشبكة)
• تسليم التكوين (البرامج النصية Ansible ، AWX ، بيثون للاتصال)
• Zero Touch Provisioning (ما هي البيانات المطلوبة ، وكيفية بناء العملية بحيث تكون ، وكيفية الاتصال بقطعة من الأجهزة غير مكونة)

لم ينجح الأمر لتناسب كل شيء في مقال واحد ، فكل عنصر يستحق مناقشة منفصلة ، ويمكننا التحدث عن شيء الآن ، وعن شيء عندما نتحقق من الحلول في الممارسة العملية. إذا كنت مهتمًا بأي من الموضوعات - في النهاية ، سيكون هناك استطلاع حيث يمكنك التصويت على المقال التالي. إذا لم يتم تضمين الموضوع في القائمة ، ولكن من المثير للاهتمام أن نقرأ عنه ، فاترك تعليقًا في أسرع وقت ممكن ، تأكد من مشاركة تجربتنا.

---

شكر خاص لفريلين ألكساندر ( xscrew ) و Sibgatulin Marat ( eucariot ) على الزيارة المرجعية في خريف عام 2018 إلى سحابة ياندكس وقصة الأتمتة في البنية التحتية للشبكة السحابية. بعده ، حصلنا على الإلهام والكثير من الأفكار حول استخدام الأتمتة و NetDevOps في البنية التحتية لمجموعة البيع بالتجزئة X5.