Cluster aus Vax 4000/705 und 3500

  • Ein Cluster rein über Ethernet macht bei einer VAX keine Sinn da keine Redundanz in der Clusterkommunikation. Die Systemplatte müsste ein Rechner bereit stellen und der wird zum alleinigen Flaschenhals. Ein Sattelit als Quorum müsste zusätzlich her.

    Eine 3500 mit einer 705a zu Clustern macht vom Load Balancing keinen Sinn da die 3500er im Vergleich zur 705er sehr schwachbrüstig ist.

    Alles unter dem Gesichtspunkt der Redundanz, die 705 Standalone und die 3500er als Satellit ist eine Option.

  • Ein Cluster rein über Ethernet macht bei einer VAX keine Sinn

    Das heißt ein Cluster mit den kleinen Maschinen ergibt keinen Sinn da kein CI/DSSI? Ich dachte Cluster heißt mehr oder weniger der gemeinsame Zugriff auf alle Datenträger im Verbund?

    Richtig, aber Cluster kann auch Redundanz bedeuten. Wenn du die 705 als Standalone Clusterserver betreibst ist das ok. Dann greifen alle Satelliten auf den Server zu und halten Page- und Swapfile sowie lokale Anwendungen auf der lokalen Platte vor

  • Eine 3500 mit einer 705a zu Clustern macht vom Load Balancing keinen Sinn da die 3500er im Vergleich zur 705er sehr schwachbrüstig ist.

    Das kommt ja darauf an, was man mit dem Clustering erreichen möchte - Symmetrische Lastverteilung ist nur eine der Möglichkeiten. LAVC-Cluster mit Ethernet dienen zum Resourcen-Sharing, d.h. man hat einen Server und mehrere Workstations, die ins Cluster booten und die Platten des Servers nutzen. Oder man hat eine große VAX, die nur im Batch-Betrieb genutzt, und eine andere, auf der interaktiv gearbeitet wird, und da die Systeme über DSSI, CI oder LAVC verbunden sind, sehen alle Systeme im Cluster die gleichen Platten. Oder man hat eine Hot-Standby-Konfiguration, bei der die Platten über DSSI oder CI mit zwei Systemen verbunden sind. Beide Systeme sind identisch konfiguriert, aber nur eins der beiden wird im Normalbetrieb verwendet. Fällt ein System aus, kann das andere direkt übernehmen.


    Es gab viele sinnvolle Kombinationen und Einsatzmöglichkeiten. Ich habe verschiedene gesehen und Mischbetrieb kam sehr häufig vor.

  • Eine 3500 mit einer 705a zu Clustern macht vom Load Balancing keinen Sinn da die 3500er im Vergleich zur 705er sehr schwachbrüstig ist.

    Das kommt ja darauf an, was man mit dem Clustering erreichen möchte - Symmetrische Lastverteilung ist nur eine der Möglichkeiten. LAVC-Cluster mit Ethernet dienen zum Resourcen-Sharing, d.h. man hat einen Server und mehrere Workstations, die ins Cluster booten und die Platten des Servers nutzen. Oder man hat eine große VAX, die nur im Batch-Betrieb genutzt, und eine andere, auf der interaktiv gearbeitet wird, und da die Systeme über DSSI, CI oder LAVC verbunden sind, sehen alle Systeme im Cluster die gleichen Platten. Oder man hat eine Hot-Standby-Konfiguration, bei der die Platten über DSSI oder CI mit zwei Systemen verbunden sind. Beide Systeme sind identisch konfiguriert, aber nur eins der beiden wird im Normalbetrieb verwendet. Fällt ein System aus, kann das andere direkt übernehmen.


    Es gab viele sinnvolle Kombinationen und Einsatzmöglichkeiten. Ich habe verschiedene gesehen und Mischbetrieb kam sehr häufig vor.

    Es ging mir um einen Cluster Server Verbund, evtl. war das in meiner Antwort nicht klar. Ein Load Balancing mit zwei solcher Systeme ist absolut sinnfrei. Ich hatte daher erwähnt, das die 3500 als Satellit absolut ok ist.

    Selbst wenn ich die Systeme über DSSI oder CI verbinde, limitiere ich die Einsatzmöglichkeiten für den Endanwender.

    Abgesehen vom administrativen Aufwand.

    Ein System im Standby zu verwenden ist Unix Denken und VMS nicht würdig. Wenn zwei Systeme Gesund sind gibt es keinen Grund es im Normalbetrieb nicht zu verwenden.

  • Kann ich mir das so vorstellen, ich habe eine VAX, daran 100 Terminals. Irgendwann wird die Maschine zu langsam, dann stelle ich eine zweite daneben, mache einen Cluster daraus und die Benutzer bekommen davon nichts mit, nur der Service ist schneller?

    Telex 563140 goap d

  • Ein System im Standby zu verwenden ist Unix Denken und VMS nicht würdig. Wenn zwei Systeme Gesund sind gibt es keinen Grund es im Normalbetrieb nicht zu verwenden.

    Das ist, was unsere Kunden öfter gemacht haben, und ich kann daran nichts unwürdiges oder Unix-artiges erkennen. Redundante Auslegung ist das eine, Anwendungen so zu schreiben, dass sie ein Cluster transparent nutzen können, das andere. Ein einfacher Failover auf ein Standby-System, bei dem nur die Anwendung neu gestartet werden muss, war im übrigen in einem VAXCluster einfacher zu realisieren als auf gleichwertigen Unix-Systemen der gleichen Ära.


    Bei diesen Anwendungen interessiert die Würde von VMS nicht. Es geht darum, maximale Betriebssicherheit und Verfügbarkeit mit minimalem operativen Aufwand zu realisieren.

  • Ein System im Standby zu verwenden ist Unix Denken und VMS nicht würdig. Wenn zwei Systeme Gesund sind gibt es keinen Grund es im Normalbetrieb nicht zu verwenden.

    Das ist, was unsere Kunden öfter gemacht haben, und ich kann daran nichts unwürdiges oder Unix-artiges erkennen. Redundante Auslegung ist das eine, Anwendungen so zu schreiben, dass sie ein Cluster transparent nutzen können, das andere. Ein einfacher Failover auf ein Standby-System, bei dem nur die Anwendung neu gestartet werden muss, war im übrigen in einem VAXCluster einfacher zu realisieren als auf gleichwertigen Unix-Systemen der gleichen Ära.


    Bei diesen Anwendungen interessiert die Würde von VMS nicht. Es geht darum, maximale Betriebssicherheit und Verfügbarkeit mit minimalem operativen Aufwand zu realisieren.

    Sehr interessant, kenne ich so nicht. In meinen über 30 Jahren ist mir noch kein inoperatives Standby System bei VMS unter gekommen.

    Evtl. legen wir den Begriff Standby unterschiedlich aus. Für mich läuft auf einem Standby System nichts, es frisst Strom und wartet auf seinen Einsatz.

  • Sehr interessant, kenne ich so nicht. In meinen über 30 Jahren ist mir noch kein inoperatives Standby System bei VMS unter gekommen.

    Evtl. legen wir den Begriff Standby unterschiedlich aus. Für mich läuft auf einem Standby System nichts, es frisst Strom und wartet auf seinen Einsatz

    Genau so lief das aber beispielsweise in einem Hochregallager bei Opel, sowohl in Bochum als auch in Rüsselsheim. Die zweite der zwei 4000er-VAXen haben wir gelegentlich zum Übersetzen von Änderungen benutzt, ansonsten hat sie herumgestanden und Strom gefressen. Der Vorteil dieser Konfiguration war eben, dass für das Failover nur ein Script laufen musste, und das konnte man ggf. auch per Modem machen. Solche Konfigurationen habe ich in der Industrie ein paar Jahre später auch mit Solaris gehabt. Die Kosten für den Strom, den die Standby-Maschine gefressen hat, waren gegenüber den operativen Vorteilen nachrangig, zumal die Computer-Hardware sowie Energiekosten in den Gesamtprojektbudgets ohnehin nicht dominiert haben. Wenn ich daran denke, was allein die Planung solcher Projekte gekostet hat, wird mir schwindlig :)

  • Auch bei diesem Thema Anmerkungen aus meiner schwachen Erinnerung.

    DSSI bedeutet "gleichzeitiger physikalischer" Zugriff auf die angeschlossenen Platten von den angeschlossenen Rechnern!

    Das ist natürlich über LAN nicht möglich.

    Cluster unter VMS bedeutet nicht nur höhere Ausfallsicherheit sondern auch vereinfachte zentrale Systemverwaltung:

    Für alle Rechner nur eine Systemplatte und eine Benutzer- und Drucker-Verwaltung (und da ist noch etwas, was mir gerade nicht einfällt :/:/)

  • Auch bei diesem Thema Anmerkungen aus meiner schwachen Erinnerung.

    DSSI bedeutet "gleichzeitiger physikalischer" Zugriff auf die angeschlossenen Platten von den angeschlossenen Rechnern!

    Das ist natürlich über LAN nicht möglich.

    Cluster unter VMS bedeutet nicht nur höhere Ausfallsicherheit sondern auch vereinfachte zentrale Systemverwaltung:

    Für alle Rechner nur eine Systemplatte und eine Benutzer- und Drucker-Verwaltung (und da ist noch etwas, was mir gerade nicht einfällt :/:/)

    In der aktuellen Load nachzulesen