☰

Breve respuesta

tag-icon • tag-icon azure-networking
Breve respuesta

Mirando lo siguiente: ingrese la descripción de la imagen aquí

Aquí vemos una única cuenta corporativa AZURE X. Consulte "azsql1.database.windows.net". Puede acceder a eso desde las instalaciones.

¿Qué pasaría si, por el bien de los argumentos, tuviera un segundo entorno AZURE? configurado exactamente igual: Cuenta corporativa AZURE Y, con "azsql1.database.windows.net".

Es teórico, pero me gustaría saber cómo resuelve esto el sistema local si uno intenta usar "azsql1.database.windows.net" para un informe de conexión en, por ejemplo, Tableau, Spotfire.

Supongo que de alguna manera necesita saber qué reenviador de DNS usar en qué cuenta corporativa AZURE.

Entonces, perdóname, pero entiendo cosas básicas de resolución de DNS con Internet, bla, bla, bla, pero no soy un experto en redes.

Respuesta1

Para otros lectores con la misma pregunta: ver tambiénDirección que se utilizará para acceder a la dirección IP privada para el recurso AZURE desde las instalacionespara obtener algunos antecedentes.

Antes de comenzar a responder una pequeña corrección a tu pregunta, ya que escribiste "...mismo nombre DNS". Creo que esto es un malentendido, ya que elAzure Cosmos DBes un servicio totalmente gestionado, significaPaaSy como tal tiene nombres únicos. En otras palabras, es imposible que dos servicios de Azure Cosmos DB tengan el mismo nombre DNS. Aún así, no quiero corregir eso en la pregunta, sino que prefiero la referencia como parte de la respuesta, ya que de hecho se trata de un malentendido común. Todo se reduce a la forma en que se diseña la resolución de nombres de una solución híbrida.

Resolver tal escenario es fácil usando nombres DNS únicos (lo cual no es un problema ya que CosmosDB es SaaS y como tal tiene nombres únicos) y asegurándose de que todos los recursos se puedan resolver.

Breve respuesta

Para cada una de sus suscripciones bajo una cuenta corporativa conectada localmente a través de ExpressRoute o VPN, configure unDNS privado de Azurey un reenviador de DNS, que se implementa dentro de la misma subred. Un Hub conecta todo, incluso lo local.

Respuesta larga

Ejemplo hipotético (definición de misión)

Cómo funciona es mejor explicarlo con un ejemplo.

Ante el hipotético "corporativo"NKOTBINC" tiene 3 departamentos:

  • Finanzas
  • ÉL
  • Marketing

Cada departamento opera 2 suscripciones de Azure, una para desarrollo y la otra para carga de trabajo de producción. Así que tenemos que lidiar con al menos seis suscripciones en total para cumplir con los requisitos.

Los requisitos relacionados con la red son los siguientes:

  • Cada suscripción debe tener conectividad local.
  • Cada suscripción puede o no utilizar recursos que se implementan mediante enlaces privados.
  • Debido a restricciones legales, todos los recursos dentro de todas las suscripciones se implementan actualmente dentroregión"Este de EE. UU.".
  • Está previsto ampliar el negocio y eventualmente utilizar otras regiones. Por lo tanto, esto debe ser considerado en la planificación.

Estrategia de implementación

Con este escenario, puede terminar con al menos 7 suscripciones:

  • finanzas de desarrollo
  • prd-finanzas
  • dev-it
  • prd-it
  • marketing de desarrollo
  • prd-marketing
  • Centroque se conecta al sistema local a través de VPN o ExpressRoute.

Las seis suscripciones deben implementar un DNS privado de Azure y un reenviador de DNS. Además, todos ellos utilizan una VNET conectada a la suscripción central del Hub. Entonces, eventualmente terminarás con estos siete dominios DNS internos:

  • dev.finance.eastus.azure.nkotb
  • prd.finance.eastus.azure.nkotb
  • dev.it.eastus.azure.nkotb
  • prd.it.eastus.azure.nkotb
  • dev.marketing.eastus.azure.nkotb
  • prd.marketing.eastus.azure.nkotb
  • hub.eastus.azure.nkotb

NKOTB inc: descripción general de la conectividad de red de alto nivel

La suscripción Hub tiene un segundo conjunto de servidores DNS y reenviadores configurados. Solo este conjunto de servidores DNS conoce los otros siete reenviadores de DNS implementados en los otros dominios y es responsable de la resolución de nombres del dominio "eastus.azure.nkotb". Todos los servidores DNS locales están configurados para reenviar todas las solicitudes de DNS para *.eastus.azure.nkotb a este conjunto de servidores DNS.

