简介

本文档介绍如何恢复在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
```

目录

简介