Compartir a través de

Preguntas más frecuentes (P+F) sobre Traffic Manager

  • Artículo

Introducción a Traffic Manager

¿Qué dirección IP usa el Administrador de tráfico?

Tal y como se explica en la sección sobre Cómo funciona Traffic Manager, este servicio funciona en el nivel de DNS (Sistema de nombres de dominio). Envía respuestas DNS para dirigir a los clientes al punto de conexión de servicio adecuado. Después, los clientes se conectan directamente al punto de conexión de servicio, y no a través del Administrador de tráfico.

Por lo tanto, Traffic Manager no proporciona un punto de conexión o una dirección IP para que los clientes puedan conectarse. Si desea una dirección IP estática para el servicio, esta debe configurarse en el servicio y no en Traffic Manager.

¿Qué tipos de tráfico se pueden enrutar mediante Traffic Manager?

Como se explica en Funcionamiento de Traffic Manager, un punto de conexión de Traffic Manager puede ser cualquier servicio con acceso a Internet que esté hospedado dentro o fuera de Azure. Por lo tanto, Traffic Manager puede redirigir el tráfico que se origina desde la red pública de Internet hacia un conjunto de puntos de conexión que también tienen acceso a Internet. Si tiene puntos de conexión que están dentro de una red privada (por ejemplo, una versión interna de Azure Load Balancer) o usuarios que hacen solicitudes DNS desde dichas redes internas, no puede usar Traffic Manager para redirigir este tráfico.

¿Admite Traffic Manager sesiones temporales?

Tal y como se explica en la sección sobre el funcionamiento de Traffic Manager, este servicio funciona en el nivel de DNS. para dirigir a los clientes al punto de conexión de servicio adecuado. Los clientes se conectan directamente al punto de conexión de servicio, y no a través de Traffic Manager. Por lo tanto, Traffic Manager no ve el tráfico HTTP entre el cliente y el servidor.

Además, la dirección IP de origen de la consulta de DNS que recibe Traffic Manager pertenece al servicio DNS recursivo, no al cliente. Por lo tanto, Traffic Manager no tiene forma de realizar un seguimiento de los clientes individuales y no puede implementar sesiones persistentes. Esta no es una limitación específica de Traffic Manager sino que, más bien, es común en todos los sistemas de administración de tráfico basado en DNS.

¿Por qué obtengo un error HTTP al utilizar Traffic Manager?

Tal y como se explica en la sección sobre el funcionamiento de Traffic Manager, este servicio funciona en el nivel de DNS. para dirigir a los clientes al punto de conexión de servicio adecuado. Después, los clientes se conectan directamente al punto de conexión de servicio, y no a través del Administrador de tráfico. Traffic Manager no ve el tráfico HTTP entre el cliente y el servidor. Por tanto, todos los errores HTTP que obtenga deben provenir de la aplicación. Para que el cliente pueda conectarse a la aplicación, todos los pasos de la resolución DNS deben estar completos. Esto incluye cualquier interacción que tenga Traffic Manager en el flujo de tráfico de la aplicación.

Por tanto, debe llevar a cabo una investigación más extensa centrándose en la aplicación.

El encabezado host HTTP enviado desde el explorador del cliente es la fuente más habitual de problemas. Asegúrese de que la aplicación esté configurada para aceptar el encabezado host correcto para el nombre de dominio que esté usando. Para los puntos de conexión que utilizan Azure App Service, consulte Configuración de un nombre de dominio personalizado para una aplicación web en Azure App Service mediante Traffic Manager.

¿Cómo puedo resolver un problema 500 (error interno del servidor) al usar Traffic Manager?

Si los clientes o aplicaciones reciben un error HTTP 500 al usar Traffic Manager, eso puede deberse a una consulta DNS obsoleta. Para resolver el problema, borre la memoria caché DNS y permita que los clientes generen una nueva consulta DNS.

Si un punto de conexión de servicio no responde, los clientes y las aplicaciones que usen ese punto de conexión no se restablecerán hasta que se actualice la memoria caché DNS. La duración de la memoria caché la determina la propiedad de período de vida (TTL) de cada registro DNS. Para obtener más información, consulte Traffic Manager y la memoria caché DNS.

Consulte también las preguntas más frecuentes de este artículo, que están relacionadas con el tema:

¿Cómo afecta al rendimiento el uso del Administrador de tráfico?

Tal y como se explica en la sección sobre el funcionamiento de Traffic Manager, este servicio funciona en el nivel de DNS. Puesto que los clientes se conectan directamente a los puntos de conexión de servicio, el rendimiento no se verá afectado cuando se utilice Traffic Manager una vez establecida la conexión.

Como Traffic Manager se integra con las aplicaciones en el nivel de DNS, hay que insertar una búsqueda DNS adicional en la cadena de resolución DNS. El impacto del Administrador de tráfico en el tiempo de resolución DNS es mínimo. Traffic Manager usa una red global de servidores de nombres y redes de difusión por proximidad anycast para asegurarse de que siempre se enruten las consultas de DNS en el servidor de nombres disponible más cercano. Además, como las respuestas DNS se almacenan en caché, la latencia DNS adicional que se genera por utilizar Administrador de tráfico se aplica solo a una fracción de las sesiones.

El método Rendimiento enruta el tráfico al punto de conexión más cercano disponible. Como resultado, el impacto en el rendimiento general asociado a este método debería ser mínimo. Cualquier aumento en la latencia de DNS se debería reemplazar por una menor latencia de red al punto de conexión.

¿Qué protocolos de aplicación puedo usar con el Administrador de tráfico?

Tal y como se explica en la sección sobre el funcionamiento de Traffic Manager, este servicio funciona en el nivel de DNS. Una vez finalizada la búsqueda DNS, los clientes se conectan directamente al punto de conexión de la aplicación, y no a través del Administrador de tráfico. Por tanto, la conexión puede usar cualquier protocolo de aplicación. Si selecciona TCP como el protocolo de supervisión, la supervisión del estado del punto de conexión de Traffic Manager puede realizarse sin usar ningún protocolo de aplicación. Si decide comprobar el estado mediante un protocolo de aplicación, el punto de conexión necesita ser capaz de responder a las solicitudes HTTP o HTTPS GET.

¿Puedo usar Traffic Manager con un nombre de dominio desnudo?

Sí. Para obtener información sobre cómo crear un registro de alias para el código Apex del nombre de dominio para hacer referencia a un perfil de Azure Traffic Manager, consulte Configuración de un registro de alias para admitir nombres de dominio de Apex con Traffic Manager.

¿Traffic Manager considera la dirección de subred de cliente cuando controla las consultas de DNS?

Sí. Además de la dirección IP de origen de la consulta DNS (normalmente la dirección IP del resolvedor DNS), Traffic Manager también tiene en cuenta la dirección de subred del cliente si está incluida en la consulta DNS que envía el resolvedor DNS que hace la solicitud en nombre del usuario final. Estas direcciones IP se usan para optimizar los métodos de enrutamiento geográfico, rendimiento y subred. En concreto, RFC 7871: subred de cliente en consultas de DNS que proporciona un mecanismo de extensión para DNS (EDNS0) que puede pasar la dirección de subred de cliente desde las resoluciones que la admiten.

¿Qué es el TTL de DNS y cómo afecta a mis usuarios?

