Zwei Racks voller Hardware haben seit mehr als 15 Jahren meine Serversammlung zuverlässig bereitgestellt. Das hätte auch so für einige Zeit weitergehen können, wären da nicht mehrere Faktoren, die eine komplette Überarbeitung der Umgebung sinnvoll machten:

• Für die zum Teil sehr alte Hardware wird die Ersatzteilversorgung immer schwieriger und teuerer. Ich habe in den Jahren nicht viel gebraucht, aber das Risiko einesKomplettausfall einer wichtigen Komponente, die dann erst nach langen Beschaffungszeiten erst wieder in BEtrieb genommen werden kann, steigt.
• Alle Systeme waren nicht mehr ausbahfähig und zum teil an Rande ihrer Kapazität. Neue Funktionen ließen sich nicht mehr integrieren.
• Der Stromverbrauch ist viel zu hoch. Für den Betrie waren in Jahr mehrere Tausend Euro erforderlich.
• Eine Softwarekomponenten erfordern in der aktuellen Version Hardware-Eigenschaften, die vo den alten Systemen nicht bereitgestellt werden. Eine, oft auch aus Sicherheitsgründen, erforderliche Aktualiserung ist daher unmöglich.

Ein Reihe neuer Hardwareangebote, die in den letzten Monaten auf den Markt gekommen sind, löst alle diese Probleme.

Die alten Umgebung:
3 x DEC/ComPaq/HP Alphaserver unter OpenVMS 8.4 – OpenVMS spielt bei mir, aus nostalgischen Gründen, eine große Rolle und muss daher auch zukünftig betrieben werden können.

Komplett redundanter MSA1500 Fibre Channel SAN storage.
Die großen Nachteile dieser an sich eleganten Lösung für die Bereitstellung von redundanten Plattenplatz sind:
Es werden nur Platten bis 1TB Große und zudem keine SSDs unterstützt.
Die maximale Größe von 12TB (Sicherheitsmaßnahmen wie Spiegelung halbieren den nutzbaren Bereich) verhindern den Betrieb einer vernünftig dimensionierten Cloud.
Der Stromverbrauch ist viel zu hoch.
Die Abwärme ist viel zu hoch und erfordert im Sommer eine Klimatisierung.
Für die Anbindung an die Server ist ein eigenes Glasfasernetzwerk erforderlich, dass auf Grund seines Alters kaum schneller als 2,5GB-Kupfer-Ethernetanbindungen ist.
Die Ersatzteilsituation ist kritisch.

2 x IBM/Lenovo Server
Die Systeme sind von ESX-Version ab 6.5 nicht mehr unterstützt.
30 GB Haupspeicher pro Server reichen auch beim konsequenten Einsatz von Debian-Systeme, die ja nicht sehr speicherhungrig sind, gerade so aus. Einen Ausbau der vituellen Serverlandschaft ode die Anpassung an höheren Bedarf einzelner Dienste ist icht möglich, beide Server sind aktuell voll ausgelastet.
Auch hier ist die Ersatzteilbeschaffung ein Problem,genau wie der Strombedarf und die Abwärme.
Die Lizenzpolitik von ESX hat sich so verändert, dass eine weitere Nutzung nicht sinnvoll ist.

Diverse Hubs, Switche, Konsolumschalter, LAT-Terminalserver, Bandspeicher.

Ziel des neuen Designs:

Schnellere Hardware mit mehr Kernen und höherer Rechenleistung
Mehr Hauptspeicher
Mehr Plattenplatz
Mehr Schnittstellen für eine bessere Verteilung und Abschottung der Umgebung
Keine Wärmelast und der Verzicht auf die Klimatisierung
Deutlich niedrigerer Stomverbrauch
Problemlose Übernahme der vorhandenen Server auf die neue Umgebung
Konsequenter Einsatz von Open Source
Kostengünstige Lösung

Das Ergebnis:

3 x Minisform MS-A2 Server mit je
96GB Haupspeicher
12TB Plattenplatz (NVME), ausbaubar auf 96TB
2x 2,5 GB Ethernet
2x 10GB SPF+

ProxMox als Virtualisierungsplattform.

Dazu ein MiniPC als Konsole
Konsolumschalter, um alle Systeme über eine Tastatur und einen Bildschirm betreiben zu können.

Als Ergänzung zur vorhandenen Netzwerkinfrastruktur eine Switch, der sowohl 10GB SPF als auch 2,5GB Ethernet bereitstellt.

Diese Umgebung erfüllt alle oben genannten Kriterien. Während bei der Altumgebung zwei USV mit voller Auslastung Sicherheit gegen Probleme im Stromnetz gewährleisteten, genügt nun eine kleine, die am unterer Rand ihrer Kapazität arbeitet. Alleine die gesparten Energiekosten kompensieren die Kosten für die neue Hardware innerhalb eines Jahres.

Die Migration von ESX nach Proxmox war sehr einfach und ohne Probleme.

Seit Inbetriebnahme der neuen Umgebung liegt die Temperatur im Rechnerraum immer auf der Höhe der Umgebungstemperaturen, eine Klimatisierung wird nicht mehr benötigt.

Zudem hat sich der Platzbedarf deutlich reduziert, jetzt genügem 10 Höheneinheiten statt zwei kompletter Racks, was Freiheiten bei der Platzierung des Gesamtsystems gibt.

Die Alpha-Systeme habe ich durch ein APX-Box-Virtualiserung unter Debian ersetzt, alles läuft schneller und die Abhängigkeit von alter proprietäter Hardware ist Geschichte.

Auch alle weiteren Services (Webhostung, Mailserver, DNS, Cloud, Entwicklungsumbgebung, NAS) laufen auf aktuellen Debianservern. zudem habe ich einen alten MacMini mit uraltem Betriebssystem durch eine Virtualisierung auf aktuellem Softwarestand ersetzt.

