La resolución del Sistema de nombres de dominio (DNS) está al centro de prácticamente todas las conexiones digitales que realiza. Es la forma de navegar por la web, recibir correos electrónicos, ver Netflix, y hacer llamadas por Skype. DNS es el mecanismo que traduce un nombre, como manning.com, a una dirección IP. Cuando quiero aprender un nuevo tema, no necesito recordar 35.166.24.88; simplemente ingreso manning.com en un navegador web y busco los libros que quiero. Los dispositivos de red enrutan el tráfico basado en direcciones IP, así que necesita un enfoque que ayude a aquellos que tenemos mala memoria a hacer cosas como comprar un libro o pedir una pizza en línea.
En los últimos capítulos, hemos dedicado bastante tiempo a aprender cómo compilar aplicaciones que pueden escalar, están altamente disponibles y se distribuyen globalmente. Una de las últimas piezas que falta es cómo dirigir a los clientes de todo el mundo a la instancia de aplicación más adecuada, normalmente la instancia más cercana a ellos. Azure Traffic Manager facilita el enrutamiento automático de los clientes a las instancias de su aplicación basándose en el rendimiento o la ubicación geográfica. En este capítulo, analizaremos cómo puede crear y administrar zonas DNS en Azure y luego cómo utilizar Traffic Manager para enrutar a los clientes con consultas DNS.
¿Qué es Azure DNS?
No necesita una comprensión profunda de cómo funciona DNS para completar este capítulo y usar Azure DNS. La figura 11.2 muestra una descripción general de alto nivel sobre cómo un usuario consulta un servicio DNS para obtener la dirección IP de una aplicación web. Pueden ocurrir una gran cantidad de pasos secundarios alrededor de los pasos 1 y 2, así que si le sobra un poco de tiempo a la hora de almuerzo cuando finalice este capítulo, tómese un tiempo y lea sobre cómo funcionan las consultas DNS y la recursividad.
Azure DNS funciona de la misma manera que cualquier solución DNS existente que pueda utilizar o conocer. Su zona y registros se almacenan en Azure, y los servidores de nombres que responden a las consultas DNS se distribuyen globalmente a través de los centros de datos de Azure.
Azure DNS es compatible con todos los tipos de registros que esperaría en un servicio DNS normal. Se pueden crear tanto registros IPv4 como IPv6. Los tipos de registro son los siguientes:
– A: registros de host IPv4, para dirigir a los clientes a sus aplicaciones y servicios.
– AAAA: registros de host IPv6, para los más entusiastas que utilizan IPv6 para dirigir a los clientes a sus aplicaciones y servicios.
– CNAME: nombre canónico, o alias, registros, como para proporcionar un nombre corto que sea más fácil de usar que el nombre de host completo de un servidor.
– MX: registros de intercambio de correo para distribuir el tráfico de correo electrónico a sus servidores o proveedor de correo.
– NS: registros de servidor de nombres, que incluyen registros generados automáticamente para los servidores de nombres Azure.
– PTR: registros de puntero, para consultas de DNS inversas para asignar direcciones IP a nombres de host.
– SOA: registros de inicio de autoridad, que incluyen registros generados automáticamente para los servidores de nombres Azure.
– SRV: registros de servicio, para proporcionar descubrimiento de servicios de red, por ejemplo, como para identidad.
– TXT: registros de texto, como por ejemplo, para el Marco de protección del remitente (SPF) o DomainKeys Identified Mail (DKIM).
En una configuración típica de DNS, usted configura varios servidores DNS. Incluso con la distribución geográfica de esos servidores para redundancia, los clientes pueden consultar un servidor de nombres al otro lado del mundo. Esos milisegundos necesarios para consultar, resolver y luego solicitar una respuesta para la aplicación web pueden sumarse cuando hay muchos clientes que quieren pedir una pizza.
Una zona DNS Azure se replica globalmente a través de los centros de datos de Azure. La red Anycast garantiza que cuando un cliente realiza una consulta DNS a su dominio, el servidor de nombres disponible más cercano responde a su solicitud. ¿Cómo funciona el enrutamiento Anycast? Normalmente, se anuncia una sola dirección IP en varias regiones. En lugar de usar una simple consulta DNS que resuelve de vuelta a una única dirección IP que solo existe en una ubicación, el enrutamiento Anycast permite que la infraestructura de red determine de forma inteligente de dónde proviene la solicitud, y dirige al cliente a la región publicada más cercana. Este enrutamiento permite a sus clientes conectarse a la aplicación web con mayor rapidez y le proporciona una mejor experiencia general.
No necesita ser un experto en redes para entender completamente cómo funciona esto, ¡Azure lo hace automáticamente! Al combinar Azure DNS con Azure Traffic Manager, no solo devuelve las consultas DNS de los servidores de nombres más cercanos, sino que también conecta a los clientes con la instancia de aplicación más cercana.
Delegación de un dominio real a Azure DNS
Cuando registra un dominio real, su proveedor le proporciona una interfaz de administración y herramientas para administrar ese dominio. Para permitir a los clientes acceder a sus servicios y utilizar la zona y los registros de Azure DNS, delegue la autoridad de su dominio a los servidores de nombres Azure. Esta delegación hace que todas las consultas DNS se dirijan inmediatamente a los servidores de nombres Azure, como se muestra en la figura. Actualmente, Azure no le permite comprar y registrar dominios dentro de la plataforma, por lo que necesita comprar el nombre de dominio a través de un registrador externo y luego dirigir los registros NS a los servidores de nombres Azure.
¿Por qué delegar su DNS a Azure? Para simplificar la administración y las operaciones. Si crea servicios adicionales, ajusta la configuración del equilibrador de carga o desea mejorar los tiempos de respuesta con DNS replicado globalmente, Azure proporciona esa única interfaz de administración para completar esas tareas. Cuando sus zonas DNS se hospedan en Azure, también puede implementar algunas de las funciones de seguridad de Resource Manager que se analizan en el capítulo 6: funciones como control de acceso basado en roles (RBAC) para limitar y auditar el acceso a las zonas DNS y los bloqueos de recursos para evitar la eliminación accidental, o incluso maliciosa, de la zona.
La mayoría de los registradores de dominio proporcionan interfaces y controles más bien básicos para administrar zonas y registros DNS. Para reducir los gastos generales de administración y mejorar la seguridad, Azure DNS le permite utilizar la CLI de Azure, Azure PowerShell o API REST para agregar o editar registros. Los equipos de operaciones pueden utilizar las mismas herramientas y flujos de trabajo para incorporar nuevos servicios; y si se presentan problemas, a menudo es más fácil solucionarlos cuando puede comprobar que DNS funciona según lo esperado, sin introducir la variable de un proveedor DNS externo.
Por lo tanto, si está convencido de que existe una lógica para delegar su dominio a Azure DNS, ¿a qué servidores de nombres Azure dirige su dominio? Si crea una zona DNS Azure, los servidores de nombres se enumeran en el portal, como se muestra en la figura. También puede acceder a estas direcciones de servidor de nombres con la CLI de Azure o Azure PowerShell.
No ha habido ejercicios «Pruébelo ahora» en las páginas anteriores, porque a menos que compre y configure un dominio real, no puede probar cómo enrutar tráfico real. Puede crear una zona DNS Azure sin un dominio real, pero no se puede enrutar ningún tráfico. En la vida real, actualiza los registros NS con su proveedor actual para dirigir las consultas de su dominio a los servidores de nombres Azure. Puede tomar de 24 a 48 horas (aunque normalmente es mucho menos tiempo) para que la delegación de su dominio se propague en la jerarquía global de DNS, este comportamiento puede causar breves interrupciones para los clientes que accedan a su aplicación.
Enrutamiento global y resolución con Traffic Manager
En capítulos anteriores, aprendió acerca de las aplicaciones altamente disponibles que se distribuyen globalmente. El objetivo final es varias instancias de aplicaciones web o VM en diferentes regiones o continentes, que se conectan a una instancia de Cosmos DB cercana. Pero, ¿cómo hace que sus clientes se conecten a la VM o aplicación web más cercana que ejecuta su aplicación?
Azure Traffic Manager es un servicio de red que actúa como un destino central para sus clientes. Usemos el ejemplo de una aplicación web en la dirección www.azure-mol.com. En la figura se proporciona una visión general de cómo Traffic Manager enruta a los usuarios a la aplicación disponible más cercana.
Traffic Manager no realiza la función de un equilibrador de carga del que aprendió en el capítulo 8. Como muestra la figura, Traffic Manager enruta el tráfico a una IP pública. Examinemos el flujo de tráfico un poco más de cerca:
1 El usuario realiza una consulta DNS para www.azuremol.com. Su servidor DNS contacta a los servidores de nombres para azuremol.com (que podrían ser los servidores de nombres Azure si usa Azure DNS) y solicita el registro para www.
2 El host www determina un registro CNAME que dirige a azuremol.trafficmanager.net.
3 El servicio DNS remite la solicitud DNS a los servidores de nombres Azure para trafficmanager.net.
4 A continuación, Traffic Manager examina la solicitud y determina un punto de conexión al cual dirigir al usuario. Se examina el estado y funcionamiento del punto de conexión, así como con los equilibradores de carga Azure. También se revisa el método de enrutamiento de Traffic Manager. Los métodos de enrutamiento que Traffic Manager puede utilizar son los siguientes:
– Prioridad: permite controlar el orden en el que se accede a los puntos de conexión.
– Ponderado: distribuye el tráfico a través de los puntos de conexión basándose en una métrica de ponderación asignada.
– Rendimiento: enrutamiento basado en la latencia de los usuarios a un punto de conexión final para que el usuario reciba el tiempo de respuesta más rápido posible.
– Geográfico: asocia puntos de conexión con una región geográfica y dirige a los usuarios basándose en su ubicación.
5 Traffic Manager devuelve el punto de conexión eastus.cloudapp.net al servicio DNS.
6 El servicio DNS busca el registro DNS para eastus.cloudapp.net y devuelve el resultado de la consulta al cliente.
7 Con la dirección IP del punto de conexión solicitado, el cliente se contacta directamente con la aplicación web. En este punto, el tráfico podría llegar a la dirección IP pública de un equilibrador de carga Azure en lugar de llegar directamente a la VM.
Como puede ver, la función de Traffic Manager es determinar un punto de conexión de aplicación determinado para dirigir a los clientes. Algunas comprobaciones de estado que monitorean el estado de los puntos de conexión, similar a los sondeos de estado del equilibrador de carga que aprendió en el capítulo 8. Además, puede definir una prioridad o un mecanismo de enrutamiento de tráfico ponderado para distribuir a los usuarios a través de un conjunto de puntos de conexión disponibles, similar también al equilibrador de carga. Normalmente, Traffic Manager dirige el tráfico a un equilibrador de carga Azure o Application Gateway o a una implementación de Web Apps.
Azure Front Door
Traffic Manager, que veremos en esta sección, es ideal para distribuir y enrutar el tráfico globalmente. Funciona con cualquier tipo de punto final de Internet, no solo con recursos en Azure. El enrutamiento de tráfico está basado en DNS y no examina la aplicación real en sí.
Si necesita una distribución del tráfico a nivel de aplicación y la capacidad de realizar una descarga TLS/SSL o un enrutamiento de solicitudes HTTP/HTTPS, la puerta de entrada de Azure lo ayuda. Traffic Manager y Front Door ofrecen el mismo tipo de servicio opciones de configuración, pero Front Door está diseñado específicamente para que funcione en el nivel de aplicación. Front Door también tiene algunos trucos de rendimiento fantásticos, como el TCP dividido para interrumpir las conexiones en piezas más pequeñas y reducir la latencia.
En el capítulo 8, analizamos los equilibradores de carga y Application Gateway mencionada, que funciona en el nivel de la aplicación y hace cosas como la descarga de TLS. El enfoque en el capítulo estaba en los equilibradores de carga para ayudarle a aprender los conceptos básicos, con qué Application Gateway se compilaría. Lo mismo ocurre aquí. Nos centramos en Traffic Manager en este capítulo, aunque muchos de los mismos conceptos y opciones de configuración, como las opciones de enrutamiento, también están disponibles para Azure Front Door. Como sucede con la mayoría de las cosas en Azure, lo que se debe utilizar en cada servicio depende de las aplicaciones que se ejecutan y de sus necesidades.
Creación de perfiles de Traffic Manager
Traffic Manager utiliza perfiles para determinar qué método de enrutamiento utilizar y cuáles son los puntos de conexión asociados para una solicitud dada. Para continuar con el tema de los capítulos anteriores sobre una aplicación distribuida globalmente, sus usuarios deben utilizar la aplicación web más cercana a ellos. Si vuelve a observar los métodos de enrutamiento, tiene dos formas de hacerlo:
– Enrutamiento de rendimiento: el cliente se enruta al punto de conexión con la latencia más baja, en relación con el origen de la solicitud. Este método de enrutamiento proporciona cierta inteligencia y siempre permite que Traffic Manager reenvíe al cliente a un punto de conexión disponible.
– Enrutamiento geográfico: el cliente siempre se enruta a un punto de conexión determinado, basándose en el origen de su solicitud. Si el cliente está en Estados Unidos, siempre será dirigido al Este de EE. UU., por ejemplo. Este método de enrutamiento requiere definir las regiones geográficas que se asociarán con cada punto de conexión.
Cuando utiliza el enrutamiento geográfico, tiene un poco más de control sobre los puntos de conexión que utilizan los clientes. Puede haber razones reglamentarias que exigen que los clientes en una región determinada siempre utilicen puntos de conexión en la misma región. Los ejercicios usan puntos de conexión geográficos para mostrar un ejemplo más real, porque hay un truco para el enrutamiento geográfico: debe especificar un perfil secundario, no un punto de conexión directamente.
No pasará nada malo si utiliza el método de enrutamiento geográfico con puntos de conexión, pero la práctica recomendada es utilizar otro perfil de Traffic Manager para pasar el tráfico al punto de conexión final. ¿Por qué? Las regiones solo pueden asociarse con un perfil de Traffic Manager. En los capítulos anteriores sobre alta disponibilidad, siempre debió asegurarse de tener redundancia. Si asocia una región con un punto de conexión determinado y utiliza enrutamiento geográfico, no tiene ninguna opción de conmutación por error si ese punto de acceso final tiene problemas o si hace mantenimiento.
En lugar de ello, los perfiles secundarios anidados permiten establecer una prioridad que siempre dirige el tráfico a un punto de conexión en buen estado. Si el punto de conexión no está en buen estado, el tráfico se va a un punto de conexión alternativo. En la figura, se muestra el tráfico que conmuta por error a una región diferente, aunque también podría crear varias instancias de aplicación web en el Oeste de EE. UU. y utilizar un método de enrutamiento ponderado en el perfil secundario. A medida que comienza a escalar el entorno de aplicación, tómese un tiempo para pensar en la mejor manera de proporcionar alta disponibilidad a los puntos de conexión detrás de Traffic Manager. Para estos ejemplos, creará una conmutación por error entre regiones para ver claramente las diferencias de comportamiento.
Pruébelo ahora
Complete los siguientes pasos para crear los perfiles de Traffic Manager para la aplicación distribuida.
El resto de los ejercicios usan Este de EE. UU. y Oeste de Europa. Si no vive en una de esas regiones, escoja una región que sea más apropiada. Solo recuerde ser coherente a lo largo de los ejercicios. El laboratorio de fin del capítulo muestra la forma en que todo esto funciona en conjunto, pero no se dirigirá correctamente a sus aplicaciones web si vive fuera de Norteamérica o Europa y no cambia las regiones como corresponde.
1 Abra Azure Portal y seleccione el icono Cloud Shell en la parte superior del panel.
2 Cree un grupo de recursos, especificando un nombre para el grupo de recursos, como azuremolchapter11 y una ubicación, como eastus:
az group create –name azuremolchapter11 –location eastus
3 Cree el perfil de Traffic Manager primario. Utilice el método de enrutamiento geográfico y, a continuación, especifique un nombre, como azuremol. El parámetro del nombre DNS indica que debe ser único, así que proporcione un nombre único. El siguiente dominio crea el nombre de host azuremol.trafficmanager.net, que se utiliza para configurar las aplicaciones web en el laboratorio de fin del capítulo:
az network traffic-manager profile create \
–resource-group azuremolchapter11 \
–name azuremol \
–routing-method geographic \
–unique-dns-name azuremol
4 Cree uno de los perfiles de Traffic Manager secundarios. Esta vez, utilice el método de enrutamiento prioritario y el nombre eastus, y especifique otro nombre DNS único, como azuremoleastus:
az network traffic-manager profile create \
–resource-group azuremolchapter11 \
–name eastus \
–routing-method priority \
–unique-dns-name azuremoleastus
5 Cree un perfil más de Traffic Manager secundario con el nombre westeurope y otro nombre DNS único, como azuremolwesteurope:
az network traffic-manager profile create \
–resource-group azuremolchapter11 \
–name westeurope \
–routing-method priority \
–unique-dns-name azuremolwesteurope
6 Ya ha creado una aplicación web un par de veces, así que utilicemos la CLI para crear rápidamente dos planes de App Services y luego una aplicación web en cada plan. Una de estas aplicaciones web está en Este de EE. UU. y la otra en Oeste de Europa. En el laboratorio de fin del capítulo, cargará páginas web de ejemplo a estas aplicaciones web, así que por ahora solo tiene que crear el sitio web vacío y alistarlas para usar un repositorio de Git local.
Cree la aplicación web en Este de EE. UU. de la siguiente manera:
az appservice plan create \
–resource-group azuremolchapter11 \
–name appserviceeastus \
–location eastus \
–sku S1
az webapp create \
–resource-group azuremolchapter11 \
–name azuremoleastus \
–plan appserviceeastus \
–deployment-local-git
7 Cree una segunda aplicación web en Oeste de Europa:
az appservice plan create \
–resource-group azuremolchapter11 \
–name appservicewesteurope \
–location westeurope \
–sku S1
az webapp create \
–resource-group azuremolchapter11 \
–name azuremolwesteurope \
–plan appservicewesteurope \
–deployment-local-git
Distribución global del tráfico a la instancia más cercana
Ha creado los perfiles y puntos de conexión de Traffic Manager, pero el tráfico no puede fluir. Si los clientes se redirigieran a los perfiles, no habría asociación con sus puntos de conexión. El diagrama de la figura muestra cómo debe asociar los puntos de conexión con los perfiles.
Las primeras asociaciones que realice son para sus puntos de conexión de la aplicación web. Recuerde que para una alta disponibilidad, deben estar disponibles ambas aplicaciones web para cada perfil de Traffic Manager. Utilizará un método de enrutamiento prioritario para dirigir todo el tráfico a la aplicación web principal para cada perfil. Si esa aplicación web no está disponible, el tráfico puede conmutar por error al punto de conexión secundario de la aplicación web.
Cuando creó los perfiles de Traffic Manager en la sección, se utilizaron algunos valores predeterminados para las opciones de comprobación de estado y supervisión del punto de conexión. Exploremos cuáles son esas opciones:
– Período de vida (TTL) de DNS: 30 segundos. Define el tiempo que pueden almacenarse en caché las respuestas DNS de Traffic Manager. Un TTL corto garantiza que el tráfico del cliente se enrute adecuadamente cuando se realizan actualizaciones en la configuración de Traffic Manager.
– Protocolo de supervisión del punto de conexión: HTTP. También puede elegir HTTPS o una comprobación TCP básica. Al igual que con los equilibradores de carga, HTTP o HTTPS garantiza que se devuelva una respuesta HTTP 200 OK de cada punto de conexión.
– Puerto: 80. Puerto para comprobar cada punto de conexión.
– Ruta: /. De forma predeterminada, comprueba la raíz del punto de conexión, aunque también puede configurar una página personalizada, como la página de comprobación de estado que utilizan los equilibradores de carga.
– Intervalo de sondeo de puntos de conexión: 30 segundos. La frecuencia con que se comprueba el estado del punto de conexión. El valor puede ser de 10 segundos o 30 segundos. Para realizar sondeos rápidos cada 10 segundos, hay un cargo adicional por punto de conexión.
– Número de errores tolerables: 3. Número de veces que un punto de conexión puede fallar una comprobación de estado antes de que el punto de conexión se marque como no disponible.
– Número de errores tolerables: 10 segundos. Duración antes de que un sondeo se marque como fallido y se vuelva a sondear el punto de conexión.
No es necesario cambiar ninguna de estas opciones predeterminadas. Para cargas de trabajo críticas cuando compila sus propios entornos de aplicaciones en el mundo real, se puede reducir el número de fallas a tolerar o el intervalo de sondeo. Estos cambios garantizan que cualquier problema en el estado se detecte rápidamente y el tráfico se enrute antes a otro punto de conexión.
Pruébelo ahora
Complete los siguientes pasos para asociar los puntos de conexión a los perfiles y finalizar el enrutamiento geográfico:
1 En Azure Portal, busque y seleccione su grupo de recursos. Para este ejercicio, seleccione el perfil de Traffic Manager que creó para Este de EE. UU.
2 Seleccione puntos de conexión en la barra de navegación a la izquierda del perfil y luego seleccione Agregar.
3 Cree un punto de conexión de Azure y escriba un nombre, como eastus.
4 Hay diferentes tipos de recursos de destino; desea usar App Service. Para el recurso de destino, seleccione la aplicación web en Este de EE. UU., como azuremoleastus.
5 Deje la prioridad en 1, acepte cualquier otro valor predeterminado que se pueda estar configurado y, a continuación, seleccione Aceptar.
6 Repita el proceso para agregar otro punto de conexión. Esta vez, nombre el punto de conexión westeurope, seleccione su aplicación web en Oeste de Europa como el Recurso de destino y establezca una prioridad de 100.
Ahora, su perfil de Traffic Manager enumera dos puntos de conexión: uno para la aplicación web en Este de EE. UU. y otro para la aplicación web en Oeste de Europa, como se muestra en la figura. Este enrutamiento basado en prioridades de los puntos de conexión siempre dirige el tráfico a la aplicación web en Este de EE. UU. cuando ese recurso está en buen estado. Si ese recurso no está disponible, hay redundancia para conmutar por error a la aplicación web en Oeste de Europa.
7 Vuelva al grupo de recursos y seleccione el perfil de Traffic Manager para Oeste de Europa.
8 Elija agregar puntos de conexión.
9 Repita los pasos para agregar dos puntos finales y configúrelos como sigue:
– Nombre: westeurope
Recurso de destino: aplicación web en Oeste de Europa
Prioridad: 1
– Nombre: eastus
Recurso de destino: aplicación web en Este de EE. UU.
Prioridad: 100
Ahora, su perfil de Traffic Manager enumera dos puntos de conexión: uno para la aplicación web en Oeste de Europa y otro para la aplicación web en Este de EE. UU., como se muestra en la figura. Ha proporcionado la misma redundancia que el perfil de Traffic Manager anterior, esta vez con todo el tráfico que va a Oeste de Europa cuando está en buen estado y Este de EE. UU. si no lo está.
Solo falta una parte más para este proceso, ¡lo prometo! Recuerde, esta es una práctica recomendada para alta disponibilidad si utiliza Traffic Manager para la distribución global de aplicaciones. En el mundo real, su entorno puede no ser tan complejo. Mire el diagrama para ver los perfiles secundarios y las asociaciones con las aplicaciones web regionales que necesita crear, como se muestra en la figura.
Para dirigir el tráfico basado en la región geográfica, debe definir una región, como Norteamérica, y un perfil anidado, como eastus. Todos los clientes de la región de Norteamérica son dirigidos a este perfil secundario. Configuró las prioridades de ese perfil secundario para que la aplicación web en Este de EE. UU. siempre sirva el tráfico. Pero ha proporcionado una opción redundante para conmutar por error a la aplicación web en Oeste de Europa, según sea necesario.
El inverso sucede para los clientes en Oeste de Europa. Se puede agregar otro punto de conexión para el perfil del Traffic Manager primario, esta vez con Europa como la región que se asociará con el punto de conexión y luego el perfil anidado westeurope. Todo el tráfico europeo se enruta a este perfil, y la aplicación web en Oeste de Europa siempre sirve a la aplicación web. En caso de problemas, el tráfico puede conmutar por error a Este de EE. UU.
Si tiene mandatos de soberanía de directiva o de datos, tales como que el tráfico no puede conmutar por error a una región diferente de esta forma, deberá ajustar la forma en que se configuran los puntos de conexión y los perfiles de Traffic Manager. Puede, por ejemplo, crear varias aplicaciones web en Oeste de Europa, como vimos en la entrada 9. De esta manera, tiene varias instancias de aplicación web que pueden servir a los clientes. O bien, si la aplicación se ejecuta en VM, utilice un conjunto de escalado detrás del equilibrador de carga para perfilar una redundancia similar.
Pruébelo ahora
Aquí es donde importa su propia ubicación regional. Si vive fuera de una de las agrupaciones regionales que se muestran en los perfiles de Traffic Manager, asegúrese de seleccionar su propia región o no podrá acceder a la aplicación web en el laboratorio de fin del capítulo.
Complete los siguientes pasos para asociar los perfiles secundarios con el perfil primario:
1 En Azure Portal, busque y seleccione su grupo de recursos.
2 Seleccione el perfil primario de Traffic Manager. En los ejemplos anteriores, se llamaba azuremol.
3 Seleccione puntos de conexión en la barra de navegación a la izquierda del perfil y luego seleccione Agregar.
4 Cree un punto de conexión que utilice el primer perfil secundario. Defina el tipo como un punto de conexión anidado y proporcione un nombre, como eastus. Como el recurso de destino, seleccione el perfil de Traffic Manager que creó para Este de EE. UU.
5 En Agrupación regional, seleccione Norteamérica/Centroamérica/Caribe en el menú desplegable y, a continuación, seleccione Aceptar.
6 Repita los pasos para agregar otro punto de conexión. Esta vez, nombre el punto de conexión westeurope, defina el recurso de destino en el perfil secundario de Traffic Manager para Oeste de Europa y elija Europa en el menú desplegable para agrupación regional.
Ahora, sus puntos de conexión para el perfil primario enumeran los dos perfiles secundarios, donde cada uno tiene un punto de conexión asociado con la región geográfica adecuada, como se muestra en la figura.
Las aplicaciones web están actualmente configuradas para que solo acepten tráfico en su dominio predeterminado, que tiene el formato webappname.azurewebsites.net. Cuando Traffic Manager dirige a los clientes a las instancias de aplicaciones web, el tráfico parece provenir del dominio del perfil primario, como azuremol.trafficmanager.net. Las aplicaciones web no reconocen este dominio, así que la aplicación web no se cargará.
7 Agregue el dominio del perfil primario de Traffic Manager a las dos instancias de la aplicación web que creó en los pasos 4-6. Si fuera necesario, puede encontrar el nombre de dominio en la página de Información general del perfil primario de Traffic Manager:
az webapp config hostname add \
–resource-group azuremolchapter11 \
–webapp-name azuremoleastus \
–hostname azuremol.trafficmanager.net
az webapp config hostname add \
–resource-group azuremolchapter11 \
–webapp-name azuremolwesteurope \
–hostname azuremol.trafficmanager.net
Ahora, cuando abra la dirección de su perfil principal de Traffic Manager en un navegador web, como por ejemplo https://azuremol.trafficmanager.net, no se puede saber a qué punto de conexión accede, ya que ambas aplicaciones web ejecutan la página web predeterminada. En el laboratorio de fin del capítulo, cargará una página web básica a cada aplicación web para diferenciarlas.
Detengámonos para examinar lo que ha creado con estos ejercicios. Es importante, porque ahora los clientes pueden usar todas las funcionalidades de alta disponibilidad y redundancia de capítulos anteriores, con enrutamiento de tráfico automático que los dirige a la instancia más cercana de su aplicación web. En este capítulo, ha creado lo siguiente:
– Una aplicación web en Este de EE. UU. y otra en Oeste de Europa.
– Perfiles de Traffic Manager que utilizan enrutamiento geográfico para dirigir a todos los clientes de Norteamérica y Centroamérica a la aplicación web de Este de EE. UU. y a todos los clientes en Europa a la aplicación web de Oeste de Europa.
– Directivas secundarias de Traffic Manager con enrutamiento prioritario para usar mediante conmutación por error la región alternativa si la aplicación web principal de la región no está disponible.
En términos de alta disponibilidad:
– Si combina esta configuración con aplicaciones web que escalan automáticamente, tiene un montón de redundancia en este momento.
– Si combina estas aplicaciones web con Cosmos DB, ahora toda su aplicación escala de manera automática y está distribuida globalmente, los clientes siempre acceden a los recursos cercanos a ellos para una latencia más baja en los tiempos de respuesta y un mejor rendimiento.
– Incluso si se enreda con las VM, puede utilizar conjuntos de escalado con equilibradores de carga para proporcionar el mismo entorno altamente disponible y distribuido de manera global.
Y sí, podría reemplazar Traffic Manager con Front Door si necesita utilizar funciones avanzadas de administración de tráfico en el nivel de aplicación.
Sé que los últimos capítulos contienen un montón de cosas nuevas y cada capítulo le ha tomado prácticamente todo su descanso para almorzar a diario. Pero mire hasta dónde llegó la semana pasada. Ahora puede crear una aplicación web con VM IaaS o aplicaciones web PaaS, hacerlas altamente disponibles con carga equilibrada, y dejarlas escalar de manera automática. Puede utilizar una base de datos de Cosmos DB de back-end distribuida globalmente para sus necesidades de bases de datos y puede enrutar de manera automática a los clientes a la instancia regional más cercana de su aplicación, todo con DNS alojado en Azure.
En el laboratorio de fin del capítulo cargará un par de sitios web básicos a sus aplicaciones web, solo para demostrar que Traffic Manager funciona y que el punto de conexión adecuado sirve su tráfico. Si tiene tiempo, puede completar el ejercicio; de lo contrario, relájese. ¡No se lo diremos a su jefe!
Tenemos un capítulo más en esta segunda sección del libro, que trata sobre cómo asegurarse de que sus aplicaciones permanezcan en buen estado: cómo supervisar y solucionar los problemas de sus aplicaciones e infraestructura.
Laboratorio: Implementación de aplicaciones web para ver Traffic Manager en acción
Este ha sido otro capítulo donde hemos pasado mucho contenido, así que este ejercicio debiera seguir compilando musculatura mental de sus habilidades de Azure con aplicaciones web. En el repositorio de ejemplos de GitHub de Azure hay dos páginas web básicas para la aplicación de pizzería en línea. El título de cada página web muestra la ubicación de la aplicación web. Cargue estas páginas web en la instancia pertinente de la aplicación web para ver los flujos de Traffic Manager en práctica:
1 Si fuera necesario, clone el repositorio de ejemplos de GitHub en su Cloud Shell de la siguiente manera:
git clone https://github.com/fouldsy/azure-mol-samples-2nd-ed.git
2 Comience con la página web eastus y repita los pasos siguientes en el directorio westeurope:
cd ~/azure-mol-samples-2nd-ed/11/eastus
3 Inicialice el repositorio Git y agregue la página web básica:
git init && git add . && git commit -m «Pizza»
4 En Azure Portal, la URL de Git Clone aparece en la ventana de Información general de su aplicación web. Copie esta URL y, a continuación, defínala como destino para el sitio HTML de ejemplo en Cloud Shell con el siguiente comando:
git remote add eastus
5 Inserte el sitio HTML de ejemplo en su aplicación web:
git push eastus master
6 Repita estos pasos para el directorio azure-mol-samples-2nd-ed/11/westeurope.
7 Cuando haya terminado, abra el navegador web con el nombre de dominio del perfil de Traffic Manager, como https://azuremol.trafficmanager.net, para ver el flujo de tráfico.
Y bien terminamos un capitulo interesante por el dia de hoy!!!!