Prácticas recomendadas para el rendimiento de ISA Server 2006

Microsoft® Internet Security and Acceleration (ISA) Server 2006 proporciona acceso seguro y controlado entre redes y sirve de proxy de almacenamiento en caché de web ofreciendo capacidades de rápida respuesta web y de descarga, así como publicación en Web segura para acceso remoto. Su arquitectura multicapa y motor de directivas avanzadas ofrecen control granular del equilibrio entre el nivel de seguridad que usted necesita y los recursos requeridos. Como servidor perimetral que conecta muchas redes, ISA Server administra grandes cantidades de tráfico en comparación con otros servidores de una organización. Por este motivo, está diseñado para ofrecer un alto rendimiento. Este artículo proporciona instrucciones para la implementación de ISA Server con el mejor rendimiento posible y una capacidad adecuada.

Resumen ejecutivo

En la mayoría de los casos, el ancho de banda de red disponible, especialmente el del vínculo de Internet, puede protegerse con ISA Server en ejecución en el hardware más básico disponible. Una implementación predeterminada típica de ISA Server que protege el acceso web de salida para tráfico de Protocolo de transferencia de hipertexto (HTTP) requiere configuraciones de hardware específicas para diferentes vínculos de Internet. Estas configuraciones del hardware se muestran en la tabla siguiente. (Para más detalles, consulte los Escenarios proxy web en este documento).

El empleo de filtrado activo de capa de transporte en lugar del filtro de proxy web mejora 10 veces la utilización de CPU para las mismas pautas de tráfico. Tanto el filtrado activo como el filtrado de aplicación pueden ser utilizados en paralelo para proporcionar control granular sobre el rendimiento.

Principio de la página

Planificación de la capacidad de ISA Server

La obtención de más información sobre sus requisitos de capacidad es el primer paso para determinar los recursos necesarios para una implementación de ISA Server. Hay diferentes casos para un amplio espectro de implementaciones. En general, es probable que tenga la métrica siguiente:

La métrica más importante para la capacidad de ISA Server son los anchos de banda real de la red, porque generalmente representan sus necesidades reales de capacidad. En muchos casos, el ancho de banda de la red, y en concreto el del vínculo de Internet, puede determinar la capacidad de ISA Server.

El número de usuarios es menos indicativo de sus necesidades de capacidad porque cada usuario tiene su propio modo de uso, en función de sus necesidades y de las directivas de red de su organización. A veces, el número de usuarios, así como la métrica en el nivel de aplicación, pueden resultar útiles para calcular el tráfico de red.

Todos los casos de planificación de la capacidad de ISA Server se encuentran en una de las categorías siguientes:

Las secciones siguientes describen estos casos con mayor detalle.

Principio de la página

Instrucciones de ajuste de rendimiento

Cuando haya decidido qué opción de capacidad se ajusta a sus necesidades, su siguiente tarea será ajustarla para un mejor rendimiento. Para ISA Server a escala de empresa, esto se traduce en el diseño de recursos de hardware adecuados para hacer que el sistema dependa de su potencia de CPU como origen de un posible cuello de botella. Para un equipo individual básico ISA Server, el ancho de banda de Internet es el origen de un posible cuello de botella, y no el procesador que usted elija.

Ajuste del hardware para un máximo uso de la CPU

La capacidad del ISA Server depende de los recursos de hardware de CPU, memoria, red y disco. Cada recurso tiene un límite de capacidad y mientras se consuman todos los recursos por debajo de su límite, el sistema en su conjunto funcionará correctamente, cumpliendo sus objetivos de rendimiento. El rendimiento disminuye considerablemente cuando se alcanza uno de estos límites, produciéndose un cuello de botella. En este caso, se dice que el sistema está enlazado a ese recurso. Cada cuello de botella produce determinados síntomas en el rendimiento general del sistema que pueden servir de ayuda para detectar el recurso con capacidad inadecuada. Cuando se descubra un cuello de botella, bastará agregar más capacidad al recurso de capacidad inadecuada para eliminarlo.

Desde la perspectiva de costos, lo más eficiente es diseñar un sistema que esté basado en recursos de CPU. Esto se debe a que es el recurso más caro de actualizar. Otras carencias de recursos son menos costosas de corregir: Agregue otro disco, agregue otro adaptador de red, o bien amplíe la memoria. Le recomendamos que ajuste el hardware del sistema para maximizar el uso de la CPU. Compruebe que un sistema no tenga cuellos de botella de rendimiento antes de alcanzar el uso completo de la CPU. Si la capacidad de procesamiento de la CPU puede soportar la carga esperada, nunca se producirá un cuello de botella. Para ello, todos los demás recursos deben tener la capacidad adecuada. Las secciones siguientes describen cómo diseñar un sistema maximizado para la CPU con la capacidad adecuada en cada recurso, cómo supervisar cada recurso y cómo solucionar un cuello de botella en cada recurso.

Determinar la capacidad de la CPU y de la arquitectura del sistema

Como la mayoría de las aplicaciones de servidor que sirven numerosas solicitudes de cliente, el rendimiento del ISA Server también se beneficia de una mayor velocidad de la CPU, de una mayor caché de procesador y de una arquitectura mejorada del sistema:

•	Velocidad de la CPU. Como en la mayoría de aplicaciones, ISA Server se beneficia de CPU más rápidas. Sin embargo, aumentar la velocidad de la CPU no garantiza un aumento lineal del rendimiento. Debido al frecuente y gran efecto de acceso a la memoria, aumentar la velocidad de la CPU puede producir más ciclos de CPU inactivos desaprovechados a la espera de la memoria.
•	Tamaño de caché L2/L3. El manejo de grandes cantidades de datos requiere de frecuentes accesos a la memoria. Una caché L2/L3 mejora el rendimiento en recuperaciones de memoria grandes.
•	Arquitectura del sistema. Debido a que ISA Server transfiere grandes cargas de datos entre dispositivos de red, memoria y la CPU, los elementos de sistema alrededor de la CPU afectan también al rendimiento de ISA Server. Un bus de memoria frontal más rápido y buses de E/S más rápidos mejoran la capacidad general.

Los cuellos de botella de la CPU se caracterizan por situaciones en las que\Processor\% Processor Time las cifras del contador de rendimiento son elevadas mientras que el adaptador de red y las E/S del disco permanecen por debajo de su capacidad. En este caso, (que es el sistema maximizado para la CPU idóneo), llegar al 100  por cien significa que se debe aumentar la CPU, bien actualizando a una CPU más rápida, o bien agregando más procesadores. Para obtener más información acerca de opciones de escalado de CPU, consulte Escalado de ISA Server en este documento. Si ISA Server continúa teniendo tiempos de respuesta altos, pero los porcentajes de CPU son bajos, significa que el cuello de botella está en otra parte.

Las capacidades de Hyper-threading también pueden ayudar a reducir los niveles de uso de CPU cuando consuma menos del 60 por ciento de la CPU. En niveles más altos de uso de CPU, si se habilita Hyper-threading se consumirá la misma capacidad de procesamiento que si está deshabilitado.

Determinar la capacidad de memoria

La memoria de ISA Server se utiliza para:

•	Almacenar sockets de red (principalmente desde agrupaciones no paginadas)
•	Estructuras de datos internos
•	Objetos de solicitudes pendientes

En escenarios de almacenamiento en caché proxy web, la memoria se utiliza también para:

•	La estructura de directorios de la memoria caché de disco
•	Almacenamiento en memoria caché

Debido a que ISA Server administra numerosas conexiones simultáneas que necesitan memoria de sistema no paginada, el factor limitador de la memoria es el tamaño de la agrupación no paginada, en función del tamaño total de memoria. Para sistemas operativos Microsoft Windows Server® 2003 y Windows® 2000 Server, los valores mínimo y máximo del tamaño de agrupación no paginada se muestran en la tabla siguiente.

Memoria física (MB)	128	256	512	1,024	2,048	4,096
Tamaño mínimo de agrupación no paginada	4	8	16	32	64	128
Tamaño máximo de agrupación no paginada	50	100	200	256	256	256

Cuándo no está habilitado el almacenamiento en caché de web, 512 MB deberían ser suficientes para equipos de procesador único, 1.024 MB son suficientes para equipos con doble procesador y 2.048 MB son suficientes para equipos con doble procesador y doble núcleo. Estas cantidades pueden almacenar también la capacidad total de memoria del conjunto de trabajo.

La prueba más crítica de que la memoria no está correctamente ajustada es cuando \Memory\Pages/sec (que mide los errores severos de página por segundo) es elevado (superior a 10) durante cargas de pico. Si esto sucede, la primera acción depende de si está habilitado el almacenamiento en caché de web:

1.	Si está deshabilitado el almacenamiento en caché de web, deberá determinar si se necesita más memoria física supervisando la memoria utilizada por todos procesos del sistema. Los siguientes contadores del rendimiento le ayudarán: \Memory\Pages/sec\Memory\Pool Nonpaged Bytes\Memory\Pool Paged Bytes\Process(*)\Working Set
2.	Si está habilitado el almacenamiento en caché de web, primero pruebe a reducir el tamaño de la memoria caché al 10 por ciento de memoria física. Si aún hay errores severos de página, siga con el paso 1.

