Folgendes Diagramm zeigt, wie eine Versionskontrolle der Systemanpassungen auf CA SDM-Servern durchgeführt wird:

Mit der CA SDM-Versionskontrolle können Sie die Systemanpassungen auf allen CA SDM-Servern (Client und Server) verwalten. Abhängig von der CA SDM-Konfiguration werden folgende Clients und Server verwendet:
casm173
Mit der CA SDM-Versionskontrolle können Sie die Systemanpassungen auf allen CA SDM-Servern (Client und Server) verwalten. Abhängig von der CA SDM-Konfiguration werden folgende Clients und Server verwendet:
  • Konventionelle Konfiguration,
    • Client: Sekundärserver
    • Server: Primärserver
  • Konfiguration für erweiterte Verfügbarkeit,
    • Client: Anwendungsserver und Standby-Server
    • Server: Hintergrundserver
Beispiel: Als Systemadministrator haben Sie ein Feld auf der Seite "detail_usp_server.htmpl" von CA SDM hinzugefügt. Jetzt möchten Sie diese Änderung auf den Clients und den Servern synchronisieren. Dieses Beispiel wird im Szenario verwendet, um zu erläutern, wie die Anpassung synchronisiert wird.
Folgendes Diagramm zeigt, wie eine Versionskontrolle der Systemanpassungen auf CA SDM-Servern durchgeführt wird:
Diagramm zeigt, wie eine Versionskontrolle der Systemanpassungen auf CA SDM-Servern durchgeführt wird.
Gehen Sie folgendermaßen vor:
Verifizieren der Voraussetzungen.
Überprüfen Sie folgende Voraussetzungen:
  • Stellen Sie sicher, dass die Option "ver_ctl" auf den Wert "
    Aktualisieren
    " festgelegt ist. Wenn ein Versionsunterschied erkannt wird, dann wird versucht, die betroffenen Komponenten auf dem Client zu aktualisieren. Wenn das Upgrade erfolgreich ist, bleibt die Client-Verbindung mit dem Server bestehen. Anderenfalls wird die Verbindung getrennt. Weitere Informationen zur Option "ver_ctl" finden Sie in der
    Online-Hilfe
    .
  • Stellen Sie sicher, dass die Datei "server_secondary_custom.ver" im Verzeichnis "$NX_ROOT\site\mods" vom Primärserver oder Hintergrundserver (abhängig von der CA SDM-Konfiguration) erstellt wird. Alle Anpassungen einer Versionskontrollkomponente müssen in dieser Datei vorgenommen werden. Wenn die Datei nicht vorhanden ist, stellen Sie sicher, dass Sie sie am gleichen Speicherort erstellen.
Ändern der Versionskontrolldatei des Servers
Nachdem Sie die Anpassung abgeschlossen haben (zum Beispiel ein Feld auf der HTMPL-Seite hinzugefügt), müssen Sie die Versionskontrollkomponenten der Versionskontrolldatei des Servers hinzufügen oder aktualisieren. Eine Versionskontrollkomponente kann eine Datei, ein Verzeichnis oder die Umgebungsvariablendatei "client_nx.env" darstellen.
Gehen Sie folgendermaßen vor:
  1. Melden Sie sich abhängig von Ihrer CA SDM-Konfiguration bei folgendem Server an:
    • Konventionell: Primärserver
    • Erweiterte Verfügbarkeit: Hintergrundserver
  2. Wechseln Sie in das folgende Verzeichnis:
    $NX_ROOT\site\mods
  3. Öffnen Sie die Datei "server_secondary_custom.ver".
  4. Fügen Sie folgende Komponenten hinzu:
    [ MY_USP_SERVERS_HTMPL ] directory="$NX_ROOT/site/mods/www/htmpl/web/analyst/Analyst" filename="detail_usp_servers.htmpl" version="2.0 , 20121119" o_mode="RW" g_mode="RW" w_mode="RW" file_ctl
    Weitere Informationen über das Hinzufügen oder Aktualisieren von Versionskontrollkomponenten finden Sie im Abschnitt Versionskontrollkomponenten.
  5. Speichern Sie die Datei "server_secondary_custom.ver".
    Die Versionskontrollkomponente wird der Versionskontrolldatei hinzugefügt.
