المحتويات

المقدمة

المتطلبات الأساسية

المتطلبات

المكونات المستخدمة

معلومات أساسية

المختصرات

مدير العناصر الفائقة بعد إصدار Ultra 6.3 - تغييرات البنية

عدد مثيلات UEM VM قابلة للتكوين اعتبارا من الإصدار 6.3

توزيع ZooKeeper

تقديم لوحة كيبالم للهكتار

فصل SCM من عملية NCS

يتم تشغيل خدمة EM على العقدة الرئيسية فقط

خطوات أستكشاف المشكلات المتعلقة بإدارة العناصر وإصلاحها

إعداد UEM باستخدام 2 VM - تسلسل بدء التشغيل للعملية وموقع السجل

إعداد UEM باستخدام 3 أجهزة افتراضية (VM) - تسلسل بدء التشغيل للعملية وموقع السجل

ملخص عمليات UEM

المقدمة

يصف هذا المستند التغييرات التي تم إدخالها في بنية مدير العناصر (EM) كجزء من إصدار 6.3 UltraM.

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

- ستارو

- البنية الأساسية Ultra-M

المكونات المستخدمة

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.

معلومات أساسية

قبل الإصدار Ultra 6.3، كان من الضروري لبرنامج Ultra Element Manager أن يعمل إنشاء 3 أجهزة UEM VM.  لم يكن النوع الثالث قيد الاستخدام وكان هناك للمساعدة في تشكيل مجموعة ZooKeeper. اعتبارا من إصدار 6.3، تغير هذا التصميم.

المختصرات

المختصرات المستخدمة في هذه المقالة:

VNF

وظيفة الشبكة الظاهرية

سي إف

دالة التحكم

SF

وظيفة الخدمة

ESC

وحدة التحكم المرنة في الخدمة

فيم

مدير البنية الأساسية الظاهرية

VM

جهاز ظاهري

إم

مدير العناصر

UAS

خدمات أتمتة Ultra

uID

المعرف الفريد العالمي

زد ك

حارس حديقة الحيوانات

مدير العناصر الفائقة بعد إصدار Ultra 6.3 - تغييرات البنية

يصف هذا المستند التغييرات الخمسة التالية التي يتم تقديمها كجزء من إصدار 6.3 UltraM:

عدد مثيلات UEM VM قابلة للتكوين اعتبارا من الإصدار 6.3

قبل الإصدار 6.3، كان عدد أجهزة UEM 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 |

| 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

...

بغض النظر عن عدد المثيلات المحددة في هذا الأمر، فإن عدد مرات SPUN VM كان دائما 3. بمعنى آخر، تم تجاهل قيمة عدد المثيلات.

اعتبارا من 6.3، يتم تغيير هذا - يمكن أن تكون القيمة التي تم تكوينها 2 أو 3.

عندما تقوم بتكوين 2، يتم إنشاء 2 UEM VMs.

عندما يشكل أنت 3، ال 3 UEM VMs خلقت.

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 ظل على حاله. أن، في em جزء من ال config (vnf.conf مبرد) ال 3 عنوان بعد إلزامي:

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. على الرغم من أن المثيل الثالث لم يتم إستخدامه بفاعلية، فإن IP الثالث يتم تخصيصه للمثيل الثالث، أو ما يسمى Arbiter ZK (راجع Diff.2 للحصول على مزيد من الإيضاح).

وما تأثير ذلك في شبكة التنظير؟

سيكون هناك دائما 3 منافذ خلقت في شبكة التزامن (أن يربط ال 3 ذكر عنوان).

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

ولم يتغير هذا الشرط. ومع ذلك، بالنسبة للمواقع التي يتم فيها إستخدام جهازي UEM VM، يتم إستضافة مثيل ZK ثالث على نفس مجموعة الأجهزة الافتراضية:

قبل 6. 3 وبعد 6. 3 في إعداد مزود ب 3 أجهزة UEM VM:

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

تقديم لوحة كيبالم للهكتار

مع الإصدارات السابقة، يتم إستخدام إطار إختيار زعيم ZK لتحديد Master EM. لم يعد هذا هو الحال كما انتقلت Cisco إلى إطار عمل keepalived.

ما هو الابط وكيف يعمل؟

Keeplaived هو برنامج قائم على لينكس يستخدم لموازنة الأحمال والتوفر العالي لنظام لينوكس والبنية التحتية القائمة على لينوكس.

وهو يستخدم بالفعل في ESC ل HA.

في EM، يستخدم Keepalived لفصل NCS عن حالة نظام مجموعة Zk.

يتم تشغيل العملية Keepalived فقط على المثالين الأولين من EM وستحدد الحالة الرئيسية لعملية NCS.

To check if the keepalived process is running:

ps -aef | grep keepalived

(must return the process ID)

لماذا التغيير؟

في عملية تنفيذ سابقة، تم دمج تحديد العقدة الرئيسية (NCS/SCM) بشكل وثيق مع حالة مجموعة Zk (تم إختيار المثيل الأول الذي تم تأمينه على /em في قاعدة بيانات Zk كقاعدة بيانات رئيسية). يؤدي هذا إلى حدوث مشاكل عندما تفقد شركة Zk الاتصال بالمجموعة.

يتم إستخدام Keepalived للحفاظ على مجموعة UEM النشطة/الاحتياطية على أساس VM.

تحافظ NCS على بيانات التكوين.

يحتفظ برنامج حماية الحيوان ببيانات التشغيل.

فصل 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 تعمل على كل من Master/Slave. اعتبارا من 6.3 يتم تشغيل الخدمات على العقدة الرئيسية فقط. سيؤثر هذا على الإخراج المعروض في show ems. اعتبارا من 6.3، من المتوقع أن ترى عقدة (أساسية) واحدة فقط باستخدام هذا الأمر، بمجرد تسجيل الدخول إلى واجهة سطر أوامر UEM:

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

خطوات أستكشاف المشكلات المتعلقة بإدارة العناصر وإصلاحها

أثناء بدء التشغيل، هذا هو تسلسل بدء التشغيل:

إعداد UEM باستخدام 2 VM - تسلسل بدء التشغيل للعملية وموقع السجل

الوحدة الرئيسية لمصنعي الأجهزة الأصلية:

- رقيق

- حارس حدائق حيوانات

- NCS

- هيئة تحكيم (رقم 3)

- VNFM-Proxy

- SCM

- SLA

شركة Slave UEM:

- رقيق

- حارس حدائق حيوانات

- NCS

إعداد UEM باستخدام 3 أجهزة افتراضية (VM) - تسلسل بدء التشغيل للعملية وموقع السجل

الوحدة الرئيسية لمصنعي الأجهزة الأصلية:

- رقيق

- حارس حدائق حيوانات

- NCS

- VNFM-Proxy

- SCM

- SLA

شركة Slave UEM:

- رقيق

- حارس حدائق حيوانات

- NCS

الجيل الثالث من مصنعي المعدات الأصلية:

- حارس حدائق حيوانات

ملخص عمليات UEM

هذا هو ملخص عمليات UEM التي يجب عليك تشغيلها.

يمكنك التحقق من الحالة باستخدام PS -AEF | GREP XX

رقيق

وسيط

SCM

إتفاقية مستوى الخدمة

حديقة الحيوانات.cfg

ncs

يمكنك التحقق من الحالة باستخدام حالة XX للخدمة، حيث xx:

حافظ حيوانات وسيط

وكيل

SCM

إتفاقية مستوى الخدمة

زكا

ncs