المحتويات

المقدمة

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

هيلث شيك

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

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

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

إزالة عقدة الحوسبة من قائمة تجميع Nova

حذف عقدة الحوسبة

حذف من Overcloud

حذف عقدة الحوسبة من قائمة الخدمات

حذف عوامل النترونات

حذف من قاعدة البيانات التهكمية

تثبيت عقدة الحوسبة الجديدة

إضافة عقدة الحوسبة الجديدة إلى OverCloud

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

إضافة إلى قائمة تجميع نوفا

إسترداد VM من وحدة التحكم المرنة في الخدمات (ESC)

التحقق من خدمات وظيفة سياسة وقواعد الشحن (PCRF) الموجودة على VM من Cisco

حذف وإعادة نشر جهاز VM واحد أو أكثر في حالة فشل إسترداد ESC

الحصول على أحدث قالب ESC للموقع

الإجراء الخاص بتعديل الملف

الخطوة 1. قم بتعديل ملف قالب التصدير.

الخطوة 2. قم بتشغيل ملف قالب التصدير المعدل.

الخطوة 3. قم بتعديل ملف قالب التصدير لإضافة الأجهزة الافتراضية.

الخطوة 4. قم بتشغيل ملف قالب التصدير المعدل.

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

الخطوة 6. قم بتشغيل التشخيصات للتحقق من حالة النظام.

معلومات ذات صلة

المقدمة

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

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

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

ملاحظة: يتم النظر في الإصدار Ultra M 5.1.x لتحديد الإجراءات الواردة في هذا المستند.

هيلث شيك

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

الخطوة 1. من نشر OpenStack (OSPD).

[root@director ~]$ su - stack

[stack@director ~]$ cd ansible

[stack@director ansible]$ ansible-playbook -i inventory-new openstack_verify.yml  -e platform=pcrf

الخطوة 2. تحقق من صحة النظام من تقرير UltraTram-health الذي يتم إنشاؤه كل خمس عشرة دقيقة.

[stack@director ~]# cd /var/log/cisco/ultram-health

الخطوة 3. تحقق من ملف ultram_health_os.report.يجب أن تظهر الخدمات فقط كحالة xxx هي الوكيلneton-sriov-nic.service.

الخطوة 4. للتحقق من تشغيل Rabbitmq لكافة وحدات التحكم من OSPD.

[stack@director ~]# for i in $(nova list| grep controller | awk '{print $12}'| sed 's/ctlplane=//g') ; do (ssh -o StrictHostKeyChecking=no heat-admin@$i "hostname;sudo rabbitmqctl eval 'rabbit_diagnostics:maybe_stuck().'" ) & done

الخطوة 5. التحقق من تمكين الجهاز

[stack@director ~]# sudo pcs property show stonith-enabled

الخطوة 6. تحقق كافة وحدات التحكم من حالة أجهزة الكمبيوتر.

- يتم بدء تشغيل جميع عقد وحدات التحكم تحت نسخ-بروكسي.

- جميع عقد وحدات التحكم نشطة تحت الجاليرا.

- تم بدء تشغيل جميع عقد وحدات التحكم تحت Rabbitmq.

- عقدة وحدة تحكم نشطة وعقدان جاهزان أسفل REDIS.

الخطوة 7. من OSPD.

[stack@director ~]$ for i in $(nova list| grep controller | awk '{print $12}'| sed 's/ctlplane=//g') ; do (ssh -o StrictHostKeyChecking=no heat-admin@$i "hostname;sudo pcs status" ) ;done

الخطوة 8. تحقق من أن جميع خدمات OpenStack نشطة، من OSPD التي تشغل هذا الأمر.

[stack@director ~]# sudo systemctl list-units "openstack*" "neutron*" "openvswitch*"

الخطوة 9. تحقق من أن حالة CEPH هي HEALTH_OK لوحدات التحكم.

[stack@director ~]# for i in $(nova list| grep controller | awk '{print $12}'| sed 's/ctlplane=//g') ; do (ssh -o StrictHostKeyChecking=no heat-admin@$i "hostname;sudo ceph -s" ) ;done

