さまざまなUltra-Mコンポーネントのバックアップおよび復元手順 – CPS

はじめに

このドキュメントでは、ホストがCPS仮想ネットワーク機能を呼び出すUltra-Mセットアップで仮想マシン(VM)をバックアップおよび復元するために必要な手順について説明します。

背景説明

Ultra-Mは、仮想ネットワーク機能(VNF)の導入を簡素化するように設計された、パッケージおよび検証済みの仮想化モバイルパケットコアソリューションです。Ultra-Mソリューションは、次のタイプの仮想マシン(VM)で構成されます。

• Elastic Services Controller（ESC）
• Cisco Policy Suite(CPS)

Ultra-Mのアーキテクチャの概要と関連するコンポーネントを次の図に示します。

省略形

VNF	仮想ネットワーク機能
ESC	柔軟なサービスコントローラ
MOP	手続の方式
OSD	オブジェクトストレージディスク
HDD	ハードディスクドライブ
SSD	ソリッドステートドライブ
VIM	仮想インフラストラクチャマネージャ
仮想マシン	仮想マシン
UUID	ユニバーサル一意識別子

バックアップ手順

OSPDバックアップ

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.バックアップ処理を実行する前に、使用可能な十分なディスク領域があることを確認します。このtarballは3.5 GB以上になると予想されます。

[stack@director ~]$df -h

4. rootユーザーとして次のコマンドを実行し、undercloudノードから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

ESCバックアップ

1. ESCは、VIMとやり取りすることで仮想ネットワーク機能(VNF)を起動します。

2. ESCは、Ultra-Mソリューションで1:1の冗長性を持ちます。2つのESC VMが導入され、Ultra-Mで1つの障害をサポートします。たとえば、システムに1つの障害がある場合は、システムを回復します。

ESCバックアップ詳細：

• Running Configuration
• 会議用CDB DB
• ESCログ
• Syslogの設定

3. ESC DBバックアップの頻度は注意が必要です。ESCは、導入されているさまざまなVNF VMのさまざまな状態マシンを監視および維持するため、バックアップの頻度は慎重に処理する必要があります。これらのバックアップは、特定の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. ESCをOSPDから起動します。

nova start esc1 

10.スタンバイESC VMで同じ手順を繰り返し、ログをバックアップサーバに転送します。

11.両方のESC VMでsyslog設定のバックアップを収集し、バックアップサーバに転送します。

[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

  

CPSバックアップ

ステップ 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：Cluster Managerがシャットオフ状態であることを確認します。

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

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

ステップ 3：次のコマンドに示すように、novaスナップショットイメージを作成します。

nova image-create --poll <cluman-vm-name> <snapshot-name>

重要：スナップショットの作成後に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：将来リストアするCluster Manager 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プライマリから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ファイルを作成し、リモートの場所(OSPD /home/stack/CPS_BACKUP)にftpします。

5. LBおよびPCRFクライアントからルートファイルのバックアップを作成します。

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

復元手順

OSPDリカバリ

OSPDの回復手順は、これらの前提条件に基づいて実行されます。 

1. OSPDバックアップは、古いOSPDサーバから使用できます。

2. OSPDの回復は、システム内の古いOSPDサーバの代わりとなる新しいサーバで実行できます。 を参照。

ESCリカバリ

1. ESC VMは、VMがエラー状態またはシャットダウン状態の場合に回復可能です。影響を受ける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とセカンダリVMの両方ですべてが停止していることを確認します。

# escadm status

7.スクリプトを実行してデータベースをリストアします。新しく作成されたESCインスタンスへのDBの復元の一環として、このツールはインスタンスの1つをプライマリESCに昇格させ、そのDBフォルダをdrbdデバイスにマウントして、PostgreSQLデータベースを起動することもできます。

# /opt/cisco/esc/esc-scripts/esc_dbtool.py restore --file scp://<username>:<password>@<backup_vm_ip>:<filename>

8. ESCサービスを再起動して、データベースの復元を完了します。両方のVMでHAを実行するには、キープアライブサービスを再起動します。

# service keepalived start

9. VMが正常に復元され、実行されたら、すべてのsyslog固有の設定が以前の正常な既知のバックアップから復元されていることを確認します。すべてのESC VMで復元されていることを確認します。

[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. ESCをOSPDスナップショットから再構築する必要がある場合は、このコマンドを、バックアップ中に取得したスナップショットを使用して使用します。

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を起動できない場合

• 予期しない状態が原因で、ESCがVMの起動に失敗する場合があります。回避策は、プライマリESCをリブートしてESCスイッチオーバーを実行することです。ESCの切り替えには約1分かかります。  新しいプライマリESCでhealth.shを実行して、それがアップになっていることを確認します。ESCがプライマリになると、ESCはVMの状態を修正してVMを起動できます。この操作はスケジュールされているため、完了するまで5 ～ 7分待つ必要があります。 

• /var/log/esc/yangesc.logおよび/var/log/esc/escmanager.logを監視できます。5 ～ 7分経過してもVMがリカバリされない場合は、影響を受けるVMの手動リカバリを実行する必要があります。

• VMが正常に復元されて実行されたら、すべてのsyslog固有の設定が、以前の正常な既知のバックアップから復元されていることを確認します。すべての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リカバリ

OpenStackでCluster Manager VMを復元します。

ステップ 1：次のコマンドに示すように、Cluster Manager 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：クラスタマネージャVMが存在するかどうかに応じて、クラスタを作成するか、またはクラスタを再構築するかを選択できます。

・Cluster Manager VMインスタンスが存在しない場合は、次の例に示すように、HeatまたはNovaコマンドでCluster VMを作成します。

ESCを使用してColumn 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コマンドを使用して、次に示すように、アップロードされたスナップショットでCluman 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

注：ソフトウェアコンポーネントはすべて、現在のステータスとして「モニタされていません(Not Monitored)」と表示される必要があります。

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

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を出力できます。

例：Repository UUID: ea50bbd2-5726-46b8-b807-10f4a7424f0e

ステップ 3：次の例に示すように、Cluster Managerでバックアップポリシービルダーの設定データをインポートします。

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： 最新の設定を使用してCluster ManagerでVMアーカイブファイルを生成するには、次のコマンドを実行します。

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

  

ステップ 5：pcrfclient01 VMを導入するには、次のいずれかを実行します。

OpenStackでは、HEATテンプレートまたはNovaコマンドを使用してVMを再作成します。詳細については、『CPS Installation Guide for OpenStack』を参照してください。

手順 6：次の一連のコマンドを実行して、pcrfclient01をプライマリとして、pcrfclient01とpcrfclient02間のSVNプライマリ/セカンダリ同期を再確立します。

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)mongoプロセスを開始します。

/usr/bin/systemctl start sessionmgr-XXXXX

c)アービターが起動するまで待ってから、diagnostics.sh —get_replica_statusを実行してレプリカセットの状態を確認します。

