Descripción del equilibrio de carga en Exchange 2010
Se aplica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3
Última modificación del tema: 2016-11-28
El equilibrio de carga es una forma de administrar cuál de sus servidores recibe tráfico. Proporciona redundancia de conmutación por error para garantizar a los usuarios que continúen recibiendo el servicio Exchange en caso de errores en el equipo. Además, permite que la implementación pueda manejar más tráfico del que puede procesar un servidor durante el ofrecimiento de un nombre único de host para sus clientes.
Además del equilibrio de carga, Microsoft Exchange Server 2010 proporciona varias soluciones de cambio y redundancia de conmutación por error. Estas soluciones incluyen lo siguiente:
Alta disponibilidad y resistencia de sitios Se pueden implementar dos sitios de Active Directory en distintas ubicaciones geográficas, mantener sincronizados los datos de buzón entre ambos, como así también permitir que uno de los sitios tome la totalidad de la carga si el otro falla. Exchange 2010 usa los grupos de disponibilidad de la base de datos (DAG) para mantener varias copias de sus buzones en distintos servidores sincronizados.
Movimientos del buzón de correo en línea En un movimiento del buzón de correo en línea, los usuarios finales tienen acceso a sus cuentas de correo electrónico durante el movimiento. Solo se bloquea el acceso de los usuarios a las cuentas durante un breve período al final del proceso, cuando se produce la sincronización final. Los movimientos de buzones de correo en línea son compatibles entre las bases de datos de Exchange 2010 y entre Exchange Server 2007 Service Pack 3 (SP3) o una versión posterior de bases de datos de Exchange 2007 y Exchange 2010. Puede realizar movimientos de buzones de correo en línea entre bosques o en el mismo bosque.
Redundancia de instantáneas La redundancia de instantáneas protege la disponibilidad y capacidad de recuperación de mensajes mientras están en tránsito. Con la redundancia de instantáneas, la eliminación de un mensaje de las bases de datos de transporte se retrasa hasta que el servidor Transporte comprueba que todos los saltos que debe ir superando el mensaje se han completado. Si alguno de esos saltos da error antes de que se informe de que la entrega ha sido correcta, el mensaje se reenvía para su entrega al salto que no se completó.
Contenido
Descripción de equilibrio de carga
Descripción de las cargas de tráfico de Exchange 2010
Descripción de opciones de equilibrio de carga
Recomendaciones de equilibrio de carga
Opciones de afinidad
Descripción de equilibrio de carga
El equilibrio de carga sirve para dos propósitos principales. Reduce el impacto de un único error del servidor de acceso de cliente en uno de sus sitios de Active Directory. Además, garantiza que la carga en el servidor de acceso de cliente y los equipos de transporte de concentradores se distribuya de forma pareja.
Cambios de arquitectura en el equilibrio de carga de Exchange 2010
Hay varios cambios en Exchange 2010 que acentúan la importancia del equilibrio de carga para su organización. El servicio de acceso de cliente de Exchange RPC y el servicio de libreta de direcciones de Exchange en el rol de servidor de acceso de clientes mejoran la experiencia del usuario durante los errores del buzón, mediante el movimiento de puntos finales de conexión para el acceso al buzón de Outlook y otros clientes MAPI al rol de servidor de acceso de clientes en lugar de hacerlo al rol de servidor del buzón. En versiones anteriores de Exchange, Outlook conectado directamente al servidor del buzón que hospeda el buzón del usuario, y las conexiones del directorio se colocaron en proxy mediante el rol servidor de buzones o se remitieron directamente a un servidor de catálogos global Active Directory en particular. Ya que estas conexiones se manejan mediante el rol de servidor de acceso de cliente, se debe equilibrar la carga de las conexiones externas e internas de Outlook a través de la matriz de los servidores de acceso de cliente en una implementación para lograr tolerancia a errores.
Se recomienda una matriz de equilibrio de carga de servidores de acceso de cliente para cada sitio de Active Directory y para cada versión de Exchange. No es posible compartir una matriz de equilibrio de carga de servidores de acceso de cliente para varios sitios de Active Directory o combinar versiones distintas de Exchange o versiones de Service Pack de Exchange en la misma matriz.
Al instalar Exchange 2010 en su organización existente y configurar un espacio de nombres heredado para la coexistencia con versiones anteriores de Exchange, los clientes automáticamente se conectarán al servidor de acceso de cliente de Exchange 2010 o a la matriz del servidor. El servidor de acceso de cliente de Exchange 2010 o la matriz del servidor de acceso del cliente colocará en proxy o redirigirá las solicitudes de cliente de buzones en versiones anteriores de Exchange a servidores front-end de Exchange 2003 o a servidores de acceso de cliente de Exchange 2007 que coincidan con la versión del buzón. Para obtener más información, consulte Descripción de la actualización a Exchange 2010.
Nota
Se pueden combinar Ingenierías de corrección rápida (QFE) y actualizar paquetes acumulativos al aplicarlos a todas las partes de una matriz. Recomendamos aplicar las QFE y actualizar los paquetes acumulativos a todos los equipos de una matriz.
Su configuración de equilibrio de carga tendrá un efecto directo sobre los nombres de host que sus clientes usen para conectarse y los certificados de capa de sockets seguros (SSL) que usa. Para obtener más información sobre los certificados de Exchange 2010, consulte Descripción de los certificados digitales y SSL.
Configuración de la matriz de servidor de acceso de cliente
Puede configurar una matriz de servidor de acceso de cliente por sitio de Active Directory. Inmediatamente después de configurar la matriz de servidor de acceso de cliente, puede configurar la base de datos de buzones para usar la matriz de servidor de acceso de cliente como punto final de MAPI en lugar de un servidor de acceso de cliente específico.
Para obtener más información sobre la matriz de servidor de acceso de cliente y cómo configurar la base de datos de buzones para usar una matriz de servidor de acceso de cliente para el sitio de Active Directory específico, consulte Descripción del acceso de clientes RPC.
Descripción de las cargas de tráfico de Exchange 2010
Antes de configurar el equilibrio de carga, debe entender las cargas colocadas en un servidor de acceso de cliente de Exchange 2010. Un servidor de acceso de cliente de Exchange 2010 recibe los siguientes tres tipos de tráfico:
Tráfico de clientes externos
Tráfico de clientes internos
Tráfico de proxy de otros servidores de acceso de cliente
El tráfico de proxy de otros servidores de acceso de cliente es el tráfico que originalmente es enviado por un cliente externo o interno a un servidor de acceso de cliente, pero que después se coloca en proxy en otro servidor de acceso de cliente. Esto puede ocurrir por varios motivos, pero generalmente ocurre porque el cliente de origen no se puede conectar directamente al servidor de acceso de cliente de destino. Además puede ocurrir cuando un usuario intenta obtener acceso a un buzón desde Internet, pero el buzón está ubicado en un sitio de Active Directory no expuesto a Internet. Para obtener más información acerca de las conexiones proxy, consulte Descripción del uso de proxy y redirección.
Cada uno de los tipos de tráfico que reciben los servidores de acceso de cliente incluye solicitudes de una lista de protocolos y proviene de dispositivos y equipos cliente con distintas características. Estas diferencias afectan las estrategias de equilibrio de carga que se pueden usar.
Volver al principio
Descripción de opciones de equilibrio de carga
Existen varias diferencias tecnológicas clave entre las distintas soluciones de equilibrio de carga.
Rendimiento ¿Cuántas solicitudes por segundo puede manejar la solución?
Capacidad de administración ¿Cuán sencillo es configurar e implementar la solución de equilibrio de carga?
Automatización y detección de conmutación por error ¿Cuán inteligente es el equilibrador de carga en cuanto a detección cuando un servidor o servicio de acceso de cliente arrojó errores?
Afinidad ¿Qué tipos de cliente de afinidad del servidor de acceso de cliente admite la solución de equilibrio de carga?
Descripción de afinidad
Cuando una solución de equilibrio de carga proporciona afinidad de servidor de cliente a cliente, esto significa que existe una asociación de larga permanencia entre un cliente en particular y un servidor de acceso de cliente en particular. El cliente puede ser Outlook ejecutado en un equipo portátil, Microsoft Exchange ActiveSync ejecutado en un dispositivo móvil, Microsoft Office Outlook Web App, servicios web de Exchange u otra aplicación cliente.
Esta asociación de larga permanencia, o afinidad, garantiza que todas las solicitudes enviadas desde el cliente vayan al mismo servidor de acceso de cliente. Algunos protocolos de Exchange 2010 requieren afinidad y otros protocolos de Exchange no.
Equilibrio de carga de red de Windows
El equilibrio de carga de red de Windows (WNLB) es el equilibrador de carga de software más frecuente usado para servidores de Exchange. Existen varias limitaciones asociadas con la implementación de WNLB con Microsoft Exchange.
WNLB no se puede usar en servidores de Exchange donde también se estén usando los DAG del buzón debido a la incompatibilidad de WNLB con la agrupación en clúster de conmutación por error de Windows. Si se usa un DAG de Exchange 2010 y desea usar WNLB, debe ejecutar el rol de servidor de acceso de cliente y el rol de servidor de buzón en servidores diferentes.
Debido a problemas de rendimiento, recomendamos no poner más de ocho servidores de acceso de cliente en una matriz con equilibrio de carga de WNLB.
WNLB no detecta las interrupciones de servicio. WNLB solamente detecta las interrupciones del servidor por su dirección IP. Esto significa que si un servicio web específico, como Outlook Web App, falla , pero el servidor sigue funcionando, WNLB no detectará el error y continuará enrutando las solicitudes a ese servidor de acceso de cliente. Se requiere intervención manual para quitar el servidor de acceso de cliente que está experimentando la interrupción desde el conjunto de equilibrios de carga.
La configuración de WNLB puede provocar saturación de puerto, que puede saturar las redes.
Dado que WNLB solamente realiza afinidad de cliente mediante el uso de la dirección IP, no es una solución eficaz cuando el conjunto de IP de origen es demasiado pequeño. Esto puede ocurrir cuando el conjunto de IP de origen proviene de la subred de una red remota o cuando su organización usa traducción de direcciones de red.
Recomendaciones de equilibrio de carga
Existen varias opciones disponibles de equilibrio de carga. La opción que usa depende del tamaño y la configuración de la red.
Equilibrio de carga de red de Windows con afinidad de IP de origen
La primera opción de equilibrio de carga es WNLB con afinidad de IP de origen. Esta solución es adecuada si tiene más de un servidor de acceso de cliente por sitio de Active Directory, pero menos de ocho. Esta solución se integra en Windows y no requiere equipos adicionales.
Hay dos escenarios en los que no querrá usar WNLB.
Su organización tiene un servidor proxy inverso que se comunica directamente con el servidor de acceso de cliente y no a través de la dirección IP virtual de WNLB. El servidor proxy inverso oculta las direcciones IP de cliente desde una matriz de servidor de acceso de cliente. Por lo tanto, la afinidad de IP de origen no funcionará como se espera. No obstante, es posible que siga queriendo usar WNLB para el tráfico interno del equilibrio de carga.
Su organización tiene varios clientes que tienen acceso a los servidores de acceso de cliente a través de un conjunto muy pequeño de direcciones IP. WNLB tiende a crear afinidad de toda una subred de clase C con un servidor de acceso de cliente.
Equilibrio de carga de hardware
Si tiene más de ocho servidores de acceso de cliente en un único sitio de Active Directory, su organización necesitará una solución de equilibrio de carga más sólida. Si bien existen soluciones sólidas de equilibrio de carga de software, una solución de equilibrio de carga de hardware proporciona la máxima capacidad. Para obtener más información acerca de las soluciones de equilibrador de carga del servidor de Exchange 2010, consulte Implementación de equilibrio de carga del hardware de Microsoft Unified Communications.
Los equilibradores de carga de hardware soportan un rendimiento de carga muy elevado y el equilibrio de carga se puede configurar de diversas maneras. La mayoría de los proveedores de equilibradores de carga de hardware tienen documentación detallada acerca de cómo funciona su producto con Exchange 2010. La manera más sencilla de configurar equilibradores de carga de hardware es crear una lista de reserva de los métodos de afinidad que va a aplicar el equilibrador de carga. Por ejemplo, el equilibrador de carga intentará primero la afinidad basada en cookies, después la id. de la sesión SSL y después la afinidad de IP de origen.
Soluciones de proxy inverso
Si cuenta con una solución de proxy inverso que pueda realizar un equilibrio de carga para los servidores que publica en Internet, como Microsoft Forefront Threat Management Gateway (TMG) o Forefront Unified Access Gateway (UAG), recomendamos que la use.
Al pasar el tráfico por el servidor proxy inverso para llegar a los servidores de acceso de cliente, la dirección IP original del cliente se reemplaza por la dirección IP del servidor proxy inverso. De esta manera se interrumpe la afinidad de IP de origen. Existen formas de resolver este problema, incluso configurar el servidor proxy inverso de modo que sea la puerta de enlace predeterminada para la subred con la que se crea la conexión proxy.
No obstante, la mayoría de los servidores proxy inversos pueden realizar un equilibrio de carga para los servicios que publican en Internet. Estos servidores proxy inversos admiten el equilibrio de carga mediante cookie creada por el equilibrador de carga para los servicios Exchange compatibles. Esta solución es más confiable que el equilibrio de carga de IP de origen. Para que funcione, el servidor proxy inverso debe poder leer y modificar el flujo de datos HTTP. Si se usa SSL, esto significa que el servidor proxy inverso debe descifrar el tráfico para leer el contenido y crear la cookie en el flujo. Este descifrado no es posible en algunas circunstancias, como cuando usa autenticación del certificado del cliente, en las que el cliente se conecta al servidor de acceso de cliente.
Volver al principio
Opciones de afinidad
Las distintas soluciones de equilibrio de carga ofrecen diversos métodos para asociar clientes a un servidor de acceso de cliente específico. Existen varios tipos frecuentes de afinidad disponibles en los distintos productos de equilibrio de carga, tanto de hardware como de software. No todos los tipos de afinidad están disponibles en todas las opciones de equilibrio de carga, tal como se describe en los siguientes ejemplos:
WNLB solamente admite la afinidad de IP de origen o no admite afinidad.
Un equilibrador de carga de software en una matriz de servidor independiente puede usar las cookies creadas por el equilibrador de carga para los protocolos compatibles con esas cookies y la afinidad de IP de origen para los protocolos restantes.
Los equilibradores de carga de hardware con descarga de SSL permiten configurar el comportamientos más complejos. Por ejemplo, puede configurar un conjunto de cookies existentes que se aplicarán en los protocolos que admiten estas cookies, como así también una cookie creada por equilibrador de carga, la id. de la sesión de SSL y la IP de origen.
Además de las opciones que admiten las distintas soluciones de equilibradores de carga, también puede configurar algunos de estos pasos para aplicarlos solo en determinados protocolos y servicios de Exchange. Dado que cada protocolo se comporta de forma diferente, esto puede ayudar a optimizar el rendimiento.
Cookies o encabezados HTTP existentes
El uso de cookies o encabezados HTTP existentes es la forma más confiable de identificar un cliente y asociarlo a un servidor de acceso de cliente específico. Estos cookies y encabezados son creados por el cliente o servidor como parte del protocolo de comunicaciones. Esta opción tampoco requiere que el equilibrador de carga modifique el tráfico, lo cual contribuye al rendimiento.
Cuando se usa esta opción de afinidad, se debe tener en cuenta lo siguiente:
El equilibrador de carga debe admitir este tipo de afinidad. Actualmente, solo los equilibradores de carga de hardware admiten esta afinidad.
Esta afinidad solo funciona para los protocolos que pasan el tráfico en HTTP.
Debe haber una cookie o encabezado existente que se mantenga constante durante la sesión del cliente y sea único para cada cliente específico, o para un pequeño conjunto de clientes, en el protocolo.
La solución de equilibrador de carga debe poder escribir e interpretar el flujo de datos HTTP. Si se usa SSL, esto significa que el equilibrador de carga debe descifrar el tráfico para leer los contenidos. A veces, esto da como resultado un aumento de la carga en el equilibrador de carga. Asimismo, este descifrado no es posible en algunas circunstancias, como cuando usa autenticación del certificado del cliente con la sesión SSL, en las que el cliente se conecta al servidor de acceso de cliente.
Las cookies y encabezados HTTP existentes adecuados para el equilibrador de carga que están disponibles en los protocolos de Exchange 2010 son los siguientes:
Encabezado de autorización de autenticación HTTP básica Este encabezado funciona cuando se usa la autenticación HTTP básica. Esta autenticación básica es el tipo de autenticación predeterminado y que se usa con mayor frecuencia para Exchange ActiveSync. Este encabezado es poco frecuente para otros protocolos y métodos de autenticación. La autorización de autenticación básica envía todo el tráfico que usa la autenticación básica y que pertenece a un usuario específico para el mismo servidor de acceso de cliente. El encabezado también se usa cuando el tráfico de Outlook se transmite completamente a través de HTTP y los clientes están tras el servidor proxy inverso.
Cookie HTTP UserContext de OWA Esta cookie funciona con Outlook Web App, que es el único cliente que la usa. Cuando se usa autenticación basada en formularios (FBA) con Outlook Web App, que es la configuración predeterminada, al comienzo de la sesión de Outlook Web App se realiza un pequeño conjunto de solicitudes, antes de crearse la cookie UserContext. Para garantizar que esas solicitudes usen la afinidad para conectar el cliente al mismo servidor de acceso de cliente, que se requiere para que funcione la autenticación basada en formularios, debe haber una opción de afinidad de reserva cuando se use la cookie UserContext. Le recomendamos usar el id. de la sesión de SSL o la afinidad de IP de origen como reserva para proporcionar afinidad a esas solicitudes iniciales antes de que el equilibrador de carga obtenga la cookie UserContext que va a usar.
Nota
Las solicitudes Outlook Web App que usan un inicio de sesión explícito para tener acceso a un resultado de buzón específico en el uso de una cookie UserContext con un nombre e id. distintos. La cookie comienza con UserContext, pero se antepone una cadena que identifica el buzón específico. Así se complica el equilibrio de carga con la cookie UserContext porque el equilibrador de carga primero debe buscar una cookie que comience con UserContext. El resultado es una disminución del rendimiento.
Cookie msExchEcpCanary del Panel de control de HTTP Exchange Esta cookie funciona únicamente con el Panel de control de Exchange.
Cookie HTTP OutlookSession de Outlook 2010 Los equilibradores de carga de hardware admiten la cookie OutlookSession y otras cookies genéricas. La siguiente tabla describe los requisitos de compatibilidad de cookies de cliente OutlookSession para Outlook RPC/HTTP:
Windows XP
Windows Vista
Windows 7
Outlook 2003
No se admite
No se admite
No se admite
Outlook 2007
No se admite
No se admite
No se admite
Outlook 2007 Paquete de hospedaje (KB2544404)
No se admite
Se admite
Se admite
Outlook 2010
No se admite
Se admite
Se admite
Nota
Cuando Microsoft Outlook se ejecuta en Windows XP, no es compatible con la cookie OutlookSession para el equilibrio de carga. En este escenario, se recomienda utilizar el equilibrio de carga IP.
Cookie HTTP MS-WSMAN de PowerShell remoto Este método solo funciona para PowerShell remoto.
Volver al principio
Cookie creada por el equilibrador de carga
La segunda forma más confiable de asociar una sesión de cliente a un servidor de acceso de cliente es mediante el uso de una cookie creada por el equilibrador de carga. El equilibrador de carga agrega una cookie HTTP a la conversación del protocolo cliente/servidor y después usa esa cookie para determinar qué servidor de acceso de cliente debe administrar una solicitud entrante. Las aplicaciones de Exchange 2010 que admiten este método son Outlook Web App, Panel de control de Exchange y PowerShell remoto. Este tipo de cookie tiene varias limitaciones.
El equilibrador de carga debe admitir este tipo de afinidad. Actualmente, solo los equilibradores de carga de hardware y los de software que se ejecutan en un nivel de servidor distinto admiten esta afinidad.
Este método solo funciona para los protocolos que pasan el tráfico de HTTP. Este método no puede usar para el servicio de acceso de cliente RPC, el servicio de libreta de direcciones de Exchange, POP3 o IMAP4.
La solución de equilibrador de carga debe poder escribir e interpretar el flujo de datos HTTP. Si se usa SSL, esto significa que el equilibrador de carga debe descifrar el tráfico para leer los contenidos. A veces, esto da como resultado una carga mayor en el equilibrador de carga. En otros casos, no es posible que el equilibrador de carga interprete el flujo de datos HTTP, como cuando se usa la autenticación del certificado del cliente en el servidor de acceso de cliente.
El cliente debe poder recibir cookies arbitrarias del servidor y debe incluir esas cookies en todas las solicitudes futuras enviadas por el cliente al servidor. Los clientes de Exchange ActiveSync, los clientes de Outlook y algunos clientes del servicio web de Exchange como los dispositivos Microsoft Office Communications Server 2007, no admiten estas acciones.
Id. de sesión SSL
El equilibrio de carga basado en la id. de sesión SSL proporciona más detalles que la afinidad de IP de origen y le permite dividir el tráfico de distintos clientes aun si esos clientes provienen de la misma dirección IP. El equilibrio de carda de id. de sesión SSL también tiene la ventaja de permitirle realizar el equilibrio de carga sin descifrar el tráfico SSL. Esto es necesario cuando se usa la autenticación del certificado del cliente y cuando finaliza la conexión de SSL en el servidor de acceso de cliente.
No se recomienda la afinidad de id. de sesión SSL en las dos situaciones siguientes:
Algunos clientes, como Internet Explorer 8, vuelven a crear su sesión de SSL para cada proceso del explorador que se ejecuta en el equipo cliente. El resultado es una nueva sesión de SSL para cada ventana de Outlook Web App. Dado que se interrumpe la afinidad del cliente con Outlook Web App, esta forma de implementación del equilibrio de carga no es compatible con Exchange 2010. Algunos dispositivos móviles, como Apple iPhone, también crean nuevas sesiones de SSL para algunas partes de su comunicación de Exchange ActiveSync con Exchange.
Nota
Cuando se usa la autenticación del certificado del cliente, los exploradores usan la misma sesión de SSL para todo el tráfico con un nombre de host determinado. Siempre que la autenticación del certificado del cliente esté habilitada, la id. de sesión SSL es una opción de afinidad válida para Outlook Web App y el Panel de control de Exchange.
En el caso de Outlook Anywhere, los servidores de acceso de cliente usarán el componente de proxy Windows RPC para emparejar las conexiones RPC_DATA_IN y RPC_DATA_OUT. Esto puede afectar negativamente el rendimiento.
IP de origen
La forma más frecuente de proporcionar afinidad entre clientes y servidores de acceso de cliente es el uso de la afinidad de IP de origen. El equilibrador de carga examina la dirección IP de un cliente y envía todo el tráfico desde un IP de origen específico a un servidor de acceso de cliente específico. Éste es el único tipo de afinidad que admite WNLB. Existen dos aspectos importantes que se deben considerar al usar la afinidad de IP de origen.
La afinidad se interrumpe cuando el cliente cambia la dirección IP. Eso puede ocurrir cuando un equipo portátil se mueve de una conexión LAN con cable a Wi-Fi, o se traslada entre distintas redes Wi-Fi. Cuando el cliente cambia la dirección IP se produce un impacto en el usuario. Por ejemplo, cuando se usa Outlook Web App, los usuarios deben autenticarse cada vez que el equipo obtiene una nueva dirección IP.
Si muchos de sus clientes tienen acceso a su solución de equilibrio de carga desde la misma dirección IP, la distribución de la carga no será pareja. El impacto de esto depende de cuántos clientes están ocultos tras una dirección IP determinada. Por ejemplo, si tiene cuatro servidores de acceso de cliente y el 50 por ciento de sus clientes tienen acceso al equilibrador de carga desde la misma dirección IP, al menos 50 por ciento del tráfico irá a un servidor de acceso de cliente y los otros tres servidores manejarán el resto del tráfico. Existen dos motivos principales por los cuales la mayoría de los clientes tienen acceso a su organización de Exchange a través de una única dirección IP.
Traductores de direcciones de red (NAT) o servidores proxy salientes, como Microsoft Forefront Threat Management Gateway (TMG). Cuando hay un NAT o servidor proxy saliente entre sus clientes y sus servidores de acceso de cliente, las direcciones IP de cliente originales están ocultos en el NAT o la dirección IP del servidor proxy saliente.
Servidor de acceso de cliente para el tráfico de proxy de servidor de acceso de cliente. En algunos escenarios, el servidor de acceso de cliente dirige mediante proxy el tráfico a otro servidor de acceso de cliente. En general, esto ocurre entre sitios de Active Directory porque un cliente debe tener acceso al servidor de acceso de cliente en el mismo sitio de Active Directory como su buzón. Para obtener más información acerca de las conexiones proxy, consulte Descripción del uso de proxy y redirección.
Sin afinidad
El último tipo de afinidad es sin afinidad. Cuando no se usa afinidad, cada consulta de un cliente se asigna a un servidor de acceso de cliente aleatorio. Esta opción no es recomendable para protocolos que requieren afinidad o los que experimentan beneficios de rendimiento a partir de la afinidad.
Se recomienda no usar afinidad para protocolos que no necesitan afinidad cuando está configurada la descarga de SSL.
Volver al principio
Resumen de opciones de equilibrio de carga
La tabla siguiente proporciona un resumen de las opciones de equilibrio de carga disponibles.
| Solución | Afinidad de servidores de acceso de cliente a cliente | Método de conmutación por error | Capacidad | Costo |
|---|---|---|---|---|
Equilibrador de carga de hardware |
Según el protocolo y el cliente, elija entre los siguientes elementos:
|
Conmutación por error automática con tiempo de inactividad mínimo de cliente. Los equilibradores de carga de hardware también pueden proporcionar conmutación por error para un protocolo específico. |
++++ |
$$$ |
Equilibrador de carga de software en una capa de servidor independiente Nota: TMG y UAG son las únicas soluciones que funcionan para el tráfico externo. |
Cualquier cookie o IP de origen creado por el equilibrador de carga, según el protocolo y el cliente. |
Conmutación por error automática con tiempo de inactividad mínimo de cliente. |
++ |
$$ |
Equilibrador de carga de software en la misma capa de servidor que el servidor de acceso de cliente (WNLB) |
IP de origen |
Conmutación por error automática con tiempo de inactividad mínimo de cliente. |
+ |
$ |
DNS Round robin |
Cada cliente obtiene una dirección IP de servidor de acceso de cliente aleatoria. |
Pasos manuales para detectar problemas y recuperar. El comportamiento del almacenamiento en caché de DNS del sistema operativo y el explorador puede impedir conexiones de clientes incluso después de que un administrador realice la recuperación. Esta solución interrumpe la afinidad con muchos protocolos como Acceso de clientes RPC, Outlook Web App, Servicios web de Exchange y el Panel de control de Exchange. |
+++ |
$ |
Sin equilibrador de carga |
Los nombres de host distintos se asignan manualmente a cada servidor de acceso de cliente. |
Pasos manuales para detectar problemas y conmutación por error. Las cachés del cliente DNS producen una lenta conmutación por error. |
+ |
N/D |
Cada una de estas opciones tiene varias ventajas y desventajas.
Los equilibradores de carga de hardware generalmente incluyen funcionalidad de seguridad y rendimiento, como descarga de SSL e inspección de tráfico.
Los equilibradores de carga de software en una capa de servidor distinta generalmente se incluyen como partes de paquetes de software más grandes, con capacidades de proxy inverso, como autenticación previa, descarga de SSL e inspección de tráfico extenso. Cuando los equilibradores de carga de software realizan la autenticación previa de usuarios, esos usuarios no tienen la necesidad de volver a autenticarse si se produce un error en el servidor de acceso de cliente con el que tienen afinidad. No obstante, algunos equilibradores de carga de software requieren afinidad entre el cliente y el servidor proxy inverso. En este caso, se necesita una capa de equilibrio de carga adicional frente a servidores reverse proxy inversos antes de que dichos servidores proxy inversos puedan realizar tareas de equilibrio de carga para los servidores de acceso de cliente.
© 2010 Microsoft Corporation. Reservados todos los derechos.