إستبدال اللوحة الأم في خادم Ultra-M UCS 240M4 - CPS

المقدمة

يصف هذا المستند الخطوات المطلوبة لاستبدال لوحة أم معيبة لخادم في إعداد Ultra-M يستضيف وظائف الشبكة الظاهرية (VNF) ل CPS.

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

Ultra-M هو حل أساسي لحزم الأجهزة المحمولة تم تجميعه في حزم مسبقا والتحقق من صحته افتراضيا تم تصميمه من أجل تبسيط نشر شبكات VNF. OpenStack هو مدير البنية الأساسية الظاهرية (VIM) ل Ultra-M ويتكون من أنواع العقد التالية:

• حوسبة
• قرص تخزين الكائنات - الحوسبة (OSD - الحوسبة)
• ضابط
• النظام الأساسي OpenStack - المدير (OSPD)

تم توضيح البنية المعمارية عالية المستوى لتقنية Ultra-M والمكونات المعنية في هذه الصورة:

هذا المستند مخصص لأفراد Cisco المطلعين على نظام Cisco Ultra-M الأساسي وهو يفصل الخطوات المطلوبة ليتم تنفيذها على مستوى OpenStack و StarOS VNF في وقت إستبدال اللوحة الأم في الخادم.

ملاحظة: يتم النظر في الإصدار Ultra M 5.1.x لتحديد الإجراءات الواردة في هذا المستند.

المختصرات

VNF	وظيفة الشبكة الظاهرية
ESC	وحدة التحكم المرنة في الخدمة
ممسحة	طريقة إجرائية
OSD	أقراص تخزين الكائنات
محرك الأقراص الثابتة	محرك الأقراص الثابتة
محرك أقراص مزود بذاكرة مصنوعة من مكونات صلبة	محرك أقراص في الحالة الصلبة
فيم	مدير البنية الأساسية الظاهرية
VM	جهاز ظاهري
إم	مدير العناصر
UAS	خدمات أتمتة Ultra
uID	المعرف الفريد العالمي

سير عمل مذكرة التفاهم

إستبدال اللوحات الأم في إعداد Ultra-M

في الإعداد الفائق متعدد الوظائف، قد تكون هناك سيناريوهات تتطلب إستبدال اللوحة الأم في أنواع الخوادم التالية: الكمبيوتر وحوسبة العناصر التي تعمل بنظام التشغيل OSD ووحدة التحكم.

ملاحظة: يتم إستبدال أقراص التمهيد مع تثبيت OpenStack بعد إستبدال اللوحة الأم. وبالتالي لا يوجد أي متطلبات لإضافة العقدة مرة أخرى إلى السحابة. بمجرد تشغيل الخادم بعد نشاط الاستبدال، فإنه سيقوم بتسجيل نفسه مرة أخرى في مكدس السحابة الزائدة.

إستبدال اللوحات الرئيسية في عقدة الحوسبة

قبل النشاط، يتم إيقاف تشغيل الأجهزة الافتراضية (VM) المستضافة في عقدة "الحوسبة" بشكل جميل. وبمجرد إستبدال اللوحة الأم، تتم إستعادة الأجهزة الافتراضية.

تحديد الأجهزة الافتراضية المستضافة في عقدة الحوسبة

التعرف على الأجهزة الافتراضية (VM) المستضافة على خادم الكمبيوتر.

يحتوي خادم الكمبيوتر على CPS أو وحدة التحكم المرنة في الخدمات (ESC) VMs:

[stack@director ~]$ nova list --field name,host | grep compute-8
| 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea | pod1-compute-8.localdomain     |
| f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229     | pod1-compute-8.localdomain     |
| 75528898-ef4b-4d68-b05d-882014708694 | VNF2-ESC-ESC-0                                             | pod1-compute-8.localdomain     |

ملاحظة:في الإخراج المعروض هنا، يتوافق العمود الأول مع المعرف الفريد العالمي (UUID)، بينما يمثل العمود الثاني اسم معرف فئة المورد (VM) بينما يمثل العمود الثالث اسم المضيف الذي يوجد به معرف فئة المورد (VM). سيتم إستخدام المعلمات من هذا الإخراج في الأقسام التالية.

إيقاف تشغيل الطاقة الرشيقة

عقد الحوسبة تستضيف CPS/ESC VMs

الخطوة 1. قم بتسجيل الدخول إلى عقدة ESC التي تتوافق مع VNF وتحقق من حالة الأجهزة الافتراضية (VMs).

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                    <state>VM_ALIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                    <state>VM_ALIVE_STATE</state>
<deployment_name>VNF2-DEPLOYMENT-em</deployment_name>
                  <vm_id>507d67c2-1d00-4321-b9d1-da879af524f8</vm_id>
                  <vm_id>dc168a6a-4aeb-4e81-abd9-91d7568b5f7c</vm_id>
                  <vm_id>9ffec58b-4b9d-4072-b944-5413bf7fcf07</vm_id>
                <state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea</vm_name>
                    <state>VM_ALIVE_STATE</state>
