目录

简介

背景信息

运行状况检查

备份

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

禁用驻留在VM上的PCRF服务以关闭

从Nova聚合列表中删除计算节点

计算节点删除

从Overcloud中删除

从服务列表中删除计算节点

删除中子代理

从Ironic数据库中删除

安装新计算节点

将新计算节点添加到超云

恢复虚拟机

Nova聚合列表的附加项

从弹性服务控制器(ESC)恢复虚拟机

检查驻留在虚拟机上的思科策略和计费规则功能(PCRF)服务

在ESC恢复失败时删除并重新部署一个或多个VM

获取网站的最新ESC模板

修改文件的过程

步骤1.修改导出模板文件。

步骤2.运行修改的导出模板文件。

步骤3.修改导出模板文件以添加虚拟机。

步骤4.运行修改的导出模板文件。

步骤5.检查驻留在VM上的PCRF服务。

步骤6.运行诊断程序以检查系统状态。

相关信息

简介

本文档介绍在托管思科策略套件(CPS)虚拟网络功能(VNF)的Ultra-M设置中更换有故障的计算服务器所需的步骤。

背景信息

本文档面向熟悉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.从每15分钟生成的ultram-health报告检验系统的运行状况。

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

步骤3.检查文件ultram_health_os.report。唯一的服务应显示为XXX 状态是neutron-sriov-nic-agent.service。

步骤4.检查OSPD中运行的所有控制器是否运行rabbitmq。

[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.检验Stonith是否已启用

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

步骤6.对于所有控制器，检验PCS状态。

- 所有控制器节点在haproxy-clone下启动。

- 所有控制器节点在galera下都处于活动状态。

- 所有控制器节点都在Rabbitmq下启动。

- 1个控制器节点处于主用状态，2个备用状态。

步骤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.从OSPD运行此命令，验证所有openstack服务是否都处于活动状态。

[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

备份

在恢复时，思科建议使用以下步骤备份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 VM备份CPS 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

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

确定托管在计算服务器上的虚拟机：

[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名称，第三列是VM所在的主机名。此输出的参数将用于后续部分。

禁用驻留在VM上的PCRF服务以关闭

步骤1.登录VM的管理IP:

[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的每个文件，运行service sessionmgr-xxxxx stop:

[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.从识别的聚合中删除计算节点(通过“识别在计算节点中托管的VM”部分中注明的主机名删除)��

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

计算节点删除

本节中提到的步骤是通用的，与计算节点中托管的虚拟机无关。

从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堆栈操作移至“完成”状态。

[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

删除中子代理

删除旧的关联中子代理并打开计算服务器的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

从Ironic数据库中删除

从Ironic数据库中删除节点并对其进行验证。

[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升级步骤如下：Cisco UCS C系列机架式服务器BIOS升级指南

步骤4.要验证物理驱动器的状态，请导航到Storage > Cisco 12G SAS模块化RAID控制器(SLOT-HBA)> Physical Drive Info。它必须未配置良好

此处显示的存储可以是SSD驱动器。

步骤5.要从RAID级别为1的物理驱动器创建虚拟驱动器，请导航到Storage > Cisco 12G SAS模块化RAID控制器(SLOT-HBA)> Controller Info > Create Virtual Drive from Unused Physical Drives

步骤6.选择VD并配置Set as Boot Drive(设置为引导驱动器)，如图所示。

步骤7.要启用IPMI over LAN，请导航至Admin > Communication Services > Communication Services，如图所示。

步骤8.要禁用超线程（如图所示），请导航至Compute > BIOS > Configure BIOS > Advanced > Processor Configuration。

注意：此处显示的映像和本节中提及的配置步骤均参考固件版本3.0(3e)，如果您使用其他版本，可能会略有变化

将新计算节点添加到超云

本节中提到的步骤是通用的，与计算节点托管的VM无关。

步骤1.添加具有不同索引的计算服务器。

创建仅包含要添加的新计算服务器详细信息的add_node.json文件。确保以前未使用新计算服务器的索引号。通常，增加下一个最高的计算值。

示例：最早的是compute-17，因此，在2-vnf系统的情况下创建compute-18。

注意：注意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”下将IP地址添加到custom-templates/layout.yml。您将该地址添加到每个类型的列表末尾，此处显示的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聚合列表的附加项

将计算节点添加到聚合主机并验证主机是否已添加。

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

从弹性服务控制器(ESC)恢复虚拟机

步骤1. 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     |

步骤2.从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处于关闭状态，则使用ESC中的esc_nc_cli打开它电源。

从集群管理器VM中检查diagnostics.sh，如果发现任何针对恢复的VM的错误，则

步骤1.登录到相应的VM。

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

[root@XXXSM03 ~]# monit start all

步骤2.如果VM是SM、OAM或仲裁，除此之外，请启动之前停止的sessionmgr服务：

对于标有sessionmgr-xxxxx的每个文件，运行service sessionmgr-xxxxx start:

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

如果诊断仍未清除，则从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

在ESC恢复失败时删除并重新部署一个或多个VM

如果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关联的VM组。

导出模板文件用于特定群集。

该集群中有多个vm_group。  每个VM类型(PD、PS、SM、OM)有一个或多个vm_groups。

注意：某些vm_groups有多个VM。  该组中的所有VM将被删除并重新添加。

在该部署中，您需要标记一个或多个vm_groups以进行删除。

示例：

<vm_group>

<name>cm</name>

现在将<vm_group>更改为<vm_group nc:operation="delete">并保存更改。

步骤2.运行修改的导出模板文件。

从ESC运行：

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

在ESC门户中，您应该能够看到一个或多个VM，这些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关联的VM组。

导出模板文件分为两个部署(cluster1 / cluster2)。

每个集群中都有一个vm_group。每个VM类型(PD、PS、SM、OM)有一个或多个vm_groups。

注意：某些vm_groups有多个VM。  将重新添加该组中的所有VM。

示例：

<vm_group nc:operation="delete">

<name>cm</name>

将<vm_group nc:operation="delete">更改为<vm_group>。

注意：如果因主机被替换而需要重建VM，则主机的主机名可能已更改。  如果主机的主机名已更改，则需要更新vm_group放置部分中的主机名。

<placement>

<type>zone_host</type>

<enforcement>严格</enforcement>

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

</placement>

在执行此MOP之前，将上一节中显示的主机名称更新为Ultra-M团队提供的新主机名。安装新主机后，保存更改。

步骤4.运行修改的导出模板文件。

从ESC运行：

/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.检查驻留在VM上的PCRF服务。

检查PCRF服务是否关闭并启动它们。

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

[root@XXXSM03 ~]# monsum

[root@XXXSM03 ~]# monit start all

如果VM是SM、OAM或仲裁，则另请启动之前停止的sessionmgr服务：

对于标有sessionmgr-xxxxx的每个文件，运行service sessionmgr-xxxxx start:

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

如果诊断仍不清除，请从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

步骤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