简介
本文档介绍在托管思科策略套件(CPS)虚拟网络功能(VNF)的Ultra-M设置中停止 — 启动故障计算服务器所需的步骤。
注意：为了定义本文档中的步骤，我们考虑了Ultra M 5.1.x版本。本文档面向熟悉Cisco Ultra-M平台的思科人员，并详细介绍在计算服务器停止启动时在OpenStack和CPS VNF级别执行所需的步骤。
先决条件
备份
在停止 — 启动计算节点之前，检查Red Hat OpenStack平台环境的当前状态非常重要。建议您检查当前状态以避免出现问题。
在恢复时，思科建议使用以下步骤备份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配置。
使用此配置可从Cluster Manager Virtual Machine(VM)备份CPS VM。
[root@CM ~]# config_br.py -a export --all /mnt/backup/CPS_backup_28092016.tar.gz
确定托管在计算节点中的虚拟机
确定托管在计算服务器上的虚拟机。
[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
注意：在此处显示的输出中，第一列对应于通用唯一IDentifier(UUID)，第二列是VM名称，第三列是VM所在的主机名。此输出的参数将用于后续部分。
禁用驻留在VM上的PCRF服务以关闭
1.登录VM的管理IP。
[stack@XX-ospd ~]$ ssh root@<Management IP>
[root@XXXSM03 ~]# monit stop all
2.如果VM是SM、OAM或Arbiter，则另请停止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的前文件运行service sessionmgr-xxxxx stop。
[root@XXXSM03 init.d]# service sessionmgr-27717 stop
平稳关闭电源
从ESC关闭VM
1.登录到与VNF对应的ESC节点并检查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名称停止VM。（VM名称在“识别托管在计算节点中的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必须进入SHUTOFF状态。
[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>
计算节点停止启动
本节中提到的步骤是通用的，与计算节点中托管的虚拟机无关。
从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 |
恢复虚拟机
从ESC恢复虚拟机
1.理想情况下，如果检查nova列表，则从OSPD，VM应处于“关闭”状态。在这种情况下，您需要从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在nova列表中处于错误状态，请执行此配置。
[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恢复VM。
[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].
检查驻留在VM上的PCRF服务
注意：如果VM处于SHUTOFF状态，则使用ESC中的esc_nc_cli将其打开。从集群管理器VM中检查diagnostics.sh，如果发现找到任何错误，则会恢复虚拟机。
1.登录到相应的VM。
[stack@XX-ospd ~]$ ssh root@<Management IP>
[root@XXXSM03 ~]# monit start all
2.如果VM是SM、OAM或Arbiter，则此外，请启动之前停止的sessionmgr服务。前文件标题为sessionmgr-xxxxx，运行service sessionmgr-xxxxx start。
[root@XXXSM03 init.d]# service sessionmgr-27717 start
3.如果仍不清除诊断，则从Cluster Manager VM执行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
反馈