Ultra 6.3リリース以降のElement Manager：アーキテクチャの変更とEMの問題のトラブルシューティング方法

概要

このドキュメントでは、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