Alpha-Hardware mit OpenVMS am SAN ist eine gute Idee, da man dadurch Cluster aus mehreren Systemen bilden kann, die sich dann eine Systemplatte teilen und so die Vewaltung der Gesamtumgebung deutlich vereinfachen. Das gleiche gilt natürlich auch für die Datenplatten, der Clustermanager synchronisert die Zugriffe und stellt den Inhalt quasi lokal zur Verfügung. Zudem steht eine clusterweite Quorum-Platte zur Verfügung, die hilft, die Konsistenz des Clusters beim Ausfall einer oder mehrerer Rechner aufrecht zu erhalten. Dazu kommen noch die weiteren Vorteile des SANs: Bereitstellung von großen virtuellen Platten, Raidlevel, die die CPU-Leistung der Rechner nicht beeinträchtigen und eine schnelle Anbindung über Glasfaser.
Für VMS gibt es aber eine entscheidende technische Voraussetzung: das SAN muss das Betriebssystem unterstützen. Und hier kommen die MSA-Lösungen von DEC/Compaq/HP ins Spiel: die können das. Die erste erschwingliche Lösung war MSA1000. Sie erlaube eine vollständig redundante Konfiguration mit bis zu drei Plattenboxen und je zwei Controllern und Glasfaser-Switchen. Pro Box konnten bis zu 14 SCSI-Platten installiert werden, die dann boxenübergreifend in den gängigen Raid-Leveln genutzt werden. Die dadurch generierten logischen Platten konnten eine oder mehrere LUNs bedienen. Zudem war die Lösung offen, ein gemischter Betrieb mit VMS-, Unix-, Windows- und ESX-Servern war problemlos möglich.
Solch ein SAN hatte ich mit 3 ALPHAs unter OpenVMS 8.4 und 2 IBM-Servern unter ESX in Betrieb.
Nun ist diese Hardware mittlerweile recht alt und damit nicht mehr sinnvoll betreibbar, die Gründe dafür sind:
- SCSI-Platten sind inzwischen teuer geworden.
- Der Stromverbrauch ist durch die alten Platten sehr hoch
- Größenbeschränkung des möglichen Plattenplatzes auf maximal 42 Laufwerke mit insgesamt 12 TB
- Die Fibre-Switche sind dedizierte Lösungen, die über Einschübe in die Boxen angeschlossen werden. Bei Defekten muss der Einschub gegen gleiche Module ersetzt werden, die neu kaum, und wenn dann teuer zu beschaffen sind.
Auf die SAN-Plattform kann ich nicht verzichten, da sie die notwendige Flexibilität im Tagesbetrieb bietet. Um zukunftssicher zu sein, muss also eine Lösung her, die die oben genannten Einschränkungen umgeht und natürlich auch die OpenVMS-Systeme weiter unterstützt.
Als einfachste Lösung bietet sich der Wechsel auf die Folgegeneration MSA1500 an: Hier können sowohl SCSI- wie auch SATA-Platten mit einer Gesamtkapazität 96TB von eingesetzt werden, mit der Einschränkung, das nur Platten mit bis zu 1TB unterstützt werden. Für meinen Bedarf ist das vollkommen ausreichend. Die SATA-Platten sind preiswert verfügbar. Als Fibre-Switches können alle auf dem Markt verfügbaren genutzt werden. Ich setzt HP- und Brocade-Geräte ein – wobei der HP-Switch ein umbenannter Brocade ist. Die Verfügbarkeit von preiswerten Ersatz ist also gegeben.
Die Hardware war über Ebay einfach und preiswert zu beschaffen. Für einen reibungslosen Betriebsübergang habe ich erst einmal eine Test- und Migrationsumgebung aus einem Alpha-, einem ESX-Server und einem Fibre-Switch aufgebaut.
Drei 80GB-Platten, 2 im Spiegel und eine als Reserve, reichen für die VMS-Umgebung vollkommen aus. Darauf sind 5 LUNs in verschiedenen Größen abgebildet. Der Datastorage DS1 ist für die Systemplatten der auf ESX betriebenen Debian-Systeme vorgesehen.
Die Testumgebung habe ich dazu genutzt, mit mit der Konfiguration der Fibre-Switche vertraut zu machen – Reset, Zugang trotz nicht bekanntem Admin-Passwort zu bekommen, Konfiguration etc., die Hardware auf Stand zu bringen (Säubern, Pufferbatterien austauschen etc) und dann das Zusammenspiel der einzelnen Komponenten zum Laufen zu bekommen. Im nächsten Schritt habe ich dann die Platten entsprechend der geplanten Aufteilung konfiguriert und das VMS- und ein Debian-System testweise umgezogen. Das alles lief relativ reibungslos, da die eigentliche Konfiguration des MSA1500 sich nicht von der des MSA1000 unterscheidet.
Der Umzug der Systeme ist je nach Plattform unterschiedlich aufwändig.
Der Umzug von VMS-Systemen ist denkbar einfach. Meine regelmäßigen Sicherungen bestehen aus einem Vollabzug aller Platten am Samstag und inkrementellen Sicherungen unter der Woche. Daraus lässt sich ein System mit wenigen Befehlen rekonstruieren. Aus Redundanz- und Sicherheitsgründen halte ich auf jedem Rechner auf einer lokalen Platte eine bootbare Systemplatte bereit. Die wird angestartet, dann die Sicherungsdateien über da Netz kopiert und je nach Platzbedarf auf eine lokale oder eine temporär eingerichtete SAN-Platte abgelegt und dann per Backup/image auf die neuen Zielplatten kopiert. Danach ist die neue Produktionsumgebung fertig und betriebsbereit.
Die Debian-Systeme habe ich per ESX-Funktion umgezogen. Im ersten Schritt wurden alle Systeme auf lokale Platten im Server verschoben und dort wieder gestartet. damit war die Ausfallzeit minimiert und ich konnte die SAN-Hardware in Ruhe umbauen. Dann alles wieder zurück auf das neue SAN und der Umbau war abgeschlossen. Meine Stromrechnung wird es mit danken und die hauseigene Cloudd kann nun auch üppigen Platz bereitstellen.
