BS2000/OSD Scope Kapitel 6...

BS2000/OSD Scope Kapitel 6 Systemsoftware

Ausgabe Februar 2013

Produkt BS2000/OSD

Verteiler Extern

Seiten 17

Einleitung Die Weiterentwicklung des BS2000/OSD gilt dem Ausbau seiner mainframe-typischen Stärken unter gleichzeitiger Nutzung heutiger und zukünftiger technologischer Möglichkeiten. Dadurch wird auch in Zukunft BS2000/OSD erste Wahl sein für den hochleistungsfähigen OLTP- und Data Center-Betrieb, sowie auch als Server in beliebigen Netzen.

Höchstverfügbarkeit wird mit dem HIPLEX-Konzept erreicht.

Durch Virtualisierung werden Applikationen und zugehörige Daten von dedizierten Hardware Ressourcen entkoppelt. Das virtuelle Maschinensystem VM2000 ermöglicht eine flexible, lastorientierte Aufteilung der Ressourcen eines Servers in mehrere parallel laufende Systeme, die voneinander unabhängig sind und mit unterschiedlichen Systemversionen betrieben werden können.

Inhalt

Einleitung 1 6.1 Überblick 2 6.2 Betriebssystem BS2000/OSD 2

6.2.1 Hardware-Unterstützung 2 6.2.2 Skalierbarkeit 4 6.2.3 Verfügbarkeit 5 6.2.4 Security 6 6.2.5 Storage-Integration 8 6.2.6 Manageability und Ease of Use 9 6.2.7 Offenheit und Integrationsfähigkeit 10

6.3 Highly Integrated System Complex HIPLEX 12 6.3.1 Hochverfügbarkeit mit HIPLEX 12 6.3.2 Die Produkte HIPLEX MSCF und HIPLEX AF 13

6.4 Virtuelles Maschinen-System VM2000 14 6.4.1 Nutzungs-Szenarien 14 6.4.2 VM2000-Versionsübersicht 15 6.4.3 VM2000-Konzept für SQ-Server 16 6.4.4 Funktionserweiterungen der neuen VM2000-Version 17

Summary Ausgabe: Februar 2013 BS2000/OSD-Scope – Kapitel 6 Systemsoftware Verteiler: Extern Seite 2 / 17

6.1 Überblick

Moderne IT - Systeme müssen ein Höchstmaß an Sicherheit, Zuverlässigkeit, Skalierbarkeit und Performance erreichen. Gleichzeitig soll durch Offenheit die hohe Flexibilität und leichte Integration aller Geschäftsprozesse möglich sein. Die bewährten Mainframe-Eigenschaften – unübertroffene Ausfallsicherheit, hervorragende Sicherheitskonzepte, exzellente Skalierbarkeit und ausgezeichnete Manageability– sind wichtiger denn je. Sie bilden die Basis für die anerkannt niedrige TCO (Total Cost of Ownership) des BS2000/OSD. Mit seinen umfassenden Leistungen und Funktionen unterstützt BS2000/OSD vorhandene und neue IT-Infrastrukturen optimal. BS2000/OSD wird seit vielen Jahren kontinuierlich innoviert und an ständig wechselnde Marktanforderungen angepasst. So läuft BS2000/OSD als Mainframe-Betriebssystem auf Servern mit Standardprozessoren. Und es bietet mit seinen offenen Schnittstellen die zukunftssichere Integrierbarkeit in moderne Anwendungsarchitekturen. Ein strategischer Entwicklungsschwerpunkt ist die Kombination bewährter BS2000/OSD- und offener Standardtechnologie unter Wahrung der Kompatibilität. Dazu gehören gemeinsame, offene Standardschnittstellen, sowie gemeinsam einsetzbare, offene Middleware (openUTM, WebTransactions, Oracle). Die umfassende Skalierbarkeit der BS2000/OSD - Plattform bis in höchste Leistungsbereiche stellt sicher, dass BS2000/OSD-Kunden flexibel auf steigende Anforderungen an die Gesamtsystemleistung reagieren können. Die Architektur ist hinsichtlich Höchstleistung optimiert, sodass mehrere zehntausend Clients gleichzeitig, effizient und mit hoher Verfügbarkeit betrieben werden können. Höchstverfügbarkeit wird mit dem HIPLEX-Konzept erreicht. In ihm realisieren mehrere BS2000/OSD-Server einen Failover-Verbund: Bei Serverausfall oder temporärer geplanter Nicht-Verfügbarkeit eines Servers werden Anwendungen automatisch oder nach Anweisung auf einen anderen Server verlagert. Das virtuelle Maschinensystem VM2000 eröffnet für BS2000/OSD-Kunden eine weitere Dimension der Skalierbarkeit und Verfügbarkeit. VM2000 ermöglicht eine flexible, lastorientierte Aufteilung eines Servers in mehrere parallel laufende Systeme, die voneinander unabhängig sind und mit unterschiedlichen Systemversionen betrieben werden können. Diese Systeme können einerseits IT-Teilprozessen (Produktion, Entwicklung, Test etc.) zugeordnet werden und andererseits abgrenzbaren Teil-Geschäftsprozessen bis hin zum Einsatz für Outsourcing mit Kunde/System-Zuordnung. Das Hochverfügbarkeitskonzept mit Failover funktioniert natürlich auch für die einzelnen VM2000-Gastsysteme. Die volle Kompatibilität von Programmen im Objekt-Code sichert Software-Investitionen langfristig. Diese Kompatibilität wird von BS2000/OSD garantiert und ist selbstverständlich auch über die unterschiedlichen, von BS2000/OSD unterstützten Serverlinien gegeben. Investitionssicherheit, exzellente Skalierbarkeit und hohe Verfügbarkeit bedeuten für BS2000/OSD-Anwender das sprichwörtliche „Wachsen ohne zu wechseln“.

6.2 Betriebssystem BS2000/OSD

6.2.1 Hardware-Unterstützung

BS2000/OSD unterstützt die jeweils neuesten BS2000/OSD-Business Server und Peripherie-Komponenten binärkompatibel im /390-Standard. Der Hauptspeicherausbau der BS2000/OSD-Business Server kann sich bis in den Terabyte-Bereich erstrecken. Die Multiprozessor-Fähigkeit des BS2000/OSD kann auch zweistellige Prozessor-Zahlen effizient unterstützen. Diese Leistungsfähigkeit wird kontinuierlich ausgebaut. Server-Unterstützung: Neue S-Server S175 und S210 BS2000/OSD-BC V9.0 unterstützt die neuesten Server S175 und S210 der S-Serie. Im oberen Leistungsbereich bedient

BS2000/OSD-BC V9.0 damit /390-Architektur-basierte BS2000/OSD-Server mit einer Leistung bis zu 5.000 RPF (siehe Kapitel 7). Die Server S175 und S210 sind auch für den Einsatz unter BS2000/OSD-BC V7.0 und V8.0 freigegeben. Fibre Channel Connectivity an BS2000/OSD-Business Servern der S-Serie

An den S-Servern wurde der Fibre Channel-Anschluss Ende 2002 beginnend mit den Modellen S120/S140/S170 mit der BS2000/OSD-BC V5.0B eingeführt. Er ist inzwischen für alle aktuellen S-Server-Modelle verfügbar und ist auch bei den aktuellen Servern S175 und S210 standardmäßig vorhanden. Alle angebotenen Online- und Nearline-Peripheriegeräte für BS2000/OSD-Server der S-Serie bieten Fibre Channel-Anschluss. Die BS2000-Netzanbindung wird mit dem HNC IV oder HNC V über Fibre Channel realisiert. Die Fibre Channel-Anschlusstechnik zeichnet sich durch hohe Übertragungsraten und extrem kurze Antwortzeiten aus. Sie ermöglicht die Integration der Server in ein Enterprise Storage Area Network (SAN) und damit auch eine Einbindung der Server in eine Storage-Konsolidierung auf der Basis modernster Verbindungsstandards. Mit dem Fibre Channel-Anschluss wurden an S-Servern Durchsatzwerte bis zu 95 MB/s gemessen. Wegen der deutlichen Performanceverbesserung vereinfacht sich auch die I/O-Konfiguration wesentlich, da ein Fibre Channel-Kanal im Mittel vier ESCON-Kanäle ersetzt. Ein besonderer Vorteil der SAN-Einbindung liegt darin, dass die Speichersysteme über ein homogenes Fibre Channel-Netz auch von mehreren, verschiedenartigen Servern gemeinsam genutzt werden können. Es wird nur eine einzige, gemeinsame SAN-Infrastruktur benötigt. Kunden, die noch das CKD-Plattenformat einsetzen, müssen ihren Datenbestand in das FBA-Format überführen, wenn sie die Vorteile des Fibre Channels nutzen wollen. Um die hierfür nötige Betriebsunterbrechung zu vermeiden, wird mit DRV ab V3.1

eine Funktionserweiterung angeboten, welche den Konvertierungsvorgang online und automatisiert im Hintergrund abwickelt.


Server-Unterstützung : Business Server der SQ- und SX-Serie

Die BS2000/OSD-Server der SQ-Serie decken aktuell den BS2000/OSD-Einstiegs- und Midrange-Leistungsbereich ab. Die SQ-Server basieren auf High End Intel-Servern und bauen in ihrer Softwarestruktur auf die erfolgreichen SX-Server mit SPARC64-Prozessoren auf. Für den Ablauf des BS2000/OSD und seiner Anwendungen auf Intel- und auf SPARC64-Prozessoren fungiert die HW-Abstraktions-Schicht X2000 als Trägersystem. Aus einem gemeinsamen Source des Betriebssystems BS2000/OSD-BC werden drei Code-Varianten für Business Server mit /390-Prozessoren, für Business Server mit Intel-Prozessoren und für Business Server mit SPARC64-Standard-Prozessoren erzeugt. Der volle Schutz der Kunden-Investitionen wird durch Objektkompatibilität für alle existierenden Anwendungen und Middleware-Produkte im /390-Objektcode sichergestellt. BS2000/OSD-BC wird jeweils für die Business Server der SQ- und SX-Serie als Bestandteil des OSD Extended Configuration-Pakets OSD/XC freigegeben. Basierend auf BS2000/OSD-BC V8.0 steht die Paketversion OSD/XC V4.1 zur Verfügung. Ab der Version OSD-BC V9.0 gibt es das Paket OSD/XC V9.0. Dieses steht ausschließlich für SQ zur Verfügung. SX Server nutzen

