目錄

簡介

必要條件

需求

採用元件

背景資訊

縮寫

Ultra 6.3發行版後的Ultra元素管理器 — 體系結構更改

自6.3版本起，可配置的UEM虛擬機器例項數量

ZooKeeper發佈

HA的Keepalive簡介

將SCM與NCS進程分離

EM服務僅在主節點上運行

元素管理器相關問題故障排除步驟

使用2個虛擬機器的UEM設定 — 處理啟動順序和日誌位置

使用3個虛擬機器設定 — 處理啟動順序和日誌位置

UEM流程摘要

簡介

本文檔介紹作為6.3 UltraM版本的一部分引入的元素管理器(EM)體系結構中的更改。

必要條件

需求

思科建議您瞭解以下主題：

- STARO

- Ultra-M基本體系結構

採用元件

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

背景資訊

在Ultra 6.3發行版之前， Ultra Element Manager需要建立3個UEM虛擬機器，才能正常運行。  第三個沒有使用，是幫助形成ZooKeeper集群。從6.3版本起，此設計已更改。

縮寫

本文中使用的縮寫：

VNF

虛擬網路功能

CF

控制功能

SF

服務功能

ESC

彈性服務控制器

VIM

虛擬基礎架構管理員

虛擬機器

虛擬機器

EM

元素管理器

UAS

Ultra自動化服務

UUID

通用唯一識別符號

ZK

動物園管理員

Ultra 6.3發行版後的Ultra元素管理器 — 體系結構更改

本文檔介紹作為6.3 UltraM版本的一部分引入的這5項更改：

自6.3版本起，可配置的UEM虛擬機器例項數量

在6.3版本之前，必須使用3 UEM VM。來源核心租戶檔案後，您可以通過nova list看到：

[root@POD]# openstack server list --all

+--------------------------------------+-----------------------+--------+--------------------------------------------------------------------+---------------+

| ID | Name | Status | Networks | Image Name |

+--------------------------------------+-----------------------+--------+---------------------------------....

| fae2d54a-96c7-4199-a412-155e6c029082 | vpc-LAASmme-em-3 | ACTIVE | orch=192.168.12.53; mgmt=192.168.11.53 | ultra-em |

| c89a3716-9028-4835-9237-759166b5b7fb | vpc-LAASmme-em-2 | ACTIVE | orch=192.168.12.52; mgmt=192.168.11.52 | ultra-em |

| 5f8cda2c-657a-4ba1-850c-805518e4bc18 | vpc-LAASmme-em-1 | ACTIVE | orch=192.168.12.51; mgmt=192.168.11.51 | ultra-em |

已使用此配置快照（來自vnf.conf檔案）：

vnfc em

health-check enabled

health-check probe-frequency 10

health-check probe-max-miss 6

health-check retry-count 6

health-check recovery-type restart-then-redeploy

health-check boot-time 300

vdu vdu-id em

number-of-instances 1 --> HERE, this value was previously ignored in pre 6.3 releases

connection-point eth0

...

無論此命令中指定的例項數如何，旋轉虛擬機器數始終為3。換句話說，忽略了例項數值。

從6.3開始，此值將更改 — 配置的值可以是2或3。

配置2時，將建立2個UEM VM。

配置3時，將建立3個UEM VM。

vnfc em

health-check enabled

health-check probe-frequency 10

health-check probe-max-miss 6

health-check retry-count 3

health-check recovery-type restart

health-check boot-time 300

vdu vdu-id vdu-em

vdu image ultra-em

vdu flavor em-flavor

number-of-instances 2 --> HERE

connection-point eth0

....

此配置將導致2個VM，如nova列表所示。

[root@POD]# openstack server list --all

+--------------------------------------+-----------------------+--------+--------------------------------------------------------------------+---------------+

| ID | Name | Status | Networks | Image Name |

+--------------------------------------+-----------------------+--------+---------------------------------....