Versionskontrollkomponenten
So definieren Sie eine neue Komponente,
  • Verwenden Sie folgende Syntax. Elemente in
    Kursivschrift
    entsprechen Daten, die Sie bereitstellen. Die Parameter
    component-name
    und Versionsparameter sind immer erforderlich. Andere Parameter sind abhängig vom Wert für "
    control-type
    " erforderlich. Alle anderen Elemente sind Schlüsselwörter, die Sie genau wie m folgenden Beispiel gezeigt eingeben müssen:
    [ component-name ] version = "x.x, yyyymmdd" control-type filename = "filename" directory = "directory" link = "link-directory" source = "source-directory" effectivity = "effect-spec" checksum min_release = "release" max_release = "release" component_type = "file-type" o_mode = "owner-mode" g_mode = "group-mode" w_mode = "world-mode"
    Weitere Informationen zu den Parametern finden Sie unter Versionskontrollparameter. Weitere Informationen zur Struktur und Syntax der Versionskontrolldateien finden Sie in den ".ver"-Dateien, die im Verzeichnis "$NX_ROOT\site" installiert sind. Diese Dateien enthalten nützliche Kommentare und Beispieleinstellungen, die Ihnen helfen können.
So aktualisieren Sie einen vorhandenen Komponenteneintrag,
  • Ändern Sie den Parameter. Ändern Sie zum Beispiel die Versionsnummer.
So entfernen Sie das Steuerelement aus einer Komponente,
  • Bearbeiten Sie die Komponente folgendermaßen:
    ! uncontrol component-name
Versionskontrollparameter
Für die Versionskontrolle gelten die folgenden Parameter:
  • [ component-name ]
    Gibt den Namen eines Elements unter Versionskontrolle an. Der Name muss eindeutig sein und in eckigen Klammern angegeben werden. Bei
    component-name
    muss nicht auf Groß- und Kleinschreibung geachtet werden. Dieser Parameter ist für eine Komponentendefinition erforderlich.
  • Version="x.x. yyymmd"
    Gibt eine Versionsnummer (
    x.x
    ) und ein Datum (
    yyyymmdd
    ) an, die die Version der Komponente definieren. Dieser Parameter ist erforderlich und muss in Anführungszeichen eingeschlossen werden. Die Versionskontrolle prüft die Version einer Komponente, indem sie die Versionsnummer und das Datum auf dem Server mit der Versionsnummer und dem Datum auf dem Client vergleicht. Sowohl die Versionsnummer als auch das Datum müssen übereinstimmen, damit die Komponente als synchron zwischen Client und Server betrachtet wird. Wenn die Prüfsummeneigenschaft aktiviert ist, wird die Datei vor ihrer Aktualisierung durch eine Prüfsummenverifizierung geprüft.
  • control-type
    Gibt den Typ der Versionskontrolle für diese Komponente an. Die folgenden Einstellungen sind für "Kontrolle-Typ" gültig:
Einstellung
Beschreibung
dir_ctl
Gibt an, dass die Komponente ein Verzeichnis darstellt. Sie müssen den Verzeichnisparameter liefern, um den Pfad zum Verzeichnis anzugeben. Sie können auch den Dateinamenparameter angeben, um eine Gruppe von Dateien im Verzeichnis zu filtern. Unterverzeichnisse werden weder unter UNIX noch unter Windows aufgerüstet.
file_ctl
Gibt an, dass die Komponente eine Datei darstellt. Sie müssen den Verzeichnis- und Dateinamenparameter liefern, um den Pfad zur Datei anzugeben.
Nxenv_ctl
Gibt an, dass diese Komponente die Datei "client_nx.env" darstellt, in der interne CA SDM-Umgebungsvariablen gespeichert werden. CA SDM-Versionskontrolle und der Optionsmanager pflegen diese Datei automatisch. Es gibt genau eine nxenv_ctl-Komponente, und ihr Komponentenname muss CLIENT_NXENV lauten.
ver_ctl
Dies ist der Standardkontrolltyp. Er gibt an, dass die Komponente generisch ist; d. h. sie ist nicht mit einem bestimmten externen Objekt verbunden. Mit einer generischen Komponente können Sie eine Versionskontrolle für den Client als Ganzes oder für eine Datei oder ein Verzeichnis zur Verfügung stellen, die bzw. das für eine automatische Aktualisierung zu groß ist. Komponenten mit dem Kontrolltyp „ver_ctl“ können nicht aufgerüstet werden. Ein Versionsunterschied bei einer ver_ctl-Komponente bewirkt einen Abbruch der Clientverbindung, wenn der Server den Modus UPGRADE hat.
  • filename="filename"
    Gibt den Namen einer Datei unter Versionskontrolle an. Dieser Parameter enthält keine Angaben zum Verzeichnis. Er ist für file_ctl-Komponenten erforderlich, ist aber für Komponenten mit Verzeichniskontrolle (dir_ctl) optional. Wenn der Dateinamenparameter zusammen mit Verzeichniskomponenten verwendet wird, fungiert er als Dateimaske, um die mit der dir_ctl-Komponente verbundenen Dateien einzuschränken. Wenn zum Beispiel der Dateiname für eine dir_ctl-Komponente *.README lautet, dann schließt ein Upgrade dieses Verzeichnisses nur Dateien ein, die mit „.README“ enden.
  • directory="directory"
    Gibt den Pfad zum Verzeichnis für dir_ctl-Komponenten oder zu dem Verzeichnis an, das die Datei für file_ctl-Komponenten enthält. Dieser Parameter wird für ver_ctl- und nxenv_ctl-Komponenten ignoriert. Der Verzeichnispfad muss in Anführungszeichen eingeschlossen werden und kann Verweise auf Umgebungsvariablen enthalten, wobei $ vorangestellt werden muss.
    Um Unterverzeichnisse im Pfadnamen zu trennen, verwenden Sie immer den Schrägstrich (nicht den umgekehrten Schrägstrich), auch auf einem Windows-Server.
  • link="link-directory"
    Gibt ein Link-Verzeichnis auf dem Client im gleichen Format an, das zuvor für Verzeichnisparameter beschrieben wurde. Dieser Parameter ist optional für file_ctl- und dir_ctl-Komponenten und wird für ver_ctl- und nxenv_ctl-Komponenten ignoriert. Wenn er angegeben wird, dann wird bei einem Upgrade auf einem Linux-Client ein symbolischer Link ins Link-Verzeichnis gestellt. Dieser verweist auf die eigentliche Datei, die in die im Verzeichnisparameter angegebene Position kopiert wurde. Bei einem Upgrade auf einem Windows-Client wird die eigentliche Datei sowohl in den Link- als auch in den Verzeichnisspeicherort kopiert.
  • source="source-directory"
    (Optional) Gibt ein anderes Verzeichnis auf dem Server an, aus dem der Server Dateien zur Bereitstellung abrufen kann. Dieser Parameter hat das gleiche Format, das zuvor für den Verzeichnisparameter beschrieben wurde. Er ist nützlich, wenn die dem Client bereitzustellenden Dateien sich von den gleichen Dateien im Verzeichnisspeicherort auf dem Server unterscheiden. Dieser Parameter wird verwendet, um dem Server mitzuteilen, dass die Datei aus dem
    source-directory
    abgerufen und an dem im Verzeichnisparameter angegebenen Speicherort auf dem Client bereitgestellt werden soll. Der Verzeichnisparameter ist erforderlich, wenn Sie den Quellparameter angeben.
  • effectivity="effect-spec"
    (Optional) Gibt an, ob der Client diese Komponente erhalten soll. Hiermit können Sie den Download zu einigen Clients ausschließen. Wenn ein Client in die Effektivitätsangabe nicht eingeschlossen ist, erhält er die Komponente nicht. Wenn dieser Parameter nicht angegeben wird, erhalten alle Clients die Komponente. Die Effektivitätsangabe verwendet die folgenden Symbole:
    • + (Pluszeichen)
      Gibt an, dass eine Clientgruppe hinzugefügt werden soll.
    • - (Minusvorzeichen)
      Gibt an, dass eine Clientgruppe ausgeschlossen werden soll.
Die folgenden Clientgruppen sind gültig:
  • SUN4SOL
  • AIX
  • LINUX
  • LINUX390
  • HP
  • WINDOWS_CLIENTS
  • UNIX_CLIENTS
