Dolly Digital

Wer bislang seine in die Jahre gekommene Alpha-Hardware durch Emulation auf x86-Systemen ablösen wollte, hatte nur die Wahl, auf Windows zu wechseln. Die einzigen Alpha-Emulatoren für die Cross-Plattform Virtualization waren bis vor Kurzem CHARON-AXP von Stromasys (siehe „Onlinequellen“, [a]) und das noch junge FreeAXP beziehungsweise Avanti von Migration Specialties [b]. Wie der Artikel „Neue Heimat“ beschreibt, waren beide Produkte bislang lediglich unter Windows verfügbar [1].

Wer jedoch OpenVMS virtualisieren wollte, hatte nur bedingt ein Windows-System als Emulations-Host im Sinn. Das hochsichere OpenVMS ausgerechnet auf ein als „unsicher“ gebrandmarktes System zu legen, war für viele zu abwegig. Für diese Zielgruppe bietet Stromasys nun seinen CHARON-AXP für Linux [c] an. Damit lässt sich OpenVMS vom echten Alpha-System in eine emulierte Alpha unter x86_64-Linux betten.

Kostenloses Ausprobieren möglich

CHARON-AXP für Linux gibt es in zwei Varianten. Da ist zunächst die kommerzielle, per Lizenz-Dongle (HASP-USB) abgesicherte und kostenpflichtige, die sich durch hohe Leistungsfähigkeit sowie diverse Support-Angebote auszeichnet.

Die andere, CHARON-AXP NCE (Non-Commercial and Educational), steht – nach Registrierung – kostenlos zum Download bereit und ist gegenüber dem großen kommerziellen Bruder in der Leistung gedrosselt. Außerdem hat Stromasys die NCE-Variante mit einem Zeitlimit beschränkt. Nach dem Enddatum heißt es, eine neue Version herunterladen und die Software austauschen. Dafür ist diese Version für private Zwecke, zum Reinschnuppern und zur Weiterbildung kostenfrei. Support ist dabei natürlich nicht enthalten.

CHARON-AXP hat in seiner kommerziellen Variante mehrere Emulatoren im Gepäck. Sie stehen für unterschiedliche Hardwaretypen und -familien wie AlphaServer 4100, DS10 oder ES40. Damit lässt sich der bestehende Hardwarepark zielgenau ersetzen. CHARON-AXP NCE hingegen liefert nur den Emulator für eine ES40.

Als Linux-Host-System erwartet CHARON-AXP ein AMD64-System (x86_64), das für CHARON-AXP wenigstens zwei Cores oder Prozessoren exklusiv bereitstellt. Der Host kann dabei entweder ein physikalisches System sein oder eine virtuelle Maschine in einem VMware ESXi 4.1 Update 1 Hypervisor. CHARON-AXP setzt entweder Red Hat Enterprise Linux (RHEL) 6 oder Fedora 14 voraus, jeweils in der 64-Bit-Version.

In puncto CPU-Leistung des Hostsystems lässt sich keine allgemeingültige Aussage treffen. Hängt es doch stark davon ab, welche Alpha-Systeme man ablösen möchte. Ebenso verhält es sich mit der RAM-Ausstattung. Neben dem notwendigen Arbeitsspeicher für das RHEL- oder Fedora-Basissystem will die RAM-Kapazität des emulierten Alpha-Systems berücksichtigt sein.

Virtuelle Maschine anlegen

Die folgenden ersten Schritte zeigen nun exemplarisch das Anlegen einer virtuellen Alpha ES40. Sie lassen sich identisch mit der kommerziellen sowie der NCE-Version nachvollziehen.

Anders als x86-Emulatoren wie VMware oder VirtualBox bietet CHARON-AXP keine grafische Oberfläche. Die Konfiguration erfolgt in einer ASCII-Datei, die mit entsprechenden Variablen für RAM-Größe, CPU-Anzahl und emulierte Geräte ausgestattet ist. Für die einzelnen Emulatorprogramme liefert Stromasys gut kommentierte Vorlagen mit, die als Basis für die eigene Konfiguration dienen können.