pcrfclient02 VMを再展開するには、次の手順に従います。

 ステップ 1：Cluster Manager VMにルートユーザとしてログインします。

ステップ 2：最新の設定を使用してCluster ManagerでVMアーカイブファイルを生成するには、次のコマンドを実行します。

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

ステップ 3：pcrfclient02 VMを導入するには、次のいずれかを実行します。
OpenStackでは、HEATテンプレートまたはNovaコマンドを使用してVMを再作成します。詳細については、『CPS Installation Guide for OpenStack』を参照してください。

ステップ 4：pcrfclient01へのセキュアシェル：

ssh pcrfclient01

ステップ 5：pcrfclient01からSVNリポジトリを回復するには、次のスクリプトを実行します。

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

sessionmgr VMを再デプロイするには、次の手順に従います。

ステップ 1：Cluster Manager VMにルートユーザとしてログインします。

ステップ 2：sessionmgr VMを導入し、障害が発生した、または破損したVMを交換するには、次のいずれかを実行します。

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：sessionmgr VMにセキュアシェル(SSH)で接続し、mongoプロセスを開始します。

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

Policy Director（ロードバランサ）VMを再展開するには、次の手順を実行します。

 ステップ 1：Cluster Manager VMにルートユーザとしてログインします。

ステップ 2：Cluster Managerでバックアップポリシービルダーの設定データをインポートするには、次のコマンドを実行します。

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

ステップ 3：最新の設定を使用してCluster ManagerでVMアーカイブファイルを生成するには、次のコマンドを実行します。

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

ステップ 4：lb01 VMを導入するには、次のいずれかを実行します。

OpenStackでは、HEATテンプレートまたはNovaコマンドを使用してVMを再作成します。詳細については、『CPS Installation Guide for OpenStack』を参照してください。

ポリシーサーバ(QNS)VMを再導入するには、次の手順を実行します。

 ステップ 1：Cluster Manager VMにルートユーザとしてログインします。

ステップ 2：次の例に示すように、Cluster Managerでバックアップポリシービルダーの設定データをインポートします。

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

ステップ 3：最新の設定を使用してCluster Managerで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シェルをデータベースに切り替えます。

use $db

ここで、$dbは前のコマンドで表示されたデータベース名です。

useコマンドは、mongoシェルをそのデータベースに切り替えます。

たとえば、

use balance_mgmt

4. コレクションを表示するには、次のコマンドを実行します。

show collections

5.コレクション内のレコード数を表示するには、次のコマンドを実行します。

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

前述の例では、Balanceデータベース(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