9. الشبكة#

كانت أتمتة الشبكات المحلية (VLAN) تعمل في المختبر منذ ثلاثة أسابيع. ثلاثة محولات، واحد من كل مورِّد، وجميع سير العمل ناجحة. شعر الفريق بثقة. في أول تشغيل إنتاجي، فشل 23 من أصل 800 محول في شبكة الحرم. كلها HPE. كلها تعمل بإصدار برامج ثابتة لم يوثِّقه أحد.

كان الـ playbook يتحقق من استجابة الخطأ من كل جهاز بعد دفع إعداد VLAN. في أنظمة HPE الحديثة، تُرجع VLAN الموجودة مسبقاً رمز الخطأ duplicate-vlan. في هذا الإصدار الأقدم من البرامج الثابتة، أرجعت الحالة ذاتها vlan-exists. كُتب الـ playbook ليُعامل duplicate-vlan كإشارة تكافؤ أداتي، أي “هذا موجود بالفعل، لا بأس”. لم يُكتَب لمعالجة vlan-exists، فعامله كفشل. أبلغ ثلث أسطول HPE عن فشل. جرى التراجع بنظافة. ظلت تذكرة فريق التطبيقات مفتوحة لثلاث ساعات إضافية بينما دقَّق فريق الشبكات يدوياً أي المحولات جرى إعدادها فعلاً وأيها لم يجرِ.

الأتمتة لم تكن خاطئة. كان للشبكة رأي لم يوثِّقه أحد.

بعد ستة أشهر، كان الفريق ذاته يمتلك طوبولوجيا containerlab تعكس المبنى ب: 24 محولاً، وصوراً مطابقة للمورِّد، مع إقفال عقد HPE على إصدار البرامج الثابتة الإنتاجي المسجَّل في Source of Truth (SoT). في التشغيل الأول لاختبار سير عمل VLAN ضد تلك الطوبولوجيا، فشلت 8 عقد HPE بالضبط برمز الخطأ ذاته. أضاف الفريق vlan-exists إلى قائمة ردود رموز التكافؤ الأداتي في محوِّل HPE. إعادة التشغيل: اجتازت جميع العقد الـ 24. النشر الإنتاجي: 800 محول، صفر إخفاقات.

الفارق لم يكن كوداً أفضل. كان بيئة اختبار تعكس الواقع.

يتناول هذا الفصل المكوِّن الذي كان دائماً ضمنياً في الجزء الثاني: الشبكة ذاتها. كل مكوِّن بنيوي بُني حتى الآن صمَّمه فريق الأتمتة ويتصرف وفق واجهاته الموثَّقة. الشبكة موروثة. لها خصوصيات وواجهات متنوعة وتفاوتات في البرامج الثابتة وقدرات تتباين حسب المورِّد والمنصة وجيل البرنامج. يتناول الفصل التاسع سؤالين: ماذا نحتاج من الشبكة لجعل الأتمتة موثوقة، وكيف نتحقق بأمان من منطق الأتمتة قبل أن يلمس الإنتاج؟

9.1. الأسس#

9.1.1. السياق#

قدَّم الفصل الثالث الشبكةَ بوصفها أحد المكوِّنات السبعة في NAF Framework: المكوِّن الوحيد الذي لا “يمتلكه” فريق الأتمتة (يندرج في نطاق هندسة الشبكات). يُعدُّونها ويراقبونها ويُنمذجون نيَّتها، لكنهم لم يبنوا نظام التشغيل ولا نموذج البيانات ولا واجهة الـ API. هذا الاعتماد يُشكِّل كل قرار تصميمي في المنصة فوقه.

تناول الفصل الخامس مسار الكتابة في Executor بالتفصيل: كيف تعمل أدوار الأتمتة والمهام ذات المعاملات وفحوصات التكافؤ الأداتي. ما يُعامله الفصل الخامس كمُسلَّم به هو أن الجهاز في الطرف الآخر يُعرِّض واجهة موثوقة ومتسقة. يتناول الفصل التاسع ما إذا كان هذا الافتراض صحيحاً، وماذا يُفعَل حين لا يكون كذلك.

تناول الفصل السادس مسار القراءة في Collector: بث القياس عن بُعد عبر gRPC Network Management Interface (gNMI)، واستطلاع SNMP، وخط أنابيب تطبيع البيانات. يُغطِّي الفصل التاسع المتطلبات المسبقة على جانب الجهاز لتلك المسارات: ما يجب أن يكون صحيحاً في جهاز الشبكة لكي يستطيع المجمِّع القراءة منه باتساق.

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

9.1.2. الأهداف#

ثلاثة أهداف تُحدِّد مساهمة مكوِّن الشبكة في منصة الأتمتة:

1. فهم طيف البنية التحتية الشبكية الكاملة والتنقل فيه. قد تتحدث أي منصة أتمتة واسعة النطاق إلى محولات الحرم وأقمشة مراكز البيانات وVPCs السحابية وطبقات Kubernetes العلوية ووحدات التحكم في الطبقات العلوية والأجهزة الموروثة في آنٍ واحد. كل نوع يُعرِّض واجهات قابلة للبرمجة مختلفة. يجب على المنصة التعامل مع جميعها دون الانهيار في تجريد واحد يُعامِل الجميع بالحد الأدنى المشترك.

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

3. إبقاء منصة الأتمتة مستقرة مع تطور الشبكة. تُضاف مورِّدون جدد. تتغير إصدارات البرامج الثابتة. تصل أنواع بنية تحتية جديدة. يجب تصميم المنصة لاستيعاب هذا التغيير من خلال استراتيجيات التجريد، لا من خلال ترقيعات خاصة لكل سير عمل عند تغيُّر الشبكة.

9.1.3. الركائز#

ثلاث ركائز تدعم هذه الأهداف، واحدة لكل وظيفة:

1. طيف البنية التحتية الشبكية والواجهات القابلة للبرمجة: النطاق الكامل من أنواع الشبكات التي يجب على المنصة أتمتتها، والواجهة التي يُعرِّضها كل نوع للمنفِّذ والمجمِّع.
2. بيئات المحاكاة والاختبار: سلسلة أدوات التحقق قبل الإنتاج. أين تتلاءم أنواع بيئات المختبر المختلفة، وكيف تتصل بنمط Saga من الفصل السابع، وكيف تتوسع.
3. استراتيجيات التجريد: مناهج هيكلية تُتيح لمنصة الأتمتة البقاء مستقرة مع تغيُّر الشبكة الأساسية، بصرف النظر عن المورِّد وجيل المنصة وبروتوكول الواجهة.

9.1.4. النطاق#

في النطاق:

• الواجهات التي يصل من خلالها المنفِّذ والمجمِّع إلى أجهزة الشبكة. كلٌّ من NETCONF وgNMI يدعم عمليات الإعداد والقياس عن بُعد؛ يعتمد التفضيل بينهما لكل حالة استخدام على نقاط القوة التشغيلية، لا على حصرية البروتوكول. البروتوكول يُشارَك في الغالب بين المكوِّنين؛ نوع العملية يختلف.
• بيئات الاختبار والمنهجيات التي تتحقق من الأتمتة قبل الإنتاج
• استراتيجيات التجريد لإدارة التباين متعدد المورِّدين والمنصات
• انعكاسات الشبكات السحابية وKubernetes والطبقات العلوية على تصميم الأتمتة

خارج النطاق:

• توليد الإعداد وعرض القوالب (Source of Truth (SoT)، الفصل الرابع)
• ميكانيكيات التنفيذ: كيف تُنفِّذ أدوات الأتمتة مهمةً (المنفِّذ، الفصل الخامس)
• خط أنابيب جمع القياس عن بُعد: كيف تتدفق المقاييس إلى قاعدة بيانات السلاسل الزمنية (Observability، الفصل السادس)

الحد متسق: يُغطِّي الفصل التاسع جانب الشبكة من كل واجهة، لا جانب المنصة.

9.2. الوظائف#

مكوِّن الشبكة هو مكوِّن البناء الوحيد في إطار NAF الذي لا تتحكم فيه منصة الأتمتة. لا يمكنها إلا التواصل مع الشبكة كما تسمح الشبكة. كل قرار تصميمي في الفصول الخمسة السابقة، كيف تُخزَّن النية، وكيف يُشغَّل التنفيذ، وكيف يُجمَع القياس عن بُعد، وكيف تُنسَّق سير العمل، وكيف يُخدَم المستهلكون، يصبُّ في نهاية المطاف في سؤال حول ما يدعمه جهاز الشبكة في الطرف الآخر من الاتصال. يُدرِّس هذا الفصل هذا القيد مباشرةً.

graph LR

    subgraph الأهداف
        direction TB
        A1[التنقل عبر طيف البنية التحتية الشبكية الكاملة]
        A2[التحقق من الأتمتة قبل الإنتاج]
        A3[الحفاظ على استقرار المنصة مع تطور الشبكة]
    end

    subgraph الركائز
        direction TB
        B1[طيف البنية التحتية الشبكية والواجهات القابلة للبرمجة]
        B2[بيئات المحاكاة والاختبار]
        B3[استراتيجيات التجريد]
    end

    subgraph الوظائف
        direction TB
        C1[الواجهات القابلة للبرمجة]
        C2[بيئات المحاكاة والاختبار]
        C3[استراتيجيات التجريد]
    end

    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3

    classDef row1 fill:#eef7ff,stroke:#4a90e2,stroke-width:1px;
    classDef row2 fill:#ddeeff,stroke:#4a90e2,stroke-width:1px;
    classDef row3 fill:#cce5ff,stroke:#4a90e2,stroke-width:1px;

    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;

9.2.1. الواجهات القابلة للبرمجة#

الشبكة غير متجانسة بطبيعتها. ليست شيئاً واحداً. إنها طيف من أنواع البنية التحتية المتراكمة على مدار سنوات، يُبنى في الغالب بشكل متوازٍ من قِبَل فرق مختلفة (يُستعرض التنظيم وحدود الملكية في الفصل الثالث عشر)، كل منها بنموذج واجهة وتجريد ونضج أتمتة خاص. يمكن لمنصة أتمتة حديثة أن تمتد عبر محولات الحرم وأقمشة مراكز البيانات وVPCs السحابية ووحدات تحكم الطبقات العلوية ومجموعات Kubernetes وبنية تحتية WAN لمزودي الخدمة ومستويات إعادة التوجيه التي يديرها كبار مزودي الخدمات السحابية، في آنٍ واحد. يجب على المنصة التعامل مع جميعها. يُحدِّد نوع البنية التحتية الواجهة المتاحة؛ ومنصة الأتمتة تتكيَّف مع تلك الواقع بدلاً من فرض واجهة موحدة.