Implementación de servidor virtual

  Nota:

Se admite la instalación de ISA Server 2006 en Microsoft Virtual Server 2005 R2.

Debido a que el sistema operativo de Windows que aloja Virtual Server no puede ser protegido por ISA Server en un servidor virtual, ISA Server en un entorno Virtual Server no debe ser utilizado en un escenario de firewall perimetral,

y esta configuración no se admite. Usted puede usar esta configuración de forma segura en otros escenarios, tales como:

•	Una implementación en producción en la que ISA Server sobre Virtual Server ofrece servicios proxy web tales como proxy de reenvío, publicación y almacenamiento en caché y está protegido por un firewall perimetral, como un equipo ISA Server o una matriz adicionales.
•	Una implementación en laboratorio

Si usted encuentra altos \Process\wspsrv\Virtual Bytes valores de contador del rendimiento (valores de 1.800.000.000 (1,8 GB) indican que puede haber un problema), puede considerar la utilización de ISA Server sobre Virtual Server 2005 R2, como una alternativa a la compra de otro equipo ISA Server:

•	Defina el número de sistemas operativos invitados alojados por el servidor virtual. Cuando los bytes virtuales superen 1,8 GB, debería considerar agregar un sistema operativo virtual al equipo después de agregar 2 GB de memoria de acceso aleatorio (RAM).
•	Agregue RAM al equipo host (2 GB para cada sistema operativo invitado).
•	Instale Microsoft Virtual Server 2005 R2 en su servidor. Para más detalles, consulte el sitio web de Microsoft Virtual Server. Siga las recomendaciones de rendimiento en Ayuda y soporte técnico de Microsoft.
•	Instale sistemas operativos invitados.
•	Instale y configure ISA Server en cada sistema operativo invitado.
•	Utilice un equilibrador de carga externo, como por ejemplo, operación por turnos DNS (sistema de nombres de dominio) basado en hardware o equilibrio de carga de red de Windows (NLB), para propagar el tráfico entre los equipos ISA Server.

Las mediciones de una llamada a procedimiento remoto (RPC) sobre un escenario de publicación HTTP seguro (HTTPS) en un servidor con doble procesador o procesador de doble núcleo a 2,2 GHz con 8 GB de RAM mostraron lo siguiente:

•	Una única instalación de ISA Server en un equipo host administró 40.000 conexiones simultáneas con aproximadamente 2 GB de memoria virtual.
•	Tres equipos ISA Server instalados sobre tres sistemas operativos virtuales administraron 60.000 conexiones simultáneas y cada equipo virtual empleó sólo 1,3 GB. Este modelo podría ser escalado a más equipos virtuales (por ejemplo, cuatro, ocho, etcétera) en función de la cantidad de RAM y de la capacidad de procesamiento del servidor host. Las pruebas fueron ejecutadas en tres equipos.
•	El uso de CPU en ambos casos fue casi igual.

Determinar la capacidad de la red

Cada dispositivo de red que existe en una conexión tiene su límite de capacidad. Entre estos dispositivos se incluyen los adaptadores de red del cliente y del servidor, los enrutadores, conmutadores y los concentradores que los interconectan. Una capacidad adecuada de red significa que ninguno de estos dispositivos de red está saturado. La supervisión de la actividad de la red es esencial para asegurar que las cargas reales sobre todos dispositivos de red están por debajo de su capacidad máxima.

Hay dos casos generales donde la capacidad de red afecta al rendimiento de ISA Server:

•

ISA Server está conectado a Internet mediante un vínculo WAN. En la mayoría de las situaciones, el ancho de banda de la conexión a Internet establece el límite para la cantidad de tráfico. Es probable que la causa de un rendimiento bajo durante horas punta de tráfico sea la sobreutilización del vínculo de Internet. Esto se aplica también a un escenario de sucursal, donde los equipos ISA Server de la sucursal están conectados al equipo ISA Server en la sede central sobre una conexión lenta.

•

ISA Server está conectado sólo a redes LAN. En este caso, es importante disponer de una infraestructura que soporte los requisitos de tráfico máximo. Sin embargo, en la mayoría de las situaciones, esto no es un problema debido al bajo precio de las redes LAN de 100 Mbps y de 1 Gbps.

Para supervisar la actividad de la red, use el contador del rendimiento:\Network Interface(*)\Bytes Total/secSi su valor es superior al 75 por ciento del ancho de banda máximo de cualquier interfaz de red, considere aumentar el ancho de banda de la infraestructura de la red que no sea adecuado. O bien considere la utilización de las características avanzadas de ISA Server 2006 como se detalla en Almacenamiento en caché BITS y Compresión HTTP en este documento.

Determinar la capacidad de almacenamiento en disco

ISA Server utiliza el almacenamiento en disco para:

•	Registrar la actividad del firewall
•	Almacenamiento en caché de web

Si ambos están deshabilitados o no hay tráfico, ISA Server no realizará ninguna actividad de E/S de disco. En una instalación típica de ISA Server, el registro está habilitado y configurado para usar el registro de Microsoft SQL Server™ 2005 Desktop Engine (MSDE 2005). Para la mayoría de las implementaciones, un solo disco es suficiente para servir la tasa máxima de registro. Si está habilitado el almacenamiento en caché de web, la capacidad de almacenamiento en disco debe ser planificada cuidadosamente tal como se explica en Almacenamiento en caché de web en este documento.

El factor limitador de cualquier sistema de almacenamiento en disco es el número de accesos físicos a disco por segundo. Este número varía en función de lo aleatorios que sean estos accesos y de lo rápido que el disco gire físicamente. Generalmente, el límite está entre 100 y 200 accesos por segundo. El contador de rendimiento que se debe usar para supervisar la tasa de acceso a disco es:\PhysicalDisk(*)\Disk Transfers/secSi se alcanza este límite en un disco durante un espacio de tiempo prolongado es probable que el sistema se ralentice, lo que usted advertirá por un aumento en el tiempo de respuesta del sistema. Para eliminar este cuello de botella, la solución inmediata es reducir los accesos a disco agregando más discos físicos.

Otra causa de una alta tasa de acceso a disco son los errores severos de página. Para solucionar esta situación, consulte Almacenamiento en caché de web en este documento.

Filtros web y de aplicación

ISA Server utiliza filtros de aplicación para realizar la inspección de seguridad del nivel de aplicación. Un filtro de aplicación es una biblioteca de vínculos dinámicos (DLL) que se registra en un puerto de protocolo específico. Siempre que se envía un paquete a este puerto de protocolo, se pasa al filtro de aplicación, que lo inspecciona según la lógica de aplicación y decide qué hacer según la directiva. Cuándo no se asigna un filtro de aplicación a un protocolo, los datos se someten a filtrado activo TCP. En este nivel, ISA Server sólo comprueba la información de encabezado TCP/IP.

En general, el filtrado en el nivel de aplicación requiere más procesamiento que el filtrado activo TCP por varios motivos:

Debido a que los filtros de aplicación son ampliaciones de procesamiento del firewall, pueden tener una repercusión en el rendimiento. Recomendamos:

Registro

ISA Server ofrece dos métodos principales para registrar la actividad del firewall:

Comparando los dos métodos, MSDE tiene más características, pero utiliza más recursos del sistema. Concretamente, es probable que en general se produzca una mejora del 10 al 20 por ciento en la utilización del procesador al cambiar a registro sobre archivos desde MSDE.

El registro MSDE también consume más recursos de almacenamiento en disco. El registro MSDE realiza aproximadamente dos accesos a disco para cada megabit. El registro sobre archivos requerirá la misma cantidad de accesos a disco para 10 megabits. Una forma de mejorar el rendimiento del ISA Server es cambiar de registro MSDE a registro sobre archivos. Esto se recomienda sólo cuando haya un problema de rendimiento provocado por la saturación de un procesador o de accesos a disco.

ISA Server 2006 Enterprise Edition proporciona también registro remoto SQL, que puede ser utilizado para registrar sobre una base de datos SQL administrada de forma central. El registro remoto SQL consume recursos de CPU a medio camino entre los utilizados por registro MSDE y registro sobre archivos y no utiliza casi E/S a disco. Sin embargo, el registro remoto SQL presenta otros requisitos de capacidad que deben ser tenidos en cuenta, ya que todos los datos de registro se escriben en una base de datos central remota:

La tabla siguiente ofrece una estimación de la tasa de transacciones y del ancho de banda de registro para los tres anchos de banda del vínculo de Internet.

Para anchos de banda mayores, las cifras de la tabla anterior pueden ser extrapoladas linealmente.

Principio de la página

Escenarios

ISA Server es compatible con una amplia variedad de escenarios de implementación y aplicación. Las secciones siguientes describen la mayoría de los escenarios y sus características de rendimiento.

Escenarios de implementación