Die Hardware hat sich bisher bewährt, es gab über die Monate seit dem Umstieg keinerlei Ausfälle.

Schätze aus alter Zeit, die ich beim Aufräumen gefunden habe:

• Aus meiner PDP-11-Zeit, DECPack und RK02-Platte mit RSX-11M, Band mit der Bibliothek meiner eigenen Unterprogramm-Sammlung

• Disketten und Bandkassetten

• TK50-,tk70-, TK85- und Dat-Bandkassetten. Dafür habe ich auch noch die passenden Laufwerke. Das TK50 hat die Installationsdateien einer alten VAX/VMS-Version gespeichert.

• Den Quellcode für VMS 4.0 auf Mikrofilm. Einen Leser habe ich leider nicht, das liegt nur aus Nostalgie im Regal.

• Ein Karte, die die Tastenbelegung eines VT-52-Terminals im Editor-Modus zeigt.

• Eine Mappe mit den Ausdrucken alter Assemblerprogramme für IBM /370 MVS

Die Betriebssoftware eines Stahlwerks gliedert sich in mehrere Ebenen, die gewöhnlich als “Level1”, “Level 2” und “Level 3” bezeichnet werden.

Der “Level 1” besteht aus den Automaten oder SPS, die die Anlage auf unterster Ebene steuern.

Bei dem  “Level 2” handelt es sich um Software, die den Produktionsprozess verfolgt, dazu mit allen Automaten kommuniziert, alle Produktionsinformationen sammelt und basierend auf diesen Informationen  die Durchführung einer Schmelze steuert. Schon bei der Planung der Produktion  bestellt der Level 2  die notwenigen  Rohstoffe  beim  Schrottplatz, errechnet aus der angeforderten Stahlgüte Vorgaben zu Dauer, Temperatursteuerung und Zuschlagsstoffen für Schmelze und steuert die Materialzugaben.  Während der Schmelze kommuniziert der Level 2 mit dem Schrottplatz, dem Labor, der Qualitätssicherung. Er informiert die Operateure über alle Details des produktionsverlaufs. Nach Abschluss der Schmelze werden die Stahlmenge, die erzeugte Güte und Verbrauchswerte an den Level 3 zur kommerziellen Behandlung geliefert und an die nachgelagerte Gussstation geliefert.

Der Level 3 ist die kommerzielle Steuerungsebenen. Hier werden Bestellungen zu Schmelzenreihen zusammengestellt, um eine möglichst kontinuierliche Auslastung der Gesamtanlage zu erhalten. Diese Schmelzenreihen gehen dann als Bestellungen an den Level 2, der sie zum Abruf und zur Abarbeitung bereit hält. Nach Abschluss der Abarbeitung der Bestellungen durch den Level 2 verwertet der Level 3 die gemeldeten Produktionsdaten und Ergebnisse für die kommerzielle Behandlung: Lieferungen zusammenstellen, Rechnungswesen, langfristige Datenhaltung zur Qualitätskontrolle etc

Rosin war schon fast zehn Jahre Lieferant für Level 2  Systeme, mit weltweiten Installation, als über eine große deutsche Industrieanlagenbaufirma der Auftrag für die Aktualisierung einer Anlage in Spanien an uns vergeben wurden.

Dieser Auftrag war ein guter Anlass, eine komplette Neuentwicklung unserer Level 2-Software in Angriff zu nehmen, um folgende Ziele zu erreichen: Das neue Systeme sollte multilingual,  Hardware- und Betriebssystem-unabhängig, datenbankunabhängig, und zukunftssicher sein.

Durch moderne Systemware-Methoden wie Objektorientierung, Java aus Entwicklungssprache, und Oracle als Datenbank wurden diese Kriterien erreicht.

Als  Hardware-Plattform wurden Alpha-Server unter OpenVMS gewählt, zu dieser  Zeit der Standard in  Automation. Die  Benutzeroberfläche wurde in englisch und spanisch bereitgestellt, aber schon im ersten Release war sie leicht um weitere Sprachen erweiterbar, auch in arabisch und chinesisch. Die Entwicklung erfolgte weitgehend unter Windows und Unix, die Portierung auf OpenVMS  erfolgte fortlaufend während de Erstellung, sodass die aktuelle Entwicklungsstand jederzeit auf allen drei Betriebssystemen lauffähig war. Parallel liefen Tests mit Opensource-Datenbanken wie Postgres und Mysql.

2003 wurde der Level 2 beim Kunden installiert, in Betrieb gesetzt und übergeben.

Nach fast neunzehn Jahren meldet sich der Kunde zu unserer Überraschung  im Herbst 2021 mit einem Problem. Das große Rätselraten, was denn nach so vielen Betriebsjahren nun Sorgen bereiten könnte, löste sich auf überraschende Weise:  Die IT-Mannschaft, die sich mit dem System auskennt, geht in Rente, das Systems selbst hat sich aber als so stabil erwiesen, dass man es gerne weiterbetreiben möchte. Die Lösung ist die Übernahme der Betreuung durch uns – dem Kunden kommt dabei zu Gute, dass das System inzwischen für andere Einsätze  deutlich weiterentwickelt wurde, und der Kunde nunmehr auch von den Neuerungen profitieren kann.

Inzwischen sind die Servercomputer auf lokale Umgebungen in Linz und Ronda geclont, erste Probleme durch die Änderungen, die der Kunden in den letzten Jahren eingearbeitet hatte, gelöst, und ein Plan für die nächsten Upgrades erstellt.

Und es macht Spass, wieder mit OpenVMS zu arbeiten

Foto und Text: Dieter Roßbach