9.2.1.1. طيف البنية التحتية الشبكية#

هذا استعراض رفيع المستوى لسيناريوهات مختلفة من البنية التحتية الشبكية قد تواجهها، وذلك حسب طبيعة شركتك:

• تبديل الحرم والفروع هو السيناريو المحوري الذي استخدمته مثالاً في الجزء الثاني: محولات مادية متعددة المورِّدين (Cisco وArista وHPE وExtreme). تُعرِّض أجهزة الحرم الحديثة Command Line Interface (CLI) وNETCONF وgRPC Network Management Interface (gNMI) في آنٍ واحد. نضج الأتمتة عالٍ للأجهزة من السنوات الخمس إلى السبع الماضية؛ وهو متفاوت للأجهزة الموروثة التي لا تزال تعمل ببرامج ثابتة من عقد مضت.

• قماش مركز البيانات ذو طوبولوجيا ورقة-عمود في الغالب، من مجموعة أصغر من المورِّدين: Arista وCisco Nexus أو منصات الشبكات المفتوحة الأصيلة للأتمتة. توحيد الواجهات أعلى من الحرم؛ وإدارة التغيير أشد صرامة. تُضيف طبقات EVPN/VXLAN العلوية مستوى إدارة فوق القماش قد يكون له واجهة برمجية خاصة، منفصلة عن واجهة الجهاز الفردي. منصات SONiC (Cisco 8000 وNvidia Spectrum) حاضرة بشكل متزايد في عمليات نشر مراكز البيانات المتأثرة بكبار مزودي الخدمات السحابية؛ واجهة إعدادها قاعدة بيانات منظمة بدلاً من CLI أو NETCONF، وتُغطَّى أكثر في قسم استراتيجيات التجريد.

• البنية التحتية لمزودي الخدمة والشبكة الواسعة (موجِّهات على مستوى المشغِّل، وشبكات MPLS، وأقمشة توجيه مجزَّأة) لها تحديات أتمتة خاصة: الحجم، وتعقيد البروتوكول، والقلق المزدوج من إعداد مستوى التحكم وسياسة هندسة الحركة. NETCONF ونماذج YANG راسخة في هذا المجال؛ لدى مورِّدين مثل Cisco IOS-XR وJunos تغطية YANG ناضجة. تستهدف منصة الأتمتة في الغالب وحدة تحكم (SR-PCE وCrosswork وNSO) بدلاً من الأجهزة الفردية.

• الشبكات السحابية: AWS VPC وAzure VNet وGCP VPC وغيرها. واجهات REST ذات دلالة اتساق لاحق. لا يوجد مفهوم “دفع إعداد” والانتظار على تأكيد متزامن. يتعامل المنفِّذ مع العمليات غير المتزامنة: إنشاء واستطلاع والتحقق. أدوات البنية التحتية كرمز تتلاءم مع هذا النموذج بشكل طبيعي. يجب على منصة الأتمتة مراعاة نموذج الاتساق المختلف، لا افتراض دلالة تطبيق-وتأكيد متزامنة.

• SD-WAN والشبكات العلوية (Cisco SD-WAN وVersa وVMware VeloCloud) تُدار من وحدة تحكم. هدف الأتمتة هو واجهة وحدة التحكم البرمجية، لا الجهاز الفردي. الطبقة المادية الأساسية لا تزال موجودة لكن تُدار بالكامل من خلال تجريد الطبقة العلوية. هذا يؤثر على كل من التنفيذ والرصد الشامل: يكتب المنفِّذ السياسة إلى وحدة التحكم؛ كما يتدفق قياس عن بُعد حركة المرور واختيار المسار وتطبيق السياسة من خلال الواجهة الشمالية لوحدة التحكم، لا من الأجهزة المادية الأساسية مباشرةً.

• شبكات Kubernetes على طبقة CNI تُقلب نموذج الجهاز كلياً. الشبكة مُعرَّفة من خلال كائنات Kubernetes API: NetworkPolicy والخدمات وIngress والموارد المخصصة من إضافات CNI مثل Cilium وCalico وFlannel. يختفي الجهاز بوصفه هدف أتمتة. Kubernetes API هو الواجهة. سياسات الشبكة هي رمز، لا إعداد جهاز. هذا هو النموذج الذي يتقارب نحوه الآخرون: نية تصريحية، وحالة تُوفَّق بواسطة وحدة التحكم، وبلا وصول مباشر للجهاز.

• وحدات المعالجة الرقمية (DPU) والبطاقات الذكية (SmartNIC) (Nvidia BlueField وIntel IPU وMarvell Octeon) تُمثِّل تحولاً في مكان حدوث معالجة الشبكة. في مراكز البيانات الحديثة، تُثبَّت وحدات المعالجة الرقمية جنباً إلى جنب مع وحدات المعالجة المركزية على كل خادم لإلغاء تحميل وظائف الشبكة: تغليف VXLAN والتشفير وتطبيق سياسة جدار الحماية وتوزيع الحمل والتجزئة الدقيقة. هذا يُلغي تحميل هذه الوظائف من وحدة المعالجة المركزية المضيفة ومن أجهزة الشبكة المخصصة إلى برامج البطاقة الذكية الثابتة. العواقب على الأتمتة: “جهاز الشبكة” لم يعد فقط محولاً أو موجِّهاً في الرف. الوظائف التي كانت تُدار سابقاً من خلال واجهات برمجة أجهزة الشبكة المخصصة تُدار الآن من خلال مستوى إدارة وحدة المعالجة الرقمية وSDK المورِّد لها، وهو فئة واجهة جديدة لا تصلها أدوات NETCONF وgRPC Network Management Interface (gNMI) القياسية بعد بشكل نظيف.

• الشبكات المفتوحة (SONiC وDENT وOPX) تُشغِّل برنامج Network Operating System (NOS) على أجهزة اشتراكية. واجهة إعداد SONiC قاعدة بيانات Redis ذات مخطط مُنظَّم بـ Yet Another Next Generation (YANG)، مختلفة هيكلياً عن CLI أو NETCONF، وبرمجية بطبيعتها. حاضرة بشكل متزايد في مراكز البيانات المؤسسية والمتأثرة بكبار مزودي الخدمات السحابية. SONiC ملحوظة لأنها صُمِّمت للأتمتة منذ البداية: الواجهة قاعدة بيانات منظمة، لا CLI مُكيَّف للوصول البرمجي.

• وظائف الشبكة الافتراضية تتعايش مع البنية التحتية المادية في بيئات كثيرة. جدار حماية برمجي يُدرج الحركة عبر مسارات مُعرَّفة بالسياسة، وموزِّع حمل افتراضي يُدير توزيع الحركة عبر مجموعات تطبيقات، وعاكس مسار BGP قائم على برنامج: كلها أهداف أتمتة تستخدم واجهات إدارة تتراوح من واجهات REST الخاصة بالمورِّد إلى NETCONF. تُدار في الغالب جنباً إلى جنب مع الجرد المادي باستخدام نفس مصدر الحقيقة والمنفِّذ، لكنها تستلزم مسارات محوِّل منفصلة لأن نماذج واجهاتها تختلف عن الأجهزة المادية.

• وحدات التحكم اللاسلكية (Cisco DNA وAruba Central وJuniper Mist) تعمل من وحدة تحكم؛ هدف الأتمتة هو واجهة وحدة التحكم البرمجية. ذات صلة عندما يمتد تزويد VLAN إلى SSIDs اللاسلكية جنباً إلى جنب مع منافذ المحول السلكية، كما في سيناريو الحرم.

الهدف ليس تعداد كل نوع من البنية التحتية باستفاضة. بل إثبات أن منصة تُؤتمت أي شبكة غير تافهة تتفاعل مع أنواع متعددة في آنٍ واحد. يجب على المنفِّذ والمجمِّع توجيه كل عملية إلى نوع الواجهة الصحيح. يجب على Source of Truth (SoT) نمذجة النية على مستوى فوق الواجهة الفردية. تعقيد الشبكة هو قيد التصميم الذي بُنيت المنصة لاستيعابه.

9.2.1.2. أنواع الواجهات#

كل نوع من البنية التحتية يُعرِّض نوعاً واحداً أو أكثر من الواجهات لمنصة الأتمتة. يجوز للمحول المادي ذاته تعريض الثلاثة في آنٍ واحد. تتكيَّف المنصة مع ما هو متاح، مع تفضيلات تعكس الموثوقية والبنية والحجم. لا يوجد نوع واجهة إلزامي عالمياً؛ الخيار الصحيح يعتمد على ما يدعمه الجهاز وما تستلزمه العملية.

• Command Line Interface (CLI) عبر Secure Shell (SSH) عالمي وموروث وهش. يتعطَّل كشط الشاشة وتحليل النص عند تغيير البرامج الثابتة تنسيق المخرجات أو إضافة حقول جديدة. رموز الخطأ غير متسقة عبر المورِّدين وعبر إصدارات البرامج الثابتة. CLI لا تزال الخيار الوحيد للأجهزة الأقدم. التوصية هي تقليل استخدامها وتجنب بناء سير عمل تعتمد عليها لأكثر من الأجهزة التي لا بديل لها (الملاذ الأخير). ضبط وصف واجهة يبدو كالتالي:

interface GigabitEthernet0/1
 description uplink-to-core

• NETCONF منظَّم وتعاملي وصحيح حين يعمل. يدعم العمليات الذرية والتراجع، ونموذج بياناته قابل للتحليل آلياً. طبقة النقل موثوقة بشكل عام؛ طبقة نموذج البيانات هي حيث توجد الثغرات. جودة نموذج YANG للمورِّدين تتفاوت تفاوتاً كبيراً: قد يدَّعي الجهاز دعم NETCONF لكن لديه نماذج غير مكتملة أو خاصة للميزات التي تحتاجها المنصة. نماذج YANG الخاصة بـ IETF وOpenConfig تُوحِّد طبقة النية؛ نماذج YANG الخاصة بالمورِّد تسدُّ الثغرات. وصف الواجهة ذاته عبر NETCONF:

<config>
  <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
    <interface>
      <name>GigabitEthernet0/1</name>
      <description>uplink-to-core</description>
    </interface>
  </interfaces>
</config>

• RESTCONF هو المكافئ القائم على HTTP لـ NETCONF، يستخدم نماذج YANG ذاتها لكن يُعرِّضها بدلالة REST. مفيد حين تكون الفرق أكثر ارتياحاً مع أدوات HTTP مقارنةً بنقل NETCONF XML/SSH. نموذج البيانات ذاته؛ النقل فقط يختلف. دعم المورِّد أقل توحيداً من NETCONF. وصف الواجهة ذاته عبر RESTCONF:

