REDES
& TELECOM
WAP: ¿Éxito o Fracaso?

“Las Empresas se Están Orientando
en la Tecnología
Inalámbrica Wi-Fi, Frente a Bluetooth”: 3Com

Modernizan Red
Para Eficientar la
Administración de
Justicia

SOLUCIONES
& SERVICIOS
Tivoli Storage Manager 5.1 Protege y Recupera la Información

OPINION
Hacia una Nueva Teoría de la Empresa

La Industria de TI Recibe un Golpe en la Quijada

MERCADO
& INDUSTRIA
Mostró Altas y Bajas el Mercado PC en AL

Aumentarán 15% Ingresos de los Servicios CRM en 2002

Irrumpe Microsoft en el Mercado de Soluciones CRM

DESARROLLO
EJECUTIVO
Buscan Salarios Óptimos
en TI

El Futuro de los CIOs

SEGURIDAD
Ofrece IBM más
Seguridad en
Transacciones por
Internet

Plan Para lo Peor,
Esperanza Para lo Mejor

Se puede construir un sitio de comercio electrónico que nunca falle. He aquí cómo lo han hecho otros.

En el día de mejores compras del año, su sitio Web -el alma de la compañía- desciende. ÀCómo sucedió? ÀRegresarán los clientes?

El fin de semana del pasado Día de Gracias, Amazon.com vivió esta pesadilla. El popular sitio electrónico minorista estuvo suspendido durante 30 minutos en noviembre 24 y durante otros 15 minutos en noviembre 30; la compañía mencionó problemas de software. Aún resentido desde los ataques masivos de negación de servicio el pasado febrero, Amazon.com no necesitó otro moretón en el servicio.

Ninguna compañía de comercio electrónico global que trabaja 24 horas al día y siete días a la semana lo hace. Un sitio aletargado podría significar pérdida de clientes a largo plazo debido a que "la gente recuerda sus experiencias negativas", dice Alberto Savoia, jefe de tecnología de KeyReadiness Services en Keynote Systems, una firma de revisión y pruebas Web en San Mateo, California.

Hasta la lenta ejecución ocasional es una amenaza. "Si un sitio Web es lento, un fabricante podría estar perdiendo clientes y sin siquiera saberlo", dice Savoia, quien compara la experiencia con no quejarse con el chef después de una mala comida, sino con nunca regresar al restaurante.

De manera que Àcómo se construye un complejo sitio de comercio electrónico que nunca falla? Los ejecutivos de Tecnología de la Información que dirigen sitios Web exitosos para AmericanGreetings.com, EOS Bank, Monster.com, la Universidad Penn State, United Parcel Service y la Federation Mundial de Lucha (WWF) dicen que la redundancia en los sistemas medulares es el arma secreta.

"La infraestructura debería ser `a prueba de fallos' en cualquier punto crítico", enfatiza Bruce Petro, CIO de AmericanGreetings.com en Cleveland.

AmericanGreetings.com es uno de los 50 sitios más visitados de Internet, con más de 8.5 millones de visitantes únicos en Octubre de 2000, según Media Metrix, compañía de medición de tráfico Web. Petro dice que el sitio da servicio a cerca de seis millones de páginas diarias durante semanas sin días de fiesta y el doble de esa cantidad durante un periodo de fiestas.

AmericanGreetings.com ha tenido pocos dolores de cabeza desde su lanzamiento en Mayo de 1995, dice Petro, pero el tiempo inactivo no programado ha sido mínimo. Para Petro, prueba de fallos significa construir en redundancia en el muro de protección, dispositivos de balance de carga, interruptores principales de red y su base de datos. Si cualquiera de éstos fallan, el tráfico automáticamente es transbordado a un respaldo. Otros sistemas, como los servidores, envían alertas cuando se aproximan a cargas pico.

"Tenemos 250 servidores de aplicaciones y Web, lo que mitiga el impacto de que cualquiera resulte perdido", dice Petro.

Robert O'Connor, supervisor de investigación y desarrollo de arquitectura de redes en Penn State, dice que un análisis comprensivo de riesgo "le ayudará a decidir en dónde se debe gastar dinero en redundancia".

Por ejemplo, Penn State utiliza dos fuentes internas de energía, pero solamente una de energía ininterrumpible para cada servidor. El admite que la opción da a Penn State un posible punto de falla, pero agrega que esos dispositivos son confiables.

