内容

概要

背景説明

省略形

MoPのワークフロー

前提条件

バックアップ

コンポーネントRMA – コンピュートノード

コンピューティングノードでホストされるVMの特定

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

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

VMスナップショット

グレースフルパワーオフ

コンピューティングノードからの障害コンポーネントの交換

VMの復元

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

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

SSH の有効化

SSHセッションの確立

コンポーネントRMA - OSDコンピュートノード

OSDコンピューティングノードでホストされるVMの特定

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

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

VMスナップショット

CEPHをメンテナンスモードにする

グレースフルパワーオフ

OSDコンピュートノードの障害コンポーネントの交換

CEPHをメンテナンスモードから移動

VMの復元

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

コンポーネントRMA – コントローラノード

事前確認

コントローラクラスタをメンテナンスモードに移動

コントローラノードからの障害のあるコンポーネントの交換

サーバの電源オン

概要

このドキュメントでは、Ultra-MセットアップでUnified Computing System(UCS)サーバに記載されている障害のあるコンポーネントを交換するために必要な手順について説明します。

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

- デュアルインラインメモリモジュール(DIMM)交換MOP

- FlexFlashコントローラの障害

- ソリッドステートドライブ(SSD)の障害

- トラステッドプラットフォームモジュール(TPM)の障害

- Raidキャッシュ障害

- RAIDコントローラ/ホットバスアダプタ(HBA)の障害

- PCIライザーの障害

- PCIeアダプタIntel X520 10G障害

- モジュラLAN-on Motherboard(MLOM)障害

- ファントレイRMA

- CPU障害

背景説明

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

- 計算

- オブジェクトストレージディスク – コンピューティング（OSD – コンピューティング）

- コントローラ

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

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

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

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

省略形

MOP

手続きの方法

OSD

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

OSPD

OpenStack Platform Director

HDD

ハードディスクドライブ

SSD

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

VIM

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

VM

仮想マシン

EM

エレメント マネージャ

UAS

Ultra Automation Services

UUID

汎用一意識別子

MoPのワークフロー

前提条件

バックアップ

障害のあるコンポーネントを交換する前に、Red Hat OpenStack Platform環境の現在の状態を確認することが重要です。交換プロセスがオンのときに複雑さを回避するために、現在の状態を確認することをお勧めします。この交換フローによって実現できます。

リカバリの場合は、次の手順を使用して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

このプロセスにより、インスタンスの可用性に影響を与えることなく、ノードを確実に交換できます。また、交換するコンピューティング/OSDコンピューティングノードがControl Function(CF)仮想マシン(VM)をホストする場合は、特にStarOSの設定をバックアップすることをお勧めします。

注：サーバがコントローラノードの場合は、セクション「」に進み、それ以外の場合は次のセクションに進みます。必要に応じてVMをリストアできるように、インスタンスのスナップショットがあることを確認します。VMのスナップショットを作成する手順に従います。

コンポーネントRMA – コンピュートノード

コンピューティングノードでホストされるVMの特定

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

[stack@al03-pod2-ospd ~]$ nova list --field name,host

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

| ID                                   | Name                      | Host                             |

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

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

| 3bc14173-876b-4d56-88e7-b890d67a4122 | aaa2-21                   | pod2-stack-compute-3.localdomain |

| f404f6ad-34c8-4a5f-a757-14c8ed7fa30e | aaa21june                 | pod2-stack-compute-3.localdomain |

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

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

バックアップ:スナップショットプロセス

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

ステップ1:TMO実稼働ネットワークに接続されているすべての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

2. 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ディレクトリに配置されます。

- プロセスをバックグラウンドに送信すると（たとえば、TCPポートがTCPポートを介して）、接続が失われた場合、プロセスも停止します。

- 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 sftproot@x.x.x.xを使用して一時的に別のサイトのOSPDに転送することです。x.x.x.xはリモートOSPDのIPです。転送を高速化するために、宛先を複数のOSPDに送信できます。同様に、scp *name_of_the_file*.qcow2 root@ x.x.x.x:/tmp （x.x.x.xはリモートOSPDのIP）コマンドを実行して、ファイルを別のOSPDに転送できます。

グレースフルパワーオフ

