إيقاف وظيفة "قواعد الشحن" و"بدء تشغيل العقدة الحسابية"

المقدمة

يصف هذا المستند الخطوات المطلوبة لإيقاف تشغيل خادم حوسبة معيب في إعداد Ultra-M يستضيف وظائف شبكة (VNF) مجموعة سياسات Cisco (CPS) الظاهرية.

ملاحظة: يتم النظر في الإصدار Ultra M 5.1.x لتحديد الإجراءات الواردة في هذا المستند. مخصص هذا المستند لأفراد Cisco المطلعين على نظام Cisco Ultra-M الأساسي وهو يفصل الخطوات المطلوبة ليتم تنفيذها على مستوى OpenStack و CPS VNF في وقت توقف بدء تشغيل خادم الكمبيوتر.

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

النسخ الاحتياطي

قبل إيقاف تشغيل عقدة حوسبة، من المهم التحقق من الحالة الحالية لبيئة النظام الأساسي ل Red Hat OpenStack. يوصى بالتحقق من الحالة الحالية لتجنب المضاعفات.

في حالة الاسترداد، توصي Cisco بإجراء نسخ إحتياطي لقاعدة بيانات OSPD باستخدام هذه الخطوات.

<[root@director ~]# mysqldump --opt --all-databases > /root/undercloud-all-databases.sql
[root@director ~]# tar --xattrs -czf undercloud-backup-`date +%F`.tar.gz /root/undercloud-all-databases.sql 
/etc/my.cnf.d/server.cnf /var/lib/glance/images /srv/node /home/stack
tar: Removing leading `/' from member names

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

[root@CM ~]# config_br.py -a export --all /mnt/backup/CPS_backup_28092016.tar.gz

تحديد الأجهزة الافتراضية المستضافة في عقدة الحوسبة

التعرف على الأجهزة الافتراضية (VM) المستضافة على خادم الحوسبة.

[stack@director ~]$ nova list --field name,host,networks | grep compute-10
| 49ac5f22-469e-4b84-badc-031083db0533 |  VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d     |  pod1-compute-10.localdomain    | Replication=10.160.137.161; Internal=192.168.1.131; Management=10.225.247.229; tb1-orch=172.16.180.129

ملاحظة: في الإخراج المبين هنا، يتوافق العمود الأول مع المعرف الفريد العالمي (UUID)، بينما يمثل العمود الثاني اسم الجهاز الظاهري (VM) بينما يمثل العمود الثالث اسم المضيف الذي يوجد به الجهاز الظاهري. سيتم إستخدام المعلمات من هذا الإخراج في الأقسام التالية.

تعطيل خدمات PCRF الموجودة على VM ليتم إيقاف تشغيلها

1. تسجيل الدخول إلى عنوان IP الخاص بإدارة الجهاز الظاهري.

[stack@XX-ospd ~]$ ssh root@<Management IP>
[root@XXXSM03 ~]# monit stop all

2. إذا كانت VMis anSM،OAMorArbiter، بالإضافة إلى ذلك، أوقف خدمات sessionMGR.

[root@XXXSM03 ~]# cd /etc/init.d
[root@XXXSM03 init.d]# ls -l sessionmgr*
-rwxr-xr-x 1 root root 4544 Nov 29 23:47 sessionmgr-27717
-rwxr-xr-x 1 root root 4399 Nov 28 22:45 sessionmgr-27721
-rwxr-xr-x 1 root root 4544 Nov 29 23:47 sessionmgr-27727

3. ملف FrontVery بعنوان sessionMGR-xxxxx تشغيل الخدمة إيقاف SESSIONmgr-xxxxx.

[root@XXXSM03 init.d]# service sessionmgr-27717 stop

إيقاف تشغيل الطاقة الرشيقة

إيقاف تشغيل VM من ESC

1. سجل الدخول إلى عقدة ESC التي تتوافق مع VNF وتحقق من حالة VM.

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                    <state>VM_ALIVE_STATE</state>
                    <vm_name> VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d</vm_name>
                    <state>VM_ALIVE_STATE</state>
<snip>

2. إيقاف الجهاز الظاهري باستخدام اسم الجهاز الظاهري الخاص به. (اسم VM الذي تمت ملاحظته من القسم " تحديد الأجهزة الافتراضية المستضافة في عقدة الحوسبة").

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d

 3. بمجرد إيقافه، يجب أن يدخل VM في حالة إيقاف التشغيل.

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                    <state>VM_ALIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                    <state>VM_ALIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d</vm_name>
                    <state>VM_SHUTOFF_STATE</state>
<snip> 

إيقاف تشغيل عقدة الحوسبة

الخطوات المذكورة في هذا القسم شائعة بغض النظر عن الأجهزة الافتراضية (VMs) المستضافة في عقدة الحوسبة.

إيقاف تشغيل عقدة الحوسبة من OSPD

1. تحقق من الحالة ثم قم بإيقاف تشغيل العقدة.

[stack@director ~]$ nova list | grep compute-10 
| 03f15071-21aa-4bcf-8fdd-acdbde305168 | pod1-stack-compute-10 | ACTIVE | - | Running | ctlplane=192.200.0.106 |

[stack@director ~]$ nova stop pod1-stack-compute-10

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

[stack@director ~]$ nova start pod1-stack-compute-10

3. تأكد من أن عقدة الكمبيوتر الجديدة في الحالة "نشط".

[stack@director ~]$ source stackrc
[stack@director ~]$ nova list |grep compute-10
| 03f15071-21aa-4bcf-8fdd-acdbde305168 | pod1-stack-compute-10 | ACTIVE | - | Running | ctlplane=192.200.0.106 |

[stack@director ~]$ source pod1-stackrc-Core
[stack@director ~]$ openstack hypervisor list |grep compute-10
| 6 | pod1-compute-10.localdomain    |

إستعادة الأجهزة الافتراضية

إسترداد VM من ESC

1. من OSPD، إذا كنت تفحص قائمة نوفا، فإن VMs ينبغي أن تكون في حالة إغلاق. في هذه الحالة، تحتاج إلى بدء تشغيل الأجهزة الافتراضية من ESC.

[admin@VNF2-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action START VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
[sudo] password for admin: 

2. أو، إذا كان VM في حالة خطأ في قائمة نوفا، قم بإجراء هذا التكوين.

[stack@director  ~]$ nova list |grep VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
| 49ac5f22-469e-4b84-badc-031083db0533 | VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d     | ERROR  | -          | NOSTATE     | 

3. الآن، استرد الجهاز الظاهري من ESC.

[admin@VNF2-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
[sudo] password for admin: 

Recovery VM Action
/opt/cisco/esc/confd/bin/netconf-console --port=830 --host=127.0.0.1 --user=admin --privKeyFile=/root/.ssh/confd_id_dsa --privKeyType=dsa --rpc=/tmp/esc_nc_cli.ZpRCGiieuW
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <ok/>
</rpc-reply>

4. مراقبة سجل الدخول في Yangesc.log.

admin@VNF2-esc-esc-0 ~]$ tail -f /var/log/esc/yangesc.log
…
14:59:50,112 07-Nov-2017 WARN  Type: VM_RECOVERY_COMPLETE
14:59:50,112 07-Nov-2017 WARN  Status: SUCCESS
14:59:50,112 07-Nov-2017 WARN  Status Code: 200
14:59:50,112 07-Nov-2017 WARN  Status Msg: Recovery: Successfully recovered VM [VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d].

تحقق من خدمات PCRF الموجودة على الجهاز الظاهري

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

1. الدخول إلى الجهاز الظاهري المعني.

[stack@XX-ospd ~]$ ssh root@<Management IP>
[root@XXXSM03 ~]# monit start all

2. إذا كانت VMis anSM،OAMorArbiter، بالإضافة إلى ذلك، ابدأ تشغيل خدمات SessionMGR التي توقفت قبل ذلك. الملف الأمامي بعنوان sessionMGR-xxxxx، قم بتشغيل جلسة العمل mgr-xxxxx بداية.

[root@XXXSM03 init.d]# service sessionmgr-27717 start

 3. إذا لم يكن التشخيص بعد واضحا، فقم بتنفيذ build_all.sh من نظام VM الخاص بإدارة نظام المجموعة ثم قم بتنفيذ VM-init على الجهاز الظاهري الخاص.

/var/qps/install/current/scripts/build_all.sh

ssh VM   e.g. ssh pcrfclient01 
/etc/init.d/vm-init