La infraestructura paranoica
Una vez hecho un plan de negocios sensato, con la experiencia desastrosa de algunas .com en mente, cualquier iniciativa que quiera adentrarse en el comercio electrónico deberá montar su infraestructura tecnológica preparándose siempre para lo peor. Esta especie de paranoia es la única manera de estar en condiciones de que siempre suceda lo mejor.
Puede suceder que, en plena campaña de Navidad, el sitio Web de una compañía se venga abajo, dando al traste con sus planes de venta online anuales. Entonces vendrán las inevitables preguntas: ¿qué ha sucedido?, ¿se pudo evitar?, ¿volverán los clientes perdidos? En pleno puente del Día de Acción de Gracias de Estados Unidos, Amazon.com vivió una auténtica pesadilla. El popular y controvertido sitio se vino abajo durante 30 minutos el 24 de noviembre y otros 15 el día 30: la compañía se disculpó asegurando que había sufrido problemas con el software. Después del ataque masivo de denegación de servicio que Amazon había sufrido anteriormente, eso era justo lo que nunca debía haber pasado.
Y es que en el comercio electrónico hay que asegurarse que el servicio estará disponible las 24 horas de los siete días de la semana. El que un sitio esté inoperativo, aunque sólo sean pequeños momentos de vez en cuando, puede traducirse a largo plazo en pérdida de clientes, porque la gente recuerda sus experiencias negativas y tiende a evitarlas en otras ocasiones. Incluso un rendimiento lento ocasional supone un gran problema, porque se puede estar perdiendo clientes sin ni siquiera saberlo. Si no nos gusta la comida de un restaurante, no solemos quejarnos al chef; simplemente no regresamos jamás.
Pero, ¿cómo construir un sitio complejo de comercio electrónico que nunca falle? Se podría dar respuesta a esta pregunta con las opiniones de los responsables tecnológicos de algunos sitios españoles, pero, dada la mayor experiencia en estas lides de Estados Unidos, tomemos como referencia los casos de los seis sitios Web de éxito que nos ofrece nuestro servicio de información interno IDG News Service: AmericanGreetings.com, EOS Bank, Monster.com, Penn State University, United Parcel Service (UPS) y la World Wrestling Federation (WWF). Todos ellos coinciden en que la clave está en la redundancia de los sistemas centrales.
“Cualquier punto crítico de la infraestructura debería estar a salvo de fallos”, dice Bruce Petro, CIO de AmericanGreetings.com, uno de los 50 sitios más visitados, con más de 8,5 millones de visitantes únicos en octubre de 2000, según Media Metrix. El sitio sirve alrededor de 6 millones de páginas al día en periodos laborables y dobla ese volumen en tiempo de vacaciones. Y, aunque AmericanGreetings.com ha sufrido algunas crisis de crecimiento desde su lanzamiento en mayo de 1995, las caídas inesperadas han sido mínimas.
Para Petro, a salvo de fallos significa construir con redundancia los cortafuegos, los dispositivos de balanceo de cargas, los principales conmutadores de la red y las bases de datos. Si cualquiera de estos elementos cae, el tráfico automáticamente pasa al sistema de backup correspondiente. Además, otros sistemas, como los servidores, envían alertas cuando se acercan a cargas pico. “Contamos con 250 servidores Web y de aplicaciones, lo que mitiga el impacto que supone que uno de ellos falle”, asegura Petro.
El mejor método a seguir es realizar un análisis global de riesgos antes de decidir dónde hay que invertir en redundancia, sin olvidar nunca los sistemas de alimentación eléctrica.
CENTROS DE DATOS
Monster.com, UPS y WWF emplean múltiples centros de datos para tratar sus masivas cargas de tráfico: si uno se viene abajo, los otros entran en acción. El buscador de empleos dispone de dos centros de datos en costas separadas para tratar alrededor de 390 millones de páginas vistas por mes desde sus 15 sitios Web desplegados en todo el mundo, según Brian Farrey, CTO de Monster.com.
La compañía prefiere construir sus propios centros de datos “porque la mayoría de las instalaciones de collocation no podrían satisfacer las necesidades de espacio de Monster.com”. De hecho, utiliza 300 servidores Dell basados en Windows NT y un número indeterminado de routers y conmutadores de Cisco.
Las cargas de tráfico se balancean entre los dos sitios, en función de criterios geográficos. Cada uno utiliza múltiples fuentes de alimentación y líneas de ISP. Si una cae, otra puede tratar el tráfico global. La compañía, además, utiliza dispositivos de balanceo de cargas de Hydra Web Technologies, que chequea la disponibilidad del servidor antes de enviar los paquetes.
Junto a la distribución de cargas entre las dos instalaciones, las aplicaciones de Monster.com dependen de grupos de servidores en lo que Farrey llama “clustering funcional”. Por ejemplo, la aplicación de búsqueda de empleos está soportada por 50 servidores, 25 en cada centro. Si uno falla, los otros 24 se ocupan de su carga. Si un cluster entero cae, el tráfico pasa a su cluster “en espejo” situado en el otro centro de datos. Y si, en el peor de los casos, ambos clusters se vienen abajo, el resto de aplicaciones del sitio pueden permanecer activas.
CARGAS DE TRAFICO
La federación mundial de lucha libre WWF ofrece alrededor de nueve horas de programación de TV por semana. Si un anunciante menciona WWF.com durante una emisión, 100.000 usuarios podrían entrar en el sitio minutos después. En noviembre de 2000, la entidad tuvo 239 millones de páginas vistas a través de los muchos sitios Web que opera.
“Normalmente funcionamos con un nivel de uso de nuestra capacidad muy bajo, pero hay que estar preparados para soportar los picos”, dice Gerry Louw, CTO de WWF.com. El enfoque que está siguiendo para balancear las cargas entre sus cien servidores Web y de streaming media es similar al de Monster.com, aunque la red cubre una distancia física menor y usa un servicio de collocation. WWF corre sus operaciones Web desde dos instalaciones de Level 3 Communications en Nueva York. Además, planea abrir un tercer centro de datos en una instalación de Level 3 en la Costa Oeste a finales de año.
Los dos principales sitios WWF -wwf.com y wwfsuperstars.com- están divididos al 50% entre los centros de datos de Nueva York. Otros servidores situados en Virginia tratan, en régimen de outsourcing, 52 sitios Web más pequeños dedicados a pago por visión. Pero pronto se pasarán a la nueva instalación en la Costa Oeste.
En los racks de Level 3, WWF utiliza 60 servidores Compaq DL360 con Linux de Red Hat y software Squid Web Proxy Cache para ofrecer contenidos HTML. Seis servidores se dedican a streaming media, con otras 34 máquinas en standby preparadas para soportar cualquier incidencia. Para tratar el tráfico dirigido a los dos sitios principales, la entidad utiliza routers, conmutadores y dispositivos de balanceo de cargas. La regla de Louw es que las cargas pico nunca deberían superar el 60% de la capacidad. Si exceden ese umbral, entran en acción más servidores.
Aunque el sitio nunca se ha caído a causa de las cargas de tráfico, la compañía ocasionalmente se ve obligada a limitar el número de visitantes que acceden a alguno de los contenidos de streaming media para asegurar una visualización de alta calidad. El límite varía en función del volumen de
Puede suceder que, en plena campaña de Navidad, el sitio Web de una compañía se venga abajo, dando al traste con sus planes de venta online anuales. Entonces vendrán las inevitables preguntas: ¿qué ha sucedido?, ¿se pudo evitar?, ¿volverán los clientes perdidos? En pleno puente del Día de Acción de Gracias de Estados Unidos, Amazon.com vivió una auténtica pesadilla. El popular y controvertido sitio se vino abajo durante 30 minutos el 24 de noviembre y otros 15 el día 30: la compañía se disculpó asegurando que había sufrido problemas con el software. Después del ataque masivo de denegación de servicio que Amazon había sufrido anteriormente, eso era justo lo que nunca debía haber pasado.
Y es que en el comercio electrónico hay que asegurarse que el servicio estará disponible las 24 horas de los siete días de la semana. El que un sitio esté inoperativo, aunque sólo sean pequeños momentos de vez en cuando, puede traducirse a largo plazo en pérdida de clientes, porque la gente recuerda sus experiencias negativas y tiende a evitarlas en otras ocasiones. Incluso un rendimiento lento ocasional supone un gran problema, porque se puede estar perdiendo clientes sin ni siquiera saberlo. Si no nos gusta la comida de un restaurante, no solemos quejarnos al chef; simplemente no regresamos jamás.
Pero, ¿cómo construir un sitio complejo de comercio electrónico que nunca falle? Se podría dar respuesta a esta pregunta con las opiniones de los responsables tecnológicos de algunos sitios españoles, pero, dada la mayor experiencia en estas lides de Estados Unidos, tomemos como referencia los casos de los seis sitios Web de éxito que nos ofrece nuestro servicio de información interno IDG News Service: AmericanGreetings.com, EOS Bank, Monster.com, Penn State University, United Parcel Service (UPS) y la World Wrestling Federation (WWF). Todos ellos coinciden en que la clave está en la redundancia de los sistemas centrales.
“Cualquier punto crítico de la infraestructura debería estar a salvo de fallos”, dice Bruce Petro, CIO de AmericanGreetings.com, uno de los 50 sitios más visitados, con más de 8,5 millones de visitantes únicos en octubre de 2000, según Media Metrix. El sitio sirve alrededor de 6 millones de páginas al día en periodos laborables y dobla ese volumen en tiempo de vacaciones. Y, aunque AmericanGreetings.com ha sufrido algunas crisis de crecimiento desde su lanzamiento en mayo de 1995, las caídas inesperadas han sido mínimas.
Para Petro, a salvo de fallos significa construir con redundancia los cortafuegos, los dispositivos de balanceo de cargas, los principales conmutadores de la red y las bases de datos. Si cualquiera de estos elementos cae, el tráfico automáticamente pasa al sistema de backup correspondiente. Además, otros sistemas, como los servidores, envían alertas cuando se acercan a cargas pico. “Contamos con 250 servidores Web y de aplicaciones, lo que mitiga el impacto que supone que uno de ellos falle”, asegura Petro.
El mejor método a seguir es realizar un análisis global de riesgos antes de decidir dónde hay que invertir en redundancia, sin olvidar nunca los sistemas de alimentación eléctrica.
CENTROS DE DATOS
Monster.com, UPS y WWF emplean múltiples centros de datos para tratar sus masivas cargas de tráfico: si uno se viene abajo, los otros entran en acción. El buscador de empleos dispone de dos centros de datos en costas separadas para tratar alrededor de 390 millones de páginas vistas por mes desde sus 15 sitios Web desplegados en todo el mundo, según Brian Farrey, CTO de Monster.com.
La compañía prefiere construir sus propios centros de datos “porque la mayoría de las instalaciones de collocation no podrían satisfacer las necesidades de espacio de Monster.com”. De hecho, utiliza 300 servidores Dell basados en Windows NT y un número indeterminado de routers y conmutadores de Cisco.
Las cargas de tráfico se balancean entre los dos sitios, en función de criterios geográficos. Cada uno utiliza múltiples fuentes de alimentación y líneas de ISP. Si una cae, otra puede tratar el tráfico global. La compañía, además, utiliza dispositivos de balanceo de cargas de Hydra Web Technologies, que chequea la disponibilidad del servidor antes de enviar los paquetes.
Junto a la distribución de cargas entre las dos instalaciones, las aplicaciones de Monster.com dependen de grupos de servidores en lo que Farrey llama “clustering funcional”. Por ejemplo, la aplicación de búsqueda de empleos está soportada por 50 servidores, 25 en cada centro. Si uno falla, los otros 24 se ocupan de su carga. Si un cluster entero cae, el tráfico pasa a su cluster “en espejo” situado en el otro centro de datos. Y si, en el peor de los casos, ambos clusters se vienen abajo, el resto de aplicaciones del sitio pueden permanecer activas.
CARGAS DE TRAFICO
La federación mundial de lucha libre WWF ofrece alrededor de nueve horas de programación de TV por semana. Si un anunciante menciona WWF.com durante una emisión, 100.000 usuarios podrían entrar en el sitio minutos después. En noviembre de 2000, la entidad tuvo 239 millones de páginas vistas a través de los muchos sitios Web que opera.
“Normalmente funcionamos con un nivel de uso de nuestra capacidad muy bajo, pero hay que estar preparados para soportar los picos”, dice Gerry Louw, CTO de WWF.com. El enfoque que está siguiendo para balancear las cargas entre sus cien servidores Web y de streaming media es similar al de Monster.com, aunque la red cubre una distancia física menor y usa un servicio de collocation. WWF corre sus operaciones Web desde dos instalaciones de Level 3 Communications en Nueva York. Además, planea abrir un tercer centro de datos en una instalación de Level 3 en la Costa Oeste a finales de año.
Los dos principales sitios WWF -wwf.com y wwfsuperstars.com- están divididos al 50% entre los centros de datos de Nueva York. Otros servidores situados en Virginia tratan, en régimen de outsourcing, 52 sitios Web más pequeños dedicados a pago por visión. Pero pronto se pasarán a la nueva instalación en la Costa Oeste.
En los racks de Level 3, WWF utiliza 60 servidores Compaq DL360 con Linux de Red Hat y software Squid Web Proxy Cache para ofrecer contenidos HTML. Seis servidores se dedican a streaming media, con otras 34 máquinas en standby preparadas para soportar cualquier incidencia. Para tratar el tráfico dirigido a los dos sitios principales, la entidad utiliza routers, conmutadores y dispositivos de balanceo de cargas. La regla de Louw es que las cargas pico nunca deberían superar el 60% de la capacidad. Si exceden ese umbral, entran en acción más servidores.
Aunque el sitio nunca se ha caído a causa de las cargas de tráfico, la compañía ocasionalmente se ve obligada a limitar el número de visitantes que acceden a alguno de los contenidos de streaming media para asegurar una visualización de alta calidad. El límite varía en función del volumen de