Los escenarios de implementación se refieren a la ubicación de un equipo ISA Server dentro de una intranet corporativa. Debido a consideraciones de seguridad y rendimiento, varios escenarios populares han evolucionado con el paso de los años y las secciones siguientes describen cada uno de ellos bajo una perspectiva de rendimiento y capacidad.

Firewall perimetral de Internet

Las organizaciones con necesidades de capacidad a escala de empresa pueden considerar la implementación un equipo ISA Server como un firewall perimetral de Internet dedicado que actúe como puerta de enlace segura a Internet para todos los clientes corporativos. Para mantener altos niveles de rendimiento de cientos de Mbps entre las redes internas e Internet, el ISA Server puede ser configurado para ofrecer sólo filtrado en el nivel de paquetes y de capa de transporte activo.

El filtrado más avanzado en el nivel de aplicación que proporciona ISA Server se habilitará en la segunda capa de defensa, que está compuesta por equipos ISA Server con firewall back-end.

Firewall departamental o back-end

La siguiente línea de defensa para organizaciones a escala de empresa incluye varios equipos ISA Server que son implementados como firewalls de departamento o back-end de red que ofrecen control de acceso entrante y saliente seguro dentro y fuera de redes LAN protegidas. Las organizaciones con infraestructuras de firewall ya existentes pueden mantener sus firewalls de alto rendimiento actuales en el perímetro de Internet y descargar el sofisticado filtrado de capa de aplicación hacia equipos ISA Server en el perímetro de LAN. Esto permitiría a una organización usar las actuales conexiones de Internet de alta velocidad y beneficiarse a la vez del nivel único de protección ofrecido por las capacidades de filtrado de capa de aplicación de ISA Server 2006.

Desde una perspectiva del rendimiento, es necesario un firewall de departamento para soportar sólo una parte del tráfico total que pasa por el firewall perimetral, permitiendo la ejecución de más características de seguridad que consuman recursos, tales como filtros de aplicación.

Firewall de sucursal

ISA Server puede ser utilizado para conectar de forma segura redes de sucursales a una oficina principal utilizando conexiones de red privada virtual (VPN) de sitio a sitio. En esta implementación, ISA Server se sitúa en una sucursal donde actúa tanto de firewall, protegiendo la red de la sucursal, como de puerta de enlace VPN, conectando la red de la sucursal a la red de la oficina principal.

En general, una VPN de sitio a sitio filtrada en el nivel de transporte consume sólo un 25 por ciento de la capacidad de procesamiento por unidad de tráfico que se necesita para el acceso a Internet filtrado en el nivel de aplicación.

  Nota:

En una VPN de sitio a sitio filtrada en el nivel de transporte, el tráfico que pasa por el túnel no lo inspeccionan filtros en el nivel de aplicación. El filtrado en el nivel de aplicación para tráfico VPN de sitio a sitio, como cualquier otro tráfico, está habilitado en una base por protocolo.

Escenarios proxy web

La mayoría del tráfico en Internet y dentro de las actuales redes corporativas utiliza HTTP. Un análisis de pautas de tráfico de muchos protocolos indica que HTTP es exigente en términos de rendimiento de la red. Por lo tanto, las simulaciones típicas de carga de trabajo de tráfico web son realistas para medir la capacidad y las características de rendimiento de cualquier firewall.

  Nota:

Una métrica típica para validar el rendimiento de la red es la cantidad de transacciones intercambiadas mediante conexión TCP. Los valores típicos para HTTP (3 a 5 de media) son reducidos en comparación con otros protocolos.

La tabla siguiente resume las recomendaciones de hardware para soportar el tráfico HTTP en tres implementaciones típicas con equipo individual según el ancho de banda del vínculo de Internet.

Vínculo de Internet	Hasta 5 T1 (7,5 Mbps)	Hasta 25 Mbps	Hasta T3 (45 Mbps)	Hasta 90 Mbps
Procesadores/núcleos	1	1	2	2/2
Tipo de procesador	Pentium III a 550 MHz (o superior)	Pentium 4 a 2,0–3,0 GHz	Xeon a 2,0–3,0 GHz	Xeon Doble Núcleo AMD Doble Núcleo 2,0–3,0 GHz
Memoria	256 MB	512 MB	1 GB	2 GB
Espacio en disco	150 MB	2,5 GB	5 GB	10 GB
Interfaz de red	10/100 Mbps	10/100 Mbps	100/1000 Mbps	100/1000 Mbps

Los requisitos de la tabla anterior son para la configuración predeterminada de la instalación de ISA Server 2006 y una configuración de la directiva que contiene centenares de reglas. Esto incluye todo el filtrado web y de aplicación predeterminado, así como el registro MSDE. Lo siguiente se refiere a la tabla anterior:

•	Ancho de banda del vínculo de Internet. Las cifras del ancho de banda se refieren a una carga de trabajo donde ISA Server 2006 se utiliza como proxy web transparente con filtrado completo de capa de aplicación HTTP. Al servir de proxy web de reenvío o inverso, ISA Server puede duplicar el rendimiento, lo que significa que el equipo mínimo recomendado para un ancho de banda T3 es un procesador Pentium 4 simple y un equipo con doble procesador para dos conexiones T3. Para más detalles acerca de diferencias de rendimiento entre varios escenarios proxy web, consulte Escenarios proxy en este documento. En las implementaciones que sólo necesiten filtrado activo (sin necesidad de mayor filtrado en el nivel de aplicación), el hardware recomendado alcanza las velocidades de cable LAN. Para más detalles, consulte Filtrado activo en este documento. Si está habilitado el almacenamiento en caché de web, se puede reducir el ancho de banda del vínculo de Internet entre un 20 y un 30 por ciento en función de la relación de aciertos de byte. Para más detalles, consulte Almacenamiento en caché de web en este documento.
•	Procesadores. Las cifras fueron obtenidas mediante la simulación de tráfico HTTP en miles de direcciones IP, cargando un procesador ISA Server hasta un 70-80 por ciento de utilización.
•	Tipo de procesador. También se pueden considerar otros procesadores que emulen el conjunto de instrucciones IA-32 con una potencia comparable.
•	Memoria. Los requisitos de la memoria no tienen en cuenta el espacio de memoria para el almacenamiento en caché de web. Para más información acerca de la memoria adicional para el almacenamiento en caché de web, consulte Almacenamiento en caché de web en este documento.
•	Espacio en disco. Los requisitos de espacio en disco indican la cantidad de espacio en disco libre que se recomienda para los registros del ISA Server. Para planificar los requisitos de espacio en disco para el almacenamiento en caché de web, consulte Almacenamiento en caché de web en este documento.
•	Interfaz de red. Los requisitos de interfaz de la red son para redes internas (las que no están conectadas a Internet).

ISA Server protege el tráfico HTTP mediante su filtro proxy web integrado. Este filtro de aplicaciones admite tres escenarios diferentes: Proxy de reenvío y proxy transparente para proteger el acceso de salida a Internet para usuarios corporativos y proxy inverso para proteger el acceso entrante de usuarios de Internet a sitios web internos. Las secciones siguientes describen cada uno de estos escenarios desde una perspectiva del rendimiento y explican cómo se puede usar el almacenamiento en caché para mejorar el rendimiento.

Escenarios proxy

Esta sección ofrece escenarios para proxy de reenvío, proxy transparente y proxy inverso.

Proxy de reenvío

En proxy de reenvío, los exploradores web cliente están enterados de la presencia del proxy. En Microsoft Internet Explorer®, por ejemplo, esto se hace configurando Utilizar un servidor proxy o Detectar la configuración automáticamente en Opciones de Internet. Cuando los clientes web tienen en cuenta el proxy, abren conexiones directamente al proxy y envían las solicitudes proxy para ubicaciones en Internet. (Por ejemplo, Internet Explorer abrirá dos conexiones al proxy al enviar solicitudes HTTP 1.1). Cuándo ISA Server recibe una solicitud para un servidor, abre una conexión a este servidor y lo vuelve a emplear para otras solicitudes procedentes de otros clientes al mismo servidor. Esto lleva a una topología de conexión en estrella.

La ventaja del rendimiento de este escenario es que permite una gran reutilización de las conexiones, lo que minimiza el número de conexiones abiertas, así como la tasa conexiones.

Proxy transparente

En proxy transparente, los exploradores web cliente no advierten la presencia del proxy. Detectan que son enrutados directamente a servidores en Internet sin agentes de por medio. Concretamente, los clientes web tienen acceso directo a servidores de Internet abriendo conexiones con los sitios web de destino. Esto conduce a un aumento considerable de la tasa de conexiones, ya que después de que un usuario pida una página en un nuevo servidor, el explorador web cierra sus conexiones con el servidor web actual y abre conexiones nuevas con el nuevo servidor web. Esto es típico de proxy transparente y afecta al rendimiento de ISA Server. Normalmente, la tasa de conexiones en el lado del cliente en proxy transparente es aproximadamente tres veces más alta que en proxy de reenvío, que consume aproximadamente el doble de ciclos de procesador por solicitud.

Proxy transparente es un escenario popular porque es fácil de implementar, especialmente para proveedores de servicios de Internet (ISP) con una base de clientes heterogénea. Por este motivo, hay considerables mejoras de rendimiento en este escenario.