الخطوة 10. التحقق من سجلات مكون OpenStack. ابحث عن أي خطأ:

Neutron:

[stack@director ~]# sudo tail -n 20 /var/log/neutron/{dhcp-agent,l3-agent,metadata-agent,openvswitch-agent,server}.log

Cinder:

[stack@director ~]# sudo tail -n 20 /var/log/cinder/{api,scheduler,volume}.log

Glance:

[stack@director ~]# sudo tail -n 20 /var/log/glance/{api,registry}.log

الخطوة 11. من OSPD قم بهذه عمليات التحقق ل API.

[stack@director ~]$ source

[stack@director ~]$ nova list

[stack@director ~]$ glance image-list

[stack@director ~]$ cinder list

[stack@director ~]$ neutron net-list

الخطوة 12. التحقق من صحة الخدمات.

Every service status should be “up”:

[stack@director ~]$ nova service-list

Every service status should be “ :-)”:

[stack@director ~]$ neutron agent-list

Every service status should be “up”:

[stack@director ~]$ cinder service-list

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

في حالة الاسترداد، توصي 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.

من أجل نسخ CPS VMs إحتياطيا، من برنامج Cluster Manager VM:

[root@CM ~]# config_br.py -a export --all /mnt/backup/CPS_backup_$(date +\%Y-\%m-\%d).tar.gz

or

[root@CM ~]# config_br.py -a export --mongo-all --svn --etc --grafanadb --auth-htpasswd --haproxy /mnt/backup/$(hostname)_backup_all_$(date +\%Y-\%m-\%d).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 الخاص بالإدارة الخاص ب VM:

[stack@XX-ospd ~]$ ssh root@

[root@XXXSM03 ~]# monit stop all

الخطوة 2. إذا كان VM هو SM، OAM أو المحكم، بالإضافة إلى ذلك، أوقف خدمات 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. لكل ملف بعنوان sessionmgr-xxxxx، قم بتشغيل جلسة الخدمة mgr-xxxxx توقف:

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

إزالة عقدة الحوسبة من قائمة تجميع Nova

الخطوة 1. قم بسرد التجميعات والتعرف على التجميع المطابق لخادم الحوسبة استنادا إلى VNF الذي يستضيفه. وعادة ما يكون بتنسيق <VNFNAME>-SERVICE<X>:

[stack@director ~]$ nova aggregate-list

+----+-------------------+-------------------+

| Id | Name              | Availability Zone |

+----+-------------------+-------------------+

| 29 | POD1-AUTOIT   | mgmt              |

| 57 | VNF1-SERVICE1 | -                 |

| 60 | VNF1-EM-MGMT1 | -                 |

| 63 | VNF1-CF-MGMT1 | -                 |

| 66 | VNF2-CF-MGMT2 | -                 |

| 69 | VNF2-EM-MGMT2 | -                 |

| 72 | VNF2-SERVICE2 | -                 |

| 75 | VNF3-CF-MGMT3 | -                 |

| 78 | VNF3-EM-MGMT3 | -                 |

| 81 | VNF3-SERVICE3 | -                 |

+----+-------------------+-------------------+

في هذه الحالة، ينتمي خادم الكمبيوتر الذي سيتم إستبداله إلى VNF2. وبالتالي، فإن قائمة التجميع المقابلة هي VNF2-SERVICE2.

