أتمتة عرض النطاق الترددي عند الطلب حالة إستخدام من خلال مجموعة برامج أتمتة الحلقة المغلقة

المقدمة

يصف هذا المستند المكونات في حل التشغيل التلقائي للحلقة المغلقة من Cisco لتضمين التوجيه العام (GRE) tunnel scaling automation وإمكانية تكيفه للحالات الأخرى.

 معلومات أساسية

يريد موفرو الخدمة التحكم في إستخدامات النطاق الترددي عبر أنفاق شبكة إيثرنت (GRE) عبر شبكتهم ومراقبتهم عن كثب لتطوير الأنفاق كما هو مطلوب باستخدام حل ذكي للتشغيل التلقائي ذي الحلقة المغلقة.

GRE هو بروتوكول نفق يوفر نهجا عاما بسيطا لنقل الحزم من بروتوكول إلى آخر باستخدام التضمين. يركز هذا المستند على المثال المستند إلى نفق GRE للنظام الأساسي Cisco IOS® XRv ولكن يمكن أيضا تعميمه على أنظمة أساسية أخرى. تتضمن GRE حمولة، حزمة داخلية يلزم تسليمها إلى شبكة وجهة داخل حزمة IP خارجية. ويتصرف نفق GRE كإرتباط ظاهري من نقطة إلى نقطة مع نقطتي نهاية يتم تحديدهما بواسطة مصدر النفق وعنوان وجهة النفق. 

أنفاق GRE بين الموجهات

يتضمن تكوين نفق GRE إنشاء واجهة نفق وتحديد مصدر النفق والوجهة. توضح هذه الصورة تكوين ثلاثة أنفاق GRE بين الموجه-A والموجه-B. ل هذا التكوين، يجب أن يقوم واحد بإنشاء ثلاث واجهات، لكل منها على الموجه A، مثل Tunnel-1 و Tunnel-2 و Tunnel-3، كما يجب إنشاء ثلاث واجهات على الموجه-B، مثل Tunnel-1 و Tunnel-2 و Tunnel-3. بين موجهات موفر الخدمة، يمكن أن يكون هناك أنفاق GRE متعددة. يحتوي كل نفق، مثل أي واجهة شبكة أخرى تماما، على سعة محددة تستند إلى سعة الواجهة. وبالتالي، يمكن أن يحمل النفق الحد الأقصى لحركة المرور فقط ويساوي عرض النطاق الترددي. غالبا ما يعتمد عدد الأنفاق على التوقع الأولي لحمل حركة المرور واستخدام النطاق الترددي بين موقعين (الموجهات). ومن المتوقع أن يتغير إستخدام عرض النطاق الترددي هذا نظرا لتغييرات الشبكة وتوسعة الشبكة. ولتحقيق الاستخدام الأمثل للنطاق الترددي للشبكة، من المهم إضافة أنفاق جديدة أو إزالة قنوات إضافية بين جهازين استنادا إلى إستخدام النطاق الترددي الذي يتم قياسه عبر جميع الأنفاق بين الجهازين.

من هذا المثال، يمكنك القول إن السعة الإجمالية لجميع الأنفاق الثلاثة بين الموجه-A والموجه-B هي مجموع سعات النفق-1 و Tunnel-2 و Tunnel-3، والتي يطلق عليها النطاق الترددي المجمع أو النطاق الترددي العريض على مستوى حزمة GRE. يرجى ملاحظة أن الكلمة الأساسية "الحزمة" هنا تشير إلى الأنفاق بين زوج من الموجهات؛ لا توجد علاقة ضمنية مع LACP/تجميع إرتباط EtherChannel المقصود. كما أن حركة المرور الفعلية بين الموجهين هي حركة المرور الإجمالية المجمعة عبر النفق-1، النفق-2، والنفق-3. عادة، يمكنك ابتكار مفهوم لاستخدام النطاق الترددي على مستوى الحزمة، والذي يمكن أن يكون نسبة من إجمالي حركة المرور عبر الأنفاق إلى السعة الإجمالية لجميع الأنفاق بين الموجهين. بشكل عام، يريد أي مزود خدمة إتخاذ إجراء إصلاح عن طريق إضافة أو إزالة أنفاق بين الموجهين إذا لاحظ أن عرض النطاق الترددي يصبح مستهلكا بشكل زائد أو غير مستغل بشكل كامل. مهما، ل هذا وثيقة، اعتبرت أن الحد أدنى هو 20٪ للاستخدام منخفض و 80٪ للاستخدام العالي للحزمة إستعمال مستوى بين مسحاج تخديد.

 

