备份和恢复 — 完整群集恢复 — CPS

简介

本文档介绍在托管CPS虚拟网络功能(VNF)的Ultra-M设置中恢复整个CPS群集所需的步骤。

背景信息

Ultra-M是预打包和验证的虚拟化移动数据包核心解决方案，旨在简化VNF的部署。Ultra-M解决方案包括以下虚拟机(VM)类型：

• 弹性服务控制器(ESC)
• 思科策略套件(CPS)

此图中描述了Ultra-M的高级体系结构和涉及的组件：

本文档面向熟悉Cisco Ultra-M平台的思科人员。

注意：Ultra M 5.1.x版本用于定义本文档中的过程。

缩写

VNF	虚拟网络功能
ESC	弹性服务控制器
MOP	程序方法
OSD	对象存储磁盘
硬盘	硬盘驱动器
SSD	固态驱动器
VIM	虚拟基础设施管理器
虚拟机	虚拟机
UUID	通用唯一IDentifier

假设

对于此过程，假设仅恢复CPS群集，并且Openstack级别的所有组件都运行正常，包括ESC 

恢复过程

   

当ESC无法启动VM时：

• 在某些情况下，ESC由于意外状态而无法启动VM。解决方法是通过重新启动主ESC执行ESC切换。ESC切换大约需要一分钟。在新的主ESC上运行health.sh以验证其是否已启用。当ESC变为主时，ESC可以修复VM状态并启动VM。由于已计划此操作，您必须等待5-7分钟才能完成。 

• 您可以监控/var/log/esc/yangesc.log和/var/log/esc/escmanager.log。如果您在5-7分钟后未看到VM恢复，则用户需要转到并手动恢复受影响的VM。

• VM成功恢复并运行后；确保所有系统日志特定配置都从先前成功的已知备份中恢复。确保已在所有ESC VM中恢复。

root@abautotestvnfm1em-0:/etc/rsyslog.d# pwd
/etc/rsyslog.d

root@abautotestvnfm1em-0:/etc/rsyslog.d# ll

total 28
drwxr-xr-x  2 root root 4096 Jun  7 18:38 ./
drwxr-xr-x 86 root root 4096 Jun  6 20:33 ../]
-rw-r--r--  1 root root  319 Jun  7 18:36 00-vnmf-proxy.conf
-rw-r--r--  1 root root  317 Jun  7 18:38 01-ncs-java.conf
-rw-r--r--  1 root root  311 Mar 17  2012 20-ufw.conf
-rw-r--r--  1 root root  252 Nov 23  2015 21-cloudinit.conf
-rw-r--r--  1 root root 1655 Apr 18  2013 50-default.conf

root@abautotestvnfm1em-0:/etc/rsyslog.d# ls /etc/rsyslog.conf
rsyslog.conf

CPS恢复

1.创建CPS Cluster-Manager的备份

步骤1.使用以下命令查看nova实例并注意群集管理器VM实例的名称：

nova list

从ESC中停止Cluman。

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP 
     
     

步骤2.检验集群管理器处于SHUTF状态。

admin@esc1 ~]$ /opt/cisco/esc/confd/bin/confd_cli 

admin@esc1> show esc_datamodel opdata tenants tenant Core deployments * state_machine

步骤3.创建新快照映像，如以下命令所示：

nova image-create --poll 
     
      
       
     

注：确保有足够的磁盘空间用于快照。

重要信息 — 如果创建快照后VM无法访问，请使用nova list命令检查VM的状态。如果它处于“关闭”状态，则需要手动启动VM。

步骤4.使用以下命令查看映像列表：nova image-list图1:输出示例

步骤5.创建快照时，快照映像存储在OpenStack Glance中。要将快照存储在远程数据存储中，请下载快照并将OSPD中的文件传输到(/home/stack/CPS_BACKUP)

要下载映像，请在OpenStack中使用以下命令：

glance image-download –-file For example: glance image-download –-file snapshot.raw 2bbfb51c-cd05-4b7c-ad77-8362d76578db

步骤6.列出下载的映像，如以下命令所示：

ls —ltr *snapshot*

Example output: -rw-r--r--. 1 root root 10429595648 Aug 16 02:39 snapshot.raw

步骤7.存储群集管理器VM的快照以在将来恢复。

2.备份配置和数据库。

