Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Nutzungsmodelle

&pagelevel(5)&pagelevel

Im Folgenden sind alle unterstützten Nutzungsmodelle für das BS2000-UFS und für ferne Workstations dargestellt.

BS2000-UFS

Beschreibung der Umgebung

Bild 27: HSMS in einem HIPLEX für BS2000-UFS: Erreichbarkeit der POSIX-Dateien und HSMS-Metadaten

  • Das HIPLEX-System umfasst mehrere Hosts, in diesem Beispiel Host 1 und Host 2.

  • Jeder Host unterstützt die HSMS-Funktionen für sein BS2000-UFS.

  • Der POSIX-Verwalter muss alle Dateisystem-Behälter, für die die HIPLEX-Fähigkeit gewünscht wird, auf einem der SM-Pubsets (gemeinsam benutzt oder exklusiv) ablegen. Im Bild oben sind die Dateisystem-Behälter auf dem SM-Pubset C abgelegt.

  • Die betroffenen SM-Pubsets müssen unter HSMS-Kontrolle gebracht werden (CREATE-SM-PUBSET-PARAMETERS, HSMS 1 für A und C, HSMS 2 für B und C).

  • Mehrere Archive müssen auf den SM-Pubsets A, B und C angelegt werden.

  • Auf Host 1 muss das BS2000-UFS unter HSMS-Kontrolle gebracht werden, in jeder Umgebung entsprechend dem BS2000-UFS (SF-Pubset für das Root-Dateisystem, SM-Pubset A für den Zweig /SM-PUB/A, SM-Pubset C für den Zweig /SM-PUB/C):

    //MODIFY-NODE-PARAMETERS NODE-ID=*BS2000-UFS,ENVIRONMENT=*S-F
//MODIFY-NODE-PARAMETERS NODE-ID=*BS2000-UFS,ENVIRONMENT=*S-M(CAT-ID=A)
//MODIFY-NODE-PARAMETERS NODE-ID=*BS2000-UFS,ENVIRONMENT=*S-M(CAT-ID=C)

  • Auf Host 2 muss das BS2000-UFS unter HSMS-Kontrolle gebracht werden, in jeder Umgebung entsprechend dem BS20000-UFS (SF-Pubset für das Root-Dateisystem, SM-Pubset B für den Zweig /SM-PUB/B, SM-Pubset C für den Zweig /SM-PUB/C): 

    //MODIFY-NODE-PARAMETERS NODE-ID=*BS2000-UFS,ENVIRONMENT=*S-F
//MODIFY-NODE-PARAMETERS NODE-ID=*BS2000-UFS,ENVIRONMENT=*S-M(CAT-ID=B)
//MODIFY-NODE-PARAMETERS NODE-ID=*BS2000-UFS,ENVIRONMENT=*S-M(CAT-ID=C)

Während des normalen Betriebs speichert HSMS die entsprechenden Metadaten in der Umgebung, in der auch die POSIX-Daten gespeichert werden:

  • Wenn ein Dateisystem gesichert wird, das sich unter dem Zweig /SM-PUB/A befindet, legt HSMS die Metadaten in einem Archiv auf dem SM-Pubset A ab.

  • Wenn ein Dateisystem gesichert wird, das sich unter dem Zweig /SM-Pub/C befindet, legt HSMS die Metadaten in einem Archiv auf dem SM-Pubset C ab.

Maßnahmen nach einem Systemausfall

Nach einem Systemausfall auf Host 1 wird Host 2 als Ersatz-Host bestimmt. Nachdem folgende Maßnahmen durchgeführt wurden, kann HSMS 2 die Arbeit von HSMS 1 fortsetzen.

Maßnahmen auf Host 1

Maßnahmen auf Ersatz-Host 2

Systemausfall
-> Host 1 steht nicht mehr zur Verfügung


                                                                            