En general, ISA Server requiere el doble de recursos de CPU para proxy transparente que para proxy de reenvío.

Proxy inverso

Proxy inverso o publicación en Web funcionan de la misma manera que proxy de reenvío, pero la dirección es de entrada en lugar de salida. En este escenario, ISA Server actúa como un sitio web al que tienen acceso clientes en Internet. Los clientes no saben que el sitio web al que tienen acceso es realmente un proxy. Al igual que con proxy de reenvío, el número de conexiones y la tasa de conexiones son mínimos, debido a la eficiente reutilización de conexiones. Proxy inverso se utiliza para la publicación segura de servidores web, como Microsoft Internet Information Services (IIS), Microsoft Office Outlook® Web Access 2003, Microsoft Office Sharepoint® Portal Server y muchos más.

Desde una perspectiva de rendimiento, el proxy inverso tiene características semejantes al proxy de reenvío. La diferencia principal es que la mayor cantidad de tráfico fluye desde el ISA Server a usuarios de Internet, lo cual requiere una gran conexión a Internet. Como se explica en la sección siguiente, el proxy de reenvío y el proxy inverso tienen diferentes repercusiones de rendimiento cuando está habilitado el almacenamiento en caché de web.

Almacenamiento en caché de web

El almacenamiento en caché de web es una característica para mejorar el rendimiento de ISA Server en todos los escenarios proxy web. Pero el efecto de la mejora del rendimiento es diferente cuando se habilita la memoria caché para escenarios de salida (proxy de reenvío y proxy transparente) y el escenario de proxy inverso de entrada.

La diferencia principal entre almacenamiento en caché de reenvío (transparente) e inverso es el propósito de la memoria caché. El almacenamiento en caché de reenvío (y transparente) está pensado para ahorrar costos de ancho de banda de Internet y para reducir el tiempo de respuesta mediante la colocación de contenido popular almacenable en la memoria caché cerca de los usuarios. El almacenamiento en caché inverso se utiliza para descargar los servidores web back-end. El almacenamiento en caché inverso no afecta al tiempo de respuesta e incluso aumentará el tiempo de espera para objetos que no están almacenados en la memoria caché.

En términos de ahorro, el almacenamiento en caché de reenvío ahorra intentos de acceso a servidores web en Internet al atender esos intentos desde la memoria caché, lo cual implica un ahorro en ancho de banda necesario del vínculo de Internet. Por ejemplo, si la relación de aciertos de byte de caché es del 20 por ciento y el rendimiento pico en los vínculos internos es de 10 Mbps, el rendimiento pico en el vínculo de Internet sería sólo de 8 Mbps.

  Nota:

La relación de aciertos de objeto de caché es la proporción de objetos que se atienden desde la memoria caché del total de objetos atendidos por el proxy. Igualmente, la relación de aciertos de byte de caché es la proporción de bytes que se atienden desde la memoria caché del total de bytes atendidos por el proxy. Los valores medios comunes son aproximadamente el 35 por ciento de la relación de aciertos de objeto y aproximadamente el 20 por ciento de la relación de aciertos de byte.

El almacenamiento en caché inverso ayuda a la consolidación de servidores web, reduciendo tanto los costos de hardware como de administración. Por ejemplo, si el 80 por ciento de los datos de un sitio web es estático y almacenable en caché y un objeto dinámico requiere cuatro veces más ciclos de CPU en comparación con un objeto estático, la utilización de un proxy inverso reducirá el número de servidores web en un 50 por ciento.

  Nota:

Supongamos que un objeto estático necesita X ciclos de CPU y un objeto dinámico requiere 4X ciclos. Si 80 de cada 100 solicitudes son estáticas, el número total de ciclos necesarios para 100 solicitudes es 80X + (100-80)4X = 160X, y el 50 por ciento de los utilizados para contenido estático serán servidos por una caché de ISA Server.

Otra diferencia entre la memoria caché inversa y de reenvío es la magnitud del conjunto de trabajo almacenado en caché. En caché inversa, el tamaño del conjunto de trabajo del cliente es ilimitado, pero el conjunto de trabajo del servidor contiene sólo varios sitios web y un número relativamente pequeño de objetos. En la mayoría de los casos, ISA Server puede diseñarse con la memoria y el espacio en disco razonables para almacenar todo el contenido almacenable en caché alojado en su caché, para que sólo el contenido dinámico no almacenable en caché sea dirigido a los servidores web alojados. Preferiblemente, toda la memoria caché puede ser guardada y servida en memoria.

En caché de reenvío, el espacio de servidor contiene un número ilimitado de sitios y objetos web, de modo que el conjunto de trabajo en caché es ilimitado. Para mantener un conjunto de trabajo tan grande, deberá definir cachés de disco grandes. Las secciones siguientes describen cómo planificar y ajustar la capacidad caché de web para el almacenamiento en caché inverso y de reenvío.

Ajuste de discos y memoria caché de reenvío

En el almacenamiento en caché de reenvío, la relación de aciertos de objeto y la tasa de solicitudes pico HTTP se utilizan para determinar el número de discos necesarios según la fórmula siguiente:

Número_de_discos = (Tasa_solicitudes_pico X Relación_aciertos_objeto) /100

Por ejemplo, si la tasa de las solicitudes pico es de 900 solicitudes por segundo y la relación de aciertos de objeto es del 35 por ciento, se necesitan cuatro discos.

  Nota:

El número 100 en la fórmula anterior es empírico y significa que el disco físico de rendimiento medio (que gira hasta 10.000 revoluciones por minuto) puede atender 100 operaciones E/S por segundo. Un disco más rápido girando a 15.000 revoluciones por minuto puede realizar entre 130—140 operaciones E/S por segundo.

Recomendamos usar discos dedicados del mismo tipo y de igual capacidad. Si se usa un subsistema de almacenamiento RAID, debe configurarse como RAID 0 (sin tolerancia a errores). Se recomiendan discos pequeños, preferiblemente de hasta 40 GB.

El ajuste de la memoria caché es más complicado. En los escenarios caché, la memoria se usa para:

•	Objetos de solicitudes pendientes. El número de objetos de solicitudes pendientes es proporcional al número de conexiones de clientes al equipo ISA Server. En la mayoría de los casos, será menor del 50 por ciento de las conexiones de clientes. Cada solicitud pendiente necesita aproximadamente 15 KB. Para 10.000 conexiones simultáneas, el conjunto de trabajo de la memoria del proxy web tiene hasta 50% × 10.000 × 15 KB = 75 MB asignados a objetos de solicitudes pendientes. Sin embargo en un RPC sobre escenario de publicación HTTP o HTTPS, todas las conexiones tienen un objeto de solicitud pendiente. Siguiendo el ejemplo anterior, un total de 100% × 10.000 × 15 KB = 150 MB están asignados a objetos de solicitudes pendientes.
•	Directorio de caché. El directorio que contiene una entrada de 48 bytes por cada objeto almacenado en caché. El tamaño del directorio de caché se determina directamente por el tamaño de la memoria caché y del tamaño medio de respuesta. Por ejemplo, una caché de 50 GB que aloja 7.000.000 objetos (aproximadamente 7 KB cada uno como media) necesita 48 × 7.000.000 = 336 MB.
•	Almacenamiento en memoria caché. El propósito del almacenamiento en memoria caché es servir las solicitudes de objetos populares almacenados en caché directamente desde la memoria, reduciendo las recuperaciones desde la memoria caché de disco. Pero puesto que el contenido almacenable en caché es ilimitado en el almacenamiento en caché de reenvío, el tamaño de la memoria caché tiene un efecto limitado sobre el rendimiento.

De forma predeterminada, la memoria caché es el 10 por ciento de la memoria física total y es configurable. En general, recomendamos usar la configuración predeterminada a menos que se produzcan errores severos de página. Los errores severos de página producen una grave degradación del rendimiento. La manera más fácil de corregir esta situación cuando se usa almacenamiento en caché es reducir el tamaño de la memoria caché.

Teniendo en cuenta esta información, use el proceso siguiente para ajustar el tamaño de la memoria caché:

1.	Ajuste el tamaño de la memoria caché de disco, como se explica en el apartado anterior.
2.	Calcule la memoria necesaria como el resultado de: 1. Objetos de solicitudes pendientes (50% × 15 KB × pico-conexiones-establecidas). 2. Tamaño de directorio de caché (48 x direccionesURL-en-caché). 3. Tamaño de memoria caché (de forma predeterminada, el 10 por ciento de la memoria total). 4. La memoria del sistema requiere aproximadamente 50 MB más 2 KB por conexión (50 MB + 2 KB x pico-conexiones-establecidas). 5. Al menos 100 MB para otros procesos en ejecución en el sistema.
3.	Supervise el uso de memoria y cambie el tamaño de la memoria caché como corresponda. Los contadores informativos del rendimiento son: \ISA Server Cache\Memory Cache Allocated Space (KB) \ISA Server Cache\Memory URL Retrieve Rate (URL/sec) \ISA Server Cache\Memory Usage Ratio Percent (%) \ISA Server Cache\URLs in Cache \Memory\Pages/sec \Memory\Pool Nonpaged Bytes \Memory\Pool Paged Bytes \Process(WSPSRV)\Working Set \TCP\Established Connections