1. config_br.py -a export --all /var/tmp/backup/ATP1_backup_all_$(date +\%Y-\%m-\%d).tar.gz OR
2. config_br.py -a export --mongo-all /var/tmp/backup/ATP1_backup_mongoall$(date +\%Y-\%m-\%d).tar.gz
3. config_br.py -a export --svn --etc --grafanadb --auth-htpasswd --haproxy /var/tmp/backup/ATP1_backup_svn_etc_grafanadb_haproxy_$(date +\%Y-\%m-\%d).tar.gz
4. mongodump - /var/qps/bin/support/env/env_export.sh --mongo /var/tmp/env_export_$date.tgz
5. patches - cat /etc/broadhop/repositories, check which patches are installed and copy those patches to the backup directory /home/stack/CPS_BACKUP on OSPD
6. backup the cronjobs by taking backup of the cron directory: /var/spool/cron/ from the Pcrfclient01/Cluman. Then move the file to CPS_BACKUP on the OSPD.

从crontab -l验证是否需要任何其他备份

将所有备份传输到OSPD /home/stack/CPS_BACKUP

3.从ESC Master备份yaml文件。

/opt/cisco/esc/confd/bin/netconf-console --host 127.0.0.1 --port 830 -u 
     
     
       -p 
      
        --get-config > /home/admin/ESC_config.xml 
       
     

在OSPD /home/stack/CPS_BACKUP中传输文件

4.备份crontab -l条目

使用crontab -l创建一个文本文件，并将其ftp到远程位置（在OSPD /home/stack/CPS_BACKUP中）

5.从LB和PCRF客户端备份路由文件。

Collect and scp the below conifgurations from both LBs and Pcrfclients
route -n /etc/sysconfig/network-script/route-*

在OpenStack中恢复群集管理器VM

步骤1.将集群管理器VM快照复制到控制器刀片，如以下命令所示：

ls —ltr *snapshot*

示例输出：-rw-r—r—. 1 root root 10429595648 8月16日02:39 snapshot.raw

步骤2.将快照映像从Datastore上传到OpenStack:

glance image-create --name --file --disk-format qcow2 --container-format bare

  

步骤3.验证是否使用Nova命令上载快照，如本示例所示：

nova image-list

图 2：输出示例

步骤4.根据群集管理器VM是否存在，您可以选择创建群集或重建群集：

如果集群管理器VM实例不存在，请使用Heat或Nova命令创建集群VM，如以下示例所示：

使用ESC创建群集VM 

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

PCRF群集将在上述命令的帮助下生成，然后从使用config_br.py恢复执行的备份中恢复群集管理器配置，从备份中执行的转储中恢复mongorestore

delete - nova boot --config-drive true --image "" --flavor "" --nic net-id=",v4-fixed-ip=" --nic net-id="network_id,v4-fixed-ip=ip_address" --block-device-mapping "/dev/vdb=2edbac5e-55de-4d4c-a427-ab24ebe66181:::0" --availability-zone "az-2:megh-os2-compute2.cisco.com" --security-groups cps_secgrp "cluman" 

如果群集管理器VM实例存在，请使用nova rebuild命令使用上传的快照重建群集VM实例，如下所示：

nova rebuild 
     
      
       
     

例如：nova rebuild cps-cluman-5f3tujqvbi67 cluman_snapshot

第5步列出所有实例，并验证新集群管理器实例已创建并运行：

新星列表

图 3：输出示例

恢复系统上的最新补丁

1.       Copy the patch files to cluster manager which were backed up in OSPD /home/stack/CPS_BACKUP 
2.       Login to the Cluster Manager as a root user.
3.       Untar the patch by executing the following command:  tar -xvzf [patch name].tar.gz
4.       Edit /etc/broadhop/repositories and add the following entry:  file:///$path_to_the plugin/[component name]  
5.       Run build_all.sh script to create updated QPS packages:  /var/qps/install/current/scripts/build_all.sh
6.       Shutdown all software components on the target VMs:  runonall.sh sudo monit stop all
7.       Make sure all software components are shutdown on target VMs:  statusall.sh

注意：软件组件必须全部显示为“未监控”(Not Monitored)为当前状态)8.使用reinit.sh脚本使用新软件更新qns VM:/var/qps/install/current/scripts/upgrade/reinit.sh 9.重新启动目标VM上的所有软件组件：runonall.sh sudo monit启动所有10。验证组件是否已更新，运行：about.sh