Cuando una consulta de DNS llega a Traffic Manager, establece un valor en la respuesta denominada período de vida (TTL). Este valor, cuya unidad está en segundos, indica a las resoluciones DNS de bajada cuánto tiempo se debe almacenar en caché esta respuesta. Aunque no se garantiza que los solucionadores DNS copien en caché este resultado, el almacenamiento en caché les permite responder a cualquier consulta posterior desde la memoria caché en lugar de ir a los servidores DNS de Traffic Manager. Esto afecta a las respuestas de la manera siguiente:

  • Un TTL más alto reduce el número de consultas que llegan a los servidores DNS de Traffic Manager, que puede reducir el costo de un cliente ya que el número de consultas que se atiende es un uso facturable.
  • Un TTL más alto puede reducir potencialmente el tiempo que se tarda en realizar una búsqueda de DNS.
  • Un TTL con un valor más alto también significa que los datos no reflejan la información de estado más reciente que Traffic Manager ha obtenido mediante sus agentes de sondeo.

¿Cuál es el límite superior e inferior en que puedo establecer el TTL para las respuestas de Traffic Manager?

Puede establecer, en un nivel de perfil, el TTL de DNS tan bajo como 0 segundos y tan alto como 2 147 483 647 segundos (el intervalo máximo compatible con RFC-1035). Un TTL de 0 significa que los solucionadores de DNS de nivel inferior no almacenan en caché las respuestas de las consultas y se espera que todas las consultas lleguen a los servidores DNS de Traffic Manager para su resolución.

¿Cómo puedo comprender el volumen de las consultas que llegan a mi perfil?

Una de las métricas que proporciona Traffic Manager es el número de consultas a las que responde un perfil. Puede obtener esta información en una agregación de nivel de perfil o dividirla aún más para ver el volumen de consultas en las que se devolvieron puntos de conexión específicos. Además, puede configurar alertas para recibir una notificación si el volumen de respuestas de consulta supera las condiciones que haya configurado. Para obtener más detalles, consulte Métricas y alertas de Traffic Manager.

Cuando se elimina un Traffic Manager, ¿cuánto tarda el nombre del perfil en estar disponible para su reutilización?

Al eliminar un perfil de Traffic Manager, el nombre de dominio asociado se reserva durante un período de tiempo. Otros perfiles de Traffic Manager del mismo inquilino pueden reutilizar inmediatamente el nombre. Sin embargo, otro inquilino de Azure no puede usar el mismo nombre de perfil hasta que expire la reserva. Esta característica le permite mantener la autoridad sobre los espacios de nombres que implemente, lo que elimina la preocupación de que otro inquilino pueda tomar el nombre.

Por ejemplo, si el nombre del perfil de Traffic Manager es label1, label1.trafficmanager.net se reserva para el inquilino incluso si elimina el perfil. También se reservan los espacios de nombres secundarios, como xyz.label1 o 123.abc.label1. Cuando expire la reserva, el nombre se pone a disposición de otros inquilinos. El nombre asociado a un perfil deshabilitado se reserva indefinidamente. Para preguntas sobre el período de tiempo por el que se reserva un nombre, póngase en contacto con su representante de cuenta.

Método de enrutamiento del tráfico geográfico de Traffic Manager

¿En qué casos de uso el enrutamiento geográfico resulta útil?

El tipo de enrutamiento geográfico se puede usar en cualquier escenario en el que el cliente de Azure necesite distinguir a sus usuarios en función de las regiones geográficas. Por ejemplo, si usa el método de enrutamiento de tráfico geográfico, puede darle a los usuarios provenientes de regiones específicas una experiencia de usuario distinta de las de otras regiones. Otro ejemplo es cumplir los mandatos de soberanía de datos locales que requieren que los usuarios de una región específica sean atendidos solo por puntos de conexión de dicha región.

¿Cómo decido si debo usar el método de enrutamiento por rendimiento o el método de enrutamiento geográfico?

La diferencia clave entre estos dos populares métodos de enrutamiento es que en el método de enrutamiento por rendimiento el objetivo principal es enviar tráfico al punto de conexión que puede proporcionar la latencia más baja al llamador, mientras que en el método de enrutamiento geográfico el objetivo principal es aplicar una geovalla para los llamadores de manera que pueda enrutarlos deliberadamente a un punto de conexión determinado. La superposición se produce porque hay una correlación entre la proximidad geográfica y una latencia menor, aunque este no es siempre el caso. Puede haber un punto de conexión en una ubicación geográfica diferente que puede ofrecer una mejor experiencia de latencia para el llamador. En ese caso, el enrutamiento por rendimiento envía al usuario a ese punto de conexión, pero el enrutamiento geográfico siempre lo envía al punto de conexión que se haya asignado a su región geográfica. Para aclarar esto, considere el ejemplo siguiente: con el enrutamiento geográfico, puede realizar asignaciones poco comunes, como enviar todo el tráfico de Asia a puntos de conexión en Estados Unidos y todo el tráfico de Estados Unidos a puntos de conexión en Asia. En ese caso, el enrutamiento geográfico hace deliberadamente exactamente lo que ha configurado para hacer y la optimización del rendimiento no es una consideración.

Nota:

Puede haber escenarios en los que necesite funcionalidades de enrutamiento tanto por rendimiento como geográfico. Para estos escenarios, los perfiles anidados pueden ser una excelente opción. Por ejemplo, puede configurar un perfil principal con enrutamiento geográfico donde todo el tráfico de Norteamérica se envía a un perfil anidado con puntos de conexión en EE. UU. y usar el enrutamiento por rendimiento para enviar ese tráfico al mejor punto de conexión dentro de ese conjunto.

¿Cuáles son las regiones que son compatibles con Traffic Manager para el enrutamiento geográfica?

Puede encontrar la jerarquía de países o regiones utilizada por Traffic Manager aquí. Aunque esta página se mantiene actualizada con cualquier cambio que se realice, puede recuperar mediante programación la misma información usando la API de REST de Azure Traffic Manager.

¿Cómo determina Traffic Manager desde dónde consulta un usuario?

Traffic Manager busca la dirección IP de origen de la consulta (probablemente se trata de una resolución DNS local que realiza la consulta en nombre del usuario) y usa una dirección IP interna a la asignación de la región para determinar la ubicación. Esta asignación se actualiza de forma continuada para tener en cuenta los cambios de Internet.

¿Está garantizado que Traffic Manager puede determinar correctamente la ubicación geográfica exacta del usuario en cada caso?

No, Traffic Manager no puede garantizar que la región geográfica que se infiere de la dirección IP de origen de una consulta de DNS siempre corresponde a la ubicación del usuario debido a las razones siguientes:

  • En primer lugar, como se describe en las preguntas más frecuentes anteriores, la dirección IP de origen que vemos es la de un solucionador DNS que realiza la búsqueda en nombre del usuario. Si bien la ubicación geográfica de la resolución DNS es un buen proxy para la ubicación geográfica del usuario, también puede ser distinta dependiendo de la huella del servicio de resolución DNS y el servicio de resolución DNS específico que eligió usar un cliente. Por ejemplo, un cliente ubicado en Malasia podría especificar en la configuración de su dispositivo que se use un servicio de resolución DNS cuyo servidor DNS en Singapur se podría detectar para controlar las resoluciones de consulta de ese usuario o dispositivo. En ese caso, Traffic Manager solo puede ver la dirección IP del solucionador que corresponde a la ubicación de Singapur. Además, consulte la P+F anterior relacionada con la compatibilidad de direcciones de subred de cliente en esta página.

  • En segundo lugar, Traffic Manager usa un mapa interno para traducir la dirección IP a la región geográfica. Aunque este mapa se valida y actualiza continuamente para aumentar su precisión y tener en cuenta la naturaleza en constante evolución de Internet, existe la posibilidad de que nuestra información no sea una representación exacta de la ubicación geográfica de todas las direcciones IP.

