نقل نموذج الإدارة لا ينقل عقد الكتابة

الخلاصة

• يحول RFC 6643 وحدات SMIv2 إلى YANG للوصول القرائي عبر NETCONF. وجود وصف يسمح بالكتابة في الأصل لا يجعل العقدة الناتجة قابلة للتهيئة تلقائيا.
• تختلف مواضع تحديد الاستمرارية: قد ترتبط في SNMP بوصف الكائن أو خصائص صفه، بينما ترتبط تهيئة NETCONF بخصائص مخزن البيانات المستهدف.
• يمكن توثيق انحرافات تجعل عقدا مختارة قابلة للتهيئة عندما تبقى الدلالات متسقة. لا يثبت هذا الاستثناء أن جميع مهام الإدارة انتقلت أو أن إيقاف المسار القديم أصبح آمنا.

ثلاث وعود داخل كلمة واحدة

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

يوضح RFC 6643، المنشور في يوليو 2012، حدود إحدى هذه الوعود. فهو يحدد تحويلا آليا من وحدات MIB المكتوبة بصيغة SMIv2 إلى وحدات YANG، بغرض إتاحة القراءة بواسطة NETCONF. لا يقدم تحويل كل كائن قابل للكتابة إلى أمر تهيئة مكافئ في الوجهة.

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

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

ما الذي يبقى من صلاحية الكتابة القديمة؟

تستخدم SMIv2 عبارة MAX-ACCESS لوصف طبيعة الوصول إلى الكائن. وقد يحمل التعريف قيمتي read-write أو read-create. لا يحذف التحويل هذه المعرفة؛ بل يسجلها في امتداد باسم smiv2:max-access.

في المقابل، يفرض RFC 6643 أن تكون الحاوية العليا الناتجة للكائنات المدارة من نوع config false. وهكذا يمكن أن تبقى الإشارة إلى قابلية الكتابة الأصلية داخل نموذج لا يصنف تلك البيانات بوصفها تهيئة. ليست هذه مفارقة تحتاج إلى تغيير آلي لكل العلامات، بل فصل بين وصف الأصل وعقد الوجهة.

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

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

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

الحفظ ليس صفة يستنتجها اسم الحقل

تشرح الفقرة 11 من RFC 6643 سبب عدم إمكان توليد عقد التهيئة تلقائيا من جميع تعريفات SMIv2. في SNMP، قد تحدد فقرة وصف الكائن كيفية بقاء قيمته، وقد يتبع ذلك خصائص الصف المفاهيمي الذي ينتمي إليه. وفي بعض الحالات تضبطه خانة تستخدم الاصطلاح StorageType. في NETCONF، تدخل خصائص مخزن التهيئة في تحديد هذه الدلالة.

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

يوضح تعريف StorageType في RFC 2579 مقدار التفصيل المطلوب. فالصف المتطاير يضيع عند إعادة التشغيل. وتستند أنواع أخرى إلى تخزين مستقر، لكنها لا تتشارك قواعد التغيير. الصف من نوع permanent يمكن تعديله ولا يمكن حذفه، بينما لا يقبل صف readOnly التعديل ولا الحذف.

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

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

عندما يدعم الجهاز مخزنا منفصلا لتهيئة البدء، لا تنتقل إليه تغييرات التهيئة الجارية تلقائيا. تحديث startup انطلاقا من running يحتاج إلى عملية نسخ صريحة. لذلك لا تكفي تسمية NETCONF لإثبات أن كل تغيير سيبقى بعد التشغيل التالي.

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

هناك أيضا فرق بين التهيئة والحالة التشغيلية. عمليات تحرير التهيئة ونسخها في RFC 6241 لا توفر آلية عامة لتغيير أي حالة تشغيلية اعتباطا. ليست كل قيمة يمكن قراءتها مدخلا ينبغي إعادة تطبيقه بوصفه إعدادا. تصنيف طبيعة الفعل يسبق اختيار طريقة ترحيل كتابته.

الاستثناء المحلي لا يثبت اكتمال الاستبدال

يترك RFC 6643 مجالا لبعض الكائنات التي تتسق دلالات استمراريتها بين النظامين. يمكن للتنفيذ أن يقدم عقدا مختارة من النموذج الناتج بوصفها بيانات تهيئة، مع توثيق هذا الاختلاف في وحدة YANG منفصلة للانحرافات، وفقا لتوجيه الوثيقة.

ويقر عقد التحويل حالة محددة لا يؤثر فيها الانتقال من config false إلى true في التوافق مع الوحدة المولدة: ألا يصاحبه تغيير آخر في دلالة العقدة. لا يثبت هذا الشرط أن كل العقد تحقق الاتساق. إنه يتيح اختيارا مبررا، لا أمرا بترقية النموذج كله إلى قابلية الكتابة.

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

يجب فصل هذا التنبيه عن قواعد توريث قيمة config عندما لا تذكر صراحة. يشرح RFC 7950 الخاص بـYANG 1.1 هذا التوريث، ويمنع وضع بيانات تهيئة تحت عقدة حالة، ويشترط بقاء النموذج صالحا بعد تطبيق الانحرافات المعلنة. قراءة سطر واحد من الملف الأساسي لا تكفي لفهم المخطط الفعلي.

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

أين تحفظ أسباب التعديل؟

ينصح RFC 6643 بإجراء التغييرات الضرورية في SMIv2 الأصلي، وتحديث معلومات المراجعة، ثم إعادة توليد YANG، بدلا من تعديل الملف الناتج مباشرة. وتبقى الإضافات والانحرافات المنفصلة ممكنة.

هذه ليست مسألة ترتيب ملفات فحسب. إذا أصبحت نسخة معدلة يدويا هي المرجع الوحيد، فقد تمحو إعادة التوليد افتراضا محليا. وإذا بقي المصدر من دون الانحرافات المستخدمة فعليا، فقد يستلم الفريق التالي وصفا لا يمثل القدرة التي بني عليها العمل.

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

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

من المناسب أن يؤدي اعتماده إلى مراجعة حالة التوليد المعنية. وليس مناسبا اعتباره شهادة بأن كل إدارة الجهاز قد انتقلت. كذلك يبين سجل RFC 6643 لدى RFC Editor سياق النشر، لكنه لا يثبت سلوك منتج أو جهاز محدد.

المسار الذي لا يظهر في عداد التقدم

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

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

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

وللقراءة وحدها حدود حماية أيضا. يحيل RFC 6643 إلى حساسية كائنات MIB الأصلية وإلى ضوابط الوصول في NETCONF. عدم القدرة على تعديل البيانات عبر هذا النموذج لا يجعل كشفها مباحا للجميع. حماية المعلومات وحماية أفعال التغيير مسألتان منفصلتان.

الدليل والتفسير

يستفيد هذا التحليل من تمييز Lu Heng بين التمثيل الرمزي والقوة القابلة للتنفيذ، ومن تناوله انفصال التحكم عن تحمل العواقب. تطبيق هذه العدسة على ترحيل الإدارة هو استنتاج Daniel Kade، وليس تقييما لهذه البروتوكولات منسوبا إلى Lu Heng.

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