Konfiguration Scheduler

Standard-Konfiguration für alle Betriebssysteme

Für die Nutzung des Scheduler-Diensten ist in der Standard-Konfiguration keine explizite Anpassung notwendig.

Falls der Scheduler über den dsm Client Acceptor Daemon (dsmcad) gestartet werden soll, muss dies in der dsm.sys / dsm.opt durch die folgende Option eingestellt werden:

MANAGEDService SCHEDULE

Der dsmcad wurde für Windows-Rechner empfohlen, weil er weniger Speicherressourcen benötigt, während das Backup nicht läuft. In Anbetracht der aktuellen RAM-Ausstattung von Servern und auch Endgeräten, fällt der Mehrverbrauch durch einen dauerhaft laufenden Scheduler nicht wirklich ins Gewicht. Es ist damit einfacher, direkt den Scheduler als Windows-Dienst zu konfigurieren. Unter Linux hingegen lässt sich der dsmcad direkt über init.d bzw. den systemd starten und während für den Schedulers entsprechene Routinen erstellt werden müssen. Für Linux/BSD wird daher der dsmcad empfohlen.

Darüber hinaus sollten Sie überlegen, die beiden folgenden Optionen zu nutzen:

SCHEDLOGMAX <MB>
SCHEDLOGRetention <days>[D,S]

Über einen der beiden Parameter wird die maximale Größe des Scheduler-Logs festgelegt, entweder über die Dateigröße in MegaByte (ERRORLOGMAX <MB>) oder die Aufbewahrungszeit in Tagen (SCHEDLOGRentenion <days>[D,S]), die zusätzlichen bei Angaben bei der Option ERRORLOGRentenion legen den Umgang mit älteren Logeinträgen fest:

D – Löschen der Daten, (Voreinstellung)
S – Sichern der Daten in einer weiteren Datei dsmschedlog.pru.

Konfiguration bei mehreren Knoten auf einer Maschine

Windows

Die Konfiguration mehrerer Scheduler ist unter Windows ziemlich einfach:

Erstellen Sie für jeden Scheduler eine eigene dsm.opt-Datei.
Weisen Sie bei der Konfiguration des Scheduler-Services die passenden dsm.opt-Datei dem Service zu.

Fertig!

Linux

Die Steuerung erfolgt über die Optionsdatei, der Start der Scheduler durch den DSMcad:

Soll ein Rechner über mehrere Scheduler gesichert werden, so sind für diesen mehrere Knotennamen oder mehrere Server definiert. In beiden Fällen gibt es mehrere SErvername <NAME>-Einträge und Serverdefinitionen in der Konfigurtaionsdatei dsm.sys. Meist gibt es auch mehrere Optionsdatein dsm.opt in unterschiedlichen Ordnern oder mit abweichenden Namen.

Die zu nutzenden Optionsdatei kann entweder im Aufruf der CLI (dsmc -optfile=<NAME>) oder GUI (dsmj -optfile=<NAME>) angegeben werden, alternativ kann die Umgebungsvariable DSM_CONFIG mit dem Namen der passenden Optionsdatei besetzt werden.

Dieser letztgenannte Weg kann genutzt werden, um mehrere Scheduler über den DSMcad auf einem Knoten laufen zu lassen.

Umsetzung -- Systemd

Services werden bei systemd-Linuxen über entsprechende service-Dateien beschrieben. Im Rahmen der Installation des SP-Clients wird eine dsmcad.service-Datei erzeugt und im Konfigurations-Pfad des Clients (i.d.R. /opt/tivoli/tsm/client/ba/bin/) abgelegt. Der

Vorbereiten

Ansatz für mehrere Client-Instanzen besetht nun darin, diese Datei als Vorlage zu nehmen, zu kopieren und anzupassen und anschließend in das systemd-Verzeichnis zu kopieren / verschieben:

