OpenVMS.org (Archiv) dcl.OpenVMS.org (Archiv) HPE OpenVMS OpenVMS Technical Journal VMS Software Inc.
de.openvms.org - Für die deutschsprachige VMS-Community [OpenVMS Swoosh]
Hosted by
PDV-Systeme GmbH
Aktuell | Suchen | Archiv | Eintragen | Über uns | Disclaimer | Kontakt
Links zum Artikel

Navigation

Rubriken

RSS Feeds

de.OpenVMS.org

Benutzer
Gäste online: 10
Benutzer online: 0


Login
Benutzername:

Passwort:


[Einen Benutzer anlegen]


OpenVMS.org ist jetzt OpenVMSNews.com. Links, die auf den alten Site verweisen, funktionieren nicht.


OpenVMS Solo-Cluster: Eine neue Perspektive - funktioneller, flexibler, benutzbarer
Der OpenVMS-Fachberater - 13-Jan-2010 13:15 UTC
von Bob Gezelter

Alleinstehende OpenVMS-Systeme und OpenVMS Cluster werden i.allg. als verschiedene Konfigurations-Alternativen angesehen. Diese Unterscheidung hat sich überlebt und sollte beseitigt werden. Stattdessen schlage ich OpenVMS Solo-Cluster als angemessenere Bezeichnung und nützliche Default-Konfiguration vor. Ein OpenVMS Solo-Cluster ist ein OpenVMS Cluster, das nur aus einem einzigen System besteht. Diese Einstellung sollte die bevorzugte Konfiguration für einzelne OpenVMS-Systeme sein. Solch ein Solo-Cluster mag eine triviale Instanz eines Clusters sein, hat aber auf lange Sicht signifikante Vorteile. Diese Konfiguration erlaubt einen nahtlosen Übergang zu einem Multinode-Cluster, sowohl temporär als auch dauerhaft.

Obwohl sie ein Widerspruch in sich zu sein scheinen, sind sowohl Solo-Cluster als auch Solo-Shadowsets von erheblichem Nutzen.

Solo-Cluster spiegeln eine verfeinerte strategische Vision dessen wieder, wie OpenVMS-Technologien der Firma einen Wettbewerbsvorteil verschaffen können. Dieses Konzept vereinigt die Macht mehrerer Technologien, u.a.:
  • OpenVMS Cluster

  • Host Based Volume Shadowing (HBVS)

  • DECnet

  • TCP/IP

OpenVMS bietet im Vergleich zu anderen Betriebssystemen viele Vorteile. Es wurde als sicher, vielseitig und robust entworfen. Seine Design-Prinzipien haben sich über Jahre bewährt. Seine Architektur basiert auf einer konsistenten Gruppe von Kernkonzepten. Diese grundlegenden konzeptuellen Bausteine sichern, dass Verbesserungen in darunterliegenden Schichten (z.B. RMS oder OpenVMS Cluster) von Applikationen ohne Codeänderungen genutzt werden können. Oft ist weder Neu-Kompilierung noch Relinking von Executables notwendig. Änderungen in zugrunde liegenden Diensten werden automatisch eingebunden, wenn ausführbare Dateien aktiviert oder Geräte angesprochen werden.

Ich habe mir anhören müssen, dass das nichts Neues ist, und dass diese Konzepte schon voll ausgeschöpft wurden. Ich bin anderer Meinung. OpenVMS Solo-Cluster verwandeln Features (z.B. OpenVMS Cluster und HBVS) von Nischen-Fähigkeiten in ein strategisches Fundament, um die Kapazität und Leistungsfähigkeit mit der Zeit richtig einzustellen. Die Fähigkeit, Kapazitäten schnell und unterbrechungsfrei neu zu konfigurieren, ist von enormem Wert. Besonders OpenVMS Solo-Cluster sind ein Ausgangspunkt, von dem aus OpenVMS-basierte Systeme nahtlos und wiederholt upgedatet und eingestellt werden können, ohne dass Benutzer das bemerken. Das ist eine unabdingbare Voraussetzung für "Infrastruktur-EDV".

Derzeit werden HBVS und OpenVMS Cluster sowohl als eigenständige Produkte als auch als Teil der
Enterprise und Mission Critical Lizenzgruppen auf HP Integrity Servern lizensiert.