PATCH /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0%2F1
Content-Type: application/yang-data+json

{
  "ietf-interfaces:interface": {
    "name": "GigabitEthernet0/1",
    "description": "uplink-to-core"
  }
}

• gRPC Network Management Interface (gNMI) وgNOI بروتوكولان قائمان على gRPC Remote Procedure Call (gRPC). يُعالج gNMI قياس عن بُعد وقراءة/كتابة الإعداد؛ ويُعالج gNOI الأوامر التشغيلية. حديثان وصديقان للحجم. دعم المورِّد ناضج في Arista وأحدث منصات Cisco؛ متفاوت في HPE والأجهزة الموروثة. غطَّى الفصل السادس gNMI من منظور المجمِّع. يُغطِّي الفصل التاسع المتطلبات المسبقة على جانب الجهاز: يجب على الجهاز دعم اشتراكات gNMI على إصدار نظام التشغيل الذي تستهدفه المنصة. محولات Nvidia Spectrum التي تعمل بـ SONiC تُعرِّض gNMI بشكل أصيل جنباً إلى جنب مع واجهة CONFIG_DB، مما يجعلها من أكثر المنصات ملاءمةً للأتمتة لكل من الإعداد والقياس عن بُعد. وصف الواجهة ذاته عبر طلب gNMI Set:

path:  /interfaces/interface[name=GigabitEthernet0/1]/config/description
value: "uplink-to-core"

• واجهات REST الخاصة بالمورِّد (eAPI وNX-API وCumulus NVUE والمشابهة) قابلة للقراءة آلياً لكن غير موحَّدة عبر المورِّدين. مفيدة كوسيلة سد الثغرات حين يكون NETCONF أو gNMI غائباً أو غير مكتمل لعملية معينة. تُعرِّض محولات Nvidia Cumulus واجهة NVUE (واجهة REST منظَّمة بمخطط JSON متسق) بوصفها واجهتها البرمجية الأساسية؛ تُعرِّض Arista وCisco Nexus واجهتَي eAPI وNX-API على التوالي كبديل لـ NETCONF. عامِلها كاهتمامات طبقة المحوِّل، لا كأساس لمنصة محايدة المورِّد. وصف الواجهة ذاته عبر Arista eAPI (JSON-RPC عبر HTTPS):

{
  "jsonrpc": "2.0",
  "method": "runCmds",
  "params": {
    "version": 1,
    "cmds": [
      "interface GigabitEthernet0/1",
      "description uplink-to-core"
    ],
    "format": "json"
  },
  "id": "1"
}

• واجهات السحابة ووحدات التحكم تتبع أنماط REST مع اتساق لاحق. نموذج العملية غير المتزامنة هو متطلب تصميمي، لا قيد للتحايل عليه. بالنسبة لـ SD-WAN والشبكات اللاسلكية ومستويات إدارة وحدات المعالجة الرقمية، تكون واجهة وحدة التحكم البرمجية في الغالب الواجهة الوحيدة المتاحة. إضافة وصف إلى AWS VPC تُوضِّح النمط: تحديث موارد مُوسوم مُقدَّم بشكل غير متزامن، دون تأكيد متزامن بتطبيق التغيير:

POST https://ec2.eu-west-1.amazonaws.com/ HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: AWS4-HMAC-SHA256 ...

Action=CreateTags
&ResourceId.1=vpc-0a1b2c3d4e5f67890
&Tag.1.Key=Description
&Tag.1.Value=uplink-to-core
&Version=2016-11-15

• واجهة Kubernetes API تصريحية وتُوفِّقها وحدة التحكم ومتسقة عبر المورِّدين. NetworkPolicy والخدمات والموارد المخصصة لـ CNI هي أهداف الأتمتة. لا يوجد وصول مباشر للجهاز؛ خادم API هو الواجهة الوحيدة. سياسة عزل شبكة لخدمة app-payments:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: app-payments-isolation
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: app-payments
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: app-payments

• SONiC CONFIG_DB (Redis) هي الواجهة الأصيلة لمنصات SONiC. بدلاً من بروتوكول مُطبَّق فوق نظام التشغيل، هي مخزن إعداد نظام التشغيل ذاته: قاعدة بيانات Redis ذات مخطط مُنظَّم بـ YANG. تكتب الأتمتة إدخالات JSON مباشرةً في CONFIG_DB؛ يُوفِّق الوحيد الداخلي orchagent في SONiC النية مع جداول إعادة التوجيه في العتاد. gNMI متاح في وقت متوازٍ لقراءات القياس عن بُعد. هذا مختلف معمارياً عن CLI أو NETCONF أو REST: الواجهة هي مخزن البيانات ذاته. يتناول القسم 9.2.3.4 هذا بعمق أكبر. وصف الواجهة ذاته مكتوباً في CONFIG_DB عبر JSON patch (مُطبَّق بـ config load):

{
  "PORT": {
    "Ethernet0": {
      "description": "uplink-to-core",
      "admin_status": "up"
    }
  }
}

9.2.1.3. اختيار الواجهة لكل جهاز#

حين يُعرِّض الجهاز واجهات متعددة، يجب على المنصة اختيار واجهة واحدة لكل نوع عملية والحفاظ على ذلك الاختيار باتساق. محول حرم يُعرِّض Command Line Interface (CLI) وNETCONF وgRPC Network Management Interface (gNMI) في آنٍ واحد يستلزم قراراً، لا نهجاً انتقائياً يتفاوت حسب سير العمل أو تفضيل المهندس.

التسلسل الهرمي الموصى به، مُطبَّق لكل نوع عملية. كلٌّ من gRPC Network Management Interface (gNMI) وNETCONF يدعمان كتابة الإعداد وقراءة القياس عن بُعد؛ يعكس التفضيل أدناه نقاط القوة التشغيلية، لا حصرية البروتوكول:

• gRPC Network Management Interface (gNMI) مُفضَّل لجمع القياس عن بُعد (اشتراكات البث، منظَّم، صديق للحجم؛ وgNMI Set مسار إعداد صالح أيضاً)
• NETCONF مُفضَّل للإعداد (تعاملي، قادر على التراجع؛ NETCONF get وget-config متساويان في الصلاحية لقراءات الحالة)
• RESTCONF أو REST الخاص بالمورِّد كملاذ ثانٍ حين يكون NETCONF غير مكتمل لميزة معينة
• Command Line Interface (CLI) كملاذ أخير للأجهزة الموروثة فقط

ما يحتاجه المنفِّذ من الواجهة: Idempotency أو على الأقل رموز خطأ موثوقة تُميِّز “موجود بالفعل” من “فشل”، وردود خطأ منظَّمة، وقدرة التحقق من الحالة بعد التطبيق. مشكلة vlan-exists مقابل duplicate-vlan في HPE كانت بالضبط فشلاً في الشرط الثاني: دلالات رمز الخطأ تغيَّرت بين إصدارات البرامج الثابتة.

ما يحتاجه المجمِّع: قراءات منظَّمة، واشتراكات قياس عن بُعد بثِّية، ونماذج بيانات متسقة لكي لا تحتاج طبقة الرصد الشامل إلى محللات خاصة بكل جهاز. gRPC Network Management Interface (gNMI) هو بروتوكول الاشتراك المُفضَّل حيث يُدعَم: منظَّم وهرمي ومُتحقَّق من مخططه على الجهاز، مما يُلغي تحليل النص الخاص بكل جهاز الذي هيمن على جمع عصر SNMP. لكن أي آلية اشتراك تُوصِّل بيانات منظَّمة وفي الوقت المناسب تؤدي الوظيفة ذاتها. يبقى استطلاع SNMP صالحاً للأجهزة الموروثة حيث gNMI غير متاح. تُغذِّي Syslog الأحداث المنظَّمة لرصد قائم على السجلات. OpenTelemetry (OTel) معيار ناشئ يستحق المتابعة: صُمِّم أصلاً لرصد التطبيقات، ويكتسب تبنِّياً بوصفه ناقلاً محايد المورِّد لقياس الشبكة عن بُعد والمقاييس والتتبعات. اختيار بروتوكول المجمِّع دالة لما يدعمه الجهاز؛ لا ينبغي لطبقة الرصد الشامل أن تحتاج إلى معرفة أي نقل جرى استخدامه.

يُسجِّل Source of Truth (SoT) الحالة المقصودة لكل سمة جهاز تشغِّل عليها المنصة: إعداد VLAN المقصود، وعلاقات BGP الجوار المقصودة، وأوصاف الواجهة المقصودة، وإصدار نظام التشغيل المقصود. يستحق إصدار نظام التشغيل إشارة خاصة لأنه يؤثر ليس فقط على اكتشاف الانحراف الإعدادي بل على اختيار مسار المحوِّل ذاته: يتفرع المنفِّذ حسب إصدار نظام التشغيل حين يتصرف نفس البرنامج الثابت للمورِّد بشكل مختلف بين الإصدارات. هذه ليست حالة خاصة لإصدار نظام التشغيل؛ إنه نمط النية-مقابل-الواقع ذاته مُطبَّق على كل سمة تديرها المنصة. إصدار نظام التشغيل المرغوب هو ما وافق عليه فريق العمليات؛ الإصدار الجاري هو ما يرصده الرصد الشامل. حين يتباينان، ذلك التباين إشارة: قد يكون الجهاز متأخراً في ترقية مخططة، أو حدث تغيير غير مخطط. تحتاج المنصة كلا نقطتَي البيانات لتقرير ما إذا كانت تمضي قدماً أم تتوقف.

هذا التمييز مهم عملياً. يقول مصدر الحقيقة إن الجهاز ينبغي أن يعمل بـ AOS-CX 10.13. يُبلِّغ المجمِّع أنه يعمل بـ 10.12.1006. للمنصة خياران: تعليق التنفيذ حتى تُوفَّق نسخة نظام التشغيل، أو المضي باستخدام مسار المحوِّل للإصدار 10.12. الجواب الصحيح يعتمد على سياسة إدارة التغيير لدى الفريق، لكن المنصة تحتاج كلا نقطتَي البيانات لاتخاذ القرار. مصدر الحقيقة يُوفِّر النية؛ والرصد الشامل يُوفِّر الواقع.

9.2.2. بيئات المحاكاة والاختبار#

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