¿Un punto de conexión debe encontrarse físicamente en la misma región que la configurada para el enrutamiento geográfico?

No, la ubicación del punto de conexión no impone restricción alguna sobre qué las regiones pueden asignarse a él. Por ejemplo, un punto de conexión en la región de Azure del centro de EE. UU. puede hacer que todos los usuarios de la India se redirijan a él.

¿Se pueden asignar regiones geográficas a puntos de conexión en un perfil que no está configurado para el enrutamiento geográfico?

Sí. Si el método de enrutamiento de un perfil no es geográfico, puede usar la API de REST de Azure Traffic Manager para asignar regiones geográficas a puntos de conexión en dicho perfil. En el caso de los perfiles de tipo de enrutamiento no geográfico, esta configuración se omite. Si cambia después este perfil al tipo de enrutamiento geográfico, Traffic Manager puede usar esas asignaciones.

¿Por qué cuando intento cambiar el método de enrutamiento de un perfil existente a geográfico obtengo un error?

Todos los puntos de conexión en un perfil con una necesidad de enrutamiento geográfico deben tener al menos una región asignada a ellos. Para convertir un perfil existente al tipo de enrutamiento geográfico, primero debe asociar las regiones geográficas a todos sus puntos de conexión mediante la API de REST de Azure Traffic Manager antes de cambiar el tipo de enrutamiento a geográfico. Si usa el portal, tendrá que eliminar primero los puntos de conexión, cambiar el método de enrutamiento del perfil a geográfico y, después, agregar los puntos de conexión junto con su asignación de región geográfica.

Una región puede asignarse a un único punto de conexión en un perfil si está utilizando el método de enrutamiento geográfico. Si ese punto de conexión no es un tipo anidado con un perfil secundario asociado a él, y aunque pase a un estado incorrecto, Traffic Manager le seguirá enviando tráfico, ya que la alternativa de no enviar ningún tráfico no es mejor. Traffic Manager no realiza la conmutación por error a otro punto de conexión, incluso cuando la región asignada es la "principal" de la región asignada al punto de conexión que pasó a un estado incorrecto (por ejemplo, si un punto de conexión con la región España es incorrecto, no se realizará la conmutación por error a otro punto de conexión que tenga asignada la región Europa). Esto se hace para asegurarse de que Traffic Manager respeta los límites geográficos que un cliente ha configurado en su perfil. Para obtener la ventaja de la conmutación por error a otro punto de conexión cuando un punto de conexión pasa a ser incorrecto, se recomienda que las regiones geográficas se asignen a perfiles anidados con puntos de conexión múltiples en lugar de a puntos de conexión individuales. De este modo, si se produce un error en un punto de conexión del perfil secundario anidado, el tráfico puede conmutar por error a otro punto de conexión dentro del mismo perfil secundario anidado.

¿Existen restricciones en la versión de API que admite este tipo de enrutamiento?

Sí, solo la API versión 2017-03-01 y más recientes admiten el tipo de enrutamiento geográfico. Las versiones anteriores de la API no se pueden usar para crear perfiles de enrutamiento geográfico ni para asignar regiones geográficas a puntos de conexión. Si se usa una versión anterior de la API para recuperar perfiles desde una suscripción de Azure, no se devuelve ningún perfil de enrutamiento geográfico. Además, al usar las versiones anteriores de la API, cualquier perfil devuelto que tenga puntos de conexión con una asignación de región geográfica no muestra su asignación de región geográfica.

Métodos de enrutamiento del tráfico de subredes de Traffic Manager

¿En qué casos de uso el enrutamiento de subredes resulta útil?

El enrutamiento de subredes le permite diferenciar la experiencia que proporciona a grupos específicos de usuarios que se identifican mediante la dirección IP de origen de sus solicitudes de DNS. Un ejemplo sería mostrar contenido diferente si los usuarios se están conectando a un sitio web desde su sede corporativa. Otro sería restringir a los usuarios de ciertos ISP (proveedores de servicios de Internet) para tener acceso solo a los puntos de conexión que admiten solo conexiones IPv4 si esos ISP tienen un rendimiento inferior al esperado cuando se usa IPv6.

Otra razón para utilizar el método de enrutamiento de subredes es en conjunción con otros perfiles en un conjunto de perfiles anidados. Por ejemplo, si quiere usar el método de enrutamiento geográfico para establecer una geovalla alrededor de sus usuarios, pero para un ISP específico quiere usar un método de enrutamiento diferente, puede tener un perfil con el método de enrutamiento de subredes como perfil primario y reemplazar ese ISP para utilizar un perfil secundario específico y tener el perfil geográfico estándar para todos los demás.

Nota:

Azure Traffic Manager admite direcciones IPv6 en invalidaciones de subred para perfiles de subred. Esta funcionalidad permite un control más granular sobre el enrutamiento de tráfico en función de la dirección IP de origen de las consultas de DNS, incluidas las direcciones IPv4 e IPv6.

¿Cómo sabe Traffic Manager la dirección IP del usuario final?

Los dispositivos de usuario final suelen utilizar un solucionador DNS para realizar la búsqueda de DNS en su nombre. La dirección IP saliente de estas resoluciones es lo que Traffic Manager ve como la dirección IP de origen. Además, el método de enrutamiento por subred también busca si hay información de subred de cliente extendida (ECS) de EDNS0 que se haya pasado con la solicitud. Si hay información de ECS, esa es la dirección que se usará para determinar el enrutamiento. Si dicha información no existe, la dirección IP de origen de la consulta se usa para fines de enrutamiento.

¿Cómo se pueden especificar direcciones IP al usar el enrutamiento de subredes?

Las direcciones IP para asociar a un punto de conexión se pueden especificar de dos maneras. En primer lugar, puede utilizar la notación octeto decimal de cuatro puntos con direcciones de inicio y final para especificar el intervalo (por ejemplo, 1.2.3.4-5.6.7.8 o 3.4.5.6-3.4.5.6). En segundo lugar, puede usar la notación CIDR para especificar el intervalo (por ejemplo, 1.2.3.0/24). Puede especificar varios intervalos y puede usar ambos tipos de notación en un conjunto de intervalos. Sin embargo, se aplican algunas restricciones.

  • No puede haber superposición de intervalos de direcciones, ya que cada IP solo puede asignarse a un único punto de conexión.
  • La dirección de inicio no puede ser mayor a la dirección final.
  • Para la notación CIDR, la dirección IP que precede a la "/" debe ser la dirección de red de ese intervalo (por ejemplo, 1.2.3.0/24 es válida, pero 1.2.3.4.4/24 NO lo es)

¿Cómo se puede especificar un punto de conexión de reserva al usar el enrutamiento de subredes?

En un perfil con enrutamiento de subred, si tiene un punto de conexión sin subredes asignadas, cualquier solicitud que no coincida con otros puntos de conexión se dirige aquí. Se recomienda encarecidamente tener este punto de conexión de reserva en el perfil, ya que Traffic Manager devuelve una respuesta NXDOMAIN si llega una solicitud y no está asignado a ningún punto de conexión o si se asigna a un punto de conexión incorrecto.