<snip>

الخطوة 2. أوقف CPS VMs واحدا تلو الآخر باستخدام اسم VM الخاص به. (اسم VM الملاحظ من القسم التعرف على الأجهزة الافتراضية المستضافة في عقدة الحوسبة).

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea

الخطوة 3. بعد توقفها، يجب أن يدخل VMs حالة إيقاف التشغيل.

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                    <state>VM_SHUTOFF_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                    <state>VM_ALIVE_STATE</state>
<deployment_name>VNF2-DEPLOYMENT-em</deployment_name>
                  <vm_id>507d67c2-1d00-4321-b9d1-da879af524f8</vm_id>
                  <vm_id>dc168a6a-4aeb-4e81-abd9-91d7568b5f7c</vm_id>
                  <vm_id>9ffec58b-4b9d-4072-b944-5413bf7fcf07</vm_id>
                <state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea</vm_name>
                    
     
     
       VM_SHUTOFF_STATE 
     
<snip>

الخطوة 4. قم بتسجيل الدخول إلى ESC المستضاف في عقدة الكمبيوتر وتحقق مما إذا كان في الحالة الرئيسية. إذا كانت الإجابة بنعم، فقم بتبديل ESC إلى وضع الاستعداد:

[admin@VNF2-esc-esc-0 esc-cli]$ escadm status
0 ESC status=0 ESC Master Healthy


[admin@VNF2-esc-esc-0 ~]$ sudo service keepalived stop
Stopping keepalived:                                       [  OK  ]

[admin@VNF2-esc-esc-0 ~]$ escadm status
1 ESC status=0 In SWITCHING_TO_STOP state. Please check status after a while.

[admin@VNF2-esc-esc-0 ~]$ sudo reboot
Broadcast message from admin@vnf1-esc-esc-0.novalocal
       (/dev/pts/0) at 13:32 ...
The system is going down for reboot NOW!

النسخ الاحتياطي ل ESC

الخطوة 1. يتميز حل ESC بمعدل تكرار يبلغ 1:1 في حل UltraM. 2 يتم نشر الأجهزة الافتراضية الافتراضية التي تعمل بنظام تصحيح الأخطاء (ESC) وتدعم فشلا واحدا في UltraM، أي يتم إسترداد النظام في حالة حدوث عطل واحد في النظام.

ملاحظة: إذا كان هناك أكثر من فشل واحد، فهو غير مدعوم وقد يتطلب إعادة توزيع النظام.

تفاصيل النسخ الاحتياطي باستخدام حل ESC:

• التكوين الجاري تشغيله
• CONFd CDB
• سجلات ESC
• تكوين Syslog

الخطوة 2. إن معدل تكرار النسخ الاحتياطي باستخدام تقنية ESC DB يعد أمرا صعبا ويحتاج إلى المعالجة بعناية أثناء قيام مركز الأنظمة الإلكترونية (ESC) بمراقبة الأجهزة المختلفة في الحالة والمحافظة عليها من أجل إستخدام العديد من الأجهزة الافتراضية التي تعمل بتقنية VNF. ينصح بإجراء هذه النسخ الاحتياطية بعد متابعة الأنشطة في VNF/POD/Site معين.

الخطوة 3. تحقق من صحة ESC جيدا لاستخدام البرنامج النصي health.sh.

[root@auto-test-vnfm1-esc-0 admin]# escadm status
0 ESC status=0 ESC Master Healthy

[root@auto-test-vnfm1-esc-0 admin]# health.sh
esc ui is disabled -- skipping status check
esc_monitor start/running, process 836
esc_mona is up and running ...
vimmanager start/running, process 2741
vimmanager start/running, process 2741
esc_confd is started
tomcat6 (pid 2907) is running...                           [  OK  ]
postgresql-9.4 (pid  2660) is running...
ESC service is running...
Active VIM = OPENSTACK
ESC Operation Mode=OPERATION

/opt/cisco/esc/esc_database is a mountpoint

============== ESC HA (MASTER) with DRBD =================

DRBD_ROLE_CHECK=0
MNT_ESC_DATABSE_CHECK=0
VIMMANAGER_RET=0
ESC_CHECK=0
STORAGE_CHECK=0
ESC_SERVICE_RET=0
MONA_RET=0
ESC_MONITOR_RET=0

=======================================

ESC HEALTH PASSED

الخطوة 4. قم بإجراء عملية نسخ إحتياطي للتكوين الجاري تشغيله ونقل الملف إلى خادم النسخ الاحتياطي.

[root@auto-test-vnfm1-esc-0 admin]# /opt/cisco/esc/confd/bin/confd_cli -u admin -C

