モジュラコンポーネントRMA-PCRF
ダウンロード オプション
Updated: 2018 年 9 月 5 日
Document ID:213630
偏向のない言語
この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
翻訳について
シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。
内容
概要
このドキュメントでは、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のディザスタリカバリを効果的に実行するには、このバックアップを作成する必要があります
- [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 - このファイルを、クラウド外のサーバにftp/sftpのローカルコンピュータにダウンロードします。
ステップ2:PCRFクラウド設定のバックアップ展開XMLで参照されるすべてのスクリプトとユーザデータファイル。
- 前の手順でエクスポートした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 - CPSオーケストレーションAPIの送信に使用されるすべての導入後スクリプトを検索します。
- 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リカバリ
- 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 |
- 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 - モニタ 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].
- 起動しているVMのすべてのサービスを確認します。
ESC VMのリカバリ
- コンソールからESCにログインし、ステータスを確認します。
- まだ開始していない場合は、プロセスを開始します
[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：コントローラクラスタをメンテナンスモードに移動します。
- アップデート中のコントローラにpcクラスタをスタンバイ状態にします.
[heat-admin@pod1-controller-0 ~]$ sudo pcs cluster standby
- 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
- 他の2つのコントローラのpcステータスも、ノードがスタンバイとして表示されます。
ステップ3：コントローラノードから障害のあるコンポーネントを交換します。
指定したサーバの電源をオフにします。UCS C240 M4サーバ上の障害のあるコンポーネントを交換する手順は、次から参照できます。
ステップ4：サーバの電源をオンにします。
- サーバの電源をオンにし、サーバが起動することを確認します。
[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 |
- 影響を受けるコントローラにログインし、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
- モニタサービスの一部（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
シスコ エンジニア提供
- Nitesh BansalCisco Advance Services
フィードバックシスコに問い合わせ
- サポート ケースをオープン
- (シスコ サービス契約が必要です。)