Computadoras Tandem

El primer sistema fue el Tandem/16 o T/16 , posteriormente renombrado como NonStop I. [ ^{6 ] La} máquina constaba de entre dos y dieciséis CPU, organizadas como un clúster de computadoras tolerante a fallos empaquetado en un único rack. Cada CPU tenía su propia memoria privada no compartida, su propio procesador de E/S , su propio bus de E/S privado para conectarse a los controladores de E/S y conexiones duales a todas las demás CPU a través de un bus de plano posterior entre CPU personalizado llamado Dynabus . Cada controlador de disco o controlador de red estaba duplicado y tenía conexiones duales tanto a las CPU como a los dispositivos. Cada disco estaba duplicado, con conexiones separadas a dos controladores de disco independientes. Si un disco fallaba, sus datos seguían estando disponibles desde su copia duplicada. Si una CPU, controlador o bus fallaba, el disco seguía siendo accesible a través de una CPU, controlador y/o bus alternativos. Cada controlador de disco o de red estaba conectado a dos CPU independientes. Cada fuente de alimentación estaba conectada a un solo lado de un par de CPU, controladores o buses, de modo que el sistema continuara funcionando sin perder conexiones si fallaba una fuente de alimentación. La cuidadosa y compleja disposición de las piezas y conexiones en las configuraciones más grandes de los clientes se documentó en un diagrama de Mackie , llamado así en honor al jefe de ventas David Mackie, quien inventó la notación. ^{[ 7 ]} Ninguna de estas piezas duplicadas eran "piezas de repuesto" desperdiciadas; todas contribuían al rendimiento del sistema durante las operaciones normales.

Además de recuperarse eficazmente de fallos en los componentes, el T/16 también se diseñó para detectar la mayor cantidad posible de fallos intermitentes, lo antes posible. Esta detección inmediata se denomina "fallo rápido". El objetivo era encontrar y aislar los datos corruptos antes de que se escribieran permanentemente en bases de datos y otros archivos de disco. En el T/16, la detección de errores se implementó mediante circuitos personalizados que apenas incrementaron el coste total del diseño; no se duplicaron componentes principales para lograr la detección de errores.

La CPU T/16 era un diseño propietario. Estuvo muy influenciada por la minicomputadora HP 3000. Ambas eran máquinas microprogramadas de 16 bits , basadas en pila , con direccionamiento virtual segmentado de 16 bits . Ambas estaban diseñadas para programarse exclusivamente en lenguajes de alto nivel, sin utilizar ensamblador . Ambas se implementaron inicialmente mediante chips TTL estándar de baja densidad , cada uno con una porción de 4 bits de la ALU de 16 bits . Ambas tenían un pequeño número de registros de datos de 16 bits en la parte superior de la pila, además de algunos registros de direcciones adicionales para acceder a la pila de memoria. Ambas utilizaban la codificación Huffman de los desplazamientos de direcciones de operandos, para ajustar una gran variedad de modos de direccionamiento y tamaños de desplazamiento al formato de instrucción de 16 bits con buena densidad de código. Ambas dependían en gran medida de grupos de direcciones indirectas para superar el formato de instrucción corto. Ambas admitían operandos más grandes de 32 y 64 bits mediante múltiples ciclos de la ALU y operaciones de cadena de memoria a memoria. Ambos sistemas utilizaban direccionamiento "big-endian" para operandos de memoria largos y cortos. Todas estas características se inspiraron en las máquinas de pila de los mainframes Burroughs B5500–B6800.