Ajuste de discos y memoria caché inversa

En el almacenamiento en caché inverso, el tamaño del conjunto de trabajo es tan pequeño en comparación con el almacenamiento en caché de reenvío que es relevante tratar de ponerlo todo en memoria. El tamaño del conjunto de trabajo es la cantidad total de objetos almacenables en caché en el sitio web que aloja la memoria caché. Se recomienda que el tamaño del disco y de la memoria caché sea aproximadamente el doble del tamaño del conjunto de trabajo para mantener todos los objetos almacenables en caché y para justificar la directiva de fragmentación en la asignación de discos y de actualización de caché. Por ejemplo, un conjunto de trabajo de 500 MB requiere una caché de disco de1.000 MB y una memoria de 1.500 MB con un tamaño de caché de memoria al 66 por ciento.

Debido a que la mayoría de recuperaciones de caché se sirven desde la memoria caché, la tasa de E/S sobre el disco es baja. En la mayoría de los casos, un solo disco físico es suficiente, sin llegar a ser un cuello de botella.

Utilizar el modificador /3GB en boot.ini

Para grandes sistemas con más de 2 GB de memoria, Windows Server 2003 y Windows 2000 Advanced Server ofrecen la característica de ajuste 4GT RAM. Esta característica divide un espacio de la memoria del proceso en 3 GB para la memoria de aplicación y 1 GB para la memoria de sistema. Esta característica permite que los procesos se beneficien de más de 2 GB de RAM de espacio de usuario y se habilita agregando el modificador /3GB al archivo boot.ini. (Para más detalles, consulte el artículo Q171793, "Información sobre el uso de aplicación del ajuste 4GT RAM" en la Microsoft Knowledge Base).

Esta característica puede ser beneficiosa para ISA Server, especialmente para el almacenamiento en caché inverso que aloja un sitio web grande. Sin embargo, el empleo de esta característica reduce el tamaño máximo de la agrupación no paginada (a 128 MB en lugar de 256 MB); de ahí el número máximo de conexiones TCP simultáneas.

Almacenamiento en caché BITS

El Servicio de transferencia inteligente en segundo plano (BITS), introducido en ISA Server 2004 Service Pack 2 (SP2) e incluido en ISA Server 2006, habilita el almacenamiento en caché de solicitudes de intervalo HTTP para Windows Update. BITS ofrece un ahorro considerable en el consumo de ancho de banda y reduce la demora en la descarga de actualizaciones en implementaciones con bajo ancho de banda, lo que es importante debido a la creciente demanda de actualizaciones a través de Web.

La medición del rendimiento de almacenamiento en caché BITS mostró lo siguiente:

•

El almacenamiento en caché BITS duplica la relación general de aciertos durante el proceso de actualización mensual del 10 por ciento al 20 por ciento. Durante la actualización mensual, hubo un ahorro del 18 por ciento del tráfico total.

•

El tráfico administrado con el almacenamiento en caché BITS funciona mucho mejor que cualquier otro tráfico web, debido al rendimiento medio extraordinariamente alto por conexión y relación de aciertos. Por ejemplo, en el mismo hardware, el almacenamiento en caché BITS puede atender tres o cuatro veces más bits con la misma utilización de procesador que el tráfico web administrado sin BITS. La habilitación del almacenamiento en caché BITS para Windows Update no tiene repercusión negativa en las características de rendimiento del tráfico que no está asociado a Windows Update.

Compresión HTTP

ISA Server 2006 ofrece una característica de compresión del protocolo de transferencia de hipertexto (HTTP). Cuando se configura la compresión HTTP, ISA Server puede comprimir el contenido para conservar el ancho de banda limitado. Esto es útil, por ejemplo, en escenarios donde una oficina principal proxy dirige las solicitudes de Internet directamente a Internet y las sucursales dirigen sus solicitudes a través de la oficina principal, sobre una red con ancho de banda limitado. La característica utiliza un algoritmo de compresión muy conocido (GZip) para comprimir los datos HTTP, mientras que la razón de compresión varía en función del tipo de datos de destino. (De manera predeterminada, sólo se comprimen los datos basados en texto).

  Nota:

Cuando los filtros web de ISA Server inspeccionan el contenido comprimido entrante, se descomprime el contenido comprimido. Una vez descomprimido, el contenido se almacena en la memoria caché en forma de texto descomprimido. Si ISA Server recibe una petición del contenido almacenado en caché, lo vuelve a comprimir antes de enviarlo, lo que aumenta el tiempo de respuesta.

Al medir la compresión HTTP sobre una línea de 56 Kbps con una latencia de 50 milisegundos (msec), en conexión con un equipo ISA Server en la sede central a múltiples equipos ISA Server en las sucursales y pasando un total de 96 Mbps (descomprimidos), los datos mostraron lo siguiente:

•	La compresión HTTP posee el mayor impacto en una red lenta. Mejora el uso de red en un 28 por ciento y de esta manera mejora el rendimiento total del sistema.
•	La latencia entre la sede central y las sucursales mejoró en un factor de 15.
•	El impacto en la CPU habilitando compresión HTTP en el sistema probado (dual Xeon a 2,4 GHz) fue del 15 por ciento.

Autenticación web

Hay muchos métodos para realizar la autenticación web y cada uno tiene su propia repercusión en el rendimiento. La tabla siguiente resume las ventajas y las desventajas de cada método.

Esquema de autenticación	Seguridad	Cuándo se realiza la autenticación	Sobrecarga por solicitud	Sobrecarga por lote
Básica	Baja	Por tiempo	Baja	Ninguna
Digest	Media	Por tiempo/contador	Ninguna	Alta
NTLM	Media	Por conexión	Ninguna	Alta
NTLMv2	Alta	Por conexión	Ninguna	Alta
Kerberos	Alta	Por conexión	Ninguna	Media
SecurID	Alta	Por sesión de explorador	Ninguna	Media
RADIUS por solicitud	Alta	Por solicitud	Alta	Ninguna
RADIUS por tiempo de espera (predeterminado)	Media	Por tiempo	Baja	Ninguna

Desde la perspectiva del rendimiento, un esquema de autenticación funciona mejor sin sobrecarga por solicitud y con una sobrecarga por lote baja. Decidir qué esquema de autenticación usar depende de la seguridad y la infraestructura.

Igualmente, la autenticación proxy web puede ser configurada al nivel de escucha proxy web o al nivel de regla. Elija el nivel de escucha sólo si la autenticación es necesaria para todos los accesos web. De otro modo, elija el nivel de regla, lo que significa que esa autenticación será realizada sólo cuando sea necesario según las reglas.

Filtros web

Al igual que los filtros de aplicación, los filtros web pueden tener también una repercusión en el rendimiento, en función de lo que hagan. ISA Server incorpora varios filtros web que realizan tareas especificadas. De éstos, los que más CPU consumen son el filtro HTTP y el filtro de traducción de vínculos.

Un filtro HTTP inspecciona cada solicitud y respuesta web, comprobando que cumplen la utilización normal del protocolo HTTP. Está habilitado de forma predeterminada, y su configuración predeterminada proporciona los límites de tamaño a encabezados HTTP y dirección URL. Otras características disponibles incluyen bloqueo por métodos, por extensiones, por encabezados y por carga de firmas HTTP. Estas funciones no tienen repercusión en el rendimiento cuando se seleccionan, excepto bloqueo de firma, que requiere un 10 por ciento más de ciclos de CPU. Se recomienda un filtro HTTP para proteger el tráfico web.

La traducción de vínculos se utiliza específicamente en escenarios de publicación en Web. Se inspeccionan los cuerpos de las respuestas en HTML, buscando hipervínculos absolutos, y se modifican para que apunten al equipo ISA Server en su lugar. De forma predeterminada, la traducción de vínculos inspecciona los cuerpos de respuesta y encabezados HTTP, de modo que hay una notable repercusión en el rendimiento. Cuando está habilitada la inspección de cuerpos, comprueba de forma predeterminada sólo el contenido HTML, provocando un incremento general del 15 por ciento en la utilización de la CPU.

Publicación en Web segura

Utilizando capa de sockets seguros (SSL), ISA Server mejora la publicación segura de una variedad de contenido web. ISA Server, junto con SSL, habilita el acceso privado a sitios web publicados y, para usuarios corporativos, protege el acceso a varios recursos de red internos, tales como correo electrónico, sitios web compartidos, servicios de Terminal Server, etc.

SSL es un protocolo TCP que utiliza el puerto 443. SSL se conoce también como HTTP seguro (HTTPS), ya que define un entorno seguro, autenticación y cifrado para el contenido HTTP.

Desde la perspectiva del rendimiento, el cifrado y el descifrado SSL crean una capa de procesamiento adicional, más allá del procesamiento HTTP normal. Esta capa incluye dos fases intensivas importantes de CPU:

