内容

概要

背景説明

省略形

前提条件

復元手順

CPSリカバリ

OpenStackのCluster Manager VMの復元

クロジョブの復元

クラスタ内の個々のVMのリストア

pcrfclient01 VMを再展開するには

pcrfclient02 VMを再導入するには

sessionmgr VMを再配置するには、次の手順に従います

Policy Director（ロードバランサ）VMを再展開するには

ポリシーサーバ(QNS)VMを再導入するには

データベース復元の一般的な手順

Subversionリポジトリの復元

グラフダッシュボードの復元

リストアの検証

概要

このドキュメントでは、CPS仮想ネットワーク機能(VNF)をホストするUltra-MセットアップでCPSクラスタ全体を回復するために必要な手順について説明します。

背景説明

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

- Elastic Services Controller（ESC）

- Cisco Policy Suite(CPS)

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

このドキュメントは、Cisco Ultra-Mプラットフォームに精通したシスコ担当者を対象としています。

注：Ultra M 5.1.xリリースは、このドキュメントの手順を定義するために考慮されています。

省略形

VNF

仮想ネットワーク機能

ESC

Elastic Service Controller

MOP

手続きの方法

OSD

オブジェクトストレージディスク

HDD

ハードディスクドライブ

SSD

ソリッドステートドライブ

VIM

仮想インフラストラクチャマネージャ

VM

仮想マシン

UUID

ユニバーサル一意IDentifier

前提条件

この手順では、CPSクラスタのみがリカバリされ、OpenstackレベルのすべてのコンポーネントがESCを含めて動作可能であることを前提としています

復元手順

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リカバリ

1. CPS Cluster-Managerのバックアップの作成

ステップ1：次のコマンドを使用して、ノバインスタンスを表示し、クラスタマネージャVMインスタンスの名前をメモします。

nova list

Escキーを押してClumanを停止します。

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

ステップ2：クラスタマネージャがシャットオフ状態であることを確認します。

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

注：スナップショットに十分なディスク領域があることを確認してください。

重要：スナップショットの作成後に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

-p

--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 below conifgurations from both LBs and Pcrfclients

route -n /etc/sysconfig/network-script/route-*

OpenStackのCluster Manager VMの復元

ステップ1：次のコマンドに示すように、クラスタマネージャVMスナップショットをコントローラブレードにコピーします。

ls —ltr *snapshot*

出力例：-rw-r—r— 1ルートルート10429595648 8月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コマンドを使用してCluman 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 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

以下に、いくつかの例を示します。nova rebuild cps-cluman-5f3tujqvbi67 cluman_snapshot

ステップ5次に示すように、すべてのインスタンスをリストし、新しいCluster Managerインスタンスが作成されて実行されていることを確認します。

ノバリスト

図 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 start all 10.コンポーネントが更新されていることを確認し、次のコマンドを実行します。about.sh

クロジョブの復元

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：次の例に示すように、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をマスターとしてpcrfclient02を使用して、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でもある場合は、次の手順を実行します。

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：最新の設定を使用して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へのシェルを保護し、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)のコレクション「account」内のレコード数を示します。

Subversionリポジトリの復元

バックアップからPolicy Builder設定データを復元するには、次のコマンドを実行します。

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

グラフダッシュボードの復元

次のコマンドを使用して、Grafanaダッシュボードを復元できます。

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

リストアの検証

データを復元したら、次のコマンドを使用して作業システムを確認します。

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

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を手動でリカバリする必要があります。

- クラスタが完全に使用不可で、ESCのみが到達可能な場合は、Cronjobsを介して実行されるスケジュールされたバックアップから取得された最新のバックアップから復元を実行する必要があります。回復手順は、MOPで説明した手順と同じです。