المحتويات

المقدمة

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

المختصرات

إجراء النسخ الاحتياطي

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

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

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

إجراء الاستعادة

إسترداد OSPD

ESC إستعادة

إسترداد CPS

المقدمة

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

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

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

- وحدة التحكم المرنة في الخدمات (ESC)

- مجموعة سياسات Cisco (CPS)

كما هو موضح في هذه الصورة، البنية عالية المستوى للطراز Ultra-M والمكونات المعنية.

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

المختصرات

VNF

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

ESC

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

ممسحة

طريقة إجرائية

OSD

أقراص تخزين الكائنات

محرك الأقراص الثابتة

محرك الأقراص الثابتة

محرك أقراص مزود بذاكرة مصنوعة من مكونات صلبة

محرك أقراص في الحالة الصلبة

فيم

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

VM

جهاز ظاهري

uID

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

إجراء النسخ الاحتياطي

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

1. تحقق من حالة مكدس OpenStack وقائمة العقد.

[stack@director ~]$ source stackrc

[stack@director ~]$ openstack stack list --nested

[stack@director ~]$ ironic node-list

[stack@director ~]$ nova list

2. تحقق مما إذا كانت جميع خدمات الشبكة الفرعية في حالة تحميل ونشاط وتشغيل من عقدة OSP-D.

[stack@director ~]$ systemctl list-units "openstack*" "neutron*" "openvswitch*"

UNIT                                       LOAD   ACTIVE SUB     DESCRIPTION

neutron-dhcp-agent.service                 loaded active running OpenStack Neutron DHCP Agent

neutron-openvswitch-agent.service          loaded active running OpenStack Neutron Open vSwitch Agent

neutron-ovs-cleanup.service                loaded active exited  OpenStack Neutron Open vSwitch Cleanup Utility

neutron-server.service                     loaded active running OpenStack Neutron Server

openstack-aodh-evaluator.service           loaded active running OpenStack Alarm evaluator service

openstack-aodh-listener.service            loaded active running OpenStack Alarm listener service

openstack-aodh-notifier.service            loaded active running OpenStack Alarm notifier service

openstack-ceilometer-central.service       loaded active running OpenStack ceilometer central agent

openstack-ceilometer-collector.service     loaded active running OpenStack ceilometer collection service

openstack-ceilometer-notification.service  loaded active running OpenStack ceilometer notification agent

openstack-glance-api.service               loaded active running OpenStack Image Service (code-named Glance) API server

openstack-glance-registry.service          loaded active running OpenStack Image Service (code-named Glance) Registry server

openstack-heat-api-cfn.service             loaded active running Openstack Heat CFN-compatible API Service

openstack-heat-api.service                 loaded active running OpenStack Heat API Service

openstack-heat-engine.service              loaded active running Openstack Heat Engine Service

openstack-ironic-api.service               loaded active running OpenStack Ironic API service

openstack-ironic-conductor.service         loaded active running OpenStack Ironic Conductor service

openstack-ironic-inspector-dnsmasq.service loaded active running PXE boot dnsmasq service for Ironic Inspector

openstack-ironic-inspector.service         loaded active running Hardware introspection service for OpenStack Ironic

openstack-mistral-api.service              loaded active running Mistral API Server

openstack-mistral-engine.service           loaded active running Mistral Engine Server

openstack-mistral-executor.service         loaded active running Mistral Executor Server

openstack-nova-api.service                 loaded active running OpenStack Nova API Server

openstack-nova-cert.service                loaded active running OpenStack Nova Cert Server

openstack-nova-compute.service             loaded active running OpenStack Nova Compute Server

openstack-nova-conductor.service           loaded active running OpenStack Nova Conductor Server

openstack-nova-scheduler.service           loaded active running OpenStack Nova Scheduler Server

openstack-swift-account-reaper.service     loaded active running OpenStack Object Storage (swift) - Account Reaper

openstack-swift-account.service            loaded active running OpenStack Object Storage (swift) - Account Server