المتطلبات

1. يلزم توفر حل الحلقة المغلقة لإجراء أتمتة الحلقة المغلقة من نهاية إلى نهاية لمجموعة GRE على XRv9K حيث يمكن للنظام جمع بيانات بيانات بيانات القياس عن بعد ومراقبة البيانات في شكل مؤشرات الأداء الرئيسية (KPIs) وتطبيق التجميع وإنشاء تنبيهات متقاطعة للحد (TCA) وإجراء تكوين المعالجة التلقائية وإغلاق التنبيه.
2. يمكن للحل حساب مؤشر أداء مفتاح الشبكة (KPI) لتوفير إستخدام عرض النطاق الترددي لمدخل النفق الفردي (Rx) ومخرج النفق (Tx) لكل نفق استنادا إلى سعة المعالجة الأولية للأنفاق بالتردد المرغوب.
3. يمكن أن يكون الحل قادرا على حساب مؤشرات الأداء الرئيسية (KPIs) المخصصة لتوفير إستخدام عرض النطاق الترددي لمدخل النفق (Rx) ومخرج النفق (Tx) لكل حزمة وهو إستخدام النطاق الترددي المجمع لجميع الأنفاق بين زوج من الموجهات. 
4. يمكن للحل اكتشاف تنبيهات وإنشائها إذا تم تجاوز حدود مستوى الحزمة المحددة. تتوفر مثل هذه التنبيهات للمراقبة.
5. يجب أن ينتج عن التنبيه إطلاق سير عمل مؤتمت يمكن أن يؤدي إلى تشغيل تكوين إضافي على الجهاز لإضافة أنفاق أو إزالتها استنادا إلى شروط التنبيه.
6. وأخيرا، يجب على النظام إغلاق التنبيهات تلقائيا بالتحديثات المطلوبة.

الحل

يتضمن حل أتمتة الحلقة المغلقة أدوات متعددة تعمل على الهدف المحدد في هذا الحل الشامل. توضح هذه الصورة المكونات والأدوات التي تساعدنا على تحقيق البنية النهائية وتحدد الدور رفيع المستوى. يمكنك النظر إلى كل مكون واستخدامه في الأقسام التالية.

حل أتمتة الحلقة المغلقة من Cisco حل أتمتة الحلقة المغلقة من Cisco