La proporción entre el rendimiento agregado y la tasa de conexiones determina la media del número de bits que son procesados en cada conexión. Esta proporción se define como bits por conexión y, en la práctica, cada aplicación tiene un valor característico para esta proporción.

A continuación se muestran algunos ejemplos.

Outlook Web Access

Cuando un cliente web se conecta a un servidor front-end de Outlook Web Access Exchange Server, carga la página web de Outlook que contiene los iconos de la interfaz de usuario y los encabezados de los mensajes que hay actualmente en el buzón. En consecuencia, cualquier operación que el usuario realice (tal como Abrir, Enviar, o Mover a carpeta) genera una nueva conexión HTTP que transfiere un promedio de 10 a 20 kilobytes (KB). Cuando se suma el comportamiento de Outlook Web Access de muchos usuarios, el cliente web crea normalmente un valor de bits por conexión relativamente bajo (del orden de 100 kilobits por conexión).

RPC sobre HTTP con Outlook 2003 en modo de Exchange en caché

La llamada a procedimiento remoto (RPC) sobre HTTP es una característica de Microsoft Exchange Server 2003 que permite a los clientes Outlook 2003 tener acceso a un Exchange Server en la red corporativa interna desde Internet. Al conectarse a Exchange Server, un cliente Outlook 2003 que funcione en modo de Exchange en caché normalmente comienza con una sincronización del contenido del buzón sobre un archivo de caché local. Cuando se ha completado la sincronización, se producen conexiones intermitentes, en las que se transfieren los nuevos mensajes. Para un trabajador con conocimientos con un perfil de uso intenso, la operación de sincronización transfiere muchos bytes de datos sobre un número pequeño de conexiones, de modo que el valor característico general de bits por conexión es bastante elevado (del orden de 500 kilobits por conexión).

  Nota:

Cada RPC sobre cliente HTTP establece aproximadamente 10 conexiones, de modo que debe considerar también la cantidad total de conexiones (el número de clientes x 10) al planificar su implementación.

Sitio web

Hay muchas maneras de diseñar e implementar un sitio web. Por tanto, los sitios web no tienen un valor de bits por conexión típico. Sin embargo, después de que un sitio web sirva solicitudes, usted puede medir los bits acumulados por conexión. En la práctica, los sitios web tienen valores de bits por conexión medios (entre 100 y 500 kilobits por conexión).

Protocolo de puente SSL

Cuándo usted implementa ISA Server con publicación en Web segura, los clientes web seguros en la red externa pueden conectarse al puerto SSL. El protocolo de puente SSL es una característica de ISA Server, que le permite especificar cómo se comunica ISA Server con el servidor web back-end que está publicado. Esta característica permite que usted pueda elegir entre los dos tipos siguientes de protocolo de puente:

Protocolo de puente SSL a SSL refuerza la seguridad en la red Interna, pero agrega el costo de procesamiento del doble cifrado a cada paquete que se transfiere entre ISA Server y el servidor back-end. Protocolo de puente SSL a SSL cuesta aproximadamente un 10 por ciento más que el protocolo de puente SSL a HTTP.

Determinar la capacidad SSL

Para determinar el tamaño del equipo ISA Server que debe tener para cargas de tráfico de red pico, deberá primero medir los kilobits típicos por conexión de su tráfico de red y después medir el tráfico agregado total. Utilice el procedimiento siguiente para determinarlo:

1.	Utilice la herramienta monitor de rendimiento del sistema para supervisar el tráfico de red de cada servidor de aplicaciones para las dos horas punta de la actividad del servidor. Recopile los contadores siguientes: \Network Interface\Bytes Total/sec. Éste es el contador de la interfaz publicado por ISA Server. Utilice el valor medio como el rendimiento medio de la duración. Este valor también se utiliza para calcular el tráfico agregado total.\TCPv4\Connections Active. El valor de este contador es el número total de conexiones creadas durante la sesión de supervisión. Para determinar la media de conexiones por segundo dentro de esta duración, divida la diferencia entre los valores máximos y mínimos entre la duración total. Calcule el número de kilobits por conexión de esta forma: kilobits por conexión = (total de bytes por segundo × 8 por 1000) por (conexiones por segundo).
2.	Determine la media total de kilobits por conexión como la media ponderada de kilobits por conexión de cada servidor de aplicaciones. El peso para cada servidor es el rendimiento de ese servidor dividido por el rendimiento total de todos servidores.
3.	Determine el tráfico agregado total agregando el tráfico medido en cada servidor.
4.	Utilice la tabla siguiente para determinar el número de megaciclos que se necesitan por cada megabit de tráfico SSL que procesa ISA Server, según los kilobits por conexión medidos en el Paso 2. Kilobits por conexión 100 (Outlook Web Access) 200 (Web) 500 (RPC sobre HTTP) 1 procesador, SSL a HTTP 91 77 69 1 procesador, SSL a SSL 120 96 83 2 procesadores, SSL a HTTP 128 104 91 2 procesadores, SSL a SSL 142 120 104
5.	Para determinar la velocidad del procesador que necesaria para soportar el tráfico agregado total, multiplique los megaciclos por megabit, de la tabla del Paso 4 por el rendimiento total, tal como se midió en el Paso 3.   Nota: A causa de la variedad de configuraciones de ISA Server, escenarios de uso y de plataformas de hardware, los números anteriormente citados sólo para propósitos de estimación. Para implementaciones con un ancho de banda del vínculo de Internet superior a 10 megabits por segundo, recomendamos hacer una prueba piloto para comprobar estas estimaciones.

Por ejemplo, supongamos que los kilobits por conexión calculados en el Paso 2 son 200, el rendimiento agregado total es de 15 megabits y necesita que ISA Server realice protocolo de puente SSL a SSL. Según se extrae de la tabla anterior, un solo procesador necesita 96 megaciclos por megabit o 96 × 15 = 1440 megaciclos por 15 megabits por segundo. Un procesador Intel Pentium 4 simple a 2,4 GHz es suficiente para esta carga y se utiliza a 1440/2400 = 60% a rendimiento pico. Un equipo con doble procesador con dos procesadores Intel Pentium 4 a 2,4 GHz necesita 120 megaciclos por megabit o 120 × 15 = 1800 megaciclos por 15 megabits por segundo y se usa al 1800/ (2 × 2400) = 38% a rendimiento pico.

La tabla siguiente muestra la cantidad del tráfico en megabits que un procesador a 2,4 GHz puede procesar al máximo de utilización recomendado (80 por ciento).

Esta tabla es específica para implementaciones en las que ISA Server se utiliza sólo para tráfico SSL. Si tiene previsto implementar ISA Server para tráfico SSL y HTTP no cifrado, puede estimar la capacidad de procesamiento que necesita calculando una media ponderada de megaciclos según la cantidad de tráfico de cada escenario multiplicada por los megaciclos por megabit, mostrados en la tabla siguiente.

Por ejemplo, supongamos que desea implementar ISA Server en un escenario de firewall perimetral en el cual el 40 por ciento del tráfico pico de 20 megabits por segundo es proxy transparente, el 35 por ciento es proxy de reenvío y el 25 por ciento es SSL a SSL con 200 kilobits por conexión. La cantidad total de megaciclos necesarios para que ISA Server procese este tráfico en un equipo con un solo procesador es:

megaciclos = 20 megabits por segundo × (74 × 40% + 37 × 35% + 96 × 25%) = 1331

Un procesador Intel Pentium 4 a 2,4 GHz es suficiente para procesar esta carga y se utiliza al 1331/2400 = 55% de rendimiento pico. Un equipo de doble procesador requiere 20 × (86 × 40% + 43 × 35% + 120 × 25%) = 1589 megaciclos, que utiliza 1589/ (2400 × 2) = 33% de dos procesadores Intel Pentium 4 a 2,4 GHz a rendimiento pico.

VPN

Una red privada virtual (VPN) consiste en dos escenarios básicos: VPN de acceso remoto y VPN de sitio a sitio. Ambos pueden usar varios protocolos y trabajar en conjunción con filtrado de aplicación o con filtrado activo. Los protocolos basados en seguridad de protocolo de Internet (IPsec) pueden usar también las capacidades de descarga de hardware disponibles en muchos adaptadores de red, lo que mejora la utilización general del procesador. Algunos protocolos pueden funcionar con compresión para aumentar el rendimiento o ahorrar ancho de banda. Todas estas características afectan al rendimiento, como se explica en las secciones siguientes.

VPN de acceso remoto

Los clientes remotos que llaman desde Internet utilizan acceso remoto por VPN para tener acceso a sus redes corporativas. Los protocolos empleados en el acceso remoto son protocolo de túnel punto a punto (PPTP) y protocolo de túnel de capa dos (L2TP) sobre seguridad de protocolo de Internet (IPsec). Ambos protocolos son compatibles con la compresión, que está recomendada porque ahorra ancho de banda y capacidad de procesamiento necesarias para el cifrado.

