المحتويات

المقدمة

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

المتطلبات

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

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

التكوين

الرسم التخطيطي للشبكة

التكوينات

التحقق

كيف يتم التحقق من عقدة بادئة النسخ المتماثل؟

تحديث كلمة مرور أداة التحقق من الصحة (vBond) بعد تسجيل إستعادة البيانات بعد الكوارث

كلمة مرور تحديث المدقق (vbond)

إضافة أداة تحقق جديدة (vBond) ليتم تغليفها بعد تسجيل إستعادة البيانات بعد الكوارث

ترقية العناصر المضمنة لاسترداد البيانات بعد الكوارث

قبل البدء

عملية الترقية

معلومات ذات صلة

المقدمة

يصف هذا المستند طبيعة حالة برنامج Cisco vManage وموجه الأساسي/الثانوي المخصص (DR)، مما يتيح إمكانية تجاوز الأعطال يدويا باستخدام النسخ التلقائي للبيانات.

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

المتطلبات

توصي Cisco بأن تكون لديك معرفة بقطاعات vManage ذات 3 عقد.

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

توصي Cisco بوجوب استيفاء هذه المتطلبات قبل تسجيل إستعادة البيانات بعد الكوارث:

- تأكد من إمكانية الوصول إلى العقدة الأساسية والثانوية بواسطة HTTPS على شبكة VPN للنقل (VPN 0).

- تأكد من أن وحدات التحكم vSmart من Cisco و Cisco vBond Orchestrator الموجودة على الإعداد الثانوي متصلة بالإعداد الأساسي.

- تأكد من أن عقدة Cisco vManage الأساسية والعقدة الثانوية تقوم بتشغيل نفس إصدار Cisco vManage.

- واجهة نظام مجموعة خارج النطاق في شبكة VPN 0:

- بالنسبة لكل مثيل vManage داخل نظام مجموعة، يلزم توفر واجهة ثالثة (إرتباط نظام المجموعة) إلى جانب الواجهات المستخدمة للشبكة الخاصة الظاهرية (VPN) رقم 0 (النقل) والشبكة الخاصة الظاهرية (VPN) رقم 512 (الإدارة).

- يتم إستخدام هذه الواجهة للاتصال والمزامنة بين خوادم vManage داخل نظام المجموعة.

- يجب أن تكون هذه الواجهة 1 جيجابت في الثانية على الأقل وبها زمن وصول يبلغ 4 مللي ثانية أو أقل. يوصى باستخدام واجهة بسرعة 10 جيجابت في الثانية.

- يجب أن تكون كلا عقدتي vManage قادرة على الوصول إلى بعضها البعض من خلال هذه الواجهة: سواء كان مقطع من الطبقة 2 أو من خلال توجيه من الطبقة 3.

- في كل vManage، يجب تكوين هذه الواجهة في واجهة المستخدم الرسومية (GUI) كواجهة نظام مجموعة (إدارة>إدارة نظام المجموعة- يشير إلى عنوان IP الخاص بواجهة نظام مجموعة خارج النطاق والمستخدم وكلمة المرور).

- للسماح لعقد Cisco vManage بالاتصال ببعضها البعض عبر مراكز البيانات، قم بتمكين منافذ TCP 8443 و 830 على جدران الحماية بمركز البيانات لديك.

- تأكد من تمكين جميع الخدمات (خادم التطبيق، وخادم التكوين-db، وخادم المراسلة، وخادم التنسيق، و statistics-db) على كل من عقد Cisco vManage.

- قم بتوزيع جميع وحدات التحكم، بما في ذلك برنامج Cisco vBond Orchestrator، عبر مراكز البيانات الأساسية والثانوية على حد سواء. تأكد من إمكانية الوصول إلى وحدات التحكم هذه بواسطة عقد vManage من Cisco التي يتم توزيعها عبر مراكز البيانات هذه. تتصل وحدات التحكم فقط بعقدة Cisco vManage الأساسية.

- تأكد من عدم وجود عمليات أخرى قيد التنفيذ في عقدة (أساسي) النشطة والعقدة الاحتياطية (الثانوية) vManage من Cisco. على سبيل المثال، تأكد من عدم وجود خوادم في عملية ترقية القوالب أو إرفاقها بالأجهزة.