أداة	الغرض
وحدة التحكم في شبكة Cisco Crosswork (CNC)	توفر وحدة التحكم في شبكة Crosswork إمكانية رؤية في الوقت الفعلي عبر دورة حياة الخدمة والأجهزة، مع إمكانية تنقل سهلة عبر مخطط الشبكة وجرد الخدمة وسياسات النقل وصحة الخدمة وصحة الجهاز والمزيد من الدعم لمجموعة كبيرة من حالات الاستخدام مع تجربة مستخدم مشتركة ومتكاملة. في هذا الحل، يتم إستخدامه كأداة في المقام الأول لإدارة الأجهزة وجمع بيانات أداء النفق باستخدام gNMI (واجهة إدارة شبكة gRPC) أو MDT. المزيد من التفاصيل: https://www.cisco.com/site/us/en/products/networking/software/crosswork-network-controller/index.html
مصفوفة Cisco	يتم تسليم خدمات تحليلات CX (حزم الوظائف) باستخدام حل Matrix، وهو عبارة عن حل تحليلات متعدد المجالات ومورد واحد من الزجاج.  في هذا الحل، تستهلك المصفوفة البيانات من Kafka يرسل بواسطة CNC عبر Kafka Topics وينفذ كذلك تجميع KPI القائم على النفق في KPI مستوى الحزمة باستخدام عمليات البحث الطوبولوجيا وتخزينها كبيانات سلسلة زمنية وتخزينها في قاعدة بيانات Postgres. وبمجرد تخزين هذه البيانات تكون متاحة للعرض وتكون المصفوفة قد تم الكشف عن الأخطاء باستخدام تنبيهات تجاوز العتبة التي تسمح لنا بتكوين عتبات مؤشرات الأداء الأساسي التي نجمعها من الشبكة.
تجمع كافكا	مجموعة كافكا هي نظام يضم مواضيع سماسرة مختلفة، و أقسامهم الخاصة.  يقوم المنتج بإرسال أو كتابة البيانات/الرسائل إلى الموضوع ضمن المجموعة. يقوم المستهلك بقراءة أو إستهلاك الرسائل من مجموعة كافكا.  في هذا الحل، يعمل CNC كمنتج يرسل البيانات إلى مواضيع Kafka المحددة مسبقا في شكل حمولة JSON بعد تحويل البيانات من بيانات بيانات بيانات القياس عن بعد المجمعة من الموجهات.  في هذا الحل، تعمل المصفوفة كمستهلك يستهلك هذه البيانات، ويعالج البيانات، ويجمع البيانات، ويخزنها لمزيد من المعالجة وكشف الأخطاء.
Cisco NSO	تنسيق خدمات شبكة Cisco Crosswork Network Services Orchestrator (NSO)  تعد NSO جزءا من مجموعة أدوات الأتمتة Crosswork التي تم تصميمها لمزودي الخدمة والمؤسسات الكبيرة.  في هذا الحل، تجمع NSO المعلومات المتعلقة بجميع الأنفاق والأجهزة وتبني جدول مخطط مخصص لهذا الحل. أيضا، في هذا الحل، يتم إستخدام NSO مع قدرات أتمتة عملية الأعمال لتشغيل سير عمل إصلاح واتخاذ إجراء مثل إضافة أو إزالة نفق من الجهاز والمزيد من تنبيهات المسح في مصفوفة Cisco. المزيد من التفاصيل: https://www.cisco.com/c/en/us/products/cloud-systems-management/network-services-orchestrator/index.html
فيتريا VIA AIOps	تقدم تقنية Viria عبر AIOps للأتمتة الشبكية من Cisco تحليلا تلقائيا يتيح إمكانية المعالجة السريعة للأحداث التي تؤثر على الخدمة عبر جميع طبقات التقنية والتطبيقات. في هذا الحل، يتم إستخدام VIA AIOps لربط أحداث حد KPI التي تم إنشاؤها من Cisco Matrix لإنشاء حادث، وإشعار، وإطلاق إجراء مؤتمت تجاه NSO من Cisco لزيادة أو تقليل عدد نفق GRE.  المزيد من التفاصيل: https://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/crosswork-network-automation/solution-overview-c22-2403404.html

ويتخذ الحل هذه الخطوات للوفاء بحالة الاستخدام هذه، التي ترد بالتفصيل في الفروع التالية.

1. مراقبة إستخدام النفق بين أزواج الموجهات
2. مراقبة إستخدام مجموعة الموجهات بين أزواج الموجهات
   
3. إنشاء تنبيهات تجاوز الحد
4. تشغيل الحادث وتدفق عمل الإصلاح التلقائي
5. إضافة أنفاق أو إزالتها ومسح التنبيه

مراقبة إستخدام النفق بين أزواج الموجهات

