PCRF更换计算服务器UCS C240 M4

下载选项

PDF (1.4 MB)
在各种设备上使用 Adobe Reader 查看
ePub (1.2 MB)
在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上使用各种应用查看
Mobi (Kindle) (731.1 KB)
在 Kindle 设备上查看或在多个设备上使用 Kindle 应用查看

已更新: 2021 年 1 月 27 日

文档 ID:213626

非歧视性语言

此产品的文档集力求使用非歧视性语言。在本文档集中，非歧视性语言是指不隐含针对年龄、残障、性别、种族身份、族群身份、性取向、社会经济地位和交叉性的歧视的语言。由于产品软件的用户界面中使用的硬编码语言、基于 RFP 文档使用的语言或引用的第三方产品使用的语言，文档中可能无法确保完全使用非歧视性语言。深入了解思科如何使用包容性语言。

关于此翻译

思科采用人工翻译与机器翻译相结合的方式将此文档翻译成不同语言，希望全球的用户都能通过各自的语言得到支持性的内容。请注意：即使是最好的机器翻译，其准确度也不及专业翻译人员的水平。 Cisco Systems, Inc. 对于翻译的准确性不承担任何责任，并建议您总是参考英文原始文档（已提供链接）。

简介

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

现在将<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">

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

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

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

</placement>

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

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