- قم بتعطيل خادم وكيل Cisco vManage HTTP/HTTPS في حال تمكينه. راجع خادم وكيل HTTP/HTTPS لاتصال Cisco vManage مع الخوادم الخارجية. إذا لم تقم بتعطيل الخادم الوكيل، فسيحاول Cisco vManage إنشاء اتصال لاسترداد البيانات بعد الكوارث من خلال عنوان IP للوكيل، حتى إذا كانت عناوين IP الخاصة بمجموعة vManage خارج النطاق قابلة للوصول إليها مباشرة. يمكنك إعادة تمكين خادم وكيل Cisco vManage HTTP/HTTPS بعد اكتمال تسجيل إسترداد البيانات بعد الكوارث.

- قبل بدء عملية تسجيل إسترداد البيانات بعد الكوارث، انتقل إلى نافذة الأدوات>إعادة اكتشاف الشبكة على عقدة Cisco vManage الأساسية وأعد اكتشاف Cisco vBond Orchestrator.

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

تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج التالية:

- المدير: 20.12.5

- أداة التحقق من الصحة: 20.12.5

- جهاز التحكم: 20.12.5

- cEdge: 17.12.5

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

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

توفر عملية إستعادة البيانات بعد الكوارث عملية تجاوز للفشل يجريها المسؤول. عند تسجيل إستعادة البيانات بعد الكوارث، يتم نسخ البيانات تلقائيا بين مجموعات vManage الأساسية والثانوية من Cisco. يمكنك إجراء تجاوز الفشل يدويا إلى المجموعة الثانوية إذا لزم الأمر.

التكوين

الرسم التخطيطي للشبكة

يوضح هذا الشكل البنية عالية المستوى لحل إسترداد البيانات بعد الكوارث باستخدام مجموعة مكونة من ثلاث عقد.

التكوينات

لمزيد من المعلومات حول ميزة vManage لاسترداد البيانات بعد الكوارث، ارجع إلى هذا الارتباط.

تم إنشاء مجموعتي 3 عقد منفصلتين بالفعل، بافتراض أن كل مدير SD-WAN لديه الحد الأدنى من التكوين واكتمل جزء الاعتماد.

- انتقل إلى إدارة > إدارة نظام المجموعة على كلا المجموعتين وتحقق من أن جميع العقد في حالة جاهزة.

تقنية vManage للتيار المستمر:

برنامج DR-vManage:

- انتقل إلى الإدارة>إستعادة البيانات بعد الكوارث. انقر على إدارة إستعادة البيانات بعد الكوارث.

- في الإطار المنبثق، قم بتعبئة تفاصيل كل من vManage الأساسي والثانوي.
عناوين IP التي سيتم الإشارة إليها هي عناوين IP لواجهات قطاعات خارج النطاق.

يجب أن تكون بيانات الاعتماد الخاصة بمستخدم NetAdmin ويجب ألا يتم تغييرها بمجرد تكوين DR، ما لم يتم حذفها.

بمجرد تعبئته، انقر فوق التالي.

- قم بتعبئة تفاصيل وحدات التحكم في vBond.

يجب أن تكون وحدات التحكم vBond قابلة للوصول إليها في عنوان IP المحدد عبر NetConf.

بمجرد تعبئته، انقر فوق التالي.

- في وضع الاسترداد، أختر يدوي. وضع التشغيل التلقائي مهمل. انقر فوق Next (التالي).

قم بتعيين القيمة وانقر فوق حفظ.

- يبدأ تسجيل DR الآن. انقر فوق زر التحديث لتحديث الحالة وسجلات التقدم يدويا. قد تستغرق هذه العملية ما يصل إلى 20 إلى 30 دقيقة.

التحقق

- انتقل إلى الإدارة>إستعادة البيانات بعد الكوارث لعرض حالة إسترداد البيانات بعد الكوارث وعندما تم نسخ البيانات نسخا متماثلا في المرة الأخيرة.

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

تحقق من سجل إستعادة البيانات بعد الكوارث في كلتا المجموعتين.

DC-vmanage (9a15f979-d613-4d75-97bf-f7d4124bc687 is export ID)

vmanage1:/var/log/nms$ cat vmanage-disaster_recovery.log | grep 9a15f979-d613-4d75-97bf-f7d4124bc687

04-Jul-2025 05:17:08,297 UTC INFO [] [] [DataReplicationManager] (pool-232-thread-1) || Export ID Generated: 9a15f979-d613-4d75-97bf-f7d4124bc687