تتطلب التطبيقات جمع البيانات من خلال وظائف التجميع. ثم يقوم Cisco Crosswork بتعيين وظائف التجميع هذه إلى عبارة بيانات Cisco Crosswork لخدمة الطلب. تدعم عبارة بيانات Crosswork تجميع البيانات من أجهزة الشبكة باستخدام بيانات تتبع الاستخدام التي تستند إلى نموذج (MDT) لاستهلاك تدفقات بيانات تتبع الاستخدام مباشرة من الأجهزة (للأنظمة الأساسية المستندة إلى Cisco IOS XR فقط). يسمح Cisco Crosswork لك بإنشاء وجهات بيانات خارجية يمكن إستخدامها بواسطة وظائف التجميع لإيداع البيانات. يمكن إضافة Kafka كوجهات بيانات جديدة لوظائف تجميع REST التي تم إنشاؤها بواسطة واجهة برمجة التطبيقات. في هذا الحل، تجمع CDG البيانات من الموجهات المتعلقة بإحصائيات واجهة النفق وترسل البيانات إلى موضوع Kafta.وتستهلك Cisco Matrix البيانات من موضوع Kafka وتعين البيانات إلى تطبيق عامل Matrix الذي يعالج البيانات على أنها KPI ويحفظها في طريقة التسلسل الزمني كما هو موضح في الشكل التالي الذي يصف تدفق العملية.

حل أتمتة الحلقة المغلقة من Cisco

تحتوي بيانات السلسلة الزمنية على سمات KPI التي يتم تخزينها في قاعدة بيانات المصفوفة.

سمات KPI	الغرض
عقدة	الجهاز أو المصدر الذي يتم تخزين KPI له مثال: الموجه-A
الوقت	الوقت الذي يتم فيه جمع البيانات مثال: 22-05-2024 10:00:00
فهرس	المعرف الفريد  مثال: نفق-1
القيمة	قيمة KPI - القيمة الرقمية
KPI	اسم مؤشر الأداء الأساسي مثال: إستخدام النفق

مراقبة إستخدام مجموعة الموجهات بين أزواج الموجهات 

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

الجهاز المصدر	اسم واجهة المصدر	جهاز بعيد	اسم الواجهة البعيدة
الموجه A	أنفاق-1	الموجه-B	أنفاق-1
الموجه A	أنفاق-2	الموجه-B	أنفاق-2
الموجه A	أنفاق-3	الموجه-B	أنفاق-3
....	...	...	..

لإنشاء جدول إرتباطات الطبولوجيا هذا في هذا الحل، يمكنك ملء جدول مخصص، جدول بيانات الارتباطات، مضمن في مصفوفة بناء على برنامج نصي يتم تشغيله على الخادم كل يوم في الوقت المفضل. يقوم هذا البرنامج النصي بإجراء إستدعاء واجهة برمجة تطبيقات ل BPA-NSO ويعيد إخراج JSON من حزم GRE بين أزواج الموجهات. ثم يحلل بيانات الواجهة لبناء الطوبولوجيا بتنسيق JSON. يأخذ النص أيضا مخرجات JSON ويكتبها إلى جدول بيانات الروابط كل يوم. كلما قامت بتحميل البيانات الجديدة في الجدول، فإنها تقوم أيضا بكتابة هذه البيانات في ذاكرة التخزين المؤقت للريديس لتقليل المزيد من عمليات البحث في قاعدة البيانات وتحسين الكفاءة.

ربط عملية جدول البيانات

لذلك، من الضروري أن تكون كافة الارتباطات بين نفس الجهازين جزءا من الحزمة التي تم تعريفها على أنها تنتمي إلى الحزمة نفسها. بمجرد توفر مؤشرات الأداء الرئيسية الخاصة بمستوى النفق الخام، تكون قد قمت ببناء تطبيق مخصص ل KPI_aggregate على المصفوفة التي تقوم بمهمة حساب إستخدامات مستوى الحزمة وتخزينها على هيئة KPI. 

يأخذ هذا التطبيق هذه المدخلات: 

سمة التكوين	الغرض
كرونتاب	التكرار الذي يجب تشغيل مهمة التجميع الدورية عنده
خانة الاختيار الممكنة	تنشيط/إلغاء تنشيط هذا التكوين
اسم KPI لواجهة النفق	اسم KPI الخام الذي يتم إستخدامه لحساب KPI المجمعة. يتم إنشاء اسم KPI للتجميع تلقائيا ك <raw_KPI_Name>_agg
نطاق التاريخ	تردد البيانات الخام.

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

