内容

概要

背景説明

省略形

MoPのワークフロー

CPARアプリケーションのシャットダウン

VMスナップショットタスク

VMスナップショット

VMの復元

スナップショットによるインスタンスのリカバリ

フローティングIPアドレスの作成と割り当て

SSH の有効化

SSHセッションの確立

CPARインスタンス開始

アクティビティ後のヘルスチェック

概要

このドキュメントでは、Ultra-Mセットアップで故障したオブジェクトストレージディスク(OSD)コンピューティングサーバを交換するために必要な手順について説明します。

この手順は、ESCがCPARを管理せず、CPARがOpenstackに導入された仮想マシン(VM)に直接インストールされるNEWTONバージョンのOpenstack環境に適用されます。

背景説明

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

- 計算

- OSD – コンピューティング

- コントローラ

- OpenStackプラットフォーム – Director(OSPD)

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

このドキュメントは、Cisco Ultra-Mプラットフォームに精通しているシスコの担当者を対象としており、OpenStackおよびRedhat Operating System(OS)で実行する必要がある手順の詳細を説明しています。

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

省略形

MOP

メソッド

OSD

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

OSPD

OpenStack Platform Director

HDD

ハードディスクドライブ

SSD

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

VIM

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

VM

仮想マシン

EM

エレメント マネージャ

UAS

Ultra Automation Services

UUID

ユニバーサル一意IDentifier

MoPのワークフロー

バックアップ

コンピュートノードを置き換える前に、Red Hat OpenStackプラットフォーム環境の現在の状態を確認することが重要です。コンピューティングの交換プロセスがオンの場合は、複雑さを避けるために現在の状態を確認することをお勧めします。この交換フローによって実現できます。

リカバリの場合は、次の手順を使用してOSPDデータベースのバックアップを取ることを推奨します。