04-Jul-2025 05:17:58,431 UTC INFO [] [] [DisasterRecoveryAlarmsDAO] (pool-232-thread-1) || AlarmsDAO::addAlarm() - Adding alarm {suppressed=false, component=["Disaster Recovery"], severity="Info", eventname="EXPORT_DATA", message="Primary Successfully Exported", acknowledged=false, active=true, type="Disaster_Recovery", rule_name_display="Disaster_Recovery", uuid="ec133314-7205-4afc-bee3-a4b080fc42f0", update_time=1751606278431, entry_time=1751606278431, values=[{host-name="vmanage1", system-ip="11.11.11.1", dcPersonality="primary", exportSize="22.363 MB", exportDuration="49 secs", exportID="9a15f979-d613-4d75-97bf-f7d4124bc687"}], values_short_display=[{host-name="vmanage1", system-ip="11.11.11.1", dcPersonality="primary", exportSize="22.363 MB", exportDuration="49 secs", exportID="9a15f979-d613-4d75-97bf-f7d4124bc687"}], devices=[{host-name="vmanage1", system-ip="11.11.11.1", dcPersonality="primary", exportSize="22.363 MB", exportDuration="49 secs", exportID="9a15f979-d613-4d75-97bf-f7d4124bc687"}], receive_time=1751606278431}

04-Jul-2025 05:17:58,722 UTC INFO [] [] [DataReplicationManager] (pool-232-thread-1) || Sending the import request to remote server 89.89.89.4 for exportID: 9a15f979-d613-4d75-97bf-f7d4124bc687.

04-Jul-2025 05:17:59,081 UTC INFO [a17a50ae-e6d3-401c-9d34-7c9423a5dd5a] [vmanage1] [DisasterRecoveryRestfulResource] (default task-32) |default| Received request from 89.89.89.1, for token: 9a15f979-d613-4d75-97bf-f7d4124bc687, and file: default_1751001428297.tar.gz

04-Jul-2025 05:21:06,515 UTC INFO [a456da19-9868-42e1-b3e7-9cb7ef3bdb81] [vmanage1] [DisasterRecoveryRestfulResource] (default task-31) |default| Replication status for exportID: 9a15f979-d613-4d75-97bf-f7d4124bc687, is Success

vmanage1:/var/log/nms$

DR-Vmanage

DR-vmanage1:/var/log/nms$ cat vmanage-disaster_recovery.log | grep 9a15f979-d613-4d75-97bf-f7d4124bc687

04-Jul-2025 05:15:23,296 UTC INFO [] [] [DataReplicationManager] (Thread-366) || Payload received for data replication: {replicationDir="/opt/data/disaster_recovery/", filename="default_1751001428297.tar.gz", exportID="9a15f979-d613-4d75-97bf-f7d4124bc687", deviceIP="89.89.89.1", exportTime="1751606278229", exportDuration="49 secs", exportSize="22.363 MB", SwitchOverHistoryNode={lastSwitch=0, reasonForSwitch=null, updatedPrimary="89.89.89.1"}, startTime="1751606228297", sha256sum="06363770a967beec4667f29e5b033de4a538523f34e36d9952ffc893fb0557db"}

04-Jul-2025 05:15:23,298 UTC INFO [] [] [DataReplicationManager] (Thread-366) || destinationURL dataservice/disasterrecovery/download/9a15f979-d613-4d75-97bf-f7d4124bc687/default_1751001428297.tar.gz Saved to File /opt/data/disaster_recovery/default_1751001428297.tar.gz

04-Jul-2025 05:15:24,040 UTC INFO [] [] [DisasterRecoveryAlarmsDAO] (Thread-366) || AlarmsDAO::addAlarm() - Adding alarm {suppressed=false, component=["Disaster Recovery"], severity="Info", eventname="DOWNLOAD_DATA", message="Replication payload successfully downloaded by secondary", acknowledged=false, active=true, type="Disaster_Recovery", rule_name_display="Disaster_Recovery", uuid="94ab4c3a-26d9-4d99-b631-d380313d7f08", update_time=1751606124040, entry_time=1751606124040, values=[{host-name="DR-vmanage1", system-ip="12.12.12.1", dcPersonality="secondary", exportSize="22.363 MB", downloadDuration="00 secs", exportID="9a15f979-d613-4d75-97bf-f7d4124bc687"}], values_short_display=[{host-name="DR-vmanage1", system-ip="12.12.12.1", dcPersonality="secondary", exportSize="22.363 MB", downloadDuration="00 secs", exportID="9a15f979-d613-4d75-97bf-f7d4124bc687"}], devices=[{host-name="DR-vmanage1", system-ip="12.12.12.1", dcPersonality="secondary", exportSize="22.363 MB", downloadDuration="00 secs", exportID="9a15f979-d613-4d75-97bf-f7d4124bc687"}], receive_time=1751606124040}

