内容

概要

前提条件

要件

使用するコンポーネント

背景説明

省略形

Ultra 6.3リリース以降のUltra Element Manager – アーキテクチャの変更

UEM VMインスタンス数は6.3リリース時点で設定可能

ZooKeeperディストリビューション

HAのキープアライブの概要

SCMをNCSプロセスから分離

EMサービスはマスターノードでのみ実行

Element Manager関連の問題のトラブルシューティング手順

2台のVMを使用したUEMのセットアップ – プロセスの起動シーケンスとログの場所

3つのVMを使用したUEMのセットアップ – プロセスの起動シーケンスとログの場所

UEMプロセスの概要

概要

このドキュメントでは、6.3 UltraMリリースの一部として導入されたElement Manager(EM)アーキテクチャの変更について説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

- STARO

- Ultra-Mベースアーキテクチャ

使用するコンポーネント

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

Ultra 6.3リリース以前では、Ultra Element Managerが動作するためには、3つのUEM VMを作成する必要がありました。  3つ目は使用されておらず、ZooKeeperクラスタの形成を支援するためにそこにあった。6.3リリース以降、この設計は変更されました。

省略形

この記事で使用されている略語：

VNF

仮想ネットワーク機能

CF

制御機能

SF

サービス機能

ESC

Elastic Service Controller

VIM

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

VM

仮想マシン

EM

エレメント マネージャ

UAS

Ultra Automation Services

UUID

ユニバーサル一意IDentifier

ZK

動物園の飼育員

Ultra 6.3リリース以降のUltra Element Manager – アーキテクチャの変更

このドキュメントでは、6.3 UltraMリリースの一部として導入された次の5つの変更について説明します。

UEM VMインスタンス数は6.3リリース時点で設定可能

6.3リリース以前は、3台のUEM 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 |

| 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

...

このコマンドで指定されたインスタンスの数に関係なく、スピンされたVMの数は常に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が発生します。

[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がZKの3つのインスタンスを動作させるために必要です。すべてのインスタンスにIPアドレスが必要です。3番目のインスタンスが効果的に使用されていなくても、3番目のIPは、いわゆるアービター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より前はクラスタの形成に使用されていたため、この要件は3番目のVMに対するものです。

その要件は変わっていない。ただし、2つのUEM VMが使用されるセットアップでは、同じVMセット上で第3のZKインスタンスがホストされます。

3 UEM VMを使用したセットアップで6.3より前および6.3以降：

UEM VM1:ホスティングZkインスタンス1

UEM VM2:ホスティングZkインスタンス2

UEM VM3:ホスティングZkインスタンス3

6.3以降では、2つのVMのみ：

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のキープアライブの概要

以前のリリースでは、マスターEMを決定するために使用されるZKリーダー選出フレームワークが使用されました。シスコがキープアライブフレームワークに移行したため、これはもう該当しません。

キープアライブとは何ですか。どのように機能しますか。

キープアライブは、Linuxベースのソフトウェアで、LinuxシステムおよびLinuxベースのインフラストラクチャへのロードバランシングと高可用性のために使用されます。

これは、ESCでHA用にすでに使用されています。

EMでは、キープアライブはNCSをZkクラスタ状態から切り離すために使用されます。

キープアライブプロセスは、EMの最初の2つのインスタンスでのみ実行され、NCSプロセスのマスター状態を判別します。

To check if the keepalived process is running:

ps -aef | grep keepalived

(must return the process ID)

なぜ変わる？

以前の実装では、(NCS/SCM)マスターノードの選択がZkクラスタステータスと密接に統合されていました（Zkデータベースの/emをロックする最初のインスタンスがマスターに選出されました）。 これにより、Zkがクラスタとの接続を失うと問題が発生します。

キープアライブは、VMベースでアクティブ/スタンバイ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にログインすると、次のコマンドを使用して1つの（マスター）ノードだけが表示されるようになっています。

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配布の概要を示しています

Element Manager関連の問題のトラブルシューティング手順

ブートアップ時の起動シーケンスは次のとおりです。

2台のVMを使用したUEMのセットアップ – プロセスの起動シーケンスとログの場所

マスターUEM:

- キープアライブ

- 飼育員

- NCS

- Zookeeperのアービター(3rd)の例

- VNFM-Proxy

- SCM

- SLA

スレーブUEM:

- キープアライブ

- 飼育員

- NCS

3つのVMを使用したUEMのセットアップ – プロセスの起動シーケンスとログの場所

マスターUEM:

- キープアライブ

- 飼育員

- NCS

- VNFM-Proxy

- SCM

- SLA

スレーブUEM:

- キープアライブ

- 飼育員

- NCS

3番目のUEM:

- 飼育員

UEMプロセスの概要

これは、実行する必要があるUEMプロセスの要約です。

ps -aefでステータスを確認します。 | grep xx

キープアライブ

アービタ

scm

sla

zoo.cfg

ncs

ステータスはservice xx statusで確認できます。ここでxxは次のとおりです。

zookeeper-arbiter

プロキシ

scm

sla

ザック

ncs