Latest / M365.FM – Podcast de Microsoft 365, Copilot e IA en español / Azure Traffic Manager explicado: balanceo de carga DNS, 6 métodos de enrutamiento y failover automático (Doblaje IA)

Transcript

Azure Traffic Manager explicado: balanceo de carga DNS, 6 métodos de enrutamiento y failover automático (Doblaje IA) · M365.FM – Podcast de Microsoft 365, Copilot e IA en español

0:00
Speaker 2: Preparado para 10 días de Microsoft 365, Copilot y Azure
0:04
Speaker 2: y las personas que dan forma al futuro del trabajo.
0:08
Speaker 2: Este enero, M365 con Regresa y lo hace a lo grande.
0:12
Speaker 2: Unas en nuestras sesiones en vivo. Demostraciones reales y conocimientos
0:15
Speaker 2: prácticos de MVP y expertos del sector en todo el mundo.
0:18
Speaker 2: Sin diapositivas genéricas ni palabras de moda interminable. Estamos abordando
0:22
Speaker 2: los desafíos reales. Copilot Studio, agentes de IAA Fabric, Seguridad,
0:26
Speaker 2: Gobernanza y Automatización. Ya sea un profesional de TI, un
0:31
Speaker 2: desarrollador o un líder empresarial, hay sesiones diseñadas para usted.
0:35
Speaker 2: Con 10 días completos, puede explorar múltiples tecnologías y conectarse
0:39
Speaker 2: con una comunidad global. Mírelo en vivo y lleve conocimientos
0:42
Speaker 2: prácticos a su organización. Enero de 2027. 10 días. Una
0:48
Speaker 2: comunidad de Microsoft. La inscripción ya está abierta. Vaya a m365com.net
0:52
Speaker 2: y asegure su lugar hoy mismo. Eso es m365com.net. Únase
1:00
Speaker 2: ahora en m365.com.net y nos vemos en vivo en enero.
1:05
Speaker 2: Bienvenido a otro episodio de Microsoft Knowledge Nuggets. Soy su anfitrión,
1:08
Speaker 2: Mirko Peters. El tema de hoy es Azure Traffic Manager.
1:12
Speaker 2: Imagine que ha creado una aplicación web que quieren usar
1:14
Speaker 2: personas de todo el mundo. Usuarios de Tokio, Londres y
1:16
Speaker 2: San Pablo intentan acceder a su aplicación al mismo tiempo.
1:19
Speaker 2: Pero aquí está el problema. Todos y cada uno de
1:21
Speaker 2: sus usuarios acceden a un servidor de una región, digamos Virginia.
1:25
Speaker 2: El usuario de Tokio espera más de 200 milisegundos por
1:27
Speaker 2: solicitud y el usuario de San Pablo tiene una experiencia
1:29
Speaker 2: aún peor. Y si ese centro de datos de Virginia
1:32
Speaker 2: deja de funcionar, se produce un corte de energía, un
1:34
Speaker 2: corte de red o algo inesperado, toda la aplicación se desconecta.
1:37
Speaker 2: Todos los usuarios en todas partes son un único punto
1:39
Speaker 2: de error y suponen un gran problema.¿ Y si pudieras
1:41
Speaker 2: dirigir a cada usuario a su servidor más cercano, rápido
1:43
Speaker 2: y saludable de forma automática?¿ Qué pasaría si un usuario
1:46
Speaker 2: en Tokio usara un centro de datos de Japón?¿ Si
1:48
Speaker 2: un usuario de Londres recibiese esas datos?¿ Si una región
1:50
Speaker 2: dejara de funcionar y el tráfico se trasladara a otro
1:52
Speaker 2: lugar sin que usted hiciera nada? Eso es exactamente lo
1:55
Speaker 2: que hace Azure Traffic Manager. Y lo hace a nivel
1:56
Speaker 2: de DNS, lo que significa que es más sencillo de
1:58
Speaker 2: lo que crees. Al final de este episodio entenderás qué
2:01
Speaker 2: es realmente Traffic Manager, cómo funcionan sus seis métodos de
2:04
Speaker 2: enrutamiento y cuándo usar cada uno. Toma tu café y empecemos.¿
2:08
Speaker 2: Por qué es importante el enrutamiento de tráfico? Vamos a desglosar.
2:11
Speaker 2: Al oír hablar de equilibrio de carga, muchos piensan en
2:13
Speaker 2: un servidor que distribuye tráfico entre pocas máquinas dentro de
2:16
Speaker 2: un centro de datos. Eso es Azure Load Balancer y
2:18
Speaker 2: funciona muy bien para una única región.¿ Pero qué ocurre
2:20
Speaker 2: cuando los usuarios están repartidos por varios medios? Un usuario
2:23
Speaker 2: de Japón que accede a un servidor de Virginia nunca
2:25
Speaker 2: obtendrá una respuesta rápida. La física de Internet no lo permite.
2:30
Speaker 2: La luz viaja a una velocidad fija y cada salto
2:32
Speaker 2: de red añade un retraso. No se puede solucionar con
2:36
Speaker 2: un mejor código o un servicio más rápido. La cuestión
2:38
Speaker 2: es que las aplicaciones lentas pierden usuarios. Un retraso en
2:40
Speaker 2: un segundo reduce las conversiones en un 7% y una
2:42
Speaker 2: interrupción regional no solo ralentiza las cosas, sino que deja
2:45
Speaker 2: toda la aplicación fuera de línea. Los usuarios no pueden
2:47
Speaker 2: comunicarse con ustedes, los ingresos se detienen y su reputación
2:49
Speaker 2: se ve afectada. Hace 20 años, el enfoque antiguo consistía
2:52
Speaker 2: en crear servidores en cada región y dirigir manualmente a
2:55
Speaker 2: los usuarios al correcto. Actualizabas los registros de NES a
2:58
Speaker 2: Manu Mantenías hojas de cálculo de qué usuarios iban a
3:00
Speaker 2: dónde y rezabas para no cometer un error de una
3:02
Speaker 2: conmutación prueba. Ese enfoque es poco práctico y frágil porque
3:05
Speaker 2: no es escalable y se rompe bajo presión. El nuevo
3:08
Speaker 2: enfoque es un único director de tráfico basado en DNS
3:11
Speaker 2: que elige el mejor punto final por usuario y solicitud.
3:14
Speaker 2: No requiere actualizaciones manuales ni hojas de cálculo frágil. En
3:16
Speaker 2: su lugar, observa dónde está el usuario, comprueba qué puntos
3:19
Speaker 2: finales están en buen estado y devuelve el mejor. Piensa
3:22
Speaker 2: en ello como un sistema de control de tráfico aéreo global,
3:24
Speaker 2: donde cada centro de datos es un aeropuerto y Traffic
3:26
Speaker 2: Manager es la torre de control que dirige a cada
3:28
Speaker 2: usuario al servidor disponible más cercano. Ahí es donde entra
3:30
Speaker 2: el juego Traffic Manager. Hablemos de lo que es en realidad,
3:33
Speaker 2: de lo que es Traffic Manager. Esta es la definición
3:36
Speaker 2: más sencilla. Traffic Manager es un equilibrador de carga basado
3:38
Speaker 2: en DNS que se ejecuta a escala global. Imagílalo como
3:41
Speaker 2: una recepción inteligente, en la entrada a un edificio de
3:43
Speaker 2: oficinas a nivel mundial. Cuando entras, el recepcionista no atiende
3:46
Speaker 2: tus llamadas telefónicas ni procesa tu papeleo. Solo te indica
3:49
Speaker 2: la planta correcta. Eso es todo lo que es el
3:51
Speaker 2: Traffic Manager. Indica a los usuarios el servidor correcto. Esta
3:54
Speaker 2: es la diferencia clave. Traffic Manager nunca ve tu tráfico real.
3:58
Speaker 2: No procesa solicitudes, no inspecciona paquetes ni almacena contenido en caché.
4:01
Speaker 2: Cuando un usuario escribe tu nombre de dominio en su navegador,
4:04
Speaker 2: se envía una consulta DNS. Traffic Manager responde a esa
4:07
Speaker 2: consulta con la dirección IP del mejor punto final, el
4:09
Speaker 2: más cercano, el más saludable, el que has configurado como prioritario.
4:12
Speaker 2: A continuación, el usuario se conecta directamente a ese punto
4:16
Speaker 2: final y Traffic Manager se aparta por completo. Eso significa
4:18
Speaker 2: que añade latencia cero a la ruta del tráfico porque
4:20
Speaker 2: no está en medio de flujo de datos y no
4:22
Speaker 2: puede ralentizar las cosas. También funciona con cualquier punto de conexión,
4:25
Speaker 2: con conexión a internet, servicios de hash source, servidores en
4:28
Speaker 2: otra nube e incluso su propio centro de datos local.
4:30
Speaker 2: Siempre que el punto de conexión tenga una dirección IP
4:32
Speaker 2: pública o un nombre de dominio, Traffic Manager puede enrutarlo.
4:35
Speaker 2: Y como es un servicio global, es resistente a los
4:37
Speaker 2: fallos regionales. Si una región completa de Azure falla, Traffic
4:41
Speaker 2: Manager sigue operando y enruta a los usuarios a puntos
4:43
Speaker 2: de conexión sanos externos. No sé cómo sabe Traffic Manager
4:46
Speaker 2: qué punto de conexión es tan sano. Lo sondea cada
4:48
Speaker 2: 30 segundos de forma predeterminada, enviando una solicitud HTTP o
4:51
Speaker 2: HTTPS a una ruta específica en cada punto de conexión.
4:54
Speaker 2: Si el endpoint responde con un código de estado 200
4:56
Speaker 2: dentro del tiempo de espera, es saludable. Si no responde
4:59
Speaker 2: varias veces seguidas, Traffic Manager lo marca como degradado y
5:02
Speaker 2: deja de enviar usuarios allí. Cuando el punto de conexión
5:05
Speaker 2: se recupera, Traffic Manager también lo detecta y lo vuelve
5:07
Speaker 2: a poner en rotación. Esta monitorización del estado es lo
5:10
Speaker 2: que permite la conmutación automática. Ahora veamos las diferentes formas
5:14
Speaker 2: en que Traffic Manager decide a qué punto final los
5:16
Speaker 2: usuarios son. Ahí es donde entran los métodos de enrutamiento.
5:20
Speaker 2: Enrutamiento prioritario y recuperación fácil ante desastres. El enrutamiento prioritario
5:24
Speaker 2: es el método más sencillo. Clasifica tus puntos finales del
5:27
Speaker 2: 1 al número que tengas. Es esto. Todo el tráfico
5:29
Speaker 2: va a la prioridad 1. Si ese punto final falla,
5:31
Speaker 2: el tráfico cambia a la prioridad 2, luego a la
5:33
Speaker 2: 3 y así sucesivamente. Es una configuración activa. El mundo
5:37
Speaker 2: final se encarga de todo. Los demás esperan entre bastidores.
5:40
Speaker 2: Este es un ejemplo del mundo real. Supongamos que tus
5:42
Speaker 2: servidores principales se ejecutan en el este U y tienes
5:44
Speaker 2: un respaldo en Europa Occidental. Fijas el este de U.
5:47
Speaker 2: Como prioridad 1, Europa Occidental como 2. En funcionamiento normal,
5:50
Speaker 2: todos los usuarios van al este de E. Pero si
5:52
Speaker 2: el este de U sufre una interrupción, ya sea eléctrica
5:55
Speaker 2: o de red, Traffic Manager lo detecta en segundos. Deja
5:58
Speaker 2: de enviar nuevos usuarios al este de U y comienza
6:00
Speaker 2: a redirigirlos a Europa Occidental. Tu aplicación sigue online, es
6:03
Speaker 2: posible que los usuarios no noten que pasó algo. Ahora
6:05
Speaker 2: viene aquí un detalle importante. Los usuarios existentes mantienen su
6:08
Speaker 2: conexión actual. El enrutamiento DNS solo afecta nuevas búsquedas DNS.
6:11
Speaker 2: Por lo tanto, si alguien ya cargó tu aplicación y
6:13
Speaker 2: tiene una sesión activa, esa sesión continúa yendo al punto
6:15
Speaker 2: de conexión original hasta que finalice o caduque la caché
6:17
Speaker 2: de DNS. Por eso debes establecer un TTL de DNS bajo.
6:21
Speaker 2: El punto óptimo es de 30 segundos. Un TTL bajo
6:23
Speaker 2: significa que los solucionadores de DNS comproban si hay actualizaciones
6:26
Speaker 2: con más frecuencia. Así, cuando Traffic Manager cambia los puntos
6:28
Speaker 2: de conexión, el cambio se propaga antes. Un error común
6:30
Speaker 2: que comete la gente es olvidarse de probar la computación
6:32
Speaker 2: por error. Estableces un enrutamiento prioritario, implementas tu región de
6:35
Speaker 2: respaldo y lo das por hecho que funciona. Pero aquí
6:37
Speaker 2: está la cuestión. Tu región de respaldo debe gestionar la
6:39
Speaker 2: carga completa. Si tu servidor principal gestiona un millón de
6:42
Speaker 2: usuarios al día y tu respaldo solo 100.000 en operaciones normales,
6:45
Speaker 2: ese respaldo podría colapsar cuando todo el tráfico se desplace
6:48
Speaker 2: repentinamente hacia él. Prueba tu comunicación por error. Simula una
6:52
Speaker 2: interrupción y observa lo que ocurre. Esa es la única
6:54
Speaker 2: manera de saber si funciona. La prioridad consiste en mantener
6:57
Speaker 2: activa la aplicación durante los fallos.¿ Pero qué pasa con
6:59
Speaker 2: la rapidez para todo? Rutamiento de rendimiento. Velocidad por encima
7:03
Speaker 2: de todo. El enrutamiento de rendimiento funciona distinto al de prioridad.
7:06
Speaker 2: En lugar de decir utilizar siempre este punto de conexión primero,
7:08
Speaker 2: dice enviar a cada usuario el punto de conexión que
7:10
Speaker 2: le proporcione la conexión más rápida. Por tanto, un usuario
7:13
Speaker 2: de Tokio se enruta a un servidor de Japón. Un
7:14
Speaker 2: usuario de Londres se enruta a Irlanda. Un usuario de
7:17
Speaker 2: San Paulo se enruta a Brasil. Todos los usuarios obtienen
7:19
Speaker 2: la experiencia más rápida posible sin importar dónde se encuentren.¿
7:22
Speaker 2: Cómo sabe Traffic Manager qué punto de conexión es el
7:24
Speaker 2: más rápido? Utiliza algo denominado tabla de latencia de Internet.
7:27
Speaker 2: Imagínate que es un mapa que Azure mantiene actualizado. Realiza
7:30
Speaker 2: un seguimiento de la latencia de red real entre diferentes
7:32
Speaker 2: partes del mundo y cada región de Azure. Cuando llega
7:35
Speaker 2: una consulta de DNS, Traffic Manager comprueba dónde se encuentra
7:38
Speaker 2: el solucionador de DNS del usuario, busca en la tabla
7:40
Speaker 2: de latencia y devuelve el punto de conexión que proporciona
7:42
Speaker 2: a ese usuario la latencia más baja. Ahora bien, esto
7:45
Speaker 2: podría sorprenderte. No se basa en la distancia física. Un
7:48
Speaker 2: usuario de la India podría obtener una latencia más baja
7:50
Speaker 2: en el este de EU que en el sudeste asiático,
7:52
Speaker 2: según cómo los cables submarinos y los intercambios de Internet
7:54
Speaker 2: enruten el tráfico en ese momento. La tabla de latencia
7:57
Speaker 2: captura las condiciones reales de la red, no solo la
7:59
Speaker 2: distancia en línea recta. El punto de conexión más cercano
8:02
Speaker 2: no siempre es el que se halla más cerca geográficamente.
8:04
Speaker 2: El enrutamiento de rendimiento es ideal para aplicaciones globales en
8:07
Speaker 2: las que la experiencia del usuario depende de la velocidad.
8:10
Speaker 2: Sitios de comercio electrónico, streaming y herramientas de colaboración en
8:12
Speaker 2: tiempo real, todo donde una respuesta lenta pierde al usuario.
8:15
Speaker 2: Pero hay un problema. No tiene en cuenta cuánta carga
8:17
Speaker 2: está gestionando cada punto de conexión. Si la región del
8:20
Speaker 2: este de U funciona al 95% de su capacidad y
8:23
Speaker 2: la región de Europa Occidental al 20% podría enviar nuevos
8:26
Speaker 2: usuarios al este de E, porque es de la latencia
8:27
Speaker 2: más baja para él. No tiene en cuenta la carga servida.
8:30
Speaker 2: Por lo tanto, normalmente se combina el enrutamiento de rendimiento
8:32
Speaker 2: con otros equilibradores de carga Dentro de cada región, Azure
8:35
Speaker 2: Load Balancer o Application Gateway para gestionar la distribución real
8:38
Speaker 2: del tráfico en los servidores una vez que el usuario
8:40
Speaker 2: llega a la región correcta. El enrutamiento de rendimiento optimiza
8:43
Speaker 2: la velocidad.¿ Pero qué pasa si necesitas controlar cuánto tráfico
8:46
Speaker 2: recibe cada punto final? Enrutamiento ponderado y geográfico. Control y cumplimiento.
8:51
Speaker 2: El enrutamiento de rendimiento es velocidad.¿ Pero qué pasa si
8:53
Speaker 2: quieres controlar exactamente cuánto tráfico recibe cada punto final?¿ O
8:56
Speaker 2: enrutar a los usuarios en función de su ubicación en
8:58
Speaker 2: el mundo? Ahí es donde entra en juego el enrutamiento
9:01
Speaker 2: ponderado y geográfico. Empecemos con el enrutamiento ponderado. Este es
9:03
Speaker 2: exactamente lo que parece. Asignas un peso a cada punto final,
9:07
Speaker 2: un número entre 1 y 1000, luego Traffic Manager. Distribuye
9:10
Speaker 2: el tráfico proporcionalmente en función de esos pesos. Entonces, si
9:13
Speaker 2: tienes un punto final A con un peso de 80
9:15
Speaker 2: y un punto final B con un peso de 20,
9:17
Speaker 2: aproximadamente el 80% de tus usuarios se envían A y
9:20
Speaker 2: el 20% van a B. Matemáticas simples. Ahora bien,¿ por
9:23
Speaker 2: qué querrías hacer eso? Piensa en una versión Canary. Has
9:25
Speaker 2: creado una nueva versión de tu aplicación y quieres probarla
9:27
Speaker 2: con usuarios reales antes de implementarla para todos. configuras un
9:30
Speaker 2: segundo punto de conexión que ejecuta. La nueva versión, le
9:32
Speaker 2: das una ponderación de 5 y le das tu punto
9:34
Speaker 2: de conexión de producción actual. Una ponderación de 95, el
9:36
Speaker 2: 5% de 95, el 5% de tus usuarios acceden a
9:38
Speaker 2: la nueva versión. Observa si hay errores, supervisas el rendimiento
9:41
Speaker 2: y si todo parece bien, aumentas poco a poco la
9:43
Speaker 2: ponderación de la nueva versión, quizá un 20% semana que viene,
9:45
Speaker 2: luego un 50%, luego un 100%. Si algo sale mal,
9:48
Speaker 2: vuelves a bajar la ponderación a 0 y el problema
9:49
Speaker 2: queda controlado. No hay una implementación radical ni se puede
9:52
Speaker 2: revertir una versión defectuosa delante de todos tus usuarios. La
9:54
Speaker 2: misma idea se aplica a las pruebas A-B.¿ Quieres ver
9:56
Speaker 2: si una nueva función mejora la interacción? Envía la mitad
9:59
Speaker 2: de tus usuarios a la versión A y la otra
10:00
Speaker 2: mitad a la versión B usando ponderación en sí. Compara
10:02
Speaker 2: los resultados. O bien estás migrando usuarios de una región
10:05
Speaker 2: a otra. Cambia gradualmente la ponderación de la región antigua
10:08
Speaker 2: a la nueva a lo largo de unas semanas. Sin embargo,
10:10
Speaker 2: hay algo importante que debes entender. En el rotamiento ponderado
10:12
Speaker 2: no es un proceso roto. No alterna entre puntos de
10:14
Speaker 2: conexión una solicitud cada. Es una distribución estadística. En un
10:18
Speaker 2: gran número de solicitudes, el tráfico se divide según tus ponderaciones.
10:21
Speaker 2: Sin embargo, un solo usuario que realiza varias solicitudes podría
10:23
Speaker 2: seguir llegando al mismo punto final porque su solucionador de
10:26
Speaker 2: DNS al resultado, PAC, lo considera es un equilibrio de
10:29
Speaker 2: carga perfecto. Piensa en ello como el control de la
10:31
Speaker 2: proporción general del tráfico a lo largo del tiempo. Hablemos
10:33
Speaker 2: ahora de enrutamiento geográfico. Este enruta a los usuarios en
10:36
Speaker 2: función del origen de su consulta de DNS, país, continente
10:39
Speaker 2: o una región específica. Por ejemplo, un usuario en Alemania
10:42
Speaker 2: es enviado a tu punto final en Frankfurt. Un usuario
10:44
Speaker 2: en Brasil es enviado a tu punto final en San Paulo.
10:47
Speaker 2: ese nivel de granularidad.¿ Por qué usarías esto? La soberanía
10:50
Speaker 2: de los datos nunca. Las normas de la Unión Europea
10:52
Speaker 2: podrían exigir que los datos del usuario se queden en Europa.
10:54
Speaker 2: El enrutamiento geográfico te permite hacer cumplir eso a nivel
10:56
Speaker 2: de NES. Un usuario de Francia resuelve tu dominio y
10:59
Speaker 2: el gestor de tráfico devuelve la dirección IP de tu
11:01
Speaker 2: punto final europeo. Sus datos nunca salen del continente. Lo
11:04
Speaker 2: mismo ocurre con tenerlo localizado. Si quieres que los usuarios
11:06
Speaker 2: de Japón vean una versión en japonés de tu sitio,
11:08
Speaker 2: el enrutamiento geográfico los envía al punto final que sirve
11:11
Speaker 2: ese contenido. Hay una regla clave que debes conocer. Cada
11:14
Speaker 2: región geográfica debe asignarse a un solo punto final. No
11:17
Speaker 2: puedes dividir un solo país en dos puntos finales. Por
11:19
Speaker 2: lo tanto, si tienes usuarios en Alemania y quieres que
11:21
Speaker 2: el 50% vaya a Frankfurt y a Frankfurt y el
11:23
Speaker 2: 50% a Berlín, no puedes hacerlo solo con enrutamiento geográfico.
11:26
Speaker 2: En su lugar, tendrías que usar un perfil anidado. Los
11:28
Speaker 2: perfiles anidados son exactamente lo que parecen. Colocas un perfil
11:31
Speaker 2: de Traffic Manager dentro de otro. Así, en el nivel superior,
11:34
Speaker 2: usas el enrutamiento geográfico para dirigir a los usuarios europeos
11:36
Speaker 2: a un perfil, a los norteamericanos a otro y demás.
11:39
Speaker 2: Dentro de cada uno de esos perfiles, usas el enrutamiento
11:41
Speaker 2: ponderado para dividir el tráfico entre los puntos finales dentro
11:43
Speaker 2: de ese régimen. Geográfico arriba por cumplimiento ponderado dentro para
11:46
Speaker 2: el control. Es una combinación poderosa. Otros dos métodos de
11:49
Speaker 2: enrutamiento cubren escenarios específicos. Echemos un vistazo. Enrutamiento multivalor y
11:54
Speaker 2: de subred para un control detallado. El enrutamiento multivalor es
11:57
Speaker 2: un truco simple pero útil. En lugar de devolver solo
11:59
Speaker 2: un punto final en la respuesta de MS, Traffic Manager
12:02
Speaker 2: envía varias direcciones IP sanas a la vez. Su navegador
12:06
Speaker 2: o aplicación elige la primera de la lista, lo que
12:08
Speaker 2: distribuye la carga sin que el gestor de tráfico tenga
12:10
Speaker 2: que decidir para cada solicitud. Pero hay un truco. El
12:13
Speaker 2: valor múltiple solo funciona con puntos finales IPv4 e IPv6,
12:16
Speaker 2: por lo que no es posible usarlo con servicios de aplicaciones,
12:18
Speaker 2: en la nube, o cualquier punto final que use un
12:20
Speaker 2: nombre de dominio en lugar de una IP. Exclusivamente para
12:23
Speaker 2: puntos finales basados en IP. Sin embargo, cuando los tiene,
12:25
Speaker 2: el sistema es más resistente, porque si una IP falla,
12:27
Speaker 2: el cliente puede probar con otra de la lista sin
12:29
Speaker 2: realizar una nueva búsqueda de DNS. Eso significa una conmutación
12:32
Speaker 2: por error más rápida en el lado del cliente. El
12:34
Speaker 2: enrutamiento de subredes es aún más específico, pero potente cuando
12:36
Speaker 2: lo necesite. Enruta a los usuarios en función de la
12:38
Speaker 2: subred IP de origen de la que proviene su consulta
12:40
Speaker 2: de DNS. Así, puede asignar el rango de IP de
12:42
Speaker 2: su oficina a un punto final de pruebas mientras que
12:44
Speaker 2: el resto obtiene la versión de producción. También puede enrutar
12:47
Speaker 2: a usuarios desde una subred VPN específica a un backend
12:50
Speaker 2: dedicado de pruebas. Imagina un escenario de prueba interna en
12:53
Speaker 2: el que su equipo de desarrollo trabaja desde la oficina.
12:56
Speaker 2: Sus consultas DNS provienen de su rango de IP corporativas
12:59
Speaker 2: y usted asigna ese rango a un entorno de ensayo
13:01
Speaker 2: donde pueden probar la última compilación. Todos los demás en
13:04
Speaker 2: Internet obtienen la versión de producción. Sin URL especiales, sin
13:07
Speaker 2: configuraciones de VPN, solo enrutamiento transparente basado en el origen
13:10
Speaker 2: de la solicitud. Ambos métodos son específicos. La mayoría de
13:13
Speaker 2: las personas utilizarán prioridad, rendimiento, ponderación o geografía para su
13:16
Speaker 2: gestión principal del tráfico. Sin embargo, los valores múltiples y
13:19
Speaker 2: las subredes están ahí. Cuando los necesite, resuelven problemas que
13:21
Speaker 2: los otros métodos no pueden. Supervisión del estado de conmutación
13:23
Speaker 2: por error. Todos estos métodos de enrutamiento dependen de una cosa,
13:26
Speaker 2: saber qué puntos finales están realmente en buen estado. Enrutar
13:29
Speaker 2: el tráfico a un servidor averiado no ayuda a nadie.
13:32
Speaker 2: Hablemos de cómo funciona la supervisión del estado en la práctica.
13:34
Speaker 2: Traffic Manager envía una sonda de estado a cada punto
13:37
Speaker 2: final cada 30 segundos de forma predeterminada y esa sonda
13:39
Speaker 2: es una solicitud HTTP o HTTPS a una ruta específica
13:42
Speaker 2: en su punto final. Espera una respuesta con un código
13:45
Speaker 2: de estado entre 200 y 299 dentro de un periodo
13:47
Speaker 2: de tiempo de espera determinado. Si el punto final responde correctamente,
13:50
Speaker 2: está en buen estado. Si no lo hace, Traffic Manager
13:52
Speaker 2: vuelve a intentar. Tras una cantidad configurable de fallos, 3
13:55
Speaker 2: de forma predeterminada, Traffic Manager marca ese punto de conexión
13:58
Speaker 2: como degradado y lo excluye del imputamiento hasta que vuelva
14:00
Speaker 2: a superar las comprobaciones de estado. Pues configura el intervalo
14:02
Speaker 2: de sondeo y el tiempo de espera. Las comprobaciones más
14:04
Speaker 2: rápidas implican una computación Si estableces el intervalo en 10
14:07
Speaker 2: segundos en lugar de 30, Traffic Manager detecta los fallos
14:10
Speaker 2: antes y redirige el tráfico más rápidamente. Sin embargo, las
14:13
Speaker 2: comprobaciones más rápidas suponen una mayor carga para los puntos
14:15
Speaker 2: de conexión, ya que cada comprobación es una solicitud del
14:17
Speaker 2: servidor de gestión. Por tanto, si tienes miles de puntos
14:19
Speaker 2: de conexión y realizas comprobaciones cada 10 segundos, las solicitudes
14:22
Speaker 2: se acumulan. Por lo tanto, debes equilibrar la velocidad con
14:23
Speaker 2: la sobrecarga. El impacto real de una configuración adecuada de
14:26
Speaker 2: comprobaciones de estado es la diferencia entre una computación por
14:28
Speaker 2: error sin problemas y una falsa alarma que interrumpe el enrutamiento.
14:31
Speaker 2: Si la comprobación es demasiado sensible, podrías marcar un punto
14:34
Speaker 2: de conexión como degradado cuando en realidad está bien. Un
14:37
Speaker 2: pico temporal de latencia, un breve fallo en la red,
14:39
Speaker 2: una consulta lenta a la base de datos. Cualquiera de
14:41
Speaker 2: estos podría desencadenar un falso positivo. Cuando Traffic Manager deja
14:44
Speaker 2: de enviar usuarios a ese punto final, acaba de crear
14:46
Speaker 2: una interrupción que no tenía por qué ocurrir. Este es
14:49
Speaker 2: un error común. Las personas establecen la ruta de la
14:51
Speaker 2: sonda en la raíz de su aplicación, solo una barra diagonal.
14:54
Speaker 2: Eso está bien para una comprobación de estado básica, pero
14:55
Speaker 2: no es lo ideal porque la página raíz podría cargarse
14:58
Speaker 2: lentamente si representa una página completa con consultas de base
15:01
Speaker 2: de datos, imágenes y JavaScript. Un mejor enfoque es crear
15:04
Speaker 2: un punto final de comprobación de estado dedicado. Algo ligero,
15:07
Speaker 2: un punto final simple que devuelva un código de estado
15:09
Speaker 2: a 200 rápidamente y confirme que la aplicación se está ejecutando.
15:11
Speaker 2: Sin consultas a la base de datos, sin procesamiento pesado,
15:14
Speaker 2: solo un latido. De esa manera sus ondas son rápidas,
15:16
Speaker 2: confiables y tienen menos probabilidades de desencadenar falsas alarmas. Permítanme
15:19
Speaker 2: concluir con cuándo debería usar Traffic Manager en comparación con
15:22
Speaker 2: otras opciones. Conclusión y guía de toma de decisión. Este
15:26
Speaker 2: es un resumen rápido. Traffic Manager es un director de
15:28
Speaker 2: tráfico global basado en DNS con 6 métodos de enrutamiento.
15:31
Speaker 2: En realidad no gestiona el tráfico. Simplemente dirige a los
15:34
Speaker 2: usuarios al lugar adecuado en función del método que elijas.
15:36
Speaker 2: El enrutamiento es prioritario para la recuperación. Mantiene tu aplicación
15:39
Speaker 2: activa incluso si toda una región falla. El enrutamiento de
15:43
Speaker 2: rendimiento tiene que ver con el resto. Envía a cada
15:45
Speaker 2: usuario al punto final con la latencia más baja. El
15:48
Speaker 2: enrutamiento ponderado permite hacer despliegues controlados, como lanzamientos canario o
15:51
Speaker 2: pruebas AV. El enrutamiento geográfico gestiona el cumplimiento. Mantienes los
15:56
Speaker 2: datos en la región adecuada según la ubicación de los usuarios.
15:59
Speaker 2: El enrutamiento multivalor es para una distribución simple a nivel
16:01
Speaker 2: de IP en varias direcciones. Y el enrutamiento de su
16:03
Speaker 2: red enruta en función del IP de origen de la
16:05
Speaker 2: consulta DNS. Ahora, hablemos de dónde encaja Traffic Manager en
16:08
Speaker 2: una arquitectura real. Piénselo.