Zum Beispiel gibt Folgendes an, dass nur UNIX-Clients die Dateien erhalten:
effectivity = "+ UNIX_CLIENTS"
  • checksum
    Weist die Komponente zur Aktualisierung an, wenn die Prüfsumme der Komponente auf dem Client nicht mit der entsprechenden Prüfsumme auf dem Server übereinstimmt. Wenn der Parameter für ein Verzeichnis gilt, wird die Prüfsumme auf jede Datei angewandt.
  • min_release=“release” und max_release="release"
    Gibt den ältesten und neuesten Client an, an den diese Komponente verteilt werden soll. Versionen werden durch Anweisungen in der Datei "server_default.ver" definiert. Diese Parameter haben folgende Form, wobei Ga
    xx
    die Version angibt und die folgenden Werte mit der Version verbundene „genlevels“ sind.
    ! Release GA50 50MVV000900 50W7T000900 ! Release GA45 45MW000900 50WTT000900
    Die Reihenfolge gibt an, dass GA50 neuer ist als GA45.
  • component_type
    Gibt den Typ der verwendeten Komponente an. Folgende Typen von Komponenten werden verwendet:
Einstellung
Beschreibung
file
Dies ist der Standardkomponententyp. Er gibt an, dass auf den Client zu kopierende Dateien direkt von dem Speicherort auf dem Server abgerufen werden, der im Verzeichnisparameter angegeben ist.
exe_file
Gibt an, dass auf den Client zu kopierende Dateien von einem Speicherort auf dem Server abgerufen werden, der vom Betriebssystem des Client abhängt, zum Beispiel:
windows (Windows)
sun4Sol (Solaris)
hp (HP-UX)
aix -- AIX)
linux (Linux)
linux390 (Linux390)
Die Speicherorte für diese Unterverzeichnisse hängen von der Einstellung des Verzeichnisparameters ab. Wenn dieser Parameter eingestellt ist, befinden sich Unterverzeichnisse unter dem angegebenen
Verzeichnis
. Andernfalls befinden sie sich unter dem Verzeichnis "bin" des CA SDM-Installationshauptverzeichnisses von .
  • o_mode="owner-mode"
    Gibt die Dateizugriffsberechtigungen für den Eigentümer der Datei an.
  • g_mode="group-mode"
    Gibt Dateizugriffsberechtigungen für Anwender in der Dateieigentümergruppe an (wird nur für UNIX-Clients verwendet).
  • w_mode="world-mode"
    Gibt Dateizugriffsberechtigungen für Anwender an, die nicht in der Dateieigentümergruppe enthalten sind (wird nur für UNIX-Clients verwendet).
    Mit den drei mode-Parametern können verschiedene Versionen derselben ausführbaren Datei auf dem Server verwaltet werden. Sie geben Zugriffssteuerungen für die Datei an, wenn diese auf den Client kopiert wird. Diese Parameter werden nur während eines Upgrades verwendet. Sie bestehen aus einen bis drei Zeichen, die folgende Bedeutung haben:
Einstellung
Beschreibung
R
Gelesen
W
Schreiben
X
Ausführen
PC-Clients ignorieren die Schreib- und Ausführungsberechtigungen.
Sie können jede Kombination eines oder mehrerer Dateizugriffsmodi angeben. Auf UNIX-Clients erhält die Datei den angegebenen Zugriffsmodus. Auf PC-Clients ist die Datei beschreibbar oder schreibgeschützt, abhängig davon, ob w_mode angegeben wurde.
Neustart von CA SDM auf dem Client
Sie starten CA SDM auf den Client-Servern neu, um die Versionskontrolldateien des Clients mit den Anpassungen zu aktualisieren.
Wählen Sie
Start
>
Einstellungen
>
Systemsteuerung
>
Verwaltung
>
Dienste
. Mit der rechten Maustaste in der
CA SDM-Server
, und wählen Sie
Start
, um neu zu starten, oder Starten von Servern.
Gehen Sie folgendermaßen vor:
  1. Starten Sie für die konventionelle Konfiguration den sekundären Server neu.
  2. Führen Sie für die Konfiguration für erweiterte Verfügbarkeit folgende Schritte aus:
    1. Starten Sie alle Standby-Server neu.
    2. Starten Sie den Anwendungsserver neu, der wenig aktiv ist.
    3. Starten Sie den Anwendungsserver.
    4. Führen Sie die Schritte "d" und "e" für weitere Anwendungsserver aus.
    Der Client stellt eine Verbindung mit dem Server her, um eine Liste der gesteuerten Komponenten zu senden. Der Server vergleicht die Liste mit seiner eigenen Hauptliste. Die betroffenen Komponenten auf dem Client werden aktualisiert.
