CPAR VMのスナップショットとリカバリ
内容
概要
このドキュメントでは、認証、認可、アカウンティング(AAA)インスタンスをバックアップ（スナップショット）する手順について説明します。
背景説明
加入者のトラフィックへの影響を最小限に抑えるには、サイトごと、およびサイトごとに1つずつ実行する必要があります。
この手順は、Elastic Services Controller(ESC)でCisco Prime Access Registrar(CPAR)を管理せず、CPARがOpenstackに導入された仮想マシン(VM)に直接インストールされているNEWTONバージョンを使用するOpenstack環境にに適用します。
Ultra-Mは、仮想ネットワーク機能(VNF)の導入を簡素化するために設計された、パッケージ化および検証済みの仮想モバイルパケットコアソリューションで、Ultra-Mの仮想インフラストラクチャマネージャ(VIM)で、次のノードタイプで構成されています。
- 計算
- オブジェクトストレージディスク – コンピューティング（OSD – コンピューティング）
- コントローラ
- OpenStackプラットフォーム – Director(OSPD)
-
Ultra-Mのアーキテクチャと関連するコンポーネントを次の図に示します。
このドキュメントは、Cisco Ultra-Mプラットフォームに精通しているシスコ担当者を対象としており、OpenStackおよびRedhat OSで実行するために必要な手順の詳細を説明しています。
ネットワークへの影響
一般に、CPARのプロセスがダウンすると、KPIの低下が予想されます。アプリケーションをシャットダウンすると、直径ピアダウントラップが送信されるまで最大5分かかります。この時点で、CPARにルーティングされたすべての要求は失敗します。その後、リンクがダウンしていると判断され、Diameter Routing Agent(DRA)は、このノードへのトラフィックのルーティングを停止します。
さらに、シャットダウンされたAAA内の既存のすべてのセッションについては、別のアクティブなAAAとの接続/デタッチ手順が存在する場合、シャットダウンされたAAAにユーザが登録され、手順が正常に完了できない。
STRのパフォーマンスは、課題が完了してから10時間ほどで90 %未満の成功率が見込まれます。その後、90%の正常値に達する必要があります。
アラーム
Simple Network Management Protocol（SNMP；簡易ネットワーク管理プロトコル）アラームは、CPARサービスが停止して開始されるたびに生成されるため、プロセス全体でSNMPトラップが生成されることが予想されます。次のトラップが必要です。
- CPARサーバ停止
- VMダウン
- NODE DOWN（ノード停止）:CPARインスタンスによって直接生成されないアラームが予想されます。
- DRA
VMスナップショットバックアップ
CPARアプリケーションのシャットダウン
ステップ1:Transformation Management Office(TMO)実稼働ネットワークに接続されているセキュアシェル(SSH)クライアントを開き、CPARインスタンスに接続します。
ステップ2:CPARアプリケーションをシャットダウンするには、次のコマンドを実行します。
/opt/CSCOar/bin/arserver stop
「Cisco Prime Access Registrar Server Agent shutdown complete」というメッセージが表示されます。
ERROR: You can not shut down Cisco Prime Access Registrar while the
CLI is being used. Current list of running
CLI with process id is:
2903 /opt/CSCOar/bin/aregcmd –s
この例では、CPARを停止する前に、強調表示されたプロセスID 2903を終了する必要があります。このような場合は、コマンドを実行して、次のプロセスを終了します。
kill -9 *process_id*
次に、ステップ1を繰り返します。
ステップ3:CPARアプリケーションが実際にシャットダウンされたことを確認するには、次のコマンドを実行します。
/opt/CSCOar/bin/arstatus
次のメッセージが表示されます。
Cisco Prime Access Registrar Server Agent not running Cisco Prime Access Registrar GUI not running
VMバックアップスナップショットタスク
ステップ1：現在作業しているサイト（都市）に対応するHorizon GUI Webサイトを入力します。
Horizonにアクセスすると、図に示すように画面が表示されます。
ステップ2：図に示すように、[プロジェクト] > [インスタンス]に移動します。
ユーザがCPARの場合、このメニューには4つのAAAインスタンスだけが表示されます。
ステップ3：一度に1つのインスタンスだけをシャットダウンし、このドキュメントのプロセス全体を繰り返します。VMをシャットダウンするには、図に示すように[Actions] > [Shut Off Instance]に移動し、選択内容を確認します。
ステップ4：インスタンスが実際にシャットダウンされていることを確認するには、次の図に示すように、[Status] = [Shutoff]、[Power State] = [Shut Down]をチェックします。
この手順により、CPARシャットダウンプロセスが終了します。
VMスナップショット
CPAR VMがダウンすると、スナップショットは独立した計算に属するため、並行して取得できます。
4つのQCOW2ファイルが並行して作成されます。
ステップ1：各AAAインスタンスのスナップショットを作成します。
ステップ2:PODのOpenstackのHorizon GUIにログインします。
ステップ3：ログインしたら、トップメニューの[Project] > [Compute] > [Instances]に移動し、図に示すようにAAAインスタンスを探します。
ステップ3：図に示すように、[Create Snapshot]をクリックして、スナップショットの作成を続行します。これは、対応するAAAインスタンスで実行する必要があります。
ステップ4：スナップショットが実行されたら、[Images]メニューに移動し、すべての完了を確認し、図に示すように問題が報告されていないことを確認します。
ステップ5：次のステップは、このプロセスでOSPDが失われた場合に、QCOW2形式でスナップショットをダウンロードし、リモートエンティティに転送することです。これを行うには、図に示すように、コマンドglance image-listをOSPDレベルで実行して、スナップショットを識別します。
ステップ6：ダウンロードするスナップショット（この場合は緑色でマークされているスナップショット）を特定したら、コマンドglance image-downloadを使用してQCOW2形式でダウンロードできます。
[root@elospd01 stack]# glance image-download 92dfe18c-df35-4aa9-8c52-9c663d3f839b --file /tmp/AAA-CPAR-LGNoct192017.qcow2 &
プロセスをバックランドに送信します(&S)。操作を完了するには時間がかかります。このイメージを作成したら、/tmpディレクトリに配置できます。
- プロセスをバックグラウンドに送信し、接続が失われた場合、プロセスも停止します。
- disown -hコマンドを実行して、SSH接続が失われた場合でも、プロセスがOSPDで実行されて終了するようにします。
ステップ7：ダウンロード処理が終了したら、圧縮プロセスを実行する必要があります。これは、オペレーティングシステム(OS)によって処理されるプロセス、タスク、一時ファイルが原因で、スナップショットにゼロを埋め込むことができるためです。 ファイル圧縮のために実行するコマンドはvirt-sparsifyです。
[root@elospd01 stack]# virt-sparsify AAA-CPAR-LGNoct192017.qcow2 AAA-CPAR-LGNoct192017_compressed.qcow2
このプロセスには時間がかかる場合があります（約10 ～ 15分）。 完了すると、次の手順で指定した外部エンティティに転送する必要があるファイルが結果として表示されます。
ファイルの整合性を確認する必要があります。これを行うには、次のコマンドを実行し、出力の最後に「corrupt」属性を探します。
[root@wsospd01 tmp]# qemu-img info AAA-CPAR-LGNoct192017_compressed.qcow2
image: AAA-CPAR-LGNoct192017_compressed.qcow2
file format: qcow2
virtual size: 150G (161061273600 bytes)
disk size: 18G
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false
ステップ8:OSPDが失われる問題を回避するには、QCOW2形式で最近作成したスナップショットを外部エンティティに転送する必要があります。ファイル転送を開始する前に、宛先に十分な空きディスク領域があるかどうかを確認し、コマンドdf -khを実行してメモリ領域を確認する必要があります。
アドバイスは、SFTP sftp root@x.x.x.xwhere x.x.x.xはリモートOSPDのIPを使用して、別のサイトのOSPDに一時的に転送することです。
ステップ9：転送を高速化するために、宛先を複数のOSPDに送信できます。同じ方法でscp *name_of_the_file*.qcow2 root@ x.x.x.x.x:/tmp (x.x.x.xはリモートOSPDのIPです)コマンドを実行して、ファイルを別のOSPDに転送できます。
スナップショットによるインスタンスのリカバリ
リカバリプロセス
前のステップで実行したスナップショットを使用して、前のインスタンスを再展開できます。
ステップ1:[オプション]使用可能な以前のVMスナップショットがない場合は、バックアップが送信されたOSPDノードに接続し、バックアップを元のOSPDノードに送信します。sftp root@x.x.x.xを使用します。x.x.x.xは元のOSPDのIPです。スナップショットファイルを/tmpディレクトリに保存します。
ステップ2：図に示すように、インスタンスが再展開されるOSPDノードに接続します。
ステップ3：スナップショットをイメージとして使用するには、必要に応じて地平線にアップロードする必要があります。次のコマンドを使用して実行します。
#glance image-create -- AAA-CPAR-Date-snapshot.qcow2 --container-format bare --disk-format qcow2 --name AAA-CPAR-Date-snapshot
このプロセスは、次の図に示すように水平線で確認できます。
ステップ4:HorizonでProject > Instancesに移動し、図に示すようにLaunch Instanceをクリックします。
ステップ5：インスタンス名を入力し、図に示すように[Availability Zone]を選択します。
ステップ6:[Source]タブで、インスタンスを作成するイメージを選択します。[Select Boot Source]メニューでイメージを選択し、イメージのリストを次に示します。図に示すように、その+記号をクリックして、以前にアップロードしたものを選択します。
ステップ7:[Flavor]タブで、図に示すように+記号をクリックして[AAA Flavor]を選択します。
ステップ8：最後に、[Networks]タブに移動し、+記号をクリックしてインスタンスに必要なネットワークを選択します。この場合は、図に示すように、diameter-soutable1、radius-routable1、tb1-mgmtを選択します。
ステップ9:[Launch Instance]をクリックして、インスタンスを作成します。図に示すように、進行状況をホライズンでモニタできます。
ステップ10：数分後に、インスタンスが完全に導入され、次の図に示すように使用可能になります。
フローティングIPアドレスの作成と割り当て
フローティングIPアドレスは、ルーティング可能なアドレスです。つまり、Ultra M/Openstackアーキテクチャの外部から到達可能であり、ネットワークの他のノードと通信できます。
ステップ1:[Horizon]トップメニューで、[Admin] > [Floating IPs]に移動します。
ステップ2:[Allocate IP to Project]をクリックします。
ステップ3：図に示すように、「フローティングIPの割り当て」ウィンドウで、新しいフローティングIPが属するプール、割り当て先のプロジェクト、新しいフローティングIPアドレスを選択します。
ステップ4:[Allocate Floating IP]をクリックします。
ステップ5:[Horizon]トップメニューで、[Project] > [Instances]に移動します。
ステップ6:[アクション]列で、[スナップショットの作成]ボタンを下に向く矢印をクリックすると、メニューが表示されます。[Associate Floating IP]オプションをクリックします。
ステップ7:IP Addressフィールドで使用する対応するフローティングIPアドレスを選択し、図に示すように、このフローティングIPが関連付けられるポートで割り当てられる新しいインスタンスから対応する管理インターフェイス(eth0)を選択します。 
ステップ8:[Associate]をクリックします。
SSH の有効化
ステップ1:[Horizon]トップメニューで、[Project] > [Instances]に移動します。
ステップ2:「新規インスタンスの起動」セクションで作成したインスタンス/VMの名前をクリックします。
ステップ3:[Console]をクリックします。VMのCLIが表示されます。
ステップ4:CLIが表示されたら、次の図に示すように適切なログインクレデンシャルを入力します。
ユーザ名:root
パスワード：<cisco123>
ステップ5:CLIでコマンドvi /etc/ssh/sshd_configを実行して、SSH設定を編集します。
ステップ6:SSH設定ファイルが開いたら、Iキーを押してファイルを編集します。次に、図に示すように、最初の行をPasswordAuthentication noからPasswordAuthentication yesに変更します。
ステップ7: ESCキーを押し、:wq！と入力してsshd_configファイルの変更を保存します。
ステップ8：図に示すように、service sshd restartコマンドを実行します。
ステップ9:SSH設定の変更が正しく適用されているかどうかをテストするために、任意のSSHクライアントを開き、インスタンス(10.145.0.249)およびユーザroot)に割り当てられたリモートセキュア接続を試行します。
SSHセッションの確立
ステップ1：図に示すように、アプリケーションがインストールされている対応するVM/サーバのIPアドレスでSSHセッションを開きます。
CPARインスタンス開始
アクティビティが完了し、シャットダウンされたサイトでCPARサービスを再確立できたら、次の手順に従います。
ステップ1：ホライズンにログインし、[project] > [instance] > [start instance]に移動します。
ステップ2：図に示すように、インスタンスの[Status]が[Active]で、[Power State]が[Running]であることを確認します。
アクティビティ後のヘルスチェック
ステップ1:OSレベルでコマンド/opt/CSCOar/bin/arstatusを実行します。
[root@wscaaa04 ~]# /opt/CSCOar/bin/arstatus Cisco Prime AR RADIUS server running (pid: 24834) Cisco Prime AR Server Agent running (pid: 24821) Cisco Prime AR MCD lock manager running (pid: 24824) Cisco Prime AR MCD server running (pid: 24833) Cisco Prime AR GUI running (pid: 24836) SNMP Master Agent running (pid: 24835) [root@wscaaa04 ~]#
ステップ2:OSレベルでコマンド/opt/CSCOar/bin/aregcmdを実行し、管理者クレデンシャルを入力します。CPAR Healthが10のうち10であることを確認し、CPAR CLIを終了します。
[root@aaa02 logs]# /opt/CSCOar/bin/aregcmd
Cisco Prime Access Registrar 7.3.0.1 Configuration Utility
Copyright (C) 1995-2017 by Cisco Systems, Inc. All rights reserved.
Cluster:
User: admin
Passphrase:
Logging in to localhost
[ //localhost ]
LicenseInfo = PAR-NG-TPS 7.3(100TPS:)
PAR-ADD-TPS 7.3(2000TPS:)
PAR-RDDR-TRX 7.3()
PAR-HSS 7.3()
Radius/
Administrators/
Server 'Radius' is Running, its health is 10 out of 10
--> exit
ステップ3：コマンドnetstatを実行する | grep diameterとして、すべてのDRA接続が確立されていることを確認します。
ここで説明する出力は、Diameterリンクが必要な環境を対象としています。表示されるリンク数が少ない場合は、分析が必要なDRAからの切断を表します。
[root@aa02 logs]# netstat | grep diameter tcp 0 0 aaa02.aaa.epc.:77 mp1.dra01.d:diameter ESTABLISHED tcp 0 0 aaa02.aaa.epc.:36 tsa6.dra01:diameter ESTABLISHED tcp 0 0 aaa02.aaa.epc.:47 mp2.dra01.d:diameter ESTABLISHED tcp 0 0 aaa02.aaa.epc.:07 tsa5.dra01:diameter ESTABLISHED tcp 0 0 aaa02.aaa.epc.:08 np2.dra01.d:diameter ESTABLISHED
ステップ4:TelePresence Server(TPS)ログに、CPARによって処理された要求が表示されることを確認します。強調表示された値はTPSを表し、これらは注意が必要な値です。
TPSの値は1500を超えることはできません。
[root@wscaaa04 ~]# tail -f /opt/CSCOar/logs/tps-11-21-2017.csv 11-21-2017,23:57:35,263,0 11-21-2017,23:57:50,237,0 11-21-2017,23:58:05,237,0 11-21-2017,23:58:20,257,0 11-21-2017,23:58:35,254,0 11-21-2017,23:58:50,248,0 11-21-2017,23:59:05,272,0 11-21-2017,23:59:20,243,0 11-21-2017,23:59:35,244,0 11-21-2017,23:59:50,233,0
ステップ5:name_radius_1_logで「error」または「alarm」メッセージを探します。
[root@aaa02 logs]# grep -E "error|alarm" name_radius_1_log
ステップ6:CPARプロセスが使用するメモリ量を確認するには、次のコマンドを実行します。
top | grep radius
[root@sfraaa02 ~]# top | grep radius 27008 root 20 0 20.228g 2.413g 11408 S 128.3 7.7 1165:41 radius
この強調表示された値は、アプリケーションレベルで許可される最大値である7 Gbより小さい必要があります。
フィードバック