admin connected from 127.0.0.1 using console on auto-test-vnfm1-esc-0.novalocal
auto-test-vnfm1-esc-0# show running-config | save /tmp/running-esc-12202017.cfg
auto-test-vnfm1-esc-0#exit

[root@auto-test-vnfm1-esc-0 admin]# ll /tmp/running-esc-12202017.cfg
-rw-------. 1 tomcat tomcat 25569 Dec 20 21:37 /tmp/running-esc-12202017.cfg

النسخ الاحتياطي لقاعدة بيانات ESC

الخطوة 1. قم بتسجيل الدخول إلى ESC VM وقم بتشغيل هذا الأمر قبل إجراء النسخ الاحتياطي.

[admin@esc ~]# sudo bash
[root@esc ~]# cp /opt/cisco/esc/esc-scripts/esc_dbtool.py /opt/cisco/esc/esc-scripts/esc_dbtool.py.bkup
[root@esc esc-scripts]# sudo sed -i "s,'pg_dump,'/usr/pgsql-9.4/bin/pg_dump," /opt/cisco/esc/esc-scripts/esc_dbtool.py

#Set ESC to mainenance mode
[root@esc esc-scripts]# escadm op_mode set --mode=maintenance

الخطوة 2. تحقق من وضع ESC وتأكد من أنه في وضع الصيانة.

[root@esc esc-scripts]# escadm op_mode show

الخطوة 3. النسخ الاحتياطي لقاعدة البيانات باستخدام أداة إستعادة النسخ الاحتياطي لقاعدة البيانات المتوفرة في ESC.

[root@esc scripts]# sudo /opt/cisco/esc/esc-scripts/esc_dbtool.py backup --file  scp://
     
     
       : 
      
        @ 
       
         : 
         
        
       
     

الخطوة 4. قم بتعيين ESC مرة أخرى إلى وضع العملية وتأكيد الوضع.

[root@esc scripts]# escadm op_mode set --mode=operation

[root@esc scripts]# escadm op_mode show 

الخطوة 5. انتقل إلى دليل البرامج النصية وتجميع السجلات.

[root@esc scripts]# /opt/cisco/esc/esc-scripts

sudo ./collect_esc_log.sh

الخطوة 6. لإنشاء لقطة ل ESC، قم أولا بإيقاف تشغيل ESC.

shutdown -r now

الخطوة 7. من OSPD قم بإنشاء لقطة صورة.

•  nova image-create --poll esc1 esc_snapshot_27aug2018 

الخطوة 8. تحقق من إنشاء اللقطة 

openstack image list | grep esc_snapshot_27aug2018

الخطوة 9. بدء تشغيل ESC من OSPD 

nova start esc1 

الخطوة 10. كرر نفس الإجراء على ESC VM في وضع الاستعداد ونقل السجلات إلى خادم النسخ الاحتياطي.

الخطوة 11. قم بتجميع النسخ الاحتياطي لتكوين syslog على كل من ESC VMS ونقلها إلى خادم النسخ الاحتياطي.

[admin@auto-test-vnfm2-esc-1 ~]$ cd /etc/rsyslog.d
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/00-escmanager.conf
00-escmanager.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/01-messages.conf
01-messages.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/02-mona.conf
02-mona.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.conf
rsyslog.conf

استبدل اللوحة الأم

الخطوة 1. يمكن الرجوع إلى الخطوات المتعلقة باستبدال اللوحة الأم في خادم UCS C240 M4 من:

دليل خدمة وتثبيت الخادم Cisco UCS C240 M4

الخطوة 2. قم بتسجيل الدخول إلى الخادم باستخدام CIMC IP.

الخطوة 3. قم بإجراء ترقية BIOS إذا لم تكن البرامج الثابتة متوافقة مع الإصدار الموصى به المستخدم سابقا. تم تقديم خطوات تحديث BIOS هنا:

دليل ترقية BIOS الخاص بالخادم المركب على حامل Cisco UCS C-Series

إستعادة الأجهزة الافتراضية

Compute Node يستضيف CPS و ESC

إسترداد ESC VM

الخطوة 1. يكون ESC VM قابلا للاسترداد إذا كان VM في حالة خطأ أو في حالة إيقاف التشغيل فعليك بإجراء إعادة تمهيد ثابت لإظهار VM المتأثر. قم بتشغيل هذه الخطوات لاستعادة ESC.

الخطوة 2. تعرف على الجهاز الظاهري (VM) الذي يكون في حالة الخطأ أو حالة إيقاف التشغيل، بمجرد التعرف على إعادة تمهيد ESC VM بشكل ثابت. في هذا المثال، قم بإعادة تمهيد الاختبار التلقائي-vnfm1-ESC-0.

[root@tb1-baremetal scripts]# nova list | grep auto-test-vnfm1-ESC-