Ejemplo 1: DNS interno entre una suscripción y local

Dado que el equipo de finanzas decide implementar una base de datos denominada "Alzheimer" dentro de la suscripción de producción, utilizando un enlace privado. Entonces, el nombre DNS interno (FQDN) para esta base de datos sería alzheimer.prd.finance.eastus.azure.nkotb. Gracias a la resolución de nombres interna que está alineada en todas las suscripciones y también en las instalaciones, este nombre podría resolverse en todas partes dentro de la red corporativa.

Cómo funciona el ejemplo 1

  • Un cliente aleatorio ubicado en las instalaciones solicita al servidor DNS local que resuelva el problema alzheimer.prd.finance.eastus.azure.nkotb.
  • El servidor DNS local no sabe la respuesta, pero está configurado para reenviar todas las solicitudes *.eastus.azure.nkotbal reenviador DNS implementado dentro de la suscripción Hub, y así lo sabe. Se puede acceder a este servidor DNS (a nivel de red), ya que el servidor local está conectado a esta suscripción central a través de ExpressRoute/VPN.
  • El reenviador de DNS implementado dentro de la suscripción central no conoce la respuesta, pero conoce el reenviador de DNS que está implementado en la suscripción de financiación de producción, por lo que la solicitud se reenvía en esta dirección. Se puede acceder a este servidor DNS (a nivel de red), ya que ambas suscripciones se han emparejado con VNET.
  • El servidor DNS y el reenviador implementados en prd.finance.eastus.azure.nkotb pueden resolver la dirección IP de la base de datos y enviar la respuesta a la cadena.
  • El cliente ubicado en las instalaciones recibe la respuesta.
  • Cada solicitud DNS de seguimiento (dentro del TTL del registro) será respondida inmediatamente desde el servidor DNS local, ya que la respuesta se almacenó en caché.

Ejemplo 2: DNS interno entre 2 suscripciones

Dado que el equipo de marketing decide implementar una base de datos llamada "Ballyhoo" dentro de la suscripción de desarrollo, el nombre DNS interno sería ballyhoo.dev.marketing.eastus.azure.nkotb. Al igual que la otra base de datos implementada por finanzas, esta base de datos también se puede resolver localmente. Pero en este escenario, el equipo de TI recopila algunos datos dentro de la suscripción del desarrollador de TI, que deben almacenarse mediante ballyhoo.dev.marketing.eastus.azure.nkotbuna base de datos. Entonces, este escenario describe cómo se puede resolver un registro DNS dentro de 2 suscripciones.

Cómo funciona el ejemplo 2

  • La aplicación de recopilación de datos implementada en la suscripción dev-IT solicita al solucionador de DNS local implementado dentro de la misma VNET la dirección IP de ballyhoo.dev.marketing.eastus.azure.nkotb.
  • El servidor DNS local no sabe la respuesta, pero está configurado para reenviar todas las solicitudes al reenviador DNS implementado dentro de la suscripción Hub, y así lo sabe. Se puede acceder a este servidor DNS (a nivel de red), ya que ambas suscripciones se han emparejado con VNET.
  • El reenviador de DNS implementado dentro de la suscripción del concentrador no conoce la respuesta, pero conoce el reenviador de DNS que está implementado en la suscripción de marketing de desarrollo, por lo que la solicitud se reenvía en esta dirección. Se puede acceder a este servidor DNS (a nivel de red), ya que ambas suscripciones se han emparejado con VNET.
  • El servidor DNS y el reenviador implementados en dev.marketing.eastus.azure.nkotb pueden resolver la dirección IP de la base de datos y enviar la respuesta a la cadena.
  • La aplicación de recopilación de datos recibe la respuesta.
  • Cada solicitud DNS de seguimiento (dentro del TTL del registro) será respondida inmediatamente desde el servidor DNS local, ya que la respuesta se almacenó en caché.

Notas

Su contacto comercial en Azure normalmente le ayuda a planificar estos escenarios, por lo que no tiene que resolverlo todo usted mismo. Hay otros aspectos importantes a considerar durante el proceso de planificación, pero el espacio no permite detallarlos aquí. Realización: suele ser útil incluir al equipo de la red en el proceso desde el principio.

En general, recomiendo encarecidamente utilizar la versión gratuita.Microsoft Learn para Azurepara desarrollar los conocimientos y habilidades necesarios. Para sus dudas, los siguientes cursos serían adecuados:

información relacionada