Una unidad central (en inglés mainframe ) es una computadora grande, potente y costosa, usada principalmente por una gran compañía para el procesamiento de una gran cantidad de datos, como por ejemplo, para el procesamiento de transacciones bancarias. Wikipedia
Antes de empezar hay que deshacer un mito: los mainframes ya no son dinasaurios con tecnologías obsoletas, cintas dando vueltas y tarjetas perforadas. Eso es falso. Los sistemas mainframes modernos también ejecutan bajo Linux, y soportan sistemas relacionales como Oracle y lenguajes modernos.
Lo que diferencia un mainframe es el hardware: son enormes bestias de procesamiento y unos monstruos en su capacidad de entrada/salida. Y no son baratos ni flexibles.
Puede que algunos se pregunten por qué los bancos no cambian estos sistemas por componentes mucho más baratos, lo que viene a ser un sistema de computación distribuida donde está claro que podemos escalar de forma mucho más económica e incluso podemos ser elásticos y reducir potencia si no necesitamos tanto hierro en determinado momento.
A mi, tras empezar a conocer un poco mejor el tema de arquitecturas distribuidas me ha venido una razón muy clara, pero no he encontrado este mismo razonamiento en otro sitio; cuando te venden las ventajas de estos sistemas te hablan del TCO, del ahorro,… no te hablan de esto.
La Conjetura de Brewer
En 2000 Eric Brewer enunció una Conjetura que sostenía que cuando lo que tienes es un sistema distribuido es imposible garantizar de forma simultanea la consistencia de la información, la disponibilidad del sistema completo y el particionado (esto es, la tolerancia a seguir operando en caso de fallo de algún nodo).
En un sistema distribuido, por definición, tenemos partición ya que es el concepto mismo de sistema distribuido.
Por tanto debe elegirse si quieres tener consistencia de información (todos los nodos ven la misma información en el mismo orden en cualquier momento) o quieres asegurar disponibilidad del sistema (algún nodo puede tener información distinta y ya los pondremos de acuerdo, esto es consistencia eventual, pero el sistema siempre responde).
El Teorema CAP
La Conjetura de Brewer pasó a ser un teorema demostrado matemáticamente en 2002 (Nancy Lynch and Seth Gilbert, “Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services”).
Sí, hay una demostración matemática. Osea que siempre que estés usando un sistema de computación distribuida, o elijes consistencia, o elijes disponibilidad.
En un sitio web como Amazon probablemente prefieran disponibilidad: si un producto no tiene stock porque el nodo tenía información no actualizada en ese momento, ya lo solucionarán, pero nada de una pantalla de indisponibilidad. Aquí queremos vender mucho.
Quizás un sistema de información de otro tipo prefiere consistencia. Si no estamos seguros de tener información correcta esperamos a que los nodos se puedan encontrar en el mismo estado, y puedo permitirme esa espera en que la información esté consistente.
Entonces ¿qué pasa con los bancos?
Pues ocurre que los bancos no pueden renunciar a la consistencia ni a la disponibilidad. No podemos anotar operaciones más que en un orden y en un sólo sitio debe tenerse la información. La operación debe garantizar la consistencia fuerte (strong consistency: All accesses are seen by all parallel processes in the same order — sequentially)
Tampoco podemos dejar de dar servicio 24x7 porque un nodo se haya caído o tenga un tiempo de espera por el que, el resto, deba dejar de atender hasta encontrar un estado consistente (en sistemas distribuidos se puede garantizar la consistencia fuerte si esperamos a que los nodos se trasladen un ACK de haberse puesto en la misma versión de la información, pero nosotros no podemos esperar)
Osea que esto, según el teorema CAP es imposible,… en sistemas distribuidos.
La única solución es no tener sistemas distribuidos.
En una empresa normal diríamos que tenemos una base de datos centralizando la información, lo de toda la vida, pero es que en un banco no hablamos de un sistema normal, es que estamos hablando de un sistema de gestión de información de enorme capacidad de procesamiento y entrada/salida. Esto es lo que ofrece un sistema mainframe, los big-iron: una locura de procesamiento y una disponibilidad casi completa en un nodo centralizado que asegura consistencia fuerte (strong consistency).
El nodo debe ser capaz de soportar un enorme número de transacciones, enorme (sí, esas compras navideñas o del Black Friday, todas anotándose en el mainframe) y debe tener una disponibilidad absoluta (ni caerse, ni perder datos).
Por eso las arquitecturas de los mainframes escalan de forma vertical, con sistemas de procesamiento de E/S que nada tienen que ver con los ordenadores normales (las tarjetas de E/S tienen CPUs dedicadas).
Top comments (1)
Ahora todo tiene sentido. Y ahora también conozco un poco más sobre lo complicado que son los sistemas distribuidos. Hueso duro de roer :)