Auch wenn es nicht weithin bekannt ist, so wird für die Konfiguration und den Betrieb eines einzelnen Knotens als Solo-Cluster kein OpenVMS Cluster PAK benötigt. Hingegen ist der Lizenz-PAK notwendig, um das OpenVMS Cluster auf mehr als einen Knoten zu erweitern. Volume Shadowing für OpenVMS wird z.Zt. separat lizensiert, falls das Produkt nicht anderweitig bereits lizensiert ist.

Im normalen Betrieb gibt es keinen Unterschied zwischen einem alleinstehenden OpenVMS-System und einem OpenVMS Solo-Cluster; die Unterschiede zeigen sich mit der Zeit.

Über die Zeit betrachtet, emöglicht diese Änderung etwas, das ich als "Spiraling" bezeichnen möchte; einen Ansatz zur Systemimplementation, der agil, dynamisch und kosteneffektiv ist. Dieser Ansatz nutzt die Einrichtungen von OpenVMS, um die Kosteneffizienz und Laufzeit zu verbessern. Einfach ausgedrückt erlaubt Spiraling einem System, sich nahtlos von einer Testumgebung zu einem vollen Produktionssystem zu entwickeln. Maßstäbe werden unerheblich. Die Testumgebung kann in einer Garage, einem Esszimmer oder einem Lager in Betrieb gehen; das Produktionssystem kann in der Größe irgendwo zwischen zwei kleinen Server und einem Multi-Site OpenVMS Cluster mit fast 100 Knoten bestehen.

Der Schlüssel zum Spiraling besteht in der Erweiterung der strategischen Anwendung von OpenVMS Clustern, HBVS und dem Netzwerk, um die Arbeitslast im Laufe der Zeit zu verlagern. OpenVMS-Standorte, die Cluster-Laufzeiten im Jahrzehnte-Maßstab erreicht haben, haben diesem Ansatz in dieser oder einer anderen Art über Jahre verfolgt.

Wenn man den Gedanken des Spiraling weiter verfolgt, so wäre eine kleine Änderung in der Standard-Konfiguration während der OpenVMS-Installation angemessen. Derzeit wird bei einer jungfräulichen Installation von OpenVMS gefragt, ob das System Teil eines OpenVMS Cluster sein wird. Die Änderung ist schlicht und dreht sich um die Frage:

Will this system be a member of an OpenVMS Cluster? (Yes/No)

Die Standard-Antwort ist z.Zt. No. Eine bessere Standardeinstellung wäre Yes. Zur Vereinfachung sollten auch die Eingabe der DECnet-Knotenadresse und des SCSID vereinheitlicht werden. Dies verändert die Standard-Grundkonfiguration von einem alleinstehenden OpenVMS-System zu einem OpenVMS Solo-Cluster.

Obwohl ich sie nicht namentlich erwähnt habe, sind die Techniken seit vielen Jahren Teil meiner Beratungstätigkeit. Spiraling war auch ein nicht namentlich erwähntes Basiskonzept meiner jüngsten HP-Technologie-Vorträge, u.a. Evolving OpenVMS Environments: An Exercise In Continuous Computing, Migrating OpenVMS Storage Environments without Interruption or Disruption, Strategies for Migrating from Alpha and VAX Systems to HP Integrity Servers on OpenVMS und dem gleichnamigen Artikel im OpenVMS Technical Journal von 2007.

Diese konzeptuelle Änderung bedingt eine kleine Änderung bei der Lizensierung von OpenVMS. Im normalen Betrieb vergrößert sich weder die Funktionalität von OpenVMS durch diese Änderung noch verringert sie sich; daher gibt es keine Nachteile. Im schlimmsten Falle ist sie kostenneutral. Mit der Zeit bietet sie sowohl den Nutzern Vorteile als auch unerschlossenes Einkommenspotential für HP. Die Durchführung dieser kleinen Änderung ist unkompliziert. Die einzig benötigte Änderung ist es, die Verwendung von HBVS, beschränkt auf ein einzelnes Shadowset-Mitglied, unter der OpenVMS-Basislizenz für Alpha- und Integrity-Server zu gestatten.