04-Jul-2025 05:15:24,170 UTC INFO [] [] [DataReplicationManager] (Thread-366) || Downloaded replication file size 23449259 for token 9a15f979-d613-4d75-97bf-f7d4124bc687

04-Jul-2025 05:15:24,171 UTC INFO [] [] [DisasterRecoveryManager] (Thread-366) || Sending rpc message to copyReplicationFile for token 9a15f979-d613-4d75-97bf-f7d4124bc687

04-Jul-2025 05:15:24,216 UTC INFO [] [] [DisasterRecoveryManager] (Thread-366) || Sending message to destinations [Endpoint{ip='89.89.89.5', uuid='c3e303a2-53d0-4525-901b-d96e9ce92875'}, Endpoint{ip='89.89.89.6', uuid='bf45f345-ff2e-48ec-b8fd-0bb92427cc28'}] for token 9a15f979-d613-4d75-97bf-f7d4124bc687

04-Jul-2025 05:15:24,245 UTC INFO [] [] [DisasterRecoveryManager] (Thread-366) || Waiting for copyReplicationFile to complete for token 9a15f979-d613-4d75-97bf-f7d4124bc687

04-Jul-2025 05:18:19,545 UTC INFO [] [] [DataReplicationWorker] (Thread-366) || Successfully Deleted Imported Data Directory /opt/data/disaster_recovery/9a15f979-d613-4d75-97bf-f7d4124bc687

04-Jul-2025 05:18:19,643 UTC INFO [] [] [DisasterRecoveryAlarmsDAO] (Thread-366) || AlarmsDAO::addAlarm() - Adding alarm {suppressed=false, component=["Disaster Recovery"], severity="Info", eventname="IMPORT_DATA", message="Secondary Successfully Imported", acknowledged=false, active=true, type="Disaster_Recovery", rule_name_display="Disaster_Recovery", uuid="1fc80500-f621-4d45-9395-4ed949ddda68", update_time=1751606299643, entry_time=1751606299643, values=[{host-name="DR-vmanage1", system-ip="12.12.12.1", dcPersonality="secondary", exportSize="22.363 MB", importDuration="02 mins 45 secs", exportID="9a15f979-d613-4d75-97bf-f7d4124bc687"}], values_short_display=[{host-name="DR-vmanage1", system-ip="12.12.12.1", dcPersonality="secondary", exportSize="22.363 MB", importDuration="02 mins 45 secs", exportID="9a15f979-d613-4d75-97bf-f7d4124bc687"}], devices=[{host-name="DR-vmanage1", system-ip="12.12.12.1", dcPersonality="secondary", exportSize="22.363 MB", importDuration="02 mins 45 secs", exportID="9a15f979-d613-4d75-97bf-f7d4124bc687"}], receive_time=1751606299643}

04-Jul-2025 05:18:19,707 UTC INFO [] [] [DataReplicationManager] (Thread-366) || Successfully imported data from exportID 9a15f979-d613-4d75-97bf-f7d4124bc687

04-Jul-2025 05:18:19,716 UTC INFO [] [] [DisasterRecoveryManager] (Thread-366) || Sending rpc message to deleteReplicationFile for token 9a15f979-d613-4d75-97bf-f7d4124bc687

04-Jul-2025 05:18:19,849 UTC INFO [] [] [DisasterRecoveryManager] (Thread-366) || Sending message to destinations [Endpoint{ip='89.89.89.5', uuid='c3e303a2-53d0-4525-901b-d96e9ce92875'}, Endpoint{ip='89.89.89.6', uuid='bf45f345-ff2e-48ec-b8fd-0bb92427cc28'}] for token 9a15f979-d613-4d75-97bf-f7d4124bc687

كيف يتم التحقق من عقدة بادئة النسخ المتماثل؟

- أستخدم واجهة برمجة تطبيقات (API) التالية للعثور على عقدة بادئة النسخ المتماثل على كلا المجموعتين:

https://<vmanage-ip>/خدمة البيانات/ملكية الكيان/الشجرة.

بالنسبة لمجموعة DC:

عقدة النسخ المتماثل هي CB87a08e-079e-4394-81c3-e63c36ac22c0 وهي العقدة1، دققت عليها من show control local-properties.

كما هو الحال بالنسبة ل DR-vManage، عقدة النسخ المتماثل هي d78832e5-e6d3-4b6b-bf61-f923cf3c7282.

