Ultra-M UCS 240M4サーバのマザーボード交換 – CPS

概要

このドキュメントでは、CPS仮想ネットワーク機能(VNF)をホストするUltra-Mセットアップでサーバのマザーボードの障害を交換するために必要な手順について説明します。

背景説明

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

• 計算
• オブジェクトストレージディスク – コンピューティング（OSD – コンピューティング）
• コントローラ
• OpenStackプラットフォーム – Director(OSPD)

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

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

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

省略形

VNF	仮想ネットワーク機能
ESC	Elastic Service Controller
MOP	手続きの方法
OSD	オブジェクトストレージディスク
HDD	ハードディスクドライブ
SSD	ソリッドステートドライブ
VIM	仮想インフラストラクチャマネージャ
VM	仮想マシン
EM	エレメント マネージャ
UAS	Ultra Automation Services
UUID	ユニバーサル一意IDentifier

MoPのワークフロー

Ultra-Mセットアップでのマザーボードの交換

Ultra-Mセットアップでは、次のサーバタイプでマザーボードの交換が必要になる場合があります。コンピューティング、OSDコンピューティング、コントローラ

注：openstackをインストールしたブートディスクは、マザーボードの交換後に交換されます。したがって、ノードをオーバークラウドに追加する必要はありません。交換アクティビティの後にサーバの電源がオンになると、サーバ自体がオーバークラウドスタックに登録されます。

コンピューティングノードでのマザーボードの交換

このアクティビティの前に、コンピューティングノードでホストされているVMは正常にシャットオフされます。マザーボードを交換すると、VMが復元されます。

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

コンピューティングサーバでホストされているVMを特定します。

コンピューティングサーバには、CPSまたはElastic Services Controller(ESC)VMが含まれています。

[stack@director ~]$ nova list --field name,host | grep compute-8
| 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea | pod1-compute-8.localdomain     |
| f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229     | pod1-compute-8.localdomain     |
| 75528898-ef4b-4d68-b05d-882014708694 | VNF2-ESC-ESC-0                                             | pod1-compute-8.localdomain     |

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

グレースフルパワーオフ

コンピュートノードホストCPS/ESC VM

ステップ1:VNFに対応するESCノードにログインし、VMのステータスを確認します。

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                    <state>VM_ALIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                    <state>VM_ALIVE_STATE</state>
<deployment_name>VNF2-DEPLOYMENT-em</deployment_name>
                  <vm_id>507d67c2-1d00-4321-b9d1-da879af524f8</vm_id>
                  <vm_id>dc168a6a-4aeb-4e81-abd9-91d7568b5f7c</vm_id>
                  <vm_id>9ffec58b-4b9d-4072-b944-5413bf7fcf07</vm_id>
                <state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea</vm_name>
                    <state>VM_ALIVE_STATE</state>
<snip>

ステップ2:VM名を使用してCPS VMを1つずつ停止します。(VM名は「コンピュートノードでホストされるVMを識別する」セクションに記載されています)。

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea

ステップ3：停止後、VMはシャットオフ状態になる必要があります。

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                    <state>VM_SHUTOFF_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                    <state>VM_ALIVE_STATE</state>
<deployment_name>VNF2-DEPLOYMENT-em</deployment_name>
                  <vm_id>507d67c2-1d00-4321-b9d1-da879af524f8</vm_id>
                  <vm_id>dc168a6a-4aeb-4e81-abd9-91d7568b5f7c</vm_id>
                  <vm_id>9ffec58b-4b9d-4072-b944-5413bf7fcf07</vm_id>
                <state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea</vm_name>
                    
     
     
       VM_SHUTOFF_STATE 
     
<snip>

ステップ4：コンピューティングノードでホストされている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!

ESCバックアップ

ステップ1:ESCは、UltraMソリューションで1:1の冗長性を持ちます。2 ESC VMが導入され、UltraMで単一障害をサポートつまり、システムに1つの障害が発生すると、システムが回復します。

注：複数の障害が発生した場合は、サポートされず、システムの再展開が必要になる可能性があります。

ESCバックアップの詳細：

• Running Configuration
• ConfD CDB DB
• ESCログ
• Syslog設定

ステップ2:ESC DBのバックアップの頻度は複雑で、ESCが各種のVNF VMを監視して維持するため、慎重に処理する必要があります。これらのバックアップは、特定のVNF/POD/Siteで次のアクティビティを実行した後に実行することをお勧めします。

ステップ3:ESCの状態がhealth.shスクリプトの使用に適していることを確認してください。

