目錄

簡介

必要條件

確定計算節點中託管的VM

正常斷電

計算節點停止 — 啟動

恢復虛擬機器

簡介

本文檔介紹在承載思科策略套件(CPS)虛擬網路功能(VNF)的Ultra-M設定中停止啟動有故障的計算伺服器所需的步驟。

附註：Ultra M 5.1.x版本用於定義本文檔中的過程。本文檔面向熟悉Cisco Ultra-M平台的思科人員，詳細說明了在Compute Server停止啟動時在OpenStack和CPS VNF級別上執行的步驟。

必要條件

備份

在停止 — 啟動計算節點之前，請務必檢查Red Hat OpenStack平台環境的當前狀態。建議您檢查當前狀態以避免併發症。

在進行恢復時，思科建議使用以下步驟備份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

此過程可確保在不影響任何例項可用性的情況下替換節點。此外，建議備份CPS配置。

使用此配置可以從群集管理器虛擬機器(VM)備份CPS虛擬機器。

[root@CM ~]# config_br.py -a export --all /mnt/backup/CPS_backup_28092016.tar.gz

確定計算節點中託管的VM

確定託管在計算伺服器上的虛擬機器。

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

| 49ac5f22-469e-4b84-badc-031083db0533 |  VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d     |  pod1-compute-10.localdomain    | Replication=10.160.137.161; Internal=192.168.1.131; Management=10.225.247.229; tb1-orch=172.16.180.129

附註：此處顯示的輸出中，第一列對應於通用唯一識別符號(UUID)，第二列是VM名稱，第三列是存在VM的主機名。此輸出的引數將在後續章節中使用。

禁用駐留在VM上的PCRF服務以關閉

1.登入虛擬機器的管理IP。

[stack@XX-ospd ~]$ ssh root@<Management IP>

[root@XXXSM03 ~]# monit stop all

2.如果VMis anSM、OAMorArbiter，請停止sessionmgr服務。

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

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

-rwxr-xr-x 1 root root 4544 Nov 29 23:47 sessionmgr-27717

-rwxr-xr-x 1 root root 4399 Nov 28 22:45 sessionmgr-27721

-rwxr-xr-x 1 root root 4544 Nov 29 23:47 sessionmgr-27727

3.標題為sessionmgr-xxxxx的forevery檔案run service sessionmgr-xxxxx stop。

[root@XXXSM03 init.d]# service sessionmgr-27717 stop

正常斷電

從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_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d</vm_name>

<state>VM_ALIVE_STATE</state>

<snip>

2.使用虛擬機器名稱停止虛擬機器。（在「識別計算節點中託管的VM」部分中註明的VM名稱。）

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d

3.一旦停止，VM必須進入SHUTOFF狀態。

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

<vm_name>VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d</vm_name>

<state>VM_SHUTOFF_STATE</state>

<snip>

計算節點停止 — 啟動

不論計算節點中託管的VM，本節中提到的步驟都是通用的。

從OSPD停止 — 啟動計算節點

1.檢查狀態，然後停止啟動節點。

[stack@director ~]$ nova list | grep compute-10

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

[stack@director ~]$ nova stop pod1-stack-compute-10

2.等待電腦處於關閉狀態，然後再次啟動。

[stack@director ~]$ nova start pod1-stack-compute-10

3.檢查新的計算節點是否處於活動狀態。

[stack@director ~]$ source stackrc

[stack@director ~]$ nova list |grep compute-10

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

[stack@director ~]$ source pod1-stackrc-Core

[stack@director ~]$ openstack hypervisor list |grep compute-10

| 6 | pod1-compute-10.localdomain    |

恢復虛擬機器

從ESC恢復VM

1.理想情況下，從OSPD中，如果檢查新星清單，VM應處於關閉狀態。在這種情況下，您需要從ESC啟動VM。

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

[sudo] password for admin:

2.或者，如果VM在新星清單中處於錯誤狀態，請執行此配置。

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

3.現在，從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

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

4.監控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上的PCRF服務

附註：如果VM處於SHUTOFF狀態，則使用ESC的esc_nc_cli將其開啟。從群集管理器虛擬機器中檢查diagnostics.sh，如果發現已恢復的VM的任何錯誤，請進行檢查。

1.登入到相應的虛擬機器。

[stack@XX-ospd ~]$ ssh root@<Management IP>

[root@XXXSM03 ~]# monit start all

2.如果VMis anSM、OAMorArbiter，請啟動之前停止的sessionmgr服務。標題為sessionmgr-xxxxx的檔案運行service sessionmgr-xxxxx start。

[root@XXXSM03 init.d]# service sessionmgr-27717 start

3.如果仍不清除診斷，則從群集管理器虛擬機器執行build_all.sh，並在相應的虛擬機器上執行VM-init。

/var/qps/install/current/scripts/build_all.sh

ssh VM   e.g. ssh pcrfclient01

/etc/init.d/vm-init