| f03e3cac-a78a-439f-952b-045aea5b0d2c | auto-test-vnfm1-ESC-0                                       | ACTIVE | -          | running     | auto-testautovnf1-uas-orchestration=172.57.12.11; auto-testautovnf1-uas-management=172.57.11.3                                                                                      |
| 79498e0d-0569-4854-a902-012276740bce | auto-test-vnfm1-ESC-1                                       | ACTIVE | -          | running     | auto-testautovnf1-uas-orchestration=172.57.12.15; auto-testautovnf1-uas-management=172.57.11.5                                                                                      |

[root@tb1-baremetal scripts]# [root@tb1-baremetal scripts]# nova reboot --hard f03e3cac-a78a-439f-952b-045aea5b0d2c\
Request to reboot server <Server: auto-test-vnfm1-ESC-0> has been accepted.

[root@tb1-baremetal scripts]#

الخطوة 3. إذا تم حذف ESC VM ويجب إعادة طرحه. 

[stack@pod1-ospd scripts]$ nova list |grep ESC-1
| c566efbf-1274-4588-a2d8-0682e17b0d41 | vnf1-ESC-ESC-1                                                 | ACTIVE | -          | running     | vnf1-UAS-uas-orchestration=172.168.11.14; vnf1-UAS-uas-management=172.168.10.4                                                                                                 |

[stack@pod1-ospd scripts]$ nova delete vnf1-ESC-ESC-1
Request to delete server vnf1-ESC-ESC-1 has been accepted.

الخطوة 4. من OSPD، تحقق من أن ESC VM الجديد نشط/قيد التشغيل:

[stack@pod1-ospd ~]$ nova list|grep -i esc
| 934519a4-d634-40c0-a51e-fc8d55ec7144 | vnf1-ESC-ESC-0                                                 | ACTIVE | -          | running     | vnf1-UAS-uas-orchestration=172.168.11.13; vnf1-UAS-uas-management=172.168.10.3                                                                                                 |
| 2601b8ec-8ff8-4285-810a-e859f6642ab6 | vnf1-ESC-ESC-1                                                 | ACTIVE | -          | running     | vnf1-UAS-uas-orchestration=172.168.11.14; vnf1-UAS-uas-management=172.168.10.6                                                                                                 |

#Log in to new ESC and verify Backup state.  You may execute health.sh on ESC Master too.

…
   ####################################################################
   #   ESC on vnf1-esc-esc-1.novalocal is in BACKUP state.
   ####################################################################

[admin@esc-1 ~]$ escadm status
0 ESC status=0 ESC Backup Healthy

[admin@esc-1 ~]$ health.sh
============== ESC HA (BACKUP) =================
=======================================

ESC HEALTH PASSED
[admin@esc-1 ~]$ cat /proc/drbd
version: 8.4.7-1 (api:1/proto:86-101)
GIT-hash: 3a6a769340ef93b1ba2792c6461250790795db49 build by mockbuild@Build64R6, 2016-01-12 13:27:11
 1: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
    ns:0 nr:504720 dw:3650316 dr:0 al:8 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

الخطوة 5. إذا كان ESC VM غير قابل للاسترداد ويتطلب إستعادة قاعدة البيانات، فيرجى إستعادة قاعدة البيانات من النسخة الاحتياطية التي تم الحصول عليها مسبقا.

الخطوة 6. بالنسبة لاستعادة قاعدة بيانات ESC، علينا التأكد من إيقاف خدمة ESC قبل إستعادة قاعدة البيانات، وبالنسبة ل ESC HA، قم بالتنفيذ في الجهاز الظاهري الثانوي أولا ثم الجهاز الظاهري الرئيسي.

# service keepalived stop

الخطوة 7. تحقق من حالة خدمة ESC وتأكد من إيقاف كل شيء في الأجهزة الافتراضية الأساسية والثانوية للحصول على HA

# escadm status

الخطوة 8. قم بتنفيذ البرنامج النصي لاستعادة قاعدة البيانات. وكجزء من إستعادة قاعدة بيانات المحول (DB) إلى مثيل ESC الذي تم إنشاؤه حديثا، ستعمل الأداة أيضا على ترقية أحد المثيلات لتصبح ESC أساسي، وتحميل مجلد قاعدة البيانات (DB) الخاص بها إلى الجهاز DRBD، كما ستقوم ببدء تشغيل قاعدة بيانات PostGreSQL.

# /opt/cisco/esc/esc-scripts/esc_dbtool.py restore --file scp://
     
     
       : 
      
        @ 
       
         : 
         
        
       
     

الخطوة 9. قم بإعادة تشغيل خدمة ESC لإكمال إستعادة قاعدة البيانات.

بالنسبة إلى HA التي يتم تنفيذها في كلا الجهازين VM، قم بإعادة تشغيل خدمة keepalived