Der Systemverwalter muss folgende Maßnahmen durchführen:

  1. SM-Pubset A importieren (/IMPORT-PUBSET)
  2. POSIX-Sitzung starten, falls noch keine existiert.
  3. Dateisysteme von Host 1 mit dem POSIX-Installationsprogramm „anhängen“ (Datei SYSDAT.POSIX-BC.FSLIST verwenden);
    Jetzt stehen den Benutzern von Host 1 dieselbe Konfiguration und dieselben Zugriffsmöglichkeiten wie vor dem Systemausfall zur Verfügung.
  4. HSMS laden und starten, wenn HSMS noch nicht läuft.
  5. BS2000-UFS in der neuen importierten Umgebung unter HSMS-Kontrolle bringen.

Der HSMS-Verwalter muss folgende Maßnahme durchführen:

HSMS-Anweisung RECOVER-REQUESTS REQUEST-DATA-ORIGIN=*NODE für SM-Pubset A geben, um die Aufträge bearbeiten zu können, die vor dem Systemausfall auf dem Host 1 eingeleitet wurden.

Bild 28: HSMS in einem HIPLEX für BS2000-UFS: Erreichbarkeit der POSIX-Dateien und HSMS-Metadaten nach einem Systemausfall


Maßnahmen nach Behebung des Systemausfalls

Nachdem Host 1 wieder läuft, können die Knotendateien auf den ursprünglichen Host gebracht und die HSMS-Aktivitäten zurück übertragen werden. Dazu müssen folgende Maßnahmen durchgeführt werden:

Maßnahmen auf Host 1

Maßnahmen auf Ersatz-Host 2

Ursache des Systemausfalls beseitigt
-> Host 1 steht wieder zur Verfügung

                                                                                


Der Systemverwalter muss folgende Maßnahmen durchführen:

  1. Mit dem POSIX-Installationsprogramm die Dateisysteme „löschen“
  2. BS2000-UFS im SM-Pubset A außer HSMS-Kontrolle bringen
  3. SM-Pubset A exportieren (/EXPORT-PUBSET)


Der Systemverwalter muss folgende Maßnahmen durchführen:


  1. SM-Pubset A importieren (/IMPORT-PUBSET)
  2. Benutzerkatalog aktualisieren:
    Benutzer hinzufügen, die während der Maßnahmen auf Host 2 zu Host 1 hinzugefügt wurden; dazu Informationen in der Datei SYSDAT.HIPLEX.USERS auf dem SM-Pubset A auswerten
  3. Dateisysteme von Host 1 mit dem POSIX-Installationsprogramm „anhängen“ (Datei SYSDAT.POSIX-BC.FSLIST verwenden)
  4. BS2000-UFS in der Umgebung SM-Pubset A und C unter HSMS-Kontrolle bringen, wenn dies noch nicht geschehen ist.


Der HSMS-Verwalter muss folgende Maßnahme durchführen:


HSMS-Anweisung RECOVER-REQUESTS REQUEST-DATA-ORIGIN=*NODE für SM-Pubset A geben, um die Aufträge bearbeiten zu können, die vor dem Systemausfall auf Host 1 eingeleitet wurden.

Organisation der Dateisysteme

Im Folgenden werden die verschiedenen Möglichkeiten dargestellt, wie die POSIX-Dateisysteme organisiert werden können, damit die HIPLEX-Fähigkeit für einen Teil des Dateisystembaums gewährleistet ist.

Bild 29: POSIX-/HSMS-Mechanismus: Client-Dateisysteme auf SM-Pubsets

Auf dem SF-Pubset befinden sich das Root-Dateisystem und die Dateisystem-Behälter von USER 1 und USER 2, da es sich um „Nicht-HIPLEX-Clients“ handelt.

Der Dateisystem-Behälter von USER 3 liegt auf dem SM-Pubset A. Die Dateisystem-Behälter der übrigen Benutzer sind auf dem SM-Pubset B abgelegt. Dabei müssen folgende Konventionen eingehalten werden:

  • Wenn sich ein Dateisystem-Behälter auf dem SM-Pubset A befindet, muss das entsprechende Dateisystem unter dem Zweig /SM-PUB/A eingehängt werden.

  • Wenn sich ein Dateisystem-Behälter auf dem SM-Pubset B befindet, muss das entsprechende Dateisystem unter dem Zweig /SM-PUB/B eingehängt werden.

Das folgende Bild zeigt, wie während des normalen Betriebs des Systems auf die POSIX-Daten und die HSMS-Metadaten zugegriffen werden kann.