¿Qué ocurre si se deshabilita un punto de conexión en un perfil de tipo de enrutamiento de subredes?

En un perfil con enrutamiento de subredes, si tiene un punto de conexión deshabilitado, Traffic Manager se comporta como si no existieran ese punto de conexión ni las asignaciones de subredes. Si se hubiera recibido una consulta que habría coincidido con su asignación de dirección IP y el punto de conexión está deshabilitado, Traffic Manager devuelve un punto de conexión de reserva (uno sin asignaciones); o bien, si dicho punto de conexión no existe, devuelve una respuesta NXDOMAIN.

Método de enrutamiento del tráfico de varios valores de Traffic Manager

¿En qué casos de uso el enrutamiento multivalor resulta útil?

El enrutamiento de varios valores devuelve múltiples puntos de conexión válidos en una sola respuesta de consulta. La principal ventaja de esto es que, si un punto de conexión está dañado, el cliente tiene más opciones para volver a intentarlo sin hacer otra llamada DNS (lo que podría devolver el mismo valor desde una caché ascendente). Esto se aplica a aplicaciones sensibles a la disponibilidad que desean minimizar el tiempo de inactividad. Otro uso del método de enrutamiento de varios valores es si un punto de conexión tiene doble conexión a direcciones IPv4 e IPv6 y desea dar al llamador ambas opciones para que elija cuándo iniciar una conexión con el punto de conexión.

¿Cuántos puntos de conexión se devuelven cuando se usa el enrutamiento de varios valores?

Puede especificar el número máximo de puntos de conexión que se devolverán y MultiValue devuelve no más que esos puntos de conexión en buen estado cuando se reciba una consulta. El valor máximo posible para esta configuración es 10.

¿Obtendré el mismo conjunto de puntos de conexión cuando se use el enrutamiento de varios valores?

No podemos garantizar la devolución del mismo conjunto de puntos de conexión en cada consulta. Esto también se ve afectado por el hecho de que algunos de los puntos de conexión podrían volverse incorrectos y no se incluirían en la respuesta

Real User Measurements

¿Cuáles son las ventajas de usar Real User Measurements?

Cuando se usa el método de enrutamiento de rendimiento, Traffic Manager selecciona la mejor región de Azure para que se conecte el usuario final, para lo cual inspecciona la IP de origen y la subred de cliente EDNS (si se pasa) y vuelve a comprobar la latencia de red que mantiene el servicio de inteligencia. Mediciones de usuario reales mejora esta operación para la base de usuarios finales ya que su experiencia contribuye a esta tabla de latencia, además de garantizar que esta tabla abarca adecuadamente las redes de usuario final desde donde los usuarios finales se conectan a Azure. De este modo, el usuario final realiza enrutamientos con una mayor precisión.

¿Se puede usar Real User Measurements con regiones que no son de Azure?

Real User Measurements mide la latencia para llegar a las regiones de Azure e informa únicamente a este respecto. Si va a usar el enrutamiento basado en el rendimiento con puntos de conexión hospedados en regiones que no son de Azure, también puede beneficiarse de esta característica al disponer de una mayor información sobre la latencia de la región de Azure representativa que había seleccionado para asociarse con este punto de conexión.

¿Qué método de enrutamiento se beneficia de Real User Measurements?

La información adicional obtenida mediante Real User Measurements solo es aplicable a perfiles que usan el método de enrutamiento de rendimiento. El vínculo Mediciones de usuario reales está disponible en todos los perfiles cuando se visualiza a través de Azure Portal.

¿Es necesario habilitar Real User Measurements para cada perfil por separado?

No, solo es necesario habilitarla una vez por suscripción y toda la información de latencia medida y notificada estará disponible para todos los perfiles.

¿Cómo se desactiva Real User Measurements en una suscripción?

Puede dejar de acumular gastos relacionados con Real User Measurements cuando deja de recopilar y enviar medidas de latencia desde la aplicación cliente. Por ejemplo, cuando se inserta JavaScript de medida en páginas web, puede dejar de usar esta característica quitando el código JavaScript o bien desactivando su invocación cuando se representa la página.

También puede eliminar la clave para desactivar las Mediciones de usuario reales. Una vez eliminada la clave, cualquier medida que se envíe a Traffic Manager con esta clave se descartará.

¿Se puede usar Real User Measurements con aplicaciones cliente que no sean páginas web?

Sí, Mediciones de usuario reales está diseñado para ingerir datos recopilados a través de diferentes tipos de clientes de usuario final. Esta pregunta frecuente se actualiza a medida que se admitan nuevos tipos de aplicaciones cliente.

¿Cuántas medidas se realizan cada vez que se representa la página web habilitada para Real User Measurements?

Cuando se usa Real User Measurements con el código JavaScript de medida proporcionado, cada representación de página da lugar a la realización de seis medidas. Estas se notifican luego al servicio Traffic Manager. Esta característica se cobra en función del número de medidas notificadas al servicio Traffic Manager. Por ejemplo, si el usuario navega fuera de su página web mientras se toman las medidas, pero antes de que se notifique, esas medidas no se tienen en cuenta en la facturación.

¿Existe un retraso antes de que el script de Real User Measurements se ejecute en la página web?

No. No hay ningún retraso programado antes de invocar el script.

¿Se pueden usar las Mediciones de usuario reales solo con las regiones que se quieren medir?

No. Cada vez que se invoque, el script de Mediciones de usuario reales mide un conjunto de seis regiones de Azure, según lo determinado por el servicio. Este conjunto varía entre distintas invocaciones y, cuando se producen muchas de estas invocaciones, la cobertura de medida se distribuye entre distintas regiones de Azure.

¿Se puede limitar el número de medidas realizadas a un número específico?

El código JavaScript de medida se inserta dentro de la página web y se tiene control completo sobre cuándo empezar a usarlo y dejar de usarlo. Siempre que el Traffic Manager reciba una solicitud para que se mida una lista de regiones de Azure, se devuelve un conjunto de regiones.

¿Se pueden ver las medidas realizadas por mis aplicaciones cliente como parte de Real User Measurements?

Dado que la lógica de medida se ejecuta desde la aplicación cliente, se tiene control completo sobre lo que sucede, como ver las medidas de latencia. Traffic Manager no informa una vista agregada de las medidas recibidas con la clave vinculada a su suscripción.

¿Se puede modificar el script de medida proporcionado por Traffic Manager?

Mientras se tiene el control de lo que está insertado en la página web, se recomienda firmemente no realizar cambios en el script de medida para garantizar que las latencias se miden y notifican correctamente.

¿Podrán ver otros usuarios la clave que se usa con Real User Measurements?

Cuando se inserta el script de medida en una página web, otros usuarios pueden ver el script y la clave de Real User Measurements (RUM). Sin embargo, es importante saber que esta clave es diferente del identificador de suscripción y que la genera Traffic Manager con este único fin. Conocer la clave RUM no pone en peligro la seguridad de la cuenta de Azure.

¿Pueden otros usuarios hacer un uso inapropiado de la clave RUM?

Aunque es posible que otros usuarios usen la clave para enviar información incorrecta a Azure, algunas medidas incorrectas no cambiarán el enrutamiento, ya que se tienen en cuenta junto con todas las demás medidas que recibimos. Si necesita cambiar las claves, puede volver a generarlas. En ese momento, la clave antigua se descarta.