# service keepalived start

الخطوة 10. بمجرد إستعادة VM وتشغيله بنجاح، تأكد من إستعادة جميع التكوين المحدد syslog من النسخ الاحتياطي السابق المعروف. تأكد من استعادته في جميع الأجهزة الافتراضية (ESC)

[admin@auto-test-vnfm2-esc-1 ~]$
[admin@auto-test-vnfm2-esc-1 ~]$ cd /etc/rsyslog.d
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/00-escmanager.conf
00-escmanager.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/01-messages.conf
01-messages.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/02-mona.conf
02-mona.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.conf
rsyslog.conf

الخطوة 11. إذا كان يجب إعادة إنشاء ESC من لقطة OSPD، فاستخدم الأمر التالي باستخدام اللقطة التي تم التقاطها أثناء النسخ الاحتياطي.

nova rebuild --poll --name esc_snapshot_27aug2018 esc1

الخطوة 12. تحقق من حالة ESC بعد اكتمال عملية إعادة الإنشاء.

nova list --fileds name,host,status,networks | grep esc

الخطوة 13. تحقق من صحة ESC باستخدام الأمر التالي.

health.sh

Copy Datamodel to a backup file
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata > /tmp/esc_opdata_`date +%Y%m%d%H%M%S`.txt

إستعادة الأجهزة الافتراضية من CPS

سيكون CPS VM في حالة خطأ في قائمة نوفا:

[stack@director  ~]$ nova list |grep VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
| 49ac5f22-469e-4b84-badc-031083db0533 | VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d     | ERROR  | -          | NOSTATE     | 

إستردت ال CPS VM من ال esc:

[admin@VNF2-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
[sudo] password for admin: 

Recovery VM Action
/opt/cisco/esc/confd/bin/netconf-console --port=830 --host=127.0.0.1 --user=admin --privKeyFile=/root/.ssh/confd_id_dsa --privKeyType=dsa --rpc=/tmp/esc_nc_cli.ZpRCGiieuW
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <ok/>
</rpc-reply>

راقبت الموقع winesc.log:

admin@VNF2-esc-esc-0 ~]$ tail -f /var/log/esc/yangesc.log
…
14:59:50,112 07-Nov-2017 WARN  Type: VM_RECOVERY_COMPLETE
14:59:50,112 07-Nov-2017 WARN  Status: SUCCESS
14:59:50,112 07-Nov-2017 WARN  Status Code: 200
14:59:50,112 07-Nov-2017 WARN  Status Msg: Recovery: Successfully recovered VM [VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d].

عند فشل ESC في بدء تشغيل VM

الخطوة 1. في بعض الحالات، سيفشل مركز الأنظمة الإلكترونية في بدء تشغيل الجهاز الظاهري (VM) بسبب حالة غير متوقعة. الحل البديل هو تنفيذ تحويل ESC من خلال إعادة تشغيل ESC الرئيسي. ستستغرق عملية التبديل ESC حوالي دقيقة.  قم بتنفيذ health.sh على Master ESC الجديد للتحقق من أنه قيد التشغيل. عندما يصبح ESC رئيسيا، يمكن أن يقوم ESC بإصلاح حالة VM وبدء تشغيل VM. بما أن هذه العملية مجدولة، يجب الانتظار 5-7 دقائق حتى تكتمل.

الخطوة 2. يمكنك مراقبة /var/log/esc/yangesc.log و /var/log/esc/escmanager.log. إذا لم يظهر لديك الجهاز الظاهري الذي تم إسترداده بعد 5 إلى 7 دقائق، فسيحتاج المستخدم إلى الذهاب وإجراء عملية الاسترداد اليدوي للأجهزة الافتراضية (الأجهزة الافتراضية) المتأثرة.

الخطوة 3. بمجرد إستعادة VM وتشغيله بنجاح، تأكد من إستعادة جميع التكوين المحدد syslog من النسخ الاحتياطي السابق المعروف. تأكد من استعادته في جميع الأجهزة الافتراضية (ESC).

root@autotestvnfm1esc2:/etc/rsyslog.d# pwd
/etc/rsyslog.d

root@autotestvnfm1esc2:/etc/rsyslog.d# ll

total 28
drwxr-xr-x  2 root root 4096 Jun  7 18:38 ./
drwxr-xr-x 86 root root 4096 Jun  6 20:33 ../]
-rw-r--r--  1 root root  319 Jun  7 18:36 00-vnmf-proxy.conf
-rw-r--r--  1 root root  317 Jun  7 18:38 01-ncs-java.conf
-rw-r--r--  1 root root  311 Mar 17  2012 20-ufw.conf
-rw-r--r--  1 root root  252 Nov 23  2015 21-cloudinit.conf
-rw-r--r--  1 root root 1655 Apr 18  2013 50-default.conf

