Consideraciones acerca de la implementación de una topología de aplicaciones para el usuario y servicios de fondo

 

Última modificación del tema: 2005-05-24

Cuando se implementa una topología de aplicaciones para el usuario y servicios de fondo, hay que tener en cuenta varios factores, entre otros, la carga prevista, las necesidades de hardware, la sobrecarga administrativa, el equilibrado de la carga y la seguridad. En las siguientes secciones se describen estos factores de forma más detallada.

No organice en clúster los servidores de aplicaciones para el usuario

Organizar en clúster los servidores de aplicaciones para el usuario de Exchange no ofrece ningún beneficio en cuanto a rendimiento. Los servidores de aplicaciones para el usuario no contienen información sobre el estado por lo que, en relación con el rendimiento, es mucho mejor tener dos servidores separados que comparten conexiones (o Equilibrio de carga de red) en lugar de organizarlos en un clúster.

Configuraciones y relaciones de servidores recomendados

La configuración del servidor depende de muchos factores, incluido el número de usuarios para cada servidor de servicios de fondo, los protocolos utilizados y la carga esperada en el sistema. La configuración de modelos particulares de servidores debe realizarse con la colaboración de un proveedor o consultor de hardware.

Generalmente, es razonable disponer de un servidor de aplicaciones para el usuario por cada cuatro servidores de servicios de fondo. Sin embargo, esta relación es sólo una sugerencia y un punto de partida, no una regla. Los servidores de aplicaciones para el usuario no necesitan un almacenamiento en disco grande o especialmente rápido, pero deben tener CPU rápidas y una gran cantidad de memoria. No es necesario realizar una copia de seguridad de los discos del servidor de aplicaciones para el usuario a menos que elija habilitar SMTP, ya que SMTP confirma el correo en cola en el disco local. Para POP, IMAP y HTTP, en la unidad no se almacena ningún dato de usuario.

Para obtener más información acerca de los requisitos de hardware para servidores de aplicaciones para el usuario y servicios de fondo, consulte los siguientes documentos técnicos:

Equilibrio de carga

En un entorno corporativo o de host, es posible que desee utilizar el equilibrio de carga en servidores de aplicaciones para el usuario. Windows proporciona el equilibrio de carga a través de Equilibrio de carga de red (NLB). También se pueden utilizar otros mecanismos de equilibrio de carga, incluidas soluciones de hardware para equilibrio de carga.

Windows NLB organiza en un clúster dos o más servidores que representan el clúster de NLB con una única dirección IP. Cada equipo recibe el tráfico en su propia dirección IP y en la dirección IP compartida. Todos los miembros del clúster de NLB ejecutan un algoritmo de operaciones hash para asignar los clientes de entrada a uno de los miembros del clúster de NLB en función de la dirección IP, el puerto y otro tipo de información. Cuando llega un paquete, todos los servidores o los hosts ejecutan el mismo algoritmo de operaciones hash, y el resultado es uno de estos host. Dicho host responde al paquete. La asignación no cambia a menos que varíe el número de hosts del clúster de NLB. La configuración de todos los servidores del clúster de NLB debe ser igual; en caso contrario, los clientes podrían experimentar comportamientos diferentes en función del servidor al que sean enrutados.

Nota

NLB no dispone de supervisión de estado; por ejemplo, si el Servicio de publicación World Wide Web de un servidor de aplicaciones para el usuario no está funcionando, NLB continúa enviando solicitudes a ese servidor. Se puede ejecutar Microsoft Application Center 2000 en un servidor de aplicaciones para el usuario para configurar NLB y supervisar el estado de los servidores de carga equilibrada. (Sin embargo, no se puede administrar los recursos de Exchange ni duplicar la información de configuración de Exchange mediante Application Center.) Para obtener más información acerca de Application Center, consulte el sitio Web de Microsoft Application Center.

Aunque no es necesario, debe asegurarse de que cada usuario sea enviado siempre al mismo servidor de aplicaciones para el usuario durante la duración de una sesión. Se utiliza la información del estado de la conexión y la caché de inicio del Nivel de sockets seguros (SSL) que ya se mantiene en el servidor de aplicaciones para el usuario. Además, esto es necesario para la autenticación basada en formularios, ya que sólo el servidor de aplicaciones para el usuario que emite la cookie puede descifrarla. En NLB, esto se denomina "afinidad de cliente". Muchas soluciones de hardware también tienen esta capacidad

Nota

Los servidores de seguridad avanzados pueden afectar a la capacidad para organizar en un clúster de NLB los servidores de aplicaciones para el usuario, especialmente si enmascaran la dirección IP del cliente entrante. Para obtener más información, consulte la documentación del producto o póngase en contacto con su fabricante.

Reducir la creación de servidores virtuales

En algunas circunstancias, podría ser importante reducir el número de servidores virtuales creados en los servidores de servicios de fondo. No reduzca el número de servidores virtuales a menos que comprenda perfectamente cómo funcionan los servidores virtuales HTTP. Existen dos métodos para reducir la creación de servidores virtuales.

Analizar los usuarios y los datos en cada servidor de servicios de fondo para determinar si alguna vez los usuarios se dirigirán a ese servidor particular. Si un servidor de servicios de fondo contiene buzones sólo para adatum.com, no es necesario que tenga un servidor virtual para contoso.com. Sin embargo, si más adelante se agregan los usuarios de contoso.com a ese servidor de servicios de fondo, es posible que el administrador tenga que crear un servidor virtual para contoso.com.

De forma similar, sólo es necesario crear directorios virtuales para los recursos a los que los usuarios vayan a tener acceso. En un servidor que no tiene almacén público, no es necesario el directorio virtual público.