El conjunto de instrucciones T/16 modificó varias características del  diseño de la HP 3000. La T/16 admitió memoria virtual paginada desde el principio. La  serie HP 3000 no incorporó la paginación hasta la generación PA-RISC, 10 años después (aunque a través de MPE V ya contaba con una forma de paginación mediante el firmware APL, en 1978). Tandem añadió soporte para direccionamiento de 32 bits en su segunda máquina; la HP  3000 carecía de esta función hasta su generación PA-RISC. La paginación y las direcciones largas eran fundamentales para admitir software de sistema complejo y aplicaciones de gran tamaño. La T/16 gestionaba sus registros de la parte superior de la pila de una forma novedosa; el compilador, y no el microcódigo, era el responsable de decidir cuándo los registros llenos se volcaban a la pila de memoria y cuándo los registros vacíos se rellenaban desde la pila de memoria. En la HP  3000, esta decisión requería ciclos de microcódigo adicionales en cada instrucción. La HP  3000 admitía COBOL con varias instrucciones para calcular directamente sobre cadenas de dígitos BCD (decimal codificado en binario) de longitud arbitraria. La T/16 simplificó esto a instrucciones únicas para convertir entre cadenas BCD y enteros binarios de 64 bits.

En el T/16, cada CPU constaba de dos placas de lógica TTL y SRAM , y funcionaba a aproximadamente 0,7 MIPS . ^{[ 8 ]} En cualquier instante, solo podía acceder a cuatro segmentos de memoria virtual (Datos del sistema, Código del sistema, Datos de usuario, Código de usuario), cada uno limitado a 128  KB. Los espacios de direcciones de 16 bits ya eran pequeños para las aplicaciones principales cuando se lanzó.

La primera versión de T/16 solo incluía un lenguaje de programación: el Lenguaje de Aplicaciones de Transacciones (TAL). Este era un lenguaje de programación de sistemas eficiente y dependiente de la máquina (para sistemas operativos, compiladores, etc.), pero también podía utilizarse para aplicaciones no portátiles. Derivaba del  Lenguaje de Programación de Sistemas (SPL) de HP 3000. Ambos tenían una semántica similar a la de C , pero una sintaxis basada en ALGOL de Burroughs . Las versiones posteriores añadieron compatibilidad con Cobol74, Basic , Fortran , Java , C, C++ y MUMPS .

La serie Tandem NonStop utilizaba un sistema operativo personalizado que era significativamente diferente de Unix o  del MPE de HP 3000. Inicialmente se llamó T/TOS ( Tandem Transactional Operating System ), pero pronto se le cambió el nombre a Guardian por su capacidad para proteger todos los datos de fallos de la máquina y del software. A diferencia de todos los demás sistemas operativos comerciales, Guardian se basaba en el paso de mensajes como método básico para que todos los procesos interactuaran, sin memoria compartida, independientemente de dónde se ejecutaran los procesos. ^{[ 9 ] [ 10 ]} Este enfoque se adaptaba fácilmente a clústeres de múltiples computadoras y ayudaba a aislar los datos corruptos antes de que se propagaran.

Todos los procesos del sistema de archivos y los procesos de aplicaciones transaccionales se estructuraron como pares maestro/esclavo que se ejecutaban en CPUs separadas. El proceso esclavo tomaba instantáneas periódicas del estado de la memoria del maestro y asumía la carga de trabajo si el proceso maestro presentaba problemas. Esto permitía que la aplicación sobreviviera a fallos en cualquier CPU o sus dispositivos asociados, sin pérdida de datos. Además, permitía la recuperación ante fallos de software intermitentes. Entre fallos, la monitorización por parte del proceso esclavo añadía cierta sobrecarga de rendimiento, pero esta era mucho menor que la duplicación total de otros diseños de sistemas. Algunas de las primeras aplicaciones importantes se codificaron directamente con este estilo de puntos de control, pero la mayoría utilizaba diversas capas de software de Tandem que ocultaban los detalles de forma semiportátil.

En 1981, todas las CPU T/16 fueron reemplazadas por la NonStop II . Su principal diferencia con la T/16 era la compatibilidad con el direccionamiento ocasional de 32 bits mediante un "segmento de datos extendido" conmutable por el usuario. Esto permitió el crecimiento del software durante los siguientes diez años y representó una ventaja sobre la T/16 o la HP  3000. Los registros visibles seguían siendo de 16 bits, y esta adición no planificada al conjunto de instrucciones requería la ejecución de muchas instrucciones por referencia de memoria en comparación con la mayoría de las minicomputadoras de 32 bits. Todas las computadoras TNS posteriores se vieron afectadas por esta ineficiencia del conjunto de instrucciones. Dado que la NonStop II carecía de rutas de datos internas más amplias, tuvo que utilizar pasos de microcódigo adicionales para las direcciones de 32 bits. Una CPU NonStop II tenía tres placas, utilizando chips y un diseño similar al de la T/16. La NonStop II también reemplazó la memoria de núcleo con memoria DRAM con respaldo de batería.