openstack-swift-container-updater.service  loaded active running OpenStack Object Storage (swift) - Container Updater

openstack-swift-container.service          loaded active running OpenStack Object Storage (swift) - Container Server

openstack-swift-object-updater.service     loaded active running OpenStack Object Storage (swift) - Object Updater

openstack-swift-object.service             loaded active running OpenStack Object Storage (swift) - Object Server

openstack-swift-proxy.service              loaded active running OpenStack Object Storage (swift) - Proxy Server

openstack-zaqar.service                    loaded active running OpenStack Message Queuing Service (code-named Zaqar) Server

openstack-zaqar@1.service                  loaded active running OpenStack Message Queuing Service (code-named Zaqar) Server Instance 1

openvswitch.service                        loaded active exited  Open vSwitch

LOAD   = Reflects whether the unit definition was properly loaded.

ACTIVE = The high-level unit activation state, i.e. generalization of SUB.

SUB    = The low-level unit activation state, values depend on unit type.

37 loaded units listed. Pass --all to see loaded but inactive units, too.

To show all installed unit files use 'systemctl list-unit-files'.

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

[stack@director ~]$df -h

4. قم بتنفيذ هذه الأوامر كمستخدم جذري لإجراء نسخ إحتياطي للبيانات من العقدة الموجودة تحت السحابة إلى ملف باسم under cloud-backup-[timestamp].tar.gz ونقلها إلى خادم النسخ الاحتياطي.

[root@director ~]# mysqldump --opt --all-databases > /root/undercloud-all-databases.sql

[root@director ~]# tar --xattrs -czf undercloud-backup-`date +%F`.tar.gz /root/undercloud-all-databases.sql

/etc/my.cnf.d/server.cnf /var/lib/glance/images /srv/node /home/stack

