تقليل فشل الترقية إلى مهايئ الناقل المضيف (HA) الذي يتميز بالأمان عبر جدار الحماية 7.6 FTD

المقدمة

يوضح هذا المستند أستكشاف الأخطاء وإصلاحها لمعالجة حالات فشل ترقية FTD من الإصدارات 7.0 إلى 7.2، وخاصة في عمليات النشر عالية التوفر (HA).

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

وينبع أكثر من نصف حالات الفشل هذه من مشكلات أثناء مرحلة 200_enable_maintenance_mode، حيث تقوم عمليات التحقق من HA الموجودة بإجراء فحوصات الحالة النشطة/الاحتياطية الأساسية بشكل أساسي، والتي لا تكفي لعمليات الانتقال الشاملة HA.

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

تم الترحيل من: https://confluence-eng-rtp2.cisco.com/conf/display/IFT/FTD+HA+Upgrade+Failure+Reduction

المشكلة

• هناك عدد كبير من حالات فشل الترقية إلى برنامج الإرسال فائق السرعة (FTD) التي تم الإبلاغ عنها من قبل العملاء عبر الإصدارات 7.0 و 7.1 و 7.2 لعمليات النشر HA.
• يأتي أكثر من 50٪ من حالات الفشل من عمليات نشر FTD HA. وتساهم حالات الفشل في وضع 200_enable_maintenance_mode في حالات فشل HA.
• عمليات التحقق من حالة HA الموجودة هي عمليات تحقق من الصحة الأساسية مثل عمليات التحقق من حالة الاستعداد/النشطة ولا تقوم بالتحقق من عمليات الانتقال HA بشكل كامل.

ما الجديد (حل)

عمليات التحقق المحسنة من HA لترقية FTD:

• التحقق من صحة انتقال حالة HA
• مهلات ترقية FTD HA المحسنة لحالة انتقال HA مثل مزامنة التكوين (7200 ثانية)، ومزامنة التطبيق (1200 ثانية)، والمزامنة المجمعة (7200 ثانية)
• إعطاء المزيد من التحكم ل FMC في وقت بدء أو فشل ترقية FTD
• تحسين الإبلاغ عن الأخطاء ورسائل الاسترداد لعمليات ترقية FTD HA

مقارنة بالإصدارات السابقة، فإنها تشتمل على ما يلي:

• تساعد عمليات التحقق المحسنة من HA على تقليل مشكلات إنشاء HA بعد الترقية في عمليات نشر HA
• تساعد عمليات التحقق المحسنة على تقليل حالات فشل ترقية FTD

المتطلبات الأساسية

الأنظمة الأساسية المدعومة

• المدير (المدراء) والإصدار (الإصدارات) : FMC 7.6.0
• التطبيق (ASA/FTD) والحد الأدنى لإصدار التطبيق: برنامج FTD 7. 6. 0؛ إدارة FMC إدارة 7.6.0 FTD HA
• الأنظمة الأساسية المدعومة: كافة الأنظمة الأساسية التي تعمل بتقنية FTD HA
  
  

ملاحظة: تنطبق هذه الميزة على عمليات النشر FTD HA المدارة من FMC فقط. لا تنطبق هذه الميزة على الأجهزة المجمعة أو FTD HA المدارة بواسطة FTD.

نظرة عامة على الميزة

• تساعد هذه الميزة في تقليل حالات فشل ترقية FTD في نشر HA عن طريق التحقق من حالات HA للوحدات التي تمت ترقيتها بواسطة FMC بعد جزء إعادة تمهيد عملية الترقية.
• بعد إعادة تمهيد الترقية، تتحقق FMC من حالة الاستعداد/النشط ومن أي حالات فشل في مزامنة HA.
• يقوم برنامج الإرسال فائق السرعة (FTD) بإعلام FMC بموعد بدء الترقية أو فشلها على العقدة الثانية في شكل عملية أستكشاف أخطاء HA المتقدمة جديدة وإصلاحها.
• إن يكون هناك أي إخفاق في الانضمام ال HA ما بعد ترقية reboot، رسالة مناسب عرضت على ال FMC UI.

سير عمل ترقية جديد ل FTD HA

الوحدة الاحتياطية هي أول وحدة تتم ترقيتها

ترقية الوحدة الأولى (الوحدة الاحتياطية)