En 1983, la CPU NonStop TXP fue la primera implementación completamente nueva de la arquitectura del conjunto de instrucciones TNS. ^{[ 11 ] [ 12 ] [ 13 ]} Se construyó a partir de chips TTL estándar y chips Programmed Array Logic, con cuatro placas por módulo de CPU. Fue la primera vez que Tandem utilizó memoria caché. Tenía una implementación más directa de direccionamiento de 32 bits, pero aún los enviaba a través de sumadores de 16 bits. Un almacenamiento de microcódigo más amplio permitió una reducción importante en los ciclos ejecutados por instrucción; la velocidad aumentó a 2,0 MIPS. Utilizó el mismo empaquetado en rack, controladores, placa base y buses que antes. Los buses Dynabus y de E/S se habían sobredimensionado en el T/16 para que funcionaran durante varias generaciones de actualizaciones.

Ahora se podían combinar hasta 14 sistemas TXP y NonStop II mediante FOX , un bus de fibra óptica tolerante a fallos de larga distancia para conectar clústeres TNS en todo un campus empresarial; un clúster de clústeres con un total de 224 CPU. Esto permitió una mayor escalabilidad para gestionar las aplicaciones de mainframe más grandes. ^{[ 14 ]} Al igual que los módulos de CPU dentro de las computadoras, el sistema operativo Guardian podía transferir conjuntos completos de tareas a otras máquinas en la red. También se podían construir clústeres mundiales de 4000 CPU mediante enlaces de red convencionales de larga distancia.

En 1986, Tandem presentó una CPU de tercera generación, la NonStop VLX . ^{[ 15 ]} Tenía rutas de datos de 32 bits, un microcódigo más amplio,  un tiempo de ciclo de 12 MHz y una tasa máxima de una instrucción por ciclo. Estaba construida a partir de tres placas de chips de matriz de puertas ECL (con asignación de pines TTL). Tenía un Dynabus revisado con una velocidad aumentada a 20  MB/s por enlace, 40  MB/s en total. Posteriormente, FOX II aumentó el diámetro físico de los clústeres TNS a 4 kilómetros.

El soporte inicial de Tandem para bases de datos era solo para bases de datos jerárquicas no relacionales a través del sistema de archivos ENSCRIBE . Esto se extendió a una base de datos relacional llamada ENCOMPASS . ^{[ 16 ]} En 1986, Tandem presentó la primera base de datos SQL tolerante a fallos , NonStop SQL . ^{[ 17 ]} Desarrollada completamente internamente, NonStop SQL incluye una serie de características basadas en Guardian para garantizar la validez de los datos en todos los nodos. NonStop SQL es conocida por escalar linealmente en rendimiento con el número de nodos agregados al sistema, mientras que la mayoría de las bases de datos tenían un rendimiento que se estancaba bastante rápido, a menudo después de solo dos CPU. Una versión posterior lanzada en 1989 agregó transacciones que podían distribuirse entre nodos, una característica que siguió siendo única durante algún tiempo. NonStop SQL continuó evolucionando, primero como NonStop SQL/MP y luego NonStop SQL/MX, que pasó de Tandem a Compaq y luego a HP. El código sigue utilizándose tanto en NonStop SQL/MP de HP, NonStop SQL/MX y el proyecto Apache Trafodion . ^{[ 18 ]}

