排除PCRF会话管理器VM恢复故障

下载选项

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

已更新: 2018 年 9 月 4 日

文档 ID:213624

非歧视性语言

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

关于此翻译

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

简介

本文档介绍在Ultra-M/OpenStack部署上部署的会话管理器恢复过程。

故障排除

会话管理器实例恢复过程

从关闭状态打开会话管理器电源

如果任何实例由于计划的关闭或其他原因处于SHUTOFF状态，请使用此过程启动实例并在ESC中启用itâ€™s监控。

通过OpenStack检查实例的状态

source /home/stack/destackovsrc-Pcrf
nova list --fields name,host,status | grep sm-s1
| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | destackovs-compute-2  | SHUTOFF|

检查计算是否可用，并确保状态为up。

source /home/stack/destackovsrc
nova hypervisor-show destackovs-compute-2 | egrep ‘status|state’
| state                     | up                                       |
| status                    | enabled                                  |

以管理员用户身份登录到弹性服务控制器(ESC)Master并检查opdata中实例的状态。

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata | grep sm-s1_0
SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 VM_ERROR_STATE

从openstack打开实例电源

source /home/stack/destackovsrc-Pcrf
nova start SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

。

等待5分钟，使实例启动并进入活动状态。

source /home/stack/destackovsrc-Pcrf
nova list –fields name,status | grep sm-s1_0
| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | ACTIVE |

在实例处于活动状态后，在ESC中启用VM监控。

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

有关实例配置的进一步恢复，请参阅下一节中提供的实例类型特定过程。

从错误状态恢复任何实例

如果openstack中CPS实例的状态为ERROR，则可使用此过程：

检查OpenStack中实例的状态。

source /home/stack/destackovsrc-Pcrf
nova list --fields name,host,status | grep sm-s1
| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | destackovs-compute-2  | ERROR|

检查计算是否可用并运行正常。

source /home/stack/destackovsrc
nova hypervisor-show destackovs-compute-2 | egrep â€˜status|stateâ€™
| state                     | up                                       |
| status                    | enabled                                  |

以管理员用户身份登录ESC Master并检查opdata中实例的状态。

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata | grep sm-s1_0

SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 VM_ERROR_STATE

重置实例状态以强制实例返回活动状态而不是错误状态，完成后，请重新启动实例。

source /home/stack/destackovsrc-Pcrf

nova reset-state â€“active SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226
nova reboot â€“-hard  SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

等待5分钟，使实例启动并进入活动状态。

source /home/stack/destackovsrc-Pcrf
nova list â€“fields name,status | grep sm
| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | ACTIVE |

如果，集群管理器在重新启动后将状态更改为ACTIVE，则在集群管理器实例处于活动状态后在ESC中启用VM监控器。

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

恢复到运行/活动状态后，请参阅实例类型特定过程以从备份恢复配置/数据。

会话管理器/MongoDB恢复

会话管理器在本节中为集群策略套件提供数据库层，讨论最近恢复的会话管理器实例上的数据库恢复：

处于脱机状态的复制副本集的成员

如果复制副本集的成员处于脱机状态，请使用以下过程：

在群集管理器上使用此命令检查复制副本集的状态。

diagnostics.sh --get_replica_status

在所有副本集中列出所有离线成员。
在集群管理器上运行命令。

cd /var/qps/bin/support/mongo
build_set.sh --all --create-scripts

安全外壳到会话管理器VM并启动监控进程。

ssh sessionmgrXX
/etc/init.d/sessionmgr-XXXXX start

复本集的成员停滞在“启动”状态2/恢复状态长时间

如果复制副本集的成员停滞在启动2或恢复状态，并且主成员在复制副本集中可用，请使用以下过程：

在群集管理器上使用此命令检查复制副本集的状态。

diagnostics.sh --get_replica_status

列出所有复制集中的所有成员。

安全外壳到sessionmgr VM并获取mongo进程的存储位置。如示例dbpath所示，在端口37717的sessionmgr01上运行的mongo进程为/var/data/sessions.1/b。

ssh sessionmgr01
ps -ef | grep mongo | grep 37717
root      2572     1 25 Feb11 ?        24-11:43:43 /usr/bin/mongod --ipv6 --nojournal --storageEngine mmapv1 --noprealloc --smallfiles --port 37717 --dbpath=/var/data/sessions.1/b --replSet set01b --fork --pidfilepath /var/run/sessionmgr-37717.pid --oplogSize 5120 --logpath /var/log/mongodb-37717.log --logappend --quiet --slowms 500

停止mongo进程并清除dbpath中的内容：

/etc/init.d/sessionmgr-xxxxx stop
rm -rf /var/data/sessions.1/b/*

启动mongo进程，这会导致复制副本集成员同步来自主数据库的所有数据，而不是操作日志。

/etc/init.d/sessionmgr-xxxxx start

第5步可能需要相当长的时间才能同步来自主数据库的所有数据，具体取决于数据库大小。

重建复制副本集

由于某些中断，可能需要重建部分或所有复制副本集。但是，在决定重建部分或全部复制副本集之前，可能会注意到这些复制副本集中的所有数据都可能丢失。必须交叉验证这些数据库的备份可用性：

管理员(通常为27721)
余额(通常在端口27718上)
SPR(通常在端口27720上)

在对备份进行交叉验证并做出重新创建数据库副本集的决策后，请使用以下过程：

检查/etc/broadhop/mongoConfig.cfg的内容,LLD必须包含有关此文件中必须存在的配置的信息，或者您可以使用备份的文件。

命令build_set.sh —<db-name> —create必须在集群管理器上运行，这取决于要重建的数据库。它会创建与该数据库相关的所有复制副本集。

注意：用于在复制副本集中创建所有dbs的命令可清除数据库。复制集的所有内容都将丢失。

如果要为一个数据库重建特定的复制副本集，请使用以下命令：

build_set.sh --
     
     
       --create --setname

如果要重建所有数据库的所有复制副本集，请使用以下命令：

build_set.sh --all --create

从备份后副本集恢复数据库

一旦复制副本集的所有成员都联机并且其中一个成员是主成员，则可以通过此过程从备份中恢复mongoDB。

要从备份恢复所有数据库，请使用以下命令：

config_br.py --action import --mongo-all  /mnt/backup/

要通过config_br.py从备份恢复特定数据库，以下选项可用：

config_br.py --action import --mongo-all --spr /mnt/backup/

管理员

config_br.py --action import --mongo-all --admin /mnt/backup/



余额

config_br.py --action import --mongo-all --balance /mnt/backup/



报告

config_br.py --action import --mongo-all --report /mnt/backup/

如果mongodump用于备份数据库，则说明它通过mongo恢复的使用：

提取备份tar.gz文件。

tar -zxf /mnt/backup/

找到包含要恢复的数据库的mongo转储的文件夹，然后更改目录以输入该文件夹。

ls -ltr /mnt/backup/cd /mnt/backup/27721_backup_$(date +\%Y-\%m-\%d)/dump

从备份恢复复制副本集。

mongorestore --host --port

或者，要恢复特定集合或数据库，请使用以下命令：

mongorestore --host --port --db --

由思科工程师提供

Nitesh Bansal
Cisco Advance Services

排除PCRF会话管理器VM恢复故障 — Openstack