tar: Removing leading `/' from member names

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

1. تقوم ESC، بدورها، باستحداث وظيفة الشبكة الظاهرية (VNF) من خلال التفاعل مع VIM.

2. يحتوي ESC على معدل تكرار يبلغ 1:1 في حل Ultra-M. يتم نشر جهازي ESC VM ويدعمان فشلا واحدا في Ultra-M. على سبيل المثال، قم باستعادة النظام في حالة حدوث عطل واحد في النظام.

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

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

- التكوين الجاري تشغيله

- CONFd CDB

- سجلات ESC

- تكوين Syslog

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

4. تأكد من سلامة 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

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

[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://<username>:<password>@<backup_vm_ip>:<filename>

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- بدء تشغيل مركز الخدمات الإلكترونية من مكتب دعم المشاريع

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

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

1. إنشاء نسخة إحتياطية من برنامج Cluster-Manager لإدارة مجموعات CPS

أستخدم هذا الأمر لعرض مثيلات Nova وملاحظة اسم مثيل VM الخاص بمدير نظام المجموعة:

nova list

أوقفوا الكلومان من ESC

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP <vm-name>

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

admin@esc1 ~]$ /opt/cisco/esc/confd/bin/confd_cli

admin@esc1> show esc_datamodel opdata tenants tenant Core deployments * state_machine

الخطوة 3. قم بإنشاء صورة لقطة نوفا كما هو موضح في الأمر التالي:

nova image-create --poll

ملاحظة: تأكد من وجود مساحة كافية على القرص للقطة.

هام - في حالة عدم إمكانية الوصول إلى VM بعد إنشاء لقطة، تحقق من حالة VM باستخدام أمر قائمة نوفا. إذا كان في حالة "إيقاف التشغيل"، فأنت بحاجة إلى بدء تشغيل الجهاز الظاهري يدويا.

الخطوة 4. عرض قائمة الصور باستخدام الأمر التالي: صورة Nova Image-list شكل 1: مثال إخراج

الخطوة 5. عند إنشاء لقطة، يتم تخزين صورة اللقطة في نظرة OpenStack. لتخزين اللقطة في مخزن بيانات بعيد، قم بتنزيل اللقطة ونقل الملف في OSPD إلى ( /home/stack/CPS_BACKUP )

لتنزيل الصورة، أستخدم الأمر التالي في OpenStack:

glance image-download –-file For example: glance image-download –-file snapshot.raw 2bbfb51c-cd05-4b7c-ad77-8362d76578db

الخطوة 6. قم بسرد الصور التي تم تنزيلها كما هو موضح في الأمر التالي:

ls —ltr *snapshot*

Example output: -rw-r--r--. 1 root root 10429595648 Aug 16 02:39 snapshot.raw

الخطوة 7. قم بتخزين لقطة برنامج إدارة نظام المجموعة VM لاستعادتها في المستقبل.

2. النسخ الاحتياطي للتكوين وقاعدة البيانات.

1. config_br.py -a export --all /var/tmp/backup/ATP1_backup_all_$(date +\%Y-\%m-\%d).tar.gz OR

2. config_br.py -a export --mongo-all /var/tmp/backup/ATP1_backup_mongoall$(date +\%Y-\%m-\%d).tar.gz

3. config_br.py -a export --svn --etc --grafanadb --auth-htpasswd --haproxy /var/tmp/backup/ATP1_backup_svn_etc_grafanadb_haproxy_$(date +\%Y-\%m-\%d).tar.gz

4. mongodump - /var/qps/bin/support/env/env_export.sh --mongo /var/tmp/env_export_$date.tgz

5. patches - cat /etc/broadhop/repositories, check which patches are installed and copy those patches to the backup directory /home/stack/CPS_BACKUP on OSPD

6. backup the cronjobs by taking backup of the cron directory: /var/spool/cron/ from the Pcrfclient01/Cluman. Then move the file to CPS_BACKUP on the OSPD.

تحقق من Crontab -l إذا كانت هناك حاجة إلى أي نسخ إحتياطي آخر

نقل كافة النسخ الاحتياطية إلى OSPD /home/stack/CPS_Backup

3. نسخ إحتياطي لملف من ESC الرئيسي

/opt/cisco/esc/confd/bin/netconf-console --host 127.0.0.1 --port 830 -u <admin-user> -p <admin-password> --get-config > /home/admin/ESC_config.xml

نقل الملف في OSPD /home/stack/CPS_Backup

4. نسخ إدخالات crontab -l إحتياطيا

إنشاء ملف txt باستخدام crontab -l وإفلاته إلى موقع بعيد ( في OSPD /home/stack/CPS_BACKUP )

5. قم بإجراء عملية نسخ إحتياطي لملفات المسار من عميل LB و PCRF

Collect and scp the below conifgurations from both LBs and Pcrfclients

route -n /etc/sysconfig/network-script/route-*

إجراء الاستعادة

إسترداد OSPD

يتم تنفيذ إجراء إسترداد OSPD استنادا إلى الافتراضات التالية

1. يتوفر النسخ الاحتياطي ل OSPD من خادم OSPD القديم.

2. سيتم إسترداد OSPD على الخادم الجديد الذي هو بديل خادم OSPD القديم في النظام. .

ESC إستعادة

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. إذا كان ESC VM غير قابل للاسترداد ويتطلب إستعادة قاعدة البيانات، فيرجى إستعادة قاعدة البيانات من النسخة الاحتياطية التي تم الحصول عليها مسبقا.

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

# service keepalived stop

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

# escadm status

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

# /opt/cisco/esc/esc-scripts/esc_dbtool.py restore --file scp://<username>:<password>@<backup_vm_ip>:<filename>

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

# service keepalived start

9. بمجرد إستعادة VM وتشغيله بنجاح؛ تأكد من إستعادة جميع التكوين المحدد syslog من النسخ الاحتياطي السابق المعروف. تأكد من استعادته في جميع أجهزة ESC VMs.

[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

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

nova rebuild --poll --name esc_snapshot_27aug2018 esc1

11. تحقق من حالة ESC بعد اكتمال عملية إعادة الإنشاء

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

12. تحقق من صحة 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

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

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

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

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

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

/etc/rsyslog.d

root@abautotestvnfm1em-0:/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

إسترداد CPS

Restore Cluster Manager VM في OpenStack

الخطوة 1 انسخ لقطة برنامج VM الخاص بإدارة المجموعة إلى الخادم النصلي لوحدة التحكم كما هو موضح في الأمر التالي:

ls —ltr *snapshot*

Example output: -rw-r--r--. 1 root root 10429595648 Aug 16 02:39 snapshot.raw

الخطوة 2 تحميل صورة اللقطة إلى OpenStack من Datastore:

glance image-create --name --file --disk-format qcow2 --container-format bare

الخطوة 3 تأكد من تحميل اللقطة باستخدام أمر Nova كما هو موضح في المثال التالي:

nova image-list

الشكل 2: مثال الإخراج

الخطوة 4 بناء على ما إذا كان مدير نظام المجموعة VM موجودا أم لا، يمكنك إختيار إنشاء مستنسخ أو إعادة إنشاء مستنسخ:

· إذا لم يكن مثيل نظام المجموعة Cluster Manager VM موجودا، فقم بإنشاء نظام المجموعة الافتراضية (VM) باستخدام أمر Heat أو Nova كما هو موضح في المثال التالي:

إنشاء VM مستنسخ باستخدام ESC

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli edit-config /opt/cisco/esc/cisco-cps/config/gr/tmo/gen/<original_xml_filename>

سيتم إصدار نظام المجموعة PCRF بمساعدة الأمر المذكور أعلاه، ومن ثم يتم إستعادة تكوينات مدير نظام المجموعة من عمليات النسخ الاحتياطي التي تم إجراؤها باستخدام ميزة Config_br.py Restore، و Mongorestore من عملية تفريغ البيانات التي تم إجراؤها في عملية النسخ الاحتياطي

delete - nova boot --config-drive true --image "" --flavor "" --nic net-id=",v4-fixed-ip=" --nic net-id="network_id,v4-fixed-ip=ip_address" --block-device-mapping "/dev/vdb=2edbac5e-55de-4d4c-a427-ab24ebe66181:::0" --availability-zone "az-2:megh-os2-compute2.cisco.com" --security-groups cps_secgrp "cluman"

· في حالة وجود مثيل Cluster Manager VM، أستخدم الأمر Nova Rebuild لإعادة إنشاء مثيل Cluman VM باستخدام اللقطة التي تم تحميلها كما هو موضح:

nova rebuild <instance_name> <snapshot_image_name>

على سبيل المثال:

nova rebuild cps-cluman-5f3tujqvbi67 cluman_snapshot

الخطوة 5 سرد كافة المثيلات كما هو موضح والتحقق من إنشاء مثيل مدير نظام المجموعة الجديد وتشغيله:

nova list

شكل 3. مثال الإخراج

إستعادة أحدث برامج التصحيح الموجودة على النظام

1.       Copy the patch files to cluster manager which were backed up in OSPD /home/stack/CPS_BACKUP

2.       Login to the Cluster Manager as a root user.

3.       Untar the patch by executing the following command:  tar -xvzf [patch name].tar.gz

4.       Edit /etc/broadhop/repositories and add the following entry:  file:///$path_to_the plugin/[component name]

5.       Run build_all.sh script to create updated QPS packages:  /var/qps/install/current/scripts/build_all.sh

6.       Shutdown all software components on the target VMs:  runonall.sh sudo monit stop all

7.       Make sure all software components are shutdown on target VMs:  statusall.sh

ملاحظة: يجب أن تعرض جميع مكونات البرامج غير خاضعة للمراقبة كالحالة الحالية.

8.       Update the qns VMs with the new software using reinit.sh script:  /var/qps/install/current/scripts/upgrade/reinit.sh

9.       Restart all software components on the target VMs:  runonall.sh sudo monit start all

10.     Verify that the component is updated, run:  about.sh

إستعادة Cronjobs

1. انقل الملف الذي تم نسخه إحتياطيا من OSPD إلى Cluman/PCRFCLIENT01.

2. قم بتشغيل الأمر لتنشيط cronjob من backup.

#crontab Cron-backup

3. تحقق مما إذا كان قد تم تنشيط عمليات إعادة التشغيل من خلال الأمر أدناه.

#crontab -l

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

لإعادة نشر PCRFCLIENT01 VM:

الخطوة 1 سجل الدخول إلى VM الخاص بإدارة المجموعة كمستخدم جذري.

الخطوة 2 لاحظ UID الخاص بمستودع SVN باستخدام الأمر التالي:

svn info http://pcrfclient02/repos | grep UUID

سيقوم الأمر بإخراج معرف المستخدم الخاص بالمستودع.

على سبيل المثال: UUID الخاص بالمستودع: ea50bbd2-5726-46b8-b807-10f4a7424f0e

الخطوة 3 قم باستيراد بيانات تكوين Backup Policy Builder على "مدير المجموعة"، كما هو موضح في المثال التالي:

config_br.py -a import --etc-oam --svn --stats --grafanadb --auth-htpasswd --users /mnt/backup/oam_backup_27102016.tar.gz

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

الخطوة 4 لإنشاء ملفات أرشيف VM على "إدارة المجموعة" باستخدام أحدث التكوينات، قم بتنفيذ الأمر التالي:

/var/qps/install/current/scripts/build/build_svn.sh

الخطوة 5 لنشر الإصدار VM من PCRFCLIENT01، قم بتنفيذ أحد الإجراءات التالية:

في OpenStack، أستخدم قالب الحرارة أو الأمر Nova لإعادة إنشاء الجهاز الظاهري. لمزيد من المعلومات، راجع دليل تثبيت CPS ل OpenStack.

الخطوة 6 إعادة إنشاء مزامنة مدير/تابع SVN بين pcrfclient01 و pcrfclient02 مع pcrfclient01 كمدير من خلال تنفيذ السلسلة التالية من الأوامر.

إذا كان SVN متزامن بالفعل، فلا تقم بإصدار هذه الأوامر.

للتحقق من مزامنة SVN، قم بتشغيل الأمر التالي من pcrfclient02.

إذا تم إرجاع قيمة، فإن SVN يكون متزامنا بالفعل:

/usr/bin/svn propget svn:sync-from-url --revprop -r0 http://pcrfclient01/repos

قم بتنفيذ الأوامر التالية من pcrfclient01:

/bin/rm -fr /var/www/svn/repos

/usr/bin/svnadmin create /var/www/svn/repos

/usr/bin/svn propset --revprop -r0 svn:sync-last-merged-rev 0 http://pcrfclient02/repos-proxy-sync

/usr/bin/svnadmin setuuid /var/www/svn/repos/ "Enter the UUID captured in step 2"

/etc/init.d/vm-init-client /

var/qps/bin/support/recover_svn_sync.sh

الخطوة 7 إذا كانت PCRFclient01 هي أيضا جهاز التحكم VM، فعليك تنفيذ الخطوات التالية:

أ) إنشاء البرامج النصية أحادية الإتجاه للبداية/الإيقاف استنادا إلى تكوين النظام. ليست كافة عمليات النشر قد تم تكوين جميع قواعد البيانات هذه.

ملاحظة: ارجع إلى /etc/broadhop/mongoConfig.cfg لتحديد قواعد البيانات التي يجب إعدادها.

cd /var/qps/bin/support/mongo

build_set.sh --session --create-scripts

build_set.sh --admin --create-scripts

build_set.sh --spr --create-scripts

build_set.sh --balance --create-scripts

build_set.sh --audit --create-scripts

build_set.sh --report --create-scripts

ب) بدء عملية التحول:

/usr/bin/systemctl start sessionmgr-XXXXX

ج) انتظر حتى يبدأ المحكم، ثم قم بتشغيل diagnostic.sh — get_replica_status للتحقق من صحة مجموعة النسخ المتماثلة.

لإعادة نشر PCRFCLIENT02 VM:

الخطوة 1 سجل الدخول إلى الجهاز الظاهري لإدارة المجموعة كمستخدم جذري

الخطوة 2 لإنشاء ملفات أرشيف VM على "إدارة المجموعة" باستخدام أحدث التكوينات، قم بتنفيذ الأمر التالي:

/var/qps/install/current/scripts/build/build_svn.sh

الخطوة 3 لنشر الإصدار PCRFCLIENT02 VM، قم بتنفيذ أحد الإجراءات التالية:

في OpenStack، أستخدم قالب الحرارة أو الأمر Nova لإعادة إنشاء الجهاز الظاهري. لمزيد من المعلومات، راجع دليل تثبيت CPS ل OpenStack.

الخطوة 4 طبقة الأمان إلى pcrfclient01:

ssh pcrfclient01

الخطوة 5 قم بتشغيل البرنامج النصي التالي لاسترداد رسائل SVN من pcrfclient01:

/var/qps/bin/support/recover_svn_sync.sh

لإعادة نشر معرف فئة مورد (VM) جلسة عمل:

الخطوة 1 سجل الدخول إلى الجهاز الظاهري لإدارة المجموعة كمستخدم جذري

الخطوة 2 لنشر وحدة الذاكرة الافتراضية (VM) لجلسة العمل واستبدال وحدة الذاكرة الافتراضية (VM) الفاشلة أو التالفة، قم بتنفيذ واحد مما يلي:

في OpenStack، أستخدم قالب الحرارة أو الأمر Nova لإعادة إنشاء الجهاز الظاهري. لمزيد من المعلومات، راجع دليل تثبيت CPS ل OpenStack

الخطوة 3 أنشئ البرامج النصية أحادية الإتجاه للبداية/الإيقاف استنادا إلى تكوين النظام.

ليست كافة عمليات النشر قد تم تكوين جميع قواعد البيانات هذه. ارجع إلى /etc/broadhop/mongoConfig.cfg لتحديد قواعد البيانات التي يجب إعدادها

cd /var/qps/bin/support/mongo

build_set.sh --session --create-scripts

build_set.sh --admin --create-scripts

build_set.sh --spr --create-scripts

build_set.sh --balance --create-scripts

build_set.sh --audit --create-scripts

build_set.sh --report --create-scripts

الخطوة 4 بروتوكول Secure Shell إلى جلسة العمل و بدء عملية الأبجدية:

ssh sessionmgrXX

/usr/bin/systemctl start sessionmgr-XXXXX

الخطوة 5 انتظر حتى يبدأ الأعضاء ومزامنة الأعضاء الثانويين، ثم قم بتشغيل diagnostic.sh— get_replica_status للتحقق من صحة قاعدة البيانات.

الخطوة 6 لاستعادة قاعدة بيانات "مدير جلسة العمل"، أستخدم أحد أوامر المثال التالي بناء على ما إذا كان قد تم إجراء النسخ الاحتياطي باستخدام خيار —mongo-all أو— mongo:

• config_br.py -a import --mongo-all --users /mnt/backup/Name of backup

or

• config_br.py -a import --mongo --users /mnt/backup/Name of backup

لإعادة نشر مدير السياسة (موازن التحميل) VM:

الخطوة 1 سجل الدخول إلى VM الخاص بإدارة المجموعة كمستخدم جذري.

الخطوة 2 لاستيراد بيانات تكوين "منشئ نهج النسخ الاحتياطي" على "إدارة نظام المجموعة"، قم بتنفيذ الأمر التالي:

config_br.py -a import --network --haproxy --users /mnt/backup/lb_backup_27102016.tar.gz

الخطوة 3 لإنشاء ملفات أرشيف VM على "إدارة المجموعة" باستخدام أحدث التكوينات، قم بتنفيذ الأمر التالي:

/var/qps/install/current/scripts/build/build_svn.sh

الخطوة 4 لنشر الطراز LB01 VM، قم بتنفيذ أحد الأمور التالية:

في OpenStack، أستخدم قالب الحرارة أو الأمر Nova لإعادة إنشاء الجهاز الظاهري. لمزيد من المعلومات، راجع دليل تثبيت CPS ل OpenStack.

لإعادة نشر VM الخاص بخادم النهج (QNS):

الخطوة 1 سجل الدخول إلى VM الخاص بإدارة المجموعة كمستخدم جذري.

الخطوة 2 قم باستيراد بيانات تكوين Backup Policy Builder على "مدير المجموعة"، كما هو موضح في المثال التالي:

config_br.py -a import --users /mnt/backup/qns_backup_27102016.tar.gz

الخطوة 3 لإنشاء ملفات أرشيف VM على "إدارة المجموعة" باستخدام أحدث التكوينات، قم بتنفيذ الأمر التالي:

/var/qps/install/current/scripts/build/build_svn.sh

الخطوة 4 لنشر وحدة QNS VM، قم بتنفيذ أحد الأمور التالية:

في OpenStack، أستخدم قالب الحرارة أو الأمر Nova لإعادة إنشاء الجهاز الظاهري. لمزيد من المعلومات، راجع دليل تثبيت CPS ل OpenStack

الإجراء العام لاستعادة قاعدة البيانات

الخطوة 1 قم بتنفيذ الأمر التالي لاستعادة قاعدة البيانات:

config_br.py –a import --mongo-all /mnt/backup/backup_$date.tar.gz where $date is the timestamp when the export was made.

على سبيل المثال,

config_br.py –a import --mongo-all /mnt/backup/backup_27092016.tgz

الخطوة 2 سجل الدخول إلى قاعدة البيانات وتحقق مما إذا كانت قيد التشغيل ويمكن الوصول إليها:

1. تسجيل الدخول إلى مدير الجلسة:

mongo --host sessionmgr01 --port $port

حيث $port هو رقم المنفذ لقاعدة البيانات التي سيتم فحصها. على سبيل المثال، 27718 هو منفذ التوازن الافتراضي.

2. عرض قاعدة البيانات من خلال تنفيذ الأمر التالي:

show dbs

3. قم بتبديل shell الأحادي إلى قاعدة البيانات من خلال تنفيذ الأمر التالي:

use $db

حيث $db هو اسم قاعدة بيانات معروض في الأمر السابق.

يقوم الأمر 'use' بتحويل shell mongo إلى قاعدة البيانات هذه.

على سبيل المثال,

use balance_mgmt

4. لعرض المجموعات، قم بتنفيذ الأمر التالي:

show collections

5. لعرض عدد السجلات في المجموعة، قم بتنفيذ الأمر التالي:

db.$collection.count()

For example, db.account.count()

سيظهر المثال أعلاه عدد السجلات في "حساب" المجموعة في قاعدة بيانات الرصيد (balance_mgmt).

إستعادة مستودع النسخ الاحتياطية

لاستعادة بيانات تكوين منشئ السياسة من نسخة إحتياطية، قم بتنفيذ الأمر التالي:

config_br.py –a import --svn /mnt/backup/backup_$date.tgz where, $date is the date when the cron created the backup file.

إستعادة لوحة معلومات Grafana

يمكنك إستعادة لوحة معلومات Grafana باستخدام الأمر التالي:

config_br.py -a import --grafanadb /mnt/backup/

التحقق من صحة الاستعادة

بعد إستعادة البيانات، تحقق من نظام العمل من خلال تنفيذ الأمر التالي:

/var/qps/bin/diag/diagnostics.sh