Para determinar la capacidad adecuada para un servidor VPN ISA Server, primero necesitará evaluar el número máximo de conexiones remotas simultáneas que su equipo ISA Server necesita soportar. Por ejemplo, si espera que menos del 5 por ciento de los empleados de su organización establezcan conexiones remotas simultáneamente y su organización tiene 5.000 empleados, 250 conexiones simultáneas de acceso remoto VPN simultáneas es la capacidad que necesita.

La tabla siguiente indica el número máximo de conexiones simultáneas de acceso remoto VPN admitidas por cada plataforma de hardware. Estas cifras implican una configuración de ISA Server lista para funcionar que incorpora filtrado proxy web, registro MSDE y compresión tanto para PPTP como L2TP sobre protocolos IPsec.

Lo siguiente se refiere a la tabla anterior:

En las implementaciones donde los clientes VPN son de mayor confianza, se puede deshabilitar el filtrado del nivel de aplicación, lo que mejora la capacidad total y reduce el nivel de seguridad. La tabla siguiente muestra las cifras cuando está deshabilitado el filtro proxy web.

Lo siguiente se refiere a la tabla anterior:

VPN de sitio a sitio

En una VPN de sitio a sitio hay dos opciones principales desde una perspectiva de rendimiento y capacidad. Una opción es usar PPTP o L2TP sobre IPsec. Estos protocolos ofrecen compresión del tráfico de la aplicación, lo que duplica el rendimiento que puede ser transferido a través del vínculo de sitio a sitio. Por ejemplo, el envío de archivo de 2 MB a través de un túnel PPTP o L2TP realmente pasará sólo 1 MB. La otra opción es usar túnel IPsec, que no incorpora compresión. Así que de hecho, PPTP y L2TP sobre IPsec ahorran rendimiento de sitio a sitio en un 50 por ciento, en comparación con túnel IPsec.

Con el filtro proxy web deshabilitado, L2TP sobre IPsec necesita un único procesador Pentium III a 750 MHZ para un tráfico de aplicación de 15 Mbps. El paso de este tráfico en una dirección requiere sólo una capacidad de vínculo de 7,5 Mbps, debido a la compresión. Un procesador Pentium 4 simple a 3 GHz puede controlar un tráfico de aplicación de hasta 90 Mbps que necesite una capacidad de vínculo T3 (45 Mbps). Cuando el filtro proxy web está habilitado, un procesador Pentium III a 750 MHz puede soportar un tráfico de aplicación de 7 Mbps que requiere un ancho de banda de vínculo de Internet de 3,5 Mbps, mientras que un procesador Pentium 4 simple a 3 GHz administra un tráfico de aplicación de 34 Mbps que corresponde a un ancho de banda de Internet de17 Mbps. Los procesadores Dual Xeon a 3 GHz pueden administrar un tráfico de aplicación de 53 Mbps que requiere un ancho de banda del vínculo de Internet de 26,5 Mbps. PPTP puede administrar aproximadamente entre un 15 y un 20 por ciento más rendimiento para el mismo consumo de CPU.

La segunda opción es usar túnel IPsec, que no es compatible con la compresión, lo que significa que el tráfico del vínculo de Internet es igual que el tráfico de aplicación. Al funcionar en conjunción con filtrado activo (el filtro proxy web está deshabilitado), el túnel IPsec puede administrar 10 Mbps en un único procesador Pentium III procesador a 550 MHZ y 52 Mbps en un procesador Pentium 4 simple a 3 GHz. Cuando está habilitado el filtro proxy web, las cifras de rendimiento son 4 Mbps, 18 Mbps y 30 Mbps para el procesador Pentium III simple, Pentium 4 simple y las plataformas dual Xeon, respectivamente.

La tabla siguiente resume estos resultados: los megabits reales admitidos por segundo al 75 por ciento de utilización de CPU. (Los números entre paréntesis representan los volúmenes de tráfico no comprimido).

La descarga de hardware IPsec, disponible en muchos adaptadores de interfaz de red, puede aumentar los valores de rendimiento entre un 20 y un 25 por ciento.

VPN de sitio a sitio en varias sucursales

En muchas organizaciones, es común encontrar un escenario con varias sucursales y una sola sede central. En esta configuración, varios equipos de sucursales están conectados al mismo equipo en la sede central. Esto se conoce como topología en estrella.

Una medición del escenario mostró que un solo equipo ISA Server en la sede central puede admitir hasta 60 equipos de sucursales conectados simultáneamente, con una tasa de tráfico de 200 Kbps. El hardware utilizado para esta prueba fue un procesador Quad AMD a 2,4 GHz con 2 GB de RAM. Los túneles VPN fueron creados utilizando L2TP sobre IPsec.

Principio de la página

Escalado de ISA Server

Hay varias maneras de escalar un sistema ISA Server:

•	Mediante un equipo hardware de conmutación de red de alto nivel. Estos conmutadores a menudo se denominan conmutadores L3, L4 o L7 (capa 3, capa 4 o capa 7) porque proporcionan capacidades de conmutación basada en la información disponibles en diferentes capas de red. La conmutación L3 se basa en información de capa de paquete (IP), L4 se basa en información de capa de transporte (TCP) y L7 realiza conmutación basada en datos de aplicación (encabezados HTTP). La información disponible en estos niveles puede proporcionar un sofisticado equilibrio de carga, según el origen IP o las direcciones de destino, los puertos TCP de origen o destino, dirección URL y tipo de contenido. Debido a que los conmutadores son implementados como aparatos de hardware, tienen un rendimiento relativamente alto y tienen una alta disponibilidad y fiabilidad, pero son costosos. La mayoría de los conmutadores pueden detectar condiciones de bloqueo de servidor, habilitando tolerancia a errores.
•	Mediante resolución de nombres de operación por turnos DNS. A un clúster de servidores se le puede asignar el mismo nombre en el Sistema de nombres de dominio (DNS). DNS responde a consultas para ese nombre examinando la lista de forma cíclica. Se trata de una solución económica (sin costo), pero tiene inconvenientes. Un problema es que la carga no se distribuye necesariamente de manera uniforme entre los servidores del clúster. Otro problema es que no proporciona tolerancia a errores.
•	Mediante equilibrio de carga de red de Windows. Equilibrio de carga de red (NLB) funciona compartiendo una dirección IP con todos los servidores de un clúster y todos los datos enviados a esa dirección IP son vistos por todos los servidores. Sin embargo, cada paquete es servido sólo por uno de los servidores, según alguna función hash compartida. NLB se implementa en el nivel del sistema operativo. Proporciona equilibrio de carga uniformemente distribuido y admite tolerancia a errores. (Otros servidores del clúster pueden detectar si falla un servidor y distribuir su carga entre ellos). Sin embargo, requiere sobrecarga de procesamiento de CPU (aproximadamente entre el 10 y el 15 por ciento en escenarios ISA Server comunes) y tiene un límite en el número de miembros en el clúster (aproximadamente 8 equipos como máximo recomendado). Para más información acerca de cómo implementar NLB, consulte "Conceptos de integración de equilibrio de carga de red para Microsoft Internet Security and Acceleration (ISA) Server 2006" en el sitio web de Microsoft Technet.
•	Mediante el Protocolo de enrutamiento de matriz de caché. Para escenarios de almacenamiento en caché, ISA Server admite el Protocolo de enrutamiento de matriz de caché (CARP), que es un protocolo de equilibrio de carga en caché. No sólo distribuye la carga entre los servidores, sino también el contenido almacenado en caché. Cada solicitud se envía a un equipo específico del clúster, para que los siguientes sean servidos de ese equipo.

Debido a que ISA Server mantiene un estado para cada secuencia que pasa a través de él, todos los métodos de escalado deben admitir adherencia para que todos los datos pasen por el equipo ISA Server.

El escalado se utiliza para aumentar la capacidad de un sistema. Cada método de escalado tiene sus ventajas y sus inconvenientes y, para ISA Server, también depende del escenario. Al decidir qué método de escalado usar, considere lo siguiente:

•	Factor de rendimiento. El factor de multiplicación para rendimiento agregado cuando se duplica el número de equipos en la matriz.
•	Costo del sistema. Costo inicial de compra del sistema y no el costo de propiedad.
•	Administración del sistema. Nivel de complejidad en la administración del sistema. Tiene consecuencias directas sobre los costos de propiedad del sistema.
•	Tolerancia a errores. Método utilizado por el sistema para posibilitar la alta disponibilidad y confiabilidad.
•	Crecimiento del sistema. Método utilizado para aumentar la capacidad de procesamiento del sistema. El costo de actualizaciones también es un factor importante.

A continuación se muestran algunas implicaciones que considerar al decidir escalar:

•

Único punto de posibles errores contra tolerancia a errores. La disponibilidad de una implementación con un solo equipo es más susceptible de errores de hardware que un clúster de varios equipos. Un error en la placa base o en el controlador de disco provocará que falle el sistema entero y necesite reparación. Esto también es cierto para un equilibrador de carga de hardware que no funcione correctamente.

•

Crecimiento. Actualizar una solución de equipo único de un procesador a dos procesadores es sencillo, siempre y cuando haya una ranura de procesador vacía en el equipo (o puertos disponibles en el conmutador de equilibrio de carga de hardware). En clústeres de varios equipos, agregar otro equipo es más complicado.