¿Es necesario poner el código JavaScript de medida en todas las páginas web?

Real User Measurements ofrece más valor conforme aumenta el número de medidas. Dicho esto, es decisión suya ponerlo en todas las páginas web o en unas cuantas. Nuestra recomendación es comenzar a ponerlo en la página más visitada, donde se espera que un usuario permanezca cinco o más segundos.

¿Puede Traffic Manager identificar la información sobre mis usuarios finales si uso Real User Measurements?

Cuando se usa el código JavaScript de medida proporcionado, Traffic Manager puede ver la dirección IP del cliente de los usuarios finales y la dirección IP de origen de la resolución DNS que usan. Traffic Manager usa la dirección IP del cliente solo después de haberla truncado para no poder identificar el usuario final específico que envió la medida.

¿Es necesario que la página web que realiza las medidas de usuarios reales use Traffic Manager para el enrutamiento?

No, no es necesario que use Traffic Manager. El lado de enrutamiento de Traffic Manager funciona de forma independiente de la parte de Mediciones de usuario reales y, aunque es una buena idea tenerlos a ambos en la misma propiedad web, no es necesario que lo estén.

¿Es necesario hospedar algún servicio en regiones de Azure para usar Real User Measurements?

No, no es necesario hospedar ningún componente del lado servidor en Azure para que funcionen las Mediciones de usuario reales. Azure hospeda y administra la imagen de píxel único descargada por el código JavaScript de medida y el servicio que lo ejecuta en diferentes regiones de Azure.

¿Aumentará el uso de ancho de banda de Azure debido a la utilización de Real User Measurements?

Como se mencionó en la respuesta anterior, Azure es propietario de los componentes del lado servidor de Real User Measurements, y también los administra. Esto significa que el uso de ancho de banda de Azure no aumentará si usa Mediciones de usuario reales. Esto no incluye el uso de ancho de banda al margen de los cargos de Azure. Para reducir el ancho de banda usado, se descarga una imagen de un único píxel para medir la latencia a una región de Azure.

Traffic View

¿Cómo funciona Traffic View?

Traffic View es una característica de Traffic Manager que le ayuda a comprender mejor a sus usuarios y su experiencia. Emplea las consultas que recibe Traffic Manager y las tablas de inteligencia de latencia de red que el servicio mantiene para proporcionarle lo siguiente:

  • Regiones donde residen los usuarios que se conectan a los puntos de conexión en Azure.
  • El volumen de usuarios que se conectan desde estas regiones.
  • Regiones de Azure a las que se enrutan.
  • La experiencia de latencia de los usuarios se enruta a estas regiones de Azure.

Esta información está disponible para que la utilice mediante una superposición de mapa geográfico y vistas tabulares del portal, y también está disponible como datos sin procesar para su descarga.

¿Cuál es el beneficio de usar Traffic View?

Traffic View le proporciona una vista general del tráfico que reciben los perfiles de Traffic Manager. En concreto, se puede usar para entender desde dónde se conecta la base de usuarios e, igualmente importante, cuál es su experiencia de latencia media. Luego, esta información puede usarse para buscar áreas en las que es necesario centrarse, por ejemplo, la expansión de la superficie de Azure a una región que pueda prestar servicio a esos usuarios con una latencia más baja. Otra información que se puede obtener usando Vista de tráfico son los patrones de tráfico a diferentes regiones. Esto puede ayudarle a tomar decisiones sobre si aumentar o reducir la inversión en esas regiones.

¿En qué se diferencia Traffic View de las métricas de Traffic Manager disponibles mediante Azure Monitor?

Azure Monitor se puede usar para comprender en un nivel agregado el tráfico que recibe el perfil y sus puntos de conexión. También permite realizar el seguimiento del estado de mantenimiento de los puntos de conexión mediante la exposición de los resultados de comprobación de mantenimiento. Cuando sea necesario ir más allá y comprender la experiencia del usuario final que se conecta a Azure en un nivel regional, Traffic View puede usarse con esta finalidad.

¿Usa Traffic View información de subred de cliente de EDNS?

Las consultas de DNS que sirve Azure Traffic Manager consideran la información de ECS para aumentar la exactitud del enrutamiento. Sin embargo, cuando se crea el conjunto de datos que muestra desde dónde se conectan los usuarios, Vista de tráfico solo usa la dirección IP de la resolución DNS.

¿Cuántos días de datos usa Traffic View?

La salida de Vista de tráfico incluye los datos de los siete días anteriores al día en que usted ve los datos. Se trata de una ventana móvil y se usan los datos más recientes cada vez que se visita.

¿Cómo controla Traffic View los puntos de conexión externos?

Cuando se usan puntos de conexión externos hospedados fuera de las regiones de Azure en un perfil de Traffic Manager, puede elegir asignarlos a una región de Azure que funcione como un servidor proxy por sus características de latencia (de hecho, esto es necesario si se usa el método de enrutamiento de rendimiento). Si tiene esta asignación de región de Azure, las métricas de latencia de dicha región se usan al crear la salida de Vista de tráfico. Si no se especifica ninguna región de Azure, la información de latencia está vacía en los datos de esos puntos de conexión externos.

¿Es necesario habilitar Traffic View en cada perfil de la suscripción?

Durante el periodo de versión preliminar, Vista de tráfico estaba habilitado en el nivel de suscripción. Como parte de las mejoras que hemos realizado antes de la disponibilidad general, ahora puede habilitar Vista de tráfico en un nivel de perfil, lo que permite una habilitación más granular de esta característica. De forma predeterminada, Vista de tráfico se deshabilita para un perfil.

Nota:

Si habilitó Vista de tráfico en un nivel de suscripción durante la versión preliminar, ahora debe volver a habilitarla para cada perfil de la suscripción.

¿Cómo se desactiva Traffic View?

Puede desactivar Vista de tráfico para cualquier perfil mediante el Portal o la API de REST.

¿Cómo funciona la facturación de Traffic View?

El precio de Traffic View se basa en el número de puntos de datos usados para crear la salida. Actualmente, el único tipo de datos admitido son las consultas que recibe su perfil. Además, solo se le facturará por el procesamiento que se haya realizado cuando haya tenido Vista de tráfico habilitado. Esto significa que, si habilita Traffic View durante un período de tiempo de un mes y lo desactiva en otros momentos, solo los puntos de datos procesados mientras tenía habilitada la característica se tienen en cuenta para la facturación.

Puntos de conexión del Administrador de tráfico

¿Puedo usar el Administrador de tráfico con puntos de conexión de varias suscripciones?

No se pueden usar puntos de conexión de varias suscripciones con Azure Web Apps. Azure Web Apps requiere que cualquier nombre de dominio personalizado usado con Web Apps se use únicamente en una suscripción. No es posible usar Web Apps desde varias suscripciones con el mismo nombre de dominio.

Para otros tipos de punto de conexión, es posible usar Traffic Manager con puntos de conexión de más de una suscripción. En Resource Manager, pueden agregarse puntos de conexión de cualquier suscripción al Administrador de tráfico, siempre y cuando la persona que configura el perfil de este servicio tenga acceso de lectura al punto de conexión. Estos permisos pueden concederse mediante la funcionalidad de control de acceso basado en roles de Azure (RBAC de Azure). Los puntos de conexión de otras suscripciones se pueden agregar mediante Azure PowerShell o la CLI de Azure.