| fae2d54a-96c7-4199-a412-155e6c029082 | vpc-LAASmme-em-3 | ACTIVE | orch=192.168.12.53; mgmt=192.168.11.53 | ultra-em |

| c89a3716-9028-4835-9237-759166b5b7fb | vpc-LAASmme-em-2 | ACTIVE | orch=192.168.12.52; mgmt=192.168.11.52 | ultra-em |

但是請注意，3個IP地址要求保持不變。即，在配置（vnf.conf檔案）的EM部分中，3個IP地址仍然為必填地址：

vnfc em

health-check enabled

health-check probe-frequency 10

health-check probe-max-miss 6

health-check retry-count 3

health-check recovery-type restart

health-check boot-time 300

vdu vdu-id vdu-em

vdu image ultra-em

vdu flavor em-flavor

number-of-instances 2 ---> NOTE NUMBER OF INSTANCES is 2

connection-point eth0

virtual-link service-vl orch

virtual-link fixed-ip 172.x.y.51  --> IP #1

!

virtual-link fixed-ip 172.x.y.52 --> IP #2

!

virtual-link fixed-ip 172.x.y.53  --> IP #3

!

要使ZK工作，需要使用3個ZK例項。每個例項都需要一個IP地址。即使第3個例項未有效使用，第3個IP也分配給第3個，即所謂的Arbiter ZK例項（有關更多說明，請參見Diff.2）。

這對協調網路有何影響？

在協調網路中始終會建立3個埠（用於繫結3個提到的IP地址）。