Eine Beispielkonfiguration zeigt das Listing für eine emulierte ES40, die über eine virtuelle Festplatte vom Typ „DEC RZ26B“ mit 1 GByte Kapazität, 512 MByte RAM, ein Netz-Interface vom Typ „DE500BA PCI“ sowie einen SCSI-Controller verfügt. CHARON-AXP realisiert die Netz-Interfaces als Bridge auf eine physische Schnittstelle; im Listing auf das Linux-Gerät eth0.

Weiter bildet die Konfiguration die Festplatte DKA0 und das CD-ROM-Laufwerk DKA400 auf Dateien ab. Alternativ ließen sich hier physische Geräte des Hosts angeben. Zum Generieren der Disk-Images liefert CHARON-AXP das Dienstprogramm mkdskcmd mit. Damit lassen sich Images diverser Festplatten erzeugen, die auf Alpha, VAX und PDP-11 zum Einsatz kommen respektive kamen. Einen Überblick liefert der Befehl mkdskcmd –l. Das Erzeugen der Datei dka0.vdisk für die Festplatte DKA0 vom Typ RZ26B übernimmt das Kommando mkdskcmd –o dsk0.vdisk –d RZ26B.

Damit ist auch schon eine einfache virtuelle Maschine vom Typ AlphaServer ES40 fertig konfiguriert. Sie lässt sich nun über es40 es40.cfg im Falle der kommerziellen Variante und über es40_nce es40.cfg beim Einsatz der NCE-Variante starten. Auf dem Terminal erscheinen die ersten Ausgaben der Alpha-typischen SRM-Console, und der Prompt P00>> harrt der Eingabe von Befehlen. Die weiteren Schritte unterscheiden sich von denen auf einer echten Alpha nicht. Ein Booten von CD erfolgt durch den Befehl b dka400.

Damit lässt sich die Installation von OpenVMS starten und ausführen. Sind Installation und Shutdown abgeschlossen, zeigt sich wieder der Prompt der SRM-Console. Der Befehl b dka0 startet die virtuelle ES40 schließlich von der Festplatte DKA0 und damit ins installierte System (siehe Screenshot). Dort lässt sich die weitere Konfiguration des OpenVMS-Systems vornehmen. Nach dem Shutdown akzeptiert die SRM-Console den Befehl power off, der das virtuelle Alpha-System „ausschaltet“. Für CHARON-AXP heißt das: Der Emulator beendet sich.

Migration vorhandener Altsysteme

Wie gezeigt, ist das Erzeugen einer jungfräulichen virtuellen Alpha kein Hexenwerk. Allerdings stellt sich die Frage, wie bestehende physikalische Systeme in die virtualisierte Welt wandern können. Selbstverständlich hängt der einzuschlagende Weg stark vom Umfeld und konkreten Faktoren ab, beispielsweise der Komplexität der Umgebung oder der Akzeptanz etwaiger Downtimes. Dennoch lassen sich einige Lösungsmuster für einen Umzug in die neue Heimat finden.

Ein radikaler Weg wäre, die SCSI-Festplatten aus den Alphas zu ziehen und ans Linux-System anzuschließen. Die Geräte ließen sich womöglich über ihre Special-Files CHARON-AXP als set PKA container[N]="/dev/…" unterschieben. Dieser Ansatz wäre aber ziemlich brutal und risikoreich. Schließlich würden die Platten auskühlen (nach dem Dauerbetrieb ein Problem) und wären beim Transport Erschütterungen ausgesetzt. Zudem wäre dies zwangsläufig mit einer längeren Downtime von Systemen verbunden – was sich im Cluster-Betrieb noch abfedern ließe. Außerdem würden schließlich die alten Platten, die man eigentlich ersetzen wollte, in die neue Konfiguration einfließen. Gerade die Festplatten sind in einem Altsystem der größte Risikofaktor; unterliegen sie doch dem höchsten Verschleiß.

Ein anderer Weg wäre der Einsatz von Sicherungen auf (lokales) Band. Das führt allerdings nur bedingt zum Ziel. Einerseits müsste das Bandlaufwerk wiederum den Weg ans Linux-System finden. Andererseits müsste der Emulator das Bandlaufwerk virtualisiert einem laufenden OpenVMS bereitstellen.