root@abautotestvnfm1em-0:/etc/rsyslog.d# ls /etc/rsyslog.conf
rsyslog.conf

إستبدال اللوحات الأم في عقدة حوسبة OSD

قبل النشاط، يتم إيقاف تشغيل الأجهزة الظاهرية (VM) المستضافة في عقدة "الحوسبة" بشكل جيد ويتم وضع CEPH في وضع الصيانة. وبمجرد إستبدال اللوحة الأم، تتم إستعادة الأجهزة الافتراضية (VM) ويتم نقل وضع CEPH خارج وضع الصيانة.

وضع CEPH في وضع الصيانة

الخطوة 1. التحقق من حالة شجرة الإعداد في الخادم

[heat-admin@pod1-osd-compute-1 ~]$ sudo ceph osd tree

ID WEIGHT   TYPE NAME                         UP/DOWN REWEIGHT PRIMARY-AFFINITY

-1 13.07996 root default
-2  4.35999     host pod1-osd-compute-0
 0  1.09000         osd.0                          up  1.00000          1.00000
 3  1.09000         osd.3                          up 1.00000          1.00000
 6  1.09000         osd.6                          up  1.00000          1.00000
 9  1.09000         osd.9                          up  1.00000          1.00000

-3  4.35999     host pod1-osd-compute-2
 1  1.09000        osd.1                          up  1.00000          1.00000
 4  1.09000         osd.4                          up  1.00000          1.00000
 7  1.09000         osd.7                          up  1.00000          1.00000
10  1.09000         osd.10                         up  1.00000          1.00000

-4  4.35999     host pod1-osd-compute-1
 2  1.09000         osd.2                          up  1.00000          1.00000
 5  1.09000         osd.5                          up  1.00000          1.00000
 8  1.09000         osd.8                          up  1.00000          1.00000
11  1.09000         osd.11                         up  1.00000          1.00000 

الخطوة 2. سجل الدخول إلى عقدة حوسبة OSD ووضع CEPH في وضع الصيانة.

[root@pod1-osd-compute-1 ~]# sudo ceph osd set norebalance
[root@pod1-osd-compute-1 ~]# sudo ceph osd set noout

[root@pod1-osd-compute-1 ~]# sudo ceph status

 cluster eb2bb192-b1c9-11e6-9205-525400330666
 health HEALTH_WARN
 noout,norebalance,sortbitwise,require_jewel_osds flag(s) set
 monmap e1: 3 mons at {pod1-controller-0=11.118.0.40:6789/0,pod1-controller-1=11.118.0.41:6789/0,pod1-controller-2=11.118.0.42:6789/0}
 election epoch 58, quorum 0,1,2 pod1-controller-0,pod1-controller-1,pod1-controller-2
 osdmap e194: 12 osds: 12 up, 12 in
 flags noout,norebalance,sortbitwise,require_jewel_osds
 pgmap v584865: 704 pgs, 6 pools, 531 GB data, 344 kobjects
 1585 GB used, 11808 GB / 13393 GB avail
 704 active+clean
 client io 463 kB/s rd, 14903 kB/s wr, 263 op/s rd, 542 op/s wr

ملاحظة: عند إزالة CEPH، يخضع RAID VNF HD إلى الحالة المخفضة ولكن يجب الوصول إلى القرص الثابت

تحديد الأجهزة الافتراضية المستضافة في عقدة حوسبة OSD

التعرف على الأجهزة الافتراضية (VM) المستضافة على خادم حوسبة OSD.

يحتوي خادم الحوسبة على وحدة التحكم المرنة في الخدمات (ESC) أو CPS VMs

[stack@director ~]$ nova list --field name,host | grep osd-compute-1
| 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea   | pod1-compute-8.localdomain     |
| f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229     | pod1-compute-8.localdomain     |
| 75528898-ef4b-4d68-b05d-882014708694 | VNF2-ESC-ESC-0                                             | pod1-compute-8.localdomain     |
| f5bd7b9c-476a-4679-83e5-303f0aae9309 | VNF2-UAS-uas-0                                             | pod1-compute-8.localdomain     |

ملاحظة: في الإخراج المبين هنا، يتوافق العمود الأول مع المعرف الفريد العالمي (UUID)، بينما يمثل العمود الثاني اسم الجهاز الظاهري (VM) بينما يمثل العمود الثالث اسم المضيف الذي يوجد به الجهاز الظاهري. سيتم إستخدام المعلمات من هذا الإخراج في الأقسام التالية.

إيقاف تشغيل الطاقة الرشيقة

القضية 1. عقد OSD-Compute تستضيف ESC

إجراء تشغيل الأجهزة الافتراضية (VMs) باستخدام ESC أو CPS بشكل جيد هو نفسه بغض النظر عما إذا كان قد تم إستضافة الأجهزة الافتراضية (VMs) في عقدة Compute أو OSD-Compute.

