Clusterweites Batch-System
OpenVMS verfügt über ein einzigartiges System zur Kontrolle und Verwaltung von Batchjobs. Jeder Knoten im Cluster kann Jobs in jede beliebige, im Cluster verfügbare Queue stellen.
OpenVMS bietet dazu ein zweistufiges Konzept mit "Generic-Queues" und "Execution-Queues" an.
- Jobs können in Generic-Queues submitted werden.
- Eine beliebige freie Execution-Queue, die einer Generic-Queue zugeordnet ist, übernimmt die Ausführung des Batch-Jobs.
Es ist vorab nicht festgelegt, auf welchem Clusterknoten der Job aus der Generic-Queue laufen wird. OpenVMS übernimmt die Verteilung auf eine "passende" Execution Queue.
"Was bringt mir das?"
Batchverarbeitung und Job-Scheduling ist ein zentraler Bestandteil jeder Systemlandschaft.
Das OpenVMS Queue-System ermöglicht die Verteilung von Batchjobs auf alle verfügbaren Knoten im Cluster. Es steht uns damit ein ausfallsicheres, desaster-tolerantes und verteiltes Batch-Verarbeitungs-Environment zur Verfügung.
Clusterweites Filesystem
Das clusterweitere Filesystem ermöglicht Prozessen, die auf verschiedenen Knoten des Cluster laufen, gleichzeitigen Zugrif auf Dateien bei gleichzeitiger Sicherstellung der Datenintegrität.
Alle Clusterknoten haben auf alle Disken im Cluster die gleichen Zugriffsmöglichkeiten. Sie können die gleichen Dateioperationen auf ein und die selbe Disk (ein und das selbe Filesystem) gleichzeitig durchführen. Es kommt dabei keinerlei "Fileserving"-Funktionalität zum Einsatz. Der Distributed-Lock-Manager koordiniert dabei den Zugriff auf die Dateien oder einzelne Datensätze in den Datendateien.
"Was bringt mir das?"
Alle Knoten im Cluster haben gleichzeitigen, gleichartigen und gleichberechtigten Zugriff auf alle Disken und Dateien, das ist die effizienteste Art von Resourcen-Sharing und Sicherstellung der Datenintegrität.
Der Cluster als Fundament
Auf den Punkt gebracht: Echtes 24x7 Computing.
Wir ein Clusterknoten heruntergefahren, haben alle verbleibenden Knoten im Cluster nach wie for Zugriff auf alle Applikationen und Daten. Es gibt keinen "Single-Point-of-Failure", der den Ausfall Ihrer Applikation bedeutet. In einem OpenVMS Cluster kann jede CPU unabhängig arbeiten, profitiert aber von allen gemeinsam verfügbaren Ressourcen wie Storage, Bandlaufwerke oder auch Batch- und Print Queues. Wird ein einzelnes System in einem traditionellen Environment oder in einem der vielen anderen "sogenannten Cluster-Systemen" heruntergefahren, stehen die Informationen, die auf diesem System verwaltet werden, im Netzwerk nicht mehr zur Verfügung. Und oftmals bedeutet jede Minute Downtime enorme finanzielle Ausfälle.
Leistungsstarker Distributed Lock Manager
Der "Distributed Lock Manager" ist das Herzstück jedes OpenVMS Clusters.
Er wird von nahzu allen Komponenten des Betriebsystems verwendet und ist gleichzeitig auch für den Applikationseinsatz verfügbar. Alle Dateioperationen, unabhängig davon, ob sie RMS oder datenbankbasierend sind, werden vom Lock Manager koordiniert.
Der Lock Manager stellt alle Funktionalitäten in einer zukunfsweisenden Implementierung zur Verfügung:
- Asynchrone I/O
- Asynchrone Lock Notification
- Deadlock Detection
- Lock Trees
- Lock Quotas
- Dynamisches Re-Mastering
- Value Blocks
- und viele mehr
Die Disk-Cache-Kohärenz des Distributed Lock Managers stellt in einzigartiger Weise die Konsistenz von verteilten und geteilten Resourcen sicher.
"Was bringt mir das?"
Koordinierter Plattenzugriff ermöglicht skalierbare Environments: Die Leistungsfähigkeit eines Applikationssystems kann einfach durch das Hinzufügen von Servern und Rechenleistung gesteigert werden.
Der Distributed Lock Manager bietet die Möglichkeit, Resourcen in einer Cluster-Umgebung gemeinsam zu nutzen. So können Applikationen auf einfache Art und Weise parallel und im Verbund betrieben werden. Jeder Clusterknoten kann seine Resourcen im Cluster bereitstellen und gleichzeitig auf alle im Cluster bereitgestellten Resourcen zugreifen, unabhängig davon, ob es sich um Disk-Devices, Dateien oder einzelne Records in einer Datei handelt. Gleichzeitig verhindert das System sogenannte "Split-Brain" Situationen, in denen die auf mehreren Seiten des Clusters exisiterenden Versionen eines Datenbestandes nicht mehr exakte Duplikate von einander darstellen.
"Split Brain", also "geteiltes Gerhirn", wird diese Situation deshalb genannt, weil zwei oder mehrere Seiten des Clusters (des Gehirns) am Leben sind und von den jeweils anderen Seiten nicht wissen, in welchem exakten Zustand sich diese befinden. Wenn sich der Cluster in einem "Split-Brain" Zustand befindet, verliert er die Möglichkeit, im Fehlerfall die Arbeit der ausgefallenen Clusterknoten zu übernehmen und an der Stelle wieder aufzusetzen, an der ein Clusterknoten ausgefallen ist.
In Nicht-OpenVMS-Clusterumgebungen führt dieses Phänomen oft zu stundenlangen, beschwerlichen Resynchronisierungsarbeiten, bis ein einheitlicher, gemeinsamer und gültiger Datenbestand wieder herzustellt werden kann.