En 1987, Tandem presentó el NonStop CLX , un sistema de minicomputadora de bajo costo y menos expandible. ^{[ 19 ] [ 20 ]} Su función era expandir el segmento de gama baja del mercado de tolerancia a fallas y desplegarse en los bordes remotos de grandes redes Tandem. Su rendimiento inicial era aproximadamente similar al del TXP; las versiones posteriores mejoraron hasta ser aproximadamente un 20% más lentas que un VLX. Su pequeño gabinete podía instalarse en cualquier entorno de oficina de "sala de fotocopiadoras". Una CPU CLX era una placa, que contenía seis chips ASIC CMOS de "silicio compilado" . El chip del núcleo de la CPU estaba duplicado y sincronizado para una detección máxima de errores. Esto no agregaba tolerancia a fallas adicional, pero aseguraba la integridad de los datos, ya que cada CPU incluía lógica de verificación que aseguraba que los resultados de ambos chips de CPU fueran idénticos. Otros procesadores proporcionarían tolerancia a fallas. La disposición de pines era una limitación principal de esta tecnología de chips. El microcódigo, la caché y la TLB eran externos al núcleo de la CPU y compartían un solo bus y un solo banco de SRAM . Como resultado, CLX requería al menos dos ciclos de máquina por instrucción.

En 1989, Tandem presentó el NonStop Cyclone , un sistema rápido pero costoso para el segmento de mercado de mainframes. ^{[ 21 ] [ 22 ]} Cada CPU de autocomprobación requería tres placas llenas de chips de matriz de puertas ECL de funcionamiento en caliente, además de placas de memoria. A pesar de estar microprogramada, la CPU era superescalar , completando a menudo dos instrucciones por ciclo de caché. Esto se lograba mediante una rutina de microcódigo separada para cada par de instrucciones comunes. ^{[ 23 ]} Ese par fusionado de instrucciones de pila generalmente realizaba el mismo trabajo que una sola instrucción de las minicomputadoras normales de 32 bits. Los procesadores Cyclone se empaquetaban como secciones de cuatro CPU cada una, y las secciones se unían mediante una versión de fibra óptica de Dynabus.

Al igual que las máquinas de alta gama anteriores de Tandem, los gabinetes Cyclone presentaban un diseño con líneas angulares en color negro para sugerir robustez y potencia. Los videos publicitarios comparaban directamente a Cyclone con el avión espía Lockheed SR-71 Blackbird Mach 3. Se suponía que el nombre Cyclone representaba su "velocidad imparable para procesar cargas de trabajo OLTP". El día del anuncio fue el 17 de octubre de 1989. Esa tarde, la región fue azotada por el terremoto de Loma Prieta de magnitud 6.9 , que provocó el derrumbe de autopistas en Oakland y grandes incendios en San Francisco . Las oficinas de Tandem se vieron afectadas, pero nadie resultó gravemente herido en el lugar.

Entre 1980 y 1983, Tandem intentó rediseñar por completo su pila de hardware y software para consolidar sus métodos NonStop sobre una base más sólida que la heredada de la HP  3000. El hardware de Rainbow era una máquina de registro de 32 bits que aspiraba a superar a la VAX de Digital Equipment Corporation . Para una programación fiable, el lenguaje de programación principal era TPL, un subconjunto de Ada . En aquel entonces, los programadores apenas sabían cómo compilar Ada a código no optimizado. No existía una ruta de migración para el software del sistema NonStop existente, codificado en TAL. El sistema operativo, la base de datos y los compiladores Cobol se rediseñaron por completo. Los clientes lo percibirían como una línea de productos totalmente independiente que requería software completamente nuevo. El desarrollo del software de este proyecto se prolongó mucho más de lo previsto. El hardware ya estaba obsoleto y el rendimiento de TXP era inferior al de este antes de que su software estuviera listo, lo que provocó el abandono del proyecto Rainbow. Todos los esfuerzos posteriores se centraron en la compatibilidad ascendente y en facilitar las rutas de migración.

El desarrollo del marco de desarrollo de aplicaciones cliente/servidor avanzado de Rainbow llamado "Crystal" continuó durante un tiempo más y se separó como el producto "Ellipse" de Cooperative Systems Incorporated. ^{[ 24 ]}