恢复Cronjobs

1. 将备份文件从OSPD移动到Cluman/Pcrfclient01 
   
   
2. 运行命令以从备份激活cronjob
   #crontab Cron-backup
   
3. 检查cronjobs是否已通过以下命令激活
           #crontab -l       

在集群中恢复单个VM

重新部署pcrfclient01 VM

步骤1.以根用户身份登录到Cluster Manager VM。

步骤2.使用以下命令记录SVN存储库的UUID:

svn info http://pcrfclient02/repos | grep UUID

该命令将输出存储库的UUID。

例如：存储库UUID:ea50bbd2-5726-46b8-b807-10f4a7424f0e

步骤3.在群集管理器上导入备份策略生成器配置数据，如以下示例所示：

config_br.py -a import --etc-oam --svn --stats --grafanadb --auth-htpasswd --users /mnt/backup/oam_backup_27102016.tar.gz

注意：许多部署都运行定期备份配置数据的cron作业。有关详细信息，请参阅Subversion资源库备份。 

步骤4.要使用最新配置在群集管理器上生成VM存档文件，请执行以下命令：

/var/qps/install/current/scripts/build/build_svn.sh

步骤5.要部署pcrfclient01 VM，请执行以下操作之一：

在OpenStack中，使用HEAT模板或Nova命令重新创建VM。有关详细信息，请参阅《OpenStack CPS安装指南》。

步骤6.在运行这些命令时，在pcrfclient01和pcrfclient02之间重新建立SVN主/从同步，并将pcrfclient01作为主。

如果SVN已同步，请勿发出这些命令。

要检查SVN是否同步，请从pcrfclient02运行此命令。

如果返回值，则SVN已同步：

/usr/bin/svn propget svn:sync-from-url --revprop -r0 http://pcrfclient01/repos

从pcrfclient01运行以下命令：

/bin/rm -fr /var/www/svn/repos
 
/usr/bin/svnadmin create /var/www/svn/repos
 
/usr/bin/svn propset --revprop -r0 svn:sync-last-merged-rev 0 http://pcrfclient02/repos-proxy-sync
 
/usr/bin/svnadmin setuuid /var/www/svn/repos/ "Enter the UUID captured in step 2"
 
/etc/init.d/vm-init-client /var/qps/bin/support/recover_svn_sync.sh

步骤7.如果pcrfclient01也是仲裁器VM，则运行以下步骤：

1.根据系统配置创建mongodb启动/停止脚本。并非所有部署都配置了所有这些数据库。

注意：请参阅/etc/broadhop/mongoConfig.cfg以确定需要设置哪些数据库。

cd /var/qps/bin/support/mongo
 
build_set.sh --session --create-scripts
build_set.sh --admin --create-scripts
build_set.sh --spr --create-scripts
build_set.sh --balance --create-scripts
build_set.sh --audit --create-scripts
build_set.sh --report --create-scripts

2.启动mongo流程：

/usr/bin/systemctl start sessionmgr-XXXXX

3.等待仲裁程序启动，然后运行diagnostics.sh —get_replica_status以检查复制副本集的运行状况。

重新部署pcrfclient02 VM

步骤1.以根用户身份登录到Cluster Manager VM。

步骤2.要使用最新配置在群集管理器上生成VM存档文件，请运行以下命令：

/var/qps/install/current/scripts/build/build_svn.sh

第3步要部署pcrfclient02 VM，请执行以下操作之一： 

在OpenStack中，使用HEAT模板或Nova命令重新创建VM。有关详细信息，请参阅《OpenStack CPS安装指南》。

第4步安全外壳到pcrfclient01:

ssh pcrfclient01

第5步运行此脚本以从pcrfclient01恢复SVN重订：

/var/qps/bin/support/recover_svn_sync.sh

重新部署会话管理器VM

步骤1.以根用户身份登录到Cluster Manager VM

步骤2.要部署sessionmgr VM并更换出现故障或损坏的VM，请执行以下操作之一：

在OpenStack中，使用HEAT模板或Nova命令重新创建VM。有关详细信息，请参阅《OpenStack CPS安装指南》

步骤3.根据系统配置创建mongodb启动/停止脚本。

并非所有部署都配置了所有这些数据库。请参阅/etc/broadhop/mongoConfig.cfg以确定需要设置哪些数据库

cd /var/qps/bin/support/mongo
 