Anders sieht es schon mit zentralisierten Backup-Lösungen aus. So lässt sich beispielsweise ein IBM Tivoli Storage Manager (TSM) per STORServer Archive Backup Client (ABC) ansprechen, um Backups von OpenVMS auf ein TSM zu legen. Auf diese Datensicherungen in TSM kann man auch aus einem virtualisierten OpenVMS heraus zugreifen. Einem Restore aus TSM heraus in die virtuelle Alpha steht damit nichts im Wege.

Aus Alt mach Neu: Klonen von Systemen

Eine weitere Option eröffnen die Bordmittel von OpenVMS. Sowohl DECnet als auch VMScluster bieten eine gut ausgestattete Infrastruktur zum Klonen von OpenVMS-Systemen. Zwar empfiehlt HP bei OpenVMS-Platten dieses Vorgehen nicht gerade [h], sondern propagiert die Neuinstallation über das OpenVMS-Distributionskit als einfacheren, sichereren und schnelleren Weg. Unter normalen Umständen mag dies zutreffen. Wer jedoch Alpha-Systeme virtualisiert, statt auf die aktuelle Hardware-Plattform Itanium2 (Integrity) umzusteigen, kämpft in der Regel mit den typischen Problemen des Legacy-Umfelds. Historisch gewachsene, teils schlecht dokumentierte Systeme und unzureichendes Know-how über die alten Systeme sind hier an der Tagesordnung. Das Klonen scheint oft erfolgsversprechender als eine Neuinstallation zu sein. Die gute Nachricht ist, dass dieser Weg gangbar ist, wenn man einige Regeln beherzigt.

Einfaches Umstecken funktioniert nicht

Da das Umstecken von Festplatten oder lokalen Sicherungsbändern aus den oben genannten Gründen ausscheidet, muss ein anderes Sicherungsmedium her. Idealerweise bietet sich eine virtuelle Disk auf dem CHARON-AXP-Zielsystem an. Dieses lässt sich über DECnet zur Aufnahme der Backup-Images der alten Festplatten nutzen. Im VMScluster ist ein direktes Cloning auf diese virtuelle Disk möglich. Nach demselben Schema, wie zuvor die virtuelle Platte für DKA0 entstand, lassen sich über mkdskcmd weitere virtuelle Disks erzeugen. Zeilen der Form

set PKA container[N]="dkaN.vdisk" 

nehmen diese neuen virtuellen Platten in die Konfiguration der virtuellen Alpha auf. N ist dabei eine Adresse, die im Endeffekt mit einer SCSI-ID korreliert, konkret 0, 100, 200, 300 und so weiter.

Bevor das Klonen per DECnet oder VMScluster beginnen kann, sollte man möglichst viele Prozesse stoppen, die Dateien offen halten. Dies sind insbesondere Queues, Datenbanken und andere Dienste. Ebenfalls aus dem System zu verbannen sind aktive Benutzer. Lediglich das System hält weitere Dateien offen, wie solche für Paging/Swapping. Das ist bei diesem Ansatz unvermeidlich. Dies ließe sich nur dadurch umgehen, dass man der zu migrierenden Alpha eine weitere Festplatte spendiert, dort parallel ein OpenVMS installiert und dieses bootet. Danach lassen sich die originalen Platten ohne offene Dateien migrieren. Die dadurch entstehende Downtime liegt im Bereich des Vertretbaren; ganz ohne Ausfall funktioniert das Klonen nicht. Die bereitgestellten Queues, Datenbanken und Dienste sind in jedem Fall zu stoppen. Beim Verwenden eines parallel installierten OpenVMS kommen jedoch zusätzliche Konfigurationsaufgaben wie das Einrichten von DECnet (Plus) und gegebenenfalls VMScluster hinzu.

Verdopplung via DECnet

Das Klonen über DECnet erfolgt notwendigerweise in zwei Schritten. Anders als im Cluster lassen sich die Platten des zu klonenden Systems nicht remote mounten. Stattdessen ist zunächst auf dem zu klonenden System ein Backup der Festplatte in eine Backup-Datei auf dem virtuellen System zu schreiben. Idealerweise legt man hierzu, wie zuvor erwähnt, eine eigene Backup-Disk in der virtuellen Alpha an. Diese Backup-Disk sollte circa ein Drittel größer sein als der Speicherplatz, den alle Platten der echten Alpha belegt haben. Damit ist man auf der sicheren Seite.