[root@auto-test-vnfm1-esc-0 admin]# escadm status
0 ESC status=0 ESC Master Healthy

[root@auto-test-vnfm1-esc-0 admin]# health.sh
esc ui is disabled -- skipping status check
esc_monitor start/running, process 836
esc_mona is up and running ...
vimmanager start/running, process 2741
vimmanager start/running, process 2741
esc_confd is started
tomcat6 (pid 2907) is running...                           [  OK  ]
postgresql-9.4 (pid  2660) is running...
ESC service is running...
Active VIM = OPENSTACK
ESC Operation Mode=OPERATION

/opt/cisco/esc/esc_database is a mountpoint

============== ESC HA (MASTER) with DRBD =================

DRBD_ROLE_CHECK=0
MNT_ESC_DATABSE_CHECK=0
VIMMANAGER_RET=0
ESC_CHECK=0
STORAGE_CHECK=0
ESC_SERVICE_RET=0
MONA_RET=0
ESC_MONITOR_RET=0

=======================================

ESC HEALTH PASSED

ステップ4：実行コンフィギュレーションのバックアップを取り、ファイルをバックアップサーバに転送します。

[root@auto-test-vnfm1-esc-0 admin]# /opt/cisco/esc/confd/bin/confd_cli -u admin -C

admin connected from 127.0.0.1 using console on auto-test-vnfm1-esc-0.novalocal
auto-test-vnfm1-esc-0# show running-config | save /tmp/running-esc-12202017.cfg
auto-test-vnfm1-esc-0#exit

[root@auto-test-vnfm1-esc-0 admin]# ll /tmp/running-esc-12202017.cfg
-rw-------. 1 tomcat tomcat 25569 Dec 20 21:37 /tmp/running-esc-12202017.cfg

バックアップESCデータベース

ステップ1:ESC VMにログインし、バックアップを実行する前にこのコマンドを実行します。

[admin@esc ~]# sudo bash
[root@esc ~]# cp /opt/cisco/esc/esc-scripts/esc_dbtool.py /opt/cisco/esc/esc-scripts/esc_dbtool.py.bkup
[root@esc esc-scripts]# sudo sed -i "s,'pg_dump,'/usr/pgsql-9.4/bin/pg_dump," /opt/cisco/esc/esc-scripts/esc_dbtool.py

#Set ESC to mainenance mode
[root@esc esc-scripts]# escadm op_mode set --mode=maintenance

ステップ2:ESCモードをチェックし、メンテナンスモードであることを確認します。

[root@esc esc-scripts]# escadm op_mode show

ステップ3:ESCで使用できるデータベースバックアップ復元ツールを使用してデータベースをバックアップします。

[root@esc scripts]# sudo /opt/cisco/esc/esc-scripts/esc_dbtool.py backup --file  scp://
     
     
       : 
      
        @ 
       
         : 
         
        
       
     

ステップ4:ESCを[Operation Mode]に戻し、モードを確認します。

[root@esc scripts]# escadm op_mode set --mode=operation

[root@esc scripts]# escadm op_mode show 

ステップ5:scriptsディレクトリに移動し、ログを収集します。

[root@esc scripts]# /opt/cisco/esc/esc-scripts

sudo ./collect_esc_log.sh

ステップ6:ESCのスナップショットを作成するには、まずESCをシャットダウンします。

shutdown -r now

ステップ7:OSPDからイメージスナップショットを作成します。

•  nova image-create --poll esc1 esc_snapshot_27aug2018 

ステップ8：スナップショットが作成されたことを確認します 

openstack image list | grep esc_snapshot_27aug2018

ステップ9:OSPDからESCを起動します 

nova start esc1 

ステップ10：スタンバイESC VMで同じ手順を繰り返し、ログをバックアップサーバに転送します。

ステップ11：両方のESC VMSでsyslog設定バックアップを収集し、バックアップサーバに転送します。

[admin@auto-test-vnfm2-esc-1 ~]$ cd /etc/rsyslog.d
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/00-escmanager.conf
00-escmanager.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/01-messages.conf
01-messages.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/02-mona.conf
02-mona.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.conf
rsyslog.conf

マザーボードの交換

ステップ1:UCS C240 M4サーバのマザーボードを交換する手順は、次のURLから参照できます。

『Cisco UCS C240 M4 Server Installation and Service Guide』

ステップ2:CIMC IPを使用してサーバにログインします。

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

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

VMのリストア

コンピュートノードホストCPS、ESC

