目录

简介

先决条件

确定托管在计算节点中的虚拟机

平稳关闭电源

计算节点停止启动

恢复虚拟机

简介

本文档介绍在托管思科策略套件(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