Auswählen des Anwendungsservers, der wenig aktiv ist
Sie wählen einen Anwendungsserver mit der geringsten Anwenderaktivität aus. Führen Sie folgenden Befehl auf jedem Anwendungsserver aus, um den Server auszuwählen, der keine oder nur wenige aktive Sitzungen hat.
pdm_webstat
: Dieser Befehl erfasst nicht die SOAP- oder REST-Webservice-Sitzungen.
Anhalten der anderen Anwendungsserver
Sie benachrichtigen alle aktiven Anwender auf einem Anwendungsserver darüber, auf den am wenigsten aktiven Anwendungsserver zu wechseln, bevor Sie ihn anhalten. Stellen Sie sicher, dass Sie den Anwendungsserver, der am wenigsten aktiv ist, neu gestartet haben, bevor Sie alle Anwender dorthin verschieben.
Gehen Sie folgendermaßen vor:
  1. (Empfohlen) Fordern Sie alle aktiven Support-Automatisierungs-Analysten auf dem Anwendungsserver, den Sie anhalten möchten, dazu auf, ein Ticket in CA SDM mit ihren Sitzungsinformationen zu erstellen. Dieser Vorgang stellt sicher, dass die Sitzungsinformationen nicht verloren gehen. Zum Beispiel ist der Support-Automatisierungs-Analyst in einer Sitzung mit einem Kunden, um einen Hardware-Issue zu lösen. In diesem Fall kann der Support-Automatisierungs-Analyst einen Issue in CA SDM mit den Sitzungsinformationen erstellen, bevor der Anwendungsserver heruntergefahren wird.
  2. Senden Sie eine Benachrichtigung (zum Beispiel eine E-Mail-Benachrichtigung) an alle aktiven Anwender auf dem Anwendungsserver, in der die Anwender aufgefordert werden, zum Anwendungsserver, der am wenigsten aktiv ist und den Sie gerade neu gestartet haben, zu wechseln. Diese Benachrichtigung kann die Details des aktualisierten Anwendungsservers enthalten.
  3. Führen Sie folgenden Befehl auf dem Anwendungsserver aus:
    pdm_server_control [-h] -q interval -s server_name
    • -h
      Zeigt die Hilfeseite an.
    • -q interval -s server_name
      Benachrichtigt einen lokalen Anwendungsserver oder einen Remote-Anwendungsserver, eine Stilllegung in einem angegebenen Zeitintervall durchzuführen. Dieses Intervall ist die Anzahl von Sekunden, bevor der Server offline geschaltet wird. Wenn Sie diese Option ohne "Servername" verwendet, dann wird der lokale Server zur Stilllegung benachrichtigt. Diese Option kann für einen Hintergrundserver oder einen Standby-Server nicht verwendet werden.
    Eine Pop-up-Meldung wird allen aktiven Anwendern auf dem Anwendungsserver angezeigt. Die Meldung weist auf das Herunterfahren des Servers und auf die verbleibende Zeit bis zum Herunterfahren hin. Die Anwender müssen ihre Arbeit speichern und sich innerhalb dieser Zeit abmelden. Der Anwendungsserver wird nach der angegebenen Zeit angehalten. Die Anwender melden sich auf dem anderen Anwendungsserver an, um ihre Arbeit fortzusetzen. Der Support-Automatisierungs-Analyst kann sich auf das Ticket beziehen und seine Arbeit fortsetzen.
    Der Anwendungsserver wird erfolgreich angehalten.
Überprüfen der Anpassungen auf dem Client
Sie überprüfen die Versionskontrolldatei auf dem Client, um zu überprüfen, ob alle Anpassungen synchronisiert wurden.
Gehen Sie folgendermaßen vor:
  1. Melden Sie sich abhängig von Ihrer CA SDM-Konfiguration auf folgendem Client an:
    • Konventionell: Sekundärserver
    • Erweiterte Verfügbarkeit: Standby-Server und Anwendungsserver
  2. Öffnen Sie die Datei "stdlog" vom folgenden Speicherort:
    $NX_ROOT\log
  3. Finden Sie heraus, ob alle auf dem Server vorgenommenen Anpassungen auf dem Client angewendet wurden.