weiterhin das Paket OSD/XC V4.1. Das OSD/XC-Paket enthält folgende Software-Produkte:

Funktionsbereich Produktname Version in OSD/XC V4.1

Version in OSD/XC V9.0

Betriebssystem BS2000/OSD-BC V8.0 V9.0

Open Networking openNet Server V3.4 V3.5

TIAM V13.2 V13.2

Daten-/Programm-Management CRTE V2.8 V2.9

EDT V17.0 V17.0

LMS V3.4 V3.4

PERCON V2.9 V2.9

SCA V17.0 V18.0

SORT V7.9 V7.9

Backup und Datensicherung ARCHIVE V9.0 V9.0

HSMS V9.0 V9.0B

Printing / Batchjobabwicklung JV V15.0 V15.1

RSO V3.6 V3.6

OSD/XC V9.0 unterstützt auch die neueste SQ-Servergeneration. Mittels der zugehörigen Version des Trägersystems X2000 bietet sie eine erhebliche Steigerung in der Multiprozessorleistung und damit eine wesentlich erweiterte Systemskalierbarkeit (siehe Kapitel 7).

Bild 1: Überblick Speicherarchitektur mit Fibre Channel (FC)


Ausblick

BS2000/OSD-BC V9.0 enthält unter anderem Optimierungen im Memory Management und ist dadurch auch auf die Unterstützung kommender Servergenerationen vorbereitet. Die Unterstützung neuer Peripherie wird durch BS2000/OSD-BC V9.0 ausgeweitet und auch nach der Freigabe durch Anpassungen und Regressionstests fortgeführt.

6.2.2 Skalierbarkeit

Die Skalierbarkeit der BS2000/OSD-Systemplattform bis in höchste Leistungsbereiche stellt sicher, dass Betreiber flexibel auf steigende Anforderungen an Serverleistung reagieren können. Serverleistung, Netzbandbreite und Datenhaltung sind so konfigurierbar, dass mehrere 10.000 Endbenutzer quasi gleichzeitig effizient bedient werden können. Der Leistungsbereich des Servers umfasst einen Faktor von über 400, gemessen in RPF (Relativer Performance Faktor): von der SQ210 mit 12 RPF bis zur S210 mit 5.000 RPF. Immer größere Peripherie-Konfigurationen speichern die stetig anwachsenden Datenmengen. Bei der Weiterentwicklung wird das Design des Betriebssystems so ausgelegt, dass steigende Leistungsanforderungen problemlos erfüllt werden können. In der aktuellen Version BS2000/OSD-BC V9.0 sind wiederum Maßnahmen zur Performancesteigerung des BS2000-Betriebs

erfolgt: Performante Unterstützung der SQ-Server bis MP-Grad 16

Ziel aller zur BS2000/OSD-BC V9.0 freigegebenen Performancemaßnahmen für SQ-Server war es, für die MP-Grade 8 bis 16 einen gleich guten MP-Faktor zu erreichen wie bei S-Servern. Hauptansatz zur Steigerung der MP-Performance bei SQ war die Durchführung von x86-Page Table Optimierungen. Darüber hinaus erfolgte in der OSD V9.0 das Reference Recording auf SQ-Servern nur „on Demand“. Durch die Maßnahmen wurde eine Performanceverbesserung von 5 - 10% bei Mono, 10 – 20% bei Multi-Prozessoren erreicht.

Erhöhung der Anzahl paralleler RSC-I/Os pro Gerät von 4 auf 6 Über RSC wurden bislang standardmäßig 4 I/Os gleichzeitig auf ein Gerät ausgegeben. Zur Steigerung der I/O-Parallelisierung wurde dieser Wert in der OSD V9.0 auf 6 erhöht.

Formale Unterstützung von bis zu 32 Prozessoren (als Vorleistung für spätere leistungsstarke SQ-Server) Ab OSD V9.0 ist auf SQ-Maschinen die formale Unterstützung von bis zu 32 Prozessoren möglich (bislang maximal 16 CPUs); da derzeit kein konkretes SQ-Modell mit >16 CPUs geplant ist, ist die Erweiterung als Vorleistung für spätere leistungsstarke SQ-Server gedacht.

Extended PAV Mit PAV (Parallel Access Volume) können mehrere I/Os gleichzeitig auf ein logisches Volume erfolgen. Mit PAV lassen sich die Antwortzeiten bei stark ausgelasteten Platten reduzieren sowie die maximalen I/O-Raten auf ein Volume erhöhen. Mit Extended PAV für Geräte am FC-Kanal wird die bisherige Einschränkung, dass ein Alias-Gerät in derselben logischen Steuerung wie das Basis-Gerät liegen muss, aufgehoben. Zu einer vorhandenen logischen Steuerung kann eine weitere logische Steuerung (bei Bedarf auch mehrere) mit 256 Alias-Geräten dazu konfiguriert werden. Extended PAV schafft damit höhere Flexibilität bei (unvorhergesehenen) Engpässen und eignet sich insbesondere für Konfigurationen, in denen PAV nicht von Anfang an eingeplant wurde, in denen keine oder nur wenige freie Adressen für Alias-Geräte zur Verfügung stehen.

Parallelisierung der Paging-I/Os mit PAV Beim Erzeugen hoher Datenmengen im Hauptspeicher in kurzer Zeit muss der Paging-Mechanismus den Hauptspeicherinhalt mit gleicher oder gar höherer Geschwindigkeit verdrängen, wie neue Daten erzeugt werden. Um dies auch bei ständig zunehmender Serverleistung sicher zu stellen, wurde in der BS2000/OSD-BC V9.0 eine Parallelisierung von Paging-I/Os vorgenommen. Somit können bis zu 4 I/Os pro Gerät parallel durchgeführt werden.

Verbesserte PTHREADS-Performance Die Performance für fork() in PTHREAD-Anwendungen wird mittels Einführung der "copy-on-write Semantik" für den CL6-Memory-Pool der PTHREADS verbessert. Diese Verbesserungen kommen Kunden mit SHC-OSD-Konfigurationen, dem ORACLE EMAGENT und SM2-Nutzern zugute.


6.2.3 Verfügbarkeit

Für die IT-Prozesse, die das E-Business unterstützen, besteht die Forderung nach permanenter Verfügbarkeit aller involvierten IT-Ressourcen. Viele Branchen wickeln ihre unternehmenskritischen Prozesse inzwischen vollkommen IT-basiert ab. Auch dabei wächst die Bedeutung von Hochverfügbarkeit laufend. Verfügbarkeit war daher schon immer ein Entwicklungsschwerpunkt für BS2000/OSD und wird es auch weiterhin sein. Heute ist für das Betriebssystem und die systemnahen Komponenten bereits ein hoher Stand der Verfügbarkeit erreicht: Funktionen zur Vermeidung/ Verkürzung geplanter Betriebsunterbrechungen (Self-configuring- Eigenschaften des BS2000/OSD):

Online-Wartung / -Austausch von Hardware-Komponenten: Service-/ Konsol-Prozessor, Peripherie, ESCON-Kanäle, Firmware und Lüfter sind im laufenden Betrieb austauschbar. Dynamische Änderung der HW-Konfiguration: Die BS2000/OSD Business Server mit /390-Architektur bieten hardwaremäßig

die Möglichkeit, die I/O-Konfiguration im laufenden Betrieb, d.h. ohne neuen IPL, zu modifizieren. BS2000/OSD unterstützt diese Funktion auch softwareseitig, indem für freigegebene I/O-Komponenten (Kanäle, System-Connection-Directors (SCDs), Gerätesteuerungen und Geräte) dynamisch neue Einträge aufgenommen bzw. Einträge verändert und gelöscht werden können.

Dynamische Änderung der Betriebssystem- Einstellungen: I/O-Pfade, Datum/Zeit, Benutzer-Einträge, Job- Management-Einträge, Netz-(BCAM-) Einträge, FT-Partner-Definitionen, Pubset-Zuordnungen, Katalog-Größe, Paging-Dateien, POSIX-Systemparameter können im laufenden Betrieb geändert werden.

Dynamische Änderung der Software-Konfiguration: Mit IMON/DSSM ist das Einspielen neuer Produkt- / Subsystem-Versionen im laufenden Betrieb möglich.

Datensicherung via Concurrent Copy: Die Anwendungsunterbrechung kann auf die Erzeugung des Konsistenz-Punktes beschränkt werden, indem die Sicherung durch die Concurrent Copy-Funktion von HSMS durchgeführt wird. Die HSMS-Sicherung mit Concurrent Copy unterstützt ETERNUS DX EquivalentCopy, Symmetrix TimeFinder und CLARiiON CX SnapView. Dabei werden die Daten während des Sicherungslaufs von den abgetrennten Volumes gelesen.

Reorganisation offener Dateien und online Vergrößerung von Volumes in Verbindung mit SPACEOPT ab V3.0. Funktionen zur Vermeidung / Verkürzung ungeplanter Systemunterbrechungen (Self-healing-Eigenschaften des BS2000/OSD):

Ausfall von Hardware-Komponenten: Fehler der Hardware-Komponenten werden automatisch erkannt und fehlerhafte Prozessoren, Speicherbereiche, Kanäle, IOPs werden (bei Redundanz) im Allgemeinen ohne Betriebsunterbrechung auskonfiguriert. Fehlerhafte Peripherie kann im laufenden Betrieb ausgetauscht, fehlerhafte I/O-Pfade können umdefiniert werden. Bei Druckerausfall können Spool-Jobs via DPRINT auf Ersatz-Drucker gelenkt werden

Schutz gegen Fehler im Anwender- Programm: Anwendungsprogramme werden gegeneinander und gegen die Middleware (UDS/SQL, SESAM/SQL-Server, Oracle) isoliert: Bei Fehlern im Anwender-Programm bricht nur die betroffene Transaktion, nicht aber die Gesamt-Anwendung ab.