- ノードの電源オフ

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                 |

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

コンピューティングノードからの障害コンポーネントの交換

指定したサーバの電源をオフにします。UCS C240 M4サーバで障害のあるコンポーネントを交換する手順は、次のURLから参照できます。

サーバコンポーネントの交換

VMの復元

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

リカバリプロセス

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

ステップ1:[オプション]使用可能な以前のVMsnapshotがない場合は、バックアップが送信されたOSPDノードに接続し、バックアップを元のOSPDノードにSFTPして戻します。sftproot@x.x.x.x(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] > [Instances]に移動し、[Launch Instance]をクリックします。

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

ステップ6:[Source]タブで、インスタンスを作成するイメージを選択します。[ブートソースの選択]メニューでイメージを選択します。イメージのリストが表示され、前にアップロードしたイメージのリストをクリックして選択しますが+記号と、次の図のとおりです。

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

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

最後に、[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:Horizonにログインし、[Project] > [インスタンス] > [Start Instance]に移動します

ステップ2：インスタンスのステータスがアクティブで、この図に示すように電源の状態が実行中であることを確認します。

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

ステップ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.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より小さい必要があります。

コンポーネントRMA - OSDコンピュートノード

OSDコンピューティングノードでホストされるVMの特定

OSD-Computeサーバでホストされている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が存在するホスト名です。この出力のパラメータは、以降のセクションで使用します。

バックアップ:スナップショットプロセス

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

ステップ1:TMO実稼働ネットワークに接続されているすべての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

2. 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]メニューに移動し、[all finish]を確認し、このイメージに示すような問題が発生していないことを確認します。

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ディレクトリに配置されます。

- プロセスをバックグラウンドに送信すると（たとえば、TCPポートがTCPポートを介して）、接続が失われた場合、プロセスも停止します。

- 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 -khinを実行してメモリ領域を確認します。アドバイスの1つは、SFTP sftproot@x.x.x.xを使用して一時的に別のサイトのOSPDに転送することです。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に転送できます。

CEPHをメンテナンスモードにする

注：障害のあるコンポーネントをOSD-Computeノードで交換する場合は、コンポーネントの交換に進む前にCephをサーバのメンテナンスに入れてください。

- ceph 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

- OSDコンピュートノードにログインし、CEPHをメンテナンスモードにします。

[root@pod2-stack-osd-compute-0 ~]# sudo ceph osd set norebalance

[root@pod2-stack-osd-compute-0 ~]# sudo ceph osd set noout

[root@pod2-stack-osd-compute-0 ~]# sudo ceph status

cluster eb2bb192-b1c9-11e6-9205-525400330666

health HEALTH_WARN

noout,norebalance,sortbitwise,require_jewel_osds flag(s) set

monmap e1: 3 mons at {pod2-stack-controller-0=11.118.0.10:6789/0,pod2-stack-controller-1=11.118.0.11:6789/0,pod2-stack-controller-2=11.118.0.12:6789/0}

election epoch 10, quorum 0,1,2 pod2-stack-controller-0,pod2-stack-controller-1,pod2-stack-controller-2

osdmap e79: 12 osds: 12 up, 12 in

flags noout,norebalance,sortbitwise,require_jewel_osds

pgmap v22844323: 704 pgs, 6 pools, 804 GB data, 423 kobjects

2404 GB used, 10989 GB / 13393 GB avail

704 active+clean

client io 3858 kB/s wr, 0 op/s rd, 546 op/s wr

注：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                 |

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

OSDコンピュートノードの障害コンポーネントの交換

指定したサーバの電源をオフにします。UCS C240 M4サーバで障害のあるコンポーネントを交換する手順は、次のURLから参照できます。

サーバコンポーネントの交換

CEPHをメンテナンスモードから移動

- OSDコンピュートノードにログインし、CEPHをメンテナンスモードから外します。

[root@pod2-stack-osd-compute-0 ~]# sudo ceph osd unset norebalance

[root@pod2-stack-osd-compute-0 ~]# sudo ceph osd unset noout

[root@pod2-stack-osd-compute-0 ~]# sudo ceph status

cluster eb2bb192-b1c9-11e6-9205-525400330666

health HEALTH_OK