KPI Name: <Raw_KPI_Name>_agg

Example: tunnel_utilization_agg

Value = sum (tunnel_interface_tx_link_utilization of all the interfaces on the device connected to same remote device)/ Number of tunnel interfaces in the group

Index: <local device> _<remote device>

Router-A _Router-B

Node: <Local-Device>

Router-A

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

عملية تجميع KPI لمؤشر KPI لتجميع مستوى المجموعة

إنشاء تنبيهات تجاوز الحد

عتبة مؤشر الأداء الأساسي المكونة في المصفوفة هي 85٪، مما يعني أنه عندما تتجاوز قيمة مؤشر الأداء الأساسي هذا الحد، يتم إنشاء تنبيه هام، وعندما تقل عن الحد، يتم إنشاء تنبيه واضح. يتم حفظ هذه التنبيهات في قاعدة بيانات المصفوفة، كما تتم إعادة توجيهها إلى Vitria في هذا الحل في حالة إستخدام إستخدام أتمتة التكرار الخطي. إذا تجاوزت القيمة المحسوبة لمؤشر الأداء الأساسي الحد، يتم إرسال تنبيه إلى فيتريا (VIA-AIOPs) عبر Kafka حيث تكون الحالة الحالية حرجة في الرسالة. وبالمثل، إذا كانت القيمة ترجع ضمن قيم الحد من القيم الهامة، فيجب عليها إرسال تنبيه إلى VIA-AIOPs عبر Kafka مع ظهور الحالة الحالية كما هو واضح في الرسالة. تم إرسال نموذج رسالة إلى النظام وخصائصه هي كما يلي.