Verkürzung des System-Wiederanlaufs: Die Warteschlangen von Batch, openFT und Spool-Jobs werden beim Restart automatisch weiter abgearbeitet.

Größere Spool-Jobs können an Checkpoints wieder aufgesetzt werden. Automatisierung des Wiederanlaufs: openUTM, Datenbanken, DSSM u.a. hinterlegen laufend Status-Informationen in Job-

Variablen, die über Automatisierungsprozeduren ausgewertet werden können. Alle aktuellen S-Server-Modelle, insbesondere auch die neuen Server S175 und S210 sind mit einem Ersatz-

Verarbeitungsprozessor, einer so genannten Hot Spare-CPU ausgestattet. Bei Ausfall eines Verarbeitungsprozessors wird die Hot Spare-CPU im laufenden Betrieb aktiviert und der Betrieb mit der ursprünglichen, modellspezifischen Leistung fortgesetzt. Dies gilt auch im Fall von Monoprozessor-Anlagen, wenn die einzige CPU der Anlage ausfällt.

Für HIPLEX-Konfigurationen mit Global Storage bietet BS2000/OSD-BC Rekonfigurationsfunktionen, mit denen eine unterbrechungsfreie Wiederinbetriebnahme der GS-Units auch nach Stromausfällen oder anderen Katastrophenszenarien gewährleistet ist.

Journaling file system in POSIX ab A37. Beschleunigung der Ausfall-Erkennung im Verbund mit HIPLEX MSCF ab V4.0 und HIPLEX AF V3.2. Bei der BS2000/OSD-Weiterentwicklung kommt der weiteren Steigerung der Systemverfügbarkeit höchste Bedeutung zu. In BS2000/OSD-BC V9.0 sind weitere Entwicklungen zur Erhöhung der Verfügbarkeit enthalten:

Online SNAP-File-Einrichtung (+ Erweiterung des Speicherabzugs)

Bisher konnte der Snapshot-Prozess nur beim Systemstartup über die Parameterdatei aktiviert bzw. deaktiviert werden. Ist in der laufenden Session ein Fehler aufgetreten, so wurde meistens der Snapshot-Prozess gestoppt. Ein erneutes Anstarten war nur durch einen kompletten Systemneustart möglich. Auch die Größe der $TSOS.SNAPFILE (Datencontainer für den Snapshot-Prozess) konnte bisher nicht verändert werden. In der OSD V9.0 kann der Snapshot-Prozess in der laufenden Session beliebig oft gestoppt, wiederangefahren, neu initialisiert werden. Dabei werden auch veränderte Randbedingungen wirksam, z.B. eine Größenänderung der $TSOS.SNAPFILE. Dazu werden neue Kommandos ACTIVATE-SNAPSHOT und DEACTIVATE-SNAPSHOT zum Ein/Ausschalten der SNAP-Dump-Funktion angeboten. Durch Änderungen des Speicherabzugs wird die Diagnose-Unterstützung verbessert:


Online-Update der Change-Dates für Sommer- und Winterzeit

Die Umschaltzeitpunkte zwischen Sommer- und Winterzeit wurden bislang in der nur vom Startup eingelesenen und ausgewerteten SYSPAR-Datei für maximal drei Jahre im Voraus festgelegt, weil auch die zuständige staatliche Behörde die Umschaltzeitpunkte nur für einen solchen Zeitraum im Voraus festlegt. Zur Pflege/Erweiterung der Umschaltzeitpunkte war die Datei SYSPAR.BS2.<ver> für den Bereich "GTIME" zu editieren (klassische Aufgabe eines Systemverwalters). Für eine Modifikation der Umschaltzeitpunkte war bisher nach höchstens drei Jahren ein Restart des Systems – und damit eine Betriebsunterbrechung –notwendig. Mit OSD V9.0 können nun neue/geänderte Umschaltzeitpunkte dem Betriebssystem per Kommando bekannt gemacht werden. Ein Restart des Systems ist dafür nicht mehr notwendig. Die Funktion wird als neues Subsystem "CHDATES" mit den Kommandos ADD-, /MODIFY-, /REMOVE-, /SHOW-CHANGE-DATES angeboten. Damit ist keine Betriebsunterbrechung / kein STARTUP mehr notwendig (7 * 24-h-Betrieb). Bei Gesetzesänderungen im Hinblick auf Sommer- und Winterzeit kann schnell reagiert werden. Online Sicherung des Home Pubsets mit FDDRL V18.0

Die physikalische Sicherung des Home-Pubsets mit FDDRL hat gegenüber der logischen Sicherung mit ARCHIVE/HSMS den Vorteil, dass die IPL-Fähigheit, die Pubset-Attribute, die gesamte Softwarekonfiguration und die Benutzer-Attribute gesichert und bei der Restaurierung wiederhergestellt werden. Ein mit FDDRL restauriertes Pubset kann sofort wieder in Betrieb genommen werden. Demgegenüber muss ein mit HSMS/ARCHIVE gesichertes HOME-Pubset erst wieder aufgebaut und eingerichtet werden. Im Hinblick auf eine schnelle und zuverlässige Restaurierung des Home-Pubsets ist die Sicherung mit FDDRL unerlässlich und wird deshalb dringend empfohlen. Weil die Softwarekonfiguration recht konstant ist und nicht jeden Tag geändert wird, reicht es, eine FDDRL-Sicherung in größeren Abständen z.B. monatlich durchzuführen. Um das Home-Pubset mit FDDRL zu sichern, musste bisher jedoch der Systemlauf beendet werden. Dann konnte das Home Pubset mit einem anderen System offline gesichert werden. Mit FDDRL V18.0 kann jetzt die Home-Pubset-Sicherung im laufenden. Betrieb erfolgen.

6.2.4 Security Verlässlicher Datenschutz ist eine wesentliche Voraussetzung beim Einsatz von Systemen in der kommerziellen Datenverarbeitung. Unternehmenskritische Daten müssen gegen vorsätzliche und besonders gegen fahrlässige Modifikation oder Zerstörung wirksam geschützt sein. Ein solcher Datenschutz wird sowohl in der System-Plattform BS2000/OSD als auch in der zugehörigen Middleware angeboten. BS2000/OSD verfügt bereits heute über funktionsmächtige Self-protecting-Eigenschaften.

BS2000/OSD in Verbindung mit dem Produkt SECOS (Security Control System) entspricht der Klasse F2/Q3-Zertifizierung des Bundesamtes für Sicherheit in Informationssystemen.

Bild 2: Basis-Sicherheit im Betriebssystem, erweiterte Sicherheit mit SECOS


SECOS bietet folgende Funktionen:

Erweiterte Zugangskontrolle durch verbesserte Identifikation und Authentisierung der Benutzer: Dadurch wird im

BS2000/OSD sichergestellt, dass nur berechtigte Benutzer mit dem System arbeiten und für unberechtigte Benutzer der Zugang verhindert wird. Im BS2000/OSD wird der Passwortmechanismus zur Authentisierung beim Zugang zum System verwendet. Mit SECOS stehen für LOGON-Passworte Schutzmaßnahmen zur Verfügung, die ein systematisches Ausprobieren im praktischen Betrieb wirkungsvoll verhindern. Bei gemeinsam benutzten Kennungen dient das „Persönliche LOGON“ zur Identifizierung.

Zugriffskontrolle bei Objekten (u.a. Dateien): Mit SECOS stehen erweiterte Schutzmechanismen zur Verfügung, die auf unterschiedliche Weise die Mehrbenutzbarkeit von Dateien und die Zugriffsrechte regeln. Die Zugriffskontrollliste erlaubt die Definition von Zugriffsrechten bis auf die Ebene von Einzelbenutzern; die festlegbaren Zugriffsarten umfassen Lesen, Schreiben und Ausführen. Mit einem GUARD können Zugriffsrechte für mehrere Objekte gleichermaßen festgelegt werden. Dies hat den Vorteil, dass mit einfachem Handling mehrere Objekte mit den gleichen Zugriffsrechten versehen werden können. Standardeinstellungen von Schutzattributen ermöglichen es, Objekte bereits zum Erstellzeitpunkt wirksam zu schützen.

Unterstützung von Benutzergruppen: Damit kann die Vielzahl von Benutzern, die im System vorhanden sind, übersichtlicher strukturiert werden. Außerdem ist es möglich, organisatorische Einheiten oder Projekte, die durch bestimmte Personen mit Benutzerkennungen dargestellt werden, auch mit der entsprechenden Betriebsmittelzuordnung im System nachzubilden.

Mechanismen zur erweiterten Rechteverwaltung / Dezentralisierung der Systemverwaltung: So können unterschiedliche Administrationsaufgaben der privilegierten Benutzerkennung TSOS auf mehrere andere Benutzerkennungen verteilt werden. Die Funktion Miteigentümerschaft dient der Dezentralisierung von Aufgaben. Sie erlaubt, die Administrationsrechte, wie Anlegen und Löschen von Objekten, die einer beliebigen Benutzerkennung gehören, einer anderen Benutzerkennung (als der Systemverwaltung) zuzuordnen. Die spezielle Funktion TSOS-Miteigentümerschaft schränkt das Recht eines Benutzers unter der Kennung TSOS, auf Dateien bzw. Jobvariablen einer beliebigen Benutzerkennung zuzugreifen, gezielt auf einzelne Dateien / JVs ein.

Beweissicherung/Protokollierung sicherheitsrelevanter Ereignisse: „Security Audit Trail“ (SAT) als Bestandteil des Produktes SECOS unterstützt die selektive Protokollierung von sicherheitsrelevanten Ereignissen in besonders geschützte Dateien. Mit Auswertung dieser Dateien erhalten entsprechend autorisierte Benutzer einen lückenlosen Überblick, welcher Benutzer zu welchem Zeitpunkt in welcher Art und Weise auf ein bestimmtes Objekt zugegriffen hat. Die SAT-Ausgaben können wahlweise auch im XML-Format für Folgeverarbeitung erfolgen.

