本產品的文件集力求使用無偏見用語。針對本文件集的目的,無偏見係定義為未根據年齡、身心障礙、性別、種族身分、民族身分、性別傾向、社會經濟地位及交織性表示歧視的用語。由於本產品軟體使用者介面中硬式編碼的語言、根據 RFP 文件使用的語言,或引用第三方產品的語言,因此本文件中可能會出現例外狀況。深入瞭解思科如何使用包容性用語。
思科已使用電腦和人工技術翻譯本文件,讓全世界的使用者能夠以自己的語言理解支援內容。請注意,即使是最佳機器翻譯,也不如專業譯者翻譯的內容準確。Cisco Systems, Inc. 對這些翻譯的準確度概不負責,並建議一律查看原始英文文件(提供連結)。
本文檔介紹在承載呼叫CPS虛擬網路功能的Ultra-M設定中備份和還原虛擬機器所需的步驟。
Ultra-M是經過預打包和驗證的虛擬化移動資料包核心解決方案,旨在簡化虛擬網路功能(VNF)的部署。Ultra-M解決方案由以下虛擬機器(VM)型別組成:
Ultra-M的高級體系結構及涉及的元件如圖所示。
註:為定義本文檔中的過程,需要考慮Ultra M 5.1.x版本。 本文檔適用於熟悉Cisco Ultra-M平台的思科人員。
VNF | 虛擬網路功能 |
ESC | 彈性服務控制器 |
澳門幣 | 程式方法 |
OSD | 對象儲存磁碟 |
HDD | 硬碟驅動器 |
固態硬碟 | 固態驅動器 |
VIM | 虛擬基礎架構管理員 |
虛擬機器 | 虛擬機器 |
UUID | 通用唯一ID識別符號 |
1.檢查OpenStack堆疊和節點清單的狀態。
[stack@director ~]$ source stackrc
[stack@director ~]$ openstack stack list --nested
[stack@director ~]$ ironic node-list
[stack@director ~]$ nova list
2.從OSP-D節點檢查所有底層雲服務是否處於已載入、活動和運行狀態。
[stack@director ~]$ systemctl list-units "openstack*" "neutron*" "openvswitch*"
UNIT LOAD ACTIVE SUB DESCRIPTION
neutron-dhcp-agent.service loaded active running OpenStack Neutron DHCP Agent
neutron-openvswitch-agent.service loaded active running OpenStack Neutron Open vSwitch Agent
neutron-ovs-cleanup.service loaded active exited OpenStack Neutron Open vSwitch Cleanup Utility
neutron-server.service loaded active running OpenStack Neutron Server
openstack-aodh-evaluator.service loaded active running OpenStack Alarm evaluator service
openstack-aodh-listener.service loaded active running OpenStack Alarm listener service
openstack-aodh-notifier.service loaded active running OpenStack Alarm notifier service
openstack-ceilometer-central.service loaded active running OpenStack ceilometer central agent
openstack-ceilometer-collector.service loaded active running OpenStack ceilometer collection service
openstack-ceilometer-notification.service loaded active running OpenStack ceilometer notification agent
openstack-glance-api.service loaded active running OpenStack Image Service (code-named Glance) API server
openstack-glance-registry.service loaded active running OpenStack Image Service (code-named Glance) Registry server
openstack-heat-api-cfn.service loaded active running Openstack Heat CFN-compatible API Service
openstack-heat-api.service loaded active running OpenStack Heat API Service
openstack-heat-engine.service loaded active running Openstack Heat Engine Service
openstack-ironic-api.service loaded active running OpenStack Ironic API service
openstack-ironic-conductor.service loaded active running OpenStack Ironic Conductor service
openstack-ironic-inspector-dnsmasq.service loaded active running PXE boot dnsmasq service for Ironic Inspector
openstack-ironic-inspector.service loaded active running Hardware introspection service for OpenStack Ironic
openstack-mistral-api.service loaded active running Mistral API Server
openstack-mistral-engine.service loaded active running Mistral Engine Server
openstack-mistral-executor.service loaded active running Mistral Executor Server
openstack-nova-api.service loaded active running OpenStack Nova API Server
openstack-nova-cert.service loaded active running OpenStack Nova Cert Server
openstack-nova-compute.service loaded active running OpenStack Nova Compute Server
openstack-nova-conductor.service loaded active running OpenStack Nova Conductor Server
openstack-nova-scheduler.service loaded active running OpenStack Nova Scheduler Server
openstack-swift-account-reaper.service loaded active running OpenStack Object Storage (swift) - Account Reaper
openstack-swift-account.service loaded active running OpenStack Object Storage (swift) - Account Server
openstack-swift-container-updater.service loaded active running OpenStack Object Storage (swift) - Container Updater
openstack-swift-container.service loaded active running OpenStack Object Storage (swift) - Container Server
openstack-swift-object-updater.service loaded active running OpenStack Object Storage (swift) - Object Updater
openstack-swift-object.service loaded active running OpenStack Object Storage (swift) - Object Server
openstack-swift-proxy.service loaded active running OpenStack Object Storage (swift) - Proxy Server
openstack-zaqar.service loaded active running OpenStack Message Queuing Service (code-named Zaqar) Server
openstack-zaqar@1.service loaded active running OpenStack Message Queuing Service (code-named Zaqar) Server Instance 1
openvswitch.service loaded active exited Open vSwitch
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, for example, generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
37 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
3.在執行備份過程之前,請確認有足夠的可用磁碟空間。此彈珠應至少為3.5 GB。
[stack@director ~]$df -h
4.以root使用者身份執行這些命令,將資料從底層雲節點備份到名為undercloud-backup-[timestamp].tar.gz的檔案中,然後將其傳輸到備份伺服器。
[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
1. ESC通過與VIM互動來啟用虛擬網路功能(VNF)。
2. ESC在Ultra-M解決方案中具有1:1冗餘。在Ultra-M中部署了兩個ESC虛擬機器,它們支援單個故障。例如,如果系統中存在單個故障,請恢復系統。
註:如果出現多個故障,則不受支援,可能需要重新部署系統。
ESC備份詳細資訊:
3. ESC資料庫備份的頻率很棘手,在ESC監視和維護所部署的各種VNF虛擬機器的各種狀態機時需要仔細處理。建議您在給定VNF/POD/站點中的這些活動之後執行這些備份。
4.使用health.sh指令碼驗證ESC的運行狀況是否良好。
[root@auto-test-vnfm1-esc-0 admin]# escadm status
0 ESC status=0 ESC Primary Healthy
[root@auto-test-vnfm1-esc-0 admin]# health.sh
esc ui is disabled -- skipping status check
esc_monitor start/running, process 836
esc_mona is up and running ...
vimmanager start/running, process 2741
vimmanager start/running, process 2741
esc_confd is started
tomcat6 (pid 2907) is running... [ OK ]
postgresql-9.4 (pid 2660) is running...
ESC service is running...
Active VIM = OPENSTACK
ESC Operation Mode=OPERATION
/opt/cisco/esc/esc_database is a mountpoint
============== ESC HA (Primary) with DRBD =================
DRBD_ROLE_CHECK=0
MNT_ESC_DATABSE_CHECK=0
VIMMANAGER_RET=0
ESC_CHECK=0
STORAGE_CHECK=0
ESC_SERVICE_RET=0
MONA_RET=0
ESC_MONITOR_RET=0
=======================================
ESC HEALTH PASSED
5.備份運行配置,並將檔案傳輸到備份伺服器。
[root@auto-test-vnfm1-esc-0 admin]# /opt/cisco/esc/confd/bin/confd_cli -u admin -C
admin connected from 127.0.0.1 using console on auto-test-vnfm1-esc-0.novalocal
auto-test-vnfm1-esc-0# show running-config | save /tmp/running-esc-12202017.cfg
auto-test-vnfm1-esc-0#exit
[root@auto-test-vnfm1-esc-0 admin]# ll /tmp/running-esc-12202017.cfg
-rw-------. 1 tomcat tomcat 25569 Dec 20 21:37 /tmp/running-esc-12202017.cfg
備份ESC資料庫
1.登入到ESC VM並在進行備份之前執行此命令。
[admin@esc ~]# sudo bash
[root@esc ~]# cp /opt/cisco/esc/esc-scripts/esc_dbtool.py /opt/cisco/esc/esc-scripts/esc_dbtool.py.bkup
[root@esc esc-scripts]# sudo sed -i "s,'pg_dump,'/usr/pgsql-9.4/bin/pg_dump," /opt/cisco/esc/esc-scripts/esc_dbtool.py
#Set ESC to mainenance mode
[root@esc esc-scripts]# escadm op_mode set --mode=maintenance
2.檢查ESC模式並確保它處於維護模式。
[root@esc esc-scripts]# escadm op_mode show
3.使用ESC中提供的資料庫備份還原工具備份資料庫。
[root@esc scripts]# sudo /opt/cisco/esc/esc-scripts/esc_dbtool.py backup --file scp://<username>:<password>@<backup_vm_ip>:<filename>
4.將ESC設定為「操作模式」並確認模式。
[root@esc scripts]# escadm op_mode set --mode=operation
[root@esc scripts]# escadm op_mode show
5.導航到scripts目錄並收集日誌。
[root@esc scripts]# /opt/cisco/esc/esc-scripts
sudo ./collect_esc_log.sh
6.要建立ESC的快照,請先關閉ESC。
shutdown -r now
7.從OSPD建立映像快照。
nova image-create --poll esc1 esc_snapshot_27aug2018
8.驗證是否已建立快照。
openstack image list | grep esc_snapshot_27aug2018
9.從OSPD啟動ESC。
nova start esc1
10.在備用ESC VM上重複相同過程,並將日誌傳輸到備份伺服器。
11.收集兩個ESC VM上的系統日誌配置備份,並將它們傳輸到備份伺服器。
[admin@auto-test-vnfm2-esc-1 ~]$ cd /etc/rsyslog.d
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/00-escmanager.conf
00-escmanager.conf
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/01-messages.conf
01-messages.conf
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/02-mona.conf
02-mona.conf
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.conf
rsyslog.conf
步驟 1.建立CPS Cluster-Manager的備份。
使用以下命令檢視nova例項並記下群集管理器VM例項的名稱:
nova list
從ESC中停止Cluman。
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP <vm-name>
步驟 2.驗證群集管理器是否處於SHUTOFF狀態。
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 <cluman-vm-name> <snapshot-name>
注意:請確保有足夠的磁碟空間用於建立快照。
.重要資訊 — 如果快照建立後無法訪問虛擬機器,請使用nova list命令檢查VM的狀態。如果處於SHUTOFF狀態,則需要手動啟動VM。
步驟 4.使用以下命令檢視影象清單:nova image-list
影象1:輸出示例
步驟 5.建立快照後,快照映像將儲存在OpenStack概覽中。要將快照儲存在遠端資料儲存中,請下載快照並將檔案以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.儲存要在將來恢復的Cluster Manager虛擬機器的快照。
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主伺服器備份yaml檔案。
/opt/cisco/esc/confd/bin/netconf-console --host 127.0.0.1 --port 830 -u <admin-user> -p <admin-password> --get-config > /home/admin/ESC_config.xml
在OSPD /home/stack/CPS_BACKUP中傳輸檔案。
4.備份crontab -l條目。
使用crontab -l建立一個txt檔案,然後將其ftp到遠端位置(在OSPD /home/stack/CPS_BACKUP中)。
5.從LB和PCRF客戶端備份路由檔案。
Collect and scp the configurations from both LBs and Pcrfclients route -n /etc/sysconfig/network-script/route-*
OSPD恢復程式基於這些假設來執行。
1.可從舊OSPD伺服器獲得OSPD備份。
2. OSPD恢復可以在新伺服器上完成,該伺服器是系統中舊OSPD伺服器的替代伺服器。 .
1.如果VM處於錯誤或關閉狀態,請通過硬重新啟動來啟動受影響的VM,ESC VM可恢復。執行這些步驟以恢復ESC。
2.識別處於錯誤或關閉狀態的VM,一旦識別硬重新啟動ESC VM。在本示例中,您將重新啟動auto-test-vnfm1-ESC-0。
[root@tb1-baremetal scripts]# nova list | grep auto-test-vnfm1-ESC-
| f03e3cac-a78a-439f-952b-045aea5b0d2c | auto-test-vnfm1-ESC-0 | ACTIVE | - | running | auto-testautovnf1-uas-orchestration=172.31.12.11; auto-testautovnf1-uas-management=172.31.11.3 |
| 79498e0d-0569-4854-a902-012276740bce | auto-test-vnfm1-ESC-1 | ACTIVE | - | running | auto-testautovnf1-uas-orchestration=172.31.12.15; auto-testautovnf1-uas-management=172.31.11.15 |
[root@tb1-baremetal scripts]# [root@tb1-baremetal scripts]# nova reboot --hard f03e3cac-a78a-439f-952b-045aea5b0d2c\
Request to reboot server <Server: auto-test-vnfm1-ESC-0> has been accepted.
[root@tb1-baremetal scripts]#
3.如果刪除ESC VM,需要再次啟動。請按照以下步驟順序操作。
[stack@pod1-ospd scripts]$ nova list |grep ESC-1
| c566efbf-1274-4588-a2d8-0682e17b0d41 | vnf1-ESC-ESC-1 | ACTIVE | - | running | vnf1-UAS-uas-orchestration=172.16.11.14; vnf1-UAS-uas-management=172.16.10.4 |
[stack@pod1-ospd scripts]$ nova delete vnf1-ESC-ESC-1
Request to delete server vnf1-ESC-ESC-1 has been accepted.
4.如果ESC VM不可恢復並且需要還原資料庫,請從以前備份中還原資料庫。
5.對於ESC資料庫還原,必須在還原資料庫之前確保esc服務已停止;對於ESC HA,先在輔助VM中執行,然後在主要VM中執行。
# service keepalived stop
6.檢查ESC服務狀態,並確保在HA的主和輔助VM中所有操作都已停止。
# escadm status
7.執行指令碼以恢複資料庫。作為將資料庫恢復到新建立的ESC例項的一部分,該工具還可以將其中一個例項升級為主ESC,將其資料庫資料夾裝載到驅動器裝置並且可以啟動PostgreSQL資料庫。
# /opt/cisco/esc/esc-scripts/esc_dbtool.py restore --file scp://<username>:<password>@<backup_vm_ip>:<filename>
8.重新啟動ESC服務以完成資料庫還原。對於在兩個VM中執行的HA,請重新啟動keepalive服務。
# service keepalived start
9.成功還原並運行虛擬機器後,請確保從以前成功的已知備份還原所有系統日誌特定配置。確保還原所有ESC虛擬機器中的配置。
[admin@auto-test-vnfm2-esc-1 ~]$
[admin@auto-test-vnfm2-esc-1 ~]$ cd /etc/rsyslog.d
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/00-escmanager.conf
00-escmanager.conf
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/01-messages.conf
01-messages.conf
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/02-mona.conf
02-mona.conf
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.conf
rsyslog.conf
10.如果需要從OSPD快照重建ESC,請使用此命令並在備份過程中使用快照。
nova rebuild --poll --name esc_snapshot_27aug2018 esc1
11.檢查重建完成後ESC的狀態。
nova list --fileds name,host,status,networks | grep esc
12.使用此命令檢查ESC運行狀況。
health.sh
Copy Datamodel to a backup file
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata > /tmp/esc_opdata_`date +%Y%m%d%H%M%S`.txt
當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
在OpenStack中恢復群集管理器虛擬機器。
步驟 1.將群集管理器VM快照複製到控制器刀片,如下命令所示:
ls —ltr *snapshot*
Example output: -rw-r--r--. 1 root root 10429595648 Aug 16 02:39 snapshot.raw
步驟 2.將快照映像從資料儲存上傳到OpenStack:
glance image-create --name --file --disk-format qcow2 --container-format bare
步驟 3.驗證是否使用Nova命令上傳快照,如以下示例所示:
nova image-list
影象2:輸出示例
步驟 4.根據群集管理器虛擬機器是否存在,您可以選擇建立群集或重建群集:
·如果Cluster Manager VM例項不存在,請使用Heat或Nova命令建立Cluman VM,如以下示例所示:
使用ESC建立Cluman VM。
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli edit-config /opt/cisco/esc/cisco-cps/config/gr/tmo/gen/<original_xml_filename>
PCRF群集可以在前面命令的幫助下生成,然後從使用config_br.py restore進行的備份中恢復群集管理器配置,從備份中進行的轉儲中恢復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"
·如果Cluster Manager VM例項存在,請使用nova rebuild命令重建帶有上載快照的Cluster VM例項,如下所示:
nova rebuild <instance_name> <snapshot_image_name>
舉例來說:
nova rebuild cps-cluman-5f3tujqvbi67 cluman_snapshot
步驟 5.列出所有例項,如圖所示,並驗證是否已建立並運行新的集群管理器例項:
nova list
圖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 this command: tar -xvzf [patch name].tar.gz 4. Edit /etc/broadhop/repositories and add this 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
注意:所有軟體元件必須顯示「未監視」為當前狀態。
8. Update the qns VMs with the new software using reinit.sh script: /var/qps/install/current/scripts/upgrade/reinit.sh 9. Restart all software components on the target VMs: runonall.sh sudo monit start all 10. Verify that the component is updated, run: about.sh
恢復克朗喬布斯。
1.將備份檔案從OSPD移動到Cluman/Pcrfclient01。
2.運行命令以從備份中啟用cronjob。
#crontab Cron-backup
3.檢查此命令是否已啟用cronjobs。
#crontab -l
恢復群集中的單個虛擬機器。
重新部署pcrfclient01 VM:
步驟 1.以根使用者身份登入群集管理器虛擬機器。
步驟 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 Repository Backup。
步驟 4. 要使用最新配置在群集管理器上生成VM歸檔檔案,請執行以下命令:
/var/qps/install/current/scripts/build/build_svn.sh
步驟 5.要部署pcrfclient01虛擬機器,請執行以下操作之一:
在OpenStack中,使用HEAT模板或Nova命令重新建立VM。有關詳細資訊,請參閱《CPS Installation Guide for OpenStack》。
步驟 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,則執行以下步驟:
a)根據系統配置建立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
b)啟動蒙戈進程:
/usr/bin/systemctl start sessionmgr-XXXXX
c)等待仲裁程式啟動,然後運行diagnostics.sh —get_replica_status檢查副本集的運行狀況。
重新部署pcrfclient02 VM:
步驟 1.以根使用者身份登入群集管理器虛擬機器。
步驟 2.要使用最新配置在群集管理器上生成VM歸檔檔案,請執行以下命令:
/var/qps/install/current/scripts/build/build_svn.sh
步驟 3.要部署pcrfclient02 VM,請執行以下操作之一:
在OpenStack中,使用HEAT模板或Nova命令重新建立VM。有關詳細資訊,請參閱《CPS Installation Guide for OpenStack》。
步驟 4.將shell安全到pcrfclient01:
ssh pcrfclient01
步驟 5.運行此指令碼以從pcrfclient01恢復SVN回覆:
/var/qps/bin/support/recover_svn_sync.sh
重新部署sessionmgr VM:
步驟 1.以根使用者身份登入群集管理器虛擬機器。
步驟 2.要部署sessionmgr虛擬機器並替換故障或損壞的虛擬機器,請執行以下操作之一:
在OpenStack中,使用HEAT模板或Nova命令重新建立VM。有關詳細資訊,請參閱《CPS Installation Guide for OpenStack》。
步驟 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.將shell保護到sessionmgr VM並啟動監控進程:
ssh sessionmgrXX /usr/bin/systemctl start sessionmgr-XXXXX
步驟 5.等待成員啟動且輔助成員同步,然後運行diagnostics.sh —get_replica_status檢查資料庫的運行狀況。
步驟 6.要恢復Session Manager資料庫,請使用以下示例命令之一,具體取決於是使用 — 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
要重新部署策略導向器(負載平衡器)虛擬機器:
步驟 1.以根使用者身份登入群集管理器虛擬機器。
步驟 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。有關詳細資訊,請參閱《CPS Installation Guide for OpenStack》。
重新部署策略伺服器(QNS)虛擬機器:
步驟 1.以根使用者身份登入群集管理器虛擬機器。
步驟 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。有關詳細資訊,請參閱《CPS Installation Guide for OpenStack》。
資料庫還原的一般過程。
步驟 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
修訂 | 發佈日期 | 意見 |
---|---|---|
2.0 |
20-Mar-2024 |
已更新標題、簡介、Alt文本、機器翻譯、樣式要求和格式。 |
1.0 |
21-Sep-2018 |
初始版本 |