¿Puedo usar Traffic Manager con espacios de ensayo de servicio en la nube?

Sí. Los espacios de ensayo de servicio en la nube se pueden configurar en Traffic Manager como puntos de conexión externos. Las comprobaciones de estado se siguen cobrando a la tarifa Puntos de conexión de Azure.

¿Admite el Administrador de tráfico puntos de conexión IPv6?

Actualmente, Traffic Manager no proporciona servidores de nombres que admitan direcciones IPv6. Pero los clientes IPv6 que se conectan a puntos de conexión IPv6 pueden seguir usando Traffic Manager si el servidor DNS recursivo del cliente admite IPv4. Un cliente no envía solicitudes de DNS directamente a Traffic Manager. En su lugar, el cliente usa un servicio DNS recursivo. Un cliente solo IPv6 envía solicitudes al servicio DNS recursivo por medio de IPv6. Después, el servicio recursivo debe poder ponerse en contacto con los servidores de nombres de Traffic Manager mediante IPv4. Traffic Manager responde con el nombre DNS o la dirección IP del punto de conexión.

¿Puedo usar el Administrador de tráfico con más de una aplicación web en la misma región?

Normalmente, el Administrador de tráfico se utiliza para dirigir el tráfico a las aplicaciones implementadas en diferentes regiones. Sin embargo, también se puede utilizar en los casos en que una aplicación tenga más de una implementación en la misma región. Los puntos de conexión de Azure de Traffic Manager no permiten que se agregue más de un punto de conexión de Web App de la misma región de Azure al mismo perfil de Traffic Manager.

¿Cómo muevo los puntos de conexión de Azure de mi perfil de Traffic Manager a un grupo de recursos o suscripción diferente?

El seguimiento de los puntos de conexión de Azure que están asociados a un perfil de Traffic Manager se realiza mediante sus identificadores de recurso. Cuando un recurso de Azure que se usa como punto de conexión (por ejemplo, una dirección IP pública, un servicio en la nube clásico, una aplicación web u otro perfil de Traffic Manager usado de forma anidada) se mueve a otro grupo de recursos o suscripción, su identificador de recurso cambia. Actualmente, en este caso, debe actualizar el perfil de Traffic Manager. Para ello, debe eliminar primero los puntos de conexión y, después, volver a agregarlos al perfil.

Para obtener más información, consulte Mover un punto de conexión.

¿Admite Azure Traffic Manager mecanismos de extensión IPv6 para DNS (ECS)?

Azure Traffic Manager admite direcciones IPv6 con mecanismos de extensión para DNS (ECS). Esto significa que cuando una consulta DNS incluye información de ECS, Azure Traffic Manager puede usar la dirección IP de origen dentro del ECS para tomar decisiones de enrutamiento inteligentes.

La compatibilidad con ECS IPv6 ofrece varias ventajas:

  • Localización mejorada: teniendo en cuenta la dirección IPv6 en ECS, Traffic Manager puede enrutar a los usuarios al punto de conexión más cercano o más adecuado, lo que mejora la experiencia del usuario con una latencia reducida.
  • Control de tráfico mejorado: ECS IPv6 permite decisiones de enrutamiento de tráfico más granulares, lo que permite una mejor administración del tráfico global y la distribución.

Al usar ECS IPv6, es importante asegurarse de que los puntos de conexión estén configurados correctamente para controlar el tráfico IPv6. Compruebe también que la infraestructura DNS, incluidas las resoluciones recursivas, sea capaz de controlar la información de ECS con direcciones IPv6.

Supervisión de puntos de conexión de Traffic Manager

¿Traffic Manager es resistente a errores de región de Azure?

Traffic Manager es un componente clave de la entrega de aplicaciones de alta disponibilidad en Azure. Para ofrecer alta disponibilidad, Traffic Manager debe tener un grado de disponibilidad excepcionalmente alto y ser resistente a errores regionales.

Por diseño, los componentes de Traffic Manager son resistentes a un error completo de cualquier región de Azure. Esta resistencia se aplica a todos los componentes del Administrador de tráfico: los servidores de nombres DNS, la API, la capa de almacenamiento y el servicio de supervisión del punto de conexión.

En el improbable caso de una interrupción de toda una región de Azure, se espera que Traffic Manager continúe funcionando con normalidad. Las aplicaciones implementadas en varias regiones de Azure pueden confiar en Traffic Manager para dirigir el tráfico a una instancia disponible de su aplicación.

¿Cómo afecta al Administrador de tráfico la elección de la ubicación del grupo de recursos?

El Administrador de tráfico es servicio global individual. No es regional. La elección de la ubicación del grupo de recursos no supone ninguna diferencia con respecto a los perfiles del Administrador de tráfico implementados en dicho grupo de recursos.

Azure Resource Manager requiere que todos los grupos de recursos especifiquen una ubicación, que determina la ubicación predeterminada de los recursos implementados en dicho grupo de recursos. Cuando crea un perfil de Traffic Manager, se crea en un grupo de recursos. Todos los perfiles de Traffic Manager usan global como ubicación, lo que omite la configuración predeterminada del grupo de recursos.

¿Cómo se determina el estado actual de cada punto de conexión?

El estado de supervisión actual de cada punto de conexión, junto con el del perfil global, se muestra en el Portal de Azure. Esta información también está disponible a través de la API de REST, los cmdlets de PowerShell y la CLI de Azure multiplataforma del Monitor de tráfico.

También puede usar Azure Monitor para hacer un seguimiento del mantenimiento de los puntos de conexión y ver una representación visual de los mismos. Para más información sobre cómo usar Azure Monitor, consulte la documentación de supervisión de Azure.

¿Puedo supervisar puntos de conexión HTTPS?

Sí. El Administrador de tráfico admite el sondeo a través de HTTPS. Configure HTTPS como protocolo de la configuración de supervisión.

Traffic Manager no puede proporcionar ninguna validación de certificados, lo que incluye que:

  • Los certificados del lado del servidor no se validan
  • Los certificados SNI del lado del servidor no se validan
  • No se admiten certificados de cliente

¿Uso una dirección IP o un nombre DNS al agregar un punto de conexión?

Traffic Manager admite la adición de puntos de conexión mediante tres formas de referencia: como nombre DNS, como una dirección IPv4 y como una dirección IPv6. Si el punto de conexión se agrega como una dirección IPv4 o IPv6, la respuesta de la consulta es, respectivamente, de tipo de registro A o AAAA. Si el punto de conexión se agregó como un nombre DNS, la respuesta de la consulta es de tipo de registro CNAME. Solo está permitido agregar puntos de conexión como direcciones IPv4 o IPv6 si el punto de conexión es de tipo Externo. Todos los métodos de enrutamiento y la configuración de supervisión son compatibles con los tres tipos de direcciones de punto de conexión.

¿Qué tipos de direcciones IP puedo usar al agregar un punto de conexión?

Traffic Manager permite usar direcciones IPv4 o IPv6 para especificar los puntos de conexión. Hay algunas restricciones que se enumeran a continuación:

  • No se permiten direcciones que correspondan a espacios de dirección IP privada reservados. Estas direcciones incluyen las indicadas en RFC 1918, RFC 6890, RFC 5737, RFC 3068, RFC 2544 y RFC 5771
  • La dirección no puede contener números de puerto (puede especificar los puertos que se usarán en las opciones de configuración del perfil)
  • Dos puntos de conexión en el mismo perfil no pueden tener la misma dirección IP de destino

