Por @Alvy — 1 de Octubre de 2023

CERN: Navegando por el Centro de Computación en Fotos.

Los otrora despejados armarios del centro de datos del CERN (Centro Europeo para la Investigación Nuclear) en Suiza han ido llenándose poco a poco durante los últimos años y ya han alcanzado un exabyte de capacidad de almacenamiento. Eso es equivalente a un millón de terabytes, una medida más comprensible que está al alcance de muchos ordenadores personales.

Según cuentan en la nota en la que explican cómo se ha llegado a esa cifra se dice que en 2010 ya había 18 PB (petabytes), en 2016 se superaron los 100 PB y en 2022 los 500 PB.

También dicen que el exabyte actual es la combinación de unos 111.000 dispositivos distintos, la mayor parte discos duros y algunas unidades flash. La velocidad de transferencia promedio también es de más de 1 terabyte por segundo.

_____
Foto (CC) Ars Electronica @ Flickr.

Compartir en Flipboard Publicar / Tuitear
PUBLICIDAD


Por @Wicho — 29 de Septiembre de 2023

Logo de HashiCorpComo casi cualquier persona que ande metido en esto de la informática había oído hablar de los servicios en la nube que ofrecen Amazon, Google o Microsoft para desplegar ordenadores sin necesidad de adquirir máquinas. Incluso utilizo algunos servicios en mi trabajo que están montados de esta forma. Pero nunca me había parado a pensar mucho cómo despliegas estas máquinas hasta que la gente de HashiCorp me invitó a una de sus jornadas para desarrolladores.

La historia de HashiCorp comienza con Vagrant. Mitchell Hashimoto, uno de los fundadores de la empresa, se encontró allá por 2010 con que cada cierto tiempo tenía que reinstalar el software de los entornos de desarrollo montados sobre máquinas virtuales que había sido actualizado a versiones nuevas. Era un proceso básicamente manual pero con Vagrant buscó la forma de automatizarlo.

Vagrant funciona entre la máquina virtual y quien la va a usar y le evita quebraderos de cabeza, ya que es adaptable a distintas plataformas y configuraciones de software; se encarga de buscar lo que es necesario para desplegar las herramientas que sean sobre la plataforma que sea.

Pero además tiene la ventaja de que los ficheros en los que se describe la configuración sirven también para codificar el por qué de las opciones tomadas, de tal manera que ese conocimiento queda ahí guardado con independencia de que la o las personas que hayan tomado esas decisiones luego se olviden del motivo o dejen la empresa. Esta es una idea que HashiCorp ha ido incorporando en todos sus productos.

La primera versión estable de Vagrant salió en marzo de 2012; y en noviembre de ese año Mitchell Hashimoto y Armon Dadgar fundaron HashiCorp para dar soporte a su desarrollo.

Con el tiempo la empresa ha ido añadiendo más productos a la colección. Sin ser exhaustivo: Packer, en 2013, que sirve para automatizar la configuración esas máquinas virtuales y que parece un paso lógico después de Vagrant; Terraform, en 2014, que sirve para automatizar la provisión y configuración en distintas plataformas de la infraestructura sobre la que corren esas máquinas; Vault, de 2015, que permite guardar información sensible como claves, contraseñas y tokens sin meterla en el código de las aplicaciones; y Boundary, de 2020, que permite configurar accesos remotos a la infraestructura creada.

De nuevo, en todas ellas la información que se ha usado para ponerlas en marcha queda descrita y codificada en los archivos de configuración. Y al ser productos del mismo fabricante se hablan entre ellos sin mayores problemas, lo que también facilita la vida de quien ha de gestionarlos y usarlos.

Airbus, Air France, Booking o Decathlon, por citar algunos nombres, usan los productos de HashiCorp. Aunque no hace falta ser tan grande para usar sus productos: todos ellos son Open Source y están disponibles bajo un modelo freemium, así que si estás mirando opciones para montar y gestionar infraestructura en la nube pueden ser opciones a tener en cuenta.

La empresa tiene publicadas tres encuestas sobre adopción y resultados del uso de la computación en la nube que te pueden interesar: Welcome to the Multi-Cloud Era (2021), Making Multi-Cloud Work (2022) Y Cloud maturity drives operational efficiency (2023).

Compartir en Flipboard Publicar / Tuitear
PUBLICIDAD