[root@POD# neutron port-list | grep -em_

| 02d6f499-b060-469a-b691-ef51ed047d8c | vpc-LAASmme-em_vpc-LA_0_70de6820-9a86-4569-b069-46f89b9e2856 | fa:16:3e:a4:9a:49 | {"subnet_id": "bf5dea3d-cd2f-4503-a32d-5345486d66dc", "ip_address": "192.168.12.52"} |

| 0edcb464-cd7a-44bb-b6d6-07688a6c130d | vpc-LAASmme-em_vpc-LA_0_2694b73a-412b-4103-aac2-4be2c284932c | fa:16:3e:80:eb:2f | {"subnet_id": "bf5dea3d-cd2f-4503-a32d-5345486d66dc", "ip_address": "192.168.12.51"} |

| 9123f1a8-b3ea-4198-9ea3-1f89f45dfe74 | vpc-LAASmme-em_vpc-LA_0_49ada683-a5ce-4166-aeb5-3316fe1427ea | fa:16:3e:5c:17:d6 | {"subnet_id": "bf5dea3d-cd2f-4503-a32d-5345486d66dc", "ip_address": "192.168.12.53"} |

ZooKeeper發佈

6.3 ZK之前的版本用於形成群集，因此此要求適用於第三個VM。

這一要求並未改變。但是，對於使用2個UEM虛擬機器的設定，第3個ZK例項託管在同一組VM上：

在具有3個UEM虛擬機器的設定中，6.3之前和6.3之後：

UEM VM1:託管Zk例項1

UEM VM2:託管Zk例項2

UEM VM3:託管Zk例項3

在6.3及更高版本中，只有2個虛擬機器：

UEM VM1:託管Zk例項1和Zk例項3

UEM VM2:託管Zk例項2

UEM VM3:不存在

請參見本文底部的圖片1。以瞭解詳細的圖形表示。

Useful Zk commands:

To see Zk mode (leader/follower):

/opt/cisco/usp/packages/zookeeper/current/bin/zkServer.sh status

ZooKeeper JMX enabled by default

Using config: /opt/cisco/usp/packages/zookeeper/current/bin/../conf/zoo.cfg

Mode: leader

To check if Zk is running:

echo stat | nc IP_ADDRESS 2181

How to find the Ip address of Zk instance:

Run 'ip addr' from EM

In the /opt/cisco/em/config/ip.txt there are all the 3IP's

From vnf.conf file

From 'nova list' look for orchestration IP

For 2 EM's the arbiter IP can be found also in /opt/cisco/em/config/proxy-params.txt

How to check status of the Zk instance:

echo stat | nc 192.168.12.51 2181 | grep Mode

Mode: follower

You can run this command from one Zk for all other Zk instances (even they are on different VM)!

To connect to the Zk cli - now must use the IP (rather then localhost earlier):

/opt/cisco/usp/packages/zookeeper/current/bin/zkCli.sh -server

:2181

You can use same command to connect to other Zk instances (even they are on different VM)!

Some useful command you can run once you connect to ZkCli:

ls /config/vdus/control-function

ls /config/element-manager

ls /

ls /log

ls /stat

get /config/vdus/session-function/BOOTxx

HA的Keepalive簡介

在以前的版本中，ZK領導者選舉框架用於確定主EM。而隨著思科遷移到keepalive框架，情況已不再是這樣。

什麼是keepalive及其運作方式？

Keepalive是一種基於Linux的軟件，用於Linux系統和基於Linux的基礎架構的負載平衡和高可用性。

已在ESC中使用HA。

在EM中，Keepalive用於將NCS與Zk集群狀態分離。

Keepalive進程僅在EM的前兩個例項上運行，並且會確定NCS進程的主狀態。

To check if the keepalived process is running:

ps -aef | grep keepalived

(must return the process ID)

為什麼要改變？

在早期實現中，(NCS/SCM)主節點選擇與Zk群集狀態緊密整合（在Zk資料庫中鎖定/em的第一個例項被選為主例項）。 當Zk失去與群集的連線時，這會產生問題。

Keepalive用於維護虛擬機器上的主用/備用UEM集群。

NCS維護配置資料。

Zookeeper維護運算元據。

將SCM與NCS進程分離

在6.3之前的版本中，SCM元件與NCS捆綁在一起。這表示當NCS啟動時，SCM也啟動（因此）。 在此版本中，這現在已解除耦合，而SCM本身就是一個獨立的程式。

Commands to check the NCS and SCM services & processes.

To be executed from the ubuntu command line

ps -aef | grep ncs

ps -aef | grep scm

sudo service show ncs

sudo service scm status

EM服務僅在主節點上運行

6.3之前的版本中，UEM服務同時運行在主/從上。自6.3起，服務僅在主節點上運行。這將影響show ems中顯示的輸出。從6.3開始，使用此命令只能看到一個（主）節點，一旦登入到UEM CLI:

root@vpc-em-2:/var/log# sudo -i

root@vpc-em-2:~# ncs_cli -u admin -C

admin connected from 127.0.0.1 using console on vpc-LAASmme-em-2

admin@scm# show ems

EM VNFM

ID SLA SCM PROXY VERSION

------------------------------

52 UP UP UP 6.3.0 ===> HERE Only one EM instance is seen. In previous releases you were able to see 2 instances.

實際上，除NCS外，所有服務都將在主節點上運行，這是由NCS要求引起的。

此圖顯示了Ultra Element Manager可能的服務和VM分佈的摘要

元素管理器相關問題故障排除步驟

啟動期間，啟動順序如下：

使用2個虛擬機器的UEM設定 — 處理啟動順序和日誌位置

主UEM:

- keepalive

- Zookeeper

- NCS

- Zookeeper的Arbiter(第3個)例項

- VNFM-Proxy

- SCM

- SLA

從屬UEM:

- keepalive

- Zookeeper

- NCS

使用3個虛擬機器設定 — 處理啟動順序和日誌位置

主UEM:

- keepalive

- Zookeeper

- NCS

- VNFM-Proxy

- SCM

- SLA

從屬UEM:

- keepalive

- Zookeeper

- NCS

第3個UEM:

- Zookeeper

UEM流程摘要

這是您必須運行的UEM進程的摘要。

使用ps -aef檢查狀態 | grep xx

keepalive

仲裁器

scm

sla

zoo.cfg

ncs

您可以用service xx status檢查狀態，其中xx:

zookeeper-arbiter

代理

scm

sla

zk

ncs