monmap e1: 3 mons at {pod2-stack-controller-0=11.118.0.10:6789/0,pod2-stack-controller-1=11.118.0.11:6789/0,pod2-stack-controller-2=11.118.0.12:6789/0}

election epoch 10, quorum 0,1,2 pod2-stack-controller-0,pod2-stack-controller-1,pod2-stack-controller-2

osdmap e81: 12 osds: 12 up, 12 in

flags sortbitwise,require_jewel_osds

pgmap v22844355: 704 pgs, 6 pools, 804 GB data, 423 kobjects

2404 GB used, 10989 GB / 13393 GB avail

704 active+clean

client io 3658 kB/s wr, 0 op/s rd, 502 op/s wr

VMの復元

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

リカバリプロセス

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

ステップ1:[オプション]使用可能な以前のVMsnapshotがない場合は、バックアップが送信されたOSPDノードに接続し、バックアップを元のOSPDノードにsftpして戻します。sftproot@x.x.x.xを使用します。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]タブで、インスタンスを作成するイメージを選択します。[Select Boot Source]メニューで[Image]を選択すると、イメージのリストが表示され、+記号をクリックしてアップロードしたイメージを選択します。

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

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

最後に、[インスタンスの起動]をクリックして作成します。進行状況は、次のHorizonで監視できます。

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

フローティングIPアドレスを作成して割り当てる

フローティングIPアドレスは、ルーティング可能なアドレスです。つまり、Ultra M/Openstackアーキテクチャの外部から到達可能であり、ネットワークの他のノードと通信できます。

ステップ1:[Horizon]トップメニューで、[Admin] > [Floating IPs]に移動します。

ステップ2:[Allocate IP to Project]をクリックします。

ステップ3:[Allocate Floating IP]ウィンドウで、新しいフローティングIPが属するプール、割り当て先のプロジェクト、新しいフローティングIPアドレスを選択します。

以下に、いくつかの例を示します。

ステップ4:[Allocate Floating IP]をクリックします。

ステップ5:[Horizon]トップメニューで、[Project] > [Instances]に移動します。

ステップ6:[Action]列で[Create Snapshot]ボタンをポイントする矢印をクリックすると、メニューが表示されます。[Associate Floating IP]オプションを選択します。

ステップ7:[IP Address]フィールドで使用する対応するフローティングIPアドレスを選択し、関連付けるポートでこのフローティングIPが割り当てられる新しいインスタンスから対応する管理インターフェイス(eth0)を選択します。

ステップ8：最後に、[Associate]をクリックします。

SSH の有効化

ステップ1:[Horizon]トップメニューで、[Project] > [Instances]に移動します。

ステップ2:「新規インスタンスの起動」セクションで作成したインスタンス/VMの名前をクリックします。

ステップ3:[Console]タブをクリックします。これにより、VMのコマンドラインインターフェイスが表示されます。

ステップ4:CLIが表示されたら、次の図に示すように適切なログインクレデンシャルを入力します。

ユーザ名：root

パスワード：cisco123

ステップ5:CLIでコマンドvi /etc/ssh/sshd_configを実行して、ssh設定を編集します。

ステップ6: ssh設定ファイルが開いたら、Iを押してファイルを編集します。次に、このセクションを探し、最初の行をPasswordAuthentication noからPasswordAuthentication yesに変更します。

ステップ7: Escキーを押して:wq!tと入力し、sshd_configファイルの変更を保存します。

ステップ8：コマンドservice sshd restartを実行します。

ステップ9:SSH設定の変更が正しく適用されたことをテストするために、任意のSSHクライアントを開き、インスタンスに割り当てられたフローティングIP(10.145.0.249)とユーザrootを使用してリモートセキュア接続を確立します。

SSHセッションの確立

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

CPARインスタンスの開始

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

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

ステップ2：インスタンスのステータスがアクティブで、電源の状態が実行中であることを、図に示すように確認します。

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

ステップ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.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より小さい必要があります。

コンポーネントRMA – コントローラノード

事前確認

- OSPDからコントローラにログインし、pcが正常な状態であることを確認します。3つのコントローラすべてがオンラインとGaleraに3つすべてのコントローラがマスターとして表示されます。

