أستكشاف أخطاء PCRF Session Manager VM Recovery - OpenStack

المقدمة

يصف هذا المستند إجراء إسترداد مدير جلسة العمل الذي تم نشره على عمليات نشر Ultra-M/OpenStack.

استكشاف الأخطاء وإصلاحها

إجراءات إسترداد مثيل مدير جلسة العمل

تشغيل مدير جلسة العمل من حالة إيقاف التشغيل

إذا كانت أي حالة في حالة إيقاف التشغيل بسبب إيقاف التشغيل المخطط أو لسبب آخر، يرجى إستخدام هذا الإجراء لبدء المثيل وتمكين مراقبة ITAD™في ESC.

1. تحقق من حالة المثيل عبر OpenStack
   
   

   source /home/stack/destackovsrc-Pcrf
   nova list --fields name,host,status | grep sm-s1
   | c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | destackovs-compute-2  | SHUTOFF|

2. تحقق مما إذا كان الكمبيوتر متوفرا وتأكد من أن الحالة قيد التشغيل.
   
   

   source /home/stack/destackovsrc
   nova hypervisor-show destackovs-compute-2 | egrep ‘status|state’
   | state                     | up                                       |
   | status                    | enabled                                  |

3. قم بتسجيل الدخول إلى مدير وحدة التحكم المرنة في الخدمات (ESC) كمستخدم مسؤول وتحقق من حالة المثيل في opdata. 
   
   

   /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata | grep sm-s1_0
   SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 VM_ERROR_STATE

4. تشغيل المثيل من OpenStack
   
   

   source /home/stack/destackovsrc-Pcrf
   nova start SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

   .
5. انتظر خمس دقائق حتى يتم إجراء التمهيد ثم تصل إلى الحالة النشطة.
   
   

   source /home/stack/destackovsrc-Pcrf
   nova list –fields name,status | grep sm-s1_0
   | c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | ACTIVE |

6. تمكين مراقبة VM في ESC بعد المثيل في الحالة النشطة.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

للحصول على مزيد من إسترداد تكوينات المثيل، ارجع إلى إجراءات نوع المثيل المحددة الواردة في القسم التالي.

إسترداد أي مثيل من حالة الخطأ

يمكن إستخدام هذا الإجراء إذا كانت حالة مثيل CPS في OpenStack خطأ:

1. تحقق من حالة المثيل في OpenStack.
   
   

   source /home/stack/destackovsrc-Pcrf
   nova list --fields name,host,status | grep sm-s1
   | c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | destackovs-compute-2  | ERROR|

2. تحقق مما إذا كان الكمبيوتر متوفرا وقم بالتشغيل بشكل جيد.
   
   

   source /home/stack/destackovsrc
   nova hypervisor-show destackovs-compute-2 | egrep ‘status|state’
   | state                     | up                                       |
   | status                    | enabled                                  |

3. قم بتسجيل الدخول إلى ESC Master كمستخدم مسؤول وتحقق من حالة المثيل في opdata.
   
   

   /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata | grep sm-s1_0
   
   SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 VM_ERROR_STATE

4. قم بإعادة تعيين حالة المثيل لإجبار المثيل على العودة إلى حالة نشطة بدلا من حالة خطأ، بمجرد القيام بذلك، قم بإعادة تشغيل المثيل.
   
   

   source /home/stack/destackovsrc-Pcrf
   
   nova reset-state –active SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226
   nova reboot –-hard  SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

5. انتظر خمس دقائق حتى يتم تحميل المثيل ثم يأتي إلى الحالة النشطة.
   
   

   source /home/stack/destackovsrc-Pcrf
   nova list –fields name,status | grep sm
   | c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | ACTIVE |

6. إذا قام "مدير نظام المجموعة" بتغيير الحالة إلى "نشط بعد إعادة التمهيد"، فقم بتمكين مراقبة VM في ESC بعد أن يكون مثيل "مدير نظام المجموعة" في حالة نشطة.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

ترحيل الاسترداد إلى حالة التشغيل/النشاط، ارجع إلى الإجراء الخاص بنوع المثيل لاسترداد التكوين/البيانات من النسخ الاحتياطي.

مدير جلسة العمل/MongoDB إستعادة

يوفر "مدير جلسة العمل" طبقة "قاعدة البيانات" لمجموعة سياسات نظام المجموعة في هذا القسم، تتم مناقشة إسترداد قواعد البيانات على مثيل تم إسترداده مؤخرا من "إدارة جلسات العمل":

عضو مجموعة النسخ المتماثلة في حالة عدم الاتصال

