Oswald Regular
OpenSans Regular
Crear una ratonera mejor
Un dispositivo antierupción de software, ¡al menos uno que funciona!

¿Quién había oído hablar de los “dispositivos antierupción” antes de 2010? Tras el derrame de petróleo en el golfo de México, se sucedieron las informaciones acerca de cómo los dispositivos antierupción son el medio que garantiza una recuperación del petróleo limpia y segura (gracias a la cual se evita la posibilidad de un desastre ecológico). El dispositivo antierupción es una máquina de varias toneladas de peso, que se coloca sobre un pozo en el fondo del océano. Cuando todo funciona como es debido, el dispositivo antierupción permite que el petróleo fluya de forma continua desde el pozo hasta la tubería de recuperación. Cuando algo no funciona, se prevé que el dispositivo active unos enormes cilindros hidráulicos que bloquean la tubería de dos pies de diámetro y la parten en dos. Obviamente, la activación del dispositivo antierupción es un suceso extraordinario. Cuando falla, los efectos pueden ser devastadores.

Por suerte, los desastres durante la perforación de pozos de petróleo son muy poco frecuentes. Todo lo contrario de lo que sucede con los fallos en los sistemas de procesamiento de datos empresariales, que son comunes. Los escenarios son diversos: el suministro energético se interrumpe y el sistema de reserva no se activa; los equipos se cierran de manera inesperada aunque sean redundantes; las unidades de disco fallan aunque se encuentren en matrices RAID; alguien pulsa el botón incorrecto aunque haya sido capacitado para no hacerlo; datos no válidos se infiltran en un sistema y lo colapsan; las bases de datos se bloquean y dejan de cargar datos; las redes se congestionan y las transacciones se abandonan… Si tenemos suerte, cuando estos sistemas se estropean, la actividad se interrumpe. Pero si no la tenemos, como sucedió con el desastre del pozo de petróleo del golfo de México, se derraman datos desde las canalizaciones de datos y se crea un lío formidable. En tal situación, el personal de operaciones tiene que apagar los sistemas e intentar recuperar los datos que puedan. Con un riesgo extra: el reinicio de operaciones puede ser peligroso, puesto que puede propiciar otra erupción, más datos perdidos y un lío aún mayor.

A los desarrolladores de software no les gusta la palabra “erupción” porque el solo mencionarla siembra el miedo entre los usuarios. Pero, al fin y al cabo, en eso consiste un fallo. Tras una erupción, los datos se esparcen a diestro y siniestro, lo que puede generar que algunas piezas del sistema queden inservibles o deshabilitadas.

Los ingenieros de software llevan décadas enfrentándose a este problema. Ocurre que la creación de sistemas a prueba de fallos es extremadamente difícil, porque cada uno es diferente. Además, los “dispositivos antierupciones de software” están diseñados de forma personalizada (a menudo, por personas que no los comprenden). Los costos asociados a su creación son altos, por lo que los ingenieros de software tienden a tomar atajos. (¿Cuántas veces ha escuchado, “¡No es posible que no funcione!”?). Como no se entiende por qué se producen los fallos, estos sistemas se suelen comprobar de una forma arriesgada. Y lo que es peor, un alto grado de su robustez está directamente en conflicto, por lo general, con otras necesidades para el sistema de procesamiento de datos. Como por ejemplo, con el alto rendimiento. (Se puede tener uno u otro, pero no ambos al mismo tiempo). Como no se puede demostrar que un sistema sea robusto, pero en cambio los objetivos del negocio, como el rendimiento, se pueden medir con facilidad, la robustez se suele posponer hasta más adelante.

UN NUEVO ENFOQUE

