الخلاصة

  • حين يقبل الخادم <commit><confirmed/> يكون محتوى candidate قد انتقل إلى running بالفعل. المؤقّت لا يؤخر التنفيذ، بل يؤخر رفع واجب الاستعادة عن الخادم.
  • في الصيغة العادية يؤدي انتهاء جلسة البدء قبل التأكيد إلى التراجع. أما persist فيجعل الإجراء باقياً بعد الجلسة، ويتيح لجلسة أخرى تحمل persist-id المطابق أن تؤكده أو تمدده أو تلغيه.
  • لا تثبت <ok> ولا صلاحية YANG ولا إشعار complete أن startup متطابق، أو أن intended صار operational، أو أن الحزم تعبر، أو أن عدة أجهزة غيّرت حالتها كمعاملة واحدة.

انقطع الاتصال، لكن الجهاز كان قد احتفظ بقرار العودة

يعدّل مهندس عنوان الإدارة في جهاز بعيد. يبني الإعداد في candidate، يتحقق منه، ثم يرسل confirmed commit. تأتي <ok>، ويبدأ running الجديد في العمل. بعد لحظات تنقطع جلسة SSH، ولا ينجح الوصول عبر العنوان الجديد.

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

هذا هو قلب الآلية: التغيير قد أصبح واقعاً تنفيذياً قبل انقطاع الاتصال. لم يبق candidate خارج الجهاز منتظراً موافقة ثانية؛ بل صار running وقاد سلوك النظام. ما ظل مؤقتاً هو حق هذا السلوك في البقاء.

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

ما الذي حدث عند commit بالضبط؟

يعرّف RFC 6241 مخازن الإعداد وعمليات NETCONF الأساسية. عندما يعلن الخادم قدرة :candidate يستطيع العميل إعداد تكوين كامل بعيداً عن running. تنقل <commit> محتوى candidate إلى running. وتضيف :confirmed-commit:1.1، التي تعتمد على candidate، شرط النهائية بعد هذا النقل.

إذا لم يرسل العميل confirm-timeout تكون المهلة الافتراضية 600 ثانية. يستطيع commit لاحق إنهاء الإجراء بالتأكيد. ويستطيع confirmed commit آخر تمديد الإجراء وفق القواعد والمهلة الجديدة. وتؤدي <cancel-commit> إلى استعادة الحالة السابقة. ويؤدي timeout إلى النتيجة نفسها.

من المفيد فصل الأفعال التي تختصرها لوحات التشغيل عادة بكلمة «تم»:

  • التحقق يسأل هل يطابق candidate نموذج البيانات الحالي؛
  • commit يسأل هل أصبح candidate هو running؛
  • التأكيد يسأل هل انتهى واجب العودة الخاص بهذه النافذة؛
  • الإلغاء أو انتهاء المهلة أو الجلسة أو إعادة التشغيل يحدد متى تُستعاد القاعدة السابقة؛
  • حفظ startup يحدد ما سيُحمّل عند الإقلاع التالي؛
  • القياس التشغيلي يسأل ما الذي يستخدمه الجهاز والشبكة بالفعل.

يقدّم RFC 6470 إشعارات بأحداث start وextend وcomplete وcancel وtimeout. وهي لغة ممتازة لتسجيل دورة حياة الإجراء. لكنها ليست الفعل الذي يمنح النهائية. قد يفقد جامع السجلات إشعاراً، وقد يظهر complete بينما لا يزال العتاد يطبّق الإعداد. الدليل يحتاج إلى ربط RPC بالمستخدم والجلسة وبصمة candidate وبصمة running السابقة والمهلة والإشعارات والحالة اللاحقة.

عشر دقائق ليست حكماً عالمياً على المخاطر

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

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

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

persist ينقل استمرارية القرار ولا يثبت هوية صاحبه

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

لكن منصات الأتمتة قد تفصل بين مهمة البدء ومهمة الفحص، أو تحتاج إلى أن يتولى مستجيب للحادث الإجراء من اتصال جديد. هنا يرسل العميل قيمة مبهمة في persist. يبقى confirmed commit قائماً بعد انتهاء الجلسة. وتستطيع جلسة أخرى أن ترسل القيمة المطابقة في persist-id عند التأكيد أو التمديد أو الإلغاء المسموح به.

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

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

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

الاستعادة قد تمحو عملاً جاء بعد التغيير المؤقت

من السهل تخيل rollback على أنه patch عكسي لا يمس إلا الأسطر التي غيرها صاحب الإجراء. لكن confirmed commit يحتفظ بحالة سابقة ليستعيدها. يحذر RFC 6241 من أن تغييرات إعداد جاءت بعد commit المؤقت يمكن أن تتغير أو تُزال عند العودة.

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

لذلك تدخل الأقفال في حجة السلامة. يمنع lock شامل في NETCONF الجلسات الأخرى من تعديل datastore المشمول. ويعرّف RFC 5717 القفل الجزئي، لكنه يطلب رفض قفل جزئي جديد على running أثناء confirmed commit قائم، لأن الخادم قد يحتاج إلى استعادة نطاق أوسع.

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

RESTCONF قد يحسم نافذة بدأت في NETCONF

قد لا تتبع حدود السلطة أسماء الواجهات. يعرّف RFC 8040 RESTCONF فوق مخازن مفهومية مشتركة مع خادم NETCONF في الموقع نفسه. عندما يستخدم الخادم candidate، تؤدي عملية تحرير RESTCONF الناجحة إلى commit تلقائي للمحتوى الناتج.

إذا كان هناك confirmed commit غير مستدام في NETCONF، يعمل ذلك commit الجديد كتأكيد له. يستطيع عميل RESTCONF إغلاق نافذة التراجع التي فتحها شخص آخر من غير أن يرسل عملية اسمها «confirm». يكفي أن الواجهتين تتشاركان حالة واحدة.