Single Sign On mit Kerberos Mittels Kerberos-Authentifizierung wird BS2000-Anwendern die Möglichkeit geboten, die Benutzeranmeldungen (LOGON) im Sinne eines Single Sign On ohne Kennwort-Angabe durchzuführen. Es wurde ein Kerberos Client im BS2000/OSD realisiert, der den (in der Regel) im BS2000-Umfeld existierenden Windows Primary Domain Controller (PDC) als Server (Key Distribution Center) benutzt. Vorteile für den Kunden sind: - Keine zusätzlichen HW/SW-Kosten durch Nutzung des Windows PDC als Authentisierungsserver. - Kerberos-Protokolle bieten hohe kryptografische Sicherheit. Auf der Client-Seite ist die Unterstützung der Kerberos-Authentifizierungsfunktion in der Terminal-Emulation MT9750 ab V6.0

sowie in weiteren Emulationen von SW-Partnern erfolgt, Die Kerberos-Authentisierungs-Funktionalität steht auch für TU-Anwendungen zur Verfügung. Nutzer dieser Möglichkeiten sind die Produkte OMNIS-MENU ab V3.4 (in Kombination mit OMNIS ab V8.4) und openUTM ab V5.3.

Security Audits unter Einbeziehung von BS2000/OSD Business Servern

Immer mehr Kunden wollen ihr Data Center einem "Security-Audit" unterziehen. Dabei erstellt ein Unternehmen selbst Sicherheits-Richtlinien und lässt diese und ihre Einhaltung durch einen internen oder externen Auditor evaluieren. Der Anlass, einen Security-Audit durchzuführen, kommt meist von außerhalb des Unternehmens, den Rahmen stecken dabei gesetzliche Bedingungen wie das Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) in Deutschland oder der Sarbanes-Oxley Act in den USA. Die Sicherheitsrichtlinien können sich, analog zum Qualitätsmanagement, auf ISO-Standards stützen, insbesondere auf ISO/IEC 27001 mit dem Titel "Information technology - Security techniques - Information security management systems - Requirements". Speziell in Deutschland hat das Bundesamt für Sicherheit in der Informationstechnik in Form des IT-Grundschutzhandbuchs dazu umfangreiche Ausführungsbestimmungen geschaffen und bietet dafür einen eigenen Zertifizierungsprozess an. Die BS2000/OSD Business Server können mit ihren Sicherheitsfunktionen erfolgreich in Security Audits einbezogen werden. Das Betriebssystem BS2000/OSD-BC enthält per Default umfangreiche Sicherheitsmechanismen. SECOS ermöglicht eine erweiterte, feingranulare Steuerung der Sicherheitsmechanismen; SECOS hat im ISO27001-Umfeld die wichtigen Funktionen Beweissicherung, Persönliches Login auch unter Systemverwalterkennungen, Sicherstellung der Integrität der Systemdateien (auch über SAT-Logging realisiert). Für die SX- und SQ-Server ist zusätzlich ein Sicherheits-Konzept in X2000 verfügbar, das auf SQ-Servern standardmäßig zum Einsatz kommt; für SX-Server wurde dessen Einsatz im Rahmen der Installations-Checkliste abgefragt. Zur Unterstützung unserer Kunden bei Security Audits bieten wir auf Projektbasis Know How und Manpower an.


Funktionserweiterungen in SECOS V5.3 (aktuelle Version):

Das Subsystem GUARDS realisiert einen Zugriffsschutzmechanismus für Objekte unterschiedlichen Typs. Die Schutzkriterien werden dabei zentral im System verwaltet und die Schutzdefinitionen, bezogen auf ein bestimmtes Objekt, in einem so genannten Guard zusammengefasst. Für jeden Guard-Container ist ein fester Bereich für die Zugriffsbedingungen vorgesehen. Dieser Bereich wird jetzt vergrößert. Damit sind weitere Nutzungsszenarien für Guards möglich, z.B. die Nutzung für den LOGON-Zugang über Personal-ID (Hier können derzeit nur knapp 90 Einträge verwaltet werden).

Kerberos-Keys, die im Key Distribution Center per z.B. ktpass eingetragen werden, mussten bislang händisch in‘s BS2000 eingetragen werden. Dies hat oft zu Fehleinstellungen geführt. In der SECOS V5.3 kann die ktpass-file direkt ausgewertet werden. Dies reduziert die Gefahr der Fehlbedienung deutlich.

Ausblick In der Folgeversion SECOS V5.4 werden schwerpunktmäßig Benutzeranforderungen realisiert. Folgende

Funktionserweiterungen sind bereits beschlossen und werden derzeit umgesetzt: Default des ADDRESS-SPACE-LIMIT für Benutzerkennungen einstellbar größer 16 MB:

Standardmäßig werden neue Benutzerkennungen derzeit mit einem ADDRESS-SPACE-LIMIT von 16 MB angelegt. Dieser verfügbare Adressraum entspricht nicht mehr den Anforderungen an eine Kennung. Daher wird in den Kommandos ADD-USER und ADD-USER-GROUP für den Wert ADDRESS-SPACE-LIMIT=*STD der Klasse-2-Systemparameter SYSGJASL eingeführt.

Erhöhung der maximalen Anzahl von SATUT-Eingabedateien: Bei täglichem Wechsel der SATLOG soll auch dann noch eine Monatsauswertung möglich sein, wenn das System einige Male neu gestartet wurde, so dass für diese Tage mehrere Dateien existieren. Dies wird durch eine deutliche Erhöhung der maximalen Anzahl von SATUT-Eingabedateien von derzeit 31 erzielt.

LOGON-Wahlmöglichkeit zwischen NET-DIALOG und DIALOG Die Wahlmöglichkeit, ob das LOGON über die Einstellungen des NET-DIALOG (Stationstyp 9763) oder über DIALOG (Stationstyp <> 9763) erfolgen soll, ist bislang nur für den Stationstyp der MT9750 Emulation realisiert.

In einer weiteren Folgeversion von SECOS ist für die Kerberos-Authentisierung die Unterstützung weiterer symmetrischer Algorithmen geplant.

6.2.5 Storage-Integration System Managed Storage bezeichnet das übergreifende Konzept für ein Datenmanagement durch das Betriebssystem statt durch den Benutzer (Self-optimizing Datenmanagement). Es liefert einen wesentlichen Beitrag zur Verfügbarkeit und Automatisierung des Systembetriebs. Wesentliche Aspekte sind die Transparenz der Speicherhierarchie für den Endbenutzer und die Vereinfachung der Datenverwaltungsmaßnahmen für den Systemadministrator. Die optimale Ablage der Daten innerhalb des Pubsets erfolgt automatisch durch das System. System Managed Storage ermöglicht, ein Information Lifecycle Management (ILM) zu betreiben mit dem Ziel, die richtige Information zur richtigen Zeit am richtigen Ort bei geringsten Kosten zu haben. ILM ist ein Storage Management-Konzept, das Informationsobjekte während ihres gesamten Lebenszyklus aktiv steuert und verwaltet. Ein Optimierungsprozess innerhalb eines Regelwerks bestimmt den best geeigneten Platz für die Speicherung der Informationen. Die für ein ILM erforderlichen Backup-, Replikations-, Verdrängungs-, Verlagerungs- und Archivierungsfunktionen sind in BS2000/OSD vorhanden. Sie werden durch das Produkt HSMS (Hierarchisches Storage Management System) realisiert. Der Schwerpunkt der neuen Funktionalität zur Storage-Integration in BS2000/OSD-BC V9.0 ist die Einbindung von NET-

Storage (NAS) und die Unterstützung der ETERNUS DX Speichersysteme auf Basis SHC-OSD: BS2000/OSD Integration für NET-Storage (NAS)

Im BS2000 werden bisher die Speichermedien Platten und Magnetband in verschiedenen Ausprägungen unterstützt. In der BS2000/OSD V9.0 können zusätzlich Speichermedien durch das BS2000 genutzt werden, die ihre Dienste über NFS anbieten. Die neue Funktionalität eröffnet folgende neue Möglichkeiten: Ablage von performance-unkritischen BS2000-Dateien auf preisgünstigen NAS-Speichern, mit etwas geringerer Performance

als auf den SAN-Platten (z.B. zur Datensicherung und Ablage von Logging-Dateien und Testdaten). Direkter Zugriff auf gemeinsam benötigte Daten im Original durch zusammenarbeitende inhomogene Anwendungen

(vorstellbar: Applikationen hinterlegen Statusinformationen in Datei-Form; Weiterverarbeitung für von BS2000 auf dem NET-Storage abgelegten PDF- und HTML-Dateien)

Die Anwendungen, die auf solchen Speichern (allgemein bezeichnet als NET-Storage) abgelegte Dateien nutzen, verarbeiten diese genauso wie auf einem klassischen lokalen Pubset. Die betroffenen Kommandos werden entsprechend erweitert. Die neue Funktionalität ist für die Anwendungen voll kompatibel. Mit SHOW-NET-STORAGE kann sich der Benutzer über verfügbare NET-Server informieren. Außerdem können Informationen über vorhandene NET-Volumes ausgegeben werden. Zum Sicherungsumfang eines Pubsets gehören in der OSD V9.0 auch die Daten auf dem NET-Storage. Bei Sicherungen mit den bisherigen Standard-Einstellungen in ARCHIVE und HSMS werden deshalb grundsätzlich die Daten auf dem NET-Storage mit gesichert. Das User Interface von ARCHIVE wird nicht erweitert. Über erweiterte HSMS-Schnittstellen kann die Sicherungsmenge hinsichtlich Dateien auf lokalen Pubsets und Dateien auf fernem NET-Storage gezielt ausgewählt werden.


Der Zugriff von dem BS2000-System auf den NET-Storage muss durch eine entsprechende Konfigurierung erlaubt werden. Der BS2000-Systemverwalter erhält neue Kommandos (MOUNT-NET-STORAGE/UMOUNT-NET-STORAGE, CREATE-NET-STORAGE-VOLUME/DELETE-NET-STORAGE-VOLUME) zur Administration des von BS2000 genutzten NET-Storage als BS2000-Speicher.

Architektur Ein separates Linux-System fungiert als Trägersystem für den NET-Client (Gateway zwischen BS2000 und dem NET-Storage).