Por @Alvy — 28 de Septiembre de 2023

En este vídeo del canal Chornobyl Family puede disfrutarse del trabajo de seis meses de Alex y Michaela, dos entusiastas de la retroinformática de Ucrania y Eslovaquia. Llevan años visitado la Zona y han recopilado información sobre los ordenadores y equipos que se utilizaban en la central de Chernóbil, principalmente sobre uno llamado SKALA.

El caso es que los equipos informáticos de los reactores I, II y III siguieron funcionando tras el desastre del IV durante muchos años (hasta 1991, 1996 y 2000) y luego se dejaron allí abandonados. Recuperarlos era algo que no tenía mucho sentido y ninguna autoridad tenía previsto hacerlo, pero antes de que acabaran en el basurero se rescataron y restauraron para que pudieran verse en el museo de la central.

Tecnología del pasado, pero adecuada para la época

Estamos hablando de una central de los años 70-80 con equipos informáticos y tecnología de la época, que ahora nos parece primitiva a todas luces. El ordenador principal SKALA (de System of Control and Automatization of Leningrad Atomic Station) utilizaba dos procesadores V-30M con 20 KB de memoria RAM cada uno y una memoria compartida de 8 KB. Esa memoria octal estaba fabricada con núcleos magnéticos de ferrita en grandes placas que se guardaban en armarios. Los hilos de conexión de los bits y bytes estaban enhebrados por amanuenses, como en los ordenadores más primitivos, y soldados con 32 puntos de contacto de forma redundante, con dos conectores de dos capas de paladio, porque debían ser totalmente a prueba de fallos.

El SKALA se utilizaba principalmente para recibir toda la información física de lo que sucedía en el reactor RBMK, que consistía en miles de parámetros: temperatura, presión, niveles radioactivos, de agua y demás. Unos datos eran digitales y otros analógicos. Llegaban desde miles de sensores, cable por cable, hasta la sala donde estaba el SKALA y el resto de unidades de procesamiento y control. Un programa principal llamado DREG se encargaba de hacer los cálculos, mostrar los datos y disparar alertas si algo se salía de los parámetros nominales.

Con otro programa llamado PRIZMA se podía también predecir el comportamiento del reactor según se configurara; esto se usaba en la recarga de combustible. Además había otros programas más pequeños para otras labores puntuales, tales como las pruebas y demás.

Sistema operativo y Lenguaje

El lenguaje que «hablaba» el SKALA era puro código máquina, aunque los investigadores han encontrado algunas notas en pseudoensamblador. No tenía un sistema operativo como tal (al menos, no como los modernos) sino que ejecutaba los programas bajo el concepto de ser una máquina virtual. Además del programa principal de monitorización (DREG) y otro de supervisión, había muchos otros para tareas más sencillas o secundarias que se podían ejecutar cuando había tiempo disponible. Los programas se guardaban y cargaban en cintas magnéticas, pero el arranque del sistema estaba preservado en una cinta perforada, como la de los teletipos; también se usaba esta cinta para modificar el código.

Ver e introducir datos

Tan impresionante como la forma de recoger y procesar los datos era la de mostrarlos. En toda la sala de control no había ni un solo monitor (no existía la tecnología), tan solo botones, luces, pequeños displays e impresoras, además de teletipos. Esa sala y sus panales son una obra de arte del diseño, casi como una vidriera medieval. Las imágenes del sitio son propias de los escenarios del Enterprise de Star Trek (la serie original, claro), con miles de botones luminosos cada uno con una indicación, conectados cable por cable al SKALA del centro de procesamiento de datos, mostrando los valores críticos, normales y todo lo que sucedía en la central.

La «interfaz de usuario» para manejar todo aquello eran pues botones físicos, que en algún caso formaban un panel de control alfanumérico que recuerda mucho a los del Apollo Guidance Computer. Había varios para diferentes operadores en toda la sala. Se escribía un código que representaba a un valor, se pulsaba el botón de consulta y se recibía la respuesta en forma numérica.

Mientras tanto, las impresoras iban imprimiendo línea a línea todo lo que sucedía en la central, a modo de log; los teletipos se utilizaba para las alertas más importantes cuando los parámetros se salían de lo normal. De hecho esos registros físicos fueron muy relevantes a la hora de evaluar lo que sucedió durante el accidente nuclear de 1986, uno de los peores de la historia. Curiosamente Alex y Michaela creen que las marcas de tiempo indicadas en esos registros podrían tener cierto desfase temporal debido a cómo funcionaba el SKALA, que hacía que más que el «cuándo ha sucedido el evento» se imprimiera el «momento en el que se ha procesado el evento». Sobre esto investigarán más.