build_set.sh --session --create-scripts
build_set.sh --admin --create-scripts
build_set.sh --spr --create-scripts
build_set.sh --balance --create-scripts
build_set.sh --audit --create-scripts
build_set.sh --report --create-scripts

步骤4.将外壳安全到sessionmgr VM并启动监控进程：

ssh sessionmgrXX

/usr/bin/systemctl start sessionmgr-XXXXX

步骤5.等待成员启动和辅助成员同步，然后运行diagnostics.sh —get_replica_status以检查数据库的运行状况。

步骤6.要恢复会话管理器数据库，请根据备份是使用 — mongo-all还是 — mongo选项执行，使用以下示例命令之一：

• config_br.py -a import --mongo-all --users /mnt/backup/Name of backup 

or

• config_br.py -a import --mongo --users /mnt/backup/Name of backup

重新部署策略导向器（负载均衡器）VM

步骤1.以根用户身份登录到Cluster Manager VM。

步骤2.要在群集管理器上导入备份策略生成器配置数据，请运行以下命令：

config_br.py -a import --network --haproxy --users /mnt/backup/lb_backup_27102016.tar.gz

第3步要使用最新配置在群集管理器上生成VM存档文件，请运行以下命令：

/var/qps/install/current/scripts/build/build_svn.sh

步骤4.要部署lb01 VM，请执行以下操作之一：

在OpenStack中，使用HEAT模板或Nova命令重新创建VM。有关详细信息，请参阅《OpenStack CPS安装指南》。

重新部署策略服务器(QNS)VM

步骤1.以根用户身份登录到Cluster Manager VM。

步骤2.在群集管理器上导入备份策略生成器配置数据，如本例所示：

config_br.py -a import --users /mnt/backup/qns_backup_27102016.tar.gz

步骤3.要使用最新配置在群集管理器上生成VM存档文件，请运行以下命令：

/var/qps/install/current/scripts/build/build_svn.sh

第4步要部署qns VM，请执行以下操作之一：

在OpenStack中，使用HEAT模板或Nova命令重新创建VM。有关详细信息，请参阅《OpenStack CPS安装指南》 

数据库恢复的一般过程

步骤1.运行此命令以恢复数据库：

config_br.py –a import --mongo-all /mnt/backup/backup_$date.tar.gz where $date is the timestamp when the export was made.

例如，

config_br.py –a import --mongo-all /mnt/backup/backup_27092016.tgz

步骤2.登录数据库并验证数据库是否正在运行且可访问：

1.登录会话管理器：

mongo --host sessionmgr01 --port $port

其中$port是要检查的数据库的端口号。例如，27718是默认余额端口。

2.通过执行以下命令显示数据库：

show dbs

3.通过执行以下命令将mongo shell切换到数据库：

use $db

其中，$db是上一命令中显示的数据库名称。

use命令将mongo shell切换到该数据库。

例如，

use balance_mgmt

4.要显示集合，请运行以下命令：

show collections

5.要显示集合中的记录数，请运行以下命令：

db.$collection.count()
 
For example, db.account.count()

上例将显示余额数据库(balance_mgmt)中收集“帐户”中的记录数。

Subversion存储库还原

要从备份恢复策略生成器配置数据，请执行以下命令：

config_br.py –a import --svn /mnt/backup/backup_$date.tgz where, $date is the date when the cron created the backup file. 

恢复Grafana控制面板

您可以使用以下命令恢复Grafana控制面板：

config_br.py -a import --grafanadb /mnt/backup/

验证恢复

恢复数据后，请通过以下命令验证工作系统：

/var/qps/bin/diag/diagnostics.sh

当ESC无法启动VM时

• 在某些情况下，ESC由于意外状态而无法启动VM。解决方法是通过重新启动主ESC执行ESC切换。ESC切换大约需要一分钟。在新的主ESC上运行health.sh以验证其是否已启用。当ESC变为主时，ESC可以修复VM状态并启动VM。由于已计划此操作，您必须等待5-7分钟才能完成。  

• 您可以监控/var/log/esc/yangesc.log和/var/log/esc/escmanager.log。如果您在5-7分钟后未看到VM恢复，则用户需要转到并手动恢复受影响的VM。
  
  
• 如果群集完全不可用，并且只能访问ESC，则必须从通过Cronjobs执行的定时备份中执行最新备份执行恢复。恢复程序与《澳门公约》中所述相同。