En 1985, Tandem intentó hacerse con una parte del creciente mercado de ordenadores personales con el lanzamiento de la estación de trabajo Dynamite, basada en MS-DOS . Numerosas limitaciones de diseño (incluida una plataforma de hardware única basada en el microcontrolador 8086, incompatible con las tarjetas de expansión de la época y con una compatibilidad extremadamente limitada con los ordenadores basados ​​en IBM ) relegaron a la Dynamite a funcionar principalmente como terminal inteligente. Fue retirada del mercado de forma discreta y rápida.

En 1986, la compañía presentó el 6AT, un ordenador compatible con IBM PC AT . Tandem solo vendió el 6AT a sus clientes habituales; «no vamos a salir a innovar», declaró. ^{[ 25 ]}

El sistema operativo NonStop de Tandem, basado en mensajes, ofrecía ventajas en cuanto a escalabilidad, fiabilidad extrema y uso eficiente de costosos recursos de reserva. Sin embargo, muchos clientes potenciales buscaban una fiabilidad aceptable en un sistema pequeño, utilizando un sistema operativo Unix familiar y programas estándar de la industria. Los diversos competidores de Tandem, que ofrecían tolerancia a fallos, adoptaron un diseño más sencillo, centrado en la memoria y basado únicamente en hardware, donde la recuperación se realizaba mediante la conmutación entre unidades de reserva en caliente. El competidor más exitoso fue Stratus Technologies , cuyas máquinas fueron comercializadas por IBM como "IBM System/88".

En estos sistemas, los procesadores de reserva no contribuyen al rendimiento del sistema entre fallos, sino que simplemente ejecutan de forma redundante el mismo hilo de datos que el procesador activo en el mismo instante, de manera sincronizada. Los fallos se detectan al observar cuándo divergen las salidas de los procesadores clonados. Para detectar fallos, el sistema debe contar con dos procesadores físicos por cada procesador lógico activo. Para implementar también la recuperación automática ante fallos, el sistema debe contar con tres o cuatro procesadores físicos por cada procesador lógico. El coste, que triplica o cuadruplica, de esta reserva resulta viable cuando las piezas duplicadas son microprocesadores de un solo chip estándar.

Los productos de Tandem para este mercado comenzaron con la línea Integrity en 1989, que utilizaba procesadores MIPS y una variante de Unix llamada "NonStop UX". Fue desarrollada en Austin, Texas. En 1991, el Integrity S2 utilizó TMR, Triple Modular Redundancy, donde cada CPU lógica utilizaba tres microprocesadores MIPS R2000 para ejecutar el mismo hilo de datos, con votación para encontrar y bloquear una parte defectuosa. Sus relojes rápidos no podían sincronizarse como en el bloqueo estricto, por lo que la votación se realizaba en cada interrupción. ^{[ 26 ]} Algunas otras versiones de Integrity utilizaron redundancia 4x "pares y repuestos". Pares de procesadores funcionaban en modo de bloqueo para comprobarse mutuamente. Cuando no coincidían, ambos procesadores se marcaban como no confiables y su carga de trabajo era asumida por un par de procesadores de reserva en caliente cuyo estado ya era actual. En 1995, el Integrity S4000 fue el primero en utilizar ServerNet (una estructura de "bus" en red) y avanzó hacia la compartición de periféricos con la línea NonStop.

Entre 1995 y 1997, Tandem se asoció con Microsoft para implementar funciones de alta disponibilidad y configuraciones SQL avanzadas en clústeres de máquinas Microsoft Windows NT estándar. Este proyecto recibió el nombre en clave "Wolfpack" y se lanzó inicialmente como Microsoft Cluster Server en 1997. ^{[ 27 ]} Microsoft se benefició enormemente de esta asociación; Tandem no.