Uno o dos Centros de Información
Monster.com, UPS y la WWF emplean centros de información múltiples para manejar sus cargas de tráfico masivo. Si uno se cae, el otro se hace cargo. El buscador de empleos, Monster.com posee dos centros de información en costas separadas para manejar los aproximadamente 390 millones de páginas que obtiene por mes a través de los 15 sitios Web que opera alrededor del mundo, dice Brian Farrey, CTO de Monster.com.

Monster.com creó sus propios centros de datos debido a que la mayoría de las facilidades de colocación no cubrían la necesidad de espacio de la compañía. Ésta utiliza 300 servidores Dell basados en Windows NT y un sinnúmero de interruptores y enrutadores Cisco. "Somos muy grandes para las facilidades de colocación. Los hacemos huir con nuestro tamaño", dice Farrey.

Las cargas de tráfico son balanceadas entre los dos sitios, basados en Geografía. Cada uno recibe servicio de múltiples troncos ISP y suministradores de energía. Si uno se cae, el otro puede manejar el tráfico global por sí mismo, comenta Farrey. Actualmente, la compañía utiliza dispositivos de balanceo de carga de HydraWeb Technologies que supervisan la disponibilidad del servidor antes de enviar paquetes de información, agrega Farrey.

Además de distribuir la carga entre las dos instalaciones, Monster.com acomoda sus aplicaciones en grupos en el servidor en lo que Farrey llama "agrupamiento funcional". Por ejemplo, la solicitud de búsqueda de empleo se propaga en 50 servidores, 25 en cada centro de información. Si uno falla, los otros 24 en el centro de información llevan su carga. Si un cluster completo falla, el tráfico se va al cluster réplica en el otro centro de información. Si ambos clusters fallan, las otras aplicaciones del sitio permanecerán activas, comenta.

Lucha con Cargas de Tráfico
El WWF saca aproximadamente nueve horas de programación televisiva por semana. Si un anunciante menciona WWF.com durante una transmisión, 1000 mil usuarios pueden visitar el sitio minutos más tarde. En Noviembre del 2000, la compañía tuvo 239 millones de páginas visitadas a través de los muchos sitios Web que opera.

"Estamos funcionando con un muy bajo porcentaje de capacidad, pero tenemos que estar preparados para los picos", dice Gerry Louw, CTO de WWF. El método de Louw para balancear la carga a través de sus 100 servidores Web y multimedia es similar al de Farrey, aunque la red abarca menos distancia física y utiliza un servicio de colocación. WWF corre su operación Web en dos instalaciones de Level 3 Communications en Nueva York. La WWF planea colocar un tercer centro de datos en una facilidad Level 3 de la Costa Oeste más adelante este año, dice Louw.

Los dos principales sitios WWF -wwf.com y wwfsuperstars.com- están divididos 50-50 entre los centros de información de Nueva York. Muchos servidores en Virginia (de un anterior negocio de fuente externa) manejan 52 sitios Web más pequeños para eventos pago-por-evento individuales y estrellas individuales. Esos serán cambiados a la nueva facilidad de la Costa Oeste.

Dentro de los anaqueles de nivel 3, la WWF utiliza 60 servidores Compaq DL360 que corren con software Red Hat Linux y Squid Web Proxy Cache para proporcionar contenido HTML. Los seis servidores proporcionan clips de multimedia con otras 34 máquinas en modo de espera para eventos en vivo. La compañía utiliza enrutadores Cisco, interruptores y dispositivos de balanceo de carga para administrar el tráfico entrante a los dos sitios principales.

La experiencia de Louw es que la carga pico nunca debe ser más que el 60% de la capacidad. Si la carga excede ese umbral, se habilitan más servidores. Él mide la capacidad de ejecución por medio de guiones personalizados desde la información básica que proporciona Level 3.

Mientras que el sitio nunca se ha caído debido a cargas de tráfico, la compañía ocasionalmente tiene que limitar el número de gente que entra a algunos de los contenidos multimedia para asegurar las experiencias de visión de alta calidad. El tope varía dependiendo de la cantidad de banda ancha consumida por el número total de usuarios.

Proporcionando Contenido Web
En UPS, las visitas diarias son de un estimado de 100 millones durante los días de fiesta. De Noviembre 15 a Enero 15, el equipo de fiabilidad de Internet de la compañía se reúne diariamente para revisar los asuntos de funcionamiento. Durante dichas reuniones, el equipo cubre temas de problemas específicos, como el de una reducción de actividad de 5 minutos en la Costa Oeste, dice John Nallin, vicepresidente de Sistemas de Información en UPS. "En algunos casos, el problema se resuelve antes de que sepamos de él".