Als Plattform dient für S-Server der HNC (HNC IV und HNC V), bei SQ-Servern wird direkt X2000 genutzt (die für den SQ200-

Nachfolger entwickelte X2000-Version). Wie jede BS2000-Datei besitzt auch eine Datei auf Net-Storage einen Katalogeintrag auf einem Pubset. Hier sind Informationen über die Dateiablage auf Net-Storage hinterlegt.

Unterstützte NET-Server Die erste unterstützte NET-Server-Hardware ist der neue NAS-Anschluss von ETERNUS CS High End V5. Eine Freigabe für NAS System von NetApp ist auf Sonderfreigabe-Antrag erhältlich. BS2000/OSD-Integration für die ETERNUS DX Clone- und Snap-Funktionen auf Basis von SHC-OSD

Die Storage-Systeme Fujitsu ETERNUS DX410/DX440, DX410 S2/DX440 S2 und DX8400/DX8700 sind für den Betrieb mit Fujitsu BS2000/OSD Business Servern der S- und der SQ-Serie mit BS2000/OSD V7.0 und V8.0 freigegeben. Die Freigabe der Modelle ETERNUS DX8000 S2 ist in einem Nachtrag zu SHC-OSD V9.0 für das 1. Quartal 2012 geplant. Die Storage Host-Komponente SHC-OSD und darauf aufsetzende Produkte/Komponenten haben bislang eine mächtige und umfassende Funktionalität zur Steuerung der Replikationsfunktionen der EMC Storage-Systeme Symmetrix und CLARiiON CX aus dem BS2000/OSD angeboten. Mit der Freigabe von Fujitsu BS2000/OSD SHC-OSD V9.0 Mitte September 2011 wurden auch für ETERNUS DX Informationsfunktionen und Event Monitoring angeboten und die ETERNUS DX Replikationsfunktionen Equivalent Copy und Remote Equivalent Copy an den BS2000-Servern unterstützt. EC ist die lokale Spiegelung auf Volume Ebene vergleichbar zu TimeFinder/Clone bei Symmetrix. REC ist die Remote Spiegelung vergleichbar zu SRDF bei Symmetrix. Die Clone- und Snap-Funktionalität von ETERNUS DX weicht in einigen Punkten von der Clone/Snap-Realisierung der EMC-Storage-Systeme ab, so dass SHC-OSD den aufsetzenden Komponenten Snapsets, CCOPY und PVSREN keine kompatiblen Schnittstellen anbieten kann. Diese Komponenten werden in den betroffenen OSD-Versionen entsprechend angepasst. Dem BS2000-Kunden wird hiermit eine Alternative zu den EMC Symmetrix-Systemen angeboten. Ausblick

Weitere Maßnahmen zur Verbesserung der Storage-Integration sind bereits in Vorbereitung. So ist für die Folgeversion von SHC-OSD (V10.0), freigegeben voraussichtlich im 2. HJ 2012, die Unterstützung der lokalen Spiegelung mit Snaps und der asynchronen Remote-Spiegelung für ETERNUS DX Systeme geplant. Zusätzlich ist für eine weitere Nachfolgeversion die Unterstützung von Virtual Provisioning vorgesehen.

6.2.6 Manageability und Ease of Use Kostengünstige Administration, eine effiziente Betriebsmittelauslastung und ein 24-Stunden-Betrieb sind nur möglich, wenn alle wesentlichen Betriebsabläufe automatisiert werden können. BS2000/OSD ist eine hoch automatisierbare Systemplattform. Mit jeder Version werden weitere Automatisierungsfunktionen hinzugefügt. Aber auch Verbesserungen an der Dialogoberfläche machen den Betrieb des BS2000/OSD einfacher und effektiver. In BS2000/OSD V9.0 wurden u.a. folgende Erweiterungen realisiert:

MAIL-FILE-Erweiterungen

In der BS2000/OSD V8.0 wurden Mail-Funktionen realisiert, die es Systemkomponenten und User-Programmen auf einfache Weise erlauben, Emails aus Systemabläufen heraus zu erzeugen. Damit kann eine Textdatei alternativ zur Druckausgabe als Anhangdatei einer Email an die Mail-Adresse der Benutzerkennung verschickt werden. Die zu versendende BS2000-Datei musste bisher eine SAM oder ISAM-Datei sein. In der BS2000/OSD V9.0 können auch Bibliothekselemente von druckaufbereitbaren Elementtypen (ohne Umweg über vorheriges Extrahieren der Dateien) und PDF-Dateien versandt werden (Mit dem Kommando CONVERT-FILE-TO-PDF können BS2000-Text-Dateien (katalogisierte SAM- oder ISAM-Dateien) in „PDF-Dateien“ (speziell gekennzeichnete SAM-U-Dateien) konvertiert werden). Angleichung der SHOW- und MODIFY-Kommandos der Pubset-Verwaltung

Für die Pubset-Verwaltung werden neue (zusätzliche) SHOW-Kommandos angeboten in der Art, dass zu einem SHOW-Kommando auch ein MODIFY-Kommando allein durch den Funktionspräfix auffindbar ist, und umgekehrt. Beispiel: Zu SHOW-PUBSET-PARAMETERS gehören heute die MODIFY-Kommandos MODIFY-PUBSET-CACHE-ATTRIBUTES, MODIFY-PUBSET-SPACE-DEFAULTS und MODIFY-SPACE-SATURATION-LEVELS. In Zukunft wird es zusätzlich die Kommandos, SHOW-PUBSET-CACHE-ATTRIBUTES, SHOW-PUBSET-SPACE-DEFAULTS, SHOW-SPACE-SATURATION-LEVELS geben. Neue EDIT-Kommandos

Zu einer Reihe von häufig verwendeten MODIFY-Kommandos werden EDIT-Kommandos mit Vorbelegung der aktuellen Operanden-Werte angeboten (analog zu den bereits bestehenden EDIT-FILE-Kommandos). Damit kann der Operanden-Wert in einem Arbeitsgang angezeigt und geändert werden. Die EDIT-Kommandos wurden mittels SDF-P S-Prozeduren realisiert und als kompilierte SDF-P S-Prozeduren ausgeliefert, so dass sie vom Kunden nicht modifiziert werden können. Vorteil: Sie setzen für ihren Ablauf beim Kunden nicht das kostenpflichtige Produkt SDF-P voraus. In der BS2000/OSD V9.0 sind dies u.a. Kommandos aus dem Bereich MODIFY-JOB, MODIFY-JV, MODIFY-PUBSET und MODIFY-USER.


Aussagefähigere Meldungen

Bei einigen Kommandos fehlen nach negativem Return Code Zusatzinformationen wie der Bezug auf das Objekt (z.B. welche Datei). Dadurch wird die Fehler-Diagnose für Kunden erschwert. In der BS2000/OSD-BC V9.0 sind entsprechende Maßnahmen u.a. für die Kommandos des Pubset-Management realisiert. Wählbare Systemreaktion bei Überschreitung von CPU-Time-Limits

Tasks und Programme, die ihr vorgegebenes CPU-Time-Limit überschreiten, sollen möglichst zeitnah hart terminiert werden können. Beim Erreichen eines CPU-Time-Limits werden

keine Zeit-Zuschläge gewährt,

Batch- und Dialog-Tasks gleich behandelt und

keine beantwortbaren Konsolmeldungen ausgegeben.

Dieses Verhalten wird über die Class-2-Option DIATTL zusätzlich angeboten.

Funktionserweiterungen für BS2000-Kommandos

Das RUN-Kommando für den Operator wird um die Möglichkeit erweitert, RUN-Prozeduren aus Bibliothekselementen zu starten.

Das neue Kommando SHOW-TEST-OPTIONS dient zur Anzeige der mittels Kommando MODIFY-TEST-OPTIONS eingestellter sowie weiterer Testoptionen.

Bedingungsloses Warten bei Kommando WAIT-EVENT

Das Kommando WAIT-EVENT wird erweitert um

unbedingtes Warten für eine bestimmte Zeitspanne

unbedingtes Warten bis zu einem bestimmten Zeitpunkt

ohne Spin Off auszulösen.

6.2.7 Offenheit und Integrationsfähigkeit Die seit Jahren verfolgte Strategie der Offenheit wird konsequent fortgesetzt. Dies ist etwa durch die in 1997 erlangte Unix95-Zertifizierung (SPEC1170) für BS2000/OSD dokumentiert. Fujitsu hat selbst auf die XPG4-Schnittstellen Basisdienste wie Network File System (NFS) und Simple Network Management Protocol (SNMP) portiert. Darüber hinaus ist der Ausbau des BS2000/OSD Gesamtsystems zu einem vollständigen Internet Server/OSD erfolgt. Von Betriebssystem, Kommunikationsmanager und Aufsatzprodukten werden alle notwendigen Protokolle, Schnittstellen und Services angeboten, die für den Betrieb im Internet notwendig sind (siehe Kapitel 3). Als technische Basis dieser Entwicklungen dienen ebenfalls die POSIX-Schnittstellen des BS2000/OSD. POSIX

BS2000/OSD-BC ist mit standardisierten Schnittstellen gemäß POSIX / XPG4.2 ausgestattet. Der vollständige Umfang der POSIX-Shell ist als Bestandteil des Betriebssystems verfügbar. POSIX als die technische Basis der BS2000/OSD-Öffnungsstrategie wird entsprechend den Anforderungen der Nutzer weiterentwickelt. In Verbindung mit BS2000/OSD-BC V8.0 wurde die Version POSIX A41 entwickelt. Schwerpunkt ist hier das BS2000-Dateisystem bs2fs mit der Möglichkeit, aus der POSIX-Umgebung transparent auf BS2000-Dateien zuzugreifen und so z.B. bei der Programmentwicklung für das BS2000 die umfangreichen Möglichkeiten der POSIX-Tool-Umgebung (grep, make) zu nutzen. Der Zugriff von Remote Clients auf BS2000-Dateien ist in der POSIX-Folgeversion POSIX A43 zur BS2000/OSD-BC V9.0 geplant. Er geschieht in zwei Schritten: Zuerst wird das BS2000-Dateisystem mit einem (erweiterten) mount-Kommando an der gewünschten Stelle im ufs-