ESC VMのリカバリ

ステップ1:VMがエラー状態またはシャットダウン状態の場合、ESC VMは回復可能です。ハードリブートを行って、影響を受けるVMを起動します。ESCを回復するには、次の手順を実行します。

ステップ2：エラーまたはシャットダウン状態のVMを特定し、ESC VMをハードリブートします。この例では、auto-test-vnfm1-ESC-0をリブートします。

[root@tb1-baremetal scripts]# nova list | grep auto-test-vnfm1-ESC-

| f03e3cac-a78a-439f-952b-045aea5b0d2c | auto-test-vnfm1-ESC-0                                       | ACTIVE | -          | running     | auto-testautovnf1-uas-orchestration=172.57.12.11; auto-testautovnf1-uas-management=172.57.11.3                                                                                      |
| 79498e0d-0569-4854-a902-012276740bce | auto-test-vnfm1-ESC-1                                       | ACTIVE | -          | running     | auto-testautovnf1-uas-orchestration=172.57.12.15; auto-testautovnf1-uas-management=172.57.11.5                                                                                      |

[root@tb1-baremetal scripts]# [root@tb1-baremetal scripts]# nova reboot --hard f03e3cac-a78a-439f-952b-045aea5b0d2c\
Request to reboot server <Server: auto-test-vnfm1-ESC-0> has been accepted.

[root@tb1-baremetal scripts]#

ステップ3:ESC VMが削除され、再度起動する必要がある場合。 

[stack@pod1-ospd scripts]$ nova list |grep ESC-1
| c566efbf-1274-4588-a2d8-0682e17b0d41 | vnf1-ESC-ESC-1                                                 | ACTIVE | -          | running     | vnf1-UAS-uas-orchestration=172.168.11.14; vnf1-UAS-uas-management=172.168.10.4                                                                                                 |

[stack@pod1-ospd scripts]$ nova delete vnf1-ESC-ESC-1
Request to delete server vnf1-ESC-ESC-1 has been accepted.

ステップ4:OSPDから、新しいESC VMがアクティブ/実行中であることを確認します。

[stack@pod1-ospd ~]$ nova list|grep -i esc
| 934519a4-d634-40c0-a51e-fc8d55ec7144 | vnf1-ESC-ESC-0                                                 | ACTIVE | -          | running     | vnf1-UAS-uas-orchestration=172.168.11.13; vnf1-UAS-uas-management=172.168.10.3                                                                                                 |
| 2601b8ec-8ff8-4285-810a-e859f6642ab6 | vnf1-ESC-ESC-1                                                 | ACTIVE | -          | running     | vnf1-UAS-uas-orchestration=172.168.11.14; vnf1-UAS-uas-management=172.168.10.6                                                                                                 |

#Log in to new ESC and verify Backup state.  You may execute health.sh on ESC Master too.

…
   ####################################################################
   #   ESC on vnf1-esc-esc-1.novalocal is in BACKUP state.
   ####################################################################

[admin@esc-1 ~]$ escadm status
0 ESC status=0 ESC Backup Healthy

[admin@esc-1 ~]$ health.sh
============== ESC HA (BACKUP) =================
=======================================

ESC HEALTH PASSED
[admin@esc-1 ~]$ cat /proc/drbd
version: 8.4.7-1 (api:1/proto:86-101)
GIT-hash: 3a6a769340ef93b1ba2792c6461250790795db49 build by mockbuild@Build64R6, 2016-01-12 13:27:11
 1: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
    ns:0 nr:504720 dw:3650316 dr:0 al:8 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

ステップ5:ESC VMが回復不能でデータベースの復元が必要な場合は、以前に取得したバックアップからデータベースを復元してください。

ステップ6:ESCデータベースを復元するには、データベースを復元する前にESCサービスが停止していることを確認する必要があります。ESC HAの場合は、最初にセカンダリVMで、次にプライマリVMで実行します。

# service keepalived stop

ステップ7:ESCサービスのステータスを確認し、HAのプライマリVMとセカンダリVMの両方ですべてが停止していることを確認します

# escadm status

ステップ8：スクリプトを実行してデータベースをリストアします。新しく作成されたESCインスタンスへのDBの復元の一環として、ツールはインスタンスの1つをプライマリESCに昇格し、そのDBフォルダをdrbdデバイスにマウントして、PostgreSQLデータベースを起動します。

# /opt/cisco/esc/esc-scripts/esc_dbtool.py restore --file scp://
     
     
       : 
      
        @ 
       
         : 
         
        
       
     

