DNS 컨피그레이션 오류로 인한 IM&P Inter-Clustering 문제 해결

소개

이 문서는 클러스터 간 피어 시나리오에서 Cisco IM&P(Instant Messaging and Presence) Server 내의 피어 연결 테스트에 대해 "연결할 수 없음(피어 주소가 유효한지, AXL이 피어에서 실행되고 있는지, AXL 사용자 이름/비밀번호 자격 증명이 유효한지 확인)" 오류가 수신되는 시나리오를 설명합니다.

사전 요구 사항

요구 사항

다음 주제에 대한 지식을 보유하고 있으면 유용합니다.

• Cisco IM and Presence 서비스
• 클러스터 간 피어링 기능 

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

배경 정보

다음 그림에서는 Cisco Unified CM IM and Presence Administration(Cisco Unified CM IM and Presence 관리) > Presence(프레즌스) > Inter-Clustering(클러스터링간)에서 발견된 오류를 보여 줍니다.

• AXL(Administrative XML Web Service) 사용자 이름과 AXL 암호가 모두 유효합니다.
• Cisco AXL Web Service가 피어에서 실행되고 있습니다.
• 이 클러스터링 간 오류는 DNS(Domain Name System) 컨피그레이션 문제로 인해 발생합니다. 그러나 IM&P 추적은 네트워크에 의해 유입된 가능한 지연을 나타내는 것으로 보이므로 초기 분류 작업을 잘못 진행할 수 있습니다. 두 피어의 동시 패킷 캡처 수집을 통해 네트워크에 어떠한 지연도 발생하지 않음을 알 수 있습니다.

참고: 일반적으로 이는 단방향 문제입니다. 즉, IM&P 클러스터 A가 IM&P 클러스터 B와 성공적으로 통신할 수 있지만 IM&P 클러스터 B가 IM&P 클러스터 A와 통신을 시도할 때 Not reachable(연결할 수 없음) 오류가 발생합니다.

문제 해결

1단계. AXL 사용자 이름, AXL 비밀번호 및 피어 주소가 모두 올바른지 확인합니다. 이 시나리오에서는 연결이 문제가 되지 않으며 피어가 두 가지 방법으로 통신할 수 있어야 합니다(ping할 수 있을 뿐 아니라 해당 AXL 포트를 통해서도 연결할 수 있어야 함). 8443).

2단계. IM&P 클러스터 A 및 B에서 다음 로그 집합을 적어도 하나씩 수집합니다.

•  Cisco AXL 웹 서비스
•  Cisco 클러스터 간 동기화 에이전트

주의: 테스트를 수행하기 전에 일부 서비스 추적을 디버그 레벨로 설정해야 합니다. 테스트가 수행된 후 추적 수준을 기본 상태로 설정하여 서버 성능에 더 이상의 영향을 미치지 않도록 합니다.

참고: 관련된 두 클러스터에서 로그를 수집하는 것이 중요합니다.

각 서비스에 대해 디버그 수준을 활성화하는 경로는 다음과 같습니다.

• Cisco Unified IM and Presence Serviceability(Cisco Unified IM and Presence 서비스 가용성) > Trace(추적) > Configuration(컨피그레이션) > Select IM&P Server(IM&P 서버 선택) 및 Go(이동)를 클릭하고 > Database and Admin Services(데이터베이스 및 관리 서비스)를 선택한 다음 Go(이동) > Select Cisco AXL Web Service(Cisco AXL 웹 서비스 선택)를 클릭한 다음Go(이동)를 클릭합니다.
• Cisco Unified IM and Presence Serviceability(Cisco Unified IM and Presence 서비스 가용성) > Trace(추적) > Configuration(컨피그레이션) > Select IM&P Server(IM&P 서버 선택)를 클릭하고 Go(이동) > Select IM and Presence Services(IM and Presence 서비스 선택)를 클릭한 후 Go(이동) > Select Cisco Intercluster Sync Agent(Cisco Intercluster Sync Agent 선택)를 클릭하고 Go(이동)를 클릭합니다.

3단계. 로그 분석에서는 다음 메시지 흐름을 보여 줍니다.