الخطوة 2. قم بإزالة عقدة الكمبيوتر من التجميع المحدد (قم بإزالة الاسم المضيف الملاحظ من القسم التعرف على الأجهزة الافتراضية (VMs) المستضافة في عقدة الحوسبة��

nova aggregate-remove-host

[stack@director ~]$ nova aggregate-remove-host VNF2-SERVICE2 pod1-compute-10.localdomain

الخطوة 3. تحقق من إزالة عقدة الكمبيوتر من التجميعات. الآن، يجب ألا يتم إدراج المضيف ضمن التجميع:

nova aggregate-show

[stack@director ~]$ nova aggregate-show VNF2-SERVICE2

حذف عقدة الحوسبة

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

حذف من Overcloud

الخطوة 1. قم بإنشاء ملف برنامج نصي باسم delete_node.sh بالمحتويات كما هو موضح هنا. تأكد من أن القوالب المذكورة تماثل القوالب المستخدمة في البرنامج النصي deploy.sh المستخدم لنشر المكدس.

delete_node.sh

openstack overcloud node delete --templates -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml -e /home/stack/custom-templates/layout.yaml --stack

[stack@director ~]$ source stackrc

[stack@director ~]$ /bin/sh delete_node.sh

+ openstack overcloud node delete --templates -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml -e /home/stack/custom-templates/layout.yaml --stack pod1 49ac5f22-469e-4b84-badc-031083db0533

Deleting the following nodes from stack pod1:

- 49ac5f22-469e-4b84-badc-031083db0533

Started Mistral Workflow. Execution ID: 4ab4508a-c1d5-4e48-9b95-ad9a5baa20ae

real   0m52.078s

user   0m0.383s

sys    0m0.086s

الخطوة 2. انتظر حتى يتم نقل عملية مكدس OpenStack إلى حالة COMPLETE.

[stack@director ~]$  openstack stack list

+--------------------------------------+------------+-----------------+----------------------+----------------------+

| ID                                   | Stack Name | Stack Status    | Creation Time        | Updated Time         |

+--------------------------------------+------------+-----------------+----------------------+----------------------+

| 5df68458-095d-43bd-a8c4-033e68ba79a0 | pod1 | UPDATE_COMPLETE | 2018-05-08T21:30:06Z | 2018-05-08T20:42:48Z |

+--------------------------------------+------------+-----------------+----------------------+----------------------+

حذف عقدة الحوسبة من قائمة الخدمات

احذف خدمة الحوسبة من قائمة الخدمات:

[stack@director ~]$ source corerc

[stack@director ~]$ openstack compute service list | grep compute-8

| 404 | nova-compute     | pod1-compute-8.localdomain     | nova     | enabled | up    | 2018-05-08T18:40:56.000000 |

openstack compute service delete

[stack@director ~]$ openstack compute service delete 404

حذف عوامل النترونات

احذف عامل النترونات القديم المرتبط وعامل Open VSWITCH الخاص بخادم الحوسبة:

[stack@director ~]$ openstack network agent list | grep compute-8

| c3ee92ba-aa23-480c-ac81-d3d8d01dcc03 | Open vSwitch agent | pod1-compute-8.localdomain     | None              | False  | UP    | neutron-openvswitch-agent |

| ec19cb01-abbb-4773-8397-8739d9b0a349 | NIC Switch agent   | pod1-compute-8.localdomain     | None              | False  | UP    | neutron-sriov-nic-agent   |

openstack network agent delete

[stack@director ~]$ openstack network agent delete c3ee92ba-aa23-480c-ac81-d3d8d01dcc03

[stack@director ~]$ openstack network agent delete ec19cb01-abbb-4773-8397-8739d9b0a349

حذف من قاعدة البيانات التهكمية

قم بحذف عقدة من قاعدة البيانات التهكمية وتحقق منها.

[stack@director ~]$ source stackrc

nova show

| grep hypervisor

[stack@director ~]$ nova show pod1-compute-10 | grep hypervisor

| OS-EXT-SRV-ATTR:hypervisor_hostname  | 4ab21917-32fa-43a6-9260-02538b5c7a5a

ironic node-delete

[stack@director ~]$ ironic node-delete 4ab21917-32fa-43a6-9260-02538b5c7a5a

[stack@director ~]$ ironic node-list (node delete must not be listed now)

تثبيت عقدة الحوسبة الجديدة

يمكن الرجوع إلى الخطوات الخاصة بتثبيت خادم UCS C240 M4 جديد وخطوات الإعداد الأولية من: دليل خدمة وتثبيت خادم Cisco UCS C240 M4

الخطوة 1. بعد تثبيت الخادم، قم بإدراج الأقراص الثابتة في الفتحات ذات الصلة كالخادم القديم.

الخطوة 2. قم بتسجيل الدخول إلى الخادم باستخدام CIMC IP.

الخطوة 3. قم بإجراء ترقية BIOS إذا لم تكن البرامج الثابتة متوافقة مع الإصدار الموصى به المستخدم سابقا. تم توضيح خطوات ترقية BIOS هنا: دليل ترقية BIOS للخادم المركب على حامل Cisco UCS C-Series

الخطوة 4. للتحقق من حالة محركات الأقراص المادية، انتقل إلى وحدة التخزين > وحدة التحكم RAID النمطية Cisco 12G SAS (slot-HBA) > معلومات محرك الأقراص المادية. يجب أن يكون غير مكون جيدا

يمكن أن تكون وحدة التخزين الموضحة هنا محرك أقراص مزود بذاكرة مصنوعة من مكونات صلبة (SSD).

الخطوة 5. لإنشاء محرك أقراص افتراضي من محركات الأقراص المادية المزودة بتقنية RAID المستوى 1، انتقل إلى التخزين > وحدة التحكم RAID النمطية Cisco 12G SAS (slot-HBA) > معلومات وحدة التحكم > إنشاء محرك أقراص افتراضي من محركات الأقراص المادية غير المستخدمة

الخطوة 6. حدد معرف فئة المورد (VD) وقم بتكوين المجموعة كمحرك أقراص تمهيد، كما هو موضح في الصورة.

الخطوة 7. لتمكين IPMI عبر LAN، انتقل إلى Admin > خدمات الاتصالات > خدمات الاتصال، كما هو موضح في الصورة.

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

ملاحظة: ترتبط الصورة الموضحة هنا وخطوات التكوين المذكورة في هذا القسم بالإصدار 3.0(3e) من البرنامج الثابت، وقد تكون هناك إختلافات طفيفة إذا كنت تعمل على إصدارات أخرى

إضافة عقدة الحوسبة الجديدة إلى OverCloud

الخطوات المذكورة في هذا القسم عامة بغض النظر عن VM المستضاف من قبل عقدة الكمبيوتر.

الخطوة 1. إضافة خادم حوسبة باستخدام فهرس مختلف.

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

على سبيل المثال، كان Compute-17 هو الأعلى سابقا، لذلك، تم إنشاء Compute-18 في حالة نظام 2vnf.

ملاحظة: ضع في اعتبارك صيغة json.

[stack@director ~]$ cat add_node.json

{

"nodes":[

{

"mac":[

"

"

],

"capabilities": "node:compute-18,boot_option:local",

"cpu":"24",

"memory":"256000",

"disk":"3000",

"arch":"x86_64",

"pm_type":"pxe_ipmitool",

"pm_user":"admin",

"pm_password":"<PASSWORD>",

"pm_addr":"192.100.0.5"

}

]

}

الخطوة 2. إستيراد ملف json.

[stack@director ~]$ openstack baremetal import --json add_node.json

Started Mistral Workflow. Execution ID: 78f3b22c-5c11-4d08-a00f-8553b09f497d

Successfully registered node UUID 7eddfa87-6ae6-4308-b1d2-78c98689a56e

Started Mistral Workflow. Execution ID: 33a68c16-c6fd-4f2a-9df9-926545f2127e

Successfully set all nodes to available.

الخطوة 3. قم بتشغيل إدخال العقدة باستخدام UUID الذي تمت ملاحظته من الخطوة السابقة.

[stack@director ~]$ openstack baremetal node manage 7eddfa87-6ae6-4308-b1d2-78c98689a56e

[stack@director ~]$ ironic node-list |grep 7eddfa87

| 7eddfa87-6ae6-4308-b1d2-78c98689a56e | None | None                                 | power off   | manageable         | False       |

[stack@director ~]$ openstack overcloud node introspect 7eddfa87-6ae6-4308-b1d2-78c98689a56e --provide

Started Mistral Workflow. Execution ID: e320298a-6562-42e3-8ba6-5ce6d8524e5c

Waiting for introspection to finish...

Successfully introspected all nodes.

Introspection completed.

Started Mistral Workflow. Execution ID: c4a90d7b-ebf2-4fcb-96bf-e3168aa69dc9

Successfully set all nodes to available.

[stack@director ~]$ ironic node-list |grep available

| 7eddfa87-6ae6-4308-b1d2-78c98689a56e | None | None                                 | power off   | available          | False       |

الخطوة 4. إضافة عناوين IP إلى custom-templates/layout.yml ضمن ComputeIPs. تضيف هذا العنوان إلى نهاية القائمة لكل نوع، compute-0 الظاهر هنا كمثال.

ComputeIPs:

internal_api:

- 11.120.0.43

- 11.120.0.44

- 11.120.0.45

- 11.120.0.43   <<< take compute-0 .43 and add here

tenant:

- 11.117.0.43

- 11.117.0.44

- 11.117.0.45

- 11.117.0.43   << and here

storage:

- 11.118.0.43

- 11.118.0.44

- 11.118.0.45

- 11.118.0.43   << and here

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

[stack@director ~]$ ./deploy.sh

++ openstack overcloud deploy --templates -r /home/stack/custom-templates/custom-roles.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml --stack ADN-ultram --debug --log-file overcloudDeploy_11_06_17__16_39_26.log --ntp-server 172.24.167.109 --neutron-flat-networks phys_pcie1_0,phys_pcie1_1,phys_pcie4_0,phys_pcie4_1 --neutron-network-vlan-ranges datacentre:1001:1050 --neutron-disable-tunneling --verbose --timeout 180

…

Starting new HTTP connection (1): 192.200.0.1

"POST /v2/action_executions HTTP/1.1" 201 1695

HTTP POST http://192.200.0.1:8989/v2/action_executions 201

Overcloud Endpoint: http://10.1.2.5:5000/v2.0

Overcloud Deployed

clean_up DeployOvercloud:

END return value: 0

real   38m38.971s

user   0m3.605s

sys    0m0.466s

الخطوة 6. انتظر حتى اكتمال حالة مكدس OpenStack.

[stack@director ~]$ openstack stack list

+--------------------------------------+------------+-----------------+----------------------+----------------------+

| ID                                   | Stack Name | Stack Status    | Creation Time        | Updated Time         |

+--------------------------------------+------------+-----------------+----------------------+----------------------+

| 5df68458-095d-43bd-a8c4-033e68ba79a0 | ADN-ultram | UPDATE_COMPLETE | 2017-11-02T21:30:06Z | 2017-11-06T21:40:58Z |

+--------------------------------------+------------+-----------------+----------------------+----------------------+

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

[stack@director ~]$ source stackrc

[stack@director ~]$ nova list |grep compute-18

| 0f2d88cd-d2b9-4f28-b2ca-13e305ad49ea | pod1-compute-18    | ACTIVE | -          | Running     | ctlplane=192.200.0.117 |

[stack@director ~]$ source corerc

[stack@director ~]$ openstack hypervisor list |grep compute-18

| 63 | pod1-compute-18.localdomain    |

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

إضافة إلى قائمة تجميع نوفا

قم بإضافة عقدة الحوسبة إلى مضيف التجميع وتحقق من إضافة المضيف.

nova aggregate-add-host

[stack@director ~]$ nova aggregate-add-host VNF2-SERVICE2 pod1-compute-18.localdomain

nova aggregate-show

[stack@director ~]$ nova aggregate-show VNF2-SERVICE2

إسترداد VM من وحدة التحكم المرنة في الخدمات (ESC)

الخطوة 1. ال 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     |

الخطوة 2. إسترداد VM من 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

الخطوة 3. مراقبة سجل الدخول في 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) الموجودة على VM من Cisco

ملاحظة: إذا كان VM في حالة إيقاف التشغيل، فقم بتشغيل esc_nc_cli من ESC.

تحقق من diagnostic.sh من VM الخاص بمدير المجموعة وإذا تم العثور على أي خطأ للأجهزة الافتراضية (VM) التي تم إستردادها في ذلك الحين

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

[stack@XX-ospd ~]$ ssh root@

[root@XXXSM03 ~]# monit start all

الخطوة 2. إذا كان VM هو SM، OAM أو المحكم، بالإضافة إلى ذلك، ابدأ تشغيل خدمات SessionMGR التي توقفت قبل ذلك:

لكل ملف بعنوان sessionMGR-xxxxx، قم بتشغيل جلسة الخدمة mgr-xxxxx بداية:

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

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

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

ssh VM   e.g. ssh pcrfclient01

/etc/init.d/vm-init

حذف وإعادة نشر جهاز VM واحد أو أكثر في حالة فشل إسترداد ESC

إذا لم يعمل أمر إسترداد ESC (أعلاه) (VM_RECOVERY_FAILED)، فقم بحذف وحدات VM الفردية وإعادة قراءتها.

الحصول على أحدث قالب ESC للموقع

من بوابة ESC:

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

الخطوة 2. يتم تقديم خيار لتنزيل القالب إلى الجهاز المحلي، تحقق من حفظ الملف، كما هو موضح في الصورة.