Im Folgenden soll die „Backup-Disk“ auf der virtuellen Alpha das Label BCKUP00 erhalten und als DKA100: bereitstehen. Folgende auf dem DCL-Prompt der laufenden virtuellen Alpha abgesetzten Befehle formatieren die Disk und mounten sie:

INIT DKA100 BCKUP00 
MOUNT/SYS/NOASSIST DKA100 BCKUP00 

Ist die virtuelle Alpha beispielsweise über die DECnet-Adresse 2.10 erreichbar, stößt folgendes Kommando auf der echten Alpha ein Backup der Festplatte DKA0 an:

BACKUP/IMAGE/IGNORE=INTER DKA0: 2.10"USER PWD"::DISK$BCKUP00:
 [000000]DKA0.BCK/SAVE 

USER und PWD sind dabei durch einen berechtigten Benutzer auf der virtuellen Alpha und dessen Passwort zu ersetzen. Dies kann entfallen, wenn ein DECnet-Proxy zum Einsatz kommt. Nach erfolgreichem Lauf findet sich in der Datei DISK$BCKUP00:[000000]DKA0.BCK ein Sicherungs-Image der DKA0-Platte der echten Alpha. Backups weiterer Festplatten lassen sich analog über DECnet auf der virtuellen Alpha erstellen.

Im zweiten Schritt kann nun der Restore der Festplatte im virtuellen System erfolgen. Hierfür sind weitere virtuelle Festplatten anzulegen und in die CHARON-AXP-Konfiguration einzubinden, die als Ziel für das Klonen dienen. Zum Zurücksichern von DKA0 beispielsweise auf eine virtuelle Platte DKA200 dienen folgende Befehle:

MOUNT/FOREIGN DKA200: 
BACKUP/IMAGE DISK$BCKUP00:[000000]DKA0.BCK DKA200: 
DISMOUNT DKA200: 

Anschließend lässt sich die Festplatte über die Befehle überprüfen:

MOUNT/OVER=IDENT DKA200:
ANALYSE/DISK DKA200: 
DISMOUNT DKA200: 

Nach dem gleichen Vorgehen lassen sich alle anderen Festplatten aus den Sicherungen wieder herstellen. Auf diese Weise entsteht ein 1:1-Abbild der echten Alpha auf dem virtuellen System. Sind alle Festplatten erfolgreich wieder hergestellt, lässt sich die CHARON-AXP-Konfiguration umbauen und der Klon booten. Die alte DKA0-Platte der virtuellen Alpha und die Backup-Platte sind dann nicht mehr notwendig.

Klonen via Cluster

In nur einem Schritt ist das Klonen im Cluster zu bewältigen. Das virtuelle Alpha-System muss hierzu zunächst in den Cluster. Das bewältigt komfortabel der folgende Befehl, wobei Cluster-Nummer und -Passwort bereitzuhalten sind:

@SYS$MANAGER:CLUSTER_CONFIG 

Anschließend benötigt das virtuelle System lediglich virtuelle Festplatten als Ziel für das Klonen. Ein Backup-Medium ist nicht notwendig. Nachdem die virtuelle Alpha im Cluster angekommen ist, lässt sich das Klonen anstoßen. Angenommen, das zu klonende echte Alpha-System hört auf den Node-Namen AXP006, und seine Platte DKA0 hat das Label AXP006SYS. Weiter ist diese DKA0-Disk auf die Platte DKA100 des virtuellen Systems zu klonen. Hierzu ist Letztere zunächst auf dem virtuellen System mit der Option FOREIGN zu mounten:

MOUNT/FOREIGN DKA100: 

Anschließend hängt man auf dem virtuellen System die Platte DKA0 von AXP006 ein:

MOUNT/SYS/NOASSIST AXP006$DKA0 AXP006SYS 

Nun stößt der BACKUP-Befehl das direkte Klonen an:

BACKUP/IMAGE /IGNORE=INTER AXP006$DKA0: DKA100: 