¿Puedo usar tipos de direccionamiento de punto de conexión diferentes con un único punto de conexión?

No. Traffic Manager no permite mezclar tipos de direccionamiento de punto de conexión dentro de un perfil, excepto en el caso de un perfil con un tipo de enrutamiento multivalor donde puede mezclar tipos de direccionamiento IPv4 e IPv6.

¿Qué ocurre cuando el tipo de registro de la consulta entrante es diferente del tipo de registro asociado con el tipo de direccionamiento de los puntos de conexión?

Cuando se recibe una consulta con un perfil, Traffic Manager busca primero el punto de conexión que debe devolverse según el método de enrutamiento especificado y el estado de mantenimiento de los puntos de conexión. A continuación, examina el tipo de registro solicitado en la consulta entrante y el tipo de registro asociado con el punto de conexión antes de devolver una respuesta basada en la tabla siguiente.

En el caso de perfiles con cualquier método de enrutamiento que no sea de varios valores:

Solicitud de consulta entrante Tipo de punto de conexión Respuesta proporcionada
ANY A / AAAA / CNAME Punto de conexión de destino
A A / CNAME Punto de conexión de destino
A AAAA NODATA
AAAA AAAA / CNAME Punto de conexión de destino
AAAA A NODATA
CNAME CNAME Punto de conexión de destino
CNAME A / AAAA NODATA

En el caso de los perfiles con el método de enrutamiento establecido en varios valores:

Solicitud de consulta entrante Tipo de punto de conexión Respuesta proporcionada
ANY Combinación de A y AAAA Extremos de destino
A Combinación de A y AAAA Solo puntos de conexión de destino de tipo A
AAAA Combinación de A y AAAA Solo puntos de conexión de destino de tipo AAAA
CNAME Combinación de A y AAAA NODATA

¿Puedo usar un perfil con puntos de conexión con direcciones IPv4 / IPv6 en un perfil anidado?

Sí, con la excepción de que un perfil de tipo multivalor no puede ser un perfil primario en un conjunto de perfiles anidados.

Detuve un punto de conexión de una aplicación web en mi perfil de Traffic Manager, pero no recibo tráfico ni siquiera después de haberlo reiniciado. ¿Cómo lo puedo corregir?

Cuando se detiene un punto de conexión de una aplicación web de Azure, Traffic Manager deja de comprobar su mantenimiento y reinicia las comprobaciones de estado solo una vez que detecta que se reinició el punto de conexión. Para evitar este retraso, deshabilite y vuelva a habilitar ese punto de conexión en el perfil de Traffic Manager después de reiniciar el punto de conexión.

¿Puedo usar Traffic Manager incluso si mi aplicación no tiene compatibilidad con HTTP o HTTPS?

Sí. Puede especificar TCP como el protocolo de supervisión y Traffic Manager puede iniciar una conexión TCP y esperar una respuesta del punto de conexión. Si el punto de conexión responde a la solicitud de conexión con una respuesta para establecer la conexión, en el período de tiempo de expiración, entonces ese punto de conexión se marca como correcto.

¿Qué respuestas específicas se necesitan del punto de conexión cuando se usa la supervisión TCP?

Cuando se usa la supervisión TCP, Traffic Manager inicia un protocolo de enlace TCP de tres direcciones mediante el envío de una solicitud SYN al punto de conexión en el puerto especificado. A continuación, espera una respuesta SYN-ACK desde el punto de conexión durante un período de tiempo (especificado en la configuración de tiempo de espera).

  • Si se recibe una respuesta SYN-ACK en el período de tiempo de expiración especificado en la configuración de supervisión, ese punto de conexión se considera correcto. Una confirmación de FIN o FIN-ACK es la respuesta esperada de Traffic Manager cuando finaliza un socket de manera normal.
  • Si se recibe una respuesta SYN-ACK después del tiempo de espera especificado, Traffic Manager responde con un RST para restablecer la conexión.

¿Con qué rapidez Traffic Manager mueve mis usuarios de un punto de conexión incorrecto?

Traffic Manager proporciona varias opciones que pueden ayudarle a controlar el comportamiento de conmutación por error de su perfil de Traffic Manager de la manera siguiente:

  • Puede especificar que Traffic Manager sondee los puntos de conexión más frecuentemente estableciendo el intervalo de sondeo en 10 segundos. Esto garantiza que cualquier punto de conexión que vaya a ser incorrecto se detecte lo antes posible.
  • Puede especificar cuánto tiempo esperar antes de que se agote el tiempo de espera de una solicitud de comprobación de estado (el valor de tiempo de espera mínimo es 5 segundos).
  • Puede especificar cuántos errores pueden producirse antes de que el punto de conexión se marque como incorrecto. Este valor puede ser tan bajo como 0, en cuyo caso el punto de conexión se marca como incorrecto tan pronto como se produzca un error en la primera comprobación de estado. En cambio, con el valor mínimo de 0 para el número de errores permitido puede provocar que los puntos de conexión se quiten de la rotación debido a cualquier problema transitorio que pueda producirse en el momento del sondeo.
  • Puede especificar el período de vida (TTL) para que la respuesta DNS sea tan baja como 0. Esto significa que los solucionadores DNS no pueden almacenar en caché la respuesta y cada nueva consulta obtiene una respuesta que incorpora la información de estado más actualizada que tiene Traffic Manager.

Con estas opciones, Traffic Manager puede proporcionar conmutaciones por error en 10 segundos después de que un punto de conexión se vuelva incorrecto y se realice una consulta DNS en el perfil correspondiente.

¿Cómo puedo especificar diferentes opciones de supervisión para los diferentes puntos de conexión de un perfil?

La configuración de supervisión de Traffic Manager se encuentra en el nivel de perfil. Si necesita usar una configuración de supervisión diferente solo para un punto de conexión, puede realizarse teniendo ese punto de conexión como un perfil anidado cuya configuración de supervisión sea diferente de la del perfil principal.

¿Cómo puedo asignar encabezados HTTP para las comprobaciones de estado de Traffic Manager a mis puntos de conexión?

Traffic Manager permite especificar encabezados personalizados en las comprobaciones de estado de HTTP(S) que inicia en sus puntos de conexión. Si desea especificar un encabezado personalizado, puede hacerlo en el nivel de perfil (se aplica a todos los puntos de conexión) o especificarlo en el nivel del punto de conexión. Si un encabezado se define en ambos niveles, el especificado en el nivel de punto de conexión invalidará el del perfil de nivel 1. Un caso de uso común para esto es especificar encabezados de host para que las solicitudes de Traffic Manager se enruten correctamente a un punto de conexión hospedado en un entorno multiinquilino. Otro caso de uso de esto es identificar solicitudes de Traffic Manager desde registros de solicitudes HTTP(S) de un punto de conexión

¿Qué encabezado host se utiliza en las comprobaciones de estado de punto de conexión?

Si no se proporciona ningún valor de encabezado de host personalizado, el encabezado de host utilizado por Traffic Manager es el nombre DNS del destino del punto de conexión configurado en el perfil, si está disponible.

¿Cuáles son las direcciones IP desde las que proceden las comprobaciones de estado?