الخطوة 3. كما هو موضح في الصورة، حدد موقعا وقم بحفظ الملف للاستخدام لاحقا.

الخطوة 4. قم بتسجيل الدخول إلى Active ESC لحذف الموقع ونسخ الملف المحفوظ أعلاه في ESC في هذا الدليل.

/opt/cisco/esc/cisco-cps/config/gr/tmo/gen

الخطوة 5. تغيير الدليل إلى /opt/cisco/esc/cisco-cps/config/gr/tmo/gen:

cd /opt/cisco/esc/cisco-cps/config/gr/tmo/gen

الإجراء الخاص بتعديل الملف

الخطوة 1. قم بتعديل ملف قالب التصدير.

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

ملف قالب التصدير خاص بمجموعة معينة.

يوجد داخل هذا النظام عدة VM_GROUPS.  هناك vm_group واحدة أو أكثر لكل نوع من أنواع الأجهزة الافتراضية (PD و PS و SM و OM).

ملاحظة: تحتوي بعض VM_GROUPS على أكثر من جهاز VM واحد.  سيتم حذف كافة الأجهزة الافتراضية داخل هذه المجموعة وإعادة إضافتها.

ضمن عملية النشر هذه، يلزمك تمييز مجموعة أو أكثر من مجموعات vm_groups للحذف.

