NetWorker: Prácticas recomendadas de solución de problemas de resolución de nombres

NetWorker depende de la resolución de nombres. Si la resolución de nombres no es correcta y es completamente coherente, pueden surgir problemas en muchas de las operaciones de NetWorker. Dado que NetWorker gestiona datos potencialmente confidenciales, debe garantizar las identidades de los hosts con los que interactúa por diversos medios.

Cualquier cantidad de síntomas en NetWorker pueden ser el resultado de imperfecciones en la resolución de nombres en NetWorker:

• Mensajes de error que indican problemas de búsqueda de nombres hacia delante o hacia atrás.
• Incapacidad de sondear clientes durante el respaldo
• Incapacidad de los clientes para guardar manualmente en el servidor o recuperar.
• Problemas para clonar o acceder a dispositivos del nodo de almacenamiento
• Problemas de navegación o registro de la base de datos de medios.
• El servidor o el nodo de almacenamiento dejan de responder durante el inicio o durante el funcionamiento normal.
• Directorios de índice anidados o con nombre incorrecto
• Errores de cliente configurados erróneamente

Flujo de trabajo de resolución de nombres

Los intentos de resolver un nombre de host utilizado por comando o configuración interna se deben resolver en una dirección IP para poder utilizarse. Los siguientes recursos se comprueban, en el siguiente orden, para ver si el nombre:IP ya se almacenó en caché, deteniéndose cuando se coincide con el nombre. 

1. Caché de nombres de NetWorker: La mayoría de los principales demonios de NetWorker; Vida útil configurable en la base de datos NSRLA 
2. Caché de resolución de host local: Varía según el sistema operativo y difiere la carga de los hosts o las búsquedas de DNS
3. Entradas de archivos de hosts locales: Búsqueda local rápida, pero mantenida manualmente; útil para anular la resolución de DNS
4. Búsquedas de servidores DNS : Se prefiere la industria debido a la administración centralizada, pero es más lenta

1. Almacenamiento en caché de NetWorker:

Los demonios de NetWorker mantienen cachés de nombres internos. Los clientes almacenan en caché los nombres resueltos en nsrexecd, mientras que los demonios principales como nsrd y nsmmdbd mantienen sus propias cachés. Esta es la primera tabla de IP que se comprueba, y la más rápida. La duración de la caché interna se puede configurar en la base de datos nsrla de cada host de NetWorker mediante lo siguiente: 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

Debe devolver 30 minutos de manera predeterminada (1800 segundos):

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

Este valor controla cuánto tiempo transcurre antes de que NetWorker purgue deliberadamente la caché del proceso en favor de información actualizada de las capas siguientes de manera secuencial. Por lo tanto, elevarlo es apropiado para entornos en los que la búsqueda de DNS es lenta, pero el direccionamiento de DNS es relativamente estático. Por el contrario, es posible que se aconsejen valores inferiores para ambientes con direcciones que cambian con frecuencia. 

Si hay un nombre necesario presente en la caché interna de NetWorker, se utiliza y se detienen las consultas. Para la solución de problemas, si las asignaciones de nombre a IP almacenadas en caché parecen incorrectas, utilice comandos para registrar la caché actual y, a continuación, vacíe o vuelva a resolver las entradas:

• • dbgcommand -n nsrd PrintDnsCache=1 (Volcar a daemon.raw)
  • dbgcommand -n nsrd FlushDnsCache=1 (Al ras), o, 
  • dbgcommand -n nsrd FlushDnsCache=9 (Vaciar y volver a resolver/reconstruir la caché de inmediato)

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

2. Caché de resolución:

• • El vaciado de la caché de resolución varía según el SO o la distribución: consulte la documentación del proveedor.
  • Windows: ipconfig /flushdns

3. Archivos de hosts:

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

4. Resolución de reenvío:

• Ejecutar nslookup sin argumentos para ingresar al indicador interactivo.
• Ingrese la iteración del nombre que desea buscar y presione Intro para recuperar el registro de reenvío desde el servidor DNS al que se conectó.
• Ingrese el mismo nombre dos veces más para ver si el registro de nombre realiza operaciones por turnos de forma silenciosa entre diferentes hosts o devuelve los mismos datos.
• Repita el mismo proceso para cualquier instancia de cualquier nombre al que el host pueda ser llamado por otros hosts o que se considere para la misma dirección IP.
• Repita el mismo proceso para cualquier otro servidor DNS en el que el host esté configurado para utilizar potencialmente ingresando al servidor next_dns_server.

5. Resolución inversa:

• Ejecutar nslookup sin argumentos para ingresar al indicador interactivo.
• Ingresar conjunto q=ptr para cambiar el tipo de consulta a Reverse Zone.
• Ingrese la dirección IP para revertir la resolución y presione Intro.
• Asegúrese de que el nombre que se muestra en el registro inverso coincida con el nombre/IP del registro de reenvío.

[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.

Prueba de la resolución de nombres

Todos los hosts de NetWorker deben tener una resolución de nombres hacia adelante e hacia atrás coherente para cualquier host con el que se comuniquen, según su función de zona de datos. Es fundamental que los administradores de NetWorker se aseguren de que cualquier problema de resolución de host se aborde de inmediato y por completo.
Cuando solucione problemas de resolución de nombres o para descartarlos en su zona de datos de NetWorker:
    1. Busque todos los hosts involucrados en la operación fallida: servidor, clientes y posiblemente nodos de almacenamiento, etc.
    2. Para cada uno, determine las direcciones IP configuradas localmente y todos los nombres esperados que puedan resolverse para esas IP.
    3. Configure todos los hosts para usar el archivo de hosts antes de DNS para la resolución de hosts.
    4. Al comienzo del archivo hosts de un host, configure una sola entrada para cada IP, con cada nombre que corresponda en la misma línea.
    5. Copie esas líneas exactamente desde el primer host a los archivos de hosts de los otros hosts involucrados.
    6. Edite los objetos del cliente NetWorker para que los alias correspondan correctamente a las IP deseadas.
    7. Apague NetWorker en todos los hosts involucrados.
    8. Borre la caché de resolución en cada host mediante el mecanismo adecuado del sistema operativo.
    9. Reinicie NetWorker y vuelva a intentar la operación problemática.

Para demostrar que un host determinado resuelve el nombre, utilice esta prueba:
    1. Desde el primer host de NetWorker (por ejemplo, el cliente), conéctese al segundo (por ejemplo, el servidor) mediante nsradmin -s remote_host -p nsrexec - Deja la sesión abierta.
    2. En el mismo host, determine el proceso para nsradmin (por ejemplo, Windows, tasklist | findstr nsradmin)
3. Ejecute netstat para mostrar el socket asociado con ese proceso (por ejemplo, Windows, netstat -ao | findstr process_id)
4. Determine el conector de conexión desde ese host (el emparejamiento de IP:puerto del extremo izquierdo en la salida)
    5. En el host remoto, ejecute netstat -a y findstr/grep para :calling_port_from_first_host.
    6. El nombre de host antes de los dos puntos es la forma en que el segundo host resuelve el primer host cuando acepta la conexión entrante.
    7. Ejecute de nuevo con el comando -n Se agregó el switch al comando netstat para verificar la IP del mismo socket a fin de comprobar si se espera la IP/ruta.
    8. Invierta la misma prueba para asegurarse de que el segundo host resuelva el primer host dentro de los parámetros esperados.

Acerca de los alias de cliente de NetWorker

NetWorker también tiene un campo configurable que es global para todas las instancias de cliente denominado "Alias", que debe reflejar todos los nombres que se pueden resolver para ese cliente. Esto permite que NetWorker vincule varios nombres resueltos a una instancia de cliente. Por ejemplo, client1.domain.prod también puede aparecer como client1.domain.bkup o client1, según la IP utilizada.

Las operaciones de NetWorker, como savegroup, utilizan varios sockets TCP: uno para las actualizaciones de control, otro para los datos y otro para las actualizaciones de índices. Si algún socket utiliza un nombre incoherente (pero válido), la operación puede fallar.

• Round Robin a veces se utiliza y configura intencionalmente, pero generalmente es inesperado y se debe evitar
• netstat -a revela sockets TCP abiertos/activos, que revelan el nombre resuelto por el sistema operativo del host externo: esto se puede utilizar para identificar problemas
• En ocasiones, el enrutamiento estático puede ser necesario cuando el tráfico de red utiliza un adaptador inesperado o no deseado, lo que posteriormente puede provocar problemas de resolución de nombres.

Vea también:  Procesos y puertos de NetWorker