Bild 30: Zugriff auf POSIX-Dateien und HSMS-Metadaten vor einem Systemausfall

Das UNIX-Dateisystem auf dem SM-Pubset A hängt am Host 1. Das UNIX-Dateisystem auf dem SM-Pubset B hängt am Host 2.

Nach einem Systemausfall muss der Systemverwalter die auf "BS2000-UFS: Maßnahmen nach einem Systemausfall" beschriebenen Maßnahmen durchführen, damit die Aktivitäten auf einen Ersatzhost übertragen werden können. Dort wird auf die POSIX-Daten und die HSMS-Metadaten so zugegriffen, wie es im folgenden Bild zu sehen ist.

Bild 31: Zugriff auf POSIX-Dateien und HSMS-Metadaten nach einem Systemausfall

Das UNIX-Dateisystem auf dem SM-Pubset A hängt jetzt nicht mehr am Host 1, sondern am Host 2. 

Ferne Workstations

Beschreibung der Umgebung

Bild 32: HSMS in einem HIPLEX für Workstations mit NFS-Zugriff: Daten-/Metadatenstrom


  • Das HIPLEX-System umfasst mehrere Hosts.

  • Host 1 stellt die HSMS-Funktionen für die ferne Workstation WS1 zur Verfügung.

  • Der Systemverwalter muss die Daten aller Dateisysteme der Workstation auf einem einzigen SM-Pubset (gemeinsam benutzt oder exklusiv) speichern, in diesem Beispiel auf dem SM-Pubset A.

  • Der betreffende SM-Pubset (hier A) muss unter HSMS-Kontrolle gebracht werden (//CREATE-SM-PUBSET-PARAMETERS, HSMS 1 für A).

  • Mehrere Archive müssen auf dem SM-Pubset A angelegt werden.

  • WS1 muss in der Umgebung SM-Pubset A unter HSMS 1-Kontrolle gebracht werden (//MODIFY-NODE-PARAMETERS).

  • Auf die WS1-Daten wird mit NFS zugegriffen – abhängig vom Typ der Workstation (siehe Bild 32).

  • Wenn auf WS1 über NFS zugegriffen wird (siehe Bild 32), muss das Dateisystem von WS1 unter /HSMS im POSIX-Root-Dateisystem eingehängt werden. Zusätzlich muss auch das BS2000-UFS unter HSMS-Kontrolle gebracht werden (//MODIFY-NODE-PARAMETERS).

Während des normalen Betriebs speichert HSMS die zugehörigen Metadaten in der Umgebung, in der auch die WS1-Daten gespeichert sind. 

Maßnahmen nach einem Systemausfall

Nach einem Systemausfall auf Host 1 wird Host 2 als Ersatz-Host bestimmt. Nachdem folgende Maßnahmen durchgeführt wurden, kann HSMS 2 die Arbeit von HSMS 1 fortsetzen.

Maßnahmen auf Host 1

Maßnahmen auf Ersatz-Host 2

Systemausfall
-> Host 1 steht nicht mehr zur Verfügung


                                                                          

Der Systemverwalter muss folgende Maßnahmen durchführen:

  1. /CREATE-VIRTUAL-HOST
    Definieren des virtuellen Hosts.
    (Dieses BCAM-Kommando kann schon beim Starten von HIPLEX gegeben werden – also bereits vor einem Systemausfall.)
  2. /BCACT HOST=Host 2
    Aktivieren des virtuellen Hosts, der nun Host 1 ersetzen muss.
    Nach einem Systemausfall ruft dann der Systemverwalter diese Prozedur auf.)
    In einem TCP/IP-Netzwerk wird die Adresse des neu aktivierten virtuellen Hosts transparent verbreitet.
  3. Importieren des SM-Pubsets A (/IMPORT-PUBSET)
  4. Für Workstations mit Zugriff über NFS:
    Mit NFS die fernen Workstations „einhängen“, die vom Host 1 unter /HSMS verwaltet werden.
  5. HSMS laden und starten, wenn HSMS noch nicht läuft.



Der HSMS-Verwalter muss folgende Maßnahme durchführen:

HSMS-Anweisung RECOVER-REQUESTS REQUEST-DATA-ORIGIN=*NODE für SM-Pubset A geben, um die Aufträge bearbeiten zu können, die vor dem Systemausfall auf dem Host 1 eingeleitet wurden.

Bild 33: HIPLEX für Workstations mit NFS-Zugriff: Erreichbarkeit der Daten/Metadaten nach Systemausfall

Maßnahmen nach Behebung des Systemausfalls

Nachdem Host 1 wieder läuft, können die HSMS-Aktivitäten für die Knotendateien der Workstations auf den ursprünglichen Host zurück übertragen werden. Dazu müssen folgende Maßnahmen durchgeführt werden:

Maßnahmen auf Host 1

Maßnahmen auf Ersatz-Host 2

Ursache des Systemausfalls beseitigt
-> Host 1 steht wieder zur Verfügung


                                                               

Der Systemverwalter muss folgende Maßnahmen durchführen:

  1. Nur für Workstations mit Zugriff über NFS:
    Mit NFS die fernen Dateisysteme „aushängen“, die auf dem SM-Pubset A gesichert wurden.
  2. /CREATE-VIRTUAL-HOST
    Definieren des virtuellen Hosts.
    (Dieses BCAM-Kommando kann schon beim Starten von HIPLEX gegeben werden – also bereits vor einem Systemausfall.)
  3. /BCACT HOST=Host 2
    Aktivieren des virtuellen Hosts, der nun Host 1 ersetzen muss.
    Nach einem Systemausfall ruft dann der Systemverwalter diese Prozedur auf.) In einem TCP/IP-Netzwerk wird die Adresse des neu aktivierten virtuellen Hosts transparent verbreitet.
  4. /BCDAC HOST=Host 2
    Deaktivieren des virtuellen Hosts und Rückkehr auf den ursprünglichen Host 1.
  5. SM-Pubset A exportieren (/EXPORT-PUBSET)


Der Systemverwalter muss folgende Maßnahmen durchführen:


  1. SM-Pubset A importieren (/IMPORT-PUBSET)
  2. Nur für Workstations mit Zugriff über NFS:
    Mit NFS die fernen Workstations „einhängen“, die von Host 1 unter /HSMS verwaltet werden sollen.

Der HSMS-Verwalter muss folgende Maßnahme durchführen:


  1. HSMS-Anweisung RECOVER-REQUESTS REQUEST-DATA-ORIGIN=*NODE für SM-Pubset A geben, um die Aufträge bearbeiten zu können, die vor dem Systemausfall auf Host 1 eingeleitet wurden.


Organisation der Dateisysteme

Für Workstations, auf die ohne NFS zugegriffen wird, sind keine besonderen Voraussetzungen bei der Organisation der Dateisysteme der Workstation zu berücksichtigen.

Für Workstations, auf die mit NFS zugegriffen wird, müssen die Dateisysteme der Workstation unter /HSMS im POSIX-Root-Dateisystem eingehängt werden.

Das folgende Bild zeigt, wie die Dateisysteme der Workstations WS1 und WS2 bei Zugriff über NFS organisiert sein müssen, damit die HIPLEX-Fähigkeit gewährleistet ist.

Bild 34: HIPLEX für Workstations mit NFS-Zugriff: Zugriff auf Metadaten vor einem Systemausfall

Workstation WS1 hängt am Host 1, Workstation WS2 am Host 2. HSMS greift auf die beiden Workstations über NFS zu.

Nach einem Systemausfall von Host 1 muss der Systemverwalter die auf "Ferne Workstations: Maßnahmen nach einem Systemausfall" beschriebenen Maßnahmen durchführen, damit die Aktivitäten auf einen Ersatz-Host übertragen werden können. Dort wird auf die Daten der Workstation WS1 und die HSMS-Metadaten so zugegriffen, wie es im folgenden Bild zu sehen ist.

Bild 35: HIPLEX für Workstations mit NFS-Zugriff: Zugriff auf Metadaten nach einem Systemausfall

Die Workstations WS1 und WS2, die von HSMS verwaltet werden, hängen nun beide am Host 2.

Powered by Atlassian Confluence and Scroll Viewport.