مثال:

<vm_group>

<name>cm</name>

قم بتغيير <vm_group>الآن إلى <vm_group nc:operation="delete"> واحفظ التغييرات.

الخطوة 2. قم بتشغيل ملف قالب التصدير المعدل.

من ESC Run:

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli edit-config /opt/cisco/esc/cisco-cps/config/gr/tmo/gen/

من بوابة ESC، يجب أن تكون قادرا على رؤية جهاز افتراضي (VM) واحد أو أكثر ينتقل إلى حالة إلغاء النشر ثم يختفي تماما.

يمكن تعقب التقدم في مركز الأنظمة الإلكترونية (ESC) على العنوان /var/log/esc/yangesc.log

مثال:

09:09:12,608 29-Jan-2018 INFO  ===== UPDATE SERVICE REQUEST RECEIVED(UNDER TENANT) =====

09:09:12,608 29-Jan-2018 INFO  Tenant name: Pcrf

09:09:12,609 29-Jan-2018 INFO  Deployment name: WSP1-tmo

09:09:29,794 29-Jan-2018 INFO

09:09:29,794 29-Jan-2018 INFO  ===== CONFD TRANSACTION ACCEPTED  =====

09:10:19,459 29-Jan-2018 INFO

09:10:19,459 29-Jan-2018 INFO  ===== SEND NOTIFICATION STARTS =====

09:10:19,459 29-Jan-2018 INFO  Type: VM_UNDEPLOYED

09:10:19,459 29-Jan-2018 INFO  Status: SUCCESS

09:10:19,459 29-Jan-2018 INFO  Status Code: 200

|

|

|

09:10:22,292 29-Jan-2018 INFO  ===== SEND NOTIFICATION STARTS =====

09:10:22,292 29-Jan-2018 INFO  Type: SERVICE_UPDATED

09:10:22,292 29-Jan-2018 INFO  Status: SUCCESS

09:10:22,292 29-Jan-2018 INFO  Status Code: 200

