サーバUCS C240 M4の障害のあるコンポーネントの交換

ダウンロードオプション

PDF (3.6 MB)
Adobe Reader を使ってさまざまなデバイスで表示
ePub (3.3 MB)
iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
Mobi (Kindle) (2.7 MB)
Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示

Updated: 2018 年 9 月 6 日

Document ID:213663

偏向のない言語

この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージの取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポートコンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

内容

概要

背景説明

省略形

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時間）

PODのOpenstackのHorizon GUIにログインします。
ログインしたら、トップメニューの[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に転送できます。

グレースフルパワーオフ

ノードの電源オフ

インスタンスの電源をオフにするには、次の手順を実行します。nova stop <INSTANCE_NAME>
インスタンス名は、ステータスシャットオフで確認できます。

[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時間）

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

ログインしたら、トップメニューの[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ディスクにアクセスできる必要があります。

グレースフルパワーオフ

ノードの電源オフ

インスタンスの電源をオフにするには、次の手順を実行します。nova stop <INSTANCE_NAME>

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

[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