Dateisystem gemounted. Beim Zugriff auf eine Datei (z.B. open()) wird der Kopiervorgang für die Datei angestoßen, Nach der Bearbeitung wird wieder nach BS2000 kopiert. POSIX sorgt dabei für die Konsistenz der Stände.

Ist das BS2000-Dateisystem gemounted, so kann auch von einem fernen Rechner (wie lokal in POSIX) auf diese Dateien zugegriffen werden. D.h. BS2000/POSIX ist dann der Server und der ferne Rechner ist der Client, auf dem das Verzeichnis in das die BS2000-Dateien gemounted wurden, via NFS gemounted wird.

Weitere wichtige Funktionen in POSIX A43 sind:

Eigene Jobklassen für POSIX-Tasks, die entsprechend den Default-Jobklassen für DIALOG und BATCH definiert werden. Die Ressourcen für „POSIX-Tasks“ sind dann über spezielle Job-Klassen steuerbar. Das Shell-Kommando fork() weist der zu erzeugenden Task die POSIX-Default-Jobklasse zu, sofern diese für die Kennung definiert ist

Sicherung von bs2fs-Dateien nach Fehler beim close(): Es wird ein „bs2fs_lost+found“ implementiert, in dem Dateien nach Fehler beim close() aufbewahrt werden und aus dem sie ins BS2000 gesichert werden können.

Beschleunigung des POSIX-Shutdown. Der Nutzen ist die Beschleunigung von Wartungs- und Testarbeiten, welche einen POSIX-Neustart erfordern

Einführung „logrotate“ („syslogd“): Rotation der POSIX-Protokolldateien im laufenden Betrieb (vgl. zu CONSLOG)


Apache

Der weltweit meistgenutzte Web-Server Apache ist in der aktuellen Freigabeversion neben Windows, Linux, Solaris auch für BS2000/OSD verfügbar und im Betriebssystem BS2000/OSD-BC enthalten. Mit APACHE (BS2000/OSD) V2.2 ist der Umstieg auf den Apache http-Server 2.2.8 der Apache Software Foundation erfolgt mit der Unterstützung von PHP V5.2 ; PERL V5.8 ; TOMCAT V5.5 statt JSERV/JSP. Die APACHE (BS2000/OSD) V2.2 enthält die Unterstützung des SSL-Protokolls (Secure Socket Layer) zur sicheren Übertragung von Dokumenten und Daten über das Internet; das bisherige Zusatzprodukt interNet Security ("Apache+SSL") entfällt. Java

Mit BS2000/OSD Environment for Java (Kurzform JENV) wird Java als Bestandteil von BS2000/OSD-BC bereitgestellt. Mit dem BS2000/OSD Environment for Java (JENV) können alle Java-Programme, die auf beliebigen Plattformen erstellt wurden, auf BS2000-Systemen zum Ablauf gebracht werden. BS2000/OSD-BC ab V7.0 enthält die Version JENV (BS2000/OSD) V6.0. Die Version V6.0 des Environment for Java ist eine Rebasierung auf Java2 SDK Standard Edition 6.0. Diese Version erfüllt die relevanten Spezifikationen: The Java Language Specification, Third Edition“ „The Java Virtual Machine Specification, Second Edition“ die versionsspezifische API Spezifikation „Java 2 Platform Standard Edition API Specification 6.0“ Ebenso können Java-Applets und Java-Anwendungen entwickelt werden. Die mit JENV V6.0 erzeugten Programme können dann auf beliebigen Plattformen, die eine SDK™ V6.0-kompatible Ablaufumgebung haben, zum Ablauf gebracht werden. In der Weiterentwicklung ist die Portierung der Java SE 7 JDK ins BS2000/OSD geplant. WebTransactions for OSD

Das Produkt WebTransactions for OSD realisiert die Einbindung von beliebigen BS2000/OSD-Anwendungen in das Internet oder ein Intranet/Extranet. WebTransactions for OSD arbeitet auf der Systemplattform BS2000/OSD mit dem Web-Server APACHE zusammen. Mit BS2000/OSD-BC ab V7.0 wird die Variante WebTransactions V7.5 für OSD-Anwendungen ablauffähig auf BS2000/OSD unter POSIX, mit einer unbegrenzten Anzahl von Userlizenzen ausgeliefert. Damit liegen bereits im Betriebssystem-Grundausbau die Voraussetzungen vor, die Web-Technologie für E-Business-Aktivitäten zu nutzen. Die Version WebTransactions for OSD V7.5 enthält gegenüber der Vorversion V7.1 eine erweiterte Unicode-Unterstützung Unicode im BS2000/OSD

Einige EU-Richtlinien und deren Umsetzung in nationale Gesetzgebungen zwingen unsere Kunden, ihre IT-Anwendungen an Vorgaben zur korrekten Schreibung von Namen, Auslandsanschriften u.ä. anzupassen. Das BS2000/OSD verwendet bei der Bearbeitung von Daten standardmäßig einen 7-Bit EBCDIC-Zeichensatz, mit dem 95 verschiedene Zeichen zur Verfügung stehen. Es unterstützt daneben auch 8-Bit-Zeichensätze, die es erlauben, mit Zeichencodes von bis zu 189 Zeichen zu arbeiten. Ziel von Unicode ist, für alle weltweit vorkommenden Zeichen eine weltweit eindeutige Codierung festzulegen. Die BS2000-Implementierung leistet dies für den westeuropäischen Raum. Mit der Unicode-Unterstützung im BS2000/OSD werden die in BS2000/OSD -Systemen verfügbaren EBCDIC-Zeichensätze um zusätzliche Zeichen erweitert, die im europäischen Sprachraum künftig benötigt werden. Dies erfolgt durch den Einsatz ausgewählter Unicode-Codepoints additiv zu den bisherigen EBCDIC-Varianten. Dem Anwender wird die Programmier- und Ablauf-Umgebung zur Verfügung gestellt, die er benötigt, damit er seine bestehenden Anwendungen um Unicodedatenfelder erweitern kann. Die Unicode-Unterstützung der Programmier- und Ablauf-Umgebung erstreckt sich auf folgende Funktionsbereiche: Programmierung: COBOL2000, ESQL-COBOL, IFG/FHS (Unicode-Datenfelder), AID Datenspeicherung: SESAM/SQL, UDS/SQL, ORACLE (Unicode-Datenfelder) Verarbeitung von Daten: EDT, SORT, PERCON Input/Output: Terminal-Support (VTSU, MT9750, FHS) , Printer-Support (RSO, Spool), File Transfer (openFT),

OMNIS/OMNIS-MENU, WebTransactions Zur Unterstützung der Unicode-Funktionalität im BS2000/OSD wird eine entsprechende Softwarekonfiguration unter den BS2000/OSD-BC-Versionen ab V6.0 bereitgestellt. Ausblick Unicode-EDT (Kommando „edtu“) in POSIX A43

Das derzeit verfügbare Shell-Kommando „edt“ nutzt die V16.6-Funktionalität des EDT-Unterprogramms. Die V17-Variante des EDT-Unterprogramms bietet neue Features

Unicode-und ISO-Zeichensätze, neue Ausgabeformate

sehr wichtig in POSIX: lange Zeilen (32768 Bytes)

Mit POSIX A43 wird ein neues Kommando „edtu“ in die Shell integriert, das die die V17-Funktionalität des EDT-Unterprogramms.nutzt.


Bild 3 HIPLEX-Prinzip

6.3 Highly Integrated System Complex HIPLEX

6.3.1 Hochverfügbarkeit mit HIPLEX

Im Internet werden aufgrund der globalen Geschäftsvorgänge die Anforderungen nach permanenter IT-Verfügbarkeit dramatisch wachsen. Für die Betreiber von IT-Infrastrukturen gilt es, Wege zu finden, um IT-Anwendungen permanent verfügbar zu halten. Die Steigerung der Verfügbarkeit von IT-Subsystemen, z.B. von Servern, ist zwar nützlich, reicht aber für permanente Verfügbarkeit von Anwendungen grundsätzlich nicht aus. Hohe Anwendungsverfügbarkeit ist nur über die Nutzung von Redundanzen bei den Ablaufträgern dieser Anwendungen erreichbar. Hochverfügbarkeit von Systemen wird im Wesentlichen durch zwei Techniken erzielt: Fehlertoleranz und Failover. Fehlertoleranz

In ein bestehendes System wird soviel an Redundanz und Fehlerentdeckungslogik eingebaut, dass Fehler fast immer sofort entdeckt werden und ohne Verzug auf redundante Komponenten umgeschaltet werden kann. Dies führt zu sehr hoher Verfügbarkeit ohne Anwendungsunterbrechung, hat aber einen Nachteil: Die mitlaufende Redundanz verrichtet im Normalbetrieb keine produktive Arbeit und ist damit sehr teuer. Failover

Mit einem bestehenden System wird ein im Wesentlichen gleiches, zweites System verbunden. Beide Systeme kontrollieren sich gegenseitig und spielen füreinander das Backup-System. Beide Systeme sind im Normalbetrieb produktiv. Im Fehlerfall werden geschäftskritische Anwendungen des ausfallenden Systems inklusive Ressourcen auf das lebende System verlagert (ggf. müssen weniger wichtige Leistungen auf dem übernehmenden System beendet werden). Diesen Vorgang nennt man Failover. Failover basiert nicht auf ungenutzten Redundanzen und ist damit eine sehr wirtschaftliche Lösung, die als weiteren Vorteil auch noch erhöhte Skalierbarkeit bietet. Deshalb realisieren heute fast alle Serverplattform-Hersteller Failover-Konzepte. Im Mainframe-Umfeld bieten Cluster die Failover-Fähigkeit. Mit Clustern lässt sich mit relativ geringem Aufwand und zu vernünftigen Kosten hohe Verfügbarkeit von Server-Anwendungen erreichen. HIPLEX (Highly Integrated System Complex)

