内容

概要

背景説明

省略形

コンポーネントRMAのトラブルシューティング：コンピューティング/OSDコンピューティングノード

ステップ1：グレースフルシャットダウン

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

Cluster Manager VMのグレースフルシャットダウンの場合

アクティブなPD/ロードバランサVMのグレースフルシャットダウン

スタンバイPD/ロードバランサVMのグレースフルシャットダウン

PS/QNS VMグレースフルシャットダウンの場合

OAM/pcrfclient VMグレースフルシャットダウンの場合

アービターVMの場合

ステップ2:ESCデータベースバックアップ。

ステップ3:ESCをスタンバイモードに移行する。

ステップ4：コンピューティング/OSDコンピュートノードの障害コンポーネントを交換します。

ステップ5:VMをリストアします。

ESCからのVMリカバリ

ESC VMのリカバリ

ESC回復障害の処理

コンポーネントRMAのトラブルシューティング：コントローラノード

ステップ1：コントローラ – プレチェック

ステップ2：コントローラクラスタをメンテナンスモードに移動します。

ステップ3：コントローラノードから障害のあるコンポーネントを交換します。

ステップ4：サーバの電源をオンにします。

概要

このドキュメントでは、Cisco Policy Suite(CPS)仮想ネットワーク機能(VNF)をホストするUltra-MセットアップのCisco Unified Computing System(UCS)サーバで説明されている障害のあるコンポーネントを交換するために必要な手順について説明します。

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

- FlexFlashコントローラの障害

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

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

- Raidキャッシュ障害

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

- PCIライザーの障害

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

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

- ファントレイRMA

- CPU障害

著者：Cisco Advance Services、Nitesh Bansal

背景説明

Ultra-Mは、VNFの導入を簡素化するように設計された、パッケージ化および検証済みの仮想化ソリューションです。OpenStackは、Ultra-Mの仮想化インフラストラクチャマネージャ(VIM)であり、次のノードタイプで構成されています。

- 計算

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

- コントローラ

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

- Ultra M 5.1.xリリースは、このドキュメントの手順を定義するために考慮されています。

- このドキュメントは、Cisco Ultra-Mプラットフォームに精通したシスコ担当者を対象としており、サーバのコンポーネント交換時にOpenStackおよびCPS VNFレベルで実行する必要がある手順の詳細を説明しています。

障害のあるコンポーネントを交換する前に、Red Hat Open Stackプラットフォーム環境の現在のステータスを確認することが重要です。交換プロセスがオンのときに複雑さを回避するために、現在の状態を確認することをお勧めします。

回復時には、次の手順を使用して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

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

注：サーバがコントローラノードの場合は、のセクションに進んでください。そうしないと、次のセクションに進んでください。

省略形

VNF

仮想ネットワーク機能

PD

Policy Director（ロードバランサ）

PS

ポリシーサーバ( pcrfclient )

ESC

Elastic Service Controller

MOP

手続きの方法

OSD

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

HDD

ハードディスクドライブ

SSD

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

VIM

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

VM

仮想マシン

SM

セッションマネージャ

QNS

Quantumネームサーバ

UUID

ユニバーサル一意IDentifier

コンポーネントRMAのトラブルシューティング：コンピューティング/OSDコンピューティングノード

ステップ1：グレースフルシャットダウン

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

コンピューティング/OSD-Computeは、複数のタイプのVMをホストできます。すべてを特定し、特定のベアメタルノードとこのコンピューティングでホストされている特定のVM名に関する個々の手順に進みます。

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

| 49ac5f22-469e-4b84-badc-031083db0533 |  SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634     |

pod1-compute-10.localdomain    |

| 49ac5f22-469e-4b84-badc-031083db0533 |  SVS1-tmo_sm-s3_0_05966301-bd95-4071-817a-0af43757fc88     |

pod1-compute-10.localdomain    |

Cluster Manager VMのグレースフルシャットダウンの場合

ステップ1：スナップショットを作成し、サーバの外部の他の場所、または可能であればラックの外部にファイルをFTPします。

openstack image create --poll

ステップ2:ESCからVMを停止します。

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < CM vm-name>

ステップ3:VMが停止しているかどうかを確認します。

[admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"

<snip>

<state>SERVICE_ACTIVE_STATE</state>

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634

VM_SHUTOFF_STATE

アクティブなPD/ロードバランサVMのグレースフルシャットダウン

ステップ1：アクティブlbにログインし、次のようにサービスを停止します

- lbをアクティブからスタンバイに切り替える

service corosync restart

- スタンバイlbでサービスを停止

service monit stop

service qns stop

手順 2.ESCマスターから。

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < Standby PD vm-name>

ステップ 3：  VMが停止しているかどうかを確認します。

admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "

|

|

|

"

SERVICE_ACTIVE_STATE

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634                     VM_SHUTOFF_STATE

スタンバイPD/ロードバランサVMのグレースフルシャットダウン

ステップ1：スタンバイlbにログインし、サービスを停止します。

service monit stop

service qns stop

ステップ2:ESCマスターから。

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < Standby PD vm-name>

ステップ3:VMが停止しているかどうかを確認します。

[admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "

|

|

|

"

SERVICE_ACTIVE_STATE

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634                     VM_SHUTOFF_STATE

PS/QNS VMグレースフルシャットダウンの場合

ステップ1：サービスを停止します。

service monit stop

service qns stop

ステップ2: ESCマスターから。

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < PS vm-name>

ステップ 3：  VMが停止しているかどうかを確認します。

[dmin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[dmin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "

|

|

|

"

SERVICE_ACTIVE_STATE

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634                     VM_SHUTOFF_STATE

SM VMグレースフルシャットダウンの場合

ステップ1:sessionmgrに存在するすべてのmongoサービスを停止します。

[root@sessionmg01 ~]# cd /etc/init.d

[root@sessionmg01 init.d]# ls -l sessionmgr*

[root@sessionmg01 ~]# /etc/init.d/sessionmgr-27717 stop Stopping mongod: [  OK  ]

[root@ sessionmg01 ~]# /etc/init.d/sessionmgr-27718 stop Stopping mongod: [  OK  ]

[root@ sessionmg01 ~]# /etc/init.d/sessionmgr-27719 stop Stopping mongod: [  OK  ]

ステップ2:ESCマスターから。

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < PS vm-name>

ステップ3:VMが停止しているかどうかを確認します。

[admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "

|

|

|

"

SERVICE_ACTIVE_STATE

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634                     VM_SHUTOFF_STATE

OAM/pcrfclient VMグレースフルシャットダウンの場合

ステップ1：次のコマンドを使用してポリシーSVNが同期されているかどうかを確認します。値が返された場合、SVNはすでに同期しており、PCRFCLIENT02から同期する必要はありません。必要に応じて、最後のバックアップからの回復をスキップしてください。

/usr/bin/svn propget svn:sync-from-url --revprop -r0 http://pcrfclient01/repos

ステップ2:PCRFCLIENT01で一連のコマンドを実行して、pcrfclient01とpcrfclient02の間のSVNマスター/スレーブ同期をpcrfclient01をマスターとして再確立します。

/bin/rm -fr /var/www/svn/repos

/usr/bin/svnadmin create /var/www/svn/repos

/usr/bin/svn propset --revprop -r0 svn:sync-last-merged-rev 0

http://pcrfclient02/repos-proxy-sync

/usr/bin/svnadmin setuuid /var/www/svn/repos/ "Enter the UUID captured in step 2"

/etc/init.d/vm-init-client

/var/qps/bin/support/recover_svn_sync.sh

ステップ 3：  クラスタマネージャでSVNのバックアップを取ります。

config_br.py -a export --svn /mnt/backup/svn_backup_pcrfclient.tgz

ステップ 4：  pcrfclientのサービスをシャットダウンします。

service monit stop

service qns stop

ステップ 5：  ESCマスターから：

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < pcrfclient vm-name>

手順 6：  VMが停止しているかどうかを確認します。

[admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "

|

|

|

"

SERVICE_ACTIVE_STATE

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634                     VM_SHUTOFF_STATE

アービターVMの場合

ステップ1：アービターにログインし、サービスをシャットダウンします。

[root@SVS1OAM02 init.d]# ls -lrt sessionmgr*

-rwxr-xr-x 1 root root 4382 Jun 21 07:34 sessionmgr-27721

-rwxr-xr-x 1 root root 4406 Jun 21 07:34 sessionmgr-27718

-rwxr-xr-x 1 root root 4407 Jun 21 07:34 sessionmgr-27719

-rwxr-xr-x 1 root root 4429 Jun 21 07:34 sessionmgr-27717

-rwxr-xr-x 1 root root 4248 Jun 21 07:34 sessionmgr-27720

service monit stop

service qns stop

/etc/init.d/sessionmgr-[portno.] stop , where port no is the db port in the arbiter.

ステップ2:ESCマスターから。

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < pcrfclient vm-name>

ステップ3:VMが停止しているかどうかを確認します。

[admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "

|

|

|

"

SERVICE_ACTIVE_STATE

SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634                     VM_SHUTOFF_STATE

Elastic Services Controller(ESC)の場合

ステップ1:ESC-HAの設定は、VNFを使用したスケールアップまたはスケールダウン操作の前/後、およびESCで設定変更の前/後に、毎月バックアップする必要があります。ESCのディザスタリカバリを効果的に実行するには、このバックアップを作成する必要があります

1. [Admin Credentials]および[Export opdata to XML]を使用してESCにログインします。

/opt/cisco/esc/confd/bin/netconf-console --host 127.0.0.1 --port 830 -u

-p

--get-config > /home/admin/ESC_config.xml

2. このファイルを、クラウド外のサーバにftp/sftpのローカルコンピュータにダウンロードします。

ステップ2:PCRFクラウド設定のバックアップ展開XMLで参照されるすべてのスクリプトとユーザデータファイル。

1. 前の手順でエクスポートしたopdataから、すべてのVNFの配備XMLで参照されているすべてのユーザデータファイルを検索します。出力例.

file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-cm_cloud.cfg

file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-oam_cloud.cfg

file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-pd_cloud.cfg

file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-qns_cloud.cfg

file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-sm_cloud.cfg

2. CPSオーケストレーションAPIの送信に使用されるすべての導入後スクリプトを検索します。

3. esc opdataのポスト配置スクリプトのサンプルスニペット。

設定例 1：

PCRF_POST_DEPLOYMENT

LCS::POST_DEPLOY_ALIVE

FINISH_PCRF_INSTALLATION

SCRIPT

----------

script_filename

/opt/cisco/esc/cisco-cps/config/gr/tmo/cfg/../cps_init.py

script_timeout

3600

設定例 2：

PCRF_POST_DEPLOYMENT

LCS::POST_DEPLOY_ALIVE

FINISH_PCRF_INSTALLATION

SCRIPT

CLUMAN_MGMT_ADDRESS

10.174.132.46

CLUMAN_YAML_FILE

/opt/cisco/esc/cisco-cps/config/vpcrf01/ cluman_orch_config.yaml

script_filename

/opt/cisco/esc/cisco-cps/config/vpcrf01/vpcrf_cluman_post_deployment.py

wait_max_timeout

3600

展開ESCのopdata（前の手順で抽出）に強調表示されたファイルが含まれている場合は、バックアップを取ります。

バックアップコマンドの例：

tar –zcf esc_files_backup.tgz /opt/cisco/esc/cisco-cps/config/

このファイルを、クラウド外のサーバにftp/sftpのローカルコンピュータにダウンロードします。

Note:- Although opdata is synced between ESC master and slave, directories containing user-data, xml and post deploy scripts are not synced across both instances. It is suggested that customers can push the contents of directory containing these files using scp or sftp, these files should be constant across ESC-Master and ESC-Standby in order to recover a deployment when ESC VM which was master during deployment is not available do to any unforeseen circumstances.

ステップ2:ESCデータベースバックアップ。

ステップ1：両方のESC VMからログを収集し、バックアップします。

$ collect_esc_log.sh

$ scp /tmp/

@

:

ステップ2：マスターECSノードからデータベースをバックアップします。

ステップ3：ルートユーザに切り替え、プライマリESCのステータスを確認し、出力値がMasterであることを確認します。

$ sudo bash

$ escadm status

Set ESC to maintenance mode & verify

$ sudo escadm op_mode set --mode=maintenance

$ escadm op_mode show

ステップ4：変数を使用してファイル名と日付情報を設定し、バックアップツールを呼び出して、前のステップのファイル名変数を指定します。

fname=esc_db_backup_$(date -u +"%y-%m-%d-%H-%M-%S")

$ sudo /opt/cisco/esc/esc-scripts/esc_dbtool.py backup -- file /tmp/atlpod-esc-master-$fname.tar

ステップ5：バックアップストレージ内のバックアップファイルを確認し、ファイルが存在することを確認します。

ステップ6：マスターESCを通常の動作モードに戻します。

$ sudo escadm op_mode set --mode=operation

dbtoolバックアップユーティリティに障害が発生した場合は、ESCノードで次の回避策を1回適用します。次に、手順6を繰り返します。

$ sudo sed -i "s,'pg_dump,'/usr/pgsql-9.4/bin/pg_dump,"

/opt/cisco/esc/esc-scripts/esc_dbtool.py

ステップ3:ESCをスタンバイモードに移行する。

ステップ1：ノードでホストされているESCにログインし、マスター状態であるかどうかを確認します。存在する場合は、ESCをスタンバイモードに切り替えます。

[admin@VNF2-esc-esc-0 esc-cli]$ escadm status

0 ESC status=0 ESC Master Healthy

[admin@VNF2-esc-esc-0 ~]$ sudo service keepalived stop Stopping keepalived:

[  OK  ]

[admin@VNF2-esc-esc-0 ~]$ escadm status

1 ESC status=0 In SWITCHING_TO_STOP state. Please check status after a while.

[admin@VNF2-esc-esc-0 ~]$ sudo reboot

Broadcast message from admin@vnf1-esc-esc-0.novalocal

(/dev/pts/0) at 13:32 ...

The system is going down for reboot NOW!

ステップ2:VMがESCスタンバイになったら、shutdown -r now

注：障害のあるコンポーネントをOSD-Computeノードで交換する場合は、コンポーネントの交換に進む前に、CEPHをサーバのメンテナンスに移します。

[admin@osd-compute-0 ~]$ sudo ceph osd set norebalance

set norebalance

[admin@osd-compute-0 ~]$ sudo ceph osd set noout

set noout

[admin@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 {tb3-ultram-pod1-controller-0=11.118.0.40:6789/0,tb3-ultram-pod1-controller-1=11.118.0.41:6789/0,tb3-ultram-pod1-controller-2=11.118.0.42:6789/0}

election epoch 58, quorum 0,1,2 tb3-ultram-pod1-controller-0,tb3-ultram-pod1-controller-1,tb3-ultram-pod1-controller-2

osdmap e194: 12 osds: 12 up, 12 in

flags noout,norebalance,sortbitwise,require_jewel_osds

pgmap v584865: 704 pgs, 6 pools, 531 GB data, 344 kobjects

1585 GB used, 11808 GB / 13393 GB avail

704 active+clean

client io 463 kB/s rd, 14903 kB/s wr, 263 op/s rd, 542 op/s wr

ステップ4：コンピューティング/OSDコンピュートノードの障害コンポーネントを交換します。

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

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

次の手順の「永続ロギング」を参照し、必要に応じて実行します

ステップ5:VMをリストアします。

ESCからのVMリカバリ

1. VMはnovaリストでエラー状態になります。

[stack@director  ~]$ nova list |grep VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d

| 49ac5f22-469e-4b84-badc-031083db0533 | VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d     | ERROR  | -          | NOSTATE     |

2. ESCからVMをリカバリします。

[admin@VNF2-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d

[sudo] password for admin:

Recovery VM Action

/opt/cisco/esc/confd/bin/netconf-console --port=830 --host=127.0.0.1 --user=admin --privKeyFile=/root/.ssh/confd_id_dsa --privKeyType=dsa --rpc=/tmp/esc_nc_cli.ZpRCGiieuW

3. モニタ yangesc.log

admin@VNF2-esc-esc-0 ~]$ tail -f /var/log/esc/yangesc.log

…

14:59:50,112 07-Nov-2017 WARN  Type: VM_RECOVERY_COMPLETE

14:59:50,112 07-Nov-2017 WARN  Status: SUCCESS

14:59:50,112 07-Nov-2017 WARN  Status Code: 200

14:59:50,112 07-Nov-2017 WARN  Status Msg: Recovery: Successfully recovered VM [VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d].

4. 起動しているVMのすべてのサービスを確認します。

ESC VMのリカバリ

1. コンソールからESCにログインし、ステータスを確認します。

2. まだ開始していない場合は、プロセスを開始します

[admin@esc ~]$ sudo service keepalived start

[admin@esc ~]$ escadm status 0 ESC status=0 ESC Slave Healthy

ESC回復障害の処理

予期しない状態が原因でESCがVMの起動に失敗する場合は、マスターESCをリブートしてESCスイッチオーバーを実行することを推奨します。ESCスイッチオーバーには約1分かかります。新しいマスターESCでスクリプト「health.sh」を実行し、ステータスがアップであるかどうかを確認します。マスターESCを使用してVMを開始し、VMの状態を修正します。この回復タスクの完了には最大5分かかります。

/var/log/esc/yangesc.logと/var/log/esc/escmanager.logを監視できます。5 ～ 7分後にVMがリカバリされない場合は、影響を受けるVMを手動でリカバリする必要があります。

ESC VMが回復されない場合は、新しいESC VMを導入する手順に従います。手順については、シスコサポートにお問い合わせください。

コンポーネントRMAのトラブルシューティング：コントローラノード

ステップ1：コントローラ – プレチェック

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

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

heat-admin@pod1-controller-0 ~]$ sudo pcs status

Cluster name: tripleo_cluster

Stack: corosync

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

Last updated: Mon Dec  4 00:46:10 2017                        Last change: Wed Nov 29 01:20:52 2017 by hacluster via crmd on pod1-controller-0

3 nodes and 22 resources configured

Online: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

Full list of resources:

ip-11.118.0.42  (ocf::heartbeat:IPaddr2):           Started pod1-controller-1

ip-11.119.0.47  (ocf::heartbeat:IPaddr2):           Started pod1-controller-2

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

ip-192.200.0.102          (ocf::heartbeat:IPaddr2):           Started pod1-controller-2

Clone Set: haproxy-clone [haproxy]

Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

Master/Slave Set: galera-master [galera]

Masters: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

ip-11.120.0.47  (ocf::heartbeat:IPaddr2):           Started pod1-controller-2

Clone Set: rabbitmq-clone [rabbitmq]

Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

Master/Slave Set: redis-master [redis]

Masters: [ pod1-controller-2 ]

Slaves: [ pod1-controller-0 pod1-controller-1 ]

ip-10.84.123.35            (ocf::heartbeat:IPaddr2):           Started pod1-controller-1

openstack-cinder-volume          (systemd:openstack-cinder-volume):            Started pod1-controller-2

my-ipmilan-for-pod1-controller-0        (stonith:fence_ipmilan):  Started pod1-controller-0

my-ipmilan-for-pod1-controller-1        (stonith:fence_ipmilan):  Started pod1-controller-0

my-ipmilan-for-pod1-controller-2        (stonith:fence_ipmilan):  Started pod1-controller-0

Daemon Status:

corosync: active/enabled

pacemaker: active/enabled

pcsd: active/enabled

ステップ2：コントローラクラスタをメンテナンスモードに移動します。

1. アップデート中のコントローラにpcクラスタをスタンバイ状態にします.

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

2. pcのステータスを再度確認し、pcクラスタがこのノードで停止したことを確認します.

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

Cluster name: tripleo_cluster

Stack: corosync

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

Last updated: Mon Dec  4 00:48:24 2017                        Last change: Mon Dec  4 00:48:18 2017 by root via crm_attribute on pod1-controller-0

3 nodes and 22 resources configured

Node pod1-controller-0: standby

Online: [ pod1-controller-1 pod1-controller-2 ]

Full list of resources:

ip-11.118.0.42  (ocf::heartbeat:IPaddr2):           Started pod1-controller-1

ip-11.119.0.47  (ocf::heartbeat:IPaddr2):           Started pod1-controller-2

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

ip-192.200.0.102          (ocf::heartbeat:IPaddr2):           Started pod1-controller-2

Clone Set: haproxy-clone [haproxy]

Started: [ pod1-controller-1 pod1-controller-2 ]

Stopped: [ pod1-controller-0 ]

Master/Slave Set: galera-master [galera]

Masters: [ pod1-controller-1 pod1-controller-2 ]

Slaves: [ pod1-controller-0 ]

ip-11.120.0.47  (ocf::heartbeat:IPaddr2):           Started pod1-controller-2

Clone Set: rabbitmq-clone [rabbitmq]

Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

Master/Slave Set: redis-master [redis]

Masters: [ pod1-controller-2 ]

Slaves: [ pod1-controller-1 ]

Stopped: [ pod1-controller-0 ]

ip-10.84.123.35            (ocf::heartbeat:IPaddr2):           Started pod1-controller-1

openstack-cinder-volume          (systemd:openstack-cinder-volume):            Started pod1-controller-2

my-ipmilan-for-pod1-controller-0        (stonith:fence_ipmilan):  Started pod1-controller-1

my-ipmilan-for-pod1-controller-1        (stonith:fence_ipmilan):  Started pod1-controller-1

my-ipmilan-for-pod1-controller-2        (stonith:fence_ipmilan):  Started pod1-controller-2

Daemon Status:

corosync: active/enabled

pacemaker: active/enabled

pcsd: active/enabled

3. 他の2つのコントローラのpcステータスも、ノードがスタンバイとして表示されます。

ステップ3：コントローラノードから障害のあるコンポーネントを交換します。

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

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

ステップ4：サーバの電源をオンにします。

1. サーバの電源をオンにし、サーバが起動することを確認します。

[stack@tb5-ospd ~]$ source stackrc

[stack@tb5-ospd ~]$ nova list |grep pod1-controller-0

| 1ca946b8-52e5-4add-b94c-4d4b8a15a975 | pod1-controller-0  | ACTIVE | -          | Running     | ctlplane=192.200.0.112 |

2. 影響を受けるコントローラにログインし、unstandbyを設定してスタンバイモードを削除します。コントローラがクラスタでオンラインになり、galeraは3つのコントローラすべてをマスターとして表示することを確認します。これには数分かかることがあります.

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

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

Cluster name: tripleo_cluster

Stack: corosync

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

Last updated: Mon Dec  4 01:08:10 2017                        Last change: Mon Dec  4 01:04:21 2017 by root via crm_attribute on pod1-controller-0

3 nodes and 22 resources configured

Online: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

Full list of resources:

ip-11.118.0.42  (ocf::heartbeat:IPaddr2):           Started pod1-controller-1

ip-11.119.0.47  (ocf::heartbeat:IPaddr2):           Started pod1-controller-2

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

ip-192.200.0.102          (ocf::heartbeat:IPaddr2):           Started pod1-controller-2

Clone Set: haproxy-clone [haproxy]

Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

Master/Slave Set: galera-master [galera]

Masters: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

ip-11.120.0.47  (ocf::heartbeat:IPaddr2):           Started pod1-controller-2

Clone Set: rabbitmq-clone [rabbitmq]

Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

Master/Slave Set: redis-master [redis]

Masters: [ pod1-controller-2 ]

Slaves: [ pod1-controller-0 pod1-controller-1 ]

ip-10.84.123.35            (ocf::heartbeat:IPaddr2):           Started pod1-controller-1

openstack-cinder-volume          (systemd:openstack-cinder-volume):            Started pod1-controller-2

my-ipmilan-for-pod1-controller-0        (stonith:fence_ipmilan):  Started pod1-controller-1

my-ipmilan-for-pod1-controller-1        (stonith:fence_ipmilan):  Started pod1-controller-1

my-ipmilan-for-pod1-controller-2        (stonith:fence_ipmilan):  Started pod1-controller-2

Daemon Status:

corosync: active/enabled

pacemaker: active/enabled

pcsd: active/enabled

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

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

cluster eb2bb192-b1c9-11e6-9205-525400330666

health HEALTH_OK

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

election epoch 70, quorum 0,1,2 pod1-controller-0,pod1-controller-1,pod1-controller-2

osdmap e218: 12 osds: 12 up, 12 in

flags sortbitwise,require_jewel_osds

pgmap v2080888: 704 pgs, 6 pools, 714 GB data, 237 kobjects

2142 GB used, 11251 GB / 13393 GB avail

704 active+clean

client io 11797 kB/s wr, 0 op/s rd, 57 op/s wr