Consecución de alta disponibilidad y escalabilidad: ARR y equilibrador de carga de hardware
por Won Yoo
Consecución de alta disponibilidad y escalabilidad:
Enrutamiento de solicitud de aplicaciones de Microsoft (ARR) para IIS 7.0 y versiones posteriores y equilibrador de carga de hardware.
| Microsoft Corporation | F5 |
|---|---|
| Autor: Won Yoo | Autor: Ryan Korock |
| Fecha de publicación: 13 de noviembre de 2008 |
Abstract
En este documento se proporcionan instrucciones prescriptivas sobre cómo se puede usar el Enrutamiento de solicitud de aplicación (ARR) con un equilibrador de carga de hardware para lograr una alta disponibilidad y escalabilidad. El equilibrador de carga F5 BIG-IP se usa en este documento para ilustrar la relación de trabajo entre ARR y los equilibradores de carga de hardware.
Información general
El enrutamiento de solicitudes de aplicaciones (ARR) de Microsoft para IIS 7.0 y versiones superiores es un módulo de enrutamiento basado en proxy que reenvía solicitudes HTTP a servidores de contenido en función de los encabezados HTTP, las variables de servidor y los algoritmos de equilibrio de carga. En el diagrama siguiente se muestra una implementación típica de ARR:
Aunque ARR proporciona alta disponibilidad y escalabilidad para los servidores de contenido, la implementación general no es de alta disponibilidad ni escalable por lo siguiente:
- ARR es el único punto de error.
- La escalabilidad de los servidores de contenido la limita la capacidad máxima de un servidor ARR.
Para superar estos desafíos, los administradores pueden considerar la posibilidad de usar varios servidores ARR con equilibradores de carga de hardware, como F5 BIG-IP. ARR se puede implementar en modo activo/pasivo para lograr solo alta disponibilidad o en modo activo/activo para lograr alta disponibilidad y escalabilidad. En estas notas del producto se describe cómo se puede implementar ARR y F5 BIG-IP conjuntamente para habilitar los escenarios principales de ARR al tiempo que se logra una alta disponibilidad y escalabilidad generales.
Uso del Enrutamiento de solicitud de aplicación y F5 BIG-IP
ARR se crea como un módulo basado en IIS y está diseñado para tomar las decisiones de enrutamiento en el nivel 7 (aplicación). Para ser más precisos, ARR se basa en otro módulo de IIS, Reescritura de direcciones URL, a fin de inspeccionar los encabezados de solicitud HTTP de entrada y las variables de servidor para tomar las decisiones de enrutamiento. Dado este diseño, los administradores podrían escribir reglas de enrutamiento inteligentes basadas en la información de nivel de aplicación, como las siguientes:
- Nombre de host (HTTP_HOST): enruta el tráfico a distintos servidores de contenido en función del nombre de host.
- Recurso solicitado (URL): en función de las extensiones de archivo, determina si los recursos solicitados son para contenido estático o contenido dinámico y si enrutan las solicitudes en consecuencia.
- Información de cliente (HTTP_USER_AGENT): en función del tipo y la versión del explorador, enruta las solicitudes a los servidores de contenido adecuados.
- Encabezados personalizados (establecer como una cookie por aplicaciones): enruta el tráfico en función de la información de cookies que establecen las aplicaciones, como las preferencias del usuario o Id. de usuario.
Los anteriores son solo algunos de los ejemplos. Para obtener una lista completa de encabezados HTTP y variables de servidor, consulte Apéndice A.
La función de nivel 3 y 4 de F5 Big-IP complementa la fuerza de ARR para tomar decisiones de enrutamiento basadas en la nivel 7, como encabezados HTTP y variables de servidor. Al mismo tiempo, ARR no proporciona características de implementación tolerantes a errores por sí mismo y debe confiar en otras tecnologías y soluciones complementarias a fin de lograr una alta disponibilidad para el nivel de ARR, como se muestra a continuación:
Escenario 1: Enrutamiento basado en HTTP y equilibrio de carga
El escenario de enrutamiento y equilibrio de carga basado en HTTP permite una arquitectura de implementación de 3 niveles que implica lo siguiente:
- Nivel 1 (web): proporciona dos propósitos de procesamiento de contenido estático, enrutamiento y equilibrio de carga de las solicitudes dinámicas restantes a los servidores de nivel 2.
- Nivel 2 (aplicación): procesa el contenido dinámico que se basa en la lógica de negocios.
- Nivel 3 (datos): almacena datos.
En el diagrama siguiente se muestra la implementación de 3 niveles:
Aunque en el ejemplo anterior se muestra una regla de enrutamiento que diferencia el contenido estático del contenido dinámico, otro escenario común es diferenciar las solicitudes de presentación de las de servicio web.
Opción 1: Activo/pasivo
En el modo activo/pasivo, normalmente hay dos servidores ARR, en los que uno de ellos procesa las solicitudes mientras que el otro es un servidor de conmutación por error. Como se indicó anteriormente, aunque esta configuración logra una alta disponibilidad quitando el único punto de error, no es una solución de escalabilidad horizontal, ya que la capacidad agregada de los servidores de contenido la limita la capacidad máxima de un servidor ARR.
En esta configuración, dado que se configuran dos servidores ARR de la misma manera, se usa una configuración compartida. F5 BIG-IP está configurado de modo que enruta todas las solicitudes al servidor ARR activo y solo enruta las solicitudes al servidor ARR pasivo cuando sea necesario.
A excepción de la característica de afinidad de nombre de host en ARR, no hay información de estado en runtime que se deba compartir entre los dos servidores ARR. Por lo tanto, para este escenario, no se necesita ninguna configuración especial en los servidores ARR ni en F5 BIG-IP. Incluso si usa la característica de afinidad de servidor en ARR, la información de estado de afinidad estará disponible para el servidor pasivo mediante una cookie en el encabezado de solicitud cuando F5 BIG-IP enruta las solicitudes al servidor que anteriormente era pasivo pero ahora es activo.
Este escenario es totalmente compatible con la versión 1 de ARR.
Configuración de ARR
Paso 1: Habilitar la configuración compartida en dos servidores ARR.
- Siga los pasos de este documento para establecer la configuración compartida en IIS.
Paso 2: Configurar la arquitectura de implementación de 3 niveles mediante ARR.
Siga los pasos de este documento para configurar ARR en la arquitectura de implementación de 3 niveles.
En general, el documento anterior describe lo siguiente:
- Cómo hacer que el contenido estático esté disponible en el servidor ARR.
- Cómo escribir reglas de reescritura de direcciones URL para contenido estático a fin de que se sirvan directamente desde el servidor ARR.
- Cómo escribir reglas de reescritura de direcciones URL para contenido dinámico a fin de que se reenvíen a los servidores de aplicaciones.
Configuración de F5 BIG-IP
En este escenario, creará un servidor virtual que equilibre la carga en un grupo de dos servidores ARR (o más). El método de equilibrio de carga que seleccione debe enviar todo el tráfico al servidor ARR principal hasta que deje de estar disponible. En ese momento, BIG-IP LTM debe enviar todo el tráfico al servidor ARR secundario.
Paso 1: Configurar el grupo de servidores ARR.
- En la sección Tráfico local, haga clic en Grupos. Después, haga clic en el botón Crear para crear un grupo.
- Cualquier nombre único funcionará para el grupo; en el ejemplo se usa ARR_Pool.
- Para Health Monitor, puede usar un monitor HTTP personalizado o el monitor HTTP predeterminado.
- Puede dejar el método de equilibrio de carga establecido en Round Robin. En este escenario, dado que solo hay un servidor ARR activo y pasivo, no se usa el equilibrio de carga.
- Asegúrese de habilitar la activación de grupo de prioridad. Esto configura BIG-IP para enviar tráfico a los servidores con el valor de prioridad más alto. Cuando esos servidores no están disponibles, BIG-IP envía tráfico al servidor ARR con el siguiente valor de prioridad más alta.
- En este escenario, el servidor ARR de 10.0.0.1 tiene un valor de prioridad de 1 y 10.0.0.2 tiene un valor de prioridad de 2. Todo el tráfico se enviará a 10.0.0.2 hasta que deje de funcionar y, luego, se enviará a 10.0.0.1.
Paso 2: Configurar el grupo de servidores ARR.
- En la sección Tráfico local, haga clic en Servidores virtuales. Después, haga clic en el botón Crear para crear un servidor virtual.
- Cualquier nombre único funcionará para el servidor virtual; en el ejemplo se usa ARR_VS.
- Para Destino, puede usar la dirección IP a la que los usuarios apuntarán sus exploradores. En este ejemplo específico, usamos 65.197.145.23. Para el puerto de servicio, usamos "80".
- Para la sección Tipo de servidor virtual, tiene varias opciones. Puesto que depende de ARR para enrutar, puede seleccionar HTTP de rendimiento, que está diseñado a fin de obtener el mejor rendimiento.
- Para Grupo predeterminado, seleccione el grupo que creó en el Paso 1.
- En este momento, debería poder conectarse a este servidor virtual, que se enviará al servidor ARR adecuado.
Opción 2: Activo/activo
En el modo activo/activo, puede tener dos o más servidores ARR. Esta configuración logra la alta disponibilidad y la escalabilidad, a diferencia del modo activo/pasivo, lo que solo logra una alta disponibilidad. Como se indicó anteriormente, como varios servidores ARR se configuran de la misma manera, se usa una configuración compartida. F5 BIG-IP está configurado para equilibrar la carga de las solicitudes de entrada a todos los servidores ARR disponibles y correctos, que a su vez reenvía las solicitudes a los servidores de contenido. Independientemente de si la característica de afinidad de servidor se usa en F5 BIG-IP, no se necesita ninguna configuración especial en los servidores ARR. Por un lado, los servidores ARR usan una configuración compartida para que se configuren de la misma manera. En segundo lugar, dado que ARR usa una cookie de cliente a fin de almacenar la información de afinidad del servidor para su propio uso, esta información está disponible por solicitud y, por tanto, disponible en los servidores ARR. Este escenario es totalmente compatible con la versión 1 de ARR.
Configuración de ARR
La configuración de ARR para activo/activo es idéntica a la de activo/pasivo. La principal diferencia es cómo se configura F5.
Paso 1: Habilitar la configuración compartida en dos servidores ARR.
- Siga los pasos de este documento para establecer la configuración compartida en IIS.
Paso 2: Configurar la arquitectura de implementación de 3 niveles mediante ARR.
Siga los pasos de este documento para configurar ARR en la arquitectura de implementación de 3 niveles.
En general, el documento anterior describe lo siguiente:
- Cómo hacer que el contenido estático esté disponible en el servidor ARR.
- Cómo escribir reglas de reescritura de direcciones URL para contenido estático a fin de que se sirvan directamente desde el servidor ARR.
- Cómo escribir reglas de reescritura de direcciones URL para contenido dinámico a fin de que se reenvíen a los servidores de aplicaciones.
Configuración de F5 BIG-IP
En este escenario, todos los servidores ARR disponibles se consideran activos y candidatos para el tráfico con equilibrio de carga. Use BIG-IP LTM para determinar el estado y el rendimiento de los front-end de ARR y dirigir el tráfico a los que mejor funcionan.
Paso 1: Configurar el grupo de servidores ARR.
- En la sección Tráfico local, haga clic en Grupos. Después, haga clic en el botón Crear para crear un grupo.
- Cualquier nombre único funcionará para el grupo; en los ejemplos se usa ARR_Pool. - Para Health Monitor, puede usar un monitor HTTP personalizado o el monitor HTTP predeterminado. - Dado que tiene varios servidores ARR a los que distribuir el tráfico, querrá seleccionar el método de equilibrio de carga que mejor se adapte a sus necesidades. Suponiendo que todos los servidores de ARR tienen características de hardware similares, un método de equilibrio de carga dinámico, como el más rápido, observado o predictivo, le proporcionará una distribución basada en el rendimiento.
Paso 2: Configurar el servidor virtual.
- En la sección Tráfico local, haga clic en Servidores virtuales. Después, haga clic en el botón Crear para crear un servidor virtual.
- Cualquier nombre único funcionará para el servidor virtual; en el ejemplo se usa ARR_VS. - Para Destino, puede usar la dirección IP a la que los usuarios apuntarán sus exploradores. En este ejemplo específico, usamos 65.197.145.23. Para el Puerto de servicio, usamos "80". - Para la sección Tipo de servidor virtual, tiene varias opciones. Puesto que depende de ARR para enrutar, puede seleccionar HTTP de rendimiento, que está diseñado a fin de obtener el mejor rendimiento. - Para Grupo predeterminado, seleccione el grupo que creó en el Paso 1.
Escenario 2: Hospedaje compartido con afinidad de nombre de host
En este escenario se usa la característica de afinidad de nombre de host en ARR a fin de habilitar una implementación de hospedaje compartida para lo siguiente:
- Reducir la administración manual y el mantenimiento implicados en la implementación tradicional de hospedaje compartido.
- Maximizar los recursos de servidor existentes al tiempo que garantiza que todos los recursos de servidor se usen uniformemente.
- Escalar horizontalmente el entorno con facilidad.
- Crear oportunidades de negocio para vender capacidad adicional.
Para obtener más información sobre el hospedaje compartido y ARR, vea este documento.
En el diagrama siguiente se muestra el entorno de hospedaje compartido mediante ARR: 
.
Opción 1: Activo/pasivo
Tal como se indicó anteriormente, en el modo activo/pasivo normalmente hay dos servidores ARR, en los que uno de ellos procesa las solicitudes mientras que el otro es un servidor de conmutación por error. Aunque esta configuración logra una alta disponibilidad quitando el único punto de error, no es una solución de escalabilidad horizontal, ya que la capacidad agregada de los servidores de contenido la limita la capacidad máxima de un servidor ARR.
En esta configuración, dado que se configuran dos servidores ARR de la misma manera, se usa una configuración compartida. F5 BIG-IP está configurado para enrutar todas las solicitudes al servidor ARR activo y solo enrutar las solicitudes al servidor ARR pasivo cuando sea necesario.
La característica de afinidad de nombre de host de ARR muestra afinidad de las solicitudes a un servidor determinado (o a un grupo de servidores en RC) en función del nombre de host. La información de estado en runtime de la asignación de afinidad entre los nombres de host y los servidores de contenido se almacena en la memoria dentro de una instancia de un servidor ARR. En la versión 1 de ARR se saca provecho de la caché externa de Microsoft para IIS a fin de compartir y mantener este estado en runtime entre varios servidores ARR. En este documento encontrará más información sobre este escenario.
Este escenario es totalmente compatible con la versión 1 de ARR.
Configuración de ARR
Paso 1: Habilitar la configuración compartida en dos servidores ARR.
- Siga los pasos de este documento para establecer la configuración compartida en IIS.
Paso 2: Configurar la arquitectura de implementación de 3 niveles mediante ARR.
Siga los pasos de este documento para configurar ARR en la arquitectura de implementación de 3 niveles.
En general, el documento anterior describe lo siguiente:
- Cómo hacer que el contenido estático esté disponible en el servidor ARR.
- Cómo escribir reglas de reescritura de direcciones URL para contenido estático a fin de que se sirvan directamente desde el servidor ARR.
- Cómo escribir reglas de reescritura de direcciones URL para contenido dinámico a fin de que se reenvíen a los servidores de aplicaciones.
Paso 3: Habilitar y configurar la caché externa.
- Siga los pasos de este documento para habilitar y configurar la caché externa que se usará con ARR.
Configuración de F5 BIG-IP
En este escenario, creará un servidor virtual que equilibre la carga en un grupo de dos servidores ARR (o más). El método de equilibrio de carga que seleccione debe enviar todo el tráfico al servidor ARR principal hasta que deje de estar disponible. En ese momento, BIG-IP LTM debe enviar todo el tráfico al servidor ARR secundario.
Paso 1: Configurar el grupo de servidores ARR.
- En la sección Tráfico local, haga clic en Grupos. Después, haga clic en el botón Crear para crear un grupo.
- Cualquier nombre único funcionará para el grupo; en el ejemplo se usa ARR_Pool. - Para Health Monitor, puede usar un monitor HTTP personalizado o el monitor HTTP predeterminado. - Puede dejar el método de equilibrio de carga establecido en Round Robin. En este escenario, dado que solo hay un servidor ARR activo y pasivo, no se usa el equilibrio de carga. - Asegúrese de habilitar la activación de grupo de prioridad. Esto configura BIG-IP para enviar tráfico a los servidores con el valor de prioridad más alto. Cuando esos servidores no están disponibles, BIG-IP envía tráfico al servidor ARR con el siguiente valor de prioridad más alta. - En este escenario, el servidor ARR de 10.0.0.1 tiene un valor de prioridad de 1 y 10.0.0.2 tiene un valor de prioridad de 2. Todo el tráfico se enviará a 10.0.0.2 hasta que deje de funcionar y, luego, se enviará a 10.0.0.1.
Paso 2: Configurar el servidor virtual.
- En la sección Tráfico local, haga clic en Servidores virtuales. Después, haga clic en el botón Crear para crear un servidor virtual.
- Cualquier nombre único funcionará para el servidor virtual; en el ejemplo se usa ARR_VS. - Para Destino, puede usar la dirección IP a la que los usuarios apuntarán sus exploradores. En este caso, usamos . Para el Puerto de servicio, usamos "80". - Para la sección Tipo de servidor virtual, tiene varias opciones. Puesto que depende de ARR para enrutar, puede seleccionar HTTP de rendimiento, que está diseñado a fin de obtener el mejor rendimiento. - Para Grupo predeterminado, seleccione el grupo que creó en el Paso 1.
- En este momento, debería poder conectarse a este servidor virtual, que se enviará al servidor ARR adecuado.
Opción 2: Activo/activo en ARR
En el modo activo/activo, puede tener dos o más servidores ARR. Esta configuración logra la alta disponibilidad y la escalabilidad, a diferencia del modo activo/pasivo, lo que solo logra una alta disponibilidad. Como se configuran varios servidores ARR de la misma manera, se usa una configuración compartida. F5 BIG-IP está configurado para equilibrar la carga de las solicitudes de entrada a todos los servidores ARR disponibles y correctos, que a su vez reenvía las solicitudes a los servidores de contenido.
Tal como se ha indicado anteriormente, la información de estado en runtime de la asignación de afinidad entre los nombres de host y los servidores de contenido se almacena en la memoria dentro de una instancia de un servidor ARR. Para compartir esta información entre varios servidores ARR, se usa la caché externa de Microsoft para IIS. Para obtener más información sobre la caché externa, consulte este documento.
Configuración de ARR
La configuración de ARR para activo/activo es idéntica a la de activo/pasivo. La principal diferencia es cómo se configura F5.
Paso 1: Habilitar la configuración compartida en dos servidores ARR.
- Siga los pasos de este documento para establecer la configuración compartida en IIS.
Paso 2: Configurar la arquitectura de implementación de 3 niveles mediante ARR.
Siga los pasos de este documento para configurar ARR en la arquitectura de implementación de 3 niveles.
En general, el documento anterior describe lo siguiente:
- Cómo hacer que el contenido estático esté disponible en el servidor ARR.
- Cómo escribir reglas de reescritura de direcciones URL para contenido estático a fin de que se sirvan directamente desde el servidor ARR.
- Cómo escribir reglas de reescritura de direcciones URL para contenido dinámico a fin de que se reenvíen a los servidores de aplicaciones.
Paso 3: Habilitar y configurar la caché externa.
- Siga los pasos de este documento para habilitar y configurar la caché externa que se usará con ARR.
Configuración de F5 BIG-IP
En este escenario, todos los servidores ARR disponibles se consideran activos y candidatos para el tráfico con equilibrio de carga. Use BIG-IP LTM para determinar el estado y el rendimiento de los front-end de ARR y dirigir el tráfico a los que mejor funcionan.
Paso 1: Configurar el grupo de servidores ARR.
- En la sección Tráfico local, haga clic en Grupos. Después, haga clic en el botón Crear para crear un grupo.
- Cualquier nombre único funcionará para el grupo; en el ejemplo se usa ARR_Pool. - Para Health Monitor, puede usar un monitor HTTP personalizado o el monitor HTTP predeterminado. - Dado que tiene varios servidores ARR a los que distribuir el tráfico, querrá seleccionar el método de equilibrio de carga que mejor se adapte a sus necesidades. Suponiendo que todos los servidores de ARR tienen características de hardware similares, un método de equilibrio de carga dinámico, como el más rápido, observado o predictivo, le proporcionará una distribución basada en el rendimiento.
Paso 2: Configurar el servidor virtual.
- En la sección Tráfico local, haga clic en Servidores virtuales. Después, haga clic en el botón Crear para crear un servidor virtual.
- Cualquier nombre único funcionará para el servidor virtual; en el ejemplo se usa ARR_VS. - Para Destino, puede usar la dirección IP a la que los usuarios apuntarán sus exploradores. En este caso, usamos . Para el Puerto de servicio, usamos "80". - Para la sección Tipo de servidor virtual, tiene varias opciones. Puesto que depende de ARR para enrutar, puede seleccionar HTTP de rendimiento, que está diseñado a fin de obtener el mejor rendimiento. - Para Grupo predeterminado, seleccione el grupo que creó en el Paso 1.
Resumen
En estas notas del producto, se revisaron dos escenarios principales de ARR para lograr alta disponibilidad y escalabilidad implementando varios servidores ARR y el uso de F5 BIG-IP.
Apéndice
Apéndice A: Todos los encabezados HTTP y variables de servidor disponibles para escribir reglas de decisión de enrutamiento.
| ALL_HTTP | ALL_RAW | APPL_MD_PATH |
|---|---|---|
| APPL_PHYSICAL_PATH | CERT_COOKIE | CERT_FLAGS |
| CERT_ISSUER | CERT_KEYSIZE | CERT_SECRETKEYSIZE |
| CERT_SERIALNUMBER | CERT_SERVER_ISSUER | CERT_SERVER_SUBJECT |
| CERT_SUBJECT | CONTENT_LENGTH | CONTENT_TYPE |
| DOCUMENT_ROOT | GATEWAY_INTERFACE | HTTP_ACCEPT |
| HTTP_ACCEPT_ENCODING | HTTP_ACCEPT_LANGUAGE | HTTP_CONNECTION |
| HTTP_CONTENT_LENGTH | HTTP_HOST | HTTP_IF_MODIFIED_SINCE |
| HTTP_IF_NONE_MATCH | HTTP_REFERER | HTTP_UA_CPU |
| HTTP_USER_AGENT | HTTPS | HTTPS_KEYSIZE |
| HTTPS_SECRETKEYSIZE | HTTPS_SERVER_ISSUER | HTTPS_SERVER_SUBJECT |
| INSTANCE_ID | INSTANCE_META_PATH | LOCAL_ADDR |
| PATH_INFO | PATH_TRANSLATED | QUERY_STRING |
| REMOTE_ADDR | REMOTE_HOST | REMOTE_PORT |
| REMOTE_USER | REQUEST_FILENAME | REQUEST_METHOD |
| REQUEST_URI | SCRIPT_FILENAME | SCRIPT_NAME |
| SERVER_ADDR | SERVER_NAME | SERVER_PORT |
| SERVER_PORT_SECURE | SERVER_PROTOCOL | SERVER_SOFTWARE |
| URL |
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de