إذا كان عضو (أعضاء) مجموعة نسخ متماثلة في حالة عدم الاتصال، فاستخدم هذا الإجراء:

1. تحقق من حالة مجموعة النسخ المتماثلة باستخدام هذا الأمر على "إدارة نظام المجموعة".

diagnostics.sh --get_replica_status

2. سرد كافة العناصر غير المتصلة في كافة مجموعات النسخ المتماثلة.
   
   
3. قم بتشغيل الأمر على إدارة نظام المجموعة.

cd /var/qps/bin/support/mongo
build_set.sh --all --create-scripts

4. طبقة آمنة إلى وحدة (وحدات) VM الخاصة بجلسة العمل وبدء عملية الرياح الأحادية.

ssh sessionmgrXX
/etc/init.d/sessionmgr-XXXXX start

عضو (أعضاء) مجموعة النسخ المتماثلة عالقة في حالة بدء التشغيل 2/الاسترداد لفترة طويلة

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

1. تحقق من حالة مجموعة النسخ المتماثلة باستخدام هذا الأمر على "إدارة نظام المجموعة".

diagnostics.sh --get_replica_status

2. سرد كافة الأعضاء في كافة مجموعات النسخ المتماثلة.

3. طبقة آمنة إلى وحدة (وحدات) VM في جلسة العمل والحصول على موقع تخزين عملية أحادية النظام.كما هو موضح في المثال dbpath هو /var/data/sessions.1/b لعملية أحادية تعمل على جلسة العملMGR01 في المنفذ 37717.

ssh sessionmgr01
ps -ef | grep mongo | grep 37717
root      2572     1 25 Feb11 ?        24-11:43:43 /usr/bin/mongod --ipv6 --nojournal --storageEngine mmapv1 --noprealloc --smallfiles --port 37717 --dbpath=/var/data/sessions.1/b --replSet set01b --fork --pidfilepath /var/run/sessionmgr-37717.pid --oplogSize 5120 --logpath /var/log/mongodb-37717.log --logappend --quiet --slowms 500

4. إيقاف عملية mongo وتنظيف المحتويات في dBPATH:

/etc/init.d/sessionmgr-xxxxx stop
rm -rf /var/data/sessions.1/b/*

5. بدء عملية أحادية، يؤدي ذلك إلى قيام عضو مجموعة النسخ المتماثلة بمزامنة جميع البيانات من قاعدة البيانات الأساسية وليس من المستند.

/etc/init.d/sessionmgr-xxxxx start

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

إعادة إنشاء مجموعات النسخ المتماثلة

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

• Admin (بشكل عام في 27721)
• الرصيد (عادة على المنفذ 27718)
• SPR (بشكل عام على المنفذ 27720)

بمجرد التحقق من النسخ الاحتياطية واتخاذ قرار بإعادة إنشاء مجموعات النسخ المتماثلة لقاعدة البيانات، أستخدم هذا الإجراء:

1. فحصت محتويات /etc/broadhop/mongoConfig.cfg، LLD ينبغي يتلقى معلومة على ما تشكيل ينبغي كنت حاضر في هذا مبرد أو أنت يستطيع استعملت نسخة إحتياطية مبرد.
   

2. يجب أن يعمل الأمر build_set.sh —<db-name> —create على Cluster Manager، والذي يعتمد على قاعدة البيانات التي تنوي إعادة بنائها. يقوم بإنشاء كافة مجموعات النسخ المتماثلة المتعلقة ب DB هذا.

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

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

build_set.sh --
     
     
       --create --setname 
       
     

4. إذا كنت ترغب في إعادة إنشاء كافة مجموعات النسخ المتماثلة لكافة قواعد البيانات، أستخدم هذا الأمر:

build_set.sh --all --create 

إستعادة قاعدة البيانات من مجموعة النسخ المتماثلة لمادة النشر الاحتياطية

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

1. لاستعادة جميع DBs من النسخة الاحتياطية، أستخدم هذا الأمر:

config_br.py --action import --mongo-all  /mnt/backup/
     
      

2. لاستعادة قاعدة بيانات معينة من النسخ الاحتياطي من خلال config_br.py تتوفر هذه الخيارات:

• SPR

config_br.py --action import --mongo-all --spr /mnt/backup/
     
     

config_br.py --action import  --mongo-all --admin  /mnt/backup/
      
      

config_br.py --action import  --mongo-all --balance  /mnt/backup/
       
        

config_br.py --action import  --mongo-all --report  /mnt/backup/
       
       

mongorestore --host 
        
        
          --port 
         
           --db 
          
            --