أستكشاف أخطاء التجميع بين IM&P وإصلاحها بسبب التكوين غير الصحيح ل DNS

المقدمة

يصف هذا المستند سيناريو حيث يتم تلقي خطأ "غير قابل للوصول (التحقق من عنوان النظير صالح، بينما يتم تشغيل AXL على بيانات اعتماد النظير و AXL username/كلمة المرور صالحة)" لاختبار اتصال النظير داخل خادم المراسلة الفورية والتواجد (IM&P) من Cisco في سيناريو نظير لنظام المجموعة البينية.

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

المتطلبات

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

• خدمة المراسلة الفورية والحضور من Cisco
• ميزة التناظر بين المجموعات 

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

لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.

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

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

تظهر الصورة التالية الخطأ الذي تم العثور عليه داخل إدارة المراسلة الفورية والحضور Cisco Unified CM > Presence > التجميع البيني:

• كلا من اسم مستخدم خدمة ويب (AXL) الإدارية XML وكلمة مرور AXL صالحين.
• يتم تشغيل خدمة ويب AXL من Cisco على النظير.
• يرجع سبب هذا الخطأ في التجميع بين المجموعات إلى وجود مشاكل في تكوين نظام اسم المجال (DNS)؛ ومع ذلك، يمكن أن تضلل آثار المراسلة الفورية والتتبع في الفرز الأولي، حيث يبدو أنها تشير إلى احتمال حدوث تأخير من قبل الشبكة. يمكن بعد ذلك أن تظهر مجموعة التقاط الحزم المتزامنة من كلا النظيرين أنه لا يوجد أي تأخير في الشبكة على الإطلاق.

ملاحظة: عادة ما تكون هذه المشكلة أحادية الإتجاه، مما يعني أن المجموعة أ من IM&P قادرة على الاتصال بنجاح بالمجموعة ب من IM&P، ولكن المجموعة ب من IM&P تلقي بالخطأ الذي يتعذر الوصول إليه عندما تحاول الاتصال بالمجموعة أ من IM&P.

استكشاف الأخطاء وإصلاحها

الخطوة 1. تحقق من صحة أسماء مستخدمي AXL وكلمات مرور AXL وعناوين الأجهزة النظيرة. في هذا السيناريو، لا يمثل الاتصال مشكلة ويجب أن يكون الأقران قادرين على الاتصال بكلا الطريقتين (يجب ألا يكونوا فقط قابلين للجلب بل أيضا يمكن الوصول إليه من خلال منافذ AXL المقابلة: 8443).

الخطوة 2. قم بتجميع هذه المجموعة من السجلات على الأقل من كل من المجموعة A و B من IM&P:

•  خدمة ويب Cisco AXL
•  وكيل مزامنة Cisco Intercluster

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

ملاحظة: من المهم جمع السجلات من كلتا المجموعتين المعنيتين.

المسار لتمكين مستوى تصحيح الأخطاء لكل خدمة هو:

• خدمة Cisco Unified IM وخدمة التواجد > تتبع > تكوين > تحديد IM&P Server وانقر انتقال>حدد خدمات قاعدة البيانات والإدارة وانقر فوق انتقال > تحديد خدمة ويب AXL من Cisco وانقر فوق انتقال
• خدمة Cisco Unified IM وخدمة التواجد > تتبع > تكوين > تحديد IM&P Server وانقر انتقال > تحديد خدمات المراسلة الفورية والحضور وانقر فوق Go > تحديد وكيل Cisco Intercluster Sync وانقر فوق Go

الخطوة 3. يوضح تحليل السجل تدفق الرسالة هذا:

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

2019-07-14 06:00:07,842 DEBUG [Peer: node name in Cluster A] axl.AXLClientLogger - runSoapReq: The axl request is : 
     
     
     
      
       
       
        
        
          SELECT count(*) from processnode WHERE systemnode='f' and tknodeusage= 0 
         
        
       
     

يظهر "عامل مزامنة نظام المجموعة" نفسه في نظام المجموعة "ب" أنه تم تلقي الاستجابة حتى الدقيقتين التاليتين، مما يتسبب في مهلة للحركة:

019-07-14 06:02:36,176 DEBUG [AXL Runner for parent thread ID:4741 (Peer: node name in Cluster A] axl.AXLClientLogger - AXLClientBase - sendSOAPRequest received : 
     
     
     
      
       
        
         
          
          
            2 
           
          
         
        
       
     
"node name in Cluster A" received AXL request at "2019-07-14 01:02:36"

قد يؤدي ذلك إلى الشك في وجود نوع من تأخير الحزم داخل الشبكة. ومع ذلك، يشير نص الاستجابة نفسه إلى أن النظير في المجموعة A تلقى طلب AXL بعد دقيقتين (تحتاج إلى تنفيذ تحويل المنطقة الزمنية إذا كانت المجموعات موجودة في مناطق زمنية مختلفة).

إذا قمت بالنظر إلى سجلات AXL Web Service في المجموعة A، يمكنك العثور على معالجة الطلب بالمللي ثانية:

2019-07-14 01:02:36,110 INFO  [http-bio-443-exec-742] servletRouters.AXLFilter - AXL REQUEST : 

     
      
       
       
        
        
          SELECT count(*) from processnode WHERE systemnode='f' and tknodeusage= 0 
         
        
       
     
"node name in Cluster A" sent response at "2019-07-14 01:02:36"

2019-07-14 01:02:36,131 DEBUG [http-bio-443-exec-742] servletRouters.AXLFilter - Final response String  : 
     
     
     
      
       
        
         
          
          
            2 
           
          
         
        
       
     

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

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

الحل

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

السيناريو 1:

في المجموعة B، لا يمكن الوصول إلى خادم DNS الأساسي. على الرغم من إمكانية الوصول إلى خادم DNS الثانوي، فقد تأخرت العقدة كثيرا عند محاولتها حل جميع شبكات FQDN المطلوبة عبر خادم DNS الأساسي. وبحلول الوقت الذي يتغير فيه إلى خادم DNS الثانوي، يكون هناك تأخير لمدة دقيقتين بالفعل، وبالتالي انتهت مهلة الطلب.

الطريقة التي يمكنك بها التحقق من هذا الإجراء هي من خلال أوامر واجهة سطر الأوامر (CLI) التالية :

قم بإصدار الأمر show network eth0 لسرد عقدة DNS Servers IM&P التي تم تكوينها للاستخدام:

admin:show network eth0
Ethernet 0
DHCP         : disabled           Status     : up
IP Address   : 10.0.10.10         IP Mask    : 255.255.255.000
Link Detected: yes                Mode       : Auto disabled, Full, 10000 Mbits/s
Duplicate IP : no

DNS
Primary      : 10.0.10.31         Secondary  : 10.0.10.32

ثم حاول إختبار اتصال خادم DNS الأساسي من خلال الأمر utils network ping <عنوان IP لخادم DNS الأساسي>:

admin:utils network ping 10.0.10.31
PING 10.0.10.31 (10.0.10.31) 56(84) bytes of data.
From 10.0.10.10 icmp_seq=2 Destination Host Unreachable
From 10.0.10.10 icmp_seq=3 Destination Host Unreachable
From 10.0.10.10 icmp_seq=4 Destination Host Unreachable

إذا لم يكن خادم DNS الأساسي يمكن الوصول إليه، فتأكد من صحة عنوان IP الذي تم تكوينه له. بعد ذلك، قم بإصلاح جميع مشكلات الاتصال. بمجرد أن تتمكن من إختبار اتصال كل من خوادم DNS الأساسية والثانوية دون حدوث مشاكل، يجب أيضا إصلاح خطأ نظام المجموعات المشتركة. وفي حالة إستمرار المشكلة بعد هذه الإجراءات، انتقل إلى الخطوات المنصوص عليها في السيناريو 2.

السيناريو الثاني:

في المجموعة B، يمكن الوصول إلى خوادم DNS الأساسية والثانوية معا، ولكن لا يزال خادم IM&P يعرض تحذير DNS الذي يتعذر الوصول إليه في واجهة سطر الأوامر وصفحة الويب:

Command Line Interface is starting up, please wait ...

   Welcome to the Platform Command Line Interface

VMware Installation:
        128 vCPU: Intel(R) Xeon(R) CPU E5-2699A v4 @ 2.40GHz
        Disk 1: 80GB, Partitions aligned
        4096 Mbytes RAM
        WARNING: DNS unreachable

أيضا، يعرض إختبار تشخيص أمر واجهة سطر الأوامر (CLI) مشكلة في تحليل DNS، وخاصة ضمن الوحدة النمطية validate_network، والتي يمكن أن تشير إلى خطأ مثل فشل بحث DNS العكسي:

admin:utils diagnose test
Log file: platform/log/diag4.log

Starting diagnostic test(s)
===========================
test - disk_space          : Passed (available: 6938 MB, used: 11852 MB)
skip - disk_files          : This module must be run directly and off hours
test - service_manager     : Passed
test - tomcat              : Passed
test - tomcat_deadlocks    : Passed
test - tomcat_keystore     : Passed
test - tomcat_connectors   : Passed
test - tomcat_threads      : Passed
test - tomcat_memory       : Passed
test - tomcat_sessions     : Passed
skip - tomcat_heapdump     : This module must be run directly and off hours
test - validate_network    : Reverse DNS lookup failed
test - raid                : Passed

يشير هذا الخطأ الخاص إلى وجود مشكلة مع خادم DNS، الذي يتعذر عليه حل بعض عناوين IP إلى أسماء المجالات المؤهلة بالكامل (FQDNs). أنت يستطيع أكثر عزلت هذا إصدار من خلال ال CLI أمر عرض شبكة قطاع. يعرض هذا الأمر قائمة الإدخالات (كافة خوادم CUCM و IM&P) التي تعد جزءا من نظام المجموعة هذا:

admin:show network cluster
10.3.74.13 IMPPUB.edgrodrilab.com IMPPUB Subscriber cups DBPub authenticated
10.3.74.14 IMPSUB.edgrodrilab.com IMPSUB Subscriber cups DBSub authenticated using TCP since Fri Oct 15 10:22:20 2021
10.3.74.12 CUCMSUB.edgrodrilab.com CUCMSUB Subscriber callmanager DBSub authenticated using TCP since Thu Oct 28 11:24:16 2021
10.3.74.11 CUCMPUB.edgrodrilab.com CUCMPUB Publisher callmanager DBPub authenticated using TCP since Thu Oct 28 11:27:36 2021

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

مثال لدقة DNS العاملة:

admin:utils network host IMPPUB
Local Resolution:
IMPPUB.edgrodrilab.com resolves locally to 10.0.10.10

External Resolution:
IMPPUB.edgrodrilab.com has address 10.0.10.10

admin:utils network host 10.0.10.10
Local Resolution:
10.0.10.10 resolves locally to IMPPUB.edgrodrilab.com

External Resolution:
10.10.0.10.in-addr.arpa domain name pointer imppub.edgrodrilab.com.

مثال على حل DNS غير العامل:

admin:utils network host IMPSUB
Local Resolution:
IMPSUB.edgrodrilab.com resolves locally to 10.0.10.10

External Resolution:
IMPSUB.edgrodrilab.com has address 10.0.10.10

admin:utils network host 10.0.10.10
Local Resolution:
10.0.10.10 resolves locally to IMPSUB.edgrodrilab.com

External Resolution:
No external servers found

في هذه الحالة المحددة، لا يحتوي خادم DNS على سجل PTR الذي سيتم حله من عنوان IP 10.0.10.10 إلى IMPSUB.edgrodrilab.com FQDN.

لإصلاح تحذير DNS الذي يتعذر الوصول إليه وخطأ البحث العكسي في DNS، يلزمك إنشاء مضيفوسجلات PTR المطلوبة في خادم DNS حتى تتمكن من حل جميع عقد CUCM و IM&P لكل من البحث في DNS العكسي والمرسل للأمام.

التحقق من الصحة

عند مواجهة نفس المشكلة المتعلقة بالتكوين المشترك تماما وتطابق توقيع الخطأ السجلات، يكون أحد الإعدادات الأساسية للتحقق هو حالة خادم DNS وتكوينه.

يلزم أن تكون خوادم DNS الأساسية والثانوية قابلة للوصول/السحب وقادرة على حل جميع عقد CUCM و IM&P داخل نظام المجموعة للبحث عن DNS العكسي والتقديم.

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