En 1991, Tandem lanzó el Cyclone/R, también conocido como CLX/R. Este era un sistema de gama media de bajo costo basado en componentes CLX, pero utilizaba microprocesadores R3000 en lugar de la placa de máquina de pila CLX, mucho más lenta. Para minimizar el tiempo de comercialización, esta máquina se envió inicialmente sin ningún software en modo nativo MIPS. Todo, incluido su sistema operativo NonStop Kernel (NSK) (una continuación de Guardian) y la base de datos NonStop SQL, se compiló a código máquina de pila TNS. Ese código objeto se traducía luego a secuencias de instrucciones MIPS equivalentes parcialmente optimizadas durante la instalación del kernel mediante una herramienta llamada Accelerator. ^{[ 28 ]} Los programas menos importantes también podían ejecutarse directamente sin pretraducción, a través de un intérprete de código TNS . Estas técnicas de migración tuvieron éxito y siguen utilizándose hoy en día. El software del usuario final se migró sin trabajo adicional, el rendimiento era suficientemente bueno para máquinas de gama media y los programadores podían ignorar las diferencias de instrucciones, incluso al depurar a nivel de código máquina. En una versión posterior, estas máquinas Cyclone/R se actualizaron con un sistema operativo NSK en modo nativo más rápido.

Los microprocesadores R3000 y posteriores solo contaban con una cantidad típica de comprobación de errores interna, insuficiente para las necesidades de Tandem. Por lo tanto, el Cyclone/R ejecutaba pares de procesadores R3000 en sincronización, ejecutando el mismo hilo de datos. Esto se hacía para garantizar la integridad de los datos, no la tolerancia a fallos, ya que esta última se gestionaba mediante otros mecanismos ya implementados. Se utilizaba una variante de sincronización. El procesador de comprobación se ejecutaba un ciclo por detrás del procesador principal. Esto les permitía compartir una única copia de las cachés de código y datos externas sin sobrecargar el bus del sistema ni reducir la frecuencia del reloj. Para que los microprocesadores funcionen correctamente en sincronización, los chips deben diseñarse para ser completamente deterministas. Cualquier estado interno oculto debe borrarse mediante el mecanismo de reinicio del chip. De lo contrario, los chips emparejados pueden desincronizarse sin motivo aparente y sin fallos, incluso mucho después de reiniciarlos. Los diseñadores de chips coinciden en que estos son buenos principios, ya que les ayudan a probar los chips durante la fabricación. Sin embargo, todos los nuevos chips de microprocesador parecían tener fallos en este aspecto y requerían meses de trabajo conjunto entre MIPS (el fabricante externo utilizado por Tandem) y Tandem para eliminar o sortear los últimos fallos sutiles.

En 1993, Tandem lanzó la serie NonStop Himalaya K con el procesador MIPS R4400 más rápido , un sistema operativo NSK nativo y componentes del sistema Cyclone totalmente ampliables. Estos se conectaban mediante Dynabus, Dynabus+ y el bus de E/S original, que para entonces ya estaban agotando su capacidad de rendimiento.

En 1995, el núcleo NonStop se amplió con un entorno POSIX similar a Unix llamado Open System Services. ^{[ 29 ]} El shell Guardian original y la ABI siguieron estando disponibles.

En 1997, Tandem presentó la serie NonStop Himalaya S con una nueva arquitectura de sistema de alto nivel basada en conexiones ServerNet . ServerNet reemplazó a los buses Dynabus, FOX y de E/S. Era mucho más rápido, más general y podía extenderse a más que la redundancia bidireccional mediante una red arbitraria de conexiones punto a punto. Tandem diseñó ServerNet para sus propias necesidades, pero luego promovió su uso entre otros; evolucionó hasta convertirse en el estándar industrial InfiniBand .

Todas las máquinas de la serie S utilizaban procesadores MIPS, incluidos los modelos R4400, R10000 , R12000 y R14000 .

El diseño de los núcleos MIPS posteriores y más rápidos fue financiado principalmente por Silicon Graphics Inc. Sin embargo, la sexta generación del Pentium Pro de Intel superó el rendimiento de los diseños RISC , y además, el negocio de gráficos de SGI se redujo. Tras el R10000, no se invirtió en nuevos diseños significativos de núcleos MIPS para servidores de gama alta. Por lo tanto, Tandem tuvo que migrar su línea de productos NonStop a otra arquitectura de microprocesador con chips rápidos y competitivos.