Renovación y fin

Aunque parezca increíble, el SKALA fue renovado en 1991 y continuó operando hasta 2000 en las zonas de la central que todavía eran operativas. Entre las mejoras había monitores convencionales para facilitar ver toda la información y un nuevo sistema llamado DIIS basado en un ordenador CM-1210 ucraniano capaz de ejecutar más rápidamente los programas como PRIZMA. Finalmente dejó de usarse, comenzó su desmantelamiento y pasó a la historia, excepto para los estudios científicos y de los retroinformáticos, como se ve.

(¡Gracias, Gali, por una pista tan atómica!)

Más enlaces:

Compartir en Flipboard Publicar / Tuitear
PUBLICIDAD


Por @Alvy — 26 de Septiembre de 2023

Está creación de DotEye es tan intranscendente como impresionante, aunque lo curioso es que se le pueden encontrar multitud de aspectos fascinantes que van desde el diseño a las matemáticas o la informática y la programación para gestionar cantidades ingentes de datos. Y es que estando inspirada en la cuasi infinita y vastísima Biblioteca de Babel de Jorge Luis Borges y con Minecraft como «mundo base» no podría ser de otro modo.

La versión Minecraft de la Biblioteca almacena todas las posibles variaciones de las letras del alfabeto (mayúsculas) de 15 caracteres en libros de 16 páginas. Los diferentes volúmenes están en en grandes librerías a medida en las paredes de habitaciones que conectan unas con otras de un modo laberíntico pero no infinito. De este modo, hay un libro que contiene la página con «A», otro con «B», «C» y luego «AA», «AB», etcétera… Y así, habitación por habitación, libro por libro, página por página, hasta «ZZZZZZZZZZZZZZZ», incluyendo algunas consideradas interesantes con «ALEA JACTA EST» o «ÉRASE UNA VEZ».

El proyecto tiene muchas cuestiones curiosas, como por ejemplo las relativas a la arquitectura de las habitaciones, que forman una especie de bloque de 16×16×16 habitaciones con entradas, salidas y escaleras, que encaja con bloques adyacentes idénticos. En cuanto a la parte técnica se utiliza una versión personalizada de un servidor de Minecraft creado mediante ingeniería inversa al que se quitaron todas las funciones no esenciales; la idea era que eso además permitiera gestionar la enormidad de datos del proyecto.

Las cifras de la Biblioteca son impresionantes: según cuenta para almacenar todos los datos harían falta unos 80 PB, porque la lista de las páginas (350 billones) serían unos 350 PB y además hace falta información adicional. Parte del truco para hacerlo manejable es usar unas funciones matemáticas que evitan almacenar todos datos sino que los generan sobre la marcha, a partir de la posición del jugador (básicamente, sus coordenadas) en las habitaciones de la Biblioteca.

Dado que tener todos los libros ordenados alfabéticamente (A, B, C… AA, AB, AC…) sería realmente aburrido de cara a jugar a «descubrir cosas interesantes» hay que desordenarlos. Pero mezclar aleatoriamente los 350 billones de páginas no es trivial. Así que el truco es usar una función criptográfica que produce una secuencia pseudoaleatoria a partir del «número de orden» de dicha secuencia. Es algo así como que a partir de (1, 2, 3, 4, 5, 6, 7) se genera siempre (5, 4, 7, 1, 3, 2, 6). Esta función es curiosamente como las que emplea el algoritmo criptográfico RSA, en concreto uno llamado FF3 de la familia de cifrados con preservación de formato.

A todo esto se añaden virguerías como que en el servidor de Minecraft puede haber varios jugadores que se vean entre sí caminando por las habitaciones y examinando los libros, una función que permite buscar textos (y encontrar el lugar en el que está el libro con tu nombre, por ejemplo) y otras pequeñas maravillas. El proyecto entero es de código abierto y está en Github como Minecraft Library of Babel de donde se puede descargar para jugar, ver, aprender, modificar y mejorar.

Relacionado:

Compartir en Flipboard Publicar / Tuitear
PUBLICIDAD