ist das Cluster-Konzept von Fujitsu zur Unterstützung eines Verfügbarkeitsverbunds mit mehreren BS2000/OSD Business Servern. Ein HIPLEX besteht aus mehreren BS2000/OSD-Systemen, die über ein Verbindungssystem miteinander vernetzt sind. Diese Konstruktion eines HIPLEX bietet bessere self-healing-Eigenschaften durch höhere Skalierbarkeit und Redundanz als ein klassischer Uni- oder Multiprozessor (mit gemeinsamer Kopplung der Prozessoren über den Hauptspeicher). Im Rahmen des HIPLEX-Konzeptes werden Skalierbarkeit und Redundanz zur Steigerung der Leistungsfähigkeit und der Verfügbarkeit genutzt und den BS2000/OSD-Anwendern verfügbar gemacht. Gleichzeitig werden Funktionen zur Automation und Administration des Verbunds realisiert. Die sehr hohe und sich immer noch verbessernde Verfügbarkeit von BS2000/OSD-Clustersystemen resultiert aus der sich ständig verbessernden Hardwareverfügbarkeit und

Konfigurierbarkeit der BS2000/OSD-Server, den neuen Verfügbarkeitsfeatures im Betriebssystem

BS2000/OSD und aus der möglichen Verlagerung von Anwendungen und ihren

Ressourcen im HIPLEX. Durch die vollautomatische Verlagerung von Anwendungen im Fehlerfall lassen sich für HIPLEX-Anwendungen Ausfallzeiten eliminieren, die durch Reparatur und Neustart des ausfallenden Servers verursacht werden. Dadurch wird eine Anwendungsverfügbarkeit erreicht, die wesentlich über der erreichbaren Verfügbarkeit nur eines Servers liegt. Die zentralen Produkte im HIPLEX sind HIPLEX MSCF (Multi System Control Facility) HIPLEX AF (Availability Facility)


6.3.2 Die Produkte HIPLEX MSCF und HIPLEX AF HIPLEX MSCF

HIPLEX MSCF etabliert für maximal 164 BS2000/OSD Business Server Grundstrukturen für den Auftrags,- Last- und Verfügbarkeitsverbund sowie für verteilte Anwendungen. HIPLEX MSCF expandiert die Server- bzw. System-lokalen Basisfunktionen Katalogzugriff, Dateizugriff, Starten von ENTER-JOBs auf den HIPLEX MSCF-Verbund. HIPLEX AF

HIPLEX AF überwacht Anwendungen im Multi-Serververbund und schaltet die Anwendungen mit ihren Betriebsmitteln bei Ausfall eines Servers automatisch auf einen intakten Server um. Darüber hinaus können Anwendungen mit HIPLEX AF gezielt auf einen anderen Server verlagert werden. Im Falle einer Katastrophe, also bei lokalem Ausfall von Server und Storage-Systemen, ermöglicht HIPLEX AF eine vollautomatische Umschaltung in ein entferntes Data Center. In den Verbundvarianten spielen HIPLEX MSCF und HIPLEX AF folgende Rollen:

Lastverbund: Der Lastverbund nutzt die weitgehende Skalierbarkeit durch leichte Integration weiterer BS2000-Server in den Verbund und durch die Aufteilung von Anwendungen auf mehrere BS2000-Server. HIPLEX MSCF und HIPLEX AF realisieren die statische Aufgabenverteilung und die geplante Anwendungsverlagerung im Lastverbund. Verfügbarkeitsverbund: Der Verfügbarkeitsverbund garantiert sehr hohe Anwendungsverfügbarkeit durch die Verlagerung von Anwendungen auf andere Business-Server innerhalb des Verbunds. HIPLEX MSCF und HIPLEX AF sind im Verfügbarkeitsverbund in der Lage, Ausfälle zu erkennen und betroffene Anwendungen gezielt auf ein Standby-System umzuschalten. Ausfallerkennung im Verbund mit HIPLEX-MSCF ab V4.0 und HIPLEX AF ab V3.2

Der Ausfall eines Partnerrechners muss möglichst schnell erkannt werden, um die Wiederanlaufzeit betroffener Anwendungen zu verkürzen. Zusätzlich zur Nutzung der MSCF-spezifischen Mechanismen zur Ausfallerkennung können über Schnittstellen die entsprechenden Mechanismen von HIPLEX-AF genutzt werden. HIPLEX-AF realisiert seit der Version V3.2 einen Live-Monitor, der einen Systemausfall erkennt und an HIPLEX-MSCF meldet. Darüber hinaus kann HIPLEX MSCF den Live-Monitor beauftragen, den Zustand eines Systems zu prüfen und es zu terminieren, falls kein eindeutiger Aktiv-Zustand festgestellt wird. Die Gesamtzeit für Ausfallerkennung ist die MSCF-Ausfall-Erkennungszeit plus die Wartezeit bis zur Fail-Rekonfiguration (währenddessen erfolgt ggf. vorsorglich ein SETS des für ausgefallen erkannten Rechners). Sicherheit der Ausfallerkennung: Mit der MSCF-Abfrage CHECK-SYSTEM bzw. STOP-SYSTEM-CONDITIONAL kann eine fehlerhafte Ausfallerkennung vermieden werden, danach kann die Fail-Rekonfiguration ohne vorsorglichen SETS und ohne Wartezeit erfolgen. Unterstützung von Autoswap ab HIPLEX AF V3.2

Autoswap ist eine HIPLEX AF-Funktion, die es erlaubt, im Falle eines geplanten Ausfalls einer SRDF-gespiegelten Symmetrix automatisch auf die Spiegel-Symmetrix umzuschalten. Dadurch können z.B. Wartungsarbeiten an einer Symmetrix ohne Anwendungsunterbrechung offline durchgeführt werden. Im Falle des ungeplanten Ausfalls einer Symmetrix ermöglicht Autoswap zusätzlich zur automatischen Umschaltung des Work-Systems auf ein Standby-System durch HIPLEX AF auch noch die automatische Umschaltung des ausgefallenen Work-Symmetrix-Systems auf ein SRDF-gespiegeltes Standby-Symmetrix-System. Dadurch kann der Failover-Vorgang schneller eingeleitet werden und die System-Downtime wird reduziert. Die Anwendungen laufen nach kurzer Zeit auf demselben Server, ohne dass eine Unterbrechung und ein Restart notwendig ist, mit den konsistenten Daten der gespiegelten Symmetrix weiter.


6.4 Virtuelles Maschinen-System VM2000

Eine virtuelle Infrastruktur führt zur Senkung der IT-Kosten durch gesteigerte Effizienz, Flexibilität und Reaktionsfähigkeit. Somit können IT-Ressourcen schnell entsprechend dem wechselnden Geschäftsbedarf zugeordnet, neue Dienste bereitgestellt und die Auslastung der Server deutlich gesteigert werden.

VM2000 ermöglicht das gleichzeitige Betreiben unterschiedlicher, voneinander völlig abgeschotteter Systemumgebungen auf

einem Server. Abhängig vom Typ des Servers können bis zu 15 BS2000/OSD-Systeme (Gastsysteme) auf einem Server unter VM2000 ablaufen. Vorteil des Einsatzes von VM2000 gegenüber dem Einsatz mehrerer Server ist die Möglichkeit der Konsolidierung im Sinne der besseren Nutzung von HW-Ressourcen, Personal und Infrastruktur.

6.4.1 Nutzungs-Szenarien Parallelbetrieb von Produktion, Entwicklung und Test

VM2000 ermöglicht den Betrieb eines Entwicklungssystems mit unerprobten, instabilen Anwendungen neben der Produktion: Beim Betrieb mehrerer Systeme auf einer Anlage haben Systemfehler in einem System keine Auswirkungen auf die anderen gleichzeitig ablaufenden Systeme. Differenzierte Systeme, z.B. für Service Provider

Benötigt ein Dienstleistungs-Data Center unterschiedliche Systemumgebungen für seine Kunden, so eröffnet VM2000 die Möglichkeit, einen einzigen Server mit hoher Leistung zu installieren. Damit sind Einsparungen an Stellfläche und im administrativen Bereich zu erzielen. Die gleichen Vorteile können mit VM2000 auch von Kunden genutzt werden, die selbst unterschiedliche Produktionsumgebungen benötigen, z.B. wenn Anwendungen noch nicht an aktuelle Versionen des BS2000/OSD oder der systemnahen Software angepasst sind. Mit der VM2000-Funktion „CPU-Utilization“ kann ein Dienstleistungs-Data Center seinen Kundensystemen genau die (maximale) CPU-Leistung zuweisen, die vereinbart wurde.

Bild 4: Betrieb mehrerer Gastsysteme unter VM2000


Ausgleich von Lastspitzen, Nutzung für Backup-Konzepte

Mit der VM2000-Funktion „Dynamische Vergrößerung und Verkleinerung der Hauptspeicher-Domäne" lassen sich die VM2000-Einsatzszenarien noch weiter optimieren. Ohne laufende Gastsysteme beenden zu müssen, hat man mit diesem Feature die Möglichkeit, Lastspitzen von Gastsystemen noch besser auszugleichen, kurzfristig temporäre Gastsysteme einzurichten und Backup-Gastsysteme vorzuhalten mit minimalem Ressourcenverbrauch. Durchführung von Versionsumstiegen

Mit VM2000 können die einzelnen Produktionsanwendungen (soweit dies durch voneinander unabhängige Datenbestände möglich ist) schrittweise in die neue Systemumgebung überführt werden. Dabei wird zuerst der Ablauf der einzelnen Anwendungskomplexe in einem zweiten Gastsystem getestet, bis Fehlerfreiheit vorliegt. Danach erfolgt der Einsatz im Produktionssystem. Der Umstieg mit VM2000 läuft somit zeitlich entspannt ab: Bisher notwendige Vorkehrungen wie Nachttestzeiten und Wochenendarbeitszeiten können mit VM2000 eingespart werden. Während der Testarbeiten kann das Bedienpersonal die neue Version in Ruhe kennen lernen. So trägt der Einsatz der VM2000 auch dazu bei, spätere Bedienfehler im Produktionssystem zu minimieren.

6.4.2 VM2000-Versionsübersicht

Modellreihe S-Server SX-Server SQ-Server

VM2000-Version V7.0 V8.0 V9.0 V10.0 V7.5 V8.0 V9.0 V9.5 V10.0