ステップ9:ESCサービスを再起動して、データベースの復元を完了します。

両方のVMでHAを実行するには、キープアライブサービスを再起動します

# service keepalived start

ステップ10:VMが正常に復元されて実行されたら、以前の正常な既知のバックアップからすべてのsyslog固有の設定が復元されていることを確認します。すべてのESC VMで復元されていることを確認します

[admin@auto-test-vnfm2-esc-1 ~]$
[admin@auto-test-vnfm2-esc-1 ~]$ cd /etc/rsyslog.d
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/00-escmanager.conf
00-escmanager.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/01-messages.conf
01-messages.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/02-mona.conf
02-mona.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.conf
rsyslog.conf

ステップ11:ESCをOSPDスナップショットから再構築する必要がある場合は、バックアップ中に取得したスナップショットを使用して次のコマンドを使用します。

nova rebuild --poll --name esc_snapshot_27aug2018 esc1

ステップ12：再構築が完了したら、ESCのステータスを確認します。

nova list --fileds name,host,status,networks | grep esc

ステップ13：次のコマンドでESCの状態を確認します。

health.sh

Copy Datamodel to a backup file
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata > /tmp/esc_opdata_`date +%Y%m%d%H%M%S`.txt

CPS VMの復元

CPS 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からCPS 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
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <ok/>
</rpc-reply>

yanesc.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].

ESCがVMの起動に失敗した場合

ステップ1：予期しない状態が原因で、ESCがVMを起動できない場合があります。回避策は、マスターESCをリブートしてESCスイッチオーバーを実行することです。ESCスイッチオーバーには約1分かかります。  新しいマスターESCでhealth.shを実行し、起動していることを確認します。ESCがマスターになると、ESCはVMの状態を修正し、VMを起動できます。この操作はスケジュールされているため、完了するまで5 ～ 7分待つ必要があります。

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

ステップ3:VMが正常に復元されて実行されたら、以前の正常な既知のバックアップからすべてのsyslog固有の設定が復元されていることを確認します。すべてのESC VMで復元されていることを確認します。

root@autotestvnfm1esc2:/etc/rsyslog.d# pwd
/etc/rsyslog.d

root@autotestvnfm1esc2:/etc/rsyslog.d# ll

total 28
drwxr-xr-x  2 root root 4096 Jun  7 18:38 ./
drwxr-xr-x 86 root root 4096 Jun  6 20:33 ../]
-rw-r--r--  1 root root  319 Jun  7 18:36 00-vnmf-proxy.conf
-rw-r--r--  1 root root  317 Jun  7 18:38 01-ncs-java.conf
-rw-r--r--  1 root root  311 Mar 17  2012 20-ufw.conf
-rw-r--r--  1 root root  252 Nov 23  2015 21-cloudinit.conf
-rw-r--r--  1 root root 1655 Apr 18  2013 50-default.conf

root@abautotestvnfm1em-0:/etc/rsyslog.d# ls /etc/rsyslog.conf
rsyslog.conf

OSDコンピュートノードでのマザーボードの交換

アクティビティの前に、コンピューティングノードでホストされているVMは正常にシャットオフされ、CEPHはメンテナンスモードになります。マザーボードを交換すると、VMが復元され、CEPHがメンテナンスモードから外れます。

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

ステップ1：サーバでceph osdツリーのステータスがupであることを確認します

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

ID WEIGHT   TYPE NAME                         UP/DOWN REWEIGHT PRIMARY-AFFINITY

-1 13.07996 root default
-2  4.35999     host pod1-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 pod1-osd-compute-2
 1  1.09000        osd.1                          up  1.00000          1.00000
 4  1.09000         osd.4                          up  1.00000          1.00000
 7  1.09000         osd.7                          up  1.00000          1.00000
10  1.09000         osd.10                         up  1.00000          1.00000

-4  4.35999     host pod1-osd-compute-1
 2  1.09000         osd.2                          up  1.00000          1.00000
 5  1.09000         osd.5                          up  1.00000          1.00000
 8  1.09000         osd.8                          up  1.00000          1.00000
11  1.09000         osd.11                         up  1.00000          1.00000 

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

[root@pod1-osd-compute-1 ~]# sudo ceph osd set norebalance
[root@pod1-osd-compute-1 ~]# sudo ceph osd set noout