كان اختبار أتمتة الشبكات دائماً أصعب من اختبار رمز التطبيقات. الشبكة نظام موزَّع بمكوِّنات كثيرة لا يتحكم فيها فريق الأتمتة: أنظمة مستقلة مجاورة عند نقاط التبادل، ومورِّدو عبور من الجانب الأعلى، وCPE يديره العملاء، وعملاء لاسلكيون، وبنية تحتية سحابية يشغِّلها أطراف ثالثة. مزود خدمة يختبر تغيير سياسة توجيه لا يستطيع تشغيل BGP peer وهمي من مزود عبور للتحقق من السلوك الكامل. مؤسسة تختبر سير عمل تجاوز فشل WAN لا تستطيع التحكم في كيفية استجابة مزود MPLS. بيئات المحاكاة الموصوفة في هذا القسم هي أفضل بديل متاح: تعيد إنتاج ما يتحكم فيه الفريق، وتقبل محدودية ما لا يمكنه، وتُركِّز التحقق على طبقة المنطق حيث تعيش الأخطاء فعلاً.

ينطبق هرم الاختبار من الفصل الثاني (وحدة، وتكامل، وشامل) هنا مباشرةً. اختبارات الوحدة تتحقق من وحدات أتمتة فردية بمعزل، في الغالب مع ردود جهاز وهمية. اختبارات التكامل تتحقق من التفاعلات متعددة الخطوات: واجهة مصدر الحقيقة البرمجية تُرجع البنية البيانية المتوقعة، والمنفِّذ يُترجمها بشكل صحيح، وردود الجهاز تُعالَج بشكل صحيح. تختبر الاختبارات الشاملة سير العمل الكامل ضد شيء يتصرف كجهاز شبكة حقيقي. بيئات المحاكاة هي الطبقة الشاملة.

9.2.2.1. أنواع البيئات#

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

• المحاكاة القائمة على الحاويات تستخدم صور نظام تشغيل الشبكة الخفيفة الوزن التي تعمل كحاويات متصلة بوصلات افتراضية. بدء التشغيل يستغرق ثوانٍ. هي الخيار العملي الافتراضي لـ CI/CD الاعتيادي: يُشغِّل فريق الأتمتة نفس رمز سير العمل ضد طوبولوجيا محاكاة حاويات عند كل تغيير، يلتقط أخطاء المنطق قبل الإنتاج. لا يُعاد إنتاج سلوك مستوى البيانات، لكن سلوك مستوى التحكم وسلوك واجهة الإدارة كافيان لاختبار منطق الأتمتة.

• المحاكاة القائمة على الأجهزة الافتراضية تُشغِّل صور NOS الكاملة كأجهزة افتراضية. توفر تغطية مورِّدين أوسع وسلوك NOS أكثر واقعية بما في ذلك مستوى البيانات، ومناسبة لاختبار تصميم البروتوكول وسيناريوهات قابلية التشغيل البيني متعددة المورِّدين. التوازن: تكلفة موارد أعلى، وبدء تشغيل أبطأ، وتكامل محدود مع خطوط الأنابيب الآلية. غير عملية لاختبار منتظم على مستوى كل إيداع.

• مختبرات العتاد المادي يُصانها كثير من المنظمات الكبيرة: رف من المحولات والموجِّهات الفعلية، يعكس في الغالب أنماط البنية الإنتاجية. هذا يوفر أعلى دقة لسلوكيات خاصة بالعتاد، واختبار الأداء، والسيناريوهات التي لا تُعيد فيها المحاكاة سلوك الجهاز بدقة. التكلفة كبيرة: استثمار رأسمالي، وطاقة ومساحة، والتكلفة التشغيلية لإبقاء طوبولوجيا المختبر متزامنة مع البنية الإنتاجية. المختبرات التي تتباعد عن الأنماط الإنتاجية تُعطي ثقة زائفة. القيمة حقيقية؛ انضباط الصيانة هو التحدي.

• التوأمات الرقمية نسخ حية من الطوبولوجيا الإنتاجية، مُغذَّاة بمصدر الحقيقة (نفس نماذج الأجهزة والطوبولوجيا والإعداد المقصود الحالي) والحالة الحالية من الرصد الشامل. يعكس التوأم الرقمي ما يبدو عليه الإنتاج فعلاً الآن، لا تقريباً. التكلفة التشغيلية كبيرة: الحفاظ على المزامنة بين التوأم الرقمي والإنتاج يستلزم توفيقاً مستمراً. استثمار على مستوى النضج، مناسب للفرق التي تحققت بالفعل من منصتها على نطاق واسع وتحتاج أعلى مستوى من الثقة قبل الإنتاج.

المحاكاة القائمة على الحاويات هي نقطة البداية العملية لمعظم الفرق. تبدأ في ثوانٍ، وتتكامل بشكل أصيل مع خطوط أنابيب CI/CD، وتُغطِّي أجهزة الحرم ومراكز البيانات الحديثة المستخدمة في غالبية حالات استخدام الأتمتة. الاستثمار في بناء هذه البيئة يُسدَّد في أول حادث تمنعه.

9.2.2.2. سلسلة أدوات المحاكاة القائمة على الحاويات والأجهزة الافتراضية#

المنظومة القائمة على الحاويات لديها أدوات متعددة بأدوار متمايزة كثيراً ما تُخلَط:

• containerlab يُنشئ ويُربط صور نظام تشغيل الشبكة القائمة على الحاويات. أنشأه Roman Dodin وجرى تبنِّيه على نطاق واسع في مجتمع أتمتة الشبكات، وأصبح المعيار الفعلي للمختبرات الشبكية القائمة على الحاويات. يُنظِّم مباشرةً حاويات Docker (Arista cEOS وFRR وSONiC وVyOS وغيرها) ويتصل بها بوصلات افتراضية مُعرَّفة في ملف طوبولوجيا. يبدأ containerlab الطوبولوجيا ويُوفِّر مختبراً جاهزاً في ثوانٍ. ملف طوبولوجيا ثلاثي العقد بسيط يبدو كالتالي:

  مع توسُّع الفرق، يُصبح تشغيل containerlab على جهاز واحد عنق زجاجة. يُوزِّع clabernetes طوبولوجيات containerlab عبر مجموعة Kubernetes، مما يُتيح تشغيل محاكاة متعددة بالتوازي ويُمكِّن الفرق من توسيع بوابة ما قبل الإنتاج مع نمو المنصة.

name: building-b-sim
topology:
  nodes:
    cisco-1:
      kind: ceos
      image: ceos:17.9.4
    arista-1:
      kind: ceos
      image: ceos:4.31.2F
    hpe-1:
      kind: vr-aoscx
      image: vrnetlab/vr-aoscx:10.12.1006
  links:
    - endpoints: ["cisco-1:eth1", "arista-1:eth1"]
    - endpoints: ["arista-1:eth2", "hpe-1:eth1"]

• netlab يُجرِّد تعريف الطوبولوجيا فوق containerlab. أنشأه Ivan Pepelnjak، يُتيح netlab للمهندس وصف ما ينبغي أن تُحقِّقه الطوبولوجيا بدلاً من كيفية ربطها: “هذه العقد الثلاث تُشغِّل BGP”، “هذه العقد في نفس VLAN.” يُفسِّر netlab ذلك الوصف ويُعيد تصييره إلى ملف طوبولوجيا containerlab بالإضافة إلى إعدادات الجهاز الأولية لكل مورِّد. فكِّر فيه كوصف تصريحي للمختبر: يُعرِّف المهندس الخدمة؛ ويُولِّد netlab تعريف البنية التحتية. حين يكون الهدف اختبار منطق الأتمتة ضد طوبولوجيا تعكس نموذج شبكة إنتاجية، netlab هو نقطة البداية الصحيحة؛ وcontainerlab هو ما يُنشئها. طوبولوجيا netlab بسيطة للسيناريو ذاته ثلاثي العقد:

nodes:
  cisco-1:
    device: iosxe
    image: ceos:17.9.4
  arista-1:
    device: eos
  hpe-1:
    device: aoscx

links:
  - cisco-1:
    arista-1:
  - arista-1:
    hpe-1:

vlans:
  app-payments:
    id: 210
    links: [ cisco-1, arista-1, hpe-1 ]

• vrnetlab يُجسِّر المحاكاة القائمة على الحاويات والأجهزة الافتراضية. بعض المورِّدين لا يُوفِّرون صور حاويات أصيلة. يُغلِّف vrnetlab صور الأجهزة الافتراضية للمورِّدين داخل حاويات، مما يجعلها قابلة للاستخدام داخل طوبولوجيا containerlab. هذه هي طريقة الاختبار ضد Cisco IOS-XR أو Junos في بيئة containerlab دون التحويل إلى منصة قائمة على الأجهزة الافتراضية.

• EVE-NG و**GNS3** منصتا محاكاة قائمتان على الأجهزة الافتراضية توفران تغطية مورِّدين واسعة، وتصميم طوبولوجيا عبر واجهة رسومية، وسلوك NOS كامل بما في ذلك إعادة توجيه مستوى البيانات. التوازن: استخدام موارد أعلى، وبدء تشغيل أبطأ، وتكامل محدود مع CI/CD. هذه هي الخيار الصحيح لاختبار البروتوكول والتصميم، والمنصات الموروثة، وسيناريوهات قابلية التشغيل البيني متعددة المورِّدين.

• Cisco Modeling Labs منصة مختبر أجهزة افتراضية تجارية من Cisco مع REST API لتكامل جزئي مع CI/CD. الخيار الصحيح للبيئات المتمحورة حول Cisco التي تحتاج إلى الوصول إلى أجهزة IOS-XE وIOS-XR وNX-OS الافتراضية في مختبر مُدار ومشترَك.

9.2.2.3. أطر التحقق#

التحقق من أن الجهاز يدعم بشكل صحيح بروتوكول واجهة معيناً أو مسار YANG جزء من العمل الموصوف في الفصل الخامس (التنفيذ) والفصل السادس (الرصد الشامل): يُغطِّي فصل التنفيذ التحقق من واجهات الإعداد قبل الاعتماد عليها في سير العمل الإنتاجي؛ ويُغطِّي فصل الرصد الشامل التحقق من مسارات الجمع والتأكيد من أن الاشتراكات تُرجع بيانات بالتنسيق المتوقع.

