Administrando el CRECIMIENTO del servidor web
"Una vez que usted tiene una idea de sus necesidades futuras de desempeño, existen muchas cosas que puede hacer -algunas a bajo costo, otras no- para mejorar tanto la velocidad como la confiabilidad de su servidor actual: Actualice su versión del OS/400, afine el TCP/IP y los parámetros LAN, agregue hardware de red AS/400, y descargue tareas menos críticas en otros servidores."
Definitivamente, esta es una época en la que la gran mayoría de los negocios tendrán que dirigirse a los ambientes de Red. El comercio y los negocios electrónicos, las transacciones y los intercambios informáticos a distancia, y la consolidación de las cada vez más utilizadas tecnologías de dispositivos móviles con capacidades de Red, obligan a los diferentes actores a consolidar su o sus servidores de Red. El AS/400, como es natural, se perfila como una poderosa herramienta en este bullicioso entorno. Así, Mel Beckman detalla en este artículo algunos de los pasos clave que han de observarse para sacar el máximo provecho del AS/400 como servidor de Red. "Confiabilidad, desempeño, bajo costo -escoja dos-".
Es una mantra frecuentemente repetida que resume los factores con los que un administrador de red tiene que hacer malabares frente al crecimiento de la demanda de servicios de Red del usuario. Mientras que tener un servidor de Red arriba y corriendo puede realizarse directamente, mantenerlo con tráfico de Red creciente es una batalla interminable. En una intranet, en la medidad en que los desarrolladores de aplicaciones conviertan más aplicaciones heredadas en entregas de Red, el tráfico local de Red puede incrementar exponencialmente. En Internet, en la medida que los clientes encuentran el comercio y las relaciones públicas con base Web más convenientes, el tráfico remoto de Red aumenta. Ambos negocios hacen que cada vez más su servidor de Red empresarial sea uno de misión crítica. Su reto se vuelve uno en que ha de afrontar estas demandas e incrementar la confiabilidad sin romper el presupuesto. Una solución al problema es gastar mucho dinero en servidores masivos y en grandes pipas de Internet. Una aproximación mucho más conciente de los costos es incrementar el desempeño de su servidor de Red. Muchas de las técnicas descritas abajo pueden ayudar a hacerlo justo de esa manera.
Una clave para implementar mejoras de desempeño es analizar el desempeño para medir los efectos de los cambios. Mejoras tales como la carga de CPU, transacciones Web por hora, y los megabits transmitidos por segundo representan los latidos de su servidor. Capturar valores comunes de estas mediciones, junto con el conocimiento del número de usuarios a los que proporciona el servicio, le permite predecir los efectos de agregar más usuarios, aplicaciones, o ambos. Una vez que usted tiene una idea de sus necesidades futuras de desempeño, existen muchas cosas que puede hacer -algunas a bajo costo, otras no- para mejorar tanto la velocidad como la confiabilidad de su servidor actual: Actualice su versión del OS/400, afine el TCP/IP y los parámetros LAN, agregue hardware de red AS/400, y descargue tareas menos críticas en otros servidores.
En algún momento, sin embargo, tendrá que agregar redundancia para cubrir el tráfico creciente y las demandas de confiabilidad. Si está sirviendo en Internet, también tendrá que ensanchar -e incrementar el número de- conexiones de Internet. Aprender diversas técnicas para la administración del servidor redundante le permitirá escoger la aproximación con el costo más eficiente de acuerdo con su situación.
Red-o-metrosz
Antes de que pueda saber hacia dónde va, necesita saber dónde está. Numerosos factores afectan el desempeño de su servidor de Red; descubrir qué factores son problemáticos en su ambiente actual es el objetivo del análisis del desempeño. Incluso si usted no cree que tiene un problema de desempeño, el análisis de desempeño de su ambiente de servidor de Red que corre bien, establece una base para futuras comparaciones; el seguimiento continuo del desempeño le ayuda a identificar los cambios en la demanda y responder a ellos antes de que el desempeño decrezca.
El AS/400 puede correr cierto número de servidores de Red de diversos vendedores (no examinamos ofertas específicas de los vendedores aquí, de manera que verifique con su proveedor de software para las implementaciones específicas de productos a modo). Estos difieren en sus caracterí sticas, pero todos desempeñan un número de tareas similares:
Servir páginas HTML estáticas
Entregar objetos grandes, como gráficas y applets de Java
Crear múltiples hileras de ejecución para usuarios simultáneos
Ejecutar programas de lenguaje de alto nivel (HHL, por sus siglas en inglés) a través de la Common Gateway Interface (CGI)
Gateway Interface (CGI)
Recuperar y actualizar información a través de SQL
Procesar macros Net.Data
Ejecutar servlets Java que accesen objetos integrados al archivo del sistema
Encriptar el intercambio de tráfico con browser activados en Secure Sockets Layer (SSL)
Cada una de estas tareas consume tiempo precioso de CPU, pero no lo hacen de manera equitativa. La habilidad de su AS/400 para responder a los requerimientos del usuario depende de la mezcla de estas cargas en sus aplicaciones. Todos los servidores Web AS/400utilizan esencialmente las mismas facilidades del OS/400 para llevar a cabo estas tareas. Por ejemplo, los requerimientos SQL son procesados por la DB2 Universal Database AS/400 (DB2/UDB), y los servlets de Java son ejecutados por el ambiente de ejecución de Java nativo del OS/400. Por esta razón, IBM ha publicado los factores de desempeño -llamados tiempos CPU relativos- que lo ayudan a predecir el efecto de cambiar cualesquiera de estas cargas en su ambiente informático.
Si usted está preparando un AS/400 para usarlo como un servidor de Red, puede hallar útil el Workload Estimator de IBM para AS/400 ( http:// web. archive.org/web/20030204003701/http://as400service.ibm.com/estimator ). Esta herramienta le permite especificar, en términos muy generales, el tipo de descargas -como una ejecución de Java-, el número de usuarios, y los porcentajes de transacciones que espera que le entregue su AS/400; entonces genera una prueba de configuración que IBM cree que puede manejar la descarga. Usted puede estar seguro que la estimación de IBM es generosa, de manera que no siga ciegamente estas recomendaciones de la herramienta. Una verificación adicional es construir su aplicación para evitar tareas costosas en la medida de lo posible, y después hacer mediciones realistas de desempeño en un AS/400 real para determinar el tamaño real del servidor.
Cuando su servidor de Red está corriendo, es difícil medir estos diferentes factores de desempeño utilizando las herramientas de medición AS/400 tradicionales. Sin embargo, todos los servidores Red AS/400 le permiten registrar el trabajo real que está siendo desempeñado por el servidor. Este registro contiene la información más importante sobre el desempeño de su Hypertext Transfer Protocol (HTTP). El formato de registro http está estandarizado en Internet y prácticamente todos los servidores Web se adecuan al estándar. Estos formatos de registro graban la fecha y el tiempo de cada transferencia http, la forma y el tamaño del objeto transferido, y la identidad del usuario que ha solicitado la transferencia.
Este meticuloso nivel de detalle genera registros enormes que son difíciles de interpretar sin ayuda. Afortunadamente, cierto número de herramientas de análisis de registros pueden ayudarlo a condensar los registros http en estadísticas con sentido. Una de estas herramientas para el AS/400 es el componente de WebSphere Site Analysis, una parte del WebSphere Application Server, cuya edición estándar es gratis en el AS/400. El WebSphere Analysis corre en Windows, recuperando automáticamente los registros http del servidor AS/400, y genera y predefine conjuntos de reportes - incluyendo cuadros gráficos- que usted puede personalizar para cubrir sus necesidades.
El Site Analyser le permite ver el tráfico de cargas sobre el tiempo, de manera que usted puede avistar tendencias (Figura 2) y saber qué importantes demandas están siendo solicitadas en sus servidor. También proporciona un resumen de transacciones http por objeto de Red, frecuencia y tamaño (Figura 3), que usted puede utilizar para identificar objetos de alto uso listos para la optimización. Otros reportes analizan el trá fico por usuario, por sesión y por localización geográfica. Una característica dinámica de contenido encauza los parámetros que pasan por los Java servlets y por las Java Server Pages (JSP). La herramienta corre sobre una base periódica (por ejemplo, de manera nocturna), utilizando una sesión FTP agendada para recuperar el registro HTTP AS/400 y procesarlo. El Output también está en la forma http, permitiéndole distribuir fácilmente reportes y gráficos.
El servidor Web que usted usa puede incluir sus propias herramientas de análisis de registros, o puede comprar herramientas de un tercero que procesen registros http estándar. El punto importante es no dejar para más tarde el análisis rutinario de registros Web. Establecer un parámetro de desempeño y encauzar las tendenciaas es el meollo de todas las otras técnicas de mejora del desempeño.
Diferencias en los modelos AS/400 y el OS/400
La versión del OS/400 que usted está corriendo puede tener un mayor impacto en el desempeño TCP/IP. El V4R2 es la versión más vieja que usted puede considerar correr. Éste incorpora el protocolo de estantería mejorado TCP/IP que incluye los asistentes de desempeño RISC-hardware. Sin embargo, usted puede mejorar todavía más el desempeño actualizando a una versión más usual. El servidor HTTP V4R3 corre por lo menos cincuenta por ciento más rápido que las ediciones previas, e IBM hacce numerosas mejoras al TCP/IP en la versión V4R3 que levantan el desempeño de todos los servidores TCP/IP.
Seleccionar un modelo AS/400 apropiado también afecta el desempeño. A pesar de que usted pudiera pensar de otra manera, el OS/400 tiene que ver con los trabajos TCP/IP -incluyendo a los servidores Web- como un trabajo no interactivo. El AS/400e y los AS/400 Advanced Servers son los modelos mejor colocados para los trabajos no interactivos.
Su AS/400 también debe usar Ethernet en vez de Token Ring o adaptadores WAN para la interface de Red. No obstante que Token Ring soporta arriba de 16 Mbps frames más grandes que los 10 Mbps Ethernet, los IOPs Ethernet de IBM proporcionan soporte (en V4R4) para optimizaciones TCP /IP no disponibles en Token Ring. Cualquier LAN IOP se dessempeñará mejor que una WAN IOP, de manera que si usted va a conectar directamente su AS/400 a una WAN a través de, por ejemplo, Frame Relay, debe considerar cambiar a un ruteador WAN externo comunicado con su AS/400 a través de Ethernet.
Estirando el TCP/IP
IBM embarca el OS/400 con ejecuciones de comunicación que cubren un amplio rango de protocolos, incluyendo TCP/IP, SNA e IPX. Pero esta generalidad tiene como resultado un desempeño por debajo de los estándares si usted está corriendo TCP/IP únicamente para proporcionar los protocolos de Internet (i.e., HTTP). Unos pocos ajustes menores pero críticos a las características nativas de IBM pueden mejorar ampliamente el desempeño total de la red y traducirlo en una respuesta en tiempo más rápida para los usuarios y en menos trabajo para el CPU de su AS//400.
Si usted está corriendo el V4R4 con un adaptador Ethernet, puede cambiar la línea descriptiva de la Ethernet para soportar solamente TCP/IP a trav és del parámetro TCPONLY (Figura 4). Esto produce que el IOP Ethernet, en el siguiente reinicio, cargue una versión TCP/IP optimizada en su microc ódigo y mueve cierto número de funciones TCP (por ejemplo, cálculo y verificación de checksum) del procesador principal del AS/400 al IOP. Note que estas características impiden correr cualquier forma de SNA o IPX en esta interface, así que asegúrese que no tenga aplicaciones dependientes de estos protocolos antes de hacer el cambio.
Para cualquier versión del OS/400, incrementar la cantidad de memoria dirigida a un paquete de procesos TCP/IP, ayuda al desempeño. La funci ón nativa de la orden envío y recepción del tamaño de parámetros del buffer de CHGTCPA (Change TCP/IP Attributes) para TCP/IP de IBM (Figura 5) es de solamente 8,192 bytes. Antes del V4R4, el valor útil máximo es de 65,536 bytes por buffer, y usted debería siempre elevar este número. El V4R4 puede tomar ventaja de más de 8 MB (8,388,608 bytes) totales para manejar altos volúmenes de transacción. Dependiendo de cuanta memoria tenga usted, incrementar el número de bytes puede incrementar el número de transacciones simultáneas que su AS/400 puede procesar. Usted tendría que colocar un millón de bytes (1,000,000) en cada buffer si es posible, y más si la memoria disponible lo permite.
El ambiente de comunicaciones que usted puede cambiar para mejorar el desempeño TCP/IP es el tamaño máximo de unidades de transmisión ( MTU). Este valor estable el tamaño máximo de un paquete TCP/IP. El valor MTU prestablecido es de 576 bytes. Esto es con mucho muy pequeño para Ethernet, que puede ajustar arriba de 1,496 bytes por paquete. El entorno prestablecido da como resultado un OS/400 que transmite y recibe tres veces tantos paquetes como sea necesario, incrementando grandemente el CPU y la carga de trabajo IOP y volviendo ineficiente el uso del ancho de banda disponible como resultado de los paquetes de headers redundantes.
Para cambiar el valor MTU del menú TCP/IP configurado (GO CFGTCP), escoja "Work with TCP/IP Rules" para seleccionar las rutas por los que usted quiere cambiar el tamaño del MTU. Generalmente, usted sólo escogerá uno, la ruta prestablecida (*DFTROUTE), pero si su AS/400 tiene rutas hacia redes que no sean Internet, usted debería elegir cambiarlas también. Especificar la opción Change en una ruta saca el prompt de la orden Change TCP/IP Route (CHGTCPRTE) (Figura 6). Cambie la orden a "Interface" (*IFC) para indicar al TCP/IP que utilice el máximo posible de ejecución en la interface en uso (por ejemplo, Ethernet, Token Ring). Las líneas descrptivas prestablecidas proporcionadas por IBM para Ethernet contienen el tama ño MTU correcto de 1,492 bytes.
Además de alterar los parámetros genéricos de comunicaciones, usted puede hacer diversos cambios en la configuración del servidor http con el fin de mejorar el desempeño. Los dos cambios más comunes son deshabilitar el buscador Domain Name Service (DNS) para permitir que la memoria atrape con frecuencia los objetos solicitados. Otras giros del desempeño deben estar disponibles para su servidor -verifique la documentación de su vendedor para detalles-.
El buscador DNS es el proceso de búsqueda de un nombre para la dirección IP de cada visitante de su sitio, de manera que el nombre pueda ser grabado en el archivo de registros del servidor HTTP. Mientras que esto hace conveniente la lectura manual del archivo de registros, al mismo tiempo es una operación costosa que puede hacer que su sitio Web opere muy lentamente. Esto es así debido a que la página inicial para un usuario determinado no es desplegada hasta después de que la resolución DNS se ha completado -un proceso que requiere más que muchos segundos-. Si su visitante no tiene un nombre asociado con su dirección IP, el usuario puede esperar hasta que el DSN termine -comúnmente un minuto o más- antes de obtener el contenido de Red, volviendo el acceso prácticamente imposible.
El buscador DNS en tiempo real no es verdaderamente necesario, debido a que prácticamente todas las herramientas de análisis de registros desempeñarán estas tareas para usted en modo batch, que es mucho más eficiente. Apagar el buscador DNS puede mejorar grandemente la respuesta en tiempo.La Figura 7 muestra cómo hacer esto con el servidor HTTP de IBM.
La recuperación dentro del depósito de memoria de objetos Web frecuentemente accesados acelera el tiempo de respuesta al eliminar el acceso de disco. Para la mayoría de los servidores, esta característica se apaga automáticamente, pero el tamaño del depósito, está inicialmente establecido para un tamaño pequeño -de unos pocos kilobytes como máximo-. Si usted tiene memoria disponible, incrementar el tamaño del depósito a muchos megabytes puede reducir las lecturas del disco en más del 50 por ciento si una gran cantidad de contenido es proporcionado repetidamente. Más allá del depósito en memoria, usted querría considerar un depósito externo (que se describe más abajo) como futuro spiff de desempeño.
Mejoras de hardware
Si usted quiere todavía un mejor desempeño TCP/IP después de ajustar las comunicaciones y los parámetros del servidor, considere actualizar su hardware. Como ha estado viendo, el TCP/IP V4R4 puede tomar ventaja de la memoria adicional para proporcionar altos porcentajes transaccionales. Agregar memoria es probablemente uno de las más sencillas mejoras de hardware que usted puede hacer, ya que esta mejoría no requiere TCP/IP o cambios de aplicación. La memoria adicional también le permite correr un mayor número de servidores de trabajo TCP/IP, que incrementan el número de transacciones simultáneas que su servidor puede procesar.
En AS/400 más grandes, la LAN IOP se vuelve un cuello de botella para el desempeño. IBM dice que los adaptadores 10Base Ethernet más viejos ( previos al V4R1), puede procesar cerca de 800 paquetes por segundo con TCPONLY(*YES); los adaptadores más nuevos manejan alrededor del doble de este promedio. Con el tamaño máximo por paquete, 800 paquetes por segundo pueden llenar fácilmente la capacidad disponible de la 10Base Ethernet. Y dado que la mayoría del tráfico de Red consiste en muchos paquetes pequeños y sólo unos pocos más grandes, la utilización real es mucho más baja, de manera que los adaptadores Ethernet más nuevos pueden incrementar sustancialmente el tráfico.
Dividir el numero de paquetes en 10 (debido a que el promedio de objetos http requiere cerca de 10 paquetes para transferir) da una ruda aproximación del número de objetos HTTP transferidos, o "hits", que usted puede proporcionar con una interface dada. El panorama es de cerca de 80 por segundo para adaptadores más viejos y de 160 por segundo para adaptadores más recientes. Cada página Web usualmente posee numerosos hits -uno para la página misma y uno para cada objeto gráfico de la página. Una página tradicional tendrá entre cinco y diez objetos, generando entre cinco y diez hits. Dependiendo de la frecuencia de uso, este promedio determina el número de servidores que usted puede implementar. Por ejemplo, si el usuario promedio llama una nueva página que requiere 10 hits cada 10 segundos y su servidor puede proporcionar 100 hits por segundo, usted puede servir cerca de 100 usuarios. Este es el mejor caso de valor, asumiendo que el procesador CPU no es un cuello de botella. El número cae en la medida que la página Web y la complejidad de las transacciones crece.
Si usted está corriendo un sólo adaptador 10Mbps Ethernet, usted puede mejorar este porcentaje añadiendo un segundo adaptador Ethernet, con una segunda dirección IP, y distribuyendo las peticiones ente los adaptadores utilizando una DNS round-robin. Esto eleva a cerca de cuatro adaptadores Ethernnet; después de ese punto, la carga de trabajo CPU para administrar múltiples adaptadores prefigura las ganancias en desempeñ o.
Es interesante observar que el adaptador 100 Mbps Ethernet de IBM solamente proporciona cerca del doble de tráfico del más gordo adaptador de 100 Mbps -cerca de 3,200 paquetes por segundo-. Cuatro tarjetas de 100 Mbps pueden cuadruplicar su tráfico a cerca de 12,000 paquetes por segundo. Debido a que la Ethernet 100BaseT utiliza el mismo MTU que la 10BaseT, la 100BaseT no reduce el número de paquetes que su servidor debe tener en campo -solamente los mueve a una mayor velocidad-. Incluso cuatro las tarjetas 100BaseT únicamente utilizan entre 25 y 50 por ciento de la capacidad disponible 100BaseT en una aplicación común de servidor de Red.
Moviendo las cargas de trabajo
Una manera de asegurarse que los usuarios de Red obtienen la mejor utilidad de un servidor AS/400 HTTP, es asegurarse que la interface de ancho de banda del servidor y que los caballos de fuerza del CPU estén exclusivamente dedicados al servidor de Red. Usted debe mover tareas no relacionadas, tales como sesiones de emulación de terminales interactivas, trabajos batch, y otros servidores TCP/IP (por ejemplo, FTP, DNS, SMPT), a otros servidores, posiblemente en otros segmentos Ethernet. Debe evitar correr ciertos servicios -particularmente AnyNet, NetServer, (archivos compartidos de Windows y Client Access- en el servidor HTTP.
Todos estos consumen cantidades prodigiosas de memoria AS/400 y tiempo de CPU incluso cuando no están moviendo tráfico. Si usted utiliza estos servicios para actualizar información en su servidor HTTP, habilítelos sólo durante el tiempo en que esté transfiriendo los archivos HTML. Deshabilitar los servicios cuando no están en uso libera los recursos para el proceso HTTP.
Todavía mejor, utilice el FTP para cargar los archivos HTML, porque el servidor FTP de IBM no consume recursos cuando las transferencias no están siendo efectuadas.
No sienta que tiene que descargar todos estos servicios en otro AS/400. Usted puede encontar las encarnaciones de DNS, SMPT y los servicios de archivos compartidos de Windows y Unix más fáciles de ejecutar y mantener que sus contrapartes en AS/400.
Como notamos anteriormente, mucho del contenido proporcionado por un servidor Web es repetitivo -todos los usuarios tienden a descargar la misma home page, los mismos gráficos, y mucho del mismo HTML-. Solamente el contenido dinámico difiere en realidad de un usuario a otro. Una manera de afianzar su procesamiento de transacciones AS/400 es descargando el contenido repetitivo a un servidor externo reverse proxy cache.
Un depósito externo de poder inverso (reverse proxy cache) se ubica entre su servidor Web y los usuarios remotos, de manera que todas las peticiones para su AS/400 van primero al servidor de poder (proxy server), el que las canaliza, si es necesario, a su AS/400. Este funciona mucho m ás parecido al depósito de memoria interna de un servidor HTTP nativo AS/400. La primera vez que una petición para un objeto particular ocurre, el proxy simplemente la pasa a su servidor AS/400. Cuando su servidor responde entregando el objeto requerido, éste responde al depósito del servidor, el que pasa el objeto de vuelta al peticionario original. No obstante, el depósito del servidor también desliza una copia de este objeto -generalmente en el disco-, así que el próximo usuario que lo pida puede ser servido directamente por el depósito del servidor en lugar del AS/400.
Usted puede construir su propio servidor de depósito de poder inverso corriendo el software del depósito de poder en una computadora existente. Existen paquetes de depósito open-source como Apache ( http://web.archive.org/web/20030204003701/http://www.apache.com/ ) y Squid ( http ://web.archive.org/web/20030204003701/http://www.nlanr.net/Squid ), o usted puede comprar una aplicación que autocontenga un utensilio de depósito. Tanto el Apache como el Squid corren en el AS/400, e IBM espera embarcar versiones de estos servidores más tarde en este mismo año. Los factores clave para elegir un servidor de depósito son su disco y sus capacidades de memoria de depósito. El tamaño del depósito de disco determina la cantidad máxima de información que usted puede almacenar, en tanto que la memoria mantiene a mano los objetos con más frecuancia requeridos para una rápida entrega sin accesar el disco.
Departamento de redundacia departamento
En la medida en que los usuarios se vuelven más dependientes del contenido entregado por la Red, usted necesitará incrementar la confiabilidad del servicio de entrega de dicho material. Esto es menos importante para una intranet -donde usted tiene un control listo de todos los componentes de red- que cuando los usuarios se originan de Internet. Si un cable o una conexión Ethernet fallan en su LAN, usualmente usted puede identificar al componente que ha fallado y remplazarlo en el corto tiempo. Cuando usted usa características de alta disponibilidad como la protección de almacenamiento RAID y procesadores múltiples, el mismo AS/400 es comúnmente el componente más confiable.
En Internet, sin embargo, muchas cosas pueden ir mal -la mayoría de ellas fuera de su control directo-. La liga digital a su proveedor de Internet puede fallar. Su proveedor de Internet puede tener problemas internos que hacen imposible para los usuarios alcanzar su confiabilidad de servdor. Problemas en el backbone de Internet puede partir la Internet en segmentos inalcanzables, haciendo imposible la conexión para algunos usuarios.
Para cubrir estos problemas, usted necesita facilidades redundantes de Internet que automáticamente se hagan cargo en la eventualidad de una falla, un proceso llamado fail-over automático. Un primer corte común de tal redundancia es de un segundo, al hacer la recuperación del link con su provedor de Internet (Figura 9). Usualmente, el link de recuperación es de la misma velocidad y tipo del link principal, posiblemente utilizando un carrier diferente de intercambio local para excluir el problema de telecomunicaciones como un solo punto problemático. Durante una operación normal, el tráfico es balanceado equitativamente a través de ambas ligas.
Cuando una liga falla, la otra reanuda la inoperante y encauza el tráfico a través de las dos ligas. Esta aproximación trabaja bien mientras la carga del tráfico normal sea del 50 por ciento o menos en ambas ligas. Si esta es más alta, una sola liga no podrá acomodar todo el tráfico durante una ruptura, causando la pérdida de los paquetes y una pobre respuesta en tiempo. Esta técnica tampoco puede desviar los problemas a su proveedor de Internet o al backbone de Internet, así que mientras mejora la confiabilidad, no cubre todas las posibles caídas. Para obtener la mejor protección fuera de esta técnica, usted debe usar ruteadores separados para cada conexión, así su ruteador deja de ser un solo punto problemático.
Una mejora en esta técnica es tener dos o más ligas de Internet de proveedores diferentes, generalmente también con dos o más ruteadores locales (Figura 10). Este proceso, llamado multihoming, requiere un ingeniero de Internet entendido para ser ejecutada exitosamente. Si usted puede tener un block completo de direcciones IP Class C, usted estaría listo para usar una dirección IP para su servidor, ruteada a través de ambas ligas.
Un block Class C (de 256 direcciones) es el block más pequeño que puede ser anunciado en dos ligas Internet por dos proveedores de manera simult ánea. Si usted separa subredes más pequeñas de cada proveedor, usted puede asignar una dirección IP a cada subred en su puerto Ethernet AS/400 (una característica del V4R4) y utilizar un DNS round-robin para distribuir el tráfico entre dos ligas.
El DNS round-robin trabaja regresando una dirección IP diferente a cada visitante sucesivo de su sitio (Figura 11). Doquiera que un servidor DNS tenga más de una dirección IP para un nombre dado, éste opera en la modalidad round-robin, la que difícilmente se puede aproximar al balance de la carga en condiciones correctas. Algunos servidores DNS round-robin (pero no, ay de mí, el OS/400) puede ser sensibles a la utilización de ligas y balancear el tráfico a través de éstas. Si una liga llegara a fallar, este modelo del servidor DNS es suficientemente listo para dejar de proporcionar direcciones IP a la liga que ha fallado.
Una tercera aproximación a la redundancia es correr dos o más servidores, cada uno en una locación diferente en Internet (Figura 12). Este mé todo lo protege de cualquier falla simple de un ruteador, ligas de comunicación, o ISP. Esto también lo aisla de muchos problemas del backbone de Internet --una falla que afecte a un proveedor no es susceptible de afectar a un segundo proveedor no relacionado-. Usted puede rentar espacio en la llamada "Web farm" para completar este arreglo de servidores distribuidos. Una llave para una apropiada funcionalidad de los servidores distribuidos es un solo servidor Internet DNS registrado en cada locación. El sistema DNS utiliza un servidor centralizado nombrado, llamado root name server, para almacenar la lista de servidores delegados para traducir nombres en números para cada nombre del dominio. En la técnica DNS round-robin failover, cada servidor DNS autorizado devuelve sólo la dirección IP del servidor HTTP a esa locación. Al dar de alta el parámetro Time to Live (TTL) del nombre DNS para su servidor HTTP a un valor más bajo (a unos pocos minutos) usted alcanza un fail-over automático: Si un servidor determinado se vuelve inalcanzable, su DNS es también inalcanzable, y los usuarios irán al siguiente servidor DNS Internet registrado. El bajo valor TTL asegura que los usuarios retendrán una dirección IP dada solamente por unos cuántos minutos antes de que sea renovada, con el fin de prevenir a un usuario que trate de accesar un servidor inalcanzable. Una vez que el tiempo fuera expira, el sistema del usuario localizará uno de los servidores disponibles.
La aproximación final, y la más recientemente desarrollada, a la redundancia es utilizar un servicio especializado en depósitos distribuidos remotos ( Figura 13). Dos de estos servicios son Akamai ( http://web.archive.org/web/20030204003701/http://www.akamai.com/ ) y Digital Island ( http:// web.archive.org/web/20030204003701/http://www.digitalisland.com/ ). Estos servicios utilizan un servidor DNS especial de distribución de tráfico que trabaja con su propio servidor principal de contenido para distribuir objetos de Red frecuentemente solicitados para servicios de depósito cerca de los usuarios que requieran el contenido.
Esto reduce su dependencia de una conexión local de Internet y le permite manejar subidas repentinas en el tráfico. Debido a que cada usuario recupera mucho de su contenido de un servidor de depósito cercano, los usuarios ven una respuesta en tiempo consistente. Los servicios de depó sito distribuidos cobran por el gigabyte (comúnmente de 15 a 50 dólares por gigabyte proporcionado), así que entre más los use más paga. No obstante, los servicios le permiten entregar grandes andanadas de tráfico sin invertir en caras conexiones Internet de multimegabits que podrían desperdiciar mucho tiempo. Ya que el depósito distribuido depende de su propio servidor como fuente de información a ser depositada, esta técnica incrementa la confiabilidad cuando usted tiene servidores fuente redundantes.
En conclusión
Optimizar los tres grandes factores Web -confiabilidad, desempeño y costo- es algo posible de hacer, siempre que siga unos pocos lineamientos. El AS/400 contribuye muchísimo en la fórmula al proporcionarle una plataforma robusta y confiable para comenzar. Después de tomar ciertas medidas b ásicas de desempeño, usted puede comenzar a retorcer las configuraciones y actualizar donde sea apropiado para alcanzar sus objetivos. Las medidas de desempeño en marcha -y su revisión- son la clave para detectar problemas antes de que estos se vuelvan serios, dándole tiempo de cubrirlos apropiadamente. Agregar redundancia le permite mejorar la confiabilidad en los incrementos, algunos más caros que otros.
Si su servidor está destinado a muchos usuarios y un bajo ancho de banda, usted puede incrementar la redundancia y distribuir su contenido a trav és de numerosos sitios para potenciar la confianza y la velocidad simultáneamente. Su confiable AS/400 sigue constituyendo el corazón estratégico de su red, de manera que usted puede seguir cosechando los beneficios de la robustez, la capacidad de base de datos y la facilidad de uso del AS/ 400 mientras su imperio en línea continúa creciendo.