[root@pod1-osd-compute-1 ~]# 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 {pod1-controller-0=11.118.0.40:6789/0,pod1-controller-1=11.118.0.41:6789/0,pod1-controller-2=11.118.0.42:6789/0}
 election epoch 58, quorum 0,1,2 pod1-controller-0,pod1-controller-1,pod1-controller-2
 osdmap 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

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

Osd-ComputeノードでホストされるVMの特定

OSDコンピューティングサーバでホストされているVMを特定します。

コンピューティングサーバには、Elastic Services Controller(ESC)またはCPS VMが含まれています

[stack@director ~]$ nova list --field name,host | grep osd-compute-1
| 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea   | pod1-compute-8.localdomain     |
| f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229     | pod1-compute-8.localdomain     |
| 75528898-ef4b-4d68-b05d-882014708694 | VNF2-ESC-ESC-0                                             | pod1-compute-8.localdomain     |
| f5bd7b9c-476a-4679-83e5-303f0aae9309 | VNF2-UAS-uas-0                                             | pod1-compute-8.localdomain     |

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

グレースフルパワーオフ

ケース1. OSDコンピュートノードホストESC

ESCまたはCPS VMの正常な電源投入手順は、VMがComputeノードまたはOSD-Computeノードでホストされているかどうかに関係なく同じです。

「コンピューティングノードのマザーボード交換」の手順に従って、VMの電源を正常にオフにします。

マザーボードの交換

ステップ1:UCS C240 M4サーバのマザーボードを交換する手順は、次のURLから参照できます。

『Cisco UCS C240 M4 Server Installation and Service Guide』

ステップ2:CIMC IPを使用してサーバにログインします

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

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

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

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

[root@pod1-osd-compute-1 ~]# sudo ceph osd unset norebalance
[root@pod1-osd-compute-1 ~]# sudo ceph osd unset noout

[root@pod1-osd-compute-1 ~]# sudo ceph status

 cluster eb2bb192-b1c9-11e6-9205-525400330666
 health HEALTH_OK
 monmap e1: 3 mons at {pod1-controller-0=11.118.0.40:6789/0,pod1-controller-1=11.118.0.41:6789/0,pod1-controller-2=11.118.0.42:6789/0}
 election epoch 58, quorum 0,1,2 pod1-controller-0,pod1-controller-1,pod1-controller-2
 osdmap e196: 12 osds: 12 up, 12 in
 flags sortbitwise,require_jewel_osds
 pgmap v584954: 704 pgs, 6 pools, 531 GB data, 344 kobjects
 1585 GB used, 11808 GB / 13393 GB avail
 704 active+clean
 client io 12888 kB/s wr, 0 op/s rd, 81 op/s wr

VMのリストア

ケース1. ESCまたはCPS VMをホストするOSD-Computeノード

CF/ESC/EM/UAS VMの復元手順は、VMがコンピューティングまたはOSDコンピューティングノードのどちらでホストされているかに関係なく同じです。

「ケース2：コンピュートノードホストCF/ESC/EM/UAS」の手順に従って、VMを復元します。

コントローラノードでのマザーボードの交換

コントローラのステータスを確認し、クラスタをメンテナンスモードにします

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

[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-controller-0 (stonith:fence_ipmilan): Started pod1-controller-0
 my-ipmilan-for-controller-1 (stonith:fence_ipmilan): Started pod1-controller-0
 my-ipmilan-for-controller-2 (stonith:fence_ipmilan): Started pod1-controller-0

Daemon Status:
 corosync: active/enabled
 pacemaker: active/enabled
 pcsd: active/enabled

クラスタをメンテナンスモードにします。

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

[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-controller-0 (stonith:fence_ipmilan): Started pod1-controller-1
 my-ipmilan-for-controller-1 (stonith:fence_ipmilan): Started pod1-controller-1
 my-ipmilan-for-controller-2 (stonith:fence_ipmilan): Started pod1-controller-2

マザーボードの交換

ステップ1:UCS C240 M4サーバのマザーボードを交換する手順は、次のURLから参照できます。

『Cisco UCS C240 M4 Server Installation and Service Guide』

ステップ2:CIMC IPを使用してサーバにログインします。

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

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

クラスタステータスの復元

影響を受けるコントローラにログインし、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-controller-0 (stonith:fence_ipmilan): Started pod1-controller-1
 my-ipmilan-for-controller-1 (stonith:fence_ipmilan): Started pod1-controller-1
 my-ipmilan-for-controller-2 (stonith:fence_ipmilan): Started pod1-controller-2

Daemon Status:
 corosync: active/enabled
 pacemaker: active/enabled
 pcsd: active/enable