• أثناء ترقية الوحدة الأولى، يقوم البرنامج النصي للترقية ببدء مهمة action_queue لجمع بيانات أستكشاف أخطاء HA المتقدمة وإصلاحها في مرحلة 999_finish.
• يبدأ تنفيذ المهمة المدرجة فقط بعد إعادة تشغيل ما بعد الترقية ويجمع معلومات أستكشاف الأخطاء وإصلاحها في شكل ملف JSON.
• تتم مزامنة نفس ملف JSON مع FMC.
• بمجرد خروج العقدة الأولى من وضع الصيانة، تقوم FMC بتشغيل مهمة action_queue عن بعد على الوحدة النشطة لتجميع أستكشاف أخطاء HA المتقدمة وإصلاحها (يجب أن تكون الوحدة النشطة 7.6 أو أعلى). وفي حالة العثور على الوحدة النشطة أقل من 7.6، لا يتم تجميع أية عمليات أستكشاف الأخطاء وإصلاحها من الوحدة النشطة، كما تتخذ FMC قرارا استنادا فقط إلى أستكشاف الأخطاء وإصلاحها التي تم تجميعها من الوحدة الاحتياطية.

وبمجرد تجميع أستكشاف أخطاء HA المتقدمة وإصلاحها من كلتا الوحدتين، تقرر FMC بدء الترقية أو حظر الترقية على العقدة الثانية (الوحدة النشطة).

ترقية الوحدة الثانية (الوحدة النشطة)

• وكما هو الحال مع الوحدة الاحتياطية، يقوم البرنامج النصي للترقية ببدء مهمة action_queue لتجميع أستكشاف أخطاء HA المتقدمة وإصلاحها في مرحلة 999_finish.
• يبدأ تنفيذ المهمة المدرجة فقط إعادة تشغيل ما بعد الترقية ويقوم بإنشاء معلومات أستكشاف الأخطاء وإصلاحها في شكل ملف JSON.
• تتم مزامنة نفس الملف مع FMC.
• في حالة فشل أي من الوحدات بسبب HA، يتم عرض بيانات فشل HA على واجهة مستخدم FMC في علامة التبويب "ترقية".
• في حالة حدوث أي فشل في الانضمام إلى إعادة تشغيل ما بعد الترقية HA، يتم وضع علامة إتمام الترقية ويتم الإبلاغ عن حالات فشل التحقق من صحة HA في علامة التبويب نفسه للترقية.

أستكشاف أخطاء HA المتقدمة وإصلاحها

• يعد أستكشاف أخطاء HA المتقدمة وإصلاحها ملف JSON أحادي جديد تم تقديمه كجزء من هذه الميزة التي تحتوي على معلومات HA. يتم إنشاؤها بعد إعادة التمهيد بعد الترقية ويتم إرسالها من FTD إلى FMC.
• اسم الملف والمسار: /ngfw/var/sf/sync/ha/upgrade_troubleshoot
• بمجرد أن تجمع FMC البيانات المسبقة لاستكشاف أخطاء HA وإصلاحها من الوحدة الأولى (الاحتياطية)، تقوم FMC بتشغيل مهمة بعيدة لجمع نفس المعلومات من الوحدة النشطة.
  • يتم دعم مجموعة البيانات البعيدة هذه فقط عندما تكون الأجهزة قيد التشغيل 7.6 أو أعلى.
  • إذا تم العثور على أجهزة تشغل إصدارا أقل من 7.6، فسيتم تخطي تجميع البيانات عن بعد. وعلى هذا فإن لجنة إدارة الاتصالات الفيدرالية في هذه الحالة لن تجمع البيانات إلا من الوحدة الاحتياطية وتقرر المزيد من الإجراءات.

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

تقرير HA المتقدم لاستكشاف الأخطاء وإصلاحها

تقوم كل وحدة HA بإنشاء بيانات أستكشاف أخطاء HA المتقدمة وإصلاحها في شكل إعادة تمهيد ما بعد الترقية لملف JSON وتشاركها مع FMC. وإليك أمثلة من التحقق عندما يكون هناك فشل ونجاح.

مثال على فشل التحقق من HA

ملف: /ngfw/var/sf/sync/ha/upgrade_troubleshoot

{
"failover_lan" : "NA",
"error_code" : "1046 -
STARTUP_FAILOVER_CONFIG_NOT_PRESENT",
"current_time" : 1701369637,
"peer_HA_state" : "Not Detected",
"FMC_AQ_ID" : "0",
"state_link" : "NA",
"json_time" : "18:40:37 UTC Nov 30 2023",
"my_HA_state" : "Disabled",
"my_HA_role" : "Secondary",
"return_status" : "STATUS_ERROR",
"message" : "Failover config is not present on the startup
config. Device is in standalone state. Please configure failover.",
"peer_HA_role" : "Primary"
}