Lieferfreigabe Mai 02 Mrz 05 Mai 07 Mrz 12 Jan 03 Mrz 05 Mai 07 Sept 10 Mrz 12

BS2000/OSD Version des Monitorsystem

OSD-BC

V4.0, V5.0

OSD-BC

V5.0, V6.0, V7.0

OSD-BC

V6.0, V7.0, V8.0, V9.0

OSD-BC

V8.0, V9.0

OSD/XC

V1.x

OSD/XC

V1.x, V2.x, V3.0

OSD/XC

V2.x, V3.0, V4.x

OSD/XC

V4.x, V9.0

OSD/XC

V4.x, V9.0

Gastsysteme

BS2000/OSD V4.0 x x

BS2000/OSD V5.0 x x x

BS2000/OSD V6.0 x x x x

BS2000/OSD V7.0 x x x

BS2000/OSD V8.0 x x

BS2000/OSD V9.0 x

OSD/XC V1.0, V1.1, V1.2 x x x

OSD/XC V2.0, V2.1, V2.2 x x x

OSD/XC V3.0 x x

OSD/XC V4.0, V4.1 x x x

OSD/XC V9.0 x x

Unterstützte Business Server

S110,S115,S120,S130, S135,S140,S150,S160, S170

x x x

S145,S155,S180,S190 x x x x

S165, S200 (1) x x x

S175, S210 (2) x x

SX100-A/-B,SX130, SX140

x x x

SX100-C, SX150 (3) x x

SX100-D, SX160 (4) x

SQ100, SQ200, SQ210 x x

(1): Gastsysteme ab OSD V5.0 (auch unter VM2000 V8.0)

(2): Gastsysteme ab OSD V7.0

(3): Monitorsystem nur OSD/XC ab V2.x.

(4): Monitor- und Gastsysteme nur OSD/XC ab V3.0


6.4.3 VM2000-Konzept für SQ-Server

VM2000 ermöglicht in gleicher Weise wie auf S-Servern den Ablauf mehrerer paralleler BS2000/OSD-Systeme auf einem SQ-Server. VM-Konzept auf SQ-Servern

VM2000 wurde auf SQ-Servern unter Beibehaltung der VM2000-Benutzerschnittstellen mit einer Xen-basierten Architektur realisiert. Das Betreiben und Virtualisieren der Hardware übernimmt dabei der Xen Hypervisor. Auf den S- und SX-Servern besteht VM2000 i.W. aus den Komponenten VM2000-Monitor und VM2000-Hypervisor. Die Komponente VM2000-Monitor implementiert die Benutzeroberfläche von VM2000, realisiert die internen Funktionen Accounting, Logging, Eventing, verwaltet die VM-Administratoren und realisiert den Netzzugang für die VM-Administration und die virtuelle Konsole. Auf den SQ-Servern steht der VM2000-Monitor weiterhin mit kompatibler Kommando-Oberfläche zur Verfügung. Die Funktionen des VM2000-Hypervisors werden durch den Xen Hypervisor und eine zusätzliche Komponente VM2000-Agent in der privilegierten Domäne Dom0 übernommen.

Bild 5: VM-Konzept für SQ-Server

Die VM2000 Kommando-Funktionen zum Bedienen von VMen und zum Verwalten des Hosts werden auf SQ-Servern auf Xen-Administrationsfunktionen abgebildet. Der in Dom0 laufende Dämon VM2000-Agent realisiert die Abbildung der VM2000-Hypervisor Funktionalität. Dabei treten als Auftraggeber neben dem VM2000-Monitor auch BS2000-Gastsysteme auf. VM2000-Funktionen in den Gastsystemen

Jedes BS2000-Gastsystem hat heute Kommunikations-Schnittstellen zum VM2000-Hypervisor, um Auskunft über den VM2000-Betrieb zu erhalten und im Gastsystem VM2000-spezifische Aktionen einzuleiten (z.B. implizite Gerätezuordnung). Auch auf SQ-Servern können die BS2000 Gastsysteme weiterhin VM2000-Funktionalität nutzen, indem anstelle der bisherigen Hypervisor-Calls Xen-Schnittstellen aufgerufen werden. Im VM2000 Betrieb besitzt jede BS2000-Domäne einen eigenen HAL und eigene CISC-Firmware. Ablauf von BS2000-, Linux- und Windows-Gastsystemen auf SQ-Servern

Neben dem parallelen Betrieb mehrerer BS2000-Gastsysteme mittels VM2000 können auf Basis der Xen-Architektur auch Linux und Windows als zusätzliche Gastsysteme zum Ablauf gebracht werden. Die Administrationsoberfläche der SQ-Server, der SQ-Manager, wurde erweitert und ermöglicht nun auch die Administration von Linux- und Windows-Gastsystemen. Die Administration der BS2000-Gastsysteme erfolgt dagegen wie bisher über die VM2000-Kommandos. Der VM2000-Verwalter erhält über sie jedoch auch Informationen über vorhandene Ressourcen von Linux- und Windows-Gastsystemen (CPU, Hauptspeicher). Das GUI des SQ-Managers zeigt auch BS2000-Gastsysteme an und ermöglicht für BS2000-Gastsysteme die Funktionen „Gastsystem starten“, „Gastsystem beenden“ und „Gastsystem abbrechen“.


Alle Rechte vorbehalten, insbesondere gewerbliche Schutzrechte. Änderung von technischen Daten

sowie Lieferbarkeit vorbehalten. Haftung oder Garantie für Vollständigkeit, Aktualität und Richtigkeit

der angegebenen Daten und Abbildungen ausgeschlossen. Wiedergegebene Bezeichnungen

können Marken und/oder Urheberrechte sein, deren Benutzung durch Dritte für eigene Zwecke die

Rechte der Inhaber verletzen kann.

Weitere Einzelheiten unter ts.fujitsu.com/terms_of_use.html

Copyright © Fujitsu Technology Solutions GmbH 2013

Kontakt

FUJITSU Technology Solutions GmbH

Adresse: Domagkstraße 28, 80807 München

Email: [email protected] Website: http://ts.fujitsu.com/bs2000

Firmenstempel

6.4.4 Funktionserweiterungen der neuen VM2000-Version VM2000 V10.0

VM2000 V10.0 ist eine gemeinsame Version für Business Server der S- und der SQ-Serie. Die SX-Server werden durch VM2000 V10.0 nicht mehr unterstützt. VM2000 V10.0 unterstützt BS2000/OSD-BC V9.0 als Monitorsystem und als Gastsystem. Die wesentlichen neuen Funktionen von VM2000 V10.0 sind: Gemeinsame VM2000-Version für S- und SQ-Server

Nach der Version V9.0 (S/SX) und V9.5 (nur SQ) ist VM2000 V10.0 eine gemeinsame Version, die wieder alle aktuellen HSI-Linien unterstützt (S/SQ). SX-Server werden offiziell nicht mehr unterstützt. Vollständiger Unterstützung von ETERNUS Plattensystemen

Eternus DX Plattensysteme (DX400/8000) werden in dem gleichen Umfang wie EMC Symmetrix Plattensysteme von VM2000 unterstützt (PAV, Snap & Clones). Sichern der VM2000-Konfiguration und automatische Wiederherstellung bei Server-Start (S- und SQ-Server)

Die Sicherung einer bestehenden VM2000-Konfiguration soll dem VM2000-Administrator dazu dienen, dass er nach dem Neustart des VM2000-Gesamtsystems, d.h. der Beendigung aller Gastsysteme und dem Neustart des Monitorsystems, die VM2000-Konfiguration wiederherstellen kann, ohne dass er eine geeignete Prozedurdatei mit VM2000-Kommandos schreiben bzw. eine existierende Prozedurdatei anpassen muss. Die Sicherung soll auch eingesetzt werden können, um die VM2000-Konfiguration auf einem Backup-Server wiederherzustellen, auf dem außer dem Monitorsystem keine weiteren BS2000-Gastsysteme laufen. Der VM2000-Administrator kann eine Sicherung mit dem Kommando SAVE-VM-CONFIGURATION erzeugen. Das Wieder-herstellen einer VM2000-Konfiguration durch das Einspielen einer Sicherung kann der VM2000-Administrator durch das Kommando RESTORE-VM-CONFIGURATION veranlassen. CPU-Pools für BS2000-VMs auch bei SQ-Server (incl. Anpassung des virtuellen Multiprozessorgrads) Die Einschränkung, dass auf SQ-Servern neben den statischen CPU-Pools keine weiteren dynamischen CPU-Pools

eingerichtet werden können, wird aufgehoben. Für die Verwaltung der CPU-Pools stehen dem VM2000-Administrator die Kommandos CREATE-, DELETE- und SHOW-VM-CPU-POOL sowie ASSIGN-VM-TO-CPU-POOL und SWITCH-VM-CPU zur Verfügung. Bei den letzten zwei Kommandos wird wie auf S-Servern der aktuelle Multiprozessorgrad der betroffenen VM(s) überprüft, bzw. automatisch angepasst. Unterstützung von 32 virtuellen CPUs pro VM (SQ-Server)

Der maximale Multiprozessorgrad einer VM auf einem SQ-Server wird von 16 auf 32 erhöht. VM2000-Unterstützung von High Availability- & LiveMigration-Konfigurationen (SQ-Server)

Die High Availability & Live Migration Funktionalität für SQ-Server-Units wird hauptsächlich durch MARS, X2000 und HA-Addon-Software realisiert. Trotzdem werden auch Zulieferungen in VM2000 benötigt, die eine Nutzung von VM2000 in einen solchen HA-Cluster ermöglichen (z.B. eine globale Sicht auf alle VMs in einem Cluster wegen der geforderten globalen Eindeutigkeit von VM-Namen und notwendige VM2000-spezifische Prüfungen). Ausblick

VM2000 wird auch künftig an neue Anforderungen von Kunden angepasst. Darüberhinaus werden Zulieferungen zu Systemanforderungen realisiert.

mailto:[email protected]

http://ts.fujitsu.com/bs2000

Date post:	15-Aug-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

BS2000/OSD Scope Kapitel 6...

Documents