Solche Lizenzänderungen gab es schon früher. Seit den Anfängen hat es DECnet-VMS dem Nutzer erlaubt, ohne besondere Netzwerk-Lizenz auf einem degenerierten Netzwerk aus einem einzelnen Knoten zu arbeiten. Diese Netzwerk-Konfiguration bietet vollen Zugriff auf die DECnet-APIs unter der einzigen Bedingung, dass alle Kommunikation innerhalb des Knotens und nicht zwischen mehreren Knoten abläuft. Auch wenn es dem Endbenutzer nur bedingt nützt, so ist es doch für OEMs und ISVs sehr wertvoll. Es erlaubt Test, Entwicklung und kleine Produktionssysteme auf Einzelknoten, mit einer nahtlosen Erweiterungsmöglichkeit auf mehrere Knoten, einfach durch Änderung einer Konfigurationseinstellung, oft durch einen logischen Namen. Wenn es mittels logischen Namen implementiert wird, ist es sogar möglich, die Änderung ohne Unterbrechung des Systembetriebs durchzuführen.

Weiterhin vereinfacht diese Änderung einen Wechsel in der Hardware dramatisch. BigBang-Übergangsrisiken gehören der Vegangenheit an. Hardwarewechsel nehmen die gleichen Züge an, die für Upgrades von Hochverfügbarkeits-Software charakteristisch sind: Rolling Updates auf neue Hardware. Das kann mit zeitlich begrenzten Lizenzen bewerkstelligt werden, für die Dauer des Betriebs jenseits des Solisten.

Darunter fallen CPU-Änderungen, sowohl innerhalb der Architektur als auch der Übergang zu einer anderen Architektur. In beiden Fällen wird aus dem OpenVMS Solo-Cluster zeitweise ein Zwei-Knoten-Cluster gemacht, der neue Knoten übernimmt die Arbeitslast, der alte Knoten wird aus dem Cluster entfernt, und der Betrieb als Solo-Cluster wieder aufgenommen. Danach besteht kein Bedarf mehr für eine Unterstützung von Multi-Knoten-Clustern und der temporäre PAK wird nicht mehr benötigt. Der springende Punkt ist, dass es von außen gesehen keine Unterbrechung der Dienste gibt.

In gleicher Weise wird ein Wechsel auf neuen Massenspeicher zu einem Test des neuen Speichersystems, der Erzeugung oder Installation von neuen Platten, dem Einbinden dieser Platten in die bereits bestehenden Shadowsets, dem Abwarten der Komplettierung der Shadow-Kopien, und dem Entfernen der alten Platten aus den Shadowsets. Das erlaubt es, neue Hardware einfach und mit kontrolliertem Risiko in Betrieb zu nehmen. Der Prozeß kann an jedem Punkt pausiert werden, wenn Probleme auftreten. Sobald alle Platte migriert und die alten Platten entfernt sind, gibt es dafür keinen Bedarf mehr für Shadowsets mit mehreren Mitgliedern.

Auf den ersten Blick scheinen OpenVMS Solo-Cluster und -Shadowsets ungewöhnlich oder unorthodox zu sein. Dieser Eindruck trügt. Sowohl OpenVMS Cluster als auch Shadowsets haben diese Konfigurationen seit der Einführung dieser Techologien voll unterstützt. Alles bisher Erwähnte steht im Einklang mit der Dokumentation und den SPDs.

Zugegeben, die meisten sind vertrauter mit OpenVMS Clustern und Shadowsets in Paaren oder größeren Kollektionen. Manche möchten vielleicht mit diesen Konfigurationen persönliche Erfahrungen sammeln und sie besser verstehen. Im Falle der OpenVMS Cluster ist alles, was gebraucht wird, eine Testkonfiguration.

Der Betrieb eines OpenVMS Solo-Clusters erfordert lediglich die OpenVMS-Basis-Lizenz. Die OpenVMS-Cluster-Lizenz wird nur benötigt, um ein Cluster mit mehr als einem Mitglied zu betreiben.

Host-Based Volume Shadowing benötigt einen Lizenz-PAK, selbst für den Solo-Betrieb. Es gibt Test-Lizenz-PAKs für jene, die das Arbeiten damit ausprobieren möchten, wenn die Firma Mitglied von HPs Developer and Solution Partner Program (DSPP) ist. Wenn Sie bei einer Bildungseinrichtung beschäftigt sind: HBVS ist eines der Layered Products, die Teil des Programms sind. Studenten und Fakultätsmitglieder können die Brauchbarkeit dieser Konfigurationen erforschen.