سيناريو واحد يستحق معاملة خاصة في سياق المحاكاة: التحقق الموجِّي. بعد نجاح المحاكاة لكن قبل الالتزام بالنطاق الإنتاجي الكامل، تُشغِّل بعض الفرق مروراً تحقق منظَّماً ضد الموجة الأولى. pyATS يُوفِّر إطار اختبار لكتابة اختبارات تفاعل الجهاز المنظَّمة مع تحليل غني ومقارنة حالة. Robot Framework إطار أتمتة اختبار أوسع قائم على الكلمات المفتاحية مع مكتبات خاصة بالشبكات. يُتيح كلاهما لفريق ترميز الحالة المتوقعة بعد التغيير كتأكيدات قابلة للتنفيذ: بعد نشر VLAN 210 على الموجة 1، تأكَّد من وجود VLAN 210 على جميع المحولات، وتأكَّد من صحة ارتباطات الواجهة، وتأكَّد من أن طبقة الرصد الشامل ترى الحالة المتوقعة. يتصل هذا مباشرةً بالقسم 9.2.2.4: طبقة التحقق المنظَّمة التي تفصل بين تشغيل محاكاة ناجح والثقة التشغيلية الحقيقية قبل المضي إلى الموجة التالية.

اختبار pyATS بسيط يؤكِّد وجود VLAN بعد النشر:

from pyats import aetest

class VlanValidation(aetest.Testcase):
    @aetest.test
    def verify_vlan_exists(self, device):
        output = device.parse('show vlan brief')
        assert 210 in output['vlans'], f"VLAN 210 missing on {device.name}"

    @aetest.test
    def verify_vlan_name(self, device):
        output = device.parse('show vlan brief')
        assert output['vlans'][210]['name'] == 'app-payments'

الفحص ذاته في Robot Framework باستخدام مكتبة NAPALM مع إعداد صريح وأسماء كلمات مفتاحية مقروءة:

*** Settings ***
Library    Collections
Library    napalm    WITH NAME    NAPALM

*** Variables ***
@{DEVICES}    cisco-1    arista-1    hpe-1

*** Test Cases ***
VLAN 210 Is Present On All Switches After Deployment
    FOR    ${hostname}    IN    @{DEVICES}
        Connect And Check VLAN    ${hostname}    210    app-payments
    END

*** Keywords ***
Connect And Check VLAN
    [Arguments]    ${hostname}    ${vlan_id}    ${vlan_name}
    NAPALM.Open    ${hostname}
    ${vlans}=    NAPALM.Get VLANs
    Dictionary Should Contain Key    ${vlans}    ${vlan_id}
    Should Be Equal    ${vlans}[${vlan_id}][name]    ${vlan_name}
    [Teardown]    NAPALM.Close

9.2.2.4. المحاكاة بوصفها بوابة Saga قبل الإنتاج#

وصف الفصل السابع نمط Saga (نمط التعويض التسلسلي): سير عمل متعدد الخطوات حيث لكل خطوة إجراء تعويض مقابل يُشغَّل إن فشلت خطوة لاحقة. يُعالج Saga الإخفاقات في الإنتاج. تُضيف المحاكاة الخطوة قبل بدء Saga: شغِّل سير العمل ضد بيئة محاكاة أولاً. إن فشل تشغيل المحاكاة، لا يحدث تغيير إنتاجي. فقط حين تنجح المحاكاة يمضي سير العمل إلى الهدف الإنتاجي.

flowchart LR
    SoT["تصدير مصدر الحقيقة (الطوبولوجيا + إصدارات نظام التشغيل)"]
    Lab["بيئة المحاكاة (طوبولوجيا containerlab)"]
    Workflow["تنفيذ سير العمل (نفس الكود المستخدَم في الإنتاج)"]
    Pass{اجتازت؟}
    Prod["التنفيذ الإنتاجي (المنسِّق: النطاق الكامل)"]
    Fix["التحقيق والإصلاح (دون تأثير على الإنتاج)"]

    SoT --> Lab --> Workflow --> Pass
    Pass -- نعم --> Prod
    Pass -- لا --> Fix --> Workflow

هذه هي بوابة ما قبل الإنتاج: المحاكاة بوصفها أول فحص قبل بدء نطاق Saga الإنتاجي. الإخفاق في المحاكاة يُلتقَط قبل لمس أي جهاز إنتاجي.

التطبيق العملي:

1. يُصدِّر مصدر الحقيقة تعريف الطوبولوجيا للنطاق المستهدَف، بما في ذلك إصدارات نظام التشغيل لكل جهاز.
2. تُنشَأ بيئة المحاكاة بصور مورِّدين مطابقة، مع إقفال إصدارات نظام التشغيل لتطابق الحالة المقصودة في مصدر الحقيقة.
3. سير العمل ذاته الذي سيُشغَّل في الإنتاج يُشغَّل ضد هدف المحاكاة أولاً.
4. أي خطوة تفشل في المحاكاة تُشغِّل التحقيق قبل المضي في التنفيذ الإنتاجي.

موجات الطرح التدريجي

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

فريق ينشر سير عمل جديداً إلى 100 مركز بيانات قد يهيكله كالتالي: محاكاة (طوبولوجيا افتراضية) → موقع تجريبي واحد → موقعان → 4 → 8 → 16 → المواقع المتبقية. كل موجة تتحقق من تصرف سير العمل بشكل صحيح في الموجة السابقة قبل التوسع. إن أظهرت الموجة 4 فشلاً لم تلتقطه المحاكاة (سلوك خاص بالعتاد، أو حالة خاصة بالموقع)، يتوقف الطرح، ويُحل المشكل، ويُستأنف تسلسل الموجات من نقطة الفشل.

flowchart LR
    Sim["المحاكاة"] --> W1["الموجة 1 (موقع واحد)"] --> W2["الموجة 2 (موقعان)"] --> W3["الموجة 3 (4 مواقع)"] --> W4["الموجة N (النطاق الكامل)"]
    W1 -- فشل --> Fix["التحقيق + الإصلاح"]
    W2 -- فشل --> Fix
    W3 -- فشل --> Fix
    Fix --> Sim

يتحكم المنسِّق في تقدم الموجات. يُحدِّد مصدر الحقيقة نطاق كل موجة حسب الموقع أو المبنى أو مجموعة الأجهزة. بوابات التحقق بين الموجات هي خطوات سير عمل صريحة: يتحقق المنسِّق من طبقة الرصد الشامل للحالة المتوقعة قبل المضي. ينطبق هذا النمط سواء كان النطاق 100 مركز بيانات أو 800 محول حرم: المبدأ هو تحديد نطاق الانفجار لأي فشل غير متوقع بينما تتراكم الثقة مع كل موجة ناجحة.

محدودية المحاكاة: صور الحاويات لا تعيد إنتاج جميع سلوكيات البرامج الثابتة. تُشغِّل صورة الحاوية في الغالب رمز NOS الحديث؛ خصوصيات البرامج الثابتة الأقدم قد لا تكون قابلة للإعادة إلا إذا أُقفل الصورة على إصدار معين. المحاكاة تلتقط أخطاء المنطق وانتهاكات عقد الواجهة وثغرات نموذج Yet Another Next Generation (YANG) والإخفاقات على مستوى الطوبولوجيا. لا تضمن اختبار كل حالة جهاز ممكنة في الإنتاج. الهدف تقليل المخاطر بشكل ملموس، لا صفر مخاطر.

مشكلة الحالات الفريدة: المحاكاة أكثر موثوقية حين تتبع الشبكة الإنتاجية أنماط بنية متسقة. شبكة بمئات الإعدادات المخصصة فردياً، كل منها بحالة وتاريخ فريد، أصعب في التمثيل الدقيق في المحاكاة. هذا أحد أسباب جعل مبادئ معمارية الأتمتة (أنماط تصميم موحَّدة، وقوالب ذهبية، وإعداد مدفوع بمصدر الحقيقة) الاختبارَ أكثر فاعلية: الشبكة المصمَّمة جيداً أكثر قابلية للمحاكاة. قيمة المحاكاة تتضاعف مع جودة تصميم الشبكة الذي تمثِّله. بناء هذه القابلية للتكرار يستلزم شراكة وثيقة مع مهندسي الشبكات، لا مهندسي الأتمتة فحسب: مهندس الشبكات الذي يفهم أي المواقع متطابقة فعلاً وأيها يحمل استثناءات مخفية هو من يمكنه جعل المحاكاة تمثيلية. جودة المحاكاة هي ناتج مشترك لانضباط تصميم الشبكة ومنصة الأتمتة.

9.2.3. استراتيجيات التجريد#

الشبكة متغايرة بطبيعتها، وليس فقط بمعنى اختلاف المورِّدين. أي منصة أتمتة تعمل على نطاق واسع تمتد عبر التبديل المادي والبنية السحابية ووحدات تحكم التراكب وبنية تحتية WAN لمزودي الخدمة والمعدات الموروثة في آنٍ واحد. كل منها يتحدث لغة مختلفة. يجب ألا تُعاد بناء منصة الأتمتة في كل مرة تُضاف نوع جديد من البنية التحتية.

يدور هذا القسم حول تصميم طبقة الأتمتة لاستيعاب التغيير بدلاً من الانهيار تحته: ليس فقط التعامل مع التغايرية الحالية بل التصميم لأنواع البنية التحتية التي ستُضاف العام القادم.

تمتد منصات الأتمتة الحديثة عبر مجالات بنية تحتية متعددة في آنٍ واحد. المعمارية التي تتعامل مع هذا بنظافة تنطبق سواء كان المشغِّل مؤسسة كبيرة، أو مزود خدمة يدير WAN وحافة العميل في آنٍ واحد، أو مزود خدمة هايبرسكيل يُشغِّل شبكة أقمشة مراكز البيانات جنباً إلى جنب مع تراكبات الشبكات السحابية. النقطة الرئيسية: المنفِّذ يكتب والمجمِّع يقرأ عبر نفس واجهة الجهاز (gRPC Network Management Interface (gNMI)/NETCONF للمعدات المادية، وREST للسحابة ووحدات التحكم)، لذا فبروتوكول الواجهة يُعدّ اهتماماً مشتركاً لكلا الكتلتين، وليس خياراً تصميمياً منفصلاً لكل كتلة.

flowchart LR
    SoT["مصدر الحقيقة"]
    Orch["المنسِّق"]
    Obs["الرصد الشامل"]

    subgraph Physical["المجال المادي"]
        PhysIF["واجهة الشبكة (NETCONF/gNMI)"]
        PhysNet["معدات الحرم ونسيج DC وWAN"]
        PhysIF --- PhysNet
    end

    subgraph Cloud["المجال السحابي"]
        CloudIF["واجهة الشبكة (REST غير متزامن)"]
        CloudNet["VPCs السحابية / الشبكات"]
        CloudIF --- CloudNet
    end

    subgraph Overlay["مجال التراكب"]
        OvIF["واجهة الشبكة (API وحدة التحكم)"]
        OvNet["SD-WAN / MPLS PCE / التراكب"]
        OvIF --- OvNet
    end

    SoT --> Orch
    Orch -->|كتابة المنفِّذ| PhysIF
    Orch -->|كتابة المنفِّذ| CloudIF
    Orch -->|كتابة المنفِّذ| OvIF
    PhysIF -->|قراءة المجمِّع| Obs
    CloudIF -->|قراءة المجمِّع| Obs
    OvIF -->|قراءة المجمِّع| Obs