{     "node": "router-A"،     "node_type": "الموجه"،     "kpi": "tunnel_utilization_agg"،     "kpi_description": "إستخدام مستوى الحزمة"،     "المخطط": "،     "index": "router-a_router-B"،     "الوقت": "2023-08-09 05:45:00+00:00"،     "القيمة": "86.0"،     "Previous_state": "CLEAR"،     "current_state": "هام"،     "link_name": "router-a_router-B" }
سمة رسالة تنبيه كافكا	مثال القيمة	الغرض
عقدة	الموجه A	اسم جهاز الشبكة
node_type	الموجّه	نوع الجهاز
KPI	tunnel_utilization_agg	اسم مؤشر الأداء الأساسي
kpi_description	إستخدام مستوى الحزمة	وصف KPI
مخطط	غير موجود	غير موجود
فهرس	الموجه-A_router-B	<local_device>-<remote_device>
زمن	"2023-08-09 05:45:00+00:00"	زمن
القيمة	86.0	قيمة KPI
السابق_الحالة	واضحاتان	حالة التنبيه السابقة
الحالية_الحالة	حرج	حالة التنبيه الحالية
link_name	الموجه-A_router-B	سمة الارتباط

سمة link_name هي اسم فرز أبجديا للأجهزة الموجودة في قيمة الفهرس. ويتم القيام بذلك لتحقيق الارتباط على مستوى VIA AIOPs حيث يجب على VIA AIOs ربط التنبيهات الواردة من نفس إرتباط الحزمة. على سبيل المثال، عند وصول تنبيهات متعددة إلى VIA AIOPs مع نفس link_name، فهذا يعني أن التنبيهات تنتمي إلى نفس إرتباط الحزمة في الشبكة المشار إليها بواسطة أسماء الأجهزة في اسم الارتباط.

إنشاء تنبيه تجميع KPI باستخدام سجل كشف المصفوفة

تشغيل الحادث وتدفق عمل الإصلاح التلقائي

يتم تكوين VIA AIOps للتعامل مع الأحداث غير العادية الخاصة بمؤشر الأداء الأساسي (KPI) من موضوع محدد في Kafka. يتم التعامل مع هذه الأحداث، كما يتم استقبالها عبر رسائل Kafka، عبر AIOs من خلال محلل أحداث JASO لتتم معالجتها لاحقا. ومن المهم للغاية أن تقوم VIA AIOs بالتعرف بدقة على أحداث انحراف KPI المتعلقة بأنفاق GRE، وتحديد اقترانها بأزواج أجهزة معينة (على سبيل المثال، الموجه A - الموجه B)، والتحقق مما إذا كان هذا الشذوذ يتطلب بدء التشغيل التلقائي لتغيير حجم نفق GRE - سواء أكان ذلك تطويرا أم تحجيميا.

يجب تكوين محلل أحداث JASO ضمن VIA AIOps لاستخراج وترجمة الأبعاد ذات الصلة من حدث غير عادي ل KPI في المصفوفة، وتحديدا "المضيف" و"KPI" و"الفهرس" و"القيمة". يجب تكوين بعد إضافي، يسمى 'automation_action'، ليتم تحديثه ديناميكيا بواسطة "محلل حدث JASO"، بناء على مقياس "القيمة" الموجود داخل حدث KPI الخاص بالمصفوفة الشاذ. ويعد هذا البعد محوريا في تحديد ما إذا كان يجب تفعيل إستجابة مؤتمتة أم لا، وتحديدا ما إذا كان سيتم تشغيل إجراءات "زيادة حجم نفق GRE" أو "تخفيض مقياس نفق GRE" من خلال معالجة حقل "قيمة KPI". وتمثل الإشارة، في نظام معلومات العمليات، تجميعا لحالات الأحداث. لتحسين عملية الارتباط هذه، يجب تكوين الإشارات المميزة ذات الحالة التي ترتبط بالأبعاد 'host' و'link name' و'kpi' و'automation_action'. والجدول مثال للإشارات، ومجموعات الارتباط، وأشكال الارتباط الخاصة بكل منها.

على سبيل المثال، الإشارة التي تم تعريفها على أنها GRE_KPIA_SCALEUP سيتم البدء بها بعد إستعانة نظام VIA AIOs برسالة فردية محددة خاصة ب KPI، كما هو مفصل في القسم 3.

اسم إشارة VIA AIOps	مفاتيح إرتباط الإشارة	اسم قاعدة مجموعة الارتباط
GRE_KPIA_SCALEUP	المضيف، kpi، اسم الارتباط، automated_action	تطوير نفق GRE
GRE_KPIB_Scaleup	المضيف، kpi، اسم الارتباط، automated_action
GRE_KPIA_SCALEDOWN	المضيف، kpi، اسم الارتباط، automated_action	تخفيض مقياس نفق GRE
GRE_KPIB_SCALEDOWN	المضيف، kpi، اسم الارتباط، automated_action

تم تصميم قاعدة مجموعة الارتباط لتسهيل تجميع الإشارات حول الجهاز A والجهاز B والأنفاق الخاصة بهم A و B و C في حدث موحد. تضمن قاعدة الارتباط هذه أنه بالنسبة لأي اقتران محدد بين الجهاز A والجهاز B، يتم إنشاء حادثتين منفصلتين كحد أقصى: حدث واحد لزيادة نطاق نفق GRE يتضمن الجهاز A والجهاز B، وحدث آخر لتخفيض نطاق نفق GRE لنفس اقتران الجهاز. يمكن لإطار عمل وكيل VIA AIOps التفاعل مع Business Process Automation (BPA) و Network Services Orchestrator (NSO).

إرتباط حدث KPI والإخطار باستخدام VIA AIOps

وفيما يلي مثال على إخطار واجهة برمجة التطبيقات (API) لتوسيع نفق GRE الذي تم إرساله إلى BPA/NSO من خلال AIOs.

{

  "create": [

    {

      "gre-tunnels-device-cla": [

        {

          "index": "RouterA-RouterB",

          "tunnelOperation": "SCALE UP",

          "MatrixData": [

            { "node": "RouterA", "kpi": "tunnel_utilization_agg" },

            { "node": "RouterB", "kpi": "tunnel_utilization_agg" }

          ]

        }

      ]

    }

  ]

}

إضافة أنفاق أو إزالتها ومسح التنبيه 

عند تلقي مكالمة API من خلال AIOps، يقوم Cisco Business Process Automation (BPA) ببدء توجيهات التطوير المطلوبة، من خلال الطلبات الداخلية إلى Cisco Network Service Orchestrator (NSO). يقوم BPA بتقييم حمولة البيانات المقدمة من VIA AIOps، والتي تتضمن تفاصيل عملية النفق، والفهرس، وبيانات المصفوفة. يتم إستخدام معلومات عملية الفهرس والنفق للواجهة مع NSO، مما يوفر معلمات لعملية القياس. وفي الوقت نفسه، تتم معالجة بيانات المصفوفة بواسطة "الوحدة النمطية لتحديث المصفوفة"، والتي تكون مسؤولة عن حل أي أحداث شاذة ل KPI من خلال التفاعل مع واجهات برمجة تطبيقات المصفوفة.

التحقق من البيانات وتكوين الجهاز باستخدام BPA-NSO

وقبل البدء في أى عمليات تغيير حجم، يتعين تطوير نموذج عمل يانغ للمكتب. يحدد هذا النموذج الإجراءات المحددة التي يجب أن ينفذها NSO إما لزيادة أو تقليل عدد النفق بين الموجه A والموجه B. يبدأ نظام أتمتة عمليات الأعمال (BPA) بتوسيع نطاق العمليات من خلال الاتصال ب Network Service Orchestrator (NSO) لإجراء "تشغيل جاف". هذه هي المرحلة الأولية من العملية حيث يطلب BPA من NSO محاكاة تغييرات التكوين المقصودة بدون تطبيقها. يعمل التشغيل الجاف كخطوة تحقق أساسية، مما يضمن إمكانية تنفيذ إجراءات التطوير المقترحة، كما هو محدد بواسطة نموذج عمل YANG، دون التسبب في أي أخطاء أو تعارضات في تكوين الشبكة.

إذا اعتبر التشغيل الجاف ناجح، مشيرا إلى أنه تم التحقق من صحة إجراءات القياس، ينتقل BPA بعد ذلك إلى مرحلة "الالتزام". عند هذه النقطة، يرشد BPA NSO لتنفيذ تعديلات التكوين الفعلية اللازمة لزيادة أو تقليل عدد نفق GRE بين الموجه A والموجه B. يقوم BPA بتشغيل "وحدة تحديث المصفوفة" باتجاه المصفوفة باستخدام إستدعاء API لإغلاق حدث KPI بالترادف مع VIA AIOs. وبمجرد إغلاق هذا الوضع الشاذ في Matrix، ترسل Matrix أيضا تنبيها ذي حدة على أنه "ممسوح" إلى VIA AIOs، مما يؤدي إلى إغلاق الحادثة في نهايتها بشكل إضافي. بهذه الطريقة، اكتملت دورة إصلاح مستوى الشبكة. يتم وصف إصدار معمم لتدفق البيانات داخل التطبيق، مستخدم في أتمتة الحلقة المغلقة هذه، في هذه الصورة.

تدفق البيانات لأتمتة الحلقة المغلقة لحزمة نفق GRE

إغلاق الحلقة لفتح إمكانيات جديدة للمعالجة التلقائية

تتم مناقشة الحل الذي تمت مناقشته في هذه الورقة بشكل متعمد مع مثال واحد هو GRE Bundle التي تقوم على أساس شذوذ الشبكة لمساعدتنا على الاتصال بمختلف كتل البناء الخاصة بهذا الحل. لقد تمت دراستها بشكل ملخص حول كيفية تكامل مكدس تقنية Cisco التي تتضمن NSO و Cisco Matrix و Cisco BPA بسلاسة مع مكونات مثل VIA AIOs و Kafka ومجموعة برامج أخرى لمساعدتنا على مراقبة مشاكل الشبكة وإصلاحها تلقائيا. يفتح هذا الحل إمكانية لكل حالات إستخدام الشبكات الأخرى التي يمكن أن تكون مشاكل نموذجية تحدث في مزود الخدمة أو شبكات المؤسسة.