简介
本文档介绍如何恢复在Ultra-M/Openstack部署上部署的思科虚拟策略和计费规则功能(vPCRF)实例。
作者：思科高级服务部Nitesh Bansal。
先决条件
要求
思科建议您了解以下主题：
- OpenStack
- CPS
- 现在可以使用部署受影响实例的计算。
- 计算资源在与受影响实例相同的可用区域中可用。
使用的组件
本文档中的信息基于CPS，适用于所有版本。
本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。
故障排除
从关闭状态打开仲裁电源
如果任何实例由于计划的关闭或其他原因处于关闭状态，请使用以下步骤启动该实例并在弹性服务控制器(ESC)中启用其监控。
步骤1.通过OpenStack检查实例的状态。
source /home/stack/destackovsrc-Pcrf
nova list --fields name,host,status | grep arbiter
| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 | destackovs-compute-2 | SHUTOFF|
步骤2.检查计算是否可用并确保状态为up。
source /home/stack/destackovsrc
nova hypervisor-show destackovs-compute-2 | egrep ‘status|state’
| state | up |
| status | enabled |
步骤3.以管理员用户身份登录到ESC Master并检查opdata中实例的状态。
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata | grep arbiter
r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 VM_ERROR_STATE
步骤4.从openstack打开实例电源。
source /home/stack/destackovsrc-Pcrf
nova start r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957
步骤5.等待五分钟，使实例启动并进入活动状态。
source /home/stack/destackovsrc-Pcrf
nova list –fields name,status | grep cm
| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 | ACTIVE |
步骤6.在实例处于活动状态后，在ESC中启用VM监控。
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957
有关实例配置的进一步恢复，请参阅下面提供的实例类型特定过程。
从错误状态恢复任何实例
如果openstack中的CPS实例状态为ERROR状态，请使用以下步骤启动该实例：
步骤1.重置实例的状态以强制实例返回活动状态而不是错误状态，完成后，重新启动实例。
source /home/stack/destackovsrc-Pcrf
nova reset-state –active r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957
nova reboot –-hard r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957
步骤2.以管理员用户身份登录到ESC Master并检查opdata中实例的状态。
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata | grep arbiter
r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 VM_ERROR_STATE
步骤3.检查计算是否可用并运行正常。
source /home/stack/destackovsrc
nova hypervisor-show destackovs-compute-2 | egrep ‘status|state’
| state | up |
| status | enabled |
步骤4.检查OpenStack中实例的状态。
source /home/stack/destackovsrc-Pcrf
nova list --fields name,host,status | grep arbiter
| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 | destackovs-compute-2 | ERROR|
步骤5.等待五分钟，使实例启动并进入活动状态。
source /home/stack/destackovsrc-Pcrf
nova list –fields name,status | grep arbiter
| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 | ACTIVE |
步骤6.如果 在重新启动后，集群管理器将状态更改为活动，在集群管理器实例处于活动状态后，在ESC中启用VM监控器。
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957
步骤7.恢复到运行/活动状态后，请参阅实例类型特定过程以从备份中恢复配置/数据。
恢复仲裁器/arbitervip
如果最近恢复了仲裁器实例/pcrfclient，并且仲裁器不在diagnostics.sh get_replica_status输出中，则按照此步骤操作。
如果部署有专用仲裁服务器VM使用步骤1到3，则对于arbitervip，请另外运行步骤4，然后运行以下步骤：
- 在集群管理器上，运行以下命令以根据系统配置创建mongodb启动/停止脚本：
cd /var/qps/bin/support/mongo
build_set.sh --all --create-scripts
2. 在PCRFCLIENTXX或（和）仲裁服务器上，运行此命令以列出您需要启动的所有进程。
cd etc/init.d/
ll | grep sessionmgr
3. 在PCRFCLIENTXX或（和）仲裁服务器上列出的每个文件上，运行此命令，用端口号替换xxxxx，例如27717:
/etc/init.d/sessionmgr-xxxxx start
Example:
/etc/init.d/sessionmgr-27717 start
- 如果使用仲裁服务器vip，请通过以下命令检查pcrfclient01上的任何pcs资源是否需要清除：
pcs resource show | grep –v started
如果步骤4中的命令返回了任何输出，请使用以下命令清除pcs资源，对于未启动的多个pcs资源，请对每个资源重复该命令：
pcs resource cleanup
验证
验证副本状态的运行状况：
Run diagnostics.sh on pcrfclient01
如果仲裁服务器作为仲裁服务器运行，而不是仲裁服务器/pcrfclient，则验证VM是否完全恢复，您可以执行以下步骤：
- 在主仲裁器上，所有mongo进程都应运行，并且可以在仲裁器上使用此命令来验证它：
ps –aef | grep mongo
- 验证监控下的所有进程是否都处于仲裁器的正常（运行/监控）状态。
monit summary
反馈