مصدر الحقيقة يُنمذج القصد الكامل عبر جميع أنواع الطوبولوجيا كنموذج خدمة موحَّد. Orchestrator يحتوي على فروع حسب مجال الشبكة. المنفِّذ يُوجَّه إلى المحوِّل الصحيح استناداً إلى بيانات مصدر الحقيقة. الرصد الشامل يمتد عبر جميع الطبقات، مُغذِّياً نفس خط أنابيب البيانات بصرف النظر عن نوع البنية التحتية الكامنة.

الانضباط المعماري الرئيسي: التفريع يحدث في المنفِّذ والمنسِّق، لا في مصدر الحقيقة. يحتفظ مصدر الحقيقة بنموذج قصد واحد للخدمة. كيف يتحقق ذلك القصد على أنواع بنية تحتية مختلفة يُعدّ اهتماماً خاصاً بالمنفِّذ.

9.2.3.1. أبعاد التغايرية#

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

كل صف يمثِّل محوراً من الاختلاف يجب على المنصة التعامل معه دون أن تُرغَم على ترميزه في مصدر الحقيقة. نموذج القصد يبقى موحَّداً؛ المنفِّذ والمنسِّق يستوعبان التباين. الاستراتيجيات في الأقسام التالية تُعالج الكيفية.

9.2.3.2. نمط المحوِّل في المنفِّذ والمجمِّع#

نقطة البداية الأكثر شيوعاً والاستراتيجية الأوسع تطبيقاً. وحدة أتمتة واحدة لكل مورِّد، وجميعها تقبل نفس هيكل بيانات الإدخال من مصدر الحقيقة. يخزِّن مصدر الحقيقة القصد المحايد من المورِّدين؛ طبقة المحوِّل في المنفِّذ تُترجم لكل مورِّد عند وقت التنفيذ. ينطبق نفس المبدأ على المجمِّع: وحدة جمع واحدة لكل مورِّد أو بروتوكول، وجميعها تُوصِّل هيكل بيانات مُوحَّداً إلى خط أنابيب الرصد الشامل. المورِّد الذي يتحدث gNMI يستخدم محوِّلاً واحداً؛ المورِّد الذي يتطلب استطلاع SNMP أو REST مملوك يستخدم محوِّلاً آخر. طبقة الرصد الشامل ترى نفس مخطط البيانات بصرف النظر عن طريقة الجمع من المنبع.

flowchart LR
    SoT["قصد مصدر الحقيقة (محايد من المورِّدين): vlan_id=210, vlan_name=app-payments"]
    Exec["المنفِّذ"]
    CiscoA["محوِّل Cisco: IOS-XE NETCONF"]
    AristaA["محوِّل Arista: eAPI / EOS"]
    HPEA["محوِّل HPE: NETCONF + معالجة أخطاء إصدار نظام التشغيل"]
    CiscoD["Cisco Catalyst"]
    AristaD["Arista 7050"]
    HPED["HPE Aruba 6300"]

    CollGNMI["المجمِّع: محوِّل gNMI"]
    CollSNMP["المجمِّع: محوِّل SNMP"]
    Obs["خط أنابيب الرصد الشامل (مخطط مُوحَّد)"]

    SoT --> Exec
    Exec --> CiscoA --> CiscoD
    Exec --> AristaA --> AristaD
    Exec --> HPEA --> HPED

    CiscoD --> CollGNMI --> Obs
    AristaD --> CollGNMI
    HPED --> CollSNMP --> Obs

عملي في البناء ومفهوم جيداً. عبء الصيانة ينمو مع تنويع مخزون الأجهزة: كل مورِّد جديد أو إصدار نظام تشغيل جديد يتطلب محوِّلاً جديداً أو مُحدَّثاً. نمط المحوِّل يتوسع بشكل جيد لمجموعة مُحدَّدة من المورِّدين؛ يُصبح مُرهِقاً حين يجب على المنصة دعم كتالوج أجهزة كبير ومتغيِّر باستمرار.

9.2.3.3. نماذج YANG المجتمعية والصناعية#

هيئتان صناعيتان تنشران نماذج YANG المحايدة من المورِّدين التي تُقلِّل عمل المحوِّل الخاص بكل مورِّد. نماذج IETF (المنشورة كـ RFCs ومسودات إنترنت) تُعرِّف هياكل البيانات الأساسية: ietf-interfaces، وietf-routing، وietf-bgp. نماذج OpenConfig، التي طوَّرها اتحاد من المشغِّلين (Google وAT&T وDeutsche Telekom وآخرون)، تُغطي مجالاً مشابهاً بمخطط أكثر تركيزاً على التشغيل ودورة تكرار أسرع. كلاهما يسمح لمنصة الأتمتة بكتابة القصد مرةً واحدة ضد نموذج معياري وتوقع عمله على أي جهاز متوافق.

وحدة YANG التي تُعرِّف واجهةً تبدو هكذا (مبسَّطة من ietf-interfaces):

module ietf-interfaces {
  container interfaces {
    list interface {
      key "name";
      leaf name      { type string; }
      leaf description { type string; }
      leaf enabled   { type boolean; default true; }
    }
  }
}

نفس البنية تظهر في OpenConfig (openconfig-interfaces) وفي النماذج الأصيلة للمورِّدين، لكن بمسارات مختلفة، وأسماء أوراق مختلفة، ودلالات افتراضية مختلفة. وحدة YANG تُعرِّف المخطط؛ البروتوكول (NETCONF أو gNMI) ينقل البيانات؛ طبقة المحوِّل تعمل كوسيط بين المعيار وواقع المورِّد.

الواقع العملي لـ OpenConfig: تطبيقات المورِّدين تتفاوت في الاكتمال. قد يدَّعي الجهاز دعم OpenConfig لكنه لا ينفِّذ سوى مجموعة فرعية من النموذج: القراءات تعمل، الكتابات لا؛ أو نموذج الواجهة يعمل لكن نموذج BGP غائب.

ما وراء المسارات المفقودة، المشكلة الأكثر إخفاءً هي عدم الاتساق في البيانات. يُرجع الجهاز قيمة لمسار OpenConfig لكن بوحدة خاطئة، أو نوع مختلف، أو حقول يجب أن تكون فارغة مملوءة بقيم افتراضية خاصة بالمورِّد. اشتراك gRPC Network Management Interface (gNMI) يعمل في وضع SAMPLE قد يفشل بصمت في وضع ON_CHANGE على نفس الجهاز.

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

ملاحظة حول عائلات نماذج YANG

ثلاث عائلات من نماذج Yet Another Next Generation (YANG) تتعايش في شبكات الإنتاج، وفهم الفرق مهم لاختيار الهدف المناسب:

• نماذج IETF تتطور عبر عملية معايير IETF وتُنشر كـ RFCs أو مسودات إنترنت. إنها المعايير التأسيسية: ietf-interfaces، وietf-routing، وietf-bgp. الاعتماد واسع لكن بطيء؛ العملية شاملة لكن تستغرق سنوات. تطبيقات المورِّدين غالباً تصل بعد سنتين إلى أربع سنوات من النشر.
• نماذج OpenConfig تتطور بواسطة اتحاد OpenConfig، مجموعة يقودها المشغِّلون (Google وAT&T وDeutsche Telekom وآخرون). تكرار OpenConfig أسرع من IETF وأكثر تركيزاً على التشغيل. تُغطي الكثير من نفس المجالات الوظيفية التي تُغطيها نماذج IETF لكن بخيارات تصميم مخطط مختلفة. معظم عمليات نشر gNMI الإنتاجية تستخدم مسارات OpenConfig.
• النماذج الأصيلة للمورِّدين هي امتدادات كل مورِّد الخاصة: cisco-ios-xe-native، وjunos-conf-root، وarista-eos-augments. هذه تكشف ميزات لا تُغطيها النماذج المعيارية، وكثيراً ما تكون مطلوبة لأي شيء يتجاوز الوظائف ذات القاسم المشترك الأدنى التي تُعالجها IETF وOpenConfig. Nokia حالة متطرفة: تقريباً جميع البيانات التشغيلية على SR OS لا يمكن الوصول إليها إلا عبر نماذج YANG الخاصة بـ Nokia (nokia-conf، وnokia-state). النماذج المعيارية تُغطي سطحاً رفيعاً؛ النماذج الأصيلة للمورِّدين إلزامية لأي أتمتة ذات معنى على تلك المنصة.

التجريد يُحقِّق التوحيد على حساب الوصول إلى الميزات. كل مورِّد لديه قدرات مملوكة لا نظير لها في النماذج المعيارية. يجب على فريق يستخدم OpenConfig أن يختار: يتجاهل الميزة، أو يُضيف امتداداً خاصاً بالمورِّد، أو يحتفظ بمسار تجاوز خاص بالمورِّد. لا توجد إجابة نظيفة. في الممارسة العملية، معظم أعمال الأتمتة تتركز في الوظائف المُغطَّاة جيداً بالنماذج المعيارية (VLANs وBGP والواجهات)؛ الميزات المملوكة مهمة لكنها نادراً ما تكون حالة الاستخدام الأساسية. تصل المعايير أيضاً مع تأخر في التبني: قد يُنفِّذ مورِّد وحدة IETF بعد سنتين إلى أربع سنوات من النشر، وفقط على المنصات الأحدث. قيِّد استخدام الميزة على إصدار نظام التشغيل المسجَّل في مصدر الحقيقة بدلاً من افتراض الدعم الموحَّد.

9.2.3.4. SONiC والشبكات المفتوحة#

واجهة إعداد SONiC هي قاعدة بيانات Redis بمخطط منظَّم بـ YANG: موحَّدة وبرمجية ومُصمَّمة للأتمتة من البداية. عمل المحوِّل الخاص بالمورِّد الذي يستنزف الجهد في البيئات المادية متعددة المورِّدين لا ينطبق هنا. نفس منطق الأتمتة يعمل عبر جميع المنصات القائمة على SONiC بصرف النظر عن مورِّد العتاد الكامن.

إدخال VLAN في SONiC CONFIG_DB يبدو هكذا:

{
  "VLAN": {
    "Vlan210": {
      "vlanid": "210"
    }
  },
  "VLAN_MEMBER": {
    "Vlan210|Ethernet0": {
      "tagging_mode": "untagged"
    }
  }
}

هذا JSON يُكتب مباشرةً إلى Redis عبر sonic-cfggen أو REST API لإدارة SONiC. لا يوجد CLI للتحليل، لا XML لإنشائه. منصة الأتمتة تكتب بيانات منظَّمة؛ orchagent الخاص بـ SONiC يُطابقها مع جداول إعادة التوجيه في العتاد.

هذا هو التوجه التصميمي الذي يدعو إليه مجتمع الشبكات المفتوحة: واجهة شبكة مُصمَّمة للأتمتة بدلاً من التكيُّف معها. الفرق التي تُقدِّم منصات قائمة على SONiC إلى جانب المعدات التقليدية ستجد محوِّل SONiC الأبسط في الكتابة والأكثر موثوقية في التشغيل.

• عروض المورِّدين: تجاوز SONiC أصوله في Microsoft Azure بكثير. معظم كبار مورِّدي شرائح المفاتيح يقدِّمون الآن منصات قائمة على SONiC: Microsoft Azure SONiC (النسخة المرجعية الأولية)، وArista مع APIs إدارة متوافقة مع SONiC على منصات مختارة، وCisco 8000 series مع دعم SONiC القائم على Broadcom، وDell OS10 (الذي يستخدم معمارية مشتقة من SONiC)، ومنصات Nvidia Spectrum التي تُشغِّل SONiC كخيار من الدرجة الأولى، وعدد متزايد من مورِّدي ODM (Edgecore وCelestica وUfiSpace) الذين يشحنون منصات SONiC ذات علامات تجارية. نضج النظام البيئي لدرجة أن المنصة القائمة على SONiC متاحة تجارياً في كل فئة سعرية وأداءية.

• حالات الاستخدام الناضجة: أقمشة leaf-spine لمراكز البيانات هي النشر الأكثر رسوخاً. تُشغِّل الهايبرسكيلرز SONiC على نطاق واسع لأكثر من عقد؛ مراكز البيانات المؤسسية تسير الآن على نفس المسار. تراكب EVPN/VXLAN وتوجيه BGP وتوازن حمل ECMP ودعم واجهات 400G/800G مُتحقَّق منها بشكل جيد. قصة الأتمتة قوية: gNMI وYANG وCONFIG_DB المدعومة بـ Redis هي واجهات أصيلة. يمكن إدارة أسطول SONiC بنفس الأدوات التي تُدار بها أي منصة تدعم gNMI.

• الحدود الجديدة: يبدأ SONiC في الظهور خارج نسيج DC التقليدي. منصات التوجيه المفككة (حيث يعمل SONiC على أجهزة التوجيه ذات عدد المنافذ المرتفع بدلاً من المفاتيح فحسب) تُمدِّد نموذج NOS المفتوح إلى حالات استخدام التوجيه. يتضمن SONiC الآن دعم التوجيه القطعي: SRv6 (التوجيه القطعي عبر IPv6) متاح في SONiC الأصلي ويُستخدم في الإنتاج من قبل مزودي الخدمة الذين يُشغِّلون منصات قائمة على SONiC للهندسة المرورية وتقسيم الشبكة. بعض مزودي الخدمة يُقيِّمون أيضاً SONiC لحافة نقاط الاتصال وتجميع النطاق العريض. عمليات نشر SONiC في الحرم لا تزال نادرة لكنها ممكنة تقنياً؛ النظام البيئي للعتاد لعوامل شكل الحرم أقل نضجاً. بالنسبة للفرق التي تبني منصات جديدة اليوم، السؤال لم يعد ما إذا كان SONiC جاهزاً للإنتاج في مراكز البيانات: إنه كذلك. السؤال المفتوح هو ما إذا كانت فرع SONiC الخاص بالمورِّد وإيقاع إصداراته سيبقيان متوافقَين مع الأصل على مدار دورة حياة المنصة.

9.2.3.5. إدارة التعايش خلال هجرة البرامج الثابتة#

يفترض نمط المحوِّل إصدار نظام تشغيل معروفاً ومستقراً لكل جهاز. خلال ترقية متجددة للبرامج الثابتة، ينكسر هذا الافتراض: الأجهزة بنفس الدور، التي تُديرها نفس منصة الأتمتة، تُشغِّل إصدارات مختلفة من نظام التشغيل في آنٍ واحد لأيام أو أسابيع. قد لا يعمل مسار التجريد الذي عمل أمس على البرامج الثابتة 10.12 على البرامج الثابتة 10.13 حتى يُضاف مسار محوِّل جديد.

يجب أن يُسجِّل مصدر الحقيقة إصدار نظام التشغيل المقصود (الهدف بعد الهجرة) ويُظهر المجمِّع إصدار نظام التشغيل الحالي كحالة تشغيلية. قبل أن يُطبِّق المنفِّذ الإعداد، يجب أن يقرأ إصدار نظام التشغيل الحالي من المجمِّع أو من خط أنابيب الرصد الشامل ويختار مسار المحوِّل المناسب، لا أن يفترض أن الإصدار المقصود مُنشر بالفعل.

آلية ملموسة: يستعلم المنفِّذ كتلة الرصد الشامل (أو فحصاً خفيفاً قبل التنفيذ ضد الجهاز نفسه) عن إصدار نظام التشغيل الجاري. سجل المحوِّلات يُعيِّن نطاقات إصدارات نظام التشغيل إلى تطبيقات المحوِّلات. يستدعي المنفِّذ المحوِّل الصحيح بناءً على الحالة الحالية، لا على قصد مصدر الحقيقة. بمجرد ترقية الجهاز وتطابق الإصدار الجاري مع القصد، يستقر اختيار المحوِّل. خلال نافذة الهجرة، قد يكون مسارا محوِّل لنفس المورِّد نشطَين في آنٍ واحد.

مثال التطبيق في القسم 9.3 يُوضِّح هذا النمط مباشرةً: اُستثير خطأ محوِّل HPE لأن إصداراً واحداً من البرامج الثابتة أرجع vlan-exists وإصداراً آخر أرجع duplicate-vlan للحالة ذاتها. الإصلاح كان معالجة الأخطاء الخاصة بكل إصدار نظام تشغيل في سجل المحوِّلات. أي منصة أتمتة تُدير أسطولاً متعدد الإصدارات ستواجه هذا النوع من المشاكل. ترميز منطق المحوِّل الخاص بكل إصدار، مدفوعاً بإصدار نظام التشغيل الحالي المقروء من المجمِّع، هو التخفيف المنهجي. يتناول الفصل الحادي عشر كيفية الحفاظ على تعيينات إصدارات نظام التشغيل ككتالوج على مستوى المنصة بدلاً من ثوابت خاصة بكل تطبيق.

الاستتباع التنظيمي: شخص ما يجب أن يملك تتبع إصدار نظام التشغيل في مصدر الحقيقة وسجل إصدارات المحوِّلات وسير عمل تسلسل الترقية. هذه الأدوات الثلاث تُشكِّل نظام أتمتة الترقية. بدون ملكية صريحة، تتباعد بشكل مستقل وتتدهور موثوقية المنصة مع كل إصدار للبرامج الثابتة.

9.2.4. الشبكة كقيد على كل كتلة#

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

قدرات واجهة الشبكة تُقيِّد ما يمكن للمنفِّذ فعله: جهاز يدعم CLI فقط يُجبر محوِّل المنفِّذ على كشط الشاشة الهش؛ جهاز بدعم gNMI ناضج يُتيح إعداداً موثوقاً وبيانات قياس عن بُعد مُتدفِّقة. دعم جمع الشبكة يُقيِّد ما يمكن للمجمِّع استيعابه: جهاز لا يُنفِّذ مسار OpenConfig المطلوب يستلزم حلاً بديلاً خاصاً بالمورِّد أو ثغرة في الجمع. طوبولوجيا الشبكة تُقيِّد ما يمكن للمنسِّق تنفيذه بشكل متوازٍ بأمان: حجم دُفعة آمن لطبقة وصول مسطَّحة قد يكون كارثياً لقماش spine-leaf حيث التغييرات المتزامنة على عقد spine متعددة يمكن أن تُقسِّم الشبكة.

نموذج بيانات مصدر الحقيقة يعكس هذه القيود. حقول إصدار نظام التشغيل تبوِّب اختيار المحوِّل. حقول نوع الواجهة تبوِّب طريقة الجمع. علاقات الطوبولوجيا تبوِّب قواعد تزامن المنسِّق. مصدر الحقيقة الذي يُسجِّل مخزون الأجهزة دون تسجيل السمات ذات الصلة بالأتمتة (قدرات الواجهة وإصدار نظام التشغيل ودور الطوبولوجيا) ناقص بطرق لا تكشف نفسها إلا عند وقت التنفيذ.

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

9.3. مثال التطبيق#

9.3.1. من المحاكاة إلى الإنتاج#

سير عمل VLAN في الحرم جاهز. ثمانية أسابيع من التطوير، ثلاثة مورِّدين مُنمذجين، واختُبرت خاصية التكافؤ الأداتي ضد مختبر ثلاثي العقد. يريد الفريق نشره في الإنتاج: 800 محول، المباني A إلى F. قبل ذلك، يُشغِّلونه ضد المحاكاة.

يتبع هذا المثال تسلسل بوابة ما قبل الإنتاج الموصوف في القسم 9.2.2.4، باستخدام نطاق المبنى B كهدف المحاكاة: 24 محولاً، 8 Cisco و8 Arista و8 HPE.

الخطوة 1: تصدير الطوبولوجيا من مصدر الحقيقة

يحتفظ مصدر الحقيقة بجرد محولات المبنى B مع إصدارات نظام التشغيل المقصودة:

• 8 Cisco Catalyst 9300: IOS-XE 17.9.4
• 8 Arista 7050: EOS 4.31.2F
• 8 HPE Aruba 6300: AOS-CX 10.12.1006 (خط برامج ثابتة أقدم، ما قبل 10.13)

يُنتج تصدير مصدر الحقيقة تعريف طوبولوجيا netlab: أنواع العقد وعلامات الصور الخاصة بالمورِّد المعيَّنة لإصدارات نظام التشغيل المقصودة وحالة VLAN التي يجب أن تبدأ بها المحاكاة (VLANs 100 و150 و200 الحالية مُعدَّة مسبقاً على جميع المحولات، تطابق حالة الإنتاج).

الخطوة 2: إنشاء بيئة المحاكاة