اتبع الخطوات التي تبدأ من "إستبدال اللوحة الأم في عقدة الحوسبة" للتخلص من الأجهزة الافتراضية بسهولة تامة.

استبدل اللوحة الأم

الخطوة 1. يمكن الرجوع إلى الخطوات المتعلقة باستبدال اللوحة الأم في خادم UCS C240 M4 من:

دليل خدمة وتثبيت الخادم Cisco UCS C240 M4

الخطوة 2. تسجيل الدخول إلى الخادم باستخدام CIMC IP

3. قم بإجراء ترقية BIOS إذا لم تكن البرامج الثابتة متوافقة مع الإصدار الموصى به المستخدم سابقا. تم تقديم خطوات تحديث BIOS هنا:

دليل ترقية BIOS الخاص بالخادم المركب على حامل Cisco UCS C-Series

نقل CEPH خارج وضع الصيانة

قم بتسجيل الدخول إلى عقدة حوسبة OSD ونقل CEPH خارج وضع الصيانة.

[root@pod1-osd-compute-1 ~]# sudo ceph osd unset norebalance
[root@pod1-osd-compute-1 ~]# sudo ceph osd unset noout

[root@pod1-osd-compute-1 ~]# sudo ceph status

 cluster eb2bb192-b1c9-11e6-9205-525400330666
 health HEALTH_OK
 monmap e1: 3 mons at {pod1-controller-0=11.118.0.40:6789/0,pod1-controller-1=11.118.0.41:6789/0,pod1-controller-2=11.118.0.42:6789/0}
 election epoch 58, quorum 0,1,2 pod1-controller-0,pod1-controller-1,pod1-controller-2
 osdmap e196: 12 osds: 12 up, 12 in
 flags sortbitwise,require_jewel_osds
 pgmap v584954: 704 pgs, 6 pools, 531 GB data, 344 kobjects
 1585 GB used, 11808 GB / 13393 GB avail
 704 active+clean
 client io 12888 kB/s wr, 0 op/s rd, 81 op/s wr

إستعادة الأجهزة الافتراضية

القضية 1. عقدة OSD-Compute التي تستضيف ESC أو CPS VMs

إجراء إستعادة الأجهزة الافتراضية (VMs) التي تعمل بتقنية CF/ESC/EM/UAS هو نفسه بغض النظر عما إذا كان قد تم إستضافة الأجهزة الافتراضية (VMs) في عقدة Compute أو OSD-Compute.

اتبع الخطوات من "الحالة 2". تستضيف عقدة الحوسبة CF/ESC/EM/UAS لاستعادة الأجهزة الافتراضية.

إستبدال اللوحة الأم في عقدة وحدة التحكم

التحقق من حالة وحدة التحكم ووضع نظام المجموعة في وضع الصيانة

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

[heat-admin@pod1-controller-0 ~]$ sudo pcs status
Cluster name: tripleo_cluster
Stack: corosync
Current DC: pod1-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
Last updated: Mon Dec 4 00:46:10 2017 Last change: Wed Nov 29 01:20:52 2017 by hacluster via crmd on pod1-controller-0

3 nodes and 22 resources configured

Online: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

Full list of resources:

ip-11.118.0.42 (ocf::heartbeat:IPaddr2): Started pod1-controller-1
 ip-11.119.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2
 ip-11.120.0.49 (ocf::heartbeat:IPaddr2): Started pod1-controller-1
 ip-192.200.0.102 (ocf::heartbeat:IPaddr2): Started pod1-controller-2
 Clone Set: haproxy-clone [haproxy]
 Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]
 Master/Slave Set: galera-master [galera]
 Masters: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]
 ip-11.120.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2
 Clone Set: rabbitmq-clone [rabbitmq]
 Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]
 Master/Slave Set: redis-master [redis]
 Masters: [ pod1-controller-2 ]
 Slaves: [ pod1-controller-0 pod1-controller-1 ]
 ip-10.84.123.35 (ocf::heartbeat:IPaddr2): Started pod1-controller-1
 openstack-cinder-volume (systemd:openstack-cinder-volume): Started pod1-controller-2
 my-ipmilan-for-controller-0 (stonith:fence_ipmilan): Started pod1-controller-0
 my-ipmilan-for-controller-1 (stonith:fence_ipmilan): Started pod1-controller-0
 my-ipmilan-for-controller-2 (stonith:fence_ipmilan): Started pod1-controller-0

Daemon Status:
 corosync: active/enabled
 pacemaker: active/enabled
 pcsd: active/enabled

ضع نظام المجموعة في وضع الصيانة.

[heat-admin@pod1-controller-0 ~]$ sudo pcs cluster standby

