Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
El alojamiento multisitio le permite configurar más de una aplicación web en el mismo puerto de los gateways de aplicaciones mediante listeners públicos. Permite configurar una topología más eficaz para las implementaciones al agregar hasta 100 sitios web a una puerta de enlace de aplicaciones. Cada sitio web puede dirigirse a su propio grupo de backends. Por ejemplo, tres dominios, contoso.com, fabrikam.com y adatum.com, señalan a la dirección IP de la puerta de enlace de aplicaciones. Crearía tres clientes de escucha multisitio y configuraría cada uno con la configuración respectiva de protocolo y puerto.
También puede definir nombres de host con el carácter comodín en un cliente de escucha de varios sitios y hasta cinco nombres de host por cliente de escucha. Para obtener más información, consulte los nombres de host comodín en el listener.
Importante
Las reglas se procesan en el orden en que se enumeran en el portal para la SKU v1. Para la SKU v2, use la prioridad de las reglas para especificar el orden de procesamiento. Es muy recomendable configurar a los agentes de escucha multisitio antes de configurar un agente de escucha básico. Esto garantiza que el tráfico se dirija al servidor de back-end adecuado. Si un agente de escucha básico aparece en primer lugar y coincide con una solicitud entrante, lo procesa ese agente de escucha.
Las solicitudes para http://contoso.com se enrutan a ContosoServerPool y para http://fabrikam.com se enrutan a FabrikamServerPool.
De forma similar, puede hospedar varios subdominios del mismo dominio principal en la misma implementación de la puerta de enlace de aplicaciones. Por ejemplo, puede hospedar http://blog.contoso.com y http://app.contoso.com en la misma implementación de puerta de enlace de aplicaciones.
Orden de evaluación de las reglas de enrutamiento de solicitudes
Para asegurarse de que el tráfico del cliente se enrute al back-end preciso al usar clientes de escucha de varios sitios, es importante que las reglas de enrutamiento de solicitudes se presenten en el orden correcto.
Por ejemplo, si tiene 2 agentes de escucha con los nombres de host asociados *.contoso.com y shop.contoso.com, el agente de escucha con el nombre de host shop.contoso.com debe procesarse antes que el agente de escucha con el nombre de host *.contoso.com. Si el cliente de escucha con *.contoso.com se procesa primero, el cliente de escucha shop.contoso.com más específico no recibiría tráfico de clientes.
El orden de las reglas se puede establecer especificando un valor en el campo Prioridad para las reglas de enrutamiento de solicitudes asociadas a los agentes de escucha. Puede especificar un valor entero de 1 a 20000, siendo 1 la prioridad más alta y 20000 la prioridad más baja. Si el tráfico entrante del cliente coincide con varios escuchas, se usa la regla de enrutamiento de solicitudes con la prioridad más alta para procesar la solicitud. Cada regla de enrutamiento de solicitudes debe tener un valor de prioridad único.
El campo de prioridad solo afecta al orden de evaluación de una regla de enrutamiento de solicitudes; esto no cambiará el orden de evaluación de las reglas basadas en rutas de acceso dentro de una PathBasedRouting regla de enrutamiento de solicitudes.
Nota:
Si desea usar la prioridad de regla, tendrá que especificar valores de campo de prioridad de regla para todas las reglas de enrutamiento de solicitudes existentes. Una vez que el campo de prioridad de la regla esté en uso, cualquier nueva regla de enrutamiento que se cree también tendría que tener un valor de campo de prioridad de regla como parte de su configuración.
Importante
A partir de la versión de API 2021-08-01, el campo de prioridad de regla es un campo obligatorio en las reglas de enrutamiento de solicitudes. Los valores del campo de prioridad de las reglas de enrutamiento de solicitudes existentes, basados en el orden actual de evaluación durante la primera llamada PUT, se completarán automáticamente si se aplican actualizaciones de configuración mediante la versión 2021-08-01 de la API y posteriores, el portal, Azure PowerShell y la CLI de Azure. Cualquier actualización futura de las reglas de enrutamiento de solicitudes debe tener el campo de prioridad de la regla proporcionado como parte de la configuración.
Nombres de host con comodín en el listener
Application Gateway permite el enrutamiento basado en el host mediante un agente de escucha HTTP(S) multisitio. Ahora, puede usar caracteres comodín como el asterisco (*) y el signo de interrogación (?) en el nombre del host y hasta 5 nombres de host por cliente de escucha HTTPS(S) de varios sitios. Por ejemplo, *.contoso.com.
Con un carácter comodín en el nombre del host, puede hacer coincidir varios nombres de host en un único cliente de escucha. Por ejemplo, *.contoso.com puede coincidir con ecom.contoso.com, b2b.contoso.com y customer1.b2b.contoso.com y así sucesivamente. Mediante una lista de nombres de host, puede configurar más de un nombre de host para una escucha a fin de dirigir las solicitudes a un grupo de servidores back-end. Por ejemplo, un cliente de escucha puede contener contoso.com, fabrikam.com, lo que aceptará las solicitudes para ambos nombres de host.
Nota:
Esta característica solo está disponible para las SKU Standard_v2 y WAF_v2 de Application Gateway.
En Azure PowerShell, debe usar -HostNames en lugar de -HostName. Con HostNames, puede especificar hasta 5 nombres de host separados por comas y usar caracteres comodín. Por ejemplo, -HostNames "*.contoso.com","*.fabrikam.com".
En la CLI de Azure, debe usar --host-names en lugar de --host-name. Con los nombres de host, puede mencionar un máximo de cinco nombres de host como valores separados por comas y usar caracteres comodín. Por ejemplo, --host-names "*.contoso.com,*.fabrikam.com".
En el portal de Azure, en la escucha multisitio, debe elegir el tipo de host Multiple/Wildcard para especificar hasta cinco nombres de host con caracteres comodín permitidos.
Caracteres permitidos en el campo de nombres de host
-
(A-Z,a-z,0-9)-caracteres alfanuméricos -
--guion o menos -
.- punto como delimitador -
*-puede coincidir con varios caracteres del intervalo permitido -
?-puede coincidir con un único carácter del intervalo permitido
Condiciones para usar caracteres comodín y varios nombres de host en un cliente de escucha
Las siguientes condiciones se aplican cuando se usan caracteres comodines o varios nombres de host en un oyente.
| Restricción | Limit | Example |
|---|---|---|
| Nombres de host en un solo oyente | Hasta 5 | No es aplicable |
Asterisco (*) en un componente de un nombre de estilo de dominio o nombre de host |
Solo puede mencionarse una vez |
component1*.component2*.component3.
(*.contoso-*.com) es válido. |
Asteriscos (*) en un nombre de host |
Hasta dos |
*.contoso.* es válido y *.contoso.*.*.com es inválido. |
| Caracteres comodín en un nombre de host | Máximo de 4 |
????.contoso.com y w??.contoso*.edu.* son válidas, pero ????.contoso.* son inválidas. |
Asterisco (*) y signo de interrogación (?) juntos en un componente de un nombre de host (*? o **?* ) |
No válido |
*?.contoso.com y **.contoso.com son inválidos. |
Comportamiento de coincidencia de *.contoso.com |
No coincide con contoso.com |
*.contoso.com especifica que hay un punto antes de contoso, así que contoso.com no coincide. |
Consideraciones y limitaciones del uso de caracteres comodín o varios nombres de host en un cliente de escucha
-
La terminación de SSL y SSL de extremo a extremo requiere configurar el protocolo como HTTPS y cargar un certificado que se utilizará en la configuración del agente de escucha. Si se trata de un agente de escucha multisitio, también puede especificar el nombre de host; normalmente, este es el CN del certificado SSL. Al especificar varios nombres de host en el cliente de escucha o se usan caracteres comodín, se debe tener en cuenta lo siguiente:
- Si es un nombre de host con comodín como *.contoso.com, debe cargar un certificado comodín cuyo CN sea *.contoso.com
- Si se mencionan varios nombres de host en el mismo listener, debe cargar un certificado SAN (nombres alternativos del sujeto) con los CN que coincidan con los nombres de host mencionados.
- No es posible usar una expresión regular para mencionar el nombre de host. Solo se pueden usar caracteres comodín como el asterisco (*) y el signo de interrogación (?) para formar el patrón de nombre de host.
- En la comprobación de estado del back-end, no se pueden asociar varios sondeos personalizados a una configuración HTTP. En su lugar, puede sondear uno de los sitios web del backend o usar "127.0.0.1" para sondear el host local del servidor del backend. Sin embargo, cuando se usan caracteres comodín o varios nombres de host en un cliente de escucha, las solicitudes de todos los patrones de dominio especificados se enrutarán al grupo de back-end en función del tipo de regla (básica o basada en la ruta de acceso).
- La propiedad «hostname» acepta una cadena, en la que solo se puede indicar un único nombre de dominio sin comodines. La propiedad «hostname» toma una matriz de cadenas como entrada, donde solo se pueden mencionar hasta cinco nombres de dominio comodín. No se pueden usar las dos propiedades a la vez.
Consulte crear varios sitios con Azure PowerShell o usar la CLI de Azure para obtener una guía paso a paso sobre cómo configurar nombres de host comodín en un oyente multisitio.
Agente de escucha multisitio para agentes de escucha de protocolo TLS y TCP
La función multisitio también está disponible para el proxy Layer4, pero solo para sus listeners TLS. Puede dirigir el tráfico de cada aplicación a su grupo de servidores back-end especificando nombres de dominio en el listener de TLS. Para el funcionamiento de la característica multisitio en los agentes de escucha TLS, Application Gateway usa el valor de indicación de nombre de servidor (SNI) (los clientes presentan principalmente la extensión SNI para capturar el certificado TLS correcto). Un agente de escucha TLS multisitio elegiría este valor de SNI de los datos de protocolo de enlace TLS de una conexión entrante y enrutaría esa conexión al grupo de back-end adecuado. La conexión TCP no tiene inherentemente ningún concepto de nombre de host o nombre de dominio; por lo tanto, esto no está disponible para los agentes de escucha TCP.
Encabezados de host e Indicación de nombre de servidor (SNI)
Existen tres mecanismos comunes para habilitar el hospedaje multisitio en la misma infraestructura.
- Hospede varias aplicaciones web, cada una en una dirección IP única.
- Use el nombre de host para hospedar varias aplicaciones web en la misma dirección IP.
- Use puertos distintos para hospedar varias aplicaciones web en la misma dirección IP.
En la actualidad, Application Gateway admite una dirección IP pública única en la que escucha el tráfico. Por lo tanto, actualmente no se permite tener varias aplicaciones, cada una con su propia dirección IP.
Application Gateway permite que haya varias aplicaciones y que cada una escuche en un puerto diferente. Sin embargo, este escenario requiere que las aplicaciones acepten el tráfico en puertos no estándar.
Application Gateway se basa en los encabezados de host HTTP 1.1 para hospedar más de un sitio web en la misma dirección IP pública y en el mismo puerto. Los sitios que se hospedan en la puerta de enlace de aplicaciones también pueden admitir la descarga TLS con la extensión TLS de Indicación de nombre de servidor (SNI). Este escenario significa que el explorador cliente y la granja de servidores web back-end deben admitir la extensión TLS y HTTP/1.1, como se define en RFC 6066.
Pasos siguientes
Aprenda a configurar el hospedaje multisitio en Application Gateway
Consulte la plantilla de Resource Manager con hospedaje de múltiples sitios para ver una implementación completa basada en una plantilla.