Consulte este artículo para aprender a recuperar las listas de direcciones IP de las que pueden originarse las comprobaciones de estado de Traffic Manager. Puede usar la API de REST, la CLI de Azure o Azure PowerShell para recuperar la lista más reciente. Revise las direcciones IP que se muestran para asegurarse de que se permiten las conexiones entrantes de estas direcciones IP en los puntos de conexión para comprobar su estado de mantenimiento.

Ejemplo de uso de Azure PowerShell:

$serviceTags = Get-AzNetworkServiceTag -Location eastus
$result = $serviceTags.Values | Where-Object { $_.Name -eq "AzureTrafficManager" }
$result.Properties.AddressPrefixes

Nota

Las direcciones IP públicas pueden cambiar sin previo aviso. Asegúrese de recuperar la información más reciente mediante la API de detección de etiquetas de servicio o el archivo JSON descargable.

¿Cuántas comprobaciones de estado en mi punto de conexión puedo esperar de Traffic Manager?

El número de comprobaciones de estado de Traffic Manager que llega a su punto de conexión depende de lo siguiente:

  • el valor que haya establecido para el intervalo de supervisión (un intervalo más pequeño significa más solicitudes que llegan a su punto de conexión en cualquier período de tiempo determinado);
  • el número de ubicaciones desde donde se originan las comprobaciones de estado (las direcciones IP desde donde puede esperar estas comprobaciones se muestran en las preguntas más frecuentes anteriores).

¿Cómo puedo recibir notificación de si uno de mis puntos de conexión deja de funcionar?

Una de las métricas que proporciona Traffic Manager es el estado de mantenimiento de los puntos de conexión de un perfil. Puede ver esto como un agregado de todos los puntos de conexión dentro de un perfil (por ejemplo, el 75 % de los puntos de conexión tienen un estado correcto) o en un nivel por punto de conexión. Las métricas de Traffic Manager se exponen a través de Azure Monitor y puede usar sus funcionalidades de alerta para recibir notificaciones cuando se produzca un cambio en el estado de mantenimiento del punto de conexión. Para obtener más información, consulte Métricas y alertas de Traffic Manager.

Perfiles anidados de Traffic Manager

¿Cómo se configuran los perfiles anidados?

Los perfiles anidados de Traffic Manager se pueden configurar mediante Azure Resource Manager y las API de REST del portal clásico, cmdlets de Azure PowerShell y comandos de la CLI de Azure multiplataforma. También se admiten a través del nuevo Azure Portal.

¿Cuántas capas de anidamiento admite el Administrador de tráfico?

Puede anidar perfiles con hasta 10 niveles de profundidad. No se permiten "bucles".

¿Puedo combinar otros tipos de puntos de conexión con perfiles secundarios anidados, en el mismo perfil del Administrador de tráfico?

Sí. No hay ninguna restricción en el modo de combinar puntos de conexión de diferentes tipos dentro de un perfil.

¿Cómo se aplica el modelo de facturación para perfiles anidados?

El uso de perfiles anidados no afecta de forma negativa a los precios.

La facturación de Traffic Manager tiene dos componentes: comprobaciones de estado del punto de conexión y millones de consultas DNS.

  • Comprobaciones de estado del punto de conexión: cuando un perfil secundario se configura como punto de conexión de un perfil primario no se aplica ningún cargo. La supervisión de los puntos de conexión del perfil secundario se factura de la manera habitual.
  • Consultas de DNS: cada consulta se cuenta una sola vez. Las consultas a un perfil primario que devuelven un punto de conexión de un perfil secundario solo se cuentan con respecto al perfil primario.

Para obtener todos los detalles, consulte la página de precios de Traffic Manager.

¿Se ve afectado el rendimiento por el uso de perfiles anidados?

No, no hay ningún efecto sobre el rendimiento derivado del uso de perfiles anidados.

Los servidores de nombres de Traffic Manager atravesarán la jerarquía de perfil internamente cuando se procese cada consulta de DNS. Una consulta de DNS realizada a un perfil primario puede recibir una respuesta de DNS con un punto de conexión de un perfil secundario. Se usará un único registro CNAME, tanto si usa un solo perfil como si usa perfiles anidados. No es necesario crear un registro CNAME para cada perfil de la jerarquía.

¿Cómo calcula Traffic Manager el estado de un punto de conexión anidado en un perfil primario?

El perfil primario no realiza comprobaciones de estado en el perfil secundario directamente. En su lugar, el estado de los puntos de conexión del perfil secundario se usa para calcular el estado general del perfil secundario. Esta información se propaga hacia arriba en la jerarquía del perfil anidado para determinar el estado del punto de conexión anidado. El perfil primario usa este estado agregado para determinar si se puede dirigir el tráfico al perfil secundario.

En la tabla siguiente se describe el comportamiento de las comprobaciones de estado de Traffic Manager para un punto de conexión anidado.

Estado de supervisión de perfiles secundarios Estado de supervisión de extremos principales Notas
Deshabilitado. Se ha deshabilitado el perfil secundario. Detenido El estado del extremo primario es “Detenido”, no “Deshabilitado”. El estado Deshabilitado está reservado para indicar que ha deshabilitado el punto de conexión en el perfil primario.
Degradado. Al menos un punto de conexión de perfil secundario se encuentra en estado Degradado. En línea: el número de puntos de conexión en línea en el perfil secundario es, como mínimo, el valor de MinChildEndpoints.
CheckingEndpoint: el número de puntos de conexión en línea más CheckingEndpoint en el perfil secundario es, como mínimo, el valor de MinChildEndpoints.
Degradado: en caso contrario.		 El tráfico se enruta a un punto de conexión con estado CheckingEndpoint. Si MinChildEndpoints se establece demasiado alto, el punto de conexión siempre se degradará.
En línea. Al menos un punto de conexión de perfil secundario se encuentra en estado En línea. Ningún punto de conexión está en estado Degradado. Consulte más arriba.
CheckingEndpoints. Al menos un punto de conexión de perfil secundario es "CheckingEndpoint". Ningún punto de conexión está "En línea" o "Degradado". Igual que el anterior.
Inactivo. Todos los puntos de conexión de perfil secundario están en estado "Deshabilitado" o "Detenido", o bien se trata de un perfil sin ningún punto de conexión. Detenido

Importante

Al administrar perfiles secundarios en un perfil primario en Azure Traffic Manager, se puede producir un problema si deshabilita y habilita simultáneamente dos perfiles secundarios. Si estas acciones se producen al mismo tiempo, puede haber un breve período en el que ambos puntos de conexión están deshabilitados, lo que hace que el perfil primario entre en un estado en peligro.

Para evitar este problema, tenga cuidado al realizar cambios simultáneos en los perfiles secundarios. Considere la posibilidad de escalonar las acciones para evitar interrupciones no deseadas en la configuración de administración del tráfico.

¿Por qué no puedo agregar puntos de conexión de soporte extendido de Azure Cloud Services a mi perfil de Traffic Manager?

Para agregar puntos de conexión extendidos en la nube de Azure a un perfil de Traffic Manager, el grupo de recursos debe tener compatibilidad con la API de Azure Service Management (ASM). Los perfiles ubicados en el grupo de recursos anterior deben cumplir los estándares de API de ASM, que prohíben la inclusión de puntos de conexión de dirección IP pública o puntos de conexión de una suscripción diferente a la del perfil. Para resolver esto, considere la posibilidad de mover el perfil de Traffic Manager y los recursos asociados a un nuevo grupo de recursos compatible con la API de ASM.

Pasos siguientes: