内容

概要

前提条件

要件

使用するコンポーネント

背景説明

省略形

問題：EMはUltra-M Health Managerの場合と同様に、この状態になります

トラブルシューティングと回復手順

ステップ1:EMの状態を確認します。

ステップ2：クラスタに参加しないノードの/var/log/emのログを確認します。

ステップ3：問題のスナップショットが存在することを確認します。

ステップ4：回復手順

概要

このドキュメントでは、Element Managerがスタンドアロンモードで動作している場合の問題のトラブルシューティング方法の概要を示します。

前提条件

要件

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

- StarOs

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

使用するコンポーネント

このドキュメントの情報は、Ultra 5.1.xリリースに基づくものです。

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

背景説明

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

- 計算

- オブジェクトストレージディスク – コンピューティング（OSD – コンピューティング）

- コントローラ

- OpenStackプラットフォーム – Director(OSPD)

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

UltraMアーキテクチャ

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

省略形

この記事では、次の略語を使用しています。

VNF

仮想ネットワーク機能

EM

エレメント マネージャ

VIP

仮想 IP アドレス

CLI

コマンドライン

問題：EMはUltra-M Health Managerの場合と同様に、この状態になります

EM: 1 is not part of HA-CLUSTER,EM is running in standalone mode

バージョンによって異なりますが、システムで稼働するEMは2つまたは3つがあります。

3つのEMを導入している場合、そのうちの2つが機能し、3つ目はZookeeperクラスタを使用できるだけです。ただし、使用されません。

2つの機能EMのいずれかが動作しない場合、または到達不能な場合、動作中のEMはスタンドアロンモードになります。

2つのEMを導入した場合、そのうちの1つが動作していない場合や到達可能でない場合は、残りのEMをスタンドアロンモードにすることができます。

このドキュメントでは、これが発生するかどうかを確認する方法と回復方法について説明します。

トラブルシューティングと回復手順

ステップ1:EMの状態を確認します。

EM VIPに接続し、ノードがこの状態であることを確認します。

root@em-0:~# ncs_cli -u admin -C

admin connected from 127.0.0.1 using console on em-0

admin@scm# show ems

EM VNFM ID SLA SCM PROXY

3 up down up

admin@scm#

ここからは、SCMに1つのエントリしかなく、それがノードのエントリであることがわかります。

他のEMに接続できたら、次のように表示されます。

root@em-1# ncs_cli -u admin -C admin connected from 127.0.0.1 using

admin connected from 127.0.0.1 using console on em-1

admin@scm# show ems

% No entries found.

EMの問題によっては、NCS CLIにアクセスできないか、ノードがリブートしている可能性があります。

ステップ2：クラスタに参加しないノードの/var/log/emのログを確認します。

ノード上のログを問題の状態で確認します。したがって、前述の例では、em-1/var/log/em/zookeeperログに移動します。

...

2018-02-01 09:52:33,591 [myid:4] - INFO [main:QuorumPeerMain@127] - Starting quorum peer

2018-02-01 09:52:33,619 [myid:4] - INFO [main:NIOServerCnxnFactory@89] - binding to port 0.0.0.0/0.0.0.0:2181

2018-02-01 09:52:33,627 [myid:4] - INFO [main:QuorumPeer@1019] - tickTime set to 3000

2018-02-01 09:52:33,628 [myid:4] - INFO [main:QuorumPeer@1039] - minSessionTimeout set to -1

2018-02-01 09:52:33,628 [myid:4] - INFO [main:QuorumPeer@1050] - maxSessionTimeout set to -1

2018-02-01 09:52:33,628 [myid:4] - INFO [main:QuorumPeer@1065] - initLimit set to 5

2018-02-01 09:52:33,641 [myid:4] - INFO [main:FileSnap@83] - Reading snapshot /var/lib/zookeeper/data/version-2/snapshot.5000000b3

2018-02-01 09:52:33,665 [myid:4] - ERROR [main:QuorumPeer@557] - Unable to load database on disk

java.io.IOException: The current epoch, 5, is older than the last zxid, 25769803777

at org.apache.zookeeper.server.quorum.QuorumPeer.loadDataBase(QuorumPeer.java:539)

at org.apache.zookeeper.server.quorum.QuorumPeer.start(QuorumPeer.java:500)

at org.apache.zookeeper.server.quorum.QuorumPeerMain.runFromConfig(QuorumPeerMain.java:153)

at org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:111)

at org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:78)

2018-02-01 09:52:33,671 [myid:4] - ERROR [main:QuorumPeerMain@89] - Unexpected exception, exiting abnormally

java.lang.RuntimeException: Unable to run quorum server

at org.apache.zookeeper.server.quorum.QuorumPeer.loadDataBase(QuorumPeer.java:558)

at org.apache.zookeeper.server.quorum.QuorumPeer.start(QuorumPeer.java:500)

at org.apache.zookeeper.server.quorum.QuorumPeerMain.runFromConfig(QuorumPeerMain.java:153)

at org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:111)

at org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:78)

Caused by: java.io.IOException: The current epoch, 5, is older than the last zxid, 25769803777

at org.apache.zookeeper.server.quorum.QuorumPeer.loadDataBase(QuorumPeer.java:539)

ステップ3：問題のスナップショットが存在することを確認します。

/var/lib/zookeeper/data/version-2に移動し、ステップ2で赤くなっているスナップショットが存在することを確認します。

300000042 log.500000001 snapshot.300000041 snapshot.40000003b

ubuntu@em-1:/var/lib/zookeeper/data/version-2$ ls -la

total 424

drwxrwxr-x 2 zk zk 4096 Jan 30 12:12 .

drwxr-xr-x 3 zk zk 4096 Feb 1 10:33 ..

-rw-rw-r-- 1 zk zk 1 Jan 30 12:12 acceptedEpoch

-rw-rw-r-- 1 zk zk 1 Jan 30 12:09 currentEpoch

-rw-rw-r-- 1 zk zk 1 Jan 30 12:12 currentEpoch.tmp

-rw-rw-r-- 1 zk zk 67108880 Jan 9 20:11 log.300000042

-rw-rw-r-- 1 zk zk 67108880 Jan 30 10:45 log.400000024

-rw-rw-r-- 1 zk zk 67108880 Jan 30 12:09 log.500000001

-rw-rw-r-- 1 zk zk 67108880 Jan 30 12:11 log.5000000b4

-rw-rw-r-- 1 zk zk 69734 Jan 6 05:14 snapshot.300000041

-rw-rw-r-- 1 zk zk 73332 Jan 29 09:21 snapshot.400000023

-rw-rw-r-- 1 zk zk 73877 Jan 30 11:43 snapshot.40000003b

-rw-rw-r-- 1 zk zk 84116 Jan 30 12:09 snapshot.5000000b3 ---> HERE, you see it

ubuntu@em-1:/var/lib/zookeeper/data/version-2$

ステップ4：回復手順

1.デバッグモードを有効にして、EMがリブートを停止するようにします。

ubuntu@em-1:~$ sudo /opt/cisco/em-scripts/enable_debug_mode.sh

VMのリブートが再度必要になる場合があります（自動的に行われます。何も行う必要はありません）。

2.zookeeperデータを移動します。

/var/lib/zookeeper/dataに、DBのスナップショットを持つversion-2というフォルダがあります。上記のエラーは、ロードが失敗して削除されることを示しています。

ubuntu@em-1:/var/lib/zookeeper/data$ sudo mv version-2 old

ubuntu@em-1:/var/lib/zookeeper/data$ ls -la

total 20

....

-rw-r--r-- 1 zk   zk      2 Feb  1 10:33 myid

drwxrwxr-x 2 zk   zk   4096 Jan 30 12:12  old  -->  so you see now old folder and you do not see version-2

-rw-rw-r-- 1 zk   zk      4 Feb  1 10:33 zookeeper_server.pid

..

3.ノードをリブートします。

sudo reboot

4.デバッグモードを無効にします。

ubuntu@em-1:~$ sudo /opt/cisco/em-scripts/disable_debug_mode.sh

これらの手順により、問題のあるEMでサービスが復旧します。