注：正常なクラスタには2つのアクティブコントローラが必要です。残りの2つのコントローラがオンラインとアクティブであることを確認してください。

[heat-admin@pod2-stack-controller-0 ~]$ sudo pcs status

Cluster name: tripleo_cluster

Stack: corosync

Current DC: pod2-stack-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum

Last updated: Fri Jul 6 09:03:37 2018Last change: Fri Jul 6 09:03:35 2018 by root via crm_attribute on pod2-stack-controller-0

3 nodes and 19 resources configured

Online: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]

Full list of resources:

ip-11.120.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1

Clone Set: haproxy-clone [haproxy]

Started: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]

Master/Slave Set: galera-master [galera]

Masters: [ pod2-stack-controller-1 pod2-stack-controller-2 ]

Slaves: [ pod2-stack-controller-0 ]

ip-192.200.0.110(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1

ip-11.120.0.44(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2

ip-11.118.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2

Clone Set: rabbitmq-clone [rabbitmq]

Started: [ pod2-stack-controller-1 pod2-stack-controller-2 ]

Stopped: [ pod2-stack-controller-0 ]

ip-10.225.247.214(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1

Master/Slave Set: redis-master [redis]

Masters: [ pod2-stack-controller-2 ]

Slaves: [ pod2-stack-controller-0 pod2-stack-controller-1 ]

ip-11.119.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2

openstack-cinder-volume(systemd:openstack-cinder-volume):Started pod2-stack-controller-1

Daemon Status:

corosync: active/enabled

pacemaker: active/enabled

pcsd: active/enabled

コントローラクラスタをメンテナンスモードに移動

- スタンバイで更新されるコントローラ上でpcクラスタを実行します。

[heat-admin@pod2-stack-controller-0 ~]$ sudo pcs cluster standby

- pcのステータスを再度確認し、このノードでpcクラスタが停止していることを確認します。

[heat-admin@pod2-stack-controller-0 ~]$ sudo pcs status

Cluster name: tripleo_cluster

Stack: corosync

Current DC: pod2-stack-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum

Last updated: Fri Jul 6 09:03:10 2018Last change: Fri Jul 6 09:03:06 2018 by root via crm_attribute on pod2-stack-controller-0

3 nodes and 19 resources configured

Node pod2-stack-controller-0: standby

Online: [ pod2-stack-controller-1 pod2-stack-controller-2 ]

Full list of resources:

ip-11.120.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1

Clone Set: haproxy-clone [haproxy]

Started: [ pod2-stack-controller-1 pod2-stack-controller-2 ]

Stopped: [ pod2-stack-controller-0 ]

Master/Slave Set: galera-master [galera]

Masters: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]

ip-192.200.0.110(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1

ip-11.120.0.44(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2

ip-11.118.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2

Clone Set: rabbitmq-clone [rabbitmq]

Started: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]

ip-10.225.247.214(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1

Master/Slave Set: redis-master [redis]

Masters: [ pod2-stack-controller-2 ]

Slaves: [ pod2-stack-controller-1 ]

Stopped: [ pod2-stack-controller-0 ]

ip-11.119.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2

openstack-cinder-volume(systemd:openstack-cinder-volume):Started pod2-stack-controller-1

Daemon Status:

corosync: active/enabled

pacemaker: active/enabled

pcsd: active/enabled

また、他の2つのコントローラのpcステータスは、ノードをスタンバイとして表示する必要があります。

コントローラノードからの障害のあるコンポーネントの交換

指定したサーバの電源をオフにします。UCS C240 M4サーバで障害のあるコンポーネントを交換する手順は、次のURLから参照できます。

サーバコンポーネントの交換

サーバの電源オン

- サーバの電源を入れ、サーバが起動することを確認します。

[stack@director ~]$ source stackrc

[stack@director ~]$ nova list

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

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

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

| 03f15071-21aa-4bcf-8fdd-acdbde305168 | pod2-stack-compute-0 | ACTIVE | - | Running | ctlplane=192.200.0.106 |

| 1f725ce3-948d-49e9-aed9-b99e73d82644 | pod2-stack-compute-1 | ACTIVE | - | Running | ctlplane=192.200.0.107 |

| fbc13c78-dc06-4ac9-a3c5-595ccc147adc | pod2-stack-compute-2 | ACTIVE | - | Running | ctlplane=192.200.0.119 |

| 3b94e0b1-47dc-4960-b3eb-d02ffe9ae693 | pod2-stack-compute-3 | ACTIVE | - | Running | ctlplane=192.200.0.112 |

| 5dbac94d-19b9-493e-a366-1e2e2e5e34c5 | pod2-stack-compute-4 | ACTIVE | - | Running | ctlplane=192.200.0.116 |

| b896c73f-d2c8-439c-bc02-7b0a2526dd70 | pod2-stack-controller-0 | ACTIVE | - | Running | ctlplane=192.200.0.113 |

| 2519ce67-d836-4e5f-a672-1a915df75c7c | pod2-stack-controller-1 | ACTIVE | - | Running | ctlplane=192.200.0.105 |

| e19b9625-5635-4a52-a369-44310f3e6a21 | pod2-stack-controller-2 | ACTIVE | - | Running | ctlplane=192.200.0.120 |

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

| 26d3f7b1-ba97-431f-aa6e-ba91661db45d | pod2-stack-osd-compute-1 | ACTIVE | - | Running | ctlplane=192.200.0.117 |

| 6e4a8aa9-4870-465a-a7e2-0932ff55e34b | pod2-stack-osd-compute-2 | ACTIVE | - | Running | ctlplane=192.200.0.103 |

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

- 該当のコントローラにログインし、unstandbyを使用してスタンバイモードを削除します。コントローラがクラスタでオンラインになり、Galeraが3つすべてのコントローラをマスターとして表示することを確認します。これには数分かかることがあります。

[heat-admin@pod2-stack-controller-0 ~]$ sudo pcs cluster unstandby

[heat-admin@pod2-stack-controller-0 ~]$ sudo pcs status

Cluster name: tripleo_cluster

Stack: corosync

Current DC: pod2-stack-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum

Last updated: Fri Jul 6 09:03:37 2018Last change: Fri Jul 6 09:03:35 2018 by root via crm_attribute on pod2-stack-controller-0

3 nodes and 19 resources configured

Online: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]

Full list of resources:

ip-11.120.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1

Clone Set: haproxy-clone [haproxy]

Started: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]

Master/Slave Set: galera-master [galera]

Masters: [ pod2-stack-controller-1 pod2-stack-controller-2 ]

Slaves: [ pod2-stack-controller-0 ]

ip-192.200.0.110(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1

ip-11.120.0.44(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2

ip-11.118.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2

Clone Set: rabbitmq-clone [rabbitmq]

Started: [ pod2-stack-controller-1 pod2-stack-controller-2 ]

Stopped: [ pod2-stack-controller-0 ]

ip-10.225.247.214(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1

Master/Slave Set: redis-master [redis]

Masters: [ pod2-stack-controller-2 ]

Slaves: [ pod2-stack-controller-0 pod2-stack-controller-1 ]

ip-11.119.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2

openstack-cinder-volume(systemd:openstack-cinder-volume):Started pod2-stack-controller-1

Daemon Status:

corosync: active/enabled

pacemaker: active/enabled

pcsd: active/enabled

- cephなどのモニタサービスの一部が正常な状態であることを確認できます。

[heat-admin@pod2-stack-controller-0 ~]$ sudo ceph -s

cluster eb2bb192-b1c9-11e6-9205-525400330666

health HEALTH_OK

monmap e1: 3 mons at {pod2-stack-controller-0=11.118.0.10:6789/0,pod2-stack-controller-1=11.118.0.11:6789/0,pod2-stack-controller-2=11.118.0.12:6789/0}

election epoch 10, quorum 0,1,2 pod2-stack-controller-0,pod2-stack-controller-1,pod2-stack-controller-2

osdmap e81: 12 osds: 12 up, 12 in

flags sortbitwise,require_jewel_osds

pgmap v22844355: 704 pgs, 6 pools, 804 GB data, 423 kobjects

2404 GB used, 10989 GB / 13393 GB avail

704 active+clean

client io 3658 kB/s wr, 0 op/s rd, 502 op/s wr