バックアップとリカバリ – クラスタ全体のリカバリ – CPS
内容
概要
このドキュメントでは、CPS仮想ネットワーク機能(VNF)をホストするUltra-MセットアップでCPSクラスタ全体を回復するために必要な手順について説明します。
背景説明
Ultra-Mは、VNFの導入を簡素化するように設計された、パッケージ化および検証済みの仮想化モバイルパケットコアソリューションです。Ultra-Mソリューションは、次の仮想マシン(VM)タイプで構成されます。
- Elastic Services Controller（ESC）
- Cisco Policy Suite(CPS)
Ultra-Mのアーキテクチャと関連するコンポーネントを次の図に示します。
このドキュメントは、Cisco Ultra-Mプラットフォームに精通したシスコ担当者を対象としています。
省略形
| 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
クロジョブの復元
- バックアップしたファイルをOSPDからCluman/Pcrfclient01に移動します
- コマンドを実行して、バックアップからcronjobをアクティブ化します
#crontab cron-backup - 次のコマンドで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
ステップ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開始/停止スクリプトを作成します。すべての導入で、これらのデータベースがすべて設定されているわけではありません。
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で説明した手順と同じです。
フィードバック