Nach dem Klonen ist noch ein DISMOUNT fällig:

DISMOUNT DKA100: 

Alle weiteren Festplatten treten nach demselben Prinzip die Wanderung über den Cluster ins virtuelle System an. Das Überprüfen der so geklonten Festplatten erfolgt mit den gleichen Schritten wie beim Vorgehen über DECnet.

Mit dem Cluster lässt sich dieser Vorgang direkt von Gerät zu Gerät in einem Schritt durchführen. Dieser Weg ist damit einfacher, schneller und benötigt weniger Festplattenplatz. Außerdem führt man sämtliche Schritte des eigentlichen Klonens auf dem virtuellen System aus. Lediglich die vorbereitenden Schritte wie das Stoppen von Queues, Datenbanken et cetera erfolgt naturgemäß auf dem echten Alpha-System.

Fazit

Das Verdoppeln von Alpha-Systemen in die virtuelle Welt von CHARON-AXP unter Linux ist weitgehend unkompliziert möglich. Lediglich Detailunterschiede in der Konfiguration der echten und der virtuellen Alpha können Schwierigkeiten bereiten. Diese lassen sich aber durch ein wenig Nacharbeit leicht beheben. Ob nun das zweistufige Klonen per DECnet oder das direkte Kopieren per Cluster zum Einsatz kommt, hängt von der konkreten Systemarchitektur ab.

Sicherlich wäre die Neuinstallation mit anschließendem Migrieren als Alternative zum Klonen sauberer, da sie die Möglichkeit zum gründlichen „Hausputz“ beinhaltet. Für Migrationen von VAX oder Alpha auf Itanium ist das der einzig gangbare Weg. Allgemein wäre es zu bevorzugen. Die Empfehlung von HP kommt nicht von ungefähr, da beim Klonen immer einige (System-)Dateien offen bleiben. Wie zuvor gesagt, für viele Migrierende wäre die „Hausputz-Variante“ beim Übergang in die virtuelle Welt sicherlich aber der steinigere Weg. Das „offene Dateien-Problem“ lässt sich notfalls durch ein für das Klonen parallel installiertes, unabhängiges OpenVMS vermeiden. Es erfordert dann aber mehr Aufwand.

Oliver Müller

ist freiberuflicher Berater, Trainer und Autor. Seine Schwerpunkte sind Unix/Linux, Legacy-Systeme, Java EE und mobile Plattformen.

Literatur

[1] Oliver Müller; Altlasten-Virtualisierung; Neue Heimat; OpenVMS-Systeme auf neuer Hardware; iX 9/2010, S. 99

Alle Links: www.ix.de/ix1111152

# Emuliere einen AlphaServer ES40
 set session hw_model="AlphaServer_ES40"
 
 # Setze das Log auf "append"
 set session log="AlphaServer_ES40.log" log_method="append"
 
 # 512 MB RAM
 set ram size=512
 
 # Erhalte Einstellungen der SRM-Console
 # bei Emulator-Restart
 set rom container="clipper.bin"
 
 # Speichere NVRAM-Inhalt, sodass
 # Datum und Zeit erhalten bleiben
 set toy container="clipper.dat"
 
 # Operator Console ist das Linux-Terminal
 load operator_console OPA0
 
 # alternativ lässt sich die Console auch
 # auf serielle Schnittstelle legen:
 # load physical_serial_line OPA0 line="/dev/tty0"
 # Lade einen DE500BA PCI Netzwerkadapter
 # "bridged" auf eth0
 load DE500BA/dec21x4x EWA interface=EWA0
 load packet_port/chnetwrk EWA0 interface="eth0"
 
 # Emuliere einen SCSI-Controller vom Typ DEC-KZPBA
 load KZPBA PKA scsi_id=7
 # Emuliere eine Festplatte als DKA0 in der
 # Datei dka0.vdisk
 set PKA container[0]="dka0.vdisk"
 
 # Emuliere ein CD-ROM-Laufwerk als DKA400 und
 # verbinde es mit dem ISO-Image alphacd.iso,
 # welche die Setup-CD für OpenVMS 8.3 AXP enthält.
 set PKA container[400]="alphacd.iso" 

(avr)