إستبدال خادم الكمبيوتر UCS C240 M4 ل PCRF
المحتويات
المقدمة
يصف هذا المستند الخطوات المطلوبة لاستبدال خادم حوسبة معيب في إعداد Ultra-M يستضيف وظائف شبكة (VNF) مجموعة سياسات Cisco (CPS) الظاهرية.
معلومات أساسية
هذا المستند مخصص لأفراد Cisco المطلعين على نظام Cisco Ultra-M الأساسي وهو يفصل الخطوات المطلوبة ليتم تنفيذها على مستوى OpenStack و CPS VNF في وقت إستبدال خادم الكمبيوتر.
هيلث شيك
قبل إستبدال عقدة حوسبة، من المهم التحقق من حالة الصحة الحالية لبيئة النظام الأساسي 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
تعطيل خدمات PCRF الموجودة على VM ليتم إيقاف تشغيلها
الخطوة 1. تسجيل الدخول إلى IP الخاص بالإدارة الخاص ب VM:
[stack@XX-ospd ~]$ ssh root@
الخطوة 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 > متقدم > تكوين المعالج.
إضافة عقدة الحوسبة الجديدة إلى OverCloud
الخطوات المذكورة في هذا القسم عامة بغض النظر عن VM المستضاف من قبل عقدة الكمبيوتر.
الخطوة 1. إضافة خادم حوسبة باستخدام فهرس مختلف.
قم بإنشاء ملف add_node.json مع تفاصيل خادم الكمبيوتر الجديد الذي ستتم إضافته فقط. تأكد من عدم إستخدام رقم الفهرس لخادم الكمبيوتر الجديد من قبل. في العادة، زيادة أعلى قيمة حوسبة تالية.
على سبيل المثال، كان Compute-17 هو الأعلى سابقا، لذلك، تم إنشاء Compute-18 في حالة نظام 2vnf.
[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
تحقق من diagnostic.sh من VM الخاص بمدير المجموعة وإذا تم العثور على أي خطأ للأجهزة الافتراضية (VM) التي تم إستردادها في ذلك الحين
الخطوة 1. تسجيل الدخول إلى الجهاز الظاهري المعني.
[stack@XX-ospd ~]$ ssh root@
الخطوة 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_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_group nc:operation="delete">
<name>cm</name>
قم بتغيير <vm_group nc:operation="delete"> إلى <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 ~]# 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
التعليقات