La tabla siguiente resume los métodos de escalado.

Características	Conmutador de hardware	Windows NLB	Operación por turnos DNS	CARP
Factor de escala	2	1,75 para el tráfico web 1,9 para SSL y acceso remoto VPN	2	Empezando en 1,5 y aproximándose asintóticamente a 2
Costo del sistema.	Costoso	Sin costo agregado	Sin costo agregado	Sin costo agregado
Tolerancia a errores	Depende del conmutador (la mayoría detecta equipos con errores y carga a los otros)	Por detección mutua de equipos que fallan	Ninguna	Por detección mutua de equipos que fallan
Escenario	Todos	Todos	Todos	Sólo almacenamiento en caché de reenvío

Lo siguiente se refiere a la tabla anterior:

•	NLB requiere una sobrecarga de rendimiento del 15 por ciento cuando se habilita. Una matriz NLB con un solo miembro realizará el 15 por ciento menos que la misma matriz con NLB deshabilitado. Por lo tanto, al estimar la capacidad con escalado NLB, primero hay que reducir los valores de rendimiento para un solo equipo en un 15 por ciento y a continuación aplicar los factores de escala.
•	El factor de escala NLB para el tráfico web implica una configuración de afinidad bidireccional (al configurar más de un clúster de NLB en una matriz). En muchos casos, la afinidad simple será suficiente para el tráfico web, en cuyo caso el factor de escala es 1,9.
•	Cuando se utiliza una VPN de sitio a sitio con NLB, no es posible equilibrar la carga de varios túneles que conectan dos sitios sobre varios miembros de la matriz. En este caso, NLB sólo proporciona tolerancia a errores. Cuando se conecta un sitio sobre una matriz NLB a muchos sitios, ISA Server propagará los túneles sobre todos los miembros de la matriz.

Principio de la página

Ajuste del tamaño del Servidor de almacenamiento de configuración

Uno de los componentes del servidor que se introduce con ISA Server 2006 Enterprise Edition es el componente del Servidor de almacenamiento de configuración. El Servidor de almacenamiento de configuración es el repositorio del diseño de la empresa y la configuración para cada equipo ISA Server en la empresa. Este repositorio es un ejemplo de Active Directory® Application Mode (ADAM). Cada equipo ISA Server tiene una copia local de su configuración que es una réplica de la configuración del servidor, que se encuentra en el Servidor de almacenamiento de configuración.

El número recomendado de equipos ISA Server que se pueden conectar a un solo Servidor de almacenamiento de configuración es 300, y el máximo recomendado es 600. Estas cifras fueron estimadas con medidas de rendimiento de la operación más intensiva de recursos sobre el Servidor de almacenamiento de configuración (la importación de una directiva a gran escala con centenares de reglas con miles de referencias a objetos de directiva, dando como resultado un archivo de lenguaje de marcado extensible (XML) de aproximadamente 6 MB. En este escenario, el Servidor de almacenamiento de configuración importa el archivo XML y crea una nueva configuración. Tan pronto como el Servidor de almacenamiento de configuración comienza a escribir los datos de la nueva configuración a disco, todos los equipos ISA Server conectados comienzan a recuperar esta configuración al mismo tiempo, dando como resultado una carga considerable de CPU, red y E/S a disco en el Servidor de almacenamiento de configuración. Utilizando un equipo con doble procesador Intel Pentium 4 a 3,6 GHz con 2 GB de memoria física para el Servidor de almacenamiento de configuración, las mediciones muestran que el Servidor de almacenamiento de configuración podría soportar un nivel de 2.600 solicitudes de Protocolo ligero de acceso a directorios (LDAP) por segundo. El número total de solicitudes LDAP por equipo ISA Server requeridas para la sincronización completa con importación de directiva a gran escala es de 7.000. Estas cifras se traducen en el tiempo necesario para una sincronización completa de todos los equipos ISA Server después de que el Servidor de almacenamiento de configuración importe un archivo XML de directiva a gran escala, de la siguiente manera:

Tiempo total de importación = Tiempo para la importación XML + Tiempo para escribir la configuración a disco + Tiempo para sincronizar la configuración por todos los equipos ISA Server

Donde:

Tiempo para la importación XML = 120 segundos

Tiempo para escribir la configuración a disco = 120 segundos

Tiempo para sincronizar la configuración por N equipos ISA Server = N × 7000 / 2600 = 2,7 × N segundos

La tabla siguiente resume estos resultados.

Durante las dos primeras fases (la importación XML y escritura de la configuración a disco), el nivel de utilización de CPU fue aproximadamente del 50 por ciento. Esto se debe a que lo realiza un solo subproceso que no puede consumir más del 50 por ciento de la capacidad de procesamiento de un equipo con doble procesador. En equipos de procesador único, el consumo de CPU será del 100 por cien en estas fases, una situación que debe ser evitada. Por lo tanto, recomendamos implementar equipos de doble procesador para el Servidor de almacenamiento de configuración o bien habilitar tecnología Hyper-Threading en un equipo de procesador único (con procesadores Pentium 4).

Para obtener información detallada acerca de la implementación del Servidor de almacenamiento de configuración de ISA Server, consulte "Instrucciones de implementación para ISA Server 2006 Enterprise Edition" en el sitio web de Microsoft Technet.

Principio de la página

Referencia y ejemplo de ajuste de tamaño

Esta sección ofrece una referencia central y un resumen para ajustar el tamaño de ISA Server 2006 Standard Edition y Enterprise Edition. La primera tabla proporciona los megaciclos por megabit para el proxy web, SSL, VPN y escenarios de filtrado activo.

SSL - SSL a HTTP

SSL - SSL a SSL

Acceso remoto VPN - filtro web habilitado

Acceso remoto VPN - filtro web deshabilitado

VPN de sitio a sitio - filtro web habilitado

VPN de sitio a sitio - filtro web deshabilitado

Lo siguiente se refiere a la tabla anterior:

Las cifras de la tabla anterior se obtuvieron utilizando los supuestos siguientes:

Lo siguiente se refiere a la tabla anterior:

El ejemplo siguiente ilustra cómo usar las tablas anteriores para calcular el hardware necesario para soportar los requisitos de tráfico específicos.

Supongamos que un sitio grande tiene un ancho de banda de vínculo de Internet de 80 megabits por segundo que se usa por completo en horas de utilización pico. Durante este tiempo, el 10 por ciento del tráfico se utiliza para acceso VPN remoto (L2TP sobre IPsec con filtro web habilitado), el 20 por ciento se utiliza para Outlook Web Access (utilizando protocolo de puente SSL a HTTP) y el 70 por ciento se utiliza para exploración web de salida (50 por ciento para proxy transparente y 50 por ciento para proxy de reenvío). Para calcular los megaciclos necesarios para este tráfico, calcule primero los megaciclos ponderados por megabit, suponiendo una única implementación en equipo dual Xeon (sin equilibrado de carga):

Megaciclos/megabit = 353 × 10% + 128 × 20% + 86 × 35% + 43 × 35% = 107

La cantidad total de megaciclos por segundo necesarios para 80 megabits por segundo es 80 × 107 = 8560.

Un equipo con doble procesador a 3 GHz tiene sólo 2 × 3000 × 75% = 4500 megaciclos cuando se utiliza al 75 por ciento, lo cual no es suficiente. Es necesario escalar con más equipos. En este momento, no queda claro exactamente cuánto se necesita probablemente dos, pero quizá tres. Para calcular el número factorizado de megaciclos necesarios por megabit, multiplique el número de megaciclos por megabit para cada de tipo de tráfico por su factor de escala correspondiente y recuerde realizar otra factorización del +15 por ciento. Para dos miembros de una matriz, tome 1,143 para el tráfico web (presuponiendo Arquitectura de controlador de difusión) y 1,053 para tráfico VPN y SSL. El resultado es:

Megaciclos/megabit factorizados presuponiendo una matriz de dos miembros = 115% × (353 × 10% × 1,053 + 128 × 20% × 1,053 + 86 × 35% × 1,143 + 49 × 35% × 1,143) = 136

El total de megaciclos por segundo necesarios resultante es de 80 × 136 = 10880. Esto es demasiado para ser servido por dos miembros. (Dos equipos con doble procesador a 3 GHz soportan sólo 2 × 4500 = 9000 megaciclos por segundo). Tres equipos probablemente tendrán suficiente capacidad para soportar esta carga. El resultado del cálculo es:

Megaciclos/megabit factorizados presuponiendo una matriz de tres miembros = 115% × (353 × 10% × 1,085 + 128 × 20% × 1,085 + 86 × 35% × 1,236 + 49 × 35% × 1,236) = 143

El total de megaciclos por segundo necesarios resultante es de 80 × 143 = 11440. Tres equipos con doble procesador a 3 GHz proporcionan 13500 megaciclos por segundo a un 84 por ciento de utilización del procesador. Esto es suficiente para soportar esta carga y proporciona algo de espacio para crecimiento.

Principio de la página

Información adicional

Para obtener más información, consulte lo siguiente:

Principio de la página