cp /opt/tivoli/tsm/client/ba/bin/dsmcad.service /opt/tivoli/tsm/client/ba/bin/dsmcad.instance1.service
.. Editieren ..
ln -s /opt/tivoli/tsm/client/ba/bin/dsmcad..instance1.service /usr/lib/systemd/system/

Nach jeder Änderung an einer Datei im /usr/lib/systemd/system-Verzeichnis muss das Verzeichnis neu eingeladen werden (systemctl daemon-reload).

Die Anpassung der .service-Datei umfasst dabei:

Es ist eine Zeile hinzufügen, die auf das jeweilige opt-File verweist, z.B.
```
Environment="DSM_CONFIG=/opt/tivoli/tsm/client/ba/bin/instance1.opt
```
Das Binary für die Option ExecStart ist auf die Kopie des dsmcad zu ändern, z.B.
```
ExecStart=/usr/bin/dsmcad.instance1
```

Da ExecStart in das Verzeichnis /usr/bin zeigt, muss das Binary vom dsmcad auch dorthin kopiert / verlinkt werden:
ln -s /opt/tivoli/tsm/client/ba/bin/dsmcad.instance1 /usr/bin/
Das Startskript funktioiniert offensichtlich nicht, wenn bei ExecStart direkt auf das Binary im Pfad
/opt/tivoli/tsm/client/ba/bin/ verwiesen wird – warum es dann aber ein Symlink tut?

Ausführen

Der Start erfolgt „ganz normal“ über das systemctl-Kommando, z.B.
```
 systemctl start dsmcad.instance1
```
Ebenso die Etablierung als Dienst beim Systemstart, z.B.:
```
 systemctl enable dsmcad.instance1
```

Umsetzung -- Init-V--Ansatz

Der Start des dsmcad erfolgt über das Skript rc.dsmcad, dieses liegt in der Regel unter /etc/init.d/dsmcad als symbolischer Link zu /opt/tivoli/tsm/client/ba/bin/rc.dsmcad). Für mehrere Knoten auf einem Host, muss dieses kopieren und umbenannt werden, z.B.
```
cd /etc/init.d/ && cp rc.dsmcad rc.dsmcad.knoten_1
```
Um die verschiedenen Prozesse unterscheiden zu können (z.B auch für das service <Name> [start|stop]), sollte auch das benutzte Binary (dsmcad) kopiert werden, z.B.
```
cp /opt/tivoli/tsm/client/ba/bin/dsmcad /opt/tivoli/tsm/client/ba/bin/dsmcad.knoten_1
```
Es kann dann eindeutig identifiziert werden.
Im kopierten Skript (rc.dsmcad.knoten_1)

Achtung: Die Datei ist per default auch für root nur lesbar!
- eine Zeile ergänzen, die die Variable DSM_CONFIG auf die passenden Optionsdatei verweisen lässt, z.B.:
```
export DSM_CONFIG=/opt/tivoli/tsm/client/ba/bin/dsm-node1.opt
```
- Den Namen des Binaries im Skript (Zeile DSMCAD_BIN=…) anpassen, z.B.
```
DSMCAD_BIN=$DSMCAD_DIR/dsmcad.node1
```
Das geänderte Skript kann nun wie das Original-Skript mittels der Parameter start, stop restart und status benutzt werden.

Liegt das neue Skript im Verzeichnis etc/init.d (bzw. liegt dort ein symbolischer Link zum geänderten Skript) kann auch der geänderte DSMcad über die üblichen Wege als Dienst gestartet werden.

z.B.

SuSE:

chkconfig dsmcad-Server_1 on

bzw. zum Start in Runlevel 3 und 5:

chkconfig dsmcad-Server_1 35

generisch:

cd /etc/init.d/
for i in $(ls rc.dsmcad*); 
do 
  ln -s /etc/init.d/$i /etc/init.d/rc3.d/K01$i
  ln -s /etc/init.d/$i /etc/init.d/rc3.d/S15$i
done

OSX

sollte wie bei Linux funktionieren (nicht getestet).