الخطوة 3. قم بتعديل ملف قالب التصدير لإضافة الأجهزة الافتراضية.

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

يتم تقسيم ملف قالب التصدير إلى عمليتي نشر (cluster1 / cluster2).

يوجد في كل مجموعة vm_group. هناك vm_group واحدة أو أكثر لكل نوع من أنواع الأجهزة الافتراضية (PD و PS و SM و OM).

ملاحظة: تحتوي بعض VM_GROUPS على أكثر من جهاز VM واحد.  ستتم إعادة إضافة جميع الأجهزة الافتراضية ضمن هذه المجموعة.

مثال:

<vm_group nc:operation="delete">

<name>cm</name>

قم بتغيير <vm_group nc:operation="delete"> إلى <vm_group> فقط.

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

<الوضع>

<type>zone_host</type>

<enforcement>صارم</enforcement>

<host>wsstackovs-compute-4.localdomain</host>

</الوضع>

قم بتحديث اسم المضيف الظاهر في القسم السابق إلى اسم المضيف الجديد كما هو منصوص عليه من قبل فريق Ultra-M قبل تنفيذ أمر التوريد هذا. بعد تثبيت المضيف الجديد، احفظ التغييرات.

الخطوة 4. قم بتشغيل ملف قالب التصدير المعدل.

من ESC Run:

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli edit-config /opt/cisco/esc/cisco-cps/config/gr/tmo/gen/

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

يمكن تعقب التقدم في مركز الأنظمة الإلكترونية (ESC) على العنوان /var/log/esc/yangesc.log

مثال:

09:14:00,906 29-Jan-2018 INFO  ===== UPDATE SERVICE REQUESTRECEIVED (UNDER TENANT) =====

09:14:00,906 29-Jan-2018 INFO  Tenant name: Pcrf

09:14:00,906 29-Jan-2018 INFO  Deployment name: WSP1-tmo

09:14:01,542 29-Jan-2018 INFO

09:14:01,542 29-Jan-2018 INFO  ===== CONFD TRANSACTION ACCEPTED  =====

09:16:33,947 29-Jan-2018 INFO

09:16:33,947 29-Jan-2018 INFO  ===== SEND NOTIFICATION STARTS =====

09:16:33,947 29-Jan-2018 INFO  Type: VM_DEPLOYED

09:16:33,947 29-Jan-2018 INFO  Status: SUCCESS

09:16:33,947 29-Jan-2018 INFO  Status Code: 200

|

|

|

09:19:00,148 29-Jan-2018 INFO  ===== SEND NOTIFICATION STARTS =====

09:19:00,148 29-Jan-2018 INFO  Type: VM_ALIVE

09:19:00,148 29-Jan-2018 INFO  Status: SUCCESS

09:19:00,148 29-Jan-2018 INFO  Status Code: 200

|

|

|

09:19:00,275 29-Jan-2018 INFO  ===== SEND NOTIFICATION STARTS =====

09:19:00,275 29-Jan-2018 INFO  Type: SERVICE_UPDATED

09:19:00,275 29-Jan-2018 INFO  Status: SUCCESS

09:19:00,275 29-Jan-2018 INFO  Status Code: 200

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

تحقق مما إذا كانت خدمات PCRF معطلة أم لا وقم بتشغيلها.

[stack@XX-ospd ~]$ ssh root@

[root@XXXSM03 ~]# monsum

[root@XXXSM03 ~]# monit start all

إذا كان VM هو SM، OAM أو المحكم، بالإضافة إلى ذلك، ابدأ خدمات SessionMGR التي توقفت قبل ذلك:

لكل ملف بعنوان sessionMGR-xxxxx تشغيل جلسة خدمة MGR-xxxxx بداية:

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

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

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

ssh VM   e.g. ssh pcrfclient01

/etc/init.d/vm-init

الخطوة 6. قم بتشغيل التشخيصات للتحقق من حالة النظام.

[root@XXXSM03 init.d]# diagnostics.sh

معلومات ذات صلة

- https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/director_installati...

- https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/director_installati...

- الدعم التقني والمستندات - Cisco Systems