[heat-admin@pod1-controller-0 ~]$ sudo pcs status
Cluster name: tripleo_cluster
Stack: corosync
Current DC: pod1-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
Last updated: Mon Dec 4 00:48:24 2017 Last change: Mon Dec 4 00:48:18 2017 by root via crm_attribute on pod1-controller-0

3 nodes and 22 resources configured

Node pod1-controller-0: standby
Online: [ pod1-controller-1 pod1-controller-2 ]

Full list of resources:

ip-11.118.0.42 (ocf::heartbeat:IPaddr2): Started pod1-controller-1
 ip-11.119.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2
 ip-11.120.0.49 (ocf::heartbeat:IPaddr2): Started pod1-controller-1
 ip-192.200.0.102 (ocf::heartbeat:IPaddr2): Started pod1-controller-2
 Clone Set: haproxy-clone [haproxy]
 Started: [ pod1-controller-1 pod1-controller-2 ]
 Stopped: [ pod1-controller-0 ]
 Master/Slave Set: galera-master [galera]
 Masters: [ pod1-controller-1 pod1-controller-2 ]
 Slaves: [ pod1-controller-0 ]
 ip-11.120.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2
 Clone Set: rabbitmq-clone [rabbitmq]
 Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]
 Master/Slave Set: redis-master [redis]
 Masters: [ pod1-controller-2 ]
 Slaves: [ pod1-controller-1 ]
 Stopped: [ pod1-controller-0 ]
 ip-10.84.123.35 (ocf::heartbeat:IPaddr2): Started pod1-controller-1

 openstack-cinder-volume (systemd:openstack-cinder-volume): Started pod1-controller-2
 my-ipmilan-for-controller-0 (stonith:fence_ipmilan): Started pod1-controller-1
 my-ipmilan-for-controller-1 (stonith:fence_ipmilan): Started pod1-controller-1
 my-ipmilan-for-controller-2 (stonith:fence_ipmilan): Started pod1-controller-2

استبدل اللوحة الأم

الخطوة 1. يمكن الرجوع إلى الخطوات المتعلقة باستبدال اللوحة الأم في خادم UCS C240 M4 من:

دليل خدمة وتثبيت الخادم Cisco UCS C240 M4

الخطوة 2. قم بتسجيل الدخول إلى الخادم باستخدام CIMC IP.

الخطوة 3. قم بإجراء ترقية BIOS إذا لم تكن البرامج الثابتة متوافقة مع الإصدار الموصى به المستخدم سابقا. تم تقديم خطوات تحديث BIOS هنا:

دليل ترقية BIOS الخاص بالخادم المركب على حامل Cisco UCS C-Series

إستعادة حالة نظام المجموعة

سجل الدخول إلى وحدة التحكم المتأثرة، وقم بإزالة وضع الاستعداد عن طريق إعداد غير الاستعداد. تحقق من أن وحدة التحكم تأتي عبر الإنترنت مزودة بنظام المجموعة ويظهر برنامج Galera وحدات التحكم الثلاث جميعها كوحدات تحكم رئيسية. قد يستغرق ذلك بضع دقائق.

[heat-admin@pod1-controller-0 ~]$ sudo pcs cluster unstandby

[heat-admin@pod1-controller-0 ~]$ sudo pcs status
Cluster name: tripleo_cluster
Stack: corosync
Current DC: pod1-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
Last updated: Mon Dec 4 01:08:10 2017 Last change: Mon Dec 4 01:04:21 2017 by root via crm_attribute on pod1-controller-0

3 nodes and 22 resources configured

Online: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

Full list of resources:

ip-11.118.0.42 (ocf::heartbeat:IPaddr2): Started pod1-controller-1
 ip-11.119.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2
 ip-11.120.0.49 (ocf::heartbeat:IPaddr2): Started pod1-controller-1
 ip-192.200.0.102 (ocf::heartbeat:IPaddr2): Started pod1-controller-2
 Clone Set: haproxy-clone [haproxy]
 Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]
 Master/Slave Set: galera-master [galera]
 Masters: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]
 ip-11.120.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2
 Clone Set: rabbitmq-clone [rabbitmq]
 Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]
 Master/Slave Set: redis-master [redis]
 Masters: [ pod1-controller-2 ]
 Slaves: [ pod1-controller-0 pod1-controller-1 ]
 ip-10.84.123.35 (ocf::heartbeat:IPaddr2): Started pod1-controller-1
 openstack-cinder-volume (systemd:openstack-cinder-volume): Started pod1-controller-2
 my-ipmilan-for-controller-0 (stonith:fence_ipmilan): Started pod1-controller-1
 my-ipmilan-for-controller-1 (stonith:fence_ipmilan): Started pod1-controller-1
 my-ipmilan-for-controller-2 (stonith:fence_ipmilan): Started pod1-controller-2

Daemon Status:
 corosync: active/enabled
 pacemaker: active/enabled
 pcsd: active/enable