[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

このプロセスにより、インスタンスの可用性に影響を与えることなく、ノードを確実に交換できます。

注：必要に応じてVMをリストアできるように、インスタンスのスナップショットがあることを確認します。VMのスナップショットを作成する手順に従います。

1. OSDコンピューティングノードでホストされるVMを特定します。

2. サーバでホストされているVMを特定します。

[stack@director ~]$ nova list --field name,host | grep osd-compute-0

| 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | pod2-stack-compute-4.localdomain |

注：ここに示す出力では、最初の列が汎用一意識別子(UUID)に対応し、2番目の列がVM名、3番目の列がVMが存在するホスト名です。この出力のパラメータは、以降のセクションで使用します。

CPARアプリケーションのシャットダウン

ステップ1：ネットワークに接続されているSecure Shell(SSH)クライアントを開き、CPARインスタンスに接続します。

1つのサイト内のすべての4つのAAAインスタンスを同時にシャットダウンしないようにし、1つずつ実行することが重要です。

ステップ2:CPARアプリケーションをシャットダウンするには、次のコマンドを実行します。

/opt/CSCOar/bin/arserver stop

「Cisco Prime Access Registrar Server Agent shutdown complete」というメッセージ 表示する必要があります。

注：ユーザーがコマンドラインインターフェイス(CLI)セッションを開いたままにした場合、arserver stopコマンドは機能せず、このメッセージが表示されます。

ERROR:    You cannot 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：次の図に示すように、ステータス=シャットオフおよび電源の状態=シャットダウンをチェックして、インスタンスが実際にシャットダウンされたことを確認します。

この手順により、CPARシャットダウンプロセスが終了します。

VMスナップショット

CPAR VMがダウンすると、スナップショットは独立した計算に属するため、並行して取得できます。

4つのQCOW2ファイルが並行して作成されます。

各AAAインスタンスのスナップショットを作成します。（25分–1時間）（qcowイメージをソースとして使用したインスタンスは25分、rawイメージをソースとして使用したインスタンスは1時間）

1. PODのOpenstackのHorizon GUIにログインします。

2. ログインしたら、トップメニューの[Project] > [Compute] > [Instances]セクションに移動し、次の図に示すようにAAAインスタンスを探します。

3.次の図に示すように、[Create Snapshot]をクリックして、スナップショットの作成を続行します（これは、対応するAAAインスタンスで実行する必要があります）。

4.スナップショットが実行されたら、[Images]をクリックして、すべての完了を確認し、次の図に示すように問題が報告されていないことを確認します。

5.次のステップは、このプロセス中にOSPDが失われた場合に、QCOW2形式でスナップショットをダウンロードし、リモートエンティティに転送することです。これを行うには、コマンドglance image-listをOSPDレベルで実行して、スナップショットを識別してください。

[root@elospd01 stack]# glance image-list

+--------------------------------------+---------------------------+

| ID                                   | Name                      |             +--------------------------------------+---------------------------+

| 80f083cb-66f9-4fcf-8b8a-7d8965e47b1d | AAA-Temporary             |             | 22f8536b-3f3c-4bcc-ae1a-8f2ab0d8b950 | ELP1 cluman 10_09_2017    |

| 70ef5911-208e-4cac-93e2-6fe9033db560 | ELP2 cluman 10_09_2017    |

| e0b57fc9-e5c3-4b51-8b94-56cbccdf5401 | ESC-image                 |

| 92dfe18c-df35-4aa9-8c52-9c663d3f839b | lgnaaa01-sept102017       |

| 1461226b-4362-428b-bc90-0a98cbf33500 | tmobile-pcrf-13.1.1.iso   |

| 98275e15-37cf-4681-9bcc-d6ba18947d7b | tmobile-pcrf-13.1.1.qcow2 |

+--------------------------------------+---------------------------+

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

- OSPDが失われる問題を回避するには、QCOW2形式で最近作成したスナップショットを外部エンティティに転送する必要があります。ファイル転送を開始する前に、宛先に十分な空きディスク領域があるかどうかを確認し、コマンドdf -khを実行してメモリ領域を確認する必要があります。アドバイスの1つは、SFTP sftp root@x.x.x.xを使用して別のサイトのOSPDに一時的に転送することです。 x.x.x.xはリモートOSPDのIPです。転送を高速化するために、宛先を複数のOSPDに送信できます。同じ方法でscp *name_of_the_file*.qcow2 root@ x.x.x.x.x:/tmp （x.x.x.xはリモートOSPDのIP）コマンドを実行して、ファイルを別のOSPDに転送できます。

1. OSDコンピューティングノードでホストされるVMを特定します。

2. サーバでホストされているVMを特定します。

[stack@director ~]$ nova list --field name,host | grep osd-compute-0

| 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | pod2-stack-compute-4.localdomain |

注：ここに示す出力では、最初の列が汎用一意識別子(UUID)に対応し、2番目の列がVM名、3番目の列がVMが存在するホスト名です。この出力のパラメータは、以降のセクションで使用します。

- 単一のOSDサーバを削除できるように、CEPHに使用可能な容量があることを確認します。

[heat-admin@pod2-stack-osd-compute-0 ~]$ sudo ceph df

GLOBAL:

SIZE       AVAIL      RAW USED     %RAW USED

13393G     11088G        2305G         17.21

POOLS:

NAME        ID     USED      %USED     MAX AVAIL     OBJECTS

rbd         0          0         0         3635G           0

metrics     1      3452M      0.09         3635G      219421

images      2       138G      3.67         3635G       43127

backups     3          0         0         3635G           0

volumes     4       139G      3.70         3635G       36581

vms         5       490G     11.89         3635G      126247

- ceph osdツリーのステータスがosdコンピュートサーバでアップしていることを確認します。

[heat-admin@pod2-stack-osd-compute-0 ~]$ sudo ceph osd tree

ID WEIGHT   TYPE NAME                         UP/DOWN REWEIGHT PRIMARY-AFFINITY

-1 13.07996 root default

-2  4.35999     host pod2-stack-osd-compute-0

0  1.09000         osd.0                          up  1.00000          1.00000

3  1.09000         osd.3                          up  1.00000          1.00000

6  1.09000         osd.6                          up  1.00000          1.00000

9  1.09000         osd.9                          up  1.00000          1.00000

-3  4.35999     host pod2-stack-osd-compute-1

1  1.09000         osd.1                          up  1.00000          1.00000

4  1.09000         osd.4                          up  1.00000          1.00000

7  1.09000         osd.7                          up  1.00000          1.00000

10  1.09000         osd.10                         up  1.00000          1.00000

-4  4.35999     host pod2-stack-osd-compute-2

2  1.09000         osd.2                          up  1.00000          1.00000

5  1.09000         osd.5                          up  1.00000          1.00000

8  1.09000         osd.8                          up  1.00000          1.00000

11  1.09000         osd.11                         up  1.00000          1.00000

- CEPHプロセスはosd-computeサーバ上でアクティブです。

[heat-admin@pod2-stack-osd-compute-0 ~]$ systemctl list-units *ceph*

UNIT                             LOAD   ACTIVE SUB     DESCRIPTION

var-lib-ceph-osd-ceph\x2d0.mount loaded active mounted /var/lib/ceph/osd/ceph-0

var-lib-ceph-osd-ceph\x2d3.mount loaded active mounted /var/lib/ceph/osd/ceph-3

var-lib-ceph-osd-ceph\x2d6.mount loaded active mounted /var/lib/ceph/osd/ceph-6

var-lib-ceph-osd-ceph\x2d9.mount loaded active mounted /var/lib/ceph/osd/ceph-9

ceph-osd@0.service               loaded active running Ceph object storage daemon

ceph-osd@3.service               loaded active running Ceph object storage daemon

ceph-osd@6.service               loaded active running Ceph object storage daemon

ceph-osd@9.service               loaded active running Ceph object storage daemon

system-ceph\x2ddisk.slice        loaded active active  system-ceph\x2ddisk.slice

system-ceph\x2dosd.slice         loaded active active  system-ceph\x2dosd.slice

ceph-mon.target                  loaded active active  ceph target allowing to start/stop all ceph-mon@.service instances at once

ceph-osd.target                  loaded active active  ceph target allowing to start/stop all ceph-osd@.service instances at once

ceph-radosgw.target              loaded active active  ceph target allowing to start/stop all ceph-radosgw@.service instances at once

ceph.target                      loaded active active  ceph target allowing to start/stop all ceph*@.service instances at once

LOAD   = Reflects whether the unit definition was properly loaded.

ACTIVE = The high-level unit activation state, i.e. generalization of SUB.

SUB    = The low-level unit activation state, values depend on unit type.

14 loaded units listed. Pass --all to see loaded but inactive units, too.

To show all installed unit files use 'systemctl list-unit-files'.

- 各cephインスタンスを無効にして停止し、各インスタンスをosdから削除して、ディレクトリをアンマウントします。cephインスタンスごとに繰り返します。

[heat-admin@pod2-stack-osd-compute-0  ~]# systemctl disable ceph-osd@0

[heat-admin@pod2-stack-osd-compute-0 ~]# systemctl stop ceph-osd@0

[heat-admin@pod2-stack-osd-compute-0 ~]# ceph osd out 0

- osd.0がマークされました。

[heat-admin@pod2-stack-osd-compute-0 ~]# ceph osd crush remove osd.0

- クラッシュマップから項目id 0名「osd.0」を削除

[heat-admin@pod2-stack-osd-compute-0  ~]# ceph auth del osd.0

- updated

[heat-admin@pod2-stack-osd-compute-0 ~]# ceph osd rm 0

- osd.0の削除

[heat-admin@pod2-stack-osd-compute-0 ~]# umount /var/lib/ceph.osd/ceph-0

[heat-admin@pod2-stack-osd-compute-0 ~]# rm -rf /var/lib/ceph.osd/ceph-0

または、

- Clean.shスクリプトは、このタスクに一度に使用できます。

[heat-admin@pod2-stack-osd-compute-0 ~]$ sudo ls /var/lib/ceph/osd

ceph-0  ceph-3  ceph-6  ceph-9

[heat-admin@pod2-stack-osd-compute-0 ~]$ /bin/sh clean.sh

[heat-admin@pod2-stack-osd-compute-0 ~]$ cat clean.sh

#!/bin/sh

set -x

CEPH=`sudo ls /var/lib/ceph/osd`

for c in $CEPH

do

i=`echo $c |cut -d'-' -f2`

sudo systemctl disable ceph-osd@$i || (echo "error rc:$?"; exit 1)

sleep 2

sudo systemctl stop ceph-osd@$i || (echo "error rc:$?"; exit 1)

sleep 2

sudo ceph osd out $i || (echo "error rc:$?"; exit 1)

sleep 2

sudo ceph osd crush remove osd.$i || (echo "error rc:$?"; exit 1)

sleep 2

sudo ceph auth del osd.$i || (echo "error rc:$?"; exit 1)

sleep 2

sudo ceph osd rm $i || (echo "error rc:$?"; exit 1)

sleep 2

sudo umount /var/lib/ceph/osd/$c || (echo "error rc:$?"; exit 1)

sleep 2

sudo rm -rf /var/lib/ceph/osd/$c || (echo "error rc:$?"; exit 1)

sleep 2

done

sudo ceph osd tree

すべてのOSDプロセスが移行/削除されると、ノードをオーバークラウドから削除できます。

注：CEPHが削除されると、VNF HD RAIDはDegraded状態になりますが、hdディスクにアクセスできる必要があります。

グレースフルパワーオフ

- ノードの電源オフ

1. インスタンスの電源をオフにするには：nova stop <INSTANCE_NAME>

2. インスタンス名は、ステータスシャットオフで確認できます。

[stack@director ~]$ nova stop  aaa2-21

Request to stop server aaa2-21 has been accepted.

[stack@director ~]$ nova list

+--------------------------------------+---------------------------+---------+------------+-------------+------------------------------------------------------------------------------------------------------------+

| ID                                   | Name                      | Status  | Task State | Power State | Networks                                                                                                   |

+--------------------------------------+---------------------------+---------+------------+-------------+------------------------------------------------------------------------------------------------------------+

| 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | ACTIVE  | -          | Running     | tb1-mgmt=172.16.181.14, 10.225.247.233; radius-routable1=10.160.132.245; diameter-routable1=10.160.132.231 |

| 3bc14173-876b-4d56-88e7-b890d67a4122 | aaa2-21                   | SHUTOFF | -          | Shutdown    | diameter-routable1=10.160.132.230; radius-routable1=10.160.132.248; tb1-mgmt=172.16.181.7, 10.225.247.234  |

| f404f6ad-34c8-4a5f-a757-14c8ed7fa30e | aaa21june                 | ACTIVE  | -          | Running     | diameter-routable1=10.160.132.233; radius-routable1=10.160.132.244; tb1-mgmt=172.16.181.10                 |

+--------------------------------------+---------------------------+---------+------------+-------------+------------------------------------------------------------------------------------------------------------+

- ノードの削除

このセクションで説明する手順は、コンピューティングノードでホストされるVMに関係なく共通できます。

サービス・リストからOSDコンピュート・ノードを削除します。

- サービスリストからコンピュートサービスを削除します。
[stack@director ~]$ openstack compute service list |grep osd-compute

| 135 | nova-compute     | pod2-stack-osd-compute-1.localdomain | AZ-esc2  | enabled | up    | 2018-06-22T11:05:22.000000 |

| 150 | nova-compute     | pod2-stack-osd-compute-2.localdomain | nova     | enabled | up    | 2018-06-22T11:05:17.000000 |

| 153 | nova-compute     | pod2-stack-osd-compute-0.localdomain | AZ-esc1  | enabled | up    | 2018-06-22T11:05:25.000000 |

- openstack 計算 service delete <ID>

[stack@director ~]$ openstack compute service delete 150

Neutronエージェントの削除

- 古い関連付けられたNeutronエージェントを削除し、ComputerServerのvswitchエージェントを開きます。
[stack@director ~]$ openstack network agent list | grep osd-compute-0

| eaecff95-b163-4cde-a99d-90bd26682b22 | Open vSwitch agent | pod2-stack-osd-compute-0.localdomain | None              | True  | UP    | neutron-openvswitch-agent |

- openstack network agent delete <ID>

[stack@director ~]$ openstack network agent delete eaecff95-b163-4cde-a99d-90bd26682b22

Ironicデータベースから削除

- 皮肉なデータベースからノードを削除し、確認します。

[root@director ~]#  nova list | grep osd-compute-0

| 6810c884-1cb9-4321-9a07-192443920f1f | pod2-stack-osd-compute-0 | ACTIVE | -          | Running     | ctlplane=192.200.0.109 |

[root@al03-pod2-ospd ~]$ nova delete 6810c884-1cb9-4321-9a07-192443920f1f

- nova show <compute -node> | grep hypervisor

[root@director ~]# source stackrc

[root@director ~]#  nova show pod2-stack-osd-compute-0 | grep hypervisor

| OS-EXT-SRV-ATTR:hypervisor_hostname  | 05ceb513-e159-417d-a6d6-cbbcc4b167d7

- ironic node-delete <ID>

[stack@director ~]$ ironic node-delete 05ceb513-e159-417d-a6d6-cbbcc4b167d7

[stack@director ~]$ ironic node-list

削除されたノードを皮肉なノードリストにリストすることはできません。

オーバークラウドから削除

- 次に示すように、内容を含むdelete_node.shという名前のスクリプトファイルを作成します。記載されているテンプレートが、スタック展開に使用されるdeploy.shスクリプトで使用されるテンプレートと同じであることを確認します。

- delete_node.sh:

openstack overcloud node delete --templates -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml -e /home/stack/custom-templates/layout.yaml --stack <stack-name> <UUID>

[stack@director ~]$ source stackrc

[stack@director ~]$ /bin/sh delete_node.sh

+ openstack overcloud node delete --templates -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml -e /home/stack/custom-templates/layout.yaml --stack pod2-stack 7439ea6c-3a88-47c2-9ff5-0a4f24647444

Deleting the following nodes from stack pod2-stack:

- 7439ea6c-3a88-47c2-9ff5-0a4f24647444

Started Mistral Workflow. Execution ID: 4ab4508a-c1d5-4e48-9b95-ad9a5baa20ae

real   0m52.078s

user   0m0.383s

sys    0m0.086s

- OpenStackスタックの動作がCOMPLETE状態に移行するのを待ちます。

[stack@director ~]$  openstack stack list

+--------------------------------------+------------+-----------------+----------------------+----------------------+

| ID                                   | Stack Name | Stack Status    | Creation Time        | Updated Time         |

+--------------------------------------+------------+-----------------+----------------------+----------------------+

| 5df68458-095d-43bd-a8c4-033e68ba79a0 | pod2-stack | UPDATE_COMPLETE | 2018-05-08T21:30:06Z | 2018-05-08T20:42:48Z |

+--------------------------------------+------------+-----------------+----------------------+----------------------+

新しいコンピューティングノードのインストール

- 新しいUCS C240 M4サーバをインストールする手順と初期セットアップ手順は、次から参照できます。

『Cisco UCS C240 M4 Server Installation and Service Guide』

- サーバのインストールが完了したら、ハードディスクを古いサーバとしてそれぞれのスロットに挿入します。

- CIMC IPを使用してサーバにログインします。

- ファームウェアが以前に使用した推奨バージョンと異なる場合は、BIOSアップグレードを実行します。BIOSアップグレードの手順は次のとおりです。

Cisco UCS CシリーズラックマウントサーバBIOSアップグレードガイド

- 物理ドライブのステータスを確認します。構成を解除する必要があります。

次の図に示すように、[Storage] > [Cisco 12G SAS Modular Raid Controller (SLOT-HBA)] > [Physical Drive Info]に移動します。

- RAIDレベル1の物理ドライブから仮想ドライブを作成します。

次の図に示すように、[Storage] > [Cisco 12G SAS Modular Raid Controller (SLOT-HBA)] > [Controller Info] > [Create Virtual Drive from Unused Physical Drives]に移動します。

- VDを選択し、図に示すように[Set as Boot Drive]を設定します。

- IPMI over LANの有効化：

図に示すように、[Admin] > [Communication Services] > [Communication Services]に移動します。

- ハイパースレッディングを無効にします。

図に示すように、[Compute] > [BIOS] > [Configure BIOS] > [Advanced] > [Processor Configuration]に移動します。

- 物理ドライブ1および2で作成されたBOOTOS VDと同様に、次の4つの仮想ドライブを作成します。

JOURNAL > From physical drive number 3

OSD1 > From physical drive number 7

OSD2 > From physical drive number 8

OSD3 > From physical drive number 9

OSD4 > From physical drive number 10

- 最後に、物理ドライブと仮想ドライブは、図に示すように類似している必要があります。

注：このセクションで説明するイメージと設定手順は、ファームウェアバージョン3.0(3e)を参照するもので、他のバージョンで作業する場合は、若干の違いがあります。

Overcloudへの新しいOSDコンピューティングノードの追加

このセクションで説明する手順は、コンピューティングノードによってホストされるVMに関係なく共通しています。

- 別のインデックスを持つコンピューティングサーバーを追加します。

追加する新しいコンピュートサーバの詳細のみを含むadd_node.jsonファイルを作成します。新しいコンピュートサーバのインデックス番号が以前に使用されていないことを確認します。通常は、次に高い計算値を増やします。

例：最も前のバージョンはosd-compute-17で、2-vnfシステムの場合はosd-compute-18が作成されました。

注：json形式に注意してください。

[stack@director ~]$ cat add_node.json

{

"nodes":[

{

"mac":[

"<MAC_ADDRESS>"

],

"capabilities": "node:osd-compute-3,boot_option:local",

"cpu":"24",

"memory":"256000",

"disk":"3000",

"arch":"x86_64",

"pm_type":"pxe_ipmitool",

"pm_user":"admin",

"pm_password":"<PASSWORD>",

"pm_addr":"192.100.0.5"

}

]

}

- jsonファイルをインポートします。

[stack@director ~]$ openstack baremetal import --json add_node.json

Started Mistral Workflow. Execution ID: 78f3b22c-5c11-4d08-a00f-8553b09f497d

Successfully registered node UUID 7eddfa87-6ae6-4308-b1d2-78c98689a56e

Started Mistral Workflow. Execution ID: 33a68c16-c6fd-4f2a-9df9-926545f2127e

Successfully set all nodes to available.

- 前のステップでメモしたUUIDを使用して、ノードイントロスペクションを実行します。

[stack@director ~]$ openstack baremetal node manage 7eddfa87-6ae6-4308-b1d2-78c98689a56e

[stack@director ~]$ ironic node-list |grep 7eddfa87

| 7eddfa87-6ae6-4308-b1d2-78c98689a56e | None | None                                 | power off   | manageable         | False       |

[stack@director ~]$ openstack overcloud node introspect 7eddfa87-6ae6-4308-b1d2-78c98689a56e --provide

Started Mistral Workflow. Execution ID: e320298a-6562-42e3-8ba6-5ce6d8524e5c

Waiting for introspection to finish...

Successfully introspected all nodes.

Introspection completed.

Started Mistral Workflow. Execution ID: c4a90d7b-ebf2-4fcb-96bf-e3168aa69dc9

Successfully set all nodes to available.

[stack@director ~]$ ironic node-list |grep available

| 7eddfa87-6ae6-4308-b1d2-78c98689a56e | None | None                                 | power off   | available          | False       |

- IPアドレスをcustom-templates/layout.ymlのOsd Compute IPsに追加します。この場合、osd-compute-0を置き換えて、各タイプのリストの最後にそのアドレスを追加します

OsdComputeIP:

internal_api:

- 11.120.0.43

- 11.120.0.44

- 11.120.0.45

- 11.120.0.43   <<< take osd-compute-0 .43 and add here

tenant:

- 11.117.0.43

- 11.117.0.44

- 11.117.0.45

- 11.117.0.43   << and here

storage:

- 11.118.0.43

- 11.118.0.44

- 11.118.0.45

- 11.118.0.43   << and here

storage_mgmt:

- 11.119.0.43

- 11.119.0.44

- 11.119.0.45

- 11.119.0.43   << and here

- 新しいコンピュートノードをオーバークラウドスタックに追加するには、スタックの展開に以前に使用したdeploy.shスクリプトを実行します。
[stack@director ~]$ ./deploy.sh

++ openstack overcloud deploy --templates -r /home/stack/custom-templates/custom-roles.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml --stack ADN-ultram --debug --log-file overcloudDeploy_11_06_17__16_39_26.log --ntp-server 172.24.167.109 --neutron-flat-networks phys_pcie1_0,phys_pcie1_1,phys_pcie4_0,phys_pcie4_1 --neutron-network-vlan-ranges datacentre:1001:1050 --neutron-disable-tunneling --verbose --timeout 180

…

Starting new HTTP connection (1): 192.200.0.1

"POST /v2/action_executions HTTP/1.1" 201 1695

HTTP POST http://192.200.0.1:8989/v2/action_executions 201

Overcloud Endpoint: http://10.1.2.5:5000/v2.0

Overcloud Deployed

clean_up DeployOvercloud:

END return value: 0

real   38m38.971s

user   0m3.605s

sys    0m0.466s

- openstackスタックのステータスが[Complete]になるまで待ちます。

[stack@director ~]$  openstack stack list

+--------------------------------------+------------+-----------------+----------------------+----------------------+

| ID                                   | Stack Name | Stack Status    | Creation Time        | Updated Time         |

+--------------------------------------+------------+-----------------+----------------------+----------------------+

| 5df68458-095d-43bd-a8c4-033e68ba79a0 | ADN-ultram | UPDATE_COMPLETE | 2017-11-02T21:30:06Z | 2017-11-06T21:40:58Z |

+--------------------------------------+------------+-----------------+----------------------+----------------------+

- 新しいコンピュートノードがアクティブ状態であることを確認します。

[stack@director ~]$ source stackrc

[stack@director ~]$ nova list |grep osd-compute-3

| 0f2d88cd-d2b9-4f28-b2ca-13e305ad49ea | pod1-osd-compute-3    | ACTIVE | -          | Running     | ctlplane=192.200.0.117 |

[stack@director ~]$ source corerc

[stack@director ~]$ openstack hypervisor list |grep osd-compute-3

| 63 | pod1-osd-compute-3.localdomain    |

- 新しいosd-compute serverにログインし、cephプロセスを確認します。最初は、cephが回復したため、ステータスはHEALTH_WARNです。

- [heat-admin@pod1-osd-compute-3 ~]$ sudo ceph -s

cluster eb2bb192-b1c9-11e6-9205-525400330666

health HEALTH_WARN

223 pgs backfill_wait

4 pgs backfilling

41 pgs degraded

227 pgs stuck unclean

41 pgs undersized

recovery 45229/1300136 objects degraded (3.479%)

recovery 525016/1300136 objects misplaced (40.382%)

monmap e1: 3 mons at {Pod1-controller-0=11.118.0.40:6789/0,Pod1-controller-1=11.118.0.41:6789/0,Pod1-controller-2=11.118.0.42:6789/0}

election epoch 58, quorum 0,1,2 Pod1-controller-0,Pod1-controller-1,Pod1-controller-2

osdmap e986: 12 osds: 12 up, 12 in; 225 remapped pgs

flags sortbitwise,require_jewel_osds

pgmap v781746: 704 pgs, 6 pools, 533 GB data, 344 kobjects

1553 GB used, 11840 GB / 13393 GB avail

45229/1300136 objects degraded (3.479%)

525016/1300136 objects misplaced (40.382%)

477 active+clean

186 active+remapped+wait_backfill

37 active+undersized+degraded+remapped+wait_backfill

4 active+undersized+degraded+remapped+backfilling

- ただし、短時間（20分）の後、CEPHはHEALTH_OK状態に戻ります。

[heat-admin@pod1-osd-compute-3 ~]$ sudo ceph -s

cluster eb2bb192-b1c9-11e6-9205-525400330666

health HEALTH_OK

monmap e1: 3 mons at {Pod1-controller-0=11.118.0.40:6789/0,Pod1-controller-1=11.118.0.41:6789/0,Pod1-controller-2=11.118.0.42:6789/0}

election epoch 58, quorum 0,1,2 Pod1-controller-0,Pod1-controller-1,Pod1-controller-2

osdmap e1398: 12 osds: 12 up, 12 in

flags sortbitwise,require_jewel_osds

pgmap v784311: 704 pgs, 6 pools, 533 GB data, 344 kobjects

1599 GB used, 11793 GB / 13393 GB avail

704 active+clean

client io 8168 kB/s wr, 0 op/s rd, 32 op/s wr

[heat-admin@pod1-osd-compute-3 ~]$ sudo ceph osd tree

ID WEIGHT   TYPE NAME                         UP/DOWN REWEIGHT PRIMARY-AFFINITY

-1 13.07996 root default

-2        0     host pod1-osd-compute-0

-3  4.35999     host pod1-osd-compute-2

1  1.09000         osd.1                          up  1.00000          1.00000

4  1.09000         osd.4                          up  1.00000          1.00000

7  1.09000         osd.7                          up  1.00000          1.00000

10  1.09000         osd.10                         up  1.00000          1.00000

-4  4.35999     host pod1-osd-compute-1

2  1.09000         osd.2                          up  1.00000          1.00000

5  1.09000         osd.5                          up  1.00000          1.00000

8  1.09000         osd.8                          up  1.00000          1.00000

11  1.09000         osd.11                         up  1.00000          1.00000

-5  4.35999     host pod1-osd-compute-3

0  1.09000         osd.0                          up  1.00000          1.00000

3  1.09000         osd.3                          up  1.00000          1.00000

6  1.09000         osd.6                          up  1.00000          1.00000

9  1.09000         osd.9                          up  1.00000          1.00000

VMの復元

スナップショットによるインスタンスのリカバリ

前のステップで実行したスナップショットを使用して、前のインスタンスを再展開できます。

ステップ1:（オプション）使用可能な以前のVMスナップショットがない場合は、バックアップが送信されたOSPDノードに接続し、バックアップを元のOSPDノードにSFTPして戻します。sftp root@x.x.x.xwhere x.x.x.xは元のOSPDのIPです。スナップショットファイルを/tmpディレクトリに保存します。

ステップ2：インスタンスが再配置されるOSPDノードに接続します。

次のコマンドを使用して、環境変数をソース化します。

# source /home/stack/pod1-stackrc-Core-CPAR

ステップ3：スナップショットをイメージとして使用するには、必要に応じて地平線にアップロードする必要があります。次のコマンドを実行して、実行します。

#glance image-create -- AAA-CPAR-Date-snapshot.qcow2 --container-format bare --disk-format qcow2 --name AAA-CPAR-Date-snapshot

このプロセスは、次の図に示すように水平線で確認できます。

ステップ4：次の図に示すように、[Horizon]で[Project] > [インスタンス]に移動し、[インスタンスをロード]をクリックします。

ステップ5：インスタンス名を入力し、次の図に示す[Availability Zone]を選択します。

ステップ6:[Source]タブでイメージを選択して、インスタンスを作成します。[ブートソースの選択]メニューでイメージを選択して、イメージのリストを表示して、+記号をクリックしてアップロードしたイメージを選択します。次の図を参照してください。

ステップ7:[Flavor]タブで、次の図に示すように+記号をクリックしてAAAフレーバーを選択します。

ステップ8：最後に、[Network]タブに移動し、+記号をクリックしてインスタンスに必要なネットワークを選択します。この場合は、次の図に示すように、diameter-soutable1、radius-routable1、およびtb1-mgmtを選択します。

ステップ9：最後に、[Launch Instance]をクリックして作成します。次の図に示すように、Horizonで進行状況を監視できます。

数分後に、インスタンスが完全に導入され、使用可能な状態になります。

フローティング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クライアントを開き、インスタンスに割り当てられたフローティングIP(10.145.0.249)とユーザrootを使用してリモート安全接続ををを確立します。

SSHセッションの確立

ステップ1：次の図に示すように、アプリケーションがインストールされている対応するVM/サーバのIPアドレスでSSHセッションを開きます。

CPARインスタンス開始

アクティビティが完了し、シャットダウンされたサイトでCPARサービスを再確立できたら、次の手順に従います。

ステップ1：ホライズンにログインし、[プロジェクト] > [インスタンス] > [インスタンスの開始]に移動します。

ステップ2：次の図に示すように、インスタンスのステータスがActiveで、電源状態が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：コマンド/opt/CSCOar/bin/aregcmdをOSレベルで実行し、管理者クレデンシャルを入力します。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.2(100TPS:)

PAR-ADD-TPS 7.2(2000TPS:)

PAR-RDDR-TRX 7.2()

PAR-HSS 7.2()

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: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より小さい必要があります。