클러스터 B의 클러스터 간 동기화 에이전트 로그(연결 불가 오류가 표시된 클러스터)에서 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

클러스터 B의 동일한 클러스터 간 동기화 에이전트 로그에서는 2분 후까지 응답이 수신되어 트랜잭션 시간 초과가 발생함을 보여 줍니다.

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의 피어가 2분 후에 AXL 요청을 받았음을 나타냅니다(클러스터가 다른 표준 시간대에 있는 경우 표준 시간대 변환을 적용해야 함).

클러스터 A에서 AXL 웹 서비스 로그를 살펴보면 요청이 처리되는 시간이 밀리초 단위입니다.

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는 요청을 처리하고 몇 밀리초 내에 응답합니다(예상대로).

클러스터 B에서 AXL 요청을 지연시키는 이유나 이 문제의 정확한 원인이 무엇인지에 대한 조사는 매우 시간이 걸릴 수 있습니다. 그러나 이 시나리오에 대한 기본 진단 단계로 확인된 몇 가지 검증이 있습니다.

해결 방법

IM&P 클러스터 B 내에서 이러한 지연이 DNS 문제로 인해 발생한 경우가 여러 번 있습니다. 다음 두 시나리오 중 하나를 직면할 수 있습니다.

시나리오 1:

클러스터 B에서 기본 DNS 서버에 연결할 수 없습니다. 보조 DNS 서버에 연결할 수 있지만 노드가 기본 DNS 서버를 통해 모든 필수 FQDN을 확인하려고 할 때 상당한 지연이 발생했습니다. 보조 DNS 서버로 변경될 때까지 이미 2분 지연이 발생하여 요청 시간이 초과됩니다.

이를 검증하는 방법은 다음 CLI(Command Line Interface) 명령을 사용하는 것입니다.

show network eth0 명령을 실행하여 IM&P 노드가 사용하도록 구성된 DNS 서버를 나열합니다.

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

그런 다음 utils network ping <Primary DNS server의 IP Address> 명령을 통해 주 DNS 서버를 ping합니다.

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 서버를 모두 ping할 수 있으면 클러스터링간 오류도 수정해야 합니다. 이러한 작업 후에도 문제가 지속되는 경우 시나리오 2의 단계를 수행하십시오.

시나리오 2:

클러스터 B에서 기본 및 보조 DNS 서버 모두 연결/ping이 가능하지만 IM&P 서버는 여전히 CLI 및 웹 페이지에 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 명령 유틸리티 진단 테스트는 특히 validate_network 모듈 내에서 DNS 확인 문제를 표시하며, 이는 Reverse 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

이 특정 오류는 일부 IP 주소를 FQDN(정규화된 도메인 이름)으로 확인할 수 없는 DNS 서버 문제를 나타냅니다. CLI 명령 show network cluster를 통해 이 문제를 추가로 격리할 수 있습니다. 이 명령은 해당 클러스터에 속하는 항목(모든 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 서버는 10.0.10.10 IP 주소에서 IMPSUB.edgrodrilab.com FQDN으로 확인할 PTR 레코드를 포함하지 않습니다.

DNS 도달 불가 경고 및 역방향 DNS 조회 실패 오류를 해결하려면 DNS 서버에 필수 A 호스트 및 PTR 레코드를 만들어 정방향 및 역방향 DNS 조회의 모든 CUCM 및 IM&P 노드를 확인할 수 있어야 합니다.

다음을 확인합니다.

정확히 동일한 클러스터링 간 문제가 발생하고 오류 서명이 로그와 일치하면 확인해야 할 기본 설정 중 하나는 DNS 서버 상태 및 컨피그레이션입니다.

기본 및 보조 DNS 서버는 모두 연결/ping이 가능하고, 정방향 및 역방향 DNS 조회를 위해 클러스터 내의 모든 CUCM 및 IM&P 노드를 확인할 수 있어야 합니다.

Inter-Clustering 오류를 트러블슈팅하기 전에 모든 DNS 경고, 오류 또는 경고를 지워야 합니다. DNS 컨피그레이션을 검증하려면 utils diagnose test 명령을 사용할 수 있습니다.