تحديث كلمة مرور أداة التحقق من الصحة (vBond) بعد تسجيل إستعادة البيانات بعد الكوارث

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

[04-July-2025 6:47:35 UTC] Unshut control tunnel on the standby vManage.

[04-July-2025 6:47:36 UTC] Sleeping for 10 seconds to ensure control tunnel is fully up and functional on the vmanage.

[04-July-2025 6:47:55 UTC] Failed to activate the cluster. Vbond is unreachable

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

04-July-2025 06:47:55,206 UTC ERROR [89b008fa-2c1b-4f78-b093-ed1fa1f06b71] [vManage20-14-DR] [DisasterRecoveryManager] (dr_activate) |default| IP credentials are not reachable through given ip and authentication creds com.viptela.vmanage.server.device.common.NetConfClientException: java.io.IOException: Unable to authenticate for deviceIP 10.66.91.163. With session Nio2Session[local=/10.66.91.173:56704, remote=/10.66.91.163:830]!

at com.viptela.vmanage.server.device.common.NetConfClient.connect(NetConfClient.java:255) ~[vmanage-server-1.0.0-SNAPSHOT.jar:?]

at com.viptela.vmanage.server.device.common.NetConfClient.

(NetConfClient.java:114) ~[vmanage-server-1.0.0-SNAPSHOT.jar:?]

كلمة مرور تحديث المدقق (vbond)

تأكد من تحديث كلمة مرور vBond الجديدة في كل من صفحة إسترداد البيانات بعد الكوارث وكلمة المرور تحت إدارة كلمة المرور:

إدارة > إستعادة البيانات بعد الكوارث > إدارة كلمة المرور > تحديث كلمة مرور vBond.

تأكد من نجاح النسخ المتماثل بعد تحديث كلمة المرور. حاول تجاوز الفشل فقط بعد تأكيد النسخ المتماثل الناجح.

تحذير: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwn19224.

إضافة أداة تحقق جديدة (vBond) ليتم تغليفها بعد تسجيل إستعادة البيانات بعد الكوارث

لا يتم دعم إضافة مدقق جديد إلى تغشية SD-WAN بعد تسجيل إستعادة البيانات بعد الكوارث، حيث إن إعداد إسترداد البيانات بعد الكوارث لا يعي بمعلومات التحقق الجديدة هذه نظرا لعدم تحديثها أثناء التسجيل.

على الرغم من أنه يمكنك إضافة المدقق، فإن تبديل يفشل.

إذا كنت بحاجة لإضافة مدقق جديد، لاحظ الخطوات التالية:

1. احذف إعداد إستعادة البيانات بعد الكوارث.

2. إضافة أداة التحقق الجديدة إلى تغشية شبكة WAN الخاصة ببرنامج SD.

3. إعادة تكوين إستعادة البيانات بعد الكوارث.

ترقية العناصر المضمنة لاسترداد البيانات بعد الكوارث

قبل البدء

- أستخدم طريقة واجهة سطر الأوامر (CLI) لترقية كل من المدراء النشطين والاحتياطيين Cisco SD-WAN.

- تأكد من أن حالة النسخ المتماثل على Administration > Disaster Recovery مستقرة وليست في حالة انتقالية مثل إستيراد معلق،تصدير معلق، أو تنزيل معلق. يجب أن يكون في حالة النجاح قبل إيقاف إستعادة البيانات بعد الكوارث مؤقتا.

- قم بإيقاف عملية إستعادة البيانات بعد الكوارث مؤقتا باستخدام Pause (إيقاف إستعادة البيانات بعد الكوارث) تحت الإدارة > إسترداد البيانات بعد الكوارث.

عملية الترقية

في هذه الحالة، أنت تقوم بترقية نظام مجموعة vManage من 20.12.5 إلى 20.15.2. أستخدم أسلوب CLI لترقية نظام المجموعة.

قبل الترقية، تحقق من حالة الإصدار والنسخ المتماثل.

إيقاف إستعادة البيانات بعد الكوارث مؤقتا:

بعد الترقية، تأكد من أن جميع الخدمات قيد التشغيل ومن أنه يمكنك تسجيل الدخول إلى جميع عقد vManage (DC و DR) باستخدام واجهة المستخدم الرسومية (GUI).

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

معلومات ذات صلة

- https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/ha-scaling/ios-xe-17/high-availability-book-xe/m-disaster-recovery.html

- الدعم الفني والتنزيلات من Cisco