Ab Initio se dio cuenta, haciendo de ello un principio central, de que la única forma de impedir estas erupciones de procesamiento de datos consistía en tomar un enfoque diferente y exhaustivo. Los ingenieros de Ab Initio se comprometieron a no desarrollar ningún software hasta que hubieran aprendido a incorporar en el diseño mecanismos que –desde el principio– fueran robustos y fáciles de utilizar, sin perjudicar por ello al rendimiento. Este enfoque es integral al software de Ab Initio. El objetivo es garantizar que los usuarios se puedan centrar en los requisitos del negocio, con la confianza de que no se producirán erupciones que deshabiliten sus sistemas.

¿Cómo funciona lo anterior? En primer lugar, imagine una aplicación de Ab Initio como una serie de pasos de procesamiento conectados mediante canalizaciones que transportan datos. Los datos fluyen a través de estas canalizaciones a altas velocidades, desde un paso al siguiente. A veces, un paso contará con varias canalizaciones entrantes y/o varias canalizaciones salientes. Estas canalizaciones, en última instancia, se conectan a unidades de almacenamiento de datos o a otros sistemas de procesamiento que aceptan o generan secuencias de datos. Estos sistemas interconectados de pasos de procesamiento y canalizaciones de datos, pueden ser extremadamente grandes. Mucho mayores y más complejos, que el mapa del metro de Nueva York.

El mecanismo de puntos de verificación de Ab Initio consta de válvulas entrelazadas dentro de estas canalizaciones de datos. En general, hay un conjunto de válvulas en las entradas y en las salidas del sistema general de procesamiento. Es posible que también existan válvulas en puntos estratégicos del sistema de procesamiento. Además, es posible que haya reservas de datos en las válvulas (puntos de verificación) para capturar una copia de los datos antes de que pasen a la siguiente sección del sistema. Aunque algunas de estas válvulas (puntos de verificación) pueden ser especificadas por los usuarios, otras las coloca el software de Ab Initio de forma automática. La mayoría de estas válvulas están implementadas en el software de Ab Initio, aunque algunas se encuentran en otras tecnologías de software, como las bases de datos y las colas de mensajes. La clave es que todas estas válvulas están conectadas a un controlador central, el Co>Operating System de Ab Initio, que las abre y las cierra de una forma cuidadosamente sincronizada.

El Co>Operating System está diseñado para un procesamiento en paralelo y distribuido de alto rendimiento; además de para ser increíblemente robusto en caso de fallos. Por tanto, aunque haya grandes cantidades de datos fluyendo a través de sus canalizaciones a alta velocidad (sobre las redes y a través de servidores, y conectados a todas las clases de sistemas externos), es preciso poner especial cuidado para evitar que se produzcan erupciones.

CUANDO SUCEDE LO PEOR

Como el Co>Operating System ha estado abriendo y cerrando las válvulas con mucho cuidado, si se produce una erupción, la pérdida se limita a los datos que fluyen entre válvulas. Y como el Co>Operating System conserva una copia en sus reservas de todos los datos que podrían estar en peligro (además de saber exactamente cuántos datos han entrado y han salido del sistema), nunca se pierde ningún dato. Tan pronto como se haya solucionado la causa del fallo, el Co>Operating System se puede reiniciar. Automáticamente reanudará las aplicaciones en los lugares correctos. El Co>Operating System rellenará las canalizaciones de datos con los datos correctos desde las reservas y todo quedará como si el fallo no se hubiera producido nunca. Y eso es lo que quiere escuchar cualquier cliente. Aunque las erupciones son inevitables, se puede minimizar los daños y evitar la pérdida de datos, con lo que el bombeo de datos se reanuda tan pronto como se arreglen las canalizaciones. No se puede pedir más.

P.D.: Se han omitido muchos detalles de la descripción de los puntos de verificación. No se han explicado las confirmaciones en dos fases, los desencadenadores de puntos de verificación, los blips de mensajes, los administradores de transacciones y el protocolo XA. Ab Initio trabaja para que el usuario no tenga que preocuparse por los detalles. Lo importante es que la tecnología funcione.

English
Français
Idioma:
Español
Deutsch
简体中文
日本語