مثال على التحقق من HA بنجاح

ملف: /ngfw/var/sf/sync/ha/upgrade_troubleshoot

{
"return_status" : "STATUS_OK",
"message" : "No Action required.",
"current_time" : 1699526448,
"my_HA_state" : "Standby Ready",
"FMC_AQ_ID" : "0",
"retry_count" : "3",
"error_code" : "0000 - HA_OK",
"peer_HA_role" : "Secondary",
"failover_lan" : "up",
"peer_HA_state" : "Active",
"my_HA_role" : "Primary",
"state_link" : "up",
"json_time" : "10:40:48 UTC Nov 09 2
}

محتويات أستكشاف أخطاء HA وإصلاحها المتقدمة

موقع ملف أستكشاف أخطاء HA المتقدمة وإصلاحها

تحليل متقدم HA لموقع ملف JSON:

On FTD: /ngfw/var/sf/sync/ha/upgrade_troubleshoot
On FMC: /var/sf/peers//sync/ha/upgrade_troubleshoot

• يعتمد أستكشاف أخطاء HA وإصلاحها على الأمر lina.
  • إذا فشل أستكشاف الأخطاء وإصلاحها في إنشاء سجل في /ngfw/var/sf/sync/ha/upgrade_troubleshooting، فيمكن للمستخدم الرجوع إلى السجلات على /ngfw/var/log/ha_upgrade_troubleshoot.log
• /ngfw/var/sf/sync/ha/upgrade_troubleshooting والملفات /ngfw/var/log/ha_upgrade_troubleshoot.log هي جزء من ملف أستكشاف أخطاء FTD وإصلاحها.

نصائح عن تحري مشاكل إنشاء HA المتقدم

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

في مثل هذه الحالات، تحقق لمعرفة ما إذا كانت عمليات lina و ActionQueue قيد التشغيل باستخدام هذا الأمر في وضع الخبير:

pmtool status | grep lina
lina (system) - Running 5503  Indicates Lina is up and running

pmtool status | grep ActionQueueScrape
ActionQueueScrape (system) - Running 5268  Indicates action queue is up and running

حالة الإرجاع والإجراء في أستكشاف أخطاء HA المتقدمة وإصلاحها

• STATUS_INIT: وهذا يشير إلى أنه تم تشغيل أستكشاف HA وإصلاحها.
• STATUS_OK: الجهاز في حالة مستقرة. ليس مطلوب أي إجراء.
• خطأ الحالة: وهذا يحدد حدوث خطأ لم يتم تكوين HA بسببه. يحتاج المستخدم إلى إتخاذ إجراء بناء على الرسالة المعروضة أو يحتاج المستخدم إلى الاتصال ب TAC.
• Status_Retry: الأداة يستطيع كنت في واحد من الحالة متوسط. يستمر أستكشاف أخطاء HA وإصلاحها في إعادة المحاولة بعد فترة زمنية ثابتة استنادا إلى الحالة حتى تتم مواجهة STATUS_ERROR أو STATUS_OK.
  • استنادا إلى حالات الفشل التي واجهت خطأ الحالة، يتم تصنيف حالات فشل HA إلى حالتين:
    • تدخل المستخدم - يمكن للمستخدم إصلاح حالات فشل HA هذه، ويمكن للمستخدم إستئناف الترقية، حيث لا يكون تدخل TAC مطلوبا.
    • تدخل TAC - بالنسبة لعمليات فشل HA هذه، لا يمكن للمستخدم إصلاحه بنفسه؛ تدخل TAC مطلوب.

رمز الخطأ وتصنيفه

استنادا إلى رموز الأخطاء، يتم تصنيف الأخطاء كما هو موضح هنا:

رسائل تدخل المستخدم

رسائل تدخل TAC

تغييرات واجهة مستخدم مركز إدارة جدار الحماية

بنية البرامج

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

الأسئلة المتداولة

س: هل الميزة قابلة للتطبيق لوظيفة الإرجاع الخاصة بترقية FTD؟
ج: لا. لا تنطبق هذه الميزة على وظيفة الإرجاع حيث تعمل عملية الإرجاع في FTD بالتوازي، وليس 1 في 1.

س: إذا فشلت الترقية على 200_enable_maintenance_mode.pl، هل تقوم بإنشاء بيانات أستكشاف الأخطاء وإصلاحها المتقدمة؟
ج: لا. لا يتم إنشاء تحريت HA إلا بعد إعادة تشغيل ما بعد الترقية وليس أثناء فشل الترقية

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