يُصيِّر netlab تصدير مصدر الحقيقة إلى ملف طوبولوجيا containerlab. يُشغِّل containerlab على خادم Linux محاكاة مشترك في بيئة CI للفريق (خادم bare-metal بذاكرة وصول عشوائي 64 جيجابايت، كافٍ لـ 24 حاوية cEOS/vrnetlab خفيفة في آنٍ واحد). تستخدم عقد HPE صورة AOS-CX مُغلَّفة بـ vrnetlab ومُقفلة على الإصدار 10.12.1006، مطابقةً لإصدار نظام التشغيل المقصود من مصدر الحقيقة. يبدأ containerlab الطوبولوجيا. جميع العقد الـ 24 تعمل وتستجيب لـ NETCONF وgRPC Network Management Interface (gNMI) في غضون تسعين ثانية.

الخطوة 3: تشغيل سير عمل VLAN من الفصل السابع ضد هدف المحاكاة

يُشغِّل المنسِّق سير العمل مع جرد المحاكاة كنطاق هدف بدلاً من الجرد الإنتاجي. تكتمل خطوات سير العمل الأربع الأولى دون مشكلة:

• استُقبل webhook من ServiceNow، وجرى تحليله، والتحقق من صحته ضد مخطط مصدر الحقيقة
• الفحص المسبق: VLAN 210 غير موجود في المحاكاة (صحيح)
• مصدر الحقيقة مُحدَّث بقصد VLAN 210
• بوابة الموافقة: موافقة تلقائية في وضع المحاكاة

الخطوة الخامسة من سير العمل، التوزيع عبر جميع المحولات الـ 24 المحاكاة عبر المنفِّذ، تُرجع إخفاقات.

النتائج: 8 عقد Cisco تنجح. 8 عقد Arista تنجح. 8 عقد HPE تفشل.

خطأ من عقد HPE: vlan-exists. كان فحص خاصية التكافؤ الأداتي في محوِّل HPE يتعامل مع duplicate-vlan بوصفها عملية لا-فعل لكن لم يكن لديه معالج لـ vlan-exists. أرجع المنفِّذ إخفاقاً، مُشغِّلاً تعويض Saga: إزالة VLAN 210 من جميع العقد التي استلمته.

لم يحدث أي تغيير إنتاجي. تكلفة الإخفاق هي وقت بدء تشغيل الحاوية وتحقيق مدته ثلاثون دقيقة.

الخطوة 4: التشخيص والإصلاح

يتحقق الفريق من ملاحظات إصدار AOS-CX 10.12. خطأ vlan-exists أُدخل في الإصدار 10.11.1، مُحلِّلاً محل duplicate-vlan لاكتشاف VLAN المكرر. إصدار 10.13 عاد إلى duplicate-vlan للاتساق مع بقية خط منتجات Aruba.

الإصلاح: إضافة vlan-exists إلى قائمة رموز خطأ خاصية التكافؤ الأداتي في محوِّل HPE. يُحدَّث مصدر الحقيقة بملاحظة حول حدود إصدار نظام التشغيل (من 10.11 إلى 10.12.x يُرجع vlan-exists؛ 10.13 وما بعده يُرجع duplicate-vlan).

قبل إعادة التشغيل، يُرمِّز الفريق الحالة المتوقعة بعد التغيير كاختبار pyATS أو Robot Framework: بعد اكتمال سير العمل، تأكَّد من وجود VLAN 210 على جميع عقد المحاكاة الـ 24 وأن تعويض Saga لم يُشغَّل. تُضاف هذه التأكيدات إلى معايير اجتياز المحاكاة: لا تُغلَق بوابة المحاكاة إلا حين يكتمل سير العمل وتنجح تأكيدات التحقق.

الخطوة 5: إعادة التشغيل في المحاكاة

يُشغَّل المحوِّل المُصحَّح ضد نفس طوبولوجيا containerlab. تنجح جميع العقد الـ 24. يكتمل Saga دون تعويض. يُظهر مصدر الحقيقة وجود VLAN 210 على جميع عقد المبنى B.

الخطوة 6: النشر الإنتاجي

يُشغِّل المنسِّق نفس سير العمل ضد النطاق الإنتاجي الكامل: 800 محول، المباني A إلى F. كل خطوة تمر عبر نمط Saga ذاته الذي جرى التحقق منه في المحاكاة. صفر إخفاقات على عقد HPE. تذكرة ServiceNow الخاصة بفريق التطبيق تُغلَق تلقائياً حين يكتمل المنسِّق. تُتحقَّق طبقة الرصد الشامل من وجود VLAN 210 على جميع الواجهات ضمن النافذة الزمنية المتوقعة.

ما يُظهره هذا

بيئة المحاكاة ليست خطوة تحقق يمكن تخطيها حين يشعر الفريق بالثقة. إنها البوابة قبل الإنتاج في نمط Saga. طوبولوجيا محاكاة تعكس طوبولوجيا الإنتاج وإصدارات نظام التشغيل هي الحد الأدنى من بيئة الاختبار القابلة للتطبيق لفريق ينشر الأتمتة على نطاق الحرم. الاستثمار هو إعداد containerlab وصور مُقفلة على إصدار نظام التشغيل وآلية تصدير مصدر الحقيقة. العائد هو القدرة على اكتشاف الأخطاء الخاصة بالجهاز قبل أن تتحول إلى حوادث.

المحاكاة التقطت هذا الخطأ ليس بسبب اختبار غير عادي، بل لأن إصدار نظام التشغيل في المحاكاة طابق الإنتاج وشغَّلت المنصة نفس كود سير العمل ضده. أمانة بيئة المحاكاة للحالة الإنتاجية هي ما يجعل الاكتشاف ممكناً. بيئة محاكاة تُشغِّل أحدث صور المورِّدين كانت ستفوِّت الخطأ.

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

9.4. الخلاصة#

يُختتم الفصل التاسع الجزء الثاني بمعالجة الكتلة التي كانت منصة الأتمتة تُشير إليها دائماً: الشبكة نفسها.

ثلاث أفكار تُرسِّخ الفصل.

الشبكة ليست موحَّدة. أي منصة أتمتة واسعة النطاق تتفاعل مع تبديل الحرم وأقمشة مراكز البيانات وVPCs السحابية وتراكبات Kubernetes ووحدات تحكم التراكب والمعدات الموروثة في آنٍ واحد. كل منها يكشف واجهة مختلفة، ويعمل تحت دلالات اتساق مختلفة، وله نضج أتمتة مختلف. تستوعب المنصة هذه التغايرية عبر التسلسل الهرمي لاختيار الواجهة (gRPC Network Management Interface (gNMI) للقياس عن بُعد، وNETCONF للإعداد، وCommand Line Interface (CLI) كملاذ أخير)، وتتبع إصدار نظام التشغيل في مصدر الحقيقة، والمحوِّلات الخاصة بالمورِّد في المنفِّذ.

بيئات المحاكاة هي البوابة قبل الإنتاج. توفِّر المحاكاة القائمة على الحاويات بيئات واقعية وسريعة ومتكاملة مع CI/CD حيث يُختبر منطق الأتمتة ضد طوبولوجيا وإصدارات نظام تشغيل تعكس الإنتاج. الإخفاقات في المحاكاة رخيصة. الإخفاقات في الإنتاج مُكلفة. أمانة بيئة المحاكاة للحالة الإنتاجية هي ما يجعل البوابة ذات معنى.

استراتيجيات التجريد تُطيل عمر المنصة. نمط المحوِّل يتعامل مع البيئة المادية متعددة المورِّدين الحالية. تدفع OpenConfig وYANG نحو نماذج محايدة من المورِّدين تُقلِّل صيانة المحوِّلات على المدى البعيد. SONiC يُلغي عمل المحوِّل كلياً للمنصات التي تدعمه. لا توفِّر أيٌّ من هذه الاستراتيجيات إجابةً مثالية؛ كل منها ينطوي على مقايضات بين التوحيد والوصول إلى الميزات. الاختيار الصحيح يعتمد على كتالوج أجهزة الفريق وطاقته التشغيلية وقدر عمل الأتمتة الذي يقع ضمن تغطية الميزات المعيارية.

مع الفصل التاسع، اكتمل الجزء الثاني. ستة فصول غطَّت جميع كتل البناء السبع لإطار NAF: مصدر الحقيقة، والمجمِّع والرصد الشامل (معاً في الفصل السادس)، والتنفيذ، والتنسيق، وطبقة العرض، والشبكة. هذه ليست أدوات مستقلة. يُغذِّي مصدر الحقيقة المنفِّذ بالقصد الذي يحتاجه والمجمِّع بالحالة المتوقعة للتحقق منها. المنسِّق يُسلسل كليهما ويتعامل مع الإخفاق ويُظهر التقدم لطبقة العرض. الشبكة تجلس تحت جميعها: القيد الذي شكَّل تصميم كل كتلة أخرى، والمكان الذي تُنتج فيه الأتمتة نتيجةً أو تفشل.

يتحوَّل الجزء الثالث من بناء الكتل إلى تشغيل المنصة على نطاق واسع: الهندسة من أجل الموثوقية، والتصميم من أجل الأمن والامتثال، ومعاملة منصة الأتمتة كمنتج ذي دورة حياة ومتطلبات تشغيلية خاصة به.

المراجع وقراءات إضافية#

• Network Programmability and Automation، Matt Oswalt وChristian Adell وScott Lowe وJason Edelman (O’Reilly، الطبعة الثانية 2023). الدليل العملي الأشمل لأدوات أتمتة الشبكات، يُغطِّي NETCONF وgNMI ونماذج YANG وأطر الأتمتة بعمق.
• Network Programmability with YANG، Benoit Claise وLoe Clarke وJan Lindblad (Pearson، 2019). المرجع الأساسي لنمذجة بيانات YANG: كيفية بناء نماذج IETF وOpenConfig وكيفية قراءة وكتابة وحدات YANG وكيف يستخدمها NETCONF وRESTCONF.
• Cisco pyATS: Network Test and Automation Solution، John Capobianco وDan Wade (Cisco Press). دليل شامل لـ pyATS وGenie لأتمتة اختبار الشبكات: نصوص الاختبار والمحللات والتحقق من الحالة المنظَّمة وتكامل خط أنابيب CI/CD.
• Infrastructure as Code، Kief Morris (O’Reilly، الطبعة الثانية 2021). ليس خاصاً بالشبكات، لكنه أساسي لفهم كيف تنطبق المبادئ الكامنة وراء البنية التحتية القابلة للتكرار والاختبار والمُتحكَّم بإصداراتها مباشرةً على تصميم منصة أتمتة الشبكات.

💬 Found something to improve? Send feedback for this chapter