Es gibt auch viele, die - aus welchen Gründen auch immer - diese Konzepte in ihrem Arbeitsleben nicht erforschen wollen oder können. Der Grund mag ein nicht vorhandener Zugang zu Hardware sein, oder das Bedürfnis, diese Konzepte privat zu erkunden. Für all jene bietet das OpenVMS Hobbyist Lizenzprogramm einen Weg, ihr Verständnis von OpenVMS ohne die Unterstützung eines kommerziellen Sponsors zu vertiefen.

Sollte zuhause keine Hardware vorhanden sein, oder das Bedürfnis bestehen, auf dem nächsten Flug oder der Bahnfahrt zur Arbeit diese Konzepte zu erkunden, dann gibt es eine ganze Anzahl von Simulatoren für VAX- und Alpha-Systeme, deren Benutzung für den Privatgebrauch kostenlos ist, u.a.:

Alle diese Simulationen laufen auf gewöhnlichen x86-basierten Systeme, einschließlich Notebooks. Ein OpenVMS Cluster mit Spiraling ist ein wesentlich geschmeidigeres Werkzeug mit mehr Funktionalität als viele andere Optionen im Bereich der Migration zu virtuellen Maschinen.

Wie immer begrüße ich Leserkorrespondenz zu den Inhalten dieser Kolumne. Ich bin zu erreichen über den Website meiner Firma unter http://www.rlgsc.com.

FreeAXP™ ist ein Warenzeichen von Migration Specialties International, Inc.



Über den Autor:

Robert Gezelter, CDP, CSA, CSE, Software Consultant, hat mehr als 30 Jahre internationale Erfahrung mit der Fachberatung im privaten und öffentlichen Sektor. Er ist regelmäßiger Gastredner auf technischen Konferenzen weltweit, einschließlich des HP Technology Forums. 2004 hat die IEEE Computer Society Mr. Gezelter in ihr Distinguished Visitors Program berufen, das Redner auf Veranstaltungen von IEEE-Verbänden in ganz Nordamerika vermittelt. Außerdem hat er zahlreiche technische Artikel und Buchkapitel verfasst, einschließlich zweier Kapitel in dem kürzlich erschienenen Computer Security Handbook, 5. Auflage.

Kürzlich hat er begonnen, Ruminations - An IT Blog über IT-Themen zu schreiben, die nicht mit OpenVMS in Verbindung stehen.

Die Tätigkeit seiner Firma betont detaillierte technische Expertise in den Bereichen Computer-Architekturen, Betriebssysteme, Netzwerke, Sicherheit, APIs und verwandte Themen. Mr. Gezelter hat mit OpenVMS seit der ersten Release von VAX/VMS 1977 gearbeitet.

Seine Kundenstamm umfasst sowohl kleinere Firmen wie auch Firmen in den Fortune 10, lokal, national und international, mit Arbeitsbereichen, die von individuellen Telefon-Fragen bis zu größeren Projekten reichen.

Im Web ist er über den Website seiner Firma unter http://www.rlgsc.com zu erreichen.


Original auf www.openvms.org

Links zum Thema: | Version zum Drucken

< OpenVMS Webinar Nr.3: Das Mimer SQL DBMS auf OpenVMS | NHSBT- Fallstudie von HP veröffentlicht >

HP-Benutzergruppen

Events

Websites

Blogs

Freie VMS-Accounts

[Future Forward] OpenVMS: 30 Jahre, und es geht weiter

Der 25. Oktober 2007 markiert das 30te Jubiläum der VMS V1.0 Release. Drei Dekaden Exzellenz, von anderen Betriebssystemen unerreicht. Von VAX über Alpha bis Integrity, OpenVMS ist die Kraft hinter den kritischsten Anwendungen auf der Welt!


Bei HP:

- HP feiert 30 Jahre OpenVMS
- Ein Grußwort von Ann McQuaid, General Manager HP OpenVMS Systems Division

In der Gemeinschaft und der Presse:
- ComputerWorld: Während sich OpenVMS der 30 nähert, graben Benutzer Videos aus DECs Blütezeit aus
- InternetNews: OpenVMS ist 30, und immer noch stark
- InformationWeek: VMS Betriebssystem ist 30 Jahre alt; Kunden sind überzeugt, dass es für immer halten kann
- Enterprise Open Source Magazin: Happy Birthday, OpenVMS

OpenVMS® is a trademark of HP.
All other trademarks are those of their owners.