في الإجراء المستدام تختلف النتيجة. لا يملك RESTCONF حقلاً لإرسال persist-id. إذا كان الإجراء القائم يتطلبه، يجب أن تفشل الكتابة بحالة HTTP 409 in-use بدلاً من أن تؤكد الإجراء خفية. ويمكن لقفل NETCONF أن يولد 409 أيضاً. لذلك ينبغي ربط هذه الأخطاء بإجراء confirmed commit أو lock معلوم؛ وإلا ضاعت إشارة إلى أن سلطة النهائية أو الكتابة لا تزال في مكان آخر.

هناك فرق آخر في startup. إذا دعم الخادم المشترك startup، يحدد RFC 8040 أن تحرير RESTCONF الناجح يحدّثه تلقائياً. لا يجوز نقل هذه القاعدة إلى commit NETCONF العادي. مسار الكتابة نفسه يغير ما يمكن قوله عن الاستدامة بعد إعادة التشغيل.

SSH لا يمنح وحده حق تعديل كل شيء

يحدد RFC 6242 نقل NETCONF عبر SSH. القناة المحمية وهوية الطرف أساس ضروري، لكنهما لا يقرران إن كان هذا المستخدم يستطيع استدعاء <commit> أو تغيير عقدة بعينها.

يفصل نموذج NACM في RFC 8341 بين الوصول إلى العمليات وعقد البيانات والإشعارات. قد تكون الجلسة موثقة وتُرفض العملية. وقد تُسمح العملية وتصطدم بعقدة محظورة. وقد تمنح جلسة استرداد استثناءً خاصاً بالتنفيذ. كل نتيجة يجب أن تبقى منفصلة في السجل.

ثم تأتي صلاحية النموذج. يعرّف RFC 7950 لغة YANG 1.1 وأنواعها وقيودها ومراجعها. يستطيع عنوان أن يطابق النوع ويخص الموقع الخطأ. وتستطيع سياسة أن تحقق كل المراجع وتقطع الخدمة. صحة schema شرط للقبول، وليست إثباتاً للغرض.

ويتيح RFC 8525 اكتشاف وحدات YANG والميزات والانحرافات وعلاقتها بالـ datastores، مع content-id خاص بالخادم. يجب ربط التحقق بهذه الحالة الدقيقة. إذا تغيّرت المكتبة بين التحضير وcommit فقد تتغير دلالة candidate نفسه.

اكتمال running لا يعني أن الجهاز نفّذ intended

يفصل NMDA في RFC 8342 بين running وintended وoperational. يحتوي running على الإعداد الكامل الحالي. قد يحوله النظام بتوسيع قوالب أو حذف عقد غير فعالة أو إضافة قيم يتحكم بها النظام ليصنع intended. ويعرض operational ما يستخدمه النظام فعلاً عند الرصد.

قد يبقى إعداد لمورد غير موجود في running وintended، ولا يظهر كإعداد مطبق في operational. وقد تؤخر قيود فيزيائية أو تبعيات داخلية أو عمل غير متزامن التطبيق أو تغيره. من الممكن أن يكون confirmed commit قد صار complete فيما يزال الجهاز في حالة مختلفة جزئياً.

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

تظهر هنا طبقات الواقع: تذكرة مقبولة، جلسة موثقة، عملية مأذونة، candidate صالح، running نهائي، intended مولّد، operational مطبق، وخدمة تعمل. يمكن لكل طبقة أن تكون صحيحة والطبقة التالية خاطئة.

تكرار العملية على أجهزة كثيرة لا يصنع معاملة موزعة

يصف RFC 6244 بنية إدارة أوسع تستخدم NETCONF وYANG. يستطيع المنسق استعمال confirmed commit كلبنة لتغيير شبكة، لكن كل خادم يحتفظ بقاعدته ومؤقته وقدراته وأقفاله ومسار تطبيقه.

لا تبدأ الطلبات في اللحظة نفسها. قد يعيد جهاز التشغيل، ويرفض آخر lock، ويقبل ثالث running من دون تطبيق المورد. إذا أعادت تسعة أجهزة <ok> وفشل العاشر، صار هناك واقع جزئي. تأكيد التسعة يجعله نهائياً. وإلغاؤها لا يثبت أن forwarding القديم عاد.

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

ما الذي يمكن إثباته من دون مبالغة؟

تمنح IANA أسماء مشتركة لقدرات candidate وconfirmed commit وstartup وvalidate وغيرها. هذا الحد الأدنى ضروري للتشغيل البيني. أما فصل الأدوار، والمهل، والأقفال، والقياس، وسياسة الأجهزة المتعددة فهي قرارات محلية.

التقرير القابل للدفاع يقول: هذه الجلسة وهذا المستخدم، تحت هذه السياسة وهذا schema، نقلا هذا candidate من هذه القاعدة إلى running؛ حكمت هذه المهلة وهذه الجلسة أو القيمة على النهائية؛ انتهى الإجراء بهذا الحدث؛ وصلت running وstartup إلى هاتين الحالتين؛ وأظهرت intended وoperational والحزم والخدمات هذه النتائج؛ ثم صولحت نتائج كل جهاز.

السلطة العملية ليست الاسم المكتوب في مخطط الموافقة. إنها قدرة النظام أو الشخص على إرسال RPC، وحفظ الرمز، وتمديد الوقت، والتأكيد، وكتابة startup، وتحديد متى تكفي المراقبة. حين تنفصل هذه القدرات وتصبح قابلة للرؤية، يتحول confirmed commit من طقس إلى حوكمة.

المصادر