Espero que puedas ayudar. Gracias de antemano.
Tengo un DNS privado de Azure en Azure que está conectado a 4 Vnet en 2 regiones. Leí que puedo poner 2 IP en un solo registro A (por ejemplo, nombre de registro A sql.midomain.local IP1 192.168.1.1/192.168.2.1).
Esperaba que si la VM IP1 estaba apagada, un cliente pudiera resolverse en IP2, pero eso no sucedió. Cuando hago un ping para "sql.domain.local", siempre se resuelve en IP1, a pesar de que esta VM está apagada.
Necesito esto porque necesito más resiliencia si la instancia SQL1 en la región 1 está APAGADA, el cliente aún se conecta a la VM replicada en la región 2. El balanceador de carga interno en Azure admite esto, pero no quiero poner una IP pública en mis SQL para usar el equilibrio de carga externo.
¿Alguna idea de cómo puedo llegar a eso?
PD: Es importante saber que todas las redes virtuales pueden comunicarse entre sí a través del emparejamiento de redes virtuales. Puedo acceder a cualquier máquina virtual en cualquier red virtual.
Respuesta1
Leí que puedo poner 2 IP en un solo Registro A.
No, puedes crear varios registros A (o CNAME, TXT, MX) con el mismo nombre y valores diferentes.
Esperaba que si la VM IP1 estaba apagada, un cliente pudiera resolverse en IP2, pero eso no sucedió. Cuando hago un ping para "sql.domain.local", siempre se resuelve en IP1, a pesar de que esta VM está apagada
Cuando se presentan varias direcciones para un nombre determinado, el clientedeberíapruébalos uno por uno. Esto se describe enRFC 1794. Ping es una herramienta de diagnóstico de bajo nivel; Necesitaría hacer una investigación importante para determinar si su comportamiento aquí es deliberado, anacrónico o simplemente defectuoso.
Los navegadores funcionan de manera muy diferente: el DNS por turnos (rrDNS) es una herramienta muy eficaz para admitir la alta disponibilidad de los servicios HTTP. Pero eso se debe a que implementan la detección de fallas conmuchotiempos de espera más cortos (<1 segundo) que otros clientes TCP. Las configuraciones TCP predeterminadas en la mayoría de los sistemas operativos tienen un tiempo de espera de detección de fallas de 5 minutos o más. Esto también presupone que el cliente TCP cumple correctamente con RFC. Según mi experiencia, Java (o quizás el código de la aplicación que se ejecuta sobre Java) no maneja la resolución DNS como se esperaba.
Una alternativa costosa para proporcionar acceso HA a clientes externos es a través de rutas múltiples TCP. IME con 2 proveedores diferentes, la detección/cambio de conmutación por error tomó al menos 3 minutos y, a veces, ni siquiera sucedió.
Si bien es una excelente solución para brindar alta disponibilidad a clientes externos, no usaría rrDNS como medio para brindar alta disponibilidad para conexiones entre nodos dentro de una infraestructura determinada.
pero no quiero poner una IP pública en mis SQL para usar el equilibrio de carga externo
No exponer sus servidores DBMS en una dirección pública es sensato. No significa que no puedas conectarlos por otros medios. De hecho, si tiene datos transaccionales en su DBMS, entonces realmente,EN REALIDADdebe poder garantizar las comunicaciones entre los nodos de la base de datos. Si está disponible a través de emparejamiento vnet y su aplicación no admite una capacidad de cliente HA intrínseca, eche un vistazo a haproxy o ProxySQL.
OTOH, es posible que su aplicación sea algo sensible a la latencia entre el servidor de aplicaciones y DBMS (por ejemplo, si usa ORM trivial). En cuyo caso, NO será deseable permitir que un servidor de aplicaciones en la ubicación 'A' se conecte a un DBMS en la ubicación 'B'; aquí, rrDNS para pilas aisladas puede resolver parcialmente el problema, pero también debe pensar en la administración de sesiones y la replicación de datos durante conmutación por error/conmutación por recuperación.
Respuesta2
Cuando hago un ping para "sql.domain.local", siempre se resuelve en IP1, a pesar de que esta VM está apagada.
Esto es natural porque el sistema operativo almacenará en caché la dirección IP resuelta durante el tiempo TTL especificado por el servidor DNS.
DNS tiene un mecanismo de operación por turnos que rotará la respuesta cada vez que un cliente pregunta directamente desde ese servidor, pero no fue diseñado para escenarios de conmutación por error como el suyo. No conozco su entorno, pero en general le recomendaré que utilice un proxy inverso.