NetWorker: 이름 해석 문제 해결 모범 사례

NetWorker는 이름 해석에 따라 달라집니다. 이름 해석이 올바르지 않고 완전히 일관되지 않으면 NetWorker의 여러 작업에서 문제가 발생할 수 있습니다. NetWorker는 잠재적인 기밀 데이터를 관리하므로 상호 작용하는 호스트의 ID를 다양한 방법으로 확인해야 합니다.

NetWorker의 이름 해석이 불완전하여 NetWorker에서 증상이 나타날 수 있습니다.

• 정방향 또는 역방향 이름 조회 문제를 나타내는 오류 메시지입니다.
• 백업 중 클라이언트를 조사할 수 없음
• 클라이언트가 서버에 수동으로 저장하거나 복구할 수 없습니다.
• 스토리지 노드 디바이스 클론 생성 또는 액세스 문제
• 탐색 또는 미디어 데이터베이스 레코드 문제입니다.
• 시작 시 또는 일반 작업 중에 서버 또는 스토리지 노드가 응답을 중지합니다.
• 이름이 잘못되었거나 중첩된 인덱스 디렉터리
• 잘못 구성된 클라이언트 오류

이름 확인 워크플로

명령 또는 내부 구성에서 사용되는 호스트 이름을 확인하려는 시도는 사용할 IP 주소로 확인되어야 합니다. 다음 리소스는 name:IP 가 이미 캐싱되었는지 확인하기 위해 다음 순서로 검사되며 이름이 일치하면 중지됩니다. 

1. NetWorker 이름 캐시: 대부분의 주요 NetWorker 데몬 NSRLA 데이터베이스에서 구성 가능한 수명
2. 로컬 호스트 확인자 캐시: 운영 체제에 따라 다르며 호스트 또는 DNS 조회에서 로드를 지연합니다.
3. 로컬 호스트 파일 항목: 빠른 로컬 조회이지만 수동으로 유지 관리됩니다. DNS 확인을 재정의하는 데 유용합니다.
4. DNS 서버 조회: 중앙 집중식 관리로 인해 업계에서 선호되지만 속도가 느림

1. NetWorker 캐싱:

NetWorker 데몬은 내부 이름 캐시를 유지합니다. 클라이언트는 확인된 이름을 nsrexecd에 캐시하는 반면, nsrd 및 nsmmdbd와 같은 핵심 데몬은 자체 캐시를 유지합니다. 이는 검사된 첫 번째 IP 테이블이며 가장 빠릅니다. 내부 캐시 수명은 다음을 사용하여 각 NetWorker 호스트의 nsrla 데이터베이스에서 설정할 수 있습니다 nsradmin:

Linux/UNIX

printf ". type: nsrla\nshow positive DNS cache TTL; negative DNS cache TTL\nprint\n" | nsradmin -p nsrexec -s remote_host

Windows

(echo . type: nsrla & echo show positive DNS cache TTL; negative DNS cache TTL & echo print) | nsradmin -p nsrexec -s remote_host

기본적으로 30분(1800초)을 반환해야 합니다.

positive DNS cache TTL: 1800;
negative DNS cache TTL: 1800;

이 값은 다음 계층에서 순차적으로 업데이트된 정보를 얻기 위해 의도적으로 프로세스 캐시를 제거하기까지의 시간을 제어합니다. 따라서 DNS 조회 속도가 느리지만 DNS 주소 지정이 비교적 정적인 환경에서는 이 속성을 높이는 것이 적절합니다. 반대로, 주소가 자주 변경되는 환경에서는 낮은 값이 바람직할 수 있습니다. 

NetWorker의 내부 캐시에 필수 이름이 있으면 해당 이름이 사용되고 추가 쿼리가 중지됩니다. 문제를 해결하려면 캐싱된 이름-IP 매핑이 잘못된 것 같으면 명령을 사용하여 현재 캐시를 기록한 다음 항목을 플러시하거나 다시 확인합니다.

• • dbgcommand -n nsrd PrintDnsCache=1 (daemon.raw로 덤프)
  • dbgcommand -n nsrd FlushDnsCache=1 (플러시), 또는, 
  • dbgcommand -n nsrd FlushDnsCache=9 (캐시를 플러시한 후 즉시 다시 해결/재구축)

• • Linux/UNIX: ps -ef | grep nsr 
  • Windows: tasklist | findstr nsr

2. 해석기 캐시:

• • 해결 프로그램 캐시 플러싱은 OS/배포판에 따라 다릅니다. 공급업체 설명서를 참조하십시오.
  • Windows: ipconfig /flushdns

3. 호스트 파일:

• • UNIX/Linux: /etc/hosts
  • Windows: %systemroot%\System32\drivers\etc\hosts

4. 정방향 해석:

• Windows 업그레이드를 실행하라는 프롬프트에 아래 내용이 표시될 때까지 nslookup 대화형 프롬프트를 입력할 인수가 없습니다.
• 조회할 이름을 반복 입력하고 키를 눌러 연결된 DNS 서버에서 정방향 레코드를 검색합니다.
• 동일한 이름을 두 번 더 입력하여 이름 레코드가 서로 다른 호스트 간에 자동으로 라운드 로빈되는지 아니면 동일한 데이터를 반환하는지 확인합니다.
• 호스트가 다른 호스트에 의해 호출되거나 자신을 동일한 IP 주소로 간주하는 이름의 인스턴스에 대해 동일한 프로세스를 반복합니다.
• server next_dns_server를 입력하여 호스트가 잠재적 사용을 위해 구성된 다른 DNS 서버에 대해서도 동일한 프로세스를 반복합니다.

5. 역방향 해석:

• Windows 업그레이드를 실행하라는 프롬프트에 아래 내용이 표시될 때까지 nslookup 대화형 프롬프트를 입력할 인수가 없습니다.
• 집합 입력 q=ptr 을 클릭하여 쿼리 유형을 역방향 영역으로 변경합니다.
• 역방향으로 해석하려는 IP 주소를 입력하고 키를 누릅니다.
• 역방향 레코드에서 반환되는 이름이 정방향 레코드 이름/IP와 일치하는지 확인합니다.

[root@linux_a~]# nslookup linux_a
Server:         1.2.3.4
Address:        1.2.3.4#53
Name:   linux_a.domain.com
Address: 5.6.7.8
         
[root@linux_a~]# nslookup 5.6.7.8
Server:         1.2.3.4
Address:        1.2.3.4#53
Name:   linux_a.domain.com
Address: 5.6.7.8
         
[root@linux_a~]# nslookup
> set q=ptr
> 5.6.7.8
Server:         1.2.3.4
Address:        1.2.3.4#53
Non-authoritative answer:
8.7.6.5.in-addr.arpa        name = linux_a.domain.com.

이름 확인 테스트

모든 NetWorker 호스트는 데이터 영역 역할에 따라 통신하는 모든 호스트의 정방향 및 역방향 이름 확인이 일관적이어야 합니다. NetWorker 관리자가 모든 호스트 해석 문제를 즉각적이고 완벽하게 해결하는 것은 매우 중요합니다.
이름 해석 문제를 해결하거나 NetWorker 데이터 영역에서 제외하려면 다음을 수행합니다.
    1. 서버, 클라이언트, 스토리지 노드 등 실패한 작업과 관련된 모든 호스트를 찾습니다.
    2. 각각에 대해 로컬로 구성된 IP 주소와 해당 IP에 대해 예상되는 해석 가능 이름을 모두 확인합니다.
    3. 호스트 해석을 위해 DNS보다 먼저 호스트 파일을 사용하도록 모든 호스트를 구성합니다.
    4. 한 호스트의 호스트 파일의 시작 부분에서 각 IP에 대해 하나의 항목을 구성합니다. 이때 해당되는 모든 이름은 같은 줄에 있습니다.
    5. 첫 번째 호스트에서 관련된 다른 호스트의 호스트 파일로 해당 줄을 정확하게 복사합니다.
    6. 원하는 IP에 해당하는 별칭을 정확하게 사용하도록 NetWorker 클라이언트 오브젝트를 편집합니다.
    7. 관련된 모든 호스트에서 NetWorker를 종료합니다.
    8. 적절한 운영 체제 메커니즘을 사용하여 각 호스트에서 확인자 캐시를 지웁니다.
    9. NetWorker를 재시작하고 문제가 있는 작업을 다시 시도합니다.

지정된 호스트에서 이름이 확인되었는지 확인하려면 다음 테스트를 사용합니다.
    1. 첫 번째 NetWorker 호스트(예: Client)에서 다음을 사용하여 두 번째 NetWorker 호스트(예: Server)에 연결합니다. nsradmin -s remote_host -p nsrexec - 세션을 열어 둡니다.
    2. 동일한 호스트에서 nsradmin 프로세스(예: Windows, tasklist | findstr nsradmin)
3. netstat를 실행하여 해당 프로세스와 연결된 소켓을 표시합니다(예: Windows, netstat -ao | findstr process_id)
4. 해당 호스트에서 연결 소켓을 확인합니다(출력에서 가장 왼쪽에 있는 IP:port 페어링)
    5. 원격 호스트에서 다음을 실행합니다. netstat -a 및 findstr/grep for :calling_port_from_first_host.
    6. 콜론 앞의 호스트 이름은 인바운드 연결을 수락할 때 두 번째 호스트가 첫 번째 호스트를 확인하는 방법입니다.
    7. 를 사용하여 다시 실행합니다. -n 동일한 소켓의 IP를 확인하고 IP/경로가 예상되는지 확인하기 위해 netstat 명령에 스위치가 추가되었습니다.
    8. 동일한 테스트를 거꾸로 수행하여 두 번째 호스트가 예상 매개변수 내에서 첫 번째 호스트를 확인하는지 확인합니다.

NetWorker Client 별칭 정보

또한 NetWorker에는 해당 클라이언트에 대해 확인할 수 있는 모든 이름을 반영해야 하는 별칭 이라는 모든 클라이언트 인스턴스에 대해 전역으로 사용할 수 있는 구성 가능한 필드가 있습니다. 이렇게 하면 NetWorker가 확인된 여러 이름을 하나의 클라이언트 인스턴스에 연결할 수 있습니다. 예를 들어 client1.domain.prod 는 사용된 IP에 따라 client1.domain.bkup 또는 client1로 나타날 수도 있습니다.

세이브 그룹과 같은 NetWorker 작업에서는 여러 개의 TCP 소켓을 사용합니다. 각각 하나씩, 제어, 데이터 및 인덱스 업데이트에 사용됩니다. 소켓이 일치하지 않는(그러나 유효한) 이름을 사용하는 경우 작업이 실패할 수 있습니다.

• 라운드 로빈은 의도적으로 사용되고 구성되기도 하지만, 일반적으로 예기치 않은 상황이므로 피해야 합니다.
• netstat -a 외부 호스트의 OS 확인 이름을 표시하는 개방/활성 TCP 소켓을 표시합니다. 이는 문제를 식별하는 데 사용할 수 있습니다.
• 네트워크 트래픽이 예기치 않은/원치 않는 어댑터를 사용하는 경우 정적 라우팅이 필요할 수 있으며, 이로 인해 나중에 이름 확인 문제가 발생할 수 있습니다.

다음을 참조하십시오.  NetWorker 프로세스 및 포트