UPS da soporte a operaciones Web en todo el mundo con dos centros de información casi idénticos en Nueva Jersey y Georgia. Su meta es utilizar la capacidad en cada ubicación en alrededor de 40%, de manera que si un sitio falla el otro pueda manejar el desbordamiento, dice Nallin. El factoraje en la capacidad de comunicaciones del centro de información es el truco.

"Solía suceder que uno compraba una caja para obtener un poco de capacidad extra, pero ahora se tienen que comprar dos cajas para cada centro de información y una caja para hablar con ambos centros de información", agrega.

La compañía utiliza un esquema virtual Domain Name System para dirigir el tráfico entre los centros de información.

El balanceo de carga se maneja en el ISP y de nuevo ante el muro de protección. Los servidores Web corren principalmente en máquinas Sun Solaris, pero también en unos cuantos servidores NT. Las aplicaciones como rastreo de paquetes y captura de firmas corren en servidores IBM AS/400 y 15 mainframes IBM 3090 en dos ubicaciones. "Con 100 terabytes de información, no se pueden correr en pequeñas cajas Unix", dice Nallin.

Con un cambio diario, UPS opera un centro de información desde el otro para prácticas. De esta manera, si una tormenta de nieve en Nueva Jersey mantiene a los trabajadores en casa, cualquier problema en ese centro de información puede ser manejado por los ingenieros en Georgia, por ejemplo, dice Nallin.

Manteniéndose Delante de la Capacidad
Para medir la capacidad y supervisar el rendimiento, UPS utiliza una combinación de reportes, de Keynote Systems y datos desde una aplicación integrada y personalizada que rastrea la ejecución de la aplicación y del servidor proxy.

"Tradicionalmente vemos un crecimiento en las actividades de cerca del 100% por año", dice Nallin. "Lo vemos de manera creciente de trimestre a trimestre y de semestre en semestre. Siempre tenemos equipos de fases y aprovisionamientos entrando durante el año".

EOS Bank, un banco que funciona únicamente en línea, planea tener una capacidad basada en proyecciones de crecimiento de negocio. El banco trabaja para triplicar sus clientes, que se espera lleguen a 300 mil dentro de los próximos tres años. "No careceremos de capacidad antes de que podamos agregar más", dice Roy Henderson, presidente y CEO.

La fuente externa fue lo más económico para EOS. Aloja sus servidores de extremo posterior en facilidades de Exodus Communications en El Segundo, California. Las aplicaciones de servidor Web son operadas por Home Accounts, empresa derivada de la procesadora de tarjetas de crédito FDR. Sus servidores están conectados por medio de múltiples líneas T-1 para prevenir cualquier punto de fallo.

Pero los mejores planes aún pueden dar problemas como resultado. Cuando Penn State puso su sistema de control de grados en línea hace cerca de tres años, tenía un software de fábrica de balanceo de carga para ecualizar el tráfico a través de servidores múltiples. El código personalizado funcionó pobremente, y los servidores comenzaron a bloquearse. "Teníamos a dos estudiantes sentados enfrente de los servidores para reiniciarlos en caso de que se cayeran", dice O'Connor.

Inútil decirlo, Penn State se deshizo de la aplicación de tercera parte. Ahora utiliza Enterprise Network Dispatcher de IBM.

Planeando el Rendimiento
Muchos cuellos de botella pueden atribuirse a malas configuraciones de sistema entre productos de diferentes fabricantes. Savoia de Keynote dice que una compañía podría gastar 10 millones de dólares en un sistema que actúa como una Pentium de 500-MHz conectada a la Internet vía un modem de 28.8K bit/seg. La solución podría ser tan simple como hacer un cambio de configuración en un enrutador Cisco y regresar a toda la potencia", dice.

Para Monster.com, esto significa probar las aplicaciones con el software de pruebas de regresión SilkTest de Segue Software antes de activar cualquier cosa. "Nos gusta hacer una prueba de humo básica antes de empezar a usar una aplicación en la producción", dice Farrey. "Esto ayuda a obtener un sentimiento certero de que la aplicación puede manejar el tráfico".

No obstante, pruebe tanto como pueda, no se pueden controlar todos los problemas relacionados con la carga. "No se tiene control sobre todos los componentes que controlan sus niveles de servicio", dice Nallin de UPS. "AT&T y UUNET podrían estar teniendo problemas, pero para el usuario final será como para usted. No hay control sobre eso".

Pero si usted ha trabajado para tener mucha capacidad y tiene redundancia en las coyunturas críticas, entonces usted ha hecho más que simplemente esperar lo mejor.

Contacte al Editor de Multimedia Jason Meserve en "mailto:jmeserve@nww.com".